From jan at rychter.com  Thu Mar  3 10:19:52 2005
From: jan at rychter.com (Jan Rychter)
Date: Thu, 03 Mar 2005 11:19:52 +0100
Subject: [Bese-devel] ucw available through darcs
In-Reply-To: <m2ekfuxag5.fsf@soma.local> (Marco Baringer's message of "Sun, 06
	Feb 2005 11:13:46 +0100")
References: <m2ekfuxag5.fsf@soma.local>
Message-ID: <m2650958vr.fsf@tnuctip.rychter.com>

>>>>> "Marco" == Marco Baringer <mb at bese.it> writes:
 Marco> in the hopes of making ucw as easy as possible to work with (and
 Marco> to send me your changes), i've created a darcs repo for ucw:

 Marco> http://common-lisp.net/project/ucw/_darcs/ucw
[...]
 Marco> not withstanding this excursion into darcs land i want every to
 Marco> know that the official source for ucw is the arch repository. i
 Marco> will keep the darcs repo synchronized (though it may lag a bit)
 Marco> and i'll accept darcs patches, but we're not switching over to
 Marco> darcs.

 Marco> p.s. - this is my first attempt at setting up darcs, comments
 Marco> welcome.

It doesn't seem to be updated -- which is a real pity. Any chance this
could be fixed?

Some of us find tla/arch a major pain to use. Darcs is delightfully
simple and I believe the subset of arch functionality that UCW needs
fits easily within what darcs has to offer.

I'd much rather keep track of arnesi, yaclml and ucw using darcs than
arch.

--J.


From mb at bese.it  Thu Mar  3 12:08:26 2005
From: mb at bese.it (Marco Baringer)
Date: Thu, 03 Mar 2005 13:08:26 +0100
Subject: [Bese-devel] ucw available through darcs
In-Reply-To: <m2650958vr.fsf@tnuctip.rychter.com> (Jan Rychter's message of
	"Thu, 03 Mar 2005 11:19:52 +0100")
References: <m2ekfuxag5.fsf@soma.local> <m2650958vr.fsf@tnuctip.rychter.com>
Message-ID: <m27jkpc4p1.fsf@soma.local>

Jan Rychter <jan at rychter.com> writes:

> It doesn't seem to be updated -- which is a real pity. Any chance this
> could be fixed?

i'd messed up the cronjob, sorry. it should be fixed now (it's updated
(along with the arch mirrors) every three hours), send me a big angry
scary email if it isn't.

-- 
-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 Mar  3 12:24:51 2005
From: mb at bese.it (Marco Baringer)
Date: Thu, 03 Mar 2005 13:24:51 +0100
Subject: [Bese-devel] the darcs popularity contest
Message-ID: <m23bvcdii4.fsf@soma.local>


i'm curious, how many of you use (or would use if it worked) ucw's
darcs repo? 

-- 
-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 rm at seid-online.de  Thu Mar  3 12:55:07 2005
From: rm at seid-online.de (rm at seid-online.de)
Date: Thu, 3 Mar 2005 13:55:07 +0100
Subject: [Bese-devel] the darcs popularity contest
In-Reply-To: <m23bvcdii4.fsf@soma.local>
References: <m23bvcdii4.fsf@soma.local>
Message-ID: <20050303125507.GC8403@seid-online.de>

On Thu, Mar 03, 2005 at 01:24:51PM +0100, Marco Baringer wrote:
> 
> i'm curious, how many of you use (or would use if it worked) ucw's
> darcs repo? 


Me, 1+

 cheers RalfD

> 
> -- 
> -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
> _______________________________________________
> bese-devel mailing list
> bese-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel


From drewc at tech.coop  Thu Mar  3 21:31:47 2005
From: drewc at tech.coop (Drew Crampsie)
Date: Thu, 03 Mar 2005 13:31:47 -0800
Subject: [Bese-devel] the darcs popularity contest
In-Reply-To: <20050303125507.GC8403@seid-online.de>
References: <m23bvcdii4.fsf@soma.local> <20050303125507.GC8403@seid-online.de>
Message-ID: <42278243.2040000@tech.coop>

rm at seid-online.de wrote:
> On Thu, Mar 03, 2005 at 01:24:51PM +0100, Marco Baringer wrote:
> 
>>i'm curious, how many of you use (or would use if it worked) ucw's
>>darcs repo? 
> 
> 
> 
> Me, 1+

ME TOO!

drewc


From digash at gmail.com  Fri Mar  4 00:46:27 2005
From: digash at gmail.com (Dimitry Gashinsky)
Date: Thu, 3 Mar 2005 19:46:27 -0500
Subject: [Bese-devel] the darcs popularity contest
Message-ID: <e2c76ba505030316461276c88b@mail.gmail.com>

I like it too.


From mb at bese.it  Fri Mar  4 16:21:26 2005
From: mb at bese.it (Marco Baringer)
Date: Fri, 04 Mar 2005 17:21:26 +0100
Subject: [Bese-devel] arch popularity contest
Message-ID: <m26507e60p.fsf@soma.local>


i got 7 response to my "darcs popularity contest" email (which is
quite a lot of responses on a mailing list with only 42 people
subscribed). so, let me ask the opposite question:

how many of you use ucw's arch repo?

-- 
-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 ats at acm.org  Fri Mar  4 16:24:19 2005
From: ats at acm.org (Alan Shutko)
Date: Fri, 04 Mar 2005 10:24:19 -0600
Subject: [Bese-devel] arch popularity contest
In-Reply-To: <m26507e60p.fsf@soma.local> (Marco Baringer's message of "Fri, 04
	Mar 2005 17:21:26 +0100")
References: <m26507e60p.fsf@soma.local>
Message-ID: <871xave5vw.fsf@vera.springies.com>

"Marco Baringer" <mb at bese.it> writes:

> how many of you use ucw's arch repo?

I do.  Emacs's support for syncing things between your archive and
mine is very handy!

-- 
Alan Shutko <ats at acm.org> - I am the rocks.



From mb at bese.it  Fri Mar  4 16:36:01 2005
From: mb at bese.it (Marco Baringer)
Date: Fri, 04 Mar 2005 17:36:01 +0100
Subject: [Bese-devel] arch popularity contest
In-Reply-To: <871xave5vw.fsf@vera.springies.com> (Alan Shutko's message of
	"Fri, 04 Mar 2005 10:24:19 -0600")
References: <m26507e60p.fsf@soma.local> <871xave5vw.fsf@vera.springies.com>
Message-ID: <m2zmxjcqry.fsf@soma.local>

Alan Shutko <ats at acm.org> writes:

> "Marco Baringer" <mb at bese.it> writes:
>
>> how many of you use ucw's arch repo?
>
> I do.  Emacs's support for syncing things between your archive and
> mine is very handy!

definetely. one of darcs' biggest problems atm is xtla :)

-- 
-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 jan at rychter.com  Fri Mar  4 17:24:57 2005
From: jan at rychter.com (Jan Rychter)
Date: Fri, 04 Mar 2005 18:24:57 +0100
Subject: [Bese-devel] the darcs popularity contest
In-Reply-To: <m23bvcdii4.fsf@soma.local> (Marco Baringer's message of "Thu, 03
	Mar 2005 13:24:51 +0100")
References: <m23bvcdii4.fsf@soma.local>
Message-ID: <m2wtsnqq6u.fsf@rychter.com>

>>>>> "Marco" == Marco Baringer <mb at bese.it> writes:
 Marco> i'm curious, how many of you use (or would use if it worked)
 Marco> ucw's darcs repo?

I guess my vote went in already, as I was the one complaining about it
being out of sync. But just to make it clear:

Yes, I would definitely prefer that.

The main reason here being that I think tla/arch is overly complicated
and has a badly designed UI. I won't repeat my other reasons -- the
'Finding Lisp' blog described these issues in detail recently and I
mostly agree with it.

--J.


From asf at boinkor.net  Fri Mar  4 21:28:40 2005
From: asf at boinkor.net (Andreas Fuchs)
Date: Fri, 04 Mar 2005 22:28:40 +0100
Subject: [Bese-devel] arch popularity contest
In-Reply-To: <m26507e60p.fsf@soma.local>
References: <m26507e60p.fsf@soma.local>
Message-ID: <87y8d3rth3.wl%asf@boinkor.net>

Today, Marco Baringer <mb at bese.it> wrote:
> how many of you use ucw's arch repo?

I use the tarball releases as a starting point, then track development
using the bin/update.sh script, which works pretty well.

-- 
Andreas Fuchs, <asf at boinkor.net>, asf at jabber.at, antifuchs


From slawek.zak at gmail.com  Fri Mar  4 21:29:14 2005
From: slawek.zak at gmail.com (=?UTF-8?Q?S=C5=82awek_=C5=BBak?=)
Date: Fri, 4 Mar 2005 22:29:14 +0100
Subject: [Bese-devel] Patch for control-flow.lisp
Message-ID: <787bbe1c0503041329e7fc479@mail.gmail.com>

Fixes referral to undefined self variable in the inspector and a typo.
Tested with HEAD (however it is called in arch:)

--- orig/src/rerl/standard-component/control-flow.lisp
+++ mod/src/rerl/standard-component/control-flow.lisp
@@ -63,8 +63,8 @@
 methods, to avoid the creation of spurious actions this action
 can be used whenever we want to cause a compoent ot answer.
 
-VALUE should default to COMPOENT.")
-  (:method ((c component) &optional (value c))
+VALUE should default to COMPONENT.")
+  (:method ((self component) &optional (value self))
     (answer value)))
 
 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;


From etyurin at comcast.net  Sat Mar  5 02:47:45 2005
From: etyurin at comcast.net (Eugene Tyurin)
Date: Fri, 4 Mar 2005 21:47:45 -0500
Subject: [Bese-devel] arch popularity contest
In-Reply-To: <m26507e60p.fsf@soma.local>
References: <m26507e60p.fsf@soma.local>
Message-ID: <9b93f2bc4897d67ea4e6775ddce2b743@comcast.net>


I use arch: bin/update.sh all the way, baby! ;-)

--ET.



From ajuckel at gmail.com  Sat Mar  5 04:03:41 2005
From: ajuckel at gmail.com (Anthony Juckel)
Date: Fri, 4 Mar 2005 22:03:41 -0600
Subject: [Bese-devel] arch popularity contest
In-Reply-To: <9b93f2bc4897d67ea4e6775ddce2b743@comcast.net>
References: <m26507e60p.fsf@soma.local>
	<9b93f2bc4897d67ea4e6775ddce2b743@comcast.net>
Message-ID: <a45b92ac050304200310917a4c@mail.gmail.com>

I've been using arch to track development, and consequently started
using it for my own projects as well.

Anthony W. Juckel


From rm at fabula.de  Sun Mar  6 21:31:04 2005
From: rm at fabula.de (rm at fabula.de)
Date: Sun, 6 Mar 2005 22:31:04 +0100
Subject: [Bese-devel] arch popularity contest
In-Reply-To: <m26507e60p.fsf@soma.local>
References: <m26507e60p.fsf@soma.local>
Message-ID: <20050306213104.GB32195@seid-online.de>

On Fri, Mar 04, 2005 at 05:21:26PM +0100, Marco Baringer wrote:
> 
> i got 7 response to my "darcs popularity contest" email (which is
> quite a lot of responses on a mailing list with only 42 people
> subscribed). so, let me ask the opposite question:
> 
> how many of you use ucw's arch repo?

Me too, but only because the darcs archive seems to lag behind :-)

 cheers RalfD

