Binary/F Unit Testing
Kris Kowal
anyone's interested in helping get this ball rolling:
Kris Kowal
Ondřej Žára
I just started a project for a compliance test for Binary/F if
anyone's interested in helping get this ball rolling:
http://gist.github.com/310702
I am thinking about commencing an implementation of B/F. However, I will be facing the "two-different-binary-modules" case. Do we have some recommended way to distinguish between these? B/F unit test requires "binary"; may I suggest renaming that to require("binary/f")? Or, because of the exported class name, require("buffer")?
O.
Kris Kowal
--
You received this message because you are subscribed to the Google Groups "CommonJS" group.
To post to this group, send email to comm...@googlegroups.com.
To unsubscribe from this group, send email to commonjs+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/commonjs?hl=en.
Kris Kowal
> I am thinking about commencing an implementation of B/F. However, I will be
> facing the "two-different-binary-modules" case. Do we have some recommended
> way to distinguish between these? B/F unit test requires "binary"; may I
> suggest renaming that to require("binary/f")? Or, because of the exported
> class name, require("buffer")?
I think it's best to stick with just "binary". I would like to back
off Binary/B personally; or at least be at liberty to incorporate some
of the spec bug fixes that came out in later proposals. In any case,
I think you'll find that it's mostly possible to implement Binary/B in
terms of Binary/F. You might implement "Buffer" in something like
"binary/buffer" and then re-export it from your "binary" module.
Kris Kowal
Wes Garland
Ondras -- I am considering an impl. as well. My current impulse is to have modules "binaryb" and "binaryf", then alias binaryf to binary if I need to.
Although, that said, that means I will need to fix real, live production code.
Kris, what do you think about coming up with a naming scheme for specs like binaryb, binaryf, etc while they are in their early stages, then having a well-known alias for the "winner" when it emerges? That way we can write future-proof JS code today. I currently deploy CommonJS applications to multiple production platforms and some of my scripts are executed millions of times per month in a 5-nines environment. Future-proofing is a Really Big Deal.
Wes
Kris Kowal
--
You received this message because you are subscribed to the Google Groups "CommonJS" group.
To post to this group, send email to comm...@googlegroups.com.
To unsubscribe from this group, send email to commonjs+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/commonjs?hl=en.
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
Christoph Dorn
> Kris, what do you think about coming up with a naming scheme for specs
> like binaryb, binaryf, etc while they are in their early stages, then
> having a well-known alias for the "winner" when it emerges? That way we
> can write future-proof JS code today. I currently deploy CommonJS
> applications to multiple production platforms and some of my scripts are
> executed millions of times per month in a 5-nines environment.
> Future-proofing is a Really Big Deal.
+1
Christoph
Kris Kowal
> Kris, what do you think about coming up with a naming scheme for specs like
> binaryb, binaryf, etc while they are in their early stages, then having a
> well-known alias for the "winner" when it emerges? That way we can write
> future-proof JS code today. I currently deploy CommonJS applications to
> multiple production platforms and some of my scripts are executed millions
> of times per month in a 5-nines environment. Future-proofing is a Really
> Big Deal.
I think it'd be fine; perhaps we should go through and rework the
proposals to each provide their own provisional "binary-lower-case"
module name, "binary-b", "binary-lite", "binary-f".
Kris Kowal
Ondřej Žára
Ondřej Žára
1) I believe that #112 should expect "1" as a correct value,
2) it turned out that V8 does not consider "-1" a valid numeric index, so I am unable to intercept buffer[-1] with standard indexedproperty handler and it is therefore impossible to throw in this situation. Is it possible to weaken this requirement in a way that accessing such index (as well as index outside of buffer size) returns undefined (I believe JS arrays work the same way...) ?
Thanks,
Ondrej
Wes Garland
Wes
Ondřej Žára
Ondrej, can you intercept -1 with a generic property accessor? i.e. pretend it is index["-1"] instead of index[-1]. I bet that would work!
Yes, I guess that would work. On the other hand, why should:
var anyProp = "-1";
buffer[anyProp];
throw an exception? And for which values of anyProp? All? That sounds a bit crazy to me...
O.
Kris Kowal
> Yes, I guess that would work. On the other hand, why should:
>
> var anyProp = "-1";
> buffer[anyProp];
>
> throw an exception? And for which values of anyProp? All? That sounds a bit
> crazy to me...
To cause an early error so the bug doesn't lay hidden until it's hard to trace.
Kris Kowal
Kris Kowal
> 1) I believe that #112 should expect "1" as a correct value,
Yes. I've added the tests to my fork of the commonjs repo:
http://github.com/kriskowal/commonjs/commit/f30bc7e7268c0574432f4d5f825ec787474a5804
> 2) it turned out that V8 does not consider "-1" a valid numeric index, so I
> am unable to intercept buffer[-1] with standard indexedproperty handler and
> it is therefore impossible to throw in this situation. Is it possible to
> weaken this requirement in a way that accessing such index (as well as index
> outside of buffer size) returns undefined (I believe JS arrays work the same
> way...) ?
We could. It might not be possible to intercept it in V8 either.
Kris Kowal
Ondřej Žára
Are we still completely in sync on this one? The case which confuses me (and which seems to be perfectly OK for you) is:
var x = buffer.mOnKeYs; // throws!
O.
Kris Kowal
> 2010/2/24 Kris Kowal <cowber...@gmail.com>
> Are we still completely in sync on this one? The case which confuses me (and
> which seems to be perfectly OK for you) is:
>
> var x = buffer.mOnKeYs; // throws!
Ah, I see. What's the proposed verbiage? Is this possible:
buffer[-1] // throws
buffer["-1"] // does not throw
buffer["monkey"]() // does not throw
buffer.monkey // does not throw
Kris Kowal
Ondřej Žára
On Wed, Feb 24, 2010 at 11:07 AM, Ondřej Žára <ondre...@gmail.com> wrote:
> 2010/2/24 Kris Kowal <cowber...@gmail.com>
> Are we still completely in sync on this one? The case which confuses me (andAh, I see. What's the proposed verbiage? Is this possible:
> which seems to be perfectly OK for you) is:
>
> var x = buffer.mOnKeYs; // throws!
buffer[-1] // throws
buffer["-1"] // does not throw
I am not sure if these two are distinguishable in V8. Will perform some experiments tomorrow.
O.
buffer["monkey"]() // does not throw
buffer.monkey // does not throw
Kris Kowal
Wes Garland
> buffer[-1] // throws
> buffer["-1"] // does not throw
Wes
Kris Kowal
--
You received this message because you are subscribed to the Google Groups "CommonJS" group.
To post to this group, send email to comm...@googlegroups.com.
To unsubscribe from this group, send email to commonjs+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/commonjs?hl=en.
Kris Kowal
> It's probably possible in spidermonkey by examining the un-coerced type of
> the idval passed to the resolveop or class getter. But I really, really,
> really, really think that doing so would be a mistake. JavaScript just
> doesn't behave like that.
Although that changes in strict mode. However, given that we're not
talking about strict mode, I'm willing to consider continuing in
JavaScript's tradition of silent errors.
Here's the proposed verbiage:
; <nowiki>[[Get]]</nowiki> Any
# If the index is a Number, returns the byte at the given offset.
# If there index is beyond the bounds of the Buffer, returns "undefined".
# If the property name is a non-numeric String, returns the
corresponding property.
# If no property exists for a non-numeric String, returns "undefined"
# ''Note: the behavior of a numeric string is not defined by this
specification.''
; <nowiki>[[Put]]</nowiki> Number
# If the index is a Number,
## coerces the value to a Number,
## masks it with 0xFF,
## sets the value for the given offset
## returns the value
# ''Note: the behavior of setting a value to a Number index beyond the
bounds of the buffer is not defined by this specification.''
# ''Note: the behavior of setting a value for a numeric String is not
defined by this specification.''
Kris Kowal
Wes Garland
## coerces the value to a Number,
## masks it with 0xFF,
## sets the value for the given offset
That doesn't make sense to me. 2^53 is a more realistic limit, although I could be talked into 2^31.
Wes
Kris Kowal
--
You received this message because you are subscribed to the Google Groups "CommonJS" group.
To post to this group, send email to comm...@googlegroups.com.
To unsubscribe from this group, send email to commonjs+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/commonjs?hl=en.
Wes Garland
Kris Kowal
> # If the index is a Number,
> ## coerces the value to a Number,
> ## masks it with 0xFF,
> ## sets the value for the given offset
>
> You are limiting buffers to 255 bytes?
The mask applies to the value, not the offset.
Kris Kowal
Wes Garland
Thanks
Wes
Ondřej Žára
On Wed, Feb 24, 2010 at 11:38 AM, Wes Garland <w...@page.ca> wrote:Although that changes in strict mode. However, given that we're not
> It's probably possible in spidermonkey by examining the un-coerced type of
> the idval passed to the resolveop or class getter. But I really, really,
> really, really think that doing so would be a mistake. JavaScript just
> doesn't behave like that.
talking about strict mode, I'm willing to consider continuing in
JavaScript's tradition of silent errors.
Here's the proposed verbiage:
Maybe a shortened version "[[Get]] behaves exactly like it does with Array. [[Put]] does nothing for indexes out of range" ?
O.
; <nowiki>[[Get]]</nowiki> Any
# If the index is a Number, returns the byte at the given offset.
# If there index is beyond the bounds of the Buffer, returns "undefined".
# If the property name is a non-numeric String, returns the
corresponding property.
# If no property exists for a non-numeric String, returns "undefined"
# ''Note: the behavior of a numeric string is not defined by this
specification.''
; <nowiki>[[Put]]</nowiki> Number
# If the index is a Number,
## coerces the value to a Number,
## masks it with 0xFF,
## sets the value for the given offset
## returns the value
# ''Note: the behavior of setting a value to a Number index beyond the
bounds of the buffer is not defined by this specification.''
# ''Note: the behavior of setting a value for a numeric String is not
defined by this specification.''
Kris Kowal
Kris Kowal
> Maybe a shortened version "[[Get]] behaves exactly like it does with Array.
> [[Put]] does nothing for indexes out of range" ?
This would welcome a great deal of interpretation, which makes it
harder to write unit tests that we agree correspond to the
specification, but I'm fine with the generalization. Anyone else mind
the broadness of these statements? One interesting facet of
generalizing this is that the semantics change when strict-mode lands,
and we would be well within our rights to write unit tests that verify
equivalent behavior both strict and free. We'll also have to write
our unit tests using arrays as an oracle.
Kris Kowal
Ondřej Žára
Actually, I do not want to stay in a rebellious position, throwing away stricter proposals and shouting for unlimited flexibility. It just occured to me that - as far as I know - there is no object in JS world which throws an exception *any time* some of its properties (not defined before) is accessed. From this point of view, the proposed buffer would behave like an alien cactus :)
On the other hand, I am totally unfamiliar with recent/future standardization efforts, so it might happen that a behavior similar to this is where JS is heading...
O.
Wes Garland
This would welcome a great deal of interpretation, which makes it
harder to write unit tests that we agree correspond to the
specification
Wes
Kris Kowal
>> This would welcome a great deal of interpretation, which makes it
>> harder to write unit tests that we agree correspond to the
>> specification
>
> You could always effect the same behaviour against an Array and observe if
> Buffer matches said behaviour.
That's what I mean by using Array instances as an oracle; but the
question remains, which behaviors to test. Is everyone here okay with
a bit of ambiguity? I don't mind.
Kris Kowal