- tbnl-devel@common-lisp.net - mailman3.common-lisp.net

Re: [hunchentoot-devel] Widget Guidlines
by First name Last name 20 Jan '09

20 Jan '09

I don't think we need agreement from all, we need one or two of the main developers to agree on a specification. Compliance can be enforced by only adding "valid" widgets to a widgets repository. As more widgets are added arguments about the the how and why will fade as reusability wins in the end. Besides its open source, and opponents can come up with their own specification and own repository if they feel that strongly about it, nothing wrong with some choice. The specification does not need to be perfect if it covers 80% of what is needed then it will be good enough. The last 20% is almost always not worth bothering with any way. I vote for some thing over nothing here. ----- Original Message ------ From:Edi Weitz Sent:Tuesday, January 20, 2009 09:08 To:General interest list for Hunchentoot and CL-WEBDAV tbnl-devel(a)common-lisp.net; Subject:Re: [hunchentoot-devel] Widget Guidlines On Mon, Jan 19, 2009 at 7:41 PM, First name Last name wrote: > I have been using hunchentoot for the last two months and I have created a > DB-Grid widget for myself. I pass relevant info in through parameters like > table name and columns to display and the widget generates a html grid with > paging, edit/delete and search functionality. > > My lisp experience however is limited and my widget is feeling more and more > clunky as the functionality grows. I would like to ask the experts how they > would structure/design such a widget using hunchentoot (cl-who + > postmodern). > > I was thinking that such a widget might benefit others as well and others > might have widgets that I might find useful. If we all use our own designs > thow the resulting code might end up being to diverse to support. I would > also not like to have to use a whole other framework on top of hunchentoot > unless it came from the hunchentoot community and/or was supported by them. > I would like the widgets to be as close as possible to hunchentoot to make > them small, light and independant. > > Would it be feasible to set up a guideline/specification for hunchentoot > widgets in general and widgets dealing with data-binding specifically? This > way we could share widget among each other based on some standard that is > documented and "trusted". I think this generally sounds like a good idea although I imagine that it'll be kind of hard to reach consensus even in the small group of Hunchentoot users about the requirements for such widgets. Cheers, Edi. _______________________________________________ tbnl-devel site list tbnl-devel(a)common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel

1 0

[hunchentoot-devel] Widget Guidlines
by First name Last name 20 Jan '09

20 Jan '09

Hi I have been using hunchentoot for the last two months and I have created a DB-Grid widget for myself. I pass relevant info in through parameters like table name and columns to display and the widget generates a html grid with paging, edit/delete and search functionality. My lisp experience however is limited and my widget is feeling more and more clunky as the functionality grows. I would like to ask the experts how they would structure/design such a widget using hunchentoot (cl-who + postmodern). I was thinking that such a widget might benefit others as well and others might have widgets that I might find useful. If we all use our own designs thow the resulting code might end up being to diverse to support. I would also not like to have to use a whole other framework on top of hunchentoot unless it came from the hunchentoot community and/or was supported by them. I would like the widgets to be as close as possible to hunchentoot to make them small, light and independant. Would it be feasible to set up a guideline/specification for hunchentoot widgets in general and widgets dealing with data-binding specifically? This way we could share widget among each other based on some standard that is documented and "trusted". Regards

4 3

[hunchentoot-devel] Fwd: [Sbcl-devel] SBCL crashes in READ-SEQUENCE with Error: The value 1025 is not of type (MOD 1025)
by Hans Hübner 08 Jan '09

08 Jan '09

Recently, I saw one of my servers crash to ldb with the error message "Error: The value 1025 is not of type (MOD 1025)". This happens every few months, and I have not been bothered too much by it (and I will be bothered even less now that Zach Beane has posted how I can disable ldb), but I wanted to know what the cause for this is, so inquired in sbcl-devel. See Juho's answer below. It boils down to: There is a file descriptor leak. -Hans ---------- Forwarded message ---------- From: Juho Snellman <jsnell(a)iki.fi> Date: Thu, Jan 8, 2009 at 14:26 Subject: Re: [Sbcl-devel] SBCL crashes in READ-SEQUENCE with Error: The value 1025 is not of type (MOD 1025) To: Hans Hübner <hans.huebner(a)gmail.com> Cc: sbcl-devel(a)lists.sourceforge.net Hans Hübner <hans.huebner(a)gmail.com> writes: > Hi, > > sporadically, some of my Hunchentoot based web servers running on SBCL > 1.0.20.22 (FreeBSD, threaded) crash to ldb, with the following messages > appearing on the REPL: > > Error: The value 1025 is not of type (MOD 1025). My first guess would be that you've got a fd that's too large (select can only handle fds smaller than FD_SETSIZE). Some people have explored replacing the use of select() for serve-event with using various other fd polling interfaces to work around this problem (there should be one patch floating around that uses epoll() on Linux, don't know whether that'd be usable for you on FreeBSD). -- Juho Snellman

2 2

[hunchentoot-devel] Limit on Request Content Size
by Volkan YAZICI 05 Jan '09

05 Jan '09

