From: lisp linux
Subject: clsql hunchentoot problem working together
Date: 
Message-ID: <U96dnYTxKelzr-XanZ2dnUVZ_qCunZ2d@comcast.com>
Hi

I am having trouble figuring out where my problem is.
I have already spent more than a day trying to solve it myself.
(In this post 'server' refers to hunchentoot)

Each of the following cases were put in a lisp file,
loaded using C-c C-k  .
Between each test run, I deleted all generated fasl and "*.so" files
and restarted emacs and slime (and hence sbcl).
This is on linux ( FC8 ) sbcl  1.0.10

Please please help either reproducing or solving
--------------------------------------------------------------
;Following works and starts the server
(eval-when (:compile-toplevel :load-toplevel :execute)
;(asdf:operate 'asdf:load-op 'clsql)
  (asdf:operate 'asdf:load-op 'hunchentoot))

(defpackage :clsqlhunch)
(cl:in-package :clsqlhunch)

(cl:defvar *server* (hunchentoot:start-server :port 7777))

----------------------------------------------------
;Following compiles loads and gets to the repl prompt
;but the server does not seem to be up
(eval-when (:compile-toplevel :load-toplevel :execute)
  (asdf:operate 'asdf:load-op 'clsql)
  (asdf:operate 'asdf:load-op 'hunchentoot))

(defpackage :clsqlhunch)
(cl:in-package :clsqlhunch)

(cl:defvar *server* (hunchentoot:start-server :port 7777))
----------------------------------------------
;following gives the error
;-- SB-INT:SIMPLE-READER-PACKAGE-ERROR at 179 (line 8, column 45) on #<SB-SYS:FD-STREAM for "file 
;/home/antony/temp/problem.lisp" {1005CAD601}>:
;       package "HUNCHENTOOT" not found
(asdf:operate 'asdf:load-op 'clsql)
(asdf:operate 'asdf:load-op 'hunchentoot)

(defpackage :clsqlhunch)
(cl:in-package :clsqlhunch)

(cl:defvar *server* (hunchentoot:start-server :port 7777))
------------------------------------------------
;following gets me to repl prompt

(asdf:operate 'asdf:load-op 'clsql)
(asdf:operate 'asdf:load-op 'hunchentoot)

(defpackage :clsqlhunch)
(cl:in-package :clsqlhunch)

;(cl:defvar *server* (hunchentoot:start-server :port 7777))

;at the repl typing
(cl:in-package :clsqlhunch)
(cl:defvar *server* (hunchentoot:start-server :port 7777))
;start server ok
---------------------------------------------------------

Basically the problem seems to be -
"I can't figure out what incantation is needed to have the start server code within a lisp file when 
both clsql and hunchentoot are 'require'd "

The actual code tries to use asdf, but I'd like understand the basics behind why I *can* start the 
http server reliably on repl, but not by loading a lisp file even though it does seem to do that 
just fine when clsql is not loaded.

FWIW I am a CL newbee.

-Antony

From: Drew Crampsie
Subject: Re: clsql hunchentoot problem working together
Date: 
Message-ID: <885a2d4d-5476-438c-a7ce-ee885b9e8a1e@i29g2000prf.googlegroups.com>
On Dec 30, 7:08 pm, lisp linux <·········@lisp.linux> wrote:
> Hi
>
> I am having trouble figuring out where my problem is.
> I have already spent more than a day trying to solve it myself.
> (In this post 'server' refers to hunchentoot)

You are making a few common newb mistakes.. you seem to be a little
confused as to which 'time' things happen at.
>
> Each of the following cases were put in a lisp file,
> loaded using C-c C-k  .
> Between each test run, I deleted all generated fasl and "*.so" files
> and restarted emacs and slime (and hence sbcl).
> This is on linux ( FC8 ) sbcl  1.0.10
>
> Please please help either reproducing or solving
> --------------------------------------------------------------
> ;Following works and starts the server
> (eval-when (:compile-toplevel :load-toplevel :execute)
> ;(asdf:operate 'asdf:load-op 'clsql)
>   (asdf:operate 'asdf:load-op 'hunchentoot))
>
> (defpackage :clsqlhunch)
> (cl:in-package :clsqlhunch)
>
> (cl:defvar *server* (hunchentoot:start-server :port 7777))

