How can I provide file content to shell.js

[zeev.f...@gmail.com]

Hi,
The read() function defined in shell.js by call of readBinaryFile() - JSC case or by call of readbuffer() - V8 case. That assumes usage in V8 or JSC JS VM.
The default js shell (applied by utils/jsshell/js script) from some reason doesn't work because of issues with ./utils/jsshell/js-bin ... may be I'm missing some environment variables ?
Is there way to use SpiderMonkey console? or only V8 and JSC may be used ?

[Till Schneidereit]

Hi Ze'ev,

the SpiderMonkey shell is what we're using in our day-to-day development. I
personally have it in my path and regularly compile new versions straight
from mozilla-central. You can also download a new build from
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/.

I'm curious about the issues you have with the provided version, though.
Can you give more details about the errors you see?

> _______________________________________________
> dev-shumway mailing list
> dev-s...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-shumway
>

[zeev.f...@gmail.com]

Hi Till,
I've tried to run acceptance test for avm2:
"js build/ts/shell.js -s -x test/avm2/acceptance.json"

I have 2 questions:

1. Does that approach covers all acceptance tests for AVM2, may be can you propose other way to test correctness of AVM2 or are there different/additional to test it
2. Some test were failed:

========================================================================
getproperty of null ref FAILED! expected: VerifyError should have been thrown, actual: 11

STRICTEQ: call length via restArgcHelper FAILED! expected: number[3], actual: undefined[undefined]

new Date(-8633982067200000) PASSED!
Date(1969,11,31,16,0,0,0) FAILED! expected: true got: false
.....
Date(2031,11,31,16,0,0,0) FAILED! expected: true got: false
new Date( 1969,11,31,15,59,59,999).getTime() PASSED!

Date.parse( + givenDate + ).toLocaleString()) FAILED! expected: 951782400000 got: 1020297600000
Date.parse( + givenDate + ).toLocaleString()) FAILED! expected: 951782399000 got: 1017791999000
Date.parse( + givenDate + ).toLocaleString()) FAILED! expected: 951782400000 got: 1020297600000
Date.parse( + givenDate + ).toLocaleString()) PASSED!
Date.parse( + givenDate + ).toLocaleString()) FAILED! expected: 1104537599000 got: 1152748799000
Date.parse( + givenDate + ).toLocaleString()) PASSED!

delete( int.MIN_VALUE ) FAILED! expected: false got: true
delete( int.MIN_VALUE ); int.MIN_VALUE FAILED! expected: -2147483648 got: undefined

int.MAX_VALUE + 1 = -2147483648 FAILED! expected: -2147483648 got: 0
int.MAX_VALUE + 1 = -2147483648 FAILED! expected: -2147483648 got: 1
increment int at int.MAX_VALUE FAILED! expected: -2147483648 got: 1
int.MIN_VALUE - 1 = 2147483647 FAILED! expected: 2147483647 got: 0
int.MIN_VALUE - 1 = 2147483647 FAILED! expected: 2147483647 got: -1
decrement int at int.MIN_VALUE FAILED! expected: 2147483647 got: -1
int.MAX_VALUE * 2 = -2 FAILED! expected: -2 got: 0

int.MAX_VALUE << 1 FAILED! expected: -2 got: 0

....

========================================================================

Some failures probably follows from the obsolete test assumptions that do not match current JS implementation. But may be I'm wrong, what is your opinion ? Are all acceptance tests passing on your system ?

[zeev.f...@gmail.com]

Hi Till,
Thanks for your comments !
First of all, I've updated SpiderMonkey to the latest version and succeed to get output when xml.abc was ran by shell.js !!! Thanks again for your advice !!!

Actually I have had a couple of issues with adaptation of Shumway project to mine environment: 64bit Debian OS.

1. From some reason the default JS shell returned error:

./utils/jsshell/js build/ts/shell.js -s -x test/avm2/shumway/xml.abc
./utils/jsshell/js: line 3: ./utils/jsshell/js-bin: No such file or directory

The same error I received even after the local path:"./utils/jsshell/js-bin" was changed to global one

2. Compilation of SpiderMonkey on 64bit system requires some changes, I have found them at: https://groups.google.com/forum/#!topic/mozilla.dev.tech.js-engine/uRNk0wKRv1M (based on: https://developer.mozilla.org/en/Compiling_32-bit_Firefox_on_a_Linux_64-bit_OS)

I would like to run avm2 tests, but the direct call of "grunt exec:test_avm2_quick" returns:

" Running "exec:test_avm2_quick" (exec) task
Verifying property exec.test_avm2_quick exists in config...ERROR
"

Probably I'm missing some setting or configuration file for avm2 tests ... I will check that later.

Best Regards,
Ze'ev

[Till Schneidereit]

Hi Ze'ev,

On Tue, Jun 16, 2015 at 11:30 PM, <zeev.f...@gmail.com> wrote:

> Hi Till,
> I've tried to run acceptance test for avm2:
> "js build/ts/shell.js -s -x test/avm2/acceptance.json"
>
> I have 2 questions:
>
> 1. Does that approach covers all acceptance tests for AVM2, may be can you
> propose other way to test correctness of AVM2 or are there
> different/additional to test it
>

That covers that particular test suite, yes. We have a few other suites
which can be run with various testing commands (see below).

> 2. Some test were failed:
>

Some failures probably follows from the obsolete test assumptions that do
> not match current JS implementation. But may be I'm wrong, what is your
> opinion ? Are all acceptance tests passing on your system ?
>

Failures are expected, yes: we don't currently have 100% compatibility. In
many cases, that's because we decided that some extreme corner case isn't
relevant. In other cases, we simply have bugs. You can see our current
expectation for how many errors we encounter in the various
"test/test_*.baseline" files.

> I would like to run avm2 tests, but the direct call of "grunt
exec:test_avm2_quick" returns:
>
> " Running "exec:test_avm2_quick" (exec) task
> Verifying property exec.test_avm2_quick exists in config...ERROR
> "

That command doesn't exist anymore. You can run `grunt -h` to get a list of
commands. If you search the output for "test" you should get a good
overview. Note that the suites with "ats" in the name require a set of SWFs
to be present that we sadly can't give you because we don't have the
copyrights, so can only use them internally.