<blockquote type="cite">Hunh - I didn't remember that at all; I thought Boris Shingarov had been Mr OS/2-Squeak.</blockquote> There were two OS/2 ports that did non-overlapping things because they were designed with orthogonal goals in mind. Juan's port was a "real PresentationManager/2 application", but it was a real PM/2 *Squeak* in that it opened a PM/2 window and BitBlt'd the Squeak Display to that. Opposite to that, the idea of "real PM/2" to me meant "Native Widgets" and I wanted to have that in Squeak. The problem was, in a live system (which is also "truly single-threaded"), how do I debug the "native-widget" event loop when the PM/2 is tied up by the BitBlt UI? This meant that Juan's design wouldn't fit: I needed to somehow have all the Squeak tools but without touching PM/2. This was enabled by two things: (1) compiling the VM with Ian's sqXWindow.c, so Squeak would show on an X display while appearing to OS/2 initially as a headless app talking to the network, and (2) writing an FFI for the VM -- "native-widget" PM/2 calls were made via that FFI. <blockquote type="cite">I wouldn't be surprised if it still works. But this was never part of the official releases.</blockquote> I very much wanted to merge it upstream into Ian's unix port (the diff was very small). The desire seems weird and silly now, but back then I somehow thought it would make a difference, and I remember I was very frustrated that the merge didn't happen. But it *is* part of the 1.23 distribution on files.squeak.org today. <blockquote type="cite"> Later this was the base of his extremely interesting Cheese project. </blockquote> Oh yes -- Cheese. This is what 3 years later led to the work on Eclipse SWT. <blockquote type="cite">I started with dissecting Slang out of the Cuis VMMaker packages and VMMakerJS (SqeakJS) project into a couple of packages which could be used for generating anything besides VM plugins.</blockquote> You don't need Alien plugins to do VMIL18-simulation-style development of the core VM. For that there is now the Smalltalk implementation of RSP, which I recently added to VMMaker. There is a wide choice how to run the native CPU code: various simulators (gem5 or qemu), or on production silicon under GDB, or on some FPGA prototype under OpenOCD, ... well ... really anything that knows how to speak RSP. This will have a number of far-reaching consequences; this margin is too narrow to explain them, but you can watch a number of my presentations on the subject. Where does this stand right now? VMIL-18-simulation of Cog runs fine over RSP. VMMaker depends on a subtle inaccuracy in the Alien's emulation of instruction atomicity. This will cause VMMaker to fail on off-the-shelf production silicon. But when you modify the CPU to behave like Alien, OSTVM runs just fine (I verified on gem5). So it's a matter of very small fix to the Cogit to match what the stock processor is doing, before we have the full freedom to run anywhere we want. The larger problem that stops me from bringing in all the rest of the system (the target-agnostic synthesizer, the binutils-in-Smalltalk, the symbolic execution engine, the superoptimizer, etc), is the lack of a usable mother-Smalltalk. OSTVM is hosted in Squeak. With all my love for Squeak, I still can't use it for this kind of work. There are blocker problems with SUnit (causes erratic behavior of Socket code which works fine outside SUnit), so I can't have tests, I resort to launching everything from doits. I have no PetitParser. I have no JSON. I can't use my FFI-to-Z3 bindings. In the middle of working I randomly get unexpected problems with access to source.squeak.org. And so on. So. Is there an environment where work would not be blocked by such problems? Let's look. <blockquote type="cite">Pharo VM did not only fork the transpiled C code, they also put the Smalltalk VMMaker code in the repository and maintain it there. They do not use the VMMaker Monticello repository if I understand correctly. So in their repository and workflow, it really is a source fork.</blockquote> You must know some magic! something I've been begging the Pharo people for months to tell me the secret where to download that source from. I tried the headless branch, but it doesn't even compile in Pharo. I tried asking on pharo-dev, but I got zero responses since February. So. The million-dollar question again: Is there *any* environment that works well enough to do OST VM work in? <blockquote type="cite"> I started with dissecting Slang out of the Cuis VMMaker packages and VMMakerJS (SqeakJS) project into a couple of packages which could be used for generating anything besides VM plugins. Atleast that's my intentiont, I don't yet know of how that project idea will pan out, atleast I intend to learn something of how Slang works and how it's generated. It's currently highly expiremental, but I got some of the existing VMMaker testscases "green" and so I thought I could share the current state of it. Maybe the whole idea of using it outside the VMMaker is not so a good idea, maybe, maybe not :-) </blockquote> For the reasons I just explained above, I believe it would be more than just "a good idea". It is critical to the viability of this whole stack. If your project works, it give us an environment enabling further collaboration on OSTVM. Well, I must admit I don't know which way is shorter / more straightforward: this, or making Squeak work. I would be happy either way. I don't care which: I have much bigger fish to fry. -- boris <div></div>