Re: [Development] Should QVariant be doing fuzzy comparisons on doubles?

[Thiago Macieira]

On quarta-feira, 21 de setembro de 2016 03:56:31 PDT Kevin Kofler wrote:
> Thiago Macieira wrote:
> > And I will reject any patch that adds more complexity in qFuzzyCompare for
> > a 0.01% corner-case. Instead, we should document that it only works for
> > finite numbers far enough away from zero. If your number can be infinite
> > or NaN or zero, you have to find something else.
> 
> This is just ridiculous, the code would be fixing a clear bug, and avoid
> having to very dangerously change the behavior of QVariant.

The clear bug is in QVariant and my original patch fixed qvariant.cpp 
numericCompare function. It's ok to call fpclassify() there, since QVariant 
comparison is not expected to be really fast. Besides, it's out-of-line code.

However, I will oppose adding fpclassify() or isinf() to qFuzzyCompare. That 
function has existed for 10 years (or more) and this is this is the first we 
ever discuss it having a problem. The bug report isn't even about 
qFuzzyCompare, so as far as I know, no user has ever complained about it not 
working for infinities.

I do remember a discussion some 8 or 9 years ago about using qFuzzyCompare to 
compare to zero. That's why qFuzzyIsNull exists. Which also means that 
QVariant comparisons to exact-zero or when the numbers are close to zero 
aren't fuzzy.

-- 
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] Should QVariant be doing fuzzy comparisons on doubles?

[Kevin Kofler]

Thiago Macieira wrote:
> And I will reject any patch that adds more complexity in qFuzzyCompare for
> a 0.01% corner-case. Instead, we should document that it only works for
> finite numbers far enough away from zero. If your number can be infinite
> or NaN or zero, you have to find something else.

This is just ridiculous, the code would be fixing a clear bug, and avoid 
having to very dangerously change the behavior of QVariant.

Kevin Kofler

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

Re: [Development] Qt5 Bearer: broken PPP support

[Thiago Macieira]

On terça-feira, 20 de setembro de 2016 22:48:42 PDT Alexander Smirnov wrote:
> After debugging I figured out, that the problem is in commit:
> 
>043f5d3eb52587831f643bc52c95079c36d984c7
> 
> This commit allows to add to list:
> 
>QList interfaces;
> 
> interfaces with no address field (ifa_addr == NULL).
> 
> Then, I've checked the output from 'getifaddrs()' syscall on my board,
> and it returns 2! instances of ppp0:
> 
>   - one with AF_INET family
>   - one with ifa_addr == NULL
[cut]
> So, is it a bug? :-)

Probably. Can you give me a full dump of what getifaddrs gave you along with

ip -d link show dev ppp0
ip -d addr show dev ppp0

I'll fix it.

-- 
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] QCS2016 Session Notes - QUIPs for Qt

[Thiago Macieira]

On terça-feira, 20 de setembro de 2016 22:30:56 PDT Sergio Ahumada wrote:
> which 5-year-old feature are we missing?

The new UI.

I want to see all comment, in all files, from all reviews, along with the 
review message, in one page.

The new UI also has the ability to comment on multiple lines or sections of a 
line.

-- 
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] QCS2016 Session Notes - QUIPs for Qt

[Sergio Ahumada]

On 20.09.2016 21:26, Thiago Macieira wrote:

On terça-feira, 20 de setembro de 2016 19:04:07 PDT Filippo Cucchetto wrote:

Really?
Shouldn't be better to just announce a proposal on the mailing list
and then shift the discussion and feedbacks
on the codereview?


It may come as a shock to you, but the Gerrit user interface is horrible.
Reviewing discussions after they're done is very difficult, since there's no way
to dump inline comments with the 5-year-old interface we're using (the one
Gerrit added some time 3 or 4 years ago can do it). Joining a discussion in
progress is very difficult.

Email is much easier.



which 5-year-old feature are we missing? --comments?

$ ssh codereview.qt-project.org gerrit query 171459 --patch-sets 
--comments --format JSON | python -c $'import json, sys; 
l=sys.stdin.readline();j=json.loads(l)\nfor i in j["patchSets"]:\n\tif 
"comments" in i: print i["comments"]'


