after reading several glowing accounts of how good lisp was. I have
begun to learn it (and agree with many or the glowing accounts,) and
recently I have installed mod_lisp so as to write a web application.
I've had some difficulty.
after some research, I found a posting on either this list or the
mod_lisp list that mirrored my problem. however that post was dated
2002, and was never answered.
so,
I am running clisp, mod_lisp, apache, OS X. mod_lisp is installed and
functioning, and when I load and start clisp and the lisp server it
does work. once or twice, then it just sort of hangs. is there any
explanation that anyone could provide? the one response to the other
fellow, was to use cmucl instead of clisp, but clisp seems to be a bit
friendlier. and to date, mod_lisp for cmucl will not function for me,
the following error results fromt trying (start-apache-listener). what
is fdefinition.lisp, where should it be, why is it not there, etc.etc.
Source: Error finding source:
Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no
longer exists:
target:code/fdefinition.lisp.
If I could but solve that problem, I could get on to some of the more
philosophical questions that I'm curious about.
for instance, I have noticed that there are some syntax differences,
and several of the librariesfor cmucl seem not to be available for
clisp. is there any reason why some of these utilities have not been
ported to clisp?, is there something lacking? is cmucl that much
better/faster/etc? clisp seems to include several 'normal' shell
actions, (history etc.) that cmucl seems to lack. I seem to recall
that it is stated somewhere that clisp lacks the some 'session
management" ability. generally has anyone got a list of pros/cons
about the various (apparently not very) common lisp implementations?
thank you in advance for any assistance to these somewhat stream of
conciousness questions
cheers all,
peter
> and to date, mod_lisp for cmucl will not function for me,
Does CMUCL run under Mac OS X yet? That's news to me.
> Source: Error finding source:
> Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no
> longer exists:
> target:code/fdefinition.lisp.
That's not the original error message; that's the debugger telling you
it cannot find the CMUCL sources. The error message comes earlier.
> for instance, I have noticed that there are some syntax differences,
> and several of the librariesfor cmucl seem not to be available for
> clisp. is there any reason why some of these utilities have not been
> ported to clisp?
> is cmucl that much better/faster/etc?
Both CMUCL and CLISP are very complete ANSI Common Lisp implementations.
CMUCL is 10 to 40 times faster than CLISP. CLISP is 10 times smaller
than CMUCL.
Because of that, people tend to use CLISP and CMUCL for different
things, which at least partly explains why the sets of available
libraries are different.
> clisp seems to include several 'normal' shell actions, (history
> etc.) that cmucl seems to lack.
REPL history is not done by CMUCL, but by an external interface. The
current favourite is SLIME,
http://common-lisp.net/project/slime/
but you might also want to check ILISP.
Juliusz
"circusboy" <········@gmail.com> writes:
> after reading several glowing accounts of how good lisp was. I have
> begun to learn it (and agree with many or the glowing accounts,) and
> recently I have installed mod_lisp so as to write a web application.
>
> I've had some difficulty.
>
> after some research, I found a posting on either this list or the
> mod_lisp list that mirrored my problem. however that post was dated
> 2002, and was never answered.
>
> so,
>
> I am running clisp, mod_lisp, apache, OS X. mod_lisp is installed and
> functioning, and when I load and start clisp and the lisp server it
> does work. once or twice, then it just sort of hangs. is there any
> explanation that anyone could provide?
If you don't plan to use this server out of MacOS X, you could try
openmcl (works on MacOSX/ppc, Darwin/ppc and Linux/ppc). But clisp is
a good choice if portability is important.
For servers, one drawback of clisp is its (current) lack of threads.
I don't know how it'd behave if several requests arrived at the same
time. Where the "hang" appears? In mod_lisp or in clisp proper?
While the lack of threads means that you cannot as easily as in other
implementation debug interactively live servers, you can still start
the server from the REPL of clisp, and when it hangs, break into the
debugger with control-c. There you can examine the backtrace (:bt) to
get an idea of what it's doing, where it's hung. You'd better try it
with uncompiled server code if you want to get good information, to be
able to inspect argument values, etc.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Kitty like plastic.
Confuses for litter box.
Don't leave tarp around.
the hang appears to happen after a couple of requests. basically what
happens is I start clisp, load the modlisp-clisp.lisp file, start the
listener, (in this case, (modlisp:modlisp-server) until I'm sure it
works) then open a browser and request the page.
all is well. (though there is another bit that is going wrong there,
one problem at a time.(for the curious, supposedly if you request a
URL in the directory that causes the listener to run, the default
action of the modlisp-clisp script is to return a 'fixed-string with
/debug-table at the end of the url, you should get ad table of debug
information. I don't, no matter what, I get the 'fixed-string')
repeat the request, it works again.
repeat the request again, and this time, and forever after, nothing
happens. the progress bar in the browser goes far enough to make me
believe that the request has been made, but the listener has not heard
it, or at least doesn't feel like doing anything about it. I will try
the backtrace and see what happens, though I have noticed that if I do
break into the debugger apache returns an error page to the browser,
(as one might expect).
update on that, curiouser and curiouser... if I hit C-c it responds
'*** - Ctrl-C: User break'
I then enter (:bt) as instructed, and oddly the page suddenly appears
in the browser, though nothing else seems to occur in the lisp
environment. (i.e. no data or anything) color me very confused. what
would you have expected to appear? (I am still very unfamiliar with
this way of working so I am probably doing this wrong.)
as far as your other questions go, the project in question is private
and low traffic, there is a very limited set of users, so I'm not too
worried about massive overlapping requests. I am however working for
people who are not very decisive, but tempermental. so the idea of
being able to modify and update quickly is very attractive. (plus it's
quite a challenge.) this project was announced a month ago, and I'm
still waiting for someone to decide what exactly will be done. long
live academia! knowing that I still have at least a couple of weeks
before someone decides who gets to decide, means that I have the time
to get to know new things. this will eventually run on an intel/linux
server, (which flaver is yet to be determined, but they are
conservative, so I suspect pretty basic debian, or red hat, it's not up
to me. I have an os X machine to work on, so I was hoping to work as
portably as possible. again, most of my reading to date has seemed to
revolve around clisp, I'm willing to use whatever works, but I would
rather avoid having to spend a lot of time rewriting the project later.
I don't think I can convince them to buy xserves or anything... I have
recently downloaded openMCL, but the mod_lisp scripts are only for
clisp and cmucl. ( which to answer to the previous poster, yes, there
is a port to os X http://www.pmsf.de/personal/darwin/ ( experimental,
but the error messages are much more verbose. (which I see a lot of,
but a story for another day. different error)) (you can, perhaps, see
why I'm drawn towards lisp)
anyway, I have not really read up on OpenMCL yet, is the difference in
the dialect great? (is it truly a pain to translate from one to the
other?) I notice for instance the load file command in clisp is (load
'modlisp-clisp) and in cmucl is (load "modlisp-cmucl.lisp") and for
some reason the command to start the listener in each case is very
different, do the dialects vary so wildly as to require that? despite
conformance to the ANSI standard? I suppose it has more to do with
where the language ends and the libraries begin?
thank you for your advice so far, and for (hopefully) more to come.
Peter
"circusboy" <········@gmail.com> writes:
> the hang appears to happen after a couple of requests. basically what
> happens is I start clisp, load the modlisp-clisp.lisp file, start the
> listener, (in this case, (modlisp:modlisp-server) until I'm sure it
> works) then open a browser and request the page.
>
> all is well. (though there is another bit that is going wrong there,
> one problem at a time.(for the curious, supposedly if you request a
> URL in the directory that causes the listener to run, the default
> action of the modlisp-clisp script is to return a 'fixed-string with
> /debug-table at the end of the url, you should get ad table of debug
> information. I don't, no matter what, I get the 'fixed-string')
>
> repeat the request, it works again.
>
> repeat the request again, and this time, and forever after, nothing
> happens. the progress bar in the browser goes far enough to make me
> believe that the request has been made, but the listener has not heard
> it, or at least doesn't feel like doing anything about it. I will try
> the backtrace and see what happens, though I have noticed that if I do
> break into the debugger apache returns an error page to the browser,
> (as one might expect).
>
> update on that, curiouser and curiouser... if I hit C-c it responds
> '*** - Ctrl-C: User break'
> I then enter (:bt) as instructed, and oddly the page suddenly appears
> in the browser, though nothing else seems to occur in the lisp
> environment. (i.e. no data or anything) color me very confused. what
> would you have expected to appear? (I am still very unfamiliar with
> this way of working so I am probably doing this wrong.)
Perhaps you're missing a FINISH-OUTPUT (or FORCE-OUTPUT) somewhere...
You might learn something by studing the backtrace itself, what
functions are active?
> anyway, I have not really read up on OpenMCL yet, is the difference in
> the dialect great? (is it truly a pain to translate from one to the
> other?)
There should be no difference "in the dialect". Common-Lisp
implementations strive to compliance, so the differences tend to 0
with the time. The problem is the difference in the additional
packages. Anything that is not in COMMON-LISP won't be portable usually.
Beware that implementations are allowed to import any package in
COMMON-LISP-USER, therefore you might be using specific extensions
without noticing.
I put:
(DOLIST (USED (REMOVE (FIND-PACKAGE "COMMON-LISP")
(COPY-SEQ (PACKAGE-USE-LIST "COMMON-LISP-USER"))))
(UNUSE-PACKAGE USED "COMMON-LISP-USER"))
in my ~/.common.lisp which is loaded from the variouns ~/.clisprc,
~/.sbcllrc, ~/.cmucl-init.lisp, ~/openmcl-init.lisp, etc.
And explicitely use any extra package.
> I notice for instance the load file command in clisp is (load
> 'modlisp-clisp) and in cmucl is (load "modlisp-cmucl.lisp")
Put this in a common "modlisp.lisp" file:
(defvar *implementation-table*
;; *feature* (lisp-implementation-type) tag
;; --------- ---------------------------- --------
'((:clisp "CLISP" "clisp")
(:cmu "CMU Common Lisp" "cmucl")
(:ecl "ECL" "ecl")
(:gcl "Kyoto Common Lisp" "gcl")
(:sbcl "SBCL" "sbcl")
;; Add OpenMCL, I don't have it at hand right now.
))
(defun lisp-implementation-tag ()
(third (find (lisp-implementation-type) *implementation-table*
:key (function second) :test (function string=))))
(load (format nil "modlisp-~A.lisp" (lisp-implementation-tag))
:verbose *load-verbose*
:print *load-print*)
and use (load "modlisp.lisp").
> and for
> some reason the command to start the listener in each case is very
> different, do the dialects vary so wildly as to require that? despite
> conformance to the ANSI standard? I suppose it has more to do with
> where the language ends and the libraries begin?
No, this is only bad design IMO. Here you freedom software hero
enter the scene, and write a common API encapsulating all these
different cases.
Either put the common functions in each of the modlisp-X.lisp files (I
prefer it this way), or add to modlisp.lisp one common function using
ugly #+ and #-.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Wanna go outside.
Oh, no! Help! I got outside!
Let me back inside!
hmmm, I think you may have misunderstood my confusion about the (load
xxx) command. my curiousity was that in clisp the command is typed
(load 'xxxx) and in cmucl (load "xxxx.lisp") i.e. one implementation
uses a single quote and assumes the .lisp extension, and the other does
it differently. not that the name had different words in the middle of
the line a la modlisp-xxxx.lisp.
is not (load) a part of the base ansi standard?
anyway, found my trouble with the :bt, (shouldn't have been using
parens, silly me ;)) and there seem at the time of the break, about 40
functions active. It will take some time for me to pore over this, as
I am still abit unfamiliar with how this all works. other than looking
for a finish|force-output that *isn't* there, can you (or anyone else
for that matter,) suggest what might look to actually be there?
cheers to all,
peter sgouros
btw is the author of mod-lisp hanging about this area, if so, could you
shed some light?
thanks very much!
"circusboy" <········@gmail.com> writes:
> hmmm, I think you may have misunderstood my confusion about the (load
> xxx) command. my curiousity was that in clisp the command is typed
> (load 'xxxx) and in cmucl (load "xxxx.lisp") i.e. one implementation
> uses a single quote and assumes the .lisp extension, and the other does
> it differently. not that the name had different words in the middle of
> the line a la modlisp-xxxx.lisp.
>
> is not (load) a part of the base ansi standard?
Yes. And a symbol is not a filespec so it cannot be given to LOAD,
and clisp gives rightly an error in such a case:
[12]> (load 'lander)
*** - PARSE-NAMESTRING: argument LANDER should be a pathname designator (OR STRING FILE-STREAM PATHNAME)
Break 1 [13]>
In all cases, you may omit the extension, in which case LOAD may
choose (implementation dependant) either the (implementation
dependant) compiled file extension (.fas, .fasl, .x86f, etc) or the
(implementation dependant) source file extension (.cl, .lsp, .lisp),
depending on the presence of a compiled version, not counting the
defaults taken from *default-pathname-defaults*.
Ie. in clisp:
(load "modlisp")
may actually do:
(load "modlisp.fas")
or:
(load "modlisp.lisp")
Perhaps you mean REQUIRE? In the case of REQUIRE, we can give a
symbol or a string as first argument (a string designator). But
anyway, the behavior of REQUIRE is implementation dependant, and
moreover, it's deprecated.
> anyway, found my trouble with the :bt, (shouldn't have been using
> parens, silly me ;)) and there seem at the time of the break, about 40
> functions active. It will take some time for me to pore over this, as
> I am still abit unfamiliar with how this all works. other than looking
> for a finish|force-output that *isn't* there, can you (or anyone else
> for that matter,) suggest what might look to actually be there?
> update on that, curiouser and curiouser... if I hit C-c it responds
> '*** - Ctrl-C: User break'
> I then enter (:bt) as instructed, and oddly the page suddenly appears
> in the browser, though nothing else seems to occur in the lisp
> environment. (i.e. no data or anything) color me very confused. what
> would you have expected to appear? (I am still very unfamiliar with
> this way of working so I am probably doing this wrong.)
It sounds like the output of your server is buffered, and the second
time it's not sent to the client, but still produced and accumulated
in the buffer. And then when you break into the debugger, these
buffers are flushed (finish-output) and the data then arrives to the
client.
So, somewhere near the end of the processing of the requests, before
looping back to waitting for the next request, there should be
something like: (FINISH-OUTPUT *socket*)
> cheers to all,
>
> peter sgouros
>
> btw is the author of mod-lisp hanging about this area, if so, could you
> shed some light?
>
> thanks very much!
--
__Pascal Bourguignon__ http://www.informatimago.com/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d? s++:++ a+ C+++ UL++++ P--- L+++ E+++ W++ N+++ o-- K- w---
O- M++ V PS PE++ Y++ PGP t+ 5+ X++ R !tv b+++ DI++++ D++
G e+++ h+ r-- z?
------END GEEK CODE BLOCK------
hmm for me clisp actually did not give the error for (load 'whatever)
but dutifully loaded the file... curious. any way I will be looking
for (finish-output and the like.
what would you suggest if I do not find it? my curiousity is basically
that am I looking at a bug in either clisp, modlisp-clisp, mod_lisp,
apache, os x, or something I'm as yet unaware of. (this last category
is the most likely, but there is always the possibility that I might
not be wrong...) just as importantly, what would you suggest if I do?
If the buffer is hanging, what would you suggest is the next reasonable
course of action? switch to another lisp? it seemed to work for the
other fellow, (see below) but out of sheer bloody mindedness, I would
at least like to quantify the problem before giving up on it.
part of my wonder about this problem is that it was reported in this
list in 2002 (see
http://groups-beta.google.com/group/comp.lang.lisp/browse_thread/thread/897d6d83c52ba4f6/67cc09d4a9621d37?q=sketchiness&rnum=1#67cc09d4a9621d37
) and the responder suggested having the same problem with
clisp/mod_lisp/modlisp-clisp on another bsd, and solved the problem
replacing clisp with cmucl. but as it mirrors my experience pretty
closely I went looking for OP. I eventually found the original
poster's website where he details giving up on lisp, I would rather not
do that, I'm too intrigued, (and a little under pressured at work, so I
have time)
I will do some more investigating here before I make any further
guesses, I'll get back to you.
From: Sam Steingold
Subject: Re: an old, apparently unanswered, question
Date:
Message-ID: <usm2fzc5z.fsf@gnu.org>
> * circusboy <········@tznvy.pbz> [2005-03-28 12:54:08 -0800]:
>
> hmm for me clisp actually did not give the error for (load 'whatever)
> but dutifully loaded the file... curious.
<http://clisp.cons.org/impnotes/filename-dict.html#path-des>:
Pathname Designators. When CUSTOM:*PARSE-NAMESTRING-ANSI* is
NIL, SYMBOL is also treated as a pathname designator, namely its
SYMBOL-NAME is converted to the operating system's preferred
pathname case.
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.jihadwatch.org/> <http://www.camera.org> <http://www.dhimmi.com/>
<http://www.mideasttruth.com/> <http://pmw.org.il/> <http://www.iris.org.il>
I don't like cats! -- Come on, you just don't know how to cook them!
Sam Steingold <···@gnu.org> writes:
> > * circusboy <········@tznvy.pbz> [2005-03-28 12:54:08 -0800]:
> >
> > hmm for me clisp actually did not give the error for (load 'whatever)
> > but dutifully loaded the file... curious.
>
> <http://clisp.cons.org/impnotes/filename-dict.html#path-des>:
> Pathname Designators. When CUSTOM:*PARSE-NAMESTRING-ANSI* is
> NIL, SYMBOL is also treated as a pathname designator, namely its
> SYMBOL-NAME is converted to the operating system's preferred
> pathname case.
Oh! So the difference may be that I use clisp -ansi and circusboy uses
traditional clisp. Perhaps that's why mod_lisp doesn't work correctly.
Try to add the -ansi option to the clisp command line.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Until real software engineering is developed, the next best practice
is to develop with a dynamic system that has extreme late binding in
all aspects. The first system to really do this in an important way
is Lisp. -- Alan Kay
Pascal Bourguignon writes:
> "circusboy" <········@gmail.com> writes:
>> the hang appears to happen after a couple of requests. basically what
>> happens is I start clisp, load the modlisp-clisp.lisp file, start the
>> listener, (in this case, (modlisp:modlisp-server) until I'm sure it
>> works) then open a browser and request the page.
>>
>> all is well. (though there is another bit that is going wrong there,
>> one problem at a time.(for the curious, supposedly if you request a
>> URL in the directory that causes the listener to run, the default
>> action of the modlisp-clisp script is to return a 'fixed-string with
>> /debug-table at the end of the url, you should get ad table of debug
>> information. I don't, no matter what, I get the 'fixed-string')
>>
>> repeat the request, it works again.
>>
>> repeat the request again, and this time, and forever after, nothing
>> happens. the progress bar in the browser goes far enough to make me
>> believe that the request has been made, but the listener has not heard
>> it, or at least doesn't feel like doing anything about it. I will try
>> the backtrace and see what happens, though I have noticed that if I do
>> break into the debugger apache returns an error page to the browser,
>> (as one might expect).
>>
>> update on that, curiouser and curiouser... if I hit C-c it responds
>> '*** - Ctrl-C: User break'
>> I then enter (:bt) as instructed, and oddly the page suddenly appears
>> in the browser, though nothing else seems to occur in the lisp
>> environment. (i.e. no data or anything) color me very confused. what
>> would you have expected to appear? (I am still very unfamiliar with
>> this way of working so I am probably doing this wrong.)
> Perhaps you're missing a FINISH-OUTPUT (or FORCE-OUTPUT) somewhere...
> You might learn something by studing the backtrace itself, what
> functions are active?
It's calling (force-output *apache-socket*) in the apache-listen
function. I'm seeing the same problem, using the vanilla
modlisp-clisp.lisp. This using Fedora Core 2, GNU CLISP 2.33.2, Apache
1.3.33, mod_lisp 2.43. As soon as it's done processing the request the
first time, it immediately enters get-apache-command, and hangs in the
first let* construct:
(defun get-apache-command ()
(ignore-errors
(let* ((header (loop for key = (read-line *apache-socket* nil nil)
while (and key (string-not-equal key "end"))
collect (cons key (read-line *apache-socket* nil nil)) )))
[...]
The backtrace shows:
Break 1 [3]> :bt
<1> #<SYSTEM-FUNCTION SHOW-STACK>
<2> #<COMPILED-CLOSURE SYSTEM::DEBUG-BACKTRACE>
<3> #<SYSTEM-FUNCTION SYSTEM::READ-EVAL-PRINT>
<4> #<COMPILED-CLOSURE SYSTEM::BREAK-LOOP-2-1>
<5> #<SYSTEM-FUNCTION SYSTEM::SAME-ENV-AS>
<6> #<COMPILED-CLOSURE SYSTEM::BREAK-LOOP-2>
<7> #<SYSTEM-FUNCTION SYSTEM::DRIVER>
<8> #<COMPILED-CLOSURE SYSTEM::BREAK-LOOP>
<9> #<SYSTEM-FUNCTION INVOKE-DEBUGGER>
<10> #<SYSTEM-FUNCTION READ-LINE>
EVAL frame for form (PSETQ MODLISP::KEY (READ-LINE MODLISP::*APACHE-SOCKET* NIL NIL))
<11> #<SPECIAL-OPERATOR PSETQ>
[...]
so it's hanging in the read-line call. I can verify (using ngrep or
other network sniffing tool) that there's input coming to port 3000 from
Apache's mod_lisp module, but it seems modlisp-clisp.lisp just refuses to
see it. (Or rather, the input isn't coming in for the read-line call.)
I'm not experienced enough with CL (or CLISP in particular) yet to say if
this is a problem with CLISP or with modlisp-clisp.lisp. The socket
*apache-socket* should still be open, at least the "close" call in the
source isn't executed. (But maybe the socket is closed in some of the
other macros or functions whose detailed inner workings I'm not familiar
with.)
Doing it with CMUCL works fine. I'd like to have it work with CLISP
though, so any pointers or other ideas to solve this is much appreciated.
Thank you,
Bjorn.