<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">If you've had a customer or client ask you to reduce the disk footprint of a binary in the last twenty years please raise your hand.<div><br></div><div>We ran into this a lot in the 1980s. It took quite a bit of work to get the original CCL (Coral Common Lisp) to fit onto a floppy disk. Since the deprecation of floppies, though, I can't remember it ever actually coming up as a practical concern.</div><div><br></div><div>Concatenating fasls, on the other hand, does make things easier to manage while having the beneficial side effect of speeding up load time.</div><div><br></div><div><br></div><div><div><div>On Jun 9, 2013, at 1:28 PM, Dave Cooper <<a href="mailto:david.cooper@genworks.com">david.cooper@genworks.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div style=""><br></div><div style="">Hi Mike et al,</div><div style=""><br></div>The current ASDF provides 'asdf:monolithic-fasl-op.<div><br></div><div>I'm not sure if ASDF has or contemplates any automatic facility for compressing/uncompressing fasls, but that might be something nice to have, to be able to deliver a compressed monofasl and have the receiving end be able to "play" it directly.</div>
<div><br></div><div>This all of course assumes that the receiving end already has compatible CCL version installed (that's somewhat analogous assumption with JAR files). Where the analogy falls apart, at least for CCL, is that any delivered fasls will still be platform-specific (e.g. Mac, Windows, Linux) unlike JAR files which are supposed to run unmodified on any underlying OS platform.</div>
<div><br></div><div><div style="">I wrote up a little blog posting a while back with an example use of ASDF's monolithic-fasl-op:</div><div style=""><br></div><div style=""> <a href="http://gendl.blogspot.com/">http://gendl.blogspot.com</a></div>
<div style=""><br></div><div style="">This is in need of some followup, but it introduces the basics and also mentions the possibility of using the monofasl as a first step in preparing a dumped executable image. </div><div style="">
<br></div><div style=""><br></div><div style="">Regards,</div><div style=""><br></div><div style=""> Dave</div><div style=""><br></div></div><div style=""><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 9, 2013 at 11:09 AM, Ron Garret <span dir="ltr"><<a href="mailto:ron@flownet.com" target="_blank">ron@flownet.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">4.10. Concatenating FASL Files<br>
<br>
Multiple fasl files can be concatenated into a single file.<br>
<br>
[Function]<br>
<br>
fasl-concatenate out-file fasl-files &key (:if-exists :error)<br>
Concatenate several fasl files, producing a single output file.<br>
Arguments and Values:<br>
out-file--- Name of the file in which to store the concatenation.<br>
<br>
fasl-files--- List of names of fasl files to concatenate.<br>
<br>
:if-exists--- As for OPEN, defaults to :error<br>
<br>
Description:<br>
Creates a fasl file which, when loaded, will have the same effect as loading the individual input fasl files in the specified order. The single file might be easier to distribute or install, and loading it may be at least a little faster than loading the individual files (since it avoids the overhead of opening and closing each file in succession.)<br>
<br>
The PATHNAME-TYPE of the output file and of each input file defaults to the current platform's fasl file type (.dx64fsl or whatever.) If any of the input files has a different type/extension an error will be signaled, but it doesn't otherwise try too hard to verify that the input files are real fasl files for the current platform.<br>
<div class="HOEnZb"><div class="h5"><br>
On Jun 9, 2013, at 6:57 AM, Mike Manilone wrote:<br>
<br>
> Hi all,<br>
><br>
> I think that delivering apps may be easier if CCL provides something<br>
> similar to JAR (LAR)... A compressed file is much smaller than a core<br>
> image or a huge executable. Maybe a bundle of FASLs? The compilation may<br>
> depend on ASDF.<br>
><br>
> Any comments?<br>
><br>
> --<br>
> ===========道可道也===========<br>
> | Mike Manilone (ekd123) |<br>
> | <a href="http://www.ekd123.org/" target="_blank">http://www.ekd123.org</a> |<br>
> ===========非恆道也===========<br>
><br>
><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> Openmcl-devel mailing list<br>
> <a href="mailto:Openmcl-devel@clozure.com">Openmcl-devel@clozure.com</a><br>
> <a href="http://clozure.com/mailman/listinfo/openmcl-devel" target="_blank">http://clozure.com/mailman/listinfo/openmcl-devel</a><br>
<br>
_______________________________________________<br>
Openmcl-devel mailing list<br>
<a href="mailto:Openmcl-devel@clozure.com">Openmcl-devel@clozure.com</a><br>
<a href="http://clozure.com/mailman/listinfo/openmcl-devel" target="_blank">http://clozure.com/mailman/listinfo/openmcl-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>My Best,<br><br>Dave Cooper, Genworks Support<br><a href="mailto:david.cooper@genworks.com">david.cooper@genworks.com</a>, <a href="http://dave.genworks.com/">dave.genworks.com</a>(skype)<br>
USA: 248-327-3253(o), 1-248-330-2979(mobile)<br>UK: 0191 645 1699<br>
</div>
_______________________________________________<br>Openmcl-devel mailing list<br><a href="mailto:Openmcl-devel@clozure.com">Openmcl-devel@clozure.com</a><br>http://clozure.com/mailman/listinfo/openmcl-devel<br></blockquote></div><br></div></body></html>