[local-time-devel] Locating the zoneinfo repository

[Abhishek Reddy]

 Hi,

On Fri, Oct 30, 2009 at 10:57 PM, Attila Lendvai
<attila.lendvai at gmail.com>wrote:

> >   * When LOAD-ing local-time (not via ASDF) while ASDF is incidentally
> > loaded into the image, local-time will try to locate the ASDF package
> path
> > anyway, ignoring *load-pathname*.  The result may be NIL, yielding an
> error
> > in constructing the pathname.
>
>
>
> fixed
>

Works for me.


>   * When LOAD-ing local-time (not via ASDF) while there is no ASDF in the
> > image, *project-home-directory* will default to the directory of
> > *load-pathname*, which in the current source tree layout is src/ --
> whereas
> > the repository is under src/../ -- eventually causing an error in
> TRUENAME.
>
>
> fixed
>

Works for me.



>  >   * In a saved image that includes local-time (via ASDF) and ASDF
> itself,
> > the value of *project-home-directory* may be set at the time of
> saving.[1]
> > If the image is deployed in a different environment, it may not find the
> > repository, eventually causing an error in TRUENAME.
>
>
> that's the usual issue which needs to be taken care of the one who
> saves the image. if static timezone files are ok, then read them
> before saving. if they are not, then no smartness is enough to handle
> the issue without the saver's help.
>

Okay, but maybe local-time can handle the case more consistently.  See below
about conditions.


 >   * In a saved image that includes local-time but excludes ASDF, the
> package
> > path cannot be found, and *load-pathname* may be NIL.[2]  This yields an
> > error in constructing the pathname, before the client has a chance to do
> > anything about it.
>
>
> should be fixed
>

Still a problem in ECL since (or *compile-file-truename* *load-truename*) =>
NIL.  Merging "../" fails before the client gets control.  This works:

diff -rN old-local-time/src/local-time.lisp
new-local-time/src/local-time.lisp
201c201
<           (try (merge-pathnames "../" path)))
---
>           (when path (try (merge-pathnames "../" path))))


Is the noisy warning necessary?  In ECL, it writes to stderr just before the
client code runs.  In a saved executable, it is expected that the directory
might not be found at boot, so the warning is not useful there.  Muffling
the warning from the client side could be unnecessarily complicated (I'm not
sure if it is even possible), or might affect other unexpected warnings or
stderr messages.  In SBCL, the saved path is not checked at boot, and no
warning is raised -- which is inconsistent with the behaviour in ECL.

I would prefer instead a condition/error to be generated when an invalid
project home directory is used, with a descriptive report.  Signalling late
in the program should make local-time's behaviour more consistent and
predictable.  (It would even help in the case of an interactive session --
suppose something in the filesystem changes after the parameter is
initialized.)

Attached is a patch demonstrating one kind of condition scheme.  Is
something like this viable?

Thanks!

-- 
Abhishek Reddy
http://abhishek.geek.nz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/local-time-devel/attachments/20091031/ae974f84/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: local-time-invalid-directory.patch
Type: text/x-diff
Size: 2664 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/local-time-devel/attachments/20091031/ae974f84/attachment.patch>