From aankhen at gmail.com Tue Feb 3 15:17:49 2009 From: aankhen at gmail.com (Aankhen) Date: Tue, 3 Feb 2009 20:47:49 +0530 Subject: [Bese-devel] [patch] Add plain HTML generation In-Reply-To: References: Message-ID: [Sent directly to Drew by mistake.] Hi Drew, On Fri, Jan 30, 2009 at 00:19, Drew Crampsie wrote: > This is a good idea, but the execution (run time parameter checks) is > not at all right.. it should be done at compile time. > > I'll accept the patch if you want to rework it so that the logic is > all finished by run-time, but i can't possibly keep it like this .. > there is no need to do the work every time a page is rendered :). The reasoning behind it was that otherwise it becomes a nightmare to maintain two seperate versions of everything in the case where one Lisp image needs to generate both HTML and XHTML (or both HTML and any XML format, for that matter). This might happen if you run an HTML-based site and an XHTML-based site in the same image; if you use content negotiation to serve up XHTML to capable browsers, HTML to others; if you use HTML everywhere on your site except in those cases where you need to use XHTML features (e.g. specific pages with embedded MathML or SVG); if you use YACLML to generate static HTML as well as static XHTML; or if, indeed, you have a completely HTML-based site and you generate any sort of XML output (RSS, Atom come to mind). If the decision is made at compile-time as to which version to generate, then each time you make a change to your template, you need to first recompile every file under yaclml/src/tags/, then recompile your own template, since the decision is made when you compile those files rather than your template. Given all that, I agree with you that unconditionally doing everything at run-time isn't really such a good idea. What I have right now is pure static compilation. My suggestion (which I'm working on) is to have another variable *YACLML-STATIC-COMPILATION-P* which controls whether to use static or dynamic compilation. (Perhaps "compilation" is the wrong word?) The default value would be T, i.e. no change. If set to NIL, however, it would do what my earlier patch did. I'd be happy to put this together if it would be acceptable to you. At any rate, here's a clean patch incorporating the changes you requested. Aankhen -------------- next part -------------- A non-text attachment was scrubbed... Name: yaclml-plain-html.patch Type: application/octet-stream Size: 8373 bytes Desc: not available URL: From clinton at unknownlamer.org Tue Feb 3 21:14:59 2009 From: clinton at unknownlamer.org (Clinton Ebadi) Date: Tue, 03 Feb 2009 16:14:59 -0500 Subject: [Bese-devel] [patch] Add plain HTML generation In-Reply-To: (aankhen@gmail.com's message of "Tue, 3 Feb 2009 20:47:49 +0530") References: Message-ID: <87skmvkyss.fsf@unknownlamer.org> Aankhen writes: > [Sent directly to Drew by mistake.] > > Hi Drew, > > On Fri, Jan 30, 2009 at 00:19, Drew Crampsie wrote: >> This is a good idea, but the execution (run time parameter checks) is >> not at all right.. it should be done at compile time. >> >> I'll accept the patch if you want to rework it so that the logic is >> all finished by run-time, but i can't possibly keep it like this .. >> there is no need to do the work every time a page is rendered :). > > The reasoning behind it was that otherwise it becomes a nightmare to > maintain two seperate versions of everything in the case where one > Lisp image needs to generate both HTML and XHTML (or both HTML and any > XML format, for that matter). This might happen if you run an > HTML-based site and an XHTML-based site in the same image; if you use > content negotiation to serve up XHTML to capable browsers, HTML to > others; if you use HTML everywhere on your site except in those cases > where you need to use XHTML features (e.g. specific pages with > embedded MathML or SVG); if you use YACLML to generate static HTML as > well as static XHTML; or if, indeed, you have a completely HTML-based > site and you generate any sort of XML output (RSS, Atom come to mind). Why would you want to generate HTML4? The xhtml produced by yaclml is valid html (note things like "" and whatnot). -- Lindsay (Carlton): should i eat more post its From aankhen at gmail.com Wed Feb 4 08:26:45 2009 From: aankhen at gmail.com (Aankhen) Date: Wed, 4 Feb 2009 13:56:45 +0530 Subject: [Bese-devel] [patch] Add plain HTML generation In-Reply-To: <87skmvkyss.fsf@unknownlamer.org> References: <87skmvkyss.fsf@unknownlamer.org> Message-ID: On Wed, Feb 4, 2009 at 02:44, Clinton Ebadi wrote: > Why would you want to generate HTML4? The xhtml produced by yaclml is > valid html (note things like "" and whatnot). Actually, the XHTML produced by YACLML is *well-formed* (i.e. there are no syntactical errors) XHTML (i.e. not HTML). Producing invalid code with YACLML is easy. Observe: (:span (:div "Hi")) ?

; invalid because `span' is an inline element; it is not allowed to contain block-level elements like `div' Of course, that's a *good* thing, IMO. YACLML generates markup. It should not be enforcing validity. As for your question, the choice between XHTML and HTML is (at this point) rather philosophical, hence why I avoided getting into the "why" of it in my original post. Suffice to say that there is nothing to be gained from using XHTML unless you're actually making use of the fact that it's XML, by integrating other vocabularies or parsing it using XML tools in a way that you couldn't if it were HTML. All that requires you actually serve it as `application/xhtml+xml'?which Internet Explorer, happily enough, doesn't support?or else the browser just takes it to be regular HTML tag soup. ?I'll stop here rather than clutter up the list with more in that vein. :-) Aankhen From aankhen at gmail.com Fri Feb 6 17:49:04 2009 From: aankhen at gmail.com (Aankhen) Date: Fri, 6 Feb 2009 23:19:04 +0530 Subject: [Bese-devel] [patch] Add plain HTML generation In-Reply-To: References: Message-ID: Hi Drew, Here's a reworked patch that implements the static processing flag I mentioned earlier. Sorry it took so long. Aankhen -------------- next part -------------- A non-text attachment was scrubbed... Name: yaclml-add-plain-html-generation.patch Type: application/octet-stream Size: 15978 bytes Desc: not available URL: From clinton at unknownlamer.org Mon Feb 9 04:05:20 2009 From: clinton at unknownlamer.org (Clinton Ebadi) Date: Sun, 08 Feb 2009 23:05:20 -0500 Subject: [Bese-devel] Minor Arnesi and UCW Fixes for CCL Message-ID: <8763jki7b3.fsf@unknownlamer.org> Greetings, I have a small (total of ten characters changed!) patch to arnesi in my branch at http://darcs.unknownlamer.org/arnesi_dev_closer-mop/ that makes call/cc work with at least CCL. I'm not sure if this is /right/; is there any particular reason `closure/cc' was only a `funcallable-standard-class' on SBCL? I am potentially missing something here... but did the code work at all on any other implementations? My branch also has a (large, but straightforward) patch to remove MOPP in favor of Closer MOP. http://unknownlamer.org/darcsweb/browse?r=arnesi_dev_closer-mop;a=commitdiff;h=20090209034308-44524-b9334b5e7612ffa659f4d87cb0160e3ad37776b2.gz shows the two spots where I removed the #+sbcl to make things work with CCL. A couple of minor fixes to UCW Core are in my branch (http://unknownlamer.org/darcsweb/browse?r=ucw-core_clinton;a=commit;h=20090209033623-44524-e2df0861e544e62590e723df4362fa8595bcff72.gz) that make things run on CCL. I did a quick test and everything seems to be OK. -- "Karen loved animals. Unfortunately the cheetahs betrayed her trust," Libot said. From senatorzergling at gmail.com Wed Feb 25 10:40:55 2009 From: senatorzergling at gmail.com (szergling) Date: Wed, 25 Feb 2009 23:40:55 +1300 Subject: [Bese-devel] New tutorial typos In-Reply-To: References: <8a4b88390901150242s3c3dc4f8i606b28449f69aafc@mail.gmail.com> Message-ID: <8a4b88390902250240q692edec3y8df0ae889bf8c6d9@mail.gmail.com> Hi again, sorry for the long delay in this reply. I've been slowly hacking (on other things too) and reading UCW's source... >2009/1/15 szergling : >> Some further questions: >> >> In the YACLML section, >> >> *** YACLML: Yet another common lisp markup language. >> >> (defun render-message-form (name) >> (<:form >> (<:as-html "Enter a new message:") >> (<:input >> :type "text" :name (string-downcase name)) >> (<:submit))) >> >> What does the form submit to? That is, what gets generated in the >> All this is probably offtopic for a UCW discussion. >> ---------- >> >> *** Frames, Actions, Callbacks. >> >> "A frame represents an individual hit, a page rendered... an >> interaction with the application." >> >> I still don't understand what a frame is. It doesn't seem to be >> visible to a UCW user, so perhaps it should come later, since it >> describes UCW internals? That is, show what the user would write >> first, then show what the written code does behind the scenes. > >Ok, let me put it to you this way. You hit an entry point. there is >only one link on it. You open that link twice in two new windows, and >you now have three frames. Each frame represents a unique browser >url.. a window. Without frames we'd only have sessions in which to >store callbacks and actions... and that would mean only one browser >window would actually work.. and you'd see weird errors when you clone >windows, hit the back button, or whatever. > >Does that makes sense? Thanks for the clarification. So frames are a way to represent state in the presence of continuations. Can we think of them as, in effect, "tree-like" structures that keep track of "immutable" state? For example, instead of mutating state, we represent the evolution of a counter as we increment it thus: [The trees below are represented by lists: car <=> parent node, cdr <=> leaf nodes, except lists, which are sub-trees. The evolution of the values, and the tree representing them, as shown together with some commentaries.] 1. (1) The initial value seen in some browser window 2. (1 2) The value is incremented to 2. The original 1 is still available because we might go back. Another possibility, is that 2 might have been a simultaneous increment & clone operation (as when someone middle clicks on an "Increment" link), so now, we have the original window showing 1, and a new window showing 2. 3. (1 2 2) Possible causes: the browser window/tab showing the 2 is cloned. Or, the browswer window showing 1 is incremented, or "increment & cloned"... etc 4. (1 (2 3) 2) The value in the window showing 2 is incremented. 5. (1 (2 (3 4)) 2) The value in the first window (now showing 3) is incremented again. 6. (1 (2 (3 4) 3) 2) >From the first window, we click back twice, back to the screen showing the value 2, and increment again. This results in a new branch of values... (among other possibilities, etc) So after step 6, the tree looks like: 1 | +- 2 | | | +- 3 | | | | | +- 4 | | | +- 3 | +- 2 There is only 1 counter (1 state), but each frame stores a "alternative" value of the counter. Backtracks are used to save/restore the value from any required branch into that counter. So, have I got the right idea? I've been trying to figure all this out from the source, but am still trying to work out backtracking slots (the mop bit). ;;-------------------- Now, I am also confused about another thing. Suppose a component displays an action that does not 'answer', but has side-effects instead. I'm not sure why this action would repeatedly get called even when the component display is only refreshed and not clicked on. Here is a simple example to illustrate: (defcomponent refresh-demo () ((value :initform 0 :accessor component-value))) (defmethod render ((c refresh-demo)) (<:p "Current value is: " (<:as-html (component-value c))) ( Sorry if my previous email did come through, but I've been getting no end of trouble from common-lisp.net mailing lists. Lost emails, no "own posts" (yes, it's ticked in the "mailing list membership configuration" panel), etc. This time, it looks as if my last post was truncated, so I'm including it again as an attachment. Very sorry for the mess. (but I don't think it's my fault). Any tips on managing using all these mailing lists? I don't even subscribe to that many... Apologies if this seems like a rant. I'm frustrated. You don't even deserve this... it's not your fault. -------------- next part -------------- Hi again, sorry for the long delay in this reply. I've been slowly hacking (on other things too) and reading UCW's source... >2009/1/15 szergling : >> Some further questions: >> >> In the YACLML section, >> >> *** YACLML: Yet another common lisp markup language. >> >> (defun render-message-form (name) >> (<:form >> (<:as-html "Enter a new message:") >> (<:input >> :type "text" :name (string-downcase name)) >> (<:submit))) >> >> What does the form submit to? That is, what gets generated in the >> All this is probably offtopic for a UCW discussion. >> ---------- >> >> *** Frames, Actions, Callbacks. >> >> "A frame represents an individual hit, a page rendered... an >> interaction with the application." >> >> I still don't understand what a frame is. It doesn't seem to be >> visible to a UCW user, so perhaps it should come later, since it >> describes UCW internals? That is, show what the user would write >> first, then show what the written code does behind the scenes. > >Ok, let me put it to you this way. You hit an entry point. there is >only one link on it. You open that link twice in two new windows, and >you now have three frames. Each frame represents a unique browser >url.. a window. Without frames we'd only have sessions in which to >store callbacks and actions... and that would mean only one browser >window would actually work.. and you'd see weird errors when you clone >windows, hit the back button, or whatever. > >Does that makes sense? Thanks for the clarification. So frames are a way to represent state in the presence of continuations. Can we think of them as, in effect, "tree-like" structures that keep track of "immutable" state? For example, instead of mutating state, we represent the evolution of a counter as we increment it thus: [The trees below are represented by lists: car <=> parent node, cdr <=> leaf nodes, except lists, which are sub-trees. The evolution of the values, and the tree representing them, as shown together with some commentaries.] 1. (1) The initial value seen in some browser window 2. (1 2) The value is incremented to 2. The original 1 is still available because we might go back. Another possibility, is that 2 might have been a simultaneous increment & clone operation (as when someone middle clicks on an "Increment" link), so now, we have the original window showing 1, and a new window showing 2. 3. (1 2 2) Possible causes: the browser window/tab showing the 2 is cloned. Or, the browswer window showing 1 is incremented, or "increment & cloned"... etc 4. (1 (2 3) 2) The value in the window showing 2 is incremented. 5. (1 (2 (3 4)) 2) The value in the first window (now showing 3) is incremented again. 6. (1 (2 (3 4) 3) 2) From the first window, we click back twice, back to the screen showing the value 2, and increment again. This results in a new branch of values... (among other possibilities, etc) So after step 6, the tree looks like: 1 | +- 2 | | | +- 3 | | | | | +- 4 | | | +- 3 | +- 2 There is only 1 counter (1 state), but each frame stores a "alternative" value of the counter. Backtracks are used to save/restore the value from any required branch into that counter. So, have I got the right idea? I've been trying to figure all this out from the source, but am still trying to work out backtracking slots (the mop bit). ;;-------------------- Now, I am also confused about another thing. Suppose a component displays an action that does not 'answer', but has side-effects instead. I'm not sure why this action would repeatedly get called even when the component display is only refreshed and not clicked on. Here is a simple example to illustrate: (defcomponent refresh-demo () ((value :initform 0 :accessor component-value))) (defmethod render ((c refresh-demo)) (<:p "Current value is: " (<:as-html (component-value c))) (