Two Squeak-related bugs and three questions

Squeakers,

at
        http://www.ba-stuttgart.de/~helbig/st80/bsearch.txt
you'll find an article about two Squeak related bugs, one in Java, one in the
GNU-C-optimizer.

The last bug provokes three questions. One to Tim Rowledge, one to Jan Piumarta
and one to Stefane Ducasse. But others may read it as well :-)

Enjoy
Wolfgang
--

sed  's/ie Philosophie/as Programmieren/
      s/Ludwig Wittgenstein/Wolfgang Helbig/' \
<<'Ende der Weisheit'
Die Philosophie ist ein Kampf gegen die Verhexung unseres
Verstandes durch die Mittel unserer Sprache. (Ludwig Wittgenstein)
Ende der Weisheit

Wolfgang Helbig wrote:
> one in the
> GNU-C-optimizer.

Have you reported the bug to the GCC bugzilla? If not, please do :-)
(and let me know the bug number, I'm very interested in tracking this one).

(What a great find, by the way! I'm absolutely astonished. If the
"redundant" parens around the latter part of the boolean expression are
removed, the optimizer generates correct code.)

Tony
--
 [][][] Tony Garnock-Jones     | Mob: +44 (0)7905 974 211
   [][] LShift Ltd             | Tel: +44 (0)20 7729 7060
 []  [] http://www.lshift.net/ | Email: [hidden email]

Tony,
you asked me:
>Have you reported the bug to the GCC bugzilla? If not, please do :-)

The Bug Id is 28042. See at
        http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28042

Greetings,
Wolfgang

On 15-Jun-06, at 3:37 AM, Wolfgang Helbig wrote:

So my first question is why you couldn't simply ask the question in  
email.

Second question is why you are spending effort on the 1.18 vm,  
something so old and obsolete it practically smells of mold.

Third, the shift/xor trick for determining a valid smallInt value is  
one I came up with in 1987 and it was put into the Squeak vm  in  
probably 1.2 or thereabouts, when nobody was considering anything  
other than 32 bit cpus and so the comment was perfectly reasonable.  
In what way is the comment 'rather useless'? I think it explains the  
point quite adequately and it's sure as hell better than the complete  
lack of comments in 90% or more of the methods in the system..

Fourth, the code generator changes quite a lot of things in the  
process of transliterating from the VM code to the C code so you  
shouldn't be at all surprised when one formulation is used in the  
image and another in the generated code. It would be nice if things  
could be more directly connected but no-one has had time to tackle  
what is actually a big problem. We tried at Interval and concluded it  
required a lot of work to do well.

Fifth - you're surely not surprised to find bugs in gcc?


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: SDJ: Send all Data to Japan

Tim, you asked even more questions.
>So my first question is why you couldn't simply ask the question in  
>email.

For historical reasons. When I've started the article, I didn't know that
I'll end up with three questions and GCC's optimizer bug.

>
>Second question is why you are spending effort on the 1.18 vm,  
>something so old and obsolete it practically smells of mold.

Since it is the smallest Squeak I could get. I like to study programs that
I can comprehend. Squeak 1.18 is much closer to it than contemporary Squeaks.

>
>Third, the shift/xor trick for determining a valid smallInt value is  
>one I came up with in 1987 and it was put into the Squeak vm  in  
>probably 1.2 or thereabouts, when nobody was considering anything  
>other than 32 bit cpus and so the comment was perfectly reasonable.

Reasonable yes, but still wrong. I've found that out, when trying to prove
that both expressions are equivalent.
 
>In what way is the comment 'rather useless'? I think it explains the  
>point quite adequately and it's sure as hell better than the complete  
>lack of comments in 90% or more of the methods in the system..

It sure is! But most of it simply rephrases the code. And that is what
I consider useless.

>Fourth, the code generator changes quite a lot of things in the  
>process of transliterating from the VM code to the C code so you  
>shouldn't be at all surprised when one formulation is used in the  
>image and another in the generated code.

I am not surprised! I've noticed that inLining-flag. I am not at all
mourning at it.

>
>Fifth - you're surely not surprised to find bugs in gcc?

Hmm. Kind of. I was using gcc quite a lot in the FreeBSD/NetBSD project. And
never found a bug. But as I learned today this is because the default flags in
those projects did carefully avoid calling the optimizer.

Greetings,
Wolfgang

On 15-Jun-06, at 8:51 AM, Wolfgang Helbig wrote:

