Re: Rhino 1.5R2 release candidate
Date:
Fri, 13 Jul 2001 22:52:43 -0700
From:
Christopher Oliver <coliver@mminternet.com>
Organization:
Primary Interface LLC
To:
Norris Boyd <nboyd@atg.com>
References:
1
Hi Norris,
Attached are some (final?) changes to the debugger:
- Display NativeCall objects as "[object Call]" in this/locals tree-tables
- Fixed "Go to Function" to highlight the target function in the source
window
- Synchronized ContextListener implementation
- Added slightly more useful tooltips to the tool bar
Note I modified files from today's rhinoTip.zip. Hopefully they were
identical to those in the cvs release branch.
Chris
Rhino: deal with all Throwables in Interpreter.interpret
Date:
Thu, 12 Jul 2001 14:27:34 +0200
From:
Igor Bukanov <igor@icesoft.no>
Organization:
Wind River
To:
Norris Boyd <nboyd@atg.com>
The attached patch modifies the catch code in Interpreter.interpret to
catch general Throwable exceptions to allow cleanup after throwing an
Error instance from Context.observeInstructionCount.
===================
Subject:
Rhino: change of InterpreterData.itsLineNumberTable from Hahstable to
UintHash
Date:
Thu, 12 Jul 2001 15:51:38 +0200
From:
Igor Bukanov <igor@icesoft.no>
Organization:
Wind River
To:
Norris Boyd <nboyd@atg.com>
The patch linetable_patch changes InterpreterData.itsLineNumberTable
from Hahstable to UintHash and debug/DebuggableScript.java to return
int[] array instead of Enumeration. It was run produced via
diff -ru javascript.0 javascript
The patch debugger_patch contains update for
toolsrc/org/mozilla/javascript/tools/debugger/Main.java to reflect above
api changes.
===============================
Subject:
Rhino: patch not to store VariableTable in InterpreterData
Date:
Thu, 12 Jul 2001 16:34:18 +0200
From:
Igor Bukanov <igor@icesoft.no>
Organization:
Wind River
To:
Norris Boyd <nboyd@atg.com>
The patch removes the "VariableTable itsVariableTable" field from
InterpreterData so it would not be stored in
InterpretedFunction/InterpretedScript and could be garbage collected
after interpreter byte code generation is finished. The usage of
theData.itsVariableTable it Interpreter.interpret is replaced by
accessing argNames/argCount fields from the passed NativeFunction.
Subject:
Fatal error executing in IBM J9 VM
Resent-Date:
Mon, 9 Jul 2001 15:35:32 -0700 (PDT)
Resent-From:
mozilla-jseng@mozilla.org
Date:
9 Jul 2001 15:33:38 -0700
From:
bdemchak@tpsoft.com (Barry Demchak)
Organization:
http://groups.google.com/
To:
mozilla-jseng@mozilla.org
Newsgroups:
netscape.public.mozilla.jseng
Hi --
I've encountered an error in either Rhino or the IBM J9 VM's runtime
support -- I'm not sure which -- but the end result is an unhandled
exception. I'm quite willing to believe that it's already been dealt
with. If so, will someone point me to the solution?
I'm using: IBM's J9 on Windows 2000,
IBM's IDE v1.3 on Windows 2000,
Rhino v1.5 from mozilla.org
The exception is java.lang.StringIndexOutOfBoundsException.
It occurs in Context.getSourcePositionFromStack just after the call to
RuntimeException.printStackTrace. The code is expecting a code
reference that looks something like "(Example.js:50)" where "50" is
the line number. (I gather that's what the Sun VM returns???)
Instead, J9 is returning a code reference that looks like:
"java.lang.RuntimeException\n\n\n\nStack trace:\n\n
java/lang/Throwable.<int>()V\n\n" etc, etc, etc.
The error occurs because the Colon variable's value is less than the
Open variable's value in Context.getSourcePositionFromStack. When the
s.substring is evaulated, there's a negative string length ... boom.
I've patched an "if" statement in the getSourcePositionFromStack code
so that instead of:
if (c == '\n' && open != -1 && close != -1 && colon != -1)
I have:
if (c == '\n' && open != -1 && close != -1 && colon != -1 && open <
colon && colon < close)
Certainly, there's a better fix, but it's sufficient to keep me going.
So, I have several questions ... being new to open source and this
forum:
1) Is this a real bug ... a real Rhino bug??
2) Has this already been found?
3) Has this already been fixed?
4) If not, what's the proper protocol for reporting it?
5) What's the proper protocol for fixing it?
This shows up *very* quickly when trying to run a script under J9.
When it occurs, Rhino is trying to issue a warning about some shady
JavaScript code.
If this is a real bug and hasn't been fixed, I would infer that there
aren't a lot of people trying to run this under J9. Would that be a
fair statement? If so, can anyone comment as to why that would be??
Thanks!
Rhino: Fixes for catch in Interpreter.interpret
Date:
Wed, 11 Jul 2001 19:06:46 +0200
From:
Igor Bukanov <igor@icesoft.no>
Organization:
Wind River
To:
Norris Boyd <nboyd@atg.com>
Hi, Norris!
When doing that instruction counting implementation, I managed to mess
up code in the catch statement in Interpreter.interpret.
First for some reason I assumed that for a general RuntimeException the
previous code do not run finally statements but only script catch code.
Of cause this was wrong: that code skipped catch for arbitrary exception
while calling finally.
This is a reasonable behavior especially given the fact that arbitrary
RuntimeException may only arise from, say, bugs, other exceptions should
be wrapped to JavaScriptException.
Second I removed calls to debug.handleExceptionThrown...
The attached patch restores the original catch/finally logic and re-adds
calls to debug.handleExceptionThrown.
I will later update it that catch to handle Error as well to allow
cleanup after throwing an Error instance from
Context.observeInstructionCount , but restoration should go first.
Regards, Igor
nboyd%atg.com
rginda%netscape.com
brendan%mozilla.org
dbaron%fas.harvard.edu
pschwartau%netscape.com
timeless%mac.com
jaggernaut%netscape.com
radha%netscape.com
waldemar%netscape.com
cls%seawood.org
rogerl%netscape.com
jst%netscape.com
av%netscape.com
bryner%uiuc.edu