- Pharo-dev - lists.pharo.org

Re: [Pharo-project] <deprecated> annotation?

by Lukas Renggli

>>> How would that help anybody to find out whether they are relying on >>> deprecated methods? This seems like a big step backwards form a user >>> point of view. Suddenly a method is gone and you didn't get a warning. >>> You are you supposed to check for deprecated methods? Debug each and >>> every one of your message sends? >> >> +1, such an annotation is totally counterproductive. > > Provide an alternative. > Imagine that we're want to deprecate Array>>at: Disable the deprecateded notifications in the system settings. Like this you acknoledge that you use outdated code; and if this gets too annoying you might want to actually fix it. Ideally the deprecated notification debugger could allow you to disable further warnings. However deprecated warnings should always be turned on in downloaded images, otherwise we can as well remove them. Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 17, 2011

Re: [Pharo-project] <deprecated> annotation?

by Igor Stasenko

On 17 August 2011 14:26, Levente Uzonyi <leves(a)elte.hu> wrote: > On Wed, 17 Aug 2011, Philippe Marschall wrote: > >> On 16.08.2011 19:51, Igor Stasenko wrote: >>> >>> Hello, >>> >>> i know that we're already having #deprecated: , #deprecated: on: in: etc >>> >>> but one thing what i think useful about annotations that it is a way >>> to indicate that method is deprecated without showing a warning. >>> >>> The problem with using messages, that if you deprecate something which >>> used quite often by code, >>> you will be spammed with deprecation warnings all the time. >>> >>> So, Â i think that in addition to messages, we can use these >>> annotations, to indicate deprecated methods, in places where showing >>> warning(s) are not feasible >>> (for instance you cannot deprecate Deprecation>>showWarning, because >>> it will lead to infinite recurtion) >>> >>> There could be variations in same way as with messages: >>> >>> <deprecated> >>> <deprecated: '...' on: '..' in: '..'> >>> >>> etc. >>> >>> >>> What you think? >> >> How would that help anybody to find out whether they are relying on >> deprecated methods? This seems like a big step backwards form a user >> point of view. Suddenly a method is gone and you didn't get a warning. >> You are you supposed to check for deprecated methods? Debug each and >> every one of your message sends? >> >> Yeah you could write tools support but we both know this isn't gonna >> happen. > > What about using "soft deprecation". If would raise an exception which would > have no default action, but from the TestRunner (or other tools) you'd be > noticed that your code relies on deprecated methods. So if your code has > good test coverage, then you'll know that you have to update your code. For > example: > > foo > > Â Â Â Â self softDeprecated: 'This method shouldn't be used anymore. Use #bar > instead." > Â Â Â Â ... > +1 this seems like a nice way to solve the problem. So, we can add a Deprecation subclass, say SoftDeprecation and then modify test runner to catch all deprecations while running tests. Because right now we don't have a way to deprecate stuff, which is used often: things like browser protocol, system navigation, SmalltalkImage, Morphic, Canvas etc etc.. -- Best regards, Igor Stasenko AKA sig.

Aug. 17, 2011

Re: [Pharo-project] <deprecated> annotation?

by Philippe Marschall

On 17.08.2011 14:24, Igor Stasenko wrote: > On 17 August 2011 14:14, Philippe Marschall <kustos(a)gmx.net> wrote: >> On 16.08.2011 19:51, Igor Stasenko wrote: >>> Hello, >>> >>> i know that we're already having #deprecated: , #deprecated: on: in: etc >>> >>> but one thing what i think useful about annotations that it is a way >>> to indicate that method is deprecated without showing a warning. >>> >>> The problem with using messages, that if you deprecate something which >>> used quite often by code, >>> you will be spammed with deprecation warnings all the time. >>> >>> So, i think that in addition to messages, we can use these >>> annotations, to indicate deprecated methods, in places where showing >>> warning(s) are not feasible >>> (for instance you cannot deprecate Deprecation>>showWarning, because >>> it will lead to infinite recurtion) >>> >>> There could be variations in same way as with messages: >>> >>> <deprecated> >>> <deprecated: '...' on: '..' in: '..'> >>> >>> etc. >>> >>> >>> What you think? >> >> How would that help anybody to find out whether they are relying on >> deprecated methods? This seems like a big step backwards form a user >> point of view. Suddenly a method is gone and you didn't get a warning. > > Yes. You get an error instead of warning :) Right, I get an MNU. If this is your "solution" then you don't need deprecation at all, you can just straight out remove the method. Which I'm not against, don't get be wrong. But in this case I really don't see the point in the pragma. >> You are you supposed to check for deprecated methods? Debug each and >> every one of your message sends? >> >> Yeah you could write tools support but we both know this isn't gonna happen. >> > > I understand your concerns. I don't like this too. > But what choice you have if you have to deprecate something which used > a lot? If you put a message there, you will get an > image, which will show you warnings every time you doing something. > This will piss off users up to the point that for comfortable work, > they won't have other choice but to disable deprecation warnings, Been like this for years. > which means that at the end we will have same issue: > once you disable it, you cannot see anymore whether your code using > deprecated stuff or not. I don't do that because I have to either fix that code or inform some other person that they need to fix their code. Cheers Philippe

