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.
nboyd%atg.com
rginda%netscape.com
jst%netscape.com
bratell%lysator.liu.se
pschwartau%netscape.com
brendan%mozilla.org
sfraser%netscape.com
beard%netscape.com
dbaron%fas.harvard.edu
rogerl%netscape.com
seawood%netscape.com
dbradley%netscape.com
jband%netscape.com
bryner%netscape.com
alecf%netscape.com
timeless%mac.com
igor%mir2.org
dougt%netscape.com
jaggernaut%netscape.com
pavlov%netscape.com
ccarlen%netscape.com
bzbarsky%mit.edu
mkaply%us.ibm.com