[lukego]

That's a fair point.

I'm viewing the tooling as a separate project. RaptorJIT is one application that it supports and Pharo is one UI.

Codegen is appealing for being able to use the same data for more things e.g. also generate gdb/rr extensions for debugging the RaptorJIT VM, or generate Lua code for a simple console-based analysis tool, etc. There are already other people writing LuaJIT tooling in Python and Javascript and ... so I want to keep an open mind about target environments for the sake of potential collaboration.

(You could also think of codegen as a bridging strategy in case the tooling should be ported to some more conventional environment(s) once it is mature e.g. CLI, web, emacs, etc.)

EDIT: Should also note that the Studio tooling can be run via Docker in pure text mode, converting the binary diagnostic data into ascii that's similar to but richer than the classic LuaJIT '-jdump'. So users don't need to use the GUI, or setup any of the dependencies, or even learn different ways of working.

[patrec]

> I'm viewing the tooling as a separate project

If the quality (and acceptance) of the tooling is pretty important to the success of RaptorJIT and the tooling is unlikely to be used for anything else than RaptorJIT (e.g. pypy or at least another luajit fork), they are not really _that_ separate.

I don't think codegen is in itself bad, but R -> Pharo so you can work on some low level lua JIT stuff – you're mightily reducing the set of people who don't need to learn extra tech to be able to contribute (from an already small pool of people who have the relevant skills and inclination to improve a JIT compiler).

[lukego]

> the tooling is unlikely to be used for anything else than RaptorJIT

Here we are talking at cross-purposes. I view the tooling as an extensible framework like Emacs or Eclipse. I am talking about my intentions for extending the diagnostic tooling to support other projects beyond RaptorJIT.

Over time I would anticipate reducing the number of moving parts in the RaptorJIT tooling.

The value of a "there's more than one way to do it" approach is to make it easier to support new projects besides RaptorJIT using whatever tools that project's community are comfortable with (which, as you say, probably won't be Pharo but might be R/python/perl/emacs/etc.)