- Pharo-dev - lists.pharo.org

Re: [Pharo-project] ESUG selected as GSoC 2010 mentoring organization!!!!

by Mariano Martinez Peck

Hi Smalltalkers! Maybe you are not aware of what our selection to this year GSoC really means for the Smalltalk community. And I wasn't aware completely until few hours. Just to give you an example, even such big organizations like Ruby or PHP where not selected. From this viewpoint you can see what we have achieved. Some people said and still says that Smalltalk is old and that it is dead. Ok, we have been selected by the major Informatics and Software company all over the world. The point is that ESUG and the Smalltalk community was selected because of the seriousness mixed with passion of all the application, project and ideas. We have an incredible high quality list of ideas and mentors. We have a unique opportunity to show the rest of the world why we love Smalltalk, why it is much better than other alternatives, etc. So, we invite all of you to make this happens. Thanks to everybody for all the congratulations and nice words!!! Your GSoC admins esug.gsoc.adm2010(a)gmail.com http://gsoc2010.esug.org On Thu, Mar 18, 2010 at 11:33 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > We are incredibly proud to announce that ESUG was selected for the GSoC > 2010. We have a long list of wonderful projects, mentors and a cool website. > > > We want to thank you to all the people who help us publishing project > ideas, giving feedback on the submit text or the English, etc. > > For the moment, we don't know the slots (amount of projects) that we will > receive. > > Don't worry. We will contact you again very soon to let you know the > following steps. > > Now, prepare yourself. We have to show the rest of the world why we love > Smalltalk so much :) > > Thank you very much. > > The very happy GSoC admin team >

March 19, 2010

[Pharo-project] Sets with nils using SetElement(s)

by Igor Stasenko

i added a changesets into a corresponding tracker issue (#1907) please, be advised, that in Squeak it was adopted after HashedCollection refactoring. And a scope of changes is wider than my own (it includes KeyedSet and KeyedIdentitySet, which i haven't touched before). Still, all tests are green, except there is unimplemented #errorNoFreeSpace , which can be found in trunk's HashedCollection ). -- Best regards, Igor Stasenko AKA sig.

March 19, 2010

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