Malc's style in the examples is also not typical of most Ruby programmers - you CAN pass arguments without wrapping them in parentheses, but it is often considered poor style - as here, it can lead to slightly ambiguous syntax that confuses the parser.
So I would always write the line as...
Note that there should never be whitespace between the method name and the opening parenthesis - it does work most of the time, but isn't reliable.
Another useful little tip for de-bugging (though it doesn't help with Syntax bugs). End your methods with a generic 'rescue' clause that prints a little extra exception data...
Code: Select all
def myMethod
##CODE##
##CODE##
rescue => error
watch "Last Error", error.message
watch "Trace", error.backtrace
raise # re-raise the same error so that error handler still sees it.
end
Line numbers are usually one or two lines out, but can give a clue where the error happened. The part of the trace where it says "eval" can be ignored - it would normally be the path of a source file where the method is defined, but our RubyEdit methods are just 'eval'uated strings.
The main advantage of this is that it makes the error message persistent - if another trigger immediately causes the Ruby to run again without error, the message won't get deleted before you have a chance to read it!
Since this gives you a trace, you only really need to do this for the 'event' and 'draw' methods, as they are always the 'entry functions' - exceptions raised elsewhere will nearly always 'fall-through' to one of those two.
EDIT) He he - looks like NuBeat got there first!Something else I often do is to put a "shared" RubyEdit at the top level of the schematic. It only has one line of code...
...and resize the 'watch' area at the bottom to be really big.
You can then get watch messages sent to this from any other RubyEdit, so that you have one place to see debugging messages from anywhere in the schematic. In any other RubyEdit instance, just use the $DEBUGGER global variable as the receiver of watch...
Code: Select all
$DEBUGGER.watch "Debug message from over here...", ...
Just make sure to delete those lines before removing the 'de-bugger' RubyEdit and exporting - otherwise the undefined $DEBUGGER variable will lead to 'NoMethod' errors!! - and see the point below about global variables being shared; this trick only works well when you have a single schematic open.
A few other points worth remembering...
- One Ruby parser is used for all schematics that are currently open in FS. So they will share global variables and Class/Module definitions. In general, global variables should be avoided anyway, but there are some pre-defined ones that are commonly used that might allow 'crosstalk' between schematics (e.g. the $1, $2, $3... used by Regular Expression matches).
- Editing the code always forces the 'init' method to be called - so defining 'init' can be useful to be sure of the program state following an edit.
- At load time, the order for each RubyEdit is this...
1) Code is parsed, and all method definitions, new classes etc. constructed.
2) The 'init' method is called - note that this is BEFORE any stored input/output/saveState variables are defined, so don't rely on their values, and be prepared for values that might get over-written by the next stages.
3) Stored Input and output values are loaded
4) loadState is called (if you defined it) to restore user-defined 'persistent' variables.
5) Once this is done for ALL RubyEdits, 'Green', Audio and the Ruby event system are initialised.
Note that the order of the RubyEdits is determined by module hierarchy and the order that you added things to modules - so can be very unpredictable. This needs care if you use custom Modules and Classes - it's generally unwise to make an instance of a new Class at the 'init' stage if the Class is defined in a different RubyEdit - it may not have been parsed yet!
- Instance variable values, Classes and Modules are persistent. This can sometimes catch you out when re-factoring. For example, you may have re-named an instance variable but accidentally left the old name in a few places. You might not notice because the old instance variable still has a value, even after editing the code. So, before a de-bugging session, it is worth quitting FS and re-loading, to ensure that you are starting with a clean Ruby session.
Finally, if you're really serious about your Rubying, I'd heartily recommend using an external editor (e.g. Notepad++). RubyEdits re-parse the code with every single key-stroke while you're editing. Not only does this get seriously slow when there are more than a few dozen lines of code, you can also get some strange effects from Ruby parsing partially typed code.
For example, if I were refactoring, and decided to shorten the class name "TrogsClass" to "Trog" - I'd end up having defined the classes "TrogsClass", "TrogsClas", "TrogsCla", "TrogsCl", "TrogsC", "Trogs" and "Trog".
Those class definitions would persist until quitting FS, and might lead to 'false positives' where code runs OK, then becomes buggy when re-loaded, or problems if I just wrote over a Class that I really did want to call "TrogsCla".
Notepad++, the NppExec plugin and a full Ruby 1.9.3 install works perfectly for me when writing new classes. As long as they don't need FS specific methods, you can create a nice little unit testing environment, and catch loads of bugs before even putting the code into FS - and get Syntax Error messages that are far more meaningful!
I'm just trying to write at the moment a test suite that includes "dummies" of the FS classes and methods so that I can extend the unit testing further - I'll post about how to set this up if I manage to get it working nicely.
].
This was something nice about Knobman, as we could make some unique knob designs. Right now I struggle to make a 3D looking vector knob.