GHC version expectations

[mpickering]

Is it expected that you compile the daemon and plugin with the same GHC version?

It seems that the derived binary instances won't work if they are modified between GHC versions.

OTOH, it seems pretty difficult to build the daemon with HEAD because it relies on nix-flakes etc in order to provide the imgui bindings. So you would have to package your version of HEAD with nix before attempting to build the daemon.

Some possible improvements in this area:

• Check that the plugin and daemon are built with the same GHC version
• Abstract away from GHC version somehow in so that you don't need to couple to GHC version each part is built with.

[wavewave]

Yes, that was exactly what I am going to do. Thank you for the question that I can now document my next plan here.
It took a little convoluted path because I decided to narrow down the target users and use cases from the original one, so it may be quite confusing in the current status.

First of all, this program is best for GHC developers and anyone who is very closely working for GHC and the compiler internal detail. So I minimize any dependencies other than what ghc-debug needs and C/C++ libraries and FFI binding. The fficxx-provided FFI bindings only needs template haskell. (note that fficxx generator needs some dependencies, but generated FFI bindings do not need it)

I will also make the version of ghc-specter tightly bound to GHC version as well. The current version is ghc-specter 9.6.x, and next version will be 9.8.x and 9.9.x (where x part can be different from actual GHC releases)

The currently nix shell provides a preinstalled GHC, but I will remove that. Only C/C++ deps and the source code of fficxx bindings. and that shell will be given in a form of overlay (and shell for convenience). As a user using nix, one can just import that overlay with their nix env equipped with a preferred version of GHC. and then this tool (plugin and daemon) will be compiled there in the user's shell.

I am also planning to have some internalized fingerprint from the GHC library version to the plugin and daemon. So if the daemon gets some messages from a plugin with different fingerprint, the daemon will fail with informative message.

This very tight binary-level coupling may give another interesting direction of development. If plugin and daemon are truly binary-compatible, we can have faster communication channel via shared memory or mmap'ed compact region etc, and in the end, I would like to enable ghc-specter to truly inspect the heap space of running GHC.