mozilla/js/rhino/org is now distributed between
mozilla/js/rhino/src and mozilla/js/rhino/toolsrc.
The build.xml has been split in three.
Docs now live in the project directory.
These changes mean that the cvs directories mirror the distribution and thus a distribution
will build the same way as a cvs build.
Minor fix to JSDebugger
Date:
Wed, 28 Mar 2001 16:34:24 -0800
From:
Christopher Oliver <coliver@mminternet.com>
Organization:
Primary Interface LLC
To:
nboyd@atg.com
Hi Norris,
Attached is a minor fix to the JSDebugger GUI that causes the tool-bar buttons to all have the same width.
I checked out and modified a file from CVS today. See the screenshot below.
Cheers,
Chris
* fixed ImporterTopLevel constructor - it now calls
cx.initStandardObjects before defining any functions. The old
constructor is still around for backwards compatibility.
Re: Debugger problem
Date:
Mon, 08 Jan 2001 14:16:30 -0800
From:
Christopher Oliver <coliver@mminternet.com>
Organization:
Primary Interface LLC
To:
Kurt Westerfeld <kurt@ManagedObjects.com>
CC:
Norris Boyd <nboyd@atg.com>
References:
1 , 2 , 3
Kurt, Norris,
Yes, with the change to the shell this should be possible. The problem before
was that if you loaded the same file with different relative path names, two
different windows in the debugger were created because everything (windows,
breakpoints, etc) is keyed off the source name.
The attached file contains the fix (and includes the workaround for
Desktop.getSelectedFrame).
There are still some bugs in transferring focus between the windows in the
Desktop. I haven't had time to track down the problem or a solution.
Chris
Kurt Westerfeld wrote:
> I would point out that "Source Name" of a script isn't necessarily a
> filename. In our system, scripts are run remotely from a script library
> that has no file system backing. Canonicalizing the file names is really
> unnecessary.
>
> Can't you just modify JSDebugger to not care what the name of the file is?
> If access to the original script is unavailable except through the file
> system, I'd be surprised.
>
> ----- Original Message -----
> From: Christopher Oliver <coliver@mminternet.com>
> To: Kurt Westerfeld <kurt@ManagedObjects.com>
> Cc: Norris Boyd <nboyd@atg.com>
> Sent: Sunday, January 07, 2001 2:23 AM
> Subject: Re: Debugger problem
>
> > Hi Kurt,
> >
> > I rather would say that it is a problem with the processFile method in the
> > shell's Main class. If you change the current working directory or the
> value
> > of the System property "user.dir" after compiling a script, relative path
> names
> > can become ambiguous. Norris, would it be ok to modify the shell to
> > "canonicalize" the names of files it compiles? That way the source name
> that
> > shows up in the stack and in DebuggableScript will always be unique. For
> > example:
> >
> > public static void processFile(Context cx, Scriptable scope,
> > String filename)
> > {
> > Reader in = null;
> > try {
> > in = new PushbackReader(new FileReader(filename));
> > int c = in.read();
> > // Support the executable script #! syntax: If
> > // the first line begins with a '#', treat the whole
> > // line as a comment.
> > if (c == '#') {
> > while ((c = in.read()) != -1) {
> > if (c == '\n' || c == '\r')
> > break;
> > }
> > ((PushbackReader) in).unread(c);
> > } else {
> > // No '#' line, just reopen the file and forget it
> > // ever happened. OPT closing and reopening
> > // undoubtedly carries some cost. Is this faster
> > // or slower than leaving the PushbackReader
> > // around?
> > in.close();
> > in = new FileReader(filename);
> > }
> > filename = new java.io.File(filename).getCanonicalPath();
> > <<<====== Add this
> > }
> > catch (FileNotFoundException ex) {
> > Context.reportError(ToolErrorReporter.getMessage(
> > "msg.couldnt.open",
> > filename));
> > exitCode = EXITCODE_FILE_NOT_FOUND;
> > return;
> > } catch (IOException ioe) {
> > globalState.getErr().println(ioe.toString());
> > }
> >
> > // Here we evalute the entire contents of the file as
> > // a script. Text is printed only if the print() function
> > // is called.
> > evaluateReader(cx, scope, in, filename, 1);
> > }
> >
> >
> > Attached is *my* latest version of the debugger code. Norris, have you
> made
> > any progress on cvs commit priveledges? The attached version fixes a
> number of
> > GUI bugs:
> >
> > 1) If you undocked the Variables window and popped up the Context
> combo-box and
> > then closed the window with the system menu, the Context pop-up was not
> cleaned
> > up properly.
> > 2) The first time you minimize a file window it appeared to dissappear
> when you
> > tried to restore it. This was due to the fact that I forgot to "pack" its
> > contents and as a result its requested size was 0x0.
> >
> > I also added a menu item to toggle whether to break on exceptions and one
> which
> > allows you to open (and compile) a JavaScript file without actually
> executing
> > it.
> >
> > I have also attached a Word document with some basic documentation for the
> > Debugger.
> >
> > Note that this version also includes all the changes to support debugging
> > scripts in the AWT dispatch thread.
> >
> > Chris
> >
> > Kurt Westerfeld wrote:
> >
> > > Hello. I ran into a null pointer exception in JSDebugger tonight, and I
> > > thought I'd drop you a note.
> > >
> > > The problem line is 2336, where a breakpoint is hit. To simulate, load
> the
> > > debugger using the command line syntax on a file that has not been
> resolved
> > > to cannonical path.
> > >
> > > Example,
> > >
> > > jshell -debug -f \myfile.fs
> > >
> > > At any rate, the "handleCompilationDone" routine takes \myfile.fs and
> turns
> > > it into a canonical path. If you hit a breakpoint in this file and say
> > > "go", when the breakpoint hits the file is not found, because the same
> > > canonical path resolution is not done. The resolution seems dubious,
> since
> > > it is only done in the compilation done callback, but I don't know the
> best
> > > way to suggest a fix since it seems that code had some purpose.
> > >
> > > Anyway, thought you'd wanna know.
> > >
> > > ________________________________________________________________________
> > > Kurt Westerfeld
> > > Senior Software Architect
> > > Managed Objects
> > > mailto:kwester@ManagedObjects.com
> > > 703.770.7225
> > > http://www.ManagedObjects.com
> > >
> > > Managed Objects: manage technology > rule business
> >
JSDebugger.java
Name:
JSDebugger.java
Type:
Java Class File (java/*)
Encoding:
base64
* Make use of DebuggableEngine interface to keep Context API smaller
* Change org.mozilla.javascript.debug.Frame to DebugFrame to avoid
confusion with java.awt.Frame
updated Global, Main and ImporterTopLevel
Date:
Mon, 23 Oct 2000 14:37:45 +0100
From:
Matthias Radestock <matthias@lshift.net>
To:
nboyd@atg.com
Norris,
I've made some more changes to shell.Main and shell.Global in order to
reduce their mutual dependency, enable "quit" and get "load" to operate
in the local scope.
see attachments for updated .diffs.
Matthias.
Subject:
Embedding the shell
Date:
Wed, 8 Sep 1999 16:01:44 -0400
From:
"Kurt Westerfeld" <kurt@westerfeld.com>
To:
"Norris Boyd" <norris@netscape.com>
Norris, please find the attached zip file containing the (minor)
modifications to the Rhino shell module that enables the shell to be
embedded in a host application.
There are two areas of change to be concerned about:
1. Any and all references to System.in/out/err have been modified to use
Main.in/out/err, which default to System.in/out/err. Methods to do a setIn,
setOut, and setErr were added. Note that in/out/err on Main were made
static public, so that the jikes compiler wouldn't complain (I had them as
static protected, but when accessed outside of the package, a warning was
issued).
2. The global and sharedGlobal static variables were made protected so
that my app can make use of them (to add extensions after an initial pass
through main()).
That's it.
I have successfully used the facility to drop a remote telnet server into
the shell interpreter, effectively giving our server a remote shell
interpreter. It's quite nice, as we have a lot of extensions to Rhino
written that blend into our server already.
PS, I am still working on the array issues, but made a lot of progress
today. I just wanted to get this stuff off my desk.
Thanks!
________________________________________________________________________
Kurt Westerfeld
Managed Object Solutions
2722 Merrilee Drive
Suite 350
Fairfax, VA 22031
Phone: 703.208.3330 x225
Fax: 703.208.3331
http://www.mosol.com
mailto:kurt@mosol.com
shell.zip
Name:
shell.zip
Type:
Zip Compressed Data (application/x-zip-compressed)
Encoding:
base64
==============================================================================
Subject:
Rhino Array Source (Fixed)
Date:
Thu, 9 Sep 1999 14:12:03 -0400
From:
"Kurt Westerfeld" <kurt@mosol.com>
To:
"Norris Boyd" <norris@netscape.com>
Attached is NativeJavaObject.java, which seems to now pass the tests supplied to me by you and Scott. Not a lot of change, but a lot of
testing and thinking was involved. <g>
PS. I also fixed a bug in reportConversionError() which was throwing an IllegalArgumentException inside of the MessageFormat class at times.
It also looks a little nicer (uses formatting from NativeJavaMethod) and closer to the C implementation.
NativeJavaObject.java
Name:
NativeJavaObject.java
Type:
Java Source File (text/java)
Encoding:
quoted-printable
Subject:
ImporterTopLevel problem
Date:
Fri, 6 Aug 1999 15:42:50 -0400
From:
"\"Howard\" Xuhua Lin" <howard@softcom.com>
To:
"Norris Boyd" <norris@netscape.com>
CC:
"Andrew Wason" <aw@softcom.com>
Hi, The following script will cause an EvaluatorException: Ambiguous import: [JavaPackage java.awt.JButton] and [JavaPackage
java.awt.Packages.javax.swing.JButton] in the js shell:
js>importPackage(java.awt);
js>importPackage(Packages.javax.swing);
js>new JButton();.
The current JS shell will not print this exception message, even though the comment says "// Already printed message, so just fall
through". I add System.err.println(ee.getMessage()); for this exception.
The problem is that in NativeJavaPackage.get(String, Scriptable) method, if a ClassNotFoundException is caught, a
NativeJavaPackage object is created and passed back to ImporterTopLevel.get Method. So in ImporterTopLevel.get method, object v
is always not NOT_FOUND and the ambiguous exception will be thrown. Object v is supposed to be a Class object but it actually is
a Package object.
The fix can be either (1) in NativeJavaPackage.get(String, Scriptable) method, if a ClassNotFoundException is caught, return a
NOT_FOUND object (you may still create a Package object) or (2) in ImporterTopLevel.get method, make sure the returned object
from NativeJavaPackage.get method is of NativeJavaClass type.
Howard
Support for jsGet_ and jsSet_ prefixes to methods for explicit getter
and setter definition.
Addition of "importClass" and "importPackage" top-level functions.
The beginnings of a history object accessible from the shell.
nboyd%atg.com
matthias%sorted.org
beard%netscape.com
norris%netscape.com
rginda%netscape.com
dmose%mozilla.org