Nabble - Mozilla - JavaScript Engine

Re: New harness for shell JSTests

2009-11-27T09:40:58Z

2009/11/24 David Mandelin <dmandelin@...>:
> IMO the baseline is that everything should just work, so yes, please file a
> bug on this too.

There are some tests that fails if the amount of memory they can
allocate is limited to, say, 512 MB. In addition using -t switch is
useful to limit the execution time on a slow CPU. So it would be nice
to have an explicit switch that output the list of failures into a
file that can be passed using -x switch.
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

extension access check problem

2009-11-27T00:52:12Z

Hi:
We found that all the extensions in firefox work in the same
jscontext and no same origin check is done for accesses to objects in
that context. The SameOriginCheck only happen when access occurs
between two different contexts, right?

If it is the case, what can we do if we want to add extra check whenever
we access one object from one extension to another? What would be the
proper functions we can look at? Looking forward to your reply.
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

Re: New harness for shell JSTests

2009-11-24T18:52:59Z

On Tue, Nov 24, 2009 at 10:58 PM, itroot <ivan.tolstosheyev@...> wrote:

>
> But while i run this test suite on my machine, i get
>
> itroot@itroot-desktop:~/prefix/js/tests$ python jstests.py ../shell/js
> Traceback (most recent call last):
> File "jstests.py", line 262, in <module>
> test_list = manifest.parse(OPTIONS.manifest, xul_tester)
> File "/home/itroot/prefix/js/tests/manifest.py", line 102, in parse
> ans += parse(os.path.join(dir, parts[1]), xul_tester)
> File "/home/itroot/prefix/js/tests/manifest.py", line 102, in parse
> ans += parse(os.path.join(dir, parts[1]), xul_tester)
> File "/home/itroot/prefix/js/tests/manifest.py", line 130, in parse
> if xul_tester.test(cond):
> File "/home/itroot/prefix/js/tests/manifest.py", line 78, in test
> raise Exception("Failed to test XUL condition '%s'"%cond)
>
> Maybe this is wrong place to post it, if it so, where i can post bug?

I just filed https://bugzilla.mozilla.org/show_bug.cgi?id=530969.

Nick
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

Removing JS_strtod and JS_dtostr

2009-11-24T16:54:48Z

I'm fixing bug 509857 ("get rid of LOCK_DTOA"). This avoids entering
and leaving a lock in some cases where we convert a string to a number
or vice versa.

However, with my changes it's no longer convenient to implement
JS_strtod and JS_dtostr.

Note that these functions have never been in jsapi.h. I'm not sure why
they are named with the uppercase JS_ prefix.

Is anyone using these? Speak up!

-j
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

Re: New harness for shell JSTests

2009-11-24T10:58:58Z

On 11/24/09 3:58 AM, itroot wrote:

> On Nov 24, 12:13 am, David Mandelin<dmande...@...> wrote:
>> I just landed to the tracemonkey repo a new harness for running the
>> shell JSTests that we've been working on for a while. My primary goal
>> was to make the tests run faster on multiple cores and to be easier to
>> run day-to-day for devs, but it also supports Tinderbox-style reporting
>> and a bunch of other new features.
>>
>> The basic usage is:
>>
>> # in directory js/src/tests
>> python jstests.py PATH_TO_JS
>>
>> This will run with a progress bar and report results in a compact way.
>> The 3 numbers on the left are mochitest-style "passed/failed/known
>> fails". There is no need to do a baseline run; bc's new manifest files
>> indicate which tests are known to fail, should be skipped, etc.
>>
>> If you have more than 2 cores, then you probably want '-j N' to run
>> faster. I think it can run the whole suite in about a minute on an
>> 8-core machine.
>>
>> Here are a few more sample command lines:
>>
>> # print options help text
>> python jstests.py -h
>>
>> # tinderbox-style output
>> python jstests.py PATH_TO_JS --tinderbox
>>
>> # run only tests that contain the string '263935'
>> python jstests.py PATH_TO_JS 263935
>>
>> # run only those tests and print command lines and output
>> python jstests.py -so PATH_TO_JS 263935
>>
>> # run only those tests in valgrind
>> python jstests.py --valgrind PATH_TO_JS 263935
>>
>> # run that test in gdb
>> python jstests.py -g PATH_TO_JS 263935
>>
>> Note that the options are processed with Python OptionParse, so they can
>> come in any order. E.g., this is fine:
>>
>> # run only those tests and print command lines and output
>> python jstests.py PATH_TO_JS 263935 -so
>>
>> Finally, thanks to Bob Clary and Jason Orendorff for patiently reviewing
>> multiple versions of this patch and guiding me on features,
>> understanding the test, and Python styling. And thanks to everyone who
>> encouraged me by trying out the prototype versions and liking it. :-)
>>
>> --
>> Dave
>
> oh, that's nice, thank you!
>
> But while i run this test suite on my machine, i get
>
> itroot@itroot-desktop:~/prefix/js/tests$ python jstests.py ../shell/js
> Traceback (most recent call last):
> File "jstests.py", line 262, in<module>
> test_list = manifest.parse(OPTIONS.manifest, xul_tester)
> File "/home/itroot/prefix/js/tests/manifest.py", line 102, in parse
> ans += parse(os.path.join(dir, parts[1]), xul_tester)
> File "/home/itroot/prefix/js/tests/manifest.py", line 102, in parse
> ans += parse(os.path.join(dir, parts[1]), xul_tester)
> File "/home/itroot/prefix/js/tests/manifest.py", line 130, in parse
> if xul_tester.test(cond):
> File "/home/itroot/prefix/js/tests/manifest.py", line 78, in test
> raise Exception("Failed to test XUL condition '%s'"%cond)
>
> itroot@itroot-desktop:~/prefix/js/tests$ python --version
> Python 2.6.2
> itroot@itroot-desktop:~/prefix/js/tests$ uname -a
> Linux itroot-desktop 2.6.28-16-generic #55-Ubuntu SMP Tue Oct 20
> 19:48:32 UTC 2009 x86_64 GNU/Linux
> I built tracemonkey as standalone library.
>
> I can fix this problem just setting ans to False instead of raising
> exception, but it is not appropriate for everyone.
> In "out" variable i get "x86_64" instead of true false or null.
>
> Maybe this is wrong place to post it, if it so, where i can post bug?

That's definitely a bug. I think you can file it as a SpiderMonkey bug.
I'll find it there.

--
Dave
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

Re: New harness for shell JSTests

2009-11-24T10:53:06Z

On 11/23/09 8:11 PM, Nicholas Nethercote wrote:

> On Tue, Nov 24, 2009 at 8:13 AM, David Mandelin<dmandelin@...> wrote:
>> I just landed to the tracemonkey repo a new harness for running the shell
>> JSTests that we've been working on for a while. My primary goal was to make
>> the tests run faster on multiple cores and to be easier to run day-to-day
>> for devs, but it also supports Tinderbox-style reporting and a bunch of
>> other new features.
>
> This is awesome, thanks for doing it.
>
> trace-test.py has the wonderful -f option which prints the command
> lines of all failed tests. This is much nicer than jstest.py's -s
> option because it only prints command lines for failed tests, and it
> prints the command line exactly, not as an array of strings, so you
> can cut-and-paste them easily. Could this be added to jstests.py? I
> see -f has a different meaning for jstests.py, perhaps a different
> option could be used, although it would be nice if jstests.py and
> trace-test.py were as similar as possible.

