nsIComponentRegistrar.
2. Converts callers of nsComponentManager::AutoRegister to use
nsIComponentRegistrar's autoRegistrar method.
3. Add nsIComponentRegistrar implmentation to nsComponentManagerImpl.
4. Rearrange nsComponentManager.cpp so that related methods are in the same
place.
5. Added a C-style function NS_GetComponentRegistrar so that getting the
registrar is easier in some places.
6. Added a nsISimpleEnumerator interface on PLDHashTableEnumeratorImpl. in
this way, the same base class can support both old style and new style
enumerations.
7. Fixed a nasty bug where unregistring factories will leave the contract id
hash with a dangling pointer. Now, when unregister is called we search the
contract id hash for entries which have the given doomned cid and remove them.
Bug 115853. r=dp@netscape.com, sr=rpotts@netscape.com
implement the jsdIContext interface.
create only one jsdValue wrapper per unique jsval.
add executionContext property to jsdIStackFrame.
add enumerateContexts to jsdIDebuggerService.
add jsdIContextEnumerator interface.
adds jsdIDebugHook interface, change the meaning of jsdIErrorHook.
error hook is called when an error occurs, and is given information about the error report.
debug hook is called when/if the error hook returns false, and is given information about the ececution state.
Thanks!
As promised, I tried the debugger this afternoon and I had a problem with the '-f' option.
We use -f to run a standard "startup" script before executing the "main" script. For
example, we run the Rhino shell with the options "-f startup.js main.js".
When running the debugger's shell with the same options the debugger exits after the
startup.js completes; i.e., I can single step starting from startup.js but the debugger
exits at the end of startup.js without letting me single step into main.js. This worked
fine in the 1.5R2 release of Rhino and the debugger.
I have not had a chance to look into the problem closely, but a cursory look at the code
suggests (to me) that the problem can be in either the debugger or the shell (since the
debugger basically runs the shell after creating the right "hooks".) Of course, it could
also be a problem with my embedding.
So ... my question is, has anyone tried single stepping when the options to the debugger
include a '-f' option. If so, I'll continue to look for a problem in my embedding.
Any suggestions would be appreciated.
Thanks,
dave
Norris,
I realize this is probably a nuisance, but the following problem causes our
regression test suite to fail:
js> foo = new Error("bar")
undefined: bar
js> foo.name Error
js> foo.toString()
undefined: bar
Our test suite expects:
js> foo = new Error("bar")
Error: bar
js> foo.name Error
js> foo.toString()
Error: bar
I have not yet tried the debugger with the RC2 release, but I expect to get
to that later today.
I hope I'm not to late to influence the 1.5R3 release.
Thanks,
dave
understand exactly what the problem is here, and it does not seem to
happen on gcc 2.96, and 2.95 doesn't have the alias optimizations that
called for the new code in the first place, just make 2.95 use the old
code. r=timeless, sr=brendan.
We have found a problem in string.replace() when replacing a regular
expression with a dollar sign. The following code works right when the
replacement string does not contain "$":
$ java -jar js.jar
js> var re = new RegExp("%%%");
js> var price = "%%% 1.99";
js> price.replace(re, "USD");
USD 1.99
js> price.replace(re, "$");
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException
at
org.mozilla.javascript.regexp.ReplaceData.interpretDollar(RegExpImpl.java:40 0)
at
org.mozilla.javascript.regexp.ReplaceData.findReplen(RegExpImpl.java:502)
at
org.mozilla.javascript.regexp.RegExpImpl.replace(RegExpImpl.java:116)
at
org.mozilla.javascript.NativeString.execMethod(NativeString.java:266)
at org.mozilla.javascript.IdFunction.call(IdFunction.java:78)
at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1222)
at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:1940)
at
org.mozilla.javascript.InterpretedScript.call(InterpretedScript.java:68)
at
org.mozilla.javascript.InterpretedScript.exec(InterpretedScript.java:59)
at org.mozilla.javascript.Context.evaluateReader(Context.java:773)
at
org.mozilla.javascript.tools.shell.Main.evaluateReader(Main.java:312)
at
org.mozilla.javascript.tools.shell.Main.processSource(Main.java:219)
at org.mozilla.javascript.tools.shell.Main.exec(Main.java:106)
at org.mozilla.javascript.tools.shell.Main.main(Main.java:68)
We are converting from spidermonkey to rhino and it appears that the
name property for the constructor function returns "constructor" for
all builtin types. Spidermonkey would return "Date" or "Array" or
whatever. Is there a workaround? This code needs to work with both
interpreters.
Here is an example of the rhino behavior:
js> var i=new Date;
js> i.constructor.name
constructor
js> Date.name
constructor
js> function bob(){}
js> bob.name
bob
js> var i = new Array();
js> i.constructor.name
constructor
js>
nboyd%atg.com
jband%netscape.com
pschwartau%netscape.com
seawood%netscape.com
igor%mir2.org
brendan%mozilla.org
rginda%netscape.com
sfraser%netscape.com
dougt%netscape.com
rogerl%netscape.com
jst%netscape.com
bratell%lysator.liu.se
beard%netscape.com
dbaron%fas.harvard.edu
dbradley%netscape.com
bryner%netscape.com
alecf%netscape.com
timeless%mac.com