I don't know much about fasl files. Are they only for a Lisp
development environment, or will they run in an end-user environment
for an application developed in Lisp and delivered to end-users
without Lisp?
I know I can get a good version of Lispworks for $799 with a very
liberal delivery license. But does it include everything needed for
delivering fasl files? Can I send some kind of runtime package to
each user once, then send fasl files forever to update it? All
covered by the same developer's license with no need for any runtime
licenses?
··········@mailandnews.com (Software Scavenger) writes:
> I don't know much about fasl files. Are they only for a Lisp
> development environment, or will they run in an end-user environment
> for an application developed in Lisp and delivered to end-users
> without Lisp?
FASL files (short for FASt Load, btw) are the output of Lisp
compilers, and may be either byte code or native code (depending on
the Lisp system). FASLs are *not* executable programs in the sense
that you're probably thinking of, ie they cannot be simply *executed*
from a command prompt -- they require that the Lisp system be loaded.
Executables are typically made by dumping an entire Lisp image,
including the Lisp system *and* the program.
Lisp is a bit 'different' since programs are really just extensions of
the system. Most of a Lisp system is implemented in the same way, as
an extension of the core (or kernel). This is analogous to C programs
depending on a C library. Unlike C whose standard was made with the
intent on designing a language that could produce programs independent
of an operating environment[footnote], it's difficult to write
programs that do not depend on the Lisp system (not to say it can't be
done, though). It is in fact difficult to write (useful) C programs
that do not depend on the C library in many cases, anyway.
Operating systems do not typically support Lisp in the same way they
support C, in the form of dynamically linkable libraries, and this is
mostly because operating systems nowadays are designed with the
calling conventions of C in mind, not those of Lisp. It is perfectly
conceivable that one could develop a system that uses dynamic
libraries (shared object libs, DLLs, etc) instead of dumping a Lisp
runtime image, but to my knowledge such a thing has not been done to
the same extent that it has been done with C/C++. A liblisp.so
wouldn't be such a bad thing, though...
> I know I can get a good version of Lispworks for $799 with a very
> liberal delivery license. But does it include everything needed for
> delivering fasl files?
If it has a compiler, it can make FASLs, or something like them (the
name might be different for LW, don't know).
> Can I send some kind of runtime package to each user once, then send
> fasl files forever to update it?
Yes. Typically a Lisp vendor will support such a licensing scheme.
This would in essence be the distribution of a reduced Lisp image (or
core, or whatever they want to call it) with support only for the Lisp
that you use in your program, or only a certain reduced amount of
support (such as no debugger). You dump an image based on this one
including the program that you want included and some code to start
the program when the Lisp is started.
> All covered by the same developer's license with no need for any
> runtime licenses?
That differs from company to company. I suggest that you call around,
or more simply read their various web sites for such licensing
information.
Footnote: At the C standards meetings it was said "What if C is used
to program an elevator controller? You don't need printf() on an
elevator controller, do you? So it shouldn't be part of the language,
it should be part of a library." And now printf() and all other forms
of user i/o are now part of the C library, not part of the language.
So nearly *every* program has to #include <stdio.h>.
To a certain extent I appreciate this sentiment because it allows for
developing programs that can run entirely without an operating system,
under certain circumstances. But it *does* make things a PITA for
most other tasks, because you're never sure if your problem is with
your use of the language, if the C library is incompliant with the
standards, or if you're just confused by all the pointers.
'james
--
James A. Crippen <·····@unlambda.com> ,-./-. Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us | |/ | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System,
Y(F) = F(Y(F)) \_,-_/ Milky Way.
>>>>> On 2 Oct 2001 16:34:23 -0700, Software Scavenger ("Software") writes:
Software> I don't know much about fasl files. Are they only for a Lisp
Software> development environment, or will they run in an end-user environment
Software> for an application developed in Lisp and delivered to end-users
Software> without Lisp?
Although they are akin to ".o" files in C. FASL files do not require
a development environment. FASL files are the binary files containing
the compiled Lisp code; they are used (dynamically link-loaded) by a
Lisp program, simply by calling LOAD. FASL files are a proprietary
format, not a standard operating-system shared library format.
They do require the Lisp runtime system in order to be useful.
Software> I know I can get a good version of Lispworks for $799 with a very
Software> liberal delivery license. But does it include everything needed for
Software> delivering fasl files? Can I send some kind of runtime package to
Software> each user once, then send fasl files forever to update it? All
Software> covered by the same developer's license with no need for any runtime
Software> licenses?
FASL files can be delivered with any Lisp program: they are the
output produced by the COMPILE-FILE function.
You will need a Lisp runtime in order to use the FASL files,
and that runtime will be part of an executable file of some sort.
Lispworks will create a executable (ie. an ".EXE" file).
First you get yourself into the Lisp development environment
and write your program. You compile each of your source files,
resulting in corresponding FASL files. You also write a little
bootstrap Lisp program that basically just calls LOAD on all
the rest of the files. To deliver your application, you start
up a clean Lisp image, and LOAD your application bootstrap,
which in turn LOADs all the rest of the files FASL files.
Then you call the Lisp functions (or maybe the bootstrap
program includes these calls, at the end) that performs a
special type of agressive garbage collection,
and finally writes out the single binary executable file.
I think all the executable delivery mechanisms from the vendors
work pretty much like that, although the LOAD function and the
existance of FASL files (different formats for different Lisps)
are the only standard parts.
Lispworks (and I think Franz) do not have a seperate Lisp
runtime DLL. There isn't a core runtime DLL that you can
give to your customer. But you can give them an entire
application, and when they run it, it can LOAD all the
FASL files that it wants.
Some Lisp systems do have a feature that allows you to produce
a DLL instead of an EXE, but the DLL is an entire application.
The executable file (DLL or EXE) is your application, and
includes all of the Lisp runtime.
Once you have delivered an executable program (eg. EXE or DLL)
to your customer, your application can call LOAD whenever it wants.
You can therefore distribute patches as FASL files.
Christopher Stacy <······@spacy.Boston.MA.US> writes:
> Software> I know I can get a good version of Lispworks for $799
> Software> with a very liberal delivery license. But does it
> Software> include everything needed for delivering fasl files? Can
> Software> I send some kind of runtime package to each user once,
> Software> then send fasl files forever to update it? All covered
> Software> by the same developer's license with no need for any
> Software> runtime licenses?
>
> FASL files can be delivered with any Lisp program: they are the
> output produced by the COMPILE-FILE function.
>
> You will need a Lisp runtime in order to use the FASL files,
> and that runtime will be part of an executable file of some sort.
> Lispworks will create a executable (ie. an ".EXE" file).
Actually, although there is not a legal issue, there is a technical
issue. Depending on how mcuh "tree shaking" you do in trying to
deliver your application, you can shake out code that would have been
needed to load the relevant code correctly. If you do a vanilla image
save with no tree shaking (the default), it should usually work. But
if you try to squeeze the image down to smallest size, that will be
done on the basis of what's loaded at the time you save the image, and
things you don't point to will be assumed to be collectable. So be
careful as you decide how small your image must be. I usually go for
larger image size and patchability myself, but it depends on your
needs. I have seen people obsess over getting the smallest possible
image, only to destroy patchability... Even in WebMaker (a lisp-based
product Harlequin used to sell when I worked there), we ran into this. ;-)
Kent M Pitman <······@world.std.com> writes:
> Actually, although there is not a legal issue, there is a technical
> issue. Depending on how much "tree shaking" you do in trying to
> deliver your application, you can shake out code that would have
> been needed to load the relevant code correctly. If you do a
> vanilla image save with no tree shaking (the default), it should
> usually work. But if you try to squeeze the image down to smallest
> size, that will be done on the basis of what's loaded at the time
> you save the image, and things you don't point to will be assumed to
> be collectable. So be careful as you decide how small your image
> must be. I usually go for larger image size and patchability
> myself, but it depends on your needs. I have seen people obsess
> over getting the smallest possible image, only to destroy
> patchability... Even in WebMaker (a lisp-based product Harlequin
> used to sell when I worked there), we ran into this. ;-)
Would it then work to maintain gratuitous pointers to the stuff needed
to load?
I'm wondering why the tree-shaking code (which is of course
implementation dependent) doesn't provide some sort of flag telling it
to keep only enough to run everything called by a specific function,
recursively. Then you have one entry point for the program, and any
functions that it calls or functions those functions call (etc) will
be saved. Everything else will be flushed. Of course it would be
necessary to keep enough code to get to that function as well, but
that ought (I think) to be unchanging and thus plannable by the
implementors.
This of course requires having one particular entry point or 'main'
function using C's parlance. Which is not always ideal in some Lisp
situations, but you get the idea.
I get the feeling someone else has thought of this before -- it seems
too obvious to me. Is there some specific reason why this is too
hard? Implementors? Any thoughts?
'james
--
James A. Crippen <·····@unlambda.com> ,-./-. Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us | |/ | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System,
Y(F) = F(Y(F)) \_,-_/ Milky Way.
From: Wade Humeniuk
Subject: Re: Tree shaking (was Re: Are fasl files feasible for delivery?)
Date:
Message-ID: <9pf67d$p20$1@news3.cadvision.com>
>
> I get the feeling someone else has thought of this before -- it seems
> too obvious to me. Is there some specific reason why this is too
> hard? Implementors? Any thoughts?
Of course its been thought about, the LispWorks delivery functions has all
that. (Everything has :-)). It has a full tree shaker.
http://www.xanalys.com/software_tools/reference/lww41/deluser/D_1.HTM
Look under Keywords to the delivery system. You can optionally keep any
function, or load, or eval...
Wade
From: Tim Bradshaw
Subject: Re: Tree shaking (was Re: Are fasl files feasible for delivery?)
Date:
Message-ID: <ey3pu85ozdu.fsf@cley.com>
* James A Crippen wrote:
> I get the feeling someone else has thought of this before -- it seems
> too obvious to me. Is there some specific reason why this is too
> hard? Implementors? Any thoughts?
I think the answer is LOAD or EVAL or (funcall (symbol-function ...))
or one of the other inconvenient things in Lisp that suddenly mean
everything is reachable. If you remove all that stuff then you can
tree-shake very efficiently, but then, well, you've removed that
stuff. In the specific case at hand here, if you want to have LOAD
work for patches or whatever, then you really need to leave most
things in (maybe you can excise the compiler, but only maybe).
It's interesting that every Lisp application I've worked on in recent
times has (a) been rather small in terms of the physical resources of
the machine it ran on, such as memory, and (b) relied crucially on the
ability to load unconstrained code and/or interact with a Lisp
listener at some point. I don't think tree-shaking is very
interesting, at least for a lot of applications, and the potential
cost of it if you screw up being able to load patches or whatever can
be great - the first time you ship the system it's only 4Mb, but
because you can't patch it every tiny change requires another 4Mb...
In fact the two largest problems (apart from the usual one of not
being a very good programmer...) I've had have been persuading people
that, in fact, the application was small (ps and top are your
friends!) and then worrying that when the data got big the Lisp system
wouldn't be *able* to address all the memory we could put in the
machine...
--tim
From: Will Deakin
Subject: Re: Tree shaking (was Re: Are fasl files feasible for delivery?)
Date:
Message-ID: <3BBB2516.3020804@hotmail.com>
Tim Bradshaw wrote:
> and then worrying that when the data got big the Lisp system
> wouldn't be *able* to address all the memory we could put in the
> machine...
What you need is a 64bit Lisp...
;)w
·····@unlambda.com (James A. Crippen) writes:
> I'm wondering why the tree-shaking code (which is of course
> implementation dependent) doesn't provide some sort of flag telling it
> to keep only enough to run everything called by a specific function,
> recursively. Then you have one entry point for the program, and any
> functions that it calls or functions those functions call (etc) will
> be saved. Everything else will be flushed. Of course it would be
> necessary to keep enough code to get to that function as well, but
> that ought (I think) to be unchanging and thus plannable by the
> implementors.
>
> This of course requires having one particular entry point or 'main'
> function using C's parlance. Which is not always ideal in some Lisp
> situations, but you get the idea.
The "obvious" extension would be for function TREE-SHAKE to accept a
list of values, perhaps thus:
(tree-shake '(#'main-application-function
#'some-other-function-I-want
some-other-named-object))
So if you want to retain EVAL, you'd throw it in thus:
(tree-shake '(#'my-app-code #'EVAL))
--
(concatenate 'string "aa454" ·@freenet.carleton.ca")
http://www.ntlug.org/~cbbrowne/sgml.html
Don't panic.
-- The Hitchhiker's Guide to the Galaxy
From: Tim Bradshaw
Subject: Re: Tree shaking (was Re: Are fasl files feasible for delivery?)
Date:
Message-ID: <ey3g090q169.fsf@cley.com>
* cbbrowne wrote:
> The "obvious" extension would be for function TREE-SHAKE to accept a
> list of values, perhaps thus:
> (tree-shake '(#'main-application-function
> #'some-other-function-I-want
> some-other-named-object))
I think this is exactly how they work (except that there are a lot of
other issues because reachability is not as simple as this).
> So if you want to retain EVAL, you'd throw it in thus:
> (tree-shake '(#'my-app-code #'EVAL))
Can such a call be anything other than a no-op?
--tim
From: Pekka P. Pirinen
Subject: Re: Tree shaking (was Re: Are fasl files feasible for delivery?)
Date:
Message-ID: <uwv2cpnh7.fsf@globalgraphics.com>
·····@unlambda.com (James A. Crippen) writes:
> Kent M Pitman <······@world.std.com> writes:
> > Depending on how much "tree shaking" you do in trying to
> > deliver your application, you can shake out code that would have
> > been needed to load the relevant code correctly. [...]
>
> Would it then work to maintain gratuitous pointers to the stuff needed
> to load?
If it's system code that's missing, no, because you don't know what it
is. If it's only your own, sure.
> I'm wondering why the tree-shaking code (which is of course
> implementation dependent) doesn't provide some sort of flag telling it
> to keep only enough to run everything called by a specific function,
> recursively.
That's pretty much what tree shakers do. The problem is that CL
systems are densely interconnected, so just doing that in an
application of any size will not shake much anything. Even if you
don't use EVAL and COMPILE, functions like PRINT, FORMAT, READ, and
ERROR connect to most of rest of the system.
You could do sophisticated analysis on the arguments, to prove that
you don't need all of it (say, that (PRINT "FOO") does not need the
floating-point system), but this quickly gets hairy.
So what the implementations do in practice is allow the programmer to
tell the tree shaker that they won't need particular features, even
though there seems to be a path to them: drop floating-point, drop the
debugger, drop tracing support, drop ability to redefine classes, etc.
--
Pekka P. Pirinen
"My definition of a free society is a society where it is safe
to be unpopular."
- Adlai Stevenson
From: Wade Humeniuk
Subject: Re: Tree shaking (was Re: Are fasl files feasible for delivery?)
Date:
Message-ID: <9pfohp$bpi$1@news3.cadvision.com>
> That's pretty much what tree shakers do. The problem is that CL
> systems are densely interconnected, so just doing that in an
> application of any size will not shake much anything. Even if you
> don't use EVAL and COMPILE, functions like PRINT, FORMAT, READ, and
> ERROR connect to most of rest of the system.
That is not true, I still have all of print, format, read and error and my
image still shakes from 25MB down to 4MB. No eval or compiler, (still CLOS,
CAPI). LWW delivery level 5.
Wade
Kent M Pitman <······@world.std.com> writes:
> Depending on how mcuh "tree shaking" you do in trying to
> deliver your application, you can shake out code that would have been
> needed to load the relevant code correctly.
> I have seen people obsess over getting the smallest possible
> image, only to destroy patchability... Even in WebMaker (a lisp-based
> product Harlequin used to sell when I worked there), we ran into this. ;-)
We once released a web server-like application under Franz Allegro CL,
and used their facilities to build a runtime application without a compiler
(which made it smaller).
A long time later we tried to patch some production servers with a little
bit of new code. Even though it worked in development, the patch failed in
production. It took us a little while to discover that the problem was
the LOOP macro wasn't defined the the smaller runtime image. (We were patching
with source code.)
Not a surprise, in hindsight. But the developers were tricked because the
original source code had LOOP all over the place, so they expected it to be
available in the production environment. Easy to fix: either patch with
compiled code instead of source code, or else just MACROEXPAND the LOOP
patch first in development, and send out only the lower-level expanded
source code into production.
Still, it caused a bit of confusion for awhile...
-- Don
_______________________________________________________________________________
Don Geddis www.overture.com ······@overture.com
Vice President of Research and Development Phone 650-403-2220
Overture, 1820 Gateway Drive, Suite 360, San Mateo, CA 94404 Fax 650-403-2201