This is the best thing I've read on the Pro list so far, I think. I'm a filer, but as I deploy multiple cloud instances, I'm starting to think about the advantages of imaging. However, I have little experience with it. Especially on Debian. Anybody have good resources on imaging that are not obtainable through a superficial web search? On Thu, Jan 20, 2011 at 7:45 AM, Ala'a Mohammad <amalawi@gmail.com> wrote:

Hi,

I'm continually learning Common-lisp and trying to find the best style that suites me better. I've tried 'an imager' style (cooking a an image with all required libraries loaded when required), and 'a filer' style (loading files or systems each time I fire-up a CL implementation). I'm interested to hear what others use CL. How do they manage day to day work? how do their preferred style mesh into their production pipeline (coding, debugging, deployment and maintenance)? and what makes them prefer one way over another or the mix if applicable?

Regards,

Ala'a Mohammad.

_______________________________________________ pro mailing list pro@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/pro

-- Jacob Kozinn Bespoke Tailor http://jacobkozinnbespoke.com <http://jacobkozinn-bespoketailor.com>

On Thu, Jan 20, 2011 at 4:45 PM, Ala'a Mohammad <amalawi@gmail.com> wrote:

I'm continually learning Common-lisp and trying to find the best style that suites me better. I've tried 'an imager' style (cooking a an image with all required libraries loaded when required), and 'a filer' style (loading files or systems each time I fire-up a CL implementation). I'm interested to hear what others use CL. How do they manage day to day work? how do their preferred style mesh into their production pipeline (coding, debugging, deployment and maintenance)? and what makes them prefer one way over another or the mix if applicable?

Some reasons why one would use images rather than loading up from files: - Saving on startup times Nowadays, using images to reduce startup time of the Lisp is often not worth the trouble. Computers are fast, file systems are fast and most importantly, restarts are relatively rare with most Lisp systems that I know. There certainly are cases where every second in terms of saved startup time is important, and in these cases, writing an image is a good way to go. - Reducing the number of files needed to distribute an application, or distribute binary applications Some Lisps can dump images that are self contained. Most of them require some auxiliary files. If you want to distribute your system without providing source code, a dumped image is the easiest way to achive that. - Save transient state across Lisp invocations As an image includes the full heap state, one can use saved images to snapshot transient state. That way, one can get around all serialization issues that database systems try to solve. The approach is limited in that the commit units are generally rather large. Personally, I used saved images rarely. I deploy my systems with source code, so I need to deploy a lot of files anyway, and I use a database system, so I don't need images as a persistence mechanism. Startup times don't matter much to me, as I'm usually working with long-running Lisp instances. -Hans

