Re: Spiffy relies on content-length (was Re: [Chicken-users] Spiffy relies on removed proc.)
On Sun, Mar 16, 2008 at 6:06 PM, Peter Bex <[EMAIL PROTECTED]> wrote: > On Sun, Mar 16, 2008 at 02:56:11PM -0700, Robin Lee Powell wrote: > > With define-http-resource, *Spiffy* defines the headers, and it > > never asks the body. In fact, the headers are sent before the body > > is run. > > That's not entirely correct. Spiffy parameterizes the headers. You > can override them in the body. I'm glad I wasn't totally wrong, since I didn't look into Spiffy's docs first. :-) But yes, this should work: (current-reponse-headers (cons (cons "Content-Length" (->string clen)) (current-response-headers))) Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: Spiffy relies on content-length (was Re: [Chicken-users] Spiffy relies on removed proc.)
On Sun, Mar 16, 2008 at 02:56:11PM -0700, Robin Lee Powell wrote: > With define-http-resource, *Spiffy* defines the headers, and it > never asks the body. In fact, the headers are sent before the body > is run. That's not entirely correct. Spiffy parameterizes the headers. You can override them in the body. However, I *do* think that Spiffy should do the Right Thing and send the Content-Length header. I'm trying to come up with a test case so I can have something to ensure this will not happen in the future. Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth pgpACwNeewNZ4.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: Spiffy relies on content-length (was Re: [Chicken-users] Spiffy relies on removed proc.)
On Sun, Mar 16, 2008 at 04:48:29PM -0400, Graham Fawcett wrote: > Well, you've got three options that I can think of: > > 1) use a Content-Length header, > 2) use a Connection: close header to prevent keep-alive, > 3) use chunked encoding to send responses of arbitrary length, but > retaining keepalive. Ah, you've made a false assumption, I'm afraid, which is that I can do any of those things. With define-http-resource, *Spiffy* defines the headers, and it never asks the body. In fact, the headers are sent before the body is run. -Robin -- Lojban Reason #17: http://en.wikipedia.org/wiki/Buffalo_buffalo Proud Supporter of the Singularity Institute - http://singinst.org/ http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: Spiffy relies on content-length (was Re: [Chicken-users] Spiffy relies on removed proc.)
On Sun, Mar 16, 2008 at 4:06 PM, Robin Lee Powell
<[EMAIL PROTECTED]> wrote:
> On Sun, Mar 16, 2008 at 03:20:11PM +0100, Peter Bex wrote:
> >
> > Thanks for the error report! I've fixed the bug and added a
> > testcase for it so it will not happen again. I've also pushed a
> > new release which should be available shortly (3.8).
>
> It seems to work now, but this leads to a more general Spiffy
> problem.
>
> Run spiffy with:
>
> (define-http-resource ("/test") "test html, sort of")
>
> and then access /test in any browser. You will find (I hope) that
> the browser hangs until timeout or until you kill Spiffy; I
> certainly do.
>
> Sending a Content-Length header, which define-http-resource doesn't,
> solves the problem.
Well, you've got three options that I can think of:
1) use a Content-Length header,
2) use a Connection: close header to prevent keep-alive,
3) use chunked encoding to send responses of arbitrary length, but
retaining keepalive.
The latter requires a "Transport-Encoding: chunked" header, and an
encoding of your response into chunked format. It's not hard, and a
(define-http-resource/chunked) could be written to handle the encoding
and header for you. See
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1 for the
details.
But still, there are at least three options, and none is "correct" as
a default. The lack of a correct default is probably why Spiffy punts
on the issue and leaves it up to you to do the right thing for your
app.
Graham
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Spiffy relies on content-length (was Re: [Chicken-users] Spiffy relies on removed proc.)
On Sun, Mar 16, 2008 at 03:20:11PM +0100, Peter Bex wrote:
>
> Thanks for the error report! I've fixed the bug and added a
> testcase for it so it will not happen again. I've also pushed a
> new release which should be available shortly (3.8).
It seems to work now, but this leads to a more general Spiffy
problem.
Run spiffy with:
(define-http-resource ("/test") "test html, sort of")
and then access /test in any browser. You will find (I hope) that
the browser hangs until timeout or until you kill Spiffy; I
certainly do.
Sending a Content-Length header, which define-http-resource doesn't,
solves the problem.
The issue is *probably* that Spiffy does keep-alive connections by
default, and without Content-Length, there's no way to know when the
server is done talking.
I'm not sure that keep-alive by default is the right thing (I mean
I'm genuinely not sure: I don't know much at all about how
keep-alive works), and even if it is, there should be a way to turn
it off, and there doesn't seem to be.
-Robin
--
Lojban Reason #17: http://en.wikipedia.org/wiki/Buffalo_buffalo
Proud Supporter of the Singularity Institute - http://singinst.org/
http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Problem with ~?
On Sat, Mar 15, 2008 at 10:13:52AM -0700, Kon Lovett wrote: > > > Fixed in chicken/trunk. > > This was a holdover from a previous incarnation of fprintf which > didn't use a string buffer but wrote directly to the port. Not all > ramifications of the change were investigated. Fix confirmed. Thanks! -Robin -- Lojban Reason #17: http://en.wikipedia.org/wiki/Buffalo_buffalo Proud Supporter of the Singularity Institute - http://singinst.org/ http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Proposed egg-post-commit changes.
So I mentioned in an earlier mail that I'd like to do 2-fork documentation: wiki for general docs and examples and so on, and mole-generated docs for actual function definitions. Turns out egg-post-commit won't allow this. I've got some suggested changes here, first to the .meta file, then to egg-post-commit.scm itself. These are totally untested, because I tried to get egg-post-commit to work on my system and it just kept getting more and more scary/baroque, and eventually I gave up. I've updated caketext/1.5 to use this tag, so if someone (Mario?) could try this new code out on the egg build box, I'd be very grateful. -Robin - .meta ; The following is used to add additional documents to the install, ; so the auto-generated or wiki documents can like to them. All ; file names listed here will have "[egg]-" added to the front, so ; if you put "doc.html" here, make sure "mpeg3-doc.html" exists. ; (documentation "doc.html") - -- Index: egg-post-commit.scm === --- egg-post-commit.scm (revision 9794) +++ egg-post-commit.scm (working copy) @@ -359,6 +359,18 @@ (system* "csi -s ~a >~a" (make-pathname egg-dir (cadr edoc)) (make-pathname egg-dir eggname "html")) ) ) ) +; Install additional documentation, if any. +(cond + ((assq 'documentation meta) + => + (lambda (docs) + (for-each + (lambda (doc) + (let ([doc-full (conc eggname "-" doc)]) + (print "Installying additional docs: " doc-full) + (set! eggfiles (cons (make-pathname egg-dir doc-full) + (cdr docs) + (print "Creating egg...") (if files (system* "D=`pwd`; cd ~a; ~a cfz $D/~a ~a ~a 2>&1" -- Lojban Reason #17: http://en.wikipedia.org/wiki/Buffalo_buffalo Proud Supporter of the Singularity Institute - http://singinst.org/ http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] ANN: Updated srfi-29, procedure-surface, levenshtein eggs
Hi Folks, - srfi-29 1.7.0: Cached template lookup. 'localized-template' takes default parameter. Added 'localized-format', 'current-locale-format- function'. - procedure-surface 1.1.0: Removed syntax-case dependency. - levenshtein 1.7.0: Removed syntax-case dependency. Requirement of toplevel-only utf8 egg. Best Wishes, Kon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ditching syntax-case modules for the utf8 egg
On Mar 16, 2008, at 12:07 AM, Alex Shinn wrote: "Kon" == Kon Lovett <[EMAIL PROTECTED]> writes: Kon> On Mar 15, 2008, at 9:33 AM, Felix Winkelmann wrote: Kon> Is this a "char-string" issue or a "byte-string" Kon> issue? When the source "...string..." is a string Kon> of ASCII non-nul char then there should be no Kon> problem w/ the utf8 egg overriding the string Kon> operators. The problem comes when the source "..." Kon> is actually a "byte-string". Kon> I am uncomfortable with that particular Chicken Kon> idiom. Kon> How about moving the utf8 egg's Kon> "byte-string-srfi-13.scm" & "byte- string.scm" into Kon> the core? Then when a "byte-string" use is intended Kon> everyone will know. That's a good idea, but they don't need to be moved into the core, we can just split them out into a separate egg. Since they are variable definitions the impact to the core is probably slight. But the impact on coding style is what I want. If one means string of byte say so. Placing it in the core also means load order is not an issue. -- Alex Best Wishes, Kon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] URLs for Chicken websites, wiki outage
On Sun, Mar 16, 2008 at 03:24:05PM +0100, Tobia Conforto wrote: > What about choosing one of the new domains and putting all the > services on it? > > Front page: www.chicken-scheme.org > Wiki: wiki.chicken-scheme.org > Trac: trac.chicken-scheme.org > Search box: index.chicken-scheme.org > > The old domains could be configured to do http 301 redirects to the > new place, as would the other new domains. +1, this is nice and clean Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth pgpuNckbGU8bW.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] URLs for Chicken websites, wiki outage
What about choosing one of the new domains and putting all the services on it? Front page: www.chicken-scheme.org Wiki: wiki.chicken-scheme.org Trac: trac.chicken-scheme.org Search box: index.chicken-scheme.org The old domains could be configured to do http 301 redirects to the new place, as would the other new domains. Tobia ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Spiffy relies on removed proc.
On Sun, Mar 16, 2008 at 01:21:13AM -0700, Robin Lee Powell wrote: > > In the latest spiffy.scm is: > > (parameterize ([http:error-response-handler (http-resource:error-handler > exn)]) > > but http-resource:error-handler was removed in 3.5 (3.7 is current). > > The last time it appeared, in 3.4, it looked like this: > > (define (http-resource:error-handler ex) > (lambda (code msg) > (build-error-message ex code msg))) > > Not sure what the right move is here; 3.5 talks about fixing > exception handling, so I don't want to just put it back the way it > was (and I don't have perms to do so anyways). Thanks for the error report! I've fixed the bug and added a testcase for it so it will not happen again. I've also pushed a new release which should be available shortly (3.8). Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth pgpzNMc6hPYC8.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] fixnum problem in http egg is back, magically.
On Sat, Mar 15, 2008 at 07:23:33PM -0700, Robin Lee Powell wrote: > On Sat, Mar 15, 2008 at 07:10:14PM -0700, Robin Lee Powell wrote: > > [SPIFFY: (root) reading /home/rlpowell/svn/sert/test.scm with size > > 222.0#] > > Error: (file-read) bad argument type - not a fixnum: 222.0 > > Error: 500 Internal server error > > *Huh*. > > I've managed to track the problem down. It occurs when spiffy tries > to serve a file whose extension it doesn't know. If it does, it will simply send the file's contents. This is done through sendfile, which looks at the size of the file, which is calculated with file-size. This procedure can return big numbers, for which Felix has made a change. This change requires you to compile chicken twice. Again, this is *not* a bug in Spiffy or in http. Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth pgpxmCs5nkfzj.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Problems with csc and csi under MinGW + MSYS
I believe I know the cause of the error with chicken-setup. It appears that Chicken is unable to find any file in the MinGW filesystem: csi> (file-exists? (make-absolute-pathname "/usr/local/bin" "chicken.exe")) #f $ ls /usr/local/bin/chicken.exe /usr/local/bin/chicken.exe The file exists in /usr/local/bin under the directory where MinGW is installed, but the corresponding system call probably tries to find that file in /usr/local/bin as a top-level directory. So when chicken-setup tries to run csc, it does something like (system "/usr/local/bin/csc" ...) and that fails because csc.exe is not found in that location. The same goes for the case when csc tries to run the chicken compiler. -Ivan Ivan Raikov <[EMAIL PROTECTED]> writes: > 2) The chicken compiler works, but the csc driver program doesn't: > > > $ echo "(print \"Hello, world!\")" > hello.scm > $ chicken hello.scm > compiling `hello.scm' ... > generating `hello.c'... > > $ csc hello.scm > (some garbage characters ...) ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: Problems with csc and csi under MinGW + MSYS
Yes, I can run sh+csi from the Windows shell, just not from rxvt. Is this a known issue with rxvt under MinGW? -Ivan Ivan Shmakov <[EMAIL PROTECTED]> writes: > > 1) After building and installing Chicken development snapshot 3.0.8, > > the csi REPL seems to go into an infinite loop upon startup. csi can > > print its version, evaluate expressions on the command line, and run > > scripts, but it cannot run the REPL. This occurs in the MSYS > > shell. If I run csi under the Windows shell, it works normally as far > > as I can tell. > > I've run into the problems with MSYS shell running within rxvt > too (although with different software.) It seems to be related > to Windows ``console'' I/O. Could you please try the following? > > * run sh.exe from cmd.exe, then try running csi.exe from it; > > * rename MSYSDIRECTORY/bin/rxvt.exe to MSYS/bin/rxvt1.exe, then > try running msys.bat and csi.exe in the appearing window. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Spiffy relies on removed proc.
In the latest spiffy.scm is: (parameterize ([http:error-response-handler (http-resource:error-handler exn)]) but http-resource:error-handler was removed in 3.5 (3.7 is current). The last time it appeared, in 3.4, it looked like this: (define (http-resource:error-handler ex) (lambda (code msg) (build-error-message ex code msg))) Not sure what the right move is here; 3.5 talks about fixing exception handling, so I don't want to just put it back the way it was (and I don't have perms to do so anyways). -Robin -- Lojban Reason #17: http://en.wikipedia.org/wiki/Buffalo_buffalo Proud Supporter of the Singularity Institute - http://singinst.org/ http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ditching syntax-case modules for the utf8 egg
> "Kon" == Kon Lovett <[EMAIL PROTECTED]> writes:
Kon> Is this a "char-string" issue or a "byte-string"
Kon> issue? When the source "...string..." is a string
Kon> of ASCII non-nul char then there should be no
Kon> problem w/ the utf8 egg overriding the string
Kon> operators. The problem comes when the source "..."
Kon> is actually a "byte-string".
There are other places things can go wrong, of course. If
you use STRING-{SEARCH,MATCH}-POSITIONS, in code that's not
utf8-aware, and any of the match positions come after wide
characters in the string, then it will break if some other
egg has loaded utf8.
This just makes me sad. The whole concept of referencing
strings by index is broken.
--
Alex
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ditching syntax-case modules for the utf8 egg
> "Kon" == Kon Lovett <[EMAIL PROTECTED]> writes: Kon> On Mar 15, 2008, at 9:33 AM, Felix Winkelmann wrote: Kon> Is this a "char-string" issue or a "byte-string" Kon> issue? When the source "...string..." is a string Kon> of ASCII non-nul char then there should be no Kon> problem w/ the utf8 egg overriding the string Kon> operators. The problem comes when the source "..." Kon> is actually a "byte-string". Kon> I am uncomfortable with that particular Chicken Kon> idiom. Kon> How about moving the utf8 egg's Kon> "byte-string-srfi-13.scm" & "byte- string.scm" into Kon> the core? Then when a "byte-string" use is intended Kon> everyone will know. That's a good idea, but they don't need to be moved into the core, we can just split them out into a separate egg. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ditching syntax-case modules for the utf8 egg
> "Felix" == Felix Winkelmann <[EMAIL PROTECTED]> writes: Felix> Alex, what happens if I pass string operators as first Felix> class values? These don't get inlined. What Felix> happens now? I actually thought the change you introduced didn't really inline most of the operators but referenced a static table, and that this would occur regardless of whether the procedure was in operator position or not. If that's not the case, what happens is the same thing that happened before when you imported utf8 into the top-level - and there have been no bug reports about that yet. That may have more to do with the fact that the utf8 egg may never have gotten much usage, but if that's the case it's silly to worry about compatibility. Anyway, the places where it can break (treating strings like byte-strings) are easy to detect and fix. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
