Preparing for a 1.6.8 release.

Preparing for a 1.6.8 release.

[Rob Browning]

I'd like to release 1.6.8 quite soon.

Given that, if there are issues that need to be resolved that you
think I might overlook, please speak up.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Preparing for a 1.6.8 release.

[Steve Ellcey]

Rob,

> I'd like to release 1.6.8 quite soon.
> 
> Given that, if there are issues that need to be resolved that you
> think I might overlook, please speak up.
> 
> Thanks
> -- 
> Rob Browning
> rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
> GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4

Rob,

I was hoping the next release of guile would be buildable on IA64 HP-UX.
The change that is needed is to modify libguile/continuations.c,
libguile/continuations.h, and libguile/gc.c to have ifdefs on IA64
instead of __ia64__.

IA64 is set in libguile/gc_os_dep.c only for IA64 Linux.  __ia64__ is set
by GCC (and other compilers) for both Linux and HP-UX.  But the code
that is under the __ia64__ ifdef is Linux specific and will not compile
on HP-UX.

I made the ifdef changes to guile 1.6.7 to test them and I still had a
bulid problem that I don't understand, the build of libguile seemed to
work fine but the overall libguile make died while making some
documentation:

| cat alist.doc arbiters.doc async.doc backtrace.doc boolean.doc chars.doc continuations.doc debug.doc dynl.doc dynwind.doc environments.doc eq.doc error.doc eval.doc evalext.doc extensions.doc feature.doc fluids.doc fports.doc gc.doc goops.doc gsubr.doc guardians.doc hash.doc hashtab.doc hooks.doc init.doc ioext.doc iselect.doc keywords.doc lang.doc list.doc load.doc macros.doc mallocs.doc modules.doc numbers.doc objects.doc objprop.doc options.doc pairs.doc ports.doc print.doc procprop.doc procs.doc properties.doc random.doc rdelim.doc read.doc root.docrw.doc scmsigs.doc script.doc simpos.doc smob.doc sort.doc srcprop.doc stackchk.doc stacks.doc stime.doc strings.doc strop.doc strorder.doc strports.doc struct.doc symbols.doc throw.doc values.doc variable.doc vectors.doc version.doc vports.doc weaks.doc symbols-deprecated.doc ramap.doc unif.doc filesys.doc posix.doc net_db.doc socket.do
 c regex-posix.doc | GUILE="/shale/sje/guile/obj/pre-inst-guile" /shale/sje/guile/guile-1.6
 .7/scripts/snarf-check-and-output-texi --manual > guile.texi || { rm guile.texi; false; }
