[Chicken-users] Srfi-19 problems

[Timothy Beyer]

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

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

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.

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.

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