this shows both inline comments in 
https://codereview.qt-project.org/#/c/171459/1/src/plugins/platforms/vnc/qvnc.cpp


--
Sergio Ahumada
sahum...@texla.cl

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

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Filippo Cucchetto]

I could agree, but basically you're saying that the problem is the
tool and not the idea to discuss
the details on the codereview. At the end a proposal is for sure a
document (thus a sort of source file) and so
gerrit would help matching the discussion with the actual version of
the document (imho this could be
harder by email).
Given that i'm ok in both codereview or email...maybe i'm too biased
by github :)


2016-09-20 21:26 GMT+02:00 Thiago Macieira :
> On terça-feira, 20 de setembro de 2016 19:04:07 PDT Filippo Cucchetto wrote:
>> Really?
>> Shouldn't be better to just announce a proposal on the mailing list
>> and then shift the discussion and feedbacks
>> on the codereview?
>
> It may come as a shock to you, but the Gerrit user interface is horrible.
> Reviewing discussions after they're done is very difficult, since there's no 
> way
> to dump inline comments with the 5-year-old interface we're using (the one
> Gerrit added some time 3 or 4 years ago can do it). Joining a discussion in
> progress is very difficult.
>
> Email is much easier.
>
> --
> 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



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

[Development] Qt5 Bearer: broken PPP support

[Alexander Smirnov]

Dear all,

I've faced with the following problem. I use the Linux-based board, in 
which I start PPP daemon to have GPRS networking. After upgrading from 
Qt5.4 to Qt5.6 my ppp0 interface is always in 
QNetworkConfiguration::Defined state, so it's unusable.


After debugging I figured out, that the problem is in commit:

  043f5d3eb52587831f643bc52c95079c36d984c7

This commit allows to add to list:

  QList interfaces;

interfaces with no address field (ifa_addr == NULL).

Then, I've checked the output from 'getifaddrs()' syscall on my board, 
and it returns 2! instances of ppp0:


 - one with AF_INET family
 - one with ifa_addr == NULL

So, with the commit mentioned above, there are 2 ppp0 interfaces now in 
the list, one - correct, second - incorrect.


Due to this mix, eventually in

  QGenericEngine::doRequestUpdate()

ppp0 is always set to QNetworkConfiguration::Defined, because:

  interface.addressEntries().isEmpty()


Reverting the patch helps to get ppp0 in QNetworkConfiguration::Active 
state.


So, is it a bug? :-)

--
With best regards,
Alexander Smirnov

ilbers GmbH
Baierbrunner Str. 28c
D-81379 München
+49 (89) 122 67 24-0
http://ilbers.de/
Commercial register Munich, HRB 214197
General manager: Baurzhan Ismagulov
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Matthew Woehlke]

On 2016-09-20 15:18, Konstantin Tokarev wrote:
> 20.09.2016, 22:11, "Matthew Woehlke" :
>> That works with e.g. make/ninja, but not so well with VS, but that's a
>> VS failing that I don't see how Qbs could overcome, given that VS *is*
>> the build tool and doesn't AFAIK support dynamic build graphs. 
> 
> QBS does not use VS as a build tool, it is not a project generator

...but that's sort of my point; calling CMake deficient because it can't
do something that Qbs can't do either is disingenuous.

Saying "oh, but Qbs just tells VS to invoke Qbs" isn't really better;
there is no reason (besides "no one has implemented it") why CMake
couldn't do the same thing with e.g. ninja as the build driver. (And
either case assumes you don't include the generated files in the VS
project, or both will still have VS complaining about reloading the
project...)

-- 
Matthew

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

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Thiago Macieira]

On terça-feira, 20 de setembro de 2016 19:04:07 PDT Filippo Cucchetto wrote:
> Really?
> Shouldn't be better to just announce a proposal on the mailing list
> and then shift the discussion and feedbacks
> on the codereview?

It may come as a shock to you, but the Gerrit user interface is horrible. 
Reviewing discussions after they're done is very difficult, since there's no 
way 
to dump inline comments with the 5-year-old interface we're using (the one 
Gerrit added some time 3 or 4 years ago can do it). Joining a discussion in 
progress is very difficult.

Email is much easier.

