From mbaringer at common-lisp.net  Sat Apr  1 05:30:03 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Sat,  1 Apr 2006 00:30:03 -0500 (EST)
Subject: [Bese-devel] New patches to ucw_dev: 31-Mar-2006
Message-ID: <20060401053003.1929550002@common-lisp.net>


Fri Mar 31 07:21:18 EST 2006  Marco Baringer <mb at bese.it>
  * Added authors file

    A ./AUTHORS


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

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


From mb at bese.it  Sat Apr  1 11:27:59 2006
From: mb at bese.it (Marco Baringer)
Date: Sat, 01 Apr 2006 13:27:59 +0200
Subject: [Bese-devel] missing patches
Message-ID: <m2psk1pmbk.fsf@bese.it>


hi,

  i seem to have gotten forgetfull in applying patches sent to the
  list. if you have a patch which i have not yet applied please point
  it out to me, odds are the patch was fine and i just forgot to apply
  it. sorry.

ps - any of you who have commit priws to ucw please fell free to apply
patches sent to list if i don't seem to answer or apply them.

-- 
-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 hoan at ton-that.org  Sat Apr  1 08:51:10 2006
From: hoan at ton-that.org (Hoan Ton-That)
Date: Sat, 1 Apr 2006 19:51:10 +1100
Subject: [Bese-devel] Unwalker mistakes
Message-ID: <e2c5eaf10604010051k126eec39lf4fcb8240b8298e6@mail.gmail.com>

YO!

This fixes the mistakes in my code unwaker when unwalking
labels and flet.

Hoan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CHANGESET
Type: application/octet-stream
Size: 31179 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060401/1288f831/attachment.obj>

From luca at pca.it  Sat Apr  1 16:25:16 2006
From: luca at pca.it (Luca Capello)
Date: Sat, 01 Apr 2006 18:25:16 +0200
Subject: [Bese-devel] Re: New patches to ucw_dev: 30-Mar-2006
In-Reply-To: <m2odzmtwdw.fsf@bese.it> (Marco Baringer's message of "Fri, 31
	Mar 2006 18:24:43 +0200")
References: <20060331053003.CBC1B704B@common-lisp.net> <m2odzmtwdw.fsf@bese.it>
Message-ID: <87r74h9sb7.fsf@gismo.pca.it>

Hello!

On Fri, 31 Mar 2006 18:24:43 +0200, Marco Baringer wrote:
> mbaringer at common-lisp.net (Marco Baringer) writes:
>
>> Thu Mar 30 13:20:22 EST 2006  Luca Capello <luca at pca.it>
>>   * render UCW really configurable via ucwctl
>
> NB: this patch makes it difficult to start ucw without detachtty and
> cl-launch. if you don't have those two libs (and don't want to
> download them) don't pull this patch. this will last until we can
> figure out how to make the old 'load-one-file-to-start-ucw'
> behaviour fit into luca's new (very cool btw) framework.

Actually, the detachtty dependency is not really a problem: you can
start UCW directly with cl-launch, but not through ucwctl.  It should
not so difficult to provide an ucwctl option to start UCW without
detachtty, even if this means that you need to keep the terminal open
until the end of the UCW session.  I prefer the ancient option instead
(loading the start.lisp file), but I can work at it if someone is
interested and it will be `ucwctl --no-detachtty`.

The major feature of cl-launch is the fact that you don't need to
specify any arguments for the Common Lisp implementation you want to
use, but only the name of the implementation (thus removing the need
for the $EVAL option).

OTOH, the cl-launch dependency is mandatory for the `:ucw.default'
system because the `*ucw-config-file*' and `*ucw-log-root-directory*'
variables are defined through the `cl-launch:getenv' function
($CONFIGFILE and $LOGROOT, respectively).

The simplest (and preferable) solution would be to implement
`arnesi:getenv', thus letting UCW be loadable through the start.lisp
file only, something like:

  $ CONFIGFILE=filename LOGROOT=directory sbcl --load start.lisp

Otherwise, we can modify the `:ucw.default' system to define the
`*ucw-config-file*' and `*ucw-log-root-directory*' variables only when
the cl-launch package is found.

Other suggestions?

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

From luca at pca.it  Sat Apr  1 17:09:07 2006
From: luca at pca.it (Luca Capello)
Date: Sat, 01 Apr 2006 19:09:07 +0200
Subject: [Bese-devel] New patches to ucw_dev: 31-Mar-2006
In-Reply-To: <20060401053003.1929550002@common-lisp.net> (Marco Baringer's
	message of "Sat, 1 Apr 2006 00:30:03 -0500 (EST)")
References: <20060401053003.1929550002@common-lisp.net>
Message-ID: <871wwh9qa4.fsf@gismo.pca.it>

Hello!

On Sat, 01 Apr 2006 07:30:03 +0200, Marco Baringer wrote:
> Fri Mar 31 07:21:18 EST 2006  Marco Baringer <mb at bese.it>
>   * Added authors file
>
>     A ./AUTHORS

Shouldn't the same be done for the other BESE softwares?  :-)

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

