From luca at pca.it  Mon May  1 11:26:08 2006
From: luca at pca.it (Luca Capello)
Date: Mon, 01 May 2006 13:26:08 +0200
Subject: [Bese-devel] Re: Load a custom ucwctl.conf
References: <031901c66233$fa96d180$d80a0a0a@acceleration.net>
	<87irp7c3ht.fsf@gismo.pca.it>
Message-ID: <87vesqyoj3.fsf@gismo.pca.it>

Hello!

On Mon, 17 Apr 2006 23:10:38 +0200, Luca Capello wrote:
> On Mon, 17 Apr 2006 17:31:20 +0200, Nathan Bird wrote:
>>> Nathan, I think this was what you asked for, right?  Do you (or
>>> other) want to test the patch before inclusion?
>>
>> I'll give it a whirl, where can I get it? None of the 16(!) patches
>> I pulled this morning jumped out at me as doing this.
>
> Included a preliminary patch, you need to apply it with
[...]
> As soon as it will be confirmed to work as expected, I'll commit to
> ucw_dev.

As no one reported errors with the preliminary patch, I just pushed it
to ucw_dev.  Please let me know if breaks something.

Ties, can you update the necessary docs as well (except the manual
page), please?

Thx, bye,
Gismo / Luca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060501/d12b2293/attachment.sig>

From mb at bese.it  Mon May  1 13:22:08 2006
From: mb at bese.it (Marco Baringer)
Date: Mon, 01 May 2006 15:22:08 +0200
Subject: [Bese-devel] ucw boxset
Message-ID: <m2bquh283j.fsf@bese.it>


i've created a simple script which downloads all of ucw's dependencies
and creates a easy to use startup script:

http://common-lisp.net/project/ucw/ucw-boxset.tar.gz [3.6MB]

the download contains all the code neccessary to run ucw (i went so
far as even include asdf). loading the examples requires unpacking
that tarball and loading the included start.lisp script.

comments?
-- 
-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 chriss at muon.de  Mon May  1 13:28:28 2006
From: chriss at muon.de (Christian Haselbach)
Date: Mon, 1 May 2006 15:28:28 +0200
Subject: [Bese-devel] UCW submit action issues
Message-ID: <20060501132828.GA9899@tngtech.com>

Hello,

I have got some issues with form and submit action. I want to perform
a certain action when a submit button is clicked.

(defaction call-viewer ((bac b-action-component) name)
  (incf (counter bac))
  (call 'b-viewer :name name))

(defmethod render ((bac b-action-component))
  (<:h1 (<:as-html "Choose your action #" (counter bac)))
  (let ((name "n/a"))
    (<ucw:form :action (call-viewer bac name)
	       (<ucw:submit :value "one" :accessor name)
	       (<ucw:submit :value "two" :accessor name))))

This works just fine, but I cannot see a way to assign the action
directly:

(defmethod render ((bac b-action-component))
  (<:h1 (<:as-html "Choose your action #" (counter bac)))
  (<:form (<ucw:submit :value "one" :action (call-viewer bac "one"))
	  (<ucw:submit :value "two" :action (call-viewer bac "two"))))

This does nothing (except bringing you back to the start).

Taking a look a the dynamic forms example, I saw it uses the simple-form
component. Looking at the produced html one can see that the "add"
button does not have a name attribute. So the form does not know which
button has been pressed when javascript is turned off. Indeed, the
example does not work without javascript.

So, is there a way to associate an action with a button without relying
on javascript? Using value for manual association (like the code above
sort of does) becomes a nightmare with I18N.

Thanks.

Regards,
Christian


From mb at bese.it  Mon May  1 13:38:04 2006
From: mb at bese.it (Marco Baringer)
Date: Mon, 01 May 2006 15:38:04 +0200
Subject: [Bese-devel] Re: ucw boxset
References: <m2bquh283j.fsf@bese.it>
Message-ID: <m24q0927cz.fsf@bese.it>

Marco Baringer <mb at bese.it> writes:

> comments?

um, i totaly forgot the real reason i announced that:

i would like it if people could download it and make sure it does
actually run. just see if this works as expected:

wget http://common-lisp.net/project/ucw/ucw-boxset.tar.gz
tar -zxf ucw-boxset.tar.gz
cd ucw-boxset
YOURLISPHERE --load start.lisp

(the only defect atm is that start.lisp assumes your pwd is the ucw-boxset directory)

-- 
-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 May  1 13:55:45 2006
From: mb at bese.it (Marco Baringer)
Date: Mon, 01 May 2006 15:55:45 +0200
Subject: [Bese-devel] Re: tabbed-pane makeover
References: <d7ce4ebf0604301658t6b0cc94ck47238452a2fa5457@mail.gmail.com>
Message-ID: <m2u089zw66.fsf@bese.it>

"Ties Stuij" <cjstuij at gmail.com> writes:

> hi all,
> I applied a patch to the ucw_public repository that brings the
> tabbed-pane into the century of the fruit-bat so to speak. e.g. it now
> wraps panes in divs in stead of a table for more design flexibility.
> And incidentally it is not dependent on a tal file anymore. See the
> example admin section, which has gotten a face-lift. If you dislike it
> much, let me know.

applied, thanks. if you feel like making the examples and admin app
prettier please do so.

-- 
-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 mbaringer at common-lisp.net  Tue May  2 04:30:04 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Tue,  2 May 2006 00:30:04 -0400 (EDT)
Subject: [Bese-devel] New patches to ucw_dev:  1-May-2006
Message-ID: <20060502043004.1B2FB61026@common-lisp.net>


Mon May  1 11:42:50 EDT 2006  Marco Baringer <mb at bese.it>
  * Added send-redirect function.
  
  send-redirect does what redirect-component's render method did but
  it's usable from a simple-dispatcher (or anywhere else we don't have
  ucw's component context machinery).

    M ./src/components/redirect.lisp -3 +11
    M ./src/packages.lisp -1 +1

Mon May  1 09:53:14 EDT 2006  Marco Baringer <mb at bese.it>
  * Use dolist*, not dolist, in tabbed-pane's render method.

    M ./src/components/tabbed-pane.lisp -1 +1

Mon May  1 09:50:00 EDT 2006  Marco Baringer <mb at bese.it>
  * Using (when (whatever) T) is weird, use (whatever) instead

    M ./src/components/form.lisp -3 +2

Mon May  1 09:48:49 EDT 2006  Marco Baringer <mb at bese.it>
  * Minor indentation/whitespace fixups in src/components/form.lisp

    M ./src/components/form.lisp -7 +11

Sun Apr 30 20:17:56 EDT 2006  cjstuij at gmail.com
  * make-with-dummy-request-nicer

    M ./src/rerl/standard-request-context.lisp -2 +1

Sun Apr 30 19:39:20 EDT 2006  cjstuij at gmail.com
  * tabbed-pane-makeover - tabbed panes are now wrapped in divs in stead of a table, for more design flexibility. Is no longer tied to a tal file.

    M ./src/admin/admin.lisp -6 +4
    M ./src/components/tabbed-pane.lisp -18 +14
    M ./wwwroot/stylesheet.css -17 +42

Fri Apr 28 12:58:29 EDT 2006  Nathan Bird <nathan at acceleration.net>
  * Removing integer-range-validator, use number-range-validator instead.

    M ./examples/forms.lisp -10
    M ./src/components/form.lisp -5 +3

Fri Apr 28 12:49:49 EDT 2006  Nathan Bird <nathan at acceleration.net>
  * the value of a number-field should be nil, not 0, if nothing was entered.

    M ./src/components/form.lisp -1 +1

Mon May  1 07:00:31 EDT 2006  Luca Capello <luca at pca.it>
  * bin/ucwctl: allow a custom ucwctl.conf via -u|--ucwctl-file
  
  This adds the possibility to specify a different ucwctl.conf file
  instead of the default /etc/ucw/ucwctl.conf.  Moreover, by default
  ucwctl now reads ~/.ucw/ucwctl.conf it it exists, overriding the
  values in the general /etc/ucw/ucwctl.conf, and the same happens if
  the ucwctl.conf is specified via the command line option.  All command
  line options override the values present in any ucwctl.conf files.
  The order is the following:
  
    1) /etc/ucw/ucwctl.conf (if it exists)
    2) ~/.ucw/ucwctl.conf (if it exists)
    3) -u|--ucwctl-file (if specified, exit if it cannot be read)
    4) command line options
  
  A deeper discussion is available at:
  
    http://common-lisp.net/pipermail/bese-devel/2006-April/001932.html
    http://common-lisp.net/pipermail/bese-devel/2006-April/001961.html

    M ./bin/ucwctl -58 +88
    M ./bin/ucwctl.1 -1 +11


An updated tarball of ucw_dev's source can be downloaded here:
http://common-lisp.net/project/ucw/tarballs/ucw_dev-20060501.tar.gz

Darcsweb URL:
http://uncommon-web.com/darcsweb/darcsweb.cgi?r=ucw_dev;a=summary


From chr at nybo.no  Tue May  2 08:01:20 2006
From: chr at nybo.no (=?ISO-8859-1?Q?Christian_Nyb=F8?=)
Date: Tue, 2 May 2006 10:01:20 +0200
Subject: [Bese-devel] Re: ucw boxset
In-Reply-To: <uil4q086ex4.fsf@false.linpro.no>
References: <uil4q086ex4.fsf@false.linpro.no>
Message-ID: <BC8DDCE8-0A61-4189-BAD5-F118FB1654C0@nybo.no>

Marco Baringer <mb at bese.it> writes:

> i would like it if people could download it and make sure it does
> actually run. just see if this works as expected:
>
> wget http://common-lisp.net/project/ucw/ucw-boxset.tar.gz
> tar -zxf ucw-boxset.tar.gz
> cd ucw-boxset
> YOURLISPHERE --load start.lisp
>
> (the only defect atm is that start.lisp assumes your pwd is the ucw- 
> boxset directory)

Is there anything in the archive?  I only see null-bytes.
-- 
chr


From vagif at cox.net  Tue May  2 06:30:58 2006
From: vagif at cox.net (Vagif Hagverdiyev)
Date: Mon, 1 May 2006 23:30:58 -0700
Subject: [Bese-devel] Re: ucw boxset
In-Reply-To: <m24q0927cz.fsf@bese.it>
Message-ID: <000c01c66db1$f95516e0$0302a8c0@p4>

Does not work on windows lispworks.

1. Windows does not have symlinks. So asdf cannot find files.
I solved this problem following way:
1. delete subfolder systems
2. In start.lisp remove form with systems folder in asdf-registry and
replace it with following form:

(defvar *lib-dirs* "c:/lisp/ucw-boxset/")

