[Pharo-project] WeakArray>>isFinalizationSupported
As I port code from Sophie, I keep running into WeakArray>>isFinalizationSupported calls. Why was this method removed from Pharo? I want to make sure I understand what I'm doing when I remove these calls. Thanks. Sean -- View this message in context: http://forum.world.st/WeakArray-isFinalizationSupported-tp3168849p3168849.ht... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 30 December 2010 23:11, Sean P. DeNigris <sean@clipperadams.com> wrote:
As I port code from Sophie, I keep running into WeakArray>>isFinalizationSupported calls.
This is strange.. this code was introduced only since Pharo 1.2 and Squeak 4.2 images jut couple of months ago. And of course, Pharo 1.1 images, where you porting know nothing about this method. You can patch Pharo 1.1. by putting WeakArray>>isFinalizationSupported ^ false in this method. But i don't understand what you doing... how it could happen that Sophie knows about (and using) this recently introduced code? Or perhaps you trying to port Collections-Weak? which i would not recommend to do, because it is a part of Kernel.
Why was this method removed from Pharo? Â I want to make sure I understand what I'm doing when I remove these calls.
Thanks. Sean -- View this message in context: http://forum.world.st/WeakArray-isFinalizationSupported-tp3168849p3168849.ht... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko AKA sig.
On Thu, 30 Dec 2010, Igor Stasenko wrote:
On 30 December 2010 23:11, Sean P. DeNigris <sean@clipperadams.com> wrote:
As I port code from Sophie, I keep running into WeakArray>>isFinalizationSupported calls.
This is strange.. this code was introduced only since Pharo 1.2 and Squeak 4.2 images jut couple of months ago. And of course, Pharo 1.1 images, where you porting know nothing about this method.
You can patch Pharo 1.1. by putting WeakArray>>isFinalizationSupported ^ false in this method.
But i don't understand what you doing... how it could happen that Sophie knows about (and using) this recently introduced code?
Or perhaps you trying to port Collections-Weak? which i would not recommend to do, because it is a part of Kernel.
You are mixing the methods. #isFinalizationSupported used to answer what it's name suggests: "does the VM support any form of finalization?". What you're thinking about is WeakFinalizationList class >> #hasNewFinalization (or so) which is unrelated. The method was removed during a "cleanup". And as you know, backwards compatibility is not a priority for Pharo. Levente
Why was this method removed from Pharo? Â I want to make sure I understand what I'm doing when I remove these calls.
Thanks. Sean -- View this message in context: http://forum.world.st/WeakArray-isFinalizationSupported-tp3168849p3168849.ht... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko AKA sig.
2010/12/31 Levente Uzonyi <leves@elte.hu>:
On Thu, 30 Dec 2010, Igor Stasenko wrote:
On 30 December 2010 23:11, Sean P. DeNigris <sean@clipperadams.com> wrote:
As I port code from Sophie, I keep running into WeakArray>>isFinalizationSupported calls.
This is strange.. this code was introduced only since Pharo 1.2 and Squeak 4.2 images jut couple of months ago. And of course, Pharo 1.1 images, Â where you porting know nothing about this method.
You can patch Pharo 1.1. by putting WeakArray>>isFinalizationSupported ^ false in this method.
But i don't understand what you doing... how it could happen that Sophie knows about (and using) this recently introduced code?
Or perhaps you trying to port Collections-Weak? which i would not recommend to do, because it is a part of Kernel.
You are mixing the methods. #isFinalizationSupported used to answer what it's name suggests: "does the VM support any form of finalization?". What you're thinking about is WeakFinalizationList class >> #hasNewFinalization (or so) which is unrelated. The method was removed during a "cleanup". And as you know, backwards compatibility is not a priority for Pharo.
Ah... phew.. sorry for confusion :)
Levente
Why was this method removed from Pharo? Â I want to make sure I understand what I'm doing when I remove these calls.
Thanks. Sean -- View this message in context: http://forum.world.st/WeakArray-isFinalizationSupported-tp3168849p3168849.ht... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
Hopefully that can eventually be said as "backward compatibility with good stuff is a priority for Pharo." Moving targets are perhaps best left moving for now. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Thursday, December 30, 2010 6:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] WeakArray>>isFinalizationSupported (or so) which is unrelated. The method was removed during a "cleanup". And as you know, backwards compatibility is not a priority for Pharo. Levente
Well the question as pointed out was does this vm support weak object finalization? and since all closure vm support finalization, then asking the question was mute, so it was ditched. Sophie from the 2003 era had to ask. On 12/30/10, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Hopefully that can eventually be said as "backward compatibility with good stuff is a priority for Pharo." Moving targets are perhaps best left moving for now.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Thursday, December 30, 2010 6:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] WeakArray>>isFinalizationSupported
(or so) which is unrelated. The method was removed during a "cleanup". And as you know, backwards compatibility is not a priority for Pharo.
Levente
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
John M McIntosh wrote:
since all closure vm support finalization, then asking the question was mute
Okay, so I will remove these unnecessary checks. Sean -- View this message in context: http://forum.world.st/WeakArray-isFinalizationSupported-tp3168849p3169081.ht... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Thanks john. Some people think that we are just total idiot and reality is somehow different and fun to look at it. Stef On Dec 31, 2010, at 1:57 AM, John McIntosh wrote:
Well the question as pointed out was does this vm support weak object finalization? and since all closure vm support finalization, then asking the question was mute, so it was ditched. Sophie from the 2003 era had to ask.
On 12/30/10, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Hopefully that can eventually be said as "backward compatibility with good stuff is a priority for Pharo." Moving targets are perhaps best left moving for now.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Thursday, December 30, 2010 6:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] WeakArray>>isFinalizationSupported
(or so) which is unrelated. The method was removed during a "cleanup". And as you know, backwards compatibility is not a priority for Pharo.
Levente
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On Thu, 30 Dec 2010, John McIntosh wrote:
Well the question as pointed out was does this vm support weak object finalization? and since all closure vm support finalization, then asking the question was mute, so it was ditched. Sophie from the 2003 era had to ask.
The need for the check it outdated, but the method is still sent by external packages. With proper deprecation policy the method would be still available. It would simply return true and raise a deprecation warning. Levente
On 12/30/10, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Hopefully that can eventually be said as "backward compatibility with good stuff is a priority for Pharo." Moving targets are perhaps best left moving for now.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Thursday, December 30, 2010 6:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] WeakArray>>isFinalizationSupported
(or so) which is unrelated. The method was removed during a "cleanup". And as you know, backwards compatibility is not a priority for Pharo.
Levente
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On the other hand, if old packages are usefull, they should be maintained and upgraded. If Pharo wants to remove these deprecated methods, an alternative policy is to move deprecated methods in a separate backward compatibility package. Nicolas 2010/12/31 Levente Uzonyi <leves@elte.hu>:
On Thu, 30 Dec 2010, John McIntosh wrote:
Well the question as pointed out was does this vm support weak object finalization? and since all closure vm support finalization, then asking the question was mute, so it was ditched. Sophie from the 2003 era had to ask.
The need for the check it outdated, but the method is still sent by external packages. With proper deprecation policy the method would be still available. It would simply return true and raise a deprecation warning.
Levente
On 12/30/10, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Hopefully that can eventually be said as "backward compatibility with good stuff is a priority for Pharo." Â Moving targets are perhaps best left moving for now.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Thursday, December 30, 2010 6:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] WeakArray>>isFinalizationSupported
(or so) which is unrelated. The method was removed during a "cleanup". And as you know, backwards compatibility is not a priority for Pharo.
Levente
--
=========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. Â http://www.smalltalkconsulting.com
===========================================================================
On 31 December 2010 11:03, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
On the other hand, if old packages are usefull, they should be maintained and upgraded.
If Pharo wants to remove these deprecated methods, an alternative policy is to move deprecated methods in a separate backward compatibility package.
+1 I would call it 'Pharo-Cruft' :)
Nicolas
2010/12/31 Levente Uzonyi <leves@elte.hu>:
On Thu, 30 Dec 2010, John McIntosh wrote:
Well the question as pointed out was does this vm support weak object finalization? and since all closure vm support finalization, then asking the question was mute, so it was ditched. Sophie from the 2003 era had to ask.
The need for the check it outdated, but the method is still sent by external packages. With proper deprecation policy the method would be still available. It would simply return true and raise a deprecation warning.
Levente
On 12/30/10, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Hopefully that can eventually be said as "backward compatibility with good stuff is a priority for Pharo." Â Moving targets are perhaps best left moving for now.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Thursday, December 30, 2010 6:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] WeakArray>>isFinalizationSupported
(or so) which is unrelated. The method was removed during a "cleanup". And as you know, backwards compatibility is not a priority for Pharo.
Levente
--
=========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. Â http://www.smalltalkconsulting.com
===========================================================================
-- Best regards, Igor Stasenko AKA sig.
On 31 December 2010 12:45, Igor Stasenko <siguctua@gmail.com> wrote:
On 31 December 2010 11:03, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
On the other hand, if old packages are usefull, they should be maintained and upgraded.
If Pharo wants to remove these deprecated methods, an alternative policy is to move deprecated methods in a separate backward compatibility package.
+1 I would call it 'Pharo-Cruft' :)
Sorry for quick comment. I think this idea is userful to safely remove anything from system and it can be even automated Utilities moveDeprecatedToCruft "put all senders of #deprecated to '*Pharo-Cruft' category" ... Because a package author who wants to upgrade his package can be always sure that he can fix it, because he can use Pharo-Cruft for checking what removed methods was doing, and what is analogous functionality he can use in modern image (all deprecated methods should contain a comment describing, why it was removed and what should be used instead). Just removing methods, as it shown by this topic (isFinalizationSupported), could lead to unnecessary questions and confusion.
Nicolas
-- Best regards, Igor Stasenko AKA sig.
Igor Stasenko wrote:
On 31 December 2010 12:45, Igor Stasenko <siguctua@gmail.com> wrote:
On 31 December 2010 11:03, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
If Pharo wants to remove these deprecated methods, an alternative policy is to move deprecated methods in a separate backward compatibility package.
Utilities moveDeprecatedToCruft "put all senders of #deprecated to '*Pharo-Cruft' category" ...
Yes, awesome idea! This would be so helpful. When rescuing an old package, one could load it into an image with Cruft installed, and... Igor Stasenko wrote:
(all deprecated methods should contain a comment describing, why it was removed and what should be used instead).
This is the key! It would be almost trivial to upgrade old packages if the debugger explained how the code should be changed! There could even be a link to a relevant help topic, if one exists. Sean -- View this message in context: http://forum.world.st/WeakArray-isFinalizationSupported-tp3168849p3169485.ht... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
we have that this is called Deprecated1.2 Deprecated1.1 except that not all the methods are deprecated because we/you forget. Stef
Igor Stasenko wrote:
On 31 December 2010 12:45, Igor Stasenko <siguctua@gmail.com> wrote:
On 31 December 2010 11:03, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
If Pharo wants to remove these deprecated methods, an alternative policy is to move deprecated methods in a separate backward compatibility package.
Utilities moveDeprecatedToCruft "put all senders of #deprecated to '*Pharo-Cruft' category" ...
Yes, awesome idea! This would be so helpful. When rescuing an old package, one could load it into an image with Cruft installed, and...
Igor Stasenko wrote:
(all deprecated methods should contain a comment describing, why it was removed and what should be used instead).
This is the key! It would be almost trivial to upgrade old packages if the debugger explained how the code should be changed! There could even be a link to a relevant help topic, if one exists.
Sean -- View this message in context: http://forum.world.st/WeakArray-isFinalizationSupported-tp3168849p3169485.ht... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
nicolas cellier-2 wrote:
On the other hand, if old packages are usefull, they should be maintained and upgraded.
This is a great ideal, but in reality there are a ton of useful, out-of-date packages out there. Anything that helps restore them to usability for the community is a plus. For example, some projects I use all the time in my personal image that I had to update for current Squeak and/or Pharo: Applescript CommandShell ExternalWebBrowser HTML (Validating Parser) KeyBinder Keymapping MathMorphs rST SHWorkspace (World Menu Fix) sqlite3 SSpec SVI Sophie MP3 playing Sophie QuickTime video playing Sean -- View this message in context: http://forum.world.st/WeakArray-isFinalizationSupported-tp3168849p3169475.ht... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Thanks for the usual rant. This is good to have you here because we could have forgotten. Now of course we apply deprecation (we are probably the guy responsible to get the methods in Squeak long long time ago) but there are moments when there is too much to deprecate or when people forget. And forgetting is humane. Now if your company has lot of money, we can hire another engineer and work full speed and apply even more software engineering practices. Now it does not mean that we do not pay attention. We pay attention to people and to their product. May be each community needs its pain in the ass after all it shows that we get cooler and cooler. But it would be nice if you could give us a break. Stef On Dec 31, 2010, at 10:22 AM, Levente Uzonyi wrote:
On Thu, 30 Dec 2010, John McIntosh wrote:
Well the question as pointed out was does this vm support weak object finalization? and since all closure vm support finalization, then asking the question was mute, so it was ditched. Sophie from the 2003 era had to ask.
The need for the check it outdated, but the method is still sent by external packages. With proper deprecation policy the method would be still available. It would simply return true and raise a deprecation warning.
Levente
On 12/30/10, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Hopefully that can eventually be said as "backward compatibility with good stuff is a priority for Pharo." Moving targets are perhaps best left moving for now.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Thursday, December 30, 2010 6:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] WeakArray>>isFinalizationSupported
(or so) which is unrelated. The method was removed during a "cleanup". And as you know, backwards compatibility is not a priority for Pharo.
Levente
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Stephane, You can't be serious: you learn something usefull from students acid comments and nothing from the ones of Levente ? Comm'on! It's guaranteed that you'll get complaints. Only who doesn't do anything won't. Forgetting is human, mistakes are, and unfortunately your are human too. You must accept to fail, and you must accept some critics: it's up to you to turn these in positive feedback. cheers Nicolas 2010/12/31 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Thanks for the usual rant. This is good to have you here because we could have forgotten. Now of course we apply deprecation (we are probably the guy responsible to get the methods in Squeak long long time ago) but there are moments when there is too much to deprecate or when people forget. And forgetting is humane. Now if your company has lot of money, we can hire another engineer and work full speed and apply even more software engineering practices. Now it does not mean that we do not pay attention. We pay attention to people and to their product. May be each community needs its pain in the ass after all it shows that we get cooler and cooler. But it would be nice if you could give us a break.
Stef
On Dec 31, 2010, at 10:22 AM, Levente Uzonyi wrote:
On Thu, 30 Dec 2010, John McIntosh wrote:
Well the question as pointed out was does this vm support weak object finalization? and since all closure vm support finalization, then asking the question was mute, so it was ditched. Sophie from the 2003 era had to ask.
The need for the check it outdated, but the method is still sent by external packages. With proper deprecation policy the method would be still available. It would simply return true and raise a deprecation warning.
Levente
On 12/30/10, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Hopefully that can eventually be said as "backward compatibility with good stuff is a priority for Pharo." Â Moving targets are perhaps best left moving for now.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Thursday, December 30, 2010 6:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] WeakArray>>isFinalizationSupported
(or so) which is unrelated. The method was removed during a "cleanup". And as you know, backwards compatibility is not a priority for Pharo.
Levente
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. Â http://www.smalltalkconsulting.com ===========================================================================
ahahaa.. you guys are killing me.. You are taking things too serious. Yeah.. i would be gladly hear from Levente, what is 'the proper deprecation policy'. But since nobody described it, we are doomed to use one, invented before :) Nothing is perfect, but its not the reason to fight. On 31 December 2010 15:34, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Stephane, You can't be serious: you learn something usefull from students acid comments and nothing from the ones of Levente ? Comm'on! It's guaranteed that you'll get complaints. Only who doesn't do anything won't. Forgetting is human, mistakes are, and unfortunately your are human too. You must accept to fail, and you must accept some critics: it's up to you to turn these in positive feedback.
cheers
Nicolas
2010/12/31 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Thanks for the usual rant. This is good to have you here because we could have forgotten. Now of course we apply deprecation (we are probably the guy responsible to get the methods in Squeak long long time ago) but there are moments when there is too much to deprecate or when people forget. And forgetting is humane. Now if your company has lot of money, we can hire another engineer and work full speed and apply even more software engineering practices. Now it does not mean that we do not pay attention. We pay attention to people and to their product. May be each community needs its pain in the ass after all it shows that we get cooler and cooler. But it would be nice if you could give us a break.
Stef
On Dec 31, 2010, at 10:22 AM, Levente Uzonyi wrote:
On Thu, 30 Dec 2010, John McIntosh wrote:
Well the question as pointed out was does this vm support weak object finalization? and since all closure vm support finalization, then asking the question was mute, so it was ditched. Sophie from the 2003 era had to ask.
The need for the check it outdated, but the method is still sent by external packages. With proper deprecation policy the method would be still available. It would simply return true and raise a deprecation warning.
Levente
On 12/30/10, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Hopefully that can eventually be said as "backward compatibility with good stuff is a priority for Pharo." Â Moving targets are perhaps best left moving for now.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Thursday, December 30, 2010 6:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] WeakArray>>isFinalizationSupported
(or so) which is unrelated. The method was removed during a "cleanup". And as you know, backwards compatibility is not a priority for Pharo.
Levente
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. Â http://www.smalltalkconsulting.com ===========================================================================
-- Best regards, Igor Stasenko AKA sig.
On Fri, 31 Dec 2010, Igor Stasenko wrote:
ahahaa.. you guys are killing me.. You are taking things too serious. Yeah.. i would be gladly hear from Levente, what is 'the proper deprecation policy'. But since nobody described it, we are doomed to use one, invented before :)
I described my ideas here, so I won't repeat it. But I can tell you that removing a method which wasn't deprecated at all is _not_ a proper deprecation policy.
Nothing is perfect, but its not the reason to fight.
There's no fight. Levente
On 31 December 2010 15:34, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Stephane, You can't be serious: you learn something usefull from students acid comments and nothing from the ones of Levente ? Comm'on! It's guaranteed that you'll get complaints. Only who doesn't do anything won't. Forgetting is human, mistakes are, and unfortunately your are human too. You must accept to fail, and you must accept some critics: it's up to you to turn these in positive feedback.
cheers
Nicolas
2010/12/31 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Thanks for the usual rant. This is good to have you here because we could have forgotten. Now of course we apply deprecation (we are probably the guy responsible to get the methods in Squeak long long time ago) but there are moments when there is too much to deprecate or when people forget. And forgetting is humane. Now if your company has lot of money, we can hire another engineer and work full speed and apply even more software engineering practices. Now it does not mean that we do not pay attention. We pay attention to people and to their product. May be each community needs its pain in the ass after all it shows that we get cooler and cooler. But it would be nice if you could give us a break.
Stef
On Dec 31, 2010, at 10:22 AM, Levente Uzonyi wrote:
On Thu, 30 Dec 2010, John McIntosh wrote:
Well the question as pointed out was does this vm support weak object finalization? and since all closure vm support finalization, then asking the question was mute, so it was ditched. Sophie from the 2003 era had to ask.
The need for the check it outdated, but the method is still sent by external packages. With proper deprecation policy the method would be still available. It would simply return true and raise a deprecation warning.
Levente
On 12/30/10, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Hopefully that can eventually be said as "backward compatibility with good stuff is a priority for Pharo." Â Moving targets are perhaps best left moving for now.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Thursday, December 30, 2010 6:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] WeakArray>>isFinalizationSupported
(or so) which is unrelated. The method was removed during a "cleanup". And as you know, backwards compatibility is not a priority for Pharo.
Levente
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. Â http://www.smalltalkconsulting.com ===========================================================================
-- Best regards, Igor Stasenko AKA sig.
2010/12/31 Levente Uzonyi <leves@elte.hu>:
On Fri, 31 Dec 2010, Igor Stasenko wrote:
ahahaa.. you guys are killing me.. You are taking things too serious. Yeah.. i would be gladly hear from Levente, what is 'the proper deprecation policy'. But since nobody described it, we are doomed to use one, invented before :)
I described my ideas here, so I won't repeat it. But I can tell you that removing a method which wasn't deprecated at all is _not_ a proper deprecation policy.
can you give a pointer, where i can read about it?
Nothing is perfect, but its not the reason to fight.
There's no fight.
uh okay.. whatever you call it :)
Levente
-- Best regards, Igor Stasenko AKA sig.
On Dec 31, 2010, at 5:30 PM, Igor Stasenko wrote:
2010/12/31 Levente Uzonyi <leves@elte.hu>:
On Fri, 31 Dec 2010, Igor Stasenko wrote:
ahahaa.. you guys are killing me.. You are taking things too serious. Yeah.. i would be gladly hear from Levente, what is 'the proper deprecation policy'. But since nobody described it, we are doomed to use one, invented before :)
I described my ideas here, so I won't repeat it. But I can tell you that removing a method which wasn't deprecated at all is _not_ a proper deprecation policy.
can you give a pointer, where i can read about it?
The one we use. Now we should get a refactoring so that we can simply deprecate a method instead of forgetting. In addition there is a lack of support (but I do not real idea about how to do it well). How to deprecate complete classes.
Nothing is perfect, but its not the reason to fight.
There's no fight.
uh okay.. whatever you call it :)
Levente
-- Best regards, Igor Stasenko AKA sig.
On Fri, 31 Dec 2010, Igor Stasenko wrote:
2010/12/31 Levente Uzonyi <leves@elte.hu>:
On Fri, 31 Dec 2010, Igor Stasenko wrote:
ahahaa.. you guys are killing me.. You are taking things too serious. Yeah.. i would be gladly hear from Levente, what is 'the proper deprecation policy'. But since nobody described it, we are doomed to use one, invented before :)
I described my ideas here, so I won't repeat it. But I can tell you that removing a method which wasn't deprecated at all is _not_ a proper deprecation policy.
can you give a pointer, where i can read about it?
You can search this mailing list. But to make it a bit easier, it's basically the same as what it's intended to be: - deprecate all non-private methods that are to be removed (some private methods should also be deprecated) - keep the deprecated methods for at least one new release - calculate the deprecation dates from the method timestamps
Nothing is perfect, but its not the reason to fight.
There's no fight.
uh okay.. whatever you call it :)
... Levente
Levente
-- Best regards, Igor Stasenko AKA sig.
On 31 December 2010 19:47, Levente Uzonyi <leves@elte.hu> wrote:
On Fri, 31 Dec 2010, Igor Stasenko wrote:
2010/12/31 Levente Uzonyi <leves@elte.hu>:
On Fri, 31 Dec 2010, Igor Stasenko wrote:
ahahaa.. you guys are killing me.. You are taking things too serious. Yeah.. i would be gladly hear from Levente, what is 'the proper deprecation policy'. But since nobody described it, we are doomed to use one, invented before :)
I described my ideas here, so I won't repeat it. But I can tell you that removing a method which wasn't deprecated at all is _not_ a proper deprecation policy.
can you give a pointer, where i can read about it?
You can search this mailing list. But to make it a bit easier, it's basically the same as what it's intended to be: - deprecate all non-private methods that are to be removed (some private methods should also be deprecated) - keep the deprecated methods for at least one new release - calculate the deprecation dates from the method timestamps
Forgive me my ignorance. I know that Pharo using a deprecation policy, but i didn't paid much attention to details, and probably missed some key messages where policy was discussed. I knew only that people agreed to not remove methods immediately and that deprecation warning should stay at least single release cycle. -- Best regards, Igor Stasenko AKA sig.
2010/12/31 Levente Uzonyi <leves@elte.hu>
On Fri, 31 Dec 2010, Igor Stasenko wrote:
ahahaa.. you guys are killing me..
You are taking things too serious. Yeah.. i would be gladly hear from Levente, what is 'the proper deprecation policy'. But since nobody described it, we are doomed to use one, invented before :)
I described my ideas here, so I won't repeat it. But I can tell you that removing a method which wasn't deprecated at all is _not_ a proper deprecation policy.
+1.
Nothing is perfect, but its not the reason to fight.
There's no fight.
Levente
On 31 December 2010 15:34, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Stephane, You can't be serious: you learn something usefull from students acid comments and nothing from the ones of Levente ? Comm'on! It's guaranteed that you'll get complaints. Only who doesn't do anything won't. Forgetting is human, mistakes are, and unfortunately your are human too. You must accept to fail, and you must accept some critics: it's up to you to turn these in positive feedback.
cheers
Nicolas
2010/12/31 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Thanks for the usual rant. This is good to have you here because we could have forgotten. Now of course we apply deprecation (we are probably the guy responsible to get the methods in Squeak long long time ago) but there are moments when there is too much to deprecate or when people forget. And forgetting is humane. Now if your company has lot of money, we can hire another engineer and work full speed and apply even more software engineering practices. Now it does not mean that we do not pay attention. We pay attention to people and to their product. May be each community needs its pain in the ass after all it shows that we get cooler and cooler. But it would be nice if you could give us a break.
Stef
On Dec 31, 2010, at 10:22 AM, Levente Uzonyi wrote:
On Thu, 30 Dec 2010, John McIntosh wrote:
Well the question as pointed out was does this vm support weak object
finalization? and since all closure vm support finalization, then asking the question was mute, so it was ditched. Sophie from the 2003 era had to ask.
The need for the check it outdated, but the method is still sent by external packages. With proper deprecation policy the method would be still available. It would simply return true and raise a deprecation warning.
Levente
On 12/30/10, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Hopefully that can eventually be said as "backward compatibility with good stuff is a priority for Pharo." Moving targets are perhaps best left moving for now.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Thursday, December 30, 2010 6:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] WeakArray>>isFinalizationSupported
(or so) which is unrelated. The method was removed during a "cleanup". And as you know, backwards compatibility is not a priority for Pharo.
Levente
--
=========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
===========================================================================
-- Best regards, Igor Stasenko AKA sig.
On Dec 31, 2010, at 3:34 PM, Nicolas Cellier wrote:
Stephane, You can't be serious: you learn something usefull from students acid comments and nothing from the ones of Levente ?
I learned don't worry but levente is often at the edge of getting in my spam filter. So you see I continue to believe that he is not too boring...
Comm'on! It's guaranteed that you'll get complaints.
Sure when doing we always get exposed and I do not fear complaints. I got bird names in the past and I did not care. Now I care about the systematic anti pharo spirit developed.
Only who doesn't do anything won't. Forgetting is human, mistakes are, and unfortunately your are human too. You must accept to fail, and you must accept some critics: it's up to you to turn these in positive feedback.
I accept criticisms. Now not systematic. As I said did you see me sending a bad mail in squeak about squeak. I do not even do that in Pharo about squeak because this is not fun, productive. I have 10 years to make something cool, good and positive. Stef
cheers
Nicolas
2010/12/31 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Thanks for the usual rant. This is good to have you here because we could have forgotten. Now of course we apply deprecation (we are probably the guy responsible to get the methods in Squeak long long time ago) but there are moments when there is too much to deprecate or when people forget. And forgetting is humane. Now if your company has lot of money, we can hire another engineer and work full speed and apply even more software engineering practices. Now it does not mean that we do not pay attention. We pay attention to people and to their product. May be each community needs its pain in the ass after all it shows that we get cooler and cooler. But it would be nice if you could give us a break.
Stef
On Dec 31, 2010, at 10:22 AM, Levente Uzonyi wrote:
On Thu, 30 Dec 2010, John McIntosh wrote:
Well the question as pointed out was does this vm support weak object finalization? and since all closure vm support finalization, then asking the question was mute, so it was ditched. Sophie from the 2003 era had to ask.
The need for the check it outdated, but the method is still sent by external packages. With proper deprecation policy the method would be still available. It would simply return true and raise a deprecation warning.
Levente
On 12/30/10, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Hopefully that can eventually be said as "backward compatibility with good stuff is a priority for Pharo." Moving targets are perhaps best left moving for now.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Thursday, December 30, 2010 6:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] WeakArray>>isFinalizationSupported
(or so) which is unrelated. The method was removed during a "cleanup". And as you know, backwards compatibility is not a priority for Pharo.
Levente
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
El vie, 31-12-2010 a las 10:22 +0100, Levente Uzonyi escribió:
On Thu, 30 Dec 2010, John McIntosh wrote:
Well the question as pointed out was does this vm support weak object finalization? and since all closure vm support finalization, then asking the question was mute, so it was ditched. Sophie from the 2003 era had to ask.
The need for the check it outdated, but the method is still sent by external packages. With proper deprecation policy the method would be still available. It would simply return true and raise a deprecation warning.
But having a deprecated existing method also encourage to never update the external packages, so old bits are floating around even if not needed. Given the refactoring-mindset of the smalltalk community I'd say that better to have tha package be broken so the next one that *really* need that package update it as soon as discovered the flaw. That is a little pain in the short term for the dude that suffered the blow up of the package but overall good for the community once the package is upgraded to the new times. Cheers -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
On Fri, 31 Dec 2010, Miguel Cobá wrote:
El vie, 31-12-2010 a las 10:22 +0100, Levente Uzonyi escribió:
On Thu, 30 Dec 2010, John McIntosh wrote:
Well the question as pointed out was does this vm support weak object finalization? and since all closure vm support finalization, then asking the question was mute, so it was ditched. Sophie from the 2003 era had to ask.
The need for the check it outdated, but the method is still sent by external packages. With proper deprecation policy the method would be still available. It would simply return true and raise a deprecation warning.
But having a deprecated existing method also encourage to never update the external packages, so old bits are floating around even if not needed. Given the refactoring-mindset of the smalltalk community I'd say
You're right, those popups with the deprecation warnings are really encouraging people to not update the code. And who would give a damn about the deprecation message anyway? It's better to guess why things don't work or ask someone else (list). Levente
that better to have tha package be broken so the next one that *really* need that package update it as soon as discovered the flaw. That is a little pain in the short term for the dude that suffered the blow up of the package but overall good for the community once the package is upgraded to the new times.
Cheers -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
El vie, 31-12-2010 a las 17:18 +0100, Levente Uzonyi escribió:
On Fri, 31 Dec 2010, Miguel Cobá wrote:
El vie, 31-12-2010 a las 10:22 +0100, Levente Uzonyi escribió:
On Thu, 30 Dec 2010, John McIntosh wrote:
Well the question as pointed out was does this vm support weak object finalization? and since all closure vm support finalization, then asking the question was mute, so it was ditched. Sophie from the 2003 era had to ask.
The need for the check it outdated, but the method is still sent by external packages. With proper deprecation policy the method would be still available. It would simply return true and raise a deprecation warning.
But having a deprecated existing method also encourage to never update the external packages, so old bits are floating around even if not needed. Given the refactoring-mindset of the smalltalk community I'd say
You're right, those popups with the deprecation warnings are really encouraging people to not update the code. And who would give a damn about the deprecation message anyway? It's better to guess why things don't work or ask someone else (list).
Of course it is better. A pop up can be in some code path that only seldom is executed. For someone loading the code, no warnings means that everything is ok. Suppose they install it on a server side image thinking that everything is ok. Then sometime after that, the image stops working because the headless mode can't allow to see the popup that is waiting for someone to press a button. Again, the GUI is good sometimes, but sometimes is better to fail earlier. If on loading it doesn't load because of some missing method, the user can see right there that something is wrong with the package is trying to use. Cheers -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
On Fri, 31 Dec 2010, Miguel Cobá wrote:
El vie, 31-12-2010 a las 17:18 +0100, Levente Uzonyi escribió:
On Fri, 31 Dec 2010, Miguel Cobá wrote:
El vie, 31-12-2010 a las 10:22 +0100, Levente Uzonyi escribió:
On Thu, 30 Dec 2010, John McIntosh wrote:
Well the question as pointed out was does this vm support weak object finalization? and since all closure vm support finalization, then asking the question was mute, so it was ditched. Sophie from the 2003 era had to ask.
The need for the check it outdated, but the method is still sent by external packages. With proper deprecation policy the method would be still available. It would simply return true and raise a deprecation warning.
But having a deprecated existing method also encourage to never update the external packages, so old bits are floating around even if not needed. Given the refactoring-mindset of the smalltalk community I'd say
You're right, those popups with the deprecation warnings are really encouraging people to not update the code. And who would give a damn about the deprecation message anyway? It's better to guess why things don't work or ask someone else (list).
Of course it is better. A pop up can be in some code path that only seldom is executed. For someone loading the code, no warnings means that everything is ok. Suppose they install it on a server side image thinking that everything is ok. Then sometime after that, the image stops working because the headless mode can't allow to see the popup that is waiting for someone to press a button. Again, the GUI is good sometimes, but sometimes is better to fail earlier. If on loading it doesn't load because of some missing method, the user can see right there that something is wrong with the package is trying to use.
What you describe here is simply bad practice. One should run the tests before deploying code (besides testing the complete system thoroughly). If you use RFB, you can access the GUI in headless mode. Also when a debugger opens with a deprecation warning, the stack trace is written to the log file, so you will be notified about the problem even when you don't have access to the GUI. Anyway, there's no reason to remove a method (especially an API method) without deprecating and keeping it around for a few releases. Levente
Cheers
-- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
El vie, 31-12-2010 a las 20:05 +0100, Levente Uzonyi escribió:
What you describe here is simply bad practice. One should run the tests before deploying code (besides testing the complete system thoroughly). If you use RFB, you can access the GUI in headless mode. Also when a debugger opens with a deprecation warning, the stack trace is written to the log file, so you will be notified about the problem even when you don't have access to the GUI.
Yeah, sure. But if it a second level dependency (a package I use that uses a package that contains popups deprecation warnings) I have big chances of being bite by this problem. I concede, this could be avoided by test-running every and whatnot package in the image but for a system that updates automatically this will bite. Also, even if I can use RFB or read the image logs, I most likely will monitor the application logs and will pass a time without me knowing that some part of the application is waiting some user input. At the end I expect that the maintainer of the package is the *responsible* of test the application for the image I use, and not the user of the package. That is what I do with magma on Pharo. I test and fix the issues generated by the evolution of Pharo and then I release a new ConfigurationOfMagma that the user can use without knowing that n deprecations were involved in the upgrade of the package.
Anyway, there's no reason to remove a method (especially an API method) without deprecating and keeping it around for a few releases.
I agree that is better to not forget to mark some method as deprecated but, again, I think that this promote the external packages not being updated to the current pharo image. Cheers -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
On Fri, 31 Dec 2010, Miguel Cobá wrote:
El vie, 31-12-2010 a las 20:05 +0100, Levente Uzonyi escribió:
What you describe here is simply bad practice. One should run the tests before deploying code (besides testing the complete system thoroughly). If you use RFB, you can access the GUI in headless mode. Also when a debugger opens with a deprecation warning, the stack trace is written to the log file, so you will be notified about the problem even when you don't have access to the GUI.
Yeah, sure. But if it a second level dependency (a package I use that uses a package that contains popups deprecation warnings) I have big chances of being bite by this problem. I concede, this could be avoided by test-running every and whatnot package in the image but for a system that updates automatically this will bite.
So you're saying that it's better to get a DNU instead of a deprecation warning with proper description about what and how to update/change? Levente
Also, even if I can use RFB or read the image logs, I most likely will monitor the application logs and will pass a time without me knowing that some part of the application is waiting some user input. At the end I expect that the maintainer of the package is the *responsible* of test the application for the image I use, and not the user of the package. That is what I do with magma on Pharo. I test and fix the issues generated by the evolution of Pharo and then I release a new ConfigurationOfMagma that the user can use without knowing that n deprecations were involved in the upgrade of the package.
Anyway, there's no reason to remove a method (especially an API method) without deprecating and keeping it around for a few releases.
I agree that is better to not forget to mark some method as deprecated but, again, I think that this promote the external packages not being updated to the current pharo image.
Cheers
-- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
Oh, come on... Levente, we all agree with you. Pharo is trying to use that deprecation policy since some months ago... Sometimes people make mistakes (me included) and don't do it, but we agreed that we have to deprecate and remove after two versions of being deprecated. I'm tired of this stupid arguments. I expect the new year will bring us more doing and less discussing :). 2010/12/31 Levente Uzonyi <leves@elte.hu>
On Fri, 31 Dec 2010, Miguel Cobá wrote:
El vie, 31-12-2010 a las 20:05 +0100, Levente Uzonyi escribió:
What you describe here is simply bad practice. One should run the tests before deploying code (besides testing the complete system thoroughly). If you use RFB, you can access the GUI in headless mode. Also when a debugger opens with a deprecation warning, the stack trace is written to the log file, so you will be notified about the problem even when you don't have access to the GUI.
Yeah, sure. But if it a second level dependency (a package I use that uses a package that contains popups deprecation warnings) I have big chances of being bite by this problem. I concede, this could be avoided by test-running every and whatnot package in the image but for a system that updates automatically this will bite.
So you're saying that it's better to get a DNU instead of a deprecation warning with proper description about what and how to update/change?
Levente
Also, even if I can use RFB or read the image logs, I most likely will
monitor the application logs and will pass a time without me knowing that some part of the application is waiting some user input. At the end I expect that the maintainer of the package is the *responsible* of test the application for the image I use, and not the user of the package. That is what I do with magma on Pharo. I test and fix the issues generated by the evolution of Pharo and then I release a new ConfigurationOfMagma that the user can use without knowing that n deprecations were involved in the upgrade of the package.
Anyway, there's no reason to remove a method (especially an API method) without deprecating and keeping it around for a few releases.
I agree that is better to not forget to mark some method as deprecated but, again, I think that this promote the external packages not being updated to the current pharo image.
Cheers
-- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
On Fri, Dec 31, 2010 at 11:50 AM, Guillermo Polito < guillermopolito@gmail.com> wrote:
Oh, come on...
Levente, we all agree with you. Pharo is trying to use that deprecation policy since some months ago... Sometimes people make mistakes (me included) and don't do it, but we agreed that we have to deprecate and remove after two versions of being deprecated.
I'm tired of this stupid arguments.
I expect the new year will bring us more doing and less discussing :).
Unless we are prepared to discuss, discover, admit and correct our mistakes our doing will be of little worth. I don't see anything stupid in discussing deprecation policy. This criticism of Levente is entirely unjustified and reminds me of recent treatment of certain prominent whistle-blowers. Can we just drop the childish feelings of hurt, and direct ourselves to the substance of arguments rather than our immediate emotional reactions to email? We should all know by now that email is a particularly inexpressive medium, prone to misinterpretation and therefore it behooves us to take a breath before we reply and try and read beyond our surface perceptions. [I am a hypocrite in this regard having over-reacted recently over timestamps.] Doubtless we are all imperfect in our use of email and can all do better here. But we won't get any better by lacking objectivity and reacting emotionally to valid criticism. Can we make one of our new year's resolutions an attempt to be less emotional and more objective in all our email discussions in the broader Squeak community? Please? Happy New Year Eliot
2010/12/31 Levente Uzonyi <leves@elte.hu>
On Fri, 31 Dec 2010, Miguel Cobá wrote:
El vie, 31-12-2010 a las 20:05 +0100, Levente Uzonyi escribió:
What you describe here is simply bad practice. One should run the tests before deploying code (besides testing the complete system thoroughly). If you use RFB, you can access the GUI in headless mode. Also when a debugger opens with a deprecation warning, the stack trace is written to the log file, so you will be notified about the problem even when you don't have access to the GUI.
Yeah, sure. But if it a second level dependency (a package I use that uses a package that contains popups deprecation warnings) I have big chances of being bite by this problem. I concede, this could be avoided by test-running every and whatnot package in the image but for a system that updates automatically this will bite.
So you're saying that it's better to get a DNU instead of a deprecation warning with proper description about what and how to update/change?
Levente
Also, even if I can use RFB or read the image logs, I most likely will
monitor the application logs and will pass a time without me knowing that some part of the application is waiting some user input. At the end I expect that the maintainer of the package is the *responsible* of test the application for the image I use, and not the user of the package. That is what I do with magma on Pharo. I test and fix the issues generated by the evolution of Pharo and then I release a new ConfigurationOfMagma that the user can use without knowing that n deprecations were involved in the upgrade of the package.
Anyway, there's no reason to remove a method (especially an API method) without deprecating and keeping it around for a few releases.
I agree that is better to not forget to mark some method as deprecated but, again, I think that this promote the external packages not being updated to the current pharo image.
Cheers
-- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
On 31 December 2010 22:49, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Fri, Dec 31, 2010 at 11:50 AM, Guillermo Polito <guillermopolito@gmail.com> wrote:
Oh, come on...
Levente, we all agree with you. Pharo is trying to use that deprecation policy since some months ago... Sometimes people make mistakes (me included) and don't do it, but we agreed that we have to deprecate and remove after two versions of being deprecated.
I'm tired of this stupid arguments.
I expect the new year will bring us more doing and less discussing :).
Unless we are prepared to discuss, discover, admit and correct our mistakes our doing will be of little worth.  I don't see anything stupid in discussing  deprecation policy.  This criticism of Levente is entirely unjustified and reminds me of recent treatment of certain prominent whistle-blowers.  Can we just drop the childish feelings of hurt, and direct ourselves to the substance of arguments rather than our immediate emotional reactions to email?  We should all know by now that email is a particularly inexpressive medium, prone to misinterpretation and therefore it behooves us to take a breath before we reply and try and read beyond our surface perceptions.  [I am a hypocrite in this regard having over-reacted recently over timestamps.]
I have expressed my disgust about stamps quite emotionally too. Didn't mean to hurt anybody, just were too sad that we have to spend our energy to take care about things like that instead of doing something else.
Doubtless we are all imperfect in our use of email and can all do better here. Â But we won't get any better by lacking objectivity and reacting emotionally to valid criticism. Â Can we make one of our new year's resolutions an attempt to be less emotional and more objective in all our email discussions in the broader Squeak community? Â Please?
Amen.
Happy New Year Eliot
-- Best regards, Igor Stasenko AKA sig.
Eliot I was replying and I throw away the mail :) I already applied my new year resolution :) Stef PS: we know all that we should have better deprecation policy. We apply that but deprecation is good for little changes not huge ones.
On Fri, Dec 31, 2010 at 11:50 AM, Guillermo Polito <guillermopolito@gmail.com> wrote: Oh, come on...
Levente, we all agree with you. Pharo is trying to use that deprecation policy since some months ago... Sometimes people make mistakes (me included) and don't do it, but we agreed that we have to deprecate and remove after two versions of being deprecated.
I'm tired of this stupid arguments.
I expect the new year will bring us more doing and less discussing :).
Unless we are prepared to discuss, discover, admit and correct our mistakes our doing will be of little worth. I don't see anything stupid in discussing deprecation policy. This criticism of Levente is entirely unjustified and reminds me of recent treatment of certain prominent whistle-blowers. Can we just drop the childish feelings of hurt, and direct ourselves to the substance of arguments rather than our immediate emotional reactions to email? We should all know by now that email is a particularly inexpressive medium, prone to misinterpretation and therefore it behooves us to take a breath before we reply and try and read beyond our surface perceptions. [I am a hypocrite in this regard having over-reacted recently over timestamps.]
Doubtless we are all imperfect in our use of email and can all do better here. But we won't get any better by lacking objectivity and reacting emotionally to valid criticism. Can we make one of our new year's resolutions an attempt to be less emotional and more objective in all our email discussions in the broader Squeak community? Please?
Happy New Year Eliot
2010/12/31 Levente Uzonyi <leves@elte.hu>
On Fri, 31 Dec 2010, Miguel Cobá wrote:
El vie, 31-12-2010 a las 20:05 +0100, Levente Uzonyi escribió: What you describe here is simply bad practice. One should run the tests before deploying code (besides testing the complete system thoroughly). If you use RFB, you can access the GUI in headless mode. Also when a debugger opens with a deprecation warning, the stack trace is written to the log file, so you will be notified about the problem even when you don't have access to the GUI.
Yeah, sure. But if it a second level dependency (a package I use that uses a package that contains popups deprecation warnings) I have big chances of being bite by this problem. I concede, this could be avoided by test-running every and whatnot package in the image but for a system that updates automatically this will bite.
So you're saying that it's better to get a DNU instead of a deprecation warning with proper description about what and how to update/change?
Levente
Also, even if I can use RFB or read the image logs, I most likely will monitor the application logs and will pass a time without me knowing that some part of the application is waiting some user input. At the end I expect that the maintainer of the package is the *responsible* of test the application for the image I use, and not the user of the package. That is what I do with magma on Pharo. I test and fix the issues generated by the evolution of Pharo and then I release a new ConfigurationOfMagma that the user can use without knowing that n deprecations were involved in the upgrade of the package.
Anyway, there's no reason to remove a method (especially an API method) without deprecating and keeping it around for a few releases.
I agree that is better to not forget to mark some method as deprecated but, again, I think that this promote the external packages not being updated to the current pharo image.
Cheers
-- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
On Dec 31, 2010, at 8:50 PM, Guillermo Polito wrote:
Oh, come on...
Levente, we all agree with you. Pharo is trying to use that deprecation policy since some months ago... Sometimes people make mistakes (me included) and don't do it, but we agreed that we have to deprecate and remove after two versions of being deprecated.
I'm tired of this stupid arguments.
I expect the new year will bring us more doing and less discussing :).
+ 1 What is interesting is to see that such kind of emails are often coming from the same source. BTW guillermo I reallllllly deeply appreciate what you are doing on shortcut. I will have a look soon. Now I'm fighting with pomodoro to get rid of an important porposal I keep postponing like an idiot. Stef
El vie, 31-12-2010 a las 20:38 +0100, Levente Uzonyi escribió:
So you're saying that it's better to get a DNU instead of a deprecation warning with proper description about what and how to update/change?
No. I say that is the job of the maintainer of the package (or the upstream developer) to ensure some package load in some image and that *doesn't* use any deprecated message! Deprecation methods aren't a solution. The package *must* be upgraded to the new API or a compatibility layer must be installed. Any of them are chores of the maintainer, and the user must not even know what had to be done in order for the package to work for him. -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
Of course it is better. A pop up can be in some code path that only seldom is executed. For someone loading the code, no warnings means that everything is ok. Suppose they install it on a server side image thinking that everything is ok. Then sometime after that, the image stops working because the headless mode can't allow to see the popup that is waiting for someone to press a button. Again, the GUI is  good sometimes, but sometimes is better to fail earlier. If on loading it doesn't load because of some missing method, the user can see right there that something is wrong with the package is trying to use.
A robust server will have proper error-handling. I put a check for #maIsHeadless in my error-handler for Warnings so that they'll never halt when headless, but output a line to the log file. With that out of the way, that leaves, "the GUI is good." :) - Chris
participants (11)
-
Chris Muller -
Eliot Miranda -
Guillermo Polito -
Igor Stasenko -
John McIntosh -
Levente Uzonyi -
Miguel Cobá -
Nicolas Cellier -
Schwab,Wilhelm K -
Sean P. DeNigris -
Stéphane Ducasse