February 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] About condensing sources, becoming CompiledMethods and VM crashes

by Marcus Denker

On Feb 20, 2013, at 12:13 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Ok, I tried the following: > > - changed the become in #setSourcePointer: by an #at:put: in the method dict > - before exporting the sources, I run the shutdown and after, I run the startup lists. > - I ran the condense sources like > > [ Smalltalk condenseSources ] forkAt: Processor highestPriority. > > > Then, the export runs ok, but there is a crash in the CompiledMethod class>>cleanUp > I think the cleanup is not necessary when condensingâ¦ it touches only methods that are *not* installed in classes. We should remove that call from the condense method. > Segmentation fault > > > Smalltalk stack dump: > 0xbffbe2d0 M ByteString class(String class)>new: 528605460: a(n) ByteString class > 0xbffbe2f8 M ByteString(SequenceableCollection)>copyReplaceFrom:to:with: 531139536: a(n) ByteString > 0xbffbe31c M ByteString(SequenceableCollection)>, 531139536: a(n) ByteString > 0xbffbe33c M CompiledMethodTrailer>encode 570089224: a(n) CompiledMethodTrailer > 0xbffbe35c M CompiledMethodTrailer>createMethod:class:header: 570089224: a(n) CompiledMethodTrailer > 0xbffbe39c M CompiledMethod>copyWithTrailerBytes: 530925156: a(n) CompiledMethod > 0xbffbe3bc M CompiledMethod>zapSourcePointer 530925156: a(n) CompiledMethod > 0xbffbe3d4 M [] in CompiledMethod class>cleanUp 528604864: a(n) CompiledMethod class > > On Wed, Feb 20, 2013 at 12:00 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > i thinking that become is unnecessary, > it can be just at:put: into method dictionary, > so eventually all methods will be updated (after restarting permanent processes) > > On 20 February 2013 11:13, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > I summon Eliot :). > > > > > > On Wed, Feb 20, 2013 at 11:03 AM, Marcus Denker <marcus.denker(a)inria.fr> > > wrote: > >> > >> > >> On Feb 20, 2013, at 11:01 AM, Guillermo Polito <guillermopolito(a)gmail.com> > >> wrote: > >> > >> 'cause you don't know if the method has trailer or not I think... There > >> are empty trailers and trailers embedding source (directly in the image)... > >> isn't it? > >> > >> Not for those methods installed in classesâ¦ we are updating an existing > >> pointer here. > >> > >> Marcus > >> > >> > >> On Wed, Feb 20, 2013 at 10:52 AM, Marcus Denker <marcus.denker(a)inria.fr> > >> wrote: > >>> > >>> > >>> On Feb 20, 2013, at 10:45 AM, Guillermo Polito > >>> <guillermopolito(a)gmail.com> wrote: > >>> > >>> Hi! > >>> > >>> There is this bug open I was taking a look yesterday: > >>> > >>> > >>> http://code.google.com/p/pharo/issues/detail?can=2&start=0&num=100&q=Milest… > >>> > >>> The condense sources compacts the changes and source files, and adds a > >>> new method trailer to a compiled method with it's new source pointer. In > >>> order to do that, it does a #becomeForward: to the method. > >>> > >>> CompiledMethod>>setSourcePointer: srcPointer > >>> "We can't change the trailer of existing method, since > >>> it could have completely different format. Therefore we need to > >>> generate a copy with new trailer, containing an scrPointer, and then > >>> #become it" > >>> | trailer copy | > >>> trailer := CompiledMethodTrailer new sourcePointer: srcPointer. > >>> copy := self copyWithTrailerBytes: trailer. > >>> >>> self becomeForward: copy. > >>> ^ copy > >>> > >>> So far, with simple methods, so good. > >>> > >>> However, there are cases, in which becoming the compiled method, breaks > >>> processes, sometimes getting a crash in the VM. For example: > >>> > >>> (Delay class>>#handleTimerEvent) setSourcePosition: 200 inFile: 1 > >>> > >>> (ProcessorScheduler class>>#idleProcess) setSourcePosition: 200 inFile: 1 > >>> > >>> My assumption is that the #becomeForward: of compiled methods do not get > >>> well with the stack mapping in the vm... But just guessing. > >>> > >>> > >>> I wonder why we don't just update the pointer. > >>> That is: we keep the method the same, rewrite the pointer, and nothing > >>> else. > >>> > >>> Marcus > >>> > >> > >> > > > > > > -- > Best regards, > Igor Stasenko. > >

