On Tue, Mar 12, 2013 at 12:01 PM, Esteban Lorenzano <esteba...@gmail.com>wrote:
> > On Mar 12, 2013, at 7:44 PM, Eliot Miranda <eliot.mira...@gmail.com> > wrote: > > > > 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. > > > 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). > Yes, I agree. I didn't choose my words carefully enough. It is a version of Cog, just as the one I build is the Croquet version (soon to be a Squeak version). But it would be nice if there was more agreement on the format of Smalltalk getSystemAttribute: 1009. This is a useful attribute and nice if it were parsed by the Pharo image code. 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, "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 > > > -- best, Eliot
