Thiago, many thanks for your time. :)
UPD: Now, we will continue discussion about QtSerialPort in google groups:
https://groups.google.com/forum/#!forum/qtserialport
Please, who has any ideas and questions, you can join there.
BR,
Denis
2014-04-29 19:19 GMT+04:00 Thiago Macieira
Em qua 30 abr 2014, às 12:32:42, Denis Shienkov escreveu:
Thiago, many thanks for your time. :)
UPD: Now, we will continue discussion about QtSerialPort in google groups:
https://groups.google.com/forum/#!forum/qtserialport
Please, who has any ideas and questions, you can join there.
Hi Thiago,
No, it isn't. The socket notifier activates when there's buffer available
in the
kernel, not that the buffer is empty. That means something got flushed,
but it
does not indicate that everything did.
I will ask very specifically: what ioctl or fcntl do you need to enable to
get
the
conversion and garbage collection. Or just another tooling
nightmare?
Nils
--
Message: 6
Date: Mon, 28 Apr 2014 11:16:27 +0200
From: Oswald Buddenhagen oswald.buddenha...@digia.com
Subject: Re: [Development] [QIODevice]How to correctly
treat/understand
Em ter 29 abr 2014, às 12:48:55, Denis Shienkov escreveu:
This is expected behavior?
Yes. Except that you're referring to non-existent unbuffered modes of
QTcpSocket and QProcess...
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
2014-04-29 19:13 GMT+04:00 Denis Shienkov denis.shien...@gmail.com:
Yes. Except that you're referring to non-existent unbuffered modes of
QTcpSocket and QProcess...
Ok, then what is it This code is for the new Unbuffered QTcpSocket use
case?
Em ter 29 abr 2014, às 19:16:51, Denis Shienkov escreveu:
Yes. Except that you're referring to non-existent unbuffered modes of
QTcpSocket and QProcess...
Ok, then what is it This code is for the new Unbuffered QTcpSocket use
case?
On Sun, Apr 27, 2014 at 01:34:52PM -0700, Thiago Macieira wrote:
Em dom 27 abr 2014, às 11:08:44, Denis Shienkov escreveu:
Here I am a little disagree. Because in Unbuffered mode, loss of data is
exists. For example, in a case when the port accepts a data stream. And
when the user ignores
Hi Oswald,
a separate signal would be redundant, as checking byteToWrite() == 0 in
the slot called from bytesWritten() is sufficient.
Can you, please, more explain of your idea?
BR,
Denis
2014-04-28 13:16 GMT+04:00 Oswald Buddenhagen oswald.buddenha...@digia.com
:
On Sun, Apr 27, 2014
Em seg 28 abr 2014, às 11:16:27, Oswald Buddenhagen escreveu:
On Sun, Apr 27, 2014 at 01:34:52PM -0700, Thiago Macieira wrote:
yeah, but serial ports can be operated without flow control. if the
kernel does not buffer indefinitely (which seems plausible, as otherwise
one could DoS it), data
Em seg 28 abr 2014, às 17:04:31, Denis Shienkov escreveu:
Hi Thiago,
By the way, what is that tx-empty event?
E.g., it is an signal of QSocketNotifier::activated(fd) for the Write type
of notifier.
No, it isn't. The socket notifier activates when there's buffer available in
the
kernel,
Hi Carlos.
Look at the read/write calls in Unix. If you use the asynchronous
mode of operation you will get an error if the data cannot be
read/written. No data is lost, unless you explicitly delete the data you
pass to those functions. And from your point of view there is no way to
tell if
Em dom 27 abr 2014, às 11:08:44, Denis Shienkov escreveu:
Here I am a little disagree. Because in Unbuffered mode, loss of data is
exists. For example, in a case when the port accepts a data stream. And
when the user ignores readyRead() signal, i.e do not reads nothing from
port. In this case
On Apr 22, 2014, at 12:10 PM, Thiago Macieira thiago.macie...@intel.com wrote:
Em ter 22 abr 2014, às 19:34:48, Denis Shienkov escreveu:
1. or keep it as is, but then bytesWritten() will be tell lies
It's not lying. It's telling the user that the bytes were written from the
QIODevice to
Hi Kuba,
The `QSerialPort` API must be nonblocking,
It is truth, currently it is non-blocking.
The writes should be executed right away if they won’t block. The
semantics would be:
There are some problems, please see below:
1. Check how many bytes can be written to the OS device buffers
Hi Thiago, Kuba,
It should support the same waitForBytesWritten() and waitForReadyRead()
that
QAbstractSocket and QProcess have. Those are blocking.
Yes, QSerialPort does it (at least tries to do). :)
Let's make sure we distinguish blocking from buffered. It's quite ok for
QSerialPort to be
Em ter 22 abr 2014, às 12:28:39, Denis Shienkov escreveu:
If to be honest, I don't agree with implementation with emission of the
bytesWritten() signal in QAbstractSocket. IMHO, this signal has to be
emitted when data were really transferred, i.e. after completion of
transfer, when fired the
Hi Thiago,
That's simply not workable.
If the buffer never empties, bytesWritten() would never fire. Imagine the
user
is always writing data at the same speed as the device is transmitting (or
faster).
Hmm.. Yes. But this scenario it is possible in case of continuous flushing
(or, maybe
Em ter 22 abr 2014, às 19:34:48, Denis Shienkov escreveu:
1. or keep it as is, but then bytesWritten() will be tell lies
It's not lying. It's telling the user that the bytes were written from the
QIODevice to the underlying device. That's the best we can do, since now those
bytes are no longer
Hi Thiago, Kuba,
It should support the same waitForBytesWritten() and waitForReadyRead() that
QAbstractSocket and QProcess have. Those are blocking.
Yes, QSerialPort does it (at least tries to do). :)
Let's make sure we distinguish blocking from buffered. It's quite ok for
QSerialPort to
Em ter 22 abr 2014, às 11:13:00, Carlos Duclos escreveu:
PS1 Where could I take a look at your code?
QtSerialPort is part of Qt since 5.2.
https://qt.gitorious.org/qt/qtserialport
http://code.woboq.org/qt5/qtserialport/
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect
Hmmm..
Thiago, what do you mean by writeable? It is when device was opened in
the WriteOnly (ReadWrite) mode, or something else?
If I correctly understand, then I assume that the device always is
writeable: i.e. opened in WriteOnly (ReadWrite) and the internal buffer
of writing is not empty.
Em seg 21 abr 2014, às 16:50:50, Denis Shienkov escreveu:
Hmmm..
Thiago, what do you mean by writeable? It is when device was opened in
the WriteOnly (ReadWrite) mode, or something else?
When the underlying device can receive more bytes from the userspace.
Sockets and pipes are buffered in
Essentially, there’s only *two* changes I’d like to see in QSerialPort’s
implementation. These changes may not be possible to implement on all
platforms, of course. The `QSerialPort` API must be nonblocking, that’s the
whole point of having it to start with. Doing blocking reads/writes is
Em seg 21 abr 2014, às 14:21:24, Kuba Ober escreveu:
Essentially, there’s only *two* changes I’d like to see in QSerialPort’s
implementation. These changes may not be possible to implement on all
platforms, of course. The `QSerialPort` API must be nonblocking, that’s the
whole point of having
Thiago,
many thanks for your time and answers.
Forgive for my importunity, but I shall ask also about following:
== Second issue ==
What about two scenarios ? (e.g. for some abstract I/O device):
1) Without flush():
MyClass::foo()
{
dev.write('a');
dev.write('b');
}
MyClass::bar()
{
Em dom 20 abr 2014, às 22:13:47, Denis Shienkov escreveu:
== Second issue ==
What about two scenarios ? (e.g. for some abstract I/O device):
1) Without flush():
MyClass::foo()
{
dev.write('a');
dev.write('b');
}
MyClass::bar()
{
dev.write('c');
dev.write('d');
}
when, the
Hi Thiago,
many thanks for your answer..
== First issue ==
But still I didn't receive the concrete response: as to us to be? :)
In a buffer mode is to use the deferred writing or the immediately
writing?
This question causes many disputes in our QtSerialPort team ( even, up
to a fight :) ).
Hi Carlos,
Disclaimer. I don't work for Digia and I have never worked for Digia.
I did work for Trolltech and Nokia though.
Ahh, clear. Thx.
I think you are starting from the wrong end. The question is not if
you should support one mode of operation or the other, that needs to be
Em sáb 19 abr 2014, às 10:42:27, Denis Shienkov escreveu:
But still I didn't receive the concrete response: as to us to be?
In a buffer mode is to use the deferred writing or the immediately
writing?
You choose.
If you choose to write immediately in writeData(), justify.
Otherwise, follow
Hi.
My question most likely belongs to the Qt developers from Digia. For
example to maintainers of a network subsystem.
I see that in QAbstractSocket::write() in a buffered mode is used the
deferred data transmission:
Hi.
I once again fluently look source codes of Qt and I see that the only one
I/O class which supports a buffered mode is QTcpSocket (i.e.
QAbstractSocket in buffered mode); in which is used the deferred writing
for data transfer.
Thus, whether can I take such behavior (with deferred writing) as
Em sex 18 abr 2014, às 18:14:43, Denis Shienkov escreveu:
Hi.
I once again fluently look source codes of Qt and I see that the only one
I/O class which supports a buffered mode is QTcpSocket (i.e.
QAbstractSocket in buffered mode); in which is used the deferred writing
for data transfer.
Em sex 18 abr 2014, às 14:32:49, Denis Shienkov escreveu:
My question most likely belongs to the Qt developers from Digia. For
example to maintainers of a network subsystem.
Note: none of the 3 network maintainers work for Digia.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software
Hi.
Hi again,
Disclaimer. I don't work for Digia and I have never worked for Digia. I did
work for Trolltech and Nokia though.
I once again fluently look source codes of Qt and I see that the only one
I/O class which supports a buffered mode is QTcpSocket (i.e.
QAbstractSocket in buffered
Hi,
I'm not sure I understand your question so I'll reply according to what I
understood.
QIODevice is a generic interface and as such has to provide an interface that
works well with different ways of doing things. What seems to confuse you is
the possibility of doing buffered communications
36 matches
Mail list logo