Very good idea. Could you please file a bug on this? On the option
names, I've been picking things fairly arbitrarily. I agree they should
be the same for both harnesses. Tell me what you think and I'll do it.

> Also, I just tried a i386 debug build, got this:
>
> ecma/Date/15.9.3.8-1.js
...
> ecma_5/Date/15.9.4.2.js
> js1_5/extensions/toLocaleFormat-02.js
> js1_5/extensions/toLocaleFormat-01.js
> js1_8_1/decompilation/regress-530537.js
>
> From the looks of it, most of them are caused by all-too-common
> "waddya mean there are timezones outside of North America?" problem
> (eg. see bugs 515254, 526665). Are these failures known? Should I
> file a bug?

IMO the baseline is that everything should just work, so yes, please
file a bug on this too.

--
Dave
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

Re: New harness for shell JSTests

2009-11-24T03:58:25Z

On Nov 24, 12:13 am, David Mandelin <dmande...@...> wrote:

> I just landed to the tracemonkey repo a new harness for running the
> shell JSTests that we've been working on for a while. My primary goal
> was to make the tests run faster on multiple cores and to be easier to
> run day-to-day for devs, but it also supports Tinderbox-style reporting
> and a bunch of other new features.
>
> The basic usage is:
>
> # in directory js/src/tests
> python jstests.py PATH_TO_JS
>
> This will run with a progress bar and report results in a compact way.
> The 3 numbers on the left are mochitest-style "passed/failed/known
> fails". There is no need to do a baseline run; bc's new manifest files
> indicate which tests are known to fail, should be skipped, etc.
>
> If you have more than 2 cores, then you probably want '-j N' to run
> faster. I think it can run the whole suite in about a minute on an
> 8-core machine.
>
> Here are a few more sample command lines:
>
> # print options help text
> python jstests.py -h
>
> # tinderbox-style output
> python jstests.py PATH_TO_JS --tinderbox
>
> # run only tests that contain the string '263935'
> python jstests.py PATH_TO_JS 263935
>
> # run only those tests and print command lines and output
> python jstests.py -so PATH_TO_JS 263935
>
> # run only those tests in valgrind
> python jstests.py --valgrind PATH_TO_JS 263935
>
> # run that test in gdb
> python jstests.py -g PATH_TO_JS 263935
>
> Note that the options are processed with Python OptionParse, so they can
> come in any order. E.g., this is fine:
>
> # run only those tests and print command lines and output
> python jstests.py PATH_TO_JS 263935 -so
>
> Finally, thanks to Bob Clary and Jason Orendorff for patiently reviewing
> multiple versions of this patch and guiding me on features,
> understanding the test, and Python styling. And thanks to everyone who
> encouraged me by trying out the prototype versions and liking it. :-)
>
> --
> Dave

oh, that's nice, thank you!

But while i run this test suite on my machine, i get

itroot@itroot-desktop:~/prefix/js/tests$ python jstests.py ../shell/js
Traceback (most recent call last):
File "jstests.py", line 262, in <module>
test_list = manifest.parse(OPTIONS.manifest, xul_tester)
File "/home/itroot/prefix/js/tests/manifest.py", line 102, in parse
ans += parse(os.path.join(dir, parts[1]), xul_tester)
File "/home/itroot/prefix/js/tests/manifest.py", line 102, in parse
ans += parse(os.path.join(dir, parts[1]), xul_tester)
File "/home/itroot/prefix/js/tests/manifest.py", line 130, in parse
if xul_tester.test(cond):
File "/home/itroot/prefix/js/tests/manifest.py", line 78, in test
raise Exception("Failed to test XUL condition '%s'"%cond)

itroot@itroot-desktop:~/prefix/js/tests$ python --version
Python 2.6.2
itroot@itroot-desktop:~/prefix/js/tests$ uname -a
Linux itroot-desktop 2.6.28-16-generic #55-Ubuntu SMP Tue Oct 20
19:48:32 UTC 2009 x86_64 GNU/Linux
I built tracemonkey as standalone library.

I can fix this problem just setting ans to False instead of raising
exception, but it is not appropriate for everyone.
In "out" variable i get "x86_64" instead of true false or null.

Maybe this is wrong place to post it, if it so, where i can post bug?
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

RE: Seiko Coutura Diamond Gold-tone Steel Ladies Watch SXGN28

2009-11-23T20:42:29Z

All,

The email I am forwarding is spam email!!!

I don't know how it send from email address:
dev-tech-js-engine-bounces+fanzhe_cui=yahoo.com@...
[mailto:dev-tech-js-engine-bounces+fanzhe_cui=yahoo.com@...]
On Behalf Of watches replica.

The above email address have my email address Fanzhe_cui@... in it. I
received 8 emails like this.

What we can do in order to stop this spam email?

-----Original Message-----
From: dev-tech-js-engine-bounces+fanzhe_cui=yahoo.com@...
[mailto:dev-tech-js-engine-bounces+fanzhe_cui=yahoo.com@...]
On Behalf Of watches replica
Sent: Monday, November 23, 2009 5:36 PM
To: dev-tech-js-engine@...
Subject: Seiko Coutura Diamond Gold-tone Steel Ladies Watch SXGN28

Seiko Coutura Diamond Gold-tone Steel Ladies Watch SXGN28

http://www.watchestrade.net/Seiko-Coutura.html
http://www.watchestrade.net/Seiko-Watches.html

http://www.watchestrade.net/Seiko-Coutura-Diamond-Gold-tone-Steel-Ladies-Wat
ch-SXGN28.html

http://www.watchestrade.net/
 Gold-tone stainless steel
case and bracelet. Black
dial. Diamond bezel. Scratch resistant sapphire crystal. Push button
deployment clasp. Cabochon crown. Quartz movement. Water resistant at
30 meters (100 feet).
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

Re: New harness for shell JSTests

2009-11-23T20:11:37Z

On Tue, Nov 24, 2009 at 8:13 AM, David Mandelin <dmandelin@...> wrote:
> I just landed to the tracemonkey repo a new harness for running the shell
> JSTests that we've been working on for a while. My primary goal was to make
> the tests run faster on multiple cores and to be easier to run day-to-day
> for devs, but it also supports Tinderbox-style reporting and a bunch of
> other new features.

This is awesome, thanks for doing it.

trace-test.py has the wonderful -f option which prints the command
lines of all failed tests. This is much nicer than jstest.py's -s
option because it only prints command lines for failed tests, and it
prints the command line exactly, not as an array of strings, so you
can cut-and-paste them easily. Could this be added to jstests.py? I
see -f has a different meaning for jstests.py, perhaps a different
option could be used, although it would be nice if jstests.py and
trace-test.py were as similar as possible.

Also, I just tried a i386 debug build, got this:

