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

Re: [Pharo-dev] new bug in RPackage

by Esteban Lorenzano

I'm so tired of RPackage... :( On Oct 2, 2013, at 9:36 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > In fact what is intriguing is that > > RPackageOrganizer default > packageNamed: 'Refactoring-Core' > > in the image used to generate the configuration > > classExtensionSelectors is correct defined > a Dictionary(#ClassTrait->a Set(#soleInstance) #TClassDescription->a Set(#whichSelectorsReallyRead:) ) > > So either the package is wrongly saved but this is not the case. > Or while reloading it the logic is wrong. May be it should not raise systemMethodRecategorizedActionFrom: > because it may be not be a recatogiration (or may be it was a override). > > Stef > > > > On Oct 2, 2013, at 9:28 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > >> esteban >> >> tomorrow I can show you the bug I found. >> >> during the test of the correct reloading of RB >> >> (ConfigurationOfRefactoring project version: #stable) load >> >> in my noNautilus and no RB I got >> >> >> systemMethodRecategorizedActionFrom: ann >> "a protocol has been renamed >> a method has been removed. // WILL BE TREATED WITH SystemMethodRemovedAnnouncement >> a method has been moved to another category >> -maybe from the classic category to an extending package >> -maybe from an extending package to another extending package >> -maybe from an extending package to a classic category >> - maybe from a classic category to another classic category" >> >> | oldProtocol newProtocol method methodPackage destinationPackage | >> >> oldProtocol := ann oldProtocol. >> "old protocol might be nil:" >> oldProtocol asString ifNil: [oldProtocol := '']. >> newProtocol := ann newProtocol. >> method := ann methodRecategorized. >> >> "1). See compiledMethod >> packageFromOrganizer:" >> >> "we have to pay attention that this announcement can come from TraitDescription>>updateOrganizationSelector:oldCategory:newCategory: . In this context, it can happen that the method referenced by the event is nil. In this case I think we should change nothing" >> >> >> method isNil ifFalse: [ >> "If the method origin is not the one of the event, we do not care about that method" >> method origin = ann methodClass ifFalse: [^ self]. >> >> methodPackage := method packageFromOrganizer: self. >> "if newProtocol is nil, it means that we are in a 'methodRemoved' case. Nothing should be modified (all the work will be done when catching methodRemovedAnnouncement) " >> newProtocol isNil ifTrue: [^self]. >> "it can happen that oldProtocol is Nil. in this case we should do nothing" >> oldProtocol ifNil: [^ self]. >> "maybe the category has changed" >> newProtocol asLowercase = oldProtocol asLowercase >> ifFalse: [ >> "according the extension specified is valid or not, the method will be defined as an extension of an external package or in the class parent package" >> destinationPackage := (self hasPackageForProtocol: newProtocol inClass: method methodClass) >> ifTrue: [ self packageForProtocol: newProtocol inClass: method methodClass ] >> ifFalse: [ >> (newProtocol beginsWith: '*') >> ifTrue: [ self ensureExistAndRegisterPackageNamed: newProtocol allButFirst capitalized ] >> ifFalse: [ method methodClass package ] ]. >> methodPackage := (self hasPackageForProtocol: oldProtocol inClass: method methodClass) >> ifTrue: [ self packageForProtocol: oldProtocol inClass: method methodClass ] >> ifFalse: [ method methodClass package ]. >> >> "then, we will remove the method from the method package, and add it to the destination package (we check before that the source package and the destination package are different)." >> methodPackage = destinationPackage >> ifFalse: [ >> (methodPackage methods includes: method) >> ifTrue: [ methodPackage removeMethod: method ]. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> where method was ClassTrait>>#soleInstance and apparently it does not exit raising an error >> >> classDefinitionSelectors in RPackage is >> a Set(#instanceVariableNames: #classTrait #copy #adoptInstance:from: #compile:classified:withStamp:notifying:logSource: #baseTrait #name #baseTrait: #isClassTrait #definition #classTrait: #initializeWithBaseTrait: #new #isBaseTrait) >> >> classExtensionSelectors is Set new >> and after investigation: >> soleInstance on ClassTrait is defined as an extension on *refactoring-core >> => >> >> >> >> destinationPackage addMethod: method. >> >> SystemAnnouncer uniqueInstance >> methodRepackaged: method >> from: methodPackage >> to: destinationPackage. >> ] >> ] >> ] > >

