<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Mar 8, 2014 at 7:15 PM, Faré <span dir="ltr"><<a href="mailto:fahree@gmail.com" target="_blank">fahree@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Dear Liam,<br>
<div class=""><br>
> I am using asdf-system-connections and notice a glitch in its design. As the<br>
> original author no longer maintains it, I'm try to fix this myself. This<br>
> system is designed to allow the loading of a connected system (say "A")<br>
> automatically when two or more dependent systems (say "B" and "C") are<br>
> loaded. The problem I'm encountering is that when another system (say "D")<br>
> is defined to depend on B and C, then A is not loaded until after D is done<br>
> loading, but D may need the definitions in A. asdf-system-connections<br>
> defines a function load-connected-systems which does the work of loading the<br>
> connected system definitions, but this is called from a new #'operate :after<br>
> method which apparently doesn't get called until A is done loading.<br>
><br>
</div>If you depend on A rather than merely on B and C, then<br>
the obvious solution is to depend on A.<br></blockquote><div><br></div><div>Thanks Faré, this is so obvious, I'm embarrassed I didn't think of it myself!<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Actually, I would go so far as to discourage use of asdf-system-connections,<br>
and encourage only explicit dependency on connection systems.<br>
IIUC, the hu.dwim team changed their systems this way, at my suggestion.<br>
<div class=""><br>
> I am looking for a place from which to call load-connected-systems that will<br>
> trigger its call as soon as it's able, i.e., immediately once both "B" and<br>
> "C" are loaded. I'm not familiar with the internals of ASDF and wonder if<br>
> someone can guide me to a good place to define this.<br>
><br>
</div>There is no such place. Even what asdf-system-connections is a bit of a stretch.<br>
On @(ASDF3), you could try an after method on make-plan, or something like that,<br>
but it will be quite ugly, and will confuse the hell out of the<br>
methods that call<br>
traverse-action directly, etc.<br>
<br>
Frankly, the whole idea is bunk. A build system ought to be<br>
predictable, reproducible, and minimize surprise.<br>
asdf-system-connections, as it stands, is not great in this regards,<br>
but at least does not disrupt the internal dependency model of ASDF;<br>
it stands on top. Your proposed extension requires subverting basic<br>
invariants of ASDF internals.<br></blockquote><div><br></div><div>Well, I think it has some use, though now in the Quicklisp era it's less important, and that is to define an optional dependency for something that's incidental to the main system. For example, one of my projects (Antik) defines units as part of a large system for doing science/engineering math. As a convenience, it will use the degree symbol. In order to get the degree symbol, I use cl-unicode. This is an incidental use of one (big) system for the occasional (cosmetic) augmentation of another. Most people will not care about units at all, and so loading cl-unicode grows the system mostly unnecessarily, and adding a new user-visible system definition complicates users' mindspace for a mostly unused benefit (and imagine you have 3 optional definitions like this - then you would need to define 7 new systems to capture each combination). The alternative is to give up on the degree symbol, but it is nice to have it when you use degrees, and easy (one line of source code) to add if cl-unicode is present.<br>
<br></div><div>The old Lisp machine (Symbolics) had an option in the defsystem form :load-when-systems-loaded, which allowed you to add on modules/files to be loaded when certain other specified system(s) were loaded, but would not force the load of those systems. This worked quite well and was very nice for a case like this.<br>
<br>From Symbolics SCT, Volume 12, "Program Development Utilities," p. 24:<br>:load-when-systems-loaded<br>"The :load-when-systems-loaded option instructs SCT not to load some<br>modules of a system when a set of required systems is not loaded.<br>
When all the required systems become loaded, SCT automatically loads<br>the unloaded modules.<br>Including this option in a module has two effects:<br>- If the required systems are not all loaded, that module is not<br>loaded.<br>
- When all the required systems become loaded, SCT goes back and loads<br>the module.<br>- You cannot safely patch that module, as it might not be loaded yet<br>at the time patches are loaded.<br>:load-when-systems-loaded differs from the :required-systems option<br>
to defsystem in that :required-systems gives an error if the required<br>systems are not present. :load-when-systems-loaded never gives an<br>error.<br>...<br>Example:<br>(defsystem print-spooler<br> (:default-pathname t)<br>
(:module unix-spooler ("ux-spool")<br> (:load-when-systems-loaded :unix-support))<br> (:serial (:parallel "defs" "macros")<br> "spooler"<br> "unix-spooler"))<br>
Suppose the system UNIX-SUPPORT is _not_ loaded. When you load the<br>PRINT-SPOOLER system, all the files in the system are loaded except<br>for those files in UNIX-SPOOLER module (namely, ux-spool). If and<br>when you load the UNIX-SUPPORT system, the files in the UNIX-SPOOLER<br>
[module] will get loaded."<br><br></div><div>[Yes, I still have the full set of Symbolics manuals on my shelf.]<br></div><div><br></div><div><br></div><div>Liam<br> </div></div><br></div></div>