Being able to automate is very good, however... <rant> I find a great deal of issues report are unhelpful, not to say totally useless. Take for example http://code.google.com/p/pharo/issues/detail?id=5482 it just tells, "hey look at the fix in this slice, and you'll understand" Then some bits of status (integrated, closed...). Generally the code is not even accessible from within the bug report (unless of few cases of change sets...) What do we learn from such reports? Do we find a rationale justifying the change? Do we only even guess the intention by just reading the report? What does this bring exactly to the process quality? If we just have to look at the code, then follow something light like squeak/trunk, just publish diffs and don't bother with pseudo-quality disguise. One huge progress would be the possibility to navigate across continuous integration server, issue tracker, source code repository, and so called ScriptLoader containing the list of fixes applied from one version to another... Tracking a regression down, seeing in which version it happened, what did change in this version, browsing the related issue in the tracker to understand the rationale of the change, and browsing the code diffs, all this directly from the web pages would help a lot... Of course, if reports are empty or cryptic, then maybe they can still feed bots, but don't expect help of humans too much ;) </rant> Nicolas Le 15 mars 2012 22:47, Stéphane Ducasse <stephane.ducasse@inria.fr> a écrit :

thanks stefan Can you open a bug tracker and publish your code with a slice or a cs so that our crawler can handle it automatically? Yes we are getting professional thanks for camillo and ben :)

Stef

On Mar 15, 2012, at 8:58 PM, Stefan Marr wrote:

...

Hi:

While stepping through bytecodes, I noticed a slightly annoying inefficiency in the SUnit implementation. The description string in #assert:equals: is always computed, even if it is not necessary.

While that might not be a performance problem, I find it rather distracting when I have to debug on the bytecode/VM level.

Since there seem to be only 127 senders or so in the image, you will probably not notice a big performance gain. The change to compute the string only when necessary is below.

Best regards Stefan

PS: This is a resend, because the original mail seemed to have been lost, while the mailing list was down.

!TestCase methodsFor: 'asserting' stamp: 'StefanMarr 3/13/2012 23:41'! assert: aBooleanOrBlock description: aStringOrBlock aBooleanOrBlock value ifFalse: [ | aString | aString := aStringOrBlock value. self logFailure: aString. TestResult failure signal: aString] ! !

!TestCase methodsFor: 'asserting' stamp: 'StefanMarr 3/13/2012 23:40'! assert: aBooleanOrBlock description: aStringOrBlock resumable: resumableBoolean | exception | aBooleanOrBlock value ifFalse: [|aString| aString := aStringOrBlock value. self logFailure: aString. exception := resumableBoolean ifTrue: [TestResult resumableFailure] ifFalse: [TestResult failure]. exception signal: aString] ! !

!TestCase methodsFor: 'asserting' stamp: 'StefanMarr 3/13/2012 23:40'! assert: expected equals: actual ^ self assert: (expected = actual) description: [self comparingStringBetween: actual and: expected] ! !

-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Hi Mariano: On 27 Apr 2012, at 10:24, Mariano Martinez Peck wrote:

Fix in inbox

http://code.google.com/p/pharo/issues/detail?id=5562

What happened to the issue I created, and which included a patch? http://code.google.com/p/pharo/issues/detail?id=5487 Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Hi Mariano: On 27 Apr 2012, at 13:11, Mariano Martinez Peck wrote:

...

http://code.google.com/p/pharo/issues/detail?id=5562

What happened to the issue I created, and which included a patch? http://code.google.com/p/pharo/issues/detail?id=5487

I didn't integrate 5487. I did integrate what you said in the first mail of this thread.

Ok, but the first mail only include the one part of the problem. The patch in 5487 should be more complete, no? Or does it break stuff? Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525