Hi All,<br><br><div class="gmail_quote">On Tue, Jun 21, 2011 at 12:29 PM, St�phane Ducasse <span dir="ltr">&lt;<a href="mailto:stephane.ducasse@inria.fr">stephane.ducasse@inria.fr</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
what we should pay attention (to be verified) is that igor told me that he does not understand why<br>
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.<br>
In addition the latest vm produced by eliot does not include a long list of fixes made by igor and mariano.<br>
Igor asked in the vm mailing-list what will happen to his changes and there were no reaction so far.<br></blockquote><div><br></div><div>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&#39;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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
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<br>
may be we will have to burn igor&#39;s time to merge vm fixes when other people don&#39;t do it.<br>
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<br>
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.<br>
<br>
Stef<br>
<br>
yeah.. harmonization, it would be good, Eliot if you take a look of<br>
changes made in<br>
VMMaker-oscog-MarianoMartinezPeck.66<br>
and integrate them, so we will use common version.<br>
<br>
They have a common ancestor -<br>
VMMaker-oscog.54<br>
<br>
Without this all of the following work will be lost:<br>
<br>
Name: VMMaker-oscog-IgorStasenko.54<br>
Author: IgorStasenko<br>
Time: 23 March 2011, 5:30:42 pm<br>
UUID: c98a0b6c-7f68-4af7-9012-85d3dfdf29ae<br>
Ancestors: VMMaker-oscog-IgorStasenko.53<br>
<br>
- added disabling module loading support<br>
<br>
<br>
Name: VMMaker-oscog.dtl.56<br>
Author: dtl<br>
Time: 4 April 2011, 10:06:00.292 pm<br>
UUID: c1d30608-00e8-53b7-209a-34f7a46c1508<br>
Ancestors: VMMaker-IgorStasenko.55<br>
<br>
Add tests from VMMaker trunk to document various issues and verify<br>
presence of primitives.<br>
<br>
Name: VMMaker-oscog.dtl.57<br>
Author: dtl<br>
Time: 11 April 2011, 10:13:51.668 pm<br>
UUID: c1d30608-04dd-53b7-209a-34f7a46c1508<br>
Ancestors: VMMaker-oscog.dtl.56<br>
<br>
Generate C code for #repeat.<br>
Implementation by Igor Stasenko and Nicolas Cellier.<br></blockquote><div><br></div><div>That&#39;s already integrated.</div><div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
Name: VMMaker-oscog-dtl.58<br>
Author: dtl<br>
Time: 17 April 2011, 10:22:12.174 pm<br>
UUID: c1d30608-04b3-a5b7-20ca-2bf7a46c1508<br>
Ancestors: VMMaker-oscog-dtl.57, VMMaker-oscog.dtl.57<br>
<br>
Merge VMMaker-oscog.dtl.57<br>
<br>
Generate C code for #repeat.<br>
Implementation by Igor Stasenko and Nicolas Cellier.<br></blockquote><div><br></div><div>ditto.</div><div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Name: VMMaker-oscog-dtl.59<br>
Author: dtl<br>
Time: 17 April 2011, 10:32:55.018 pm<br>
UUID: c1d30608-042d-4bb7-20ca-2bf7a46c1508<br>
Ancestors: VMMaker-oscog-dtl.58<br>
<br>
Merge VMMaker-oscog.dtl.58, and add #primitiveImageFormatVersion<br></blockquote><div><br></div><div>Since there&#39;s a VM parameter I question the need for yet-another-primitive.</div><div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
Add primitiveMillisecondClockMask, an optional named primitive used in<br>
conjunction with primitiveMillisecondClock for duration calculations.<br>
The image assumes a value for this constant that is assumed to<br>
correspond to the actual value used in the VM. This primitive permits<br>
the VM to report the actual value being used.<br></blockquote><div><br></div><div>Already integrated.</div><div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
Add primitiveImageFormatVersion, an optional named primitive answering<br>
the image format number of the current image. This is the value stored<br>
in the first word of an image file header when the image is saved, and<br>
possibly modified on image load if the VM adds or removes capabilities<br>
for the running image. This primitive was added to VMMaker trunk in<br>
VMMaker-dtl.169. Rationale: supports float word order handing for<br>
image segments, reference<br>
<a href="http://lists.squeakfoundation.org/pipermail/vm-dev/2011-April/007712.html" target="_blank">http://lists.squeakfoundation.org/pipermail/vm-dev/2011-April/007712.html</a></blockquote><div><br></div><div>Not integrating this. �The VM parameter (41) has been in Cog since the beginning. �Instead why not merge the VM parameter back into Interpreter?</div>
<div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<br>
Name: VMMaker-oscog-dtl.64<br>
Author: dtl<br>
Time: 21 April 2011, 8:24:32.46 pm<br>
UUID: c1d30608-30ec-50b7-208a-31f7a46c1508<br>
Ancestors: VMMaker-oscog-dtl.59<br>
<br>
Re-save from VMMaker-oscog-EstebanLorenzano.62 because<br>
VMMaker-oscog-dtl.61 and VMMaker-oscog-dtl.60 were saved without<br>
correct ancestry. This version incorporates the changes from<br>
VMMaker-oscog-EstebanLorenzano.62, VMMaker-oscog-dtl.61, and<br>
VMMaker-oscog-dtl.60.<br>
<br>
Name: VMMaker-oscog-EstebanLorenzano.62<br>
-added ClipboardExtendedPlugin as a regular plugin (taken from the<br>
InterpreterVM branch)<br>
I don&#39;t know if it works right now, but at least it compiles :)<br>
<br>
Name: VMMaker-oscog-dtl.61<br>
A second batch of updates from VMM trunk, primarily cosmetic but also<br>
a class comment update and a couple of methods that had not previously<br>
been pragmatized in oscog.<br>
<br>
Name: VMMaker-oscog-dtl.60<br>
These changes are methods from the main VMM branch for which<br>
&lt;#var:#type:&gt; declarations have been formatted with proper spacing. By<br>
updating these in the oscog branch, all of these methods are identical<br>
in both branches. All changes are cosmetic (no functional changes to<br>
the methods).<br>
<br>
Name: VMMaker-oscog-MarianoMartinezPeck.65<br>
Author: MarianoMartinezPeck<br>
Time: 23 April 2011, 1:50:19 pm<br>
UUID: 944f5c54-f2f5-4cc7-b693-b4db9320cff8<br>
Ancestors: VMMaker-oscog-dtl.64<br>
<br>
blah<br>
<br>
Name: VMMaker-oscog-MarianoMartinezPeck.66<br>
Author: MarianoMartinezPeck<br>
Time: 23 April 2011, 2:17:26 pm<br>
UUID: 97bab5b0-51d6-4deb-8b58-5bcedd4747dc<br>
Ancestors: VMMaker-oscog-MarianoMartinezPeck.65<br>
<br>
Adapt VMMakerTool so that it doesnt try to register in the menu if<br>
TheWorldMenu is not present, like the case of Pharo. This change was<br>
already integrated in the main trunk of VMMaker but since Eliot forked<br>
VMMaker-oscog before that, it was not there.<br>
<br>
It doesn&#39;t affect Squeak<br>
<font color="#888888"><br>
<br>
--<br>
Best regards,<br>
Igor Stasenko AKA sig.<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>best,<div>Eliot</div><br>