Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

events vs trace

48 views
Skip to first unread message

sled...@gmail.com

unread,
Jul 25, 2018, 2:32:17 PM7/25/18
to
Aside from the women using this group who are just dying to meet me ...

Question: does it take less time and resources to use events or 'tracing' the change of a variable to handle an event.

Background:

Have a speech rec app that employs TCOM to interface with MS SAPI. SAPI posts a recognition event, which, in turn is managed by a tcl event bound to a window as a result of an event generate command.

Tried to use uevent, but Komodo throws up even while editing.

BTW: Speech rec is exceedingly response-time sensitive. As an aside, most often, it is only a 500ms pause that indicates to you that the other person has stopped speaking.

But I digress...

So the thought occurred - put trace on a variable that is modified when TCOM passes back the SAPI recognition event. Seems that is a lot less 'work' in terms of setup and execution.

Perspectives on this are most welcomed.

And 'Yes', I am asking this before time is spent developing a test suite and timings.

And if you want to mess with Alexa's mind...just ask her\it to play "Sioux City Sue".

briang

unread,
Jul 25, 2018, 5:57:26 PM7/25/18
to
On Wednesday, July 25, 2018 at 11:32:17 AM UTC-7, sled...@gmail.com wrote:
> Aside from the women using this group who are just dying to meet me ...
>
> Question: does it take less time and resources to use events or 'tracing' the change of a variable to handle an event.
>
> Background:
>
> Have a speech rec app that employs TCOM to interface with MS SAPI. SAPI posts a recognition event, which, in turn is managed by a tcl event bound to a window as a result of an event generate command.
>
> Tried to use uevent, but Komodo throws up even while editing.
>
> BTW: Speech rec is exceedingly response-time sensitive. As an aside, most often, it is only a 500ms pause that indicates to you that the other person has stopped speaking.
>
> But I digress...
>
> So the thought occurred - put trace on a variable that is modified when TCOM passes back the SAPI recognition event. Seems that is a lot less 'work' in terms of setup and execution.
>
> Perspectives on this are most welcomed.

You have to understand the difference between the two approaches. The trace will fire and execute the callback immediately when the variable is set. The [set] command cannot complete until the callback is done, thus blocking other event activity. (and don't even think about calling [update] in a trace callback.)

Using events allows for the event loop to determine what should be handled and when, hopefully giving better overall behavior.

>
> And 'Yes', I am asking this before time is spent developing a test suite and timings.

Most likely the only way to know what works best is to do the testing and timings.


-Brian

sled...@gmail.com

unread,
Jul 25, 2018, 6:01:46 PM7/25/18
to
Thank you...
That is the insight that I was hoping to get. Info regarding event loop ... invaluable...

Ralf Fassel

unread,
Jul 26, 2018, 6:41:12 AM7/26/18
to
* sled...@gmail.com
| Question: does it take less time and resources to use events or
| 'tracing' the change of a variable to handle an event.

Don't know the answer to that, but I dislike traces for anything but
trivial things like changing colors or updating tooltip texts.

With traces, an 'innocent'
set variable to-something
in the code does not indicate that anything can happen before that line
terminates. This is especially true in multi-module code where the
trace is set up by programmer A in February in one module and the
variable is set by programmer B in October in another.
Takes programmer C until December to debug errors in that. ;-)

With
event generate {.} <<SomeEvent>>
it is clear that anything can happen via the event.

My EUR 0.02
R'
0 new messages