RubyAPI - UI timers

globuloz

Hello,

I am a new trainee in Trimble Paris and I have to develop a sketchup plugin.
I am a newbie and I saw that timers (defined in UI module) would be great to do asynchronous stuff.

In order to think right, I wish to know how these timers work in Sketchup. I mean, how Sketchup manages these timers ? When does it launch them ? Maybe in a thread ? Can two timers run in the same time (if the previous one hasn't finish before the time expire)

Thanks to help me to understand the Sketchup implementation, and sorry for my poor English !

TIG

Welcome...

I am pleased you have come here to SCF to ask your questions...
BUT as a contracted 'Trimble-guy' you might consider asking [without much hope of a useful reply!] in their 'somewhat ineffectual' Trimble..SketchUp..API www-site, or even ask for help directly to the Trimble SketchUp guys themselvesin Boulder...

BUT then... you might well get better answers for us - we are 'the guys at the cutting edge', compared to your own vapid forum and your 'office coders' who are not focused on the world 'as it is'...
BUT it does rankle me a little that 'Trimble' [for that is who you now represent - like it or not] will ask SCF members for help, when Trimble themselves are not always quite so forthcoming in the other direction to help us.

That is now 'off my chest'...
firstly please read the Trimble Sketchup API documents on UI and timers... !
BUT put simply...
You launch a timerN = UI.timer_start(time_interval, repeat){### what to do each iteration}
You can have any number of timers running at a time, if they might 'interact' with each opther then you need to manage how they might do it !!!
Timers do work 'asynchronously', BUT of course block up your threads if they are 'incomplete' or still 'running'.
You can 'run' a 'Timer' just one time if repeat==false- typically then the time_interval=0, so that it starts right away...
You can stop a 'Timer' if some event crops up externally, OR something happens within the Timer's block {} block itself - using:
UI.timer_stop(timerN) if xxxx
Where timerN is the reference to the particular Timer and xxxx is the test true || false to stop it/
If this helps you then please consider starting a personal 'Premium Membership' to SCF, as a small recompense for having taken such useful advice from a 'free-forum' compared to your 'boss' - a 'mega-company'...

thomthom

Yea, sounds like you really want threads - which unfortunately does not work in the SketchUp Ruby API. At least not in any way that doesn't block the rest of the SketchUp process.

Also, I'd strongly recommend against attempting to perform any action from within a timer which manipulates the SketchUp model. You'll be very likely to interfere with both native and third-party extension operations - maybe even BugSplat SketchUp.

Can you give some hints on what you want to achieve? Maybe we can suggest some solution?

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.