| ERROR: In procedure variable-set-name-hint!:
| ERROR: Wrong type argument in position 2 (expecting SYMBOLP): #<freed cell 40050f00; GC missed a reference>
| make[2]: *** [guile.texi] Error 1
| make[2]: Leaving directory `/shale/sje/guile/obj/libguile'

I don't know if this is a known issue or IA64 specific or what since I
am not that familiar with guile (I mostly just want to build autogen).

Steve Ellcey
sje@cup.hp.com


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Preparing for a 1.6.8 release.

[Kevin Ryde]

Rob Browning <rlb@defaultvalue.org> writes:
>
> I'd like to release 1.6.8 quite soon.

In GUILE-VERSION, I think the libtool versioning
LIBGUILE_INTERFACE_REVISION and
LIBGUILE_SRFI_SRFI_13_14_INTERFACE_REVISION should be incremented, for
changes to the code there.

Except I'm not sure that's been done before has it?

(The soname doesn't change, just the sub-minor version on the library
filename.  Probably affects just about nothing.)


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Preparing for a 1.6.8 release.

[Rob Browning]

Kevin Ryde <user42@zip.com.au> writes:

> In GUILE-VERSION, I think the libtool versioning
> LIBGUILE_INTERFACE_REVISION and
> LIBGUILE_SRFI_SRFI_13_14_INTERFACE_REVISION should be incremented, for
> changes to the code there.
>
> Except I'm not sure that's been done before has it?
>
> (The soname doesn't change, just the sub-minor version on the library
> filename.  Probably affects just about nothing.)

Right, and thanks.  That's on my to-do.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Preparing for a 1.6.8 release.

[Ludovic Courtès]

Hi,

Rob Browning <rlb@defaultvalue.org> writes:

> I'd like to release 1.6.8 quite soon.
>
> Given that, if there are issues that need to be resolved that you
> think I might overlook, please speak up.

Just to let you know: on `powerpc-unknown-linux-gnu', the compilation
went fine and the test suite run well too.

  Testing /home/ludo/tmp/guile-1.6.8/pre-inst-guile ...
  with GUILE_LOAD_PATH=/home/ludo/tmp/guile-1.6.8/test-suite
  Running alist.test
  Running and-let-star.test
  Running bit-operations.test
  Running c-api.test
  Running chars.test
  Running common-list.test
  Running environments.test
  Running eval.test
  Running exceptions.test
  Running filesys.test
  Running format.test
  Running gc.test
  Running getopt-long.test
  Running goops.test
  Running guardians.test
  Running hash.test
  Running hooks.test
  Running import.test
  Running interp.test
  Running list.test
  Running load.test
  Running numbers.test
  Running optargs.test
  Running poe.test
  Running popen.test
  Running ports.test
  Running posix.test
  Running r4rs.test
  Running ramap.test
  Running reader.test
  Running receive.test
  Running regexp.test
  Running slib.test
  Running srcprop.test
  Running srfi-1.test
  Running srfi-10.test
  Running srfi-13.test
  Running srfi-14.test
  Running srfi-17.test
  Running srfi-19.test
  Running srfi-31.test
  Running srfi-39.test
  Running srfi-4.test
  Running srfi-9.test
  Running strings.test
  Running symbols.test
  Running syncase.test
  Running syntax.test
  Running time.test
  Running unif.test
  Running version.test
  Running weaks.test

  Totals for this test run:
  passes:                 9742
  failures:               0
  unexpected passes:      0
  expected failures:      18
  unresolved test cases:  0
  untested test cases:    0
  unsupported test cases: 9
  errors:                 0

  PASS: check-guile

Thanks,
Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Preparing for a 1.6.8 release.

[Rob Browning]

Steve Ellcey <sje@cup.hp.com> writes:

> I was hoping the next release of guile would be buildable on IA64 HP-UX.
> The change that is needed is to modify libguile/continuations.c,
> libguile/continuations.h, and libguile/gc.c to have ifdefs on IA64
> instead of __ia64__.
>
> IA64 is set in libguile/gc_os_dep.c only for IA64 Linux.  __ia64__ is set
> by GCC (and other compilers) for both Linux and HP-UX.  But the code
> that is under the __ia64__ ifdef is Linux specific and will not compile
> on HP-UX.

I'll need to think about this for a moment.  We can't use IA64
directly if it's only defined in gc_os_dep.c, since that's not
something continuations.c or gc.c can see.

I also don't want to introduce any new header symbols during a stable
release, so the least intrusive change would probably be to copy the
detection logic from gc_os_dep.c (or something similar) to
continuations.c and gc.c.

I haven't investigated carefully yet -- do you have any idea offhand
if the __ia64__ guarded bits in those files are absolutely Linux
specific?  If we're not *sure*, then we'll need to reverse the sense
of the test and just exclude HP-UX so that we don't accidentally break
some other ia64 platform.

> | ERROR: In procedure variable-set-name-hint!:
> | ERROR: Wrong type argument in position 2 (expecting SYMBOLP): #<freed cell 40050f00; GC missed a reference>

I can't recall if I already asked this, but could you re-try with
the 1.6.8-rc0 archive (or current 1.6 CVS)?

> I don't know if this is a known issue or IA64 specific or what since I
> am not that familiar with guile (I mostly just want to build autogen).

We had a similar problem on ia64/Linux, but with rc0 it seems to have
vanished, at least on the machine I tested.  We still have a problem
on m68k.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Preparing for a 1.6.8 release.

