Hello list,
this is with a fresh svn checkout from: svn://bknr.net/svn/trunk/thirdparty/hunchentoot svn://bknr.net/svn/trunk/thirdparty/cl-webdav
In a shell:
cadaver http://localhost:4243/
triggers the following backtrace:
The function (SETF HUNCHENTOOT:CONTENT-TYPE) is undefined. [Condition of type UNDEFINED-FUNCTION]
Restarts: 0: [TERMINATE-THREAD] Terminate this thread (#<THREAD "Hunchentoot worker (client: 127.0.0.1:35255)" RUNNING {C164E19}>)
Backtrace: 0: ((LAMBDA (SWANK-BACKEND::DEBUGGER-LOOP-FN)) #<FUNCTION (LAMBDA #) {AF28C2D}>) 1: (SWANK::DEBUG-IN-EMACS #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}>) 2: (SWANK-BACKEND::CALL-WITH-BREAK-HOOK #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {C1B909D}>) 3: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {C1B909D}>) 4: (SWANK::CALL-WITH-BINDINGS ..) 5: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {B366A09}> #<CLOSURE (LAMBDA #) {C1B909D}>) 6: (SWANK:INVOKE-SLIME-DEBUGGER #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}>) 7: (SWANK-BACKEND::CALL-WITH-BREAK-HOOK #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {C1B907D}>) 8: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {C1B907D}>) 9: (SWANK:SWANK-DEBUGGER-HOOK #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}> #<unavailable argument>) 10: (INVOKE-DEBUGGER #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}>) 11: ((SB-PCL::FAST-METHOD HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER (T)) #<unavailable argument> #<unavailable argument> #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}>) 12: (SIGNAL #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}>)[:EXTERNAL] 13: (ERROR UNDEFINED-FUNCTION)[:EXTERNAL] 14: (SB-KERNEL::UNDEFINED-FUN-ERROR-HANDLER #<unavailable argument> #.(SB-SYS:INT-SAP #XB6561D10) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #XB6561A1C :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14)) 15: (SB-KERNEL:INTERNAL-ERROR #.(SB-SYS:INT-SAP #XB6561A1C) #<unavailable argument>) 16: ("foreign function: #x806726B") 17: ("foreign function: #x8052FE8") 18: ("foreign function: #x805872E") 19: ("foreign function: #x8056E2B") --more--
Is this a known problem?
TIA Ralf Mattes
Since Hunchentoot 1.0, a lot of functions for setting HTTP header informations changed their name from foo to foo*.
So you can fix this in your copy by calling content-type* instead of content-type http://www.weitz.de/hunchentoot/#content-type*
But that of course doesn't fix the svn.
Best, Martin
On Feb 17, 2010, at 4:18 PM, Ralf Mattes wrote:
Hello list,
this is with a fresh svn checkout from: svn://bknr.net/svn/trunk/thirdparty/hunchentoot svn://bknr.net/svn/trunk/thirdparty/cl-webdav
In a shell:
cadaver http://localhost:4243/
triggers the following backtrace:
The function (SETF HUNCHENTOOT:CONTENT-TYPE) is undefined. [Condition of type UNDEFINED-FUNCTION]
Restarts: 0: [TERMINATE-THREAD] Terminate this thread (#<THREAD "Hunchentoot worker (client: 127.0.0.1:35255)" RUNNING {C164E19}>)
Backtrace: 0: ((LAMBDA (SWANK-BACKEND::DEBUGGER-LOOP-FN)) #<FUNCTION (LAMBDA #) {AF28C2D}>) 1: (SWANK::DEBUG-IN-EMACS #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}>) 2: (SWANK-BACKEND::CALL-WITH-BREAK-HOOK #<FUNCTION SWANK:SWANK- DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {C1B909D}>) 3: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {C1B909D}>) 4: (SWANK::CALL-WITH-BINDINGS ..) 5: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {B366A09}> #<CLOSURE (LAMBDA #) {C1B909D}>) 6: (SWANK:INVOKE-SLIME-DEBUGGER #<UNDEFINED-FUNCTION (SETF CONTENT- TYPE) {C1B8FF1}>) 7: (SWANK-BACKEND::CALL-WITH-BREAK-HOOK #<FUNCTION SWANK:SWANK- DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {C1B907D}>) 8: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {C1B907D}>) 9: (SWANK:SWANK-DEBUGGER-HOOK #<UNDEFINED-FUNCTION (SETF CONTENT- TYPE) {C1B8FF1}> #<unavailable argument>) 10: (INVOKE-DEBUGGER #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}>) 11: ((SB-PCL::FAST-METHOD HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER (T)) #<unavailable argument> #<unavailable argument> #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}>) 12: (SIGNAL #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}>) [:EXTERNAL] 13: (ERROR UNDEFINED-FUNCTION)[:EXTERNAL] 14: (SB-KERNEL::UNDEFINED-FUN-ERROR-HANDLER #<unavailable argument> #.(SB-SYS:INT-SAP #XB6561D10) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #XB6561A1C :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14)) 15: (SB-KERNEL:INTERNAL-ERROR #.(SB-SYS:INT-SAP #XB6561A1C) #<unavailable argument>) 16: ("foreign function: #x806726B") 17: ("foreign function: #x8052FE8") 18: ("foreign function: #x805872E") 19: ("foreign function: #x8056E2B") --more--
Is this a known problem?
TIA Ralf Mattes
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Well, cl-webdav had not been brought fully up to speed with hunchentoot v1.x yet. I submitted a simple patch to get some cl-webdav commands working (basically what Martin notes: <function> to <function>*) although that alone doesn't get all the commands working (but I thought the command you ran was working last I looked at it). I haven't finished with it yet, so this is my bad, as Edi asked me to look at it awhile ago, and I got busy with other things.
-Matt
On Wed, Feb 17, 2010 at 10:18 AM, Ralf Mattes rm@seid-online.de wrote:
Hello list,
this is with a fresh svn checkout from: svn://bknr.net/svn/trunk/thirdparty/hunchentoot svn://bknr.net/svn/trunk/thirdparty/cl-webdav
In a shell:
cadaver http://localhost:4243/
triggers the following backtrace:
The function (SETF HUNCHENTOOT:CONTENT-TYPE) is undefined. [Condition of type UNDEFINED-FUNCTION]
Restarts: 0: [TERMINATE-THREAD] Terminate this thread (#<THREAD "Hunchentoot worker (client: 127.0.0.1:35255)" RUNNING {C164E19}>)
Backtrace: 0: ((LAMBDA (SWANK-BACKEND::DEBUGGER-LOOP-FN)) #<FUNCTION (LAMBDA #) {AF28C2D}>) 1: (SWANK::DEBUG-IN-EMACS #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}>) 2: (SWANK-BACKEND::CALL-WITH-BREAK-HOOK #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {C1B909D}>) 3: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {C1B909D}>) 4: (SWANK::CALL-WITH-BINDINGS ..) 5: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {B366A09}> #<CLOSURE (LAMBDA #) {C1B909D}>) 6: (SWANK:INVOKE-SLIME-DEBUGGER #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}>) 7: (SWANK-BACKEND::CALL-WITH-BREAK-HOOK #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {C1B907D}>) 8: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {C1B907D}>) 9: (SWANK:SWANK-DEBUGGER-HOOK #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}> #<unavailable argument>) 10: (INVOKE-DEBUGGER #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}>) 11: ((SB-PCL::FAST-METHOD HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER (T)) #<unavailable argument> #<unavailable argument> #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}>) 12: (SIGNAL #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}>)[:EXTERNAL] 13: (ERROR UNDEFINED-FUNCTION)[:EXTERNAL] 14: (SB-KERNEL::UNDEFINED-FUN-ERROR-HANDLER #<unavailable argument> #.(SB-SYS:INT-SAP #XB6561D10) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #XB6561A1C :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14)) 15: (SB-KERNEL:INTERNAL-ERROR #.(SB-SYS:INT-SAP #XB6561A1C) #<unavailable argument>) 16: ("foreign function: #x806726B") 17: ("foreign function: #x8052FE8") 18: ("foreign function: #x805872E") 19: ("foreign function: #x8056E2B") --more--
Is this a known problem?
TIA Ralf Mattes
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Wed, 2010-02-17 at 10:46 -0500, Matthew Curry wrote:
Well, cl-webdav had not been brought fully up to speed with hunchentoot v1.x yet. I submitted a simple patch to get some cl-webdav commands working (basically what Martin notes: <function> to <function>*) although that alone doesn't get all the commands working (but I thought the command you ran was working last I looked at it).
Looks like Edi didn't apply all of that patch.
I haven't finished with it yet, so this is my bad, as Edi asked me to look at it awhile ago, and I got busy with other things.
I'll try to fix it locally and maybe send a patch.
Thank's for your time
RalfD
-Matt
On Wed, Feb 17, 2010 at 9:12 PM, Ralf Mattes rm@seid-online.de wrote:
Looks like Edi didn't apply all of that patch.
Hmm, I just looked at this again and it seems I /wrote/ that I applied the patch but in fact I didn't. Cough...
Let's see...