>
> It sure is! But most of it simply rephrases the code. And that is what
> I consider useless.
I completely disagree. It *explains* what the code is intended to do  
and the way that it does it. Simply sticking the code in there would  
be completely unreasonable since it is non-obvious how it provides  
the correct result.

Comments that explain the intent, the purpose, the reason, for the  
code are crucial to maintaining a system. The old joke "comments? why  
do think it's called code?" sums up the antithesis of responsible  
programming that seems to be the normal approach. Yes, reading the  
code tells you what it *does* do (until you find a compiler bug for  
example) but it tells you nothing about what it was intended to do,  
what spec it was putatively meeting or what limits on its  
functionality were known about.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: SD: Self Destruct

Tim, you disagreed:

And I completely agree with the above paragraph.

Regards,
Wolfgang

On 2006 June 15 12:28, tim Rowledge wrote:
>
> Comments that explain the intent, the purpose, the reason, for the
> code are crucial to maintaining a system.

+1

> The old joke "comments? why
> do think it's called code?" sums up the antithesis of responsible
> programming that seems to be the normal approach. Yes, reading the
> code tells you what it *does* do (until you find a compiler bug for
> example) but it tells you nothing about what it was intended to do,
> what spec it was putatively meeting or what limits on its
> functionality were known about.

+1

>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: SD: Self Destruct

On Jun 15, 2006, at 8:50 PM, Milan Zimmermann wrote:

>
>> The old joke "comments? why
>> do think it's called code?" sums up the antithesis of responsible
>> programming that seems to be the normal approach. Yes, reading the
>> code tells you what it *does* do (until you find a compiler bug for
>> example) but it tells you nothing about what it was intended to do,
>> what spec it was putatively meeting or what limits on its
>> functionality were known about.

So did tests, pre- / postconditions and counterexamples -- if they  
were known to focus on a given method.

If in doubt whether I should write a comment or a test, I'd go for  
the test.
Nice thing is, that the test not only helps other developers to  
understand the system, but also the computer to automatically...test it.
If I had enough time, I'd write both.

If there were a discussion to introduce a "documentation space" shown  
next to a given method to document it (as it is the case for classes  
right now) I'd strongly argue to use it for tests -- and not for  
comments.
You can find a suggestion for explicitly linking a test to a method  
here:
http://www.iam.unibe.ch/~scg/Archive/Papers/ 
Gael04cLinkingMethodsAndTests.pdf

Today I would either use method properties or blocks to denote the  
method under test (and not comments anymore...;-)
A better example than testing an accessor (as used in the screenshot  
of above paper - boooring) would help also to illustrate the power of  
a five-pane browser, where the fifth pane included tests.
Note that we could also easily extract the concrete types for the  
method under test - and - if we returned the result of a sampled  
method, also the instance variables of the class of the resulting  
object.

Cheers,

Markus

On 2006 June 15 15:20, Markus Gaelli wrote:
> On Jun 15, 2006, at 8:50 PM, Milan Zimmermann wrote:

(actually it was Tim :) )

I agree with what you are saying with two comments.

        While tests are for asserting whether a method, instance, or module behave as
expected under given inputs (including whether the code under test handles
broken preconditions etc), I would say comments are necessary to describe
intent, purpose, broader "cultural" circumstances, design decisions,
including dead end streets encountered when the code (method, instance,
module) was designed and developed.

> If I had enough time, I'd write both.>

        Yes, but I would argue (this is my perception) that writing good comments
takes about 10% of the time of writing good comprehensive tests, so if there
is enough time writing good tests, there is always time to start with a
helpful comment describing intent and purpose (etc - as above). For that
reason, I am not sure in practice writing test first and documentation second
is the best approach, as writing a really "complete" test for a module or
application may be close in time to writing the module or application self,
while writing comments can give good guidance for future readers of the code,
as well as present or future writers of code tests.

> If there were a discussion to introduce a "documentation space" shown
> next to a given method to document it (as it is the case for classes
> right now) I'd strongly argue to use it for tests -- and not for
> comments.

I don't want to argue with that (I think your assumption is if option was
given to only have one such space), but I would really miss my comments (of
the type described above), written to save my (and hopefully others')
backside in the future.

> You can find a suggestion for explicitly linking a test to a method
> here:
> http://www.iam.unibe.ch/~scg/Archive/Papers/
> Gael04cLinkingMethodsAndTests.pdf
>

I think I read your article in the past :) - rereading it I like it, if I
understand, the meta model ties one test method to each method, does it also
play any role in defining the test suites?

