eessppeelllloo/processing4
1
0
Fork 0
mirror of https://github.com/processing/processing4.git synced 2026-02-12 10:00:42 +01:00
Code Issues Packages Projects Releases Wiki Activity

fixing up the docs for the preproc

Browse Source
This commit is contained in:
benfry
2005-11-30 18:16:55 +00:00
parent 95fc189208
commit da5c9dfad0
1 changed files with 30 additions and 33 deletions
Download Patch File Download Diff File Expand all files Collapse all files

63
app/preproc/PdePreprocessor.java
View File

@@ -42,6 +42,36 @@ import com.oroinc.text.regex.*;
/**
* Class that orchestrates preprocessing p5 syntax into straight Java.
* <P/>
* <B>Current Preprocessor Subsitutions:</B>
* <UL>
* <LI>any function not specified as being protected or private will
* be made 'public'. this means that <TT>void setup()</TT> becomes
* <TT>public void setup()</TT>. This is important to note when
* coding with core.jar outside of the PDE.
* <LI><TT>compiler.substitute_floats</TT> (currently "substitute_f")
* treat doubles as floats, i.e. 12.3 becomes 12.3f so that people
* don't have to add f after their numbers all the time since it's
* confusing for beginners.
* <LI><TT>compiler.enhanced_casting</TT> byte(), char(), int(), float()
* works for casting. this is basic in the current implementation, but
* should be expanded as described above. color() works similarly to int(),
* however there is also a *function* called color(r, g, b) in p5.
* <LI><TT>compiler.color_datatype</TT> 'color' is aliased to 'int'
* as a datatype to represent ARGB packed into a single int, commonly
* used in p5 for pixels[] and other color operations. this is just a
* search/replace type thing, and it can be used interchangeably with int.
* <LI><TT>compiler.web_colors</TT> (currently "inline_web_colors")
* color c = #cc0080; should unpack to 0xffcc0080 (the ff at the top is
* so that the color is opaque), which is just an int.
* </UL>
* <B>Other preprocessor functionality</B>
* <UL>
* <LI>detects what 'mode' the program is in: static (no function
* brackets at all, just assumes everything is in draw), active
* (setup plus draw or loop), and java mode (full java support).
* http://processing.org/reference/environment/
* </UL>
* <P/>
* The PDE Preprocessor is based on the Java Grammar that comes with
* ANTLR 2.7.2. Moving it forward to a new version of the grammar
* shouldn't be too difficult.
@@ -97,39 +127,6 @@ import com.oroinc.text.regex.*;
* itself. The ANTLR manual goes into a fair amount of detail about the
* what each type of file is for.
* <P/>
* <B>Current Preprocessor Subsitutions:</B>
* <UL>
* <LI><TT>compiler.substitute_floats</TT> (currently "substitute_f")
* treat doubles as floats, i.e. 12.3 becomes 12.3f so that people
* don't have to add f after their numbers all the time. this is
* confusing for beginners.
* <LI><TT>compiler.enhanced_casting</TT> byte(), char(), int(), float()
* works for casting. this is basic in the current implementation, but
* should be expanded as described above. color() works similarly to int(),
* however there is also a *function* called color(r, g, b) in p5.
* will this cause trouble?
* <LI><TT>compiler.color_datattype</TT> 'color' is aliased to 'int'
* as a datatype to represent ARGB packed into a single int, commonly
* used in p5 for pixels[] and other color operations. this is just a
* search/replace type thing, and it can be used interchangeably with int.
* <LI><TT>compiler.web_colors</TT> (currently "inline_web_colors")
* color c = #cc0080; should unpack to 0xffcc0080 (the ff at the top is
* so that the color is opaque), which is just an int.
* </UL>
* <B>Other preprocessor functionality</B>
* <UL>
* <LI>detects what 'mode' the program is in: static (no function
* brackets at all, just assumes everything is in draw), active
* (setup plus draw or loop), and java mode (full java support).
* http://processing.org/reference/environment/
* <LI>size and background are pulled from draw mode programs and
* placed into setup(). this has a problem if size() is based on a
* variable, which we try to avoid people doing, but would like to be
* able to support it (perhaps by requiring the size() to be final?)
* <LI>currently does a godawful scrambling of the comments so that
* the substitution doesn't try to run on them. this also causes lots
* of bizarro bugs.
* </UL>
*/
public class PdePreprocessor {