116 Commits

Author SHA1 Message Date
igor%mir2.org
5188320068 1. To evaluate script represented by String, use Context.evaluateString to avoid the need to create StringReader instances.
2. Catch VirtualMachineError so on out-of-memory/stack-overflow the shell will exit with System.exit(EXITCODE_RUNTIME_ERROR), not with 1. It will allow to distinguish cases when script tried to consume all available stack/memory with bugs in Rhino itself leading to NullPointerException etc.

3. Remove code to rethrow ThreadDeath from JavaScriptExcception since ThreadDeath is re-thrown by the engine itself.
2003-07-06 19:21:42 +00:00
igor%mir2.org
df5af91220 Updating exception debugging to reflect changes due to http://bugzilla.mozilla.org/show_bug.cgi?id=210605 . 2003-07-02 16:37:29 +00:00
igor%mir2.org
fde9643eed Addition of seal function to Rhino shell to seal all supplied arguments. 2003-05-19 15:53:23 +00:00
igor%mir2.org
3f84d7fe70 Resolving http://bugzilla.mozilla.org/show_bug.cgi?id=203013 :
Changing behavior of sealed objects to throw an exception on any attempt to modify them including changing values of existing properties. In the same time making object sealed does not affect read-only status of its properties which allows to override properties of objects with a sealed object as a prototype.

Rhino shell now accepts -sealedlib option to seal all standard objects.
2003-05-16 14:25:57 +00:00
nboyd%atg.com
09fe5de968 Fix bug 202344 (which was not fully fixed by the previous change.) 2003-04-21 19:43:45 +00:00
nboyd%atg.com
9f67dc975f Fix bug 202344. 2003-04-21 14:59:22 +00:00
igor%mir2.org
58a609ac23 Patch from Steven Beal fixing a bug due to my changes:
I just noticed that the changes introduced with
v1.29 of Main.java broke the ability to do hot
reloads of scripts.  To be more explicit, the script
is actually reloaded but the source in the debugger
is not updated to reflect the newly loaded code.
...
Attached is a patch that restores the original behavior.
The refactorings are preserved but the handling of
previously loaded SourceInfo objects is restored and the
check for previously loaded ScriptItem instances
removed.
2003-02-13 03:01:09 +00:00
igor%mir2.org
615d6d6623 Do not call setSelectedIndex on frame JList if there are no frames. 2003-01-26 18:33:30 +00:00
igor%mir2.org
ae4b000c3f Added documentation strings for runCommnad and spawn is changed to pass empty argument array instead of null if function arguments are not specified to avoid a null pointer exception in InterpretedFunction.call 2003-01-26 18:28:26 +00:00
igor%mir2.org
7b5c64a220 Added runCommand to execute external processes 2003-01-26 15:43:50 +00:00
igor%mir2.org
3b9a6fe0ef Patch from Christopher Oliver to fix http://bugzilla.mozilla.org/show_bug.cgi?id=189183 2003-01-20 15:09:45 +00:00
igor%mir2.org
d8492658bb Committing patch from Steven Beal:
Have you considered adding a "Go" method to Main.java with
public visibility (same behavior as pressing the "Go" button in the debugger UI).

This would be a big help in a system where the debugger has been
embedded.  Being able to close the debugger and ensure that any
breakpoints were removed and any blocked threads notified would
be a nice feature.  Without this, closing the debugger can either
a) halt the application or b) destroy the debugger leaving blocked
threads in a permanent wait state.  Note that the debugger is
not actually destroyed in this case because the waiting threads
prevent it from being wholly GCed.
2003-01-15 10:42:56 +00:00
igor%mir2.org
71741a82b8 Fixing mnemonics shortcuts for Debug menu 2003-01-14 14:44:46 +00:00
igor%mir2.org
b9e26a25cb From Steaven Beal:
This looks like a simple case of using the Hashtable key
instead of the value...

    public void clearAllBreakpoints() {
        // Igor - Use of keys() is inappropriate here.  It produces
        // a ClassCastException on the assignment below.  The
        // keys are String instances, not SourceInfo instances...
        //
        //Enumeration e = sourceNames.keys();
        Enumeration e = sourceNames.elements();
	...
    }