> -- 
> -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
> _______________________________________________
> bese-devel mailing list
> bese-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel


From jan at rychter.com  Wed Mar  9 13:10:17 2005
From: jan at rychter.com (Jan Rychter)
Date: Wed, 09 Mar 2005 14:10:17 +0100
Subject: [Bese-devel] ucw available through darcs
In-Reply-To: <m27jkpc4p1.fsf@soma.local> (Marco Baringer's message of "Thu, 03
	Mar 2005 13:08:26 +0100")
References: <m2ekfuxag5.fsf@soma.local> <m2650958vr.fsf@tnuctip.rychter.com>
	<m27jkpc4p1.fsf@soma.local>
Message-ID: <m23bv59d8m.fsf@tnuctip.rychter.com>

>>>>> "Marco" == Marco Baringer <mb at bese.it> writes:
 Marco> Jan Rychter <jan at rychter.com> writes:
 >> It doesn't seem to be updated -- which is a real pity. Any chance
 >> this could be fixed?

 Marco> i'd messed up the cronjob, sorry. it should be fixed now (it's
 Marco> updated (along with the arch mirrors) every three hours), send
 Marco> me a big angry scary email if it isn't.

[THIS IS A BIG ANGRY SCARY EMAIL]

It seems to be stuck at patch-275.

--J.


From mb at bese.it  Wed Mar  9 13:42:05 2005
From: mb at bese.it (Marco Baringer)
Date: Wed, 09 Mar 2005 14:42:05 +0100
Subject: [Bese-devel] ucw available through darcs
In-Reply-To: <m23bv59d8m.fsf@tnuctip.rychter.com> (Jan Rychter's message of
	"Wed, 09 Mar 2005 14:10:17 +0100")
References: <m2ekfuxag5.fsf@soma.local> <m2650958vr.fsf@tnuctip.rychter.com>
	<m27jkpc4p1.fsf@soma.local> <m23bv59d8m.fsf@tnuctip.rychter.com>
Message-ID: <m28y4xndg2.fsf@soma.local>

Jan Rychter <jan at rychter.com> writes:

>>>>>> "Marco" == Marco Baringer <mb at bese.it> writes:
>  Marco> i'd messed up the cronjob, sorry. it should be fixed now (it's
>  Marco> updated (along with the arch mirrors) every three hours), send
>  Marco> me a big angry scary email if it isn't.
>
> [THIS IS A BIG ANGRY SCARY EMAIL]
>
> It seems to be stuck at patch-275.
>
> --J.

am i doing something wrong here?

soma:~ mb$ cd /tmp/
soma:/tmp mb$ darcs get 'http://common-lisp.net/project/ucw/_darcs/ucw'
Copying patch 766 of 766... done!
Applying patches to the "working" directory...
[...]
Finished getting.
soma:/tmp mb$ cd ucw/
soma:/tmp/ucw mb$ darcs changes --reverse --last 5 
Sun Mar  6 18:04:00 CET 2005  Marco Baringer <mb at bese.it>
  * Export *debug-on-error* and *inspect-components*

Sun Mar  6 18:04:23 CET 2005  Marco Baringer <mb at bese.it>
  * Change log level for "action called" log messages

Sun Mar  6 21:07:54 CET 2005  Marco Baringer <mb at bese.it>
  * Added snote in TODO

Sun Mar  6 21:08:45 CET 2005  Marco Baringer <mb at bese.it>
  * Use mim-part structures when parsing form data on the mod_lisp backend

Sun Mar  6 21:15:18 CET 2005  Marco Baringer <mb at bese.it>
  * update version number for arnesi in update.sh
soma:/tmp/ucw mb$ 

'update version number for arnesi in update.sh' is (according to tla
logs) ucw--dev--0.3--patch-296, which is the latest available patch.

-- 
-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 der_julian at web.de  Wed Mar  9 19:00:33 2005
From: der_julian at web.de (Julian Stecklina)
Date: Wed, 9 Mar 2005 20:00:33 +0100
Subject: [Bese-devel] UCW Tutorial
Message-ID: <20050309200033.2ce840b2@localhost>

Hello,

is there some kind of tutorial for UCW? I am trying to get started with
it, but it is very hard without some initial explanations. I am aware of
the documentation and the examples, but there is no aha-effect yet. ;)

Regards,
-- 
Julian Stecklina

-- Common Lisp can do what C, C++, Java, PASCAL, PHP, Perl, (you --
-- name it) can do. Here's how:                                  --
--                                                               --
-- http://www.amazon.com/exec/obidos/ASIN/1590592395             --


From mb at bese.it  Thu Mar 10 10:08:45 2005
From: mb at bese.it (Marco Baringer)
Date: Thu, 10 Mar 2005 11:08:45 +0100
Subject: [Bese-devel] UCW Tutorial
In-Reply-To: <20050309200033.2ce840b2@localhost> (Julian Stecklina's message
	of "Wed, 9 Mar 2005 20:00:33 +0100")
References: <20050309200033.2ce840b2@localhost>
Message-ID: <m2acpbdd8y.fsf@soma.local>

Julian Stecklina <der_julian at web.de> writes:

> Hello,
>
> is there some kind of tutorial for UCW? I am trying to get started with
> it, but it is very hard without some initial explanations. I am aware of
> the documentation and the examples, but there is no aha-effect yet. ;)

a part of me hopes that there will be no 'ah-ha' moment. i'd like ucw
to be so natural that you don't need to "understand" it but that it
just works the way you think it should.

a part is is more realistic :) drew campsie (our residente pr) has
written: http://lisp.tech.coop/Web%2FContinuation

p.s. - were the slides useless as well?

