[Vm-dev] Sounds baaad sounds

Igor Stasenko siguctua at gmail.com
Wed Feb 2 14:55:34 UTC 2011


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

Yeah.. probably because i am talking not about technical details here,
but about changing the process how
we developing the VM-related stuff. But see more below.

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

Well, it needs analysis.
Pharoers split this package on two parts. Which made base Sound to be
not dependent on morphic.
I'm not ready to answer what exactly should go to VM-related 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?
>
> 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?
>

It is clearly more process organization issue rather than technical one.
Splitting is required to separate responsibilities between
VM-developers and image developers.
So, in addition to splitting ,we put SoundPrims to VMMaker repository.
This will guarantee that everyone will use same branch
of SoundPrims irrelevant to fork(ed) image, as long as we using same
VM and as long as code related to VM i prefer to see it at right place
and being managed by right people who taking responsibility that VM is
working and stable.

Sorry that i were not precise about that earlier, but i thought that
it is obvious. Split required to reassign responsibilities,
not just because it is nicer/cleaner or otherwise introducing
unnecessary complexity etc etc.


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

And so, when you leave nobody will be able to reproduce your process ,
because it is not open
and not documented. We should move away from that practice.
Knowledge should be available in form of sources and configuration
lying at public places,
not in form of packaged .zip files released once per year by single person.
Take a CogVM for instance. Why i should use image, stored in repo?
What if i want to use different one for building VM?
How i can reproduce same package/source set and put it into different
image and be sure it will produce same
VM as in original image?
Can anyone, except Eliot reproduce such image from scratch by loading
related packages from publicly available places? (I know the answer,
but i want to hear yours).

It is a pain to extract this knowledge, but i doing it anyways.. So,
please be patient :)

Clearly, we need such an artifact, which can continue living without
its original author(s) otherwise nobody will use it.


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


All such cases should be properly documented. if class used in special
objects array
or its slots layout used by primitives, this should be stated, that no
changes should be made
unless you synchronously change the VM.
The argument was about visibility of such things in form of warnings
and documentation,
to minimize the chance of affecting this code by some random
refactoring (hehehe :).
And of course separating responsibilities and not mixing high-level
with low-level helps in that direction too.

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

I am against fences. Fence means that you're not able to do something
without getting pass.
I want to be able to pass through fence when i want.
But i don't want to find myself walking on minefield, because someone
forgot to put sign there.

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

Because as i said, SoundPrims have to be maintained by VM developers
as long as it is an integral part of VM,
and as long as same VM shared among multiple forks.
How people using these prims in their forks, or if they are using them
at all is not a concern of VM developers.


> Cheers,
>  - Andreas
>
>



-- 
Best regards,
Igor Stasenko AKA sig.


More information about the Vm-dev mailing list