From edi at agharta.de  Wed Apr  7 06:08:46 2010
From: edi at agharta.de (Edi Weitz)
Date: Wed, 7 Apr 2010 08:08:46 +0200
Subject: [hunchentoot-devel] suggested imporvement: setting content-type
	with keywords
In-Reply-To: <w2yfd2982321004061505v6ecd9167i591e3c96aed043a4@mail.gmail.com>
References: <af6a3d2d1003221125q647e94b5r67a2453333807f2b@mail.gmail.com>
	<af6a3d2d1003221500y6aada6fdw843366d38e3575@mail.gmail.com>
	<fd2982321003222351p18abb50apee27cd3c3ba043c6@mail.gmail.com>
	<y2iaf6a3d2d1004020727p661ceff6odf55df690202791f@mail.gmail.com>
	<k2ifd2982321004060223p2333082fr1a8110c24ce7e748@mail.gmail.com>
	<n2raf6a3d2d1004061016lc98698d6zb45af053477ec90e@mail.gmail.com>
	<w2yfd2982321004061505v6ecd9167i591e3c96aed043a4@mail.gmail.com>
Message-ID: <v2tb56421a01004062308yc8b38d10gca0392a73ba64358@mail.gmail.com>

I'm taking this back to the mailing list.  I think there's no need to
discuss this in private.

FWIW, I agree with Hans and don't think this is a very useful patch.
You argue that with the patch you won't have to memorize mime types,
but then you'll have to memorize file suffixes instead.  And even if
you don't need to learn them (as many of those suffixes have become
second nature to us), they are a pretty arbitrary classification from
the olden days of operating systems.  Finally, how many different mime
types will you use in a typical web application?  Is it such a big
deal?

Thanks,
Edi.



On Wed, Apr 7, 2010 at 12:05 AM, Hans H?bner <hans.huebner at gmail.com> wrote:
> Ala'a,
>
> hereby I forward your reply to Edi. ?I think the basic concern is that
> MIME types are standardized, whereas keywords are not, and that it is
> not clear what keywords are supported and how keywords would be added.
> ?I agree with you that abstraction is good, but it is good only if it
> does not break easily, because, say, no new MIME types can be added,
> or there is ambiguity between MIME types and keywords as in the case
> of XML. ?Sometimes, something that first seemed simple and
> straightforward becomes cumbersome and ugly. ?This is not to say that
> your patch is in that class, I'm just saying that there may be valid
> counterarguments against including such a simple thing in the base
> HTTP surrogate because it does not scale beyond the simple use cases
> provoided as example.
>
> That said, let's see if Edi has an opinion.
>
> -Hans
>
>
> ---------- Forwarded message ----------
> From: Ala'a (cmo-0) <amalawi at gmail.com>
> Date: Tue, Apr 6, 2010 at 19:16
> Subject: Re: [hunchentoot-devel] suggested imporvement: setting
> content-type with keywords
> To: Hans H?bner <hans.huebner at gmail.com>
>
>
> Hi Hans,
>
> I understand, thus the followings are the motives/notes/thoughts
> regarding the patch:
>
> - As a developer I do not want to be concerned/or memorize that
> sending pdf should be
> ?using "application/pdf". The details of mime types should be hidden
> (a kind of abstraction)
> ?in other words, moving from constructing the details of the response
> (as much as possible),
> ?and concentrating on the task at hand which is developing the web
> content (js, ajax, html
> ?and other content dynamic and/or static). In general there is no
> productivity boost, except
> ?to avoid looking for the right mime type, Is it
> application/something? or text/something?
> ?Maybe its time for googling mime types again ;)
>
> - There are some uses of keyword designators in the API (like in
> *lisp-errors-log-level* and
> ?the use of :post :get and :both in define-esay-handler) which could
> be strings, so I
> ?thought/assumed that my patch will not be a stranger within the current API.
>
> - Still the API is backward compatible, there is no need to force the
> users to use the new
> ?designator. And the code uses the already built in database for mime types.
>
> - This patch can propagate the API abstraction upward and be used by
> other extension (maybe another patch) like:
> (defun set-content-spec (mime-type-designator &optional
> disposition-type filename) ...)
> where
> mime-type-designator: the same value as taken by (setf content-type*).
> filename: the name of sent content.
> disposition-type: is either :inline (open within the browser) or
> :attachment (open a save-as dialog).
> so I can say something like:
> (defun lpo-pdf ()
> ?(let ((lpo (query-for-lpo ...))) ;lpo is short for: local purchase order
> ? ? (set-content-spec :pdf :attachment (format nil "~A.pdf" (serial lpo)))
> ? ? (generate-pdf-content)))
>
> sheesh, this is almost triple the size of the patch ;)
>
> Regards,
>
> Ala'a (cmo-0)
>
>



From edi at agharta.de  Wed Apr  7 06:23:44 2010
From: edi at agharta.de (Edi Weitz)
Date: Wed, 7 Apr 2010 08:23:44 +0200
Subject: [hunchentoot-devel] suggested imporvement: setting content-type
	with keywords
