On 8 déc. 04, at 03:56, Andreas Raab wrote:

> 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 know same feeling here and I always have the feeling to paly with 
bombs in the kernel. Just yesterday I do not know why
but I got a bug because changesorter added twice the same class 
definitino in a changeset and I just added a method to systemDictionary 
and classBuilder did not like it. We checked (of course) with marcus 
now this is working but we could not get why....There are really some 
hidden dependencies.

> 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.

This is not what I'm saying but they can help.
>
> 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).

Ok.

>> 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".

I know :)
this is why I raised the question. Communication is important.

>
>> 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".

Yes exactly. I think that the kernel also deserves a simple rewrite 
after 20 years of accumulation and patches
I think that this is crucial but I may be wrong.

Now your comment worries me bit for the following reasons:
I know that you did not imply what I read between the lines :) but I 
prefer to explicitly state
my gut feelings. Because you know me I can't not tell it.

	- first there is still a LOT of shit in the system and there is no 
other words for that. I simply has to open a browser.

	- second we did not deprecated that much methods and we always pay 
attention to avoid to disrupt people.
	But Smalltalk is not a junk. I can show you a lot of examples of the 
changes we did that make a lot of sense
	How this is possible that SystemDictionary 	got so much junk 
accumulated and how can we work with that. 	SystemDictionary got more 
than 15 different responsibilities.
	
	- third: I admit that we got a bit crazy on Beeper but you should not 
throw away
	ALL the good stuff we did because of ONE error.

	- fourth: we are always extremely concerned by the state of the image 
and the system.
	Much more than other people. And this is NOT easy for us because the 
kernel is central
	so we know that we are walking on eggs and would prefer to invent new 
recipe breaking some
	eggs from time to time.

	- five: It would be much easier for us to create our own private 
stream and fix what we want
	there and do not share it with the rest of the community. Really. 
Reimplementing traits took
	us a lot of time, cleaning all the stuff in the process took us again 
a lot of time. So
	if the community considers that we are damaging it instead of helping. 
Please let us know.
	Really. I can tell you that marcus HAS now to focus on his PhD and 
stop been the housekeeper
	of the system.
	
	- six:  What we are doing is publicly available (for example the new 
namespace is on squeaksource)
	and if people do not like it we will not put into the stream but 
create our own stream because we
	want to really be able to work and invent new kernels.



Stef