[chuck-users] preprocessing chuck (was: Time to SMIRK!)

Stephen Sinclair radarsat1 at gmail.com
Sat Oct 4 12:26:33 EDT 2008


On Sat, Oct 4, 2008 at 3:47 AM, Scott Wheeler <wheeler at kde.org> wrote:
> 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


More information about the chuck-users mailing list