From hbabcockos1 at mac.com Thu Jun 1 01:21:55 2006 From: hbabcockos1 at mac.com (hbabcockos1 at mac.com) Date: Wed, 31 May 2006 21:21:55 -0400 Subject: [Bese-devel] Re: utf-8 encoding problem In-Reply-To: References: <0E875E0C-8AE6-4807-8584-DE1D4EFA7D77@mac.com> Message-ID: <5B270672-1B6F-4696-8A5D-991571EBAE5F@mac.com> On May 30, 2006, at 6:52 AM, Marco Baringer wrote: > > we've recently tried to make utf-8 output easier, or so we thought... It is easy once you figure out what you are doing :). Thanks all for the help and suggestions! The root of the problem was my confusion concerning 'character, '(unsigned-byte 8) and unicode strings. -Hazen From marijnh at gmail.com Thu Jun 1 11:55:08 2006 From: marijnh at gmail.com (Marijn Haverbeke) Date: Thu, 1 Jun 2006 13:55:08 +0200 Subject: [Bese-devel] I am unsure whether this is a bug or me being dumb, but when I add an From marijnh at gmail.com Fri Jun 2 10:18:38 2006 From: marijnh at gmail.com (Marijn Haverbeke) Date: Fri, 2 Jun 2006 12:18:38 +0200 Subject: [Bese-devel] Hi again, After happily playing with the From marijnh at gmail.com Fri Jun 2 11:44:49 2006 From: marijnh at gmail.com (Marijn Haverbeke) Date: Fri, 2 Jun 2006 13:44:49 +0200 Subject: [Bese-devel] Re: References: Message-ID: > After happily playing with the :accessors for a while, I came across situations where I needed to have > javascript read and write to the value of such elements client-side. Since > their values all seem to contain mysteriously hashed strings, this will not > work. Is there a way around this? For example a way to turn off the hashing > (it seems that is only necessary if you want to store lisp objects in them). > Right now I'm messily working around them by using normal input fields and > reading the post values from the request in order to store them in my > component again... basically re-implementing the :accessor functionality. > Of course, in my previous mail I was actually only referring to 'select' and 'hidden' tags, because other kinds can be manipulated in javascript just fine. Also, I think there is a bug with From mb at bese.it Sun Jun 4 17:14:22 2006 From: mb at bese.it (Marco Baringer) Date: Sun, 04 Jun 2006 19:14:22 +0200 Subject: [Bese-devel] Re: Message-ID: "Marijn Haverbeke" writes: > ...the select element will indeed allow multiple rows to be selected, and the > value that is put into the component slot is indeed a list instead of a single > value, but it only contains one element, even when I select multiple elements > before submitting. How do I fix this? what backend is this? -- -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 Jun 4 17:18:23 2006 From: mb at bese.it (Marco Baringer) Date: Sun, 04 Jun 2006 19:18:23 +0200 Subject: [Bese-devel] Re: Message-ID: "Marijn Haverbeke" writes: > Hi again, > > After happily playing with the :accessors for a while, I came across situations where I needed to have > javascript read and write to the value of such elements client-side. Since > their values all seem to contain mysteriously hashed strings, this will not > work. Is there a way around this? For example a way to turn off the hashing (it > seems that is only necessary if you want to store lisp objects in them). Right > now I'm messily working around them by using normal input fields and reading > the post values from the request in order to store them in my component > again... basically re-implementing the :accessor functionality. all the tags take a :name parameter (and if they don't it's a bug) which allows you to specify what http request parameter name to use. all the tags also take an :id parameter, you can set that and then use document.getElementById or whatever. the form stuff (src/components/form.lisp) makes a lot of this easier, you could look into those. > Also, it seems that there is no way to get at the parameters of a request > object without using internal ucw symbols. Is this intentional, or also a case > of forgetting to export a symbol? get-parameter sholud have been exported, my bad. -- -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 steve at salkin.org Tue Jun 6 05:12:56 2006 From: steve at salkin.org (Steve Salkin) Date: Tue, 06 Jun 2006 01:12:56 -0400 Subject: [Bese-devel] backtracking.lisp: compile issue Message-ID: <44850ED8.6090409@salkin.org> Hi, I wonder if this rings a bell with anyone? The code doesn't look problematic to me at a glance, but I am not really used to CPS/arnesi style. ; compiling file "/home/steve/.sbcl/site/ucw_dev/src/rerl/backtracking.lisp" (written 27 MAY 2006 08:18:37 AM): ; compiling (IN-PACKAGE :IT.BESE.UCW) ; compiling (DEFMACRO MAKE-PLACE ...) ; compiling (DEFMETHOD PLACE ...) ; file: /home/steve/.sbcl/site/ucw_dev/src/rerl/backtracking.lisp ; in: DEFMETHOD PLACE (PLACE) ; (DEFMETHOD IT.BESE.UCW::PLACE ; ((IT.BESE.UCW::PLACE IT.BESE.UCW::PLACE)) ; "Returns the current value of PLACE." ; (ETYPECASE (IT.BESE.UCW::PLACE.GETTER IT.BESE.UCW::PLACE) ; (FUNCTION ; (FUNCALL (IT.BESE.UCW::PLACE.GETTER IT.BESE.UCW::PLACE))) ; (IT.BESE.ARNESI::CLOSURE/CC ; (IT.BESE.ARNESI:WITH-CALL/CC (FUNCALL #))))) ; ; caught WARNING: ; Reference to unknown variable PLACE. ; compiling (DEFMETHOD (SETF PLACE) ...) ; file: /home/steve/.sbcl/site/ucw_dev/src/rerl/backtracking.lisp ; in: DEFMETHOD (SETF PLACE) (T PLACE) ; (DEFMETHOD (SETF IT.BESE.UCW::PLACE) ; (IT.BESE.UCW:VALUE (IT.BESE.UCW::PLACE IT.BESE.UCW::PLACE)) ; "Set the value of PLACE to VALUE." ; (ETYPECASE (IT.BESE.UCW::PLACE.SETTER IT.BESE.UCW::PLACE) ; (FUNCTION ; (FUNCALL (IT.BESE.UCW::PLACE.SETTER IT.BESE.UCW::PLACE) ; IT.BESE.UCW:VALUE)) ; (IT.BESE.ARNESI::CLOSURE/CC ; (IT.BESE.ARNESI:WITH-CALL/CC (FUNCALL # IT.BESE.UCW:VALUE))))) ; ; caught WARNING: ; Reference to unknown variable PLACE. ; ; caught WARNING: ; Reference to unknown variable VALUE. Details: On a fresh checkout of ucw_dev with no old fasls, using sbcl 0.9.13.8, I ran sbcl and did the following: (require 'asdf) (asdf:oos 'asdf:load-op :fiveam) ; needed because the next line bombs otherwise (load "/home/steve/.ucw/start.lisp") ~/.ucw has copies of start.lisp, stop.lisp, conf.lisp, ucwctl.conf with appropriate values for this machine Any thoughts appreciated :) S- From attila.lendvai at gmail.com Tue Jun 6 07:31:41 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Tue, 6 Jun 2006 09:31:41 +0200 Subject: [Bese-devel] backtracking.lisp: compile issue In-Reply-To: <44850ED8.6090409@salkin.org> References: <44850ED8.6090409@salkin.org> Message-ID: > ; in: DEFMETHOD PLACE (PLACE) > ; (DEFMETHOD IT.BESE.UCW::PLACE > ; ((IT.BESE.UCW::PLACE IT.BESE.UCW::PLACE)) > ; "Returns the current value of PLACE." > ; (ETYPECASE (IT.BESE.UCW::PLACE.GETTER IT.BESE.UCW::PLACE) > ; (FUNCTION > ; (FUNCALL (IT.BESE.UCW::PLACE.GETTER IT.BESE.UCW::PLACE))) > ; (IT.BESE.ARNESI::CLOSURE/CC > ; (IT.BESE.ARNESI:WITH-CALL/CC (FUNCALL #))))) > ; > ; caught WARNING: > ; Reference to unknown variable PLACE. recently Marco enabled arnesi call/cc warnings for unknown variable references and it's probably a bug with defmethod's argument handling in the cps transform. i've seen this here, too... > On a fresh checkout of ucw_dev with no old fasls, using sbcl 0.9.13.8, I > ran sbcl and did the following: > (require 'asdf) > (asdf:oos 'asdf:load-op :fiveam) ; needed because the next line bombs > otherwise this is a bug in rfc2109.asd i have a patch for locally with another small bugfix. if somebody can add me (alendvai) to the group i can check them in. or i'll send the patch, but i've warned the author about the missing 5am dependency long ago. - attila (alias 101 on irc &no 'its not lisp code :) From marijnh at gmail.com Wed Jun 7 11:50:21 2006 From: marijnh at gmail.com (Marijn Haverbeke) Date: Wed, 7 Jun 2006 13:50:21 +0200 Subject: [Bese-devel] A field class for multiple select inputs Message-ID: Hi, Following is a field class for select elements that allow you to select more than one options. Unless I missed something, there is no class yet for select elements like that. This could be added to components/form.lisp to implement that. BUT, you'll probably notice the really ugly hack with the hidden input whose callback grabs all the values for the select input out of the parameters. If there is a better way to run code when a request is made I'd like to hear about it, so I can make a prettier implementation. Maybe the callback mechanism needs some rethinking anyway? The (setf (client-value field) nil) in the render method of checkbox-field is also a case of code that should always be run before the parameters are handled, and does not really belong in a render method. Maybe add a way to register special callbacks for a form that allways run before the other callbacks? It seems forms already add a hidden variable to identify themselves, that could be used to decide which form-specific callbacks are run. Currently normal callbacks are not form-specific, are they? I mean, if there are two forms on a page, and both have a field called 'name', will the two callbacks for those fields coexist peacefully or will they override each other? Also, did you know that many xxx-field classes ignore the :name slot and just generate a random name (though make-new-callback)? Is this a bug or a feature? Well, here's the code, for what it's worth: (defclass multiple-select-field (select-field) () (:default-initargs :name (random-string 8) :client-value ())) (defmethod render ((field multiple-select-field)) (<:ai (value field)) (<:input :type "hidden" :value "x" :name (make-new-callback (lambda (value) (declare (ignore value)) (do ((vars (slot-value (context.request *context*) 'parameters) (cdr vars)) (result ())) ((null vars) (setf (client-value field) result)) (if (string= (caar vars) (name field)) (push (cdar vars) result)))))) (<:select :name (name field) :tabindex (tabindex field) :multiple t (setf (data-map field) (build-data-map field)) (render-options field))) (defmethod render-options ((field multiple-select-field)) (dolist* ((key-string . value) (data-map field)) (<:option :value key-string :selected (member key-string (client-value field) :test #'string=) (render-value field value)))) (defmethod value ((field multiple-select-field)) (mapcar (lambda (x) (cdr (assoc x (data-map field) :test #'string=))) (client-value field))) -------------- next part -------------- An HTML attachment was scrubbed... URL: From marijnh at gmail.com Wed Jun 7 11:54:57 2006 From: marijnh at gmail.com (Marijn Haverbeke) Date: Wed, 7 Jun 2006 13:54:57 +0200 Subject: [Bese-devel] Re: A field class for multiple select inputs In-Reply-To: References: Message-ID: Grrr, there was still debug code in that snipped. How clumsy! Here's it again without the extra <:ai call. (defclass multiple-select-field (select-field) () (:default-initargs :name (random-string 8) :client-value ())) (defmethod render ((field multiple-select-field)) (<:input :type "hidden" :value "x" :name (make-new-callback (lambda (value) (declare (ignore value)) (do ((vars (slot-value (context.request *context*) 'parameters) (cdr vars)) (result ())) ((null vars) (setf (client-value field) result)) (if (string= (caar vars) (name field)) (push (cdar vars) result)))))) (<:select :name (name field) :tabindex (tabindex field) :multiple t (setf (data-map field) (build-data-map field)) (render-options field))) (defmethod render-options ((field multiple-select-field)) (dolist* ((key-string . value) (data-map field)) (<:option :value key-string :selected (member key-string (client-value field) :test #'string=) (render-value field value)))) (defmethod value ((field multiple-select-field)) (mapcar (lambda (x) (cdr (assoc x (data-map field) :test #'string=))) (client-value field))) -------------- next part -------------- An HTML attachment was scrubbed... URL: From marijnh at gmail.com Wed Jun 7 12:11:30 2006 From: marijnh at gmail.com (Marijn Haverbeke) Date: Wed, 7 Jun 2006 14:11:30 +0200 Subject: [Bese-devel] dom-id's in xxx-select-field elements Message-ID: Hi, I'm really spamming this list now, but I think in the render function for select-field it should say :id (dom-id field) somewhere inside the <:select call, because as it stands now it is ignoring the :dom-id initarg. Also, is there a way to make select inputs where you can specify both the values and text of the options? I thought alist-select-field would do this, but it just uses the keys of the alist as tags and ignores the rest of the list. I have a field that shows strings that can vary (because of internationalization), which represent a limited set of options, so I wanted to use a fixed set of values but also specify other option tag texts, if you get what I mean. Regards, Marijn -------------- next part -------------- An HTML attachment was scrubbed... URL: From mb at bese.it Wed Jun 7 12:59:07 2006 From: mb at bese.it (Marco Baringer) Date: Wed, 07 Jun 2006 14:59:07 +0200 Subject: [Bese-devel] (setf container.current-component) returns t when the set actually happened Message-ID: setf methods must return the new value, i don't think this is actually written anywhere in the standard but every single setf method i have ever seen does this. why was this change made? -- -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 attila.lendvai at gmail.com Wed Jun 7 13:24:32 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Wed, 7 Jun 2006 15:24:32 +0200 Subject: [Bese-devel] (setf container.current-component) returns t when the set actually happened In-Reply-To: References: Message-ID: > setf methods must return the new value, i don't think this is actually > written anywhere in the standard but every single setf method i have > ever seen does this. > > why was this change made? in my code i'm using this to do different things if the setf actually happened. i was considering this issue myself, but i've never seen code relying on the return value of setf. doing the check for the current component from outside the container code needs to rely on container behaviour/internals, so it's not an option. so, i'm open to suggestions! maybe there should be a set-current-component that does the same as the setf but returns this extra information? -- - attila (alias 101 on irc &no 'its not lisp code :) From marijnh at gmail.com Wed Jun 7 13:37:23 2006 From: marijnh at gmail.com (Marijn Haverbeke) Date: Wed, 7 Jun 2006 15:37:23 +0200 Subject: [Bese-devel] Events for input field objects In-Reply-To: References: Message-ID: (I got a bounce for this mail, so I'm re-sending it... if you're lucky you aren't getting it twice.) --------- Forwarded message ---------- From: Marijn Haverbeke Date: Jun 7, 2006 2:58 PM Subject: Events for input field objects To: bese-devel at common-lisp.net Hey, I added some stuff to the generic-html-input class to allow client code to register extra events on the form elements. If anybody is actually looking at the code I'm mailing here, tell me, and I'll try to actually create a decent diff the next time. Is just pasting diffs into an email the way to do that, or do you attach them? Or maybe there's some kind of special darcs format? What this does is add an extra initarg :events to the generic-html-input class, to which to you can pass a list of (eventname . javascript) lists, for example '(("onchange" (call-js-function-1) (return true)) - the two elements in the cdr will be put into the javascript lambda that is registered for the event. Anyway, I added the events slot here: (defclass generic-html-input (form-field) ((dom-id :accessor dom-id :initarg :dom-id :initform (js:gen-js-name-string :prefix "_ucw_")) (client-value :accessor client-value :initarg :client-value :initform "" :documentation "The string the client submitted along with this field.") (name :accessor name :initarg :name :initform nil) (tabindex :accessor tabindex :initarg :tabindex :initform nil) (events :accessor events :initarg :events :initform nil))) And the first when clause in the render method is also new: (defmethod render :after ((field generic-html-input)) (when (events field) ( From mb at bese.it Wed Jun 7 13:31:35 2006 From: mb at bese.it (Marco Baringer) Date: Wed, 07 Jun 2006 15:31:35 +0200 Subject: [Bese-devel] (setf container.current-component) returns t when the set actually happened In-Reply-To: (Attila Lendvai's message of "Wed, 7 Jun 2006 15:24:32 +0200") References: Message-ID: "Attila Lendvai" writes: > doing the check for the current component from outside the container > code needs to rely on container behaviour/internals, so it's not an > option. > > so, i'm open to suggestions! maybe there should be a > set-current-component that does the same as the setf but returns this > extra information? it's only the primary value which is fixed, how about returning (values new-value t-or-nil)? -- -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 marijnh at gmail.com Thu Jun 8 20:44:36 2006 From: marijnh at gmail.com (Marijn Haverbeke) Date: Thu, 8 Jun 2006 22:44:36 +0200 Subject: [Bese-devel] Re: dom-id's in xxx-select-field elements In-Reply-To: References: Message-ID: I'm just replying to myself, don't mind me :P On 6/7/06, Marijn Haverbeke wrote: > > Also, is there a way to make select inputs where you can specify both the > values and text of the options? I thought alist-select-field would do this, > but it just uses the keys of the alist as tags and ignores the rest of the > list. I have a field that shows strings that can vary (because of > internationalization), which represent a limited set of options, so I wanted > to use a fixed set of values but also specify other option tag texts, if you > get what I mean. > In the meantime I have figured out what alist-select-fields do, but they work exactly backward from what I would expect. I was expecting I could pass it an alist of (key . label) pairs, and it would show the labels to the users and give me back the keys as values. Right now it works rather oddly, the cars of the pairs are used as labels and the cdrs as keys, but when you want to pass it a :value (or even :client-value) to use as a default you have to use the car value (which, in my case, is a string that will be different for different clients due to translation and is really unsuitable for that kind of thing). My question is, is anybody very attached to the way the ...-select-field classes currently work, or would it be a good idea if I overhauled them to be a bit more consistent? It's also rather hard to make them support the multiple attribute (see my other mail) without lots of duplicated code the way they work now. How stable should the external interface of ucw be considered? There might be some other things that I would prefer to be done in another way, but I'd rather not make myself impossible by raging in here like a drunken elephant and tell you all how things should be. Marijn -------------- next part -------------- An HTML attachment was scrubbed... URL: From marijnh at gmail.com Thu Jun 8 21:01:40 2006 From: marijnh at gmail.com (Marijn Haverbeke) Date: Thu, 8 Jun 2006 23:01:40 +0200 Subject: [Bese-devel] Changing the css-class of input fields (when they are wrapped in field objects) Message-ID: Again about the form-field classes - they currently inherit from widget-component, which gives them a css-class slot. Only in a lot of cases the behaviour this implements is not what you want - wrapping something in a DIV with a class is rarely equivalent to just giving it that class, and I need some of my input fields to have a certain class. (And I dislike superfluous DIV elements anyway.) Maybe add an extra slot called field-class or something to generic-html-input, and have the render functions include it in the output? This (combined with the events slot I suggested in another mail) is kind of starting to sound like a bloated interface... But both events and class are rather fundamental properties of HTML that you're going to have to be able to have control over sooner or later in practically every project. Now that I'm thinking about this, do input field objects really need to inherit from widget-component? In my experience just wrapping something in a DIV to apply style to it is usually not such a great idea, and the widget-component functionality is rather orthogonal to what the generic-html-input classes are implementing - people could inherit from both if they really wanted an input field with a DIV around it. Thoughts? Marijn -------------- next part -------------- An HTML attachment was scrubbed... URL: From vanek at acd.net Thu Jun 8 21:37:01 2006 From: vanek at acd.net (Lou Vanek) Date: Thu, 08 Jun 2006 21:37:01 +0000 Subject: [Bese-devel] Re: Changing the css-class of input fields (when they are wrapped in field objects) In-Reply-To: References: Message-ID: I agree a css-class slot is fundamental and would be welcome by me. I don't consider adding a css-class slot bloated because you're then able to push off a lot of html-cosmetic stuff out of the code (and into the css file where it belongs). I'm not far enough along to comment knowledgably about your last point (I'm still trying to get the examples to run on clisp/araneida). But I agree that wrapping-DIVs should be avoided if the HTML spec allows the characteristic/class/attribute to be specified in the target HTML widget/INPUT/etc. -lv -- Our lives begin to end the day we become silent about the things that matter. Dr. ML King, from a jail cell in Birmingham, Alabama in 1963. Marijn Haverbeke wrote: > Again about the form-field classes - they currently inherit from > widget-component, which gives them a css-class slot. Only in a lot of > cases the behaviour this implements is not what you want - wrapping > something in a DIV with a class is rarely equivalent to just giving it > that class, and I need some of my input fields to have a certain class. > (And I dislike superfluous DIV elements anyway.) > > Maybe add an extra slot called field-class or something to > generic-html-input, and have the render functions include it in the > output? This (combined with the events slot I suggested in another mail) > is kind of starting to sound like a bloated interface... But both events > and class are rather fundamental properties of HTML that you're going to > have to be able to have control over sooner or later in practically > every project. > > Now that I'm thinking about this, do input field objects really need to > inherit from widget-component? In my experience just wrapping something > in a DIV to apply style to it is usually not such a great idea, and the > widget-component functionality is rather orthogonal to what the > generic-html-input classes are implementing - people could inherit from > both if they really wanted an input field with a DIV around it. Thoughts? > > Marijn > > > ------------------------------------------------------------------------ > > _______________________________________________ > bese-devel mailing list > bese-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel From vanek at acd.net Thu Jun 8 21:55:29 2006 From: vanek at acd.net (Lou Vanek) Date: Thu, 08 Jun 2006 21:55:29 +0000 Subject: [Bese-devel] Re: dom-id's in xxx-select-field elements In-Reply-To: References: Message-ID: <44889CD1.8070601@acd.net> Dear Drunken Elephant :) I'm kinda new around these here corners of the net, but allow me to add my thoughts. The external interface seems to be in flux (the examples don't even compile any more due to interface changes). So changing things around to be more consistent seems more than workable. I would go ahead and make the changes, create a few patches, and submit 'em. What's the worst that can happen? You get a code base that's more to your liking (it's partially YOUR code), and Marco may decide not to merge your changes. But that doesn't change the fact that you have changed ucw more to your liking. Your changes remain intact every time you run darcs (unless of course the SELECT code is changed in the future, but then you can simply refuse that patch). I've been working on several patches myself. I'll probably be submitting them in the next day or two. I'm trying to get ucw to play nice with clisp and araneida. Marco's code walker has my head hurting, but the worst is over. Lou Vanek -- To sin by silence when they should protest makes cowards of men. --Abraham Lincoln [sorry if this is a double post -- gmane is acting up] Marijn Haverbeke wrote: > I'm just replying to myself, don't mind me :P > > On 6/7/06, *Marijn Haverbeke* > wrote: > > Also, is there a way to make select inputs where you can specify > both the values and text of the options? I thought > alist-select-field would do this, but it just uses the keys of the > alist as tags and ignores the rest of the list. I have a field that > shows strings that can vary (because of internationalization), which > represent a limited set of options, so I wanted to use a fixed set > of values but also specify other option tag texts, if you get what I > mean. > > > In the meantime I have figured out what alist-select-fields do, but they > work exactly backward from what I would expect. I was expecting I could > pass it an alist of (key . label) pairs, and it would show the labels to > the users and give me back the keys as values. Right now it works rather > oddly, the cars of the pairs are used as labels and the cdrs as keys, > but when you want to pass it a :value (or even :client-value) to use as > a default you have to use the car value (which, in my case, is a string > that will be different for different clients due to translation and is > really unsuitable for that kind of thing). > > My question is, is anybody very attached to the way the ...-select-field > classes currently work, or would it be a good idea if I overhauled them > to be a bit more consistent? It's also rather hard to make them support > the multiple attribute (see my other mail) without lots of duplicated > code the way they work now. > > How stable should the external interface of ucw be considered? There > might be some other things that I would prefer to be done in another > way, but I'd rather not make myself impossible by raging in here like a > drunken elephant and tell you all how things should be. > > Marijn > > > ------------------------------------------------------------------------ > > _______________________________________________ > bese-devel mailing list > bese-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel From marijnh at gmail.com Fri Jun 9 12:20:56 2006 From: marijnh at gmail.com (Marijn Haverbeke) Date: Fri, 9 Jun 2006 14:20:56 +0200 Subject: [Bese-devel] Having a simple-form call an action Message-ID: Hi, Is there a way to make an object that inherits from simple-form call an action when submitted, the way the From marijnh at gmail.com Fri Jun 9 12:49:43 2006 From: marijnh at gmail.com (Marijn Haverbeke) Date: Fri, 9 Jun 2006 14:49:43 +0200 Subject: [Bese-devel] Re: Having a simple-form call an action In-Reply-To: References: Message-ID: > > Is there a way to make an object that inherits from simple-form call an > action when submitted, the way the :action argument? > Well, it seems I am confused. Defining a refresh-component for my form class does allow me to do something when the form is submitted, but it's not quite what I needed. Firstly, I what I want to do is call an action on the component that this form is a part of. Now I keep a parent reference to that in my form component, but that is a bit crummy. Second, when I try to call answer from this refresh-component method it complains that the form's calling-component slot is unbound. Which I guess it is... the user got to that page by clicking a link that called an action which called the component that this form is a part of. What I expected was that when I call answer, it will return from the last component that was called... but apparantly that is not the case. How can I implement the behaviour of a form that does some checking and then answers from the current component when it is submitted? Thanks, Marijn -------------- next part -------------- An HTML attachment was scrubbed... URL: From marijnh at gmail.com Fri Jun 9 12:54:00 2006 From: marijnh at gmail.com (Marijn Haverbeke) Date: Fri, 9 Jun 2006 14:54:00 +0200 Subject: [Bese-devel] Re: Having a simple-form call an action In-Reply-To: References: Message-ID: Ho hum. I swear I really do think about these things before mailing, but it seems I had missed the answer-component function. So what I do now is get the parent reference from the form, and call answer-component on that in the refresh-component method of the form. Is this more or less the intended way? I'd still prefer to directly call an action on the parent component and go without the ugly parent pointer altogether. Well, it seems I am confused. Defining a refresh-component for my form class > does allow me to do something when the form is submitted, but it's not quite > what I needed. Firstly, I what I want to do is call an action on the > component that this form is a part of. Now I keep a parent reference to that > in my form component, but that is a bit crummy. Second, when I try to call > answer from this refresh-component method it complains that the form's > calling-component slot is unbound. Which I guess it is... the user got to > that page by clicking a link that called an action which called the > component that this form is a part of. What I expected was that when I call > answer, it will return from the last component that was called... but > apparantly that is not the case. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdanish at andrew.cmu.edu Fri Jun 9 14:26:33 2006 From: mdanish at andrew.cmu.edu (Matthew Danish) Date: Fri, 9 Jun 2006 10:26:33 -0400 Subject: [Bese-devel] Re: UCW performance In-Reply-To: References: Message-ID: <20060609142633.GC28533@mapcar.org> On Fri, May 26, 2006 at 04:03:37PM +0200, Marco Baringer wrote: > Marco Baringer writes: > > > wrapping the dispatchers in a TIME form is pretty easy (though > > collecting the output will require some non-protable code), but i > > think you'd be much better off using your lisp's profiler. > > fwiw i mean something like this: > > (in-package :ucw) > > (defmethod handle-request :around ((server standard-server) > (request request) > (response response)) > (time (call-next-method))) > TIME isn't really meant to be called from the non-top-level, or programmatically, for that matter. Better off to use GET-INTERNAL-RUN-TIME, plus, collecting the output will be less troublesome. Some interesting statistical profiling add-on could be imagined using this and method combination, I suppose. -- ;; Matthew Danish -- user: mrd domain: cmu.edu ;; OpenPGP public key: C24B6010 on keyring.debian.org From mdanish at andrew.cmu.edu Fri Jun 9 14:18:03 2006 From: mdanish at andrew.cmu.edu (Matthew Danish) Date: Fri, 9 Jun 2006 10:18:03 -0400 Subject: [Bese-devel] Re: References: Message-ID: <20060609141803.GB28533@mapcar.org> On Fri, Jun 02, 2006 at 01:44:49PM +0200, Marijn Haverbeke wrote: > Also, I think there is a bug with - browsers do not seem to add a variable to a request for an unchecked > checkbox, causing the :accessor or :writer on such tags to never run when > the box is unchecked. This is true; I recently was puzzled by this, and ended up "working around" by clearing out the value while rendering the page each time. -- ;; Matthew Danish -- user: mrd domain: cmu.edu ;; OpenPGP public key: C24B6010 on keyring.debian.org From mb at bese.it Fri Jun 9 14:52:21 2006 From: mb at bese.it (Marco Baringer) Date: Fri, 09 Jun 2006 16:52:21 +0200 Subject: [Bese-devel] Re: Having a simple-form call an action References: Message-ID: "Marijn Haverbeke" writes: > Ho hum. I swear I really do think about these things before mailing, but it > seems I had missed the answer-component function. So what I do now is get the > parent reference from the form, and call answer-component on that in the > refresh-component method of the form. Is this more or less the intended way? > I'd still prefer to directly call an action on the parent component and go > without the ugly parent pointer altogether. (it the case of simple-form the call to refresh-component is hard wired, that's a horrible name and it should probbaly become submit or something). the only thing simple-form adds to widget component is the automatic writing of the
tag, are you sure you don't want to just drop the simple-form superclas and write your own Message-ID: "Marijn Haverbeke" writes: > Again about the form-field classes - they currently inherit from > widget-component, which gives them a css-class slot. Only in a lot of cases the > behaviour this implements is not what you want - wrapping something in a DIV > with a class is rarely equivalent to just giving it that class, and I need some > of my input fields to have a certain class. (And I dislike superfluous DIV > elements anyway.) what would work (and is a good idea now that you bring it up) is an html-element class of which widget class (with its current behaviour) and generic-html-input are subclasses of. html-element would have slots for style, class, id, onclick, etc. widget-class would maintain its current behaviour and the form stuff would avoid spurious divs. -- -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 Jun 9 15:37:45 2006 From: mb at bese.it (Marco Baringer) Date: Fri, 09 Jun 2006 17:37:45 +0200 Subject: [Bese-devel] Re: UCW performance References: <20060609142633.GC28533@mapcar.org> Message-ID: Matthew Danish writes: > Some interesting statistical profiling add-on could be imagined using > this and method combination, I suppose. tried sb-sprof? -- -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 Jun 9 15:36:36 2006 From: mb at bese.it (Marco Baringer) Date: Fri, 09 Jun 2006 17:36:36 +0200 Subject: [Bese-devel] Re: dom-id's in xxx-select-field elements References: <44889CD1.8070601@acd.net> Message-ID: Lou Vanek writes: > The external interface seems to be in flux (the examples > don't even compile any more due to interface changes). So > changing things around to be more consistent seems more than > workable. can you paste the error? they seem to work on my copy of ucw_dev :( > I would go ahead and make the changes, create a few patches, > and submit 'em. What's the worst that can happen? You get > a code base that's more to your liking (it's partially YOUR > code), and Marco may decide not to merge your changes. But that > doesn't change the fact that you have changed ucw more to your > liking. Your changes remain intact every time you run darcs > (unless of course the SELECT code is changed in the future, but > then you can simply refuse that patch). truer words have never been spoken. > I've been working on several patches myself. I'll probably be > submitting them in the next day or two. I'm trying to get ucw > to play nice with clisp and araneida. Marco's code walker has > my head hurting, but the worst is over. if you have clisp+araneida patches i'd be really interested in 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 vanek at acd.net Fri Jun 9 16:49:40 2006 From: vanek at acd.net (Lou Vanek) Date: Fri, 09 Jun 2006 16:49:40 +0000 Subject: [Bese-devel] Re: dom-id's in xxx-select-field elements In-Reply-To: References: <44889CD1.8070601@acd.net> Message-ID: <4489A6A4.8030503@acd.net> Marco Baringer wrote: > Lou Vanek writes: > >>The external interface seems to be in flux (the examples >>don't even compile any more due to interface changes). So >>changing things around to be more consistent seems more than >>workable. > > > can you paste the error? they seem to work on my copy of ucw_dev :( This is part of examples.lisp: :dispatchers (list (make-instance 'action-dispatcher) (simple-dispatcher "mul.ucw" (mul-table-example)) (make-instance 'ucw::minimal-dispatcher :url-string "mul-direct.ucw" :handler (lambda (application context) (declare (ignore application context)) (direct-mul-table-example)))))) I believe standard-application's 'dispatchers accessor was taken out. And I don't think the new accessor is exported even though it's an external api (or should be). I'm still having trouble with examples.lisp; looking into the possible causes. Let you know. There's a number of changes to the 'hello' example which I've documented and will send along with the patches. My system must be unusual, or I've inadvertantly bumped something, because there was no way the hello example was going to run the first time with Clisp and Araneida. I see you've made use of 'make-load-form'. This use doesn't seem to work with Clisp when the code walker destructively makes changes (for example, after LOOPs are expanded and GO is replaced by a place. The place is being saved to the .fas as a #:make-load-form-XXXX symbol. I don't understand the code or CL well enough to fix this, but I can get around the problem by never loading the .fas but instead load hello.lisp without compilation. Dorky, but it works. >>I would go ahead and make the changes, create a few patches, >>and submit 'em. What's the worst that can happen? You get >>a code base that's more to your liking (it's partially YOUR >>code), and Marco may decide not to merge your changes. But that >>doesn't change the fact that you have changed ucw more to your >>liking. Your changes remain intact every time you run darcs >>(unless of course the SELECT code is changed in the future, but >>then you can simply refuse that patch). > > > truer words have never been spoken. > > >>I've been working on several patches myself. I'll probably be >>submitting them in the next day or two. I'm trying to get ucw >>to play nice with clisp and araneida. Marco's code walker has >>my head hurting, but the worst is over. > > > if you have clisp+araneida patches i'd be really interested in them. Every time I fix something something new deserves attention. "Whack a Mole" has crossed my mind. I'll send patches as soon as I can get a minimally usable system running. I'm relatively new to CL so this is taking longer than anticipated. Patience is a virtual (and I'm talking to myself when I say this). Lou Vanek -- Who puts the 'b' back in subtle. From eslick at csail.mit.edu Fri Jun 9 18:39:04 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Fri, 09 Jun 2006 14:39:04 -0400 Subject: [Bese-devel] Hosting UCW apps Message-ID: <4489C048.6010504@csail.mit.edu> I'm working on a common-lisp library with the 'common lisp gardeners' and wanted to use UCW for the project's website so I can export some search capabilities and a simple process for managing patches, feature requests and such. Is there a good web hosting service that would host a UCW app for free that someone on this list knows about? Anyone know if common-lisp.net has considered hosting more complex apps? I just haven't kept up with these discussions. Thank you, Ian From attila.lendvai at gmail.com Fri Jun 9 18:41:36 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Fri, 9 Jun 2006 20:41:36 +0200 Subject: [Bese-devel] Re: dom-id's in xxx-select-field elements In-Reply-To: <4489A6A4.8030503@acd.net> References: <44889CD1.8070601@acd.net> <4489A6A4.8030503@acd.net> Message-ID: > > can you paste the error? they seem to work on my copy of ucw_dev :( > > This is part of examples.lisp: > > :dispatchers (list (make-instance 'action-dispatcher) > (simple-dispatcher "mul.ucw" > (mul-table-example)) > (make-instance 'ucw::minimal-dispatcher > :url-string "mul-direct.ucw" > :handler (lambda (application context) > (declare (ignore application context)) > (direct-mul-table-example)))))) > > I believe standard-application's 'dispatchers accessor was taken out. > And I don't think the new accessor is exported even though it's an > external api (or should be). a patch was backported from the ajax branch (but not the same as it is in that branch) and the examples were not fixed. i've fixed them in the ajax branch but this aspect of the two branches are not compatible now. someone could copy the make-standard-dispatchers defun to ucw_dev and then pull the examples fix from the ajax branch... i don't have a dev branch here at hand. - attila (alias 101 on irc &no 'its not lisp code :) From vanek at acd.net Fri Jun 9 20:24:32 2006 From: vanek at acd.net (Lou Vanek) Date: Fri, 09 Jun 2006 20:24:32 +0000 Subject: [Bese-devel] Re: dom-id's in xxx-select-field elements In-Reply-To: References: <44889CD1.8070601@acd.net> <4489A6A4.8030503@acd.net> Message-ID: <4489D900.3090906@acd.net> Attila Lendvai wrote: >> > can you paste the error? they seem to work on my copy of ucw_dev :( >> >> This is part of examples.lisp: >> >> :dispatchers (list (make-instance 'action-dispatcher) >> (simple-dispatcher "mul.ucw" >> (mul-table-example)) >> (make-instance 'ucw::minimal-dispatcher >> :url-string >> "mul-direct.ucw" >> :handler (lambda >> (application context) >> (declare >> (ignore application context)) >> >> (direct-mul-table-example)))))) >> >> I believe standard-application's 'dispatchers accessor was taken out. >> And I don't think the new accessor is exported even though it's an >> external api (or should be). > > > a patch was backported from the ajax branch (but not the same as it is > in that branch) and the examples were not fixed. i've fixed them in > the ajax branch but this aspect of the two branches are not compatible > now. Thanks. I didn't even find the ajax branch until a short while ago. Unfortunately, I've already made my fixes. I'll try to remember to look at both branches in the future. Not sure I want to work on two branches at the same time. Not even sure exactly what the differences btn the two are, besides that one branch favors ajax over the other. Shame there are two branches. I would've just added more config parameters and never have split it. This is the CL problem in microcosm--fractured at best / spread too thin and left for dead at worst. CL may be a victim of its own malleability: it's so easy to change things that everybody and his dog wants to make their own version of the program. Heck, that even applies to me and I'm just a Lisp-young'n. Lou someone could copy the make-standard-dispatchers defun to ucw_dev > and then pull the examples fix from the ajax branch... i don't have a > dev branch here at hand. > > - attila > > (alias 101 on irc &no 'its not lisp code :) From attila.lendvai at gmail.com Fri Jun 9 20:48:27 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Fri, 9 Jun 2006 22:48:27 +0200 Subject: [Bese-devel] Re: dom-id's in xxx-select-field elements In-Reply-To: <4489D900.3090906@acd.net> References: <44889CD1.8070601@acd.net> <4489A6A4.8030503@acd.net> <4489D900.3090906@acd.net> Message-ID: > Shame there are two branches. I would've just added more > config parameters and never have split it. This is the CL > problem in microcosm--fractured at best / spread too thin > and left for dead at worst. CL may be a victim of its own > malleability: it's so easy to change things that everybody and his > dog wants to make their own version of the program. Heck, that > even applies to me and I'm just a Lisp-young'n. i know what you mean, but this is not the case here. the ajax branch is basically the dev branch + (potentially young and fragile) code needed to make ajax work. this is only a temporary situation, and darcs makes it quite easy to manage and merge... i keep the ajax branch in sync with the dev branch. - attila (alias 101 on irc &no 'its not lisp code :) From vanek at acd.net Sat Jun 10 09:48:33 2006 From: vanek at acd.net (Lou Vanek) Date: Sat, 10 Jun 2006 09:48:33 +0000 Subject: [Bese-devel] Re: dom-id's in xxx-select-field elements In-Reply-To: References: <44889377.8070906@acd.net> Message-ID: <448A9571.4070108@acd.net> Marijn Haverbeke wrote: > On 6/8/06, *Lou Vanek* > wrote: > > I would go ahead and make the changes, create a few patches, > and submit 'em. What's the worst that can happen? You get > a code base that's more to your liking (it's partially YOUR > code), and Marco may decide not to merge your changes. But that > doesn't change the fact that you have changed ucw more to your > liking. Your changes remain intact every time you run darcs > (unless of course the SELECT code is changed in the future, but > then you can simply refuse that patch). > > > Great, I'll do that. I haven't worked much with darcs before - What is > the best way to submit a patch? > > Marijn CREATE A PRISTINE UCW DIRECTORY Create a new ucw directory so that you have something to compare to. 'cd' to where you want a new ucw directory to be created, and get one of the darcs repositories: darcs get http://common-lisp.net/project/ucw/repos/ucw_dev or, for the more adventurous soul who wants ajax: darcs get http://common-lisp.net/project/ucw/repos/ucw_ajax Later, these directories can be updated by 'cd'ing into their top level and doing a 'pull' instead of a 'get': darcs pull http://common-lisp.net/project/ucw/repos/ucw_dev I put this command in a simple shell script and have it run everyday so my code is up to date and I don't run into problems that have already been fixed. CREATE THE PATCH This is one way: LC_ALL=C diff -Naurbdwt -x '*.fas' -x '*.lib' -x _darcs -x docs -x bin -x 'READ*' -I '^\s*;' ucw_dev ucw_dev.my This says, LC_ALL=C standardize my environment before creating the patch because the patch must also be able to work on other computers -Naurbdwt bunch of options that can be found in the diff man page -x '*.fas' ignore all lisp compiled files (I use Clisp. Your compiled files may be different) -x _darcs ignore the darcs repository -x docs ignore the docs directory -I '^\s*;' ignore comment lines common to both files being compared and recursively compare the clean directory 'ucw_dev' with my modified directory 'ucw_dev.my'. I run commands in bash so this command would also work in sh and probably csh. Don't know about DOS shell, though. Probably not so much. I would put this command in a shell script because I might run it later. Call it something like diff_ucw_dev.bash, then 'cd' one level above 'ucw_dev' and run it to create the patch: diff_ucw_dev.bash > my_super_duper_patch This text file can be posted to the NG if it's not too large, either directly into email or as attachments. It would probably have to be directly emailed to Marco if it was larger than, say, 25K, because many NGs/MLs automatically filter out large postings. REVIEWING AND MODIFYING THE PATCH (OPTIONAL) The patch is just a text file so you can easily see the differences it found. You probably don't want to send every nit in the patch, so you can do one of two things. Either change your code to comply with the "clean" ucw_dev (and recreate the patch), or do minor surgery on the patch itself. After reviewing the changes in the patch, if there is one change you don't want sent you can open the patch file up and manually delete the offending 'chunk' and the patch will still work as long as you excise the entire 'chunk' en toto: . the file names preceding the chunk . the line numbers of the chunk you don't want to send . the chunk's actual text that you don't want included in the patch APPLYING THE PATCH After receiving a patch, somebody (such as Marco) can apply it by 'cd'ing to the same place in the directory structure where the patch was created, and run, patch -Np0 < my_super_duper_patch and, if he decides he doesn't like the results of the patch, he can reverse it, patch -NRp0 < my_super_duper_patch (Those are zeros, not ohs, in the options.) It's up to you to tell the person who is applying the patch which directory to start in, but anybody should be able to figure it out easily just be opening the patch up in a text editor and looking at the file names (which is why I don't bother). I would save my_super_duper_patch because it's possible that a darcs patch will stomp on something you did. Darcs will usually tell you when there is a merge conflict, and you will have to manually go in and decide which blob of text to keep. But if something screwed up you may want to apply your patch to your own code later. Lou -- My windows box has been up for over 6 days without requiring a reboot. I think that's a personal best. From attila.lendvai at gmail.com Sat Jun 10 10:40:43 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Sat, 10 Jun 2006 12:40:43 +0200 Subject: [Bese-devel] Re: dom-id's in xxx-select-field elements In-Reply-To: <448A9571.4070108@acd.net> References: <44889377.8070906@acd.net> <448A9571.4070108@acd.net> Message-ID: > CREATE A PRISTINE UCW DIRECTORY [...] what's the problem with darcs whatsnew/record/send? - attila (alias 101 on irc &no 'its not lisp code :) From vanek at acd.net Sat Jun 10 10:48:03 2006 From: vanek at acd.net (Lou Vanek) Date: Sat, 10 Jun 2006 10:48:03 +0000 Subject: [Bese-devel] Re: dom-id's in xxx-select-field elements In-Reply-To: References: <44889377.8070906@acd.net> <448A9571.4070108@acd.net> Message-ID: I'm pretty much a darcs virgin and wasn't aware of those commands. I learned something new. Thanks! Lou -- Until real software engineering is developed, the next best practice is to develop with a dynamic system that has extreme late binding in all aspects. The first system to really do this in an important way is Lisp. -- Alan Kay Attila Lendvai wrote: >> CREATE A PRISTINE UCW DIRECTORY > > > [...] > > what's the problem with darcs whatsnew/record/send? > > - attila > > (alias 101 on irc &no 'its not lisp code :) From vanek at acd.net Sat Jun 10 10:55:32 2006 From: vanek at acd.net (Lou Vanek) Date: Sat, 10 Jun 2006 10:55:32 +0000 Subject: [Bese-devel] Re: dom-id's in xxx-select-field elements In-Reply-To: References: <44889377.8070906@acd.net> <448A9571.4070108@acd.net> Message-ID: <448AA524.4050400@acd.net> Ties Stuij wrote: >> CREATE THE PATCH >> >> This is one way: >> >> LC_ALL=C diff -Naurbdwt -x '*.fas' -x '*.lib' -x _darcs -x docs -x >> bin -x 'READ*' -I '^\s*;' ucw_dev ucw_dev.my >> ... etc > > > what's wrong with a simple "> darcs record" in the root of the > repository directory? Why go out of your way to circumvent the darcs > diffing facilities? > > Greets, > Ties Thanks for bringing this to my attention. I'm new to darcs so my ignorance is now on display to the world (or at least the internet and all future googlers and googlerets). Lou -- At a world brewing convention in the States, the CEOs of various Brewing organizations retired to the bar at the end of each day's conference. Bruce, CEO of Fosters, shouted to the Barman: "In 'Strylya, we make the best bladdy beer in the world, so pour me a Bladdy Fosters, mate." Bob, CEO of Budweiser, calls out next: "In the States, we brew the finest beers in the world, and I make the King of them all; gimme a Bud." Hans steps up next: "In Germany ve invented das beer, verdamt. Give me ein Becks, ya ist Der real King of beers, danke." Paddy, CEO of Guinness, steps forward "Barman, would ya give me a doyet coke wid ice and lemon. Tanks." The others stare at him in stunned silence, amazement written all over their faces. Eventually Bruce asks, "Are you not going to have a Guinness, Pat?" Paddy replies: "Well, if you fookin' pansies aren't drinkin', then neither am I". From cjstuij at gmail.com Sat Jun 10 11:19:53 2006 From: cjstuij at gmail.com (Ties Stuij) Date: Sat, 10 Jun 2006 13:19:53 +0200 Subject: [Bese-devel] Re: dom-id's in xxx-select-field elements In-Reply-To: <448AA524.4050400@acd.net> References: <44889377.8070906@acd.net> <448A9571.4070108@acd.net> <448AA524.4050400@acd.net> Message-ID: > Thanks for bringing this to my attention. I'm new to darcs so my > ignorance is now on display to the world (or at least the internet > and all future googlers and googlerets). One can never instanta-incidental-doublepost-bomb hapless victims enough to drive home the point ;o) greets, Ties From cjstuij at gmail.com Sat Jun 10 10:29:22 2006 From: cjstuij at gmail.com (Ties Stuij) Date: Sat, 10 Jun 2006 12:29:22 +0200 Subject: [Bese-devel] Re: dom-id's in xxx-select-field elements In-Reply-To: References: <44889377.8070906@acd.net> <448A9571.4070108@acd.net> Message-ID: > CREATE THE PATCH > > This is one way: > > LC_ALL=C diff -Naurbdwt -x '*.fas' -x '*.lib' -x _darcs -x docs -x bin -x 'READ*' -I '^\s*;' ucw_dev ucw_dev.my > ... etc what's wrong with a simple "> darcs record" in the root of the repository directory? Why go out of your way to circumvent the darcs diffing facilities? Greets, Ties From vanek at acd.net Sat Jun 10 15:03:43 2006 From: vanek at acd.net (Lou Vanek) Date: Sat, 10 Jun 2006 15:03:43 +0000 Subject: [Bese-devel] component tree Message-ID: <448ADF4F.8000708@acd.net> [bump] ... Next question. I'm working on the make-new-callback thing now, because it doesn't behave very well in some situations (multiple forms, which have names with the same fields, on a page, and when you want to always run some code when a form is submitted, for use with checkboxes and multi-select inputs)... but I am running into some serious terminology confusion. Could somebody give me a hint on the meaning of the _s and _f hidden inputs that are added to References: <448ADF4F.8000708@acd.net> Message-ID: > Could somebody give me a hint on the meaning of the _s and _f hidden inputs that are added to References: <448ADF4F.8000708@acd.net> Message-ID: > > > Could somebody give me a hint on the meaning of the _s and _f hidden > inputs that are added to the role of the make-new-action call in > Well as i understand it the _s stands for the user session to look > for, the _f is for the relevant frame and the make-action associates > the action you want to execute with a string in the relevant frame. If > you use slime, alt-. your way to it. Thanks. You'll have to forgive me if alt-. doesn't always enlighten me - there's quite a bit of documentation in the code, but it's not much help for understanding the high-level concepts used. So why is the session put into a hidden input when it is also stored in a cookie? Do UCW applications without cookies work at all? A quick experiment seems to suggest they do at least simple things right, what is the difference between an application with cookies and one without? Also, I noticed that when no :action is defined for a form, the accessors & writers of its fields have no effect. Is this by design? If so, why? Bye, Marijn -------------- next part -------------- An HTML attachment was scrubbed... URL: From rtvd at mail.ru Sat Jun 10 19:19:56 2006 From: rtvd at mail.ru (Rtveliashvili Denys) Date: Sat, 10 Jun 2006 23:19:56 +0400 Subject: [Bese-devel] streaming binary data Message-ID: <522A89FC-7FF1-48C4-AF4A-F12FDA9AE84E@mail.ru> Hi, I am looking for a possibility to stream a binary data to user instead of HTML. Imagine a situation when a registration form has to be displayed, and the form should show an image with a rendered code which has to be entered by user manually to prove that the registration is made by a human being. Or, for example, imagine a situation when it is necessary to display a pie chart which is dynamically generated on the server side. In both situations it is necessary so send a binary content to client side and specify the content type. Does anybody know how to do it in UnCommon Web? Thank you, Denys R. From vanek at acd.net Sat Jun 10 23:29:59 2006 From: vanek at acd.net (Lou Vanek) Date: Sat, 10 Jun 2006 23:29:59 +0000 Subject: [Bese-devel] streaming binary data In-Reply-To: <522A89FC-7FF1-48C4-AF4A-F12FDA9AE84E@mail.ru> References: <522A89FC-7FF1-48C4-AF4A-F12FDA9AE84E@mail.ru> Message-ID: <448B55F7.408@acd.net> This one time, at band camp, Rtveliashvili Denys wrote: > Hi, > > I am looking for a possibility to stream a binary data to user instead > of HTML. > > Imagine a situation when a registration form has to be displayed, and > the form should show an image with a rendered code which has to be > entered by user manually to prove that the registration is made by a > human being. Or, for example, imagine a situation when it is necessary > to display a pie chart which is dynamically generated on the server > side. In both situations it is necessary so send a binary content to > client side and specify the content type. > > Does anybody know how to do it in UnCommon Web? > > Thank you, > Denys R. > _______________________________________________ > bese-devel mailing list > bese-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel > This patch is NOT ready for prime time. Do not apply. It was written only for my system (Clisp and Araneida), but it should give you a good idea of how to change the character stream to binary. (Just do a search on 'binary' in the patch.) The reason why I wrote this is because Clisp MUST send a binary data stream when the data is UTF8. I have no idea whether this works with any other lisp, but it should give you good a idea or two and perhaps a starting point. HTH Lou Vanek -- Did you hear about the agnostic insomniac dyslexic? He lay awake at night wondering if there's a Dog. diff -Narbdwt -u4 -x '*.fas' -x '*.lib' -x _darcs -x docs -x bin -x 'READ*' -I '^\s*;' TMP/ucw_dev.clean/src/backend/araneida.lisp ucw_dev/src/backend/araneida.lisp --- TMP/ucw_dev.clean/src/backend/araneida.lisp 2006-06-02 07:06:58.765625000 -0400 +++ ucw_dev/src/backend/araneida.lisp 2006-06-09 18:30:35.260750000 -0400 @@ -61,9 +87,12 @@ (ucw.backend.info "Starting up ARANEIDA backend ~S on ~A" backend (araneida:urlstring (default-url backend))) (araneida:start-listening (listener backend)) - #+clisp (araneida:host-serve-events)) + ;; This next line is important (iff running clisp), but it should run a bit later + ;; after we start swank. (This line causes the process to block.) + #+nil (araneida:host-serve-events) + ) (defmethod shutdown-backend ((backend araneida-backend) &rest init-args) (declare (ignore init-args)) (ucw.backend.info "Stopping ARANEIDA backend ~S on ~A." @@ -138,11 +167,15 @@ (defmethod shutdown ((r araneida-request)) nil) +(defmethod close-request ((request araneida-request)) + (shutdown request)) + (defclass araneida-response (response) ((request :accessor request :initarg :request) (headers :accessor headers :initform '()) + (status :accessor status :initform "200 OK") (html-stream :accessor html-stream :initform (make-string-output-stream)))) (defmethod clear-response ((response araneida-response)) (setf (headers response) '() @@ -156,12 +189,31 @@ (defmethod add-header ((response araneida-response) header-name value) (push (cons header-name value) (headers response))) -(defmethod shutdown ((r araneida-response)) +(defmethod send-headers ((response araneida-response)) + (araneida-send-headers response nil)) + +(defun content-type-and-charset (response) + (let (charset/encoding) + (dolist* ((name . value) (headers response)) + (if (starts-with name "Content-Type") + (handler-bind ((condition (lambda (condition) + (format t "~%!! parse header error.~%~%") + (describe condition) + (format t "condition type: ~a~%" (type-of condition)) + (invoke-debugger condition)))) + (multiple-value-bind (ctype attributes) + (rfc2388:parse-header-value value) + (when-bind charset/encoding (assoc "charset" attributes :test #'string=) + (setq charset/encoding (cdr charset/encoding))) + (return-from content-type-and-charset (values ctype charset/encoding)))))))) + +(defun araneida-send-headers (response body-length) (let (content-type content-type/charset content-length expires cache-control location refresh - pragma set-cookie conditional www-authenticate last-modified extra-headers) - (dolist* ((&whole header-cons name . value) (headers r)) + pragma set-cookie conditional www-authenticate last-modified extra-headers + (status (assoc "Status" (headers response) :test #'string-equal))) + (dolist* ((&whole header-cons name . value) (headers response)) (switch (name :test #'string-equal) ("Content-Type" (multiple-value-bind (type attributes) (rfc2388:parse-header-value value) @@ -178,21 +230,23 @@ ("Conditional" (setf conditional value)) ("WWW-Authenticate" (setf www-authenticate value)) ("Last-Modified" (setf last-modified value)) (t (push header-cons extra-headers)))) - (let ((content (if (starts-with content-type "text") - (string-to-octets (get-output-stream-string (html-stream r)) - (switch (content-type/charset :test #'string=) - ("UTF-8" :utf-8) - (("latin-1" "iso-8859-1") :iso-8859-1) - (t :us-ascii))) - ;; um, it's not text. this is really wrong - (string-to-octets (get-output-stream-string (html-stream r)) - :iso-8859-1)))) - (araneida:request-send-headers (request r) - :response-code (cdr (assoc "Status" (headers r) :test #'string-equal)) + + (assert (listp status) (status) "Response header 'status' cannot be empty.") + (or content-length + body-length + (warn "! content length unknown.~%")) + + (handler-bind ((condition (lambda (condition) + (format t "~%!! request-send-headers error.~%~%") + (describe condition) + (format t "condition type: ~a~%" (type-of condition)) + (invoke-debugger condition)))) + (araneida:request-send-headers (request response) + :response-code (cdr status) :content-type (or content-type "text/html") - :content-length (or content-length (length content)) + :content-length (or content-length body-length 0) :expires expires :cache-control cache-control :location location :refresh refresh @@ -200,16 +254,59 @@ :set-cookie set-cookie :conditional conditional :www-authenticate www-authenticate :last-modified last-modified - :extra-http-headers extra-headers) - (write-sequence content (araneida:request-stream (request r)))))) + :extra-http-headers extra-headers)))) + + +(defmethod send-response ((response araneida-response)) + (shutdown response)) + +(defmethod shutdown ((resp araneida-response)) + (multiple-value-bind (content-type content-type/charset) + (content-type-and-charset resp) + (let* ((s (get-output-stream-string (html-stream resp))) + (content (if (starts-with content-type "text") + (string-to-octets s + (switch (content-type/charset :test #'string=) + ("UTF-8" :utf-8) + (("latin-1" "iso-8859-1") :iso-8859-1) + (t :us-ascii))) + ;; um, it's not text. this is really wrong + (string-to-octets (get-output-stream-string (html-stream resp)) + :iso-8859-1)))) + (araneida-send-headers resp (length content)) + (handler-bind ((condition (lambda (condition) + (format t "~%!! write-sequence error.~%~%") + (describe condition) + (format t "condition type: ~a~%" (type-of condition)) + (catch 'abort-action + (format t "~a~%~%" (collect-backtrace condition))) + (invoke-debugger condition)))) + (let ((stream (araneida:request-stream (request resp)))) + (write-binary-sequence content stream)))))) (defmethod make-backend ((backend araneida:http-listener) &key host port) (make-instance 'ucw:araneida-backend :listener backend :default-url (araneida:make-url :scheme "http" :host host :port port))) +(defun make-binary-stream (araneida-request-obj) + (let ((stream (araneida:request-stream araneida-request-obj))) + #+clisp (unless (equal (stream-element-type stream) '(unsigned-byte 8)) + (setf (stream-element-type stream) '(unsigned-byte 8))) + stream + )) + +(defmethod network-stream ((response araneida-response)) + (make-binary-stream (request response))) + +(defmethod network-stream ((request araneida-request)) + (make-binary-stream (request request))) + +(defmethod network-stream ((request araneida:request)) + (make-binary-stream request)) + ;; Copyright (c) 2003-2006 Edward Marco Baringer ;; All rights reserved. ;; ;; Redistribution and use in source and binary forms, with or without diff -Narbdwt -u4 -x '*.fas' -x '*.lib' -x _darcs -x docs -x bin -x 'READ*' -I '^\s*;' TMP/ucw_dev.clean/src/backend/common.lisp ucw_dev/src/backend/common.lisp --- TMP/ucw_dev.clean/src/backend/common.lisp 2006-06-02 07:06:59.390625000 -0400 +++ ucw_dev/src/backend/common.lisp 2006-06-09 17:58:35.823250000 -0400 @@ -147,13 +157,14 @@ ("css" "text/css") (t "text/plain"))) (get-header response "Content-Length") (princ-to-string (file-length file))) (send-headers response) + (ucw.rerl.server.dribble "defserve: serve-file: sent headers.") (loop with buffer = (make-array 8192 :element-type 'unsigned-byte) for end-pos = (read-sequence buffer file) until (zerop end-pos) do - (write-sequence buffer (network-stream request) :end end-pos)))) + (write-binary-sequence buffer (network-stream request) :end end-pos)))) (defserve (serve-sequence (sequence &key (request (context.request *context*)) (response (context.response *context*)) @@ -169,9 +180,30 @@ sequence))) (setf (get-header response "Content-Type") content-type (get-header response "Content-Length") (princ-to-string (length bytes))) (send-headers response) - (write-sequence bytes (network-stream request))))) + (write-binary-sequence bytes (network-stream request))))) + +(defun write-binary-sequence (sequence stream &rest rest &key (start 0) (end nil)) + (declare (ignore start end)) + (handler-bind ((condition (lambda (condition) + (if nil + (progn + (format t "~%!!! write-binary-sequence error.~%~%") + (describe condition) + (format t "condition type: ~a~%" (type-of condition)) + (catch 'abort-action + (format t "~a~%~%" (collect-backtrace condition))) + (invoke-debugger condition)) + (warn "- null sequence sent to output stream."))))) + (if (null sequence) + (signal 'null-content) + (progn + ; cannot send binary data to character socket (must be made binary socket) + #+clisp (unless (equal (stream-element-type stream) '(unsigned-byte 8)) + (setf (stream-element-type stream) '(unsigned-byte 8))) + (apply #'write-sequence sequence stream rest))))) + ;;;; Parsing HTTP request bodies. ;;;; The httpd, mod_lisp and araneida backends use this code. From attila.lendvai at gmail.com Sun Jun 11 11:55:28 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Sun, 11 Jun 2006 13:55:28 +0200 Subject: [Bese-devel] component tree In-Reply-To: <448ADF4F.8000708@acd.net> References: <448ADF4F.8000708@acd.net> Message-ID: > Next question. I'm working on the make-new-callback thing now, because it doesn't behave very well in some situations (multiple forms, which have names with the same fields, on a page, and > when you want to always run some code when a form is submitted, for use with checkboxes and multi-select inputs)... but I am running into some serious terminology confusion. the ajax branch has submit-callback's that are lambdas executed whenever a form is submitted. for common tasks like reading checkbox values, but i just wanted to smarten up the code in form.lisp to make it unnecessary. but still in other cases it comes handy... - attila (alias 101 on irc &no 'its not lisp code :) From attila.lendvai at gmail.com Mon Jun 12 10:57:25 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Mon, 12 Jun 2006 12:57:25 +0200 Subject: [Bese-devel] streaming binary data In-Reply-To: <448B55F7.408@acd.net> References: <522A89FC-7FF1-48C4-AF4A-F12FDA9AE84E@mail.ru> <448B55F7.408@acd.net> Message-ID: there's serve-file and serve-sequence in stock ucw (hm, maybe only in the ajax branch). if you need finer control take a look at the impl of serve-sequence. - attila (alias 101 on irc &no 'its not lisp code :) From evrim at core.gen.tr Mon Jun 12 15:21:37 2006 From: evrim at core.gen.tr (Evrim ULU) Date: Mon, 12 Jun 2006 18:21:37 +0300 Subject: [Bese-devel] yaclml <:html tag Message-ID: <448D8681.4090407@core.gen.tr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi, i think there is conflict with <:html tag, its defined twice in yaclml/src/tags/html4.lisp as below: (deftag <:html (&attribute dir lang (prologue t) &body body) (when prologue (emit-princ "")) (emit-open-tag "html" (list (cons "dir" dir) (cons "lang" lang))) (emit-body body) (emit-close-tag "html")) (def-html-tag <:html :i18n) evrim. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEjYaBwzkKLGtRuHsRAoxzAKC5YhXqKRoiYavFZkSG9l37q5/AHQCghxR6 ooYmKN2speNrcthskxPRfPg= =r7gp -----END PGP SIGNATURE----- From hbabcockos1 at mac.com Tue Jun 13 00:39:21 2006 From: hbabcockos1 at mac.com (hbabcockos1 at mac.com) Date: Mon, 12 Jun 2006 20:39:21 -0400 Subject: [Bese-devel] streaming binary data In-Reply-To: <522A89FC-7FF1-48C4-AF4A-F12FDA9AE84E@mail.ru> References: <522A89FC-7FF1-48C4-AF4A-F12FDA9AE84E@mail.ru> Message-ID: <5FEAF3D7-B5A3-4567-B2FD-DBFF40C442BB@mac.com> On Jun 10, 2006, at 3:19 PM, Rtveliashvili Denys wrote: > Hi, > > I am looking for a possibility to stream a binary data to user > instead of HTML. > > Imagine a situation when a registration form has to be displayed, > and the form should show an image with a rendered code which has to > be entered by user manually to prove that the registration is made > by a human being. Or, for example, imagine a situation when it is > necessary to display a pie chart which is dynamically generated on > the server side. In both situations it is necessary so send a > binary content to client side and specify the content type. > > Does anybody know how to do it in UnCommon Web? You might also look at the attachment of this message in the Bese archive, as I recall it even shows how to dynamically generate a pie chart :). http://common-lisp.net/pipermail/bese-devel/2006-April/001951.html -Hazen From dbeauchesne at gmail.com Mon Jun 12 08:41:20 2006 From: dbeauchesne at gmail.com (Dan Beauchesne) Date: 12 Jun 2006 17:41:20 +0900 Subject: [Bese-devel] compile-op error on backtracking.lisp Message-ID: <87ver6bwb3.fsf@localhost.localdomain> Hi all, Please bear with me, I'm new to lisp. My setup: SBCL 0.9.13.30 (on debian etch) ucw_dev latest (ie. today) I've downloaded all the UCW dependencies and made sure they are loadable by ASDF. When I try to load the start.lisp file, it seems to be going fine for some time and then the slime debugger pops up with a compile-op error on backtracking.lisp. So when I do a (compile-file "/path/to/rerl/backtracking.lisp") I get: ; compiling (IN-PACKAGE :IT.BESE.UCW) ; compiling (DEFMACRO MAKE-PLACE ...) ; compiling (DEFMETHOD PLACE ...) ; file: /home/dan/src/ucw_dev/src/rerl/backtracking.lisp ; in: DEFMETHOD PLACE (PLACE) ; (DEFMETHOD IT.BESE.UCW::PLACE ; ((IT.BESE.UCW::PLACE IT.BESE.UCW::PLACE)) ; "Returns the current value of PLACE." ; (ETYPECASE (IT.BESE.UCW::PLACE.GETTER IT.BESE.UCW::PLACE) ; (FUNCTION ; (FUNCALL (IT.BESE.UCW::PLACE.GETTER IT.BESE.UCW::PLACE))) ; (IT.BESE.ARNESI::CLOSURE/CC ; (IT.BESE.ARNESI:WITH-CALL/CC (FUNCALL #))))) ; ; caught WARNING: ; Reference to unknown variable PLACE. ; compiling (DEFMETHOD (SETF PLACE) ...) ; file: /home/dan/src/ucw_dev/src/rerl/backtracking.lisp ; in: DEFMETHOD (SETF PLACE) (T PLACE) ; (DEFMETHOD (SETF IT.BESE.UCW::PLACE) ; (IT.BESE.UCW:VALUE (IT.BESE.UCW::PLACE IT.BESE.UCW::PLACE)) ; "Set the value of PLACE to VALUE." ; (ETYPECASE (IT.BESE.UCW::PLACE.SETTER IT.BESE.UCW::PLACE) ; (FUNCTION ; (FUNCALL (IT.BESE.UCW::PLACE.SETTER IT.BESE.UCW::PLACE) ; IT.BESE.UCW:VALUE)) ; (IT.BESE.ARNESI::CLOSURE/CC ; (IT.BESE.ARNESI:WITH-CALL/CC (FUNCALL # IT.BESE.UCW:VALUE))))) ; ; caught WARNING: ; Reference to unknown variable PLACE. ; ; caught WARNING: ; Reference to unknown variable VALUE. ; compiling (DEFMETHOD CLONE-PLACE-VALUE ...) ; compiling (DEFCONSTANT +UNBOUND-VALUE+ ...) ; compiling (DEFMETHOD SAVE-BACKTRACKED ...) ; compiling (DEFMETHOD REINSTATE-BACKTRACKED ...) ; compiling (DEFUN CLONE-BACKTRACKS ...) ; compiling (DEFMETHOD BACKTRACK ...) ; compiling (DEFMETHOD BACKTRACK-SLOT ...); ; compilation unit finished ; caught 3 WARNING conditions ; /home/dan/src/ucw_dev/src/rerl/backtracking.fasl written ; compilation finished in 0:00:00 #P"/home/dan/src/ucw_dev/src/rerl/backtracking.fasl" T I have a feeling this is just a stupid error on my part, as ucw-boxset works just fine. But after double-checking my dependencies and re-reading the README, I'm not sure what it is. Thanks guys -- Dan Beauchesne dbeauchesne -at- gmail -dot- com From dbeauchesne at gmail.com Mon Jun 12 08:41:20 2006 From: dbeauchesne at gmail.com (Dan Beauchesne) Date: 12 Jun 2006 17:41:20 +0900 Subject: [Bese-devel] compile-op error on backtracking.lisp Message-ID: <87ver6bwb3.fsf@localhost.localdomain> Hi all, Please bear with me, I'm new to lisp. My setup: SBCL 0.9.13.30 (on debian etch) ucw_dev latest (ie. today) I've downloaded all the UCW dependencies and made sure they are loadable by ASDF. When I try to load the start.lisp file, it seems to be going fine for some time and then the slime debugger pops up with a compile-op error on backtracking.lisp. So when I do a (compile-file "/path/to/rerl/backtracking.lisp"), I get: ; compiling (IN-PACKAGE :IT.BESE.UCW) ; compiling (DEFMACRO MAKE-PLACE ...) ; compiling (DEFMETHOD PLACE ...) ; file: /home/dan/src/ucw_dev/src/rerl/backtracking.lisp ; in: DEFMETHOD PLACE (PLACE) ; (DEFMETHOD IT.BESE.UCW::PLACE ; ((IT.BESE.UCW::PLACE IT.BESE.UCW::PLACE)) ; "Returns the current value of PLACE." ; (ETYPECASE (IT.BESE.UCW::PLACE.GETTER IT.BESE.UCW::PLACE) ; (FUNCTION ; (FUNCALL (IT.BESE.UCW::PLACE.GETTER IT.BESE.UCW::PLACE))) ; (IT.BESE.ARNESI::CLOSURE/CC ; (IT.BESE.ARNESI:WITH-CALL/CC (FUNCALL #))))) ; ; caught WARNING: ; Reference to unknown variable PLACE. ; compiling (DEFMETHOD (SETF PLACE) ...) ; file: /home/dan/src/ucw_dev/src/rerl/backtracking.lisp ; in: DEFMETHOD (SETF PLACE) (T PLACE) ; (DEFMETHOD (SETF IT.BESE.UCW::PLACE) ; (IT.BESE.UCW:VALUE (IT.BESE.UCW::PLACE IT.BESE.UCW::PLACE)) ; "Set the value of PLACE to VALUE." ; (ETYPECASE (IT.BESE.UCW::PLACE.SETTER IT.BESE.UCW::PLACE) ; (FUNCTION ; (FUNCALL (IT.BESE.UCW::PLACE.SETTER IT.BESE.UCW::PLACE) ; IT.BESE.UCW:VALUE)) ; (IT.BESE.ARNESI::CLOSURE/CC ; (IT.BESE.ARNESI:WITH-CALL/CC (FUNCALL # IT.BESE.UCW:VALUE))))) ; ; caught WARNING: ; Reference to unknown variable PLACE. ; ; caught WARNING: ; Reference to unknown variable VALUE. ; compiling (DEFMETHOD CLONE-PLACE-VALUE ...) ; compiling (DEFCONSTANT +UNBOUND-VALUE+ ...) ; compiling (DEFMETHOD SAVE-BACKTRACKED ...) ; compiling (DEFMETHOD REINSTATE-BACKTRACKED ...) ; compiling (DEFUN CLONE-BACKTRACKS ...) ; compiling (DEFMETHOD BACKTRACK ...) ; compiling (DEFMETHOD BACKTRACK-SLOT ...); ; compilation unit finished ; caught 3 WARNING conditions ; /home/dan/src/ucw_dev/src/rerl/backtracking.fasl written ; compilation finished in 0:00:00 #P"/home/dan/src/ucw_dev/src/rerl/backtracking.fasl" T I have a feeling this is just a stupid error on my part, as ucw-boxset works just fine. But after double-checking my dependencies and re-reading the README, I'm not sure what it is. Thanks guys -- Dan Beauchesne dbeauchesne -at- gmail -dot- com From vanek at acd.net Tue Jun 13 07:27:12 2006 From: vanek at acd.net (Lou Vanek) Date: Tue, 13 Jun 2006 07:27:12 +0000 Subject: [Bese-devel] compile-op error on backtracking.lisp In-Reply-To: <87ver6bwb3.fsf@localhost.localdomain> References: <87ver6bwb3.fsf@localhost.localdomain> Message-ID: <448E68D0.7000003@acd.net> Short answer: this is probably no big deal. Long answer: you can probably turn this off by setting *warn-undefined* to nil in start.lisp. Whenever a ucw file is compiled and sees "with-call/cc" a special code walker is invoked that parses all the code within the "with-call/cc" scope. Sometimes it doesn't know about variables and functions outside this scope and issues this warning. You can test to make sure this code is working properly by running the QUICKSTART Hello application. If you can get this program to greet you a few times then you know continuations are working properly. I'm running Clisp and I don't get this warning (for reasons I'm not wholely aware of), but Clisp brings its own bundle of problems to the table. Lou Vanek -- Man will occasionally stumble over the truth, but most of the time he will pick himself up and continue on. Winston Churchill Dan Beauchesne wrote: > Hi all, > > Please bear with me, I'm new to lisp. > > My setup: > SBCL 0.9.13.30 (on debian etch) > ucw_dev latest (ie. today) > > I've downloaded all the UCW dependencies and made sure they are > loadable by ASDF. When I try to load the start.lisp file, it seems to > be going fine for some time and then the slime debugger pops up with a > compile-op error on backtracking.lisp. > > So when I do a (compile-file "/path/to/rerl/backtracking.lisp") > I get: > > ; compiling (IN-PACKAGE :IT.BESE.UCW) > ; compiling (DEFMACRO MAKE-PLACE ...) > ; compiling (DEFMETHOD PLACE ...) > > ; file: /home/dan/src/ucw_dev/src/rerl/backtracking.lisp > ; in: DEFMETHOD PLACE (PLACE) > ; (DEFMETHOD IT.BESE.UCW::PLACE > ; ((IT.BESE.UCW::PLACE IT.BESE.UCW::PLACE)) > ; "Returns the current value of PLACE." > ; (ETYPECASE (IT.BESE.UCW::PLACE.GETTER IT.BESE.UCW::PLACE) > ; (FUNCTION > ; (FUNCALL (IT.BESE.UCW::PLACE.GETTER IT.BESE.UCW::PLACE))) > ; (IT.BESE.ARNESI::CLOSURE/CC > ; (IT.BESE.ARNESI:WITH-CALL/CC (FUNCALL #))))) > ; > ; caught WARNING: > ; Reference to unknown variable PLACE. > > ; compiling (DEFMETHOD (SETF PLACE) ...) > > ; file: /home/dan/src/ucw_dev/src/rerl/backtracking.lisp > ; in: DEFMETHOD (SETF PLACE) (T PLACE) > ; (DEFMETHOD (SETF IT.BESE.UCW::PLACE) > ; (IT.BESE.UCW:VALUE (IT.BESE.UCW::PLACE IT.BESE.UCW::PLACE)) > ; "Set the value of PLACE to VALUE." > ; (ETYPECASE (IT.BESE.UCW::PLACE.SETTER IT.BESE.UCW::PLACE) > ; (FUNCTION > ; (FUNCALL (IT.BESE.UCW::PLACE.SETTER IT.BESE.UCW::PLACE) > ; IT.BESE.UCW:VALUE)) > ; (IT.BESE.ARNESI::CLOSURE/CC > ; (IT.BESE.ARNESI:WITH-CALL/CC (FUNCALL # IT.BESE.UCW:VALUE))))) > ; > ; caught WARNING: > ; Reference to unknown variable PLACE. > ; > ; caught WARNING: > ; Reference to unknown variable VALUE. > > ; compiling (DEFMETHOD CLONE-PLACE-VALUE ...) > ; compiling (DEFCONSTANT +UNBOUND-VALUE+ ...) > ; compiling (DEFMETHOD SAVE-BACKTRACKED ...) > ; compiling (DEFMETHOD REINSTATE-BACKTRACKED ...) > ; compiling (DEFUN CLONE-BACKTRACKS ...) > ; compiling (DEFMETHOD BACKTRACK ...) > ; compiling (DEFMETHOD BACKTRACK-SLOT ...); > ; compilation unit finished > ; caught 3 WARNING conditions > > ; /home/dan/src/ucw_dev/src/rerl/backtracking.fasl written > ; compilation finished in 0:00:00 > #P"/home/dan/src/ucw_dev/src/rerl/backtracking.fasl" > T > > I have a feeling this is just a stupid error on my part, as ucw-boxset > works just fine. But after double-checking my dependencies and > re-reading the README, I'm not sure what it is. > > Thanks guys > > -- > > Dan Beauchesne > dbeauchesne -at- gmail -dot- com > _______________________________________________ > bese-devel mailing list > bese-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel > From tpop.news at gmail.com Tue Jun 13 03:05:09 2006 From: tpop.news at gmail.com (Tom Popovich) Date: Mon, 12 Jun 2006 23:05:09 -0400 Subject: [Bese-devel] UCW box-set - undefined-function error get it.bese.arnesi::get-match-handler Message-ID: <5671b1b50606122005h21b71bcam15284912c75bc099@mail.gmail.com> Error: I get undefined-function : get it.bese.arnesi::get-match-handler on current box set. Details: Downloaded the box set release; did load start.lisp Many files loaded then I get: attempt to call the undefined function (setf it.bese.arnesi::get-match-handler) with args: # :bind. [Condition of type undefined-function] [[ I grepped all the lisp code and could not find any definition in the box set source code.]] Has anyone else seen this error w/ the latest box set Repro: *wget* http://common-lisp.net/project/*ucw*/*ucw*-*boxset*.tar.gz extract it. load start.lisp -------------- next part -------------- An HTML attachment was scrubbed... URL: From vanek at acd.net Tue Jun 13 11:08:45 2006 From: vanek at acd.net (Lou Vanek) Date: Tue, 13 Jun 2006 11:08:45 +0000 Subject: [Bese-devel] Re: UCW box-set - undefined-function error get it.bese.arnesi::get-match-handler In-Reply-To: <5671b1b50606122005h21b71bcam15284912c75bc099@mail.gmail.com> References: <5671b1b50606122005h21b71bcam15284912c75bc099@mail.gmail.com> Message-ID: Tom Popovich wrote: > Error: > I get undefined-function : get it.bese.arnesi::get-match-handler > on current box set. > > Details: > > Downloaded the box set release; did load start.lisp Many files > loaded then I get: > > > attempt to call the undefined function (setf > it.bese.arnesi::get-match-handler) with args: > # #x20e4d7a2> :bind. > [Condition of type undefined-function] > > [[ I grepped all the lisp code and could not find any definition in the > box set source code.]] > > > Has anyone else seen this error w/ the latest box set > > Repro: > *wget* http://common-lisp.net/project/*ucw*/*ucw*-*boxset*.tar.gz > > extract it. > > load start.lisp > > > ------------------------------------------------------------------------ > > _______________________________________________ > bese-devel mailing list > bese-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel Line 122 of matcher.lisp creates the matcher that your Lisp is complaining about: (def-matcher :bind (spec var) When file matcher.lisp is loaded it should be creating the :bind matcher (with this line). The matcher is stored in the match-handler hash table, so as long as hash.lisp and matcher.lisp are loaded prior to the file that is giving you trouble the function that is causing you the trouble should be defined. Perhaps you could tell us your Lisp version and show us a longer transcript of the output of where the error is occurring so we can see what is prompting the error. Is matcher.lisp and hash.lisp loading w/o error and warning? What file is loading when you get the error? Do you know the line number or function that it dies on? Lou Vanek -- Fairy tales do not tell children the dragons exist. Children already know that dragons exist. Fairy tales tell children the dragons can be killed. -- G.K.Chesterton From hoan at ton-that.org Tue Jun 13 12:18:40 2006 From: hoan at ton-that.org (Hoan Ton-That) Date: Tue, 13 Jun 2006 22:18:40 +1000 Subject: [Bese-devel] More unwalker and Lisp-1 fixes Message-ID: Hey Marco, I've fixed the unwalker to handle `eval-when'. Also some Lisp-1 forms were missing like `throw' and `return-from'. We can also now use `return-from' with `defun1' and `defmethod1'. Thats it! Have a nice day! Hoan -------------- next part -------------- A non-text attachment was scrubbed... Name: CHANGESET Type: application/octet-stream Size: 32440 bytes Desc: not available URL: From marijnh at gmail.com Tue Jun 13 14:13:07 2006 From: marijnh at gmail.com (Marijn Haverbeke) Date: Tue, 13 Jun 2006 16:13:07 +0200 Subject: [bese-devel] parenscript regexps Message-ID: It seems that the UCW version of parenscript adds slashes to it's argument when printing it. This is contrary to what the parenscript manual says ("The regex form actually does nothing at all to its argument, and prints it as is."), and makes it impossible to do things like "/bla/i" (case-insensitive compare). I can't download the latest non-ucw parenscript because that site (the one linked from CLiki) has been down forever, but the ASDF-install version of parenscript does not add these slashes. So think the UCW version shouldn't do that either. Simply a matter of changing (defmethod js-to-strings ((regex regex) start-pos) (declare (ignore start-pos)) (list (format nil "/~A/" (value regex)))) in src/js.lisp and removing the slashes in the string. Regards, Marijn Haverbeke -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.lendvai at gmail.com Tue Jun 13 14:38:16 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Tue, 13 Jun 2006 16:38:16 +0200 Subject: [bese-devel] parenscript regexps In-Reply-To: References: Message-ID: > So think the UCW version shouldn't do that either. Simply a matter of > changing > > (defmethod js-to-strings ((regex regex) start-pos) > (declare (ignore start-pos)) > (list (format nil "/~A/" (value regex)))) or maybe changing the manual... that noone cared about much because you have the code that sais it all (at least about the nifty details like this). - attila (alias 101 on irc &no 'its not lisp code :) From vanek at acd.net Tue Jun 13 14:53:18 2006 From: vanek at acd.net (Lou Vanek) Date: Tue, 13 Jun 2006 14:53:18 +0000 Subject: [bese-devel] parenscript regexps In-Reply-To: References: Message-ID: <448ED15E.1030905@acd.net> Marijn Haverbeke wrote: > It seems that the UCW version of parenscript adds slashes to it's > argument when printing it. This is contrary to what the parenscript > manual says ("The regex > form actually does nothing at all to its argument, and prints it as > is."), and makes it impossible to do things like "/bla/i" > (case-insensitive compare). I can't download the latest non-ucw > parenscript because that site (the one linked from CLiki) has been down > forever, but the ASDF-install version of parenscript does not add these > slashes. > > So think the UCW version shouldn't do that either. Simply a matter of > changing > > (defmethod js-to-strings ((regex regex) start-pos) > (declare (ignore start-pos)) > (list (format nil "/~A/" (value regex)))) > > in src/js.lisp and removing the slashes in the string. > > Regards, > Marijn Haverbeke > > > ------------------------------------------------------------------------ > > _______________________________________________ > bese-devel mailing list > bese-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel ;; Maybe this makes more sense? (defun first-slash-p (string) (and (> (length string) 0) (eq (char string 0) '#\/))) (defmethod js-to-strings ((regex regex) start-pos) (declare (ignore start-pos)) (let ((slash (if (first-slash-p (value regex)) nil "/"))) (list (format nil (concatenate 'string slash "~A" slash) (value regex))))) Lou Vanek -- Civilization had too many rules for me, so I did my best to rewrite them. Bill Cosby From marijnh at gmail.com Tue Jun 13 18:01:53 2006 From: marijnh at gmail.com (Marijn Haverbeke) Date: Tue, 13 Jun 2006 20:01:53 +0200 Subject: [bese-devel] parenscript regexps In-Reply-To: References: Message-ID: On 6/13/06, Attila Lendvai wrote: > > > So think the UCW version shouldn't do that either. Simply a matter of > > changing > > > > (defmethod js-to-strings ((regex regex) start-pos) > > (declare (ignore start-pos)) > > (list (format nil "/~A/" (value regex)))) > > or maybe changing the manual... that noone cared about much because > you have the code that sais it all (at least about the nifty details > like this). Well - that will not solve the problem of not being able to add options after the second slash. I guess Lou's idea works best. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marijnh at gmail.com Tue Jun 13 20:53:05 2006 From: marijnh at gmail.com (Marijn Haverbeke) Date: Tue, 13 Jun 2006 22:53:05 +0200 Subject: [Bese-devel] HTML-elements (was: Changing the css-class of input fields) Message-ID: On 6/9/06, Marco Baringer wrote: > > what would work (and is a good idea now that you bring it up) is an > html-element class of which widget class (with its current behaviour) > and generic-html-input are subclasses of. html-element would have > slots for style, class, id, onclick, etc. widget-class would maintain > its current behaviour and the form stuff would avoid spurious divs. Attached is a patch to ucw_dev implementing this. At least I hope it works - I used 'darcs record' + 'darcs send -o' to create it, and it sure *looks* like a patch. Lemme know whether it is of any use. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: html-element-patch Type: application/octet-stream Size: 22922 bytes Desc: not available URL: From tpop.news at gmail.com Thu Jun 15 02:47:36 2006 From: tpop.news at gmail.com (Tom Popovich) Date: Wed, 14 Jun 2006 22:47:36 -0400 Subject: [Bese-devel] Re: UCW box-set - undefined-function error get it.bese.arnesi::get-match-handler Message-ID: <5671b1b50606141947m6cd4cbbetc804ade4e1909f74@mail.gmail.com> Hi Lou, || Line 122 of matcher.lisp creates the matcher that your Lisp is complaining about: || (def-matcher :bind (spec var) || || When file matcher.lisp is loaded it should be creating the :bind matcher (with this line). || Yes that is the line; I tried to eval that form directly and it gives the same error. || The matcher is stored in the match-handler hash table, so as long as hash.lisp || and matcher.lisp are loaded prior to the file that is giving you trouble the || function that is causing you the trouble should be defined. || || Perhaps you could tell us your Lisp version and show us a longer transcript || of the output of where the error is occurring so we can see what is prompting || the error. WHAT LISP: I was using Allegro version 8.0 on Windows (modern image version - the one w/ case sensitive symbol names) - its called mlisp.exe they also have alisp.exe that uppercases all symbol names. || || Is matcher.lisp and hash.lisp loading w/o error and warning? || What file is loading when you get the error? Do you know the line number || or function that it dies on? || || Lou Vanek hash.lisp loads fine. matcher.lisp is causing problems - it is this function: at line# 122 in matcher.lisp that I have problems: ---------------------------------------------- (def-matcher :bind (spec var) "The :bind matcher attempts to match MATCHER and bind whatever MATCHER consumnd to VAR. group is equivalent to SPEC except the value of matched when spec has matched will be bound to var." (declare (special %bind-vars%)) (push var %bind-vars%) (let ((spec-matcher (%make-matcher spec))) (lambda (s k q) (funcall spec-matcher s (lambda (s. k. q.) (declare (ignore k.)) ;; SPEC succeded, bind var (funcall k (copy-state s. :bindings (cons (cons var (matched s.)) (bindings s.))) k q.)) q)))) ----------------------- I tried to eval the def-matcher macro definition (which evals fine) but then even when hand evaluating the above, I get the same error "undefined function (setf it.bese.arnesi::get-match-handler) " It works find up until the above form is evaluated. --- ---- High-Level steps that I did (and corresponding line number in the attached log of my complete REPL session: See file REPL_last_run_attempt.txt.gz.uu (uuencoded gzip-ed text file copied from xemacs slime buffer)) I Change-Directory to the top level directory where I extracted the UCW box set, then did: 1. (load "start.lisp") 2. First problem was easier to fix: I had problems w/ with-unique-names, => caused by compiling: arnesi_dev\src\one-liners.lisp (which uses arnesi_dev\src\packages.fasl) so you will see I did a restart to "use cl-ppcre::with-unique-names" in place of "it.bese.arnesi:with-unique-names"[SEE line #235-255 in the log file where I redo (load "start.lisp") ] 3. The above restart helps keep moving... but later when => ?fast loading: \arnesi_dev\src\matcher.fasl we get Error: attempt to call the undefined function (setf it.bese.arnesi::get-match-handler) at line #583-595 (which I originally posted to start this thread). --- later on -- just for a test -- 4. see, Near line 627, I redid: (load "start.lisp") ;;; this time choose "2: [skip] skip loading C:\Documents and Settings\popovth\.lispbox\fasl\allegro- 8.0-mswindows-x86\tjp\lisp\ucw-boxset\arnesi_dev\src\matcher.fasl" and see how far we get... ( I know the above is a little risky, but I did it just as a test to see how far I can continue compiling UCW) you will see near line #1151, I get an error that: restart:#P'C:\\Documents and Settings\\popovth\\.lispbox\\fasl\\allegro- m8.0-mswindows-x86\\tjp\\lisp\\ucw-boxset\\parenscript\\src\\js-html.fasl' does not exist, PS: I am using the asdf setup that is done in "lispbox" which is what I used to bootstrap my environment *but I am running a CVS copy of SLIME that I pulled about Feb 2006. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: REPL_last_run_attempt.txt.gz.uu Type: application/octet-stream Size: 7987 bytes Desc: not available URL: From tpop.news at gmail.com Thu Jun 15 02:54:33 2006 From: tpop.news at gmail.com (Tom Popovich) Date: Wed, 14 Jun 2006 22:54:33 -0400 Subject: [Bese-devel] Re: UCW box-set - undefined-function error get it.bese.arnesi::get-match-handler Message-ID: <5671b1b50606141954k2f7fe5bfl1fb5ee3ac45d9365@mail.gmail.com> Hi Lou, [[ here is a repeat of the previous email's header -- attaching the log file caused the entire discussion to get stored on a link.]] I downloaded the file in the link but the size is wrong. If anyone wants the link, send me email and I'll send you a copy. || Line 122 of matcher.lisp creates the matcher that your Lisp is complaining about: || (def-matcher :bind (spec var) || || When file matcher.lisp is loaded it should be creating the :bind matcher (with this line). || Yes that is the line; I tried to eval that form directly and it gives the same error. || The matcher is stored in the match-handler hash table, so as long as hash.lisp || and matcher.lisp are loaded prior to the file that is giving you trouble the || function that is causing you the trouble should be defined. || || Perhaps you could tell us your Lisp version and show us a longer transcript || of the output of where the error is occurring so we can see what is prompting || the error. WHAT LISP: I was using Allegro version 8.0 on Windows (modern image version - the one w/ case sensitive symbol names) - its called mlisp.exe they also have alisp.exe that uppercases all symbol names. || || Is matcher.lisp and hash.lisp loading w/o error and warning? || What file is loading when you get the error? Do you know the line number || or function that it dies on? || || Lou Vanek hash.lisp loads fine. matcher.lisp is causing problems - it is this function: at line# 122 in matcher.lisp that I have problems: ---------------------------------------------- (def-matcher :bind (spec var) "The :bind matcher attempts to match MATCHER and bind whatever MATCHER consumnd to VAR. group is equivalent to SPEC except the value of matched when spec has matched will be bound to var." (declare (special %bind-vars%)) (push var %bind-vars%) (let ((spec-matcher (%make-matcher spec))) (lambda (s k q) (funcall spec-matcher s (lambda (s. k. q.) (declare (ignore k.)) ;; SPEC succeded, bind var (funcall k (copy-state s. :bindings (cons (cons var (matched s.)) (bindings s.))) k q.)) q)))) ----------------------- I tried to eval the def-matcher macro definition (which evals fine) but then even when hand evaluating the above, I get the same error "undefined function (setf it.bese.arnesi::get-match-handler) " It works find up until the above form is evaluated. --- ---- High-Level steps that I did (and corresponding line number in the attached log of my complete REPL session: See file REPL_last_run_attempt.txt.gz.uu (uuencoded gzip-ed text file copied from xemacs slime buffer)) I Change-Directory to the top level directory where I extracted the UCW box set, then did: 1. (load "start.lisp") 2. First problem was easier to fix: I had problems w/ with-unique-names, => caused by compiling: arnesi_dev\src\one-liners.lisp (which uses arnesi_dev\src\packages.fasl) so you will see I did a restart to "use cl-ppcre::with-unique-names" in place of "it.bese.arnesi:with-unique-names"[SEE line #235-255 in the log file where I redo (load "start.lisp") ] 3. The above restart helps keep moving... but later when => ?fast loading: \arnesi_dev\src\matcher.fasl we get Error: attempt to call the undefined function (setf it.bese.arnesi::get-match-handler) at line #583-595 (which I originally posted to start this thread). --- later on -- just for a test -- 4. see, Near line 627, I redid: (load "start.lisp") ;;; this time choose "2: [skip] skip loading C:\Documents and Settings\popovth\.lispbox\fasl\allegro- 8.0-mswindows-x86\tjp\lisp\ucw-boxset\arnesi_dev\src\matcher.fasl" and see how far we get... ( I know the above is a little risky, but I did it just as a test to see how far I can continue compiling UCW) you will see near line #1151, I get an error that: restart:#P'C:\\Documents and Settings\\popovth\\.lispbox\\fasl\\allegro- m8.0-mswindows-x86\\tjp\\lisp\\ucw-boxset\\parenscript\\src\\js-html.fasl' does not exist, PS: I am using the asdf setup that is done in "lispbox" which is what I used to bootstrap my environment *but I am running a CVS copy of SLIME that I pulled about Feb 2006. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vanek at acd.net Thu Jun 15 08:34:48 2006 From: vanek at acd.net (Lou Vanek) Date: Thu, 15 Jun 2006 08:34:48 +0000 Subject: [Bese-devel] Re: UCW box-set - undefined-function error get it.bese.arnesi::get-match-handler In-Reply-To: <5671b1b50606141947m6cd4cbbetc804ade4e1909f74@mail.gmail.com> References: <5671b1b50606141947m6cd4cbbetc804ade4e1909f74@mail.gmail.com> Message-ID: <44911BA8.3060507@acd.net> Tom Popovich wrote: > Hi Lou, > > || Line 122 of matcher.lisp creates the matcher that your Lisp is complaining about: > || (def-matcher :bind (spec var) > || > || When file matcher.lisp is loaded it should be creating the :bind matcher (with this line). > || > > Yes that is the line; I tried to eval that form directly and it gives the same error. > > || The matcher is stored in the match-handler hash table, so as long as hash.lisp > || and matcher.lisp are loaded prior to the file that is giving you trouble the > || function that is causing you the trouble should be defined. > || > || Perhaps you could tell us your Lisp version and show us a longer transcript > || of the output of where the error is occurring so we can see what is prompting > || the error. > > WHAT LISP: I was using Allegro version 8.0 on Windows (modern image version - the one w/ case sensitive symbol names) - its called mlisp.exe they also have alisp.exe that uppercases all symbol names. [snip] I'm 90% sure this is the problem: the hash table's getters/setters are dynamically created with uppercase letters, yet when they are invoked they use lowercase letters. This is fine for ansi cl, but not so much for "modern" versions of lisp. Use the ansi version of allegro (alisp) and I think that solves this problem. BR Lou Vanek -- Change is inevitable, except from a vending machine. /// Bram Moolenaar From tpop.news at gmail.com Fri Jun 16 01:09:28 2006 From: tpop.news at gmail.com (Tom Popovich) Date: Thu, 15 Jun 2006 21:09:28 -0400 Subject: [Bese-devel] Re: UCW box-set - undefined-function error Message-ID: <5671b1b50606151809x4eedd1c1y70c42ff4ee958a44@mail.gmail.com> || > WHAT LISP: I was using Allegro version 8.0 on Windows (modern image || > version - the one w/ case sensitive symbol names) - its called mlisp.exe || > they also have alisp.exe that uppercases all symbol names. || [snip] || || I'm 90% sure this is the problem: the hash table's getters/setters are dynamically created || with uppercase letters, yet when they are invoked they use lowercase letters. || This is fine for ansi cl, but not so much for "modern" versions of lisp. || || Use the ansi version of allegro (alisp) and I think that solves this problem. Thanks again Lou! For alisp.exe, I fixed some key upper -vs- lower case symbol problems. I had started replacing depackage import/uses using defpackage2 (which I thought I'd have to replace everywhere but so far I've only changed one file - split-sequence.lisp ). I will post the changes to the forum. ?? what is the best way to submit code? I tried to email a uuencoded gzip compressed file previously but that did easily make it to the web site. now have loaded " start.lisp" (at least the load now returns true!) And I can click on *http://127.0.0.1:8080/ * and see the demos. I have a problem w/ dynamic form demo which blows up. The other demos seem to work. *I needed to fix 2** areas* *:* *(1)* package names == sol ved with coming up w/ a new defpackage2 macro *(2)* with-unique-names macro from package :it.bese.arnesi is never found Details: *== (1) ==* I had some trouble w/ package names & I developed a nice soln to always use symbol name. It works. BUT for some crazy reason (unknown to me) I had to stickstring-2-function-symbol-name and string-2- package-symbol-name it in the CL package to get it to work. Otherwise I got "unbound fnct" errors in the split-sequence.lisp file. (which is what I did) See end of this email for code: I defined a new macro defpackage2 that automatically converts string forms to symbols. Idea is to easily map: (defpackage2 :split-sequence (:use "cl") (:nicknames "partition") (:export "split-sequence" "split-sequence-if" "split-sequence-if-not" "partition" "partition-if" "partition-if-not")) to: (defpackage :split-sequence (:USE :CL) (:NICKNAMES :PARTITION) (:EXPORT #:SPLIT-SEQUENCE #:SPLIT-SEQUENCE-IF #:SPLIT-SEQUENCE-IF-NOT #:PARTITION #:PARTITION-IF #:PARTITION-IF-NOT)) Then I was going to go thru the " box set" and replace all defpackage w/ defpackage2 *== (2) ==* I had to hand eval the with-unique-names macro when lisp was in a error break: ( its definition is shown below ??? for some reason it thinks that its not defined in the package yet its there near the top of the file that is being compiled???) --- for some reason somewhere in one-liners.lisp it tries to use : WITH-UNIQUE-NAMES and I always had to choose restart use the one from CL-PPRE ? this time I eval-ed the macro definition while in the : it.bese.arnesi package Appendix: -- to solve == (1) == here is some new code I put into top of file: split-sequence.lisp ( strangely this file is the only place that I had to use defpackage2, but most likely a better place would be in new ?packager? module: Then we could have a defpackage2 -> defpackage by default (macro expands to `(defpackage ,packagename , at args) and in other lisps like allegro and lispworks??? We use the macro I wrote to force us to use symbols for fnct + package names. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (in-package :COMMON-LISP) ;;;;;;;;;;;;;;;;;;;;;;;; ;; allegro likes lower case names for modern images! *Its really hard to get ;; the uppercase syms correct ==> so we use a defpackage2 that maps strings ;; to symbols... ;;;;;;;;;;;;;;;;;;;;;;;; (defun string-2-package-symbol-name (string) "convert a string like \"cl\" to sym: :cl" (let ((downcase (string-downcase string))) ;;(print downcase) (read-from-string (format nil ":~A" downcase)) ;; return a SYM ;; (format nil ":~A" downcase) ;; return a STRING )) ; ; (string-2-symbol "cl") (defun string-2-function-symbol-name (string) "convert a string like \"downcase\" to sym: #:downcase" (let ((downcase (string-downcase string))) ;;(print downcase) (read-from-string (format nil "#:~A" downcase)) ;; return a SYM ;; (format nil "#:~A" downcase) ;; return a STRING )) ; ; (string-2-symbol "downcase") (defmacro defpackage2 (pkg-name &rest spec-list) "smartly define a package, hunt for :use :nicknames :export and make any symbol names specified as a string to be symbols (defpackage2 :split-sequence (:use 'cl') (:nicknames 'partition') (:export 'split-sequence' 'split-sequence-if' 'split-sequence-if-not' 'partition' 'partition-if' 'partition-if-not')) ==> converts to: (DEFPACKAGE :SPLIT-SEQUENCE (:USE :CL) (:NICKNAMES :PARTITION) (:EXPORT #:SPLIT-SEQUENCE #:SPLIT-SEQUENCE-IF #:SPLIT-SEQUENCE-IF-NOT #:PARTITION #:PARTITION-IF #:PARTITION-IF-NOT)) " (labels ((convert-all-strings-to-syms (list str-to-sym-converter) (mapcar #'(lambda (STR) (if (stringp STR) (funcall str-to-sym-converter STR) STR)) list))) (dolist (L spec-list) (case (first L) ( (:use :nicknames) (format t "fixing ~A~%" (first L)) (setf (cdr L) ;(convert-all-strings-to-syms (cdr L) #'split-sequence:string-2-package-symbol-name ) (convert-all-strings-to-syms (cdr L) #'string-2-package-symbol-name ) ;;(cdr L) )) ( (:export) (format t "fixing ~A~%" (first L)) (setf (cdr L) ;(convert-all-strings-to-syms (cdr L) #'split-sequence:string-2-function-symbol-name ) (convert-all-strings-to-syms (cdr L) #'string-2-function-symbol-name ) ;;(cdr L) ) )))) ;; `(quote (defpackage3 ,pkg-name ,spec-list)) ;;; use this if you just want it returned quoted to call defpackage3 a fictuous fnct (w/o being run) `(defpackage ,pkg-name , at spec-list))) ; ;== to test it: ; ; (macroexpand-1 (defpackage2 :split-sequence ; (:use "cl") ; (:nicknames "partition") ; (:export "split-sequence" "split-sequence-if" "split-sequence-if-not" ; "partition" "partition-if" "partition-if-not"))) ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; then I do: ;; allegro likes lower case names for modern images! *Its really hard to get upper case vs lower case right w/ strings evidently * defpackage2 will always work. #+allegro (defpackage2 :split-sequence (:use "cl") (:nicknames "partition") (:export "split-sequence" "split-sequence-if" "split-sequence-if-not" "partition" "partition-if" "partition-if-not")) #+allegro (in-package :split-sequence) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbeauchesne at gmail.com Thu Jun 15 11:18:58 2006 From: dbeauchesne at gmail.com (Dan Beauchesne) Date: 15 Jun 2006 20:18:58 +0900 Subject: [Bese-devel] Another newbie UCW question.. dynamic links Message-ID: <87ac8e3bvh.fsf@localhost.localdomain> Hi list, Thanks to Lou I got UCW working. But I've already hit a snag. Basically, I want to query the user and search through a hash table for results, and then display the results. That part works fine. The thing is, I need each separate result to be a link which, when clicked, will add that result to a separate list. I did something like.. (in the main component) (dotimes (n (length results)) (ucw:a :action (add-to-list main (nth n results)) (<:as-html (nth n results)))) (defaction add-to-list ((res main) it) (setf (clicked-list main) (append (list it) (clicked-list main)))) I thought this was too easy, and apparently it was :), the page loads fine and each result it clickable, but when I click it, some kind of inifinite loop happens (doesn't say what), and I have to kill it. What is the best way to do this problem? -- Dan Beauchesne dbeauchesne -at- gmail -dot- com From mb at bese.it Fri Jun 16 07:33:11 2006 From: mb at bese.it (Marco Baringer) Date: Fri, 16 Jun 2006 09:33:11 +0200 Subject: [Bese-devel] Re: component tree References: <448ADF4F.8000708@acd.net> Message-ID: "Marijn Haverbeke" writes: > So why is the session put into a hidden input when it is also stored in a > cookie? Do UCW applications without cookies work at all? A quick experiment > seems to suggest they do at least simple things right, what is the difference > between an application with cookies and one without? ucw apps work fine without cookies, though you lose "pretty" urls. the cookie code is very simplistic and does not keep track of whether the client accepts cookies or not, so we always set bot the cookie and the request parameter for forms. > Also, I noticed that when no :action is defined for a form, the accessors & > writers of its fields have no effect. Is this by design? If so, why? Message-ID: "Ties Stuij" writes: >> Could somebody give me a hint on the meaning of the _s and _f hidden inputs that are added to > Well as i understand it the _s stands for the user session to look > for, the _f is for the relevant frame and the make-action associates > the action you want to execute with a string in the relevant frame. If > you use slime, alt-. your way to it. _s is the id for the user's session. _f is the id for the frame (request/response iteration). you'll also see _a, which is the action defined within that frame. all the other 'random junk' parameters are callbacks. -- -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 Jun 16 07:42:18 2006 From: mb at bese.it (Marco Baringer) Date: Fri, 16 Jun 2006 09:42:18 +0200 Subject: [Bese-devel] Re: component tree References: <448ADF4F.8000708@acd.net> Message-ID: Lou Vanek writes: > [bump] > > ... > Next question. I'm working on the make-new-callback thing now, because > it doesn't behave very well in some situations (multiple forms, which > have names with the same fields, on a page, and when you want to > always run some code when a form is submitted, for use with checkboxes > and multi-select inputs)... but I am running into some serious > terminology confusion. can you explain this multiple form problem better? i may just be a very simplistic form user, but multiple forms on a page have never caused me any grief. > Also, is there something I could read to get some more clue on what > the 'component tree' is? I actually thought it was just a stack... but > some comments in the ucw sources are telling me it is an actual > *tree*. How does it work, where is it stored, and when exactly are > components copied/re-created? components are never copied or created unless the developer explictly calls make-instance (or CALL, which is a wrapper around, among other things, make-instance). The component "tree" is an actualy tree and it is rooted at the object in the frame's window-component slot. many components will also have nested-components (sometimes refered to as sub-component in the source). a nested component is nothing more than a clos slot whose value is a component object (this slot was, 99% of the time, declared via a :component slot argument). The component "tree" is used during the rendering phase, it serves two purposes: 1) we assume (but do not stritly enforce) that rendering a component will also render all of its sub components and 2) when creating urls for links a component can add reuest parameters to all of the links created by itself and all of its children. the point of this later feature is to allow a search-results-viewer component to change the links created by its nested item-details components so that, should the user's session expire, or the link be sent via email, the search data can be recreated. There is also a component stack, which is completly unrelated to component rendering. the component stack ties a component to the component which call'd it. in the counter example, when the page is asking you "are you sure you want to answer ... to ...?", that query component was called by another query component which was called by the counter component. this component stack is maintained via the calling-component slot in component objects. you can, 99.9% of the time, completly ignore this component stack. questions? -- -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 Jun 16 07:45:29 2006 From: mb at bese.it (Marco Baringer) Date: Fri, 16 Jun 2006 09:45:29 +0200 Subject: [Bese-devel] Re: dom-id's in xxx-select-field elements References: <44889CD1.8070601@acd.net> <4489A6A4.8030503@acd.net> <4489D900.3090906@acd.net> Message-ID: Lou Vanek writes: > Shame there are two branches. I would've just added more > config parameters and never have split it. This is the CL > problem in microcosm--fractured at best / spread too thin > and left for dead at worst. CL may be a victim of its own > malleability: it's so easy to change things that everybody and his > dog wants to make their own version of the program. Heck, that > even applies to me and I'm just a Lisp-young'n. wrong. the ucw_dev branch is what I, and others, use for day to day work. it does not undergo major changes without much fore-warning. the ucw_ajax branch is attempting to add ajax goodness to ucw, this can not be done if you're limited to small, stable, changes. ucw_ajax gives attila the freedom to experiment with different things without making me worry about breaking all my apps every other day. there's some very cool stuff going on on that branch, and it _will_ be merged into ucw_dev (and closed) at some point in the near future. this is not a case of fragmentation or forking, this is just a normal development practice. -- -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 Jun 16 07:52:47 2006 From: mb at bese.it (Marco Baringer) Date: Fri, 16 Jun 2006 09:52:47 +0200 Subject: [Bese-devel] Re: compile-op error on backtracking.lisp References: <87ver6bwb3.fsf@localhost.localdomain> <448E68D0.7000003@acd.net> Message-ID: Lou Vanek writes: > Long answer: you can probably turn this off by setting > *warn-undefined* to nil in start.lisp. Whenever a ucw file > is compiled and sees "with-call/cc" a special code walker > is invoked that parses all the code within the "with-call/cc" > scope. Sometimes it doesn't know about variables and functions > outside this scope and issues this warning. exactly. after looking into this for a bit it appears that the problem, on sbcl at least, is this: (defaction foo ((a bar)) ...) which is expanded into: (defmethod foo ((a bar)) (with-call/cc ...)) when sbcl compiles that defmethod form it will macro expand the body twice, the first time around the lexical environment (the &environment object passed to macros) will be NIL and with-call/cc won't see the binding of A, the second time around a complete environment object is passed and the code works (in fact the generated compiled code is correct since sbcl throws away with-call/cc's expansion on that first expansion) . what happens on that first expansion is that with-call/cc signals a warning, asdf, on sbcl, treats this a compile _error_ and breaks. anybody with sbcl skilz able to suggest a solution? -- -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 Jun 16 07:57:06 2006 From: mb at bese.it (Marco Baringer) Date: Fri, 16 Jun 2006 09:57:06 +0200 Subject: [Bese-devel] Re: HTML-elements [UCW API CHANGES] References: Message-ID: "Marijn Haverbeke" writes: > On 6/9/06, Marco Baringer wrote: > > what would work (and is a good idea now that you bring it up) is an > html-element class of which widget class (with its current behaviour) > and generic-html-input are subclasses of. html-element would have > slots for style, class, id, onclick, etc. widget-class would maintain > its current behaviour and the form stuff would avoid spurious divs. > > > Attached is a patch to ucw_dev implementing this. At least I hope it works - I > used 'darcs record' + 'darcs send -o' to create it, and it sure *looks* like a > patch. Lemme know whether it is of any use. applied, thanks. nb: this patch changes the name of some of the accessors from widget-component.XYZ to, the much more sensable, XYZ. -- -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 Jun 16 08:06:00 2006 From: mb at bese.it (Marco Baringer) Date: Fri, 16 Jun 2006 10:06:00 +0200 Subject: [Bese-devel] Re: UCW box-set - undefined-function error References: <5671b1b50606151809x4eedd1c1y70c42ff4ee958a44@mail.gmail.com> Message-ID: "Tom Popovich" writes: > I will post the changes to the forum. ?? what is the best way to submit code? > I tried to email a uuencoded gzip compressed file previously but that > did easily make it to the web site. if possible the best thing is a darcs patch. > Details: > > == (1) == > > I had some trouble w/ package names & I developed a nice soln to always use > symbol name. It works. > BUT for some crazy reason (unknown to me) I had to stick > string-2-function-symbol-name and string-2- package-symbol-name it in the CL > package to get it to work. Otherwise I got "unbound fnct" errors in the > split-sequence.lisp file. > > (which is what I did) See end of this email for code: > > > I defined a new macro defpackage2 that automatically converts string forms to > symbols. the 'solution' to this is to fix the defpackage form: (defpackage :split-sequenc (:use #:common-lisp) (:nicknames #:partition) (:export #:split-sequence #:split-sequence-if #:split-sequence-if-not #:partition #:partition-if #:partition-if-not)) this will work on both ansi and modern lisps and is 100% standard code. > == (2) == > > I had to hand eval the with-unique-names macro when lisp was in a error break: > ( its definition is shown below ??? for some reason it thinks that its not > defined in the package yet its there near the top of the file that is being > compiled???) what happens when compiling a file: loop for form = (read-next-form-from-file) until (no-more-forms-in-file) if (eval-time-of-form-is-:compile-toplevel) do (eval form) else do (compile (MACROEXPAND form)) the idea is that macroexpansion is performed at compile time, macroexpansion requires running user code. let's say you have this file: ------------------------------------------------------------------------ (defun foo () (bar)) (defmacro bar () `(stuff)) ------------------------------------------------------------------------ even though bar is in the same file as foo the definiton of bar is not noticed until after foo has been compilied, however in order to compile foo we need the definiton of bar ... boom! generally the solution to this is to wrap the problematic forms in (eval-when (:compile-toplevel :load-toplevel :execute) ...) [note: there's an eval-always macro in arnesi which makes that easier to write, but i'm going to stick with ansi lisp here] this ensure that the various definitions are available eariel enough. now, im not 100% certain this is your problem, but could you try and see what happens? -- -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 Jun 16 08:11:34 2006 From: mb at bese.it (Marco Baringer) Date: Fri, 16 Jun 2006 10:11:34 +0200 Subject: [Bese-devel] Re: Another newbie UCW question.. dynamic links References: <87ac8e3bvh.fsf@localhost.localdomain> Message-ID: Dan Beauchesne writes: > Hi list, > > Thanks to Lou I got UCW working. But I've already hit a snag. > > Basically, I want to query the user and search through a hash table > for results, and then display the results. That part works fine. > > The thing is, I need each separate result to be a link which, when > clicked, will add that result to a separate list. > > I did something like.. (in the main component) > > (dotimes (n (length results)) ^^^^^^^ (this may not be your only problem). DOTIMES is not required, by ansi, to create a new binding for the iteration variable (n in this case) on each iteration of the loop. the :action attribute which you have on the next line creates a lambda which clases over the binding of N, if DOTIMES reuses the same bindings then all links will end up doing the same thing (call add-to-list with n bound to (length results) or NIL depending). what you want is the dolist* macro (part of arnesi) which ensures that a fresh binding is created: (dolist* (n (length results)) (ucw-stuff-goas-here)) > (ucw:a :action (add-to-list main (nth n results)) > (<:as-html (nth n results)))) > > (defaction add-to-list ((res main) it) > (setf (clicked-list main) (append (list it) (clicked-list main)))) > > I thought this was too easy, and apparently it was :), the page loads > fine and each result it clickable, but when I click it, some kind of > inifinite loop happens (doesn't say what), and I have to kill it. if you wait long enough you will eventually get a stack-overflow, that will be accompanied by a backtrace which we can then use to figure where the infinite loop is happening. (btw: the ucw error includes a backtrace, the backtrace includes copies of all the data on the stack _copied_ for each frame. i once had an error in a file uploead page, in the error page the file's contents (17+MB pdf) was being displayed about 20 times, it took about 5 minutes to show the page. unless you're getting a stack-overflow error don't be sure that it's an infinite loop error). -- -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 Jun 16 08:14:11 2006 From: mb at bese.it (Marco Baringer) Date: Fri, 16 Jun 2006 10:14:11 +0200 Subject: [Bese-devel] Re: ucw boxset problems References: <20060529082658.GA7884@semp.x-si.org> Message-ID: Damir Horvat writes: > Any ideas? sorry, with such an uninformative error i can't begin to guess what the problem is :( can you try, somehow, to get a more detailed backtrace? loading the code from slime may, or may not, allow you to glean something from the error. -- -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 Jun 16 08:15:45 2006 From: mb at bese.it (Marco Baringer) Date: Fri, 16 Jun 2006 10:15:45 +0200 Subject: [Bese-devel] Re: let/cc References: <447C92ED.4040403@acd.net> Message-ID: Lou Vanek writes: > Hi list, > > I got araneida and ucw to start, but, as the error shows below, my first ucw > http request aborts. LET/CC is being expanded into CALL/CC and for some reason > CALL/CC is not defined. I haven't been able to parse marco's call/cc code to > know why. > > Has anybody seen this? > I'm trying to run the ucw examples. i'm guessing from your later mails that you worked around this, what was the problem? -- -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 Jun 16 08:17:04 2006 From: mb at bese.it (Marco Baringer) Date: Fri, 16 Jun 2006 10:17:04 +0200 Subject: [Bese-devel] Re: secure-app#exit-user References: <447D84C0.6030307@core.gen.tr> Message-ID: Evrim ULU writes: > hi, > > here is a patch to fix exit-user. applied. thanks. -- -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 Jun 16 08:16:39 2006 From: mb at bese.it (Marco Baringer) Date: Fri, 16 Jun 2006 10:16:39 +0200 Subject: [Bese-devel] Re: Validators manipulating stylesheets References: Message-ID: "Marijn Haverbeke" writes: > Hi, > > It seems there was a bug in javascript-invalid-handler that caused it to just > add the ucw-form-field-invalid class to elements without removing the valid > class. Maybe this works on some browsers, but on Firefox 1.5 under Linux I > didn't get any red borders around inputs in the example pages. I modified the > functions as follows (3rd and 4th lines are new): thanks. this sholud be fixed in ucw_dev. -- -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 Jun 16 08:21:04 2006 From: mb at bese.it (Marco Baringer) Date: Fri, 16 Jun 2006 10:21:04 +0200 Subject: [Bese-devel] Re: <20060609141803.GB28533@mapcar.org> Message-ID: Matthew Danish writes: > On Fri, Jun 02, 2006 at 01:44:49PM +0200, Marijn Haverbeke wrote: >> Also, I think there is a bug with > - browsers do not seem to add a variable to a request for an unchecked >> checkbox, causing the :accessor or :writer on such tags to never run when >> the box is unchecked. > > This is true; I recently was puzzled by this, and ended up "working > around" by clearing out the value while rendering the page each time. this is what the checkbox elements do in form.lisp, works, but it sure ain't pretty. is there, other than this, a good reason to have callbacks which are called even when the corresponding reuest parameter isn't provided (this is a fairly easy change t omake but will cause problems in the code which assumes the current behaviour). -- -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 Jun 16 08:41:24 2006 From: mb at bese.it (Marco Baringer) Date: Fri, 16 Jun 2006 10:41:24 +0200 Subject: [Bese-devel] Re: streaming binary data References: <522A89FC-7FF1-48C4-AF4A-F12FDA9AE84E@mail.ru> Message-ID: Rtveliashvili Denys writes: > Hi, > > I am looking for a possibility to stream a binary data to user > instead of HTML. it only works with mod_lisp and httpd backends atm (it's doable on portableaserve, but hasn't been done, araneida is more complicated since araneida assumes characters streams). what you'll need to do is: 1) set the request's Content-Type headers using (setf (get-header response "Content-Type") "application/pdf"); 2) send the headers before sending any of the data, and after setting all the interesting headers. use (send-headers response); 3) write the binary data to the response's network-stream. this an (unsinged-byte 8) stream attached directly to the client's browser (or apache in the case of mod_lisp). hth -- -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 Jun 16 08:48:12 2006 From: mb at bese.it (Marco Baringer) Date: Fri, 16 Jun 2006 10:48:12 +0200 Subject: [Bese-devel] Re: component tree In-Reply-To: (Marijn Haverbeke's message of "Fri, 16 Jun 2006 10:12:41 +0200") References: <448ADF4F.8000708@acd.net> Message-ID: "Marijn Haverbeke" writes: > That cleared up some things. What exactly is the practical difference between a > slot in a component that has :component in its slot declaration and one that > doesn't? Only that the holding object can not influence links created in the > held object? the _only_ differences are: 1) when setf'ing (or initializing) a slot defined with :component the component's parent and place slots are updated automatically (see (setf slot-value-using-class) in src/rerl/standard-component/standard-component.lisp). 2) the child-components method only recognizes slots which are :component and contain a subclass of component. > The multiple form problem works like this: When two forms on a page both have a > field with name X, and both register a callback with make-new-callback, the > second callback will override the first one. This is not usually a real > problem, but it's somewhat unelegant. I think it would be a good idea to > organize these callbacks under forms, and only call them when *their* form is > submitted. This could be done with a dynamic variable that is bound with a let > by an The other problem was that it is impossible to register callbacks that allways > get executed when a form is submitted, for input fields whose values do not > correspond 1-to-1 with request parameters (checkbox, multiple select). I'm > still planning to work on this, but my grasp on the action and frame concepts > is still a little weak, so I can't really see what would be the best way to do > this. yeah, this is an issue. attila is working on something like this in the ucw_ajax branch. if that isn't enough, or if i'm misunderstanding what attila is doing, then we should definetly think about how to do this. -- -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 vanek at acd.net Fri Jun 16 09:04:57 2006 From: vanek at acd.net (Lou Vanek) Date: Fri, 16 Jun 2006 09:04:57 +0000 Subject: [Bese-devel] Re: let/cc In-Reply-To: References: <447C92ED.4040403@acd.net> Message-ID: <44927439.6090400@acd.net> Marco Baringer wrote: > Lou Vanek writes: > > >> Hi list, >> >> I got araneida and ucw to start, but, as the error shows below, my first ucw >> http request aborts. LET/CC is being expanded into CALL/CC and for some reason >> CALL/CC is not defined. I haven't been able to parse marco's call/cc code to >> know why. >> >> Has anybody seen this? >> I'm trying to run the ucw examples. > > > > i'm guessing from your later mails that you worked around this, what > was the problem? It was a red herring, masking the real cause of the problem that was caused by the LOOP macro in Hello.lisp. (GO-FORM :make-load-form-XXX)* was being written into the .fas instead of a (GO-FORM ) form. Work around: use asdf's load-source-op instead of load-op. * where :make-load-form-XXX is just a symbol, not an actual load form, and XXX represents a random integer. From attila.lendvai at gmail.com Fri Jun 16 10:06:41 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Fri, 16 Jun 2006 12:06:41 +0200 Subject: [Bese-devel] Re: References: <20060609141803.GB28533@mapcar.org> Message-ID: > > This is true; I recently was puzzled by this, and ended up "working > > around" by clearing out the value while rendering the page each time. > > this is what the checkbox elements do in form.lisp, works, but it sure > ain't pretty. is there, other than this, a good reason to have > callbacks which are called even when the corresponding reuest > parameter isn't provided (this is a fairly easy change t omake but > will cause problems in the code which assumes the current behaviour). submit callbacks in the ajax branch could be used for this. callbacks even have priorities and dependencies among each other now. for each cb you could register a submit callback, with an appropiate priority to run before normal callbacks, to clear the value. it could even check for the cb name in the request params and only clear the value when the cb name is not found, and then it really doesn't do unnecessary value changes (if that is an issue at all). submit callbacks are arg-less lambdas rendered as hidden input fields. - attila (alias 101 on irc &no 'its not lisp code :) From attila.lendvai at gmail.com Fri Jun 16 10:15:49 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Fri, 16 Jun 2006 12:15:49 +0200 Subject: [Bese-devel] Re: component tree In-Reply-To: References: <448ADF4F.8000708@acd.net> Message-ID: > > problem, but it's somewhat unelegant. I think it would be a good idea to > > organize these callbacks under forms, and only call them when *their* form is > > submitted. This could be done with a dynamic variable that is bound with a let > > by an > The other problem was that it is impossible to register callbacks that allways > > get executed when a form is submitted, for input fields whose values do not > > correspond 1-to-1 with request parameters (checkbox, multiple select). I'm > > still planning to work on this, but my grasp on the action and frame concepts > > is still a little weak, so I can't really see what would be the best way to do > > this. > > yeah, this is an issue. attila is working on something like this in > the ucw_ajax branch. if that isn't enough, or if i'm misunderstanding > what attila is doing, then we should definetly think about how to do > this. submit callbacks are exactly for this... please look around in the ajax branch! (i feel like a marketing guy... :) - attila (alias 101 on irc &no 'its not lisp code :) From marijnh at gmail.com Fri Jun 16 10:44:07 2006 From: marijnh at gmail.com (Marijn Haverbeke) Date: Fri, 16 Jun 2006 12:44:07 +0200 Subject: [Bese-devel] Re: component tree In-Reply-To: References: <448ADF4F.8000708@acd.net> Message-ID: On 6/16/06, Attila Lendvai wrote: > > submit callbacks are exactly for this... please look around in the > ajax branch! (i feel like a marketing guy... :) Heh, I know. I'm just a little intimidated by that branch since I don't have a clue what changed and why, so where do I start looking around? Has anything at all been written about the approach that is being taken there, or can you maybe point me to useful posts in the mailing list archive? Thanks, Marijn -------------- next part -------------- An HTML attachment was scrubbed... URL: From mb at bese.it Fri Jun 16 11:22:16 2006 From: mb at bese.it (Marco Baringer) Date: Fri, 16 Jun 2006 13:22:16 +0200 Subject: [Bese-devel] Re: component tree References: <448ADF4F.8000708@acd.net> Message-ID: "Marijn Haverbeke" writes: > Heh, I know. I'm just a little intimidated by that branch since I don't have a > clue what changed and why, so where do I start looking around? Has anything at > all been written about the approach that is being taken there, or can you maybe > point me to useful posts in the mailing list archive? http://uncommon-web.com/darcsweb/darcsweb.cgi?r=ucw_ajax;a=summary that will let you see what's changed and when. you can browse the source as well (and get per-file annotations). -- -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 attila.lendvai at gmail.com Fri Jun 16 11:38:23 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Fri, 16 Jun 2006 13:38:23 +0200 Subject: [Bese-devel] Re: component tree In-Reply-To: References: <448ADF4F.8000708@acd.net> Message-ID: > Heh, I know. I'm just a little intimidated by that branch since I don't have > a clue what changed and why, so where do I start looking around? Has > anything at all been written about the approach that is being taken there, > or can you maybe point me to useful posts in the mailing list archive? hm, let's try to make one quickly... :) the ajax branch is the dev branch + some extras and some changes, and i keep them in sync. it's 99% compatible with the dev branch but backward compatibility was not the primary focus. the most important infrastructural changes happened around actions. actions are now structs (as opposed to simple lambdas) and this struct can store several details about the action (should it create a new frame? should it's body be wrapped in with-call/cc? should we call the render loop after it's finished? should we manage the response or the action does it itself, etc). to be able to define these details the action creation has been changed a little (action-href, make-new-action and friends), for details see use the source. callbacks were similarly refactored, they have priorities and dependencies now but they are a bit more internal then the actions. the <448E68D0.7000003@acd.net> Message-ID: <87u06lo04g.fsf@logxor.random-state.net> Marco Baringer writes: > (defaction foo ((a bar)) > ...) > > which is expanded into: > > (defmethod foo ((a bar)) > (with-call/cc ...)) > > when sbcl compiles that defmethod form it will macro expand the body > twice, the first time around the lexical environment (the &environment > object passed to macros) will be NIL and with-call/cc won't see the > binding of A, the second time around a complete environment object is > passed and the code works (in fact the generated compiled code is > correct since sbcl throws away with-call/cc's expansion on that first > expansion) . what happens on that first expansion is that with-call/cc > signals a warning, asdf, on sbcl, treats this a compile _error_ and > breaks. > > anybody with sbcl skilz able to suggest a solution? The first expansion comes from the PCL code walker that is responsible for all sorts of CLOS magic, and the second expansion comes from the actual compiler. As first approximation, I'd suggest STYLE-WARNING instead, or MUFFLE-WARNING to deal with the rogue warnings, or alternatively ASDF:*COMPILE-FILE-FAILURE-BEHAVIOUR* to make ASDF not grind to halt if COMPILE-FILE returns a tertiary value of true. As for actual solutions... well, obviously it would be good if the code-walker provided environments isometric similar to the ones generated by the compiler. Question: what kind of queries do you perform on the environment, and how? Do you dip into the internals, or do you use eg. SB-CLTL2? Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." From vanek at acd.net Fri Jun 16 14:23:52 2006 From: vanek at acd.net (Lou Vanek) Date: Fri, 16 Jun 2006 14:23:52 +0000 Subject: [Bese-devel] single-threaded ucw patches Message-ID: <4492BEF8.7010701@acd.net> If you are using single-threaded CL these patches will help integrate UCW. Enclosed in the attachment are 5 patches and sample startup scripts. The patches are for 5 directories: . ucw_dev . arnesi_dev . parenscript . yaclml . araneida-release If using the patch program, the patches will probably not install unless using the -l option. (Something like 'patch -Nlp0 < some.patch' should work.) These patches were specifically made for Clisp 2.38 but would probably be of use to anybody having a hard time getting the QUICKSTART hello.lisp program running, especially if using the araneida backend http server. Special thanks to Vlado for posting the swank fixes. Lou Vanek -- I wouldn't mind the rat race so much if it wasn't for all the damn cats. - David Steuber -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.tar.gz Type: application/x-gzip Size: 21405 bytes Desc: not available URL: From vanek at acd.net Fri Jun 16 14:47:33 2006 From: vanek at acd.net (Lou Vanek) Date: Fri, 16 Jun 2006 14:47:33 +0000 Subject: [Bese-devel] single-threaded ucw patches In-Reply-To: <4492BEF8.7010701@acd.net> References: <4492BEF8.7010701@acd.net> Message-ID: <4492C485.5050703@acd.net> forgot to include vlado's swank patch. see attachment. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch-swank.txt URL: From mb at bese.it Fri Jun 16 15:08:01 2006 From: mb at bese.it (Marco Baringer) Date: Fri, 16 Jun 2006 17:08:01 +0200 Subject: [Bese-devel] Re: compile-op error on backtracking.lisp References: <87ver6bwb3.fsf@localhost.localdomain> <448E68D0.7000003@acd.net> <87u06lo04g.fsf@logxor.random-state.net> Message-ID: Nikodemus Siivola writes: > Question: what kind of queries do you perform on the environment, and > how? Do you dip into the internals, or do you use eg. SB-CLTL2? we need a way to know all of the local variables and functions (we should grab symbol-macros and macrolets as well, but we don't atm). this is done using these snippets (arnesi/src/lexenv.lisp): #+sbcl (defmethod lexical-variables ((environment sb-kernel:lexenv)) (loop for var-spec in (sb-c::lexenv-vars environment) when (and (atom (cdr var-spec)) (not (and (typep (cdr var-spec) 'sb-c::lambda-var) (sb-c::lambda-var-ignorep (cdr var-spec))))) collect (car var-spec))) #+sbcl (defmethod lexical-functions ((environment sb-kernel:lexenv)) (mapcar #'first (sb-c::lexenv-funs environment))) i didn't know about sb-cltl2's existence, but it looks like that's missing the map-environment function. -- -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 vanek at acd.net Fri Jun 16 15:47:38 2006 From: vanek at acd.net (Lou Vanek) Date: Fri, 16 Jun 2006 15:47:38 +0000 Subject: [Bese-devel] Re: Is dynamic-forms-demo working in the latest box set? I get a `NIL' is not of the expected type `ARRAY' In-Reply-To: <87E5F673384DEC44A2604F7EC0735E420164820F@HQGTNEX2.doe.local> References: <87E5F673384DEC44A2604F7EC0735E420164820F@HQGTNEX2.doe.local> Message-ID: <4492D29A.4070200@acd.net> Popovich, Thomas wrote: > Hi Marco & Lou, > > Thanks again for your assistance. I?ve tried the demos and I think most > work except > > Dynamic Form demo which gives exception : `NIL' is not of the expected > type `ARRAY' when running the DynamicFormsDemo in allegro version 8 (on > windows). > > I get this when I click on the link to launch the demo; > > I made a flash movie so as to show and can send it to you, it is about 1 > Meg is size. Let me know if you want me to send it. > > Attached find the slime events showing the backtrace w/ a few frames > opened up: > > <> > > Have you guys seen this before? > > > > ------------------------------------------------------------------------ > > `NIL' is not of the expected type `ARRAY' > [Condition of type TYPE-ERROR] > > Restarts: > 0: [RETRY] Retry rendering the component #. > 1: [RETRY] Retry rendering the component #. > 2: [RETRY] Retry rendering the component #. > 3: [RETRY] Retry calling RENDER. > 4: [SERVER-ERROR] Send the client an internal server error page. > 5: [GENERATE-BACKTRACE-FOR-EMACS] Generate a bug report in Emacs. > 6: [FAIL-MISERABLY] Pretend this request never happend and fail. > 7: [TRY-AGAIN] Play this request over from the top. > 8: [ABORT] Abort entirely from this (lisp) process. > > Backtrace: > 0: (SWANK::DEBUG-IN-EMACS #) > 1: ((:INTERNAL SWANK:SWANK-DEBUGGER-HOOK 0)) > 2: ((METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T T)) # #) > 3: ((:INTERNAL SWANK::CALL-WITH-CONNECTION 0)) > 4: (SWANK::CALL-WITH-REDIRECTED-IO # #) > 5: (SWANK::MAYBE-CALL-WITH-IO-REDIRECTION # #) > 6: (SWANK::CALL-WITH-CONNECTION # #) > 7: (SWANK:SWANK-DEBUGGER-HOOK # NIL) > 8: ((:INTERNAL (METHOD IT.BESE.UCW::HANDLE-REQUEST (IT.BESE.UCW:STANDARD-SERVER IT.BESE.UCW:REQUEST IT.BESE.UCW:RESPONSE)) 4) #) > 9: (SIGNAL #) > 10: (ERROR TYPE-ERROR :DATUM NIL :EXPECTED-TYPE ARRAY :FORMAT-CONTROL "~@<`~s' is not of the expected type `~s'~:@>" :FORMAT-ARGUMENTS (NIL ARRAY)) > 11: (ADJUST-ARRAY NIL 1) > Locals: > ARRAY = NIL Program is dying on line 565 of form.lisp: (adjust-array +string-index-cache+ (1+ i)) +string-index-cache+ is null, for some reason. Works in Clisp. Allegro 8 is probably unable to process the following sexp and create the array: (defvar +string-index-cache+ (map-into (make-array 50 :element-type 'string :adjustable t) (let ((i -1)) (lambda () (princ-to-string (incf i)))))) You may want to try eval'ing this manually just to see if you get an error message or warning from allegro. Lou Vanek -- Google's corporate motto is "Don't Be Evil". Microsoft's is only slightly different: "Be Evil". From vanek at acd.net Fri Jun 16 17:28:10 2006 From: vanek at acd.net (Lou Vanek) Date: Fri, 16 Jun 2006 17:28:10 +0000 Subject: [Bese-devel] Re: Is dynamic-forms-demo working in the latest box set? I get a `NIL' is not of the expected type `ARRAY' In-Reply-To: <87E5F673384DEC44A2604F7EC0735E4201648213@HQGTNEX2.doe.local> References: <87E5F673384DEC44A2604F7EC0735E4201648213@HQGTNEX2.doe.local> Message-ID: <4492EA2A.1090107@acd.net> Popovich, Thomas wrote: > Hi Lou, > > Thanks again. > > Can you somehow "remove the "bese-devel" from the to list" as I usually > post from a gmail address ... and we can not access gmail from work. > (so it's a 2 step process write a msg go home.. and post it) When I remember, I like to post to both the personal acct and the dev list so that others may keep track and possibly benefit from similar experiences. If not for now, but for the future, so similar questions don't have to be repeated. Since this letter is going to two mailboxes I would think you can simply ignore the bese-devel ML, can't you? I'm pretty think when it comes to how Big Gov does things, but I'd like to continue to be polite and keep bese-devel cc'ed unless this is privileged conversation, which I have no reason to believe this is. > > PS: > > How did you narrow it down to that stmt? Like you, I did a grep, and there is only one line that has adjust-array in it. I have vim set up so that I can do this very quickly. This is one reason why I am suspicious of locking myself into any proprietory IDE. > Frame: > > 11: (ADJUST-ARRAY NIL 1) > > > is seemingly bad looking. I'm new at debugging tracebacks in Lisp - the > traceback should have linenumber and filename (if you compiled the file > from a file... that would be nice) Anyway the traceback seems to lack > that info. To be clear, I am just an innocent bystander. Marco is the one who wrote, owns, and maintains UCW. I just happened by and noticed something cool, so I stopped and tried to get UCW to work with Clisp. RoR is nice if you can live w/in it's capabilites envelope, but I think I found something a little better. Still not sure. ActiveRecord still beats the crap out of anything I've been able to get to work with Clisp, but I may be able to get Drew's postgresql module to work and that would be almost as good. That said, coming from a C/C++ background I, too, am a little surprised there aren't linenumbers/filenames, but the CL programming environment (I am slowly understanding) is different: code tends to evolve via Lisp programming sessions where the same expression may be re-evaluated over and over by hand instead of running make. Good CLs will be able to show you the entire form in each frame so there is little to no ambiguity as to what is going on, so line numbers are of little consequence. Alas, however, I'm using Clisp, and things aren't so nice. Or I haven't found the magic button yet that is able to unknot all these compiled functions. Yes, I'm sorta new to Lisp myself and had a terrible time acclimating to these dense tracebacks, especially since Clisp compiles most of the information away and I haven't been able to figure out how to get at most of it, even when I think I'm doing something bright with "declaim". What I do is look for the frame that initially signals the error and then scrutinize 3 or 4 frames directly "above" in the stack. I noticed that frame 10 is where the error was initially raised, so frames 11,12,13, and 14 would probably tell me what caused it. Looking at frame 11 showed an array method with possibly a null "pointer," so to speak (my C background is showing). Anyway, that's bad. So looking at frames 12 - 14 I noticed that the functions that were successively called were: ... ((METHOD IT.BESE.UCW:RENDER (IT.BESE.UCW:SELECT-FIELD)) ((METHOD IT.BESE.UCW::BUILD-DATA-MAP (IT.BESE.UCW:SELECT-FIELD)) (IT.BESE.UCW::INTEGER-TO-STRING 0) (ADJUST-ARRAY NIL 1) BOOM I noticed that build-data-map is defined only 5 times, all in the same file. (Again, egrep quickly showed this and vim readily displayed all matches at once.) Since the backtrace said 'build-data-map' was called with a SELECT-FIELD argument that narrowed the search down to just one defmethod. Sure enough, there is an 'integer-to-string' function called in this build-data-map method, so I looked for where integer-to-string is defined (if you're using vim and ctags it's "g C-]") and there is the 'adjust-array' statement. To make sure I was looking at this right I double-checked the Lisp Hyperspec and looked up adjust-array, and, yes, the first argument to adjust-array is supposed to be an array object. Slime would probably have told me the same thing faster. > e.g. > more frames: > 11: (ADJUST-ARRAY NIL 1) > 12: (IT.BESE.UCW::INTEGER-TO-STRING 0) > 13: ((METHOD IT.BESE.UCW::BUILD-DATA-MAP (IT.BESE.UCW:SELECT-FIELD)) > #) > > I usually get the fnct name and grep the source. > Do you have a pointers to how to more "effectively" get to the line of > the problem. I suspect that you can train SLIME to teach emacs code > locations but I have not explored that yet. I debug using both vim and emacs/slime. Clisp doesn't give very good info in slime so I usually use emacs just to do evaluations, but use vim to quickly jump around in the code and look for things. It's a bizarre arrangement but it works for me because I have vim tricked out the way I like with a bunch of syntax files, plugins, macros, function key mappings, etc. It's mostly boils down to integrating egrep and ctags into vim and mapping the most commonly used routines to just a few keystrokes. I'm sure the same can be done in emacs. I used to be an emacs snob but I let most of my emacs knowledge atrophy once I found vim to be more productive, at least on non-lisp projects. Lou Vanek -- "My name is Ozymandias, King of Kings: Look upon my works, ye Mighty, and despair!" From vanek at acd.net Fri Jun 16 18:17:22 2006 From: vanek at acd.net (Lou Vanek) Date: Fri, 16 Jun 2006 18:17:22 +0000 Subject: [Bese-devel] Re: Is dynamic-forms-demo working in the latest box set? I get a `NIL' is not of the expected type `ARRAY' In-Reply-To: <87E5F673384DEC44A2604F7EC0735E4201648217@HQGTNEX2.doe.local> References: <87E5F673384DEC44A2604F7EC0735E4201648217@HQGTNEX2.doe.local> Message-ID: <4492F5B2.6080304@acd.net> I downloaded a copy of Allegro 8 express and ran this in a little window and +string-index-cache+ evaluated properly: (defvar +string-index-cache+ (make-array 50 :element-type 'string :adjustable t)) (map-into +string-index-cache+ (let ((i -1)) (lambda () (princ-to-string (incf i))))) I think the "modern" option is set but I don't think that makes a difference. Anyway, I think this change fixes it. -lv Popovich, Thomas wrote: > I then hacked it further > First to eval the following live: (to get the string-index-cache > but when running it it fails - I'm debugging that. > First thing that I'm researching is why when I Eval (type-of > IT.BESE.UCW::+STRING-INDEX-CACHE+) it says FIXNUM. (sparked by the > trace back) > > > == my eval code == > (progn > > (in-package :it.bese.ucw) > (defvar +string-index-cache+ > (map-into (make-array 50 > :element-type 'string > :adjustable t) > (let ((i -1)) > (lambda () > (princ-to-string (incf i)))))) > ) > > > Then ... > It dumps even before getting to the spot where I inserted the (break) . > > Error dump: shows bad datatype > > 11: (COND ((<= (LENGTH IT.BESE.UCW::+STRING-INDEX-CACHE+) > IT.BESE.UCW::I) (IT.BESE.UCW::TJP-ADJUST-ARRAY-BREAK (1+ > IT.BESE.UCW::I)) (SETF (AREF IT.BESE.UCW::+STRING-INDEX-CACHE+ > IT.BESE.UCW::I) (PRINC-TO-STRING IT.BESE.UCW::I))) ((NULL (AREF > IT.BESE.UCW::+STRING-INDEX-CACHE+ IT.BESE.UCW::I)) (SETF (AREF > IT.BESE.UCW::+STRING-INDEX-CACHE+ IT.BESE.UCW::I) (PRINC-TO-STRING > IT.BESE.UCW::I))) (T (AREF IT.BESE.UCW::+STRING-INDEX-CACHE+ > IT.BESE.UCW::I))) > Locals: > EXCL::X = (((<= (LENGTH IT.BESE.UCW::+STRING-INDEX-CACHE+) > IT.BESE.UCW::I) (IT.BESE.UCW::TJP-ADJUST-ARRAY-BREAK (1+ > IT.BESE.UCW::I)) (SETF (AREF IT.BESE.UCW::+STRING-INDEX-CACHE+ > IT.BESE.UCW::I) (PRINC-TO-STRING IT.BESE.UCW::I))) ((NULL (AREF > IT.BESE.UCW::+STRING-INDEX-CACHE+ IT.BESE.UCW::I)) (SETF (AREF > IT.BESE.UCW::+STRING-INDEX-CACHE+ IT.BESE.UCW::I) (PRINC-TO-STRING > IT.BESE.UCW::I))) (T (AREF IT.BESE.UCW::+STRING-INDEX-CACHE+ > IT.BESE.UCW::I))) > IT.BESE.UCW::I = 0 > EXCL::LOCAL-0 = (((<= (LENGTH IT.BESE.UCW::+STRING-INDEX-CACHE+) > IT.BESE.UCW::I) (IT.BESE.UCW::TJP-ADJUST-ARRAY-BREAK (1+ > IT.BESE.UCW::I)) (SETF (AREF IT.BESE.UCW::+STRING-INDEX-CACHE+ > IT.BESE.UCW::I) (PRINC-TO-STRING IT.BESE.UCW::I))) ((NULL (AREF > IT.BESE.UCW::+STRING-INDEX-CACHE+ IT.BESE.UCW::I)) (SETF (AREF > IT.BESE.UCW::+STRING-INDEX-CACHE+ IT.BESE.UCW::I) (PRINC-TO-STRING > IT.BESE.UCW::I))) (T (AREF IT.BESE.UCW::+STRING-INDEX-CACHE+ > IT.BESE.UCW::I))) > EXCL::LOCAL-1 = COND > 12: (IT.BESE.UCW::INTEGER-TO-STRING 0) > > > > -----Original Message----- > From: Popovich, Thomas > Sent: Friday, June 16, 2006 1:35 PM > To: 'Lou Vanek' > Subject: RE: Is dynamic-forms-demo working in the latest box set? I get > a `NIL' is not of the expected type `ARRAY' > > > [maybe u can just bcc me and change the email addr to > tpop.news at gmail.com] > > I was typing this up when your other email came. > > === > > I hacked the code to allow debugging as shown below. > === > > Your hunch was right. > > As you will see below I hacked it to add a few debug fncts: > > > then in emacs I can do this handy inspect trick: > go to the proper SLDB frame and eval an expression( emacs will prompt > me ... then I've use electric command history to get the thing to reuse > it quicker) > > here it is: > (sldb-eval-in-frame "IT.BESE.UCW:: +string-index-cache+ ") > > > Looking at the call stack I see: > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; > 8: (BREAK) > 9: (IT.BESE.UCW::TJP-ADJUST-ARRAY-BREAK=LEVEL-2 1 # COMMON-LISP-USER package> NIL) > Locals: > IT.BESE.UCW::I = 1 > IT.BESE.UCW::P = # > IT.BESE.UCW::TC = NIL > 10: (LET* ((IT.BESE.UCW::PKG *PACKAGE*) (IT.BESE.UCW::TC > (IT.BESE.UCW::TJP-GET-+STRING-INDEX-CACHE+))) > (IT.BESE.UCW::TJP-ADJUST-ARRAY-BREAK=LEVEL-2 IT.BESE.UCW::I > IT.BESE.UCW::PKG IT.BESE.UCW::TC) (ADJUST-ARRAY > IT.BESE.UCW::+STRING-INDEX-CACHE+ (1+ IT.BESE.UCW::I))) > 11: (IT.BESE.UCW::TJP-ADJUST-ARRAY-BREAK 1) > Locals: > IT.BESE.UCW::I = 1 > 12: (IT.BESE.UCW::INTEGER-TO-STRING 0) > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; > > > I doubt that the P var above = # (copy of > *package*) > Is a problem right? > > > > (progn > > (in-package :it.bese.ucw) ;; hack to enable us to eval this at end of > progn when *package* is globally some other package > > > > (defun tjp-adjust-array-break=level-2 (i p tc) ;; just 3 locals to use > as watch points > (break) > ) > > > (defun tjp-adjust-array-break (i) > (let* (( pkg *package*) > ( tc (tjp-get-+string-index-cache+))) > > (tjp-adjust-array-break=level-2 i pkg tc) > > (adjust-array +string-index-cache+ (1+ i))) > ) > > ; this did sldb break cmd did not work. > ;(sldb-break #'tjp-adjust-array-break) > > > (defun integer-to-string (i) > (cond > ((<= (length +string-index-cache+) i) > (tjp-adjust-array-break (1+ i)) > ;;(adjust-array +string-index-cache+ (1+ i)) ;; above line is > used so we can break -- it does the same thing as this commented out > line > (setf (aref +string-index-cache+ i) (princ-to-string i))) > ((null (aref +string-index-cache+ i)) > (setf (aref +string-index-cache+ i) (princ-to-string i))) > (t > (aref +string-index-cache+ i)))) > ) > > > > > From marijnh at gmail.com Fri Jun 16 18:58:54 2006 From: marijnh at gmail.com (Marijn Haverbeke) Date: Fri, 16 Jun 2006 20:58:54 +0200 Subject: [Bese-devel] Why dojo? Message-ID: I guess Dojo is a nice library, but it seems UCW only uses a bunch of generic utility functions from it - dojo.js is 138k, and most of it is of no use for the things UCW is doing. Maybe composing a subset of it and distributing that with UCW would be an idea? (I know the size of a static JS file isn't going to cause *too* many bandwith problems, but I'm imaging the thing also bloats up the javascript interpreter, and in the end I'm just a terrible minimalist.) Marijn -------------- next part -------------- An HTML attachment was scrubbed... URL: From vanek at acd.net Fri Jun 16 19:18:57 2006 From: vanek at acd.net (Lou Vanek) Date: Fri, 16 Jun 2006 19:18:57 +0000 Subject: [Bese-devel] Why dojo? In-Reply-To: References: Message-ID: <44930421.8000703@acd.net> I've noticed IE6 and FF1.5 are both intelligent enough to make the dojo download only once because the file's expiration date is being honored. Opera, on the other hand, is downloading it. On. Every. Single. Request. Which means either I have to 1) discard Opera altogether, or 2) find an Opera work-around. Don't know about safari. Don't care about any other browsers (except for IE7). A minimal dojo sounds like a good idea if the functions aren't being used. (Actually, I would prefer prototype and scriptaculous since they seem to be developing quicker, but I'm not going to press the point.) -lv Marijn Haverbeke wrote: > I guess Dojo is a nice library, but it seems UCW only uses a bunch of > generic utility functions from it - dojo.js is 138k, and most of it is > of no use for the things UCW is doing. Maybe composing a subset of it > and distributing that with UCW would be an idea? > > (I know the size of a static JS file isn't going to cause *too* many > bandwith problems, but I'm imaging the thing also bloats up the > javascript interpreter, and in the end I'm just a terrible minimalist.) > > > Marijn > > > ------------------------------------------------------------------------ > > _______________________________________________ > bese-devel mailing list > bese-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel From nikodemus at random-state.net Fri Jun 16 21:32:12 2006 From: nikodemus at random-state.net (Nikodemus Siivola) Date: Sat, 17 Jun 2006 00:32:12 +0300 Subject: [Bese-devel] Re: compile-op error on backtracking.lisp References: <87ver6bwb3.fsf@localhost.localdomain> <448E68D0.7000003@acd.net> <87u06lo04g.fsf@logxor.random-state.net> Message-ID: <878xnwdbxf.fsf@logxor.random-state.net> Marco Baringer writes: > we need a way to know all of the local variables and functions (we > should grab symbol-macros and macrolets as well, but we don't > atm). this is done using these snippets (arnesi/src/lexenv.lisp): Right. Taking a slightly better look at the PCL walker, it seems to ignore variables totally -- since they don't matter for the stuff it is doing. How painfull are the workarounds I suggested? (While getting the PCL code-walker to add variable information to environments doesn't seem horribly hard, it seems fiddly enough that unless something makes it rather urgent, I doubt I'll get to it very soon.) Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." From cjstuij at gmail.com Fri Jun 16 22:26:32 2006 From: cjstuij at gmail.com (Ties Stuij) Date: Sat, 17 Jun 2006 00:26:32 +0200 Subject: [Bese-devel] Why dojo? In-Reply-To: References: Message-ID: On 6/16/06, Marijn Haverbeke wrote: > I guess Dojo is a nice library, but it seems UCW only uses a bunch of > generic utility functions from it - dojo.js is 138k, and most of it is of no > use for the things UCW is doing. Maybe composing a subset of it and > distributing that with UCW would be an idea? Well actually dojo itself comes in a range of flavors from basic to redicilously boated. Maybe you should check out the dojo website before you start tinkering yourself. Just a few bits of time back I just dumped the redicilously bloaded over the basic version in ucw because: 1) the forms validation code needed dojo functions that wasn't covered by the basic stuff and i was to lazy to check out which package would cover it without adding unnesicary (this is not spelt right) stuff. 2) i figured that while you're developing, why constrain yourself. Use what you need and trim in a production environment. If you know how dojo cuts the meat of it's functionality, this shouldn't be to much of a problem. And why dojo? It seems to be quite modular, practical to me. Don't know about how others feel about it. But if you want to use someting else, there is hardly any dojo interwoven into standard ucw i thought. Or don't use javascript at all. The ajax branch might be more demanding though. ps. i see that since 0.3 the dojo profiles are a bit more muffled away than they used to be. Still they're to be found on the front page. After a quick check it seems that the browser io package for example sets you back 60 k in stead of 129 k which is the current size of the ajax version, which is the version included in ucw. That is to say not the version number but the kind of dojo. You still there? Ah well... Greets, Ties From vanek at acd.net Fri Jun 16 23:17:44 2006 From: vanek at acd.net (Lou Vanek) Date: Fri, 16 Jun 2006 23:17:44 +0000 Subject: [Bese-devel] single-threaded ucw patches In-Reply-To: <4492BEF8.7010701@acd.net> References: <4492BEF8.7010701@acd.net> Message-ID: <44933C18.4070509@acd.net> and this patch fixes an IE date header problem. -------------- next part -------------- A non-text attachment was scrubbed... Name: b2.patch.gz Type: application/x-gzip Size: 593 bytes Desc: not available URL: From maciekp at japhy.fnord.org Sat Jun 17 13:51:26 2006 From: maciekp at japhy.fnord.org (Maciek Pasternacki) Date: Sat, 17 Jun 2006 15:51:26 +0200 Subject: [Bese-devel] single-threaded ucw patches In-Reply-To: <44933C18.4070509@acd.net> (Lou Vanek's message of "Fri, 16 Jun 2006 23:17:44 +0000") References: <4492BEF8.7010701@acd.net> <44933C18.4070509@acd.net> Message-ID: <871wtn3n6p.fsf@lizard.king> On Pungenday, Confusion 22, 3172 YOLD, Lou Vanek wrote: > and this patch fixes an IE date header problem. Applied to ucw_dev. I leave clisp/araneida patch to Marco or someone else who would be able to test it. -- __ Maciek Pasternacki [ http://japhy.fnord.org/ ] `| _ |_\ / { Any sufficently complicated Java program requires ,|{-}|}| }\/ a programmable IDE to make up for the half of Common Lisp \/ |____/ not implemented in the program itself. } ( Peter Seibel ) -><- From albertosantini at gmail.com Sat Jun 17 16:22:24 2006 From: albertosantini at gmail.com (Alberto Santini) Date: Sat, 17 Jun 2006 18:22:24 +0200 Subject: [Bese-devel] single-threaded ucw patches In-Reply-To: <871wtn3n6p.fsf@lizard.king> References: <4492BEF8.7010701@acd.net> <44933C18.4070509@acd.net> <871wtn3n6p.fsf@lizard.king> Message-ID: <6a066ca20606170922k2c1f957dm66faa1794b91b374@mail.gmail.com> Hello. Using openmcl (1.0/ppc) src/backend/common.lisp doesn't compile. I added 'if-modified-value' in with-unique-name to fix it. ... (macrolet ((defserve ((name args &key last-modified expires content-length) &body body) (with-unique-names (last-modified-value expires-value content-length-value if-modified-value) ... Regards, Alberto On 6/17/06, Maciek Pasternacki wrote: > On Pungenday, Confusion 22, 3172 YOLD, Lou Vanek wrote: > > > and this patch fixes an IE date header problem. > > Applied to ucw_dev. I leave clisp/araneida patch to Marco or someone > else who would be able to test it. From maciekp at japhy.fnord.org Sat Jun 17 17:37:08 2006 From: maciekp at japhy.fnord.org (Maciek Pasternacki) Date: Sat, 17 Jun 2006 19:37:08 +0200 Subject: [Bese-devel] single-threaded ucw patches In-Reply-To: <6a066ca20606170922k2c1f957dm66faa1794b91b374@mail.gmail.com> (Alberto Santini's message of "Sat, 17 Jun 2006 18:22:24 +0200") References: <4492BEF8.7010701@acd.net> <44933C18.4070509@acd.net> <871wtn3n6p.fsf@lizard.king> <6a066ca20606170922k2c1f957dm66faa1794b91b374@mail.gmail.com> Message-ID: <87u06j1y63.fsf@lizard.king> On Pungenday, Confusion 22, 3172 YOLD, Alberto Santini wrote: > Using openmcl (1.0/ppc) src/backend/common.lisp doesn't compile. > I added 'if-modified-value' in with-unique-name to fix it. > ... > (macrolet ((defserve ((name args &key last-modified expires > content-length) &body body) > (with-unique-names (last-modified-value expires-value > content-length-value if-modified-value) > ... Oops, sorry, my fault. Applied in ucw_dev. -- __ Maciek Pasternacki [ http://japhy.fnord.org/ ] `| _ |_\ / { ...I choose to live and to lie, kill and give and to ,|{-}|}| }\/ die, learn and love and to do what it takes to step through... } \/ |____/ ( M. J. Keenan ) -><- From attila.lendvai at gmail.com Sat Jun 17 18:20:35 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Sat, 17 Jun 2006 20:20:35 +0200 Subject: [Bese-devel] l10n changes Message-ID: hi! the l10n stuff in ucw has been revised. now working hand in hand with cl-l10n ucw sets the locale according to the setting in the user's browser. this possible list of locales is tried by the template resolver to find the most preferred language of the given page. i'll add some i18n examples eventually that are not tal based. cl-l10n has stuff like locale specific plural-of, etc. subscribe to cl-l10n-devel and get your hands dirty with implement stuff for your mother tongue. i'm working on english and hungarian. an issue left: encoding is screwed up while templates are processed. i've fixed their encoding to utf-8 while loading (not too flexible but still better then the previous ascii) but the rendered page is bugous. the response heder is wrong, and probably the actul data encoding, too. Marco? - attila (alias 101 on irc &no 'its not lisp code :) From pupeno at pupeno.com Sun Jun 18 07:27:28 2006 From: pupeno at pupeno.com (Pupeno) Date: Sun, 18 Jun 2006 09:27:28 +0200 Subject: [Bese-devel] Getting ucw_box to work Message-ID: <1150615648.24727.12.camel@ulab.pupeno.com> Hello, I am trying to get ucw to work, so I tried loading lisp.start (from slime) to find this error: The name "IT.BESE.UCW-USER" does not designate any package. [Condition of type SB-KERNEL:SIMPLE-PACKAGE-ERROR] Restarts: 0: [ABORT] Abort SLIME compilation. 1: [ABORT-REQUEST] Abort handling SLIME request. 2: [TERMINATE-THREAD] Terminate this thread (#) So, I went form by form in that file until (asdf:oos 'asdf:load-op :ucw) which eventually hungs. I am running it again and let it run for a long time. Any obvious mistake that I am making ? Thank you. -- Pupeno http://pupeno.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From vanek at acd.net Sun Jun 18 12:36:18 2006 From: vanek at acd.net (Lou Vanek) Date: Sun, 18 Jun 2006 12:36:18 +0000 Subject: [Bese-devel] Re: Getting ucw_box to work In-Reply-To: <1150615648.24727.12.camel@ulab.pupeno.com> References: <1150615648.24727.12.camel@ulab.pupeno.com> Message-ID: <449548C2.50402@acd.net> Pupeno wrote: > Hello, > I am trying to get ucw to work, so I tried loading lisp.start (from > slime) to find this error: > > The name "IT.BESE.UCW-USER" does not designate any package. > [Condition of type SB-KERNEL:SIMPLE-PACKAGE-ERROR] > > Restarts: > 0: [ABORT] Abort SLIME compilation. > 1: [ABORT-REQUEST] Abort handling SLIME request. > 2: [TERMINATE-THREAD] Terminate this thread (# "worker" {B06D469}>) > > So, I went form by form in that file until > > (asdf:oos 'asdf:load-op :ucw) > > which eventually hungs. I am running it again and let it run for a long > time. > > Any obvious mistake that I am making ? > > Thank you. > Pupeno, You don't mention which version of Lisp or OS you are using, but I'm guessing Clisp on Windows. (Lisp in a box?) If you are on Windows you will have a harder time getting things to work. You have an asdf problem. You either don't have links defined that reference the ucw.asd file or asdf hasn't been set up to look in the right directory for these links. Here are a couple of references that may help you trouble-shoot the adsf problem: http://www.cliki.net/LispBox http://constantly.at/lisp/asdf/ Not only must you tell asdf where your central repository (of .asd links) is, but there should be links back to all your .asd files located in this central repository. Asdf was looking for your ucw.asd file when it errored out. That said, CLisp support in UCW is a bit spotty and you will have problems even if you get your asdf problem fixed (if using Clisp). There are a number of patches to UCW so that Clisp can work, however. They were posted (by me) on this ML two days ago. If you are feeling adventurous you could try patching your version of UCW (if using CLisp) and look at the sample startup files supplied in the attachments. Once you call (asdf:oos 'asdf:load-op :ucw) asdf makes a note of the event so that when you try to call it again asdf (usually) just returns immediately because it thinks it has already loaded the package. So if asdf is hanging its an indication that asdf may have to be updated. You can find the latest version (it's only one file) here: http://cclan.cvs.sourceforge.net/cclan/asdf/ There is also a cclan mailing list that answers asdf-related questions: http://dir.gmane.org/gmane.lisp.cclan.general Lou Vanek -- We know what we are, but know not what we may be. Shakespeare From pupeno at pupeno.com Sun Jun 18 12:54:32 2006 From: pupeno at pupeno.com (Pupeno) Date: Sun, 18 Jun 2006 14:54:32 +0200 Subject: [Bese-devel] Re: Getting ucw_box to work In-Reply-To: <449548C2.50402@acd.net> References: <1150615648.24727.12.camel@ulab.pupeno.com> <449548C2.50402@acd.net> Message-ID: <1150635272.24727.91.camel@ulab.pupeno.com> On Sun, 2006-06-18 at 12:36 +0000, Lou Vanek wrote: > Pupeno wrote: > > > Hello, > > I am trying to get ucw to work, so I tried loading lisp.start (from > > slime) to find this error: > > > > The name "IT.BESE.UCW-USER" does not designate any package. > > [Condition of type SB-KERNEL:SIMPLE-PACKAGE-ERROR] > > > > Restarts: > > 0: [ABORT] Abort SLIME compilation. > > 1: [ABORT-REQUEST] Abort handling SLIME request. > > 2: [TERMINATE-THREAD] Terminate this thread (# > "worker" {B06D469}>) > > > > So, I went form by form in that file until > > > > (asdf:oos 'asdf:load-op :ucw) > > > > which eventually hungs. I am running it again and let it run for a long > > time. > > > > Any obvious mistake that I am making ? > > > > Thank you. > > > > Pupeno, > > You don't mention which version of Lisp or OS you are using, but I'm guessing > Clisp on Windows. (Lisp in a box?) If you are on Windows you will have a harder > time getting things to work. I am running SBCL on Ubuntu (Linux). Actually, I am using packages that I made myself taking the Debian Sarge sources (they are more up to date). I have asdf set up more or less correctly I believe. I dig into the problem until I've found there was a problem loading swank, I have slime installed on my system (by Debian packages) and neither that nor the one in the box work. I believe it is a kind of threading problem. Furthermore, since I am running this from Slime, isn't swank already loaded ? I opened start.lisp and tried out the forms by hand: CL-USER> (load (make-pathname :name "load-asdf" :type "lisp" :defaults *load-truename*)) T That went ok. Then I should load ucw, so I took a look at ucw.asd to load the packages it depended on by hand, so: CL-USER> (asdf:oos 'asdf:load-op :arnesi) ... some warnings ... NIL CL-USER> (asdf:oos 'asdf:load-op :yaclml) NIL And now long list of warnings: CL-USER> (asdf:oos 'asdf:load-op :swank) ; loading system definition from ; /home/pupeno/Software/hosting-compass/ucw-boxset/systems/swank.asd into ; # ; registering # as SWANK STYLE-WARNING: redefining LISP-VERSION-STRING in DEFUN STYLE-WARNING: redefining UNIQUE-DIRECTORY-NAME in DEFUN STYLE-WARNING: redefining FILE-NEWER-P in DEFUN STYLE-WARNING: redefining SLIME-VERSION-STRING in DEFUN STYLE-WARNING: redefining DEFAULT-FASL-DIRECTORY in DEFUN STYLE-WARNING: redefining BINARY-PATHNAME in DEFUN STYLE-WARNING: redefining COMPILE-FILES-IF-NEEDED-SERIALLY in DEFUN STYLE-WARNING: redefining LOAD-USER-INIT-FILE in DEFUN STYLE-WARNING: redefining LOAD-SITE-INIT-FILE in DEFUN STYLE-WARNING: redefining SWANK-SOURCE-FILES in DEFUN STYLE-WARNING: redefining LOAD-SWANK in DEFUN ;; loading #P"/home/pupeno/.slime/fasl/sbcl-0.9.13-linux-x86/swank-backend.fasl" WARNING: SWANK-BACKEND also exports the following symbols: (SWANK-BACKEND:MAKE-WEAK-VALUE-HASH-TABLE SWANK-BACKEND:FRAME-CATCH-TAGS SWANK-BACKEND:ADD-SIGIO-HANDLER SWANK-BACKEND:FORMAT-SLDB-CONDITION SWANK-BACKEND:PROFILE-PACKAGE SWANK-BACKEND:RESTART-FRAME SWANK-BACKEND:DEFAULT-DIRECTORY SWANK-BACKEND:MAKE-RECURSIVE-LOCK SWANK-BACKEND:FRAME-SOURCE-LOCATION-FOR-EMACS SWANK-BACKEND:MAKE-WEAK-KEY-HASH-TABLE SWANK-BACKEND:COMPUTE-BACKTRACE SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK SWANK-BACKEND:INITIALIZE-MULTIPROCESSING SWANK-BACKEND:LIST-CALLEES SWANK-BACKEND:RECEIVE SWANK-BACKEND:COMPILER-MACROEXPAND-1 SWANK-BACKEND:REMOVE-SIGIO-HANDLERS SWANK-BACKEND:ACCEPT-CONNECTION SWANK-BACKEND:THREAD-NAME SWANK-BACKEND:CALL-WITH-RECURSIVE-LOCK-HELD SWANK-BACKEND:UNPROFILE SWANK-BACKEND:TOGGLE-TRACE SWANK-BACKEND:THREAD-ALIVE-P SWANK-BACKEND:SET-STREAM-TIMEOUT SWANK-BACKEND:CLOSE-SOCKET SWANK-BACKEND:DESCRIBE-SYMBOL-FOR-EMACS SWANK-BACKEND:SPAWN SWANK-BACKEND:MAKE-DEFAULT-INSPECTOR SWANK-BACKEND:SLDB-BREAK-AT-START SWANK-BACKEND:FIND-DEFINITIONS SWANK-BACKEND:WHO-SPECIALIZES SWANK-BACKEND:THREAD-STATUS SWANK-BACKEND:CONDITION-EXTRAS SWANK-BACKEND:FUNCTION-NAME SWANK-BACKEND:OPERATE-ON-SYSTEM SWANK-BACKEND:UNPROFILE-ALL SWANK-BACKEND:EVAL-IN-FRAME SWANK-BACKEND:FIND-THREAD SWANK-BACKEND:SLDB-BREAK-ON-RETURN SWANK-BACKEND:WHO-REFERENCES SWANK-BACKEND:LOCAL-PORT SWANK-BACKEND:CALL-WITH-DEBUGGING-ENVIRONMENT SWANK-BACKEND:PROFILED-FUNCTIONS SWANK-BACKEND:SEND SWANK-BACKEND:CALL-WITH-SYNTAX-HOOKS SWANK-BACKEND:EMACS-CONNECTED SWANK-BACKEND:WHO-BINDS SWANK-BACKEND:MAKE-LOCK SWANK-BACKEND:CREATE-SOCKET SWANK-BACKEND:BUFFER-FIRST-CHANGE SWANK-BACKEND:SET-DEFAULT-DIRECTORY SWANK-BACKEND:PROFILE-RESET SWANK-BACKEND:FRAME-VAR-VALUE SWANK-BACKEND:MACROEXPAND-ALL SWANK-BACKEND:CURRENT-THREAD SWANK-BACKEND:STARTUP-IDLE-AND-TOP-LEVEL-LOOPS SWANK-BACKEND:ACTIVATE-STEPPING SWANK-BACKEND:DISASSEMBLE-FRAME SWANK-BACKEND:SWANK-COMPILE-FILE SWANK-BACKEND:PROFILE-REPORT SWANK-BACKEND:CALL-WITH-LOCK-HELD SWANK-BACKEND:FRAME-LOCALS SWANK-BACKEND:ALL-THREADS SWANK-BACKEND:DESCRIBE-DEFINITION SWANK-BACKEND:WHO-SETS SWANK-BACKEND:CALL-WITH-COMPILATION-HOOKS SWANK-BACKEND:REMOVE-FD-HANDLERS SWANK-BACKEND:LISP-IMPLEMENTATION-TYPE-NAME SWANK-BACKEND:ARGLIST SWANK-BACKEND:RETURN-FROM-FRAME SWANK-BACKEND:LIST-CALLERS SWANK-BACKEND:PREFERRED-COMMUNICATION-STYLE SWANK-BACKEND:ADD-FD-HANDLER SWANK-BACKEND:KILL-THREAD SWANK-BACKEND:CALL-WITHOUT-INTERRUPTS SWANK-BACKEND:COMPILER-MACROEXPAND SWANK-BACKEND:CONDITION-REFERENCES SWANK-BACKEND:THREAD-ID SWANK-BACKEND:MAKE-FN-STREAMS SWANK-BACKEND:PRINT-FRAME SWANK-BACKEND:GETPID SWANK-BACKEND:DESCRIBE-PRIMITIVE-TYPE SWANK-BACKEND:PROFILE SWANK-BACKEND:SWANK-COMPILE-STRING SWANK-BACKEND:MAKE-STREAM-INTERACTIVE SWANK-BACKEND:DEFAULT-READTABLE-ALIST SWANK-BACKEND:WHO-CALLS SWANK-BACKEND:INTERRUPT-THREAD SWANK-BACKEND:INSTALL-DEBUGGER-GLOBALLY SWANK-BACKEND:WHO-MACROEXPANDS SWANK-BACKEND:CALLS-WHO) See also: The ANSI Standard, Macro DEFPACKAGE STYLE-WARNING: redefining WARN-UNIMPLEMENTED-INTERFACES in DEFUN STYLE-WARNING: redefining IMPORT-TO-SWANK-MOP in DEFUN STYLE-WARNING: redefining IMPORT-SWANK-MOP-SYMBOLS in DEFUN STYLE-WARNING: redefining IMPORT-FROM in DEFUN STYLE-WARNING: redefining CREATE-SOCKET in DEFGENERIC STYLE-WARNING: redefining LOCAL-PORT in DEFGENERIC STYLE-WARNING: redefining CLOSE-SOCKET in DEFGENERIC STYLE-WARNING: redefining ACCEPT-CONNECTION in DEFGENERIC STYLE-WARNING: redefining ADD-SIGIO-HANDLER in DEFGENERIC STYLE-WARNING: redefining REMOVE-SIGIO-HANDLERS in DEFGENERIC STYLE-WARNING: redefining ADD-FD-HANDLER in DEFGENERIC STYLE-WARNING: redefining REMOVE-FD-HANDLERS in DEFGENERIC STYLE-WARNING: redefining PREFERRED-COMMUNICATION-STYLE in DEFGENERIC STYLE-WARNING: redefining PREFERRED-COMMUNICATION-STYLE NIL in DEFMETHOD STYLE-WARNING: redefining SET-STREAM-TIMEOUT in DEFGENERIC STYLE-WARNING: redefining SET-STREAM-TIMEOUT (T T) in DEFMETHOD STYLE-WARNING: redefining EMACS-CONNECTED in DEFGENERIC STYLE-WARNING: redefining EMACS-CONNECTED NIL in DEFMETHOD STYLE-WARNING: redefining CALL-WITHOUT-INTERRUPTS in DEFGENERIC STYLE-WARNING: redefining CALL-WITHOUT-INTERRUPTS (T) in DEFMETHOD STYLE-WARNING: redefining GETPID in DEFGENERIC STYLE-WARNING: redefining LISP-IMPLEMENTATION-TYPE-NAME in DEFGENERIC STYLE-WARNING: redefining LISP-IMPLEMENTATION-TYPE-NAME NIL in DEFMETHOD STYLE-WARNING: redefining DEFAULT-DIRECTORY in DEFGENERIC STYLE-WARNING: redefining DEFAULT-DIRECTORY NIL in DEFMETHOD STYLE-WARNING: redefining SET-DEFAULT-DIRECTORY in DEFGENERIC STYLE-WARNING: redefining SET-DEFAULT-DIRECTORY (T) in DEFMETHOD STYLE-WARNING: redefining CALL-WITH-SYNTAX-HOOKS in DEFGENERIC STYLE-WARNING: redefining CALL-WITH-SYNTAX-HOOKS (T) in DEFMETHOD STYLE-WARNING: redefining DEFAULT-READTABLE-ALIST in DEFGENERIC STYLE-WARNING: redefining DEFAULT-READTABLE-ALIST NIL in DEFMETHOD STYLE-WARNING: redefining QUIT-LISP in DEFGENERIC STYLE-WARNING: redefining CALL-WITH-COMPILATION-HOOKS in DEFGENERIC STYLE-WARNING: redefining SWANK-COMPILE-STRING in DEFGENERIC STYLE-WARNING: redefining OPERATE-ON-SYSTEM in DEFGENERIC STYLE-WARNING: redefining OPERATE-ON-SYSTEM (T T) in DEFMETHOD STYLE-WARNING: redefining SWANK-COMPILE-FILE in DEFGENERIC STYLE-WARNING: redefining MAKE-FN-STREAMS in DEFGENERIC STYLE-WARNING: redefining MAKE-STREAM-INTERACTIVE in DEFGENERIC STYLE-WARNING: redefining MAKE-STREAM-INTERACTIVE (T) in DEFMETHOD STYLE-WARNING: redefining ARGLIST in DEFGENERIC STYLE-WARNING: redefining ARGLIST (T) in DEFMETHOD STYLE-WARNING: redefining FUNCTION-NAME in DEFGENERIC STYLE-WARNING: redefining FUNCTION-NAME (T) in DEFMETHOD STYLE-WARNING: redefining MACROEXPAND-ALL in DEFGENERIC STYLE-WARNING: redefining COMPILER-MACROEXPAND-1 in DEFGENERIC STYLE-WARNING: redefining COMPILER-MACROEXPAND-1 (T) in DEFMETHOD STYLE-WARNING: redefining COMPILER-MACROEXPAND in DEFGENERIC STYLE-WARNING: redefining COMPILER-MACROEXPAND (T) in DEFMETHOD STYLE-WARNING: redefining DESCRIBE-SYMBOL-FOR-EMACS in DEFGENERIC STYLE-WARNING: redefining DESCRIBE-DEFINITION in DEFGENERIC STYLE-WARNING: redefining INSTALL-DEBUGGER-GLOBALLY in DEFGENERIC STYLE-WARNING: redefining INSTALL-DEBUGGER-GLOBALLY (T) in DEFMETHOD STYLE-WARNING: redefining CALL-WITH-DEBUGGING-ENVIRONMENT in DEFGENERIC STYLE-WARNING: redefining CALL-WITH-DEBUGGER-HOOK in DEFGENERIC STYLE-WARNING: redefining CALL-WITH-DEBUGGER-HOOK (T T) in DEFMETHOD STYLE-WARNING: redefining COMPUTE-BACKTRACE in DEFGENERIC STYLE-WARNING: redefining PRINT-FRAME in DEFGENERIC STYLE-WARNING: redefining FRAME-SOURCE-LOCATION-FOR-EMACS in DEFGENERIC STYLE-WARNING: redefining FRAME-CATCH-TAGS in DEFGENERIC STYLE-WARNING: redefining FRAME-LOCALS in DEFGENERIC STYLE-WARNING: redefining FRAME-VAR-VALUE in DEFGENERIC STYLE-WARNING: redefining DISASSEMBLE-FRAME in DEFGENERIC STYLE-WARNING: redefining EVAL-IN-FRAME in DEFGENERIC STYLE-WARNING: redefining RETURN-FROM-FRAME in DEFGENERIC STYLE-WARNING: redefining RESTART-FRAME in DEFGENERIC STYLE-WARNING: redefining FORMAT-SLDB-CONDITION in DEFGENERIC STYLE-WARNING: redefining FORMAT-SLDB-CONDITION (T) in DEFMETHOD STYLE-WARNING: redefining CONDITION-REFERENCES in DEFGENERIC STYLE-WARNING: redefining CONDITION-REFERENCES (T) in DEFMETHOD STYLE-WARNING: redefining CONDITION-EXTRAS in DEFGENERIC STYLE-WARNING: redefining CONDITION-EXTRAS (T) in DEFMETHOD STYLE-WARNING: redefining ACTIVATE-STEPPING in DEFGENERIC STYLE-WARNING: redefining SLDB-BREAK-ON-RETURN in DEFGENERIC STYLE-WARNING: redefining SLDB-BREAK-AT-START in DEFGENERIC STYLE-WARNING: redefining LOCATION-BUFFER in DEFUN STYLE-WARNING: redefining (SETF LOCATION-BUFFER) in DEFUN STYLE-WARNING: redefining LOCATION-POSITION in DEFUN STYLE-WARNING: redefining (SETF LOCATION-POSITION) in DEFUN STYLE-WARNING: redefining LOCATION-HINTS in DEFUN STYLE-WARNING: redefining (SETF LOCATION-HINTS) in DEFUN STYLE-WARNING: redefining LOCATION-P in DEFUN STYLE-WARNING: redefining MAKE-LOCATION in DEFUN STYLE-WARNING: redefining ERROR-MESSAGE in DEFUN STYLE-WARNING: redefining (SETF ERROR-MESSAGE) in DEFUN STYLE-WARNING: redefining ERROR-P in DEFUN STYLE-WARNING: redefining MAKE-ERROR in DEFUN STYLE-WARNING: redefining FILE-NAME in DEFUN STYLE-WARNING: redefining (SETF FILE-NAME) in DEFUN STYLE-WARNING: redefining FILE-P in DEFUN STYLE-WARNING: redefining MAKE-FILE in DEFUN STYLE-WARNING: redefining BUFFER-NAME in DEFUN STYLE-WARNING: redefining (SETF BUFFER-NAME) in DEFUN STYLE-WARNING: redefining BUFFER-P in DEFUN STYLE-WARNING: redefining MAKE-BUFFER in DEFUN STYLE-WARNING: redefining POSITION-POS in DEFUN STYLE-WARNING: redefining (SETF POSITION-POS) in DEFUN STYLE-WARNING: redefining POSITION-P in DEFUN STYLE-WARNING: redefining MAKE-POSITION in DEFUN STYLE-WARNING: redefining FIND-DEFINITIONS in DEFGENERIC STYLE-WARNING: redefining BUFFER-FIRST-CHANGE in DEFGENERIC STYLE-WARNING: redefining BUFFER-FIRST-CHANGE (T) in DEFMETHOD STYLE-WARNING: redefining WHO-CALLS in DEFGENERIC STYLE-WARNING: redefining CALLS-WHO in DEFGENERIC STYLE-WARNING: redefining WHO-REFERENCES in DEFGENERIC STYLE-WARNING: redefining WHO-BINDS in DEFGENERIC STYLE-WARNING: redefining WHO-SETS in DEFGENERIC STYLE-WARNING: redefining WHO-MACROEXPANDS in DEFGENERIC STYLE-WARNING: redefining WHO-SPECIALIZES in DEFGENERIC STYLE-WARNING: redefining LIST-CALLERS in DEFGENERIC STYLE-WARNING: redefining LIST-CALLEES in DEFGENERIC STYLE-WARNING: redefining PROFILE in DEFGENERIC STYLE-WARNING: redefining PROFILED-FUNCTIONS in DEFGENERIC STYLE-WARNING: redefining UNPROFILE in DEFGENERIC STYLE-WARNING: redefining UNPROFILE-ALL in DEFGENERIC STYLE-WARNING: redefining UNPROFILE-ALL NIL in DEFMETHOD STYLE-WARNING: redefining PROFILE-REPORT in DEFGENERIC Now I didn't have an error or backtrace (like I did before), it just stopped there and it has been 5 minutes or so already. I'll try with my system's swank, the one my system's Slime (with that I've got an error and a backtrace). Thank you. -- Pupeno http://pupeno.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From vanek at acd.net Sun Jun 18 13:10:39 2006 From: vanek at acd.net (Lou Vanek) Date: Sun, 18 Jun 2006 13:10:39 +0000 Subject: [Bese-devel] Re: Getting ucw_box to work In-Reply-To: <1150635272.24727.91.camel@ulab.pupeno.com> References: <1150615648.24727.12.camel@ulab.pupeno.com> <449548C2.50402@acd.net> <1150635272.24727.91.camel@ulab.pupeno.com> Message-ID: <449550CF.7050003@acd.net> Pupeno wrote: > On Sun, 2006-06-18 at 12:36 +0000, Lou Vanek wrote: > >>Pupeno wrote: >> >> > Hello, >> > I am trying to get ucw to work, so I tried loading lisp.start (from >> > slime) to find this error: >> > >> > The name "IT.BESE.UCW-USER" does not designate any package. >> > [Condition of type SB-KERNEL:SIMPLE-PACKAGE-ERROR] >> > >> > Restarts: >> > 0: [ABORT] Abort SLIME compilation. >> > 1: [ABORT-REQUEST] Abort handling SLIME request. >> > 2: [TERMINATE-THREAD] Terminate this thread (#> > "worker" {B06D469}>) >> > >> > So, I went form by form in that file until >> > >> > (asdf:oos 'asdf:load-op :ucw) >> > >> > which eventually hungs. I am running it again and let it run for a long >> > time. >> > >> > Any obvious mistake that I am making ? >> > >> > Thank you. >> > >> >>Pupeno, >> >>You don't mention which version of Lisp or OS you are using, but I'm guessing >>Clisp on Windows. (Lisp in a box?) If you are on Windows you will have a harder >>time getting things to work. > > > I am running SBCL on Ubuntu (Linux). Actually, I am using packages that > I made myself taking the Debian Sarge sources (they are more up to > date). > > I have asdf set up more or less correctly I believe. > I dig into the problem until I've found there was a problem loading > swank, I have slime installed on my system (by Debian packages) and > neither that nor the one in the box work. I believe it is a kind of > threading problem. Furthermore, since I am running this from Slime, > isn't swank already loaded ? ... Yes. Try letting start.lisp create the swank server, and connect to it later (if everything starts up correctly) with slime. Make sure swank is closed down first (M-x slime-disconnect). From pupeno at pupeno.com Sun Jun 18 13:10:43 2006 From: pupeno at pupeno.com (Pupeno) Date: Sun, 18 Jun 2006 15:10:43 +0200 Subject: [Bese-devel] Re: Getting ucw_box to work In-Reply-To: <1150635272.24727.91.camel@ulab.pupeno.com> References: <1150615648.24727.12.camel@ulab.pupeno.com> <449548C2.50402@acd.net> <1150635272.24727.91.camel@ulab.pupeno.com> Message-ID: <1150636243.24727.95.camel@ulab.pupeno.com> Another try. Just running sbcl, without slime, and loading start.lisp produces a more meaningful error: pupeno at ulab:~/Software/hosting-compass/ucw-boxset$ sbcl This is SBCL 0.9.13, an implementation of ANSI Common Lisp. More information about SBCL is available at . SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (load "start.lisp") 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 QUEUE->LIST STYLE-WARNING: implicitly creating new generic function ENQUEUE-OR-MOVE-TO-FRONT debugger invoked on a SIMPLE-TYPE-ERROR in thread #: Argument X is not a REAL: NIL 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 # on #. 1: [ACCEPT] Continue, treating # on # as having been successful. 2: [ABORT ] Exit debugger, returning to top level. (SB-KERNEL:TWO-ARG-> NIL 3359602209) 0] -- Pupeno http://pupeno.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From vanek at acd.net Sun Jun 18 13:19:06 2006 From: vanek at acd.net (Lou Vanek) Date: Sun, 18 Jun 2006 13:19:06 +0000 Subject: [Bese-devel] Re: Getting ucw_box to work In-Reply-To: <1150636243.24727.95.camel@ulab.pupeno.com> References: <1150615648.24727.12.camel@ulab.pupeno.com> <449548C2.50402@acd.net> <1150635272.24727.91.camel@ulab.pupeno.com> <1150636243.24727.95.camel@ulab.pupeno.com> Message-ID: <449552CA.5020503@acd.net> Pupeno wrote: > Another try. > Just running sbcl, without slime, and loading start.lisp produces a more > meaningful error: > > pupeno at ulab:~/Software/hosting-compass/ucw-boxset$ sbcl > This is SBCL 0.9.13, an implementation of ANSI Common Lisp. > More information about SBCL is available at . > > SBCL is free software, provided as is, with absolutely no warranty. > It is mostly in the public domain; some portions are provided under > BSD-style licenses. See the CREDITS and COPYING files in the > distribution for more information. > * (load "start.lisp") > 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 QUEUE->LIST > STYLE-WARNING: implicitly creating new generic function > ENQUEUE-OR-MOVE-TO-FRONT > > debugger invoked on a SIMPLE-TYPE-ERROR in thread > #: > Argument X is not a REAL: NIL > > 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 # on > #. > 1: [ACCEPT] Continue, treating # on > # as having > been > successful. > 2: [ABORT ] Exit debugger, returning to top level. > > (SB-KERNEL:TWO-ARG-> NIL 3359602209) > 0] Is sbcl multithreaded? If not, you will not be able to start swank the way it is shown in start.lisp. An example of starting swank from a lisp that does not support multithreading is shown in the previously-referenced patches that I posted. From pupeno at pupeno.com Sun Jun 18 13:19:21 2006 From: pupeno at pupeno.com (Pupeno) Date: Sun, 18 Jun 2006 15:19:21 +0200 Subject: [Bese-devel] Re: Getting ucw_box to work In-Reply-To: <449550CF.7050003@acd.net> References: <1150615648.24727.12.camel@ulab.pupeno.com> <449548C2.50402@acd.net> <1150635272.24727.91.camel@ulab.pupeno.com> <449550CF.7050003@acd.net> Message-ID: <1150636761.24727.97.camel@ulab.pupeno.com> On Sun, 2006-06-18 at 13:10 +0000, Lou Vanek wrote: > Try letting start.lisp create the swank server, and connect to it > later (if > everything starts up correctly) with slime. Make sure swank is closed > down > first (M-x slime-disconnect). I think I've tried that by running sbcl and typing (load "start.lisp"), right ? I've posted the result in another mail. Thank you. -- Pupeno http://pupeno.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From vanek at acd.net Sun Jun 18 13:27:32 2006 From: vanek at acd.net (Lou Vanek) Date: Sun, 18 Jun 2006 13:27:32 +0000 Subject: [Bese-devel] Re: Getting ucw_box to work In-Reply-To: <1150636243.24727.95.camel@ulab.pupeno.com> References: <1150615648.24727.12.camel@ulab.pupeno.com> <449548C2.50402@acd.net> <1150635272.24727.91.camel@ulab.pupeno.com> <1150636243.24727.95.camel@ulab.pupeno.com> Message-ID: <449554C4.8000506@acd.net> Pupeno wrote: > Another try. > Just running sbcl, without slime, and loading start.lisp produces a more > meaningful error: > > pupeno at ulab:~/Software/hosting-compass/ucw-boxset$ sbcl > This is SBCL 0.9.13, an implementation of ANSI Common Lisp. > More information about SBCL is available at . > > SBCL is free software, provided as is, with absolutely no warranty. > It is mostly in the public domain; some portions are provided under > BSD-style licenses. See the CREDITS and COPYING files in the > distribution for more information. > * (load "start.lisp") > 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 QUEUE->LIST > STYLE-WARNING: implicitly creating new generic function > ENQUEUE-OR-MOVE-TO-FRONT > > debugger invoked on a SIMPLE-TYPE-ERROR in thread > #: > Argument X is not a REAL: NIL > > 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 # on > #. > 1: [ACCEPT] Continue, treating # on > # as having > been > successful. > 2: [ABORT ] Exit debugger, returning to top level. > > (SB-KERNEL:TWO-ARG-> NIL 3359602209) > 0] I'm assuming you're running on a 2.6+ Linux (sbcl says it supports threads on this version of Linux). What does the backtrace tell you about the error? Doesn't sbcl have a verbose option that can tell you which function it was compiling when it died? From pupeno at pupeno.com Sun Jun 18 13:41:18 2006 From: pupeno at pupeno.com (Pupeno) Date: Sun, 18 Jun 2006 15:41:18 +0200 Subject: [Bese-devel] Re: Getting ucw_box to work In-Reply-To: <449552CA.5020503@acd.net> References: <1150615648.24727.12.camel@ulab.pupeno.com> <449548C2.50402@acd.net> <1150635272.24727.91.camel@ulab.pupeno.com> <1150636243.24727.95.camel@ulab.pupeno.com> <449552CA.5020503@acd.net> Message-ID: <1150638078.24727.100.camel@ulab.pupeno.com> On Sun, 2006-06-18 at 13:19 +0000, Lou Vanek wrote: > Is sbcl multithreaded? It seems so: * (member :sb-thread *features*) (:SB-THREAD :ANSI-CL :COMMON-LISP :SBCL :UNIX :SB-DOC :SB-TEST :SB-PACKAGE-LOCKS :SB-UNICODE :SB-SOURCE-LOCATIONS :IEEE-FLOATING-POINT :X86 :ELF :LINUX :GENCGC :STACK-GROWS-DOWNWARD-NOT-UPWARD :C-STACK-IS-CONTROL-STACK :STACK-ALLOCATABLE-CLOSURES :ALIEN-CALLBACKS :LINKAGE-TABLE :OS-PROVIDES-DLOPEN :OS-PROVIDES-DLADDR :OS-PROVIDES-PUTWC) -- Pupeno http://pupeno.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From pupeno at pupeno.com Sun Jun 18 13:50:03 2006 From: pupeno at pupeno.com (Pupeno) Date: Sun, 18 Jun 2006 15:50:03 +0200 Subject: [Bese-devel] Re: Getting ucw_box to work In-Reply-To: <449554C4.8000506@acd.net> References: <1150615648.24727.12.camel@ulab.pupeno.com> <449548C2.50402@acd.net> <1150635272.24727.91.camel@ulab.pupeno.com> <1150636243.24727.95.camel@ulab.pupeno.com> <449554C4.8000506@acd.net> Message-ID: <1150638603.24727.105.camel@ulab.pupeno.com> On Sun, 2006-06-18 at 13:27 +0000, Lou Vanek wrote: > I'm assuming you're running on a 2.6+ Linux (sbcl says it supports threads > on this version of Linux). I am. > What does the backtrace tell you about the error? > Doesn't sbcl have a verbose option that can tell you which function it was > compiling when it died? Here I have the backtrace: 0: (SB-KERNEL:TWO-ARG-> NIL 3359602209) 1: (FILE-NEWER-P #P"/var/cache/common-lisp-controller/1000/sbcl/local/home/pupeno/Software/hosting-compass/ucw-boxset/slime/slime/swank-backend.lisp" #P"/home/pupeno/.slime/fasl/sbcl-0.9.13-linux-x86/swank-backend.fasl") 2: ((LAMBDA ())) 3: (SB-C::%WITH-COMPILATION-UNIT #) 4: (LOAD-SWANK :SOURCE-DIRECTORY NIL :FASL-DIRECTORY NIL) 5: (SB-FASL::LOAD-FASL-GROUP #) 6: (SB-FASL::LOAD-AS-FASL # NIL #) 7: (SB-FASL::INTERNAL-LOAD #P"/var/cache/common-lisp-controller/1000/sbcl/local/home/pupeno/Software/hosting-compass/ucw-boxset/slime/slime/swank-loader.fasl" #P"/var/cache/common-lisp-controller/1000/sbcl/local/home/pupeno/Software/hosting-compass/ucw-boxset/slime/slime/swank-loader.fasl" :ERROR NIL NIL :BINARY NIL) 8: (SB-FASL::INTERNAL-LOAD #P"/var/cache/common-lisp-controller/1000/sbcl/local/home/pupeno/Software/hosting-compass/ucw-boxset/slime/slime/swank-loader.fasl" #P"/var/cache/common-lisp-controller/1000/sbcl/local/home/pupeno/Software/hosting-compass/ucw-boxset/slime/slime/swank-loader.fasl" :ERROR NIL NIL NIL :DEFAULT) 9: (LOAD #P"/var/cache/common-lisp-controller/1000/sbcl/local/home/pupeno/Software/hosting-compass/ucw-boxset/slime/slime/swank-loader.fasl") 10: ((SB-PCL::FAST-METHOD ASDF:PERFORM (ASDF:LOAD-OP ASDF:CL-SOURCE-FILE)) # # # #) 11: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1.)) # # # #) 12: ((LAMBDA ())) 13: (SB-C::%WITH-COMPILATION-UNIT #) 14: (ASDF:OPERATE ASDF:LOAD-OP :UCW) 15: (SB-INT:EVAL-IN-LEXENV (ASDF:OOS 'ASDF:LOAD-OP :UCW) #) 16: (SB-FASL::LOAD-AS-SOURCE # NIL NIL) 17: (SB-FASL::INTERNAL-LOAD #P"start.lisp" #P"/home/pupeno/Software/hosting-compass/ucw-boxset/start.lisp" :ERROR NIL NIL :SOURCE :DEFAULT) 18: (SB-FASL::INTERNAL-LOAD #P"start.lisp" #P"/home/pupeno/Software/hosting-compass/ucw-boxset/start.lisp" :ERROR NIL NIL NIL :DEFAULT) 19: (LOAD "start.lisp") 20: (SB-INT:EVAL-IN-LEXENV (LOAD "start.lisp") #) 21: (SB-EXT:INTERACTIVE-EVAL (LOAD "start.lisp")) 22: (SB-IMPL::REPL-FUN NIL) 23: ((LAMBDA ())) 24: ((LAMBDA ())) 25: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX #) 26: (SB-IMPL::TOPLEVEL-REPL NIL) 27: (SB-IMPL::TOPLEVEL-INIT) 28: ((LABELS SB-IMPL::RESTART-LISP)) Thank you. -- Pupeno http://pupeno.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From vanek at acd.net Sun Jun 18 14:04:48 2006 From: vanek at acd.net (Lou Vanek) Date: Sun, 18 Jun 2006 14:04:48 +0000 Subject: [Bese-devel] Re: Getting ucw_box to work In-Reply-To: <1150638603.24727.105.camel@ulab.pupeno.com> References: <1150615648.24727.12.camel@ulab.pupeno.com> <449548C2.50402@acd.net> <1150635272.24727.91.camel@ulab.pupeno.com> <1150636243.24727.95.camel@ulab.pupeno.com> <449554C4.8000506@acd.net> <1150638603.24727.105.camel@ulab.pupeno.com> Message-ID: <44955D80.4090402@acd.net> Pupeno wrote: [snip] > Here I have the backtrace: > > 0: (SB-KERNEL:TWO-ARG-> NIL 3359602209) > 1: (FILE-NEWER-P > > #P"/var/cache/common-lisp-controller/1000/sbcl/local/home/pupeno/Software/hosting-compass/ucw-boxset/slime/slime/swank-backend.lisp" > > #P"/home/pupeno/.slime/fasl/sbcl-0.9.13-linux-x86/swank-backend.fasl") I believe what's happening here is sbcl is dieing on line 109 of swank-loader.lisp: (defun file-newer-p (new-file old-file) "Returns true if NEW-FILE is newer than OLD-FILE." (> (file-write-date new-file) (file-write-date old-file))) ;line 109 For some reason sbcl cannot figure out what the file-write-date of "/home/pupeno/.slime/fasl/sbcl-0.9.13-linux-x86/swank-backend.fasl" is, so it is returning nil and operator '>' is complaining about a nil argument. Interestingly enough, this is a known problem (to Google): http://www.codecomments.com/archive274-2006-4-884549.html From vanek at acd.net Sun Jun 18 14:51:48 2006 From: vanek at acd.net (Lou Vanek) Date: Sun, 18 Jun 2006 14:51:48 +0000 Subject: [Bese-devel] Re: Getting ucw_box to work In-Reply-To: <1150641465.24727.111.camel@ulab.pupeno.com> References: <1150615648.24727.12.camel@ulab.pupeno.com> <449548C2.50402@acd.net> <1150635272.24727.91.camel@ulab.pupeno.com> <1150636243.24727.95.camel@ulab.pupeno.com> <449554C4.8000506@acd.net> <1150638603.24727.105.camel@ulab.pupeno.com> <44955D80.4090402@acd.net> <1150641465.24727.111.camel@ulab.pupeno.com> Message-ID: <44956884.4060804@acd.net> Pupeno wrote: > On Sun, 2006-06-18 at 14:04 +0000, Lou Vanek wrote: > >>For some reason sbcl cannot figure out what the file-write-date of >>"/home/pupeno/.slime/fasl/sbcl-0.9.13-linux-x86/swank-backend.fasl" >>is, >>so it is returning nil and operator '>' is complaining about a nil >>argument. > > I cleaned up .slime and other fasl containing directories, now the error > is > > The file > "/var/cache/common-lisp-controller/1000/sbcl/local/home/pupeno/Software/hosting-compass/ucw-boxset/slime/slime/swank-backend.lisp" does not exist. > > The fasl of that file is there, but not the lisp one. I was recommended > (by segv) to remove the swank-start form and load on Slime, but that > takes me to the first error: > > The name "IT.BESE.UCW-USER" does not designate any package. > [Condition of type SB-KERNEL:SIMPLE-PACKAGE-ERROR] > > >>Interestingly enough, this is a known problem (to Google): >>http://www.codecomments.com/archive274-2006-4-884549.html > > > Well, the fix didn't work for me :( > > Is there any particular version of sbcl know to work ? should I move to > cmucl ? > > Thanks. Here's a temp work-around that may be worth trying once. Instead of this: (defun file-newer-p (new-file old-file) "Returns true if NEW-FILE is newer than OLD-FILE." (> (file-write-date new-file) (file-write-date old-file))) you could use this: (defun file-newer-p (new-file old-file) t) This should cause asdf to recompile everything every time, which shouldn't hurt much except to cause startup times to be longer. If you want to continue using sbcl I would take this discussion to both the steel-bank.devel ML and the cclan (asdf) ML and get their opinions, since they should have seen this problem before. I'm no lisp expert and cannot recommend any particular version of lisp, but doing anything is probably going to get you further than doing nothing. In other words, yes, trying other Lisps is something I would do. I tried sbcl once in the past and gave up on it since it didn't seem to work on my platform (windows). You might also want to ask segv which version of lisp he uses since i believe segv wrote both ucw and slime. Lou Vanek From evrim at core.gen.tr Sun Jun 18 23:28:13 2006 From: evrim at core.gen.tr (Evrim ULU) Date: Mon, 19 Jun 2006 02:28:13 +0300 Subject: [Bese-devel] new dispatcher implementation Message-ID: <4495E18D.5090108@core.gen.tr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, i've finished new dispatcher implementatioon. i've tested it however, there may be glitches. please feel free to contact me in case of a bug/feature req. Here is a short changes log for information (in reverse order): Mon Jun 19 02:25:21 EEST 2006 evrim at core.gen.tr * - merged conflicts with current dev-branch. tal-matcher updated according to marc os's ends-width patch. Sun Jun 18 23:14:26 EEST 2006 evrim at core.gen.tr * - Introducing the new dispatcher implementation. now we have reusable matchers and handlers. API didn't change a lot for now. Only change is two arg'ed handler lambda()'s are replaced with zero arg-ed one's to form up a standard. Old arguments like application and context can be reached via special *context*. Please see also previous patch comments for more info about what may have changed. Sun Jun 18 20:45:43 EEST 2006 evrim at core.gen.tr * - ucw example application fixed to reflect changes in new dispacther api. Sun Jun 18 20:45:07 EEST 2006 evrim at core.gen.tr * - ucw admin application dispatchers fixed to reflect new dispatcher api. Sun Jun 18 20:44:30 EEST 2006 evrim at core.gen.tr * - ensure-session moved to std-application class. Sun Jun 18 20:43:11 EEST 2006 evrim at core.gen.tr * - defentry-point fixed accoring to new disaptcher implementation. It now creates a zero-arged lambda function for action handling. Sun Jun 18 20:42:08 EEST 2006 evrim at core.gen.tr * - fixed exports for new dispatcher implementaion. exported dispatchers: * action-dispatcher * minimal-dispatcher * simple-dispatcher * parenscript-dispatcher * url-dispatcher * regexp-dispatcher * tal-dispatcher - *dispatcher-registers* is un-exported since it does not exists anymore. Sun Jun 18 20:39:02 EEST 2006 evrim at core.gen.tr * - flush-request-response() moved to object std-request-context. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEleGMwzkKLGtRuHsRAttUAKDXMnmc3f8jLs6RjZ1OWtiVWY2VOQCeO4of mL5z2UjW8qL726UtEaEQ4rk= =+j1V -----END PGP SIGNATURE----- From door at lcpi.ru Mon Jun 19 07:39:42 2006 From: door at lcpi.ru (Alexey Antipov) Date: Mon, 19 Jun 2006 11:39:42 +0400 Subject: [Bese-devel] action-dispatcher creation fix Message-ID: <20060619073942.GA5052@rabbit.loc> action-dispatcher created with nil priority this variant use class :initform (defun action-dispatcher (&optional (priority nil priorityp)) (apply #'make-instance 'action-dispatcher (when priorityp :priority priority))) -------------- next part -------------- New patches: [action-dispatcher created with nil priority Alexey Antipov **20060619073557] { hunk ./src/rerl/standard-dispatcher.lisp 392 -(defun action-dispatcher (&optional priority) - (make-instance 'action-dispatcher - :priority priority)) +(defun action-dispatcher (&optional (priority nil priorityp)) + (apply #'make-instance 'action-dispatcher + (when priorityp + :priority priority))) } Context: [- merged conflicts with current dev-branch. tal-matcher updated according to marcos's ends-width patch. evrim at core.gen.tr**20060618232521] [- Introducing the new dispatcher implementation. now we have reusable evrim at core.gen.tr**20060618201426 matchers and handlers. API didn't change a lot for now. Only change is two arg'ed handler lambda()'s are replaced with zero arg-ed one's to form up a standard. Old arguments like application and context can be reached via special *context*. Please see also previous patch comments for more info about what may have changed. ] [- ucw example application fixed to reflect changes in new dispacther evrim at core.gen.tr**20060618174543 api. ] [- ucw admin application dispatchers fixed to reflect new dispatcher evrim at core.gen.tr**20060618174507 api. ] [- ensure-session moved to std-application class. evrim at core.gen.tr**20060618174430] [- defentry-point fixed accoring to new disaptcher implementation. It evrim at core.gen.tr**20060618174311 now creates a zero-arged lambda function for action handling. ] [- fixed exports for new dispatcher implementaion. exported dispatchers: evrim at core.gen.tr**20060618174208 * action-dispatcher * minimal-dispatcher * simple-dispatcher * parenscript-dispatcher * url-dispatcher * regexp-dispatcher * tal-dispatcher - *dispatcher-registers* is un-exported since it does not exists anymore. ] [- flush-request-response() moved to object std-request-context. evrim at core.gen.tr**20060618173902] [Display the locale preference list in the l10n example attila.lendvai at gmail.com**20060618211355] [Merge dev/ajax conflict in l10n example attila.lendvai at gmail.com**20060618154956] [Make the l10n tal example an embeddable non-window component attila.lendvai at gmail.com**20060618153512] [Use indefinit articles in l10n example attila.lendvai at gmail.com**20060618143451] [Backport examples to the dev branch (fix it :) attila.lendvai at gmail.com**20060618142159] [Better way to load the examples in the README attila.lendvai at gmail.com**20060618142128] [New l10n and i18n example attila.lendvai at gmail.com**20060618134812] [Fixed some glitches to make (progn (require :ucw) (load "ucw/etc/start.lisp")) work out of the box attila.lendvai at gmail.com**20060618114506] [Get rid of accidental listify, use ensure-list attila.lendvai at gmail.com**20060618114006] [Some more l10n work attila.lendvai at gmail.com**20060617175729] [Export make-request-context and cookie-session-request-context attila.lendvai at gmail.com**20060617132000] [Small i18n fix and comment attila.lendvai at gmail.com**20060616123417] [Fix last patch (by Alberto Santini ) Maciek Pasternacki **20060617173114] [Fix an IE date header problem (by Lou Vanek ) Maciek Pasternacki **20060617134808] [Rename i18n to l10n. restructure files. move cl-l10n dependncy to ucw.l10n system (off of ucw) Marco Baringer **20060617123925] [Added :initarg to extension slot of tal-dispatcher Marco Baringer **20060616153433] [Use IF instead of AIF since the it binding is nevere referenced. Marco Baringer **20060616153418] [Remover spurious cons in read-from-client-string Marco Baringer **20060616153209] [Update (setf container.current-component)'s docstring Marco Baringer **20060616153139] [set arnesi:*warn-undefined* to NIL to avoid problems with asdf+sbcl Marco Baringer **20060616152852] [Adds a class html-element and makes it superclass of the widgets and form inputs. Also fixes some inconsistencies in marijn at haverbeke.nl**20060613220202 components/form.lisp. ] [Minor indentation fix Marco Baringer **20060607120319] [Changed the tal-dispatcher to only look for tals files for specific urls (defaults to those ending in .ucw) Marco Baringer **20060607120228] [Lazy create the isolate-hash hashtable attila.lendvai at gmail.com**20060616150043] [Added enabled/disabled image/tooltip support to checkbox attila.lendvai at gmail.com**20060614152854] [Add cl-l10n dependency to the docs attila.lendvai at gmail.com**20060616115153] [cl-l10n integration (WARNING: i18n api change) attila.lendvai at gmail.com**20060616111739 The stuff in i18n.lisp has been revisited. Most of the locale values are cl-l10n locale instances or locale names that the cl-l10n locale function understands. If you subclass i18n-application then each request will bind *locale* according to the client's browser settings. Most of the time it's a list in which case *locale* will be bound to this list and resource lookups will try each locale in this list until the resource is found. The application's default locale is always appended to the end of this list when it's not already in it. ] [Only return the (absolute) path in map-query-path-to-file when it has a filename part attila.lendvai at gmail.com**20060616110635] [Since we're alread using dojo we might as well use all the shortcuts it provides Marco Baringer **20060607120422] [Cache the cl-ppcre:scanner for the url-string in a regexp dispatcher. Nathan Bird **20060613151409 Profiling showed that a LOT of time and memory was spent creating scanners. Do the regexp compilation once, and reuse the scanner for all requests. If the url-string on the regexp-dispatcher is changed then the scanner will be recreated. ] [httpd now skips empry request params in map-parameters attila.lendvai at gmail.com**20060613152005] [- :initarg :dispatchers added std-application. evrim at core.gen.tr**20060612171540] [Added comments to the cache examples attila.lendvai at gmail.com**20060610114956] [- parenscript-dispatcher: no need for a dynamic handler function since evrim at core.gen.tr**20060611145936 it's static. Parenscript disptacher was using function-dispatcher and a (lambda (app context)) to dispatch. I've implemented a usual dispatch method to dispatch paresncript js files. The reason is, it's easier to debug now since handler lambda's are not instantiated across applications. ] [Fix config.lisp dependency in ucw.asd attila.lendvai at gmail.com**20060609213216] [Tiny doc fix attila.lendvai at gmail.com**20060609205951] [Added tooltip support to form fields attila.lendvai at gmail.com**20060609151248] [Fix return value of remove-component switching-container attila.lendvai at gmail.com**20060607145208] [- export #:window-component.content-type evrim at core.gen.tr**20060608112655] [- std-application default dispatchers are now provided from via initform. evrim at core.gen.tr**20060607125015] [- removed shared-init :after method of std-application, default dispathers are now in :initform evrim at core.gen.tr**20060607124939] [Modify setf component.current-component to return (values new-value happened) attila.lendvai at gmail.com**20060607134355] [(setf container.current-component) returns t when the set actually happened attila.lendvai at gmail.com**20060606195958] [Fix dynamic forms example delete attila.lendvai at gmail.com**20060604201256] [Split ucw.css and examples.css attila.lendvai at gmail.com**20060604200705] [Added child-components to container, WARNING: small api change attila.lendvai at gmail.com**20060604185229 In the process renamed the :pred kayword argument to :predicate ] [Doc/comment fixes attila.lendvai at gmail.com**20060604185138] [Add typecheck to s-c s-v-u-c and also set the parent slot attila.lendvai at gmail.com**20060604172617] [Export get-paremeter and map-parameters Marco Baringer **20060604171847] [When adding the ucw-form-field-invalid class remeber to remove the ucw-form-field-valid class (Patch by: Marijn Haverbeke ) Marco Baringer **20060604171146] [- secure-application#exit-user is broken due to removal of find-entry-point. evrim at core.gen.tr**20060531115550] [Silly typos in previous patch Marco Baringer **20060604141410] [Added :class attributes to all the form elements Marco Baringer **20060604140146] [Allow for component-slot definition with :component nil Nathan Bird **20060508155758 This patch changes the way the component-class.component-sltos list is built. It should now be in the same order as the class-slots which is hopefully the same order they were defined in. Additionally (the bigger reason) is so that slots that were declared with ':component nil' are marked as being component-slots but are left unbound. ] [Bind swank::*sldb-quit-restart* to 'fail-miserably Nathan Bird **20060531193531 Now when the slime debug buffer pops up while handling a web request, 'q' (sldb-quit) will cause the 'fail-miserably restart to be invoked. ] [fixing logging message typo Nathan Bird **20060531155026] [made the remove component :after be correctly specialized Russ Tyndall **20060529222215] [added pass through for optional args in read client string Russ Tyndall **20060525223940] [made it correctly out put human number strings rather than lisp number strings (aka no more 1.23d0) Russ Tyndall **20060517164149] [provide #'meta-refresh Nathan Bird **20060529215502 Cause a meta-refresh (a freshly got (GET) url) at this point. This is useful in order to have a GET url after a form POST's actions have completed running. The user can then refresh to his heart's content. ] [Adding child-components export Nathan Bird **20060508161431] [Add a child-components function Nathan Bird **20060508160149] [Export ucw::get-header Marco Baringer **20060530233436] [Added render-option specialized on nil attila.lendvai at gmail.com**20060530213435] [Don't specialize slot-value-using-class on the value parameter Marco Baringer **20060530105600] [write-uri-sans-query needs to deal with 'special' characters in the query-part Marco Baringer **20060529182043] [Added logging statements which report the action being evaluated. Marco Baringer **20060529080637] [Add "_" prefix to all ucw defined query parameters. Marco Baringer **20060529072846 This helps aliviate (but does not completly remove) the probablitily of a ucw defined parameter conflicting with a user defined parameter. I'll admit that the odds of one of ucw's randomly defined parameter names being the same as a user defined parameter name are slim, but when it does happen it's a once-every-1000-totally-unreproducable-100%untractable error :( ] [Implement radio-button widget Marco Baringer **20060529072632] [Tiny doc fix attila.lendvai at gmail.com**20060525225601] [Added remove-component to container attila.lendvai at gmail.com**20060523154055] [Set arnesi:*warn-undefined* to T in the start.lisp script Marco Baringer **20060526192721] [Fix erroneous evaluation bug in ucw-tags.lisp Marco Baringer **20060526192234 the code which checked for the precesne of an action parameter in a **20060514233614 To simplify things, the two systems used by bin/ucwctl are merged into the general `:ucw' one. As a side-effect, etc/start.lisp now loads the `*ucw-config-file*' when present or set the `*ucw-systems*' and `*ucw-applications*' variables. http://common-lisp.net/pipermail/bese-devel/2006-May/002122.html ] [Export ucw:is-an-integer-validator. Maciek Pasternacki **20060514232653] [Add message slot to validator class to contain an error message. Maciek Pasternacki **20060514232631] [switch from bare-bones dojo to ajax edition. To fix dependency errors where ucw expects the dojo.html namespace or whatever you want to call it to be present. cjstuij at gmail.com**20060510220528] [Read-from-client-string Nathan Bird **20060430215547 Useful for reading data from questionable origins where *read-eval* needs to be false. ] [Indentation fixup in tabbed-pane.lisp Marco Baringer **20060509102104] [Minor refactoring in container.lisp Marco Baringer **20060509102050] [Mention the difference between (setf application.dispathers) and (setf (slot-value app 'dispatchers)) in the docstring Marco Baringer **20060509101051] [Add a **20060506233602 **20060504233324] [INCOMPATIBLE CHANGE: add NET-TELENT-DATE dependency, send out Date: header, make SERVE-FILE cache-friendly (use Date:, Last-Modified:, Expires: and If-Modified-Since: headers). Maciek Pasternacki **20060503013844] [Don't send headers set to NIL (especially Content-Length:) in response. Maciek Pasternacki **20060503013648] [New function (delete-header message header-name). Maciek Pasternacki **20060503011904] [Don't send body if HTTP method is HEAD. Maciek Pasternacki **20060502222010] [Save HTTP method of request as string. Maciek Pasternacki **20060502221955] [Initform for (request response). Maciek Pasternacki **20060502221939] [Include in httpd response a request associated with it. Maciek Pasternacki **20060502221158] [changed docs to get up to date and add some info cjstuij at gmail.com**20060503094055] [Added send-redirect function. Marco Baringer **20060501154250 send-redirect does what redirect-component's render method did but it's usable from a simple-dispatcher (or anywhere else we don't have ucw's component context machinery). ] [Use dolist*, not dolist, in tabbed-pane's render method. Marco Baringer **20060501135314] [Using (when (whatever) T) is weird, use (whatever) instead Marco Baringer **20060501135000] [Minor indentation/whitespace fixups in src/components/form.lisp Marco Baringer **20060501134849] [make-with-dummy-request-nicer cjstuij at gmail.com**20060501001756] [tabbed-pane-makeover - tabbed panes are now wrapped in divs in stead of a table, for more design flexibility. Is no longer tied to a tal file. cjstuij at gmail.com**20060430233920] [Removing integer-range-validator, use number-range-validator instead. Nathan Bird **20060428165829] [the value of a number-field should be nil, not 0, if nothing was entered. Nathan Bird **20060428164949] [bin/ucwctl: allow a custom ucwctl.conf via -u|--ucwctl-file Luca Capello **20060501110031 This adds the possibility to specify a different ucwctl.conf file instead of the default /etc/ucw/ucwctl.conf. Moreover, by default ucwctl now reads ~/.ucw/ucwctl.conf it it exists, overriding the values in the general /etc/ucw/ucwctl.conf, and the same happens if the ucwctl.conf is specified via the command line option. All command line options override the values present in any ucwctl.conf files. The order is the following: 1) /etc/ucw/ucwctl.conf (if it exists) 2) ~/.ucw/ucwctl.conf (if it exists) 3) -u|--ucwctl-file (if specified, exit if it cannot be read) 4) command line options A deeper discussion is available at: http://common-lisp.net/pipermail/bese-devel/2006-April/001932.html http://common-lisp.net/pipermail/bese-devel/2006-April/001961.html ] [In the phone and email validators instead of defining a new slot we just use the :default-initargs class option Marco Baringer **20060428103114] [Adding documentation to form.lisp Nathan Bird **20060428023256] [Rearranging file contents to reduce style-warnings Nathan Bird **20060428022511] [Implementing value-validators Nathan Bird **20060428020403 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. ] [Expanded the forms example to include a number-field and number-range-validated field. Nathan Bird **20060428014551] [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 russ at acceleration.net**20060425154947] [added regex exports russ at acceleration.net**20060424225714] [Comment fixup Nathan Bird **20060427173259] [Added missing id param that got lost in my **20060425145623] Patch bundle hash: e36f1f393d230625220944109016d8d165541461 From pupeno at pupeno.com Mon Jun 19 10:13:40 2006 From: pupeno at pupeno.com (Pupeno) Date: Mon, 19 Jun 2006 12:13:40 +0200 Subject: [Bese-devel] More languages Message-ID: <1150712020.11282.14.camel@ulab.pupeno.com> A patch to add Spanish and Esperanto translations of the simple message (I haven't tested it because the box doesn't work on my system). -- Pupeno http://pupeno.com -------------- next part -------------- New patches: [Spanish translation. Jos? Pablo Ezequiel "Pupeno" Fern?ndez Silva **20060619095043] { adddir ./wwwroot/ucw/examples/l10n/es_ES addfile ./wwwroot/ucw/examples/l10n/es_ES/greeting.tal hunk ./wwwroot/ucw/examples/l10n/es_ES/greeting.tal 1 +Hola! Estoy en Espa?ol } [Esperanto translation. Jos? Pablo Ezequiel "Pupeno" Fern?ndez Silva **20060619101131] { adddir ./wwwroot/ucw/examples/l10n/eo addfile ./wwwroot/ucw/examples/l10n/eo/greeting.tal hunk ./wwwroot/ucw/examples/l10n/eo/greeting.tal 1 +Saluton! Mi parolas Esperanton! hunk ./wwwroot/ucw/examples/l10n/es_ES/greeting.tal 1 -Hola! Estoy en Espa?ol +Hola! Estoy en Espa?ol! } Context: [- merged conflicts with current dev-branch. tal-matcher updated according to marcos's ends-width patch. evrim at core.gen.tr**20060618232521] [- Introducing the new dispatcher implementation. now we have reusable evrim at core.gen.tr**20060618201426 matchers and handlers. API didn't change a lot for now. Only change is two arg'ed handler lambda()'s are replaced with zero arg-ed one's to form up a standard. Old arguments like application and context can be reached via special *context*. Please see also previous patch comments for more info about what may have changed. ] [- ucw example application fixed to reflect changes in new dispacther evrim at core.gen.tr**20060618174543 api. ] [- ucw admin application dispatchers fixed to reflect new dispatcher evrim at core.gen.tr**20060618174507 api. ] [- ensure-session moved to std-application class. evrim at core.gen.tr**20060618174430] [- defentry-point fixed accoring to new disaptcher implementation. It evrim at core.gen.tr**20060618174311 now creates a zero-arged lambda function for action handling. ] [- fixed exports for new dispatcher implementaion. exported dispatchers: evrim at core.gen.tr**20060618174208 * action-dispatcher * minimal-dispatcher * simple-dispatcher * parenscript-dispatcher * url-dispatcher * regexp-dispatcher * tal-dispatcher - *dispatcher-registers* is un-exported since it does not exists anymore. ] [- flush-request-response() moved to object std-request-context. evrim at core.gen.tr**20060618173902] [Display the locale preference list in the l10n example attila.lendvai at gmail.com**20060618211355] [Merge dev/ajax conflict in l10n example attila.lendvai at gmail.com**20060618154956] [Make the l10n tal example an embeddable non-window component attila.lendvai at gmail.com**20060618153512] [Use indefinit articles in l10n example attila.lendvai at gmail.com**20060618143451] [Backport examples to the dev branch (fix it :) attila.lendvai at gmail.com**20060618142159] [Better way to load the examples in the README attila.lendvai at gmail.com**20060618142128] [New l10n and i18n example attila.lendvai at gmail.com**20060618134812] [Fixed some glitches to make (progn (require :ucw) (load "ucw/etc/start.lisp")) work out of the box attila.lendvai at gmail.com**20060618114506] [Get rid of accidental listify, use ensure-list attila.lendvai at gmail.com**20060618114006] [Some more l10n work attila.lendvai at gmail.com**20060617175729] [Export make-request-context and cookie-session-request-context attila.lendvai at gmail.com**20060617132000] [Small i18n fix and comment attila.lendvai at gmail.com**20060616123417] [Fix last patch (by Alberto Santini ) Maciek Pasternacki **20060617173114] [Fix an IE date header problem (by Lou Vanek ) Maciek Pasternacki **20060617134808] [Rename i18n to l10n. restructure files. move cl-l10n dependncy to ucw.l10n system (off of ucw) Marco Baringer **20060617123925] [Added :initarg to extension slot of tal-dispatcher Marco Baringer **20060616153433] [Use IF instead of AIF since the it binding is nevere referenced. Marco Baringer **20060616153418] [Remover spurious cons in read-from-client-string Marco Baringer **20060616153209] [Update (setf container.current-component)'s docstring Marco Baringer **20060616153139] [set arnesi:*warn-undefined* to NIL to avoid problems with asdf+sbcl Marco Baringer **20060616152852] [Adds a class html-element and makes it superclass of the widgets and form inputs. Also fixes some inconsistencies in marijn at haverbeke.nl**20060613220202 components/form.lisp. ] [Minor indentation fix Marco Baringer **20060607120319] [Changed the tal-dispatcher to only look for tals files for specific urls (defaults to those ending in .ucw) Marco Baringer **20060607120228] [Lazy create the isolate-hash hashtable attila.lendvai at gmail.com**20060616150043] [Added enabled/disabled image/tooltip support to checkbox attila.lendvai at gmail.com**20060614152854] [Add cl-l10n dependency to the docs attila.lendvai at gmail.com**20060616115153] [cl-l10n integration (WARNING: i18n api change) attila.lendvai at gmail.com**20060616111739 The stuff in i18n.lisp has been revisited. Most of the locale values are cl-l10n locale instances or locale names that the cl-l10n locale function understands. If you subclass i18n-application then each request will bind *locale* according to the client's browser settings. Most of the time it's a list in which case *locale* will be bound to this list and resource lookups will try each locale in this list until the resource is found. The application's default locale is always appended to the end of this list when it's not already in it. ] [Only return the (absolute) path in map-query-path-to-file when it has a filename part attila.lendvai at gmail.com**20060616110635] [Since we're alread using dojo we might as well use all the shortcuts it provides Marco Baringer **20060607120422] [Cache the cl-ppcre:scanner for the url-string in a regexp dispatcher. Nathan Bird **20060613151409 Profiling showed that a LOT of time and memory was spent creating scanners. Do the regexp compilation once, and reuse the scanner for all requests. If the url-string on the regexp-dispatcher is changed then the scanner will be recreated. ] [httpd now skips empry request params in map-parameters attila.lendvai at gmail.com**20060613152005] [- :initarg :dispatchers added std-application. evrim at core.gen.tr**20060612171540] [Added comments to the cache examples attila.lendvai at gmail.com**20060610114956] [- parenscript-dispatcher: no need for a dynamic handler function since evrim at core.gen.tr**20060611145936 it's static. Parenscript disptacher was using function-dispatcher and a (lambda (app context)) to dispatch. I've implemented a usual dispatch method to dispatch paresncript js files. The reason is, it's easier to debug now since handler lambda's are not instantiated across applications. ] [Fix config.lisp dependency in ucw.asd attila.lendvai at gmail.com**20060609213216] [Tiny doc fix attila.lendvai at gmail.com**20060609205951] [Added tooltip support to form fields attila.lendvai at gmail.com**20060609151248] [Fix return value of remove-component switching-container attila.lendvai at gmail.com**20060607145208] [- export #:window-component.content-type evrim at core.gen.tr**20060608112655] [- std-application default dispatchers are now provided from via initform. evrim at core.gen.tr**20060607125015] [- removed shared-init :after method of std-application, default dispathers are now in :initform evrim at core.gen.tr**20060607124939] [Modify setf component.current-component to return (values new-value happened) attila.lendvai at gmail.com**20060607134355] [(setf container.current-component) returns t when the set actually happened attila.lendvai at gmail.com**20060606195958] [Fix dynamic forms example delete attila.lendvai at gmail.com**20060604201256] [Split ucw.css and examples.css attila.lendvai at gmail.com**20060604200705] [Added child-components to container, WARNING: small api change attila.lendvai at gmail.com**20060604185229 In the process renamed the :pred kayword argument to :predicate ] [Doc/comment fixes attila.lendvai at gmail.com**20060604185138] [Add typecheck to s-c s-v-u-c and also set the parent slot attila.lendvai at gmail.com**20060604172617] [Export get-paremeter and map-parameters Marco Baringer **20060604171847] [When adding the ucw-form-field-invalid class remeber to remove the ucw-form-field-valid class (Patch by: Marijn Haverbeke ) Marco Baringer **20060604171146] [- secure-application#exit-user is broken due to removal of find-entry-point. evrim at core.gen.tr**20060531115550] [Silly typos in previous patch Marco Baringer **20060604141410] [Added :class attributes to all the form elements Marco Baringer **20060604140146] [Allow for component-slot definition with :component nil Nathan Bird **20060508155758 This patch changes the way the component-class.component-sltos list is built. It should now be in the same order as the class-slots which is hopefully the same order they were defined in. Additionally (the bigger reason) is so that slots that were declared with ':component nil' are marked as being component-slots but are left unbound. ] [Bind swank::*sldb-quit-restart* to 'fail-miserably Nathan Bird **20060531193531 Now when the slime debug buffer pops up while handling a web request, 'q' (sldb-quit) will cause the 'fail-miserably restart to be invoked. ] [fixing logging message typo Nathan Bird **20060531155026] [made the remove component :after be correctly specialized Russ Tyndall **20060529222215] [added pass through for optional args in read client string Russ Tyndall **20060525223940] [made it correctly out put human number strings rather than lisp number strings (aka no more 1.23d0) Russ Tyndall **20060517164149] [provide #'meta-refresh Nathan Bird **20060529215502 Cause a meta-refresh (a freshly got (GET) url) at this point. This is useful in order to have a GET url after a form POST's actions have completed running. The user can then refresh to his heart's content. ] [Adding child-components export Nathan Bird **20060508161431] [Add a child-components function Nathan Bird **20060508160149] [Export ucw::get-header Marco Baringer **20060530233436] [Added render-option specialized on nil attila.lendvai at gmail.com**20060530213435] [Don't specialize slot-value-using-class on the value parameter Marco Baringer **20060530105600] [write-uri-sans-query needs to deal with 'special' characters in the query-part Marco Baringer **20060529182043] [Added logging statements which report the action being evaluated. Marco Baringer **20060529080637] [Add "_" prefix to all ucw defined query parameters. Marco Baringer **20060529072846 This helps aliviate (but does not completly remove) the probablitily of a ucw defined parameter conflicting with a user defined parameter. I'll admit that the odds of one of ucw's randomly defined parameter names being the same as a user defined parameter name are slim, but when it does happen it's a once-every-1000-totally-unreproducable-100%untractable error :( ] [Implement radio-button widget Marco Baringer **20060529072632] [Tiny doc fix attila.lendvai at gmail.com**20060525225601] [Added remove-component to container attila.lendvai at gmail.com**20060523154055] [Set arnesi:*warn-undefined* to T in the start.lisp script Marco Baringer **20060526192721] [Fix erroneous evaluation bug in ucw-tags.lisp Marco Baringer **20060526192234 the code which checked for the precesne of an action parameter in a **20060514233614 To simplify things, the two systems used by bin/ucwctl are merged into the general `:ucw' one. As a side-effect, etc/start.lisp now loads the `*ucw-config-file*' when present or set the `*ucw-systems*' and `*ucw-applications*' variables. http://common-lisp.net/pipermail/bese-devel/2006-May/002122.html ] [Export ucw:is-an-integer-validator. Maciek Pasternacki **20060514232653] [Add message slot to validator class to contain an error message. Maciek Pasternacki **20060514232631] [switch from bare-bones dojo to ajax edition. To fix dependency errors where ucw expects the dojo.html namespace or whatever you want to call it to be present. cjstuij at gmail.com**20060510220528] [Read-from-client-string Nathan Bird **20060430215547 Useful for reading data from questionable origins where *read-eval* needs to be false. ] [Indentation fixup in tabbed-pane.lisp Marco Baringer **20060509102104] [Minor refactoring in container.lisp Marco Baringer **20060509102050] [Mention the difference between (setf application.dispathers) and (setf (slot-value app 'dispatchers)) in the docstring Marco Baringer **20060509101051] [Add a **20060506233602 **20060504233324] [INCOMPATIBLE CHANGE: add NET-TELENT-DATE dependency, send out Date: header, make SERVE-FILE cache-friendly (use Date:, Last-Modified:, Expires: and If-Modified-Since: headers). Maciek Pasternacki **20060503013844] [Don't send headers set to NIL (especially Content-Length:) in response. Maciek Pasternacki **20060503013648] [New function (delete-header message header-name). Maciek Pasternacki **20060503011904] [Don't send body if HTTP method is HEAD. Maciek Pasternacki **20060502222010] [Save HTTP method of request as string. Maciek Pasternacki **20060502221955] [Initform for (request response). Maciek Pasternacki **20060502221939] [Include in httpd response a request associated with it. Maciek Pasternacki **20060502221158] [changed docs to get up to date and add some info cjstuij at gmail.com**20060503094055] [Added send-redirect function. Marco Baringer **20060501154250 send-redirect does what redirect-component's render method did but it's usable from a simple-dispatcher (or anywhere else we don't have ucw's component context machinery). ] [Use dolist*, not dolist, in tabbed-pane's render method. Marco Baringer **20060501135314] [Using (when (whatever) T) is weird, use (whatever) instead Marco Baringer **20060501135000] [Minor indentation/whitespace fixups in src/components/form.lisp Marco Baringer **20060501134849] [make-with-dummy-request-nicer cjstuij at gmail.com**20060501001756] [tabbed-pane-makeover - tabbed panes are now wrapped in divs in stead of a table, for more design flexibility. Is no longer tied to a tal file. cjstuij at gmail.com**20060430233920] [Removing integer-range-validator, use number-range-validator instead. Nathan Bird **20060428165829] [the value of a number-field should be nil, not 0, if nothing was entered. Nathan Bird **20060428164949] [bin/ucwctl: allow a custom ucwctl.conf via -u|--ucwctl-file Luca Capello **20060501110031 This adds the possibility to specify a different ucwctl.conf file instead of the default /etc/ucw/ucwctl.conf. Moreover, by default ucwctl now reads ~/.ucw/ucwctl.conf it it exists, overriding the values in the general /etc/ucw/ucwctl.conf, and the same happens if the ucwctl.conf is specified via the command line option. All command line options override the values present in any ucwctl.conf files. The order is the following: 1) /etc/ucw/ucwctl.conf (if it exists) 2) ~/.ucw/ucwctl.conf (if it exists) 3) -u|--ucwctl-file (if specified, exit if it cannot be read) 4) command line options A deeper discussion is available at: http://common-lisp.net/pipermail/bese-devel/2006-April/001932.html http://common-lisp.net/pipermail/bese-devel/2006-April/001961.html ] [In the phone and email validators instead of defining a new slot we just use the :default-initargs class option Marco Baringer **20060428103114] [Adding documentation to form.lisp Nathan Bird **20060428023256] [Rearranging file contents to reduce style-warnings Nathan Bird **20060428022511] [Implementing value-validators Nathan Bird **20060428020403 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. ] [Expanded the forms example to include a number-field and number-range-validated field. Nathan Bird **20060428014551] [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 russ at acceleration.net**20060425154947] [added regex exports russ at acceleration.net**20060424225714] [Comment fixup Nathan Bird **20060427173259] [Added missing id param that got lost in my **20060425145623] Patch bundle hash: e995ae0eaa9cd7ca335aa746840ca1b45a396741 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From attila.lendvai at gmail.com Mon Jun 19 13:47:03 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Mon, 19 Jun 2006 15:47:03 +0200 Subject: [Bese-devel] WARNING: darcs pull currently needs user interaction due to a darcs bug Message-ID: hi! darcs have a bug when pulling patches with directory renames. when it tries to rename the i18n dir to l10n it tries to delete the i18n dir. if you have some extra user files in there then the deletion will fail and leave your local tree with half of the patch applied. you need to 'darcs revert' and delete the dir by hand. if you have local changes then it's a real headache, so create a backup of your repo before pulling. - attila (alias 101 on irc &no 'its not lisp code :) From marijnh at gmail.com Tue Jun 20 12:50:40 2006 From: marijnh at gmail.com (Marijn Haverbeke) Date: Tue, 20 Jun 2006 14:50:40 +0200 Subject: [Bese-devel] per-application.js Message-ID: Hi, I was looking at the per-application-javascript.lisp file, and I wondered what it is for. Wouldn't per-application javascript be something you add in your own application, instead of modifying a file in the UCW source tree? But the reason I was looking at that file in the first place is that I was getting mysterious errors whenever I handled a request: 13:54 UCW.BACKEND/+ERROR+: Error while shutdown'ing response: #. 13:54 UCW.BACKEND/+ERROR+: Error while shutdown'ing response: #. This is with mod-lisp as a backend, and after digging for a bit I figured out this was because mod-lisp-send-headers ran across a header that didn't have a value, when handling a request for the per-application.js file. The offending header is a "Content-Length" one, it appears in the headers of the response, but does not have a value (or a value of nil). I'm puzzled about where this header comes from, especially since mod-lisp-send-headers seems to have its own functionality for adding the Content-Length header. What could this be? By the way, the patch to select-fields I sent yesterday arrive for anybody? I couldn't see it in the archive yet. Maybe messages with an attachment have to be approved first? Anyway, let me know if I should resend it. I put a lot of love into that patch so I wouldn't want it to be lost :P Marijn -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.lendvai at gmail.com Tue Jun 20 13:06:21 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Tue, 20 Jun 2006 15:06:21 +0200 Subject: [Bese-devel] per-application.js In-Reply-To: References: Message-ID: > I was looking at the per-application-javascript.lisp file, and I wondered > what it is for. Wouldn't per-application javascript be something you add in > your own application, instead of modifying a file in the UCW source tree? check out this file in the ajax branch to get an idea what should go there... > But the reason I was looking at that file in the first place is that I was > getting mysterious errors whenever I handled a request: > > 13:54 UCW.BACKEND/+ERROR+: Error while shutdown'ing response: # {AD43BA1}>. > 13:54 UCW.BACKEND/+ERROR+: Error while shutdown'ing response: # {AD4C141}>. this is either due to a recent dispatcher refactor or due to the fact that the file is empty in the dev branch. -- - attila (alias 101 on irc &no 'its not lisp code :) From marijnh at gmail.com Tue Jun 20 13:28:35 2006 From: marijnh at gmail.com (Marijn Haverbeke) Date: Tue, 20 Jun 2006 15:28:35 +0200 Subject: [Bese-devel] per-application.js In-Reply-To: References: Message-ID: (Oops, I keep replying to single people instead of list, sorry Attila for double mail.) On 6/20/06, Attila Lendvai wrote: > > this is either due to a recent dispatcher refactor or due to the fact > that the file is empty in the dev branch. Making it non-empty didn't solve the problem though. All code that I can find that might change the Content-Length headers uses functions that shouldn't return nil. I'm stumped! Marijn -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.lendvai at gmail.com Tue Jun 20 13:58:22 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Tue, 20 Jun 2006 15:58:22 +0200 Subject: [Bese-devel] per-application.js In-Reply-To: References: Message-ID: > > this is either due to a recent dispatcher refactor or due to the fact > > that the file is empty in the dev branch. > > Making it non-empty didn't solve the problem though. All code that I can > find that might change the Content-Length headers uses functions that > shouldn't return nil. I'm stumped! pushed something that may fix it. could you please check it? -- - attila (alias 101 on irc &no 'its not lisp code :) From attila.lendvai at gmail.com Tue Jun 20 19:34:58 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Tue, 20 Jun 2006 21:34:58 +0200 Subject: [Bese-devel] per-application.js In-Reply-To: References: Message-ID: > > Making it non-empty didn't solve the problem though. All code that I can > > find that might change the Content-Length headers uses functions that > > shouldn't return nil. I'm stumped! > > pushed something that may fix it. could you please check it? as usual when you are in the middle of a refactoring and quickly push something without testing then no matter how trivial it is, most of the time it'll break stuff... but the dev branch should have a fix for this now. -- - attila (alias 101 on irc &no 'its not lisp code :) From pupeno at pupeno.com Wed Jun 21 00:27:32 2006 From: pupeno at pupeno.com (Pupeno) Date: Wed, 21 Jun 2006 02:27:32 +0200 Subject: [Bese-devel] Forms, how to make them Message-ID: <1150849652.26761.9.camel@ulab.pupeno.com> Hello, I have made a simple component with a some fields and now I want it to be a form, I've tried two ways which lead to different problems. In-CL markup, so I build the form like: (<:p (<:label "Name: " (render (account-name form)))) (<:p (<:label "Email address: " (render (account-email form)))) (<:p (<:label "Password: " (render (account-password form))))) Now, for example, how do I put an "accesskey" parameter to the generated input elements ? I am ok with automatically generated ids and names, but, do they have to be randomly generated ? It breaks the useful browser feature of auto-completation. Then I tried using TAL (with which I am confortable since my days as a Zope developer), but there, how do I generate the input elements ? and/or can I write them myself (to have the right names and the right parameters, like "account-name" and "n" for the first field in the previous example) ? Is it possible to still have all that javascript voodoo still in place ? Thanks. -- Pupeno http://pupeno.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From dbeauchesne at gmail.com Wed Jun 21 10:59:03 2006 From: dbeauchesne at gmail.com (Dan Beauchesne) Date: Wed, 21 Jun 2006 19:59:03 +0900 Subject: [Bese-devel] name conflict with arnesi\iterate WHILE and UNTIL, and compile-op error on request-error-loop.lisp Message-ID: Hi list, This is with the latest ucw_dev, arnesi, parenscript, and yaclml, and with SBCL 0.9.13.47. While loading "start.lisp", there is a name conflict with WHILE and UNTIL, possibly from here? http://www.uncommon-web.com/darcsweb/darcsweb.cgi?r=arnesi_dev;a=commit;h=20060620125308-887f0-5b6eac1c3cb2281c37775e3613852843e455e0cf.gz After going through SBCL's resolve conflict deal, there is a compile-op error on rerl/request-error-loop.lisp, which has been attached as it is rather long. Thanks guys, -- --- Dan Beauchesne -------------- next part -------------- A non-text attachment was scrubbed... Name: request-error-loop.error Type: application/octet-stream Size: 6869 bytes Desc: not available URL: From dbeauchesne at gmail.com Tue Jun 20 18:05:15 2006 From: dbeauchesne at gmail.com (Dan Beauchesne) Date: 21 Jun 2006 03:05:15 +0900 Subject: [Bese-devel] new WHILE and UNTIL in arnesi conflict with iterates', and request-loop-error.lisp compile-op error Message-ID: <87psh3n1no.fsf@localhost.localdomain> Hi list, Latest ucw_dev and dependencies, sbcl 0.9.13.43, while loading "start.lisp", firstly I get a name confliction between WHILE and UNTIL in iterate, and WHILE and UNTIL in arnesi. Maybe this? http://www.uncommon-web.com/darcsweb/darcsweb.cgi?r=arnesi_dev;a=commitdiff;h=20060620125308-887f0-5b6eac1c3cb2281c37775e3613852843e455e0cf.gz If I go through SBCL's RESOLVE CONFLICT deal things go fine until I get a compile op error on request-loop-error.lisp. It's quite long so I attached the output. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- Thanks, -- Dan Beauchesne dbeauchesne -at- gmail -dot- com From pupeno at pupeno.com Wed Jun 21 12:35:10 2006 From: pupeno at pupeno.com (Pupeno) Date: Wed, 21 Jun 2006 14:35:10 +0200 Subject: [Bese-devel] Forms validation and a possible patch. Message-ID: <1150893310.30377.6.camel@ulab.pupeno.com> Hello, I am writting the code to validate a form, taking from forms.lisp (the example) I wrote the following (which generates a more user friendly set of messages): (flet ((push-message-unless-valid (field name) (multiple-value-bind (validp failed-validators) (validp field) (unless validp (dolist (failed-validator failed-validators) (push (list "error" (format nil "~A ~A" name (cond ((typep failed-validator 'not-empty-validator) "should not be empty.") ((typep failed-validator 'length-validator) (format nil "is too short. It should be at least ~a letters long." (min-length failed-validator))) (t "is not valid.")))) (messages form))))))) (push-message-unless-valid (account-name form) "Your name") (push-message-unless-valid (account-email form) "Your email") (push-message-unless-valid (account-password form) "Your password") Basically the difference is that I don't print the class of the validator that failed but I dispatch on it generating a friendly message (the cond there). Is that a good way to do it ? Is there a better ? Now, to be able to generate the message "Your password is too short. It should be at least 6 letters long." I needed to export min-length from ucw, would you consider that a good thing ? I also exported max-length while I was at it. The patch is attached. -- Pupeno http://pupeno.com PS: Note that I am working with the latest box and not the latest... just to avoid problems. But it shouldn't be a problem for this patch. -------------- next part -------------- New patches: [Export min and max -length for the length-validator. Jos? Pablo Ezequiel "Pupeno" Fern?ndez Silva **20060621122848] { hunk ./src/packages.lisp 186 + #:min-length + #:max-length } Context: [(setf container.current-component) returns t when the set actually happened attila.lendvai at gmail.com**20060606195958] [Fix dynamic forms example delete attila.lendvai at gmail.com**20060604201256] [Split ucw.css and examples.css attila.lendvai at gmail.com**20060604200705] [Added child-components to container, WARNING: small api change attila.lendvai at gmail.com**20060604185229 In the process renamed the :pred kayword argument to :predicate ] [Doc/comment fixes attila.lendvai at gmail.com**20060604185138] [Add typecheck to s-c s-v-u-c and also set the parent slot attila.lendvai at gmail.com**20060604172617] [Export get-paremeter and map-parameters Marco Baringer **20060604171847] [When adding the ucw-form-field-invalid class remeber to remove the ucw-form-field-valid class (Patch by: Marijn Haverbeke ) Marco Baringer **20060604171146] [- secure-application#exit-user is broken due to removal of find-entry-point. evrim at core.gen.tr**20060531115550] [Silly typos in previous patch Marco Baringer **20060604141410] [Added :class attributes to all the form elements Marco Baringer **20060604140146] [Allow for component-slot definition with :component nil Nathan Bird **20060508155758 This patch changes the way the component-class.component-sltos list is built. It should now be in the same order as the class-slots which is hopefully the same order they were defined in. Additionally (the bigger reason) is so that slots that were declared with ':component nil' are marked as being component-slots but are left unbound. ] [Bind swank::*sldb-quit-restart* to 'fail-miserably Nathan Bird **20060531193531 Now when the slime debug buffer pops up while handling a web request, 'q' (sldb-quit) will cause the 'fail-miserably restart to be invoked. ] [fixing logging message typo Nathan Bird **20060531155026] [made the remove component :after be correctly specialized Russ Tyndall **20060529222215] [added pass through for optional args in read client string Russ Tyndall **20060525223940] [made it correctly out put human number strings rather than lisp number strings (aka no more 1.23d0) Russ Tyndall **20060517164149] [provide #'meta-refresh Nathan Bird **20060529215502 Cause a meta-refresh (a freshly got (GET) url) at this point. This is useful in order to have a GET url after a form POST's actions have completed running. The user can then refresh to his heart's content. ] [Adding child-components export Nathan Bird **20060508161431] [Add a child-components function Nathan Bird **20060508160149] [Export ucw::get-header Marco Baringer **20060530233436] [Added render-option specialized on nil attila.lendvai at gmail.com**20060530213435] [Don't specialize slot-value-using-class on the value parameter Marco Baringer **20060530105600] [write-uri-sans-query needs to deal with 'special' characters in the query-part Marco Baringer **20060529182043] [Added logging statements which report the action being evaluated. Marco Baringer **20060529080637] [Add "_" prefix to all ucw defined query parameters. Marco Baringer **20060529072846 This helps aliviate (but does not completly remove) the probablitily of a ucw defined parameter conflicting with a user defined parameter. I'll admit that the odds of one of ucw's randomly defined parameter names being the same as a user defined parameter name are slim, but when it does happen it's a once-every-1000-totally-unreproducable-100%untractable error :( ] [Implement radio-button widget Marco Baringer **20060529072632] [Tiny doc fix attila.lendvai at gmail.com**20060525225601] [Added remove-component to container attila.lendvai at gmail.com**20060523154055] [Set arnesi:*warn-undefined* to T in the start.lisp script Marco Baringer **20060526192721] [Fix erroneous evaluation bug in ucw-tags.lisp Marco Baringer **20060526192234 the code which checked for the precesne of an action parameter in a **20060514233614 To simplify things, the two systems used by bin/ucwctl are merged into the general `:ucw' one. As a side-effect, etc/start.lisp now loads the `*ucw-config-file*' when present or set the `*ucw-systems*' and `*ucw-applications*' variables. http://common-lisp.net/pipermail/bese-devel/2006-May/002122.html ] [Export ucw:is-an-integer-validator. Maciek Pasternacki **20060514232653] [Add message slot to validator class to contain an error message. Maciek Pasternacki **20060514232631] [switch from bare-bones dojo to ajax edition. To fix dependency errors where ucw expects the dojo.html namespace or whatever you want to call it to be present. cjstuij at gmail.com**20060510220528] [Read-from-client-string Nathan Bird **20060430215547 Useful for reading data from questionable origins where *read-eval* needs to be false. ] [Indentation fixup in tabbed-pane.lisp Marco Baringer **20060509102104] [Minor refactoring in container.lisp Marco Baringer **20060509102050] [Mention the difference between (setf application.dispathers) and (setf (slot-value app 'dispatchers)) in the docstring Marco Baringer **20060509101051] [Add a **20060506233602 **20060504233324] [INCOMPATIBLE CHANGE: add NET-TELENT-DATE dependency, send out Date: header, make SERVE-FILE cache-friendly (use Date:, Last-Modified:, Expires: and If-Modified-Since: headers). Maciek Pasternacki **20060503013844] [Don't send headers set to NIL (especially Content-Length:) in response. Maciek Pasternacki **20060503013648] [New function (delete-header message header-name). Maciek Pasternacki **20060503011904] [Don't send body if HTTP method is HEAD. Maciek Pasternacki **20060502222010] [Save HTTP method of request as string. Maciek Pasternacki **20060502221955] [Initform for (request response). Maciek Pasternacki **20060502221939] [Include in httpd response a request associated with it. Maciek Pasternacki **20060502221158] [changed docs to get up to date and add some info cjstuij at gmail.com**20060503094055] [Added send-redirect function. Marco Baringer **20060501154250 send-redirect does what redirect-component's render method did but it's usable from a simple-dispatcher (or anywhere else we don't have ucw's component context machinery). ] [Use dolist*, not dolist, in tabbed-pane's render method. Marco Baringer **20060501135314] [Using (when (whatever) T) is weird, use (whatever) instead Marco Baringer **20060501135000] [Minor indentation/whitespace fixups in src/components/form.lisp Marco Baringer **20060501134849] [make-with-dummy-request-nicer cjstuij at gmail.com**20060501001756] [tabbed-pane-makeover - tabbed panes are now wrapped in divs in stead of a table, for more design flexibility. Is no longer tied to a tal file. cjstuij at gmail.com**20060430233920] [Removing integer-range-validator, use number-range-validator instead. Nathan Bird **20060428165829] [the value of a number-field should be nil, not 0, if nothing was entered. Nathan Bird **20060428164949] [bin/ucwctl: allow a custom ucwctl.conf via -u|--ucwctl-file Luca Capello **20060501110031 This adds the possibility to specify a different ucwctl.conf file instead of the default /etc/ucw/ucwctl.conf. Moreover, by default ucwctl now reads ~/.ucw/ucwctl.conf it it exists, overriding the values in the general /etc/ucw/ucwctl.conf, and the same happens if the ucwctl.conf is specified via the command line option. All command line options override the values present in any ucwctl.conf files. The order is the following: 1) /etc/ucw/ucwctl.conf (if it exists) 2) ~/.ucw/ucwctl.conf (if it exists) 3) -u|--ucwctl-file (if specified, exit if it cannot be read) 4) command line options A deeper discussion is available at: http://common-lisp.net/pipermail/bese-devel/2006-April/001932.html http://common-lisp.net/pipermail/bese-devel/2006-April/001961.html ] [In the phone and email validators instead of defining a new slot we just use the :default-initargs class option Marco Baringer **20060428103114] [Adding documentation to form.lisp Nathan Bird **20060428023256] [Rearranging file contents to reduce style-warnings Nathan Bird **20060428022511] [Implementing value-validators Nathan Bird **20060428020403 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. ] [Expanded the forms example to include a number-field and number-range-validated field. Nathan Bird **20060428014551] [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 russ at acceleration.net**20060425154947] [added regex exports russ at acceleration.net**20060424225714] [Comment fixup Nathan Bird **20060427173259] [Added missing id param that got lost in my **20060425145623] Patch bundle hash: db9f4853787de8751cbaaa41c021b24792ef4312 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From pupeno at pupeno.com Wed Jun 21 12:51:41 2006 From: pupeno at pupeno.com (Pupeno) Date: Wed, 21 Jun 2006 14:51:41 +0200 Subject: [Bese-devel] [PATCH] Missplaced comments on forms.lisp Message-ID: <1150894301.30377.10.camel@ulab.pupeno.com> It seems the code was updated and the comments didn't, so, I fixed them. -- Pupeno http://pupeno.com -------------- next part -------------- A non-text attachment was scrubbed... Name: comment.patch Type: text/x-patch Size: 14266 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From marijnh at gmail.com Mon Jun 19 10:21:16 2006 From: marijnh at gmail.com (Marijn Haverbeke) Date: Mon, 19 Jun 2006 12:21:16 +0200 Subject: [Bese-devel] Patch for select fields Message-ID: Attached is a patch that makes some rather big changes to the select fields in components/form.lisp, a small one to checkbox fields, and adds hidden fields. Because it seems there is little animo for overhauling the make-new-callback system, and the ucw_ajax branch uses hidden fields for callbacks that are allways needed, I decided to just hack stuff with hidden fields. Later, these hacks can be combined with the callback mechanisms in ucw_ajax. Changes to the select-field classes: - They support the :multiple initarg. When this is true, the field will allow multiple options to be selected, and its value and client-value will be lists instead of single values. - For alist, plist and hash fields, the interpretation of the data-sets has changed. Basically, I reversed it, because this appears to make much more sense to me, but this is debatable and if someone has a good reason why it should be the other way I'd like to hear it. The way they work in my patch is that they map lisp values to text labels. The select fields will show the labels, and return the lisp values if you call value on them. - Setting the value of mapping select fields now work like you'd expect it - you give it a value of the kind that you would get if you call value, instead of giving it a text label. - Select fields no longer store their data-set. They transform it into a data-map that maps client values, values, and text labels to each other, and store that. - There's a :traverse-func initarg for the select fields classes that allows you to specify the way the data-set is mapped to value/label pairs. This is used to implement plist, alist and hash selects, and can be used to do fancier stuff. There is now a class hidden-field. It works as you'd expect it to. The checkbox-field class no longer resets itself every time it is rendered, but instead uses the trick with the hidden input to call a function that sets it to the right value after it is submitted. I added a function next-anon-field-name that generates unique field names, because the hidden-input trick requires some kind of name for the element even when none is specified. Radio buttons also use this function now - they used random strings before and a comment indicated that the person who put that there didn't think this was a very good approach either. Bye, Marijn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: select-field-patch Type: application/octet-stream Size: 34117 bytes Desc: not available URL: From pupeno at pupeno.com Wed Jun 21 13:18:49 2006 From: pupeno at pupeno.com (Pupeno) Date: Wed, 21 Jun 2006 15:18:49 +0200 Subject: [Bese-devel] [PATCH] Be able to specify accesskey for input elemnts. Message-ID: <1150895929.30377.14.camel@ulab.pupeno.com> Well, that. -- Pupeno http://pupeno.com -------------- next part -------------- A non-text attachment was scrubbed... Name: accesskey.patch Type: text/x-patch Size: 14553 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From pupeno at pupeno.com Wed Jun 21 13:30:48 2006 From: pupeno at pupeno.com (Pupeno) Date: Wed, 21 Jun 2006 15:30:48 +0200 Subject: [Bese-devel] [PATCH] Be able to specify accesskey for input elemnts. In-Reply-To: <1150895929.30377.14.camel@ulab.pupeno.com> References: <1150895929.30377.14.camel@ulab.pupeno.com> Message-ID: <1150896649.30377.17.camel@ulab.pupeno.com> I forgot that there are other input fields that text that also deserve an accesskey. New patch that makes obsolete the previous one. One field that still doesn't get accesskey is the selection. That is, I believe, because yaclml is missing the particular code. I've commented that on the source code itself. On Wed, 2006-06-21 at 15:18 +0200, Pupeno wrote: > Well, that. > _______________________________________________ > bese-devel mailing list > bese-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel -- Pupeno http://pupeno.com -------------- next part -------------- A non-text attachment was scrubbed... Name: accesskey.patch Type: text/x-patch Size: 15404 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From pupeno at pupeno.com Wed Jun 21 22:22:54 2006 From: pupeno at pupeno.com (Pupeno) Date: Thu, 22 Jun 2006 00:22:54 +0200 Subject: [Bese-devel] Line breaks Message-ID: <1150928574.2930.4.camel@ulab.pupeno.com> Hello, The output of UCW looks like this: Hosting Compass There are many line breaks in odd places. I understand that it may solve some problems putting them there, but, are they valid ? Whether they are valid or not, it confuses the validator (http://validator.w3.org) into reading instead of and then it claims it is invalid XML. Is there anything that can be done to avoid those line jumps (even if it means outputing one long line) ? And if it is a valid XML, then I'll post a bug report for the validator. Thanks. -- Pupeno http://pupeno.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From ctdean at sokitomi.com Wed Jun 21 23:01:06 2006 From: ctdean at sokitomi.com (Chris Dean) Date: Wed, 21 Jun 2006 16:01:06 -0700 Subject: [Bese-devel] Line breaks In-Reply-To: <1150928574.2930.4.camel@ulab.pupeno.com> (pupeno@pupeno.com's message of "Thu, 22 Jun 2006 00:22:54 +0200") References: <1150928574.2930.4.camel@ulab.pupeno.com> Message-ID: Pupeno writes: > Is there anything that can be done to avoid those line jumps (even > if it means outputing one long line) ? You can set *yaclml-indent* to control this. Note that it must be set when the code is compiled: "When T (must be set while compiling yaclml code) the generated HTML is indented." Cheers, Chris Dean From mbaringer at common-lisp.net Thu Jun 22 04:00:09 2006 From: mbaringer at common-lisp.net (Marco Baringer) Date: Thu, 22 Jun 2006 00:00:09 -0400 (EDT) Subject: [Bese-devel] New patches to arnesi_dev: 21-Jun-2006 Message-ID: <20060622040009.906E048146@common-lisp.net> Wed Jun 21 11:38:19 EDT 2006 Marco Baringer * Don't export WHILE and UNTIL. Arnesi if often used in conjunction with iterate, which also exports the symbols while and until. If you want while and until just do arnesi::while or import the symbols manually. M ./src/packages.lisp -2 Wed Jun 21 06:42:45 EDT 2006 Marco Baringer * io.lisp depends on string.lisp M ./arnesi.asd -1 +1 Wed Jun 21 06:42:04 EDT 2006 Marco Baringer * Updated read-string-from-file's docstring M ./src/io.lisp -3 +11 Wed Jun 21 06:23:33 EDT 2006 Marco Baringer * Added copy-array M ./src/packages.lisp +1 M ./src/sequence.lisp +16 An updated tarball of arnesi_dev's source can be downloaded here: http://common-lisp.net/project/bese/tarballs/arnesi_dev-20060621.tar.gz Darcsweb URL: http://uncommon-web.com/darcsweb/darcsweb.cgi?r=arnesi_dev;a=summary From mbaringer at common-lisp.net Thu Jun 22 04:15:06 2006 From: mbaringer at common-lisp.net (Marco Baringer) Date: Thu, 22 Jun 2006 00:15:06 -0400 (EDT) Subject: [Bese-devel] New patches to yaclml: 21-Jun-2006 Message-ID: <20060622041506.90FEB56018@common-lisp.net> Wed Jun 21 10:13:48 EDT 2006 Marco Baringer * Reindent packages.lisp M ./src/packages.lisp -37 +39 Wed Jun 21 10:13:34 EDT 2006 Marco Baringer * Implement with-yaclml-output-to-string in terms of with-unique-names; avoid variable capture M ./src/yaclml.lisp -4 +4 Wed Jun 21 10:02:42 EDT 2006 Luis Oliveira * Normalize tabs to spaces in packages.lisp M! ./src/packages.lisp -44 +48 Wed Jun 21 10:02:13 EDT 2006 Luis Oliveira * Fix conflict between arnesi and iterate. M ./src/packages.lisp +1 An updated tarball of yaclml's source can be downloaded here: http://common-lisp.net/project/bese/tarballs/yaclml-20060621.tar.gz Darcsweb URL: http://uncommon-web.com/darcsweb/darcsweb.cgi?r=yaclml;a=summary From mange at freemail.hu Thu Jun 22 08:51:18 2006 From: mange at freemail.hu (Magnus Henoch) Date: Thu, 22 Jun 2006 10:51:18 +0200 Subject: [Bese-devel] Line breaks In-Reply-To: <1150928574.2930.4.camel@ulab.pupeno.com> (pupeno@pupeno.com's message of "Thu, 22 Jun 2006 00:22:54 +0200") References: <1150928574.2930.4.camel@ulab.pupeno.com> Message-ID: <87ejxhbmk9.fsf@freemail.hu> Pupeno writes: > And if it is a valid XML, then I'll post a bug report for the validator. >From : Tags for Empty Elements [44] EmptyElemTag ::= '<' Name (S Attribute)* S? '/>' [WFC: Unique Att Spec] where S stands for whitespace (specifically, (#x20 | #x9 | #xD | #xA)+). So this usage seems to be valid, and the validator is overzealous. Magnus From mb at bese.it Thu Jun 22 11:59:24 2006 From: mb at bese.it (Marco Baringer) Date: Thu, 22 Jun 2006 13:59:24 +0200 Subject: [Bese-devel] Re: Forms, how to make them References: <1150849652.26761.9.camel@ulab.pupeno.com> Message-ID: Pupeno writes: > Hello, > I have made a simple component with a some fields and now I want it to > be a form, I've tried two ways which lead to different problems. > In-CL markup, so I build the form like: > > (<:p (<:label "Name: " (render (account-name form)))) > (<:p (<:label "Email address: " (render (account-email form)))) > (<:p (<:label "Password: " (render (account-password form))))) > > Now, for example, how do I put an "accesskey" parameter to the generated > input elements ? form elements don't currenty support the accesskey parameter, adding them is an excellent idea. > I am ok with automatically generated ids and names, but, do they have to > be randomly generated ? It breaks the useful browser feature of > auto-completation. the ids can be changed with the :dom-id initarg (slot defined by the html-element class) and the name can be set with the :name initarg (slot defined by the generic-form-element). > Then I tried using TAL (with which I am confortable since my days as a > Zope developer), but there, how do I generate the input elements ? > and/or can I write them myself (to have the right names and the right > parameters, like "account-name" and "n" for the first field in the > previous example) ? Is it possible to still have all that javascript > voodoo still in place ? the javascript vodoo is generated by the form elements only, if you don't use the form elements you don't get the javascript, sorry. -- -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 Thu Jun 22 12:04:49 2006 From: mb at bese.it (Marco Baringer) Date: Thu, 22 Jun 2006 14:04:49 +0200 Subject: [Bese-devel] Re: [PATCH] Missplaced comments on forms.lisp References: <1150894301.30377.10.camel@ulab.pupeno.com> Message-ID: Pupeno writes: > It seems the code was updated and the comments didn't, so, I fixed them. applied. thanks. -- -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 Thu Jun 22 12:04:09 2006 From: mb at bese.it (Marco Baringer) Date: Thu, 22 Jun 2006 14:04:09 +0200 Subject: [Bese-devel] Re: Forms validation and a possible patch. References: <1150893310.30377.6.camel@ulab.pupeno.com> Message-ID: Pupeno writes: > (flet ((push-message-unless-valid (field name) > (multiple-value-bind (validp failed-validators) > (validp field) > (unless validp > (dolist (failed-validator failed-validators) > (push (list "error" > (format nil "~A ~A" name > (cond > ((typep failed-validator 'not-empty-validator) > "should not be empty.") > ((typep failed-validator 'length-validator) > (format nil "is too short. It should be at least ~a letters > long." (min-length failed-validator))) > (t "is not valid.")))) > (messages form))))))) > (push-message-unless-valid (account-name form) "Your name") > (push-message-unless-valid (account-email form) "Your email") > (push-message-unless-valid (account-password form) "Your password") applied somethnig along these lines. > Basically the difference is that I don't print the class of the > validator that failed but I dispatch on it generating a friendly message > (the cond there). nice idea, i'll apply something along these lines shortly > The patch is attached. applied. thanks. -- -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 dbeauchesne at gmail.com Fri Jun 23 01:04:37 2006 From: dbeauchesne at gmail.com (Dan Beauchesne) Date: 23 Jun 2006 10:04:37 +0900 Subject: [Bese-devel] new WHILE and UNTIL in arnesi conflict with iterates', and request-loop-error.lisp compile-op error In-Reply-To: <87psh3n1no.fsf@localhost.localdomain> References: <87psh3n1no.fsf@localhost.localdomain> Message-ID: <874pyc7kd6.fsf@localhost.localdomain> Hi list, Sorry about the dupe-- my mta reported an error, I thought it didn't get sent the first time. I noticed the WHILE and UNTIL problem was patched, and the new error is...: yaclml, arnesi, ucw_dev as of 10 minutes ago, SBCL 0.9.13.47. ; file: /home/dan/src/ucw_dev/src/control.lisp ; in: DEFMETHOD IT.BESE.UCW::MAKE-BACKEND ((EQL :ARANEIDA)) => IT.BESE.UCW::DEFAULT-URL IT.BESE.UCW::ARANEIDA-SERVER ; (IT.BESE.UCW::DEFAULT-URL IT.BESE.UCW::ARANEIDA-SERVER) ; ; caught STYLE-WARNING: ; undefined function: IT.BESE.UCW::DEFAULT-URL ; file: /home/dan/src/ucw_dev/src/rerl/standard-request-context.lisp ; in: ; DEFMETHOD IT.BESE.UCW::QUERY-PATH-SANS-PREFIX (IT.BESE.UCW::STANDARD-REQUEST-CONTEXT) ; (IT.BESE.UCW::MAKE-DISPLACED-ARRAY ; (IT.BESE.UCW::QUERY-PATH (IT.BESE.UCW:CONTEXT.REQUEST IT.BESE.UCW::CONTEXT)) ; (LENGTH ; (IT.BESE.UCW::APPLICATION.URL-PREFIX ; (IT.BESE.UCW::CONTEXT.APPLICATION IT.BESE.UCW::CONTEXT)))) ; ; caught STYLE-WARNING: ; undefined function: IT.BESE.UCW::MAKE-DISPLACED-ARRAY ; file: /home/dan/src/ucw_dev/src/rerl/standard-dispatcher.lisp ; in: ; DEFMETHOD IT.BESE.UCW::HANDLER-HANDLE (IT.BESE.UCW::PARENSCRIPT-HANDLER ; IT.BESE.UCW:STANDARD-APPLICATION ; IT.BESE.UCW::STANDARD-REQUEST-CONTEXT ; T) ; (IT.BESE.UCW:SERVE-SEQUENCE IT.BESE.UCW::CACHED-JAVASCRIPT ; :LAST-MODIFIED ; IT.BESE.UCW::LAST-COMPILED ; :CONTENT-TYPE ; "text/javascript") ; ; caught STYLE-WARNING: ; undefined function: IT.BESE.UCW:SERVE-SEQUENCE ; file: /home/dan/src/ucw_dev/src/components/form.lisp ; in: DEFMETHOD IT.BESE.UCW:RENDER (IT.BESE.UCW:CHECKBOX-FIELD) ; (IT.BESE.UCW::WIDGET-COMPONENT.CSS-CLASS IT.BESE.UCW::FIELD) ; ; caught STYLE-WARNING: ; undefined function: IT.BESE.UCW::WIDGET-COMPONENT.CSS-CLASS ; ; caught STYLE-WARNING: ; These functions are undefined: ; IT.BESE.UCW::DEFAULT-URL IT.BESE.UCW::MAKE-DISPLACED-ARRAY IT.BESE.UCW:SERVE-SEQUENCE IT.BESE.UCW::WIDGET-COMPONENT.CSS-CLASS ; ; compilation unit finished ; caught 13 STYLE-WARNING conditions ; printed 728 notes debugger invoked on a TYPE-ERROR in thread #: The value #P"/etc/ucw/applications.d/" is not of type SEQUENCE. Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. (LENGTH #P"/etc/ucw/applications.d/") 0] Hope this helps, -- Dan Beauchesne dbeauchesne -at- gmail -dot- com From mbaringer at common-lisp.net Fri Jun 23 04:30:09 2006 From: mbaringer at common-lisp.net (Marco Baringer) Date: Fri, 23 Jun 2006 00:30:09 -0400 (EDT) Subject: [Bese-devel] New patches to ucw_dev: 22-Jun-2006 Message-ID: <20060623043009.BF9E35601A@common-lisp.net> Thu Jun 22 08:37:35 EDT 2006 Marco Baringer * Merge conflicts with Pupeno's last patch M ./src/components/form.lisp -2 +13 Wed Jun 21 09:28:40 EDT 2006 Jos?? Pablo Ezequiel "Pupeno" Fern??ndez Silva * Be able to define accesskey in other input fields than text. M! ./src/components/form.lisp -8 +7 Wed Jun 21 09:16:57 EDT 2006 Jos?? Pablo Ezequiel "Pupeno" Fern??ndez Silva * Be able to specify accesskey for input elemnts. M! ./src/components/form.lisp -4 +3 Thu Jun 22 08:10:56 EDT 2006 Marco Baringer * Define shared-initialize :after, not a shared-initialize whose first form in (call-next-method) M ./src/rerl/standard-dispatcher.lisp -3 +3 Wed Jun 21 08:47:50 EDT 2006 Jos?? Pablo Ezequiel "Pupeno" Fern??ndez Silva * Re-place comments (email and regexp validator). M ./src/components/form.lisp -1 +3 Wed Jun 21 08:28:48 EDT 2006 Jos?? Pablo Ezequiel "Pupeno" Fern??ndez Silva * Export min and max -length for the length-validator. M ./src/packages.lisp +2 An updated tarball of ucw_dev's source can be downloaded here: http://common-lisp.net/project/ucw/tarballs/ucw_dev-20060622.tar.gz Darcsweb URL: http://uncommon-web.com/darcsweb/darcsweb.cgi?r=ucw_dev;a=summary From attila.lendvai at gmail.com Fri Jun 23 08:13:50 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Fri, 23 Jun 2006 10:13:50 +0200 Subject: [Bese-devel] new WHILE and UNTIL in arnesi conflict with iterates', and request-loop-error.lisp compile-op error In-Reply-To: <874pyc7kd6.fsf@localhost.localdomain> References: <87psh3n1no.fsf@localhost.localdomain> <874pyc7kd6.fsf@localhost.localdomain> Message-ID: > ; file: /home/dan/src/ucw_dev/src/control.lisp > ; in: DEFMETHOD IT.BESE.UCW::MAKE-BACKEND ((EQL :ARANEIDA)) => IT.BESE.UCW::DEFAULT-URL IT.BESE.UCW::ARANEIDA-SERVER > ; (IT.BESE.UCW::DEFAULT-URL IT.BESE.UCW::ARANEIDA-SERVER) these are probably due to the araneida backend lagging a little behind ucw. try httpd... -- - attila (alias 101 on irc &no 'its not lisp code :) From dbeauchesne at gmail.com Fri Jun 23 15:00:57 2006 From: dbeauchesne at gmail.com (Dan Beauchesne) Date: 24 Jun 2006 00:00:57 +0900 Subject: [Bese-devel] new WHILE and UNTIL in arnesi conflict with iterates', and request-loop-error.lisp compile-op error In-Reply-To: References: <87psh3n1no.fsf@localhost.localdomain> <874pyc7kd6.fsf@localhost.localdomain> Message-ID: <87ac83kjbq.fsf@localhost.localdomain> This is from a completely fresh "darcs get". I havn't modified default.lisp or anything else. "Attila Lendvai" writes: > > ; file: /home/dan/src/ucw_dev/src/control.lisp > > ; in: DEFMETHOD IT.BESE.UCW::MAKE-BACKEND ((EQL :ARANEIDA)) => IT.BESE.UCW::DEFAULT-URL IT.BESE.UCW::ARANEIDA-SERVER > > ; (IT.BESE.UCW::DEFAULT-URL IT.BESE.UCW::ARANEIDA-SERVER) > > these are probably due to the araneida backend lagging a little behind > ucw. try httpd... > > -- > - attila > > (alias 101 on irc &no 'its not lisp code :) > -- Dan Beauchesne dbeauchesne -at- gmail -dot- com From mbaringer at common-lisp.net Sat Jun 24 04:30:09 2006 From: mbaringer at common-lisp.net (Marco Baringer) Date: Sat, 24 Jun 2006 00:30:09 -0400 (EDT) Subject: [Bese-devel] New patches to ucw_dev: 23-Jun-2006 Message-ID: <20060624043009.B1B5B77006@common-lisp.net> Fri Jun 23 05:12:56 EDT 2006 attila.lendvai at gmail.com tagged 2006-06-23 An updated tarball of ucw_dev's source can be downloaded here: http://common-lisp.net/project/ucw/tarballs/ucw_dev-20060623.tar.gz Darcsweb URL: http://uncommon-web.com/darcsweb/darcsweb.cgi?r=ucw_dev;a=summary From evrim at core.gen.tr Sat Jun 24 10:16:07 2006 From: evrim at core.gen.tr (Evrim ULU) Date: Sat, 24 Jun 2006 13:16:07 +0300 Subject: [Bese-devel] ucw modular-application Message-ID: <449D10E7.9080809@core.gen.tr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I've finished new modular-application API and moved current featured applications to this API. Here is a short description: ;;;; * UCW Moduler Application API - This enables us to mix several ;;;; features of different application together like i18n & cookie. ;;;; Also, an end-user can define his/her own context mixin class to ;;;; provide a modular context which is crucial for real applications. The aim is to be able to use application features as mixins. Now one can create a cookie+l10n application via defining simple class like: (defclass my-cookie-and-l10n-application (modular-application cookie-session-application-module l10n-application-module) ()) A warning may be, there is no more a "secure-application-mixin". The name is changed to secure-application-module. Here is the changelog: Fri Jun 23 23:07:52 EEST 2006 evrim at core.gen.tr * cookie-session.lisp removed. moved to modular-applications. Shall I push this patch? (1/11) [ynWvpxqadjk], or ? for help: y Fri Jun 23 23:11:02 EEST 2006 evrim at core.gen.tr * secure-application.lisp removed. moved to modular-applications. Shall I push this patch? (2/11) [ynWvpxqadjk], or ? for help: y Fri Jun 23 23:16:34 EEST 2006 evrim at core.gen.tr * l10n.lisp removed. moved to modular-applications. Shall I push this patch? (3/11) [ynWvpxqadjk], or ? for help: y Sat Jun 24 11:34:52 EEST 2006 evrim at core.gen.tr * added src/rerl/modular-application direcorty. Shall I push this patch? (4/11) [ynWvpxqadjk], or ? for help: y Sat Jun 24 11:35:31 EEST 2006 evrim at core.gen.tr * fixed type in l10n-example -> *l10n-example-appication* Shall I push this patch? (5/11) [ynWvpxqadjk], or ? for help: y Sat Jun 24 12:20:32 EEST 2006 evrim at core.gen.tr * added LICENCE file. Shall I push this patch? (6/11) [ynWvpxqadjk], or ? for help: y Sat Jun 24 12:20:45 EEST 2006 evrim at core.gen.tr * cookie-module.lisp added. Shall I push this patch? (7/11) [ynWvpxqadjk], or ? for help: y Sat Jun 24 12:21:13 EEST 2006 evrim at core.gen.tr * added l10n-module.lisp Shall I push this patch? (8/11) [ynWvpxqadjk], or ? for help: y Sat Jun 24 12:21:54 EEST 2006 evrim at core.gen.tr * added modular-application.lisp which specifies modular applications. Shall I push this patch? (9/11) [ynWvpxqadjk], or ? for help: y Sat Jun 24 12:22:27 EEST 2006 evrim at core.gen.tr * added security-module.lisp Shall I push this patch? (10/11) [ynWvpxqadjk], or ? for help: y Sat Jun 24 12:22:37 EEST 2006 evrim at core.gen.tr * fixed asd file for modular-applications. Shall I push this patch? (11/11) [ynWvpxqadjk], or ? for help: y Finished applying... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEnRDnwzkKLGtRuHsRAvguAKDMlX03gvJeYdo9fewpOdwX4fOGowCguaQd +qYxoqT/e+fZ34st2IOjIhw= =8q+j -----END PGP SIGNATURE----- From evrim at core.gen.tr Sat Jun 24 22:47:17 2006 From: evrim at core.gen.tr (Evrim ULU) Date: Sun, 25 Jun 2006 01:47:17 +0300 Subject: [Bese-devel] ucw.asd Message-ID: <449DC0F5.3030700@core.gen.tr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Why not using :serial t instead of defining every dependency? evrim. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEncDzwzkKLGtRuHsRAj4xAJ955cIzFji7GZy4wDwj8xsXQXc+OACgqmXk IDI5nosqeNO6U+ap5Vo1ZMQ= =NQoc -----END PGP SIGNATURE----- From luismbo at gmail.com Sun Jun 25 01:17:52 2006 From: luismbo at gmail.com (=?utf-8?Q?Lu=C3=ADs?= Oliveira) Date: Sun, 25 Jun 2006 02:17:52 +0100 Subject: [Bese-devel] Re: ucw.asd References: <449DC0F5.3030700@core.gen.tr> Message-ID: Evrim ULU writes: > Why not using :serial t instead of defining every dependency? Because recompilations are faster that way. -- Lu?s Oliveira luismbo (@) gmail (.) com http://student.dei.uc.pt/~lmoliv/ From evrim at core.gen.tr Sun Jun 25 00:04:26 2006 From: evrim at core.gen.tr (Evrim ULU) Date: Sun, 25 Jun 2006 03:04:26 +0300 Subject: [Bese-devel] Re: ucw.asd In-Reply-To: References: <449DC0F5.3030700@core.gen.tr> Message-ID: <449DD30A.6040904@core.gen.tr> Lu?s Oliveira wrote: >Evrim ULU writes: > > >>Why not using :serial t instead of defining every dependency? >> >> >Because recompilations are faster that way. > > could you expand this more? didn't get why we constantly need to recompile whole ucw to consider speed as a problem. i'm favoring simplicity and readablity. evrim. From luismbo at gmail.com Sun Jun 25 02:34:32 2006 From: luismbo at gmail.com (=?utf-8?Q?Lu=C3=ADs?= Oliveira) Date: Sun, 25 Jun 2006 03:34:32 +0100 Subject: [Bese-devel] Re: ucw.asd References: <449DC0F5.3030700@core.gen.tr> <449DD30A.6040904@core.gen.tr> Message-ID: Evrim ULU writes: >>>Why not using :serial t instead of defining every dependency? >>Because recompilations are faster that way. >> > could you expand this more? didn't get why we constantly need to > recompile whole ucw to consider speed as a problem. i'm favoring > simplicity and readablity. That's the point. Specifying the dependencies between files avoids recompiling the whole UCW when a change is made to, say, just one file. ASDF will only recompile what depends on that file. It's a big win in large systems. Anyway, I guess it's up to the developer(s) to decide whether it's worth the trouble to specify the dependencies. -- Lu?s Oliveira luismbo (@) gmail (.) com http://student.dei.uc.pt/~lmoliv/ From mbaringer at common-lisp.net Sun Jun 25 04:30:08 2006 From: mbaringer at common-lisp.net (Marco Baringer) Date: Sun, 25 Jun 2006 00:30:08 -0400 (EDT) Subject: [Bese-devel] New patches to ucw_dev: 24-Jun-2006 Message-ID: <20060625043008.C42A83800B@common-lisp.net> Sat Jun 24 05:22:37 EDT 2006 evrim at core.gen.tr * fixed asd file for modular-applications. M ./ucw.asd -6 +13 Sat Jun 24 05:22:27 EDT 2006 evrim at core.gen.tr * added security-module.lisp A ./src/rerl/modular-application/security-module.lisp Sat Jun 24 05:21:54 EDT 2006 evrim at core.gen.tr * added modular-application.lisp which specifies modular applications. A ./src/rerl/modular-application/modular-application.lisp Sat Jun 24 05:21:13 EDT 2006 evrim at core.gen.tr * added l10n-module.lisp A ./src/rerl/modular-application/l10n-module.lisp Sat Jun 24 05:20:45 EDT 2006 evrim at core.gen.tr * cookie-module.lisp added. A ./src/rerl/modular-application/cookie-module.lisp Sat Jun 24 05:20:32 EDT 2006 evrim at core.gen.tr * added LICENCE file. A ./LICENCE Sat Jun 24 04:35:31 EDT 2006 evrim at core.gen.tr * fixed type in l10n-example -> *l10n-example-appication* M ./examples/l10n.lisp -3 +3 Sat Jun 24 04:34:52 EDT 2006 evrim at core.gen.tr * added src/rerl/modular-application direcorty. A ./src/rerl/modular-application/ Fri Jun 23 16:16:34 EDT 2006 evrim at core.gen.tr * l10n.lisp removed. moved to modular-applications. R ./src/l10n.lisp Fri Jun 23 16:11:02 EDT 2006 evrim at core.gen.tr * secure-application.lisp removed. moved to modular-applications. R ./src/components/secure-application.lisp Fri Jun 23 16:07:52 EDT 2006 evrim at core.gen.tr * cookie-session.lisp removed. moved to modular-applications. R ./src/rerl/cookie-session.lisp An updated tarball of ucw_dev's source can be downloaded here: http://common-lisp.net/project/ucw/tarballs/ucw_dev-20060624.tar.gz Darcsweb URL: http://uncommon-web.com/darcsweb/darcsweb.cgi?r=ucw_dev;a=summary From dbeauchesne at gmail.com Mon Jun 26 01:11:04 2006 From: dbeauchesne at gmail.com (Dan Beauchesne) Date: 26 Jun 2006 10:11:04 +0900 Subject: [Bese-devel] Multiple errors in the latest ucw_dev Message-ID: <873bds67rr.fsf@localhost.localdomain> Hi list, There are a few different errors with the latest checkout of ucw_dev. This is with SBCL 0.9.13.52, and latest dependencies: I posted this earlier, but I'm not sure it was noticed. There is a bug in load-applications (config.lisp) where concatenate is being passed a pathname instead of a string: (let ((directory (or applications-directory *ucw-applications-directory*))) (when directory (unless (cl-fad:directory-exists-p directory) (error "~S is not a valid directory" directory)) (push (concatenate 'string directory "/") asdf:*central-registry*) (prepare-applications-variables directory)) For a quick workaround I passed it a string instead (I'm not sure what the base problem is), and came onto a problem with name conflicts between the ucw package and cl-l10n. It seems the symbols DAY, MONTH, and YEAR in the cl-l10n package conflict with ucw's DAY, MONTH, and YEAR. After doing SBCL's name resolution, I came upon this error: ; compiling (IN-PACKAGE :IT.BESE.UCW-USER) ; compiling (EVAL-ALWAYS (IT.BESE.UCW::IMPORT-CL-L10N-SYMBOLS #)) ; compiling (ENABLE-SHARPQUOTE-READER) ; compiling (DEFPACKAGE :IT.BESE.UCW.LANG ...) ; compiling (EVAL-ALWAYS (LOCALE "en_US") ...) ;; Loading locale from /home/dan/src/cl-l10n_0.3/locales/en_US. debugger invoked on a UNDEFINED-FUNCTION in thread #: The function RELOAD-RESOURCES is undefined. 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 # on #. 1: [ACCEPT] Continue, treating # on # as having been successful. 2: [ABORT ] Exit debugger, returning to top level. ("bogus stack frame") 0] backtrace 10 0: ("bogus stack frame") 1: (SB-IMPL::%EVAL 0 #) 2: (SB-INT:EVAL-IN-LEXENV (WITH-RESOURCE-PACKAGE :LANG (RELOAD-RESOURCES)) #) 3: ((FLET SB-C::DEFAULT-PROCESSOR) (WITH-RESOURCE-PACKAGE :LANG (RELOAD-RESOURCES))) 4: (SB-C::PROCESS-TOPLEVEL-FORM (WITH-RESOURCE-PACKAGE :LANG (RELOAD-RESOURCES)) ((EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE) (LOCALE "en_US") (WITH-RESOURCE-PACKAGE :LANG (RELOAD-RESOURCES))) SB-C::ORIGINAL-SOURCE-START 0 4) (:COMPILE-TOPLEVEL)) 5: (SB-C::PROCESS-TOPLEVEL-PROGN ((LOCALE "en_US") (WITH-RESOURCE-PACKAGE :LANG (RELOAD-RESOURCES))) ((EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE) (LOCALE "en_US") (WITH-RESOURCE-PACKAGE :LANG (RELOAD-RESOURCES))) SB-C::ORIGINAL-SOURCE-START 0 4) (:COMPILE-TOPLEVEL)) 6: (SB-C::PROCESS-TOPLEVEL-FORM (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE) (LOCALE "en_US") (WITH-RESOURCE-PACKAGE :LANG (RELOAD-RESOURCES))) (SB-C::ORIGINAL-SOURCE-START 0 4) NIL) 7: ((FLET SB-C::DEFAULT-PROCESSOR) (EVAL-ALWAYS (LOCALE "en_US") (WITH-RESOURCE-PACKAGE :LANG (RELOAD-RESOURCES)))) 8: (SB-C::PROCESS-TOPLEVEL-FORM (EVAL-ALWAYS (LOCALE "en_US") (WITH-RESOURCE-PACKAGE :LANG (RELOAD-RESOURCES))) (SB-C::ORIGINAL-SOURCE-START 0 4) NIL) 9: (SB-C::SUB-SUB-COMPILE-FILE #) I'm quite new to lisp so I'm not sure if this is between ucw and cl-l10n or just cl-l10n. If it is the latter I'll post it on the appropriate list. Thanks guys, -- Dan Beauchesne dbeauchesne -at- gmail -dot- com From evrim at core.gen.tr Mon Jun 26 00:10:38 2006 From: evrim at core.gen.tr (Evrim ULU) Date: Mon, 26 Jun 2006 03:10:38 +0300 Subject: [Bese-devel] Multiple errors in the latest ucw_dev In-Reply-To: <873bds67rr.fsf@localhost.localdomain> References: <873bds67rr.fsf@localhost.localdomain> Message-ID: <449F25FE.8080108@core.gen.tr> Dan Beauchesne wrote: >I'm quite new to lisp so I'm not sure if this is between ucw and >cl-l10n or just cl-l10n. If it is the latter I'll post it on the >appropriate list. > > Could you do a darcs get common-lisp.net/project/cl-l10n/repos/cl-l10n it seems you'r using old CVS version which i personlayy did the same mistake. evrim. From mbaringer at common-lisp.net Mon Jun 26 04:30:09 2006 From: mbaringer at common-lisp.net (Marco Baringer) Date: Mon, 26 Jun 2006 00:30:09 -0400 (EDT) Subject: [Bese-devel] New patches to ucw_ajax: 25-Jun-2006 Message-ID: <20060626043009.37A523063@common-lisp.net> Sun Jun 25 09:02:23 EDT 2006 attila.lendvai at gmail.com * Call threaded-lisp-p at load-time to avoid a warning M ./src/control.lisp -15 +16 Sun Jun 25 08:47:28 EDT 2006 attila.lendvai at gmail.com * Get rid of the eval defclass in modular-application M ./src/rerl/modular-application/modular-application.lisp -10 +12 Sun Jun 25 08:20:21 EDT 2006 attila.lendvai at gmail.com * Merge dispatcher and application refactor with the dev branch M ./examples/examples.lisp -8 +5 M ./src/packages.lisp -1 +2 M ./src/rerl/standard-application.lisp -2 +3 M ./src/rerl/standard-dispatcher.lisp -134 +51 Sun Jun 25 06:55:38 EDT 2006 attila.lendvai at gmail.com * Make sure context.locale is always a list M ./src/rerl/modular-application/l10n-module.lisp -5 +5 Sat Jun 24 05:22:37 EDT 2006 evrim at core.gen.tr * fixed asd file for modular-applications. M ./ucw.asd -6 +13 Sat Jun 24 05:22:27 EDT 2006 evrim at core.gen.tr * added security-module.lisp A ./src/rerl/modular-application/security-module.lisp Sat Jun 24 05:21:54 EDT 2006 evrim at core.gen.tr * added modular-application.lisp which specifies modular applications. A ./src/rerl/modular-application/modular-application.lisp Sat Jun 24 05:21:13 EDT 2006 evrim at core.gen.tr * added l10n-module.lisp A ./src/rerl/modular-application/l10n-module.lisp Sat Jun 24 05:20:45 EDT 2006 evrim at core.gen.tr * cookie-module.lisp added. A ./src/rerl/modular-application/cookie-module.lisp Sat Jun 24 05:20:32 EDT 2006 evrim at core.gen.tr * added LICENCE file. A ./LICENCE Sat Jun 24 04:35:31 EDT 2006 evrim at core.gen.tr * fixed type in l10n-example -> *l10n-example-appication* M ./examples/l10n.lisp -3 +3 Sat Jun 24 04:34:52 EDT 2006 evrim at core.gen.tr * added src/rerl/modular-application direcorty. A ./src/rerl/modular-application/ Fri Jun 23 16:16:34 EDT 2006 evrim at core.gen.tr * l10n.lisp removed. moved to modular-applications. R ./src/l10n.lisp Fri Jun 23 16:11:02 EDT 2006 evrim at core.gen.tr * secure-application.lisp removed. moved to modular-applications. R ./src/components/secure-application.lisp Fri Jun 23 16:07:52 EDT 2006 evrim at core.gen.tr * cookie-session.lisp removed. moved to modular-applications. R ./src/rerl/cookie-session.lisp Thu Jun 22 08:10:56 EDT 2006 Marco Baringer * Define shared-initialize :after, not a shared-initialize whose first form in (call-next-method) M ./src/rerl/standard-dispatcher.lisp -3 +3 Mon Jun 19 05:55:36 EDT 2006 attila.lendvai at gmail.com * Fix the fix for dispatcher priority M ./src/rerl/standard-dispatcher.lisp -1 +1 Mon Jun 19 03:35:57 EDT 2006 Alexey Antipov * action-dispatcher created with nil priority M ./src/rerl/standard-dispatcher.lisp -3 +4 Sun Jun 18 19:25:21 EDT 2006 evrim at core.gen.tr * - merged conflicts with current dev-branch. tal-matcher updated according to marcos's ends-width patch. M ./src/rerl/standard-dispatcher.lisp -91 +11 Sun Jun 18 16:14:26 EDT 2006 evrim at core.gen.tr * - Introducing the new dispatcher implementation. now we have reusable matchers and handlers. API didn't change a lot for now. Only change is two arg'ed handler lambda()'s are replaced with zero arg-ed one's to form up a standard. Old arguments like application and context can be reached via special *context*. Please see also previous patch comments for more info about what may have changed. M! ./src/rerl/standard-dispatcher.lisp -138 +380 Sun Jun 18 13:45:43 EDT 2006 evrim at core.gen.tr * - ucw example application fixed to reflect changes in new dispacther api. M! ./examples/examples.lisp -8 +8 Sun Jun 18 13:45:07 EDT 2006 evrim at core.gen.tr * - ucw admin application dispatchers fixed to reflect new dispatcher api. M ./src/admin/admin.lisp -7 +3 Sun Jun 18 13:44:30 EDT 2006 evrim at core.gen.tr * - ensure-session moved to std-application class. M ./src/rerl/standard-application.lisp +11 Sun Jun 18 13:43:11 EDT 2006 evrim at core.gen.tr * - defentry-point fixed accoring to new disaptcher implementation. It now creates a zero-arged lambda function for action handling. M ./src/rerl/standard-action.lisp -1 +1 Sun Jun 18 13:42:08 EDT 2006 evrim at core.gen.tr * - fixed exports for new dispatcher implementaion. exported dispatchers: * action-dispatcher * minimal-dispatcher * simple-dispatcher * parenscript-dispatcher * url-dispatcher * regexp-dispatcher * tal-dispatcher - *dispatcher-registers* is un-exported since it does not exists anymore. M! ./src/packages.lisp -3 +3 Sun Jun 18 13:39:02 EDT 2006 evrim at core.gen.tr * - flush-request-response() moved to object std-request-context. M ./src/rerl/standard-request-context.lisp +8 Fri Jun 23 17:42:28 EDT 2006 attila.lendvai at gmail.com * Render custom checkbox images so that the page is not scrolled when they are clicked M ./src/components/form.lisp -2 +1 M ./wwwroot/ucw/ucw.css +4 Fri Jun 23 04:37:56 EDT 2006 attila.lendvai at gmail.com * Merge conflicts with dev branch in forms.lisp M ./src/components/form.lisp -1 +5 Thu Jun 22 08:37:35 EDT 2006 Marco Baringer * Merge conflicts with Pupeno's last patch M ./src/components/form.lisp -1 +8 Wed Jun 21 09:28:40 EDT 2006 Jos?? Pablo Ezequiel "Pupeno" Fern??ndez Silva * Be able to define accesskey in other input fields than text. M! ./src/components/form.lisp -8 +7 Wed Jun 21 09:16:57 EDT 2006 Jos?? Pablo Ezequiel "Pupeno" Fern??ndez Silva * Be able to specify accesskey for input elemnts. M! ./src/components/form.lisp -4 +3 Wed Jun 21 08:47:50 EDT 2006 Jos?? Pablo Ezequiel "Pupeno" Fern??ndez Silva * Re-place comments (email and regexp validator). M ./src/components/form.lisp -1 +3 Wed Jun 21 08:28:48 EDT 2006 Jos?? Pablo Ezequiel "Pupeno" Fern??ndez Silva * Export min and max -length for the length-validator. M ./src/packages.lisp +2 Tue Jun 20 15:31:45 EDT 2006 attila.lendvai at gmail.com * Err, really fix the content-length header this time M ./src/backend/common.lisp -1 +1 Tue Jun 20 09:45:10 EDT 2006 attila.lendvai at gmail.com * Fix content-length header in serv-* backend methods M ./src/backend/common.lisp -1 +1 Mon Jun 19 06:11:31 EDT 2006 Jos?? Pablo Ezequiel "Pupeno" Fern??ndez Silva * Esperanto translation. A ./wwwroot/ucw/examples/l10n/eo/ A ./wwwroot/ucw/examples/l10n/eo/greeting.tal M ./wwwroot/ucw/examples/l10n/es_ES/greeting.tal -1 +1 Mon Jun 19 05:50:43 EDT 2006 Jos?? Pablo Ezequiel "Pupeno" Fern??ndez Silva * Spanish translation. A ./wwwroot/ucw/examples/l10n/es_ES/ A ./wwwroot/ucw/examples/l10n/es_ES/greeting.tal Sun Jun 18 17:13:55 EDT 2006 attila.lendvai at gmail.com * Display the locale preference list in the l10n example M ./examples/l10n.lisp -3 +7 M ./wwwroot/ucw/examples/l10n/l10n-example.tal -1 +1 Sun Jun 18 11:35:12 EDT 2006 attila.lendvai at gmail.com * Make the l10n tal example an embeddable non-window component M ./examples/l10n.lisp -13 +7 M ./wwwroot/ucw/examples/l10n/l10n-example.tal -9 +6 Sun Jun 18 10:21:28 EDT 2006 attila.lendvai at gmail.com * Better way to load the examples in the README M ./README -1 +2 Sat Jun 17 13:31:14 EDT 2006 Maciek Pasternacki * Fix last patch (by Alberto Santini ) M ./src/backend/common.lisp -1 +1 Sat Jun 17 09:48:08 EDT 2006 Maciek Pasternacki * Fix an IE date header problem (by Lou Vanek ) M ./src/backend/common.lisp -3 +8 Sun Jun 18 10:34:51 EDT 2006 attila.lendvai at gmail.com * Use indefinit articles in l10n example M ./examples/l10n.lisp -6 +6 M ./src/l10n.lisp -1 +1 An updated tarball of ucw_ajax's source can be downloaded here: http://common-lisp.net/project/ucw/tarballs/ucw_ajax-20060625.tar.gz Darcsweb URL: http://uncommon-web.com/darcsweb/darcsweb.cgi?r=ucw_ajax;a=summary From mbaringer at common-lisp.net Mon Jun 26 04:30:09 2006 From: mbaringer at common-lisp.net (Marco Baringer) Date: Mon, 26 Jun 2006 00:30:09 -0400 (EDT) Subject: [Bese-devel] New patches to ucw_dev: 25-Jun-2006 Message-ID: <20060626043009.633184041@common-lisp.net> Sun Jun 25 12:40:51 EDT 2006 aycan.irican at core.gen.tr * exports for modular-application M ./src/packages.lisp +7 Sun Jun 25 08:47:28 EDT 2006 attila.lendvai at gmail.com * Get rid of the eval defclass in modular-application M ./src/rerl/modular-application/modular-application.lisp -10 +12 Sun Jun 25 06:55:38 EDT 2006 attila.lendvai at gmail.com * Make sure context.locale is always a list M ./src/rerl/modular-application/l10n-module.lisp -5 +5 Sun Jun 25 09:02:23 EDT 2006 attila.lendvai at gmail.com * Call threaded-lisp-p at load-time to avoid a warning M ./src/control.lisp -15 +16 Fri Jun 23 17:42:28 EDT 2006 attila.lendvai at gmail.com * Render custom checkbox images so that the page is not scrolled when they are clicked M ./src/components/form.lisp -2 +1 M ./wwwroot/ucw/ucw.css +4 An updated tarball of ucw_dev's source can be downloaded here: http://common-lisp.net/project/ucw/tarballs/ucw_dev-20060625.tar.gz Darcsweb URL: http://uncommon-web.com/darcsweb/darcsweb.cgi?r=ucw_dev;a=summary From attila.lendvai at gmail.com Mon Jun 26 08:00:48 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Mon, 26 Jun 2006 10:00:48 +0200 Subject: [Bese-devel] Multiple errors in the latest ucw_dev In-Reply-To: <873bds67rr.fsf@localhost.localdomain> References: <873bds67rr.fsf@localhost.localdomain> Message-ID: > I posted this earlier, but I'm not sure it was noticed. There is a bug > in load-applications (config.lisp) where concatenate is being passed a > pathname instead of a string: > > (let ((directory (or applications-directory > *ucw-applications-directory*))) > (when directory > (unless (cl-fad:directory-exists-p directory) > (error "~S is not a valid directory" directory)) > (push (concatenate 'string directory "/") asdf:*central-registry*) > (prepare-applications-variables directory)) i've pushed a fix for this but i don't use this mechanism so i couldn't test it. please report back if there are any errors... - attila (alias 101 on irc &no 'its not lisp code :) From mb at bese.it Mon Jun 26 08:00:46 2006 From: mb at bese.it (Marco Baringer) Date: Mon, 26 Jun 2006 10:00:46 +0200 Subject: [Bese-devel] Re: ucw.asd References: <449DC0F5.3030700@core.gen.tr> <449DD30A.6040904@core.gen.tr> Message-ID: Lu?s Oliveira writes: > Anyway, I guess it's up to the developer(s) to decide whether it's worth > the trouble to specify the dependencies. there are some cases where i think serial is a good idea: when every file depends on the previous one. in most of ucw's case that's just not the case. look at the :components module of the :ucw system, what ordering should we use there? why choose one over the other? why recompile login when task has changed? i'll admit that it's occasionaly a pain to keep the depends on lists up to date, but i strongly believe that the ucw file should express the real dependncies, not the simple-to-maintain dependncies. -- -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 attila.lendvai at gmail.com Mon Jun 26 20:02:24 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Mon, 26 Jun 2006 22:02:24 +0200 Subject: [Bese-devel] rfc2109 Message-ID: hi! here's the case with rfc2109: it conditionally reads the 5am tests in its single lisp file with #+5am tests. the trouble comes when a user loads rfc2109 with 5am already loaded (fasl gets compiled with 5am references) and later loads it when 5am is not loaded (fasl fails to load). this seems to be rare at first look, but still many ucw users report this. the usual solution for this is to create an rfc2109.test system in rfc2109.asd but it won't work with a single file project and too complicated for a project of this size anyway. another solution would be if we could force asdf to always load rfc2109 from source and leave alone fasl's. anyone knows how to do that? until it's properly resolved i've pushed an UNDO of my patch that added 5am unconditionally to the dependencies. this will render the box-set working again except the situation described above. -- - attila (alias 101 on irc &no 'its not lisp code :) From vanek at acd.net Mon Jun 26 21:54:37 2006 From: vanek at acd.net (Lou Vanek) Date: Mon, 26 Jun 2006 21:54:37 +0000 Subject: [Bese-devel] Re: rfc2109 In-Reply-To: References: Message-ID: <44A0579D.8070409@acd.net> Attila Lendvai wrote: > hi! > > here's the case with rfc2109: it conditionally reads the 5am tests in > its single lisp file with #+5am tests. > > the trouble comes when a user loads rfc2109 with 5am already loaded > (fasl gets compiled with 5am references) and later loads it when 5am > is not loaded (fasl fails to load). > > this seems to be rare at first look, but still many ucw users report this. > > the usual solution for this is to create an rfc2109.test system in > rfc2109.asd but it won't work with a single file project and too > complicated for a project of this size anyway. > > another solution would be if we could force asdf to always load > rfc2109 from source and leave alone fasl's. anyone knows how to do > that? There are several ways of doing that with asdf. The simplest is to use :load-source-op instead of :load-op. Example: (asdf:oos 'asdf:load-source-op :hello) [at least on asdf revision 1.98 it works] Here's another (more complicated) example (by Gary King): (defclass load-only-file-mixin () ()) (defclass load-only-cl-source-file (load-only-file-mixin cl-source-file) ()) (defmethod perform ((op compile-op) (component load-only-file-mixin)) nil) (defmethod perform ((op load-op) (component load-only-cl-source-file)) (load (component-pathname component))) (defsystem asdf-binary-locations :version "0.1" :author "Gary Warren King " :maintainer "Gary Warren King " :licence "MIT Style License" :description "Put compiled Lisp files in their places." :components ((:module "dev" :components ((:load-only-cl-source-file "main") (:static-file "notes.text"))) (:module "website" :components ((:module "source" :components ((:static-file "index.lml"))))))) > until it's properly resolved i've pushed an UNDO of my patch that > added 5am unconditionally to the dependencies. this will render the > box-set working again except the situation described above. > From vanek at acd.net Mon Jun 26 22:24:05 2006 From: vanek at acd.net (Lou Vanek) Date: Mon, 26 Jun 2006 22:24:05 +0000 Subject: [Bese-devel] javascript Message-ID: <44A05E85.9090009@acd.net> Hi Attila, How do you delay-eval the javascript scripts in the ajax branch? It's not being done in the main trunk so I added function wrappers around all javascript scripts and call them (via javascript) after the page has finished loading (and after dojo.js has finished loading). If I don't do this then I get errors indicating the 'dojo' variable is undefined, which it is since the dojo file usually hasn't finished downloading until after the page has fully loaded. (At least upon first-load, when dojo hasn't made its way into the browser cache yet.) BTW, here are some of my latest dojo tests: o firefox properly caches dojo and does not try to load it again o IE6 gets confused and tries to load it once per page o Opera 9 is utterly hopeless and asks for dojo twice per page load. Opera is also javascript-challenged and so I've pretty much given up hope trying to get my scripts to run on it. This was tested on winxp. Part of the problem was that dojo.js was being included twice in the response headers but that's easy to fix, and the above test results still apply. Another interesting fact: if there's anybody out there using clisp on windows you should replace the "write-sequence" calls with ext:write-char-sequence, or ext:write-byte-sequence. I'm seeing a 57,000% speed up in downloads after doing this, but it's probably just my sucky windows platform. Lou Vanek From attila.lendvai at gmail.com Mon Jun 26 22:38:09 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Tue, 27 Jun 2006 00:38:09 +0200 Subject: [Bese-devel] Re: rfc2109 In-Reply-To: <44A0579D.8070409@acd.net> References: <44A0579D.8070409@acd.net> Message-ID: > Here's another (more complicated) example > (by Gary King): > > (defclass load-only-file-mixin () > ()) > > (defclass load-only-cl-source-file (load-only-file-mixin cl-source-file) > ()) > > (defmethod perform ((op compile-op) (component load-only-file-mixin)) > nil) > > (defmethod perform ((op load-op) (component load-only-cl-source-file)) > (load (component-pathname component))) > > (defsystem asdf-binary-locations > :version "0.1" > :author "Gary Warren King " > :maintainer "Gary Warren King " > :licence "MIT Style License" > :description "Put compiled Lisp files in their places." > > :components ((:module > "dev" > :components ((:load-only-cl-source-file "main") > > (:static-file "notes.text"))) > > (:module > "website" > :components ((:module "source" > :components ((:static-file > "index.lml"))))))) thanks! i've pushed this solution adapted to rfc2109. now it's always loaded from source when loaded through asdf (this means (require :rfc2109) in sbcl, too). - attila (alias 101 on irc &no 'its not lisp code :) From attila.lendvai at gmail.com Mon Jun 26 23:10:13 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Tue, 27 Jun 2006 01:10:13 +0200 Subject: [Bese-devel] javascript In-Reply-To: <44A05E85.9090009@acd.net> References: <44A05E85.9090009@acd.net> Message-ID: > How do you delay-eval the javascript scripts in the ajax branch? > It's not being done in the main trunk so I added function wrappers > around all javascript scripts and call them (via javascript) after > the page has finished loading (and after dojo.js has finished loading). > If I don't do this then I get errors indicating the 'dojo' variable > is undefined, which it is since the dojo file usually hasn't finished > downloading until after the page has fully loaded. (At least upon > first-load, when dojo hasn't made its way into the browser cache yet.) well, i'm not a js guru, but this is how one of my page looks like: BTW, here are some of my latest dojo tests: > > o firefox properly caches dojo and does not try to load it again > o IE6 gets confused and tries to load it once per page > o Opera 9 is utterly hopeless and asks for dojo twice per page load. > Opera is also javascript-challenged and so I've pretty much given > up hope trying to get my scripts to run on it. this is my log with opera 8.5 on linux at first load (and after a very quick test all ajax stuff works): 00:54 UCW.BACKEND/+INFO+: Handling request for "/cocoma/" 00:54 UCW.BACKEND/+INFO+: Handling request for "/cocoma/dwim.ico" 00:54 UCW.BACKEND/+INFO+: Handling request for "/cocoma/treemenu.css" 00:54 UCW.BACKEND/+INFO+: Handling request for "/cocoma/dwim.css" 00:54 UCW.BACKEND/+INFO+: Handling request for "/cocoma/ucw/ucw.css" 00:54 UCW.BACKEND/+INFO+: Handling request for "/cocoma/dojo/dojo.js" 00:54 UCW.BACKEND/+INFO+: Handling request for "/cocoma/dojo/src/debug.js" 00:54 UCW.BACKEND/+INFO+: Handling request for "/cocoma/ucw/js/per-application.js" 00:54 UCW.BACKEND/+INFO+: Handling request for "/cocoma/dwim-static.js" 00:54 UCW.BACKEND/+INFO+: Handling request for "/cocoma/cocoma.css" 00:54 UCW.BACKEND/+INFO+: Handling request for "/cocoma/ucw/images/collapsible-off.png" 00:54 UCW.BACKEND/+INFO+: Handling request for "/cocoma/ucw/images/collapsible-on.png" > This was tested on winxp. > > Part of the problem was that dojo.js was being included twice in the response > headers but that's easy to fix, and the above test results still apply. is it with the stock ucw examples or with a custom application? stuff seems to be working here with 8.51 opera and a recent ff. - attila (alias 101 on irc &no 'its not lisp code :) From vanek at acd.net Mon Jun 26 23:40:24 2006 From: vanek at acd.net (Lou Vanek) Date: Mon, 26 Jun 2006 23:40:24 +0000 Subject: [Bese-devel] javascript In-Reply-To: References: <44A05E85.9090009@acd.net> Message-ID: <44A07068.9080401@acd.net> Attila Lendvai wrote: >> How do you delay-eval the javascript scripts in the ajax branch? >> It's not being done in the main trunk so I added function wrappers >> around all javascript scripts and call them (via javascript) after >> the page has finished loading (and after dojo.js has finished loading). >> If I don't do this then I get errors indicating the 'dojo' variable >> is undefined, which it is since the dojo file usually hasn't finished >> downloading until after the page has fully loaded. (At least upon >> first-load, when dojo hasn't made its way into the browser cache yet.) > > > well, i'm not a js guru, but this is how one of my page looks like: > > >> > > > > and i think that script tags should be executed in order. somebody > correct me if i'm wrong (but then i'll give up all hope in all www > standards) please check and/or send what it looks like in your pages. Yes, javascript is executed in order, but asynchronously in some cases. Specifically, for 'src="/.../dojo.js"', the (asynchronous) call is made back to the server for the dojo.js file, but the js continues to be evaluated in the browser. If there is a variable client-side that is defined in dojo.js then an error is thrown, at least on the windows platform--maybe things are different on linux, or all your js files are previously cached client-side. To test this, clear all your caches and then try to do a simple 'alert(dojo);' and dojo returns null on windows if the script is executed prior to the page finishing its load. > (dojo needs its debug configuration created before it is loaded) This debug configuration data is being evaluated prior to dojo being loaded, which is true. I'm asking about the opposite situation: client-side variables that rely upon dojo.js being loaded first. > as with the caching of the parenscript: they are generated at the > first request and cached on the server until the lisp file is touched. > it's sent with some cache headers, take a look at > parenscript-dispatcher and server-sequence. Not interested in parenscript, per se. Interested in ensuring that dojo's variables are loaded and defined before the parenscript-generated code is evaluated client-side. i'd be more than happy if > you could fix any possibble issues with cache headers with ie or > opera. I'll show you want I've done in another email. I'm amazed that you don't have this problem on linux. >> BTW, here are some of my latest dojo tests: >> >> o firefox properly caches dojo and does not try to load it again >> o IE6 gets confused and tries to load it once per page >> o Opera 9 is utterly hopeless and asks for dojo twice per page load. >> Opera is also javascript-challenged and so I've pretty much given >> up hope trying to get my scripts to run on it. > > > this is my log with opera 8.5 on linux at first load (and after a very > quick test all ajax stuff works): > > 00:54 UCW.BACKEND/+INFO+: Handling request for "/cocoma/" > 00:54 UCW.BACKEND/+INFO+: Handling request for "/cocoma/dwim.ico" > 00:54 UCW.BACKEND/+INFO+: Handling request for "/cocoma/treemenu.css" > 00:54 UCW.BACKEND/+INFO+: Handling request for "/cocoma/dwim.css" > 00:54 UCW.BACKEND/+INFO+: Handling request for "/cocoma/ucw/ucw.css" > 00:54 UCW.BACKEND/+INFO+: Handling request for "/cocoma/dojo/dojo.js" > 00:54 UCW.BACKEND/+INFO+: Handling request for "/cocoma/dojo/src/debug.js" > 00:54 UCW.BACKEND/+INFO+: Handling request for > "/cocoma/ucw/js/per-application.js" > 00:54 UCW.BACKEND/+INFO+: Handling request for "/cocoma/dwim-static.js" > 00:54 UCW.BACKEND/+INFO+: Handling request for "/cocoma/cocoma.css" > 00:54 UCW.BACKEND/+INFO+: Handling request for > "/cocoma/ucw/images/collapsible-off.png" > 00:54 UCW.BACKEND/+INFO+: Handling request for > "/cocoma/ucw/images/collapsible-on.png" Hmm, apparently Opera 9-Windows is more brain damaged than Opera 8.5-Linux. >> This was tested on winxp. >> >> Part of the problem was that dojo.js was being included twice in the >> response >> headers but that's easy to fix, and the above test results still apply. > > > is it with the stock ucw examples or with a custom application? Custom. Had to fix a lot of small things. For example, DOCTYPE was being included twice on every page. stuff > seems to be working here with 8.51 opera and a recent ff. On linux. FF works great on windows, too. FF is the only browser on windows that i have tested which is honoring file expiration dates. > - attila > > (alias 101 on irc &no 'its not lisp code :) > Lou Vanek From vanek at acd.net Mon Jun 26 23:55:14 2006 From: vanek at acd.net (Lou Vanek) Date: Mon, 26 Jun 2006 23:55:14 +0000 Subject: [Bese-devel] javascript In-Reply-To: References: <44A05E85.9090009@acd.net> Message-ID: <44A073E2.60603@acd.net> The following is what i use for clisp to delay javascripts from executing until the page has finished loading. (defmacro defun-inline (name bvl &body forms) `(progn (declaim (inline ,name)) (defun ,name ,bvl , at forms))) (defun-inline string-append (&rest strings) (declare (dynamic-extent strings)) (apply #'concatenate 'string strings)) (defun-inline js-bootstrap-code () " ") ;; not used because it really isn't necessary and takes a lot of resources. (defun move-scripts-into-head (s) (let* ((head_re "(?i)") (script_re "(?i)(?s)](.*?)") (h (cl-ppcre:scan head_re s))) (when h (loop for x = h then end for (start end) = (multiple-value-bind (s e) (cl-ppcre:scan script_re s :start x) (list s e)) while end collect (string-append (subseq s start end) '(#\Newline)) into scripts collect (subseq s x start) into nonscripts finally (return-from move-scripts-into-head (arnesi:join-strings (append (list (subseq s 0 h)) scripts nonscripts (list (subseq s x))))) )) s)) (defun insert-into-head (html new-item) (let* ((head_re "(?i)") (h (cl-ppcre:scan head_re html))) (if h (string-append (subseq html 0 h) new-item '(#\Newline) (subseq html h)) html))) (defun patch__function__XXX (tgt) (let ((regex (cl-ppcre:create-scanner "__function__\(XXX\) =")) (i -1)) (flet ((patchNumber (target-string start end match-start match-end reg-starts reg-ends) (declare (ignore start end match-end reg-starts reg-ends)) (format nil "__function__~3,'0D =" (incf i)))) (setf tgt (cl-ppcre:regex-replace-all regex tgt #'patchNumber)) (values tgt (incf i))))) (defmethod shutdown ((resp araneida-response)) (multiple-value-bind (content-type content-type/charset) (content-type-and-charset resp) (let* ((s (get-output-stream-string (html-stream resp))) (content (if (starts-with content-type "text") (string-to-octets (insert-into-head (patch__function__XXX s) (js-bootstrap-code)) and so on... and i added a new tag to use when you want your script executed after the page has finished loading (and the code in dojo.js is guaranteed to have been defined): (deftag-macro " ~%))) From vanek at acd.net Tue Jun 27 01:11:52 2006 From: vanek at acd.net (Lou Vanek) Date: Tue, 27 Jun 2006 01:11:52 +0000 Subject: [Bese-devel] javascript In-Reply-To: References: <44A05E85.9090009@acd.net> <44A073E2.60603@acd.net> Message-ID: <44A085D8.7020803@acd.net> Alexander Kjeldaas wrote: > On 6/27/06, Lou Vanek wrote: > >> The following is what i use for clisp to delay javascripts >> from executing until the page has finished loading. >> > > I'm no javascript expert, but do you have the HEAD/BODY > placement of your scripts correct? > AFAIU, these are the rules: > You can't do any load-time modifications to the page > from a script placed in the HEAD section. All HEAD > scripts can be asyncronously executed (or in order but > independent of BODY and rendering of the page). > That means you cannot have any script in the BODY > section that calls scripts loaded from the HEAD section. > So, if you want to do stuff at (the end of) load-time that > calls some dojo magic, dojo.js must be loaded from the > BODY section and not from HEAD. Thanks! I was sure I tried that, but it was several years ago. It works (on windows at least) if you place the js script load just after the opening body tag. Results are flaky if you put the js load at the bottom of the page, but that can be avoided. > When events can start triggering, all HEAD scripts > must be loaded, and it looks like your magic hooks > all functions into an events-can-start-to-trigger-now event > (onload or similar), but I don't see how this is different > from loading dojo.js from the BODY section. Empirically, I would have to agree with you. > This is probably obvious, and in that case, sorry for > the noise :-) This 'noise' saves us a lot of work and perhaps a little embarrassment. > Btw, with a real js-aware "compiler" or such, it should > be possible to write a tree-shaker that could additionaly > split js-functions into HEAD and BODY parts ;-). > > astor Moving all javascript load scripts out of HEAD and after the opening body tag is a better solution since it's simpler than what I came up with. Should probably make this part of a new References: <44A05E85.9090009@acd.net> <44A073E2.60603@acd.net> Message-ID: On 6/27/06, Lou Vanek wrote: > The following is what i use for clisp to delay javascripts > from executing until the page has finished loading. > I'm no javascript expert, but do you have the HEAD/BODY placement of your scripts correct? AFAIU, these are the rules: You can't do any load-time modifications to the page from a script placed in the HEAD section. All HEAD scripts can be asyncronously executed (or in order but independent of BODY and rendering of the page). That means you cannot have any script in the BODY section that calls scripts loaded from the HEAD section. So, if you want to do stuff at (the end of) load-time that calls some dojo magic, dojo.js must be loaded from the BODY section and not from HEAD. When events can start triggering, all HEAD scripts must be loaded, and it looks like your magic hooks all functions into an events-can-start-to-trigger-now event (onload or similar), but I don't see how this is different from loading dojo.js from the BODY section. This is probably obvious, and in that case, sorry for the noise :-) Btw, with a real js-aware "compiler" or such, it should be possible to write a tree-shaker that could additionaly split js-functions into HEAD and BODY parts ;-). astor From mbaringer at common-lisp.net Tue Jun 27 04:30:15 2006 From: mbaringer at common-lisp.net (Marco Baringer) Date: Tue, 27 Jun 2006 00:30:15 -0400 (EDT) Subject: [Bese-devel] New patches to ucw_dev: 26-Jun-2006 Message-ID: <20060627043015.D1B4B30010@common-lisp.net> Mon Jun 26 03:58:04 EDT 2006 attila.lendvai at gmail.com * Fix application-directory handling in config.lisp M ./src/config.lisp -8 +9 An updated tarball of ucw_dev's source can be downloaded here: http://common-lisp.net/project/ucw/tarballs/ucw_dev-20060626.tar.gz Darcsweb URL: http://uncommon-web.com/darcsweb/darcsweb.cgi?r=ucw_dev;a=summary From attila.lendvai at gmail.com Tue Jun 27 08:24:25 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Tue, 27 Jun 2006 10:24:25 +0200 Subject: [Bese-devel] javascript In-Reply-To: <44A085D8.7020803@acd.net> References: <44A05E85.9090009@acd.net> <44A073E2.60603@acd.net> <44A085D8.7020803@acd.net> Message-ID: > Moving all javascript load scripts out of HEAD and after the opening body > tag is a better solution since it's simpler than what I came up > with. Should probably make this part of a new " #\Newline) (<:html (<:head (<:meta :http-equiv "Content-Type" :content (window-component.content-type window)) (<:title (<:as-html (window-component.title window))) (awhen (window-component.icon window) (<:link :rel "icon" :type "image/x-icon" :href it)) (dolist (stylesheet (ensure-list (window-component.stylesheet window))) (<:link :rel "stylesheet" :href stylesheet :type "text/css"))) (let* ((app (context.application *context*)) (url-prefix (application.url-prefix app))) (<:body ( References: <44A05E85.9090009@acd.net> <44A073E2.60603@acd.net> <44A085D8.7020803@acd.net> Message-ID: <44A1150E.4040004@acd.net> Attila Lendvai wrote: >> Moving all javascript load scripts out of HEAD and after the opening body >> tag is a better solution since it's simpler than what I came up >> with. Should probably make this part of a new > > Lou, what happens if you replace the window render function with > something like the paste at the end of this mail? it's the old render > function in window.lisp except that the script definitions were moved > into the <:body tag. > > if it solves your troubles i'll commit it, as it didn't change > anything for me locally. > > - attila > > (alias 101 on irc &no 'its not lisp code :) > > > > > (defmethod render :wrapping ((window simple-window-component)) > "This convience method assumes: 1) the stylesheet is > external (as opposed to inlined) or is not used; 2) the script > file is javascript and is external or is no script is used and 3) > the title is simply the value of the title slot in the WINDOW (no > dynamic titles)." > (<:as-is " Transitional//EN\" > \"http://www.w3.org/TR/xhtml1/DTD/transitional.dtd\">" > #\Newline) > (<:html > (<:head > (<:meta :http-equiv "Content-Type" :content > (window-component.content-type window)) > (<:title (<:as-html (window-component.title window))) > (awhen (window-component.icon window) > (<:link :rel "icon" > :type "image/x-icon" > :href it)) > (dolist (stylesheet (ensure-list (window-component.stylesheet window))) > (<:link :rel "stylesheet" > :href stylesheet > :type "text/css"))) > (let* ((app (context.application *context*)) > (url-prefix (application.url-prefix app))) > (<:body > ( :is-debug ,(if (debug-on-error app) > 'true > 'false) > :base-loader-uri ,(strcat > url-prefix "dojo/")))) > (<:script :type "text/javascript" :src (strcat url-prefix > "dojo/dojo.js")) > (<:script :type "text/javascript" :src (strcat url-prefix > "ucw/js/per-application.js")) > (dolist* ((type value &key with-url-prefix) > (window-component.javascript window)) > (ecase type > (:src > ;; most browsers (firefox, safari and ie at least) really, > ;; really, really don't like empty script tags. The "" forces > ;; yaclml to generate a seperate closing tag. > (<:script :type "text/javascript" :src (if with-url-prefix > (strcat url-prefix > value) > value) > "")) > (:js > (<:script :type "text/javascript" (<:as-is (js:js* value)))) > (:script > (<:script :type "text/javascript" (<:as-is value))))) > (call-next-method))))) On first blush this seemed to solve most of the problems: it works as expected on ff, opera 9 still complains about an undefined dojo variable (but I don't care any more about opera), and IE6 worked correctly. That is, until I noticed a brief error flash on the 302 redirect. Since this change isn't included in the 302 redirect the error is still occurring, but now only _between_ pages during the 302 redirect. I still think this code needs to be taken out of this render method so that other methods may reuse it, such as the 302 send-redirect function. There are two other small problems, at least on my system: I had to comment out the DOCTYPE line because it's being included elsewhere (the yaclml <:html tag), and I had to comment out the dojo.js line because it's being included elsewhere, too (otherwise I get two DOCTYPE and two src="dojo.js" lines). But this is better than before. Lou Vanek From vanek at acd.net Tue Jun 27 11:29:41 2006 From: vanek at acd.net (Lou Vanek) Date: Tue, 27 Jun 2006 11:29:41 +0000 Subject: [Bese-devel] javascript In-Reply-To: <44A1150E.4040004@acd.net> References: <44A05E85.9090009@acd.net> <44A073E2.60603@acd.net> <44A085D8.7020803@acd.net> <44A1150E.4040004@acd.net> Message-ID: <44A116A5.5010100@acd.net> > On first blush this seemed to solve most of the problems: it works as > expected on ff, opera 9 still complains about an undefined dojo variable > (but I don't care any more about opera), and IE6 worked correctly. > That is, until I noticed a brief error flash on the 302 redirect. > > Since this change isn't included in the 302 redirect the error is still > occurring, but now only _between_ pages during the 302 redirect. > > I still think this code needs to be taken out of this render method so > that other methods may reuse it, such as the 302 send-redirect function. Or the 302 redirect page can be simplified so that it doesn't require a 132K support file to run w/o error on ie. I think that means taking out the html anchor tag. From mbaringer at common-lisp.net Thu Jun 29 04:30:23 2006 From: mbaringer at common-lisp.net (Marco Baringer) Date: Thu, 29 Jun 2006 00:30:23 -0400 (EDT) Subject: [Bese-devel] New patches to ucw_dev: 28-Jun-2006 Message-ID: <20060629043023.34C162B033@common-lisp.net> Wed Jun 28 04:49:44 EDT 2006 attila.lendvai at gmail.com * Move some stuff from start.lisp into ucw.asd M ./etc/start.lisp -19 M ./src/control.lisp -3 +5 M ./src/packages.lisp +1 M ./ucw.asd -1 +22 Tue Jun 27 10:16:34 EDT 2006 attila.lendvai at gmail.com * Convert external-format-for into a defun M ./src/helpers.lisp -2 +5 M ./ucw.asd -1 +1 Mon Jun 26 18:06:00 EDT 2006 attila.lendvai at gmail.com * Added a with-url-prefix keyword param to :src javascript entries M ./src/components/window.lisp -14 +23 An updated tarball of ucw_dev's source can be downloaded here: http://common-lisp.net/project/ucw/tarballs/ucw_dev-20060628.tar.gz Darcsweb URL: http://uncommon-web.com/darcsweb/darcsweb.cgi?r=ucw_dev;a=summary From dmgenp at gmail.com Thu Jun 29 20:36:31 2006 From: dmgenp at gmail.com (Dmitry Petukhov) Date: Fri, 30 Jun 2006 02:36:31 +0600 Subject: [Bese-devel] ucw_dev - two minor problems on compilation Message-ID: <84ee89da0606291336g7932990el4558c6fd54389a0c@mail.gmail.com> Hello list, I successfully started ucw, but has two minor problems, maybe someone wish to fix them: 1) cl-l10n exports 'year 'month and 'day symbols, while src/components/form.lisp wants them as accessors, so there was name conflict. solved by adding (:shadow year month day) into defpackage :it.bese.ucw in src/packages.lisp 2) ucw.asd specifies (:module :i18n ....), but there's no such module (seems it is replaced by cl-l10n). solved by commented out this in defsystem. From attila.lendvai at gmail.com Thu Jun 29 21:02:05 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Thu, 29 Jun 2006 23:02:05 +0200 Subject: [Bese-devel] ucw_dev - two minor problems on compilation In-Reply-To: <84ee89da0606291336g7932990el4558c6fd54389a0c@mail.gmail.com> References: <84ee89da0606291336g7932990el4558c6fd54389a0c@mail.gmail.com> Message-ID: > 1) cl-l10n exports 'year 'month and 'day symbols, while > src/components/form.lisp wants them as accessors, so there was name > conflict. you need to pull the darcs repo of cl-l10n, see homepage. > 2) ucw.asd specifies (:module :i18n ....), but there's no such module > (seems it is replaced by cl-l10n). solved by commented out this in > defsystem. i don't have any i18n reference in my local asd, maybe you need to pull ucw, too? - attila (alias 101 on irc &no 'its not lisp code :) From mbaringer at common-lisp.net Fri Jun 30 04:00:08 2006 From: mbaringer at common-lisp.net (Marco Baringer) Date: Fri, 30 Jun 2006 00:00:08 -0400 (EDT) Subject: [Bese-devel] New patches to arnesi_dev: 29-Jun-2006 Message-ID: <20060630040008.4324A54055@common-lisp.net> Thu Jun 29 21:28:11 EDT 2006 attila.lendvai at gmail.com * Export encoding-keyword-to-native M ./src/packages.lisp +1 An updated tarball of arnesi_dev's source can be downloaded here: http://common-lisp.net/project/bese/tarballs/arnesi_dev-20060629.tar.gz Darcsweb URL: http://uncommon-web.com/darcsweb/darcsweb.cgi?r=arnesi_dev;a=summary From mbaringer at common-lisp.net Fri Jun 30 04:30:07 2006 From: mbaringer at common-lisp.net (Marco Baringer) Date: Fri, 30 Jun 2006 00:30:07 -0400 (EDT) Subject: [Bese-devel] New patches to ucw_dev: 29-Jun-2006 Message-ID: <20060630043007.414226D02E@common-lisp.net> Thu Jun 29 20:18:34 EDT 2006 attila.lendvai at gmail.com * Only start swank from the asd when *ucw-swank-port* is not nil M ./ucw.asd -1 +3 Wed Jun 28 16:54:17 EDT 2006 evrim at core.gen.tr * - fixed %100 cpu utilization when action-id is not specified in the URL. M ./src/rerl/standard-session-frame.lisp +3 Tue Jun 27 11:09:48 EDT 2006 evrim at core.gen.tr * - effective-context-definition exported for external app-module definitions. M ./src/packages.lisp -1 +2 An updated tarball of ucw_dev's source can be downloaded here: http://common-lisp.net/project/ucw/tarballs/ucw_dev-20060629.tar.gz Darcsweb URL: http://uncommon-web.com/darcsweb/darcsweb.cgi?r=ucw_dev;a=summary From mbaringer at common-lisp.net Fri Jun 30 04:30:08 2006 From: mbaringer at common-lisp.net (Marco Baringer) Date: Fri, 30 Jun 2006 00:30:08 -0400 (EDT) Subject: [Bese-devel] New patches to ucw_ajax: 29-Jun-2006 Message-ID: <20060630043008.619BB6D033@common-lisp.net> Thu Jun 29 20:18:34 EDT 2006 attila.lendvai at gmail.com * Only start swank from the asd when *ucw-swank-port* is not nil M ./ucw.asd -1 +3 Thu Jun 29 19:10:51 EDT 2006 attila.lendvai at gmail.com * Fix read-line-from-network in httpd backend M ./src/backend/httpd.lisp -5 +4 Thu Jun 29 18:16:34 EDT 2006 attila.lendvai at gmail.com * Resolve conflicts with the dev branch with find-action M ./src/rerl/standard-session-frame.lisp +3 Wed Jun 28 16:54:17 EDT 2006 evrim at core.gen.tr * - fixed %100 cpu utilization when action-id is not specified in the URL. M! ./src/rerl/standard-session-frame.lisp -2 +2 Tue Jun 27 11:09:48 EDT 2006 evrim at core.gen.tr * - effective-context-definition exported for external app-module definitions. M ./src/packages.lisp -1 +2 Thu Jun 29 18:00:33 EDT 2006 attila.lendvai at gmail.com * Added missing parenscript-utils dependency to components in the asd M ./ucw.asd -1 +1 Thu Jun 29 17:58:37 EDT 2006 attila.lendvai at gmail.com * Fix isolated action handling M ./src/rerl/standard-dispatcher.lisp -12 +19 Wed Jun 28 04:49:44 EDT 2006 attila.lendvai at gmail.com * Move some stuff from start.lisp into ucw.asd M ./etc/start.lisp -19 M ./src/control.lisp -3 +5 M ./src/packages.lisp +1 M ./ucw.asd -1 +22 Tue Jun 27 10:16:34 EDT 2006 attila.lendvai at gmail.com * Convert external-format-for into a defun M ./src/helpers.lisp -2 +5 M ./ucw.asd -1 +1 Mon Jun 26 03:58:04 EDT 2006 attila.lendvai at gmail.com * Fix application-directory handling in config.lisp M ./src/config.lisp -8 +9 Sun Jun 25 12:40:51 EDT 2006 aycan.irican at core.gen.tr * exports for modular-application M ./src/packages.lisp +7 Mon Jun 26 19:15:22 EDT 2006 attila.lendvai at gmail.com * Added a :with-url-prefix keyword param to javascript entries in window.lisp M ./src/components/window.lisp -12 +15 An updated tarball of ucw_ajax's source can be downloaded here: http://common-lisp.net/project/ucw/tarballs/ucw_ajax-20060629.tar.gz Darcsweb URL: http://uncommon-web.com/darcsweb/darcsweb.cgi?r=ucw_ajax;a=summary From attila.lendvai at gmail.com Fri Jun 30 17:51:17 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Fri, 30 Jun 2006 19:51:17 +0200 Subject: [Bese-devel] boxset Message-ID: hi! there were some incompatible changes in how ucw starts up. if you have an older box-set that you keep in sync with darcs pull and friends then i suggest downloading a fresh box-set archive. (otherwise your old start.lisp will have trouble starting ucw) - attila (alias 101 on irc &no 'its not lisp code :)