[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Chicken-users] Srfi-19 problems
[Chicken-users] Srfi-19 problems
Thu, 06 Nov 2008 19:56:22 -0800
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 MULE XEmacs/21.4 (patch 21) (Educational Television) (i386--freebsd)
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)
#,(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
(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
<syntax> (use files)
<syntax> (##core#require-extension (quote files))
<syntax> (begin (##sys#require (quote files))
<syntax> (##sys#require (quote files))
<syntax> (quote files)
<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.
- [Chicken-users] Srfi-19 problems,
Timothy Beyer <=