-- 
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] Notes on "Qt Build Systems" @ QtCon 2016

[Konstantin Tokarev]

20.09.2016, 22:21, "Matthew Woehlke" :
> On 2016-09-15 02:57, Oswald Buddenhagen wrote:
>>  On Wed, Sep 14, 2016 at 12:05:15PM +0200, Stephen Kelly via Development 
>> wrote:
>>>  I want to understand Qbs and what it can do with a dynamic build graph
>>>  which CMake can't do.
>>
>>  there is no such thing, as after full expansion the graph has to be
>>  static by definition (the output artifacts are expected to be
>>  deterministic, after all).
>
> I don't think that's actually true; it just has to *halt*. That is, you
> can execute as many steps as you like that generate new build edges, as
> long as *at some point* you end up with a static graph.
>
> CMake necessarily imposes that you can run exactly one iteration, but
> I'm not aware of any theoretical reason you couldn't have an entire
> chain of targets each of which don't know their outputs (which are the
> inputs of the next in the chain) until you go to actually build them.
>
> For that matter, you can do that sort of thing with make, by having each
> target depend on the previous one, and generate a new Makefile that is
> used to build the next one.

More popular pattern: include generated makefile (e.g., depfile produced by GCC)
into "master" makefile

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

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Jake Petroules]

> On Sep 20, 2016, at 12:18 PM, Konstantin Tokarev  wrote:
> 
> 
> 
> 20.09.2016, 22:11, "Matthew Woehlke" :
>> That works with e.g. make/ninja, but not so well with VS, but that's a
>> VS failing that I don't see how Qbs could overcome, given that VS *is*
>> the build tool and doesn't AFAIK support dynamic build graphs. 
> 
> QBS does not use VS as a build tool, it is not a project generator

Although it can act as one; I recently added support for generating VS 
projects: https://codereview.qt-project.org/#/c/91353/

Qbs still performs the build entirely on its own though, the VS output is no 
more than a file listing.

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

-- 
Jake Petroules - jake.petrou...@qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io

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

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Matthew Woehlke]

On 2016-09-15 02:57, Oswald Buddenhagen wrote:
> On Wed, Sep 14, 2016 at 12:05:15PM +0200, Stephen Kelly via Development wrote:
>> I want to understand Qbs and what it can do with a dynamic build graph
>> which CMake can't do.
>
> there is no such thing, as after full expansion the graph has to be
> static by definition (the output artifacts are expected to be
> deterministic, after all).

I don't think that's actually true; it just has to *halt*. That is, you
can execute as many steps as you like that generate new build edges, as
long as *at some point* you end up with a static graph.

CMake necessarily imposes that you can run exactly one iteration, but
I'm not aware of any theoretical reason you couldn't have an entire
chain of targets each of which don't know their outputs (which are the
inputs of the next in the chain) until you go to actually build them.

For that matter, you can do that sort of thing with make, by having each
target depend on the previous one, and generate a new Makefile that is
used to build the next one.

-- 
Matthew

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

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Konstantin Tokarev]

20.09.2016, 22:11, "Matthew Woehlke" :
> That works with e.g. make/ninja, but not so well with VS, but that's a
> VS failing that I don't see how Qbs could overcome, given that VS *is*
> the build tool and doesn't AFAIK support dynamic build graphs. 

QBS does not use VS as a build tool, it is not a project generator

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

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Matthew Woehlke]

On 2016-09-08 07:41, Bo Thorsen wrote:
> Den 05-09-2016 kl. 20:49 skrev Milian Wolff:
>>> As an incredibly simple example, make is inherently limited in that it
>>> cannot even represent a rule with multiple outputs (there are some
>>> workarounds, but they are hacky and rather limited in how they can be
>>> applied). And ninja is no magic bullet here either, because that still
>>> represents a static build graph, whereas the content of Qbs' build
>>> graph can actually change during the execution of the build.
>>
>> Can you give an example for why we should care? This may sound 
>> flame-baity, but I'm really truly interested. I simply don't care
>> about my build system, as long as it gets the job done without too
>> much hassle (and yes, that is the case for me personally with
>> cmake), and fast, too (which is the case with ninja).
> 
> I can answer that because I asked for this feature all the way back at
> QtCS in Bilbao.
> 
> The context I was talking about was code generators. At the time I had
> built a code generator that created both the Qt and the PHP side of a
> client-server system. It had a single JSON file that described a server
> with the available remote methods on it. The output from the C++ code
> generator was a .h and .cpp file per method and a single .h and .cpp
> that described the server. So on qmake run time you can't know how many
> output files you have unless you force the user to run qmake every time
> you modify the JSON description.
> 
> And to make the problem worse, the customer wanted each of the classes
> describing a remote call to be qobjects with a Q_OBJECT so a moc run is
> required.
> 
> AFAIK this is impossible to do with both qmake and cmake. Not just hard,
> actually impossible.

