Sounds baaad sounds

>
> On 1/31/2011 4:40 PM, Igor Stasenko wrote:
>>
>> Funny thing ..
>> Sound package contains a code, which used by VMMaker for generating
>> sound plugin..
>>
>> which means that depending on the hacks and on forks (Pharo having
>> different Sound package version than Squeak),
>> you will end up with different VMs..
>> Sounds cool yeah? :)
>
> Huh? Are you saying that Pharo contains different primitives than Squeak? If
> not, I somewhat fail to see the problem.
>

>  
> On 31 January 2011 19:21, Andreas Raab <[hidden email]> wrote:
> >
> > On 1/31/2011 4:40 PM, Igor Stasenko wrote:
> >>
> >> Funny thing ..
> >> Sound package contains a code, which used by VMMaker for generating
> >> sound plugin..
> >>
> >> which means that depending on the hacks and on forks (Pharo having
> >> different Sound package version than Squeak),
> >> you will end up with different VMs..
> >> Sounds cool yeah? :)
> >
> > Huh? Are you saying that Pharo contains different primitives than Squeak? If
> > not, I somewhat fail to see the problem.
> >
>
> I don't feel ok knowing that VM depends on right combination of
> classes in Sound package,
> since there is no clear separation between plugin and language side
> implementation.
>
> Pharo could diverge to the point that it could not load a Squeak's
> Sound package anymore.
> 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.
> With things like Sound package its not possible, since they are
> integral part of image, and not separated
> on VM and language side implementations.

>
> On 1/31/2011 9:08 PM, Igor Stasenko wrote:
>>
>> On 31 January 2011 19:21, Andreas Raab<[hidden email]>  wrote:
>>>
>>> Huh? Are you saying that Pharo contains different primitives than Squeak?
>>> If
>>> not, I somewhat fail to see the problem.
>>>
>> I don't feel ok knowing that VM depends on right combination of
>> classes in Sound package,
>> since there is no clear separation between plugin and language side
>> implementation.
>
> 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).
>

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

> On 1 February 2011 09:28, Andreas Raab<[hidden email]>  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.

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

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

>
> On 2/1/2011 11:34 AM, Igor Stasenko wrote:
>>
>> On 1 February 2011 09:28, Andreas Raab<[hidden email]>  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.
>

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

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

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

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

> On 1 February 2011 16:04, Andreas Raab<[hidden email]>  wrote:
>>> 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.
>>
> Hmm..
> Are you sure that following is not 'needless complexity'?
>
> ADPCMCodecPlugin, having ZERO methods at its instance side, and only
> one method at its class side.
>
> ADPCMCodecPlugin class>>translateInDirectory: directory doInlining: inlineFlag
> "handle a special case code string rather than generated code"
> "Not currently hooked into the timeStamp mechanism for VMMaker since
> this would mean replicating code from InterpreterPlugin; waiting for a
> more elegant solution to appear. In the meantime this means that this
> plugin will always get regenerated even if the file is uptodate"
> | cg |
> self initialize.
>
> cg := self buildCodeGeneratorUpTo: InterpreterPlugin.
>
> cg addMethodsForPrimitives: ADPCMCodec translatedPrimitives.
> inlineFlag ifTrue:[
> "now remove a few which will be inlined but not pruned"
> cg pruneMethods: #(indexForDeltaFrom:to: nextBits: nextBits:put:)].
> self storeString: cg generateCodeStringForPrimitives onFileNamed:
> (directory fullNameFor: self moduleName, '.c').
> ^cg exportedPrimitiveNames asArray
>
>
> this method alone could spoil someone's day because as it appears that
> this class serves only as a facade, while all of the behavior lies
> somewhere else.
>
> So, if that is not an example of 'unnecessary complexity', then what it is? :)

> Why bother creating ADPCMCodecPlugin, when code generator can do this
> by itself by simply looking for all implementors of
> #translatedPrimitives
> of all classes in system, and generate necessary primitives out of them.
> Simple, universal and doing the same, because there are no clear
> separation between 'what is a primitive' and what is language side
> code.
> But if that is not a goal, then why bother, right?
>
>
>>> 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? ;-)
> I cannot agree.
> Good design which comes from dependency decoupling and good
> abstraction layer(s) is not 'unnecessary complexity'.
> In fact, in far perspective, it works straightly in opposite direction.

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

