On 8 June 2017 at 15:07, Ben Coman <[email protected]> wrote: > On Thu, Jun 8, 2017 at 6:15 PM, Luke Gorrie <[email protected]> wrote: > >> Currently I am working towards teaching the Inspector to explore internal >> data structures in a tracing JIT. >> > > I presume this is for LuaJIT that Snabbu uses? >
Short answer is yes. Long answer is that it is for RaptorJIT, which is the fork of LuaJIT where I am moving from diagnostics by introspection (Lua code running inside the VM) to by inspection (external Pharo/Nix tools that deeply understand the VM.) Ongoing hacking here: https://github.com/raptorjit/raptorjit/pull/63 Once it works the question will be whether to migrate Snabb to RaptorJIT or port the functionality back to LuaJIT. That will be impressive. It would be nice if the DWARF stuff can be > separated. I'm sure that could be useful sometime elsewhere. > I am finding it an interesting experience to write an application that is half Pharo (frontend) and half Nix (backend). For each piece of functionality the question is, how much should be done in the frontend vs the backend? For visualizing the JIT I could on the one hand do everything in the frontend with Pharo code to parse DWARF files, etc, or on the other hand I could do everything in the backend with Pharo simply displaying PNG files produced by Nix. Current trade-off is that Nix will produce a JSON summary of the DWARF type information and then Pharo will use that to decode the logged binary data structures via the GT Inspector. and when I say "Nix" I really mean the whole Nix ecosystem that includes basically every program and programming language. So I am able to freely mix shell, awk, perl, python, R, etc, and still keep things under control. That's the hypothesis anyway. Here is a PR showing the current Frankenstein DWARF backend if you're curious: https://github.com/studio/studio/pull/14
