From mb at bese.it Sun May 2 09:55:04 2004 From: mb at bese.it (Marco Baringer) Date: Sun, 02 May 2004 11:55:04 +0200 Subject: [Bese-devel] trees, threads, and places oh my! Message-ID: [hoping the weird subject won't ge this email ticked as spam by anyone :)] I'm currently working on adding seaside's "component threads" to UCW. you can follow the action on the ucw--component-trees--0.2 branch. The fundamental change required was to tell every component that it lived in a particular "place" (see the PLACE class and teh new file src/rerl/place.lisp for the gory details). Then we had to teach the call/answer mechanism to deal with keeping the right object in the right place. This then required passing an explicit FROM component to call and answer (before the was implicitly the current frame's component). Anyway it's basically working in the above mentioned branch, but the code is still very low level (ie you have to eplicitly specify everything each time), i'm currently working on refactoring things and searching for the right macros to make using this api comfortable. if you want to wait i should merge it into ucw--dev--0.2 in the next few days. in the mean time over in arnesi land i've added three new macros: defun/cc, defmethod/cc and (just for completness, it's not really neccessary) defgeneric/cc. If you define a method or function with these macros they will be able, always using call/cc, to capture continutions which span function calls, this functionality is used in the new component api, so update you'll need to update arnesi to follow this branch. nb: the tarballs get the latest versions of the dev branch, so this change won't show up there until i merge things back in. as always, comments would be appreciated. -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From mb at bese.it Sun May 2 10:50:43 2004 From: mb at bese.it (Marco Baringer) Date: Sun, 02 May 2004 12:50:43 +0200 Subject: [Bese-devel] trees, threads, and places oh my! References: Message-ID: one thing i forgot to mention: the current component place stuff has _nothing_ to do with html generation, the rendering protocol has not changed. let me explain: previously when you call'd a component we simply created an instance of the proper object, dumped it in the current frame's component slot and rendered it. Now call'ing is a two component operation[1], we have an explicitly named "caller" and "callee", as before the calle knows (via the calling-component slot) who the caller is, the only difference is that now the callee does not get put into the current frame's component solt but it gets put in the caller's place. when the callee answers the caller is put back in the place. however, we continue to call render-on on the frame's component, so this swapiing around of component could actually have no visible effect on the generated pages (not that i can think of a reason for actually doing this). does this make any sense? for example, see the new example-app component. it sets it's place to a lost of itself, this way when example-app is the caller the calle gets put in example-app, not in the current frame's component slot (which is where example-app happens to live). whether this is a cool usefull technique or just really really confusing is debatable. the second thing to notice is that places are not limited to a single position in memory, a place is simply an object which specifies 3 things: 1) how to get the current value of the place, 2) how to set the current value of the place and 3) how to copy the value in the place. so if you were so inclined you could have a place which corresponded to a hash table, a slot in a class and the car of a list, or you cloud have a place which simply did did nothing (again, i can think of no use for these "blackhole" places, but it's easier to allow them then to disallow them). [1] - it was this way before as well, except the calling component was always the current frame's component slot. p.s. - one of the coolest things about lisp is that i con first define a very generic, very correct, api for something and then later, after having used it for a bit, code up the common idioms in macros. someone should write some advocacy about how lisp (common lisp in particular) makes it possible (and easy) to have generic apis and idiomatic uses of the apis live peacfully together. -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From ng at stamov.ch Sun May 2 14:37:59 2004 From: ng at stamov.ch (Plamen Stamov) Date: Sun, 02 May 2004 16:37:59 +0200 Subject: [Bese-devel] status of ucw on various implementations In-Reply-To: References: Message-ID: <409507C7.6010105@stamov.ch> Hello, I sendet several mails to you, but may be your spam filter reacts on "macrolet" :) So here it goes again. As first thank you a lot for providing the daily snapshots of the source of UCW! Last week I've managed to let it run in LispWorks using a patch (which I sended to you) for the old version of the CPS-transformer. Here is a new patch for the version from 27.04.2004 (sorry for not having the possibility to provide a real diff or something which arch could understand automatically, so the rest of the mail could become boring): In the file ucw/ucw/libs/arnesi/src/cps.lisp there is a fragment of code like this (ensure-exists-handler 'application) (setf (handler.rename (gethash 'application *cps-handlers*)) (lambda (form) (destructuring-bind (op &rest args) form (acond ((lookup :flet op) `(,it ,@(mapcar #'cps-rename args))) ((lookup :macrolet op) (cps-rename (funcall it form))) The next line (in my copy it is the line 198) in case of found macro-function, it gets invoked. ((macro-function op) (cps-rename (funcall it form nil))) For LispWorks, this has to be expaned using this : ((macro-function op) (cps-rename (macroexpand-1 form nil))) If I interpret CLHS correctly, the patch doesn't restrict and doesn't change the semantics. (macroexpand would do it probably too, but I haven't readed enough the source of the CPS-transformer). So the new form would look like (setf (handler.rename (gethash 'application *cps-handlers*)) (lambda (form) (destructuring-bind (op &rest args) form (acond ((lookup :flet op) `(,it ,@(mapcar #'cps-rename args))) ((lookup :macrolet op) (cps-rename (funcall it form))) ((macro-function op) (cps-rename (macroexpand-1 form))) (t `(,op ,@(mapcar #'cps-rename args))))))) I hope this mail reaches you With best regards Plamen Stamov Marco Baringer wrote: >Supposedly UCW runs on SBCL, OpenMCL and CMUCL. let's check: > >OpenMCL - ok (this is after all the main development platform) >SBCL/ppc single thread - ok. >SBCL/x86 - ?? >CMUCL - no. > >:( > >i'd like to know what platforms ucw is (and isn't) running on. Since i >don't have cmucl available i can't personally deal with that >implementation. Does anybody with some spare time and cmucl care to >get ucw running on that implementation? > > > From mb at bese.it Mon May 3 19:52:13 2004 From: mb at bese.it (Marco Baringer) Date: Mon, 03 May 2004 21:52:13 +0200 Subject: [Bese-devel] trees, threads, and places oh my! In-Reply-To: (Marco Baringer's message of "Sun, 02 May 2004 12:50:43 +0200") References: Message-ID: ok, that's that. the component-trees branch has been merged into the main branch (ucw--dev--0.2--patch-72). changes to look out for: 1) defaction now requires that it's first arg be a component. 2) defaction now binds UCW:SELF to said component. 3) the macros call and answer simply pass UCW:SELF to the generic functions call-component and answer-component. In those cases where the component contral doesn't follow the "normal" route, you'll need to use call-component/answer-component, otherwise you'll use call and answer just as before. 4) all the entry points need to set the frame's "root" component, the goto macro (and associated goto-component generic function) do this. 5) the defcomponent form no longer implictly sets up standard-component as a super class of the component, this is probably a mistake. 6) when the global variable *inspect-components* is set to T you get a link at the bottom of every component allowing you to inspect it. this is variable can be toggled from the control panel. i'd be nice to have a link which opens up that component in a slime inspector, working on it. 7) the transaction example is gone, we really need to rethink transactions that we've changed the way components interact with each other. we want a way to have the transaction be tied to a particular component thread, not the entire frame. 8) the are no longer seperate counter.ucw, hello-world.ucw, etc. example urls, just go to /ucw/examples/ and chose from the menu on the left. you'll probably need to change apache's httpd.conf file to make this url get to ucw. 9) portableaserve may or may not work, i haven't checked. cmucl and sbcl may or may not work, i haven't checked. this is going to become ucw 0.2.1 after i make sure that the portableaserve backend warks, then it'll be time to overhaul the docs. to anyone who was hoping that i'd get my act together and start using css to make ucw aesthetically acceptable: nope. happy hacking, -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From mb at bese.it Tue May 4 18:38:16 2004 From: mb at bese.it (Marco Baringer) Date: Tue, 04 May 2004 20:38:16 +0200 Subject: [Bese-devel] ucw 0.2.1 Message-ID: UnCommonWeb version 0.2.1 - 2004-05-04 * Download ftp://ftp.common-lisp.net/pub/project/ucw/ucw_0.2.1.tar.gz NB: This tarball contains ucw, arnesi, yaclml and cl-icu. You'll need to install a recent CVS version of SLIME, portableaserve 1.2.35 and/or mod_lisp 2.33 * New Features (since 0.2.0) ** UCW - Component threads - Removed dependencies on acl-compat. - Improved error handling code - improved admin app. ** TAL - Improved TAL environments ** Notes - This release has been tested with OpenMCL _only_. -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From mb at bese.it Sat May 15 19:08:58 2004 From: mb at bese.it (Marco Baringer) Date: Sat, 15 May 2004 21:08:58 +0200 Subject: [Bese-devel] ucw 0.2.2 Message-ID: I've just uploaded ucw 0.2.2, it's basically just 0.2.1 but adds nestable (and working) component transactions. ftp://ftp.common-lisp.net/pub/project/ucw/ucw_0.2.2.tar.gz happy hacking, -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From mb at bese.it Wed May 19 13:06:52 2004 From: mb at bese.it (Marco Baringer) Date: Wed, 19 May 2004 15:06:52 +0200 Subject: [Bese-devel] action-anchor Message-ID: just a quick heads up: 1) the action-anchor yaclml tag is going away, it is going to be replaced by the