[Vm-dev] Sounds baaad sounds

[Igor Stasenko]

On 2 February 2011 10:55, Andreas Raab <andreas.raab at gmx.de> wrote:
>
> 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.
>

You did fixed it.. but this is not a fix i wanted to have:
" Weakly reference to ADPCMCodec and AbstractSound from VMMaker to
allow loading without requiring sound package. Also make translated
primitives more forgiving by skipping any translated prims that aren't
present in the image. "

This is not a solution to problem. Because you still have dependency ,
now even worse than before, because its not uncovers itself
immediately,
i mean now there is nothing tells to developer that VM depends on some
classes from Sound package, and that you should be careful when
changing stuff there.

So, from development process perspective your fix even worsened
situation, because now instead of explicit dependency, which shows
itself immediately when you loading code,
we have a hidden implicit one.

Yes the example how new FileSystem made was just an example how to do
things properly in future.
Its not clear if it applicable to Sound package in same way, but it
shows that clear separation between high and low level can be made
nicely and cleanly.

What i actually wanted to see as a "FIX" to VMMaker is:
- Create a new package , say "SoundPrims"
- put all classes which used by VMMaker there , remove these classes
from Sound package.

Now, VMMaker should have _explicit_ dependency from SoundPrims
And Sound should have _explicit_ dependency from SoundPrims.

This minimizing the chances that someone someday step over that code
and do something nasty, without knowing
that it could affect the VM stability, which we building for various
images, not just for specific ones.

Simple enough?


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

Of course you wrong. We have two different Sound packages maintained
by different parties.
Where the guarantees that changes which one party will make in future
won't affect the code which goes to VM side?
What are chances that changes which one party make will go unnoticed
by another one? What if one party would want to significantly diverge
own branch,
which affects the language side code, and as side effect (unwanted
one) it could affect the VM-generated code? How to ensure that it
won't happen?
These are the questions which i want to have answered.

And if we don't find a solution to that, then it will mean that either
these two parties now should have own forks of VM, or have no way to
clearly state what code goes into VM
and what is not  (again: freeze for ages or being thrown away).

I cannot claim that my VM is equal to yours, once i using different
packages for generating its code.
So, next time when i will have some issues, i will be on my own,
because you can always say: you are not using "proper" sources for
generating VM, so its your own problem.
So, lets make sure that we all using same proper sources, and don't
pretend that apples and oranges are the same, because they are fruits.


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

Shady in terms of dependencies and hidden knowledge. Maybe for you the
layers of system is transparent and you can clearly see what are
dependencies
between them. But put yourself on place of the guy which has no any
clues about it.
He only started and wants to build own VM, so at some day when he
learn enough he could contribute own VM hacks to community.
But now, the problem is, that without knowing everything he can't even
start, because we don't have things which can be reproduced
independently from who is sitting before keyboard
and pressing "doit" key.


>> 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 ;-)
>

Arrogance neither.

If development process assuming that we cannot do mistakes, and there
are no measures to minimize the chances of doing them,
because it was designed by/for people who never doing mistakes, then
its not good process.

Humans tend to do a lot of mistakes, and we should invent the process
which takes this into account and deals with it,
otherwise we can simply state that humans are not fit for developing
squeak VM or even code in smalltalk.

And yes, no methods with <var:declareC:> were touched..  But that is
not necessary to put VM on knees. Just insert  an instance variable to
ADCPCodec class
before all existing ones and see what will happen.

>> 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's a little different. Exposing VM internals to FFI not makes VM
more fragile in a sense,
that i can (re)produce same VM from its sources as artifact whether i
exploiting these features or not.
You are mixing concerns here.

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

See the above:  refactor Sound package and move all VM-specific code
into separate package
and make VMMaker to be explicitly dependent on that package.

> Cheers,
>  - Andreas
>
>



-- 
Best regards,
Igor Stasenko AKA sig.