(dolist (dir-candidate (directory (concatenate 'string *lib-dirs* "*/")))
	  (let ((asd-candidate (merge-pathnames "*.asd" dir-candidate)))
	    (when (directory asd-candidate)
	      (push dir-candidate asdf:*central-registry*))))


2. When loading lispworks.lisp gives error "package comm. Not found".
Solved by providing (require "comm") before loading lispworks.lisp

3. When starting ucw server with httpd gives error: trivial-sockets bla bla
not supported.
Do not know what that means, tried to switch to aserve, got another error,
gave up.


This is great effort, and in right direction, that you decided to assemble a
single download-install package.

But I think it lacks certain thing essential for success of ANY web
framework.
In my opinion it is: SPECIFICLY TARGETING WINDOWS!!

When you will be able to create a download-install package that will
smoothly run on windows, then you will see start of wide adoption of ucw.



-----Original Message-----
From: bese-devel-bounces at common-lisp.net
[mailto:bese-devel-bounces at common-lisp.net] On Behalf Of Marco Baringer
Sent: Monday, May 01, 2006 6:38 AM
To: bese-devel at common-lisp.net
Subject: [Bese-devel] Re: ucw boxset

Marco Baringer <mb at bese.it> writes:

> comments?

um, i totaly forgot the real reason i announced that:

i would like it if people could download it and make sure it does
actually run. just see if this works as expected:

wget http://common-lisp.net/project/ucw/ucw-boxset.tar.gz
tar -zxf ucw-boxset.tar.gz
cd ucw-boxset
YOURLISPHERE --load start.lisp

(the only defect atm is that start.lisp assumes your pwd is the ucw-boxset
directory)

-- 
-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 mb at bese.it  Tue May  2 08:47:11 2006
From: mb at bese.it (Marco Baringer)
Date: Tue, 02 May 2006 10:47:11 +0200
Subject: [Bese-devel] Re: ucw boxset
References: <uil4q086ex4.fsf@false.linpro.no>
	<BC8DDCE8-0A61-4189-BAD5-F118FB1654C0@nybo.no>
Message-ID: <m2r73c7r00.fsf@bese.it>

Christian Nyb? <chr at nybo.no> writes:

> Is there anything in the archive?  I only see null-bytes.

my bad. i created a cronjob to update the archive daily and the
crontob was borken. it should be fixed now.

-- 
-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 attila.lendvai at gmail.com  Tue May  2 09:10:37 2006
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Tue, 2 May 2006 11:10:37 +0200
Subject: [Bese-devel] Re: ucw boxset
In-Reply-To: <000c01c66db1$f95516e0$0302a8c0@p4>
References: <m24q0927cz.fsf@bese.it> <000c01c66db1$f95516e0$0302a8c0@p4>
Message-ID: <b54b34af0605020210w10843023ifb26ca46ef0519f0@mail.gmail.com>

> 1. Windows does not have symlinks. So asdf cannot find files.

windows (ntfs) does have symlinks, but they only work for dirs though.
unfortunately the _only_ program i know that can create them is FAR, a
norton clone. but luckily once they are created they are transparent
for programs that don't care about them. files can only be hardlinked.

- attila

(alias 101 on irc &no 'its not lisp code :)

From attila.lendvai at gmail.com  Tue May  2 10:48:07 2006
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Tue, 2 May 2006 12:48:07 +0200
Subject: [Bese-devel] two patches for arnesi
Message-ID: <b54b34af0605020348m194e9a3ch3eac989b72c19ec4@mail.gmail.com>

hi!

  * Skip nil's in strcat
  * Fix the return value of compose for fn > 4

- attila

(alias 101 on irc &no 'its not lisp code :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: arnesi-compose.patch
Type: text/x-patch
Size: 29919 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060502/9b1bf530/attachment.bin>

From chr at nybo.no  Tue May  2 11:16:39 2006
From: chr at nybo.no (=?ISO-8859-1?Q?Christian_Nyb=F8?=)
Date: Tue, 2 May 2006 13:16:39 +0200
Subject: [Bese-devel] ucw boxset
In-Reply-To: <m2r73c7r00.fsf@bese.it>
References: <uil4q086ex4.fsf@false.linpro.no>
	<BC8DDCE8-0A61-4189-BAD5-F118FB1654C0@nybo.no>
	<m2r73c7r00.fsf@bese.it>
Message-ID: <D259A471-E770-4EAE-8B4F-D966FCC8E9C2@nybo.no>


On May 2, 2006, at 10:47, Marco Baringer wrote:

> Christian Nyb? <chr at nybo.no> writes:
>
>> Is there anything in the archive?  I only see null-bytes.
>
> my bad. i created a cronjob to update the archive daily and the
> crontob was borken. it should be fixed now.

Thanks.  Loads nicely with slime.

What is the recommended way of starting it?
Should I start slime from within emacs and load start.lisp from there:

;; In emacs:
M-x slime RET
... wait a while ...
,cd RET ~/lisp/boxset/ucw-boxset RET
;; in the slime buffer:
CL-USER> (load "start")

or should I start slime with a prefix argument to have it
prompt me for the command like this:

;; In emacs:
C-u M-x slime RET
/Applications/openmcl/ccl/scripts/openmcl -l /Users/chr/lisp/boxset/ 
ucw-boxset/start.lisp RET

Either way, I don't see the message from the last form in start.lisp:
(write-line "UCW Started. Point your browser to http://127.0.0.1:8080/")

-- 
chr



From mb at bese.it  Tue May  2 11:38:25 2006
From: mb at bese.it (Marco Baringer)
Date: Tue, 02 May 2006 13:38:25 +0200
Subject: [Bese-devel] Re: ucw boxset
References: <000c01c66db1$f95516e0$0302a8c0@p4>
Message-ID: <m2aca064i6.fsf@bese.it>

"Vagif Hagverdiyev" <vagif at cox.net> writes:

> Does not work on windows lispworks.
>
> 1. Windows does not have symlinks. So asdf cannot find files.
> I solved this problem following way:
> 1. delete subfolder systems

we know, when we generating the boxset, exactly which .asd files we
need. i've changed the build script so that a lisp file is created
which explicitly loads all these .asd files. asdf:*central-registry*
is still set to ucw-boxset/systems, but i don't think it matters
anymore.

> 2. When loading lispworks.lisp gives error "package comm. Not found".
> Solved by providing (require "comm") before loading lispworks.lisp

is this trivial-sockets' lispworks.lisp? i tried with the personal
edition on MacOS X and not only was it not neccessary but (require
:comm) failed with an error about comm not existing.

> 3. When starting ucw server with httpd gives error: trivial-sockets bla bla
> not supported.
> Do not know what that means, tried to switch to aserve, got another error,
> gave up.

what lisp are you testing this on? i had to make a few changes to
trivial sockets (after downloading the boxset apply the patches i've
attached to the trivial-sockets directory).

> This is great effort, and in right direction, that you decided to assemble a
> single download-install package.
>
> But I think it lacks certain thing essential for success of ANY web
> framework.
> In my opinion it is: SPECIFICLY TARGETING WINDOWS!!
> When you will be able to create a download-install package that will
> smoothly run on windows, then you will see start of wide adoption of ucw.

cool, go for it! the scripts used to generate the boxset are in a
darcs repo at:

http://common-lisp.net/project/ucw/repos/ucw-boxset

atm they assume openmcl and a unix system (it's just a bunch of shell
scripts) but any patches wolud be welcome.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: CHANGES
Type: application/octet-stream
Size: 1364 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060502/a07f8f4d/attachment.obj>
-------------- next part --------------

-- 
-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 door at lcpi.ru  Tue May  2 11:39:56 2006
From: door at lcpi.ru (Alexey Antipov)
Date: Tue, 2 May 2006 15:39:56 +0400
Subject: [Bese-devel] UCW submit action issues
In-Reply-To: <20060501132828.GA9899@tngtech.com>
References: <20060501132828.GA9899@tngtech.com>
Message-ID: <20060502113956.GA24863@rabbit.loc>

On Mon, May 01, 2006 at 03:28:28PM +0200, Christian Haselbach wrote:
> I have got some issues with form and submit action. I want to perform
> a certain action when a submit button is clicked.

Please check that dojo.js used, i.e. you have
something like <script type="text/javascript" src="dojo/dojo.js"?>
and its really loaded.


From mb at bese.it  Tue May  2 11:40:44 2006
From: mb at bese.it (Marco Baringer)
Date: Tue, 02 May 2006 13:40:44 +0200
Subject: [Bese-devel] Re: ucw boxset
References: <uil4q086ex4.fsf@false.linpro.no>
	<BC8DDCE8-0A61-4189-BAD5-F118FB1654C0@nybo.no>
	<m2r73c7r00.fsf@bese.it>
	<D259A471-E770-4EAE-8B4F-D966FCC8E9C2@nybo.no>
Message-ID: <m24q0864eb.fsf@bese.it>

Christian Nyb? <chr at nybo.no> writes:

> What is the recommended way of starting it?
> Should I start slime from within emacs and load start.lisp from there:

start.lisp should, on a multi-threaded lisp, create a swank-server
bound to 127.0.0.1:8080. i test under the assumpiton that ucw is
started from a terminal and then slime-connect'd from emacs.

> Either way, I don't see the message from the last form in start.lisp:
> (write-line "UCW Started. Point your browser to http://127.0.0.1:8080/")

there are only two things i can think of:

1) your on a single-threaded lisp and hence ucw:create-server blocks

2) the output is going to some other stream.

-- 
-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 chr at nybo.no  Tue May  2 12:03:25 2006
From: chr at nybo.no (=?ISO-8859-1?Q?Christian_Nyb=F8?=)
Date: Tue, 2 May 2006 14:03:25 +0200
Subject: [Bese-devel] ucw boxset
In-Reply-To: <m24q0864eb.fsf@bese.it>
References: <uil4q086ex4.fsf@false.linpro.no>
	<BC8DDCE8-0A61-4189-BAD5-F118FB1654C0@nybo.no>
	<m2r73c7r00.fsf@bese.it>
	<D259A471-E770-4EAE-8B4F-D966FCC8E9C2@nybo.no>
	<m24q0864eb.fsf@bese.it>
Message-ID: <C26C40E2-8F65-4EE9-A65F-3857CF4CB9BF@nybo.no>


On May 2, 2006, at 13:40, Marco Baringer wrote:

> Christian Nyb? <chr at nybo.no> writes:
>
>> What is the recommended way of starting it?
>> Should I start slime from within emacs and load start.lisp from  
>> there:
>
> start.lisp should, on a multi-threaded lisp, create a swank-server
> bound to 127.0.0.1:8080.

I think you mean that the swank-server is bound to 127.0.0.1:4005.

> i test under the assumpiton that ucw is
> started from a terminal and then slime-connect'd from emacs.

I see.  I do
/Applications/openmcl/ccl/scripts/openmcl -l /Users/chr/lisp/boxset/ 
ucw-boxset/start.lisp
in the terminal, and then I do
M-X slime-connect from emacs, answering host: localhost and port: 4005.

Works great!
-- 
chr



From cjstuij at gmail.com  Tue May  2 12:13:32 2006
From: cjstuij at gmail.com (Ties Stuij)
Date: Tue, 2 May 2006 14:13:32 +0200
Subject: [Bese-devel] ucw boxset
In-Reply-To: <D259A471-E770-4EAE-8B4F-D966FCC8E9C2@nybo.no>
References: <uil4q086ex4.fsf@false.linpro.no>
	<BC8DDCE8-0A61-4189-BAD5-F118FB1654C0@nybo.no>
	<m2r73c7r00.fsf@bese.it>
	<D259A471-E770-4EAE-8B4F-D966FCC8E9C2@nybo.no>
Message-ID: <d7ce4ebf0605020513h2d68d16ch6725fd572837047b@mail.gmail.com>

on sbcl i need to load bsd-sockets to not let trivial-sockets whine
for a dependency. eg.:

#+sbcl
(require 'sb-bsd-sockets)

at the beginning of the file.

With cmucl on linux i've got a problem i also have with other files:
if i load the file from the commandline or inside lisp, i have to load
it twice. So when i load start.lisp from the command-line, it throws
me to the promp without having loaded anything significant. When i
subsequently (load "start.lisp") from the prompt it loads fine.

does that sound familiar to anyone?

When i load the start.lisp file on cmucl on freebsd i've got the same
problem, with the added problem that asdf get's in a loop when it
wants to register the asd files. It keeps on regestering the same
files over and over, untill i kill it.

ah well.

greets,
ties


From mb at bese.it  Tue May  2 16:19:39 2006
From: mb at bese.it (Marco Baringer)
Date: Tue, 02 May 2006 18:19:39 +0200
Subject: [Bese-devel] Re: UCW submit action issues
References: <20060501132828.GA9899@tngtech.com>
Message-ID: <m2u0881js4.fsf@bese.it>

Christian Haselbach <chriss at muon.de> writes:

> (defmethod render ((bac b-action-component))
>   (<:h1 (<:as-html "Choose your action #" (counter bac)))
>   (<:form (<ucw:submit :value "one" :action (call-viewer bac "one"))
> 	  (<ucw:submit :value "two" :action (call-viewer bac "two"))))
>
> This does nothing (except bringing you back to the start).

if you change that to <ucw:form (not <:form) does it work?

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



From mb at bese.it  Tue May  2 16:21:06 2006
From: mb at bese.it (Marco Baringer)
Date: Tue, 02 May 2006 18:21:06 +0200
Subject: [Bese-devel] Re: two patches for arnesi
References: <b54b34af0605020348m194e9a3ch3eac989b72c19ec4@mail.gmail.com>
Message-ID: <m2psiw1jpp.fsf@bese.it>

"Attila Lendvai" <attila.lendvai at gmail.com> writes:

> hi!
>
>  * Skip nil's in strcat
>  * Fix the return value of compose for fn > 4

applied. thanks.

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



From waldo at trianet.net  Tue May  2 17:33:26 2006
From: waldo at trianet.net (Waldo Rubinstein)
Date: Tue, 2 May 2006 13:33:26 -0400
Subject: [Bese-devel] SBCL on Mac OS X
Message-ID: <915237C4-369D-46C7-BDF6-6FBA9D8C4772@trianet.net>

Hi guys,

Let me apologize if this is not the most appropriate place to post  
this, but, ultimately, I'm trying to develop UCW apps :)


I have been doing some minor development with UCW on Mac OS using  
OpenMCL. However, because my deployment environment will be a Linux  
box, I plan on using SBCL for production. The problem I have is that  
some of the libraries I'm using behave differently in OpenMCL and  
SBCL (most likely bugs, which I have been reporting and are being  
fixed). Because I'm not a LISP "guru" yet, I don't have the man power  
nor sufficient knowledge to fix these problems.

Therefore, I wanted to develop in the same environment my application  
will be deployed. That way, I can concentrate on testing under one  
environment and reduce the amount of "guessing" which environment is  
at fault, if there is a fault from the environment at all. The  
problem, as we all know, is that SBCL does not seem to run in multi- 
threaded mode under Mac OS X.

I could follow Marco's example on the video by connecting SLIME to a  
remote machine, but because most of the work I do is on a laptop and  
I'm mobile 75% of the time, I prefer to be able to work locally.

So, onto the question: how do you guys recommend working with UCW in  
SBCL under Mac OS X? I searched the archives because I remember  
asking a similar question in the past and I believe the most  
appropriate answer was that whenever a bug popped up and I needed a  
debugger, I could suspend the UCW app, correct what needed to be  
corrected, and the resume the app. Well, if this is indeed the most  
appropriate answer, how do you do that? :)

Thanks,
Waldo


From waldo at trianet.net  Tue May  2 17:57:33 2006
From: waldo at trianet.net (Waldo Rubinstein)
Date: Tue, 2 May 2006 13:57:33 -0400
Subject: [Bese-devel] ucw boxset
In-Reply-To: <m2bquh283j.fsf@bese.it>
References: <m2bquh283j.fsf@bese.it>
Message-ID: <88F18DD4-28CA-49B0-B58D-C38457B26AC7@trianet.net>

Marco,

I just downloaded your boxset on a fresh SBCL install in Mac OS X.  
Here is the output of the initial sbcl --load start.lisp command:

This is SBCL 0.9.12, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
; in: LAMBDA NIL
;     (ASDF::FORMAT-ARGUMENTS ASDF::C)
;
; caught STYLE-WARNING:
;   undefined function: FORMAT-ARGUMENTS

;     (ASDF::FORMAT-CONTROL ASDF::C)
;
; caught STYLE-WARNING:
;   undefined function: FORMAT-CONTROL

;
; caught STYLE-WARNING:
;   These functions are undefined:
;     FORMAT-ARGUMENTS FORMAT-CONTROL
;
; compilation unit finished
;   caught 3 STYLE-WARNING conditions

; in: LAMBDA NIL
;     (ASDF:ERROR-COMPONENT ASDF::C)
;
; caught STYLE-WARNING:
;   undefined function: ERROR-COMPONENT

;     (ASDF:ERROR-OPERATION ASDF::C)
;
; caught STYLE-WARNING:
;   undefined function: ERROR-OPERATION

;
; caught STYLE-WARNING:
;   These functions are undefined:
;     ERROR-COMPONENT ERROR-OPERATION
;
; compilation unit finished
;   caught 3 STYLE-WARNING conditions

; in: LAMBDA NIL
;     (ASDF::COMPONENT-VISITED-P ASDF::O ASDF::C)
;
; caught STYLE-WARNING:
;   undefined function: COMPONENT-VISITED-P

;
; caught STYLE-WARNING:
;   This function is undefined:
;     COMPONENT-VISITED-P
;
; compilation unit finished
;   caught 2 STYLE-WARNING conditions

; in: LAMBDA NIL
;     (ASDF::CHECK-COMPONENT-INPUT TYPE
;                                ASDF::NAME
;                                ASDF::WEAKLY-DEPENDS-ON
;                                ASDF::DEPENDS-ON
;                                ASDF::COMPONENTS
;                                ASDF::IN-ORDER-TO)
;
; caught STYLE-WARNING:
;   undefined function: CHECK-COMPONENT-INPUT

;
; caught STYLE-WARNING:
;   This function is undefined:
;     CHECK-COMPONENT-INPUT
;
; compilation unit finished
;   caught 2 STYLE-WARNING conditions

; in: LAMBDA NIL
;     (ASDF::SYSDEF-ERROR-COMPONENT ":depends-on must be a list."
;                                 TYPE
;                                 ASDF::NAME
;                                 ASDF::DEPENDS-ON)
;
; caught STYLE-WARNING:
;   undefined function: SYSDEF-ERROR-COMPONENT

;
; caught STYLE-WARNING:
;   This function is undefined:
;     SYSDEF-ERROR-COMPONENT
;
; compilation unit finished
;   caught 2 STYLE-WARNING conditions

debugger invoked on a SIMPLE-ERROR:
   Error during processing of --eval option (LOAD #P"start.lisp"):

   The function ASDF::MODULE-PROVIDE-ASDF is undefined.

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
   0: [CONTINUE] Ignore and continue with next --eval option.
   1: [ABORT   ] Skip rest of --eval options.
   2:            Skip to toplevel READ/EVAL/PRINT loop.
   3: [QUIT    ] Quit SBCL (calling #'QUIT, killing the process).

((LAMBDA (SB-IMPL::E)) #<UNDEFINED-FUNCTION MODULE-PROVIDE-ASDF  
{119F86E1}>)
0]

However, after adding:

(require 'asdf)

to the top of start.lisp, everything seems to be working. Demos seem  
to be working as well.

Hope this helps.
Waldo

On May 1, 2006, at 9:22 AM, Marco Baringer wrote:

>
> i've created a simple script which downloads all of ucw's dependencies
> and creates a easy to use startup script:
>
> http://common-lisp.net/project/ucw/ucw-boxset.tar.gz [3.6MB]
>
> the download contains all the code neccessary to run ucw (i went so
> far as even include asdf). loading the examples requires unpacking
> that tarball and loading the included start.lisp script.
>
> comments?
> -- 
> -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 mprice at atl.lmco.com  Tue May  2 17:35:15 2006
From: mprice at atl.lmco.com (Michael Price)
Date: Tue, 2 May 2006 13:35:15 -0400
Subject: [Bese-devel] qbook and ignoring code
Message-ID: <17495.38995.160102.394947@brownsmill.atl.lmco.com>

Quick question,

If my lisp source has something like the following:

  #+some-crazy-thing-not-in-my-features
  (ignore this form)

Then how do I get qbook to ignore that? One practical use of a construct
like that would be #+5am and test code.

If qbook can't ignore things like that yet then would someone be kind
enough to point out where in qbook source I should start looking if I
wanted to add that feature?

Thanks.

Michael


From vagif at cox.net  Tue May  2 16:15:27 2006
From: vagif at cox.net (Vagif Hagverdiyev)
Date: Tue, 2 May 2006 09:15:27 -0700
Subject: [Bese-devel] Re: ucw boxset
In-Reply-To: <m2aca064i6.fsf@bese.it>
Message-ID: <001701c66e03$a02b0910$0302a8c0@p4>


I'm working on lispworks on windows.

Try (require "comm") instead of (require :comm)

Unfortunately I have gazillion of projects on me. I try very hard to snatch
every minute of my "free" time to learn ucw AND LISP (yes I'm newbee in lisp
too). But it is terribly not enough.
I'm sorry.

If you find someone who is working on windows, knows lisp, ucw and has time
to create an installable package, that would be great.
I've seen a couple of tutorials on ucw. Unfortunately looks like those guys
are linux/macos guys too.

So I guess I'll have to wait on that.

-----Original Message-----
From: Marco Baringer [mailto:mb at bese.it] 
Sent: Tuesday, May 02, 2006 4:38 AM
To: Vagif Hagverdiyev
Cc: bese-devel at common-lisp.net
Subject: Re: [Bese-devel] Re: ucw boxset

"Vagif Hagverdiyev" <vagif at cox.net> writes:

> Does not work on windows lispworks.
>
> 1. Windows does not have symlinks. So asdf cannot find files.
> I solved this problem following way:
> 1. delete subfolder systems

we know, when we generating the boxset, exactly which .asd files we
need. i've changed the build script so that a lisp file is created
which explicitly loads all these .asd files. asdf:*central-registry*
is still set to ucw-boxset/systems, but i don't think it matters
anymore.

> 2. When loading lispworks.lisp gives error "package comm. Not found".
> Solved by providing (require "comm") before loading lispworks.lisp

is this trivial-sockets' lispworks.lisp? i tried with the personal
edition on MacOS X and not only was it not neccessary but (require
:comm) failed with an error about comm not existing.

> 3. When starting ucw server with httpd gives error: trivial-sockets bla
bla
> not supported.
> Do not know what that means, tried to switch to aserve, got another error,
> gave up.

what lisp are you testing this on? i had to make a few changes to
trivial sockets (after downloading the boxset apply the patches i've
attached to the trivial-sockets directory).

> This is great effort, and in right direction, that you decided to assemble
a
> single download-install package.
>
> But I think it lacks certain thing essential for success of ANY web
> framework.
> In my opinion it is: SPECIFICLY TARGETING WINDOWS!!
> When you will be able to create a download-install package that will
> smoothly run on windows, then you will see start of wide adoption of ucw.

cool, go for it! the scripts used to generate the boxset are in a
darcs repo at:

http://common-lisp.net/project/ucw/repos/ucw-boxset

atm they assume openmcl and a unix system (it's just a bunch of shell
scripts) but any patches wolud be welcome.




From chriss at muon.de  Tue May  2 18:43:23 2006
From: chriss at muon.de (Christian Haselbach)
Date: Tue, 2 May 2006 20:43:23 +0200
Subject: [Bese-devel] UCW submit action issues
In-Reply-To: <20060502113956.GA24863@rabbit.loc>
References: <20060501132828.GA9899@tngtech.com>
	<20060502113956.GA24863@rabbit.loc>
Message-ID: <20060502184323.GA9199@tngtech.com>

On Tue, May 02, 2006 at 03:39:56PM +0400, Alexey Antipov wrote:
> Please check that dojo.js used, i.e. you have
> something like <script type="text/javascript" src="dojo/dojo.js"?>
> and its really loaded.

No, it is not loaded. This probably explains why it does not work even
with javascript. However, my key question was whether it is possible
to have this working without javascript in ucw.

Regards,
Christian


From chriss at muon.de  Tue May  2 19:22:47 2006
From: chriss at muon.de (Christian Haselbach)
Date: Tue, 2 May 2006 21:22:47 +0200
Subject: [Bese-devel] Re: UCW submit action issues
In-Reply-To: <m2u0881js4.fsf@bese.it>
References: <20060501132828.GA9899@tngtech.com> <m2u0881js4.fsf@bese.it>
Message-ID: <20060502192247.GB9199@tngtech.com>

On Tue, May 02, 2006 at 06:19:39PM +0200, Marco Baringer wrote:
> Christian Haselbach <chriss at muon.de> writes:
> 
> > (defmethod render ((bac b-action-component))
> >   (<:h1 (<:as-html "Choose your action #" (counter bac)))
> >   (<:form (<ucw:submit :value "one" :action (call-viewer bac "one"))
> > 	  (<ucw:submit :value "two" :action (call-viewer bac "two"))))
> >
> > This does nothing (except bringing you back to the start).
> 
> if you change that to <ucw:form (not <:form) does it work?

No, all this does is to let the javascript debuger complain about
missing dojo. I guess it would work with javascript if dojo would be
loaded.

Just checked, yes it does. Defining the component to load dojo.js makes
the button action work.

With links it works just fine (without javascript):
(defmethod render ((bac b-action-component))
  (<:h1 (<:as-html "Choose your action #" (counter bac)))
  (<ucw:a :action (call-viewer bac "one") (<:as-html "one"))
  (<ucw:a :action (call-viewer bac "two") (<:as-html "two")))

I can solve the particular problem with links. It is just that I thought
buttons would work the same way.

Regards,
Christian

P.S.: The test program is not too long, so here it is, if someone wants
to see it:

(in-package :it.bese.ucw-user)

(defvar *b-action*
  (make-instance 'cookie-session-application :url-prefix "/baction/"))

(register-application *default-server* *b-action*)

(defentry-point "index.ucw" (:application *b-action*) ()
  (call 'b-action-component))

(defcomponent b-viewer (simple-window-component)
  ((name :accessor name :initarg :name)))

(defmethod render ((bv b-viewer))
  (<:p "Action: " (<:as-html (name bv)))
  (<ucw:a :action (ok bv) (<:as-html "ok")))

(defcomponent b-action-component (simple-window-component)
  ((counter :accessor counter :initform 0)))

(defaction call-viewer ((bac b-action-component) name)
  (incf (counter bac))
  (call 'b-viewer :name name))

;;; Using form action - works
(defmethod render ((bac b-action-component))
  (<:h1 (<:as-html "Choose your action #" (counter bac)))
  (let ((name "n/a"))
    (<ucw:form :action (call-viewer bac name)
	       (<ucw:submit :value "one" :accessor name)
	       (<ucw:submit :value "two" :accessor name))))

;;; Using button action - doesn't work w/o javascript
(defmethod render ((bac b-action-component))
  (<:h1 (<:as-html "Choose your action #" (counter bac)))
  (<ucw:form (<ucw:submit :value "one" :action (call-viewer bac "one"))
	     (<ucw:submit :value "two" :action (call-viewer bac "two"))))

;;; Using link action - works w/o javascript
(defmethod render ((bac b-action-component))
  (<:h1 (<:as-html "Choose your action #" (counter bac)))
  (<ucw:a :action (call-viewer bac "one") (<:as-html "one"))
  (<ucw:a :action (call-viewer bac "two") (<:as-html "two")))


From mbaringer at common-lisp.net  Wed May  3 04:00:09 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Wed,  3 May 2006 00:00:09 -0400 (EDT)
Subject: [Bese-devel] New patches to arnesi_dev:  2-May-2006
Message-ID: <20060503040009.5EE327D000@common-lisp.net>


Tue May  2 06:43:11 EDT 2006  attila.lendvai at gmail.com
  * Fix the return value of compose for fn > 4

    M ./src/lambda.lisp -1 +1

Mon Feb 13 18:02:04 EST 2006  attila.lendvai at gmail.com
  * Skip nil's in strcat

    M ./src/string.lisp -1 +1


An updated tarball of arnesi_dev's source can be downloaded here:
http://common-lisp.net/project/bese/tarballs/arnesi_dev-20060502.tar.gz

Darcsweb URL:
http://uncommon-web.com/darcsweb/darcsweb.cgi?r=arnesi_dev;a=summary


From whalliburton at gmail.com  Tue May  2 19:01:15 2006
From: whalliburton at gmail.com (William Halliburton)
Date: Tue, 2 May 2006 14:01:15 -0500
Subject: [Bese-devel] ucwctrl problems.
Message-ID: <4e7bd29e0605021201v76d753c1q26d310dd6f708500@mail.gmail.com>

Nothing like bug chasing to learn things.. ;)

Just insalled new source to a new machine and trying to get ucwctl to work.

SBCL 0.9.12

I can get ucw working fine by running sbcl and loading the start.lisp file.

But using ucwctl it called cl-launch::compile-and-load-file but the
start.lisp will not compile without an error.

Transcript from ucwctl start.  See the error at the top. Compilation failed
in (cl-launch::compile-and-load-file "/etc/ucw/start.lisp") but it still
wrote a fasl to the .cache firectory. Just one that ended at the point of
the error, which was the next line after the (asdf:oos 'asdf:load-op
:arnesi) - (setf arnesi::*call/cc-returns* nil)

;
; compilation unit aborted
;   caught 1 fatal ERROR condition
; loading system definition from /home/conrad/.sbcl/systems/arnesi.asd into
; #<PACKAGE "ASDF0">
; registering #<SYSTEM :ARNESI {B234271}> as ARNESI
; registering #<SYSTEM :ARNESI.TEST {A796FD9}> as ARNESI.TEST
; registering #<SYSTEM :ARNESI.CL-PPCRE-EXTRAS {A8FE5E1}> as
; ARNESI.CL-PPCRE-EXTRAS
STYLE-WARNING: implicitly creating new generic function
EFFECTIVE-KEYWORD-NAME
STYLE-WARNING: implicitly creating new generic function APPLY-LAMBDA/CC
STYLE-WARNING: implicitly creating new generic function ENABLED-P
STYLE-WARNING: implicitly creating new generic function LOG.LEVEL
STYLE-WARNING: implicitly creating new generic function (SETF LOG.LEVEL)
STYLE-WARNING: implicitly creating new generic function ENQUEUE
STYLE-WARNING: implicitly creating new generic function DEQUEUE
STYLE-WARNING: implicitly creating new generic function PEEK-QUEUE
STYLE-WARNING: implicitly creating new generic function QUEUE-EMPTY-P
STYLE-WARNING: implicitly creating new generic function QUEUE-FULL-P
STYLE-WARNING: implicitly creating new generic function QUEUE-COUNT
STYLE-WARNING:
   implicitly creating new generic function CALL-FOR-ALL-ELEMENTS-WITH-INDEX
STYLE-WARNING: implicitly creating new generic function GROW-QUEUE
STYLE-WARNING: implicitly creating new generic function MOVE-TAIL
STYLE-WARNING: implicitly creating new generic function MOVE-HEAD
STYLE-WARNING: implicitly creating new generic function
ENQUEUE-OR-MOVE-TO-FRONT
*


The error can be seen by compiling the file seperatly.

conrad at bdm /etc/ucw $ sbcl
* (require 'asdf)

("ASDF")
* (compile-file "/etc/ucw/start.lisp")

; compiling file "/etc/ucw/start.lisp" (written 30 APR 2006 03:50:17 PM):
; compiling (IN-PACKAGE :COMMON-LISP-USER)
; compiling (ASDF:OOS (QUOTE ASDF:LOAD-OP) ...);
; compilation unit aborted
;   caught 1 fatal ERROR condition
compilation aborted because of fatal error:
                                                 READ failure in
COMPILE-FILE:
                                                   READER-ERROR at 915 (line
33, column 31) on #<SB-SYS:FD-STREAM for "file /etc/ucw/start.lisp"
{AA6E239}>:
package "ARNESI" not found

; /etc/ucw/start.fasl written
; compilation finished in 0:00:00
#P"/etc/ucw/start.fasl"
T
T
*


Simple case of the package not present at compile time.

Is this not a case for the eval-when? Anyone know why I did not see this
earlier?

Thank you,
William Halliburton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060502/c5b24962/attachment.html>

From mb at bese.it  Wed May  3 08:37:14 2006
From: mb at bese.it (Marco Baringer)
Date: Wed, 03 May 2006 10:37:14 +0200
Subject: [Bese-devel] Re: ucw boxset
References: <m2aca064i6.fsf@bese.it> <001701c66e03$a02b0910$0302a8c0@p4>
Message-ID: <m2odyfwll1.fsf@bese.it>

"Vagif Hagverdiyev" <vagif at cox.net> writes:

> I'm working on lispworks on windows.
>
> Try (require "comm") instead of (require :comm)

thanks, that worked. i added it to the trivial-sockets code and
regenerated the tarball. can you try running the boxset again?

-- 
-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 May  3 09:43:19 2006
From: mb at bese.it (Marco Baringer)
Date: Wed, 03 May 2006 11:43:19 +0200
Subject: [Bese-devel] Re: ucw boxset
References: <m2bquh283j.fsf@bese.it>
	<88F18DD4-28CA-49B0-B58D-C38457B26AC7@trianet.net>
Message-ID: <m28xpjv3yg.fsf@bese.it>

Waldo Rubinstein <waldo at trianet.net> writes:

> Marco,
>
> I just downloaded your boxset on a fresh SBCL install in Mac OS X.
> Here is the output of the initial sbcl --load start.lisp command:

while i was unable to reproduce this specific error (it looks like
asdf/asdf.lisp isn't getting loaded) i did get errors regarding
trivial-sockets. there are a couple of things i needed to change in
trivial-sockets, until i can talk to dan and see about merging these
into the 'main' trivial-sockets (some of the patches are of debatable
quality) i've created a temporary repo and the boxset uses that
instead of the one on versions.telent.net (gotta love run-on
sentences).

my only suggestion atm is to get the tarball again (i just regenerated
it) and see if you problem still persists. if it does, and it's still
the asdf issue, try to figure out what happens when the first form of
load-asdf.lisp (the auto-generated file) is executed and why that
doesn't in fact load asdf. maybe we sholud do #+sbcl (require :asdf)
#-sbcl (load asdf/asdf.lisp) or something in load-asdf.lisp...

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



From mprice at atl.lmco.com  Wed May  3 15:14:14 2006
From: mprice at atl.lmco.com (Michael Price)
Date: Wed, 3 May 2006 11:14:14 -0400
Subject: [Bese-devel] Re: qbook and ignoring code
In-Reply-To: <17495.38995.160102.394947@brownsmill.atl.lmco.com>
References: <17495.38995.160102.394947@brownsmill.atl.lmco.com>
Message-ID: <17496.51398.74701.879589@brownsmill.atl.lmco.com>

Michael Price writes:
> If my lisp source has something like the following:
> 
>   #+some-crazy-thing-not-in-my-features
>   (ignore this form)
> 
> Then how do I get qbook to ignore that? One practical use of a construct
> like that would be #+5am and test code.
> 
> If qbook can't ignore things like that yet then would someone be kind
> enough to point out where in qbook source I should start looking if I
> wanted to add that feature?

I was somewhat confused about the messages I've seen on this list until I
explored more and discovered that this is essentially the ucw list with
the wrong name.

Is there an actual bese-devel list where they discuss bese issues?

Michael


From mb at bese.it  Wed May  3 15:53:21 2006
From: mb at bese.it (Marco Baringer)
Date: Wed, 03 May 2006 17:53:21 +0200
Subject: [Bese-devel] Re: qbook and ignoring code
References: <17495.38995.160102.394947@brownsmill.atl.lmco.com>
	<17496.51398.74701.879589@brownsmill.atl.lmco.com>
Message-ID: <m23bfrqf4e.fsf@bese.it>

Michael Price <mprice at atl.lmco.com> writes:

> I was somewhat confused about the messages I've seen on this list until I
> explored more and discovered that this is essentially the ucw list with
> the wrong name.
>
> Is there an actual bese-devel list where they discuss bese issues?

no, this is the bese-devel list. it's just that ucw is the most talked
about bese project. FiveAM and arnesi are discussed here occasionally.

in response to your original question:

i don't really know how to get qbook to ignore #+not-on-featurers
foo. due to qbook's use of read-preserving whitespace it's hard to get
it to 'skip' source text. the code is read by the read-source-file
function in src/qbook.lisp which is where you could look, but i don't
have any ideas to suggest to you.

-- 
-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 nathan at acceleration.net  Wed May  3 17:26:43 2006
From: nathan at acceleration.net (Nathan Bird)
Date: Wed, 3 May 2006 13:26:43 -0400
Subject: [Bese-devel] patches not in the darcs repos
Message-ID: <0fbb01c66ed6$bf5c45f0$d80a0a0a@acceleration.net>

I've had a couple occurrences lately of patches seeming to disappear from
the ucw_dev darcs repository, and am trying to track down why that might be.

 

I see from time to time, patches like this
http://uncommon-web.com/darcsweb/darcsweb.cgi?r=ucw_public;a=commit;h=200603
04153343-dd2a1-8df6a3c66adaba7fef54530e989f690c83fcf83d.gz "Move the yaclml
directory into the new html directory" from Marco.

This patch isn't in the ucw_dev repository.  That particular patch I believe
I applied to ucw_public, when I was uploading some other patches to
ucw_public a week ago, I figured that it was just one that hadn't gotten
pushed over from dev to public yet. But then when I got a fresh copy of
ucw_dev I find that the patch isn't present in that repository. But if I
didn't get it from ucw_dev or ucw_public, I'm not sure where it did come
from.

 

Looking at the tree of ucw_dev
http://uncommon-web.com/darcsweb/darcsweb.cgi?r=ucw_dev;a=tree;f=/src you
can also see that the effects of the patch aren't there.

 

I've seen this on one or two other patches in the last couple of months, but
don't have any specific links. The question is, do you know why this might
be happening? Have you unpulled or unrecorded (rather than rollback) patches
from the ucw_dev repo? Am I doing something wrong with darcs? Is this a bug
in darcs? 

 

This hasn't been to much of a problem, but I'm really curious as to why it
is happening.

 

Nathan Bird

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060503/d3b3813a/attachment.html>

From mb at bese.it  Wed May  3 19:19:15 2006
From: mb at bese.it (Marco Baringer)
Date: Wed, 03 May 2006 21:19:15 +0200
Subject: [Bese-devel] Re: patches not in the darcs repos
References: <0fbb01c66ed6$bf5c45f0$d80a0a0a@acceleration.net>
Message-ID: <m2r73aor0s.fsf@bese.it>

"Nathan Bird" <nathan at acceleration.net> writes:

> I see from time to time, patches like this http://uncommon-web.com/darcsweb/
> darcsweb.cgi?r=ucw_public;a=commit;h=
> 20060304153343-dd2a1-8df6a3c66adaba7fef54530e989f690c83fcf83d.gz ?Move the
> yaclml directory into the new html directory? from Marco.
>
> This patch isn?t in the ucw_dev repository.  That particular patch I believe I
> applied to ucw_public, when I was uploading some other patches to ucw_public a
> week ago, I figured that it was just one that hadn?t gotten pushed over from
> dev to public yet. But then when I got a fresh copy of ucw_dev I find that the
> patch isn?t present in that repository. But if I didn?t get it from ucw_dev or
> ucw_public, I?m not sure where it did come from.

you got it from ucw_public, i accidentally pushed it late one night
when i'd had a bit too much to drink and wanted to restructure ucw's
directory layout...

> Looking at the tree of ucw_dev http://uncommon-web.com/darcsweb/darcsweb.cgi?r=
> ucw_dev;a=tree;f=/src you can also see that the effects of the patch aren?t
> there.

it turned out to be a gratuitous change and i thought better of it.

> I?ve seen this on one or two other patches in the last couple of months, but
> don?t have any specific links. The question is, do you know why this might be
> happening? Have you unpulled or unrecorded (rather than rollback) patches from
> the ucw_dev repo? Am I doing something wrong with darcs? Is this a bug in
> darcs?
>
> This hasn?t been to much of a problem, but I?m really curious as to why it is
> happening.

the short story is that i do stupid things from time to time. you're
doing everything right it's just that there are some patches is
ucw_public which i have no intention of applying to ucw_dev (and
should in fact unrec from ucw_public).

when stupid things like this happen _please_ bug me and make sure i
keep things clean.

-- 
-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 nathan at acceleration.net  Wed May  3 20:42:41 2006
From: nathan at acceleration.net (Nathan Bird)
Date: Wed, 3 May 2006 16:42:41 -0400
Subject: [Bese-devel] Re: patches not in the darcs repos
In-Reply-To: <m2r73aor0s.fsf@bese.it>
Message-ID: <0fe501c66ef2$1fc84f40$d80a0a0a@acceleration.net>

> [Bunch of stuff about the mystery of the phantom patches]
>the short story is that i do stupid things from time to time. you're
>doing everything right it's just that there are some patches is
>ucw_public which i have no intention of applying to ucw_dev (and
>should in fact unrec from ucw_public).
>
>when stupid things like this happen _please_ bug me and make sure i
>keep things clean.
>
That was my suspicion :-)

How about (in the future) Rollback instead of an Unrecord, pretty much the
same effect, but then there is a record of the patch being there and then
being undone, so if we happen to have pulled in that brief period, we don't
get confused by the phantom patches :-) "I hate Phantom Spaceman." [1]

Remember, when it's the middle of the night there, we are still working over
here!

Nathan Bird

[1] Venture Brothers is an awesome show:
http://venture.mancubus.net/eps/102.php






From nathan at acceleration.net  Wed May  3 22:56:00 2006
From: nathan at acceleration.net (Nathan Bird)
Date: Wed, 3 May 2006 18:56:00 -0400
Subject: [Bese-devel] ucw special slots
Message-ID: <0ff501c66f04$bfcd4150$d80a0a0a@acceleration.net>

A standard component has a number of slots used by UCW for 'stuff'  i.e.
component.place, parent, calling-component.  When trying to do automatic
component rendering by rendering all of the slots, we have to filter out all
of the ucw ones, otherwise we end in rendering circles.  Is there some way
of determing whether it is a UCW information slot other than by checking its
name against a list?

 

The function component-class.component-slots is close, but that seems to
only give slots declared with the :component keyword, and an ordinary slot
on a component class is still made as an ordinary slot, even if it is later
filled with a component.  It looks like I can declare it with :component T,
to delay filling it but still make it a component slot. I think this will
meet all my needs.

 

Is there something that already does this that I haven't found yet? Am I
missing some better way?

 

Nathan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060503/9eafcda1/attachment.html>

From mbaringer at common-lisp.net  Thu May  4 04:30:04 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Thu,  4 May 2006 00:30:04 -0400 (EDT)
Subject: [Bese-devel] New patches to ucw_dev:  3-May-2006
Message-ID: <20060504043004.9E6CC2009@common-lisp.net>


Wed May  3 05:40:55 EDT 2006  cjstuij at gmail.com
  * changed docs to get up to date and add some info

    M ./README -3 +19
    M ./docs/ucw-intro/ucw-intro.html -368 +281
    M ./docs/ucw-intro/ucw-intro_source.tar


An updated tarball of ucw_dev's source can be downloaded here:
http://common-lisp.net/project/ucw/tarballs/ucw_dev-20060503.tar.gz

Darcsweb URL:
http://uncommon-web.com/darcsweb/darcsweb.cgi?r=ucw_dev;a=summary


From vagif at cox.net  Thu May  4 04:14:34 2006
From: vagif at cox.net (Vagif Hagverdiyev)
Date: Wed, 3 May 2006 21:14:34 -0700
Subject: [Bese-devel] Re: ucw boxset
In-Reply-To: <m2odyfwll1.fsf@bese.it>
Message-ID: <001b01c66f31$40319630$0302a8c0@p4>

Boxset is gone.
Downloaded archive contains only start.lisp and couple of empty folders.


-----Original Message-----
From: bese-devel-bounces at common-lisp.net
[mailto:bese-devel-bounces at common-lisp.net] On Behalf Of Marco Baringer
Sent: Wednesday, May 03, 2006 1:37 AM
To: bese-devel at common-lisp.net
Subject: [Bese-devel] Re: ucw boxset

"Vagif Hagverdiyev" <vagif at cox.net> writes:

> I'm working on lispworks on windows.
>
> Try (require "comm") instead of (require :comm)

thanks, that worked. i added it to the trivial-sockets code and
regenerated the tarball. can you try running the boxset again?

-- 
-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 luca at pca.it  Thu May  4 12:03:41 2006
From: luca at pca.it (Luca Capello)
Date: Thu, 04 May 2006 14:03:41 +0200
Subject: [Bese-devel] Re: ucwctrl problems.
References: <4e7bd29e0605021201v76d753c1q26d310dd6f708500@mail.gmail.com>
Message-ID: <87ac9y574y.fsf@gismo.pca.it>

Hello!

On Tue, 02 May 2006 21:01:15 +0200, William Halliburton wrote:
> Just insalled new source to a new machine and trying to get ucwctl
> to work.
>
> SBCL 0.9.12
[...]
> The error can be seen by compiling the file seperatly.
[...]
> Simple case of the package not present at compile time.
>
> Is this not a case for the eval-when? Anyone know why I did not see
> this earlier?

What does "earlier" mean?  I got the error with SBCL versions
0.9.9.11, 0.9.10 and 0.9.11 (the first two manually compiled, the
latest one Debian binary).  The same happens with CLISP-2.28 and
CMUCL-19c-release-patch-1, but the latter also outputs

  The package named "IT.BESE.UCW-USER" doesn't exist.

Anyone, I confirm the error ;-)

Thx, bye,
Gismo / Luca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060504/585695d0/attachment.sig>

From attila.lendvai at gmail.com  Thu May  4 20:57:05 2006
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Thu, 4 May 2006 22:57:05 +0200
Subject: [Bese-devel] ajax related and other patches in public
Message-ID: <b54b34af0605041357w4c9d4696j3f7831b2e5defbf9@mail.gmail.com>

hi!

i've applied a few patches to the public repo. the most interesting
and the most dubious is this (i'm not sure that this is The Right
Way):

* Store an action-struct instead of a simple lambda when making actions

(defstruct (action-entry (:conc-name action-))
  (lambda nil :type function)
  (valid-p t :type boolean)
  (isolated-p nil :type boolean)
  (ajax-p nil :type boolean)
  (id nil :type (or nil string)))

the interesting part is the ajax-p flag, which alters the action
calling so that it gets suitable for ajax communication.

with this patch, with dojo plus some other code which is not mature
enough (ajax-component-mixin and firends) i'm replacing entire
widget-components quite transparently to the rest of the code.
basically i can start the render loop at random position in the
component hierarchy which will walk the parent slot. as soon as an
ajax-component-mixin is found the rendering starts there and the
result is returned wrapped in an xml.

the client side js blindly looks up the div with the id and replaces
with the returned xml. there were some gotcha's, but it works like a
charm now... :)

hope you like it, the rest will follow

- attila

(alias 101 on irc &no 'its not lisp code :)

From attila.lendvai at gmail.com  Thu May  4 22:15:21 2006
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Fri, 5 May 2006 00:15:21 +0200
Subject: [Bese-devel] ajax related and other patches in public
In-Reply-To: <b2ec2dee0605041457t6d702c1dy85a9284fd0c29bcc@mail.gmail.com>
References: <b54b34af0605041357w4c9d4696j3f7831b2e5defbf9@mail.gmail.com>
	<b2ec2dee0605041457t6d702c1dy85a9284fd0c29bcc@mail.gmail.com>
Message-ID: <b54b34af0605041515q41756790j852cf0aeac3d1459@mail.gmail.com>

> Whoa!  Dreams come true.. :-)
> Do you have the degradeable stuff as well so it transparently works
> with non-ajax clients?

i'm not even sure it works on ie... :D

our focus is on enterprise stuff where it's ok to expect a recent ff
installed. so i'll not put too much effort into that. but on a
resonably new ie or ff it should work fine.

and to be honest i'm just fishing in the dirt: i'm new to js, html,
lisp, and ucw... but not to google! :) and stuff seems to work...

hell, i always wanted to stay away from html, css, js, etc...

- attila

(alias 101 on irc &no 'its not lisp code :)

From nathan at acceleration.net  Thu May  4 22:38:33 2006
From: nathan at acceleration.net (Nathan Bird)
Date: Thu, 4 May 2006 18:38:33 -0400
Subject: [Bese-devel] ucw special slots
In-Reply-To: <0ff501c66f04$bfcd4150$d80a0a0a@acceleration.net>
Message-ID: <108501c66fcb$79e36df0$d80a0a0a@acceleration.net>

I was playing around with the component-class.component-slots function a bit
more and the idea of declaring components slots with ":component T". The
goal is to be able to declare an unbound slot that is still listed as one of
the component-slots.  This doesn't quite work right now because it tries to
instantiate a class of type t, and fails.

 

Looking at the code, I can add a check into the initialize-component-slots
function that doesn't try to make an instance when that is the value for
type of component. But this is a bit odd because T is a type.

 

Alternatively we thought about using ":component nil" to indicate the same,
but this kind of appears to be saying I don't want it to be a component.
This does capture the idea of getting an unbound slot though.

 

Alternatively we could add to the standard-component-direct-slot a slot
named componentp or some such.

 

I'm leaning towards :component nil, and add a bit of documentation. Any
thoughts? Is this a bad idea for some other reason? Any better suggestions?
I don't actually have a component right now that I need to be able to do
that, but it seems like something I would want and I was working on a
child-components function which got me thinking about it.

 

Next to this, I am implementing a nice child-components function that will
give you the values of all the slots that are component-slots, and have
components in them.

 

Nathan Bird

 

 

  _____  

From: bese-devel-bounces at common-lisp.net
[mailto:bese-devel-bounces at common-lisp.net] On Behalf Of Nathan Bird
Sent: Wednesday, May 03, 2006 6:56 PM
To: bese-devel at common-lisp.net
Subject: [Bese-devel] ucw special slots

 

A standard component has a number of slots used by UCW for 'stuff'  i.e.
component.place, parent, calling-component.  When trying to do automatic
component rendering by rendering all of the slots, we have to filter out all
of the ucw ones, otherwise we end in rendering circles.  Is there some way
of determing whether it is a UCW information slot other than by checking its
name against a list?

 

The function component-class.component-slots is close, but that seems to
only give slots declared with the :component keyword, and an ordinary slot
on a component class is still made as an ordinary slot, even if it is later
filled with a component.  It looks like I can declare it with :component T,
to delay filling it but still make it a component slot. I think this will
meet all my needs.

 

Is there something that already does this that I haven't found yet? Am I
missing some better way?

 

Nathan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060504/690a4ef1/attachment.html>

From attila.lendvai at gmail.com  Thu May  4 22:35:24 2006
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Fri, 5 May 2006 00:35:24 +0200
Subject: [Bese-devel] ajax related and other patches in public
In-Reply-To: <b54b34af0605041515q41756790j852cf0aeac3d1459@mail.gmail.com>
References: <b54b34af0605041357w4c9d4696j3f7831b2e5defbf9@mail.gmail.com>
	<b2ec2dee0605041457t6d702c1dy85a9284fd0c29bcc@mail.gmail.com>
	<b54b34af0605041515q41756790j852cf0aeac3d1459@mail.gmail.com>
Message-ID: <b54b34af0605041535t1840f0afn9dbf93df7249cb40@mail.gmail.com>

> and to be honest i'm just fishing in the dirt: i'm new to js, html,

err, before someone takes it as an insult on lisp or ucw, it wanted to
be "fishing in muddy waters"... :) but i was wrong when i tought that
it also exists in english, anyway.

so it only means i'm not sure what i'm doing...

- attila

(alias 101 on irc &no 'its not lisp code :)

From alexander.kjeldaas at gmail.com  Thu May  4 21:57:57 2006
From: alexander.kjeldaas at gmail.com (Alexander Kjeldaas)
Date: Thu, 4 May 2006 23:57:57 +0200
Subject: [Bese-devel] ajax related and other patches in public
In-Reply-To: <b54b34af0605041357w4c9d4696j3f7831b2e5defbf9@mail.gmail.com>
References: <b54b34af0605041357w4c9d4696j3f7831b2e5defbf9@mail.gmail.com>
Message-ID: <b2ec2dee0605041457t6d702c1dy85a9284fd0c29bcc@mail.gmail.com>

On 5/4/06, Attila Lendvai <attila.lendvai at gmail.com> wrote:
>
> the interesting part is the ajax-p flag, which alters the action
> calling so that it gets suitable for ajax communication.
>
> with this patch, with dojo plus some other code which is not mature
> enough (ajax-component-mixin and firends) i'm replacing entire
> widget-components quite transparently to the rest of the code.
> basically i can start the render loop at random position in the
> component hierarchy which will walk the parent slot. as soon as an
> ajax-component-mixin is found the rendering starts there and the
> result is returned wrapped in an xml.
>
> the client side js blindly looks up the div with the id and replaces
> with the returned xml. there were some gotcha's, but it works like a
> charm now... :)
>
> hope you like it, the rest will follow
>

Whoa!  Dreams come true.. :-)
Do you have the degradeable stuff as well so it transparently works
with non-ajax clients?

Can't wait to get going on my project now.

astor


From mbaringer at common-lisp.net  Fri May  5 04:30:05 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Fri,  5 May 2006 00:30:05 -0400 (EDT)
Subject: [Bese-devel] New patches to ucw_dev:  4-May-2006
Message-ID: <20060505043005.02A762F00A@common-lisp.net>


Thu May  4 19:33:24 EDT 2006  Maciek Pasternacki <maciekp at japhy.fnord.org>
  * Docfix for net-telent-date dependency.

    M ./README +11
    M ./docs/QUICKSTART +1

Tue May  2 21:38:44 EDT 2006  Maciek Pasternacki <maciekp at japhy.fnord.org>
  * INCOMPATIBLE CHANGE: add NET-TELENT-DATE dependency, send out Date: header, make SERVE-FILE cache-friendly (use Date:, Last-Modified:, Expires: and If-Modified-Since: headers).

    M ./src/backend/common.lisp -12 +23
    M ./src/rerl/standard-server.lisp -1 +2
    M ./ucw.asd -1 +1

Tue May  2 21:36:48 EDT 2006  Maciek Pasternacki <maciekp at japhy.fnord.org>
  * Don't send headers set to NIL (especially Content-Length:) in response.

    M ./src/backend/httpd.lisp -4 +7

Tue May  2 21:19:04 EDT 2006  Maciek Pasternacki <maciekp at japhy.fnord.org>
  * New function (delete-header message header-name).

    M ./src/backend/httpd.lisp +8

Tue May  2 18:20:10 EDT 2006  Maciek Pasternacki <maciekp at japhy.fnord.org>
  * Don't send body if HTTP method is HEAD.

    M ./src/backend/httpd.lisp -2 +5

Tue May  2 18:19:55 EDT 2006  Maciek Pasternacki <maciekp at japhy.fnord.org>
  * Save HTTP method of request as string.

    M ./src/backend/httpd.lisp -1 +1

Tue May  2 18:19:39 EDT 2006  Maciek Pasternacki <maciekp at japhy.fnord.org>
  * Initform for (request response).

    M ./src/backend/httpd.lisp -1 +1

Tue May  2 18:11:58 EDT 2006  Maciek Pasternacki <maciekp at japhy.fnord.org>
  * Include in httpd response a request associated with it.

    M ./src/backend/httpd.lisp -2 +5
    M ./src/backend/mod-lisp.lisp -1 +3


An updated tarball of ucw_dev's source can be downloaded here:
http://common-lisp.net/project/ucw/tarballs/ucw_dev-20060504.tar.gz

Darcsweb URL:
http://uncommon-web.com/darcsweb/darcsweb.cgi?r=ucw_dev;a=summary


From attila.lendvai at gmail.com  Fri May  5 09:16:08 2006
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Fri, 5 May 2006 11:16:08 +0200
Subject: [Bese-devel] ucw special slots
In-Reply-To: <108501c66fcb$79e36df0$d80a0a0a@acceleration.net>
References: <0ff501c66f04$bfcd4150$d80a0a0a@acceleration.net>
	<108501c66fcb$79e36df0$d80a0a0a@acceleration.net>
Message-ID: <b54b34af0605050216k2b578abdm21cfafe8ef7318d8@mail.gmail.com>

> Alternatively we thought about using ":component nil" to indicate the same,
> but this kind of appears to be saying I don't want it to be a component.
> This does capture the idea of getting an unbound slot though.

i'm using that, too. from one point of view it might seem odd, because
nil is false in cl. but if you look at it so that :component means
that it's a component slot, and its argument is the initform of the
slot, then it looks logical.

> Alternatively we could add to the standard-component-direct-slot a slot
> named componentp or some such.

if you ever start playing with the standard-component(-class) code,
please consider factoring out the :component nil behaviour into a
separate feature. i've tried to create a
component-hierarchy-node-mixin that has the lightweigth behaviour
(parent slot, :component slots auto setf-ing place, etc) of component
(leaving out backtracking and such), but i'm not a MOP guru and
failed. for now i have a local patch that makes components
instantiatable outside of a request context, but it's a waste
comparing to that single feature i want: auto setf-ing the place of
components being put in :component slots of something that is not a
full-blown component.

> Next to this, I am implementing a nice child-components function that will
> give you the values of all the slots that are component-slots, and have
> components in them.

consider the case of containers. unfortunately there is some anomaly
in container.lisp, which is my fault. switching-container does not
inherit from component, while list-container does. one can find pro
reasons for this, but still it's strange why one of them is not like
the other. (the clean solution would probably be that neither is a
component, but i can't really decide...)

but either way, containers ought to be handled in a function like
child-components. and if swithing-container is not a component...

- attila

(alias 101 on irc &no 'its not lisp code :)

From emailmac at gmail.com  Sat May  6 03:45:48 2006
From: emailmac at gmail.com (Mac Chan)
Date: Fri, 5 May 2006 20:45:48 -0700
Subject: [Bese-devel] arnesi call/cc usage examples
Message-ID: <4877ae640605052045v760fb5f0hcb4d1cb8bef68102@mail.gmail.com>

Hi,

I'm reading the the last few chapters of _On Lisp_. The
nondeterministic programs are pretty cool, but using the continuation
passing style is very convenient at times.

Since I'm still not very well versed in advanced lisp techniques, I
couldn't figure out by myself how to use the call/cc interpreter in
arnesi.

Could somebody try to dumb it down and explains in high level how it works?

Actually, if any kind soul can translate the following scheme examples
as described in _On Lisp_ to CL using the arnesi library, that'll
greatly help newbies alike to understand how to use it.

Thanks!
-- Mac

;; Figure 22.3 contains a pair of functions to guess two numbers which
;; sum to a number given by the caller.  The first function,
;; two-numbers, nondeterministically chooses two numbers and returns
;; them in a list. When we call parlor-trick, it calls two-numbers for
;; a list of two integers. Note that, in making its choice,
;; two-numbers doesn't have access to the number entered by the user.

;; Figure 22.3: Choice in a subroutine.

(define (two-numbers)
    (list (choose '(0 1 2 3 4 5))
          (choose '(0 1 2 3 4 5))))

(define (parlor-trick sum)
    (let ((nums (two-numbers)))
      (if (= (apply + nums) sum)
          `(the sum of , at nums)
          (fail))))


;; Figure 20.3: Tree traversal using continuations.

(define (dft tree)
    (cond ((null? tree) ())
          ((not (pair? tree)) (write tree))
          (else (dft (car tree))
                (dft (cdr tree)))))

(define *saved* ())

(define (dft-node tree)
    (cond ((null? tree) (restart))
          ((not (pair? tree)) tree)
          (else (call-with-current-continuation
                 (lambda (cc)
                   (set! *saved*
                         (cons (lambda ()
                                 (cc (dft-node (cdr tree))))
                               *saved*))
                   (dft-node (car tree)))))))

(define (restart)
    (if (null? *saved*)
        'done
        (let ((cont (car *saved*)))
          (set! *saved* (cdr *saved*))
          (cont))))

(define (dft2 tree)
    (set! *saved* ())
  (let ((node (dft-node tree)))
    (cond ((eq? node 'done) ())
          (else (write node)
                (restart)))))

;; Suppose nodes is bound to a list of nodes in a tree, and (kids n)
;; is a function which returns the descendants of node n, or #f if
;; there are none. We want to write a function (descent n1 n2) which
;; returns a list of nodes on some path from n1 to its descendant n2,
;; if there is one.

;; Figure 22.2: Nondeterministic tree search.

(define (descent n1 n2)
    (cond ((eq? n1 n2) (list n2))
          ((null? (kids n1)) (fail))
          (else (cons n1 (descent (choose (kids n1)) n2)))))


From emailmac at gmail.com  Sat May  6 20:09:10 2006
From: emailmac at gmail.com (Mac Chan)
Date: Sat, 6 May 2006 13:09:10 -0700
Subject: [Bese-devel] Re: arnesi call/cc usage examples
Message-ID: <4877ae640605061309p1fcbc07ey35486b0eeacbdf1c@mail.gmail.com>

So, going thru all the devel archives _again_ give me a few insight of
the semantics of call/cc.

Larry D'Anna's examples are quite helpful, but I have to modify his
examples to run in the latest arnesi:

(with-call/cc
  (print (let/cc k
           (print 'a)
           (kall k 'b)
           (print 'c)
           'd)))

;; Here is an example of how to use this construct to implement coroutines
;; It should print out the first 10 pyramid numbers.

(defmacro coro (&body body)
  (with-unique-names (coro)
    `(let (,coro)
      (with-call/cc
	(flet ((yield (x)
		 (let/cc k
		   (setq ,coro k)
		   x)))
	  (yield :ok)
	  , at body))
      #'(lambda (x) (kall ,coro x)))))

(let* ((tri-cr (coro (loop with num = 0
			   for i = 1 then (1+ i)
			   do (yield (incf num i)))))
       (pyr-cr (coro (loop with num = 0
			   do (yield (incf num (funcall tri-cr nil)))))))
  (loop for i from 1 to 10
	collect (funcall pyr-cr nil)))

;; (1 4 10 20 35 56 84 120 165 220)



So the first thing I want to try is to write the depth first search
using arnesi:

(defparameter t1 '(a (b (d h)) (c e (f i) g)))

(defparameter *saved* nil)

(defun/cc dft-node (tree)
  (cond ((null tree) (restart-search))
        ((not (consp tree)) tree)
        (t (call/cc
            (lambda (cc)
              (setf *saved*
                    (cons #'(lambda ()
                              (kall cc (dft-node (cdr tree))))
                          *saved*))
              (dft-node (car tree)))))))

(defun/cc restart-search ()
  (if (null *saved*)
      'done
      (let ((cont (car *saved*)))
        (setf *saved* (cdr *saved*))
        (funcall cont))))

ARNESI> (with-call/cc (dft-node t1))
A
ARNESI> (with-call/cc (restart-search))
B
ARNESI> (with-call/cc (restart-search))
D
ARNESI> (with-call/cc (restart-search))
H
ARNESI> (with-call/cc (restart-search))
C
ARNESI> (with-call/cc (restart-search))
E
ARNESI> (with-call/cc (restart-search))
F
ARNESI> (with-call/cc (restart-search))
I
ARNESI> (with-call/cc (restart-search))
G
ARNESI> (with-call/cc (restart-search))
DONE

So far, so good.

However, when I try to package up the automatic backtracking in a
function, it doesn't work.

(defun/cc dft2 (tree)
  (setf *saved* nil)
  (let ((node (dft-node tree)))
    (cond ((eq node 'done) nil)
          (t (print node)
             (restart-search)))))

ARNESI> (with-call/cc (dft2 t1))
A  ;;;; we want dft2 to return ABDHCEFIG instead

Whereas the _On Lisp_ dft2 example written in continuation passing
style work as advertised.

How to write dft2 so it will return all the results (ABDHCEFIG) at once?


There's also an example in the archives that I don't quite understand:

(defvar *k* nil)

(with-call/cc
  (dotimes (i 3)
    (let/cc k
      (setf *k* k)
      i)))
0
CL-USER> (kall *k*)
1
CL-USER> (kall *k*)
2
CL-USER> (kall *k*)
NIL


In PG's _On Lisp_, he usually cons the continuation into a global list
and pop one off one at a time when resuming the computation.

In the above example that Marco gave, how come repeating calling *k*
will return different result?  I assume that the last (setf *k* k)
will overwrite the previous (setf *k* k) so calling (kall *k*) should
always return the same thing??

Thanks,
-- Mac

(PS: I was wondering if having call/cc in Lisp implementation would be
a good thing? It will greatly simplify things so we don't have to
emulate it in user code)


From cjstuij at gmail.com  Sun May  7 14:51:47 2006
From: cjstuij at gmail.com (Ties Stuij)
Date: Sun, 7 May 2006 16:51:47 +0200
Subject: [Bese-devel] Re: ucw boxset
In-Reply-To: <001b01c66f31$40319630$0302a8c0@p4>
References: <m2odyfwll1.fsf@bese.it> <001b01c66f31$40319630$0302a8c0@p4>
Message-ID: <d7ce4ebf0605070751n543b6a82w1e303cb4e71f58e3@mail.gmail.com>

> Downloaded archive contains only start.lisp and couple of empty folders.

worked again a day later but now it contains only the start.lisp file

greets,
Ties


From gefla at pond.sub.org  Sun May  7 18:02:54 2006
From: gefla at pond.sub.org (Gerd Flaig)
Date: Sun, 07 May 2006 20:02:54 +0200
Subject: [Bese-devel] Re: ucw boxset
References: <m2bquh283j.fsf@bese.it> <m24q0927cz.fsf@bese.it>
Message-ID: <8764khg1bl.fsf@kilo.pond.sub.org>

Marco Baringer <mb at bese.it> writes:

> Marco Baringer <mb at bese.it> writes:
>
>> comments?
>
> um, i totaly forgot the real reason i announced that:
>
> i would like it if people could download it and make sure it does
> actually run. just see if this works as expected:
>
> wget http://common-lisp.net/project/ucw/ucw-boxset.tar.gz
> tar -zxf ucw-boxset.tar.gz
> cd ucw-boxset
> YOURLISPHERE --load start.lisp

tried it in a fresh Debian sid chroot with sbcl. Is it intended
behaviour that "Signal a render'ing(sic) error" produces an empty page
an code 200 instead of a descriptive error message and 5xx? Console
output is:

   17:59 UCW.BACKEND/+INFO+: Handling request for "/error-render.ucw?s=rzYXQrjNnUlitvskXPLVNKcmfCEBajZohZuDyKHC"
   17:59 UCW-LOGGER/+INFO+: URL-DISPATCHER matched, passing control to #<CLOSURE (LAMBDA
                                                            (IT.BESE.UCW::APPLICATION
                                                             IT.BESE.UCW::CONTEXT)) {CF0A95D}>.
   17:59 UCW-LOGGER/+INFO+: CALL?ng to /#<ERROR-DURING-RENDER-COMPONENT {A80EFA9}> 
   17:59 UCW-LOGGER/+ERROR+: Got request error #<SIMPLE-ERROR {A833631}>.
   17:59 UCW-LOGGER/+INFO+: Aborting request.


Everything else works fine as far as I can see.

     Goodbyte, Gerd.
-- 
The last thing one knows in constructing a work is what to put first.
                -- Blaise Pascal



From whalliburton at gmail.com  Sun May  7 20:08:47 2006
From: whalliburton at gmail.com (William Halliburton)
Date: Sun, 7 May 2006 15:08:47 -0500
Subject: [Bese-devel] Re: ucwctrl problems.
In-Reply-To: <87ac9y574y.fsf@gismo.pca.it>
References: <4e7bd29e0605021201v76d753c1q26d310dd6f708500@mail.gmail.com>
	<87ac9y574y.fsf@gismo.pca.it>
Message-ID: <4e7bd29e0605071308x6dbb6b72q43ab752b9b3f70ce@mail.gmail.com>

Yes. I fixed the problem by wrapping several lines in an eval-when

;;;; Load arnesi first so we can set arnesi::*call/cc-returns* before
;;;; ucw is compiled and loaded.

(eval-when (:compile-toplevel :load-toplevel :execute)
  (asdf:oos 'asdf:load-op :arnesi))

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

;;;; Load up UCW itself

(eval-when (:compile-toplevel :load-toplevel :execute)
  (asdf:oos 'asdf:load-op :ucw))


On 5/4/06, Luca Capello < luca at pca.it> wrote:
>
> Hello!
>
> On Tue, 02 May 2006 21:01:15 +0200, William Halliburton wrote:
> > Just insalled new source to a new machine and trying to get ucwctl
> > to work.
> >
> > SBCL 0.9.12
> [...]
> > The error can be seen by compiling the file seperatly.
> [...]
> > Simple case of the package not present at compile time.
> >
> > Is this not a case for the eval-when? Anyone know why I did not see
> > this earlier?
>
> What does "earlier" mean?  I got the error with SBCL versions
> 0.9.9.11 , 0.9.10 and 0.9.11 (the first two manually compiled, the
> latest one Debian binary).  The same happens with CLISP-2.28 and
> CMUCL-19c-release-patch-1, but the latter also outputs
>
>   The package named " IT.BESE.UCW-USER" doesn't exist.
>
> Anyone, I confirm the error ;-)
>
> Thx, bye,
> Gismo / Luca
>
>
> _______________________________________________
> bese-devel mailing list
> bese-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060507/3ec7ff56/attachment.html>

From evrim at core.gen.tr  Mon May  8 10:04:28 2006
From: evrim at core.gen.tr (Evrim ULU)
Date: Mon, 08 May 2006 13:04:28 +0300
Subject: [Bese-devel] Ajax
Message-ID: <445F17AC.5000901@core.gen.tr>

Hi,

I've attached the ajax patch for ucw_dev. Added some examples to
examples/ajax folder, but they'r rather like tests for now. It's needing
jsunit tests, real examples and more documentation and bug fixes.

have a nice day.
evrim.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ucw-ajax-0.1.patch
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060508/bfc3b302/attachment.ksh>

From attila.lendvai at gmail.com  Mon May  8 15:15:22 2006
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Mon, 8 May 2006 17:15:22 +0200
Subject: [Bese-devel] Ajax
In-Reply-To: <445F17AC.5000901@core.gen.tr>
References: <445F17AC.5000901@core.gen.tr>
Message-ID: <b54b34af0605080815m11d2470dq674705c85b01e42f@mail.gmail.com>

> I've attached the ajax patch for ucw_dev. Added some examples to
> examples/ajax folder, but they'r rather like tests for now. It's needing
> jsunit tests, real examples and more documentation and bug fixes.
>
> have a nice day.
> evrim.

thanks Evrim!

i've already merged it with my local changes and the ajax examples work fine.

i suggest to create a new branch for the ajax stuff until it's mature
enough. it would be cool if we could have write access to it with
Evrim but i don't want to talk in his name. unfortunately he has no
c-l.net account, luckily i have one (alendvai).

Marco, if you agree, could you create the new branch for the ajax stuff?

- attila

(alias 101 on irc &no 'its not lisp code :)

From nathan at acceleration.net  Mon May  8 18:02:52 2006
From: nathan at acceleration.net (Nathan Bird)
Date: Mon, 8 May 2006 14:02:52 -0400
Subject: [Bese-devel] read-from-client-string
Message-ID: <003401c672c9$a0980c70$d80a0a0a@acceleration.net>

There are a number of cases of read-from-string in ucw_dev right now. Most
of these are in form.lisp, but there are a few scattered elsewhere as well.
Almost every case of this needs to be surrounded in let *read-eval* be nil
block. This is so that strings being read in from the client can't be
maliciously constructed to execute arbitrary code. 

Think about someone entering as their age "#.(clsql:query "DELETE * FROM
contacts")"... whoops!

What about setting this up surrounding every request? Wrap a suitably
high-level handle-request function with a binding for *read-eval* to nil to
help prevent that class of vulnerability to begin with.

In the meantime I added a read-from-client-string function to helpers.lisp
which just does the binding and read-from-string call. Form.lisp now uses
this. Other places that it might be appropriate is in the aserve backend
where it is parsing headers. I didn't touch anything here since I don't have
a working aserve to test this with.  

Admin.lisp also calls read-from-string, but since the result is immediately
being passed to eval itself, I don't think that would really help anything
:-)

It's in ucw_public.

Nathan Bird



From waldo at trianet.net  Mon May  8 18:27:27 2006
From: waldo at trianet.net (Waldo Rubinstein)
Date: Mon, 8 May 2006 14:27:27 -0400
Subject: [Bese-devel] OpenLaszlo and UCW
Message-ID: <749799F6-2F0C-4F2C-92B3-B25193AF88CF@trianet.net>

Has anyone ever used OpenLaszlo and UCW together? In a way, I think  
it sort of defeats the purpose of the whole browser-based  
continuation concept, but, I have a simple app I developed in UCW  
working just fine. I would like to deliver a RIA using OpenLaszlo  
connected to the same, already working, UCW app. Basically, just add  
a new view to the app.

Is it possible? OpenLaszlo would simply work off HTTP GET/POST  
requests to the UCW server. Can the concept of continuation be  
extended to the OpenLaszlo app?

BTW, in case anyone is wondering, I'm very new to OpenLaszlo and am  
just learning it, so please accept my apologies if my question is  
stupid. So far, I've done very simple things in OpenLaszlo and the  
idea came to my mind about the UCW integration.

Anyway, thanks,
Waldo


From tomelam at gmail.com  Tue May  9 09:25:34 2006
From: tomelam at gmail.com (Thomas Elam)
Date: Tue, 9 May 2006 14:55:34 +0530
Subject: [Bese-devel] OpenLaszlo and UCW
In-Reply-To: <749799F6-2F0C-4F2C-92B3-B25193AF88CF@trianet.net>
References: <749799F6-2F0C-4F2C-92B3-B25193AF88CF@trianet.net>
Message-ID: <6251c7160605090225h6a119845r6c5c0f8d348773c9@mail.gmail.com>

Waldo,

I am *very* interested in what you have done. I have been following
OpenLaszlo and wanted to combine it with UCW, too.

On 5/8/06, Waldo Rubinstein <waldo at trianet.net> wrote:
>
> Has anyone ever used OpenLaszlo and UCW together? In a way, I think
> it sort of defeats the purpose of the whole browser-based
> continuation concept, but, I have a simple app I developed in UCW
> working just fine. I would like to deliver a RIA using OpenLaszlo
> connected to the same, already working, UCW app. Basically, just add
> a new view to the app.
>
> Is it possible? OpenLaszlo would simply work off HTTP GET/POST
> requests to the UCW server. Can the concept of continuation be
> extended to the OpenLaszlo app?
>
> BTW, in case anyone is wondering, I'm very new to OpenLaszlo and am
> just learning it, so please accept my apologies if my question is
> stupid. So far, I've done very simple things in OpenLaszlo and the
> idea came to my mind about the UCW integration.
>
> Anyway, thanks,
> Waldo
> _______________________________________________
> bese-devel mailing list
> bese-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel
>



--
Lisp humour:

LISP> (setf god (symbol-value god))
Warning:  Declaring GOD special.
Error:  GOD is unbound.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060509/64f905e9/attachment.html>

From waldo at trianet.net  Tue May  9 12:48:49 2006
From: waldo at trianet.net (Waldo Rubinstein)
Date: Tue, 9 May 2006 08:48:49 -0400
Subject: [Bese-devel] OpenLaszlo and UCW
In-Reply-To: <6251c7160605090225h6a119845r6c5c0f8d348773c9@mail.gmail.com>
References: <749799F6-2F0C-4F2C-92B3-B25193AF88CF@trianet.net>
	<6251c7160605090225h6a119845r6c5c0f8d348773c9@mail.gmail.com>
Message-ID: <8494C95A-CF73-463A-AA22-8F3BA3DB7973@trianet.net>

Thomas,

Well, that's the thing. So far, I've just been "playing" with OL. It  
is because I also want to combine it with UCW that I was asking. I  
haven't done anything to combine/integrate them yet, but I guess not  
many people have. I may just take a stab at it later this week,  
unless someone comes forward with practical experience or suggestions.

Thanks,
Waldo

On May 9, 2006, at 5:25 AM, Thomas Elam wrote:

> Waldo,
>
> I am *very* interested in what you have done. I have been following  
> OpenLaszlo and wanted to combine it with UCW, too.
>
> On 5/8/06, Waldo Rubinstein <waldo at trianet.net> wrote:
> Has anyone ever used OpenLaszlo and UCW together? In a way, I think
> it sort of defeats the purpose of the whole browser-based
> continuation concept, but, I have a simple app I developed in UCW
> working just fine. I would like to deliver a RIA using OpenLaszlo
> connected to the same, already working, UCW app. Basically, just add
> a new view to the app.
>
> Is it possible? OpenLaszlo would simply work off HTTP GET/POST
> requests to the UCW server. Can the concept of continuation be
> extended to the OpenLaszlo app?
>
> BTW, in case anyone is wondering, I'm very new to OpenLaszlo and am
> just learning it, so please accept my apologies if my question is
> stupid. So far, I've done very simple things in OpenLaszlo and the
> idea came to my mind about the UCW integration.
>
> Anyway, thanks,
> Waldo
> _______________________________________________
> bese-devel mailing list
> bese-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel
>
>
>
> -- 
> Lisp humour:
>
> LISP> (setf god (symbol-value god))
> Warning:  Declaring GOD special.
> Error:  GOD is unbound.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060509/9643964e/attachment.html>

From attila.lendvai at gmail.com  Tue May  9 13:32:44 2006
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Tue, 9 May 2006 15:32:44 +0200
Subject: [Bese-devel] serve-file fixed
Message-ID: <b54b34af0605090632m8056688ka9a72154c6d632d7@mail.gmail.com>

hi!

fyi, i've broken serve-file, and it's already in ucw_dev. a fix is
available in ucw_public if someone has pulled it...

sorry for that,

- attila

(alias 101 on irc &no 'its not lisp code :)

From maciekp at japhy.fnord.org  Tue May  9 14:36:27 2006
From: maciekp at japhy.fnord.org (Maciek Pasternacki)
Date: Tue, 09 May 2006 16:36:27 +0200
Subject: [Bese-devel] serve-file fixed
In-Reply-To: <b54b34af0605090632m8056688ka9a72154c6d632d7@mail.gmail.com>
	(Attila Lendvai's message of "Tue, 9 May 2006 15:32:44 +0200")
References: <b54b34af0605090632m8056688ka9a72154c6d632d7@mail.gmail.com>
Message-ID: <87slnj9ses.fsf@lizard.king>

On Prickle-Prickle, Discord 56, 3172 YOLD, Attila Lendvai wrote:

> fyi, i've broken serve-file, and it's already in ucw_dev. a fix is
> available in ucw_public if someone has pulled it...

,----
| Tue May  9 09:24:43 EDT 2006  attila.lendvai at gmail.com
|   * Fix serve-file
| Shall I pull this patch? (3/3) [ynWvxqadjk], or ? for help: y
| Finished pulling.
| mpasternacki at clnet:/project/ucw/public_html/repos/ucw_dev$
`----

It's in ucw_dev now.

-- 
__    Maciek Pasternacki <maciekp at japhy.fnord.org> [ http://japhy.fnord.org/ ]
`| _   |_\  / { ...don't just call me pessimist, try and read between the
,|{-}|}| }\/ lines, I can't imagine why you wouldn't welcome any change my
\/   |____/ friend, I wanna see it all come down... }   ( M. J. Keenan )  -><-


From mb at bese.it  Tue May  9 17:01:28 2006
From: mb at bese.it (Marco Baringer)
Date: Tue, 09 May 2006 19:01:28 +0200
Subject: [Bese-devel] Re: Ajax
References: <445F17AC.5000901@core.gen.tr>
	<b54b34af0605080815m11d2470dq674705c85b01e42f@mail.gmail.com>
Message-ID: <m23bfj5dzr.fsf@bese.it>

"Attila Lendvai" <attila.lendvai at gmail.com> writes:

>> I've attached the ajax patch for ucw_dev. Added some examples to
>> examples/ajax folder, but they'r rather like tests for now. It's needing
>> jsunit tests, real examples and more documentation and bug fixes.
>>
>> have a nice day.
>> evrim.
>
> thanks Evrim!
>
> i've already merged it with my local changes and the ajax examples work fine.
>
> i suggest to create a new branch for the ajax stuff until it's mature
> enough. it would be cool if we could have write access to it with
> Evrim but i don't want to talk in his name. unfortunately he has no
> c-l.net account, luckily i have one (alendvai).
>
> Marco, if you agree, could you create the new branch for the ajax stuff?

done:

http://common-lisp.net/project/ucw/repos/ucw_ajax

i'm going to ask erik to add you to the ucw group on cl.net so you can
commit directly to the repo. evrim: do you want commit rights to the
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 mb at bese.it  Tue May  9 17:10:36 2006
From: mb at bese.it (Marco Baringer)
Date: Tue, 09 May 2006 19:10:36 +0200
Subject: [Bese-devel] Re: read-from-client-string
References: <003401c672c9$a0980c70$d80a0a0a@acceleration.net>
Message-ID: <m2r7333z03.fsf@bese.it>

"Nathan Bird" <nathan at acceleration.net> writes:

> There are a number of cases of read-from-string in ucw_dev right now. Most
> of these are in form.lisp, but there are a few scattered elsewhere as well.
> Almost every case of this needs to be surrounded in let *read-eval* be nil
> block. This is so that strings being read in from the client can't be
> maliciously constructed to execute arbitrary code. 
>
> Think about someone entering as their age "#.(clsql:query "DELETE * FROM
> contacts")"... whoops!

afaicr the only places ucw needs to use read-from-string are:

1) the admin app. 'nuff said.

2) parsing numbers. we really shouldn't be using the lisp reader for
   this anyway, what we really want is just a floating point
   parser. openmcl has ccl::parse-float, i'm sure other lisps have it
   buryed somewhere. if not we could just cut 'n paste someone's
   implementation into arnesi (though i'm loath to add more code we
   have to maintain).

> What about setting this up surrounding every request? Wrap a suitably
> high-level handle-request function with a binding for *read-eval* to nil to
> help prevent that class of vulnerability to begin with.

personally it smells bad to me, i'd be happier if we didn't. if you
want it (and can understand their being situations where you do) it's
a simple as:

(defmethod ucw::service :around ((app standard-application) (context request-context))
  (let ((*read-eval* nil))
    (call-next-method)))

> In the meantime I added a read-from-client-string function to helpers.lisp
> which just does the binding and read-from-string call. Form.lisp now uses
> this. Other places that it might be appropriate is in the aserve backend
> where it is parsing headers. I didn't touch anything here since I don't have
> a working aserve to test this with.  

it's a good idea, and i'll leave it in for now, but i'd prefer
avoiding read-string entirely.

> Admin.lisp also calls read-from-string, but since the result is immediately
> being passed to eval itself, I don't think that would really help anything
> :-)

:)

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



From mb at bese.it  Tue May  9 17:14:00 2006
From: mb at bese.it (Marco Baringer)
Date: Tue, 09 May 2006 19:14:00 +0200
Subject: [Bese-devel] Re: OpenLaszlo and UCW
References: <749799F6-2F0C-4F2C-92B3-B25193AF88CF@trianet.net>
	<6251c7160605090225h6a119845r6c5c0f8d348773c9@mail.gmail.com>
	<8494C95A-CF73-463A-AA22-8F3BA3DB7973@trianet.net>
Message-ID: <m2ejz33yuf.fsf@bese.it>

Waldo Rubinstein <waldo at trianet.net> writes:

> Thomas,
>
> Well, that's the thing. So far, I've just been "playing" with OL. It is because
> I also want to combine it with UCW that I was asking. I haven't done anything
> to combine/integrate them yet, but I guess not many people have. I may just
> take a stab at it later this week, unless someone comes forward with practical
> experience or suggestions.

to the best of my knowledge (which is admitedly limited) merging UCW's
continuations and OL would require reloading the client rich interface
on every request, which defeats the point of OL. you could always use
ucw as the backend and just return XML which OL can then deal with,
but at that point why not just use araneida or tbnl? (i'd still
suggest using ucw, just because, but you're not going to take
advantage of continuations or the component UI stuff)

-- 
-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 waldo at trianet.net  Tue May  9 17:29:39 2006
From: waldo at trianet.net (Waldo Rubinstein)
Date: Tue, 9 May 2006 13:29:39 -0400
Subject: [Bese-devel] Re: OpenLaszlo and UCW
In-Reply-To: <m2ejz33yuf.fsf@bese.it>
References: <749799F6-2F0C-4F2C-92B3-B25193AF88CF@trianet.net>
	<6251c7160605090225h6a119845r6c5c0f8d348773c9@mail.gmail.com>
	<8494C95A-CF73-463A-AA22-8F3BA3DB7973@trianet.net>
	<m2ejz33yuf.fsf@bese.it>
Message-ID: <857425AB-0561-41D2-8EBE-0EDA78EA7B78@trianet.net>

Marco,

Thanks. That's what I was suspecting. Well, since my original  
intentions were to link my existing UCW app to OL, I might as well  
stick to UCW and use the XML exchange of data. I really haven't done  
it; not have I done anything but continuations in UCW, so I don't  
know how that's going to work out. I guess I will need to play with  
UCW in terms of extracting data purely through HTTP GET/POST requests  
independently of the continuation as well as posting data and  
extracting posting feedback.

Thanks,
Waldo

On May 9, 2006, at 1:14 PM, Marco Baringer wrote:

> Waldo Rubinstein <waldo at trianet.net> writes:
>
>> Thomas,
>>
>> Well, that's the thing. So far, I've just been "playing" with OL.  
>> It is because
>> I also want to combine it with UCW that I was asking. I haven't  
>> done anything
>> to combine/integrate them yet, but I guess not many people have. I  
>> may just
>> take a stab at it later this week, unless someone comes forward  
>> with practical
>> experience or suggestions.
>
> to the best of my knowledge (which is admitedly limited) merging UCW's
> continuations and OL would require reloading the client rich interface
> on every request, which defeats the point of OL. you could always use
> ucw as the backend and just return XML which OL can then deal with,
> but at that point why not just use araneida or tbnl? (i'd still
> suggest using ucw, just because, but you're not going to take
> advantage of continuations or the component UI stuff)
>
> -- 
> -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  Tue May  9 18:23:46 2006
From: drewc at tech.coop (Drew Crampsie)
Date: Tue, 09 May 2006 11:23:46 -0700
Subject: [Bese-devel] Re: read-from-client-string
In-Reply-To: <m2r7333z03.fsf@bese.it>
References: <003401c672c9$a0980c70$d80a0a0a@acceleration.net>
	<m2r7333z03.fsf@bese.it>
Message-ID: <4460DE32.8020309@tech.coop>

Marco Baringer wrote:
> afaicr the only places ucw needs to use read-from-string are:
>
> 1) the admin app. 'nuff said.
>
> 2) parsing numbers. we really shouldn't be using the lisp reader for
>    this anyway, what we really want is just a floating point
>    parser. openmcl has ccl::parse-float, i'm sure other lisps have it
>    buryed somewhere. if not we could just cut 'n paste someone's
>    implementation into arnesi (though i'm loath to add more code we
>    have to maintain).
>   
http://www.cliki.net/PARSE-NUMBER ... lets let someone else maintain it? ;)

drewc




From nathan at acceleration.net  Tue May  9 18:32:02 2006
From: nathan at acceleration.net (Nathan Bird)
Date: Tue, 9 May 2006 14:32:02 -0400
Subject: [Bese-devel] Re: Ajax
In-Reply-To: <m23bfj5dzr.fsf@bese.it>
Message-ID: <014f01c67396$de50be40$d80a0a0a@acceleration.net>

Would you mind linking these (ucw_ajax, ucw_forms, ucw_presentations)
repositories into the darcsweb?
http://uncommon-web.com/darcsweb/darcsweb.cgi

I was very happy to find http://trac.common-lisp.net/ucw/ just now, looks
like it hasn't been up for very long. Should we start using this further for
a wiki or continue to ride on top of cliki? If we want to make this more
general how do we get common-lisp.net logins? I looked through their pages a
bit, but I didn't see anything for signing onto an existing project.

>-----Original Message-----
>From: bese-devel-bounces at common-lisp.net [mailto:bese-devel-bounces at common-
>lisp.net] On Behalf Of Marco Baringer
>Sent: Tuesday, May 09, 2006 1:01 PM
>To: bese-devel at common-lisp.net
>Subject: [Bese-devel] Re: Ajax
>
>http://common-lisp.net/project/ucw/repos/ucw_ajax



From nathan at acceleration.net  Tue May  9 18:40:59 2006
From: nathan at acceleration.net (Nathan Bird)
Date: Tue, 9 May 2006 14:40:59 -0400
Subject: [Bese-devel] Re: read-from-client-string
In-Reply-To: <m2r7333z03.fsf@bese.it>
Message-ID: <016201c67398$1e2df770$d80a0a0a@acceleration.net>



>-----Original Message-----
>From: bese-devel-bounces at common-lisp.net [mailto:bese-devel-bounces at common-
>lisp.net] On Behalf Of Marco Baringer
>Sent: Tuesday, May 09, 2006 1:11 PM
>To: bese-devel at common-lisp.net
>Subject: [Bese-devel] Re: read-from-client-string
>
> [...]
>afaicr the only places ucw needs to use read-from-string are:
>
>1) the admin app. 'nuff said.
>
>2) parsing numbers. we really shouldn't be using the lisp reader for
>   this anyway, what we really want is just a floating point
>   parser. openmcl has ccl::parse-float, i'm sure other lisps have it
>   buryed somewhere. if not we could just cut 'n paste someone's
>   implementation into arnesi (though i'm loath to add more code we
>   have to maintain).

Yeah, that's pretty much the case, I had been using read in the forms number
parsing because that's how I saw someone else do it at some point. :-)

The aserve backend also has this in there a couple of times:
(read-from-string (format nil ":~A" header-name))
I take it this is just trying to get keyword symbols out of strings? Would a
better fix for that be using intern instead?

>> What about setting this up surrounding every request? Wrap a suitably
>> high-level handle-request function with a binding for *read-eval* to nil
>to
>> help prevent that class of vulnerability to begin with.
>
>personally it smells bad to me, i'd be happier if we didn't. [...]

Yeah, it does smell a bit, I'm just thinking if there are reads in there,
might be better to have that check on. That might just be false security
though.



From drewc at tech.coop  Tue May  9 19:15:11 2006
From: drewc at tech.coop (Drew Crampsie)
Date: Tue, 09 May 2006 12:15:11 -0700
Subject: [Bese-devel] simple submit sans javascript.
In-Reply-To: <m23bfj5dzr.fsf@bese.it>
References: <445F17AC.5000901@core.gen.tr>
	<b54b34af0605080815m11d2470dq674705c85b01e42f@mail.gmail.com>
	<m23bfj5dzr.fsf@bese.it>
Message-ID: <4460EA3F.6080603@tech.coop>

Imagine my surprise when, after updating to ucw_dev, ALL my application 
stopped working!

The culprit? forms now require dojo to work. I like dojo as much as the 
next guy, but i rarely initially develop in an environment where it is 
available.

To tell you the truth, i've never much liked the fact that forms used 
Javascript to begin with, but lived with it until now :)

anyways, patchy patchy applied to ucw_public and attached. Personally, i 
think that SIMPLE-FORMS should become the default, and the complex, 
bulky, page-bloating javascript producing forms should be used only if 
the user specifically wants them.

Thoughts?

drewc

Sun May 7 00:36:02 BST 2006 Drew Crampsie <drewc at tech.coop>
* Add a <ucw:simple-submit and <ucw:simple-form that do not require 
javascript.

<ucw:simple-submit uses a BUTTON tag to render a submit button that does 
not require javascript

To make this happen, i added a method to find-action that operates on a 
list,
grabbing the car and using it as the action id. When a form is submitted 
with an extra action parameter,
the last one submitted (first in the list) is taken to be the action-id.

This allows forms without javascript!! SIMPLE-SUBMIT will work in the 
standard UCW:FORM,
SIMPLE-FORM is a form without the JS cruft, but will not work with 
standard <UCW:* submit buttons.



-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: simple-forms
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060509/b646bb7e/attachment.ksh>

From waldo at trianet.net  Tue May  9 19:48:17 2006
From: waldo at trianet.net (Waldo Rubinstein)
Date: Tue, 9 May 2006 15:48:17 -0400
Subject: [Bese-devel] simple submit sans javascript.
In-Reply-To: <4460EA3F.6080603@tech.coop>
References: <445F17AC.5000901@core.gen.tr>
	<b54b34af0605080815m11d2470dq674705c85b01e42f@mail.gmail.com>
	<m23bfj5dzr.fsf@bese.it> <4460EA3F.6080603@tech.coop>
Message-ID: <AD2DDF43-8221-44E7-9E9C-670696DC137D@trianet.net>

I think that the exploitation of Ajax all over the place are spoiling  
the users, who after much work, time, and effort, finally accepted  
the way browser-based apps worked compared to fat client-server apps.

Now that Ajax has hit the streets and has shown the users how it can  
disguise the back and forth of the usual browser-based interaction  
with something more seamless, is just forcing everything to the  
"pages bloated with javascript".

At least this has been my experience with my customers. I don't  
develop for public users. All my applications are for internal  
purposes, intranet-like apps. So that "fat client-server"-like  
experience is not only appreciated, but now is being demanded.

I haven't done much work with Dojo, simply because I started using  
Prototype (with rails). Now that I'm developing more with UCW I am  
appreciating more Dojo and, regardless of what everyone says, I like  
it. It may not be as easy as prototype at first, but it is certainly  
very powerful and better organized.

I don't see the "big deal" in requiring it in UCW apps. Once of the  
things about Dojo compared to the rest is it's packaging system which  
will let you minimize the initial amount of javascript hat you need  
to load and then just load what you need more if you have to.

- Waldo

On May 9, 2006, at 3:15 PM, Drew Crampsie wrote:

> Imagine my surprise when, after updating to ucw_dev, ALL my  
> application stopped working!
>
> The culprit? forms now require dojo to work. I like dojo as much as  
> the next guy, but i rarely initially develop in an environment  
> where it is available.
>
> To tell you the truth, i've never much liked the fact that forms  
> used Javascript to begin with, but lived with it until now :)
>
> anyways, patchy patchy applied to ucw_public and attached.  
> Personally, i think that SIMPLE-FORMS should become the default,  
> and the complex, bulky, page-bloating javascript producing forms  
> should be used only if the user specifically wants them.
>
> Thoughts?
>
> drewc
>
> Sun May 7 00:36:02 BST 2006 Drew Crampsie <drewc at tech.coop>
> * Add a <ucw:simple-submit and <ucw:simple-form that do not require  
> javascript.
>
> <ucw:simple-submit uses a BUTTON tag to render a submit button that  
> does not require javascript
>
> To make this happen, i added a method to find-action that operates  
> on a list,
> grabbing the car and using it as the action id. When a form is  
> submitted with an extra action parameter,
> the last one submitted (first in the list) is taken to be the  
> action-id.
>
> This allows forms without javascript!! SIMPLE-SUBMIT will work in  
> the standard UCW:FORM,
> SIMPLE-FORM is a form without the JS cruft, but will not work with  
> standard <UCW:* submit buttons.
>
>
>
>
> New patches:
>
> [Add a <ucw:simple-submit and <ucw:simple-form that do not require  
> javascript.
> Drew Crampsie <drewc at tech.coop>**20060506233602
>
>  <ucw:simple-submit uses a BUTTON tag to render a submit button  
> that does not require javascript
>
>  To make this happen, i added a method to find-action that operates  
> on a list,
>  grabbing the car and using it as the action id. When a form is  
> submitted with an extra action parameter,
>  the last one submitted (first in the list) is taken to be the  
> action-id.
>
>  This allows forms without javascript!! SIMPLE-SUBMIT will work in  
> the standard UCW:FORM,
>  SIMPLE-FORM is a form without the JS cruft, but will not work with  
> standard <UCW:* submit buttons.
>
>
>
> ] {
> hunk ./src/packages.lisp 317
> +   #:simple-form
> +   #:simple-submit
> hunk ./src/rerl/standard-session-frame.lisp 12
> +
> +(defmethod find-action ((f standard-session-frame) (action-id list))
> +  (find-action f (car action-id)))
> +
> +(defmethod (setf find-action) (lambda (f standard-session-frame)  
> (action-id string))
> +  (setf (gethash action-id (frame.actions f))
> +	lambda))
> hunk ./src/yaclml/ucw-tags.lisp 39
> +(deftag-macro <ucw:simple-form (&attribute (id '(js:gen-js-name- 
> string :prefix "ucw-form"))
> +					    action
> +					    &allow-other-attributes others
> +					    &body body)
> +  "A Simple form tag, made for use with SIMPLE-SUBMIT. Does not  
> require javascript."
> +  (with-unique-names (url query action-id)
> +    (rebinding (id)
> +      `(let* ((,action-id (make-new-action (context.current-frame  
> *context*)
> +					   (lambda () (with-call/cc ,action))))
> +              (,url (compute-url *current-component*
> +                                 :action-id ,action-id)))
> +         (<:form :action (print-uri-to-string-sans-query ,url)
> +                 , at others
> +		 (dolist (,query (uri.query ,url))
> +		   (if (string= ,+action-parameter-name+ (car ,query))
> +		       (<:input :type "hidden" :name ,+action-parameter-name+
> +				:value (when ,action (cdr ,query))
> +				:id ,action-id)
> +		       (<:input :type "hidden" :name (car ,query) :value  
> (cdr ,query))))
> +		 , at body)))))
> +
> +(deftag-macro <ucw:simple-submit (&attribute action &allow-other- 
> attributes others &body body)
> +  "Presents an button tag which executes ACTION when clicked."
> +  `(<:button :type "submit"
> +	     :name +action-parameter-name+
> +	     :value (make-new-action (context.current-frame *context*)
> +				     (lambda () (with-call/cc ,action)))
> +	     , at others , at body))
> +
> +
> }
>
> Context:
>
> [Added send-redirect function.
> Marco Baringer <mb at bese.it>**20060501154250
>
>  send-redirect does what redirect-component's render method did but
>  it's usable from a simple-dispatcher (or anywhere else we don't have
>  ucw's component context machinery).
> ]
> [Use dolist*, not dolist, in tabbed-pane's render method.
> Marco Baringer <mb at bese.it>**20060501135314]
> [Using (when (whatever) T) is weird, use (whatever) instead
> Marco Baringer <mb at bese.it>**20060501135000]
> [Minor indentation/whitespace fixups in src/components/form.lisp
> Marco Baringer <mb at bese.it>**20060501134849]
> [make-with-dummy-request-nicer
> cjstuij at gmail.com**20060501001756]
> [tabbed-pane-makeover - tabbed panes are now wrapped in divs in  
> stead of a table, for more design flexibility. Is no longer tied to  
> a tal file.
> cjstuij at gmail.com**20060430233920]
> [Removing integer-range-validator, use number-range-validator instead.
> Nathan Bird <nathan at acceleration.net>**20060428165829]
> [the value of a number-field should be nil, not 0, if nothing was  
> entered.
> Nathan Bird <nathan at acceleration.net>**20060428164949]
> [bin/ucwctl: allow a custom ucwctl.conf via -u|--ucwctl-file
> Luca Capello <luca at pca.it>**20060501110031
>
>  This adds the possibility to specify a different ucwctl.conf file
>  instead of the default /etc/ucw/ucwctl.conf.  Moreover, by default
>  ucwctl now reads ~/.ucw/ucwctl.conf it it exists, overriding the
>  values in the general /etc/ucw/ucwctl.conf, and the same happens if
>  the ucwctl.conf is specified via the command line option.  All  
> command
>  line options override the values present in any ucwctl.conf files.
>  The order is the following:
>
>    1) /etc/ucw/ucwctl.conf (if it exists)
>    2) ~/.ucw/ucwctl.conf (if it exists)
>    3) -u|--ucwctl-file (if specified, exit if it cannot be read)
>    4) command line options
>
>  A deeper discussion is available at:
>
>    http://common-lisp.net/pipermail/bese-devel/2006-April/001932.html
>    http://common-lisp.net/pipermail/bese-devel/2006-April/001961.html
> ]
> [In the phone and email validators instead of defining a new slot  
> we just use the :default-initargs class option
> Marco Baringer <mb at bese.it>**20060428103114]
> [Adding documentation to form.lisp
> Nathan Bird <nathan at acceleration.net>**20060428023256]
> [Rearranging file contents to reduce style-warnings
> Nathan Bird <nathan at acceleration.net>**20060428022511]
> [Implementing value-validators
> Nathan Bird <nathan at acceleration.net>**20060428020403
>  Value-validators are a category of validators that are only  
> applied if there
>  is actually a value. This was done to provide a more systematic  
> scheme since
>  there were several different ways it was being handled previously.
>  Javascript validation in this patch is untested.
> ]
> [Expanded the forms example to include a number-field and number- 
> range-validated field.
> Nathan Bird <nathan at acceleration.net>**20060428014551]
> [added a standard regular exprexpression validator then made e-mail- 
> validator use it.  E-mail-validator IS NO LONGER INVALID IF EMPTY.  
> Adde d an international phonenumber validator
> russ at acceleration.net**20060425154947]
> [added regex exports
> russ at acceleration.net**20060424225714]
> [Comment fixup
> Nathan Bird <nathan at acceleration.net>**20060427173259]
> [Added missing id param that got lost in my <ucw:form changes
> attila.lendvai at gmail.com**20060424150549]
> [TAG 2006-04-25
> Marco Baringer <mb at bese.it>**20060425145623]
> Patch bundle hash:
> 35fa34a9ac934fdd8cafa9b7992c7e5aaf03ab8a
> _______________________________________________
> 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  Tue May  9 19:47:23 2006
From: drewc at tech.coop (Drew Crampsie)
Date: Tue, 09 May 2006 12:47:23 -0700
Subject: [Bese-devel] UCW submit action issues
In-Reply-To: <20060502184323.GA9199@tngtech.com>
References: <20060501132828.GA9899@tngtech.com>
	<20060502113956.GA24863@rabbit.loc> <20060502184323.GA9199@tngtech.com>
Message-ID: <4460F1CB.4070500@tech.coop>

Christian Haselbach wrote:
> On Tue, May 02, 2006 at 03:39:56PM +0400, Alexey Antipov wrote:
>   
>> Please check that dojo.js used, i.e. you have
>> something like <script type="text/javascript" src="dojo/dojo.js"?>
>> and its really loaded.
>>     
>
> No, it is not loaded. This probably explains why it does not work even
> with javascript. However, my key question was whether it is possible
> to have this working without javascript in ucw.
>   
It is now, see my latest patch in ucw_public. I never liked requireing 
JS for forms either, and the latest switch to requiring DOJO was enough 
to motivate me to do something about it :)

drewc
> Regards,
> Christian
> _______________________________________________
> bese-devel mailing list
> bese-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel
>   



From waldo at trianet.net  Tue May  9 19:55:36 2006
From: waldo at trianet.net (Waldo Rubinstein)
Date: Tue, 9 May 2006 15:55:36 -0400
Subject: [Bese-devel] simple submit sans javascript.
In-Reply-To: <9EA93CE5-5DC4-4FEB-938E-36441F7B19E2@user.net>
References: <445F17AC.5000901@core.gen.tr>
	<b54b34af0605080815m11d2470dq674705c85b01e42f@mail.gmail.com>
	<m23bfj5dzr.fsf@bese.it> <4460EA3F.6080603@tech.coop>
	<AD2DDF43-8221-44E7-9E9C-670696DC137D@trianet.net>
	<9EA93CE5-5DC4-4FEB-938E-36441F7B19E2@user.net>
Message-ID: <8AED5162-CF37-4884-8EBE-861752E985AC@trianet.net>

I did it again :)

Apologies about that. I'm using my friends computer and I'm not used  
to his keyboard. Anyway, he's gonna kill me for posting under his  
name and publishing all his contact info :)

- Waldo

On May 9, 2006, at 3:52 PM, Daniel Salama wrote:

> My goodness,
>
> I never knew I could type with so many typos and grammatical errors  
> in such a short passage :) My apologies.
>
> - Waldo
>
> On May 9, 2006, at 3:48 PM, Waldo Rubinstein wrote:
>
>> I think that the exploitation of Ajax all over the place are  
>> spoiling the users, who after much work, time, and effort, finally  
>> accepted the way browser-based apps worked compared to fat client- 
>> server apps.
>>
>> Now that Ajax has hit the streets and has shown the users how it  
>> can disguise the back and forth of the usual browser-based  
>> interaction with something more seamless, is just forcing  
>> everything to the "pages bloated with javascript".
>>
>> At least this has been my experience with my customers. I don't  
>> develop for public users. All my applications are for internal  
>> purposes, intranet-like apps. So that "fat client-server"-like  
>> experience is not only appreciated, but now is being demanded.
>>
>> I haven't done much work with Dojo, simply because I started using  
>> Prototype (with rails). Now that I'm developing more with UCW I am  
>> appreciating more Dojo and, regardless of what everyone says, I  
>> like it. It may not be as easy as prototype at first, but it is  
>> certainly very powerful and better organized.
>>
>> I don't see the "big deal" in requiring it in UCW apps. Once of  
>> the things about Dojo compared to the rest is it's packaging  
>> system which will let you minimize the initial amount of  
>> javascript hat you need to load and then just load what you need  
>> more if you have to.
>>
>> - Waldo
>>
>> On May 9, 2006, at 3:15 PM, Drew Crampsie wrote:
>>
>>> Imagine my surprise when, after updating to ucw_dev, ALL my  
>>> application stopped working!
>>>
>>> The culprit? forms now require dojo to work. I like dojo as much  
>>> as the next guy, but i rarely initially develop in an environment  
>>> where it is available.
>>>
>>> To tell you the truth, i've never much liked the fact that forms  
>>> used Javascript to begin with, but lived with it until now :)
>>>
>>> anyways, patchy patchy applied to ucw_public and attached.  
>>> Personally, i think that SIMPLE-FORMS should become the default,  
>>> and the complex, bulky, page-bloating javascript producing forms  
>>> should be used only if the user specifically wants them.
>>>
>>> Thoughts?
>>>
>>> drewc



From cjstuij at gmail.com  Tue May  9 20:06:37 2006
From: cjstuij at gmail.com (Ties Stuij)
Date: Tue, 9 May 2006 22:06:37 +0200
Subject: [Bese-devel] simple submit sans javascript.
In-Reply-To: <8AED5162-CF37-4884-8EBE-861752E985AC@trianet.net>
References: <445F17AC.5000901@core.gen.tr>
	<b54b34af0605080815m11d2470dq674705c85b01e42f@mail.gmail.com>
	<m23bfj5dzr.fsf@bese.it> <4460EA3F.6080603@tech.coop>
	<AD2DDF43-8221-44E7-9E9C-670696DC137D@trianet.net>
	<9EA93CE5-5DC4-4FEB-938E-36441F7B19E2@user.net>
	<8AED5162-CF37-4884-8EBE-861752E985AC@trianet.net>
Message-ID: <d7ce4ebf0605091306g17e0593em96d5bbca6119de40@mail.gmail.com>

On May 9, 2006, at 3:15 PM, Drew Crampsie wrote:
> Thoughts?

different strokes for different folks.
me likes. (as an infrequent elinks gmailer)

greets,
Ties


From attila.lendvai at gmail.com  Tue May  9 21:27:11 2006
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Tue, 9 May 2006 23:27:11 +0200
Subject: [Bese-devel] simple submit sans javascript.
In-Reply-To: <AD2DDF43-8221-44E7-9E9C-670696DC137D@trianet.net>
References: <445F17AC.5000901@core.gen.tr>
	<b54b34af0605080815m11d2470dq674705c85b01e42f@mail.gmail.com>
	<m23bfj5dzr.fsf@bese.it> <4460EA3F.6080603@tech.coop>
	<AD2DDF43-8221-44E7-9E9C-670696DC137D@trianet.net>
Message-ID: <b54b34af0605091427l5b37708eob8a854648edef31f@mail.gmail.com>

> I don't see the "big deal" in requiring it in UCW apps. Once of the
> things about Dojo compared to the rest is it's packaging system which
> will let you minimize the initial amount of javascript hat you need
> to load and then just load what you need more if you have to.

it's a me too here, but...

for me it seems like ucw is some kind of middle ground. it's stops
being super simple on the rendering ground (as plain html tags and no
js), but it's api is not yet a fully component based one where you
don't even have to use yaclml tags anymore.

btw, why do people dislike js? and be prepared, there is that new ajax
branch now... ;)

but anyway, it would be cool to have two levels of api for ucw: one
with the simple yaclml html stuff some people seem to require and one
with the "bloatware" which is much more easier to use, gives features
for free and some others tend to like... :)

