Sounds baaad sounds
Locked
12
12
 
|
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. > > 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. 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 Levente > > >> Cheers, >> - Andreas >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > |
|
|
2011/2/2 Levente Uzonyi <[hidden email]>: > > 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. >> >> 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? > 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 > separate responsibilities. > > Levente > -- Best regards, Igor Stasenko AKA sig. |
|
|
On Wed, 2 Feb 2011, Igor Stasenko wrote: > > 2011/2/2 Levente Uzonyi <[hidden email]>: >> >> 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. > |
|
|
On 3 February 2011 02:22, Levente Uzonyi <[hidden email]> wrote: > > On Wed, 2 Feb 2011, Igor Stasenko wrote: > >> >> 2011/2/2 Levente Uzonyi <[hidden email]>: >>> >>> 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? > >> >>> 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. |
|
|
On Thu, 3 Feb 2011, Igor Stasenko wrote: > > On 3 February 2011 02:22, Levente Uzonyi <[hidden email]> wrote: >> >> On Wed, 2 Feb 2011, Igor Stasenko wrote: >> >>> >>> 2011/2/2 Levente Uzonyi <[hidden email]>: >>>> >>>> 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. > |
|
|
On 3 February 2011 14:25, Levente Uzonyi <[hidden email]> wrote: > > On Thu, 3 Feb 2011, Igor Stasenko wrote: > >> >> On 3 February 2011 02:22, Levente Uzonyi <[hidden email]> wrote: >>> >>> On Wed, 2 Feb 2011, Igor Stasenko wrote: >>> >>>> >>>> 2011/2/2 Levente Uzonyi <[hidden email]>: >>>>> >>>>> 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. |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |