Hi Hannes,

> Yes, today for example this would be
>
> ftp://st.cs.uiuc.edu/pub/Smalltalk/Squeak/3.8beta/Squeak3.8g-6527.zip
>
> and
>
> ftp://st.cs.uiuc.edu/pub/Smalltalk/Squeak/3.9alpha/Squeak3.9a-6532.zip
>
Ok.
>
>
>> Big thanks goes to Daniel Vainsencher, who installed it, and made 
>> work the first time! But somehow university got both of us distracted 
>> again...
>
> I see. So where is the server and the last emails which were sent out?
>
He installed it on some machine in Israel :-) using some scheme-shell 
script. I am very bad with shell scripts so I actually tried to fork 
the images using OSProcess, but as this was not ready for prime time 
for OS-X the last time I tried, I was ending up trying to build some 
VMs for Mac with OSProcess included.
Though we did some progress with the help of David T Lewis, Ian 
Piumarta and John McIntosh, I am actually not sure, on which Mac-VM 
OSProcess is running now, with which features of OSProcess included and 
which missing. David, John, Ian?
>
>>> I do not see the fingerprint thing to be an issue.
>>
>
>> I did not explain it very well, I guess. The idea is to harvest all 
>> the unary methods (at least the ones on the class sides) and use them 
>> as "smoke tests".
>> Some of them might never run, but if some ran in an earlier version 
>> and now not anymore, that might mean sth.
>> In order to get them I was thinking to use this fingerprint approach, 
>> as you want to make sure, that no side-effects of some earlier tests 
>> occur.
>> For academic reasons I would be quite interested in this approach: 
>> has this been done before, is it useful, is it feasible?
>
> I see, you are looking for some heuristics to find out which unary 
> methods might be candidates as test cases.
>
> An related idea to this is to look for unary method calls and 
> autogenerate test cases for the classes they belong to.
>
Right, you want to store the knowledge if they are supposed to run or 
not sometime. But this needs manual intervention, and I don't have the 
time for doing this right now. So I just would take the deltas between 
running and not running for the moment, so that I do not need to make 
them explicit / store them as test cases.

What I do need first is to identify if they are running or not, and 
that is why I was looking for some trick, so that I do not have to 
build the image for _each_ method again. Test cases are supposed to 
leave the state of the image untouched (though one could check this 
with the fingerprint too)

By the way: we have only two or so (!!!!!!) assertions in the code, 
pre- and post conditions _are_ a great idea, and they are even better, 
if they are automatically executed from time to time.
Note that I am not arguing that all randomly selected unary methods 
would fulfill these postconditions, but some of them might, and they 
can be treated as full blown tests.
Somehow the whole unit testing culture obviously distracted many from 
writing post- or preconditions, all the effort seems to be spend to 
write some very specific assertions inside the test cases...

There is even an implementation of assertions from Vassili Bykov
http://www.smalltalkchronicles.net/edition2-1/st_compiler.htm
which would make assertions in code pluggable without any performance 
hits, at least that is what he claims.

> For the test cases there might be an interface / query tool for 
> selecting them easily and moving them to the actual test case pool.
>
> However the first step I perceive the very crude test
>
> load a packacke
> 	succeeds
>         fails
>
> already giving 50% of the success of automatic testing.
>
> Or even more basic just to try get working again with the most recent 
> images what Daniel had working.
>
> Or if you do not have time at least document it enough so that somebody
> other in the list might have enough knowledge to help out.
>
I will keep you informed - this time. ;-)

Markus