> Norris Boyd wrote:
>
> Igor Bukaniv wrote:
> >
> > I am curios, why there is a need to have a special JSObject support in Rhino? Was it used for anything? The implementation in the ICEbrowser does not use it as in rare cases where conversion from JSObject to/from JS type may be needed (like calling JSObject.getWindow from a script), it seems that WrapHandler (or similar modifications to pre Rhino 1.5R2 sources) and Wrapper are enough to cover all the cases.
> Yes, we should probably just remove the JSObject code. We added it early on when Rhino was first written and we thought we might need JSObject compatibility with the JS + Java implementation in Navigator 4.x. That's not important now, so we should just remove this code (which likely doesn't work at this point anyway).
given the following object :
----------------------------------------------
function SomeObject() {}
SomeObject.prototype.exec = function() {
var local = this.someField;
}
----------------------------------------------
i create an 'instance', set a field and call the exec method :
----------------------------------------------
var someField = "global field value";
var anInstance = new SomeObject();
anInstance.someField = "instance field value";
anInstance.exec();
----------------------------------------------
then the local variable 'local' in the exec() method is assigned the value
of the global 'someField' variable instead of the instance field value.
the problem seems to be in the ScriptRuntime.callOrNewSpecial() method,
which is called, because the parser treats the name 'exec' specially. in
this method the exec() method gets called with
return call(cx, fun, thisArg, args, scope);
where the 'thisArg' parameter really is the global this value instead of
the dynamic this value, which is in the jsThis variable and which would be
the one needed...
is it legitimate to replace the above call in callOrNewSpecial() with the
following line :
return call(cx, fun, jsThis, args, scope);
this seems to only happen for methods named 'exec', which are identified as
special in the NodeTransformer.isSpecialCallName() method.
any help is appreciated. thank you very much for your time.
kind regards,
felix
The attached patch adds support for debugging eval and Function code transparently. It changes omj.NativeGlobal and omj.BaseFunction to embed line number of origin of eval and Function scripts into source name and pass 1 as base line for script code. In this way a debugger implementation can treat eval and Function code in the same way as scripts loaded from some url while giving more information about error location in case of an error in eval code as the error source would contain both line number of eval origin and line number in eval code itself.
I chose to embed line numbers via patterns like
sourcefile#<line-number>(eval)
sourcefile#<line-number>(Function)
just to be able to to pass the constructed name to URL constructor if the original sourcefile is a valid URL but it is pretty arbitrary.
I have noticed that attempting to call a java method like this:
public void foo(String foo, Serializable bar)
{
// un-important details
}
from script using foo("foo", "bar"); fails because the second argument
is not deemed coercable to Serializable. A preliminary look at the
coercion code shows that no check is made in this case with
isAssignableFrom().
The to type is only tested against StringClass and ObjectClass (non
primitive case).
(See NativeJavaObject.getConversionWeight())
I attach the patch to move away setting/quering for breakpoints from the Rhino core to application as a debugger implementation can check if a particular line has a breakpoint or not. The changes to omj/tools/debugger takes more then few lines I initially thought but they are mostly caused by refactoring to implement different view to set/query breakpoints.
The patch replaces getLineNumbers, placeBreakpoint and removeBreakpoint in DebuggableScript by getFirstLine, getEndLine and getInstructionLines where the last function fills a boolean array to indicate which script lines can ever occur in DebugFrame.onLineChange. These are read-only functions so InterpeterData are never mdofied by the debugger.
omj/tools/debugger/Main uses this information to check whether it is possible to place breakpoint at a particular line, and if possible, it sets to true entry at the boolean breakpoint array. In this way testing for break in onLineChange is simple and fast as it just needs to check if breakpoint array holds true at the given line number position.
1. Targeting of labels with 0x80000000 biscuits is moved from LabelTable to ClassFileWriter as this is classfile specific and is not necessary in Interpreter.
2. LabelTable allows for pc > Short.MAX_VALUE as this restriction is classfile specific. The only requirement is for jump offsets to stay within short range.
3. LabelTable is made private member of Interpreter and ClassFileWriter instead of being classes' superclass to avoid API leakage that forced optimizer.Codegen to declare few utility methods public as they got the same signature as LabelTable methods visible throw Interpreter inheritance.
bug 139883, "ErrorHookProc can be tricked into thinking it never finished running", r=peterv
fixes bad early return in jsds_ErrorHookProc
test for correct max params (12, not 8) in CreatePPLineMap
use nsnull instead of 0 for null pointer return value
1. Replacing omj.debug.Debugger.enterFrame() by omj.debug.Debugger.getFrame() and omj.debug.DebugFrame.onEnter() to allow to return null from omj.debug.Debugger.getFrame to enable full optimization with debugger set if it is not interested in monitoring a particular frame
2. Changing type for the source argument in omj.debug.Debugger.handleCompilationDone from StringBuffer to String as Debugger instances should not be able to modify source even by chance.
