Why was the old Editor Functionality Removed?
Locked
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 |
Re: Why was the old Editor Functionality Removed?
|
|
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 > |
Re: Why was the old Editor Functionality Removed?
|
|
In reply to this post by Lukas Renggli
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 > |
Re: Why was the old Editor Functionality Removed?
|
|
In reply to this post by Lukas Renggli
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 > > |
Re: Why was the old Editor Functionality Removed?
|
|
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 <[hidden email]> wrote:
|
Re: Why was the old Editor Functionality Removed?
|
|
> 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 |
Re: 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 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 > |
Re: Why was the old Editor Functionality Removed?
|
|
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: [hidden email] [[hidden email]] On Behalf Of Stéphane Ducasse [[hidden email]] Sent: Thursday, December 09, 2010 4:49 PM To: [hidden email] 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 |
Re: Why was the old Editor Functionality Removed?
|
|
In reply to this post by Stéphane Ducasse
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." |
Re: Why was the old Editor Functionality Removed?
|
|
In reply to this post by Lukas Renggli
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 > > |
Re: Why was the old Editor Functionality Removed?
|
|
In reply to this post by Lukas Renggli
On Thu, Dec 9, 2010 at 10:32 PM, Lukas Renggli <[hidden email]> wrote:
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 |
Re: Why was the old Editor Functionality Removed?
|
|
In reply to this post by Tudor Girba
> 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 |
Re: Why was the old Editor Functionality Removed?
|
|
In reply to this post by Tudor Girba
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." > > > > > |
Re: Why was the old Editor Functionality Removed?
|
|
In reply to this post by Lukas Renggli
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 > |
Re: Why was the old Editor Functionality Removed?
|
|
In reply to this post by Lukas Renggli
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 > |
Re: Why was the old Editor Functionality Removed?
|
|
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 <[hidden email]> 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 |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |