Binary/B Extension Proposals and Implementation Notes

12 views
Skip to first unread message

Aristid Breitkreuz

unread,
May 24, 2009, 11:20:13 AM5/24/09
to serv...@googlegroups.com
Hi,

In the last few days, I've busily implemented Binary/B for Flusspferd
(http://flusspferd.org/). AFAIR, the only missing parts are everything
involving charsets (Encoding module needed).

So, I would propose the following extensions that I've already implemented:

On both ByteString and ByteArray, as in the spec on ByteString:

* indexOf
* lastIndefOf
* byteAt
* split

On ByteArray, as described in DMO* for Array:

* filter
* forEach
* every
* some
* map (extension: allows you to return an Array/ByteArray/ByteString in
addition to numbers in the callback, with the effect that the returned
ByteArray might have a different length)
* reduce
* reduceRight

On ByteArray:

* append [like push, but also allows Array/ByteArray/ByteString in
addition to numbers]
* prepend [like unshift, but also allows Array/ByteArray/ByteString in
addition to numbers]
* erase(begin[, end) [like slice, but deleting, returns length]
* replace(begin, end, values/ByteStrings/ByteArrays/Arrays...) [begin,
end like slice, returns length]
* insert(position, values/ByteStrings/ByteArrays/Arrays...)
* count [like every/some, but returns the total count]

A few notes about split:

* The returned values have the property "delimiter" set to true/false,
if it is a delimiter. (Possibly interesting when you use
includeDelimiter...)
* The delimiters returned when includeDelimiter is specified, are not
counted with regard to the count parameter.


Thank you!

Aristid


*) https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference

Kris Kowal

unread,
May 24, 2009, 3:53:04 PM5/24/09
to serv...@googlegroups.com
On Sun, May 24, 2009 at 8:20 AM, Aristid Breitkreuz
<aristid.b...@gmx.de> wrote:
> On both ByteString and ByteArray, as in the spec on ByteString:
>
> * indexOf
> * lastIndefOf
> * byteAt
> * split

Sure, most of these are lucid. Can you describe the behavior of "split"?

> On ByteArray, as described in DMO* for Array:
>
> * filter
> * forEach
> * every
> * some
> * map (extension: allows you to return an Array/ByteArray/ByteString in
> addition to numbers in the callback, with the effect that the returned
> ByteArray might have a different length)
> * reduce
> * reduceRight

Sounds good. I can see why the map extension would be useful,
although I'm generally reluctant to create such "type" special cases.
I say "ok" for now, but I think we should look for an alternate idiom.

> On ByteArray:
>
> * append [like push, but also allows Array/ByteArray/ByteString in
> addition to numbers]

The append idiom is push.apply().

> * prepend [like unshift, but also allows Array/ByteArray/ByteString in
> addition to numbers]

.unshift.apply()

> * erase(begin[, end) [like slice, but deleting, returns length]

.length = 0

> * replace(begin, end, values/ByteStrings/ByteArrays/Arrays...) [begin,
> end like slice, returns length]

.splice(begin, end, replacement) -> replaced (with its .length)

> * insert(position, values/ByteStrings/ByteArrays/Arrays...)
> * count [like every/some, but returns the total count]

.splice(at, at, replacement) -> replaced

> A few notes about split:
>
> * The returned values have the property "delimiter" set to true/false,
> if it is a delimiter. (Possibly interesting when you use
> includeDelimiter...)
> * The delimiters returned when includeDelimiter is specified, are not
> counted with regard to the count parameter.

I'm not a fan of providing or consuming hidden state on primitive
objects; I think it'll lead to difficult bugs.

Thanks for the ideas; the points that receive no objections in the
next day or so I think you should add to the wiki.

Kris Kowal

Aristid Breitkreuz

unread,
May 24, 2009, 6:20:29 PM5/24/09
to serverjs
On 24 Mai, 21:53, Kris Kowal <cowbertvon...@gmail.com> wrote:
> On Sun, May 24, 2009 at 8:20 AM, Aristid Breitkreuz
>
> <aristid.breitkr...@gmx.de> wrote:
> > On both ByteString and ByteArray, as in the spec on ByteString:
>
> > * indexOf
> > * lastIndefOf
> > * byteAt
> > * split
>
> Sure, most of these are lucid.  Can you describe the behavior of "split"?

The behaviour of split, well, that's caused some confusion, so it
probably does need some clarification. In any case, my implementation
can be found here: http://tinyurl.com/binarysplit

Synopsis:

binaryObject.split(delimiters[, options])
options = { [includeDelimiter: Boolean], [count: Number] }

Description:

If no options are specified, "split" splits the Binary "binaryObject"
along _any_ of the arbitrary-size delimiters specified by
"delimiters". It returns an array of ByteStrings / ByteArrays (the
same type as "binaryObject").

The parameter "delimiters" is either
(1) an array, in which case it is interpreted as an array of "Binary-
alikes", i.e. Numbers (0-255), Arrays of Bytes, ByteStrings or
ByteArrays;
(2) a Number (0-255), which is interpreted as the single one-byte
delimiter;
(3) a ByteString or ByteArray, which is interpreted as the single
arbitrary-size delimiter.

If any delimiter has size zero, implementation behaviour is
unspecified, I'd say. Flusspferd currently silently ignores such
delimiters.

There has to be at least one delimiter.

The options change the behaviour in the following ways:

(1) If includeDelimiter is set to 'true', delimiters will be included
in the returned Arrays.
(2) If count is set to any defined, non-'null' value, it will be
interpreted as an integer describing the maximum number of returned
(non-delimiter) elements. The last returned element will contain all
bytes to the rest of the input Binary, even if they contain
delimiters.

For each returned array element, there will be property "delimiter"
set to true/false, depending on whether it is a delimiter. In order
not to introduce hidden state, I would recommend that the returned
elements NOT be identical to the input delimiters.

Even if we should scrap this, there SHOULD be a way of indicating that
an element was a delimiter or not. Because I really think this can
simplify a lot of algorithms.

>
> > On ByteArray, as described in DMO* for Array:
>
> > * filter
> > * forEach
> > * every
> > * some
> > * map (extension: allows you to return an Array/ByteArray/ByteString in
> > addition to numbers in the callback, with the effect that the returned
> > ByteArray might have a different length)
> > * reduce
> > * reduceRight
>
> Sounds good.  I can see why the map extension would be useful,
> although I'm generally reluctant to create such "type" special cases.
> I say "ok" for now, but I think we should look for an alternate idiom.

Well, I'd be happy not to standardise the extension. I'm indifferent
about that, it just turned out to be easy to implement and I thought
it could prove useful... :-)

>
> > On ByteArray:
>
> > * append [like push, but also allows Array/ByteArray/ByteString in
> > addition to numbers]
>
> The append idiom is push.apply().

For one thing, I do not think we need to repeat all mistakes of
Javascript's core functions, because Array.prototype.push.apply(array,
[...]) is one _ugly_ way of appending elements to an array; the other
thing is that append is significantly more flexible and more
performant - it natively supports ByteStrings / ByteArrays. In fact
I'm not sure if push.apply would even _work_ on all implementations.