Oct. 2, 2013

Re: [Pharo-dev] [update 3.0] #30439

by StÃ©phane Ducasse

Thanks marcus! This is cool to see all the enhancements. Stef On Oct 2, 2013, at 9:40 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 30439 > ----- > > 11748 ConfigurationCommandLineHandler should allow multiple groups > https://pharo.fogbugz.com/f/cases/11748 > > 11747 Delete working copy of RB-Pharo-Platform > https://pharo.fogbugz.com/f/cases/11747 > > 11744 some themes are abstract > https://pharo.fogbugz.com/f/cases/11744 > > > Diff information: > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-MarcusDenke… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/ConfigurationCommandLineHandl… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/ConfigurationCommandLineHandl… >

Oct. 2, 2013

Re: [Pharo-dev] Glorp, Fuel, Native postgres driver, Voyage/Mongo, any in GemStone?

by Sven Van Caekenberghe

Mariano, On 02 Oct 2013, at 20:49, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi guys. > First, let me apologize for the amount of emails I am sending. I am doing an analysis to see if GemStone is a good candidate for a project I am working and so it deserves some research. > > I wondered if any has ever tried porting any of these tools to GemStone: Fuel, Glorp, Native PostgreSQL driver, Voyage and MongoDB. I do not understand. IMHO there is only one reason to go to Gemstone, and that is to use its capabilities as OODB. All the technologies you mention are persistency related and would not be needed in that case, right ? As you most probably know, you can get pretty far with Pharo. After that, there is load-balancing, partitioning, message queues. Pretty much what any technology stack does. You will always find more tools and libraries on the Pharo side, as the community is much larger. Sven > Thanks a lot in advance, > > -- > Mariano > http://marianopeck.wordpress.com

Oct. 2, 2013

[update 3.0] #30439

by Marcus Denker

30439 ----- 11748 ConfigurationCommandLineHandler should allow multiple groups https://pharo.fogbugz.com/f/cases/11748 11747 Delete working copy of RB-Pharo-Platform https://pharo.fogbugz.com/f/cases/11747 11744 some themes are abstract https://pharo.fogbugz.com/f/cases/11744 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/ConfigurationCommandLineHandl… http://smalltalkhub.com/mc/Pharo/Pharo30/main/ConfigurationCommandLineHandl…

Oct. 2, 2013

Re: [Pharo-dev] new bug in RPackage

by StÃ©phane Ducasse

