ClassTestCase
Locked
12
12
 
|
Hi, I want to make global the
checks included in ClassTestCase, and remove it. That is because
actually it's only being tested for it's subclasses. And also, it's declaring that a
subclass will be a class test instead of just a test, but no one of
it's subclasses actually test the class, but the instances, therefore is
a TestCase, not a ClassTestCase. See TimespanTest as an example.
What Im saying is that I'm trying to force a run of a suit of Code Standards and Code Quality tests before sending something to merge to a baseline of a project. What do you think? Are you agree with that? Cheers, Mariano. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
the key point is that we would like to avoid to have red tests all the time
so fixing the as yet unclassified should be done before. BTW Does anybody use BadEqualer HashTester PrototypeTester because so far I do not see anybody user of them. They look like experiment code to me. Stef On May 22, 2010, at 7:31 PM, Mariano Abel Coca wrote: > Hi, I want to make global the checks included in ClassTestCase, and remove it. That is because actually it's only being tested for it's subclasses. And also, it's declaring that a subclass will be a class test instead of just a test, but no one of it's subclasses actually test the class, but the instances, therefore is a TestCase, not a ClassTestCase. See TimespanTest as an example. > > What Im saying is that I'm trying to force a run of a suit of Code Standards and Code Quality tests before sending something to merge to a baseline of a project. > > What do you think? Are you agree with that? > > Cheers, > > Mariano. > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
It is a must. We have to got all the tests in green. But actually that isn't tested.
I'll make the tests, I'll fix them, and then I'll send the whole changes to merge in the baseline. Cheers, Mariano. On Sat, May 22, 2010 at 2:58 PM, Stéphane Ducasse <[hidden email]> wrote: the key point is that we would like to avoid to have red tests all the time _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
What I was thinking mariano is that we could move one class at a time in classTests and make the tests green.
This way we do not have red tests and still make progress Stef On May 22, 2010, at 8:06 PM, Mariano Abel Coca wrote: > It is a must. We have to got all the tests in green. But actually that isn't tested. > > I'll make the tests, I'll fix them, and then I'll send the whole changes to merge in the baseline. > > Cheers, > > Mariano. > > > On Sat, May 22, 2010 at 2:58 PM, Stéphane Ducasse <[hidden email]> wrote: > the key point is that we would like to avoid to have red tests all the time > so fixing the as yet unclassified should be done before. > > > BTW Does anybody use > BadEqualer > HashTester > PrototypeTester > > because so far I do not see anybody user of them. > They look like experiment code to me. > > Stef > > On May 22, 2010, at 7:31 PM, Mariano Abel Coca wrote: > > > Hi, I want to make global the checks included in ClassTestCase, and remove it. That is because actually it's only being tested for it's subclasses. And also, it's declaring that a subclass will be a class test instead of just a test, but no one of it's subclasses actually test the class, but the instances, therefore is a TestCase, not a ClassTestCase. See TimespanTest as an example. > > > > What Im saying is that I'm trying to force a run of a suit of Code Standards and Code Quality tests before sending something to merge to a baseline of a project. > > > > What do you think? Are you agree with that? > > > > Cheers, > > > > Mariano. > > _______________________________________________ > > Pharo-project mailing list > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
We're working on it, making small changes and creating code standards
tests and code quality tests. It would be great to have a way of tracking the results of these tests in a distant future and make them mandatory before integrate new things into the image. Francisco On Sat, May 22, 2010 at 7:17 PM, Stéphane Ducasse <[hidden email]> wrote: > What I was thinking mariano is that we could move one class at a time in classTests and make the tests green. > This way we do not have red tests and still make progress > Stef > > > On May 22, 2010, at 8:06 PM, Mariano Abel Coca wrote: > >> It is a must. We have to got all the tests in green. But actually that isn't tested. >> >> I'll make the tests, I'll fix them, and then I'll send the whole changes to merge in the baseline. >> >> Cheers, >> >> Mariano. >> >> >> On Sat, May 22, 2010 at 2:58 PM, Stéphane Ducasse <[hidden email]> wrote: >> the key point is that we would like to avoid to have red tests all the time >> so fixing the as yet unclassified should be done before. >> >> >> BTW Does anybody use >> BadEqualer >> HashTester >> PrototypeTester >> >> because so far I do not see anybody user of them. >> They look like experiment code to me. >> >> Stef >> >> On May 22, 2010, at 7:31 PM, Mariano Abel Coca wrote: >> >> > Hi, I want to make global the checks included in ClassTestCase, and remove it. That is because actually it's only being tested for it's subclasses. And also, it's declaring that a subclass will be a class test instead of just a test, but no one of it's subclasses actually test the class, but the instances, therefore is a TestCase, not a ClassTestCase. See TimespanTest as an example. >> > >> > What Im saying is that I'm trying to force a run of a suit of Code Standards and Code Quality tests before sending something to merge to a baseline of a project. >> > >> > What do you think? Are you agree with that? >> > >> > Cheers, >> > >> > Mariano. >> > _______________________________________________ >> > Pharo-project mailing list >> > [hidden email] >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
If anyone want, can take a look at:
http://www.squeaksource.com/CodeQualityTests http://www.squeaksource.com/CodeStandardsTests And run the tests before committing the next version of their packages. We will try to help to pass the tests as soon as possible. Cheers, Mariano. On Sat, May 22, 2010 at 8:06 PM, Francisco Ortiz Peñaloza <[hidden email]> wrote: We're working on it, making small changes and creating code standards _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Francisco Ortiz Peñaloza
> We're working on it, making small changes and creating code standards
> tests and code quality tests. > > It would be great to have a way of tracking the results of these tests > in a distant future and make them mandatory before integrate new > things into the image. Francisco Three points: - I agree on the principle. Normally I read all the code that is integrated - now we should pay attention. I prefer to put code that make progress but is not perfect versus doing nothing and waiting for a better one - then people can comment on the submission made on the tracker but really few do it. So what is the solution let the code rot there? And kill our good energy. So you see nothing is simple. This is clear that having a nice bunch of SmallLint rules should not hurt :) Stef > > Francisco > > On Sat, May 22, 2010 at 7:17 PM, Stéphane Ducasse > <[hidden email]> wrote: >> What I was thinking mariano is that we could move one class at a time in classTests and make the tests green. >> This way we do not have red tests and still make progress >> Stef >> >> >> On May 22, 2010, at 8:06 PM, Mariano Abel Coca wrote: >> >>> It is a must. We have to got all the tests in green. But actually that isn't tested. >>> >>> I'll make the tests, I'll fix them, and then I'll send the whole changes to merge in the baseline. >>> >>> Cheers, >>> >>> Mariano. >>> >>> >>> On Sat, May 22, 2010 at 2:58 PM, Stéphane Ducasse <[hidden email]> wrote: >>> the key point is that we would like to avoid to have red tests all the time >>> so fixing the as yet unclassified should be done before. >>> >>> >>> BTW Does anybody use >>> BadEqualer >>> HashTester >>> PrototypeTester >>> >>> because so far I do not see anybody user of them. >>> They look like experiment code to me. >>> >>> Stef >>> >>> On May 22, 2010, at 7:31 PM, Mariano Abel Coca wrote: >>> >>>> Hi, I want to make global the checks included in ClassTestCase, and remove it. That is because actually it's only being tested for it's subclasses. And also, it's declaring that a subclass will be a class test instead of just a test, but no one of it's subclasses actually test the class, but the instances, therefore is a TestCase, not a ClassTestCase. See TimespanTest as an example. >>>> >>>> What Im saying is that I'm trying to force a run of a suit of Code Standards and Code Quality tests before sending something to merge to a baseline of a project. >>>> >>>> What do you think? Are you agree with that? >>>> >>>> Cheers, >>>> >>>> Mariano. >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Mariano Abel Coca
Sounds exciting can you tell us a bit more?
On May 23, 2010, at 2:54 AM, Mariano Abel Coca wrote: > If anyone want, can take a look at: > > http://www.squeaksource.com/CodeQualityTests > http://www.squeaksource.com/CodeStandardsTests > > And run the tests before committing the next version of their packages. > > We will try to help to pass the tests as soon as possible. > > Cheers, > > Mariano. > > > On Sat, May 22, 2010 at 8:06 PM, Francisco Ortiz Peñaloza <[hidden email]> wrote: > We're working on it, making small changes and creating code standards > tests and code quality tests. > > It would be great to have a way of tracking the results of these tests > in a distant future and make them mandatory before integrate new > things into the image. > > Francisco > > On Sat, May 22, 2010 at 7:17 PM, Stéphane Ducasse > <[hidden email]> wrote: > > What I was thinking mariano is that we could move one class at a time in classTests and make the tests green. > > This way we do not have red tests and still make progress > > Stef > > > > > > On May 22, 2010, at 8:06 PM, Mariano Abel Coca wrote: > > > >> It is a must. We have to got all the tests in green. But actually that isn't tested. > >> > >> I'll make the tests, I'll fix them, and then I'll send the whole changes to merge in the baseline. > >> > >> Cheers, > >> > >> Mariano. > >> > >> > >> On Sat, May 22, 2010 at 2:58 PM, Stéphane Ducasse <[hidden email]> wrote: > >> the key point is that we would like to avoid to have red tests all the time > >> so fixing the as yet unclassified should be done before. > >> > >> > >> BTW Does anybody use > >> BadEqualer > >> HashTester > >> PrototypeTester > >> > >> because so far I do not see anybody user of them. > >> They look like experiment code to me. > >> > >> Stef > >> > >> On May 22, 2010, at 7:31 PM, Mariano Abel Coca wrote: > >> > >> > Hi, I want to make global the checks included in ClassTestCase, and remove it. That is because actually it's only being tested for it's subclasses. And also, it's declaring that a subclass will be a class test instead of just a test, but no one of it's subclasses actually test the class, but the instances, therefore is a TestCase, not a ClassTestCase. See TimespanTest as an example. > >> > > >> > What Im saying is that I'm trying to force a run of a suit of Code Standards and Code Quality tests before sending something to merge to a baseline of a project. > >> > > >> > What do you think? Are you agree with that? > >> > > >> > Cheers, > >> > > >> > Mariano. > >> > _______________________________________________ > >> > Pharo-project mailing list > >> > [hidden email] > >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> [hidden email] > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> [hidden email] > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
There are few now, but it was done yesterday in a few hours. We will
keep adding new tests to that suites, so suggestions are welcome :).
Actually there are only 3 tests there: - One that checks that all the methods in the image are categorized - One that checks that never redefine #doesNotUnderstand: without redefining #respondsTo: and vice versa. - And one that checks that never sent = nil, ==nil, nil =, or nil ==, ~= nil, etc. as suggested in issue 1594 (Actually, after reading this issue is that we started with this idea). Cheers, Mariano. On Sun, May 23, 2010 at 4:53 AM, Stéphane Ducasse <[hidden email]> wrote: Sounds exciting can you tell us a bit more? _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Sun, 23 May 2010, Mariano Abel Coca wrote:
> There are few now, but it was done yesterday in a few hours. We will keep > adding new tests to that suites, so suggestions are welcome :). > > Actually there are only 3 tests there: > > - One that checks that all the methods in the image are categorized > - One that checks that never redefine #doesNotUnderstand: without redefining > #respondsTo: and vice versa. > - And one that checks that never sent = nil, ==nil, nil =, or nil ==, ~= > nil, etc. as suggested in issue 1594 (Actually, after reading this issue is > that we started with this idea). are usually bad ideas, but #isNil is 2.9x(*) slower than "== nil" and "== nil" is not less readable if you know what #== means (but that's basic smalltalk knowledge, so it's fair to assume that everybody knows it). Also "foo isNil ifTrue:" is 2.7x(*) slower than "foo ifNil:" for the same reasons (#ifNil: will be compiled as "== nil ifTrue:" if possible). So "== nil" #ifNil:, #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: should be used whenever possible. (*) Benchmarks on my slow machine: ((1 to: 10) collect: [ :run | [ 1 to: 10000000 do: [ :i | 1 == nil ] ] timeToRun ]) average asFloat. "===> 386.6" ((1 to: 10) collect: [ :run | [ 1 to: 10000000 do: [ :i | 1 isNil ] ] timeToRun ]) average asFloat. "===> 586.4" ((1 to: 10) collect: [ :run | [ 1 to: 10000000 do: [ :i | ] ] timeToRun ]) average asFloat. "===> 282.3" 586.4 - 282.3 / (386.6 - 282.3) "===> 2.915627996164908" ((1 to: 10) collect: [ :run | [ 1 to: 10000000 do: [ :i | 1 ifNil: [ 2 ] ] ] timeToRun ]) average asFloat. "===> 393.6" ((1 to: 10) collect: [ :run | [ 1 to: 10000000 do: [ :i | 1 isNil ifTrue: [ 2 ] ] ] timeToRun ]) average asFloat. "===> 585.2" 585.2 - 282.3 / (393.6 - 282.3). "===> 2.7214734950584" Levente > > Cheers, > > Mariano. > > > On Sun, May 23, 2010 at 4:53 AM, Stéphane Ducasse <[hidden email] >> wrote: > >> Sounds exciting can you tell us a bit more? >> >> On May 23, 2010, at 2:54 AM, Mariano Abel Coca wrote: >> >>> If anyone want, can take a look at: >>> >>> http://www.squeaksource.com/CodeQualityTests >>> http://www.squeaksource.com/CodeStandardsTests >>> >>> And run the tests before committing the next version of their packages. >>> >>> We will try to help to pass the tests as soon as possible. >>> >>> Cheers, >>> >>> Mariano. >>> >>> >>> On Sat, May 22, 2010 at 8:06 PM, Francisco Ortiz Pe?aloza < >> [hidden email]> wrote: >>> We're working on it, making small changes and creating code standards >>> tests and code quality tests. >>> >>> It would be great to have a way of tracking the results of these tests >>> in a distant future and make them mandatory before integrate new >>> things into the image. >>> >>> Francisco >>> >>> On Sat, May 22, 2010 at 7:17 PM, Stéphane Ducasse >>> <[hidden email]> wrote: >>>> What I was thinking mariano is that we could move one class at a time >> in classTests and make the tests green. >>>> This way we do not have red tests and still make progress >>>> Stef >>>> >>>> >>>> On May 22, 2010, at 8:06 PM, Mariano Abel Coca wrote: >>>> >>>>> It is a must. We have to got all the tests in green. But actually that >> isn't tested. >>>>> >>>>> I'll make the tests, I'll fix them, and then I'll send the whole >> changes to merge in the baseline. >>>>> >>>>> Cheers, >>>>> >>>>> Mariano. >>>>> >>>>> >>>>> On Sat, May 22, 2010 at 2:58 PM, Stéphane Ducasse < >> [hidden email]> wrote: >>>>> the key point is that we would like to avoid to have red tests all the >> time >>>>> so fixing the as yet unclassified should be done before. >>>>> >>>>> >>>>> BTW Does anybody use >>>>> BadEqualer >>>>> HashTester >>>>> PrototypeTester >>>>> >>>>> because so far I do not see anybody user of them. >>>>> They look like experiment code to me. >>>>> >>>>> Stef >>>>> >>>>> On May 22, 2010, at 7:31 PM, Mariano Abel Coca wrote: >>>>> >>>>>> Hi, I want to make global the checks included in ClassTestCase, and >> remove it. That is because actually it's only being tested for it's >> subclasses. And also, it's declaring that a subclass will be a class test >> instead of just a test, but no one of it's subclasses actually test the >> class, but the instances, therefore is a TestCase, not a ClassTestCase. See >> TimespanTest as an example. >>>>>> >>>>>> What Im saying is that I'm trying to force a run of a suit of Code >> Standards and Code Quality tests before sending something to merge to a >> baseline of a project. >>>>>> >>>>>> What do you think? Are you agree with that? >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Mariano. >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> [hidden email] >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
2010/5/24 Levente Uzonyi <[hidden email]>
I ask completely in ignorance, but can't we do some Compiler/Parser teaks so that allow us to write the more readable and nice but then it convert them to the fast ones?
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Mon, 24 May 2010, Mariano Martinez Peck wrote:
> 2010/5/24 Levente Uzonyi <[hidden email]> > >> On Sun, 23 May 2010, Mariano Abel Coca wrote: >> >> There are few now, but it was done yesterday in a few hours. We will keep >>> adding new tests to that suites, so suggestions are welcome :). >>> >>> Actually there are only 3 tests there: >>> >>> - One that checks that all the methods in the image are categorized >>> - One that checks that never redefine #doesNotUnderstand: without >>> redefining >>> #respondsTo: and vice versa. >>> - And one that checks that never sent = nil, ==nil, nil =, or nil ==, ~= >>> nil, etc. as suggested in issue 1594 (Actually, after reading this issue >>> is >>> that we started with this idea). >>> >> >> "x = nil", "nil = x", "x ~= nil", "nil ~= x", "x ~~ nil" and "nil ~~ x" are >> usually bad ideas, but #isNil is 2.9x(*) slower than "== nil" and >> "== nil" is not less readable if you know what #== means (but that's basic >> smalltalk knowledge, so it's fair to assume that everybody knows it). >> >> Also "foo isNil ifTrue:" is 2.7x(*) slower than "foo ifNil:" for the same >> reasons (#ifNil: will be compiled as "== nil ifTrue:" if possible). >> >> So "== nil" #ifNil:, #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: should >> be used whenever possible. >> >> (*) Benchmarks on my slow machine: >> >> ((1 to: 10) collect: [ :run | >> [ 1 to: 10000000 do: [ :i | 1 == nil ] ] timeToRun ]) average >> asFloat. "===> 386.6" >> >> ((1 to: 10) collect: [ :run | >> [ 1 to: 10000000 do: [ :i | 1 isNil ] ] timeToRun ]) average >> asFloat. "===> 586.4" >> >> ((1 to: 10) collect: [ :run | >> [ 1 to: 10000000 do: [ :i | ] ] timeToRun ]) average asFloat. "===> >> 282.3" >> >> 586.4 - 282.3 / (386.6 - 282.3) "===> 2.915627996164908" >> >> ((1 to: 10) collect: [ :run | >> [ 1 to: 10000000 do: [ :i | 1 ifNil: [ 2 ] ] ] timeToRun ]) average >> asFloat. "===> 393.6" >> >> ((1 to: 10) collect: [ :run | >> [ 1 to: 10000000 do: [ :i | 1 isNil ifTrue: [ 2 ] ] ] timeToRun ]) >> average asFloat. "===> 585.2" >> >> 585.2 - 282.3 / (393.6 - 282.3). "===> 2.7214734950584" >> >> > > I ask completely in ignorance, but can't we do some Compiler/Parser teaks so > that allow us to write the more readable and nice but then it convert them > to the fast ones? less readable than "ifNil:". So I don't see what you're suggesting. Levente > > > > > >> >> Levente >> >> >>> Cheers, >>> >>> Mariano. >>> >>> >>> On Sun, May 23, 2010 at 4:53 AM, Stéphane Ducasse < >>> [hidden email] >>> >>>> wrote: >>>> >>> >>> Sounds exciting can you tell us a bit more? >>>> >>>> On May 23, 2010, at 2:54 AM, Mariano Abel Coca wrote: >>>> >>>> If anyone want, can take a look at: >>>>> >>>>> http://www.squeaksource.com/CodeQualityTests >>>>> http://www.squeaksource.com/CodeStandardsTests >>>>> >>>>> And run the tests before committing the next version of their packages. >>>>> >>>>> We will try to help to pass the tests as soon as possible. >>>>> >>>>> Cheers, >>>>> >>>>> Mariano. >>>>> >>>>> >>>>> On Sat, May 22, 2010 at 8:06 PM, Francisco Ortiz Pe?aloza < >>>>> >>>> [hidden email]> wrote: >>>> >>>>> We're working on it, making small changes and creating code standards >>>>> tests and code quality tests. >>>>> >>>>> It would be great to have a way of tracking the results of these tests >>>>> in a distant future and make them mandatory before integrate new >>>>> things into the image. >>>>> >>>>> Francisco >>>>> >>>>> On Sat, May 22, 2010 at 7:17 PM, Stéphane Ducasse >>>>> <[hidden email]> wrote: >>>>> >>>>>> What I was thinking mariano is that we could move one class at a time >>>>>> >>>>> in classTests and make the tests green. >>>> >>>>> This way we do not have red tests and still make progress >>>>>> Stef >>>>>> >>>>>> >>>>>> On May 22, 2010, at 8:06 PM, Mariano Abel Coca wrote: >>>>>> >>>>>> It is a must. We have to got all the tests in green. But actually that >>>>>>> >>>>>> isn't tested. >>>> >>>>> >>>>>>> I'll make the tests, I'll fix them, and then I'll send the whole >>>>>>> >>>>>> changes to merge in the baseline. >>>> >>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Mariano. >>>>>>> >>>>>>> >>>>>>> On Sat, May 22, 2010 at 2:58 PM, Stéphane Ducasse < >>>>>>> >>>>>> [hidden email]> wrote: >>>> >>>>> the key point is that we would like to avoid to have red tests all the >>>>>>> >>>>>> time >>>> >>>>> so fixing the as yet unclassified should be done before. >>>>>>> >>>>>>> >>>>>>> BTW Does anybody use >>>>>>> BadEqualer >>>>>>> HashTester >>>>>>> PrototypeTester >>>>>>> >>>>>>> because so far I do not see anybody user of them. >>>>>>> They look like experiment code to me. >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> On May 22, 2010, at 7:31 PM, Mariano Abel Coca wrote: >>>>>>> >>>>>>> Hi, I want to make global the checks included in ClassTestCase, and >>>>>>>> >>>>>>> remove it. That is because actually it's only being tested for it's >>>> subclasses. And also, it's declaring that a subclass will be a class test >>>> instead of just a test, but no one of it's subclasses actually test the >>>> class, but the instances, therefore is a TestCase, not a ClassTestCase. >>>> See >>>> TimespanTest as an example. >>>> >>>>> >>>>>>>> What Im saying is that I'm trying to force a run of a suit of Code >>>>>>>> >>>>>>> Standards and Code Quality tests before sending something to merge to >>>> a >>>> baseline of a project. >>>> >>>>> >>>>>>>> What do you think? Are you agree with that? >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Mariano. >>>>>>>> _______________________________________________ >>>>>>>> Pharo-project mailing list >>>>>>>> [hidden email] >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> [hidden email] >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> [hidden email] >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> [hidden email] >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Mariano Martinez Peck
Mariano
Some of the combinations are inlined automatically by the compiler as levente explained. The problems is that without a rule checking that for me, I cannot remember which one are optimized :) Now the cost is that if you have more inlined expressions, then the decompiler gets more complex. So having a good and flexible decompiler would be a way to favor optimization. For now the list of levente and a slow machine "So "== nil" #ifNil:, #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: should be used whenever possible." is the one to use Now > > 2010/5/24 Levente Uzonyi <[hidden email]> > On Sun, 23 May 2010, Mariano Abel Coca wrote: > > There are few now, but it was done yesterday in a few hours. We will keep > adding new tests to that suites, so suggestions are welcome :). > > Actually there are only 3 tests there: > > - One that checks that all the methods in the image are categorized > - One that checks that never redefine #doesNotUnderstand: without redefining > #respondsTo: and vice versa. > - And one that checks that never sent = nil, ==nil, nil =, or nil ==, ~= > nil, etc. as suggested in issue 1594 (Actually, after reading this issue is > that we started with this idea). > > "x = nil", "nil = x", "x ~= nil", "nil ~= x", "x ~~ nil" and "nil ~~ x" are usually bad ideas, but #isNil is 2.9x(*) slower than "== nil" and > "== nil" is not less readable if you know what #== means (but that's basic smalltalk knowledge, so it's fair to assume that everybody knows it). > > Also "foo isNil ifTrue:" is 2.7x(*) slower than "foo ifNil:" for the same reasons (#ifNil: will be compiled as "== nil ifTrue:" if possible). > > So "== nil" #ifNil:, #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: should be used whenever possible. > > (*) Benchmarks on my slow machine: > > ((1 to: 10) collect: [ :run | > [ 1 to: 10000000 do: [ :i | 1 == nil ] ] timeToRun ]) average asFloat. "===> 386.6" > > ((1 to: 10) collect: [ :run | > [ 1 to: 10000000 do: [ :i | 1 isNil ] ] timeToRun ]) average asFloat. "===> 586.4" > > ((1 to: 10) collect: [ :run | > [ 1 to: 10000000 do: [ :i | ] ] timeToRun ]) average asFloat. "===> 282.3" > > 586.4 - 282.3 / (386.6 - 282.3) "===> 2.915627996164908" > > ((1 to: 10) collect: [ :run | > [ 1 to: 10000000 do: [ :i | 1 ifNil: [ 2 ] ] ] timeToRun ]) average asFloat. "===> 393.6" > > ((1 to: 10) collect: [ :run | > [ 1 to: 10000000 do: [ :i | 1 isNil ifTrue: [ 2 ] ] ] timeToRun ]) average asFloat. "===> 585.2" > > 585.2 - 282.3 / (393.6 - 282.3). "===> 2.7214734950584" > > > > I ask completely in ignorance, but can't we do some Compiler/Parser teaks so that allow us to write the more readable and nice but then it convert them to the fast ones? > > > > > > Levente > > > Cheers, > > Mariano. > > > On Sun, May 23, 2010 at 4:53 AM, Stéphane Ducasse <[hidden email] > wrote: > > Sounds exciting can you tell us a bit more? > > On May 23, 2010, at 2:54 AM, Mariano Abel Coca wrote: > > If anyone want, can take a look at: > > http://www.squeaksource.com/CodeQualityTests > http://www.squeaksource.com/CodeStandardsTests > > And run the tests before committing the next version of their packages. > > We will try to help to pass the tests as soon as possible. > > Cheers, > > Mariano. > > > On Sat, May 22, 2010 at 8:06 PM, Francisco Ortiz Pe?aloza < > [hidden email]> wrote: > We're working on it, making small changes and creating code standards > tests and code quality tests. > > It would be great to have a way of tracking the results of these tests > in a distant future and make them mandatory before integrate new > things into the image. > > Francisco > > On Sat, May 22, 2010 at 7:17 PM, Stéphane Ducasse > <[hidden email]> wrote: > What I was thinking mariano is that we could move one class at a time > in classTests and make the tests green. > This way we do not have red tests and still make progress > Stef > > > On May 22, 2010, at 8:06 PM, Mariano Abel Coca wrote: > > It is a must. We have to got all the tests in green. But actually that > isn't tested. > > I'll make the tests, I'll fix them, and then I'll send the whole > changes to merge in the baseline. > > Cheers, > > Mariano. > > > On Sat, May 22, 2010 at 2:58 PM, Stéphane Ducasse < > [hidden email]> wrote: > the key point is that we would like to avoid to have red tests all the > time > so fixing the as yet unclassified should be done before. > > > BTW Does anybody use > BadEqualer > HashTester > PrototypeTester > > because so far I do not see anybody user of them. > They look like experiment code to me. > > Stef > > On May 22, 2010, at 7:31 PM, Mariano Abel Coca wrote: > > Hi, I want to make global the checks included in ClassTestCase, and > remove it. That is because actually it's only being tested for it's > subclasses. And also, it's declaring that a subclass will be a class test > instead of just a test, but no one of it's subclasses actually test the > class, but the instances, therefore is a TestCase, not a ClassTestCase. See > TimespanTest as an example. > > What Im saying is that I'm trying to force a run of a suit of Code > Standards and Code Quality tests before sending something to merge to a > baseline of a project. > > What do you think? Are you agree with that? > > Cheers, > > Mariano. > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
> For now the list of levente and a slow machine
> > "So "== nil" #ifNil:, #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: should be used whenever possible." > is the one to use Please read my comments on the issue tracker. For *any practical* example it doesn't matter what to use speed wise: 1 = nil ifTrue: [ ] 2 == nil ifTrue: [ ] 3 isNil ifTrue: [ ] 4 ifNil: [ ] Personally I find 3 the most readable. 1 and 3 are the only practical ones if you use OODBs, because they are not shortcut by the compiler. I only use 4 for lazy initializers, it makes a good pattern. The use of #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: is only practicable if you don't care about compatibility with other Smalltalk dialects. Lukas -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Lukas
what would be good is to have a specific pharo smallLint that we could run to check. My brain is too small for all these details. Stef On May 24, 2010, at 6:18 PM, Lukas Renggli wrote: >> For now the list of levente and a slow machine >> >> "So "== nil" #ifNil:, #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: should be used whenever possible." >> is the one to use > > Please read my comments on the issue tracker. > > For *any practical* example it doesn't matter what to use speed wise: > > 1 = nil ifTrue: [ ] > 2 == nil ifTrue: [ ] > 3 isNil ifTrue: [ ] > 4 ifNil: [ ] > > Personally I find 3 the most readable. 1 and 3 are the only practical > ones if you use OODBs, because they are not shortcut by the compiler. > > I only use 4 for lazy initializers, it makes a good pattern. The use > of #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: is only practicable > if you don't care about compatibility with other Smalltalk dialects. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Lukas Renggli
On Mon, 24 May 2010, Lukas Renggli wrote:
>> For now the list of levente and a slow machine >> >> "So "== nil" #ifNil:, #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: should be used whenever possible." >> is the one to use > > Please read my comments on the issue tracker. > > For *any practical* example it doesn't matter what to use speed wise: That's not true. Most of the time it doesn't matter, but when these checks/conditional statements are in tight loops they can make a huge difference. Core packages have some good code examples and those have to be fast, but not cross-dialect. I'm sure other smalltalks are implemented this way. > > 1 = nil ifTrue: [ ] > 2 == nil ifTrue: [ ] > 3 isNil ifTrue: [ ] > 4 ifNil: [ ] IMHO 4 is the most readable and it is the fastest in Pharo/Squeak at the moment, so that should be preferred in core packages. 2 is cross-dialect and it's probably the fastest in all dialects, so if I were writing cross-dialect code then I'd probably use that. 3 looks nice and #isNil is inlined in some dialects (AFAIK), but it's "slow" in Squeak/Pharo. 1 just looks bad, I can't imagine an OODB that doesn't map it's "null object" directly to nil, otherwise #= will be asymmetric: null = nil -> true nil = null -> false Btw I hope we will have an inlining JIT soon which can decrease/eliminate these performance differences. Levente > > Personally I find 3 the most readable. 1 and 3 are the only practical > ones if you use OODBs, because they are not shortcut by the compiler. > > I only use 4 for lazy initializers, it makes a good pattern. The use > of #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: is only practicable > if you don't care about compatibility with other Smalltalk dialects. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
> IMHO 4 is the most readable and it is the fastest in Pharo/Squeak at the
> moment, so that should be preferred in core packages. It should not be preferred or changes unless you can prove a real performance benefit. I still haven't seen a single realistic benchmark with real code (from Pharo, Seaside, Pier, ...) where you can measure a real difference between these 4 variants. > 1 just looks bad, I can't imagine an OODB that doesn't map it's "null > object" directly to nil, otherwise #= will be asymmetric: > null = nil -> true > nil = null -> false That's not the problem. The problem is when you have proxy objects then all these inlined an shortcut variants fail miserably. Lukas -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Mon, 24 May 2010, Lukas Renggli wrote:
>> IMHO 4 is the most readable and it is the fastest in Pharo/Squeak at the >> moment, so that should be preferred in core packages. > > It should not be preferred or changes unless you can prove a real > performance benefit. I still haven't seen a single realistic benchmark > with real code (from Pharo, Seaside, Pier, ...) where you can measure > a real difference between these 4 variants. Well, just replace all uses of == nil and #ifNil:, etc with isNil and isNil ifTrue: etc. Then get some benchmarks which you accept as realistic and run them in both images. For now I can only show a microbenchmark that I evaluated in PharoCore-1.1-11367 on my slow machine: Original: (1 to: 5) collect: [ :run | FileStream readOnlyFileNamed: (SourceFiles at: 1) name do: [ :file | [ [ file next isNil ] whileFalse ] timeToRun ] ] #(9928 9733 9753 9703 9711) Then I replaced the #isNil send to == nil: (1 to: 5) collect: [ :run | FileStream readOnlyFileNamed: (SourceFiles at: 1) name do: [ :file | [ [ file next == nil ] whileFalse ] timeToRun ] ] #(9214 9301 9419 9273 9285) Not bad 4.8% faster. Then I replaced the line character1 isNil ifTrue: [^ nil]. with character1 ifNil: [^ nil]. in UTF8TextConverter >> #nextFromStream:. (1 to: 5) collect: [ :run | FileStream readOnlyFileNamed: (SourceFiles at: 1) name do: [ :file | [ [ file next == nil ] whileFalse ] timeToRun ] ] #(8947 8779 8814 8845 8810). 5% faster than the previous. Removing 2 #isNil sends from the tight loop gave ~10% speedup. Levente > > >> 1 just looks bad, I can't imagine an OODB that doesn't map it's "null >> object" directly to nil, otherwise #= will be asymmetric: >> null = nil -> true >> nil = null -> false > > That's not the problem. The problem is when you have proxy objects > then all these inlined an shortcut variants fail miserably. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
5 % is cool in such scenario.
Thanks levente. I believe in small speed ups and you show that. Stef On May 24, 2010, at 10:47 PM, Levente Uzonyi wrote: > On Mon, 24 May 2010, Lukas Renggli wrote: > >>> IMHO 4 is the most readable and it is the fastest in Pharo/Squeak at the >>> moment, so that should be preferred in core packages. >> >> It should not be preferred or changes unless you can prove a real >> performance benefit. I still haven't seen a single realistic benchmark >> with real code (from Pharo, Seaside, Pier, ...) where you can measure >> a real difference between these 4 variants. > > Well, just replace all uses of == nil and #ifNil:, etc with isNil and isNil ifTrue: etc. Then get some benchmarks which you accept as realistic and run them in both images. > > For now I can only show a microbenchmark that I evaluated in PharoCore-1.1-11367 on my slow machine: > > Original: > (1 to: 5) collect: [ :run | > FileStream readOnlyFileNamed: (SourceFiles at: 1) name do: [ :file | > [ [ file next isNil ] whileFalse ] timeToRun ] ] > #(9928 9733 9753 9703 9711) > > Then I replaced the #isNil send to == nil: > > (1 to: 5) collect: [ :run | > FileStream readOnlyFileNamed: (SourceFiles at: 1) name do: [ :file | > [ [ file next == nil ] whileFalse ] timeToRun ] ] > #(9214 9301 9419 9273 9285) > > Not bad 4.8% faster. Then I replaced the line > character1 isNil ifTrue: [^ nil]. > with > character1 ifNil: [^ nil]. > in UTF8TextConverter >> #nextFromStream:. > > (1 to: 5) collect: [ :run | > FileStream readOnlyFileNamed: (SourceFiles at: 1) name do: [ :file | > [ [ file next == nil ] whileFalse ] timeToRun ] ] > #(8947 8779 8814 8845 8810). > 5% faster than the previous. > > Removing 2 #isNil sends from the tight loop gave ~10% speedup. > > > Levente > >> >> >>> 1 just looks bad, I can't imagine an OODB that doesn't map it's "null >>> object" directly to nil, otherwise #= will be asymmetric: >>> null = nil -> true >>> nil = null -> false >> >> That's not the problem. The problem is when you have proxy objects >> then all these inlined an shortcut variants fail miserably. >> >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Levente Uzonyi-2
On 2010-05-24, at 1:47 PM, Levente Uzonyi wrote: > On Mon, 24 May 2010, Lukas Renggli wrote: > >>> IMHO 4 is the most readable and it is the fastest in Pharo/Squeak at the >>> moment, so that should be preferred in core packages. >> >> It should not be preferred or changes unless you can prove a real >> performance benefit. I still haven't seen a single realistic benchmark >> with real code (from Pharo, Seaside, Pier, ...) where you can measure >> a real difference between these 4 variants. > > Well, just replace all uses of == nil and #ifNil:, etc with isNil and isNil ifTrue: etc. Then get some benchmarks which you accept as realistic and run them in both images. > Well what is going on is that you are changing the foo isNil ifTrue: which is a message send for the isNil into a foo == nil ifTrue: which then does an object identity check in byte codes. Because messages sends are *slow* removing one from millions of executions does improve things. However what be more clever is changing the compiler to optimize the use of isNil so you maintain readability without a performance penalty. Also consider 'first' 'second' Well and the case of the simple accessor self foo ifTrue:[] where foo ^foo -- =========================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
smime.p7s (3K)
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |