Say I have a stream of events and I want to be able to count how many of them there are in a time window. I would like to receive notification whenever an event enters the time window and changes the count and the same when an event exits the time window.
The below illustration show what I mean. I'm using a time window of length 4 and I want 3 notifications, one when the first event enters the window, the second when the second event enters and the third when the first event exits the time window.
How do I make a query that does that? What if I also want to group by an event's property?
Here's what I have so far, but it doesn't give me a notification when an event leaves the window: #config(async = 'true') define stream myStream (symbol string, timeStamp long) #info(name = 'query1') from myStream#window.externalTime(timeStamp,10 sec) select symbol, timeStamp, count(timeStamp) as eventCount group by symbol insert into outputStream. This is for SIddhi CEP, but I imagine Esper would be similar.
From any type of a window in WSO2 CEP, you can expect two types of events.
Current events - these are triggered when a new event enters the window. i.e. the new event itself is used as a trigger
Expired events - these are triggered when an existing event in the window exits it. i.e. in case of a time window of 1 minute, each event is kept for 1 minute and emitted at the end of 1 minute
You can also use a combination of these two in the same query to trigger it from both types of events.
An example query that uses both types of triggers in CEP 3.1.0 will be (check the docs here):
from StockExchangeStream[symbol == 'WSO2']#window.time( 1 minute )
select max(price) as maxPrice, avg(price) as avgPrice, min(price) as minPrice
insert into WSO2StockQuote for all-events
if you want this to be triggered only using expired events, use 'expired-events' in place of 'all-events'. Same applies for current-events. If you don't specify anything, it defaults to current-events, that's why your current query doesn't get triggered for expired events.
Note that for CEP 4.0.0 the syntax is a bit different, for correct syntax check the test source codes here (since the docs are still work-in-progress).
Related
I am using Python 2.7, Robot Framework and Selenium2Library on a windows server.
On a page with a button and a data text box, I have a selenium test that clicks the button, this fires off a get request and on return recreates the data text box and updates with the new value. The test then sleeps for 10s to allow this to happen and then reads the value in the data text box.
What I would really like to do is get the element for the data text box, then click the button and keep polling for the original data text reference to become unavailable on the DOM i.e. it has been recreated, and then read the text box to get the value.
I can't for the life of me find out how I would do that using Robot Framework and Selenium2Library as all the calls are self contained and don't pass references back.
Could you offer any other solution?
There are a number of ways to do it with the SeleniumLibrary, all revolving around its Wait Until keywords - documentation link.
Option one - the element is the same, so its locator doesn't change; the check is done with Wait Until Element Contains, and passing the new text:
Click Element ${the_locator_for_the_button}
Wait Until Element Contains ${the_locator_for_the_element} your target text
Option two - if on click the target element changes to a different one, e.g. the locator is different. Then you'd first wait for the initial element to disappear, and the new one to appear:
Click Element ${the_locator_for_the_button}
Wait Until Element Is Not Visible ${the_locator_for_the_initial_element}
Wait Until Element Is Visible ${the_locator_for_the_new_element}
Option three - if you don't want to deal with locators, but to make sure the actual element as Selenium sees it disappears, you can get it with Get Webelement, and then pass that reference to the Wait ... keywords - most (if not all) SeleniumLibrary support both locators or acutal webelements:
Click Element ${the_locator_for_the_button}
${webelement}= Get Webelement ${the_locator_for_the_initial_element}
Wait Until Element Is Not Visible ${webelement}
The good thing about the Wait Until ... keywords is that they constantly poll the DOM for the expected change, and continue at the first detection the condition is met. E.g. it's not a hardcoded sleep that'll pause the execution for the predefined time, but finish as soon as ready.
Have also in mind all these keywords support the argument timeout=Xs, where the X is the time up to which the keyword waits for the condition to be met.
Basically exactly what the title says. I would like to update the text that a button contains every 1 second when the user presses that particular button. I have noted that when the program doesn't have focus it works alright and the text refreshes correctly but when I am hovering over the program or when I am trying to click on it's menu Windows inform me that the program is unresponsive and asks me if I want it terminated. When the loop finishes the program returns to its normal state. Also any action I might have done (like moving it around or closing it) while it was Sleep()-ing is executed after the loop. Here is a bit of code:
case ID_BUTTON_START:
// Code executed when pressing Start Button.
char startButtonText[30]; // Storing next loop text
for (int i=5; i>0; i--)
{
sprintf(startButtonText, "Starting in ... %d", i);
SendMessage(hwndButtonStart, WM_SETTEXT, 0, (LPARAM)(startButtonText));
Sleep(1000);
}
Is this normal? If not what's causing this?
The WndProc does not process messages asynchronously within an application which means all messages are expected to be handled quickly and a return value delivered immediately. You must not Sleep in the UI thread since it will block other UI events from being processed. Any heavy work or synchronous requests/jobs which are likely to take a long time should be performed in worker threads. There are at least three viable options:
Create a new (worker thread) for the task.
If the task is likely to be done often, use a thread pool instead.
Set and subscribe to timer events.
I think the call to Sleep() might be keeping you from returning from the WndProc, so your application is not processing the incomming events for 5 secs. I suggest you try to subscribe to 5 timer events in 1s, 2s,..., 5s. Like when the timer message is recieved the button text must change. I don't know a way how to do that off the top of my head.
Using Qt4.8 on a Mint Linux 12, I implemented a simple window containing a QTableView to show contents of a model. The model data is continually updated (log messages) and the dataChanged() signal is emitted on a regular basis (i.e. every 100ms).
The problem I see is stuttering visual updates on the table.
I installed an event filter on the window that counts updateRequest-type events, which should trigger a widget repaint (also on child widgets, i.e. the tableView). These come in with an average time of ~170ms between them and a standard deviation of ~90ms (which is rather large, I guess). However, the perceived visual update rate is only two or three times a second and I wonder why. It seems that not all updateRequest events trigger a widget repaint or that the window system swallows visual updates.
As a second test, I forced the window to update itself by calling repaint or update every 100ms. Using repaint, I saw a corresponding increase in updateRequest-type events and a decrease of the standard deviation of the gaps; with update, the number did not increase. However, there was only a moderate increase of perceived update rate in both cases.
Also: Is there a good method to measure how often a widget is actually really repainted without having to overload its paintEvent handler? Maybe something from QTest?
Update: I extended my event filter to also catch paintEvent-type events. There are only a one-digit number of those versus > 1000 updateRequest-type events.
You should instrument the event dispatcher's aboutToBlock() and awake() signals, and measure time between them using a QElapsedTimer. The instance of the event dispatcher for the current thread is returned by the static QAbstractEventDispatcher::instance().
If the event loop sleeps for a very small fraction of your time measurement window, it means there's too much stuff going on in the GUI thread. You can keep a count of how long the event loop slept, say, during the last second. If it's below 10%, you can expect slow updates and whatnot. Remember that update events are queued with Qt::LowEventPriority. They will be preempted by standard queued signals and almost all other events.
QApplication::compressEvent discards QEvent::UpdateRequest, if there is already one unprocessed. Thus even repaint(s) can return immediately without painting, if the event is discarded. You can check, if your updateRequest events are discarded by overwriting compressEvent.
In the documentation of Ember.StateManager it's said that : "Inside of an action method the given state should delegate goToState calls on its StateManager". Does it mean that if I send an action message, I necessarily need to transit to another state. Is it possible to stay in the same state but doing some task by sending an action ? For example, I'm in a state "loading" and I run two actions "preprocess" and "display".
Very simply: an action message may but does not have to transition to another state.
Something you didn't ask, but is related and important: it is a bad idea and bad design to call goToState in an enter or exit method.
When dealing with statecharts in general, you can do whatever you want. It's not mandatory to switch states in an event handler. A common case would be an event handler that shows a cancel/save dialog. You can easily put the dialog on the page in the event handler, and proceed accordingly depending on which button is pressed.
A separate question is should every event handler basically just go to another state. In the above scenario, you can certainly go to a "confirm" state, the state-enter method will show the dialog, and there would be two handlers, one for each button. Those handler would in turn go to other states.
Both design choices I think are equally valid, at least in that scenario. If you choose to implement a separate state for every action, you will end up with a lot of small but concise states. If you choose to do stuff in the event handlers themselves, your states will be bigger, but there will be less of them.
One thing I will say is if an event handler is getting complicated, you are probably better of with a new state. Also, be consistent.
For you specific scenario, if I'm reading it right, you want to load data and then change the display to show the data, based on an event. In this case, I would use new states.
So you press a button that starts the process
In the event handler, go to some sort of 'MyDataSection' state
Initial substate is 'loadData'
Enter state method of 'loadData' starts the loading process
Event handler 'dataLoaded' in 'loadData' to handle when the data loads; this means you need to fire an event when the data loads
'dataLoaded' event goes to the 'show' state
show state shows the view (or removes activity indicator etc) and handles any events that come from the display.
What's good here is that if you have multiple ways to get to this section of the app, all actions that lead to this section only need to go to this state, and everything will always happen the same. Also note that since the view event handlers are on the show state, if the user hits a button while the data is loading, nothing will happen.
Basically, when one types, a keydown event happens. If the key is held for more than a certain time (~1 sec) then the key is repeatedly pressed until keyup hapens. I would like to change the time it takes for the key to be automatically repressed in my c++ application. How can this be done?
Thanks
The speed at which a keypress becomes automatically recurring is controlled by Windows.
If you want to manipulate automatic recurrences of key-presses, it might be more advantageous to poll for the state of the key rather than waiting for the keydown event. It depends on how responsive you need your application to be.
This article may help you in figuring out how to query for key states: link
You can use the SystemParametersInfo function to change the keyboard delay and refresh rate, as described in this newsgroup thread.
A simple way to handle this is to establish a buffer of time around the OnKeyDown event. Setup a timer that determines whether control passes to a secondary event handler. If the timer has expired, then it is OK to pass control. If the timer hasn't expired, then you should return and leave the event unhandled. Start the timer right before passing control to your secondary event handler.
void KeyDownHandler(...)
{
// ...
if (TimeLeft() <= 0)
{
StartTimer();
handleKeyDown();
}
}
A timer is better than counting duplicate events because you can't assume that a given system will have the same repeat rate set as yours.
I agree with Stuart that polling for the state of the key might work better. It depends upon what you are trying to accomplish.
Also note that this type of behavior might be highly annoying to your user - why do you need to ignore duplicates?
You might be able to tap into a Windows API but this might be controlled by the OS. Not sure...
You might need to manually draw a command such as to simulate a key press multiple times after a set number of seconds after the key has been pressed.
Use SetKeySpeed api (Kernel)