[hunchentoot-devel] create-folder-dispatcher-and-handler and pathname-name & pathname-type
Hi, I'm rather new to both hunchentoot and lispworks, so please bear with me. It seems to me that the function create-folder-dispatcher-and-handler uses the test (or (pathname-name base-path) (pathname-type base-path)) to see if base-path is indeed a directory. This fails on my system because both pathname accessors return :UNSPECIFIC, where base-path indeed names a directory. TBNL> (values (lisp-implementation-type) (lisp-implementation-version)) "LispWorks" "5.1.2" Funny thing is, when I do e.g. (pathname-name #p"/foo/bar") at the REPL, NIL is returned, where #p"/foo/bar" is cut'n'pasted from the error I get from hunchentoot. I had to modify the hunchentoot code to print the results from pathname-name to see that :UNSPECIFIC was returned. -- Frode V. Fjeld
What OS are you on? I just checked and this seems to work as expected on my machine with LWW and LWL. Also, how exactly did you specify/generate the value for base-path? Cheers, Edi. On Mon, Nov 9, 2009 at 3:48 PM, Frode V. Fjeld <frode@netfonds.no> wrote:
Hi, I'm rather new to both hunchentoot and lispworks, so please bear with me.
It seems to me that the function create-folder-dispatcher-and-handler uses the test (or (pathname-name base-path) (pathname-type base-path)) to see if base-path is indeed a directory. This fails on my system because both pathname accessors return :UNSPECIFIC, where base-path indeed names a directory.
TBNL> (values (lisp-implementation-type) (lisp-implementation-version)) "LispWorks" "5.1.2"
Funny thing is, when I do e.g. (pathname-name #p"/foo/bar") at the REPL, NIL is returned, where #p"/foo/bar" is cut'n'pasted from the error I get from hunchentoot. I had to modify the hunchentoot code to print the results from pathname-name to see that :UNSPECIFIC was returned.
-- Frode V. Fjeld
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Hi Edi, I'm on Linux/Ubuntu 9.10 i386-64. The problem occurred while trying to get weblocks-demo up and running. That is, this specific problem seems to occur (most consistently) when I purposely request a non-existing URL after having loaded and started weblocks-demo. After haveing tweaked hunchentoot slightly to expose the problem more, I'm seeing the call-stack below. #P"/home/frode/cvs/lib/asdf/weblocks/pub/" is indeed an existing directory. And, funnily enough: TBNL> (values (pathname-name #P"/home/frode/cvs/lib/asdf/weblocks/pub/") (pathname-type #P"/home/frode/cvs/lib/asdf/weblocks/pub/")) NIL NIL ..whereas they both return :UNSPECIFIC for the actual base-path, as you can gather from the stack below. Could it be that weblocks somehow creates the pathname object the wrong way? #P"/home/frode/cvs/lib/asdf/weblocks/pub/" is supposed to denote a directory. :UNSPECIFIC :UNSPECIFIC [Condition of type HUNCHENTOOT:PARAMETER-ERROR] Restarts: 0: [ABORT] Quit process. Backtrace: 0: (SUBFUNCTION 2 (METHOD HUNCHENTOOT:PROCESS-REQUEST (T))) (#<HUNCHENTOOT:PARAMETER-ERROR 40500858AB>) 1: SIGNAL (#<HUNCHENTOOT:PARAMETER-ERROR 40500858AB> &REST NIL) 2: CONDITIONS::CONDITIONS-ERROR (:INVISIBLEP ..) 3: ERROR (HUNCHENTOOT:PARAMETER-ERROR &REST (:FORMAT-CONTROL "~S is supposed to denote a directory. ~S ~S" :FORMAT-ARGUMENTS (#P"/home/frode/cvs/lib/asdf/weblocks/pub/" :UNSPECIFIC :UNSPECIFIC))) 4: HUNCHENTOOT:PARAMETER-ERROR ("~S is supposed to denote a directory. ~S ~S" &REST (#P"/home/frode/cvs/lib/asdf/weblocks/pub/" :UNSPECIFIC :UNSPECIFIC)) 5: HUNCHENTOOT:CREATE-FOLDER-DISPATCHER-AND-HANDLER ("/weblocks-common/pub/" #P"/home/frode/cvs/lib/asdf/weblocks/pub/" &OPTIONAL NIL) 6: WEBLOCKS::WEBLOCKS-DISPATCHER (#<HUNCHENTOOT:REQUEST 405007DED3>) 7: HUNCHENTOOT::LIST-REQUEST-DISPATCHER (#<HUNCHENTOOT:REQUEST 405007DED3>) 8: (METHOD HUNCHENTOOT:PROCESS-REQUEST (T)) (#<HUNCHENTOOT:REQUEST 405007DED3>) 9: (METHOD HUNCHENTOOT:PROCESS-CONNECTION (HUNCHENTOOT:ACCEPTOR T)) (#<WEBLOCKS:WEBLOCKS-ACCEPTOR (host *, port 8080)> 8) 10: CLOS::NEXT-METHOD-CALL-2 ((METHOD HUNCHENTOOT:PROCESS-CONNECTION (WEBLOCKS:WEBLOCKS-ACCEPTOR T)) ..) 11: (METHOD HUNCHENTOOT:PROCESS-CONNECTION (WEBLOCKS:WEBLOCKS-ACCEPTOR T)) (#<WEBLOCKS:WEBLOCKS-ACCEPTOR (host *, port 8080)> 8) 12: CLOS::METHOD-COMBINATION-TEMPLATE (:INVISIBLEP T) 13: CLOS::NEXT-METHOD-CALL-2 ((METHOD HUNCHENTOOT:PROCESS-CONNECTION :AROUND (HUNCHENTOOT:ACCEPTOR T)) ..) 14: (METHOD HUNCHENTOOT:PROCESS-CONNECTION :AROUND (HUNCHENTOOT:ACCEPTOR T)) (#<WEBLOCKS:WEBLOCKS-ACCEPTOR (host *, port 8080)> 8) 15: CLOS::METHOD-COMBINATION-TEMPLATE (:INVISIBLEP T) 16: (SUBFUNCTION MP::PROCESS-SG-FUNCTION MP::INITIALIZE-PROCESS-STACK) (:DONT-KNOW) 17: SYSTEM::%%FIRST-CALL-TO-STACK NIL Thanks, Frode Edi Weitz <edi@agharta.de> writes:
What OS are you on? I just checked and this seems to work as expected on my machine with LWW and LWL.
Also, how exactly did you specify/generate the value for base-path?
Cheers, Edi.
On Mon, Nov 9, 2009 at 3:48 PM, Frode V. Fjeld <frode@netfonds.no> wrote:
Hi, I'm rather new to both hunchentoot and lispworks, so please bear with me.
It seems to me that the function create-folder-dispatcher-and-handler uses the test (or (pathname-name base-path) (pathname-type base-path)) to see if base-path is indeed a directory. This fails on my system because both pathname accessors return :UNSPECIFIC, where base-path indeed names a directory.
TBNL> (values (lisp-implementation-type) (lisp-implementation-version)) "LispWorks" "5.1.2"
Funny thing is, when I do e.g. (pathname-name #p"/foo/bar") at the REPL, NIL is returned, where #p"/foo/bar" is cut'n'pasted from the error I get from hunchentoot. I had to modify the hunchentoot code to print the results from pathname-name to see that :UNSPECIFIC was returned.
-- Frode V. Fjeld
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Tue, Nov 10, 2009 at 9:18 AM, Frode V. Fjeld <frode@netfonds.no> wrote:
TBNL> (values (pathname-name #P"/home/frode/cvs/lib/asdf/weblocks/pub/") (pathname-type #P"/home/frode/cvs/lib/asdf/weblocks/pub/")) NIL NIL
Yes, that is what I would expect.
..whereas they both return :UNSPECIFIC for the actual base-path, as you can gather from the stack below. Could it be that weblocks somehow creates the pathname object the wrong way?
That would be my guess. I'm not familiar with weblocks, though. Cheers, Edi.
Edi Weitz wrote:
On Tue, Nov 10, 2009 at 9:18 AM, Frode V. Fjeld <frode@netfonds.no> wrote:
TBNL> (values (pathname-name #P"/home/frode/cvs/lib/asdf/weblocks/pub/") (pathname-type #P"/home/frode/cvs/lib/asdf/weblocks/pub/")) NIL NIL
Yes, that is what I would expect.
..whereas they both return :UNSPECIFIC for the actual base-path, as you can gather from the stack below. Could it be that weblocks somehow creates the pathname object the wrong way?
That would be my guess. I'm not familiar with weblocks, though.
I've missed that the OP was using Weblocks. We've had pathname issues with Lispworks in the past, and they might still be in the stable branch. I suggest to try weblocks-dev to see if this has been resolved and write to the Weblocks list if it hasn't. Leslie -- http://www.linkedin.com/in/polzer
"Leslie P. Polzer" <sky@viridian-project.de> writes:
I've missed that the OP was using Weblocks. We've had pathname issues with Lispworks in the past, and they might still be in the stable branch.
I didn't suspect it was a weblocks issue at first.
I suggest to try weblocks-dev to see if this has been resolved and write to the Weblocks list if it hasn't.
I tried weblocks-dev, and the problem appears to remain. I also made a post to the Weblocks list about this. However, I think I finally found the relevant section of the CLHS:
19.2.2.2.3 :UNSPECIFIC as a Component Value
If :unspecific is the value of a pathname component, the component is considered to be ``absent'' or to ``have no meaning'' in the filename being represented by the pathname.
[...]
When reading[1] the value of any pathname component, conforming programs should be prepared for the value to be :unspecific.
The last paragraph indicates to me that the correct resolution would be for hunchentoot to be prepared to see either NIL or :UNSPECIFIC ..? -- Frode V. Fjeld
On Tue, Nov 10, 2009 at 11:06 AM, Frode V. Fjeld <frode@netfonds.no> wrote:
The last paragraph indicates to me that the correct resolution would be for hunchentoot to be prepared to see either NIL or :UNSPECIFIC ..?
Yes, that sounds reasonable. I'll change that in the BKNR repository. Thanks, Edi.
On Tue, Nov 10, 2009 at 11:06 AM, Frode V. Fjeld <frode@netfonds.no> wrote:
The last paragraph indicates to me that the correct resolution would be for hunchentoot to be prepared to see either NIL or :UNSPECIFIC ..?
Edi Weitz <edi@agharta.de> writes:
Yes, that sounds reasonable. I'll change that in the BKNR repository.
That's excellent. Thank you. -- Frode V. Fjeld
Quoth Edi Weitz <edi@agharta.de>:
I'll change that in the BKNR repository.
Is the bknr repository the canonical location for hunchentoot development work and if so, is there any reason why it isn't used by clbuild? Seb -- Emacs' AlsaPlayer - Music Without Jolts Lightweight, full-featured and mindful of your idyllic happiness. http://home.gna.org/eap
On Tue, Nov 10, 2009 at 2:52 PM, Sebastian Tennant <sebyte@smolny.plus.com> wrote:
Is the bknr repository the canonical location for hunchentoot development work and if so, is there any reason why it isn't used by clbuild?
It currently is and has been so for almost a year, I think. And as long as Hans doesn't want to get rid of me, I don't expect this to change any time soon. I can't answer the question about clbuild.
Quoth Edi Weitz <edi@agharta.de>:
I can't answer the question about clbuild.
How about this question then.. do you want clbuild users to use the development version of hunchentoot or static timed releases (as is the case at the moment)? A simple email to the clbuild mailing list and they will change the download location. Seb -- Emacs' AlsaPlayer - Music Without Jolts Lightweight, full-featured and mindful of your idyllic happiness. http://home.gna.org/eap
On Tue, Nov 10, 2009 at 5:08 PM, Sebastian Tennant <sebyte@smolny.plus.com> wrote:
How about this question then.. do you want clbuild users to use the development version of hunchentoot or static timed releases (as is the case at the moment)?
I think I'd prefer them to use released versions. Those who want to live on the bleeding edge, should decide for themselves and be prepared to read the mailing list.
Quoth Edi Weitz <edi@agharta.de>:
I think I'd prefer them to use released versions. Those who want to live on the bleeding edge, should decide for themselves and be prepared to read the mailing list.
As I suspected. Thanks for the confirmation. Seb -- Emacs' AlsaPlayer - Music Without Jolts Lightweight, full-featured and mindful of your idyllic happiness. http://home.gna.org/eap
On Tue, Nov 10, 2009 at 9:18 AM, Frode V. Fjeld <frode@netfonds.no> wrote:
..whereas they both return :UNSPECIFIC for the actual base-path, as you can gather from the stack below. Could it be that weblocks somehow creates the pathname object the wrong way?
Edi Weitz <edi@agharta.de> writes:
That would be my guess. I'm not familiar with weblocks, though.
It appears that the root cause is this effect: TBNL> (values (pathname-type #p"/tmp") (pathname-type (probe-file #p"/tmp"))) NIL :UNSPECIFIC (Btw. sbcl will return NIL for both.) It's unclear to me what the semantics of NIL vs. :UNSPECIFIC is supposed to be, and so whether it's weblocks or hunchentoot (or both?) that needs to be tweaked. -- Frode V. Fjeld
participants (4)
-
Edi Weitz -
frode＠netfonds.no -
Leslie P. Polzer -
Sebastian Tennant