> Today I would either use method properties or blocks to denote the
> method under test (and not comments anymore...;-)
> A better example than testing an accessor (as used in the screenshot
> of above paper - boooring) would help also to illustrate the power of
> a five-pane browser, where the fifth pane included tests.

yes

> Note that we could also easily extract the concrete types for the
> method under test - and - if we returned the result of a sampled
> method, also the instance variables of the class of the resulting
> object.

So if developer writes tests first, he/she defines the argument types and
return types that are passed to and returned from the tested methods, and the
types then can be extracted from the tests by tools, making type declaration
unneeded, is that what you are saying, or am I misunderstanding..

Thanks Milan


>
> Cheers,
>
> Markus

> submit our nominations for "most-useful-comment-i-have-seen"
> award of 2006,

>From a piece of code in a system I was maintaining for one of my clients
(written in Visual Basic):

        ' Trust me: this is the right value, and the code
        ' won't work without it. Voice of experience.
        someValue = someValue + 1.8

-- Tammy

Hi wolf

You can be aggressive at me if this release your steam. Be my guest.
I also saw so many broken links on the internet that having some  
central code repository do make real sense for me.
With MC you can browse the comment for each version and check the  
difference between versions.

Note that cs do not have this property since they record that changes  
**happened** not the changes themselves.
(you can have two different changes changing the same method, and if  
you load them one after the other you will not be able to see the  
first one in the changesorter). I'm sure that everybody got bitten by  
that.

Stef

Hi Stef, you invited me again :-)
>You can be aggressive at me if this release your steam. Be my guest.

And again I must decline. I am really sorry, if I hurt your feelings.
I never ever did mean to be aggressive at you. Nor at anyone else on this list.
You all really helped me a lot studying Squeak and Smalltalk. Thanks again.

I am ready to admit that diplomacy is not one of my expertises. If in doubt
while composing emails, I'd vote for clarity.

>I also saw so many broken links on the internet that having some  
>central code repository do make real sense for me.
>With MC you can browse the comment for each version and check the  
>difference between versions.

Thanks! I'll look at that.
>
>Note that cs do not have this property since they record that changes  
>**happened** not the changes themselves.
>(you can have two different changes changing the same method, and if  
>you load them one after the other you will not be able to see the  
>first one in the changesorter). I'm sure that everybody got bitten by  
>that.

Put me on the list of being bitten.

Greetings,
Wolfgang
--
"Dijkstra is right, but you don't say such things!"
(A less courageous programmer)

Ok for me.
Just a real question. I could not have the time to check.
Did the imageformat.txt file changed compared to before?
Because I erase the old one :(

Stef


On 16 juin 06, at 09:06, Wolfgang Helbig wrote:

On Thu, 15 Jun 2006 21:20:45 +0200, Markus Gaelli wrote:

> If there were a discussion to introduce a "documentation space" shown  
> next to a given method to document it (as it is the case for classes  
> right now) I'd strongly argue to use it for tests -- and not for  
> comments.

+1

One could even go further and design new syntax elements (vs. properties  
unknown to the compiler) for attaching tests to methods, so reflecting the  
importance of tests.

In a not so distant future, perhaps, the compiler would only accept code  
if all the tests which are attached to the input pass (this scenario would  
include the case where a method change makes a test fail) who knows :)

/Klaus

> Cheers,
>
> Markus
>
>
>

Hi Milan,

This discussion about a "documentation space" for methods is purely  
hypothetical of course, as the concept of method comments is already  
built in the language and I guess nobody - including me - would  
understand the value of tearing out comments from methods into a  
separate pane. I just mentioned it to illustrate the problem, that  
method tests are not built in yet whether in the language/ meta model  
of smalltalk nor in the GUI - but we could, as we built in comments  
for classes onto a prominent place into the GUI recently...

>
>> You can find a suggestion for explicitly linking a test to a method
>> here:
>> http://www.iam.unibe.ch/~scg/Archive/Papers/
>> Gael04cLinkingMethodsAndTests.pdf
>>
>
> I think I read your article in the past :) - rereading it I like it,

:-)

> if I understand, the meta model ties one test method to each method,

0...n method commands to each method, yes. A method command could be  
also an example, or a counter example.

> does it also
> play any role in defining the test suites?

The part of the meta model described in this paper does not mention  
suites. But the concept of suites is certainly a good one and the  
complete meta model reflects it.
Note that we have the classic suites of independent tests like in  
SUnit. Denoting a test belonging to such a suite could be either done  
technically again by method properties (so the tests knows to which  
suites it belongs to) or by the approach of SUnit, where testsuites  
can be built to include several tests.

