Re: [Development] Enhancement to QIODevice?

[André Somers]

Op 14-9-2015 om 12:25 schreef Andrzej Ostruszka:
> Hello all,
>
> I'd like to ask for possibility to enhance a bit QIODevice.
>
> My problem/wish is following.  I'm using QSerialPort and (as all
> QIODevice-s) it is tailored for reading in "lines" ('\n') which is fine
> since most of the time this is exactly what I need.  But I just happen
> to have to deal with an older lock-in device which communicates via
> messages terminated by '\r'.
>
> So what I'm aiming to is to make the "line" (or more generally "packet")
> termination a bit more flexible, that is to allow user to specify the
> delimiter.  Currently I think the only available solution for my wish is
> double buffering - that is to introduce my own buffer that will suck
> everything from QIODevice and allow searching for other delimiter but
> I'd like to do better than that.
>
>   From now on I'll talk about QIODevice only since QSerialPort is
> inheriting from it for the bulk of functionality (and this could also
> benefit QIODevice).
>
> Since '\n' is just hardcoded in QIODevice (actually in buffer used in
> its private part) one option would be to add it as last optional
> parameter to canReadLine() and readLine() with default value '\n'. What
> do you think?
>
> I'm afraid a bit that you might object here:
> - we don't want to change that low level functionality to just fit some
> very specific and rare case (true my example is rare - but I can find
> other aplications like e.g. reading pipe delimited values or other)
> - this would not be backward compatible (although I don't why)
> - being low level would "naturally" push this interface change to all
> classes that inherit from QIODevice and this would be significant change
> - in addition to changing code we would have to also change documentation
>
> So the other option that I'd like for you to consider is to enhance
> buffer used for reading in QIODevicePrivate.
>
> Minimal change that I could come up with is:
> --8<---
> diff --git i/src/corelib/io/qiodevice_p.h w/src/corelib/io/qiodevice_p.h
> index 56a89ab..090e551 100644
> --- i/src/corelib/io/qiodevice_p.h
> +++ w/src/corelib/io/qiodevice_p.h
> @@ -143,6 +143,10 @@ public:
>bool canReadLine() const {
>return memchr(first, '\n', len);
>}
> +qint64 countTo(char c) {
> +char* pos =  static_cast(memchr(first, c, len));
> +return pos ? 1+(pos-first) : 0;
> +}
>void ungetChar(char c) {
>if (first == buf) {
>// underflow, the existing valid data needs to move to the en
> --8<---
> countTo() returns number of bytes one would have to read() in order to
> have first delimiter copied to user data structures (that is it is
> inclusive) and if delimiter is not available than it returns 0.
>
> By using this I can then subclass QSerialPort and implement what I want
> without double buffering.  That way I can also avoid double searching
> for delimiter [1].
I guess that also means that your countTo() would need to be virtual, 
right? That would not be bc.

Would it not make sense to just add a non-virtual getter and a setter 
for the delimitation marker in the QIODevice API, instead of hard-coding 
'\n'? Obviously you would default that to '\n', but for your usecase you 
would then set it to '\r' and everything else remain as-is...

André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Enhancement to QIODevice?

[Florian Bruhin]

* Andrzej Ostruszka  [2015-09-14 12:25:20 +0200]:
>  From now on I'll talk about QIODevice only since QSerialPort is 
> inheriting from it for the bulk of functionality (and this could also 
> benefit QIODevice).
> 
> Since '\n' is just hardcoded in QIODevice (actually in buffer used in 
> its private part) one option would be to add it as last optional 
> parameter to canReadLine() and readLine() with default value '\n'. What 
> do you think?

As an electronics engineer using Qt, this would definitely make my
life easier sometimes.

I don't think this is about "protocols using weird line-endings" -
it's about the fact there are many sensible choices for low-level
protocols to signal frames, not only \n. As an example, I was dealing
with a protocol (via QSerialPort) which uses STX (start of text,
ASCII 0x02) as delimiter.

Florian

-- 
http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
 I love long mails! | http://email.is-not-s.ms/


pgpGaGeEpB6Fq.pgp
Description: PGP signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Enhancement to QIODevice?

[Oswald Buddenhagen]

On Mon, Sep 14, 2015 at 12:25:20PM +0200, Andrzej Ostruszka wrote:
> My problem/wish is following.  I'm using QSerialPort and (as all 
> QIODevice-s) it is tailored for reading in "lines" ('\n') which is fine 
> since most of the time this is exactly what I need.  But I just happen 
> to have to deal with an older lock-in device which communicates via 
> messages terminated by '\r'.
> 
just \r, without a subsequent \n? that's old-style mac. i'm not sure we
want to add complexity to support such legacy cases.

> So what I'm aiming to is to make the "line" (or more generally "packet") 
> termination a bit more flexible, that is to allow user to specify the 
> delimiter.
> 
i'd endorse making CRLF conversions available on linux as well, as the
current limitation to windows has bothered me more than once. i wouldn't
go further than that.

i expect opinions from thiago and alex t. :)

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Enhancement to QIODevice?

[Matthew Woehlke]

On 2015-09-14 06:25, Andrzej Ostruszka wrote:
> I'd like to ask for possibility to enhance a bit QIODevice.
> 
> My problem/wish is following.  I'm using QSerialPort and (as all 
> QIODevice-s) it is tailored for reading in "lines" ('\n') which is fine 
> since most of the time this is exactly what I need.  But I just happen 
> to have to deal with an older lock-in device which communicates via 
> messages terminated by '\r'.
> 
> So what I'm aiming to is to make the "line" (or more generally "packet") 
> termination a bit more flexible [...]

