On Mon, 24 May 2010, Mariano Martinez Peck wrote:
2010/5/24 Levente Uzonyi <leves@elte.hu>
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?
I think "== nil" is just as readable as "isNil" and "isNil ifTrue:" is 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 < stephane.ducasse@inria.fr
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 <
patchinko@gmail.com> 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 <stephane.ducasse@inria.fr> 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 <
stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project