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

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

Re: [Pharo-dev] Pharo hangout analysis

by Facundo Vozzi

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. 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

Re: [Pharo-dev] unloading Nautilus

by StÃ©phane Ducasse

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] unloading Nautilus

by StÃ©phane Ducasse

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 7: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? Yes it would be good. And we should use larger fonts. I do not get why I could not hear people talking but this is another story :) stef > > cheers, > Esteban

Oct. 2, 2013

Pharo hangout analysis

by Esteban Lorenzano

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