Thanks a lot all to all of you for that valuable information. BTW, there is no pure PharoInterpreterVM available anywhere. And the InterpeterVM Frank mentioned is only available in Unix, not in OSX. (this for learning with the InterpreterSimulator in VMMaker packages)
>From a personal POV, I like the ability to build as in the CMake process and the PharoVM layout better; more logical to me. Getting CMake behave is indeed no small feat. But the fact that the VMMaker simulators don't work with the Pharo image is annoying. Any further clues? Phil 2013/3/12 Eliot Miranda <eliot.mira...@gmail.com>: > > > On Tue, Mar 12, 2013 at 2:57 AM, Esteban Lorenzano <esteba...@gmail.com> > wrote: >> >> We use an automated building method that tries to be exactly the same in >> each platform. We decided not to create bundles but dylibs because bundles >> are mac-specific stuff and .dylibs same (but for mac) as .so and .dll. >> Our process builds the vm, the plugins and the third party libraries as an >> all-in-one. Eliot builds are hand made, and when there is a process (like >> the autotool for unix builds), they are platform-specific. > > > That mine are hand-builkt is a straw man. They're not. I kick off the > builds by hand but everything is scripted and reproducible, and included in > the generated source. I don't (yet) have access to Jenkins for all three > platforms. But the VMs at Cadence are now all built via Jenkins (thanks to > Bob Westergaard). What's different is a fork. > > 1. Cog includes the set of plugins that came from Qwaq/Teleplace plus the > plugin needed to develop the VM (the x86 simulator BochsIA32Plugin). Pharo > uses the set of plugins it has chosen (several of the same plugins are > internal to the Cog VM, e.g. UUIDPlugin is internal in Cog). > > 2. Pharo uses CMake driven from Smalltalk; I'm too lazy to move, so automake > is used (one in a blue moon) on linux, and hand-crafted makefiles on Mac and > Windows (that don't change much). The Pharo way is better (although I find > CMake as incomprehensible and arbitrary as automake), but both Cog and Pharo > have predictable C make systems. > > 3. Pharo has forked the VM to include a) NativeBoost and b) ephemerons and > c) new FileSystem primitives. > a) is cool, but I don't like the x86 specificity. I want a cross-platform > FFI, so I'm not excited enough to include NB in my port. > b) is useful (I fixed the implementation of ephemerons for VisualWorks done > by someone else a while back, and I understand them well), but I don't like > Igor's implementation. IMO the ephemeronness of an object needs to be > reflected in its format field (the 4 bit type field in every object), not > found by indirecting through the class, which is hairy in the current GC and > slow. I've proposed an alternative and Igor is I think in agreement, but we > have to find the time to implement it. > c) I have to find time to port. Its a no-brainer. > >> >> TL;DR: Is easier for us to build all the vm stuff in an unified way :) >> >> Esteban >> >> On Mar 12, 2013, at 10:49 AM, "p...@highoctane.be" <p...@highoctane.be> >> wrote: >> >> > Eliot's CogVM vs PharoVM on Mac application contents. Quite different. >> > >> > And worth some explanations :-) Why is it that way? >> > >> > Phil >> > >> > 2013/3/12 Stephan Eggermont <step...@stack.nl>: >> >>> It would be good to have a parallel job, but the problem is that you >> >>> will >> >>> get a message saying that the VM is too old for the Pharo 2.0 image. >> >> >> >> I started the latest MOOSE image on Eliots latest VM on mac. >> >> It still has the 'old vm' warning. >> >> Adding a monticello repository (directory) doesn't work. >> >> Tests are still running >> >> >> >> Stephan >> >> >> >> >> > <2013-03-12_10-43-37.png> >> >> > > > > -- > best, > Eliot
