<div dir="ltr"><div><br></div>Hi Anton,<div><br></div><div>Thanks for asking about this -- I have not started experimenting with this yet in earnest. <br><div style><br></div><div style>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. </div>
<div style><br></div><div style>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. </div>
<div style><br></div><div style>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. </div>
<div style><br></div><div style>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." </div>
<div style><br></div><div style>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. </div>
<div style><br></div><div style>Anyway I will keep you apprised of progress in the next days while I am trying to prepare images for distribution. </div><div style><br></div><div style>Regards</div><div style><br></div><div style>
 Dave</div><div style><br></div><div style><br></div><div style><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 1, 2013 at 1:32 PM, Anton Vodonosov <span dir="ltr"><<a href="mailto:avodonosov@yandex.ru" target="_blank">avodonosov@yandex.ru</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dave, do you have success with moving saved lisp image to new machine/directory,<br>
when the image has asdf and quicklisp loaded?<br>
<br>
I am trying this too, and (asdf:clear-configuration) is not enough for systems<br>
loaded from quicklisp.<br>
<br>
For example many libraries keep static files, like .html, .css in their repositories.<br>
And at run-time access these resources with asdf:system-relative-pathname.<br>
<br>
The simplest example is hunchentoot. If you do<br>
  (ql:quickload :hunchentoot)<br>
  (hunchentoot:start (make-instance 'hunchentoot:easy-acceptor :port 4242))<br>
<br>
and open <a href="http://127.0.0.1:4242/" target="_blank">http://127.0.0.1:4242/</a> you see hunchentoot default page and documentation.<br>
These pages are served from quicklisp\dists\quicklisp\software\hunchentoot-1.2.7\www\<br>
<br>
When I save a lisp image and copy the image together with quicklisp/ directory<br>
to another location, the libraries can not locate their static files. In my example,<br>
hunchentoot says "The requested URL / was not found on this server."<br>
<br>
I have tried to (asdf:clear-configuration) before saving the image and after<br>
image is restored to<br>
  (setf ql:*quicklisp-home* (truename (merge-pathnames "quicklisp/" *default-pathname-defaults*)))<br>
  (ql:setup)<br>
but it didn't help.<br>
<br>
So saving lisp image only work for me in tiny applications where I know there<br>
is no need for resources from file system.<br>
<br>
For general use, where application depends on many libraries I am afraid there<br>
is no way to make relocatable lisp images. Even if I find a way to reinitialize<br>
asdf and quicklisp configurations, there are libraries which have their own custom<br>
variables holding file system paths. For such applications I only see one reliable<br>
way - prebuild all the .fals files with disabled asdf-output-translations so that<br>
.fals files are placed near the sources. Then copy full application and library<br>
sources to new location and reload them by (load "quicklisp/setup.lisp") (ql:quickload :my-application).<br>
<br>
Best regards,<br>
- Anton<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>My Best,<br><br>Dave Cooper, Genworks Support<br><a href="mailto:david.cooper@genworks.com">david.cooper@genworks.com</a>, <a href="http://dave.genworks.com">dave.genworks.com</a>(skype)<br>
USA: 248-327-3253(o), 1-248-330-2979(mobile)<br>UK: 0191 645 1699<br>
</div>