[Steve Ellcey]

> > IA64 is set in libguile/gc_os_dep.c only for IA64 Linux.  __ia64__ is set
> > by GCC (and other compilers) for both Linux and HP-UX.  But the code
> > that is under the __ia64__ ifdef is Linux specific and will not compile
> > on HP-UX.
> 
> I'll need to think about this for a moment.  We can't use IA64
> directly if it's only defined in gc_os_dep.c, since that's not
> something continuations.c or gc.c can see.

You are right, for some reason I was thinking of gc_os_dep.c as a header
file and thinking that continuations.c and gc.c would see the
definition.  My change would break IA64 Linux but I didn't see that
because I was testing on IA64 HP-UX where I didn't want IA64 defined
anyway.

> I haven't investigated carefully yet -- do you have any idea offhand
> if the __ia64__ guarded bits in those files are absolutely Linux
> specific?  If we're not *sure*, then we'll need to reverse the sense
> of the test and just exclude HP-UX so that we don't accidentally break
> some other ia64 platform.

The code might work for other OS's, the problem on HP-UX is that HP-UX
made ucontext_t an opaque type and then provided access functions to get
the information that guile is trying to access directly from ucontext_t.
If the other OS's provide ucontext_t and let you access it directly the
code might work there.

> I can't recall if I already asked this, but could you re-try with
> the 1.6.8-rc0 archive (or current 1.6 CVS)?

I did try 1.6.8.rc0 and got the same results.

> We had a similar problem on ia64/Linux, but with rc0 it seems to have
> vanished, at least on the machine I tested.  We still have a problem
> on m68k.

Given that things don't work with 1.6.8.rc0 even after changing __ia64__
to IA64 I think it is reasonable not to address this problem for 1.6.8.

I'd like to get guile working at some point on the HP-UX IA64 platform
but I don't know if that means getting the 1.6.* branch to work or if I
should just look at the top-of-tree sources.

Steve Ellcey
sje@cup.hp.com


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Preparing for a 1.6.8 release.

[Rob Browning]

Steve Ellcey <sje@cup.hp.com> writes:

> Given that things don't work with 1.6.8.rc0 even after changing __ia64__
> to IA64 I think it is reasonable not to address this problem for 1.6.8.

Well, if we can do it safely and fairly easily, I'd still be inclined
to add the code for ucontext_t on HP-UX because that lowers the bar
for future progress.  Is there a sufficiently specific test that you
think might be appropriate?

> I'd like to get guile working at some point on the HP-UX IA64 platform
> but I don't know if that means getting the 1.6.* branch to work or if I
> should just look at the top-of-tree sources.

Well if your needs aren't short-to-medium term, or if your intended
purpose can handle a potentially very unstable guile, then you might
want to focus on CVS HEAD (i.e. 1.7).  However, if you need something
stable, then 1.6 is it.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Preparing for a 1.6.8 release.

[Steve Ellcey]

> > Given that things don't work with 1.6.8.rc0 even after changing __ia64__
> > to IA64 I think it is reasonable not to address this problem for 1.6.8.
> 
> Well, if we can do it safely and fairly easily, I'd still be inclined
> to add the code for ucontext_t on HP-UX because that lowers the bar
> for future progress.  Is there a sufficiently specific test that you
> think might be appropriate?

Well the test for IA64 and not HP-UX would be "defined(__ia64) &&
!defined(__hpux)".  __hpux and __ia64 are defined by both the HP
compilers and GCC on IA64 HP-UX.  __hpux__ and __ia64__ are only defined
by GCC.  IA64 Linux GCC defines __ia64 and __ia64__ but not any of the
hpux macros.

> Well if your needs aren't short-to-medium term, or if your intended
> purpose can handle a potentially very unstable guile, then you might
> want to focus on CVS HEAD (i.e. 1.7).  However, if you need something
> stable, then 1.6 is it.

Sounds like 1.6 is more in line with what I want (1.6.9 if not 1.6.8).

Steve Ellcey
sje@cup.hp.com


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Preparing for a 1.6.8 release.