i don't really have a worked out idea, but i would like to use a full
component based interface that is well integrated and where i don't
have to care about the details of how a form is submitted and even
when a form is generated at all!

- attila

(alias 101 on irc &no 'its not lisp code :)

From chriss at muon.de  Tue May  9 22:07:01 2006
From: chriss at muon.de (Christian Haselbach)
Date: Wed, 10 May 2006 00:07:01 +0200
Subject: [Bese-devel] simple submit sans javascript.
In-Reply-To: <b54b34af0605091427l5b37708eob8a854648edef31f@mail.gmail.com>
References: <445F17AC.5000901@core.gen.tr>
	<b54b34af0605080815m11d2470dq674705c85b01e42f@mail.gmail.com>
	<m23bfj5dzr.fsf@bese.it> <4460EA3F.6080603@tech.coop>
	<AD2DDF43-8221-44E7-9E9C-670696DC137D@trianet.net>
	<b54b34af0605091427l5b37708eob8a854648edef31f@mail.gmail.com>
Message-ID: <20060509220701.GA10132@tngtech.com>

On Tue, May 09, 2006 at 11:27:11PM +0200, Attila Lendvai wrote:
> btw, why do people dislike js? and be prepared, there is that new ajax
> branch now... ;)

I don't dislike js, but I want webapps to be usable without. It makes
them more accessible. With every requirement on the client side, you
lock out some people. Javascript on the client side cannot always be
taken for granted. For example, there have been security issues with js
in IE and Mozille where users have been advises to turn javascript off.