This sounds like an opportunity to discuss with the folks working on CAN
bus how to make QIODevice more generally friendly to protocols that
communicate with some form of "packet", for whatever that definition
happens to be. QUdpSocket could presumably benefit also.

-- 
Matthew

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Enhancement to QIODevice?

[Thiago Macieira]

On Monday 14 September 2015 12:25:20 Andrzej Ostruszka wrote:
> So what I'm aiming to is to make the "line" (or more generally "packet") 
> termination a bit more flexible, that is to allow user to specify the 
> delimiter.  Currently I think the only available solution for my wish is 
> double buffering - that is to introduce my own buffer that will suck 
> everything from QIODevice and allow searching for other delimiter but 
> I'd like to do better than that.

You could use peek() to search the buffer, then read() exactly as much as you 
really need.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.5.0 build issue on OS X (10.9): OpenGL libraries

[Thiago Macieira]

On Monday 14 September 2015 08:09:28 Sorvig Morten wrote:
> Then the question is: which ones should QtGui link against? On other words
> OpenGL usage is not confined to platform plugins only.
> 
> To me this points to Xcb or Cocoa being a configure-time choice.

Shouldn't the OpenGL functions be resolved dynamically by the platform plugin? 
QtGui should not link to the GL library. We had to implement that 
functionality for Windows, so that desktop GL and ANGLE could be selected at 
runtime.

This would also allow one QtGui to work with both desktop GL as well as GL ES 
in one build (though it could be disabled if one of the two can never happen).
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Is qt.io down?

[Kojo Tero]

Hi,

Yes, we experienced a major network problem in the night-early morning (CET).
Everything is back to normal now.

Best regards,
Tero

From: development-bounces+tero.kojo=theqtcompany@qt-project.org 
[mailto:development-bounces+tero.kojo=theqtcompany@qt-project.org] On 
Behalf Of Yang Fan
Sent: 14. syyskuuta 2015 5:09
To: Majid Qureshi 
Cc: Qt Development 
Subject: Re: [Development] Is qt.io down?

me three

On Mon, Sep 14, 2015 at 10:04 AM, Majid Qureshi 
> wrote:
me too

On Mon, Sep 14, 2015 at 11:59 AM, Jonathan Bagg 
> wrote:
Down for me to

On 15-09-13 09:29 PM, Christian Gagneraud wrote:
> Hi there,
>
> Is qt.io and all *.qt.io down for you or is it 
> just me?
>
> Krys.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



--


Majid

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



--
Regards,
Fan Yang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.5.0 build issue on OS X (10.9): OpenGL libraries

[Sorvig Morten]

