Re: [Development] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO
On Fri, Jul 17, 2015 at 12:07 PM, André Somers an...@familiesomers.nl 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 employee records and key them by id, that id is also in the record itself. It would be nice to have a fast and friendly key-based container that could handle that without duplicating the data... You can have that with C++11 std::*set, and a custom transparent comparator, but of course, they are not cache-friendly. But it's testament to the value of having the ability to _have_ a custom comparator. QFashHash consequently has that ability, but its a map, not a set, so it won't fit your use-case. I guess this [1] would work, but that is C++14, not 11. Otherwise, I don't quite see how to retreive my Employee record again if I just have the id... André [1] http://en.cppreference.com/w/cpp/container/set/find variants 3 and 4 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO
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 getting the worst of both worlds: using a complicated red/black tree data structure and then iterating over it lineary to find an item that I could have found using the structure itself in logarithmic time... Or am I overlooking some very clever specialization in the find_if algorithm then? André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO
On Fri, Jul 17, 2015 at 2:13 PM, André Somers an...@familiesomers.nl 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 wouldn't that revert you back to a linear search? That sounds like getting the worst of both worlds: using a complicated red/black tree data structure and then iterating over it lineary to find an item that I could have found using the structure itself in logarithmic time... Or am I overlooking some very clever specialization in the find_if algorithm then? André Yes, that would give you linear search indeed. Guess you have to use that C++14 function then :) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO
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. It is not surprising that big-O _eventually_ wins. The point is that that eventually != always. Few collections in Qt will have more than 100 elements, and then, not all the time. Binary search is not very cache-friendly, because it exhibits a semi-random memory access pattern that the hardware has trouble predicting. If you want to see what I and others mean when we say that the node-based containers are slow, iterate over the containers. Search in large collections is what hash tables and rb-trees are optimized for, and of course they eventually win, with ever larger collections. But most collections are also iterated over, and then you better not have a node-based container in front of you if you do. Related: there's a similar benchmark to yours, container_benchmark.cpp by Stroustrup and Stepanov, which performs duplicates removal using different containers. It hasn't been updated since 2003, but it's easy to add new tests. I already posted a link in this thread, but google will find it, too. I've attached my local version, which includes some Qt containers. Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts /* Standard Container Benchmark Version 0.9, May 23, 2003 The primary purpose of this benchmark is to show how different standard containers are in terms of performance. We have observed that programmers often use sets, multisets, deques in the situations where sorted vectors are the optimal solutions. Similarly, programmers often choose lists simply because they do a few insertions and deletions without knowing that vectors are more efficient at that for small containers. Frequently, of course, performance does not matter, but it is important that programmers are aware of the consequences of their choices. We are not saying that only vectors should be used, there are cases when one really needs a more complicated data structure, but one needs to understand the price for additional functionality. The secondary purpose of the benchmark is to encourage compiler and library vendors to keep improving performance. For example, it is not acceptable that some compilers give you a sizable penalty for using vector iterators instead of pointer. It is also quite clear that performance of other standard containers could be improved. The benchmark is doing the same task 7 times using different data structures: array, vector (using a pointer as iterator), vector (using the defailt cector iterator), list, deque, set and multiset. The task is to remove duplicates from a sequence of doubles. This is a simple test, but it illustrates the performance of containers. It is clear that the benchmark needs to be eventually extended to slists and even to hash-sets and hash-maps, but we decided that at present it should work only with the standard containers. As the standard grows, so can the benchmark. The additional benefit of not including hash based containers is that now all the test have identical asymptotic complexity and, even more importantly, do almost the same number of comparisons. The difference is only in data structure overhead and cache behavior. The number of times that a given test is run inversly proportional to NlogN where N is the size of the sequence. This allows one to see how containers of different size behave. The instructive values used for the benchmark are: 10, 100, 1000, 1, 10, 100. The time taken for a run of the benchmark depends on the machine used, the compiler used, the compiler and optimizer settings used, as well as the standard library. Please note that the time taken could be several minutes - and much more if you use a slow debug mode. The output is a table where columns are separated by tabs and rows by newlines. This is barely ok for a human reader, but ideal for feeding into a program, such as a spreadsheet for display or analysis. If you want to add your own test of a container, add the name of your container to the header string, write a test function like the existing ones, e.g. vector_test, and add a call of run for your test in run_tests. Alex Stepanov stepa...@adobe.com Bjarne Stroustrup b...@cs.tamu.edu */ #include stddef.h // some older implementations lack cstddef #include time.h #include math.h #include stdlib.h #include vector #include QVector #include algorithm #include list #include QList #include QLinkedList #include deque #include set #include iostream #include iomanip typedef double element_t; using namespace std; vectordouble
Re: [Development] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO
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 other that I can just see why anyone should want to have this? What is the advantage? The idea is to implement https://en.wikipedia.org/wiki/Open_addressing with linear probing, which theoretically should be more cache friendly than a node- based container (less memory overhead, cache-friendly probing). 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. Likewise, OptionalT, required to mark entries as empty or occupied, isn't optimized at all. all but doubling the space required for most keys because of the pairing with a bool. As I said, it's WIP. -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO
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 behind it? Is so much slower than any other that I can just see why anyone should want to have this? What is the advantage? The idea is to implement https://en.wikipedia.org/wiki/Open_addressing with linear probing, which theoretically should be more cache friendly than a node- based container (less memory overhead, cache-friendly probing). 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. Likewise, OptionalT, required to mark entries as empty or occupied, isn't optimized at all. all but doubling the space required for most keys because of the pairing with a bool. As I said, it's WIP. 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 the record itself. It would be nice to have a fast and friendly key-based container that could handle that without duplicating the data... André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO
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 consecutive memory, not nodes). What was the idea behind it? Is so much slower than any other that I can just see why anyone should want to have this? What is the advantage? The idea is to implement https://en.wikipedia.org/wiki/Open_addressing with linear probing, which theoretically should be more cache friendly than a node- based container (less memory overhead, cache-friendly probing). 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. Likewise, OptionalT, required to mark entries as empty or occupied, isn't optimized at all. all but doubling the space required for most keys because of the pairing with a bool. As I said, it's WIP. 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 the record itself. It would be nice to have a fast and friendly key-based container that could handle that without duplicating the data... You can have that with C++11 std::*set, and a custom transparent comparator, but of course, they are not cache-friendly. But it's testament to the value of having the ability to _have_ a custom comparator. QFashHash consequently has that ability, but its a map, not a set, so it won't fit your use-case. -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO
On 17 July 2015 at 11:02, André Somers an...@familiesomers.nl 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. Likewise, OptionalT, required to mark entries as empty or occupied, isn't optimized at all. all but doubling the space required for most keys because of the pairing with a bool. As I said, it's WIP. 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 the record itself. It would be nice to have a fast and friendly key-based container that could handle that without duplicating the data... Woah, a big +1 to that! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Request to delete libibusplatforminputcontextplugin.so from qtbase
On 2015-07-17, Takao Fujiwara tfuji...@redhat.com 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 because unstable api's. And then I'm not sure if there might be licensing issues for various users with moving it from lgpl Qt to GPL ibus-qt, or if enough of ibus is GPL that you can't take advantage of the l in lgpl anyways. /Sune ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO
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 be removed. The exact operation performed is sort | uniq This kind of benchmark, together with a nice visualisation, and more use- cases, is what I'd wish we had for our users. Here are the results of running it on a Core-i7 Sandy Bridge pinned at 2.4GHz, formatted as HTML. Excesss dups of 1 means no duplicates, 100 means 99% dups. It is instructive to look at the memory consumption, because the size printed is the size of the *reduced* container, so the largest container size is 100 million elements, 1% of which are unique, 99% dups. That's 800M in vector, qlist, qvector, deque, but _a lot_ more in std::list (2400M + allocator overhead, on my machine 3.8G of resident memory), set, and multiset (3200M + allocator overhead, on my machine 5.2G). Conseqently, don't run this without at least 6G of RAM or reduce the max. working set size. As you can see, the only algorithm that can hold up with std::vector+std::sort+std::uniue is QSet+QList+std::osrt, but only at very high number of duplicates (starts here for some medium sizes and 90% dups), and even at its best, it's only 3x faster than std::vector, while it can be an order of magnitude slower. I find it particularly interesting that at 100'000 elements and 99% dups, it's almost as slow as std::vector, and at 1'000'000 elements, slower again. -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts Title: Container Benchmark excess elements:1sizearrayvector with pointersvector with iteratorsqvector with pointersqvector with iteratorsdequelistqlistsetqset->qlistmultiset 100.070.070.070.110.120.180.510.140.380.710.42 1000.030.040.030.050.050.080.260.070.240.390.24 1.050.040.060.060.060.110.260.070.290.340.31 10.100.100.110.100.110.140.300.120.350.370.38 100.100.100.110.110.110.130.420.120.490.370.52 1000.100.100.100.110.110.130.590.270.840.820.93 excess elements:2sizearrayvector with pointersvector with iteratorsqvector with pointersqvector with iteratorsdequelistqlistsetqset->qlistmultiset 100.320.140.160.200.210.311.040.310.510.900.92 1000.060.070.070.100.100.160.560.140.310.490.58 1.180.180.180.200.200.290.590.240.490.450.71 10.230.220.240.240.240.300.680.260.630.430.85 100.220.220.220.230.230.291.080.260.860.431.37 1000.220.210.230.220.220.281.260.591.570.932.03 excess elements:5sizearrayvector with pointersvector with iteratorsqvector with pointersqvector with iteratorsdequelistqlistsetqset->qlistmultiset 100.700.310.320.470.460.692.510.700.791.402.65 1000.190.200.210.270.260.441.720.390.720.732.10 1.590.590.610.650.640.841.670.741.070.622.15 10.620.610.630.640.640.791.910.721.410.572.58 100.570.580.610.600.600.754.360.722.130.704.98 1000.570.590.590.600.590.733.841.643.871.136.27 excess elements:10sizearrayvector with pointersvector with iteratorsqvector with pointersqvector with iteratorsdequelistqlistsetqset->qlistmultiset 100.570.560.620.850.861.355.251.351.263.525.85 1000.480.480.670.630.631.293.930.921.661.115.03 10001.251.261.281.341.411.713.801.542.010.915.28 11.221.221.271.281.271.574.911.432.740.806.68 101.151.301.201.191.231.4810.331.484.101.1912.14 1001.161.161.201.201.191.469.123.488.251.7714.79 excess elements:20sizearrayvector with pointersvector with iteratorsqvector with pointersqvector with iteratorsdequelistqlistsetqset->qlistmultiset 101.271.241.321.821.822.9511.372.902.414.0013.50 1002.012.022.082.332.293.498.762.953.451.8911.49 10002.572.572.662.742.753.438.823.193.861.4512.25 12.402.552.672.512.503.1013.953.045.401.3118.18 102.492.322.442.572.422.9924.503.088.492.2230.31 1002.332.352.442.412.562.9319.677.2815.493.0034.36 excess elements:50sizearrayvector with pointersvector with iteratorsqvector with pointersqvector with iteratorsdequelistqlistsetqset->qlistmultiset 103.563.503.514.854.857.3132.097.836.608.5441.65 1006.616.626.697.387.319.7324.608.838.824.4333.47 10006.596.606.786.936.948.6425.688.049.392.9637.02 16.076.076.316.486.518.2055.037.2713.432.8263.57 106.236.086.316.426.438.0073.258.1820.725.9494.72 1005.855.996.246.006.157.4156.9520.3538.707.04106.47 excess elements:100sizearrayvector with pointersvector with iteratorsqvector with pointersqvector with iteratorsdequelistqlistsetqset->qlistmultiset 108.418.367.7110.6010.5817.4870.8216.3717.7816.2092.57 10014.0614.0414.3515.3615.3420.0656.3218.5217.848.4380.50 100012.7812.8013.2113.4513.4416.9062.4715.6618.655.5391.59 112.2012.1912.6212.7412.7315.81137.6014.7026.425.55162.82 1012.1012.0912.5512.4512.4615.29166.1616.0939.9611.18225.32
Re: [Development] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO
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 employee records and key them by id, that id is also in the record itself. It would be nice to have a fast and friendly key-based container that could handle that without duplicating the data... You can have that with C++11 std::*set, and a custom transparent comparator, but of course, they are not cache-friendly. But it's testament to the value of having the ability to _have_ a custom comparator. QFashHash consequently has that ability, but its a map, not a set, so it won't fit your use-case. I guess this [1] would work, but that is C++14, not 11. Otherwise, I don't quite see how to retreive my Employee record again if I just have the id... André [1] http://en.cppreference.com/w/cpp/container/set/find variants 3 and 4 Yes, I meant those. Sorry, I thought they were C++11. -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO
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 the record itself. It would be nice to have a fast and friendly key-based container that could handle that without duplicating the data... You can have that with C++11 std::*set, and a custom transparent comparator, but of course, they are not cache-friendly. But it's testament to the value of having the ability to _have_ a custom comparator. QFashHash consequently has that ability, but its a map, not a set, so it won't fit your use-case. I guess this [1] would work, but that is C++14, not 11. Otherwise, I don't quite see how to retreive my Employee record again if I just have the id... André [1] http://en.cppreference.com/w/cpp/container/set/find variants 3 and 4 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Request to delete libibusplatforminputcontextplugin.so from qtbase
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 least one input context to use and test against (on Linux) when developing Qt further. Not having the plugin in qtbase will lead to us not testing IMEs on Linux anymore, something I really want to avoid. * The license is more flexible (LGPL/commercial dual licensed) on qt-project.org, and thus more suitable for some of our commercial customers as well * As Sune said, the platform plugin headers are not stable, so having it in tree will give you a better chance of keeping things in sync with Qt releases * The IMEs for pretty much all non Linux platforms reside in qtbase. Why should we handle Linux differently (except for the fact that there's still a multitude of IMEs on Linux :/ ) Ideally, I would prefer if things went the other way round and we would also get plugins for other popular IMEs on Linux moved into qtbase. Thanks, Lars On 17/07/15 18:26, development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of Sune Vuorela development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of nos...@vuorela.dk wrote: On 2015-07-17, Takao Fujiwara tfuji...@redhat.com 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 because unstable api's. And then I'm not sure if there might be licensing issues for various users with moving it from lgpl Qt to GPL ibus-qt, or if enough of ibus is GPL that you can't take advantage of the l in lgpl anyways. /Sune ___ 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] Qt for Native Client.
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. checkout qtbase wip/nacl branch 3. check out qtdeclarative branch 5.5 4. cherr-pick qtdeclarative commit https://codereview.qt-project.org/qt/qtdeclarative refs/changes/70/114670/1, 5. configure and build Qt, nacl-configure mac_x86_newlib release 64, used nacl_sdk/pepper_43. 6. make module-qtbase, -qtdeclarative and -qtquickcontrols, these succeed, i.e. the relevant .a library files appear in the builddir/libs folder. 7. extracted the example nacl app from https://github.com/msorvig/qt5-qtdeclarative-nacl.git, 5.4.0 branch, copied it to builddir/qtbase/example-nacl (provides the proper relative paths so libs link correctly). I uncommented the #include path for nacl in the .pro file. 8. it builds !! :) 9 Make sure to exit chrome completely, then run nacl-deployqt as follows: cd to example build dir, then run \full-path\qtbase\bin\nacldeployqt nacl.nexe --run I think the relevant error is related to accessing the time zone: [94230,2038145808:16:32:56.805674] Native Client module will be loaded at base address 0x4e8f Not implemented: getLocalTZA() Full console output appears below: $ /Users/steve/Qt/qt5-git-naclBuild/qtbase/bin/nacldeployqt nacl.nexe --run Note: qml_plugin_import.cpp file found. Auto-enabling --quick option. Deploying nacl.nexe Using SDK /projects/chrome/nacl_sdk/pepper_43 Qt libs in /Users/steve/Qt/qt5-git-naclBuild/qtbase/lib Output directory: /Users/steve/Qt/qt5-git-naclBuild/qtbase/example-nacl Serving HTTP on 0.0.0.0 port 8000 ... [94217:1287:0717/163253:ERROR:url_pattern_set.cc(240)] Invalid url pattern: chrome://print/* [94217:1287:0717/163254:ERROR:bluetooth_adapter_mac.mm(110)] Not implemented reached in virtual bool device::BluetoothAdapterMac::IsDiscoverable() const 127.0.0.1 - - [17/Jul/2015 16:32:54] GET / HTTP/1.1 200 - 127.0.0.1 - - [17/Jul/2015 16:32:54] GET /qtloader.js HTTP/1.1 200 - 127.0.0.1 - - [17/Jul/2015 16:32:54] GET /nacl.nmf HTTP/1.1 200 - 127.0.0.1 - - [17/Jul/2015 16:32:54] GET /nacl.nexe HTTP/1.1 200 - [94225:1287:0717/163255:ERROR:resource_request_policy.cc(57)] Denying load of chrome-extension://apdfllckaahabafndbhieahigkjlhalf/page_embed_script.js from hosted app. [94225:1287:0717/163256:ERROR:resource_request_policy.cc(57)] Denying load of chrome-extension://apdfllckaahabafndbhieahigkjlhalf/page_embed_script.js from hosted app. 127.0.0.1 - - [17/Jul/2015 16:32:56] code 404, message File not found 127.0.0.1 - - [17/Jul/2015 16:32:56] GET /favicon.ico HTTP/1.1 404 - [94230,2038145808:16:32:56.805674] Native Client module will be loaded at base address 0x4e8f Not implemented: getLocalTZA() 127.0.0.1 - - [17/Jul/2015 16:32:57] code 404, message File not found 127.0.0.1 - - [17/Jul/2015 16:32:57] GET /qml/QtQuick.2.1/qmldir HTTP/1.1 404 - 127.0.0.1 - - [17/Jul/2015 16:32:57] GET /qml/QtQuick.2/qmldir HTTP/1.1 200 - 127.0.0.1 - - [17/Jul/2015 16:32:57] code 404, message File not found 127.0.0.1 - - [17/Jul/2015 16:32:57] GET /qml/QtQuick/qmldir HTTP/1.1 404 - [94225:1287:0717/163303:ERROR:resource_request_policy.cc(57)] Denying load of chrome-extension://apdfllckaahabafndbhieahigkjlhalf/page_embed_script.js from hosted app. [94217:78855:0717/163305:ERROR:get_updates_processor.cc(243)] PostClientToServerMessage() failed during GetUpdates -- Message: 1 Date: Fri, 19 Jun 2015 13:44:38 + From: Sorvig Morten morten.sor...@theqtcompany.com Subject: [Development] Qt for Native Client To: development development@qt-project.org Message-ID: f303408c-187b-44b5-9864-44f24fd46...@digia.com Content-Type: text/plain; charset=utf-8 Hi, I?m happy to announce that a work-in-progress port of Qt to the Chrome / Native Client platform has now been pushed to the wip/nacl branch in QtBase. So far development has been closed, but we are now ready to develop in the open and also take contributions. My intention is to at some point merge the work, after the whip/nacl and dev branches have converged sufficiently, The main difference from other platforms is that Qt for NaCl is running in the web sandbox, which has lots of interesting implications for areas like file or network access. The port is tested with Qt Widgets and Qt Quick and supports raster and OpenGL graphics. Getting started? instructions can be found at qtbase/nacl-readme. One further patch is needed for QtDeclarative, available here: https://codereview.qt-project.org/#/c/114670/ - Morten -- ___ Development mailing list Development@qt-project.org
