Hi folks,
Is anyone still encountering problems with binary uploads using TBNL with SBCL and the mod_lisp front-end? I've applied Travis Cross' patches to KMRCL and RFC2388. But in spite of the patches, I'm seeing errors when trying to upload a binary file to the tbnl-test demo application. For example:
#<SB-SYS:FD-STREAM for "a constant string" {B7C2F69}> (:EXTERNAL-FORMAT :UTF-8): the octet sequence (226 227 207) cannot be decoded.
I'm using SBCL 0.9.15 on Linux 2.6; TBNL 0.11.3, KMRCL-1.89, and a fresh RFC2388, with the Cross patches applied. *features* and SLIME backtrace are below. I'm happy to do more testing/debugging, but perhaps someone could help point me in the right direction.
Thanks, Graham
*features* (:CL-WHO :TBNL :TBNL-SBCL-DEBUG-PRINT-VARIABLE-ALIST :TBNL-BIVALENT-STREAMS :URL-REWRITE :KMR-NORMAL-DSDC :KMR-NORMAL-CESD :CL-PPCRE :KMR-MOP :ASDF :SB-THREAD :ANSI-CL :COMMON-LISP :SBCL :UNIX :SB-DOC :SB-TEST :SB-LDB :SB-PACKAGE-LOCKS :SB-UNICODE :SB-SOURCE-LOCATIONS :IEEE-FLOATING-POINT :X86 :ELF :LINUX :GENCGC :STACK-GROWS-DOWNWARD-NOT-UPWARD :C-STACK-IS-CONTROL-STACK :STACK-ALLOCATABLE-CLOSURES :ALIEN-CALLBACKS :LINKAGE-TABLE :OS-PROVIDES-DLOPEN :OS-PROVIDES-DLADDR :OS-PROVIDES-PUTWC)
Snipped backtrace: 7: (TBNL::MAYBE-INVOKE-DEBUGGER #<SB-INT:STREAM-DECODING-ERROR {CFC3BC1}>) 8: (SIGNAL #<SB-INT:STREAM-DECODING-ERROR {CFC3BC1}>) 9: (ERROR SB-INT:STREAM-DECODING-ERROR) 10: (SB-INT:STREAM-DECODING-ERROR #<SB-SYS:FD-STREAM for "a constant string" {C6F56C1}> (226 227 207)) 11: (SB-IMPL::STREAM-DECODING-ERROR-AND-HANDLE #<SB-SYS:FD-STREAM for "a constant string" {C6F56C1}> 3) 12: (SB-IMPL::INPUT-CHAR/UTF-8 #<SB-SYS:FD-STREAM for "a constant string" {C6F56C1}> NIL NIL) 13: (READ-CHAR #<SB-SYS:FD-STREAM for "a constant string" {C6F56C1}> NIL NIL #<unused argument>) 14: ((FLET RFC2388::RUN) #<SB-SYS:FD-STREAM for "file /tmp/tbnl/tbnl-16" {CFC39B1}>) 15: (RFC2388::READ-UNTIL-NEXT-BOUNDARY #<SB-SYS:FD-STREAM for "a constant string" {C6F56C1}> "--------------------$ 16: ((SB-PCL::FAST-METHOD RFC2388:PARSE-MIME (STREAM T)) #<unavailable argument> #<unavailable argument> #<SB-SYS:$ 17: (TBNL::PARSE-RFC2388-FORM-DATA #<SB-SYS:FD-STREAM for "a constant string" {C6F56C1}> "multipart/form-data; bou$ 18: ((SB-PCL::FAST-METHOD INITIALIZE-INSTANCE :AFTER (TBNL::REQUEST)) (#(NIL 1 2 0 3 5 8 4 6) . #()) #<unavailable$ 19: ((LAMBDA (SB-PCL::|.P0.|)) #<unavailable argument>) 20: (TBNL::PROCESS-REQUEST (("content-stream" . #<SB-SYS:FD-STREAM for "a constant string" {C6F56C1}>) ("server-pr$ 21: (TBNL::LISTEN-FOR-REQUEST #<SB-SYS:FD-STREAM for "a constant string" {C6F56C1}> TBNL::PROCESS-REQUEST) 22: ((LAMBDA NIL))
On 10/4/06, Graham Fawcett graham.fawcett@gmail.com wrote:
Is anyone still encountering problems with binary uploads using TBNL with SBCL and the mod_lisp front-end? I've applied Travis Cross' patches to KMRCL and RFC2388. But in spite of the patches, I'm seeing errors when trying to upload a binary file to the tbnl-test demo application. For example:
I'm afraid I can't be very helpful other than to point out that it works with my setup: TBNL 0.11.3, SBCL 0.9.13, RFC2388 with Travis' patches and KMRCL 1.87.
Thanks, Erik.
On Wed, 4 Oct 2006 10:40:31 -0400, "Graham Fawcett" graham.fawcett@gmail.com wrote:
Is anyone still encountering problems with binary uploads using TBNL with SBCL and the mod_lisp front-end? I've applied Travis Cross' patches to KMRCL and RFC2388.
Probably not relevant in this case, but I think the latest version of RFC2388 doesn't need patches for SBCL anymore.
But in spite of the patches, I'm seeing errors when trying to upload a binary file to the tbnl-test demo application. For example:
#<SB-SYS:FD-STREAM for "a constant string" {B7C2F69}> (:EXTERNAL-FORMAT :UTF-8): the octet sequence (226 227 207) cannot be decoded.
I'm using SBCL 0.9.15 on Linux 2.6; TBNL 0.11.3, KMRCL-1.89, and a fresh RFC2388, with the Cross patches applied. *features* and SLIME backtrace are below. I'm happy to do more testing/debugging, but perhaps someone could help point me in the right direction.
If it's not urgent, you should take a look at the Hunchentoot beta which is supposed to replace TBNL soon. I hope the issues with SBCL will vanish with this release. If not, I'd like to know.
See the "Hunchentoot for SBCL..." thread here
http://common-lisp.net/pipermail/tbnl-devel/2006-October/thread.html
and use the second beta announced on October 2.
Cheers, Edi.
If it's not urgent, you should take a look at the Hunchentoot beta which is supposed to replace TBNL soon. I hope the issues with SBCL will vanish with this release. If not, I'd like to know.
See the "Hunchentoot for SBCL..." thread here
http://common-lisp.net/pipermail/tbnl-devel/2006-October/thread.html
and use the second beta announced on October 2.
Cheers, Edi.
Hunchentoot beta allows uploading binary files with SBCL 0.9.16. everything works nicely. Than you very much.
The only part of tbnl that does not play nicely with my setup is the usage of (load-time-value *load-pathname*) as it is not working with asdf-binary-locations nicely. I really want my fasl files in the different place from my lisp files (constant upgrades to sbcl become more difficult otherwise), but tbnl-test complains about not being able to find fz.jpg (sbcl it tries to find near fasl files). For my own libraries i am using #.(or *compile-file-truename* *load-truename*) which kind of works on sbcl, though i am not 100% sure it is the right way if it would work on ACL and lispworks (i do not have these implementations) i can send you the patch.
Ignas
On Wed, 4 Oct 2006 19:02:37 +0300, "Ignas Mikalajunas" ignas.mikalajunas@gmail.com wrote:
The only part of tbnl that does not play nicely with my setup is the usage of (load-time-value *load-pathname*) as it is not working with asdf-binary-locations nicely. I really want my fasl files in the different place from my lisp files (constant upgrades to sbcl become more difficult otherwise), but tbnl-test complains about not being able to find fz.jpg (sbcl it tries to find near fasl files). For my own libraries i am using #.(or *compile-file-truename* *load-truename*) which kind of works on sbcl, though i am not 100% sure it is the right way if it would work on ACL and lispworks (i do not have these implementations) i can send you the patch.
Thanks, I've updated my local source tree accordingly. Will be in the next release. I /think/
(load-time-value (or #.*compile-file-pathname* *load-pathname*))
should be a portable solution.
On 10/4/06, Edi Weitz edi@agharta.de wrote:
If it's not urgent, you should take a look at the Hunchentoot beta which is supposed to replace TBNL soon. I hope the issues with SBCL will vanish with this release. If not, I'd like to know.
Sure, it's not urgent. :-) I downloaded the second beta, followed the build instructions, and I get the following error when I visit the app with my browser:
invalid structure layout: A test for class STREAM was passed the obsolete instance #<FLEXI-STREAMS::VECTOR-INPUT-STREAM {BF89951}> [Condition of type SB-KERNEL:LAYOUT-INVALID]
I see there is a patch to SBCL[1] that is supposed to correct this; I'll give it a try again after that.
Graham
[1] http://sourceforge.net/mailarchive/message.php?msg_id=36304967
Graham
On 10/4/06, Graham Fawcett graham.fawcett@gmail.com wrote:
Sure, it's not urgent. :-) I downloaded the second beta, followed the build instructions, and I get the following error when I visit the app with my browser:
invalid structure layout: A test for class STREAM was passed the obsolete instance #<FLEXI-STREAMS::VECTOR-INPUT-STREAM {BF89951}> [Condition of type SB-KERNEL:LAYOUT-INVALID]
I see there is a patch to SBCL[1] that is supposed to correct this; I'll give it a try again after that.
I upgraded SBCL from 0.9.15 to 0.9.17, and this fixed the problem. Ingas reported that it is also working on 0.9.16: so that's the minimum.
Initial impressions of hunchentoot on SBCL: w00t! My binary uploads are working! :-)
I'll do some performance tests, but so far this seems to be working very well. Thanks so much!
Graham
On Wed, 4 Oct 2006 13:42:40 -0400, "Graham Fawcett" graham.fawcett@gmail.com wrote:
I'll do some performance tests, but so far this seems to be working very well.
Great! I expect performance to be a bit worse than "pure" TBNL because now two Gray streams are wrapped around the socket stream, but I don't think this'll be a problem (unless you are in the Google ballpark). Both FLEXI-STREAMS and CHUNGA haven't been optimized for speed yet, so there's enough room for improvement if necessary.