December 2013 - Pharo-users

Re: [Pharo-users] About deprecation and unit testing

by StÃ©phane Ducasse

> A related issue is the enforcing of protocol. Currently, the RPackage implementation > doesnât allow other class-side definitions of #packages. There was no test for that, > so all images with Grease loaded (all Moose & Seaside based images) fail silently. > In Slice 12324 I added a test checking that no class below Object redefines the method. I do not think that it can be correct because ClassDecription defines it and it is under Object

Dec. 4, 2013

Re: [Pharo-users] command line command from pharo image

by Sabine KnÃ¶fel

Hi Sean, thanks. I need it now, on Pharo 2.0 but I will change it when I move to 3.0. Which is the Class and the message in NB then? Sabine On Tue, Dec 3, 2013 at 5:40 PM, Sean P. DeNigris [via Smalltalk] < ml-node+s1294792n4727098h33(a)n4.nabble.com> wrote: > Sabine KnÃ¶fel wrote > OSProcess thisOSProcess > > You can remove the send of #thisOSProcess and it will still work. Also, if > you don't care about output, you can use NB without installing anything. In > Pharo 3.0, it works on Windows, will work on Mac with Igor's latest > changes... not sure about Linux... > > HTH > Cheers, > Sean > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://forum.world.st/command-line-command-from-pharo-image-tp4727022p47270… > To start a new topic under Pharo Smalltalk Users, email > ml-node+s1294792n1310670h65(a)n4.nabble.com > To unsubscribe from command line command from pharo image, click here<http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&no…> > . > NAML<http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> > -- View this message in context: http://forum.world.st/command-line-command-from-pharo-image-tp4727022p47273… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Dec. 4, 2013

Re: [Pharo-users] About deprecation and unit testing

by Marcus Denker

On 04 Dec 2013, at 11:47, Stephan Eggermont <stephan(a)stack.nl> wrote: > A related issue is the enforcing of protocol. Currently, the RPackage implementation > doesnât allow other class-side definitions of #packages. There was no test for that, > so all images with Grease loaded (all Moose & Seaside based images) fail silently. > In Slice 12324 I added a test checking that no class below Object redefines the method. > this is true for all meta kind of selectorsâ¦ e.g. #layoutâ¦ (there is an issue related to that) Marcus

Dec. 4, 2013

Re: [Pharo-users] About deprecation and unit testing

by Stephan Eggermont

A related issue is the enforcing of protocol. Currently, the RPackage implementation doesnât allow other class-side definitions of #packages. There was no test for that, so all images with Grease loaded (all Moose & Seaside based images) fail silently. In Slice 12324 I added a test checking that no class below Object redefines the method. Stephan

Dec. 4, 2013

Re: [Pharo-users] openFullscreen a WindowModel

by Benjamin

Add: WindowModel>>#openFullscreen self changed: #openFullscreen with: #() MorphicWindowAdapter>>#openFullscreen self widgetDo: [ :w | w openFullscreen ] And tada Ben On 04 Dec 2013, at 11:13, Picci Pharo <prova213(a)hotmail.it> wrote: > Hi Guys! > > One simple question: how can i open fullscreen a WindowModel? As you know, the StandardWindow has got the message "openFullscreen", but it obviously doesn't work for the WindowModel. > Any suggestion? > > Ciao! > Paolo

Dec. 4, 2013

openFullscreen a WindowModel

by Picci Pharo

Hi Guys! One simple question: how can i open fullscreen a WindowModel? As you know, the StandardWindow has got the message "openFullscreen", but it obviously doesn't work for the WindowModel.Any suggestion? Ciao!Paolo

Dec. 4, 2013

Re: [Pharo-users] About deprecation and unit testing

by Sven Van Caekenberghe

On 04 Dec 2013, at 09:56, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Wed, Dec 4, 2013 at 9:50 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> No, I wouldnât do that by default: that would defeat the whole purpose of deprecation. If you want to ignore deprecations, you should do it yourself in your own tests, at your own risk, IMHO. > > > what about: > > - when the preference #raiseWarning: is true, a test sending a > deprecated message fails > - when the preference #raiseWarning: is false, a test sending a > deprecated message succeeds > > Implemented in: > > Name: SLICE-Issue-11423-Running-unit-tests-that-raise-deprecation-warnings-makes-them-fail-incomprehensibly-DamienCassou.1 > Author: DamienCassou > Time: 4 December 2013, 9:56:07.727774 am > UUID: bc043b07-b57b-4b5c-b140-8805a4397d31 > Ancestors: > Dependencies: SUnit-Tests-DamienCassou.31, SUnit-Core-DamienCassou.107 > > - when the preference #raiseWarning: is true, a test sending a > deprecated message fails > - when the preference #raiseWarning: is false, a test sending a > deprecated message succeeds OK, that sounds reasonable, Damien. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill >

Dec. 4, 2013

Re: [Pharo-users] About deprecation and unit testing

by Damien Cassou

On Wed, Dec 4, 2013 at 9:50 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > No, I wouldnât do that by default: that would defeat the whole purpose of deprecation. If you want to ignore deprecations, you should do it yourself in your own tests, at your own risk, IMHO. what about: - when the preference #raiseWarning: is true, a test sending a deprecated message fails - when the preference #raiseWarning: is false, a test sending a deprecated message succeeds Implemented in: Name: SLICE-Issue-11423-Running-unit-tests-that-raise-deprecation-warnings-makes-them-fail-incomprehensibly-DamienCassou.1 Author: DamienCassou Time: 4 December 2013, 9:56:07.727774 am UUID: bc043b07-b57b-4b5c-b140-8805a4397d31 Ancestors: Dependencies: SUnit-Tests-DamienCassou.31, SUnit-Core-DamienCassou.107 - when the preference #raiseWarning: is true, a test sending a deprecated message fails - when the preference #raiseWarning: is false, a test sending a deprecated message succeeds -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Dec. 4, 2013

Re: [Pharo-users] About deprecation and unit testing

by Sven Van Caekenberghe

On 04 Dec 2013, at 09:33, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Wed, Dec 4, 2013 at 9:18 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> There is a related bug tracker entry: > > > I will try to propose a slice that ignores deprecation warnings while > running the tests. But this will make it harder for people to find > deprecated message sends. No, I wouldnât do that by default: that would defeat the whole purpose of deprecation. If you want to ignore deprecations, you should do it yourself in your own tests, at your own risk, IMHO. > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill >

Dec. 4, 2013

Re: [Pharo-users] About deprecation and unit testing

by Luc Fabresse

Hi All, I think that trapping Deprecations silently is not a good idea. As you said, people will not see them and it will be hard to upgrade code. Why not having a Preference? or another button in the TestRunner such as: "Run ignoring Deprecation"? #Luc 2013/12/4 Damien Cassou <damien.cassou(a)gmail.com> > On Wed, Dec 4, 2013 at 9:18 AM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > > There is a related bug tracker entry: > > > I will try to propose a slice that ignores deprecation warnings while > running the tests. But this will make it harder for people to find > deprecated message sends. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill > >

Dec. 4, 2013