-- 
-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 Mar 10 10:13:04 2005
From: mb at bese.it (Marco Baringer)
Date: Thu, 10 Mar 2005 11:13:04 +0100
Subject: [Bese-devel] Patch for control-flow.lisp
In-Reply-To: <787bbe1c0503041329e7fc479@mail.gmail.com> (
	=?utf-8?q?S=C5=82awek_=C5=BBak's_message_of?= "Fri, 4 Mar 2005 22:29:14
	+0100")
References: <787bbe1c0503041329e7fc479@mail.gmail.com>
Message-ID: <m2y8cvbyhb.fsf@soma.local>

S?awek ?ak <slawek.zak at gmail.com> writes:

> Fixes referral to undefined self variable in the inspector and a typo.
> Tested with HEAD (however it is called in arch:)

the real issue with this lies my miking of two different concepts:
defgeneric/cc and defaction. while it's true that defaction is a
wrapper around defmethod/cc, which is a wrapper around defmethod, an
action is not 'just another method' and attempting to define actions
in the body a defgeneric/cc is a Bad Idea (TM).

however, in control-flow.lisp and in other places it'd still be nice
to do:

(defgeneric/cc my-action (component)
  (:method ((foo foo)) ...)
  (:method ((bar bar)) ...))

so i'm going to write a macro which wraps defgeneric and expands into
defaction (as opposed to defmethod/cc as defgeneric/cc does). however,
i'm having a really hard time coming up with the name for such a
macro. suggestions?

> --- orig/src/rerl/standard-component/control-flow.lisp
> +++ mod/src/rerl/standard-component/control-flow.lisp
> @@ -63,8 +63,8 @@
>  methods, to avoid the creation of spurious actions this action
>  can be used whenever we want to cause a compoent ot answer.
>  
> -VALUE should default to COMPOENT.")
> -  (:method ((c component) &optional (value c))
> +VALUE should default to COMPONENT.")
> +  (:method ((self component) &optional (value self))
>      (answer value)))

-- 
-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 der_julian at web.de  Thu Mar 10 13:50:06 2005
From: der_julian at web.de (Julian Stecklina)
Date: Thu, 10 Mar 2005 14:50:06 +0100
Subject: [Bese-devel] UCW Tutorial
In-Reply-To: <m2acpbdd8y.fsf@soma.local>
References: <20050309200033.2ce840b2@localhost>
	<m2acpbdd8y.fsf@soma.local>
Message-ID: <20050310145006.20016ca2@localhost>

On Thu, 10 Mar 2005 11:08:45 +0100
"Marco Baringer" <mb at bese.it> wrote:

> Julian Stecklina <der_julian at web.de> writes:
> 
> > Hello,
> >
> > is there some kind of tutorial for UCW? I am trying to get started
> > with it, but it is very hard without some initial explanations. I am
> > aware of the documentation and the examples, but there is no
> > aha-effect yet. ;)
> 
> a part of me hopes that there will be no 'ah-ha' moment. i'd like ucw
> to be so natural that you don't need to "understand" it but that it
> just works the way you think it should.
> 
> a part is is more realistic :) drew campsie (our residente pr) has
> written: http://lisp.tech.coop/Web%2FContinuation
> 
> p.s. - were the slides useless as well?

The slides were not useless, but do not have the "How do I get
started"-type of information. :) I understand continuations (My last
book was Lisp in small pieces.), at least most of the time I think I
do...  

I found the Web/Continuation page yesterday very late and indeed it got
me started. :) Thanks for the pointer. The slides mention that it is
hard to think of doing things via continuations when you are used to
CGI-style programming and this is certainly true. There is some kind of
transition time where you need to forget all about what you did earlier
with web-based applications. It is like having used PASCAL exclusively
for years, then you get Lisp or Forth and wonder how to actually _do_
something with this stuff...

Btw, anyone knows about "Lisp-friendly" web-hosting in Germany? ;)

Regards,
--  Julian Stecklina

-- Common Lisp can do what C, C++, Java, PASCAL, PHP, Perl, (you --
-- name it) can do. Here's how:                                  --
--                                                               --
-- http://www.amazon.com/exec/obidos/ASIN/1590592395             --


From mb at bese.it  Thu Mar 10 17:16:30 2005
From: mb at bese.it (Marco Baringer)
Date: Thu, 10 Mar 2005 18:16:30 +0100
Subject: [Bese-devel] request for comments: qbook
Message-ID: <m2r7ina0b5.fsf@soma.local>


before i go and waste a lot of time converting ucw's documentation to
qbook i'd like some feedback on it. i converted fiveam and arnesi and
put them up here:

http://common-lisp.net/project/bese/docs/arnesi.html [458 KB]
http://common-lisp.net/project/bese/docs/fiveam.html [76 KB]

and here's qbook itself:

http://common-lisp.net/project/bese/docs/qbook.html [47 KB]

nb: it's not so the quality of the documentation i'm worried about (i
know that sucks). what i'd like to know is if the format works or not
(compared to the latex thing we have now). 

