June 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] #assert:equals: feels backwards

by Tudor Girba

Hi, Phexample does not patch SUnit at all. It adds only Object>>should, and then everything else is 100% SUnit compatible by extending TestCase with Phexample. But beside the DSL, with Phexample you also get a new way of organizing your tests. Every test returns a value and thus becomes an example. And examples can be based on other examples. This simple change makes the setUp irrelevant because you can simply use an example for setting up. I believe this is a cool infrastructure. Cheers, Doru On 22 Jun 2011, at 08:38, laurent laffont wrote: > > On Wed, Jun 22, 2011 at 7:58 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Jun 22, 2011, at 7:44 AM, laurent laffont wrote: > > > Camillo and Dennis, > > > > Thanks for answer and yes, I think you're right about using PhExample/Mocketry DSL, that's the way to go. > > except that I would not patch SUnit but have another Testing framework for that. > And I\m not sure that I want to write should equals:..... not enought experience to have a good point of view > > > > I don't know about PhExample but Mocketry does not patch SUnit but provide extensions to Object / SmallInteger / ... for the DSL part. > > It loads easily and also have an HelpSystem book :) > > Gofer it > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfMocketry'; > load. > > ConfigurationOfMocketry load. > > 1 should equal: 1. > > > I think I will use it for TWM. > > > Laurent. > > > > > Laurent. > > > > > > On Wed, Jun 22, 2011 at 6:31 AM, Dennis Schetinin <chaetal(a)gmail.com> wrote: > > > > > > 2011/6/22 laurent laffont <laurent.laffont(a)gmail.com> > > IMO having the expected value before is the right way ! Do you TDD ? It makes a lot of sense for me to write assert: expected equals: actual. Am I alone ? > > > > I practice TDD, and I start tests with assertions (after naming them). But I'm not sure I specify expected value first, as I'm focused on the result (I write the test for). Btw, I use Mocketry and exploit its sugar (or DSL?) for specifications there. So, I write: > > > > actualValue should equal: expectedValue. > > > > That is, after I've decided on a test case and named it, I think: what should I test? That's the actualValue. I name and write it. And only after that, I think about the value it should haveâ¦ well, in most cases at least. > > > > Anyway, I'm not sure an order I use to write assertion should be repeated by assertion messages. Just as order I use to write a test (name -> assertion -> the way to fetch the actual value -> â¦) is not reflected by test code. It's much more important to have a readable and understandable (after many months) code. And for me it's much more natural to read it this way: > > > > self assert: actualValue equals: expectedValue > > > > > > > > If you do TDD, you have first to decide what you expect. You don't know how to get it because the code doesn't exist yet. So you usually I write > > > > self assert: 'i want this' equals: > > > > then stop because I have to think about the interface / selectors / object I want. So it matches the flow of thought when I'm writing tests. > > > > And the other weird thing is that with this "fix" I now have to change hundred of tests I've written to be semantically correct !!!! > > > > > > Laurent. > > > > > > On Wed, Jun 22, 2011 at 12:39 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > > > Mariano Martinez Peck wrote: > > > > > > I don't understand Sean's problem. > > > > > > > Still using 1.2.2 :) Thanks for fixing it. > > > > Sean > > > > -- > > View this message in context: http://forum.world.st/assert-equals-feels-backwards-tp3614760p3615548.html > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > > > > > > > > -- > > Dennis Schetinin > > > > > -- www.tudorgirba.com "Sometimes the best solution is not the best solution."

June 23, 2011

Re: [Pharo-project] Athen, Cairo, Paris, Santiago, ...

by Tudor Girba

