Re: [Pharo-project] Keymapping OB conflict (was Re: Chasing Browsers)
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
Re: [Pharo-project] Keymapping OB conflict (was Re: Chasing Browsers)
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. How can we remove from the kernel the ugly browser classes and tools, if people do not support the new tools? How can we redo senders and implementors (fix the ugly listMorph treemorph) when we cannot maintain OB (because we do not understand it)? So we are probably not so off-track that you believe. It will take more time that if people would collaborate with us, but we will get there. Ok so this is my last mail on that topic. I lost already too much energy that I should have spent on 1.4. Stef
Re: [Pharo-project] Keymapping OB conflict (was Re: Chasing Browsers)
What I would like to see happening is that - keymapping is used / integrated in Pharo 1.4 - 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. Stef On Dec 10, 2011, at 11:13 PM, Guillermo Polito wrote: 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 reng...@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 s...@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
Re: [Pharo-project] Keymapping OB conflict (was Re: Chasing Browsers)
- 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
Re: [Pharo-project] Keymapping OB conflict (was Re: Chasing Browsers)
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
Re: [Pharo-project] Keymapping OB conflict (was Re: Chasing Browsers)
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
Re: [Pharo-project] Keymapping OB conflict (was Re: Chasing Browsers)
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.
Re: [Pharo-project] Keymapping OB conflict (was Re: Chasing Browsers)
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 (now, I want to deprecate #description for #magritteDescription and add a pragma builder with magritte and magritteContainer keywords :) 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
Re: [Pharo-project] Keymapping OB conflict (was Re: Chasing Browsers)
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.
Re: [Pharo-project] Keymapping OB conflict (was Re: Chasing Browsers)
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
Re: [Pharo-project] Keymapping OB conflict (was Re: Chasing Browsers)
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 reng...@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 s...@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
Re: [Pharo-project] Keymapping OB conflict (was Re: Chasing Browsers)
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 s...@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
Re: [Pharo-project] Keymapping OB conflict (was Re: Chasing Browsers)
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? Keymapping? I don't think that would work with OB that has its own keymapping. The problem you observe is a long standing bug: if you don't have a text selection key presses are handled by Pharo not by OB. This means, if you select the method and press Cmd+n it should work. Lukas 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: OBTextMorphkeyStroke: OBTextMorph(TextMorph)handleKeystroke: KeyboardEventsentTo: OBTextMorph(Morph)handleEvent: OBTextMorph(Morph)handleFocusEvent: [ActiveHand := self. ActiveEvent := anEvent. result := focusHolder handleFocusEvent: (anEvent transformedBy: (focusHolder transformedFrom: self))] in HandMorphsendFocusEvent:to:clear: - with Keymapping: SmalltalkEditorsendersOfIt SmalltalkEditorsendersOfIt: [editor sendersOfIt: event] in [:editor :morph :event | morph handleKeymappingInteraction: [editor sendersOfIt: event] fromKeyboardEvent: event] in KMEditorsDefaultSettings classbuildSmalltalkEditorKeymappingsOn: 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 classbuildSmalltalkEditorKeymappingsOn: -- 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 www.lukas-renggli.ch
Re: [Pharo-project] Keymapping OB conflict (was Re: Chasing Browsers)
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.