In fact what is intriguing is that RPackageOrganizer default packageNamed: 'Refactoring-Core' in the image used to generate the configuration classExtensionSelectors is correct defined a Dictionary(#ClassTrait->a Set(#soleInstance) #TClassDescription->a Set(#whichSelectorsReallyRead:) ) So either the package is wrongly saved but this is not the case. Or while reloading it the logic is wrong. May be it should not raise systemMethodRecategorizedActionFrom: because it may be not be a recatogiration (or may be it was a override). Stef On Oct 2, 2013, at 9:28 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > esteban > > tomorrow I can show you the bug I found. > > during the test of the correct reloading of RB > > (ConfigurationOfRefactoring project version: #stable) load > > in my noNautilus and no RB I got > > > systemMethodRecategorizedActionFrom: ann > "a protocol has been renamed > a method has been removed. // WILL BE TREATED WITH SystemMethodRemovedAnnouncement > a method has been moved to another category > -maybe from the classic category to an extending package > -maybe from an extending package to another extending package > -maybe from an extending package to a classic category > - maybe from a classic category to another classic category" > > | oldProtocol newProtocol method methodPackage destinationPackage | > > oldProtocol := ann oldProtocol. > "old protocol might be nil:" > oldProtocol asString ifNil: [oldProtocol := '']. > newProtocol := ann newProtocol. > method := ann methodRecategorized. > > "1). See compiledMethod >> packageFromOrganizer:" > > "we have to pay attention that this announcement can come from TraitDescription>>updateOrganizationSelector:oldCategory:newCategory: . In this context, it can happen that the method referenced by the event is nil. In this case I think we should change nothing" > > > method isNil ifFalse: [ > "If the method origin is not the one of the event, we do not care about that method" > method origin = ann methodClass ifFalse: [^ self]. > > methodPackage := method packageFromOrganizer: self. > "if newProtocol is nil, it means that we are in a 'methodRemoved' case. Nothing should be modified (all the work will be done when catching methodRemovedAnnouncement) " > newProtocol isNil ifTrue: [^self]. > "it can happen that oldProtocol is Nil. in this case we should do nothing" > oldProtocol ifNil: [^ self]. > "maybe the category has changed" > newProtocol asLowercase = oldProtocol asLowercase > ifFalse: [ > "according the extension specified is valid or not, the method will be defined as an extension of an external package or in the class parent package" > destinationPackage := (self hasPackageForProtocol: newProtocol inClass: method methodClass) > ifTrue: [ self packageForProtocol: newProtocol inClass: method methodClass ] > ifFalse: [ > (newProtocol beginsWith: '*') > ifTrue: [ self ensureExistAndRegisterPackageNamed: newProtocol allButFirst capitalized ] > ifFalse: [ method methodClass package ] ]. > methodPackage := (self hasPackageForProtocol: oldProtocol inClass: method methodClass) > ifTrue: [ self packageForProtocol: oldProtocol inClass: method methodClass ] > ifFalse: [ method methodClass package ]. > > "then, we will remove the method from the method package, and add it to the destination package (we check before that the source package and the destination package are different)." > methodPackage = destinationPackage > ifFalse: [ > (methodPackage methods includes: method) > ifTrue: [ methodPackage removeMethod: method ]. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > where method was ClassTrait>>#soleInstance and apparently it does not exit raising an error > > classDefinitionSelectors in RPackage is > a Set(#instanceVariableNames: #classTrait #copy #adoptInstance:from: #compile:classified:withStamp:notifying:logSource: #baseTrait #name #baseTrait: #isClassTrait #definition #classTrait: #initializeWithBaseTrait: #new #isBaseTrait) > > classExtensionSelectors is Set new > and after investigation: > soleInstance on ClassTrait is defined as an extension on *refactoring-core > => > > > > destinationPackage addMethod: method. > > SystemAnnouncer uniqueInstance > methodRepackaged: method > from: methodPackage > to: destinationPackage. > ] > ] > ]

Oct. 2, 2013

new bug in RPackage

by StÃ©phane Ducasse

esteban tomorrow I can show you the bug I found. during the test of the correct reloading of RB (ConfigurationOfRefactoring project version: #stable) load in my noNautilus and no RB I got systemMethodRecategorizedActionFrom: ann "a protocol has been renamed a method has been removed. // WILL BE TREATED WITH SystemMethodRemovedAnnouncement a method has been moved to another category -maybe from the classic category to an extending package -maybe from an extending package to another extending package -maybe from an extending package to a classic category - maybe from a classic category to another classic category" | oldProtocol newProtocol method methodPackage destinationPackage | oldProtocol := ann oldProtocol. "old protocol might be nil:" oldProtocol asString ifNil: [oldProtocol := '']. newProtocol := ann newProtocol. method := ann methodRecategorized. "1). See compiledMethod >> packageFromOrganizer:" "we have to pay attention that this announcement can come from TraitDescription>>updateOrganizationSelector:oldCategory:newCategory: . In this context, it can happen that the method referenced by the event is nil. In this case I think we should change nothing" method isNil ifFalse: [ "If the method origin is not the one of the event, we do not care about that method" method origin = ann methodClass ifFalse: [^ self]. methodPackage := method packageFromOrganizer: self. "if newProtocol is nil, it means that we are in a 'methodRemoved' case. Nothing should be modified (all the work will be done when catching methodRemovedAnnouncement) " newProtocol isNil ifTrue: [^self]. "it can happen that oldProtocol is Nil. in this case we should do nothing" oldProtocol ifNil: [^ self]. "maybe the category has changed" newProtocol asLowercase = oldProtocol asLowercase ifFalse: [ "according the extension specified is valid or not, the method will be defined as an extension of an external package or in the class parent package" destinationPackage := (self hasPackageForProtocol: newProtocol inClass: method methodClass) ifTrue: [ self packageForProtocol: newProtocol inClass: method methodClass ] ifFalse: [ (newProtocol beginsWith: '*') ifTrue: [ self ensureExistAndRegisterPackageNamed: newProtocol allButFirst capitalized ] ifFalse: [ method methodClass package ] ]. methodPackage := (self hasPackageForProtocol: oldProtocol inClass: method methodClass) ifTrue: [ self packageForProtocol: oldProtocol inClass: method methodClass ] ifFalse: [ method methodClass package ]. "then, we will remove the method from the method package, and add it to the destination package (we check before that the source package and the destination package are different)." methodPackage = destinationPackage ifFalse: [ (methodPackage methods includes: method) ifTrue: [ methodPackage removeMethod: method ]. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ where method was ClassTrait>>#soleInstance and apparently it does not exit raising an error classDefinitionSelectors in RPackage is a Set(#instanceVariableNames: #classTrait #copy #adoptInstance:from: #compile:classified:withStamp:notifying:logSource: #baseTrait #name #baseTrait: #isClassTrait #definition #classTrait: #initializeWithBaseTrait: #new #isBaseTrait) classExtensionSelectors is Set new and after investigation: soleInstance on ClassTrait is defined as an extension on *refactoring-core => destinationPackage addMethod: method. SystemAnnouncer uniqueInstance methodRepackaged: method from: methodPackage to: destinationPackage. ] ] ]

Oct. 2, 2013

Re: [Pharo-dev] MNU SpecLayout>>hasSlots

by Benjamin

I had the same once while trying to remove an inst var :s I change the image :P Ben On Oct 2, 2013, at 8:40 PM, btc(a)openinworld.com wrote: > I got to get offline right now so this is just a quick note for something I just noticed rather than a full bug report (since it may be a high priority to someone - though it may already have been noticed) > > In PharoLauncher #400, Pharo #30438, trying to add an instance variable to the PharoLauncher class generates a MNU SpecLayout>>hasSlots. > > got to head off, > cheers -ben >

Oct. 2, 2013

IDE Nice idea

by Torsten Bergmann

>Did you try "Groups" for that ? Yes, it is useful - but unfortunately not the same power and fast workflow. Even the TestRunner is able to filter its category list. I really do not understand why the filter was it removed from Nautilus instead of making it optional (via setting). Bye T.

Oct. 2, 2013

Glorp, Fuel, Native postgres driver, Voyage/Mongo, any in GemStone?

by Mariano Martinez Peck

Hi guys. First, let me apologize for the amount of emails I am sending. I am doing an analysis to see if GemStone is a good candidate for a project I am working and so it deserves some research. I wondered if any has ever tried porting any of these tools to GemStone: Fuel, Glorp, Native PostgreSQL driver, Voyage and MongoDB. Thanks a lot in advance, -- Mariano http://marianopeck.wordpress.com

Oct. 2, 2013

Re: [Pharo-dev] unloading Nautilus

by StÃ©phane Ducasse

So victory I could unload completely Nautilus and RB :) Now I will be able to reload it and I will add some unload methods to the configurations and also to key classes. I think that configuration should have a protocol for that. I do not think that we should continue to not have configuration in the image because configurations are project metadata. to reproduce: rename Nautilus-History into History (MCWorkingCopy forPackage: (MCPackage named: 'NautilusRefactoring')) unload. Nautilus cleanUp. KMRepository reset. KMPragmaKeymapBuilder release. NautilusUI allInstances do: [ :inst | SystemAnnouncer uniqueInstance unsubscribe: inst]. Smalltalk garbageCollect. (MCWorkingCopy forPackage: (MCPackage named: 'NautilusCommon')) unload. (MCWorkingCopy forPackage: (MCPackage named: 'Nautilus')) unload. (MCWorkingCopy forPackage: (MCPackage named: 'Refactoring-Tests-Critics')) unload. (MCWorkingCopy forPackage: (MCPackage named: 'Refactoring-Tests-Core')) unload. (MCWorkingCopy forPackage: (MCPackage named: 'Refactoring-Tests-Environment')) unload. (MCWorkingCopy forPackage: (MCPackage named: 'Refactoring-Tests-Changes')) unload. (MCWorkingCopy forPackage: (MCPackage named: 'Refactoring-Spelling')) unload. (MCWorkingCopy forPackage: (MCPackage named: 'Refactoring-Critics')) unload. (MCWorkingCopy forPackage: (MCPackage named: 'Refactoring-Pharo-Platform')) unload. (MCWorkingCopy forPackage: (MCPackage named: 'Refactoring-Changes')) unload. (MCWorkingCopy forPackage: (MCPackage named: 'Refactoring-Core')) unload. (MCWorkingCopy forPackage: (MCPackage named: 'Refactoring-Environment')) unload. Stef

Oct. 2, 2013