From g.castaldi at quinary.com Fri Sep 3 06:51:49 2004 From: g.castaldi at quinary.com (Giannandrea Castaldi) Date: Fri, 03 Sep 2004 08:51:49 +0200 Subject: [Bese-devel] Problem with cmucl 19a package lock Message-ID: <41381485.60001@quinary.com> Hi, I've just installed cmucl 19a and when I try to compile fiveAM I have the following error. I suppose that the problem is in the use of 'condition' as slot in the class unexpected-test-failure or as function argument. Attempt to modify the locked package COMMON-LISP, by redefining function CONDITION [Condition of type LISP::PACKAGE-LOCKED-ERROR] Restarts: 0: [CONTINUE] Ignore the lock and continue 1: [UNLOCK-PACKAGE] Disable package's definition-lock, then continue 2: [UNLOCK-ALL] Disable all package locks, then continue 3: [CONTINUE] Return NIL from load of #p"/home/gcast/.asdf-install-dir/site/fiveam_1.2.2/src/check.x86f". 4: [RETRY] Retry performing # on #. 5: [ACCEPT] Continue, treating # on # as having been successful. 6: [ABORT] Abort handling SLIME request. 7: [ABORT] Return to Top-Level. Regards. Giannandrea From mb at bese.it Fri Sep 3 10:21:57 2004 From: mb at bese.it (Marco Baringer) Date: Fri, 03 Sep 2004 12:21:57 +0200 Subject: [Bese-devel] Problem with cmucl 19a package lock In-Reply-To: <41381485.60001@quinary.com> (Giannandrea Castaldi's message of "Fri, 03 Sep 2004 08:51:49 +0200") References: <41381485.60001@quinary.com> Message-ID: Giannandrea Castaldi writes: > Hi, > I've just installed cmucl 19a and when I try to compile fiveAM I have > the following error. > I suppose that the problem is in the use of 'condition' as slot in the > class unexpected-test-failure or as function argument. fixed in FiveAM--dev--1.2--patch-8. -- -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 Fri Sep 17 16:42:08 2004 From: mb at bese.it (marco) Date: Fri, 17 Sep 2004 18:42:08 +0200 Subject: [Bese-devel] UCW 0.3.0pre0 - learning to climb Message-ID: [this will become ucw 0.3.0 in a few days time (need to test cmucl and sbcl)] UnCommonWeb version 0.3.0pre0 - learning to climb Released 2004-09-17 * Home page http://common-lisp.net/project/ucw/ * Download ftp://ftp.common-lisp.net/pub/project/ucw/ucw_0.3.0pre0.tar.gz NB: This tarball contains ucw, arnesi and yaclml. You'll need to install a recent CVS version of SLIME, portableaserve 1.2.35 and iterate (mod_lisp is included in the libs/ directory). * ARCH parameters Archive Name: ucw-2004 at common-lisp.net Archive Location: http://common-lisp.net/project/ucw/ucw-2004 at common-lisp.net Config version: ucw--dists--1.0 Config Name: 0.3.0pre0 * New Features (since 0.2) - UCW package exports the public interface. New UCW-USER package. - Inter action continuations now work as expected. - Gracefully (and programmatically) deal with requests for expired sessions. ** Components - Improved range-view API. - Simple date-picker component - Allow component threads and manipulation of component places. ** YACLML/TAL - Improved form handling. - All TAL extensions are accessable as yaclml macros. - Hi. I just ASDF-installed FiveAM and read the documentation that comes with it. I think the ideas behind FiveAM are really nice, and I'm looking forward to using it. However, I have two problems with the document. Firstly, I noticed quite a few spelling mistakes in the document. I've attached a patch that should correct them. Secondly, the document refers to the "function documentation" for more info, but I don't know where to find it. Kind regards, Dirk Gerrits -------------- next part -------------- A non-text attachment was scrubbed... Name: FiveAM.tex.patch Type: text/x-patch Size: 4385 bytes Desc: Patch for FiveAM docs. URL: From mb at bese.it Fri Sep 17 23:31:32 2004 From: mb at bese.it (marco) Date: Sat, 18 Sep 2004 01:31:32 +0200 Subject: [Bese-devel] Mistakes in FiveAM documentation In-Reply-To: <87y8j8kd0y.fsf@dirkgerrits.com> (Dirk Gerrits's message of "Fri, 17 Sep 2004 19:42:37 +0200") References: <87y8j8kd0y.fsf@dirkgerrits.com> Message-ID: Dirk Gerrits writes: > Firstly, I noticed quite a few spelling mistakes in the document. I've > attached a patch that should correct them. much abliged. > Secondly, the document refers to the "function documentation" for more > info, but I don't know where to find it. most of the functions, macros and classes in FiveAM have (relativly) detailed doc strings, i'm pretty sure that's what i was refering to. Using a recent SLIME it should be pretty easy to get at and navigate the doc strings. should that not be enough ask all the question you want, i'll answer and incorporate the answers into the current documentation. -- -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 dirk at dirkgerrits.com Sat Sep 18 10:48:06 2004 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Sat, 18 Sep 2004 12:48:06 +0200 Subject: [Bese-devel] Mistakes in FiveAM documentation In-Reply-To: (marco's message of "Sat, 18 Sep 2004 01:31:32 +0200") References: <87y8j8kd0y.fsf@dirkgerrits.com> Message-ID: <87isabkg49.fsf@dirkgerrits.com> marco writes: > Dirk Gerrits writes: > >> Firstly, I noticed quite a few spelling mistakes in the document. I've >> attached a patch that should correct them. > > much abliged. You're welcome. >> Secondly, the document refers to the "function documentation" for more >> info, but I don't know where to find it. > > most of the functions, macros and classes in FiveAM have (relativly) > detailed doc strings, i'm pretty sure that's what i was refering > to. Using a recent SLIME it should be pretty easy to get at and > navigate the doc strings. Oh of course! I thought you meant another LaTeX document. Sorry. > should that not be enough ask all the question you want, i'll answer > and incorporate the answers into the current documentation. Great. Regards, Dirk Gerrits From rm at mh-freiburg.de Sat Sep 18 22:02:54 2004 From: rm at mh-freiburg.de (Le grand pinguin) Date: Sun, 19 Sep 2004 00:02:54 +0200 Subject: [Bese-devel] Mistakes in YACLML documentation In-Reply-To: References: <87y8j8kd0y.fsf@dirkgerrits.com> Message-ID: <20040918220254.GC8548@forte.mh-freiburg.de> Ok, you don't seem to mind spellink patches. Here's one for yaclml. Greetings Ralf Mattes -------------- next part -------------- --- yaclml.tex 2004-09-17 18:35:18.000000000 +0200 +++ yaclml.tex.new 2004-09-19 00:49:29.908776496 +0200 @@ -32,11 +32,11 @@ The \yaclml{} library is designed to allow Common Lisp web application developers and graphic designers to produce HTML. -\yaclml{} provides two means to this end, a programmitc interface +\yaclml{} provides two means to this end, a programmatic interface designed for programmers and a templating interface designed for graphics artists (and their tools). -For examples of both the programmitc and the templating interface +For examples of both the programmatic and the templating interface please look at UnCommon Web, which makes heavy use of both (and provides real world examples of extending the interfaces). @@ -48,7 +48,7 @@ \begin{itemize} \item cl-who and htout \item The ZOPE project's TAL and MeTAL templating systems. -\item Terrence Parr's paper ``Enforcing Model-View Seperation in +\item Terrence Parr's paper ``Enforcing Model-View Separation in Template Engines. \end{itemize} @@ -99,7 +99,7 @@ text in a typical web page it's important to constant fold as much as possible. \item Tags should be easily definable and should be able to perform - arbitrary computiations at both run time and compile time. + arbitrary computations at both run time and compile time. \end{itemize} \section{Using \yaclml{} Tag Macros} @@ -107,7 +107,7 @@ You use \yaclml{} tags just like regular macros, any attributes are passed in like keyword arguments. \yaclml{} examines its args (at compile time) and distinguishes between the keyword arguments which -become attribues and everything else, which becames the tag's +become attributes and everything else, which becomes the tag's body. Tags all have the following syntax: \begin{verbatim} @@ -129,8 +129,8 @@ printed (via \clhs{princ}) as the value of the attribute. \end{description} -If the need ever arises to have an HTML attribute vhose value is ``T'' -or ``NIL'' it is neccessary to return the string ``T'' or ``NIL'' and +If the need ever arises to have an HTML attribute whose value is ``T'' +or ``NIL'' it is necessary to return the string ``T'' or ``NIL'' and not the symbol \sym{T} or \clhs{NIL}. \subsection{The Tag Body} @@ -158,9 +158,9 @@ \section{Standard YACLML Tag Macros} -All of the standard HTML4 tags (as specifed at +All of the standard HTML4 tags (as specified at http://www.w3.org/TR/html401). The tag macros have the same name as -the corresponding tag and the allowed attributes are thoses specified +the corresponding tag and the allowed attributes are those s specified in the standard. The tag names are all exported from the {\tt it.bese.yaclml.tags} package, which has as a nickname {\tt <}. @@ -185,12 +185,12 @@ Expands into the equivalent \sym{<:LINK} tag. -\section{Exending \yaclml{}} +\section{Extending \yaclml{}} \defmac{DEFTAG}{name attribute-lambda-list &body body} Define a new tag named \param{name}. \param{body} is run, at macro expansion -time, and must make the appropiate calls to \sym{emit-code} and +time, and must make the appropriate calls to \sym{emit-code} and \sym{emit-princ} depending on what output should be generated at run time. @@ -218,16 +218,16 @@ \begin{description} \item[required args] Like regular required args these are bound - positionally to the values passed in the aclling form. + positionally to the values passed in the calling form. \item[\&attribute] every symbol after the \&attribute tag specifies an - attribute. The calling form is examined for xeywords with the same - (under string=) symbol-name as the symbols specifiod after + attribute. The calling form is examined for keywords with the same + (under string=) symbol-name as the symbols specified after \&attribute, the corresponding values are then bound to the original symbols. \&attribute arguments can be specified in any order, when - the calling form contains multilp attributes of the same name the + the calling form contains multiple attributes of the same name the rightmost value is used. Unless an \&allow-other-attributes is specified - the attributes sperified by \&attributes are the only ones allowed. -\item [\&allow-other-attributes] the symbol folling the + the attributes specified by \&attributes are the only ones allowed. +\item [\&allow-other-attributes] the symbol following the \&allow-other-attributes marker is bound to any attributes which weren't bound to any \&attribute args. \item [\&body] Everything which isn't an attribute or a required arg @@ -247,8 +247,8 @@ bothered, to learn a new syntax, and the most common design tools, which work best with tags and attributes. -A \tal{} template is an object (reppresented internally as a function -and externally as a text file or a string) which, given an enviroment +A \tal{} template is an object (represented internally as a function +and externally as a text file or a string) which, given an environment mapping names to values and a generator which is able to locate included templates, produces some text. @@ -257,9 +257,9 @@ Given a \tal{} template (either an in-memory string or a file) We can compile this text into a function which, when called, prints to corresponding HTML on \sym{*yaclml-stream*}. The compiled function -requries two arguments: an alist mapping names (symbols) to lisp -objects (the enviroment) and a generator which is used for finding -\tal{} tomplates to include in other templates. +requires two arguments: an alist mapping names (symbols) to lisp +objects (the environment) and a generator which is used for finding +\tal{} templates to include in other templates. \section{The TAL Expression language} @@ -268,20 +268,20 @@ \begin{itemize} \item tags or attributes -which operate on values taken from the enviroment (eg: the content and +which operate on values taken from the environment (eg: the content and dolist attributes discussed below) are passed regular lisp code -(experssed as text and then converted to lisp via \clhs{READ-FROM-STRING}). +(expressed as text and then converted to lisp via \clhs{READ-FROM-STRING}). \item Inside other HTML attributes where we would like to substitute the value of some lisp code inside the textual value of the attribute. \end{itemize} When a lisp expression is expected as the value of a \tal{} attribute the '\$' read macro can be used to access values in current \tal{} -enviroment. +environment. When a string value is expected for an HTML attribute the syntax -``\${...}'' can be used to evaluate a lisp form and substitue the -result into the containg attribute value. The ``@{...}'' syntax +``\${...}'' can be used to evaluate a lisp form and substitute the +result into the contain attribute value. The ``@{...}'' syntax differs from the ``\${...}'' syntax in that the form is expected to return a list and every element of that list is embedded in the enclosing attribute. Inside the lisp forms the '\$' read macro is @@ -291,12 +291,12 @@ \tal{} templates are xml and use xml's namespace mechanism for defining the mapping from names to attribute and tag handlers. -Templates are always compilied with the default namespace bound to the +Templates are always compiled with the default namespace bound to the package \sym{:it.bese.yaclml.tags}, this allows all the standard HTML -tas to be used without problems. The namespace identifier +tags to be used without problems. The namespace identifier ``http://common-lisp.net/project/bese/tal/core'' can be used to specify the \sym{:it.bese.yaclml.tal} package which contains all the -standard \tal{} tags and attributes. If it is neccessary the +standard \tal{} tags and attributes. If it is necessary the \sym{:it.bese.yaclml.tags} namespace can be accessed via ``http://common-lisp.net/project/bese/yaclml/core''. Parameters passed to included templates need to use the @@ -328,8 +328,8 @@ \deftalatt{DOLIST}{value} \param{value} is executed and the resulting value is appended to the -current enviroment\footnote{It follows that value must return an alist - of the same form as other \tal{} enviroments}. +current environment\footnote{It follows that value must return an alist + of the same form as other \tal{} environments}. \deftaltag{TAL}{} @@ -343,7 +343,7 @@ \subsection{TAL Inclusion} \tal{} templates can be included in other templates, in order to do -this we must specify: 1) the template to include, 2) the enviroment to +this we must specify: 1) the template to include, 2) the environment to pass to the included template. Inclusion is done with the {\tt tal:include} tag. @@ -354,7 +354,7 @@ Passing values to the included template can be done via attributes, or nested param tags. Any attribute in the {\tt include} tag whose name starts with the string ``param:'' (case insensitive) is added to the -enviroment (with the associated value). The name of the param is +environment (with the associated value). The name of the param is everything after the ``param:'' string. If the include tag is not empty it's body must be a sequence of param tags. These are tags whose name, like the attributes, must start with ``param:'', they are @@ -362,14 +362,14 @@ The parameters are interned into the current package. Both attribute parameters and tag parameters are evaluated in the -containing template's enviroment and whatever text they would have +containing template's environment and whatever text they would have output on \sym{*yaclml-stream*} is passed to the included template. It is not currently possible to pass lisp objects to included tags. \section{Order of evaluation of \tal{} attributes} Multiple tag attributes can be put on the same tag, the attributes are -evaluated in left to right order. combining attributes is a convinent +evaluated in left to right order. combining attributes is a convenient and common operation. Example: we want to print a user's title in bold if the user has a @@ -380,7 +380,7 @@ \end{verb} Since the {\tt when} attribute is seen first the bold tag will be -produced (with it's contents substitued as per the {\tt content} +produced (with it's contents substituted as per the {\tt content} attribute) only when {\tt (title user)} exists (is not nil). \section{Defining TAL Tags and Attributes} From mb at bese.it Sat Sep 18 22:38:17 2004 From: mb at bese.it (marco) Date: Sun, 19 Sep 2004 00:38:17 +0200 Subject: [Bese-devel] Mistakes in YACLML documentation In-Reply-To: <20040918220254.GC8548@forte.mh-freiburg.de> (Le grand pinguin's message of "Sun, 19 Sep 2004 00:02:54 +0200") References: <87y8j8kd0y.fsf@dirkgerrits.com> <20040918220254.GC8548@forte.mh-freiburg.de> Message-ID: rm at mh-freiburg.de (Le grand pinguin) writes: > Ok, you don't seem to mind spellink patches. Here's one for > yaclml. thanks, my speelling sucks. p.s. - I WILL TAKE ANY AND ALL THE HELP I CAN GET. (god knows i need it). -- -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 ajuckel at gmail.com Tue Sep 21 01:53:24 2004 From: ajuckel at gmail.com (Anthony Juckel) Date: Mon, 20 Sep 2004 20:53:24 -0500 Subject: [Bese-devel] :template options referring to data within the "current" component Message-ID: I'm still relatively new to the internals of UCW, so the following may be a very simple question. Is there a way to refer to the current component when supplying :template options? For example, I have a set of classes: foo, bar and baz. The basic interaction for dealing with each of these objects is the same, I only wish for the template to be different depending on which is being edited. What seems reasonable, would be to have a component defined as such: (defcomponent editor (standard-component) ((object :accessor object :initarg :object)) (:template (get-edit-template-for-object _object_))) Then, I have get-edit-template-for-object defined for any object that I can safely pass to this editor component. The problem is, _object_ in the above is an unbound symbol. I see that gen-component-default-render-on (from standard-component.lisp) generates a defmethod form which gives the default render-on implementation when :template is used. This defmethod uses gensyms for the response and component parameters. Would it be reasonable to make one or both of these standard symbols? Users would have to be aware that, for example, 'response and 'component are already bound within the body of their :template form, but that seems a rather small price to pay to be able to have components using templates refer to themselves when deciding on a template (or tal environment bindings). I've made this change locally, and in simple tests nothing seems to break. Does anyone see any problems with this approach? On the other hand, perhaps I'm reading this all wrong and what I want is already available some other way... Anthony W. Juckel From mb at bese.it Tue Sep 21 08:05:44 2004 From: mb at bese.it (marco) Date: Tue, 21 Sep 2004 10:05:44 +0200 Subject: [Bese-devel] :template options referring to data within the "current" component In-Reply-To: (Anthony Juckel's message of "Mon, 20 Sep 2004 20:53:24 -0500") References: Message-ID: Anthony Juckel writes: > I'm still relatively new to the internals of UCW, so the following may > be a very simple question. not really no. it's something i would never have thought about doing, but sounds pretty cool now that you mention it. > Is there a way to refer to the current component when supplying > :template options? for the name of the template, no, for the environment yes. > For example, I have a set of classes: foo, bar and baz. The basic > interaction for dealing with each of these objects is the same, I only > wish for the template to be different depending on which is being > edited. > > What seems reasonable, would be to have a component defined as such: > > (defcomponent editor (standard-component) > ((object :accessor object :initarg :object)) > (:template (get-edit-template-for-object _object_))) > > Then, I have get-edit-template-for-object defined for any object that > I can safely pass to this editor component. The problem is, _object_ > in the above is an unbound symbol. the second form in the :template option (the one which creates the template's environment) _can_ access the current component via the symbol , however i had always assumed the template file name would be a string so i didn't consider adding this to the entire :template option. > I see that gen-component-default-render-on (from > standard-component.lisp) generates a defmethod form which gives the > default render-on implementation when :template is used. This > defmethod uses gensyms for the response and component parameters. > Would it be reasonable to make one or both of these standard symbols? > Users would have to be aware that, for example, 'response and > 'component are already bound within the body of their :template form, > but that seems a rather small price to pay to be able to have > components using templates refer to themselves when deciding on a > template (or tal environment bindings). I've made this change > locally, and in simple tests nothing seems to break. Does anyone see > any problems with this approach? it seems ok with me, but i would continue binding the component to a symbol of the same name as the component class. > On the other hand, perhaps I'm reading this all wrong and what I want > is already available some other way... what i'd immagine you'd do in this case is something like: (defcomponent editor (standard-component) ((object :accessor object :initarg :object))) (defmethod rendor-on ((res response) (editor editor)) (render-template *context* (get-edit-template-for-object editor) (get-edit-environment-for-object editor))) that said i see nothing wrong with your solution, though i would like to think about it a bit more. i'm currently entertaining the idea of rewriting some the defcomponent stuff to use a much more functional API, currently there are lots of things the defcomponent macro does for you which you simply can't do on your own without cut 'n pasting code from standard-component.lisp. -- -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 Fri Sep 24 07:52:57 2004 From: mb at bese.it (marco) Date: Fri, 24 Sep 2004 09:52:57 +0200 Subject: [Bese-devel] file uploading Message-ID: last night i commited an implementation of file uploading (which basically ammounted to ripping janis dzerins' rfc2388 implementation :)). when one of our form values is a file (aka when it's Content-Type isn't text/plain) what should the corresponding value (put in slots or accessed via an entry point's parameters) be? a simple string can't really cut it since the associated info (original file name, content type, etc.) is usefull. probably it will have to become an object (which i'll integrate into the backend protocol) but if someone has other preferences i'd love to hear them. -- -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 Fri Sep 24 08:03:20 2004 From: mb at bese.it (marco) Date: Fri, 24 Sep 2004 10:03:20 +0200 Subject: [Bese-devel] defcomponent Message-ID: currently i have two issues with the defcomponent macro: 1) it defines a shared-initialize :after method which does Important Stuff (TM) so you (the developer) can't define your own. 2) it implements a convient render-on method for templates which you can't (bar cut 'n paste) re-use. So i'd like to make defcomponent a bit less opaque. My solution to #1 would be to make that code into an initialize-component method which would be called by call-component, goto-component and replace-component. what's currently done in that shared-initialize :after method really should only be done when the component is call'd, and this change would allow you to create component objects outside of the rerl (which you currently can't do due to the dependency on *context* having a "real" value). #2 could be delt with by simply maving the code generated by defcomponent into a method (or macro) which developers could then call directly (and it would provide a place to hang some documentation off of (which is always a Good Smell (TM))). the other option would be to do this via the MOP. which my be cool (at least i thought it wolud be kind of cool at first) appears (after trying to actually implement it) be to more complex and opaque than what i'd like it to replace. anybody have an opinion they want to share? -- -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 rm at fabula.de Fri Sep 24 08:05:45 2004 From: rm at fabula.de (rm at fabula.de) Date: Fri, 24 Sep 2004 10:05:45 +0200 Subject: [Bese-devel] file uploading In-Reply-To: References: Message-ID: <20040924080545.GA25767@www> On Fri, Sep 24, 2004 at 09:52:57AM +0200, marco wrote: > > last night i commited an implementation of file uploading (which > basically ammounted to ripping janis dzerins' rfc2388 implementation > :)). when one of our form values is a file (aka when it's Content-Type > isn't text/plain) what should the corresponding value (put in slots or > accessed via an entry point's parameters) be? a simple string can't > really cut it since the associated info (original file name, content > type, etc.) is usefull. probably it will have to become an object > (which i'll integrate into the backend protocol) but if someone has > other preferences i'd love to hear them. Hi Marco, did you see the recent anouncement for mel-base on cliki? I only had a quick glance at it but it looks like there's quite a nice wrapper arround mime objects. HTH Ralf Mattes > -- > -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 > > _______________________________________________ > bese-devel mailing list > bese-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/bese-devel From rm at fabula.de Sun Sep 26 12:21:05 2004 From: rm at fabula.de (rm at fabula.de) Date: Sun, 26 Sep 2004 14:21:05 +0200 Subject: [Bese-devel] Dangling download link Message-ID: <20040926122105.GB8897@www> Hello Marco, the download link to ucw-0.3.0 on points to ucw_0.2.3. Ralf Mattes