From: Yarden Katz
Subject: defsystem on Allegro CL
Date: 
Message-ID: <86y95srby1.fsf@underlevel.net>
Hi,

  Hopefully this question is not horribly off-topic.. the FAQ does
  seem to prohibit these types of questions, and a google search
  showed favorable response to a similar question.  I apologize if
  anyone finds this off-topic.
  
  I'm trying to run the IMHO environment <see
  http://www.cliki.net/IMHO> from onShored on my version
  of Allegro CL 6.2 using Debian (woody).  I loaded defsystem.lisp
  (from the cl-defsystem package), and then loaded the two .system
  files for IMHO: imho.system and odcl.system.  Both loaded correctly,
  but when I attempted to compile the package, the following occured:

  (mk:oos "IMHO" :compile)

;    - Source file /odcl/package.lisp and binary file /odcl/package.fasl not
;      found, not loading.
Error: 
Source file "/odcl/package.lisp" and binary file "/odcl/package.fasl"
       do not exist.

   I looked through both .system files but could not trace the
   problem.  The 'package.lisp' file exists in both the IMHO and ODCL
   source directories, that are located at /usr/share/common-lisp/source/imho
   and /usr/share/common-lisp/source/odcl respectively.  package.fasl
   does not exist, but I assume I can just compile package.lisp to
   create it.  Still, something in the system files must be wrong if
   package.lisp is not found (and if it looks for it in /odcl/).. here
   are the two relevant snippets from imho.system and odcl.system:

imho.system:

(in-package :cl-user)

(setf (logical-pathname-translations "imho")
      `(("**;*.*.*" "cl-library:;imho;")))

(mk:defsystem :imho
    :source-pathname "cl-library:imho;"
    :source-extension "lisp"
    :binary-pathname nil
    :binary-extension nil
    :components
    [...])

odcl.system:

(in-package :cl-user)

(mk:defsystem :odcl
    :source-pathname "cl-library:odcl;"
    :source-extension "lisp"
    :binary-pathname nil
    :binary-extension nil
    :components
    ((:file "package")
     #+sbcl (:file "sbcl"))
    [...])
  

  Does anyone know how this problem could be fixed, or clues as to
  what I should look into?  I appreciate all the help..

Thanks a lot!
-- 
Yarden Katz <····@underlevel.net>  |  Mind the gap

From: Thomas A. Russ
Subject: Re: defsystem on Allegro CL
Date: 
Message-ID: <ymik7hc8wif.fsf@sevak.isi.edu>
Yarden Katz <····@underlevel.net> writes:

BTW, this is a perfect question for this forum.

> imho.system:
> 
> (in-package :cl-user)
> 
> (setf (logical-pathname-translations "imho")
>       `(("**;*.*.*" "cl-library:;imho;")))

This logical translation refers to the logical pathname host
"cl-library", which is probably not defined.  One way to check
would be to start the lisp system, and where you run into 
problems making the system to try evaluating

  (logical-pathname-translations "cl-library")

in the listener or debugger prompt.  If it turns out that this
doesn't have a definition (or throws an error), then you will
need to provide a logical pathname definition for the cl-library
logical host.