Aug. 17, 2011

Re: [Pharo-project] <deprecated> annotation?

by Igor Stasenko

On 17 August 2011 14:23, Lukas Renggli <renggli(a)gmail.com> wrote: >>> What you think? >> >> How would that help anybody to find out whether they are relying on >> deprecated methods? This seems like a big step backwards form a user >> point of view. Suddenly a method is gone and you didn't get a warning. >> You are you supposed to check for deprecated methods? Debug each and >> every one of your message sends? > > +1, such an annotation is totally counterproductive. > Provide an alternative. Imagine that we're want to deprecate Array>>at: what is possible solution? Because we need to have some way to deal with deprecation things like that, not only stuff which used sparingly. > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > -- Best regards, Igor Stasenko AKA sig.

Aug. 17, 2011

Re: [Pharo-project] seaside #stable on pharo.13?

by Philippe Marschall

On 16.08.2011 23:07, Dale Henrichs wrote: > Doru, > > The 'Base' group defines the minimal set of packages for Seaside (it does not include OB)... The only thing that you need in addition to 'Base' is to decide which of the Adaptors you want to use and you can have a perfectly functioning Seaside. > > If you are suggesting that the 'default' to not include the OB tools, that's fine with me, but in past discussions the decision was reached to include OB tools in the 'default' group. The rationale has always been (i believe) that the naive users need to have the Seaside control panel (which is based on OB) in order to easily start and stop Seaside ... The sophisticated and knowledgeable users can start with the 'Base' group and add exactly the packages that they are interested in ... > > Perhaps we need to have one more group that loads everything but the OB tools and leave the default group alone? If you are sophisticated enough to know you don't want OB, then you can load that group... I was confusing Metacello with other dependency managers, sorry. We'll have to talk about it at ESUG. Cheers Philippe

Aug. 17, 2011

Re: [Pharo-project] <deprecated> annotation?

by Levente Uzonyi

On Wed, 17 Aug 2011, Philippe Marschall wrote: > On 16.08.2011 19:51, Igor Stasenko wrote: >> Hello, >> >> i know that we're already having #deprecated: , #deprecated: on: in: etc >> >> but one thing what i think useful about annotations that it is a way >> to indicate that method is deprecated without showing a warning. >> >> The problem with using messages, that if you deprecate something which >> used quite often by code, >> you will be spammed with deprecation warnings all the time. >> >> So, i think that in addition to messages, we can use these >> annotations, to indicate deprecated methods, in places where showing >> warning(s) are not feasible >> (for instance you cannot deprecate Deprecation>>showWarning, because >> it will lead to infinite recurtion) >> >> There could be variations in same way as with messages: >> >> <deprecated> >> <deprecated: '...' on: '..' in: '..'> >> >> etc. >> >> >> What you think? > > How would that help anybody to find out whether they are relying on > deprecated methods? This seems like a big step backwards form a user > point of view. Suddenly a method is gone and you didn't get a warning. > You are you supposed to check for deprecated methods? Debug each and > every one of your message sends? > > Yeah you could write tools support but we both know this isn't gonna happen. What about using "soft deprecation". If would raise an exception which would have no default action, but from the TestRunner (or other tools) you'd be noticed that your code relies on deprecated methods. So if your code has good test coverage, then you'll know that you have to update your code. For example: foo self softDeprecated: 'This method shouldn't be used anymore. Use #bar instead." ... Levente > > Cheers > Philippe > > > >

