Re: [webkit-dev] platform-specific differences in test case inputs
So this thread kinda died. Anyone have any suggestions? Where is JSC's SerializedScriptValue consistency tested? Alec On Tue, Sep 18, 2012 at 1:22 PM, Alec Flett alecfl...@chromium.org wrote: Sorry I totally left out the I expose this through Internals - and adam has explained the rationale On Tue, Sep 18, 2012 at 12:46 PM, Oliver Hunt oli...@apple.com wrote: What exactly are you trying to test here? The internal serialisation format isn't exposed anywhere (nor should it be). By definition newer formats won't be backwards compatible, or are you trying to ensure that newer deserialisers will be able to continue to deserialise old content? exactly. Where does JSC test this? I'm happy to follow whatever pattern is already established. Alec ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] platform-specific differences in test case inputs
It isn't, it's never been a concern as our serialisation format is simple enough to be hard to break. That said tests would be fine, i'm just not sure how you would do them nicely. --Oliver On Sep 19, 2012, at 1:50 PM, Alec Flett alecfl...@chromium.org wrote: So this thread kinda died. Anyone have any suggestions? Where is JSC's SerializedScriptValue consistency tested? Alec On Tue, Sep 18, 2012 at 1:22 PM, Alec Flett alecfl...@chromium.org wrote: Sorry I totally left out the I expose this through Internals - and adam has explained the rationale On Tue, Sep 18, 2012 at 12:46 PM, Oliver Hunt oli...@apple.com wrote: What exactly are you trying to test here? The internal serialisation format isn't exposed anywhere (nor should it be). By definition newer formats won't be backwards compatible, or are you trying to ensure that newer deserialisers will be able to continue to deserialise old content? exactly. Where does JSC test this? I'm happy to follow whatever pattern is already established. Alec ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] platform-specific differences in test case inputs
My suggestion is to write a unit test in Chromium's webkit_unit_test framework. Adam On Wed, Sep 19, 2012 at 1:50 PM, Alec Flett alecfl...@chromium.org wrote: So this thread kinda died. Anyone have any suggestions? Where is JSC's SerializedScriptValue consistency tested? Alec On Tue, Sep 18, 2012 at 1:22 PM, Alec Flett alecfl...@chromium.org wrote: Sorry I totally left out the I expose this through Internals - and adam has explained the rationale On Tue, Sep 18, 2012 at 12:46 PM, Oliver Hunt oli...@apple.com wrote: What exactly are you trying to test here? The internal serialisation format isn't exposed anywhere (nor should it be). By definition newer formats won't be backwards compatible, or are you trying to ensure that newer deserialisers will be able to continue to deserialise old content? exactly. Where does JSC test this? I'm happy to follow whatever pattern is already established. Alec ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] platform-specific differences in test case inputs
Background: some of the storage systems use SerializedScriptValue to
persist structured-clonable objects (
http://www.w3.org/TR/html5/common-dom-interfaces.html#safe-passing-of-structured-data)
- most of this is implemented in a V8 or JSC-specific implementation of
SerializedScriptValue.
I'm adding tests for the actual values stored with SerializedScriptValue so
that we can move forward with serialization changes without breaking
backwards compatibility.
So many of my js tests boil down to:
testSerialization({}, [0x01ff, 0x003f, 0x7b6f, 0x]);
Which makes sure that these two representations are equivalent by going in
both directions.
The issue I'm hitting is that JSC has a different implementation with a
different storage format, and the serialization/deserialization between the
two storage formats is not compatible - the above code works great on V8
but JSC uses different bytes.
I can't address this with just expectations files (i.e. only check that {}
serializes to some byte array, and have different expectations depending on
the port) because I need to check that specific inputs (such as old
V8-based formats) can also deserialize back into the right native objects.
What I kind of want is something like:
#ifdef JSC
script src=serialized_script_tests_jsc.js /script
#endif
#ifdef V8
script src=serialized_script_tests_v8.js /script
#endif
Thoughts?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] platform-specific differences in test case inputs
This is an interesting case because it's important for the
serialization format to be consistent across time (so that an
IndexedDB created at one point in time can work at another point in
time), but it's not important to be consistent across embedders
(because IndexedDB created by Safari don't need to be readable by
Chrome and vice versa).
Perhaps we shouldn't use LayoutTests to test this functionality.
Instead, it might make more sense to use API-level tests that check
that a particular embedder API is stable and working as expected.
Adam
On Tue, Sep 18, 2012 at 12:19 PM, Alec Flett alecfl...@chromium.org wrote:
Background: some of the storage systems use SerializedScriptValue to persist
structured-clonable objects
(http://www.w3.org/TR/html5/common-dom-interfaces.html#safe-passing-of-structured-data)
- most of this is implemented in a V8 or JSC-specific implementation of
SerializedScriptValue.
I'm adding tests for the actual values stored with SerializedScriptValue so
that we can move forward with serialization changes without breaking
backwards compatibility.
So many of my js tests boil down to:
testSerialization({}, [0x01ff, 0x003f, 0x7b6f, 0x]);
Which makes sure that these two representations are equivalent by going in
both directions.
The issue I'm hitting is that JSC has a different implementation with a
different storage format, and the serialization/deserialization between the
two storage formats is not compatible - the above code works great on V8 but
JSC uses different bytes.
I can't address this with just expectations files (i.e. only check that {}
serializes to some byte array, and have different expectations depending on
the port) because I need to check that specific inputs (such as old V8-based
formats) can also deserialize back into the right native objects.
What I kind of want is something like:
#ifdef JSC
script src=serialized_script_tests_jsc.js /script
#endif
#ifdef V8
script src=serialized_script_tests_v8.js /script
#endif
Thoughts?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] platform-specific differences in test case inputs
JSC's SerializedScriptValue has always been versioned (having learned the
horror of no versioning with localStorage :( )
Newer formats (obviously) can't be read by older clients, but the serialisation
is intentionally forwards compatible.
--Oliver
On Sep 18, 2012, at 12:36 PM, Adam Barth aba...@webkit.org wrote:
This is an interesting case because it's important for the
serialization format to be consistent across time (so that an
IndexedDB created at one point in time can work at another point in
time), but it's not important to be consistent across embedders
(because IndexedDB created by Safari don't need to be readable by
Chrome and vice versa).
Perhaps we shouldn't use LayoutTests to test this functionality.
Instead, it might make more sense to use API-level tests that check
that a particular embedder API is stable and working as expected.
Adam
On Tue, Sep 18, 2012 at 12:19 PM, Alec Flett alecfl...@chromium.org wrote:
Background: some of the storage systems use SerializedScriptValue to persist
structured-clonable objects
(http://www.w3.org/TR/html5/common-dom-interfaces.html#safe-passing-of-structured-data)
- most of this is implemented in a V8 or JSC-specific implementation of
SerializedScriptValue.
I'm adding tests for the actual values stored with SerializedScriptValue so
that we can move forward with serialization changes without breaking
backwards compatibility.
So many of my js tests boil down to:
testSerialization({}, [0x01ff, 0x003f, 0x7b6f, 0x]);
Which makes sure that these two representations are equivalent by going in
both directions.
The issue I'm hitting is that JSC has a different implementation with a
different storage format, and the serialization/deserialization between the
two storage formats is not compatible - the above code works great on V8 but
JSC uses different bytes.
I can't address this with just expectations files (i.e. only check that {}
serializes to some byte array, and have different expectations depending on
the port) because I need to check that specific inputs (such as old V8-based
formats) can also deserialize back into the right native objects.
What I kind of want is something like:
#ifdef JSC
script src=serialized_script_tests_jsc.js /script
#endif
#ifdef V8
script src=serialized_script_tests_v8.js /script
#endif
Thoughts?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] platform-specific differences in test case inputs
What exactly are you trying to test here? The internal serialisation format
isn't exposed anywhere (nor should it be).
By definition newer formats won't be backwards compatible, or are you trying to
ensure that newer deserialisers will be able to continue to deserialise old
content?
--Oliver
On Sep 18, 2012, at 12:19 PM, Alec Flett alecfl...@chromium.org wrote:
Background: some of the storage systems use SerializedScriptValue to persist
structured-clonable objects
(http://www.w3.org/TR/html5/common-dom-interfaces.html#safe-passing-of-structured-data)
- most of this is implemented in a V8 or JSC-specific implementation of
SerializedScriptValue.
I'm adding tests for the actual values stored with SerializedScriptValue so
that we can move forward with serialization changes without breaking
backwards compatibility.
So many of my js tests boil down to:
testSerialization({}, [0x01ff, 0x003f, 0x7b6f, 0x]);
Which makes sure that these two representations are equivalent by going in
both directions.
The issue I'm hitting is that JSC has a different implementation with a
different storage format, and the serialization/deserialization between the
two storage formats is not compatible - the above code works great on V8 but
JSC uses different bytes.
I can't address this with just expectations files (i.e. only check that {}
serializes to some byte array, and have different expectations depending on
the port) because I need to check that specific inputs (such as old V8-based
formats) can also deserialize back into the right native objects.
What I kind of want is something like:
#ifdef JSC
script src=serialized_script_tests_jsc.js /script
#endif
#ifdef V8
script src=serialized_script_tests_v8.js /script
#endif
Thoughts?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] platform-specific differences in test case inputs
Where do you test that property?
Adam
On Tue, Sep 18, 2012 at 12:43 PM, Oliver Hunt oli...@apple.com wrote:
JSC's SerializedScriptValue has always been versioned (having learned the
horror of no versioning with localStorage :( )
Newer formats (obviously) can't be read by older clients, but the
serialisation is intentionally forwards compatible.
--Oliver
On Sep 18, 2012, at 12:36 PM, Adam Barth aba...@webkit.org wrote:
This is an interesting case because it's important for the
serialization format to be consistent across time (so that an
IndexedDB created at one point in time can work at another point in
time), but it's not important to be consistent across embedders
(because IndexedDB created by Safari don't need to be readable by
Chrome and vice versa).
Perhaps we shouldn't use LayoutTests to test this functionality.
Instead, it might make more sense to use API-level tests that check
that a particular embedder API is stable and working as expected.
Adam
On Tue, Sep 18, 2012 at 12:19 PM, Alec Flett alecfl...@chromium.org wrote:
Background: some of the storage systems use SerializedScriptValue to persist
structured-clonable objects
(http://www.w3.org/TR/html5/common-dom-interfaces.html#safe-passing-of-structured-data)
- most of this is implemented in a V8 or JSC-specific implementation of
SerializedScriptValue.
I'm adding tests for the actual values stored with SerializedScriptValue so
that we can move forward with serialization changes without breaking
backwards compatibility.
So many of my js tests boil down to:
testSerialization({}, [0x01ff, 0x003f, 0x7b6f, 0x]);
Which makes sure that these two representations are equivalent by going in
both directions.
The issue I'm hitting is that JSC has a different implementation with a
different storage format, and the serialization/deserialization between the
two storage formats is not compatible - the above code works great on V8 but
JSC uses different bytes.
I can't address this with just expectations files (i.e. only check that {}
serializes to some byte array, and have different expectations depending on
the port) because I need to check that specific inputs (such as old V8-based
formats) can also deserialize back into the right native objects.
What I kind of want is something like:
#ifdef JSC
script src=serialized_script_tests_jsc.js /script
#endif
#ifdef V8
script src=serialized_script_tests_v8.js /script
#endif
Thoughts?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] platform-specific differences in test case inputs
Sorry I totally left out the I expose this through Internals - and adam has explained the rationale On Tue, Sep 18, 2012 at 12:46 PM, Oliver Hunt oli...@apple.com wrote: What exactly are you trying to test here? The internal serialisation format isn't exposed anywhere (nor should it be). By definition newer formats won't be backwards compatible, or are you trying to ensure that newer deserialisers will be able to continue to deserialise old content? exactly. Where does JSC test this? I'm happy to follow whatever pattern is already established. Alec ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
