From randomtalk at gmail.com  Sat Apr  2 20:34:38 2005
From: randomtalk at gmail.com (Jason Wang)
Date: Sat, 2 Apr 2005 15:34:38 -0500
Subject: [Bese-devel] problem while starting ucw
Message-ID: <939cf2005040212347b820963@mail.gmail.com>

hi, i have followed the instructions came with ucw 0.3.5, and i typed
in (load "/var/www/ucw/init.lisp") after putting path into asdf
central-registry, it then gave me this error after 2 seconds:

component :RFC2388 not found, required by #SYSTEM "ucw" {58685855}>

i'm usinc CMUCL, and i have slime, mod_lisp2 and apache2 installed..

anyone know what's going on?
-- 
www.programer.name - my own personal blog : )


From mb at bese.it  Sun Apr  3 20:56:21 2005
From: mb at bese.it (Marco Baringer)
Date: Sun, 03 Apr 2005 22:56:21 +0200
Subject: [Bese-devel] problem while starting ucw
In-Reply-To: <939cf2005040212347b820963@mail.gmail.com> (Jason Wang's
	message of "Sat, 2 Apr 2005 15:34:38 -0500")
References: <939cf2005040212347b820963@mail.gmail.com>
Message-ID: <m2zmwfa8ay.fsf@soma.local>

Jason Wang <randomtalk at gmail.com> writes:

> hi, i have followed the instructions came with ucw 0.3.5, and i typed
> in (load "/var/www/ucw/init.lisp") after putting path into asdf
> central-registry, it then gave me this error after 2 seconds:
>
> component :RFC2388 not found, required by #SYSTEM "ucw" {58685855}>
>
> i'm usinc CMUCL, and i have slime, mod_lisp2 and apache2 installed..
>
> anyone know what's going on?

you're either missing the rfc2388 library or asdf just isn't finding
it. if you have a directory named ucw/libs/rfc2388 then just put a
symmlink from ucw/libs/rfc2388/rfc2388.asd to whatever directory holds
your asdf system defs. if you don't have this directory you need to
download and install rfc2388.

however i'd strongly suggest upgrading to ucw 0.3.7 (the development
version in arch would be even better if you can).

-- 
-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


