- Pharo-dev - lists.pharo.org

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

MNU SpecLayout>>hasSlots

by btc＠openinworld.com

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

Re: [Pharo-dev] unloading Nautilus

by Benjamin

The things is that with Nautilus, I pushed more than just Nautilus in the system, like the groups mechanism, the history etc Now, they should be pushed out of Nautilus since there may be (are) used in other part of the system. We should do this clean up phase on all the new tools I think :) (By example NewValueHolder is still part of Spec, where it should be pushed in Tools or something) Ben On Oct 2, 2013, at 8:26 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > So I moved Nautilus-History and retried and I could get a debugger with some announcements not reset > So some progress. I will publish a separate package for History > > Stef > > On Oct 2, 2013, at 8:19 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > >> Linking the inspector with nautilus is not a good idea to me. >> Because at the end we can joke the old squeak by saying that it was monolithic but we are building the same. >> >> So now I cannot unload Nautilus because when I remove it, it removes NavigationHistory that is used by the inspector and >> I do not understand why something is failing -> debugger -> fialure of debugger. >> Stef >> >>> Ok >>> I will check now I do not even understand why and how it is related. >>> >>> Stef >>> >>>> it's the inspector, not nautilus. >>>> >>>> => InspectorNavigator >> pushHistory: >>>> >>>> On 2013-10-02, at 19:20, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> >>>>> When I try >>>>> >>>>> (MCWorkingCopy forPackage: (MCPackage named: 'NautilusRefactoring')) unload >>>>> >>>>> NautilusUI allInstances do: [ :inst | >>>>> SystemAnnouncer uniqueInstance unsubscribe: inst]. >>>>> Smalltalk garbageCollect. >>>>> >>>>> (MCWorkingCopy forPackage: (MCPackage named: 'NautilusCommon')) unload. >>>>> (MCWorkingCopy forPackage: (MCPackage named: 'Nautilus')) unload >>>>> >>>>> I get the attached system. I do not understand why SpecDebugger has something to do with navigationHistory. >>>>> >>>>> Any idea? >>>>> I also think that we are not good at making sure what we load can be cleanly unloaded. Without that discipline we will never have >>>>> a modular system. >>>>> >>>>> Stef >>>>> >>>>> >>>>> <Screen Shot 2013-10-02 at 7.04.02 PM.pdf> >>>> >>> >>> >> >> > >

Oct. 2, 2013

Could we have a list of the official pragmas because it starts to be a MESS!

by StÃ©phane Ducasse

For example <systemEventRegistration> I have no idea (of course there is no comment) what is the use of this pragma. Chasing pragma interpreter can be painful so we should pay attention. Too many pragmas are a plague. Stef

Oct. 2, 2013

Re: [Pharo-dev] unloading Nautilus

by StÃ©phane Ducasse

So I moved Nautilus-History and retried and I could get a debugger with some announcements not reset So some progress. I will publish a separate package for History Stef On Oct 2, 2013, at 8:19 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > Linking the inspector with nautilus is not a good idea to me. > Because at the end we can joke the old squeak by saying that it was monolithic but we are building the same. > > So now I cannot unload Nautilus because when I remove it, it removes NavigationHistory that is used by the inspector and > I do not understand why something is failing -> debugger -> fialure of debugger. > Stef > >> Ok >> I will check now I do not even understand why and how it is related. >> >> Stef >> >>> it's the inspector, not nautilus. >>> >>> => InspectorNavigator >> pushHistory: >>> >>> On 2013-10-02, at 19:20, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>>> When I try >>>> >>>> (MCWorkingCopy forPackage: (MCPackage named: 'NautilusRefactoring')) unload >>>> >>>> NautilusUI allInstances do: [ :inst | >>>> SystemAnnouncer uniqueInstance unsubscribe: inst]. >>>> Smalltalk garbageCollect. >>>> >>>> (MCWorkingCopy forPackage: (MCPackage named: 'NautilusCommon')) unload. >>>> (MCWorkingCopy forPackage: (MCPackage named: 'Nautilus')) unload >>>> >>>> I get the attached system. I do not understand why SpecDebugger has something to do with navigationHistory. >>>> >>>> Any idea? >>>> I also think that we are not good at making sure what we load can be cleanly unloaded. Without that discipline we will never have >>>> a modular system. >>>> >>>> Stef >>>> >>>> >>>> <Screen Shot 2013-10-02 at 7.04.02 PM.pdf> >>> >> >> > >

Oct. 2, 2013

Re: [Pharo-dev] Pharo hangout analysis

by StÃ©phane Ducasse

On Oct 2, 2013, at 8:20 PM, Facundo Vozzi <facundov79(a)gmail.com> wrote: > Esteban, > I joined to the hangout session and I think it was ok. I was at my work so I could just heard the conversation, like a radio. Anyway, I watched the handout screen at times and I was interesting. > > I think that could be very interesting to do pair programming on some issues. So, go ahead with it. Maybe, It'll be interesting to let pleople connect to the session, just to see too. > > Regards, > Facu > > ps.: I hope to see you next week in Argentine. The other Esteban (EAM) said to me that you're coming here next week. yes he is :) > > > On Wed, Oct 2, 2013 at 2:55 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > So well... the first Pharo Hangout Session has passed and in my opinion it was not terribly bad :) > There were present people who usually does not show up in the sprints for obvious reasons (they live far from Lille, like in Argentina). > And we more or less worked in fixing bugs and talked about Pharo development, etc. > > No one there worked like that before and we need to acquire more experience to do the kind of things that makes our team work better: we need to learn how to explain our stuff, how to share our screen and do things, etc. > > But I think as a first experience it was very positive. > At least, we could hang (out ;)) and share working context with people that we usually don't. > And I think all presents are a bit more aware of Pharo process now (not a lot more aware, but a bit :) > > So... we will repeat this experience once a month, because I think they are very positive and we will improve them with practice. > But I also would like to add other ideas that came to my mind while sprinting. > > For example, I think we succeed in create the feeling of "all of us are working together" that a sprint has, but we failed in pair program. So I would like to try remote-pair program too. > How can we manage it? well, instead an open sprint, we declare "I want to work on this issue", and we invite people to join... and we join two or three with same interest into a shared screen and with real participation. > > What do you think? > > cheers, > Esteban >

Oct. 2, 2013