- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] unloading Nautilus

by Camillo Bruni

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

unloading Nautilus

by StÃ©phane Ducasse

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

Oct. 2, 2013

Re: [Pharo-dev] Any visualisation for Metacello?

by StÃ©phane Ducasse

metaceller in the moose image maybe On Oct 2, 2013, at 6:29 PM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > Hi, > > I have to deal with complex configurations involving Pier (and some of > its plugins), Magritte, Voyage, Mongo and Seaside. There is a bug > somewhere because I can't load all of that. Is there any tool that > would show me a graph of the projects and their dependencies? If there > is no graph, is there at least some place to get the information? I > know the #record + #loadDirective combo, but I don't understand the > result and it does not help. > > Best > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill >

Oct. 2, 2013

Any visualisation for Metacello?

by Damien Cassou

Hi, I have to deal with complex configurations involving Pier (and some of its plugins), Magritte, Voyage, Mongo and Seaside. There is a bug somewhere because I can't load all of that. Is there any tool that would show me a graph of the projects and their dependencies? If there is no graph, is there at least some place to get the information? I know the #record + #loadDirective combo, but I don't understand the result and it does not help. Best -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Oct. 2, 2013

Re: [Pharo-dev] IDE Nice idea

by StÃ©phane Ducasse

On Oct 2, 2013, at 6:11 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > I wouldn't be happy with today's VW browser as well, given the screenshots seen in ESUG presentations ;) I can't work with a browser which expect me to use it full screen on the 11"6 screen of my laptop; I really need the three browsers: code ref, code I'm writing, code using my code. at least 3 :) Stef

Oct. 2, 2013