Re: [Development] QML engine changes
Hi, Does that include to get rid of v8 as an JS engine option for QML2? I have not tested it yet, but it would be interesting to know if the new engine also uses just in time compilation, as we had quite some work done to get v8 running on WinCE due to wrong ARM abis for Windows CE among other things. Best regards Björn Breitmeyer Am Montag, 24. Juni 2013, 10:26:33 schrieb Simon Hausmann: Hi, As you may have heard (or read), Lars, Erik and I have been working on some bigger changes for qtdeclarative for a while. In a nutshell we've replaced the V8 JavaScript engine with a new engine that we wrote (based on work by Roberto and Aaron). We've progressed rather well and in our wip/v4 branch in qtdeclarative we're now passing all auto tests (as well as the ECMAScript 262 test suite). So that's why we'd like to propose merging this work into qtdeclarative mainline (dev branch), in the coming days/week(s) - in time for Qt 5.2 though. We think that this work brings in many advantages, among others much improved maintenance (we know how this thing works, which isn't something we can confidently say about V8 as much as we'd like to), a unified code path in QML [1], much less code overall and great opportunities for optimizations (way beyond what's possible with V8's API layer - you'd be surprised how often even in today's QML usage the V8 code path is not actually taken because it's slower that the built-in interpreter). So this is a heads-up and of course a last call for objections :) Simon [1] Did you know what when you read a URL property in QML binding expressions, sometimes it's a string and sometimes it's an opaque variant? That's because the builtin interpreter in qtdeclarative and V8 behave different. We're fixing that :) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com -- Björn Breitmeyer | bjoern.breitme...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Germany: +49-30-521325470, Sweden (HQ): +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML engine changes
Hi, This is really exciting news! Good stuff! Hi, Does that include to get rid of v8 as an JS engine option for QML2? Yes, that's exactly the proposed change. I have not tested it yet, but it would be interesting to know if the new engine also uses just in time compilation, as we had quite some work done to get v8 running on WinCE due to wrong ARM abis for Windows CE among other things. Yes it does just-in-time compilation and will require most probably some changes to work under Windows CE. (but it should be less than the changes require for V8, if my memory of the v8 changes serves me right) Is there an interpreter only (no JIT) compile-time option? Presumably that's required for iOS adoption, for example? I wonder how much performance delta there is between JIT and pure interpretted, with a tight enough interpreter loop, if you make some simplifying assumptions (eg, types can't change at runtime / enforce no property deletion or dynamic property addition to objects or prototypes / disallow eval()). Of course, some of those limitations would no doubt break existing client code, but I personally think that weak typing is the major negative of JavaScript :-/ Hi, As you may have heard (or read), Lars, Erik and I have been working on some bigger changes for qtdeclarative for a while. In a nutshell we've replaced the V8 JavaScript engine with a new engine that we wrote (based on work by Roberto and Aaron). We've progressed rather well and in our wip/v4 branch in qtdeclarative we're now passing all auto tests (as well as the ECMAScript 262 test suite). So that's why we'd like to propose merging this work into qtdeclarative mainline (dev branch), in the coming days/week(s) - in time for Qt 5.2 though. This confuses me a bit. Why isn't the implementation tuned specifically for QML, instead of being a fully-compliant ecmascript implementation? There are currently some problems with using 3rd party JS libraries in QML applications, simply because the environment doesn't have the stuff usually supplied by the browser (and the difficulties in injecting properties in the context at import time), so I don't know how many people actually use eval() in their QML code, for example. And I think some extremely impressive performance improvements could be gained by integrating more tightly with the QML engine. Something Aaron mentioned to me a little while ago, is the possibility of doing a two-stage binding generation (it's not too clean, but it's extremely impressive): build pre-optimized binaries; run the application on device; application emits the IR for the bindings during first time evaluation, back to QtCreator; collect the IR and do a reverse transform into C++ code; generate optimized binaries. All of the type information is generated/known at the time the IR is generated, so there shouldn't be any problems compiling the resultant reverse transform; you end up with super-fast bindings implementation, and no JIT required in the final binaries. If any bindings change at runtime, just use an interpreter to evaluate the expression. Of course there are issues (dynamically load QML resources from the web, for example, might result in different bindings at runtime) and I may have misunderstood some vital elements of the concept when Aaron explained it to me, but it seems like a really interesting area of research. In general, I think there's a lot of scope for improving the tooling around QML, but I guess that's no surprise to anyone. We think that this work brings in many advantages, among others much improved maintenance (we know how this thing works, which isn't something we can confidently say about V8 as much as we'd like to), a unified code path in QML [1], much less code overall and great opportunities for optimizations (way beyond what's possible with V8's API layer - you'd be surprised how often even in today's QML usage the V8 code path is not actually taken because it's slower that the built-in interpreter). So this is a heads-up and of course a last call for objections :) Simon [1] Did you know what when you read a URL property in QML binding expressions, sometimes it's a string and sometimes it's an opaque variant? That's because the builtin interpreter in qtdeclarative and V8 behave different. We're fixing that :) Hehe. At one stage there were three separate jsValueToMetatype() conversion functions in the codebase o_O. Anyway, I'm really excited about this change. Congrats and thanks to Erik, Lars and yourself for your impressive work! Cheers, Chris. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML engine changes
Simon sayeth: snip, proposed integration of new QML Engine replacing V8 Chris replied: This is really exciting news! Good stuff! +1 I wonder how much performance delta there is between JIT and pure interpretted, with a tight enough interpreter loop, if you make some simplifying assumptions (eg, types can't change at runtime / enforce no property deletion or dynamic property addition to objects or prototypes / disallow eval()). snip, +1, I'm very interested in this QML-engine integration beyond what was possible with V8: *- Strong type safety *- Optimizations (e.g., object-paths) *- more/better JIT options *- more/better bytecode/packaging/deployment options *- more/better future QML tooling (e.g., runtime debugging/inspection around the QML-engine) Chris: snip,, but I personally think that weak typing is the major negative of JavaScript :-/ +1 Simon: I'm also not sure yet about the exact difference between JIT and interpreter, but type propagation is something that Erik has been working on, based on the assumption that while JS is untyped, QML is in fact strongly typed. That is one of those areas with a huge potential. +1 Simon: Roberto and Aaron). We've progressed rather well and in our wip/v4 branch in qtdeclarative we're now passing all auto tests (as well as the ECMAScript 262 test suite). So that's why we'd like to propose merging this work into qtdeclarative mainline (dev branch), in the coming days/week(s) in time for Qt 5.2 though. Chris: This confuses me a bit. Why isn't the implementation tuned specifically for QML, instead of being a fully-compliant ecmascript implementation? Simon: Because we want to continue to support the use-case of import Foo.js as Bar; I've personally used that for a little spare time app I wrote, when I was super happy to discover that a piece of functionality I needed was available as third-party JS library that I could just exclude. But spec compliance does not imply tuning, and indeed I think generally any optimization we do will most likely be geared towards QML, as long as it doesn't pessimize the regular JS execution. Ok, that makes sense, so I won't argue against it. However, I agree with Chris that ecmascript compliance isn't a big wish/need/goal for me. I'd prefer to give (design) priorities to: *- strong typing *- (tight) QML-engine integration with running system (e.g., internal QML runtime system with bindings is quite different than the mechanisms intended by an ECMA-script engine) *- performance (e.g, byte-code, JIT, optimized object-paths) *- deployment/packaging options (e.g., binary byte-code) And, of course, I totally applaud the removal of eval() and other runtime code issues that block iOS deployment (I'm not targeting that platform, I just agree with Apple's complaint about embedding V8, and don't want opportunities for malicious injection in my systems). Chris: And I think some extremely impressive performance improvements could be gained by integrating more tightly with the QML engine. Simon: Absolutely, that remains a goal (tight integration). +1, I support this direction. Chris: Something Aaron mentioned to me a little while ago, is the possibility of doing a two-stage binding generation (it's not too clean, but it's extremely impressive): build pre-optimized binaries; run the application on device; application emits the IR for the bindings during first time evaluation, back to QtCreator; collect the IR and do a reverse transform into C++ code; generate optimized binaries. All of the type information is generated/known at the time the IR is generated, so there shouldn't be any problems compiling the resultant reverse transform; you end up with super-fast bindings implementation, and no JIT required in the final binaries. If any bindings change at runtime, just use an interpreter to evaluate the expression. Simon: That's an interesting idea! Whoa... THAT'S COOL. I'm very interested in more on this. Please feel free to share thoughts on this topic or other experimentation along these lines. (This could be *extremely* useful; I could see tooling be put in-place to simplify/automate this process.) So this is a heads-up and of course a last call for objections :) No objection -- :/me strong supporter! Chris: Anyway, I'm really excited about this change. Congrats and thanks to Erik, Lars and yourself for your impressive work! +1 -charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML engine changes
[Upfront: I am _really_ happy to see V8 and the glue code its service required to be on its way out. But...] On Mon, Jun 24, 2013 at 01:30:18PM +0200, Simon Hausmann wrote: This confuses me a bit. Why isn't the implementation tuned specifically for QML, instead of being a fully-compliant ecmascript implementation? Because we want to continue to support the use-case of import Foo.js as Bar; I've personally used that for a little spare time app I wrote, when I was super happy to discover that a piece of functionality I needed was available as third-party JS library that I could just exclude. [...] This still somewhat leaves the questions why that use case is so important that it justifies the hoops that need to be jumped through to make it happen (especially at the expense of more common uses that typically do not go much beyond arithmetic expressions and an 'if', or an occasional loop), and why 100% ECMA conformance for chunks of code that typically span not more than half a line is useful if the full file isn't conforming to any standard anyway. The obvious alternative would be to leave full ECMA to separate .js files (and do whatever needs to be done to make that work) and use inside .qml only the parts that are typically used in that context, perhaps garnished by some syntactic sugar to reduce boiler plate, and maybe restricted to the cases that are easily toolable - i.e. a real Domain Specific Language addressing exactly the task at hand. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Documentation discoverability in Google
On segunda-feira, 24 de junho de 2013 15.50.17, Knoll Lars wrote: On 6/24/13 5:32 PM, Giuseppe D'Angelo dange...@gmail.com wrote: On 24 June 2013 17:20, Markus Goetz mar...@woboq.com wrote: Hi, I remember that gooling for QWidget or QNetworkAccessManager gave you the documentation page (usually of the latest Qt release) as a first hit. This is not the case anymore, I'm getting an outdated MeeGo Harmattan 4.7 result or Blackberry docs now as the first results. One way to fix this would probably be if qt.nokia.com/doc and doc.trolltech.com would not be blindly forwarded to qt.digia.com but take the 'path' part of the requested URL and also append that on the forward to qt-project.org/doc. Then google would forward that old link juice and the correct Qt documentation could be the first result..) That's more or less what I proposed to do in https://bugreports.qt-project.org/browse/QTWEBSITE-504 , but I don't know the control we have on qt.nokia.com / doc.trolltech.com domains... Unfortunately I don't think we have any control on them :/ Do we need to? $ curl -s -D - http://doc.qt.nokia.com/foobar.html | grep Location: Location: http://doc.qt.digia.com/foobar.html $ curl -v -s -D - http://doc.trolltech.com/foobar.html * About to connect() to doc.trolltech.com port 80 (#0) * Trying 87.238.50.204... No route to host It would be nice if the Digia domain redirected to the official docs in qt- project.org/doc. And as a side note, any chance we can get an automatic search-and-redirect too? If I use qt:qstring in KDE, I get sent to http://qt-project.org/doc/qt-5.0/qtdoc/index.html The old TT webpage suggested pages if I had misspelt anything. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt5.1 snapshot available
Good morning, There is again new snapshot(2013-06-25-65/) available in http://download.qt-project.org/snapshots/qt/5.1/5.1.0-rc2/backups/. It is already quite near of rc2 but some changes are still missing. Below is listed new changes since my previous mail: Qtsdk: ·Fix warnings during installation, QTBUG-31955http://build.it.local/project/jiraRedirect.action?jiraIssueKey=QTBUG-31955bambooProjectKey=DQTC ·mkqt5bld: qtquickcontrols added to essentials list, QTBUG-31718http://build.it.local/project/jiraRedirect.action?jiraIssueKey=QTBUG-31718bambooProjectKey=DQTC ·Fix path for MaintenanceTool links * Make sure that createShortcuts() function is not global, QTIFW-294https://bugreports.qt-project.org/browse/QTIFW-294 * Add -no-c++11 to Mac configure options Qt5 ·configure: Fix srcpath when you run configure in the top-level dir ·rewrite top-level configures without perl, QTBUG-31786http://build.it.local/project/jiraRedirect.action?jiraIssueKey=QTBUG-31786bambooProjectKey=DQTC qt-creator: ·Fix broken list requests in CodePaster, QTCREATORBUG-9547http://build.it.local/project/jiraRedirect.action?jiraIssueKey=QTCREATORBUG-9547bambooProjectKey=DQTC Br, Jani From: Heikkinen Jani Sent: 20. kesäkuuta 2013 12:58 To: development@qt-project.org; releas...@qt-project.org Subject: New Qt5.1 snapshot available Hi all, There is new snapshot available after RC1. Unfortunately there is problems in the Linux builds and that's why only Windows Mac offline installers are available. Fixing is ongoing, let's hope we can have all installers available tomorrow! You can download newest installers from http://download.qt-project.org/snapshots/qt/5.1/5.1.0-rc1/backups/ Below is listed changes included since RC1: Qtsdk: ·QTBUG-29802: Make database plug-ins/derivers avaliable by default ·QTBUG-28963: cannot unmount DMG after installing Qt OSX package and starting creator ·Update installer graphics ·Do not mention SDK in user visible installer texts ·Change Qt as a name of the Name field in online installer qt-creator · QTCREATORBUG-9558http://build.it.local/project/jiraRedirect.action?jiraIssueKey=QTCREATORBUG-9558bambooProjectKey=DQTC ·AndroidRunner: Fix CheckPidTimer to not fire forever qtbase: ·Android Mute and FastForward keys mapped wrong ·make Makefiles not depend on .qmake.super ·QTBUG-31289 fix rcc uic .depend_commands ·always $-escape make commands ·QTBUG-31289 fix command over-escaping in vcproj files ·assemble the tool commands at use time, after all ·QTBUG-31750 OSX: Disable window restoration for the Mac color panel ·QTBUG-29161 Cocoa color dialog cannot be modal, but should show anyway ·QTBUG-31566 OSX color dialog can be accepted repeatedly ·QTBUG-31667 network requests: do not access 1st byte of empty byte array ·QTBUG-31745 Doc: Remove Tweet Search demo from the list of highlighted examples ·Adjust the cmake files to find the dlls in the bin dir. · qtdeclarative: ·QTBUG-31699 photosurface demo: behavior depends on initialization order ·stabilize tst_touchmouse. ·QFileDialogHelper: Force QWindow before setting flags. qtdoc: ·Doc: Added a link to Qt Quick Controls Overview ·QTBUG-31737 Document the deprecation of WFlags Qtmultimedia: ·Android: Fix for uncaught java exception. ·Fix for url bug in the qmlvideo examples. Qtquickcontrols: ·QTBUG-31778 Doc: Fix QCH documentation structure for Qt Quick Layouts ·Revert Add qml/js files in resource files ·Doc: Fixed Qt Quick Layouts listing in qch files. ·QTBUG-31565 Add qml/js files in resource files qttools ·QTBUG-31153 Find the cmake version template in the install location. Qttranslations ·QTBUG-31727 fix qm output dir for non-prefix builds Qtwebkit ·[Qt][Mac] Disable QTKit video on OS X. Br, Jani ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
