Hey Ge -- When you guys are doing the GC implementation, could you also put in the ability to disable it by the user? I can imagine there are times when having a big GC kick in wouldn't be a good thing to do. brad http://music.columbia.edu/~brad On Mon, 29 Jan 2007, Ge Wang wrote:

...

Is there a way to explicitly destroy object references?

Currently, ChucK is undergoing much development in terms of garbage collection. In the released version, objects are ref counted, but not all references are released correctly yet. This means either structuring code to minimize garbage, or "manually" releasing references, in order to control memory usage for now.

Someday soonish, ChucK is going to be a (hopefully properly) garbage collected language, which means the programmer will not have to manually release objects after use.

...

For instance, in a loop, I am creating an array of objects like so:

Object objects[4]; 0 => int count;

for(0 => int i; i < 4; i++ ) { new Object @=> objects[count]; count++; }

Now how would I delete the Object referenced at, say, objects[0]?

In this particular case, by assigning new instances of Object into objects[0], the old objects should have been released automatically. You can also assign 'null' to object references to decrement their ref counts, and if no other references exist to that object, it will be released.

Also, as you probably know, one can declare arrays of null references, to reduce redundant/useless instantiations:

// array of null Object references Object @ objects[4];

We are still experimenting with various options for garbage collecting ChucK, and will likely adopt two or three approaches for initial release/testing, selectable by the programmer. In any case, we don't expect any syntax-alterations to the language. We will continue to keep you posted.

Thanks!

Best, Ge!

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Ge Wang wrote:

Hi Brad!

...

When you guys are doing the GC implementation, could you also put in the ability to disable it by the user?

Definitely. We plan to provide, at the initial GC release stage, options for disabling garbage collection and for choosing among several implementations. As time goes on, we hope to narrow this to the option to one or two methods, plus the option to not automatically garbage collect.

...

I can imagine there are times when having a big GC kick in wouldn't be a good thing to do.

Yup. We are looking at different approaches to real-time friendly GC that makes sense for ChucK. We hope to adopt some kind of generational, incremental GC scheme. Nonetheless, it would be good to have the option for disabling it all.

i implemented a realtime GC once. if you'd like me to dig out the source code just tell me. best joerg -- http://joerg.piringer.net http://www.transacoustic-research.com http://www.iftaf.org http://www.vegetableorchestra.org/

Bear (bare?) with me, Is it advisable to have Events as instance variables so that shreds sporked from that instance all reference this internal event? The code below works in practice. (I have not run the code example, but I do something similar in a program). Are there any pitfalls to doing this, rather than explicitly passing in the Event, as is shown in the language tutorials? Many thanks in advance, D // event as instance variable across shreds // ----------------------------------------------------------- class Object { new Event @=> Event event; function first() { while(true) { this.event.signal(); 1::second => now; } } function second() { while(true) { this.event => now; <<< "recieved event" >>>; } } } Object object; spork ~ object.first(); spork ~ object.second();