Good .. that should work indeed. On thing i'd suggest is :USE'ing  the
common lisp pacakge. Also, it's generally a terrible idea to include
the package definition and the in-package form in the same file. You
run the risk of errors and conficts that are best avoided. Usually a
'packages.lisp' or similar is used to store the pacakge definition
source.

>
> ----------------------------------------------------
> ;Following compiles loads and gets to the repl prompt
> ;but the server does not seem to be up
> (eval-when (:compile-toplevel :load-toplevel :execute)
>   (asdf:operate 'asdf:load-op 'clsql)
>   (asdf:operate 'asdf:load-op 'hunchentoot))
>
> (defpackage :clsqlhunch)
> (cl:in-package :clsqlhunch)
>
> (cl:defvar *server* (hunchentoot:start-server :port 7777))

How are you testing if the server is 'up'? What is the value of
*SERVER* at this point? Are you aware of the difference between DEFVAR
and DEFPARAMETER?

> ----------------------------------------------
> ;following gives the error
> ;-- SB-INT:SIMPLE-READER-PACKAGE-ERROR at 179 (line 8, column 45) on #<SB-SYS:FD-STREAM for "file
> ;/home/antony/temp/problem.lisp" {1005CAD601}>:
> ;       package "HUNCHENTOOT" not found
> (asdf:operate 'asdf:load-op 'clsql)
> (asdf:operate 'asdf:load-op 'hunchentoot)
>
> (defpackage :clsqlhunch)
> (cl:in-package :clsqlhunch)
>
> (cl:defvar *server* (hunchentoot:start-server :port 7777))

Ayuh, as well it should. In common lisp, certain things happen at
certain times. I won't get into too much detail, because interning
these ideas are paramount to understanding CL and learning on your own
will be so much more productive, but it should suffice to say that
your cl:defvar form is being READ before the hunchentoot package is
defined. Your EVAL-WHEN in the previous file shows that you seem to
know some of this... perhaps you were just cargo-culting.

In any case,  the clhs section on compilation is a great read.

> ------------------------------------------------
> ;following gets me to repl prompt
>
> (asdf:operate 'asdf:load-op 'clsql)
> (asdf:operate 'asdf:load-op 'hunchentoot)
>
> (defpackage :clsqlhunch)
> (cl:in-package :clsqlhunch)
>
> ;(cl:defvar *server* (hunchentoot:start-server :port 7777))
>
> ;at the repl typing
> (cl:in-package :clsqlhunch)
> (cl:defvar *server* (hunchentoot:start-server :port 7777))
> ;start server ok
> ---------------------------------------------------------

Ok ... probably an issue of what happens when again. First thing i can
suggest is to _never_ have an 'ASDF:OOS' form in a source file that is
to be compiled and loaded... use ASDF for it's intended purpose,
define a system that :DEPENDS-ON those two systems., and load that
system.

If you _must_ have an OOS in a source file, you'd better know what you
are doing ,and make sure it's evaluated before trying to use something
created via its side effects. EVAL-WHEN and #. are among your friends
here... though i must stress that here be dragons.

>
> Basically the problem seems to be -
> "I can't figure out what incantation is needed to have the start server code within a lisp file when
> both clsql and hunchentoot are 'require'd "

Nope, that's not really your issue ;). You are misusing ASDF and lack
knowlege of the cl compilation process.

>
> The actual code tries to use asdf, but I'd like understand the basics behind why I *can* start the
> http server reliably on repl, but not by loading a lisp file even though it does seem to do that
> just fine when clsql is not loaded.

