2) make the wrappedJS QI check for a match with chained wrappers before trying QI on the wrapped JS object.
3) add support for brendan's new JSArgumentFormatter callback to do auto js arg conversions - with test.
- Fix js_GetAtom fallibility by returning &dummy on assert-botch "can't happen"
index out of range case.
- js_InitAtomMap needn't bother nulling ale->next with tmp save
- js_InitAtomState explicit tail fusion for FROB via goto bad, and early memset
(I know, JSRuntime is cleared already and it contains the atom state ... but
jsatom.c doesn't know that).
- Clear all ATOM_ flags save ATOM_PINNED when creating a new atom.
- Cleanup xtra, ALIGNNUM, etc. useless variables, use JSVAL_ALIGN and JS_MAX.
Despite my stupidity here, I must say that over-includers elsewhere of both
jspubtd.h and jsapi.h, and even jscntxt.h, with system headers intermixed, suck
a lot too.
"external" calls compiled from scripts, which have stack budget depth slots
under the return value slot for the call expression's generating pc.
- New internalCall packed boolean flag in JSStackFrame to distinguish callers
of js_InternalCall so the generating pc isn't mistakenly stored depth slots
below stack space allocated on-the-fly for internal call args/rval.
- Fixed bugzilla bug 8042, finally by storing the call expression's generating
pc -- but only for external calls.
- Whitespace policing, gratuitous parenthesization reduction, etc.
2) breakout js ops into their own file so that the flattening project is less complicated
3) add a noisy object to the test components - this object prints addrefs, release, QIs, ctor, and dtor. This is useful for refcounting tests.
4) cleanup some component registration stuff.
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.
2) added where I was not checking for JSVAL_NULL from brendan.
3) got rid of 'xpcom32' references.
4) added nsIEcho::ReturnInterface as a loopback for testing the above.
5) removed some redundant retval setting code.
- check static members of instances in JavaMembers.put
- do not unwrap Wrappers before calling NativeJavaMethod.findFunction
or NativeJavaObject.coerceType; both methods may need extra information
provided by the wrapper.
- separate Java signatures for resolving overloaded methods and script
signatures for error messages, so we can distinguish primitive types
from classes.
- separate Java signatures for resolving overloaded methods and script
signatures for error messages, so we can distinguish primitive types
from classes.
- prevent a NativeJavaClass from being treated as a wrapped instance of
java.lang.Class
- correct bug which preferred the *less* specific of two classes in
NativeJavaMethod.preferSignature
- add new LC3 conversion rules to NativeJavaObject.coerceTypes.
- coerce JS numbers to Java numbers or chars only if the JS number is in
range.
- JS_PushArguments{,VA} and JS_PopArguments to convert a list of C/C++ values
passed as actual arguments into an 'jsval *argv' on the JS stack.
- Clean up and robustify ConvertArgs test command in the js shell.
To wit:
Attached are a couple of small fixes for building in the js/ subdir.
These are for FreeBSD-CURRENT, and for building in a seperate OBJDIR.
The FreeBSD one is a quick and dirty. The real fix is pobably just to
use OS_LDFLAGS as defined by configure...
Re: netscape.javascript.JSObject ?
Date:
Thu, 03 Jun 1999 17:52:42 -0700
From:
Frank Mitchell <frankm@eng.Sun.COM>
Organization:
Java Products Engineering
To:
Norris Boyd <norris@netscape.com>
References:
1 , 2 , 3 , 4 , 5 , 6 , 7 , 8
Norris Boyd wrote:
>
> Sorry--missed the checkin of a new file. It's there now.
>
> I'd also added a small change for the "inheritance" of JavaScript array methods.
Actually, I've already done that (and for String as well). It still
fails some LC3 regression tests, though.
I'm including a tarfile that includes the previous changes and the new
ones.
Frank
Re: Rhino LiveConnect: need help?
Date:
Wed, 02 Jun 1999 19:33:37 -0700
From:
Frank Mitchell <frankm@eng.Sun.COM>
Organization:
Java Products Engineering
To:
Scott Furman <fur@netscape.com>, Norris Boyd <norris@netscape.com>
CC:
mallen@eng.Sun.COM
References:
1 , 2 , 3 , 4
Scott Furman wrote:
> In order to bring Rhino LiveConnect support up to the level of the
> C-engine, the features of LiveConnect version 2 and version 3 would
> need to be added. You can see some details of LC2 and LC3 features
> here. I would guess that 80% of the time would be spent implementing
> one feature: LC3's new method overload resolution scheme.
OK, I think I have something that implements the new overloaded method
resolution scheme ... I'm still working on getting the regression tests
running smoothly, but from command-line testing it seems to work. It's
not the *cleanest* code I've ever done, though: in particular, it has
too many static methods and type-checking code for my tastes. (Hey,
should we spin the type coercion and comparison stuff to some other
module entirely? Right now it's mostly in JavaNativeObject, with the
preference stuff in JavaNativeMethod.) I'm also not sure why some of
this stuff is public, and whether there might be backward-compatibility
problems with what I've done, particularly in repurposing the
COMPARISON_* constants.
Would you guys be kind enough to review this for me? I'm hoping to
check it in once I get an ID, but it wouldn't hurt to have another pair
of eyes or three (pairs, I mean). I've attached a tar/gzip of the
source files I've changed (or added), plus a diff.
Thanks,
Frank
Re: Rhino LiveConnect: need help?
Date:
Wed, 02 Jun 1999 19:33:37 -0700
From:
Frank Mitchell <frankm@eng.Sun.COM>
Organization:
Java Products Engineering
To:
Scott Furman <fur@netscape.com>, Norris Boyd <norris@netscape.com>
CC:
mallen@eng.Sun.COM
References:
1 , 2 , 3 , 4
Scott Furman wrote:
> In order to bring Rhino LiveConnect support up to the level of the
> C-engine, the features of LiveConnect version 2 and version 3 would
> need to be added. You can see some details of LC2 and LC3 features
> here. I would guess that 80% of the time would be spent implementing
> one feature: LC3's new method overload resolution scheme.
OK, I think I have something that implements the new overloaded method
resolution scheme ... I'm still working on getting the regression tests
running smoothly, but from command-line testing it seems to work. It's
not the *cleanest* code I've ever done, though: in particular, it has
too many static methods and type-checking code for my tastes. (Hey,
should we spin the type coercion and comparison stuff to some other
module entirely? Right now it's mostly in JavaNativeObject, with the
preference stuff in JavaNativeMethod.) I'm also not sure why some of
this stuff is public, and whether there might be backward-compatibility
problems with what I've done, particularly in repurposing the
COMPARISON_* constants.
Would you guys be kind enough to review this for me? I'm hoping to
check it in once I get an ID, but it wouldn't hurt to have another pair
of eyes or three (pairs, I mean). I've attached a tar/gzip of the
source files I've changed (or added), plus a diff.
Thanks,
Frank
2) Support passing an interface identifier to getService and NewInstance.
3) Added AbandonJSContext to allow for cleanup of per JSContext data.
4) Added interface inheritence tests.
cbegle%netscape.com
jdunn%netscape.com
norris%netscape.com
ramiro%netscape.com
brendan%mozilla.org
mccabe%netscape.com
sspitzer%netscape.com
jband%netscape.com
briano%netscape.com
dveditz%netscape.com
scc%netscape.com
mcafee%netscape.com
brendan%netscape.com
rogerl%netscape.com
Jerry.Kirk%Nexwarecorp.com
fur%netscape.com
beard%netscape.com
dp%netscape.com
frankm%eng.sun.com
waldemar%netscape.com
ducarroz%netscape.com
mang%subcarrier.org
waterson%netscape.com