ecma/Date/15.9.3.8-1.js
ecma/Date/15.9.3.8-2.js
ecma/Date/15.9.5.14.js
ecma/Date/15.9.5.22-1.js
ecma/Date/15.9.5.22-3.js
ecma/Date/15.9.5.23-1.js
ecma/Date/15.9.5.23-15.js
ecma/Date/15.9.5.23-17.js
ecma/Date/15.9.5.24-1.js
ecma/Date/15.9.5.24-2.js
ecma/Date/15.9.5.24-3.js
ecma/Date/15.9.5.24-5.js
ecma/Date/15.9.5.24-4.js
ecma/Date/15.9.5.24-6.js
ecma/Date/15.9.5.24-7.js
ecma/Date/15.9.5.24-8.js
ecma/Date/15.9.5.26-1.js
ecma/Date/15.9.5.25-1.js
ecma/Date/15.9.5.27-1.js
ecma/Date/15.9.5.28-1.js
ecma/Date/15.9.5.29-1.js
ecma/Date/15.9.5.30-1.js
ecma/Date/15.9.5.31-1.js
ecma/Date/15.9.5.32-1.js
ecma/Date/15.9.5.33-1.js
ecma/Date/15.9.5.34-1.js
ecma/Date/15.9.5.35-1.js
ecma/Date/15.9.5.36-1.js
ecma/Date/15.9.5.36-2.js
ecma/Date/15.9.5.36-3.js
ecma/Date/15.9.5.36-4.js
ecma/Date/15.9.5.36-5.js
ecma/Date/15.9.5.36-6.js
ecma/Date/15.9.5.36-7.js
ecma/Date/15.9.5.37-1.js
ecma/Date/15.9.5.8.js
ecma_3/Date/15.9.5.6.js
ecma_3/Date/15.9.5.5.js
ecma_5/Date/15.9.4.2.js
js1_5/extensions/toLocaleFormat-02.js
js1_5/extensions/toLocaleFormat-01.js
js1_8_1/decompilation/regress-530537.js

From the looks of it, most of them are caused by all-too-common
"waddya mean there are timezones outside of North America?" problem
(eg. see bugs 515254, 526665). Are these failures known? Should I
file a bug?

Nick
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

Omega Seamaster 300m 2263.80

2009-11-23T17:37:04Z

Omega Seamaster 300m 2263.80

http://www.watchestrade.net/Omega-Seamaster.html
http://www.watchestrade.net/Omega-Watches.html
http://www.watchestrade.net/Omega-Seamaster-300m-2263.80.html

http://www.watchestrade.net/
 Availability: In Stock Omega Seamaster 300m 2263.80
Stainless steel case and bracelet, textured electric blue dial,
unidirectional rotating bezel, helium escape valve at 10:00, screw-
down crown and case back, precision Swiss Quartz movement, and date
calendar. Face: 36.25 mm diameter.Omega Midsize Watch Omega Seamaster
Professional - 2263.80 / 226380 / 2263.80.00 / 22638000 Omega
Seamaster 300m 2263.80 Brand OmegaSeries Omega SeamasterGender
MidsizeCase Material Stainless SteelCase Thickness 11.4 mmCase
Diameter 36.25 mmDial Color BlueBezel Unidirectional RotatingMovement
QuartzClasp Push Button DeploymentBracelet 7" Stainless SteelWater
Resistant 300 Meters (1000 Feet)Crystal Scratch Resistant
SapphireWarranty Warranty service for this watch will be offered
through fashion163.com and not the manufacturer. Omega watches have a
2 year fashion163.com warranty. Please click here for additional watch
warranty information.Item Variations 226380 / 2263.80.00 /
22638000Additional Information Date Display At 3 O'Clock, Luminescent
Hands and MarkersOmega watches have been a standard for quality and
excellence for over 150 years, when the company began as Switzerland's
first watch manufacturer. When elegance and strength come together to
form an extraordinary timepiece, the result can only be an Omega
wristwatch. Omega watches are proud to be endorsed by many of the
world's leading athletes and celebrities, the most prominent being
James Bond 007. The Omega Seamaster watch made its first silver screen
debut in1995 in the James Bond 007 movie Goldeneye. The Omega
Constellation, Omega Aqua Terra, Omega Speedmaster, Omega double
eagle, Omega Broad Arrow, and Omega Co-Axial series are on sale at
fashion163 at competitive prices.Omega Seamaster 300m 2263.80 is brand
new, join thousands of satisfied customers and buy your Omega
Seamaster 300m 2263.80 with total satisfaction . A fashion163.com 30
Day Money Back Guarantee is included with every Omega Seamaster 300m
2263.80 for secure, risk-free online shopping. fashion163.com does not
charge sales tax for the Omega Seamaster 300m 2263.80, unless shipped
within New York State. fashion163.com is rated 5 stars on the Yahoo!
network.
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

Blancpain Villeret Mens Watch 4082-3642-55B

2009-11-23T17:36:51Z

Blancpain Villeret Mens Watch 4082-3642-55B

http://www.watchestrade.net/Blancpain-Villeret.html
http://www.watchestrade.net/Blancpain-Watches.html
http://www.watchestrade.net/Blancpain-Villeret-Mens-Watch-4082-3642-55B.html

http://www.watchestrade.net/
 Blancpains self-winding chronographs are among the
smallest and the slimmest chronograph movements in the world owing to
a totally new construction concept: The coupling-clutch wheel also
functions as a brake; no additional coupling wheel or blocker is
required. And only one finger drives the minute and hour counter. 
Established in 1735 by its founder Jehan-Jacques Blancpain, this
master watch manufacturer is renowned for its horological
complications. The company is also well-known for its Fifty-Fathoms
watch, selected by the US Navy and worn by Jacques Cousteau in his
award winning film. In 1984, Blancpain launched the world's smallest
movement, followed shortly thereafter in 1989 by the launch of the
world's thinnest movement.
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

Movado Bareleto Diamond & Blue Topaz Bangle Ladies Watch 0605475

2009-11-23T17:36:45Z

Movado Bareleto Diamond & Blue Topaz Bangle Ladies Watch 0605475

http://www.watchestrade.net/Movado-Bareleto.html
http://www.watchestrade.net/Movado-Watches.html
http://www.watchestrade.net/Movado-Bareleto-Diamond-Blue-Topaz-Bangle-Ladies-Watch-0605475.html

http://www.watchestrade.net/
 High-polished stainless steel case and hinged bangle
bracelet. Mirrored Museum dial. Bezel and bracelet set with diamonds.
Bangle ends set with blue topaz. Spring-loaded hinge for ease and
comfort. Swiss quartz movement. Water resistant at 30 meters (100
feet). Movado Bareleto Diamond & Blue Topaz Bangle Ladies Watch
0605475 / 605475
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

Tag Heuer Link Blue Mother-of-Pearl Ladies Watch WJF131D.BA0572

2009-11-23T17:36:21Z

Tag Heuer Link Blue Mother-of-Pearl Ladies Watch WJF131D.BA0572

http://www.watchestrade.net/TAG-Heuer-Link.html
http://www.watchestrade.net/TAG-Heuer-Watches.html
http://www.watchestrade.net/Tag-Heuer-Link-Blue-Mother-of-Pearl-Ladies-Watch-WJF131D.BA0572.html