Is there a way to play with it already? Cheers, Doru On 22 Jun 2011, at 21:27, Igor Stasenko wrote: > On 22 June 2011 22:24, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> Rendering in Mondrian is now externalized into visitors. It should be pretty straightforward to write one for cairo >> > Athens has initially layered structure. > The frontend you will be using (canvas , surfaces, etc) is > implementation neutral. > So, swapping a backend who doing the real work, will cost nothing from > users perspective. > >> Alexandre >> >> >> On 22 Jun 2011, at 15:21, Igor Stasenko wrote: >> >>> On 22 June 2011 22:08, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>>> Hi! >>>> >>>> Just wondering what is the status of Athen / Cairo for Pharo? We recently put some effort on exporting Mondrian visualization to HTML/Protovis to benefit from vectorial graphics... >>>> >>> >>> Status: "Under development" >>> >>> :) >>> >>> It can draw almost everything morphic-related, except one little thing - text :) >>> And now i'm on crossroads , what to do. >>> Clearly, a StrikeFont(s) is state as they now, simply don't fit with >>> scalable vector graphics engine. >>> The bitmaps stored in memory are optimized for exact fit 1:1 of >>> display pixel grid. >>> So, at minimum it will require converting all fonts to use different >>> bitmaps, before they can be drawn using Athens canvas. >>> >>> Another thing is drawing strokes. It is a question how far i should go >>> implementing a basic (and most probably fall-back) engine which using >>> old BallooonEngine, >>> which can only draw a coarse, barely anti-aliased strokes. Not saying >>> it doesn't supports many things, like joint types, dashing , masking >>> etc etc. >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- www.tudorgirba.com "When people care, great things can happen."

June 23, 2011

Re: [Pharo-project] [PBE-Spanish] Status update 2011-06-21

by Mariano Martinez Peck

On Wed, Jun 22, 2011 at 11:12 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > thanks clara this is great to see this book translation making progress. > We are creating good energy. > > Stef (I will ask mariano to explain me for the surname) > > http://en.wikipedia.org/wiki/Isabel_Allende :) > > On Jun 22, 2011, at 8:10 PM, Clara Allende wrote: > > > I would like to help with the translation if I can :) and if you wish :O > > > > 2011/6/21 Diogenes Moreira <diogenes.moreira(a)gmail.com> > > Thank you very muchhhhhhhh. for your efforts > > > > D > > (and the english wrong readers ) > > > > > > On Tue, Jun 21, 2011 at 8:52 PM, Nicolas Paez <nicopaez(a)gmail.com> > wrote: > > Hello everyone, > > > > Here is the weekly update of the Spanish translation of Pharo By Example > book. > > > > Summary > > â¢ Just 4 charpters remaining to complete the rough translation. > > â¢ During this week we will focus on completing the translation of > the remaining chapters and on fixing the compilation errors we are getting. > > â¢ We have also started to define the revision process. > > â¢ By end of June we will publish a new drop with the completed > chapters. > > Chapters drill down > > > > Chapter 01: 80% > > Chapter 02: completed, but not published yet and with compilation errors > > Chapter 03: completed, already published > > Chapter 04: completed, already published > > Chapter 05: completed, but not published yet and with compilation errors > > Chapter 06: 21% > > Chapter 07: completed, and with compilation errors > > Chapter 08: completed, and with compilation errors > > Chapter 09: completed, and with compilation errors > > Chapter 10: just started > > Chapter 11: completed, already published > > Chapter 12: 52% > > Chapter 13: completed, and with compilation errors > > Chapter 14: completed > > > > Regards, > > NicoPaez > > http://nicopaez.wordpress.com > > > > > > > -- Mariano http://marianopeck.wordpress.com

June 23, 2011

Re: [Pharo-project] PharoKernel 13269

by StÃ©phane Ducasse

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 <stephane.ducasse(a)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. 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 >

June 23, 2011

Re: [Pharo-project] #assert:equals: feels backwards

by Camillo Bruni

On 2011-06-22, at 08:38, laurent laffont wrote: > On Wed, Jun 22, 2011 at 7:58 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Jun 22, 2011, at 7:44 AM, laurent laffont wrote: > > > Camillo and Dennis, > > > > Thanks for answer and yes, I think you're right about using PhExample/Mocketry DSL, that's the way to go. > > except that I would not patch SUnit but have another Testing framework for that. > And I\m not sure that I want to write should equals:..... not enought experience to have a good point of view > > > > I don't know about PhExample but Mocketry does not patch SUnit but provide extensions to Object / SmallInteger / ... for the DSL part. AFAIK Phexample does the same for the "should" part.. but there is more stuff added which is used for having a JExample like functionality with test dependencies..

June 23, 2011

Re: [Pharo-project] [Lsehub-staff] what about a sprint at lille July 8

by Camillo Bruni

I am certainly in :). On 2011-06-22, at 09:59, StÃ©phane Ducasse wrote: > Hi guys > > I would like to get some energy around code :) > and I propose a sprint july 8th at Lille... > What do you think? > > Stef

