Re: [chuck-users] preprocessing chuck (was: Time to SMIRK!)
On Sat, Oct 4, 2008 at 3:47 AM, Scott Wheeler
Michael Heuer wrote:
Might you be able to comment on this further? Many of us are clamoring for an include/import mechanism. Even if what you have done is messy, it sets precedence for how others might do the same.
I wrote a ChucK preprocessor a while back:
http://developer.kde.org/~wheeler/files/upchuck
It checks the current directory and all dirs in the environment variable CHUCK_DIRS for .ck files, and then you include stuff with:
#include (Sequencer)
It creates a temporary ChucK file to execute and also adjusts error messages so that they correspond to the correct source file.
That's great, but 'upchuck' now means something else for chuck. ;-) Anyways, you know you easily can use the C preprocessor on chuck files no problem: a.ck: <<<"This is a">>>; #define TEST "Test" #include "b.ck" b.ck: <<<TEST>>>; command line: $ gcc -x c -E -o test.ck a.ck $ sed 's,^# ,//,' --in-place test.ck $ chuck test.ck (The 'sed' line is needed because the C preprocessor produces some comment lines starting with #) Take note, though, that using #include is not the same thing as telling ChucK to pre-load another file! With #include the code is parsed and loaded into the VM as many times as it appears, so it's not the same thing as sharing public classes within the VM. In particular if you #include a file with a public class ChucK will refuse to load it twice. You'll also run into trouble if you try to #include two different files declaring public classes, since you can only have one public class per file. Steve
Stephen Sinclair wrote:
Take note, though, that using #include is not the same thing as telling ChucK to pre-load another file! With #include the code is parsed and loaded into the VM as many times as it appears, so it's not the same thing as sharing public classes within the VM. In particular if you #include a file with a public class ChucK will refuse to load it twice. You'll also run into trouble if you try to #include two different files declaring public classes, since you can only have one public class per file.
My preprocessor works around those things (no double includes, specifically), and as mentioned, the one that was really important for me is that it takes the error output from the chuck executable and retranslates it back to the original source file where the error came from. I don't find the "public" mechanism in ChucK particularly useful. I just copied over my ChucK directory to my home page space -- there are a bunch of classes there in a couple thousand lines of code, some working some not, but it should give an idea of how I use the include mechanism. http://developer.kde.org/~wheeler/files/src/ChucK/ -Scott
Scott Wheeler wrote:
Stephen Sinclair wrote:
Take note, though, that using #include is not the same thing as telling ChucK to pre-load another file! With #include the code is parsed and loaded into the VM as many times as it appears, so it's not the same thing as sharing public classes within the VM. In particular if you #include a file with a public class ChucK will refuse to load it twice. You'll also run into trouble if you try to #include two different files declaring public classes, since you can only have one public class per file.
My preprocessor works around those things (no double includes, specifically), and as mentioned, the one that was really important for me is that it takes the error output from the chuck executable and retranslates it back to the original source file where the error came from. I don't find the "public" mechanism in ChucK particularly useful.
I just copied over my ChucK directory to my home page space -- there are a bunch of classes there in a couple thousand lines of code, some working some not, but it should give an idea of how I use the include mechanism.
Thanks Scott, this is great! The upchuck script works well for me on linux and OSX but has trouble with the temp file stuff on Windows under cygwin: $ ls -R . .: foo.ck ./include: Foo.ck $ export CHUCK_DIRS=~/chuck-working/include $ ./upchuck --silent foo.ck [chuck.Bc252]: no such file or directory mktemp seems to do the right thing $ mktemp -t chuck.XXXXX /tmp/chuck.ZY844 $ ls -als /tmp/chuck.ZY844 0 -rw------- 1 xxx xxx 0 Oct 8 11:34 /tmp/chuck.ZY844 michael
Michael Heuer wrote:
$ ./upchuck --silent foo.ck [chuck.Bc252]: no such file or directory
mktemp seems to do the right thing
It's probably that it deletes the file immediate after creating it, which might cause problems on Windows. On UNIX files aren't really deleted as long as there's still an open handle on them; that's possibly not so on Windows. You could just try commenting out the line that does the deletion and every once in a while cleaning out your /tmp/chuck.* I think you'd need a while before the amount of ChucK source code would seriously start to cut into your hard drive's free space. :-) -Scott
participants (3)
-
Michael Heuer -
Scott Wheeler -
Stephen Sinclair