[Vm-dev] Sounds baaad sounds

[Andreas Raab]

On 2/1/2011 7:33 PM, Igor Stasenko wrote:
>>> And what people usually do with things which rotten? They throw them out.
>>> Yeah, there are few, who so passionate that they could overcome the
>>> disgust and start digging in rotten pile of cruft in hope to find
>>> precious gems.
>>> But usually this not happens often, because people having more fun things
>>> to do.
>>>
>>>
>>> Hopefully the above explains better what i meant by saying:
>>> "the only means how to maintain this code is either freeze it for
>>> ages, or throw it out completely."
>>> to which you replied with:
>>> "I fail to see how either one follows from the premise."
>> And I still don't see it :-) You seem to forget the option to simply fix
>> what's broken. That's so obvious that I still don't get why freezing or
>> throwing away would be the only options.
> Well, from your words it sounds that i should not fix it. Or should
> not do it like i proposing.

Let's see, if I read your messages correctly, the immediate concern was 
that there is a dependency of VMMaker on the sound package which is 
fixed by now. Then we went on discussing design choices, but as far as I 
can tell this was a general discussion, not really tied to any concrete 
issues that you wanted to address. If you're proposing a particular 
change other than removing the dependency I'm not sure I fully 
understand what you are proposing. I'm most definitely not against 
fixing what is broken; however as I'm sure you can tell that I'm 
(generally) opposed to adding complexity unless one can point to an 
issue that is being addressed by the extra complexity.

> The problem that i (why i? WE!) need to have guaranteed way to
> reproduce the VM sources, no matter what base image i using
> (be it Pharo, Squeak or Cuis or Croquet).

I don't see why this would be a problem. In fact, I believe you *will* 
generate identical sources from the different images. Am I wrong?

> In cases when generated VM code almost directly or indirectly or in
> some nontrivial way depends on code inside an image (which not
> explicitly declared as part of VM), this is problematic, because
> obviously nobody could be able to track all these dependencies,
> because then it requires too much knowledge and magic incarnations to
> simply build same VM as you built , and therefore when people who know
> all these shady corners in labyrinth leave our community at some day,
> then we will be left with an artifact which no one will be able to
> reproduce sitting at home and running a build script.

I understand what you're saying on general principles but there is 
absolutely nothing "shady" about translated primitives. They have type 
annotations so that they can be translated to C but that's about it. 
What is "shady" about them? More importantly what are you proposing? 
Nuke them all?

> It appears that pharoers incidentally touched stuff which are not
> supposed to be touched under pain of death.

Like what? Methods with <var:declareC:> in them? Isn't that a dead 
giveaway that MAYBE someone with a bit of experience in the VM should 
look at this? Ignorance is not a valid excuse you know ;-)

> Sure thing they was not aware that thing which they touching contains
> behavior which goes directly into VM. So, i'd like to not see such
> incidental refactorings in future. Because people having right to
> change the language/system in the way they want without fearing that
> they incidentally will change the most heart of a system - VM. And for
> that we need a clear separation with BIG red banner: if you cross that
> line - there is no turning back.. (or something like that ;)

Now that's weird. If I recall correctly, you were one of the guys who 
wanted to expose everything via FFI etc. Have you ever considered what 
ignorance like in the above would do to your system when you do that? 
That the argument you are making is precisely the argument that I 
usually make regarding fences and why proper high-level abstraction in 
the VM are a Good Thing (tm)? Quite odd. But in any case, I give you 
that point. I agree that having the proper abstraction behind a fence is 
a Good Thing (tm) and a desirable goal. How do you propose we get there?

Cheers,
   - Andreas