Antiweb b 7 Compiling Error on SBCL Debian

[Watt]

I tried out SBCL 1.0.2 and i got this error

************* Antiweb Build Script *************
BUILD: Compiling and loading CL-PPCRE by Edi Weitz (please be patient)
BUILD: Compiling and loading CFFI by James Bielman (please be patient)
BUILD: Compiling and loading Let Over Lambda, Antiweb production
edition
BUILD: Compiling and loading ISAAC random number generator

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
0: [CONTINUE] Ignore and continue with next --eval option.
1: [ABORT ] Skip rest of --eval options.
2: Skip to toplevel READ/EVAL/PRINT loop.
3: [QUIT ] Quit SBCL (calling #'QUIT, killing the process).

((COMMON-LISP:FLET #:LAMBDA135)
#<COMMON-LISP:UNDEFINED-FUNCTION UNSIGNED-BYTE {AE67831}>)
0]

Is there a library missing?


Thanks for your help,



Watt P.

[do...@hcsw.org]

Hi Watt,

I haven't compiled on SBCL before. Soon I hope to port it
(patches gladly accepted). It looks like it is having trouble
compiling the ISAAC random number generator which lives in
bundled/isaac.lisp. That error message makes it look like it
is tripping up on unsigned-byte type declarations? I'll try
to give SBCL a go soon but it's not high on my priority list,
sorry.

BTW, I think 1.0.2 is a bit dated. Maybe an upgrade would
help by fixing some old bugs but with SBCL you'll probably
have new bugs to deal with. ;)

Good luck,

Doug

PS. There are several places in the source where +cmu and
+clisp are used to target those implementations. +sbcl
clauses will need to be added when AW is ported.

> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "antiweb" group.
> To post to this group, send email to ant...@googlegroups.com
> To unsubscribe from this group, send email to antiweb+u...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/antiweb?hl=en
> -~----------~----~----~----~------~----~------~--~---

[Watt]

I have tried again to compile on SBCL. I finally found something
about deftype unsigned-byte:

(deftype unsigned-byte (&optional bits)
(list 'integer 0 (if (eq bits '*) bits 256)))

So I put it in to issaac.lisp with #+sbcl. However it complains about
the cl package being locked. I am pretty confused because sbcl does
not seem to have unsigned-byte function. Added to that, even when I
choose to unlock the package, it still complains function is not
found.


Watt P.

> signature.asc
> < 1KViewDownload

[do...@hcsw.org]

On Tue, Oct 14, 2008 at 09:00:43PM -0700 or thereabouts, Watt wrote:
>
> I have tried again to compile on SBCL. I finally found something
> about deftype unsigned-byte:
>
> (deftype unsigned-byte (&optional bits)
> (list 'integer 0 (if (eq bits '*) bits 256)))
>
> So I put it in to issaac.lisp with #+sbcl. However it complains about
> the cl package being locked. I am pretty confused because sbcl does
> not seem to have unsigned-byte function. Added to that, even when I
> choose to unlock the package, it still complains function is not
> found.

Hi Watt,

Thanks for looking into SBCL. Looks like SBCL might work if we
explicitly specify integer ranges in isaac.lisp instead of
using unsigned-byte. I promise I will look into AW portability
soonish. Now that I have a 64 bit chip I wanna run it on
ClozureCL/linux and I'll eventually try SBCL too. My biggest concern
with both these implementations is threading. Antiweb doesn't
use threads at all and it will be dangerous if you incorporate
lisp libraries that use threads. 99+% of fatal lisp crashes are
somehow related to threads. Threads (by which I mean pre-emptively
scheduled, shared-memory processes) are like heroin:
Just don't do it. ;)

AW runs great on CMUCL and CLISP for me and that's all I'm really
concerned with at the moment. I'm working on Apache compatible
axs logs now. This should be in BETA8.

Good luck,

Doug

PS. The isaac.lisp file is only needed to create session IDs
and other things that require good random numbers. If you
don't need this you can leave isaac.lisp out of build.lisp
and everything else should work (except for prolly a few
function undefined warnings when it compiles antiweb.lisp).

[do...@hcsw.org]

Hi Watt,

I'm forwarding this message to the list. Thanks for questions
but under most circumstances, it is probably best to ask
questions on the list.

On Fri, Oct 17, 2008 at 08:58:29PM -0700 or thereabouts, Watt wrote:
> I totally agree on your opinion about threads. This leads me to have
> a follow up question. Would it be a given that the code that is
> called within AWP will be donw in process and not thread by default?

Each AW process runs exactly one thread. When you are computing
things, make sure you don't do anything that will take a long time
(especially don't use the network) because it will prevent the
single thread from doing other things. For doing things like
sending email, long running computational tasks, queries that
require remote data-base access, etc, I recommend using a CGI
script. However, Antiweb's BerkeleyDB support is extremely fast
and it IS designed to work in the AW process for most workloads.

Also, AW is designed to handle many vhosts. A technique I
use is to break a site up into lots of processes. For example:

A) A main HTML generating process that compiles and serves
the AWP files.

B) A static.mydomain.com which hosts things like images,
JS libraries, etc. It has a low keepalive time because
these files are cached by the browser anyways so keepalives
aren't very important.

C) A data.mydomain.com process that handles small queries to
BerkeleyDB and replies with javascript. This has as high
a keepalive as possible for AJAX optimisation. (good
candidate process for CMUCL)

D) A contact.mydomain.com process that spawns perl scripts
for sending emails to us. (good candidate for CLISP)

E) Others depending on the exact application.

Remember that async servers like AW, lighttpd, and nginx
compared to process(or thread)-per-connection servers like
Apache have much different performance characteristics.
You can run many completely separate instances of the server
because of their low memory requirements per connection.

> On Clozure port, would that be officially released? That will be
> great.

When I get around to it, yes, it will be in the subsequent
release (probably not the next one).

Doug

[Watt]

Thanks Doug,

I have more time these few days to read your code and try to
understand more. I think this will be interesting to those, like me,
who wants to use AW for application development. Maybe you can
correct me if what I understand is close to what is being done. Each
Unix socket = one AW process, each client call will be serviced with
one socket/ AW process. It is advised to separate out different
application tasks mapped to different vhosts/url based services.
States will be passed around using BDB.

> signature.asc
> < 1KViewDownload

[Watt]

I got some time yesterday to look at isaac code. It was loaded
successfully on SBCL without the defpackage part

(defpackage #:isaac
(:export #:init-null-seed
#:init-kernel-seed
#:init-common-lisp-random-seed
#:rand32
#:rand-bits))

(in-package #:isaac)

I do not really know what stop the package from loading on SBCL
though. Just FYI.