Hence, I think it is very good that the button's action association
works without javascript.

Regards,
Christian


From drewc at tech.coop  Tue May  9 22:19:27 2006
From: drewc at tech.coop (Drew Crampsie)
Date: Tue, 09 May 2006 15:19:27 -0700
Subject: [Fwd: Re: [Bese-devel] simple submit sans javascript.]
Message-ID: <4461156F.7000704@tech.coop>


Waldo Rubinstein wrote:
> I think that the exploitation of Ajax all over the place are spoiling 
> the users, who after much work, time, and effort, finally accepted the 
> way browser-based apps worked compared to fat client-server apps.
>
> Now that Ajax has hit the streets and has shown the users how it can 
> disguise the back and forth of the usual browser-based interaction 
> with something more seamless, is just forcing everything to the "pages 
> bloated with javascript".

I agree with this, and use Dojo extensively. But in the case of 
submitting a form, the page reload happens anyway, and the existing 
scheme does, in fact, make it harder to use ajax in certain cases,.

if you look closely at the patch, it changes the way the action 
parameter is processed in the case of multiple inputs. This actually 
makes it easier to use UCW with ajax (at least the way i do it) be 
letting me submit a form from the page, but call a different action 
simply by appending the correct parameter.

Also, there is the accessibility  argument, and the personal pain i 
remember when using Linux 10 years before everybody else.. alternate 
browsers and all that.

>
>
> At least this has been my experience with my customers. I don't 
> develop for public users. All my applications are for internal 
> purposes, intranet-like apps. So that "fat client-server"-like 
> experience is not only appreciated, but now is being demanded.

I didn't say anything about throwing away the baby with the bathwater 
:). I use Dojo a lot.. but never simply to submit a form. I also have an 
application that uses prototype, and an older version at that. loading 
Dojo clobbers it. i try to keep these things up to date with the latest 
ucw, as hard as that is.
>
>
> I don't see the "big deal" in requiring it in UCW apps. Once of the 
> things about Dojo compared to the rest is it's packaging system which 
> will let you minimize the initial amount of javascript hat you need to 
> load and then just load what you need more if you have to.
Dojo is great, so is lynx, cell-phone browsers, etc etc. Why require 
something that is not needed, and breaks in some environments?

just my $0.02CAD

drewc
>
>
> - Waldo
>
> On May 9, 2006, at 3:15 PM, Drew Crampsie wrote:
>
>> Imagine my surprise when, after updating to ucw_dev, ALL my 
>> application stopped working!
>>
>> The culprit? forms now require dojo to work. I like dojo as much as 
>> the next guy, but i rarely initially develop in an environment where 
>> it is available.
>>
>> To tell you the truth, i've never much liked the fact that forms used 
>> Javascript to begin with, but lived with it until now :)
>>
>> anyways, patchy patchy applied to ucw_public and attached. 
>> Personally, i think that SIMPLE-FORMS should become the default, and 
>> the complex, bulky, page-bloating javascript producing forms should 
>> be used only if the user specifically wants them.
>>
>> Thoughts?
>>
>> drewc
>>
>> Sun May 7 00:36:02 BST 2006 Drew Crampsie <drewc at tech.coop>
>> * Add a <ucw:simple-submit and <ucw:simple-form that do not require 
>> javascript.
>>
>> <ucw:simple-submit uses a BUTTON tag to render a submit button that 
>> does not require javascript
>>
>> To make this happen, i added a method to find-action that operates on 
>> a list,
>> grabbing the car and using it as the action id. When a form is 
>> submitted with an extra action parameter,
>> the last one submitted (first in the list) is taken to be the action-id.
>>
>> This allows forms without javascript!! SIMPLE-SUBMIT will work in the 
>> standard UCW:FORM,
>> SIMPLE-FORM is a form without the JS cruft, but will not work with 
>> standard <UCW:* submit buttons.
>>
>>
>>
>>
>> New patches:
>>
>> [Add a <ucw:simple-submit and <ucw:simple-form that do not require 
>> javascript.
>> Drew Crampsie <drewc at tech.coop>**20060506233602
>>
>>  <ucw:simple-submit uses a BUTTON tag to render a submit button that 
>> does not require javascript
>>
>>  To make this happen, i added a method to find-action that operates 
>> on a list,
>>  grabbing the car and using it as the action id. When a form is 
>> submitted with an extra action parameter,
>>  the last one submitted (first in the list) is taken to be the 
>> action-id.
>>
>>  This allows forms without javascript!! SIMPLE-SUBMIT will work in 
>> the standard UCW:FORM,
>>  SIMPLE-FORM is a form without the JS cruft, but will not work with 
>> standard <UCW:* submit buttons.
>>
>>
>>
>> ] {
>> hunk ./src/packages.lisp 317
>> +   #:simple-form
>> +   #:simple-submit
>> hunk ./src/rerl/standard-session-frame.lisp 12
>> +
>> +(defmethod find-action ((f standard-session-frame) (action-id list))
>> +  (find-action f (car action-id)))
>> +
>> +(defmethod (setf find-action) (lambda (f standard-session-frame) 
>> (action-id string))
>> +  (setf (gethash action-id (frame.actions f))
>> +    lambda))
>> hunk ./src/yaclml/ucw-tags.lisp 39
>> +(deftag-macro <ucw:simple-form (&attribute (id 
>> '(js:gen-js-name-string :prefix "ucw-form"))
>> +                        action
>> +                        &allow-other-attributes others
>> +                        &body body)
>> +  "A Simple form tag, made for use with SIMPLE-SUBMIT. Does not 
>> require javascript."
>> +  (with-unique-names (url query action-id)
>> +    (rebinding (id)
>> +      `(let* ((,action-id (make-new-action (context.current-frame 
>> *context*)
>> +                       (lambda () (with-call/cc ,action))))
>> +              (,url (compute-url *current-component*
>> +                                 :action-id ,action-id)))
>> +         (<:form :action (print-uri-to-string-sans-query ,url)
>> +                 , at others
>> +         (dolist (,query (uri.query ,url))
>> +           (if (string= ,+action-parameter-name+ (car ,query))
>> +               (<:input :type "hidden" :name ,+action-parameter-name+
>> +                :value (when ,action (cdr ,query))
>> +                :id ,action-id)
>> +               (<:input :type "hidden" :name (car ,query) :value 
>> (cdr ,query))))
>> +         , at body)))))
>> +
>> +(deftag-macro <ucw:simple-submit (&attribute action 
>> &allow-other-attributes others &body body)
>> +  "Presents an button tag which executes ACTION when clicked."
>> +  `(<:button :type "submit"
>> +         :name +action-parameter-name+
>> +         :value (make-new-action (context.current-frame *context*)
>> +                     (lambda () (with-call/cc ,action)))
>> +         , at others , at body))
>> +
>> +
>> }
>>
>> Context:
>>
>> [Added send-redirect function.
>> Marco Baringer <mb at bese.it>**20060501154250
>>
>>  send-redirect does what redirect-component's render method did but
>>  it's usable from a simple-dispatcher (or anywhere else we don't have
>>  ucw's component context machinery).
>> ]
>> [Use dolist*, not dolist, in tabbed-pane's render method.
>> Marco Baringer <mb at bese.it>**20060501135314]
>> [Using (when (whatever) T) is weird, use (whatever) instead
>> Marco Baringer <mb at bese.it>**20060501135000]
>> [Minor indentation/whitespace fixups in src/components/form.lisp
>> Marco Baringer <mb at bese.it>**20060501134849]
>> [make-with-dummy-request-nicer
>> cjstuij at gmail.com**20060501001756]
>> [tabbed-pane-makeover - tabbed panes are now wrapped in divs in stead 
>> of a table, for more design flexibility. Is no longer tied to a tal 
>> file.
>> cjstuij at gmail.com**20060430233920]
>> [Removing integer-range-validator, use number-range-validator instead.
>> Nathan Bird <nathan at acceleration.net>**20060428165829]
>> [the value of a number-field should be nil, not 0, if nothing was 
>> entered.
>> Nathan Bird <nathan at acceleration.net>**20060428164949]
>> [bin/ucwctl: allow a custom ucwctl.conf via -u|--ucwctl-file
>> Luca Capello <luca at pca.it>**20060501110031
>>
>>  This adds the possibility to specify a different ucwctl.conf file
>>  instead of the default /etc/ucw/ucwctl.conf.  Moreover, by default
>>  ucwctl now reads ~/.ucw/ucwctl.conf it it exists, overriding the
>>  values in the general /etc/ucw/ucwctl.conf, and the same happens if
>>  the ucwctl.conf is specified via the command line option.  All command
>>  line options override the values present in any ucwctl.conf files.
>>  The order is the following:
>>
>>    1) /etc/ucw/ucwctl.conf (if it exists)
>>    2) ~/.ucw/ucwctl.conf (if it exists)
>>    3) -u|--ucwctl-file (if specified, exit if it cannot be read)
>>    4) command line options
>>
>>  A deeper discussion is available at:
>>
>>    http://common-lisp.net/pipermail/bese-devel/2006-April/001932.html
>>    http://common-lisp.net/pipermail/bese-devel/2006-April/001961.html
>> ]
>> [In the phone and email validators instead of defining a new slot we 
>> just use the :default-initargs class option
>> Marco Baringer <mb at bese.it>**20060428103114]
>> [Adding documentation to form.lisp
>> Nathan Bird <nathan at acceleration.net>**20060428023256]
>> [Rearranging file contents to reduce style-warnings
>> Nathan Bird <nathan at acceleration.net>**20060428022511]
>> [Implementing value-validators
>> Nathan Bird <nathan at acceleration.net>**20060428020403
>>  Value-validators are a category of validators that are only applied 
>> if there
>>  is actually a value. This was done to provide a more systematic 
>> scheme since
>>  there were several different ways it was being handled previously.
>>  Javascript validation in this patch is untested.
>> ]
>> [Expanded the forms example to include a number-field and 
>> number-range-validated field.
>> Nathan Bird <nathan at acceleration.net>**20060428014551]
>> [added a standard regular exprexpression validator then made 
>> e-mail-validator use it.  E-mail-validator IS NO LONGER INVALID IF 
>> EMPTY. Adde d an international phonenumber validator
>> russ at acceleration.net**20060425154947]
>> [added regex exports
>> russ at acceleration.net**20060424225714]
>> [Comment fixup
>> Nathan Bird <nathan at acceleration.net>**20060427173259]
>> [Added missing id param that got lost in my <ucw:form changes
>> attila.lendvai at gmail.com**20060424150549]
>> [TAG 2006-04-25
>> Marco Baringer <mb at bese.it>**20060425145623]
>> Patch bundle hash:
>> 35fa34a9ac934fdd8cafa9b7992c7e5aaf03ab8a
>> _______________________________________________
>> bese-devel mailing list
>> bese-devel at common-lisp.net
>> http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel
>




From waldo at trianet.net  Tue May  9 22:33:26 2006
From: waldo at trianet.net (Waldo Rubinstein)
Date: Tue, 9 May 2006 18:33:26 -0400
Subject: [Fwd: Re: [Bese-devel] simple submit sans javascript.]
In-Reply-To: <4461156F.7000704@tech.coop>
References: <4461156F.7000704@tech.coop>
Message-ID: <D088ED10-9DAC-432E-B3E6-C0F1EBB8B7CF@trianet.net>

I didn't meant to criticize your patch. As a matter of fact, I  
haven't even had time to look at it, but based on your comments (and  
glancing at the patch), I agree with what you've done. I was just  
commenting on your general comments regarding the use of JS.

Yes, I agree with you (and Christian and the others) that in general,  
forms shouldn't require JS in order to submit or operate. I never  
_just_ rely on JS for my forms (neither submissions nor validation).  
However, form submission using Ajax is also nice. The simplest  
example I can provide is http://www.ajaxscaffold.com/ 
associations_demo/ (I apologize for polluting this list with RoR  
stuff). Just play with the actions of the People or the Pets list.

One last pollution suggestion is the way RoR encapsulates Prototype  
by checking if JS is enabled and automatically using Ajax. Otherwise,  
it uses simple form submissions. This is hidden from the developer by  
providing macro-like calls (AKA form helpers) to the Prototype  
library, so the developer is hardly ever working with Prototype  
directly.

- Waldo

On May 9, 2006, at 6:19 PM, Drew Crampsie wrote:

>
> Waldo Rubinstein wrote:
>> I think that the exploitation of Ajax all over the place are  
>> spoiling the users, who after much work, time, and effort, finally  
>> accepted the way browser-based apps worked compared to fat client- 
>> server apps.
>>
>> Now that Ajax has hit the streets and has shown the users how it  
>> can disguise the back and forth of the usual browser-based  
>> interaction with something more seamless, is just forcing  
>> everything to the "pages bloated with javascript".
>
> I agree with this, and use Dojo extensively. But in the case of  
> submitting a form, the page reload happens anyway, and the existing  
> scheme does, in fact, make it harder to use ajax in certain cases,.
>
> if you look closely at the patch, it changes the way the action  
> parameter is processed in the case of multiple inputs. This  
> actually makes it easier to use UCW with ajax (at least the way i  
> do it) be letting me submit a form from the page, but call a  
> different action simply by appending the correct parameter.
>
> Also, there is the accessibility  argument, and the personal pain i  
> remember when using Linux 10 years before everybody else..  
> alternate browsers and all that.
>
>>
>>
>> At least this has been my experience with my customers. I don't  
>> develop for public users. All my applications are for internal  
>> purposes, intranet-like apps. So that "fat client-server"-like  
>> experience is not only appreciated, but now is being demanded.
>
> I didn't say anything about throwing away the baby with the  
> bathwater :). I use Dojo a lot.. but never simply to submit a form.  
> I also have an application that uses prototype, and an older  
> version at that. loading Dojo clobbers it. i try to keep these  
> things up to date with the latest ucw, as hard as that is.
>>
>>
>> I don't see the "big deal" in requiring it in UCW apps. Once of  
>> the things about Dojo compared to the rest is it's packaging  
>> system which will let you minimize the initial amount of  
>> javascript hat you need to load and then just load what you need  
>> more if you have to.
> Dojo is great, so is lynx, cell-phone browsers, etc etc. Why  
> require something that is not needed, and breaks in some environments?
>
> just my $0.02CAD
>
> drewc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060509/565b21eb/attachment.html>

From maciekp at japhy.fnord.org  Tue May  9 23:05:47 2006
From: maciekp at japhy.fnord.org (Maciek Pasternacki)
Date: Wed, 10 May 2006 01:05:47 +0200
Subject: [Bese-devel] simple submit sans javascript.
In-Reply-To: <4460EA3F.6080603@tech.coop> (Drew Crampsie's message of "Tue, 09
	May 2006 12:15:11 -0700")
References: <445F17AC.5000901@core.gen.tr>
	<b54b34af0605080815m11d2470dq674705c85b01e42f@mail.gmail.com>
	<m23bfj5dzr.fsf@bese.it> <4460EA3F.6080603@tech.coop>
Message-ID: <87fyjiajec.fsf@lizard.king>

On Prickle-Prickle, Discord 56, 3172 YOLD, Drew Crampsie wrote:

> Imagine my surprise when, after updating to ucw_dev, ALL my
> application stopped working!
>
> The culprit? forms now require dojo to work. I like dojo as much as
> the next guy, but i rarely initially develop in an environment where
> it is available.

I was struggling with it myself at the moment, considering if the
Right Way for my app would be to use dojo or roll some simpler form
stuff.

> To tell you the truth, i've never much liked the fact that forms used
> Javascript to begin with, but lived with it until now :)

Neither did I, IMHO JS should be used only when necessary.

> anyways, patchy patchy applied to ucw_public and attached. Personally,
> i think that SIMPLE-FORMS should become the default, and the complex,
> bulky, page-bloating javascript producing forms should be used only if
> the user specifically wants them.
>
> Thoughts?

Great!  Applied, I'll play with it some more tomorrow and decide if I
will use it, or stick with dojo.  One way or the other, it is good to
have some way to avoid using JS in ucw apps.

