[Bese-devel] UCW Installation

[Waldo Rubinstein]

On Sep 6, 2005, at 4:02 AM, Marco Baringer wrote:

> Waldo Rubinstein <waldo at trianet.net> writes:
>
>
>> Just as an FYI, I tried to install a fresh copy of UCW on a  Mac OS
>> machine with SBCL and came across a couple of problems:
>>
>> 1) The copy of UCW I downloaded via darcs (stable version) does not
>>    work with stable version of arnesi (darcs). It worked with
>>    arnesi_dev
>>
>
> hm. that's not very nice is it :(
>
> try using ucw_dev and arnesi_dev, except for those times when i'm
> being really stupid (doing things on the dev branch i should do on
> other temporary branches) _dev is your best bet (unless you have
> running code and you don't want to get api changes).

Thanks. That worked. Both using the _dev versions.

>
>
>> 2) After it finally compiled everything, the console shows:
>>
>> WARNING: Can't start slime server due to lack of threads.
>> 2005-09-05T23:21.50 +INFO+ IT.BESE.UCW::UCW-LOGGER: Starting up
>> standard server #<STANDARD-SERVER HTTPD-BACKEND 2 {405B71C9}>.
>>
>> I don't necessarily know what the WARNING means, however, looking at
>> the next line, seems to indicate the server is running.
>>
>
> this is just a fyi telling the user that they can't slime-connect. you
> can safely ignore it (or use a lisp which has threads).
>
> the 'work around' to this, if you want to use slime's debugger for ucw
> errors, is to load up bin/start.lisp but comment out the
> (ucw:startup-server ucw:*default-server*) form and execute
> (swank:create-server :dont-close t :external-format
> (external-format-for :slime)). then connect to slime (M-x
> slime-connect) and from the repl in emacs run (ucw:startup-server
> ucw:*default-server*). you won't have an active repl you can execute
> forms in but at least when there's a ucw error you can use slime's
> debugger/inspector and the mighty slime-eval-in-frame.

This brings up a couple of additional questions:

1) Are these errors specific to SBCL?
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?
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

>
>
>> Unfortunately, when I go to http://localhost:8080/ucw/examples/
>> index.ucw, I get the following error:
>>
>> 2005-09-05T23:22.07 +ERROR+ IT.BESE.UCW::UCW-LOGGER: Error #<SIMPLE-
>> ERROR {10F3F6B9}> while serving action.
>> 2005-09-05T23:22.07 +ERROR+ IT.BESE.UCW::UCW-LOGGER: Aborting action.
>> Control stack guard page temporarily disabled: proceed with caution
>>
>> debugger invoked on a SB-KERNEL::CONTROL-STACK-EXHAUSTED: Control
>> stack exhausted (no more space for function call frames).  This is
>> probably due to heavily nested or infinitely recursive function
>> calls, or a tail call that SBCL cannot or has not optimized away.
>>
>
> oh my. this is bad :( would you mind sending a complete backtrace?

I don't know if it had anything to do with the fact that I was not  
using the latest versions of each. Once I tested ucw_dev and  
arnesi_dev, everything worked. I will try to load again ucw and  
arnesi_dev and see if I can replicate it. How can I get a complete  
backtrace?

>
>
>> The Mac is running Mac OS X Tiger (10.4) with SBCL 0.9.4
>>
>
> i tried with 10.3.9 and sbcl 0.9.3.2, ucw_dev and arnesi_dev and the
> examples ran fine.
>
> -- 
> -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
>

Thanks,
Waldo