[Development] modbus over serial port on windows 7 ?

[Dmitry Shapovalov]

Hello,
can someone confirm that modbus over serial port is working on windows ?
all my experiments led me to the thought that it is absolutely broken.
i am using arduno as a modbus device. i tested it with qmodbus and modbus
poll. works great. but when i try to use modbus examples from
qt(qtserialbus/examples/serialbus/modbus/master), look like it can not send
request.
i tried release(5.6) and git version of qtserialbus and qtserialport
modules with no luck.

i am using windows 7 on virtualbox.
arduino modbus library from here
https://github.com/smarmengol/Modbus-Master-Slave-for-Arduino
arduino sketch http://pastebin.com/FHW3B7TX

it's me or it's really broken ?

-- 
--
With Best Regards
Dmitry Shapovalov
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Announcing moc_combine

[Thiago Macieira]

On segunda-feira, 30 de maio de 2016 17:58:44 BRT Marc Mutz wrote:
> On Monday 30 May 2016 15:12:01 Thiago Macieira wrote:
> > Sorry, I don't buy it. Instead:
> > qmake -config ltcg
> 
> I take that "I don't buy it" means that link-time compilation also warns
> about unused data and function members?

I didn't specifically test that.

But I know that GCC does detect ODR violations when compiled in LTO mode.

> Anyway, until such a time as that becomes the default build mode for Qt, I
> don't think we should discard optimisations that only(?) benefit separate-
> compilation modes.

I doubt we'll make it the default. But correcting warnings is something that 
we Qt developers need to do and we can enable LTCG mode.

-- 
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] Announcing moc_combine

[Marc Mutz]

On Monday 30 May 2016 15:12:01 Thiago Macieira wrote:
> Sorry, I don't buy it. Instead:
> qmake -config ltcg

I take that "I don't buy it" means that link-time compilation also warns about 
unused data and function members?

Anyway, until such a time as that becomes the default build mode for Qt, I 
don't think we should discard optimisations that only(?) benefit separate-
compilation modes.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Supported platforms for Qt 5.8

[Allan Sandfeld Jensen]

On Wednesday 25 May 2016, Jake Petroules wrote:
> Hi all,
> 
> Might be a bit premature, but is anyone opposed to dropping OS X 10.9 and
> iOS 7.x in Qt 5.8? This would follow dropping one OS X and iOS release per
> Qt release for the past 3 releases, but after that I think we should slow
> to dropping one release for each release we add (so, once annually or
> about once every two Qt minor releases). 10.10 and 8.0 were larger
> releases that began a new "generation" so I think that gives us a better
> baseline to start with before slowing to an annual upgrade cycle. --

Well Qt WebEngine has always had stricter requirements than the rest of Qt, so 
this shouldn't necessarily affect all other Qt modules, but it might be worth 
keeping in mind;

The lastest Chromium 51, which is now being integrated into dev requires MSVC 
2015 on Windows, and on Mac, XCode 6.4+ which Apple only allows to run on OS X 
10.10+

Note though that these requirements are not final. Qt WebEngine 5.8 will 
likely end up using Chromium 53 before the we freeze the version, and the 
requirements might still change (though likely only up).

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

Re: [Development] Announcing moc_combine

[Thiago Macieira]

On segunda-feira, 30 de maio de 2016 17:53:48 BRT Marc Mutz wrote:
> This is orthogonal.
> 
> Obviously, I have nothing against running moc only once per
> library/executable, and applying optimisations such as string and sub-string
> sharing across classes. I also have nothing against a single output file
> for the tables. On the contrary. I applaud such changes.
> 
> But I don't want QObject subclass member functions compiled into separate
> TUs anymore, for the reasons cited.
> 
> So this would meet everyones requirements: a single moc run on all headers
> (and cpps) of a library, generating one output file with one large data
> table, and one file per class (or file), to be included in the class' .cpp
> file.

Except one requirement: the buildsytem. Each build target must produce exactly 
one output file. Anything else is not representable.

$ gmake -f /dev/stdin foo bar <<<'foo bar: ; true' 
true
true

I also don't like that the string tables and other details would be extern 
symbols. Right now, they are static. For Qt code, we do have -
fvisibility=hidden, but that's not required for users' code (though we could 
force Q_DECL_HIDDEN).

