Class Libraries, File Naming Conventions, and 'machine.add(...)'
Wow, Since the release of 1.2.0.5, I have been working with miniAudicle, and I really like what I see so far (up to this point, I had been using the commandline version of ChucK). So, I am not sure if there is a separate email list for the miniAudicle, or if I should send the email here, or to the Audicle list... so... One thing that I am trying to do is set up my Class Libraries in a fashion where I point miniAudicle to the root directory, and I put my stuff into a directory structure as follows: Package/ClassLibrary/Make.ck Where 'Package' represents a folder of my libraries, 'ClassLibrary' is the name of the particular library, and the 'Make.ck' file is used to load the individual library files in the order needed by calling 'machine.add(...)' on each of the files. In doing this, I was hoping to be able to enter the following in my program file so that the Mask library gets loaded: machine.add("mjm/Mask/Make.ck"); So, this works when I have just this line in a file, and all the class files get loaded in the proper order. BUT, once I put any additional code into this file, it will not load the class files at all (and this was after restarting the miniAudicle to ensure that there wasn't any conflict with previously loaded classes). Here are the issues that I see so far... (1) Would it be possible to allow for miniAudicle to have multiple paths that it would search for finding these libraries? (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? (3) Any thoughts on why the classes do not load when I have subsequent code in my program (after the 'machine.add')? I could send you an example of what I am trying to do, but this would require sending out my libraries, and I would prefer to sent those out as archives so that the directory structure is maintained. Mike
Hey Mike,
Since the release of 1.2.0.5, I have been working with miniAudicle, and I really like what I see so far (up to this point, I had been using the commandline version of ChucK). So, I am not sure if there is a separate email list for the miniAudicle, or if I should send the email here, or to the Audicle list... so...
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. But in any case, as it looks like these questions are related to chuck in general, we can probably discuss them here.
Here are the issues that I see so far...
(1) Would it be possible to allow for miniAudicle to have multiple paths that it would search for finding these libraries?
This is certainly possible, and seems like a pretty good idea to me. It would also be useful for things like sndbufs and WvOuts, where your sound files could theoretically be in any numbers of distinct directories. It would probably have to be a part of chuck rather than just the miniAudicle, since miniAudicle cant do that without changing the machine.add() implementation.
(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.
(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? thanks! spencer
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!
On 3/30/06, Ge Wang
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:
Yup, your example is exactly what I am doing. So, now this makes sense WHY this error is happening, I just wonder if this would be something to reconsider, as this would require that any files needed by a program to be loaded manually, or from a different file, to make sure those classes are "preloaded" before you call on them.
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?
The word for the day "PARAGRAPHICAL"!!! And yes, this is exactly the case. Mike -- Help the Environment, Plant a Bush back in Texas!
participants (3)
-
Ge Wang -
Mike McGonagle -
Spencer Salazar