>
> On 2/1/2011 5:50 PM, Igor Stasenko wrote:
>>
>> On 1 February 2011 16:04, Andreas Raab<[hidden email]>  wrote:
>>>>
>>>> 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.
>>>
>> Hmm..
>> Are you sure that following is not 'needless complexity'?
>>
>> ADPCMCodecPlugin, having ZERO methods at its instance side, and only
>> one method at its class side.
>>
>> ADPCMCodecPlugin class>>translateInDirectory: directory doInlining:
>> inlineFlag
>> "handle a special case code string rather than generated code"
>> "Not currently hooked into the timeStamp mechanism for VMMaker since
>> this would mean replicating code from InterpreterPlugin; waiting for a
>> more elegant solution to appear. In the meantime this means that this
>> plugin will always get regenerated even if the file is uptodate"
>>        | cg |
>>        self initialize.
>>
>>        cg := self buildCodeGeneratorUpTo: InterpreterPlugin.
>>
>>        cg addMethodsForPrimitives: ADPCMCodec translatedPrimitives.
>>        inlineFlag ifTrue:[
>>                "now remove a few which will be inlined but not pruned"
>>                cg pruneMethods: #(indexForDeltaFrom:to: nextBits:
>> nextBits:put:)].
>>        self storeString: cg generateCodeStringForPrimitives onFileNamed:
>> (directory fullNameFor: self moduleName, '.c').
>>        ^cg exportedPrimitiveNames asArray
>>
>>
>> this method alone could spoil someone's day because as it appears that
>> this class serves only as a facade, while all of the behavior lies
>> somewhere else.
>>
>> So, if that is not an example of 'unnecessary complexity', then what it
>> is? :)
>
> Why do you think I would disagree with your analysis? ;-) ADPCMCodecPlugin
> is not exactly a shining example of compactness and straightforwardness. But
> adding another layer surely won't improve on that ;-)
>
>> Why bother creating ADPCMCodecPlugin, when code generator can do this
>> by itself by simply looking for all implementors of
>> #translatedPrimitives
>> of all classes in system, and generate necessary primitives out of them.
>> Simple, universal and doing the same, because there are no clear
>> separation between 'what is a primitive' and what is language side
>> code.
>> But if that is not a goal, then why bother, right?
>>
>>
>>>> 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?
>>> ;-)
>>
>> I cannot agree.
>> Good design which comes from dependency decoupling and good
>> abstraction layer(s) is not 'unnecessary complexity'.
>> In fact, in far perspective, it works straightly in opposite direction.
>
> I completely agree. But in this case the decoupling already exists. It's the
> primitive where the decoupling happens. The extra indirection is helpful
> only if one needs multiple (non-primitive) backend implementations.

> Without
> that need it's a pointless indirection. For example, would you really
> consider it better design if we added the same kind of extra indirection for
> SmallInteger primitives? That's why I'm saying I don't like to add
> complexity unless there is tangible benefit in return. If there is, then
> absolutely, go for it. But if there isn't, then let's be careful with
> additional layers. They tend to get out of hand much too quickly.
>
>> This code smells. Usually things smell bad because they rot. :)
>
> Which code specifically? ADPCMCodecPlugin? Agreed for the most part. But
> then again, I don't think adding another indirection will address that smell
> particularly well.
>
>> 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.
>

>  
> On 31 January 2011 19:21, Andreas Raab <[hidden email]> wrote:
> >
> > On 1/31/2011 4:40 PM, Igor Stasenko wrote:
> >>
> >> Funny thing ..
> >> Sound package contains a code, which used by VMMaker for generating
> >> sound plugin..
> >>
> >> which means that depending on the hacks and on forks (Pharo having
> >> different Sound package version than Squeak),
> >> you will end up with different VMs..
> >> Sounds cool yeah? :)
> >
> > Huh? Are you saying that Pharo contains different primitives than Squeak? If
> > not, I somewhat fail to see the problem.
> >
>
> I don't feel ok knowing that VM depends on right combination of
> classes in Sound package,
> since there is no clear separation between plugin and language side
> implementation.

>
> Regardless of how these packages might be reorganized in the future,
> one thing that can be of immediate practical benefit is to document
> the dependencies in the form of unit tests.
>
> I have started a few tests in SqS/VMMaker/MiscPrimitivePluginTest
> (prompted primarily by a Pharo refactoring that has been causing
> problems for VMMaker). This has several benefits - it documents the
> dependencies; it makes it easy to detect that a change in the image
> is causing problems for VM code generation; and it lets you know
> if you are running a VM (plugin) that is missing support for some
> primitive that should have been generated from source in the image.
>
> If sound is a potential source of problems, then it would be great
> if someone can add some more tests to provide coverage for those
> dependencies.
>
> Dave
>

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

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

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

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

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

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

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

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

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

>
> Hi andreas
>
> So if I summarise the situation:
>
> igor wants to refactor code so that the VM can be shared by several groups of images having different code
> and make sure that the vm can be built on each of these groups so that the code/vm is always in sync.
> and you are against stating that this refactor brings extra complexity (which I do not really see but let us say that you are right).
>
> Now my question is what is then the process, if one of these groups change image side that gets an impact
> that leads to the fact that it cannot build a VM?
> I ask because the semaphore input has not be integrated on the windows VM since a year a guess and as a consequence
> we are forced to use a polling system instead of a event based one.
> The conclusion of this discussion to me seems that while you are against git "because it helps people forking and fork are evil", this
> discussion seems to show that your position would lead exactly to force people to fork. I'm not against this because forking may be good to avoid truck factor but this is not something that we wanted to do.
>
> May be I'm stupid and I do not understand well but I'm sure that you will explain it to me.
>
> Stef