Re: [Pharo-project] where to report vm crashes? (while running Moose tests)
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
Eliot builds will always have the old vm warning, even if they are not old :)... you need one of the pharo builds (CogVM, NBCogVM or PharoVM) On Mar 12, 2013, at 10:05 AM, Stephan Eggermont <stephan@stack.nl> wrote:
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
Eliot's VMs on Mac will always give the warning as the version isn't the same kind of string as Esteban's. Some kind of git thing, like: #define REVISION_STRING "git://gitorious.org/cogvm/blessed.git Commit: 63aa6ed8a070fc730224b496e0dda7c3f8482e10 Date: 2013-02-14 11:43:21 +0100 By: Esteban Lorenzano <estebanlm@gmail.com>" 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
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
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. 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
<2013-03-12_10-43-37.png>
Thank you very much. It makes a lot of sense doing things the Pharo way. Now, I have been trying to get the InterpreterSimulator to work in Pharo but there are some things to fix before being able to do so (one is to have an image in 6504 format but hey, this is for me learning) Classes like Utility etc that aren't in the image anymore. I had a chat with Bert yesterday and he actually helped me get the Interpreter starting. t would be nice to have Pharo VMMaker have a working base interpreter (in Smalltalk, running inside the image I mean). Maybe should I look at another class, like CogInterpreter? Phil 2013/3/12 Esteban Lorenzano <estebanlm@gmail.com>:
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.
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
<2013-03-12_10-43-37.png>
On Mar 12, 2013, at 11:02 AM, phil@highoctane.be wrote:
Thank you very much. It makes a lot of sense doing things the Pharo way.
Now, I have been trying to get the InterpreterSimulator to work in Pharo but there are some things to fix before being able to do so (one is to have an image in 6504 format but hey, this is for me learning) Classes like Utility etc that aren't in the image anymore.
I had a chat with Bert yesterday and he actually helped me get the Interpreter starting.
t would be nice to have Pharo VMMaker have a working base interpreter (in Smalltalk, running inside the image I mean).
yes it would be nice. Now have Utilities monster kind of class in our system is not something we like. :)
Maybe should I look at another class, like CogInterpreter?
Phil
2013/3/12 Esteban Lorenzano <estebanlm@gmail.com>:
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.
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
<2013-03-12_10-43-37.png>
The Utilities thing is just used to display a progress dialog inform:during:, so that's easy. Also String asText form for Display can be solved with a blank form. I am now stuck on getting a 6504 image format. Phil 2013/3/12 stephane ducasse <stephane.ducasse@free.fr>:
On Mar 12, 2013, at 11:02 AM, phil@highoctane.be wrote:
Thank you very much. It makes a lot of sense doing things the Pharo way.
Now, I have been trying to get the InterpreterSimulator to work in Pharo but there are some things to fix before being able to do so (one is to have an image in 6504 format but hey, this is for me learning) Classes like Utility etc that aren't in the image anymore.
I had a chat with Bert yesterday and he actually helped me get the Interpreter starting.
t would be nice to have Pharo VMMaker have a working base interpreter (in Smalltalk, running inside the image I mean).
yes it would be nice. Now have Utilities monster kind of class in our system is not something we like. :)
Maybe should I look at another class, like CogInterpreter?
Phil
2013/3/12 Esteban Lorenzano <estebanlm@gmail.com>:
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.
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
<2013-03-12_10-43-37.png>
On 12 March 2013 10:43, phil@highoctane.be <phil@highoctane.be> wrote:
The Utilities thing is just used to display a progress dialog inform:during:, so that's easy. Also String asText form for Display can be solved with a blank form.
I am now stuck on getting a 6504 image format.
What are you getting stuck on? You should just need to run the image with an Interpreter VM (grab an Interpreter VM off http://www.squeakvm.org/unix/ (stable releases) or http://build.squeak.org/job/InterpreterVM/lastSuccessfulBuild/artifact/ (bleeding edge)) and save the image. frank
Phil
2013/3/12 stephane ducasse <stephane.ducasse@free.fr>:
On Mar 12, 2013, at 11:02 AM, phil@highoctane.be wrote:
Thank you very much. It makes a lot of sense doing things the Pharo way.
Now, I have been trying to get the InterpreterSimulator to work in Pharo but there are some things to fix before being able to do so (one is to have an image in 6504 format but hey, this is for me learning) Classes like Utility etc that aren't in the image anymore.
I had a chat with Bert yesterday and he actually helped me get the Interpreter starting.
t would be nice to have Pharo VMMaker have a working base interpreter (in Smalltalk, running inside the image I mean).
yes it would be nice. Now have Utilities monster kind of class in our system is not something we like. :)
Maybe should I look at another class, like CogInterpreter?
Phil
2013/3/12 Esteban Lorenzano <estebanlm@gmail.com>:
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.
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
<2013-03-12_10-43-37.png>
Hi: On 12 Mar 2013, at 11:43, phil@highoctane.be wrote:
The Utilities thing is just used to display a progress dialog inform:during:, so that's easy. Also String asText form for Display can be solved with a blank form.
Some of that has been reported last year, including patches: https://code.google.com/p/cog/issues/detail?id=106 https://code.google.com/p/cog/issues/detail?id=107 https://code.google.com/p/cog/issues/detail?id=108 It got never integrated... Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
I didn't noticed them until now... I will integrate them as soon as possible :) Esteban On Mar 12, 2013, at 12:33 PM, Stefan Marr <smalltalk@stefan-marr.de> wrote:
Hi:
On 12 Mar 2013, at 11:43, phil@highoctane.be wrote:
The Utilities thing is just used to display a progress dialog inform:during:, so that's easy. Also String asText form for Display can be solved with a blank form.
Some of that has been reported last year, including patches:
https://code.google.com/p/cog/issues/detotil?id=106 https://code.google.com/p/cog/issues/detail?id=107 https://code.google.com/p/cog/issues/detail?id=108
It got never integrated...
Best regards Stefan
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
by base Interpreter you mean an InterpreterVM? On Mar 12, 2013, at 11:02 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Thank you very much. It makes a lot of sense doing things the Pharo way.
Now, I have been trying to get the InterpreterSimulator to work in Pharo but there are some things to fix before being able to do so (one is to have an image in 6504 format but hey, this is for me learning) Classes like Utility etc that aren't in the image anymore.
I had a chat with Bert yesterday and he actually helped me get the Interpreter starting.
t would be nice to have Pharo VMMaker have a working base interpreter (in Smalltalk, running inside the image I mean).
Maybe should I look at another class, like CogInterpreter?
Phil
2013/3/12 Esteban Lorenzano <estebanlm@gmail.com>:
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.
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
<2013-03-12_10-43-37.png>
No, I mean: (InterpreterSimulator initializeWithOptions: Dictionary new). (InterpreterSimulator new openOn: Smalltalk imageName) test. working. Of course, this does the trick on its own image, so, I could be happy enough with whichever image can be used there. That's in an image with VMMaker of course. VMMaker-Interpreter and VMMaker-InterpreterSimulation I'd like to dig inside the image format and how all of that works. As I am doing some experiments with Spoon and minimal object memories, this could come handy to improve my understanding (which is currently abysmally low). Phil 2013/3/12 Esteban Lorenzano <estebanlm@gmail.com>:
by base Interpreter you mean an InterpreterVM?
On Mar 12, 2013, at 11:02 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Thank you very much. It makes a lot of sense doing things the Pharo way.
Now, I have been trying to get the InterpreterSimulator to work in Pharo but there are some things to fix before being able to do so (one is to have an image in 6504 format but hey, this is for me learning) Classes like Utility etc that aren't in the image anymore.
I had a chat with Bert yesterday and he actually helped me get the Interpreter starting.
t would be nice to have Pharo VMMaker have a working base interpreter (in Smalltalk, running inside the image I mean).
Maybe should I look at another class, like CogInterpreter?
Phil
2013/3/12 Esteban Lorenzano <estebanlm@gmail.com>:
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.
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
<2013-03-12_10-43-37.png>
Also, it looks like the Pharo VM uses only external plugins? The Squeak VM has a bunch of those plugins, but as internal ones. That's probably most of the difference Phil's asking about. frank On 12 March 2013 09:57, 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.
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
<2013-03-12_10-43-37.png>
not exactly, but yes, some of the plugins that are internal in Eliot's are external for pharo (no real important reason: we decided to put as external as many as possible :) Esteban On Mar 12, 2013, at 11:15 AM, Frank Shearar <frank.shearar@gmail.com> wrote:
Also, it looks like the Pharo VM uses only external plugins? The Squeak VM has a bunch of those plugins, but as internal ones. That's probably most of the difference Phil's asking about.
frank
On 12 March 2013 09:57, 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.
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
<2013-03-12_10-43-37.png>
The iOS VM has another layout even. And the exe is smaller than 600KB. Phil 2013/3/12 Esteban Lorenzano <estebanlm@gmail.com>:
not exactly, but yes, some of the plugins that are internal in Eliot's are external for pharo (no real important reason: we decided to put as external as many as possible :)
Esteban
On Mar 12, 2013, at 11:15 AM, Frank Shearar <frank.shearar@gmail.com> wrote:
Also, it looks like the Pharo VM uses only external plugins? The Squeak VM has a bunch of those plugins, but as internal ones. That's probably most of the difference Phil's asking about.
frank
On 12 March 2013 09:57, 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.
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
<2013-03-12_10-43-37.png>
the layout for iOS apps is very different than for OSX apps... that's why iOS has a different arrangement. - also, apple does not allows dynamic links for iOS, so every included plugin has to be internal. - also, we are not including many of the plugins (those who does not has sense in iOS, or has not been ported yet), that's why it is so small. Esteban On Mar 12, 2013, at 11:27 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
The iOS VM has another layout even. And the exe is smaller than 600KB.
Phil
2013/3/12 Esteban Lorenzano <estebanlm@gmail.com>:
not exactly, but yes, some of the plugins that are internal in Eliot's are external for pharo (no real important reason: we decided to put as external as many as possible :)
Esteban
On Mar 12, 2013, at 11:15 AM, Frank Shearar <frank.shearar@gmail.com> wrote:
Also, it looks like the Pharo VM uses only external plugins? The Squeak VM has a bunch of those plugins, but as internal ones. That's probably most of the difference Phil's asking about.
frank
On 12 March 2013 09:57, 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.
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
<2013-03-12_10-43-37.png>
<2013-03-12_11-24-37.png>
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. 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, "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
<2013-03-12_10-43-37.png>
-- best, Eliot
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.miranda@gmail.com>:
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.
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, "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
<2013-03-12_10-43-37.png>
-- best, Eliot
On 12 March 2013 18:55, phil@highoctane.be <phil@highoctane.be> wrote:
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)
Mm, kinda sorta. In the squeak-ci repo there's a builtasticMac.sh which builds the Interpreter on OSX [1]. But it's not the "proper" OSX VM a la Carbon or Cocoa; it's the Unix Interpreter VM built on a Mac. frank [1] https://github.com/frankshearar/squeak-ci/blob/master/functions.sh#L43
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.miranda@gmail.com>:
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.
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, "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
<2013-03-12_10-43-37.png>
-- best, Eliot
On Mar 12, 2013, at 7:44 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
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
<2013-03-12_10-43-37.png>
-- best, Eliot
On Tue, Mar 12, 2013 at 12:01 PM, Esteban Lorenzano <estebanlm@gmail.com>wrote:
On Mar 12, 2013, at 7:44 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
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).
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, "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
<2013-03-12_10-43-37.png>
-- best, Eliot
-- best, Eliot
On Mar 12, 2013, at 9:43 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
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.
yes, I agree... maybe something like this: Pharo|Squeak|Newspeak MAJ.MIN.BUG:Cog|Stack|Interpreter MAJ.MIN.BUG:EXTRA-FOR-TASTE So, something for pharo would look like: Pharo 2.0.0:NBCog 1.0.0:git://gitorious.org/~estebanlm/cogvm/cog-osx.git Commit: c4036bdcc3ecf22561e40288def79ef39fb91875 Date: 2013-02-28 14:08:38 +0100 By: Esteban Lorenzano <estebanlm@gmail.com> we have a fixed part and a variable part, so everybody can have their own special information at the end... I think this would solve our identification problems... what do you think? Esteban
On 12 March 2013 19:44, Eliot Miranda <eliot.miranda@gmail.com> wrote:
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.
Just let me remind you that (x86 specificity) is completely on image side. The VM side changes are minimal and 100% not platform specific. Making NB image-side implementation platform-unspecific is another story.. but as i said before i see no reason to do it unless there's a version of Cog which runs on some other platform :) There is plans and some work started on getting there, by making a platform-neutral low-level DSL, which can be used for generating native code. -- Best regards, Igor Stasenko.
On Tue, Mar 12, 2013 at 7:54 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 12 March 2013 19:44, Eliot Miranda <eliot.miranda@gmail.com> wrote:
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.
Just let me remind you that (x86 specificity) is completely on image side. The VM side changes are minimal and 100% not platform specific. Making NB image-side implementation platform-unspecific is another story.. but as i said before i see no reason to do it unless there's a version of Cog which runs on some other platform :)
I understand that. I think Squeak should provide a platform-independent FFI at the image level.
There is plans and some work started on getting there, by making a platform-neutral low-level DSL, which can be used for generating native code.
This is called RTL ;)
-- Best regards, Igor Stasenko.
-- best, Eliot
On Mar 13, 2013, at 7:11 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Tue, Mar 12, 2013 at 7:54 PM, Igor Stasenko <siguctua@gmail.com> wrote: On 12 March 2013 19:44, Eliot Miranda <eliot.miranda@gmail.com> wrote:
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.
Just let me remind you that (x86 specificity) is completely on image side. The VM side changes are minimal and 100% not platform specific. Making NB image-side implementation platform-unspecific is another story.. but as i said before i see no reason to do it unless there's a version of Cog which runs on some other platform :)
I understand that. I think Squeak should provide a platform-independent FFI at the image level.
There is plans and some work started on getting there, by making a platform-neutral low-level DSL, which can be used for generating native code.
This is called RTL ;)
I never hear about it... you mean http://en.wikipedia.org/wiki/Register_transfer_language ? If so, looks interesting :) Esteban
-- Best regards, Igor Stasenko.
-- best, Eliot
On Thu, Mar 14, 2013 at 7:20 AM, Esteban Lorenzano <estebanlm@gmail.com>wrote:
On Mar 13, 2013, at 7:11 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Tue, Mar 12, 2013 at 7:54 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 12 March 2013 19:44, Eliot Miranda <eliot.miranda@gmail.com> wrote:
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.
Just let me remind you that (x86 specificity) is completely on image side. The VM side changes are minimal and 100% not platform specific. Making NB image-side implementation platform-unspecific is another story.. but as i said before i see no reason to do it unless there's a version of Cog which runs on some other platform :)
I understand that. I think Squeak should provide a platform-independent FFI at the image level.
There is plans and some work started on getting there, by making a platform-neutral low-level DSL, which can be used for generating native code.
This is called RTL ;)
I never hear about it... you mean http://en.wikipedia.org/wiki/Register_transfer_language ? If so, looks interesting :)
Yes. RTL is essentially an assembler for an abstract machine with readable names for registers. Arguably the Cog back-end assembler is an RTL. It has abstract registers (ReceiverResultReg, ClassReg etc), and abstract operations (e.g. MoveR:R:). To do marshalling you need only define argument registers (floating-point and integer, an empty set on the x86), return registers, the stack pointer, and maybe the frame pointer, plus a basic set of data manipulation instructions. Then either define these as numeric constants so that the JIT interprets sequences of numbers, or strings, so that the JIT uses string matching (the former is of course faster and slimmer). The JIT maps these abstract instructions and register names into concrete machine code and register numbers. Note that the RTL still has platform-specific constructs, e.g. a LinkReg is valid on RISCs but meaningless on x86, and the ABI-to-RTL compiler has all the knowledge about the format of outgoing calls, what kinds of registers are available (address, data, floating-point, etc). But it does not have to do the final assembly step, fixing up branches etc. This is low-level work the JIT already does and needs to do itself because it knows at what addresses code is generated at. P.S. that wikipedia page is rather poor. Another example other than GCC's is Ralph Johnson's and Carl McConnell's "The *RTL* System: A Framework for Code Optimization<http://www.google.com/url?sa=t&rct=j&q=ralph%20johnson%20rtl&source=web&cd=3...> ".
Esteban
-- Best regards, Igor Stasenko.
-- best, Eliot
-- best, Eliot
On 14 March 2013 19:01, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Yes. RTL is essentially an assembler for an abstract machine with readable names for registers. Arguably the Cog back-end assembler is an RTL. It has abstract registers (ReceiverResultReg, ClassReg etc), and abstract operations (e.g. MoveR:R:). To do marshalling you need only define argument registers (floating-point and integer, an empty set on the x86), return registers, the stack pointer, and maybe the frame pointer, plus a basic set of data manipulation instructions. Then either define these as numeric constants so that the JIT interprets sequences of numbers, or strings, so that the JIT uses string matching (the former is of course faster and slimmer). The JIT maps these abstract instructions and register names into concrete machine code and register numbers.
[snip] yes.. this definition fits quite well with what we're working on.. thanks for pointer(s). -- Best regards, Igor Stasenko.
On 12 March 2013 10:49, 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?
There was a discussion about that in dev list, and decision was made. First thing, putting external modules in "Resources" is non-common for Apple apps. Most of them putting extras in same directory where executable is.. because those bundles are platform-specific. As for using dylibs instead of bundles.. if external module is just a single binary file (as in case with plugins), why bundling it? i would understand if it would contain a .h files, and some other resources, then it would make sense. -- Best regards, Igor Stasenko.
participants (8)
-
Eliot Miranda -
Esteban Lorenzano -
Frank Shearar -
Igor Stasenko -
phil＠highoctane.be -
Stefan Marr -
Stephan Eggermont -
stephane ducasse