It's not *impossible*... it "just" requires that you be able to
determine the outputs at configure time, e.g. by having the tool run in
a mode that does nothing but report what files will be produced.

Granted, this is arduous, and especially terrible if the complexity of
determining the output files is on the order of producing them in the
first place, but saying it's "actually impossible" is a bit of an
exaggeration.

(This can't exactly work with VS because the *way* it works is to force
CMake to re-run when the file(s) that determine the output files change.
That works with e.g. make/ninja, but not so well with VS, but that's a
VS failing that I don't see how Qbs could overcome, given that VS *is*
the build tool and doesn't AFAIK support dynamic build graphs. Blaming
CMake for VS's shortcomings isn't really fair.)

The project I'm working on currently uses LCM, which has this problem
(we also use CMake, and have a CMake script that parses the input files
in order to determine the names of the output files). So does PySide /
Shiboken, and I'm sure there are other examples out there.

-- 
Matthew

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

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Lars Knoll]

My thinking. I’m fine to have initial discussions on the mailing list, but 
agreeing on and nailing down details will be a lot easier to do on codereview.

Lars

On 20/09/16 19:04, "Development on behalf of Filippo Cucchetto" 
 wrote:

Really?
Shouldn't be better to just announce a proposal on the mailing list
and then shift the discussion and feedbacks
on the codereview?

2016-09-20 18:46 GMT+02:00 Thiago Macieira :
> On terça-feira, 20 de setembro de 2016 08:54:05 PDT Lars Knoll wrote:
>> And it formalizes the way we can discuss and comment on things, as QUIPs
>> would be reviewed in codereview, then approved there. I believe it’ll 
lead
>> to a better workflow and better decision making in the project than
>> discussions on the mailing list that often end somewhat inconclusive.
>
> Discussions on content still happen on the mailing list for maximum
> reachability. The discussion on codereview is just the editorial workflow.
>
> --
> 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



-- 
Filippo Cucchetto
___
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] QCS2016 Session Notes - QUIPs for Qt

[Filippo Cucchetto]

Really?
Shouldn't be better to just announce a proposal on the mailing list
and then shift the discussion and feedbacks
on the codereview?

2016-09-20 18:46 GMT+02:00 Thiago Macieira :
> On terça-feira, 20 de setembro de 2016 08:54:05 PDT Lars Knoll wrote:
>> And it formalizes the way we can discuss and comment on things, as QUIPs
>> would be reviewed in codereview, then approved there. I believe it’ll lead
>> to a better workflow and better decision making in the project than
>> discussions on the mailing list that often end somewhat inconclusive.
>
> Discussions on content still happen on the mailing list for maximum
> reachability. The discussion on codereview is just the editorial workflow.
>
> --
> 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



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

Re: [Development] Should QVariant be doing fuzzy comparisons on doubles?

[Thiago Macieira]

On terça-feira, 20 de setembro de 2016 11:29:32 PDT Olivier Goffart wrote:
> > Is such a behavior change really acceptable for 5.8? I think it can break
> > applications that were relying on the current behavior in pretty bad, hard
> > to debug ways (random bugs based on rounding errors).
> 
> I tend to agree with that.
> This is a behavior change, and i see no reason to do it. Comparing double
> for equality with operator== is a bad idea.
> I know QVariant::operator== has problems, but i don't think this is
> something that should be changed.

