|
|
|
|
|
|
by patrec
2545 days ago
|
|
|
> 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). |
|
|
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.)