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