Some other small fixes are included. Here is the list...
- Make nsIJSID::id [noscript] because xpconnect automatically builds a nsIJSID
wrapper around nsid values. However, xpconnect does not maintain a table of
those wrappers. So, given the same id twice it will make two nsIJSID wrappers.
This means that property walking could get foo.id.id.id... and not detect that
the different objects represent the same id. nsIJSID already exposes 'number'
so that JS can get the stringified value of the nsid. The nsid struct returned
by 'id' is useful for C++, but only causes problems for JS.
- Fix the nsIXPCScriptable 'IGNORE' handler for GetAttributes to not fail
silently.
- Add 'Components' to global objects as a non-enumerable property for backwards
compatibility and to avoid additional work in property enumeration (esp. in
win.toSource!)
- Expose toSource on wrapped native JSObjects. This just returns an empty object
string: '{}'. It can be overridden by an interface method if present.
- Expose toString on wrapped native JSObjects. It can be overridden by an
interface method if present. Previously we only did this as part of the
Convert op. Now someWrapper.toString will return a callable function.
- Extend the toString behaviour to also print the address of the wrapper in
DEBUG builds only: e.g. "xpconnect wrapped nsIFoo @ 0x12345678". mccabe
convinced me this would be useful. Release build behaviour is unchanged - we
worried that exposing addresses might contribute to possible security exploits.
- Have wrapped native JSObjects use Object.prototype as their proto rather than
have a null proto. Originally this was going to allow delegation to
Object.prototype.toSource, but even without that, this seems like a good thing.
This is implemented by getting Object.prototype from the global object each
time we create a wrapper to allow for spify JS dynamic craziness.
- Use 16bit values in wrappednative property descriptors to save space. It was
only possible to use 16 bits of the pointer-sized ints in the structs anyway.
- Do a security check at enumeration time and only expose those properties that
the caller can actually 'Get'. This fixes the toSource security exception
problem.
- Add a big comment about the problem of reporting uncaught exceptions.
- Fix crashing bug for case where object has no enumerable properties and
xpconnect failed to fill in the zero count.
- Fix NewInstanceJSObject to dig in and find the 'ultimate' parent when
parenting new wrapper JSObject. The old scheme was ending up with hugely
long parent chains in some cases.
r=jst, sr=brendan
- Optimize integer ++ and -- to avoid double-to-int, which is quite costly for
some compilers (ftol on Windows with MSVC).
- Optimized arguments[i] and arguments.length references to use bytecodes that
avoid creating an arguments object for the current frame. This entailed
simplifying the compiler to avoid flagging functions and scripts that set
arguments, since we have code in jsfun.c to catch such sets at runtime.
- The code generator now eliminates useless expression statements, giving a
strict warning about them.
- Rationalized jsemit.c's LookupArgOrVar to have well-defined results in *pn.
Eliminate bytecode specializations for argument and local variable gets and
sets from jsparse.c -- these precede jsemit.c's LookupArgOrVar and frustrate
it, by setting pn_slot non-negative too early.
- Code generation errors set report->filename and report->lineno, rather than
hacking "{0}, line {1}: " into the localized message.
- Bogus JSFRAME_VAROBJBUG removed, JSOPTION_VAROBJFIX is sufficient.
- Spruce up jsinterp.c macros to use JS_BEGIN/END_MACRO brackets if possible.
- Avoid calling JS_PropertyStub. The call is too costly compared to a branch
in the caller.
- Optimize integer ++ and -- to avoid double-to-int, which is quite costly for
some compilers (ftol on Windows with MSVC).
- Optimized arguments[i] and arguments.length references to use bytecodes that
avoid creating an arguments object for the current frame. This entailed
simplifying the compiler to avoid flagging functions and scripts that set
arguments, since we have code in jsfun.c to catch such sets at runtime.
- The code generator now eliminates useless expression statements, giving a
strict warning about them.
- Rationalized jsemit.c's LookupArgOrVar to have well-defined results in *pn.
- Code generation errors set report->filename and report->lineno, rather than
hacking "{0}, line {1}: " into the localized message.
- Bogus JSFRAME_VAROBJBUG removed, JSOPTION_VAROBJFIX is sufficient.
- Spruce up jsinterp.c macros to use JS_BEGIN/END_MACRO brackets if possible.
- Avoid calling JS_PropertyStub. The call is too costly compared to a branch
in the caller.
Subject:
minor Rhino bug
Date:
Tue, 23 Jan 2001 13:14:51 -0800
From:
dave russo <d-russo@ti.com>
To:
nboyd@atg.com
CC:
d-russo@ti.com
Norris,
While using the new Rhino debugger (from the latest tip) I started to get "No
Context associated with current Thread" exceptions when expanding host objects
in the "Context:" debugger window.
In looking at the code, I discovered that NativeObject.toString seems to assume
that Context.getContext() may return null. In fact, getContext() always returns
a non-null context or throws an exception.
I changed NativeObject.toString to never throw an exception (see below) and this
eliminated the problem I was seeing (of course).
It would be nice to incorporate this in a future Rhino tip or, if this change is
inappropriate, any guidance would be appreciated. Thanks in advance.
I changed NativeObject.toString to:
public String toString() {
try {
Context cx = Context.getContext();
return jsFunction_toString(cx, this, null, null);
}
catch (Exception e) {
return "[object " + getClassName() + "]";
}
}
from:
public String toString() {
Context cx = Context.getContext();
if (cx != null)
return jsFunction_toString(cx, this, null, null);
else
return "[object " + getClassName() + "]";
}
Re: Small usage simplification for Rhino
Date:
Tue, 23 Jan 2001 16:01:42 +0100
From:
Igor Bukanov <igor@icesoft.no>
To:
Norris Boyd <nboyd@atg.com>
References:
1 , 2 , 3 , 4
Norris Boyd wrote:
> Thanks. I've patched in your changes and checked it into CVS.
I also looked at other places with similar pattern of few lines of
common code to construct error messages. The following was occurred too
often not to avoid temptations to move it to a separated function:
NativeGlobal.constructError(
Context.getContext(), "TypeError",
ScriptRuntime.getMessage1("msg.default.value", arg),
this)
It can be replaced by
NativeGlobal.typeError1("msg.default.value", arg, this)
There are other similar usages but they are not to frequent to bother
with code reduction because even the above replacement saves just 200
bytes in uncompressed jars (it is expensive to introduce new methods in
Java).
In any case, if you think it makes any sense, patches are attached. They
are made via
diff -cbB javascript.orig javascript > patch_context
diff -bB javascript.orig javascript > patch_std
from org/mozilla directory.
Regards, Igor
Subject:
Recent rhino broke security support
Date:
Tue, 23 Jan 2001 08:07:45 -0500
From:
"Kurt Westerfeld" <kurt@managedobjects.com>
To:
"Norris Boyd" <nboyd@atg.com>
Norris.....I like the changes made to FunctionObject to do method invocation
much faster. Very slick.
Problem tho: this mechanism does not veer into the security support plugin
on context for defining a class. This is crucial do creating event adapter
code later in applet environments.
I'm going to look into this, but perhaps you could probably make the changes
faster than I.
Unfortunately for us, we found this problem yesterday at a customer site.
:-( Shame on us.
________________________________________________________________________
Kurt Westerfeld
Senior Software Architect
Managed Objects
mailto:kwester@ManagedObjects.com
703.770.7225
http://www.ManagedObjects.com
Managed Objects: manage technology > rule business
Backing out Brendan's previous checkin for bug #65553 (jsapi.c, jsdbgapi.c, jsemit.c, jsinterp.c, jsinterp.h, jsobj.c, and jsscript.c), so we can get smoke tests going.
r=attinasi@netscape.com (sheriff)
[Fwd: My Mistake in ScriptRuntime method]]]
Date:
Tue, 16 Jan 2001 15:48:26 +0100
From:
Igor Bukanov <igor@icesoft.no>
To:
Norris Boyd <nboyd@atg.com>
Hi, Norris!
With my previous patch to fix in
org/mozilla/javascript/ScriptRuntime.java Integer.MIN_VALUE as index
problem I also added a bug to the unrelated code: I tried to minimize
object creation and unfortunately that untested "optimization" slippet
into my patch as well.
I replaced the lines 290, 291 in toNumber(String s) method from
String sub = s.substring(start, end+1);
if (sub.equals("Infinity"))
to
if (s.regionMatches(start, "Infinity", 0, 8))
But that should be
if (start + 7 == end && s.regionMatches(start, "Infinity", 0, 8))
Sory for troubles, Igor
290c290
< if (s.regionMatches(start, "Infinity", 0, 8))
---
> if (start + 7 == end && s.regionMatches(start, "Infinity", 0, 8))
Re: Debugger problem
Date:
Mon, 08 Jan 2001 14:16:30 -0800
From:
Christopher Oliver <coliver@mminternet.com>
Organization:
Primary Interface LLC
To:
Kurt Westerfeld <kurt@ManagedObjects.com>
CC:
Norris Boyd <nboyd@atg.com>
References:
1 , 2 , 3
Kurt, Norris,
Yes, with the change to the shell this should be possible. The problem before
was that if you loaded the same file with different relative path names, two
different windows in the debugger were created because everything (windows,
breakpoints, etc) is keyed off the source name.
The attached file contains the fix (and includes the workaround for
Desktop.getSelectedFrame).
There are still some bugs in transferring focus between the windows in the
Desktop. I haven't had time to track down the problem or a solution.
Chris
Kurt Westerfeld wrote:
> I would point out that "Source Name" of a script isn't necessarily a
> filename. In our system, scripts are run remotely from a script library
> that has no file system backing. Canonicalizing the file names is really
> unnecessary.
>
> Can't you just modify JSDebugger to not care what the name of the file is?
> If access to the original script is unavailable except through the file
> system, I'd be surprised.
>
> ----- Original Message -----
> From: Christopher Oliver <coliver@mminternet.com>
> To: Kurt Westerfeld <kurt@ManagedObjects.com>
> Cc: Norris Boyd <nboyd@atg.com>
> Sent: Sunday, January 07, 2001 2:23 AM
> Subject: Re: Debugger problem
>
> > Hi Kurt,
> >
> > I rather would say that it is a problem with the processFile method in the
> > shell's Main class. If you change the current working directory or the
> value
> > of the System property "user.dir" after compiling a script, relative path
> names
> > can become ambiguous. Norris, would it be ok to modify the shell to
> > "canonicalize" the names of files it compiles? That way the source name
> that
> > shows up in the stack and in DebuggableScript will always be unique. For
> > example:
> >
> > public static void processFile(Context cx, Scriptable scope,
> > String filename)
> > {
> > Reader in = null;
> > try {
> > in = new PushbackReader(new FileReader(filename));
> > int c = in.read();
> > // Support the executable script #! syntax: If
> > // the first line begins with a '#', treat the whole
> > // line as a comment.
> > if (c == '#') {
> > while ((c = in.read()) != -1) {
> > if (c == '\n' || c == '\r')
> > break;
> > }
> > ((PushbackReader) in).unread(c);
> > } else {
> > // No '#' line, just reopen the file and forget it
> > // ever happened. OPT closing and reopening
> > // undoubtedly carries some cost. Is this faster
> > // or slower than leaving the PushbackReader
> > // around?
> > in.close();
> > in = new FileReader(filename);
> > }
> > filename = new java.io.File(filename).getCanonicalPath();
> > <<<====== Add this
> > }
> > catch (FileNotFoundException ex) {
> > Context.reportError(ToolErrorReporter.getMessage(
> > "msg.couldnt.open",
> > filename));
> > exitCode = EXITCODE_FILE_NOT_FOUND;
> > return;
> > } catch (IOException ioe) {
> > globalState.getErr().println(ioe.toString());
> > }
> >
> > // Here we evalute the entire contents of the file as
> > // a script. Text is printed only if the print() function
> > // is called.
> > evaluateReader(cx, scope, in, filename, 1);
> > }
> >
> >
> > Attached is *my* latest version of the debugger code. Norris, have you
> made
> > any progress on cvs commit priveledges? The attached version fixes a
> number of
> > GUI bugs:
> >
> > 1) If you undocked the Variables window and popped up the Context
> combo-box and
> > then closed the window with the system menu, the Context pop-up was not
> cleaned
> > up properly.
> > 2) The first time you minimize a file window it appeared to dissappear
> when you
> > tried to restore it. This was due to the fact that I forgot to "pack" its
> > contents and as a result its requested size was 0x0.
> >
> > I also added a menu item to toggle whether to break on exceptions and one
> which
> > allows you to open (and compile) a JavaScript file without actually
> executing
> > it.
> >
> > I have also attached a Word document with some basic documentation for the
> > Debugger.
> >
> > Note that this version also includes all the changes to support debugging
> > scripts in the AWT dispatch thread.
> >
> > Chris
> >
> > Kurt Westerfeld wrote:
> >
> > > Hello. I ran into a null pointer exception in JSDebugger tonight, and I
> > > thought I'd drop you a note.
> > >
> > > The problem line is 2336, where a breakpoint is hit. To simulate, load
> the
> > > debugger using the command line syntax on a file that has not been
> resolved
> > > to cannonical path.
> > >
> > > Example,
> > >
> > > jshell -debug -f \myfile.fs
> > >
> > > At any rate, the "handleCompilationDone" routine takes \myfile.fs and
> turns
> > > it into a canonical path. If you hit a breakpoint in this file and say
> > > "go", when the breakpoint hits the file is not found, because the same
> > > canonical path resolution is not done. The resolution seems dubious,
> since
> > > it is only done in the compilation done callback, but I don't know the
> best
> > > way to suggest a fix since it seems that code had some purpose.
> > >
> > > Anyway, thought you'd wanna know.
> > >
> > > ________________________________________________________________________
> > > Kurt Westerfeld
> > > Senior Software Architect
> > > Managed Objects
> > > mailto:kwester@ManagedObjects.com
> > > 703.770.7225
> > > http://www.ManagedObjects.com
> > >
> > > Managed Objects: manage technology > rule business
> >
JSDebugger.java
Name:
JSDebugger.java
Type:
Java Class File (java/*)
Encoding:
base64
* Make use of DebuggableEngine interface to keep Context API smaller
* Change org.mozilla.javascript.debug.Frame to DebugFrame to avoid
confusion with java.awt.Frame
Subject:
Re: Rhino bug - Wrapper ??
Date:
Fri, 05 Jan 2001 03:46:11 +0530
From:
Mukund Balasubramanian <mukund@cs.stanford.edu>
Organization:
Another Netscape Collabra Server User
Newsgroups:
netscape.public.mozilla.jseng
References:
1 , 2 , 3 , 4 , 5 , 6
That works too,
Should I assume that this would be a part of the next tip ? I agree with the
part about
overloading code too.
Anyways, thanks a load for your help and just tell me if I could be of any
help in any other
respects of the rhino project.
ThanX,
Mukund Balasubaramanian
Norris Boyd wrote:
> Actually, I was considering removing the unwrapping code from
NativeJavaConstructor. I was
> suprised that it was there. The code dates from before we implemented proper
method and
> constructor overloading in Rhino. It's the overloading code that should have
the responsibility
> for unwrapping.
>
> Does this patch work for you:
>
> Index: NativeJavaObject.java
> ===================================================================
> RCS file:
/cvsroot/mozilla/js/rhino/org/mozilla/javascript/NativeJavaObject.java
> ,v
> retrieving revision 1.29
> diff -u -r1.29 NativeJavaObject.java
> --- NativeJavaObject.java 2000/11/13 22:10:32 1.29
> +++ NativeJavaObject.java 2001/01/04 21:33:55
> @@ -673,6 +673,12 @@
>
> return Result;
> }
> + else if (value instanceof Wrapper) {
> + value = ((Wrapper)value).unwrap();
> + if (type.isInstance(value))
> + return value;
> + reportConversionError(value, type);
> + }
> else {
> reportConversionError(value, type);
> }
>
> This handles the case where the object is both a Scriptable and a Wrapper.
>
> --N
>
> Mukund Balasubramanian wrote:
>
> > Yes they do implement Scriptable.
> > From my preliminary inspection of the code, findFunction seems to be
preceediong the
> > coerceType call and I presume findFunction call is going to fail if the
arguments are
> > wrapped (bad types mismatching signature).
> > The constructor case DOES go through an explicit unwrapping stage as
shown by the cut
> > and paste code. My question is whether the same preamble in NativeJavaMethod
is a valid bug
> > fix.
> >
> > ThanX,
> >
> > Mukund Balasubramanian
> >
> > Norris Boyd wrote:
> >
> > > Do your objects that implement Wrapper also implement Scriptable? From
simple inspection
> > > of the code I'd think that both the constructor and method cases would go
through
> > > NativeJavaMethod.coerceType, which should unwrap. However, Scriptable
objects are picked
> > > off and handled before any unwrapping is considered.
> > >
> > > --N
> > >
> > > Mukund Balasubramanian wrote:
> > >
> > > > Yup,
> > > > Here it is - Line numbers 173-178 are cut and paste from
> > > > NativeJavaConstructor.java inside NativeJavaMethod.java
> > > >
> > > > /*** Call in NativeJavaMethod.java
> > > > public Object call(Context cx, Scriptable scope, Scriptable thisObj,
> > > > Object[] args)
> > > > throws JavaScriptException
> > > > {
> > > > // Eliminate useless args[0] and unwrap if required
> > > > for (int i = 0; i < args.length; i++) {
> > > > if (args[i] instanceof Wrapper) {
> > > > args[i] = ((Wrapper)args[i]).unwrap();
> > > > }
> > > > }
> > > >
> > > > // Find a method that matches the types given.
> > > > if (methods.length == 0) {
> > > > ****/
> > > >
> > > > Is this correct ? I presume it is because of the fact that the
constructor
> > > > does this.
> > > >
> > > > Any luck with my other question regarding generalizing the WrapHandler
to all
> > > > objects (including those returned by scriptable) and not only those
returned
> > > > through nativeJava***
> > > >
> > > > ThanX,
> > > >
> > > > Mukund Balasubramanian
> > > >
> > > > Norris Boyd wrote:
> > > >
> > > > > Could you post your proposed patch?
> > > > >
> > > > > Thanks,
> > > > > Norris
> > > > >
> > > > > Mukund Balasubramanian wrote:
> > > > >
> > > > > > Hi all,
> > > > > > I am trying to play around with writing a custom WrapHandler for
my
> > > > > > Java objects in Rhino. I found WrapHandler very useful.
> > > > > > Now I am stuck at a point where, even though my wrappers
implement
> > > > > > "Wrapper", they get unwrapped only on calles to Constructors using
> > > > > > Liveconnect. Normal methods dont seem to be doing any unwrapping.
> > > > > > Managed to build rhino with a bug fix (cut and paste code from
> > > > > > NativeJavaConstructor to NativeJavamethod), and it works.
> > > > > > Just wanted to verify if it is a known bug (while I wait for
> > > > > > bugzilla to mail me a passwd).
> > > > > >
> > > > > > BTW, also found something interesting, WrapHandler gets called only
when
> > > > > > the object is returned from NativeJava***, not ANY Object. Is that
the
> > > > > > way it is supposed to work ??
> > > > > >
> > > > > > ThanX for any help,
> > > > > >
> > > > > > Mukund Balasubramanian
rogerl%netscape.com
jeff.dyer%compilercompany.com
jband%netscape.com
waldemar%netscape.com
brendan%mozilla.org
nboyd%atg.com
matthias%sorted.org
sspitzer%netscape.com
beard%netscape.com
kin%netscape.com
mccabe%netscape.com
bryner%uiuc.edu
pschwartau%netscape.com