Greetings!
awesome! glad its working out for you. Uhhh, its fine by me if miniAudicle questions go either here or to the audicle list, but if anyone thinks thats too off-topic (Ge...?) maybe i could set up a separate list for those questions.
The miniAudicle is a (great) way to chuck, and most relevant to this list, I reckon um hmm...
(2) Am I using 'machine.add(...)' for its intended purpose (in loading classes)? Might there be a good reason to add another 'machine.load(...)' that does the same thing as 'add', except it does not spork a new shread for each call? This 'load' function could also be made to keep track of what files have been loaded, and any time there is a file that gets loaded more than once, any subsequent loads could just be ignored? (This might also change the miniAudicle interfact to include a button to load, in addition to the other buttons.) Would this function be best named 'load'/'include'/'import'? Which one?
Seems reasonable to me to use machine.add() for loading classes.
while machine.add() does spork a new shred, programs that only define a new public class will exit immediately anyways. Also, chuck already rejects files that try to redefine public classes, with a compilation error. So functionally machine.add() operates very similarly to such a load routine, even though they might be conceptually different operations. Although there are certainly cases where extended class library loading functionality would be desirable.
Yeah, machine.add() is way to go for now. It's different from a static 'import' or 'include' in that it happens at runtime. We are however working on the include system, which will hopefully make loading much simpler/safer and automatic in places.
(3) Any thoughts on why the classes do not load when I have subsequent code in my program (after the 'machine.add')?
Thats strange... I have not come across this behavior in similar programs. Are you getting any unusual messages on the Console Monitor?
What kind of code do you have after the machine.add(...)? If the code tries to use the classes in the files you are adding, that won't work in the same file because machine.add() is a runtime construct. For example: foo.ck --- public class Foo { /* stuff */ } --- bar.ck --- machine.add( "foo.ck" ); Foo foo; // this won't pass the type checker --- running bar.ck first (the intended usage) would result in a type checker error 'unknown class Foo', since foo.ck won't be added until runtime and so 'Foo' is unknown when bar.ck is compiled. for now, you would have to separate the machine.add(...) into a different file from such code. this part of the language really needs work, and we have been actually working on it. hopefully we will have some working prototypes in a few releases from now. Wow, that was a big paragraphical mess I just typed, and I am not even sure I answered the right question... Is this the problem you were referring too, Mike? Doh, Ge!