Hi, [Sorry if this question was raised before, but I couldn't find anything related in the archives.] How can I force a limit on the content size of the request body? Is there such a functionality built into hunchentoot? If not, is GET-POST-DATA the right place to introduce this feature? Regards.

2 3

[hunchentoot-devel] parameterp?
by Erik Nomitch 31 Dec '08

31 Dec '08

Hi, I was wondering if there is a better way to test of a get/post parameter is set. In the documentation, it says: *(or NIL if there ain't no parameter with this name)* . But when it's not set and I do (hunchentoot:get-parameter "foo") and it DNE, I get a server error. I'm using Hunchentoot 0.15.7 (SBCL 1.0.22). Here is what I'm currently doing: * (defun parameterp (str) (dolist (x (hunchentoot:get-parameters)) (when (string= (car x) str) (return-from parameterp t))) nil)* Thanks, Erik Nomitch

2 1

Re: [hunchentoot-devel] TCP Input timeout on CCL
by sblist＠me.com 30 Dec '08

30 Dec '08

Hi Hans, On 5-Dec-08, at 12:50 AM, Hans Hübner wrote: > This happens when a connection times out - It is "normal", but the > condition is not properly caught in the worker thread function. We > will fix the problem in the upcoming (!) release, but until then, you > can just ignore it. Do you use the release or the development version > of Hunchentoot? We are using the latest release at the moment. Would you recommend trying out the development version? Where could that be obtained? Thanks for your help, - Scott

3 3

[hunchentoot-devel] hunchentoot errors
by Cyrus Harmon 25 Dec '08

25 Dec '08

so, just when I managed to squash one persistent failure (running out of threads due to sb-ext:run-process not returning), I seem to have awoken another. I've got two, possibly unrelated, issues. First, the more benign one: I see the following message quite often in the logs: [2008-12-23 18:47:38 [ERROR]] Error while processing connection: The value 1058 is not of type (MOD 1025). occasionally the message is: [2008-12-23 18:46:06 [ERROR]] Error while processing connection: The value 1065 is not of type (UNSIGNED-BYTE 10). any idea where these might be coming from? The second, more serious, problem is that I seem to end up in ldb after a few days of usage: * Argh! corrupted error depth, halting fatal error encountered in SBCL pid 60417(tid 134658560): %PRIMITIVE HALT called; the party is over. Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> Argh! corrupted error depth, halting fatal error encountered in SBCL pid 60417(tid 134659072): %PRIMITIVE HALT called; the party is over. Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> Argh! corrupted error depth, halting fatal error encountered in SBCL pid 60417(tid 136982272): %PRIMITIVE HALT called; the party is over. Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> > This is a fairly unhelpful error, but I'm wondering if the above- mentioned error isn't tickling some bug in the sbcl/freebsd error handling code. This ldb droppage is fairly new, AFAICT. There have certainly been other failure modes, but this one is new and I'm wondering if might be due to recent changes in either SBCL or hunchentoot. In any event, I'll try to get some more info from ldb to see if I can track this down. Cyrus

2 3

[hunchentoot-devel] long living session
by Jens Teich 17 Dec '08

17 Dec '08

I don't get it from the documentation. Sorry for the dumb question. How do I create a session whose cookie does not expire when I close the browser? Still on hunchentoot 0.15.6. Thanks Jens

3 3

[hunchentoot-devel] only simple-string's are allowed for md5:md5sum-sequence
by Anton Vodonosov 09 Dec '08

09 Dec '08

Hello. Huncentoot used md5 library to generate session strings. The function MD5:MD5SUM-SEQUENCE allows only SIMPLE-STRINGs as arguments. Hunchentoot passes result of FORMAT, which is not necessary returns SIMPLE-STRING (although in many implementations it does). In particular just encountered this error when testing Hunchentoot on ECL (with the patch sent by Marko Kocic here: http://common-lisp.net/pipermail/tbnl-devel/2008-November/004474.html) The fix will be as follows: (defun md5-hex (string) "Calculates the md5 sum of the string STRING and returns it as a hex string." (with-output-to-string (s) - (loop for code across (md5:md5sum-sequence string) + (loop for code across (md5:md5sum-sequence (coerce string 'simple-string)) do (format s "~2,'0x" code)))) Best regards, - Anton

3 2

Re: [hunchentoot-devel] handle-static-file
by Frank Schorr 08 Dec '08

08 Dec '08

> -----Ursprüngliche Nachricht----- > Von: "Hans Hübner" <hans(a)huebner.org> > Gesendet: 08.12.08 14:01:16 > An: "General interest list for Hunchentoot and CL-WEBDAV" <tbnl-devel(a)common-lisp.net> > Betreff: Re: [hunchentoot-devel] handle-static-file > On Mon, Dec 8, 2008 at 13:03, Frank Schorr <franks-muc(a)web.de> wrote: > > Is it really necessary to disable debugging in the production environment ? The expected information gained from a thread hanging in the IDE debugger can have a higher weight than the fear of the bad guy exploiting the until then not publicly known bug in the application. It would be interesting to have your thoughts on that. > > It is really up to you: If you want to make sure that no bad guy can > start an indefinite number of debugger threads, disable debugging. I > certainly never run any production system in a mode that makes random > Internet requests end up in a new debugger context, but that is just > my taste. > > Going back to your original inquiry: I think that the invalid > wildcard pathname error that you've produced deserves better handling. > You can try this patch: > > Index: misc.lisp > =================================================================== > --- misc.lisp (revision 4116) > +++ misc.lisp (working copy) > @@ -129,8 +129,9 @@ > denoted by PATH. Send a content type header corresponding to > CONTENT-TYPE or \(if that is NIL) tries to determine the content > type via the file's suffix." > - (unless (and (fad:file-exists-p path) > - (not (fad:directory-exists-p path))) > + (when (or (wild-pathname-p path) > + (not (fad:file-exists-p path)) > + (fad:directory-exists-p path)) > ;; does not exist > (setf (return-code) +http-not-found+) > (throw 'handler-done nil)) > > Please give it a try and let me know if it solves the problem for you. > > -Hans > > _______________________________________________ > tbnl-devel site list > tbnl-devel(a)common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > Problem solved - Thank you ! Frank ____________________________________________________________________ Psssst! Schon vom neuen WEB.DE MultiMessenger gehört? Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123

1 0