How to access v8's debug API in QJSEngine

[DavidXanatos]

Hi,

I was playing around with the new QJSEngine and wanted to access the v8's Debug interface (eider start the building debug agent, or pass debug commands directly to the engine using the C API), unfortunately it seams that the v8 symbols are not exported by the Qt Librarys.

I was looking around in the code a little bit and found some files under: ...\Src\qtdeclarative\src\qml\debugger that are using the V8's C API to pass debug messages, but yet this classes also does not seam to be fully exported. Some are exported partialy (meaning the export declaration is there some static functions work OK, but some other cause linking errors, strange)

Does anyone know how to get to the v8 Engine without having to recompile any Qt Librarys?

Cheers
David

[anda_skoa]

My understanding is that the V8 engine is considered an implementation detail of QJSEngine, i.e. it could be a different engine in the future.

Maybe there is something like http://qt-project.org/doc/qt-5.0/qts...edebugger.html for QJSEngine

Cheers,
_

[DavidXanatos]

Well... there seem not to be,
for qml scripts one can attach QtCreator for debugging when using a debug build.
But this seam not to work for QJSEngine, also for many projects one would like to be able to debug scripts while using an otherwise release version.

Scripts are often used to automatize or customize some final application.

I like QScriptEngineDebugger very much it really helped me a lot with my projects. I made a modified version that allows to do remote debugging, respectively debug engines running in other threads in the same process, the original QScriptEngineDebugger head to be in the same thread as the debugged engine and at the same time in the GUI thread limiting its usability somewhat.

Recently I wrote a new fronted class that connects to the V8 debugger agent and translates all relevant commands so that I can debug scripts running in a V8 engine using the nice debugged GUI from Qt. The project can be found here: https://gitorious.org/neoframework/neoscripttools

And now I wold like to use it to debug also QJSEngine executed scripts since it is just a wrapper for the V8.
Actually one could also put the V8DebugAdapter together with a modified remote debugger backed into a modified QtLibrary and have a QScriptEngineDebugger like debugger for the new JSEngine.

Though it would be nicer not to have to rebuild the qt library's for that.

[wysota]

You are aware V8 is going to be replaced with Qt's own JS engine called V4, right?

http://blog.qt.digia.com/blog/2013/0...engine-part-1/

[DavidXanatos]

You are aware V8 is going to be replaced with Qt's own JS engine called V4, right?

http://blog.qt.digia.com/blog/2013/0...engine-part-1/

Well, thats not relevant for a few reasons:
1. This will not happen any time soon I guess, and for now a working solution is needed.
2. I use a raw V8 and not Qt in the core of one of my projects (Qt only for GUI) so i needed a V8 debugger with a QtGUI
3. In the other project where I first used QScriptEngineDebugger i use Qt every ware and need a nice script to automatize some parts, this part requiters ideally a lot of raw Java script performance, V4 will not be Superior to V8 in this regard so if QJSEngine should not keep v8 it may be better to also use here a naked v8 and do all the binding manually.
4. The debugger probably can be also re purposed to plug into v4vm once its ready.

Having a consistent in App script debugging is I believe a great feature worth pursuing.

David X.

[anda_skoa]

Having a consistent in App script debugging is I believe a great feature worth pursuing.

Sure, but the in app scripting facility is QtScript, which does have a debugger interface.

Cheers,
_

[DavidXanatos]

Sure, but the in app scripting facility is QtScript, which does have a debugger interface.
_

Sure it is not deprecated?
I thought QJSEngine & co was intended to replace QScriptEngine & co.

Also My project that is currently using QScriptEngine would greatly benefit from the raw JS power of QJSEngine.

David X.

[anda_skoa]

Sure it is not deprecated?

I didn't find anything hinting at that in the QtScript documentation.

I thought QJSEngine & co was intended to replace QScriptEngine & co.

I initially thought that as well, but QJSEngine is part of qtdeclarative so at least for now it is not a stand-alone module and more an internals of the declarative engine and thus subject to its needs.

And those needs, at least on some platforms, is to do without just-in-time compilation. Whether this will affect all platforms or only those which have such restrictions is unknown.

Cheers,
_

[DavidXanatos]

I didn't find anything hinting at that in the QtScript documentation.

well:

http://qt-project.org/doc/qt-5.0/qtdoc/modules.html

"Classes for making Qt applications scriptable. Provided for Qt 4.x compatibility. Please use the QJS* classes in the QtQml module for new code."

In my dictionary this means QScriptEngine is deprecated.

Now the question is what will happen to the QJS* classes once QT's own Engine is ready.

Also about JustInTime compilation I believe Qt shouldn't do so much work (own engine) to solve a problem others most likely will, I can not really believe that Google will not want Chrome to run on windows RT.
They will eider sue M$ or change V8 to be able to switch between compiler and interpreter mode.
In booth cases, the problem will solve it self you just have to wait.

David X.

[wysota]

They will eider sue M$

Sue them over what? Can <put your favourite car company> sue Great Britain for their left-hand traffic?

or change V8 to be able to switch between compiler and interpreter mode.

Firstly this would mean completely rewriting V8. Secondly this does not solve some of the issues the QML engine has. I'm not a fan of changing javascript engines every 18 months but I can well understand the reasoning behind it.

[DavidXanatos]

Sue them over what?

http://www.neowin.net/news/mozilla-n...m-restrictions

Firstly this would mean completely rewriting V8.

Google has certainly the resources to do it in no time if they would want to.

Secondly this does not solve some of the issues the QML engine has.

Is there an article that explains in a bit more detail how the performance issues origin? http://blog.qt.digia.com/blog/2013/0...engine-part-1/ does not really explain why there is this prformance issue and why there are 3 representations needed.
I thought QML was just Java script plugged into Qt classes, but it seams there is more to it.

Edit:
Also Qt needs to keep v8 for webkit to have good web performance.
And QJSEngine as far as I understand it does not use qml just normal js (qs) scripts, so there should be no performance advantage in switching to v4vm.
And for webkit the JIT problem for windows RT will have to be solved anyways.

Bottom line is I hope they will keep V8 at least as a replacement for the QtScript,
and for now the question is how to properly connect to the v8 debugger interface.


David X.

[anda_skoa]

http://qt-project.org/doc/qt-5.0/qtdoc/modules.html

"Classes for making Qt applications scriptable. Provided for Qt 4.x compatibility. Please use the QJS* classes in the QtQml module for new code."

In my dictionary this means QScriptEngine is deprecated.

Ah, interesting. That would indeed hint at deprecation.
Not sure though if that was the initial goal and is still valid after the decision to create V4.

I thought QML was just Java script plugged into Qt classes, but it seams there is more to it.

While it has a similar syntax to JSON, it is just a domain specific language for describing object trees and relations between those objects' properties.
A QML document can include pieces of JavaScript code for helper functions, signal handlers, etc.

They will eider sue M$ or change V8 to be able to switch between compiler and interpreter mode.

They haven't done anything like that regarding iOS, which has the same restrictions but a way larger market share than WindowsRT.

In booth cases, the problem will solve it self you just have to wait.

There is no guarantee that it will solve itself, so this could be an infinite wait. And other frameworks do target a similar multiplatform approach so one can't wait too long.

All speculation now, maybe QJSEngine will stay with V8 on all platforms but the restricted ones.

Cheers,
_

[wysota]

All speculation now, maybe QJSEngine will stay with V8 on all platforms but the restricted ones.

That's unlikely as two different engines would have to be maintained simultaneously.