Hi,
Some notes from day 2.
- Zoltan doesn't think there will be a problem with Szeged people
signing Google's contributor's agreement (Szeged University doesn't hold
any patents)
- Weekly phone conference will be held on Tuesdays @ 3pm; Kent to set up
a recurring Nokia voice conference thingy
- Peter & Zoltan got a feeling of how we work on QtScript/V8
- JIRA, autotests and benchmarks, V8 issue tracker
- Picked some random test failures and started investigating them
- Connecting failures to upstream bugs (QEXPECT_FAIL messages)
- Used the BM tool to study performance regressions against
Qt/master. Unfortunately it's still an internal tool/configuration; the
copy on QtLabs is outdated [Kent to talk to Jo on what the status is]
- P & Z can't assign JIRA tasks to themselves yet (needs OpenGov)
- Comment & watch bugs in the meantime
- Use merge request for contributing patches
- Zoltan showed us how to use oprofile to do (system-wide) profiling
- Alternative to callgrind et al
- sudo opcontrol --start --no-vmlinux; run <your app>; sudo
opcontrol --stop; opreport <your app>
- You need to tell opreport the location of the shared libraries
your app depends on
- Olivier & Gabriel fixed issue with V8-in-release-mode
- Caio disabled QML's binding evaluator (qmlDisableOptimizer flag in
qdeclarativecompiledbindings.cpp) and found that the evaluator is ~10x
faster than using QtScript for simple bindings
- QML has its own QObject bindings, which do a lot of the same as
QtScript's QObject bindings
- We should aim to unify them
- Core bindings code should be in QtScript, but QML can configure
them to e.g. get rid of things it doesn't need (dynamic properties,
child objects)
- Dynamic property handling is completely unneeded for QML, we
should focus on the metaobject-properties-only case
- Discussions about the options we have for implementing the bindings
(either QObject or QML) in v8
- Accessors are around 2 times faster than Interceptors, not
counting the cost of caching the property names
- At least for QObject we might have to use interceptors because of
"dynamic" features
- Experiments and clarifications on what the interceptors should
intercept and what not
- Feeling that we would like to have some kind of
"after-interceptor", that is called when v8 finds no property
- The option of using the V8 API directly in the QML implementation
isn't too popular
- Tightens dependencies, more error-prone when mixing QtScript & V8 API
- Let's try to avoid it, then
- Jedrzej mentioned the option of using private QtScript classes in QML
- The private classes have an API that is more or less source
compatible with the public QtScript API
- Allows for the compiler to inline QtScript calls
- More error-prone because the QML code needs to take care of
entering/exiting V8 Isolate, but also less overhead since multiple calls
can be made to QtScript without entering & exiting the Isolate for each call
Regards,
Kent
_______________________________________________
Qt-script mailing list
[email protected]
http://lists.qt.nokia.com/mailman/listinfo/qt-script