But I like to think about many tests also as "cascaded test suites"  
meaning that many long test methods could be broken down and composed  
out of several (one-)method commands. Not that I am saying, we should  
refactor the existing ones, as this does not bring much, but when  
writing new ones, one could consider to write smaller one-method  
tests, which return the "interesting object" they created or  
manipulated, so other tests could be written on top. The advantages:  
smaller test methods should mean better readability in general, more  
reuse of complex test scenarios, faster tests, and concrete types  
that method commands provide.

The developers write which concrete objects are used to test the method.
Using some coverage tool an intelligent test tool can easily store  
the classes of the parameters _and_ result used by a given method  
under test - and display this to the developers, yes.

I prepared an image used for that oopsla workshop on:
http://www.iam.unibe.ch/~gaelli/oneMethodCommandsRDL.image.gz

I display some "concrete examples" there using some bubble help as  
seen on a screenshot here:
http://www.iam.unibe.ch/~gaelli/rdlScreenshot.png

Could be the types certainly also....

> Thanks Milan

Thanks for commenting,

Cheers,

Markus

Hi,

>Just a real question. I could not have the time to check.
>Did the imageformat.txt file changed compared to before?
>Because I erase the old one :(

Yes, it did. Twice, yesterday and today.
The last two lines of it read now:
Changes:
15.06.2006 Questions answered by the memo from Mario.
16.06.2006 Last question answerd by Klaus Witzel

When we are at it, MemoryObject.txt changed as well today.

Greetings,
Wolfgang
--
"Dijkstra is right, but you don't say such things!"
(A less courageous programmer)

On Jun 16, 2006, at 9:15 AM, Klaus D. Witzel wrote:

Before SUnit developers either used comments or ad-hoc class side  
methods to test or exemplify code.
Comments had the advantage to be close to the method under test,  
class side methods reflected the factory character of tests/examples,  
so that they could be composed and SUnit made the tests collectable.

My suggestion is to use class-side methods, which
- denote their method under test using blocks (self test: [aReceiver  
foo: aParameter]) or method properties
- which are collectable as they are in a special method category  
(using the same trick as monticello)
- and which return the object of interest they created, so that tests  
can be composed.

A decent test tool including instrumentation would not only know the  
tests which "focus" on a given method but also all tests/examples,  
which execute a given method along their way.
Saving a method should rerun all the tests which execute it, no  
matter if they focus on it or not.
Having a nice tool like spoon, one could think about an agressive  
mode, where methods are only storable, if there is some automatic  
tests/examples to imprint them.

I currently don't see how these "new syntax elements" you propose  
would look like, and why they are needed. Are we in sync that we  
better store the relationship between tests and methods under test  
into the tests?
Above "self test: [aReceiver foo: aParameter]" idiom can be easily  
implemented as
Object >> test: aBlock
        ^aBlock value
and then easily parsed again. One advantage of using this idiom is  
that you stay dialect agnostic.

Cheers,

Markus

On Fri, 16 Jun 2006 09:56:21 +0200, Markus Gaelli wrote:
Yes, that was (implicitly) among my intentions, for example (not to be  
taken literally) for a method like
isBinarySelector
  ...implementation...
  '(tested isKeywordSelector and: [testing isBinarySelector]) not'

in which the first test supplies the shared "material" for the second one,  
for composition, like in http://en.wikipedia.org/wiki/Relevance_logic 
under "The fundamental novelty in relevance logic is ..."

> A decent test tool including instrumentation would not only know the  
> tests which "focus" on a given method but also all tests/examples, which  
> execute a given method along their way.
> Saving a method should rerun all the tests which execute it, no matter  
> if they focus on it or not.

Agreed, that's what I said.

> Having a nice tool like spoon, one could think about an agressive mode,  
> where methods are only storable, if there is some automatic  
> tests/examples to imprint them.

Yes, a natural extension to what in the above the compiler does to methods.

> I currently don't see how these "new syntax elements" you propose would  
> look like, and why they are needed.

I have nontrivial OO examples written in a non-Smalltalk syntax (no, not  
c-ish ;-) which I can be make available on my web server, if that is  
interesting. Besides of that, I could have remarked earlier that the form  
of a syntax extension doesn't matter to me, as long as it is "acceptable"  
and fulfills the mission.

> Are we in sync that we better store the relationship between tests and  
> methods under test into the tests?

Sure, np: with my suggestion you can easily extract tests out of methods  
(e.g. their parse nodes) and with your suggestion I can easily associate  
tests with their compiled methods - either way suffices.

/Klaus