http://www.watchestrade.net/
 Stainless steel case and bracelet. Blue mother-of-pearl
dial with 11 Top Wesselton (VVS) diamond hour markers. Screw-in steel
crown. Double safety clasp with folding buckle. Curved scratch
resistant sapphire crystal. Quartz movement. Water resistant at 200
meters (660 feet). Tag Heuer Link Blue Mother-of-Pearl Ladies Watch
WJF131D.BA0572
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

Seiko Coutura Diamond Gold-tone Steel Ladies Watch SXGN28

2009-11-23T17:35:51Z

Seiko Coutura Diamond Gold-tone Steel Ladies Watch SXGN28

http://www.watchestrade.net/Seiko-Coutura.html
http://www.watchestrade.net/Seiko-Watches.html
http://www.watchestrade.net/Seiko-Coutura-Diamond-Gold-tone-Steel-Ladies-Watch-SXGN28.html

http://www.watchestrade.net/
 Gold-tone stainless steel case and bracelet. Black
dial. Diamond bezel. Scratch resistant sapphire crystal. Push button
deployment clasp. Cabochon crown. Quartz movement. Water resistant at
30 meters (100 feet).
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

Audemars Piguet Jules Audemars Equation of Time Mens Watch 26003BC.OO.D002CR.01

2009-11-23T17:35:43Z

Audemars Piguet Jules Audemars Equation of Time Mens Watch
26003BC.OO.D002CR.01

http://www.watchestrade.net/Audemars-Piguet-Jules-Audemars.html
http://www.watchestrade.net/Audemars-Piguet-Watches.html
http://www.watchestrade.net/Audemars-Piguet-Jules-Audemars-Equation-of-Time-Mens-Watch-26003BC.OO.D002CR.01.html

http://www.watchestrade.net/
 Jules Audemars and Edward Piguet were both in
their early twenties when they founded Audemars Piguet in 1875. In
1972 AP launched a line of mechanical watches with hexagonal screws
that fastened a porthole-like bezel. Thus was born the Royal Oak, in
honor of the British Royal Navy's line of ships bearing the same name.
The Royal Oak is among many of the most specialized and complex
watches produced by this famous manufactory.
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

Girard Perregaux Richeville Diamond 18kt White Gold Brown Leather Ladies Watch 26500-0-53-72M7

2009-11-23T17:35:30Z

Girard Perregaux Richeville Diamond 18kt White Gold Brown Leather
Ladies Watch 26500-0-53-72M7

http://www.watchestrade.net/Girard-Perregaux-Richeville.html
http://www.watchestrade.net/Girard-Perregaux-Watches.html
http://www.watchestrade.net/Girard-Perregaux-Richeville-Diamond-18kt-White-Gold-Brown-Leather-Ladies-Watch-26500-0-53-72M7.html

http://www.watchestrade.net/
 Availability: Contact Us For Availability Need
Assistance? Call us at 866-581-JOMAGirard Perregaux Richeville Diamond
18kt White Gold Brown Leather Ladies Watch 26500-0-53-72M7 18kt White
Gold Case. Brown Leather Strap. Mother-of-pearl Dial With 8 Diamonds.
Fixed Bezel. Scratch Resistant Sapphire Crystal. Tang Clasp.
Chronograph. Case Diameter 29.5mm. Case Thickness 12mm. Automatic
Movement. Water Resistant At 30 meters (100 feet). Girard Perregaux
Richeville Diamond 18kt White Gold Brown Leather Ladies Watch
26500-0-53-72M7 Girard Perregaux Richeville Diamond 18kt White Gold
Brown Leather Ladies Watch 26500-0-53-72M7 Brand Girard
PerregauxSeries Girard Perregaux RichevilleGender LadiesCase Material
18kt White GoldCase Thickness 12mmCase Diameter 29.5mmDial Color
Mother-of-pearl With 8 DiamondsBezel FixedMovement AutomaticClasp
TangBracelet Brown LeatherWater Resistant 30m/100ftCrystal Scratch
Resistant SapphireWarranty 2 Year fashion163.com WarrantyItem
Variations 26500.0.53.72M7, 26500-0-53-72M7, 26500/0/53/72M7,
2650005372M7Additional Information ChronographThe soul of a watch is
embodied in the subtlety of its movement, a work of art that only very
few master craftsmen still know how to produce. In over two centuries
of existence, Girard-Perregaux has created some truly remarkable
timepieces such as their Cat's Eye, Vintage 1945, Lady S, Sport
Classique, Ferrari, Richeville, Elegant Classique, Seahawk,
Faudrayante, Laureato EVO3 series watches. Girard-Perregaux watches
incorporate a subtle combination of traditional watchmaking skills and
cutting-edge technology resulting in unique timepieces whose movements
have undergone the strictest quality control. Deeply committed to the
art of watchmaking, the Girard-Perregaux manufactory constantly
strives to enrich its heritage and continuously meet the challenge of
achieving an even higher level of quality and reliability. Despite its
small size, Girard-Perregaux strives to make the widest variety of
models available to fine watch enthusiasts.Girard Perregaux Richeville
Diamond 18kt White Gold Brown Leather Ladies Watch 26500-0-53-72M7 is
brand new, join thousands of satisfied customers and buy your Girard
Perregaux Richeville Diamond 18kt White Gold Brown Leather Ladies
Watch 26500-0-53-72M7 with total satisfaction . A fashion163.com 30
Day Money Back Guarantee is included with every Girard Perregaux
Richeville Diamond 18kt White Gold Brown Leather Ladies Watch
26500-0-53-72M7 for secure, risk-free online shopping. fashion163.com
does not charge sales tax for the Girard Perregaux Richeville Diamond
18kt White Gold Brown Leather Ladies Watch 26500-0-53-72M7, unless
shipped within New York State. fashion163.com is rated 5 stars on the
Yahoo! network.
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

Re: Reg 64-bit architecture support for Spidermonkey 1.5 andNSPR4.4.1components

2009-11-23T15:49:46Z

On 11/23/2009 01:15 PM, Puneet wrote:

> On Nov 23, 11:43 pm, Jason Orendorff<jorendo...@...> wrote:
>> On 11/23/2009 10:31 AM, Rajesh N wrote:
>>
>>> d) JS 1.8 code still has many uses of JS_PTR_TO_UINT32, JS_PTR_TO_UINT32 and
>>> reverse conversion macros. On 64-bit systems, how can we guarantee there is
>>> no data loss when a pointer value of 8 bytes is typecated/assigned to a 4
>>> byte integer?
>>
>> The name of that macro is a lie: the type of the result is actually
>> jsuword, which is pointer-sized.
>
> jsuword is pointer sized but, JS_PTR_TO_UINT32 is actually truncation
> of pointer information, as it typecast to jsint, which is a 4 byte
> integer on 64 bit platform.
>
> Macro : jstypes.h
> #define JS_PTR_TO_INT32(x) ((jsint)((char *)(x) - (char *)0))

Oops! Yes, you are completely right about that. The macro truncates.