At the REPL you are simply EVAL'ing the forms (that is to say, READ,
EVAL and PRINT in a LOOP). When you compile/load a file, you are
READing, COMPILING, and LOAD'ing before the forms are fully ready to
be evaluated.

If you try to READ a symbol into a package before that package exists,
you'll get an error. Reading the CLHS can clear up these issues, and
teach you quite a bit more as well! :)

> FWIW I am a CL newbee.

So, it seems, are the majority of the responsders to your post... The
blind leading the blind as it were. Hopefully i've set you an the
right track in spite of my myopism :)

Cheers ,

drewc
> -Antony
From: Victor Anyakin
Subject: Re: clsql hunchentoot problem working together
Date: 
Message-ID: <86r6h3xn7e.fsf@victor-mobi.my.domain>
lisp linux <·········@lisp.linux> writes:

> Hi
>
> I am having trouble figuring out where my problem is.
> I have already spent more than a day trying to solve it myself.
> (In this post 'server' refers to hunchentoot)

Hi,

I am a newbee as well, but I would like to recommend you to watch the
famous Lispcast and download the source code supplied with it.  It
seems to me that he does a similar thing in a slightly different way:

 http://www.lispcast.com/index.php/2007/11/lispcast-episode-4/

Wish you good luck, unfortunately, I've got not enough experience to
tell you more...

Victor

http://vityok.org.ua
From: Andreas Thiele
Subject: Re: clsql hunchentoot problem working together
Date: 
Message-ID: <flaj59$tv3$01$1@news.t-online.com>
"lisp linux" <·········@lisp.linux> schrieb im Newsbeitrag ·····································@comcast.com...
> Hi
>
> I am having trouble figuring out where my problem is.
> I have already spent more than a day trying to solve it myself.
> (In this post 'server' refers to hunchentoot)
>
> Each of the following cases were put in a lisp file,
> loaded using C-c C-k  .
> Between each test run, I deleted all generated fasl and "*.so" files
> and restarted emacs and slime (and hence sbcl).
> This is on linux ( FC8 ) sbcl  1.0.10
>
> Please please help either reproducing or solving
> --------------------------------------------------------------
> ;Following works and starts the server
> (eval-when (:compile-toplevel :load-toplevel :execute)
> ;(asdf:operate 'asdf:load-op 'clsql)
>  (asdf:operate 'asdf:load-op 'hunchentoot))
>
> (defpackage :clsqlhunch)
> (cl:in-package :clsqlhunch)
>
> (cl:defvar *server* (hunchentoot:start-server :port 7777))
>
> ----------------------------------------------------
> ;Following compiles loads and gets to the repl prompt
> ;but the server does not seem to be up
> (eval-when (:compile-toplevel :load-toplevel :execute)
>  (asdf:operate 'asdf:load-op 'clsql)
>  (asdf:operate 'asdf:load-op 'hunchentoot))
>
> (defpackage :clsqlhunch)
> (cl:in-package :clsqlhunch)
>
> (cl:defvar *server* (hunchentoot:start-server :port 7777))
> ----------------------------------------------
> ;following gives the error
> ;-- SB-INT:SIMPLE-READER-PACKAGE-ERROR at 179 (line 8, column 45) on #<SB-SYS:FD-STREAM for "file ;/home/antony/temp/problem.lisp" 
> {1005CAD601}>:
> ;       package "HUNCHENTOOT" not found
> (asdf:operate 'asdf:load-op 'clsql)
> (asdf:operate 'asdf:load-op 'hunchentoot)
>
> (defpackage :clsqlhunch)
> (cl:in-package :clsqlhunch)
>
> (cl:defvar *server* (hunchentoot:start-server :port 7777))
> ------------------------------------------------
> ;following gets me to repl prompt
>
> (asdf:operate 'asdf:load-op 'clsql)
> (asdf:operate 'asdf:load-op 'hunchentoot)
>
> (defpackage :clsqlhunch)
> (cl:in-package :clsqlhunch)
>
> ;(cl:defvar *server* (hunchentoot:start-server :port 7777))
>
> ;at the repl typing
> (cl:in-package :clsqlhunch)
> (cl:defvar *server* (hunchentoot:start-server :port 7777))
> ;start server ok
> ---------------------------------------------------------
>
> Basically the problem seems to be -
> "I can't figure out what incantation is needed to have the start server code within a lisp file when both clsql and hunchentoot 
> are 'require'd "
>
> The actual code tries to use asdf, but I'd like understand the basics behind why I *can* start the http server reliably on repl, 
> but not by loading a lisp file even though it does seem to do that just fine when clsql is not loaded.
>
> FWIW I am a CL newbee.
>
> -Antony

