On segunda-feira, 26 de setembro de 2016 09:03:12 PDT Jani Heikkinen wrote:
> Arg, some error when copying submodule src packages. New try ongoing, should
> be there later today
Thanks. I've now attempted a build on my Mac to check if the issue I've been
having was related to my sources or not.
On segunda-feira, 26 de setembro de 2016 10:39:51 PDT Konstantin Tokarev
wrote:
> 26.09.2016, 10:15, "Thiago Macieira" :
> > On segunda-feira, 26 de setembro de 2016 00:42:12 PDT Konstantin Tokarev
> >
> > wrote:
> >> Option 3: restore documentation of version 12 and declare that it's the
> >> o
On segunda-feira, 26 de setembro de 2016 09:57:27 PDT Jędrzej Nowacki wrote:
> No. I think we should avoid it, there are to many side effects of such
> behavior change.
Ok, I will restore the original patch that keeps the fuzzy comparison, just
skips it for NaN and infinite.
--
Thiago Macieira
On segunda-feira, 26 de setembro de 2016 09:31:34 PDT Simon Hausmann wrote:
> That said, this is not quite the same as changing the return type of a typed
> C++ function. QVariant is designed
> to hold any type and if you receive a QVariant it has always been a little
> dangerous to rely on specifi
On segunda-feira, 26 de setembro de 2016 12:00:46 PDT Stottlemyer, Brett
(B.S.) wrote:
> Not really sure which reply to respond to with my thoughts, so I’m going
> back to the beginning.
> When you talk about documenting QDataStream, you are talking about using it
> with IPC, either to other pro
On segunda-feira, 26 de setembro de 2016 10:53:51 PDT Richard Moore wrote:
> On 26 September 2016 at 10:38, Giuseppe D'Angelo
> wrote:
> > Il 25/09/2016 05:58, Thiago Macieira ha scritto:
> > anyhow). Plus, the mere existence of that page means that someone is
> > relying on the binary format.
>
On segunda-feira, 26 de setembro de 2016 10:29:07 PDT Shawn Rutledge wrote:
> On Sep 26, 2016, at 11:34, Simon Hausmann
> mailto:simon.hausm...@qt.io>> wrote:
>
> Hi,
>
> I'm very much in favor of using a proper schema based system such as
> protocol buffers if we decide to remove the black box f
On segunda-feira, 26 de setembro de 2016 10:40:02 PDT Michael Winkelmann
wrote:
> I think what Qt is lacking is a good serialization module like cereal or
> boost serialization.
> With this pattern, QDataStream would be just another archive format,
> like JSON or XML.
> Cereal has portable and unp
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
>> fa
On tirsdag 13. september 2016 08.25.10 CEST Jędrzej Nowacki wrote:
> On fredag 19. august 2016 08.52.59 CEST Jędrzej Nowacki wrote:
> > On torsdag 18. august 2016 17.46.41 CEST Dominik Holland wrote:
> > > How are the dependencies managed for projects/modules which are not part
> > > of the qt5.git
Da: Oswald Buddenhagen
A: development@qt-project.org
Inviato: Lunedì 26 Settembre 2016 11:38
Oggetto: Re: [Development] First Qt 5.8.0 Beta snapshot available
>> On Sat, Sep 24, 2016 at 10:01:36AM +, Massimo Callegari via Development
>> wrote:
>> macx:QT_CONFIG -= no-pkg-config
>> CONFIG
On 9/24/16, 11:58 PM, "Development on behalf of Thiago Macieira"
wrote:
>A thread[1] on the interest mailing list started when someone asked for the
>docs for the current format of the QDataStream wire protocol, to which I
>replied that it doesn't exist as we don't maintain such docs.
Not r
26.09.2016, 13:29, "Shawn Rutledge" :
> On Sep 26, 2016, at 11:34, Simon Hausmann wrote:
>
>> Hi,
>>
>> I'm very much in favor of using a proper schema based system such as
>> protocol buffers if we decide
>> to remove the black box from serialization. They don't appear to be
>> connected, but
Hi,
What about Option 3 :) ?
Use another binary format for serialization: flatbuffers [1] which is super
fast, has a stable binary format and can be used by lots of other languages
[2].
Cheers,
BogDan.
P.S. On my personal fork [3] I even added Qt support, and it can be used from
QML as well ;
On Sep 26, 2016, at 11:34, Simon Hausmann
mailto:simon.hausm...@qt.io>> wrote:
Hi,
I'm very much in favor of using a proper schema based system such as protocol
buffers if we decide
to remove the black box from serialization. They don't appear to be connected,
but the moment you
need to deal
On 26 September 2016 at 10:38, Giuseppe D'Angelo
wrote:
> Il 25/09/2016 05:58, Thiago Macieira ha scritto:
> anyhow). Plus, the mere existence of that page means that someone is
> relying on the binary format.
>
IIRC it was added to allow DCOP to be used in non-Qt contexts.
Rich.
On Mon, Sep 26, 2016 at 10:13:02AM +0200, Marc Mutz wrote:
> What am I missing?
>
the preceding discussions on these lists.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
26.09.2016, 12:35, "Simon Hausmann" :
> Hi,
>
> I'm very much in favor of using a proper schema based system such as protocol
> buffers if we decide
>
> to remove the black box from serialization. They don't appear to be
> connected, but the moment you
>
> need to deal with changes in the forma
Il 25/09/2016 05:58, Thiago Macieira ha scritto:
>
> Option 2: the opposite, saying that reading QDataStream's output is fine from
> non-Qt code and it's fine to write data that QDataStream should read. This
> means extending the documentation to cover ALL 17 wire formats (including
> bugs) and
On Sat, Sep 24, 2016 at 10:01:36AM +, Massimo Callegari via Development
wrote:
> macx:QT_CONFIG -= no-pkg-config
> CONFIG += link_pkgconfig
> PKGCONFIG += sndfile
>
> Has been working on every 5.x release, but not on 5.8.0.
>
yes, the mechanism has changed. QT_CONFIG was never a user-w
Hi,
I'm very much in favor of using a proper schema based system such as protocol
buffers if we decide
to remove the black box from serialization. They don't appear to be connected,
but the moment you
need to deal with changes in the format, the protobuf approach wins IMO. The
other advantag
Hi,
I'm somewhat torn about the behavioral change. One the one hand it's the
"correct" thing to do,
on the other hand it does have the potential of breaking existing code.
That said, this is not quite the same as changing the return type of a typed
C++ function. QVariant is designed
to hold
On Freitag, 23. September 2016 19:45:18 CEST André Pönitz wrote:
> 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
Arg, some error when copying submodule src packages. New try ongoing, should be
there later today
br,
Jani
From: Development on
behalf of Thiago Macieira
Sent: Friday, September 23, 2016 5:50 PM
To: development@qt-project.org
Subject: Re: [Development] Firs
On 09/26/2016 10:40 AM, Michael Winkelmann wrote:
I think what Qt is lacking is a good serialization module like cereal or
boost serialization.
With this pattern, QDataStream would be just another archive format,
like JSON or XML.
Cereal has portable and unportable binary for endianness.
Btw, Q
I think what Qt is lacking is a good serialization module like cereal or
boost serialization.
With this pattern, QDataStream would be just another archive format,
like JSON or XML.
Cereal has portable and unportable binary for endianness.
The developer should be able specify how the data is serial
On Monday 26 September 2016 10:11:09 Ulf Hermann wrote:
> This doesn't change the implicit conversion problem that Marc mentioned,
> but at the moment I don't quite see a way to fix it without removing a lot
> of convenience for the user (that is, have the user specify the exact
> intended type for
On Montag, 26. September 2016 09:55:13 CEST Jędrzej Nowacki wrote:
> On fredag 23. september 2016 11.22.08 CEST Olivier Goffart wrote:
> > template
> > auto registerEqualityOperator()
> >
> > -> decltype(std::declval() == std::declval())
>
> I have tried it already. Sadly it bre
On 09/25/2016 05:58 AM, Thiago Macieira wrote:
A thread[1] on the interest mailing list started when someone asked for the
docs for the current format of the QDataStream wire protocol, to which I
replied that it doesn't exist as we don't maintain such docs.
Long story short, we have two options:
Hi,
On Monday 26 September 2016 09:54:23 Jani Heikkinen wrote:
> And as usual there is time to
> finalize ongoing ones in '5.7' branch; final downmerge from '5.7' to
> '5.7.1' will be done after a week.
I'd like to confess that I have no idea what that usual one-week hiatus of the
5.X branch is
On mandag 19. september 2016 09.20.48 CEST 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?
>
>
On fredag 23. september 2016 11.22.08 CEST Olivier Goffart wrote:
> template
> auto registerEqualityOperator()
> -> decltype(std::declval() == std::declval())
I have tried it already. Sadly it breaks terribly in case of private/protected
operators. It doesn't solve the problem,
Hi all,
We have now created '5.7.1' branch for Qt 5.7.1 release. Please start using it
for changes targeted to Qt 5.7.1 release. And as usual there is time to
finalize ongoing ones in '5.7' branch; final downmerge from '5.7' to '5.7.1'
will be done after a week.
br,
Jani
Jani Heikkinen
Re
On Sunday 25 September 2016 19:40:06 Thiago Macieira wrote:
> But that brings us to QDataStream's biggest advantage: the wealth of
> available operator<<.
Which is also one of its major drawbacks: Streaming out may invoke any
implicit conversions, and while the worst of these are probably caught
26.09.2016, 10:15, "Thiago Macieira" :
> On segunda-feira, 26 de setembro de 2016 00:42:12 PDT Konstantin Tokarev
> wrote:
>> Option 3: restore documentation of version 12 and declare that it's the only
>> format version that is meant for use with 3rd party encoders and decoders.
>
> Why 12? It
On segunda-feira, 26 de setembro de 2016 09:02:58 PDT Jędrzej Nowacki wrote:
> On mandag 19. september 2016 11.14.51 CEST Chris Adams wrote:
> > Hi,
> >
> > Recently, a few unit test failures[1] in the (unreleased) QtPIM module
> > showed that the recent change[2] which changes the semantics of nu
On segunda-feira, 26 de setembro de 2016 06:59:01 PDT Martin Smith wrote:
> Do we need a way to tie A specific qdoc comment to the result of a specific
> autotest?
I don't think we need to go that far.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source T
On segunda-feira, 26 de setembro de 2016 00:42:12 PDT Konstantin Tokarev
wrote:
> Option 3: restore documentation of version 12 and declare that it's the only
> format version that is meant for use with 3rd party encoders and decoders.
Why 12? It can't transmit QDateTime timezones.
--
Thiago Ma
On segunda-feira, 26 de setembro de 2016 00:12:13 PDT Konstantin Tokarev
wrote:
> In case you are going to implement CBOR from scratch, please support string
> reference extension [1] which is needed to encode repeating strings (most
> importantly, data keys) efficiently.
Please create a feature
On mandag 19. september 2016 11.14.51 CEST Chris Adams wrote:
> Hi,
>
> Recently, a few unit test failures[1] in the (unreleased) QtPIM module
> showed that the recent change[2] which changes the semantics of null
> assignment (from JS) to a QVariant Q_PROPERTY can affect existing client
> code.
>
Hi,
This initiative is much appreciated, thank you Louai!
Having been in the session at QtCon, I don't have any problems with the
proposed format and process as outlined in the initial QUIPS.
I'd like to request two QUIP numbers "Qt Community Code of Conduct", and
another one for "Code of Condu
41 matches
Mail list logo