[Vm-dev] Sounds baaad sounds

[Andreas Raab]

On 2/1/2011 11:34 AM, Igor Stasenko wrote:
> On 1 February 2011 09:28, Andreas Raab<andreas.raab at gmx.de>  wrote:
>> I'm not entirely sure what you're saying here. What's used from the sound
>> package is generated primitives; it's not that there is explicit plugin code
>> anywhere. The same holds for the Graphics and some other packages. And,
>> FWIW, you do not *need* the sound package to generate the VM; you do without
>> it if you're willing to forego the generated primitives (and if there is
>> some dependency in VMMaker that does indeed *require* the sound package,
>> then we should remove the dependency).
>>
> Yes, VMMaker depends on Sound package. And yes, we need to reconcile
> this dependency into some nicer form.
>
> Take a ADPCMCodec for example. It having primitives in its
> private[Decode/Encode][Mono/Stereo] methods.
>
> If i remove ADPCMCodec from image/package, i can no longer load
> VMMaker, because ADPCMCodecPlugin having direct
> reference to ADPCMCodec and taking primitives from it.

Now you can. I just posted a fix.

> It would be nice to move all such primitives to plugin, so VMMaker
> will not have dependency from arbitrary image-side code,

This comes at the cost of having to duplicate the primitive and 
non-primitive versions and to keep them in sync. Or make the primitives 
non-optional. I really do like translated primitives, in fact I had 
always hoped that we'd get more translated primitives since they are 
extremely convenient for all sorts of significant speedups. And who 
knows, perhaps at some point the JIT could make use of the type 
annotations as well.

>>> Pharo could diverge to the point that it could not load a Squeak's
>>> Sound package anymore.
>> Well, let's be a bit realistic. The scenario you are describing sounds
>> excruciatingly unlikely because if Pharo can no longer load Smalltalk code I
>> think it will have much bigger problems than the sound plugin.
> By unable to load, i mean unable to load cleanly. If you have
> unresolved globals, like
> missing superclass - you can still force to load the code, but what
> you get as result?
> Any please tell me why VMMaker should depend on arbitrary image-side
> code, instead
> of having a well maintained separate set of packages , which clearly
> defining what is 'VM' and its plugins.

There's a couple of reasons why VMMaker *has* to depend on a certain 
amount of image-side code. It's not self-contained so there's no way 
that it could not depend on some image-side stuff. Think VMMaker will 
continue to work if we replace streams with Xtreams? Think again. Think 
VMMaker can work in images without method annotation support? Think 
again. So certain dependencies are there and can't be helped.

On the other hand some of the dependencies are clearly unnecessary, such 
as in your example. But other than the direct references to sound 
classes I don't see anything wrong with saying that with a given sound 
package there come a given set of primitives that are translated with 
the VM. If you want a specific set of primitives then choose a specific 
sound package. Just like you choose a specific VMMaker package when you 
want to use a specific version of the VM.

> As i said, since there is no clear separation about what belongs to
> VM/plugin and what belongs image side,
> the only means how to maintain this code is either freeze it for ages,
> or throw it out completely.

I fail to see how either one follows from the premise.

>>> So, it won't be able to load VMMaker or even if it do, then generated
>>> VM code will be different depending on image you using.
>>> What i want to achieve is to make VMMaker be image agnostic, so it
>>> could be loaded cleanly
>>> into any image and produce same code as it was years ago using different
>>> image.
>> That's a nice goal but already untrue. For example, later versions of
>> VMMaker cannot be loaded into pre-3.9 images. So the goal that VMMaker can
>> be loaded into "any" image is already untrue and really not necessary. I'd
>> say your time would be better spent on improving the test suite for the VM
>> so that we can ensure that VMs we care about have the right properties.
>>
> Clarification: being able to load latest VM into latest image(s)
> namely: squeak and pharo.
> This is my goal.
> I don't like that VMMaker can only be loaded/work in some old 3.8 image(s),
> and impossible to use with latest and greatest images we are developing :)
>
> The automation, which i slowly crawling&  doing aims exactly for this purpose:
>   - it takes the _latest_ available image and tries to load VMMaker there
>
> in this way, we will keep VMMaker in sync with development mainline,
> because if something will go wrong, we will know about it immediately.
>
> Another approach is :  'don't care' .. then we could end up with situation, when
> to generate VM you should use some years old crappy image,
> and to run that image, you will need years old crappy VM , which runs
> on years old crappy OS..
> and which in own turn runs on years old crappy hardware..
> So... make your choice.

This is a bit of a false choice as there are several other alternatives. 
I would start with the simplest one: Let's remove direct references 
where they are clearly unnecessary. I just did that and unless I'm 
mistaken you can now load VMMaker without the sound plugin. Another 
alternative would be to move the plugin into Sounds-Plugin (as we do 
with B3D, FFI etc) and use a matching version of the sound package and 
plugin for your VMs.

Cheers,
   - Andreas