QA in Squeak (was: Re: [Bug][Fix] Settingcopy/paste-keypreference under Windowsdoesnot work)

Andreas Raab andreas.raab at gmx.de
Wed Dec 8 02:56:16 UTC 2004


Hi Stef -

> - the compiler and VM are not changing that often have you some data?
> (at least from my perspective), even if marcus will push the compiler of
> anthony with no full blockclosures.

I have no data on this but speaking from gut feeling changes in these areas 
are pretty rare.

> - if knowledgeable people do not have the time to review then we are in 
> the situation where nothing will really happen. So the dilemna is having
> a system that does not improve that much but is stable or a system that
> changes with the risk that some stuff may break.

That is correct and there is not much we can do about it. Personally, I 
think what we want, e.g., either rapid evolution at the cost of potential 
errors or slow and very stable evolution depends on the part of the system 
we're working on. I don't mind if some morphic text editing problem gets 
fixed three times over if it just doesn't quite work right but I *do* mind 
very much if that happens to VM, Compiler, or Kernel.

I do mind this in particular if it results in a situation like we have 
today - an already released version of Squeak (3.7) one that's about to be 
released (3.8) with code that will break if you ever touch it. That's a 
time-bomb, pure and simple.

> So I think that we should write more tests and this is the responsibility 
> of the community as a whole and run them regularly.

Tests are NOT a silver bullet solving every problem.

In this particular example no test in the world would have shown you what is 
broken unless you add tests for whether the language actually works that way 
you think it does, e.g., all of the subsystems that ever used the fact that 
#(nil) created #(#nil) would have to include tests to document this fact. If 
you start requiring this you might as well require tests for whether blocks 
work properly (as a matter of fact that problem is going to be significant 
with the new compiler), whether message sends aren't suddenly early bound 
etc. That way just lies madness.

> I have a question about the code of the VM. Dan and recently nathanael
> told me that the VM code was degrading.

What do you mean by "degrading"?

> I imagine that dan also fixed a lot of the problems with the port
> in 64 bits.

Dan (or rather Ian) fixed many of the problems which came across because 
people used shortcuts which were entirely appropriate before anyone 
considered that we may have a Squeak VM with different integral sizes for 
pointers. I would not call this "degradation" just something that people 
didn't exactly worry about since it just didn't matter at the time, like, 
for example writing "3" instead of "BytesPerWord-1" (the latter works for 
64bits the former doesn't).

> But nathanael told me that there was stuff defined in different
> places (I do not remember quite precisely but this is not crucial
> for my question). Is there a discussion between the
> VMs maintainers to sit down and clean a bit or this is more incremental
> as nobody as time?

There is a whole vm maintainers mailing list which can be used exclusively 
for this purpose and Squeak-dev itself wouldn't be a bad place to start the 
discussion. I encourage people to state their concerns if there are any - 
nothing is worse than having you tell us that "someone told you that the VM 
is degrading".

> Because this would be a good way to have another step in QA: having some 
> time where stuff get cleaned.
> I think that this is what we are doing (too slowly with
> the kernel but we also do not have that much time) and you with Tweak as a 
> massive/ultime clean of Morphic :).

I don't want to step onto your toes here but there are times when I have 
serious problems with your definition of "cleaning". To me, cleaning means 
mostly tidying up interfaces, maybe removing a few of those that aren't used 
or really broken but keeping the important interfaces the same and 
essentially in the same place. To me, "cleaning" does not mean depracating 
hundreds of interfaces (and dropping them at a speed which is way to fast in 
my understanding), moving stuff into places where even people with holistic 
memory have a hard time to remember what the place is called today etc. This 
I call a "rewrite" and that's why I would never consider Tweak to be a 
"cleanup".

Cheers,
  - Andreas




More information about the Squeak-dev mailing list