From luca at pca.it  Sat Apr  1 17:19:40 2006
From: luca at pca.it (Luca Capello)
Date: Sat, 01 Apr 2006 19:19:40 +0200
Subject: [Bese-devel] ucwctl: load stop.lisp instead of calling
	`ucw:bye-bye'?
Message-ID: <87fykx8b83.fsf@gismo.pca.it>

Hello!

With my last patch [1], I removed the stop.lisp file, which I supposed
useless because we now use the following command to stop a running UCW
session:

  $ attachtty socket '(ucw:bye-bye)' timeout >/dev/null 2>&1 || \
      kill -s QUIT `cat pid`

Basically, this has the advantage of stopping UCW even in case
attachtty fails because it reaches the timeout.

On a private discussion, Marco proposed to use a stop.lisp file
instead, thus the command will be:

  $ attachtty socket '(load "stop.lisp")' timeout [... || ...]

This solution has a clear advantage, because you can customize the
stop.lisp file, which will be available as an ucwctl command line
argument.

In case of non-negative comments, I'll start implementing Marco's
suggestion in the next week.

Thx, bye,
Gismo / Luca

[1] Thu Mar 30 20:20:22 CEST 2006  Luca Capello <luca at pca.it>
      * render UCW really configurable via ucwctl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060401/6be34ca3/attachment.sig>

From mbaringer at common-lisp.net  Sun Apr  2 05:20:01 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Sun,  2 Apr 2006 00:20:01 -0500 (EST)
Subject: [Bese-devel] New patches to parenscript:  1-Apr-2006
Message-ID: <20060402052001.EE00C15001@common-lisp.net>


Sat Apr  1 06:39:18 EST 2006  Marco Baringer <mb at bese.it>
  * Export defjsmacro

    M ./src/package.lisp -1 +2

Sat Apr  1 06:35:03 EST 2006  Marco Baringer <mb at bese.it>
  * Added docstring for *js-quote-char*

    M ./src/js.lisp -1 +6

Sat Apr  1 06:28:58 EST 2006  Marco Baringer <mb at bese.it>
  * Add variable *js-quote-char* (Patch by: Xan Lopez <xan.lopez at gmail.com>)

    M ./src/js.lisp -2 +4


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

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


From mbaringer at common-lisp.net  Mon Apr  3 04:00:06 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Mon,  3 Apr 2006 00:00:06 -0400 (EDT)
Subject: [Bese-devel] New patches to arnesi_dev:  2-Apr-2006
Message-ID: <20060403040006.DC2292E189@common-lisp.net>


Sat Apr  1 03:48:03 EST 2006  Hoan Ton-That <hoan at ton-that.org>
  * Unwalker mistakes

    M ./src/unwalk.lisp -18 +19
    M ./t/walk.lisp -9 +9


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

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


From nathan at acceleration.net  Mon Apr  3 22:08:51 2006
From: nathan at acceleration.net (Nathan Bird)
Date: Mon, 3 Apr 2006 18:08:51 -0400
Subject: [Bese-devel] Class-slots direct and effective
In-Reply-To: <A8130C63-73CC-4CB3-A5CD-1CB7EB33FFCA@metabang.com>
Message-ID: <004d01c6576b$30f99ce0$d80a0a0a@acceleration.net>

<Birdman>	in arnesi>>walk.lisp>> make-load-form
(http://paste.lisp.org/display/18580) : as far as I can tell, the code there
should just be building up the list of effective slots which is what
class-slots does. am I missing something?

<Birdman>	The reason it is important is that ACL apparently doesn't
finalize all classes in that chain (namely form and application-form) b/c
they are never instantiated. but when that function recurses up hitting
class-slots it causes a problem.

<segv>	almost. the code in arnesi only saves those slots defined by form or
one of its subclasses, unlike class-slots whcih returns all slots.
<segv>	would it not be sufficent to add in finalinze-inheritence at
opportune places? (like just before the call to class-slots?)
<segv>	i'm also under the impression that class-slots retuns direct slots
only, not effective slots.


The definition given at http://www.lisp.org/mop/dictionary.html#class-slots
and experimentally in ACL and SBCL all indicate that class-slots gives the
effective slots. There is a class-direct-slots that might be more in line
with what you want.

Yes adding finalize-inheritance is enough to solve the problem I was having,
but I think we have stumbled upon a separate one here. Should it only be
getting slots derived from form (as you apparently intended) or should it be
getting effective-slots? I still haven't been able to fully grok what all is
going on here.  



From maciekp at japhy.fnord.org  Tue Apr  4 11:47:42 2006
From: maciekp at japhy.fnord.org (Maciek Pasternacki)
Date: Tue, 04 Apr 2006 13:47:42 +0200
Subject: [Bese-devel] ucw-forms?
Message-ID: <m264lpy335.fsf@japhy.fnord.org>

What does contain darcs repo at
http://common-lisp.net/project/ucw/repos/ucw-forms/ ?  It was only
imported at March 8 (about the same time ucw-presentations was
separated) with no further patches and seems to contain just an
outdated version of src/components/form.lisp file from ucw_dev.  Will
ucw-forms be separated or kept inside ucw?  Is this repo and package
relevant at all?

Sorry for bothering without properly reading archives but I don't have
my bese-devel archives handy, and search.gmane.org... well, I won't
say what I think about this engine because I don't like to use such
words in public ;)

-- 
/home/japhy/.sig/signatures: No such file or directory



From evrim at core.gen.tr  Tue Apr  4 19:47:19 2006
From: evrim at core.gen.tr (Evrim ULU)
Date: Tue, 04 Apr 2006 22:47:19 +0300
Subject: [Bese-devel] isolated actions
Message-ID: <4432CD47.5010304@core.gen.tr>

hi,

where do we use isolated actions in practice?

king regards,
evrim.


From a_bakic at yahoo.com  Tue Apr  4 21:40:53 2006
From: a_bakic at yahoo.com (Aleksandar Bakic)
Date: Tue, 4 Apr 2006 14:40:53 -0700 (PDT)
Subject: [Bese-devel] isolated actions
In-Reply-To: <4432CD47.5010304@core.gen.tr>
Message-ID: <20060404214053.46726.qmail@web34602.mail.mud.yahoo.com>

> where do we use isolated actions in practice?

For example, when the user submits a form and you want to ensure that the
semantics of that operation is at-most-once. That is, if the user click the
Back button and tries to resubmit it, the second attempt is ignored if an
isolated action is used.

BTW, what is the current status of these, has anyone fixed the problem of "T
not being a function" (or such)?

Alex

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From evrim at core.gen.tr  Tue Apr  4 20:51:47 2006
From: evrim at core.gen.tr (Evrim ULU)
Date: Tue, 04 Apr 2006 23:51:47 +0300
Subject: [Bese-devel] isolated actions
In-Reply-To: <4433535A.1030304@tech.coop>
References: <4432CD47.5010304@core.gen.tr> <4433535A.1030304@tech.coop>
Message-ID: <4432DC63.6090800@core.gen.tr>

Drew Crampsie wrote:

> :isolate should be used when you only want an action to fire once,
> even if the same link is clicked or the page reloaded.
>
> For example, if i have an 'charge-credit-card' action, i would not
> want a reload of the page or a 'back-button, click same link' to
> charge the card _again_ (well, i wouldn't mind, but the customer might
> be pissed). :ISOLATE memoizes the action body so that it will only run
> once, regardless of how many times the same URL is hit.
>
> The attached patch is against a slightly older ucw_dev. If it no
> longer applies cleanly, the replacement code for DEFACTION follows
> (and RUN-ISOLATED can be removed from standard-component.lisp).

That's great, there is one point i want to learn. If an action must be
isolated, do we need the same action as unisolated? It seems they'r
mutually exclusive. So, instead of hacking defaction, something like
defisolated-action would work better IMHO. What do you think?

king regards,
evrim.


From drewc at tech.coop  Wed Apr  5 06:08:47 2006
From: drewc at tech.coop (Drew Crampsie)
Date: Wed, 05 Apr 2006 02:08:47 -0400
Subject: [Bese-devel] isolated actions
In-Reply-To: <20060404214053.46726.qmail@web34602.mail.mud.yahoo.com>
References: <20060404214053.46726.qmail@web34602.mail.mud.yahoo.com>
Message-ID: <44335EEF.10407@tech.coop>

Aleksandar Bakic wrote:
>>where do we use isolated actions in practice?
> 
> 
> For example, when the user submits a form and you want to ensure that the
> semantics of that operation is at-most-once. That is, if the user click the
> Back button and tries to resubmit it, the second attempt is ignored if an
> isolated action is used.
> 
> BTW, what is the current status of these, has anyone fixed the problem of "T
> not being a function" (or such)?

I sent a patch to the list along with my reply to Evrim, which i am 
using in production without a problem.

I re-sent it, incase i messed something up. (i suck at mailing lists).

drewc
> 
> Alex
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> _______________________________________________
> 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  Wed Apr  5 06:17:58 2006
From: drewc at tech.coop (Drew Crampsie)
Date: Wed, 05 Apr 2006 02:17:58 -0400
Subject: [Bese-devel] isolated actions
In-Reply-To: <4432DC63.6090800@core.gen.tr>
References: <4432CD47.5010304@core.gen.tr> <4433535A.1030304@tech.coop>
	<4432DC63.6090800@core.gen.tr>
Message-ID: <44336116.9050107@tech.coop>

Evrim ULU wrote:
> Drew Crampsie wrote:
> 
> 
>>:isolate should be used when you only want an action to fire once,
>>even if the same link is clicked or the page reloaded.
>>
>>For example, if i have an 'charge-credit-card' action, i would not
>>want a reload of the page or a 'back-button, click same link' to
>>charge the card _again_ (well, i wouldn't mind, but the customer might
>>be pissed). :ISOLATE memoizes the action body so that it will only run
>>once, regardless of how many times the same URL is hit.
>>
>>The attached patch is against a slightly older ucw_dev. If it no
>>longer applies cleanly, the replacement code for DEFACTION follows
>>(and RUN-ISOLATED can be removed from standard-component.lisp).
> 
> 
> That's great, there is one point i want to learn. If an action must be
> isolated, do we need the same action as unisolated? It seems they'r
> mutually exclusive. So, instead of hacking defaction, something like
> defisolated-action would work better IMHO. What do you think?

I don't really see the difference (besides another symbol to export). If 
you need an isolated version of an action and a non-isolated, why not 
simply define the former in terms of the latter? ie:

(defaction foo (...)...)

(defaction isolate-foo :isolate (...)
   (foo ...))

Even if we make a new macro, actions still share the same namespace, so 
you'd still need the two defining forms, and since :isolate requires a 
change to standard-component (the hash table to store results), i can't 
see anything wrong with it being part of the standard machinery (and nor 
does marco, who put my :isolate patch in mainline UCW over a year ago).

What problem are you trying to solve that requires the separation of the 
  two defining macros in a way the current code does not?

cheers, drewc




> king regards,
> evrim.
> _______________________________________________
> 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  Wed Apr  5 06:06:54 2006
From: drewc at tech.coop (Drew Crampsie)
Date: Wed, 05 Apr 2006 02:06:54 -0400
Subject: [Bese-devel] isolated patch again (why it didn't go through.. or
	did it?)
Message-ID: <44335E7E.8020802@tech.coop>



-------- Original Message --------
Subject: Re: [Bese-devel] isolated actions
Date: Wed, 05 Apr 2006 01:19:22 -0400
From: Drew Crampsie <drewc at tech.coop>
To: Evrim ULU <evrim at core.gen.tr>
CC: bese-devel at common-lisp.net
References: <4432CD47.5010304 at core.gen.tr>

Evrim ULU wrote:
> hi,
> 
> where do we use isolated actions in practice?

Isolated actions! doh! (they don't work in ucw for a while now and i
forgot to send the patch (attached)).

:isolate should be used when you only want an action to fire once, even
if the same link is clicked or the page reloaded.

For example, if i have an 'charge-credit-card' action, i would not want
a reload of the page or a 'back-button, click same link' to charge the
card _again_ (well, i wouldn't mind, but the customer might be pissed).
:ISOLATE memoizes the action body so that it will only run once,
regardless of how many times the same URL is hit.

The attached patch is against a slightly older ucw_dev. If it no longer
applies cleanly, the replacement code for DEFACTION follows (and
RUN-ISOLATED can be removed from standard-component.lisp).

Cheers,

drewc

(defmacro defaction (name &rest rest)
    (if (equal (car rest) :isolate)
        (with-unique-names (memo-id memo memo-present-p)
          `(defaction ,name ,(second rest)
            (let ((,memo-id
                   (strcat (mapcar (rcurry #'funcall *context*)
                                   (list #'find-session-id
                                         #'find-frame-id
                                         #'find-action-id)))))
            (multiple-value-bind (,memo ,memo-present-p)
                (gethash ,memo-id (component.isolate-hash ,(caar (second
rest))))
              (if  ,memo-present-p
                   ,memo
                   (setf (gethash ,memo-id (component.isolate-hash ,(caar
(second rest))))
                         (progn ,@ (cddr rest))))))))

        `(%defaction ,name , at rest)))



> 
> king regards,
> evrim.
> _______________________________________________
> bese-devel mailing list
> bese-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: isolate.patch
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060405/a3491aa3/attachment.ksh>

From drewc at tech.coop  Wed Apr  5 06:11:55 2006
From: drewc at tech.coop (Drew Crampsie)
Date: Wed, 05 Apr 2006 02:11:55 -0400
Subject: [Bese-devel] isolated actions
In-Reply-To: <44335EEF.10407@tech.coop>
References: <20060404214053.46726.qmail@web34602.mail.mud.yahoo.com>
	<44335EEF.10407@tech.coop>
Message-ID: <44335FAB.6000503@tech.coop>

Drew Crampsie wrote:

> 
> 
> I sent a patch to the list along with my reply to Evrim, which i am 
> using in production without a problem.
> 
> I re-sent it, incase i messed something up. (i suck at mailing lists).

And i still don't see it, so here it is again :

basically, replace defaction with :

(defmacro defaction (name &rest rest)
   (if (equal (car rest) :isolate)
       (with-unique-names (memo-id memo memo-present-p)
         `(defaction ,name ,(second rest)
           (let ((,memo-id
                  (strcat (mapcar (rcurry #'funcall *context*)
                                  (list #'find-session-id
                                        #'find-frame-id
                                        #'find-action-id)))))
           (multiple-value-bind (,memo ,memo-present-p)
               (gethash ,memo-id (component.isolate-hash ,(caar (second 
rest))))
             (if  ,memo-present-p
                  ,memo
                  (setf (gethash ,memo-id (component.isolate-hash ,(caar 
(second rest))))
                        (progn ,@ (cddr rest))))))))

       `(%defaction ,name , at rest)))

and remove RUN-ISOLATED from standard-component.lisp


Sorry if this appeared multiple times, etc etc.

drewc

> 
> drewc
> 
>>
>> Alex
>>
>> __________________________________________________
>> Do You Yahoo!?
>> Tired of spam?  Yahoo! Mail has the best spam protection around 
>> http://mail.yahoo.com _______________________________________________
>> bese-devel mailing list
>> bese-devel at common-lisp.net
>> http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel
> 
> 
> _______________________________________________
> bese-devel mailing list
> bese-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: isolate.patch
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060405/f531a75c/attachment.ksh>

From drewc at tech.coop  Wed Apr  5 05:19:22 2006
From: drewc at tech.coop (Drew Crampsie)
Date: Wed, 05 Apr 2006 01:19:22 -0400
Subject: [Bese-devel] isolated actions
In-Reply-To: <4432CD47.5010304@core.gen.tr>
References: <4432CD47.5010304@core.gen.tr>
Message-ID: <4433535A.1030304@tech.coop>

Evrim ULU wrote:
> hi,
> 
> where do we use isolated actions in practice?

Isolated actions! doh! (they don't work in ucw for a while now and i 
forgot to send the patch (attached)).

:isolate should be used when you only want an action to fire once, even 
if the same link is clicked or the page reloaded.

For example, if i have an 'charge-credit-card' action, i would not want 
a reload of the page or a 'back-button, click same link' to charge the 
card _again_ (well, i wouldn't mind, but the customer might be pissed). 
:ISOLATE memoizes the action body so that it will only run once, 
regardless of how many times the same URL is hit.

The attached patch is against a slightly older ucw_dev. If it no longer 
applies cleanly, the replacement code for DEFACTION follows (and 
RUN-ISOLATED can be removed from standard-component.lisp).

Cheers,

drewc

(defmacro defaction (name &rest rest)
   (if (equal (car rest) :isolate)
       (with-unique-names (memo-id memo memo-present-p)
         `(defaction ,name ,(second rest)
           (let ((,memo-id
                  (strcat (mapcar (rcurry #'funcall *context*)
                                  (list #'find-session-id
                                        #'find-frame-id
                                        #'find-action-id)))))
           (multiple-value-bind (,memo ,memo-present-p)
               (gethash ,memo-id (component.isolate-hash ,(caar (second 
rest))))
             (if  ,memo-present-p
                  ,memo
                  (setf (gethash ,memo-id (component.isolate-hash ,(caar 
(second rest))))
                        (progn ,@ (cddr rest))))))))

       `(%defaction ,name , at rest)))



> 
> king regards,
> evrim.
> _______________________________________________
> bese-devel mailing list
> bese-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: isolate.patch
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060405/e36d29d5/attachment.ksh>

From evrim at core.gen.tr  Tue Apr  4 21:25:48 2006
From: evrim at core.gen.tr (Evrim ULU)
Date: Wed, 05 Apr 2006 00:25:48 +0300
Subject: [Bese-devel] isolated actions
In-Reply-To: <44336116.9050107@tech.coop>
References: <4432CD47.5010304@core.gen.tr> <4433535A.1030304@tech.coop>
	<4432DC63.6090800@core.gen.tr> <44336116.9050107@tech.coop>
Message-ID: <4432E45C.1090600@core.gen.tr>

Drew Crampsie wrote:

> What problem are you trying to solve that requires the separation of
> the  two defining macros in a way the current code does not?
>
I'm considering to do a similar hook to defaction for ajax, it seems,
this strategy will bloat the defaction macro. I may define (defaction
sample-action :ajax) but maintainability will decrease. This is why i
offered the defisolated-action macro.

king regards,
evrim.


From drewc at tech.coop  Wed Apr  5 07:02:24 2006
From: drewc at tech.coop (Drew Crampsie)
Date: Wed, 05 Apr 2006 03:02:24 -0400
Subject: [Fwd: Re: [Bese-devel] isolated actions]
Message-ID: <44336B80.3060307@tech.coop>

Just confirming my mailing list disability, forgot to cc the list on my 
last response. Sorry to all those who learned how to use email, i was 
sick that day.

drewc
-------- Original Message --------
Subject: Re: [Bese-devel] isolated actions
Date: Wed, 05 Apr 2006 03:00:51 -0400
From: Drew Crampsie <drewc at tech.coop>
To: Evrim ULU <evrim at core.gen.tr>
References: <4432CD47.5010304 at core.gen.tr> <4433535A.1030304 at tech.coop> 
<4432DC63.6090800 at core.gen.tr> <44336116.9050107 at tech.coop> 
<4432E45C.1090600 at core.gen.tr>

Evrim ULU wrote:
> Drew Crampsie wrote:
> 
> 
>>What problem are you trying to solve that requires the separation of
>>the  two defining macros in a way the current code does not?
>>
> 
> I'm considering to do a similar hook to defaction for ajax, it seems,
> this strategy will bloat the defaction macro. I may define (defaction
> sample-action :ajax) but maintainability will decrease. This is why i
> offered the defisolated-action macro.


I see. In that case, why not refactor DEFACTION to grab it's definer
from a hash table keyed on the 'combination' keyword.

Something like (completely untested and unfinished):

(defvar *action-definers* (make-hash-table))

(defmacro define-action-definer (type &body body)
  "basically just wrap a lambda around the macro form which accepts the
name and the body of the action"
  (setf (gethash type *action-definers*)
   `(lambda (name rest)
      , at body))

(define-action-definer (:isolate)
  (with-unique-names (memo-id memo memo-present-p)
         `(defaction ,name ,(second rest)
           (let ((,memo-id
                  (strcat (mapcar (rcurry #'funcall *context*)
                                  (list #'find-session-id
                                        #'find-frame-id
                                        #'find-action-id)))))
           (multiple-value-bind (,memo ,memo-present-p)
               (gethash ,memo-id (component.isolate-hash ,(caar (second
rest))))
             (if  ,memo-present-p
                  ,memo
                  (setf (gethash ,memo-id (component.isolate-hash ,(caar
(second rest))))
                        (progn ,@ (cddr rest)))))))))


(defmacro defaction (name &rest rest)
   (if (keywordp (car rest))
       ,(funcall (gethash (car rest) *action-definers*) name rest)
       `(%defaction ,name , at rest)))

Cleans things up a bit IMO.

Then again, why do you need a new definer for 'ajax' actions? A normal
action can be used with ajax just fine, like :

`(dojo.io.bind
   (create :url ,(lol::make-action-url
	         component
	         (my-action component datum))
           :load (do-some-js-with-results)))

where lol::make-action-url is defined as:

(defmacro make-action-url (component action)
   "
There has got to be something like this buried in UCW somewhere,
but here's what i use."
   `(ucw::print-uri-to-string
     (compute-url ,component
      :action-id (ucw::make-new-action (ucw::context.current-frame
*context*)
		 (lambda ()
		   (arnesi:with-call/cc
		     ,action))))))

Of course i've got layers of macros over all this to make it easier to
use, but that's the underlying machinery. Very simple, easy to use, and
no need for a new type of action (in fact, i have code that makes a
'normal' component into an 'ajax' component with a one-line change).

I think this is a better approach, although i may not understand what
you are trying to achieve.

drewc





> 
> king regards,
> evrim.
> _______________________________________________
> bese-devel mailing list
> bese-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel




From cjstuij at gmail.com  Tue Apr  4 11:52:31 2006
From: cjstuij at gmail.com (Ties Stuij)
Date: Tue, 4 Apr 2006 13:52:31 +0200
Subject: [Bese-devel] another ucw tutorial
Message-ID: <d7ce4ebf0604040452x31e54e14g99afa95152623842@mail.gmail.com>

he there,

In the past few days i've been busy writing a ucw tutorial. I know
about the cliki one, in fact i copied ideas here and there, but i
wanted to make a document which goes through the material a bit
slower. It is intended to be a one-stop resource for the ucw-newbie,
almost like a manual. It's not finished yet but i would like some
feedback on it. Any critique is very welcome, especially on the
overall style and structure of the text and on my take on the inner
workings of ucw. The model in my head seems well enough to predict
what ucw will do, but it is bound to be full of misconceptions.

you can skip issues which are on my todo list:
- finishing not written chapters
- rewriting configuration stuff (upcoming defentry-point changes plus
the new startup code supplied by luca plus future modifications to
that one to let ucw start without detachtty)
- creating proper intro sources

furthermore i have some questions to fill holes in the tutorial:

- does ucw work at all on windows? I guess not but if you have
experience, let me know.
- in what ways does configuring a mac to work with ucw differ from
freebsd/linux if at all.
- On which other os-ses does ucw work (apart from freebsd,linux and osx)
- what are the limitations of code inside actions? What part of c-l
isn't captured?
- Which dependencies of ucw are covered by apt-get on debian? all? I
found some info which i presented as facts but they are probably out
of date.
- is there a tarball of ucw's version of detachtty? It would be nice
to have one, since it's the only dependency for which you really need
darcs.

the tutorial is to be found on http://www.fallenfrukt.com/ucw-intro.html

have fun reading ;-)

Ties


From drewc at tech.coop  Wed Apr  5 07:43:56 2006
From: drewc at tech.coop (Drew Crampsie)
Date: Wed, 05 Apr 2006 03:43:56 -0400
Subject: [Bese-devel] another ucw tutorial
In-Reply-To: <d7ce4ebf0604040452x31e54e14g99afa95152623842@mail.gmail.com>
References: <d7ce4ebf0604040452x31e54e14g99afa95152623842@mail.gmail.com>
Message-ID: <4433753C.6010701@tech.coop>

Great job so far. I just want to mention a few things.

Under no circumstances ever should a debian user use the .debs for lisp 
based development. It will only cause problems in the end.

The arnesi and yaclml packages (among others) in debian lag way too far 
behind to be useful, and will only cause headaches and frustration.
(i am a long time debian+lisp user, so you'll just have to take my word 
on this).

On top of that, c-l-c is basically just screwed, especially for SBCL 
users. Best idea is to use asdf-install or manual methods over apt-get.

Besides that, it's a great piece of work so far!

drewc

Ties Stuij wrote:

> furthermore i have some questions to fill holes in the tutorial:
> 
> - does ucw work at all on windows? I guess not but if you have
> experience, let me know.
> - in what ways does configuring a mac to work with ucw differ from
> freebsd/linux if at all.
> - On which other os-ses does ucw work (apart from freebsd,linux and osx)
> - what are the limitations of code inside actions? What part of c-l
> isn't captured?
> - Which dependencies of ucw are covered by apt-get on debian? all? I
> found some info which i presented as facts but they are probably out
> of date.
> - is there a tarball of ucw's version of detachtty? It would be nice
> to have one, since it's the only dependency for which you really need
> darcs.
> 
> the tutorial is to be found on http://www.fallenfrukt.com/ucw-intro.html
> 
> have fun reading ;-)
> 
> Ties
> _______________________________________________
> bese-devel mailing list
> bese-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel



From attila.lendvai at gmail.com  Tue Apr  4 21:07:03 2006
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Tue, 4 Apr 2006 23:07:03 +0200
Subject: [Bese-devel] isolated actions
In-Reply-To: <4432CD47.5010304@core.gen.tr>
References: <4432CD47.5010304@core.gen.tr>
Message-ID: <b54b34af0604041407q37c4c24cw741f604560dc3d5@mail.gmail.com>

On 4/4/06, Evrim ULU <evrim at core.gen.tr> wrote:
>
> hi,
>
> where do we use isolated actions in practice?


i have an example (it's in a test code, though...)

i have a generated png, and i want a button that invalidates the image. but
i don't want the invalidation to be triggered again with a browser
refresh...

btw, it doesn't work with the ucw_dev branch. if you are interested in
details, take a look at this thread: actions and broswer refresh

- attila

(alias 101 on irc &no 'its not lisp code :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060404/c80f7638/attachment.html>

From aycan.irican at core.gen.tr  Wed Apr  5 00:56:06 2006
From: aycan.irican at core.gen.tr (Aycan iRiCAN)
Date: Wed, 05 Apr 2006 03:56:06 +0300
Subject: [Bese-devel] file corruption after upload
Message-ID: <87lkukx2l5.fsf@www.hedee.com>


Hi,

I'm unable to upload files without a corruption, especially larger
than 64K ones. Uploaded file and the original have the same size but
their bytes are not equal. Is there anybody got this problem before?

Best Regards.

-- 
Aycan iRiCAN
C0R3 Computer Security Group
http://www.core.gen.tr
-------------- 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/20060405/0103557d/attachment.sig>

From brandon at cs.uri.edu  Wed Apr  5 01:23:20 2006
From: brandon at cs.uri.edu (Brandon Edens)
Date: Tue, 4 Apr 2006 21:23:20 -0400
Subject: [Bese-devel] another ucw tutorial
In-Reply-To: <4433753C.6010701@tech.coop>
References: <d7ce4ebf0604040452x31e54e14g99afa95152623842@mail.gmail.com>
	<4433753C.6010701@tech.coop>
Message-ID: <20060405012320.GA8105@gizmo.brown.edu>

On Wed, Apr 05, 2006 at 03:43:56AM -0400, Drew Crampsie wrote:

> On top of that, c-l-c is basically just screwed, especially for SBCL 
> users. Best idea is to use asdf-install or manual methods over apt-get.

Curious. what is broken about c-l-c? Is there some place where I can read
criticisms about it?

Brandon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060404/55b76fca/attachment.sig>

From drewc at tech.coop  Wed Apr  5 10:10:36 2006
From: drewc at tech.coop (Drew Crampsie)
Date: Wed, 05 Apr 2006 06:10:36 -0400
Subject: [Bese-devel] another ucw tutorial
In-Reply-To: <20060405012320.GA8105@gizmo.brown.edu>
References: <d7ce4ebf0604040452x31e54e14g99afa95152623842@mail.gmail.com>
	<4433753C.6010701@tech.coop> <20060405012320.GA8105@gizmo.brown.edu>
Message-ID: <4433979C.4000703@tech.coop>

Brandon Edens wrote:
> On Wed, Apr 05, 2006 at 03:43:56AM -0400, Drew Crampsie wrote:
> 
> 
>>On top of that, c-l-c is basically just screwed, especially for SBCL 
>>users. Best idea is to use asdf-install or manual methods over apt-get.
> 
> 
> Curious. what is broken about c-l-c? Is there some place where I can read
> criticisms about it?

Well, in does infact work wonders when you stay within it's world.. it's 
when mixing things up (which, as a ucw user, we must) that it starts to 
have problems. The problems c-l-c solve are not those of a lisp 
developer, but rather those trying to package these things as part of a 
distribution.

As an SBCL user, you are also going to want to stay current, which means 
that you will probably install the latest sbcl. Unless you want to 
create a .deb and update all the c-l-c installed libraries to ones that 
work with the latest, you are stuck installing all the libraries by hand 
  anyway.

So, i was a bit harsh on c-l-c, it's a good system for what it tries to 
do, which is a cross-lisp application delivery type thing.. but as a 
developer it tends to get in the way.

> Brandon



From attila.lendvai at gmail.com  Wed Apr  5 08:15:29 2006
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Wed, 5 Apr 2006 10:15:29 +0200
Subject: [Bese-devel] another ucw tutorial
In-Reply-To: <20060405012320.GA8105@gizmo.brown.edu>
References: <d7ce4ebf0604040452x31e54e14g99afa95152623842@mail.gmail.com>
	<4433753C.6010701@tech.coop> <20060405012320.GA8105@gizmo.brown.edu>
Message-ID: <b54b34af0604050115u2306a342g275ddf7070a211c4@mail.gmail.com>

On 4/5/06, Brandon Edens <brandon at cs.uri.edu> wrote:
>
> On Wed, Apr 05, 2006 at 03:43:56AM -0400, Drew Crampsie wrote:
>
> > On top of that, c-l-c is basically just screwed, especially for SBCL
> > users. Best idea is to use asdf-install or manual methods over apt-get.
>
> Curious. what is broken about c-l-c? Is there some place where I can read
> criticisms about it?


i'm realtively new to list, and i also started on the sbcl on debian
route... and of course i met c-l-c. but stopped using it after about a few
days, when i saw that doing admin stuff by hand just works better and causes
less headaches.

unfortunately i don't have any constructive criticism anymore.

- attila

(alias 101 on irc &no 'its not lisp code :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060405/9c0c8cd8/attachment.html>

From luca at pca.it  Wed Apr  5 08:47:35 2006
From: luca at pca.it (Luca Capello)
Date: Wed, 05 Apr 2006 10:47:35 +0200
Subject: [Bese-devel] another ucw tutorial
In-Reply-To: <d7ce4ebf0604040452x31e54e14g99afa95152623842@mail.gmail.com>
References: <d7ce4ebf0604040452x31e54e14g99afa95152623842@mail.gmail.com>
Message-ID: <87slosv26w.fsf@gismo.pca.it>

Hello!

Just a quick comment (I don't have a lot of time for a deeper
read...).

On Tue, 04 Apr 2006 13:52:31 +0200, Ties Stuij wrote:
> - Which dependencies of ucw are covered by apt-get on debian? all? I
> found some info which i presented as facts but they are probably out
> of date.

The references about UCW on Debian is this thread [1].  Here some
corrections about the tutorial Debian section:

- the cl-rfc2388 package in Debian is the upstream one and not Marco's
  fork, so it shouldn't work with UCW.  As a side note, after some
  discussion I had with Marco, he'd like to merge back his fork.

- parenscript is now in unstable, it should reach testing soon.

- slime is present in testing non-free, because of a license problem
  with a specific file for the swank module.  If you don't want to
  connect within Emacs, you just need the cl-swank package.

I'd suggest including your tutorial in the UCW repository ;-)

Thx, bye,
Gismo / Luca

[1] http://common-lisp.net/pipermail/cl-debian/2006-March/001113.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060405/7fdcf610/attachment.sig>

From evrim at core.gen.tr  Wed Apr  5 08:40:36 2006
From: evrim at core.gen.tr (Evrim ULU)
Date: Wed, 05 Apr 2006 11:40:36 +0300
Subject: [Fwd: Re: [Bese-devel] isolated actions]
In-Reply-To: <44336B80.3060307@tech.coop>
References: <44336B80.3060307@tech.coop>
Message-ID: <44338284.5020807@core.gen.tr>

Drew Crampsie wrote:

>
> Cleans things up a bit IMO.

good morning Drew,

Let's make this stay inside the code segment, ok?

(defmacro defaction (name &rest rest)
  (if (and (listp rest)
       (keywordp (car rest)))
      (let ((macro-symbol (intern (format nil "DEFACTION-~A"
(string-upcase (car rest))))))
    `(,macro-symbol ,name ,@(cdr rest)))
      `(%defaction ,name , at rest)))

(defmacro defaction-isolate (name &rest rest)
  (format t "~%name:~A, rest: ~S~%" name rest))

(defmacro defaction-yourfavoritekeywordhere (name &rest rest) ...

If you are comfortable with this, i'm going to add and export your
isolate action, of course, you may continue using the old style.

king regards,
evrim.


From maciekp at japhy.fnord.org  Wed Apr  5 11:45:10 2006
From: maciekp at japhy.fnord.org (Maciek Pasternacki)
Date: Wed, 05 Apr 2006 13:45:10 +0200
Subject: [Bese-devel] Re: file corruption after upload
References: <87lkukx2l5.fsf@www.hedee.com>
Message-ID: <m2mzf06ybd.fsf@japhy.fnord.org>

On Setting Orange, Discord 22, 3172 YOLD, Aycan iRiCAN wrote:

> I'm unable to upload files without a corruption, especially larger
> than 64K ones. Uploaded file and the original have the same size but
> their bytes are not equal. Is there anybody got this problem before?

No problems here, but I'll test it.  Can you give us example file that
fails to upload correctly?

I assume you use current (darcs) version of ucw_dev and rfc2388; am I
correct?  Which backend do you use?

-- 
-><- This signature intentionally left blank. -><-



From mb at bese.it  Wed Apr  5 12:07:28 2006
From: mb at bese.it (Marco Baringer)
Date: Wed, 05 Apr 2006 14:07:28 +0200
Subject: [Bese-devel] Re: Class-slots direct and effective
References: <A8130C63-73CC-4CB3-A5CD-1CB7EB33FFCA@metabang.com>
	<004d01c6576b$30f99ce0$d80a0a0a@acceleration.net>
Message-ID: <m2zmj0p6nz.fsf@bese.it>

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

> The definition given at http://www.lisp.org/mop/dictionary.html#class-slots
> and experimentally in ACL and SBCL all indicate that class-slots gives the
> effective slots. There is a class-direct-slots that might be more in line
> with what you want.

i did some testing comparing the current code with the equivalent
class-slots based code and discovered that the two are
equivalent. thanks for reporting this.

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



From mb at bese.it  Wed Apr  5 12:11:01 2006
From: mb at bese.it (Marco Baringer)
Date: Wed, 05 Apr 2006 14:11:01 +0200
Subject: [Bese-devel] Re: ucw-forms?
References: <m264lpy335.fsf@japhy.fnord.org>
Message-ID: <m2vetop6i2.fsf@bese.it>

Maciek Pasternacki <maciekp at japhy.fnord.org> writes:

> What does contain darcs repo at
> http://common-lisp.net/project/ucw/repos/ucw-forms/ ?  It was only
> imported at March 8 (about the same time ucw-presentations was
> separated) with no further patches and seems to contain just an
> outdated version of src/components/form.lisp file from ucw_dev.  Will
> ucw-forms be separated or kept inside ucw?  Is this repo and package
> relevant at all?

i had, at one point, considered splitting ucw into lots of little
parts (one for the core, one for the standard-components, one for
yaclml, one for dojo, one for forms, etc.) i still think it's a good
idea but i need to think more about the best to actually implement it.

the ucw-forms repo is a left over from that test, i'll delete 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  Wed Apr  5 12:14:43 2006
From: mb at bese.it (Marco Baringer)
Date: Wed, 05 Apr 2006 14:14:43 +0200
Subject: [Bese-devel] Re: file corruption after upload
References: <87lkukx2l5.fsf@www.hedee.com> <m2mzf06ybd.fsf@japhy.fnord.org>
Message-ID: <m2mzf0p6bw.fsf@bese.it>

Maciek Pasternacki <maciekp at japhy.fnord.org> writes:

> On Setting Orange, Discord 22, 3172 YOLD, Aycan iRiCAN wrote:
>
>> I'm unable to upload files without a corruption, especially larger
>> than 64K ones. Uploaded file and the original have the same size but
>> their bytes are not equal. Is there anybody got this problem before?
>
> No problems here, but I'll test it.  Can you give us example file that
> fails to upload correctly?

over 200 image files have been uploaded to animaliter.it in the last
few weeks, not one has been corrupted. there were originally some
_major_ problems with the handling of CR and LF characters embedded in
the images, but i think i fixed them all.

can you a) send the file which is being corrupted and b) try running
the random-junk test in rfc2388 (this test was added specifically to
stress test the errors i originally saw in rfc2388's parser)?

-- 
-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 Apr  5 14:23:20 2006
From: cjstuij at gmail.com (Ties Stuij)
Date: Wed, 5 Apr 2006 16:23:20 +0200
Subject: [Bese-devel] another ucw tutorial
In-Reply-To: <87slosv26w.fsf@gismo.pca.it>
References: <d7ce4ebf0604040452x31e54e14g99afa95152623842@mail.gmail.com>
	<87slosv26w.fsf@gismo.pca.it>
Message-ID: <d7ce4ebf0604050723y36b859cv78bed63fa1f38b6d@mail.gmail.com>

Thanks for the feedback people,

but relating debian i'm now more confused than i was before. thanks a lot ;)

i'll look into it and i'll make some changes,

Ties


From pjdtech2000 at gmail.com  Wed Apr  5 16:31:53 2006
From: pjdtech2000 at gmail.com (pjd tech)
Date: Wed, 5 Apr 2006 10:31:53 -0600
Subject: [Bese-devel] starting problems (cl-launch)
Message-ID: <4f712c6f0604050931l27bcc17bh99b76760957bf3f8@mail.gmail.com>

Greetings,

I having problems getting UCW_DEV going. (I had it working a while back when
everything was in one tar ball). Now I am pulling the development versions
from Darcs repositories as mentioned in the quickstart guide.


Mainly I am not sure how CL-Launch thing is supposed to work. I untarred the
cl-launch package and added the folder to my local PATH.
But ucwctl couldnt even start with that.
I renamed CL-Launch.sh as cl-launch.  Then UCW will mostly load (tail -f the
dribble file). But finally breaks like this ,

37: (SB-INT:EVAL-IN-LEXENV
     (PROGN
      (SET-DISPATCH-MACRO-CHARACTER #\#
                                    #\!
                                    #'(LAMBDA (STREAM CHAR SB-DEBUG:ARG)
                                        (DECLARE (IGNORE CHAR SB-DEBUG:ARG))
                                        (VALUES (READ-LINE STREAM))))
      (LOAD "/home/pjdurai/software/lispprogs/cl-launch/cl-launch"
            :VERBOSE
            NIL
            :PRINT
            NIL)
      (FUNCALL (INTERN (STRING :RUN) :CL-LAUNCH)
               :INIT
               "(load (pop cl-launch:*arguments*))"
               :QUIT
               NIL))
     #<NULL-LEXENV>)
38: (SB-IMPL::PROCESS-EVAL-OPTIONS
     ((SB-EXT:DISABLE-DEBUGGER)
      "(progn(set-dispatch-macro-character #\\# #\\! #'(lambda(stream char
arg)(declare(ignore char arg))(values (read-line stream))))(load
\"/home/pjdurai/software/lispprogs/cl-launch/cl-launch\" :verbose nil :print
nil)
(funcall(intern(string :run):cl-launch) :init \"(load (pop
cl-launch:*arguments*))\" :quit nil))"))
39: (SB-IMPL::TOPLEVEL-INIT)
40: ((LABELS SB-IMPL::RESTART-LISP))


More info:

slackware 10.2, sbcl 0.9.11 binary release, recent versions of pretty much
every other dependency.
I dont understand how cl-launch would work. Any help appreciated.

Appreciate your time.

thanks
pj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060405/5fc6ff7c/attachment.html>

From maciekp at japhy.fnord.org  Wed Apr  5 23:55:38 2006
From: maciekp at japhy.fnord.org (Maciek Pasternacki)
Date: Thu, 06 Apr 2006 01:55:38 +0200
Subject: [Bese-devel] Simple-form inside TAL and (validp)
Message-ID: <m24q177f2d.fsf@japhy.fnord.org>

My code goes like this: I have template component, let's call it foo,
which renders simple-form, called bar, with <ucw:render/> tag inside
TAL.  This form, in its submit action, does (answer-component
(ucw::parent self) return-value).  And everything would be ok, but the
submit action wants to call (validp self) first; validp loops over all
slots of the class and barfs on trying to access slots
'ucw::continuation and 'ucw::calling-component -- they're undefined
since form wasn't called directly but only used as a widget inside
other component.

For a moment I plumbed it over in form.lisp by not checking those two
slots, but the question is if changing my code (i.e. to make my TAL a
container component (which IMO would make no sense because this
template is used only once with this one form) or otherwise (call) bar
form directly) wouldn't be Righter Thing To Do?  I'm not sure if the
bug is mine or ucw's, and when it comes to continuations and
metaclasses my brains starts to hurt so I figured I'd better ask ;)

-- 
-><- This signature intentionally left blank. -><-



From mbaringer at common-lisp.net  Thu Apr  6 04:00:06 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Thu,  6 Apr 2006 00:00:06 -0400 (EDT)
Subject: [Bese-devel] New patches to arnesi_dev:  5-Apr-2006
Message-ID: <20060406040006.50B55200A@common-lisp.net>


Wed Apr  5 08:06:48 EDT 2006  Marco Baringer <mb at bese.it>
  * Use class-slots instead of our custom 'walk class hierarchy and collect slot defs' code.
  
  This change should fix problems with allegro. Nathan Bird reported
  this and suggested the proper solution.

    M ./src/walk.lisp -14 +4


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

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


From mbaringer at common-lisp.net  Thu Apr  6 04:30:03 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Thu,  6 Apr 2006 00:30:03 -0400 (EDT)
Subject: [Bese-devel] New patches to ucw_dev:  5-Apr-2006
Message-ID: <20060406043003.CAAC9A0E5@common-lisp.net>


Sat Apr  1 08:39:27 EST 2006  Marco Baringer <mb at bese.it>
  * The username and password inputs sholud specify a constant name to play nice with firefox's remeber-password feature

    M ./src/components/login.lisp -2 +4

Mon Mar 27 10:16:00 EST 2006  Marco Baringer <mb at bese.it>
  * Warn when no callback is found

    M ./src/rerl/standard-session-frame.lisp -1 +2

Mon Mar 27 05:20:10 EST 2006  Marco Baringer <mb at bese.it>
  * Remeber to pass the value of the name slot to make-new-callback

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

Mon Mar 27 05:19:38 EST 2006  Marco Baringer <mb at bese.it>
  * Fix typo in simple-form's :initarg

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

Sun Mar 26 13:10:54 EST 2006  Marco Baringer <mb at bese.it>
  * Export render-template

    M ./src/packages.lisp +1

Sat Mar 25 13:20:49 EST 2006  Marco Baringer <mb at bese.it>
  * Actually fix call to string-trim

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

Sat Mar 25 13:16:11 EST 2006  Marco Baringer <mb at bese.it>
  UNDO: Use cl:string-trim instead of (the no longer existent) arnesi:trim-sting

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

Sat Mar 25 13:16:11 EST 2006  Marco Baringer <mb at bese.it>
  * Use cl:string-trim instead of (the no longer existent) arnesi:trim-sting

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

Sat Mar 25 11:41:15 EST 2006  Marco Baringer <mb at bese.it>
  * Export #:context.request #:context.response #:context.session

    M ./src/packages.lisp +3

Sat Mar 18 08:08:58 EST 2006  Marco Baringer <mb at bese.it>
  * When reporting the url we're handling (in the httpd backend's handle-request method) show the entire url, not just the query-path

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


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

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


From mbaringer at common-lisp.net  Fri Apr  7 04:30:04 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Fri,  7 Apr 2006 00:30:04 -0400 (EDT)
Subject: [Bese-devel] New patches to ucw_dev:  6-Apr-2006
Message-ID: <20060407043004.B045723003@common-lisp.net>


Thu Apr  6 18:25:17 EDT 2006  Maciek Pasternacki <maciekp at japhy.fnord.org>
  * Export ucw:client-value (used in forms.lisp, was cut out with ucw-presentation exports).

    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-20060406.tar.gz

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


From aycan.irican at core.gen.tr  Thu Apr  6 20:38:07 2006
From: aycan.irican at core.gen.tr (Aycan iRiCAN)
Date: Thu, 06 Apr 2006 23:38:07 +0300
Subject: [Bese-devel] File upload problem
Message-ID: <44357C2F.7000203@core.gen.tr>

Hi,

One of our users having problem when she tries to upload his photograph. 
At the backend I'm getting this error:

invalid array index 163 for "!\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~" (should be nonnegative and <94)

The problem occurs when uploading the file with IE6. Firefox 1.5 
successfuly send the file. I just tried to find the problem but rfc2388 
has lot's of bits&bytes for me. I'm attaching the file.

Best Regards
--
aycan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.JPG
Type: image/jpeg
Size: 39753 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060406/b0844269/attachment.jpe>

From mb at bese.it  Fri Apr  7 09:03:07 2006
From: mb at bese.it (Marco Baringer)
Date: Fri, 07 Apr 2006 11:03:07 +0200
Subject: [Bese-devel] Re: File upload problem
References: <44357C2F.7000203@core.gen.tr>
Message-ID: <m2u09592r8.fsf@bese.it>

Aycan iRiCAN <aycan.irican at core.gen.tr> writes:

> Hi,
>
> One of our users having problem when she tries to upload his
> photograph. At the backend I'm getting this error:
>
> invalid array index 163 for "!\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~" (should be nonnegative and <94)

educated guess:

that error message is signaled by the as-ascii-char function in
rfc2388. as-ascii-char is called to convert the bytes in a mime part's
headers into a character, so i'm going to assume that this error is
occuring when trying to decode the file's name (i can't think of
another mime header which would have non-7-bit-asci characters in
it).

so, question #1: what's the name of the file? if you change it
something using only ascii chars does the problem go away?

as a hack fix until we figure out if this is the real issue and, if so,
what encoding is being used, use this:

(defun as-ascii-char (byte)
  "Assuming BYTE is an ASCII coded character retun the corresponding character."
  (code-char byte))

instead of the as-ascii-char function in rfc2388/source/rfc2388.lisp

> The problem occurs when uploading the file with IE6. Firefox 1.5
> successfuly send the file. I just tried to find the problem but
> rfc2388 has lot's of bits&bytes for me. I'm attaching the file.

thanks, but at this point i don't think the file is the problem.

-- 
-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 pjdtech2000 at gmail.com  Fri Apr  7 17:03:21 2006
From: pjdtech2000 at gmail.com (pjd tech)
Date: Fri, 7 Apr 2006 11:03:21 -0600
Subject: [Bese-devel] Re: starting problems (cl-launch)
In-Reply-To: <4f712c6f0604050931l27bcc17bh99b76760957bf3f8@mail.gmail.com>
References: <4f712c6f0604050931l27bcc17bh99b76760957bf3f8@mail.gmail.com>
Message-ID: <4f712c6f0604071003h221070d8xbb2ec7b7f3825715@mail.gmail.com>

I have it working now. But I still had to do a couple of strange things.

- had to copy CL-Launch.sh to cl-launch
- had to copy swank*.lisp files into a cache folder under  ~/.sbcl/cache...

Likely a misconfiguration of /etc/ucw/*  files on my part.
I havnt figure it out yet.

thanks
pj



On 4/5/06, pjd tech <pjdtech2000 at gmail.com> wrote:
>
>  Greetings,
>
> I having problems getting UCW_DEV going. (I had it working a while back
> when everything was in one tar ball). Now I am pulling the development
> versions from Darcs repositories as mentioned in the quickstart guide.
>
>
> Mainly I am not sure how CL-Launch thing is supposed to work. I untarred
> the cl-launch package and added the folder to my local PATH.
> But ucwctl couldnt even start with that.
> I renamed CL-Launch.sh as cl-launch.  Then UCW will mostly load (tail -f
> the dribble file). But finally breaks like this ,
>
> 37: (SB-INT:EVAL-IN-LEXENV
>      (PROGN
>       (SET-DISPATCH-MACRO-CHARACTER #\#
>                                     #\!
>                                     #'(LAMBDA (STREAM CHAR SB-DEBUG:ARG)
>                                         (DECLARE (IGNORE CHAR
> SB-DEBUG:ARG))
>                                         (VALUES (READ-LINE STREAM))))
>       (LOAD "/home/pjdurai/software/lispprogs/cl-launch/cl-launch"
>             :VERBOSE
>             NIL
>             :PRINT
>             NIL)
>       (FUNCALL (INTERN (STRING :RUN) :CL-LAUNCH)
>                :INIT
>                "(load (pop cl-launch:*arguments*))"
>                :QUIT
>                NIL))
>      #<NULL-LEXENV>)
> 38: (SB-IMPL::PROCESS-EVAL-OPTIONS
>      ((SB-EXT:DISABLE-DEBUGGER)
>       "(progn(set-dispatch-macro-character #\\# #\\! #'(lambda(stream char
> arg)(declare(ignore char arg))(values (read-line stream))))(load
> \"/home/pjdurai/software/lispprogs/cl-launch/cl-launch\" :verbose nil :print
> nil)
> (funcall(intern(string :run):cl-launch) :init \"(load (pop
> cl-launch:*arguments*))\" :quit nil))"))
> 39: (SB-IMPL::TOPLEVEL-INIT)
> 40: ((LABELS SB-IMPL::RESTART-LISP))
>
>
> More info:
>
> slackware 10.2, sbcl 0.9.11 binary release, recent versions of pretty much
> every other dependency.
> I dont understand how cl-launch would work. Any help appreciated.
>
> Appreciate your time.
>
> thanks
> pj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060407/31aadb65/attachment.html>

From luca at pca.it  Fri Apr  7 17:38:26 2006
From: luca at pca.it (Luca Capello)
Date: Fri, 07 Apr 2006 19:38:26 +0200
Subject: [Bese-devel] Re: starting problems (cl-launch)
In-Reply-To: <4f712c6f0604071003h221070d8xbb2ec7b7f3825715@mail.gmail.com>
References: <4f712c6f0604050931l27bcc17bh99b76760957bf3f8@mail.gmail.com>
	<4f712c6f0604071003h221070d8xbb2ec7b7f3825715@mail.gmail.com>
Message-ID: <87y7yhuvzh.fsf@gismo.pca.it>

Hello!

On Fri, 07 Apr 2006 19:03:21 +0200, pjd tech wrote:
> I have it working now. But I still had to do a couple of strange
> things.
>
> - had to copy CL-Launch.sh to cl-launch

Sorry, this will be corrected in the next few days...  I based my
patch on the Debian cl-launch package, which has cl-launch instead of
cl-launch.sh.  I'll add a check for the latter, too.

> - had to copy swank*.lisp files into a cache folder under
>   ~/.sbcl/cache...

I explained this problem in the summary of my patch, I think I'll need
to add it to the README or something similar:

=====
- cl-launch (http://www.cliki.net/cl-launch), but there a small
  problem with the SLIME swank when you're not using the
  common-lisp-controller, as reported here:
  
    http://common-lisp.net/pipermail/slime-devel/2006-March/004664.html

  Follow the thread for a possible solution.
=====

BTW, this issue is still unsolved :-(

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/20060407/54124263/attachment.sig>

From aycan.irican at core.gen.tr  Sat Apr  8 15:04:13 2006
From: aycan.irican at core.gen.tr (Aycan iRiCAN)
Date: Sat, 08 Apr 2006 18:04:13 +0300
Subject: [Bese-devel] Parsing UTF-8 mime content
Message-ID: <878xqgqfbm.fsf@core.gen.tr>


Hi,

I had some problems with utf-8 encoded forms because we're using non
ascii characters. I just looked at src/backend/common.lisp and
realized that when a form has been submitted, ucw constructs a
character array and parse the content byte by byte. This is a problem
when we use UTF-8 content. So I changed the array to unsigned-byte and
then added raw bytes. In termination-callback, I converted the array
to a proper string using octets-to-string.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: utf8-mime-content.patch
Type: text/x-patch
Size: 72867 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060408/9be7309d/attachment.bin>
-------------- next part --------------

It's not the perfect solution but it works for me.

Best Regards,

-- 
Aycan iRiCAN
C0R3 Computer Security Group
http://www.core.gen.tr
-------------- 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/20060408/9be7309d/attachment.sig>

From erick at fsl.org.mx  Sat Apr  8 17:15:57 2006
From: erick at fsl.org.mx (Erick Ivaan Lopez Carreon)
Date: Sat, 08 Apr 2006 12:15:57 -0500
Subject: [Bese-devel] knowledge to understand UCW
Message-ID: <1144516558.4045.15.camel@localhost.localdomain>

Hello:

I'm a lisp beginner (aka newbie ;) ), and i really wish to understand
UCW, but i'm a impatient to begin to do practical things, yes i can do
that following the examples that exist round there, but what i really
wanted is to understand well the how's and the why's of the things. Yes
i know i need to follow the study path but i ask to you for suggestions
of topics and sequence of them, to reach the goal of understand UCW in a
way as direct as possible.


Thanks in advance.
-- 
Erick Ivaan Lopez Carreon -- erick at fsl.org.mx   
PGP Key 1024D/9741C03A 2004-11-19 
Key fingerprint = 1764 3C6F B433 B2DD 9029  98B1 8E6B 58D3 9741 C03A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060408/414539ff/attachment.sig>

From mb at bese.it  Sat Apr  8 17:57:02 2006
From: mb at bese.it (Marco Baringer)
Date: Sat, 08 Apr 2006 19:57:02 +0200
Subject: [Bese-devel] Re: Parsing UTF-8 mime content
References: <878xqgqfbm.fsf@core.gen.tr>
Message-ID: <m2d5fsj6hd.fsf@bese.it>

"Aycan iRiCAN" <aycan.irican at core.gen.tr> writes:

> Hi,
>
> I had some problems with utf-8 encoded forms because we're using non
> ascii characters. I just looked at src/backend/common.lisp and
> realized that when a form has been submitted, ucw constructs a
> character array and parse the content byte by byte. This is a problem
> when we use UTF-8 content. So I changed the array to unsigned-byte and
> then added raw bytes. In termination-callback, I converted the array
> to a proper string using octets-to-string.

nice, thanks. i'd like to apply this but i keep getting:

soma:~/lisp/ucw_dev mb$ darcs apply utf8-mime-content.patch 
darcs: bug in get_extra.
Most likely this is caused by a bug that existed in darcs prior
to version 1.0.1.  Details for dealing with this issue can be found
at http://darcs.net/DarcsWiki/Issues1.0.1

can you try applying this to a clean ucw_dev tree and see if it's a
problem with my setup?

> It's not the perfect solution but it works for me.

the only issue i have is with the fixing of the form's encoding in the
parser. supposedly browesers will send data with the same encoding as
the page, but browser's don't always do this, and they even when they
do they don't always do it reliably. i thinks it's the best we can
hope for.

-- 
-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  Sat Apr  8 17:58:23 2006
From: mb at bese.it (Marco Baringer)
Date: Sat, 08 Apr 2006 19:58:23 +0200
Subject: [Bese-devel] Re: knowledge to understand UCW
References: <1144516558.4045.15.camel@localhost.localdomain>
Message-ID: <m28xqgj6f4.fsf@bese.it>

Erick Ivaan Lopez Carreon <erick at fsl.org.mx> writes:

> I'm a lisp beginner (aka newbie ;) ), and i really wish to understand
> UCW, but i'm a impatient to begin to do practical things, yes i can do
> that following the examples that exist round there, but what i really
> wanted is to understand well the how's and the why's of the things. Yes
> i know i need to follow the study path but i ask to you for suggestions
> of topics and sequence of them, to reach the goal of understand UCW in a
> way as direct as possible.

find a web project you're personally interested in and implement it
using ucw, send emails with problems as things come up. i wish i could
be more helpfull but i can't think of a good ucw 'study guide' :(

-- 
-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  Sat Apr  8 19:22:02 2006
From: cjstuij at gmail.com (Ties Stuij)
Date: Sat, 8 Apr 2006 14:22:02 -0500
Subject: [Bese-devel] knowledge to understand UCW
In-Reply-To: <1144516558.4045.15.camel@localhost.localdomain>
References: <1144516558.4045.15.camel@localhost.localdomain>
Message-ID: <d7ce4ebf0604081222n94153ecw38903fef1d5d3a85@mail.gmail.com>

He erick,

i'm just now working on an introduction, which tries to let you
understand how the different components work:

http://www.fallenfrukt.com/ucw-intro.html#mechanics

give me some feedback on what parts of the text didn't work or what
you missed; if you feel like it.

If you're searching for a bit more of a theoretical underpinning,
check this post:

http://www.fallenfrukt.com/blog.php?state=thread&id=21

they're just some pointers, but they might help in some way.
in any case good luck,

Ties


From mbaringer at common-lisp.net  Sun Apr  9 04:05:02 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Sun,  9 Apr 2006 00:05:02 -0400 (EDT)
Subject: [Bese-devel] New patches to fiveam:  8-Apr-2006
Message-ID: <20060409040502.E814913021@common-lisp.net>


Sat Apr  8 06:00:22 EDT 2006  Marco Baringer <mb at bese.it>
  * Adedd gen-one-element

    M ./src/packages.lisp +1
    M ./src/random.lisp +4


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

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


From mbaringer at common-lisp.net  Sun Apr  9 04:30:04 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Sun,  9 Apr 2006 00:30:04 -0400 (EDT)
Subject: [Bese-devel] New patches to ucw_dev:  8-Apr-2006
Message-ID: <20060409043004.2B6E91E005@common-lisp.net>


Sat Apr  8 13:52:19 EDT 2006  Marco Baringer <mb at bese.it>
  * Drop bin/stop.lisp

    R ./bin/stop.lisp

Mon Mar 27 10:14:44 EST 2006  Marco Baringer <mb at bese.it>
  * Make stop.lisp call bye-bye instead of shutdown-server and quit

    A! ./bin/stop.lisp


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

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


From frido at q-software-solutions.de  Sun Apr  9 08:16:51 2006
From: frido at q-software-solutions.de (Friedrich Dominicus)
Date: Sun, 09 Apr 2006 10:16:51 +0200
Subject: [Bese-devel] Hopefully a simple question
In-Reply-To: <20060409040502.E814913021@common-lisp.net> (Marco Baringer's
	message of "Sun, 9 Apr 2006 00:05:02 -0400 (EDT)")
References: <20060409040502.E814913021@common-lisp.net>
Message-ID: <87mzev40zw.fsf@flarge.here>

Can't remember reading about it and am unsure on how to achive it.
Let's say I have a render method 

(defmethod render((some-form form))...

How can I "call out" or break out of this render function to display a
yaml-page?

Regards
Friedrich


From frido at q-software-solutions.de  Sun Apr  9 09:25:39 2006
From: frido at q-software-solutions.de (Friedrich Dominicus)
Date: Sun, 09 Apr 2006 11:25:39 +0200
Subject: [Bese-devel] Hopefully a simple question
In-Reply-To: <87mzev40zw.fsf@flarge.here> (Friedrich Dominicus's message of
	"Sun, 09 Apr 2006 10:16:51 +0200")
References: <20060409040502.E814913021@common-lisp.net>
	<87mzev40zw.fsf@flarge.here>
Message-ID: <878xqf3xt8.fsf@flarge.here>

Sorry I meant a tal part, as was pointed out to me by 
Aycan. If I have such a tal-file which can present som of the
component, how can I call out from the render method to "use this
part"

e.g I have
(defcomponent some-window () 
  ((val-1)
   (val-2)))

val-2 may be a object now I have some tal pages to display it and I
want to call it from my render method from some-window. How would that
be done?


Regards
Friedrich





From luca at pca.it  Mon Apr 10 12:45:25 2006
From: luca at pca.it (Luca Capello)
Date: Mon, 10 Apr 2006 14:45:25 +0200
Subject: [Bese-devel] Re: starting problems (cl-launch)
In-Reply-To: <87y7yhuvzh.fsf@gismo.pca.it>
References: <4f712c6f0604050931l27bcc17bh99b76760957bf3f8@mail.gmail.com>
	<4f712c6f0604071003h221070d8xbb2ec7b7f3825715@mail.gmail.com>
	<87y7yhuvzh.fsf@gismo.pca.it>
Message-ID: <87k69xtx96.fsf@gismo.pca.it>

Hello!

On Fri, 07 Apr 2006 19:38:26 +0200, Luca Capello wrote:
> Hello!
>
> On Fri, 07 Apr 2006 19:03:21 +0200, pjd tech wrote:
>> I have it working now. But I still had to do a couple of strange
>> things.
>>
>> - had to copy CL-Launch.sh to cl-launch
>
> Sorry, this will be corrected in the next few days...  I based my
> patch on the Debian cl-launch package, which has cl-launch instead
> of cl-launch.sh.  I'll add a check for the latter, too.

Done, it's in the repository.

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/20060410/f86f2070/attachment.sig>

From luca at pca.it  Mon Apr 10 14:49:22 2006
From: luca at pca.it (Luca Capello)
Date: Mon, 10 Apr 2006 16:49:22 +0200
Subject: [Bese-devel] `ucw:bye-bye': define quit as key
Message-ID: <87acattril.fsf@gismo.pca.it>

Hello!

ATM, you can control the `ucw:bye-bye' behavior with t|nil, but in
order to understand the behavior, you need to dig into the code.

  (defun bye-bye (&optional (quit t))
    (shutdown-server *default-server*)
    (when quit
      (swank:quit-lisp)))

I'd suggest to define quit as key, instead, also to be consistent with
`ucw:create-server' (where you have for example keys :debug-on-error
or :inspect-components):

Another possible (and clearer) solution will be to change the name of
the variable/key with something like `quit-lisp', which is exactly the
action performed by default: you don't quit UCW, but the lisp ;-)

Objections?

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/20060410/7bfab22d/attachment.sig>

From frido at q-software-solutions.de  Mon Apr 10 16:51:33 2006
From: frido at q-software-solutions.de (Friedrich Dominicus)
Date: Mon, 10 Apr 2006 18:51:33 +0200
Subject: [Bese-devel] I hope I got that right
Message-ID: <874q11qsq2.fsf@flarge.here>

Playing TAL with UCW. 
http://www.cliki.net/ucwTutorialIntroducingTal

Fix as you read along ;-)
Regards
Friedrich


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


Mon Apr 10 11:27:36 EDT 2006  Maciek Pasternacki <maciekp at japhy.fnord.org>
  * Don't map continuation and calling-component in (validp).

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

Mon Apr 10 08:26:28 EDT 2006  Luca Capello <luca at pca.it>
  * bin/ucwctl: check also for cl-launch.sh

    M ./bin/ucwctl -2 +2


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

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


From ralphc at bellsouth.net  Mon Apr 10 17:59:10 2006
From: ralphc at bellsouth.net (Ralph Richard Cook)
Date: Mon, 10 Apr 2006 13:59:10 -0400
Subject: [Bese-devel] Differences between UCW's parenscript and BKNR's
	klammerscript?
Message-ID: <BA14172D-5767-4304-ACF1-E25EFD8C299B@bellsouth.net>

I'm interested in doing some work with parenscript/klammerscript, and  
I was wondering why UCW has their own version of the library. Are  
there bugs that weren't getting fixed, or features that UCW needed?

Thanks,
Richard



From henrik at evahjelte.com  Tue Apr 11 07:26:26 2006
From: henrik at evahjelte.com (henrik hjelte)
Date: Tue, 11 Apr 2006 09:26:26 +0200
Subject: [Bese-devel] Differences between UCW's parenscript and BKNR's
	klammerscript?
In-Reply-To: <BA14172D-5767-4304-ACF1-E25EFD8C299B@bellsouth.net>
References: <BA14172D-5767-4304-ACF1-E25EFD8C299B@bellsouth.net>
Message-ID: <1144740387.9426.15.camel@localhost.localdomain>

Parenscript has got some (minor) new features (described in the manual),
and some bugfixes. There are scripts to generate documentation and a
testframework. The new changes are not tied to ucw at all. Several
people are working with "our" version and I can highly recommend it. 

/Henrik Hjelte

On m?n, 2006-04-10 at 13:59 -0400, Ralph Richard Cook wrote:
> I'm interested in doing some work with parenscript/klammerscript, and  
> I was wondering why UCW has their own version of the library. Are  
> there bugs that weren't getting fixed, or features that UCW needed?
> 
> Thanks,
> Richard
> 
> _______________________________________________
> bese-devel mailing list
> bese-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel
> 
> 



From nathan at acceleration.net  Tue Apr 11 23:40:42 2006
From: nathan at acceleration.net (Nathan Bird)
Date: Tue, 11 Apr 2006 19:40:42 -0400
Subject: [Bese-devel] Loading UCW with ucwctl, cl-launch etc
Message-ID: <014301c65dc1$59462b80$d80a0a0a@acceleration.net>

What? How? Seriously, I'm lost here.

 

I spent a while earlier today trying to get this installed. I got cl-launch,
the custom version of detachtty the works (I thought), no dice :-(.  I'm not
even particularly sure what all I'm missing. For the time being I've just
rolled back to before these patches so that I can continue working. 

 

Here are a few of the things that caused problems for me (and at least one
fellow newbie in #ucw today).

*	There is big benefit to using start.lisp. it runs everywhere (that I
have tried).  This is almost always how I have started UCW. Since I do all
of my work over ssh, leaving a terminal open to it generally isn't a problem
and I also have a window where I can see all the messages easily. I do
appreciate dettachtty for deployment, but unfortunately we have had only a
little opportunity to do that yet. Having this run on windows is a sometime
requirement of the setup we are trying to get going. Depending on debian
packages and such makes that harder for anyone to get it going there.
*	Multiple instances of UCW. Because I work at a windows shop, we are
developing on UCW on a shared linux server. We each have our own instance of
UCW on this server. Installing stuff to /etc doesn't work in this case.
*	Defaulting to locations that don't exist (/etc/ucw/ucwctl.conf).
Defaulting to locations inside UCW is a bit easier (especially on people
getting UCW for the first time and just wanting to see what is going on).
Can we instead default to ucw_dev/bin/etc/* ? 
*	What are the different configuration files? I think I eventually
figured this out, but my first inclination on being told that I hadn't
specified a lisp implementation, was to fill in the variable in
bin/etc/ucwctl.conf, that didn't work, I then tried specifying that file
with the -c option, to no avail. Apparently that wasn't the configuration
file the -config option was expecting. I finally got it to somewhat work by
using just about all of the command line parameters at once, and then hit
some other errors.
*	ANYTHING in the readme? The best docs I could find was reading the
shell script itself (which does have some good comments but I'm not very
good at shell script) and Luca's commit message. I couldn't find anything
specifying what files should be placed where in /etc. There are distributed
comments to this effect, but if we are supposed to be copying and editing a
bunch of stuff an installation guide would be incredibly handy.
*	"ucwctl -help" reports the option as -config-file, whereas the
script appears to actually parse -config

 

 

The biggest take away point I would like to make is that there really needs
to be a TRIVIAL way to start ucw (alright "sbcl -load start.lisp" might not
be trivial, but it is closer), that does not involve copying files to root
owned directories.

 

At least some of this probably comes from my being less familiar with "The
Way Things Work" on Linux and maybe Lisp as well. I'm still fairly new to
both of these communities. I also appreciate where this is going in trying
to make it more platform independent. But by forcing a lot more
configuration up front and assuming very platform specific paths doesn't
quite do that yet.

 

I hope this helps out, please don't take it negatively, I do understand I am
working with bleeding edge beta software here. :-D

 

Nathan Bird

 

* I hold no guarantees to the factual correctness of everything in here, it
was a frustrating day of not understanding why this wasn't working. I'm sure
I was confused on more than one thing.

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

From cjstuij at gmail.com  Wed Apr 12 00:48:48 2006
From: cjstuij at gmail.com (Ties Stuij)
Date: Wed, 12 Apr 2006 02:48:48 +0200
Subject: [Bese-devel] Loading UCW with ucwctl, cl-launch etc
In-Reply-To: <d7ce4ebf0604111748n3de457die0792f5734c5cbd@mail.gmail.com>
References: <014301c65dc1$59462b80$d80a0a0a@acceleration.net>
	<d7ce4ebf0604111748n3de457die0792f5734c5cbd@mail.gmail.com>
Message-ID: <d7ce4ebf0604111748l564ec7a4oef31d643885a5a66@mail.gmail.com>

---------- Forwarded message ----------
From: Ties Stuij <cjstuij at gmail.com>
Date: Apr 12, 2006 2:48 AM
Subject: Re: [Bese-devel] Loading UCW with ucwctl, cl-launch etc
To: Nathan Bird <nathan at acceleration.net>


he nathan,

i also think we need to flatten some bumps.

check my tutorial, i just finished a section on cl-launch ed yesterday:

http://www.fallenfrukt.com/ucw-intro.html#configure

 and also check the cl-launch installation section for the swank
troubles. i'll add it to the documentation section soon.

i also think there's an easy workaround to get start.lisp working
again, if i read the code right. disable the cl-launch check in
src/default.lisp and replace the values of CONFIGFILE and LOGROOT with
something sensible. Look into it. otherwise i will, because however
funky cl-launch is, i also want a lisp way to invoke ucw.


greets, ties


From philip at glyf.org  Wed Apr 12 03:09:38 2006
From: philip at glyf.org (Philip)
Date: Tue, 11 Apr 2006 23:09:38 -0400
Subject: [Bese-devel] Loading UCW with ucwctl, cl-launch etc
In-Reply-To: <014301c65dc1$59462b80$d80a0a0a@acceleration.net>
References: <014301c65dc1$59462b80$d80a0a0a@acceleration.net>
Message-ID: <b9ee0c4d0604112009u42da57d7u71b331df0d874226@mail.gmail.com>

Hello,

Starting ucw server manually is actually easy! The function that does
that is ucw:create-server, but it takes a whole bunch of parameters.
The new starting method first loads those parameters from
src/default.lisp and then overwrites the defaults with values from
config.lisp.

I have attached a start.lisp script, which I use for development, and
which skips all those extra configuration loading steps. The code is
really self-explanatory. The only difference is that admin and
examples are not enabled.

Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: start.lisp
Type: application/octet-stream
Size: 534 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060411/287b57fc/attachment.obj>

From luca at pca.it  Wed Apr 12 07:35:03 2006
From: luca at pca.it (Luca Capello)
Date: Wed, 12 Apr 2006 09:35:03 +0200
Subject: [Bese-devel] Loading UCW with ucwctl, cl-launch etc
In-Reply-To: <014301c65dc1$59462b80$d80a0a0a@acceleration.net>
References: <014301c65dc1$59462b80$d80a0a0a@acceleration.net>
Message-ID: <878xqb457c.fsf@gismo.pca.it>

Hello!

On Wed, 12 Apr 2006 01:40:42 +0200, Nathan Bird wrote:
> What? How? Seriously, I'm lost here.

And I'm here to save you :-D

> I spent a while earlier today trying to get this installed. I got
> cl-launch, the custom version of detachtty the works (I thought), no
> dice :-(.

Output?  Log?  Lisp implementation?  Without any more details I cannot
improve the ucwctl system :-(

BTW, I tested my patch on 3 different machines: a Debian one (with
c-l-c and all the packets present in Debian, like cl-arnesi and so
on) and on two others Debian-based (but with no c-l-c and all the
software manually installed, different SBCL versions).

> I'm not even particularly sure what all I'm missing. For the time
> being I've just rolled back to before these patches so that I can
> continue working.

Yes, this was Marco's advice before finding a solution.

> Here are a few of the things that caused problems for me (and at
> least one fellow newbie in #ucw today).
                             ^^^^
Usually, I'm most of the time there, but to be sure to reach me send a
private message ;-)

> *	There is big benefit to using start.lisp.

I see...

> Depending on debian packages and such makes that harder for anyone
> to get it going there.

I'd like to note that my patch doesn't depend on any Debian package.
The problem about cl-launch vs cl-launch.sh was a very stupid one.
The SLIME problem with cl-launch has nothing to do with Debian, in
fact the Debian cl-swank package adopted a different workaround.

> *	Multiple instances of UCW. Because I work at a windows shop,
> we are developing on UCW on a shared linux server. We each have our
> own instance of UCW on this server. Installing stuff to /etc doesn't
> work in this case.

Nothing needs to be installed, as for the ucwctl command line
arguments...  But I agree that having multiple shell scripts just to
start multiple ucwctl instances with different parameters is not the
best thing.

> *	Defaulting to locations that don't exist (/etc/ucw/ucwctl.conf).
> Defaulting to locations inside UCW is a bit easier (especially on people
> getting UCW for the first time and just wanting to see what is going on).
> Can we instead default to ucw_dev/bin/etc/* ? 

I should say that the other idea was to implement something like a
`make install` command...

I'm against defaulting to ucw_dev/bin/etc/*, but if this is the common
decision, I'll agree on that.

BTW, as Marco suggested on private conversation, ucw_dev/bin/etc
should be probably moved to ucw_dev/etc.

> *	What are the different configuration files?
[...]
> *	ANYTHING in the readme?

Maybe I didn't sponsor it, but there a manual page for ucwctl:

  $ cd /path/to/ucw_dev
  $ cd bin
  $ man ./ucwctl.1

The README should absolutely be updated, I know, but free time is
always a problem here.

> There are distributed comments to this effect, but if we are
> supposed to be copying and editing a bunch of stuff an installation
> guide would be incredibly handy.

This could be in the README or, better, in a INSTALL file, agreed.

> *	"ucwctl -help" reports the option as -config-file, whereas the
> script appears to actually parse -config

Sorry, really a stupid mistake already corrected.

> I hope this helps out, please don't take it negatively, I do
> understand I am working with bleeding edge beta software here. :-D

No problem, I was quite impressed that no one complains before ;-)

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/20060412/e3ffdf73/attachment.sig>

From luca at pca.it  Wed Apr 12 07:46:01 2006
From: luca at pca.it (Luca Capello)
Date: Wed, 12 Apr 2006 09:46:01 +0200
Subject: [Bese-devel] Loading UCW with ucwctl, cl-launch etc
In-Reply-To: <b9ee0c4d0604112009u42da57d7u71b331df0d874226@mail.gmail.com>
References: <014301c65dc1$59462b80$d80a0a0a@acceleration.net>
	<b9ee0c4d0604112009u42da57d7u71b331df0d874226@mail.gmail.com>
Message-ID: <871ww344p2.fsf@gismo.pca.it>

Hello!

On Wed, 12 Apr 2006 05:09:38 +0200, Philip wrote:
> The new starting method first loads those parameters from
> src/default.lisp and then overwrites the defaults with values from
> config.lisp.

Exactly, with minor corrections: the new method loads up the
`:ucw.default' system, which defines the default parameters, loads up
the `:ucw.config' system and finally load the `*ucw-config-file*' (if this is
non-nil, it's value is obtained with `cl-launch:getenv').

The `:ucw.config' system takes care of loading the application systems
and preparing the variable for `ucw:create-server'.  This is the
reason why it's loaded even when `*ucw-config-file*' is nil.

During the patch gestation (which lasted for about 1 month), my first
approach was to add all the necessary code into start.lisp, but then I
opted for a more general solution because it's more scalable and
easier to improve in the future.

> I have attached a start.lisp script, which I use for development,
> and which skips all those extra configuration loading steps.

FWIW, I'm preparing the arnesi patch I proposed at [1]: this
completely removes the cl-launch dependency when manually loading
start.lisp, thus letting the following possible:

  $ CONFIGFILE=filename LOGROOT=directory sbcl --load start.lisp

Thx, bye,
Gismo / Luca

[1] http://common-lisp.net/pipermail/bese-devel/2006-April/001860.html
-------------- 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/20060412/bb76d8de/attachment.sig>

From mb at bese.it  Wed Apr 12 10:53:37 2006
From: mb at bese.it (Marco Baringer)
Date: Wed, 12 Apr 2006 12:53:37 +0200
Subject: [Bese-devel] Re: Hopefully a simple question
References: <20060409040502.E814913021@common-lisp.net>
	<87mzev40zw.fsf@flarge.here> <878xqf3xt8.fsf@flarge.here>
Message-ID: <m2ek03njym.fsf@bese.it>

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

> Sorry I meant a tal part, as was pointed out to me by 
> Aycan. If I have such a tal-file which can present som of the
> component, how can I call out from the render method to "use this
> part"
>
> e.g I have
> (defcomponent some-window () 
>   ((val-1)
>    (val-2)))
>
> val-2 may be a object now I have some tal pages to display it and I
> want to call it from my render method from some-window. How would that
> be done?

if val-2 is a template-component then render is sufficenet, if you
don't have a template component but just want to render some randow
tal page then you'll need to use ucw:render-template:

(defmethod render ((a component))
  ....
  (render-template ucw:*context* "path/to/template.tal"
                   (yaclml:tal-env 'component a 
                                   'other-stuff ...))
  ....)

does this anwser your question?

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



From mb at bese.it  Wed Apr 12 10:54:22 2006
From: mb at bese.it (Marco Baringer)
Date: Wed, 12 Apr 2006 12:54:22 +0200
Subject: [Bese-devel] Re: `ucw:bye-bye': define quit as key
References: <87acattril.fsf@gismo.pca.it>
Message-ID: <m2acarnjxd.fsf@bese.it>

Luca Capello <luca at pca.it> writes:

> Objections?

none at all, good idea. can you do it or do want me 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 mb at bese.it  Wed Apr 12 10:56:32 2006
From: mb at bese.it (Marco Baringer)
Date: Wed, 12 Apr 2006 12:56:32 +0200
Subject: [Bese-devel] Re: Differences between UCW's parenscript and BKNR's
	klammerscript?
References: <BA14172D-5767-4304-ACF1-E25EFD8C299B@bellsouth.net>
Message-ID: <m264lfnjtr.fsf@bese.it>

Ralph Richard Cook <ralphc at bellsouth.net> writes:

> I'm interested in doing some work with parenscript/klammerscript, and
> I was wondering why UCW has their own version of the library. Are
> there bugs that weren't getting fixed, or features that UCW needed?

at the time i had sent manuel (klammerscript author) some patches, he
said that he was no longer maintaining klammerscript so i just
forked. if manuel is still not maintainng klammerscript then the
difference between the two is that parenscript is being maintained and
klammerscript isn't. however i seem to recal that someone has picked
up klammerscript and started maintaing it again (though i'm not sure
where i heard) if this is true we should look into merging the two
together.

-- 
-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 luca at pca.it  Wed Apr 12 12:11:25 2006
From: luca at pca.it (Luca Capello)
Date: Wed, 12 Apr 2006 14:11:25 +0200
Subject: [Bese-devel] Re: `ucw:bye-bye': define quit as key
In-Reply-To: <m2acarnjxd.fsf@bese.it>
References: <87acattril.fsf@gismo.pca.it> <m2acarnjxd.fsf@bese.it>
Message-ID: <87mzer2dua.fsf@gismo.pca.it>

Hello!

On Wed, 12 Apr 2006 12:54:22 +0200, Marco Baringer wrote:
> none at all, good idea. can you do it or do want me to do it?

Done, it's in the repo.

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/20060412/fc80ef05/attachment.sig>

From luca at pca.it  Wed Apr 12 14:50:16 2006
From: luca at pca.it (Luca Capello)
Date: Wed, 12 Apr 2006 16:50:16 +0200
Subject: [Bese-devel] Re: New patches to ucw_dev: 30-Mar-2006
References: <20060331053003.CBC1B704B@common-lisp.net>
	<m2odzmtwdw.fsf@bese.it> <87r74h9sb7.fsf@gismo.pca.it>
Message-ID: <874q0y3l1z.fsf@gismo.pca.it>

Hello!

On Sat, 01 Apr 2006 18:25:16 +0200, Luca Capello wrote:
> OTOH, the cl-launch dependency is mandatory for the `:ucw.default'
> system because the `*ucw-config-file*' and
> `*ucw-log-root-directory*' variables are defined through the
> `cl-launch:getenv' function ($CONFIGFILE and $LOGROOT,
> respectively).
>
> The simplest (and preferable) solution would be to implement
> `arnesi:getenv', thus letting UCW be loadable through the start.lisp
> file only, something like:
>
>   $ CONFIGFILE=filename LOGROOT=directory sbcl --load start.lisp

The solution is in the arnesi_dev repo.

I tried the above command on two different SBCL versions and it works
like a charm, assuming that $LOGROOT is a directory ;-)

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/20060412/0aa0400d/attachment.sig>

From luca at pca.it  Wed Apr 12 15:34:58 2006
From: luca at pca.it (Luca Capello)
Date: Wed, 12 Apr 2006 17:34:58 +0200
Subject: [Bese-devel] Re: Loading UCW with ucwctl, cl-launch etc
References: <014301c65dc1$59462b80$d80a0a0a@acceleration.net>
	<b9ee0c4d0604112009u42da57d7u71b331df0d874226@mail.gmail.com>
	<871ww344p2.fsf@gismo.pca.it>
Message-ID: <87mzeq24f1.fsf@gismo.pca.it>

Hello!

On Wed, 12 Apr 2006 09:46:01 +0200, Luca Capello wrote:
>> I have attached a start.lisp script, which I use for development,
>> and which skips all those extra configuration loading steps.
>
> FWIW, I'm preparing the arnesi patch I proposed at [1]: this
> completely removes the cl-launch dependency when manually loading
> start.lisp, thus letting the following possible:
>
>   $ CONFIGFILE=filename LOGROOT=directory sbcl --load start.lisp

I completely forgot to mention that you can still specify any variable
you want in start.lisp.  As they are defined with `defvar' in
src/default.lisp, if you set them with `setf' in you start.lisp BEFORE
loading `:ucw.default', they still have the value you've specified
(not the one in src/default.lisp).

Actually, I just found a possible error in src/default.lisp: the last
action is to load the `*ucw-config-file*' if present via
`load-config-file'.  The latter calls `load-applications', to prepare
the necessary variables (`*ucw-applications*' and `*ucw-systems*')
reading the ASDF files present in `*ucw-applications-directory*'.  So,
if `*ucw-config-file*' is empty, `load-applications' is not called.

I think the best solution will be the following in src/default.lisp:

  (if *ucw-config-file*
    (load-config-file)
    (load-applications))

Comments?

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/20060412/d6bd78d5/attachment.sig>

From dpatru at gmail.com  Wed Apr 12 11:43:25 2006
From: dpatru at gmail.com (Daniel Patru)
Date: Wed, 12 Apr 2006 07:43:25 -0400
Subject: [Bese-devel] problem with detachtty
Message-ID: <483983b30604120443u64f41f16k55dd13ef095b9b47@mail.gmail.com>

UCW doesn't start on my machine when used with detachtty. However it starts
without it. In ucwctl, the start option says:

 start)
        install -d -m 755 $LOGROOT $RUNROOT
        $DETACHTTY --dribble-file $LOGROOT/ucw.dribble \
            --log-file $LOGROOT/ucw.detachtty \
            --pid-file $RUNROOT/ucw.pid \
            $RUNROOT/ucw.socket \
            $CLLAUNCH -X $OPT_LISP $OPT_PATH NO_QUIT=yes -- "$STARTFILE"
        ;;

Running "ucwctl start && ucwctl attach" results in an error.

If I change ucwctl to:

 start)
        install -d -m 755 $LOGROOT $RUNROOT
        $CLLAUNCH -X $OPT_LISP $OPT_PATH NO_QUIT=yes -- "$STARTFILE"
        ;;

"ucwctl start" runs fine, albeit dumps all the output to the terminal and
not to logfiles.

This seems to indicate that there's a problem with detachtty. It may be that
I just don't have the right version of detachtty. I have a debian clc
system. I installed the version from
http://uncommon-web.com/repos/detachttyusing "make; make install",
since "make deb" gave an error. Is there a
debian specific way to install detachtty?  I also removed the old versions
of detachtty and attachtty from the path, so that the new patched versions
are used.

I attached the output of "ucwctl start && ucwctl attach". The relevant part
seems to indicate that swank can't output to *current-error-output*
(synonymous with *current-debug-io* and *current-terminal-io*):

  Error during processing of --eval option
"(progn(set-dispatch-macro-character
#\\# #\\! #'(lambda(stream char arg)(declare(ignore char arg))(values
(read-line stream))))(load \"/usr/bin/cl-launch\" :verbose nil :print nil)
(funcall(intern(string :run):cl-launch) :init \"(load (pop
cl-launch:*arguments*))\" :quit nil))":

  couldn't write to #<SB-SYS:FD-STREAM for "the terminal" {A7F2801}>:
    Bad file descriptor

0: (SB-DEBUG:BACKTRACE
    128
    #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT-ERROR-OUTPUT* {A8412A1}>)
1: (SB-DEBUG::DEBUGGER-DISABLED-HOOK
    #<SIMPLE-ERROR {C3ABCF9}>
    #<unavailable argument>)
2: (INVOKE-DEBUGGER #<SIMPLE-ERROR {C3ABCF9}>)
3: (ERROR
    "Error during processing of --eval ~
                                    option ~S:~%~%  ~A")
4: ((LAMBDA (SB-IMPL::E)) #<SB-INT:SIMPLE-STREAM-ERROR {C3ABA71}>)
5: ((LAMBDA (SB-IMPL::E)) #<SB-INT:SIMPLE-STREAM-ERROR {C3ABA71}>)
6: (SIGNAL #<SB-INT:SIMPLE-STREAM-ERROR {C3ABA71}>)
7: (ERROR SB-INT:SIMPLE-STREAM-ERROR)
8: (SB-IMPL::SIMPLE-STREAM-PERROR
    "couldn't write to ~S"
    #<SB-SYS:FD-STREAM for "the terminal" {A7F2801}>
    9)
9: (SB-IMPL::FLUSH-OUTPUT-BUFFER
    #<SB-SYS:FD-STREAM for "the terminal" {A7F2801}>)
10: (SB-IMPL::OUTPUT-CHAR-LATIN-1-LINE-BUFFERED
     #<SB-SYS:FD-STREAM for "the terminal" {A7F2801}>
     #\Newline)
11: (WRITE-CHAR #\Newline #<SB-SYS:FD-STREAM for "the terminal" {A7F2801}>)
12: (WRITE-CHAR #\Newline #<SYNONYM-STREAM :SYMBOL SB-SYS:*TTY* {91110C9}>)
13: (WRITE-CHAR
     #\Newline
     #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT-TERMINAL-IO* {A8412F9}>)
14: (WRITE-CHAR #\Newline #<SYNONYM-STREAM :SYMBOL *TERMINAL-IO* {915F2A1}>)
15: (TERPRI #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT-DEBUG-IO* {A8413A1}>)
16: (SB-FORMAT::PERCENT_SIGN-FORMAT-DIRECTIVE-INTERPRETER
     #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT-DEBUG-IO* {A8413A1}>
     #<~%>
     NIL
     #<unavailable argument>
     NIL)
17: (SB-FORMAT::INTERPRET-DIRECTIVE-LIST
     #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT-DEBUG-IO* {A8413A1}>
     (#<~%>)
     (4005)
     NIL)
18: (SB-FORMAT::%FORMAT
     #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT-DEBUG-IO* {A8413A1}>
     "~&;; Swank started at port: ~D.~%"
     (4005)
     (4005))
19: (FORMAT
     #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT-DEBUG-IO* {A8413A1}>
     "~&;; Swank started at port: ~D.~%")
20: (SWANK::SIMPLE-ANNOUNCE-FUNCTION 4005)
21: (SWANK::SETUP-SERVER
     4005
     #<FUNCTION SWANK::SIMPLE-ANNOUNCE-FUNCTION>
     :SPAWN
     T
     :UTF-8-UNIX)
22: (SB-INT:EVAL-IN-LEXENV (START-SWANK *UCW-SWANK-PORT*) #<NULL-LEXENV>)
23: (SB-FASL::LOAD-AS-SOURCE
     #<SB-SYS:FD-STREAM for "file /etc/ucw/start.lisp" {AFCFAE1}>
     NIL
     NIL)


Any help would be greatly appreciated. Thanks,
Daniel

--
"Work and play are used to describe the same thing under differing
circumstance."
  - Mark Twain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060412/c66d85b1/attachment.html>
-------------- next part --------------
; loading system definition from /usr/share/common-lisp/systems/arnesi.asd into
; #<PACKAGE "ASDF0">
; registering #<SYSTEM :ARNESI {B17F3E9}> as ARNESI
; registering #<SYSTEM :ARNESI.TEST {B2F5881}> as ARNESI.TEST
; registering #<SYSTEM :ARNESI.CL-PPCRE-EXTRAS {A858381}> 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
; loading system definition from /usr/share/common-lisp/systems/ucw.asd into
; #<PACKAGE "ASDF0">
; registering #<SYSTEM :UCW {B1527F1}> as UCW
; registering #<SYSTEM :UCW.CONFIG {B2E3271}> as UCW.CONFIG
; registering #<SYSTEM :UCW.DEFAULT {B44F949}> as UCW.DEFAULT
; registering #<SYSTEM :UCW.ADMIN {B5B9579}> as UCW.ADMIN
; registering #<SYSTEM :UCW.EXAMPLES {A9080B1}> as UCW.EXAMPLES
; registering #<SYSTEM :UCW.HTTPD {AC355D1}> as UCW.HTTPD
; registering #<SYSTEM :UCW.MOD-LISP {AD9DBF9}> as UCW.MOD-LISP
; registering #<SYSTEM :UCW.ASERVE {AEFF621}> as UCW.ASERVE
; registering #<SYSTEM :UCW.ARANEIDA {B079CE1}> as UCW.ARANEIDA
; registering #<SYSTEM :UCW.CL-ICU {B1DA5E1}> as UCW.CL-ICU
; registering #<SYSTEM :UCW.EXAMPLES.I18N {B356C51}> as UCW.EXAMPLES.I18N
; loading system definition from /usr/lib/sbcl/site-systems/rfc2109.asd into
; #<PACKAGE "ASDF0">
; registering #<SYSTEM "rfc2109" {B647FF1}> as rfc2109
; loading system definition from /usr/lib/sbcl/site-systems/split-sequence.asd
; into #<PACKAGE "ASDF0">
; registering #<SYSTEM :SPLIT-SEQUENCE {AB71529}> as SPLIT-SEQUENCE
; loading system definition from /usr/lib/sbcl/site-systems/trivial-sockets.asd
; into #<PACKAGE "ASDF0">
; registering #<SYSTEM TRIVIAL-SOCKETS {AD0AF69}> as TRIVIAL-SOCKETS
; loading system definition from /usr/share/common-lisp/systems/cl-ppcre.asd
; into #<PACKAGE "ASDF0">
; registering #<SYSTEM #:CL-PPCRE {AEA8AC1}> as CL-PPCRE
; loading system definition from /usr/share/common-lisp/systems/parenscript.asd
; into #<PACKAGE "ASDF0">
; registering #<SYSTEM :PARENSCRIPT {B093851}> as PARENSCRIPT
; registering #<SYSTEM :PARENSCRIPT.TEST {B33EEA9}> as PARENSCRIPT.TEST
; loading system definition from /usr/share/common-lisp/systems/iterate.asd
; into #<PACKAGE "ASDF0">
; registering #<SYSTEM ITERATE {B4F27F1}> as ITERATE
; registering #<SYSTEM ITERATE-PG {B675609}> as ITERATE-PG
; registering #<SYSTEM ITERATE-TESTS {AB66169}> as ITERATE-TESTS
; loading system definition from /usr/share/common-lisp/systems/swank.asd into
; #<PACKAGE "ASDF0">
; registering #<SYSTEM :SWANK {B055F69}> as SWANK
; loading system definition from /usr/share/common-lisp/systems/yaclml.asd into
; #<PACKAGE "ASDF0">
; registering #<SYSTEM :YACLML {B1FA821}> as YACLML
; registering #<SYSTEM :YACLML.TEST {B38F531}> as YACLML.TEST
STYLE-WARNING: redefining PREFERRED-COMMUNICATION-STYLE NIL in DEFMETHOD
STYLE-WARNING: redefining CALL-WITHOUT-INTERRUPTS (T) in DEFMETHOD
STYLE-WARNING: redefining LISP-IMPLEMENTATION-TYPE-NAME NIL in DEFMETHOD
STYLE-WARNING: redefining CALL-WITH-SYNTAX-HOOKS (T) in DEFMETHOD
STYLE-WARNING: redefining DEFAULT-READTABLE-ALIST NIL in DEFMETHOD
STYLE-WARNING: redefining ARGLIST (T) in DEFMETHOD
STYLE-WARNING: redefining INSTALL-DEBUGGER-GLOBALLY (T) in DEFMETHOD
STYLE-WARNING: redefining CALL-WITH-DEBUGGER-HOOK (T T) in DEFMETHOD
STYLE-WARNING: redefining FORMAT-SLDB-CONDITION (T) in DEFMETHOD
STYLE-WARNING: redefining CONDITION-REFERENCES (T) in DEFMETHOD
STYLE-WARNING: redefining UNPROFILE-ALL NIL in DEFMETHOD
STYLE-WARNING: implicitly creating new generic function STARTUP-MULTIPROCESSING
WARNING: DEFIMPLEMENTATION of undefined interface (STARTUP-MULTIPROCESSING)
STYLE-WARNING: redefining THREAD-NAME (T) in DEFMETHOD
STYLE-WARNING: redefining THREAD-STATUS (T) in DEFMETHOD
STYLE-WARNING: redefining MAKE-LOCK NIL in DEFMETHOD
STYLE-WARNING: redefining CALL-WITH-LOCK-HELD (T T) in DEFMETHOD
STYLE-WARNING: redefining MAKE-RECURSIVE-LOCK NIL in DEFMETHOD
STYLE-WARNING: redefining CALL-WITH-RECURSIVE-LOCK-HELD (T T) in DEFMETHOD
STYLE-WARNING: redefining CURRENT-THREAD NIL in DEFMETHOD
STYLE-WARNING: redefining KILL-THREAD (T) in DEFMETHOD
STYLE-WARNING: redefining THREAD-ALIVE-P (T) in DEFMETHOD
STYLE-WARNING: redefining MAKE-STREAM-INTERACTIVE (T) in DEFMETHOD
STYLE-WARNING: redefining BUFFER-FIRST-CHANGE (T) in DEFMETHOD
STYLE-WARNING:
   implicitly creating new generic function STREAM-READ-CHAR-WILL-HANG-P
STYLE-WARNING:
   implicitly creating new generic function INSPECT-BIGGER-PIECE-ACTIONS
STYLE-WARNING:
   implicitly creating new generic function INSPECT-WHOLE-THING-ACTION
STYLE-WARNING: implicitly creating new generic function INSPECT-SHOW-MORE-ACTION
STYLE-WARNING:
   implicitly creating new generic function MENU-CHOICES-FOR-PRESENTATION
STYLE-WARNING: new FTYPE proclamation
#<SB-KERNEL:FUN-TYPE (FUNCTION (T) (VALUES SIMPLE-STRING &REST T))>
for STR does not match old FTYPE proclamation
#<SB-KERNEL:FUN-TYPE (FUNCTION (T) *)>
STYLE-WARNING: implicitly creating new generic function END-STRING
STYLE-WARNING:
   implicitly creating new generic function CREATE-GREEDY-CONSTANT-LENGTH-MATCHER
STYLE-WARNING:
   implicitly creating new generic function CREATE-GREEDY-NO-ZERO-MATCHER
STYLE-WARNING: implicitly creating new generic function CREATE-GREEDY-MATCHER
STYLE-WARNING:
   implicitly creating new generic function CREATE-NON-GREEDY-CONSTANT-LENGTH-MATCHER
STYLE-WARNING:
   implicitly creating new generic function CREATE-NON-GREEDY-NO-ZERO-MATCHER
STYLE-WARNING:
   implicitly creating new generic function CREATE-NON-GREEDY-MATCHER
STYLE-WARNING:
   implicitly creating new generic function CREATE-CONSTANT-REPETITION-CONSTANT-LENGTH-MATCHER
STYLE-WARNING:
   implicitly creating new generic function CREATE-CONSTANT-REPETITION-MATCHER
STYLE-WARNING:
   implicitly creating new generic function BUILD-REPLACEMENT-TEMPLATE
STYLE-WARNING: implicitly creating new generic function (SETF DEBUG-ON-ERROR)
STYLE-WARNING: redefining DEBUG-ON-ERROR (STANDARD-APPLICATION) in DEFMETHOD
STYLE-WARNING:
   implicitly creating new generic function HANDLE-ACTION-ERROR-USING-APPLICATION
STYLE-WARNING: implicitly creating new generic function RESTART-APPLICATION
STYLE-WARNING: implicitly creating new generic function PLACE
STYLE-WARNING: implicitly creating new generic function (SETF PLACE)
STYLE-WARNING: implicitly creating new generic function CLONE-PLACE-VALUE
STYLE-WARNING: implicitly creating new generic function SAVE-BACKTRACKED
STYLE-WARNING: implicitly creating new generic function REINSTATE-BACKTRACKED
STYLE-WARNING: implicitly creating new generic function BACKTRACK
STYLE-WARNING: implicitly creating new generic function BACKTRACK-SLOT
STYLE-WARNING: redefining HANDLE-ACTION-ERROR-USING-APPLICATION in DEFGENERIC
STYLE-WARNING: implicitly creating new generic function RUN-ISOLATED
STYLE-WARNING: redefining CALL-COMPONENT in DEFGENERIC
STYLE-WARNING: redefining CALL-COMPONENT in DEFGENERIC
STYLE-WARNING: implicitly creating new generic function ANSWER-COMPONENT*
STYLE-WARNING: implicitly creating new generic function JUMP-TO-COMPONENT
STYLE-WARNING: redefining REFRESH-COMPONENT in DEFGENERIC
STYLE-WARNING: redefining OK in DEFGENERIC
STYLE-WARNING: implicitly creating new generic function ACTION-REQUEST-P
STYLE-WARNING: implicitly creating new generic function RESTART-SERVER
STYLE-WARNING: implicitly creating new generic function REGISTER-APPLICATION
STYLE-WARNING: implicitly creating new generic function UNREGISTER-APPLICATION
STYLE-WARNING: implicitly creating new generic function MAKE-NEW-ACTION
STYLE-WARNING:
   implicitly creating new generic function MAKE-NEW-CALLBACK-USING-CLASS
STYLE-WARNING: implicitly creating new generic function FIND-FRAME-BY-ID
STYLE-WARNING: implicitly creating new generic function RENDER-TEMPLATE
STYLE-WARNING: implicitly creating new generic function PREPROCESS-TEMPLATE
STYLE-WARNING: redefining APPLICATION-AUTHENTICATE-USER in DEFGENERIC
STYLE-WARNING: redefining APPLICATION-AUTHENTICATE-USER in DEFGENERIC
STYLE-WARNING: redefining APPLICATION-AUTHORIZE-SESSION in DEFGENERIC
STYLE-WARNING: redefining APPLICATION-AUTHORIZE-SESSION in DEFGENERIC
STYLE-WARNING: redefining CALL-COMPONENT in DEFGENERIC
; in: LAMBDA (#:G1979)
;     #'(LAMBDA
;         (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0.
;          SB-PCL::.ARG1.)
;       (DECLARE (IGNORE SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL.))
;       (ERROR 'SB-PCL::LONG-METHOD-COMBINATION-ERROR
;              :FORMAT-CONTROL
;              #:G1979
;              :FORMAT-ARGUMENTS
;              (LIST 'IT.BESE.ARNESI::PRIMARY)))
; 
; caught STYLE-WARNING:
;   The variable SB-PCL::.ARG0. is defined but never used.
; 
; caught STYLE-WARNING:
;   The variable SB-PCL::.ARG1. is defined but never used.
STYLE-WARNING:
   redefining WINDOW-COMPONENT.CONTENT-TYPE (WINDOW-COMPONENT) in DEFMETHOD
STYLE-WARNING: implicitly creating new generic function SHOW-STATUS-BAR
STYLE-WARNING: implicitly creating new generic function IN-FIELD-ON-FOCUS
STYLE-WARNING: implicitly creating new generic function IN-FIELD-SETUP
STYLE-WARNING: implicitly creating new generic function VALIDATE
STYLE-WARNING: implicitly creating new generic function JAVASCRIPT-CHECK
STYLE-WARNING: implicitly creating new generic function DATE-YMD
STYLE-WARNING: redefining VALIDATE in DEFGENERIC
STYLE-WARNING: redefining JAVASCRIPT-CHECK in DEFGENERIC
STYLE-WARNING: implicitly creating new generic function REPORT-ERROR
STYLE-WARNING: implicitly creating new generic function CHECK-CREDENTIALS
STYLE-WARNING: implicitly creating new generic function FIND-COMPONENT
STYLE-WARNING: implicitly creating new generic function (SETF FIND-COMPONENT)
STYLE-WARNING: implicitly creating new generic function ADD-COMPONENT
STYLE-WARNING: implicitly creating new generic function COMPONENT-AT
STYLE-WARNING: implicitly creating new generic function (SETF COMPONENT-AT)
STYLE-WARNING:
   implicitly creating new generic function CONTAINER.CURRENT-COMPONENT
STYLE-WARNING:
   implicitly creating new generic function ENSURE-VALID-COMPONENT-LABEL
STYLE-WARNING: implicitly creating new generic function MAP-CONTENTS
STYLE-WARNING: redefining CHECK-CREDENTIALS in DEFGENERIC
STYLE-WARNING:
   implicitly creating new generic function RANGE-VIEW.CURRENT-WINDOW
STYLE-WARNING:
   implicitly creating new generic function RANGE-VIEW.CURRENT-WINDOW-ITEMS
STYLE-WARNING:
   implicitly creating new generic function RANGE-VIEW.HAVE-PREVIOUS-P
STYLE-WARNING: implicitly creating new generic function RANGE-VIEW.HAVE-NEXT-P
STYLE-WARNING: implicitly creating new generic function PROCESS-ACCEPT-LANGUAGE
; 
; compilation unit finished
;   caught 2 STYLE-WARNING conditions
; loading system definition from /usr/share/common-lisp/systems/cl-fad.asd into
; #<PACKAGE "ASDF0">
; registering #<SYSTEM #:CL-FAD {BB881E1}> as CL-FAD
; registering #<SYSTEM #:CL-FAD-TESTS {BD20B51}> as CL-FAD-TESTS
STYLE-WARNING: redefining LOGIN-SUCCESSFUL in DEFGENERIC
STYLE-WARNING: redefining SUBMIT in DEFGENERIC
STYLE-WARNING: implicitly creating new generic function SAFE-PRINT-REPL-VALUE
STYLE-WARNING: redefining START in DEFGENERIC
STYLE-WARNING: redefining REFRESH-COMPONENT in DEFGENERIC
STYLE-WARNING: redefining OK in DEFGENERIC
STYLE-WARNING: redefining START in DEFGENERIC
unhandled SIMPLE-ERROR in thread #<SB-THREAD:THREAD "initial thread" {A7F2461}>:
  Error during processing of --eval option "(progn(set-dispatch-macro-character #\\# #\\! #'(lambda(stream char arg)(declare(ignore char arg))(values (read-line stream))))(load \"/usr/bin/cl-launch\" :verbose nil :print nil)
(funcall(intern(string :run):cl-launch) :init \"(load (pop cl-launch:*arguments*))\" :quit nil))":

  couldn't write to #<SB-SYS:FD-STREAM for "the terminal" {A7F2801}>:
    Bad file descriptor

0: (SB-DEBUG:BACKTRACE
    128
    #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT-ERROR-OUTPUT* {A8412A1}>)
1: (SB-DEBUG::DEBUGGER-DISABLED-HOOK
    #<SIMPLE-ERROR {C3ABCF9}>
    #<unavailable argument>)
2: (INVOKE-DEBUGGER #<SIMPLE-ERROR {C3ABCF9}>)
3: (ERROR
    "Error during processing of --eval ~
                                    option ~S:~%~%  ~A")
4: ((LAMBDA (SB-IMPL::E)) #<SB-INT:SIMPLE-STREAM-ERROR {C3ABA71}>)
5: ((LAMBDA (SB-IMPL::E)) #<SB-INT:SIMPLE-STREAM-ERROR {C3ABA71}>)
6: (SIGNAL #<SB-INT:SIMPLE-STREAM-ERROR {C3ABA71}>)
7: (ERROR SB-INT:SIMPLE-STREAM-ERROR)
8: (SB-IMPL::SIMPLE-STREAM-PERROR
    "couldn't write to ~S"
    #<SB-SYS:FD-STREAM for "the terminal" {A7F2801}>
    9)
9: (SB-IMPL::FLUSH-OUTPUT-BUFFER
    #<SB-SYS:FD-STREAM for "the terminal" {A7F2801}>)
10: (SB-IMPL::OUTPUT-CHAR-LATIN-1-LINE-BUFFERED
     #<SB-SYS:FD-STREAM for "the terminal" {A7F2801}>
     #\Newline)
11: (WRITE-CHAR #\Newline #<SB-SYS:FD-STREAM for "the terminal" {A7F2801}>)
12: (WRITE-CHAR #\Newline #<SYNONYM-STREAM :SYMBOL SB-SYS:*TTY* {91110C9}>)
13: (WRITE-CHAR
     #\Newline
     #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT-TERMINAL-IO* {A8412F9}>)
14: (WRITE-CHAR #\Newline #<SYNONYM-STREAM :SYMBOL *TERMINAL-IO* {915F2A1}>)
15: (TERPRI #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT-DEBUG-IO* {A8413A1}>)
16: (SB-FORMAT::PERCENT_SIGN-FORMAT-DIRECTIVE-INTERPRETER
     #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT-DEBUG-IO* {A8413A1}>
     #<~%>
     NIL
     #<unavailable argument>
     NIL)
17: (SB-FORMAT::INTERPRET-DIRECTIVE-LIST
     #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT-DEBUG-IO* {A8413A1}>
     (#<~%>)
     (4005)
     NIL)
18: (SB-FORMAT::%FORMAT
     #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT-DEBUG-IO* {A8413A1}>
     "~&;; Swank started at port: ~D.~%"
     (4005)
     (4005))
19: (FORMAT
     #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT-DEBUG-IO* {A8413A1}>
     "~&;; Swank started at port: ~D.~%")
20: (SWANK::SIMPLE-ANNOUNCE-FUNCTION 4005)
21: (SWANK::SETUP-SERVER
     4005
     #<FUNCTION SWANK::SIMPLE-ANNOUNCE-FUNCTION>
     :SPAWN
     T
     :UTF-8-UNIX)
22: (SB-INT:EVAL-IN-LEXENV (START-SWANK *UCW-SWANK-PORT*) #<NULL-LEXENV>)
23: (SB-FASL::LOAD-AS-SOURCE
     #<SB-SYS:FD-STREAM for "file /etc/ucw/start.lisp" {AFCFAE1}>
     NIL
     NIL)
24: (SB-FASL::INTERNAL-LOAD
     #P"/etc/ucw/start.lisp"
     #P"/etc/ucw/start.lisp"
     :ERROR
     NIL
     NIL
     :SOURCE
     :DEFAULT)
25: (SB-FASL::INTERNAL-LOAD
     #P"/etc/ucw/start.lisp"
     #P"/etc/ucw/start.lisp"
     :ERROR
     NIL
     NIL
     NIL
     :DEFAULT)
26: (LOAD "/etc/ucw/start.lisp")
27: (SB-INT:EVAL-IN-LEXENV (LOAD (POP CL-LAUNCH:*ARGUMENTS*)) #<NULL-LEXENV>)
28: (SB-FASL::LOAD-AS-SOURCE #<SB-IMPL::STRING-INPUT-STREAM {AFC3599}> NIL NIL)
29: (LOAD #<SB-IMPL::STRING-INPUT-STREAM {AFC3599}>)
30: (CL-LAUNCH::LOAD-STRING "(load (pop cl-launch:*arguments*))")
31: (CL-LAUNCH::RUN
     :SYSTEM
     NIL
     :PATHS
     NIL
     :INIT
     "(load (pop cl-launch:*arguments*))"
     :LOAD
     NIL
     :QUIT
     NIL)
32: (SB-INT:EVAL-IN-LEXENV
     (FUNCALL (INTERN (STRING :RUN) :CL-LAUNCH)
              :INIT
              "(load (pop cl-launch:*arguments*))"
              :QUIT
              NIL)
     #<NULL-LEXENV>)
33: (SB-INT:EVAL-IN-LEXENV
     (PROGN
      (SET-DISPATCH-MACRO-CHARACTER #\#
                                    #\!
                                    #'(LAMBDA (STREAM CHAR SB-DEBUG:ARG)
                                        (DECLARE (IGNORE CHAR SB-DEBUG:ARG))
                                        (VALUES (READ-LINE STREAM))))
      (LOAD "/usr/bin/cl-launch" :VERBOSE NIL :PRINT NIL)
      (FUNCALL (INTERN (STRING :RUN) :CL-LAUNCH)
               :INIT
               "(load (pop cl-launch:*arguments*))"
               :QUIT
               NIL))
     #<NULL-LEXENV>)
34: (SB-IMPL::PROCESS-EVAL-OPTIONS
     ((SB-EXT:DISABLE-DEBUGGER)
      "(progn(set-dispatch-macro-character #\\# #\\! #'(lambda(stream char arg)(declare(ignore char arg))(values (read-line stream))))(load \"/usr/bin/cl-launch\" :verbose nil :print nil)
(funcall(intern(string :run):cl-launch) :init \"(load (pop cl-launch:*arguments*))\" :quit nil))"))
35: (SB-IMPL::TOPLEVEL-INIT)
36: ((LABELS SB-IMPL::RESTART-LISP))

unhandled condition in --disable-debugger mode, quitting
unhandled SB-INT:SIMPLE-STREAM-ERROR in thread #<SB-THREAD:THREAD "initial thread" {A7F2461}>:
  couldn't write to #<SB-SYS:FD-STREAM for "the terminal" {A7F2801}>:
    Bad file descriptor

0: (BACKTRACE
    128
    #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT-ERROR-OUTPUT* {A8412A1}>)
1: (SB-DEBUG::DEBUGGER-DISABLED-HOOK
    #<SB-INT:SIMPLE-STREAM-ERROR {C438501}>
    #<unavailable argument>)
2: (INVOKE-DEBUGGER #<SB-INT:SIMPLE-STREAM-ERROR {C438501}>)
3: (ERROR SB-INT:SIMPLE-STREAM-ERROR)
4: (SB-IMPL::SIMPLE-STREAM-PERROR
    "couldn't write to ~S"
    #<SB-SYS:FD-STREAM for "the terminal" {A7F2801}>
    9)
5: (SB-IMPL::FLUSH-OUTPUT-BUFFER
    #<SB-SYS:FD-STREAM for "the terminal" {A7F2801}>)
6: (FORCE-OUTPUT #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT-DEBUG-IO* {A8413A1}>)
7: (SB-INT:FLUSH-STANDARD-OUTPUT-STREAMS)
8: ((LABELS SB-IMPL::RESTART-LISP))

unhandled condition in --disable-debugger mode, quitting
Argh! error within --disable-debugger error handling










From mb at bese.it  Wed Apr 12 16:45:09 2006
From: mb at bese.it (Marco Baringer)
Date: Wed, 12 Apr 2006 18:45:09 +0200
Subject: [Bese-devel] Re: problem with detachtty
References: <483983b30604120443u64f41f16k55dd13ef095b9b47@mail.gmail.com>
Message-ID: <m2y7yakaju.fsf@bese.it>

"Daniel Patru" <dpatru at gmail.com> writes:

> UCW doesn't start on my machine when used with detachtty. However it starts
> without it. In ucwctl, the start option says:
>
>  start)
>         install -d -m 755 $LOGROOT $RUNROOT
>         $DETACHTTY --dribble-file $LOGROOT/ucw.dribble \
>             --log-file $LOGROOT/ucw.detachtty \
>             --pid-file $RUNROOT/ucw.pid \
>             $RUNROOT/ucw.socket \
>             $CLLAUNCH -X $OPT_LISP $OPT_PATH NO_QUIT=yes -- "$STARTFILE"
>         ;;

colud you try just running lisp, through detachtty, from the console?
(i'd like to know if the issue is detachtty itself or how we're
calling detachtty). try osmething like this:

`which detachtty` --dribble-file foo.dribble \
                  --log-file foo.log \
                  --pid-file foo.pid \
                  foo.socket sbcl

(assuming you're using sbcl)

-- 
-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 dpatru at gmail.com  Wed Apr 12 17:08:07 2006
From: dpatru at gmail.com (Daniel Patru)
Date: Wed, 12 Apr 2006 13:08:07 -0400
Subject: [Bese-devel] Re: problem with detachtty
In-Reply-To: <m2y7yakaju.fsf@bese.it>
References: <483983b30604120443u64f41f16k55dd13ef095b9b47@mail.gmail.com>
	<m2y7yakaju.fsf@bese.it>
Message-ID: <483983b30604121008w44689a47g1f6265611cff36a6@mail.gmail.com>

I tried: `which detachtty` --dribble-file foo.dribble \
                 --log-file foo.log \
                 --pid-file foo.pid \
                 foo.socket /usr/bin/sbcl
then: attachtty foo.socket
and I get the sbcl prompt. So detachtty/attachtty by themselves seem to
work.

On 4/12/06, Marco Baringer <mb at bese.it> wrote:
>
> "Daniel Patru" <dpatru at gmail.com> writes:
>
> > UCW doesn't start on my machine when used with detachtty. However it
> starts
> > without it. In ucwctl, the start option says:
> >
> >  start)
> >         install -d -m 755 $LOGROOT $RUNROOT
> >         $DETACHTTY --dribble-file $LOGROOT/ucw.dribble \
> >             --log-file $LOGROOT/ucw.detachtty \
> >             --pid-file $RUNROOT/ucw.pid \
> >             $RUNROOT/ucw.socket \
> >             $CLLAUNCH -X $OPT_LISP $OPT_PATH NO_QUIT=yes -- "$STARTFILE"
> >         ;;
>
> colud you try just running lisp, through detachtty, from the console?
> (i'd like to know if the issue is detachtty itself or how we're
> calling detachtty). try osmething like this:
>
> `which detachtty` --dribble-file foo.dribble \
>                   --log-file foo.log \
>                   --pid-file foo.pid \
>                   foo.socket sbcl
>
> (assuming you're using sbcl)
>
> --
> -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
>



--
"Work and play are used to describe the same thing under differing
circumstance."
  - Mark Twain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060412/d1c559bd/attachment.html>

From pjb at informatimago.com  Wed Apr 12 18:23:11 2006
From: pjb at informatimago.com (Pascal Bourguignon)
Date: Wed, 12 Apr 2006 20:23:11 +0200 (CEST)
Subject: [Bese-devel] defgeneric/cc missing in protocol.lisp ?
Message-ID: <20060412182311.B2B378510@thalassa.informatimago.com>


While asdf loading ucw freshly darc-downloaded, I get an error in
protocol.fas about: 

STANDARD method combination, used by
  #<STANDARD-GENERIC-FUNCTION CALL-COMPONENT>, allows no method
  qualifiers except (:BEFORE :AFTER :AROUND): #<STANDARD-METHOD
  :PRIMARY (#<BUILT-IN-CLASS NULL> #<STANDARD-CLASS
  STANDARD-COMPONENT>)>. 

Should I assume a defgeneric should be replaced by defgeneric/cc in
protocol.lisp?  At least, it can load with it.

(defgeneric/cc call-component (caller callee)
    ...)

instead of:

(defgeneric call-component (caller callee)
    ...)

in: ucw_dev/src/rerl/protocol.lisp

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
You never feed me.
Perhaps I'll sleep on your face.
That will sure show you.


From pjb at informatimago.com  Wed Apr 12 18:24:36 2006
From: pjb at informatimago.com (Pascal Bourguignon)
Date: Wed, 12 Apr 2006 20:24:36 +0200 (CEST)
Subject: [Bese-devel] LOOP: FOR clauses should occur before the loop's main
	body
Message-ID: <20060412182436.04FBA8510@thalassa.informatimago.com>


In ucw_dev/src/backend/multithread-httpd.lisp:

clisp gives this:
WARNING: LOOP: FOR clauses should occur before the loop's main body

I'd suggest:

(defun httpd-accept-loop (backend)
  (loop
     ;; loop until we get a start message
     (receive
       ((start) (return))))
  (loop
     for stream = (and (socket backend) 
                       (accept-connection (socket backend)
                                          :element-type '(unsigned-byte 8)))
     while (socket backend)
     do (send (control-thread backend)
              'connection
              (make-instance 'pending-request :network-stream stream))))


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
You never feed me.
Perhaps I'll sleep on your face.
That will sure show you.


From pjb at informatimago.com  Wed Apr 12 18:25:08 2006
From: pjb at informatimago.com (Pascal Bourguignon)
Date: Wed, 12 Apr 2006 20:25:08 +0200 (CEST)
Subject: [Bese-devel] arnesi_dev/src/string.lisp #+clisp
	encoding-keyword-to-native is wrong.
Message-ID: <20060412182508.2D84C8510@thalassa.informatimago.com>


In arnesi_dev/src/string.lisp,
#+clisp encoding-keyword-to-native is wrong.

Here is a correct implementation:

#+(and clisp unicode)
(progn
  (defun encoding-keyword-to-native (encoding)
    (ext:make-encoding
     :charset (case encoding
                (:utf-8    charset:utf-8)
                (:utf-16   charset:utf-16)
                (:us-ascii charset:ascii)
                (t (multiple-value-bind (symbol status)
                       (find-symbol (string encoding) (find-package :charset))
                     (if (eq status :external)
                         (symbol-value symbol)
                         ;; otherwise, if SYSTEM::*HTTP-ENCODING*
                         ;; is available, then use it
                         #+#.(cl:if (cl:find-symbol "*HTTP-ENCODING*" 
                                                    (cl:find-package "SYSTEM"))
                                    '(and) '(or))
                         SYSTEM::*HTTP-ENCODING*
                         ;; otherwise, use EXT:*MISC-ENCODING*
                         #+#.(cl:if (cl:find-symbol "*HTTP-ENCODING*" 
                                                    (cl:find-package "SYSTEM"))
                                    '(or) '(and))
                         EXT:*MISC-ENCODING*))))
     ;; These native encodings will be used for the HTTP protocol, 
     ;; therefore we set the line-terminator to MS-DOS.
     ;; Of course, it would be better if this was explicitely requested...
     :line-terminator :dos
     :input-error-action #\uFFFD
     :output-error-action #+debug :error #-debug :ignore))
  (defun %string-to-octets (string encoding)
    (ext:convert-string-to-bytes string (encoding-keyword-to-native encoding)))
  (defun %octets-to-string (octets encoding)
    (ext:convert-string-from-bytes octets (encoding-keyword-to-native encoding))))




-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

COMPONENT EQUIVALENCY NOTICE: The subatomic particles (electrons,
protons, etc.) comprising this product are exactly the same in every
measurable respect as those used in the products of other
manufacturers, and no claim to the contrary may legitimately be
expressed or implied.


From nathan at acceleration.net  Thu Apr 13 01:34:41 2006
From: nathan at acceleration.net (Nathan Bird)
Date: Wed, 12 Apr 2006 21:34:41 -0400
Subject: [Bese-devel] Loading UCW with ucwctl, cl-launch etc
In-Reply-To: <878xqb457c.fsf@gismo.pca.it>
Message-ID: <00a001c65e9a$700fb550$d80a0a0a@acceleration.net>

Trying to keep the length down, but we have a couple of topics going on
simultaneously here.


>-----Original Message-----
>From: bese-devel-bounces at common-lisp.net [mailto:bese-devel-bounces at common-
>lisp.net] On Behalf Of Luca Capello
>Sent: Wednesday, April 12, 2006 3:35 AM
>To: bese-devel at common-lisp.net
>Subject: Re: [Bese-devel] Loading UCW with ucwctl, cl-launch etc
>
>Hello!
>
>On Wed, 12 Apr 2006 01:40:42 +0200, Nathan Bird wrote:
>> What? How? Seriously, I'm lost here.
>
>And I'm here to save you :-D
Woohoo! Seriously though, I didn't include to many logs and such because I
was to far off, I needed to see further how the intended system worked, and
how to try to match that with what I am doing before I could tackle any of
the specific bugs. Its become a bit clearer in the past day, but I think
there are still things we can do to smooth it out.

>I'd like to note that my patch doesn't depend on any Debian package.
>The problem about cl-launch vs cl-launch.sh was a very stupid one.
>The SLIME problem with cl-launch has nothing to do with Debian, in
>fact the Debian cl-swank package adopted a different workaround.

Ok, you are correct. I had gotten this from detachtty, which was ALREADY a
requirement that I had installed it with apt. When your patch said I needed
the darcs version, I opened the INSTALL file and found: "This is a native
Debian package, which means that if you are having trouble with the Debian
version there is usually little point in trying the upstream version to see
if it's improved." while upgrading to the upstream version ;-)

As a note I haven't been using the common-lisp-controller, I tried that when
I initially started out, but as I recall it was a couple of versions behind
and something I had needed a newer version. I take it some of this work is
to get UCW into a Debian system?

Hopefully we can get the patches to swank-loader.lisp committed at some
point... I resent a patch containing both my changes and your changes
(related to the CLC compatibility) to the slime-devel list
http://common-lisp.net/pipermail/slime-devel/2006-April/004791.html.

>> *	Multiple instances of UCW. [...] Installing stuff to /etc doesn't
>> work in this case.
>
>Nothing needs to be installed, as for the ucwctl command line
>arguments...  But I agree that having multiple shell scripts just to
>start multiple ucwctl instances with different parameters is not the
>best thing.

Is there any way to use a ucwctl.conf that isn't at /etc/ucw? I am going to
have to specify at least configfile and var every time. What is the
intention of ASDFROOT? Is this a replacement/standin for any asd setup the
lisp or lisp-init-file had been doing previously? 

The frustration is in having to specify several command line parameters at
every startup in order to work around the configuration file. I would rather
specify a few more parameters once when I write the deployment script.

Alternatively I could bypass using the -c flag by editing default.lisp
analogous to how I use start.lisp now. I didn't know that yesterday. (Thanks
everyone)

>> [...]
>> Can we instead default to ucw_dev/bin/etc/* ?
>
>I should say that the other idea was to implement something like a
>`make install` command...
>
>I'm against defaulting to ucw_dev/bin/etc/*, but if this is the common
>decision, I'll agree on that.
>
>BTW, as Marco suggested on private conversation, ucw_dev/bin/etc
>should be probably moved to ucw_dev/etc.

I like the idea of ucw_dev/etc. 
Is there a reason you don't like having all of the configuration wrapped up
into UCW? If the files are being distributed in ucw_dev/etc it is more
intuitive to me to have the defaults point there. I have seen this pattern
of keeping a project-local 'etc' in a few other projects that are
distributing cross platform versions. Maybe I have just had the misfortune
of dealing with more bad ports of unix projects to windows than you have had
to suffer.

I'm (attempting to) suggest we have the defaults make UCW work out of the
box... you know after forcing the guy to fetch a dozen different
dependencies :-)

>> *	ANYTHING in the readme?
>
>Maybe I didn't sponsor it, but there a manual page for ucwctl: [...]

I saw that but my initial impression was that it was the same info as the
--help. I now see it has more in it, either that or someone was doing some
patch magic overnight ;-) I spoke precipitously.


Nathan



From mbaringer at common-lisp.net  Thu Apr 13 04:00:07 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Thu, 13 Apr 2006 00:00:07 -0400 (EDT)
Subject: [Bese-devel] New patches to arnesi_dev: 12-Apr-2006
Message-ID: <20060413040007.3C09342001@common-lisp.net>


Wed Apr 12 09:24:03 EDT 2006  Luca Capello <luca at pca.it>
  * src/posixenv.lisp: define `getenv'
  
  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).

    M ./arnesi.asd -2 +36
    M ./src/packages.lisp -3 +7
    A ./src/posixenv.lisp


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

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


From mbaringer at common-lisp.net  Thu Apr 13 04:30:03 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Thu, 13 Apr 2006 00:30:03 -0400 (EDT)
Subject: [Bese-devel] New patches to ucw_dev: 12-Apr-2006
Message-ID: <20060413043003.DFC935C122@common-lisp.net>


Wed Apr 12 11:45:07 EDT 2006  Luca Capello <luca at pca.it>
  * src/default.lisp: use `arnesi:getenv' instead of `cl-launch:getenv'

    M ./src/default.lisp -7 +3
    M ./ucw.asd -1 +3

Wed Apr 12 08:09:12 EDT 2006  Luca Capello <luca at pca.it>
  * src/control.lisp: define quit as key in `ucw:bye-bye'

    M ./src/control.lisp -6 +16

Wed Apr 12 03:06:09 EDT 2006  Luca Capello <luca at pca.it>
  * bin/ucwctl: parse correctly -config-file and not -config
  
  This was a stupid error of mine, because I alwasy tested with the
  short -c option and not the long one.
  
  Thank Nathan Bird to have pointed it out:
  
    http://common-lisp.net/pipermail/bese-devel/2006-April/001915.html

    M ./bin/ucwctl -2 +2


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

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


From luca at pca.it  Thu Apr 13 09:46:28 2006
From: luca at pca.it (Luca Capello)
Date: Thu, 13 Apr 2006 11:46:28 +0200
Subject: [Bese-devel] Re: Loading UCW with ucwctl, cl-launch etc
References: <878xqb457c.fsf@gismo.pca.it>
	<00a001c65e9a$700fb550$d80a0a0a@acceleration.net>
Message-ID: <874q0xyfij.fsf@gismo.pca.it>

Hello!

On Thu, 13 Apr 2006 03:34:41 +0200, Nathan Bird wrote:
> Trying to keep the length down, but we have a couple of topics going
> on simultaneously here.

Finally someone who writes long mails like me ;-)

>> I'd like to note that my patch doesn't depend on any Debian
>> package.  The problem about cl-launch vs cl-launch.sh was a very
>> stupid one.  The SLIME problem with cl-launch has nothing to do
>> with Debian, in fact the Debian cl-swank package adopted a
>> different workaround.
>
> Ok, you are correct. I had gotten this from detachtty, which was
> ALREADY a requirement that I had installed it with apt.

Yes, I forgot that detachtty was primarily developed for Debian :-(

> As a note I haven't been using the common-lisp-controller,

I tested my patch various time with and without the c-l-c: except the
cl-launch + SLIME bug, AFAIK no other problems.

> I take it some of this work is to get UCW into a Debian system?

Well, my final aim is to get UCW into Debian, but I tried to be as
most Debian-unrelated as possible.  The first step was to avoid manual
modification of the sources to configure UCW, which is IMHO a
requirement for a newbie (not only a Debian user).

> Is there any way to use a ucwctl.conf that isn't at /etc/ucw? I am
> going to have to specify at least configfile and var every time.

Ok, I think I need to implement another option for ucwctl, which will
be -u or --ucwctl-config and will default to /etc/ucw/ucwctl.conf if
empty.  Moreover, this won't be a mandatory option, as all ucwctl.conf
values can be overridden by the other command line options.

I think that --config-file should still refer to the conf.lisp, so the
UCW config file, not the ucwctl one, otherwise we should change every
file option, something like

    --config-file   --->   --ucw-config-file
    --start-file    --->   --ucw-start-file

Moreover, as of [1], in the next few days I'll submit the patch to
stop UCW via a stop.lisp file, which will be option -k or --kill-file
(well, we can't use -s, but maybe --stop-file is better).

> What is the intention of ASDFROOT? Is this a replacement/standin for
> any asd setup the lisp or lisp-init-file had been doing previously?

Imagine that you've some ASDF files in ~/.sbcl/systems/ and others in
~/systems: the former is by default picked up when you fire up SBCL,
the latter needs to be added by hand.  In this case, you specify
$ASDFROOT for ~/systems.

Obviously, the same can be done specifying the paths in ~/.sbclrc, but
$ASDFROOT is simpler if you want to test different version libraries.

> The frustration is in having to specify several command line
[...]
> that yesterday. (Thanks everyone)

As I posted yesterday [2], now you can load the start.lisp file
directly with `sbcl --load start.lisp`.

Moreover [3], you can specify any parameter you want in that file, too
(just do it before the `:ucw.default' system is loaded up).

>> BTW, as Marco suggested on private conversation, ucw_dev/bin/etc
>> should be probably moved to ucw_dev/etc.
>
> I like the idea of ucw_dev/etc.

I'll do that adding an INSTALL file, too, and maybe updating the
README ;-)

> Is there a reason you don't like having all of the configuration
> wrapped up into UCW? If the files are being distributed in
> ucw_dev/etc it is more intuitive to me to have the defaults point
> there.

I always thought about UCW as something you need to install, with the
configuration separated from the sources.

One possible "developer" solution will be to provide a ucwctl.dev,
which defaults to ucw_dev/etc.

Or, from a local user POV, defaulting to /usr/local/etc (which I don't
like at all).

> I'm (attempting to) suggest we have the defaults make UCW work out
> of the box... you know after forcing the guy to fetch a dozen
> different dependencies :-)

At least in my opinion, out-of-the-box means after something like a
`make install` (as root or local).  I've some ideas how to solve it
even without a `make install`, I'll try to work on.

Thx, bye,
Gismo / Luca

[1] http://common-lisp.net/pipermail/bese-devel/2006-April/001862.html
[2] http://common-lisp.net/pipermail/bese-devel/2006-April/001924.html
[3] http://common-lisp.net/pipermail/bese-devel/2006-April/001925.html
-------------- 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/20060413/e83c8b57/attachment.sig>

From cjstuij at gmail.com  Thu Apr 13 12:20:03 2006
From: cjstuij at gmail.com (Ties Stuij)
Date: Thu, 13 Apr 2006 14:20:03 +0200
Subject: [Bese-devel] some docs
Message-ID: <d7ce4ebf0604130520y5576f17ame91db637320bb69b@mail.gmail.com>

he there,
here are some doc patches. I updated the README, and i added my
tutorial to the docs section.

greets,
Ties
-------------- next part --------------
A non-text attachment was scrubbed...
Name: add-docs.patch
Type: text/x-patch
Size: 223512 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060413/233c6198/attachment.bin>

From mb at bese.it  Thu Apr 13 14:01:36 2006
From: mb at bese.it (Marco Baringer)
Date: Thu, 13 Apr 2006 16:01:36 +0200
Subject: [Bese-devel] Re: defgeneric/cc missing in protocol.lisp ?
References: <20060412182311.B2B378510@thalassa.informatimago.com>
Message-ID: <m23bghr2v3.fsf@bese.it>

Pascal Bourguignon <pjb at informatimago.com> writes:

> While asdf loading ucw freshly darc-downloaded, I get an error in
> protocol.fas about: 
>
> STANDARD method combination, used by
>   #<STANDARD-GENERIC-FUNCTION CALL-COMPONENT>, allows no method
>   qualifiers except (:BEFORE :AFTER :AROUND): #<STANDARD-METHOD
>   :PRIMARY (#<BUILT-IN-CLASS NULL> #<STANDARD-CLASS
>   STANDARD-COMPONENT>)>. 
>
> Should I assume a defgeneric should be replaced by defgeneric/cc in
> protocol.lisp?  At least, it can load with it.
>
> (defgeneric/cc call-component (caller callee)
>     ...)
>
> instead of:
>
> (defgeneric call-component (caller callee)
>     ...)
>
> in: ucw_dev/src/rerl/protocol.lisp

fixed. thanks.

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



From mb at bese.it  Thu Apr 13 14:04:53 2006
From: mb at bese.it (Marco Baringer)
Date: Thu, 13 Apr 2006 16:04:53 +0200
Subject: [Bese-devel] Re: arnesi_dev/src/string.lisp #+clisp
	encoding-keyword-to-native is wrong.
References: <20060412182508.2D84C8510@thalassa.informatimago.com>
Message-ID: <m2y7y9po56.fsf@bese.it>

Pascal Bourguignon <pjb at informatimago.com> writes:

>      ;; These native encodings will be used for the HTTP protocol, 
>      ;; therefore we set the line-terminator to MS-DOS.
>      ;; Of course, it would be better if this was explicitely requested...

i really hope this comment i wrong, neither the httpd backend nor the
mod_lisp backend should be treating the http streams as text and both
should be explicitly sending CRLF _byte_ pairs to the stream.

i applied the patch.

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



From pjb at informatimago.com  Thu Apr 13 14:47:12 2006
From: pjb at informatimago.com (Pascal Bourguignon)
Date: Thu, 13 Apr 2006 16:47:12 +0200
Subject: [Bese-devel] Re: arnesi_dev/src/string.lisp #+clisp
	encoding-keyword-to-native is wrong.
In-Reply-To: <m2y7y9po56.fsf@bese.it>
References: <20060412182508.2D84C8510@thalassa.informatimago.com>
	<m2y7y9po56.fsf@bese.it>
Message-ID: <17470.25712.730168.331558@thalassa.informatimago.com>

Marco Baringer writes:
> Pascal Bourguignon <pjb at informatimago.com> writes:
> 
> >      ;; These native encodings will be used for the HTTP protocol, 
> >      ;; therefore we set the line-terminator to MS-DOS.
> >      ;; Of course, it would be better if this was explicitely requested...
> 
> i really hope this comment i wrong, neither the httpd backend nor the
> mod_lisp backend should be treating the http streams as text and both
> should be explicitly sending CRLF _byte_ pairs to the stream.

I see.  The question is whether they will call these octets<->string
functions on single lines or on blocks of texts including CR/LF.  

If they convert only lines and insert themselves the 13/10 codes, then
this doesn't matter.

Otherwise, clisp convert-string-to-bytes with an encoding using a
MS-DOS line terminator can be used to generate the CR/LF mandated by
the protocol.  Note that for the convertion from octets to string,
clisp doesn't take into account the line terminator and interprets
both CR/LF, CR and LF as newline.


> i applied the patch.




-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

In a World without Walls and Fences, 
who needs Windows and Gates?


From a_bakic at yahoo.com  Thu Apr 13 17:04:51 2006
From: a_bakic at yahoo.com (Aleksandar Bakic)
Date: Thu, 13 Apr 2006 10:04:51 -0700 (PDT)
Subject: [Bese-devel] Re: defgeneric/cc missing in protocol.lisp ?
In-Reply-To: <m23bghr2v3.fsf@bese.it>
Message-ID: <20060413170451.4728.qmail@web38905.mail.mud.yahoo.com>

Hi,

Why not change answer-component defgeneric, a few lines below, in the same way?

Alex

> > Should I assume a defgeneric should be replaced by defgeneric/cc in
> > protocol.lisp?  At least, it can load with it.
> >
> > (defgeneric/cc call-component (caller callee)
> >     ...)
> >
> > instead of:
> >
> > (defgeneric call-component (caller callee)
> >     ...)
> >
> > in: ucw_dev/src/rerl/protocol.lisp
> 
> fixed. thanks.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From mbaringer at common-lisp.net  Fri Apr 14 04:30:04 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Fri, 14 Apr 2006 00:30:04 -0400 (EDT)
Subject: [Bese-devel] New patches to ucw_dev: 13-Apr-2006
Message-ID: <20060414043004.B7A3B69002@common-lisp.net>


Thu Mar  9 07:15:02 EST 2006  drewc at tech.coop
  * Fixed :ISOLATE. This has been broken a long time.

    M ./src/rerl/standard-action.lisp -7 +13
    M ./src/rerl/standard-component/standard-component.lisp -15

Thu Apr 13 10:06:34 EDT 2006  Marco Baringer <mb at bese.it>
  * Reorder LOOP forms to silence clisp. (Patch by: Pascal Bourguignon <pjb at informatimago.com>)

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

Thu Apr 13 10:05:50 EDT 2006  Marco Baringer <mb at bese.it>
  * Added Pascal Bourguignon <pjb at informatimago.com> to AUTHORS

    M ./AUTHORS +1

Thu Apr 13 10:01:26 EDT 2006  Marco Baringer <mb at bese.it>
  * Substitute defgeneric with defgeneric/cc (Patch by: Pascal Bourguignon <pjb at informatimago.com>)

    M ./src/rerl/protocol.lisp -1 +1

Wed Apr 12 11:50:33 EDT 2006  Marco Baringer <mb at bese.it>
  * Removed the make-image script (it hasn't worked in _ages_)

    R ./bin/make-image.lisp

Thu Apr 13 09:25:23 EDT 2006  cjstuij at gmail.com
  * updates the README and adds the ucw intro tutorial

    A ./README
    A ./docs/ucw-intro/
    A ./docs/ucw-intro/style.css
    A ./docs/ucw-intro/ucw-intro.html
    A ./docs/ucw-intro/ucw-intro_stage_dirs.tar

Thu Apr 13 07:18:01 EDT 2006  cjstuij at gmail.com
  * rm-README

    R ./README


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

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


From luca at pca.it  Fri Apr 14 22:29:22 2006
From: luca at pca.it (Luca Capello)
Date: Sat, 15 Apr 2006 00:29:22 +0200
Subject: [Bese-devel] Load a custom ucwctl.conf (was Re: Loading UCW with
	ucwctl, cl-launch etc)
References: <878xqb457c.fsf@gismo.pca.it>
	<00a001c65e9a$700fb550$d80a0a0a@acceleration.net>
	<874q0xyfij.fsf@gismo.pca.it>
Message-ID: <87mzenu6yl.fsf_-_@gismo.pca.it>

Hello!

On Thu, 13 Apr 2006 11:46:28 +0200, Luca Capello wrote:
> On Thu, 13 Apr 2006 03:34:41 +0200, Nathan Bird wrote:
>> Is there any way to use a ucwctl.conf that isn't at /etc/ucw? I am
>> going to have to specify at least configfile and var every time.
>
> Ok, I think I need to implement another option for ucwctl, which
> will be -u or --ucwctl-config and will default to
> /etc/ucw/ucwctl.conf if empty.  Moreover, this won't be a mandatory
> option, as all ucwctl.conf values can be overridden by the other
> command line options.

Actually, it's quite complex to have a custom ucwctl.conf.

Here's the actual situation:

- /etc/ucw/ucwctl.conf (if it exists) is readed as soon as you call
  ucwctl

- any command line options present is set

Different solutions (the order is my preference)...

1) the simplest one is to allow a per-user ~/.ucw/, which will be
   similar to /etc/ucw/ in content, but will supersede /etc/ucw/.
   This let a normal user to start ucwctl without root privileges and
   without specifying too many command line options.  IMHO this is
   useful in any case.

2) allow the -u|--ucwctl-config command line option, but superseding
   every other command line option.  This because we don't have any
   simple method to parse a specific command line option before the
   others (and we can't assume that -u will be the first command line
   option).  Solution 1 will alwasy be a fallback.

3) allow -u and all the other command line options.  This will be
   really a pain to be coded: you must set the command line options as
   temp (something like CONFIGFILE_TMP), at the end of the parse run
   you read the ucwctl.conf (if present, fallback is solution 1) and
   finally "fix" the temp variables.  Feasible, but not my
   preferred...

Comments?

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/20060415/6f37403c/attachment.sig>

From luca at pca.it  Sat Apr 15 14:42:42 2006
From: luca at pca.it (Luca Capello)
Date: Sat, 15 Apr 2006 16:42:42 +0200
Subject: [Bese-devel] Re: ucwctl: load stop.lisp instead of calling
	`ucw:bye-bye'?
References: <87fykx8b83.fsf@gismo.pca.it>
Message-ID: <87d5fi99y5.fsf@gismo.pca.it>

Hello!

On Sat, 01 Apr 2006 19:19:40 +0200, Luca Capello wrote:
> On a private discussion, Marco proposed to use a stop.lisp file
> instead, thus the command will be:
>
>   $ attachtty socket '(load "stop.lisp")' timeout [... || ...]

It's in the repo, defaults to /etc/ucw/stop.lisp and is configurable
via the -k or --stop-file command line options.

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/20060415/b4095666/attachment.sig>

From luca at pca.it  Sun Apr 16 00:47:20 2006
From: luca at pca.it (Luca Capello)
Date: Sun, 16 Apr 2006 02:47:20 +0200
Subject: [Bese-devel] Re: some docs
References: <d7ce4ebf0604130520y5576f17ame91db637320bb69b@mail.gmail.com>
Message-ID: <877j5q8hyf.fsf@gismo.pca.it>

Hello!

On Thu, 13 Apr 2006 14:20:03 +0200, Ties Stuij wrote:
> here are some doc patches. I updated the README, and i added my
> tutorial to the docs section.

I've some comments, but I haven't committed the patch ;-)

hunk ./README 381
-$ export CONFIGFILE=/etc/ucw/conf.lisp

  This is not necessary because it's already in /etc/ucw/ucwctl.conf
  and the default in ucwctl.  And if you plan different run with
  different CONFIGFILEs, I suggest to not export anything, instead:

    $ CONFIGFILE=/path/to/config-file cl-launch...


hunk ./README 392
-can't yet supply more than one dir through ucwctl. NO_QUIT isn't
-defined in the cl-launch script; people familiar to shell scripting
-will or will not know what this is for. The last bit of text is the
-startup file for ucw, which you can pretty much leave as
+can't yet supply more than one dir through ucwctl. When NO_QUIT is
+set, cl-launch doesn't exit after having executed the last bit of
+text, the startup file for ucw, which you can pretty much leave as

  The following example is self-explanatory IMHO:

    $ cat test.lisp
    (format t "Test~%")
    $ cl-launch -X -l sbcl -- test.lisp
    Test
    $ cl-launch -X -l sbcl NO_QUIT=yes -- test.lisp
    Test
    * (quit)
    $


hunk ./README 419
+[ADD THE NEW OPTIONS HERE]

  I mean, since this night patches, like -k|--stop-file...


hunk ./README 441
-All the options, except for --log-root and --run-root are configurable
-through /etc/ucw/ucwctl.conf . In ucwctl.conf default values are
-provided except for the lisp implementation and the .asd directory. If
-you have configured those last two, you have put the files from
-/path/to/ucw_dev/bin/etc in /etc/ucw/ and you are root, you can start
-ucw by invoking:
+All the options are configurable through /etc/ucw/ucwctl.conf .  If
+you want to specify different paths for --log-root and --run-root, add
+LOGROOT=/path/to/log-root and RUNROOT=/path/to/run-root, leaving
+VARROOT empty. In ucwctl.conf default values are provided except for
+the lisp implementation and the .asd directory. If you have configured
+those last two, you have put the files from /path/to/ucw_dev/bin/etc
+in /etc/ucw/ and you are root, you can start ucw by invoking:

  Actually, even LOGROOT and RUNROOT are configurable in ucwctl.conf.
  As soon as one of the two is specified, its value overrides the
  general VARROOT (i.e. VARROOT/log/ucw and VARROOT/run/ucw,
  respectively).


HTH!

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/20060416/1e4449f6/attachment.sig>

From luca at pca.it  Sun Apr 16 00:47:59 2006
From: luca at pca.it (Luca Capello)
Date: Sun, 16 Apr 2006 02:47:59 +0200
Subject: [Bese-devel] Re: Loading UCW with ucwctl, cl-launch etc
References: <014301c65dc1$59462b80$d80a0a0a@acceleration.net>
	<b9ee0c4d0604112009u42da57d7u71b331df0d874226@mail.gmail.com>
	<871ww344p2.fsf@gismo.pca.it> <87mzeq24f1.fsf@gismo.pca.it>
Message-ID: <873bge8hxc.fsf@gismo.pca.it>

Hello!

On Wed, 12 Apr 2006 17:34:58 +0200, Luca Capello wrote:
> Actually, I just found a possible error in src/default.lisp: the
[...]
> I think the best solution will be the following in src/default.lisp:
>
>   (if *ucw-config-file*
>     (load-config-file)
>     (load-applications))

It's in the repo.

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/20060416/bc1f56ca/attachment.sig>

From mbaringer at common-lisp.net  Sun Apr 16 04:30:04 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Sun, 16 Apr 2006 00:30:04 -0400 (EDT)
Subject: [Bese-devel] New patches to ucw_dev: 15-Apr-2006
Message-ID: <20060416043004.C1C7264009@common-lisp.net>


Sat Apr 15 19:40:25 EDT 2006  Luca Capello <luca at pca.it>
  * src/default.lisp: `load-applications' when `*ucw-config-file*' is nil
  
  If `*ucw-config-file*' is nil you get the following error:
  
    The variable *EXAMPLE-APPLICATION* is unbound
  
  `*ucw-systems*' contains the `*example-application*' system, but this
  is not loaded by ASDF, because `*ucw-config-file*' is nil.  A slightly
  deeper explanation is available at:
  
    http://common-lisp.net/pipermail/bese-devel/2006-April/001925.html
  
  Also correct a typo for `*ucw-config-file*' in src/config.lisp.

    M ./src/config.lisp -1 +1
    M ./src/default.lisp -2 +3

Sat Apr 15 18:37:49 EDT 2006  Luca Capello <luca at pca.it>
  * deal with `*ucw-applications-directory*' not ending with a /
  
  In src/default.lisp I forgot the last / for the value of
  `*ucw-applications-directory*' (/etc/ucw/applications.d), thus every
  time you have application ASDF files in the default location, you get
  the following error:
  
    component "application" not found
  
  This because the location in `asdf:*central-registry*' also lacks the
  last / (/etc/ucw/applications.d) and I bet this could be a common
  situation.
  
  This patch deals with this specific case: it always adds a "/" when
  pushing `*ucw-applications-directory*' into `asdf:*central-registry*'.

    M ./src/config.lisp -1 +1
    M ./src/default.lisp -1 +1

Sat Apr 15 10:43:05 EDT 2006  Luca Capello <luca at pca.it>
  * move bin/etc/ to etc/

     ./bin/etc -> ./etc

Sat Apr 15 10:33:53 EDT 2006  Luca Capello <luca at pca.it>
  * bin/ucwctl: stop UCW reading etc/stop.lisp

    M ./bin/etc/ucwctl.conf -1 +4
    M ./bin/ucwctl -1 +14
    M ./bin/ucwctl.1 -1 +5

Sat Apr 15 10:33:15 EDT 2006  Marco Baringer <mb at bese.it>
  * Added Slawek Zak to authors

    M ./AUTHORS +1

Sat Apr 15 09:02:42 EDT 2006  Marco Baringer <mb at bese.it>
  * Drop more time-stamp lines (hopefully this is the last such commit)

    M ./bin/etc/ucwctl.conf -2
    M ./bin/ucwctl.1 -2
    M ./ucw.asd -2

Sat Apr 15 08:58:14 EDT 2006  Marco Baringer <mb at bese.it>
  * Drop Time-stamp from ucwctl

    M ./bin/ucwctl -2

Sat Apr 15 07:55:31 EDT 2006  Marco Baringer <mb at bese.it>
  * Drop Time-stamp lines

    M ./bin/etc/conf.lisp -2
    M ./bin/etc/start.lisp -2
    M ./src/config.lisp -2
    M ./src/default.lisp -2


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

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


From cjstuij at gmail.com  Sun Apr 16 07:33:47 2006
From: cjstuij at gmail.com (Ties Stuij)
Date: Sun, 16 Apr 2006 09:33:47 +0200
Subject: [Bese-devel] Re: some docs
In-Reply-To: <877j5q8hyf.fsf@gismo.pca.it>
References: <d7ce4ebf0604130520y5576f17ame91db637320bb69b@mail.gmail.com>
	<877j5q8hyf.fsf@gismo.pca.it>
Message-ID: <d7ce4ebf0604160033p759f6449l65692aca20de4861@mail.gmail.com>

Nice, I'll change them in the tutorial also. Just one remark:

> hunk ./README 381
> -$ export CONFIGFILE=/etc/ucw/conf.lisp
>
>   This is not necessary because it's already in /etc/ucw/ucwctl.conf
>   and the default in ucwctl.  And if you plan different run with
>   different CONFIGFILEs, I suggest to not export anything, instead:
>
>     $ CONFIGFILE=/path/to/config-file cl-launch...

The export is necessary in this example because it bypasses ucwctl
altogether. Without it the line below it won't get ucw to the config
file:

$ cl-launch -X -l your-lisp-invoke-name -p
/path/to/ucw/dependency/asd/files/dir NO_QUIT=yes --
/etc/ucw/start.lisp

I put it in to show how ucwctl worked and to show how ucw can be
started without detachtty. Granted, it might be a bit to much detail,
but then i suggest changing the text to get rid of the whole cl-launch
invocation example.

greets,
Ties


From luca at pca.it  Sun Apr 16 08:20:21 2006
From: luca at pca.it (Luca Capello)
Date: Sun, 16 Apr 2006 10:20:21 +0200
Subject: [Bese-devel] Re: some docs
References: <d7ce4ebf0604130520y5576f17ame91db637320bb69b@mail.gmail.com>
	<877j5q8hyf.fsf@gismo.pca.it>
	<d7ce4ebf0604160033p759f6449l65692aca20de4861@mail.gmail.com>
Message-ID: <87lku6dj96.fsf@gismo.pca.it>

Hello!

On Sun, 16 Apr 2006 09:33:47 +0200, Ties Stuij wrote:
> The export is necessary in this example because it bypasses ucwctl
> altogether. Without it the line below it won't get ucw to the config
> file:

Sorry, you're right, I completely missread the example...  :-(

> I put it in to show how ucwctl worked and to show how ucw can be
> started without detachtty. Granted, it might be a bit to much
> detail, but then i suggest changing the text to get rid of the whole
> cl-launch invocation example.

Well, I think that if you want to start UCW without detachtty you
don't want cl-launch neither, because you can directly load the
start.lisp file.

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/20060416/03678ea7/attachment.sig>

From cjstuij at gmail.com  Sun Apr 16 09:58:50 2006
From: cjstuij at gmail.com (Ties Stuij)
Date: Sun, 16 Apr 2006 11:58:50 +0200
Subject: [Bese-devel] Re: some docs
In-Reply-To: <d7ce4ebf0604160256k75e71852h80f9a0c88ae5a217@mail.gmail.com>
References: <d7ce4ebf0604130520y5576f17ame91db637320bb69b@mail.gmail.com>
	<877j5q8hyf.fsf@gismo.pca.it>
	<d7ce4ebf0604160033p759f6449l65692aca20de4861@mail.gmail.com>
	<87lku6dj96.fsf@gismo.pca.it>
	<d7ce4ebf0604160256k75e71852h80f9a0c88ae5a217@mail.gmail.com>
Message-ID: <d7ce4ebf0604160258n432f0b6ep6b43cbfaa833dadf@mail.gmail.com>

> Well, I think that if you want to start UCW without detachtty you
> don't want cl-launch neither, because you can directly load the
> start.lisp file.

A yes, didn't know that was fixed already. The pace of the startup
improvements is blistering ;-) I'll change my writeups accordingly.

Ties


From attila.lendvai at gmail.com  Sun Apr 16 18:25:14 2006
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Sun, 16 Apr 2006 20:25:14 +0200
Subject: [Bese-devel] rebind for parenscript
Message-ID: <b54b34af0604161125p504003abx1b154e65e90de3b@mail.gmail.com>

hi!

in js you can not simply rebind variables like you can in lisp with a (let
(..) ..)

because of this if you create closures you can not easily separate their
bindings.

err, i mean you couldn't before this patch... :)

not that it's magic, but it comes handy and simple to use.

i'm not sure about its placement, i just added it to js.lisp to the helper
stuff. feel free to move around...

- attila

(alias 101 on irc &no 'its not lisp code :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060416/6639430f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: parenscript-rebind.patch
Type: text/x-patch
Size: 7263 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060416/6639430f/attachment.bin>

From whalliburton at gmail.com  Sun Apr 16 20:17:18 2006
From: whalliburton at gmail.com (William Halliburton)
Date: Sun, 16 Apr 2006 15:17:18 -0500
Subject: [Bese-devel] cl-gd image generation
Message-ID: <4e7bd29e0604161317k2ac226feg34f673cd657c7cac@mail.gmail.com>

Simple. Thank you ucw.

Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060416/60341cd0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gd.lisp
Type: application/octet-stream
Size: 3208 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060416/60341cd0/attachment.obj>

From luca at pca.it  Sun Apr 16 23:16:45 2006
From: luca at pca.it (Luca Capello)
Date: Mon, 17 Apr 2006 01:16:45 +0200
Subject: [Bese-devel] Re: Load a custom ucwctl.conf
References: <878xqb457c.fsf@gismo.pca.it>
	<00a001c65e9a$700fb550$d80a0a0a@acceleration.net>
	<874q0xyfij.fsf@gismo.pca.it> <87mzenu6yl.fsf_-_@gismo.pca.it>
Message-ID: <87slodm7qa.fsf@gismo.pca.it>

Hello!

On Sat, 15 Apr 2006 00:29:22 +0200, Luca Capello wrote:
> Actually, it's quite complex to have a custom ucwctl.conf.
[...]
> 3) allow -u and all the other command line options.  This will be
>    really a pain to be coded: you must set the command line options
>    as temp (something like CONFIGFILE_TMP), at the end of the parse
>    run you read the ucwctl.conf (if present, fallback is solution 1)
>    and finally "fix" the temp variables.  Feasible, but not my
>    preferred...

I implemented this solution and at the end it's not so complex (but I
hope I considered all the possible scenarios).  I made some tests
(just echoing the variables) and it seems OK.  What happens, in order:

  1. /etc/ucw/ucwctl.conf is included (if present)
  2. $HOME/.ucw/ucwctl.conf is included (if present)
  3. if the option -u is used, the file specified is included if
     readable, otherwise exit with an error (you specify a file that
     doesn't exist or you cannot read?)
  4. all the variables specified via command line options overwrite the
     values in one of the three ucwctl config files

Nathan, I think this was what you asked for, right?  Do you (or other)
want to test the patch before inclusion?

Now, there're still some problems about the default values of 4
variables: $CONFIGFILE, $STARTFILE, $STOPFILE and $VARROOT.  These
should have a default value, because you should be able to call ucwctl
without any argument.  The possible options are:

  a) always default to the more general situation, i.e. /etc/ucw/files
     for the first three and /var for the last one.  If you want
     different locations, just customize $HOME/.ucw/ucwctl.conf.

  b) default to $HOME/.ucw/files and $HOME/var when $USER != root.  I
     don't understand why a root user wouldn't use the general
     /etc/ucw/files and /var.  If you develop your applications as
     root, you should seriously think to change ;-)

  c) a better solution than b) is to default to $HOME/.ucw/files only
     if these files exist, otherwise default to /etc/ucw/files.  For
     $VARROOT, the situation is the same as b), so default to
     $HOME/var if $USER != root (mostly because a normal user usually
     cannot create folder on /var).

I prefer solution a), but I'd like some comments before.

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/20060417/c0d767d4/attachment.sig>

From evrim at core.gen.tr  Mon Apr 17 01:47:32 2006
From: evrim at core.gen.tr (Evrim ULU)
Date: Mon, 17 Apr 2006 04:47:32 +0300
Subject: [Bese-devel] ucw:a & action parameters other than self
Message-ID: <4442F3B4.5060600@core.gen.tr>

Hi,

i'm trying to build a simple pager. When scroll-to-page action is
called, to-page parameter is always "number-of-pages", not the current
value of the iterator since loop increments the value of i. how can i
avoid this problem? i've tried :action `(scroll-to-page ,self ,i) but
didn't help :(

--- inside render ---
(loop
     for i from 1 to number-of-pages
     do
     (if (eq current-page i)
         (<:as-html i " ")
         (<ucw:a :action (scroll-to-page self i)
             :id (format nil "page-~A" i)
             (<:as-html i " "))))
---- render ends ---

(defaction scroll-to-page ((self pager) to-page)
 bla bla..)

kind regards,
evrim.



From evrim at core.gen.tr  Mon Apr 17 02:01:53 2006
From: evrim at core.gen.tr (Evrim ULU)
Date: Mon, 17 Apr 2006 05:01:53 +0300
Subject: [Bese-devel] ucw:a & action parameters other than self
In-Reply-To: <4442F3B4.5060600@core.gen.tr>
References: <4442F3B4.5060600@core.gen.tr>
Message-ID: <4442F711.6090006@core.gen.tr>

it seems below snippet solves the problem, don't sure if it is the best
solution in this case.

 (loop
     for i from 1 to number-of-pages
     do
     (if (eq current-page i)
         (<:as-html i " ")
         (eval `(<ucw:a :action (scroll-to-page ,self ,i)
                :id ,(format nil "page-~A" i)
                (<:as-html ,i " ")))))

>--- inside render ---
>(loop
>     for i from 1 to number-of-pages
>     do
>     (if (eq current-page i)
>         (<:as-html i " ")
>         (<ucw:a :action (scroll-to-page self i)
>             :id (format nil "page-~A" i)
>             (<:as-html i " "))))
>---- render ends ---
>
>(defaction scroll-to-page ((self pager) to-page)
> bla bla..)
>  
>



From mb at bese.it  Mon Apr 17 10:43:17 2006
From: mb at bese.it (Marco Baringer)
Date: Mon, 17 Apr 2006 12:43:17 +0200
Subject: [Bese-devel] Re: ucw:a & action parameters other than self
References: <4442F3B4.5060600@core.gen.tr>
Message-ID: <m24q0spjne.fsf@bese.it>

Evrim ULU <evrim at core.gen.tr> writes:

> Hi,
>
> i'm trying to build a simple pager. When scroll-to-page action is
> called, to-page parameter is always "number-of-pages", not the current
> value of the iterator since loop increments the value of i. how can i
> avoid this problem? i've tried :action `(scroll-to-page ,self ,i) but
> didn't help :(
>
> --- inside render ---
> (loop
>      for i from 1 to number-of-pages
>      do
>      (if (eq current-page i)
>          (<:as-html i " ")
>          (<ucw:a :action (scroll-to-page self i)
>              :id (format nil "page-~A" i)
>              (<:as-html i " "))))
> ---- render ends ---

the problem is (scroll-to-page self i). ucw:a creates a closure around
the action parameter, but loop creates exactly one binding and
modifies that during the iteration. for example:

(loop
  for i from 1 to number-of-pages
  collect (lambda () i))

this code will create number-of-pages' closure but calling them will
always return the same value since they close over the same binding
and that binding is modified. however this:

(loop
  for i from 1 to number-of-pages
  collect (let ((another-i i))
            (lambda () another-i)))

will create closures which reference a freshly created binding whose
inital value is the value i had at the time the closure was created
and therefore will return different values. (try out the code for
yourself if this doesn't make sense).

to make along story short what you want to use is this:

(loop
   for i from 1 to number-of-pages
   do (if (eq current-page i)
          (<:as-html i " ")
          (let ((i i))
            (<ucw:a :action (scroll-to-page self i)
                    :id (format nil "page-~A" i)
                    (<:as-html i " ")))))

notice the let form which creates a new binding on each iteration of
the loop.

-- 
-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 a_bakic at yahoo.com  Mon Apr 17 10:54:18 2006
From: a_bakic at yahoo.com (Aleksandar Bakic)
Date: Mon, 17 Apr 2006 03:54:18 -0700 (PDT)
Subject: [Bese-devel] ucw:a & action parameters other than self
In-Reply-To: <4442F711.6090006@core.gen.tr>
Message-ID: <20060417105419.10692.qmail@web38910.mail.mud.yahoo.com>

It seems to me that the problem with both could be that you need to rebind
variable i in order to make a new binding for each value. That is, wrap the do
expression in one (let ((i i)) ...).

Alex

--- Evrim ULU <evrim at core.gen.tr> wrote:

> it seems below snippet solves the problem, don't sure if it is the best
> solution in this case.
> 
>  (loop
>      for i from 1 to number-of-pages
>      do
>      (if (eq current-page i)
>          (<:as-html i " ")
>          (eval `(<ucw:a :action (scroll-to-page ,self ,i)
>                 :id ,(format nil "page-~A" i)
>                 (<:as-html ,i " ")))))
> 
> >--- inside render ---
> >(loop
> >     for i from 1 to number-of-pages
> >     do
> >     (if (eq current-page i)
> >         (<:as-html i " ")
> >         (<ucw:a :action (scroll-to-page self i)
> >             :id (format nil "page-~A" i)
> >             (<:as-html i " "))))
> >---- render ends ---
> >
> >(defaction scroll-to-page ((self pager) to-page)
> > bla bla..)
> >  
> >
> 
> _______________________________________________
> bese-devel mailing list
> bese-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From a_bakic at yahoo.com  Mon Apr 17 10:56:01 2006
From: a_bakic at yahoo.com (Aleksandar Bakic)
Date: Mon, 17 Apr 2006 03:56:01 -0700 (PDT)
Subject: [Bese-devel] ucw:a & action parameters other than self
In-Reply-To: <4442F711.6090006@core.gen.tr>
Message-ID: <20060417105601.55518.qmail@web38908.mail.mud.yahoo.com>

Actually, in your solution, you do not need to rebind as you evaluate i early
(and you said it worked :).

Alex

--- Evrim ULU <evrim at core.gen.tr> wrote:

> it seems below snippet solves the problem, don't sure if it is the best
> solution in this case.
> 
>  (loop
>      for i from 1 to number-of-pages
>      do
>      (if (eq current-page i)
>          (<:as-html i " ")
>          (eval `(<ucw:a :action (scroll-to-page ,self ,i)
>                 :id ,(format nil "page-~A" i)
>                 (<:as-html ,i " ")))))
> 
> >--- inside render ---
> >(loop
> >     for i from 1 to number-of-pages
> >     do
> >     (if (eq current-page i)
> >         (<:as-html i " ")
> >         (<ucw:a :action (scroll-to-page self i)
> >             :id (format nil "page-~A" i)
> >             (<:as-html i " "))))
> >---- render ends ---
> >
> >(defaction scroll-to-page ((self pager) to-page)
> > bla bla..)
> >  
> >
> 
> _______________________________________________
> bese-devel mailing list
> bese-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From mb at bese.it  Mon Apr 17 11:04:29 2006
From: mb at bese.it (Marco Baringer)
Date: Mon, 17 Apr 2006 13:04:29 +0200
Subject: [Bese-devel] Re: File upload problem
In-Reply-To: <d7ce4ebf0604170302s2e7bf2eevdb635cc013edb671@mail.gmail.com>
	(Ties Stuij's message of "Mon, 17 Apr 2006 12:02:54 +0200")
References: <44357C2F.7000203@core.gen.tr> <m2u09592r8.fsf@bese.it>
	<d7ce4ebf0604170302s2e7bf2eevdb635cc013edb671@mail.gmail.com>
Message-ID: <m2zmiko43m.fsf@bese.it>

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

> He marco,
>
> i was wondering: about a month ago you announced you were going to
> overhaul the plumbing of the internals in ucw_dev soon. Any idea when
> or if that is going to happen? I just bumped into a problem with some
> ajax-code making to many frames, which could be easily solved with the
> new internals as i understood.

it's all sitting in the ucw_request-dispatch branch (and has been for
a while even though i may not have publicived it enough). it's
prodcution ready code (i'm using for two of my main projects).

http://common-lisp.net/project/ucw/repos/ucw_request-dispatch

there are some conflicts between that and the current ucw_dev code. i
was planning on merging the two a week or so ago but now i'm going to
wait a bit more until the ucwctl stuff settles down.

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 attila.lendvai at gmail.com  Mon Apr 17 11:21:46 2006
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Mon, 17 Apr 2006 13:21:46 +0200
Subject: [Bese-devel] Re: ucw:a & action parameters other than self
In-Reply-To: <m24q0spjne.fsf@bese.it>
References: <4442F3B4.5060600@core.gen.tr> <m24q0spjne.fsf@bese.it>
Message-ID: <b54b34af0604170421x2beff632ref4448b85757358@mail.gmail.com>

>
> (loop
>   for i from 1 to number-of-pages
>   collect (let ((another-i i))
>             (lambda () another-i)))
>

i have this in my utils for this:

(defmacro rebind (bindings &body body)
  `(let (,@ (iter (for binding in bindings)
                  (collect (list binding binding))))
    , at body))

notice the difference between rebind and rebinding. the latter is already in
arnesi, and works when dealing with macros. the former is not in arnesi
(marco?) and useful when dealing with closures.

these binding issues are all around, i've sent a parenscript patch just a
day ago, that does what rebind above, but in js land.

- attila

(alias 101 on irc &no 'its not lisp code :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060417/b22aa80f/attachment.html>

From attila.lendvai at gmail.com  Mon Apr 17 15:55:11 2006
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Mon, 17 Apr 2006 17:55:11 +0200
Subject: [Bese-devel] Re: :component slots and places idea/question
In-Reply-To: <b54b34af0603131603o432a8546gf6f1465cb59effaf@mail.gmail.com>
References: <b54b34af0603110555s3c17f165l6fea2c4463649e50@mail.gmail.com>
	<m2slpn994d.fsf@bese.it>
	<b54b34af0603131603o432a8546gf6f1465cb59effaf@mail.gmail.com>
Message-ID: <b54b34af0604170855k122d6035jd5bc15f5b83c0314@mail.gmail.com>

On 3/14/06, Attila Lendvai <attila.lendvai at gmail.com> wrote:
>
> nice idea. i've commited something similar (to ucw_public for now,
> > i'll move it over to ucw_dev if it works for you).
> >
>
> thanks! i had to add a "(when new-value..." to guard setf'ing nil. but
> there's still some trouble: this code breaks in the debugger with sbcl in
> the early stage of serving the page (please note the break call/condition):
>
> (defmethod (setf mopp:slot-value-using-class) ((new-value
> standard-component)
>                                                (class
> standard-component-class)
>                                                (instance
> standard-component)
>                                                (slot-def
> standard-component-effective-slot))
>   ;; let the next method perform the acutal setf'ing
>   (call-next-method)
>   (unless (or (null new-value)
>               (typep new-value 'standard-component))
>     (break))
>   (when new-value
>     (setf (component.place new-value)
>           (make-place (mopp:slot-value-using-class class instance
> slot-def))))
>   new-value)
>

i've hacked it together... it turned out not to be as simple as it seemed.

i've used the boundp'ness of the component-slot.component slot to mark
effective slot definitions on which this functionality should be enabled.
without this wierd things were happening with backtracking and friends...

i don't fully understand everything around backtracking, so please take a
deeper look at it, but it works fine for me.

it's applied to the public repo.

- attila

(alias 101 on irc &no 'its not lisp code :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060417/fe37b614/attachment.html>

From luca at pca.it  Mon Apr 17 21:10:38 2006
From: luca at pca.it (Luca Capello)
Date: Mon, 17 Apr 2006 23:10:38 +0200
Subject: [Bese-devel] Re: Load a custom ucwctl.conf
In-Reply-To: <031901c66233$fa96d180$d80a0a0a@acceleration.net> (Nathan Bird's
	message of "Mon, 17 Apr 2006 11:31:20 -0400")
References: <031901c66233$fa96d180$d80a0a0a@acceleration.net>
Message-ID: <87irp7c3ht.fsf@gismo.pca.it>

Hi Nathan!

I'm answering to the list, I found your remarks interesting for
others, too.  I hope you don't mind ;-)

On Mon, 17 Apr 2006 17:31:20 +0200, Nathan Bird wrote:
>> [...] What happens, in order:
>>
>>  1. /etc/ucw/ucwctl.conf is included (if present)
>>  2. $HOME/.ucw/ucwctl.conf is included (if present)
>>  3. if the option -u is used, the file specified is included if
>>     readable, otherwise exit with an error (you specify a file that
>>     doesn't exist or you cannot read?)
>>  4. all the variables specified via command line options overwrite
>>     the values in one of the three ucwctl config files
>
> I like the look of that. Am I correctly interpreting that options
> set in later steps override the earlier ones, or is that just the
> command line ones in step 4?

Yes, you're correct in your interpretation.  If you've both
/etc/ucw/ucwctl.conf and $HOME/.ucw/ucwctl.conf, the latter overrides
the former, but only for values that are set in the latter.

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

  $ cd /path/to/ucw_dev/bin
  $ gunzip -c /path/to/file | patch

As soon as it will be confirmed to work as expected, I'll commit to
ucw_dev.

> With all the other configurability, having a systemwide startup
> doesn't worry me anymore. Why a user wouldn't want to use the
> default /var is if he is running two instances of UCW at once (which
> I have done a few times, but not commonly), or two users are running
> it at once (frequently). Won't they collide on the pid/socket files?

The first problem with the default /var is that a normal user cannot
create files/folders in it, so I think we need to default to $HOME/var
for a normal user when $VARROOT is empty (already present in the
attached patch).  In case an user (root or not) want to start two
instances, he needs to specify the necessary variables.

The other problem is the one you pointed out: with the default values
(and with the commands ucwctl uses), if you start two processes
they'll try to share the same socket (impossible) and log files
(undesirable).  So, we need to modify how we create sockets, pid and
log files.

IMHO the better solution will be to check if the socket is present
before parsing the command parameter (so, after having parsed all the
variables).  If it's present, the script will exit with an error,
otherwise it'll continue.  Waiting for comments...  :-)

Another option we can add is the ability to use ucwctl without
detachtty, something like -d or --no-detachtty: it starts UCW via
cl-launch, but on the same terminal you are.  Could it be useful?

Thx, bye,
Gismo / Luca

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ucwctl_ucwctl-config_20060417.patch.gz
Type: application/octet-stream
Size: 1082 bytes
Desc: first implementation of the custom ucwctl.conf option
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060417/0ce18969/attachment.obj>
-------------- 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/20060417/0ce18969/attachment.sig>

From nathan at acceleration.net  Tue Apr 18 01:44:56 2006
From: nathan at acceleration.net (Nathan Bird)
Date: Mon, 17 Apr 2006 21:44:56 -0400
Subject: [Bese-devel] Re: Load a custom ucwctl.conf
In-Reply-To: <87irp7c3ht.fsf@gismo.pca.it>
Message-ID: <038401c66289$b2b62180$d80a0a0a@acceleration.net>

Side note: Does stop.lisp still exist? Is it supposed to, browsing the
darcsweb version of ucw_dev, the file is gone from ucw_dev/etc, but ucwctl
is still making sure one exists somewhere. (I commented that out for the
second). The patch comments of late seem to be leaning towards removing it?

>The first problem with the default /var is that a normal user cannot
>create files/folders in it, so I think we need to default to $HOME/var
>for a normal user when $VARROOT is empty (already present in the
>attached patch).  In case an user (root or not) want to start two
>instances, he needs to specify the necessary variables.
>
>The other problem is the one you pointed out: with the default values
>(and with the commands ucwctl uses), if you start two processes
>they'll try to share the same socket (impossible) and log files
>(undesirable).  So, we need to modify how we create sockets, pid and
>log files.
>
>IMHO the better solution will be to check if the socket is present
>before parsing the command parameter (so, after having parsed all the
>variables).  If it's present, the script will exit with an error,
>otherwise it'll continue.  Waiting for comments...  :-)
>
>Another option we can add is the ability to use ucwctl without
>detachtty, something like -d or --no-detachtty: it starts UCW via
>cl-launch, but on the same terminal you are.  Could it be useful?
>

I like the idea of --no-detachtty, but running a second command for attach
isn't too bad in the meantime.

In my global ucwctl.conf I am currently specifying only the lisp="SBCL" and
the global start.lisp. I then try to launch it with ./ucwctl -c
../etc/conf.lisp start. This tries to get everything going. It looks like it
is correctly using the $HOME/var.

Aside from that observation it is hard to test out the rest of the
combinations because I still have the same (similar? Not sure) other
problems...

When I try to run it with cl-launch it seems to get as far as trying to
start the backend before complaining that trivial-sockets:open-server is
undefined[0]. But I then can't inspect anymore because of
--disable-debugger. I've tried removing all reference to
"--disable-debugger" in cl-launch that I could find, but apparently that
wasn't enough :-(

For reference, from ucw_dev/etc/, "CONFIGFILE=conf.lisp VARROOT=~ sbcl
--load start.lisp" does work just fine.

As far as I can tell cl-launch is doing its damnedest to mess up every
assumption I have ever made about how to startup lisp :-). <Nathan repeats
"With broken assumptions comes learning" ten times>.


[0]: Asdf didn't complain that it couldn't find that package, so I don't
think that is the problem. It only has a problem when it tries to call the
function:
0:33 UCW-LOGGER/+INFO+: Starting up standard server #<STANDARD-SERVER
MULTITHREAD-HTTPD-BACKEND 2 {B7981A9}>.
unhandled SIMPLE-ERROR in thread #<SB-THREAD:THREAD "initial thread"
{A68D4A9}>:
  Error during processing of --eval option
"(progn(set-dispatch-macro-character #\\# #\\! #'(lambda(stream char
arg)(declare(ignore char arg))(values (read-line stream))))(load
\"/usr/bin/cl-launch\" :verbose nil :print nil)
(funcall(intern(string :run):cl-launch) :init \"(load (pop
cl-launch:*arguments*))\" :quit nil))":

  The function TRIVIAL-SOCKETS:OPEN-SERVER is undefined.


I'm pretty sure that there is only one copy of trivial-sockets on the
system. It is linked into sbcl/site-systems.

I got homework that isn't getting done, I need to go procrastinate more
directly on that. I'll try again tomorrow.

Nathan



From mbaringer at common-lisp.net  Tue Apr 18 04:20:02 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Tue, 18 Apr 2006 00:20:02 -0400 (EDT)
Subject: [Bese-devel] New patches to parenscript: 17-Apr-2006
Message-ID: <20060418042002.D227B5E003@common-lisp.net>


Sun Apr 16 14:18:25 EDT 2006  attila.lendvai at gmail.com
  * Added a rebind js macro that rebinds variables on the js side

    M ./src/js.lisp +14


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

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


From mbaringer at common-lisp.net  Tue Apr 18 04:30:03 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Tue, 18 Apr 2006 00:30:03 -0400 (EDT)
Subject: [Bese-devel] New patches to ucw_dev: 17-Apr-2006
Message-ID: <20060418043003.6DFC963022@common-lisp.net>


Mon Apr 17 17:26:38 EDT 2006  Luca Capello <luca at pca.it>
  * bin/ucwctl: add forgotten -t in help and manual page

    M ./bin/ucwctl -1 +1
    M ./bin/ucwctl.1 -2 +2

Mon Apr 17 11:42:42 EDT 2006  attila.lendvai at gmail.com
  * Automatically set the component.place slot when putting a component in a :component marked slot of another component
  
  When doing this:
  
  (defcomponent ...
    ((foo :component nil)))
  
  (setf (slot-value ... 'foo) (make-instance 'another-component))
  
  UCW will automatically set the component.place slot of the component being put in the :component marked slots.

    M ./src/rerl/standard-component/standard-component-class.lisp -10 +17
    M ./src/rerl/standard-component/standard-component.lisp +11

Sun Apr 16 06:52:20 EDT 2006  attila.lendvai at gmail.com
  * Added icon support to window-component

    M ./src/components/window.lisp -1 +9
    M ./src/packages.lisp +1

Wed Apr  5 05:02:41 EDT 2006  attila.lendvai at gmail.com
  * Removed make-list-container and instead added an initialize-instance that converts :contents when needed

    M ./src/components/container.lisp -8 +10

Tue Apr  4 10:39:17 EDT 2006  attila.lendvai at gmail.com
  * Added make-list-container that expects a simple list of components in :contents

    M ./src/components/container.lisp +6
    M ./src/packages.lisp +1

Sun Mar 19 16:55:55 EST 2006  attila.lendvai at gmail.com
  * Refactored container.lisp
  
  Renamed simple-container to switching-container, clearly separated the base
  container class functionality from the new switching container. After the
  refactor it is easier to use switching-container with dynamically
  generated content and in situations where the old 'label' property have
  no useful meaning (e.g. dinamically built tab pane). By default the new 'key'
  property is the component itself.
  
  User API changes (exported symbols):
   - simple-container -> switching-container
   - container.label-test -> container.key-test (also the initarg)
   - container.current-component-name -> container.current-component-key (also the initarg)
  
  Generally 'label' has been renamed to 'key' in container, and switching-container
  implementation is based on the component accessing functionality provided by container.
  

    M ./examples/examples.lisp -2 +2
    M ./src/components/container.lisp -72 +95
    M ./src/packages.lisp -3 +4

Tue Apr  4 11:39:33 EDT 2006  Nathan Bird <nathan at acceleration.net>
  * RFC2109 doesn't like nil
  rfc2109:parse-cookies doesn't like trying to parse out of a nil string.
  But in the function that calls it, we can determine this early and skip
  doing some extra work.

    M ./src/rerl/cookie-session.lisp -6 +7

Tue Apr  4 11:29:00 EDT 2006  Nathan Bird <nathan at acceleration.net>
  * Allegro multiprocessing

    M ./src/control.lisp -1 +3

Mon Apr 17 06:49:44 EDT 2006  Marco Baringer <mb at bese.it>
  * merge conflicts with russ at acceleration.net's last patch

    M ./src/components/form.lisp -15 +16
    M ./src/packages.lisp -2 +12

Mon Mar 13 10:20:49 EST 2006  russ at acceleration.net
  * added generic number field (to allow for number validation instead of integer validation) Integer nopw inherits from number

    M! ./src/components/form.lisp -17 +57
    M! ./src/packages.lisp -11 +3


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

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


From luca at pca.it  Tue Apr 18 08:15:48 2006
From: luca at pca.it (Luca Capello)
Date: Tue, 18 Apr 2006 10:15:48 +0200
Subject: [Bese-devel] Re: Load a custom ucwctl.conf
In-Reply-To: <038401c66289$b2b62180$d80a0a0a@acceleration.net> (Nathan Bird's
	message of "Mon, 17 Apr 2006 21:44:56 -0400")
References: <038401c66289$b2b62180$d80a0a0a@acceleration.net>
Message-ID: <87ejzvb8p7.fsf@gismo.pca.it>

Hello!

On Tue, 18 Apr 2006 03:44:56 +0200, Nathan Bird wrote:
> Side note: Does stop.lisp still exist? Is it supposed to, browsing
> the darcsweb version of ucw_dev, the file is gone from ucw_dev/etc,
> but ucwctl is still making sure one exists somewhere. (I commented
> that out for the second). The patch comments of late seem to be
> leaning towards removing it?

Ehm...  My mistake, I forgot to `darcs add`.  A patch is in the repo.

> I like the idea of --no-detachtty, but running a second command for
> attach isn't too bad in the meantime.

Well, I intend the --no-detachtty option as unusual: you want to test
a particular case and you don't want to type a second command to
attach.  This could be useful to perform the first test when you
install/grab all the necessary dependencies, too (as Ties suggests in
the README).

And obviously this is not the default situation...

> In my global ucwctl.conf I am currently specifying only the
> lisp="SBCL" and the global start.lisp. I then try to launch it with
> ./ucwctl -c ../etc/conf.lisp start. This tries to get everything
> going. It looks like it is correctly using the $HOME/var.

That's good :-)

> Aside from that observation it is hard to test out the rest of the
> combinations because I still have the same (similar? Not sure) other
> problems...

OK, let us try to solve them.

> When I try to run it with cl-launch it seems to get as far as trying
> to start the backend before complaining that
> trivial-sockets:open-server is undefined[0]. But I then can't
> inspect anymore because of --disable-debugger. I've tried removing
> all reference to "--disable-debugger" in cl-launch that I could
> find, but apparently that wasn't enough :-(

Could you report this bug in cl-launch (the --disable-debugger thing)
to its author?  His e-mail address is the cl-launch headers ;-)

For the trivial-sockets problem, see below.

> For reference, from ucw_dev/etc/, "CONFIGFILE=conf.lisp VARROOT=~
> sbcl --load start.lisp" does work just fine.

That's strange...  Do you specify VARROOT= or LOGROOT=?  I guess the
latter, because this is the variable src/default.lisp try to get:

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

Anyway, it seems to work as expected :-)

> As far as I can tell cl-launch is doing its damnedest to mess up
> every assumption I have ever made about how to startup lisp
> :-). <Nathan repeats "With broken assumptions comes learning" ten
> times>.

It seems that the tests I made before committing my patch weren't
enough...  :-(

> [0]: Asdf didn't complain that it couldn't find that package, so I
[...]
> I'm pretty sure that there is only one copy of trivial-sockets on
> the system. It is linked into sbcl/site-systems.

Is your trivial-sockets version up-to-date with upstream?  I remember
I had problems with trivial-sockets and sbcl, then solved by version
0.3.

I just tried to fire up UCW on another machine (Debian, but no c-l-c)
and it works with no problem (ucw with my latest patch, detachtty and
cl-launch).

> [...] I'll try again tomorrow.

I'll wait for your feedbacks ;-)

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/20060418/cc1ab3cb/attachment.sig>

From nathan at acceleration.net  Tue Apr 18 21:15:21 2006
From: nathan at acceleration.net (Nathan Bird)
Date: Tue, 18 Apr 2006 17:15:21 -0400
Subject: [Bese-devel] Re: Load a custom ucwctl.conf
In-Reply-To: <87ejzvb8p7.fsf@gismo.pca.it>
Message-ID: <042501c6632d$33d011b0$d80a0a0a@acceleration.net>


>It seems that the tests I made before committing my patch weren't
>enough...  :-(
>[...]
>
>Is your trivial-sockets version up-to-date with upstream?  I remember
>I had problems with trivial-sockets and sbcl, then solved by version
>0.3.
>
>I just tried to fire up UCW on another machine (Debian, but no c-l-c)
>and it works with no problem (ucw with my latest patch, detachtty and
>cl-launch).

Finally got it to work. The most likely culprit as near as I can tell is
SBCL 0.9.10. I updated to 0.9.11 this morning and now it works! It might
have had to do with recompiling all of the fasls, not sure. 

Just curious if any of the test setups you tried are SBCL 0.9.10? you might
be able to confirm or deny whether the SBCL version was the culprit. I
hadn't thought one minor version number of SBCL was going to make that big
of a difference which was why I hadn't updated yet. 

I did also update a number of other packages, but trivial-sockets was
already the most recent darcs from verisons.telent.net (tagged release_0_3).


Odd, but hopefully now resolved. Thanks for all the help.
Nathan



From luca at pca.it  Tue Apr 18 21:23:27 2006
From: luca at pca.it (Luca Capello)
Date: Tue, 18 Apr 2006 23:23:27 +0200
Subject: [Bese-devel] Re: Load a custom ucwctl.conf
References: <031901c66233$fa96d180$d80a0a0a@acceleration.net>
	<87irp7c3ht.fsf@gismo.pca.it>
Message-ID: <87lku27f3k.fsf@gismo.pca.it>

Hello!

On Mon, 17 Apr 2006 23:10:38 +0200, Luca Capello wrote:
> The first problem with the default /var is that a normal user cannot
> create files/folders in it, so I think we need to default to
> $HOME/var for a normal user when $VARROOT is empty (already present
> in the attached patch).  In case an user (root or not) want to start
> two instances, he needs to specify the necessary variables.

I committed a patch that do exactly the above: it defaults to
$HOME/var if $USER = "root" and this check should be POSIX-compliant,
not only bash-compliant ;-)

> The other problem is the one you pointed out: with the default
> values (and with the commands ucwctl uses), if you start two
> processes they'll try to share the same socket (impossible) and log
> files (undesirable).  So, we need to modify how we create sockets,
> pid and log files.

Actually, this is not needed, because detachtty refuses to start:
=====
gismo at innerloop:~$ sh ucwctl start

gismo at innerloop:~$ tail -n 5 var/log/ucw/ucw.dribble
STYLE-WARNING: implicitly creating new generic function \
 MAKE-WORKER
STYLE-WARNING: implicitly creating new generic function \
 PENDING-REQUEST-VALIDP
--TIME MARK 2006-04-18--
22:52 UCW-LOGGER/+INFO+: Starting up standard server \
 #<STANDARD-SERVER MULTITHREAD-HTTPD-BACKEND 3 {B705791}>.
*

gismo at innerloop:~$ sh ucwctl start
;;; detachtty: 1145393675: Is "/home/gismo/var/run/ucw/ucw.socket" \
 a dead socket from a previous run?

;;; detachtty: 1145393675: FATAL bind (Address already in use)
ucwctl: line 248:  8775 Terminated              $DETACHTTY
--dribble-file "$LOGROOT"/ucw.dribble --log-file
"$LOGROOT"/ucw.detachtty --pid-file "$RUNROOT"/ucw.pid
"$RUNROOT"/ucw.socket $CLLAUNCH -X $OPT_LISP $OPT_PATH NO_QUIT=yes --
"$STARTFILE"
gismo at innerloop:~$
=====

I corrected the ugly output above ("$FOLDER"/file), sorry for the
first not-styled patch :-(

> Another option we can add is the ability to use ucwctl without
> detachtty, something like -d or --no-detachtty: it starts UCW via
> cl-launch, but on the same terminal you are.  Could it be useful?

With this option, obviously, we need to create a false socket and pid,
so we can know if another process is running.

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/20060418/9b4e69f5/attachment.sig>

From luca at pca.it  Tue Apr 18 21:40:58 2006
From: luca at pca.it (Luca Capello)
Date: Tue, 18 Apr 2006 23:40:58 +0200
Subject: [Bese-devel] Re: Load a custom ucwctl.conf
References: <87ejzvb8p7.fsf@gismo.pca.it>
	<042501c6632d$33d011b0$d80a0a0a@acceleration.net>
Message-ID: <874q0q7ead.fsf@gismo.pca.it>

Hi Nathan!

On Tue, 18 Apr 2006 23:15:21 +0200, Nathan Bird wrote:
>> I just tried to fire up UCW on another machine (Debian, but no c-l-c)
>> and it works with no problem (ucw with my latest patch, detachtty and
>> cl-launch).
>
> Finally got it to work. The most likely culprit as near as I can
> tell is SBCL 0.9.10. I updated to 0.9.11 this morning and now it
> works! It might have had to do with recompiling all of the fasls,
> not sure.

Very good news!

> Just curious if any of the test setups you tried are SBCL 0.9.10?

Yes, I tested with SBCL 0.9.9, 0.9.9.11, 0.9.10 and 0.9.11, all of
them worked and they didn't give your problem, sorry :-(

> Odd, but hopefully now resolved. Thanks for all the help.

You're welcome :-)

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/20060418/fe053baa/attachment.sig>

From mbaringer at common-lisp.net  Wed Apr 19 04:30:04 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Wed, 19 Apr 2006 00:30:04 -0400 (EDT)
Subject: [Bese-devel] New patches to ucw_dev: 18-Apr-2006
Message-ID: <20060419043004.BC4AF30000@common-lisp.net>


Tue Apr 18 17:19:44 EDT 2006  Luca Capello <luca at pca.it>
  * bin/ucwctl: use "$FOLDER/file" instead of the ugly "$FOLDER"/file

    M ./bin/ucwctl -15 +15

Tue Apr 18 17:09:29 EDT 2006  Luca Capello <luca at pca.it>
  * bin/ucwctl: escape with double (not single) quotes $ASDFROOT

    M ./bin/ucwctl -1 +1

Tue Apr 18 16:28:07 EDT 2006  Luca Capello <luca at pca.it>
  * bin/ucwctl: default $VARROOT to $HOME/var for a normal user
  
  Usually, a normal user (i.e. a non-root one) cannot write to /var, so
  the script exit with an error with the default values.
  
  This patch adds another check for $VARROOT: when it's empty or it's
  set to the default value (/var), it checks the value of $USER and if
  this is different to "root", it sets $VARROOT to $HOME/var instead.
  
    http://common-lisp.net/pipermail/bese-devel/2006-April/001952.html
    http://common-lisp.net/pipermail/bese-devel/2006-April/001961.html

    M ./bin/ucwctl -2 +12
    M ./bin/ucwctl.1 -3 +15
    M ./etc/ucwctl.conf -2 +2

Tue Apr 18 15:55:33 EDT 2006  Luca Capello <luca at pca.it>
  * bin/ucwctl.1: use italics instead of bold for FILES

    M ./bin/ucwctl.1 -9 +9

Tue Apr 18 15:29:34 EDT 2006  Luca Capello <luca at pca.it>
  * bin/ucwctl: use the appropriate test expression

    M ./bin/ucwctl -3 +3

Tue Apr 18 13:44:53 EDT 2006  Luca Capello <luca at pca.it>
  * bin/ucwctl: deal with files/directory with spaces

    M ./bin/ucwctl -23 +23

Tue Apr 18 03:21:21 EDT 2006  Luca Capello <luca at pca.it>
  * etc/stop.lisp: add forgotten file
  
  I forgotten to add it when I committed the patch "bin/ucwctl: stop UCW
  reading etc/stop.lisp".
  
  Thank Nathan Bird to have pointed it out:
  
    http://common-lisp.net/pipermail/bese-devel/2006-April/001962.html

    A ./etc/stop.lisp


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

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


From attila.lendvai at gmail.com  Wed Apr 19 12:13:46 2006
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Wed, 19 Apr 2006 14:13:46 +0200
Subject: [Bese-devel] request dispatching
In-Reply-To: <m21wx796vr.fsf@bese.it>
References: <m21wx796vr.fsf@bese.it>
Message-ID: <b54b34af0604190513w1e78b2b0m5fb189a82aaaa94d@mail.gmail.com>

> - it is now possible, but i haven't done it yet, to create a
>   dispatcher which avoids creating frames and backtracking (think ajax
>   or home pages).
>

i would be very happy to see some changes around the new request-dispatch
branch and ajax stuff. i merged the dev and the request-dispatch branches
locally (two trivial conflicts only) and tried to do some ajax stuff with
it. i managed to refresh a generated image but only as a proof of concept.
later i saw that things are missing in ucw that i can't write high quality
enough to be committable (iow, to be worth it).

as i saw what is missing is an easy way to create an ajax action-href that,
when triggered, runs in the same session and frame where it was created.
this is realtively easy to do, but i'm not sure what i'm talking about, so i
better stop right now and go back reading... :)

- attila

(alias 101 on irc &no 'its not lisp code :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060419/e3d9d3a4/attachment.html>

From evrim at core.gen.tr  Wed Apr 19 14:37:20 2006
From: evrim at core.gen.tr (Evrim ULU)
Date: Wed, 19 Apr 2006 17:37:20 +0300
Subject: [Bese-devel] action-dispatcher & defentry-point
Message-ID: <44464B20.5080406@core.gen.tr>

Hi,

I've been reading request-dispatch code and saw a warning which reads:

;;;; ** ACTION-DISPATCHER

;;;; This is the core dispatcher for ucw. Due to how ucw's compute-url
;;;; method works it is important that the action-dispatcher be
;;;; checked before any url-dispatchers, so it sholud be the first
;;;; element in an application's dispatcher list.

We've built a portal-base to register all applications to it like an app
pool and implemented apache vhost/ucw/db start/stop/zap functions just
like sysv initrc. Sometimes we need to override old entry-points via
recalling defentry-point.  I've seen new defentry point removes the old
entry point and appends it. Shouln't it do a prepend? I know it removes
the same entry point having the same class and url string but it's
possible to have an entry-point say, standart-entry-point overriden with
a regexp-entry-point. In that case, defentry-point wouldn't be
overriding the old entry -point and since  class'es are different,  and
old entry -point will show since dispatcher will dispatch the first one
it sees (i saw, returning t from dispatch yields end of service). In
fact, i must admit, there hasn't got to be two entry-points having the
same url string, so we may drop the class-name check and depend only on
url string.

I didin't test it since i've got repo today:(

Kind Regards,
Evrim.


From evrim at core.gen.tr  Thu Apr 20 00:52:53 2006
From: evrim at core.gen.tr (Evrim ULU)
Date: Thu, 20 Apr 2006 03:52:53 +0300
Subject: [Bese-devel] expiring frames & ajax
Message-ID: <4446DB65.6050003@core.gen.tr>

Dear Marco,

I've been playing around with my previous ajax implementation and it
seems, my frames are expiring due to lru-queue. Do you have any
suggestions about this? I couldn't made up a solution other than using a
normal queue which will i suppose, increase memory consumption per
single client. Any memory statistics about this would be appriciated.

King Regards,
Evrim.


From evrim at core.gen.tr  Thu Apr 20 02:01:18 2006
From: evrim at core.gen.tr (Evrim ULU)
Date: Thu, 20 Apr 2006 05:01:18 +0300
Subject: [Bese-devel] rendering permalinks
Message-ID: <4446EB6E.1060300@core.gen.tr>

Hi,

Do we have something in yaclml to render permalinks? I'm not feeling
comfortable with :href (format nil "user.ucw?id=~A" id) , maybe
something like (<ucw:a :href (href :base "user.ucw" :id id)  ....would
do better. Or am I missing another great treasure found in ucw? :)

kind regards,
evrim.


From frido at q-software-solutions.de  Thu Apr 20 07:19:50 2006
From: frido at q-software-solutions.de (Friedrich Dominicus)
Date: Thu, 20 Apr 2006 09:19:50 +0200
Subject: [Bese-devel] Meaning of   <param:contents> ?
Message-ID: <878xq0vhm1.fsf@flarge.here>

Ok, what's the task of this tag?

Regards
Friedrich


From mb at bese.it  Thu Apr 20 11:16:51 2006
From: mb at bese.it (Marco Baringer)
Date: Thu, 20 Apr 2006 13:16:51 +0200
Subject: [Bese-devel] Re: expiring frames & ajax
References: <4446DB65.6050003@core.gen.tr>
Message-ID: <m2k69kpkd8.fsf@bese.it>

Evrim ULU <evrim at core.gen.tr> writes:

> Dear Marco,
>
> I've been playing around with my previous ajax implementation and it
> seems, my frames are expiring due to lru-queue. Do you have any
> suggestions about this? I couldn't made up a solution other than using a
> normal queue which will i suppose, increase memory consumption per
> single client. Any memory statistics about this would be appriciated.

i don't believe it's neccessary for ajax frames to create a new
frame. here's some code which runs an action within the same frame as
the one that created it (just like action-dispatcher' dispatch method
except for a one line change).

(defmethod dispatch ((dispatcher ajax-dispatcher)
                     (application standard-application)
                     (context standard-request-context))
  (when-bind session (find-session application context)
    (setf (context.session context) session
          (session.last-access session) (get-universal-time))
    (ucw.rerl.dispatcher.dribble "Found session ~S." session)
    (when-bind frame-id (find-frame-id context)
      (ucw.rerl.dispatcher.dribble "Found frame-id ~S." frame-id)
      (when-bind frame (find-frame-by-id session frame-id)
        (ucw.rerl.dispatcher.dribble "Found frame ~S." frame)
        (when-bind action (find-action frame (find-action-id context))
          (ucw.rerl.dispatcher.dribble "ACTION-DISPATCHER matched, calling action ~S." action)
          (setf (session.current-frame session) frame)
          (reinstate-backtracked frame)
          (call-callbacks frame (context.request context))
;;          (make-new-frame (context.session context))
          (with-action-error-handler () 
            (funcall action))
          (render-loop (frame.window-component (context.current-frame *context*)))
          (save-backtracked (context.current-frame *context*))
          t)))))

just uncomment the call to make-new-frame and ajax requests won't
affect the queue. the real question, and i'd love your feedback on
this, is how to tell if an action is an ajax action or not. hawe you
seen the ajax code which has been floating around? (sorry, i can't
remeber atm who wrote 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 mb at bese.it  Thu Apr 20 11:12:00 2006
From: mb at bese.it (Marco Baringer)
Date: Thu, 20 Apr 2006 13:12:00 +0200
Subject: [Bese-devel] Re: action-dispatcher & defentry-point
References: <44464B20.5080406@core.gen.tr>
Message-ID: <m2odywpklb.fsf@bese.it>

Evrim ULU <evrim at core.gen.tr> writes:

> Hi,
>
> I've been reading request-dispatch code and saw a warning which reads:
>
> ;;;; ** ACTION-DISPATCHER
>
> ;;;; This is the core dispatcher for ucw. Due to how ucw's compute-url
> ;;;; method works it is important that the action-dispatcher be
> ;;;; checked before any url-dispatchers, so it sholud be the first
> ;;;; element in an application's dispatcher list.
>
> We've built a portal-base to register all applications to it like an app
> pool and implemented apache vhost/ucw/db start/stop/zap functions just
> like sysv initrc. Sometimes we need to override old entry-points via
> recalling defentry-point.  I've seen new defentry point removes the old
> entry point and appends it. Shouln't it do a prepend? I know it removes
> the same entry point having the same class and url string but it's
> possible to have an entry-point say, standart-entry-point overriden with
> a regexp-entry-point. In that case, defentry-point wouldn't be
> overriding the old entry -point and since  class'es are different,  and
> old entry -point will show since dispatcher will dispatch the first one
> it sees (i saw, returning t from dispatch yields end of service). In
> fact, i must admit, there hasn't got to be two entry-points having the
> same url string, so we may drop the class-name check and depend only on
> url string.

it does an append because a prepend would, in my situation, hide the
action-dispatcher. i hadn't really considered the situation where you
have a url dispatcher on "foo" and want to redefine it as a regexp
dispatcher on "f.*", nor do i really think the effort involved in
having that 'just work' would be worth the gain (i do think that there
are occasions where delete-package followed by asdf:load-op is the
best solution, and this looks like on of them).

my current problems with defentry-point are do liking this setup:

an action-dispatcher (which must be first on the dipatcher list), a
list of entry-points and finally a tal-dispatcher. i don't know how to
make defentry-point figure out what it should do in this case. nor do
i want to complicate standard-application with multiple slots for
different kinds of dispatchers.

one thing i have though about doing is adding a :priority keyword to
dispatchers. when adding a new dispatcher to an app we insert it after
all dispatchers with a higher priority. so, in my case, i could give
the action-dispatcher a priority of 0, the tal-dispatcher a priority
of most-negative-fixnum and do whatever looks best for the normal
entry-points. comemnts?

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



From mb at bese.it  Thu Apr 20 11:21:32 2006
From: mb at bese.it (Marco Baringer)
Date: Thu, 20 Apr 2006 13:21:32 +0200
Subject: [Bese-devel] Re: rendering permalinks
References: <4446EB6E.1060300@core.gen.tr>
Message-ID: <m2fyk8pk5f.fsf@bese.it>

Evrim ULU <evrim at core.gen.tr> writes:

> Hi,
>
> Do we have something in yaclml to render permalinks? I'm not feeling
> comfortable with :href (format nil "user.ucw?id=~A" id) , maybe
> something like (<ucw:a :href (href :base "user.ucw" :id id)  ....would
> do better. Or am I missing another great treasure found in ucw? :)

not atm, but this would probably be a great addition:

(defun href (base &rest params)
  (with-output-to-string (href)
    (write-string base href)
    (when params
      (write-char #\? href)
      (loop
        for (key value . rest) on params by #'cddr
        do (arnesi:write-as-uri key href)
        do (write-char #\= href)
        do (arnesi:write-as-uri value href)
        when rest
          do (write-char #\& href)))))

which you'd use like so:

(<ucw:a :href (href "foo.ucw" :bar "42"))

-- 
-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  Thu Apr 20 12:04:33 2006
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Thu, 20 Apr 2006 14:04:33 +0200
Subject: [Bese-devel] i18n-application and cl-l10n integration
Message-ID: <b54b34af0604200504u3a697b01ye24fbce8d79bdd17@mail.gmail.com>

hi!

if there are no objections i'll integrate i18n-application and cl-l10n
and send a patch. it will introduce a cl-l10n dependency, but i think
it's ok. especially with the cl-l10n patches levy have in store that
helps with localization a lot. (functions with implicit dispatch on
*locale*)

- attila

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

From mb at bese.it  Thu Apr 20 12:43:33 2006
From: mb at bese.it (Marco Baringer)
Date: Thu, 20 Apr 2006 14:43:33 +0200
Subject: [Bese-devel] Re: Meaning of   <param:contents> ?
References: <878xq0vhm1.fsf@flarge.here>
Message-ID: <m2u08omn7u.fsf@bese.it>

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

> Ok, what's the task of this tag?

it's part of the tal:include mechanism, it provides one mechanism
(there are two) to pass data from the including page to the included
page.

example:

let's pretend we have template.tal (this is very similar to an actual
tal file of mine):

------------------------------------------------------------------------
<html>
  <head>
    <title tal:content="$title">title goes here</title>
  </head>
</html>
------------------------------------------------------------------------

notice how the template access the title variable. param: tags and
attributes are the means to extend the included pages'
environement. here's index.tal which uses this template:

------------------------------------------------------------------------
<tal:include tal:name="template.tal">
  <param:title><b>home</b> page</param:title>
</tal:include>
------------------------------------------------------------------------

when calling template.tal the current environemnt (whetever was used
for index.tal) will be extended with the symbol title (the string
"TITLE" will be interned in index.tal's package) bound to the content
of the param:title tag. (nb: had the tag param:foobar been used we
would be binding the symbol foobar and not title). for param: tags the
content of the tag is 'evaluated' immediatly and the resulting string
is used as the value. in this case title would be bound to the string
"<b>home</b> page".

so, that's the first mechanism, the problem is that it's limited to
pasing text to the included template. it often happens that we want to
pass lisp objects. if we use a param: _attribute_, like this:

------------------------------------------------------------------------
<tal:include tal:name="template.tal" param:foo="(slot-value $component 'foo)">
  <param:title><b>home</b> page</param:title>
</tal:include>
------------------------------------------------------------------------

then the symbol foo will be bound to the value returned by the form
(slot-value $component 'foo). i use this mechanism with tal:dolist
when i have three tables on different pages which show the same data
but on different objects.

while i'm on the subject:

tal:name worked great for a really long time (about 2 years) but
recently i needed to include different files depending on user
input. i've recently added a tal:name-expression attribute. it has the
same effect as tal:name (chooses which template to include) but
'evaluates' its value:

<tal:include tal:name-expression="details/${ (class-name (class-of (datum $component))) }"
             param:datum="(datum $component)"/>

this will include a different file in the details directory, depending
on the class of the datum slot, and pass the datum object itself to
the included file.

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 mb at bese.it  Thu Apr 20 12:44:04 2006
From: mb at bese.it (Marco Baringer)
Date: Thu, 20 Apr 2006 14:44:04 +0200
Subject: [Bese-devel] Re: i18n-application and cl-l10n integration
References: <b54b34af0604200504u3a697b01ye24fbce8d79bdd17@mail.gmail.com>
Message-ID: <m2psjcmn6z.fsf@bese.it>

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

> hi!
>
> if there are no objections i'll integrate i18n-application and cl-l10n
> and send a patch. it will introduce a cl-l10n dependency, but i think
> it's ok. especially with the cl-l10n patches levy have in store that
> helps with localization a lot. (functions with implicit dispatch on
> *locale*)

i won't object.

-- 
-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  Thu Apr 20 18:44:04 2006
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Thu, 20 Apr 2006 20:44:04 +0200
Subject: [Bese-devel] forms patch in the public repo
Message-ID: <b54b34af0604201144u1bf21345s496c420f419fa961@mail.gmail.com>

hi!

i've made some changes to how forms work. mainly around the default
action and pressing enter in form fields. it's in the public repo...

it works fine with mozilla except that now the <ucw:input tag is
called with :default t, then it renders a <ucw:script tag right after
the input tag. (to set the form's action parameter) and it may screw
up rendering in some situations (as it does for me with an ul/li tree
with display:table/table-row css)

anybody has some idea how to prevent this? first mozilla should simply
work... :) but a global js store would also help, where js fragments
could be recorded while rendering and at the end of the page would be
emitted into a <script> tag. but this is a bit hackish only to
sidestep a bug...

any ideas?

- attila

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

From attila.lendvai at gmail.com  Thu Apr 20 19:12:28 2006
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Thu, 20 Apr 2006 21:12:28 +0200
Subject: [Bese-devel] Re: forms patch in the public repo
In-Reply-To: <b54b34af0604201144u1bf21345s496c420f419fa961@mail.gmail.com>
References: <b54b34af0604201144u1bf21345s496c420f419fa961@mail.gmail.com>
Message-ID: <b54b34af0604201212y6ad25970s727b2f2bff600faf@mail.gmail.com>

> the input tag. (to set the form's action parameter) and it may screw
> up rendering in some situations (as it does for me with an ul/li tree
> with display:table/table-row css)

fyi, this only happens when dojo is included. i'll wait if it still
remains with later dojo versions...

- attila

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

From evrim at core.gen.tr  Thu Apr 20 18:26:10 2006
From: evrim at core.gen.tr (Evrim ULU)
Date: Thu, 20 Apr 2006 21:26:10 +0300
Subject: [Bese-devel] Re: expiring frames & ajax
In-Reply-To: <m2k69kpkd8.fsf@bese.it>
References: <4446DB65.6050003@core.gen.tr> <m2k69kpkd8.fsf@bese.it>
Message-ID: <4447D242.2090704@core.gen.tr>

Marco Baringer wrote:

>just uncomment the call to make-new-frame and ajax requests won't
>affect the queue. the real question, and i'd love your feedback on
>this, is how to tell if an action is an ajax action or not. hawe you
>seen the ajax code which has been floating around? (sorry, i can't
>remeber atm who wrote it).
>  
>
ok, i'll try this and see what'll happen, if i find some time, want to
write few dsl functions to analyse current session,frame,action stats.
It would be helpful.  a list of useful properties are welcome:)

sorry i'm not aware of any other ajax code.

kind regards,
evrim.


From mb at bese.it  Thu Apr 20 19:47:13 2006
From: mb at bese.it (Marco Baringer)
Date: Thu, 20 Apr 2006 21:47:13 +0200
Subject: [Bese-devel] Re: expiring frames & ajax
References: <4446DB65.6050003@core.gen.tr> <m2k69kpkd8.fsf@bese.it>
	<4447D242.2090704@core.gen.tr>
Message-ID: <m2fyk8av26.fsf@bese.it>

Evrim ULU <evrim at core.gen.tr> writes:

> Marco Baringer wrote:
>
>>just uncomment the call to make-new-frame and ajax requests won't
>>affect the queue. the real question, and i'd love your feedback on
>>this, is how to tell if an action is an ajax action or not. hawe you
>>seen the ajax code which has been floating around? (sorry, i can't
>>remeber atm who wrote it).
>>  
>>
> ok, i'll try this and see what'll happen, if i find some time, want to
> write few dsl functions to analyse current session,frame,action stats.
> It would be helpful.  a list of useful properties are welcome:)

i generally just inspect the session, is this not what you're looking
for? a few function for grabbing the session and frame and context
directly from the web page (like the copy-down links we currently have
for components) would be nice though.

> sorry i'm not aware of any other ajax code.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ajax.lisp
Type: application/octet-stream
Size: 7636 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060420/e8e21edd/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 evrim at core.gen.tr  Thu Apr 20 19:11:38 2006
From: evrim at core.gen.tr (Evrim ULU)
Date: Thu, 20 Apr 2006 22:11:38 +0300
Subject: [Bese-devel] Re: expiring frames & ajax
In-Reply-To: <m2fyk8av26.fsf@bese.it>
References: <4446DB65.6050003@core.gen.tr>
	<m2k69kpkd8.fsf@bese.it>	<4447D242.2090704@core.gen.tr>
	<m2fyk8av26.fsf@bese.it>
Message-ID: <4447DCEA.4060301@core.gen.tr>

Marco Baringer wrote:

> i generally just inspect the session, is this not what you're looking
>
>for? a few function for grabbing the session and frame and context
>directly from the web page (like the copy-down links we currently have
>for components) would be nice though.
>  
>
we'r running numerious applications simultaneously, i need something
like 'top' to monitor what's going on the server. , can be added to
admin page. i'm very happy with the current performans btw:)

evrim.




From evrim at core.gen.tr  Thu Apr 20 20:31:11 2006
From: evrim at core.gen.tr (Evrim ULU)
Date: Thu, 20 Apr 2006 23:31:11 +0300
Subject: [Bese-devel] Re: expiring frames & ajax
In-Reply-To: <4447D242.2090704@core.gen.tr>
References: <4446DB65.6050003@core.gen.tr> <m2k69kpkd8.fsf@bese.it>
	<4447D242.2090704@core.gen.tr>
Message-ID: <4447EF8F.40806@core.gen.tr>

Evrim ULU wrote:

>sorry i'm not aware of any other ajax code.
>  
>
oh i didin't see you attaching my code, yes, that's very preliminary
version of what i'm doing.

evrim.


From mbaringer at common-lisp.net  Fri Apr 21 04:30:04 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Fri, 21 Apr 2006 00:30:04 -0400 (EDT)
Subject: [Bese-devel] New patches to ucw_dev: 20-Apr-2006
Message-ID: <20060421043004.058A52E181@common-lisp.net>


Thu Apr 20 05:26:05 EDT 2006  Marco Baringer <mb at bese.it>
  * drop darcs' conflict markers

    M ./src/default.lisp -3

Mon Apr 17 23:54:01 EDT 2006  atkinw at rpi.edu
  * check for CL-LAUNCH at load-time instead of at runtime

    M ./src/default.lisp +8


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

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


From luca at pca.it  Fri Apr 21 08:45:18 2006
From: luca at pca.it (Luca Capello)
Date: Fri, 21 Apr 2006 10:45:18 +0200
Subject: [Bese-devel] Re: New patches to ucw_dev: 20-Apr-2006
References: <20060421043004.058A52E181@common-lisp.net>
Message-ID: <87psjb1fmp.fsf@gismo.pca.it>

Hello!

On Fri, 21 Apr 2006 06:30:04 +0200, Marco Baringer wrote:
> Mon Apr 17 23:54:01 EDT 2006  atkinw at rpi.edu
>   * check for CL-LAUNCH at load-time instead of at runtime

This breaks `sbcl --load etc/start.lisp`:
=====

luca at gismo:~/Hacking/cl-debian/repository/ucw-upstream$ \ 
 darcs changes --last 2
Thu Apr 20 11:26:05 CEST 2006  Marco Baringer <mb at bese.it>
  * drop darcs' conflict markers

Tue Apr 18 05:54:01 CEST 2006  atkinw at rpi.edu
  * check for CL-LAUNCH at load-time instead of at runtime

luca at gismo:~/Hacking/cl-debian/repository/ucw-upstream$ \
 sbcl --load etc/start.lisp
[...]
; compiling file
  "/home/luca/Hacking/cl-debian/repository/ucw-upstream/src/default.lisp"
  (written 20 APR 2006 06:07:03 PM):
; compiling (IN-PACKAGE :IT.BESE.UCW-USER)
; compiling (WHEN (NOT #) ...)
debugger invoked on a SIMPLE-ERROR in thread
#<THREAD "initial thread" {A7F0591}>:
  Error during processing of --eval option (LOAD #P"etc/start.lisp"):

  The CL-Launch package was not found.

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:COMPILE-OP NIL {AE39361}> on
                #<ASDF:CL-SOURCE-FILE "default" {AC55B71}>.
  1: [ACCEPT  ] Continue, treating #<ASDF:COMPILE-OP NIL {AE39361}> on
                #<ASDF:CL-SOURCE-FILE "default" {AC55B71}> 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)) #<SIMPLE-ERROR {A9AAE61}>)
0] 5

; compilation aborted after 0:00:02
;
; compilation unit aborted
;   caught 2 fatal ERROR conditions

luca at gismo:~/Hacking/cl-debian/repository/ucw-upstream$
=====

I think that the above patch was created before applying patch [1]: I
tried on a separate repo [2] and I got the same darcs' conflict.

Apart from breaking the above situation, the patch adds an unnecessary
CL-Launch dependency: unnecessary because as of [1] CL-Launch is not
needed anymore (at least in the Common Lisp code).  

I committed a patch which removes any CL-Launch check.

Thx, bye,
Gismo / Luca

[1] Wed Apr 12 17:45:07 CEST 2006  Luca Capello <luca at pca.it>
      * src/default.lisp: use `arnesi:getenv' instead of
        `cl-launch:getenv'

[2] $ darcs get --to-patch "define quit as key" \
      http://common-lisp.net/project/ucw/repos/ucw_dev
    $ [modify src/default.lisp accordingly]
    $ darcs pull
      [...]
      Wed Apr 12 17:45:07 CEST 2006  Luca Capello <luca at pca.it>
        * src/default.lisp: use `arnesi:getenv' instead of 
          `cl-launch:getenv'
      Shall I pull this patch? (1/35) [ynWvpxqadjk], or ? for help: y
      [...]
      We have conflicts in the following files:
      ./src/default.lisp
      Finished pulling and applying.
-------------- 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/20060421/853de2dd/attachment.sig>

From attila.lendvai at gmail.com  Fri Apr 21 15:40:48 2006
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Fri, 21 Apr 2006 17:40:48 +0200
Subject: [Bese-devel] actions and broswer refresh
In-Reply-To: <43FBBBC2.2090601@tech.coop>
References: <b54b34af0602211602s5296403fg13364fcdac692849@mail.gmail.com>
	<43FBBBC2.2090601@tech.coop>
Message-ID: <b54b34af0604210840scadb2b7k5c4b839095b7cd13@mail.gmail.com>

> >recently i've discovered that if i render an action with action-href,
> >press the link, and then refresh the browser, then the action is
> >triggered again.
> >
> >is this the expected behviour?
> >
> of course it is! :) imagine (<ucw:a :action (display-current-time self)
> ...). click on it, now hit 'back', and then click on the link again.
> You'd expect the time to update, right? i would. or a page with a
> meta-refresh that shows the 'current' news items....

now i think i can formulate my problem better: when an action is
triggered the document url is rewritten to contain the session,frame
and action params.

if you refresh your browser after that, then it will GET that link, so
ucw will fire the action again. and this is what bothers me.

imagine the following situation: a pageable table is displayed, user
presses next page, something (network) goes wrong while rendering the
page, gets impatient and refreshes the page. now we just stepped two
pages, which is highly unintentional.

unfortunately i'm no http/js guru, so i can't really "fix" this due to
missing the bird's view. but i modified action-dispatcher's dispatch
with partial success. (see code at the end of the mail)

what i changed is that when it can sucessfully identify a session/form
then it will handle the request no matter if an additional action can
be identified or not. but of course, if an action is also found then
it's executed.

after that if delete the a=... param from the link the action will not
be executed again and the proper page will be rendered at a refresh.

the only problem left is keeping the action param away from the
request until a user interaction explicitly sets it. maybe it could be
done by js + cookies?

as a side note: i'm already wrapping my entire page in one form tag so
that when there are multiple logically disconnected forms on one page
then submitting one will not lose the others' entered data. because of
this all my links are done with onclick js already. so it's not a big
problem if they must set cookie params or something.

any toughts? if it's not BS and somebody gives me the bird's view/impl
strategy, then i'm willing to implement it.

- attila

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



(defmethod dispatch ((dispatcher action-dispatcher)
                     (application standard-application)
                     (context standard-request-context))
  (when-bind session (find-session application context)
    (setf (context.session context) session
          (session.last-access session) (get-universal-time))
    (ucw.rerl.dispatcher.dribble "Found session ~S." session)
    (when-bind frame-id (find-frame-id context)
      (ucw.rerl.dispatcher.dribble "Found frame-id ~S." frame-id)
      (when-bind frame (find-frame-by-id session frame-id)
        (ucw.rerl.dispatcher.dribble "Found frame ~S." frame)
        (setf (session.current-frame session) frame)
        (reinstate-backtracked frame)
        (call-callbacks frame (context.request context))
        (if-bind action (find-action frame (find-action-id context))
          (progn
            (ucw.rerl.dispatcher.dribble "ACTION-DISPATCHER matched,
calling action ~S." action)
            (make-new-frame (context.session context))
            (with-action-error-handler ()
              (funcall action))
            (render-loop (frame.window-component
(context.current-frame *context*)))
            (save-backtracked (context.current-frame *context*)))
          (render-loop (frame.window-component (context.current-frame
*context*))))
        t))))

From evrim at core.gen.tr  Sat Apr 22 01:43:48 2006
From: evrim at core.gen.tr (Evrim ULU)
Date: Sat, 22 Apr 2006 04:43:48 +0300
Subject: [Bese-devel] <:ah, <:ai
Message-ID: <44498A54.8050003@core.gen.tr>

evrim.

Sat Apr 22 04:41:45 EEST 2006  evrim at core.gen.tr
  * - added exports for yaclml++
Shall I send this patch? (1/2) [ynWvpxqadjk], or ? for help: y

Sat Apr 22 04:42:14 EEST 2006  evrim at core.gen.tr
  * - added <:ah (<:as-html), <:ai (<:as-is)
Shall I send this patch? (2/2) [ynWvpxqadjk], or ? for help: y

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: yaclml.patch
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060422/238bd42a/attachment.ksh>

From evrim at core.gen.tr  Sat Apr 22 02:27:02 2006
From: evrim at core.gen.tr (Evrim ULU)
Date: Sat, 22 Apr 2006 05:27:02 +0300
Subject: [Bese-devel] (<:a :href (href "base.ucw" :id 1))
Message-ID: <44499476.7030900@core.gen.tr>

evrim.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: yaclml-href.patch
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060422/d739c25e/attachment.ksh>

From mbaringer at common-lisp.net  Sat Apr 22 04:30:04 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Sat, 22 Apr 2006 00:30:04 -0400 (EDT)
Subject: [Bese-devel] New patches to ucw_dev: 21-Apr-2006
Message-ID: <20060422043004.6703230016@common-lisp.net>


Fri Apr 21 04:23:05 EDT 2006  Luca Capello <luca at pca.it>
  * src/default.lisp: remove unnecessary CL-Launch check
  
  CL-Launch is no more needed in the Common Lisp code as of patch:
  
    Wed Apr 12 17:45:07 CEST 2006  Luca Capello <luca at pca.it>
      * src/default.lisp: use `arnesi:getenv' instead of
        `cl-launch:getenv'
  
  Removing any CL-Launch check reintroduced by patch (which BTW breaks
  `sbcl --load etc/start.lisp`):
  
    Mon Apr 17 23:54:01 EDT 2006  atkinw at rpi.edu
      * check for CL-LAUNCH at load-time instead of at runtime
  
  For a better explanation follow the thread at:
  
    http://common-lisp.net/pipermail/bese-devel/2006-April/001987.html

    M ./src/default.lisp -5


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

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


From aycan.irican at core.gen.tr  Sat Apr 22 11:58:43 2006
From: aycan.irican at core.gen.tr (Aycan iRiCAN)
Date: Sat, 22 Apr 2006 14:58:43 +0300
Subject: [Bese-devel] delete me, it's a test
Message-ID: <87psj995zg.fsf@core.gen.tr>

test

-- 
Aycan iRiCAN
C0R3 Computer Security Group
http://www.core.gen.tr
-------------- 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/20060422/da6d0c32/attachment.sig>

From aycan.irican at core.gen.tr  Sat Apr 22 12:56:50 2006
From: aycan.irican at core.gen.tr (Aycan iRiCAN)
Date: Sat, 22 Apr 2006 15:56:50 +0300
Subject: [Bese-devel] UTF-8 mime-parts
Message-ID: <87mzed93al.fsf@core.gen.tr>


Attached patch solves our utf-8 form problems (especially when using
Turkish locale).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: utf8-mime-content2.patch.gz
Type: application/octet-stream
Size: 24850 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060422/1e2629e3/attachment.obj>
-------------- next part --------------


Best Regards.

-- 
Aycan iRiCAN
C0R3 Computer Security Group
http://www.core.gen.tr
-------------- 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/20060422/1e2629e3/attachment.sig>

From mb at bese.it  Sat Apr 22 14:10:42 2006
From: mb at bese.it (Marco Baringer)
Date: Sat, 22 Apr 2006 16:10:42 +0200
Subject: [Bese-devel] Re: some docs
References: <d7ce4ebf0604130520y5576f17ame91db637320bb69b@mail.gmail.com>
Message-ID: <m2k69hn1jx.fsf@bese.it>

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

> he there,
> here are some doc patches. I updated the README, and i added my
> tutorial to the docs section.

i'm unable to apply this patch (darcs apply has consumed 100% cpu for
the last 3 hours). is someone else able to apply 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 mb at bese.it  Sat Apr 22 14:23:18 2006
From: mb at bese.it (Marco Baringer)
Date: Sat, 22 Apr 2006 16:23:18 +0200
Subject: [Bese-devel] Re: UTF-8 mime-parts
References: <87mzed93al.fsf@core.gen.tr>
Message-ID: <m2d5f9n0yx.fsf@bese.it>

"Aycan iRiCAN" <aycan.irican at core.gen.tr> writes:

> Attached patch solves our utf-8 form problems (especially when using
> Turkish locale).

you rock! applied.

-- 
-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  Sat Apr 22 14:35:20 2006
From: mb at bese.it (Marco Baringer)
Date: Sat, 22 Apr 2006 16:35:20 +0200
Subject: [Bese-devel] Re: ucw_request-dispatch
References: <m2u09j7uh4.fsf@bese.it>
Message-ID: <m28xpxn0ev.fsf@bese.it>

Marco Baringer <mb at bese.it> writes:

> achtung: i just fixed what is, afaict, the last bug in the
> request-dispatch branch. i'm going to merge it with ucw_dev soon.

merged.

-- 
-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  Sun Apr 23 04:15:02 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Sun, 23 Apr 2006 00:15:02 -0400 (EDT)
Subject: [Bese-devel] New patches to yaclml: 22-Apr-2006
Message-ID: <20060423041502.E0F9917032@common-lisp.net>


Sat Apr 22 10:14:16 EDT 2006  Marco Baringer <mb at bese.it>
  * Merge conflicts with Evrim ULU's last patch

    M ./src/packages.lisp -1 +9

Fri Apr 21 22:25:25 EDT 2006  evrim at core.gen.tr
  * href function exported.

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

Fri Apr 21 22:21:37 EDT 2006  evrim at core.gen.tr
  * - href function added. ie. (<:a :href (href "base.ucw" :id 1))

    M ./src/tags/html4.lisp +12

Fri Apr 21 21:42:14 EDT 2006  evrim at core.gen.tr
  * - added <:ah (<:as-html), <:ai (<:as-is)

    M ./src/tags/standard-yaclml.lisp +8

Fri Apr 21 21:41:45 EDT 2006  evrim at core.gen.tr
  * - added exports for yaclml++

    M! ./src/packages.lisp -8 +8


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

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


From mbaringer at common-lisp.net  Sun Apr 23 04:30:04 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Sun, 23 Apr 2006 00:30:04 -0400 (EDT)
Subject: [Bese-devel] New patches to ucw_dev: 22-Apr-2006
Message-ID: <20060423043004.50A5524002@common-lisp.net>


Sat Apr 22 10:31:13 EDT 2006  Marco Baringer <mb at bese.it>
  * Merge conflicts with ucw_request-dispatch branch

    M ./src/rerl/cookie-session.lisp -6 +7
    M ./src/rerl/standard-component/standard-component.lisp -15

Thu Apr 13 13:40:18 EDT 2006  Marco Baringer <mb at bese.it>
  * Change araneida to deal with new rerl api.
  
  This is fairly major to how the araneida backend works.

    M ./src/backend/araneida.lisp -147 +20

Thu Apr 13 13:39:42 EDT 2006  Marco Baringer <mb at bese.it>
  * Minor whitespace fixup

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

Thu Apr 13 13:39:14 EDT 2006  Marco Baringer <mb at bese.it>
  * Deal with case when (get-header "Cookie") returns NIL

    M! ./src/rerl/cookie-session.lisp -7 +6

Thu Apr 13 13:38:38 EDT 2006  Marco Baringer <mb at bese.it>
  * Moved file-serving code out of httpd.lisp and into common.lisp

    M ./src/backend/common.lisp +77
    M ./src/backend/httpd.lisp -78 +2

Thu Apr 13 09:26:49 EDT 2006  Marco Baringer <mb at bese.it>
  * Fix error handling during render loop

    M ./examples/examples.lisp -1 +1
    M ./src/rerl/standard-component/standard-component.lisp -22 +4

Thu Apr 13 09:23:36 EDT 2006  Marco Baringer <mb at bese.it>
  * Make the examples use defentry-point (and not a full list of dispatchers)

    M ./examples/examples.lisp -7 +24

Fri Apr  7 09:51:49 EDT 2006  Marco Baringer <mb at bese.it>
  * Specify that the value retruned by QUERY-PATH must not contain any uri escaping.
  
  NB: This is a backwards INcompatable change

    M ./src/backend/httpd.lisp +1
    M ./src/backend/mod-lisp.lisp -1 +2
    M ./src/rerl/protocol.lisp -1 +6

Fri Apr  7 09:34:59 EDT 2006  Marco Baringer <mb at bese.it>
  * Change regexp-dispatcher so that any registers in the url-regexp are easily accessible to the handler code.
  
  This patch works but doesn't fele very clean (the names of the
  variables suck) and will probbaly be changed shortly.

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

Fri Apr  7 09:33:51 EDT 2006  Marco Baringer <mb at bese.it>
  * Fix httpd backend's handling of multiple query parameters with the same name.
  
  There was some confusion between get-parameter and read-request
  regarding how multiple parameters need to be handled.

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

Mon Mar 27 13:29:31 EST 2006  Marco Baringer <mb at bese.it>
  * Added hack-ish error handling code in tal-dispatcher

    M ./src/rerl/standard-dispatcher.lisp -1 +12

Mon Mar 27 10:55:22 EST 2006  Marco Baringer <mb at bese.it>
  * Reintroduce defentry-point

    M ./src/rerl/standard-action.lisp +56
    M ./src/rerl/standard-classes.lisp -1 +1

Mon Mar 27 10:16:10 EST 2006  Marco Baringer <mb at bese.it>
  * Graphical fixup in inspector links

    M ./src/rerl/standard-component/standard-component.lisp -1 +1

Mon Mar 27 10:15:42 EST 2006  Marco Baringer <mb at bese.it>
  * Fix error handling when slime isn't available.

    M ./src/rerl/request-loop-error.lisp -26 +24
    M ./src/rerl/standard-server.lisp -8 +12

Mon Mar 27 10:13:54 EST 2006  Marco Baringer <mb at bese.it>
  * Change API of call-callbacks.
  
  call-callbacks really requires the request and the frame object, so
  pass just those two objects. This does make overiding call-callbacks
  much more difficult, but nobody really wants to do that anyway.

    M ./src/rerl/protocol.lisp -7 +7
    M ./src/rerl/standard-dispatcher.lisp -1 +1
    M ./src/rerl/standard-request-context.lisp -15
    M ./src/rerl/standard-session-frame.lisp +15
    M ./src/rerl/standard-session.lisp -1 +3

Mon Mar 27 09:33:23 EST 2006  Marco Baringer <mb at bese.it>
  * Remeber to set the session's current-frame to the new frame.
  
  By forgetting to do this callbacks were always called against the last
  frame, not the one whcih generated the page.

    M ./src/rerl/standard-dispatcher.lisp -3 +3

Mon Mar 27 04:58:22 EST 2006  Marco Baringer <mb at bese.it>
  * Added the 'copy to slime repl' link to the inspect components links

    M ./src/rerl/standard-component/standard-component.lisp -18 +35

Wed Mar 15 06:25:23 EST 2006  Marco Baringer <mb at bese.it>
  * When an abort-action tag is thrown we need to drop out of the handler-bind lambda.
  
  We were catching the tag but weren't performing a non-local control
  transfer, so we were never really aborting.

    M ./src/rerl/request-loop-error.lisp -5 +8

Wed Mar 15 06:24:25 EST 2006  Marco Baringer <mb at bese.it>
  * Don't log the backtrace when an error occurs (it's too big and messy to be usefull)

    M ./src/rerl/request-loop-error.lisp -1 +1
    M ./src/rerl/standard-server.lisp -2

Wed Mar 15 06:22:01 EST 2006  Marco Baringer <mb at bese.it>
  * Added some logging statements to the rfc2388 related code

    M ./src/backend/common.lisp -2 +4

Mon Mar 13 06:27:58 EST 2006  Marco Baringer <mb at bese.it>
  * Fixed the error handling code (errors during render were being dropped), added logging statements.

    M ./src/rerl/request-loop-error.lisp -1 +3
    M! ./src/rerl/standard-component/standard-component.lisp -1 +21
    M ./src/rerl/standard-dispatcher.lisp -9 +15
    M ./src/rerl/standard-server.lisp +10

Sun Mar 12 06:47:03 EST 2006  Marco Baringer <mb at bese.it>
  UNDO: Added (setf slot-value-using-class) method for standard-components.
  
  This new method automatically sets the place of the new component to
  the corresponding slot.

    M ./src/rerl/standard-component/standard-component.lisp -10

Sun Mar 12 10:50:18 EST 2006  Marco Baringer <mb at bese.it>
  * Added tal-dispatcher

    M ./src/packages.lisp +1
    M ./src/rerl/standard-dispatcher.lisp +26
    M ./src/yaclml/yaclml.lisp -17 +21

Sun Mar 12 08:04:49 EST 2006  Marco Baringer <mb at bese.it>
  * Merge conflict in secure-application.lisp

    M ./src/components/secure-application.lisp -1 +1

Sun Mar 12 08:00:38 EST 2006  Marco Baringer <mb at bese.it>
  * Export with-request-params macro

    M ./src/packages.lisp +2

Sun Mar 12 07:31:25 EST 2006  Marco Baringer <mb at bese.it>
  * Added some documentation

    M ./src/rerl/standard-dispatcher.lisp +14

Sun Mar 12 07:07:16 EST 2006  Marco Baringer <mb at bese.it>
  * Added regexp-dispatcher and convenience macros for creating url-dispatchers and regexp-dispatchers

    M ./examples/examples.lisp -12 +4
    M ./src/packages.lisp +5
    M ./src/rerl/standard-dispatcher.lisp -1 +35

Sun Mar 12 06:47:03 EST 2006  Marco Baringer <mb at bese.it>
  * Added (setf slot-value-using-class) method for standard-components.
  
  This new method automatically sets the place of the new component to
  the corresponding slot.

    M ./src/rerl/standard-component/standard-component.lisp +10

Sat Mar 11 14:11:30 EST 2006  Marco Baringer <mb at bese.it>
  * Dropped the dispatch :before and dispatch :after methods.

    M ./src/rerl/standard-dispatcher.lisp -14

Sat Mar 11 14:06:16 EST 2006  Marco Baringer <mb at bese.it>
  * Dropped standard-session-frame's service method (it's no longer used)

    M ./src/rerl/standard-session-frame.lisp -77

Sat Mar 11 14:04:04 EST 2006  Marco Baringer <mb at bese.it>
  * The cookie-session application needs to deal with the case where no session is created.

    M ./src/rerl/cookie-session.lisp -4 +5

Sat Mar 11 13:59:20 EST 2006  Marco Baringer <mb at bese.it>
  * Dropped the enable-session method. Remebered to update the session's last-access time.

    M ./src/rerl/standard-application.lisp -3
    M ./src/rerl/standard-dispatcher.lisp -2 +5

Sat Mar 11 13:58:58 EST 2006  Marco Baringer <mb at bese.it>
  * Drop standand-session-frame's service method, it's no longer used.

    M ./src/rerl/standard-session.lisp -22

Sat Mar 11 13:51:40 EST 2006  Marco Baringer <mb at bese.it>
  * Drop standard-application's service :before method and mov ethe code into service.

    M ./src/rerl/standard-application.lisp -11 +4

Sat Mar 11 13:47:55 EST 2006  Marco Baringer <mb at bese.it>
  * Use a list of dispatchers, instead of entry-poinst and nested service methods, to route incoming requests.
  
  This change moves a lot of the code which was spread out over the
  various SERVICE methods into the various dispatch methods. This change
  sholud make customizing ucw's request handling code much easier and
  reduce the amout of code in general.

    M ./examples/examples.lisp -7 +15
    M ./src/admin/admin.lisp -4 +8
    M ./src/backend/httpd.lisp -31 +10
    M! ./src/components/secure-application.lisp -1 +1
    M ./src/loggers.lisp +2
    M ./src/packages.lisp -2
    M ./src/rerl/conditions.lisp -4
    M ./src/rerl/protocol.lisp -45 +3
    M ./src/rerl/standard-action.lisp -53
    M ./src/rerl/standard-application.lisp -64 +7
    M ./src/rerl/standard-classes.lisp -17 +8
    M ./src/rerl/standard-component/control-flow.lisp -1 +1
    M ./src/rerl/standard-component/standard-component.lisp +20
    A ./src/rerl/standard-dispatcher.lisp
    M ./src/rerl/standard-request-context.lisp +8
    M ./src/rerl/standard-server.lisp -43 +32
    M ./src/rerl/standard-session-frame.lisp -3 +5
    M ./ucw.asd -1 +4

Sat Apr 22 08:52:07 EDT 2006  aycan.irican at core.gen.tr
  * This solves parsing utf-8 mime-parts

    M ./src/backend/common.lisp -5 +5
    M ./src/backend/mod-lisp.lisp -3 +4


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

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


From cjstuij at gmail.com  Sun Apr 23 09:27:51 2006
From: cjstuij at gmail.com (Ties Stuij)
Date: Sun, 23 Apr 2006 11:27:51 +0200
Subject: [Bese-devel] Re: some docs
In-Reply-To: <m2k69hn1jx.fsf@bese.it>
References: <d7ce4ebf0604130520y5576f17ame91db637320bb69b@mail.gmail.com>
	<m2k69hn1jx.fsf@bese.it>
Message-ID: <d7ce4ebf0604230227g6e6c4f7bt985183b3f6082987@mail.gmail.com>

> i'm unable to apply this patch (darcs apply has consumed 100% cpu for
> the last 3 hours). is someone else able to apply it?

you mean the patch in this thread right?
There was something wrong with it but maciek changed and already applied it.

Or maybe you mean the new patch i sent. I tested it and i can apply it
to a local repository with no problem, but i'll send a new one today
or tomorrow so as to reflect the new changes and to fix some big
mistakes.

greets,
Ties


From mb at bese.it  Sun Apr 23 09:44:47 2006
From: mb at bese.it (Marco Baringer)
Date: Sun, 23 Apr 2006 11:44:47 +0200
Subject: [Bese-devel] Re: some docs
References: <d7ce4ebf0604130520y5576f17ame91db637320bb69b@mail.gmail.com>
	<m2k69hn1jx.fsf@bese.it>
	<d7ce4ebf0604230227g6e6c4f7bt985183b3f6082987@mail.gmail.com>
Message-ID: <m24q0k39tc.fsf@bese.it>

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

>> i'm unable to apply this patch (darcs apply has consumed 100% cpu for
>> the last 3 hours). is someone else able to apply it?
>
> you mean the patch in this thread right?
> There was something wrong with it but maciek changed and already applied it.

it was the add-docs patch, the lastest one you sent applied fine. i
guess everything's ok then.

-- 
-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  Sun Apr 23 15:48:10 2006
From: cjstuij at gmail.com (Ties Stuij)
Date: Sun, 23 Apr 2006 17:48:10 +0200
Subject: [Bese-devel] defcomponent bug
Message-ID: <d7ce4ebf0604230848k2f276186k484247658e64404b@mail.gmail.com>

he,
fixed a bug with defcomponent, which when :entry-point was supplied,
still called defentry-point with a quote before the dispatch class.

sent patch to ucw_public,

greets,
Ties


From cjstuij at gmail.com  Sun Apr 23 17:27:02 2006
From: cjstuij at gmail.com (Ties Stuij)
Date: Sun, 23 Apr 2006 19:27:02 +0200
Subject: [Bese-devel] tabbed-pane fix
Message-ID: <d7ce4ebf0604231027na971dak19f7a1009b6bdd3e@mail.gmail.com>

updated tabbed-pane and the admin app to conform to the new container
mechanics. patch applied to ucw_public.


From chriss at muon.de  Sun Apr 23 21:48:23 2006
From: chriss at muon.de (Christian Haselbach)
Date: Sun, 23 Apr 2006 23:48:23 +0200
Subject: [Bese-devel] Providing raw data (Service link)
Message-ID: <20060423214823.GA10656@tngtech.com>

Hello,

what is the best way to create an url where raw data (i.e., not
wrapped / modified by ucw) is served, but where the current session is
available to create the data. I am looking for something that is called
Service Link in Tapestry.

For example a download link for some data as plain text.

My idea was to call a component wich captures the whole window (as
described in the cliki ucw cookbook). The componenent is defined using
defcomponent, but not inhereting from another component. The render
:before gets to set the content type. However, ucw modifies the output.

Another example for a service link would be an image used in a website,
that is dependend on the state of the session. Think for example of a
web mapping service, where the user can see a map an navigate through
it.

Thanks.

Regards,
Christian


From attila.lendvai at gmail.com  Sun Apr 23 22:27:45 2006
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Mon, 24 Apr 2006 00:27:45 +0200
Subject: [Bese-devel] Providing raw data (Service link)
In-Reply-To: <20060423214823.GA10656@tngtech.com>
References: <20060423214823.GA10656@tngtech.com>
Message-ID: <b54b34af0604231527h2fcb0c06pfb3877776257ab10@mail.gmail.com>

> what is the best way to create an url where raw data (i.e., not
> wrapped / modified by ucw) is served, but where the current session is
> available to create the data. I am looking for something that is called
> Service Link in Tapestry.

take a look at the thread: cl-gd image generation

- attila

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

From mbaringer at common-lisp.net  Mon Apr 24 04:00:11 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Mon, 24 Apr 2006 00:00:11 -0400 (EDT)
Subject: [Bese-devel] New patches to arnesi_dev: 23-Apr-2006
Message-ID: <20060424040011.659B665003@common-lisp.net>


Sun Apr 23 06:58:38 EDT 2006  Marco Baringer <mb at bese.it>
  * Added the REBIND macro (Patch by: Attila Lendvai <attila.lendvai at gmail.com>)

    M ./src/one-liners.lisp +6
    M ./src/packages.lisp +1

Sun Apr 23 06:56:32 EDT 2006  Marco Baringer <mb at bese.it>
  * Pass the env argument to make-load-form

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

Thu Apr 13 10:05:23 EDT 2006  Marco Baringer <mb at bese.it>
  * Fix encoding-keyword-to-native for clisp. (Patch by: Pascal Bourguignon <pjb at informatimago.com>)

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


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

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


From mbaringer at common-lisp.net  Mon Apr 24 04:30:07 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Mon, 24 Apr 2006 00:30:07 -0400 (EDT)
Subject: [Bese-devel] New patches to ucw_dev: 23-Apr-2006
Message-ID: <20060424043007.47F9130017@common-lisp.net>


Thu Apr 20 14:37:21 EDT 2006  attila.lendvai at gmail.com
  * Fix input tag rendering with :default t (worked but wasn't playing fair)

    M ./src/yaclml/ucw-tags.lisp -14 +17

Thu Apr 20 14:14:18 EDT 2006  attila.lendvai at gmail.com
  * Introduced :default t <ucw:input tag support for forms
  
  From now on when a form does not have a :action then it won't be submittable
  by pressing enter in a form element. Later, inside the form, if an <ucw:input
  element is marked as :default t, then it sets the form's action parameter to
  its own. In practice it's the same as providing the same :action for the form
  tag, but the code is decoupled. Also dojofied the scripts a little.
  
  WARNING: only tested with Mozilla! (Sorry I have no other machine)
  

    M ./src/yaclml/ucw-tags.lisp -23 +42

Sun Apr 23 13:19:12 EDT 2006  cjstuij
  * tabbed-pane-fix - updated tabbed-pane and the admin app to conform to the new container mechanics

    M ./src/admin/admin.lisp -2 +2
    M ./src/components/tabbed-pane.lisp -2 +2

Sun Apr 23 11:07:08 EDT 2006  cjstuij
  * entrypoint-unquote - removes quote before class in defcomponent when calling defentry-point

    M ./src/rerl/standard-component/standard-component.lisp -1 +1

Fri Apr 21 06:15:48 EDT 2006  cjstuij at gmail.com
  * add_rmved_ucw_intro

    A ./docs/ucw-intro/ucw-intro.html

Fri Apr 21 06:12:56 EDT 2006  cjstuij at gmail.com
  * docs_change

    M ./README +8
    R ./docs/ucw-intro/ucw-intro.html
    M ./docs/ucw-intro/ucw-intro_stage_dirs.tar

Sun Mar 19 04:23:35 EST 2006  Alberto Santini <albertosantini at tiscali.it>
  * rel. 0.6 added rfc2109 dep

    M ./docs/QUICKSTART -18 +25


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

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


From mb at bese.it  Mon Apr 24 11:19:08 2006
From: mb at bese.it (Marco Baringer)
Date: Mon, 24 Apr 2006 13:19:08 +0200
Subject: [Bese-devel] Providing raw data (Service link)
In-Reply-To: <20060423214823.GA10656@tngtech.com> (Christian Haselbach's
	message of "Sun, 23 Apr 2006 23:48:23 +0200")
References: <20060423214823.GA10656@tngtech.com>
Message-ID: <m24q0jp6fn.fsf@bese.it>

Christian Haselbach <chriss at muon.de> writes:

> Hello,
>
> what is the best way to create an url where raw data (i.e., not
> wrapped / modified by ucw) is served, but where the current session is
> available to create the data. I am looking for something that is called
> Service Link in Tapestry.
>
> For example a download link for some data as plain text.
>
> My idea was to call a component wich captures the whole window (as
> described in the cliki ucw cookbook). The componenent is defined using
> defcomponent, but not inhereting from another component. The render
> :before gets to set the content type. However, ucw modifies the output.

how does ucw modify the output?

> Another example for a service link would be an image used in a website,
> that is dependend on the state of the session. Think for example of a
> web mapping service, where the user can see a map an navigate through
> it.

i've got a couple of actions whcih generate images, or rtf or pdf
documents. the basic idea is to define a regular old component:

(defcomponent my-document ()
  (...))

and have someone call it as the toplevel component:

(call-as-window 'my-document ...)

and make sure my-document's render method setups the proper headers:

(defmethod render ((doc my-document))
  (let ((response (context.response *context*)))
    (setf (get-header response  "Content-Type") "application/rtf; charset=utf-8;"
          (get-header response "Content-Disposition") "filename=document.rtf"
          (external-format response) :iso-8859-1)
    (write-document-data (html-stream response))))

notice the call to (setf external-format) in the render method. 

one thing which ucw could do to help you in this is te split the
shutdown method into two parts:

(defgeneric send-headers (response)
  (:documentation "Send the HTTP headers in RESPONSE."))

(defgeneric send-body (response)
  (:documentation "Send the BODY of response."))

what this, combined with a custom dispatcher, wolud allow you to do is
to send the headers using the standard ucw mechanisms and then write
the data directly (skipping the call to send-body) to the response's
content-stream (which is a (unsigned-byte 8) stream attached directly
to the client).

-- 
-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 Apr 24 11:43:21 2006
From: mb at bese.it (Marco Baringer)
Date: Mon, 24 Apr 2006 13:43:21 +0200
Subject: [Bese-devel] Re: Providing raw data (Service link)
References: <20060423214823.GA10656@tngtech.com> <m24q0jp6fn.fsf@bese.it>
Message-ID: <m2vesznqqu.fsf@bese.it>

Marco Baringer <mb at bese.it> writes:

> Christian Haselbach <chriss at muon.de> writes:
>
>> Hello,
>>
>> what is the best way to create an url where raw data (i.e., not
>> wrapped / modified by ucw) is served, but where the current session is
>> available to create the data. I am looking for something that is called
>> Service Link in Tapestry.

wolud this make a good addition to ucw:


(defclass service-link (regexp-dispatcher)
  ()
  (:documentation "A very simple dispatcher which just calls the
  dispatcher's HANDLER. All normal UCW session/frame mechanisms
  are ignored. Usefull for dynamic images and binary content and,
  probably, ajax stuff."))

(defmethod dispatch ((dispatcher service-link)
                     (application standard-application)
                     (context standard-request-context))
  (multiple-value-bind (matchp *dispatcher-registers*)
      (cl-ppcre:scan-to-strings (url-string dispatcher)
                                (query-path-sans-prefix context)
                                :sharedp t)
    (when matchp
      (funcall (handler dispatcher) application context))))

(defclass service-link-with-session (service-link)
  ()
  (:documentation "Just like service-link but also ensures a
  session object is created."))

(defmethod dispatch ((dispatcher service-link-with-session)
                     (application standard-application)
                     (context standard-request-context))
  (multiple-value-bind (matchp *dispatcher-registers*)
      (cl-ppcre:scan-to-strings (url-string dispatcher)
                                (query-path-sans-prefix context)
                                :sharedp t)
    (when matchp
      (setf (context.session context) (or (find-session application context)
                                          (make-new-session application))
            (session.last-access (context.session context)) (get-universal-time))
      (funcall (handler dispatcher) application context))))

basically these are two regexp-dispatchers (one also adds a session
objcet) which don't do _any_ of the normal ucw stuff. basically what
you have here is no more (and no less) than a standard araneida
dispatcher wolud give 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 mbaringer at common-lisp.net  Tue Apr 25 04:15:03 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Tue, 25 Apr 2006 00:15:03 -0400 (EDT)
Subject: [Bese-devel] New patches to yaclml: 24-Apr-2006
Message-ID: <20060425041503.84AC116005@common-lisp.net>


Mon Apr 24 07:26:21 EDT 2006  cjstuij at gmail.com
  * <:ai-fix

    M ./src/tags/standard-yaclml.lisp -1 +1


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

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


From mbaringer at common-lisp.net  Tue Apr 25 04:30:03 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Tue, 25 Apr 2006 00:30:03 -0400 (EDT)
Subject: [Bese-devel] New patches to ucw_dev: 24-Apr-2006
Message-ID: <20060425043003.0331B19001@common-lisp.net>


Mon Apr 24 13:38:51 EDT 2006  Marco Baringer <mb at bese.it>
  * More refactoring in standard-dispatchers.
  
  Hopefully this consolidation of code makes things easier to read

    M ./src/rerl/standard-dispatcher.lisp -86 +73

Mon Apr 24 13:28:06 EDT 2006  Marco Baringer <mb at bese.it>
  * API change: split shutdown into send-headers and send-body.
  
  This change requires changes in the backend which have, atm, only been
  implemented for the httpd backend. The dispatcher code has also
  changed, the server's handle-request method no longer shutdown's the
  response, this must be done inside the various dispatch methods.

    M ./examples/gd.lisp -1 +2
    M ./src/backend/common.lisp -1 +2
    M ./src/backend/httpd.lisp -15 +20
    M ./src/packages.lisp +3
    M ./src/rerl/protocol.lisp -2 +9
    M ./src/rerl/standard-dispatcher.lisp -2 +40
    M ./src/rerl/standard-request-context.lisp -1 +3
    M ./src/rerl/standard-server.lisp -22 +15

Mon Apr 24 11:52:46 EDT 2006  Marco Baringer <mb at bese.it>
  * Fix thinko in regexp-dipatchers's dispatch method (we were accidentaly definig the method on url-dispatcher)

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

Mon Apr 24 11:52:25 EDT 2006  Marco Baringer <mb at bese.it>
  * Added the simple-dispatcher class

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

Mon Apr 24 08:01:31 EDT 2006  Marco Baringer <mb at bese.it>
  * Minor documentation fixs to standard-dispatchers

    M ./src/rerl/standard-dispatcher.lisp -1 +10

Mon Apr 24 07:45:46 EDT 2006  Marco Baringer <mb at bese.it>
  * Added COPYRIGHT info in standard-disptacher.lisp

    M ./src/rerl/standard-dispatcher.lisp +29

Mon Apr 24 05:50:16 EDT 2006  Marco Baringer <mb at bese.it>
  * Added William Halliburton's gd example

    A ./examples/gd.lisp


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

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


From christian.haselbach at tngtech.com  Mon Apr 24 22:30:20 2006
From: christian.haselbach at tngtech.com (Christian Haselbach)
Date: Tue, 25 Apr 2006 00:30:20 +0200
Subject: [Bese-devel] Providing raw data (Service link)
In-Reply-To: <m24q0jp6fn.fsf@bese.it>
References: <20060423214823.GA10656@tngtech.com> <m24q0jp6fn.fsf@bese.it>
Message-ID: <20060424223020.GA9913@tngtech.com>

Hello,

thank you and Attila for your responses.

On Mon, Apr 24, 2006 at 01:19:08PM +0200, Marco Baringer wrote:
> how does ucw modify the output?

Well, as it turned out, it was only the inspector. Not having turned it
off, I thought that not all of the html-stuff was from the inspector.
After turning it off I saw I was wrong.

By the way, is there a way to turn the inspector of for certain
components?

> i've got a couple of actions whcih generate images, or rtf or pdf
> documents. the basic idea is to define a regular old component:
[...]
> and have someone call it as the toplevel component:
[...]
> and make sure my-document's render method setups the proper headers:

That was basically what I tried.

> notice the call to (setf external-format) in the render method. 

That was missing.

Regards,
Christian


From mb at bese.it  Tue Apr 25 09:39:06 2006
From: mb at bese.it (Marco Baringer)
Date: Tue, 25 Apr 2006 11:39:06 +0200
Subject: [Bese-devel] Re: Providing raw data (Service link)
References: <20060423214823.GA10656@tngtech.com> <m24q0jp6fn.fsf@bese.it>
	<20060424223020.GA9913@tngtech.com>
Message-ID: <m2slo2c7ut.fsf@bese.it>

Christian Haselbach <christian.haselbach at tngtech.com> writes:

> Hello,
>
> thank you and Attila for your responses.
>
> On Mon, Apr 24, 2006 at 01:19:08PM +0200, Marco Baringer wrote:
>> how does ucw modify the output?
>
> Well, as it turned out, it was only the inspector. Not having turned it
> off, I thought that not all of the html-stuff was from the inspector.
> After turning it off I saw I was wrong.
>
> By the way, is there a way to turn the inspector of for certain
> components?

not at the moment, thoguh it wolud make for a nice addition.

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



From mb at bese.it  Tue Apr 25 11:09:05 2006
From: mb at bese.it (Marco Baringer)
Date: Tue, 25 Apr 2006 13:09:05 +0200
Subject: [Bese-devel] recent changes to backend protocol
Message-ID: <m28xptdi9a.fsf@bese.it>


warning: i've recently commited two patches to ucw_dev which break all
backends except httpd.

Unless you're willing to fix the code or you use the httpd backend do
not pull these patches:

'API change: split shutdown into send-headers and send-body.'

'Changed the response sending api again. It is now possible to
effectvly bypass the backend's response handling stuff.'

however, if you do fell like living with a slightly broken ucw check
out the new simple-dispatcher, minimal-dispatcher for some non-ucw
dispatchers. i've added an example, direct-mul-table-example, which
shows how to send data directly to the client as it's generated
instead of keeping it all in memory until we're ready. hopefully this
will make generating binary data even easier (if nothing else it'll be
a lot faster).

-- 
-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  Wed Apr 26 04:00:05 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Wed, 26 Apr 2006 00:00:05 -0400 (EDT)
Subject: [Bese-devel] New patches to arnesi_dev: 25-Apr-2006
Message-ID: <20060426040005.38EA62F008@common-lisp.net>


Tue Apr 25 15:57:34 EDT 2006  Maciek Pasternacki <maciekp at japhy.fnord.org>
  * Find-symbol SYSTEM::*HTTP-ENCODING* only if there is a SYSTEM package.

    M ./src/string.lisp -4 +6


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

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


From mbaringer at common-lisp.net  Wed Apr 26 04:30:05 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Wed, 26 Apr 2006 00:30:05 -0400 (EDT)
Subject: [Bese-devel] New patches to ucw_dev: 25-Apr-2006
Message-ID: <20060426043005.B60604610B@common-lisp.net>


Tue Apr 25 10:56:23 EDT 2006  Marco Baringer <mb at bese.it>
  tagged 2006-04-25


Tue Apr 25 10:38:20 EDT 2006  Marco Baringer <mb at bese.it>
  * Minore refactoring in standard-dispatcher

    M ./src/rerl/standard-dispatcher.lisp -4 +4

Tue Apr 25 10:38:07 EDT 2006  Marco Baringer <mb at bese.it>
  * Fix cookie-session-application.
  
  The service :after method is no longer a good place to set cookies in the response.

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

Tue Apr 25 08:06:53 EDT 2006  Marco Baringer <mb at bese.it>
  * Added the priority slot to the dispatchers and updated standard-application's (setf application.dispatcher) method to keep them sorted

    M ./src/rerl/standard-action.lisp -1 +3
    M ./src/rerl/standard-application.lisp +17
    M ./src/rerl/standard-classes.lisp -3 +1
    M ./src/rerl/standard-dispatcher.lisp -6 +20

Tue Apr 25 07:28:58 EDT 2006  cjstuij at gmail.com
  * docs-update - updates the readme and the ucw-intro tutorial to reflect the recent changes in ucw

    M ./README -169 +32
    A ./docs/ucw-intro/ucw-intro.html
    A ./docs/ucw-intro/ucw-intro_source.tar

Tue Apr 25 07:24:16 EDT 2006  cjstuij at gmail.com
  * del-docs-to-add-again

    R ./docs/ucw-intro/ucw-intro.html
    R ./docs/ucw-intro/ucw-intro_stage_dirs.tar

Tue Apr 25 07:27:02 EDT 2006  Marco Baringer <mb at bese.it>
  * Implement new response API for mod-lisp

    M ./src/backend/mod-lisp.lisp -31 +46

Tue Apr 25 07:05:25 EDT 2006  Marco Baringer <mb at bese.it>
  * Changed the response sending api again. It is now possible to effectvly bypass the backend's response handling stuff.
  
  Previously it was not actually possible (though it did look that
  way). See the comment at the bottow of src/rerl/protocol.lisp for
  details on the now api. as before this is only implemneted for the
  httpd backend.

    M ./examples/examples.lisp -15 +72
    M ./src/backend/common.lisp -3 +2
    M ./src/backend/httpd.lisp -22 +28
    M ./src/packages.lisp -2 +2
    M ./src/rerl/protocol.lisp -7 +42
    M ./src/rerl/standard-dispatcher.lisp -3 +2
    M ./src/rerl/standard-request-context.lisp -3 +2

Mon Apr 24 20:35:38 EDT 2006  Nathan Bird <nathan at acceleration.net>
  * Avoid registering bad applications
  Since #'ucw-user::prepare-application-variables(config.lisp) aggressively 
  searches for things that might be applications, we want to avoid registering
  anything that isn't actually an application.
  Log along the way.

    M ./src/control.lisp -1 +7


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

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


From cjstuij at gmail.com  Wed Apr 26 13:05:14 2006
From: cjstuij at gmail.com (Ties Stuij)
Date: Wed, 26 Apr 2006 15:05:14 +0200
Subject: [Bese-devel] dummy question
Message-ID: <d7ce4ebf0604260605r1eff0f4ev9be89d4c9c35c509@mail.gmail.com>

Not to be confused with noob question, although it might come close.

with-dummy-request-context works for me, as described in this list,
when i comment out the last line; e.g. it will render the component,
show the result and return the component:

       (when ,render
         (render (context.window-component *context*))
         (close-request (context.request *context*))
        ;; (send-response (context.response *context*))
         ))))

If i don't comment it out i get an error message about the first value
in a vector not being of type character, eg the 72 in:

  3: (SB-GRAY::BASIC-IO-TYPE-STREAM-WRITE-SEQUENCE
#<SWANK-BACKEND::SLIME-OUTPUT-STREAM {B4EC649}> #(72 84 84 80 47 49 46
49 32) 0 NIL #<STANDARD-GENERIC-FUNCTION SB-GRAY:STREAM-WRITE-CHAR
(1)>)

It looks like a bug but i don't know that much about streams yet.

greets,
Ties


From hbabcockos1 at mac.com  Wed Apr 26 18:25:14 2006
From: hbabcockos1 at mac.com (hbabcockos1 at mac.com)
Date: Wed, 26 Apr 2006 11:25:14 -0700
Subject: [Bese-devel] forcing a client refresh
Message-ID: <6581572.1146075914643.JavaMail.hbabcockos1@mac.com>


Hello,

I'm working on an application where I'd like to start a long process, give the user some feedback about how the process going, then display the results when the process is finished. In my (perl) past I might have done this with a javascript timer. Is there a better way to do this using ucw? Or, how would you do this using ucw?

Btw, ucw is a pretty amazing thing. It makes writing web apps so much easier! Thanks!

best,
-Hazen



From mb at bese.it  Thu Apr 27 09:48:51 2006
From: mb at bese.it (Marco Baringer)
Date: Thu, 27 Apr 2006 11:48:51 +0200
Subject: [Bese-devel] Re: dummy question
References: <d7ce4ebf0604260605r1eff0f4ev9be89d4c9c35c509@mail.gmail.com>
Message-ID: <m27j5bic1o.fsf@bese.it>

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

> Not to be confused with noob question, although it might come close.
>
> with-dummy-request-context works for me, as described in this list,
> when i comment out the last line; e.g. it will render the component,
> show the result and return the component:
>
>        (when ,render
>          (render (context.window-component *context*))
>          (close-request (context.request *context*))
>         ;; (send-response (context.response *context*))
>          ))))
>
> If i don't comment it out i get an error message about the first value
> in a vector not being of type character, eg the 72 in:
>
>   3: (SB-GRAY::BASIC-IO-TYPE-STREAM-WRITE-SEQUENCE
> #<SWANK-BACKEND::SLIME-OUTPUT-STREAM {B4EC649}> #(72 84 84 80 47 49 46
> 49 32) 0 NIL #<STANDARD-GENERIC-FUNCTION SB-GRAY:STREAM-WRITE-CHAR
> (1)>)
>
> It looks like a bug but i don't know that much about streams yet.

looks like, smells like a bug, tastes like a bug. but i'm unable to
reproduce it using the latest ucw_dev, can you senhd a test case?

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



From mb at bese.it  Thu Apr 27 09:49:56 2006
From: mb at bese.it (Marco Baringer)
Date: Thu, 27 Apr 2006 11:49:56 +0200
Subject: [Bese-devel] Re: forcing a client refresh
References: <6581572.1146075914643.JavaMail.hbabcockos1@mac.com>
Message-ID: <m23bfzibzv.fsf@bese.it>

hbabcockos1 at mac.com writes:

> Hello,
>
> I'm working on an application where I'd like to start a long
> process, give the user some feedback about how the process going,
> then display the results when the process is finished. In my (perl)
> past I might have done this with a javascript timer. Is there a
> better way to do this using ucw? Or, how would you do this using
> ucw?

there's nothing ucw-specific that can help you with this (though all
the usual javascript technicques are applicable).

-- 
-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  Thu Apr 27 11:48:03 2006
From: cjstuij at gmail.com (Ties Stuij)
Date: Thu, 27 Apr 2006 13:48:03 +0200
Subject: [Bese-devel] Re: dummy question
In-Reply-To: <m27j5bic1o.fsf@bese.it>
References: <d7ce4ebf0604260605r1eff0f4ev9be89d4c9c35c509@mail.gmail.com>
	<m27j5bic1o.fsf@bese.it>
Message-ID: <d7ce4ebf0604270448w433b0c7bm5d0d5207f17b9140@mail.gmail.com>

On 4/27/06, Marco Baringer <mb at bese.it> wrote:
> "Ties Stuij" <cjstuij at gmail.com> writes:
>
> > Not to be confused with noob question, although it might come close.
> >
> > with-dummy-request-context works for me, as described in this list,
> > when i comment out the last line; e.g. it will render the component,
> > show the result and return the component:
> >
> >        (when ,render
> >          (render (context.window-component *context*))
> >          (close-request (context.request *context*))
> >         ;; (send-response (context.response *context*))
> >          ))))
> >
> > If i don't comment it out i get an error message about the first value
> > in a vector not being of type character, eg the 72 in:
> >
> >   3: (SB-GRAY::BASIC-IO-TYPE-STREAM-WRITE-SEQUENCE
> > #<SWANK-BACKEND::SLIME-OUTPUT-STREAM {B4EC649}> #(72 84 84 80 47 49 46
> > 49 32) 0 NIL #<STANDARD-GENERIC-FUNCTION SB-GRAY:STREAM-WRITE-CHAR
> > (1)>)
> >
> > It looks like a bug but i don't know that much about streams yet.
>
> looks like, smells like a bug, tastes like a bug. but i'm unable to
> reproduce it using the latest ucw_dev, can you senhd a test case?
>

sure, well it couldn't be much simpler, which means i guess it should
always happen:

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

(defcomponent hello-world (simple-window-component) ()
             (:default-initargs :title "hi")
             (:render () (<:as-html "hello world")))

Which outputs the beforementioned error. My guess was you wrote that
*trace-output* should be bivalent. And slime says it's stream is a
character stream. e.g. that's the reason it breaks on:

(WRITE-SEQUENCE #(72 84 84 80 47 49 46 49 32) *standard-output*)

which is called in http-send-headers which is called by send-response.
So i guess it makes sense. Now, unless there is a really easy way to
change the slime stream to a bivalent stream (which i guess there is,
although i searched hard) and if my assumptions are right, i would
rather not have send-response being called, since most people (read
"I") use slime. Or...

greets,
Ties


From dsalama at user.net  Thu Apr 27 11:31:08 2006
From: dsalama at user.net (Daniel Salama)
Date: Thu, 27 Apr 2006 07:31:08 -0400
Subject: [Bese-devel] Re: forcing a client refresh
In-Reply-To: <m23bfzibzv.fsf@bese.it>
References: <6581572.1146075914643.JavaMail.hbabcockos1@mac.com>
	<m23bfzibzv.fsf@bese.it>
Message-ID: <7AD6BE3F-4E56-4860-854C-43C07A39C70D@user.net>

I guess you can use AJAX techniques to send/post your request  
asynchronously and then monitor the status of the request every so  
often.

- Waldo

On Apr 27, 2006, at 5:49 AM, Marco Baringer wrote:

> hbabcockos1 at mac.com writes:
>
>> Hello,
>>
>> I'm working on an application where I'd like to start a long
>> process, give the user some feedback about how the process going,
>> then display the results when the process is finished. In my (perl)
>> past I might have done this with a javascript timer. Is there a
>> better way to do this using ucw? Or, how would you do this using
>> ucw?
>
> there's nothing ucw-specific that can help you with this (though all
> the usual javascript technicques are applicable).
>
> -- 
> -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

Daniel Salama
dsalama at user.net
Voice: (954) 655-8051
Fax  : (954) 252-3988

------------------------

This e-mail contains information which may be confidential and
privileged. Unless you are the addressee (or authorized to
receive for the addressee), you may not use, copy or disclose
to anyone the message or any information contained in the
message.  If you have received the message in error, please
advise the sender by reply e-mail to dsalama at user.net or
tel. +1-954-655-8051 and delete the material from any computer.



From hbabcockos1 at mac.com  Thu Apr 27 18:31:06 2006
From: hbabcockos1 at mac.com (hbabcockos1 at mac.com)
Date: Thu, 27 Apr 2006 11:31:06 -0700
Subject: [Bese-devel] Re: forcing a client refresh
In-Reply-To: <m23bfzibzv.fsf@bese.it>
References: <6581572.1146075914643.JavaMail.hbabcockos1@mac.com>
	<m23bfzibzv.fsf@bese.it>
Message-ID: <2871479.1146162666054.JavaMail.hbabcockos1@mac.com>

 
On Thursday, April 27, 2006, at 03:27AM, Marco Baringer <mb at bese.it> wrote:

>hbabcockos1 at mac.com writes:
>
>> past I might have done this with a javascript timer. Is there a
>> better way to do this using ucw? Or, how would you do this using
>> ucw?
>
>there's nothing ucw-specific that can help you with this (though all
>the usual javascript technicques are applicable).

Ok, thanks. After a some fiddling I was able to figure out how to do this
using parenscript (that capitilization is tricky stuff...) to reload the
current page. I'm curious however whether it is possible to call an action.
It seems that to me that <ucw:a :action .., among other things, creates
a URL that I could in theory embed in the page for the javascript
function to call. But maybe this is pointless?

best,
-Hazen

Just in case this is helpful to anybody, this macro (if added to a
component's render method) will cause the page to be reloaded,
triggering another call to the render method.

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



From nathan at acceleration.net  Thu Apr 27 20:54:28 2006
From: nathan at acceleration.net (Nathan Bird)
Date: Thu, 27 Apr 2006 16:54:28 -0400
Subject: [Bese-devel] validators and null values
Message-ID: <0c0701c66a3c$c6a08b30$d80a0a0a@acceleration.net>

Proposed idea I wanted to toss out there for people to chew over while I'm
working on code for it:

Most of the validators are already setup to return T, indicating valid, when
given a nil value. The idea being that if you want to require a value then
use a not-empty-validator as well.

Introduce a "value-validator" subclass of validator that becomes the
superclass of most of the current validators. The :around validate for this
does the appropriate null check, and only applies the validator if there is
a value to test. I think this would apply to the following:
* regex validator (new)
  * email validator
  * phone validator (new)
* is-a-number-validator
* number-range-validator (note, currently the javascript allows null, the
server-side validate does not)
* is-an-integer-validator
* integer-range-validator
* string=-validator (server check does not allow for both boxes to be empty,
javascript does)

Really the only validator I don't think would fall under this right now is
the not-empty-validator.

I think there could potentially be other validators that would also inherit
directly from validator and would want to be called regardless of whether
the input value is null. A contrived example for this other validator is a
password box that can be empty iff a cookie or something is set.

I think there is cause for introducing a type, eg. value-validator, to
designate this class of validators who are not checked unless there is
actually a value.

I'm going to code up an implementation (shouldn't be too tough) and commit
it to ucw-public unless someone objects/has a better idea?





From nathan at acceleration.net  Fri Apr 28 02:43:09 2006
From: nathan at acceleration.net (Nathan Bird)
Date: Thu, 27 Apr 2006 22:43:09 -0400
Subject: [Bese-devel] validators and null values
In-Reply-To: <0c0701c66a3c$c6a08b30$d80a0a0a@acceleration.net>
Message-ID: <0c2901c66a6d$7cb3b750$d80a0a0a@acceleration.net>

>Most of the validators are already setup to return T, indicating valid,
>when
>given a nil value. The idea being that if you want to require a value then
>use a not-empty-validator as well.
>
>Introduce a "value-validator" subclass of validator that becomes the
>superclass of most of the current validators. The :around validate for this
>does the appropriate null check, and only applies the validator if there is
>a value to test.  [...]
>Really the only validator I don't think would fall under this right now is
>the not-empty-validator.

I changed my mind on string=-validator. That should be called regardless of
whether the field it is on has a value. If the other-field has a value and
this one doesn't then we want to indicate an error.

The external interface should be largely unchanged, with a few semantic
differences of validators succeeding where previously they failed.
Specifically: if you want a field to be required, the way to do it is a
not-empty-validator.

Other issues I came across while implementing this scheme:

Number-range-validator should inherit from is-a-number validator, it doesn't
make sense to check if a string is inside a number range, and so we've got
to do the work of ensuring it is a number first anyways. Previously this was
being handled kindof by parse-integer (would return nil or any integer found
in the string), and would break for number range validator (I expanded the
examples/forms.lisp in order to show this)

Is-an-integer-validator previously allowed 11.3 without giving any error and
returned value 11. It now fails the is-an-integer validate.


Things I came across but didn't change:

(value number-field): if the client didn't enter anything in, shouldn't we
return nil and not 0?

I don't think there is a need for the integer-range-validator anymore.
Number-range-validator takes care of it, and if you are using the
integer-field you already have the is-an-integer-validator attached.

Adding a 'required' initarg (that is itself optional :-) to form-field to
automatically attach the required validator to anything. This is such a
common case we probably want to make it easier.

The javascript validation is still untested, but was broken previously do to
an id mismatch (at least on the examples page). I will try to look into this
further somewhere in the near future.


Buy now (from ucw_public) and you ALSO GET!
* a second patch where I rearrange the file a bit to try to reduce the
number of style-warnings due to undeclared functions.
* more documentation
* Russ' regex validator, an improved email validator, and a phone-number
validator based upon it.


Nathan Bird




From mbaringer at common-lisp.net  Fri Apr 28 04:00:10 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Fri, 28 Apr 2006 00:00:10 -0400 (EDT)
Subject: [Bese-devel] New patches to arnesi_dev: 27-Apr-2006
Message-ID: <20060428040010.B74235614D@common-lisp.net>


Thu Apr 27 09:13:16 EDT 2006  Marco Baringer <mb at bese.it>
  * Export *warn-undefined*

    M ./src/packages.lisp +1

Thu Apr 27 09:12:48 EDT 2006  Marco Baringer <mb at bese.it>
  * Signal warning for undefined functions

    M ./src/walk.lisp -1 +4

Thu Apr 27 09:11:02 EDT 2006  Marco Baringer <mb at bese.it>
  * Added the *warn-undenifed* variable.
  
  We can now check for undenfined varibales/functions at walk time

    M ./src/walk.lisp -7 +37


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

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


From mb at bese.it  Fri Apr 28 10:55:55 2006
From: mb at bese.it (Marco Baringer)
Date: Fri, 28 Apr 2006 12:55:55 +0200
Subject: [Bese-devel] Re: validators and null values
References: <0c0701c66a3c$c6a08b30$d80a0a0a@acceleration.net>
	<0c2901c66a6d$7cb3b750$d80a0a0a@acceleration.net>
Message-ID: <m2fyjyt1dw.fsf@bese.it>

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

> Number-range-validator should inherit from is-a-number validator, it doesn't
> make sense to check if a string is inside a number range, and so we've got
> to do the work of ensuring it is a number first anyways. Previously this was
> being handled kindof by parse-integer (would return nil or any integer found
> in the string), and would break for number range validator (I expanded the
> examples/forms.lisp in order to show this)
>
> Is-an-integer-validator previously allowed 11.3 without giving any error and
> returned value 11. It now fails the is-an-integer validate.

nice. applied everything.

> Things I came across but didn't change:
>
> (value number-field): if the client didn't enter anything in, shouldn't we
> return nil and not 0?

yes.

> I don't think there is a need for the integer-range-validator anymore.
> Number-range-validator takes care of it, and if you are using the
> integer-field you already have the is-an-integer-validator attached.

agreed.

> Adding a 'required' initarg (that is itself optional :-) to form-field to
> automatically attach the required validator to anything. This is such a
> common case we probably want to make it easier.

agreed.

> The javascript validation is still untested, but was broken previously do to
> an id mismatch (at least on the examples page). I will try to look into this
> further somewhere in the near future.
>
>
> Buy now (from ucw_public) and you ALSO GET!
> * a second patch where I rearrange the file a bit to try to reduce the
> number of style-warnings due to undeclared functions.
> * more documentation

much abliged.

> * Russ' regex validator, an improved email validator, and a phone-number
> validator based upon it.

nice. are we sure cl-ppcre and javascript have the same syntax for
regexps?

-- 
-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  Fri Apr 28 15:05:43 2006
From: ryan at acceleration.net (Ryan Davis)
Date: Fri, 28 Apr 2006 11:05:43 -0400
Subject: [Bese-devel] Re: validators and null values
In-Reply-To: <m2fyjyt1dw.fsf@bese.it>
References: <0c0701c66a3c$c6a08b30$d80a0a0a@acceleration.net>	<0c2901c66a6d$7cb3b750$d80a0a0a@acceleration.net>
	<m2fyjyt1dw.fsf@bese.it>
Message-ID: <44522F47.90400@acceleration.net>


>> * Russ' regex validator, an improved email validator, and a phone-number
>> validator based upon it.
>>     
>
> nice. are we sure cl-ppcre and javascript have the same syntax for
> regexps?
>   
The ECMA spec (at least this one from 1999: 
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf) 
says on pg 141, section 15.10:

NOTE
The form and functionality of regular expressions is modelled [sic] 
after the regular expression facility in the
Perl 5 programming language.

So... I take that to mean javascript regexps have the same syntax in 
most cases, but don't be surprised if esoteric stuff breaks.

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:
>
>   
>> Number-range-validator should inherit from is-a-number validator, it doesn't
>> make sense to check if a string is inside a number range, and so we've got
>> to do the work of ensuring it is a number first anyways. Previously this was
>> being handled kindof by parse-integer (would return nil or any integer found
>> in the string), and would break for number range validator (I expanded the
>> examples/forms.lisp in order to show this)
>>
>> Is-an-integer-validator previously allowed 11.3 without giving any error and
>> returned value 11. It now fails the is-an-integer validate.
>>     
>
> nice. applied everything.
>
>   
>> Things I came across but didn't change:
>>
>> (value number-field): if the client didn't enter anything in, shouldn't we
>> return nil and not 0?
>>     
>
> yes.
>
>   
>> I don't think there is a need for the integer-range-validator anymore.
>> Number-range-validator takes care of it, and if you are using the
>> integer-field you already have the is-an-integer-validator attached.
>>     
>
> agreed.
>
>   
>> Adding a 'required' initarg (that is itself optional :-) to form-field to
>> automatically attach the required validator to anything. This is such a
>> common case we probably want to make it easier.
>>     
>
> agreed.
>
>   
>> The javascript validation is still untested, but was broken previously do to
>> an id mismatch (at least on the examples page). I will try to look into this
>> further somewhere in the near future.
>>
>>
>> Buy now (from ucw_public) and you ALSO GET!
>> * a second patch where I rearrange the file a bit to try to reduce the
>> number of style-warnings due to undeclared functions.
>> * more documentation
>>     
>
> much abliged.
>
>   
>> * Russ' regex validator, an improved email validator, and a phone-number
>> validator based upon it.
>>     
>
> nice. are we sure cl-ppcre and javascript have the same syntax for
> regexps?
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060428/031f27cb/attachment.html>

From mbaringer at common-lisp.net  Sat Apr 29 04:30:05 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Sat, 29 Apr 2006 00:30:05 -0400 (EDT)
Subject: [Bese-devel] New patches to ucw_dev: 28-Apr-2006
Message-ID: <20060429043005.28B8A5C120@common-lisp.net>


Fri Apr 28 06:31:14 EDT 2006  Marco Baringer <mb at bese.it>
  * In the phone and email validators instead of defining a new slot we just use the :default-initargs class option

    M ./src/components/form.lisp -5 +6

Thu Apr 27 22:32:56 EDT 2006  Nathan Bird <nathan at acceleration.net>
  * Adding documentation to form.lisp

    M ./src/components/form.lisp -9 +21

Thu Apr 27 22:25:11 EDT 2006  Nathan Bird <nathan at acceleration.net>
  * Rearranging file contents to reduce style-warnings

    M ./src/components/form.lisp -199 +205

Thu Apr 27 22:04:03 EDT 2006  Nathan Bird <nathan at acceleration.net>
  * Implementing value-validators
  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.

    M ./src/components/form.lisp -57 +77

Thu Apr 27 21:45:51 EDT 2006  Nathan Bird <nathan at acceleration.net>
  * Expanded the forms example to include a number-field and number-range-validated field.

    M ./examples/forms.lisp -3 +18

Tue Apr 25 11:49:47 EDT 2006  russ at acceleration.net
  * 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

    M ./src/components/form.lisp -8 +20
    M ./src/packages.lisp +1

Mon Apr 24 18:57:14 EDT 2006  russ at acceleration.net
  * added regex exports

    M ./src/packages.lisp +2

Thu Apr 27 13:32:59 EDT 2006  Nathan Bird <nathan at acceleration.net>
  * Comment fixup

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

Mon Apr 24 11:05:49 EDT 2006  attila.lendvai at gmail.com
  * Added missing id param that got lost in my <ucw:form changes

    M ./src/yaclml/ucw-tags.lisp +1


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

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


From mbaringer at common-lisp.net  Sun Apr 30 04:15:02 2006
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Sun, 30 Apr 2006 00:15:02 -0400 (EDT)
Subject: [Bese-devel] New patches to yaclml: 29-Apr-2006
Message-ID: <20060430041502.165BA3059@common-lisp.net>


Sat Apr 29 18:06:48 EDT 2006  cjstuij at gmail.com
  * svg-1.1

    M ./src/packages.lisp -3 +32
    M ./src/tags/svg.lisp -18 +2136


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

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


From aycan.irican at core.gen.tr  Sun Apr 30 21:01:24 2006
From: aycan.irican at core.gen.tr (Aycan iRiCAN)
Date: Mon, 01 May 2006 00:01:24 +0300
Subject: [Bese-devel] Custom backends and servers
Message-ID: <87ejzen5gb.fsf@core.gen.tr>

Hi,

I was planning to write a server for a field data collection project
in our university. Basically there is a GPRS component and I want all
data persisted sent to my server. And then present them over a web
interface.

So I started to prototype and make a simple trivial-sockets based
function. But I realized that there's alreay a rock solid framework
for this application.

Well, after looking at the source, I wrote a simple backend and a
server for this application. Here is the code url, it's very simple
and not complete.

http://coretal.core.gen.tr/cgi-bin/darcsweb.cgi?r=gprs-server;a=summary

I've implement a backend because existing backends are written for
http protocol. Besides, i've implement a new server since current one
is a little fat for my purposes.

I would like to write a web interface which reads collected data from
an exported global. Also multiple threads support for the backend is
missing.

Any ideas and fixes are welcome.

Best Regards.
-- 
Aycan iRiCAN
C0R3 Computer Security Group
http://www.core.gen.tr
-------------- 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/d951c899/attachment.sig>

From cjstuij at gmail.com  Sun Apr 30 23:58:29 2006
From: cjstuij at gmail.com (Ties Stuij)
Date: Mon, 1 May 2006 01:58:29 +0200
Subject: [Bese-devel] tabbed-pane makeover
Message-ID: <d7ce4ebf0604301658t6b0cc94ck47238452a2fa5457@mail.gmail.com>

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.

Greets,
Ties