bad Loop causes massive ruby shutdown

For general discussion related FlowStone
billv
Posts: 1165
Joined: Tue Aug 31, 2010 3:34 pm
Location: Australia
Contact:

Re: bad Loop causes massive ruby shutdown

Post by billv »

Thanks Trog.....can see those error's very clearly now... cheers :)
tester
Posts: 1786
Joined: Wed Jan 18, 2012 10:52 pm
Location: Poland, internet

Re: bad Loop causes massive ruby shutdown

Post by tester »

trogluddite wrote:The real lesson is that you cannot compare the performance of two codes unless they are semantically the same - i.e. the same input conditions produce the same output conditions (with the same timing, if that is important).
And after all this Ruby talk, it's ironic that our biggest friend here would have been the old, faithful "Green Trigger Counter" - it would have shown that the two codes were doing different things very quickly!


Couldn't agree more. :mrgreen:

And one more thing. There is no "millions of primitives". These green prims within schematic - are represented by similar pieces of code that you can find in ruby. Just imagine, a red prim, named "def", another named "end". So switching between millions of green prims and thousands of red codes just means, that you have the same amount of "pieces", just in different visual form. ;-) And to expand it a little bit - the "queue" and "stack" prims are not larger than others because they look bigger; it's one of the traps of visual programming. :-)
Need to take a break? I have something right for you.
Feel free to donate. Thank you for your contribution.
billv
Posts: 1165
Joined: Tue Aug 31, 2010 3:34 pm
Location: Australia
Contact:

Re: bad Loop causes massive ruby shutdown

Post by billv »

tester wrote:There is no "millions of primitives"

Yeh..saw that one real clear after dropping 700,000 prims....and listening to result....
RJHollins
Posts: 1573
Joined: Thu Mar 08, 2012 7:58 pm

Re: bad Loop causes massive ruby shutdown

Post by RJHollins »

I would think that the choice between PRIMS and RUBY allow programming flexibility.

As to the difference ... I'll listen to the experts views, but I would reason that the PRIMs themselves would be fairly optimized within itself. That, considering that they may have extra functions available that may or not be used by the programmer.

As to relate to RUBY, it would seem reasonable that it could be coded to mirror a PRIM's function.

A important distinction would be how the code is written in RUBY. Writing 'optimized' code is a desired end-goal ... but my typical result is to get it to work first ! ... then consider optimizing. And oft times that means a complete rewrite of the entire concept. It takes knowledge and experience to write any kind of good code. Using PRIMS can be more of a function of 'signal logic and flow' ... but the pieces being used are mostly efficient to start.

This is all really obvious ... but, I see RUBY as a desired tool to learn and use because some programming concepts are easier for me to realize as a list of instructions, rather than a flowchart. I think it really depends on what you're wanting to accomplish, and the way you relate it to the FS environment.

The difficulty of getting over the initial Ruby hurdle seems to have the bigger challenge for me at least.

Just one example that I look to Ruby for are things like multiple IF's ... or when I can ... the CASE syntax. Trying to handle many conditionals in PRIMS can be visually tough ... where using CASE or IF's in Ruby is usually easier for me to put together, manage, and follow.

I'm not trying to lessen the importants of PRIMs ... if it wasn't for them, I'd not have gotten involved with any of this probably. The PRIMS also buy me time :shock: to learn more and get better at Ruby ... because at this moment ... I am the limiting factor. :roll:
Post Reply