Qt4: Unresolved timer events - qt

A mini sample file main.cpp:
#include <iostream>
#include <QCoreApplication>
class MyApp : public QCoreApplication
{
private:
int m_idtimer;
public:
MyApp(int nargs, char* argc[]) : QCoreApplication(nargs, argc)
{
m_idtimer = startTimer(3000); // 3 segs.
}
protected:
void timerEvent(QTimerEvent* e)
{
char c = '\0';
std::cout << "timerEvent" << std::endl;
std::cin >> c;
if (c == 'q') {
killTimer(m_idtimer);
quit();
}
}
};
int main(int nargs, char* argc[])
{
MyApp app(nargs, argc);
return app.exec();
}
Extra mini Makefile:
LDFLAGS = -I/usr/include/qt4 -I/usr/include/qt4/QtCore
LDLIBS = -lQtCore
Compiling and execution:
$ make main
g++ -I/usr/include/qt4/QtCore main.cpp -lQtCore -o main
$ ./main
timerEvent
1
timerEvent
2
timerEvent
3
timerEvent
q
$
Ok and then, my question. I’ve made this sample with the purpose of testing if timer events are accumulative.
When I executing the main program, the next occurs:
the first timerEvent message is shown after 3 seconds, and timerEvent() waits a character.
I press 1 inmediatly.
3 seconds later, the second timerEvent message appear (as expected).
I wait some seconds (15 or more) and I press 2
The third message is shown immediatly (one timer event accumulated).
I press 3 immediatly.
And 3 seconds later the fourth message appear (no more timer events accumulated).
I press q and the program ends.
Question: Why aren there no more timer events accumulated? Does this behaviour depend on the platform?
PD: My Qt version is 4.8, my SO Ubuntu 13.04, and my kernel (linux) 3.8.0-19-generic. The running graphic system is Gnome 3.

Your fifteen second wait will not accumulate timer events because your timerEvent code blocks waiting for the input. Qt can't get back into its event loop until you enter the input. When it does get back to the event loop it checks the elapsed time and notices that more than 3 seconds have elapsed and so it fires off a timer event. The fact that fifteen seconds has elapsed is irrelevant.
This is the expected behaviour and will not (should not) be platform-dependent.

Related

How to compose multiple unit test result in a single txt file

I am using QTestLib Library and QTest for running my unit tests. I am working on windows 7 and using Qt 4.8 When I run my test using:
int main(int argc, char *argv[])
{
// Test gui widgets - 2 Spinboxes and 1 Combobox
QApplication a(argc, argv);
TestSpinBox testSpinBoxObj;
TestComboBox testComboBoxObj;
QTest::qExec(&testComboBoxObj, argc,argv);
QTest::qExec(&testSpinBoxObj, argc,argv);
return 0;
}
I get the output in the console:
Starting D:\Projects\Qt Learning\TestGui (1)\TestGui\debug\TestGui.exe...
********* Start testing of TestComboBox *********
Config: Using QTest library 4.8.1, Qt 4.8.1
PASS : TestComboBox::initTestCase()
PASS : TestComboBox::testComboBoxStepUp()
PASS : TestComboBox::testComboBoxStepDown()
PASS : TestComboBox::cleanupTestCase()
Totals: 4 passed, 0 failed, 0 skipped
********* Finished testing of TestComboBox *********
********* Start testing of TestSpinBox *********
Config: Using QTest library 4.8.1, Qt 4.8.1
PASS : TestSpinBox::initTestCase()
PASS : TestSpinBox::testSpinBoxStepUp()
PASS : TestSpinBox::cleanupTestCase()
Totals: 3 passed, 0 failed, 0 skipped
********* Finished testing of TestSpinBox *********
D:\Projects\Qt Learning\TestGui (1)\TestGui\debug\TestGui.exe exited with code 0
How to get the same in a single text file
There is -o filename option to specify output file. For each test object you can redirect output to own file and later concatenate them together.
QList<QObject *> objects;
objects << new TestSpinBox << new TestComboBox;
QString result;
foreach (QObject *o, objects) {
QTemporaryFile f;
f.open();
QStringList args = app.arguments();
args << "-o" << f.fileName();
QTest::qExec(o, args);
result += "\r\n" + f.readAll();
}
qDeleteAll(objects);

mpiexec checkpointing error (RPi)

