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

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

by phil＠highoctane.be

I used it with OB and indeed, it helps a lot working in one's projet indeed. Phil 2013/2/20 Esteban Lorenzano <estebanlm(a)gmail.com>: > 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

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 phil＠highoctane.be

Relax. Onboarding 3.0. 2013/2/20 Marcus Denker <marcus.denker(a)inria.fr>: > > On Feb 20, 2013, at 10:53 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. >> > Yes, and a release is only once a year.. > > If we want to fix everything on that level, we will *never* release anything. > The release is defined as something not completely unusable of the stuff we > *did do*. It is not defined as "that what I would like to have". > >> What will happen is that people will remove the method and recreate a new one. >> Version history will then go away. >> > Are you sure the version history is kept when you do a refactoring? > > >> Or is the system smart enough to find out about these things? >> > > No. But that is *not* a show stopper for 2.0 > > If you want to improve the system in these directions, you should join 3.0 development early. > >> 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

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. Also, it does not looks like you have the lastest image... you should be seeing something like this: (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] About condensing sources, becoming CompiledMethods and VM crashes

by Guillermo Polito

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

Feb. 20, 2013

[Pharo-project] Pharo 2 changes management

by Norbert Hartl

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

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] About condensing sources, becoming CompiledMethods and VM crashes

by Marcus Denker

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

Feb. 20, 2013

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

by Esteban Lorenzano

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] About condensing sources, becoming CompiledMethods and VM crashes

by Guillermo Polito

BTW, I can reproduce the crash with latest Eliot's Cog and Pharo vm. On Wed, Feb 20, 2013 at 11:00 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? > > > 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 >> >> >

Feb. 20, 2013