<div class="gmail_quote">2011/2/22 Márcio Faustino <span dir="ltr"><<a href="mailto:marciombfaustino@gmail.com">marciombfaustino@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">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.</div>

</blockquote><div><br></div><div>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.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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?<br>

</blockquote><div><br></div><div>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.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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"):<br>
(let ((*load-verbose* (if (find "-q" (ext:command-args) :test #'equal) nil t)))<br></blockquote><div><br></div><div>This is known. Lisp compilers/loaders by default always produce noise.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

I also noticed that it takes a really long time to load Quicklisp whenever I start up ECL, almost 2s.</blockquote><div><br></div><div>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.</div>

</div><div><br></div>Juanjo<br clear="all"><br>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com" target="_blank">http://juanjose.garciaripoll.googlepages.com</a><br>