When I try to run an application (just a simple hello_world.c doesn't work) I receive this error every time:
mpiexec -ckpointlib blcr -ckpoint-prefix /tmp/ -ckpoint-interval 10 -machinefile /tmp/machinefile -n 1 ./app_name
[proxy:0:0#masterpi] requesting checkpoint
[proxy:0:0#masterpi] checkpoint completed
[proxy:0:0#masterpi] requesting checkpoint
[proxy:0:0#masterpi] HYDT_ckpoint_checkpoint (./tools/ckpoint/ckpoint.c:111): Previous checkpoint has not completed.[proxy:0:0#masterpi] HYD_pmcd_pmip_control_cmd_cb (./pm/pmiserv/pmip_cb.c:905): checkpoint suspend failed
[proxy:0:0#masterpi] HYDT_dmxu_poll_wait_for_event (./tools/demux/demux_poll.c:77): callback returned error status
[proxy:0:0#masterpi] main (./pm/pmiserv/pmip.c:206): demux engine error waiting for event
[mpiexec#masterpi] control_cb (./pm/pmiserv/pmiserv_cb.c:202): assert (!closed) failed
[mpiexec#masterpi] HYDT_dmxu_poll_wait_for_event (./tools/demux/demux_poll.c:77): callback returned error status
[mpiexec#masterpi] HYD_pmci_wait_for_completion (./pm/pmiserv/pmiserv_pmci.c:197): error waiting for event
[mpiexec#masterpi] main (./ui/mpich/mpiexec.c:331): process manager error waiting for completion
I want just to make a checkpoint and nothing else (and restart later).
Thanks in advance
UPDATE:
I have tried with MPICH2, no chance. Or maybe I'm wrong somewhere...
pi#raspberrypi ~ $ mpiexec -n 1 -ckpointlib blcr -ckpoint-prefix /tmp/ -ckpoint-interval 2 ./test3
Count to: 0
[proxy:0:0#raspberrypi] requesting checkpoint
[proxy:0:0#raspberrypi] checkpoint completed
Count to: 1
[proxy:0:0#raspberrypi] requesting checkpoint
[proxy:0:0#raspberrypi] HYDT_ckpoint_checkpoint (/tmp/mpich/mpich2-1.5/src/pm/hydra/tools/ckpoint/ckpoint.c:111): Previous checkpoint has not completed.[proxy:0:0#raspberrypi] HYD_pmcd_pmip_control_cmd_cb (/tmp/mpich/mpich2-1.5/src/pm/hydra/pm/pmiserv/pmip_cb.c:902): checkpoint suspend failed
[proxy:0:0#raspberrypi] HYDT_dmxu_poll_wait_for_event (/tmp/mpich/mpich2-1.5/src/pm/hydra/tools/demux/demux_poll.c:77): callback returned error status
[proxy:0:0#raspberrypi] main (/tmp/mpich/mpich2-1.5/src/pm/hydra/pm/pmiserv/pmip.c:210): demux engine error waiting for event
[mpiexec#raspberrypi] control_cb (/tmp/mpich/mpich2-1.5/src/pm/hydra/pm/pmiserv/pmiserv_cb.c:201): assert (!closed) failed
[mpiexec#raspberrypi] HYDT_dmxu_poll_wait_for_event (/tmp/mpich/mpich2-1.5/src/pm/hydra/tools/demux/demux_poll.c:77): callback returned error status
[mpiexec#raspberrypi] HYD_pmci_wait_for_completion (/tmp/mpich/mpich2-1.5/src/pm/hydra/pm/pmiserv/pmiserv_pmci.c:196): error waiting for event
[mpiexec#raspberrypi] main (/tmp/mpich/mpich2-1.5/src/pm/hydra/ui/mpich/mpiexec.c:325): process manager error waiting for completion
Test3-Code:
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <mpi.h>
int main(int argc, char* argv[]) {
int rank;
int size;
int i = 0;
MPI_Init(&argc, &argv);
MPI_Comm_rank(MPI_COMM_WORLD, &rank);
MPI_Comm_size(MPI_COMM_WORLD, &size);
MPI_Status status;
if (rank == 0) {
for(i; i <=100; i++){
int j = 0;
while(j < 100000000){
j++;
}
printf("Count to: %i\n", i);
}
} else {
}
MPI_Finalize();
return 0;
}
I just need to have one successful checkpoint and to show the restart.
If someone has a working example (irrelevant what it makes, simple working "Hello World" would make me happy!) I would be very glad.
Happy new year!
Unfortunately, the checkpoint/restart code in MPICH 3.0.4 is known to be buggy at the moment. That will hopefully get fixed in a future release. It looks like you're probably using it correctly. It's possible that if you go back to a previous version, you might have better luck.
Here the problem was with the too small interval for checkpointing.
Setting it to 20s or more has solved this (but not the other :( ) problem.

Emacs embedded in a Qt Application

I've tried to embed emacs in a Qt Application using QX11EmbedContainer, and works but with two important exception. First of all, here is the code:
#include <QX11EmbedWidget>
#include <QtGui>
#include <QApplication>
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
QX11EmbedContainer container;
container.show();
container.resize(500, 500);
QProcess* process = new QProcess(&container);
QString executable("emacsclient");
QStringList arguments;
arguments << "--parent-id" << QString::number(container.winId());
process->start(executable, arguments);
int status = app.exec();
process->close();
return status;
}
And the compilation and execution line (and the previous thrown of the emacs server):
$ emacs -q --daemon &
// filtered output
$ g++ test.cpp -lQtGui -lQtCore -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4
$ ./a.out
And finally, the result:
But, when or if I try to write something in the minibuffer, the size of the widget is collapsed, and the focus is also lost:
If I make click in the (now shorter) widget, I can continue working with emacs without problems, but I should resize the window in order to emacs is expanded other time as originally.
Where is the problem?
Try using a layout.
Here is the Qt5 documentation on layout management.

QProcess::readAllStandardOutput gives flaky outputs

I am trying to create a GUI in Qt4 for my tcl based tool. In order to populate widgets I need to execute some tcl commands. I read about QProcess and I am invoking tcl scripts using QProcess and then grabbing their output from stdout.
Suppose I execute 3 commands in tcl then when I query stdout I believe I should see 3 outputs corresponding to each of the three commands, however this is not happening consistently. Behavior is flaky.
As you can see in the main.cpp I am executing multiple commands using runTclCommand() function and in the end executing getData() function to read stdout.
main.cpp:
#include <QApplication>
#include <QProcess>
#include <QDebug>
#include "Tclsh.h"
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
QByteArray out;
Tclsh *tcl = new Tclsh;
tcl->startTclsh();
tcl->runTclCommand("set ::tcl_interactive 1\n");
tcl->runTclCommand("set a 23\n");
tcl->runTclCommand("puts $a\n");
tcl->runTclCommand("set a 40\n");
tcl->runTclCommand("puts $a\n");
// out = idl->getData();
out = tcl->getData();
}
Tclsh.cpp:
#include <QProcessEnvironment>
#include <QProcess>
#include <QDebug>
#include "Tclsh.h"
void Tclsh::startTclsh() {
QString program = "/usr/bin/tclsh8.4";
this->setProcessChannelMode(QProcess::MergedChannels);
this->start(program);
if ( !this->waitForStarted()) {
qDebug()<<"ERROR Starting tclsh";
}
return;
}
void Tclsh::runTclCommand(const char *cmd) {
qDebug()<<"CMD:"<<cmd;
this->write(cmd);
if (!this->waitForBytesWritten()) {
qDebug()<<"Error in writing data";
}
}
QByteArray Tclsh::getData() {
if (!this->waitForReadyRead()) {
qDebug()<<"Error in reading stdout: Ready read signal is not emitted";
}
QByteArray data = this->readAllStandardOutput();
qDebug()<<"DATA:"<<data;
return data;
}
However, sometime I get the following output:
CMD: set ::tcl_interactive 1
CMD: set a 23
CMD: puts $a
CMD: set a 40
CMD: puts $a
DATA: "1
% 23
% 23
% "
And sometimes this:
CMD: set ::tcl_interactive 1
CMD: set a 23
CMD: puts $a
CMD: set a 40
CMD: puts $a
DATA: "1
"
I do not understand why this is happening. I would really appreciate if someone can point me to the error in my approach here.
Thanks,
Newbie
Edit: After some more research, here are my thoughts
According to Qt manual, readyRead signal will be emitted whenever new data is available (as specified by #Frank Osterfeld also, thanks!). It will not wait for complete output data to be available (which is justified since it does not know when will that happen). Hence my approach is not good. What I can do is something like this:
start the process -> wait for process to finish -> read stdout
This will ensure that flaky behavior does not arise as process is already finished when I am reading hence no new data can come.
However, in this proposed approach I am not clear about one thing: Does stdout is specific to a process? I mean can it happen that process which was supposed to read stdout output from process1, can get other stdout data from some other process which happen to write stdout at the same time as process1?
Thanks,
Newbie
I am closing this question. Reading from a channel more than once does not seem to a be a good idea. Instead what I do now is write what I want to write in one go --> close the channel for writing --> then read it back. In that way I get consistent output.

How does a zombie process manifest itself?

kill -s SIGCHLD
The above is the code for killing any zombie process, But my question is:
Is there any way by which a Zombie process manifest itself??
steenhulthin is correct, but until it's moved someone may as well answer it here. A zombie process exists between the time that a child process terminates and the time that the parent calls one of the wait() functions to get its exit status.
A simple example:
/* Simple example that creates a zombie process. */
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
int main(void)
{
pid_t cpid;
char s[4];
int status;
cpid = fork();
if (cpid == -1) {
puts("Whoops, no child process, bye.");
return 1;
}
if (cpid == 0) {
puts("Child process says 'goodbye cruel world.'");
return 0;
}
puts("Parent process now cruelly lets its child exist as\n"
"a zombie until the user presses enter.\n"
"Run 'ps aux | grep mkzombie' in another window to\n"
"see the zombie.");
fgets(s, sizeof(s), stdin);
wait(&status);
return 0;
}

Resources