RubyAPI - UI timers

globuloz

@TIG:
Thank you for your response !

Well, I just arrive in the company, I will be there for only three months so I have no pretension to represent anyone but me ^^
I use, for personal projects, only open-source work and collaborative forum like yours. This is why I preferred to go here in a first time.
Actually, I was a little bit surprised by your first part of your response BUT (;)) I understand it completely !

To return to the main point of the subject, I have read the API of course and I know what you wrote. However, I wish you explain more your sentence :

@unknownuser said:

Timers do work 'asynchronously', BUT of course block up your threads if they are 'incomplete' or still 'running'.

Moreover, I test a little thing :


UI.start_timer(0, false) {
	Thread.new {
		$i=0
		while true
			$i+=1
		end
	}
}

and you can see in Ruby Console that $i continues to change although the main code has finished.

Maybe you are right : I should ask to a Boulder guy because he has an access to the source code.

Thanks again, have a nice day !

thomthom

@globuloz said:

Moreover, I test a little thing :


> UI.start_timer(0, false) {
> 	Thread.new {
> 		$i=0
> 		while true
> 			$i+=1
> 		end
> 	}
> }
>

and you can see in Ruby Console that $i continues to change although the main code has finished.

Maybe you are right : I should ask to a Boulder guy because he has an access to the source code.

Thanks again, have a nice day !

o_O

What??? How on earth does that work? I see it - but it's just plain weird!

If I make a timer and make it do work it blocks the rest of SU as long as that block executes.

If I make a Thread it will block the rest of SU as long as that block textures.

How that loop can work within the timer block and not lock up SketchUp is really puzzling me!

thomthom

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...

globuloz

@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.

globuloz

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 !

thomthom

@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 }

thomthom

@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?

globuloz

@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
	
}

thomthom

I tried it - and got a BugSplat as I was trying to model while that loop was running... :s

Aerilius

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.

TIG

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...

Dan Rathbun

@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.