From burban at opopop.net Mon May 4 21:52:08 2009 From: burban at opopop.net (burban at opopop.net) Date: 04 May 2009 21:52:08 +0000 Subject: [Bese-devel] ucw-core + ajax + jQuery In-Reply-To: <87ab61u0fr.fsf@default.opopop.net> References: <87ws9l1pe5.fsf@default.opopop.net> <50e8e4f60904160346k59165810wa94e57bd0ef48d57@mail.gmail.com> <87zlebngei.fsf_-_@default.opopop.net> <87ab61u0fr.fsf@default.opopop.net> Message-ID: <87d4aozgc7.fsf@default.opopop.net> Hi Ucwers, As announced, a cleaned up version of my Ajax+jQuery work, with real darcs patches: http://lisp.opopop.net/web.ucw#ucw-core+ajax Regards. -- B. Urban From senatorzergling at gmail.com Sun May 10 06:53:29 2009 From: senatorzergling at gmail.com (szergling) Date: Sun, 10 May 2009 18:53:29 +1200 Subject: [Bese-devel] Continuations in Lispworks v5.0 Message-ID: <8a4b88390905092353s250bea55r57760be730501624@mail.gmail.com> Hi all, Searching on the net, I've not been able to find too many fix for arnesi in Lispwork's (approx v5 onwards) environment access function changes. So... Hopefully without replicating anyone's effort, I've gone through and updated the functions to the new environment API (if you can call it that, it's internal, and I hope it doesn't change anytime soon). It works enough to get UCW to run on Windows Lispworks Personal Edition v5.0. Attached are the diffs I made. They are probably not suitable to go in as patches yet because: I've simply replaced/upgraded the old environment functions, when I should conditionalise on the Lispworks version (and OS?) Insufficient refactoring? Insufficient testing (I would suggest at a minimum, the forms in the second attachment). I also need to (but haven't) get the test suite to run. General confidence -- if anyone's interested, please try it and kick it around, then turn into a proper patch? For completeness, I should mention that I have also made a few other minor patches to get my version of the ucw-boxset-01-2009 to run (I believe they are orthogonal/largely unrelated to this environment issue, but might be needed to get things to run). They are variously slime.el, components/option-dialog.lisp, components/range-view.lisp, components/template.lisp (mostly renaming make-standard-environment to the new make-standard-tal-environment), examples/wiki.lisp etc. The changes might already be in the newest patches. If there're sufficient interest, I can look into them and show diffs, or submit patches for the ones that some are mostly trivial (and haven't been fixed yet). I'm also using the version of arnesi in the boxset, not the most current in darcs (couldn't get this one to load, it keeps recursively (infinite recursion) loading arnesi.asd). asdf is just too hard (will take too long to debug/figure out), so I haven't ran any tests. (Err forget that, found out the problem, clock skew, I'm sending this email anyway). I'll be keen to hear about any shortfalls or any feedback in general. Cheers! -------------- next part -------------- --- lexenv.lisp 2009-05-10 16:54:39.000000000 +1200 +++ /home/tyc20/public_html/stuff/lexenv.lisp 2009-05-10 16:49:10.000000000 +1200 @@ -302,7 +302,7 @@ (slot-value environment 'compiler::fenv)))) #+(and lispworks (or win32 linux)) -(defmethod environment-p ((environment lexical::environment)) +(defmethod environment-p ((environment compiler::environment)) t) #+(and lispworks (or win32 linux)) @@ -311,29 +311,38 @@ (eq (symbol-package value) nil))) #+(and lispworks (or win32 linux)) -(defmethod lexical-variables ((environment lexical::environment)) - (loop for candidate in (slot-value environment 'lexical::variables) - if (lexical-runtime-p (cdr candidate)) - collect (car candidate))) +(defmethod lexical-variables ((environment compiler::environment)) + (loop for candidate in (slot-value environment 'compiler::venv) + when (eq (slot-value candidate 'compiler::kind) nil) + collect (slot-value candidate 'compiler::name))) #+(and lispworks (or win32 linux)) -(defmethod lexical-functions ((environment lexical::environment)) - (loop for candidate in (slot-value environment 'lexical::functions) - if (lexical-runtime-p (cdr candidate)) - collect (car candidate))) +(defun inline-function-p (finfo) + (and (listp finfo) + (equal finfo '(inline t)))) +#+(and lispworks (or win32 linux)) +(defmethod lexical-functions ((environment compiler::environment)) + (loop for (name . finfo) in (slot-value environment 'compiler::fenv) + when (and (not (inline-function-p finfo)) + (eq (slot-value finfo 'compiler::function-or-macro) + 'compiler::function)) + collect name)) #+(and lispworks (or win32 linux)) -(defmethod lexical-symbol-macros ((environment lexical::environment)) - (loop for candidate in (slot-value environment 'lexical::variables) - unless (lexical-runtime-p (cdr candidate)) - collect candidate)) +(defmethod lexical-symbol-macros ((environment compiler::environment)) + (loop for candidate in (slot-value environment 'compiler::venv) + when (eq (slot-value candidate 'compiler::kind) 'compiler::symbol-macro) + collect (cons (slot-value candidate 'compiler::name) + (slot-value candidate 'compiler::lambda)))) #+(and lispworks (or win32 linux)) -(defmethod lexical-macros ((environment lexical::environment)) - (loop for candidate in (slot-value environment 'lexical::functions) - unless (lexical-runtime-p (cdr candidate)) - collect candidate)) +(defmethod lexical-macros ((environment compiler::environment)) + (loop for (name . finfo) in (slot-value environment 'compiler::fenv) + when (and (not (inline-function-p finfo)) + (eq (slot-value finfo 'compiler::function-or-macro) + 'compiler::macro)) + collect (cons name (slot-value finfo 'compiler::lambda)))) ;;;; ** Allegro @@ -482,26 +491,48 @@ (cons symmac (system::make-symbol-macro def)))) +(defun raw-extend-environment (val slot-name env) + (let ((new (compiler::copy-environment env))) + (push val (slot-value new slot-name)) + new)) #+(and lispworks (or win32 linux)) -(defmethod augment-with-variable ((env lexical::environment) var) - (harlequin-common-lisp:augment-environment - env :variable (list var))) +(defmethod augment-with-variable ((env compiler::environment) var) + (raw-extend-environment (compiler::make-venv :name var :kind nil) + 'compiler::venv + env)) + +(defun no-call (&rest junk) + "The call/cc interpreter overwrites and evaluates internal +flet/labels and macrolets. Lispworks interpreter/compiler shouldn't +have to do anything." + (declare (ignore junk)) + (error "This shouldn't get called!")) #+(and lispworks (or win32 linux)) -(defmethod augment-with-function ((env lexical::environment) fun) - (harlequin-common-lisp:augment-environment - env :function (list fun))) +(defmethod augment-with-function ((env compiler::environment) fun) + (raw-extend-environment (cons fun (compiler::make-flet-info + :function-or-macro 'function + :lambda #'no-call)) + 'compiler::fenv + env)) #+(and lispworks (or win32 linux)) -(defmethod augment-with-macro ((env lexical::environment) mac def) - (harlequin-common-lisp:augment-environment - env :macro (list (list mac def)))) +(defmethod augment-with-macro ((env compiler::environment) mac def) + (raw-extend-environment (cons mac (compiler::make-flet-info + :function-or-macro 'compiler::macro + :lambda def)) + 'compiler::fenv + env)) #+(and lispworks (or win32 linux)) -(defmethod augment-with-symbol-macro ((env lexical::environment) symmac def) - (harlequin-common-lisp:augment-environment - env :symbol-macro (list (list symmac def)))) +(defmethod augment-with-symbol-macro ((env compiler::environment) symmac def) + (raw-extend-environment + (compiler::make-venv :name symmac + :kind 'compiler::symbol-macro + :lambda def) + 'compiler::venv + env)) #+(and allegro (version>= 7 0)) (defmethod augment-with-variable ((env sys::augmentable-environment) var) -------------- next part -------------- A non-text attachment was scrubbed... Name: tests.lisp Type: application/x-extension-lisp Size: 1443 bytes Desc: not available URL: From attila.lendvai at gmail.com Sun May 10 10:08:09 2009 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Sun, 10 May 2009 12:08:09 +0200 Subject: [Bese-devel] Continuations in Lispworks v5.0 In-Reply-To: <8a4b88390905092353s250bea55r57760be730501624@mail.gmail.com> References: <8a4b88390905092353s250bea55r57760be730501624@mail.gmail.com> Message-ID: > Searching on the net, I've not been able to find too many fix for > arnesi in Lispwork's (approx v5 onwards) environment access function > changes. So... > > Hopefully without replicating anyone's effort, I've gone through and > updated the functions to the new environment API (if you can call it just a note: as discussed with Marco some time ago, i've factored out cl-walker from arnesi and also made some refactoring which includes the rework of environment access. only tested on sbcl, but the vm specific part is limited to a few primitives the other access functions are based on. fwiw, that is. -- attila From senatorzergling at gmail.com Mon May 11 06:10:00 2009 From: senatorzergling at gmail.com (szergling) Date: Mon, 11 May 2009 18:10:00 +1200 Subject: [Bese-devel] Fwd: Continuations in Lispworks v5.0 In-Reply-To: <8a4b88390905102309g35940301m3b8a48dd7c6f4f34@mail.gmail.com> References: <8a4b88390905092353s250bea55r57760be730501624@mail.gmail.com> <8a4b88390905102309g35940301m3b8a48dd7c6f4f34@mail.gmail.com> Message-ID: <8a4b88390905102310n1243957dkdda2e71377cb48d3@mail.gmail.com> ---------- Forwarded message ---------- From: szergling Date: Mon, May 11, 2009 at 6:09 PM Subject: Re: [Bese-devel] Continuations in Lispworks v5.0 To: Attila Lendvai On Sun, May 10, 2009 at 10:08 PM, Attila Lendvai wrote: >> Searching on the net, I've not been able to find too many fix for >> arnesi in Lispwork's (approx v5 onwards) environment access function >> changes. So... >> >> Hopefully without replicating anyone's effort, I've gone through and >> updated the functions to the new environment API (if you can call it > > > just a note: as discussed with Marco some time ago, i've factored out > cl-walker from arnesi and also made some refactoring which includes > the rework of environment access. > > only tested on sbcl, but the vm specific part is limited to a few > primitives the other access functions are based on. > > fwiw, that is. Hi Attila, Thank you. I have seen cl-walker, and a while ago, I might have browsed through the code. I must have missed your changes, because it looked tidier, but I didn't find any major changes. Overall, I liked the more modular approach, as opposed to the monolithic feel of arnesi. When I say "updated the functions", I was referring to how call/cc doesn't work on Lispworks anymore. There were a few minor name (and package) changes, and the use of different data structures for the new environment. With my update, the arnesi interface itself remains unchanged. I'm not sure how patches should flow back and forth between arnesi & cl-walker. ucw itself has continued to use arnesi, so that's why I've sent it here first. Do you know of any other projects that also use arnesi, but could also adopt cl-walker? Perhaps a way to make propagate the work in this refactoring effort, is for arnesi to change it's code walker to use cl-walker? Is this possible without any user visible (external interface) changes? Yong. From fawxtin at gmail.com Sat May 23 06:41:59 2009 From: fawxtin at gmail.com (Fausto Santin) Date: Sat, 23 May 2009 03:41:59 -0300 Subject: [Bese-devel] "Miss behavior" :action on loop Message-ID: <169CA1E3-C29D-4FDE-9824-C3D06538AB6A@gmail.com> Hi all, Im updating things from ucw_dev to ucw-core, and simply got 1 hours with a little bug bothering me. Right when I was suposed to send a help note (this email), I found a solution to the probable bug, but Im still sending this email to see/know why, and where things happened wrong. The context: I am updating a simple blog like app, and the main render method (that renders the list of posts) is no good at "passing actions". ;; DO NOT work ok (defmethod render-html-body ((self lisdit)) (<:p ( References: <169CA1E3-C29D-4FDE-9824-C3D06538AB6A@gmail.com> Message-ID: <2677cc980905230702q3d5fade2ka6b80843db54baa6@mail.gmail.com> The same happened to me but with the iterate macro. I think it was because of the cps transformation; there's something written about it somewhere. Stick to mapcar o similar functions and you'll be ok. Cheers Mariano On Sat, May 23, 2009 at 3:41 AM, Fausto Santin wrote: > Hi all, > > Im updating things from ucw_dev to ucw-core, and simply got 1 hours > with a little bug bothering me. Right when I was suposed to send a help > note (this email), I found a solution to the probable bug, but Im > still sending > this email to see/know why, and where things happened wrong. > > The context: I am updating a simple blog like app, and the main render > method (that renders the list of posts) is no good at "passing actions". > > ;; DO NOT work ok > (defmethod render-html-body ((self lisdit)) > (<:p ( (loop :for post :in (lisdit-posts self) > :do > (<:div :id "lisdit-post" > (render post) > "post: " (<:as-html (lisdit-post-id post)) > ( it")))) ; XXX here > > Every time I use the above definition, Im getting unexpected behavior > on the remove-post > action. Whenever remove link I click, it simply removes the most old > item on the list. But when > I use mapcar, instead of the loop macro, Im getting what I expect, > the remove link I click > corresponds to the expected item. > > ;; works OK > (defmethod render-html-body ((self lisdit)) > (<:p ( (mapcar #'(lambda (post) > (<:div :id "lisdit-post" > (render post) > "post: " (<:as-html (lisdit-post-id post)) > ( self) > "remove it"))) > (lisdit-posts self))) > > Any idea why this happen? > > -- > Fausto LS > > _______________________________________________ > bese-devel mailing list > bese-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clinton at unknownlamer.org Sat May 23 16:10:30 2009 From: clinton at unknownlamer.org (Clinton Ebadi) Date: Sat, 23 May 2009 12:10:30 -0400 Subject: [Bese-devel] "Miss behavior" :action on loop In-Reply-To: <169CA1E3-C29D-4FDE-9824-C3D06538AB6A@gmail.com> (Fausto Santin's message of "Sat, 23 May 2009 03:41:59 -0300") References: <169CA1E3-C29D-4FDE-9824-C3D06538AB6A@gmail.com> Message-ID: <87zld3x0jt.fsf@unknownlamer.org> Fausto Santin writes: > Hi all, > > Im updating things from ucw_dev to ucw-core, and simply got 1 hours > with a little bug bothering me. Right when I was suposed to send a help > note (this email), I found a solution to the probable bug, but Im > still sending > this email to see/know why, and where things happened wrong. > > The context: I am updating a simple blog like app, and the main render > method (that renders the list of posts) is no good at "passing actions". > > ;; DO NOT work ok > (defmethod render-html-body ((self lisdit)) > (<:p ( (loop :for post :in (lisdit-posts self) > :do > (<:div :id "lisdit-post" > (render post) > "post: " (<:as-html (lisdit-post-id post)) > ( it")))) ; XXX here Within the body of LOOP there is only one binding of POST that is destructively modified before each iteration (you can macroexpand-1 the loop form to see the code it generates) and so the closure generated by :ACTION is capturing that binding and ends up with its final value. -- Leebert: You don't listen to music. Leebert: You listen to the audio equivalent of /dev/urandom From senatorzergling at gmail.com Wed May 27 04:34:52 2009 From: senatorzergling at gmail.com (szergling) Date: Wed, 27 May 2009 16:34:52 +1200 Subject: [Bese-devel] "Miss behavior" :action on loop In-Reply-To: <8a4b88390905262132g7e24d5bfh40214707843a55d3@mail.gmail.com> References: <169CA1E3-C29D-4FDE-9824-C3D06538AB6A@gmail.com> <8a4b88390905262132g7e24d5bfh40214707843a55d3@mail.gmail.com> Message-ID: <8a4b88390905262134peba76f7s365d663dc8d293cd@mail.gmail.com> On Wed, May 27, 2009 at 4:32 PM, szergling wrote: > On Sat, May 23, 2009 at 6:41 PM, Fausto Santin wrote: >> Hi all, [[...]] > (let ((post ...)) > (loop > (setf post (some-element-of (lisdit-posts self))) > ...body...)) > > All closures (or UCW actions) in body will share the same binding to > post. mapcar uses a different binding time, that's why it worked. To I meant "uses a different binding" *each* time through a loop. Yong From senatorzergling at gmail.com Wed May 27 04:32:32 2009 From: senatorzergling at gmail.com (szergling) Date: Wed, 27 May 2009 16:32:32 +1200 Subject: [Bese-devel] "Miss behavior" :action on loop In-Reply-To: <169CA1E3-C29D-4FDE-9824-C3D06538AB6A@gmail.com> References: <169CA1E3-C29D-4FDE-9824-C3D06538AB6A@gmail.com> Message-ID: <8a4b88390905262132g7e24d5bfh40214707843a55d3@mail.gmail.com> On Sat, May 23, 2009 at 6:41 PM, Fausto Santin wrote: > Hi all, > > Im updating things from ucw_dev to ucw-core, and simply got 1 hours > with a little bug bothering me. Right when I was suposed to send a help > note (this email), I found a solution to the probable bug, but Im > still sending > this email to see/know why, and where things happened wrong. > > The context: I am updating a simple blog like app, and the main render > method (that renders the list of posts) is no good at "passing actions". > > ;; DO NOT work ok > (defmethod render-html-body ((self lisdit)) > (<:p ( (loop :for post :in (lisdit-posts self) > :do > (<:div :id "lisdit-post" > (render post) > "post: " (<:as-html (lisdit-post-id post)) > ( it")))) ; XXX here > Ah hah, a very common misconception for newbies. In case it's still not clear enough, loop is doing something like this (pseudo-code only for illustration) (let ((post ...)) (loop (setf post (some-element-of (lisdit-posts self))) ...body...)) All closures (or UCW actions) in body will share the same binding to post. mapcar uses a different binding time, that's why it worked. To solve your issue, you just need to rebind post. (defmethod render-html-body ((self lisdit)) (<:p (