| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
JSC requires that the global object is actually a
JSGlobalObject instance, whereas QScriptEngine::setGlobalObject()
allows any object to be set as the global object. The way we
solve this is by proxying from an internal global object to the
custom (user-set) object.
We need to take care that the internal global object is never
actually exposed through our API; a brilliantly named helper
function, toUsableValue(), makes that happen.
Evaluating "var a = 10" with a custom global object doesn't work
yet; the variable always ends up in the internal Global Object.
For variable assignments, JSC appears to bypass the normal
JSObject::put() and instead use
JSGlobalObject::copyGlobals{From,To}(), which means I can't
intercept and proxy the assignments.
This commit enough to get the Context2D example working. There's
another bug with iteration of the built-in Global Object's
properties (non-enumerable properties are always skipped by the
JSC C++ API, whereas with QScriptValueIterator they should not
be), but that's a totally separate issue.
|
|
|
|
|
|
|
|
|
|
|
| |
Install custom ClientData on JSGlobalData instance instead.
Also some cleanups to avoid globalObject et al being accessed
directly.
Killed the proxying scheme employed in setGlobalObject() since it
didn't work; if you stored the original Global Object and replaced
it with another object, then added properties to the new object,
they would show up in the old object, too (because the old object
would always proxy to whatever the current Global Object was).
|
|
|
|
|
| |
Enable the tests checking the line number of exception.
Add a lower bound on the lineNumber of QScriptEngin::evaluate()
|
|
|
|
|
|
|
|
|
| |
Use the exception from JSC::exec instead of
QScriptEngin::uncaughtException.
A few more tests are passing for qscriptvalue and qscriptqobject.
Reviewed-by: Kent Hansen
|
|
|
|
|
|
|
|
|
|
| |
We have to set the CallFrame correctly in QScriptEngine::evaluate() in
order to ger the 'arguments' object and all the local stuff working.
The code Assert if dynamicGlobalObject is not set, so set it to the
global object.
Reviewed-by: Kent Hansen
|
| |
|
|
|
|
| |
Better than relying on a custom Global Object.
|
| |
|
| |
|
|
|
|
|
| |
No need to expose the fact that we go via the Global Object
to get an engine pointer.
|
|
|
|
|
|
|
|
| |
So the exception we get as result are the one thrown by the function.
(fix tst_QScriptEngine::newRegExp test)
Reviewed-by: Kent Hansen
|
| |
|
| |
|
|
|
|
|
| |
Support has been added to the JSC functions to support host functions
as well, so now we can use them directly.
|
|
|
|
|
|
| |
Handle Exception in a toString function
Reviewed-by: Kent Hansen
|
| |
|
| |
|
| |
|
|
|
|
|
| |
JSC refuses to call functions when there's an exception that hasn't
been dealt with, so save the exception and restore it afterwards.
|
| |
|
|
|
|
| |
getter
|
|
|
|
| |
There was a bug in commit 1d56e14605d74aefb955bdd81ee4083131252c9e
|
| |
|
|
|
|
| |
D'oh, inverse logic.
|
|
|
|
|
|
|
| |
engine
Also change the stringValue not to be a pointer. This fixes a memory
leak.
|
|
|
|
|
|
| |
as its prototype
port of commit 4182e9c4b2cbfcd0604c57da210e97d68cbbbb52 in qt/master.
|
|
|
|
| |
NativeFunctionWrapper is typedef for JSFunction
|
|
|
|
|
|
| |
If we implement the ability to change the global object, the
global object pointer can change, so we need to keep a
reference to the object if it's stored in a QScriptValue.
|
|
|
|
|
|
|
| |
For some reason our Global Object is not marked by the collector.
This fixes the case when you invoke GC explicitly by calling
collectGarbage(), but the issue is probably still there when GC
is invoked implicitly.
|
| |
|
| |
|
|
|
|
|
| |
Doesn't actually replace the global object, but rather has the
standard global object act as a proxy to the custom one.
|
| |
|
| |
|
| |
|
|
|
|
| |
allow stuff to run, even though it's likely to crash/not work...
|
|
|
|
|
| |
Caller is responsible for calling marked() before mark(),
otherwise you might get infinite recursion.
|
|\
| |
| |
| | |
git@scm.dev.nokia.troll.no:qt/qt-webkit into qtscript-jsc-backend
|
| |
| |
| |
| |
| |
| | |
Also, have pushContext() return currentContext() for now, to
avoid crashing, and disable processing of __postInit__ property
in importExtension() for same reason.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
With an object created by QScriptEngine::newObject(), it should
be possible to call QScriptValue::setClass() to dynamically
change the behavior of that object. Similarly, it should be
possible to promote plain script objects to QObject (QVariant)
wrappers by calling the overload of QScriptEngine::newQObject()
(newVariant()) that takes a script object as the first argument.
This commit implements this capability.
The premise is the (internal) QScriptObject class, which inherits
JSC::JSObject. It reimplements all the methods for getting/setting
properties etc. Then there's a level of indirection to facilitate
dynamic change of the class: Each QScriptObject can have a
delegate associated with it that will handle operations on the
object. By default there is no delegate, so the object behaves as
a normal JS object, as you expect. However, once a delegate is set
(e.g., when QScriptValue::setScriptClass() is called),
QScriptObject will give the delegate the chance to handle the
object operation.
In addition to a delegate implementation for QScriptClass-based
objects, there are also delegates for QObject and QVariant
wrappers. These replace the QObjectWrapperObject and
QVariantWrapperObject classes.
|
| | |
|
|/ |
|
| |
|
|
|
|
| |
The old engine did it as well. Makes more tests pass.
|
| |
|
|
|
|
| |
(QScriptValue::objectId() and QScriptEnigne::objectById)
|
|
|
|
| |
There's an off-by-one issue that we just work around for now.
|
| |
|
|
|
|
| |
E.g. QScriptClass-based objects.
|
|
|
|
| |
Do it The right way(TM), by lazily wrapping JSC::ExecState objects.
|