Re: [Chicken-users] Srfi-19 problems

[Timothy Beyer]

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:
> 
> >
> > Dear Chicken Users List,
> >
> > Since approximately version 2.6 I have noticed that (current-date)  
> > thinks that the date is 1987. These tests were performed on chicken  
> > scheme 3.3.0, (on FreeBSD) though I have only documented these  
> > problems on all of the 3 series.  (I am not sure when the problem  
> > began)
> >
> >> (current-date)
> > #,(date 443000000 54 35 23 12 6 1987 -675485856 PST #f #f #f #f)
> 
> 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)

(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

> 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?


> >
> >
> > when I give current-date the proper timezone as an argument, (my  
> > timezone is -8 of GMT), such as:
> >> (current-date (* -1 8 60 60))
> > it gives the correct value of:
> > #,(date 140000000 0 34 18 6 11 2008 -28800 #f #f #f #f #f)
> 
> FWIW, you can construct your own 'local-timezone-locale' using 'make- 
> timezone-locale' & the locale-components procedures of the "locale" egg.
I'll take a look at that procedure.

> 
> >
> >
> > In my own programs, I just extract the output of the unix date  
> > command, and feed that information to make-date, but I recently  
> > noticed that most programs that use srfi-19 don't have such a  
> > workaround, which leads me to believe that no one else is  
> > experiencing this problem, or that this issue is just be something  
> > on FreeBSD that differs from Linux, such that (make-local-timezone- 
> > locale) needs an extra conditional, or that it might work with the  
> > same code as macosx in the cond-expand), I'm not sure.
> >
> > I have decided that my current shell workaround is a hack, (although  
> > it's only a problem for third-party chicken scheme programs) since I  
> > don't want to modify source of third party programs generally, and  
> > it's not portable.  So I investigated the problem a bit further.  I  
> > ran srfi-19/tests/basic-test.scm, and it seems to fail on string- 
> > >date test, (all of the tests in the locale egg work correctly)  
> > indicating problems in (local-timezone-locale), as far as I can tell.
> >
> > (local-timezone-locale) returns the following:
> > (#f (name . "PST+187634:57:36XXXX+187633:57:36") (source . "POSIX")  
> > (std-name . "PST") (std-offset . 675485856) (dst-name . "XXXX") (dst- 
> > offset . 675482256) (dst-start (4 1 0) . 3600) (dst-end (10 5 0) .  
> > 3600))
> 
> Hum, should export 'timezone-locale-component' & 'timezone-locale-dst- 
> flag'. A 'timezone-locale' will probably be opaque at some point.
> 
> >
> >
> > An example of a potential bug caused by the incorrect value is in  
> > the hato mail suite.  When I was using hato-fetch a few months ago,  
> > I observed that it purged emails prematurely becuase the timezone  
> > was calculated incorrectly, and it seems to utilize srfi-19, which I  
> > belive was only caused by the program believing that the year was  
> > 1987.
> >
> > I noticed the current-date problem early this year, but then I  
> > forgot about it for a few months, until last week, when I when  
> > started working on another medium sized program, and noticed that my  
> > extended prelude was failing to compile.  For some reason, at this  
> > point, simply loading srfi-19 caused an instant segfault, so at  
> > least a clean reinstall of my eggs was in order.
> >
> > Then I reinstalled all of my eggs.  As I was doing so, I ran into  
> > another strange problem.  It seems that many eggs still use the  
> > files module, which by all accounts appears to be deprecated, (as  
> > far as I can tell, all of it's functions are preloaded in base now)  
> > and yet many extensions still use it.
> 
> 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.

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.
> >
> >
> > I get the following error when trying to load the files extension:
> >> (use files)
> > Error: (require) can not load extension: files
> >
> >     Call history:
> >
> >     <syntax>                (use files)
> >     <syntax>                (##core#require-extension (quote files))
> >     <syntax>                (begin (##sys#require (quote files)) 
> > (##core#undefined))
> >     <syntax>                (##sys#require (quote files))
> >     <syntax>                (quote files)
> >     <syntax>                (##core#undefined)
> >     <eval>          (##sys#require (quote files))   <--
> >
> > I manually modified all offending eggs, made a makefile for each,  
> > then manually reinstalled them (I was lazy, but I'm sure chicken has  
> > some kind of internal build system that is easier to use).
> >
> > If anyone knows of a way to make chicken automatically ignore (use  
> > files), or might have an idea why files isn't loading correctly, I  
> > would be interested to know how/why.  I only read "supported  
> > language" in the manual, which doesn't mention that files no longer  
> > is a separate module.
> >
> > If I missed anything in the user's manual that provided information  
> > on this change, or if my chicken installation is broken in some way,  
> > I will be sure to look into it.
> >
> > 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)

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.
> 

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

Regards,
Tim