[asdf-devel] clearing output-translations for a "dumped" image

[Dave Cooper]

Hi Anton,

Thanks for asking about this -- I have not started experimenting with this
yet in earnest.

My main concern is the internals of asdf and Quicklisp itself. Setting
ql:*quicklisp-home* at new image startup time at least does appear to allow
Quicklisp itself to function normally with the new local quicklisp/
directory. The main problem I was having trouble previously was
re-initializing asdf output-translations. They were getting "stuck" to
something hardcoded to an absolute pathname under "/home/dcooper8/.." (or
Windows equivalent)  which of course is a no-go for a target delivery
machine.

I still have not managed to re-initialize asdf output-translations to the
local home-directory cache of the target user, which is the desired
outcome. The best I have managed so far is to disable output-translations
entirely, so that the fasl's end up near the sources. This is not an ideal
scenario because the target user loses for example the platform-separation
benefits of output-translations.

I have not yet tried Fare's latest advice or looked at re-initializing
output-translations recently. I have to do it very soon however so I will
let you know where things end up.

For the particular case of webserver applications which rely on static
files: I am not yet familiar with Hunchentoot, but Allegroserve has the
concept of publishing static files with functions "publish-file" and
"publish-directory."

At startup time, our standard restart-init-function (for internal
development and for deployed applications) establishes the local
installation directory, which also determines the location of
ql:*quicklisp-home* -- and we simply re-publish (with Allegroserve's
publish-file or publish-directory operators) the static files. We do not
attempt to have Allegroserve magically reproduce the published locations of
static files in a newly started image - we always explicitly call
publish-file or publish-directory as part of the restart-init-function.  I
would think that any library which depends on static files in a similar way
should provide a "publish-resources" function which can be called as part
of a restart-init-function for any image.

Anyway I will keep you apprised of progress in the next days while I am
trying to prepare images for distribution.

Regards

 Dave





On Fri, Mar 1, 2013 at 1:32 PM, Anton Vodonosov <avodonosov at yandex.ru>wrote:

> Dave, do you have success with moving saved lisp image to new
> machine/directory,
> when the image has asdf and quicklisp loaded?
>
> I am trying this too, and (asdf:clear-configuration) is not enough for
> systems
> loaded from quicklisp.
>
> For example many libraries keep static files, like .html, .css in their
> repositories.
> And at run-time access these resources with asdf:system-relative-pathname.
>
> The simplest example is hunchentoot. If you do
>   (ql:quickload :hunchentoot)
>   (hunchentoot:start (make-instance 'hunchentoot:easy-acceptor :port 4242))
>
> and open http://127.0.0.1:4242/ you see hunchentoot default page and
> documentation.
> These pages are served from
> quicklisp\dists\quicklisp\software\hunchentoot-1.2.7\www\
>
> When I save a lisp image and copy the image together with quicklisp/
> directory
> to another location, the libraries can not locate their static files. In
> my example,
> hunchentoot says "The requested URL / was not found on this server."
>
> I have tried to (asdf:clear-configuration) before saving the image and
> after
> image is restored to
>   (setf ql:*quicklisp-home* (truename (merge-pathnames "quicklisp/"
> *default-pathname-defaults*)))
>   (ql:setup)
> but it didn't help.
>
> So saving lisp image only work for me in tiny applications where I know
> there
> is no need for resources from file system.
>
> For general use, where application depends on many libraries I am afraid
> there
> is no way to make relocatable lisp images. Even if I find a way to
> reinitialize
> asdf and quicklisp configurations, there are libraries which have their
> own custom
> variables holding file system paths. For such applications I only see one
> reliable
> way - prebuild all the .fals files with disabled asdf-output-translations
> so that
> .fals files are placed near the sources. Then copy full application and
> library
> sources to new location and reload them by (load "quicklisp/setup.lisp")
> (ql:quickload :my-application).
>
> Best regards,
> - Anton
>
>


-- 
My Best,

Dave Cooper, Genworks Support
david.cooper at genworks.com, dave.genworks.com(skype)
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20130301/716e2912/attachment.html>