On Tue, Mar 12, 2013 at 2:57 AM, Esteban Lorenzano
<estebanlm@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).
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, "
phil@highoctane.be" <
phil@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 <
stephan@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
>>
>>
--
best,Eliot