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

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

by Guillermo Polito

BTW, the become works in StackVM, so I would blame the JIT :) On Wed, Feb 20, 2013 at 2:48 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Yes, because the vm crash is caused by the lost of the active process... > > > On Wed, Feb 20, 2013 at 2:44 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 20 February 2013 14:37, Guillermo Polito <guillermopolito(a)gmail.com> >> wrote: >> > >> > >> > On Wed, Feb 20, 2013 at 2:23 PM, Igor Stasenko <siguctua(a)gmail.com> >> wrote: >> >> >> >> but aside of making things work, >> >> i really wonder why become on methods makes VM crash. >> >> we should have an easily reproducible case for study. >> > >> > >> > These? >> > >> > (Delay class>>#handleTimerEvent) setSourcePosition: 200 inFile: 1 >> > >> >> this one shows "computation has terminated" >> its not crashing my VM.. >> this happens when context has no sender to return to (sender is nil) >> >> > (ProcessorScheduler class>>#idleProcess) setSourcePosition: 200 inFile: >> 1 >> >> this one crashing.. but still showing the same "computation has >> terminated" dialog before. >> >> > >> >> >> >> >> >> >> >> -- >> >> Best regards, >> >> Igor Stasenko. >> >> >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> >

Feb. 20, 2013

Re: [Pharo-project] Inbox in SmalltalkHub ?

by Nicolas Petton

There was a beginning of an inbox per project, yes. It's now gone (well, the feature has been postponed) but will be back (and working this time!) soon :) Nico Serge Stinckwich <serge.stinckwich(a)gmail.com> writes: > Dear all, > > If I remember correctly, in previous version of SmalltalkHub, > there was an inbox for every project. Apparently this is not more the > case in current version ? > > Regards, > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > -- Nicolas Petton http://nicolas-petton.fr

Feb. 20, 2013

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

by phil＠highoctane.be

Now, 19.999 left. http://code.google.com/p/pharo/issues/detail?id=7554 Slice in inbox. Phil 2013/2/20 Marcus Denker <marcus.denker(a)inria.fr>: > > On Feb 20, 2013, at 2:57 PM, Ben Coman <btc(a)openInWorld.com> wrote: > >> For 2.0 could the menu item be changed from 'Rename' to 'Rename All' ? >> >> That should satisfy the Principle Of Least Surprise >> and be sufficient avoid newcomer going... >> "I've heard Pharo is cool - oh! a new release, I'll try it - Rename - WTF - DELETE!!!!!" >> Perhaps exaggerating but is possible. >> > > As I said, If you argue on that level, we can never build something that we can release. > There are (my estimation) 20.000 issues like that that we would need to fix. > > Marcus

Feb. 20, 2013

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

by Marcus Denker

On Feb 20, 2013, at 2:57 PM, Ben Coman <btc(a)openInWorld.com> wrote: > For 2.0 could the menu item be changed from 'Rename' to 'Rename All' ? > > That should satisfy the Principle Of Least Surprise > and be sufficient avoid newcomer going... > "I've heard Pharo is cool - oh! a new release, I'll try it - Rename - WTF - DELETE!!!!!" > Perhaps exaggerating but is possible. > As I said, If you argue on that level, we can never build something that we can release. There are (my estimation) 20.000 issues like that that we would need to fix. Marcus

Feb. 20, 2013

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

by Ben Coman

For 2.0 could the menu item be changed from 'Rename' to 'Rename All' ? That should satisfy the Principle Of Least Surprise and be sufficient avoid newcomer going... "I've heard Pharo is cool - oh! a new release, I'll try it - Rename - WTF - DELETE!!!!!" Perhaps exaggerating but is possible. 2.0 should not be held up by small last minute issues, but if the changing the menu item is quick to implement... Also, could these last minute UI issues that don't break an API be targeted at 2.1 rather than 3.0. cheers -Ben Benjamin wrote: > There is actually no simple way to simply rename a method. > We should maybe add one which keep track of the versions :) > > Historically (even if it sounds wrong today) you create a new method, > and delete the old one (and indeed this is disturbing for new comers ^^) > > I really think that both usage are valid even if I think that most of the time, > you want to do a refactoring while renaming :) > > Let's release Pharo 2.0, and then we will have fun experimenting this ^^ > > Ben > > On Feb 20, 2013, at 11:45 AM, phil(a)highoctane.be wrote: > > >> 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] Progress while updating

by Camillo Bruni

I cannot reproduce it I used http://pharo.gforge.inria.fr/ci/image/20/20559.zip and updated, there was clearly a progress bar visible. However it only starts once it loads Monticello data. On 2013-02-20, at 14:38, "Torsten Bergmann" <astares(a)gmx.de> wrote: > When updating from Pharo2.0a Latest update: #20559 > to Pharo2.0a Latest update: #20560 > > There is no progress bar visible. > > I'm not sure - in #20557 there was a change on progress bar > and the issue http://code.google.com/p/pharo/issues/detail?id=7110 > does not really describe what the problem really was that have > been solved. > > Thanks > T. > > >

Feb. 20, 2013

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

by Guillermo Polito

Yes, because the vm crash is caused by the lost of the active process... On Wed, Feb 20, 2013 at 2:44 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 20 February 2013 14:37, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > > > > > On Wed, Feb 20, 2013 at 2:23 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> > >> but aside of making things work, > >> i really wonder why become on methods makes VM crash. > >> we should have an easily reproducible case for study. > > > > > > These? > > > > (Delay class>>#handleTimerEvent) setSourcePosition: 200 inFile: 1 > > > > this one shows "computation has terminated" > its not crashing my VM.. > this happens when context has no sender to return to (sender is nil) > > > (ProcessorScheduler class>>#idleProcess) setSourcePosition: 200 inFile: 1 > > this one crashing.. but still showing the same "computation has > terminated" dialog before. > > > > >> > >> > >> > >> -- > >> Best regards, > >> Igor Stasenko. > >> > > > > > > -- > Best regards, > Igor Stasenko. > >

Feb. 20, 2013

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

by Igor Stasenko

On 20 February 2013 14:37, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > On Wed, Feb 20, 2013 at 2:23 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> but aside of making things work, >> i really wonder why become on methods makes VM crash. >> we should have an easily reproducible case for study. > > > These? > > (Delay class>>#handleTimerEvent) setSourcePosition: 200 inFile: 1 > this one shows "computation has terminated" its not crashing my VM.. this happens when context has no sender to return to (sender is nil) > (ProcessorScheduler class>>#idleProcess) setSourcePosition: 200 inFile: 1 this one crashing.. but still showing the same "computation has terminated" dialog before. > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

Feb. 20, 2013

[Pharo-project] Progress while updating

by Torsten Bergmann

When updating from Pharo2.0a Latest update: #20559 to Pharo2.0a Latest update: #20560 There is no progress bar visible. I'm not sure - in #20557 there was a change on progress bar and the issue http://code.google.com/p/pharo/issues/detail?id=7110 does not really describe what the problem really was that have been solved. Thanks T.

Feb. 20, 2013

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

by Guillermo Polito

On Wed, Feb 20, 2013 at 2:23 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > but aside of making things work, > i really wonder why become on methods makes VM crash. > we should have an easily reproducible case for study. > These? (Delay class>>#handleTimerEvent) setSourcePosition: 200 inFile: 1 (ProcessorScheduler class>>#idleProcess) setSourcePosition: 200 inFile: 1 > > > -- > Best regards, > Igor Stasenko. > >

Feb. 20, 2013