[1:56]<kriskowal> working on unit tests for binary/f, if anyone wants in on this action http://gist.github.com/310702 [1:59]<ashb> kriskowal: fwiw i'm not sure of hte value of testing or evne specifing .length of fns [1:59]<kriskowal> meh. ecma does [1:59]<ashb> really? [1:59]<kriskowal> yeah [1:59]<ashb> i think its serious overkill [2:00]<kriskowal> doesn't hurt [2:00]<ashb> it confused me a bit, cos we also have a .length instance property [2:00]<ashb> took me a few mos to remember you can do fn.length [2:01]<ashb> but its failry minor [2:01]<kriskowal> yeah, some things depend on it [2:01]<ashb> but i'd say the behaviour of the tests is more important [2:01]<kriskowal> partial application libs [2:01]<ashb> on a more serious note: i wonder if oyu can actually set the fn.length for C++-bound ctors in spidermonkey [2:02]<ashb> dont partial application libs just use what ever you give them? [2:02]<kriskowal> in any case, i won't miss it if it disappears [2:03]<ashb> rhino still has x.throws bug? [2:03]<kriskowal> it's not really a bug [2:03]<ashb> its the only engine that behaves that way tho isn't it? [2:03]<kriskowal> safari 2 [2:03]<ashb> "eh" [2:03]<kriskowal> not that that matters [2:04]<kriskowal> but it's *not* a bug [2:04]<kriskowal> it's just strict adherence to es3 [2:04]<ashb> lie 43 [2:04]<ashb> why does that throw [2:04]<ashb> *line [2:04]<ashb> oh it was only es5 (if even then) when they loosend the grammar to deal with that sort of thing? [2:04]<kriskowal> yeah [2:05]<ashb> (the style you've got of giving messages still looks odd to me.) [2:05]<kriskowal> g2g; plz fork and annotate [2:05]<ashb> ditto - its 2am here [2:05]<ashb> have to sleep [2:06]<ashb> tho i can make a quick edit or two [2:06]<kriskowal> tale a penny, leave a penny [2:06]<kriskowal> *take [2:06]<ashb> this is when the webedits come in handy [2:07]<kriskowal> i mean, don't hesitate to add new code if you've got a moment [2:07]<ashb> http://gist.github.com/gists/310706 [2:07]<ashb> just those two things i pointed out [2:08]<ashb> dont have time to do more now [2:08]<ashb> & [8:14]<ondras> kriskowal: hey, nice work on binary/f ! [8:15]<ondras> I have to read it again more thoroughly, but on first sight, it looks promising [8:59]<kriskowal> ondras^ very good, thanks [8:59]<kriskowal> i've got 1/4 of a test suite completed [9:00]<kriskowal> it's all stubbed, just needs about 45 more cases [9:01]<kriskowal> the design is sortof the intersection between binary/e and what ryah wrote up for nodejs, with a couple little changes to bridge the gap [9:01]<ondras> cool [9:01]<ondras> I will probably implement this proposal [9:01]<ondras> kriskowal: just posted a response with some questions.. [9:01]<kriskowal> ok [9:03]<kriskowal> well, i'll have to reverse engineer a story, on some of these questions [9:03]<kriskowal> Content is dantman's idea, "views" are from ryah's implementation and strongly resemble webgl stuff [9:04]<Dantman> I didn't like .Content, .contentConstructor was my preference. [9:05]<kriskowal> in any case, i think the views are handy for providing a "trimmed" Buffer, say, exactly the size of something you wrote to it, and then throw away the original without having to do a copy to a precisely sized buffer [9:05]<kriskowal> in any case, the concept is your idea [9:11]<Dantman> What's this about views? [9:11]<Dantman> I never saw anything on them. [9:12]<ondras> hm [9:12]<ondras> perhaps that was aimed at me? [9:12]<ondras> but views are not *exactly* my idea [9:12]<Dantman> Oh, kris left [9:12]<ondras> I just proposed them to solve some issues with binary/b [9:12]<ondras> let's wait for him :) [9:13]<ondras> Dantman: so, what is the deal with .contentConstructor? :) [9:13]<Dantman> ondras, If you look at Binary/C and IO/B/Buffer and you'll understand where the idea came from. [9:15]<Dantman> .contentConstructor is part of the idea of being able to abstractly manipulate character or byte based sequences. [9:16]<ondras> Dantman: can you point me directly to some usage scenario / code sample? [9:16]<Dantman> ie: so any algorithm you write that applies to both doesn't need to be written twice. [9:18]<ondras> var clone = someUnknownData[index].Content(someUnknownData[index]) ? [9:18]<ondras> or what? [9:20]<Dantman> ondras, The code is discarded, but this is the general idea; http://github.com/dantman/monkeyscript.lite/blob/master/src/bananas/os/io/Stream.js#L111-131 [9:21]<Dantman> http://wiki.commonjs.org/wiki/IO/B/Buffer#Abstract_API has a few things that you can do using contentConstructor [9:24]<ondras> Dantman: first, let me clarify one thing - you propose the .contentConstructor as a static property, right? [9:24]<ondras> (as opposed to prototype property) [9:24]<Dantman> No, on the prototype [9:24]<ondras> ah [9:24]<hannesw__> Quick question: how would the omission of toByteString() in Binary/F affect JSGI, which requires this method? [9:25]<ondras> hannesw__: how exactly is toBS used in JSGI? [9:25]<hannesw__> JSGI response body parts (returned by forEach) must have this method [9:26]<Dantman> "".constructor === String; "".contentConstructor === String; (new StringBuffer()).constructor !== String; (new StringBuffer()).contentConstructor === String; [9:26]<Dantman> Thus... [9:26]<tlrobinson> hannesw__: that seems like an accidental omission [9:28]<Dantman> /* where buf is a buffer of unknown content type */var buf2 = new Buffer(buf.contentConstructor, 512); buf2.replace(buf.range(128, 128), 0); [9:29]<hannesw__> it would then probably be called toBuffer() since ByteString is no more... [9:29]<hannesw__> I think I'd prefer "Binary" over "Buffer" [9:30]* Dantman preferred it when Blob and Buffer were avoided by the other Binary specs so he could safely reserve them for his own idea of binary... [9:30]<ondras> Dantman: why is new Buffer(buf.contentConstructor) preferred over new Buffer(buf) ? [9:31]<Dantman> ondras, two different things; new Buffer(buf.contentConstructor); just creates a new StringBuffer or BlobBuffer; Whilst new Buffer(buf); does also create a new buffer with the same type, but it also copies the content of the other buffer. [9:32]<ondras> hm, judging from the code sample you provided (yank), I see the Buffer used in a way c++ templates work [9:32]<ondras> Dantman: what about new buf.contentConstructor() [9:32]<ondras> Dantman: or, more precisely, new buf.constructor() ? [9:33]<Dantman> Most of the time you don't really want to create a buffer with the same contents as another buffer. What you want is a buffer that holds the same type of contents so you can move only a specific part of the buffer. [9:33]<ondras> if the content type is determined by constructor name/type, imho it is perfectly sufficient to do "new buf.constructor()" [9:33]<Dantman> new buf.constructor() would work. but wouldn't apply if you had data instead of a bufer [9:34]<ondras> ? [9:34]<Dantman> .contentConstructor has other uses than just creating a buffer [9:36]<Dantman> It's a quick and easy way to get things like a empty, or a \0, or cast data abstractly. [9:36]<Dantman> For example, .clear could actually be written in JS rather than as a native part of Buffer. [9:37]<Dantman> Buffer.prototype.clear = function(start, length) { return this.fill(start, length, this.contentConstructor.fromCode(0)); }; [9:39]<Dantman> ondras, for your ?; I mean that `new buf.constructor();` doesn't apply if you have a string or blob instead of a buffer. [9:44]<ondras> Dantman: sorry for not replying, some work had to be done [9:45]<ondras> Dantman: so, as for the "?", why cannot I use new stuff.constructor() with non-buffer data? [9:46]<ondras> also, Buffer.prototype.clear = function() { if (this.length) this.fill(start, length, this[0].constructor.fromCode(0)); } [9:48]<Dantman> Sure, you can... But the idea is that .contentConstructor applies no matter what type of data you have. Instead of swapping a half dozen different techniques to do one thing depending on the data, you have one technique that applies to whatever data you get to do that one thing. [9:50]<ondras> mhm [9:50]<ondras> still, my opinion is that one can do this even without the .contentConstructor [9:50]<ondras> (note that JS Array, an abstract storage unit, also lacks this/similar functionality) [9:51]<Dantman> JS is abstract in an even more abstract way... it's completely generic. [9:51]<Dantman> s/JS/Array/ [9:51]<ondras> yeah :) [9:53]<Dantman> sure you might be able to do stuff abstractly without .contentConstructor; but you'll probably end up having to come up with varying sets of clever tricks depending on your algorithm. [9:53]<Dantman> Big difference is also Array isn't a single type of abstract. It doesn't care what the content inside of the array is. [9:54]<Dantman> Your array could be a mix containing a few strings, some binary data, a scattered set of numbers, a whole object, a date or two, and a function thrown in. [9:54]<Dantman> Whilst a buffer ONLY ever holds text data, or binary data. [9:54]<ondras> that is indeed true [9:54]<ondras> it works exactly as a c++ template [9:55]<Dantman> ^_^ I hope those work better than Java generics when it comes to primitives. [10:19]<Dantman> ondras, Thing about contentConstructor is it really only works in Binary/C-IO/B/Buffer... When you apply it outside to these other specs that are including it, it completely loses it's use cases. [10:20]<Dantman> Oh, I see what views are now... shared buffers [10:21]<Dantman> shared portions of buffers* [10:21]<Dantman> Wait... no... comments confused me [10:23]<ondras> yes, views are shared buffers [10:24]<Dantman> Ok, now I see it in the spec... looks like it got derived from my range idea, changed from it's original purpose. [10:26]<Dantman> Guess that works with fixed-length... I prefer mutable-length Buffer though. [10:29]* ondras too [20:14]<ondras> kriskowal: ? [20:15]<kriskowal> pardon, my inbox is stuffed; i'll be back in a bit [21:02]<arvi> hi [21:08]<ondras> detach, zzz [21:20]<ashb> http://gist.github.com/311512 [21:21]<ashb> automatically fill out a template package.json when oyu edit a new file