In-Reply-To: <v2tb56421a01004062308yc8b38d10gca0392a73ba64358@mail.gmail.com>
References: <af6a3d2d1003221125q647e94b5r67a2453333807f2b@mail.gmail.com>
	<af6a3d2d1003221500y6aada6fdw843366d38e3575@mail.gmail.com>
	<fd2982321003222351p18abb50apee27cd3c3ba043c6@mail.gmail.com>
	<y2iaf6a3d2d1004020727p661ceff6odf55df690202791f@mail.gmail.com>
	<k2ifd2982321004060223p2333082fr1a8110c24ce7e748@mail.gmail.com>
	<n2raf6a3d2d1004061016lc98698d6zb45af053477ec90e@mail.gmail.com>
	<w2yfd2982321004061505v6ecd9167i591e3c96aed043a4@mail.gmail.com>
	<v2tb56421a01004062308yc8b38d10gca0392a73ba64358@mail.gmail.com>
Message-ID: <v2xb56421a01004062323nd2e0e656y688c6a4e843a4afc@mail.gmail.com>

What I forgot: The function MIME-TYPE is already exported.  If you
don't want to memorize mime types, you can simply use that function.

On Wed, Apr 7, 2010 at 8:08 AM, Edi Weitz <edi at agharta.de> wrote:
> I'm taking this back to the mailing list. ?I think there's no need to
> discuss this in private.
>
> FWIW, I agree with Hans and don't think this is a very useful patch.
> You argue that with the patch you won't have to memorize mime types,
> but then you'll have to memorize file suffixes instead. ?And even if
> you don't need to learn them (as many of those suffixes have become
> second nature to us), they are a pretty arbitrary classification from
> the olden days of operating systems. ?Finally, how many different mime
> types will you use in a typical web application? ?Is it such a big
> deal?
>
> Thanks,
> Edi.
>
>
>
> On Wed, Apr 7, 2010 at 12:05 AM, Hans H?bner <hans.huebner at gmail.com> wrote:
>> Ala'a,
>>
>> hereby I forward your reply to Edi. ?I think the basic concern is that
>> MIME types are standardized, whereas keywords are not, and that it is
>> not clear what keywords are supported and how keywords would be added.
>> ?I agree with you that abstraction is good, but it is good only if it
>> does not break easily, because, say, no new MIME types can be added,
>> or there is ambiguity between MIME types and keywords as in the case
>> of XML. ?Sometimes, something that first seemed simple and
>> straightforward becomes cumbersome and ugly. ?This is not to say that
>> your patch is in that class, I'm just saying that there may be valid
>> counterarguments against including such a simple thing in the base
>> HTTP surrogate because it does not scale beyond the simple use cases
>> provoided as example.
>>
>> That said, let's see if Edi has an opinion.
>>
>> -Hans
>>
>>
>> ---------- Forwarded message ----------
>> From: Ala'a (cmo-0) <amalawi at gmail.com>
>> Date: Tue, Apr 6, 2010 at 19:16
>> Subject: Re: [hunchentoot-devel] suggested imporvement: setting
>> content-type with keywords
>> To: Hans H?bner <hans.huebner at gmail.com>
>>
>>
>> Hi Hans,
>>
>> I understand, thus the followings are the motives/notes/thoughts
>> regarding the patch:
>>
>> - As a developer I do not want to be concerned/or memorize that
>> sending pdf should be
>> ?using "application/pdf". The details of mime types should be hidden
>> (a kind of abstraction)
>> ?in other words, moving from constructing the details of the response
>> (as much as possible),
>> ?and concentrating on the task at hand which is developing the web
>> content (js, ajax, html
>> ?and other content dynamic and/or static). In general there is no
>> productivity boost, except
>> ?to avoid looking for the right mime type, Is it
>> application/something? or text/something?
>> ?Maybe its time for googling mime types again ;)
>>
>> - There are some uses of keyword designators in the API (like in
>> *lisp-errors-log-level* and
>> ?the use of :post :get and :both in define-esay-handler) which could
>> be strings, so I
>> ?thought/assumed that my patch will not be a stranger within the current API.
>>
>> - Still the API is backward compatible, there is no need to force the
>> users to use the new
>> ?designator. And the code uses the already built in database for mime types.
>>
>> - This patch can propagate the API abstraction upward and be used by
>> other extension (maybe another patch) like:
>> (defun set-content-spec (mime-type-designator &optional
>> disposition-type filename) ...)
>> where
>> mime-type-designator: the same value as taken by (setf content-type*).
>> filename: the name of sent content.
>> disposition-type: is either :inline (open within the browser) or
>> :attachment (open a save-as dialog).
>> so I can say something like:
>> (defun lpo-pdf ()
>> ?(let ((lpo (query-for-lpo ...))) ;lpo is short for: local purchase order
>> ? ? (set-content-spec :pdf :attachment (format nil "~A.pdf" (serial lpo)))
>> ? ? (generate-pdf-content)))
>>
>> sheesh, this is almost triple the size of the patch ;)
>>
>> Regards,
>>
>> Ala'a (cmo-0)
>>
>>
>



