Граф коммитов

734 Коммитов

Автор SHA1 Сообщение Дата
nboyd%atg.com ef0947a309 Fix build problem in batik:
[javac] Compiling 1427 source files to /data/gump/xml-batik/classes
 [javac] /data/gump/xml-batik/sources/org/apache/batik/script/rhino/EventTargetWrapper.java:81:
coerceType(java.lang.Class,java.lang.Object,boolean)
in org.mozilla.javascript.NativeJavaObject cannot be applied to
(java.lang.Class,java.lang.Object)
2002-02-13 03:07:31 +00:00
igor%mir2.org 3c6a4b6df9 Making final for performance reasons 2002-02-13 01:41:11 +00:00
nboyd%atg.com 9cdc547eaa Add new Context method "toType" to convert to a specified Java type 2002-02-12 14:30:27 +00:00
nboyd%atg.com 797571ad23 Fix 124900 2002-02-12 14:29:30 +00:00
igor%mir2.org b20f228b29 cosmetics: end-of-line whitespace removal 2002-02-11 01:33:23 +00:00
igor%mir2.org 142bcdb900 tabs -> spaces 2002-02-11 00:02:14 +00:00
igor%mir2.org dd9357bec7 Avoid unnecessary calls to Context.getContext() by passing Context directly as an argument 2002-02-10 21:10:35 +00:00
igor%mir2.org 582b069550 Always use try/finally to wrap Context.exit 2002-02-10 21:09:42 +00:00
nboyd%atg.com 7eff00208f * Avoid creating a ClassNameHelper when turning caching off.
* When turning debug generation on, don't change opt level from -1 to 0.
2002-02-07 17:54:57 +00:00
nboyd%atg.com d7f0af7c79 Have ClassNameHelper object be allocated lazily 2002-02-05 13:47:16 +00:00
nboyd%atg.com dc8951753b Don't hold a static reference to a ClassLoader that will prevent JavaAdapter classes
from being unloaded.
2002-02-05 13:37:50 +00:00
nboyd%atg.com dbc9ade56d Clean up formatting. 2002-02-04 18:58:03 +00:00
nboyd%atg.com 80650f2d25 Change version to 1.5R4pre. 2002-02-04 15:26:31 +00:00
igor%mir2.org febdace285 Use heapsort instead of qsort for Array.sort to follow JS for reasons described in http://bugzilla.mozilla.org/show_bug.cgi?id=99120 2002-01-31 10:08:17 +00:00
igor%mir2.org 03c7c86042 Stricter enter/exit: enter performs sanity checks on supplied Context and the exit requires previous enter. 2002-01-29 22:58:22 +00:00
igor%mir2.org 7ca511bab3 Few Native* classes are made package private and final. They had been public only for implementation reasons. 2002-01-29 18:40:13 +00:00
igor%mir2.org 86947ddec0 Use ScriptRuntime.toString(double) to convert double to string. Easier to follow version of getElem/setElem 2002-01-29 09:44:24 +00:00
nboyd%atg.com 044c888b5f Update implementation version. 2002-01-28 00:52:12 +00:00
nboyd%atg.com a2254d8379 Clean up formatting. 2002-01-26 20:07:49 +00:00
nboyd%atg.com eec81fb952 Fix bug 121790 2002-01-26 19:15:06 +00:00
nboyd%atg.com cf94c28b89 Fix formatting 2002-01-26 19:13:22 +00:00
nboyd%atg.com d7e41aff99 UPdate implementation version 2002-01-24 20:17:05 +00:00
nboyd%atg.com f79730a30a Fix out-of-date javadoc. 2002-01-24 19:57:52 +00:00
nboyd%atg.com c24a699dd8 Fix the following problem:
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
2002-01-24 19:57:01 +00:00
nboyd%atg.com b0c8c14266 Fix bug:
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
2002-01-19 17:43:26 +00:00
nboyd%atg.com 83fc380ff9 Add link to article with Rhino. 2002-01-16 16:07:12 +00:00
nboyd%atg.com 14c34495ad Update for 1.5R3. 2002-01-15 17:35:09 +00:00
nboyd%atg.com 0328c83836 Fix bug 118636: Date format 2002-01-09 15:21:31 +00:00
nboyd%atg.com d30ebd31a8 Fix bug:
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)
2002-01-09 15:20:48 +00:00
nboyd%atg.com 0e0079e943 Fix doc bug. 2002-01-08 20:11:53 +00:00
nboyd%atg.com 302f3a0ca7 Update implemenation version date. 2002-01-04 14:04:42 +00:00
nboyd%atg.com 4476a490b1 Fix bug reported by rathje40@yahoo.com
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>
2002-01-04 14:04:01 +00:00
nboyd%atg.com bbb7be562e Remove override that is duplicate of superclass. 2002-01-04 14:02:36 +00:00
nboyd%atg.com 15ce244c1d Print implementation version when starting up interactive mode. 2002-01-04 14:02:02 +00:00
igor%mir2.org 30dfb0a96f Use Vector.elementAt instead of Vector.getfor jdk 1.1 complience 2001-12-20 22:05:42 +00:00
igor%mir2.org d6078a18da Fixes to allow to use jikes to compile and produce less warnings:
1. Replace catch(Exception) by catch(RuntimeException) when only RuntimeException can be throws

2. Make sure that inner classes does not use the same name for parameters as parent scope, see  http://domino.watson.ibm.com/syssftpr/JavaTech/Jikes.nsf/Named/SunQuery8
2001-12-20 21:15:02 +00:00
nboyd%atg.com c348be84db Added comment about bug 115717. 2001-12-19 15:31:56 +00:00
nboyd%atg.com 8114e3ffba Fix formatting. 2001-12-13 15:27:16 +00:00
nboyd%atg.com cd3ab305ae Fix bug 114491: if (true) function f(){}() 2001-12-12 14:16:57 +00:00
nboyd%atg.com 1bd9822564 Fix bug 114493: "3"[5](); 2001-12-11 14:16:13 +00:00
nboyd%atg.com d120758a27 Fix memory leak of class names--reset every time we get a new ClassLoader. 2001-12-11 14:13:55 +00:00
nboyd%atg.com bbc1ee2679 Updates for Rhino1.5R3. 2001-12-06 14:53:59 +00:00
nboyd%atg.com e795599799 Update release number, date. 2001-12-06 14:33:44 +00:00
nboyd%atg.com 44b02edcc8 Change version to 1.5R3. 2001-12-06 14:27:26 +00:00
nboyd%atg.com 82fd57b5aa Hello !
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
2001-12-06 14:26:26 +00:00
nboyd%atg.com 6a01600cc8 JavaAdapter serialization contribution from Kemal Bayram. 2001-11-23 20:40:08 +00:00
nboyd%atg.com b52f96cd91 Hi, Norris!
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
2001-11-23 20:38:50 +00:00
nboyd%atg.com 4ef25a301c Hi,
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
2001-11-22 15:48:21 +00:00
nboyd%atg.com 46b8e5185c Hi,
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>
2001-11-21 17:12:57 +00:00
nboyd%atg.com e60c42afed Patch from Igor:
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.
2001-11-07 14:15:48 +00:00