Good to hear, but maybe the docs could be improved? Write a ticket with a suggestion for better docs?

@mfikes I’ve still got https://github.com/mfikes/planck/pull/297, but I’ve left it on the floor for some time because of the move to a clean C implementation in planck 2.0. So I guess my question is would something like this be needed in planck 2.0, and/or could it piggie back on the socket-repl implementation which I guess will be in 2.0?

@slipset I think it would be cool as a 2.0-only thing. FWIW, the socket REPL implementation in C in 2.0 turned out to be much simpler than it was in 1.x, owing to UNIX socket code just being more straightforward to write.

@slipset Here is the 2.0 socket REPL implementation: https://github.com/mfikes/planck/commit/e023b2780070f64928d731ff2870dd44342d17f6

The salient bit is around here https://github.com/mfikes/planck/commit/e023b2780070f64928d731ff2870dd44342d17f6#diff-029decfec216e187891473fe22236912R377

I haven’t looked at this very closely, but I do remember from trying to do this in obj-c, that the socket-repl and a socket server is basically the same setup, but a different function handling the processing of data.

Yeah

So in some way, if run_repl was renamed to run_server and accepted an extra parameter

which would be the return of make_repl

something like int run_server(JSContextRef ctx, handler_t * handler)

with this, socket-repl woudl be run_server(ctx, make_repl())

Yeah, that might work out. Hard to tell without trying it to see if things become tangled.

modulo malloc/free

and I guess, the socket thing I was trying to make was to a socket server, not a client.

but then again, my C-code is Rusty 🙂