From edi at agharta.de  Wed Apr  7 06:29:37 2010
From: edi at agharta.de (Edi Weitz)
Date: Wed, 7 Apr 2010 08:29:37 +0200
Subject: [hunchentoot-devel] PATCH: simplify debugging of remote servers
In-Reply-To: <e0c33b911003091104i1bdccc52l6116ba83840690ea@mail.gmail.com>
References: <e0c33b911003061715l38339016i4ebcf47d903c77af@mail.gmail.com>
	<fd2982321003062303l76d41178t83da1f7f32b01bb9@mail.gmail.com>
	<e0c33b911003070037o1d399adaib248707f2f503810@mail.gmail.com>
	<b56421a01003070240n7af70a17m9d6349a46d44de83@mail.gmail.com>
	<e0c33b911003070431s72c279aci52b5241293917926@mail.gmail.com>
	<fd2982321003070445n478f1101qca63c1e0d8de009e@mail.gmail.com>
	<e0c33b911003090349p6365f1ddvfdb4f260ae66f5ba@mail.gmail.com>
	<fd2982321003090833w2a8923b0w935c880417e0d63a@mail.gmail.com>
	<e0c33b911003091104i1bdccc52l6116ba83840690ea@mail.gmail.com>
Message-ID: <v2sb56421a01004062329vb2339254p77facbc97e71a93b@mail.gmail.com>

Hi,

I've just removed this patch as it breaks the LispWorks version.  Feel
free to re-submit a cleaned-up version.

Thanks,
Edi.


On Tue, Mar 9, 2010 at 8:04 PM, Andrey Moskvitin <archimag at gmail.com> wrote:
> Hi,
>> I committed your patches - after editing - to the svn repository.
> Great!
> Thank you very much :)
> Andrey
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From amalawi at gmail.com  Wed Apr  7 14:49:37 2010
From: amalawi at gmail.com (Ala'a (cmo-0))
Date: Wed, 7 Apr 2010 18:49:37 +0400
Subject: [hunchentoot-devel] suggested imporvement: setting content-type
	with keywords
In-Reply-To: <v2tb56421a01004062308yc8b38d10gca0392a73ba64358@mail.gmail.com>
References: <af6a3d2d1003221125q647e94b5r67a2453333807f2b@mail.gmail.com> 
	<af6a3d2d1003221500y6aada6fdw843366d38e3575@mail.gmail.com> 
	<fd2982321003222351p18abb50apee27cd3c3ba043c6@mail.gmail.com> 
	<y2iaf6a3d2d1004020727p661ceff6odf55df690202791f@mail.gmail.com> 
	<k2ifd2982321004060223p2333082fr1a8110c24ce7e748@mail.gmail.com> 
	<n2raf6a3d2d1004061016lc98698d6zb45af053477ec90e@mail.gmail.com> 
	<w2yfd2982321004061505v6ecd9167i591e3c96aed043a4@mail.gmail.com> 
	<v2tb56421a01004062308yc8b38d10gca0392a73ba64358@mail.gmail.com>
Message-ID: <z2qaf6a3d2d1004070749id9901f19m5e936794192b75d7@mail.gmail.com>

Hi Edi,

Its not a memorizing issue per se, rather its all points together
(designators convenience).

I agree with Hans about the XML types (and others as well) where I'll need
to search the web. The patch was designed with :pdf, :jpeg, :gif, :svg, :png in
mind (the cases used regularly).

Before the patch I tried mime-type function. It needs a pathname designator,
however, this will work:

(setf (content-type*) (mime-type ".pdf"))

The final word is yours ;)

Regards,

Ala'a (cmo-0)

