On Saturday 14 February 2004 04:55, stefan kersten wrote: > > consider an installation running 12 hours a day. the program > creates objects (events, synthesis patches, processes) > dynamically and non-deterministically, e.g. based on room > temperature or the number of unemployed people in germany > (which seems to be unbounded). > > or imagine a performance involving devices with limited > resources (e.g. PDAs). i wouldn't want the application to > crash _anytime_ because it's running out of memory. it's not > really comparable to a recording situation, where you can > start over when that happens. > > so yes, for some applications i'd call it an unreliable > hack. > Sure, I agree, in your application, it's better not to use a conventional GC. I was just saying, that in _some_ applications, it's not a problem at all. I was just trying to remind people not to automatically reject the approach of deferred GC, when the running time of the application is time-limited. (And of course I wasn't talking about PDA's here. Was I? I certainly apologize if I gave you the impression that I advocate using a garbage-collecting language for a flash-based system and/or PDA. I'm quite curious where you got this idea(?)) Larry Troxler > > > when do you turn it back on? > > > > Simple. You do a full GC whenever you stop a real-time > > run. > > that's like cleaning your appartment whenever you have > nothing important to do. there's always something to do, so > you have to do the cleaning incrementally and if possible > non-interruptively, or the garbage will spill out of the > windows. > haha. It all depends. I could say that it's like trying to clean the garbage out of your car while you're driving. I think the point is, that we probably agree, and we are just talking about different application. > i'm not opposed to garbage collection per se, i just think > that there are implementations better suited for realtime > work (like those found in supercollider, rscheme and maybe > squeak) than the reference counting or mark-and-sweep > algorithms used in most scripting languages. supercollider, > as a bonus for object oriented folks, also has constant time > method lookup. > Hmm, note to self - look into Supercollider... Actually I have no doubt that you are right, in the sense that I understand that supercollider is a langauge developed specifically for real-time sound generation. I really need to look into it. > > Incidentally, it's interesting to see that there is not much mention of > > using Ruby instead of Python, in the Linux computer-music world. > > Presumably Python must still have an advantage in some areas? > > i don't know if there are big differences in performance > (but since we're talking about garbage collection, ruby has > a mark-and-sweep collector). i, for one, favor ruby for its > cleaner object model, and snd has a ruby but no python > interface :) > > <sk> Actually, that was just a general question about the two languages, and not specifically about comparing the GC between the two; I'm sorry if that wasn't clear. I had got the impression that Ruby is intended to obsolete Python, in the sense that there are no major disadvantages to using Ruby vs. Python (apart from the current popularity of Python, of course). But, at least on this list, it seems that Ruby has not yet displaced Python as the scripting language of choice, and I wonder if there is a valid reason for that, apart from inertia and politics. Larry Troxler
