From tschaef at sbcglobal.net  Fri Aug  3 04:45:01 2007
From: tschaef at sbcglobal.net (timothy)
Date: Fri, 03 Aug 2007 00:45:01 -0400
Subject: [hunchentoot-devel] preventing session-max-time updates
Message-ID: <1186116301.32759.11.camel@localhost.localdomain>

Hello,

I am using AJAX requests periodically on each page of my site to update
a part of the display.  These requests, however, prevent the session
from becoming stale.  Aside from fiddling with the last-click member of
the session objects directly, what is the best way of keeping the
periodic AJAX requests while letting unattended sessions become
too-old-p?

Thanks,

Tim S



From ch-tbnl at bobobeach.com  Mon Aug  6 00:07:38 2007
From: ch-tbnl at bobobeach.com (Cyrus Harmon)
Date: Sun, 5 Aug 2007 17:07:38 -0700
Subject: [hunchentoot-devel] Virtual hosts support using *META-DISPATCHER*
In-Reply-To: <6e7f31bf0707291437o49316491y9ce069c51badb808@mail.gmail.com>
References: <87tzrnu9mu.fsf@kriyative.dyndns.org> <u7iojcg99.fsf@agharta.de>
	<6e7f31bf0707291437o49316491y9ce069c51badb808@mail.gmail.com>
Message-ID: <25C003EE-3EAA-48F3-A392-2C41A576EA0D@bobobeach.com>

Perhaps I'm missing something, but why would using *meta-dispatcher*  
be preferred to, say, just setting the server-dispatch-table? I've  
been using virtual hosts without *meta-dispatcher* and I'd like to  
minimize the global changes that would change the behavior of, say,  
other servers that one might bring up in the same instance.

Thanks,

Cyrus

On Jul 29, 2007, at 2:37 PM, Ram Krishnan wrote:

> Perfect. Thanks for the follow up.
>
> Also, thanks Edi for Hunchentoot and all the other excellent Lisp  
> packages you've contributed.
>
> Regards,
>
> -ram
>
> On 7/29/07, Edi Weitz <edi at agharta.de> wrote:
> On Sat, 28 Jul 2007 21:16:57 -0700, "Ram Krishnan" <  
> rkris at kriyative.net> wrote:
>
> > Are there any problems in subverting the *META-DISPATCHER* binding
> > this way? Is there a better alternative?
>
> Looks OK to me.  That (virtual host support) was actually one of the
> reasons why *META-DISPATCHER* is there.
>
> Cheers,
> Edi.
> _______________________________________________
> 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/20070805/02fc0070/attachment.html>

From harsha.ch at gmail.com  Thu Aug  9 02:38:19 2007
From: harsha.ch at gmail.com (Harsha Ch)
Date: Wed, 8 Aug 2007 19:38:19 -0700
Subject: [hunchentoot-devel] unable to install hunchentoot on macosx
	(openmcl)
Message-ID: <6a33e6b10708081938w6dc9ab3bqca6c1f919ad3415b@mail.gmail.com>

hello all, i am trying to install hunchentoot on  macosx 10.4.10(powerpc)
using openmcl ,asdf-install , i am getting these errors, can anybody help me
. thanks

;;; ASDF-INSTALL: Downloading 125037 bytes from
http://weitz.de/files/hunchentoot.tar.gz to HUNCHENTOOT.asdf-install-tmp ...

;;; ASDF-INSTALL: Installing HUNCHENTOOT.asdf-install-tmp in
/usr/local/asdf-install/site/, /usr/local/asdf-install/site-systems/
hunchentoot-0.11.1/
hunchentoot-0.11.1/CHANGELOG
hunchentoot-0.11.1/CHANGELOG_TBNL
hunchentoot-0.11.1/cookie.lisp
hunchentoot-0.11.1/doc/
hunchentoot-0.11.1/doc/hunchentoot.gif
hunchentoot-0.11.1/doc/index.html
hunchentoot-0.11.1/doc/LICENSE.txt
hunchentoot-0.11.1/easy-handlers.lisp
hunchentoot-0.11.1/headers.lisp
hunchentoot-0.11.1/hunchentoot-test.asd
hunchentoot-0.11.1/hunchentoot.asd
hunchentoot-0.11.1/log.lisp
hunchentoot-0.11.1/mime-types.lisp
hunchentoot-0.11.1/misc.lisp
hunchentoot-0.11.1/packages.lisp
hunchentoot-0.11.1/port-acl.lisp
hunchentoot-0.11.1/port-cmu.lisp
hunchentoot-0.11.1/port-lw.lisp
hunchentoot-0.11.1/port-mcl.lisp
hunchentoot-0.11.1/port-sbcl.lisp
hunchentoot-0.11.1/README
hunchentoot-0.11.1/reply.lisp
hunchentoot-0.11.1/request.lisp
hunchentoot-0.11.1/server.lisp
hunchentoot-0.11.1/session.lisp
hunchentoot-0.11.1/specials.lisp
hunchentoot-0.11.1/test/
hunchentoot-0.11.1/test/favicon.ico
hunchentoot-0.11.1/test/fz.jpg
hunchentoot-0.11.1/test/packages.lisp
hunchentoot-0.11.1/test/test.lisp
hunchentoot-0.11.1/test/UTF-8-demo.html
hunchentoot-0.11.1/unix-acl.lisp
hunchentoot-0.11.1/unix-cmu.lisp
hunchentoot-0.11.1/unix-lw.lisp
hunchentoot-0.11.1/unix-mcl.lisp
hunchentoot-0.11.1/unix-sbcl.lisp
hunchentoot-0.11.1/util.lisp