>
> > * prepend [like unshift, but also allows Array/ByteArray/ByteString in
> > addition to numbers]
>
> .unshift.apply()

See above.

>
> > * erase(begin[, end) [like slice, but deleting, returns length]
>
> .length = 0

Does not allow removing only a few elements. You will answer "splice",
but see below.

>
> > * replace(begin, end, values/ByteStrings/ByteArrays/Arrays...) [begin,
> > end like slice, returns length]
>
> .splice(begin, end, replacement) -> replaced (with its .length)

I think creating a Binary just to be thrown away is a waste of
resources.

>
> > * insert(position, values/ByteStrings/ByteArrays/Arrays...)
> > * count [like every/some, but returns the total count]
>
> .splice(at, at, replacement) -> replaced

Waste of resources, see above.

>
> > A few notes about split:
>
> > * The returned values have the property "delimiter" set to true/false,
> > if it is a delimiter. (Possibly interesting when you use
> > includeDelimiter...)
> > * The delimiters returned when includeDelimiter is specified, are not
> > counted with regard to the count parameter.
>
> I'm not a fan of providing or consuming hidden state on primitive
> objects; I think it'll lead to difficult bugs.

In my implementation that's actually no problem because all returned
elements, including the delimiters, are freshly created. So there is
no state involved at all.

But I'm open for other proposals for signalling that an element is a
delimiter and not a non-delimiter element.

>
> Thanks for the ideas; the points that receive no objections in the
> next day or so I think you should add to the wiki.

Sure.

Kris Kowal

unread,
May 24, 2009, 7:23:22 PM5/24/09
to serv...@googlegroups.com
On Sun, May 24, 2009 at 3:20 PM, Aristid Breitkreuz
<aristid.b...@gmx.de> wrote:
> For one thing, I do not think we need to repeat all mistakes of
> Javascript's core functions, because Array.prototype.push.apply(array,
> [...]) is one _ugly_ way of appending elements to an array; the other
> thing is that append is significantly more flexible and more
> performant - it natively supports ByteStrings / ByteArrays. In fact
> I'm not sure if push.apply would even _work_ on all implementations.