Feb. 20, 2013

Re: [Pharo-project] About condensing sources, becoming CompiledMethods and VM crashes

by Guillermo Polito

Ok, I tried the following: - changed the become in #setSourcePointer: by an #at:put: in the method dict - before exporting the sources, I run the shutdown and after, I run the startup lists. - I ran the condense sources like [ Smalltalk condenseSources ] forkAt: Processor highestPriority. Then, the export runs ok, but there is a crash in the CompiledMethod class>>cleanUp Segmentation fault Smalltalk stack dump: 0xbffbe2d0 M ByteString class(String class)>new: 528605460: a(n) ByteString class 0xbffbe2f8 M ByteString(SequenceableCollection)>copyReplaceFrom:to:with: 531139536: a(n) ByteString 0xbffbe31c M ByteString(SequenceableCollection)>, 531139536: a(n) ByteString 0xbffbe33c M CompiledMethodTrailer>encode 570089224: a(n) CompiledMethodTrailer 0xbffbe35c M CompiledMethodTrailer>createMethod:class:header: 570089224: a(n) CompiledMethodTrailer 0xbffbe39c M CompiledMethod>copyWithTrailerBytes: 530925156: a(n) CompiledMethod 0xbffbe3bc M CompiledMethod>zapSourcePointer 530925156: a(n) CompiledMethod 0xbffbe3d4 M [] in CompiledMethod class>cleanUp 528604864: a(n) CompiledMethod class On Wed, Feb 20, 2013 at 12:00 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > i thinking that become is unnecessary, > it can be just at:put: into method dictionary, > so eventually all methods will be updated (after restarting permanent > processes) > > On 20 February 2013 11:13, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > I summon Eliot :). > > > > > > On Wed, Feb 20, 2013 at 11:03 AM, Marcus Denker <marcus.denker(a)inria.fr> > > wrote: > >> > >> > >> On Feb 20, 2013, at 11:01 AM, Guillermo Polito < > guillermopolito(a)gmail.com> > >> wrote: > >> > >> 'cause you don't know if the method has trailer or not I think... There > >> are empty trailers and trailers embedding source (directly in the > image)... > >> isn't it? > >> > >> Not for those methods installed in classesâ¦ we are updating an existing > >> pointer here. > >> > >> Marcus > >> > >> > >> On Wed, Feb 20, 2013 at 10:52 AM, Marcus Denker <marcus.denker(a)inria.fr > > > >> wrote: > >>> > >>> > >>> On Feb 20, 2013, at 10:45 AM, Guillermo Polito > >>> <guillermopolito(a)gmail.com> wrote: > >>> > >>> Hi! > >>> > >>> There is this bug open I was taking a look yesterday: > >>> > >>> > >>> > http://code.google.com/p/pharo/issues/detail?can=2&start=0&num=100&q=Milest… > >>> > >>> The condense sources compacts the changes and source files, and adds a > >>> new method trailer to a compiled method with it's new source pointer. > In > >>> order to do that, it does a #becomeForward: to the method. > >>> > >>> CompiledMethod>>setSourcePointer: srcPointer > >>> "We can't change the trailer of existing method, since > >>> it could have completely different format. Therefore we need to > >>> generate a copy with new trailer, containing an scrPointer, and then > >>> #become it" > >>> | trailer copy | > >>> trailer := CompiledMethodTrailer new sourcePointer: srcPointer. > >>> copy := self copyWithTrailerBytes: trailer. > >>> >>> self becomeForward: copy. > >>> ^ copy > >>> > >>> So far, with simple methods, so good. > >>> > >>> However, there are cases, in which becoming the compiled method, breaks > >>> processes, sometimes getting a crash in the VM. For example: > >>> > >>> (Delay class>>#handleTimerEvent) setSourcePosition: 200 inFile: 1 > >>> > >>> (ProcessorScheduler class>>#idleProcess) setSourcePosition: 200 > inFile: 1 > >>> > >>> My assumption is that the #becomeForward: of compiled methods do not > get > >>> well with the stack mapping in the vm... But just guessing. > >>> > >>> > >>> I wonder why we don't just update the pointer. > >>> That is: we keep the method the same, rewrite the pointer, and nothing > >>> else. > >>> > >>> Marcus > >>> > >> > >> > > > > > > -- > Best regards, > Igor Stasenko. > >

