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

Wed Jun 22 19:05:28 UTC 2011

oops, forgot CCs.

On 22 June 2011 20:07, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> 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.

The code are available for you at VMMaker repository. It is hardly an
excuse that you cannot review it
in such form. Because you are working with MC (i seen that) and i bet
that you know it good enough to compare two snapshots and do the
merge.

Concerning changesets, etc etc.. i pointed to code with new
finalization to you multiple times, in multiple forms (.cs , .mcz )
and reminded dozen times.
Still , as of now, these 2 methods change + 1 additional class var are
still not in main cog branch (by main i consider one which are
released by you).
So, how does these facts correllating with what you stated above?

Also, let me remind you that first two letters in OSCog stands for
open source, which means that this project are open source and no
single person
can own it. It is owned by comminity, by definition. And while i
really like if you (or anybody else) can spend his time reviewing my
code,
it doesn't means that all contributions should come through single
person, since it creates an unnecessary bottleneck in development
process.
And actually current experience shows how it is bad to have such bottlenecks.
So, if you want to own your project, it is fine - keep your own
private copy of Cog somewhere but don't call it public.

> Criticising me in public like this does not
> make me any more eager to find the time.

Ignoring my contributions don't makes me more eagier to do anything as
well. Continuously, i feel like i am at a noise level for you, which
you
constantly ignoring.
Because you often reacting to contributions from others and swiftly
integrating them, but not mine. It looks like i am black listed, or
you have a noise filter..
since nothing i did (which i consider important) are in your VMs.
Maybe i deserve to be at a noise level, and all my work not worth a
single penny. Just say it. Make it clear.
Because ignoring is a worst choice.

>>
>> 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.
>

Not. As i seen in your latest snapshot, an
"  added disabling module loading support " not there
as well as a better finalization scheme i implemented YEAR ago and its
already used in our images.

Just evaluate
WeakFinalizationList hasNewFinalization
in your image under VMs you built.

Now, with such approach, i feel very afraid, how much time it would
take for integrating Ephemerons, which i implemented, and would really
like to be reviewed by you.
If 2 methods change taking almost a year to integrate.. then this
could take 5 years.. or not be integrated at all.

>>
>> 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.
>
> ditto.
>
>>
>> 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?
>

Maybe i missed a discussion, where you stating that?
Btw, i really prefer symbolic names rather than numbers.
Because it is easier to remember, easier to handle and less confusing.
So, on one hand we have an extra primitive with clear name, which
states what it does,
on another hand we having a magic number '41' (btw, why not 42, i like
it more? ;) ), which says NOTHING.

Guess, which side wins?
But of course this single difference is not very significant.
Unless we approach to this systematically (use symbolic names instead
numbers), which i would really prefer to have.

[snip]

--
Best regards,
Igor Stasenko AKA sig.