[Vm-dev] Re: [Pharo-project] PharoKernel 13269

Eliot Miranda eliot.miranda at gmail.com
Wed Jun 22 17:07:52 UTC 2011

Hi All,

On Tue, Jun 21, 2011 at 12:29 PM, Stéphane Ducasse <
stephane.ducasse at inria.fr> wrote:

> what we should pay attention (to be verified) is that igor told me that he
> does not understand why
> the latest code of the vm published by eliot does not include some fixes he
> did for 1.2. May be the code was never integrated.
> In addition the latest vm produced by eliot does not include a long list of
> fixes made by igor and mariano.
> Igor asked in the vm mailing-list what will happen to his changes and there
> were no reaction so far.

I feel some ownership of the Cog branch.  It would be nice to have a chance
to review code before it gets in instead of having to merge.  You might
think of sending me changesets for the more complex sets of changes (e.g.
finalization) so that the merge is easier.  Finally, you might understand
that I'm busy at work and for personal reasons have essentially no time at
the weekends to work on Cog.  Criticising me in public like this does not
make me any more eager to find the time.

> So we should pay attention that using the latest vm from eliot may also
> break our system. We should also think about the fact that
> may be we will have to burn igor's time to merge vm fixes when other people
> don't do it.
> I asked igor to continue to work on the windows build because we want to
> run regression tests at the VM level. We should be able to trace
> vm changes and control the impact they have on us and not run after
> different versions and releases. To have a process in a sense.
> Stef
> yeah.. harmonization, it would be good, Eliot if you take a look of
> changes made in
> VMMaker-oscog-MarianoMartinezPeck.66
> and integrate them, so we will use common version.
> They have a common ancestor -
> VMMaker-oscog.54
> Without this all of the following work will be lost:
> Name: VMMaker-oscog-IgorStasenko.54
> Author: IgorStasenko
> Time: 23 March 2011, 5:30:42 pm
> UUID: c98a0b6c-7f68-4af7-9012-85d3dfdf29ae
> Ancestors: VMMaker-oscog-IgorStasenko.53
> - added disabling module loading support
> Name: VMMaker-oscog.dtl.56
> Author: dtl
> Time: 4 April 2011, 10:06:00.292 pm
> UUID: c1d30608-00e8-53b7-209a-34f7a46c1508
> Ancestors: VMMaker-IgorStasenko.55
> Add tests from VMMaker trunk to document various issues and verify
> presence of primitives.
> Name: VMMaker-oscog.dtl.57
> Author: dtl
> Time: 11 April 2011, 10:13:51.668 pm
> UUID: c1d30608-04dd-53b7-209a-34f7a46c1508
> Ancestors: VMMaker-oscog.dtl.56
> Generate C code for #repeat.
> Implementation by Igor Stasenko and Nicolas Cellier.

That's already integrated.

> Name: VMMaker-oscog-dtl.58
> Author: dtl
> Time: 17 April 2011, 10:22:12.174 pm
> UUID: c1d30608-04b3-a5b7-20ca-2bf7a46c1508
> Ancestors: VMMaker-oscog-dtl.57, VMMaker-oscog.dtl.57
> Merge VMMaker-oscog.dtl.57
> Generate C code for #repeat.
> Implementation by Igor Stasenko and Nicolas Cellier.


> Name: VMMaker-oscog-dtl.59
> Author: dtl
> Time: 17 April 2011, 10:32:55.018 pm
> UUID: c1d30608-042d-4bb7-20ca-2bf7a46c1508
> Ancestors: VMMaker-oscog-dtl.58
> Merge VMMaker-oscog.dtl.58, and add #primitiveImageFormatVersion

Since there's a VM parameter I question the need for yet-another-primitive.

> Add primitiveMillisecondClockMask, an optional named primitive used in
> conjunction with primitiveMillisecondClock for duration calculations.
> The image assumes a value for this constant that is assumed to
> correspond to the actual value used in the VM. This primitive permits
> the VM to report the actual value being used.

Already integrated.

> Add primitiveImageFormatVersion, an optional named primitive answering
> the image format number of the current image. This is the value stored
> in the first word of an image file header when the image is saved, and
> possibly modified on image load if the VM adds or removes capabilities
> for the running image. This primitive was added to VMMaker trunk in
> VMMaker-dtl.169. Rationale: supports float word order handing for
> image segments, reference
> http://lists.squeakfoundation.org/pipermail/vm-dev/2011-April/007712.html

Not integrating this.  The VM parameter (41) has been in Cog since the
beginning.  Instead why not merge the VM parameter back into Interpreter?

> Name: VMMaker-oscog-dtl.64
> Author: dtl
> Time: 21 April 2011, 8:24:32.46 pm
> UUID: c1d30608-30ec-50b7-208a-31f7a46c1508
> Ancestors: VMMaker-oscog-dtl.59
> Re-save from VMMaker-oscog-EstebanLorenzano.62 because
> VMMaker-oscog-dtl.61 and VMMaker-oscog-dtl.60 were saved without
> correct ancestry. This version incorporates the changes from
> VMMaker-oscog-EstebanLorenzano.62, VMMaker-oscog-dtl.61, and
> VMMaker-oscog-dtl.60.
> Name: VMMaker-oscog-EstebanLorenzano.62
> -added ClipboardExtendedPlugin as a regular plugin (taken from the
> InterpreterVM branch)
> I don't know if it works right now, but at least it compiles :)
> Name: VMMaker-oscog-dtl.61
> A second batch of updates from VMM trunk, primarily cosmetic but also
> a class comment update and a couple of methods that had not previously
> been pragmatized in oscog.
> Name: VMMaker-oscog-dtl.60
> These changes are methods from the main VMM branch for which
> <#var:#type:> declarations have been formatted with proper spacing. By
> updating these in the oscog branch, all of these methods are identical
> in both branches. All changes are cosmetic (no functional changes to
> the methods).
> Name: VMMaker-oscog-MarianoMartinezPeck.65
> Author: MarianoMartinezPeck
> Time: 23 April 2011, 1:50:19 pm
> UUID: 944f5c54-f2f5-4cc7-b693-b4db9320cff8
> Ancestors: VMMaker-oscog-dtl.64
> blah
> Name: VMMaker-oscog-MarianoMartinezPeck.66
> Author: MarianoMartinezPeck
> Time: 23 April 2011, 2:17:26 pm
> UUID: 97bab5b0-51d6-4deb-8b58-5bcedd4747dc
> Ancestors: VMMaker-oscog-MarianoMartinezPeck.65
> Adapt VMMakerTool so that it doesnt try to register in the menu if
> TheWorldMenu is not present, like the case of Pharo. This change was
> already integrated in the main trunk of VMMaker but since Eliot forked
> VMMaker-oscog before that, it was not there.
> It doesn't affect Squeak
> --
> Best regards,
> Igor Stasenko AKA sig.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110622/1fa0750b/attachment.htm

More information about the Vm-dev mailing list