RTimothyEdwards
commented
3 years ago Sorry for the slow response. Magic already has code that builds it as an extension of Tcl and another code set that embeds a scheme interpreter (and presumably for Rust you would want do disable both of those). Both of those change the entire command binding from magic's control to an interpreter's control, and then all of magic's commands get reimplemented in the interpreter. Check the difference between TxDispatch and _tcl_dispatch. TxDispatch is definitely a good target for that. For Tcl/Tk, I have a simple routine that registers every command in magic to a single Tcl routine that calls _tcl_dispatch (see tcltk/tclmagic.c), which in turn calls TxTclDispatch() which is a replacement for the original TxDispatch(). by replacing TxDispatch() with TxTclDispatch(), I'm cutting txGetInteractiveCommand() out of that loop.
I did all this a very long time ago, so the details are definitely a bit fuzzy.
Hi,
I'm, developing a collection of Rust EDA tool bindings and would like to add the ability to drive magic programmatically from a a separate Rust/C thread (optionally skipping the GUI rendering, but that I can figure out). After reading the code, I am torn between patching the TxDispatch and txGetInteractiveCommand to check a separate queue that is filled with commands from the driver thread and wrapping the tcl/scheme inputs. Since magic seems to be designed for extension and scripting, I was wondering would be the officially recommended way?
Best regards, Igor