[Once again I forgot to Reply All. Ala, you've seen part of this before.] I'm a filer. With ASDF and even more so these days with Quicklisp, it's just easier to load the stuff I need and it doesn't take that long and it saves me having to spend any mental energy keeping track of different images. However, Fare's mention of buildapp reminded me that I use it for some of my deployed websites, mostly just so I have one thing that is built and I know won't change, if I accidentally decide to upgrade a library or tweak some source code for some other reason. (Obviously, I could also just keep my source for the running app in some distinct place--now that I'm a bit more adept at git, I might start doing that.) -Peter On Thu, Jan 20, 2011 at 7:45 AM, Ala'a Mohammad <amalawi@gmail.com> wrote:

Hi,

I'm continually learning Common-lisp and trying to find the best style that suites me better. I've tried 'an imager' style (cooking a an image with all required libraries loaded when required), and 'a filer' style (loading files or systems each time I fire-up a CL implementation). I'm interested to hear what others use CL. How do they manage day to day work? how do their preferred style mesh into their production pipeline (coding, debugging, deployment and maintenance)? and what makes them prefer one way over another or the mix if applicable?

Regards,

Ala'a Mohammad.

_______________________________________________ pro mailing list pro@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/pro

-- Peter Seibel http://www.codequarterly.com/

I use files and quicklisp when developing, but deliver and provision binary images. Most of my apps are web based, and i run the lisp image behind runit, a service manager that handles logging as well as startup and shutdown, and restarting the image if it crashes. It also makes rolling back a release trivial, modulo database schema changes. I don't use anything like cl-launch or buildapp, if only because these tools didn't exist in a usable form when i started, and i haven't had a good reason to change. Quicklisp, OTOH, has changed the way i work significantly. With the exception of production instances, most of my code is deployed via a load.lisp script that explicitly lists and loads dependencies from QL, where before libraries were kept in version control. I'm also using more libraries these days. So, i'm both, but primarily a filer these days. Cheers, drewc On 20 January 2011 07:45, Ala'a Mohammad <amalawi@gmail.com> wrote:

Hi,

I'm continually learning Common-lisp and trying to find the best style that suites me better. I've tried 'an imager' style (cooking a an image with all required libraries loaded when required), and 'a filer' style (loading files or systems each time I fire-up a CL implementation). I'm interested to hear what others use CL. How do they manage day to day work? how do their preferred style mesh into their production pipeline (coding, debugging, deployment and maintenance)? and what makes them prefer one way over another or the mix if applicable?

Regards,

Ala'a Mohammad.

_______________________________________________ pro mailing list pro@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/pro

On Thu, Jan 20, 2011 at 07:45, Ala'a Mohammad <amalawi@gmail.com> wrote:

I'm interested to hear what others use CL. How do they manage day to day work? how do their preferred style mesh into their production pipeline (coding, debugging, deployment and maintenance)? and what makes them prefer one way over another or the mix if applicable?

For loading required software, I'd say 100% filer. ASDF and Quicklisp make operating on files to easy for me that I just don't want to waste any energy thinking about what definitions are in the image and which I've saved in a (source-controlled) file somewhere - the 30 seconds I spend waiting for software to load are nothing compared to an afternoon spent debugging a function whose definition in the image differs from what is in the file containing its (alleged) source code... Or worse, functions/variables that are present only in the image, and not in any file. When it comes to throw-away code, though, I usually just type it into the repl or the slime-scratch buffer. But: once throwaway stuff starts becoming useful, I use quickproject and paste the latest definitions into a source file and check that into git ASAP. Of course, this step has the potential to go wrong in the same way I mentioned above: if I manage to forget a definition, it's debug time again. Fortunately, that happens early enough in the source's lifetime that it's not hard to find the definition again. As for deploying, I have started making quicklisp trees containing the requisite software and a git checkout of my project. You can still incrementally load stuff, and you can be pretty certain that what you tested truly is what you deployed (-: Hope that's useful, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs

The system Ioad facility I have developed, on its first run on a particular system, creates a core file containing all the support libraries needed for the system, and then starts SBCL using that core file, proceeding to ASDF load the system proper. On subsequent starts, the first core creation step is skipped, saving much time, in most cases making the systems start instantly since no compilation needs to occur. Whenever site-lisp is changed, then the cores need to be removed and will automatically be recreated when the system restarts. In the core is stored the head git SHA commit id taken from site-lisp at the time of core creation in order to detect a core to source code discrepancy when the cores are ran. On Thu, Jan 20, 2011 at 4:45 PM, Ala'a Mohammad <amalawi@gmail.com> wrote:

Hi,

I'm continually learning Common-lisp and trying to find the best style that suites me better. I've tried 'an imager' style (cooking a an image with all required libraries loaded when required), and 'a filer' style (loading files or systems each time I fire-up a CL implementation). I'm interested to hear what others use CL. How do they manage day to day work? how do their preferred style mesh into their production pipeline (coding, debugging, deployment and maintenance)? and what makes them prefer one way over another or the mix if applicable?

Regards,

Ala'a Mohammad.

_______________________________________________ pro mailing list pro@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/pro