2003-01-14 11:24:47 +00:00
igor%mir2.org
b0dd32ca85 Deprecating ClassOutput in favor of ClassRepository and Context methods to access ClassNameHelper functionality in favor of directly calling ClassNameHelper methods. For that I changed ClassNameHelper from interface to abstract class and added ClassNameHelper.get(Context cx) method to get name helper object that is used for the given Context object. 2002-12-31 18:21:32 +00:00
igor%mir2.org
34427cc0a9 Allow application to customize class loader used for loading generated code.
For that I added new method createClasssLoader to Context, which by default returns new instance of DefiningClassLoader and changed the code to use this method instead of creating DefiningClassLoader directly. I moved DefiningClassLoader to org.mozilla.javascript package so core Rhino classes would not depend on org.mozilla.classfile package. I also changed SecurityController.createClasssLoader to take additional parentLoader argument to explicitly specify which class loader should be parent for generated code.
2002-12-31 09:42:42 +00:00
igor%mir2.org
d90d743307 Fixing design flaw in SecurityController:
The new SecurityController in its current form does not allow to define more then one generated class class in the same class loader effectively preventing to use optimizer which needs to define classes that refer each other and should be defined in the same loader.

To fix this I replaced the defineClass method in SecurityController by
    public GeneratedClassLoader createClassLoader(Object securityDomain);
which returns instance of the new GeneratedClassLoader interface which can be used to define several classes. I also made DefiningClassLoader to implement this interface to simplify code in JavaAdapter.java and optimizer/Codegen.java.
2002-12-28 05:37:43 +00:00
igor%mir2.org
ec811806ab Cosmetics: expanding tabs 2002-12-17 20:56:08 +00:00
igor%mir2.org
b99f98d8e9 Cosmetics: removal of junk white-space at line end 2002-12-17 20:48:35 +00:00
igor%mir2.org
8ae4899263 Fixing http://bugzilla.mozilla.org/show_bug.cgi?id=184111
Patch from Marcus Crafter:
...
After speaking with Christopher Oliver, the problem seems to be a general JDK
1.4 bug that caches selected values in JComboBox, even after removeAllItems() is
called. Since its a general defect Christopher and I thought we'd report and get
it fixed in the main CVS tree.
...
2002-12-08 21:06:45 +00:00
igor%mir2.org
50029c37e2 If debugger does not get function or script source via handleCompilationDone, try to read it from supplied URL. 2002-12-08 20:49:39 +00:00
igor%mir2.org
9be5d10e5c Replace getScriptable() by getFunctionName() in omj/debug/DebuggableScript.java as the debugger used DebuggableScript.getScriptable() only to query function names.
It allows to implement the DebuggableScript interface only  by omj/InterpreterData instead of 2 identical implementations by InterpretedFunction and InterpretedScript.
2002-11-14 21:12:36 +00:00
igor%mir2.org
efd9f298ab Call NativeArray.getLength() instead of deprecated NativeArray.jsGet_length() 2002-11-12 09:41:09 +00:00
igor%mir2.org
7ad5c25d66 Fixing ArrayIndexOutOfBoundsException reported by Steven Beal caused by broken code to setup endLine in SourceInfo.updateLineInfo. 2002-08-15 06:42:45 +00:00
igor%mir2.org
988587183a New security implementation. 2002-07-04 21:40:12 +00:00
igor%mir2.org
77af40f3ba From the email:
The attached patch adds support for debugging eval and Function code transparently. It changes omj.NativeGlobal and omj.BaseFunction to embed  line number of origin of eval and Function scripts into source name and pass 1 as base line for script code. In this way a debugger implementation can treat eval and Function code in the same way as scripts loaded from some url while giving more information about error location in case of an error in eval code as the error source would contain both line number of eval origin and line number in eval code itself.
I chose to embed line numbers via patterns like

sourcefile#<line-number>(eval)
sourcefile#<line-number>(Function)