> On 13 Sep 2015, at 00:55, Thiago Macieira  wrote:
> 
> On Saturday 12 September 2015 18:16:54 René J. V. Bertin wrote:
>> Thiago Macieira wrote:
>>> Maybe we need two tests: one for OpenGL for XCB plugin (with GLX support)
>>> and one for OpenGL for the Cocoa plugin (AGL support).
>> 
>> I think that's what you get when using my approach:
> 
> Not really. I guess I didn't express myself: I meant keep *both* tests, but 
> use two different variables for storing them: one for OpenGL-for-XCB and one 
> for OpenGL-for-Cocoa.
> 
> In any case, is there any Apple system that *lacks* the OpenGL libraries? Why 
> do we need to test for it? Let the configure script detect the XCB one with 
> pkg-config and let the Cocoa plugin use -framework OpenGL -framework AGL, 
> pure 
> and simple.

Then the question is: which ones should QtGui link against? On other words 
OpenGL usage is not confined to platform plugins only.

To me this points to Xcb or Cocoa being a configure-time choice.

Morten

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Winphone status

[Federico Buti]

Hi list.

We are interested in porting an app already published on the AppStore and
Google Play to WinPhone.

The app communicates with a custom Wi-Fi device and relies on networking
and bearer management. How's the status of QTBUG-43838
 and, generally speaking,
what's the plan for WinPhone?


Thanks in advance,
F.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Enhancement to QIODevice?

[Andrzej Ostruszka]

Hello all,

I'd like to ask for possibility to enhance a bit QIODevice.

My problem/wish is following.  I'm using QSerialPort and (as all 
QIODevice-s) it is tailored for reading in "lines" ('\n') which is fine 
since most of the time this is exactly what I need.  But I just happen 
to have to deal with an older lock-in device which communicates via 
messages terminated by '\r'.

So what I'm aiming to is to make the "line" (or more generally "packet") 
termination a bit more flexible, that is to allow user to specify the 
delimiter.  Currently I think the only available solution for my wish is 
double buffering - that is to introduce my own buffer that will suck 
everything from QIODevice and allow searching for other delimiter but 
I'd like to do better than that.

 From now on I'll talk about QIODevice only since QSerialPort is 
inheriting from it for the bulk of functionality (and this could also 
benefit QIODevice).

Since '\n' is just hardcoded in QIODevice (actually in buffer used in 
its private part) one option would be to add it as last optional 
parameter to canReadLine() and readLine() with default value '\n'. What 
do you think?

I'm afraid a bit that you might object here:
- we don't want to change that low level functionality to just fit some 
very specific and rare case (true my example is rare - but I can find 
other aplications like e.g. reading pipe delimited values or other)
- this would not be backward compatible (although I don't why)
- being low level would "naturally" push this interface change to all 
classes that inherit from QIODevice and this would be significant change
- in addition to changing code we would have to also change documentation

So the other option that I'd like for you to consider is to enhance 
buffer used for reading in QIODevicePrivate.

Minimal change that I could come up with is:
--8<---
diff --git i/src/corelib/io/qiodevice_p.h w/src/corelib/io/qiodevice_p.h
index 56a89ab..090e551 100644
--- i/src/corelib/io/qiodevice_p.h
+++ w/src/corelib/io/qiodevice_p.h
@@ -143,6 +143,10 @@ public:
  bool canReadLine() const {
  return memchr(first, '\n', len);
  }
+qint64 countTo(char c) {
+char* pos =  static_cast(memchr(first, c, len));
+return pos ? 1+(pos-first) : 0;
+}
  void ungetChar(char c) {
  if (first == buf) {
  // underflow, the existing valid data needs to move to the en
--8<---
countTo() returns number of bytes one would have to read() in order to 
have first delimiter copied to user data structures (that is it is 
inclusive) and if delimiter is not available than it returns 0.

By using this I can then subclass QSerialPort and implement what I want 
without double buffering.  That way I can also avoid double searching 
for delimiter [1].

Does this kind of suggestion/change has any chance of going through.  In 
other words: would it be a waste of time for me to setup dev env and 
gerrit to try to push something like this?

Best regards
Andrzej Ostruszka

[1] This is "a problem" with the current interface since usually 
QIODevice::canReadLine() and QIODevice::readLine() are used in tandem 
and in readyRead() callback one checks for "canReadLine" before invoking 
readLine() in order to not block if the whole line is not yet available. 
  This pattern means that we are doubly searching for the delimiter.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development