> This would even preserve Q_PRIVATE_SLOT, leading to less churn (unless that
> transition is desireable for other reasons than "doesn't work with
> moc_combine").

It's desireable in most cases, but it's not always easy.

-- 
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] Announcing moc_combine

[Marc Mutz]

On Monday 30 May 2016 16:24:38 Jędrzej Nowacki wrote:
> On Monday 30 of May 2016 10:19:38 Marc Mutz wrote:
> > On Sunday 29 May 2016 18:05:07 Thiago Macieira wrote:
> > > I've just pushed a feature[1] to moc that makes it process multiple
> > > headers
> > > at  the same time, producing only one output file
> > 
> > Separate compilation is not how I would recommend to use moc-generated
> > files. I'd recommend to always include the moc file in the corresponding
> > cpp file. That gives the compiler the whole picture and enables better
> > optimisation[1] and error checking[2,3].
> 
> If moc has full picture it also can apply some nice optimizations, like for
> example here https://codereview.qt-project.org/#/c/75151/.

This is orthogonal.

Obviously, I have nothing against running moc only once per 
library/executable, and applying optimisations such as string and sub-string 
sharing across classes. I also have nothing against a single output file for 
the tables. On the contrary. I applaud such changes.

But I don't want QObject subclass member functions compiled into separate TUs 
anymore, for the reasons cited.

So this would meet everyones requirements: a single moc run on all headers 
(and cpps) of a library, generating one output file with one large data table, 
and one file per class (or file), to be included in the class' .cpp file.

This would even preserve Q_PRIVATE_SLOT, leading to less churn (unless that 
transition is desireable for other reasons than "doesn't work with 
moc_combine").

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Announcing moc_combine

[Thiago Macieira]

On segunda-feira, 30 de maio de 2016 10:12:01 BRT Thiago Macieira wrote:
> Em segunda-feira, 30 de maio de 2016, às 10:19:38 BRT, Marc Mutz escreveu:
> > On Sunday 29 May 2016 18:05:07 Thiago Macieira wrote:
> > > I've just pushed a feature[1] to moc that makes it process multiple
> > > headers
> > > at  the same time, producing only one output file
> > 
> > Separate compilation is not how I would recommend to use moc-generated
> > files. I'd recommend to always include the moc file in the corresponding
> > cpp file. That gives the compiler the whole picture and enables better
> > optimisation[1] and error checking[2,3].
> 
> Sorry, I don't buy it. Instead:
>   qmake -config ltcg

I've just fixed the LTCG build for Clang on Linux. I've been doign LTCG builds 
with GCC on Linux for some time too.

See also Jędrzej's patch to share strings in moc[1] and between classes[2]. 
With both patche sets in, we should have one large string table for all 
classes in the library.

[1] https://codereview.qt-project.org/75147
[2] https://codereview.qt-project.org/75151

-- 
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] Announcing moc_combine

[Jędrzej Nowacki]

On Monday 30 of May 2016 10:19:38 Marc Mutz wrote:
> On Sunday 29 May 2016 18:05:07 Thiago Macieira wrote:
> > I've just pushed a feature[1] to moc that makes it process multiple
> > headers
> > at  the same time, producing only one output file
> 
> Separate compilation is not how I would recommend to use moc-generated
> files. I'd recommend to always include the moc file in the corresponding
> cpp file. That gives the compiler the whole picture and enables better
> optimisation[1] and error checking[2,3].

If moc has full picture it also can apply some nice optimizations, like for 
example here https://codereview.qt-project.org/#/c/75151/.

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Announcing moc_combine

[Oswald Buddenhagen]

On Mon, May 30, 2016 at 10:19:38AM +0200, Marc Mutz wrote:
> On Sunday 29 May 2016 18:05:07 Thiago Macieira wrote:
> > I've just pushed a feature[1] to moc that makes it process multiple headers
> > at  the same time, producing only one output file
> 
> Separate compilation is not how I would recommend to use moc-generated files. 
> I'd recommend to always include the moc file in the corresponding cpp file. 
>
i agree that the idea to bulk-compile mocs is somewhat backwards.

however, manual includemocs are somewhat annoying, and in fact the need
to include the moc when using Q_OBJECT in a .cpp file is one of the most
common reasons for puzzling error messages (something about a missing
vtable ... ?!?!).