[Rob Browning]

Steve Ellcey <sje@cup.hp.com> writes:

> Well the test for IA64 and not HP-UX would be "defined(__ia64) &&
> !defined(__hpux)".  __hpux and __ia64 are defined by both the HP
> compilers and GCC on IA64 HP-UX.  __hpux__ and __ia64__ are only defined
> by GCC.  IA64 Linux GCC defines __ia64 and __ia64__ but not any of the
> hpux macros.

So what code should be used on HP-UX?  Should the code in gc_os_dep.c
that's currently guarded by IA64 be enabled or not, and should gc.c
and continuations.c be doing something different for HP-UX, or nothing
at all?

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Preparing for a 1.6.8 release.

[Steve Ellcey]

> So what code should be used on HP-UX?  Should the code in gc_os_dep.c
> that's currently guarded by IA64 be enabled or not, and should gc.c
> and continuations.c be doing something different for HP-UX, or nothing
> at all?

Well, I am not sure.  There seem to be two ways to attack this, create
some HP-UX specific code for continuations.c and gc.c, which would be to
replace the access of ucontext_t with calls and then set IA64 in
gc_os_dep.c and do more HP-UX specific stuff in that file.  Or bail out
of the continuations.c and gc.c changes (use the default case) and just
use more generic code.  I am not sure what the right way to go is.

I don't have the HP-UX specific code for continuations.c and gc.c at
hand, my first thought was to just skip that code and use the generic C
code.  That is why I was wondering if we wanted to punt on 1.6.8.  And,
to add one more complication, the accessor functions that I would use to
replace the IA64 Linux code are not in libc, but in a library called
libuca.so so that library would need to be linked in with guile.  I
don't know if that complicates things or not.

I am not sure exactly what schedule 1.6.8 is on but I will be down from
tomorrow afternoon until Monday because of an office move over the
weekend.

Steve Ellcey
sje@cup.hp.com


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Preparing for a 1.6.8 release.

[Rob Browning]

Steve Ellcey <sje@cup.hp.com> writes:

> Well, I am not sure.  There seem to be two ways to attack this, create
> some HP-UX specific code for continuations.c and gc.c, which would be to
> replace the access of ucontext_t with calls and then set IA64 in
> gc_os_dep.c and do more HP-UX specific stuff in that file.  Or bail out
> of the continuations.c and gc.c changes (use the default case) and just
> use more generic code.  I am not sure what the right way to go is.

Does HP-UX work with the generic code?  If so, then what would be the
advantage to anything else?

> I don't have the HP-UX specific code for continuations.c and gc.c at
> hand, my first thought was to just skip that code and use the generic C
> code.  That is why I was wondering if we wanted to punt on 1.6.8.  And,
> to add one more complication, the accessor functions that I would use to
> replace the IA64 Linux code are not in libc, but in a library called
> libuca.so so that library would need to be linked in with guile.  I
> don't know if that complicates things or not.

Adding support for the library would probably mean we'd need to add at
least a bit of autoconfery.

> I am not sure exactly what schedule 1.6.8 is on but I will be down from
> tomorrow afternoon until Monday because of an office move over the
> weekend.

I think we're probably not in any danger of a release before then, but
you're probably right.  There's no reason this can't wait for 1.6.9,
which I can release as soon as we figure it out.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Preparing for a 1.6.8 release.

[Steve Ellcey]

> Does HP-UX work with the generic code?  If so, then what would be the
> advantage to anything else?

It's hard to say.  It builds but I die with:

ERROR: In procedure variable-set-name-hint!:
ERROR: Wrong type argument in position 2 (expecting SYMBOLP): #<freed cell 40050
f20; GC missed a reference>

And I don't really know why at this point.

> I think we're probably not in any danger of a release before then, but
> you're probably right.  There's no reason this can't wait for 1.6.9,
> which I can release as soon as we figure it out.

Sounds good.  I'll see if I can figure out more about why it dies where 
it dies.

Steve Ellcey
sje@cup.hp.com


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel