Hi, Some notes from day 3. - Played with the idea of transforming QML input to JavaScript - An exercise for learning more about QML scoping rules and such - Jedrzej investigated the QML parser and wrote a visitor for dumping the AST
- Idea of 1-to-1 relationship between C++ QObject and JS wrapper - Avoids need for overloaded operator == for QML JS wrappers - Instead of always calling the native getter when reading a QML property, the JS wrapper could have a real copy of the C++ property value; the value is kept in sync whenever the property is modified - Caio continued investigating overhead of binding expressions when using QtScript - It might be a combination of things, that can be attacked separately - Kent added a section to the wiki about the process of dealing with upstream V8 bugs (also has some boiler-plate code to help with writing minimal, self-contained testcases) - http://developer.qt.nokia.com/wiki/V8_Port#137f0270c5f601d0a1d1519f92058a1a - Kent studied the QML/QtScript integration to try to get an understanding of how QML's QObject binding differs from QtScript's - Only QMetaObject-defined properties (don't care about dynamic properties and child objects) - Try to avoid performing value conversion via QVariant (i.e. don't call QMetaProperty::read() for known types) - Don't care about QScriptable - Other strange things that the QtScript binding has (thisObject-conversion, replaceable methods, moveable methods) - QML uses interceptors for handling property access, but caches the JSC::Identifier to do fast mapping from identifier to index - With V8, we should try to implement the binding using accessors only - No need for doing identifier-to-property-index caching on our side - Use Object.preventExtensions(qmlObject) to cause an exception to be thrown if someone tries to write to a non-existent property - Olivier struggled with scope chains - One of the declarativeecmascript tests assert because the QScriptContext isn't right - With JSC, QML relies on the context provided to getOwnPropertySlot() being the same as that which was previously created by pushContext() - Peter fought with QtScript/V8 build issue (private header included from public header), and V8 infinite loop issue - Zoltan investigated a test failure related to getting the exception location / line number - V8 doesn't provide the necessary information, it might be necessary to - Zoltan started looking at the possibility of using v8::ScriptData::PreCompile() to implement QScriptProgram - Zoltan noticed that some huge JavaScriptCore changes have recently landed in WebKit trunk - Local handles& handle scopes - Moving GC - Dataflow intermediate representation for use in JIT - Overall impression: JSC getting more similar to V8 :-) - Some snapshot-related stuff I forgot to mention from day 2 - V8 feature request: Being able to select the V8 snapshot at runtime - Right now the snapshot (symbols) must be linked into V8 itself, which is less flexible - We might want to have a tailored snapshot for QtScript in QML (e.g. containing extra QML-specific APIs) - Can snapshot deserialization be sped up? (To make QScriptEngine creation faster -- it's very slow (~10x) compared to JSC) _______________________________________________ Qt-script mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt-script
