[Bese-devel] LispWorks and UCW

[Marco Baringer]

Juergen Gmeiner <gj at gjdv.at> writes:

> i ran into the same problem as friedrich dominicus, my solution
> is attached in arnesi.patch (i use a current ucw from the darcs repo,
> and a downloaded 0.3.7 for arnesi/yacml/... - so maybe this is already
> fixed in a "current" arnesi.

not fixed. thanks for the patch. i'm currently studying pascal
costanza's closer-mop package to see if we can use that instead of the
mopp stuff in arnesi.

> additionaly, my most annoying problem was errors (like the error
> example) would hang the server process by entering an endless loop
> (at least when working in the ide instead of via slime).
> i tracked down the problem in the slime code, see slime.patch
>
> i will submit the slime patch to the slime-maintainers as well,
> but i think that ucw uses the backtracking stuff differently than
> slime does internally ... so this is probably not a problem for them,
> and it may or may not make it in.

i'll apply the slime patch asap.

> also, a couple of typos/small stuff i ran into with ucw.
> - lispworks can do threading ... although it has to be enabled
>      (development images do this by default thought).
>      better would be to check if it has been enabled

how can we check for this?

> - if running ucw without threading and an error occurs, aborting
>      will kill the listener, and the associated log streams will not
>      work anymore.  trying to shutdown the server (so the socket is freed)
>      from a new listener will not work because the logging signals an error

oh my. aborting a request should not be so catastrofic (personally i
only use the server-error restart so i haven't run into this issue)

> - presentations.lisp will not compile with :accessor :decimal-sperator

i don't think i even use that...

> - i also have tbnl loaded, and tbnl also comes with rfc2388. as
>   tbnl's version is "improved" (additional optional arguments) but
>   backwards compatible, i read-time conditionalized the dependency

i've been talking to janis about this. a new rfc2388 release just came
out and ucw will stop including its own copy of it.

> also a question: it would be instructive to look at a "real"
> ucw application's source ... is there any large open-source
> application that uses ucw?

not that i know of. (if anyone does have a large open source ucw app
i'd love to hear about it).

> cheers,
> juergen

thanks a lot.
-- 
-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