Feb. 20, 2013

Re: [Pharo-project] About condensing sources, becoming CompiledMethods and VM crashes

by Igor Stasenko

i thinking that become is unnecessary, it can be just at:put: into method dictionary, so eventually all methods will be updated (after restarting permanent processes) On 20 February 2013 11:13, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > I summon Eliot :). > > > On Wed, Feb 20, 2013 at 11:03 AM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: >> >> >> On Feb 20, 2013, at 11:01 AM, Guillermo Polito <guillermopolito(a)gmail.com> >> wrote: >> >> 'cause you don't know if the method has trailer or not I think... There >> are empty trailers and trailers embedding source (directly in the image)... >> isn't it? >> >> Not for those methods installed in classesâ¦ we are updating an existing >> pointer here. >> >> Marcus >> >> >> On Wed, Feb 20, 2013 at 10:52 AM, Marcus Denker <marcus.denker(a)inria.fr> >> wrote: >>> >>> >>> On Feb 20, 2013, at 10:45 AM, Guillermo Polito >>> <guillermopolito(a)gmail.com> wrote: >>> >>> Hi! >>> >>> There is this bug open I was taking a look yesterday: >>> >>> >>> http://code.google.com/p/pharo/issues/detail?can=2&start=0&num=100&q=Milest… >>> >>> The condense sources compacts the changes and source files, and adds a >>> new method trailer to a compiled method with it's new source pointer. In >>> order to do that, it does a #becomeForward: to the method. >>> >>> CompiledMethod>>setSourcePointer: srcPointer >>> "We can't change the trailer of existing method, since >>> it could have completely different format. Therefore we need to >>> generate a copy with new trailer, containing an scrPointer, and then >>> #become it" >>> | trailer copy | >>> trailer := CompiledMethodTrailer new sourcePointer: srcPointer. >>> copy := self copyWithTrailerBytes: trailer. >>> >>> self becomeForward: copy. >>> ^ copy >>> >>> So far, with simple methods, so good. >>> >>> However, there are cases, in which becoming the compiled method, breaks >>> processes, sometimes getting a crash in the VM. For example: >>> >>> (Delay class>>#handleTimerEvent) setSourcePosition: 200 inFile: 1 >>> >>> (ProcessorScheduler class>>#idleProcess) setSourcePosition: 200 inFile: 1 >>> >>> My assumption is that the #becomeForward: of compiled methods do not get >>> well with the stack mapping in the vm... But just guessing. >>> >>> >>> I wonder why we don't just update the pointer. >>> That is: we keep the method the same, rewrite the pointer, and nothing >>> else. >>> >>> Marcus >>> >> >> > -- Best regards, Igor Stasenko.

Feb. 20, 2013

Re: [Pharo-project] Weird behavior in Nautilus when doing a method rename

by phil＠highoctane.be

