On Mon, Jan 31, 2011 at 09:08:41PM +0100, Igor Stasenko wrote:
On 31 January 2011 19:21, Andreas Raab andreas.raab@gmx.de 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