From your message, it would appear that something along the
lines of

  (setf (logical-pathname-translations "cl-library")
      `((";**;*.*.*" "/usr/share/common-lisp/source/**/")))

would help.  Unfortunately, when I just tried this, it wasn't happy
with the first ";" in the form "cl-library:;imho;", (on ACL 5.0.1),
the form from below looks like it should work a bit better.  You may
need to check the vendor-specific documentation to get tweak the
form you need in order to get things exactly right, for this is an
area that is partly implementation-dependent.

> 
> (mk:defsystem :imho
>     :source-pathname "cl-library:imho;"
>     :source-extension "lisp"
>     :binary-pathname nil
>     :binary-extension nil
>     :components
>     [...])
> 
> odcl.system:
> 
> (in-package :cl-user)
> 
> (mk:defsystem :odcl
>     :source-pathname "cl-library:odcl;"
>     :source-extension "lisp"
>     :binary-pathname nil
>     :binary-extension nil
>     :components
>     ((:file "package")
>      #+sbcl (:file "sbcl"))
>     [...])



-- 
Thomas A. Russ,  USC/Information Sciences Institute          ···@isi.edu    
From: Edi Weitz
Subject: Re: defsystem on Allegro CL
Date: 
Message-ID: <87of6orc0m.fsf@bird.agharta.de>
Yarden Katz <····@underlevel.net> writes:

> Hi,
> 
>   Hopefully this question is not horribly off-topic.. the FAQ does
>   seem to prohibit these types of questions, and a google search
>   showed favorable response to a similar question.  I apologize if
>   anyone finds this off-topic.
>   
>   I'm trying to run the IMHO environment <see
>   http://www.cliki.net/IMHO> from onShored on my version
>   of Allegro CL 6.2 using Debian (woody).  I loaded defsystem.lisp
>   (from the cl-defsystem package), and then loaded the two .system
>   files for IMHO: imho.system and odcl.system.  Both loaded correctly,
>   but when I attempted to compile the package, the following occured:
> 
>   (mk:oos "IMHO" :compile)
> 
> ;    - Source file /odcl/package.lisp and binary file /odcl/package.fasl not
> ;      found, not loading.
> Error: 
> Source file "/odcl/package.lisp" and binary file "/odcl/package.fasl"
>        do not exist.
> 
>    I looked through both .system files but could not trace the
>    problem.  The 'package.lisp' file exists in both the IMHO and ODCL
>    source directories, that are located at /usr/share/common-lisp/source/imho
>    and /usr/share/common-lisp/source/odcl respectively.  package.fasl
>    does not exist, but I assume I can just compile package.lisp to
>    create it.  Still, something in the system files must be wrong if
>    package.lisp is not found (and if it looks for it in /odcl/).. here
>    are the two relevant snippets from imho.system and odcl.system:
> 
> imho.system:
> 
> (in-package :cl-user)
> 
> (setf (logical-pathname-translations "imho")
>       `(("**;*.*.*" "cl-library:;imho;")))
> 
> (mk:defsystem :imho
>     :source-pathname "cl-library:imho;"
>     :source-extension "lisp"
>     :binary-pathname nil
>     :binary-extension nil
>     :components
>     [...])
> 
> odcl.system:
> 
> (in-package :cl-user)
> 
> (mk:defsystem :odcl
>     :source-pathname "cl-library:odcl;"
>     :source-extension "lisp"
>     :binary-pathname nil
>     :binary-extension nil
>     :components
>     ((:file "package")
>      #+sbcl (:file "sbcl"))
>     [...])
>   
> 
>   Does anyone know how this problem could be fixed, or clues as to
>   what I should look into?  I appreciate all the help..

You need to set up a logical pathname translation for the logical host
"cl-library:" first. In your case that would be

  (setf (logical-pathname-translations "cl-library") 
              '(("**;*.*.*" "/usr/share/common-lisp/source/**/")))

This should work.

See <http://www.lispworks.com/reference/HyperSpec/Body/f_logica.htm>.

Cheers,
Edi.
From: Yarden Katz
Subject: Re: defsystem on Allegro CL
Date: 
Message-ID: <86u1ggqnhk.fsf@underlevel.net>
Edi Weitz <···@agharta.de> writes:

[snip]
> You need to set up a logical pathname translation for the logical host
> "cl-library:" first. In your case that would be
>
>   (setf (logical-pathname-translations "cl-library") 
>               '(("**;*.*.*" "/usr/share/common-lisp/source/**/")))

Your suggestion worked; the files were found.  After reading the Hyperspec
document on this pointed out by Thomas A. Russ, it makes a lot of
sense.

However, Allegro CL couldn't find the .fasl files (since the Lisp
filed were not compiled)--which is reasonable.  I setup Allegro to
compile all .lisp files to .fasl, as you can see below:

(require :imho)
;    - Binary file /usr/share/common-lisp/source/odcl/package.fasl is old or does not exist. 
;      Compile (and load) source file /usr/share/common-lisp/source/odcl/package.lisp instead? y

;    - Should I bother you if this happens again? y

;;; Compiling file /usr/share/common-lisp/source/odcl/package.lisp
;;; Writing fasl file /usr/share/common-lisp/source/odcl/package.fasl
;;; Fasl write complete
; Fast loading /usr/share/common-lisp/source/odcl/package.fasl
;    - Binary file /usr/share/common-lisp/source/odcl/macros.fasl is old or does not exist. 
;      Compile (and load) source file /usr/share/common-lisp/source/odcl/macros.lisp instead? y

;    - Should I bother you if this happens again? y

;;; Compiling file /usr/share/common-lisp/source/odcl/macros.lisp
;;; Writing fasl file /usr/share/common-lisp/source/odcl/macros.fasl
;;; Fasl write complete
[.....]


This occured for a bunch of source files, but for locale.lisp, I got
the error below:

; Loading /usr/share/common-lisp/source/odcl/locale.lisp
Error: No dispatch function defined for #\i.
  [condition type: SIMPLE-ERROR]

In locale.lisp, set-dispatch-macro-character defines:

 (set-dispatch-macro-character
 #\#
 #\I
 #'(lambda(s c n)
     (declare (ignore c n))
     (let ((string (read s nil (values) t)))  ;list is object after #n{
       `(gettext ,string)))))

and I suspect Allegro complains about this function:

(defun y-n-string (boolean)
  (if boolean
      #i"Yes"
      #i"No"))

However, I have no idea how #i is intended to be defined.  Could
someone please shed some light on this?  I've attached locale.lisp in
its entirety below since it is fairly short.  I really appreciate your help.

Thanks a lot,  
-- 
Yarden Katz <····@underlevel.net>  |  Mind the gap

--start locale.lisp--
(in-package :odcl)

(defvar *lang* '((:en)))
(defvar *country* :US)

(defvar *msgs* (make-hash-table))

(defun gettext (text)
  (dolist (lang *lang*)
    (when-bind (lang (gethash (car lang) *msgs*))
      (when-bind (text (gethash text lang))
        (return-from gettext text))))
  text)

(eval-when (:compile-toplevel :load-toplevel)

(set-dispatch-macro-character
 #\#
 #\I
 #'(lambda(s c n)
     (declare (ignore c n))
     (let ((string (read s nil (values) t)))  ;list is object after #n{
       `(gettext ,string)))))


