[Vm-dev] Sounds baaad sounds

[Levente Uzonyi]

On Thu, 3 Feb 2011, Igor Stasenko wrote:

>
> On 3 February 2011 02:22, Levente Uzonyi <leves at elte.hu> wrote:
>>
>> 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.
>>
>
> And may i ask you where i can download Cog package?
> In VMMaker image its repo points to:
> MCHttpRepository
> 	location: 'http://dev.qwaq.com/ss/Homebase'
> 	user: 'anon'
> 	password: ''
>
> try open it..
> Same for VMProfiling..
>
> MCHttpRepository
> 	location: 'http://dev.qwaq.com/ss/Oinq'
>
> so..
> ?

I saved new versions of them from Eliot's image.

>
>>>
>>>
>>>>>
>>>>> 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?
>>
> Yes. But you will see the problem when you will try it.
>
>>>
>>>> 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.
>>
>
> Oh, lets stop arguing. I will make script which will work for me
> (only).. So using it i will be able to continue..
> And then if someone will have problems reproducing it... that their
> problems, not mine..

I wasn't arguing at all, just asked a simple question and noted the way 
you want solve the problem. IMHO there's no perfect solution.


Levente

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