The annotations :debug and :release seem to apply only to functions or classes or modules.
Is there a way to enable / disable calls to Sys.println() on a line by line basis inside functions ?
Here's hoping.
Thanks
The annotations :debug and :release seem to apply only to functions or classes or modules.
Is there a way to enable / disable calls to Sys.println() on a line by line basis inside functions ?
Here's hoping.
Thanks
Unfortunately, I haven't found solution for it - there is no preprocessor, so to avoid unnecessary data/code (calling empty function) you have to manually comment this line.
If you're not concerned with the memory overhead of unused code for your release build, you could use a wrapper function like so:
(:debug) function debugPrintln(str) {
System.println(str);
}
(:release) function debugPrintln(str) {
}
If you use the above approach, this third-party code optimizer might also get rid of the dead code associated with debugPrintln() on release: forums.garmin.com/.../big-update-to-prettier-extension-monkeyc
I do have a janky script which leverages the C preprocessor to do actual per-line conditional compilation, but I haven't updated the workflow for VS Code.
The annotations :debug and :release seem to apply only to functions or classes or modules.
They also apply to class member variables.
Thanks.
I'm looking for a way to shrink the foot print of my app while keeping the debugging statements available for use when necessary.
Yeah, then I guess your options are:
1) wrapper function + prettier
2) line by line conditional compilation using preprocessor
3) manually comment out lines
I used 2) pretty heavily for one of my data field apps to squeeze out every last byte of memory savings, but the downside (for me) is that I have to open Eclipse to build my app. Maybe I'll adapt the workflow for VS Code one of these days.
EDIT: I use conditional compilation to handle different code across devices / CIQ levels / screen sizes, not for debug vs release.
I think you should look into testing your app, that way you can perform tests and know how things are working. It requires less System.println() statements across the board. Your tests prove that things work as expected and you can always sprinkle debug statements when developing and running the tests.
And when things fail or work not as intended after a change you immediately know which test broke and thus which commit broke something.
That's my .02 for this thread.