Hi Leslie, after only 2-3 hours of playing with Weblocks I wouldn't start to modify it :) The solution I posted works, but I don't know yet enought about Weblocks to know the exact and right place to put that code in the Weblocks source tree. One possible place (from what I understand until now about Weblocks) would be for example as a first line of weblocks.asd, but the user's of weblocks should know about that, so they are not puzzled in some rare situations (see the explanation below). The code I sent you could actually belong more to ASDF than to Weblocks, but since about 2 years I don't know who is the actual maintainer of ASDF.
But - the code above is very simple and you can much better decide than me, where would be the right place to put and/or invoke it. It has only 2 public functions : cache-asdf-locations and uncache-asdf- locations. The first one should be called before starting the Weblocks/ Hunchentoot server (it may be called before or after loading Weblocks). The function is transparent, it fills it's cache lazy, so it wouldn't affect the normal operation of ASDF or Weblocks. The only occasion, when one would need to invoke (uncache-asdf-locations) and turn the caching off, is when one moves an existing ASDF-system to a different folder, while Weblocks/Hunchentoot are running, while that moved system is needed by Weblocks or the application running in it. In that case one should invoke (uncache-asdf-locations) before reloading that system and invoke again (cache-asdf-locations) after it, to reenable the caching and avoid the hundrets of PROBE-FILE which could otherwise go to the operatins system and dramatically slow the operation of the server. So - sorry for not sending a patch - but I think - this is better, than to send one for the wrong place :) With best regards Plamen On Mar 24, 12:52 pm, "Leslie P. Polzer" <[email protected]> wrote: > > Weblocks computes on each client request the path of the application, > > which (if i understand correctly, if not set by the developer > > explicitly) is calculated from the path of the ASDF-system to which > > the application belongs. For that Weblocks calls asdf:system- > > definitions-pathname, which on it's turn traverses all known > > directories known to ASDF to search and does a PROBE-FILE for .asd > > files with the name of the system searched. And that can take a while. > > Not knowing if this is an intendet behavior of Weblocks I implemented > > a small function, which memoizes the .asdf locations per system, which > > I turn on before loading Weblocks. Then - the demo responds allways in > > less than a second. > > That's interesting. Could you submit a full patch? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "weblocks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/weblocks?hl=en -~----------~----~----~----~------~----~------~--~---