Yes, usability matters. Especially to get traction with new people. Alt-R,Alt-N is perfectly usable, no matter how deep it is in the refactoring menu. Refactoring fine for dealing with a codebase. Not so when dealing with typos or removing methods from a path while at the same time not really removing them (aka rename doThis to doThis_ temporarily for example). Phil 2013/2/20 Esteban Lorenzano <estebanlm(a)gmail.com>: > yes, but the debate is interesting, because is about usability... and we certainly need to improve a lot in that area. > I think that currently, when people performs an operation like rename, they are waiting for a refactor, not for the clean rename (if you look at eclipse, for instance, that's what you have when you rename a method or a class)... what has become quite uncommon is to perform the "non-refactored operation". > Of course we could have a place for that operation too, but since the "refactored one" is what people expects/uses, that has to be the one that will be easier to fetch. > > Esteban > > On Feb 20, 2013, at 11:25 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > >> Yes, but the rename is *not* in the refactoring menu. It is *below* >> the refactoring menu. >> So, it is an unexpected refactoring in disguise... >> >> There was a simple rename in 1.4 I think. Maybe can we get that one >> back (in 3.0 of course...) >> >> Phil >> >> 2013/2/20 Fernando Olivero <fernando.olivero(a)usi.ch>: >>> Hi, i had the same misconception once, but i recall Lukas pointed out >>> that the refactoring engine is built on the original refactoring's >>> from Fowler's book, and implemented in Smalltalk by Roberts and >>> Johnson [1]. >>> >>> So the semantics of the refactoring are preserved in the implementation. >>> >>> If you just want a method rename, not a method refactoring rename, >>> maybe is best have an option for that in the menu [2]. >>> >>> >>> Fernando >>> >>> [1] http://st-www.cs.illinois.edu/users/droberts/tapos.pdf >>> [2] or use a better widget for editing methods, than a simple code >>> editor within the pane of the browser, as in Gaucho..which i'm working >>> on. >>> >>> On Wed, Feb 20, 2013 at 11:03 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> and you are right, scoped browsing is a very powerful feature that can be tricky to newcomers... but at least now with nautilus it is there, as first option (in OB it was there, but more or less hidden in a submenu)... >>>> It is a small step, but is something... and well... we can improve in next releases, one step at a time :) >>>> >>>> Esteban >>>> >>>> On Feb 20, 2013, at 10:52 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>>> >>>>> Yes, thanks, I figured that out. A newcomer wouldn't... and renaming >>>>> is pretty common. >>>>> >>>>> What will happen is that people will remove the method and recreate a new one. >>>>> Version history will then go away. >>>>> >>>>> Or is the system smart enough to find out about these things? >>>>> >>>>> Phil >>>>> >>>>> 2013/2/20 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>>>> hi, >>>>>> >>>>>> yes, you are right.. but that is a "nice to have", not a bug... so it will wait to 3.0 :) >>>>>> In the mean time, you can do a scoped rename: you select the packages you want, then right click and "browse scoped", then you apply you rename, and it will apply the refactor in the scoped selection, not all the image. >>>>>> >>>>>> cheers, >>>>>> Esteban >>>>>> >>>>>> On Feb 20, 2013, at 10:21 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>>>>> >>>>>>> Well, look at the screenshot then tell me that this is what I want. >>>>>>> >>>>>>> It is definitively *not* what I want. Especially unchecking that >>>>>>> endless list of methods. >>>>>>> >>>>>>> Adding a "Uncheck all" "Check all" button to the Changes Browser list >>>>>>> would help... >>>>>>> >>>>>>> Regards >>>>>>> Phil >>>>>>> >>>>>>> 2013/2/20 Camillo Bruni <camillobruni(a)gmail.com>: >>>>>>>> there is 1 certain bug, that is that you cannot see the changes of the refactoring: >>>>>>>> >>>>>>>> https://code.google.com/p/pharo/issues/detail?id=7547 >>>>>>>> >>>>>>>> the rest I would consider a bug as well. But in the terms of refactoring it might >>>>>>>> be "valid". It does preserve behavior by renaming also all implementors. >>>>>>>> >>>>>>>> How about this reasoning: >>>>>>>> >>>>>>>> Rename method >>>>>>>> => rename all senders (since you refactor) >>>>>>>> => you have to rename all implementors as well since you renamed all send sites >>>>>>>> otherwise you'll run for sure into a DNU >>>>>>>> >>>>>>>> I think I just convinced myself :D >>>>>>>> >>>>>>>> On 2013-02-20, at 09:26, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>>>>>>>> I was doing a Refactoring>rename of the initialize method in Nautilus >>>>>>>>> for the ClassMethodBrowser and then the changes browser proposed me to >>>>>>>>> change all classes with initialize. WTF? >>>>>>>>> >>>>>>>>> Phil >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> <PharoScreenshot.3.png> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> > >

Feb. 20, 2013

Re: [Pharo-project] Continuing weirdness with SS3.gemstone.com and Monticello in Pharo 2.0

by Esteban Lorenzano