June 23, 2011

Re: [Pharo-project] PharoKernel 13269

by stephane ducasse

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

June 22, 2011

Re: [Pharo-project] Athen, Cairo, Paris, Santiago, ...

by StÃ©phane Ducasse

>> > > Status: "Under development" > > :) > > It can draw almost everything morphic-related, except one little thing - text :) > And now i'm on crossroads , what to do. > Clearly, a StrikeFont(s) is state as they now, simply don't fit with > scalable vector graphics engine. > The bitmaps stored in memory are optimized for exact fit 1:1 of > display pixel grid. > So, at minimum it will require converting all fonts to use different > bitmaps, before they can be drawn using Athens canvas. > > Another thing is drawing strokes. It is a question how far i should go > implementing a basic (and most probably fall-back) engine which using > old BallooonEngine, > which can only draw a coarse, barely anti-aliased strokes. Not saying > it doesn't supports many things, like joint types, dashing , masking > etc etc. one step at a time. release often eat your own dog food > > -- > Best regards, > Igor Stasenko AKA sig. >

June 22, 2011

Re: [Pharo-project] [PBE-Spanish] Status update 2011-06-21

by StÃ©phane Ducasse

thanks clara this is great to see this book translation making progress. We are creating good energy. Stef (I will ask mariano to explain me for the surname) On Jun 22, 2011, at 8:10 PM, Clara Allende wrote: > I would like to help with the translation if I can :) and if you wish :O > > 2011/6/21 Diogenes Moreira <diogenes.moreira(a)gmail.com> > Thank you very muchhhhhhhh. for your efforts > > D > (and the english wrong readers ) > > > On Tue, Jun 21, 2011 at 8:52 PM, Nicolas Paez <nicopaez(a)gmail.com> wrote: > Hello everyone, > > Here is the weekly update of the Spanish translation of Pharo By Example book. > > Summary > â¢ Just 4 charpters remaining to complete the rough translation. > â¢ During this week we will focus on completing the translation of the remaining chapters and on fixing the compilation errors we are getting. > â¢ We have also started to define the revision process. > â¢ By end of June we will publish a new drop with the completed chapters. > Chapters drill down > > Chapter 01: 80% > Chapter 02: completed, but not published yet and with compilation errors > Chapter 03: completed, already published > Chapter 04: completed, already published > Chapter 05: completed, but not published yet and with compilation errors > Chapter 06: 21% > Chapter 07: completed, and with compilation errors > Chapter 08: completed, and with compilation errors > Chapter 09: completed, and with compilation errors > Chapter 10: just started > Chapter 11: completed, already published > Chapter 12: 52% > Chapter 13: completed, and with compilation errors > Chapter 14: completed > > Regards, > NicoPaez > http://nicopaez.wordpress.com > >

June 22, 2011

Re: [Pharo-project] Merge tool. No way to cherry pick the changes?

by StÃ©phane Ducasse

>>> Perhaps the "non-applicable" could be streamlined. >>> I.e., "keep current version" = not applicable. >>> >> yes, could be.. >> but that logic are only for conflics.. and i didn't wanted to mess >> with it because its a lot more work. > > btw, Stephane, this is a good topic for dealing with it on friday, if > you don't have anything else in mind. ok did you run MC tests? I htink that we should invest more in running tests. >> Because strangely , instead of using field to indicate a conflict (in >> MCPatchOperation record) it does something strange and overly >> complicated >> (MCConflict). >> >> So, then each entry could contain >> 'isApplicable' >> and >> 'isConflicting' >> >> and once user resolves the conflict, the isConflicting should be set to false, >> while isApplicable are uniformly to indicate which version to use >> (current or incoming one), when merging. >> >> >>> No need for the extra menu item then. >>> >>> Regards, Gary >>> >>> ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> >>> To: <Pharo-project(a)lists.gforge.inria.fr> >>> Sent: Wednesday, June 22, 2011 3:40 PM >>> Subject: Re: [Pharo-project] Merge tool. No way to cherry pick the changes? >>> >>> >>>> Here the code >>>> http://code.google.com/p/pharo/issues/detail?id=4439 >>>> >>>> please tell me if it works for you. >>>> I tested on simple merge and it works fine (the changes which i marked >>>> as not applicable are not loaded). >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

June 22, 2011