August 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Squeaksource not synchronized

by Fabrizio Perin

I will try to run a script that should fix it now. So SS will be down for some minuts cheers, Fabrizio 2011/8/17 Torsten Bergmann <astares(a)gmx.de> > Trouble with SqS again: > > JQWidgetBox-Dynatree-Core-tbn.1.mcz > JQWidgetBox-Dynatree-Core-tbn.2.mcz > JQWidgetBox-Dynatree-Core-tbn.3.mcz > JQWidgetBox-Dynatree-Dev-tbn.1.mcz > JQWidgetBox-Dynatree-Dev-tbn.2.mcz > JQWidgetBox-Dynatree-Dev-tbn.3.mcz > > I saved them yesterday to SqS - then later Squeaksource went down and was > restarted. I was not able to find them today using the web ui. > So I tried to upload them using the squeaksource web ui - but > failed since it complained that "they are not in mcz format" (???) > > So I used the "Copy" functionality from MetacelloBrowser to > copy them from the local cache to squeaksource. > This worked and now they are in the repo > http://www.squeaksource.com/JQueryWidgetBox > when I look at the repo using the Monticello browser from the image. > > But still they are not visible in the squeaksource web ui of the project: > http://www.squeaksource.com/JQueryWidgetBox.html > > The other two from today > > JQWidgetBox-Dynatree-Core-tbn.4.mcz > JQWidgetBox-Dynatree-Dev-tbn.4.mcz > > are visible in both (Monticello and Squeaksource web ui) - correct. > > Looks like the contents on disk is not in sync with the data the > squeaksource image holds. > > Any idea? > > Bye > T. > -- > NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurÃ¼ck-Garantie! > Jetzt informieren: http://www.gmx.net/de/go/freephone > >

Aug. 17, 2011

[Pharo-project] Squeaksource not synchronized

by Torsten Bergmann

Trouble with SqS again: JQWidgetBox-Dynatree-Core-tbn.1.mcz JQWidgetBox-Dynatree-Core-tbn.2.mcz JQWidgetBox-Dynatree-Core-tbn.3.mcz JQWidgetBox-Dynatree-Dev-tbn.1.mcz JQWidgetBox-Dynatree-Dev-tbn.2.mcz JQWidgetBox-Dynatree-Dev-tbn.3.mcz I saved them yesterday to SqS - then later Squeaksource went down and was restarted. I was not able to find them today using the web ui. So I tried to upload them using the squeaksource web ui - but failed since it complained that "they are not in mcz format" (???) So I used the "Copy" functionality from MetacelloBrowser to copy them from the local cache to squeaksource. This worked and now they are in the repo http://www.squeaksource.com/JQueryWidgetBox when I look at the repo using the Monticello browser from the image. But still they are not visible in the squeaksource web ui of the project: http://www.squeaksource.com/JQueryWidgetBox.html The other two from today JQWidgetBox-Dynatree-Core-tbn.4.mcz JQWidgetBox-Dynatree-Dev-tbn.4.mcz are visible in both (Monticello and Squeaksource web ui) - correct. Looks like the contents on disk is not in sync with the data the squeaksource image holds. Any idea? Bye T. -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurÃ¼ck-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone

Aug. 17, 2011

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

by Henrik Johansen

On Aug 17, 2011, at 2:40 34PM, Lukas Renggli wrote: >>>> 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 +1000 to what Lukas and Phillippe are saying. Always show deprecation warnings for a call site at least once. The whole point of deprecations vanishes if you are not made aware of them at all... If the deprecated method stored callsites in some dictionary, then skipped raising debuggers if already in the dict, that'd be swell. Didn't Alain Plaintec already make a nice GUI for browsing such triggered deprecations, or am I imagining things? IE. I think tool support is much better than a pragma. In fact, for deprecating commonly used methods I feel it is crucial. Until present, may I suggest just not deprecating such methods? I don't see any other way that will not inevitably lead to lots of swearing by users. Cheers, Henry

Aug. 17, 2011

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