On Mar 12, 2013, at 7:44 PM, Eliot Miranda <[email protected]> wrote:
> > > 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. my bad... I thought it was hand made, I'm sorry. Good to know that it isn't. > > 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). yes, as I said there is minimal difference between internal and external... just a a matter of taste if you want :) > > 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. yes, I agree that cmake is as incomprehensible as autoconf... a terrible pain when you need to touch them directly... that´s why we try to use the CMakeMaker package, who helps (but not completely) to make the task less painful. > > 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. I do not consider pharo a fork. I think is wrong to think on it like a separated development. We put some effort on top of your own effort to match other requirements (like NB, branding, allow some experiments, etc.), but in essence is the same cog... we just change the cover :) Most of the changes are now based on: NB, the Cocoa branch and some plugins not yet integrated... I hardly would consider that a fork (and we try not to fork in purpose: is dumb to divide the work of the few ppl who work on the vm level in our community). Pharo however has a different vision than other communities in some points, specifically about the plugins and its place: the plugins should be moved to inside the image as much as they can (that's why NB is so important for us). The idea is to allow the community to participate in maintaining the plugins and keep the vm programmers focused on... well, vm stuff :) Esteban > > > 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
