From mbkennedy at austin.rr.com  Mon Dec  1 01:37:46 2003
From: mbkennedy at austin.rr.com (Matthew Kennedy)
Date: Sun, 30 Nov 2003 19:37:46 -0600
Subject: [Bese-devel] some patches for sbcl and clisp
References: <8765h2dqch.fsf@killr.ath.cx>
	<mailman.252.1070210972.20290.bese-devel@common-lisp.net>
Message-ID: <871xrpuxlh.fsf@killr.ath.cx>

Marco Baringer <mb at bese.it> writes:

[...]

> the patch to src/strings.lisp has been applied (i just added
> :load-toplevel and :execute to the args to eval-when).
>
> However, the flet problem bugs me. I don't understand why sbcl would
> have issues with that, and i managed to compile and load everything
> in sbcl friday (on a x86 box i don't have access to now). could you
> tell me exactly what the error was?

Sorry for the confusion: the flet problem was with clisp (not sbcl).
Attached is the compilation log which shows the error.

Best regards,

Matt

-- 
Matthew Kennedy

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: clisp-arnesi.log
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20031130/582521dd/attachment.ksh>

From mb at bese.it  Sun Dec  7 10:40:44 2003
From: mb at bese.it (Marco Baringer)
Date: Sun, 07 Dec 2003 11:40:44 +0100
Subject: [Bese-devel] Re: [Clump] UnCommon Web version 0.1 - "learning to
	crawl"
In-Reply-To: <08A8608F-289D-11D8-8620-00039344B8E8@beta9.be> (Sven Van
	Caekenberghe's message of "Sun, 7 Dec 2003 11:06:32 +0100")
References: <m2ad69rckt.fsf@bese.it>
	<08A8608F-289D-11D8-8620-00039344B8E8@beta9.be>
Message-ID: <m2wu989ahf.fsf@bese.it>

Sven Van Caekenberghe <sven at beta9.be> writes:

> And then invoked it on the command line and tried to open the URL
> http://localhost:3001/ucw/examples in Safari.

ucw has not yet decided how to handle 404 errors, this is certainly
one part of the problem, you should try one of:

http://localhost:3001/ucw/examples/hello-world
http://localhost:3001/ucw/examples/counter
http://localhost:3001/ucw/examples/error
http://localhost:3001/ucw/admin/

(the presence or lack of trailing slashes is important)

> This gave an error in a 'worker' thread, to which I yielded to see a
> backtrace.

[snip]

> This is the listener interaction:
>  > Error in process 1-aserve-worker(2): Unknown type specifier:
>    NET.URI::ALPHA-CHAR
>  > While executing: CCL::%%TYPEP

i have gotten this error before, unfortunetly i can't reliably
reproduce it and from looking at the code i don't really understand
why it happens. i'll need to investigate more.

-- 
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
     -Leonard Cohen




From asf at boinkor.net  Sun Dec  7 10:39:33 2003
From: asf at boinkor.net (Andreas Fuchs)
Date: Sun, 07 Dec 2003 11:39:33 +0100
Subject: [Bese-devel] arnesi matcher and :greedy-star
Message-ID: <86ptf07vyy.wl%asf@boinkor.net>

hi all,

I was thinking about using the arnesi matcher in a project of
mine. This would involve matching an arbitrary number of :ANYTHINGs in
a list, so I thought :GREEDY-STAR would be the perfect match (no pun
intended). Unfortunately, I can't make it work. when I try the in:

(match '(:list* (:greedy-star :anything) a 'b :anything) '(1 2 a b))

I get an error:

invalid number of arguments: 1
   [Condition of type SB-INT:SIMPLE-PROGRAM-ERROR]

Restarts:
  0: [ABORT] Reduce debugger level (leaving debugger, returning to toplevel).
  1: [TOPLEVEL] Restart at toplevel READ/EVAL/PRINT loop.

Backtrace:
0: ("XEP for #'(LAMBDA (IT.BESE.ARNESI::S IT.BESE.ARNESI::K IT.BESE.ARNESI::Q) (FUNCALL IT.BESE.ARNESI::K # ...))" 1 1 #<FUNCTION "CLOSURE" {4801B205}> 168683692)[:EXTERNAL]
1: ("#'(LAMBDA (IT.BESE.ARNESI::S IT.BESE.ARNESI::K IT.BESE.ARNESI::Q) (IF # # ...))" #S(IT.BESE.ARNESI::MATCH-STATE :TARGET 1 :BINDINGS NIL :MATCHED NIL) #<FUNCTION "CLOSURE" {4801B205}> #<FUNCTION "CLOSURE" {4801B1DD}>)
2: (MATCH #<FUNCTION "CLOSURE" {4801B195}> (1 2 A B))
3: (MATCH (:LIST* (:GREEDY-STAR :ANYTHING) A (QUOTE B) :ANYTHING) (1 2 A B))
4: (SB-INT:EVAL-IN-LEXENV 2 (MATCH (QUOTE (:LIST* # A # :ANYTHING)) (QUOTE (1 2 A B))) #S(SB-KERNEL:LEXENV :FUNS NIL :VARS NIL :BLOCKS NIL :TAGS NIL :TYPE-RESTRICTIONS NIL :LAMBDA NIL :CLEANUP NIL :POLICY ((SPEED . 1) (SPACE . 1) (SAFETY . 1) (INHIBIT-WARNINGS . 1) (DEBUG . 1) (COMPILATION-SPEED . 1))))[:EXTERNAL]
5: ("hairy arg processor for SWANK::EVAL-REGION" "(match '(:list* (:greedy-star :anything) a 'b :anything) '(1 2 a b))" T)
6: (SWANK:LISTENER-EVAL "(match '(:list* (:greedy-star :anything) a 'b :anything) '(1 2 a b)) ")

So, how should the :GREEDY-STAR matcher be used? Is it the right thing
to use at all? And why does the :ANYTHING matcher match all elements
at the end of a list, but only one element in any other position?

Thanks,
-- 
Andreas Fuchs, <asf at acm.org>, asf at jabber.at, antifuchs



From sven at beta9.be  Sun Dec  7 12:37:29 2003
From: sven at beta9.be (Sven Van Caekenberghe)
Date: Sun, 7 Dec 2003 13:37:29 +0100
Subject: [Bese-devel] Re: [Clump] UnCommon Web version 0.1 - "learning to
	crawl"
In-Reply-To: <m2wu989ahf.fsf@bese.it>
References: <m2ad69rckt.fsf@bese.it>
	<08A8608F-289D-11D8-8620-00039344B8E8@beta9.be>
	<m2wu989ahf.fsf@bese.it>
Message-ID: <1ED3DF0A-28B2-11D8-8620-00039344B8E8@beta9.be>

On 07 Dec 2003, at 11:40, Marco Baringer wrote:

> Sven Van Caekenberghe <sven at beta9.be> writes:
>
>> And then invoked it on the command line and tried to open the URL
>> http://localhost:3001/ucw/examples in Safari.
>
> ucw has not yet decided how to handle 404 errors, this is certainly
> one part of the problem, you should try one of:
>
> http://localhost:3001/ucw/examples/hello-world
> http://localhost:3001/ucw/examples/counter
> http://localhost:3001/ucw/examples/error
> http://localhost:3001/ucw/admin/
>
> (the presence or lack of trailing slashes is important)
>
>> This gave an error in a 'worker' thread, to which I yielded to see a
>> backtrace.
>
> [snip]
>
>> This is the listener interaction:
>>> Error in process 1-aserve-worker(2): Unknown type specifier:
>>    NET.URI::ALPHA-CHAR
>>> While executing: CCL::%%TYPEP
>
> i have gotten this error before, unfortunetly i can't reliably
> reproduce it and from looking at the code i don't really understand
> why it happens. i'll need to investigate more.

All the URL you proposed as well as those were 127.0.0.1 is replacing 
localhost failed with the same error: so in my case it is reliable... 
sorry.

Sven




From mb at bese.it  Sun Dec  7 14:46:22 2003
From: mb at bese.it (Marco Baringer)
Date: Sun, 07 Dec 2003 15:46:22 +0100
Subject: [Bese-devel] Re: [Clump] UnCommon Web version 0.1 - "learning
	to crawl"
In-Reply-To: <1ED3DF0A-28B2-11D8-8620-00039344B8E8@beta9.be> (Sven Van
	Caekenberghe's message of "Sun, 7 Dec 2003 13:37:29 +0100")
References: <m2ad69rckt.fsf@bese.it>
	<08A8608F-289D-11D8-8620-00039344B8E8@beta9.be>
	<m2wu989ahf.fsf@bese.it>
	<1ED3DF0A-28B2-11D8-8620-00039344B8E8@beta9.be>
Message-ID: <m2k758y9c1.fsf@bese.it>

Sven Van Caekenberghe <sven at beta9.be> writes:

> All the URL you proposed as well as those were 127.0.0.1 is replacing
> localhost failed with the same error: so in my case it is
> reliable... sorry.

argh. what version of 0.14? what's in openmcl-init.lisp?

this error arises when aserve tries to parse a url. aserve uses meta
to parse url and defines the type net.url::aplha-char to be '(and character
(satisfies alpha-char-p)), so i don't know why meta doesn't see that
type when parsing.

-- 
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
     -Leonard Cohen




From mb at bese.it  Sun Dec  7 14:49:51 2003
From: mb at bese.it (Marco Baringer)
Date: Sun, 07 Dec 2003 15:49:51 +0100
Subject: [Bese-devel] arnesi matcher and :greedy-star
References: <86ptf07vyy.wl%asf@boinkor.net>
Message-ID: <m23cbwy968.fsf@bese.it>

Andreas Fuchs <asf at boinkor.net> writes:

> hi all,
>
> I was thinking about using the arnesi matcher in a project of
> mine. This would involve matching an arbitrary number of :ANYTHINGs in
> a list, so I thought :GREEDY-STAR would be the perfect match (no pun
> intended).

since :greedy-star was never actually needed for what i used the
mathcer for i never actually fisinhed implementing it, so some wark is
still required. since greedy-star works within a sequence it requires
a function which returns the "next" element of a sequence and a
functio which returns the "current" element of a sequence. these two
functions are different if we're ematching against a list or a
vector. it's not a lot of work, i'll see what i can do.

> So, how should the :GREEDY-STAR matcher be used? Is it the right thing
> to use at all? And why does the :ANYTHING matcher match all elements
> at the end of a list, but only one element in any other position?

because (:LIST a b) is just a convience for writing (:CONS a (:CONS b
(:EQL 'nil))).

-- 
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
     -Leonard Cohen




From mb at bese.it  Sun Dec  7 16:26:37 2003
From: mb at bese.it (Marco Baringer)
Date: Sun, 07 Dec 2003 17:26:37 +0100
Subject: [Bese-devel] some patches for sbcl and clisp
In-Reply-To: <871xrpuxlh.fsf@killr.ath.cx> (Matthew Kennedy's message of
	"Sun, 30 Nov 2003 19:37:46 -0600")
References: <8765h2dqch.fsf@killr.ath.cx>
	<mailman.252.1070210972.20290.bese-devel@common-lisp.net>
	<871xrpuxlh.fsf@killr.ath.cx>
Message-ID: <m2n0a4oapu.fsf@bese.it>

Matthew Kennedy <mbkennedy at austin.rr.com> writes:

> Sorry for the confusion: the flet problem was with clisp (not sbcl).
> Attached is the compilation log which shows the error.

sorry if it took me a while to get around to this. 

I tried with the lastest on clisp (2.31 on linux) and had no
problems. Did you ever figure out what was wrong?

-- 
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
     -Leonard Cohen




From mb at bese.it  Sun Dec  7 19:04:50 2003
From: mb at bese.it (Marco Baringer)
Date: Sun, 07 Dec 2003 20:04:50 +0100
Subject: [Bese-devel] RFC: FORMs (draft)
Message-ID: <m2u14c78kt.fsf@bese.it>


I think that in my life i have written (or some how created) about a
gazillion "data entry forms." For "data entry form" I mean an html
form whose goal is to allaw the manipulation (creation, deletion and
modification) of some kind of "object" in the application.

There are 3 main issues involved:

1) We need to allow complete control over what the form looks like (ie
   the mapping from object -> html). However, in the common case we
   will only want to speciy that a few of the many forms are different
   from all the rest, most of the forms are completly alike and should
   be automatically built, given the proper defaults.

2) We need to specify how to translate what data we get from the
   client (strings which can be maliciously manipulated) into objects
   the server can deal with.

3) We need to gracefully deal with objects which are linked to other
   objects. We also need to gracefully deal with sequences and
   indexed-arrays.

Assuming this is going to be integrated with UnCommon Web and will use
TAL/yaclml for generating the html here are my thoughts on the matter,
comments welcome:

We'll create a new class of components (not really components, but
obscenly similar) called FORM. A FORM will be an object representing a
(single) common lisp object which we want to user to be able to
monipulate via an html form.

Form objects can composed in a hierarchy (or container/contained
relationship). All form processing happens bottom up.

A form class is a sub class of:

(defclass web-form ()
  ((c-value :documentation "The client side representation for this
            object. either a string or another web-form object.")
   (s-value :documentation "The common lisp object for this form.")))

And will define methods on the following generic functions:

(defgeneric validate ((form web-form))
  (:documentation "Returns T if the user's values are \"good\", NIL
  otherwise. If it returns T it MUST also set the s-value slot to the
  corresponding common lisp object."))

(defgeneric render-on ((res response) (form web-form))
  (:documentation "Create the proper html input tag."))

When processing the user's input we will set all the c-values from
the request and then call validate bottom up:

1) if a web-form's c-value is a a web-form object then we call first
call validate on every slot in the c-value, then continue validating
this object.

2) if a web-form's c-value is text (or a list of strings) we can simply
validate the text.

This _should_ be enough to create generic "data-entry" forms, reuse
form processing logic in multiple places, and at the same time allow
fine grained control (and rendering) where it's needed. Of course,
there'll have to be a few "built-in" form classes for the simple input
tags (text, textarea, select/option, file, etc.) and for simple
collections of objects (list, indexed/ordered list, key indexed list,
etc.)

Is this really enough to cover all the cases?

-- 
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
     -Leonard Cohen




From mb at bese.it  Sun Dec  7 19:11:28 2003
From: mb at bese.it (Marco Baringer)
Date: Sun, 07 Dec 2003 20:11:28 +0100
Subject: [Bese-devel] RFC: FORMs (draft) - questions
In-Reply-To: <m2u14c78kt.fsf@bese.it> (Marco Baringer's message of "Sun, 07
	Dec 2003 20:04:50 +0100")
References: <m2u14c78kt.fsf@bese.it>
Message-ID: <m2isks789r.fsf@bese.it>


these always come to after posting a message....

1) do we need to explicity distinguish between create/modify/delete?
   what would this buy in terms of auto-generation of forms?

2) should validate really do both validation and conversion?

3) how do we want to map web-form objects to a tal enviroment? do we
   need a tal-enviroment generic function?

4) can we merge web-form and compenents? at the moment a real
   application would need to have three objects: 1) the actual
   applicaton object, 2) the component for the ui and 3) the web-form
   object. isn't this a lot?

-- 
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
     -Leonard Cohen




From mb at bese.it  Mon Dec  8 19:02:25 2003
From: mb at bese.it (Marco Baringer)
Date: Mon, 08 Dec 2003 20:02:25 +0100
Subject: [Bese-devel] random questions
Message-ID: <m24qwbrv3y.fsf@bese.it>


1) what's a good default action for:

  a) we get a request with a "bad" session id

  b) we get a request with an in-existent action-id 

  c) we get a request with an in-existent frame-id

  While we could just respond with some kind of error message i'd like
  to offer the user some pollible ways to react, but what? does this
  depend on whether it's a dev server or the production server?

