While I appreciate image based environments like Squeak or the Lisp
Machines (what I have gleaned of them from CLIM and demos), most of my
work with lisp involves smallish-looking scripts playing nicely with an
OS. This can be difficult at times even with "small" common lisp
implementations.
I am familiar with various ways to adapt, but the underlying issue never
really changes-- lisp really shines when it _is_ the OS. However, one
the things about a real os that would helpful to the way I use lisp is if
there were a separation between "user" and "kernel" data.
Hosted environments like Java and .NET can have a in memory, running vm
waiting to run applications. A lisp could provide a running image--
effectively a runtime environment, to do the same thing. However, there
is no separation between the data provided by the runtime and the data
used by the program. After the program is "done" The lisp image is in a
modified state.
Are there ways lisp can be used to serve applications similar to the way
that Java VMs run byte code? If not, what are the issues involved in
doing this?
Matt
On Jul 10, 11:18 pm, Matthew D Swank <··················@gmail.com>
wrote:
>
> I am familiar with various ways to adapt, but the underlying issue never
> really changes-- lisp really shines when it _is_ the OS.
I think that's a fairly common view. I don't think there is the same
level of support for the kind of things that Java application servers
can do for Lisp though - unsurprisingly because a huge amount of money
has been spent on Java.
However it's perfectly possible to use Lisp as conventional Unix/Linux
executables. It's implementation-dependent but most implementations
will provide some way of creating something that can be run from the
command line, and the startup time & resource requirements are not
excessive. Around 2001 I did some measurements for LispWorks-created
executables, and their startup times were slower than Perl's, but not
by so much you'd notice.
Matthew D Swank <··················@gmail.com> writes:
> Hosted environments like Java and .NET can have a in memory, running vm
> waiting to run applications. A lisp could provide a running image--
> effectively a runtime environment, to do the same thing. However, there
> is no separation between the data provided by the runtime and the data
> used by the program. After the program is "done" The lisp image is in a
> modified state.
The same is true for Java. AFAICS the only difference is that you can
modify much more of the "low-level state" in a Lisp image than in a
Java process. In both cases, you can create programs that just won't
run in the same image. In practice, you're hardly ever running two
completely separate programs in the same image anyway (at least, not
in Java, you're not), and if you do, you should be careful to "play
nice" with the environment.
> Are there ways lisp can be used to serve applications similar to the way
> that Java VMs run byte code? If not, what are the issues involved in
> doing this?
I don't see why you think that isn't already possible.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
On Fri, 11 Jul 2008 00:49:38 +0200, Joost Diepenmaat wrote:
> Matthew D Swank <··················@gmail.com> writes:
>
>> Hosted environments like Java and .NET can have a in memory, running vm
>> waiting to run applications. A lisp could provide a running image--
>> effectively a runtime environment, to do the same thing. However,
>> there is no separation between the data provided by the runtime and the
>> data used by the program. After the program is "done" The lisp image
>> is in a modified state.
>
> The same is true for Java. AFAICS the only difference is that you can
> modify much more of the "low-level state" in a Lisp image than in a Java
> process. In both cases, you can create programs that just won't run in
> the same image. In practice, you're hardly ever running two completely
> separate programs in the same image anyway (at least, not in Java,
> you're not), and if you do, you should be careful to "play nice" with
> the environment.
>
I'm thinking of CLR Application Domains. From Wikipedia
(Application_Domain):
> A Common Language Runtime application domain is a mechanism (similar to
> an operating system process), used to isolate executed software
> applications from one another so that they do not affect each other.
> This is achieved by making any unique virtual address space run exactly
> one application and scopes the resources for the process or application
> domain using that address space.
>> Are there ways lisp can be used to serve applications similar to the
>> way that Java VMs run byte code? If not, what are the issues involved
>> in doing this?
>
> I don't see why you think that isn't already possible.
It doesn't seem possible in the way I'm thinking.
Matt
Matthew D Swank wrote:
> On Fri, 11 Jul 2008 00:49:38 +0200, Joost Diepenmaat wrote:
>
>> Matthew D Swank <··················@gmail.com> writes:
>>> Are there ways lisp can be used to serve applications similar to the
>>> way that Java VMs run byte code? If not, what are the issues involved
>>> in doing this?
>> I don't see why you think that isn't already possible.
>
> It doesn't seem possible in the way I'm thinking.
Hi Matt,
Why not just use operating system processes?
Sohail
On Fri, 11 Jul 2008 03:30:47 +0000, Sohail Somani wrote:
> Matthew D Swank wrote:
>> On Fri, 11 Jul 2008 00:49:38 +0200, Joost Diepenmaat wrote:
>>
>>> Matthew D Swank <··················@gmail.com> writes:
>>>> Are there ways lisp can be used to serve applications similar to the
>>>> way that Java VMs run byte code? If not, what are the issues
>>>> involved in doing this?
>>> I don't see why you think that isn't already possible.
>>
>> It doesn't seem possible in the way I'm thinking.
>
> Hi Matt,
>
> Why not just use operating system processes?
>
That is interesting. It would allow one to clone a "virgin" runtime.
The base image is running. A request to start an app is made. The
runtime forks, then loads the app. The thing I always worry about is
memory. What can be shared? I suppose the CLR doesn't have to worry
about things like modifiable types.
It would be nice to know how small a usable lisp kernel could be.
What's in your average (for example) sbcl image?
Garbage Collector
Basic Data Structure Implementations
Symbols
Compiler
Posix Bindings
PCL
...?
How do you estimate how much each of these take up? I suppose the gc
knows.
Matt
Matthew D Swank wrote:
> On Fri, 11 Jul 2008 03:30:47 +0000, Sohail Somani wrote:
>
>> Matthew D Swank wrote:
>>> On Fri, 11 Jul 2008 00:49:38 +0200, Joost Diepenmaat wrote:
>>>
>>>> Matthew D Swank <··················@gmail.com> writes:
>>>>> Are there ways lisp can be used to serve applications similar to the
>>>>> way that Java VMs run byte code? If not, what are the issues
>>>>> involved in doing this?
>>>> I don't see why you think that isn't already possible.
>>> It doesn't seem possible in the way I'm thinking.
>> Hi Matt,
>>
>> Why not just use operating system processes?
>>
>
> That is interesting. It would allow one to clone a "virgin" runtime.
> The base image is running. A request to start an app is made. The
> runtime forks, then loads the app. The thing I always worry about is
> memory. What can be shared? I suppose the CLR doesn't have to worry
> about things like modifiable types.
Yep, this is what I was thinking. As far as memory is concerned, I
think it depends on how nice your applications and libraries are.
Why do you want to do this in the first place?
> It would be nice to know how small a usable lisp kernel could be.
Add the word "usable" and small is very relative.
> What's in your average (for example) sbcl image?
> How do you estimate how much each of these take up? I suppose the gc
> knows.
room tells you something...
On Fri, 11 Jul 2008 04:34:03 +0000, Sohail Somani wrote:
> Matthew D Swank wrote:
>> On Fri, 11 Jul 2008 03:30:47 +0000, Sohail Somani wrote:
>>
>>> Matthew D Swank wrote:
>>>> On Fri, 11 Jul 2008 00:49:38 +0200, Joost Diepenmaat wrote:
>>>>
>>>>> Matthew D Swank <··················@gmail.com> writes:
>>>>>> Are there ways lisp can be used to serve applications similar to
>>>>>> the way that Java VMs run byte code?
...
>>>
>>> Why not just use operating system processes?
>>>
>>>
>> That is interesting. It would allow one to clone a "virgin" runtime.
...
> Yep, this is what I was thinking. As far as memory is concerned, I
> think it depends on how nice your applications and libraries are.
>
> Why do you want to do this in the first place?
>
I want a long running process available to run multiple scripts
simultaneously, but beyond that I am generally curious.
Matt
Matthew D Swank wrote:
> On Fri, 11 Jul 2008 04:34:03 +0000, Sohail Somani wrote:
>> Why do you want to do this in the first place?
>>
>
> I want a long running process available to run multiple scripts
> simultaneously, but beyond that I am generally curious.
But is the real reason b/c you want quick startup? If this is the case,
you can use a core file (in sbcl) to achieve the same thing.
Matthew D Swank wrote:
> I'm thinking of CLR Application Domains. From Wikipedia
> (Application_Domain):
If you use Lisp, then Lisp _is_ the "CLR".
You can implement languages on top of it, no need for some virtual machine.
On Fri, 11 Jul 2008 00:49:38 +0200, Joost Diepenmaat <·····@zeekat.nl> said:
| Matthew D Swank <··················@gmail.com> writes:
|| Hosted environments like Java and .NET can have a in memory, running vm
|| waiting to run applications. A lisp could provide a running image--
|| effectively a runtime environment, to do the same thing. However, there
|| is no separation between the data provided by the runtime and the data
|| used by the program. After the program is "done" The lisp image is in a
|| modified state.
| The same is true for Java. AFAICS the only difference is that you can
| modify much more of the "low-level state" in a Lisp image than in a
| Java process. In both cases, you can create programs that just won't
| run in the same image. In practice, you're hardly ever running two
| completely separate programs in the same image anyway (at least, not
| in Java, you're not), and if you do, you should be careful to "play
| nice" with the environment.
Direct comparisons between a lisp image and a JVM are somewhat
involved, and direct analogies do not always work very well. This
by itself is not to say that one is better or worse than the other,
but simply that the differences must be carefully taken into
account.
As one example, consider how an "initial investment" in a JVM's
running time is needed before JIT compilation starts giving its
returns, and the implications of that.
As another example, consider how different programs running in the
same JVM can have each its own class loader and be isolated from
each other in this way. One of the consequences is that there may
be no global variables that are shared by these programs (not
counting class variables of the classes on the system class path,
which may be very restricted).
The above is "including, but not limited to"...
---Vassil.
--
Peius melius est. ---Ricardus Gabriel.
Matthew D Swank <··················@gmail.com> wrote:
+---------------
| While I appreciate image based environments like Squeak or the Lisp
| Machines (what I have gleaned of them from CLIM and demos), most of my
| work with lisp involves smallish-looking scripts playing nicely with an
| OS. This can be difficult at times even with "small" common lisp
| implementations.
+---------------
Don't despair: Modern VM systems [Unix/Linux/etc.] do a *great* job
of sharing mmap'd file segments, so much so that even with, say,
CMUCL's largish core file of ~25 MB [more, if you save out a core
image with your most popular libraries in it], because it mmap's its
core into memory and the O/S caches that across invocations, CMUCL's
startup time for the 2nd & subsequent executions can actually be *faster*
than smaller systems [e.g., the much-smaller CLISP], to wit:
$ cat test_cmucl # [Note 1]
#!/usr/local/bin/cmucl -script
(format t "Hello, world!~%")
$ /usr/bin/time ./test_cmucl
Hello, world!
0.01 real 0.00 user 0.00 sys
$ time-hist ./test_cmucl
Timing 100 runs of: ./test_cmucl
4 0.011
89 0.012
7 0.013
1.285u 1.255s 0:02.57 98.4% 224+1763k 0+0io 0pf+0w
$
Yes, that's only 11-13 milliseconds. *Plenty* fast for human-scale
response times. As a result, I use CMUCL for all *kinds* of small
"shell scripting" stuff":
$ file ~/bin/* | grep 'cmucl.*script' | wc -l
47
$
Specifically, "csq" is a small (40-line) script to convert
broadband cell modem AT+CSQ responses to dBm and vice-versa:
$ wc bin/csq
40 178 1429 bin/csq
$ csq
usage: /u/rpw3/bin/csq { +csq | -dBm | :CSQ | :DBM }
$ csq 18
AT+CSQ 18 = -77 dBm ==> 3 bars, "satisfactory (17-21)"
$ csq -63
AT+CSQ 25 = -63 dBm ==> 4 bars, "quite good (22-26)"
$ csq :dbm
AT+CSQ 4 = -105 dBm ==> 0 bars, "no signal (0-6)"
AT+CSQ 6 = -100 dBm ==> 1 bar, "borderline unusable (7-11)"
AT+CSQ 9 = -95 dBm ==> 1 bar, "borderline unusable (7-11)"
AT+CSQ 12 = -90 dBm ==> 2 bars, "weak, reduced throughput (12-16)"
AT+CSQ 14 = -85 dBm ==> 2 bars, "weak, reduced throughput (12-16)"
AT+CSQ 16 = -80 dBm ==> 3 bars, "satisfactory (17-21)"
AT+CSQ 19 = -75 dBm ==> 3 bars, "satisfactory (17-21)"
AT+CSQ 22 = -70 dBm ==> 4 bars, "quite good (22-26)"
AT+CSQ 24 = -65 dBm ==> 4 bars, "quite good (22-26)"
AT+CSQ 26 = -60 dBm ==> 5 bars, "exceptionally strong (27+)"
$
Or a stub/idiot version of an HTTP client:
$ wc bin/http-get
189 886 7283 bin/http-get
$ http-get -q http://rpw3.org/~rpw3/sample.txt # "-q" quiets headers
Nothing to see here, move along, move along...
$ http-get -H www.google.com # "-H" says do "HEAD", not "GET".
HEAD / HTTP/1.0
Host: www.google.com
HTTP/1.0 200 OK
Cache-Control: private, max-age=0
Date: Fri, 11 Jul 2008 09:06:08 GMT
Expires: -1
Content-Type: text/html; charset=ISO-8859-1
Set-Cookie: PREF=ID=72c19595acd948db:TM=1215767168:LM=1215767168:S=LKcYtKTH_bqJo_zt; expires=Sun, 11-Jul-2010 09:06:08 GMT; path=/; domain=.google.com
Server: gws
Content-Length: 0
Connection: Close
$
Or a script that, hard-linked to different names, converts temperatures
depending on its name?
$ ls -il bin/?2?
1507459 -rwxr-xr-x 1 rpw3 rpw3 819 Jul 7 2005 bin/c2f
1507459 -rwxr-xr-x 1 rpw3 rpw3 819 Jul 7 2005 bin/f2c
1507459 -rwxr-xr-x 1 rpw3 rpw3 819 Jul 7 2005 bin/k2c
$ c2f 25
77.0
$ f2c 95
35.0
$ k2c 77
-196.16
$
Is that the sort of "smallish-looking scripts playing nicely with an O/S"
you meant?!? ;-}
+---------------
| Hosted environments like Java and .NET can have a in memory, running vm
| waiting to run applications. A lisp could provide a running image--
| effectively a runtime environment, to do the same thing. However, there
| is no separation between the data provided by the runtime and the data
| used by the program. After the program is "done" The lisp image is in a
| modified state.
+---------------
That's up to how you write your apps. If you write them to *not* mutate
global state, then the persistent Lisp image will (eventually) GC whatever
allocated data got left behind and you'll be good as new again.
Also, Common Lisp gets used a *LOT* as either a web server proper
[CL-HTTP, AllegroServe, Araneida, etc.] or as a persistent web
applications daemon behind some web server such as Apache [UCW,
Hunchentoot, cl-weblocks, etc., using mod_lisp or FastCGI or
equiv. as a connector], see <http://www.cliki.net/web> for *lots*
of that kind of stuff. Such web servers & applications servers
tend to run nicely for many months without having problems with
"accumulating state".
-Rob
[1] This uses my "-script" add-on to CMUCL to support "#!" scripts:
http://rpw3.org/hacks/lisp/site-switch-script.lisp
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Jul 11, 5:38 am, ····@rpw3.org (Rob Warnock) wrote:
> Matthew D Swank <··················@gmail.com> wrote:
> +---------------
> | While I appreciate image based environments like Squeak or the Lisp
> | Machines (what I have gleaned of them from CLIM and demos), most of my
> | work with lisp involves smallish-looking scripts playing nicely with an
> | OS. This can be difficult at times even with "small" common lisp
> | implementations.
> +---------------
>
> Don't despair: Modern VM systems [Unix/Linux/etc.] do a *great* job
> of sharing mmap'd file segments, so much so that even with, say,
> CMUCL's largish core file of ~25 MB [more, if you save out a core
> image with your most popular libraries in it], because it mmap's its
> core into memory and the O/S caches that across invocations, CMUCL's
> startup time for the 2nd & subsequent executions can actually be *faster*
> than smaller systems [e.g., the much-smaller CLISP], to wit:
>
> $ cat test_cmucl # [Note 1]
> #!/usr/local/bin/cmucl -script
> (format t "Hello, world!~%")
> $ /usr/bin/time ./test_cmucl
> Hello, world!
> 0.01 real 0.00 user 0.00 sys
> $ time-hist ./test_cmucl
> Timing 100 runs of: ./test_cmucl
> 4 0.011
> 89 0.012
> 7 0.013
> 1.285u 1.255s 0:02.57 98.4% 224+1763k 0+0io 0pf+0w
> $
>
> Yes, that's only 11-13 milliseconds. *Plenty* fast for human-scale
> response times. As a result, I use CMUCL for all *kinds* of small
> "shell scripting" stuff":
>
> $ file ~/bin/* | grep 'cmucl.*script' | wc -l
> 47
> $
>
> Specifically, "csq" is a small (40-line) script to convert
> broadband cell modem AT+CSQ responses to dBm and vice-versa:
>
> $ wc bin/csq
> 40 178 1429 bin/csq
> $ csq
> usage: /u/rpw3/bin/csq { +csq | -dBm | :CSQ | :DBM }
> $ csq 18
> AT+CSQ 18 = -77 dBm ==> 3 bars, "satisfactory (17-21)"
> $ csq -63
> AT+CSQ 25 = -63 dBm ==> 4 bars, "quite good (22-26)"
> $ csq :dbm
> AT+CSQ 4 = -105 dBm ==> 0 bars, "no signal (0-6)"
> AT+CSQ 6 = -100 dBm ==> 1 bar, "borderline unusable (7-11)"
> AT+CSQ 9 = -95 dBm ==> 1 bar, "borderline unusable (7-11)"
> AT+CSQ 12 = -90 dBm ==> 2 bars, "weak, reduced throughput (12-16)"
> AT+CSQ 14 = -85 dBm ==> 2 bars, "weak, reduced throughput (12-16)"
> AT+CSQ 16 = -80 dBm ==> 3 bars, "satisfactory (17-21)"
> AT+CSQ 19 = -75 dBm ==> 3 bars, "satisfactory (17-21)"
> AT+CSQ 22 = -70 dBm ==> 4 bars, "quite good (22-26)"
> AT+CSQ 24 = -65 dBm ==> 4 bars, "quite good (22-26)"
> AT+CSQ 26 = -60 dBm ==> 5 bars, "exceptionally strong (27+)"
> $
>
> Or a stub/idiot version of an HTTP client:
>
> $ wc bin/http-get
> 189 886 7283 bin/http-get
> $ http-get -qhttp://rpw3.org/~rpw3/sample.txt # "-q" quiets headers
> Nothing to see here, move along, move along...
> $ http-get -Hwww.google.com # "-H" says do "HEAD", not "GET".
> HEAD / HTTP/1.0
> Host:www.google.com
>
> HTTP/1.0 200 OK
> Cache-Control: private, max-age=0
> Date: Fri, 11 Jul 2008 09:06:08 GMT
> Expires: -1
> Content-Type: text/html; charset=ISO-8859-1
> Set-Cookie: PREF=ID=72c19595acd948db:TM=1215767168:LM=1215767168:S=LKcYtKTH_bqJo_zt; expires=Sun, 11-Jul-2010 09:06:08 GMT; path=/; domain=.google.com
> Server: gws
> Content-Length: 0
> Connection: Close
> $
>
> Or a script that, hard-linked to different names, converts temperatures
> depending on its name?
>
> $ ls -il bin/?2?
> 1507459 -rwxr-xr-x 1 rpw3 rpw3 819 Jul 7 2005 bin/c2f
> 1507459 -rwxr-xr-x 1 rpw3 rpw3 819 Jul 7 2005 bin/f2c
> 1507459 -rwxr-xr-x 1 rpw3 rpw3 819 Jul 7 2005 bin/k2c
> $ c2f 25
> 77.0
> $ f2c 95
> 35.0
> $ k2c 77
> -196.16
> $
>
> Is that the sort of "smallish-looking scripts playing nicely with an O/S"
> you meant?!? ;-}
>
> +---------------
> | Hosted environments like Java and .NET can have a in memory, running vm
> | waiting to run applications. A lisp could provide a running image--
> | effectively a runtime environment, to do the same thing. However, there
> | is no separation between the data provided by the runtime and the data
> | used by the program. After the program is "done" The lisp image is in a
> | modified state.
> +---------------
>
> That's up to how you write your apps. If you write them to *not* mutate
> global state, then the persistent Lisp image will (eventually) GC whatever
> allocated data got left behind and you'll be good as new again.
>
> Also, Common Lisp gets used a *LOT* as either a web server proper
> [CL-HTTP, AllegroServe, Araneida, etc.] or as a persistent web
> applications daemon behind some web server such as Apache [UCW,
> Hunchentoot, cl-weblocks, etc., using mod_lisp or FastCGI or
> equiv. as a connector], see <http://www.cliki.net/web> for *lots*
> of that kind of stuff. Such web servers & applications servers
> tend to run nicely for many months without having problems with
> "accumulating state".
>
> -Rob
>
> [1] This uses my "-script" add-on to CMUCL to support "#!" scripts:
>
> http://rpw3.org/hacks/lisp/site-switch-script.lisp
>
> -----
> Rob Warnock <····@rpw3.org>
> 627 26th Avenue <URL:http://rpw3.org/>
> San Mateo, CA 94403 (650)572-2607
Indeed, this is what we're doing with our server farm at ITA Software:
running multiple Lisp images each in its own operating system process,
on each machine in our cluster. Our machines are 4-core dual-
processor Intel-type machines running Linux. We'll be doing extensive
experiments to determine the ideal number of Lisp processes to run per
cluster element. One rule of thumb I often hear is two processes per
core in the CPU, but it will obviously depend on a lot of things.
We're confident that the sharing will be good, for the reasons Rob
Warnock explains above (and because we've discussed this with the Lisp
implementors at Clozure and because we ran some simple tests).
Remember, the size of Lisp images hasn't been going up very much,
whereas the cost of main memory has been dropping sharply for many
years. Memory consumption is no longer nearly as much of an issue as
it used to be.
We'll be running servers intended to stay up for a very long time,
processing transactions at high speed. Of course they'll all be
clustered so that if one goes down, it can be restarted without any
visible effect to other components of the system. We are aiming for
99.99% system uptime. The fact that we're using Common Lisp is not
considered any problem as far as achieving high availability (or else
we would not use it).
On Jul 11, 2:47 am, Dan Weinreb <····@alum.mit.edu> wrote:
> On Jul 11, 5:38 am, ····@rpw3.org (Rob Warnock) wrote:
>
>
>
> > Matthew D Swank <··················@gmail.com> wrote:
> > +---------------
> > | While I appreciate image based environments like Squeak or the Lisp
> > | Machines (what I have gleaned of them from CLIM and demos), most of my
> > | work with lisp involves smallish-looking scripts playing nicely with an
> > | OS. This can be difficult at times even with "small" common lisp
> > | implementations.
> > +---------------
>
> > Don't despair: Modern VM systems [Unix/Linux/etc.] do a *great* job
> > of sharing mmap'd file segments, so much so that even with, say,
> > CMUCL's largish core file of ~25 MB [more, if you save out a core
> > image with your most popular libraries in it], because it mmap's its
> > core into memory and the O/S caches that across invocations, CMUCL's
> > startup time for the 2nd & subsequent executions can actually be *faster*
> > than smaller systems [e.g., the much-smaller CLISP], to wit:
>
> > $ cat test_cmucl # [Note 1]
> > #!/usr/local/bin/cmucl -script
> > (format t "Hello, world!~%")
> > $ /usr/bin/time ./test_cmucl
> > Hello, world!
> > 0.01 real 0.00 user 0.00 sys
> > $ time-hist ./test_cmucl
> > Timing 100 runs of: ./test_cmucl
> > 4 0.011
> > 89 0.012
> > 7 0.013
> > 1.285u 1.255s 0:02.57 98.4% 224+1763k 0+0io 0pf+0w
> > $
>
> > Yes, that's only 11-13 milliseconds. *Plenty* fast for human-scale
> > response times. As a result, I use CMUCL for all *kinds* of small
> > "shell scripting" stuff":
>
> > $ file ~/bin/* | grep 'cmucl.*script' | wc -l
> > 47
> > $
>
> > Specifically, "csq" is a small (40-line) script to convert
> > broadband cell modem AT+CSQ responses to dBm and vice-versa:
>
> > $ wc bin/csq
> > 40 178 1429 bin/csq
> > $ csq
> > usage: /u/rpw3/bin/csq { +csq | -dBm | :CSQ | :DBM }
> > $ csq 18
> > AT+CSQ 18 = -77 dBm ==> 3 bars, "satisfactory (17-21)"
> > $ csq -63
> > AT+CSQ 25 = -63 dBm ==> 4 bars, "quite good (22-26)"
> > $ csq :dbm
> > AT+CSQ 4 = -105 dBm ==> 0 bars, "no signal (0-6)"
> > AT+CSQ 6 = -100 dBm ==> 1 bar, "borderline unusable (7-11)"
> > AT+CSQ 9 = -95 dBm ==> 1 bar, "borderline unusable (7-11)"
> > AT+CSQ 12 = -90 dBm ==> 2 bars, "weak, reduced throughput (12-16)"
> > AT+CSQ 14 = -85 dBm ==> 2 bars, "weak, reduced throughput (12-16)"
> > AT+CSQ 16 = -80 dBm ==> 3 bars, "satisfactory (17-21)"
> > AT+CSQ 19 = -75 dBm ==> 3 bars, "satisfactory (17-21)"
> > AT+CSQ 22 = -70 dBm ==> 4 bars, "quite good (22-26)"
> > AT+CSQ 24 = -65 dBm ==> 4 bars, "quite good (22-26)"
> > AT+CSQ 26 = -60 dBm ==> 5 bars, "exceptionally strong (27+)"
> > $
>
> > Or a stub/idiot version of an HTTP client:
>
> > $ wc bin/http-get
> > 189 886 7283 bin/http-get
> > $ http-get -qhttp://rpw3.org/~rpw3/sample.txt # "-q" quiets headers
> > Nothing to see here, move along, move along...
> > $ http-get -Hwww.google.com # "-H" says do "HEAD", not "GET".
> > HEAD / HTTP/1.0
> > Host:www.google.com
>
> > HTTP/1.0 200 OK
> > Cache-Control: private, max-age=0
> > Date: Fri, 11 Jul 2008 09:06:08 GMT
> > Expires: -1
> > Content-Type: text/html; charset=ISO-8859-1
> > Set-Cookie: PREF=ID=72c19595acd948db:TM=1215767168:LM=1215767168:S=LKcYtKTH_bqJo_zt; expires=Sun, 11-Jul-2010 09:06:08 GMT; path=/; domain=.google.com
> > Server: gws
> > Content-Length: 0
> > Connection: Close
> > $
>
> > Or a script that, hard-linked to different names, converts temperatures
> > depending on its name?
>
> > $ ls -il bin/?2?
> > 1507459 -rwxr-xr-x 1 rpw3 rpw3 819 Jul 7 2005 bin/c2f
> > 1507459 -rwxr-xr-x 1 rpw3 rpw3 819 Jul 7 2005 bin/f2c
> > 1507459 -rwxr-xr-x 1 rpw3 rpw3 819 Jul 7 2005 bin/k2c
> > $ c2f 25
> > 77.0
> > $ f2c 95
> > 35.0
> > $ k2c 77
> > -196.16
> > $
>
> > Is that the sort of "smallish-looking scripts playing nicely with an O/S"
> > you meant?!? ;-}
>
> > +---------------
> > | Hosted environments like Java and .NET can have a in memory, running vm
> > | waiting to run applications. A lisp could provide a running image--
> > | effectively a runtime environment, to do the same thing. However, there
> > | is no separation between the data provided by the runtime and the data
> > | used by the program. After the program is "done" The lisp image is in a
> > | modified state.
> > +---------------
>
> > That's up to how you write your apps. If you write them to *not* mutate
> > global state, then the persistent Lisp image will (eventually) GC whatever
> > allocated data got left behind and you'll be good as new again.
>
> > Also, Common Lisp gets used a *LOT* as either a web server proper
> > [CL-HTTP, AllegroServe, Araneida, etc.] or as a persistent web
> > applications daemon behind some web server such as Apache [UCW,
> > Hunchentoot, cl-weblocks, etc., using mod_lisp or FastCGI or
> > equiv. as a connector], see <http://www.cliki.net/web> for *lots*
> > of that kind of stuff. Such web servers & applications servers
> > tend to run nicely for many months without having problems with
> > "accumulating state".
>
> > -Rob
>
> > [1] This uses my "-script" add-on to CMUCL to support "#!" scripts:
>
> > http://rpw3.org/hacks/lisp/site-switch-script.lisp
>
> > -----
> > Rob Warnock <····@rpw3.org>
> > 627 26th Avenue <URL:http://rpw3.org/>
> > San Mateo, CA 94403 (650)572-2607
>
> Indeed, this is what we're doing with our server farm at ITA Software:
> running multiple Lisp images each in its own operating system process,
> on each machine in our cluster. Our machines are 4-core dual-
> processor Intel-type machines running Linux. We'll be doing extensive
> experiments to determine the ideal number of Lisp processes to run per
> cluster element. One rule of thumb I often hear is two processes per
> core in the CPU, but it will obviously depend on a lot of things.
>
> We're confident that the sharing will be good, for the reasons Rob
> Warnock explains above (and because we've discussed this with the Lisp
> implementors at Clozure and because we ran some simple tests).
> Remember, the size of Lisp images hasn't been going up very much,
> whereas the cost of main memory has been dropping sharply for many
> years. Memory consumption is no longer nearly as much of an issue as
> it used to be.
>
> We'll be running servers intended to stay up for a very long time,
> processing transactions at high speed. Of course they'll all be
> clustered so that if one goes down, it can be restarted without any
> visible effect to other components of the system. We are aiming for
> 99.99% system uptime. The fact that we're using Common Lisp is not
> considered any problem as far as achieving high availability (or else
> we would not use it).
wow, cool, load balanced cluster ? like running 20 apaches on 4 boxes?
In article <································@speakeasy.net>,
····@rpw3.org (Rob Warnock) wrote:
> Matthew D Swank <··················@gmail.com> wrote:
> +---------------
> | While I appreciate image based environments like Squeak or the Lisp
> | Machines (what I have gleaned of them from CLIM and demos), most of my
> | work with lisp involves smallish-looking scripts playing nicely with an
> | OS. This can be difficult at times even with "small" common lisp
> | implementations.
> +---------------
Rob, it would be cool if you could collect all those nifty tricks^h^h^h^h^hmagic
and publish something about it sometime. I guess a little tutorial of yours
at some Lisp event would also be very educational. I always enjoy reading
your posts!
>
> Don't despair: Modern VM systems [Unix/Linux/etc.] do a *great* job
> of sharing mmap'd file segments, so much so that even with, say,
> CMUCL's largish core file of ~25 MB [more, if you save out a core
> image with your most popular libraries in it], because it mmap's its
> core into memory and the O/S caches that across invocations, CMUCL's
> startup time for the 2nd & subsequent executions can actually be *faster*
> than smaller systems [e.g., the much-smaller CLISP], to wit:
>
> $ cat test_cmucl # [Note 1]
> #!/usr/local/bin/cmucl -script
> (format t "Hello, world!~%")
> $ /usr/bin/time ./test_cmucl
> Hello, world!
> 0.01 real 0.00 user 0.00 sys
> $ time-hist ./test_cmucl
> Timing 100 runs of: ./test_cmucl
> 4 0.011
> 89 0.012
> 7 0.013
> 1.285u 1.255s 0:02.57 98.4% 224+1763k 0+0io 0pf+0w
> $
>
> Yes, that's only 11-13 milliseconds. *Plenty* fast for human-scale
> response times. As a result, I use CMUCL for all *kinds* of small
> "shell scripting" stuff":
>
> $ file ~/bin/* | grep 'cmucl.*script' | wc -l
> 47
> $
>
> Specifically, "csq" is a small (40-line) script to convert
> broadband cell modem AT+CSQ responses to dBm and vice-versa:
>
> $ wc bin/csq
> 40 178 1429 bin/csq
> $ csq
> usage: /u/rpw3/bin/csq { +csq | -dBm | :CSQ | :DBM }
> $ csq 18
> AT+CSQ 18 = -77 dBm ==> 3 bars, "satisfactory (17-21)"
> $ csq -63
> AT+CSQ 25 = -63 dBm ==> 4 bars, "quite good (22-26)"
> $ csq :dbm
> AT+CSQ 4 = -105 dBm ==> 0 bars, "no signal (0-6)"
> AT+CSQ 6 = -100 dBm ==> 1 bar, "borderline unusable (7-11)"
> AT+CSQ 9 = -95 dBm ==> 1 bar, "borderline unusable (7-11)"
> AT+CSQ 12 = -90 dBm ==> 2 bars, "weak, reduced throughput (12-16)"
> AT+CSQ 14 = -85 dBm ==> 2 bars, "weak, reduced throughput (12-16)"
> AT+CSQ 16 = -80 dBm ==> 3 bars, "satisfactory (17-21)"
> AT+CSQ 19 = -75 dBm ==> 3 bars, "satisfactory (17-21)"
> AT+CSQ 22 = -70 dBm ==> 4 bars, "quite good (22-26)"
> AT+CSQ 24 = -65 dBm ==> 4 bars, "quite good (22-26)"
> AT+CSQ 26 = -60 dBm ==> 5 bars, "exceptionally strong (27+)"
> $
>
> Or a stub/idiot version of an HTTP client:
>
> $ wc bin/http-get
> 189 886 7283 bin/http-get
> $ http-get -q http://rpw3.org/~rpw3/sample.txt # "-q" quiets headers
> Nothing to see here, move along, move along...
> $ http-get -H www.google.com # "-H" says do "HEAD", not "GET".
> HEAD / HTTP/1.0
> Host: www.google.com
>
> HTTP/1.0 200 OK
> Cache-Control: private, max-age=0
> Date: Fri, 11 Jul 2008 09:06:08 GMT
> Expires: -1
> Content-Type: text/html; charset=ISO-8859-1
> Set-Cookie: PREF=ID=72c19595acd948db:TM=1215767168:LM=1215767168:S=LKcYtKTH_bqJo_zt; expires=Sun, 11-Jul-2010 09:06:08 GMT; path=/; domain=.google.com
> Server: gws
> Content-Length: 0
> Connection: Close
> $
>
> Or a script that, hard-linked to different names, converts temperatures
> depending on its name?
>
> $ ls -il bin/?2?
> 1507459 -rwxr-xr-x 1 rpw3 rpw3 819 Jul 7 2005 bin/c2f
> 1507459 -rwxr-xr-x 1 rpw3 rpw3 819 Jul 7 2005 bin/f2c
> 1507459 -rwxr-xr-x 1 rpw3 rpw3 819 Jul 7 2005 bin/k2c
> $ c2f 25
> 77.0
> $ f2c 95
> 35.0
> $ k2c 77
> -196.16
> $
>
> Is that the sort of "smallish-looking scripts playing nicely with an O/S"
> you meant?!? ;-}
>
> +---------------
> | Hosted environments like Java and .NET can have a in memory, running vm
> | waiting to run applications. A lisp could provide a running image--
> | effectively a runtime environment, to do the same thing. However, there
> | is no separation between the data provided by the runtime and the data
> | used by the program. After the program is "done" The lisp image is in a
> | modified state.
> +---------------
>
> That's up to how you write your apps. If you write them to *not* mutate
> global state, then the persistent Lisp image will (eventually) GC whatever
> allocated data got left behind and you'll be good as new again.
>
> Also, Common Lisp gets used a *LOT* as either a web server proper
> [CL-HTTP, AllegroServe, Araneida, etc.] or as a persistent web
> applications daemon behind some web server such as Apache [UCW,
> Hunchentoot, cl-weblocks, etc., using mod_lisp or FastCGI or
> equiv. as a connector], see <http://www.cliki.net/web> for *lots*
> of that kind of stuff. Such web servers & applications servers
> tend to run nicely for many months without having problems with
> "accumulating state".
>
>
> -Rob
>
> [1] This uses my "-script" add-on to CMUCL to support "#!" scripts:
>
> http://rpw3.org/hacks/lisp/site-switch-script.lisp
>
> -----
> Rob Warnock <····@rpw3.org>
> 627 26th Avenue <URL:http://rpw3.org/>
> San Mateo, CA 94403 (650)572-2607
--
http://lispm.dyndns.org/
Rainer Joswig <······@lisp.de> wrote:
+---------------
| ····@rpw3.org (Rob Warnock) wrote:
| > $ cat test_cmucl # [Note 1]
| > #!/usr/local/bin/cmucl -script
| > (format t "Hello, world!~%")
| > $ /usr/bin/time ./test_cmucl
| > Hello, world!
| > 0.01 real 0.00 user 0.00 sys
| > $
...
| > [1] This uses my "-script" add-on to CMUCL to support "#!" scripts:
| > http://rpw3.org/hacks/lisp/site-switch-script.lisp
|
| Rob, it would be cool if you could collect all those nifty
| tricks^h^h^h^h^hmagic and publish something about it sometime.
+---------------
To some extent, I've already started, see <http://rpw3.org/hacks/lisp/>,
and *am* [albeit way too slowly, sorry!] planning on cleaning up and
more fully populating my nearly-empty website. [Soon, soon!]
The main "trick"[1] for convenient CMUCL "scripting" is the
"site-switch-script" hack.[2] Most everything else is just the sort
of "one-liner" personalizations any programmer carries around from
O/S to O/S and language to language over the years, and little things
like a "peek-poke" library that just gives to low-level access to
machine-code "load" & "store" and O/S "mmap()". *That* one I've
moved from C to Tcl to Scheme and, most recently, to CL (CMUCL),
always in support of user-mode hardware development/debugging.
[I can publish the CMUCL variant, if anyone cares.]
The only other generally-useful trick for CL scripting that I can
think of at the moment is to make your "main" function use keywords,
and then call it in the script this way [or, mutatis mutandis, however
your CL scripting command-line args]:
#!/usr/local/bin/cmucl -script
...[DEFUN/REQUIRE/LOAD/ASDF whatever you need]...
(defun main (&key ...whatever [incl. defaults]...)
...)
(unless *script-exit-hooks* ; Debugging?
(apply 'main (mapcar #'read-from-string *script-args*)))
This gives you a dirt-simple "getopt()"-euivalent for free!
E.g., I used this in a script which calculates R-C time constants:
$ time-constant :r 10e3 :c 4.7e-6 :v0 0 :vcc 5 :v 3
0.043065663 s to reach 3 V
$ time-constant :r 10e3 :c 4.7e-6 :v0 0 :vcc 5 :time 40e-3
2.8651977 V after 0.04 s
$ time-constant :rc .047 :v0 0 :vcc 5 :time 40e-3
2.8651977 V after 0.04 s
$ time-constant :v0 0 :vcc 5 :time 40e-3
0.19605255 V after 0.04 s
$
Note that :RC defaults to (* R C), and :R & :C are defaulted to 1
[so :RC defaults to 1 if neither :R nor :C are specified], but the
others aren't. Whether you're asking for "time until voltage" or
"voltage after time" is determined by which of :V or :TIME are given.
The rest of those 47 or so CMUCL scripts were just more of the same
little personal tools, the sort that everybody writes [don't they?!?]
in *some* scripting language. I just happen to prefer CL these days
for that, when it's reasonable. Note: I'm not fanatic; I use other
scripting languages, and don't re-code things just to change language.
Here's a rough breakdown of things in my current "~/bin/" directory
["file ~/bin/* | grep executable | sort | uniq -c | sort -rn" then edit]:
130 Bourne shell script text executable
45 /usr/local/bin/cmucl -script script text executable
22 /usr/local/bin/mzscheme -r script text executable
12 ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD)
7 perl script text executable
5 /usr/local/bin/clisp script text executable
3 /usr/local/bin/elk -l script text executable
3 FreeBSD/i386 compact demand paged dynamically linked executable (*OLD!*)
2 new awk script text executable
2 C shell script text executable
1 tcl -f script text executable
1 zsh script text executable
1 ELF 64-bit LSB executable, AMD x86-64, version 1 (FreeBSD)
Most of those 130 Bourne shell scripts are old, really, *really* old!! ;-}
Many date back to the mid-1980s and early 1990s. And the MzScheme
scripts are all from the '90s [since I switched to CL circa 2000].
My one larger work that I've intended to publish for some time but
haven't yet is my "appsrv" web application server infrastructure,
see <http://rpw3.org/hacks/lisp/appsrv-demo.lhp>, which I haven't
rushed because: (1) there are unfortunately a few remnants of the
somewhat proprietary application it was initially written to support
that haven't been sanitized yet; (2) even though "appsrv" was written
in 2002, well before many of the others at <http://www.cliki.net/web>,
because of point #1 it's been left in the dust, as it were, by the
progress of others [cl-modlisp, Hunchentoot, cl-weblocks, etc.];
(3) it wasn't all that featureful in the first place -- "just another
mod_lisp-using app" [though it didn't use "mod_lisp" per se, see
<http://rpw3.org/hacks/lisp/cgi_sock.c>]; and, finally, (4) it was
my very first largish, "production" Common Lisp application [though
I had been using Scheme for a decade], so in retrospect the code
really stinks in places. [Though it's been *very* solid, no serious
bugs in the infrastructure code in the last 5 years!]
+---------------
| I guess a little tutorial of yours at some Lisp event would
| also be very educational. I always enjoy reading your posts!
+---------------
Well, thanks! (*blush*)
I do plan on being at ILC 2009, but I'm somewhat doubtful a whole
"tutorial" could be built out of my little hodgepodge of personal
hacks [though if I'm wrong, feel free to try to convince me], which
are mostly quite CMUCL-specific in any case. Maybe what would work
better is some sort of multi-presenter "hacks" poster session,
where a half-dozen people -- hopefully at least one for every major
CL implementation -- scrawl a bunch of flip-chart sheets with one
hack per sheet and then post them up on the wall next to them.
That is, a mini-"exhibit hall" of hacks, with one "booth" [part of
a wall] per CL implementation and (at least) one person standing there
to explain/discuss/argue the hacks related to that implementation.
We'd also need several flip-charts for people to write/post new hacks
during the session, and the presenter(s) would have to promise to
write up such improve hacks for later posting on the ALU website
[since they'd be too late for the proceedings]. Does that sound
worthwhile?
-Rob
[1] No, you were right, my CMUCL "#!" hack *is* "deep magic". ;-}
But I tried very hard to allow it to be used *without*
anyone having to grok the magic, in most cases.
See <http://rpw3.org/hacks/lisp/site-switch-script.lisp>
for the gory, ugly, grotesque details, if you must! ;-} ;-}
Writing that involved wading around in the sewer that is
the CMUCL function SAVE-LISP (in "src/code/save.lisp") and
figuring out how to subvert the normal command line parsing
code: (1) to allow command line options of "#!" scripts to be
passed to the script code; (2) to suppress CMUCL's built-in
command line parser from seeing them; and (3) to pervert CMUCL's
built-in command line handling to get around the re-binding of
many specials that's done during the LOAD of the "site-init" code
[which in turn loads "site-switch-script"] and to provide a hook
for running user code in the normal *outer* binding context after
the LOAD of the user script finishes [see all the *SCRIPT-EXIT-HOOKS*
stuff near the end of "site-switch-script"].
I'm not sure that anyone but me will ever use it this way
[though *I* use it this way a lot!], but if you want your
script to set up a bunch of stuff and then drop into a normal
REPL, do this:
#!/usr/local/bin/cmucl -script
...[DEFUN/REQUIRE/LOAD/ASDF whatever you need]...
(setf *prompt* #|<|# "my-custom-prompt> ") ; [Optional]
(push :repl *script-exit-hooks*) ; Drop into normal REPL
[2] Yes, I've been talking to Carl Shapiro about whether or how to
get the "#!" hack [or equiv.] into the standard CMUCL distribution.
As you can see from the code, there's *lots* of room for conflicting
opinions over what "doing it right" might mean. ;-}
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) wrote on Fri, 11 Jul 2008:
> [2] Yes, I've been talking to Carl Shapiro about whether or how to
> get the "#!" hack [or equiv.] into the standard CMUCL distribution.
> As you can see from the code, there's *lots* of room for conflicting
> opinions over what "doing it right" might mean. ;-}
I would definitely support this effort.
Given the popularity of the unix/lisp combination, and the popularity of
"shell" scripting on unix, doing #! in lisp is a high-value addition.
Is there anything an outsider like me could do, to assist you and/or Carl
in adding this functionality?
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
Jane: Daria? Come on, the neighbors are starting to talk.
Daria: Um...good. Soon they'll progress to cave drawings and civilization
will be on its way.
Don Geddis <···@geddis.org> wrote:
+---------------
| ····@rpw3.org (Rob Warnock) wrote on Fri, 11 Jul 2008:
| > [2] Yes, I've been talking to Carl Shapiro about whether or how to
| > get the "#!" hack [or equiv.] into the standard CMUCL distribution.
| > As you can see from the code, there's *lots* of room for conflicting
| > opinions over what "doing it right" might mean. ;-}
|
| I would definitely support this effort.
|
| Given the popularity of the unix/lisp combination, and the popularity of
| "shell" scripting on unix, doing #! in lisp is a high-value addition.
|
| Is there anything an outsider like me could do, to assist you and/or Carl
| in adding this functionality?
+---------------
Grab a copy of <http://rpw3.org/hacks/lisp/site-switch-script.lisp>,
follow the "Installation & usage:" instructions in the comments,
use it a while, and then let me know what's good or not so good
about it. And if not so good, how you'd propose to improve it.
I've been using it *heavily* since I wrote it in late 2003, and have
made only two small tweaks[1] since then, so I consider it quite stable,
at least for the things *I* tend to do. But more eyes would be helpful...
And, oh, the one thing I've been thinking about adding as a builtin
(but overrideable) default -- is to exit on ^C (SIGINT) rather than
drop into the debugger. I've tended to add it as the end of a number
of my scripts, like so:
(defun my-sigint (signal code scp)
(declare (ignore signal code scp))
(unix:unix-exit 1)
(error "Unix-exit failed to exit!"))
(unless *script-exit-hooks* ; Debugging?
;; This program is usually used from the shell, where the most
;; commonly-desired behavior upon receiving SIGINT is to simply exit.
(system:with-enabled-interrupts ((unix:sigint #'my-sigint))
(main)))
but it probably should be done for everybody in "site-switch-script" [but
using SYSTEM:ENABLE-INTERRUPT rather than SYSTEM:WITH-ENABLED-INTERRUPTS].
I look forward to your comments after you've used it for a while.
-Rob
[1] 1. Add *GC-VERBOSE* and *COMPILE-VERBOSE* to the set of symbols
bound to NIL during script execution.
2. Replace the [no longer present] "-fasl" option with slightly
more smarts in "-script", so that "-script" can be used with
either CL source or CMUCL FASLs.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) wrote on Sat, 12 Jul 2008:
> Don Geddis <···@geddis.org> wrote:
> | Is there anything an outsider like me could do, to assist you and/or Carl
> | in adding this functionality?
>
> Grab a copy of <http://rpw3.org/hacks/lisp/site-switch-script.lisp>
OK, done.
> use it a while, and then let me know what's good or not so good
> about it. And if not so good, how you'd propose to improve it.
Will do.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
The climate of Bombay is such that its inhabitants have to live elsewhere.
In article <································@speakeasy.net>,
····@rpw3.org (Rob Warnock) wrote:
Thanks for the stuff...
> I do plan on being at ILC 2009, but I'm somewhat doubtful a whole
> "tutorial" could be built out of my little hodgepodge of personal
> hacks [though if I'm wrong, feel free to try to convince me], which
> are mostly quite CMUCL-specific in any case. Maybe what would work
> better is some sort of multi-presenter "hacks" poster session,
> where a half-dozen people -- hopefully at least one for every major
> CL implementation -- scrawl a bunch of flip-chart sheets with one
> hack per sheet and then post them up on the wall next to them.
> That is, a mini-"exhibit hall" of hacks, with one "booth" [part of
> a wall] per CL implementation and (at least) one person standing there
> to explain/discuss/argue the hacks related to that implementation.
> We'd also need several flip-charts for people to write/post new hacks
> during the session, and the presenter(s) would have to promise to
> write up such improve hacks for later posting on the ALU website
> [since they'd be too late for the proceedings]. Does that sound
> worthwhile?
Can't talk about other people, but I'm always interested to
learn about ''clever' 'hacks''. There are often a lot of
presentations about changing the world and so on. I'd also be
interested in hearing about changing the bytes, bits and
sub-bits. ;-) Having more hackers presenting Lisp hacks would
be fun - IMHO.
--
http://lispm.dyndns.org/
On Jul 11, 10:04 pm, ····@rpw3.org (Rob Warnock) wrote:
>
> I do plan on being at ILC 2009, but I'm somewhat doubtful a whole
> "tutorial" could be built out of my little hodgepodge of personal
> hacks [though if I'm wrong, feel free to try to convince me], which
> are mostly quite CMUCL-specific in any case. Maybe what would work
> better is some sort of multi-presenter "hacks" poster session,
> where a half-dozen people -- hopefully at least one for every major
> CL implementation -- scrawl a bunch of flip-chart sheets with one
> hack per sheet and then post them up on the wall next to them.
> That is, a mini-"exhibit hall" of hacks, with one "booth" [part of
> a wall] per CL implementation and (at least) one person standing there
> to explain/discuss/argue the hacks related to that implementation.
> We'd also need several flip-charts for people to write/post new hacks
> during the session, and the presenter(s) would have to promise to
> write up such improve hacks for later posting on the ALU website
> [since they'd be too late for the proceedings]. Does that sound
> worthwhile?
>
> -Rob
We should definitely do something like this! I've been thinking about
different possible formats for this kind of thing, and what you're
proposing is an interesting idea. Maybe it could be one of the "birds
of a feather" sessions. So I should look into finding a source of
flip charts. It's on my list.
-- Dan