From mb at bese.it  Tue Apr  5 12:43:21 2005
From: mb at bese.it (Marco Baringer)
Date: Tue, 05 Apr 2005 14:43:21 +0200
Subject: [Bese-devel] LispWorks and UCW
In-Reply-To: <4252843B.1090306@gjdv.at> (Juergen Gmeiner's message of "Tue,
	05 Apr 2005 14:27:39 +0200")
References: <87wtrxxtv5.fsf@flarge.here> <m2hdj1uxba.fsf@soma.local>
	<4252843B.1090306@gjdv.at>
Message-ID: <m2mzsdfl7a.fsf@soma.local>

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


From gj at gjdv.at  Tue Apr  5 12:27:39 2005
From: gj at gjdv.at (Juergen Gmeiner)
Date: Tue, 05 Apr 2005 14:27:39 +0200
Subject: [Bese-devel] LispWorks and UCW
In-Reply-To: <m2hdj1uxba.fsf@soma.local>
References: <87wtrxxtv5.fsf@flarge.here> <m2hdj1uxba.fsf@soma.local>
Message-ID: <4252843B.1090306@gjdv.at>

Marco Baringer wrote:
> Friedrich Dominicus <frido at q-software-solutions.de> writes:

>>Now it happens that this has failed for some symbols, but I suppose
>>that should not have happened. I know that the following is just a
>>hackerish solution to the problem:

> 
> odd. apparently our provide-mopp-symbol isn't doing what it should. it
> would be very helpfull if you: 1) trace mopp::provide-mopp-symbol 2)
> reload mopp.lisp 3) check what (find-symbol (string
> 'mopp::standard-class) :CLOS) returns.
> 

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.

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.

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
- 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
- presentations.lisp will not compile with :accessor :decimal-sperator
- 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

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?

cheers,
juergen


-------------- next part --------------
A non-text attachment was scrubbed...
Name: arnesi.patch
Type: text/x-patch
Size: 1421 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20050405/3905edd8/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ucw.patch
Type: text/x-patch
Size: 2082 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20050405/3905edd8/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: slime.patch
Type: text/x-patch
Size: 1367 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20050405/3905edd8/attachment-0002.bin>

From gj at gjdv.at  Tue Apr  5 13:32:16 2005
From: gj at gjdv.at (Juergen Gmeiner)
Date: Tue, 05 Apr 2005 15:32:16 +0200
Subject: [Bese-devel] LispWorks and UCW
In-Reply-To: <m2mzsdfl7a.fsf@soma.local>
References: <87wtrxxtv5.fsf@flarge.here>
	<m2hdj1uxba.fsf@soma.local>	<4252843B.1090306@gjdv.at>
	<m2mzsdfl7a.fsf@soma.local>
Message-ID: <42529360.8070703@gjdv.at>

Marco Baringer wrote:

>>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.

so i don't have to post this to the slime-devel list?

btw, while composing my mail to slime-devel, i played around
some more with my test-case.

the bug
- affects my test-case in the ide and slime
- does not affect normal slime backtraces, because when
    slime prints a backtrace, it does so by hijacking the
    normal ide debugger - and there is always an invoke-debugger
    frame on the stack.
- with ucw operation, the bug does not occur when having a
    slime connected, because in that case, ucw triggers the
    slime debugger, which works.
    only when ucw tries to send a html-backtrace to the browser is
    the bug triggered

in case you are interested, i attached the test case.

> 
> how can we check for this?
> 

i don't know, but i've asked on the lisphug mailing list.
i'll let you know if/when i hear something.


regards,
juergen

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: slime-bug.lisp
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20050405/91bfb081/attachment.ksh>

From mb at bese.it  Tue Apr  5 13:48:28 2005
From: mb at bese.it (Marco Baringer)
Date: Tue, 05 Apr 2005 15:48:28 +0200
Subject: [Bese-devel] LispWorks and UCW
In-Reply-To: <42529360.8070703@gjdv.at> (Juergen Gmeiner's message of "Tue,
	05 Apr 2005 15:32:16 +0200")
References: <87wtrxxtv5.fsf@flarge.here> <m2hdj1uxba.fsf@soma.local>
	<4252843B.1090306@gjdv.at> <m2mzsdfl7a.fsf@soma.local>
	<42529360.8070703@gjdv.at>
Message-ID: <m2ekdpfi6r.fsf@soma.local>

Juergen Gmeiner <gj at gjdv.at> writes:

> so i don't have to post this to the slime-devel list?

i just commited it so, unless you want to ask other slimers for
comments or something, no.

> in case you are interested, i attached the test case.

unfortunetly i don't have a lispworks system to run this on.

>> how can we check for this?
>> 
>
> i don't know, but i've asked on the lisphug mailing list.
> i'll let you know if/when i hear something.

ok.

-- 
-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


From mb at bese.it  Tue Apr  5 14:08:09 2005
From: mb at bese.it (Marco Baringer)
Date: Tue, 05 Apr 2005 16:08:09 +0200
Subject: [Bese-devel] LispWorks and UCW
In-Reply-To: <4252843B.1090306@gjdv.at> (Juergen Gmeiner's message of "Tue,
	05 Apr 2005 14:27:39 +0200")
References: <87wtrxxtv5.fsf@flarge.here> <m2hdj1uxba.fsf@soma.local>
	<4252843B.1090306@gjdv.at>
Message-ID: <m2acodfh9y.fsf@soma.local>

Juergen Gmeiner <gj at gjdv.at> writes:

> diff -rN -udp old-ucw_0.3.7/libs/arnesi/src/mopp.lisp new-ucw_0.3.7/libs/arnesi/src/mopp.lisp
> --- old-ucw_0.3.7/libs/arnesi/src/mopp.lisp	2005-02-28 18:03:38.000000000 +0100
> +++ new-ucw_0.3.7/libs/arnesi/src/mopp.lisp	2005-03-24 23:38:50.000000000 +0100
> @@ -335,12 +335,13 @@ object wrapping OBJECT."
>  ;;;; mopp:direct-slot-definition-value accordingly.
>  
>  #+mopp::have-mop
> -(eval-when (:compile-toplevel :execute)
> -  (defclass %meta-class (standard-class) ())
> +(progn ;; class not defined when loading
> +  (defclass %meta-class (cl:standard-class) ())

is is the same if we just add the :load-toplevel here? (openmcl needs
:compile-toplevel for this to work).

>    (defmethod mopp:validate-superclass ((c %meta-class) (s mopp:standard-class)) t)
>  
> -  (defclass %dsd (mopp:standard-direct-slot-definition)
> +  (defclass %dsd (#-lispworks mopp:standard-direct-slot-definition
> +                              #+lispworks clos::standard-direct-slot-definition)
>      ((%slot :accessor %slot :initarg :%slot :initform nil)))
>  
>    (defmethod mopp:direct-slot-definition-class ((c %meta-class) &rest initargs)


From mb at bese.it  Tue Apr  5 14:59:43 2005
From: mb at bese.it (Marco Baringer)
Date: Tue, 05 Apr 2005 16:59:43 +0200
Subject: [Bese-devel] LispWorks and UCW
In-Reply-To: <4252843B.1090306@gjdv.at> (Juergen Gmeiner's message of "Tue,
	05 Apr 2005 14:27:39 +0200")
References: <87wtrxxtv5.fsf@flarge.here> <m2hdj1uxba.fsf@soma.local>
	<4252843B.1090306@gjdv.at>
Message-ID: <m2u0mle0bk.fsf@soma.local>

Juergen Gmeiner <gj at gjdv.at> writes:

> - 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

[last question then i promise i'll shutup.]

I just commited a change to arnesi's logging stuff. We now check
whether the stream is closed and, if it is, singal an error with a
couple of restarts. This will require you to work your way through
another set of restarts when attempting to shutdown the server but, i
think, this is preferable (since you can chose to use the new value of
*standard-output* or *debug-io*) to just ignoring errors in
shutdown-backend. 

do you have a better idea? does the use-*debug-io* restart work on
lispworks (i only performed cursury testing on openmcl)?

-- 
-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


From gj at gjdv.at  Tue Apr  5 15:34:20 2005
From: gj at gjdv.at (Juergen Gmeiner)
Date: Tue, 05 Apr 2005 17:34:20 +0200
Subject: [Bese-devel] LispWorks and UCW
In-Reply-To: <m2ekdpfi6r.fsf@soma.local>
References: <87wtrxxtv5.fsf@flarge.here>
	<m2hdj1uxba.fsf@soma.local>	<4252843B.1090306@gjdv.at>
	<m2mzsdfl7a.fsf@soma.local>	<42529360.8070703@gjdv.at>
	<m2ekdpfi6r.fsf@soma.local>
Message-ID: <4252AFFC.4070101@gjdv.at>

Marco Baringer wrote:
> Juergen Gmeiner <gj at gjdv.at> writes:
> 
>>>how can we check for this?
>>>
>>
>>i don't know, but i've asked on the lisphug mailing list.
>>i'll let you know if/when i hear something. 
> 
> ok.
> 

from a response by dave fox:

  > how do i know if multiprocessing has been enabled in an image
  > by calling mp:initialize-multiprocessing?
  >
  > i am asking because ucw with the mod_lisp backend currently just runs
  > in the thread it was started in.  starting it in a separate thread
  > can be easily achieved by a read-time cond on :lispworks, but
  > doing this by default would break ucw for non-mp images ...
  >
  > so is there something like mp:multiprocessing-initialized-p ?

No, but you could simply treat the value of MP:*CURRENT-PROCESS* as a
generalized boolean, or similarly the value returned by
MP:LIST-ALL-PROCESSES.

cheers,
juergen


From gj at gjdv.at  Tue Apr  5 15:54:14 2005
From: gj at gjdv.at (Juergen Gmeiner)
Date: Tue, 05 Apr 2005 17:54:14 +0200
Subject: [Bese-devel] LispWorks and UCW
In-Reply-To: <m2acodfh9y.fsf@soma.local>
References: <87wtrxxtv5.fsf@flarge.here>
	<m2hdj1uxba.fsf@soma.local>	<4252843B.1090306@gjdv.at>
	<m2acodfh9y.fsf@soma.local>
Message-ID: <4252B4A6.40400@gjdv.at>

Marco Baringer wrote:
> Juergen Gmeiner <gj at gjdv.at> writes:
> 
> 
>>diff -rN -udp old-ucw_0.3.7/libs/arnesi/src/mopp.lisp new-ucw_0.3.7/libs/arnesi/src/mopp.lisp
>>--- old-ucw_0.3.7/libs/arnesi/src/mopp.lisp	2005-02-28 18:03:38.000000000 +0100
>>+++ new-ucw_0.3.7/libs/arnesi/src/mopp.lisp	2005-03-24 23:38:50.000000000 +0100
>>@@ -335,12 +335,13 @@ object wrapping OBJECT."
>> ;;;; mopp:direct-slot-definition-value accordingly.
>> 
>> #+mopp::have-mop
>>-(eval-when (:compile-toplevel :execute)
>>-  (defclass %meta-class (standard-class) ())
>>+(progn ;; class not defined when loading
>>+  (defclass %meta-class (cl:standard-class) ())
> 
> 
> is is the same if we just add the :load-toplevel here? (openmcl needs
> :compile-toplevel for this to work).
> 
> 

does not work, i get

; (DEFCLASS IT.BESE.ARNESI.MOPP%INTERNALS::%META-CLASS)


**++++ Error in (METHOD IT.BESE.ARNESI.MOPP:VALIDATE-SUPERCLASS 
(IT.BESE.ARNESI.MOPP%INTERNALS::%META-CLASS 
IT.BESE.ARNESI.MOPP:STANDARD-CLASS)):
   IT.BESE.ARNESI.MOPP:STANDARD-CLASS is not the name of a class
; (TOP-LEVEL-FORM 5)
; *** 1 error detected, no fasl file produced.


how about:

(eval-when (#-lispworks :compile-toplevel :load-toplevel :execute)

   (defclass %meta-class (cl:standard-class) ())

this works on lispworks/linux - i can't check openmcl ;-)

cheers,
juergen


From mb at bese.it  Wed Apr  6 10:02:11 2005
From: mb at bese.it (Marco Baringer)
Date: Wed, 06 Apr 2005 12:02:11 +0200
Subject: [Bese-devel] api breakage (the death of defapplication)
Message-ID: <m2mzscmdek.fsf@soma.local>


i've removed the defapplication macro and developers are now required
to have seperate application definitition (aka make-instance
'standard-application) and registration (aka registration-application
*my-application-object*). while this is annoying it's the first step
for allowing lisp images containing ucw and ucw apps to be created,
see the new file bin/make-image.lisp for my initial attempts at such a
thing. the only major problem is left is setting up the paths of the
applications whcih may be different than thoes used when building the
image.

p.s. - i'm sure some other api changes have creeped in, this is just
the most visible one.

-- 
-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


From jdz at dir.lv  Thu Apr  7 10:27:18 2005
From: jdz at dir.lv (Janis Dzerins)
Date: Thu, 07 Apr 2005 13:27:18 +0300
Subject: [Bese-devel] api breakage (the death of defapplication)
In-Reply-To: <m2mzscmdek.fsf@soma.local>
References: <m2mzscmdek.fsf@soma.local>
Message-ID: <1112869638.8048.9.camel@localhost>

A small leftover from refactoring (diff attached).

-- 
Janis Dzerins

  If million people say a stupid thing, it's still a stupid thing.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mod-lisp.diff
Type: text/x-patch
Size: 512 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20050407/2a8cd0cc/attachment.bin>

From mb at bese.it  Thu Apr  7 16:15:37 2005
From: mb at bese.it (Marco Baringer)
Date: Thu, 07 Apr 2005 18:15:37 +0200
Subject: [Bese-devel] the mod-lisp backend
Message-ID: <m2psx6imvq.fsf@soma.local>


i started out wanting to make the mod_lisp multithread. in the course
of starting that i noticed that the mod_lisp backend was very similar
to a regular http server except for the wire protocol. i then decided
that it would be usefull (for newbies at least) to have a simple web
server inculded in ucw and it wouldn't be very hard to do starting
from mod_lisp (i'd just have to change the wire protocol).

but since i was going to implemente an http server, and since the http
server and mod_lisp backend are so similar i figured i'd make the http
server multitherad, then i could just override a couple of methods and
have a multithread mod_lisp "for free."

so what we have today (on the ucw--httpd--0.3 branch) is an almost
working multithread http server. it still has some issues i can't
figure out: 1) under heavy load (as many concurrent connections as
workers) connections are randomly dropped. 1) we get closed-socket
errors on the last request made by ab (this happens fairly often, but
not always). 3) i've ended up in openmcl's kernel debugger a couple of
times as well...

any comments or bug fixs to the new backend would be _greatly_
appreciated. i'm going to make this the default backend for ucw
distributions (with a big "do not use in production" notice) since its
so small and has such a trivial setup.

-- 
-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


From mb at bese.it  Thu Apr  7 16:16:20 2005
From: mb at bese.it (Marco Baringer)
Date: Thu, 07 Apr 2005 18:16:20 +0200
Subject: [Bese-devel] api breakage (the death of defapplication)
In-Reply-To: <1112869638.8048.9.camel@localhost> (Janis Dzerins's message of
	"Thu, 07 Apr 2005 13:27:18 +0300")
References: <m2mzscmdek.fsf@soma.local> <1112869638.8048.9.camel@localhost>
Message-ID: <m2ll7uimuj.fsf@soma.local>

Janis Dzerins <jdz at dir.lv> writes:

> A small leftover from refactoring (diff attached).

applied. thanks.

-- 
-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


From mb at bese.it  Fri Apr  8 10:09:12 2005
From: mb at bese.it (Marco Baringer)
Date: Fri, 08 Apr 2005 12:09:12 +0200
Subject: [Bese-devel] rfc2388
Message-ID: <m2u0mhh96f.fsf@soma.local>


Janis Dzerins has made a new release of rfc2388 cantianing and asdf
file and some fixs providde by edi weitz. therefore i've removed
rfc2388 from the ucw tree, you can get it from:

ftp://ftp.common-lisp.net/pub/project/rfc2388/

-- 
-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


From pupeno at pupeno.com  Fri Apr  8 17:23:46 2005
From: pupeno at pupeno.com (Pupeno)
Date: Fri, 8 Apr 2005 14:23:46 -0300
Subject: [Bese-devel] rfc2388
In-Reply-To: <m2u0mhh96f.fsf@soma.local>
References: <m2u0mhh96f.fsf@soma.local>
Message-ID: <200504081423.50606.pupeno@pupeno.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Je Vendredo Aprilo 8 2005 07:09, Marco Baringer skribis:
> Janis Dzerins has made a new release of rfc2388 cantianing and asdf
> file and some fixs providde by edi weitz. therefore i've removed
> rfc2388 from the ucw tree, you can get it from:
>
> ftp://ftp.common-lisp.net/pub/project/rfc2388/

This is indeed good news! :D Very good news for us packagers, I'm hepling with 
Gentoo Lisp packages a bit and I'm interested in getting UCW as a clean 
package easy to install and roll. rfc2388 0.9 is already on Portage [1] (the 
Gentoo package repocitory).
Thank you and please keep the good work!
- -- 
Pupeno: pupeno at pupeno.com - http://pupeno.com
Reading Science Fiction ? http://sfreaders.com.ar

[1] http://packages.gentoo.org/packages/?category=dev-lisp;name=cl-rfc2388
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCVr4mfW48a9PWGkURAvG5AJ4/c62bGpmuvux/X102Qz3ToKiyggCfe43Y
GL9Fl2zQepJvP8rFiqff+KM=
=k4lD
-----END PGP SIGNATURE-----


From digash at gmail.com  Fri Apr  8 20:26:51 2005
From: digash at gmail.com (Dimitry Gashinsky)
Date: Fri, 8 Apr 2005 16:26:51 -0400
Subject: [Bese-devel] update failed need signature
Message-ID: <e2c76ba505040813262dc6ed8a@mail.gmail.com>

Hi Marco,

I am trying to update UCW using update script and running into problem with 
gpg keys. Which key do I need for it to succeed?

$ ./bin/update.sh 
Updating UCW
gpgkeys: key 3E58406D6450AA06 not found on keyserver


********************************

INVALID SIGNATURE ON REVISION!
archive: ucw-2004 at common-lisp.net
revision ucw--dev--0.3--patch-320
checksum file: checksum

********************************


trouble reading checksum file for 
ucw-2004 at common-lisp.net/ucw--dev--0.3--patch-320<http://ucw-2004 at common-lisp.net/ucw--dev--0.3--patch-320>

gzip: stdin: unexpected end of file
tar: Child returned status 1
tar: Error exit delayed from previous errors

$ gpg --list-key Marco
pub 1024D/4C66CCA7 2003-11-05 [expired: 2004-11-13)]
uid Marco Baringer <mb at bese.it>

pub 1024D/CDE9491D 2003-11-05 [expired: 2004-11-13)]
uid Marco Baringer (CL Hacker) <mbaringer at common-lisp.net>

pub 1024D/26DDF1B2 2004-11-11
uid Edward Marco Baringer <mb at bese.it>
uid Marco Baringer <mb at bese.it>
uid Marco Baringer <mbaringer at common-lisp.net>
sub 2048g/049B41A4 2004-11-11

Regards,
Dimitry
-- 
((lambda (lambda) `(,lambda ',lambda)) '(lambda (lambda) `(,lambda 
',lambda)))
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20050408/6aa2ea4f/attachment.html>

From pupeno at pupeno.com  Sat Apr  9 18:24:05 2005
From: pupeno at pupeno.com (Pupeno)
Date: Sat, 9 Apr 2005 15:24:05 -0300
Subject: [Bese-devel] Starting with UCW
Message-ID: <200504091524.07862.pupeno@pupeno.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,
I'm trying to get started with development of web applications with UCW, but I 
just can't find how.
I'm new to Lisp as well.
What I'm asking for is how to run an example that works, or some tutorial that 
works, every time I tried something I've found an error. I'm using the latest 
(I think) as retrieved with gnu arch. I've tried loading bin/start.lisp, but 
that gave me an error, most of the examples in examples/ didn't load either. 
Maybe it is my environment that is wrong, I don't know. I just want if you 
can point me one good way to get into development.
Thank you.
- -- 
Pupeno: pupeno at pupeno.com - http://pupeno.com
Reading Science Fiction ? http://sfreaders.com.ar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCWB3HfW48a9PWGkURAhRLAJsHllgbHV1D9qvtkWdv0kH5OQYiCgCfRaxX
sIIongZpcJYTPbM06AhA3Bw=
=Ix8Q
-----END PGP SIGNATURE-----


From randomtalk at gmail.com  Sun Apr 10 04:34:49 2005
From: randomtalk at gmail.com (Jason Wang)
Date: Sun, 10 Apr 2005 00:34:49 -0400
Subject: [Bese-devel] Starting with UCW
In-Reply-To: <200504091524.07862.pupeno@pupeno.com>
References: <200504091524.07862.pupeno@pupeno.com>
Message-ID: <939cf2005040921345390e7a5@mail.gmail.com>

yup, i was trying to figure out how to make the wiki example work also
:|.. apparently the guide didn't say exactly how to make all that code
work together :|.. someone please enlighten me on the exact precedure
as to how to make it work? thanks alot :D

Jason

-- 
www.programer.name - my own personal blog : )


From pupeno at pupeno.com  Sun Apr 10 21:38:40 2005
From: pupeno at pupeno.com (Pupeno)
Date: Sun, 10 Apr 2005 18:38:40 -0300
Subject: [Bese-devel] start.lisp and Slime
Message-ID: <200504101838.43203.pupeno@pupeno.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,
This is just an little usability problem. I can load start.lisp with (load 
"....../start.lisp") with no problem but I can't load it with C-c C-k 
(slime-compile-and-load-file) command of Slime, the error I get is:
- -+  Errors (1)
 `-- READER-ERROR at 1111 (line 30, column 33) on #<SB-SYS:FD-STREAM for "file 
\"/home/pupeno/src/ucw-dist/ucw/bin/start.lisp\"" {9272DE9}>:
     package "ARNESI" not found

That line is:

(eval-when (:compile-toplevel :load-toplevel :execute)
  (setf arnesi::*call/cc-returns* nil))

That's all, I don't really know how to fix it, it seems that setf is using 
arnesi which hasn't been loaded yet, but well, that's kinda obvius.
Thank you.
- -- 
Pupeno: pupeno at pupeno.com - http://pupeno.com
Reading Science Fiction ? http://sfreaders.com.ar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD4DBQFCWZzjfW48a9PWGkURAjhbAJUfS0PvkEbc51vqxl8OpxXWVUA6AJ9PJTcc
o1BR4vC26nn8oqghRSTbwQ==
=f1qt
-----END PGP SIGNATURE-----


From djwatson at docwatson.org  Mon Apr 11 03:51:53 2005
From: djwatson at docwatson.org (Dave Watson)
Date: Sun, 10 Apr 2005 20:51:53 -0700
Subject: [Bese-devel] setting client-value of a text field
Message-ID: <20050411035151.GA27445@attu2.cs.washington.edu>

Is there a way to set the client-value of a text field?   Setting the
lisp-value seems to work fine in an shared-initialize, but that
doesn't actually set the initial text sent to the client.   

-Dave Watson
djwatson at docwatson.org


From lutzj at operamail.com  Fri Apr  8 19:09:07 2005
From: lutzj at operamail.com (John Lutz)
Date: Fri, 08 Apr 2005 20:09:07 +0100
Subject: [Bese-devel] join
Message-ID: <20050408190908.3912021AFF9@ws5-6.us4.outblaze.com>

Hello all,
Can anyone tell me how to get UnCommon Web to work
with a browser?

using ucwctl start && ucwctl attach

There is an initial request, it logs the session, gets a cookie
then accepts no other request. The initial request forms
as a hang on the browser side.

Slime-connect in emacs results in Connecting to Swank on port
4005 and never does.

Regards,
John
-- 
_____________________________________________________________
Web-based SMS services available at http://www.operamail.com.
From your mailbox to local or overseas cell phones.

Powered by Outblaze


From mb at bese.it  Mon Apr 11 16:19:19 2005
From: mb at bese.it (Marco Baringer)
Date: Mon, 11 Apr 2005 18:19:19 +0200
Subject: [Bese-devel] update failed need signature
In-Reply-To: <e2c76ba505040813262dc6ed8a@mail.gmail.com> (Dimitry
	Gashinsky's message of "Fri, 8 Apr 2005 16:26:51 -0400")
References: <e2c76ba505040813262dc6ed8a@mail.gmail.com>
Message-ID: <m2aco5nv5k.fsf@soma.local>

Dimitry Gashinsky <digash at gmail.com> writes:

> Hi Marco,
>
> I am trying to update UCW using update script and running into problem with gpg
> keys. Which key do I need for it to succeed?

as of now: none. up to yesterday: one of my 3 keys (two of which i've
lost the private key). i'll keep signing the patches so that i'll
always be able to check the integrity of the code, but i've messed
things up too far to make signing the archives a good option.

-- 
-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


From digash at gmail.com  Mon Apr 11 22:47:53 2005
From: digash at gmail.com (Dimitry Gashinsky)
Date: Mon, 11 Apr 2005 18:47:53 -0400
Subject: [Bese-devel] update failed need signature
In-Reply-To: <m2aco5nv5k.fsf@soma.local>
References: <e2c76ba505040813262dc6ed8a@mail.gmail.com>
	<m2aco5nv5k.fsf@soma.local>
Message-ID: <e2c76ba505041115471547aff@mail.gmail.com>

On Apr 11, 2005 12:19 PM, Marco Baringer <mb at bese.it> wrote:

> as of now: none. up to yesterday: one of my 3 keys (two of which i've

Thanks works like a charm. I start using darcs some time ago and found
that it fine grained user interface is annoying at times. I switch to
arch and found it to be quite easy to use. I was put off originally by
all the complains about it complexity.

Dimitry
-- 
((lambda (lambda) `(,lambda ',lambda)) '(lambda (lambda) `(,lambda ',lambda)))


From mb at bese.it  Tue Apr 12 07:49:03 2005
From: mb at bese.it (Marco Baringer)
Date: Tue, 12 Apr 2005 09:49:03 +0200
Subject: [Bese-devel] Starting with UCW
References: <200504091524.07862.pupeno@pupeno.com>
Message-ID: <m21x9gigeo.fsf@soma.local>

Pupeno <pupeno at pupeno.com> writes:

> Hello,
> I'm trying to get started with development of web applications with UCW, but I 
> just can't find how.

UCW is definetly not newbie friendly (_especially_ if this newbie is
also a lisp newbie). i'm doing what i can to fix that, but it'll never
be a high priority for me (though i'll offer a pint of beer (of your
choice) for every page of tutorial/howto of other newbie documentation
i get).

having said that, here's a step by step walk through to running the
wiki app: (All of this assumes that you have a directory called
~/lisp/ucw/ where we can keep all of the ucw stuff.)

I'd by really greatfull (as will any future ucw users) if people could
try this walk through and see where it breaks or i've forgotten
something.

1) we'll need to get the LATEST (0.3.7 is NOT enough) UCW (and the
   latest versions of arnesi and yaclml):

$ tla ~/lisp/ucw/
$ tla register-archive 'http://common-lisp.net/project/ucw/ucw-2004 at common-lisp.net'
$ tla register-archive 'http://common-lisp.net/project/bese/bese-2004 at common-lisp.net'
$ tla get ucw-2004 at common-lisp.net/ucw--dev ucw
$ cd ucw
$ tla buildcfg libs/config

2) We're going to use UCW's builtin server (this is why you must have
   the latest ucw) since it is (almost) completly builtin to UCW
   itself. The only things we're mising are:

2a) SLIME - You MUST use a cvs version of slime:

$ cd ~/lisp/ucw/libs/
$ cvs -z3 -d :pserver:anonymous:anonymous at common-lisp.net:/project/slime/cvsroot co slime

We must tell asdf about slime:

$ cd ~/lisp/ucw/systems/
$ ln -s ../libs/slime/swank.asd .

2b) puri - I'm slowly removing my ad-hoc 80% uri modlue and replacing
it with kmr's port of franz's uri module:

$ cd ~/lisp/ucw/libs/
$ ncftpget ftp://files.b9.com/puri/puri-latest.tar.gz
$ gzcat puri-latest.tar.gz | tar -xf -
$ cd ../systems/
$ ln -s ../libs/puri*/puri.asd .

2c) rfc2388

$ cd ~/lisp/ucw/libs/
$ ncfptget ftp://ftp.common-lisp.net/pub/project/rfc2388/rfc2388_0.9.tar.gz
$ gzcat rfc2388_0.9.tar.gz | tar -xf -
$ cd ../systems/
$ ln -s ../libs/rfc2388/rfc2388.asd .

3) We now have all the code we need to run UCW. We now need to make
   sure that ASDF sees all this code. Edit the file
   ~/lisp/ucw/bin/start.lisp and add this as the first form in the
   file:

(push "/home/me/lisp/ucw/systems/" asdf:*central-registry*)

Some lisps, openmcl for example, do not include asdf in the default
image, so you'll need to add this _before_ that form:

(require :asdf)

4) Finally (took long enough didn't it? :)) we're ready to start UCW:

$ cd ~/lisp/ucw/

$ sbcl --load bin/start.lisp
OR
$ lisp -load bin/start.lisp
OR
$ openmcl -l bin/start.lisp

5) Now you can test the setup by playing with the examples at
   http://127.0.0.1:8080/ucw/examples/index.ucw

6) Wait, wasn't the point of this to run the wiki? 

6a) download and install (as we did with puri and slime) cl-ppcre:
http://www.weitz.de/cl-ppcre/

Both x86 linux and ppc have free multithread lisps available (cmucl,
sbcl or openmcl). On windows you'll need either allegro, lispworks, or
you'll just have to deal with working on a single theraded lisp.

Anyway, let's assume you have a multitherad lisp and connect emacs to
our lisp (single thread lisps don't get, by default, a running slime
server):

[from within emacs]

M-x slime RET 127.0.0.1 RET 4005 RET

Slime will now open up a repl connected to our running ucw
installation. Open up (C-x C-f) the wiki.lisp file and load it (C-c
C-k or C-c C-l). If everything is working you can point your browser
to one of the wiki's urls and play around. NB: by loading the wiki
file you will get the "last" version of the wiki (the one with the
login demo). If you want to read the wiki tutorial and play with it as
you go you'll need to use C-x C-e on a form by form basis.

7) send an email to bese-devel at common-lisp.net with any and all
   comments/suggestions/whatever.

p.s. - i'm working on getting ucw 0.3.8 out (and making a release of
arnesi and yaclml). hopefully this will make getting started easier.

-- 
-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


From djwatson at u.washington.edu  Mon Apr 11 22:48:51 2005
From: djwatson at u.washington.edu (djwatson at u.washington.edu)
Date: Mon, 11 Apr 2005 15:48:51 -0700 (PDT)
Subject: [Bese-devel] [patch] emit-indentation cleanup
Message-ID: <Pine.LNX.4.43.0504111548510.32625@hymn07.u.washington.edu>

emit-indentation emits the indentation in weird spots, fixed to emit after tags only.

-Dave Watson
djwatson at u.washington.edu



-------------- next part --------------
A non-text attachment was scrubbed...
Name: emit-indentation.patch
Type: application/octet-stream
Size: 975 bytes
Desc: 
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20050411/e0495ec6/attachment.obj>

From djwatson at u.washington.edu  Mon Apr 11 22:47:53 2005
From: djwatson at u.washington.edu (djwatson at u.washington.edu)
Date: Mon, 11 Apr 2005 15:47:53 -0700 (PDT)
Subject: [Bese-devel] [patch] range-view.tal indexing error
Message-ID: <Pine.LNX.4.43.0504111547530.32625@hymn07.u.washington.edu>

attached is a small patch to fix the range-view.tal indexing error

-Dave Watson
djwatson at u.washington.edu



-------------- next part --------------
A non-text attachment was scrubbed...
Name: range-view.tal.patch
Type: application/octet-stream
Size: 568 bytes
Desc: 
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20050411/95de65ca/attachment.obj>

From mb at bese.it  Tue Apr 12 08:01:24 2005
From: mb at bese.it (Marco Baringer)
Date: Tue, 12 Apr 2005 10:01:24 +0200
Subject: [Bese-devel] [patch] emit-indentation cleanup
In-Reply-To: <Pine.LNX.4.43.0504111548510.32625@hymn07.u.washington.edu>
	(djwatson@u.washington.edu's
	message of "Mon, 11 Apr 2005 15:48:51 -0700 (PDT)")
References: <Pine.LNX.4.43.0504111548510.32625@hymn07.u.washington.edu>
Message-ID: <m2mzs4h19n.fsf@soma.local>

djwatson at u.washington.edu writes:

> emit-indentation emits the indentation in weird spots, fixed to emit after tags only.

unfortunetly doing that changes the way the html is output. some
browsers (ie on mac in particular) are whitespace sensitive in odd,
suprising and rather abritrary ways. 

the _only_ way to indent html without changing the way its rendered
(and with giving indentor a doop understanding of html itself) is to
put the indentation with the tags themselves (i'd _love_ to be proven
wrong on this).

-- 
-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


From mb at bese.it  Tue Apr 12 08:01:47 2005
From: mb at bese.it (Marco Baringer)
Date: Tue, 12 Apr 2005 10:01:47 +0200
Subject: [Bese-devel] [patch] range-view.tal indexing error
In-Reply-To: <Pine.LNX.4.43.0504111547530.32625@hymn07.u.washington.edu>
	(djwatson@u.washington.edu's
	message of "Mon, 11 Apr 2005 15:47:53 -0700 (PDT)")
References: <Pine.LNX.4.43.0504111547530.32625@hymn07.u.washington.edu>
Message-ID: <m2is2sh190.fsf@soma.local>

djwatson at u.washington.edu writes:

> attached is a small patch to fix the range-view.tal indexing error

applied. thanks.

-- 
-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


From mb at bese.it  Tue Apr 12 08:21:52 2005
From: mb at bese.it (Marco Baringer)
Date: Tue, 12 Apr 2005 10:21:52 +0200
Subject: [Bese-devel] join
In-Reply-To: <20050408190908.3912021AFF9@ws5-6.us4.outblaze.com> (John
	Lutz's message of "Fri, 08 Apr 2005 20:09:07 +0100")
References: <20050408190908.3912021AFF9@ws5-6.us4.outblaze.com>
Message-ID: <m2y8boflr3.fsf@soma.local>

"John Lutz" <lutzj at operamail.com> writes:

> Hello all,
> Can anyone tell me how to get UnCommon Web to work
> with a browser?

try the step-by-step instructions I posted in the 'Starting with UCW'
thread. If those work then we can try and figure out whats's wrong
with ucwctl attach.

> using ucwctl start && ucwctl attach

my first guess is that you're using an attachtty without the --eval
patch (see the bugs listing for detachtty in debian for details).

> There is an initial request, it logs the session, gets a cookie
> then accepts no other request. The initial request forms
> as a hang on the browser side.

is this a multi thread lisp?

-- 
-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


From mb at bese.it  Tue Apr 12 08:24:04 2005
From: mb at bese.it (Marco Baringer)
Date: Tue, 12 Apr 2005 10:24:04 +0200
Subject: [Bese-devel] start.lisp and Slime
References: <200504101838.43203.pupeno@pupeno.com>
Message-ID: <m2hdicflnf.fsf@soma.local>

Pupeno <pupeno at pupeno.com> writes:

> Hello,
> This is just an little usability problem. I can load start.lisp with (load 
> "....../start.lisp") with no problem but I can't load it with C-c C-k 
> (slime-compile-and-load-file) command of Slime, the error I get is:
> -+  Errors (1)
>  `-- READER-ERROR at 1111 (line 30, column 33) on #<SB-SYS:FD-STREAM for "file 
> \"/home/pupeno/src/ucw-dist/ucw/bin/start.lisp\"" {9272DE9}>:
>      package "ARNESI" not found
>
> That line is:
>
> (eval-when (:compile-toplevel :load-toplevel :execute)
>   (setf arnesi::*call/cc-returns* nil))
>
> That's all, I don't really know how to fix it, it seems that setf is using 
> arnesi which hasn't been loaded yet, but well, that's kinda obvius.
> Thank you.

the problem is that start.lisp can not be complied until after it has
been loaded. slime-compile-and-load-file doesn't deal with files like
this.

start.lisp is a script, its not meant to be compiled nor is it meant
to be used interactivly from within slime. At the same time i'm pretty
sure C-c C-l will work (unless the underlying lisp (cmucl for example)
attempts to compile files before loading them).

If C-c C-l does in fact work i'll add a note in start.lisp saying to
use it, otherwise i'll add a note reminding people to not attempt ot
load the file from within slime.

-- 
-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


From djwatson at docwatson.org  Tue Apr 12 16:37:54 2005
From: djwatson at docwatson.org (Dave Watson)
Date: Tue, 12 Apr 2005 09:37:54 -0700
Subject: [Bese-devel] [patch] emit-indentation cleanup
In-Reply-To: <m2mzs4h19n.fsf@soma.local>
References: <Pine.LNX.4.43.0504111548510.32625@hymn07.u.washington.edu>
	<m2mzs4h19n.fsf@soma.local>
Message-ID: <20050412163753.GA27165@dearf.cs.washington.edu>

On Tue, Apr 12, 2005 at 10:01:24AM +0200, Marco Baringer wrote:
> djwatson at u.washington.edu writes:
> 
> > emit-indentation emits the indentation in weird spots, fixed to emit after tags only.
> 
> the _only_ way to indent html without changing the way its rendered
> (and with giving indentor a doop understanding of html itself) is to
> put the indentation with the tags themselves (i'd _love_ to be proven
> wrong on this).

At a minimum I think a comment about this should go in the mentioned 
file then, and perhaps even in the generated output.   Perhaps even
another global variable would be in order.   When debugging it is much
more helpful to view the source than have compatability.

-Dave Watson


From pupeno at pupeno.com  Tue Apr 12 18:53:24 2005
From: pupeno at pupeno.com (Pupeno)
Date: Tue, 12 Apr 2005 15:53:24 -0300
Subject: [Bese-devel] bin/conf.lisp
Message-ID: <200504121553.28117.pupeno@pupeno.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In the file bin/ucwctl, there's a comment that says "NB: Actually configuring 
UCW itself is done by editing bin/conf.lisp" but bin/conf.lisp doesn't seem 
to exists. It seems that configuration is on bin/start.lisp, am I wrong ?
Thank you.
- -- 
Pupeno: pupeno at pupeno.com - http://pupeno.com
Reading Science Fiction ? http://sfreaders.com.ar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCXBkofW48a9PWGkURAgDsAJ4pf498lQ02JXY9MQRbx9Tzo/c5ugCdF+AQ
zQQ0idRb8XwPD7dvUe9BzSs=
=hcFN
-----END PGP SIGNATURE-----


From mb at bese.it  Wed Apr 13 07:16:12 2005
From: mb at bese.it (Marco Baringer)
Date: Wed, 13 Apr 2005 09:16:12 +0200
Subject: [Bese-devel] bin/conf.lisp
In-Reply-To: <200504121553.28117.pupeno@pupeno.com> (pupeno@pupeno.com's
	message of "Tue, 12 Apr 2005 15:53:24 -0300")
References: <200504121553.28117.pupeno@pupeno.com>
Message-ID: <m2sm1v170j.fsf@soma.local>

Pupeno <pupeno at pupeno.com> writes:

> In the file bin/ucwctl, there's a comment that says "NB: Actually configuring 
> UCW itself is done by editing bin/conf.lisp" but bin/conf.lisp doesn't seem 
> to exists. It seems that configuration is on bin/start.lisp, am I wrong ?

no, you're right. i'll fix the comment in bin/ucwctl.

> Thank you.
> -- 
> Pupeno: pupeno at pupeno.com - http://pupeno.com
> Reading Science Fiction ? http://sfreaders.com.ar
> _______________________________________________
> bese-devel mailing list
> bese-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel


From mb at bese.it  Wed Apr 13 07:18:03 2005
From: mb at bese.it (Marco Baringer)
Date: Wed, 13 Apr 2005 09:18:03 +0200
Subject: [Bese-devel] [patch] emit-indentation cleanup
In-Reply-To: <20050412163753.GA27165@dearf.cs.washington.edu> (Dave Watson's
	message of "Tue, 12 Apr 2005 09:37:54 -0700")
References: <Pine.LNX.4.43.0504111548510.32625@hymn07.u.washington.edu>
	<m2mzs4h19n.fsf@soma.local>
	<20050412163753.GA27165@dearf.cs.washington.edu>
Message-ID: <m2oecj16xg.fsf@soma.local>

Dave Watson <djwatson at docwatson.org> writes:

> On Tue, Apr 12, 2005 at 10:01:24AM +0200, Marco Baringer wrote:
>> djwatson at u.washington.edu writes:
>> 
>> > emit-indentation emits the indentation in weird spots, fixed to emit after tags only.
>> 
>> the _only_ way to indent html without changing the way its rendered
>> (and with giving indentor a doop understanding of html itself) is to
>> put the indentation with the tags themselves (i'd _love_ to be proven
>> wrong on this).
>
> At a minimum I think a comment about this should go in the mentioned 
> file then, and perhaps even in the generated output.   Perhaps even
> another global variable would be in order.   When debugging it is much
> more helpful to view the source than have compatability.

ok, i'll add a comment to this effect in yaclml.lisp (tat's the file
you're talking about right?) but what would i suggest i put in the generated output?

-- 
-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


From mb at bese.it  Wed Apr 13 07:59:13 2005
From: mb at bese.it (Marco Baringer)
Date: Wed, 13 Apr 2005 09:59:13 +0200
Subject: [Bese-devel] regarding 0.3.7
Message-ID: <m21x9fyuni.fsf@soma.local>


i'd like to let everyone know that ucw 0.3.7 corresponds to patch-266
on the ucw--dev--0.3 branch. the latest patch on that branch, as of
today, is patch-373! i _strongly_ suggest using arch and working with
the latest version of ucw. it may not be user-friendly (not thta 0.3.7
was), but i've got ucw--dev--0.3--patch-354 running on one production
server and ucw--dev--0.3--patch-373 is the current target for a
desktop app, you're not missing out on stability by using the latest
ucw code.

-- 
-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


From mb at bese.it  Wed Apr 13 08:39:16 2005
From: mb at bese.it (Marco Baringer)
Date: Wed, 13 Apr 2005 10:39:16 +0200
Subject: [Bese-devel] 0.3.8pre0
In-Reply-To: <m21x9fyuni.fsf@soma.local> (Marco Baringer's message of "Wed,
	13 Apr 2005 09:59:13 +0200")
References: <m21x9fyuni.fsf@soma.local>
Message-ID: <m2pswzxe8b.fsf@soma.local>


I just put up 0.3.8pre0 (it corresponds to ucw--dev--0.3--patch-376):

ftp://ftp.common-lisp.net/pub/project/ucw/ucw_0.3.8pre9.tar.bz2

This will become, after any distribution mistakes have been corrected
and i've created the RELEASE_NOTES file, ucw 0.3.8. i'd be great if
people could download and install that and tell me how it goes.

-- 
-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


From jagarenbraperson at yahoo.se  Wed Apr 13 12:31:15 2005
From: jagarenbraperson at yahoo.se (Henrik Hjelte)
Date: Wed, 13 Apr 2005 14:31:15 +0200 (CEST)
Subject: [Bese-devel] Small patches to get started using allegro
Message-ID: <20050413123115.85531.qmail@web25610.mail.ukl.yahoo.com>

Hi. I found some minor obstacles on my way to get
started with the current arch version of ucw on
allegro 7. It is now working so I'd like to share the
changes I made. 
First there seemed to be a problem compiling
mopp.lisp, similar problems to what frido had with
lispworks. Not digging deep into the problem, I found
that fridos "hackish" patch from the 24:th of march
worked fine with allegro as well, just change
#+LispWorks and #-Lispworks in fridos patch to #+(or
LispWorks allegro) and #-(or LispWorks allegro).
Second, there was a problem when running the demo,
allegro complained about "trying to displace an array
of type character to an array of type T". I had to add
the :element-type argument to make-array in
httpd.lisp, as below. I have also included it as a
patch.

Now I'm looking forward to trying it out..
/Henrik Hjelte

--- orig/src/backend/httpd.lisp
+++ mod/src/backend/httpd.lisp
@@ -344,6 +344,7 @@
     ;; get the parametetrs from the uri
     (awhen (position #\? (raw-uri request))
       (let ((query-param-string (make-array (-
(length (raw-uri request)) it 1)
+                                           
:element-type 'character
                                            
:displaced-to (raw-uri request)
                                            
:displaced-index-offset (1+ it))))
         (add-parameters (parse-urlencoded query-param-string))))
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CHANGESET.tar.gz
Type: application/x-gzip
Size: 679 bytes
Desc: CHANGESET.tar.gz
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20050413/30f0794a/attachment.bin>

From jagarenbraperson at yahoo.se  Wed Apr 13 13:05:24 2005
From: jagarenbraperson at yahoo.se (Henrik Hjelte)
Date: Wed, 13 Apr 2005 15:05:24 +0200 (CEST)
Subject: [Bese-devel] Changes to the README
Message-ID: <20050413130524.96770.qmail@web25610.mail.ukl.yahoo.com>

Here are some small changes to the README file. A
mention to download rfc2388, and the tla changes
output option is -o  not -D.
The changeset includes my previous patch to
httpd.lisp.
/Henrik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CHANGESET.tar.gz
Type: application/x-gzip
Size: 1556 bytes
Desc: CHANGESET.tar.gz
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20050413/bacb7e6c/attachment.bin>

From mb at bese.it  Wed Apr 13 13:35:53 2005
From: mb at bese.it (Marco Baringer)
Date: Wed, 13 Apr 2005 15:35:53 +0200
Subject: [Bese-devel] Small patches to get started using allegro
References: <20050413123115.85531.qmail@web25610.mail.ukl.yahoo.com>
Message-ID: <m2sm1uu7d2.fsf@soma.local>

Henrik Hjelte <jagarenbraperson at yahoo.se> writes:

> Hi. I found some minor obstacles on my way to get
> started with the current arch version of ucw on
> allegro 7. It is now working so I'd like to share the
> changes I made. 

applied. thanks!

my only issue is with the patch to mopp.lisp. I just rechecked on
cmucl (19a for ppc), sbcl 0.8.21, Openmcl 0.14.3, clisp cvs from a few
weeks ago and allegro: _none_ of them have the problem that ugly piece
of code in mopp.lisp is trying to solve. i'm going to perfrom a few
more test and then just drop that part of mopp.lisp.

-- 
-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


From mb at bese.it  Wed Apr 13 13:36:20 2005
From: mb at bese.it (Marco Baringer)
Date: Wed, 13 Apr 2005 15:36:20 +0200
Subject: [Bese-devel] Changes to the README
In-Reply-To: <20050413130524.96770.qmail@web25610.mail.ukl.yahoo.com> (Henrik
	Hjelte's message of "Wed, 13 Apr 2005 15:05:24 +0200 (CEST)")
References: <20050413130524.96770.qmail@web25610.mail.ukl.yahoo.com>
Message-ID: <m2oeciu7cb.fsf@soma.local>

Henrik Hjelte <jagarenbraperson at yahoo.se> writes:

> Here are some small changes to the README file. A
> mention to download rfc2388, and the tla changes
> output option is -o  not -D.
> The changeset includes my previous patch to
> httpd.lisp.

applied. thanks.

-- 
-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


From djwatson at docwatson.org  Wed Apr 13 18:11:28 2005
From: djwatson at docwatson.org (Dave Watson)
Date: Wed, 13 Apr 2005 11:11:28 -0700
Subject: [Bese-devel] regarding 0.3.7
In-Reply-To: <m21x9fyuni.fsf@soma.local>
References: <m21x9fyuni.fsf@soma.local>
Message-ID: <20050413181126.GB5729@dearf.cs.washington.edu>

On Wed, Apr 13, 2005 at 09:59:13AM +0200, Marco Baringer wrote:
> today, is patch-373! i _strongly_ suggest using arch and working with
> the latest version of ucw. it may not be user-friendly (not thta 0.3.7

You might have already noticed, but:

dearf:/uns/lib/sbcl$ tla get ucw-2004 at common-lisp.net/ucw--dev--0.3 ucw
corrupt archive
  name: ucw-2004 at common-lisp.net
  location: http://common-lisp.net/project/ucw/ucw-2004 at common-lisp.net
  revision: ucw--dev--0.3--patch-381

and the ftp file for 3.8pre doesn't seem to actually exist...

-- 
-Dave Watson
djwatson at docwatson.org


From mb at bese.it  Thu Apr 14 08:10:21 2005
From: mb at bese.it (Marco Baringer)
Date: Thu, 14 Apr 2005 10:10:21 +0200
Subject: [Bese-devel] regarding 0.3.7
In-Reply-To: <20050413181126.GB5729@dearf.cs.washington.edu> (Dave Watson's
	message of "Wed, 13 Apr 2005 11:11:28 -0700")
References: <m21x9fyuni.fsf@soma.local>
	<20050413181126.GB5729@dearf.cs.washington.edu>
Message-ID: <m2d5sxok2a.fsf@soma.local>

Dave Watson <djwatson at docwatson.org> writes:

> On Wed, Apr 13, 2005 at 09:59:13AM +0200, Marco Baringer wrote:
>> today, is patch-373! i _strongly_ suggest using arch and working with
>> the latest version of ucw. it may not be user-friendly (not thta 0.3.7
>
> You might have already noticed, but:
>
> dearf:/uns/lib/sbcl$ tla get ucw-2004 at common-lisp.net/ucw--dev--0.3 ucw
> corrupt archive
>   name: ucw-2004 at common-lisp.net
>   location: http://common-lisp.net/project/ucw/ucw-2004 at common-lisp.net
>   revision: ucw--dev--0.3--patch-381

weird, i just tried (using a clean user in a clean home directory) and
was able successfully get patch-385 (starting fromthe archived
patch-361).

> and the ftp file for 3.8pre doesn't seem to actually exist...

please check
ftp://ftp.common-lisp.net/pub/project/ucw/ucw_0.3.8pre0.tar.gz again
(maybe i've gotten the perms wrong but the file does certainly exist).

-- 
-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


From mb at bese.it  Thu Apr 28 13:41:42 2005
From: mb at bese.it (Marco Baringer)
Date: Thu, 28 Apr 2005 15:41:42 +0200
Subject: [Bese-devel] make-standard-enviroment
Message-ID: <m2ekcv2f3d.fsf@soma.local>


I _just_ realized that yaclml has had a method called
make-standard-enviroment (note the mising "n") for a really long
time. i changed the name in yaclml, you'll need to fix any code
(mainly template-component-environment methods) which uses it.

-- 
-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


From bdowning at lavos.net  Fri Apr 29 00:33:35 2005
From: bdowning at lavos.net (Brian Downing)
Date: Thu, 28 Apr 2005 19:33:35 -0500
Subject: [Bese-devel] UCW: random annoyances
Message-ID: <20050428193335.I659@lavos.net>

Hi.  I've recently been learning UCW by putting together a simple game
(occasionally up at http://www.lavos.net:2501/triple-triad/index.ucw),
and have been incredibly impressed.  However, I've noticed some things
that I'm not quite sure about.  I'm using a recent checkout of ucw-dev.

First, I initially tried to have an entry point other than "index.ucw",
however all links seemed to be made to go to that unconditionally, so I
couldn't click on anything.  Easily fixed, but I don't really want to
have an index.ucw entry point if possible.

The :COMPONENT and :BACKTRACK initargs to component classes don't seem
to be changeable upon reevaluation on my platform (SBCL 0.9.0).  This is
quite annoying while in development, as I have to unintern the class
name and recompile the entire file, or, in the case of :BACKTRACK, quit
and restart UCW entirely for some reason.  Is there a hard technical
reason why this is the case, or is this a bug?

Finally, this component definition:

(defcomponent triple-triad-window (simple-window-component)
  ((body :component setup :accessor body :backtrack t))
  (:default-initargs 
   :title "Triple Triad"
   :stylesheet "stylesheet.css"))

fails with a "Slot BODY is unbound" error.  I assume this is because
it's trying to backtrack it before it is populated with the component.
Adding an :INITFORM NIL in there fixes it, but that seems quite
non-intuitive next to the :COMPONENT initarg.  Would it make sense for
the backtracking machinery to check whether the slot is bound before
trying to save it?

Other than that, the backtracking machinery is beautiful - just throwing
:BACKTRACK #'COPY-LIST on my deck slots made the interface completely
compatible with the back button and browser cloning without me losing my
mind keeping the state on the browser.

Given enough time I may try to fix some of these on my own, but for
right now the code base is pretty confusing to me, and I figured I'd at
least make them known.

Finally, I just want to put this here, since this is just a ridiculously
simple expression of something that would be hellish with traditional
web programming:

(<ucw:a :action (rotatef (deck (p1-picker app)) (deck (p2-picker app)))
        "[<- swap ->]")

Thanks for UCW!

-bcd
-- 
*** Brian Downing <bdowning at lavos dot net> 


From pupeno at pupeno.com  Fri Apr 29 04:47:55 2005
From: pupeno at pupeno.com (Pupeno)
Date: Fri, 29 Apr 2005 01:47:55 -0300
Subject: [Bese-devel] Error starting
Message-ID: <200504290147.58468.pupeno@pupeno.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

While starting UCW by loading start.lisp, with everything as it is on the gnu 
arch version (the lattest one), I get this errror:

The function IT.BESE.UCW-USER::GET-LOGGER is undefined.
   [Condition of type UNDEFINED-FUNCTION]
Restarts:
  0: [ABORT] Abort handling SLIME request.
  1: [DESTROY-THREAD] Destroy this thread (4266)
(backtrace below).

I've searched for the procedure get-logger and indeed, it's not defined 
anywhere. What am I missing here ?

Thank you.
- -- 
Pupeno: pupeno at pupeno.com - http://pupeno.com
Reading Science Fiction ? http://sfreaders.com.ar

PS: Backtrace:
  0: ("bogus stack frame")
  1: (SYMBOL-FUNCTION IT.BESE.UCW-USER::SETUP-LOGGERS)
  2: (SB-INT:EVAL-IN-LEXENV (IT.BESE.UCW-USER::SETUP-LOGGERS 
(MAKE-PATHNAME :NAME NIL :TYPE NIL :DIRECTORY (APPEND # #) :DEFAULTS 
*LOAD-TRUENAME*)) #S(SB-KERNEL:LEXENV :FUNS NIL :VARS NIL :BLOCKS NIL :TAGS 
NIL :TYPE-RESTRICTIONS NIL :LAMBDA NIL :CLEANUP NIL :HANDLED-CONDITIONS 
NIL :DISABLED-PACKAGE-LOCKS NIL :POLICY ((SPEED . 1) (SPACE . 1) (SAFETY . 1) 
(INHIBIT-WARNINGS . 1) (DEBUG . 1) (COMPILATION-SPEED . 1))))
  3: (SB-FASL::LOAD-AS-SOURCE #<SB-SYS:FD-STREAM for "file 
\"/home/pupeno/src/ucw/bin/start.lisp\"" {A2663A1}> NIL NIL)
  4: (SB-FASL::INTERNAL-LOAD #P"/home/pupeno/src/ucw/bin/start.lisp" 
#P"/home/pupeno/src/ucw/bin/start.lisp" :ERROR NIL NIL :SOURCE :DEFAULT)
  5: (SB-FASL::INTERNAL-LOAD #P"/home/pupeno/src/ucw/bin/start.lisp" 
#P"/home/pupeno/src/ucw/bin/start.lisp" :ERROR NIL NIL NIL :DEFAULT)
  6: (LOAD "/home/pupeno/src/ucw/bin/start.lisp")
  7: (SB-INT:EVAL-IN-LEXENV (LOAD "/home/pupeno/src/ucw/bin/start.lisp") 
#S(SB-KERNEL:LEXENV :FUNS NIL :VARS NIL :BLOCKS NIL :TAGS 
NIL :TYPE-RESTRICTIONS NIL :LAMBDA NIL :CLEANUP NIL :HANDLED-CONDITIONS 
NIL :DISABLED-PACKAGE-LOCKS NIL :POLICY ((SPEED . 1) (SPACE . 1) (SAFETY . 1) 
(INHIBIT-WARNINGS . 1) (DEBUG . 1) (COMPILATION-SPEED . 1))))
  8: (SWANK::EVAL-REGION "(load \"/home/pupeno/src/ucw/bin/start.lisp\")
" T)
  9: ((LAMBDA NIL))
 10: ((SB-PCL::FAST-METHOD SWANK-BACKEND:CALL-WITH-SYNTAX-HOOKS (T)) #<unused 
argument> #<unused argument> #<CLOSURE (LAMBDA NIL) {A25CF75}>)
 11: (SWANK::CALL-WITH-BUFFER-SYNTAX #<CLOSURE (LAMBDA NIL) {A25CF75}>)
 12: (SB-INT:EVAL-IN-LEXENV (SWANK:LISTENER-EVAL "(load 
\"/home/pupeno/src/ucw/bin/start.lisp\")
") #S(SB-KERNEL:LEXENV :FUNS NIL :VARS NIL :BLOCKS NIL :TAGS 
NIL :TYPE-RESTRICTIONS NIL :LAMBDA NIL :CLEANUP NIL :HANDLED-CONDITIONS 
NIL :DISABLED-PACKAGE-LOCKS NIL :POLICY ((SPEED . 1) (SPACE . 1) (SAFETY . 1) 
(INHIBIT-WARNINGS . 1) (DEBUG . 1) (COMPILATION-SPEED . 1))))
 13: ((LAMBDA NIL))
 14: ((SB-PCL::FAST-METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T T)) 
#<unused argument> #<unused argument> #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> 
#<CLOSURE (LAMBDA NIL) {A25CDE5}>)
 15: ((LAMBDA NIL))
 16: ((LAMBDA NIL))
 17: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {9090DC1}> #<CLOSURE 
(LAMBDA NIL) {A25CCAD}>)
 18: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {9090DC1}> #<FUNCTION 
(LAMBDA NIL) {9E5915D}>)
 19: (SWANK::HANDLE-REQUEST #<SWANK::CONNECTION {9090DC1}>)
 20: ((LAMBDA NIL))
 21: ((LAMBDA NIL))
 22: ((LAMBDA NIL))
 23: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {9090DC1}> #<CLOSURE 
(LAMBDA NIL) {919C085}>)
 24: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {9090DC1}> #<CLOSURE 
(LAMBDA NIL) {919C075}>)
 25: (SWANK::CALL-WITH-BINDINGS NIL #<CLOSURE (LAMBDA NIL) {919C055}>)
 26: ((LAMBDA NIL))
 27: ("foreign function: call_into_lisp")
 28: ("foreign function: funcall0")
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCcbx+fW48a9PWGkURAmbfAJ9jBVQ6Rvd0DlnGDqFB/YT0iPgFFQCfQuPt
bc5AYsLNRw8eOnkXFMr75/4=
=7J7u
-----END PGP SIGNATURE-----


From mb at bese.it  Fri Apr 29 08:19:28 2005
From: mb at bese.it (Marco Baringer)
Date: Fri, 29 Apr 2005 10:19:28 +0200
Subject: [Bese-devel] UCW: random annoyances
In-Reply-To: <20050428193335.I659@lavos.net> (Brian Downing's message of
	"Thu, 28 Apr 2005 19:33:35 -0500")
References: <20050428193335.I659@lavos.net>
Message-ID: <m2u0lqc7vz.fsf@soma.local>

Brian Downing <bdowning at lavos.net> writes:

> Hi.  I've recently been learning UCW by putting together a simple game
> (occasionally up at http://www.lavos.net:2501/triple-triad/index.ucw),
> and have been incredibly impressed.  However, I've noticed some things
> that I'm not quite sure about.  I'm using a recent checkout of ucw-dev.
>
> First, I initially tried to have an entry point other than "index.ucw",
> however all links seemed to be made to go to that unconditionally, so I
> couldn't click on anything.  Easily fixed, but I don't really want to
> have an index.ucw entry point if possible.

here's what _should_ happen:

link and form urls are calculated by the method compute-url (which
walks tho component tree (following parent links) and calling
update-url). The defalut implementation of compute-url simply calls
compute-url on the application object (the idea is that yau can
provide an application wide default url and customize it for
particular components). The implementation of compute-url for
standard-application objects simply usesr the query-path of the
current request object. [all of this so that hopefully the code is a
bit less confusing].

anyway, the point of this is that if your app has a single entry-paint
named foo.bar, and you never define your own compute-url or update-url
methods, all links _should_ be of the form foo.bar?s=...&f=...&a=...

This (new) compute-url logic was implemented in patch
ucw--dev--0.3--patch-368 (bug fixs to the change in patch-369 and
patch-370). The old logic had index.ucw hard coded.

so there are two possible issues: 1) your using an old version of ucw
2) the new ucw code is bugged. the former can be checked with a simple
tla logs and the later can be checked by seeing how compute-url is
implemented in ucw/src/rerl/standard-component/standard-component.lisp.

> The :COMPONENT and :BACKTRACK initargs to component classes don't seem
> to be changeable upon reevaluation on my platform (SBCL 0.9.0).  This is
> quite annoying while in development, as I have to unintern the class
> name and recompile the entire file, or, in the case of :BACKTRACK, quit
> and restart UCW entirely for some reason.  Is there a hard technical
> reason why this is the case, or is this a bug?

this i a bug (i've created an issue for it in the docs/issues/
directory). Basically I need to define a correct reinitialize-instance
method for standard-component-class objects.

> Finally, this component definition:
>
> (defcomponent triple-triad-window (simple-window-component)
>   ((body :component setup :accessor body :backtrack t))
>   (:default-initargs 
>    :title "Triple Triad"
>    :stylesheet "stylesheet.css"))
>
> fails with a "Slot BODY is unbound" error.  I assume this is because
> it's trying to backtrack it before it is populated with the component.
> Adding an :INITFORM NIL in there fixes it, but that seems quite
> non-intuitive next to the :COMPONENT initarg.  Would it make sense for
> the backtracking machinery to check whether the slot is bound before
> trying to save it?

i'm going to add a check which prohibits both :backtrack and
:component on the same slot. That said it would alsa make sense to
have the backtrack machinery check for slot-boundness.

> Given enough time I may try to fix some of these on my own, but for
> right now the code base is pretty confusing to me, and I figured I'd at
> least make them known.
>
> Finally, I just want to put this here, since this is just a ridiculously
> simple expression of something that would be hellish with traditional
> web programming:
>
> (<ucw:a :action (rotatef (deck (p1-picker app)) (deck (p2-picker app)))
>         "[<- swap ->]")
>
> Thanks for UCW!

my pleasure.

-- 
-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