[Vm-dev] Sounds baaad sounds

[Andreas Raab]

On 2/1/2011 2:00 PM, Igor Stasenko wrote:
> But still , it is good to split the things in two parts: frontend and backend.
> Backend can be translated to primitives directly or just use
> interpreter if no plugin avail... not really matters.
>
> Then a frontend can live and evolve relatively independent from what
> its using at low-level,
> and low-level implementation can be swapped out/replaced by something different.
>
> A great example of such decoupling, which i saw recently was in a new
> filesystem.
>
> Gofer new
>       wiresong: 'mc';
>       package: 'Filesystem';
>       load.
>
> (or load it manually from http://source.wiresong.ca/FileSystem)
>
> There is a class, named FSFileNandle
> which having a protocol for all file operations like open/close etc..
> but for invoking actual operation on OS filesystem it delegates them
> to a class variable Primitives,
> which implements low-level primitive protocol, for example:
>
> FSFileNandle>>close
> 	Primitives close: id.
> 	id := nil
>
> and Primitives are initialized like following:
>
> useFilePlugin
> 	Primitives := FSFilePluginPrims new
>
> and then FSFilePluginPrims having the corresponding #close: implementation:
>
> FSFilePluginPrims>>close: id
> 	"Close this file."
>
> 	<primitive: 'primitiveFileClose' module: 'FilePlugin'>
> 	
>
> In that way, at any moment if we could decide to use different
> plugin/primitives for file system operations,
> we could easily swap them out with another implementation without need
> to hack every place where you using them in class(es), which providing
> public API.
>
> That's really nice design, because you can place all primitive-related
> part into platform/dialect specific package
> and it enables you to use same FileSystem API among not just various
> forks of Squeak, but even among various dialects of smalltalk,
> without need of hacking/porting core API classes!!!

Yes, that is a very nice approach if the goal is to support different 
backend primitives. On the other hand, *unless* that is the goal and 
*unless* there are significant differences in the backend implementation 
the approach borders on needless complexity.

> I think that this approach could be applied to sound prims as well, to
> nicely decouple a front-end API, from low-level backend, implemented
> either primitively or 'naively' or whatever.

It could, but see above. What would be the point of doing this? It just 
adds complexity and unless there is tangible benefit I'm against adding 
needless complexity. I mean, if one indirection is good, two must be 
better, no? ;-)

Cheers,
   - Andreas

>>>>> 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.
>>
> I agree. But keeping the number of dependencies at certain limit and
> cover them by tests
> - that would be good way to ensure that we can recreate each and every
> artifact we were produced
> over years, without hassles in any distant point in future.
>
>
>> 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.
>>
> Well, we're certainly not at the point where we could say: to run this
> image, use this VM. Period.
> Only after we could guarantee that we could easily produce VM out of
> any kind of combinations of packages/plugins,
> then certainly this approach will gain credibility.
>
>
>>> 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.
> Stephane did some refactoring of Sound package, by splitting it into two parts:
>   - Sound base
>    - Sound IU, which is a morphic-specific UI which using sound classes.
>
> In that way, a pharo Sound package potentially could be used even if
> you don't have morphic in your image.
>
> But now there is a certain risk, that if i build VM using Pharo Sound
> package, i may end up with different VM
> if i build it using Squeak's Sound package. This is what i want to
> avoid , because i is _certainty_ a very bad reason
> for forking VM just because Pharo did some cleanup/morphic decoupling
> in Sound package :)
>
>>>>> 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.
>>
> Good. I will check that out.
>
> Also, if we take a new FileSystem as an example (I think this is the way to go).
> and split it like:
>    SoundPrims
>    Sound
>
> then
>    VMMaker could just load SoundPrims
> while image loads SoundPrims and Sound both.
>
> And of course, we could take SoundPlugin out of VMMaker and put it
> into separate package,
> so, VMMaker then will load
> SoundPrims and SoundPlugin to build plugin.
>
>
>
>> Cheers,
>>   - Andreas
>>
>