Lukas Renggli wrote

Maybe you use the wrong browser? AFAIK, only OB implements it.

Ahh, thank you Lukas. It seems like a bug in Keymapping. What do you think, Guillermo? The situation: In 1.2.2, I get anOBSendersBrowser. However in 1.3 rc, from a method definition in OB: - if I choose "Senders" from the menu I get anOBSendersBrowser - but if I hit Cmd-n, I get a FlatMessageListBrowser. The call stack: - without key mapping:

OBTextMorph>>keyStroke: OBTextMorph(TextMorph)>>handleKeystroke: KeyboardEvent>>sentTo: OBTextMorph(Morph)>>handleEvent: OBTextMorph(Morph)>>handleFocusEvent: [ActiveHand := self. ActiveEvent := anEvent. result := focusHolder handleFocusEvent: (anEvent transformedBy: (focusHolder transformedFrom: self))] in HandMorph>>sendFocusEvent:to:clear:

- with Keymapping:

SmalltalkEditor>>sendersOfIt SmalltalkEditor>>sendersOfIt: [editor sendersOfIt: event] in [:editor :morph :event | morph handleKeymappingInteraction: [editor sendersOfIt: event] fromKeyboardEvent: event] in KMEditorsDefaultSettings class>>buildSmalltalkEditorKeymappingsOn: SmalltalkEditor(TextEditor)>>handleKeystrokeAction: SmalltalkEditor(TextEditor)>>handleEditionAction:fromKeyboardEvent: [self editor handleEditionAction: aBlockInteraction fromKeyboardEvent: anEvent] in OBTextMorph(TextMorph)>>handleKeymappingInteraction:fromKeyboardEvent: OBTextMorph(TextMorph)>>handleInteraction: OBTextMorph(TextMorphForEditView)>>handleInteraction: OBTextMorph(TextMorph)>>handleKeymappingInteraction:fromKeyboardEvent: [:editor :morph :event | morph handleKeymappingInteraction: [editor sendersOfIt: event] fromKeyboardEvent: event] in KMEditorsDefaultSettings class>>buildSmalltalkEditorKeymappingsOn:

-- View this message in context: http://forum.world.st/Chasing-Browsers-tp4102608p4157598.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Lukas Renggli wrote

OB. This means, if you select the method and press Cmd+n it should

Bummer, Cmd-n with a method name selected in OB system browser still brings up the non-chasing senders browser. -- View this message in context: http://forum.world.st/Chasing-Browsers-tp4102608p4159064.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Hmm, I'll have a brief look to avoid keymapping to conflict with OB between today and tuesday. I don't think it makes sense to spend any time integrating it with OB (yet) since it's removed from Pharo 1.4. Guille On Mon, Dec 5, 2011 at 3:32 AM, Lukas Renggli <renggli@gmail.com> wrote:

Ok, then it must be something else.

I don't know why this Keymapping thing, but it is unlikely to work with OB if it was not written for OB. As I said, OB managed its keybindings itself.

Lukas

On 5 December 2011 03:51, Sean P. DeNigris <sean@clipperadams.com> wrote:

...

Lukas Renggli wrote

...

OB. This means, if you select the method and press Cmd+n it should

Bummer, Cmd-n with a method name selected in OB system browser still

brings

...

up the non-chasing senders browser.

-- View this message in context: http://forum.world.st/Chasing-Browsers-tp4102608p4159064.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

-- Lukas Renggli www.lukas-renggli.ch

 - then that OB can be loaded on top of Pharo. Remember we are not against OB we just do not have    the knowledge to maintain it. So if lukas gets OB working for 1.4 beta then we will probably include in Pharo.    Now if OB is working for 1.4 only three months after 1.4 is released then we will not include it.

Yes please, do not wait for me. Just to repeat myself: With Pharo 1.4 having uncountable changes in core parts of the system and with the system including more and more forked and increasingly incompatible versions of packages (AST, RB, FS, Shout, Regex, ...) I am unwilling to go through the same pain as with Pharo 1.3 again. In the current state, I don't see any of the code I am involved with (including Seaside, Magritte, Pier, OB, PetitParser, ...) to move forward. I suspect that moving to another development platform soon causes less pain than to move to adopt the next Pharo :-( Lukas -- Lukas Renggli www.lukas-renggli.ch

Hello gentlemen, Let's loosen up a bit, please :). These are important pieces that nobody wants to see remain behind. But, before we go on, we should first identify the root of these concerns. @Lukas: please, could you point out what are the expected problems? For example, all PetitParser-Tests are green out of the box in the latest 1.4. Cheers, Doru On 11 Dec 2011, at 14:58, Stéphane Ducasse wrote:

Thanks for this really bad and sad message. So you are implying that Seaside, Magritte, Pier, OB, PetitParser will not be maintained on Pharo 1.4.

This is important for us to know that and this is a really nice stab in our back and this will kill a lot of the effort we build over the years.

Thanks again lukas! At least this is clear.

Stef

On Dec 11, 2011, at 12:33 PM, Lukas Renggli wrote:

...

...

- then that OB can be loaded on top of Pharo. Remember we are not against OB we just do not have the knowledge to maintain it. So if lukas gets OB working for 1.4 beta then we will probably include in Pharo. Now if OB is working for 1.4 only three months after 1.4 is released then we will not include it.

Yes please, do not wait for me.

Just to repeat myself: With Pharo 1.4 having uncountable changes in core parts of the system and with the system including more and more forked and increasingly incompatible versions of packages (AST, RB, FS, Shout, Regex, ...) I am unwilling to go through the same pain as with Pharo 1.3 again. In the current state, I don't see any of the code I am involved with (including Seaside, Magritte, Pier, OB, PetitParser, ...) to move forward. I suspect that moving to another development platform soon causes less pain than to move to adopt the next Pharo :-(

