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>
a) create a new nsIComponentManager with only four functions on it:
CreateInstance CreateInstanceByContractID GetClassInfo GetClassInfoByContractID.
b) rename the old nsIComponentManager to nsIComponentManagerObsolete.
c) fixes callers which use to access the nsIComponentManager for component
registration functionality. These callers will temporary use the
nsIComponentManagerObsolete interface.
d) Create a new API NS_GetComponentManager() which mirrors the
NS_GetServiceManager()
e) Perserves the old NS_GetGlobalComponentManager(). Note the cast usage.
r/sr = rpotts@netscape.comalecf@netscape.combrendan@mozilla.org
* Adds Makefile.ins to win32 specific dirs
* Adds WINNT ifdefs to Makefile.ins
* Causes NSPR to be compiled with --with-mozilla
* Misc general Makefile.in cleanup
Bug #58981 r=mcafee
I'm the maintainer of JPackage project rhino package (see
jpackage.sourceforge.net). I just found two problems for building it (version
1.52 from cvs):
- the property src.debugger is badly initialised in toolsrc/build.xml. See
patch attached for correction. Moreover, this was a real pain to make offline
building possible. I guess it's a licensing problem that prevents you
including those files in rhino sources ?
- the produced javadoc has an empty (0 sized) package-list file. Have you got
any idea why ?
-- Guillaume Rousse <rousse@ccr.jussieu.fr>
GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html
In our browser we need to support scripts that use as an identifier name future reserved keywords such as interface. The scripts are rather old and perfectly legal under previous revisions of EcmaScript which does not included the list of almost every Java keyword to the future reserve.
To support this I added an option to query Context.hasFeature for FEATURE_RESERVED_KEYWORD_AS_IDENTIFIER:
/**
* if hasFeature(RESERVED_KEYWORD_AS_IDENTIFIER) returns true,
* treat future reserved keyword (see Ecma-262, section 7.5.3) as ordinary
* identifiers but warn about this usage
*/
public static final int FEATURE_RESERVED_KEYWORD_AS_IDENTIFIER = 3;
The corresponding code in TokenStream checks for it and issues just a warning when this feature is enabled.
I also think that it would be better not to return RESERVED as a token from TokenStream.getToken but report the specific syntax error immediately because it is very unclear from the error message:
js> x.interface = 1
js: "<stdin>", line 1: uncaught JavaScript exception: SyntaxError: missing name after . operator (<stdin>; line 1)
js: x.interface = 1
js: ..........^
what exactly went wrong. I can send a patch later for that.
Regards, Igor
I'm working on a project which uses rhino. I wanted to have finer
control over class generation and saving so I've done some patching
and clean up on the current rhino tip.
The biggest change I've made is the replacement of ClassOutput with
ClassRepository that has the single method:
public boolean storeClass(String className, byte[] classBytes,
boolean isTopLevel) throws IOException;
This interface allows any arbitary storage method, such as a
Hashtable/Map. In addition it also allows you to specify whether a
class should be loaded, via returning true or false. You can still use
ClassOutput as I've coded an internal wrapper.
With this interface it has also been possible to strip out the file
saving code from Codegen and OptClassNameHelper. The file
saving code is now an inner class FileClassRepository in Context. As
a consequence of this I've stripped out some methods from ClassNameHelper.
The resulting code is much more cleaner then before hand and everything
still works as per usual.
Other small additions are:
o Annonymous functions are now named class$1 instead of class1
o get/setClassName added to ClassNameHelper exposed in Context.
My final thoughts are, since all methods in ClassNameHelper except reset()
are now exposed whould n't it be much more "cleaner" to simply to some
how work around to eliminate reset() and provide getClassNameHelper()
via Context? You could then remove the numerous ClassNameHelper shadow
methods from Context.
Likewise, FileClassRepository could be made a public class very easily
and combined with the above result in a dozen or so less public methods in
Context.
Anyway, the changes can be found on http://www.cins.co.uk/rhino.zip
Hope it is of use to some
Kemal Bayram
I'm working on a project which uses rhino. I wanted to have finer
control over class generation and saving so I've done some patching
and clean up on the current rhino tip.
The biggest change I've made is the replacement of ClassOutput with
ClassRepository that has the single method:
public boolean storeClass(String className, byte[] classBytes,
boolean isTopLevel) throws IOException;
This interface allows any arbitary storage method, such as a
Hashtable/Map. In addition it also allows you to specify whether a
class should be loaded, via returning true or false. You can still use
ClassOutput as I've coded an internal wrapper.
With this interface it has also been possible to strip out the file
saving code from Codegen and OptClassNameHelper. The file
saving code is now an inner class FileClassRepository in Context. As
a consequence of this I've stripped out some methods from ClassNameHelper.
The resulting code is much more cleaner then before hand and everything
still works as per usual.
Other small additions are:
o Annonymous functions are now named class$1 instead of class1
o get/setClassName added to ClassNameHelper exposed in Context.
My final thoughts are, since all methods in ClassNameHelper except reset()
are now exposed whould n't it be much more "cleaner" to simply to some
how work around to eliminate reset() and provide getClassNameHelper()
via Context? You could then remove the numerous ClassNameHelper shadow
methods from Context.
Likewise, FileClassRepository could be made a public class very easily
and combined with the above result in a dozen or so less public methods in
Context.
Anyway, the changes can be found on http://www.cins.co.uk/rhino.zip
Hope it is of use to some
Kemal Bayram <rhino@cins.co.uk>
I suggest to move the code in ScriptableObject.get/put that deals with getter/setter
into separated methods so it would be easy to follow the code and the attached patch
does just that.
