Looks like Lisp's back on the menu boys
Guile is absolutely amazing these days: it has a JIT for speed, superb POSIX support, plus you can dynamic-link in any functionality you need from a C library.
11–20 of 24 posts
Looks like Lisp's back on the menu boys
Guile is absolutely amazing these days: it has a JIT for speed, superb POSIX support, plus you can dynamic-link in any functionality you need from a C library.
Realistically, how much data is it practical to stash inside these continuations? It seems like it could get out of hand quite quickly for non-toy examples. If you were propagating e.g. game state, you'd still want to stick that in a db, so the continuation would just be a session id?
Game state has to be propagated from the server to the client so the player knows what is happening where-as continuations as used in this article are more about avoiding this propagation (the hidden field in the example is replaced by dispatch-table tag which acts as a session id / location in the dispatch-table for finding the continuation function)
Realistically, how much data is it practical to stash inside these continuations? It seems like it could get out of hand quite quickly for non-toy examples. If you were propagating e.g. game state, you'd still want to stick that in a db, so the continuation would just be a session id?
A continuation is a function that, when called, jumps back to a specific part of the program that was frozen (meaning current memory, the call stack, the line number). So it can't really be stored. If your game state was stored in a db, you'd still have to load it memory to perform operations on it. Those operations, if using continuations, would then stick around in memory while waiting the continuation to be resume…
If you google ‘serializable continuations’ you’ll find a reasonable amount of prior art (e.g. http://wiki.call-cc.org/eggref/5/s11n). I think there has never been a good solution to versioning then against changes to the code.
Realistically, how much data is it practical to stash inside these continuations? It seems like it could get out of hand quite quickly for non-toy examples. If you were propagating e.g. game state, you'd still want to stick that in a db, so the continuation would just be a session id?
A continuation is a function that, when called, jumps back to a specific part of the program that was frozen (meaning current memory, the call stack, the line number). So it can't really be stored. If your game state was stored in a db, you'd still have to load it memory to perform operations on it. Those operations, if using continuations, would then stick around in memory while waiting the continuation to be resume…
Persisting a continuation seems like it's similarly as challenging as persisting an arbitrary closure. Like usual there are things you can't really persist, for example in your call stack you might have some unwind handlers for closing files -- how do you persist file handles?
Instead of that `xml` library and format, many people use the SXML format defined by Oleg Kiselyov: https://docs.racket-lang.org/sxml-intro/ SXML became the de facto standard in the Scheme community after Oleg and others developed some powerful libraries for it, starting with Oleg's SSAX parser. SXML is also better-suited to efficient manipulation of large HTML/XML when using immutable lists. Also, if you're looking…
To your point though - sxml is fantastic.
Instead of that `xml` library and format, many people use the SXML format defined by Oleg Kiselyov: https://docs.racket-lang.org/sxml-intro/ SXML became the de facto standard in the Scheme community after Oleg and others developed some powerful libraries for it, starting with Oleg's SSAX parser. SXML is also better-suited to efficient manipulation of large HTML/XML when using immutable lists. Also, if you're looking…
I had an xml problem to solve at work, and used sxml to prototype solutions in CL and Guile. The CL solution was much (much) faster, but I ended up using Guile because the libraries are built in. Maybe I should try a Racket version. To your point though - sxml is fantastic.
But Scheme code can often be made faster, especially if you know the performance characteristics of the particular implementation.
Besides generally using good performance practices, know that Racket has some profilers that can be immensely helpful. (I once rigged up Racket's statistical profiler at the time to capture the data for each instance of certain kinds of very complicated Web requests in a production system, and used the reports to optimize the heck out of it.)
Earlier quoted context omitted.
I'm using the Racket webserver, but each page is it own rkt file. I'm using no continuations, just storing and reading everything in the hard disk. (I'm not sure it's optimal, but I prefer that approach.)
Interesting. Do you have a viewable page example?
I have a shared module for the common parts of the webpage (like footer or header), parameters for the info of the user (like name or email), some macros like for/user to iterate through the whole list of users updating the parameters, and a macro to hide all the boilerplate at the top (it probably should be a #lang, but a macro is easier to write).
Instead of that `xml` library and format, many people use the SXML format defined by Oleg Kiselyov: https://docs.racket-lang.org/sxml-intro/ SXML became the de facto standard in the Scheme community after Oleg and others developed some powerful libraries for it, starting with Oleg's SSAX parser. SXML is also better-suited to efficient manipulation of large HTML/XML when using immutable lists. Also, if you're looking…
I had an xml problem to solve at work, and used sxml to prototype solutions in CL and Guile. The CL solution was much (much) faster, but I ended up using Guile because the libraries are built in. Maybe I should try a Racket version. To your point though - sxml is fantastic.
Earlier quoted context omitted.
I had an xml problem to solve at work, and used sxml to prototype solutions in CL and Guile. The CL solution was much (much) faster, but I ended up using Guile because the libraries are built in. Maybe I should try a Racket version. To your point though - sxml is fantastic.
It's hard to beat a skilled CL person who invests in making something fast. But Scheme code can often be made faster, especially if you know the performance characteristics of the particular implementation. Besides generally using good performance practices, know that Racket has some profilers that can be immensely helpful. (I once rigged up Racket's statistical profiler at the time to capture the data for each insta…
I meant to say "But a given piece of Scheme code can often be made faster than it was before".
Instead of that `xml` library and format, many people use the SXML format defined by Oleg Kiselyov: https://docs.racket-lang.org/sxml-intro/ SXML became the de facto standard in the Scheme community after Oleg and others developed some powerful libraries for it, starting with Oleg's SSAX parser. SXML is also better-suited to efficient manipulation of large HTML/XML when using immutable lists. Also, if you're looking…
Is there a good guide to this kind of stuff as someone new to Scheme? Like a community intro, showing what the core packages are etc.?