-- 
__    Maciek Pasternacki <maciekp at japhy.fnord.org> [ http://japhy.fnord.org/ ]
`| _   |_\  / { ...to keep from dying is not the same as ``to live''. }
,|{-}|}| }\/
\/   |____/                                            ( Frank Herbert )  -><-


From mbaringer at common-lisp.net  Wed May 10 04:00:07 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Wed, 10 May 2006 00:00:07 -0400 (EDT)
Subject: [Bese-devel] New patches to arnesi_dev:  9-May-2006
Message-ID: <20060510040007.732F24507B@common-lisp.net>


Tue May  9 10:52:23 EDT 2006  Marco Baringer <mb at bese.it>
  * implement walker for eval-when

    M ./src/walk.lisp -2 +5

Tue May  9 10:44:10 EDT 2006  Marco Baringer <mb at bese.it>
  * Change defclss-struct to allow class-options

    M ./src/defclass-struct.lisp -7 +11


An updated tarball of arnesi_dev's source can be downloaded here:
http://common-lisp.net/project/bese/tarballs/arnesi_dev-20060509.tar.gz

Darcsweb URL:
http://uncommon-web.com/darcsweb/darcsweb.cgi?r=arnesi_dev;a=summary


From mbaringer at common-lisp.net  Wed May 10 04:20:02 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Wed, 10 May 2006 00:20:02 -0400 (EDT)
Subject: [Bese-devel] New patches to parenscript:  9-May-2006
Message-ID: <20060510042002.505574E003@common-lisp.net>


Mon May  8 07:08:34 EDT 2006  attila.lendvai at gmail.com
  * Added compile-parenscript-file

    M ./src/package.lisp +2
    M ./src/utils.lisp +52

Mon May  8 07:06:11 EDT 2006  attila.lendvai at gmail.com
  * Added character type conversion

    M ./src/js.lisp +2


An updated tarball of parenscript's source can be downloaded here:
http://common-lisp.net/project/ucw/tarballs/parenscript-20060509.tar.gz

Darcsweb URL:
http://uncommon-web.com/darcsweb/darcsweb.cgi?r=parenscript;a=summary


From mbaringer at common-lisp.net  Wed May 10 04:30:05 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Wed, 10 May 2006 00:30:05 -0400 (EDT)
Subject: [Bese-devel] New patches to ucw_dev:  9-May-2006
Message-ID: <20060510043005.A3B775903C@common-lisp.net>


Sat May  6 19:36:02 EDT 2006  Drew Crampsie <drewc at tech.coop>
  * Add a <ucw:simple-submit and <ucw:simple-form that do not require javascript.
  
  <ucw:simple-submit uses a BUTTON tag to render a submit button that does not require javascript
  
  To make this happen, i added a method to find-action that operates on a list, 
  grabbing the car and using it as the action id. When a form is submitted with an extra action parameter, 
  the last one submitted (first in the list) is taken to be the action-id.
  
  This allows forms without javascript!! SIMPLE-SUBMIT will work in the standard UCW:FORM, 
  SIMPLE-FORM is a form without the JS cruft, but will not work with standard <UCW:* submit buttons.
  
  
  

    M ./src/packages.lisp +2
    M ./src/rerl/standard-session-frame.lisp +7
    M ./src/yaclml/ucw-tags.lisp +30

Tue May  9 09:24:43 EDT 2006  attila.lendvai at gmail.com
  * Fix serve-file

    M ./src/backend/common.lisp -9 +7

Mon May  8 18:08:33 EDT 2006  attila.lendvai at gmail.com
  * Added serve-sequence next to serve file with a defserve macrolet

    M ./src/backend/common.lisp -21 +61
    M ./src/packages.lisp +1
    M ./src/rerl/standard-dispatcher.lisp -1 +3

Mon May  8 16:30:35 EDT 2006  attila.lendvai at gmail.com
  * Resolve conflicts with "Don't send headers set to NIL (especially Content-Length:) in response."

    M ./src/backend/httpd.lisp -6 +1

Mon May  8 16:23:28 EDT 2006  attila.lendvai at gmail.com
  * Add dojo.js to standard-window to avoid user surprises

    M ./src/components/window.lisp +1

Mon May  8 16:20:29 EDT 2006  attila.lendvai at gmail.com
  * Ensure in shared-initialize of standard-application that the required dispatchers exists
  
  action dispatcher and a parenscript-dispatcher is crucial for UCW to function properly.
  To make sure things work fine in the normal situations add them in shared-initialize.
  For full control one can still use the application.dispatchers accessor...

    M ./src/rerl/standard-application.lisp -3 +12
    M ./src/rerl/standard-classes.lisp -10 +6

Mon May  8 15:02:28 EDT 2006  attila.lendvai at gmail.com
  * Use context.cookie-value to acces session cookie, also rename the cookie constant to +ucw-session-cookie-name+

    M ./src/rerl/cookie-session.lisp -9 +3

Mon May  8 14:58:42 EDT 2006  attila.lendvai at gmail.com
  * Added parenscript-dispatcher
  
  It lazily compiles a parenscript file at the first request and tehn serves it.

    M ./src/packages.lisp +1
    M ./src/rerl/standard-dispatcher.lisp -1 +34

Sat May  6 18:50:10 EDT 2006  attila.lendvai at gmail.com
  * Added a per-application parenscript file

    M ./src/components/window.lisp +2
    A ./src/per-application-parenscript.lisp
    M ./src/rerl/standard-classes.lisp -1 +9

Sat May  6 13:42:48 EDT 2006  attila.lendvai at gmail.com
  * Added encoding method to response

    M ./src/backend/common.lisp +7
    M! ./src/backend/httpd.lisp -1 +5
    M ./src/backend/mod-lisp.lisp -1 +1
    M ./src/rerl/protocol.lisp +4

Fri May  5 18:37:24 EDT 2006  attila.lendvai at gmail.com
  * Added context.cookies and context.cookie-value

    M ./src/rerl/protocol.lisp -1 +7
    M ./src/rerl/standard-request-context.lisp +12

Thu May  4 11:14:09 EDT 2006  attila.lendvai at gmail.com
  * Use widget-component.css-* accessors when rendering, so that it can be overridden

    M ./src/components/widget.lisp -2 +3

Thu May  4 08:02:48 EDT 2006  attila.lendvai at gmail.com
  * Do not render the ol/li elements when the container has only one member

    M ./src/components/container.lisp -2 +5

Sun Apr 23 14:45:25 EDT 2006  attila.lendvai at gmail.com
  * Resolve conflicts

    M ./src/components/form.lisp -3 +4
    M ./src/packages.lisp +2

Fri Apr 14 09:04:00 EDT 2006  attila.lendvai at gmail.com
  * Added tabindex support for form-fields

    M! ./src/components/form.lisp -5 +12
    M! ./src/packages.lisp -1


An updated tarball of ucw_dev's source can be downloaded here:
http://common-lisp.net/project/ucw/tarballs/ucw_dev-20060509.tar.gz

Darcsweb URL:
http://uncommon-web.com/darcsweb/darcsweb.cgi?r=ucw_dev;a=summary


From mb at bese.it  Wed May 10 09:44:25 2006
From: mb at bese.it (Marco Baringer)
Date: Wed, 10 May 2006 11:44:25 +0200
Subject: [Bese-devel] Re: read-from-client-string
References: <m2r7333z03.fsf@bese.it>
	<016201c67398$1e2df770$d80a0a0a@acceleration.net>
Message-ID: <m2ejz2xlhi.fsf@bese.it>

"Nathan Bird" <nathan at acceleration.net> writes:

> Yeah, that's pretty much the case, I had been using read in the forms number
> parsing because that's how I saw someone else do it at some point. :-)

that 'someone' else was probably me....

> The aserve backend also has this in there a couple of times:
> (read-from-string (format nil ":~A" header-name))
> I take it this is just trying to get keyword symbols out of strings? Would a
> better fix for that be using intern instead?

most definetly.

> Yeah, it does smell a bit, I'm just thinking if there are reads in there,
> might be better to have that check on. That might just be false security
> though.

not with standing evyrthing else i agree 100% that if we do use
read-from-string we want *read-eval* to be nil (and in fact i'm
leaving your patch until we decide what to do).

-- 
-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 May 10 09:54:26 2006
From: mb at bese.it (Marco Baringer)
Date: Wed, 10 May 2006 11:54:26 +0200
Subject: [Bese-devel] Re: Ajax
References: <m23bfj5dzr.fsf@bese.it>
	<014f01c67396$de50be40$d80a0a0a@acceleration.net>
Message-ID: <m2ac9qxl0t.fsf@bese.it>

"Nathan Bird" <nathan at acceleration.net> writes:

> Would you mind linking these (ucw_ajax, ucw_forms, ucw_presentations)
> repositories into the darcsweb?
> http://uncommon-web.com/darcsweb/darcsweb.cgi

done. (ucw_forms doesn't exist anymore as a seperate repository)

> I was very happy to find http://trac.common-lisp.net/ucw/ just now, looks
> like it hasn't been up for very long. Should we start using this further for
> a wiki or continue to ride on top of cliki? If we want to make this more
> general how do we get common-lisp.net logins? I looked through their pages a
> bit, but I didn't see anything for signing onto an existing project.

i had originally asked for trac because i thought the wiki was public
(and the ticket tracking system looked pretty cool).when i found out
the wiki wasn't public i kind of dropped the idea. 

but, if people are willing to get cl.net accounts (send an e-mail to
admin at common-lisp.net with your name and gpg key) then i'll start
publicizing the wiki (i'd be really happy to move the ucw tutorial on
cliki over to a ucw-specific site).

-- 
-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 ryan at acceleration.net  Wed May 10 15:05:47 2006
From: ryan at acceleration.net (Ryan Davis)
Date: Wed, 10 May 2006 11:05:47 -0400
Subject: [Bese-devel] Re: Ajax
In-Reply-To: <m2ac9qxl0t.fsf@bese.it>
References: <m23bfj5dzr.fsf@bese.it>	<014f01c67396$de50be40$d80a0a0a@acceleration.net>
	<m2ac9qxl0t.fsf@bese.it>
Message-ID: <4462014B.2070804@acceleration.net>

Trac has a permissions scheme where you can make the wiki public. 

The permissions can be controlled via the command-line:
http://projects.edgewall.com/trac/wiki/TracAdmin

Or with the webadmin plugin:
http://projects.edgewall.com/trac/wiki/WebAdmin

This seems like a pretty good tutorial for getting all that setup:
http://www.darcs.net/DarcsWiki/TracOnDarcs

Ryan Davis
Acceleration.net
Director of Programming Services
2831 NW 41st street, suite B
Gainesville, FL 32606

Office: 352-335-6500 x 124
Fax: 352-335-6506



Marco Baringer wrote:
> "Nathan Bird" <nathan at acceleration.net> writes:
>
>   
>> Would you mind linking these (ucw_ajax, ucw_forms, ucw_presentations)
>> repositories into the darcsweb?
>> http://uncommon-web.com/darcsweb/darcsweb.cgi
>>     
>
> done. (ucw_forms doesn't exist anymore as a seperate repository)
>
>   
>> I was very happy to find http://trac.common-lisp.net/ucw/ just now, looks
>> like it hasn't been up for very long. Should we start using this further for
>> a wiki or continue to ride on top of cliki? If we want to make this more
>> general how do we get common-lisp.net logins? I looked through their pages a
>> bit, but I didn't see anything for signing onto an existing project.
>>     
>
> i had originally asked for trac because i thought the wiki was public
> (and the ticket tracking system looked pretty cool).when i found out
> the wiki wasn't public i kind of dropped the idea. 
>
> but, if people are willing to get cl.net accounts (send an e-mail to
> admin at common-lisp.net with your name and gpg key) then i'll start
> publicizing the wiki (i'd be really happy to move the ucw tutorial on
> cliki over to a ucw-specific site).
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060510/d9f636c4/attachment.html>

From mb at bese.it  Wed May 10 15:24:58 2006
From: mb at bese.it (Marco Baringer)
Date: Wed, 10 May 2006 17:24:58 +0200
Subject: [Bese-devel] Re: Ajax
References: <m23bfj5dzr.fsf@bese.it>
	<014f01c67396$de50be40$d80a0a0a@acceleration.net>
	<m2ac9qxl0t.fsf@bese.it> <4462014B.2070804@acceleration.net>
Message-ID: <m2r731rjg5.fsf@bese.it>

Ryan Davis <ryan at acceleration.net> writes:

> Trac has a permissions scheme where you can make the wiki public. 
>
> The permissions can be controlled via the command-line:
> http://projects.edgewall.com/trac/wiki/TracAdmin

thanks for pointing that out, the wiki is now public!

-- 
-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 May 10 15:25:26 2006
From: mb at bese.it (Marco Baringer)
Date: Wed, 10 May 2006 17:25:26 +0200
Subject: [Bese-devel] ucw wiki
Message-ID: <m2mzdprjfd.fsf@bese.it>


the ucw trac wiki is now world writable:

http://trac.common-lisp.net/ucw/wiki

go crazy.

-- 
-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 cjstuij at gmail.com  Wed May 10 22:46:33 2006
From: cjstuij at gmail.com (Ties Stuij)
Date: Thu, 11 May 2006 00:46:33 +0200
Subject: [Bese-devel] dojo switch
Message-ID: <d7ce4ebf0605101546q3cf0c6c8s25b893cda91270c8@mail.gmail.com>

Changed the dojo.js in /path/to/ucw/wwwroot/ to the ajax edition. The
dojo.js currently supplied misses some features that ucw forms need
for correct validation. eg the stuff in dojo.html according to my
firefox js error checker. We can just as well include the ajax edition
i figured. Nothing as easy as replacing it with a less bloated version
if you need to.

Patch is in ucw_public.

greets,
Ties


From mbaringer at common-lisp.net  Thu May 11 04:20:02 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Thu, 11 May 2006 00:20:02 -0400 (EDT)
Subject: [Bese-devel] New patches to parenscript: 10-May-2006
Message-ID: <20060511042002.38AD167001@common-lisp.net>


Wed May 10 08:54:47 EDT 2006  Marco Baringer <mb at bese.it>
  * Move compile-parenscript code into a sperate file so that it complies cleanly
  
  The problew is that compile-parenscript-file-to-string contains a call
  to the macro js:js* this macro needs to be defined before we compile
  the compile-parenscript-file-to-string function.

    A ./src/compile-js.lisp
    M ./src/utils.lisp -49

Wed May 10 08:54:22 EDT 2006  Marco Baringer <mb at bese.it>
  * Use an explicit asdf:perform :after method instead of :perform (load-op :after ...)

    M ./parenscript.asd -4 +5


An updated tarball of parenscript's source can be downloaded here:
http://common-lisp.net/project/ucw/tarballs/parenscript-20060510.tar.gz

Darcsweb URL:
http://uncommon-web.com/darcsweb/darcsweb.cgi?r=parenscript;a=summary


From mbaringer at common-lisp.net  Thu May 11 04:30:04 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Thu, 11 May 2006 00:30:04 -0400 (EDT)
Subject: [Bese-devel] New patches to ucw_dev: 10-May-2006
Message-ID: <20060511043004.E166572022@common-lisp.net>


Sun Apr 30 17:55:47 EDT 2006  Nathan Bird <nathan at acceleration.net>
  * Read-from-client-string
  Useful for reading data from questionable origins where *read-eval* needs to be false.

    M ./src/components/form.lisp -6
    M ./src/helpers.lisp +5
    M ./src/packages.lisp +3

Tue May  9 06:21:04 EDT 2006  Marco Baringer <mb at bese.it>
  * Indentation fixup in tabbed-pane.lisp

    M ./src/components/tabbed-pane.lisp -3 +4

Tue May  9 06:20:50 EDT 2006  Marco Baringer <mb at bese.it>
  * Minor refactoring in container.lisp

    M ./src/components/container.lisp -19 +16

Tue May  9 06:10:51 EDT 2006  Marco Baringer <mb at bese.it>
  * Mention the difference between (setf application.dispathers) and (setf (slot-value app 'dispatchers)) in the docstring

    M ./src/rerl/standard-classes.lisp -5 +8


An updated tarball of ucw_dev's source can be downloaded here:
http://common-lisp.net/project/ucw/tarballs/ucw_dev-20060510.tar.gz

Darcsweb URL:
http://uncommon-web.com/darcsweb/darcsweb.cgi?r=ucw_dev;a=summary


From attila.lendvai at gmail.com  Thu May 11 08:49:23 2006
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Thu, 11 May 2006 10:49:23 +0200
Subject: [Bese-devel] session.current-frame race condition?
Message-ID: <b54b34af0605110149x3465653sb457379356368793@mail.gmail.com>

hi!

what happens if two requests come simulateneously into the same
session? seems like to me that (setf session.current-frame ...) will
have a race condition... shouldn't it be a bound dynamic variable just
like *context* or be a slot in *context*?

also something related: some code in my action handling extras needs
an atomic-incf (for isolated, but not to be mistaken with the
hashtable based defaction :isolated). does anyone have an idea how to
have it inside ucw?

to be honest i'm not actually using (action-href :isolated t) anywhere
yet, but i think will come handy once. currenty it breaks the service
loop and returns with an empty page (ucw_ajax branch) but eventually
it should record the response that the first invocation created and
blindly return it to the client when the href is requested again.

- attila

(alias 101 on irc &no 'its not lisp code :)

From mb at bese.it  Thu May 11 10:16:00 2006
From: mb at bese.it (Marco Baringer)
Date: Thu, 11 May 2006 12:16:00 +0200
Subject: [Bese-devel] Re: session.current-frame race condition?
References: <b54b34af0605110149x3465653sb457379356368793@mail.gmail.com>
Message-ID: <m2u07whnof.fsf@bese.it>

"Attila Lendvai" <attila.lendvai at gmail.com> writes:

> hi!
>
> what happens if two requests come simulateneously into the same
> session? seems like to me that (setf session.current-frame ...) will
> have a race condition... shouldn't it be a bound dynamic variable just
> like *context* or be a slot in *context*?

right you are, since everytihng else is a slot in context i think i'll
do that.

ticket: http://trac.common-lisp.net/ucw/ticket/4

> also something related: some code in my action handling extras needs
> an atomic-incf (for isolated, but not to be mistaken with the
> hashtable based defaction :isolated). does anyone have an idea how to
> have it inside ucw?

i don't think there's anything ucw specific about it. i discovered a
bug the other day in the multithread htpd backend the other day
(http://trac.common-lisp.net/ucw/ticket/2) which requires
portable-threads (or some similar library) to solve. portable-threads
has an atomic-incf macro which you could use.

-- 
-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 whalliburton at gmail.com  Sat May 13 03:51:54 2006
From: whalliburton at gmail.com (William Halliburton)
Date: Fri, 12 May 2006 22:51:54 -0500
Subject: [Bese-devel] Latest parenscript patch breaks compile.
Message-ID: <4e7bd29e0605122051v7f66e267n76a38a11d1c4a59@mail.gmail.com>

Patch titled

Added import-macros-from-lisp that bring lisp macros into the js
macroexpansion

does not compile under SBCL 0.9.12. Have not tried any other lisp.

Probem is that the new function undefine-js-compile-macro is defined and
used by a macro used in this file.

To fix I wrapped the function in (eval-when (:execute :load-toplevel
:compile-toplevel).


<http://uncommon-web.com/darcsweb/darcsweb.cgi?r=parenscript;a=commit;h=20060512152954-6b9e8-72eca5cd28854044963f5453ac30dcbaca2aea3d.gz>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060512/2d3e2290/attachment.html>

From luca at pca.it  Sat May 13 20:46:14 2006
From: luca at pca.it (Luca Capello)
Date: Sat, 13 May 2006 15:46:14 -0500
Subject: [Bese-devel] Refactoring :ucw.default and :ucw.config
Message-ID: <87slnd7iw9.fsf@gismo.pca.it>

Hello!

I decided to simplify how the default options are loaded through
ucwctl (but this is true as well if you directly call the correct
functions).

Now, the situation is the following:

- the :ucw.config system defines a series of function that manage to
  load the *ucw-config-file* and prepare the *ucw-applications* and
  *ucw-systems* variables

- the :ucw.default system, on the contrary, set the default values for
  each variables and then load the *ucw-config-file* when present or
  just call the function to set the *ucw-applications* and
  *ucw-systems* variables

Now, this means that two ASDF systems are used, but they could be
merged back into the general :ucw system, because:

- setting the default variables even if they are not used later is not
  really a problem (please correct me if I'm wrong)

- instead of firing the :ucw.default system up, etc/start.lisp loads
  the *ucw-config-file* if present or call the needed function for the
  *ucw-applications* and *ucw-systems* variables (this is exactly the
  same last action executed by the :ucw.default system)

Does anyone have better suggestions or comments?  In case of no
replies for the next 3 days, I'll commit the changes.

Thx, bye,
Gismo / Luca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060513/8fe9e6b6/attachment.sig>

From attila.lendvai at gmail.com  Sun May 14 13:42:12 2006
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Sun, 14 May 2006 15:42:12 +0200
Subject: [Bese-devel] iterate dependency
Message-ID: <b54b34af0605140642l6db4aa25u43568aba4f24bf4c@mail.gmail.com>

hi!

i've got a local patch for yaclml that properly escapes attribute
values with escape-as-html (which should be called as escape-as-xml,
shouldn't it?)

this is a move towards xhtml conformance.

but this patch depends on a fresh iterate, so i haven't yet pushed it
yet. what is the policy in such situations? the dependency in iterate
is already available both as a release and in its darcs repo for a few
weeks.

- attila

(alias 101 on irc &no 'its not lisp code :)

From mb at bese.it  Sun May 14 13:52:53 2006
From: mb at bese.it (Marco Baringer)
Date: Sun, 14 May 2006 15:52:53 +0200
Subject: [Bese-devel] iterate dependency
In-Reply-To: <b54b34af0605140642l6db4aa25u43568aba4f24bf4c@mail.gmail.com>
	(Attila Lendvai's message of "Sun, 14 May 2006 15:42:12 +0200")
References: <b54b34af0605140642l6db4aa25u43568aba4f24bf4c@mail.gmail.com>
Message-ID: <m24pzsg1ca.fsf@bese.it>

"Attila Lendvai" <attila.lendvai at gmail.com> writes:

> hi!
>
> i've got a local patch for yaclml that properly escapes attribute
> values with escape-as-html (which should be called as escape-as-xml,
> shouldn't it?)
>
> this is a move towards xhtml conformance.

cool.

> but this patch depends on a fresh iterate, so i haven't yet pushed it
> yet. what is the policy in such situations? the dependency in iterate
> is already available both as a release and in its darcs repo for a few
> weeks.

write a big fat warning in the patch's log message and do it.

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


From attila.lendvai at gmail.com  Sun May 14 14:39:28 2006
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Sun, 14 May 2006 16:39:28 +0200
Subject: [Bese-devel] with-xml-syntax in yaclml
Message-ID: <b54b34af0605140739v37e8079ds7516a3f7025db26f@mail.gmail.com>

so i've pushed everything to yaclml, and just now i noticed that i've
replaced the with-xml-syntax function with a macro.

previously it was playing with lambdas to set the proper state at read
time, but now it's a simple macro that does the same (hopefully).

(with-xml-syntax
  <foo :bar "baz"
  (call some lisp)>)

expands to:

(PROGN
 (WRITE-STRING "<foo bar=\"baz\"
  >"
               *YACLML-STREAM*)
 (CALL SOME LISP)
 (WRITE-STRING "</foo
>"
               *YACLML-STREAM*)
 NIL)

i think it was not widely used and i hope it does not cause confusion.

- attila

(alias 101 on irc &no 'its not lisp code :)

From mb at bese.it  Sun May 14 16:04:50 2006
From: mb at bese.it (Marco Baringer)
Date: Sun, 14 May 2006 18:04:50 +0200
Subject: [Bese-devel] Re: with-xml-syntax in yaclml
References: <b54b34af0605140739v37e8079ds7516a3f7025db26f@mail.gmail.com>
Message-ID: <m2ves8egnx.fsf@bese.it>

"Attila Lendvai" <attila.lendvai at gmail.com> writes:

> previously it was playing with lambdas to set the proper state at read
> time, but now it's a simple macro that does the same (hopefully).

since macro expansion is post read-time this code:

(with-xml-syntax
  <foo <bar>>)

no longer works. the original with-xml-syntax function was meant to be
used in conjunction with arnesi's { read macro:

(read-from-string "{with-xml-syntax <foo <bar>>}")
==>
(WRITE-STRING "<foo><bar/></foo>" *YACLML-STREAM*)

> (with-xml-syntax
>  <foo :bar "baz"
>  (call some lisp)>)
>
> expands to:
>
> (PROGN
> (WRITE-STRING "<foo bar=\"baz\"
>  >"
>               *YACLML-STREAM*)
> (CALL SOME LISP)
> (WRITE-STRING "</foo
>>"
>               *YACLML-STREAM*)
> NIL)

-- 
-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 attila.lendvai at gmail.com  Sun May 14 20:04:14 2006
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Sun, 14 May 2006 22:04:14 +0200
Subject: [Bese-devel] Re: with-xml-syntax in yaclml
In-Reply-To: <m2ves8egnx.fsf@bese.it>
References: <b54b34af0605140739v37e8079ds7516a3f7025db26f@mail.gmail.com>
	<m2ves8egnx.fsf@bese.it>
Message-ID: <b54b34af0605141304q31614fafp83d4f008010ce560@mail.gmail.com>

> (with-xml-syntax
>   <foo <bar>>)
>
> no longer works. the original with-xml-syntax function was meant to be
> used in conjunction with arnesi's { read macro:

i was lacking quite some knowledge about reader stuff, and pobably
still lacking. but it's clear now that it was a bugous change and i've
already rolled back the with-xml-syntax part.

but looking at how *readtable* is restored after loading/compiling a
file, it seems like the rest of the stuff that counts nesting and
restores original reader char handlers are also pointless...

so, i've created this in arnesi:

(defmacro locally-enable-bracket-reader ()
  "Enable bracket reader for the rest of the file (being loaded or compiled).
Be careful when using in different situations, because it modifies *readtable*!"
  ;; The standard sais that *readtable* is restored after
loading/compiling a file,
  ;; so we make a copy and alter that. The effect is that it will be enabled
  ;; for the rest of the file being processed.
  `(eval-when (:compile-toplevel)
    (setf *readtable* (copy-readtable *readtable*))
    (enable-bracket-reader)))

and i'm planning to do the same for the xml-syntax and drop rest of
the pointless code counting the nesting of enable/disable calls and
backuping the old handlers.

but i'd better not commit anything until i hear some opinions to avoid
further noise in the repo...

- attila

(alias 101 on irc &no 'its not lisp code :)

From luca at pca.it  Sun May 14 23:46:37 2006
From: luca at pca.it (Luca Capello)
Date: Sun, 14 May 2006 18:46:37 -0500
Subject: [Bese-devel] Re: Refactoring :ucw.default and :ucw.config
References: <87slnd7iw9.fsf@gismo.pca.it>
Message-ID: <87ves8186a.fsf@gismo.pca.it>

Hello!

On Sat, 13 May 2006 15:46:14 -0500, Luca Capello wrote:
> I decided to simplify how the default options are loaded through
> ucwctl (but this is true as well if you directly call the correct
> functions).
[...]
> Does anyone have better suggestions or comments?  In case of no
> replies for the next 3 days, I'll commit the changes.

OK, after a private discussion with Marco, I just applied it :-)

Thx, bye,
Gismo / Luca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060514/31cbc527/attachment.sig>

From luca at pca.it  Mon May 15 00:08:08 2006
From: luca at pca.it (Luca Capello)
Date: Sun, 14 May 2006 19:08:08 -0500
Subject: [Bese-devel] Special variables in src/default.lisp
Message-ID: <87ody0176f.fsf@gismo.pca.it>

Hello,

now that src/default.lisp is compiled by default, I was finding a
better default values for the two most critical variables:
`*ucw-applications-directory*' and `*ucw-log-root-directory*'.

The problem with the former is that now it defaults to
/etc/ucw/applications.d/, thus generating an error it that folder is
not present or the user has set it to nil or another valid folder.
So, with a clever thinking, I think that we can default to:

- nil (probably the best thing)

- when empty, in order and if they exist to ~/.ucw/applications.d/ or
  /etc/uwc/applications.d/ (nil will be the fallback)

I vote for the first option, the etc/conf.lisp file is there for this
kind of customizations ;-)

The problem with the latter, `*ucw-log-root-directory*', is probably
simpler: if $LOGROOT is empty, we can default to ./logs, which is the
folder used by the ucw-boxset.  So, this be something like:

    (defvar *ucw-log-root-directory*
      (or (arnesi:getenv "LOGROOT") "logs"))

Comments/suggestions?  As usual, if no ones will arrive in 3 days,
I'll commit the patch ;-)

Thx, bye,
Gismo / Luca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060514/05fb73d5/attachment.sig>

From maciekp at japhy.fnord.org  Mon May 15 18:44:55 2006
From: maciekp at japhy.fnord.org (Maciek Pasternacki)
Date: Mon, 15 May 2006 20:44:55 +0200
Subject: [Bese-devel] Special variables in src/default.lisp
In-Reply-To: <87ody0176f.fsf@gismo.pca.it> (Luca Capello's message of "Sun, 14
	May 2006 19:08:08 -0500")
References: <87ody0176f.fsf@gismo.pca.it>
Message-ID: <87odxzruu0.fsf@lizard.king>

On Setting Orange, Discord 62, 3172 YOLD, Luca Capello wrote:

> now that src/default.lisp is compiled by default, I was finding a
> better default values for the two most critical variables:
> `*ucw-applications-directory*' and `*ucw-log-root-directory*'.
>
> The problem with the former is that now it defaults to
> /etc/ucw/applications.d/, thus generating an error it that folder is
> not present or the user has set it to nil or another valid folder.
> So, with a clever thinking, I think that we can default to:
>
> - nil (probably the best thing)
>
> - when empty, in order and if they exist to ~/.ucw/applications.d/ or
>   /etc/uwc/applications.d/ (nil will be the fallback)
>
> I vote for the first option, the etc/conf.lisp file is there for this
> kind of customizations ;-)

I'm not sure how does nil work here, but IMHO the default for UCW
should be not to touch anything outside of UCW source dir.  It can
seek configuration file in /etc/ucw/ or ~/.ucw/, but if there is no
such file, it means I don't want to run UCW system-wide or even
homedir-wide, but just start it and be sure it won't make mess
anywhere else.

