Hi Esteban,
So my suggestions are a) restore Pharo to using by the primitive correctly in the exactly the same configuration as Squeak b) no one in the Pharo community changes the definition or position of a primitive without consulting a vm person (and Esteban is a vm person as is Clément and arguably Guille). c) we measure the performance of the primitive and the equivalent non-primitive code in StackInterpreter, Cog and Sista configurations (using Spur, the current object representation) for a range of strings and see how much benefit we're getter by from the primitive; maybe we can nuke it. But yes, it is a bad bug to position this primitive in String; it works only for ByteString.
|
On Tue, Apr 4, 2017 at 10:00 AM, Denis Kudriashov <[hidden email]> wrote:
Not yet. We are close. Last week I got angry with Esteban because I thought that the joe was stalled because Pharo didn't want to move to opensmalltalk-vm, but I over reacted. One of the issues preventing the move was indeed this primitive and the fact that someone, without thinking to talk to anyone working with the VM, renamed the primitive, and then someone put it on the wrong class. Esteban and I have spent some hours trying to work around such issues. I wish people would be more considerate. If issues like this can be resolved we are very close to using the opensmalltalk-vm process for stable Pharo VMs. Esteban wants (and has built) a test build that tries to produce sources and generate Vs and runs tests every time VMMaker is committed. On the Squeak side we only try and build VMs when opensmalltalk-vm is committed in git. I don't want to stand in Esteban's way. I *do* want stable VMs to be built from the opensmalltalk-vm tree. _,,,^..^,,,_ best, Eliot |
2017-04-04 20:03 GMT+02:00 Eliot Miranda <[hidden email]>:
+1 The faster we get the feedback the better. So the Pharo VM has to be built on opensmalltalk-vm If Pharo people wants to have a fork for mastering their release cycle, (the officially released VM) that's understandable. If Pharo people wants to have a better automation with VMMaker code generation (maybe in a dev branch) and non regression tests that's all good. It's just that we should integrate back any improvment and fix ASAP. It would be even better to commit those fix in opensmalltalk-vm directly (feature branch and/or pull request) BTW, don't forget Ronie as a referent Pharo VM developer :) |
|
2017-04-04 22:32 GMT+02:00 Eliot Miranda <[hidden email]>:
And I certainly mispelled, it must be Ronnie |
In reply to this post by Nicolas Cellier
we all agree with that. thing is: - we still want to have a CI process running which covers all the stages of VM development: source generation, compilation, test. - we have a different packaging policy (basically we push to different places). now, I do not see why that cannot coexist with opensmalltalk-vm, after all the work made this year (and believe me, it was A LOT of work). Esteban |
In reply to this post by Eliot Miranda-2
(If we were using one set of sources this issue would be moot).
|
Free forum by Nabble | Edit this page |