1.6.8 release candidate 0 available for testing.

1.6.8 release candidate 0 available for testing.

[Rob Browning]

For now it's available here:

  http://people.debian.org/~rlb/tmp/guile-1.6.8-rc0.tar.gz

Please test.  This file isn't likely to become the actual release, but
it's probably close.

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: 1.6.8 release candidate 0 available for testing.

[Greg Troxel]

This builds on NetBSD/i386 3.99.9, and almost passes make check,
except for:

FAIL: time.test: strftime %Z doesn't return garbage

I renamed the distfile to avoid fighting the package system (the
1.6.8-rc0 could be 1.6.8rc0 to make it more clearly part of the
version, but I'm not sure that's it).

With the patches in NetBSD pkgsrc, the built/installed guile worked,
where works means that I used guile-pg, guile-gnome, and a private ospf
lsa access library via a guile wrapper.

The two patches I sent in private mail are not yet in your rc tarball,
but probably should be.

Thanks for making the tarball.

-- 

        Greg Troxel <gdt@ir.bbn.com>


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

Re: 1.6.8 release candidate 0 available for testing.

[Kevin Ryde]

Greg Troxel <gdt@ir.bbn.com> writes:
>
> This builds on NetBSD/i386 3.99.9, and almost passes make check,
> except for:
>
> FAIL: time.test: strftime %Z doesn't return garbage

Can you pick out the code from that test to see what it does return?
(It's supposed to test that the timezone string passes straight
through.)


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

Re: 1.6.8 release candidate 0 available for testing.

[Greg Troxel]

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

> Greg Troxel <gdt@ir.bbn.com> writes:
>
> > FAIL: time.test: strftime %Z doesn't return garbage
> 
> Can you pick out the code from that test to see what it does return?
> (It's supposed to test that the timezone string passes straight
> through.)

strftime of %Z returns "EST", which is the correct time zone for the
program given no TZ in environment and isdst zero.  Comments in the
NetBSD libc sources indicate that returning the current zone is
a legitimate response according to C99.

gdt 133 ~ > cat time.scm
(define t (localtime (current-time)))

(display t)
(display "\n")

(set-tm:zone t "UTC")
(set-tm:isdst t 0)

(display t)
(display "\n")

(display (strftime "%F %T %Z" t))
(display "\n")

gdt 132 ~ > guile -s time.scm
#(15 37 15 18 9 105 2 290 1 14400 EDT)
#(15 37 15 18 9 105 2 290 0 14400 UTC)
2005-10-18 15:37:15 EST

There's a buglet in the guile info docs in that strftime has a cross
reference to the libc info file, and that would seem to be Linux
specific.  The docs also don't state if strftime in scheme is supposed
to conform to C99, translated into Scheme, or something else.  I note
that the strftime source in libguile accomodates systems w/o a
timezone field.  NetBSD's struct tm has one, but doesn't use it in
strftime:

In src/lib/libc/time/strftime.c:

			case 'Z':
#ifdef TM_ZONE
				if (t->TM_ZONE != NULL)
					pt = _add(t->TM_ZONE, pt, ptlim);
				else
#endif /* defined TM_ZONE */
				if (t->tm_isdst >= 0)
					pt = _add(tzname[t->tm_isdst != 0],
						pt, ptlim);
				/*
				** C99 says that %Z must be replaced by the
				** empty string if the time zone is not
				** determinable.
				*/
				continue;


This code is this way because using tm_zone would violate ISO-C; gory
details at:

http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=21722

So, I respectfully suggest that the test is demanding more than one
can rightfully conclude from the documentation.
Perhaps libguile/strftime.c needs to not assume that strftime(3) will examine
fields not specified by the standard, or perhaps that Scheme strftime
should define what it does more precisely.  A problem here is that
guile uses a structure which is bigger than C89 says.

I didn't find C99 specs for strftime, so I don't know if programs are
required to set tm_zone before calling strftime.

It would be interesting to run the test program from the PR on Linux.

Anyway, this isn't a new issue and has nothing to do with 1.6.8; have
seen this before but never tracked it down.  So whether it changes or
not, it's not in the way of a 1.6.8 release.





-- 
        Greg Troxel <gdt@ir.bbn.com>


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

Re: 1.6.8 release candidate 0 available for testing.

[Kevin Ryde]

[taking this bit separately]

Greg Troxel <gdt@ir.bbn.com> writes:
>
> There's a buglet in the guile info docs in that strftime has a cross
> reference to the libc info file, and that would seem to be Linux
> specific.

You mean gnu-specific of course, strftime probably doesn't go near the
kernel.  But in any case I don't think it's too terrible for a gnu
package to xref other gnu package.  I'll add "or see man 3 strftime",
if you like.


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

