[Ecls-list] ECL with XAMPP

[Juan Jose Garcia-Ripoll]

2011/2/22 Márcio Faustino <marciombfaustino at gmail.com>

> Yes, when I want to quickload some module then I need to ensure I do that
> inside the Visual Studio command prompt. What I don't get is why do I even
> need it again when running Lisp code as a CGI script with the correct
> HOMEDRIVE and HOMEPATH variables defined. It should find that the modules
> are already compiled and should just load them like it does on a regular
> command prompt.
>

I do not know. This is related to ASDF/Quicklisp territory. It may be that
it evaluates the forms and some functions are still compiled on the fly even
if the modules have been compiled too -- some libraries, for instance,
compile functions as they go. This is what the bytecodes file compiler tries
to solve, though it is not 100% stable yet.


> However, I wrapped the execution of the Lisp script using a Python script
> communicating with it via popen. This allowed me to start it and load
> Quicklisp by manually passing the Visual Studio required environment
> variables. All this sounds fishy to me, so I'm pretty sure I'm going to have
> problems soon. This can't be the right way to do it. Any ideas?
>

Investigate the list of environment variables that the Microsoft Visual
Studio provides and teach them to ECL? I can not force ECL to "capture"
those variables in arbitrary builds, but it might be an option to recognize
the logic in Microsoft's tools and try to embed this in some
"configure-msvc" function that automates the process.

I also had to do this in my ".eclrc" file when loading Quicklisp, so that I
> don't have any output before the start of the HTTP headers (e.g.
> "Content-Type"):
> (let ((*load-verbose* (if (find "-q" (ext:command-args) :test #'equal) nil
> t)))
>

This is known. Lisp compilers/loaders by default always produce noise.


> I also noticed that it takes a really long time to load Quicklisp whenever
> I start up ECL, almost 2s.


This is a problem with Windows. When ECL has to load a compiled filed it has
to make a copy of it. It can't just use DLLOpen because that "locks" the
file and avoids recompilation / deletion of the file. That means ECL has to
copy each one of the compiled files of each library that Quicklisp requires.
Add to this the fact that Quicklisp is not using ECL's extensions, which
allow merging multiple compiled files in a single FASL file and you get the
slow loading times. Help is welcome on how to solve this -- there might be
better ways to do this.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20110222/ec0dd528/attachment.html>