On Feb 19, 2013, at 11:27 PM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > Well, that's what you get from having people using some other kind of > workflow that the usual one you gurus use since years; they do click > on some unforseen button combinations. But frozen it was for sure. yep... and that's why your reports are welcome, we need some others than us trying the system to find this issues before release (otherwise, it will be a failed release, and no one wants that :) > > Anyway, cannot send you any image for testing... it was frozen. > > This makes me wonder: isn't there any way to put a kind of non > maskable kind of interrupt key in the VM that would interrupt its > execution for sure? > > I do encounter a tad too many freezes. Some of them my fault but quite > some others not really. I now understand why one would have a process > saving images with an incrementing number endlessly in the background > to avoid just that now. > > I don't even want to think about life before Monticello ... Yikes! tbh, I know about this problem since a couple of days: is a vm problem that we are trying to figure out if is a problem in our merge or it is a JIT problem (I think is the last one, but I have to be sure before transmit it to Eliot) Esteban > > Phil > > 2013/2/19 Camillo Bruni <camillobruni(a)gmail.com>: >> this is rather strange. >> We're using gemstone for all pharo development and we haven't had any problems with it. >> >> I loaded all the stuff from your test-repository and it worked. >> more details? ;) >> >> On 2013-02-19, at 22:06, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >> >>> So, I wanted to merge my stuff from the SS3 project. >>> >>> When loading it needed to have BitBltPen (which I had somewhere as in >>> BitBltPen-MarianoMartinezPeck.4.mcz) >>> >>> I wanted to put that into my SS3 area and so, added the repository to >>> the list of repos in monticello, then took the mcz and then added the >>> repository to the package. >>> >>> Net result: Frozen image. >>> >>> No amount of Cmd-. could do anything. >>> >>> See screenshot. >>> >>> ... now restarting VM... >>> >>> Phil >>> <Capture dâÃ©cran 2013-02-19 Ã 22.01.46.png> >> >> >

Feb. 20, 2013

Re: [Pharo-project] Weird behavior in Nautilus when doing a method rename

by phil＠highoctane.be

Like in the top of the menu, along with a shortcut... Now, Renaming a class exists in Refactoring>Class Refactoring>Rename/Remove and also as Rename below the refactoring. For method refactoring, there is not the rename in the refactorings menu. So, all right, there is a whole slew of improvements possible in there as "First Impressions Count". So, how do I rename a method without refactorings? I had a look at RBChangeMethodNameRefactoring>>renameImplementors self implementors do: [:each | | parseTree | parseTree := each parseTreeFor: oldSelector. parseTree isNil ifTrue: [self refactoringFailure: 'Could not parse source code.']. self implementorsCanBePrimitives ifFalse: [parseTree isPrimitive ifTrue: [self refactoringFailure: ('<1p>''s implementation of #<2s> is a primitive' expandMacrosWith: each with: oldSelector)]]. self modifyImplementorParseTree: parseTree in: each. (each methodFor: oldSelector) compileTree: parseTree] but then saw: transform self renameImplementors. self renameMessageSends. self removeRenamedImplementors Really so complicated for a rename? Is there any place to look at? Phil 2013/2/20 Esteban Lorenzano <estebanlm(a)gmail.com>: > he... yeah, probably there are a lot of theory that says that you should have them in separated places or whatever. > But in practice, people does refactors all the time and they need to have them close to their use, not lost in some paper-defined place :) > > Esteban > > On Feb 20, 2013, at 11:06 AM, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > >> Hi, i had the same misconception once, but i recall Lukas pointed out >> that the refactoring engine is built on the original refactoring's >> from Fowler's book, and implemented in Smalltalk by Roberts and >> Johnson [1]. >> >> So the semantics of the refactoring are preserved in the implementation. >> >> If you just want a method rename, not a method refactoring rename, >> maybe is best have an option for that in the menu [2]. >> >> >> Fernando >> >> [1] http://st-www.cs.illinois.edu/users/droberts/tapos.pdf >> [2] or use a better widget for editing methods, than a simple code >> editor within the pane of the browser, as in Gaucho..which i'm working >> on. >> >> On Wed, Feb 20, 2013 at 11:03 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> and you are right, scoped browsing is a very powerful feature that can be tricky to newcomers... but at least now with nautilus it is there, as first option (in OB it was there, but more or less hidden in a submenu)... >>> It is a small step, but is something... and well... we can improve in next releases, one step at a time :) >>> >>> Esteban >>> >>> On Feb 20, 2013, at 10:52 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>> >>>> Yes, thanks, I figured that out. A newcomer wouldn't... and renaming >>>> is pretty common. >>>> >>>> What will happen is that people will remove the method and recreate a new one. >>>> Version history will then go away. >>>> >>>> Or is the system smart enough to find out about these things? >>>> >>>> Phil >>>> >>>> 2013/2/20 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>>> hi, >>>>> >>>>> yes, you are right.. but that is a "nice to have", not a bug... so it will wait to 3.0 :) >>>>> In the mean time, you can do a scoped rename: you select the packages you want, then right click and "browse scoped", then you apply you rename, and it will apply the refactor in the scoped selection, not all the image. >>>>> >>>>> cheers, >>>>> Esteban >>>>> >>>>> On Feb 20, 2013, at 10:21 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>>>> >>>>>> Well, look at the screenshot then tell me that this is what I want. >>>>>> >>>>>> It is definitively *not* what I want. Especially unchecking that >>>>>> endless list of methods. >>>>>> >>>>>> Adding a "Uncheck all" "Check all" button to the Changes Browser list >>>>>> would help... >>>>>> >>>>>> Regards >>>>>> Phil >>>>>> >>>>>> 2013/2/20 Camillo Bruni <camillobruni(a)gmail.com>: >>>>>>> there is 1 certain bug, that is that you cannot see the changes of the refactoring: >>>>>>> >>>>>>> https://code.google.com/p/pharo/issues/detail?id=7547 >>>>>>> >>>>>>> the rest I would consider a bug as well. But in the terms of refactoring it might >>>>>>> be "valid". It does preserve behavior by renaming also all implementors. >>>>>>> >>>>>>> How about this reasoning: >>>>>>> >>>>>>> Rename method >>>>>>> => rename all senders (since you refactor) >>>>>>> => you have to rename all implementors as well since you renamed all send sites >>>>>>> otherwise you'll run for sure into a DNU >>>>>>> >>>>>>> I think I just convinced myself :D >>>>>>> >>>>>>> On 2013-02-20, at 09:26, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>>>>>>> I was doing a Refactoring>rename of the initialize method in Nautilus >>>>>>>> for the ClassMethodBrowser and then the changes browser proposed me to >>>>>>>> change all classes with initialize. WTF? >>>>>>>> >>>>>>>> Phil >>>>>>>> >>>>>>> >>>>>>> >>>>>> <PharoScreenshot.3.png> >>>>> >>>>> >>>> >>> >>> >> > >