Aug. 17, 2011

Re: [Pharo-project] <deprecated> annotation?

by Igor Stasenko

On 17 August 2011 14:14, Philippe Marschall <kustos(a)gmx.net> wrote: > On 16.08.2011 19:51, Igor Stasenko wrote: >> Hello, >> >> i know that we're already having #deprecated: , #deprecated: on: in: etc >> >> but one thing what i think useful about annotations that it is a way >> to indicate that method is deprecated without showing a warning. >> >> The problem with using messages, that if you deprecate something which >> used quite often by code, >> you will be spammed with deprecation warnings all the time. >> >> So, Â i think that in addition to messages, we can use these >> annotations, to indicate deprecated methods, in places where showing >> warning(s) are not feasible >> (for instance you cannot deprecate Deprecation>>showWarning, because >> it will lead to infinite recurtion) >> >> There could be variations in same way as with messages: >> >> <deprecated> >> <deprecated: '...' on: '..' in: '..'> >> >> etc. >> >> >> What you think? > > How would that help anybody to find out whether they are relying on > deprecated methods? This seems like a big step backwards form a user > point of view. Suddenly a method is gone and you didn't get a warning. Yes. You get an error instead of warning :) > You are you supposed to check for deprecated methods? Debug each and > every one of your message sends? > > Yeah you could write tools support but we both know this isn't gonna happen. > I understand your concerns. I don't like this too. But what choice you have if you have to deprecate something which used a lot? If you put a message there, you will get an image, which will show you warnings every time you doing something. This will piss off users up to the point that for comfortable work, they won't have other choice but to disable deprecation warnings, which means that at the end we will have same issue: once you disable it, you cannot see anymore whether your code using deprecated stuff or not. > Cheers > Philippe -- Best regards, Igor Stasenko AKA sig.

Aug. 17, 2011

Re: [Pharo-project] <deprecated> annotation?

by Lukas Renggli

>> What you think? > > How would that help anybody to find out whether they are relying on > deprecated methods? This seems like a big step backwards form a user > point of view. Suddenly a method is gone and you didn't get a warning. > You are you supposed to check for deprecated methods? Debug each and > every one of your message sends? +1, such an annotation is totally counterproductive. Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 17, 2011

Re: [Pharo-project] <deprecated> annotation?

by Philippe Marschall

On 16.08.2011 19:51, Igor Stasenko wrote: > Hello, > > i know that we're already having #deprecated: , #deprecated: on: in: etc > > but one thing what i think useful about annotations that it is a way > to indicate that method is deprecated without showing a warning. > > The problem with using messages, that if you deprecate something which > used quite often by code, > you will be spammed with deprecation warnings all the time. > > So, i think that in addition to messages, we can use these > annotations, to indicate deprecated methods, in places where showing > warning(s) are not feasible > (for instance you cannot deprecate Deprecation>>showWarning, because > it will lead to infinite recurtion) > > There could be variations in same way as with messages: > > <deprecated> > <deprecated: '...' on: '..' in: '..'> > > etc. > > > What you think? How would that help anybody to find out whether they are relying on deprecated methods? This seems like a big step backwards form a user point of view. Suddenly a method is gone and you didn't get a warning. You are you supposed to check for deprecated methods? Debug each and every one of your message sends? Yeah you could write tools support but we both know this isn't gonna happen. Cheers Philippe

Aug. 17, 2011

Re: [Pharo-project] Headless image hanging

by Bernat Romagosa

Thanks all! So I extended the table, let's see how it holds up now! Mariano, I know the vm's a little bit old, but I had already tried updating to the latest one and still had the same problem. Will update it anyway now that I noticed :) Thanks again! Cheers, 2011/8/17 Sven Van Caekenberghe <sven(a)beta9.be> > > On 17 Aug 2011, at 09:35, Mariano Martinez Peck wrote: > > > BTW, is not this the problem of Sempahores or I don't know what that you > need to change/make bigger in Cog ? > > Probably, http://code.google.com/p/pharo/issues/detail?id=4505 > > Hendrik fixed it for 1.4 > > You can manually extend the table in 1.2 like this: > > "Extend the external object table to allow for more sockets" > Smalltalk vmParameterAt: 49 put: 8192. > > This is only needed for Cog VMs. > > Sven > -- Bernat Romagosa.

Aug. 17, 2011