<div class="gmail_extra">I thought I'd report back briefly on some results.</div><div class="gmail_extra"><br></div><div class="gmail_extra">First, I spent some time attempting to implement "perform with session state". This is the idea that when working with ASDF, it would be useful to be able to invoke or create specific behavior for my use case and also to be able to capture work session state without relying on globals. This was partially successful, but I broke something and ran out of patience. ASDF is some wonderful code, but takes a bit to grok it all.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">So I took the crude approach of just installing a global and using it to accumulate loaded files from within a perform. I created an .asd file which defined the dependencies I wanted the image to have. The loaded it with load-system. Then at the end of load-system I inserted code to save a structure containing a list of the *defined-systems* as well as a list of the loaded files (in order of loading).</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">The next step was to create a little loader script which loads all of the files, and then populates *modules* via satisfies. There were a couple of glitches. For one, a couple of systems had hard coded asdf dependencies. After removing them, they compiled fine. Then another system required asdf-system-connections. I needed to remove that out of the file load list because it isn't necessary after things are loaded.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Finally the load list works, the image saves and starts just fine. I can use regular ol' REQUIRE to provide a sanity check, although I realize this may not be the best approach, at least it works without extra code. </div>
<div class="gmail_extra"><br></div><div class="gmail_extra">This saved about 10% on the image size compared to asdf-loading the same systems, and cleared out some unnecessary dependencies. It will take a while to work out the best "batteries included" image. I can always load ASDF for a given project if it needs to incorporate other systems, smaller projects can just load themselves.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Of course for development I'll still be using ASDF a hundred times a day!</div><div class="gmail_extra"><br></div><div class="gmail_extra">Erik.</div><div class="gmail_extra">
<br></div><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 23, 2012 at 2:10 PM, Robert Goldman <span dir="ltr"><<a href="mailto:rpgoldman@sift.info" target="_blank">rpgoldman@sift.info</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 4/23/12 Apr 23 -3:52 PM, Erik Pearson wrote:<br>
> Hi Robert,<br>
</div><div class="im">> What I was thinking is that OPERATE assembles the plan via TRAVERSE,<br>
> then executes it via PERFORM-PLAN, which calls PERFORM to translate the<br>
> abstraction of operation + component into an action with side effect. It<br>
> seems to me that it is each PERFORM (or, rather, the ones that we are<br>
> interested in) that needs to be captured, since it is only in the body<br>
> of the PERFORM method that the abstractions are made concrete in into<br>
> lisp forms which carry out the desired actions.<br>
><br>
> What I am referring to as "recording" is to append the lisp forms<br>
> produced by each PERFORM into a list or other structure. At present this<br>
> structure would need to be a global, but ideally it would be a slot in a<br>
> session object that threads through each PERFORM. It is because the<br>
> PERFORMS are carried out serially by PERFORM-PLAN according to the plan<br>
> assembled by TRAVERSE that they can be "played back" to recreate the<br>
> actions of this asdf session. Now if there were parallel executions of<br>
> PERFORMs by PERFORM-PLAN, that would be different...<br>
><br>
> I hope that makes sense.<br>
<br>
</div>I suppose, but I don't know how you break into what PERFORM does.<br></blockquote><div><br></div><div>A quick and dirty way, as I described above, does require breaking into PERFORM. But I think you could either create an alternate method and inject that at around the PERFORM-PLAN level, or use a SESSION object as an additional specializer argument to open up other possible PERFORM implementations.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I was thinking you would precompute and cache the plan, and then invoke<br>
PERFORM-PLAN on that.<br></blockquote><div><br></div><div>Or maybe another method altogether to take the place of perform, like SIMULATE-PLAN or RECORD-PLAN, or ASSEMBLE-PLAN. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

That assumes that the call to TRAVERSE is actually expensive enough that<br>
this is worth the trouble.  I think you could confirm or disconfirm that<br>
claim quickly with some timing experiments.<br></blockquote><div><br></div><div>Yes, I think I did that -- but with a different concern. When I was concerned about ASDF mucking around inspecting files when I was doing a REQUIRE, I added a feature to cause a fully loaded module to be flagged as loaded via mark-operation-done, so that do-traverse would stop traversing at such a module. It was about 2.5 seconds to traverse normally, and about 0.5 with this optimization for a require after the first one (of course for a deployed system not development.)</div>
<div><br></div><div>In any case load time is not my only interest.  It is also a desire to be able to use ASDF more effectively for more use cases. </div><div><br></div><div>Erik.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

cheers,<br>
r<br>
</blockquote></div><br></div>