Debugging Ruby

[Exo]

Hey I am trying to port the drawing of the Multi Stage env to Ruby.

I have written the code and as far as I can see it should work, but obviously does not.

I am getting rather annoyed with a cryptic syntax error saying "unexpected keyword_end, expecting $end" What the hell does that mean? all my "end"s are in the right place.

Been staring at the code for ages now and need a fresh pair of eyes to take a look see if I am missing something obvious!

Code: Select all

def draw v
   pBrush = Brush.new Color.new(128,128,255,255),@pointSize
   pPen = Pen.new Color.new(128,128,255,255),@curvePointSize
   curvePen = Pen.new Color.new (128,128,255,255), 0.1
   @w = v.width-1
   @h = v.height-1
   pHalf = @pointSize *0.5
   
   ## Draw section points
   0.step(@sections,1) do |i|
     v.drawEllipse pBrush , [((@xArray[i]*@zoom)*@w)-pHalf,@yArray[i]*@h,@pointSize,@pointSize]
   end
   
   ## Draw curve points
   0.step(@sections-1,1) do |i|
   
    x = (((@xArray[i+1]-@xArray[i])*0.5)+@xArray[i])
    y = (((@yArray[i+1]-@yArray[i])*@curveArray[i]) + @yArray[i])
    v.drawEllipse pPen , [x*@w*@zoom - @curvePointSize*0.5,y*@h - @curvePointSize*0.5 + 0.5,@pointSize,@pointSize]
   
    startX = @xArray[i]*@w
    startY = @yArray[i]*@h
    endX = @xArray[i+1]*@w
    endY = @yArray[i+1]*@h
   
    yRange = endY - startY
    xRange = endX - startX
   
    areaStep = xRange / 128
   
    curvePlot = [128]
    frac = 0.00790514
    invert = 1/@curveArray[i]
   
    ##Plot the curve
    0.step(128,1) do |j|
      accum = j*frac
      t1 = (1 - invert) * (accum-1) + accum
      t2 = (1/t1) * accum * -2
     
      curvePlot[j] = [ startX + i*areaStep, t2*yRange + startY]
    end
     ##Draw the curve
     v.drawLines curvePen, curvePlot
    end

end

I've attached the fsm also.

Thanks for any help!

Also any tips for debugging in Ruby? I've been developing in Java the last few years and am now feeling rather spoiled with my fancy IDE

[Tronic]

curvePen = Pen.new Color.new (128,128,255,255), 0.1

just remove the space after Color.new
curvePen = Pen.new Color.new(128,128,255,255), 0.1

annoing syntax parser ...

[Nubeat7]

cool, i wanted to do this either some time ago but never finished (finally it was a bit too complex for my skills), but i did an adsr out of it instead i think it could be of interest for it

viewtopic.php?f=3&t=1756

about debugging, i use this few lines from trog very often when the error message is not clear enough

Code: Select all

      rescue=>error
   watch "error message",error.message
   watch "error trace", error.backtrace
   raise error

just place it at the end of any methode

[trogluddite]

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...

Code: Select all

Pen.new(Color.new(a, r, g, b), w)

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...

Code: Select all

$DEBUGGER = @this

...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.

[Exo]

curvePen = Pen.new Color.new (128,128,255,255), 0.1

just remove the space after Color.new
curvePen = Pen.new Color.new(128,128,255,255), 0.1

annoing syntax parser ...

That was it thanks!

[Exo]

cool, i wanted to do this either some time ago but never finished (finally it was a bit too complex for my skills), but i did an adsr out of it instead i think it could be of interest for it

viewtopic.php?f=3&t=1756

about debugging, i use this few lines from trog very often when the error message is not clear enough

Code: Select all

      rescue=>error
   watch "error message",error.message
   watch "error trace", error.backtrace
   raise error

just place it at the end of any methode

Thanks for the example it has given me a few tips

[Exo]

@Trogluddite Thanks for the in depth reply! Lots of useful tips and gotchas they will help me alot.

I think once I get into Ruby a bit more I will probably got the notepad route, seems like it will be less hassle.

[FluxCapacitance]

Chalk another good one for the wiki. haha.

[billv]

Hey guys...
does DSPR have any plans to update the 'Ruby' prim with better debugging..???
I'm not asking much here...Even a simple 'line number' where the error is, will do for me..

Been staring at the code for ages now

Me too...for days now...
I've been trying to build a "Ruby Draw Wave" (many attempts)...
I can do arrays for the co-ordinates...that's ok....but really
struggling with the 'technique' with creating/drawing a array of pens or brushes,
without typing them in, one by one.
Your code , as confusing as it is to me, is helping me a lot...
Cheers

[RJHollins]

any improvements writing and de-bugging RUBY would be most welcomed [staying totally within FS as I'm nowhere good enough to write 'outside' the schematic ! ].

Ahh ... the Ruby graphics. There is so much power there ... but I'm still doing baby steps. I've been thinking about the process of coding a vector knob into something OTHER than a circle 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.
oh well ....

As always ... Thanks TROG for exposing some very useful coding tools !