Subject: Re: shootout: implementing an interpreter for a simple procedural language Minim
From: rpw3@rpw3.org (Rob Warnock)
Date: Tue, 07 Aug 2007 03:35:20 -0500
Newsgroups: comp.lang.lisp,comp.lang.functional
Message-ID: <d7OdnVG_ee5VsyXbnZ2dnUVZ_u2mnZ2d@speakeasy.net>
Rainer Joswig  <joswig@lisp.de> wrote:
+---------------
| There are several Lisp applictions in the field that are being
| live patched.
+---------------

I personally support several web sites which include a persistent
Common Lisp-based (CMUCL) application server as part of the site,
and have on numerous occasions "live patched" the production server
in preference to stopping/restarting it. [Yes, the patches had all
been previously applied to a test server, so the risk was quite small.]

Note that the Lisp application server on these systems stays up
"forever" [so far, knock on wood!] unless the underlying system
gets rebooted for some reason. [The Linux system that's at a co-lo
tends to get rebooted once a week "whether it needs it or not",
due to their use of RHEL's "auto-update" process. Others (mostly
FreeBSD-based) have uptimes in months to years...]

+---------------
| Markus wrote:
| > Furthermore, if live pathcing becomes a development methodology rather
| > than an upgrade mechanism I start to wonder how those people do
| > version control and code reviews: It must be really difficult to
| > recover the current state of code in the image after patching in all
| > changes?
+---------------

Bull. Live patching is *NOT* incompatible with good source code control.

Moreover, "live patching as a development methodology" is, IMHO,
*the* way to go for rapid deployment of web sites. I couldn't have
developed the apps I did in the small amount of time I did had I
not done it that way. Multiple windows open: a browser, a "tail -f"
of the Apache error log, an "attachtty" window to a listener/REPL
in the running server, and a window per file being edited. During
development, each page hit did an ASDF:LOAD-OP on the associated
server subsystem(s), so the development cycle was: (1) Edit whichever
files needed it; (2) Do a "save" on changed files; (3) Hit the
"Reload" [or "Refresh", for you MS users] button on the browser.
Voila! The new code gets compiled & loaded & used to serve up the
reloaded page.


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607