just to be able to to pass the constructed name to URL constructor if the original sourcefile is a valid URL but it is pretty arbitrary.
2002-05-20 11:40:17 +00:00
igor%mir2.org
4bb3f8ada0 Elimination of FileWindow.breakpoints and Main.breakpointsMap as reference to SourceInfo provides all necessary information 2002-05-11 18:28:44 +00:00
igor%mir2.org
ba0661c493 Removing itsFirstLine and itsEndLine from InterpreterData and replacing in DebuggableScript getFirstLine, getEndLine and getIntructionLines by getLineNumbers as Debugger imlementation can get all the necessary information from single call to getLineNumbers 2002-05-11 16:15:50 +00:00
igor%mir2.org
6d860f39e3 From email about moving breakpoint support away from Rhino core:
I attach the patch to move away setting/quering for breakpoints from the Rhino core to application as a debugger implementation can check if a particular line has a breakpoint or not. The changes to omj/tools/debugger takes more then few lines I initially thought but they are mostly caused by refactoring to implement different view to set/query breakpoints.

The patch replaces getLineNumbers, placeBreakpoint and removeBreakpoint in DebuggableScript by getFirstLine, getEndLine and getInstructionLines where the last function fills a boolean array to indicate which script lines can ever occur in DebugFrame.onLineChange. These are read-only functions so InterpeterData are never mdofied by the debugger.

omj/tools/debugger/Main uses this information to check whether it is possible to place breakpoint at a particular line, and if possible, it sets to true entry at the boolean breakpoint array. In this way testing for break in onLineChange is simple and fast as it just needs to check if breakpoint array holds true at the given line number position.
2002-05-10 16:17:33 +00:00
igor%mir2.org
aa545a86e2 Replace when possible usage of API available only since JDK 1.2 by their JDK 1.1 analogous or by classes available in the Rhino core to make port to JDK 1.1 easier. 2002-05-03 19:42:36 +00:00
igor%mir2.org
fe448dc961 Updating the debugger to reflect changes in Rhino debug API. 2002-04-22 20:47:51 +00:00
igor%mir2.org
760e4b4196 Clear jiles warning:
VariableModel.java:220:30:220:40: Caution: This try block cannot throw a "checked exception" (JLS section 14.7) that can be caught here. You may have intended to catch a RuntimeException instead of an Exception.
2002-04-06 17:33:33 +00:00
igor%mir2.org
c31e40fc89 From the email about debug API changes:
Changes to omj.tools.debugger are mostly due to renames and refactoring, the new code is limited to ContextData class which contains simplified version of the code for DebugFrame stack from the current DebuggableEngineImplementation and FrameHelper class implementing DebugFrame.
2002-04-06 13:57:24 +00:00
nboyd%atg.com
750bfdb52c Patch from Chris Oliver:
Hi Norris,

Can you check in the attached Main.java which works around a problem with using
JTreeTable in JDK 1.4.

Thanks,

Chris
2002-04-01 22:12:11 +00:00
nboyd%atg.com
b9766e8169 Changes from Christopher Oliver:
Hi Norris,

Would you mind checking in the attached changes to the debugger. The
attached files include the following changes:

1) Use ScriptableObject.getAllIds to obtain an object's properties (if
the object extends ScriptableObject).  This makes non-enumerable
properties visible in the debugger for ScriptableObject's.
2) Made the coding style more consistent with the rest of Rhino.
3) Better support for displaying and stepping through eval-ed code.

As Igor suggested to me once, it might be a good idea to define a new
interface to similarly support debugging host objects that don't extend
ScriptableObject, something like the following:

public interface Debuggable extends Scriptable {
    public Object[] getAllIds();
}

The debugger could check for this interface and if a host object chose
to implement it, the debugger would be able to display its
non-enumerable properties.

Chris
2002-03-26 23:02:43 +00:00
nboyd%atg.com
4b432d7521 Add missing support for multiple -implements classes 2002-03-24 22:37:57 +00:00
timeless%mac.com
dec943eb10 Bug 106386 rid source of misspellings
r=db48x sr=blake a=asa
2002-03-19 04:30:17 +00:00
igor%mir2.org
d262e89e9f Added .cvsignore to ignore generated sources 2002-03-16 23:34:23 +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
nboyd%atg.com
d7f0af7c79 Have ClassNameHelper object be allocated lazily 2002-02-05 13:47:16 +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
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
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
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
bcf8c2b632 Move serialization classes to separate package. 2001-09-29 20:54:08 +00:00
nboyd%atg.com
212d1b132a Add support for serialization and deserialization. 2001-09-27 02:33:51 +00:00