On 12 Mar 2013, at 12:15, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-03-12, at 10:17, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Camillo,
On 12 Mar 2013, at 09:39, Camillo Bruni <camillobruni@gmail.com> wrote:
from that point of view, it is just a warning. Unless you do some fancy new FileSystem stuff it will continue to work with 2.0 and for a while with 3.0.
Is it not possible to clarify *exactly* what is missing and will not work well.
Right now this is like a mystery.
We are all developers and capable of understanding a technical explanation ;-)
Which primitives are we talking about, how are they used and what end user effect do they have ?
I know that NativeBoost is an important difference. The question is, will the image start without proper NB support and will something be broken if NB is non-functional (apart from NB code itself, I mean high level normal stuff) ?
Thanks for the answers, Camillo. First off: I am absolutely for a Pharo vm - we need to take maximal control over this crucial element. Incredible progress has been made the last year, year and a half, and that is fantastic and has to continue. The bin directory is cleaner and all the scripting is much better.
Well so far there is only some FileSystem primitives, and besides the tests nobody ever relied on getting the permissions or checks if a file is an symlink. But we can do that now.
But you still did not answer exactly which primitives, which methods. I think this is important knowledge that has to be public and documented.
NativeBoost is shipped with 2.0 but not yet used in the Kernel, but this is going to change in 3.0 where we hope to rewrite the UI driver talking to Cairo using an NativeBoost-FFI binding.
The thing is, I don't want to care and define which external VMs work with which Pharo version. (Still, yes you can run Pharo 20 on CogVM, we just don't like it :P )
I agree that we should maximally use the same Pharo VM to get the best possible testing exposure and to improve the quality. But it is very important to be able to diagnose strange VM crashes by using different VM's. The JIT code is still under active development and we need Eliot in the loop. He needs the option that the large Pharo community uses/tests his work, we need his help. Maybe given a clear description of the primitives situation will result in enough users asking for them to be included in the standard Cog VM as well.
Pharo ships and runs only with the Pharo and the PharoS VM. Currently the situation is not perfect with our VMs being unstable
I was doing some more builds today with the headless Pharo VM on Linux and these went fine. I like the config handler more and more ! Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill