[Vm-dev] Sounds baaad sounds

[Igor Stasenko]

On 3 February 2011 14:25, Levente Uzonyi <leves at elte.hu> wrote:
>
> 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.
>

Yes, and that's boiling down to same issue: process & who taking responsibility.
What is an 'official' location that everyone should use for builds?
Yours, mine, or somebody else's?
If there is no common source, then there is no common artifact, which
you can produce out of it.

This is exactly the problem with Sound package. I can't put in my
config a single source which everyone using. Instead i should use two
different forks of it
depending on image which is used for loading VMMaker. And that sucks.

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


-- 
Best regards,
Igor Stasenko AKA sig.