Feb. 20, 2013

Re: [Pharo-project] Weird behavior in Nautilus when doing a method rename

by Esteban Lorenzano

yes, but the debate is interesting, because is about usability... and we certainly need to improve a lot in that area. I think that currently, when people performs an operation like rename, they are waiting for a refactor, not for the clean rename (if you look at eclipse, for instance, that's what you have when you rename a method or a class)... what has become quite uncommon is to perform the "non-refactored operation". Of course we could have a place for that operation too, but since the "refactored one" is what people expects/uses, that has to be the one that will be easier to fetch. Esteban On Feb 20, 2013, at 11:25 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > Yes, but the rename is *not* in the refactoring menu. It is *below* > the refactoring menu. > So, it is an unexpected refactoring in disguise... > > There was a simple rename in 1.4 I think. Maybe can we get that one > back (in 3.0 of course...) > > Phil > > 2013/2/20 Fernando Olivero <fernando.olivero(a)usi.ch>: >> Hi, i had the same misconception once, but i recall Lukas pointed out >> that the refactoring engine is built on the original refactoring's >> from Fowler's book, and implemented in Smalltalk by Roberts and >> Johnson [1]. >> >> So the semantics of the refactoring are preserved in the implementation. >> >> If you just want a method rename, not a method refactoring rename, >> maybe is best have an option for that in the menu [2]. >> >> >> Fernando >> >> [1] http://st-www.cs.illinois.edu/users/droberts/tapos.pdf >> [2] or use a better widget for editing methods, than a simple code >> editor within the pane of the browser, as in Gaucho..which i'm working >> on. >> >> On Wed, Feb 20, 2013 at 11:03 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> and you are right, scoped browsing is a very powerful feature that can be tricky to newcomers... but at least now with nautilus it is there, as first option (in OB it was there, but more or less hidden in a submenu)... >>> It is a small step, but is something... and well... we can improve in next releases, one step at a time :) >>> >>> Esteban >>> >>> On Feb 20, 2013, at 10:52 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>> >>>> Yes, thanks, I figured that out. A newcomer wouldn't... and renaming >>>> is pretty common. >>>> >>>> What will happen is that people will remove the method and recreate a new one. >>>> Version history will then go away. >>>> >>>> Or is the system smart enough to find out about these things? >>>> >>>> Phil >>>> >>>> 2013/2/20 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>>> hi, >>>>> >>>>> yes, you are right.. but that is a "nice to have", not a bug... so it will wait to 3.0 :) >>>>> In the mean time, you can do a scoped rename: you select the packages you want, then right click and "browse scoped", then you apply you rename, and it will apply the refactor in the scoped selection, not all the image. >>>>> >>>>> cheers, >>>>> Esteban >>>>> >>>>> On Feb 20, 2013, at 10:21 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>>>> >>>>>> Well, look at the screenshot then tell me that this is what I want. >>>>>> >>>>>> It is definitively *not* what I want. Especially unchecking that >>>>>> endless list of methods. >>>>>> >>>>>> Adding a "Uncheck all" "Check all" button to the Changes Browser list >>>>>> would help... >>>>>> >>>>>> Regards >>>>>> Phil >>>>>> >>>>>> 2013/2/20 Camillo Bruni <camillobruni(a)gmail.com>: >>>>>>> there is 1 certain bug, that is that you cannot see the changes of the refactoring: >>>>>>> >>>>>>> https://code.google.com/p/pharo/issues/detail?id=7547 >>>>>>> >>>>>>> the rest I would consider a bug as well. But in the terms of refactoring it might >>>>>>> be "valid". It does preserve behavior by renaming also all implementors. >>>>>>> >>>>>>> How about this reasoning: >>>>>>> >>>>>>> Rename method >>>>>>> => rename all senders (since you refactor) >>>>>>> => you have to rename all implementors as well since you renamed all send sites >>>>>>> otherwise you'll run for sure into a DNU >>>>>>> >>>>>>> I think I just convinced myself :D >>>>>>> >>>>>>> On 2013-02-20, at 09:26, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>>>>>>> I was doing a Refactoring>rename of the initialize method in Nautilus >>>>>>>> for the ClassMethodBrowser and then the changes browser proposed me to >>>>>>>> change all classes with initialize. WTF? >>>>>>>> >>>>>>>> Phil >>>>>>>> >>>>>>> >>>>>>> >>>>>> <PharoScreenshot.3.png> >>>>> >>>>> >>>> >>> >>> >> >

