Please guys fluidify, it's too damned important.
Hilaire Le 23/06/2011 07:50, Stéphane Ducasse a écrit : > > On Jun 22, 2011, at 7:07 PM, Eliot Miranda wrote: > >> Hi All, >> >> On Tue, Jun 21, 2011 at 12:29 PM, Stéphane Ducasse >> <[email protected]> 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. > > eliot I understand that. I'm not criticizing but people should be aware that > there are differences between VMs and that we can have bugs related to that. > I think that igor should know how to play in the vm community. Just tell him > that his contributions are not welcomed > and we will think about it and do something. After we met this winter I > thought it was clear you wanted to collaborate and build a community. > I can tell you that I do not like when igor enters my office and tell me that > he feels like shit because some of his changes > from about a year ago are still not integrated. > > Stef > > > > > >> >> >> 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. >> >> 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? >> >> >> >> 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. >> >> >> >> -- >> best, >> Eliot >> > > > -- Education 0.2 -- http://blog.ofset.org/hilaire
