Mochabot log - CommonJS IRC channel: #commonjs on irc.freenode.net

2010-10-15:

[22:28] <deanlandolt> Wes node's buffers and Binary/F are /so very similar/
[22:31] <Wes-> deanlandolt: That's not an accident
[22:31] <Wes-> deanlandolt: Binary/F was conceived after much input from Ryan
[22:31] <deanlandolt> oh? i didn't realize
[22:31] <deanlandolt> cool
[22:32] <Wes-> deanlandolt: I would implement Binary/F if others were interested
[22:32] <Wes-> deanlandolt: Except for the crazy parts
[22:32] <deanlandolt> it can be implemented on top of the other stuff
[22:32] <Wes-> Or was that /E with all the crazy stuff?
[22:32] <Wes-> (crazy - bit-types)
[22:32] <deanlandolt> E's got the crazy
[22:32] <deanlandolt> well, D's got the bittypes
[22:32] <Wes-> deanlandolt: Yeah - I would implement Binary/F in pure JS re-using my Memory (blob) type
[22:32] <deanlandolt> neat ideas, but definitely need to be layered ontop
[22:33] <deanlandolt> good deal
[22:33] <deanlandolt> so i got gpsee built last night but still need to toy around with it...it's got /B right?
[22:34] <deanlandolt> B seems to have the most implementations...
[22:39] <Wes-> deanlandolt: It does indeed have binary/b
[22:40] <deanlandolt> cool...fewer shims i have to write :)
[22:40] <deanlandolt> given the broad support for binary/b i'm fairly sure i can have something up that will let you do pretty much all of binary/f in every lib this weekend
[22:40] <deanlandolt> err, every engine
[22:41] <deanlandolt> Wes- given your encoding knowledge, i've got another crazy idea to run by you...i know kriskowal has suggested this several times but i'm not positive it would work (given stateful encodings and all that crap)...
[22:42] <deanlandolt> so, we could specify (or not, just have it as a feature for now) that you can pass an object with encode and decode members rather than a string charset
[22:46] <Wes-> deanlandolt: probably useless tip -- if you add properties to Memory, rather than wrapping in another object, the bytes in Memory can be directly passed as C pointers when using gffi
[22:47] <deanlandolt> you have absolutely no idea how far over my head that tip is :)
[22:48] <Wes-> deanlandolt: LOL - someday, maybe. :)
[22:49] <Wes-> deanlandolt: Another tip, if you "steal" methods from require("binary").ByteString.prototype (or ByteArray.prototype), they will probably work on instances of Memory, since they all share a common C back-end storage model
[22:49] <deanlandolt> now that i can use :)
[22:50] <deanlandolt> what would you say the difference is between your idea of Memory and Buffer?
[22:50] <deanlandolt> i'm trying to classify this stuff to get a better feel...right now there's a basic binary host object interface, then a mutable one, then a "buffer" one (for lack of a better word...maybe i should call it "subsettable"
[22:51] <deanlandolt> or "rangeable" to use the word from binary/f
[22:51] <Wes-> deanlandolt: Memory was just intended to be a generic wrapper for malloc() so I could use it for/with C functions requiring pointers to blocks of malloc'd memory
[22:52] <Wes-> When GPSEE allocates a ByteThing internally, we have a common C storage semantic (which allows, for example, method stealing), then we put a JS "face" on it to expose the properties/methods we want
[22:53] <Wes-> In Memory()'s case, those are a finalizer that frees, ability to tweak individual bytes, and that's about it
[22:53] <deanlandolt> okay...so if you put enough of a face on it you've got a Buffer i guess
[22:54] <Wes-> deanlandolt: Pretty much, yeah. If it became a spec, I would just add another constructor that behaved liked memory, then add the methods in JS, and call it something else
[22:54] <Wes-> We can have mixed C / JS modules, so that kind of thing is easy
[22:54] <deanlandolt> nice
[22:54] <Wes-> deanlandolt: Some design notes that may interest you: http://code.google.com/p/gpsee/wiki/ByteThings
[22:55] <deanlandolt> thanks, that'll be helpful...i'm diving into pretty much every api doc i can find
[22:55] <Wes-> If C were OO, "ByteThing" would be the base class that all my binary types derive from
[22:55] <deanlandolt> i was calling that BinaryHost
[22:55] <deanlandolt> err, HostBinary
[22:55] <Wes-> That includes not only binary/b and Memory, but also things like MutableStruct, which is a memory image of a C structure (like a java object, kinda)
[22:56] <deanlandolt> because the binary objects themselves are supplied by the host -- i make no assumptions about modules
[22:56] <Wes-> Probably a better name; we used ByteThing after we already had ByteArray and ByteString and wanted to refactor and reuse :)
[22:57] <deanlandolt> so w/ something like binary/b i should use ByteArray as the HostBinary, right?
[22:58] <deanlandolt> been trying to figure out the right approach but i don't understand the low-level implications
[22:59] <deanlandolt> i was planning on patching the HostBinary methods onto both, actually, so that's not the right question...i guess i don't really have to pick one, but i have to get cute w/ the interface spec
[23:00] <Wes-> deanlandolt: basically, I think you can start off with something like
[23:00] * Wes- types furiously
[23:01] <deanlandolt> oh, and just to update you, since we can't patch into [[Get]] and [[Put]] w/o proxy objs i was thinking we could use prototype.get (for all binary) and prototype.put for mutable
[23:01] <Wes-> http://pastebin.mozilla.org/818329
[23:01] <Wes-> is one idea
[23:02] <deanlandolt> what does charCodeAt do specifically?
[23:02] <Wes-> deanlandolt: I think those should be mandatory with [[Get]] optional
[23:02] <Wes-> (does ES-5 add catch-all? I don't think it does)
[23:02] <deanlandolt> yeah, good deal
[23:02] <deanlandolt> no, it doesn't
[23:02] <deanlandolt> harmony...whenever that happens :)
[23:03] <deanlandolt> but yeah, your pastebin was pretty much what i had in mind...
[23:04] <deanlandolt> i guess it does make sense to make a special branch for gpsee
[23:04] <deanlandolt> i can still have a simple binary/b fallback but if you think a gffi/Memory obj is the best that should be easy enough to do
[23:05] <Wes-> deanlandolt: Hm, there are certainly advantages for doing binary/b for you as well
[23:05] <Wes-> deanlandolt: either way, when you're done I can re-factor super fast
[23:05] <deanlandolt> nice
[23:06] <deanlandolt> the node one is almost done...everything else should be a lot easier since i won't have to think too hard
[23:06] <deanlandolt> also, what do you think about changing toBinary to getBytes (a la java.lang.String -- given js has ripped off most of java.lang.String already)
[23:06] <deanlandolt> it's completely neutral about what it's supposed to return
[23:06] <Wes-> In fact, binary/b gives you the advantage of documentation that's correct :/
[23:07] <Wes-> deanlandolt: I like that better, honestly
[23:07] <deanlandolt> cool
[23:07] <Wes-> Although, what's it returning?
[23:07] <Wes-> an array of numbers?
[23:07] <deanlandolt> a HostBinary
[23:07] <Wes-> ah, of course
[23:07] <deanlandolt> no, i mean this isn't /actually/ java :)
[23:07] <deanlandolt> we don't have byte[]
[23:08] <Wes-> FWIW - I don't actually know java, I just read a chapter in a book on it once :)
[23:08] <deanlandolt> but that host binary could just as well be a bytestring, bytearray, buffer, blob, whatever
[23:08] <Wes-> Or a real HostBinary
[23:08] <deanlandolt> yeah
[23:09] <Wes-> if you built binary/dean around HostBinary.prototype it would be really simple to swap in implementations
[23:09] <deanlandolt> but they're all real HostBinary (because it's not necessarily a class, even though it could be...it's just a duckspec'ed interface)
[23:09] <Wes-> all you would technically need (for crappy performance) is get and put
[23:09] * Wes- nods
[23:09] <deanlandolt> i'm using get and set...hmm, stupid node
[23:09] <deanlandolt> i guess i should use put
[23:10] <deanlandolt> none the less, you don't actually need put to be a HostBinary...just to be a MutableHostBinary (ugh, how terribly java that looks...but it's just for documentation's sake)
[23:10] <deanlandolt> IHostBinaryMutable...ugh
[23:11] <deanlandolt> AbstractBaseHostBinaryFactoryFactory
[23:11] <Wes-> FWIW, keeping Mutability spec clean, it means implementations can add Copy-On-Write much easier down the road
[23:11] <deanlandolt> sweet
[23:11] <deanlandolt> i was thinking just set and setBytes
[23:11] <deanlandolt> (put makes more sense but putBytes sounds silly :-/)
[23:12] <Wes-> I already drawn up rules for GPSEE, but haven't implemented them yet. It's a lot of work, too much to do without metrics telling me it's necessary
[23:12] <deanlandolt> setBytes being the getBytes corrallary...but it's not strictly necessary
[23:12] <Wes-> Does ES-5 use [[Set]] or [[Put]]? Whichever it is is probably the right direction for you
[23:13] <deanlandolt> well, it uses IDL which i think uses [[Put]]...let me see
[23:14] <deanlandolt> damn, it's [[Put]]
[23:14] <deanlandolt> ah well...setBytes was a stupid idea anyway...use copy if you really want that
[23:14] <Wes-> Last time I touched IDL was for VB6. Man that was a long time ago.
[23:15] <deanlandolt> hmm, dropping setBytes is nice
[23:15] <deanlandolt> alright...i'll start writing up some tests for the node stuff a little later tonight and get the binary/b stuff started...i'll keep you posted
[23:16] <Wes-> Please Mr. Unix Hacker Man, Give your lib to me. And make a DLL. And do some IDL. And make a TLB, 'cause I'm into basic - can't hack Visual-C
[23:16] <deanlandolt> my company still has vb6 libs in production :-/
[23:17] <deanlandolt> (it was what the owner of the company learned on...and for a while he didn't actually know how to read lines...so there are libs in use every day that read the whole file character by character and build up words)
[23:18] <deanlandolt> i mean, reading his code it's clear his brilliant...how else could you possibly keep all that in your head...it's like reading assembly
[23:35] <Wes-> deanlandolt: Don't laugh, when I was growing up, we wrote assembly in basic, using data statements: http://www.atarimagazines.com/compute/issue70/096_1_The_New_Automatic_Proofreader_For_Commodore.php (scroll to bottom)
[23:35] <Wes-> those data statements contain the bytes of assembly to run

 

 

Logs by date :