> For eg, in func DefineProperty, it first typecast to jsid from jsint
> and same jsid is accessed as an atom pointer after converting it back
> to jsint in func DefineNativeProperty.

if (attrs & JSPROP_INDEX) {
id = INT_TO_JSID(JS_PTR_TO_INT32(name));

This is OK because JSPROP_INDEX means that `name` is actually an integer
that fits in 31 bits. The data is not pointer data at all.

https://developer.mozilla.org/En/JS_GetPropertyAttributes#Property_attributes

>> I have filed a bug to get rid of the last few remaining uses of these
>> macros, bug 530583. But the code is 64-bit safe already, despite the
>> misleading INT32 in the macro names.

I still believe this last sentence is true.

-j
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

New harness for shell JSTests

2009-11-23T13:13:58Z

I just landed to the tracemonkey repo a new harness for running the
shell JSTests that we've been working on for a while. My primary goal
was to make the tests run faster on multiple cores and to be easier to
run day-to-day for devs, but it also supports Tinderbox-style reporting
and a bunch of other new features.

The basic usage is:

# in directory js/src/tests
python jstests.py PATH_TO_JS

This will run with a progress bar and report results in a compact way.
The 3 numbers on the left are mochitest-style "passed/failed/known
fails". There is no need to do a baseline run; bc's new manifest files
indicate which tests are known to fail, should be skipped, etc.

If you have more than 2 cores, then you probably want '-j N' to run
faster. I think it can run the whole suite in about a minute on an
8-core machine.

Here are a few more sample command lines:

# print options help text
python jstests.py -h

# tinderbox-style output
python jstests.py PATH_TO_JS --tinderbox

# run only tests that contain the string '263935'
python jstests.py PATH_TO_JS 263935

# run only those tests and print command lines and output
python jstests.py -so PATH_TO_JS 263935

# run only those tests in valgrind
python jstests.py --valgrind PATH_TO_JS 263935

# run that test in gdb
python jstests.py -g PATH_TO_JS 263935

Note that the options are processed with Python OptionParse, so they can
come in any order. E.g., this is fine:

# run only those tests and print command lines and output
python jstests.py PATH_TO_JS 263935 -so

Finally, thanks to Bob Clary and Jason Orendorff for patiently reviewing
multiple versions of this patch and guiding me on features,
understanding the test, and Python styling. And thanks to everyone who
encouraged me by trying out the prototype versions and liking it. :-)

--
Dave

_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

RE: Reg 64-bit architecture support for Spidermonkey 1.5andNSPR4.4.1components

2009-11-23T11:32:06Z

On Nov 23, 11:43 pm, Jason Orendorff <jorendo...@...> wrote:
> On 11/23/2009 10:31 AM, Rajesh N wrote:
> > d) JS 1.8 code still has many uses of JS_PTR_TO_UINT32, JS_PTR_TO_UINT32
and
> > reverse conversion macros. On 64-bit systems, how can we guarantee there
is
> > no data loss when a pointer value of 8 bytes is typecated/assigned to a
4
> > byte integer?
> The name of that macro is a lie: the type of the result is actually
> jsuword, which is pointer-sized.

jsuword is pointer sized but, JS_PTR_TO_UINT32 is actually truncation
of pointer information, as it typecast to jsint, which is a 4 byte
integer on 64 bit platform.
Macro : jstypes.h
#define JS_PTR_TO_INT32(x) ((jsint)((char *)(x) - (char *)0))
File : jsapi.c
3101: static JSBool
3102 DefineProperty(JSContext *cx, JSObject *obj, const char *name,
jsval value,
3103: JSPropertyOp getter, JSPropertyOp setter, uintN
attrs,
3104: uintN flags, intN tinyid)
3105: {
3106: jsid id;
3107: JSAtom *atom;
3108:
3109: if (attrs & JSPROP_INDEX) {
3110: id = INT_TO_JSID(JS_PTR_TO_INT32(name));
For eg, in func DefineProperty, it first typecast to jsid from jsint
and same jsid is accessed as an atom pointer after converting it back
to jsint in func DefineNativeProperty.
Filet : jsapi.c
3119: if (flags != 0 && OBJ_IS_NATIVE(obj)) {
3120: return js_DefineNativeProperty(cx, obj, id, value,
getter, setter,
3121 attrs, flags, tinyid,
NULL);
It does a series of operations, which does not seems to guarantee
restoration of truncated data.
> I have filed a bug to get rid of the last few remaining uses of these
> macros, bug 530583. But the code is 64-bit safe already, despite the
> misleading INT32 in the macro names.
> -j

-Puneet

_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

Re: Reg 64-bit architecture support for Spidermonkey 1.5 andNSPR4.4.1components

2009-11-23T11:15:51Z

On Nov 23, 11:43 pm, Jason Orendorff <jorendo...@...> wrote:
> On 11/23/2009 10:31 AM, Rajesh N wrote:
>
> > d) JS 1.8 code still has many uses of JS_PTR_TO_UINT32, JS_PTR_TO_UINT32 and
> > reverse conversion macros. On 64-bit systems, how can we guarantee there is
> > no data loss when a pointer value of 8 bytes is typecated/assigned to a 4
> > byte integer?
>
> The name of that macro is a lie: the type of the result is actually
> jsuword, which is pointer-sized.

jsuword is pointer sized but, JS_PTR_TO_UINT32 is actually truncation
of pointer information, as it typecast to jsint, which is a 4 byte
integer on 64 bit platform.

Macro : jstypes.h
#define JS_PTR_TO_INT32(x) ((jsint)((char *)(x) - (char *)0))

File : jsapi.c
3101: static JSBool
3102 DefineProperty(JSContext *cx, JSObject *obj, const char *name,
jsval value,
3103: JSPropertyOp getter, JSPropertyOp setter, uintN
attrs,
3104: uintN flags, intN tinyid)
3105: {
3106: jsid id;
3107: JSAtom *atom;
3108:
3109: if (attrs & JSPROP_INDEX) {
3110: id = INT_TO_JSID(JS_PTR_TO_INT32(name));

For eg, in func DefineProperty, it first typecast to jsid from jsint
and same jsid is accessed as an atom pointer after converting it back
to jsint in func DefineNativeProperty.
Filet : jsapi.c

3119: if (flags != 0 && OBJ_IS_NATIVE(obj)) {
3120: return js_DefineNativeProperty(cx, obj, id, value,
getter, setter,
3121 attrs, flags, tinyid,
NULL);

It does a series of operations, which does not seems to guarantee
restoration of truncated data.

> I have filed a bug to get rid of the last few remaining uses of these
> macros, bug 530583. But the code is 64-bit safe already, despite the
> misleading INT32 in the macro names.
> -j

-Puneet
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

Re: Reg 64-bit architecture support for Spidermonkey 1.5 andNSPR4.4.1components

2009-11-23T10:43:30Z

On 11/23/2009 10:31 AM, Rajesh N wrote:
> d) JS 1.8 code still has many uses of JS_PTR_TO_UINT32, JS_PTR_TO_UINT32 and
> reverse conversion macros. On 64-bit systems, how can we guarantee there is
> no data loss when a pointer value of 8 bytes is typecated/assigned to a 4
> byte integer?

The name of that macro is a lie: the type of the result is actually
jsuword, which is pointer-sized.

I have filed a bug to get rid of the last few remaining uses of these
macros, bug 530583. But the code is 64-bit safe already, despite the
misleading INT32 in the macro names.

-j
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

Re: Reg 64-bit architecture support for Spidermonkey 1.5 andNSPR4.4.1components

2009-11-23T09:45:22Z

On Mon, Nov 23, 2009 at 11:31 AM, Rajesh N <rajeshn@...> wrote:

> a) File jsarena.c
> Function: JS_INIT_NAMED_ARENA_POOL
> Here argument "align" is of type size_t (8 bytes on 64-bit system). This
> argument "align" is passed as argument to JS_CeilingLog2 function.
>
> JS_CeilingLog2 prototype specifies that its argument is of type JSUint32
> (unsigned int, even on LP64 systems, as per the definition in jstypes.h).
>
> Won't such an invocation lead to data loss or truncation from unsigned long
> to unsigned int??

Only if you pass an extremely large value to it -- I don't think we'll
be aligning to anything that huge.

> b) Data struture definitions do not take care of padding explicitly.
> Example: JSConstDoubleSpec, JSPropertySpec etc in jspai.h
>
> c) Defnition of struct BinaryDigitReader (jsnum.c)
> struct BinaryDigitReader
> {
> uintN base; /* Base of number; must be a power of 2 */
> uintN digit; /* Current digit value in radix given by base */
> uintN digitMask; /* Mask to extract the next bit from digit */
> const jschar *digits; /* Pointer to the remaining digits */
> const jschar *end; /* Pointer to first non-digit */
> };
>
> Even on a 64-bit LP64 system, uintN is unsigned int (4 bytes). So,the
> pointer memebr digits is not aligned to be on 8-byte aligned address.

That's the compiler's problem: it needs to produce appropriate
alignment of members for its ABI; this is not unique to 64-bit, and
just basic C-compiler requirements.

> d) JS 1.8 code still has many uses of JS_PTR_TO_UINT32, JS_PTR_TO_UINT32 and
> reverse conversion macros. On 64-bit systems, how can we guarantee there is
> no data loss when a pointer value of 8 bytes is typecated/assigned to a 4
> byte integer?

