How to access v8's debug API in QJSEngine

[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.

[DavidXanatos]

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

Well, actually 3 if you count the old QScriptEngine that has the nice debug interface.

I'm afraid that QScriptEngine will have to bite the dirt first and there will be no replacement in place that would provide decent in app debugging capabilities.

Of cause one could hope they will get rid of QJSEngine all together, keep QScriptEngine for scripting and use v4vm only for QQmlEngine.

on a side note: qml and webkit, i haven't looked into it in detail, but are they actually deploying v8 code twice once as part of qml and once as part of web kit? Thats not elegant, there should be a shared v8 library used by all modules.

Than there would be still 3 engines but at least one for each separate module.

There are many articles you would have to read to understand it all.

links?

David X.

[wysota]

Well, actually 3 if you count the old QScriptEngine that has the nice debug interface.

It does not really be maintained as its functionality is finished. QML on the other hand is actively developed.

Of cause one could hope they will get rid of QJSEngine all together, keep QScriptEngine for scripting and use v4vm only for QQmlEngine.

QScriptEngine is likely to stay because of licensing policies (especially the commercial license).

on a side note: qml and webkit, i haven't looked into it in detail, but are they actually deploying v8 code twice once as part of qml and once as part of web kit?

Most probably yes.

Thats not elegant, there should be a shared v8 library used by all modules.

This would require both modules to be released together which is agains the policy introduced in Qt5 where independent modules can be released separately.

links?

I would start with the docs and DevDays videos on QML.

[DavidXanatos]

QScriptEngine is likely to stay because of licensing policies (especially the commercial license).

In which way does the licensing policies play here a role?

This would require both modules to be released together

No, they would use a shared library.
They wouldn't have to be together just use the same shared v8.dll

DevDays videos on QML.

Are there no text articles describing the stuff, other than the docs themselves?

[wysota]

In which way does the licensing policies play here a role?

Hmm.. somehow I thought V8 was LGPL which would prevent statically compiling it into closed-source projects but it seems it is BSD.

No, they would use a shared library.
They wouldn't have to be together just use the same shared v8.dll

The point is now QtWebKit and QtQml can use different versions of V8. Release schedules of QtWebKit and QtQml are quite different.

Are there no text articles describing the stuff, other than the docs themselves?

I don't have any specific links for you right now. Most that I've learn with regard to this subject was by studying QtQml internals myself. Nasty hacks to work around Qt's property system in QML is one of the example areas.

[anda_skoa]

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

True, I also don't find that likely. Too bad though, having a high performance engine available would have been nice and that was probably even the original intent.

I'm afraid that QScriptEngine will have to bite the dirt first and there will be no replacement in place that would provide decent in app debugging capabilities.

Well, "first" in this context still means Qt6, it is more likely that QJSEngine's internals will change earlier than that.

Ideally QQmlEngine would have used QJSEngine and so it could switch to something else while keeping QJSEngine and deprecating QScriptEngine.
But alas it derives from it, so unless QJSEngine is two different things internally (very unlikely!), it will become an engine optimized for the QML use case.

My take is that the needs for in-application scripting, especially due to the easy way of accessing application provided infrastructure from scripts, can easily be fulfilled by QScriptEngine.

Of cause one could hope they will get rid of QJSEngine all together, keep QScriptEngine for scripting and use v4vm only for QQmlEngine.

While they obviously can't get rid of QJSEngine as a class, my guess is that it will become an implemetation detail of QQml and QScriptEngine stays the main in-application scripting facility.

on a side note: qml and webkit, i haven't looked into it in detail, but are they actually deploying v8 code twice once as part of qml and once as part of web kit? Thats not elegant, there should be a shared v8 library used by all modules.

WebKit is special, its Qt "frontend" is part of the WebKit, not WebKit part of Qt. So it is more a separate project that is being worked on by some developers who also happen to be developers on Qt-Project.org

WebKit might also switch to a different JS engine at some point.

Regarding QML:

a QML document describes a tree of element, much like XML but with less verbose syntax. Each element type is specified either by another QML document or a C++ class registered with the QML type system. The requirement for the latter is that the class derives, directly or indirectly, from QObject and that it can be created without arguments.

As Qt developers we often create trees of QObjects, e.g. QWidget trees, QStateMachine with nested states, etc.
QML can be used to do that in a less hard-coded fashion, e.g. if the tree in question needs to be changable without changing the binary.

Since all nodes in such a tree are essentially QObject instances, they have the capability of signals, slots and properties. QML allows to call slots, connect to signals and read/write properties. One really nice feature is that properties can not only be assigned a fixed value but an expression containing other properties and that expression is automatically reevaluated whenever one of its contained properties changes its value.

The latter is of course especially nice in UI code, where e.g. a button's enabled state often depends on some other UI element's content.
But it can be useful for other object hierachies as well, it is mostly a matter of getting used to this form of state propagation.

Cheers,
_

[DavidXanatos]

This clears up some things I think, thx.

Assuming that QJSEngine may become an implemetation detail of QQml and QScriptEngine will stay for application scripting, it may be an interesting option to create a fork of the current v8 based QJSEngine with an exposed debug interface for in app debugging, and those use cases where a lot of JS performance is needed and the slow interface for QObject is not significant.

But you are probably right that Qt wont maintain 2 scripting engines that basically do almost the same, just with different performance and platform compatibility.

So if there is a need for such a thing it would have to be some extern component maintained by some 3rd party.

Cheers

[wysota]

Assuming that QJSEngine may become an implemetation detail of QQml and QScriptEngine will stay for application scripting, it may be an interesting option to create a fork of the current v8 based QJSEngine with an exposed debug interface for in app debugging, and those use cases where a lot of JS performance is needed and the slow interface for QObject is not significant.

Nothing can stop you from extracting QJSEngine code, renaming it to QV8Engine and making it a separate library.

But you are probably right that Qt wont maintain 2 scripting engines that basically do almost the same, just with different performance and platform compatibility.

So if there is a need for such a thing it would have to be some extern component maintained by some 3rd party.

I would assume the Trolls will want V4 to be as fast as V8. Since it's JIT, execution speed (of the compiled code at least) should be similar.

[DavidXanatos]

I would assume the Trolls will want V4 to be as fast as V8. Since it's JIT, execution speed (of the compiled code at least) should be similar.

According to the blog post linked on the previous page one of the problems of v8 is that is JIT and on windows RT this does not work as you cant write a memory block and make it executable.
So to my understanding V4 will have to be an interpreter.

Cheers

[anda_skoa]

That is my understanding is well

Cheers,
_

[wysota]

So to my understanding V4 will have to be an interpreter.

Let me quote the article:

The new engine contains a fully compliant ECMAScript 5.1 implementation, that runs on all platforms Qt supports. It contains a JIT that currently works on Linux, Mac and iOS.

[DavidXanatos]

Let me quote the article:

iOS and WinRT support
iOS does not allow making memory both executable and writable, something that existing JS engines require. WinRT doesn’t allow making memory executable at all. This makes it impossible to use V8 on these platforms without writing a full interpreter backend to V8.

If they do a JIT again despite knowing that it is odd to fail on WinRT this would be a major MAJOR F*** up.

Even if many people don't like win 8 in general and WinRT in particular, I think M$ will be throwing enough money on this until WinRT gets it market share, i mean from a user point of view its not worse than iOS, its the same jailed not really general purpose proprietary computing device.
Also I think that windows phone has the same kernel as win RT so it will have the same limitations.
Qt shouldn't develop solutions that would fail on this platforms.

David X.

[wysota]

If they do a JIT again despite knowing that it is odd to fail on WinRT this would be a major MAJOR F*** up.

From what I understand, they have a solution that does JIT where it is possible and falls back to interpreting where it is not. Or maybe there is a solution to do JIT without breaking platform policies (after all they said they have a working V4/JIT on iOS).

[DavidXanatos]

Or maybe there is a solution to do JIT without breaking platform policies (after all they said they have a working V4/JIT on iOS).

afaik. on iOS you can request a block of writable memory write to it and then change the flags to read only but executable. On WinRT you an not do that.

So Yes, they would need to have a interpreter as Fall-back.