Pull event without yelding?

Is it possible to pull an event without yelding the PC (like an os.pullEvent that returns nil if no event is in the queue) or even to read the event queue maually to implement the former?

no its not, it yields till it gets an event, thats the whole point in having a coroutine anyway, what would you need this for?

os.pullEvent is based off os.pullEventRaw
os.pullEventRaw consists of a single line of code, unfortunately for you that line is return coroutine.yield

However! You can try the following!

local evtTimeout = os.startTimer(0.05) //Single-Tick Timer
local evt = {os.pullEvent()}
if evt[2] == evtTimeout then
   //Event Timeout
end

That's a clever way to solve the problem, Ditto. Thanks! ^^

Nix, on 26 October 2012 - 02:43 PM said:

That's a clever way to solve the problem, Ditto. Thanks! ^^

D'Awww! :3 Well thank you, but it does still yield, and you may have to change the timing (I've never actually done this).

I would have to make the loop sleep, I hope that works too

Nix, on 26 October 2012 - 02:57 PM said:

I would have to make the loop sleep, I hope that works too

Sleep yields too. :D/>/> (it's basically os.setTimer(t) and os.pullEvent('timer') if I'm not mistaken)

And sleep eats events. Why do you need this anyway? Chances are you're over complicating things.

After reading the OP again. Can't you just use the parallel API to run a coroutine that pulls events and adds them to an internal queue. Then from another coroutine you can just check that internal queue for (all) new events without yielding (and waiting). You'd still want to yield now and then in that coroutine though. :D/>/>

simply do Orwell's idea with only one coroutine

local tQueue={}
local queuer=coroutine.wrap(function() while true do tQueue[#tQueue+1]={os.pullEvent()} end end)
local function pull()
  return table.remove(tQueue,1)
end

unfortunately you will need to make your code a coroutine too though

Orwell, on 26 October 2012 - 03:11 PM said:

Nix, on 26 October 2012 - 02:57 PM said:

I would have to make the loop sleep, I hope that works too

Sleep yields too. :D/>/> (it's basically os.setTimer(t) and os.pullEvent('timer') if I'm not mistaken)

I know, I mean: if I didn't yeld it for a while, the script would stop: "too long without yelding"

Cloudy, on 26 October 2012 - 03:15 PM said:

And sleep eats events. Why do you need this anyway? Chances are you're over complicating things.

What do you mean, "Sleep eats events"?

Orwell, on 26 October 2012 - 03:18 PM said:

After reading the OP again. Can't you just use the parallel API to run a coroutine that pulls events and adds them to an internal queue. Then from another coroutine you can just check that internal queue for (all) new events without yielding (and waiting). You'd still want to yield now and then in that coroutine though. :)/>/>

Ehrm… I think "my" (Thanks again, Ditto) way is simpler, so I prefer it ^^'

Orwell, on 26 October 2012 - 03:11 PM said:

Sleep yields too. :D/>/> (it's basically os.setTimer(t) and os.pullEvent('timer') if I'm not mistaken)

Huh… That's good to know (I just checked and you are correct).
It starts a timer and then pulls events until it gets that timer.
Basically it's intercepting events from being passed to the calling program until the timer ends.

Sleep eats events. If you start a five-second sleep, any and all events that the program would have otherwise received during those five seconds will be discarded by the sleep function waiting for its timer event to fire.

Ok, thank all of you

Lyqyd, on 26 October 2012 - 03:45 PM said:

Sleep eats events. If you start a five-second sleep, any and all events that the program would have otherwise received during those five seconds will be discarded by the sleep function waiting for its timer event to fire.

if you have a simultaneous coroutine listening it will still be recorded though

KaoS, on 26 October 2012 - 04:30 PM said:

Lyqyd, on 26 October 2012 - 03:45 PM said:

Sleep eats events. If you start a five-second sleep, any and all events that the program would have otherwise received during those five seconds will be discarded by the sleep function waiting for its timer event to fire.

if you have a simultaneous coroutine listening it will still be recorded though

Lyqyd, on 26 October 2012 - 03:45 PM said:

Sleep eats events. If you start a five-second sleep, any and all events that the program would have otherwise received during those five seconds will be discarded by the sleep function waiting for its timer event to fire.

As you can see, I am well aware of that fact. An easy way to demonstrate this is to use bundled cable rednet to send a large message to a computer, then have the receiving computer sleep for a short time when the message starts being received. The rednet.run() function, running in parallel with the shell, will still see all of the events come in, despite the other program sleeping.

erm, ok… I must have misunderstood. I apologize

KaoS, on 26 October 2012 - 06:12 PM said:

erm, ok… I must have misunderstood. I apologize

No, you were correct, I was simply stating that it had already been said. I then provided an easy example to see it in action.