On Tue, Mar 12, 2013 at 2:57 AM, Esteban Lorenzano <[email protected]>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, "[email protected]" <[email protected]> > 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 <[email protected]>: > >>> 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