On Wed, Apr 7, 2010 at 10:08 AM, Edi Weitz <edi at agharta.de> wrote:
> I'm taking this back to the mailing list. ?I think there's no need to
> discuss this in private.
>
> FWIW, I agree with Hans and don't think this is a very useful patch.
> You argue that with the patch you won't have to memorize mime types,
> but then you'll have to memorize file suffixes instead. ?And even if
> you don't need to learn them (as many of those suffixes have become
> second nature to us), they are a pretty arbitrary classification from
> the olden days of operating systems. ?Finally, how many different mime
> types will you use in a typical web application? ?Is it such a big
> deal?
>
> Thanks,
> Edi.
>
>
>
> On Wed, Apr 7, 2010 at 12:05 AM, Hans H?bner <hans.huebner at gmail.com> wrote:
>> Ala'a,
>>
>> hereby I forward your reply to Edi. ?I think the basic concern is that
>> MIME types are standardized, whereas keywords are not, and that it is
>> not clear what keywords are supported and how keywords would be added.
>> ?I agree with you that abstraction is good, but it is good only if it
>> does not break easily, because, say, no new MIME types can be added,
>> or there is ambiguity between MIME types and keywords as in the case
>> of XML. ?Sometimes, something that first seemed simple and
>> straightforward becomes cumbersome and ugly. ?This is not to say that
>> your patch is in that class, I'm just saying that there may be valid
>> counterarguments against including such a simple thing in the base
>> HTTP surrogate because it does not scale beyond the simple use cases
>> provoided as example.
>>
>> That said, let's see if Edi has an opinion.
>>
>> -Hans
>>
>>
>> ---------- Forwarded message ----------
>> From: Ala'a (cmo-0) <amalawi at gmail.com>
>> Date: Tue, Apr 6, 2010 at 19:16
>> Subject: Re: [hunchentoot-devel] suggested imporvement: setting
>> content-type with keywords
>> To: Hans H?bner <hans.huebner at gmail.com>
>>
>>
>> Hi Hans,
>>
>> I understand, thus the followings are the motives/notes/thoughts
>> regarding the patch:
>>
>> - As a developer I do not want to be concerned/or memorize that
>> sending pdf should be
>> ?using "application/pdf". The details of mime types should be hidden
>> (a kind of abstraction)
>> ?in other words, moving from constructing the details of the response
>> (as much as possible),
>> ?and concentrating on the task at hand which is developing the web
>> content (js, ajax, html
>> ?and other content dynamic and/or static). In general there is no
>> productivity boost, except
>> ?to avoid looking for the right mime type, Is it
>> application/something? or text/something?
>> ?Maybe its time for googling mime types again ;)
>>
>> - There are some uses of keyword designators in the API (like in
>> *lisp-errors-log-level* and
>> ?the use of :post :get and :both in define-esay-handler) which could
>> be strings, so I
>> ?thought/assumed that my patch will not be a stranger within the current API.
>>
>> - Still the API is backward compatible, there is no need to force the
>> users to use the new
>> ?designator. And the code uses the already built in database for mime types.
>>
>> - This patch can propagate the API abstraction upward and be used by
>> other extension (maybe another patch) like:
>> (defun set-content-spec (mime-type-designator &optional
>> disposition-type filename) ...)
>> where
>> mime-type-designator: the same value as taken by (setf content-type*).
>> filename: the name of sent content.
>> disposition-type: is either :inline (open within the browser) or
>> :attachment (open a save-as dialog).
>> so I can say something like:
>> (defun lpo-pdf ()
>> ?(let ((lpo (query-for-lpo ...))) ;lpo is short for: local purchase order
>> ? ? (set-content-spec :pdf :attachment (format nil "~A.pdf" (serial lpo)))
>> ? ? (generate-pdf-content)))
>>
>> sheesh, this is almost triple the size of the patch ;)
>>
>> Regards,
>>
>> Ala'a (cmo-0)
>>
>>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From sebyte at smolny.plus.com  Tue Apr 13 13:53:57 2010
From: sebyte at smolny.plus.com (Sebastian Tennant)
Date: Tue, 13 Apr 2010 13:53:57 +0000
Subject: [hunchentoot-devel] UTF-8 encoding problems
Message-ID: <hbnfa26i.fsf@vps203.linuxvps.org>

Hi all,

CL-USER> (hunchentoot-asd:*hunchentoot-version*)
"1.1.0"

With:

  (setq tbnl:*default-content-type* "text/html; charset=utf-8")

called once when TBNL is initialised, Turkish characters provided in Lisp
source files are sent to the client without a problem, but Turkish characters
that come from a UTF-8 database via Postmodern cause the following error:

  Error while processing connection: #\LATIN_SMALL_LETTER_DOTLESS_I (code 305)
  is not a LATIN-1 character.

before they can be sent to the client.

Why does TBNL expect LATIN-1 characters in one context but not in another?
 
Incidentally, I experience the same 'not a LATIN-1 character' error when I
evaluate Lisp files via SLIME, but not when the files are load'ed.

Putting:

  (setf (content-type*) "text/html; charset=utf-8") 

in the handler makes no difference.

What else can I try?

Seb

P.S. Turkish characters in the results of Postmodern queries performed directly
     in the REPL are displayed (in SLIME) correctly.

-- 
Emacs' AlsaPlayer - Music Without Jolts
Lightweight, full-featured and mindful of your idyllic happiness.
http://home.gna.org/eap




From archimag at gmail.com  Tue Apr 13 14:11:39 2010
From: archimag at gmail.com (Andrey Moskvitin)
Date: Tue, 13 Apr 2010 18:11:39 +0400
Subject: [hunchentoot-devel] UTF-8 encoding problems
In-Reply-To: <hbnfa26i.fsf@vps203.linuxvps.org>
References: <hbnfa26i.fsf@vps203.linuxvps.org>
Message-ID: <p2je0c33b911004130711ha5fd8230r28daa988150bdd85@mail.gmail.com>

> What else can I try?

(setf hunchentoot:*hunchentoot-default-external-format*
hunchentoot::+utf-8+)


Andrey

2010/4/13 Sebastian Tennant <sebyte at smolny.plus.com>

> Hi all,
>
> CL-USER> (hunchentoot-asd:*hunchentoot-version*)
> "1.1.0"
>
> With:
>
>  (setq tbnl:*default-content-type* "text/html; charset=utf-8")
>
> called once when TBNL is initialised, Turkish characters provided in Lisp
> source files are sent to the client without a problem, but Turkish
> characters
> that come from a UTF-8 database via Postmodern cause the following error:
>
>  Error while processing connection: #\LATIN_SMALL_LETTER_DOTLESS_I (code
> 305)
>  is not a LATIN-1 character.
>
> before they can be sent to the client.
>
> Why does TBNL expect LATIN-1 characters in one context but not in another?
>
> Incidentally, I experience the same 'not a LATIN-1 character' error when I
> evaluate Lisp files via SLIME, but not when the files are load'ed.
>
> Putting:
>
>  (setf (content-type*) "text/html; charset=utf-8")
>
> in the handler makes no difference.
>
> What else can I try?
>
> Seb
>
> P.S. Turkish characters in the results of Postmodern queries performed
> directly
>     in the REPL are displayed (in SLIME) correctly.
>
> --
> Emacs' AlsaPlayer - Music Without Jolts
> Lightweight, full-featured and mindful of your idyllic happiness.
> http://home.gna.org/eap
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20100413/28bcb32e/attachment.html>