2) since there are quite a few things which we want to handle
   differently in a dev enviroment than in a production enviroment do
   we want a global ucw:*debug-server* variable or a sub class of
   application? (i'm leaning towards the latter as it would be a good
   test of how well the application api is defined)

3) mind if i kill ucw-devel at common-lisp.net and just do everything on
   bese-devel at common-lisp.net?

-- 
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
     -Leonard Cohen




From sven at beta9.be  Mon Dec  8 21:09:33 2003
From: sven at beta9.be (Sven Van Caekenberghe)
Date: Mon, 8 Dec 2003 22:09:33 +0100
Subject: [Bese-devel] Re: [Clump] UnCommon Web version 0.1 - "learning to
	crawl"
In-Reply-To: <m2k758y9c1.fsf@bese.it>
References: <m2ad69rckt.fsf@bese.it>
	<08A8608F-289D-11D8-8620-00039344B8E8@beta9.be>
	<m2wu989ahf.fsf@bese.it>
	<1ED3DF0A-28B2-11D8-8620-00039344B8E8@beta9.be>
	<m2k758y9c1.fsf@bese.it>
Message-ID: <D269A1B6-29C2-11D8-AC67-00039344B8E8@beta9.be>

On 07 Dec 2003, at 15:46, Marco Baringer wrote:

