| Author |
Message |
rogan

Joined: Dec 16, 2007 Posts: 83 Location: Urbana, IL
Audio files: 5
|
Posted: Sun Dec 16, 2007 4:54 pm Post subject:
include files |
 |
|
Hi all,
Is there any way to include files? I know that `machine.add' will chuck files for me (so I can make sure my classes have been loaded), but is there any way that I can include code like in C? I'd like to break my code into "header" and "main" to separate functions from scores, and miniaudicle stuff from unit generators.
Thanks!
Rogan |
|
|
Back to top
|
|
 |
davebotpdx
Joined: Dec 18, 2007 Posts: 2 Location: portland, or
|
Posted: Tue Dec 18, 2007 12:12 pm Post subject:
about that... |
 |
|
Rogan,
Maybe you can help me out, I've got a question about something you wrote.
Say I've got a instrument class Sampler.ck.
The following doesn't work for me:
//------somefile.ck-------//
Machine.add("Sampler.ck");
Sampler s;
//---------------------------//
Are you getting this to work? I can get it to work only by first loading
the class from outside of this file. (and removing the .add line)
Thanks very much,
dave |
|
|
Back to top
|
|
 |
Kassen
Janitor


Joined: Jul 06, 2004 Posts: 7678 Location: The Hague, NL
G2 patch files: 3
|
Posted: Tue Dec 18, 2007 12:25 pm Post subject:
|
 |
|
Welcome &welcome!
The issue is that a file first gets parsed for syntactic correctness, then compiled to the VM and executed.
So, in your "sampler" case the parser discovers that you use a class that hasn't yet be defined and so brings that to your attention (as well as going on strike from there on!), if ChucK would somehow continue beyond this it would find that the class would get defined before it would get used but things don't happen in that order as we have a compile stage before it actually runs.
The solution would indeed be to have a sort of "include" facility that would take effect before parsing the rest, this is being worked on.
For now, what you can do is have a sort of "mother" file that adds all your classes for you, then adds the actual program. This works but it can get inconvenient.
Hope that helps. _________________ Kassen |
|
|
Back to top
|
|
 |
davebotpdx
Joined: Dec 18, 2007 Posts: 2 Location: portland, or
|
Posted: Tue Dec 18, 2007 3:01 pm Post subject:
|
 |
|
That does help. Do you think this compiler behavior will change in the future?
What I have been doing was to have a class loader file, and then separate programs.
But, what your saying is these can be combined to have:
Machine.add ( "the class I want to load" );
Machine.add ("the chuck program I want to run using that class above" );
That should be fine. Thanks for your help.
-dave |
|
|
Back to top
|
|
 |
rogan

Joined: Dec 16, 2007 Posts: 83 Location: Urbana, IL
Audio files: 5
|
Posted: Tue Dec 18, 2007 3:30 pm Post subject:
|
 |
|
Hi all,
Thanks for the replies. The 'mother' file is a good idea. I think I'll start using that. I'm definitely looking forward to normal include files (as I wrote above), for just normal code cleanliness. Maybe if I score some free time soon, I'll take a look at the Chuck code....
Cheers,
Rogan |
|
|
Back to top
|
|
 |
Kassen
Janitor


Joined: Jul 06, 2004 Posts: 7678 Location: The Hague, NL
G2 patch files: 3
|
Posted: Wed Dec 19, 2007 10:43 am Post subject:
|
 |
|
| davebotpdx wrote: | Do you think this compiler behavior will change in the future?
|
I'm sure it will. This has been talked about quite a few times and I know Ge is working on it (but I also know he's a busy man). I think the current plan is to inspire includes/imports/whatever on the Java way of doing them but of course everybody can share good ideas.
It's a important topic, includes would help manage larger projects which is cool but it would also open the way for user contributed libraries which would be very good from a community perspective. Hopefully there will be a good idea and we'll be able to keep it all simple.
In the same vein there are also plans to enable users to use their own home-build Ugens. _________________ Kassen |
|
|
Back to top
|
|
 |
Frostburn

Joined: Dec 12, 2007 Posts: 255 Location: Finland
Audio files: 9
|
Posted: Wed Dec 19, 2007 2:17 pm Post subject:
|
 |
|
I find the POV-ray way of doing include files quite practical.
typing:
| Code: |
#include the_amazing_ugen.inc
|
is practically the same as copy&pasteing the contents of "the_amazing_ugen.inc" right onto that spot.
This way you could just have a list of #include commands (or any fancy new chuckian operator like §= ) at the bottom of your file to define the needed classes. (Classes should be defined after the main program, right? In POV-ray you usually have the #include foo.ck at the top of the document. )
Or define your melody arrays in an include file and 'chinc' ( §= "melody.ck" ) it at the top. |
|
|
Back to top
|
|
 |
Kassen
Janitor


Joined: Jul 06, 2004 Posts: 7678 Location: The Hague, NL
G2 patch files: 3
|
Posted: Wed Dec 19, 2007 3:10 pm Post subject:
|
 |
|
| Frostburn wrote: | (Classes should be defined after the main program, right? In POV-ray you usually have the #include foo.ck at the top of the document. )
|
Classes can be defined anywhere you like, as long as they aren't inside of something else (say a function). I just like them at the bottom where they are out of the way as for me they tend to be utility stuff to write once, then forget, you are completely free to define them when you need them or at the top or to sort functions and classes by alphabet and file your main loop under "m" :¬)
I would probably put includes at the top but I could imagine somebody preferring to put a include line right before the first point where it's used. I don't think the parser would mind.
The one thing that's important is to *instantiate* classes before the instantiation is used but I'd call that common sense as well as quite logical and natural. Previously that could crash, I think the parser now catches it, not sure from the top of my head how it's dealt with, just that it no longer crashes (knock on wood). _________________ Kassen |
|
|
Back to top
|
|
 |
lamarcph
Joined: Oct 21, 2004 Posts: 40 Location: Montreal, Canada
G2 patch files: 4
|
Posted: Wed Dec 19, 2007 3:35 pm Post subject:
|
 |
|
Until there is a "build in" solution I use a little java app I made.
It recursively looks for "!#import filename" tags in comments and add that file to the chuck command line, in reverse order.
The same sort of thing could be done at chuck_main.cpp ln 590. It's easier to that in comments because you don't need to worry about the chuck parser.
What I would really love is a import functionality and a chuck symbolic parser that would provide "auto-complete" of user and standard data type. =!Maybe!= we could modify miniaudicle to do that. That and flat files access, and a xml parser! ok, I am dreaming. |
|
|
Back to top
|
|
 |
Kassen
Janitor


Joined: Jul 06, 2004 Posts: 7678 Location: The Hague, NL
G2 patch files: 3
|
Posted: Wed Dec 19, 2007 3:46 pm Post subject:
|
 |
|
Didn't Spencer say he wanted auto-complete in the Mini for build-in stuff and user defined things? I'm fairly sure he's going to do that but I haven't seen him 'round for a while. _________________ Kassen |
|
|
Back to top
|
|
 |
|