[Pharo-project] Why was the old Editor Functionality Removed?
I wonder why the old editor functionality was removed instead of being deprecated until the next release like this is normally done? It is extremely difficult to get any GUI related stuff ported, because the packages cannot simply be loaded. One has to fix part of the package in the old image, and part of the package in the new image. One wrong method, and everything blows up irreversibly. I spent the whole afternoon trying to get OB, Shout and eCompletion working. OB and Shout kind of work (thanks to the preparations in the PharoTaskForces), but they are still subtly broken. eCompletion is very hard to get working. The idea of making completion part of the ToolSet doesn't help at all, the patch now just moved from Morphic to the StandardToolSet class. I am frustrated and give up, I revert back to Pharo 1.1. Lukas -- Lukas Renggli www.lukas-renggli.ch
Hi lukas, sorry for your frustration, that I can easily understand I do not remember. There are some changes that when deprecated get in our way. I still think that we need a refactoring deprecate methods because just doing all of them by hand is not possible. I believe that we need to have the RBEngine all the time available and that the notion of core should vanish but I made no progress on the idea of using metacello to manage pharo-dev in a way that we could refactor all the packages at the same time. Stef
I wonder why the old editor functionality was removed instead of being deprecated until the next release like this is normally done?
It is extremely difficult to get any GUI related stuff ported, because the packages cannot simply be loaded. One has to fix part of the package in the old image, and part of the package in the new image. One wrong method, and everything blows up irreversibly.
I spent the whole afternoon trying to get OB, Shout and eCompletion working. OB and Shout kind of work (thanks to the preparations in the PharoTaskForces), but they are still subtly broken. eCompletion is very hard to get working. The idea of making completion part of the ToolSet doesn't help at all, the patch now just moved from Morphic to the StandardToolSet class.
I am frustrated and give up, I revert back to Pharo 1.1.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
Hi Lukas, all I guess I'm the one who made all this bad changes. So sorry, sorry sorry. Maybe we can come back to the "old" one. No problem for me. I can make a slice in that direction. But frankly, what a catastrophic mail for people who are trying to make the system cleaner. do you know how much of my free time I've spent to make the undo/redo work again? Maybe one can just simply ask for help instead of blaming. Cheers Alain Le 09/12/2010 19:17, Lukas Renggli a écrit :
I wonder why the old editor functionality was removed instead of being deprecated until the next release like this is normally done?
It is extremely difficult to get any GUI related stuff ported, because the packages cannot simply be loaded. One has to fix part of the package in the old image, and part of the package in the new image. One wrong method, and everything blows up irreversibly.
I spent the whole afternoon trying to get OB, Shout and eCompletion working. OB and Shout kind of work (thanks to the preparations in the PharoTaskForces), but they are still subtly broken. eCompletion is very hard to get working. The idea of making completion part of the ToolSet doesn't help at all, the patch now just moved from Morphic to the StandardToolSet class.
I am frustrated and give up, I revert back to Pharo 1.1.
Lukas
On Thu, 9 Dec 2010, Lukas Renggli wrote:
I wonder why the old editor functionality was removed instead of being deprecated until the next release like this is normally done?
It is extremely difficult to get any GUI related stuff ported, because the packages cannot simply be loaded. One has to fix part of the package in the old image, and part of the package in the new image. One wrong method, and everything blows up irreversibly.
I spent the whole afternoon trying to get OB, Shout and eCompletion working. OB and Shout kind of work (thanks to the preparations in the PharoTaskForces), but they are still subtly broken. eCompletion is very hard to get working. The idea of making completion part of the ToolSet doesn't help at all, the patch now just moved from Morphic to the StandardToolSet class.
OCompletion works and it includes ECompletion. Since I added a setting for using ECompletion instead of OCompletion (and not just as a fallback mechanism), ECompletion is also working with the new editors. Levente
I am frustrated and give up, I revert back to Pharo 1.1.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
And shout is kinda working too... i tried hard on OB just for fun but had no luck.. i think i'd got meta meta confused :) I would love to dedicate more time to it, but currently i'm very bussy. Cheers, Francisco On Thu, Dec 9, 2010 at 5:24 PM, Levente Uzonyi <leves@elte.hu> wrote:
On Thu, 9 Dec 2010, Lukas Renggli wrote:
I wonder why the old editor functionality was removed instead of being
deprecated until the next release like this is normally done?
It is extremely difficult to get any GUI related stuff ported, because the packages cannot simply be loaded. One has to fix part of the package in the old image, and part of the package in the new image. One wrong method, and everything blows up irreversibly.
I spent the whole afternoon trying to get OB, Shout and eCompletion working. OB and Shout kind of work (thanks to the preparations in the PharoTaskForces), but they are still subtly broken. eCompletion is very hard to get working. The idea of making completion part of the ToolSet doesn't help at all, the patch now just moved from Morphic to the StandardToolSet class.
OCompletion works and it includes ECompletion. Since I added a setting for using ECompletion instead of OCompletion (and not just as a fallback mechanism), ECompletion is also working with the new editors.
Levente
I am frustrated and give up, I revert back to Pharo 1.1.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
I guess I'm the one who made all this bad changes. So sorry, sorry sorry.
I don't think so.
Maybe we can come back to the "old" one. No problem for me.
I think the main problem is that the new editor model (which I really like) was merged directly into the existing editor morphs, so everything that uses more than just the morphs breaks.
I can make a slice in that direction.
I am not sure if this is possible anymore, because now we have dependencies on PluggableTextMorph and friends with the old API and dependencies on PluggableTextMorph and friends with the new API.
But frankly, what a catastrophic mail for people who are trying to make the system cleaner. do you know how much of my free time I've spent to make the undo/redo work again? Maybe one can just simply ask for help instead of blaming.
I am *not criticizing* the system cleanup. I am criticizing the changes that didn't go through a deprecation phase. It started with the introduction of the 'style' variable in a commonly used superclass. The problem was discussed a long time ago and I was shut up; today the problem turns out to be way worse.
OCompletion works and it includes ECompletion. Since I added a setting for using ECompletion instead of OCompletion (and not just as a fallback mechanism), ECompletion is also working with the new editors.
I looked at the OCompletion changes and tried to merge them into eCompletion, but as Francisco says it is only kinda working. Lukas -- Lukas Renggli www.lukas-renggli.ch
Thanks all for your time. We should try to do it better in the future. We should also change and improve our tools for helping us being better. Now something important is how can we move this style variable in a way that we can move it and also avoid to break. this is just an example: let us do an analysis of the problems and learn for the next cycle. Stef
I guess I'm the one who made all this bad changes. So sorry, sorry sorry.
I don't think so.
Maybe we can come back to the "old" one. No problem for me.
I think the main problem is that the new editor model (which I really like) was merged directly into the existing editor morphs, so everything that uses more than just the morphs breaks.
I can make a slice in that direction.
I am not sure if this is possible anymore, because now we have dependencies on PluggableTextMorph and friends with the old API and dependencies on PluggableTextMorph and friends with the new API.
But frankly, what a catastrophic mail for people who are trying to make the system cleaner. do you know how much of my free time I've spent to make the undo/redo work again? Maybe one can just simply ask for help instead of blaming.
I am *not criticizing* the system cleanup. I am criticizing the changes that didn't go through a deprecation phase. It started with the introduction of the 'style' variable in a commonly used superclass. The problem was discussed a long time ago and I was shut up; today the problem turns out to be way worse.
OCompletion works and it includes ECompletion. Since I added a setting for using ECompletion instead of OCompletion (and not just as a fallback mechanism), ECompletion is also working with the new editors.
I looked at the OCompletion changes and tried to merge them into eCompletion, but as Francisco says it is only kinda working.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
Stef, One approach might be to remove all direct accesses to the variable, and then arrange a (probably sub-optimal) temporary way to access through the existing receivers but with it in its new home. Then arrange to send the messages to the new intended recipient. Easier said than done, but it might fix Lukas' hassles with fixing things in both images - I've encountered similar problems, and they can be a huge pain. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Thursday, December 09, 2010 4:49 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Why was the old Editor Functionality Removed? Thanks all for your time. We should try to do it better in the future. We should also change and improve our tools for helping us being better. Now something important is how can we move this style variable in a way that we can move it and also avoid to break. this is just an example: let us do an analysis of the problems and learn for the next cycle. Stef
I said it before: just give the variable a different name. For example, textStyle. That would solve all loading problems. Doru On 9 Dec 2010, at 22:49, Stéphane Ducasse wrote:
Thanks all for your time. We should try to do it better in the future. We should also change and improve our tools for helping us being better.
Now something important is how can we move this style variable in a way that we can move it and also avoid to break. this is just an example: let us do an analysis of the problems and learn for the next cycle.
Stef
I guess I'm the one who made all this bad changes. So sorry, sorry sorry.
I don't think so.
Maybe we can come back to the "old" one. No problem for me.
I think the main problem is that the new editor model (which I really like) was merged directly into the existing editor morphs, so everything that uses more than just the morphs breaks.
I can make a slice in that direction.
I am not sure if this is possible anymore, because now we have dependencies on PluggableTextMorph and friends with the old API and dependencies on PluggableTextMorph and friends with the new API.
But frankly, what a catastrophic mail for people who are trying to make the system cleaner. do you know how much of my free time I've spent to make the undo/redo work again? Maybe one can just simply ask for help instead of blaming.
I am *not criticizing* the system cleanup. I am criticizing the changes that didn't go through a deprecation phase. It started with the introduction of the 'style' variable in a commonly used superclass. The problem was discussed a long time ago and I was shut up; today the problem turns out to be way worse.
OCompletion works and it includes ECompletion. Since I added a setting for using ECompletion instead of OCompletion (and not just as a fallback mechanism), ECompletion is also working with the new editors.
I looked at the OCompletion changes and tried to merge them into eCompletion, but as Francisco says it is only kinda working.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- www.tudorgirba.com "Every thing has its own flow."
I said it before: just give the variable a different name. For example, textStyle. That would solve all loading problems.
I said it before: This doesn't solve anything at all. In fact it is much easier to remove the variable and fork the code. Renaming causes a ripple effect to lots of methods and makes it impossible to merge the forks in the future. The style variable is just one example of the problem. I am suggesting that the next time the editor framework is replaced the old code is left untouched, then deprecated, and different class names are chosen for the new implementation. Like this both frameworks can coexist for a while making it much easier to migrate the code. The current situation comes from the fact that some existing classes changed their class layout and API completely making migration really difficult. Lukas -- Lukas Renggli www.lukas-renggli.ch
Yes I think that this is the pattern that we are applying for packageInfo for example
I said it before: This doesn't solve anything at all. In fact it is much easier to remove the variable and fork the code. Renaming causes a ripple effect to lots of methods and makes it impossible to merge the forks in the future.
The style variable is just one example of the problem. I am suggesting that the next time the editor framework is replaced the old code is left untouched, then deprecated, and different class names are chosen for the new implementation. Like this both frameworks can coexist for a while making it much easier to migrate the code.
The current situation comes from the fact that some existing classes changed their class layout and API completely making migration really difficult.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
so, concerning the new editor changes, I would like to help because this messy situation is partly my fault. would it be helpful if I rename current TextEditor as TextEditor2, (give me another name please ...), current SmalltalkEditor as SmalltalkEditor2 and reintroduce the previous implementation for TextEditor and SmalltalkEditor ? Cheers Alain Le 10/12/2010 00:32, Lukas Renggli a écrit :
I said it before: just give the variable a different name. For example, textStyle. That would solve all loading problems. I said it before: This doesn't solve anything at all. In fact it is much easier to remove the variable and fork the code. Renaming causes a ripple effect to lots of methods and makes it impossible to merge the forks in the future.
The style variable is just one example of the problem. I am suggesting that the next time the editor framework is replaced the old code is left untouched, then deprecated, and different class names are chosen for the new implementation. Like this both frameworks can coexist for a while making it much easier to migrate the code.
The current situation comes from the fact that some existing classes changed their class layout and API completely making migration really difficult.
Lukas
No, don't waste time on reverting. I almost got it working. My comment was ment for the future :-) Lukas On 10 December 2010 13:02, Alain Plantec <alain.plantec@free.fr> wrote:
so, concerning the new editor changes, I would like to help because this messy situation is partly my fault. would it be helpful if I rename current TextEditor as TextEditor2, (give me another name please ...), current SmalltalkEditor as SmalltalkEditor2 and reintroduce the previous implementation for TextEditor and SmalltalkEditor ? Cheers Alain
Le 10/12/2010 00:32, Lukas Renggli a écrit :
I said it before: just give the variable a different name. For example, textStyle. That would solve all loading problems.
I said it before: This doesn't solve anything at all. In fact it is much easier to remove the variable and fork the code. Renaming causes a ripple effect to lots of methods and makes it impossible to merge the forks in the future.
The style variable is just one example of the problem. I am suggesting that the next time the editor framework is replaced the old code is left untouched, then deprecated, and different class names are chosen for the new implementation. Like this both frameworks can coexist for a while making it much easier to migrate the code.
The current situation comes from the fact that some existing classes changed their class layout and API completely making migration really difficult.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
yes we should have done that On Dec 9, 2010, at 11:44 PM, Tudor Girba wrote:
I said it before: just give the variable a different name. For example, textStyle. That would solve all loading problems.
Doru
On 9 Dec 2010, at 22:49, Stéphane Ducasse wrote:
Thanks all for your time. We should try to do it better in the future. We should also change and improve our tools for helping us being better.
Now something important is how can we move this style variable in a way that we can move it and also avoid to break. this is just an example: let us do an analysis of the problems and learn for the next cycle.
Stef
I guess I'm the one who made all this bad changes. So sorry, sorry sorry.
I don't think so.
Maybe we can come back to the "old" one. No problem for me.
I think the main problem is that the new editor model (which I really like) was merged directly into the existing editor morphs, so everything that uses more than just the morphs breaks.
I can make a slice in that direction.
I am not sure if this is possible anymore, because now we have dependencies on PluggableTextMorph and friends with the old API and dependencies on PluggableTextMorph and friends with the new API.
But frankly, what a catastrophic mail for people who are trying to make the system cleaner. do you know how much of my free time I've spent to make the undo/redo work again? Maybe one can just simply ask for help instead of blaming.
I am *not criticizing* the system cleanup. I am criticizing the changes that didn't go through a deprecation phase. It started with the introduction of the 'style' variable in a commonly used superclass. The problem was discussed a long time ago and I was shut up; today the problem turns out to be way worse.
OCompletion works and it includes ECompletion. Since I added a setting for using ECompletion instead of OCompletion (and not just as a fallback mechanism), ECompletion is also working with the new editors.
I looked at the OCompletion changes and tried to merge them into eCompletion, but as Francisco says it is only kinda working.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- www.tudorgirba.com
"Every thing has its own flow."
On Thu, 9 Dec 2010, Lukas Renggli wrote:
I guess I'm the one who made all this bad changes. So sorry, sorry sorry.
I don't think so.
Maybe we can come back to the "old" one. No problem for me.
I think the main problem is that the new editor model (which I really like) was merged directly into the existing editor morphs, so everything that uses more than just the morphs breaks.
I can make a slice in that direction.
I am not sure if this is possible anymore, because now we have dependencies on PluggableTextMorph and friends with the old API and dependencies on PluggableTextMorph and friends with the new API.
But frankly, what a catastrophic mail for people who are trying to make the system cleaner. do you know how much of my free time I've spent to make the undo/redo work again? Maybe one can just simply ask for help instead of blaming.
I am *not criticizing* the system cleanup. I am criticizing the changes that didn't go through a deprecation phase. It started with the introduction of the 'style' variable in a commonly used superclass. The problem was discussed a long time ago and I was shut up; today the problem turns out to be way worse.
OCompletion works and it includes ECompletion. Since I added a setting for using ECompletion instead of OCompletion (and not just as a fallback mechanism), ECompletion is also working with the new editors.
I looked at the OCompletion changes and tried to merge them into eCompletion, but as Francisco says it is only kinda working.
He said that shout is what kinda working. If you've found a problem with OCompletion, let me know. Levente
Lukas
-- Lukas Renggli www.lukas-renggli.ch
On Thu, Dec 9, 2010 at 10:32 PM, Lukas Renggli <renggli@gmail.com> wrote:
I guess I'm the one who made all this bad changes. So sorry, sorry sorry.
I don't think so.
Maybe we can come back to the "old" one. No problem for me.
I think the main problem is that the new editor model (which I really like) was merged directly into the existing editor morphs, so everything that uses more than just the morphs breaks.
I can make a slice in that direction.
I am not sure if this is possible anymore, because now we have dependencies on PluggableTextMorph and friends with the old API and dependencies on PluggableTextMorph and friends with the new API.
But frankly, what a catastrophic mail for people who are trying to make the system cleaner. do you know how much of my free time I've spent to make the undo/redo work again? Maybe one can just simply ask for help instead of blaming.
I am *not criticizing* the system cleanup. I am criticizing the changes that didn't go through a deprecation phase.
I don't fully agree. We should deprecate certaing methods when it is really worth it. Deprecating each fucking method you remove its insane, overwork and I gues it will kill the process. There may be places that we didn't depreacte but should do it. But we cannot deprecate everything. Don't exagerate.
It started with the introduction of the 'style' variable in a commonly used superclass. The problem was discussed a long time ago and I was shut up; today the problem turns out to be way worse.
OCompletion works and it includes ECompletion. Since I added a setting for using ECompletion instead of OCompletion (and not just as a fallback mechanism), ECompletion is also working with the new editors.
I looked at the OCompletion changes and tried to merge them into eCompletion, but as Francisco says it is only kinda working.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
participants (8)
-
Alain Plantec -
Francisco Ortiz Peñaloza -
Levente Uzonyi -
Lukas Renggli -
Mariano Martinez Peck -
Schwab,Wilhelm K -
Stéphane Ducasse -
Tudor Girba