Re: wait for messages
At 2:14 AM -0800 3/1/2002, David Vaughan wrote: >Are you really getting 30 seconds, not 30 ticks, or was that a typo? It was a typo. >I confirmed it works as you say in the runtime environment ... which is >pretty interesting ... might we have some documentation of this fact >please, while waiting for decisions on a fix...? :-) It will be in the readme if it's not fixed by the next version. -- Jeanne A. E. DeVoto ~ [EMAIL PROTECTED] http://www.runrev.com/ Runtime Revolution Limited - Power to the Developer! ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: wait for messages
Jeanne
I definitely and repeatably measure 30 ticks in the Rev Dev
environment - half a second. No message recognisable by Umbrellaman (nor
Idle nor mouseWithin, which Uman does not watch) triggered the break so
I assume it was caused by an internal "send...in.." or equivalent rather
than a Transcript event message. This was on OS X 10.1.3. Are you really
getting 30 seconds, not 30 ticks, or was that a typo? If you are, why
the difference (it might be a clue to the cause)?
I confirmed it works as you say in the runtime environment ... which is
pretty interesting ... might we have some documentation of this fact
please, while waiting for decisions on a fix...? :-)
cheers
David
On Friday, March 1, 2002, at 07:16 , Jeanne A. E. DeVoto wrote:
> At 5:26 PM -0800 2/25/2002, David Vaughan wrote:
>> Replying to myself ;-) ... of course the "wait {N time} with messages"
>> will wait the time you define while allowing other actions, and is not
>> accelerated by those actions, whereas "wait {N time}" simply waits.
>> None
>> of this makes "wait for messages", apparently meaning a random time up
>> to half a second, very useful ... so far.
>
> I have taken a look at what "wait for messages" is doing. It works as
> documented - that is, it waits until a message is sent - in a standalone
> (or in MC, for that matter) but it times out after 30 seconds in Rev's
> development environment. In these situations your handler shows results
> as
> you'd expect. My best guess at the moment is that the dev environment is
> sending a message every 30 seconds that has the effect of timing out
> wait
> for messages I'm still getting more info on this and whether it
> might
> be changeable.
>
> But it does work properly in a standalone, or when launched without the
> development environment running.
>
> --
> Jeanne A. E. DeVoto ~ [EMAIL PROTECTED]
> http://www.runrev.com/
> Runtime Revolution Limited - Power to the Developer!
>
>
> ___
> use-revolution mailing list
> [EMAIL PROTECTED]
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution
Re: wait for messages
At 5:26 PM -0800 2/25/2002, David Vaughan wrote:
>Replying to myself ;-) ... of course the "wait {N time} with messages"
>will wait the time you define while allowing other actions, and is not
>accelerated by those actions, whereas "wait {N time}" simply waits. None
>of this makes "wait for messages", apparently meaning a random time up
>to half a second, very useful ... so far.
I have taken a look at what "wait for messages" is doing. It works as
documented - that is, it waits until a message is sent - in a standalone
(or in MC, for that matter) but it times out after 30 seconds in Rev's
development environment. In these situations your handler shows results as
you'd expect. My best guess at the moment is that the dev environment is
sending a message every 30 seconds that has the effect of timing out wait
for messages I'm still getting more info on this and whether it might
be changeable.
But it does work properly in a standalone, or when launched without the
development environment running.
--
Jeanne A. E. DeVoto ~ [EMAIL PROTECTED]
http://www.runrev.com/
Runtime Revolution Limited - Power to the Developer!
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution
Re: wait for messages
David,
I appreciate the research you did on this. You've clarified many of the issues I
raised.
I'm still experimenting, trying to better understand how multiple waits of various
sorts interact with oneanother. My interest has to do with attempting to emulate some
sort of rudimentary multithreading behavior with a centralized scheduler that can dole
out processing time in a controlled fashion. I believe "send ... in " semantics
alone aren't quite up to that.
Given the way messaging works in TransScript, threads would have to be cooperative, of
course, but I can work around that.
Although I still have some timing questions to resolve, I think I've got much of it
figured out. The other "wait" forms are very useful, but "wait for messages" is
turning out to have no role in my particular application, now that I know what it's
doing.
Thanks for your help.
RR
David Vaughan wrote:
> On Tuesday, February 26, 2002, at 12:11 , David Vaughan wrote various
> things readable in the previous post by me under this title :-)
>
> Replying to myself ;-) ... of course the "wait {N time} with messages"
> will wait the time you define while allowing other actions, and is not
> accelerated by those actions, whereas "wait {N time}" simply waits. None
> of this makes "wait for messages", apparently meaning a random time up
> to half a second, very useful ... so far.
>
> regards
> David
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution
Re: wait for messages
Bob I think we can now answer some of your questions: Why should it have worked the first time, but not subsequently? In my experience, it never waited (in the indefinite sense) and I have no idea why it waited for you even once. Your system had some coincidental activity that slowed it down at the critical moment? Are there messages a script can never see (or that bypass the usual message hierarchy) that, nevertheless, satisfy the wait condition of "wait for messages"? I doubt it. It just seems to time out after a period up to 500ms. Is there a way to see what messages are causing "wait for messages" to stop waiting? Thanks to Richard Gaskin's Umbrellaman, just posted, I checked and there are no known messages causing it to time out. It just stops, as I said above. Is there a way to get a message trace in general? That would be extremely useful. Indeed it is. Check Richard's post and stack. What does the following note in the "waitDepth" entry of the Transcript Dictionary mean? "The wait for messages form of the wait command allows Revolution to respond to messages and execute handlers while waiting." As I said in my earlier post on this, "wait N time" stops other handlers while it waits whereas "wait for messages" allows them to execute while it waits up to half a second, and "wait N time with messages" waits that time while allowing other events and handlers to execute. Shouldn't that be "... with messages form ..."? ...well, that is more useful, I think. snip Speaking of "waitDepth", if there are multiple waits pending, in what order to they resume? Last first? Last last? Unspecified? It appears to me that the waitDepth shows the number of handlers executing, not the messages waiting. This is pretty much what the documentation says. The tests above (one button) showed a waitDepth of 1 while the test below (used two buttons, waiting one while pressing another) showed a waitDepth of 2. Does a message resume all waiting handlers, or just the next in line? I'm guessing all, if the documentation is correct, but the resumption order question still pertains. I've looked in the Revolution stacks for examples of "wait for messages". They all look something like this: . . . repeat while someStatus is empty wait for messages end repeat . . . Why wasn't the command "wait while someStatus is empty with messages" used instead? Can't answer for why, but... Are these equivalent? ...they are not equivalent. The "wait while...with messages" construct will barrel along handling all messages and executing all handlers other than the one with the wait statement, until the wait is satisfied when it, too, will resume. A "wait for messages" form will continue execution of that handler after 500ms even where nothing else has happened. One potential difference I see is that the repeat loop won't pause for messages if the loop condition is false, while "wait while" might require at least one message to proceed, even if the condition is already false. Is that right? No, it isn't. The condition is checked immediately and, if false, processing continues. Sorry for being longwinded, but a detailed section in the documentation on execution order, in the presence of waits and sends, would be welcome, and I'm hoping all these questions prompt some of its contents. Execution order is the usual chronological order of events (and their messages). It is not mucked around by wait except to the extent that a script is halted in certain usages or that other handlers can execute during that time, but, again, in their natural order. All my comments are research-based, not guru-given, so forgive me for any errors, omissions or lack of clarity. My tentative conclusion, incidentally, is that "wait...with messages" is great and "wait for messages" is useless. Whether or not the last is true, the documentation on it needs improvement. regards David
Re: wait for messages
On Tuesday, February 26, 2002, at 12:11 , David Vaughan wrote various
things readable in the previous post by me under this title :-)
Replying to myself ;-) ... of course the "wait {N time} with messages"
will wait the time you define while allowing other actions, and is not
accelerated by those actions, whereas "wait {N time}" simply waits. None
of this makes "wait for messages", apparently meaning a random time up
to half a second, very useful ... so far.
regards
David
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution
Re: wait for messages
OK, I've waited a bit for a Transcript guru to answer Bob's questions (in shortened form below) but nothing has clarified this so far. So I tried a couple of experiments myself, effectively replicating Bob's results. These are two of my tests: In the stack I put this idle handler (oh shame!) on idle global gFrog add 1 to gFrog end idle and in a button this script: on mouseUp global gFrog put zero into gFrog put empty into field 1 put empty into field 2 repeat with i = 1 to 50 wait for messages put i & comma after field 2 put gFrog & comma after field 1 end repeat end mouseUp The result was that messages continue to flow during the repeat loop, but only slowly, a shade faster than the idle message (and therefore it was not the idle message, as promised by the documentation). If I moved the mouse during the loop then it accelerated dramatically. I ditched the idle script and changed the button script to: on mouseUp put empty into field 1 put empty into field 2 put the ticks into tickTime repeat with i = 1 to 50 wait for messages put (the ticks - tickTime) & comma after field 2 put the ticks into tickTime end repeat put average(field 2) into field 1 end mouseUp Being careful not to move the mouse, I clicked the button and saw tick delays of 6,17 and 32 for the first three instances after which it settled down to 30 tick intervals with the occasional 29 (average 29 ticks). Wriggling the mouse accelerated the loop to 1-2 tick delays. So, part of the answer seems to be that "wait for messages" will wait up to 30 ticks for a message and then continue processing anyway. In fact, it may wait only 6 or so ticks on the first pass. This is not what the documentation says, and also leaves the value of the construct rather uncertain. Incidentally, in a separate test I found that waitDepth remained at 1 before, during and after a loop such as the above. This seems correct if it means that only the mouseUp handler was executing. Is there any further enlightenment that can be offered on the "Wait for messages" command please? I am comfortable at the moment with the "with messages" form. Unless further experiments have offered him enlightenment, Bob is probably still pretty curious too. regards David On Monday, February 25, 2002, at 01:00 , Bob Rasmussen wrote: Can anyone give me some insight about the "wait for messages" command? Is there a way to see what messages are causing "wait for messages" to stop waiting? Is there a way to get a message trace in general? That would be extremely useful. Devin Asay asked for a Message Watcher today. I didn't use it much in HC but it would certainly have been useful here. What does the following note in the "waitDepth" entry of the Transcript Dictionary mean? "The wait for messages form of the wait command allows Revolution to respond to messages and execute handlers while waiting." Speaking of "waitDepth", if there are multiple waits pending, in what order to they resume? Last first? Last last? Unspecified? Does a message resume all waiting handlers, or just the next in line? I'm guessing all, if the documentation is correct, but the resumption order question still pertains. I've looked in the Revolution stacks for examples of "wait for messages". They all look something like this: . . . repeat while someStatus is empty wait for messages end repeat
Re: wait for messages
Title: Re: wait for messages on 2/24/02 6:00 PM, Bob Rasmussen at [EMAIL PROTECTED] wrote: > Can anyone give me some insight about the "wait for messages" command? -- I'm still a long ways from understanding all the new stuff in MC/RR different from HC, but I'm betting if no pending messages exist, it will freeze until RR gets a message, which would explain why the simple handler you wrote continued only after you moved the mouse, which sent a message, of course. If anything sends any message, open a card, move the mouse, type something, any message except idle, the script will take off again as soon as RR gets it. This gives some more control to the user. Everything (but idle) stops right where it is, if they need to answer the phone, stop the coffemaker from boiling over, whatever, but if RR was in the middle of making computations, that would continue. It probably wouldn't suspend computing, but it would stop the rest of the script from running until the user hits a key or moves the mouse, like what happens with a screensaver. Just a hunch. Best regards, Ken N.
wait for messages
Can anyone give me some insight about the "wait for messages" command? The first time I ever tried to use it, I put the following lines into a main stack script: . . . wait for messages put "done waiting" . . . I ran the script from the message box and lo and behold, nothing happened until I moved the mouse, when "done waiting" appeared in the window. "Okay. That works just as expected," I thought. The trouble is, it has never worked since! That is, "wait for messages" never waits, but proceeds immediately to the next line in the script. I've tried a number of variations (putting the wait in a button script, calling the script in a delayed send, and so on), but with no luck. My initial suspicion was that there are repeated messages similar to idle, causing "wait for messages" to proceed. I identified a small number of potential candidates, but putting in handlers in the stack script to signal if they were occurring showed nothing. By the way -- this was particularly surprising for the mouseWithin message, which seems not to follow the usual message path. That is, a mouseWithin handler in a control gets the message, but without a handler in the control, the message is not passed up the hierarchy as you would expect. I didn't find any documentation of this feature. In any event, these messages also apparently cease when the cursor is outside any window (unless that counts as within something else), but "wait for messages", nevertheless, does not wait. Do I have the wrong idea about how "wait for messages" ought to work? Why should it have worked the first time, but not subsequently? Are there messages a script can never see (or that bypass the usual message hierarchy) that, nevertheless, satisfy the wait condition of "wait for messages"? Is there a way to see what messages are causing "wait for messages" to stop waiting? Is there a way to get a message trace in general? That would be extremely useful. What does the following note in the "waitDepth" entry of the Transcript Dictionary mean? "The wait for messages form of the wait command allows Revolution to respond to messages and execute handlers while waiting." Shouldn't that be "... with messages form ..."? Otherwise, as near as I can tell, as soon as there are messages to respond to, "wait for messages" stops waiting, so how can you "execute handlers while waiting" when you're no longer waiting? The only way I can reconcile this is if Revolution always handle at least one message before resuming from "wait for messages". Is that how it works? If so, how many messages does it handle before resuming? Speaking of "waitDepth", if there are multiple waits pending, in what order to they resume? Last first? Last last? Unspecified? Does a message resume all waiting handlers, or just the next in line? I'm guessing all, if the documentation is correct, but the resumption order question still pertains. I've looked in the Revolution stacks for examples of "wait for messages". They all look something like this: . . . repeat while someStatus is empty wait for messages end repeat . . . Why wasn't the command "wait while someStatus is empty with messages" used instead? Are these equivalent? One potential difference I see is that the repeat loop won't pause for messages if the loop condition is false, while "wait while" might require at least one message to proceed, even if the condition is already false. Is that right? Sorry for being longwinded, but a detailed section in the documentation on execution order, in the presence of waits and sends, would be welcome, and I'm hoping all these questions prompt some of its contents.
