"Thompson, David" <dthomps...@worcester.edu> skribis: > Now, I think this solves the immediate need of being able to live hack > dmd, but I'd like to note an additional shortcoming: Thread > synchronization isssues. As you know, there's potential for the main > dmd thread and a REPL thread to write to the same memory and blow > things up. In practice, this would be unlikely, but it shouldn't even > be a possibility. To accommodate programs that run in an event loop > (though I know dmd doesn't truly have this yet), Mark and I developed > the (system repl coop-server) module available in Guile 2.0.11. This > "cooperative" REPL server can be integrated into an event loop and > guarantee that expressions are only evaluated in the context of a > single thread, in this case the main thread. I think that this should > be the approach taken in the not-so-long term, which will require > modifying dmd itself.
I agree that the cooperative REPL server is the way to go. I just couldn’t resist the temptation to hack that thing. ;-) It would be ideal if instead of having built-in support for the REPL server, dmd instead provided a way for services to return file descriptors to monitor and if they could be notified of I/O events on those file descriptors. That way, the REPL server could be a normal REPL service. > Now that we can live hack dmd, we'll need some things to help make it > pleasant. Most of the time I am tweaking service definitions until > they are just right. Currently, that means calling a procedure to > unload the version that exists, and then registering a new one. I'd > like to reduce that to a single step to tighten the feedback loop. > What do you think about adding a 'register-services*' procedure, or > maybe a 'define-service' form, that first unregisters the old service > before registering the new one? Sounds good to me. Thanks, Ludo’.