I did add a changelog for important behaviour change and I do think it should 
be changed. Fuzzy comparisons only operate on certain values. We know there's  
a problem with them when both numbers are close to zero: for example, fuzzy 
comparing 1.2e-12 to 0 is false, comparing it to -1.2e-12 is false, even 
though they could be the result from the same operation.

I also think that if you want a fuzzy comparison in variants, you should call 
qFuzzyCompare(QVariant, QVariant) (which doesn't exist, I can add it).

> (Correct me if i'm wrong, but this might actually have quite some bad
> performance impact on QML where lot of bindings are done on a real value and
> they are compared for equality before emiting the changed signal. (or does
> QML takes the value out of qvariant before comparing?))

Question for Simon.

> On the other hand, the fact that qFuzzyCompare(inf, -inf) returns true looks
> like a bug within qFuzzyCompare.

And I will reject any patch that adds more complexity in qFuzzyCompare for a 
0.01% corner-case. Instead, we should document that it only works for finite 
numbers far enough away from zero. If your number can be infinite or NaN or 
zero, you have to find something else.

-- 
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] QCS2016 Session Notes - QUIPs for Qt

[Thiago Macieira]

On terça-feira, 20 de setembro de 2016 08:54:05 PDT Lars Knoll wrote:
> And it formalizes the way we can discuss and comment on things, as QUIPs
> would be reviewed in codereview, then approved there. I believe it’ll lead
> to a better workflow and better decision making in the project than
> discussions on the mailing list that often end somewhat inconclusive.

Discussions on content still happen on the mailing list for maximum 
reachability. The discussion on codereview is just the editorial workflow.

-- 
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] Should QVariant be doing fuzzy comparisons on doubles?

[Marc Mutz]

On Tuesday 20 September 2016 12:44:04 Olivier Goffart wrote:
> > It is easy to forget registering comparator functions and currently Qt
> > doesn't help in debugging such issues. So I wonder if QVariant should
> > forbid comparison of custom types without having a comparator function
> > registered.
> 
> That's a source incompatible change.

But one of the type we allow (fixes still compile and work with older Qt), in 
line with adding `explicit` to ctors that miss it.

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] Should QVariant be doing fuzzy comparisons on doubles?

[Olivier Goffart]

On Dienstag, 20. September 2016 12:21:11 CEST Mathias Hasselmann wrote:
> Am 19.09.2016 um 23:27 schrieb Olivier Goffart:
> > We really cannot have a qHash for QVariant anyway, because that would
> > imply
> > that ALL QVariant can be hashed, and compared. Which is not the case. Most
> > custom types don't even register comparator function.
> 
> Which actually is quite a serious issue, as we do a simply memcmp() on
> such custom types, which simply won't work if your custom data structure
> contains uninitialized memory from alignment padding.

We don't do that. We just return false in that case.


> It is easy to forget registering comparator functions and currently Qt
> doesn't help in debugging such issues. So I wonder if QVariant should
> forbid comparison of custom types without having a comparator function
> registered.

That's a source incompatible change.

-- 
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Should QVariant be doing fuzzy comparisons on doubles?

[Mathias Hasselmann]

Am 19.09.2016 um 23:27 schrieb Olivier Goffart:

We really cannot have a qHash for QVariant anyway, because that would imply
that ALL QVariant can be hashed, and compared. Which is not the case. Most
custom types don't even register comparator function.


Which actually is quite a serious issue, as we do a simply memcmp() on 
such custom types, which simply won't work if your custom data structure 
contains uninitialized memory from alignment padding.


It is easy to forget registering comparator functions and currently Qt 
doesn't help in debugging such issues. So I wonder if QVariant should 
forbid comparison of custom types without having a comparator function 
registered.


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

Re: [Development] Should QVariant be doing fuzzy comparisons on doubles?

[Olivier Goffart]

On Dienstag, 20. September 2016 03:08:42 CEST Kevin Kofler wrote:
> Thiago Macieira wrote:
> > Since this is a P3 and 5.8 hasn't been released, I will push the behaviour
> > change to 5.8 and drop the fuzzy comparison.
> 
> Is such a behavior change really acceptable for 5.8? I think it can break
> applications that were relying on the current behavior in pretty bad, hard
> to debug ways (random bugs based on rounding errors).

