[Vm-dev] Sounds baaad sounds

[Andreas Raab]

On 2/2/2011 2:07 PM, Igor Stasenko wrote:
>> 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:

Sorry to hear that, but if you're telling me that the problem you're 
having is that you can't load VMMaker without loading the sound package 
and that you'd like to see that change, don't be surprised if I fix the 
problem you're telling me, not the problem you're having in the back of 
your mind. My Jedi powers are weak you know :-)

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

Let's be a bit more explicit: Which classes and methods would be 
included in that?

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

Certainly. But see below.

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

These are good questions. But one thing that I don't understand is why 
you think the SoundPrims package would be unaffected by these issues. 
People can change that package just as easily as the Sound package, and 
given that you seem to be saying that some Pharo folks have changed the 
prims in the Sound package without knowing what they were doing, what 
makes you think they would have left a separate SoundPrims package 
alone?! And why do you think that the SoundPrims package would stay in 
sync over time? I mean, all the (good) issues you are raising apply 
every bit as much to a SoundPrims package as they apply to the Sound 
package. So if there is a solution that you're having in mind for the 
SoundPrims package, can't we apply the solution directly to the Sound 
package and just get over it?

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

You seem to be misinterpreting the usage of (in particular) translated 
primitives. You *can* generate a VM without translated primitives. They 
are used purely for optimization. That means your VM may be different 
from mine, but that's no different than you choosing a different set of 
plugins to generate or (not) loading other packages such as Balloon3D or 
Freetype. In both cases our VMs will differ and knowledge about what is 
required to build exactly "my" VM is always needed (in fact, that is why 
I always produce source releases with generated sources so that people 
don't have to guess).

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

So true. But how exactly are your changes going to fix that? And why 
single out Sound? Just insert an ivar before everything else in class 
Process. Or Semaphore. Or Behavior. Or Form. Or Whatnot. Seriously, I 
understand the above line of thought but bringing in an argument along 
the lines of "ZOMG, I cannot add an iVar to class AbstractSound, we need 
a SoundPrims package!" make no sense to me. The latter does not follow 
from the former. Maybe I'm missing something here but I don't understand 
why you're even bringing such an argument in here. It seems entirely 
unrelated.

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

I'm just amused by the apparent inconsistency of your position regarding 
fences :-)
But never mind, this is not the point 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.

Personally, I'm still not convinced that the added complexity is worth 
it, though others might obviously disagree. I'm curious about your 
answers to the question above, i.e., why you think that a SoundPrims 
package would make a difference and if we couldn't use whatever you're 
planning to keep it in sync with the Sound package itself.

Cheers,
   - Andreas