Yeah, there is the misfortune that it may not be possible for binary
types to be array-like on some platforms.

> In my implementation that's actually no problem because all returned
> elements, including the delimiters, are freshly created. So there is
> no state involved at all.

I'm not anticipating shared state or GC bugs, but rather methods
behaving differently depending on delimiter state carried around but
not shown. Perhaps this could be addressed by showing the attached
delimiter in toString() and toSource(). That being said, an attached
delimiter is not a concern I would like to have when working with a
ByteString or ByteArray. Though, I'll confess that I don't have a
clear idea about what this is used for and how.

> I think creating a Binary just to be thrown away is a waste of
> resources.

Given your arguments about wasteful allocation and not repeating the
mistakes of JavaScript past, I'll buy:
* erase(begin, end)

I think that "replace" should be subsumed by "erase(begin, end,
replacement)" since "replace" has a different meaning for Strings.
"append" is Python's word for "push", so I think we might consider a
different name like "extend", which is Python's word for what you've
described. "prepend" hasn't had the fortune of making it into the
English dictionary yet, but it certainly would be the opposite of
"append", therefore a synonym for "unshift", so I think we should
consider the opposite of "extend" or a pair of opposite words like
"extendLeft" and "extendRight".

And I've already bought without argument:
* ByteArray().indexOf() :Number
* ByteArray().lastIndexOf() :Number
* ByteArray().byteAt()
* ByteArray().forEach(block, [context])
* ByteArray().map(block, [context]) :Array
* ByteArray().reduce(block, [context]) :Number
* ByteArray().reduceRight(block, [context]) :Number

I put ByteArray().byteAt() on the Wiki some time ago, but realized I
hadn't explicated the return type. I'm proposing ByteString for both
ByteArray and ByteString. I also support cross implementing charAt as
an alias on both types.

I'm abstaining on the issue of split, join, delimiters, and the map
extension for lack of expertise, but I hope someone will want discuss
the issues further.

Would you mind adding a link to this discussion to the wiki?

Kris Kowal

Aristid Breitkreuz

unread,
May 25, 2009, 4:41:12 AM5/25/09
to serverjs
On 25 Mai, 01:23, Kris Kowal <cowbertvon...@gmail.com> wrote:
> On Sun, May 24, 2009 at 3:20 PM, Aristid Breitkreuz <aristid.breitkr...@gmx.de> wrote:
> > [...]
>
> [...]
>
> > In my implementation that's actually no problem because all returned
> > elements, including the delimiters, are freshly created. So there is
> > no state involved at all.
>
> I'm not anticipating shared state or GC bugs, but rather methods
> behaving differently depending on delimiter state carried around but
> not shown.  Perhaps this could be addressed by showing the attached
> delimiter in toString() and toSource().  That being said, an attached
> delimiter is not a concern I would like to have when working with a
> ByteString or ByteArray.  Though, I'll confess that I don't have a
> clear idea about what this is used for and how.

