Is this thing a threadless repl server? if so, i suggest that the code be separated and can be easily integrated into other project.
the guile-scsh badly needs such a feature. On Sat, Oct 5, 2013 at 8:56 AM, David Thompson <dthomps...@worcester.edu> wrote: > Hello all, > > As some of you know, I am writing my own custom REPL that fits nicely > with my game framework, guile-2d. I just finished hacking (system repl > server) to suit my needs and things seem to be working well. > > Looking upon the diff, I see that I only changed the serve-client > procedure. Thus, I think it would be a good idea to build some > abstraction that allows custom REPLs to be run, not just start-repl in > (system repl repl). > > Here is the original serve-client method: > > (define (serve-client client addr) > (with-continuation-barrier > (lambda () > (with-input-from-port client > (lambda () > (with-output-to-port client > (lambda () > (with-error-to-port client > (lambda () > (with-fluids ((*repl-stack* '())) > (start-repl)))))))))) > (close-socket! client)) > > And here is my version: > > (define (serve-client client addr) > (agenda-schedule > (colambda () > (with-input-from-port client > (lambda () > (with-output-to-port client > (lambda () > (with-error-to-port client > (lambda () > (with-fluids ((*repl-stack* '())) > (start-repl)))))))) > (close-socket! client)))) > > In this snippet, start-repl comes from a guile-2d module, not (system > repl repl). > > There's an abstraction lurking here, but I'm not quite sure what it is. > I've removed the continuation barrier, changed the start-repl procedure, > and wrapped everything in a form that creates a coroutine. I tried > simply adding an additional argument to spawn-server that specifies the > procedure used to serve the client. However, close-socket! is private, > and I don't think it would be a good idea to expose it. > > Can anyone think of a good way to generalize this? > > Thanks, > > - Dave >
