June 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] New and richer halt messages

by Cyril Ferlicot D.

Le 04/06/2017 Ã 11:40, Peter Uhnak a Ã©crit : > But then I wouldn't be able to write 1halt. :( > > Peter > You can still add some startup script :) I have one compiling a "h" method in object calling halt to be able to write "1h" :) -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

June 4, 2017

Re: [Pharo-dev] Abstract test classes are not managed well in SUnit

by Cyril Ferlicot D.

Le 04/06/2017 Ã 12:38, monty a Ã©crit : > I agree with you, and I would rather subclasses inherit tests by default, but be aware that this isn't a bug[1], and changing it will temporarily break some test hierarchies. > > [1] https://github.com/pharo-project/pharo/blob/08fdc8d1712f91b2c22d95349cdf73f… > > If most people agree that we should inherit the tests by default I think this is a change that should be done very early in the Pharo 7 dev. Thus it would let time to people to adapt their project. -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

June 4, 2017

Re: [Pharo-dev] New and richer halt messages

by Esteban A. Maringolo

2017-06-04 6:40 GMT-03:00 Peter Uhnak <i.uhnak(a)gmail.com>: > On Sat, Jun 03, 2017 at 02:46:30PM -0700, Sean P. DeNigris wrote: >> Henrik-Nergaard wrote >> > Sounds like a good idea, but please implement them as constructors/class >> > side methods in Halt instead of adding even more methods to Object. >> >> You're speaking my language! When Stephan Eggermont and I paired at ESUG >> creating the Halt API, we wanted to remove all the Object methods, but we >> were advised not to scare the users too much ha ha. Maybe the time has >> finally come?! > > But then I wouldn't be able to write 1halt. :( I'd only leave #halt in Object, anything else goes to Halt class. I became a user of "1 halt" as well. Esteban A. Maringolo

June 4, 2017

Re: [Pharo-dev] Abstract test classes are not managed well in SUnit

by monty

I agree with you, and I would rather subclasses inherit tests by default, but be aware that this isn't a bug[1], and changing it will temporarily break some test hierarchies. [1] https://github.com/pharo-project/pharo/blob/08fdc8d1712f91b2c22d95349cdf73f… > Sent: Saturday, June 03, 2017 at 8:50 PM > From: "Cyril Ferlicot D." <cyril.ferlicot(a)gmail.com> > To: pharo-dev(a)lists.pharo.org > Subject: Re: [Pharo-dev] Abstract test classes are not managed well in SUnit > > Le 04/06/2017 Ã 02:26, monty a Ã©crit : > > I've seen this before, and I'm not sure it's a bug. > > > > A testless, non-abstract subclass of a TestCase is useless unless it inherits test methods. But if it defines its own test methods, then it isn't clear if it was made a subclass to inherit test methods, or if it was made a subclass to inherit non-test helper methods, or both. I think to be safe it assumes the second. > > > > Implement #shouldInheritSelectors in the superclass to get your intended behavior. > > > > > > I think that in most case we want the tests from the superclass. At > least this is what I expect. > > A subclass of an object keep the behaviour of its superclass when the > methods are not overridden. Why should it be different for tests? > > I see your point but if that is the case I think it should inherit the > tests by default and we could had a way to prevent this behaviour in > some cases. > > It is very awkward to get less tests after adding a new test in a class. > I think it reduce the power of the tests. > > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > >

June 4, 2017

Re: [Pharo-dev] New and richer halt messages

by Peter Uhnak

On Sat, Jun 03, 2017 at 02:46:30PM -0700, Sean P. DeNigris wrote: > Henrik-Nergaard wrote > > Sounds like a good idea, but please implement them as constructors/class > > side methods in Halt instead of adding even more methods to Object. > > You're speaking my language! When Stephan Eggermont and I paired at ESUG > creating the Halt API, we wanted to remove all the Object methods, but we > were advised not to scare the users too much ha ha. Maybe the time has > finally come?! But then I wouldn't be able to write 1halt. :( Peter

June 4, 2017

Re: [Pharo-dev] FFI does not work on Linux 64-bit

by Esteban Lorenzano

sorry, but this is not FFI. FFI works fine, this is another thing :) Esteban > On 3 Jun 2017, at 14:27, Oleksandr Zaytsev <olk.zaytsev(a)gmail.com> wrote: > > Hello, > > Yesterday during the Pharo Sprint I was experiencing many problems with my 64-bit Pharo Image and Pharo Sprint App. For example, whenever I clicked "Open in FogBugz", "Discuss on Discord", or "Help" in a Sprint App, I got > Error: Could not find accessor for variable named "command" > > As suggested on Discord, I tried this > WebBrowser openOn: 'http://pharo.org <http://pharo.org/>' > and received the same error > > Then, after I executed > xdg-open 'http://pharo.org <http://pharo.org/>' > in my Linux terminal, and it worked without an error, Juraj Kubelka assumed that ffi does not work on Linux 64-bit and told me that I should report this issue to Torsten Bergmann. > > Also, no method comments or class comments were visible in my image. And when I tried to write and save a comment, it just disappeared. These two problems may be related. > > OS: Ubuntu 16.04 LTS > VM: 201705310241 (http://files.pharo.org/vm/pharo-spur64/ <http://files.pharo.org/vm/pharo-spur64/>) > Image: Pharo64-60498 (http://files.pharo.org/image/60/latest-64.zip <http://files.pharo.org/image/60/latest-64.zip>) > > Oleks

June 4, 2017

Re: [Pharo-dev] Abstract test classes are not managed well in SUnit

by Max Leske

> On 4 Jun 2017, at 02:50, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > > Le 04/06/2017 Ã 02:26, monty a Ã©crit : >> I've seen this before, and I'm not sure it's a bug. >> >> A testless, non-abstract subclass of a TestCase is useless unless it inherits test methods. But if it defines its own test methods, then it isn't clear if it was made a subclass to inherit test methods, or if it was made a subclass to inherit non-test helper methods, or both. I think to be safe it assumes the second. >> >> Implement #shouldInheritSelectors in the superclass to get your intended behavior. >> >> > > I think that in most case we want the tests from the superclass. At > least this is what I expect. > > A subclass of an object keep the behaviour of its superclass when the > methods are not overridden. Why should it be different for tests? > > I see your point but if that is the case I think it should inherit the > tests by default and we could had a way to prevent this behaviour in > some cases. > > It is very awkward to get less tests after adding a new test in a class. > I think it reduce the power of the tests. I second that. > > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France >

June 4, 2017

Re: [Pharo-dev] Abstract test classes are not managed well in SUnit

by Cyril Ferlicot D.

Le 04/06/2017 Ã 02:26, monty a Ã©crit : > I've seen this before, and I'm not sure it's a bug. > > A testless, non-abstract subclass of a TestCase is useless unless it inherits test methods. But if it defines its own test methods, then it isn't clear if it was made a subclass to inherit test methods, or if it was made a subclass to inherit non-test helper methods, or both. I think to be safe it assumes the second. > > Implement #shouldInheritSelectors in the superclass to get your intended behavior. > > I think that in most case we want the tests from the superclass. At least this is what I expect. A subclass of an object keep the behaviour of its superclass when the methods are not overridden. Why should it be different for tests? I see your point but if that is the case I think it should inherit the tests by default and we could had a way to prevent this behaviour in some cases. It is very awkward to get less tests after adding a new test in a class. I think it reduce the power of the tests. -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

June 4, 2017

Re: [Pharo-dev] Abstract test classes are not managed well in SUnit

by monty

I've seen this before, and I'm not sure it's a bug. A testless, non-abstract subclass of a TestCase is useless unless it inherits test methods. But if it defines its own test methods, then it isn't clear if it was made a subclass to inherit test methods, or if it was made a subclass to inherit non-test helper methods, or both. I think to be safe it assumes the second. Implement #shouldInheritSelectors in the superclass to get your intended behavior. > Sent: Saturday, June 03, 2017 at 5:09 PM > From: "Cyril Ferlicot D." <cyril.ferlicot(a)gmail.com> > To: Pharo <pharo-dev(a)lists.pharo.org> > Subject: [Pharo-dev] Abstract test classes are not managed well in SUnit > > Hi, > > Today I found a bug in SUnit. > > Sometimes when you have an abstract test class and you override it the > tests will be inherit or not. > > If a subclass has other tests, the tests will not be inherited. If the > subclass has no other tests, the tests will be inherited. > > Here is a little script showing the problem: > > TestCase subclass: #A > slots: { } > classVariables: { } > category: 'TestProblem'. > > #A asClass subclass: #B > slots: { } > classVariables: { } > category: 'TestProblem'. > > #B asClass subclass: #C > slots: { } > classVariables: { } > category: 'TestProblem'. > > #A asClass class compile: 'isAbstract > ^ self = A'. > > #A asClass compile: 'actualClass > ^ self subclassResponsibility'. > > #A asClass compile: 'testTest > self actualClass new'. > > #C asClass buildSuiteFromAllSelectors run. > "1 run, 0 passes, 0 skipped, 0 expected failures, 0 failures, 1 errors, > 0 unexpected passes" > > #C asClass compile: 'testAnotherTest > self assert: true'. > > #C asClass buildSuiteFromAllSelectors run. > "1 run, 1 passes, 0 skipped, 0 expected failures, 0 failures, 0 > errors, 0 unexpected passes" > > > In the last line I would expect 2 run cases. 1 pass and 1 error. > > I think this is important to correct because it weaken the strength of > the tests. > > https://pharo.fogbugz.com/f/cases/20118/SUnit-does-not-manage-well-abstract… > > > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > >

June 4, 2017

Re: [Pharo-dev] New and richer halt messages

by Sean P. DeNigris

Henrik-Nergaard wrote > Sounds like a good idea, but please implement them as constructors/class > side methods in Halt instead of adding even more methods to Object. You're speaking my language! When Stephan Eggermont and I paired at ESUG creating the Halt API, we wanted to remove all the Object methods, but we were advised not to scare the users too much ha ha. Maybe the time has finally come?! ----- Cheers, Sean -- View this message in context: http://forum.world.st/New-and-richer-halt-messages-tp4948920p4949188.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 3, 2017