Hello,
As development and deployment of Lisp software are quite different
to what can be found in C, Java, etc., I was wondering: how do you
usually work with Lisp images?
Basically, how do you use them during development, running your
own code and deployment?
Implementations come with default images.
For development, do you use that default image and load all your
own code (macros, utilities, etc.) or do you create a new image from
it with the code?
If you are running an application, do you make a new image for
this application or do you run it with your development environment
(different instances)? Or do you it from your current listener?
When deploying, do you just use your development image or do you
somewhat do it from scratch with the default image?
If you create many images, how do you remember what you put in
them (besides writing it down somewhere)? Setting *features* or the
like? For example, if I'd like to have something like ifstar.lisp when
developing, is it better to have it loaded during startup or already
in the image?
Georges.
--
Georges Ko (Taipei, Taiwan) 2001-03-25 ···@gko.net / ICQ: 8719684
Jour 7 de la semaine 12 de l'an 2001
On most Lisp systems, here is how it works.
The default image includes the IDE tools: as the compiler itself,
the editor, debugger, etc. It also contains many of the libraries
that you might want: networking, foreign-function interfaces,
window system, CLIM, etc.
For development, you load your code into a base image (sometimes
called a "world"). This allows the development tools to be
tightly integrated with your application for development
and debugging purposes. There are two ways for you to load
your application into the image, and when developing, you
typically do both.
First, you can enter code into the image by typing it at the
"listener" window. The expression is immediately compiled and
linked into the image's address space and executed. You can
do this as many times as you want. The expression could be
a Lisp definition (such as a DEFUN), or it could be another
function call (perhaps to interactively test a program definition
you previously entered). You can also go into the IDE editor, type
source code there and use a command to execute (eg. compile+link) it.
You can work on just one function, or on a region of the code,
or on an entire file/editor-buffer of code.
When you are done debugging (for now) a file of source code, whether
or not it is entirely complete, you have another option. You can
compile the source file into a FASL file. FASL files are proprietary
format binary files that can be loaded and dynamically linked by Lisp.
(FASL is historical and stands for "FASt Loading").
At this point, you could start a fresh base image, load in your FASL
files, and execute expressions that run your application. You can also
read the corresponding source code into the editor and make incremental
changes and re-definitions. (You could make those changes permanent by
saving the source file and also recompiling the file into another FASL.
You can also continue to type new expressions at the listener, create
new source file/buffers, etc. You use all these techniques together
in concert, in whatever way is convenient.
When you're all done with that, you have a bunch of FASL files (and
corresponding source files) that constitute your application.
Application deployment is usually done one of two ways.
You could write some kind of script (eg. a Unix or DOS shell script)
that will simply start the base Lisp image and execute an initial
Lisp expression. That expression will be a call to LOAD all the
necessary FASL files that make up the application, and start the
application.
One downside with that simple technique is that you have to provide
each user with the executable lisp image (which may include the compiler,
editor, and everything). That is, the user needs access to a base image
into which the FASL files will be loaded. This is the same way that Perl
applications are delivered, except that Perl is an interpreter and loads
source files, rather than loading compiled (FASL) files.
Alternatively, many systems have a delivery feature called "tree shaking".
You start a fresh Lisp image, load your application FASLs into it,
and invoke the tree-shaker delivery tool. It looks at your application,
and maybe at some hints you provide, and tries to eliminate everything
in the Lisp image except the code and data that is actually going to
be used. This is a special kind of garbage collection. It therefore
eliminates the IDE tools (editor, compiler, debugger), any libraries
(window system interface, networking), and even Lisp features (such as
floating point numbers) that you are not using. Finally, the resulting
Lisp image is dumped out into an operating system-dependant executable
or dynamic-library format, such as "so" or "EXE" or "DLL".
Georges> If you create many images, how do you remember what you put in
Georges> them (besides writing it down somewhere)? Setting *features* or the
Georges> like? For example, if I'd like to have something like ifstar.lisp when
Georges> developing, is it better to have it loaded during startup or already
Georges> in the image?
I usually only have two or three images: the base image, the base image plus
all the libraries (CLIM, networking, SQL, etc.) pre-loaded, and maybe an
image that contains all that junk plus the application-specific libraries
that I have written. I know which ones are which because each image has
a different file name, and I launch whichever one is appropriate for the
development project at hand.
Another thing you might not know about is DEFSYSTEM. This is a Lisp
tool that allows you to define an application in terms of source files,
modules, and dependancies. It is a higher-level version of the *FEATURES*
and REQUIRE/PROVIDE ideas, and may or may not be implemented using them.
You load up DEFSYSTEM (if it is not already included in the base image),
then you load (execute) a file that contains the definition of your application,
then you execute an expression something like (LOAD-SYSTEM "my-system")
or (COMPILE-SYSTEM "my-system"). This takes care of compiling all the
necessary source files and loading the resulting FASLs.
Most Lisp systems support "init files, which are files of Lisp code
that are automatically loaded when the base image starts. There might
be a particular file name based on your home directory, and maybe also
a site init file. Init files include snippets of code that always you
want to execute. These might be your own customizations or extensions
to the development environment, calls to LOAD additional files, etc.
Chris
Georges Ko <···@gko.net> writes:
> Hello,
>
> As development and deployment of Lisp software are quite different
> to what can be found in C, Java, etc., I was wondering: how do you
> usually work with Lisp images?
Where I am now, we generally start with a base image from the vendor
and load our fasl files into it when we start developing. This takes
little time, even if we recompile everything from scratch.
For distribution, however, we build an image that contains only our
stuff and the appropriate support code.
It would make sense to create a development image with a certain
amount of our code pre-loaded, but for a number of reasons, both
technical and political, we don't do that. Since the code is
currently small enough to compile and load from scratch without much
of a wait, it isn't a pressing issue.
> If you create many images, how do you remember what you put in
> them (besides writing it down somewhere)? Setting *features* or the
> like? For example, if I'd like to have something like ifstar.lisp when
> developing, is it better to have it loaded during startup or already
> in the image?
One advantage of loading and developing from a base image is that you
*know* you haven't forgotten what goes into the product.
Each developer here can certainly load any extra packages he wants to
help development, but it is expected that he wouldn't write production
code that depends on optional packages (it is discovered fairly early
on anyway because we all try to keep up to date with the development
tip.)
It is useful to check every now and then that you can build a
deliverable product directly from a base image and the sources. In
our case, we do this frequently enough that it is not an issue.
If you do create a special `development' image, it would be useful to
check every now and then that you can still create the product from
scratch.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----