DSP Robotics Support

I am attempting to switch what is being drawn to a view via an external switch.
Rather than giving different simultaneous draw instructions to my code (more code/cpu?) and switch via alpha/opacity control... I want to execute the code on command to redraw based on input selection, much like Trog's code chooser..(which I am assuming is more efficient / opens the door to new possibilities).

just disconnect the view from my original solution, and plug it into my current guess of how it could work (though it doesn't)

In itself, the self-modifying code that redefines the draw method is fine, and is a nifty use of "metaprogramming" for efficiency (assuming that the selector is rarely changed). The problem is with the keys to the Hash of Procs...

The keys to a Hash are matched very strictly, and you've defined them as integers (strictly speaking, objects of Ruby class Fixnum). However, you're using a Float number to select an element. A Float key will never match a Fixnum, as they belong to different Ruby classes, so the Hash is resorting to selecting the default every time. You just need to change the input connector type to integer to make the keys match, and the module will work as expected.

As a further example, if you changed the input connector to boolean type, the Hash keys would have to be "true" and "false", as those boolean values also belong to their own Ruby classes (TrueClass and FalseClass).

thank you trog ! what do you mean by assuming the selector is rarely changed? what should I take into account and factor into my decisions?

Is it dangerous to rapidly change and force a redraw with a prim and tick when calling procs?
I see you forced a redraw in your ruby stars, and it looks smooth.
Now that I comprehend it, I may make use of procs in many ways, not just changing lines. Should I be worried flipping procs and forcing redraws and beyond?

The Proc's themselves aren't a problem - they're not so different to the "code blocks" that a lot of Ruby methods use, and they can be a really great way to avoid having too much decision-making and branching inside methods.

In your code, however, the Procs contain code which redefines the 'draw' method at runtime. This has a good side and a bad side...

The good side is that each redraw only has to make a regular method call to 'draw', and the method itself never contains any decision-making code or Array/Hash lookups - it's always defined to do exactly what's needed and no more. Redraws tend to be called a lot, so this can be a good place to have that kind of efficiency.

The down side is that changing a method definition is relatively slow, and also makes Ruby clear its internal caches. The caches are used by Ruby to store "shortcuts" to the most often called methods, so Ruby will be a little bit slower while the caches get rebuilt after each change. If the selector for the drawing "style" is rarely changed, this won't matter much, and it will be well worth it for the faster redraws. OTOH, if the selection were changing several times per second, using regular if-then-else code might be better.

Some coders would also tell you that it's bad to use self-modifying code. It is true that it can sometimes make debugging etc. more tricky (say, if you had no idea which version of 'draw' is currently in use). But personally, I think you have to take things case by case - slightly less clear code can be well worth trading for efficiency sometimes, and a few extra code comments or "watch" messages could be used to clarify what''s going on.

Mr. Trog, you have just helped me grow exponentially.
May your next supper taste like a feast worthy of the gods.

You're welcome!

guyman wrote:May your next supper taste like a feast worthy of the gods.

Sorted...

(never mind loo roll - this is what I hoard in a crisis! )

trogluddite wrote:(never mind loo roll - this is what I hoard in a crisis! )

You'll need plenty of loo roll if you munch on them all night

trogluddite wrote:Some coders would also tell you that it's bad to use self-modifying code. It is true that it can sometimes make debugging etc. more tricky (say, if you had no idea which version of 'draw' is currently in use). But personally, I think you have to take things case by case - slightly less clear code can be well worth trading for efficiency sometimes, and a few extra code comments or "watch" messages could be used to clarify what''s going on.

I hear what you're saying, but back when dinosaurs walked the earth and you entered the boot-loader using front-panel switches, one of my mentors said, "Just because something works doesn't mean it's a good idea."

after doing a bit of research on this subject online I don't really see what the fuss is about. wrong right good bad all subjective baseless things. I want to hear real consequences. All I can see now is this talk of how it can get messy in terms of organization {solved with careful planning and notation(we are "programmers" right?)}.. and maybe runaway memory issues if used incorrectly. if ruby dumps it's cache when doing this that solves problems of procs causing memory issues, but could throw a wrench in my own tactic if I am calling for arrays, but I can work around that. I like Trog's perspective of it being circumstantial, and I'd take it a step further and say it SHOULD be wielded where ever it can (that is if you are making something interesting enough to .call for such force.abilities)...