[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Chicken-users] srfi-19, etc.

From: Kon Lovett
Subject: [Chicken-users] srfi-19, etc.
Date: Wed, 4 Jan 2006 10:32:56 -0800

Hi Felix,

("My" srfi-19 is based/inspired on/by the PLT Scheme & Scsh ports of the reference, but I didn't do anything extraordinary to chg your "crap" opinion. I do try to clean & streamline where I can though.)

Nearly "finished" w/ locale, srfi-29 & srfi-19. They pass their tests. Some restrictions/notes in 0.1:

- locale is posix only, MacOS CoreFoundation support in 0.2, Windows in ?

- locale is not hooked into any of the comparison (collate) or conversion machinery,
it exists to support srfi-29 (for now)

- srfi-29 bundles are stored in (make-pathname (repository-path) "srfi-29-bundles"), but can be overridden by the caller

- no support for NLS (posix msg catalogs), MacOS, or Windows resources by srfi-29

- srfi-19 rqrs the numbers egg (I do not look forward to the numerical analysis necessary to shift to use of inexact arithmetic)

- when posix locale is not set the default country & language are 'us & 'en (the parameters can be set by the caller)

- timezones are rudimentary, besides srfi-19 "support" I integrated the info available from the Chicken local & gm time procedures. I need to think about a timezone object. I have the Olsen tz database but I will leave this until (if) I move to platform specific timezone support.

- the definition of gc-time is cumulative, built from the current-gc- time proc

- process-time is the sum of cpu-time components

- thread-time is process-time

I've a few jobs to do before 0.1 release to svn repo:

- Add timezone name support (this will be an incomplete hack for now, just enough to get the ~Z format to do something reasonable)

- Add .meta & .setup

- Add eggdoc (not a small job I know, 0.1 will probably just note the extensions & fixes then refer to the srfi doc)

I'm going to leave any attempt at integration of srfi-18 & srfi-19 time to later. While the support for the time struct is straightforward, if messy, the collision of the (current-time) procedures is a problem. Need to discuss this.

Suggestion: how about adding an optional flag to the seconds->local/ utc-time procs to state if the timezone abbreviation string is desired. This could be the 11'th vector element. I can code this as a patch if you think it advisable. (I don't need it but it would be nice for the std Chicken api.)

Best Wishes,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]