Re: [Chicken-users] Srfi-19 problems

[Kon Lovett]

On Nov 7, 2008, at 12:58 PM, Timothy Beyer wrote:

> At Fri, 7 Nov 2008 10:19:36 -0800,
> Hi Kon,
>
> Kon Lovett wrote:
> > Hello Tim,
> >
> > Sorry you are having problems with the SRFI 19 Chicken impl.
> >
> > On Nov 6, 2008, at 7:56 PM, Timothy Beyer wrote:
<snip>
> > When the "srfi-19" egg loads it initializes the '(local-timezone-
> > locale)' from either the string value of the "TZ" environment  
> > variable
> > (the "locale" egg actually does this) or "fakes" one from '(seconds-
> > > local-time (current-seconds))' if there isn't any TZ value (hum,
> > should have the "locale" egg do this).
> >
> > What does '(seconds->local-time (current-seconds))' return? The
> > timezone-offset is the 10th element in the returned vector.
> (seconds->local-time (current-seconds))
> returns
> #(17 42 12 7 10 108 5 311 #f 675485856)

So the FreeBSD struct tm doesn't have the timezone offset field. I  
shall look into this.

> (apparently I don't have TZ set at all, my mistake)

> After I set TZ, it returns (ran this a few minutes later)
>
> > (seconds->local-time (current-seconds))
> #(40 51 12 7 10 108 5 311 #f 675485856)
>
> But for some reason, it is working with TZ set

In POSIX systems the environment variable is used first if available.  
Then other techniques are tried. (Currently the only other "technique"  
is the use of the C library 'localtime' call.)

> > While I doubt "echo $TZ" = "PST+187634:57:36XXXX+187633:57:36" what  
> > is
> > the value, if any?
> It doesn't seem to be set, I think a value of
>
> of
> TZ=PST8PDT resolves the problem completely though.
>
> Maybe the extension should raise an exception if TZ is unset?

Maybe a warning if the "locale" egg cannot determine the timezone. But  
it cannot be a requirement to have the timezone available.

>
<snip>
> > The "files" unit came into existence with Chicken 3.4.0 (you are  
> > using
> > 3.3.0 I see). I suggest creating a empty extension "files" so
> > 'require' doesn't barf, upgrading Chicken, or using earlier versions
> > of eggs.
> Ah, my mistake, I think I did the majority of the testing about 1.5  
> weeks ago, so that's why I'm behind on the version.

Not a mistake.

> It might be nice to have an UPDATING file with the major changes  
> that egg users should be aware of though.  If there is already  
> something like this, then great.

As others have indicated the addition of the Unit files was poorly  
handled.

> > >
<snip>
> > > Also, to Felix: it might be a good idea to include srfi-19 in the
> > > chicken base installation because time functions are used in many
> > > programs. (On a tangent, on a quick examination of sbky, date or  
> > > ls -
> > > la is for commit time is used instead of srfi-19, because that is
> > > working properly for me)  That way, it could be consistently working
> > > with the latest and greatest releases.
> >
> > It won't happen (and I am unanimous in this).
>
> Fair enough, but it would be nice if packages could require a  
> specific range of versions of chicken when major changes like this  
> occur (The Haskell community does this with hackage).  For example  
> on this specific package version, the requirements could be chicken  
> >= 3.4, and then changed accordingly with each release if there are  
> any significant changes)

Yes, the eggs that were modified to require the Unit files, such as  
"srfi-29", should have the Chicken version requirement in the .setup  
file.

> I tend to use the latest eggs, but I don't use a new chicken version  
> until it's on the releases page, and sometimes I'm .1 behind on that  
> page, as well, because I'm lazy.

No, the lazy person was me since I forgot to add the Chicken version  
requirement.

> >
<snip>
> >
> Thanks Kon, the information was very helpful.  It seems that the  
> TZ=PST8PDT was all that was needed though to fix the problem!

Yes, but you have pointed out a, minor but real, core Chicken problem.  
Thank you.

> Regards,
> Tim

Best Wishes,
Kon