(defun y-n-string (boolean)
  (if boolean
      #i"Yes"
      #i"No"))

(defun parse-lc (locale)
  (let ((lang (subseq locale 0 2))
        (country (subseq locale 3 5)))
    (list (intern (string-upcase lang) :keyword)
          (intern (string-upcase country) :keyword))))

(defun addtext (msgid locale msg)
  (destructuring-bind (lang country)
      (parse-lc locale)
    (declare (ignore country))
    (let ((msgs (gethash lang *msgs*)))
      (unless msgs
        (setf msgs (make-hash-table :test #'equal)
              (gethash lang *msgs*) msgs))
      (setf (gethash msgid msgs) msg))))
    
(addtext "Yes" "de_DE" "Ja")
(addtext "No" "de_DE" "Nein")
(addtext "Yes" "fr_FR" "Oui")
(addtext "No" "fr_FR" "Non")
--end locale.lisp--
From: Edi Weitz
Subject: Re: defsystem on Allegro CL
Date: 
Message-ID: <877kdc58rd.fsf@bird.agharta.de>
Yarden Katz <····@underlevel.net> writes:

> Edi Weitz <···@agharta.de> writes:
> 
> [snip]
> > You need to set up a logical pathname translation for the logical host
> > "cl-library:" first. In your case that would be
> >
> >   (setf (logical-pathname-translations "cl-library") 
> >               '(("**;*.*.*" "/usr/share/common-lisp/source/**/")))
> 
> Your suggestion worked; the files were found.  After reading the Hyperspec
> document on this pointed out by Thomas A. Russ, it makes a lot of
> sense.
> 
> However, Allegro CL couldn't find the .fasl files (since the Lisp
> filed were not compiled)--which is reasonable.  I setup Allegro to
> compile all .lisp files to .fasl, as you can see below:
> 
> (require :imho)
> ;    - Binary file /usr/share/common-lisp/source/odcl/package.fasl is old or does not exist. 
> ;      Compile (and load) source file /usr/share/common-lisp/source/odcl/package.lisp instead? y
> 
> ;    - Should I bother you if this happens again? y
> 
> ;;; Compiling file /usr/share/common-lisp/source/odcl/package.lisp
> ;;; Writing fasl file /usr/share/common-lisp/source/odcl/package.fasl
> ;;; Fasl write complete
> ; Fast loading /usr/share/common-lisp/source/odcl/package.fasl
> ;    - Binary file /usr/share/common-lisp/source/odcl/macros.fasl is old or does not exist. 
> ;      Compile (and load) source file /usr/share/common-lisp/source/odcl/macros.lisp instead? y
> 
> ;    - Should I bother you if this happens again? y
> 
> ;;; Compiling file /usr/share/common-lisp/source/odcl/macros.lisp
> ;;; Writing fasl file /usr/share/common-lisp/source/odcl/macros.fasl
> ;;; Fasl write complete
> [.....]
> 
> 
> This occured for a bunch of source files, but for locale.lisp, I got
> the error below:
> 
> ; Loading /usr/share/common-lisp/source/odcl/locale.lisp
> Error: No dispatch function defined for #\i.
>   [condition type: SIMPLE-ERROR]
> 
> In locale.lisp, set-dispatch-macro-character defines:
> 
>  (set-dispatch-macro-character
>  #\#
>  #\I
>  #'(lambda(s c n)
>      (declare (ignore c n))
>      (let ((string (read s nil (values) t)))  ;list is object after #n{
>        `(gettext ,string)))))
> 
> and I suspect Allegro complains about this function:
> 
> (defun y-n-string (boolean)
>   (if boolean
>       #i"Yes"
>       #i"No"))
> 
> However, I have no idea how #i is intended to be defined.  Could
> someone please shed some light on this?  I've attached locale.lisp in
> its entirety below since it is fairly short.  I really appreciate your help.

This works fine for me with ACL 6.2 trial on Linux. Could it be that
you have one of those case-insensitive ACL versions? Have you tried
changing the two occurences of #i to #I?

Edi.
From: Yarden Katz
Subject: Re: defsystem on Allegro CL
Date: 
Message-ID: <86wulbpqbk.fsf@underlevel.net>
Edi Weitz <···@agharta.de> writes:

[snip]
> This works fine for me with ACL 6.2 trial on Linux. Could it be that
> you have one of those case-insensitive ACL versions? Have you tried
> changing the two occurences of #i to #I?
>
> Edi.

Changing #i to #I, or changing:

(eval-when (:compile-toplevel :load-toplevel)

to 

(eval-when (:compile-toplevel :load-toplevel :execute)

both fix the problem, but compilation/loading stops again at
odcl/package.lisp:

; While compiling (:TOP-LEVEL-FORM "package.lisp" 431):
Error: Using package `EXCL' results in name conflicts for these
       symbols: ODCL:WHILE ODCL:WHILE
  [condition type: PACKAGE-ERROR]

I then removed :excl from the :use line, to get

(:use :common-lisp :mp :odcl :net.html.generator)

but again, loading stopped at:

; Fast loading /usr/share/common-lisp/source/imho/variables.fasl
Error: attempt to call `MAKE-LOCK' which is an undefined function.
  [condition type: UNDEFINED-FUNCTION]

'make-lock' is called as follows in variables.fasl:
  
(defvar *session-timeout-lock* (make-lock #-cmu :name "session-timeout-lock")
  "Lock for protecting the freeing of sessions from the accessing of sessions")

but since 'make-lock' is not part of excl, it doesn't seem that the
problem is caused by my changes to package.lisp.  Do you know how I
could fix this?  It's odd that all of this is working for you with no
errors on ACL 6.2 trial.

Thanks a lot for your help! 
-- 
Yarden Katz <····@underlevel.net>  |  Mind the gap
From: Edi Weitz
Subject: Re: defsystem on Allegro CL
Date: 
Message-ID: <873cnz62mt.fsf@bird.agharta.de>
Yarden Katz <····@underlevel.net> writes:

> Edi Weitz <···@agharta.de> writes:
> 
> [snip]
> > This works fine for me with ACL 6.2 trial on Linux. Could it be that
> > you have one of those case-insensitive ACL versions? Have you tried
> > changing the two occurences of #i to #I?
> >
> > Edi.
> 
> Changing #i to #I, or changing:
> 
> (eval-when (:compile-toplevel :load-toplevel)
> 
> to 
> 
> (eval-when (:compile-toplevel :load-toplevel :execute)
> 
> both fix the problem, but compilation/loading stops again at
> odcl/package.lisp:
> 
> ; While compiling (:TOP-LEVEL-FORM "package.lisp" 431):
> Error: Using package `EXCL' results in name conflicts for these
>        symbols: ODCL:WHILE ODCL:WHILE
>   [condition type: PACKAGE-ERROR]
> 
> I then removed :excl from the :use line, to get
> 
> (:use :common-lisp :mp :odcl :net.html.generator)
> 
> but again, loading stopped at:
> 
> ; Fast loading /usr/share/common-lisp/source/imho/variables.fasl
> Error: attempt to call `MAKE-LOCK' which is an undefined function.
>   [condition type: UNDEFINED-FUNCTION]
> 
> 'make-lock' is called as follows in variables.fasl:
>   
> (defvar *session-timeout-lock* (make-lock #-cmu :name "session-timeout-lock")
>   "Lock for protecting the freeing of sessions from the accessing of sessions")
> 
> but since 'make-lock' is not part of excl, it doesn't seem that the
> problem is caused by my changes to package.lisp.  Do you know how I
> could fix this?  It's odd that all of this is working for you with no
> errors on ACL 6.2 trial.

No, I just checked whether I could compile ODCL with the AllegroCL
trial version that I have here - I run into the same problems with
IMHO.

Did you read somewhere that IMHO is actually _supposed_ to work with
AllegroCL? I seem to remember that the Onshored software is usually
written for CMUCL and might have patches for LispWorks if you're
lucky. It might just be the case that you have to use CMUCL or LW.

Edi.
From: Yarden Katz
Subject: Re: defsystem on Allegro CL (Calling other Lisps from Lisp)
Date: 
Message-ID: <86k7hbpmwe.fsf_-_@underlevel.net>
Edi Weitz <···@agharta.de> writes:

> No, I just checked whether I could compile ODCL with the AllegroCL
> trial version that I have here - I run into the same problems with
> IMHO.
>
> Did you read somewhere that IMHO is actually _supposed_ to work with
> AllegroCL? I seem to remember that the Onshored software is usually
> written for CMUCL and might have patches for LispWorks if you're
> lucky. It might just be the case that you have to use CMUCL or LW.

I was not able to find anything about cl-imho working or not working
on Allegro.  It seemed to be an unexplored area.  The reason I'm
trying to force IMHO on Allegro is because my project relies on two
other Lisp packages, Wilbur[1] and RACER[2], that were specifically
made for Allegro CL and will not run on any other environment.  I was
trying to find a library that will allow me to build a fairly
extensive CGI interface for my project, and IMHO seemed to be the best
choice.

How do people generally overcome this problem, when functions from a
software that runs only on X Lisp need to be referenced from a Lisp
program that is run on Y Lisp?  Is it practical to try and link them?

I am also very open and willing to use another CGI toolkit other than
IMHO.  The only other Lisp software package I've seen that may be able
to do is is the Lisp Server Pages.  Other CGI toolkits, like Le
Sursis, generally only run on CLISP, and I remember way back I even
had trouble getting Le Sursis to run on CLISP.  If you know of any
other CGI frameworks, please let me know.

Thanks a lot!
-- 
Yarden Katz <····@underlevel.net>  |  Mind the gap
From: Edi Weitz
Subject: Re: defsystem on Allegro CL (Calling other Lisps from Lisp)
Date: 
Message-ID: <87y95r4h6v.fsf@bird.agharta.de>
Yarden Katz <····@underlevel.net> writes:

> I am also very open and willing to use another CGI toolkit other
> than IMHO.  The only other Lisp software package I've seen that may
> be able to do is is the Lisp Server Pages.  Other CGI toolkits, like
> Le Sursis, generally only run on CLISP, and I remember way back I
> even had trouble getting Le Sursis to run on CLISP.  If you know of
> any other CGI frameworks, please let me know.

Specifically with AllegroCL you can use AllegroServe which was written
by John Foderaro of Franz Inc. for AllegroCL. Also, mod_lisp will work
with AllegroCL. Other options are listed here:

  <http://www.cliki.net/Web>

Edi.
From: Yarden Katz
Subject: web toolkits for Allegro (was Re: defsystem on Allegro CL)
Date: 
Message-ID: <86ptr3nx1y.fsf_-_@underlevel.net>
Edi Weitz <···@agharta.de> writes:

> Yarden Katz <····@underlevel.net> writes:
>
>> I am also very open and willing to use another CGI toolkit other
>> than IMHO.  The only other Lisp software package I've seen that may
>> be able to do is is the Lisp Server Pages.  Other CGI toolkits, like
>> Le Sursis, generally only run on CLISP, and I remember way back I
>> even had trouble getting Le Sursis to run on CLISP.  If you know of
>> any other CGI frameworks, please let me know.
>
> Specifically with AllegroCL you can use AllegroServe which was written
> by John Foderaro of Franz Inc. for AllegroCL. Also, mod_lisp will work
> with AllegroCL. Other options are listed here:
>
>   <http://www.cliki.net/Web>
>
> Edi.

I believe I have exhausted all of the available options listed on
http://www.cliki.net/Web.  As I've explained earlier, I am bound to
Allegro Lisp due to the fact the two toolkits I'm using (Wilbur
<wilbur-rdf.sf.net) and RACER
<http://www.fh-wedel.de/~mo/racer/index.html>) will only run on it.

I tried AllegroServe. Its features list seemed to answer all of my
needs, and most importantly, it was created for Allegro Lisp. I
downloaded the latest version of AllegroServe and began
installation.. it turned out the heap size limit of the free trial
version of Allegro was met.  I am using Allegro for educational
purposes and cannot afford to pay for its full-license, which is the
only way to run software that takes up as much memory as Allegro CL.

Next, I tried Araneida, a small webserver, which seemed to have the
right features, but it only runs on CMUCL and SBCL, so it was
immediately ruled out.  Le Sursis, a CGI library, seemed good
feature-wise, but again, it only runs on CLISP.  FastCGI also runs
only on CLISP and CMUCL.  Finally, the Lisp Server Pages seemed very
feasible but its stable versions rely on AllegroServe, so again, it
scratched off.

The last promising choice was the heavyweight CL-HTTP server. It does
everything I want in terms of feature, has a large userbase and fairly
extensive documentation. However, the Allegro Lisp version I'm using,
6.2., is the most problematic one to get CL-HTTP to run on.
Downgrading is not possible, because of the new customizations that
RACER authors made especially for me to the Linux ACL 6.2 version of
their software.

I am currently in the process of trying to get CL-HTTP to run on ACL
6.2, although my attempts are probably already futile; if AllegroServe
took up too much memory for the free trial version of ACL to handle,
CL-HTTP will require twice as much.

I don't know how to solve this problem.  Any input that anyone might
have will be greatly appreciated--I am completely stuck.

Thanks a lot,
-- 
Yarden Katz <····@underlevel.net>  |  Mind the gap
From: Henrik Motakef
Subject: Re: web toolkits for Allegro (was Re: defsystem on Allegro CL)
Date: 
Message-ID: <877kdbe11j.fsf@interim.henrik-motakef.de>
Yarden Katz <····@underlevel.net> writes:

> I believe I have exhausted all of the available options listed on
> http://www.cliki.net/Web.  As I've explained earlier, I am bound to
> Allegro Lisp due to the fact the two toolkits I'm using (Wilbur
> <wilbur-rdf.sf.net) and RACER
> <http://www.fh-wedel.de/~mo/racer/index.html>) will only run on it.

I didn't know about RACER until your postings, but I seem to remember
to have compiled and used Wilbur successfully some months ago, and I
didn't have my ACL trial back then. So maybe trying to port Wilbur and
RACER to another Lisp instead of finding a web framework that works
for you on ACL is worth a try.

I don't know what exactly you want to do, of course, but I recently
thought about an interface to the RDFDB (http://www.guha.com/rdfdb/).
It seems to have quite a simple socket interface for querying an RDF
model, and AFAIK can parse RDF-XML and N3 on it's own. It doesn't seem
to deal with anything but base RDF, however, so if you need RDFS,
DAML+OIL, WebOnt or something, you will probably have to build it
yourself (or write a wrapper that RACER accepts, at least.)

Regards
Henrik
From: Yarden Katz
Subject: Re: web toolkits for Allegro (was Re: defsystem on Allegro CL)
Date: 
Message-ID: <86iswuoqkm.fsf@underlevel.net>
Henrik Motakef <··············@web.de> writes:

> Yarden Katz <····@underlevel.net> writes:
>
>> I believe I have exhausted all of the available options listed on
>> http://www.cliki.net/Web.  As I've explained earlier, I am bound to
>> Allegro Lisp due to the fact the two toolkits I'm using (Wilbur
>> <wilbur-rdf.sf.net) and RACER
>> <http://www.fh-wedel.de/~mo/racer/index.html>) will only run on it.
>
> I didn't know about RACER until your postings, but I seem to remember
> to have compiled and used Wilbur successfully some months ago, and I
> didn't have my ACL trial back then. So maybe trying to port Wilbur and
> RACER to another Lisp instead of finding a web framework that works
> for you on ACL is worth a try.

I would be very curious to know what Lisp you got Wilbur to work on.
The website for it says that Wilbur only runs on MCL and ACL, and that
an OpenMCL port is 'possible'.  However, I know there's a LispWorks
version of RACER available, and since RACER uses Wilbur, there's hope
for a LispWorks port.. then again, the personal free version of
LispWorks also has heap size limitations like Allegro.

Thanks a lot,
-- 
Yarden Katz <····@underlevel.net>  |  Mind the gap
From: Louis Theran
Subject: Re: web toolkits for Allegro (was Re: defsystem on Allegro CL)
Date: 
Message-ID: <a2503e25.0301150959.2a7f3e97@posting.google.com>
Yarden Katz <····@underlevel.net> wrote in message news:<··············@underlevel.net>...

> I would be very curious to know what Lisp you got Wilbur to work on.

Please send reports of Wilbur ports and patches to ······@cs.umass.edu.  Thanks.

^L
From: Edi Weitz
Subject: Re: web toolkits for Allegro (was Re: defsystem on Allegro CL)
Date: 
Message-ID: <87hecfw95i.fsf@bird.agharta.de>
Yarden Katz <····@underlevel.net> writes:

> Edi Weitz <···@agharta.de> writes:
> 
> > Yarden Katz <····@underlevel.net> writes:
> >
> >> I am also very open and willing to use another CGI toolkit other
> >> than IMHO.  The only other Lisp software package I've seen that may
> >> be able to do is is the Lisp Server Pages.  Other CGI toolkits, like
> >> Le Sursis, generally only run on CLISP, and I remember way back I
> >> even had trouble getting Le Sursis to run on CLISP.  If you know of
> >> any other CGI frameworks, please let me know.
> >
> > Specifically with AllegroCL you can use AllegroServe which was written
> > by John Foderaro of Franz Inc. for AllegroCL. Also, mod_lisp will work
> > with AllegroCL. Other options are listed here:
> >
> >   <http://www.cliki.net/Web>
> >
> > Edi.
> 
> I believe I have exhausted all of the available options listed on
> http://www.cliki.net/Web.  As I've explained earlier, I am bound to
> Allegro Lisp due to the fact the two toolkits I'm using (Wilbur
> <wilbur-rdf.sf.net) and RACER
> <http://www.fh-wedel.de/~mo/racer/index.html>) will only run on it.
> 
> I tried AllegroServe. Its features list seemed to answer all of my
> needs, and most importantly, it was created for Allegro Lisp. I
> downloaded the latest version of AllegroServe and began
> installation.. it turned out the heap size limit of the free trial
> version of Allegro was met.  I am using Allegro for educational
> purposes and cannot afford to pay for its full-license, which is the
> only way to run software that takes up as much memory as Allegro CL.
> 
> Next, I tried Araneida, a small webserver, which seemed to have the
> right features, but it only runs on CMUCL and SBCL, so it was
> immediately ruled out.  Le Sursis, a CGI library, seemed good
> feature-wise, but again, it only runs on CLISP.  FastCGI also runs
> only on CLISP and CMUCL.  Finally, the Lisp Server Pages seemed very
> feasible but its stable versions rely on AllegroServe, so again, it
> scratched off.
> 
> The last promising choice was the heavyweight CL-HTTP server. It does
> everything I want in terms of feature, has a large userbase and fairly
> extensive documentation. However, the Allegro Lisp version I'm using,
> 6.2., is the most problematic one to get CL-HTTP to run on.
> Downgrading is not possible, because of the new customizations that
> RACER authors made especially for me to the Linux ACL 6.2 version of
> their software.
> 
> I am currently in the process of trying to get CL-HTTP to run on ACL
> 6.2, although my attempts are probably already futile; if AllegroServe
> took up too much memory for the free trial version of ACL to handle,
> CL-HTTP will require twice as much.
> 
> I don't know how to solve this problem.  Any input that anyone might
> have will be greatly appreciated--I am completely stuck.

Have you actually tried mod_lisp which I mentioned in my last posting?
It's small and fast and should work with ACL without any problems.

Edi.
From: Bill Clementson
Subject: Re: web toolkits for Allegro (was Re: defsystem on Allegro CL)
Date: 
Message-ID: <wku1geyvj7.fsf@attbi.com>
Yarden Katz <····@underlevel.net> writes:

> I believe I have exhausted all of the available options listed on
> http://www.cliki.net/Web.  As I've explained earlier, I am bound to
> Allegro Lisp due to the fact the two toolkits I'm using (Wilbur
> <wilbur-rdf.sf.net) and RACER
> <http://www.fh-wedel.de/~mo/racer/index.html>) will only run on it.
> 
> I tried AllegroServe. Its features list seemed to answer all of my
> needs, and most importantly, it was created for Allegro Lisp. I
> downloaded the latest version of AllegroServe and began
> installation.. it turned out the heap size limit of the free trial
> version of Allegro was met.  I am using Allegro for educational
> purposes and cannot afford to pay for its full-license, which is the
> only way to run software that takes up as much memory as Allegro CL.

Have you downloaded the ACL6.2 patches from Franz? The ACL6.2 free trial
version had a bug which meant that the heap size was used up much more
quickly than in earlier versions. There is a patch for it and you can
install it by doing the following:

1. Establish an internet connection
2. Run ACL
3. From the REPL prompt, run the following form:
   (sys:update-allegro)
4. All patches will be downloaded from the Franz site. When finished,
   follow the instructions that will be displayed.

I use the ACL 6.2 trial on Windows with AllegroServe and have not had
any problems with exceeding the heap size after downloading these
patches. BTW, the Franz technical people are very helpful when you have
issues like this (even if you're not yet a paying customer).

--
Bill Clementson
From: Joe Marshall
Subject: Re: defsystem on Allegro CL
Date: 
Message-ID: <znq5ccnt.fsf@ccs.neu.edu>
Yarden Katz <····@underlevel.net> writes:

> compilation/loading stops again at odcl/package.lisp:
> 
> ; While compiling (:TOP-LEVEL-FORM "package.lisp" 431):
> Error: Using package `EXCL' results in name conflicts for these
>        symbols: ODCL:WHILE ODCL:WHILE
>   [condition type: PACKAGE-ERROR]
> 
> I then removed :excl from the :use line, to get
> 
> (:use :common-lisp :mp :odcl :net.html.generator)

It is important to set up the package structure *before* you do
anything else.  It appears (given only what I've seen in your
messages) that the symbol `WHILE' was interned into the ODCL package
before the package.lisp file was compiled.