You'd have to give the examples -- in most (all?) the operands of
these operations were produced by converting an int to a pointer,
meaning that it's known to be safe. You could add assertions in the
macros I guess, if you thought you'd found a case that was wrong, or
just post here with details.

Mike
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

RE: Reg 64-bit architecture support for Spidermonkey 1.5 andNSPR4.4.1components

2009-11-23T08:31:04Z

Hi Jason/All,

I noticed a few points in JS 1.8 code where I had some queries on the 64-bit
compatibility aspects.

Could you please help me get clear on these issues?

a) File jsarena.c
Function: JS_INIT_NAMED_ARENA_POOL
Here argument "align" is of type size_t (8 bytes on 64-bit system). This
argument "align" is passed as argument to JS_CeilingLog2 function.

JS_CeilingLog2 prototype specifies that its argument is of type JSUint32
(unsigned int, even on LP64 systems, as per the definition in jstypes.h).

Won't such an invocation lead to data loss or truncation from unsigned long
to unsigned int??

b) Data struture definitions do not take care of padding explicitly.
Example: JSConstDoubleSpec, JSPropertySpec etc in jspai.h

c) Defnition of struct BinaryDigitReader (jsnum.c)
struct BinaryDigitReader
{
uintN base; /* Base of number; must be a power of 2 */
uintN digit; /* Current digit value in radix given by base */
uintN digitMask; /* Mask to extract the next bit from digit */
const jschar *digits; /* Pointer to the remaining digits */
const jschar *end; /* Pointer to first non-digit */
};

Even on a 64-bit LP64 system, uintN is unsigned int (4 bytes). So,the
pointer memebr digits is not aligned to be on 8-byte aligned address.

d) JS 1.8 code still has many uses of JS_PTR_TO_UINT32, JS_PTR_TO_UINT32 and
reverse conversion macros. On 64-bit systems, how can we guarantee there is
no data loss when a pointer value of 8 bytes is typecated/assigned to a 4
byte integer?

Thanks
Rajesh

-----Original Message-----
From: dev-tech-js-engine-bounces+rajeshn=huawei.com@...
[mailto:dev-tech-js-engine-bounces+rajeshn=huawei.com@...] On
Behalf Of Jason Orendorff
Sent: Wednesday, November 18, 2009 2:20 AM
To: dev-tech-js-engine@...
Subject: Re: Reg 64-bit architecture support for Spidermonkey 1.5
andNSPR4.4.1components

On 11/17/2009 12:05 AM, Rajesh N wrote:
> a) Is JS 1.8.0 RC1 64-bit compatible? Does the sourcebase take care of
> issues like address alignment, padding, typecasts (pointer<->integer) and
> conversions?

Yes.

> b) Yes, I observe that JS 1.6 added E4X, JS 1.7 added new concepts like
> iterators,generators etc. My understanding is JS 1.8.0 builds over the
same
> code base. However, has these enhancements affected any basic features
that
> a JS engine embedded application would need - like create runtime, create
> context, compile and execute scripts, compile and call functions,
define/set
> properties etc?

I don't know. Try it!

-j
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

Re: Lock contention and performance problems

2009-11-23T07:37:58Z

On 11/18/2009 04:50 PM, gurkhali wrote:
> Sure I can take a stab at the patch.
>
> Ok then that leads me to the other question then. Why does the helper
> thread not get created when JS_THREADSAFE is not enabled?

Without JS_THREADSAFE we avoid anything that would require linking NSPR,
that's all.

> On the post
> I referred to earlier Brenden mentioned that barring some possible
> issues, creating multiple non-sharing runtime on different threads are
> supported without the JS_THREADSAFE option. But some of the earlier
> posts (shown below) explicitly prohibit that. I suspect that things
> have changed since 2006 but I wanted to make sure that was the case.
>
> Can you please comment on where we stand currently. I would be more
> than happy to find fix bugs found along the way but I don't want to
> spend time in the weeds if its not some thing that the engine is
> designed for.

The engine is designed to avoid sharing state between runtimes. There is
one known spot in dtoa where we don't do this, and that's bug 509857
which you linked earlier.

There might be one or two more hiding in the engine. I would be a little
surprised. Like Brendan, I would be more than happy to land patches
fixing this unnecessary limitation.

-j
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

Re: Get a variable in the scope chain

2009-11-20T07:32:40Z

On 11/18/2009 05:06 PM, franck.fr wrote:
> If I use the following code to get variables value, a, b and c are
> properly detected by JS_HasProperty but JS_GetProperty say that b has
> undefined (JSVAL_VOID) value:

Franck, this is hopeless. The JS engine is not going to keep around
apparently-dead variables on the off chance that someone might call a
native function that uses the debugger APIs to read them off the stack.
The debugger APIs don't work that way. You can use eval:

var a = 'a';
function foo() {
var b = 'b';
function bar() {
var c = 'c';
Print(eval(Expand('$(a)$(b)$(c)')));
}
bar();
}
foo();