Re: 1.6.8 release candidate 0 available for testing.

[Kevin Ryde]

Greg Troxel <gdt@ir.bbn.com> writes:
>
> I didn't find C99 specs for strftime, so I don't know if programs are
> required to set tm_zone before calling strftime.

The bit about %Z is

         %Z  is   replaced  by  the  locale's  time  zone  name  or
             abbreviation, or by no characters if no time  zone  is
             determinable.  [tm_isdst]

which I suppose is because struct tm is speced without tm_zone.

> So, I respectfully suggest that the test is demanding more than one
> can rightfully conclude from the documentation.

You'd think a system with tm_zone should use it, but yes no sense
demanding what doesn't work.

> Perhaps libguile/strftime.c needs to not assume that strftime(3) will examine
> fields not specified by the standard, or perhaps that Scheme strftime
> should define what it does more precisely.  A problem here is that
> guile uses a structure which is bigger than C89 says.

Since we initialize tm_zone if it exists we should be safe, but a note
in the docs about what guile tm:zone might or might not do could be in
order.


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

Re: 1.6.8 release candidate 0 available for testing.

[Greg Troxel]

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

> > There's a buglet in the guile info docs in that strftime has a cross
> > reference to the libc info file, and that would seem to be Linux
> > specific.
> 
> You mean gnu-specific of course, strftime probably doesn't go near the
> kernel.  But in any case I don't think it's too terrible for a gnu
> package to xref other gnu package.  I'll add "or see man 3 strftime",
> if you like.

Sorry you are quite right, I should have said GNU libc (is that used
on other than Linux and HURD these days?).

In this case, GNU libc is not a requirement for guile, which runs on
free operating systems with GNU libc, free OS w/o GNU libc and
non-free OS.  The real reference is to the C99-specified strftime.  I
think what bothered me was the broken link in the info file since I do
not have GNU libc info files installed.  I tried to follow it, and
then realized it was a cross-file link.  So, sure, adding "or see
strftime(3)" would help.

-- 
        Greg Troxel <gdt@ir.bbn.com>


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

Re: 1.6.8 release candidate 0 available for testing.

[Greg Troxel]

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

> Greg Troxel <gdt@ir.bbn.com> writes:
>
> The bit about %Z is
> 
>          %Z  is   replaced  by  the  locale's  time  zone  name  or
>              abbreviation, or by no characters if no time  zone  is
>              determinable.  [tm_isdst]
> 
> which I suppose is because struct tm is speced without tm_zone.

Probably.  NetBSD libc uses the environment variable or /etc/localtime.

> You'd think a system with tm_zone should use it, but yes no sense
> demanding what doesn't work.

Yes, but the point (from the PR) is that a conforming program doesn't
have to set it, so libc reading it causes undefined behavior, and thus
libc can't read it.

> > Perhaps libguile/strftime.c needs to not assume that strftime(3)
> > will examine fields not specified by the standard, or perhaps that
> > Scheme strftime should define what it does more precisely.  A
> > problem here is that guile uses a structure which is bigger than
> > C89 says.
> 
> Since we initialize tm_zone if it exists we should be safe, but a note
> in the docs about what guile tm:zone might or might not do could be in
> order.

Sure, guile sets it.  Options I see are

1) declare the Scheme proc strftime has extended semantics beyond C99,
   document them, and make the implementation set TZ before calling
   strftime (perhaps unless an implementation which guarantees to read
   tm_zone is detected).

2) Document that the scheme proc strftime conforms, after langauge
   mapping, to C99, and point out that thus tm_zone is expected to be
   ignored because it isn't part of the standard.  Perhaps don't set
   the non-C99 fields in what is used for the libc call to avoid
   nonportable expectations.

The meta-issue I see here is about guile providing consistent behavior
on all platforms.  On some points it seems to do this, but it also at
times just wraps OS libraries.  One of the wins of guile is
portability, and I'd like to keep as much of that as possible.

-- 
        Greg Troxel <gdt@ir.bbn.com>


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

Re: 1.6.8 release candidate 0 available for testing.

[Ludovic Courtès]

Hi,

Greg Troxel <gdt@ir.bbn.com> writes:

> Sorry you are quite right, I should have said GNU libc (is that used
> on other than Linux and HURD these days?).

Sure it is: GNU/kFreeBSD[0] and even...  GNU/NetBSD[1].  I know there
has been significant work on the former, don't know about the latter.

> In this case, GNU libc is not a requirement for guile, which runs on
> free operating systems with GNU libc, free OS w/o GNU libc and
> non-free OS.  The real reference is to the C99-specified strftime.  I
> think what bothered me was the broken link in the info file since I do
> not have GNU libc info files installed.  I tried to follow it, and
> then realized it was a cross-file link.  So, sure, adding "or see
> strftime(3)" would help.

