[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,
Kon
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Chicken-users] srfi-19, etc.,
Kon Lovett <=