where Expand('$(a)$(b)$(c)') returns the string '""+(a)+(b)+(c)'.

Or you can run your JS code through the C preprocessor before passing it
to SpiderMonkey, and use something like

#define Expand(s) eval(__expand(s))

-j
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

Re: How to build JS 1.8.0 using MSVC 6.0 (win32)

2009-11-20T07:00:26Z

Hi Puneet,

"Puneet Sharma" <puneetbs@...> wrote in message
news:mailman.1415.1258575222.526.dev-tech-js-engine@......
> We have corrected our build. Now Issue 2 and Issue 3 are resolved.
> jsparse.c assert is gone once we ported to VC2005, probably it is problem
> in VC6.
> Mozilla build document was useful in this case.

This blog has links to a VS 2005 solution file that I have successfully used
to build spider monkey 1.8.1:

http://bindzus.wordpress.com/2008/02/08/spidermonkey-solution-file-for-microsoft-visual-studio-2005/

I'm sure I read somewhere on one of the Mozilla wiki pages that VS6 was no
longer supported as a build platform so I gave up and moved to VS 2005 which
seems to work fine.

Colin

_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

Spidermonkey 1.8rc1 memory usage

2009-11-20T04:00:12Z

Hi,

I have recently moved to JS 1.8rc1 from JS 1.5. Thanks to SM, for
maintaining its backward compatibility for such a long time.
But, now JS 1.8 is reporting out of memory for same scenarios which
were used to be OK for JS 1.5.

I am using spidermonkey API's in below sequence:
1. JS_NewRuntime(1 << 14); maxbytes : 1 << 14 bytes
2. JS_NewContext(rt, 1<<13)
3. JS_NewObject() : Create class object
4. JS_InitStandardClasses

I debugged this issue and got to know that JS 1.8 is reporting "out of
memory" in InitStandardClasses API. To get rid of this, I tried increasing
size of runtime, so it didn't work with "1<<15", but got initialized with
1<<16.

Memory required for initialization in JS 1.8 is about 4 times the size of
JS 1.5 took. Or these is something which I need do along with current set of
API. Or it has something to do with Garbage collector. I tried using
JS_GetGCParameter API, but it also specifies same values which JS_NewRuntime
specifies.

Now, memory requirement has increased subsequently, is there any way to
curb this memory consumption which is getting huge in initialization itself.

Regards,
Puneet

_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

Re: Get a variable in the scope chain

2009-11-18T15:06:20Z

If I use the following code to get variables value, a, b and c are
properly detected by JS_HasProperty but JS_GetProperty say that b has
undefined (JSVAL_VOID) value:

JSStackFrame *fp = JS_GetScriptedCaller(cx, NULL);
for ( JSObject *scope = JS_GetFrameScopeChain(cx, fp); scope; scope =
JS_GetParent(cx, scope) ) {
JS_HasProperty(cx, scope, name, &found);
if ( found ) {
JS_GetProperty(cx, scope, name, vp);
return JS_TRUE;
}
}

Franck.
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

Re: Lock contention and performance problems

2009-11-18T14:50:34Z

Sure I can take a stab at the patch.

Ok then that leads me to the other question then. Why does the helper
thread not get created when JS_THREADSAFE is not enabled? On the post
I referred to earlier Brenden mentioned that barring some possible
issues, creating multiple non-sharing runtime on different threads are
supported without the JS_THREADSAFE option. But some of the earlier
posts (shown below) explicitly prohibit that. I suspect that things
have changed since 2006 but I wanted to make sure that was the case.

Can you please comment on where we stand currently. I would be more
than happy to find fix bugs found along the way but I don't want to
spend time in the weeds if its not some thing that the engine is
designed for.

http://groups.google.com/group/mozilla.dev.tech.js-engine/browse_thread/thread/3c3980fde4e2fd50/ff6280eab3e5f70b?lnk=gst&q=JS_THREADSAFE#ff6280eab3e5f70b

http://groups.google.com/group/mozilla.dev.tech.js-engine/browse_thread/thread/95f9bc2f67a3d608/27c207eb5f1ae6ae?lnk=gst&q=JS_THREADSAFE#27c207eb5f1ae6ae

Bhushan

On Nov 18, 12:18 pm, Jason Orendorff <jorendo...@...> wrote:

> On 11/17/2009 06:57 PM, gurkhali wrote:
>
> > [...] Instantiating interpretor per
> > thread seems to work great and I am running with JS_THREADSAFE option.
> > The only catch now seem to be that each of the runtime is creating a
> > back ground thread.
>
> Ah - yes, we ship all calls to free() off to a background thread, for
> performance. We don't really need a background thread per runtime, so I
> filed a bug:
>
> Bug 529526 - SpiderMonkey launches one JSBackgroundThread per JSRuntimehttps://bugzilla.mozilla.org/show_bug.cgi?id=529526
>
> You could change this to a single global JSBackgroundThread. You can use
> PR_CallOnce to make sure the thread is only launched once. If you're
> willing to write the patch, I think we'll take it.
>
> -j

_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

Re: Get a variable in the scope chain

2009-11-18T14:47:09Z

Thank you for the clarification.

> > Is there a better method to access myVar without using eval-like
> > functions ?
>
> I don't think so. What are you trying to do?
>

I try to enable my Expand() function to use the scope chain. eg:
var a = 'a';
function foo() {
var b = 'b';
function bar() {
var c = 'c';
Print( Expand('$(a)$(b)$(c)') );
};
bar();
};
foo();

Franck.
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

Re: Lock contention and performance problems

2009-11-18T12:18:11Z

On 11/17/2009 06:57 PM, gurkhali wrote:
> [...] Instantiating interpretor per
> thread seems to work great and I am running with JS_THREADSAFE option.
> The only catch now seem to be that each of the runtime is creating a
> back ground thread.

Ah - yes, we ship all calls to free() off to a background thread, for
performance. We don't really need a background thread per runtime, so I
filed a bug:

Bug 529526 - SpiderMonkey launches one JSBackgroundThread per JSRuntime
https://bugzilla.mozilla.org/show_bug.cgi?id=529526

You could change this to a single global JSBackgroundThread. You can use
PR_CallOnce to make sure the thread is only launched once. If you're
willing to write the patch, I think we'll take it.

-j
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

RE: How to build JS 1.8.0 using MSVC 6.0 (win32)

2009-11-18T12:13:36Z

Hi,

Thanks for response.
Pls find inline comments.

Regards
Puneet

On Nov 18, 10:34 pm, Wes Garland <w...@...> wrote:
> Rajesh;
>
> I think you want to google up "mozilla build". IIUC, the old js.mak stuff
> hasn't been supported since js1.7 (although should be relatively easy to
> make work).
>
> Off the top of my head, from your errors, you want to include your obj dir
> in your include path, and you need to look at and examine the reason for
> your that assert in jsparse.c on line 93.

We have corrected our build. Now Issue 2 and Issue 3 are resolved.
jsparse.c assert is gone once we ported to VC2005, probably it is problem in VC6.
Mozilla build document was useful in this case.