From sebyte at smolny.plus.com  Wed Apr 14 11:13:53 2010
From: sebyte at smolny.plus.com (Sebastian Tennant)
Date: Wed, 14 Apr 2010 11:13:53 +0000
Subject: [hunchentoot-devel] UTF-8 encoding problems
References: <hbnfa26i.fsf@vps203.linuxvps.org>
	<p2je0c33b911004130711ha5fd8230r28daa988150bdd85@mail.gmail.com>
Message-ID: <iq7u1e32.fsf@vps203.linuxvps.org>

Quoth Andrey Moskvitin <archimag at gmail.com>:
> (setf hunchentoot:*hunchentoot-default-external-format* hunchentoot::+utf-8+)

Damn! This time it is making a difference :)  Thanks.

I tried setting this variable (without success) when I wrote to this list about
the evaluation-versus-load'ing oddity a while back:

 http://thread.gmane.org/gmane.lisp.lib.tbnl.general/2523

I was also told:

 "As explained in the documentation, the special variable
 *HUNCHENTOOT-DEFAULT-EXTERNAL-FORMAT* is used when computing the /request/
 object.  As you said, it doesn't have an effect on the reply."

Hence I didn't try it again this time round.

If it's only used to compute the request object, why is it now helping with
(some of) my UTF-8 replies?

Seb
-- 
Emacs' AlsaPlayer - Music Without Jolts
Lightweight, full-featured and mindful of your idyllic happiness.
http://home.gna.org/eap




From jeremy.reimer at gmail.com  Wed Apr 14 22:59:57 2010
From: jeremy.reimer at gmail.com (Jeremy Reimer)
Date: Wed, 14 Apr 2010 15:59:57 -0700
Subject: [hunchentoot-devel] Status of Kevin Rosenberg and b9.com?
Message-ID: <x2sebb417091004141559q86ff4b79ged3ed9c693446349@mail.gmail.com>

Hello,

I am getting into LISP and I have found the wonderful Hunchentoot web server
project.  I am in the process of installing it but I have run into a strange
roadblock.

I have installed SBCL and Slime, and I am at this point:

