Re: Webactions / SBCL

Memet Bilgin <[email protected]> wrote:

>  I've actually managed to make it work right now, however, I've made
> many many changes to the source and have had to recompile many times
> given that there's different versions of the libraries floating
> around.

Sounds painfull.  Sorry to hear it caused you grief.

>  I have indeed rolled out my own version of sb-bsd-sockets with the
> added auto-close key. I also have to apply this kludge before loading/
> compiling the files:
> 
> (defun SB-IMPL::char->utf8 (char) char)
> 
>  And finally, the load.cl file for webactions has a sys:copy-file
> function which does not exist out of the box on my sbcl. I've replaced
> this with a simple rename-file call.

I used the asd for webactions and it worked out of the box, not that
it's too different from changing and loading the load.cl file.

>  One thing that I know for sure is that using the acl-compat package
> you get from asdf-install does not work. It has to be the acl-compat
> from that enhanced paserve tarball from sourceforge. I think the
> SYS:copy-file method is defined in the other version of acl-compat.

Possibly.  I think since this is an enhanced version for sbcl it's
making the claim that it needs these specialized versions of common
libraries.

>  However, trying to build with that acl-compat gives me *many* errors
> with SB-GRAY:EXTERNAL-FORMAT value being unbound.
> 
>  Like I said, long story short is that it just doesn't work out of
> the box. Now I'm left wondering if it actually does work fully or if I
> just managed to make it simply build properly but there are some nasty
> bugs lurking inside.

There could be.  From the version that I've built there are several
warnings that are printed out I'd like to go back and investigate.
Since you are using a branch of a branch of a supported product there
really is no guarantee that it's going to work exactly like the
original.  I'd like to spend some time with it and maybe get a version
up on github that solves many of the issues you've struggled with.

>  The other thing that worries me is that I originally had a built wa
> +aserve, but when actually going to a published wa page, it would
> chunk out with weird "OBJECTS not bound in CLP entity" style errors (I
> paraphrase). And sometimes, but not always, it would again chunk out
> with "2 is not a list", which through debugger inspection revealed
> that again OBJECTS was probably improperly assigned the value 2
> somewhere in the stack.
>  These errors seem to be resolved now, mind you.

Good to hear they were resolved by persistence.  Building this version
of portableaserve is rather specific in the versions of libraries it
uses, so it's understandable that it might not work perfectly on the
first try and with other versions.

>  Do you use wa/aserve it in on a production system with a lisp other
> than allegro? Or is it with AllegroCL?

In house we use acl and the entire process you've been through is
replaced by (require :webactions).  I personally would like to get
portable aserve to be as easy.

> Thanks, let me know how it goes.

Smoother than what you discribe, but still complex.  I grabbed sbcl from
git and built it with the :auto-close modification to sb-bsd-sockets.
Then I grabbed portable-aserve code from cliki.net, unpacked it and
linked in the asd files.  I did need to grab md5 from git.b9.com to get
all the requirements, but for all others I used what was provided in the
tar from cliki.net.

>  PS. Is there some sort of smoke test for wa?

There is a t-webactions.cl file in the portableaserve/webactions/test
directory of the tarball that uses the tester test framework that
can be found here:

   http://opensource.franz.com/test/index.html

I think we are going to put tester on github soon and then convert the
opensource.franz.com page into basically a pointer to github, so that
link in a few days might not work.  In that case go to: 

   http://opensource.franz.com

and follow the link to tester.

Cheers,
Elliott