flexi-streams-devel August 2007

flexi-streams-devel@common-lisp.net

2 participants
3 discussions

[flexi-streams-devel] New release 0.11.1
by Edi Weitz 10 Nov '07

10 Nov '07

ChangeLog: Version 0.11.1 2007-03-22 More ugliness for a bit of output performance in special cases Download: http://weitz.de/files/flexi-streams.tar.gz Cheers, Edi.

3 9

[flexi-streams-devel] Re: [hunchentoot-devel] write-sequence to *hunchentoot-stream* on x86_64
by Jeff Caldwell 22 Aug '07

22 Aug '07

Hi Edi, Thanks for pointing me in a good direction. I hope this ends up in the same thread as your cc from hunchentoot-devel, but here is a summary in case it doesn't: 32-bit LWLPro 4.3.7 ran OK on 32-bit Linux but on x86_64. Hunchentoot returned the headers OK, followed by a block of seemingly-random binary data, followed by the content, which was OK. I found a workaround, using write-string instead of write-sequence to write the content. >Edi wrote: > >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. The flexi-streams test suite ran with all tests passed (3313 of them, if I recall correctly). LWL 5.0.x Personal Edition does not exhibit the problem. I'm using flexi-streams-0.11.2. I suppose the limitation of my workaround (write-string vs write-sequence) is the charset, no UTF? Anything else to be aware of? Maybe I can leverage this app into a nice new 5.0 license, courtesy of my employer. If not, do you have a quick thought regarding where else I might look to change the behavior in 4.3.7? Thanks, Jeff Caldwell ____________________________________________________________________________________Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. http://tv.yahoo.com/

2 1

[flexi-streams-devel] Re: [hunchentoot-devel] write-sequence to *hunchentoot-stream* on x86_64
by Edi Weitz 21 Aug '07

21 Aug '07

On Mon, 20 Aug 2007 12:47:06 -0700 (PDT), Jeff Caldwell <jdcal(a)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.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

flexi-streams-devel August 2007