Feb. 20, 2013

Re: [Pharo-project] Pharo 2 changes management

by Esteban Lorenzano

On Feb 20, 2013, at 11:25 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 20.02.2013 um 11:17 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > >> there is a problem with the package definition, I think (PetitXPath != Petitxpath), and new RPackage cannot detect they are the same... in fact, IMO that exposes an old PackageInfo bug, not an RPackage problem, so I think the real solution is to commit a package with a good package name. > > So, what are the rules. Does the case sensitivity also reflect in method extensions? Meaning do I need to call the extension *petitXPath or even *PetitXPath? nono, method extensions remains the same (case insensitive). What I mean is that I made a mistake when I create the PetitXPath package originally (I committed with a bad mc name)... that's the origin of your problem now (yep, once again, my fault :). But it shouldn't happen with other well-formed packages. And in my opinion, best way to proceed is to create a package as it should be and re-commit, because is not a MC problem, nor an RPackage problem, is a problem with that specific package. > >> Also, it does not looks like you have the lastest image... you should be seeing something like this: >> > Yeah, I made the screenshot with an older image. I retried it then with updating the image first. But seeing that the result ist the same made me send the old screenshot. fiuuuuu... I was worried :) Esteban > Norbert > >> <Screen Shot 2013-02-20 at 11.15.07 AM.png> >> >> >> (notice the diff morph has a bar in the middle, also two text label on top). >> >> >> On Feb 20, 2013, at 11:08 AM, Norbert Hartl <norbert(a)hartl.name> wrote: >> >>> I opened a fresh pharo 2 (#20559) and loaded PetitXPath. Modifying a method does not mark the package dirty in monticello browser. And If I press the "changes" button I can see >>> >>> <Bildschirmfoto 2013-02-20 um 11.00.54.png> >>> >>> That basically shows all the code that is in the package. But from my own change I cannot see anything in there. >>> >>> Norbert >> >

Feb. 20, 2013

Re: [Pharo-project] Pharo 2 changes management

by Norbert Hartl

Am 20.02.2013 um 11:17 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > there is a problem with the package definition, I think (PetitXPath != Petitxpath), and new RPackage cannot detect they are the same... in fact, IMO that exposes an old PackageInfo bug, not an RPackage problem, so I think the real solution is to commit a package with a good package name. So, what are the rules. Does the case sensitivity also reflect in method extensions? Meaning do I need to call the extension *petitXPath or even *PetitXPath? > Also, it does not looks like you have the lastest image... you should be seeing something like this: > Yeah, I made the screenshot with an older image. I retried it then with updating the image first. But seeing that the result ist the same made me send the old screenshot. Norbert > <Screen Shot 2013-02-20 at 11.15.07 AM.png> > > > (notice the diff morph has a bar in the middle, also two text label on top). > > > On Feb 20, 2013, at 11:08 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> I opened a fresh pharo 2 (#20559) and loaded PetitXPath. Modifying a method does not mark the package dirty in monticello browser. And If I press the "changes" button I can see >> >> <Bildschirmfoto 2013-02-20 um 11.00.54.png> >> >> That basically shows all the code that is in the package. But from my own change I cannot see anything in there. >> >> Norbert >

Feb. 20, 2013

Re: [Pharo-project] Weird behavior in Nautilus when doing a method rename

by phil＠highoctane.be

Yes, but the rename is *not* in the refactoring menu. It is *below* the refactoring menu. So, it is an unexpected refactoring in disguise... There was a simple rename in 1.4 I think. Maybe can we get that one back (in 3.0 of course...) Phil 2013/2/20 Fernando Olivero <fernando.olivero(a)usi.ch>: > Hi, i had the same misconception once, but i recall Lukas pointed out > that the refactoring engine is built on the original refactoring's > from Fowler's book, and implemented in Smalltalk by Roberts and > Johnson [1]. > > So the semantics of the refactoring are preserved in the implementation. > > If you just want a method rename, not a method refactoring rename, > maybe is best have an option for that in the menu [2]. > > > Fernando > > [1] http://st-www.cs.illinois.edu/users/droberts/tapos.pdf > [2] or use a better widget for editing methods, than a simple code > editor within the pane of the browser, as in Gaucho..which i'm working > on. > > On Wed, Feb 20, 2013 at 11:03 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> and you are right, scoped browsing is a very powerful feature that can be tricky to newcomers... but at least now with nautilus it is there, as first option (in OB it was there, but more or less hidden in a submenu)... >> It is a small step, but is something... and well... we can improve in next releases, one step at a time :) >> >> Esteban >> >> On Feb 20, 2013, at 10:52 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >> >>> Yes, thanks, I figured that out. A newcomer wouldn't... and renaming >>> is pretty common. >>> >>> What will happen is that people will remove the method and recreate a new one. >>> Version history will then go away. >>> >>> Or is the system smart enough to find out about these things? >>> >>> Phil >>> >>> 2013/2/20 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>> hi, >>>> >>>> yes, you are right.. but that is a "nice to have", not a bug... so it will wait to 3.0 :) >>>> In the mean time, you can do a scoped rename: you select the packages you want, then right click and "browse scoped", then you apply you rename, and it will apply the refactor in the scoped selection, not all the image. >>>> >>>> cheers, >>>> Esteban >>>> >>>> On Feb 20, 2013, at 10:21 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>>> >>>>> Well, look at the screenshot then tell me that this is what I want. >>>>> >>>>> It is definitively *not* what I want. Especially unchecking that >>>>> endless list of methods. >>>>> >>>>> Adding a "Uncheck all" "Check all" button to the Changes Browser list >>>>> would help... >>>>> >>>>> Regards >>>>> Phil >>>>> >>>>> 2013/2/20 Camillo Bruni <camillobruni(a)gmail.com>: >>>>>> there is 1 certain bug, that is that you cannot see the changes of the refactoring: >>>>>> >>>>>> https://code.google.com/p/pharo/issues/detail?id=7547 >>>>>> >>>>>> the rest I would consider a bug as well. But in the terms of refactoring it might >>>>>> be "valid". It does preserve behavior by renaming also all implementors. >>>>>> >>>>>> How about this reasoning: >>>>>> >>>>>> Rename method >>>>>> => rename all senders (since you refactor) >>>>>> => you have to rename all implementors as well since you renamed all send sites >>>>>> otherwise you'll run for sure into a DNU >>>>>> >>>>>> I think I just convinced myself :D >>>>>> >>>>>> On 2013-02-20, at 09:26, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>>>>>> I was doing a Refactoring>rename of the initialize method in Nautilus >>>>>>> for the ClassMethodBrowser and then the changes browser proposed me to >>>>>>> change all classes with initialize. WTF? >>>>>>> >>>>>>> Phil >>>>>>> >>>>>> >>>>>> >>>>> <PharoScreenshot.3.png> >>>> >>>> >>> >> >> >

Feb. 20, 2013