oops, forgot CCs. On 22 June 2011 20:07, Eliot Miranda <eliot.miranda@gmail.com> wrote:

Hi All,

On Tue, Jun 21, 2011 at 12:29 PM, Stéphane Ducasse <stephane.ducasse@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.