RubyAPI - UI timers
-
hm... the timer is redundant. I see it working the same without it. Still find it strange it doesn't lock up SU. AS Ruby 1.8's threads are not real native threads.
Maybe the operation of adding 1 is so simple it doesn't lock up. Because I've not been able to do anything useful work within a Ruby thread...
-
@thomthom:
I forgot to say I'm using the full Ruby library 1.8.6 (with a .dll replacement and $LOAD_PATH adaptation)I would like to run a socket listener. But in general way, I want to understand how timers are managed. Maybe Sketchup has a simple loop like : manage events, drawing, timers... like a game engine would distribute time between events, animation, AI, drawing.
An other point (I am writing code to test it) is to know if a timer would repeat event if the previous iteration has no finished.
-
I am happy to show you a weird thing My friends say me often I have a twisted mind... (good thing or not? ^^)
So, I test this :
$i=0 $tid = UI.start_timer(1, true) { puts $i } $tid2 = UI.start_timer(1, true) { sleep 2 # blocks SU $i+=1 }
And in the output we have : 1, 2, 3, 4...
In conclusion, SU launch a new iteration even if the previous one isn't over.
(If not, we would have 1, 1, 2, 2, 3, 3...)
To note : SU is blocked in the iteration but can launch the next one ! -
@globuloz said:
@thomthom:
I forgot to say I'm using the full Ruby library 1.8.6 (with a .dll replacement and $LOAD_PATH adaptation)You use the Standard library? Beware that some stuff, like the Set class will conflict with the Set the that SketchUp bundle. If you distributed an extension that required the Standard Library it'd probably break lots of other extensions - might even some stuff that ship with SketchUp.
It's an issue that often crops up, that the SketchUp Ruby doesn't play quite well with the Standard Library.@globuloz said:
I would like to run a socket listener. But in general way, I want to understand how timers are managed. Maybe Sketchup has a simple loop like : manage events, drawing, timers... like a game engine would distribute time between events, animation, AI, drawing.
That's not any information which has been publicly available. I've certainly not heard of any description. Would be interesting though.
@globuloz said:
An other point (I am writing code to test it) is to know if a timer would repeat event if the previous iteration has no finished.
Nope. The timer block needs to complete.
t=UI.start_timer(0.2,true) { puts 'Timer'; x=1; 10000000.times { |i| x = x + i }; puts x }
-
@globuloz said:
To note : SU is blocked in the iteration but can launch the next one !
What is this twilight-zone we've entered here?
-
@thomthom said:
hm... the timer is redundant. I see it working the same without it. Still find it strange it doesn't lock up SU. AS Ruby 1.8's threads are not real native threads.
Maybe the operation of adding 1 is so simple it doesn't lock up. Because I've not been able to do anything useful work within a Ruby thread...
Yes, you're right, it is redundant.
Even with a block instruction, SU doesn't freeze
Thread.new { while true puts "plop" sleep 1 end }
-
I tried it - and got a BugSplat as I was trying to model while that loop was running... :s
-
I've done similar experiments and found evidence that Threads do (partially) work.
I haven't posted about it yet because then again more complex examples didn't work, locked up or crashed.
A different, but similar approach is the "sleep loop" (to make asynchronous tasks synchronous again). When I use a loop with sleep and then break if a file exists, it runs perfectly. However if I instead check whether a variable changed its value the loop freezes SketchUp.
-
BUT why would you want to use a Thread or 'sleep' inside a UI timer...
You haven't clearly explained [at least to me] what it is you want to end up with...
Anyone can lock up SketchUp with timers/sleeps/whiles/until-loops etc...
Mixing them up together just adds another layer of complexity...If you formulate a clear and simple written explanation of what it is you want to achieve [in 'English' without 'geek-speak'] then perhaps someone here or on Trimble's side can advise you on the best route forward... and some byways and pitfalls that are best to skirt around...
-
@aerilius said:
I've done similar experiments and found evidence that Threads do (partially) work.
And ... in PC SketchUp prior to v8, it distro'd with Ruby v1.8.0 in which the
Thread
class was very unstable.But threads have gotten more stable in Ruby versions above v1.8.6, even more so in the v1.8.7 branch.
Keep in mind that all the Mac Sketchup editions still disto with Ruby v1.8.5 (initial release.)Usually .. coders wish to use threads in order to prevent SketchUp from blocking.
As ThomThom said.. threads in the Ruby 1.8.x trunk are green threads (still within SketchUp's process.) Read the description of Green Threads at wikipedia.DITTO what TIG said.
Advertisement