I've managed to get some of AllegroServe 1.1.25 working on Corman Lisp. Is there any interest from the AllegroServe developers on comments about what was involved in porting to another Lisp? If so, I'll write something up.
Is it ok for me to provide a distribution from my website of a modified AllegroServe to run with Corman Lisp?
Not all the functionality is implemented but it allows publishing files, computed entities, etc. The multiprocessing and simple servers both work.
Congratuations on getting AllegroServe working in Corman Lisp. You asked
about what to do with your changes to the source and I'd like
to answer your questions (as well as others who have wondered about
this issue).
Let me start way back at the beginning with the two main goals I had in
writing AllegroServe.
1. Write an industrial strength web server that could compete in reliablity
and speed against the best currently out there, and that could better
them in dynamic page generation capability through use of a serious
programming language (Lisp) over a toy scripting language.
2. Show by example how to do network and multi-threaded programming in
Allegro CL. When you go to a bookstore you don't see a wall full of
books on network programming in Lisp. All the novice programmer gets
is a list of functions and he has to figure out the idioms for combining them.
With AllegroServe we can say, "This is one way of doing it we know works
in ACL." AllegroServe is written in a subset of CL that maximizes
readability. The hope is that AllegroServe is read by programmers and not
just run.
As for the issue of portability of AllegroServe between Lisps that
is neither a goal nor a non-goal. If portability were a goal then
AllegroServe would have been written much differently: I would have
written a layer to separate the Ansi from the non-Ansi parts.
That layer would have had well defined semantics so that in each
Lisp glue code could written to enable that lisp to plug into the
interface. This is do-able but it doesn't get me to either
of my goals:
1. portable programs work in the least common denominator of the
capabilties of the target platforms. I have a lot of control
over things I can add to ACL to make it achieve the speed/reliability
goal but I have no control over the other lisp implementations.
Likewise other Lisps may have special features that I can't make use of
since not all other Lisps have equivalent features.
2. It's easier to understand network programming for any single Lisp
than for an ad hoc abstraction layer on top of a set of Lisp implementations.
Thus my goal is better served by writing in the ACL network
and threads interface.
However I'm not opposed to porting AllegroServe to other Lisps and
have done quite a bit of work to make it possible, including
distributing the source via the LGPL and setting up a CVS repository.
This is how I had envisioned porting of AllegroServe to work:
A person who wants to port it to X-Lisp (for some X) checks out
a CVS tree for the current version. They eventually get it
to work. They they advertise that they have that version ported
for X-Lisp and put it on a web site. They handle the port-specific
bug reports if they have the time. Meanwhile I continue
to upgrade and publish the ACL version on the sourceforge
site. When the porter wants to upgrade their port to the latest
ACL version they "cvs update -d" and the latest changes I've
made are merged into their source tree. When there are conflicts
they are noted by CVS and the porter has to deal with each one
of them, and then with porting issues from the changes I made.
When the port again works the porter announces a new version.
Thus in this scenario I can publish new ACL versions without worrying
that it will now cease to work on any other port (since the official
versions for the other ports are stored on different web sites).
Users of each X-Lisp can find a version that will work on their machine.
It may not be the latest version but it will be a working version.
As for where to put the versions for the other ports, it would be simplest
if you used web or ftp space that you control. However if you don't
have any I can store the files on SourceForge. I can also put
pointers to web sites on the AllegroServe project page so people
can find the other versions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your reply. I agree with your comments and the distribution of a seperate version sounds like a good idea. My port of AllegroServe is still incomplete but I plan to make what I've done available for Corman Lisp users. Maybe it will get people interested in the capability of a full Lisp like Allegro and encourage purchasing of that to get all the functionality of ACL and Allegroserve.
Incidentally there wasn't much involved in the port. Most of the code was nicely portable anyway. Most of what I did was implement wrappers that emulated certain Allegro libraries like URI, some of EXCL, MP, etc. The remainder of AllegroServe compiled without much difficulty (except for uncovering bugs in Corman Lisp :-)
A big thank you to Franz for Open Sourcing AllegroServe, and your LHTML, XML libraries too!
If you build applications with generate-application and include :restart-app-function (a useful function for starting up aserve and whatever other daemons you may want to run should be put here) but not :restart-init-function, you will get an image that has no initial top-level listener.
That works fine for me, we use this for runtime images all the time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oops, sorry I was toggling to quick between different windows, this was supposed to be in the help forum, I'll repost it there. (isn't there any way to remove articles here??)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've managed to get some of AllegroServe 1.1.25 working on Corman Lisp. Is there any interest from the AllegroServe developers on comments about what was involved in porting to another Lisp? If so, I'll write something up.
Is it ok for me to provide a distribution from my website of a modified AllegroServe to run with Corman Lisp?
Not all the functionality is implemented but it allows publishing files, computed entities, etc. The multiprocessing and simple servers both work.
Chris.
--
http://www.double.co.nz/cl
Congratuations on getting AllegroServe working in Corman Lisp. You asked
about what to do with your changes to the source and I'd like
to answer your questions (as well as others who have wondered about
this issue).
Let me start way back at the beginning with the two main goals I had in
writing AllegroServe.
1. Write an industrial strength web server that could compete in reliablity
and speed against the best currently out there, and that could better
them in dynamic page generation capability through use of a serious
programming language (Lisp) over a toy scripting language.
2. Show by example how to do network and multi-threaded programming in
Allegro CL. When you go to a bookstore you don't see a wall full of
books on network programming in Lisp. All the novice programmer gets
is a list of functions and he has to figure out the idioms for combining them.
With AllegroServe we can say, "This is one way of doing it we know works
in ACL." AllegroServe is written in a subset of CL that maximizes
readability. The hope is that AllegroServe is read by programmers and not
just run.
As for the issue of portability of AllegroServe between Lisps that
is neither a goal nor a non-goal. If portability were a goal then
AllegroServe would have been written much differently: I would have
written a layer to separate the Ansi from the non-Ansi parts.
That layer would have had well defined semantics so that in each
Lisp glue code could written to enable that lisp to plug into the
interface. This is do-able but it doesn't get me to either
of my goals:
1. portable programs work in the least common denominator of the
capabilties of the target platforms. I have a lot of control
over things I can add to ACL to make it achieve the speed/reliability
goal but I have no control over the other lisp implementations.
Likewise other Lisps may have special features that I can't make use of
since not all other Lisps have equivalent features.
2. It's easier to understand network programming for any single Lisp
than for an ad hoc abstraction layer on top of a set of Lisp implementations.
Thus my goal is better served by writing in the ACL network
and threads interface.
However I'm not opposed to porting AllegroServe to other Lisps and
have done quite a bit of work to make it possible, including
distributing the source via the LGPL and setting up a CVS repository.
This is how I had envisioned porting of AllegroServe to work:
A person who wants to port it to X-Lisp (for some X) checks out
a CVS tree for the current version. They eventually get it
to work. They they advertise that they have that version ported
for X-Lisp and put it on a web site. They handle the port-specific
bug reports if they have the time. Meanwhile I continue
to upgrade and publish the ACL version on the sourceforge
site. When the porter wants to upgrade their port to the latest
ACL version they "cvs update -d" and the latest changes I've
made are merged into their source tree. When there are conflicts
they are noted by CVS and the porter has to deal with each one
of them, and then with porting issues from the changes I made.
When the port again works the porter announces a new version.
Thus in this scenario I can publish new ACL versions without worrying
that it will now cease to work on any other port (since the official
versions for the other ports are stored on different web sites).
Users of each X-Lisp can find a version that will work on their machine.
It may not be the latest version but it will be a working version.
As for where to put the versions for the other ports, it would be simplest
if you used web or ftp space that you control. However if you don't
have any I can store the files on SourceForge. I can also put
pointers to web sites on the AllegroServe project page so people
can find the other versions.
Thanks for your reply. I agree with your comments and the distribution of a seperate version sounds like a good idea. My port of AllegroServe is still incomplete but I plan to make what I've done available for Corman Lisp users. Maybe it will get people interested in the capability of a full Lisp like Allegro and encourage purchasing of that to get all the functionality of ACL and Allegroserve.
Incidentally there wasn't much involved in the port. Most of the code was nicely portable anyway. Most of what I did was implement wrappers that emulated certain Allegro libraries like URI, some of EXCL, MP, etc. The remainder of AllegroServe compiled without much difficulty (except for uncovering bugs in Corman Lisp :-)
A big thank you to Franz for Open Sourcing AllegroServe, and your LHTML, XML libraries too!
Cheers,
Chris.
--
http://www.double.co.nz/cl
If you build applications with generate-application and include :restart-app-function (a useful function for starting up aserve and whatever other daemons you may want to run should be put here) but not :restart-init-function, you will get an image that has no initial top-level listener.
That works fine for me, we use this for runtime images all the time.
Oops, sorry I was toggling to quick between different windows, this was supposed to be in the help forum, I'll repost it there. (isn't there any way to remove articles here??)
There seems to be a new project on sourceforge: http://sourceforge.net/projects/portableaserve