Re: The Web, Continuations, and All That
Tobias Gerdin writes: > As long as you have some way to redirect the client back to the same > application server things would scale quite well I think. You could > embed some token identifying the application server in the URL which > the reverse proxy could use to forward the request to the same > application server instance. New user sessions would still be > load-balanced using a round-robin scheme or something more > sophisticated. > > Something even cooler would be to have serializable continuations like > in Racket (but it requires limiting the language somewhat), in which > case you could store the continuations in the URL (if they are not too > big), or perhaps in some distributed hashtable that all application > server instances could access. A whole bunch of ideas were discussed on IRC a while back[1], and serialisation was one of the issues I was most concerned about. As it stands, when the program stops you lose all your existing continuations, which may be undesirable. Another important issue was brought up by Antono, which is that continuation URLs effectively form a gc root, and you can't safely get rid of continuations without possibly breaking some url. And even though it you can just say "well, tough", you at least need some strategy for periodically pruning your set of continuations. I'd like to see you, or I, or someone, do something like this for guile, but I think the first step is to look at existing continuation based frameworks and see how they handle some of these issues. 1. http://rotty.yi.org/irclogs/freenode/%23guile/2012-01-10/ -- Ian Price "Programming is like pinball. The reward for doing it well is the opportunity to do it again" - from "The Wizardy Compiled"
Re: GNU Guile 2.0.5 released
l...@gnu.org (Ludovic Courtès) writes: > We are pleased to announce GNU Guile release 2.0.5. This release fixes > the binary interface information (SONAME) of libguile, which was > incorrect in 2.0.4. It does not contain other changes. > > Please be sure to upgrade to 2.0.5 if you already installed 2.0.4. > We apologize for the inconvenience. Mozilla, eat your heart out. :) -- Ian Price "Programming is like pinball. The reward for doing it well is the opportunity to do it again" - from "The Wizardy Compiled"
Re: The Web, Continuations, and All That
Hi Tobias, On Mon 30 Jan 2012 20:17, Tobias Gerdin writes: > 2012/1/23 Andy Wingo : >> Did you ever run into problems with non-resumable continuations? > > At times I was scratching my head and wondering what was going on but > if you mean continuations that wouldn't resume due to a bug I do not > think so. If a partial continuation includes a trip through C and then back to the VM, it won't be resumable. Basically if you call a function that is implemented in C and then that function does a scm_call(...), and you abort from within the scm_call(...), the abort works but the continuation will not be resumable. This is an implementation restriction. We're trying to get around it by having more things implemented in Scheme rather than C. The reason for this restriction is that you can't capture part of the C stack, then compose it with some other C continuation (i.e., splat it at some other stack position). E.g.: scheme@(guile-user)> (call-with-prompt 'foo (lambda () (call-with-output-string (lambda args (abort-to-prompt 'foo (lambda (k) k)) $1 = # scheme@(guile-user)> ($1) ERROR: In procedure #: ERROR: Throw to key `vm-error' with args `(vm-run "Unrewindable partial continuation" (#))'. Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. scheme@(guile-user) [1]> I asked you this because I was wondering I wanted to know how we were doing in practice: if you happened to run into this. So it's nice that you didn't run into it :) > What I think would be nice would be to add a (web server control) > library making the most common web programming continuation operators > available for use in any framework built on top of (web server). This > would probably require installing a prompt in `run-server' somewhere, > (but that is not too expensive I think in the case it's never used?) > and having some policy on how the continuation table is to be managed. > One simple way would be to make use of a weak hashtable, although that > may not be ideal in all situations. There is a prompt in the server. The handler is applied to the request, body, and state values in a thunk, and that thunk is called in one of these: (define (with-stack-and-prompt thunk) (call-with-prompt (default-prompt-tag) (lambda () (start-stack #t (thunk))) (lambda (k proc) (with-stack-and-prompt (lambda () (proc k)) Andy -- http://wingolog.org/
Re: guile-2.0.pc misses a few dependency libraries
> From: l...@gnu.org (Ludovic Courtès)
> Date: Mon, 30 Jan 2012 00:19:40 +0100
>
> > I finally traced that to the contents of guile-2.0.pc file:
> >
> > Libs: -L${libdir} -lguile-2.0 -Ld:/usr/lib -lgc
> > Libs.private: d:/usr/lib/libgmp.dll.a -Ld:/usr/lib
> > d:/usr/lib/libltdl.dll.a -Ld:/usr/lib -lffi-lregex -lcrypt -lws2_32 -lm
> >
> > However, libguile-2.0.la shows more dependency libraries:
> >
> > dependency_libs=' -lgc -lffi -lunistring -liconv -lregex -lintl -liconv
> > -lgmp -ltdl -lregex -lintl -lwsock32 -lole32 -luuid -lmsvcp60 -lcrypt
> > -lws2_32'
> >
> > As you see, quite a few libraries are missing from guile-2.0.pc, and
> > also a several libraries need to appear more than once in the link
> > command line.
>
> Commit 58f86505d658359508732c8f187bc37d010074d0 (see below) should solve
> most of that, but not all
It solves all of them, thanks.
> I don’t know where -lole32, and -lregex come from, for example.
"-lregex" is needed by regex-posix.c (naturally ;-), since the default
Windows libraries do not include regcomp, regexec, etc. There's a
test in configure that first check the standard library link, then
"-lregex" and "-lrx".
However, @GUILE_LIBS@ already gets edited to include -lregex, so
there's no problems here.
"-lole32" (and a few others) come from libregex.la. However, the
standard link command for the program I'm building (GNU Make, btw)
already includes these libraries even without Guile, so using your
modified guile-2.0.pc.in, I was able to link the program successfully
with no unresolved externals.
Btw, shouldn't guile-2.0-uninstalled.pc.in get the same changes?
Thanks!
Re: guile-2.0.pc misses a few dependency libraries
Hi Eli,
Eli Zaretskii skribis:
>> From: l...@gnu.org (Ludovic Courtès)
>> Date: Mon, 30 Jan 2012 00:19:40 +0100
>>
>> > I finally traced that to the contents of guile-2.0.pc file:
>> >
>> > Libs: -L${libdir} -lguile-2.0 -Ld:/usr/lib -lgc
>> > Libs.private: d:/usr/lib/libgmp.dll.a -Ld:/usr/lib
>> > d:/usr/lib/libltdl.dll.a -Ld:/usr/lib -lffi-lregex -lcrypt -lws2_32
>> > -lm
>> >
>> > However, libguile-2.0.la shows more dependency libraries:
>> >
>> > dependency_libs=' -lgc -lffi -lunistring -liconv -lregex -lintl -liconv
>> > -lgmp -ltdl -lregex -lintl -lwsock32 -lole32 -luuid -lmsvcp60 -lcrypt
>> > -lws2_32'
>> >
>> > As you see, quite a few libraries are missing from guile-2.0.pc, and
>> > also a several libraries need to appear more than once in the link
>> > command line.
>>
>> Commit 58f86505d658359508732c8f187bc37d010074d0 (see below) should solve
>> most of that, but not all
>
> It solves all of them, thanks.
Even better than expected. :-)
>> I don’t know where -lole32, and -lregex come from, for example.
>
> "-lregex" is needed by regex-posix.c (naturally ;-), since the default
> Windows libraries do not include regcomp, regexec, etc. There's a
> test in configure that first check the standard library link, then
> "-lregex" and "-lrx".
>
> However, @GUILE_LIBS@ already gets edited to include -lregex, so
> there's no problems here.
>
> "-lole32" (and a few others) come from libregex.la. However, the
> standard link command for the program I'm building (GNU Make, btw)
> already includes these libraries even without Guile, so using your
> modified guile-2.0.pc.in, I was able to link the program successfully
> with no unresolved externals.
Great!
> Btw, shouldn't guile-2.0-uninstalled.pc.in get the same changes?
Yes, you’re right. Fixed in 7e9a301b7f3bcc811803305250b22d71a8b06155.
Thanks,
Ludo’.
Re: Guile support in GNU make
On Tue, 2012-01-31 at 23:17 +0400, Kirill Smelkov wrote: > from Debian testing, and I don't see the problem for test from the > make.info example - it works ok: > > define GUILEIO > (define (mkclose) > (close-port MKPORT) > #f) > > #f > endef > > Is it that (define ...) or maybe I've misunderstood something? It's because of the final "#f" in the define GUILEIO. That means that the final result of passing that content to Guile is #f, rather than the result of evaluating the final (define ...). If you remove that trailing "#f", or use one of the other examples we've bandied about, you'll see the same behavior (with the older version, before I fixed it). Cheers!
guilers @ fosdem
Hey Guile hackers! Anyone going to be at FOSDEM this weekend in Brussels? Ludovic and I will be there, and we'd love to meet up. Unfortunately there were some miscommunications this year and there is no GNU room, but oh well: we'll just have to meet in a bar ;-) Reply if you'll be there, and we'll figure out some meeting! Andy -- http://wingolog.org/
Re: Guile support in GNU make
Paul, On Sun, Jan 29, 2012 at 03:05:54PM -0500, Paul Smith wrote: > On Mon, 2012-01-23 at 07:08 +0100, Thien-Thi Nguyen wrote: > > Best is ‘string-every’ w/ ‘char-set:printing’ directly. > > I implemented this change. Seemed to work in both Guile 1.8 and 2.0.3. Thanks for fixing this. > However, please see my recent email to the guile-user list: I'm getting > error output from GNU make compiled with Guile 2.0.3 every time I use > (define ...), even completely unrelated to this. The same code works > fine in Guile 1.8. > > Did anyone else see these with GNU make / Guile 2.0.3? Maybe I just > built or installed my version of 2.0.3 incorrectly somehow (I'm using > the 1.8 that was provided with my GNU/Linux distribution). My Guile is kirr@mini:~$ guile --version guile (GNU Guile) 2.0.3-deb+1-2 from Debian testing, and I don't see the problem for test from the make.info example - it works ok: define GUILEIO ;; A simple Guile IO library for GNU make (define MKPORT #f) (define (mkopen name mode) (set! MKPORT (open-file name mode)) #f) (define (mkwrite s) (display s MKPORT) (newline MKPORT) #f) (define (mkclose) (close-port MKPORT) #f) #f endef # Internalize the Guile IO functions $(guile $(GUILEIO)) # now test the thing $(guile (mkopen "tmp.out" "w")) $(guile (mkwrite "Hello")) $(guile (mkclose)) $(stop 1) Is it that (define ...) or maybe I've misunderstood something? Thanks again, Kirill
