If you have a problem or need to report a bug please email : support@dsprobotics.com
There are 3 sections to this support area:
DOWNLOADS: access to product manuals, support files and drivers
HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects
USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here
NEW REGISTRATIONS - please contact us if you wish to register on the forum
Users are reminded of the forum rules they sign up to which prohibits any activity that violates any laws including posting material covered by copyright
bad Loop causes massive ruby shutdown
14 posts
• Page 2 of 2 • 1, 2
Re: bad Loop causes massive ruby shutdown
Thanks Trog.....can see those error's very clearly now... cheers
BV MUSIC SYDNEY AUSTRALIA..Songwriting and Software development
Headquartershttps://www.bvmusicsydneyaustralia.com/
Spotifyhttps://open.spotify.com/artist/7JO8QM40mVmHb7pAwKPJi0
Donatationhttps://www.paypal.com/donate/?hosted_button_id=HEUR8R7K8GZ4L
Headquartershttps://www.bvmusicsydneyaustralia.com/
Spotifyhttps://open.spotify.com/artist/7JO8QM40mVmHb7pAwKPJi0
Donatationhttps://www.paypal.com/donate/?hosted_button_id=HEUR8R7K8GZ4L
- billv
- Posts: 1157
- Joined: Tue Aug 31, 2010 3:34 pm
- Location: Australia
Re: bad Loop causes massive ruby shutdown
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.
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.
Feel free to donate. Thank you for your contribution.
- tester
- Posts: 1786
- Joined: Wed Jan 18, 2012 10:52 pm
- Location: Poland, internet
Re: bad Loop causes massive ruby shutdown
tester wrote:There is no "millions of primitives"
Yeh..saw that one real clear after dropping 700,000 prims....and listening to result....
BV MUSIC SYDNEY AUSTRALIA..Songwriting and Software development
Headquartershttps://www.bvmusicsydneyaustralia.com/
Spotifyhttps://open.spotify.com/artist/7JO8QM40mVmHb7pAwKPJi0
Donatationhttps://www.paypal.com/donate/?hosted_button_id=HEUR8R7K8GZ4L
Headquartershttps://www.bvmusicsydneyaustralia.com/
Spotifyhttps://open.spotify.com/artist/7JO8QM40mVmHb7pAwKPJi0
Donatationhttps://www.paypal.com/donate/?hosted_button_id=HEUR8R7K8GZ4L
- billv
- Posts: 1157
- Joined: Tue Aug 31, 2010 3:34 pm
- Location: Australia
Re: bad Loop causes massive ruby shutdown
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 to learn more and get better at Ruby ... because at this moment ... I am the limiting factor.
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 to learn more and get better at Ruby ... because at this moment ... I am the limiting factor.
- RJHollins
- Posts: 1571
- Joined: Thu Mar 08, 2012 7:58 pm
14 posts
• Page 2 of 2 • 1, 2
Who is online
Users browsing this forum: No registered users and 62 guests