Re: [Pharo-project] PharoKernel 13269
Locked
Re: [Pharo-project] PharoKernel 13269
 
|
Hi All, On Tue, Jun 21, 2011 at 12:29 PM, Stéphane Ducasse <[hidden email]> wrote: what we should pay attention (to be verified) is that igor told me that he does not understand why 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.
That's already integrated.
ditto.
Since there's a VM parameter I question the need for yet-another-primitive.
Already integrated.
Not integrating this. The VM parameter (41) has been in Cog since the beginning. Instead why not merge the VM parameter back into Interpreter?
-- best, Eliot |
[Pharo-project] PharoKernel 13269
|
|
oops, forgot CCs. On 22 June 2011 20:07, Eliot Miranda <[hidden email]> wrote: > Hi All, > > On Tue, Jun 21, 2011 at 12:29 PM, Stéphane Ducasse > <[hidden email]> 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. |
|
|
In reply to this post by Eliot Miranda-2
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 <[hidden email]> 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 |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |