[Vm-dev] Sounds baaad sounds

Levente Uzonyi leves at elte.hu
Thu Feb 3 01:22:47 UTC 2011


On Wed, 2 Feb 2011, Igor Stasenko wrote:

>
> 2011/2/2 Levente Uzonyi <leves at elte.hu>:
>>
>> On Wed, 2 Feb 2011, Igor Stasenko wrote:
>>
>> snip
>>
>>> 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).
>>
>> I did create my own version starting from a 4.2 trunk image and I could build a VM from it. So the answer is yes. And if I can do it, then others can do it too.
>>
>
> Can you give me instructions how to do that? Because i don't have one.

I didn't document the process (it was a mistake), so I can't give you the 
detailed steps. The idea is to load external pools, VMMaker, Cog, 
QVMProfiler and the external plugins (based on the mcm or the 
configuration + whatever you want). If MC complains about missing 
classes/dependencies then fix them. If you keep the transcript open, you 
can also get some clue about what else you have to fix. I don't have time 
nor need to do it again, but I can send you the image if you find it 
useful. Note that I didn't update it since July 2010 and it has some 
cruft inside.

>
>
>>>
>>> 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.
>>
>> Almost everyone uses such VMs, so your statement is not true. It's safer to the community if the information is available to everyone, but in the current case I have the feeling that it's not about safety.
>>
> Then about what?

Naive question. You want automated VM builds, don't you?

>
>> snip
>>
>>> 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.
>>
>> So which is better?
>> - duplicate the code in the VM and image
>> - remove the code from the image and use only the primitives there
>> - every image should depend on an external package
>>
> There is no need to remove code. The only need is to split package to
> separate responsibilities.

So you prefer the third one.


Levente

>
>
>>
>> Levente
>>
>
> -- 
> Best regards,
> Igor Stasenko AKA sig.
>


More information about the Vm-dev mailing list