-- 
__    Maciek Pasternacki <maciekp at japhy.fnord.org> [ http://japhy.fnord.org/ ]
`| _   |_\  / { ...I have a social life?
,|{-}|}| }\/ --- you will, when she turns you into on of the living dead.  }
\/   |____/                                            ( Megatokyo 442 )  -><-


From asbjxrn at bjxrnstad.net  Mon May 15 16:27:18 2006
From: asbjxrn at bjxrnstad.net (=?ISO-8859-1?Q?Asbj=F8rn_Bj=F8rnstad?=)
Date: Tue, 16 May 2006 00:27:18 +0800
Subject: [Bese-devel] Small date-field patch
Message-ID: <beba1feb0605150927q7c19d389ufebbb45988357966@mail.gmail.com>

Hi, a small patch to date-field to enable (setf value) and a set-ymd function.

(Also exported data-set, that should maybe be in a separate patch?)

I tried adding it to ucw_public, but it failed since the
tab-indentation patch from may 9th is missing. Since it's too late for
me now to figure out how to solve that, I'll just post it here and
hope someone picks it up. :)
-- 
  -asbjxrn


From attila.lendvai at gmail.com  Tue May 16 08:58:07 2006
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Tue, 16 May 2006 10:58:07 +0200
Subject: [Bese-devel] ajax and frames
Message-ID: <b54b34af0605160158y35dac60dgac39d92f4725611@mail.gmail.com>

hi!

i've added two new buttons to the counter example in the ucw_ajax
branch that increments and decrements the counter with ajax. there
were some reports that it's not working correctly on the client side,
though. i'm working with a recent firefox + firebug and it works fine
for me. eventually it'll be tested on other browsers, but feel free to
send patches... :)

i've taken a bit different route then what Evrim did with his ajax
implementation and i hope he won't be angry for me doing this. i'll
merge whatever i can from his patch, but currently mostly the
low-level stuff is being crafted. i'm adding features to <ucw: yaclml
tags, actions, tal tags...

my approach was to smarten up ucw's action handling and it seems to
work fine. if you look at the counter example diff in the ajax branch
you can see how little it takes in the user code to ajaxify something.

you can even choose trivially wether an action should be run in a new
frame with-call/cc or in the same frame without the interptered stuff
(much more lightweight). you make this choice based on wether you want
to use call/answer or not in the action.

for the counter example it means that increment can be a lightweight
ajax action because it never uses call/answer but on the other hand
decrement needs to run in a new frame because it call's a dialog when
going below 0.

the problem is that it generates a new frame for each decrement action.

what i was thinking about is some kind of lazy frame creation: the
request context knows if a new frame has been created or not and when
it's first detected that a new frame is needed then it's lazily
created. but i don't exactly know how to detect that a new frame is
needed... and maybe it can't even work, but maybe this blurred idea
inspires someone... Macro? :)

another problem might be that with ajax actions the rendering is
started from inside the action body and if someone creates a complex
action then rendering may happen before something happens that needs a
new frame. but that can be easily avoided with two separate
collect-invalid/render phase, similar to how render-loop is called
with normal actions.

ideas?

- attila

(alias 101 on irc &no 'its not lisp code :)

From cjstuij at gmail.com  Tue May 16 13:04:46 2006
From: cjstuij at gmail.com (Ties Stuij)
Date: Tue, 16 May 2006 15:04:46 +0200
Subject: [Bese-devel] form fix-likes
Message-ID: <d7ce4ebf0605160604i3b3e2075gf7218ce685ecbfad@mail.gmail.com>

he there,

i fixed several buglike things in forms:

- the javascript number validator now accepts fractions
- the javascript integer validator now disallows floating points
- fixed the email validator
- allows <ucw:month-select to have other attributes than just accessor
- in month-select changed Dicember to December

patch dumped in ucw_public

greets,
Ties


From cjstuij at gmail.com  Tue May 16 13:31:03 2006
From: cjstuij at gmail.com (Ties Stuij)
Date: Tue, 16 May 2006 15:31:03 +0200
Subject: [Bese-devel] what don't i understand about select-field?
Message-ID: <d7ce4ebf0605160631t3f7559aeq335c1af906c26101@mail.gmail.com>

Greetings,

I've been looking at the select classes in form.lisp and it seems to
me there is a lot of double work going on while the benifit is not
quite clear to me. Since you have your key-value pair ready already,
why make an index also? Especially with entities like hash tables or
alists which are supposed to have just one key to retrieve to begin
with.

Also i didn't really get the mapping-select abstraction, since it
implements its only method, render-options, exactly the same as
select-field, just with different names.

Anyway as practice i made a select field which brings the amount of
forms needed down from 12 to 4 (see below). It's the alist-select
field from form.lisp except for that the value you're after is now
already in client-value. On top of that i've built simpler select
field, which in functionality is the same as a normal select-field.
For the 'selected' attribute of options it compares the value, but
that could easily be changed to key.

As i said i made it for practice, but perhaps we could use these to
replace the select fields of form.lisp? hash-table-select and
plist-select are easily converted i think and the end result is faster
and easier to read/use.

But then again i probably missed the thing that's handy/good/practical
about the current setup.

;; simple-select-field

(defclass simple-select-field (generic-html-input)
  ((data-set :accessor data-set :initarg :data-set
             :documentation "An alist of values this select chooses
             from.")
   (test-fn :accessor test-fn :initarg :test-fn :initform #'string=
            :documentation "function to compare for :selected"))
  (:documentation "Form field used for selecting one value from a
  list of available options."))

(defmethod render ((field simple-select-field))
  (<:select :name (make-new-callback
                   (lambda (value)
                     (setf (client-value field) value)))
            (render-options field)))

(defgeneric render-options (select-field)
  (:documentation "Function used to render the list of options of
  a select field."))

(defmethod render-options ((field simple-select-field))
  (dolist* ((key-string . value) (data-set field))
           (<:option :value value
                     :selected  (funcall (test-fn field) (client-value
field) value)
                     (<:ah key-string))))

;; simpler-select-field

(defclass simpler-select-field (simple-select-field) ()
  (:documentation "needs just a list to render an option field, with the same
  value for the value as the name"))

(defmethod render-options ((field simpler-select-field))
  (dolist* (value (data-set field))
           (<:option :value value
                     :selected  (funcall (test-fn field) (client-value
field) value)
                     (<:ah value))))

greets,
Ties


From ryan at acceleration.net  Tue May 16 13:50:49 2006
From: ryan at acceleration.net (Ryan Davis)
Date: Tue, 16 May 2006 09:50:49 -0400
Subject: [Bese-devel] what don't i understand about select-field?
In-Reply-To: <d7ce4ebf0605160631t3f7559aeq335c1af906c26101@mail.gmail.com>
References: <d7ce4ebf0605160631t3f7559aeq335c1af906c26101@mail.gmail.com>
Message-ID: <4469D8B9.8080309@acceleration.net>

I think the reason for the key-value and then index is so you can have 
complicated structures as your option values seamlessly.

For instance, say you had a key of "Option 1", with a value being some 
CLOS object.  When rendering to the browser, you don't want to have:
<option value="#<FOO {C720971}>">Option 1</option>

So UCW makes an index variable to map between the option and your Lisp 
value.  This lets you think more in lisp and less in html.

Thanks,

Ryan Davis
Acceleration.net
Director of Programming Services
2831 NW 41st street, suite B
Gainesville, FL 32606

Office: 352-335-6500 x 124
Fax: 352-335-6506



Ties Stuij wrote:
> Greetings,
>
> I've been looking at the select classes in form.lisp and it seems to
> me there is a lot of double work going on while the benifit is not
> quite clear to me. Since you have your key-value pair ready already,
> why make an index also? Especially with entities like hash tables or
> alists which are supposed to have just one key to retrieve to begin
> with.
>
> Also i didn't really get the mapping-select abstraction, since it
> implements its only method, render-options, exactly the same as
> select-field, just with different names.
>
> Anyway as practice i made a select field which brings the amount of
> forms needed down from 12 to 4 (see below). It's the alist-select
> field from form.lisp except for that the value you're after is now
> already in client-value. On top of that i've built simpler select
> field, which in functionality is the same as a normal select-field.
> For the 'selected' attribute of options it compares the value, but
> that could easily be changed to key.
>
> As i said i made it for practice, but perhaps we could use these to
> replace the select fields of form.lisp? hash-table-select and
> plist-select are easily converted i think and the end result is faster
> and easier to read/use.
>
> But then again i probably missed the thing that's handy/good/practical
> about the current setup.
>
> ;; simple-select-field
>
> (defclass simple-select-field (generic-html-input)
>  ((data-set :accessor data-set :initarg :data-set
>             :documentation "An alist of values this select chooses
>             from.")
>   (test-fn :accessor test-fn :initarg :test-fn :initform #'string=
>            :documentation "function to compare for :selected"))
>  (:documentation "Form field used for selecting one value from a
>  list of available options."))
>
> (defmethod render ((field simple-select-field))
>  (<:select :name (make-new-callback
>                   (lambda (value)
>                     (setf (client-value field) value)))
>            (render-options field)))
>
> (defgeneric render-options (select-field)
>  (:documentation "Function used to render the list of options of
>  a select field."))
>
> (defmethod render-options ((field simple-select-field))
>  (dolist* ((key-string . value) (data-set field))
>           (<:option :value value
>                     :selected  (funcall (test-fn field) (client-value
> field) value)
>                     (<:ah key-string))))
>
> ;; simpler-select-field
>
> (defclass simpler-select-field (simple-select-field) ()
>  (:documentation "needs just a list to render an option field, with 
> the same
>  value for the value as the name"))
>
> (defmethod render-options ((field simpler-select-field))
>  (dolist* (value (data-set field))
>           (<:option :value value
>                     :selected  (funcall (test-fn field) (client-value
> field) value)
>                     (<:ah value))))
>
> greets,
> Ties
> _______________________________________________
> bese-devel mailing list
> bese-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel
>


From mb at bese.it  Tue May 16 14:36:49 2006
From: mb at bese.it (Marco Baringer)
Date: Tue, 16 May 2006 16:36:49 +0200
Subject: [Bese-devel] Re: form fix-likes
References: <d7ce4ebf0605160604i3b3e2075gf7218ce685ecbfad@mail.gmail.com>
Message-ID: <m2iro6jata.fsf@bese.it>

"Ties Stuij" <cjstuij at gmail.com> writes:

> he there,
>
> i fixed several buglike things in forms:

applied. thanks. (i love the phrase 'buglike things')

> - in month-select changed Dicember to December

ETOOMUCHITALIAN :)

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



From mb at bese.it  Tue May 16 14:36:14 2006
From: mb at bese.it (Marco Baringer)
Date: Tue, 16 May 2006 16:36:14 +0200
Subject: [Bese-devel] Re: what don't i understand about select-field?
References: <d7ce4ebf0605160631t3f7559aeq335c1af906c26101@mail.gmail.com>
Message-ID: <m2mzdijau9.fsf@bese.it>

"Ties Stuij" <cjstuij at gmail.com> writes:

> Greetings,
>
> I've been looking at the select classes in form.lisp and it seems to
> me there is a lot of double work going on while the benifit is not
> quite clear to me. Since you have your key-value pair ready already,
> why make an index also? Especially with entities like hash tables or
> alists which are supposed to have just one key to retrieve to begin
> with.
>
> Also i didn't really get the mapping-select abstraction, since it
> implements its only method, render-options, exactly the same as
> select-field, just with different names.

that looks like a mistake on my part.

> Anyway as practice i made a select field which brings the amount of
> forms needed down from 12 to 4 (see below). It's the alist-select
> field from form.lisp except for that the value you're after is now
> already in client-value. On top of that i've built simpler select
> field, which in functionality is the same as a normal select-field.
> For the 'selected' attribute of options it compares the value, but
> that could easily be changed to key.
>
> As i said i made it for practice, but perhaps we could use these to
> replace the select fields of form.lisp? hash-table-select and
> plist-select are easily converted i think and the end result is faster
> and easier to read/use.
>
> But then again i probably missed the thing that's handy/good/practical
> about the current setup.

the only thing you'll need to deal with is non-string keys and values,
an even more confusing situation is when you have equal (but not eq)
strings in an eq hash table :(.

-- 
-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 cjstuij at gmail.com  Tue May 16 16:03:19 2006
From: cjstuij at gmail.com (Ties Stuij)
Date: Tue, 16 May 2006 18:03:19 +0200
Subject: [Bese-devel] Re: what don't i understand about select-field?
In-Reply-To: <m2mzdijau9.fsf@bese.it>
References: <d7ce4ebf0605160631t3f7559aeq335c1af906c26101@mail.gmail.com>
	<m2mzdijau9.fsf@bese.it>
Message-ID: <d7ce4ebf0605160903t4d1683b6xc3263c013b410b02@mail.gmail.com>

@ ryan & marco > ah yes of course, thanks!


From ctdean at sokitomi.com  Tue May 16 18:20:34 2006
From: ctdean at sokitomi.com (Chris Dean)
Date: Tue, 16 May 2006 11:20:34 -0700
Subject: [Bese-devel] arnesi patch queue->list
Message-ID: <m2sln9ltl9.fsf@tungsten.sokitomi.com>


Patch attached for a function that transforms a queue into a list.

Thanks for arnesi - I use it everyday!

Regards,
Chris Dean

diff -rN -u old-arnesi/src/packages.lisp new-arnesi/src/packages.lisp
--- old-arnesi/src/packages.lisp	2006-05-16 11:10:59.000000000 -0700
+++ new-arnesi/src/packages.lisp	2006-05-16 11:10:59.000000000 -0700
@@ -251,6 +251,7 @@
    #:peek-queue
    #:queue-empty-p
    #:queue-count
+   #:queue->list
    #:lru-queue
    
    ;; decimal arith
diff -rN -u old-arnesi/src/queue.lisp new-arnesi/src/queue.lisp
--- old-arnesi/src/queue.lisp	2006-05-16 11:10:59.000000000 -0700
+++ new-arnesi/src/queue.lisp	2006-05-16 11:10:59.000000000 -0700
@@ -117,6 +117,12 @@
   (print-unreadable-object (queue stream :type t :identity t)
     (format stream "~D" (queue-count queue))))
 
+(defmethod queue->list ((queue queue))
+  (let ((res nil))
+    (do-all-elements (element queue)
+      (push element res))
+    (nreverse res)))
+
 ;;;; ** LRU Queue
 
 (defclass lru-queue (queue)



From rafal.rusin at gmail.com  Tue May 16 18:34:05 2006
From: rafal.rusin at gmail.com (Rafal Rusin)
Date: Tue, 16 May 2006 20:34:05 +0200
Subject: [Bese-devel] UCW Performance
Message-ID: <9bbf67fa0605161134v7e8da8am3b8ed9d7132d64ae@mail.gmail.com>

Hello,

I've just launched a great UCW demo from
http://www.fallenfrukt.com/ucw-intro.html
and noticed that it has about 5 req./sec. on increase counter on sbcl. I used
apache benchmark (ab) and centrino 1,5 GHz machine.
Is UCW really that that slow? Maybe it's just a backend fault or something.

Rafal


From attila.lendvai at gmail.com  Tue May 16 20:19:47 2006
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Tue, 16 May 2006 22:19:47 +0200
Subject: [Bese-devel] UCW Performance
In-Reply-To: <9bbf67fa0605161134v7e8da8am3b8ed9d7132d64ae@mail.gmail.com>
References: <9bbf67fa0605161134v7e8da8am3b8ed9d7132d64ae@mail.gmail.com>
Message-ID: <b54b34af0605161319g203b5200k49fed18b39442a25@mail.gmail.com>

> apache benchmark (ab) and centrino 1,5 GHz machine.
> Is UCW really that that slow? Maybe it's just a backend fault or something.

just a note: running it from inside a logging emacs is quite a
performance killer.

but even then with the ajax stuff i can serve layed out graphs
rendered with cairo and packed into png with 5 fps... :)

- attila

(alias 101 on irc &no 'its not lisp code :)

From luca at pca.it  Wed May 17 03:36:29 2006
From: luca at pca.it (Luca Capello)
Date: Tue, 16 May 2006 22:36:29 -0500
Subject: [Bese-devel] Re: Special variables in src/default.lisp
References: <87ody0176f.fsf@gismo.pca.it> <87odxzruu0.fsf@lizard.king>
Message-ID: <878xp15nlu.fsf@gismo.pca.it>

Hello!

On Mon, 15 May 2006 13:44:55 -0500, Maciek Pasternacki wrote:
> I'm not sure how does nil work here, but IMHO the default for UCW
> should be not to touch anything outside of UCW source dir.  It can
> seek configuration file in /etc/ucw/ or ~/.ucw/, but if there is no
> such file, it means I don't want to run UCW system-wide or even
> homedir-wide, but just start it and be sure it won't make mess
> anywhere else.

OK, so I think we should deeply reconsidered the default values.  The
following are the ones present in my local copy of src/default.lisp.

- (defvar *ucw-config-file* (arnesi:getenv "CONFIGFILE"))

  This is OK, I mean, if you don't specify $CONFIGIFILE this will be
  nil and so there should be no problem.

- (defvar *ucw-swank-port* 4005)

  I don't think other values should be assigned, here.

- (defvar *ucw-backend-type* :httpd)
  (defvar *ucw-backend-host* "127.0.0.1")
  (defvar *ucw-backend-port* 8080)

  As UCW should work out-of-the-box, we're obliged to assign values
  here.

- (defvar *ucw-server-class* 'standard-server)

  This wasn't even specified on the old start.lisp and AFAIK the
  standard-server is the only available.

- (defvar *ucw-applications-directory* nil)

  Maciek, you strongly agreed have this set to nil, am I right?

- (defvar *ucw-systems* '(:ucw.admin :ucw.examples))
  (defvar *ucw-applications* '(it.bese.ucw::*admin-application*
	                       it.bese.ucw-user::*example-application*))

  Probably we can leave the *admin-application* out, because of
  security, but otherwise the *example-application* is useful to have
  as UCW-working witness.

- (defvar *ucw-inspector* t)
  (defvar *ucw-debugger* t)

  I find this quite useful, especially in development.

- (defvar *ucw-log-root-directory* (or (arnesi:getenv "LOGROOT") "logs"))
  (defvar *ucw-log-level* '+INFO+)

  The former could default to (arnesi:getenv "LOGROOT"), so in case
  $LOGROOT is not specify it's nil.  In that case, however, the latter
  should be set accordingly to '+DRIBBLE+, am I correct?  So, the
  latter should be defined as something like

    (if *ucw-log-root-directory*
      (defvar *ucw-log-level* '+INFO+)
      (defvar *ucw-log-level* '+DRIBBLE+))

Maciek, should be this OK for you?  Has anyone else any other comment?

After that, what should we put in etc/conf.lisp?  ATM this is merely a
copy of src/default.lisp, but with the values defined as (setf ...).
I put again all the values in etc/conf.lisp actually because IMHO an
UCW user (either an end-one or a developer) should not directly modify
src/* files, working on etc/* ones instead.  Obviously, this doesn't
apply if the user works on patching UCW about these stuff ;-)

/me waiting for comments and suggestions in DebConf6 in Mexico :-D

Thx, bye,
Gismo / Luca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060516/de16b5bc/attachment.sig>

From mb at bese.it  Wed May 17 10:11:03 2006
From: mb at bese.it (Marco Baringer)
Date: Wed, 17 May 2006 12:11:03 +0200
Subject: [Bese-devel] Re: UCW Performance
References: <9bbf67fa0605161134v7e8da8am3b8ed9d7132d64ae@mail.gmail.com>
Message-ID: <m2ves5j70o.fsf@bese.it>

"Rafal Rusin" <rafal.rusin at gmail.com> writes:

> Hello,
>
> I've just launched a great UCW demo from
> http://www.fallenfrukt.com/ucw-intro.html
> and noticed that it has about 5 req./sec. on increase counter on sbcl. I used
> apache benchmark (ab) and centrino 1,5 GHz machine.
> Is UCW really that that slow? Maybe it's just a backend fault or something.

ucw is definetly not a speed deamon, but 5 req/sec is pretty
bad. could you do some profiling (with sb-sprof) and see where all
that time is being spent?

-- 
-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 albertosantini at gmail.com  Wed May 17 20:01:05 2006
From: albertosantini at gmail.com (Alberto Santini)
Date: Wed, 17 May 2006 22:01:05 +0200
Subject: [Bese-devel] How to return multiple values from a form...
Message-ID: <6a066ca20605171301i4940b5b1lbb4ab747ed9fc862@mail.gmail.com>

Hello.

A newbie question.

The code included runs, but it doesn't work fine.

I would like to pass pgn-title and pgn-string values to
the second page/component, but I cannot write something
in the form element:
...
 (ok window pgn-title pgn-string)
...

So, of course, I'm missing something or, maybe, I have to switch
to another approach: maybe I have to use an instance of simple-form
component.

Thanks in advance,
Alberto Santini


--------------------------------------
(in-package :cl-user)

(defpackage :it.albertosantini.chessweb
  (:use :common-lisp
	:it.bese.ucw))

(in-package :it.albertosantini.chessweb)

(defvar *chessweb-app*
  (make-instance 'cookie-session-application :url-prefix "/chessweb/"))

(register-application *default-server* *chessweb-app*)

(defentry-point "index.ucw" (:application *chessweb-app*) ()
  (loop
     (multiple-value-bind (pgn-title pgn-string) (call 'pgn-publisher)
       (call 'create-html-pgn :pgn-title pgn-title :pgn-string pgn-string))))

(defcomponent pgn-publisher (simple-window-component)
  ()
  (:default-initargs :title "ChessWeb Publisher"))

(defmethod render ((window pgn-publisher))
  (<:h1 "ChessWeb Publisher")
  (let ((pgn-title "")
	(pgn-string ""))
    (<ucw:form :action (ok window pgn-string)
	       (<:as-html "PGN Page Title: ")
	       (<ucw:input :accessor pgn-title)
	       (<:br)
	       (<ucw:textarea :accessor pgn-string :rows 10 :cols 64)
	       (<:br)
	       (<:submit :value "Publish"))))

(defcomponent create-html-pgn (simple-window-component)
  ((pgn-title :accessor pgn-title :initarg :pgn-title)
   (pgn-string :accessor pgn-string :initarg :pgn-string))
  (:default-initargs :title "ChessWeb Page"))

(defmethod render ((window create-html-pgn))
  (<:h1 (pgn-title window))
  (<:as-html (pgn-string window)) (<:br) (<:br)
  (<ucw:a :action (ok window) "Back"))


From cjstuij at gmail.com  Wed May 17 21:46:26 2006
From: cjstuij at gmail.com (Ties Stuij)
Date: Wed, 17 May 2006 23:46:26 +0200
Subject: [Bese-devel] How to return multiple values from a form...
In-Reply-To: <6a066ca20605171301i4940b5b1lbb4ab747ed9fc862@mail.gmail.com>
References: <6a066ca20605171301i4940b5b1lbb4ab747ed9fc862@mail.gmail.com>
Message-ID: <d7ce4ebf0605171446o7ee1a2ebs1914fd17106d2bd3@mail.gmail.com>

> Hello.

he

> A newbie question.

> (defentry-point "index.ucw" (:application *chessweb-app*) ()
>   (loop
>      (multiple-value-bind (pgn-title pgn-string) (call 'pgn-publisher)
>        (call 'create-html-pgn :pgn-title pgn-title :pgn-string pgn-string))))

well, first of all, defentrypoint always functions as a loop, second,
if you call pgn from create-html-pgn and you answer, you come back to
create-html-pgn. So you can define defentry-point like this:

(defentry-point "index.ucw" (:application *chessweb-app*) ()
  (call 'pgn-publisher))

>
> (defcomponent pgn-publisher (simple-window-component)
>   ()
>   (:default-initargs :title "ChessWeb Publisher"))
>
> (defmethod render ((window pgn-publisher))
>   (<:h1 "ChessWeb Publisher")
>   (let ((pgn-title "")
>         (pgn-string ""))
>     (<ucw:form :action (ok window pgn-string)
>                (<:as-html "PGN Page Title: ")
>                (<ucw:input :accessor pgn-title)
>                (<:br)
>                (<ucw:textarea :accessor pgn-string :rows 10 :cols 64)
>                (<:br)
>                (<:submit :value "Publish"))))

here you pass only pgn-string to the ok action which takes only one
argument while you also want to pass pgn-title. Or so i prosume
because you wanted to catch them both with a multiple-value-bind in
the defentry-point. Anyway, lets just make a defaction:

(defaction to-html-pgn ((w pgn-publisher) title string)
  (call 'create-html-pgn :pgn-title title :pgn-string string))

and call it from the png-publisher render method:
...
        (pgn-string ""))
    (<ucw:form :action (to-html-pgn window pgn-title pgn-string)
               (<:as-html "PGN Page Title: ")
...


>
> (defcomponent create-html-pgn (simple-window-component)
>   ((pgn-title :accessor pgn-title :initarg :pgn-title)
>    (pgn-string :accessor pgn-string :initarg :pgn-string))
>   (:default-initargs :title "ChessWeb Page"))
>
> (defmethod render ((window create-html-pgn))
>   (<:h1 (pgn-title window))
>   (<:as-html (pgn-string window)) (<:br) (<:br)
>   (<ucw:a :action (ok window) "Back"))

and in the render method above you forgot to (<:as-html.. the title:

(defmethod render ((window create-html-pgn))
  (<:h1 (<:as-html (pgn-title window)))
  (<:as-html (pgn-string window)) (<:br) (<:br)
  (<ucw:a :action (ok window) "Back"))


Well that works for me anyway, hope it helps.

greets,
Ties


From rtvd at mail.ru  Sat May 20 16:48:23 2006
From: rtvd at mail.ru (Rtveliashvili Denys)
Date: Sat, 20 May 2006 20:48:23 +0400
Subject: [Bese-devel] Looking for a simple working example
Message-ID: <27F1E2D6-3AE8-4763-9EA3-ACAE2E545DE8@mail.ru>

Hi!

I recently downloaded and installed UnCommon Web. Everything works  
fine, but I have no luck in writing my own application  based on UCW.

I read different tutorials and tried UnCommon Web examples as a  
guideline, but still I can not create a simple application with a  
single page on a specified URL. Maybe it is because I am not a guru  
in Common LISP. But anyway, a working example of a simple application  
would be a good starting point for those who are interested in  
UnCommon Web. What I am looking for is a small application with its  
own .asd file and minimal functionality (even showing a static page  
would be OK).
Could somebody suggest me some kind of working example?

Currently I am stuck with a strange issue that I can not define an  
entry point. When I write something like

(defentry-point "bench.ucw" (:application *bench-application*) ()
   (call 'bench-page))

I receive the following error during the build:

   There is no applicable method for the generic function
     #<STANDARD-GENERIC-FUNCTION IT.BESE.UCW::REGISTER-ENTRY-POINT (2)>
   when called with arguments
     (NIL "/bench/bench.ucw" #<IT.BESE.UCW::STANDARD-ENTRY-POINT  
{B898E81}>).

Thank you,
Denys R.


From ctdean at sokitomi.com  Sun May 21 01:31:20 2006
From: ctdean at sokitomi.com (Chris Dean)
Date: Sat, 20 May 2006 18:31:20 -0700
Subject: [Bese-devel] Looking for a simple working example
In-Reply-To: <27F1E2D6-3AE8-4763-9EA3-ACAE2E545DE8@mail.ru> (Rtveliashvili
	Denys's message of "Sat, 20 May 2006 20:48:23 +0400")
References: <27F1E2D6-3AE8-4763-9EA3-ACAE2E545DE8@mail.ru>
Message-ID: <m2d5e86u53.fsf@tungsten.sokitomi.com>


Rtveliashvili Denys <rtvd at mail.ru> writes:
> I recently downloaded and installed UnCommon Web. Everything works
> fine, but I have no luck in writing my own application based on UCW.

I'm a casual user of UCW, but the standalone code below works for me.
Maybe it will be a good starting point for you.

Hope it's useful!

Regards,
Chris Dean


(defparameter *sample-index*
  (make-instance 'cookie-session-application :url-prefix "/sample"
                  :dispatchers (list (regexp-dispatcher "^/?$"
                                       (call 'sample-home-page)))))

(defcomponent sample-home-page (simple-window-component) 
  ((value :accessor value-of :initarg :value :initform nil))
  (:default-initargs :title "Simple factorial"))

(defun factorial (n)
  (if (< n 2)
      1
      (* n (factorial (1- n)))))

(defmethod render ((sample sample-home-page))
  (<ucw:form :method "GET"
             :action (refresh-component sample)
             (<ucw:text :accessor (value-of sample))
             (<:submit :value "Calculate Factorial"))
  (when (value-of sample)
    (<:p (<:as-html (value-of sample))
         "! => "
         (<:as-html (factorial (parse-integer (value-of sample)))))))

(ucw:create-server :backend '(:httpd :port 8080)
                   :log-level (symbol-value '+debug+)
                   :start-p t)

(setf ucw:*inspect-components* t)

(register-application *default-server* *sample-index*)



From eslick at csail.mit.edu  Sun May 21 02:27:03 2006
From: eslick at csail.mit.edu (Ian Eslick)
Date: Sat, 20 May 2006 22:27:03 -0400
Subject: [Bese-devel] aserve backend refers to deprecated class
Message-ID: <446FCFF7.7010808@csail.mit.edu>

I was just getting back to UCW after a long hiatus based on the current
state of ucw_dev and the relevant libraries and discovered that the
aserve backend which I use seems to depend on a deprecated class
'standard-entry-point'.  I can find no definition of this class within
the source tree and it's the only backend which refers to it.

Any guidance?

Error:

No class named: IT.BESE.UCW::STANDARD-ENTRY-POINT.
   [Condition of type PROGRAM-ERROR]

Trace:

Backtrace:
  0: (SWANK::DEBUG-IN-EMACS #<PROGRAM-ERROR @ #x119e6c3a>)
  1: (SWANK:SWANK-DEBUGGER-HOOK #<PROGRAM-ERROR @ #x119e6c3a> #<Function
SWANK-DEBUGGER-HOOK>)
  2: (CERROR "Try finding the class again" PROGRAM-ERROR :FORMAT-CONTROL
"No class named: ~S." :FORMAT-ARGUMENTS (IT.BESE.UCW::STANDARD-ENTRY-POINT))
  3: (FIND-CLASS IT.BESE.UCW::STANDARD-ENTRY-POINT)
  4: ((:TOP-LEVEL-FORM "aserve.lisp" 1155))
  5: (LOAD
#P"/Users/eslick/Work/fsrc/lisp/ucw_dev/src/backend/allegro-8.0-macosx-powerpc/aserve.fasl")



From frido at q-software-solutions.de  Sun May 21 07:05:43 2006
From: frido at q-software-solutions.de (Friedrich Dominicus)
Date: Sun, 21 May 2006 09:05:43 +0200
Subject: [Bese-devel] Looking for a simple working example
In-Reply-To: <27F1E2D6-3AE8-4763-9EA3-ACAE2E545DE8@mail.ru> (Rtveliashvili
	Denys's message of "Sat, 20 May 2006 20:48:23 +0400")
References: <27F1E2D6-3AE8-4763-9EA3-ACAE2E545DE8@mail.ru>
Message-ID: <87d5e7dfi0.fsf@flarge.here>

Rtveliashvili Denys <rtvd at mail.ru> writes:

>
> (defentry-point "bench.ucw" (:application *bench-application*) ()
>    (call 'bench-page))
>
> I receive the following error during the build:
>
>    There is no applicable method for the generic function
>      #<STANDARD-GENERIC-FUNCTION IT.BESE.UCW::REGISTER-ENTRY-POINT (2)>
>    when called with arguments
>      (NIL "/bench/bench.ucw" #<IT.BESE.UCW::STANDARD-ENTRY-POINT
> {B898E81}>).

Well have you declared the *bench-application* ?


Regards
Friedrich


From mb at bese.it  Sun May 21 16:55:37 2006
From: mb at bese.it (Marco Baringer)
Date: Sun, 21 May 2006 18:55:37 +0200
Subject: [Bese-devel] aserve backend refers to deprecated class
In-Reply-To: <446FCFF7.7010808@csail.mit.edu> (Ian Eslick's message of "Sat,
	20 May 2006 22:27:03 -0400")
References: <446FCFF7.7010808@csail.mit.edu>
Message-ID: <m2odxrs4fq.fsf@bese.it>

Ian Eslick <eslick at csail.mit.edu> writes:

> I was just getting back to UCW after a long hiatus based on the current
> state of ucw_dev and the relevant libraries and discovered that the
> aserve backend which I use seems to depend on a deprecated class
> 'standard-entry-point'.  I can find no definition of this class within
> the source tree and it's the only backend which refers to it.
>
> Any guidance?

due to various issues i haven't updated the aserve backend in a long
time. there have been some changes to the backend protocol (like the
removal af standard-entry-point). it shouldn't be too hard to fix it
but i don't know when i personally will have the time to do it.

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


From sylvain.louboutin at aerloman.com  Mon May 22 07:22:19 2006
From: sylvain.louboutin at aerloman.com (Sylvain Louboutin)
Date: Mon, 22 May 2006 00:22:19 -0700
Subject: [Bese-devel] [Besde-devel] Looking for a simple working example
Message-ID: <20060522072219.GA23770@aerloman.com>

neat,  except that I didn't manage to get it to run as is;   the
part with 

(register-application *default-server* *sample-index*)

causes  the following error (using sbcl):

  There is no applicable method for the generic function
      #<STANDARD-GENERIC-FUNCTION REGISTER-APPLICATION (1)>
        when called with arguments
            (NIL #<COOKIE-SESSION-APPLICATION "/sample" {118854F9}>).

however,  if I comment this line out,  and instead do a 

(setf *ucw-applications* '(it.bese.ucw-user::*sample-index*))

...which I naively thought should be doing the same thing,  then it
works as advertised.

--Sylvain (completely new to this... so please be patient)

ps ...and I am still trying to figure out how to make a simple example
like this running in its own package/name space without having to muck
around in it.bese.ucw-user.


On Sun, May 21, 2006 at 01:31:49AM +0000, bese-devel-bounces at common-lisp.net wrote:
> (defparameter *sample-index*
>   (make-instance 'cookie-session-application :url-prefix "/sample"
>                   :dispatchers (list (regexp-dispatcher "^/?$"
>                                        (call 'sample-home-page)))))
> 
<...snip...>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060522/73676cda/attachment.sig>

From ctdean at sokitomi.com  Mon May 22 08:21:54 2006
From: ctdean at sokitomi.com (Chris Dean)
Date: Mon, 22 May 2006 01:21:54 -0700
Subject: [Bese-devel] [Besde-devel] Looking for a simple working example
In-Reply-To: <20060522072219.GA23770@aerloman.com> (Sylvain Louboutin's
	message of "Mon, 22 May 2006 00:22:19 -0700")
References: <20060522072219.GA23770@aerloman.com>
Message-ID: <m2mzda5v19.fsf@tungsten.sokitomi.com>


Well, I'm glad it's running.  That's a good step!

> (register-application *default-server* *sample-index*)
>
> causes  the following error (using sbcl):
>
>   There is no applicable method for the generic function
>       #<STANDARD-GENERIC-FUNCTION REGISTER-APPLICATION (1)>
>         when called with arguments
>             (NIL #<COOKIE-SESSION-APPLICATION "/sample"
>             {118854F9}>).

Sounds like we're dealing with packages differently.  I load (using
asdf) :ucw and in my defpackage I import (that is, use) :it.bese.ucw
and :it.bese.yaclml

Untested code, but something like this:

In mypackage.asd:

    (defpackage #:mypackage-system
      (:use #:cl #:asdf))

    (in-package #:mypackage-system)

    (defsystem #:mypackage
      :depends-on (#:ucw)
      :components ((:module :src :components ((:file "mypackage")))))

In src/mypackage.lisp:

    (in-package #:cl-user)
    (defpackage #:mypackage
      (:use #:cl #:it.bese.ucw #:it.bese.yaclml))

    (in-package #:index)

    ... all the code from the previous email ...


Hope that helps.

Regards,
Chris Dean



From ctdean at sokitomi.com  Mon May 22 08:23:16 2006
From: ctdean at sokitomi.com (Chris Dean)
Date: Mon, 22 May 2006 01:23:16 -0700
Subject: [Bese-devel] [Besde-devel] Looking for a simple working example
In-Reply-To: <m2mzda5v19.fsf@tungsten.sokitomi.com> (Chris Dean's message of
	"Mon, 22 May 2006 01:21:54 -0700")
References: <20060522072219.GA23770@aerloman.com>
	<m2mzda5v19.fsf@tungsten.sokitomi.com>
Message-ID: <m2fyj25uyz.fsf@tungsten.sokitomi.com>


> In src/mypackage.lisp:
>
>     (in-package #:cl-user)
>     (defpackage #:mypackage
>       (:use #:cl #:it.bese.ucw #:it.bese.yaclml))
>
>     (in-package #:index)

Oops, that should be 

    (in-package #:mypackage)

Regards,
Chris Dean



From hoan at ton-that.org  Mon May 22 11:42:42 2006
From: hoan at ton-that.org (Hoan Ton-That)
Date: Mon, 22 May 2006 21:42:42 +1000
Subject: [Bese-devel] Code without a home
Message-ID: <e2c5eaf10605220442n5944c81ag5c25e244dd180014@mail.gmail.com>

Hello,

I have some code without a home, that I'd like to put in arnesi.

We have some convenience functions, Lisp-1 support and
a syntax for partial application.  I'd be very happy if this was
included in arnesi.

Hoan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CHANGESET
Type: application/octet-stream
Size: 41722 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060522/6e5a06dc/attachment.obj>

From sylvain.louboutin at aerloman.com  Mon May 22 22:04:58 2006
From: sylvain.louboutin at aerloman.com (Sylvain Louboutin)
Date: Mon, 22 May 2006 15:04:58 -0700
Subject: [Bese-devel] [Besde-devel] Looking for a simple working example
In-Reply-To: <m2mzda5v19.fsf@tungsten.sokitomi.com>
References: <20060522072219.GA23770@aerloman.com>
	<m2mzda5v19.fsf@tungsten.sokitomi.com>
Message-ID: <20060522220458.GA16247@aerloman.com>

On Mon, May 22, 2006 at 01:21:54AM -0700, Chris Dean wrote:
> Well, I'm glad it's running.  That's a good step!

:-)

> Sounds like we're dealing with packages differently.  

you solved my problem!  the thing I didn't understand (and I reckon I
now am starting to get it) is that I was trying to avoid the indirection
you make (by defining first mypackage-system then mypackage)  and that's
how I got all messed up with clashing definitions and all that (not sure
I am describing it correctly)

as I was saying,  I am new to this (UCW and Lisp),

thanks!

--Sylvain
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060522/fef15e33/attachment.sig>

From ctdean at sokitomi.com  Mon May 22 22:41:25 2006
From: ctdean at sokitomi.com (Chris Dean)
Date: Mon, 22 May 2006 15:41:25 -0700
Subject: [Bese-devel] [Besde-devel] Looking for a simple working example
In-Reply-To: <20060522220458.GA16247@aerloman.com> (Sylvain Louboutin's
	message of "Mon, 22 May 2006 15:04:58 -0700")
References: <20060522072219.GA23770@aerloman.com>
	<m2mzda5v19.fsf@tungsten.sokitomi.com>
	<20060522220458.GA16247@aerloman.com>
Message-ID: <m23bf14r8q.fsf@tungsten.sokitomi.com>


Sylvain Louboutin <sylvain.louboutin at aerloman.com> writes:
> as I was saying,  I am new to this (UCW and Lisp),

I've been where you are, and I can say the it's a steep climb up the
Lisp mountain.  But keep climbing, the view is pretty great.  I'm not
even at the top yet and it's still a fantastic view.

Regards,
Chris Dean




From hbabcockos1 at mac.com  Thu May 25 05:15:10 2006
From: hbabcockos1 at mac.com (hbabcockos1 at mac.com)
Date: Thu, 25 May 2006 01:15:10 -0400
Subject: [Bese-devel] Re: forcing a client refresh
In-Reply-To: <2871479.1146162666054.JavaMail.hbabcockos1@mac.com>
References: <6581572.1146075914643.JavaMail.hbabcockos1@mac.com>
	<m23bfzibzv.fsf@bese.it>
	<2871479.1146162666054.JavaMail.hbabcockos1@mac.com>
Message-ID: <1640D1D9-7C70-419C-B990-200FC508D663@mac.com>


> (defmacro timed-self-refresh (delay-in-ms)
>   `(<:script :type "text/javascript"
>     (<:as-is
>      (js:js
>       (defun init-timed-refresh-call ()
> 	(set-timeout "doTimedRefreshCall()" ,delay-in-ms))
>       (defun do-timed-refresh-call ()
> 	(window.location.reload))
>       (setf window.onload init-timed-refresh-call)))))

Another more useful refresh option, as I slowly learn more about ucw.  
It works with functions but not actions, it isn't clear to me why  
this is so.

(defun timed-function-call (delay-in-ms function argument)
   (let ((href (concatenate 'string "location.href='"
			   (action-href (lambda () (funcall function argument)))
			   "'")))
     (<ucw:script `(setf window.onload
		   (set-timeout ,href ,delay-in-ms)))))

-Hazen



From mb at bese.it  Fri May 26 11:07:23 2006
From: mb at bese.it (Marco Baringer)
Date: Fri, 26 May 2006 13:07:23 +0200
Subject: [Bese-devel] Re: forcing a client refresh
References: <6581572.1146075914643.JavaMail.hbabcockos1@mac.com>
	<m23bfzibzv.fsf@bese.it>
	<2871479.1146162666054.JavaMail.hbabcockos1@mac.com>
	<1640D1D9-7C70-419C-B990-200FC508D663@mac.com>
Message-ID: <m2d5e1doyc.fsf@bese.it>

hbabcockos1 at mac.com writes:

> Another more useful refresh option, as I slowly learn more about ucw.
> It works with functions but not actions, it isn't clear to me why
> this is so.
>
> (defun timed-function-call (delay-in-ms function argument)
>   (let ((href (concatenate 'string "location.href='"
> 			   (action-href (lambda () (funcall function argument)))
> 			   "'")))
>     (<ucw:script `(setf window.onload
> 		   (set-timeout ,href ,delay-in-ms)))))

an 'action' is a cc method (something defined with defmethod/cc
(defaction is a wrapper around defmethod/cc)). cc methods, when called
normally, return another function, which must be called again until a
DONE tag is thrown. the with-call/cc macro known this and handles it
properly, you'll notice that the <ucw tags (see
src/yaclml/ucw-tags.lisp) all use action-href like this:

`(action-href (lambda () (with-call/cc ,action)))

which is the only thing your code is missing:

(defun timed-function-call (delay-in-ms function argument)
  (let ((href (concatenate 'string "location.href='"
			   (action-href (lambda ()
                                          (with-call/cc
                                            (funcall function argument))))
			   "'")))
    (<ucw:script `(setf window.onload
		   (set-timeout ,href ,delay-in-ms)))))

now you can pass an action to timed-function-call, with-call/cc knows
how to handle normal (non /cc) functions as well so this change should
add functionatily while still allowing you to use it as before.

hth.
-- 
-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 rtvd at mail.ru  Fri May 26 11:38:21 2006
From: rtvd at mail.ru (Denis Rtveliashvili)
Date: Fri, 26 May 2006 15:38:21 +0400
Subject: [Bese-devel] UCW performance
Message-ID: <E1Fjae5-000FB6-00.rtvd-mail-ru@f21.mail.ru>

Hi everybody,

I am wondering, if it is possible to profile UCW-based applications somehow. For instance, JBoss server shows performance statistics for each of the Java servlets in an application deployed. I think it would be useful to have this feature if it does not exists yet. Or maybe it already exists?

With best regards,
Denys R.


From mb at bese.it  Fri May 26 13:54:12 2006
From: mb at bese.it (Marco Baringer)
Date: Fri, 26 May 2006 15:54:12 +0200
Subject: [Bese-devel] Re: UCW performance
References: <E1Fjae5-000FB6-00.rtvd-mail-ru@f21.mail.ru>
Message-ID: <m2r72gdh8b.fsf@bese.it>

Denis Rtveliashvili <rtvd at mail.ru> writes:

> Hi everybody,
>
> I am wondering, if it is possible to profile UCW-based applications
> somehow. For instance, JBoss server shows performance statistics for
> each of the Java servlets in an application deployed. I think it
> would be useful to have this feature if it does not exists yet. Or
> maybe it already exists?

wrapping the dispatchers in a TIME form is pretty easy (though
collecting the output will require some non-protable code), but i
think you'd be much better off using your lisp's profiler.

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



From mb at bese.it  Fri May 26 14:03:37 2006
From: mb at bese.it (Marco Baringer)
Date: Fri, 26 May 2006 16:03:37 +0200
Subject: [Bese-devel] Re: UCW performance
References: <E1Fjae5-000FB6-00.rtvd-mail-ru@f21.mail.ru>
	<m2r72gdh8b.fsf@bese.it>
Message-ID: <m2irnsdgsm.fsf@bese.it>

Marco Baringer <mb at bese.it> writes:

> wrapping the dispatchers in a TIME form is pretty easy (though
> collecting the output will require some non-protable code), but i
> think you'd be much better off using your lisp's profiler.

fwiw i mean something like this:

(in-package :ucw)

(defmethod handle-request :around ((server standard-server)
                                   (request request)
                                   (response response))
  (time (call-next-method)))

-- 
-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 hbabcockos1 at mac.com  Mon May 29 00:06:24 2006
From: hbabcockos1 at mac.com (hbabcockos1 at mac.com)
Date: Sun, 28 May 2006 20:06:24 -0400
Subject: [Bese-devel] Re: forcing a client refresh
In-Reply-To: <m2d5e1doyc.fsf@bese.it>
References: <6581572.1146075914643.JavaMail.hbabcockos1@mac.com>
	<m23bfzibzv.fsf@bese.it>
	<2871479.1146162666054.JavaMail.hbabcockos1@mac.com>
	<1640D1D9-7C70-419C-B990-200FC508D663@mac.com>
	<m2d5e1doyc.fsf@bese.it>
Message-ID: <7B10DDCA-75B6-416B-818A-89F413441694@mac.com>


On May 26, 2006, at 7:07 AM, Marco Baringer wrote:
>
> an 'action' is a cc method (something defined with defmethod/cc
> (defaction is a wrapper around defmethod/cc)). cc methods, when called
> normally, return another function, which must be called again until a
> DONE tag is thrown. the with-call/cc macro known this and handles it
> properly, you'll notice that the <ucw tags (see
> src/yaclml/ucw-tags.lisp) all use action-href like this:
>
> `(action-href (lambda () (with-call/cc ,action)))
>
> which is the only thing your code is missing:
>
> (defun timed-function-call (delay-in-ms function argument)
>   (let ((href (concatenate 'string "location.href='"
> 			   (action-href (lambda ()
>                                           (with-call/cc
>                                             (funcall function  
> argument))))
> 			   "'")))
>     (<ucw:script `(setf window.onload
> 		   (set-timeout ,href ,delay-in-ms)))))
>
> now you can pass an action to timed-function-call, with-call/cc knows
> how to handle normal (non /cc) functions as well so this change should
> add functionatily while still allowing you to use it as before.

Thanks for the help! I think that you have to re-write this as a  
macro to use it with actions & with-call/cc, which makes it a little  
cleaner anyway since you don't need one (or more) argument parameters.

