[Vm-dev] Sounds baaad sounds

Igor Stasenko siguctua at gmail.com
Thu Feb 3 08:51:38 UTC 2011


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

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

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



-- 
Best regards,
Igor Stasenko AKA sig.


More information about the Vm-dev mailing list