AllegroServe on other Lisp implementations

2000-09-15
2001-09-03
  • Chris Double

    Chris Double - 2000-09-15

    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

     
    • John Foderaro

      John Foderaro - 2000-09-16

      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.

       
      • Chris Double

        Chris Double - 2000-09-16

        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

         
    • Espen Vestre

      Espen Vestre - 2000-10-09

      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.

       
      • Espen Vestre

        Espen Vestre - 2000-10-09

        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??)

         
    • Leon Roos van Raadshooven

      There seems to be a new project on sourceforge: http://sourceforge.net/projects/portableaserve

       

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks