[Bese-devel] UCW Installation

[Waldo Rubinstein]

I guess all these issues would be resolved with a thread-enabled Lisp  
version.

I installed SBCL on Tiger from Darwinports, so I didn't really  
compile it. The Darwin 'port' took care of that for me and I guess it  
didn't enable threads.

Reading about so many different versions of Lisp concerns me with  
regards to application compatibility. That's the reason I'm using  
SBCL because it runs on Mac as well as Linux.

 From a high level perspective, it may be a naive decision because  
the same "brand" of Lisp may run on multiple platforms with different  
compatibility levels.

Because I'm new to Lisp, I wasn't sure if I developed an application  
on my Mac, will I be able to run in on my Linux production  
environment? I suppose that as long as my app conform to CL  
Standards, I should be OK. However, reading on CLISP's web site, it  
says it "implements most of the ANSI standard". Then, what open- 
source Lisp versions are out there are conform to ANSI standards so  
that applications "should" run unmodified across them?

May be you guys that have more experience can briefly suggest which  
Lisps are more standards and that I can develop on Mac and deploy on  
Linux.

Thanks again,
Waldo

On Sep 10, 2005, at 1:24 PM, Marco Baringer wrote:

> Waldo Rubinstein <waldo at trianet.net> writes:
>
>
>> 1) Are these errors specific to SBCL?
>>
>
> they are specific to any single thread lisp. recompile your sbcl and
> add threads.
>
>
>> 2) One thing that attracted me from what I read was the ability to
>>    debug and fix a running application (similar to what can be done
>>    with  Squeak/Seaside). Will this impose any limitations to that
>>    end?
>>
>
> yes. within a single thread lisp you've only two ways two fix the code
> of the app:
>
> 1) from the repl in the admin app.
>
> 2) via sldb-eval-in-frame after an error has occured.
>
> neither of these are particularly convenient. you can get by with tese
> in production servers (where update are relativly rare) but i would
> strongly urge you to use not use a single threaded lisp for
> development. (i have an app which is developed on openmcl and then
> deployed on clisp+windows)
>
>
>> 3) What will happen when UCW is handling many requests and some may
>>    take longer to execute (kind of blocking the VM)? Can some  
>> requests
>>    block other users from using the system? Say trigger an event from
>>    the browser where UCW needs to parse a very large text file and
>>    write  the results to some persistent storage. Could this cause a
>>    problem? I  found it did create a problem in Squeak/Seaside
>>
>
> that is exactly what happens in a singel thread lisp. i strongly
> suggest you get a multi-threaded lisp, the free options are:
>
> linux: sbcl, cmucl
> darwin: openmcl
>
> on windows you'll need to buy allegro or lispworks (or port cmucl or
> sbcl to windows or add multi-threading to clisp).
>
> -- 
> -Marco
> Ring the bells that still can ring.
> Forget the perfect offering.
> There is a crack in everything.
> That's how the light gets in.
>     -Leonard Cohen
>