I tend to agree with that. 
This is a behavior change, and i see no reason to do it. Comparing double for 
equality with operator== is a bad idea.
I know QVariant::operator== has problems, but i don't think this is something 
that should be changed.

(Correct me if i'm wrong, but this might actually have quite some bad 
performance impact on QML where lot of bindings are done on a real value and 
they are compared for equality before emiting the changed signal. (or does QML 
takes the value out of qvariant before comparing?))

On the other hand, the fact that qFuzzyCompare(inf, -inf) returns true looks 
like a bug within qFuzzyCompare.

-- 
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Edward Welbourne]

> [*] https://wiki.qt.io/Template:QUIP
> If someone with more Wiki-template-foo could please review this, I'm
> sure it can be improved; in particular, it uses 000{{{1}}} where clearly
> some analogue of formatting {{{1}}} with %03d would be more apt.

Sorry, obviously I meant %04d ...

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

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Lars Knoll]

On 20/09/16 09:27, "Development on behalf of Thiago Macieira" 
 wrote:

On terça-feira, 20 de setembro de 2016 09:02:11 PDT André Somers wrote:
> So, could you please explain, preferably without relying on all the
> acronyms, what problems this bureaucratization effort is trying to
> resolve, and how it fits the rest of our work flow (like making feature
> requests in Jira)?

Basically, QUIP extends the governance by formalising decisions. The 
governance says decisions are made by consensus and meritocracy on the 
mailing 
list. But once the discussion ends, how do we know what we agreed upon? And 
two years later, how do we find out what we had decided?

Can you remember the list of C++11 features we're allowed to use? We had a 
discussion on the mailing list.

Do you remember why we decided not to have the Standard Library in our ABI? 
That discussion happened in 2012.

The mailing list archives are searchable, but that doesn't mean it's easy 
to 
find what you're looking for.

And it formalizes the way we can discuss and comment on things, as QUIPs would 
be reviewed in codereview, then approved there. I believe it’ll lead to a 
better workflow and better decision making in the project than discussions on 
the mailing list that often end somewhat inconclusive.

Cheers,
Lars


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

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Thiago Macieira]

On terça-feira, 20 de setembro de 2016 09:02:11 PDT André Somers wrote:
> So, could you please explain, preferably without relying on all the
> acronyms, what problems this bureaucratization effort is trying to
> resolve, and how it fits the rest of our work flow (like making feature
> requests in Jira)?

Basically, QUIP extends the governance by formalising decisions. The 
governance says decisions are made by consensus and meritocracy on the mailing 
list. But once the discussion ends, how do we know what we agreed upon? And 
two years later, how do we find out what we had decided?

Can you remember the list of C++11 features we're allowed to use? We had a 
discussion on the mailing list.

Do you remember why we decided not to have the Standard Library in our ABI? 
That discussion happened in 2012.

The mailing list archives are searchable, but that doesn't mean it's easy to 
find what you're looking for.

-- 
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] QCS2016 Session Notes - QUIPs for Qt

[André Somers]

Hi,

Thanks for posting this, it finally cleared up a few postings by Thiago 
from just after the event.


I wrestled my way through this whole thing, trying to get through the 
self-referential nature of all the acronyms. Somewhere in the middle I 
finally found what a QUIP is supposed to be. However, nowhere did I find 
an explanation of what problem it is supposed to solve, why it solves 
it, or how it integrates with the current work flow. So far, it seems to 
me like a solution from some management sphere without a problem to solve.


So, could you please explain, preferably without relying on all the 
acronyms, what problems this bureaucratization effort is trying to 
resolve, and how it fits the rest of our work flow (like making feature 
requests in Jira)?


Thanks,

André

Op 20/09/2016 om 00:45 schreef Louai Al-Khanji:

Hi all,

Here are my notes from the QUIPs session. Thank you for your patience. :-)

QUIPs are a proposed design process for Qt, modeled after Python’s PEPs.

QUIP 1 introduces the general concept:

   http://quips-qt-io.herokuapp.com/quip-0001.html

QUIP 2 details the Qt governance model, it’s simply the current wiki page
converted into a QUIP:

   http://quips-qt-io.herokuapp.com/quip-0002.html

