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

[Sune Vuorela]

On 2016-09-23, André Pönitz  wrote:
> That gives already "surprising" behaviour if fed with QChar('a') and
> QString("a") in a row.
>
> And it is "surprising" to a degree that I'd call it buggy.

Then try feeding it boolean's and strings.

QQmlPropertyMap map;
map.insert(QLatin1String("key1"),true);
map.insert(QLatin1String("key1"),QLatin1String("p"));
QCOMPARE(map.value(QLatin1String("key1")).toString(),QLatin1String("p"));
QCOMPARE((int)map.value(QLatin1String("key1")).type(),(int)QMetaType::QString);
map.insert(QLatin1String("key1"),false);
map.insert(QLatin1String("key1"),QLatin1String(""));
QCOMPARE((int)map.value(QLatin1String("key1")).type(),(int)QMetaType::QString);

(Taken from https://codereview.qt-project.org/#/c/121715/1//ALL when I
was trying to fix things but ... kind of moved on)

/Sune

___
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?

[André Pönitz]

On Fri, Sep 23, 2016 at 09:56:30AM +, Edward Welbourne wrote:
> Indeed; having all values of some type equivalent is worse (for the "has
> my value changed" test you illustrate, at least) than having a value not
> equal to itself (which triggers a "changed" event for a non-change).  In
> fact one can have one's mathematical purity by attacking the "for all x"
> part of the above instead of the "x == x" part.  Although it's usual to
> talk about "a relation is reflexive on S if, for all s in S, it relates
> s to s"

Right. That's pretty much the definition the known universe uses:
https://en.wikipedia.org/wiki/Reflexive_relation
(and no, *I* didn't put it there)

> one can equally define reflexive by "whenever the relation
> relates any x to y, it also relates x to x and y to y". 
> (This is the
> more natural formulation in a mathematics based on relations [*] rather
> than sets.)
> 
> [*] http://www.chaos.org.uk/~eddy/maths/found/relate.xhtml#Types
> 
> With that formulation (which doesn't tie the relation to a set that it's
> "on"), returning false for the types that don't support equality
> comparison works; we won't consider any value of such a type equal to
> *anything*, so our relation isn't required to relate them to themselves.
> We are then left with QVariant::operator== being a relation formally on
> only those QVariants that support comparison, not on all QVariants
> (although it tolerates being asked about the values it doesn't relate to
> anything; it just says no about them).

How does that help with QHash which needs comparsion of the
keys?

> It's not ideal (and the justification is heterodox) but false is a valid
> answer for the incomparable values,

This is a nonsensical line of argument long as you try to use it to counter
"unexpected" results.

With your "uncomparable things compare false" approach QHash<>::contains()
will never return true for uncomparable QVariants, i.e. code like 

void doSomethingOnlyOncePerValue(QVariant v)
{
static QHash seen;
if (seen.contains(v))
return;
seen.insert(v, 0);
doSomething(v);
}

will be quite surprising, too.

Andre'
___
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?

[André Pönitz]

On Fri, Sep 23, 2016 at 11:22:08AM +0200, Olivier Goffart wrote:
> > There is not much of a choice. An equivalence relation is reflexive,
> > i.e. at least Foo(a) == Foo(a) must be true. Lacking the ability
> > to compare Foos, treating them all equal at least doesn't break the
> > relation.
> 
> Why do we want that kind of mathematical purity?

Because that's the only sane way to avoid ugly surprises.

> This ensure we have the most  useless operator==.
> Most of the code use it for stuff like that:
>   
>   void setFoo(const QVariant ) {
>  if (foo != m_foo) {
> m_foo = foo;
> emit fooChanged();
>  }
>   }

That gives already "surprising" behaviour if fed with QChar('a') and
QString("a") in a row.

And it is "surprising" to a degree that I'd call it buggy.

> And suddenly returning always true if the variant has the same type will 
> break 
> this code. And i think will break most use case for QVariant::operator==

Most of the uses of QVariant::operator==() ARE ALREADY BROKEN, and will
not be fixable if people refuse to accept basic requirements.
 
> What use case did you have in mind where a reflexive relation is any usefull?
> There is the case of the key of a QHash or in a QSet, but even then i'm not 
> sure it is wise that all QVariant of the same type map to the "same" value.

The discussion started with making QVariant ready for use in hashs.
 
> So let's be pragmatic here and do something usefull rather than something 
> methematicaly correct, but useless and that break lot of code.

This "pragmatism" has already led to the current situation where
the number of items in a QMap with QVariant keys depend on the
order of insertion and other crap.

> Now that we have C++11 and we can use some expression SFINAE, we can do 
> something like:
> 
>   
>   template
>   auto registerEqualityOperator() 
> -> decltype(std::declval() == std::declval()) 
> 
> Called from qRegisterMetaType, which automatically register the operator== if 
> it exists.
>   
> 
> The QVariant::operator==  could return false if none was registered. And 
> possibly print a qWarning: "Attempting to compare two QVariant containing 
> type 
> 'Foo' which has no equality operation registered".

That would be ok to, but does not invalidate my point.

Andre'
___
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?

[Matthew Woehlke]

On 2016-09-22 16:58, André Pönitz wrote:
> There is not much of a choice. An equivalence relation is reflexive,
> i.e. at least Foo(a) == Foo(a) must be true.

JFTR...

  auto nan = qNaN();
  assert(nan != nan); // okay
  assert(!(nan == nan)); // okay

-- 
Matthew

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

Re: [Development] First Qt 5.8.0 Beta snapshot available

[Thiago Macieira]

On sexta-feira, 23 de setembro de 2016 09:07:13 PDT Jani Heikkinen wrote:
> Hi,
> 
> 
> We have finally first Qt 5.8.0 beta snapshot available
> 
> Windows: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/570/
> 
> Mac: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/439/
> 
> src: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/latest_src/
> 
> 
> Linux ones are there as well but those don't work yet :( iOS installer is
> also missing but coming as well as MSVC2015 32 bit.

Source is not available yet. This dir is empty:

http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/latest_src/submodules/

-- 
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?

[Edward Welbourne]

Olivier Goffart
> What use case did you have in mind where a reflexive relation is any usefull?

Well, having x == x for all x is generally considered a useful property
of equality.  That's all "reflexive" is saying.

> There is the case of the key of a QHash or in a QSet, but even then i'm not
> sure it is wise that all QVariant of the same type map to the "same" value.

Indeed; having all values of some type equivalent is worse (for the "has
my value changed" test you illustrate, at least) than having a value not
equal to itself (which triggers a "changed" event for a non-change).  In
fact one can have one's mathematical purity by attacking the "for all x"
part of the above instead of the "x == x" part.  Although it's usual to
talk about "a relation is reflexive on S if, for all s in S, it relates
s to s" one can equally define reflexive by "whenever the relation
relates any x to y, it also relates x to x and y to y".  (This is the
more natural formulation in a mathematics based on relations [*] rather
than sets.)

[*] http://www.chaos.org.uk/~eddy/maths/found/relate.xhtml#Types

With that formulation (which doesn't tie the relation to a set that it's
"on"), returning false for the types that don't support equality
comparison works; we won't consider any value of such a type equal to
*anything*, so our relation isn't required to relate them to themselves.
We are then left with QVariant::operator== being a relation formally on
only those QVariants that support comparison, not on all QVariants
(although it tolerates being asked about the values it doesn't relate to
anything; it just says no about them).

It's not ideal (and the justification is heterodox) but false is a valid
answer for the incomparable values,

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

Re: [Development] Notes on "Managing Qt's branches" session @ QCS 2016

[Oswald Buddenhagen]

On Thu, Sep 22, 2016 at 09:41:29AM +0200, Marc Mutz wrote:
> On Thursday 22 September 2016 08:55:13 Liang Qi wrote:
> > Give the merge permission to everyone is obiviously not a solution.
> 
> Not everyone, but approvers, maybe? Merges need to be reviewed like any other 
> commit, so why are they special, anyway?
> 
because a botched merge push may result in hundreds of bogus reviews
(when somebody does pull --rebase before pushing the merge; no, that's
not a hypothetical situation). not having the right to push merges
trains the users to not even attempt it.

another reason is that some people tend to over-merge, needlessly
cluttering the history. having to ask another person (who will hopefully
critically examine the request) is a natural check for this.
___
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 Donnerstag, 22. September 2016 22:58:09 CEST André Pönitz wrote:
> On Thu, Sep 22, 2016 at 06:04:58AM +0200, Mathias Hasselmann wrote:
> > Am 22.09.2016 um 00:58 schrieb André Pönitz:
> > >On Wed, Sep 21, 2016 at 08:57:01AM +0200, Olivier Goffart wrote:
> > >>>No, it's not. It's changing undefined behavior into defined
> > >>>behavior.
> > >>
> > >>But in many case, we want to put something in a QVariant, and we
> > >>never compare this variant.  Forbidding types that do not have an
> > >>operator== to be in a QVariant might be to strict.
> > >
> > >Forbidding types without operator== in QVariants is not needed,
> > >not even if one wanted to use associative container with
> > >QVariants as keys.
> > >
> > >[Pseudocode]
> > >
> > >bool operator(QVariant(Foo) a, QVariant(Bar) b)
> > >{
> > >
> > >if Foo != Bar:
> > >return false
> > >
> > >if Foo has no operator==():
> > >return true
> > >
> > >return (Foo)a == (Foo)b
> > >
> > >}
> > >
> > >establishes an equivalance relation by lumping all "uncomparable"
> > >objects into a single equivalency class.
> > 
> > I rather was considering to return false.
> 
> There is not much of a choice. An equivalence relation is reflexive,
> i.e. at least Foo(a) == Foo(a) must be true. Lacking the ability
> to compare Foos, treating them all equal at least doesn't break the
> relation.

Why do we want that kind of mathematical purity? This ensure we have the most 
useless operator==.
Most of the code use it for stuff like that:
  
  void setFoo(const QVariant ) {
 if (foo != m_foo) {
m_foo = foo;
emit fooChanged();
 }
  }

And suddenly returning always true if the variant has the same type will break 
this code. And i think will break most use case for QVariant::operator==


What use case did you have in mind where a reflexive relation is any usefull?
There is the case of the key of a QHash or in a QSet, but even then i'm not 
sure it is wise that all QVariant of the same type map to the "same" value.

So let's be pragmatic here and do something usefull rather than something 
methematicaly correct, but useless and that break lot of code.


> 
> > But indeed. Forcing all that types into a single equivalency class feels
> > that unnatural, that users should notice that issue much quicker, than if
> > we'd return false.
> > 
> > Would that be sufficient to warn Qt users, or would we also have to print
> > a warning?
> 
> I don't have an opinion on that.
> 



Now that we have C++11 and we can use some expression SFINAE, we can do 
something like:

  
  template
  auto registerEqualityOperator() 
-> decltype(std::declval() == std::declval()) 

Called from qRegisterMetaType, which automatically register the operator== if 
it exists.
  

The QVariant::operator==  could return false if none was registered. And 
possibly print a qWarning: "Attempting to compare two QVariant containing type 
'Foo' which has no equality operation registered".


-- 
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

[Development] First Qt 5.8.0 Beta snapshot available

[Jani Heikkinen]

Hi,


We have finally first Qt 5.8.0 beta snapshot available

Windows: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/570/

Mac: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/439/

src: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/latest_src/


Linux ones are there as well but those don't work yet :( iOS installer is also 
missing but coming as well as MSVC2015 32 bit.


Please take a tour to see how close to beta we are. Please make sure all beta 
blockers are visible in https://bugreports.qt.io/issues/?filter=17924


br,

Jani


Jani Heikkinen
Release Manager

The Qt Company
Elektroniikkatie 13
90590 Oulu Finland
jani.heikki...@qt.io
+358 50 4873735
http://qt.io


[http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png]
[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png]
 [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] 
   
[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] 
  
[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] 
   
[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] 


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

Re: [Development] dev doesnt builds

[Martin Smith]

I did git checkout 5.8 at the qt5 level but kept my qtbase module on dev 
branch. That seems to work.


martin


From: Development  on 
behalf of Vlad Stelmahovsky 
Sent: Friday, September 23, 2016 7:00:42 AM
To: Alexander Blasche
Cc: development@qt-project.org
Subject: Re: [Development] dev doesnt builds

In my desperate attempt to build it I even re-clone whole qt5 repo from 
scratch. still doesnt works

On Thu, Sep 22, 2016 at 4:37 PM, Alexander Blasche 
> wrote:
Hi

>Cannot read .qt5/qtbase/src/corelib/qtcore-config.pri: No such file or 
>directory
>Cannot read .qt5/qtbase/src/gui/qtgui-config.pri: No such file or directory
>Project ERROR: Could not find feature system-zlib.
>Makefile:45: recipe for target 'sub-src-make_first' failed
>make[1]: *** [sub-src-make_first] Error 3
>make[1]: Leaving directory '../qt5/qtbase'
>Makefile:78: recipe for target 'module-qtbase-make_first' failed
>make: *** [module-qtbase-make_first] Error 2

>is there a workaround for this?


I had the same problem. Make sure that you have an up-to-date qt5.git checkout 
for dev as well. In combination with git clean the problem solved itself for me.

--
Alex



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