an idea would be auto-wrapping sources into generated files that
include the actual source and the moc. but that might be a bit tough to
implement with qmake, and the build artifacts would look a bit weird
(particularly relevant for debugging).

the next idea would be implementing moc inside the compiler itself,
which is possible with at least clang and gcc nowadays.

the last idea is doing away with moc entirely, at the cost of somewhat
uglier macros, and actually working c++11/14 support in the compiler.

"incidentally", olivier has more-or-less working solutions based on the
latter two ideas.

> That gives the compiler the whole picture and enables better optimisation[1] 
> and error checking[2,3].
> 
> Thanks,
> Marc
> 
> [1] https://codereview.qt-project.org/152423
> [2] https://codereview.qt-project.org/153309
> [3] https://codereview.qt-project.org/153321
> 
> -- 
> Marc Mutz  | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - Qt, C++ and OpenGL Experts
> ___
> 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

Re: [Development] Supported platforms for Qt 5.8

[Shawn Rutledge]

That’s my view too: 10.9 may be a popular holdout for years, like 10.6 was.  
Now the typical response would be: well you can still deploy Qt applications to 
it - doesn’t mean it has to be a supported developer platform.  Or, developers 
can stop upgrading Qt and stick with 5.6 or so.  Is that really what we want 
them to do?

Now I don’t think upgrading say a Core 2 Duo machine to 10.11 is anywhere near 
as bad as the iOS upgrade was (that was a disaster, in my experience on an iPad 
2), but wouldn’t be surprised if people have good reasons not to.  And what 
does it cost us?  Most of the newer features are there anyway.  Are there 
really so many ifdefs that we will avoid a maintenance nightmare by removing 
them?  Or is it about the compiler?

> On 30 May 2016, at 10:21, Mark Gaiser  wrote:
> 
> If possible, please don't..
> Unless there is a technical reason which would make dropping that version a 
> requirement?
> 
> I'm still on OSX 10.9 since i like it much more then the versions that came 
> after it.
> 
> On Thu, May 26, 2016 at 11:39 AM, Tuukka Turunen  wrote:
> Sounds good to me in principle, especially since we very likely have again 
> next generation of both iOS and OS X to support in Qt 5.8.
> 
>  
> 
> Especially in iOS users tend to upgrade to new versions quite quickly (and 
> then see if their devices still can run that or not).
> 
>  
> 
> Yours,
> 
>  
> 
> Tuukka
> 
>  
> 
> From: Development 
> [mailto:development-bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of 
> Jake Petroules
> Sent: keskiviikkona 25. toukokuuta 2016 21.17
> To: development@qt-project.org
> Subject: [Development] Supported platforms for Qt 5.8
> 
>  
> 
> Hi all,
> 
>  
> 
> Might be a bit premature, but is anyone opposed to dropping OS X 10.9 and iOS 
> 7.x in Qt 5.8? This would follow dropping one OS X and iOS release per Qt 
> release for the past 3 releases, but after that I think we should slow to 
> dropping one release for each release we add (so, once annually or about once 
> every two Qt minor releases). 10.10 and 8.0 were larger releases that began a 
> new "generation" so I think that gives us a better baseline to start with 
> before slowing to an annual upgrade cycle.
> 
> -- 
> Jake Petroules - jake.petrou...@theqtcompany.com
> Consulting Services Engineer - The Qt Company
> 
> Qbs build system evangelist - qbs.io
> 
>  
> 
> 
> ___
> 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

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

Re: [Development] Announcing moc_combine

[Marc Mutz]

On Sunday 29 May 2016 18:05:07 Thiago Macieira wrote:
> I've just pushed a feature[1] to moc that makes it process multiple headers
> at  the same time, producing only one output file

Separate compilation is not how I would recommend to use moc-generated files. 
I'd recommend to always include the moc file in the corresponding cpp file. 
That gives the compiler the whole picture and enables better optimisation[1] 
and error checking[2,3].

Thanks,
Marc

[1] https://codereview.qt-project.org/152423
[2] https://codereview.qt-project.org/153309
[3] https://codereview.qt-project.org/153321

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Supported platforms for Qt 5.8

[Tim Blechmann]

> Might be a bit premature, but is anyone opposed to dropping OS X 10.9
> and iOS 7.x in Qt 5.8?

yes: it will prevent some users (including me) to update to qt-5.8, as
our minimum osx requirement is still 10.9.

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