There is no such thing as an "attached delimiter". Delimiters are
included in the result _only_ if the includeDelimiter option is set.
Example:

ByteString([1,2,3,4,5]).split(3, {includeDelimiter: true}) returns
[ByteString([1,2]), ByteString([3]), ByteString([4, 5])]

But to make clear that the second element (ByteString([3])) is a
delimiter, it has a (plain) Javascript property "delimiter" set to
Boolean true.

>
> > I think creating a Binary just to be thrown away is a waste of
> > resources.
>
> Given your arguments about wasteful allocation and not repeating the
> mistakes of JavaScript past, I'll buy:
>  * erase(begin, end)
>
> I think that "replace" should be subsumed by "erase(begin, end,
> replacement)" since "replace" has a different meaning for Strings.

How about "displace"? Just found that word in the dictionary and I
think it would make sense. :-)

http://www.wordreference.com/definition/displace

Or maybe another word that is not erase, because using erase to add
elements seems confusing to me.

> "append" is Python's word for "push", so I think we might consider a
> different name like "extend", which is Python's word for what you've
> described.  "prepend" hasn't had the fortune of making it into the
> English dictionary yet, but it certainly would be the opposite of
> "append", therefore a synonym for "unshift", so I think we should
> consider the opposite of "extend" or a pair of opposite words like
> "extendLeft" and "extendRight".

I'd be fine with "extendLeft" and "extendRight".

>
> And I've already bought without argument:
>  * ByteArray().indexOf() :Number
>  * ByteArray().lastIndexOf() :Number
>  * ByteArray().byteAt()
>  * ByteArray().forEach(block, [context])
>  * ByteArray().map(block, [context]) :Array
>  * ByteArray().reduce(block, [context]) :Number
>  * ByteArray().reduceRight(block, [context]) :Number
>
> I put ByteArray().byteAt() on the Wiki some time ago, but realized I
> hadn't explicated the return type.  I'm proposing ByteString for both
> ByteArray and ByteString.  I also support cross implementing charAt as
> an alias on both types.

charAt on both? What would it do on ByteArray? Return a ByteString? Or
a ByteArray?

If we add charAt, we should go further and add substr and substring to
ByteArray (they should return ByteString).

>
> I'm abstaining on the issue of split, join, delimiters, and the map
> extension for lack of expertise, but I hope someone will want discuss
> the issues further.
>
> Would you mind adding a link to this discussion to the wiki?

Done already.

There are some methods that you've neither accepted nor criticised,
what about them? :-) (Specifically: "every", "some", "count" and maybe
others. Both "every" and "some" are in JS 1.6, "count" was added by
me.)

>
> Kris Kowal

Kris Kowal

unread,
May 25, 2009, 4:56:11 AM5/25/09
to serv...@googlegroups.com
>
> There are some methods that you've neither accepted nor criticised,
> what about them? :-) (Specifically: "every", "some", "count" and maybe
> others. Both "every" and "some" are in JS 1.6, "count" was added by
> me.)

Oh, I think that all the ones in the latest ES spec for Array should
be added to ByteArray for sure. How does count() differ from .length?

Kris Kowal

Daniel Friesen

unread,
May 25, 2009, 5:02:31 AM5/25/09
to serv...@googlegroups.com
If you look at my Blob spec[1] for MonkeyScript you'll notice I have
{integer|float|string}At() if you look at the sources[2] you'll notice I
actually commented out a charAt which I originally had in the spec.
charAt implies single byte, and with encoding I thought and thought, and
ended up deciding it was better to omit charAt from the Blob.
As for making charAt an alias for byteAt, I think that's a bad idea.
charAt is named charAt for a reason, same for substr and substring, I
find an API that would return Binary data from methods which say char
(character) and str(ing) to be confusing and ugly.

[1]: http://draft.monkeyscript.org/api/_std/Blob.html
[2]: http://draft.monkeyscript.org/git/api/Blob.txt