Lukas

-- Lukas Renggli www.lukas-renggli.ch

-- www.tudorgirba.com "We cannot reach the flow of things unless we let go."

Hi, On 11 Dec 2011, at 15:49, Esteban Lorenzano wrote:

Hi Lukas,

I just loaded Magritte2 into Pharo 1.4 and it loads well with all tests in green. Also, Magritte-Morph loads and seems to run well... just a small change:

replace:

PluggableListMorphOfMany

with:

PluggableListMorph ... beMultipleSelection

Thanks for looking into this :).

(now, I want to deprecate #description for #magritteDescription and add a pragma builder with <magritte> and <magritteContainer> keywords :)

I think that would be most welcome. Cheers, Doru

cheers, Esteban

El 11/12/2011, a las 10:58a.m., Stéphane Ducasse escribió:

...

Thanks for this really bad and sad message. So you are implying that Seaside, Magritte, Pier, OB, PetitParser will not be maintained on Pharo 1.4.

This is important for us to know that and this is a really nice stab in our back and this will kill a lot of the effort we build over the years.

Thanks again lukas! At least this is clear.

Stef

On Dec 11, 2011, at 12:33 PM, Lukas Renggli wrote:

...

...

- then that OB can be loaded on top of Pharo. Remember we are not against OB we just do not have the knowledge to maintain it. So if lukas gets OB working for 1.4 beta then we will probably include in Pharo. Now if OB is working for 1.4 only three months after 1.4 is released then we will not include it.

Yes please, do not wait for me.

Just to repeat myself: With Pharo 1.4 having uncountable changes in core parts of the system and with the system including more and more forked and increasingly incompatible versions of packages (AST, RB, FS, Shout, Regex, ...) I am unwilling to go through the same pain as with Pharo 1.3 again. In the current state, I don't see any of the code I am involved with (including Seaside, Magritte, Pier, OB, PetitParser, ...) to move forward. I suspect that moving to another development platform soon causes less pain than to move to adopt the next Pharo :-(

Lukas

-- Lukas Renggli www.lukas-renggli.ch

-- www.tudorgirba.com "Quality cannot be an afterthought."

All the compilation chain and code management and manipulation tools should be able to work on remote environment. We already discussed and I do not have the time to explain that the design of john was not taking into account that we would like to be able to work with one tool on another environment. The Browser environment = the complete code in the image does not work anymore. Anyway you do not want to change and this is perfect. It is just raging that I do not have enough time to fix it. Now we will see in 1.4 if people want to still use 1.3 or if they have benefit to work with 1.4. We integrated RB because we need to be able to move forward. It would be easy to have two configurations one for 1.3 and one for 1.4 but since you do not want to maintain it when you change your versions then we have to spend more time and frustration but we will do it. I spent a full day the last time while it would have cost you may be 10 min but I have no problem with that since the only thing I can do is to do it, I will do it. We will continue to work and push pharo and people can continue to use it or not. We know where we want to go and we will take responsibility and probably it will burn a bit more of our energy but there is no other paths sadly. Stef On Dec 11, 2011, at 4:42 PM, Lukas Renggli wrote:

...

This is important for us to know that and this is a really nice stab in our back and this will kill a lot of the effort we build over the years.

I don't understand why you think this is a stab into your back? I have repeated the same concerns over and over again.

...

Now how can we make progress if we do not change Pharo?

Again, we already discussed this many times. I think Pharo is totally off the track: Pharo should concentrate on getting a stable core and enabling distributions on top, not on integrating as much new things as possible.

...

May be a dead pharo is better for you.

A dead Pharo is not my goal. I need a minimal Pharo with an absolutely trusted and stable core; a system where I can load all my code; a system that does not force me to use things I don't want to use.

...

@Lukas: please, could you point out what are the expected problems? For example, all PetitParser-Tests are green out of the box in the latest 1.4.

Nice, maybe the others also just work?

OB does not work though because Polymorph changed (and the debugger doesn't even open in the UI thread anymore either, so it is not possible to figure out the problem); and because it expects a different version of RB.

...

You were against changing RB, so how can we do remote tooling?

I was against chaining RB, because the proposed changes undermined design decisions in RB. In general, it feels extremely strange to me if people change code (or even class comments) without understanding the code.

Also, for that matter, I don't see how you want to use RB for remote tooling? If you remember, I pointed out an interview a while ago with John where they discuss why remote tooling wouldn't work without rewriting most parts.

Lukas

-- Lukas Renggli www.lukas-renggli.ch

Lukas I really think that you are exaggerating. Now how can we make progress if we do not change Pharo? You were against changing RB, so how can we do remote tooling? Alain fixed a lot of the problems of 1.3. I think that your bad energy will damage us and I'm immensely sad. May be a dead pharo is better for you. Stef

...

- then that OB can be loaded on top of Pharo. Remember we are not against OB we just do not have the knowledge to maintain it. So if lukas gets OB working for 1.4 beta then we will probably include in Pharo. Now if OB is working for 1.4 only three months after 1.4 is released then we will not include it.

Yes please, do not wait for me.

Just to repeat myself: With Pharo 1.4 having uncountable changes in core parts of the system and with the system including more and more forked and increasingly incompatible versions of packages (AST, RB, FS, Shout, Regex, ...) I am unwilling to go through the same pain as with Pharo 1.3 again. In the current state, I don't see any of the code I am involved with (including Seaside, Magritte, Pier, OB, PetitParser, ...) to move forward. I suspect that moving to another development platform soon causes less pain than to move to adopt the next Pharo :-(

Lukas

-- Lukas Renggli www.lukas-renggli.ch