#P"/usr/local/asdf-install/site/hunchentoot-0.11.1/"
#P"/usr/local/asdf-install/site/hunchentoot-0.11.1/"
; loading system definition from
/usr/local/asdf-install/site-systems/hunchentoot.asd into #<Package
"ASDF269">
; registering #<SYSTEM :HUNCHENTOOT #x8454E16> as HUNCHENTOOT
; loading system definition from /usr/local/asdf-install/site-systems/url-
rewrite.asd into #<Package "ASDF270">
; registering #<SYSTEM :URL-REWRITE #x849908E> as URL-REWRITE
; loading system definition from /usr/local/asdf-install/site-systems/acl-
compat.asd into #<Package "ASDF271">
; registering #<SYSTEM ACL-COMPAT #x84B468E> as ACL-COMPAT
; loading system definition from /usr/local/asdf-install/site-systems/cl-
ppcre.asd into #<Package "ASDF285">
; registering #<SYSTEM :CL-PPCRE #x84C7FEE> as CL-PPCRE
; loading system definition from
/usr/local/asdf-install/site-systems/puri.asd into #<Package "ASDF286">
; registering #<SYSTEM PURI #x8409666> as PURI
; registering #<SYSTEM PURI-TESTS #x8401656> as PURI-TESTS
; loading system definition from
/usr/local/asdf-install/site-systems/rfc2388.asd into #<Package "ASDF290">
; registering #<SYSTEM :RFC2388 #x842EEAE> as RFC2388
; loading system definition from
/usr/local/asdf-install/site-systems/md5.asd into #<Package "ASDF291">
; registering #<SYSTEM MD5 #x842627E> as MD5
; loading system definition from
/usr/local/asdf-install/site-systems/cl+ssl.asd into #<Package "ASDF292">
; registering #<SYSTEM :CL+SSL #x843F34E> as CL+SSL
; loading system definition from /usr/local/asdf-install/site-systems/flexi-
streams.asd into #<Package "ASDF293">
; registering #<SYSTEM :FLEXI-STREAMS #x843623E> as FLEXI-STREAMS
; registering #<SYSTEM :FLEXI-STREAMS-TEST #x844D97E> as FLEXI-STREAMS-TEST
; loading system definition from
/usr/local/asdf-install/site-systems/trivial-gray-streams.asd into #<Package
"ASDF295">
; registering #<SYSTEM :TRIVIAL-GRAY-STREAMS #x8441DF6> as
TRIVIAL-GRAY-STREAMS
; loading system definition from
/usr/local/asdf-install/site-systems/cffi.asd into #<Package "ASDF296">
; registering #<SYSTEM CFFI #x8455376> as CFFI
; loading system definition from /usr/local/asdf-install/site-systems/cl-
base64.asd into #<Package "ASDF298">
; registering #<SYSTEM CL-BASE64 #x84756BE> as CL-BASE64
; registering #<SYSTEM CL-BASE64-TESTS #x848CA3E> as CL-BASE64-TESTS
; loading system definition from
/usr/local/asdf-install/site-systems/chunga.asd into #<Package "ASDF301">
; registering #<SYSTEM :CHUNGA #x8481356> as CHUNGA
> Error in process listener(1): Class named CCL::BASIC-STREAM not found.
> While executing: FIND-CLASS
> Type :POP to abort.
Type :? for other options.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20070808/e0dce237/attachment.html>

From edi at agharta.de  Fri Aug 10 21:36:26 2007
From: edi at agharta.de (Edi Weitz)
Date: Fri, 10 Aug 2007 23:36:26 +0200
Subject: [hunchentoot-devel] unable to install hunchentoot on macosx
	(openmcl)