(defmacro timed-function-call (delay-in-ms function-call)
   (let ((g0 (gensym)))
     `(let ((,g0 (concatenate 'string "location.href='"
			     (action-href (lambda ()
					    (arnesi:with-call/cc
					      ,function-call)))
			     "'")))
       (<ucw:script (list 'setf 'window.onload
		    (list 'set-timeout ,g0 ,delay-in-ms))))))

-Hazen



From damir at x-si.org  Mon May 29 08:26:58 2006
From: damir at x-si.org (Damir Horvat)
Date: Mon, 29 May 2006 10:26:58 +0200
Subject: [Bese-devel] ucw boxset problems
Message-ID: <20060529082658.GA7884@semp.x-si.org>

Hi!

I've just downloaded boxset from ucw's home page. When I load start.lisp
I get this: (system is freebsd 5.2 and 6.0)


damir at semp$ cat ~/.cmucl-init.lisp
damir at semp$ lisp
; Loading #P"/newfs/home/damir/.cmucl-init.lisp".
CMU Common Lisp 19c Release (19C), running on semp.x-si.org
With core: /usr/local/lib/cmucl/lib/lisp.core
Dumped on: Thu, 2005-11-17 02:18:11+01:00 on snapdragon.csl.sri.com
See <http://www.cons.org/cmucl/> for support information.
Loaded subsystems:
    Python 1.1, target Intel x86
    CLOS based on Gerd's PCL 2004/04/14 03:32:47
* (load "start.lisp")

; Loading #P"/newfs/home/damir/lisp/dl/ucw-boxset/start.lisp".
;; Loading #P"/newfs/home/damir/lisp/dl/ucw-boxset/load-asdf.lisp".
;;; Loading #P"/newfs/home/damir/lisp/dl/ucw-boxset/asdf/asdf.lisp".
;;; Loading
#P"/newfs/home/damir/lisp/dl/ucw-boxset/arnesi_dev/arnesi.asd".

Unable to display error condition
   [Condition of type 

Unable to display error condition
   [Condition of type 

Unable to display error condition
   [Condition of type 

Unable to display error condition
   [Condition of type Help! 11 nested errors.
KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.

Debug  (type H for help)

(LISP::FIND-SYMBOL* "OBJECT-NOT-TYPE-ERROR-HANDLER" 29 NIL)
Help! 12 nested errors.  KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.

Debug  (type H for help)

(DEBUG::DEBUG-LOOP)
Source: 
* (quit)


Any ideas? 

Regards,
Damir


From marijnh at gmail.com  Mon May 29 17:32:16 2006
From: marijnh at gmail.com (Marijn Haverbeke)
Date: Mon, 29 May 2006 19:32:16 +0200
Subject: [Bese-devel] A few UCW issues
Message-ID: <befaa7aa0605291032v50c76052v62079691220d63de@mail.gmail.com>

Hello list,

If this is not the right place for questions concerning UCW, please point me
to wherever those are appropriate.

I've started trying to get a UCW project off the ground a few weeks ago, and
by now I'm starting to get somewhat comfortable with the framework. A few
things I haven't managed to figure out yet though:

- Is there a supported way to get header variables out of a request object?
I can just access the headers slot using ucw::headers, but that's not very
nice.

- Also, is there a way to set headers for a response? I need one header
added to every response the server generates, but I haven't been able to
find a way to even set a header in a single response.

- Is it a problem to call multiple components that never answer? I suppose
this would build up some kind of call stack... is there a way to do a 'tail
call' - replacing the current component with another one?

Thanks,
Marijn Haverbeke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060529/0ae7c058/attachment.html>

From mb at bese.it  Mon May 29 18:48:05 2006
From: mb at bese.it (Marco Baringer)
Date: Mon, 29 May 2006 20:48:05 +0200
Subject: [Bese-devel] Re: A few UCW issues
References: <befaa7aa0605291032v50c76052v62079691220d63de@mail.gmail.com>
Message-ID: <m28xokwtui.fsf@bese.it>

"Marijn Haverbeke" <marijnh at gmail.com> writes:

> Hello list,
>
> If this is not the right place for questions concerning UCW, please point me to
> wherever those are appropriate.

this is the right place, the name of the list is due to ucw having
grown out the bese umbrella project on cl.net. as it currently stands
there is 95% ucw chat on this list and 5% arnesi+fiveam+qbook chat, so
be it.

> I've started trying to get a UCW project off the ground a few weeks ago, and by
> now I'm starting to get somewhat comfortable with the framework. A few things I
> haven't managed to figure out yet though:
>
> - Is there a supported way to get header variables out of a request object? I
> can just access the headers slot using ucw::headers, but that's not very nice.
>
> - Also, is there a way to set headers for a response? I need one header added
> to every response the server generates, but I haven't been able to find a way
> to even set a header in a single response.

the get-header and (setf get-header) methods are defined for both
request and response object. [get-header on a response is silly, as is
(setf get-header) on a request].

currently there is no 'normalizing' of headers, so if IE for mac
decides to send the header as Accept-encoding, and the rest of world
does it as Accept-Encoding you're sol.

> - Is it a problem to call multiple components that never answer? I suppose this
> would build up some kind of call stack... is there a way to do a 'tail call' -
> replacing the current component with another one?

yes, a component which never answers will cause its parent component
to never get garbage collected. unlike some other things in ucw (like
infinite length frame lists and request callbacks) extra components
have a minimal overhead. I wouldn't worry about it until profiling
shows that it's a problem (and i promise you it will never be as big a
problem as writing the html out).

if it were to give you warm fuzzy feelings here's what you'd need to
do:

(setf (component.calling-component my-component) nil)

where my-component is the one that nevers answer. now, as long as
nobody else has a reference to my-component's calling component, your
lisp is free to GC the 60 or so bytes occupied by the component.

hth.
-- 
-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 hbabcockos1 at mac.com  Mon May 29 22:58:38 2006
From: hbabcockos1 at mac.com (hbabcockos1 at mac.com)
Date: Mon, 29 May 2006 18:58:38 -0400
Subject: [Bese-devel] utf-8 encoding problem
Message-ID: <0E875E0C-8AE6-4807-8584-DE1D4EFA7D77@mac.com>


Hello,

I updated my version of UCW today and now I'm struggling to get utf8  
strings to my browser in a form that it can understand. If I try  
something like this:

(defun utf8-string ()
   (let ((my-string (make-array 3 :element-type 'character :initial- 
element #\SPACE)))
     (setf (char my-string 0) (code-char #xE5))
     (setf (char my-string 1) (code-char #x91))
     (setf (char my-string 2) (code-char #xB5))
     my-string))

(<:p (<:as-html (utf8-string)))     ; this would be in a render function

I don't get what I expect (which is a character in chinese). If I  
save the page in my browser and use more to read it, it looks like  
the 3 characters in my-string have become 6 characters. This worked  
in my 1.5 month old version of UCW, so maybe something changed since  
then? Do I need to specify the encoding anywhere besides in  
component/:content-type?

thanks,
-Hazen



From rtvd at mail.ru  Tue May 30 04:47:19 2006
From: rtvd at mail.ru (Denis Rtveliashvili)
Date: Tue, 30 May 2006 08:47:19 +0400
Subject: [Bese-devel] " center " tag
Message-ID: <E1Fkw8V-00055t-00.rtvd-mail-ru@f21.mail.ru>

Hi,

I propose to add support for <center> tag into yaclml. Sometimes it is quite handy to wrap something into it to make the content centered. And the tag is a part of HTML 4.01 specification.

With best regards,
Denys R.


From steve at salkin.org  Tue May 30 10:19:01 2006
From: steve at salkin.org (Steve Salkin)
Date: Tue, 30 May 2006 06:19:01 -0400
Subject: [Bese-devel] Problem with UCW under SBCL 0.9.13.8 (0.9.13.4 +?)
Message-ID: <447C1C15.3050808@salkin.org>

Hi,

I am trying to build UCW from head using SBCL from head. Here's a 
somewhat redacted version of the output:

This is SBCL 0.9.13.8, an implementation of ANSI Common Lisp.
[...]
STYLE-WARNING: redefining INITIALIZE-BACKTRACKING in DEFUN
STYLE-WARNING: redefining INITIALIZE-COMPONENT-SLOTS in DEFUN

debugger invoked on a SIMPLE-ERROR in thread
#<THREAD "initial thread" {B75C4E9}>:
  Error during processing of --eval option "(asdf:operate 'asdf:load-op 
:ucw)":

  Cannot add method
  #<STANDARD-METHOD NIL (STANDARD-COMPONENT STANDARD-COMPONENT-CLASS
                                            STANDARD-COMPONENT
                                            
STANDARD-COMPONENT-EFFECTIVE-SLOT) {BB7F1E9}>
  to #<STANDARD-GENERIC-FUNCTION (SETF SB-MOP:SLOT-VALUE-USING-CLASS) 
(3)>, as
  it specializes the new-value argument.
See also:
  The SBCL Manual, Node "Metaobject Protocol"
  AMOP, Generic Function (SETF SB-MOP:SLOT-VALUE-USING-CLASS)

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [RETRY   ] Retry performing #<ASDF:LOAD-OP NIL {B8BD2E1}> on
                #<ASDF:CL-SOURCE-FILE "standard-component" {B70FC29}>.
  1: [ACCEPT  ] Continue, treating #<ASDF:LOAD-OP NIL {B8BD2E1}> on
                #<ASDF:CL-SOURCE-FILE "standard-component" {B70FC29}> as 
having
                been successful.
  2: [CONTINUE] Ignore and continue with next --eval option.
  3: [ABORT   ] Skip rest of --eval options.
  4:            Skip to toplevel READ/EVAL/PRINT loop.
  5: [QUIT    ] Quit SBCL (calling #'QUIT, killing the process).

((LAMBDA (SB-IMPL::E)) #<SB-PCL::NEW-VALUE-SPECIALIZATION {BB7F541}>)

It's actually not a matter of special urgency to get this working, I was 
just updating some packages to current and generating a new base image 
to use when this cropped up. Since no one else has mentioned it, either 
it's just me or no one else is on SBCL head. However I think it's the 
latter, since SBCL 0.9.13.4 has a commit message from Christophe Rhodes 
saying, in part, "Explicitly disallow specializations on new-value for 
(setf slot-value-using-class), as suggested by Levente Mezaros." So I 
gather that more people will run into it next month unless one or the 
other of SBCL and UCW changes.

S-


From mb at bese.it  Tue May 30 10:52:09 2006
From: mb at bese.it (Marco Baringer)
Date: Tue, 30 May 2006 12:52:09 +0200
Subject: [Bese-devel] Re: utf-8 encoding problem
References: <0E875E0C-8AE6-4807-8584-DE1D4EFA7D77@mac.com>
Message-ID: <m27j437pk6.fsf@bese.it>

hbabcockos1 at mac.com writes:

> I don't get what I expect (which is a character in chinese). If I
> save the page in my browser and use more to read it, it looks like
> the 3 characters in my-string have become 6 characters. This worked
> in my 1.5 month old version of UCW, so maybe something changed since
> then? Do I need to specify the encoding anywhere besides in
> component/:content-type?

we've recently tried to make utf-8 output easier, or so we thought...

inside yaclml you should use (<:p #\MY-CHINESE-CHARACTER), this will
put the character onto the response's html-stream, which is a
character stream. the response has an external-format slot which
should be a keyword specifying some encoding, :utf-8 in your case (or
something else if the underlyinglisp supports it). whan the response
is written out to the client as a _binary_ stream we use the lisp's
character-encoding facilities to convert it to the proper sequence of
bytes. the encoding can also be set per-application with the charset
slot on standard-application (sorry for the confusing names), or
through (setf (external-format-for :http) :utf-8). this encoding stuff
is rather new-ish (though it is used and sholud work), if you run into
an issues please inform 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 mb at bese.it  Tue May 30 10:54:12 2006
From: mb at bese.it (Marco Baringer)
Date: Tue, 30 May 2006 12:54:12 +0200
Subject: [Bese-devel] Re: Problem with UCW under SBCL 0.9.13.8 (0.9.13.4 +?)
References: <447C1C15.3050808@salkin.org>
Message-ID: <m23ber7pgr.fsf@bese.it>

Steve Salkin <steve at salkin.org> writes:

>  Cannot add method
>  #<STANDARD-METHOD NIL (STANDARD-COMPONENT STANDARD-COMPONENT-CLASS
>                                            STANDARD-COMPONENT
>                                            STANDARD-COMPONENT-EFFECTIVE-SLOT)
> {BB7F1E9}>
>  to #<STANDARD-GENERIC-FUNCTION (SETF SB-MOP:SLOT-VALUE-USING-CLASS)
> (3)>, as
>  it specializes the new-value argument.
> See also:
>  The SBCL Manual, Node "Metaobject Protocol"
>  AMOP, Generic Function (SETF SB-MOP:SLOT-VALUE-USING-CLASS)
>
> Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

that sucks :(

i have much better odds of adjusting ucw to christophe's choices than
adjusting christophe's choices to ucw....

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



From mb at bese.it  Tue May 30 10:57:07 2006
From: mb at bese.it (Marco Baringer)
Date: Tue, 30 May 2006 12:57:07 +0200
Subject: [Bese-devel] Re: " center " tag
References: <E1Fkw8V-00055t-00.rtvd-mail-ru@f21.mail.ru>
Message-ID: <m2y7wj6arg.fsf@bese.it>

Denis Rtveliashvili <rtvd at mail.ru> writes:

> Hi,
>
> I propose to add support for <center> tag into yaclml. Sometimes it
> is quite handy to wrap something into it to make the content
> centered. And the tag is a part of HTML 4.01 specification.

this has 0 priority for me. patches welcome though.

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



From mb at bese.it  Tue May 30 11:12:32 2006
From: mb at bese.it (Marco Baringer)
Date: Tue, 30 May 2006 13:12:32 +0200
Subject: [Bese-devel] Re: Problem with UCW under SBCL 0.9.13.8 (0.9.13.4 +?)
References: <447C1C15.3050808@salkin.org> <m23ber7pgr.fsf@bese.it>
Message-ID: <m2odxf6a1r.fsf@bese.it>

Marco Baringer <mb at bese.it> writes:

> that sucks :(

no, it doesn't suck. as attila was so kind point out i'm being stupid.

fixed.

-- 
-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 attila.lendvai at gmail.com  Tue May 30 11:17:37 2006
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Tue, 30 May 2006 13:17:37 +0200
Subject: [Bese-devel] Re: Problem with UCW under SBCL 0.9.13.8 (0.9.13.4
	+?)
In-Reply-To: <m2odxf6a1r.fsf@bese.it>
References: <447C1C15.3050808@salkin.org> <m23ber7pgr.fsf@bese.it>
	<m2odxf6a1r.fsf@bese.it>
Message-ID: <b54b34af0605300417h1a87886fu455860c9b64f0246@mail.gmail.com>

> > that sucks :(
>
> no, it doesn't suck. as attila was so kind point out i'm being stupid.

nah, you were only missing some info, as we were when this
according-to-the-standard behaviour silently bit us...

at least it's not silent anymore.

- attila

(alias 101 on irc &no 'its not lisp code :)


From maciekp at japhy.fnord.org  Tue May 30 12:45:31 2006
From: maciekp at japhy.fnord.org (Maciek Pasternacki)
Date: Tue, 30 May 2006 14:45:31 +0200
Subject: [Bese-devel] utf-8 encoding problem
In-Reply-To: <0E875E0C-8AE6-4807-8584-DE1D4EFA7D77@mac.com>
	(hbabcockos1@mac.com's message of "Mon, 29 May 2006 18:58:38 -0400")
References: <0E875E0C-8AE6-4807-8584-DE1D4EFA7D77@mac.com>
Message-ID: <8764jnzno4.fsf@lizard.king>

On Setting Orange, Confusion 4, 3172 YOLD, hbabcockos1 at mac.com wrote:

> I updated my version of UCW today and now I'm struggling to get utf8
> strings to my browser in a form that it can understand. If I try
> something like this:
>
> (defun utf8-string ()
>   (let ((my-string (make-array 3 :element-type 'character :initial- 
> element #\SPACE)))
>     (setf (char my-string 0) (code-char #xE5))
>     (setf (char my-string 1) (code-char #x91))
>     (setf (char my-string 2) (code-char #xB5))
>     my-string))
>
> (<:p (<:as-html (utf8-string)))     ; this would be in a render function

Because strings are not sequences of bytes, but of characters. Just
use a string with real Unicode characters.  Which Lisp implementation
are you using?  Which UCW backend?  Httpd backend on SBCL and Clisp
should work, I'm not sure about other combinations.

-- 
__    Maciek Pasternacki <maciekp at japhy.fnord.org> [ http://japhy.fnord.org/ ]
`| _   |_\  / { Hac in hora sine mora corde pulsum tangite;
,|{-}|}| }\/         quod per sortem sternit fortem, mecum omnes plangite!   }
\/   |____/                                           ( Carmina Burana )  -><-


From marijnh at gmail.com  Tue May 30 10:02:30 2006
From: marijnh at gmail.com (Marijn Haverbeke)
Date: Tue, 30 May 2006 12:02:30 +0200
Subject: [Bese-devel] Re: A few UCW issues
In-Reply-To: <m28xokwtui.fsf@bese.it>
References: <befaa7aa0605291032v50c76052v62079691220d63de@mail.gmail.com>
	<m28xokwtui.fsf@bese.it>
Message-ID: <befaa7aa0605300302h3dbb6a9frdbe75931926d53c5@mail.gmail.com>

Hi,

On 5/29/06, Marco Baringer <mb at bese.it> wrote:
>
> "Marijn Haverbeke" <marijnh at gmail.com> writes:
> > - Is there a supported way to get header variables out of a request
> object? I
> > can just access the headers slot using ucw::headers, but that's not very
> nice.
> > - Also, is there a way to set headers for a response? I need one header
> added
> > to every response the server generates, but I haven't been able to find
> a way
> > to even set a header in a single response.
>
> the get-header and (setf get-header) methods are defined for both
> request and response object. [get-header on a response is silly, as is
> (setf get-header) on a request].


But in my version of UCW (straight from darcs  repo), ucw::get-header is an
internal symbol... so  I assumed it was not part of the interface. Is this
for a reason? Are library users supposed to just use internal symbols from
UCW?

if it were to give you warm fuzzy feelings here's what you'd need to
> do:
>
> (setf (component.calling-component my-component) nil)


I'm definitely feeling more warm and fuzzy now that I at least have a clue
what is going on. Thanks!

Regards,
Marijn Haverbeke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060530/cb4fd34c/attachment.html>

From vanek at acd.net  Tue May 30 18:46:05 2006
From: vanek at acd.net (Lou Vanek)
Date: Tue, 30 May 2006 18:46:05 +0000
Subject: [Bese-devel] let/cc
Message-ID: <447C92ED.4040403@acd.net>

Hi list,

I got araneida and ucw to start, but, as the error shows below, my first ucw
http request aborts. LET/CC is being expanded into CALL/CC and for some reason
CALL/CC is not defined. I haven't been able to parse marco's call/cc code to
know why.

Has anybody seen this?
I'm trying to run the ucw examples.

Environment:
. clisp 2.38
. winxp sp2 / cygwin
. ucw_dev    today's darcs
. araneida   today's darcs
. arnesi_dev today's darcs

Thanks,

Lou Vanek
SpeakerToMachines

P.S. If I don't respond immediately it's probably because I have to go to the gym.
Physical pain is my master now.


WARNING: Starting araneida with a default url of #<ARANEIDA:HTTP-URL "http://127.0.0.1:9000/" #x00675285>.
          You MUST use this hostname to access ucw.
--TIME MARK 2006-05-30--
13:24 UCW-LOGGER/+INFO+: Registered: #<STANDARD-APPLICATION "/admin/" #x00869B31>
13:24 UCW-LOGGER/+INFO+: Registered: #<COOKIE-SESSION-APPLICATION "/" #x0071F1D9>
13:24 UCW-LOGGER/+INFO+: Starting up standard server #<STANDARD-SERVER ARANEIDA-BACKEND 2 #x00C1AF71>.
13:24 UCW.BACKEND/+INFO+: Starting up ARANEIDA backend #<ARANEIDA-BACKEND #x00CE3D91> on http://127.0.0.1:9000/
13:24 UCW-LOGGER/+INFO+: URL-DISPATCHER matched, passing control to #<COMPILED-FUNCTION #:|51 54 (DEFENTRY-POINT "^(index.ucw\|)$" (:APPLICATION *EXAMPLE-APPLICATION* :CLASS ...) ...)-4-2|>.
WARNING: Reference to unknown function CALL/CC in
           (PROGN
            (LET/CC IT.BESE.UCW::K
             (SETF (IT.BESE.UCW::COMPONENT.CALLING-COMPONENT IT.BESE.UCW::TO) NIL (COMPONENT.PLACE IT.BESE.UCW::TO)
              (MAKE-PLACE (CONTEXT.WINDOW-COMPONENT *CONTEXT*)) (IT.BESE.UCW::COMPONENT.CONTINUATION IT.BESE.UCW::TO) IT.BESE.UCW::K
              (CONTEXT.WINDOW-COMPONENT *CONTEXT*) IT.BESE.UCW::TO)
             (IT.BESE.UCW::UCW.COMPONENT.INFO (FORMAT NIL "CALL'ing to ~{/~A~} " (IT.BESE.UCW::CALL-REQUEST-PATH IT.BESE.UCW::TO)))
             IT.BESE.UCW::TO))
          .
13:24 UCW-LOGGER/+INFO+: CALL'ing to /#<EXAMPLE-WINDOW #x00E4CB7D>
13:24 UCW-LOGGER/+ERROR+: Got request error #<CLOS:METHOD-CALL-ERROR #x00C29079>.
13:24 UCW-LOGGER/+INFO+: Aborting request


From mb at bese.it  Tue May 30 23:36:44 2006
From: mb at bese.it (Marco Baringer)
Date: Wed, 31 May 2006 01:36:44 +0200
Subject: [Bese-devel] Re: A few UCW issues
References: <befaa7aa0605291032v50c76052v62079691220d63de@mail.gmail.com>
	<m28xokwtui.fsf@bese.it>
	<befaa7aa0605300302h3dbb6a9frdbe75931926d53c5@mail.gmail.com>
Message-ID: <m28xojozjn.fsf@bese.it>

"Marijn Haverbeke" <marijnh at gmail.com> writes:

> But in my version of UCW (straight from darcs  repo), ucw::get-header is an
> internal symbol... so  I assumed it was not part of the interface. 

you assumed more or less correctly. you are correct in so far as you
should avoid internal ucw symbols, you are incorrect in believing that
i have put a lot of thought into the list of exported symbols :)

fixed in ucw_dev.

-- 
-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 marijnh at gmail.com  Wed May 31 11:11:45 2006
From: marijnh at gmail.com (Marijn Haverbeke)
Date: Wed, 31 May 2006 13:11:45 +0200
Subject: [Bese-devel] Validators manipulating stylesheets
Message-ID: <befaa7aa0605310411k163ea97fu5d544e49de40531e@mail.gmail.com>

Hi,

It seems there was a bug in javascript-invalid-handler that caused it to
just add the ucw-form-field-invalid class to elements without removing the
valid class. Maybe this works on some browsers, but on Firefox 1.5 under
Linux I didn't get any red borders around inputs in the example pages. I
modified the functions as follows (3rd and 4th lines are new):

