Hmmmmm. more weirdness; ----------------------------- 2 => int n; Shred foo[n]; while(1) { <<>>; second => now; } ------------------------------- Run that a few times for various values for n. Something very weird is going on here, -1266432768 seems like a very odd number as a shred id, especially when the VM monitor (running these in the mini) reports only a single shred. Kas.

On 19/11/2007, Ge Wang wrote:

Hi!

Hi Ge! This is bug, where the internal ID is uninitialized for user instantiated

Shred instances. This has been fixed in CVS (unsporked shreds id default to 0).

Very good! I now see why normal shreds don't start counting at 0 like everything else, good solution. However, it brings up the bigger question of what this user

created Shred might be used for, since currently, there is no facility to spork from these Shred objects (at the moment, Shred instances are internally created and can be accessed afterwards). For now, perhaps it makes sense to disable Shred instantiation from code? Thoughts?

Yes, I admit I have no real use for them right now but if spork ~ my_function() @=> Shred foo; is useful (and I think it is, giving shreds names might lead to more readable code if we are dealing with a situation where we need to remove shreds from the VM) then I'd say creating a array of empty Shred objects would be useful too. We could assign shreds to them as they get sporked and deal with larger numbers of shreds with less efford. I could imagine this getting useful if we have shreds that represent something like synth voices, we know how many the CPU can take and we want some sort of voice management or something. How useful this is depends more or less on the member functions the Shred object has. .exit() and .id() were easy to assume but are there more? The documentation is rather vague about that class, aside from noting it exists. class Super_shred extends Shred { //blahblah} ....on the other hand gives us a object that can't be used for anything right now so I would be fine with disabling that until somebody has a good idea on how to use a thing like that. Not the most fruitful of experiments, this, so far, but I do quite like the idea of making the variables that the function had accessible as members of the object that it becomes once sporked. How hard would that be to implement? It's not worth a lot of work as we can get equivalent functionality by using a class and sporking from there but as a concept it makes sense to me, particularly with regard to inter-shred communication at low syntax-overhead. I'd say that's a topic that does deserve our attention in the coming time but perhaps there are better ideas. Also, that whole "scope" thing to the --shell, is that a plan that has since been discarded and and should I stop lusting after it? That sort of functionality is the one thing I envy our friends in the SuperCollider world over. I've been talking about that rather a lot and if there was some sort of outline like say "we won't do it for now" or -say- "after garbage collection" I could relax about it on the list/ WiKi, I'm sure people are quite bored with me going "I want that, preferably graphically in the Mini" all the time by now :¬). Thanks for your help, hope you are well, Kas.

On 19/11/2007, AlgoMantra wrote:

oh shit, i just swallowed a whole peg of rum.

Could be good? http://xkcd.com/323/ Cheers! Kas.

On 19/11/2007, Ge Wang wrote:

This is bug, where the internal ID is uninitialized for user instantiated Shred instances. This has been fixed in CVS (unsporked shreds id default to 0).

One more thing, perhaps you already implemented this but in this code; ---------------------------- Shred foo; spork ~ test() @=> foo; second => now; <<>>; foo.exit(); second => now; <<>>; fun void test() { while(1) second => now; } ---------------------------- I'd like the second call for foo.id to return 0. This is useful if test() is a function that performs a specific task, then exits and we'd like to know if it already did so. IMHO (but perhaps others have better suggestions) this would be cleaner then defining a extra variable for this (especially as we may not know how many we need) and if 0 is the id for non-existant shreds this would also save making a .ifExists() (or similar) call. Perhaps there are unforeseen downsides to this? Keep on sporking, Kas.