Hi Antony,

I am not familiar with those programs, just a hint: cl:in-package looks strange to me.
Seems you should setup proper use of standard packages, perhaps by :use common-lisp?

Just a guess.

Andreas
From: Alex Mizrahi
Subject: Re: clsql hunchentoot problem working together
Date: 
Message-ID: <4778e8ed$0$90265$14726298@news.sunsite.dk>
 ll> ;Following compiles loads and gets to the repl prompt
 ll> ;but the server does not seem to be up

i don't see error in your script, perhaps it has some random nature, but as 
suggestion:

you don't actually need to compile file, as it complicates logic -- you need 
those eval-whens for compilation to be successful.
just load this file (C-c C-l). 
From: lisp linux
Subject: Re: clsql hunchentoot problem working together
Date: 
Message-ID: <CpadnUxV1p4MD-TanZ2dnUVZ_rCtnZ2d@comcast.com>
lisp linux wrote:
> I am having trouble figuring out where my problem is.
> I have already spent more than a day trying to solve it myself.
> (In this post 'server' refers to hunchentoot)
> 
> Each of the following cases were put in a lisp file,
> loaded using C-c C-k  .
   snip...
I saw a few responses. Thanks.
I wanted to clarify some things about my post.

What I wrote were test cases so I can communicate the problem and help anyone interested in 
reproducing it or solving it.
The possibilities as I see are
1. There are bugs in my code
2. The particular versions of OS, Lisp, and the lisp libs I have do not jive together
3. There is a bug in one or more of them
4. I don't know how to correctly  start a lisp application via emacs+slime

I need help in figuring this out.

It is important to note that the server comes up in cases where the code is otherwise the same 
except for the loading of clsql

My wild guess so far is that clsql loads *mysql*.so files and at the same time hunchentoot creates a 
thread and somehow that causes issues within sbcl

The code I pasted is not what I have. I do have a asd file that specifies my files and the clsql and 
hunchentoot as dependencies. I do have asdf-binary-something so that my system finds all the other 
sub-dependencies involved. I do have a separate package file that defines the package. I do do a 
:use cl although I do not do a :use clsql or :use hunchentoot

The code samples I pasted is the smallest code I could create to reproduce the problem by putting 
them in a file and doing a compile-load

I am not sure about the eval-when stuff. It is just something that I tried to see if it'll fix my issue.

I do appreciate the replies so far but I am not sure any one of them has fully addressed the actual 
issue. They all sound like workarounds and not really saying why my stuff isn't working. The problem 
is it is soooo early in my project that if I start using workarounds now...

Following the tip from Drew I have made some progress and I'll respond to his post separately.
As suggested, I will also look into how the server is started in the lispcast examples.


Thanks,
-Antony
From: Alex Mizrahi
Subject: Re: clsql hunchentoot problem working together
Date: 
Message-ID: <477b7d4c$0$90270$14726298@news.sunsite.dk>
 ll> My wild guess so far is that clsql loads *mysql*.so files and at the
 ll> same time hunchentoot creates a thread and somehow that causes issues
 ll> within sbcl