But, we were facing some linking issue related to _js_FreeStack and lot of linking errors, we have included jsinvoke.c in our build but now we are getting another linking error,
jsiter.obj : error : LNK2019: unresolved external symbol _js_Interpret in referenced in function _SendToGenerator
jsinterp.obj : error : LNK2001: unresolved external symbol _js_Interpret

Defination of js_Interpret is present in jsinterp.c with condition js_invoke__c not defined. But, when we exclude jsinvoke.c which defines js_invoke__c we get other linking errors related to _js_FreeStack(as below).

jsapi.obj : error LNK2019: unresolved external symbol _js_FreeStack reference in function _Js_PushArgumentsVA
jsarray.obj : error: LNK2001 : unresolved external symbol _js_FreeStack
jsfun.obj : error: LNK2001 : unresolved external symbol _js_FreeStack
jsstr.obj : error: LNK2001 : unresolved external symbol _js_FreeStack
jsapi.obj : error: LNK2001 : unresolved external symbol _js_AllocStack
...
...

>
> You might also want to google up "mozilla build" on the moz developer wiki.
>
> Wes
>
>
>
> On Wed, Nov 18, 2009 at 9:59 AM, Rajesh N <raje...@...> wrote:
> > Hi,
>
> > How can we build Spidermonkey JS 1.8.0 in Windows (32-bit) using Microsoft
> > Visual C++ 6.0 compiler (even using the command line build methods)?
>
> > I tried to follow the same approach as that for JS 1.5, but came across
> > multiple issues:
>
> > Issue1: js.mak not available.
>
> > I tried to use the js.mak provided athttp://blog.endflow.net/?p=55
> > <http://blog.endflow.net/?p=55〈=en> &lang=en
>
> > Issue2: jsparse.c compilation issues related to static asserts:
>
> > jsparse.c(93) : error C2057 : expected constant expression
>
> > jsparse.c(93) : error C2466 : cannot allocate an array of constant size 0
>
> > Issue3: jsscan.c compilation issues related to jsautokw.h
>
> > jsscan.c(112) : fatal error C1083 : Cannot open include file 'jsautokw.h':
> > No such file or directory
>
> > Can someone suggest the correct way of building JS 1.8 on Win32 MSVC 6.0 ?
>
> > Thanks
>
> > Rajesh
>
> > _______________________________________________
> > dev-tech-js-engine mailing list
> > dev-tech-js-eng...@...
> >https://lists.mozilla.org/listinfo/dev-tech-js-engine
>
> --
> Wesley W. Garland
> Director, Product Development
> PageMail, Inc.
> +1 613 542 2787 x 102

_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

Re: Get a variable in the scope chain

2009-11-18T11:33:15Z

On 11/18/2009 09:24 AM, franck.fr wrote:

> I am trying to access a variable value in the current scope chain:
>
> function foo() {
> var myVar = 123;
> function bar() {
> Print( EvalVarByName('myVar') );
> };
> bar();
> };
> foo();

I see what's happening here. You're running into a JS optimization.

The debugger APIs can detect some optimizations that are otherwise
transparent. Here the JS compiler sees that bar does not actually close
on any local variables in foo, so its scope chain does not include foo's
locals. Only the debugger APIs can tell the difference.

If the function did actually use myVar, that part of the scope chain
would be retained.

> Is there a better method to access myVar without using eval-like
> functions ?

I don't think so. What are you trying to do?

Later, you wrote:
> Oh, I understand my mistake.
> I have to search in the scope chain of the caller of EvalVarByName,
> not EvalVarByName itself.

Alas, I think this comment is mistaken. JS_GetScriptedCaller already
skips the (non-scripted) stack frame of EvalVarByName itself. Try this:

function foo() {
var myVar = 123;
return function bar() {
Print( EvalVarByName('myVar') );
};
}
var bar = foo();
bar();

I don't think this will work for you.

-j
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

Re: How to build JS 1.8.0 using MSVC 6.0 (win32)

2009-11-18T09:34:08Z

Rajesh;

I think you want to google up "mozilla build". IIUC, the old js.mak stuff
hasn't been supported since js1.7 (although should be relatively easy to
make work).

Off the top of my head, from your errors, you want to include your obj dir
in your include path, and you need to look at and examine the reason for
your that assert in jsparse.c on line 93.

You might also want to google up "mozilla build" on the moz developer wiki.

Wes

On Wed, Nov 18, 2009 at 9:59 AM, Rajesh N <rajeshn@...> wrote:

> Hi,
>
>
>
> How can we build Spidermonkey JS 1.8.0 in Windows (32-bit) using Microsoft
> Visual C++ 6.0 compiler (even using the command line build methods)?
>
>
>
> I tried to follow the same approach as that for JS 1.5, but came across
> multiple issues:
>
>
>
> Issue1: js.mak not available.
>
> I tried to use the js.mak provided at http://blog.endflow.net/?p=55
> <http://blog.endflow.net/?p=55&lang=en> &lang=en
>
>
>
> Issue2: jsparse.c compilation issues related to static asserts:
>
> jsparse.c(93) : error C2057 : expected constant expression
>
> jsparse.c(93) : error C2466 : cannot allocate an array of constant size 0
>
>
>
> Issue3: jsscan.c compilation issues related to jsautokw.h
>
> jsscan.c(112) : fatal error C1083 : Cannot open include file 'jsautokw.h':
> No such file or directory
>
>
>
> Can someone suggest the correct way of building JS 1.8 on Win32 MSVC 6.0 ?
>
>
>
> Thanks
>
> Rajesh
>
> _______________________________________________
> dev-tech-js-engine mailing list
> dev-tech-js-engine@...
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

Re: Get a variable in the scope chain

2009-11-18T07:57:56Z

On Nov 18, 4:50 pm, "John J. Barton" <johnjbar...@...>
wrote:

> franck.fr wrote:
> > Hello.
>
> > I am trying to access a variable value in the current scope chain:
>
> > function foo() {
> > var myVar = 123;
> > function bar() {
> > Print( EvalVarByName('myVar') );
> > };
> > bar();
> > };
> > foo();
>
> > EvalVarByName native function is define as:
> > ...
> > JSStackFrame *fp = JS_GetScriptedCaller(cx, NULL);
> > JSBool found;
> > JSObject *scope = JS_GetFrameScopeChain(cx, fp);
> > for ( ; scope; scope = JS_GetParent(cx, scope) ) {
>
> > JS_HasProperty(cx, scope, name, &found);
> > if ( found )
> > return JS_GetProperty(cx, scope, name, rval);
> > }
> > ...
> > (src:http://code.google.com/p/jslibs/source/browse/trunk/src/tools/jsTest....)
>
> > note1: if I remove the outer function foo, EvalVarByName('myVar')
> > returns 123.
>
> That suggests that your code works for the global scope but fails for
> the closure.
>
> If you add a dummy EvalVarByName JS function, put the code in to
> Firebug, and set a breakpoint in EvalVarByName you can look at the
> scopes in the Watch side panel.
>
> jjb

Oh, I understand my mistake.
I have to search in the scope chain of the caller of EvalVarByName,
not EvalVarByName itself.
Thanks.

Franck.
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine