Error

~%~A~%~%"
                   condition (html-escape (tbnl::get-backtrace))))))

(defmacro defpage (url &body body)
   ...
         (catch 'page-handler-done
           (handler-bind ((error 'devel-mode-handler))
             (html :page , at body)))))))

rg

On Aug 28, 2010, at 4:29 AM, Leslie P. Polzer wrote:

> 
> Ron Garret wrote:
>> Is there any straightforward way to get a backtrace-on-error displayed on the browser
>> screen instead of being logged to a file, like Pythons' cgitb package does?  I tried
>> this:
>> 
>> (defun error-handler (arg) [code-to-generate-backtrace])
>> 
>> (setf *HTTP-ERROR-HANDLER* 'error-handler)
>> 
>> but that doesn't work because by the time error-handler is called the server has already
>> exited the error context.
> 
> Here's what we're using in Weblocks:
> 
>  http://bitbucket.org/S11001001/weblocks-dev/src/tip/src/request-handler.lisp#cl-60
>  http://bitbucket.org/S11001001/weblocks-dev/src/tip/src/error-handler.lisp#cl-35
> 
> HTH,
> 
>   Leslie
> 
> 
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel

From zaytsev.yakov at gmail.com  Sat Aug 28 19:14:52 2010
From: zaytsev.yakov at gmail.com (Yakov Zaytsev)
Date: Sat, 28 Aug 2010 23:14:52 +0400
Subject: [hunchentoot-devel] compiling 1.1.1 specials.lisp takes too long
Message-ID: 

Hello,

with ACL 8.2 (professional license) on windows 7 on Atom Z540 with
2GiBs of memory trying to

(asdf:oos 'asdf:load-op :hunchentoot)

ends with

;;; Compiling file c:\lisplibs\hunchentoot-1.1.1\specials.lisp
; While compiling (:top-level-form "specials.lisp" 1551):
Warning: Compiling a function definition for the name defconstant as a
defmacro.  This name is in the common-lisp
         package and redefining it will be a violation for portable
programs.  Replacing the current definition of
         # may be dangerous.  The
package common-lisp has
         excl:package-definition-lock set, which causes the system to
signal this violation.

and it seems like it freezes there. Is it normal? How long does it
take typically to compile that specials.lisp?

TIA!

From edi at agharta.de  Sat Aug 28 20:39:02 2010
From: edi at agharta.de (Edi Weitz)
Date: Sat, 28 Aug 2010 22:39:02 +0200
Subject: [hunchentoot-devel] compiling 1.1.1 specials.lisp takes too long
In-Reply-To: 
References: 
Message-ID: 

I think AllegroCL is confused here.  The name DEFCONSTANT is shadowed
in the Hunchentoot package, so there's no need for a warning and
certainly the compiler shouldn't freeze. Compiling specials.lisp
should usually take only fractions of a second.

I'd report the problem to Franz.

Edi.

On Sat, Aug 28, 2010 at 9:14 PM, Yakov Zaytsev  wrote:
> Hello,
>
> with ACL 8.2 (professional license) on windows 7 on Atom Z540 with
> 2GiBs of memory trying to
>
> (asdf:oos 'asdf:load-op :hunchentoot)
>
> ends with
>
> ;;; Compiling file c:\lisplibs\hunchentoot-1.1.1\specials.lisp
> ; While compiling (:top-level-form "specials.lisp" 1551):
> Warning: Compiling a function definition for the name defconstant as a
> defmacro. ?This name is in the common-lisp
> ? ? ? ? package and redefining it will be a violation for portable
> programs. ?Replacing the current definition of
> ? ? ? ? # may be dangerous. ?The
> package common-lisp has
> ? ? ? ? excl:package-definition-lock set, which causes the system to
> signal this violation.
>
> and it seems like it freezes there. Is it normal? How long does it
> take typically to compile that specials.lisp?
>
> TIA!
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
>

From hans.huebner at gmail.com  Sun Aug 29 06:55:58 2010
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Sun, 29 Aug 2010 08:55:58 +0200
Subject: [hunchentoot-devel] cgitb
In-Reply-To: 
References: 

Message-ID: 

On Sat, Aug 28, 2010 at 12:20, Edi Weitz  wrote:
> Hunchentoot already depends om trivial-backtrace, so it should be
> pretty trivial to wrap a handler-bind around your code to make it do
> what you want.
>
> Having said that, we used to have an option to do that automatically
> (controlled by a special variable) which was removed during The Big
> Cleanup[TM]. ?If someone wants to send a patch to add this back in,
> I'll likely accept that.

I've commited http://bknr.net/trac/changeset/4603 to revive
*SHOW-LISP-BACKTRACES-P*

-Hans

From edi at agharta.de  Sun Aug 29 10:22:42 2010
From: edi at agharta.de (Edi Weitz)
Date: Sun, 29 Aug 2010 12:22:42 +0200
Subject: [hunchentoot-devel] cgitb
In-Reply-To: 
References: 

Message-ID: 

On Sun, Aug 29, 2010 at 8:55 AM, Hans H?bner  wrote:

> I've commited http://bknr.net/trac/changeset/4603 to revive
> *SHOW-LISP-BACKTRACES-P*

Thanks... :)

From peter at gigamonkeys.com  Mon Aug 30 21:00:41 2010
From: peter at gigamonkeys.com (Peter Seibel)
Date: Mon, 30 Aug 2010 14:00:41 -0700
Subject: [hunchentoot-devel] Cookies?
Message-ID: 

It seems that cookie-in returns a string, not a cookie object. Is this
a recent change or am I misunderstanding the docs?

-Peter

-- 
Peter Seibel
http://www.codequarterly.com/

From edi at agharta.de  Mon Aug 30 21:54:56 2010
From: edi at agharta.de (Edi Weitz)
Date: Mon, 30 Aug 2010 23:54:56 +0200
Subject: [hunchentoot-devel] Cookies?
In-Reply-To: 
References: 
Message-ID: 

Indeed, incoming cookies are only returned as strings and this has
always been the case.  I understand that in theory the client could
send path and domain attributes with the cookie, but I think in
practice this never happens.  At least it seems nobody using
Hunchentoot was bothered with this so far.

I agree that the documentation is a bit misleading.  Although the
chapter about cookies starts with "OUTGOING cookies [...] are CLOS
objects" which one could construe as meaning that incoming cookies
aren't... :)

Edi.

On Mon, Aug 30, 2010 at 11:00 PM, Peter Seibel  wrote:
> It seems that cookie-in returns a string, not a cookie object. Is this
> a recent change or am I misunderstanding the docs?
>
> -Peter
>
> --
> Peter Seibel
> http://www.codequarterly.com/
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
>

From peter at gigamonkeys.com  Mon Aug 30 22:01:27 2010
From: peter at gigamonkeys.com (Peter Seibel)
Date: Mon, 30 Aug 2010 15:01:27 -0700
Subject: [hunchentoot-devel] Cookies?
In-Reply-To: 
References: 

Message-ID: 

Yeah, I think the cookie-in being described as returning a "cookie" is
what threw me off.

-Peter

On Mon, Aug 30, 2010 at 2:54 PM, Edi Weitz  wrote:
> Indeed, incoming cookies are only returned as strings and this has
> always been the case. ?I understand that in theory the client could
> send path and domain attributes with the cookie, but I think in
> practice this never happens. ?At least it seems nobody using
> Hunchentoot was bothered with this so far.
>
> I agree that the documentation is a bit misleading. ?Although the
> chapter about cookies starts with "OUTGOING cookies [...] are CLOS
> objects" which one could construe as meaning that incoming cookies
> aren't... :)
>
> Edi.
>
>
> On Mon, Aug 30, 2010 at 11:00 PM, Peter Seibel  wrote:
>> It seems that cookie-in returns a string, not a cookie object. Is this
>> a recent change or am I misunderstanding the docs?
>>
>> -Peter
>>
>> --
>> Peter Seibel
>> http://www.codequarterly.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
>

-- 
Peter Seibel
http://www.codequarterly.com/