> Sven Van Caekenberghe <sven at beta9.be> writes:
>
>> All the URL you proposed as well as those were 127.0.0.1 is replacing
>> localhost failed with the same error: so in my case it is
>> reliable... sorry.
>
> argh. what version of 0.14? what's in openmcl-init.lisp?

OpenMCL Version (Alpha: Darwin) 0.14-031108 and no init file

> this error arises when aserve tries to parse a url. aserve uses meta
> to parse url and defines the type net.url::aplha-char to be '(and 
> character
> (satisfies alpha-char-p)), so i don't know why meta doesn't see that
> type when parsing.

I know, it is weird. It is probably something strange/weird in openmcl, 
no ?

Is it possible to run ucw using openmcl 0.13.x ?

Sven




From mb at bese.it  Mon Dec  8 22:34:13 2003
From: mb at bese.it (Marco Baringer)
Date: Mon, 08 Dec 2003 23:34:13 +0100
Subject: [Bese-devel] Re: [Clump] UnCommon Web version 0.1 - "learning
	to crawl"
References: <m2ad69rckt.fsf@bese.it>
	<08A8608F-289D-11D8-8620-00039344B8E8@beta9.be>
	<m2wu989ahf.fsf@bese.it>
	<1ED3DF0A-28B2-11D8-8620-00039344B8E8@beta9.be>
	<m2k758y9c1.fsf@bese.it>
	<D269A1B6-29C2-11D8-AC67-00039344B8E8@beta9.be>
