hi, everybody,
Again I want to continue discussion of previous thread:
http://lists.qt-project.org/pipermail/development/2014-April/016780.html
I will remind that earlier I made an summary of the general moments of
behavior at I/O implementation that should be in ideally (yes?):
1) Buffered mod
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 ther
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 ter
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"?
> >
> >
> > https://qt.gitorious.org/q
2014-04-29 19:13 GMT+04:00 Denis Shienkov :
> > 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"?
>
>
> https://qt.gitorious.org/qt/qtbase/source/eb211d74cc3dbf99
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
te
> Subject: Re: [Development] Updating JIRA components relating to
> events.
> To:
> Message-ID: <2441161.FSKxQZWCL6@neverwhere>
> Content-Type: text/plain; charset="us-ascii"
>
> On Monday 28 April 2014 08:42:48 Blasche Alexander wrote:
> > I rename
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
>th
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
k
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), d
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
:
> On Sun, Apr 27, 2014 at 01:34:52PM -0700, Thiago
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.
> Note that sockets and pipes don't
> have that, so please don't make QSerialPort use that by default. You can
add
> an extra signal to QSerialPort to ind
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 ign
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 ca
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
On Apr 22, 2014, at 12:10 PM, Thiago Macieira 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 the underlying devic
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
> 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
>>QSeri
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 long
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 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 th
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
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
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 havi
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 trivia
Thiago,
many thanks for your help.
BR,
Denis
21.04.2014 20:12, Thiago Macieira пишет:
> 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
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 buffere
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 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');
>
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()
{
dev.writ
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,
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
analyz
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.
>
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 buffere
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
Softwa
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 trans
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)
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:
https://qt.gitorious.org/qt/qtbase/source/454dc332b3856c1726683595575c3428
01.html
--
Message: 4
Date: Thu, 17 Apr 2014 14:23:09 +0200
From: Peter Hartmann
Subject: Re: [Development] Qt5.3 change files
To: Heikkinen Jani ,
"development@qt-project.org"
Message-ID: <534fc7ad.7070...@blackberry.com>
Content-Type:
Hi all.
I have the question concerning correct treatment of documentation and
implementation of I/O methods, e.g. for QtSerialPort.
== write ==
For example, regarding to the QIODevice::write() method. Investigating of
Qt5 source codes I see two approaches in classes derived from QIODevice (I
tal
40 matches
Mail list logo
