[Development] [QIODevice]How to correctly treat/understand of the documentation?
Denis Shienkov
denis.shienkov at gmail.com
Tue Apr 29 10:48:55 CEST 2014
>That is why I suggest that when in Unbuffered mode, write/read should
behave as their Unix counterparts in non blocking mode. If the data cannot
be written at once, then refuse to write it (or to read it).
So, means it is possible to divide on main moments for possible I/O
implementation for the serial port (the own requirements/specification of
I/O behavior):
1) Buffered mode
- reading and writing is carried out via the internal buffer of class
- data transmission should be "postponed" and is carried out only on events
from a notifier (when the FIFO of driver/device is ready for I/O
operation). Similar with the current buffered QTcpSocket implementation...
- bytesWritten() signal has to be emitted after an data transmission from
the user space to kernel space (i.e. after a successful write(),
WriteFile() syscall's). Similar with the any Unix implementation of
QTcpSocket, QProcess...
- data reading is carried out automatically when FIFO is ready for reading
(by event from the read notifier). A data from the FIFO will be read into a
internal read buffer of class. Similar with the current buffered QTcpSocket
implementation...
- the readyRead() signal should be emitted after successfully automatically
reading from the FIFO into internal buffer of class.
2) Unbuffered mode
- reading and writing is carried out directly to the device, by avoiding of
the internal buffer of class
- data transmission should be "directly" by means of calling the ::write(),
::WriteFile() syscalls. Similar with the current unbuffered QTcpSocket
implementation...
- bytesWritten() signal has to be emitted after an data transmission from
the user space to kernel space (i.e. after a successful write(),
WriteFile() syscall's). Similar with the any Unix implementation of
QTcpSocket, QProcess...
- data reading is carried out manually by user, when the FIFO is ready for
reading (by the readyRead() signal or something else), by means of calling
of the ::read(), ::ReadFile() syscalls. Similar with the current unbuffered
QTcpSocket implementation...
- the readyRead() signal should be emitted when the FIFO is ready to read.
This is expected behavior?
PS: I.e. we need to implement the general final option of use case, to
adhere to the concrete course. :)
BR,
Denis
2014-04-28 13:53 GMT+04:00 Carlos Duclos <carlosduclosv at yahoo.com>:
>
> >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 readyRead() signal, i.e do not reads nothing
> from
> >> > port. In this case FIFO of device/driver will be overflowed, that will
> >> > cause overrun/overflow errors, and part of stream will be lost.
> >>
> >> Doesn't happen with pipes, sockets and other devices with flow control.
> >>
> >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 could be discarded indeed.
>
> That is why I suggest that when in Unbuffered mode, write/read should
> behave as their Unix counterparts in non blocking mode. If the data cannot
> be written at once, then refuse to write it (or to read it).
>
> Discarding data is more or less always a possibility, unless it is stopped
> by the device itself by using flow control. The moment flow control is
> disabled, buffering data will protect it for a little while until the
> buffer is full. If nobody empties the buffer, then the data will be
> discarded at some point (or the app will be killed by the OOM). And even
> using flow control, if the flow control is automatic and the data is copied
> by QtSerialPort to its own buffer, there is risk of filling that buffer if
> the buffer is not emptied. At some point a line needs to be drawn, it is
> impossible to prevent misuse in all cases. If the user of QtSerialPort
> never empties the buffers by reading from them or the buffer cannot be
> emptied because the device is never ready for writing, then we need to
> signal the error and let the user take the corrective action.
>
> >> > As I wrote above, the only Windows has an "true" async I/O. The Unix
> has
> >> > not this feature, he has only "non-blocking" approach, but it is not
> an
> >> > "async" I/O. So, implementation of completion of I/O operation is
> >> > problematic on any Unix's. We only can judge about operation
> completion
> >> > indirectly, e.g. for writing - wait for the Tx-empty event.
> >>
> >> By the way, what is that tx-empty event? 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 indicate this, but bytesWritten()
> must mean
> >> the same as QTcpSocket and QProcess.
> >>
> >a separate signal would be redundant, as checking byteToWrite() == 0 in
> >the slot called from bytesWritten() is sufficient.
>
> That seems indeed a good option. Although, it is device independent to
> emit a signal (SIGIO|POLLOUT) if the data was written. We might not be able
> to find out if the data was written by the device or if it is being held in
> some internal buffer on the driver.
>
> El Lunes, 28 de abril, 2014 11:32 A.M., "
> development-request at qt-project.org" <development-request at qt-project.org>
> escribió:
> Send Development mailing list submissions to
> development at qt-project.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.qt-project.org/mailman/listinfo/development
> or, via email, send a message with subject or body 'help' to
> development-request at qt-project.org
>
> You can reach the person managing the list at
> development-owner at qt-project.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Development digest..."
>
>
> Today's Topics:
>
> 1. Re: Updating JIRA components relating to events. (Paul Olav Tvete)
> 2. Re: Question about Qt's future (Hartmann Thomas)
> 3. Re: Updating JIRA components relating to events.
> (Blasche Alexander)
> 4. Re: Updating JIRA components relating to events. (Paul Olav Tvete)
> 5. Re: Question about Qt's future (Nils Jeisecke)
> 6. Re: [QIODevice]How to correctly treat/understand of the
> documentation? (Oswald Buddenhagen)
> 7. Re: Question about Qt's future (Hartmann Thomas)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 28 Apr 2014 10:19:50 +0200
> From: Paul Olav Tvete <paul.tvete at digia.com>
> Subject: Re: [Development] Updating JIRA components relating to
> events.
> To: <development at qt-project.org>
> Message-ID: <1450848.oMjyDEmEbG at neverwhere>
> Content-Type: text/plain; charset="us-ascii"
>
> On Friday 25 April 2014 17:27:23 Thiago Macieira wrote:
> > I've just noticed that the "GUI: Input methods" component in JIRA has got
> > an update now saying "(Non-Latin languages)". That is, it seems the
> > purpose of that component has changed to mean complex input methods only.
> >
> > I've been reassigning to that component anything that is related to
> *any*
> > input method, especially mouse, keyboard and touch, which bug reporters
> > often submit to "Core: Event System".
> >
> > Can I ask that we create a "GUI: Basic Input Method (keyboard, mouse,
> > touch)" component? Does anyone feel like being the default assignee?
> > Please reply in QTJIRA-258.
>
> As I commented in the task, I would like to request a reversal of the "Non-
> Latin languages" renaming. On Android, we use exactly the same
> infrastructure
> for input of Latin-based languages. (Also, there are several non-Latin
> scripts
> that can use simple keyboard input on a desktop computer.) If we have to
> rename, I support Thiago's suggestion of "Complex input methods", possibly
> with a "text" or "language" thrown in.
>
> [Apology in advance for small rant.]
>
> In the future, could we please not rename components silently without
> warning?
> This renaming effectively edited several of my tasks, making them
> misleading.
> As a bonus it also messed up my filters.
>
> - Paul
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 28 Apr 2014 08:29:24 +0000
> From: Hartmann Thomas <Thomas.Hartmann at digia.com>
> Subject: Re: [Development] Question about Qt's future
> To: Thiago Macieira <thiago.macieira at intel.com>,
> "development at qt-project.org" <development at qt-project.org>
> Message-ID:
> <1380CEABC81B604BBD1CBDE7C61F9401CF0A05 at IT-EXMB01-HKI.it.local>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> while (at least for me) it is not really clear where exactly the boundary
> between declarative and functional programming lies, we could/should at
> least rule out control flow statements and anything with side effects in
> bindings.
>
> The statement "width: Math.floor(height)" could be considered declarative
> (enough), if we limit the allowed functions to a well defined subset.
>
> But currentlty one can do this: width: { Any imperative code one can
> imagine, including loops, while(true) and side effects. } This clearly is
> not declarative anymore.
>
> Another issue with QML is that some parts of the API of Qt Quick are not
> accessible through a declarative API (e.g. setting a state). While this is
> not a problem in principle (since we could extend the API), it is a problem
> in practice.
> Until now nobody (including me) found the time to fix it.
>
> >From my point of view many of these problems are caused by the fact that
> Qt Quick allows very fast prototyping
> (And Qt Quick is an excellent UI prototyping tool.), but is also used in
> real production code.
> While certain features (Like inlining .js code everywhere all over the
> place and no clear split between declarative UI and logic) are nice for
> protoyping, they can become a burden in larger production code.
>
> To give a concrete example: While things like width:
> Math.max(someId.width, someOtherId.width) + magicNumber
> are nice to achieve certain complex layouts and to circumvent limitations
> of the "declarative layout system", they create a huge maintenance burden,
> because this kind of code is hard to read and does not play nice with
> tooling.
>
> The only solution I see is to create a well defined QML/QtQuick (sub)set
> that is more suitable for production code/larger projects. Such QML would
> be more rigid, enforce more structure on the developer and would be as
> declarative as possible.
> Such a QML "dialect" could forbid any inline js code. All Java Script
> could would be part of .js files.
>
> Another idea is to allow C++ companion objects, that would take the place
> of any Java Script code for people who prefer C++. A companion object would
> be a QObject paired with the QML object, that has access to the QML
> context. The QObject would then define a couple of signals/slots that can
> be used from QML as Java Script is used today.
>
> Kind Regards,
> Thomas Hartmann
> ________________________________________
> From: development-bounces+thomas.hartmann=digia.com at qt-project.org[development-bounces+thomas.hartmann=
> digia.com at qt-project.org] on behalf of Thiago Macieira [
> thiago.macieira at intel.com]
> Sent: 28 April 2014 02:34
> To: development at qt-project.org
> Subject: Re: [Development] Question about Qt's future
>
> Em seg 28 abr 2014, ?s 00:55:12, Andr? P?nitz escreveu:
> > On Sun, Apr 27, 2014 at 01:37:33PM -0700, Thiago Macieira wrote:
> > > Em dom 27 abr 2014, ?s 12:55:58, Peter K?mmel escreveu:
> > > > Having imperative code on the JS side is also the root of the
> rejection
> > > > of
> > > > QML for many C++ developers. If QML would have been just a improved
> .ui
> > > > nobody would have complained.
> > >
> > > We'd end up with one of the problems of CSS which is that you can't do
> > > calculations in the bindings. I can't do
> > >
> > > width: 50% - 10em
> > >
> > > The moment you start adding some math, you need stuff like
> Math.random()
> > > and you end up again in JS.
> >
> > Not true. Some (basic) math fits the "declarative" needs, and would
> > be toolable. Math.random() does obviously not fit the bill.
>
> Math.floor() then.
>
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 28 Apr 2014 08:42:48 +0000
> From: Blasche Alexander <Alexander.Blasche at digia.com>
> Subject: Re: [Development] Updating JIRA components relating to
> events.
> To: "development at qt-project.org" <development at qt-project.org>
> Message-ID:
> <D0AE864289F56A48A1B9DA6FA7E3239AEAE6DF at IT-EXMB01-HKI.it.local>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi,
>
> I renamed it on request. It was such a minor change that I didn't see an
> issue especially since the component doesn't have a default assignee.
> Obviously that is not the case.
>
> Paul, you have to rename your filter again. Filtering on the name string
> is rather stupid but that's what jira does. It should really filter on
> component ID which does internally exist. Not Paul's fault though but I
> need to remember this.
>
> On Friday 25 April 2014 17:27:23 Thiago Macieira wrote:
> > I've been reassigning to that component anything that is related to *any*
> > input method, especially mouse, keyboard and touch, which bug reporters
> > often submit to "Core: Event System".
>
> I hope you reassigned it to another person? Otherwise they just end up in
> a virtual dead end considering that their is no ownership in the component.
>
> I changed it back for now. Before we create any new components I would
> like to see some ownership. Otherwise this is just an exercise in moving
> from one bucket to the next without any purpose.
>
> --
> Alex
>
> ________________________________________
> From: development-bounces+alexander.blasche=digia.com at qt-project.org[development-bounces+alexander.blasche=
> digia.com at qt-project.org] on behalf of Paul Olav Tvete [
> paul.tvete at digia.com]
> Sent: Monday, April 28, 2014 10:19
> To: development at qt-project.org
> Subject: Re: [Development] Updating JIRA components relating to events.
>
> On Friday 25 April 2014 17:27:23 Thiago Macieira wrote:
> > I've just noticed that the "GUI: Input methods" component in JIRA has got
> > an update now saying "(Non-Latin languages)". That is, it seems the
> > purpose of that component has changed to mean complex input methods only.
> >
> > I've been reassigning to that component anything that is related to *any*
> > input method, especially mouse, keyboard and touch, which bug reporters
> > often submit to "Core: Event System".
> >
> > Can I ask that we create a "GUI: Basic Input Method (keyboard, mouse,
> > touch)" component? Does anyone feel like being the default assignee?
> > Please reply in QTJIRA-258.
>
> As I commented in the task, I would like to request a reversal of the "Non-
> Latin languages" renaming. On Android, we use exactly the same
> infrastructure
> for input of Latin-based languages. (Also, there are several non-Latin
> scripts
> that can use simple keyboard input on a desktop computer.) If we have to
> rename, I support Thiago's suggestion of "Complex input methods", possibly
> with a "text" or "language" thrown in.
>
> [Apology in advance for small rant.]
>
> In the future, could we please not rename components silently without
> warning?
> This renaming effectively edited several of my tasks, making them
> misleading.
> As a bonus it also messed up my filters.
>
> - Paul
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 28 Apr 2014 10:59:29 +0200
> From: Paul Olav Tvete <paul.tvete at digia.com>
> Subject: Re: [Development] Updating JIRA components relating to
> events.
> To: <development at qt-project.org>
> Message-ID: <2441161.FSKxQZWCL6 at neverwhere>
> Content-Type: text/plain; charset="us-ascii"
>
> On Monday 28 April 2014 08:42:48 Blasche Alexander wrote:
> > I renamed it on request. It was such a minor change that I didn't see an
> > issue especially since the component doesn't have a default assignee.
> > Obviously that is not the case.
>
> No worries :) I may be using the components in a slightly non-standard
> fashion, but I do like to add additional components to tasks, instead of
> using
> one component and several labels. In this case, I used the combination of
> "QtPorts: Android" and input methods to track the input method issues on
> Android.
>
> - Paul
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 28 Apr 2014 11:00:31 +0200
> From: Nils Jeisecke <njeisecke at saltation.de>
> Subject: Re: [Development] Question about Qt's future
> To: Hartmann Thomas <Thomas.Hartmann at digia.com>
> Cc: "development at qt-project.org" <development at qt-project.org>
> Message-ID:
> <CANh_-9dOkhoHLK9AkYDO4ga1Py95Vx5h3=C-7sdKANtzM7rjoA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> > Another idea is to allow C++ companion objects, that would
> > take the place of any Java Script code for people who
> > prefer C++. A companion object would be a QObject
> > paired with the QML object, that has access to the
> > QML context. The QObject would then define a couple
> > of signals/slots that can be used from QML as
> > Java Script is used today.
> I really like this idea. Maybe one could even write C++ code
> directly in the QML file and let a preprocessor generate
> a proper C++ class containing this code. So, no more JavaScript,
> data 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.buddenhagen at digia.com>
>
> Subject: Re: [Development] [QIODevice]How to correctly
> treat/understand of the documentation?
> To: <development at qt-project.org>
> Message-ID: <20140428091627.GA5431 at troll08.it.local>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> 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 readyRead() signal, i.e do not reads nothing from
> > > port. In this case FIFO of device/driver will be overflowed, that will
> > > cause overrun/overflow errors, and part of stream will be lost.
> >
> > Doesn't happen with pipes, sockets and other devices with flow control.
> >
> 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 could be discarded indeed.
>
> > > As I wrote above, the only Windows has an "true" async I/O. The Unix
> has
> > > not this feature, he has only "non-blocking" approach, but it is not an
> > > "async" I/O. So, implementation of completion of I/O operation is
> > > problematic on any Unix's. We only can judge about operation
> completion
> > > indirectly, e.g. for writing - wait for the Tx-empty event.
> >
> > By the way, what is that tx-empty event? 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 indicate this, but bytesWritten() must
> mean
> > the same as QTcpSocket and QProcess.
> >
> a separate signal would be redundant, as checking byteToWrite() == 0 in
> the slot called from bytesWritten() is sufficient.
>
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 28 Apr 2014 09:32:12 +0000
> From: Hartmann Thomas <Thomas.Hartmann at digia.com>
> Subject: Re: [Development] Question about Qt's future
> To: Nils Jeisecke <njeisecke at saltation.de>
> Cc: "development at qt-project.org" <development at qt-project.org>
> Message-ID:
> <1380CEABC81B604BBD1CBDE7C61F9401CF125A at IT-EXMB01-HKI.it.local>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi,
>
> yes, writting C++ inline in QML would be another "tooling nightmare". Also
> what is the problem with:
>
> MouseArea {
> onClicked: companion.mouseAreaClicked();
> }
>
> If tooling creates the companion object for you (In a wizard) and code
> completion and code naviagtion (F2) works as expected?
>
>
> Kind Regards,
> Thomas Hartmann
>
>
> ________________________________________
> From: Nils Jeisecke [njeisecke at saltation.de]
> Sent: 28 April 2014 11:00
> To: Hartmann Thomas
> Cc: development at qt-project.org
> Subject: Re: [Development] Question about Qt's future
>
> Hi,
>
> > Another idea is to allow C++ companion objects, that would
> > take the place of any Java Script code for people who
> > prefer C++. A companion object would be a QObject
> > paired with the QML object, that has access to the
> > QML context. The QObject would then define a couple
> > of signals/slots that can be used from QML as
> > Java Script is used today.
> I really like this idea. Maybe one could even write C++ code
> directly in the QML file and let a preprocessor generate
> a proper C++ class containing this code. So, no more JavaScript,
> data conversion and garbage collection. Or just another tooling
> nightmare?
>
> Nils
>
>
> ------------------------------
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
> End of Development Digest, Vol 31, Issue 91
> *******************************************
>
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140429/6361c6ed/attachment.html>
More information about the Development
mailing list