(defmethod javascript-invalid-handler ((field t) (validator
validator))

  `(unless (dojo.html.has-class (document.get-element-by-id ,(dom-id field))
"ucw-form-field-invalid")
    (dojo.html.remove-class (document.get-element-by-id ,(dom-id
field))

"ucw-form-field-valid")

    (dojo.html.add-class (document.get-element-by-id ,(dom-id
field))

     "ucw-form-field-invalid")))

And now it works as expected for me.

Regards,
Marijn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060531/75d58b68/attachment.html>

From evrim at core.gen.tr  Wed May 31 11:57:52 2006
From: evrim at core.gen.tr (Evrim ULU)
Date: Wed, 31 May 2006 14:57:52 +0300
Subject: [Bese-devel] secure-app#exit-user
Message-ID: <447D84C0.6030307@core.gen.tr>

hi,

here is a patch to fix exit-user.

evrim.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ucw-secure-app-exit-user-fix.patch
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060531/83f38e66/attachment.ksh>

From nathan at acceleration.net  Wed May 31 16:27:09 2006
From: nathan at acceleration.net (Nathan Bird)
Date: Wed, 31 May 2006 12:27:09 -0400
Subject: [Bese-devel] RE: [slime-devel] Re: On the numbering of restarts in
	SLDB
In-Reply-To: <7A668D83-4D2C-4C49-99FA-DE3255D5C25E@metabang.com>
Message-ID: <0b3601c684cf$10cdd760$d80a0a0a@acceleration.net>

>-----Original Message-----
>From: slime-devel-bounces at common-lisp.net [mailto:slime-devel-
>bounces at common-lisp.net] On Behalf Of Gary King
>Subject: Re: [slime-devel] Re: On the numbering of restarts in SLDB
>
> [...] I know I'd feel better if the menu looked like:
>
>> Restarts:
>>   0     : [RETRY] Retry performing #<LOAD-OP NIL #x84F81F6> on
>> #<SYSTEM
>> "cl-containers" #x84E8EE6>.
>>   1     : [ACCEPT] Continue, treating #<LOAD-OP NIL #x84F81F6> on
>> #<SYSTEM "cl-containers" #x84E8EE6> as having been successful.
>>   Q, 2: [ABORT-REQUEST] Abort handling SLIME request.
>>   3     : [ABORT-BREAK] Reset this process
>>   4     : [ABORT] Kill this process
>
>I'd feel ever better if I couldn't kill the process without a
>confirmation... any thoughts on these two ideas?

I kind of like the idea of showing which restart q is bound to, except that
I would probably prefer "2, Q" so that the numbers still line up.

Not sure about confirming the abort restart, just need to make sure that any
code for it doesn't stop me from actually killing it if is in a really
unstable state (and therefore might not do well at running the confirmation
code).

Is there a way to bind 'q', set a particular restart as the default 'exit'
restart? When I'm hacking on UCW there is no "Abort handling SLIME request."

A database error occurred: NIL / 23000
[blah blah blah, yes I know..]
Restarts:
  0: [SHOW-BACKTRACE] Send the client a backtrace page.
  1: [SERVER-ERROR] Send the client an internal server error page.
  2: [GENERATE-BACKTRACE-FOR-EMACS] Generate a bug report in Emacs.
  3: [FAIL-MISERABLY] Pretend this request never happend and fail.
  4: [TRY-AGAIN] Play this request over from the top.
  5: [TERMINATE-THREAD] Terminate this thread (#<THREAD "an httpd worker 0"
{BD6A939}>)

I'm thinking 'fail-miserably which just closes all the streams and shuts
down would be a good one to bind.

I looked around a little bit, it doesn't look like this is currently
available. Q invokes slime's sldb-quit, which calls swank:throw-to-toplevel.
Maybe add a new parameter that defaults to 'abort-request, but could be
dynamically rebound to name a different restart before UCW invokes the
swank-debugger? Swank:throw-to-toplevel would use the parameter to invoke
the correct restart.

Any objections/much better ideas?

Nathan Bird




From vanek at acd.net  Wed May 31 16:32:23 2006
From: vanek at acd.net (Lou Vanek)
Date: Wed, 31 May 2006 16:32:23 +0000
Subject: [Bese-devel] Re: CLISP + UCW + SLIME + REPL
In-Reply-To: <726DAAD1-5944-11DA-BE4D-0005024D4623@gmail.com>
References: <21E3EC84-5943-11DA-BE4D-0005024D4623@gmail.com>
	<726DAAD1-5944-11DA-BE4D-0005024D4623@gmail.com>
Message-ID: <447DC517.9010001@acd.net>

Does anybody have a copy of the modified swank.lisp file Vlado talks about here?
If so, please forward to vanek AT acd DOT net or post in a public, well-lit place.
Much appreciated,
Lou Vanek



vlado tzankov wrote:

> Sorry in the previous mail i forgot that i have  changed the
> startup-backend
> 
> in the ucw araneida backend - file: src/backend/araneida.lisp
> 
> I have removed the last line:
>  ;; #+clisp (araneida:host-serve-events))
> 
> since it starts a global "REPL" in the described configuration.
> 
> On Saturday, November 19, 2005, at 11:26  PM, vlado tzankov wrote:
> 
>> The modifications that i have made are:
>>
>> 1. SLIME
>> Attached are the swank.lisp and swank-clisp.lisp.
>> 1.1. swank.lisp
>>     when using the :fd-handler (and :sigio) communication style - the 
>> lambda passed to the add-fd-handler should have a single parameter - 
>> which is ignored in slime, but since the lambda is called now from the 
>> araneida - it should have a parameter. This change affects all 
>> backends that use fd-handler ot sigio (cmucl, single threaded sbcl). 
>> so the backends should be changed as well - (defimplementation 
>> add-fd-handler (socket fn)) should be changed in the backends to use 
>> the passed lambda.
>> 1.2. swank-clisp.lisp
>>     the following functions are added to the file (no other 
>> modifications).
>> (defimplementation preferred-communication-style ()
>>   (if (find-package 'araneida) :fd-handler nil))
>>
>> (defimplementation add-fd-handler (socket fn)
>>   (if (find-package 'araneida)
>>       (car (push (cons socket fn) (symbol-value (intern 
>> "*FD-HANDLERS*" "ARANEIDA"))))
>>       (error "trying to use araneida event handlers without having it 
>> loaded.")))
>>
>> (defimplementation remove-fd-handlers (socket)
>>   (if (find-package 'araneida)
>>     (setf (symbol-value  (intern "*FD-HANDLERS*" "ARANEIDA"))
>>       (remove socket (symbol-value (intern "*FD-HANDLERS*" 
>> "ARANEIDA")) :count 1 :test (lambda (x y) (equal x (car y)))))
>>     (error "trying to use araneida event handlers withouit having it 
>> loaded")))
>>
>> 2. ARANEIDA
>>     The only change here is replacing the function HOST-SERVE-EVENTS 
>> in the the compat/compat-clisp.lisp with the following one:
>>
>> (defun host-serve-events ()
>>   (loop
>>    (let ((current-handlers (copy-list *fd-handlers*))
>>      (just-sockets (mapcar (lambda (pair)
>>                  (if (eq (type-of (car pair)) 'stream)
>>                      (list (car pair) :input)
>>                    (list (car pair))))
>>                    *fd-handlers*)))
>>      (loop for j in (socket:socket-status just-sockets) do
>>        (let ((x (find-if (lambda (pair) (eql (car j) (car pair))) 
>> current-handlers)))
>>          (if (or (eq (cdr j) t) (eq (cddr j) :INPUT))
>>          (if x (funcall (cdr x) (car x))))
>>          (if (and (eq (type-of (car j)) 'stream) (eq (cddr j) :EOF)) 
>> ;; we do not  care about the server-socket, it cannot get :EOF status
>>          (host-remove-fd-handler x)))))))
>>
>> (there is consing at each request, but we have to live with it, since 
>> the handler of the request may change the *fd-handlers*)
>>
>> 3. And finally - the sequence in starting clisp and everything else
>>     i am using the following start script
>>
>> (in-package :common-lisp-user)
>> (asdf:oos 'asdf:load-op 'araneida)
>> (load (merge-pathnames "../slime/swank-loader.lisp" *load-truename*))
>> (load (merge-pathnames "../ucw/bin/start.lisp" *load-truename*))
>> (ucw:startup-server ucw:*default-server*)
>> (swank:create-server :dont-close t)
>> (araneida:host-serve-events)
>>
>> After this from emacs you can do slime-connect and go on.
>>
>> when you try all this - backup you slime files - for cmucl and single 
>> threaded sbcl (and all other that use :fd-handler or :sigio) a small 
>> patch to the backend should be made. for lisps that use :spawn 
>> (openmcl, mp  sbcl) there should be no problems - but have not tested it.
>>
>> the host-serve-event in araneida is supposed to work fine - it is 
>> compatible with the original code.
>> <swank-clisp.lisp><swank.lisp>
>> br
>>     vlado
>>
>>
>> On Saturday, November 19, 2005, at 12:13  PM, Marco Baringer wrote:
>>
>>> vlado tzankov <vtzankov at gmail.com> writes:
>>>
>>>> Hi,
>>>>
>>>> I just managed to patch SLIME and Araneida CLISP support, so I am able
>>>> to run the UCW with Araneida backend and in the same time to connect
>>>> with SLIME to the REPL of the running CLISP. Regardless of single
>>>> threaded CLISP and lack of SERVE-EVENT functionality found in CMUCL
>>>> and SBCL - it is possible to emulate the serve-event stuff with
>>>> SOCKET-STATUS function in CLISP.
>>>>
>>>> So generally CLISP+Araneida+UCW behaves like a multi-threaded system.
>>>
>>>
>>> i could really use this :)
>>>
>>>> If somebody is interested I can post the changes here (or somewhere
>>>> else) - btw the changes are tested only on OS X and CLISP 2.35.
>>>
>>>
>>> post them here.
>>>
>>> -- 
>>> -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 nathan at acceleration.net  Wed May 31 17:43:16 2006
From: nathan at acceleration.net (Nathan Bird)
Date: Wed, 31 May 2006 13:43:16 -0400
Subject: [Bese-devel] *sldb-quit-restart* (was: On the numbering of restarts
	in SLDB)
In-Reply-To: <0b3601c684cf$10cdd760$d80a0a0a@acceleration.net>
Message-ID: <0b4601c684d9$b32342c0$d80a0a0a@acceleration.net>




>I looked around a little bit, it doesn't look like this is currently
>available. Q invokes slime's sldb-quit, which calls swank:throw-to-
>toplevel.
>Maybe add a new parameter that defaults to 'abort-request, but could be
>dynamically rebound to name a different restart before UCW invokes the
>swank-debugger? Swank:throw-to-toplevel would use the parameter to invoke
>the correct restart.
>
>Any objections/much better ideas?

Patch attached that does the above. It works just fine for me!

New parameter named *sldb-quit-restart*, i.e. the restart used by sldb-quit.

I looked a bit about adding 'q' to the label of the sldb-quit restart, but
the numbers are actually added late in the game in slime.el
(sldb-insert-restarts). So a bit more code would be needed than I had hoped.
We could add the *sldb-quit-restart* to the package of info that
debugger-info-for-emacs sends, but it looks like by the time it gets to
emacs it is no longer dealing with symbols, but entirely strings. Maybe
swank:format-restarts-for-emacs could add an optional third element to the
list it returns indicating if the restart is the sldb-quit-restart? Any
other information about restarts that might need to be sent along?

Nathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sldb-quit-restart.diff
Type: application/octet-stream
Size: 1270 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060531/f6c8f729/attachment.obj>

From ctdean at sokitomi.com  Wed May 31 23:58:48 2006
From: ctdean at sokitomi.com (Chris Dean)
Date: Wed, 31 May 2006 16:58:48 -0700
Subject: [Bese-devel] Arnesi patch: Support missing result forms in
	cond-bind and acond
Message-ID: <m2irnlkapz.fsf@tungsten.kyluka.com>


Below is a patch for COND-BIND and ACOND to support missing result
forms.  I've also included a small test suite for the flow-control
operators.

Let me know if you would like the patch in a different format.

Cheers,
Chris Dean



New patches:

[Support missing result forms in cond-bind and acond
Chris Dean <ctdean at sokitomi.com>**20060531234605
 
 The CLHS says that COND results in:
 
   the values of the forms in the first clause whose test-form yields
   true, or the primary value of the test-form if there are no forms in
   that clause
 
 Meaning (among other things) that 
 
   (cond (1)) => 1
 
 This is a patch to give COND-BIND and ACOND the same behavior.  Before
 this patch they would return NIL if there was a missing result form.
 
] {
hunk ./arnesi.asd 72
+                             (:file "flow-control" :depends-on ("suite"))
hunk ./src/flow-control.lisp 44
-                  (progn , at body)
-                  (cond-bind ,var , at others)))
+           (progn ,@(if body body (list var)))
+           (cond-bind ,var , at others)))
addfile ./t/flow-control.lisp
hunk ./t/flow-control.lisp 1
+;;;; -*- lisp -*-
+
+(in-package :it.bese.arnesi.test)
+
+(def-suite :it.bese.arnesi.flow-control :in :it.bese.arnesi)
+
+(in-suite :it.bese.arnesi.flow-control)
+
+(test flow-control
+  (let ((ht (make-hash-table)))
+    (setf (gethash 'a ht) 1)
+    (setf (gethash 'b ht) 'a)
+
+    ;; if-bind and aif
+    (is (= 3 (if-bind var (gethash 'z ht) (1+ var) 3)))
+    (is (= 2 (if-bind var (gethash 'a ht) (1+ var) 3)))
+    (is (= 3 (aif (gethash 'z ht) (1+ it) 3)))
+    (is (= 2 (aif (gethash 'a ht) (1+ it) 3)))
+    ;; when-bind and awhen
+    (let ((result nil))
+      (when-bind var (gethash 'z ht)
+        (setf result (1+ var)))
+      (is (null result))
+      (when-bind var (gethash 'a ht)
+        (setf result (1+ var)))
+      (is (= 2 result))
+      (setf result nil)
+      (awhen (gethash 'z ht)
+        (setf result (1+ it)))
+      (is (null result))
+      (awhen (gethash 'a ht)
+        (setf result (1+ it)))
+      (is (= 2 result)))
+    ;; cond-bind and acond
+    (is (= 99 (cond-bind var
+                ((gethash 'z ht) (1+ var))
+                ((gethash 'y ht) (1+ var))
+                (t 99))))
+    (is (= 2 (cond-bind var
+               ((gethash 'z ht) (1+ var))
+               ((gethash 'a ht) (1+ var))
+                (t 99))))
+    (is (= 1 (cond-bind var
+              ((gethash 'z ht))
+              ((gethash 'y ht))
+              ((gethash 'a ht))
+              (t 99))))
+    (is (= 99 (acond
+               ((gethash 'z ht) (1+ it))
+               ((gethash 'y ht) (1+ it))
+                (t 99))))
+    (is (= 2 (acond
+              ((gethash 'z ht) (1+ it))
+              ((gethash 'a ht) (1+ it))
+              (t 99))))
+    (is (= 2 (acond
+              ((gethash 'z ht))
+              ((gethash 'a ht) (1+ it))
+              (t 99))))
+    ;; and-bind and aand
+    (is-false (and-bind var (gethash 'z ht) (gethash var ht) (1+ var)))
+    (is (= 2 (and-bind var (gethash 'b ht) (gethash var ht) (1+ var))))
+    (is-false (aand (gethash 'z ht) (gethash it ht) (1+ it)))
+    (is (= 2 (aand (gethash 'b ht) (gethash it ht) (1+ it))))
+    ;; whichever
+    (let ((result 0))
+      (is (member (whichever (progn (incf result) 'a)
+                             (progn (incf result) 'b)
+                             (progn (incf result) 'c))
+                  '(a b c)))
+      (is (= 1 result)))
+    ;; xor
+    (let ((result 0))
+      (is (eq 'a (xor (progn (incf result) 'a)
+                      (progn (incf result) nil)
+                      (progn (incf result) nil))))
+      (is (= 3 result))
+      (setf result 0)
+      (is (eq 'a (xor (progn (incf result) nil)
+                      (progn (incf result) 'a)
+                      (progn (incf result) nil))))
+      (is (= 3 result))
+      (setf result 0)
+      (is-false (xor (progn (incf result) 'a)
+                     (progn (incf result) 'b)
+                     (progn (incf result) 'c)))
+      (is (= 2 result)))))
+    
}

Context:

[Make sure the walker doesn't call fboundp on non symbols
Marco Baringer <mb at bese.it>**20060531195843] 
[Export `_'
Hoan Ton-That <hoan at ton-that.org>**20060530105625] 
[Convenience, Lisp-1 support, and partial application syntax
Hoan Ton-That <hoan at ton-that.org>**20060522112451] 
[Added queue->list method (Patch by: Chris Dean <ctdean at sokitomi.com>)
Marco Baringer <mb at bese.it>**20060517090847] 
[Added docstring on log-file slot
Marco Baringer <mb at bese.it>**20060517090828] 
[Fix enable-bracket-reader
attila.lendvai at gmail.com**20060515173051] 
[Define apply-lambda/cc method on symbols.
Marco Baringer <mb at bese.it>**20060515135717
 
 This new method just calls apply-lambda/cc passing it the symbol-function of the operator.
] 
[Added remf-keywords macro to remove keyword args
attila.lendvai at gmail.com**20060511150622] 
[implement walker for eval-when
Marco Baringer <mb at bese.it>**20060509145223] 
[Change defclss-struct to allow class-options
Marco Baringer <mb at bese.it>**20060509144410] 
[Fix the return value of compose for fn > 4
attila.lendvai at gmail.com**20060502104311] 
[Skip nil's in strcat
attila.lendvai at gmail.com**20060213230204] 
[Export *warn-undefined*
Marco Baringer <mb at bese.it>**20060427131316] 
[Signal warning for undefined functions
Marco Baringer <mb at bese.it>**20060427131248] 
[Added the *warn-undenifed* variable.
Marco Baringer <mb at bese.it>**20060427131102
 
 We can now check for undenfined varibales/functions at walk time
] 
[Find-symbol SYSTEM::*HTTP-ENCODING* only if there is a SYSTEM package.
Maciek Pasternacki <maciekp at japhy.fnord.org>**20060425195734] 
[Added the REBIND macro (Patch by: Attila Lendvai <attila.lendvai at gmail.com>)
Marco Baringer <mb at bese.it>**20060423105838] 
[Pass the env argument to make-load-form
Marco Baringer <mb at bese.it>**20060423105632] 
[Fix encoding-keyword-to-native for clisp. (Patch by: Pascal Bourguignon <pjb at informatimago.com>)
Marco Baringer <mb at bese.it>**20060413140523] 
[src/posixenv.lisp: define `getenv'
Luca Capello <luca at pca.it>**20060412132403
 
 ATM, this is the only POSIX function present in src/posixenv.lisp.
 
 I also added "getenv" to the list of features in the ASDF file, in
 order to depend on it in other project (first of all, UCW).
] 
[Use class-slots instead of our custom 'walk class hierarchy and collect slot defs' code.
Marco Baringer <mb at bese.it>**20060405120648
 
 This change should fix problems with allegro. Nathan Bird reported
 this and suggested the proper solution.
] 
[Unwalker mistakes
Hoan Ton-That <hoan at ton-that.org>**20060401084803] 
[Let the implementation use the default value. SBCL seems to only accept a real readtable there.
levente.meszaros at gmail.com**20060325233110] 
[Change with-package read-macro specifier so that it returns a progn.
Marco Baringer <mb at bese.it>**20060324115026] 
[Added read-macros.lisp to asdf
Marco Baringer <mb at bese.it>**20060324114744] 
[Added doc strings for the read-macro stuff
Marco Baringer <mb at bese.it>**20060324113104] 
[Added bracket reader and with-package function
Marco Baringer <mb at bese.it>**20060324111610] 
[Dropped our trim-string function, common lisp already provides string-trim
Marco Baringer <mb at bese.it>**20060324104938] 
[Fix typo in walk.lisp
Marco Baringer <mb at bese.it>**20060313222523] 
[Added print-object method for log-category
Marco Baringer <mb at bese.it>**20060313222510] 
[Added copy-stream function
Marco Baringer <mb at bese.it>**20060313222455] 
[matcher ext :AND, :ACCESSORS, :PLIST
Kilian Sprotte <ml13 at onlinehome.de>**20060304195313] 
[A code UnWalker
Hoan Ton-That <hoan at ton-that.org>**20060301075456] 
[Typo in do-all-elements macro when the indexe parameter is nil
Marco Baringer <mb at bese.it>**20060226184405] 
[Added a print-object method for function-argument-form objects
Marco Baringer <mb at bese.it>**20060226184343] 
[Make the cc interpreter 'see' special variables
Marco Baringer <mb at bese.it>**20060224155153
 
 If a symbol is globally bound, and isn't locally overridden, we assume
 it's a global special and treat it as such.
] 
[Added enqueue-or-move-to-front method to the lru-queue class
Marco Baringer <mb at bese.it>**20060224154525] 
[Added lru-queue
Marco Baringer <mb at bese.it>**20060224145245] 
[Implement peek-queue
Marco Baringer <mb at bese.it>**20060224145231] 
[Create the queue's buffer to be 1+ the required size
Marco Baringer <mb at bese.it>**20060224142145
 
 The length of the buffer is actually one less than the total number of
 elements we can hold. Since the :size initarg means 'numbor of
 elements we can store without resizing' we need to create the buffer
 slightly larger.
] 
[Added vector based queue implementation
Marco Baringer <mb at bese.it>**20060224141820] 
[Added missing ignore declarations
Marco Baringer <mb at bese.it>**20060224121944] 
[escape html unicode characters
henrik.hjelte at poboxes.com*-20060215141526
 Not all unicode characters fit the latin-1 encoding, escaping them helps out.
] 
[escape html unicode characters
henrik.hjelte at poboxes.com**20060215141526
 Not all unicode characters fit the latin-1 encoding, escaping them helps out.
] 
[Eliminate runtime call to eval when exporting special variables from cc code to lisp code.
levente.meszaros at gmail.com**20060214210552] 
[Split stream-log-append into brief-stream-log-appender and verbose-stream-log-appender
Marco Baringer <mb at bese.it>**20060213185541
 
 The stream-log-appender was wasting too much space on extremly
 reptative information. The new hierarchy contains three classes: the
 abstract base class stream-log-appender; a verbose out class (exactly
 the same output as the original stream-log-appender) called
 verbose-stream-log-appender and a quieter append called
 brief-stream-log-appender.
 
 NB: This change breaks backwards compatability. All occurences of
 "make-instance 'stream-log-appender" will need to be replaced with
 "make-instance 'verbose-stream-log-appender"
] 
[Fix infinite loop in (setf log.level)
Marco Baringer <mb at bese.it>**20060213173230
 
 argh. we'd defined a method for (setf log.level) specialized on
 SYMBOLs, this method called (get-logger symbol) and passed that back
 again to (setf log.level). However, when get-logger returned nil
 (which happens the symbol didn't specify a logging category) we'd
 again call the same method (since nil is a symbol), and not the one
 specialized on category objects :(
] 
[conflict resolution with levente's special variable patch
Marco Baringer <mb at bese.it>**20060213181217] 
[Rework test cases for special variable handling.
Levente M??sz??ros <melevy at freemail.hu>**20060211205154] 
[Make importing and exporting specials explicit functions, plus support importing in defun/cc.
Levente M??sz??ros <melevy at freemail.hu>**20060211205043] 
[Add test cases for dynamic variable handling
Levente M??sz??ros <melevy at freemail.hu>**20060209215158] 
[Fixed bug in with-call/cc's handling of multiple-value-call. (Reported by: Matthew Danish <mdanish at andrew.cmu.edu>)
Marco Baringer <mb at bese.it>**20060211165654
 
 When the function in a multiple-value-call form was a literal lambda
 we were accidentaly passing _all_ the arguments passed to m-v-c to the
 function (the first of these arguments is always the function itself).
] 
[(setf log.level) needs to, as all setf methods, return the new-value
Marco Baringer <mb at bese.it>**20060210154819] 
[Add test cases for dynamic variable handling
Levente M??sz??ros <melevy at freemail.hu>**20060209213739] 
[Support capturing dynamic variables from lisp via declare.
Levente M??sz??ros <melevy at freemail.hu>**20060208214015] 
[Makes visible the dynamic variables defined in cc code for normal lisp code.
Levente M??sz??ros <melevy at freemail.hu>**20060206224603
 This has some performance issues when dynamic variables are defined in cc code.
] 
[Support (declare (special var)) declarations and put variable values in the dynamic environment.
Levente M??sz??ros <melevy at freemail.hu>**20060206224208
 This patch allows to access dynamic variables defined in cc code from cc code.
] 
[Ecase->case typo.
Maciek Pasternacki <maciekp at japhy.fnord.org>**20060130230302] 
[minor docstring fix
Marco Baringer <mb at bese.it>**20060202145727] 
[Move test suite into its own package
Marco Baringer <mb at bese.it>**20060202114156] 
[Change names of parameters in MULF and DIVF to match documentation
Marco Baringer <mb at bese.it>**20060202114140] 
[Added log.level methods specialized on symbols
Marco Baringer <mb at bese.it>**20060202114058] 
[Added time.lisp
Marco Baringer <mb at bese.it>**20060202114049] 
[Export levenshtein-distance
Marco Baringer <mb at bese.it>**20060202114018] 
[Use FiveAM's new random testing for the parse-float test
Marco Baringer <mb at bese.it>**20060124140012] 
[Reimplement intern-concat to accept only strings and symbols as string designators.
Marco Baringer <mb at bese.it>**20060124135505
 
 Simply using PRINC can have different semantics on different
 lisps. Explicitly allowing only strings and symbols resoles this issue
 and makes clearer what inter-concat is intended to deal with. (passing
 objects or numberns to inter-concat was never intentional anyway).
] 
[Fix thinko in definition of test-op
Marco Baringer <mb at bese.it>**20060124131555] 
[Update copyright dates
Marco Baringer <mb at bese.it>**20060123125009] 
[Added test for escape/unescape-uri using fiveam's new random checking
Marco Baringer <mb at bese.it>**20060120110709] 
[In recent clisps the convert-bytes-to-string function has been renamed to convert-string-from-bytes
Marco Baringer <mb at bese.it>**20060113113449] 
[Stop trying to convert keywords directly to charset symbols.
Marco Baringer <mb at bese.it>**20060113113430] 
[Enable unicode on clisp only if :UNICODE is in *features*
Marco Baringer <mb at bese.it>**20060109140827] 
[Don't use uppercase names for list-matcher symbols. not all lisps have :upcase readtable-case (Reported by: BAM <solnul at gmx.de>)
Marco Baringer <mb at bese.it>**20051220000456] 
[Drop char->hex-value. digit-char-p does the exact same thing.
Marco Baringer <mb at bese.it>**20051220000406] 
[Implement QUIT for allegro. (Patch by: BAM <solnul at gmx.de>)
Marco Baringer <mb at bese.it>**20051220000154] 
[Use the new octets-to-string function in http.lisp
Marco Baringer <mb at bese.it>**20051218124500] 
[Declare char->hex-value to be inlined
Marco Baringer <mb at bese.it>**20051218124425] 
[Fix previous eswitch/cswitch patch
Marco Baringer <mb at bese.it>**20051218124148] 
[Conditionalize on (and sbcl sb-unicode), not just sbcl
Marco Baringer <mb at bese.it>**20051218123532] 
[remove unneeded escapes
svg at surnet.ru**20051213204631] 
[Implement and export STRING-TO-OCTETS and OCTETS-TO-STRING
Marco Baringer <mb at bese.it>**20051218123215
 Currently these do something only on SBCL and CLISP.
] 
[Use &body, instead of &rest, in the lambda lists of ESWITCH and CSWITCH
Marco Baringer <mb at bese.it>**20051218122248
 This change makes slime add the proper indentation for these forms
] 
[Export extract-argument-names and walk-lambda-list
Marco Baringer <mb at bese.it>**20051211135308] 
[Fix generation of lambda list from a list of argument-parameter objects (in the walker)
Marco Baringer <mb at bese.it>**20051211135245] 
[Fix handling of &allow-other-keys and lambda lists with only (&key &allow-other-keys)
Marco Baringer <mb at bese.it>**20051211131145] 
[Also make a debug logger
Chris Dean <ctdean at sokitomi.com>**20051209072439] 
[Fix spelling in log.lisp comments
Chris Dean <ctdean at sokitomi.com>**20051209072321] 
[Added :wrap-aronud method types ot wrapping-standard method combination
Marco Baringer <mb at bese.it>**20051204162319] 
[added a walker for load-time-value
Marco Baringer <mb at bese.it>**20051201170253] 
[Document the slots of the log-category class
Marco Baringer <mb at bese.it>**20051201170222] 
[Fix walking of macrolet forms
Marco Baringer <mb at bese.it>**20051126162913] 
[include walk.lisp in qbook's autput
Marco Baringer <mb at bese.it>**20051126162859] 
[minor fix in wrapping-standard's docstring
Marco Baringer <mb at bese.it>**20051126162847] 
[Minor change in with-unique-names' docstring
Marco Baringer <mb at bese.it>**20051125173827] 
[Make docs/Makefile easier to adapat to different lisps and systems
Marco Baringer <mb at bese.it>**20051125173801] 
[Document the #L read macro
Marco Baringer <mb at bese.it>**20051125173744] 
[Removed all texinfo syntax from docstrings
Marco Baringer <mb at bese.it>**20051125173708] 
[Added a walker for unwind-protect
Marco Baringer <mb at bese.it>**20051118193044] 
[Make the 'return from unknown block' error a restartable condition
Marco Baringer <mb at bese.it>**20051118193020] 
[Added lispworks specific walk handlers
Marco Baringer <mb at bese.it>**20051115122956] 
[yet another yet another trace cc thinko
Marco Baringer <mb at bese.it>**20051112122930] 
[We had an etypecase form with a T clasue, changed to typecase (Reported by: Luigi Panzeri <matley at muppetslab.org>)
Marco Baringer <mb at bese.it>**20051111171221] 
[Yet another trace-statement patch by our resident Q&A expert. (Patch by: Aleksandar Bakic <a_bakic at yahoo.com>)
Marco Baringer <mb at bese.it>**20051110195739] 
[More fixs to trace-statements (Patch by: Aleksandar Bakic <a_bakic at yahoo.com>)
Marco Baringer <mb at bese.it>**20051110115953] 
[thinko in cc trace-statement (Patch by: Aleksandar Bakic <a_bakic at yahoo.com>)
Marco Baringer <mb at bese.it>**20051110094851] 
[Drop the :ALL option for *trace-cc*
Marco Baringer <mb at bese.it>**20051108131116] 
[Added a few more trace statements
Marco Baringer <mb at bese.it>**20051108130243] 
[Added *trace-cc* parameter (and supporitng code). See docstring for details.
Marco Baringer <mb at bese.it>**20051108125255] 
[Escape { and } in boring regexps
Marco Baringer <mb at bese.it>**20051105152003] 
[Removed qbook include to non existent file scr/cps.lisp
Marco Baringer <mb at bese.it>**20051105151143] 
[Remove duplicate export of arnesi:form
Marco Baringer <mb at bese.it>**20051105151130] 
[Changed lambda list of IF-BIND so that slime will ident it better.
Marco Baringer <mb at bese.it>**20051105150656] 
[Exported all the symbols related to the walker
Marco Baringer <mb at bese.it>**20051028122648] 
[remove debian/ folder
Luca Capello <luca at pca.it>**20051028103802
 
 The CL-Debian group decided to avoid Debian native packages.
 
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=310665
] 
[CMUCL lexical-variables global var detection
svg at surnet.ru**20051024191615] 
[Added dyn-env parameter to sbcl's call to apply-lambda/cc
Marco Baringer <mb at bese.it>**20051021153948] 
[Added tests for parse-float
Marco Baringer <mb at bese.it>**20051021153936] 
[Specify result element-type in radix-values
Marco Baringer <mb at bese.it>**20051018102502] 
[Typo in last patch
Marco Baringer <mb at bese.it>**20051018102126] 
[Rewrote parse-float in order to support tho :decimal-character keyword parameter
Marco Baringer <mb at bese.it>**20051018101950] 
[Minor fixup to wrapping-standard's docstring
Marco Baringer <mb at bese.it>**20051014094112] 
[Remove ignore declarations for unused variable DYNAMIC-ENVIRONMENT
Marco Baringer <mb at bese.it>**20051012141417] 
[lex-env support for lispworks on windows (Patch by: Mac Chan <emailmac at gmail.com>)
Marco Baringer <mb at bese.it>**20051009103654] 
[Added the :return-suffix parameter to starts-with
Marco Baringer <mb at bese.it>**20051007190426] 
[Add dynamic-environment to the cc interpreter
Marco Baringer <mb at bese.it>**20051007174859
 
 This patch changes the api for evaluate/cc (and associated functions)
 by adding a dynamic-environment parameter and fixs the catch handler
 to use this dynamic-environment (and not the lexical environment).
] 
[Added nfasl to .boring
Marco Baringer <mb at bese.it>**20051007174421] 
[Teach the walker to handle global symbol macros
Marco Baringer <mb at bese.it>**20050925155112] 
[Added if-does-not-exist parameter to write-string-to-file
Marco Baringer <mb at bese.it>**20050925155049] 
[More lexical-(variables|functions) for lispworks (Patch by: Asbj??rn Bj??rnstad <asbjxrn at bjxrnstad.net>)
Marco Baringer <mb at bese.it>**20050906140657] 
[Fix silly mistake in previous docstring for defmethod/cc patch
Marco Baringer <mb at bese.it>**20050903140254] 
[When a defmethod/cc form has somethnig which looks like a comment we 'pass' that to the underlying defmethod form
Marco Baringer <mb at bese.it>**20050901100340] 
[Added generic error-reporting method on evaluate/cc
Marco Baringer <mb at bese.it>**20050901100314] 
[More lexical-(variables|functions) methods for lispworks (Patch by: Asbj??rn Bj??rnstad <asbjxrn at bjxrnstad.net>)
Marco Baringer <mb at bese.it>**20050831094750] 
[Fix handling of special operator FUNCTION in the faco of defun/cc functions
Marco Baringer <mb at bese.it>**20050831094727] 
[enhanced defmethod/cc to work in the case of a null argument list and missing body.
drewc at tech.coop**20050819201500
 
] 
[Minor whitespace fix to previous patch
Marco Baringer <mb at bese.it>**20050827194602] 
[When sb-unicode is avaible don't encode characters with codes > 127 as html entities
binarin at gmail.com**20050827134518] 
[Make nunescape-as-uri accept external-format parameter
binarin at gmail.com**20050827134456] 
[Use &key instead of &optional in the test suite for the cc interpreter
Marco Baringer <mb at bese.it>**20050827184725] 
[Minor refactoring to avoid sbcl's "deleting unreachable code" warning
Marco Baringer <mb at bese.it>**20050827121814] 
[Introduce the distinction between a keyword argument's name and the effective-keyword used to pass the value.
Marco Baringer <mb at bese.it>**20050827111706
 
 we now can tell if the user supplied a keyword name (different from
 the argument's name) and proceed accordingly. this patch works around
 cmucl's bug in the handling of generic lambda lists.
] 
[Fix LEXICAL-FUNCTIONS on cmucl (Patch by: Fabricio Chalub <chalub at gmail.com>)
Marco Baringer <mb at bese.it>**20050827110128] 
[Added hash-table-keys and hash-table-values functions
Marco Baringer <mb at bese.it>**20050825062935] 
[Added in a few more tests
Marco Baringer <mb at bese.it>**20050824165751] 
[Fix local-function application
Marco Baringer <mb at bese.it>**20050824164938] 
[Added lexical-variables and lexical-functions for Allegro. (Patch by: Slawek Zak <slawek.zak at gmail.com>)
Marco Baringer <mb at bese.it>**20050824123802] 
[Added delete/remove family of functions to common-lisp-cc
Marco Baringer <mb at bese.it>**20050817100128] 
[fixed typo
smoof-ra at elder-gods.org**20050816174806] 
[Added copyright notices
Marco Baringer <mb at bese.it>**20050816141938] 
[Added initial version of lex-env function for lispworks
Marco Baringer <mb at bese.it>**20050816141839] 
[Convert (setf env (register env ...)) into (extend env ...)
Marco Baringer <mb at bese.it>**20050816084720] 
[Moved register/lookup/(setf lookup) into one-liners.lisp, added the extend macro
Marco Baringer <mb at bese.it>**20050816084654] 
[more usefull declaration objects
smoof-ra at elder-gods.org**20050815202603] 
[Change the name of the walker handler for atom so that it doesn't used to walk forms whose car is CL:ATOM.
Marco Baringer <mb at bese.it>**20050812114613] 
[Added required specifier :primary to cc-standard method combination
Marco Baringer <mb at bese.it>**20050812114343
 
 This prevents people from accidentaly using defmethod on a cc generic
 function. You must now either use defmethod/cc (which retains the same
 API as before), or pass the :primary method qualifier (and if you do
 we'll assume you know what you're doing).
 
] 
[Update the list of exported symbols
Marco Baringer <mb at bese.it>**20050812102709] 
[Two minor indentation fixups
Marco Baringer <mb at bese.it>**20050812102429] 
[Remove type declarations form join-string (ucw passes in strings which violate some of the type declarations)
Marco Baringer <mb at bese.it>**20050812102333] 
[JOIN-STRINGS was not returning the result :(
Marco Baringer <mb at bese.it>**20050812070730] 
[Added more tests for cc-standard method combination
Marco Baringer <mb at bese.it>**20050811152516] 
[Make the arguments to a continuation all option (the equivalent of evaluating (values))
Marco Baringer <mb at bese.it>**20050811152449] 
[Added cc definintions of common standard functions whcih take functions as parameters (assoc and mapXYZ)
Marco Baringer <mb at bese.it>**20050811152400] 
[Added missing cleane-argument-list function and tests
Marco Baringer <mb at bese.it>**20050811130722] 
[Fix generic/method/function lambda list handling and manipulation in walker and cc-interpreter
Marco Baringer <mb at bese.it>**20050811130002] 
[Added support for &key, &allow-other-keys in lambda/cc (and therefore defun/cc and defmethod/cc)
Marco Baringer <mb at bese.it>**20050810140725] 
[keyword-function-argument-form is not a subclass of optional-argument-form, even though they are superficially similar
Marco Baringer <mb at bese.it>**20050810140659] 
[Move debugging code into DEFK where have access to the name of the continuation we're calling (as apposed to KLAMBDA)
Marco Baringer <mb at bese.it>**20050810121305] 
[Refactor cc-interpreter into a few smaller files in the call-cc directory
Marco Baringer <mb at bese.it>**20050810104819] 
[Refactor FOLD-STRING (Patch by: Janis Dzerins <jdz at dir.lv>)
Marco Baringer <mb at bese.it>**20050810103438] 
[the fdefinition/cc table must remeber, other than the def, whether it was a function or a method (since we treat those two differently)
Marco Baringer <mb at bese.it>**20050810101541] 
[Added :method-combination option to the expaniosn of the defgeneric/cc macro
Marco Baringer <mb at bese.it>**20050810101446] 
[Added *debug-evaluate/cc* and related functions
Marco Baringer <mb at bese.it>**20050810063228] 
[Use fedinition/cc, not fdefinition, for defun/cc
Marco Baringer <mb at bese.it>**20050810055126] 
[Typo in name of k-for-apply/cc/optional-argument-default-value continuation
Marco Baringer <mb at bese.it>**20050810055105] 
[Don't use GET so that we don't break package locks. Add now function fdefinition/cc
Marco Baringer <mb at bese.it>**20050810054327
 
 Basically it's a bad idea to use #'get and #'(setf get) on standard
 symbols, however this is something we're going to want to do. We know
 have our own hash-table (*cc-functions*) which maps symbols to closure
 objects.
 
] 
[ method combination 
smoof-ra at elder-gods.org**20050810035825] 
[make closure/cc a funcallable instance (in sbcl)
smoof-ra at elder-gods.org**20050809182900
 
 funcalling a closure/cc will just call it with a toplevel continuation
 that way cc closures can be called totally transparently by non-cc code
 as long as the cc-closure doesn't call/cc.
 
] 
[Added copyright notice to cc-interpreter.lisp
Marco Baringer <mb at bese.it>**20050809151738] 
[Remove occurences of 'cps' in the api. We don't actually cps transforme anymore so this is misleading.
Marco Baringer <mb at bese.it>**20050809125933] 
[Remove 'cps' from test suite, replace it with 'call/cc' 
Marco Baringer <mb at bese.it>**20050809104818] 
[Rename cps.lisp to cc-interpreter.lisp
Marco Baringer <mb at bese.it>**20050809104737] 
[Fix typo in fold-strings' docstring
Marco Baringer <mb at bese.it>**20050809083006] 
[Trivial change to the name of the gensym generated by DOLIST*
Marco Baringer <mb at bese.it>**20050809061102] 
[Fix lexical-variables and lexical-functions on clisp
Marco Baringer <mb at bese.it>**20050807223244] 
[Use FDEFINITION instead of SYMBOL-FUNCTION to get a function from a function name.
Marco Baringer <mb at bese.it>**20050807222932] 
[Make sure we only pass symbols to functions like GET and MACRO-FUNCTION
Marco Baringer <mb at bese.it>**20050807222905] 
[Implement lexical-functions for CLISP
Marco Baringer <mb at bese.it>**20050807204738] 
[Implement lexical-variables and lexical-functions for NIL environments
Marco Baringer <mb at bese.it>**20050807204711] 
[Remove arnesi.el from ssytem def
Marco Baringer <mb at bese.it>**20050807204654] 
[Fix evaluation of #'(foo bar) in cps interpreter
Marco Baringer <mb at bese.it>**20050806182653] 
[Delete arnesi.el. SLIME is perfectly able to figure out the indententation by itself.
Marco Baringer <mb at bese.it>**20050807075500] 
[aparently global variables can be found in sbcl lexical environments
smoof-ra at elder-gods.org**20050804164859] 
[Implement environment-p and lexical-variables for CLISP
Marco Baringer <mb at bese.it>**20050804165821] 
[Make the lexenv stuff use generic-functions and methods
Marco Baringer <mb at bese.it>**20050804161857] 
[Fixup lexical-variables and lexical-functions for OpenMCL
Marco Baringer <mb at bese.it>**20050804152727
 
 This patch causes lexical-variables to no longer return ignored
 variables and symbol-macrolets. We've also implemented
 lexical-functions (though we do some hackery to convert functions
 names to something "normal" (ie SETF::|FOO::BAR| ==> (SETF FOO::BAR))
 
] 
[Typo in lexical-variables for sbcl (we were accessing lexenv-funs instead of lexenv-vars)
Marco Baringer <mb at bese.it>**20050804152051] 
[Change lexical-variables for sbcl so that it doesn't return ignored variables
Marco Baringer <mb at bese.it>**20050804150841] 
[Fix lexical-variables for cmucl to not return ignored variables
Marco Baringer <mb at bese.it>**20050804150256] 
[Typo in previous patch
Marco Baringer <mb at bese.it>**20050804150242] 
[Implement lexical-functions for cmucl
Marco Baringer <mb at bese.it>**20050804143350] 
[recognise flets from the lexical environment (on sbcl)
smoof-ra at elder-gods.org**20050803222732] 
[Rewrite multiple-value-setf so that my simple mind can understand it.
Marco Baringer <mb at bese.it>**20050803104652] 
[Added cps evaluation of THE forms
Marco Baringer <mb at bese.it>**20050803092059] 
[minor comment fixup
Marco Baringer <mb at bese.it>**20050803085322] 
[Moved defclass progv-form to keep the walker classes defined in alphabetical order 
Marco Baringer <mb at bese.it>**20050803085254] 
[Added walker class for THE forms
Marco Baringer <mb at bese.it>**20050803085210] 
[allow new special forms to be added to the walker by shadowing *walker-handlers*
smoof-ra at elder-gods.org**20050802165355] 
[Minor spacing fixs to the previous patch
Marco Baringer <mb at bese.it>**20050802152421] 
[progv
smoof-ra at elder-gods.org**20050802150342] 
[labels can have declarations inside the body
smoof-ra at elder-gods.org**20050801193433] 
[declares needs to be copied in the labels handler just like the other lambda-function-form slots
smoof-ra at elder-gods.org**20050801193107] 
[oops i forgot to actually make the declaration-form instances
smoof-ra at elder-gods.org**20050801185641] 
[initial support for remembering declarations
smoof-ra at elder-gods.org**20050801184329
 
 this patch adds a mixin called implicit-progn-with-declare-mixin and 
 uses it instead of implicit-progn-mixin in all the places that allow declares.
 It has slot which should contain a list of the declares at the top of the 
 implicit-progn.  This patch doesn't do anything clever with the declares, 
 it just creates declaration-form objects and points their source slots 
 at the original declares, however it would be easy to modify parse-declaration
 to generate more usefull declaration objects.
 
] 
[Call the property :FEATURES, not FEATURES
Marco Baringer <mb at bese.it>**20050729103229] 
[Rename asdf property version to features, add "cps-interpreter"
Marco Baringer <mb at bese.it>**20050728120238] 
[dont need to register allow-other-keys because its not a binding
smoof-ra at elder-gods.org**20050727153603] 
[fixed type name mismatch for allow-other-keys-function-arguement-form
smoof-ra at elder-gods.org**20050727152456] 
[defmethod arguments should be ignorable, not ignore (openmcl warns whenever you ignore a specialized argument)
Marco Baringer <mb at bese.it>**20050726090308] 
[Typo in extract-argument-names
Marco Baringer <mb at bese.it>**20050726090256] 
[Fix generation of defmethod froms from defmethod/cc; added tests
Marco Baringer <mb at bese.it>**20050726085226] 
[Fix handling of optional arguments in apply-cps-lambda
Marco Baringer <mb at bese.it>**20050726085155] 
[More tests
Marco Baringer <mb at bese.it>**20050723133158] 
[Fix a bug in the handling of the case when LOOKUP finds a value for a name but the value is NIL
Marco Baringer <mb at bese.it>**20050723133106] 
[Export the symbol KALL
Marco Baringer <mb at bese.it>**20050723133052] 
[Change the test for constant-form'ness in walk.lisp
Marco Baringer <mb at bese.it>**20050723113019] 
[Extend the walker to handle #'(setf foo) function names
Marco Baringer <mb at bese.it>**20050723104431] 
[Fix bug in the lambda generated for method forms
Marco Baringer <mb at bese.it>**20050720144450] 
[Added ignore declarations to defun/cc and defmethod/cc to make the compiler happy
Marco Baringer <mb at bese.it>**20050720110112] 
[Temporarily comment out the log tests
Marco Baringer <mb at bese.it>**20050720092312] 
[Rename (optional|keyword|rest)-argument-form classes to include the -form suffix
Marco Baringer <mb at bese.it>**20050720092124] 
[Allow defun/cc defined functions te be called outside of a with-call/cc
Marco Baringer <mb at bese.it>**20050720091826] 
[Added support for &optional arguments in cps closures
Marco Baringer <mb at bese.it>**20050720091658] 
[Added defgeneric/cc
Marco Baringer <mb at bese.it>**20050719153441] 
[Move the error checking code for lambda arguments into apply, not lambda (in cps interpreter)
Marco Baringer <mb at bese.it>**20050719153121] 
[More cps tests
Marco Baringer <mb at bese.it>**20050719152327] 
[Fix openmcl's definition of lexical-variables to deal with ccl::definition-environment
Marco Baringer <mb at bese.it>**20050719152230] 
[Added support to the cps interpreter forl communicating with lexical variables
Marco Baringer <mb at bese.it>**20050707094608] 
[walk.lisp depends on lexenv.lisp
Marco Baringer <mb at bese.it>**20050707093140] 
[added support for walking local varibales in the lexical environment
Marco Baringer <mb at bese.it>**20050707093027
 
 this applies to all those variables defined the envorinment object
 grabbed via an &environment macro argument. 
 
] 
[mistyped #+openmcl in lexenv.lisp
Marco Baringer <mb at bese.it>**20050707092959] 
[added src/lexenv.lisp to arnesi.asd
Marco Baringer <mb at bese.it>**20050707091127] 
[Rename src/environment.lisp
Marco Baringer <mb at bese.it>**20050707091114] 
[Initial version of environment.lisp
Marco Baringer <mb at bese.it>**20050707091019] 
[Minor docstring fixup for with-call/cc
Marco Baringer <mb at bese.it>**20050707090619] 
[Big patch including all the cps interpreter stuff upto now
Marco Baringer <mb at bese.it>**20050707083739] 
[Fix bug in handling of defclass-struct's :predicate option
Marco Baringer <mb at bese.it>**20050706105324] 
[Initial Import
Marco Baringer <mb at bese.it>**20050706101657
 This import moves arnesi from arch to darcs. Nothing has actually changed since 
 bese-2004 at common-lisp.net/arnesi--dev--1.4--patch-14
] 
[added arch stuff to boring file
Marco Baringer <mb at bese.it>**20050706101630] 
[Setup boring file
Marco Baringer <mb at bese.it>**20050706100535] 
Patch bundle hash:
0710cdae3ffa469c0084ae037e75e40b52436c71