QUIP 3 is an informational QUIP containing the session notes, which are
repeated below:

   http://quips-qt-io.herokuapp.com/quip-0003.html

The heroku domain is obviously a placeholder.

I have also attached the source files for proposed QUIPs 1, 2, and 3 to this 
e-mail.

One item left open was licensing of the QUIPs themselves. For these I propose
Creative Commons CC0.

Any and all feedback welcome.

Cheers,
Louai

 BEGIN NOTES 

At the Qt Contributors' Summit 2016 in Berlin a session was held to discuss the
idea of introducing QUIPs as a new process for Qt governance.

The general idea was introduced by looking at QUIPs 1 and 2, and by looking at
some Python PEPs. The general feedback was positive. An attempt was made to
identify the minimum set of work required to bootstrap QUIP, which was the main
theme of the session.

The overall discussion is summarized below, in roughly chronological order.

- Discussed background of QUIP, the process and the documents. Referred to
   Python and looked at QUIP 1 and QUIP 2 which had been prepared prior to the
   session.

   - The idea is to have a new git repository with the QUIP text files

   - Managed through Qt's normal work flow, currently gerrit code review

   - The maintainer of the quips repository takes on required editorial duties
- Agreed that the text documents should be limited to 80 character lines.

- Agreed that care must be taken to ensure that QUIPs are written in "proper"
   English so as to be clear, understandable and concise.

- Talked about how a new QUIP is introduced. The most important thing is to
   reserve a number, which is the identifier of any one QUIP. The title can
   change, and is expected to do so from time to time.

- New QUIP documents will go through a review process like any other patch to
   Qt. The author of the QUIP is responsible for logging this discussion in the
   evolving QUIP itself.

- The important thing is to bootstrap the process. Once it is bootstrapped, it
   is possible to fine-tune the QUIP process through QUIPs. It is expected that
   this will happen.

- The question of what goes into a QUIP was discussed. QUIP 1 gives a rough
   overview of the different kinds of possible QUIPs. It is expected that the
   content be further specified in revisions of QUIP 1 or in follow-up QUIPs.

- Like any other part of Qt, QUIPs are living documents. They can be updated,
   amended or entirely superseded by later ones.

- QUIP licensing was discussed. Python's PEPs are required to be either placed
   in the public domain or licensed under the Open Publication License. The
   former is not possible in all jurisdictions and the latter has apparently
   been superseded by the Creative Commons licenses the CC0 license was
   suggested.

- The minimum QUIP boostrapping process was discussed:

   1. Post QUIP 1 to qt-development mailing list for discussion.

   2. Arrange for hosting of HTML generated from QUIPs (ed. note: quips.qt.io
  has since been made available)

   3. Create new git repository to hold QUIPs

- The initial QUIP process was discussed:

   1. Author of QUIP reserves new number in QUIP 0 (the index QUIP) through
  gerrit

   2. The author gives notice of new QUIP by sending it to qt-development,
  either inline or as a text attachment (things like this can be refined
  later through QUIPs)

   3. Concurrently the author pushes the draft to gerrit where further
  discussion can take place. This discussion must be described in the QUIP.

   4. Decisions are achieved through the same lazy consensus mechanism that
  is in place today. In that respect nothing changes.

   5. A final +2 from the QUIP maintainer(s) is required. This 

Re: [Development] Should QVariant be doing fuzzy comparisons on doubles?

[Marc Mutz]

On Monday 19 September 2016 23:27:52 Olivier Goffart wrote:
> On Montag, 19. September 2016 18:48:10 CEST Marc Mutz wrote:
> > On Monday 19 September 2016 18:20:48 Thiago Macieira wrote:
> > > Should we do fuzzy comparisns in QVariant?
> > 
> > If you talk about op==, then using fuzzy compare is a definite no-no,
> > because it makes it impossible to define a hash function.
> 
> We really cannot have a qHash for QVariant anyway, because that would imply
> that ALL QVariant can be hashed, and compared. Which is not the case. Most
> custom types don't even register comparator function.
> So I don't think that's an argument.

We have a op== on QVariant, thus we must be able to have a qHash, but indeed, 
as I said, this is an extensive amount of work, as if introducing comparator 
functions from scratch.

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