[Openmcl-devel] Maybe a better way to delivery apps

Dave Cooper david.cooper at genworks.com
Sun Jun 9 17:28:16 UTC 2013


Hi Mike et al,

The current ASDF provides 'asdf:monolithic-fasl-op.

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.

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.

I wrote up a little blog posting a while back with an example use of ASDF's
monolithic-fasl-op:

  http://gendl.blogspot.com

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.


Regards,

 Dave




On Sun, Jun 9, 2013 at 11:09 AM, Ron Garret <ron at flownet.com> wrote:

> 4.10. Concatenating FASL Files
>
> Multiple fasl files can be concatenated into a single file.
>
> [Function]
>
> fasl-concatenate out-file fasl-files &key (:if-exists :error)
> Concatenate several fasl files, producing a single output file.
> Arguments and Values:
> out-file--- Name of the file in which to store the concatenation.
>
> fasl-files--- List of names of fasl files to concatenate.
>
> :if-exists--- As for OPEN, defaults to :error
>
> Description:
> 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.)
>
> 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.
>
> On Jun 9, 2013, at 6:57 AM, Mike Manilone wrote:
>
> > Hi all,
> >
> > I think that delivering apps may be easier if CCL provides something
> > similar to JAR (LAR)... A compressed file is much smaller than a core
> > image or a huge executable. Maybe a bundle of FASLs? The compilation may
> > depend on ASDF.
> >
> > Any comments?
> >
> > --
> > ===========道可道也===========
> > | Mike Manilone (ekd123) |
> > | http://www.ekd123.org  |
> > ===========非恆道也===========
> >
> >
> >
> > _______________________________________________
> > Openmcl-devel mailing list
> > Openmcl-devel at clozure.com
> > http://clozure.com/mailman/listinfo/openmcl-devel
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>



-- 
My Best,

Dave Cooper, Genworks Support
david.cooper at genworks.com, dave.genworks.com(skype)
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.clozure.com/pipermail/openmcl-devel/attachments/20130609/5ec908e3/attachment.html>


More information about the Openmcl-devel mailing list