tia.
-- 
-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 Mar 10 19:03:35 2005
From: mb at bese.it (Marco Baringer)
Date: Thu, 10 Mar 2005 20:03:35 +0100
Subject: [Bese-devel] request for comments: qbook
In-Reply-To: <m2r7ina0b5.fsf@soma.local> (Marco Baringer's message of "Thu,
	10 Mar 2005 18:16:30 +0100")
References: <m2r7ina0b5.fsf@soma.local>
Message-ID: <m2u0nj1fy0.fsf@soma.local>


a snapshot of the source code is here:

ftp://ftp.common-lisp.net/pub/project/bese/qbook.tar.bz2

the style sheets are in the src directory. build the docs with
(asdf:oos 'qbook:publish-op :qbook) [after having loaded qbook].

-- 
-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 tim at fractaldragon.net  Thu Mar 10 21:32:59 2005
From: tim at fractaldragon.net (Tim Lavoie)
Date: Thu, 10 Mar 2005 15:32:59 -0600
Subject: [Bese-devel] request for comments: qbook
In-Reply-To: <m2r7ina0b5.fsf@soma.local>
References: <m2r7ina0b5.fsf@soma.local>
Message-ID: <20050310213259.GA15515@fractaldragon.net>

On Thu, Mar 10, 2005 at 06:16:30PM +0100, Marco Baringer wrote:

> nb: it's not so the quality of the documentation i'm worried about (i
> know that sucks). what i'd like to know is if the format works or not
> (compared to the latex thing we have now). 

Hi Marco,

The format seems like a good start to me, but is unnecessarily
compressed to 600 pixels in the stylesheet. Actually, the appearance
is compressed vertically as well, so more whitespace would be easier
on the eyes.

On a related note, certain entries have horizontal scroll bars of
their own, which is also distracting. I haven't dug far into the
stylesheet yet, but some form of wrapping would be better.

	Cheers,
	Tim



From ats at acm.org  Thu Mar 10 18:14:02 2005
From: ats at acm.org (Alan Shutko)
Date: Thu, 10 Mar 2005 12:14:02 -0600
Subject: [Bese-devel] request for comments: qbook
In-Reply-To: <m2r7ina0b5.fsf@soma.local> (Marco Baringer's message of "Thu, 10
	Mar 2005 18:16:30 +0100")
References: <m2r7ina0b5.fsf@soma.local>
Message-ID: <871xanz7v9.fsf@vera.springies.com>

"Marco Baringer" <mb at bese.it> writes:

> nb: it's not so the quality of the documentation i'm worried about (i
> know that sucks). what i'd like to know is if the format works or not
> (compared to the latex thing we have now). 

The major problem I have is that the text takes about a third of my
1600-pixel-wide screen, and some of the code has horizontal scroll
bars.  If the widths were fixed (so that I didn't have to scroll code
blocks and it could be printed) I'd say it's an ok format.

-- 
Alan Shutko <ats at acm.org> - I am the rocks.



From etyurin at comcast.net  Fri Mar 11 03:14:24 2005
From: etyurin at comcast.net (Eugene Tyurin)
Date: Thu, 10 Mar 2005 22:14:24 -0500
Subject: [Bese-devel] request for comments: qbook
In-Reply-To: <m2r7ina0b5.fsf@soma.local>
References: <m2r7ina0b5.fsf@soma.local>
Message-ID: <2eb16116fe9de9748455a64955edd2d9@comcast.net>


Marco,

Have you seen the documentation tool that comes with the OSE library?

http://ose.sourceforge.net/browse.php?group=tools-manual&entry=cinfo.htm

I think it has a nice document structure list that you may want to add 
to the canned set of formats (Dumpleton calls it "= tags").  Also, I am 
not sure that HTML is such a hot primary output format - horizontal 
scroll bars inside code sections definitely have to go.  Call me 
old-fashioned but what about texinfo or latex?  Both can be then 
converted to HTML, PDF, or almost any other format/medium.

--ET.



From rm at fabula.de  Fri Mar 11 11:42:20 2005
From: rm at fabula.de (rm at fabula.de)
Date: Fri, 11 Mar 2005 12:42:20 +0100
Subject: [Bese-devel] request for comments: qbook
In-Reply-To: <2eb16116fe9de9748455a64955edd2d9@comcast.net>
References: <m2r7ina0b5.fsf@soma.local>
	<2eb16116fe9de9748455a64955edd2d9@comcast.net>
Message-ID: <20050311114220.GA24094@seid-online.de>

Hi everyone,


On Thu, Mar 10, 2005 at 10:14:24PM -0500, Eugene Tyurin wrote:
> 
> Marco,
> 
> Have you seen the documentation tool that comes with the OSE library?
> 
> http://ose.sourceforge.net/browse.php?group=tools-manual&entry=cinfo.htm
> 
> I think it has a nice document structure list that you may want to add 
> to the canned set of formats (Dumpleton calls it "= tags").  Also, I am 
> not sure that HTML is such a hot primary output format - horizontal 
> scroll bars inside code sections definitely have to go.  

Let me jump in here: this seems to be a tendency lately to focus on
html-formated documentation. While i sometimes find it rather convenient
to look up references online i _really_ prefer to read the old fashioned
way - i.e. hardcopy with coffee and chair :-/
I think one of the results of this change in documentation is the temptation
of what commonly is called "auto"-documentation, documentation created from
comments and the actual code (sometimes by means of introspection, see Albert).
More and more i find myself exposed to documentation that is little more than
a pretty-printed version of the header files ... ,-)


> Call me 
> old-fashioned but what about texinfo or latex?  Both can be then 
> converted to HTML, PDF, or almost any other format/medium.

Yes, i'd go for one of these as well. I think currently there are three source
formats worth considering: 

 - latex:   + Very nice hardcopy output
            + Can be customized for the project (LISP specific makrup etc.)
	    - Harder to learn (well, ....)

 - texinfo: + Very easy to write
            + Good support for LISP-specific markup (macro vs. function etc.)
	    - Hard to customize hardcopy output (try to change the fonts ...)

 - DocBook: + Format du jour
            + xml (can be transformed to a lot of other formats)
	    - xml (sexpr would be so much nicer)
	    - _very_ ALGOL-centric
	    - "deep" document structure (lots of tags, markup down to the individual
	      function parameter [but rather ALGOL-centric]).
            - Very few LISP tools to process XML :-(
           
 
 Currently i'd go for LaTeX or texinfo - i'd be reluctant to learn yet another documentation
 tool (SBCL uses texinfo, OpenMCL uses DocBook ...)


 cheers Ralf Mattes

> 
> --ET.
> 
> _______________________________________________
> bese-devel mailing list
> bese-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel


From itoshkov at gmail.com  Fri Mar 11 12:02:52 2005
From: itoshkov at gmail.com (Ivan Toshkov)
Date: Fri, 11 Mar 2005 14:02:52 +0200
Subject: [Bese-devel] request for comments: qbook
In-Reply-To: <20050311114220.GA24094@seid-online.de>
References: <m2r7ina0b5.fsf@soma.local>
	<2eb16116fe9de9748455a64955edd2d9@comcast.net>
	<20050311114220.GA24094@seid-online.de>
Message-ID: <7c23adaa05031104027ccf7279@mail.gmail.com>

On Fri, 11 Mar 2005 12:42:20 +0100, rm at fabula.de <rm at fabula.de> wrote:
>  - texinfo: + Very easy to write
>             + Good support for LISP-specific markup (macro vs. function etc.)
>             - Hard to customize hardcopy output (try to change the fonts ...)
> 

I vote for texinfo, because its hardcopy and HTML formats are decent
enough, it's developed for writing documentation and the info files
are easily accessible from within Emacs.

Regards,
Ivan

-- 
All languages are equal,
but Lisp is more equal than others.


From jan at rychter.com  Thu Mar 10 17:47:07 2005
From: jan at rychter.com (Jan Rychter)
Date: Thu, 10 Mar 2005 18:47:07 +0100
Subject: [Bese-devel] ucw available through darcs
In-Reply-To: <m28y4xndg2.fsf@soma.local> (Marco Baringer's message of "Wed, 09
	Mar 2005 14:42:05 +0100")
References: <m2ekfuxag5.fsf@soma.local> <m2650958vr.fsf@tnuctip.rychter.com>
	<m27jkpc4p1.fsf@soma.local> <m23bv59d8m.fsf@tnuctip.rychter.com>
	<m28y4xndg2.fsf@soma.local>
Message-ID: <m24qfjv1es.fsf@tnuctip.rychter.com>

>>>>> "Marco" == Marco Baringer <mb at bese.it> writes:
 Marco> Jan Rychter <jan at rychter.com> writes:
 >>>>>>> "Marco" == Marco Baringer <mb at bese.it> writes:
 Marco> i'd messed up the cronjob, sorry. it should be fixed now (it's
 Marco> updated (along with the arch mirrors) every three hours), send
 Marco> me a big angry scary email if it isn't.
 >>
 >> [THIS IS A BIG ANGRY SCARY EMAIL]
 >>
 >> It seems to be stuck at patch-275.
 >>
 >> --J.

 Marco> am i doing something wrong here?
[...]
 Marco> 'update version number for arnesi in update.sh' is (according to
 Marco> tla logs) ucw--dev--0.3--patch-296, which is the latest
 Marco> available patch.

My bad, the archives are indeed updated fine. Please delete the scary
email part, and sorry for the noise.

--J.


From mb at bese.it  Mon Mar 14 06:25:48 2005
From: mb at bese.it (Marco Baringer)
Date: Mon, 14 Mar 2005 07:25:48 +0100
Subject: [Bese-devel] Content-Type for uploaded files?
In-Reply-To: <m2brabv4zj.fsf@Cascade.local> (
	=?iso-8859-1?q?Tiarn=E1n_=D3=2E_Corr=E1in's_message_of?= "Wed,
	23 Feb 2005 12:24:32 +0000")
References: <m2brabv4zj.fsf@Cascade.local>
Message-ID: <m2y8cqkakz.fsf@soma.local>

ocorrain at yahoo.com (Tiarn?n ? Corr?in) writes:

> Hi--
>
> how can I get the content-type of uploaded files? I have taken code
> from the example application, viz.:

eventually i did in fact need this. what i ended up doing (which is,
currently, Just Wrong) is this:

when the post data's type is "multipart/form-data" the parameters,
which are still bonud by name, are not strings but mime-part objects,
these objects are just a pair of headers (assoc list) and the body (a
string). the problem with this solution is that entry points and
callbacks need to know whether the incoming data is
multipart/form-data or regular url-encoded. (you'll notice that the
"s", "f" and "a" parameters are special cased since various parts of
the rerl assume they're strings). what i'll do, eventually, is put the
body of the form-data in the request parameters and provide a function
MIME-PART-DATA (or something) which, given the name of a parametetr,
returns all the various mime headers.

at least that's what i'll do if no one comes up with a better solution
(hint hint hint).

-- 
-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  Mon Mar 14 06:26:14 2005
From: mb at bese.it (Marco Baringer)
Date: Mon, 14 Mar 2005 07:26:14 +0100
Subject: [Bese-devel] Content-Type for uploaded files?
In-Reply-To: <m2brabv4zj.fsf@Cascade.local> (
	=?iso-8859-1?q?Tiarn=E1n_=D3=2E_Corr=E1in's_message_of?= "Wed,
	23 Feb 2005 12:24:32 +0000")
References: <m2brabv4zj.fsf@Cascade.local>
Message-ID: <m2u0nekak9.fsf@soma.local>

ocorrain at yahoo.com (Tiarn?n ? Corr?in) writes:

> Hi--
>
> how can I get the content-type of uploaded files? I have taken code
> from the example application, viz.:

eventually i did in fact need this. what i ended up doing (which is,
currently, Just Wrong) is this:

when the post data's type is "multipart/form-data" the parameters,
which are still bonud by name, are not strings but mime-part objects,
these objects are just a pair of headers (assoc list) and the body (a
string). the problem with this solution is that entry points and
callbacks need to know whether the incoming data is
multipart/form-data or regular url-encoded. (you'll notice that the
"s", "f" and "a" parameters are special cased since various parts of
the rerl assume they're strings). what i'll do, eventually, is put the
body of the form-data in the request parameters and provide a function
MIME-PART-DATA (or something) which, given the name of a parametetr,
returns all the various mime headers.

at least that's what i'll do if no one comes up with a better solution
(hint hint hint).

-- 
-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  Mon Mar 14 06:48:33 2005
From: mb at bese.it (Marco Baringer)
Date: Mon, 14 Mar 2005 07:48:33 +0100
Subject: [Bese-devel] Content-Type for uploaded files?
In-Reply-To: <m2u0nekak9.fsf@soma.local> (Marco Baringer's message of "Mon,
	14 Mar 2005 07:26:14 +0100")
References: <m2brabv4zj.fsf@Cascade.local> <m2u0nekak9.fsf@soma.local>
Message-ID: <m2psy2k9j2.fsf@soma.local>

"Marco Baringer" <mb at bese.it> writes:

> ocorrain at yahoo.com (Tiarn?n ? Corr?in) writes:
>
>> Hi--
>>
>> how can I get the content-type of uploaded files? I have taken code
>> from the example application, viz.:
>
> eventually i did in fact need this. what i ended up doing (which is,
> currently, Just Wrong) is this:
>
> when the post data's type is "multipart/form-data" the parameters,
> which are still bonud by name, are not strings but mime-part objects,
> these objects are just a pair of headers (assoc list) and the body (a
> string). the problem with this solution is that entry points and
> callbacks need to know whether the incoming data is
> multipart/form-data or regular url-encoded. (you'll notice that the
> "s", "f" and "a" parameters are special cased since various parts of
> the rerl assume they're strings). what i'll do, eventually, is put the
> body of the form-data in the request parameters and provide a function
> MIME-PART-DATA (or something) which, given the name of a parametetr,
> returns all the various mime headers.
>
> at least that's what i'll do if no one comes up with a better solution
> (hint hint hint).

p.s. - this is currently only implemented for the mod_lisp backend.

-- 
-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  Mon Mar 14 10:54:14 2005
From: mb at bese.it (Marco Baringer)
Date: Mon, 14 Mar 2005 11:54:14 +0100
Subject: [Bese-devel] request for comments: qbook
References: <m2r7ina0b5.fsf@soma.local>
Message-ID: <m2y8cq5wh5.fsf@soma.local>


i'll just respond to everyone here instead of sending out 3 seperate
emails.

1) i set the width of the text to 40em as opposed to 600px. with my
   default font-size this is slightly wider than before, hopefully
   this will adapt better to people's font-sizes. (should it be even
   wider? i don't want to fill up the entire browser window (i find
   that hard to read) but maybe that's what most people prefer?)

2) the horizontal scroll bars in the code listings are my fault. i
   tend to work with 130 columns, so my code will, occasinaly arive at
   column 100 or 110. this is a good enough reason to reformat my
   code.

3) my intention with qbook is not to replace user manuals, howtos or
   conceptual overviews, i'd like to avoid falling into that javadoc
   trap.

   however as far as describing what the classes, methods, variables
   etc. are, describing how these work and work together i'm of the
   opinion that putting this information in comments close to the code
   itself is helpfull. i'm not trying to say that it produces the best
   possible documenatation, but i've found that it's much easier for
   me to edit/update a doc string than it is to open a latex file.

4) i like latex's pdf output, but latex2html is a big huge mess. i
   _love_ info, but texinfo produces crappy html (if at least it was
   customizable....) and i've _never_ been able to get it to work with
   my tex setup. finally i think it's important that the html output
   (which is the first thing most people see) be well done. the only
   solution that i'd be happy with is generating html, latex and
   texinfo from the same source, which is exactly what i plan on
   doing.

   until i get around to writing a latex backend for qbook (it's
   shouldn't take more than a hour) i'd appreciate feedback on the
   print style sheet.

5) thanks for the comments.

6) qbook no longer generates a single html file but splits the output
   according to the level 1 headers. this required moving the demos
   around a bit:

   http://www.common-lisp.net/project/bese/docs/qbook/index.html
   http://www.common-lisp.net/project/bese/docs/fiveam/index.html

-- 
-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 Mar 23 11:19:31 2005
From: mb at bese.it (Marco Baringer)
Date: Wed, 23 Mar 2005 12:19:31 +0100
Subject: [Bese-devel] Howto Create a Wiki with UCW
Message-ID: <m2zmwumwxo.fsf@soma.local>


I've put up the first UCW tutorial:

http://common-lisp.net/project/ucw/docs/wiki/index.html

and (for those of you who can afford print toner):

http://common-lisp.net/project/ucw/docs/wiki/wiki.pdf

I'm still working on spelling and grammar and i might restructure some
parts (the "UCW Style" seciton is still a bit too short on details),
but the core idea and most of the content is already there.

feedback appreciated.

p.s. - the directory also contains the files wiki.lisp, edit.tal,
edit.tal.html, view.tal and view.tal.html whcih could be of interest.

p.p.s. - i thought i'd gotten a great deal on a new hp printer. then the
printer cartridges ran out and i had to buy new ones. 60 EURO!

-- 
-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 contact at torkel.no  Thu Mar 24 01:01:10 2005
From: contact at torkel.no (Torkel Holm)
Date: Thu, 24 Mar 2005 02:01:10 +0100
Subject: [Bese-devel] UCW and CL-typesetting
Message-ID: <87eke53lih.fsf@uib.no>

Hi 

I have been following the qbook discussion and
recently subscribed to the list.

Have you considered using CL-Typesetting for the manuals?
You probably want a nicer front end though.
And why not use CL-Typesetting as a back end for qbook as well?
In the future it would also be nice to have some printer friendly 
PDF generation of web pages.

Latex is good but its not sexprs ;)

My vote is for Lisp all the way down.

-- 
Torkel Holm, Bergen, Norway


From pjdtech2000 at gmail.com  Wed Mar 23 23:39:02 2005
From: pjdtech2000 at gmail.com (pjd tech)
Date: Wed, 23 Mar 2005 16:39:02 -0700
Subject: [Bese-devel] Developing non-interactive applications.
Message-ID: <4f712c6f05032315391fc28afd@mail.gmail.com>

Hello

I am a relative newcomer to common lisp and UCW. I am just learning
UCW to do web programming.

But my immediate desire is to write a server application in Common
Lisp using UCW (or arnesi as the case may be) where the client is not
a browser and it is not interactive.

Client and Server talk using HTTP POSTs.
There is no interaction with user once the client is started.

Client and server exchange about 10 messages in average before finishing up.

I would like to adopt UCW to writing such a server.

It means there is no need for
   - back tracking (no BACK button)
   - No cloning.

On a further note,  
   - Client doesnt support cookies.
   - But the binary protocol does support URL rewriting. As part of
each reply, server can send a URL for the client where to POST the
next message.

I just would like to use CPS style of programming so that my server
logic is linear instead of a state machine.

Is there some way I can adapt UCW to do such a thing? Or would I need
to start with arnesi, and write UCW like framework without the GUI
bits ?

I am not skilled enough to understand UCW/Arnesi implimentations yet.
So any pointers would be greatly appreciated.

Thanks
pj


From frido at q-software-solutions.de  Thu Mar 24 09:42:38 2005
From: frido at q-software-solutions.de (Friedrich Dominicus)
Date: Thu, 24 Mar 2005 10:42:38 +0100
Subject: [Bese-devel] LispWorks and UCW
Message-ID: <87wtrxxtv5.fsf@flarge.here>

sorry, for bothering you with this. I had to tweak the mopp.lisp file,
and am now not sure if it's a bug with LispWorks or with the given
code.

As I understand all the symbols needed for portable MOP should get
imported with 
(defmethod provide-mopp-symbol ((symbol symbol) (implementation (eql :lispworks)))
  (when (find-symbol (string symbol) :clos)
    (import-to-mopp (find-symbol (string symbol) :clos))))


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:

(eval-when (:compile-toplevel :execute)
  (defclass %meta-class (standard-class) ())
  #-LispWorks
  (defmethod mopp:validate-superclass ((c %meta-class) (s mopp:standard-class)) t)
  #+Lispworks
  (defmethod mopp:validate-superclass ((c %meta-class) (s clos::standard-class)) t)
  #-LispWorks
  (defclass %dsd (mopp:standard-direct-slot-definition)
    ((%slot :accessor %slot :initarg :%slot :initform nil)))
    #+LispWorks
    (defclass %dsd (clos::standard-direct-slot-definition)
      ((%slot :accessor %slot :initarg :%slot :initform nil)))
    

  (defmethod mopp:direct-slot-definition-class ((c %meta-class) &rest initargs)
    (declare (ignore c initargs))
    (find-class '%dsd))

  (defclass %class ()
    ((a-slot :%slot 1))
    (:metaclass %meta-class))

  (let ((definition (if (consp (%slot (find-if (lambda (s)
						 (eql 'a-slot 
                                                      #-LispWorks
                                                      (mopp:slot-definition-name s)
                                                      #+LispWorks
                                                      (clos:slot-definition-name s)
                                                      ))
                                               #-LispWorks
                                               (mopp:class-direct-slots (find-class '%class))
                                               #+LispWorks
                                               (clos:class-direct-slots (find-class '%class))
                                               )))
			(lambda (slot-value) (first slot-value))
			(lambda (slot-value) slot-value))))


but with that I got UCW compiled and running with LispWorks. I'm quite
sure that this is not the "right" solution to the problem. Maybe
someone here has a better suggestion.

I still have some problems understanding UCW. Mostly how the parts
should play together. The relationship between application, component,
sub-components etc is not clear to me. 

I do not understand what slime is used for, I guess it's to see the
error messages. Is this a correct?

And well there is a thing I do  not like. The use of links for
starting actions. I would think for that buttons are the "right"
choice. Now I read someone has hacked around ucw:button? 

Would this someone explain what he has to done to implement that?

Regards
Friedrich


From mb at bese.it  Thu Mar 24 10:55:33 2005
From: mb at bese.it (Marco Baringer)
Date: Thu, 24 Mar 2005 11:55:33 +0100
Subject: [Bese-devel] Developing non-interactive applications.
References: <4f712c6f05032315391fc28afd@mail.gmail.com>
Message-ID: <m2ll8duxcq.fsf@soma.local>

pjd tech <pjdtech2000 at gmail.com> writes:

> It means there is no need for
>    - back tracking (no BACK button)
>    - No cloning.
>
> On a further note,  
>    - Client doesnt support cookies.
>    - But the binary protocol does support URL rewriting. As part of
> each reply, server can send a URL for the client where to POST the
> next message.
>
> I just would like to use CPS style of programming so that my server
> logic is linear instead of a state machine.

i don't completly understantd the details (and the details are very
important at this point), but i'll try anyway.

you have a server and a client (interactive or not it doesn't matter
much at this point). the client sends http requests and the server
resonds. unlike a regular web page we don't have multiple links to
chose from but only one. 

assuming you want to reuse UCW as much as possible:

your publicly visible url (the first url clients request from the
server) would be a ucw entry point:

(defentry-point "/start" (:application my-app) 
    ([request params for first request])
  (do-stuff [request params])
  (call 'first-response-object)
  (do-more-stuff)
  (call 'second-response-object)
  ...)

however the responses from the server aren't html but are some binary
protocol, all this means is that you'll need to write your own
render-on methods whcih don't use tal or yaclml (which is fine) [you
still want the http response headers right?]:

(defmethod render-on ((res response) (comp first-response-object))
  (write-as-binary-protocol comp :stream (content-stream res)))

which basically leaves use with one unanswered question: what url do
we send to the client in such a fashion that the next request (the one
after first-response-object) "returns" us to the right place in the
entry-point? easy (if you know ucw :)):

(defmethod render-on ((res response) (comp first-response-object))
  (write-as-binary-protocol comp 
    :stream (content-stream res)
    :next-url (compute-url comp
                :action-id (make-new-action (context.current-frame *context*)
                                            (lambda () (ok comp))))))

if you tell the client to send their next request to :next-url then
the (call 'first-response-object) form will "return" and execution in
the defentry-point will continue. The important thing to notice is
that every ucw component (as long as its a subclass of
standard-component) can use the OK action. if we want the (call
'first-response-object) form to return a value other nil we just need
to pass that value to OK:

(ok comp [call form's return value])

> Is there some way I can adapt UCW to do such a thing? Or would I need
> to start with arnesi, and write UCW like framework without the GUI
> bits ?

i would suggest, though it may seem harder at first, to mold ucw into
what you need instead of trying to rewrite ucw (i've already written
ucw once and while it's a LOT of fun it's also a lot of work).

i'd start off with something very simple which works (along the lines
of the code sample above). you can then later, when your sure it works
and your sure you want to use UCW, define your own session and
component object and eliminate the backtracking and other component
overhead. this isn't very difficult to do, i'm just suggesting that
you start by getting something (anything) working instead of trying to
do it all at once.


hth.
-- 
-Marco Baringer

Baringer Electronics and Software Engineering
www.bese.it


From mb at bese.it  Thu Mar 24 10:56:25 2005
From: mb at bese.it (Marco Baringer)
Date: Thu, 24 Mar 2005 11:56:25 +0100
Subject: [Bese-devel] LispWorks and UCW
In-Reply-To: <87wtrxxtv5.fsf@flarge.here> (Friedrich Dominicus's message of
	"Thu, 24 Mar 2005 10:42:38 +0100")
References: <87wtrxxtv5.fsf@flarge.here>
Message-ID: <m2hdj1uxba.fsf@soma.local>

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

> sorry, for bothering you with this. I had to tweak the mopp.lisp file,
> and am now not sure if it's a bug with LispWorks or with the given
> code.

never say sorry for a bug report.

> As I understand all the symbols needed for portable MOP should get
> imported with 
> (defmethod provide-mopp-symbol ((symbol symbol) (implementation (eql :lispworks)))
>   (when (find-symbol (string symbol) :clos)
>     (import-to-mopp (find-symbol (string symbol) :clos))))

that's the idea yes.

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

[ snip ]

> but with that I got UCW compiled and running with LispWorks. I'm quite
> sure that this is not the "right" solution to the problem. Maybe
> someone here has a better suggestion.

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.

The code in mopp.lisp will only work if lispwork does in fact define
all the symbols we need in the clos package, this was once the case
though things may have changed.

> I still have some problems understanding UCW. Mostly how the parts
> should play together. The relationship between application, component,
> sub-components etc is not clear to me. 

an application represents a program. [multiple programs can live
within the same server]. A component represent a piece of the user
interface (a window, a pane, a button, a label, a calendar,
etc.). Components are often (but not always and not neccessarixly)
combined (for example: the admin app has a window component which
"contains" a tabbed-pane component which "contains" other
components. one of these other components is the rerl component which
"contains" a form componet which "contains" other component).

i guess the question is: how does one component "contain" another? the
answer is that, generally, the container component will have slots
whose values are the contained components (or lists of components),
however ucw really doesn't care. the only thing whcih is usefull (but
even this can be ignored) is that a given component know who, on the
screen, its parent component is. if this relation is setup then the
method compute-url (and update-url) will work as you expect and action
urls are affected by the "closest" components.

> I do not understand what slime is used for, I guess it's to see the
> error messages. Is this a correct?

among other things, yes. slime is used as a generic portability layer,
it provides access to the debugger, the sockets and to locks on all
lisps. i assume that people already have slime installed so it was an
easy dependency to add.

> And well there is a thing I do  not like. The use of links for
> starting actions. I would think for that buttons are the "right"
> choice. Now I read someone has hacked around ucw:button? 

replace (<ucw:a :action ...) with (<ucw:button :action ...). 

NB: <ucw:button, unlike <ucw:a, must be wrapped in a <ucw:form tag.

> Would this someone explain what he has to done to implement that?

Alan Shutko wrote the <ucw:button code, look in
ucw/src/yaclml/ucw-tags.lisp. (it's very similar to the definiton of
<ucw:a). Basically the <ucw:button tag macro (like <ucw:input :type
"submit") expands into a small amout of javascript which registers the
action with ucw (using make-new-action) and puts the proper value in
the action parameter wihch will be sent back to the server.

-- 
-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 ats at acm.org  Thu Mar 24 17:08:59 2005
From: ats at acm.org (Alan Shutko)
Date: Thu, 24 Mar 2005 11:08:59 -0600
Subject: [Bese-devel] Howto Create a Wiki with UCW
In-Reply-To: <m2zmwumwxo.fsf@soma.local> (Marco Baringer's message of "Wed, 23
	Mar 2005 12:19:31 +0100")
References: <m2zmwumwxo.fsf@soma.local>
Message-ID: <87k6nxgedw.fsf@vera.springies.com>

"Marco Baringer" <mb at bese.it> writes:

> I've put up the first UCW tutorial:

Excellent!  I've just skimmed it so far, and it's really clear.  It
amazes me how difficult I was making some things in my current
project.  

-- 
Alan Shutko <ats at acm.org> - I am the rocks.
Star Trek The Musical II: The Rap of Kahn.


From pjdtech2000 at gmail.com  Fri Mar 25 17:25:49 2005
From: pjdtech2000 at gmail.com (pjd tech)
Date: Fri, 25 Mar 2005 10:25:49 -0700
Subject: [Bese-devel] Developing non-interactive applications.
In-Reply-To: <m2ll8duxcq.fsf@soma.local>
References: <4f712c6f05032315391fc28afd@mail.gmail.com>
	<m2ll8duxcq.fsf@soma.local>
Message-ID: <4f712c6f050325092541d2655b@mail.gmail.com>

On Thu, 24 Mar 2005 11:55:33 +0100, Marco Baringer <mb at bese.it> wrote:
> i'd start off with something very simple which works (along the lines
> of the code sample above). you can then later, when your sure it works
> and your sure you want to use UCW, define your own session and
> component object and eliminate the backtracking and other component
> overhead. this isn't very difficult to do, i'm just suggesting that
> you start by getting something (anything) working instead of trying to
> do it all at once.
> 
> hth.

Thank you very much Marco. That is exactly the kind of advise I was
looking for. I will try it that way and see how far I get. I will come
back with more specific questions later.

Thanks again for UCW. It is a remarkable piece of engineering.

-pj


From frido at q-software-solutions.de  Sat Mar 26 07:13:23 2005
From: frido at q-software-solutions.de (Friedrich Dominicus)
Date: Sat, 26 Mar 2005 08:13:23 +0100
Subject: [Bese-devel] LispWorks and UCW
In-Reply-To: <m2hdj1uxba.fsf@soma.local> (Marco Baringer's message of "Thu,
	24 Mar 2005 11:56:25 +0100")
References: <87wtrxxtv5.fsf@flarge.here> <m2hdj1uxba.fsf@soma.local>
Message-ID: <87is3enalo.fsf@flarge.here>

"Marco Baringer" <mb at bese.it> writes:

>
> 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
Well this happens:
(trace mopp::provide-mopp-symbol)
Warning: Can't trace IT.BESE.ARNESI.MOPP::PROVIDE-MOPP-SYMBOL; it
doesn't name a traceable procedure.
Ok it seems I have to switch to the proper package:
(in-package :it.bese.arnesi.mopp%internals)
#<PACKAGE IT.BESE.ARNESI.MOPP%INTERNALS>

IT.BESE.ARNESI.MOPP%INTERNALS 42 : 4 > :top

IT.BESE.ARNESI.MOPP%INTERNALS 43 > (cl:trace provide-mopp-symbol)


> 2) reload mopp.lisp 
here's the output I got:
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:CLASS-DIRECT-SUBCLASSES
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:CLASS-DIRECT-DEFAULT-INITARGS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:STANDARD-READER-METHOD
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:FUNCALLABLE-STANDARD-INSTANCE-ACCESS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : NIL
Warning: Unimplemented MOP symbol: IT.BESE.ARNESI.MOPP:FUNCALLABLE-STANDARD-INSTANCE-ACCESS
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:COMPUTE-CLASS-PRECEDENCE-LIST
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:METHOD
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:CLASS-SLOTS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:CLASS-DEFAULT-INITARGS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:DIRECT-SLOT-DEFINITION-CLASS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:FINALIZE-INHERITANCE
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:SPECIALIZER-DIRECT-GENERIC-FUNCTIONS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:COMPUTE-APPLICABLE-METHODS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:CLASS-DIRECT-SLOTS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:COMPUTE-DISCRIMINATING-FUNCTION
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:SLOT-DEFINITION
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:BUILT-IN-CLASS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:INTERN-EQL-SPECIALIZER
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : NIL
Warning: Unimplemented MOP symbol: IT.BESE.ARNESI.MOPP:INTERN-EQL-SPECIALIZER
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:EQL-SPECIALIZER
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:STANDARD-METHOD
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:SPECIALIZER-DIRECT-METHODS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:SLOT-DEFINITION-LOCATION
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:EFFECTIVE-SLOT-DEFINITION-CLASS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:METHOD-LAMBDA-LIST
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:MAKE-METHOD-LAMBDA
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:CLASS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:COMPUTE-APPLICABLE-METHODS-USING-CLASSES
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : NIL
Warning: Unimplemented MOP symbol: IT.BESE.ARNESI.MOPP:COMPUTE-APPLICABLE-METHODS-USING-CLASSES
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:REMOVE-DIRECT-METHOD
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:MAP-DEPENDENTS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:UPDATE-DEPENDENT
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:SLOT-DEFINITION-INITARGS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:GENERIC-FUNCTION
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:ADD-METHOD
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:ACCESSOR-METHOD-SLOT-DEFINITION
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:GENERIC-FUNCTION-NAME
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:CLASS-PROTOTYPE
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:GENERIC-FUNCTION-METHODS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:SLOT-DEFINITION-TYPE
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:SLOT-DEFINITION-WRITERS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:METHOD-FUNCTION
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:METHOD-COMBINATION
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:CLASS-DIRECT-SUPERCLASSES
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:EQL-SPECIALIZER-OBJECT
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:SLOT-DEFINITION-ALLOCATION
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:SET-FUNCALLABLE-INSTANCE-FUNCTION
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:COMPUTE-EFFECTIVE-SLOT-DEFINITION
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:GENERIC-FUNCTION-METHOD-COMBINATION
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:READER-METHOD-CLASS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:FUNCALLABLE-STANDARD-CLASS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:METHOD-SPECIALIZERS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:REMOVE-DIRECT-SUBCLASS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:COMPUTE-EFFECTIVE-METHOD
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:ADD-DEPENDENT
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:MAKE-INSTANCE
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:COMPUTE-DEFAULT-INITARGS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:ALLOCATE-INSTANCE
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...


  >> SYMBOL         : IT.BESE.ARNESI.MOPP:STANDARD-CLASS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T

-- Seems to be ok! 

0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:REMOVE-DEPENDENT
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:ENSURE-GENERIC-FUNCTION
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:STANDARD-ACCESSOR-METHOD
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:SLOT-DEFINITION-NAME
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:ADD-DIRECT-SUBCLASS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:ENSURE-CLASS-USING-CLASS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:SLOT-DEFINITION-READERS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:REMOVE-METHOD
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:CLASS-PRECEDENCE-LIST
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:FORWARD-REFERENCED-CLASS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:WRITER-METHOD-CLASS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:VALIDATE-SUPERCLASS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:STANDARD-OBJECT
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:STANDARD-SLOT-DEFINITION
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:SLOT-VALUE-USING-CLASS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:FIND-METHOD-COMBINATION
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:EXTRACT-LAMBDA-LIST
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:SLOT-DEFINITION-DOCUMENTATION
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : NIL
Warning: Unimplemented MOP symbol: IT.BESE.ARNESI.MOPP:SLOT-DEFINITION-DOCUMENTATION
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:COMPUTE-SLOTS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:SPECIALIZER
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:DIRECT-SLOT-DEFINITION
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:SLOT-MAKUNBOUND-USING-CLASS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:SLOT-DEFINITION-INITFUNCTION
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:SLOT-BOUNDP-USING-CLASS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:METHOD-QUALIFIERS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:EXTRACT-SPECIALIZER-NAMES
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:EFFECTIVE-SLOT-DEFINITION
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:GENERIC-FUNCTION-ARGUMENT-PRECEDENCE-ORDER
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:SLOT-DEFINITION-INITFORM
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:CLASS-FINALIZED-P
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:ADD-DIRECT-METHOD
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:STANDARD-GENERIC-FUNCTION
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:DIRECT-SLOT-DEFINITION-VALUE
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:GENERIC-FUNCTION-METHOD-CLASS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:STANDARD-INSTANCE-ACCESS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:METHOD-GENERIC-FUNCTION
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:STANDARD-EFFECTIVE-SLOT-DEFINITION
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:ENSURE-GENERIC-FUNCTION-USING-CLASS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:FUNCALLABLE-STANDARD-OBJECT
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:CLASS-NAME
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:STANDARD-DIRECT-SLOT-DEFINITION
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:STANDARD-WRITER-METHOD
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:GENERIC-FUNCTION-DECLARATIONS
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:METAOBJECT
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
0 PROVIDE-MOPP-SYMBOL > ...
  >> SYMBOL         : IT.BESE.ARNESI.MOPP:GENERIC-FUNCTION-LAMBDA-LIST
  >> IMPLEMENTATION : :LISPWORKS
0 PROVIDE-MOPP-SYMBOL < ...
  << VALUE-0 : T
;;; Compilation finished with 1 warning, 0 errors.



> 3) check what (find-symbol (string
> 'mopp::standard-class) :CLOS) returns.
That yields:

(find-symbol (string 'mopp:standard-class) :clos)
STANDARD-CLASS
:EXTERNAL

IT.BESE.ARNESI.MOPP%INTERNALS 48 : 1 > (find-symbol (string 'mopp:standard-class) :mopp)
IT.BESE.ARNESI.MOPP:STANDARD-CLASS
:EXTERNAL

Seems to be ok, but removing this line:
#+Lispworks
  (defmethod mopp:validate-superclass ((c %meta-class) (s
clos::standard-class)) t)

yields an error again:
**++++ Error in (METHOD
                 IT.BESE.ARNESI.MOPP:VALIDATE-SUPERCLASS
                 (IT.BESE.ARNESI.MOPP%INTERNALS::%META-CLASS
                  IT.BESE.ARNESI.MOPP:STANDARD-CLASS)): 

changing this line:
(defmethod mopp:validate-superclass ((c %meta-class) (s
mopp:standard-class)) t)

to
(defmethod mopp:validate-superclass ((c %meta-class) (s
mopp::standard-class)) t)

allows successfull compilation.....

I do not think this is ok...

Regards
Friedrich


From keith.irwin at gmail.com  Wed Mar 30 01:52:29 2005
From: keith.irwin at gmail.com (Keith Irwin)
Date: Tue, 29 Mar 2005 17:52:29 -0800
Subject: [Bese-devel] sbcl / swank
Message-ID: <8aff815905032917523107326@mail.gmail.com>

Folks--

I *finally* got UCW examples up and running.  If you're thinking about
tutorials, just some basic config stuff would be nice.  For instance,
using mod_lisp2, you have to set an Alias in http.conf in order to get
the stylesheet to serve up.

A basic quick how-to for starting/stopping the server would be nice,
too (though I got hints from init.lisp).

Maybe it's way too early in your development cycle before that kind of
thing is necessary.  I notice there's no bese-users list. ;)

ANYWAY, I'm really excited about exploring this framework!

So, the one problem I have is trying to connect to the running server via slime.

 * emacs from cvs
 * latest slime (cvs -q update)
 * sbcl 0.8.20 (on ubuntu: i.e., threads)
 * ucw 0.3.7

To reproduce:

----
gnome-terminal
sbcl
 * (load "init.lisp")
<watch spewage>

start up a new emacs
M-x slime-connect <ret> 127.0.0.1 <ret> 4005
----

Slime then seems to just hang there.  However, if I go to the terminal
and hit C-c, effectively shuttdown something (the socket connection is
there, I think, but nothing gets served), slime then will connect.

* If, in emacs/slime, I do a (ucw:shutdown-server ...), I'm fine.

* If I then do: (ucw:startup-server ...), the server starts, but the
repl is blocked.

* If I instead go to the terminal and (ucw:startup-server), the
emacs/slime repl is blocked as well.

Is this expected behavior?  (I tried starting a new swank listener
from the admin console, no go either.)

Just to test, I opened a terminal, started sbcl, (require 'swank),
(create-swank-server), then opened a fresh new emacs, M-x
slime-connect yadda yadda and it worked, so I'm guessing it's not at
least an obvious config issue outside of UCW itself.

SO, maybe this is a bug?  Perhaps it's an FAQ?

Any help appreciated!

Again, looking forward to seeing how this style of webapp development
can bring back some of the fun.... ;)

Keith


From der_julian at web.de  Wed Mar 30 19:02:25 2005
From: der_julian at web.de (Julian Stecklina)
Date: Wed, 30 Mar 2005 21:02:25 +0200
Subject: [Bese-devel] UCW and POST
Message-ID: <20050330210225.2949591e@localhost>

Hello,

I have the following form:

 <form method="POST" enctype="multipart/form-data" ucw:action="(upload
$component)">  <table>
    <tr>
      <td>Dateiname</td>
      <td><input type="file" ucw:accessor="(file $component)"/></td>
    </tr>
    <tr>
      <td></td>
      <td><input type="submit" value="post file"/></td>
    </tr>
  </table>
 </form>

But everytime I try to upload a file, UCW drops me back to the entry
point of the application: index.ucw.

Is this supposed to work? How can I debug this behaviour?

Regards,
-- 
Julian Stecklina

-- Common Lisp can do what C, C++, Java, PASCAL, PHP, Perl, (you --
-- name it) can do. Here's how:                                  --
--                                                               --
-- http://www.amazon.com/exec/obidos/ASIN/1590592395             --


From der_julian at web.de  Thu Mar 31 00:50:10 2005
From: der_julian at web.de (Julian Stecklina)
Date: Thu, 31 Mar 2005 02:50:10 +0200
Subject: [Bese-devel] checkboxes
Message-ID: <20050331025010.1eef6cf0@localhost>

Hello,

I have made a component to select among a list of items:

;; Range select

(defcomponent pic-range-select ()
  ((items :initarg :items :initform nil
	  :reader items)
   (hash  :initform (make-hash-table :test #'eq)
	  :reader hash)))

(defmethod render-on ((res response) (range pic-range-select))
  (<ucw:form
   (<:table
    (loop
       for item in (items range)
       do (<:tr
	   (<:td
	    (render-range-select-item range item))
	   (<:td
	    (<ucw:input :type "checkbox"
			:accessor (gethash item (hash range)))))))
   (<ucw:input :type "submit" :action (range-select range))))

(defmethod render-range-select-item ((range pic-range-select) item)
  (<:as-html item))

(defaction range-select ((range pic-range-select))
  (answer (let ((values nil))
	    (maphash (lambda (key val)
		       (when val
			 (push key values)))
		     (hash range))
	    values)))

The problem is that it always returns a list containing the last element
of items. Am I missing something?

Regards,
-- 
Julian Stecklina

-- Common Lisp can do what C, C++, Java, PASCAL, PHP, Perl, (you --
-- name it) can do. Here's how:                                  --
--                                                               --
-- http://www.amazon.com/exec/obidos/ASIN/1590592395             --


From mb at bese.it  Thu Mar 31 07:57:31 2005
From: mb at bese.it (Marco Baringer)
Date: Thu, 31 Mar 2005 09:57:31 +0200
Subject: [Bese-devel] checkboxes
In-Reply-To: <20050331025010.1eef6cf0@localhost> (Julian Stecklina's message
	of "Thu, 31 Mar 2005 02:50:10 +0200")
References: <20050331025010.1eef6cf0@localhost>
Message-ID: <m2is382qok.fsf@soma.local>

Julian Stecklina <der_julian at web.de> writes:

> (defmethod render-on ((res response) (range pic-range-select))
>   (<ucw:form
>    (<:table
>     (loop
>        for item in (items range)
>        do (<:tr
> 	   (<:td
> 	    (render-range-select-item range item))
> 	   (<:td
> 	    (<ucw:input :type "checkbox"
> 			:accessor (gethash item (hash range)))))))
>    (<ucw:input :type "submit" :action (range-select range))))

i always get this wrong too, and i don't know of a "good" fix. the
problem here is that :accessor uses a closure. (gethash item (hash
range)) closes over range, whcih is good, and item, but loop does not
create a new binding over each iteration, it merly modifies the
current binding. try this:

(defmethod render-on ((res response) (range pic-range-select))
  (<ucw:form
   (<:table
    (loop
       for item in (items range)
       do (<:tr
	   (<:td
	    (render-range-select-item range item))
	   (<:td
             ;; create a fresh binding of item for every checkbox
             (let ((item item))
 	       (<ucw:input :type "checkbox"
		 	   :accessor (gethash item (hash range))))))))
   (<ucw:input :type "submit" :action (range-select range))))

-- 
-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 Mar 31 08:49:17 2005
From: mb at bese.it (Marco Baringer)
Date: Thu, 31 Mar 2005 10:49:17 +0200
Subject: [Bese-devel] sbcl / swank
References: <8aff815905032917523107326@mail.gmail.com>
Message-ID: <m23buc2oaa.fsf@soma.local>

Keith Irwin <keith.irwin at gmail.com> writes:

> Folks--
>
> I *finally* got UCW examples up and running.  If you're thinking about
> tutorials, just some basic config stuff would be nice.  For instance,
> using mod_lisp2, you have to set an Alias in http.conf in order to get
> the stylesheet to serve up.

You do? Isn't symlinking from htdocs enough?

> A basic quick how-to for starting/stopping the server would be nice,
> too (though I got hints from init.lisp).

Real Soon Now (TM).

> So, the one problem I have is trying to connect to the running server via slime.
>
>  * emacs from cvs
>  * latest slime (cvs -q update)
>  * sbcl 0.8.20 (on ubuntu: i.e., threads)
>  * ucw 0.3.7
>
> To reproduce:
>
> ----
> gnome-terminal
> sbcl
>  * (load "init.lisp")
> <watch spewage>
>
> start up a new emacs
> M-x slime-connect <ret> 127.0.0.1 <ret> 4005
> ----
>
> Slime then seems to just hang there.  However, if I go to the terminal
> and hit C-c, effectively shuttdown something (the socket connection is
> there, I think, but nothing gets served), slime then will connect.
>
> * If, in emacs/slime, I do a (ucw:shutdown-server ...), I'm fine.
>
> * If I then do: (ucw:startup-server ...), the server starts, but the
> repl is blocked.
>
> * If I instead go to the terminal and (ucw:startup-server), the
> emacs/slime repl is blocked as well.
>
> Is this expected behavior?  (I tried starting a new swank listener
> from the admin console, no go either.)

It looks like ucw is acting like a single thread lisp. this is exactly
how ucw works on, for example, clisp or sbcl/ppc. what's the value of
ucw::*have-threads*? what happens if you type, at the repl:

(swank-backend:spawn (lambda () (sleep 30))
                     :name "zzzz")

> Just to test, I opened a terminal, started sbcl, (require 'swank),
> (create-swank-server), then opened a fresh new emacs, M-x
> slime-connect yadda yadda and it worked, so I'm guessing it's not at
> least an obvious config issue outside of UCW itself.
>
> SO, maybe this is a bug?  Perhaps it's an FAQ?

sounds like a bug to me.

-- 
-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 der_julian at web.de  Thu Mar 31 11:23:06 2005
From: der_julian at web.de (Julian Stecklina)
Date: Thu, 31 Mar 2005 13:23:06 +0200
Subject: [Bese-devel] checkboxes
In-Reply-To: <m2is382qok.fsf@soma.local>
References: <20050331025010.1eef6cf0@localhost>
	<m2is382qok.fsf@soma.local>
Message-ID: <20050331132306.5b97ea60@localhost>

On Thu, 31 Mar 2005 09:57:31 +0200
"Marco Baringer" <mb at bese.it> wrote:

> Julian Stecklina <der_julian at web.de> writes:
> 
> > (defmethod render-on ((res response) (range pic-range-select))
> >   (<ucw:form
> >    (<:table
> >     (loop
> >        for item in (items range)
> >        do (<:tr
> > 	   (<:td
> > 	    (render-range-select-item range item))
> > 	   (<:td
> > 	    (<ucw:input :type "checkbox"
> > 			:accessor (gethash item (hash range)))))))
> >    (<ucw:input :type "submit" :action (range-select range))))
> 
> i always get this wrong too, and i don't know of a "good" fix. the
> problem here is that :accessor uses a closure. (gethash item (hash
> range)) closes over range, whcih is good, and item, but loop does not
> create a new binding over each iteration, it merly modifies the
> current binding. try this:

Thanks. I read "Always use fresh bindings with loop" somewhere, but did
not make the mental leap, that loop modifies its bindings.

Regards,
-- 
Julian Stecklina

-- Common Lisp can do what C, C++, Java, PASCAL, PHP, Perl, (you --
-- name it) can do. Here's how:                                  --
--                                                               --
-- http://www.amazon.com/exec/obidos/ASIN/1590592395             --