>> I'm abstaining on the issue of split, join, delimiters, and the map
>> extension for lack of expertise, but I hope someone will want discuss
>> the issues further.
>>
>> Would you mind adding a link to this discussion to the wiki?
>>
>
> Done already.
>
> There are some methods that you've neither accepted nor criticised,
> what about them? :-) (Specifically: "every", "some", "count" and maybe
> others. Both "every" and "some" are in JS 1.6, "count" was added by
> me.)
>
>
>> Kris Kowal
>>

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

Kris Kowal

unread,
May 25, 2009, 5:08:58 AM5/25/09
to serv...@googlegroups.com
On Mon, May 25, 2009 at 1:41 AM, Aristid Breitkreuz
<aristid.b...@gmx.de> wrote:
> There is no such thing as an "attached delimiter". Delimiters are
> included in the result _only_ if the includeDelimiter option is set.
> Example:
>
> ByteString([1,2,3,4,5]).split(3, {includeDelimiter: true}) returns
> [ByteString([1,2]), ByteString([3]), ByteString([4, 5])]
>
> But to make clear that the second element (ByteString([3])) is a
> delimiter, it has a (plain) Javascript property "delimiter" set to
> Boolean true.

Okay, I see. Would it not be implicit that every other element of the
returned Array is a delimiter? Even if there were two adjacent
delimiters, would we not interpolate a ByteString([]) between them?
If that's the case, I don't think the delimiter flag would be useful
(apart from a very small convenience), and even then it's likely to be
an inconvenience as once that ByteString is given to someone else, the
.delimiter flag would be noise.

Sorry for being obtuse on this one; there's no precedent for a split
routine that includes delimiters. I just think that someone else
should vouch support for it before it gets in.

> How about "displace"? Just found that word in the dictionary and I
> think it would make sense. :-)

Yeah, that'd do fine, even though there's certainly no precedent.
Let's run with it.

>
> I'd be fine with "extendLeft" and "extendRight".
>

Let's put it on the books 'til someone objects.

> charAt on both? What would it do on ByteArray? Return a ByteString? Or
> a ByteArray?

Well, if byteAt is on ByteArray to be orthogonal with ByteString, it
stands to reason that charAt, being equivalent, should be on ByteArray
as well. That's a slippery slope though; I'm sure we could make a
case for having mutual support for each other's interfaces on
ByteArray and ByteString. That muddies the distinction between them
though. Being as ByteArray is for buffers and ByteString is for most
everything else, I don't think we need to cross implement too much. I
am certain that byteAt() should always return a ByteString() no matter
which type it's attached to. If you're thinking that there needs to
be a method that returns the number at a given offset in the
ByteArray, I agree, and think it should have a different name, like
numberAt, or 'get'.

Kris Kowal

Kris Kowal

unread,
May 25, 2009, 5:15:25 AM5/25/09
to serv...@googlegroups.com
On Mon, May 25, 2009 at 2:02 AM, Daniel Friesen
<nadir.s...@gmail.com> wrote:
> If you look at my Blob spec[1] for MonkeyScript you'll notice I have
> {integer|float|string}At() if you look at the sources[2] you'll notice I
> actually commented out a charAt which I originally had in the spec.
> charAt implies single byte, and with encoding I thought and thought, and
> ended up deciding it was better to omit charAt from the Blob.
> As for making charAt an alias for byteAt, I think that's a bad idea.
> charAt is named charAt for a reason, same for substr and substring, I
> find an API that would return Binary data from methods which say char
> (character) and str(ing) to be confusing and ugly.
>
> [1]: http://draft.monkeyscript.org/api/_std/Blob.html
> [2]: http://draft.monkeyscript.org/git/api/Blob.txt

integerAt, intAt, or numberAt would all be acceptable in my opinion.
You're right that charAt implies a *character* (I presume you meant
character instead of byte) and therefore possibly a multi-byte number.
That being said, that's not how it's used, which is far more the
concern for me in terms of reusability and migration. I would very
much like to be able to pass a ByteString to any generic algorithm
that would accept String.

