From: Bob Bradlee
Subject: Using newlisp for cgi based intranet ?
Date:
Message-ID: <3A2DBA1C.1E3A308F@CAVE.NET>
I am considering using newlisp http://www.newlisp.org as the glue language
for a web based information management and distribution system.
I have written numerous applications in autolisp using Autocad as my GUI.
My partner in this project is an ANSI C programmer who has played with CL.
Our latest attempt with perl resulted in both a working demo and a strong
desire for a (mapcar `lambda .... :)
Are there any cgi examples or links that I should be aware of?
Is there anyone out there using newlisp for cgi applications?
Should I avoid using newlisp for any reason I am not aware of?
Email response is welcome.
···@cave.net
"Bob Bradlee" <···@CAVE.NET> wrote in message
······················@CAVE.NET...
> I am considering using newlisp http://www.newlisp.org as the glue language
> for a web based information management and distribution system.
> I have written numerous applications in autolisp using Autocad as my GUI.
> My partner in this project is an ANSI C programmer who has played with CL.
> Our latest attempt with perl resulted in both a working demo and a strong
> desire for a (mapcar `lambda .... :)
>
> Are there any cgi examples or links that I should be aware of?
Generally cgi is not considered the best way to use Lisp for web
applications.
There are more efficient and common ways to do this :
-Use a Lisp HTTP server (there are lots of them, from small simple ones to
huge ones)
-Use an interface behind the Apache web server. (some use JServ, I used
mod_python but now I've written a mod_lisp)
> Is there anyone out there using newlisp for cgi applications?
>
> Should I avoid using newlisp for any reason I am not aware of?
Why would you use a non standard (no garbage collector!) Lisp like when you
can use a real full featured lisp.
Look at the different HTML generating macros that are around there and look
if you can have the same power with newlisp.
Marc
From: Dr Nick Levine
Subject: Re: Using newlisp for cgi based intranet ?
Date:
Message-ID: <3A2E3D28.99FC57@anglia.ac.uk>
> -Use an interface behind the Apache web server. (some use JServ, I used
> mod_python but now I've written a mod_lisp)
Are any details of the mod_lisp available?
- nick
>> > > -Use an interface behind the Apache web server. (some use JServ, I used
>> > > mod_python but now I've written a mod_lisp)
>> >
>> > Are any details of the mod_lisp available?
>>
>> For now it's just a quick hack to use LispWorks with Apache.
>> It's based on a simple socket protocol from Apache to LW.
>> The protocol is really straightforward but Lisp friendly:
>> Apache opens a socket on LW
>> It sends the CGI and Apache variables to LW
>> LW sends back the header variables
>> LW sends the response if any.
>> LW closes the socket.
This is incredibly close to the functionality of the glue layer I wrote
with CGI/C.
I would claim that what you have written is more general than mod_lisp -
it's more of a mod_socket - Apache uses a socket on localhost to pass
its inputs on to some other named executable (which should already be
running), reads the results back over the socket and passes that to the
user. Nothing about that requires the "named executable" to be a lisp.
I had imagined that you had implemented code to link in a lisp
executable (eg on Windows a lisp dll) with the Apache and make direct
function calls into the server code. I guess if you were doing that, the
details would be so vendor-specific that you'd end up with a
mod_lispworks and a mod_allegro and so on.
>> It works well so far but I want to clean and polish it a little bit before
>> making it available, but time is such a scarce resource....
>>
>> For instance to send the variables the protocol is
>> (<variable name><cr><variable value><cr>)* <end>
>>
>> it's convenient as I just do a read-line in lisp but can be easily broken.
>> I think I will change it to :
>> (<variable name><cr><variable size in ascii text><cr><variable value(size
>> octets)>)* <end>
>>
>> Comments welcome.
If the values come through encoded (ie
application/x-www-form-urlencoded) then your first approach is fine, I
would have thought. This will always (afaik) be the case for GET
requests. I have never bothered with POSTs and don't know offhand
whether the contents are urlencoded - if they are not then there will in
general be embedded #\Newlines and then you will need your revised
approach.
Btw, you day "LW closes the socket." I can't remember the protocol for
whether the client or the server is supposed to close the connection,
but I mention this in case you haven't taken that into account.
I would be interested in seeing your code.
- nick
"Dr Nick Levine" <········@anglia.ac.uk> wrote
>
> > -Use an interface behind the Apache web server. (some use JServ, I used
> > mod_python but now I've written a mod_lisp)
>
> Are any details of the mod_lisp available?
For now it's just a quick hack to use LispWorks with Apache.
It's based on a simple socket protocol from Apache to LW.
The protocol is really straightforward but Lisp friendly:
Apache opens a socket on LW
It sends the CGI and Apache variables to LW
LW sends back the header variables
LW sends the response if any.
LW closes the socket.
It works well so far but I want to clean and polish it a little bit before
making it available, but time is such a scarce resource....
For instance to send the variables the protocol is
(<variable name><cr><variable value><cr>)* <end>
it's convenient as I just do a read-line in lisp but can be easily broken.
I think I will change it to :
(<variable name><cr><variable size in ascii text><cr><variable value(size
octets)>)* <end>
Comments welcome.
Marc
Dr Nick Levine" <········@anglia.ac.uk> wrote:
> >> > > -Use an interface behind the Apache web server. (some use JServ, I
used
> >> > > mod_python but now I've written a mod_lisp)
> >> >
> >> > Are any details of the mod_lisp available?
> >>
> >> For now it's just a quick hack to use LispWorks with Apache.
> >> It's based on a simple socket protocol from Apache to LW.
> >> The protocol is really straightforward but Lisp friendly:
> >> Apache opens a socket on LW
> >> It sends the CGI and Apache variables to LW
> >> LW sends back the header variables
> >> LW sends the response if any.
> >> LW closes the socket.
>
> This is incredibly close to the functionality of the glue layer I wrote
> with CGI/C.
>
> I would claim that what you have written is more general than mod_lisp -
> it's more of a mod_socket - Apache uses a socket on localhost to pass
> its inputs on to some other named executable (which should already be
> running), reads the results back over the socket and passes that to the
> user. Nothing about that requires the "named executable" to be a lisp.
Yes, In fact I started from mod_JServ to make mod_lisp.
> I had imagined that you had implemented code to link in a lisp
> executable (eg on Windows a lisp dll) with the Apache and make direct
> function calls into the server code. I guess if you were doing that, the
> details would be so vendor-specific that you'd end up with a
> mod_lispworks and a mod_allegro and so on.
No they are lots of reasons to not link the lisp in Apache.
-I want to be able to use my lisp environment. (listener, debugger, etc....)
-Load balancing. One apache server, many Lisp application servers
-Memory used. Apache spawn processes if lisp is linked it will be in each
process
-Portability. To be able to replace Apache by any other web server (even IIS
if really needed)
> >> It works well so far but I want to clean and polish it a little bit
before
> >> making it available, but time is such a scarce resource....
> >>
> >> For instance to send the variables the protocol is
> >> (<variable name><cr><variable value><cr>)* <end>
> >>
> >> it's convenient as I just do a read-line in lisp but can be easily
broken.
> >> I think I will change it to :
> >> (<variable name><cr><variable size in ascii text><cr><variable
value(size
> >> octets)>)* <end>
> >>
> >> Comments welcome.
>
> If the values come through encoded (ie
> application/x-www-form-urlencoded) then your first approach is fine, I
> would have thought. This will always (afaik) be the case for GET
> requests. I have never bothered with POSTs and don't know offhand
> whether the contents are urlencoded - if they are not then there will in
> general be embedded #\Newlines and then you will need your revised
> approach.
>
> Btw, you day "LW closes the socket." I can't remember the protocol for
> whether the client or the server is supposed to close the connection,
> but I mention this in case you haven't taken that into account.
I close the socket to mod_lisp so that he knows the output is finished. This
does not close the apache->browser connection.
> I would be interested in seeing your code.
I will make it an alpha version available real soon. I just need to test it
under FreeBSD (I'm a recent convert)
Marc
Hi Bob,
I had never heard of newlisp before. Looks ivery nteresting
(introduction from http://www.nuevatec.com/newlisp/newlisp_manual.html
cited in full below) - but then all experiments derived from lisp are
(to my mind) interesting. There are so many major differences between
this and CL that it's a very different language indeed - you will indeed
get many of the features that make Comomn lisp such a pleasure to use
but equally you'll be lacking many others. The introduction claims many
of the changes are for efficiency or simplicity. Be warned: call by
value will have speed implications for long list structures. I wondered
about other types of structure, and then I realised: newlisp doesn't
have any. No vectors / arrays, no hash-tables, no user-defined structure
types. You won't get anywhere writing large applications with a language
which is that badly hobbled. But for sreally mall jobs it may be fine.
In any case I'm not quite sure what you meant by "glue" language. I can
envisage one scenario: where you write the main CGI handler in something
more up to the task (eg CL) and have a standard server (eg Apache)
handle the full niceties of HTTP. Then you need some light-weight client
to communicate between the two. The client does need to have a small
footprint (unlike the CGI application, which only ever has one
instantiation and so can be several MB and nobody will ever care),
because each active connection will cause Apache to fire off another
client which remains alive until that request has been served. (The
client then makes simple socket connections to the main server.) I
experimented with just this a few months back - using a commercial CL
with "off the shelf" run-time delivery techniques I could generate a 3MB
for this client (too large) but the lisp was only 20 lines and it had
taken only 20 minutes to write and test. Cursing, I later rewrote the
code in C - took half a day; the code is 5 times as long; the executable
is 40k (BUT: it will undoubtedly link in several hunderd K of dll when
it starts up, so the difference isn't that great). Source for both
clients available on request.... Anyway, maybe newLISP would have been
fine for this - it appears to have good support for sockets, could be
faster to write than C, even taking the learning curve into account, and
might have reasonably fast startup times.
I should point out that there's another approach - write the entire
application in CL, basing the web side on the Common Lisp Hypertext
Server (CL-HTTP) - http://www.ai.mit.edu/projects/iiip/doc/cl-http/ .
You then have no need to front the HTTP handling with Apache, and no
need for any glue.
Hope this helps. I don't normally write large posts before I've been to
the coffee machine, but couldn't resist this one because it's an area
I've been dabbling in all year. Keep posting if this and other replies
haven't answered your questions.
- nick
newLISP is closer to Scheme than it is to Common LISP, but is also
different in some important aspects from both dialects of LISP. In
most cases the naming and working of built in functions is similar
to
ANSI Common LISP. A few namings for functions and their workings
are
borrowed from Scheme, others from the 'C' language. newLISP is
even
smaller than most Scheme implementations, but still has over 200
built
in functions.
Through the last versions newLISP for LINUX has evolved to a
language best used in conjunction with a web server for
scripting and writing net-bots. The only 69K size executable of
newLISP, using only the most common UNIX system C-libraries, has
a very fast load time and small memory foot print. It competes
in speed with other memory resident web application languages.
newLISP is dynamically scoped, like original LISP. For object
oriented programming and packaging of local states and
procedures newLISP introduces local state variables in lambda
expressions (note that, these are different from the lexical
closure mechanism in Scheme). User defined functions (Lambda
expressions) in newLISP may be manipulated like any other list
expression. Like Scheme newLISP also evaluates the operator
element of a list expression. No special forms are required for
assigning functions to variables.
newLISP can use different name spaces or 'contexts'. This
facilitates the development of bigger applications in newLISP
composed from different independent developed modules with their
own name spaces.
newLISP is free of garbage collection. Only under error
conditions newLISP needs to collect unused memory. This results
in predictive and repeatable processing times. Each object is
referenced only once in the system and passed always by value.
Intermediate evaluation results are automatically deleted from
memory as newLISP proceeds evaluating. The current variable
environment is dynamically saved and then restored to the
previous state, when leaving a lambda defined procedure. The
update of local state variables in lambda expressions is treated
as part of an transaction, which only takes place if the
function is completed without error.
Many of newLISP's built in functions are completely type
polymorph, accepting a variety, and sometimes all, data
types. This greatly reduces the total number of different
functions and syntactic forms necessary to learn and
implement. It gives newLISP the expressive power and elegance,
LISP if famous for. Although type polymorphism is traded for the
faster performance of native code compiled LISPs with type tags,
newLISP's speed is comparable or better than the speed of other
interactive programming languages.
newLISP is extensible via a shared library interface. Functions
from shared libraries are easily imported. The version 6.0
distribution contains a module for importing the MySQL database
API. A relational database seems a natural extension to LISP.
NewLISP's TCP/IP socket interface makes it easy to write
networked applications. Simple examples how to write network
clients and servers are included. newLISP's textprocessing
facilities include pattern matching and text parsing functions
functions. This make newLISP a useful tool for CGI processing on
web servers. An Example for HTML forms processing and a simple
web server written in newLISP is also included in this
distribution.
Bob Bradlee wrote:
>
> I am considering using newlisp http://www.newlisp.org as the glue language
> for a web based information management and distribution system.
> I have written numerous applications in autolisp using Autocad as my GUI.
> My partner in this project is an ANSI C programmer who has played with CL.
> Our latest attempt with perl resulted in both a working demo and a strong
> desire for a (mapcar `lambda .... :)
>
> Are there any cgi examples or links that I should be aware of?
>
> Is there anyone out there using newlisp for cgi applications?
>
> Should I avoid using newlisp for any reason I am not aware of?
>
> Email response is welcome.
>
> ···@cave.net
Dr Nick Levine <········@anglia.ac.uk> writes:
> In any case I'm not quite sure what you meant by "glue" language. I can
> envisage one scenario: where you write the main CGI handler in something
> more up to the task (eg CL) and have a standard server (eg Apache)
> handle the full niceties of HTTP. Then you need some light-weight client
> to communicate between the two.
Another approach is to make the apache->lisp protocol HTTP, and use
apache's builtin mod_proxy support to talk to the Lisp. It's easy to
write a web server if you know that only one kind of client will ever
be accessing it, and you don't have to worry about other people's tcp
stacks and so on. If you make the lisp process set Last-Modified and
handle If-Modified-Since headers properly you can probably even make
apache cache your content for you. That's what Araneida
(http://araneida.telent.net/) does, though it may be better treated as
a proof-of-concept rather than a production system.
You do lose the IP address of the client if you do that, though;
there's no way (that I've found, at least) to get mod_proxy to pass it.
Another other approach is to do what Onshore did with IMHO
(http://alpha.onshore.com/lisp-software/) and write something that
works as a client of apache's mod_jserv.
You might want to check out the lispweb mailing list - details at
http://www.red-bean.com/lispweb - for discussion of Lisp-based web
development. It's been a bit quiet lately, but it's often
interesting.
> Bob Bradlee wrote:
> > [...]
> > Our latest attempt with perl resulted in both a working demo and a strong
> > desire for a (mapcar `lambda .... :)
map { $_ * 2 } ( 1,2,3,4,5 );
Usually when I use Perl my most fervent wishes are for better gc,
lists which don't flatten automatically, and a syntax that emacs can
parse well enough to indent properly. But that's a topic for another place.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources