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
Subject:
Re: Rhino bug - Wrapper ??
Date:
Fri, 05 Jan 2001 03:46:11 +0530
From:
Mukund Balasubramanian <mukund@cs.stanford.edu>
Organization:
Another Netscape Collabra Server User
Newsgroups:
netscape.public.mozilla.jseng
References:
1 , 2 , 3 , 4 , 5 , 6
That works too,
Should I assume that this would be a part of the next tip ? I agree with the
part about
overloading code too.
Anyways, thanks a load for your help and just tell me if I could be of any
help in any other
respects of the rhino project.
ThanX,
Mukund Balasubaramanian
Norris Boyd wrote:
> Actually, I was considering removing the unwrapping code from
NativeJavaConstructor. I was
> suprised that it was there. The code dates from before we implemented proper
method and
> constructor overloading in Rhino. It's the overloading code that should have
the responsibility
> for unwrapping.
>
> Does this patch work for you:
>
> Index: NativeJavaObject.java
> ===================================================================
> RCS file:
/cvsroot/mozilla/js/rhino/org/mozilla/javascript/NativeJavaObject.java
> ,v
> retrieving revision 1.29
> diff -u -r1.29 NativeJavaObject.java
> --- NativeJavaObject.java 2000/11/13 22:10:32 1.29
> +++ NativeJavaObject.java 2001/01/04 21:33:55
> @@ -673,6 +673,12 @@
>
> return Result;
> }
> + else if (value instanceof Wrapper) {
> + value = ((Wrapper)value).unwrap();
> + if (type.isInstance(value))
> + return value;
> + reportConversionError(value, type);
> + }
> else {
> reportConversionError(value, type);
> }
>
> This handles the case where the object is both a Scriptable and a Wrapper.
>
> --N
>
> Mukund Balasubramanian wrote:
>
> > Yes they do implement Scriptable.
> > From my preliminary inspection of the code, findFunction seems to be
preceediong the
> > coerceType call and I presume findFunction call is going to fail if the
arguments are
> > wrapped (bad types mismatching signature).
> > The constructor case DOES go through an explicit unwrapping stage as
shown by the cut
> > and paste code. My question is whether the same preamble in NativeJavaMethod
is a valid bug
> > fix.
> >
> > ThanX,
> >
> > Mukund Balasubramanian
> >
> > Norris Boyd wrote:
> >
> > > Do your objects that implement Wrapper also implement Scriptable? From
simple inspection
> > > of the code I'd think that both the constructor and method cases would go
through
> > > NativeJavaMethod.coerceType, which should unwrap. However, Scriptable
objects are picked
> > > off and handled before any unwrapping is considered.
> > >
> > > --N
> > >
> > > Mukund Balasubramanian wrote:
> > >
> > > > Yup,
> > > > Here it is - Line numbers 173-178 are cut and paste from
> > > > NativeJavaConstructor.java inside NativeJavaMethod.java
> > > >
> > > > /*** Call in NativeJavaMethod.java
> > > > public Object call(Context cx, Scriptable scope, Scriptable thisObj,
> > > > Object[] args)
> > > > throws JavaScriptException
> > > > {
> > > > // Eliminate useless args[0] and unwrap if required
> > > > for (int i = 0; i < args.length; i++) {
> > > > if (args[i] instanceof Wrapper) {
> > > > args[i] = ((Wrapper)args[i]).unwrap();
> > > > }
> > > > }
> > > >
> > > > // Find a method that matches the types given.
> > > > if (methods.length == 0) {
> > > > ****/
> > > >
> > > > Is this correct ? I presume it is because of the fact that the
constructor
> > > > does this.
> > > >
> > > > Any luck with my other question regarding generalizing the WrapHandler
to all
> > > > objects (including those returned by scriptable) and not only those
returned
> > > > through nativeJava***
> > > >
> > > > ThanX,
> > > >
> > > > Mukund Balasubramanian
> > > >
> > > > Norris Boyd wrote:
> > > >
> > > > > Could you post your proposed patch?
> > > > >
> > > > > Thanks,
> > > > > Norris
> > > > >
> > > > > Mukund Balasubramanian wrote:
> > > > >
> > > > > > Hi all,
> > > > > > I am trying to play around with writing a custom WrapHandler for
my
> > > > > > Java objects in Rhino. I found WrapHandler very useful.
> > > > > > Now I am stuck at a point where, even though my wrappers
implement
> > > > > > "Wrapper", they get unwrapped only on calles to Constructors using
> > > > > > Liveconnect. Normal methods dont seem to be doing any unwrapping.
> > > > > > Managed to build rhino with a bug fix (cut and paste code from
> > > > > > NativeJavaConstructor to NativeJavamethod), and it works.
> > > > > > Just wanted to verify if it is a known bug (while I wait for
> > > > > > bugzilla to mail me a passwd).
> > > > > >
> > > > > > BTW, also found something interesting, WrapHandler gets called only
when
> > > > > > the object is returned from NativeJava***, not ANY Object. Is that
the
> > > > > > way it is supposed to work ??
> > > > > >
> > > > > > ThanX for any help,
> > > > > >
> > > > > > Mukund Balasubramanian
Subject:
[Rhino] Script compiler bug?
Date:
Tue, 12 Dec 2000 22:08:23 GMT
From:
dave russo <d-russo@ti.com>
Organization:
Deja.com
Newsgroups:
netscape.public.mozilla.jseng
The following script does not seem to compile properly (using Rhino
1.5R1):
test.js:
var test = {};
test.foo = function () { print('foo')}
test.bar = function () { print('bar')}
After compiling test.js ("java org.mozilla.javascript.tools.jsc.Main
test.js"):
js> loadClass('test')
js> test.foo()
bar
js> load('test.js')
js> test.foo()
foo
Note that changing test.js to read:
var test = {};
test.foo = function foo() { print('foo')}
test.bar = function bar() { print('bar')}
Works around the problem. Is there a problem with anonymous functions?
Sent via Deja.com
http://www.deja.com/
Along the way, Patrick also fixed a bug that's been with the JS engine on the mac for more than three years; used to be that Mac dates throughout the year were displayed according to the machine's *current* daylight savings time setting; now they display properly and all is well with the world.
Dependent on recent checkin fixing 61577, adding needed time library to the mac build.X
r=mccabe
especially to jband for his great stress-test setup and particularly helpful
(in terms of reproducing bugs in draft patches) MP and laptop machines.
- Radical(*) object (scope) locking optimization: don't lock if a scope is
accessed on the context that exclusively owns it (initially, the context
on which the scope was created). Once a scope becomes shared among more
than one owner-context, give it the usual thin or fat lock, per existing
jslock.c code.
I did this at the memory cost of another word per JSScope, ownercx, which
raised scope size from 12 to 13 words if !DEBUG. I also added a linked
list head pointer, rt->scopeSharingTodo, and a scopeSharingDone condition
variable to JSRuntime, and a scopeToShare pointer to JSContext that's
necessary for deadlock avoidance.
The rt->scopeSharingTodo list links JSScopes through the scope->u.link
union arm, which overlays the pre-existing scope->count (now u.count)
member. This list holds scopes still exclusively owned by a context, but
wanted by js_LockScope calls active on other threads. Those calls wait
on the rt->scopeSharingDone condition, which is notified every time an
owner-context ends the request running on it, in which code active on
that context may be using scope freely until end of request.
The code that waits on rt->scopeSharingDone must first suspend any and
all requests active on the calling context, and resume those contexts
after the wait is notified. This means a GC could happen while the
thread locking a scope owned by another thread's context blocks; all
calls to JS_LOCK_OBJ must therefore first home fp->sp above any live
operands, e.g. The interpreter takes care to do that already.
To avoid AB-BA deadlocks, if a js_LockScope attempt on one context finds
that the owner-context of the scope is already waiting on a scope owned
by the current context (or indirectly depending on such a scope lock),
the attempt converts the scope from lock-free exclusive ownership to
shared ownership (thin or fat lock).
- Fix js_SetupLocks and the js_LockGlobal/js_UnlockGlobal code to avoid
divmod instruction costs, strength-reducing to bit-mask instructions.
- The radical lock-free scope change required care in handling the 0=>1
and 1=>0 transitions of cx->requestDepth, which was till now thread-local
because part of the JSContext not manipulated by other threads. It's
still updated only by cx's thread, but it is read by other threads in
the course of attempting to claim exclusive ownership of a scope for more
lock-free JS object operations.
- The JS_SuspendRequest and JS_ResumeRequest APIs have changed incompatibly
to require their caller to save and restore the requestCount found when
JS_SuspendRequest is called. This is necessary to avoid deadlock; sorry
for the incompatible change.
- Fixed various nits in jslock.[ch], including using Init/Finish rather
than New/Destroy for the methods that take a JSThinLock and initialize
and finish/free its members. Another example: JS_ATOMIC_ADDREF is now
JS_ATOMIC_INCREMENT and JS_ATOMIC_DECREMENT, so the two cases can be
mapped to PR_AtomicIncrement and PR_AtomicDecrement. This entailed
changing jsrefcount from jsword to int32 (PRInt32).
- No need to use JS_ATOMIC_INCREMENT on JSScopeProperty.nrefs, as it is
always and everywhere protected by the property's JSScope.lock.
- Cleaned up gratuitous casts in jscntxt.c by using &cx->links, etc.
- The lock used for mutual exclusion around both request begin and end vs.
GC synchronization is rt->gcLock, and this lock now also protects all
scope->ownercx pointer changes from non-null (exclusive) to null (shared),
the rt->scopeSharingTodo/scope->u.link list operations, and of course the
rt->scopeSharingDone condition.
But this means that js_GC cannot hold rt->gcLock across the bulk of its
body, in particular the mark phase, during which JS_GetPrivate calls,
e.g., may need to "promote" scope locks from lock-free to thin or fat,
because doing so would double-trip. There never was any good reason to
hold rt->gcLock so long, of course -- locks are for mutual exclusion, not
for waiting or notifying a thread -- those operations require a condition,
rt->gcDone, which we already use along with rt->gcLevel to keep racing GC
attempts at bay.
So now that rt->gcLock does not protect the mark phase, the enumeration
of rt->gcRootsHash can race badly with JS_RemoveRootRT, an API that may
legitimately be called outside of a request, without even a context. It
turns out that people may be cheating on the request model even with
JS_AddRoot, JS_AddNamedRoot, and JS_RemoveRoot calls, so we must make
all of those interlock with the GC using gcLevel and gcDone, unless they
are called on the gcThread.
Also, since bug 49816 was fixed, there has been no need for a separate
finalize phase, or for rt->gcFinalVec. Finalizers can no longer allocate
newborn GC-things that might be swept (because unmarked), or double-trip
on rt->gcLock (which is no longer held). So js_GC finalizes as it sweeps,
just as it did in days of old.
- I added comments to jslock.h making it plain that callers of JS_LOCK_OBJ
and JS_UNLOCK_OBJ must either be implementations of js_ObjectOps hooks,
or code reachable only from those hooks; or else must be predicated on
OBJ_IS_NATIVE tests. It turns out jsinterp.c's CACHED_GET and CACHED_SET
macros neglected to do such tests, limiting the ability of JS embeddings
to implement JSObjectOps with their own non-JSScope JSObjectMap subclass.
Fixed, small performance hit that the lock-free optimization should more
than make up for.
- jslock.c now gives a #error if you try to compile it on a platform that
lacks a compare-and-swap instruction. The #error says to use NSPR locks.
Before this change, some platforms would emulate compare-and-swap using
a global PRLock, which is always worse in runtime than using per-scope
PRLocks.
for call semantics. Fixed MSVC warnings from lexutils. Added BindThis
instructionand removed 'this' from Call instruction (is now extracted
from target argument).
[Rhino] importPackage() when not in Rhino shell?
Date:
Tue, 14 Nov 2000 09:37:39 -0000
From:
"Benjamin Geer" <geerb@midas-kapiti.com>
Organization:
Another Netscape Collabra Server User
Newsgroups:
netscape.public.mozilla.jseng
The importPackage() and importClass() functions provided by the Rhino shell
seems as if they would be very generally useful. Unless I've missed
something, they don't seem to be available to scripts compiled using the
JavaScript compiler, or to scripts that are run using Script.exec(). Is
there any chance these functions could be made available for all scripts to
use? This would save a lot of typing; one could then always write a = new
Foo() instead of a = new Package.com.baz.bar.foo.Foo().
--Benjamin Geer
slobo@espial.com wrote:
>
> Hello Mike
>
> In the following test case, tester returns "undefined cat" in Rhino
> while in NN it returns "meow cat".
>
> Thanks
>
> Steven
>
> /////////////////////////////////////////////////////////////////////
> function tester(nest){
> var nest = nest+" cat";
> alert(nest);
> // nest now contains the value undefined.
> }
>
> tester("meow");
refactored exceptions from icodeasm into exception*
fixed LeadingCap method names to be interCapped
added string8 and string16 typedefs (as opposed to string vs String)
More changes to support non NativeJavaObject wrappers
Date:
Fri, 03 Nov 2000 17:56:38 +0100
From:
Igor Bukanov <igor@icesoft.no>
To:
nboyd@atg.com
Hi, Norris,
In post 1.5 rhino one can introduce own wrappers for arbitrary Java
objects. But I think to fully support this
org.mozilla.javascript.ScriptRuntime should be changes as well: its eq
and shallow_eq contain references to NativeJavaObject, this should be
replaced at least to Wrapper (see the atached patch). Even better
solution would be to add to WrapHandler methods to compare wrappers: I
can send a patch for that as well.
There is a small usability problem as well: if
org.mozilla.javascript.JavaMembers would be public I do not need to copy
it to a package with non NativeJavaObject.java wrapper.
Regards, Igor
Make try { ... } catch(exn) { return exn } work by ensuring that the return value (exn) is maintained on the stack as we pop off scopes to return from the try/catch/finally. The newly added JSOP_SWAP opcode helps us bubble.
This fixes a regression uncovered by the fix to 56716.
(I've noticed that this causes *depend* builds of the standalone JS shell to crash on this construct, but I've tested in the Mozilla build, and the dependencies seem to solve the problem there.)
r=brendan.mozilla.org
sr=jband@netscape.com
56318 function literals with names don't work right
57045 negative integers as object properties: weird behavior
58479 functions defined within conditional phrases are always crea
Fixes for OSF; they they assume the existence of /share/builds/components/[jdk|nspr]/SOME_VERSION/etc/etc. Sorry, external folks!
Not part of the Mozilla build.
Fixes for Linux and SunOS; they assume the existence of /share/builds/components/[jdk|nspr]/SOME_VERSION/etc/etc. Sorry, external folks!
Not part of the Mozilla build.
[Rhino] Optimization for OptRuntime.thisGet
Date:
Mon, 23 Oct 2000 17:50:53 +0200
From:
Hannes Wallnoefer <hannes@helma.at>
Organization:
Another Netscape Collabra Server User
Newsgroups:
netscape.public.mozilla.jseng
I found a little oddity in
org.mozilla.javascript.optimizer.OptRuntime.thisGet().
get() is called twice on thisObj, once right at the beginning, and once
when starting to walk down the prototype chain. Below is what I think
this should look like - the prototype walk now begins with thisObj's
prototype, if it exists.
Also, (thisObj == null) was checked only after thisObj.get() was called,
so I moved that up in front.
Hannes
PS: I just made the changes in the news msg editor, so there may be
stupid mistakes.
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.
ECMA-262 octal literals. Old code would split 08 into 0 and 8 if JS1.2 or
other non-ECMA version, and always split 078 into 07 and 8, resulting in
missing ; syntax errors.
- Fix CheckFinalReturn to be aware of JS_HAS_EXCEPTIONS, finally (sic). Lots
of help from jag (Peter Annema, disttsc@bart.nl), thank him.
Both changes got lumped under bug 49233, and are r=jband, sr=shaver.