In-Reply-To: <6a33e6b10708081938w6dc9ab3bqca6c1f919ad3415b@mail.gmail.com>
	(Harsha Ch's message of "Wed, 8 Aug 2007 19:38:19 -0700")
References: <6a33e6b10708081938w6dc9ab3bqca6c1f919ad3415b@mail.gmail.com>
Message-ID: <utzr7kr6t.fsf@agharta.de>

On Wed, 8 Aug 2007 19:38:19 -0700, "Harsha Ch" <harsha.ch at gmail.com> wrote:

> hello all, i am trying to install hunchentoot on macosx
> 10.4.10(powerpc) using openmcl

I can't really help with this one as I don't have a Mac, but note that
for a real bug report you should provide a bit more information -
which version of OpenMCL do you use, which version are the other
libraries, what about a backtrace, etc.  Maybe someone with a Mac can
look into this.  And you could check if you get the same error with
version 0.11.0 of Hunchentoot:

  http://common-lisp.net/~loliveira/ediware/

Edi.


From ctdean at sokitomi.com  Fri Aug 10 22:22:58 2007
From: ctdean at sokitomi.com (Chris Dean)
Date: Fri, 10 Aug 2007 15:22:58 -0700
Subject: [hunchentoot-devel] unable to install hunchentoot on macosx
	(openmcl)
In-Reply-To: <utzr7kr6t.fsf@agharta.de> (Edi Weitz's message of "Fri,
	10 Aug 2007 23:36:26 +0200")
References: <6a33e6b10708081938w6dc9ab3bqca6c1f919ad3415b@mail.gmail.com>
	<utzr7kr6t.fsf@agharta.de>
Message-ID: <m2lkcj2fnh.fsf@jacaranda.kyluka.com>


Edi Weitz <edi at agharta.de> writes:
> On Wed, 8 Aug 2007 19:38:19 -0700, "Harsha Ch" <harsha.ch at gmail.com> wrote:
>
>> hello all, i am trying to install hunchentoot on macosx
>> 10.4.10(powerpc) using openmcl
>
> I can't really help with this one as I don't have a Mac, but note
> that for a real bug report you should provide a bit more information
> - which version of OpenMCL do you use, which version are the other
> libraries, what about a backtrace, etc.  Maybe someone with a Mac
> can

I have a Mac, and if Harsha can provide me with this information I'll try
and replicate the problem.

(I have never used OpenMCL.)

Cheers,
Chris Dean


From harsha.ch at gmail.com  Sat Aug 11 00:00:35 2007
From: harsha.ch at gmail.com (Harsha)
Date: Fri, 10 Aug 2007 17:00:35 -0700
Subject: [hunchentoot-devel] unable to install hunchentoot on macosx
	(openmcl)
In-Reply-To: <m2lkcj2fnh.fsf@jacaranda.kyluka.com>
References: <6a33e6b10708081938w6dc9ab3bqca6c1f919ad3415b@mail.gmail.com>
	<utzr7kr6t.fsf@agharta.de> <m2lkcj2fnh.fsf@jacaranda.kyluka.com>
Message-ID: <6751B97F-BC96-4B7B-BEB4-1888523F7C3F@beingharsha.net>


     mac version : 10.4.10
                              PowerPc G4
     openmcl : version 1.0
     libraries :
        cl-md5 -  version - 1.8
        chunga - version - 0.3.0
        cl-fad - version - 0.6.0
        cl-ppcre - version - 1.3.0
        cl-who - version - 0.10.0
        flexistreams - version - 0.11.2
       url-rewrite - version - 0.1.1
       cl-base64 - version-3.1
       rfc2388
       cl+ssl
       acl-compat

    i am trying to reinstall from scratch ,, to see if there is any  
lib problems.. thanks for the help
On Aug 10, 2007, at 3:22 PM, Chris Dean wrote:

>
> Edi Weitz <edi at agharta.de> writes:
>> On Wed, 8 Aug 2007 19:38:19 -0700, "Harsha Ch"  
>> <harsha.ch at gmail.com> wrote:
>>
>>> hello all, i am trying to install hunchentoot on macosx
>>> 10.4.10(powerpc) using openmcl
>>
>> I can't really help with this one as I don't have a Mac, but note
>> that for a real bug report you should provide a bit more information
>> - which version of OpenMCL do you use, which version are the other
>> libraries, what about a backtrace, etc.  Maybe someone with a Mac
>> can
>
> I have a Mac, and if Harsha can provide me with this information  
> I'll try
> and replicate the problem.
>
> (I have never used OpenMCL.)
>
> Cheers,
> Chris Dean
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel



From harsha.ch at gmail.com  Sat Aug 11 02:35:31 2007
From: harsha.ch at gmail.com (Harsha)
Date: Fri, 10 Aug 2007 19:35:31 -0700
Subject: [hunchentoot-devel] unable to install hunchentoot on macosx
	(openmcl)
In-Reply-To: <m2lkcj2fnh.fsf@jacaranda.kyluka.com>
References: <6a33e6b10708081938w6dc9ab3bqca6c1f919ad3415b@mail.gmail.com>
	<utzr7kr6t.fsf@agharta.de> <m2lkcj2fnh.fsf@jacaranda.kyluka.com>
Message-ID: <F6772EF6-580D-4270-9CFD-3DD8DCC9DAC7@beingharsha.net>

hi,
  i got it working , when i reinstalled everything .. i think there  
is some problem with flexi streams ( not sure though).. thanks for  
the help ..
-harsha
On Aug 10, 2007, at 3:22 PM, Chris Dean wrote:

>
> Edi Weitz <edi at agharta.de> writes:
>> On Wed, 8 Aug 2007 19:38:19 -0700, "Harsha Ch"  
>> <harsha.ch at gmail.com> wrote:
>>
>>> hello all, i am trying to install hunchentoot on macosx
>>> 10.4.10(powerpc) using openmcl
>>
>> I can't really help with this one as I don't have a Mac, but note
>> that for a real bug report you should provide a bit more information
>> - which version of OpenMCL do you use, which version are the other
>> libraries, what about a backtrace, etc.  Maybe someone with a Mac
>> can
>
> I have a Mac, and if Harsha can provide me with this information  
> I'll try
> and replicate the problem.
>
> (I have never used OpenMCL.)
>
> Cheers,
> Chris Dean
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel



From john.thingstad at chello.no  Sat Aug 18 07:17:07 2007
From: john.thingstad at chello.no (John Thingstad)
Date: Sat, 18 Aug 2007 09:17:07 +0200
Subject: [hunchentoot-devel] Strange race condition?
Message-ID: <op.tw8uitunpqzri1@pandora.upc.no>


I have just written a blog program.
Functionally it is complete, but it contains a big and serious flaw.
At intermittent intervals it gives a error like:

[2007-08-18 09:05:58 [ERROR]] While accessing database  
#<CLSQL-MYSQL:MYSQL-DATAB
ASE localhost/blog/jthing OPEN 219A8C6F>
   with expression "SELECT * FROM BLOG_ITEMS WHERE (ID = 224)":
   Error 2006 / MySQL server has gone away
   has occurred.

It seems like a clsql error.. So why am I reporting it to here?

Well the first thing to do is to isolate what is causing the error.
After eliminating that the error was in my code (which included a rewrite)  
I found it down to the following lines:

     (with-html-output-to-string
         (*standard-output* nil :prologue t :indent t)
       (:html :xmlns "http://www.w3.org/1999/xhtml"
        (:head
         (:title (fmt "~A - ~A"
                      (escape-string (getf blog :title))
                      (escape-string (getf item :title))))
         (:link :href *blog-css-file*
          :rel "stylesheet" :type "text/css")
         (:link :href *tree-css-file*
          :rel "stylesheet" :type "text/css"
          :media "screen, projection")
         (:script :type "text/javascript" :src *tree-js-file* "")
         (:script :type "text/javascript"
          (fmt "~%addLoadListener( function() { treeMenu('~A', '~A'); });"
               "navigation"
               (format nil "~A?id=~D"
                       (script-name)
                       item-id))))

So it should be reported to cl-who right. Wrong!
The problem isn't in the code that is generated.
It appers to be the fact that I am including 2 css files and a javascript  
file.
It is the UPLOAD of these from the client and the inerruption of the  
thread that causes the problem.
Has anyone here experienced anything simular?


From john.thingstad at chello.no  Sat Aug 18 07:20:36 2007
From: john.thingstad at chello.no (John Thingstad)
Date: Sat, 18 Aug 2007 09:20:36 +0200
Subject: [hunchentoot-devel] Strange race condition?
In-Reply-To: <op.tw8uitunpqzri1@pandora.upc.no>
References: <op.tw8uitunpqzri1@pandora.upc.no>
Message-ID: <op.tw8uomdcpqzri1@pandora.upc.no>

P? Sat, 18 Aug 2007 09:17:07 +0200, skrev John Thingstad  
<john.thingstad at chello.no>:

>
> I have just written a blog program.
> Functionally it is complete, but it contains a big and serious flaw.
> At intermittent intervals it gives a error like:

I forgot to mention I am running it in LispWorks under Windows.


From edi at agharta.de  Mon Aug 20 16:59:26 2007
From: edi at agharta.de (Edi Weitz)
Date: Mon, 20 Aug 2007 18:59:26 +0200
Subject: [hunchentoot-devel] Strange race condition?
In-Reply-To: <op.tw8uitunpqzri1@pandora.upc.no> (John Thingstad's message of
	"Sat, 18 Aug 2007 09:17:07 +0200")
References: <op.tw8uitunpqzri1@pandora.upc.no>
Message-ID: <u4piu3zwx.fsf@agharta.de>

On Sat, 18 Aug 2007 09:17:07 +0200, John Thingstad <john.thingstad at chello.no> wrote:

> I have just written a blog program.  Functionally it is complete,
> but it contains a big and serious flaw.  At intermittent intervals
> it gives a error like:
>
> [2007-08-18 09:05:58 [ERROR]] While accessing database
> #<CLSQL-MYSQL:MYSQL-DATAB
> ASE localhost/blog/jthing OPEN 219A8C6F>
>    with expression "SELECT * FROM BLOG_ITEMS WHERE (ID = 224)":
>    Error 2006 / MySQL server has gone away
>    has occurred.
>
> It seems like a clsql error.. So why am I reporting it to here?
>
> Well the first thing to do is to isolate what is causing the error.
> After eliminating that the error was in my code (which included a
> rewrite) I found it down to the following lines:
>
>      (with-html-output-to-string
>          (*standard-output* nil :prologue t :indent t)
>        (:html :xmlns "http://www.w3.org/1999/xhtml"
>         (:head
>          (:title (fmt "~A - ~A"
>                       (escape-string (getf blog :title))
>                       (escape-string (getf item :title))))
>          (:link :href *blog-css-file*
>           :rel "stylesheet" :type "text/css")
>          (:link :href *tree-css-file*
>           :rel "stylesheet" :type "text/css"
>           :media "screen, projection")
>          (:script :type "text/javascript" :src *tree-js-file* "")
>          (:script :type "text/javascript"
>           (fmt "~%addLoadListener( function() { treeMenu('~A', '~A'); });"
>                "navigation"
>                (format nil "~A?id=~D"
>                        (script-name)
>                        item-id))))
>
> So it should be reported to cl-who right. Wrong!  The problem isn't
> in the code that is generated.  It appers to be the fact that I am
> including 2 css files and a javascript file.  It is the UPLOAD of
> these from the client and the inerruption of the thread that causes
> the problem.  Has anyone here experienced anything simular?

FWIW, I don't understand from your description what exactly happens
and where you think the problems comes from.  I don't even see how the
code snippet above is related to MySQL and what the client /uploads/
to the server.

I have only one wild guess (as you're talking about thread
interruption): If you've wrapped all of your handlers with a function
or macro that connects to the database and if they all try to connect
using the /same/ connection, then this is probably the cause.  Maybe
connection pooling will help.


From edi at agharta.de  Mon Aug 20 17:02:07 2007
From: edi at agharta.de (Edi Weitz)
Date: Mon, 20 Aug 2007 19:02:07 +0200
Subject: [hunchentoot-devel] Virtual hosts support using *META-DISPATCHER*
In-Reply-To: <25C003EE-3EAA-48F3-A392-2C41A576EA0D@bobobeach.com> (Cyrus
	Harmon's message of "Sun, 5 Aug 2007 17:07:38 -0700")
References: <87tzrnu9mu.fsf@kriyative.dyndns.org> <u7iojcg99.fsf@agharta.de>
	<6e7f31bf0707291437o49316491y9ce069c51badb808@mail.gmail.com>
	<25C003EE-3EAA-48F3-A392-2C41A576EA0D@bobobeach.com>
Message-ID: <uzm0m2l80.fsf@agharta.de>

On Sun, 5 Aug 2007 17:07:38 -0700, Cyrus Harmon <ch-tbnl at bobobeach.com> wrote:

> Perhaps I'm missing something, but why would using *meta-dispatcher*
> be preferred to, say, just setting the server-dispatch-table? I've
> been using virtual hosts without *meta-dispatcher* and I'd like to
> minimize the global changes that would change the behavior of, say,
> other servers that one might bring up in the same instance.

I'd say that your approach is fine as well.  I'd prefer using separate
dispatch tables for stylistic reasons, but as usual TMTOWTDI.


From edi at agharta.de  Mon Aug 20 17:05:31 2007
From: edi at agharta.de (Edi Weitz)
Date: Mon, 20 Aug 2007 19:05:31 +0200
Subject: [hunchentoot-devel] preventing session-max-time updates
In-Reply-To: <1186116301.32759.11.camel@localhost.localdomain> (timothy's
	message of "Fri, 03 Aug 2007 00:45:01 -0400")
References: <1186116301.32759.11.camel@localhost.localdomain>
Message-ID: <uveba2l2c.fsf@agharta.de>

On Fri, 03 Aug 2007 00:45:01 -0400, timothy <tschaef at sbcglobal.net> wrote:

> I am using AJAX requests periodically on each page of my site to
> update a part of the display.  These requests, however, prevent the
> session from becoming stale.  Aside from fiddling with the
> last-click member of the session objects directly, what is the best
> way of keeping the periodic AJAX requests while letting unattended
> sessions become too-old-p?

There currently is no exported facility to overcome this kind of
problem.


From jdcal at yahoo.com  Mon Aug 20 19:47:06 2007
From: jdcal at yahoo.com (Jeff Caldwell)
Date: Mon, 20 Aug 2007 12:47:06 -0700 (PDT)
Subject: [hunchentoot-devel] write-sequence to *hunchentoot-stream* on x86_64
In-Reply-To: <uveba2l2c.fsf@agharta.de>
Message-ID: <317126.32140.qm@web50601.mail.re2.yahoo.com>

Hello,

Can anyone give me a way to debug the following problem, or tell me likely
places to investigate?

With Hunchentoot 0.11.1 I have a problem on this machine:

Linux machine-1-name 2.6.18-8.1.8.el5 #1 SMP Mon Jun 25 15:19:07 EDT 2007
x86_64 x86_64 x86_64 GNU/Linux

but I don't have that problem on this machine:

Linux machine-2-name 2.6.16.27-0.9-smp #1 SMP Tue Feb 13 09:35:18 UTC 2007
i686 i686 i386 GNU/Linux

I am running LWL Pro 4.3.7.

On the x86_64 machine, every page, even the Hunchentoot default page, has
some seemingly-random binary data that comes after the headers but before the
content. This appears in the browser as strange characters at the top of the
page, often (but not always) followed by part or all of the desired web page.
The random binary data is not in the content variable that is written to the
stream. The headers are OK, the content is OK, it is only that there is extra
binary data between the headers and the content.

I found a workaround. In headers.lisp, in function start-output, in the
following code, write-sequence is the original code in hunchentoot while
write-string is the workaround needed to get good output and avoid the
extraneous binary data between the headers and the content.

...
    (setf (flexi-stream-external-format *hunchentoot-stream*) 
          (reply-external-format))
    ;; now optional content
    (unless (or (null content) head-request-p)
      (ignore-errors
	#+x86_64RHEL5-workaround
        (write-string (coerce (loop for c across content 
                                    collect (code-char c)) 'string)          
        
                      *hunchentoot-stream*)
        #-x86_64RHEL5-workaround
        (write-sequence content *hunchentoot-stream*)))
    (when chunkedp
      ;; turn chunking on after the headers have been sent
      (setf (chunked-stream-output-chunking-p
             (flexi-stream-stream *hunchentoot-stream*)) t))
    *hunchentoot-stream*))

Again, can anyone give me tips on where to look or how to debug the problem?

Thanks,

Jeff Caldwell





      ____________________________________________________________________________________
Luggage? GPS? Comic books? 
Check out fitting gifts for grads at Yahoo! Search
http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz


From edi at agharta.de  Tue Aug 21 09:54:26 2007
From: edi at agharta.de (Edi Weitz)
Date: Tue, 21 Aug 2007 11:54:26 +0200
Subject: [hunchentoot-devel] write-sequence to *hunchentoot-stream* on
	x86_64
In-Reply-To: <317126.32140.qm@web50601.mail.re2.yahoo.com> (Jeff Caldwell's
	message of "Mon, 20 Aug 2007 12:47:06 -0700 (PDT)")
References: <317126.32140.qm@web50601.mail.re2.yahoo.com>
Message-ID: <ur6lxxlf1.fsf@agharta.de>

On Mon, 20 Aug 2007 12:47:06 -0700 (PDT), Jeff Caldwell <jdcal at yahoo.com> wrote:

> Can anyone give me a way to debug the following problem, or tell me
> likely places to investigate?
>
> With Hunchentoot 0.11.1 I have a problem on this machine:
>
> Linux machine-1-name 2.6.18-8.1.8.el5 #1 SMP Mon Jun 25 15:19:07 EDT 2007
> x86_64 x86_64 x86_64 GNU/Linux
>
> but I don't have that problem on this machine:
>
> Linux machine-2-name 2.6.16.27-0.9-smp #1 SMP Tue Feb 13 09:35:18 UTC 2007
> i686 i686 i386 GNU/Linux
>
> I am running LWL Pro 4.3.7.
>
> On the x86_64 machine, every page, even the Hunchentoot default
> page, has some seemingly-random binary data that comes after the
> headers but before the content. This appears in the browser as
> strange characters at the top of the page, often (but not always)
> followed by part or all of the desired web page.  The random binary
> data is not in the content variable that is written to the
> stream. The headers are OK, the content is OK, it is only that there
> is extra binary data between the headers and the content.
>
> I found a workaround. In headers.lisp, in function start-output, in
> the following code, write-sequence is the original code in
> hunchentoot while write-string is the workaround needed to get good
> output and avoid the extraneous binary data between the headers and
> the content.
>
> ...
>     (setf (flexi-stream-external-format *hunchentoot-stream*) 
>           (reply-external-format))
>     ;; now optional content
>     (unless (or (null content) head-request-p)
>       (ignore-errors
> 	#+x86_64RHEL5-workaround
>         (write-string (coerce (loop for c across content 
>                                     collect (code-char c)) 'string)          
>         
>                       *hunchentoot-stream*)
>         #-x86_64RHEL5-workaround
>         (write-sequence content *hunchentoot-stream*)))
>     (when chunkedp
>       ;; turn chunking on after the headers have been sent
>       (setf (chunked-stream-output-chunking-p
>              (flexi-stream-stream *hunchentoot-stream*)) t))
>     *hunchentoot-stream*))
>
> Again, can anyone give me tips on where to look or how to debug the
> problem?

Looks like a possible bug in flexi-streams (/or/ in LWL 4) to me and
should probably be discussed on the corresponding mailing list - see
Cc.  Could you check if the test suite of flexi-streams runs through
on your x86_64 machine?  Are you using the newest version of
flexi-streams?  Could you check if you get the same problems with LWL
5.0.x, maybe using the Personal Edition?  Unfortunately, I don't have
a 64-bit machine yet to check this myself.

Thanks,
Edi.


From austin at pettomato.com  Tue Aug 21 17:37:56 2007
From: austin at pettomato.com (Austin Haas)
Date: Tue, 21 Aug 2007 13:37:56 -0400
Subject: [hunchentoot-devel] site structure
Message-ID: <20070821173756.GA22189@bean.chicago>


How does one generally structure their source files for a multi-sectioned site?

I have a site that has several disparate sections, including:

1. main page, company information, etc.
2. portfolio of past works
3. client projects
4. various other interactive demos

When I initially setup the project, I put the source files for each section into it's own directory, and included it as a module in my main defsystem. The main dispatch table would branch from there using "create-prefix-dispatcher" and call a "dispatcher" method belonging to the appropriate module.

Each client project gets it's own source file and dispatcher, because they usually contain many unique sections themselves, such as pages for alpha demos, betas, etc. Some also need various dynamic features, too, so it's not as if I can just create some template system and pull unique data from a DB. I really need to be able to through up entirely new branches to the site on a weekly basis.

The main issue that I've faced so far is that I have to add any new files to the :components section of the main defsystem method, which is inconvenient.

It is very likely that I'm just not understanding the basics of setting up a lisp project, but I don't think most projects require the same structure as a large website. Please correct me if I'm mistaken.

I'd appreciate any suggestions, pointers, or advice that anyone might have.

Thanks.

-austin

-- 
Austin Haas
Pet Tomato, Inc.
http://pettomato.com



From xach at xach.com  Tue Aug 21 17:45:25 2007
From: xach at xach.com (Zach Beane)
Date: Tue, 21 Aug 2007 13:45:25 -0400
Subject: [hunchentoot-devel] site structure
In-Reply-To: <20070821173756.GA22189@bean.chicago>
References: <20070821173756.GA22189@bean.chicago>
Message-ID: <20070821174525.GS5338@xach.com>

On Tue, Aug 21, 2007 at 01:37:56PM -0400, Austin Haas wrote:
> 
> How does one generally structure their source files for a multi-sectioned site?
> 
> I have a site that has several disparate sections, including:
> 
> 1. main page, company information, etc.
> 2. portfolio of past works
> 3. client projects
> 4. various other interactive demos
> 
> When I initially setup the project, I put the source files for each section into it's own directory, and included it as a module in my main defsystem. The main dispatch table would branch from there using "create-prefix-dispatcher" and call a "dispatcher" method belonging to the appropriate module.
> 
> Each client project gets it's own source file and dispatcher, because they usually contain many unique sections themselves, such as pages for alpha demos, betas, etc. Some also need various dynamic features, too, so it's not as if I can just create some template system and pull unique data from a DB. I really need to be able to through up entirely new branches to the site on a weekly basis.
> 
> The main issue that I've faced so far is that I have to add any new files to the :components section of the main defsystem method, which is inconvenient.
> 
> It is very likely that I'm just not understanding the basics of setting up a lisp project, but I don't think most projects require the same structure as a large website. Please correct me if I'm mistaken.
> 
> I'd appreciate any suggestions, pointers, or advice that anyone might have.

For wigflip.com, I make new projects completely separate directories
with their own version control, source files, static files, and
foo.asd system. I have a dummy system called "load-wigflip" that
:depends-on each of the projects that needs to be loaded.

Each of the projects depends on a "wigflip" system that adds
convenience functions for carving out a portion of the URL
space. There are also convenience functions to register the project in
a way that makes a link to the project url space appear on the front
page.

There are probably a zillion ways to structure a site. This has worked
out for me so far. I can independently start up new subsections of the
site without worrying too much about synchronizing them with the
"main" site.

Zach


From austin at pettomato.com  Tue Aug 21 18:34:52 2007
From: austin at pettomato.com (Austin Haas)
Date: Tue, 21 Aug 2007 14:34:52 -0400
Subject: [hunchentoot-devel] site structure
In-Reply-To: <20070821174525.GS5338@xach.com>
References: <20070821173756.GA22189@bean.chicago>
	<20070821174525.GS5338@xach.com>
Message-ID: <20070821183452.GA22471@bean.chicago>


Thanks for the reply. That sounds great. I understand the concepts, but the implementation details are escaping me.

I'll have to mull it over for a while, but for starters, are you using a single Hunchentoot server, or one for each project/section?

-austin

-- 
Austin Haas
Pet Tomato, Inc.
http://pettomato.com

On Tue Aug 21 13:45 , Zach Beane wrote:
> On Tue, Aug 21, 2007 at 01:37:56PM -0400, Austin Haas wrote:
> > 
> > How does one generally structure their source files for a multi-sectioned site?
> > 
> > I have a site that has several disparate sections, including:
> > 
> > 1. main page, company information, etc.
> > 2. portfolio of past works
> > 3. client projects
> > 4. various other interactive demos
> > 
> > When I initially setup the project, I put the source files for each section into it's own directory, and included it as a module in my main defsystem. The main dispatch table would branch from there using "create-prefix-dispatcher" and call a "dispatcher" method belonging to the appropriate module.
> > 
> > Each client project gets it's own source file and dispatcher, because they usually contain many unique sections themselves, such as pages for alpha demos, betas, etc. Some also need various dynamic features, too, so it's not as if I can just create some template system and pull unique data from a DB. I really need to be able to through up entirely new branches to the site on a weekly basis.
> > 
> > The main issue that I've faced so far is that I have to add any new files to the :components section of the main defsystem method, which is inconvenient.
> > 
> > It is very likely that I'm just not understanding the basics of setting up a lisp project, but I don't think most projects require the same structure as a large website. Please correct me if I'm mistaken.
> > 
> > I'd appreciate any suggestions, pointers, or advice that anyone might have.
> 
> For wigflip.com, I make new projects completely separate directories
> with their own version control, source files, static files, and
> foo.asd system. I have a dummy system called "load-wigflip" that
> :depends-on each of the projects that needs to be loaded.
> 
> Each of the projects depends on a "wigflip" system that adds
> convenience functions for carving out a portion of the URL
> space. There are also convenience functions to register the project in
> a way that makes a link to the project url space appear on the front
> page.
> 
> There are probably a zillion ways to structure a site. This has worked
> out for me so far. I can independently start up new subsections of the
> site without worrying too much about synchronizing them with the
> "main" site.
> 
> Zach
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
> 


From xach at xach.com  Tue Aug 21 18:36:41 2007
From: xach at xach.com (Zach Beane)
Date: Tue, 21 Aug 2007 14:36:41 -0400
Subject: [hunchentoot-devel] site structure
In-Reply-To: <20070821183452.GA22471@bean.chicago>
References: <20070821173756.GA22189@bean.chicago>
	<20070821174525.GS5338@xach.com>
	<20070821183452.GA22471@bean.chicago>
Message-ID: <20070821183641.GT5338@xach.com>

On Tue, Aug 21, 2007 at 02:34:52PM -0400, Austin Haas wrote:
> 
> Thanks for the reply. That sounds great. I understand the concepts, but the implementation details are escaping me.
> 
> I'll have to mull it over for a while, but for starters, are you using a single Hunchentoot server, or one for each project/section?

Just one server. I'm not actually using hunchentoot, but its
predecessor TBNL, but the concepts should be similar in this case.

Zach


From rkris at kriyative.net  Tue Aug 21 19:05:01 2007
From: rkris at kriyative.net (Ram Krishnan)
Date: Tue, 21 Aug 2007 12:05:01 -0700
Subject: [hunchentoot-devel] site structure
In-Reply-To: <20070821173756.GA22189@bean.chicago>
References: <20070821173756.GA22189@bean.chicago>
Message-ID: <6e7f31bf0708211205q258f1f80pe1e70a820bc99de6@mail.gmail.com>

Austin,

We used a similar approach for managing multiple client interfaces, by
creating client-specific directories with one or more Lisp files with
handler code. In our case, we dispatched based on the virtual host name,
using the *META-DISPATCHER* special var.

Where we differed from the approach you wrote about is that we didn't use
ASDF (or DEFSYSTEM) in loading the client specific sections. We used a
simple mapping from the top-level URL prefix to Lisp file, which we just
(load)ed.

For example, if the incoming request was for a "http://foo.com/users/list",
then our *META-DISPATCHER* (which overrides the default) would look up a
dispatch-table for "foo.com", and the default handler in that dispatch-table
would look for a clients/foo.com/users.[ufasl | lisp] in the file-system,
and load that into the running Lisp image. On loading users.ufasl, one or
more explicit handlers for the /users prefix would be inserted into the
dispatch table for subsequent request.

Hope this is useful.

-ram

On 8/21/07, Austin Haas <austin at pettomato.com> wrote:
>
>
> How does one generally structure their source files for a multi-sectioned
> site?
>
> I have a site that has several disparate sections, including:
>
> 1. main page, company information, etc.
> 2. portfolio of past works
> 3. client projects
> 4. various other interactive demos
>
> When I initially setup the project, I put the source files for each
> section into it's own directory, and included it as a module in my main
> defsystem. The main dispatch table would branch from there using
> "create-prefix-dispatcher" and call a "dispatcher" method belonging to the
> appropriate module.
>
> Each client project gets it's own source file and dispatcher, because they
> usually contain many unique sections themselves, such as pages for alpha
> demos, betas, etc. Some also need various dynamic features, too, so it's not
> as if I can just create some template system and pull unique data from a DB.
> I really need to be able to through up entirely new branches to the site on
> a weekly basis.
>
> The main issue that I've faced so far is that I have to add any new files
> to the :components section of the main defsystem method, which is
> inconvenient.
>
> It is very likely that I'm just not understanding the basics of setting up
> a lisp project, but I don't think most projects require the same structure
> as a large website. Please correct me if I'm mistaken.
>
> I'd appreciate any suggestions, pointers, or advice that anyone might
> have.
>
> Thanks.
>
> -austin
>
> --
> Austin Haas
> Pet Tomato, Inc.
> http://pettomato.com
>
> _______________________________________________
> 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/20070821/34dede04/attachment.html>

From austin at pettomato.com  Tue Aug 21 20:15:22 2007
From: austin at pettomato.com (Austin Haas)
Date: Tue, 21 Aug 2007 16:15:22 -0400
Subject: [hunchentoot-devel] site structure
In-Reply-To: <6e7f31bf0708211205q258f1f80pe1e70a820bc99de6@mail.gmail.com>
References: <20070821173756.GA22189@bean.chicago>
	<6e7f31bf0708211205q258f1f80pe1e70a820bc99de6@mail.gmail.com>
Message-ID: <20070821201522.GB22471@bean.chicago>


Yes, your solution solves my main gripe and seems pretty easy to adapt my existing code to. Thanks!

Zach's solution is very interesting to me, though. With his method, it sounds like one could possibly run a section standalone, or even from another lisp image, and then (if desired) merge it into the main site once it's stable.

Thanks for the input.

-austin

-- 
Austin Haas
Pet Tomato, Inc.
http://pettomato.com

On Tue Aug 21 12:05 , Ram Krishnan wrote:
> Austin,
> 
> We used a similar approach for managing multiple client interfaces, by
> creating client-specific directories with one or more Lisp files with
> handler code. In our case, we dispatched based on the virtual host name,
> using the *META-DISPATCHER* special var.
> 
> Where we differed from the approach you wrote about is that we didn't use
> ASDF (or DEFSYSTEM) in loading the client specific sections. We used a
> simple mapping from the top-level URL prefix to Lisp file, which we just
> (load)ed.
> 
> For example, if the incoming request was for a "http://foo.com/users/list",
> then our *META-DISPATCHER* (which overrides the default) would look up a
> dispatch-table for "foo.com", and the default handler in that dispatch-table
> would look for a clients/foo.com/users.[ufasl | lisp] in the file-system,
> and load that into the running Lisp image. On loading users.ufasl, one or
> more explicit handlers for the /users prefix would be inserted into the
> dispatch table for subsequent request.
> 
> Hope this is useful.
> 
> -ram
> 
> On 8/21/07, Austin Haas <austin at pettomato.com> wrote:
> >
> >
> > How does one generally structure their source files for a multi-sectioned
> > site?
> >
> > I have a site that has several disparate sections, including:
> >
> > 1. main page, company information, etc.
> > 2. portfolio of past works
> > 3. client projects
> > 4. various other interactive demos
> >
> > When I initially setup the project, I put the source files for each
> > section into it's own directory, and included it as a module in my main
> > defsystem. The main dispatch table would branch from there using
> > "create-prefix-dispatcher" and call a "dispatcher" method belonging to the
> > appropriate module.
> >
> > Each client project gets it's own source file and dispatcher, because they
> > usually contain many unique sections themselves, such as pages for alpha
> > demos, betas, etc. Some also need various dynamic features, too, so it's not
> > as if I can just create some template system and pull unique data from a DB.
> > I really need to be able to through up entirely new branches to the site on
> > a weekly basis.
> >
> > The main issue that I've faced so far is that I have to add any new files
> > to the :components section of the main defsystem method, which is
> > inconvenient.
> >
> > It is very likely that I'm just not understanding the basics of setting up
> > a lisp project, but I don't think most projects require the same structure
> > as a large website. Please correct me if I'm mistaken.
> >
> > I'd appreciate any suggestions, pointers, or advice that anyone might
> > have.
> >
> > Thanks.
> >
> > -austin
> >
> > --
> > Austin Haas
> > Pet Tomato, Inc.
> > http://pettomato.com
> >
> > _______________________________________________
> > 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


From hkBst at gentoo.org  Fri Aug 24 13:33:37 2007
From: hkBst at gentoo.org (Marijn Schouten (hkBst))
Date: Fri, 24 Aug 2007 15:33:37 +0200
Subject: [hunchentoot-devel] Re: versioning release tarballs
In-Reply-To: <uodih47z8.fsf@agharta.de>
References: <20070710164500.GA825713@universe.org> <uodih47z8.fsf@agharta.de>
Message-ID: <46CEDE31.70007@gentoo.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Edi Weitz wrote:
> On Tue, 10 Jul 2007 18:45:00 +0200, Stelian Ionescu <sionescu at common-lisp.net> wrote:
> 
>> hello, would you be kind enough to put system versions in the
>> tarball names of the releases you make or just make some symlinks ?
>> I'm working on adding your latest releases to Gentoo and being able
>> to download already-versioned tarballs would make our task easier
> 
> Hi,
> 
> I understand that this might make your work a little bit easier, but
> it would be more work for me and it'd completely screw up the existing
> workflow for two dozens of libs I maintain.  So, no, I'm not going to
> change this is in the near future.

It seems to me that changing your scripts to:

# remove old symlink
rm hunchentoot.tar.gz
# run original script
<original script you use to produce hunchentoot.tar.gz>
# add version and recreate symlink
cp hunchentoot.tar.gz hunchentoot-VERSION.tar.gz
ln -s hunchentoot-VERSION.tar.gz hunchentoot.tar.gz

1) would be simple,
2) cost you no more time to create tarballs,
3) whould be backwards compatible with all your workflow
4) would solve the problem not just for Gentoo, but for all
people/distributions interested in distributing your packages, instead of
gratuitously requiring each and every one of them to duplicate the work of
versioning.

I don't see how this simple change can ``completely screw up the existing
workflow for two dozens of libs'', but I am hereby offering to do all of the
work to make the required changes, so all you will need to do is point me to
the scripts and judge the changes I will propose.

> But as the download links from the weitz.de index page are generated
> automatically and thus always look the same, it should be fairly easy
> to write a small script that downloads the current tarballs and
> renames them accordingly.

If you would be willing to run this script and host the versioned tarballs,
then I'm willing to write the script.

sincerely,

Marijn

- --
Marijn Schouten (hkBst), Gentoo Lisp project
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGzt4xp/VmCx0OL2wRAtFUAJ0cpyZHNUPLWC4mRh1MqPvOS8NhXQCdGCZD
omOLZaWC+nx4fipTDKfjnCI=
=QH4n
-----END PGP SIGNATURE-----