DSP Robotics Support

Posted: **Fri Aug 23, 2013 8:33 am**

Hello!

I just made an exaple to show what i have at the moment but i think there is for shure a better version.

It schould send reverse any data within a ruby class.

Please help

Regards

Posted: **Fri Aug 23, 2013 2:14 pm**

Aha - exactly the trick I've been using in my new Table stuff!

There's no need for new classes to be able to do this - the trick is to remember that Ruby variables don't really contain any data, just pointers or references to the objects. And everything in Ruby is an object - even the RubyEdit code boxes!
Every RubyEdit has a built in instance variable called '@this', which is a reference to the editor object itself - so, for example, typing...

Code: Select all

@this.output 1, "hello"

...is the same as plain old...

Code: Select all

output 1, "hello"

And there's nothing stopping us from passing the reference '@this' to a value output and sharing it with another RubyEdit primitive - allowing one Ruby editor to call the methods of another one.

Here's how it looks in practice...

RubyEdit linking.fsm: (750 Bytes) Downloaded 1036 times

The link passes a small array containing both the new value, and the '@this' of the master RubyEdit (copied to @master in the slaves).

There are a few precautions that you need to take though...
1) Make sure the value of @this is passed at startup - the IDs of the RubyEdits will be different every time you run FS, so can't be stored between sessions.
2) Make sure the slaves don't try to call the methods before the '@this' value is received - otherwise you'll be calling methods of 'nil' (which doesn't really have any), and cause a NoMethod error.
3) Watch out for feedback loops! - in the slaves, the output is driven only by getting a value from the master, and changing the value only calls the master - the input and output processes don't interact at all within the slave, to avoid the dreaded 'Too much processing' lockdown.

I really love the way that Ruby can do this - we can now make 'wireless' values that work in both directions like the 'preset' links do!

PS) The method 'send' is already defined - it's one of the Kernel methods available to nearly every object - so probably best avoided as a user-defined method name. Using the same name overwrites whatever method originally had that name (only for whatever class), so in some circumstances using a Kernel method name might break things!

Posted: **Fri Aug 23, 2013 3:01 pm**

Here's another little example of a different method for making links between objects - might be more useful if building a new object class is your intention.

This methods uses one of Ruby's most powerful features - not only are RubyEdit boxes objects, but you can also wrap up chunks of code and treat those as objects too, complete with the ability to pass parameters into them.
They look something like this...

Code: Select all

{ |parameters|   <some_code> }

The parameters between the '|' symbols work just the same as the ones you make for methods - allowing external values to be passed in and used by the code.
The clever part is that such a chunk of code (known as a 'block' or 'Proc' object) will always execute in the context where it was defined.

Here's an example...

Linking with blocks.fsm: (1.25 KiB) Downloaded 1011 times

NB) Example revised in light of MyCo's warning below - proceed with caution after reading the posts below!!

Note that the test object gets given the 'action' block within the 'output' RubyEdit - so when the block is called, that's where it gets executed, even though the class and object are elsewhere.

You can also use the 'Proc' class to make 'stand-alone' code blocks that can be passes around using variables, stored in arrays and hashes, etc. just like any other Ruby obect...

Code: Select all

@add = Proc.new{|x, y|  x + y}
@sub = Proc.new{|x, y|  x - y}

@code_array = [@add, @sub]

output 0, @cose_array[0].call(30, 10)
output 1, @code_array[1].call(30, 10)

...outputs 20 and 40 respectively.

in fact, we have all seen blocks many times already - the '{' and '}' are equivalent to 'do' and 'end' - so 'looping' methods, like 'each', work exactly this way - they are taking the loop 'body' and treating it as a code block, exactly like the method in the example code.

Posted: **Fri Aug 23, 2013 4:15 pm**

Never ever send class instances over FS connections. You'll run into terrible problems! The reason is, FS stores every value you've sent out in the connected inputs, when you save the schematic. When you reload the schematic it depends on the order of module insertion, if the RubyEdit knows the class of the value on the input, or not.

The bad thing, when you run into such a situation, there is only a Registry hack that'll allow you to recover your schematic. Without that, FS crashs directly when you load the schematic.

Posted: **Fri Aug 23, 2013 7:26 pm**

MyCo wrote:You'll run into terrible problems!

Not yet!

But, yes - I was getting a bit carried away there, and the words of warning are much appreciated, thanks!!

To keep the thread making sense, the example is now revised to show how it can be done (relatively) safely - but these things MUST be done with MUCH more caution than I just showed!!

MyCo is right (of course!) - it's a very important warning, which I should have included in the examples. In general, you gotta be careful that you don't do ANYTHING with a custom class unless you are sure it has already been declared.

That's where the module order is important - to make anything with new classes work...
1) The module containing class definitions must be the very first one inserted into the project. I put one in and label it as the first thing I do when I make a new project.
2) Make sure all other RubyEdits are inside modules too - in case 'loose' RubyEdits get read before the 'definition' module is.

In addition...
3) Ruby/FS uses a class called 'Marshal' to define how a class instance is turned into binary data for saving/loading. Without the required Marshal methods inside the class, instances can't be stored or recalled. This can mean a Ruby error when loading a schematic if, as MyCo says, they are held at inputs or outputs.
I've added said routines to the example in the previous post to show what this looks like - but it is very class specific, so please don't take this is a 'template' for guaranteeing success!

Never, ever? Hmm, well I'm kind of a "never say never" guy, and new classes are SOOooo powerful - but, as with ASM code - VERY CAREFULLY!! FS can handle it if you know Ruby well enough - but like MyCo says, get it wrong, and things can get very messy!

Posted: **Fri Aug 23, 2013 11:19 pm**

Well then you have to do a save class :-)

I always check incoming values and classes within the class. Up to now i got no problem. And i hope that i wwill have no problems in futur but i will take a spetial look on that while programing classes.
Thanks for the warning.

Regards

Posted: **Mon Aug 26, 2013 8:46 am**

Well i did a new construction:

I passed @this and the value in one array to the send-modules. And if the input is not same than the input from the system, the send module will execute @this.output ...
I also deleted the class - i thought through testing it is needed - bu ti see not it is not - maybe i had any error in my brain when i tried this first

I'll post it on Examples

Thanks to your both

Regards

DSP Robotics Support

Better funktion for sending back values in Rubyobject

Better funktion for sending back values in Rubyobject

Re: Better funktion for sending back values in Rubyobject

Re: Better funktion for sending back values in Rubyobject

Re: Better funktion for sending back values in Rubyobject

Re: Better funktion for sending back values in Rubyobject

Re: Better funktion for sending back values in Rubyobject

Re: Better funktion for sending back values in Rubyobject