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
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
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 simp
On Monday 19 September 2016, Thiago Macieira wrote:
> On segunda-feira, 19 de setembro de 2016 21:21:01 PDT André Pönitz wrote:
> > On Mon, Sep 19, 2016 at 11:10:51AM -0700, Thiago Macieira wrote:
> > > Since this is a P3 and 5.8 hasn't been released, I will push the
> > > behaviour change to 5.8 a
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 func
On segunda-feira, 19 de setembro de 2016 21:21:01 PDT André Pönitz wrote:
> On Mon, Sep 19, 2016 at 11:10:51AM -0700, 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.
https://codereview.qt-project
On Mon, Sep 19, 2016 at 11:10:51AM -0700, Thiago Macieira wrote:
> On segunda-feira, 19 de setembro de 2016 19:47:12 PDT André Pönitz wrote:
> > On Mon, Sep 19, 2016 at 09:20:48AM -0700, Thiago Macieira wrote:
> > > This code was there in Qt 5.0, so I kept it when I refactored the numeric
> > > com
On segunda-feira, 19 de setembro de 2016 19:47:12 PDT André Pönitz wrote:
> On Mon, Sep 19, 2016 at 09:20:48AM -0700, Thiago Macieira wrote:
> > This code was there in Qt 5.0, so I kept it when I refactored the numeric
> > comparisons. Now, dealing with QTBUG-56073, I'm wondering if it should be
>
On Mon, Sep 19, 2016 at 06:48:10PM +0200, Marc Mutz wrote:
> Fuzzy comparision should be performed with a named function, qFuzzyCompare,
> and _only_ with that function.
+1.
> We need to fix other classes for Qt 6, too (e.g. Q(Size|Point|Line)F.
+1.
> That said, a qFuzzyCompare(QVariant, QVar
On Mon, Sep 19, 2016 at 09:20:48AM -0700, Thiago Macieira wrote:
> This code was there in Qt 5.0, so I kept it when I refactored the numeric
> comparisons. Now, dealing with QTBUG-56073, I'm wondering if it should be
> there in the first place.
>
> Should we do fuzzy comparisns in QVariant?
No.
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.
Fuzzy comparision should be performed with a named function, qF
This code was there in Qt 5.0, so I kept it when I refactored the numeric
comparisons. Now, dealing with QTBUG-56073, I'm wondering if it should be
there in the first place.
Should we do fuzzy comparisns in QVariant?
Note that the fuzzy comparisons are always performed in qreal precision
(whic
19.09.2016, 19:06, "Thiago Macieira" :
> On segunda-feira, 19 de setembro de 2016 17:58:22 PDT Kevin Kofler wrote:
>> Louai Al-Khanji wrote:
>> > From a quick look it seems to be mostly well written. I do wonder whether
>> > it might be better to use a tool other than ldd to find the library
>
On segunda-feira, 19 de setembro de 2016 17:58:22 PDT Kevin Kofler wrote:
> Louai Al-Khanji wrote:
> > From a quick look it seems to be mostly well written. I do wonder whether
> > it might be better to use a tool other than ldd to find the library
> > dependencies. objdump -p provides the same inf
On segunda-feira, 19 de setembro de 2016 08:42:58 PDT Thiago Macieira wrote:
> On segunda-feira, 19 de setembro de 2016 17:03:04 PDT Oswald Buddenhagen
>
> wrote:
> > you can hack the project file to not create a super cache and not do the
> > configuration step. this may actually work for non-pre
Louai Al-Khanji wrote:
> From a quick look it seems to be mostly well written. I do wonder whether
> it might be better to use a tool other than ldd to find the library
> dependencies. objdump -p provides the same information, and also works for
> cross-compiles.
It's not the same thing, ldd is tr
On segunda-feira, 19 de setembro de 2016 14:45:14 PDT Louai Al-Khanji wrote:
> From a quick look it seems to be mostly well written. I do wonder whether it
> might be better to use a tool other than ldd to find the library
> dependencies. objdump -p provides the same information, and also works for
On segunda-feira, 19 de setembro de 2016 17:03:04 PDT Oswald Buddenhagen
wrote:
> you can hack the project file to not create a super cache and not do the
> configuration step. this may actually work for non-prefix builds.
Will do.
Do not expect any buildsystem contribution from me from this poi
Dear QT developers,
We have undertaken a task to assess code complexity triggers and generate
recommendations for developing simple and understandable code. Our intension is
to share the results with you, developers, so everyone can learn the triggers
behind complex software.
We need your
On Sun, Sep 18, 2016 at 06:12:17PM -0700, Thiago Macieira wrote:
> On segunda-feira, 19 de setembro de 2016 00:22:42 PDT Jake Petroules wrote:
> > > It's worked for over 4 years. I may not be the only one doing this.
> > >
> > > Please fix it.
> >
> > I don't see why we should, it seems an illogi
Hi Simon,
Nice! Looks like a good start. It’s something that’s definitely missing at the
moment.
You would likely get more people looking at it if you moved it over to Qt Code
Review. Looking at the license headers, it looks like it is your intent that
this could become part of Qt, and for tha
Can you please move this OT discussion to SG-14
(https://groups.google.com/a/isocpp.org/forum/#!forum/sg14), where it belongs?
Thanks,
Marc
On Friday 16 September 2016 22:43:39 Matthew Woehlke wrote:
> I will never, *ever* replace the PRNG shown with a high quality
> generator. The use case for
On 19/09/16 08:06, "Development on behalf of Holger Freyther"
wrote:
>
>> On 19 Sep 2016, at 03:12, Thiago Macieira wrote:
>>
>>
>
>Good Morning,
>
>
>> And, like I said, others may have done the same. See the discussion on the
>> Coverity issue.
>>
>> Please fix.
>
>as Thiago has indicate
23 matches
Mail list logo