Message-ID: <m2fzfv3pne.fsf@bese.it>

Sven Van Caekenberghe <sven at beta9.be> writes:

> I know, it is weird. It is probably something strange/weird in
> openmcl, no ?

i'll see what openmcl-devel thinks.

> Is it possible to run ucw using openmcl 0.13.x ?

more or less.

I just tried with openmcl 0.13.6 and the mod-lisp server (the
portableaserve doesn't work with 0.13). I had to tell asdf to skip the
loading of ucw/src/core/yaclml and arnesi/src/mop about 18 million
times, but eventually it loaded all the systems.

At this point the following things worked:

/ucw/examples/counter
/ucw/examples/hello-world

/ucw/admin/ : only the front page works since all the inspectors (and
therefore the repl as well) require a mop.

-- 
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
     -Leonard Cohen




From mb at bese.it  Mon Dec  8 22:50:31 2003
From: mb at bese.it (Marco Baringer)
Date: Mon, 08 Dec 2003 23:50:31 +0100
Subject: [Bese-devel] Re: [Clump] UnCommon Web version 0.1 - "learning
	to crawl"
In-Reply-To: <m2fzfv3pne.fsf@bese.it> (Marco Baringer's message of "Mon, 08
	Dec 2003 23:34:13 +0100")
References: <m2ad69rckt.fsf@bese.it>
	<08A8608F-289D-11D8-8620-00039344B8E8@beta9.be>
	<m2wu989ahf.fsf@bese.it>
	<1ED3DF0A-28B2-11D8-8620-00039344B8E8@beta9.be>
	<m2k758y9c1.fsf@bese.it>
	<D269A1B6-29C2-11D8-AC67-00039344B8E8@beta9.be>
	<m2fzfv3pne.fsf@bese.it>
Message-ID: <m2y8tmudoo.fsf@bese.it>

Marco Baringer <mb at bese.it> writes:

> /ucw/admin/ : only the front page works since all the inspectors (and
> therefore the repl as well) require a mop.

well, to be precise the repl works, but you can't inspect the
returned value, which is the intire point of having a repl built into
a server.

-- 
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
     -Leonard Cohen




From sven at beta9.be  Mon Dec 15 11:57:02 2003
From: sven at beta9.be (Sven Van Caekenberghe)
Date: Mon, 15 Dec 2003 12:57:02 +0100
Subject: [Bese-devel] Re: [Clump] UnCommon Web version 0.1 - "learning to
	crawl"
In-Reply-To: <m2fzfv3pne.fsf@bese.it>
References: <m2ad69rckt.fsf@bese.it>
	<08A8608F-289D-11D8-8620-00039344B8E8@beta9.be>
	<m2wu989ahf.fsf@bese.it>
	<1ED3DF0A-28B2-11D8-8620-00039344B8E8@beta9.be>
	<m2k758y9c1.fsf@bese.it>
	<D269A1B6-29C2-11D8-AC67-00039344B8E8@beta9.be>
	<m2fzfv3pne.fsf@bese.it>
Message-ID: <CB8E2338-2EF5-11D8-B477-00039344B8E8@beta9.be>

On 08 Dec 2003, at 23:34, Marco Baringer wrote:

> Sven Van Caekenberghe <sven at beta9.be> writes:
>
>> I know, it is weird. It is probably something strange/weird in
>> openmcl, no ?
>
> i'll see what openmcl-devel thinks.

Marco,

I think I found the problem: there was something wrong with your 
version of paserve, more specifically uri.lisp - the function 
%meta-parse-uri. In the version you included, there was a problem 
compiling this code. Something like (net.uri:parse-uri 
"http://www.apple.com/store") did nothing (and didn't give an error). I 
now load the .lisp file manually and everything works. The very latest 
CVS version of paserve is OK too, though.

We still have the same problem in LispWorks for Mac (PE) - even with 
the latest version of paserve.

PS: Did you try running ucw in LWM ?

Sven

--
Sven Van Caekenberghe - http://homepage.mac.com/svc
Beta Nine - software engineering - http://www.beta9.be

"Lisp isn't a language, it's a building material." - Alan Kay




From mb at bese.it  Tue Dec 16 12:59:55 2003
From: mb at bese.it (Marco Baringer)
Date: Tue, 16 Dec 2003 13:59:55 +0100
Subject: [Bese-devel] lispworks personal edition
Message-ID: <m2llpc6hpw.fsf@bese.it>


Having more or less figured out the problem with net.uri:parse-uri,
and having figured out the proper MOP symbols for lispworks i think
ucw should, at least, load in lispworks. However the personal edition
does not have enough heap space to load pxmlutils, anybody with a real
copy of lispworks willing to give it a try?

-- 
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
     -Leonard Cohen