March 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Here's my problems...

by Igor Stasenko

So far so good.. found DNU: Utilities noteMethodSubmission: #Comment forClass: cls while filing in the .st code -- Best regards, Igor Stasenko AKA sig.

March 19, 2010

Re: [Pharo-project] why we should ban as yet unclassified categories from the core....

by Alexandre Bergel

>> >> We should get the same for pharo, the beauty of the system should >> shout at you: I wan to be clean. >> Write class comments..... >> >> Quality is also in the details because everything is in synergy. > > +1 +1 Alexandre > > Adrian > >> >> Stef >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 19, 2010

Re: [Pharo-project] RefactoringManager and RBNamepsace error?

by Lukas Renggli

There seem to be some serious bugs when performing a sequence of renames. I added (a modified version) of your test and fixed the problem in: Name: Refactoring-Core-lr.115 Author: lr Time: 19 March 2010, 1:36:35 pm UUID: 89f629b7-df37-4545-b795-87c5b78e1127 Ancestors: Refactoring-Core-lr.114, Refactoring-Core-lr.113 - fixed some bugs and added some tests when renaming a class multiple times Name: Refactoring-Tests-Core-lr.35 Author: lr Time: 19 March 2010, 1:36 pm UUID: a2c9c388-a1b1-4f7a-a749-f3d658c42779 Ancestors: Refactoring-Tests-Core-lr.33 - fixed some bugs and added some tests when renaming a class multiple times Lukas 2010/3/19 Fernando olivero <oliverof(a)lu.unisi.ch>: > Lukas, i have the following problem: > model Â := RBNamespace new. > Then executing successive RenameRefactoring's using the same model yields an > Error. > 1. ClassA -> ClassA2 OK > 2. ClassA2 -> ClassA3 OK > 3. ClassA3 -> ClassA4Â ERROR! > > I've tracked it down to this: > 1. > RenameRefactoring>>execute > self primitiveExecute. > RefactoringManager instance addRefactoring: self > 2. > RefactoringManager>>addRefactoring: aRefactoring > RefactoryChangeManager instance performChange: aRefactoring changes. > refactorings add: aRefactoring class name > 3. > Refactoring>>changes > ^self model changes > which answers all the changes! > {Â ClassA rename: #ClassA2! > Â ClassA2 rename: #ClassA3! > ClassA3 rename: #ClassA4!Â } > Why does a particular refactoring answers all the models changes? And not > just the ones it introduced? > The problem is in #performChange: will apply over and over all the changes, > and not just the last one. > > Lukas, do you think i'm incorrectly using the namespace and refactoring's? > Â Are namespace supposed to be used once and later ditched? > My goal is to have a GauchoSystem which nows all the changes (with undos!) > that have happened, that's why i'm using always the same namespace. > > Thanks, > Fernando > > pd: a test that reproduces the problem. > >>>testSucessiveRefactoringsError > | namespace | > namespace := Â RBNamespace new. > [ > | refactoring| > Object subclass: 'ClassA' asSymbol > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'TestingNamespaces1234'. > refactoring := RenameClassRefactoring > model: namespace > rename: (Smalltalk classNamed: 'ClassA' asSymbol ) > to: 'ClassA2' asSymbol . > refactoring execute. > refactoring := RenameClassRefactoring > model: namespace > rename: Â (Smalltalk classNamed:'ClassA2' asSymbol ) > to: Â 'ClassA3' asSymbol. > refactoring execute. > refactoring := RenameClassRefactoring > model: namespace > rename: Â (Smalltalk classNamed: 'ClassA3' asSymbol ) > to: Â 'ClassA4' asSymbol. > self shouldnt:[refactoring execute] raise: Error description: 'Valid > refactoring should not raise error'. > ] ensure:[ Â SystemOrganization removeSystemCategory: 'TestingNamespaces1234' > ] > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

March 19, 2010

Re: [Pharo-project] Here's my problems...

by Igor Stasenko

Okay! I updated to the latest Pharo-Core! Image not hangs anymore. Pressing 'install' of changeset still having same problem in file browser as before. -- Best regards, Igor Stasenko AKA sig.

March 19, 2010

Re: [Pharo-project] Here's my problems...

by Henrik Johansen

On Mar 19, 2010, at 12:42 24PM, Igor Stasenko wrote: > my mistake, that i'm using old image... > > its a bit confusing that pharo-dev images downloads listed first > and they are pretty outdated. > > I just loaded PhaoCore1.1.-11268 > will try there. > At least , pressing Alt-. no longer hangs an image > -- > Best regards, > Igor Stasenko AKA sig. Agreed, 1.1Core downloads are waaaaay down there :( As for why the interrupt makes image unresponsive, iirc, there was something in the debugger which needed reinitialization after the new WeakSet was imported. Can't remember what off the tip of my head though... Cheers, Henry

March 19, 2010

Re: [Pharo-project] Here's my problems...

by GARY CHAMBERS

Try "Object reInitializeDependentsFields" first... it may help. Regards, Gary ________________________________ From: Igor Stasenko <siguctua(a)gmail.com> To: Pharo-project(a)lists.gforge.inria.fr Sent: Friday, 19 March, 2010 10:37:58 Subject: Re: [Pharo-project] Here's my problems... On 19 March 2010 11:48, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Mar 19, 2010, at 10:07 20AM, Igor Stasenko wrote: > >> I tried different VM >> http://gforge.inria.fr/frs/download.php/26654/PharoVM-Win32-3.11.8.zip >> after 40 minutes of updating , i got an error, and still were unable to do anything , because image can't react on any events :( >> no changes... >> >> >> Any ideas why interrupt key makes image unresponsive? >> >> -- >> Best regards, >> Igor Stasenko AKA sig. > > http://code.google.com/p/pharo/issues/detail?id=1628 > > Update your image. > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 19, 2010

Re: [Pharo-project] Here's my problems...

by Igor Stasenko

my mistake, that i'm using old image... its a bit confusing that pharo-dev images downloads listed first and they are pretty outdated. I just loaded PhaoCore1.1.-11268 will try there. At least , pressing Alt-. no longer hangs an image -- Best regards, Igor Stasenko AKA sig.

March 19, 2010

Re: [Pharo-project] RefactoringManager and RBNamepsace error?

by Fernando olivero

Get it now! Thanks for the clarification. On Mar 19, 2010, at 11:56 AM, Lukas Renggli wrote: > 2010/3/19 Fernando olivero <oliverof(a)lu.unisi.ch>: >> Lukas, i have the following problem: >> model := RBNamespace new. >> Then executing successive RenameRefactoring's using the same model yields an >> Error. >> 1. ClassA -> ClassA2 OK >> 2. ClassA2 -> ClassA3 OK >> 3. ClassA3 -> ClassA4 ERROR! >> >> I've tracked it down to this: >> Lukas, do you think i'm incorrectly using the namespace and refactoring's? > > Yeah, probably you are using it incorrectly. > > Just call #primtiveExecute on the refactoring if you only want to > apply it to the RBNamespace model. > >> Are namespace supposed to be used once and later ditched? > > RBNamespace provides a view on the system that can be manipulated > without touching the actual system. The class has a horrible name, it > should rather be called RBSmalltalkModel or something. After several > operations all the changes can then be applied in a single "atomic" > operation using: > > aNamespace changes execute > >> My goal is to have a GauchoSystem which nows all the changes (with undos!) >> that have happened, that's why i'm using always the same namespace. > > RBNamespace is a delta to the real system. You don't want to keep it > around for too long. You perform some operations on it, you commit > them to the image, and then you use a new instance. That's the basic > workflow. > > The undoes are kept separate in RefactoryChangeManager. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 19, 2010

Re: [Pharo-project] Here's my problems...

by Igor Stasenko

THERE_BE_DRAGONS_HERE MessageNotUnderstood: AnObsoletePreferences class>>preferenceAt:ifAbsent: 19 March 2010 1:23:52 pm VM: Win32 - IX86 - NT - Squeak3.10.2 of 11 February 2010 [latest update: #9314] Image: PharoCore1.1ALPHA [Latest update: #11146] AnObsoletePreferences class(Object)>>doesNotUnderstand: #preferenceAt:ifAbsent: Receiver: AnObsoletePreferences Arguments and temporary variables: On 19 March 2010 12:37, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 19 March 2010 11:48, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >> >> On Mar 19, 2010, at 10:07 20AM, Igor Stasenko wrote: >> >>> I tried different VM >>> http://gforge.inria.fr/frs/download.php/26654/PharoVM-Win32-3.11.8.zip >>> > after 40 minutes of updating , i got an error, and > still were unable to do anything , because image can't react on any events :( > >>> no changes... >>> >>> >>> Any ideas why interrupt key makes image unresponsive? >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >> >> http://code.google.com/p/pharo/issues/detail?id=1628 >> >> Update your image. >> >> Cheers, >> Henry >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

March 19, 2010

Re: [Pharo-project] RefactoringManager and RBNamepsace error?

by Lukas Renggli

2010/3/19 Fernando olivero <oliverof(a)lu.unisi.ch>: > Lukas, i have the following problem: > model Â := RBNamespace new. > Then executing successive RenameRefactoring's using the same model yields an > Error. > 1. ClassA -> ClassA2 OK > 2. ClassA2 -> ClassA3 OK > 3. ClassA3 -> ClassA4Â ERROR! > > I've tracked it down to this: > Lukas, do you think i'm incorrectly using the namespace and refactoring's? Yeah, probably you are using it incorrectly. Just call #primtiveExecute on the refactoring if you only want to apply it to the RBNamespace model. >Â Are namespace supposed to be used once and later ditched? RBNamespace provides a view on the system that can be manipulated without touching the actual system. The class has a horrible name, it should rather be called RBSmalltalkModel or something. After several operations all the changes can then be applied in a single "atomic" operation using: aNamespace changes execute > My goal is to have a GauchoSystem which nows all the changes (with undos!) > that have happened, that's why i'm using always the same namespace. RBNamespace is a delta to the real system. You don't want to keep it around for too long. You perform some operations on it, you commit them to the image, and then you use a new instance. That's the basic workflow. The undoes are kept separate in RefactoryChangeManager. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 19, 2010