Hi Maciek, hi all Maciek Fijalkowski wrote:

I've just checked in my changes to gencli which are essential for genjs to use gencli. It does not brake any more tests (7 failed as was before). I hope I don't get in conflict with your actual edits.

sorry for the very late response; I'm cc:ing to pypy-dev so that others can read. I've read your changes, good work: I think that now the best thing to do is to collect the modules used by both backends in a proper place, e.g. a genoo package or so (better names are welcome :-). Here are some comments on the modules that might be moved to genoo: class_.py, function.py, record.py: they contain both generic code and gencli specific code (such as Class.get_base_class() and and Class._ctor() methods). We could put generic 'Class', 'Function' and 'Record' class in genoo and subclass it in the backends. cts.py: this is CLI specific, but each backend need a similar module: we should at least put the interface specification in genoo, and possibly some shared code. database.py: there are both generic and specific parts, too. We should provide a more flexible way to handle constants, and maybe we can integrate it with the code from gensqueak that implements a sort of priority queue for emitting things in the right order. IMHO each backends should be able to decide whether to emit things in sequential order (as gencli does, should be faster) or in "declaration order" (as gensqueak and genjs2 need). ilgenerator.py: same as cts.py. oopspec.py: same as class_.py, function.py, record.py: some code can be shared, some need to be backend-specific. rte.py: its goal is to automatically compile a DLL every time the source if modified: this could be useful for all backends that need to compile some runtime environment "offline". sdk.py: very cli-specific. metavm.py: the code here is of three types: - generic code that can be used by all backends: the Generator/MicroInstrucion/InstructionList architecture is designed to be as much generic as possible, so it's not a problem to reuse it (note that the Generator interface is not very up-to-date, see Function.py). - some classes are not cli-specific but they have been designed for emitting code on stack-based machines; I guess they are not very useful for genjs2, but they could be useful for a hypotetic genjava, for example. - some code is very cli-specific, such as the _RuntimeNew class. I wrote some ideas on how you can use and extend metavm for your goal, but I decided to move them to a fresh e-mail so we don't mix the two discussions. At last we need a way to tell genoo where to find the code specific to each backend. I've seen that at the moment you decided to separately pass things such as CTS, Function, opcodes etc as arguments to GenCli constructor, but perhaps it would be better to collect them in a sort of 'container' class and pass this all around; something like this: class CliFunction: ... class CliClass: ... class CTS: ... cli_opcodes = { ... } class CliBackend: Function = CliFunction Class = CliClass TypeSystem = CTS opcodes = cli_opcodes ... Better names other than CliBackend are welcome, too :-). What do you think about this design? Valentino, Nikh, Seo and other that are working on high level backends: do you think that such a genoo could be useful for gensqueak and gencl, too? ciao Anto