Hi Morten/Qt List
I am trying to see if I can get Qt for native client running, using the read me
in qt5/qtbase wip/nacl branch.
Tools:
OSX 10.9.5
Nacl SDK, pepper_43 version
Python 2.7.10
I have done the following
1. clone qt from git, check out 5.5 branch (not 5.5.0)
2. checkou
Can you explain what the advantage of moving it out would be?
The ibus input context was originally developed by me when we ported from Qt 4
to Qt 5. I tried to implement it with a minimum set of dependencies. It's IMO
still important to have in the qtbase tree for several reasons:
* We need at
On 2015-07-17, Takao Fujiwara wrote:
> Right. ibus-qt already has the ibus module for qt4 so this request is for qt5.
> I'd think it's easy to move libibusplatforminputcontextplugin.so from qtbase
> to ibus-qt.
Part of me would like to have as many things that uses QPA headers to
stay inside Qt
On Fri, Jul 17, 2015 at 2:13 PM, André Somers
wrote:
> Mark Gaiser schreef op 17-7-2015 om 13:44:
> >
> > You can use std::find_if for that on any container.
> > Works for C++11 and even before that. C++11 gives the benefit of using
> > a lambda in the std::find_if UnaryPredicate.
> Sure, but wou
Mark Gaiser schreef op 17-7-2015 om 13:44:
>
> You can use std::find_if for that on any container.
> Works for C++11 and even before that. C++11 gives the benefit of using
> a lambda in the std::find_if UnaryPredicate.
Sure, but wouldn't that revert you back to a linear search? That sounds
like g
On Fri, Jul 17, 2015 at 12:07 PM, André Somers
wrote:
> Marc Mutz schreef op 17-7-2015 om 12:21:
> >
> > What might also be a consideration when making a container like this, is
> > that I find the key is often (not always of course) already part of the
> > value data structure. For instance, if
On Friday 17 July 2015 12:07:22 André Somers wrote:
> Marc Mutz schreef op 17-7-2015 om 12:21:
> > What might also be a consideration when making a container like this, is
> > that I find the key is often (not always of course) already part of the
> > value data structure. For instance, if I store
Marc Mutz schreef op 17-7-2015 om 12:21:
>
> What might also be a consideration when making a container like this, is
> that I find the key is often (not always of course) already part of the
> value data structure. For instance, if I store employee records and key
> them by id, that id is also in
On Friday 17 July 2015 11:18:06 Marc Mutz wrote:
> On Friday 17 July 2015 11:00:49 Marc Mutz wrote:
> [...]
>
> > I've attached my local version, which includes some Qt containers.
>
> [...]
>
> That version was some bitrot. Here's the one that works. It also varies the
> number of duplicates to
On Friday 17 July 2015 11:02:08 André Somers wrote:
> Marc Mutz schreef op 17-7-2015 om 11:09:
> > On Thursday 16 July 2015 23:09:55 Gunnar Roth wrote:
> >>> About QFastHash: that is WIP. It's the very rudimentary beginnings of
> >>> an open- addressing hash container (a hash container using consec
On 17 July 2015 at 11:02, André Somers wrote:
>> But I separated key and values into different containers, so even at optimum,
>> you get two cache hits instead of one with QHash. As Ossi pointed out in the
>> review, that's probably a pessimisation unless you have a very loaded
>> container. Like
Marc Mutz schreef op 17-7-2015 om 11:09:
> On Thursday 16 July 2015 23:09:55 Gunnar Roth wrote:
>>> About QFastHash: that is WIP. It's the very rudimentary beginnings of an
>>> open- addressing hash container (a hash container using consecutive
>>> memory, not nodes).
>>>
>>>
>> What was the idea b
On Friday 17 July 2015 11:00:49 Marc Mutz wrote:
[...]
> I've attached my local version, which includes some Qt containers.
[...]
That version was some bitrot. Here's the one that works. It also varies the
number of duplicates to be removed.
This kind of benchmark, together with a nice visualisa
On Thursday 16 July 2015 23:09:55 Gunnar Roth wrote:
> > About QFastHash: that is WIP. It's the very rudimentary beginnings of an
> > open- addressing hash container (a hash container using consecutive
> > memory, not nodes).
> >
> >
>
> What was the idea behind it? Is so much slower than any oth
On Thursday 16 July 2015 23:09:55 Gunnar Roth wrote:
> So I deduce from this test that for a container with up to 100 elements ,
> std::vector is the best choice , if you want fastest lookup, but Vector
> should be avoided. For larger container QHash should be used for best
> lookup performance.
I
15 matches
Mail list logo
