How you guys configure your lisp system for maximum productivity? Do
you have some directory structure for libraries like Bill Clementson's
[1], or you install libraries system-wide using the native package
management system like portage or apt [2]? while developing, do you
load libraries on demand (for instance, if your project need lml2 you
just load it with adsf in the REPL), you load all libraries you
usually use at lisp start-up (and wait half-hour ;-) , or you generate
a custom image and use that?
I understand that each of the above approaches are possible, but I
want to know how the big guys do it ;-) also, if you have other
approaches, please, let us know.
Footnotes:
[1] http://bc.tech.coop/blog/051004.html
[2] and what if your system is not debian of gentoo?
Pedro Kröger wrote:
> How you guys configure your lisp system for maximum productivity? Do
> you have some directory structure for libraries like Bill Clementson's
> [1], or you install libraries system-wide using the native package
> management system like portage or apt [2]? while developing, do you
> load libraries on demand (for instance, if your project need lml2 you
> just load it with adsf in the REPL), you load all libraries you
> usually use at lisp start-up (and wait half-hour ;-) , or you generate
> a custom image and use that?
>
> I understand that each of the above approaches are possible, but I
> want to know how the big guys do it ;-) also, if you have other
> approaches, please, let us know.
>
> Footnotes:
> [1] http://bc.tech.coop/blog/051004.html
> [2] and what if your system is not debian of gentoo?
I'd be very interested in this question too. I have crude ways of
handling this but I'm not satisfied with them.
Pedro Kröger schrieb:
> How you guys configure your lisp system for maximum productivity? Do
> you have some directory structure for libraries like Bill Clementson's
> [1], or you install libraries system-wide using the native package
> management system like portage or apt [2]? while developing, do you
> load libraries on demand (for instance, if your project need lml2 you
> just load it with adsf in the REPL), you load all libraries you
> usually use at lisp start-up (and wait half-hour ;-) , or you generate
> a custom image and use that?
Often I have a large custom load file which loads/compiles and
configures the software I want to use.
For LispWorks I'd use scripts which load things and dump an image.
That image then is the new image for software development.
>From time to time I dump new images with updated software.
For some stuff it also loads patches after the start.
Unfortunately LispWorks does not allow you to dump
an image that has multiprocessing running. That means
that you can't have the IDE (or any other piece of
software that requires processes) running and dump an image.
That limits the usefulness of the image dumping mechanism
a bit.
Some other Lisps allow to dump running images and have hooks
to restore application state (like MCL) on startup. This is
especially important if you want to dump a running Lisp
that has created lots of objects with pointers to
structures on the C-side. In MCL you can easily
use structures that are not allocated on the Lisp
heap, but has to be handled manually with the usual
OS mechanisms.
There I start my IDE load some stuff via a software, use the software
(to fill caches)
and then dump an image. Next time you start that image,
for example, MCL comes back with the same new menus, new application
class, etc. MCL also allows you to dump another image
from the previous one. Usually I would have much
of the application code that I work on already in the Lisp
image and only add incrementally into a running
application using the embedded Lisp development environment
(inspector, editor, listener, debugger, ...).
On the Lisp Machine one tries not to start often and keep
it running. Dumping and loading takes a lot of time.
So you load stuff and dump an image then. From
this image one can dump incremental images. So
sometimes you have a bunch of preloaded stuff
in various incremental images, which you can choose
to boot from. In networked environments one used
to dump images that could be used by other
people (even netbooted).
>
> I understand that each of the above approaches are possible, but I
> want to know how the big guys do it ;-) also, if you have other
> approaches, please, let us know.
>
> Footnotes:
> [1] http://bc.tech.coop/blog/051004.html
> [2] and what if your system is not debian of gentoo?
·······@corporate-world.lisp.de" <······@corporate-world.lisp.de> writes:
[about LispMs]
> to boot from. In networked environments one used
> to dump images that could be used by other
> people (even netbooted).
Was this feature also used for application delivery?
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
Paolo Amoroso wrote:
> ·······@corporate-world.lisp.de" <······@corporate-world.lisp.de> writes:
>
> [about LispMs]
> > to boot from. In networked environments one used
> > to dump images that could be used by other
> > people (even netbooted).
>
> Was this feature also used for application delivery?
Depends what you understand of application delivery.
But generally, no.
In the early times, applications came on tapes. Also then on floppy
disks
or cdroms. Applications on those tapes (floppy, ...) were called
'distributions'.
There were tools to create and install distributions. Basically
distributions
were a bunch of systems (system descriptions, source, compile code,
data,
patches, documentation...). If you restore a distribution, the files
will be installed in
the file system (possibly directed by logical pathnames to servers).
Later you would just load the system(s). There was a typical directory
where logical pathnames and systems were registered.
It might be possible that in some situations full preconfigured worlds
were
delivered to the customer. But 'applications' usually were delivered
as distributions (on tapes, floppy disks or CDROMs). Sometimes
I think other optical drives could be used. In the old times
every site used to have atleast one tape drive (which was usable
from other machines, too, IIRC).
Sometimes 'applications' were whole configured systems (hardware and
software).
Special machines were considered to be application machines (typically
they would not be running the development tools). Also there was a
'tool'
called 'Symbolics Firewall' which was loaded into the world to shield
the end user from
the Lisp internals (listeners, debuggers, ...).
The site administrator could also prepare netbootable images with
the necessary software and configuration preloaded and local machines
would boot from that. But that would be done at the client site
usually - AFAIK.
>
>
> Paolo
> --
> Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
> The Common Lisp Directory: http://www.cl-user.net
"Pedro Kr�ger" <············@gmail.com> writes:
> How you guys configure your lisp system for maximum productivity? Do
> you have some directory structure for libraries like Bill Clementson's
> [1], or you install libraries system-wide using the native package
> management system like portage or apt [2]? while developing, do you
> load libraries on demand (for instance, if your project need lml2 you
> just load it with adsf in the REPL), you load all libraries you
> usually use at lisp start-up (and wait half-hour ;-) , or you generate
> a custom image and use that?
For simple libraries like trivial-http, trivial-sockets, or
split-sequence (i.e. libraries that I'm not likely to need to modify
or upgrade or ever care about at all once they're installed), I just
use asdf-install and tell it to put them in ~/.asdf-install-dir.
For larger libraries, I unpack them to ~/Code/Lisp/systems, which is
supposed to keep the source for all the public libraries I use.
Libraries and applications that I've written go into ~/Projects, each
in their own directory.
I use Gary King's asdf-binary-locations to keep fasl files separate
from the Lisp source. This is nice, since I can copy the ~/Projects
and ~/Lisp/systems folder from machine to machine or even put them
under version control. And if a new version of an implementation
comes out that breaks binary compatibility of old FASL's, all I have
to do is "rm -rf ~/.fasls/impl-name".
I have a ~/.systems directory that contains symbolic links to all the
.asd files I might need access to it. I keep it updated with a simple
script called refresh_asds.sh:
---------
#!/bin/sh
cd ~/.systems
rm -f *.asd
ln -sf `find ~/.asdf-install-dir -name "*.asd"` .
ln -sf `find ~/Code/Lisp/systems -name "*.asd"` .
ln -sf `find ~/Projects -name "*.asd"` .
ln -sf ~/Source/slime/swank.asd .
---------
Since binaries are kept separate from fasls, I can use .systems,
~/Code/Lisp/systems and ~/Projects in any Lisp implementation.
.lispworks, .sbclrc, .clisprc, and .cmuclrc all have the following
snippet of code:
---------
(load "~/Code/Lisp/asdf")
(push (merge-pathnames #P".systems/" (user-homedir-pathname))
asdf:*central-registry*)
(asdf:oos 'asdf:load-op :asdf-binary-locations)
(setf asdf:*centralize-lisp-binaries* t)
---------
If I just want to try something out, I load the system from the REPL
using a simple convenience wrapper around ASDF. This way, I can type
(asdf :trivial-http) instead of OOS'ing around. In most cases,
though, I want to load the libary to use it in some other project, so
I end up loading it indirectly by creating a .asd file for my project,
putting the library in :depends-on, and then using ASDF to load my
project.
HTH,
Bill