i can confirm the problem on SBCL 1.0.12. following test case is enough:
----
(eval-when (:compile-toplevel :load-toplevel :execute)
  (asdf:operate 'asdf:load-op 'hunchentoot))

(defpackage :clsqlhunch)
(cl:in-package :clsqlhunch)

(cl:print "starting server") (cl:terpri)

(cl:defparameter *server* (hunchentoot:start-server :port 7777))

(cl:print "server started") (cl:terpri)
----

it prints only "starting server" and hangs on hunchentoot:start-server. note 
that CLSQL is not used, it perfectly hangs w/o it.

hanging occurs only if you do (load (compile-file "test.lisp")), it works 
fine if you just do (load "test.lisp")

exact place where it hangs is hunchentoot::start-up-server, in this wicked 
portion of code:

        (loop until done do (sleep .1))

here it waits until thread it spawns does it job and modifies done variable.
however thread gets blocked when creating the socket:

                       (setf socket (make-instance 
'sb-bsd-sockets:inet-socket
                                       :type :stream
                                       :protocol :tcp)
                             (sb-bsd-sockets:sockopt-reuse-address socket) 
t)

i believe that happens because of some lock held when loading FASL file (if 
it was ABCL i'd suspect autoload happening).
thus, we have a deadlock situation: loading waits until socket is created, 
but socket cannot be created until loading process releases lock.

if we abort loading process via Ctrl-C, open-socket-and-accept goes on --  
creates socket, initializes and and starts processing loop. this confirms 
that deadlock occurs because of some lock in FASL loading.

while workaround is trivial -- just don't compile file in which you're 
starting server, it might be more tricky when you're using ASDF that 
compiles all files.

so i suggest SBCL folks to clarify whether it's OK that creating socket in 
thread is blocked by fastloading. if they consider this a bug, they'll fix 
this and it will work fine.

if it's "feature by design" in SBCL, i believe hunchentoot should be fixed 
to avoid this problem.
From: Alex Mizrahi
Subject: Re: clsql hunchentoot problem working together
Date: 
Message-ID: <477b8274$0$90268$14726298@news.sunsite.dk>
 AM> exact place where it hangs is hunchentoot::start-up-server, in this 
wicked
 AM> portion of code:

 AM>         (loop until done do (sleep .1))

 AM> if it's "feature by design" in SBCL, i believe hunchentoot should be
 AM> fixed to avoid this problem.

in a second look, i don't see why start-up-server is implemented in this 
weird way.
what's wrong with setting up socket in running thread and then spawning 
thread with solely processing loop? that would be too easy? 
From: lisp linux
Subject: Re: clsql hunchentoot problem working together
Date: 
Message-ID: <HZGdnR3xXYfASBzanZ2dnUVZ_tyknZ2d@comcast.com>
Alex Mizrahi wrote:
>  ll> My wild guess so far is that clsql loads *mysql*.so files and at the
>  ll> same time hunchentoot creates a thread and somehow that causes issues
>  ll> within sbcl
> 
> i can confirm the problem on SBCL 1.0.12. following test case is enough:
> ----
>...snipped excellent debugging info ...

Thank you so much.

In the meantime I am working around (I hope) this stuff by doing something like
(mostly by looking around other libraries cause asdf documentation did not really help)

Have the following in a asd file

(asdf:defsystem :scratch
   :serial t
   :depends-on (
                :hunchentoot
...
                )
   :components ((:file "packages")
...
                (:file "server")
...
                )
   )


(defmethod perform :after ((o load-op) (c (eql (find-system 'scratch))))
   (funcall (find-symbol "START-SERVER" "SCRATCH")))

and having the following in my  server file

(in-package :scratch)

(defvar *server* nil)

(defun start-server ()
   (unless *server*
     (setf *server* (hunchentoot:start-server :port 7777))))
....

and I don't really like it :(

Sorry for casting doubts on clsql

-Antony