I'm not however concerned about passing ByteArrays to String
algorithms, but Aristid is right that there needs to be some method
for getting single numbers out of the byte array.

Kris Kowal

Aristid Breitkreuz

unread,
May 25, 2009, 5:42:25 AM5/25/09
to serverjs
On 25 Mai, 11:08, Kris Kowal <cowbertvon...@gmail.com> wrote:
> On Mon, May 25, 2009 at 1:41 AM, Aristid Breitkreuz
>
> <aristid.breitkr...@gmx.de> wrote:
> > There is no such thing as an "attached delimiter". Delimiters are
> > included in the result _only_ if the includeDelimiter option is set.
> > Example:
>
> > ByteString([1,2,3,4,5]).split(3, {includeDelimiter: true}) returns
> > [ByteString([1,2]), ByteString([3]), ByteString([4, 5])]
>
> > But to make clear that the second element (ByteString([3])) is a
> > delimiter, it has a (plain) Javascript property "delimiter" set to
> > Boolean true.
>
> Okay, I see.  Would it not be implicit that every other element of the
> returned Array is a delimiter?  Even if there were two adjacent
> delimiters, would we not interpolate a ByteString([]) between them?
> If that's the case, I don't think the delimiter flag would be useful
> (apart from a very small convenience), and even then it's likely to be
> an inconvenience as once that ByteString is given to someone else, the
> .delimiter flag would be noise.

I haven't actually considered this. Yeah, the fact that every odd
element will be a delimiter is probably good enough.

>
> Sorry for being obtuse on this one; there's no precedent for a split
> routine that includes delimiters.  I just think that someone else
> should vouch support for it before it gets in.

Yes, there is. :-)

http://www.boost.org/doc/libs/1_39_0/libs/tokenizer/char_separator.htm

"The strtok() function does not include matches with the character
delimiters in the output sequence of tokens. However, sometimes it is
useful to have the delimiters show up in the output sequence,
therefore char_separator provides this as an option. We refer to
delimiters that show up as output tokens as kept delimiters and
delimiters that do now show up as output tokens as dropped
delimiters."

> [skip]
>
> > charAt on both? What would it do on ByteArray? Return a ByteString? Or
> > a ByteArray?
>
> Well, if byteAt is on ByteArray to be orthogonal with ByteString, it
> stands to reason that charAt, being equivalent, should be on ByteArray
> as well.  That's a slippery slope though; I'm sure we could make a
> case for having mutual support for each other's interfaces on
> ByteArray and ByteString.  That muddies the distinction between them
> though.  Being as ByteArray is for buffers and ByteString is for most
> everything else, I don't think we need to cross implement too much.  I
> am certain that byteAt() should always return a ByteString() no matter
> which type it's attached to.  If you're thinking that there needs to
> be a method that returns the number at a given offset in the
> ByteArray, I agree, and think it should have a different name, like
> numberAt, or 'get'.

There is: the [] operator. But having a common subset of operations
that work on both ByteArray and ByteString will probably vastly
simplify algorithms that have to accept both ByteArray and ByteString
(heck, even ServerJS requires _many_ methods to take either).

Besides, the name byteAt is wonderfully unambiguous. Nothing left
unclear, no difficulties left.

But I certainly don't need charAt on ByteArray.

Aristid Breitkreuz

unread,
May 25, 2009, 5:45:47 AM5/25/09
to serverjs
Instead of floatAt and so on, how about something like pack/unpack?

http://perldoc.perl.org/functions/pack.html
http://perldoc.perl.org/functions/unpack.html

While the syntax is a bit ... regex-like, it's a precedent, and simply
copying it is easier than cooking up an entirely own method of doing
these things.

Take a look, you can do basically _everything_ with pack/unpack.

Aristid Breitkreuz

unread,
May 25, 2009, 6:16:39 AM5/25/09
to serverjs
On 25 Mai, 11:08, Kris Kowal <cowbertvon...@gmail.com> wrote:
> [skip]
> I am certain that byteAt() should always return a ByteString() no matter
> which type it's attached to.

