Re: [Chicken-users] Srfi-19 problems

[Kon Lovett]

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.

While I doubt "echo $TZ" = "PST+187634:57:36XXXX+187633:57:36" what is  
the value, if any?

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

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

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

> I haven't had a chance to fix the time issue, but I was just curious  
> if anyone on the list knew of any immediate solutions to the  
> problem.  If I get around to fixing it, I will send any diffs, but  
> I'm busy this over the next week or so, (and my knowledge of  
> chicken's core libraries is rather limited) so it looks unlikely  
> that this will happen anytime soon.
>
> My apologies about the excessively long message.
>
> Regards,
> Tim
>
>
> _______________________________________________
> Chicken-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/chicken-users

Best Wishes,
Kon