$ sudo sbcl
* (require 'asdf-install)
* (asdf-install:install :hunchentoot)

The asdf installer scripts reference some dependencies such as MD5
and CL-BASE64, which attempt to download packages at files.b9.com, run
by Kevin Rosenberg, but *.b9.com is currently not responding at all
(and hasn?t for several days) and there seems to be no way to contact
Kevin to inquire about the status of his web sites.  Do you know what has
happened to Kevin?  And if not, how can I install Hutchentoot?

Thank you for any help you can give me!

Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20100414/3c596ce4/attachment.html>

From hans.huebner at gmail.com  Thu Apr 15 07:02:30 2010
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Thu, 15 Apr 2010 09:02:30 +0200
Subject: [hunchentoot-devel] Status of Kevin Rosenberg and b9.com?
In-Reply-To: <x2sebb417091004141559q86ff4b79ged3ed9c693446349@mail.gmail.com>
References: <x2sebb417091004141559q86ff4b79ged3ed9c693446349@mail.gmail.com>
Message-ID: <m2wfd2982321004150002n1ebe1887r4ba4d61e3a9d6664@mail.gmail.com>

Jeremy,

the easiest way to get Hunchentoot and all of its dependencies is to
use Subversion:

svn co http://bknr.net/svn/ediware

Regards,
Hans

On Thu, Apr 15, 2010 at 00:59, Jeremy Reimer <jeremy.reimer at gmail.com> wrote:
> Hello,
> I am getting into LISP and I have found the wonderful Hunchentoot web?server
> project. ?I am in the process of installing it but I have run?into a strange
> roadblock.
> I have installed SBCL and Slime, and I am at this point:
> $ sudo sbcl
> *?(require 'asdf-install)
> * (asdf-install:install :hunchentoot)
> The asdf installer scripts reference some dependencies such as MD5
> and?CL-BASE64, which attempt to download packages at files.b9.com, run
> by?Kevin Rosenberg, but *.b9.com is currently not responding at all
> (and?hasn?t for several days) and there seems to be no way to contact
> Kevin?to inquire about the status of his web sites. ?Do you know what has
> happened to Kevin? ?And if not, how can I install Hutchentoot?
> Thank you for any help you can give me!
> Jeremy
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From jeremy.reimer at gmail.com  Thu Apr 15 22:51:21 2010
From: jeremy.reimer at gmail.com (Jeremy Reimer)
Date: Thu, 15 Apr 2010 15:51:21 -0700
Subject: [hunchentoot-devel] Status of Kevin Rosenberg and b9.com?
In-Reply-To: <m2wfd2982321004150002n1ebe1887r4ba4d61e3a9d6664@mail.gmail.com>
References: <x2sebb417091004141559q86ff4b79ged3ed9c693446349@mail.gmail.com>
	<m2wfd2982321004150002n1ebe1887r4ba4d61e3a9d6664@mail.gmail.com>
Message-ID: <l2tebb417091004151551kc5192669s93d1e694dcfe537c@mail.gmail.com>

Thanks Hans!  I did this and you're right, it's really easy to grab the
latest version and all the dependencies with SVN.  However I'm a bit
confused about how to proceed to compile from source from all these .lisp
files.  Do I still use asdf, and if so how do I point to the
newly-downloaded source?

Sorry about the complete newb questions, I've been going through various
tutorials on the web about Hunchentoot and none of them mention using SVN.

Thanks again,

Jeremy

On Thu, Apr 15, 2010 at 12:02 AM, Hans H?bner <hans.huebner at gmail.com>wrote:

> Jeremy,
>
> the easiest way to get Hunchentoot and all of its dependencies is to
> use Subversion:
>
> svn co http://bknr.net/svn/ediware
>
> Regards,
> Hans
>
> On Thu, Apr 15, 2010 at 00:59, Jeremy Reimer <jeremy.reimer at gmail.com>
> wrote:
> > Hello,
> > I am getting into LISP and I have found the wonderful Hunchentoot
> web server
> > project.  I am in the process of installing it but I have run into a
> strange
> > roadblock.
> > I have installed SBCL and Slime, and I am at this point:
> > $ sudo sbcl
> > * (require 'asdf-install)
> > * (asdf-install:install :hunchentoot)
> > The asdf installer scripts reference some dependencies such as MD5
> > and CL-BASE64, which attempt to download packages at files.b9.com, run
> > by Kevin Rosenberg, but *.b9.com is currently not responding at all
> > (and hasn?t for several days) and there seems to be no way to contact
> > Kevin to inquire about the status of his web sites.  Do you know what has
> > happened to Kevin?  And if not, how can I install Hutchentoot?
> > Thank you for any help you can give me!
> > Jeremy
> > _______________________________________________
> > tbnl-devel site list
> > tbnl-devel at common-lisp.net
> > http://common-lisp.net/mailman/listinfo/tbnl-devel
> >
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20100415/a5de2977/attachment.html>

From hans.huebner at gmail.com  Fri Apr 16 05:48:23 2010
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Fri, 16 Apr 2010 07:48:23 +0200
Subject: [hunchentoot-devel] Status of Kevin Rosenberg and b9.com?
In-Reply-To: <l2tebb417091004151551kc5192669s93d1e694dcfe537c@mail.gmail.com>
References: <x2sebb417091004141559q86ff4b79ged3ed9c693446349@mail.gmail.com> 
	<m2wfd2982321004150002n1ebe1887r4ba4d61e3a9d6664@mail.gmail.com> 
	<l2tebb417091004151551kc5192669s93d1e694dcfe537c@mail.gmail.com>
Message-ID: <s2kfd2982321004152248se209aa93z205f69e49a4667d7@mail.gmail.com>

Hi Jeremy,

On Fri, Apr 16, 2010 at 00:51, Jeremy Reimer <jeremy.reimer at gmail.com> wrote:
> However I'm a bit confused about how to proceed to compile from source from all these .lisp
> files. ?Do I still use asdf, and if so how do I point to the newly-downloaded source?
> Sorry about the complete newb questions, I've been going through various
> tutorials on the web about Hunchentoot and none of them mention using SVN.

You ran into the "Common Lisp package management is a mess" wall, but
don't despair, it is not that hard.

asdf is the predominant system building facility, make-alike if you
will.  asdf-install is just an add-on, but it is not used by many open
source developers and thus not well supported.

Have a look at http://common-lisp.net/~mmommer/asdf-howto.shtml - In
the end, it explains how you point asdf at your system definition
files.

-Hans



From semion.ababo at gmail.com  Wed Apr 21 16:41:32 2010
From: semion.ababo at gmail.com (Semion Prikhodko)
Date: Wed, 21 Apr 2010 19:41:32 +0300
Subject: [hunchentoot-devel] Hunchentoot effective DOS-attack
Message-ID: <1271868092.28674.0.camel@altermoby.com>

Hi, guys.

I have exactly the problem described in
http://common-lisp.net/pipermail/tbnl-devel/2009-July/004757.html

I have found there a patch:
http://bknr.net/trac/changeset/4435?format=diff&new=4435

but seems it cannot be applied on my vesion of Hunchentoot (mine is
1.0.0, it slightly different). Is this issue fixed in Hunchentoot 1.1?
Thanks in advance.





From semion.ababo at gmail.com  Wed Apr 21 15:00:18 2010
From: semion.ababo at gmail.com (Semion Prikhodko)
Date: Wed, 21 Apr 2010 18:00:18 +0300
Subject: [hunchentoot-devel] Hunchentoot effective DOS-attack
Message-ID: <1271862018.27261.4.camel@altermoby.com>

Hi, guys.

I have exactly the problem described in
http://common-lisp.net/pipermail/tbnl-devel/2009-July/004757.html

I have found there a patch:
http://bknr.net/trac/changeset/4435?format=diff&new=4435

but seems it cannot be applied on my vesion of Hunchentoot (mine is
1.0.0, it slightly different). Is this issue fixed in Hunchentoot 1.1?
Thanks in advance.




From hans.huebner at gmail.com  Wed Apr 21 20:02:13 2010
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Wed, 21 Apr 2010 22:02:13 +0200
Subject: [hunchentoot-devel] Hunchentoot effective DOS-attack
In-Reply-To: <1271862018.27261.4.camel@altermoby.com>
References: <1271862018.27261.4.camel@altermoby.com>
Message-ID: <m2wfd2982321004211302rcebd5ed3g35f2619fb732e867@mail.gmail.com>

Semion,

the patch that you refered to does not seem to address the problem
that you describe.  Did you send the right link?

In any case, the usocket version in the BKNR repository does not
translate SBCL's NOT-CONNECTED-ERROR, so a proper usocket patch would
be required.  Can you provide one?

Thanks,
-Hans

On Wed, Apr 21, 2010 at 17:00, Semion Prikhodko <semion.ababo at gmail.com> wrote:
> Hi, guys.
>
> I have exactly the problem described in
> http://common-lisp.net/pipermail/tbnl-devel/2009-July/004757.html
>
> I have found there a patch:
> http://bknr.net/trac/changeset/4435?format=diff&new=4435
>
> but seems it cannot be applied on my vesion of Hunchentoot (mine is
> 1.0.0, it slightly different). Is this issue fixed in Hunchentoot 1.1?
> Thanks in advance.
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From bohmer at gmail.com  Fri Apr 23 12:12:15 2010
From: bohmer at gmail.com (=?ISO-8859-1?Q?Knut_Olav_B=F8hmer?=)
Date: Fri, 23 Apr 2010 14:12:15 +0200
Subject: [hunchentoot-devel] parameter-type hash-table encoded with [] or {}
Message-ID: <u2gb00235701004230512m3f2e136bz2598e25c81489185@mail.gmail.com>

Hi,

When I post json objects from jquery

$.ajax({
        type: 'POST',
        url: '/url',
        dataType: 'json',
        data:  {"key":"val","hash",{"foo":"bar"}}

then the "hash" parameter is posted like this: "hash[foo]=bar"

If I then in hunchentoot have

(define-easy-handler (fn :uri "/url")
    ((hash :parameter-type 'hash-table))
.....

The hash is expected to be posted like this: "hash{foo}=bar"?
So I wonder if it would be correct to enable the "hash[foo]=bar" syntax for
hash tables.

Maybe it should be an argument that specifies if
compute-hash-table-parameter should use [] or {}.
This little experiment worked for me, here I just added \\[ and \\] to the
regexp.

Should I bother to make a patch?

(defun compute-hash-table-parameter (parameter-name type parameters key-type
test-function)
  "Retrieves all parameters from PARAMETERS which are named
like

\"PARAMETER-NAME{FOO}\" or \"PARAMETER-NAME[FOO]\"  \(where FOO is any
sequence of
characters

not containing curly brackets), converts them to TYPE,
and

returns a hash table with test function TEST-FUNCTION where
the

corresponding value is associated with the key FOO \(converted
to

KEY-TYPE)."
  (let ((hash-table (make-hash-table :test test-function)))
    (loop for (full-name . value) in parameters
          for key = (register-groups-bind (name key-string)
                        ("^(.*)[{\\[]([^\\[\\]{}]+)[}\\]]$" full-name)
                      (when (string= name parameter-name)
                        (convert-parameter key-string key-type)))
          when key
          do (setf (gethash key hash-table)
                   (convert-parameter value type)))
    hash-table))


-- 
Knut Olav B?hmer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20100423/0b381f77/attachment.html>

From edi at agharta.de  Fri Apr 23 20:05:57 2010
From: edi at agharta.de (Edi Weitz)
Date: Fri, 23 Apr 2010 22:05:57 +0200
Subject: [hunchentoot-devel] parameter-type hash-table encoded with []
	or {}
In-Reply-To: <u2gb00235701004230512m3f2e136bz2598e25c81489185@mail.gmail.com>
References: <u2gb00235701004230512m3f2e136bz2598e25c81489185@mail.gmail.com>
Message-ID: <y2wb56421a01004231305ieed41c63w62bdb877b7d857f7@mail.gmail.com>

Making this customizable would be OK with me.  The only problem I see
is that the current pair of delimiters is hard-coded into the regexp
and it's probably not a good idea to compute the regexp anew each time
the function is called.  I also think only paired delimiters like (),
[], {}, <> really make sense.  Any comments?

If you want to have this in Hunchentoot, please send a patch against
the diff version following the usual guidelines:

http://weitz.de/patches.html

Thanks,
Edi.


2010/4/23 Knut Olav B?hmer <bohmer at gmail.com>:
> Hi,
>
> When I post json objects from jquery
>
> $.ajax({
> ??? ??? type: 'POST',
> ??? ??? url: '/url',
> ??? ??? dataType: 'json',
> ??? ??? data:? {"key":"val","hash",{"foo":"bar"}}
>
> then the "hash" parameter is posted like this: "hash[foo]=bar"
>
> If I then in hunchentoot have
>
> (define-easy-handler (fn :uri "/url")
> ??? ((hash :parameter-type 'hash-table))
> .....
>
> The hash is expected to be posted like this: "hash{foo}=bar"?
> So I wonder if it would be correct to enable the "hash[foo]=bar" syntax for
> hash tables.
>
> Maybe it should be an argument that specifies if
> compute-hash-table-parameter should use [] or {}.
> This little experiment worked for me, here I just added \\[ and \\] to the
> regexp.
>
> Should I bother to make a patch?
>
> (defun compute-hash-table-parameter (parameter-name type parameters key-type
> test-function)
> ? "Retrieves all parameters from PARAMETERS which are named
> like
> \"PARAMETER-NAME{FOO}\" or \"PARAMETER-NAME[FOO]\"? \(where FOO is any
> sequence of
> characters
> not containing curly brackets), converts them to TYPE,
> and
> returns a hash table with test function TEST-FUNCTION where
> the
> corresponding value is associated with the key FOO \(converted
> to
> KEY-TYPE)."
> ? (let ((hash-table (make-hash-table :test test-function)))
> ??? (loop for (full-name . value) in parameters
> ????????? for key = (register-groups-bind (name key-string)
> ??????????????????????? ("^(.*)[{\\[]([^\\[\\]{}]+)[}\\]]$" full-name)
> ????????????????????? (when (string= name parameter-name)
> ??????????????????????? (convert-parameter key-string key-type)))
> ????????? when key
> ????????? do (setf (gethash key hash-table)
> ?????????????????? (convert-parameter value type)))
> ??? hash-table))
>
>
> --
> Knut Olav B?hmer
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From edi at agharta.de  Fri Apr 23 20:06:33 2010
From: edi at agharta.de (Edi Weitz)
Date: Fri, 23 Apr 2010 22:06:33 +0200
Subject: [hunchentoot-devel] parameter-type hash-table encoded with []
	or {}
In-Reply-To: <y2wb56421a01004231305ieed41c63w62bdb877b7d857f7@mail.gmail.com>
References: <u2gb00235701004230512m3f2e136bz2598e25c81489185@mail.gmail.com>
	<y2wb56421a01004231305ieed41c63w62bdb877b7d857f7@mail.gmail.com>
Message-ID: <v2sb56421a01004231306v921ef07aobf4369695668b4cd@mail.gmail.com>

On Fri, Apr 23, 2010 at 10:05 PM, Edi Weitz <edi at agharta.de> wrote:

> If you want to have this in Hunchentoot, please send a patch against
> the diff version

Cough.  The /dev/ version of course... :)



From bohmer at gmail.com  Fri Apr 23 20:38:02 2010
From: bohmer at gmail.com (=?ISO-8859-1?Q?Knut_Olav_B=F8hmer?=)
Date: Fri, 23 Apr 2010 22:38:02 +0200
Subject: [hunchentoot-devel] parameter-type hash-table encoded with []
	or {}
In-Reply-To: <v2sb56421a01004231306v921ef07aobf4369695668b4cd@mail.gmail.com>
References: <u2gb00235701004230512m3f2e136bz2598e25c81489185@mail.gmail.com>
	<y2wb56421a01004231305ieed41c63w62bdb877b7d857f7@mail.gmail.com>
	<v2sb56421a01004231306v921ef07aobf4369695668b4cd@mail.gmail.com>
Message-ID: <p2rb00235701004231338x8617ef26p6df54019a9008c57@mail.gmail.com>

On 23 April 2010 22:06, Edi Weitz <edi at agharta.de> wrote:

> On Fri, Apr 23, 2010 at 10:05 PM, Edi Weitz <edi at agharta.de> wrote:
>
> > If you want to have this in Hunchentoot, please send a patch against
> > the diff version
>
> Cough.  The /dev/ version of course... :)
>

I tried darcs clone  http://common-lisp.net/~loliveira/ediware/hunchentoot
But how do I know that I have The /dev/ version?


-- 
Knut Olav B?hmer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20100423/9dc2dd25/attachment.html>

From hans.huebner at gmail.com  Fri Apr 23 22:08:20 2010
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Sat, 24 Apr 2010 00:08:20 +0200
Subject: [hunchentoot-devel] parameter-type hash-table encoded with []
	or {}
In-Reply-To: <p2rb00235701004231338x8617ef26p6df54019a9008c57@mail.gmail.com>
References: <u2gb00235701004230512m3f2e136bz2598e25c81489185@mail.gmail.com> 
	<y2wb56421a01004231305ieed41c63w62bdb877b7d857f7@mail.gmail.com> 
	<v2sb56421a01004231306v921ef07aobf4369695668b4cd@mail.gmail.com> 
	<p2rb00235701004231338x8617ef26p6df54019a9008c57@mail.gmail.com>
Message-ID: <w2xfd2982321004231508i8dc2fc13j2938c7615ef1e789@mail.gmail.com>

2010/4/23 Knut Olav B?hmer <bohmer at gmail.com>:
> I tried darcs clone? http://common-lisp.net/~loliveira/ediware/hunchentoot
> But how do I know that I have The /dev/ version?

svn checkout svn://bknr.net/svn/ediware/ should get you the development version.

-Hans