Oh, I always thought byteAt returns a Number. But now I see that it
does not.

>  If you're thinking that there needs to
> be a method that returns the number at a given offset in the
> ByteArray, I agree, and think it should have a different name, like
> numberAt, or 'get'.

I'd be fine with 'get', in that case.

Daniel Friesen

unread,
May 25, 2009, 6:23:37 AM5/25/09
to serv...@googlegroups.com
No, I meant byte. In the context of handling binary data, I expect that
the output has something to do with what the function name implies it's
going to be outputting, but that all the lengths are properly relevant
to the actual binary data. I'd be horrified if I told one of these
methods "Extract a size 3 string from this binary data" and instead of
pulling out 3 bytes it ate 5 bytes from my stream amounting to 3
characters leaving me with invalid data and an overflow into unrelated data.

numberAt wouldn't really work. jslibs' Pack has readInt, readReal,
though going along with other naming and what most people in JS would
expect integer and float would probably be the better names. When
reading an integer or float I expect to be able to define the size, and
in the context of an integer whether it is signed or unsigned, and
whether it's in network byte order or not. If I didn't have that kind of
control I would have utterly failed at trying to implement FastCGI in JS.

Daniel Friesen

unread,
May 25, 2009, 6:32:12 AM5/25/09
to serv...@googlegroups.com
My background is:
http://code.google.com/p/jslibs/wiki/jsstd#jsstd::Pack_class

I'm of the "both" party in this case. Preferentially, I'd say write the
necessary expressive .integerAt, .floatAt, .stringAt, ... methods, and
write pack() unpack() (Well actually in the naming scheme, perhaps
.packAt(), .unpackAt() follow the pattern better) around them.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

Aristid Breitkreuz

unread,
May 25, 2009, 7:12:07 AM5/25/09
to serv...@googlegroups.com
Kris Kowal schrieb:

In taking a predicate. ByteArray([1,2,3,4,5]).count(function(x) { return
x % 2; }) == 3. As per Javascript convention, the block gets three
parameters: element, index, array.

Wes Garland

unread,
May 25, 2009, 8:57:52 AM5/25/09
to serv...@googlegroups.com

In the last few days, I've busily implemented Binary/B for Flusspferd
(http://flusspferd.org/). AFAIR, the only missing parts are everything
involving charsets (Encoding module needed).

If your backing store is a C array of unsigned chars, then you can steal my iconv code from gpsee, if you'd like. It's nothing special but it works (as far as I've tested -- but isn't really all that far).
 
Thanks for the work fleshing out APIs, etc!

Wes

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

Donny Viszneki

unread,
May 25, 2009, 1:56:42 PM5/25/09
to serv...@googlegroups.com
On Mon, May 25, 2009 at 7:12 AM, Aristid Breitkreuz
<aristid.b...@gmx.de> wrote:
> In taking a predicate. ByteArray([1,2,3,4,5]).count(function(x) { return
> x % 2; }) == 3. As per Javascript convention, the block gets three
> parameters: element, index, array.

It's worth noting that this is exactly the kind of idiom that is
easily implemented in Javascript code "on top" of an underlying native
implementation you could probably call _NativeByteArray.


--
http://codebad.com/

Daniel Friesen

unread,
May 25, 2009, 2:18:43 PM5/25/09
to serv...@googlegroups.com
_native.ByteArray ;) ?

heh, sorry.
Treating native code as a behind the scenes thing, then wrapping a pile
of JS around is has been the zone I've been in for quite awhile.
Both Banana, and even MonkeyScript itself follow an idiom of putting
everything defined natively into a _native object variable inside local
scope where it can't be seen from outside then wrapping JS around it. In
fact _native is basically the only special thing defined when
monkeyscript.js is jumped into. Where it quickly runs an anonymous
function to enclose _native and then deletes it from global view.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

Donny Viszneki

unread,
May 25, 2009, 3:24:40 PM5/25/09
to serv...@googlegroups.com
Exactly! :)
--
http://codebad.com/
Reply all
Reply to author
Forward
0 new messages