Well, Guile is a GNU project after all, which is primarily meant to be
used on the GNU system, so I think it makes perfect sense to include
links to documentation of other GNU software.  However, adding a note
like the one you propose for non-GNU users might be a good idea too.

Thanks,
Ludovic.

[0] http://www.debian.org/ports/kfreebsd-gnu/
[1] http://www.debian.org/ports/netbsd/


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

Re: 1.6.8 release candidate 0 available for testing.

[Kevin Ryde]

Greg Troxel <gdt@ir.bbn.com> writes:
>
> 1) declare the Scheme proc strftime has extended semantics beyond C99,
>    document them,

Straight "pass through" to libc sounds good to me.

>    and make the implementation set TZ before calling
>    strftime (perhaps unless an implementation which guarantees to read
>    tm_zone is detected).

That might be slow.  I notice what localtime does changing TZ is a
noticable slowdown with glibc.  (It re-reads the timezone file(s) on
every TZ change.)

I wonder if munging the global tzname[] variable would be enough.  Bad
for multi-threading, but we've got issues with that in the time funcs
already.

>    Perhaps don't set
>    the non-C99 fields in what is used for the libc call to avoid
>    nonportable expectations.

I wouldn't deliberately break something just because it's not
portable.

> The meta-issue I see here is about guile providing consistent behavior
> on all platforms.

Though I see your point.


PS. I added "man 3 strftime" to the manual.


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

Re: 1.6.8 release candidate 0 available for testing.

[Kevin Ryde]

Greg Troxel <gdt@ir.bbn.com> writes:
>
> strftime of %Z returns "EST", which is the correct time zone for the
> program given no TZ in environment and isdst zero.  Comments in the
> NetBSD libc sources indicate that returning the current zone is
> a legitimate response according to C99.

I disabled the guile test.

> It would be interesting to run the test program from the PR on Linux.

segv, which is I guess is the same as the PR says, a bug if you're
world is only c99.


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

Re: 1.6.8 release candidate 0 available for testing.

[Greg Troxel]

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

> Greg Troxel <gdt@ir.bbn.com> writes:
> 
> Straight "pass through" to libc sounds good to me.
> 
> >    and make the implementation set TZ before calling
> >    strftime (perhaps unless an implementation which guarantees to read
> >    tm_zone is detected).
> 
> That might be slow.  I notice what localtime does changing TZ is a
> noticable slowdown with glibc.  (It re-reads the timezone file(s) on
> every TZ change.)
> 
> I wonder if munging the global tzname[] variable would be enough.  Bad
> for multi-threading, but we've got issues with that in the time funcs
> already.

If we munge the variable or set TZ, then scheme strftime will have
stricter semantics than C99.  Also, I wonder if setting the variable
is safe according to the standard which defines it; that seems
dangerous.

> >    Perhaps don't set
> >    the non-C99 fields in what is used for the libc call to avoid
> >    nonportable expectations.
> 
> I wouldn't deliberately break something just because it's not
> portable.
> 
> > The meta-issue I see here is about guile providing consistent behavior
> > on all platforms.
> 
> Though I see your point.

I realize this is a tough call, but declining to provide more behavior
than the relevant standard ensures that the original programmer finds
the 'bug', rather than it later being a portability problem.

> PS. I added "man 3 strftime" to the manual.

Thanks, that will be helpful to some I think.


-- 
        Greg Troxel <gdt@ir.bbn.com>


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

Re: 1.6.8 release candidate 0 available for testing.

[Kevin Ryde]

Greg Troxel <gdt@ir.bbn.com> writes:
>
> I realize this is a tough call,

I kicked it into touch, by adding this to the manual

     Note that `%Z' might print the `tm:zone' in TM or it might print
     just the current zone (`tzset' above).  A GNU system prints
     `tm:zone', a strict C99 system like NetBSD prints the current
     zone.  Perhaps in the future Guile will try to get `tm:zone' used
     always.

and this comment as a reminder

@c
@c  The issue in the above is not just whether tm_zone exists in
@c  struct tm, but whether libc feels it should read it.  Being a
@c  non-C99 field, a strict C99 program won't know to set it, quite
@c  likely leaving garbage there.  NetBSD, which has the field,
@c  therefore takes the view that it mustn't read it.  See the PR
@c  about this at
@c
@c      http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=21722
@c
@c  Uniformly making tm:zone used on all systems (all those which have
@c  %Z at all of course) might be nice (either mung TZ and tzset, or
@c  mung tzname[]).  On the other hand it would make us do more than
@c  C99 says, and we really don't want to get intimate with the gory
@c  details of libc time funcs, no more than can be helped.
@c


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