DSP Robotics Support

Ok,
I've found an trick that work



Edit: ReUpload fixed file ... sorry

Interesting solution, Tronic!

@Exo, fyi, in general callbacks in Ruby are done through blocks. You already know blocks from enumerates. It's the part within {}. Anonymous functions are realized using the Proc class. For example:



Based on that, here's another way of implementing your example of a callback. Click "fill output" once. With this solution you need to make sure that the callback is send after all deeper nested ruby instances are initialized, so avoid sending on init at the top ruby instance.

Hi tulamide, your example not work well,
because you have to instantiate first the callback, in this case the Proc method,
to pass the instance to the caller,
the other things is not thread safe, every call to the same instance of Proc, delete the preview call, so the first call is lost.

So better to make an Class or Module for an callback implementation.

The my example not need any wireless, because it replicate the same concept of the Ruby message system.

Tronic wrote:Hi tulamide, your example not work well,
because you have to instantiate first the callback, in this case the Proc method,
to pass the instance to the caller,
the other things is not thread safe, every call to the same instance of Proc, delete the preview call, so the first call is lost.

So better to make an Class or Module for an callback implementation.

The my example not need any wireless, because it replicate the same concept of the Ruby message system.

I didn't say it's the ultimate solution. But it is the way, Ruby expects us to work with callbacks (just google for ruby callbacks). You are hacking deeper into the kernel, which gives more freedom, so I like your solution, don't panic

The good thing about doing it like Ruby wants us to is that the block is created within the context of where it is created. So, calling it will always be executed on the creation layer, which in this case is the ruby edit instance that contains the tick output.

About thread safe, that isn't of interest in this context I think. It doesn't matter which instance calls Proc or when, it just executes a trigger output.

Yes, there are more complex solutions (for example the one you presented), but this one is easy to understand and does its job

hehe, luckily I'm safe ... if you like my implementation ....
I was only willing to offer explanations on how to have after a good concept and use of Ruby
in the context of Flowstone, otherwise you may confuse rather than simplify.

Since you prefer the use of Ruby in the context of Flowstone and with classes, here's another solution. This time it uses the same fact I used for the sprite class and that is: no matter how many ruby edit instances, there is only one Ruby running at all times. All instances share the same namespace and of course everything declared in one instance is available for all other instances, too.

I like the simplicity of both solutions I offered. I think it's easier to comprehend when you're not a programmer. Personally I would probably prefer yours.

Good work Tronic and tulamide!

It is always worth trying different ways to find the best overall solution, or just the best for a given circumstance.

I like your last implementation tulamide very simple and to the point, only problem I have is the use of a global variable, this of course can be problematic.

@Tronic your solution is very interesting, it looks a little confusing at first but that is a very good object oriented solution.

Exo wrote:I like your last implementation tulamide very simple and to the point, only problem I have is the use of a global variable, this of course can be problematic.

Why? You are the only one maintaining the code, so I don't see a problem. Also, you can make sure it is not used elsewhere by giving it a proper name. Also (yeah I'm totally jealous ), Tronic makes use of quite a few global ones. Besides Flowstone's intern_this global, the class variables (starting with @@) are also semi-global, as they are not protected in any way and inherit above in the hierarchy.

So...
A class variable (@@ ) is a variable that is shared amongst all instances of a class.
This means that only one variable value exists for all objects instantiated from this class.
This means that if one object instance changes the value of the variable,
that new value will essentially change for all other object instances.
Another way of thinking of thinking of class variables is as global variables within the context of a single class.

the $intern_this is an gloabal variables declared from Flowstone to take track of your internal
copy paste and creation of RubyEdit Class.

Tronic wrote::lol:
So...
A class variable (@@ ) is a variable that is shared amongst all instances of a class.
This means that only one variable value exists for all objects instantiated from this class.
This means that if one object instance changes the value of the variable,
that new value will essentially change for all other object instances.
Another way of thinking of thinking of class variables is as global variables within the context of a single class.

the $intern_this is an gloabal variables declared from Flowstone to take track of your internal
copy paste and creation of RubyEdit Class.

Yes, your descriptions are correct. That's what I said, too. I called class variables semi-global for the reason you described. You couldn't change them for other object instances if they were protected and also couldn't change them if they wouldn't inherit above instead of just below like normal.
I know where intern_this comes from. My point is, why should it be an issue when you use your own global, but no issue when Flowstone uses a global? There's no difference, the global is of the same type (a global^^) wether declared by Flowstone or yourself. Globals and constants are valuable tools in development, even in object oriented development you can't fully work without them (as your and my examples prove)