DSP Robotics and FlowStone Graphical Programming Software Support and Forums
https://dsprobotics.com/support/
HughBanton wrote:Shame on me ...
Code: Select all
def add(a,b)
return a+b
end
add(2,1)
Yes, it is wrong. Don't compare DSP to Flowstone Green to Ruby. They are all different, they work different and they don't share anything other than that their output can be used by each other. All three are black boxes to each other, they run in parallel but not collectively. Either of them could stop running with the other two completely fine continuing running. To understand Ruby better, don't try to find parallels, but see Ruby as a programming language on its own. Ruby is built from classes, which means that everything is an object called "class". This is true for everything, including a RubyEdit (the red Ruby code editor). Every object has an initialization method, which is called by Ruby when a copy of classs definition is instantiated. A RubyEdit is instantiated, when you drag it into the schematic, when you write code into it, and when you load a schematic with a RubyEdit inside. The class definition for a RubyEdit does its own initialization tasks (as programmed in Ruby by DSPR) and then calls a method named "init". If the method doesn't exist (because you didn't write one), it's ignored. If it exists, the contents are executed. That's all there is to it. A one time initialization option, when the class instance is created.HughBanton wrote:My primary misconception, I think, was that anything inside 'def init' runs whenever a Ruby code block is called, in the same way that in DSP you can declare stage(0) to run first, and just once, whenever a new note is keyed. I now suspect that's fundamentally wrong about 'init', no?
No that's not true. The class definition of a RubyEdit is code that you don't get to see (instead you see the red Ruby editor). It's that code that calls the methods you define. The code does it using a bridge from Flowstone's internal C/C++ routines that are passed to the class. So, when you move your mouse, Flowstone informs the RubyEdit that the mouse has moved, the RubyEdit then calls "mouseMove()", and if you created a mouseMove definiton in your RubyEdit instance, its content is executed. If it doesn't exist, it is ignored.HughBanton wrote:And secondly - and bear in mind I'm a pretty inexperienced coder - in other languages, a block that's a 'Method' (or a 'Function', 'Sub-routine', etc) always gets called from somewhere else. However there are plenty of Ruby examples we encounter which seem to be 100% def 'this' & def 'that', but where nothing seems to get actually called!
No. Ruby just like Green, is event driven. Only if an event happens, Ruby reacts. So "def mouseLDown()" is called, when the left mouse button was actually pressed. Flowstone however does indeed run in a continuous loop to catch all those events and redirect them to Green, Blue and Red.HughBanton wrote:From which I assume that Flowstone Ruby always runs a method such as def 'mouseLdown x,y' in the same way as it always runs def 'event x,y', because the calling is external.
No, it is not wrong. The RubyEdit instance is there for you to do, whatever you seem fit. However, what would this particular code help you with? You define no variable to hold the result from your method, so it's put into the info pane and is then forgotten.HughBanton wrote:So is it actually wrong to write :
Code: Select all
def add(a,b)
return a+b
end
add(2,1)
Which I would consider .. 'conventional'? (Or is my write wrong!
H
HughBanton wrote:All most interesting, thanks tulamide. (Sorry about "code block" - I'm familiar with {..} and I should have known that!)
I do regularly refer to chapter 8, however I rarely do any graphics stuff so in truth my preferred Ruby resource is generally Google, such as .. "ruby insert a character" or "ruby join an array" - almost always finds me the answers I need!
But as Trog rightly said, an explanation of 'def init' is sadly lacking in the FS guide, and I confess I'm still slightly unclear how it works. The code I'd put up (that created a 'phantom error' in Alpha) had an array defined inside a def init, and then I used bare code to use that array to index another array which came in through an input.
I fixed it by making the whole thing into a 'def event i,v' instead. But I remain unclear why the original was suspect.
H
Code: Select all
class Calculator
def add(a, b)
return a + b
end
endCode: Select all
class Calculator
def add(a, b)
return a + b
end
end
calc = Calculator.new
calc.add(2, 3)Code: Select all
class Calculator
def initialize
@ha_we_falsify_add = 10
end
def add(a, b)
return @ha_we_falsify_add + a + b
end
end
calc = Calculator.new
calc.add(2, 3)Code: Select all
class Calculator
def initialize
@ha_we_falsify_add = init()
end
def init
return 10
end
def add(a, b)
return @ha_we_falsify_add + a + b
end
end
calc = Calculator.new
calc.add(2, 3)Code: Select all
class Calculator
def initialize
@ha_we_falsify_add = init()
end
def init
return 10
end
def add(a, b)
return @ha_we_falsify_add + a + b
end
end
class Calculator
def init
return 999
end
def sub(a, b)
return a - b
end
end
calc = Calculator.new
calc.sub(3, 2)
calc.add(2, 3)
) I find Chapter 8 often makes statements that only make sense if you already know what they meant in the first place. Which hopefully I do a bit now.