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

2010-03-12:

[7:35] <hannesw> question:
[7:35] <hannesw> is 64 supposed to work as encoding id for converting binaries to strings?
[7:36] <hannesw> in narwhal, Binary.decodeToString(64) will return a base64 encoded string
[7:36] <ondras> well
[7:36] <ondras> Charset strings are as defined by IANA http://www.iana.org/assignments/character-sets.
[7:36] <ondras> (taken from binary/f)
[7:36] <hannesw> i'm not sure if this is to be considered commonjs compliant or a narwhal extension
[7:36] <kriskowal> hannesw it's not speced
[7:36] <kriskowal> it's an extension.
[7:36] <hannesw> thanks guys
[7:37] <kriskowal> i didn't think i could get that past you guys, but i wanted it anyway
[7:37] <hannesw> so i'll send a pull request for my jack fork...
[7:37] <hannesw> didn't know if i should implement this as well
[7:37] <kriskowal> oh, we're depending on it in jack?
[7:37] <hannesw> yep, for cookie encoding
[7:37] <kriskowal> ah.
[7:37] <hannesw> http://github.com/hns/jack/commit/c42e949e0171953364f9f76ad631d604bd1a3c48
[7:37] <kriskowal> well, i'd be tickled pink if i could sell that feature to you guys, but i'm not counting on it
[7:38] <hannesw> :)
[7:38] <kriskowal> thanks
[7:38] <hannesw> thanks too for the help
[7:38] <ondras> by the way
[7:39] <ondras> what is the current binary status?
[7:39] <kriskowal> 0
[7:39] <ondras> there was some major discussion whether to include transcoding or not
[7:39] <kriskowal> get it!?
[7:39] <ondras> I am not sure how it ended
[7:39] <kriskowal> it hasn't really. i'm supposed to reply to Wes--'s last post on the issue
[7:40] <kriskowal> regarding minimal transcoding
[7:40] <kriskowal> i like the approach
[7:40] <kriskowal> just want to take a moment to really understand the details, maybe prototype it
[7:40] <ondras> hm
[7:40] <kriskowal> and it would be good to hear from ryah about it too
[7:40] <ondras> "minimal", what does that cover?
[7:42] <kriskowal> utf-8, utf-16, and ascii, and i'm not sure whether we're going to handle broken multi-byte sequences
[7:42] <kriskowal> i'm guessing not
[7:42] <kriskowal> if you've got some time to read his last email closely, that'd be good
[7:42] <kriskowal> i put the proposal on the wiki too
[7:42] <kriskowal> http://wiki.commonjs.org/wiki/Binary/F/Wes
[7:43] <kriskowal> the proposal needs to be folded into a copy of Binary/F so we can see it all together too
[7:44] <kriskowal> until i get my orc army set up, i'm not going to be able to crank through this stuff as quickly as i would like
[7:46] <ondras> hmm
[7:46] <ondras> I see
[13:50] <ashb> we really could do with having *some* kind of stream api, or at least consistency
[13:50] <ashb> i was chatting in the pub and someone asked me "can i open and read a file with commonjs yet?"
[13:50] <ashb> to which my answer was "er, well you can *open* it"
[13:50] <ashb> and that kinda sucks
[13:53] <ondras> exactly.
[13:53] <Wes-> ashb: I have been making this point for over a year
[13:54] <ashb> i think we should just take the average of hipp,gpsee and narhwals and see where that gets us
[13:54] <ashb> sync only obviously for now
[13:54] <Wes-> Maybe we should cobble something together here we can all agree on?
[13:54] <Wes-> ashb: I haven't really done a full API, just what I needed as I was writing code
[13:54] <ashb> does RingoJS do file access?
[13:54] <ashb> Wes-: ditto
[13:54] <Wes-> I bet it does
[13:54] <ashb> probably
[13:55] <ondras> grrrr
[13:55] <ondras> v8cgi not mentioned
[13:55] <Wes-> in what?
[13:55] <ashb> etoomanyprojects
[13:55] <ashb> the list above
[13:55] * ondras prepares a truly big trout.
[13:55] * Wes- grabs a spear
[13:55] <ashb> ondras: so what does your file api look like?
[13:55] <ashb> file *reading*
[13:56] <ashb> got docs?
[13:56] <ondras> ashb: http://code.google.com/p/v8cgi/wiki/API#Files
[13:56] <Wes-> I want: read up to \n, and read up to n bytes without block, and read-the-whole-GD file
[13:56] <ondras> new File("/etc/passwd").open("r").read();
[13:56] <Wes-> all returning ByteString
[13:56] <ondras> no big deal
[13:56] <ashb> Wes-: probably worth having text mode too
[13:57] <Wes-> maybe read() is binary and readln() is text?
[13:57] <ashb> i imagine all the APIs are broadly similar
[13:57] <Wes-> open question then - what if file does not end in newline
[13:57] <ashb> Wes-: that or you open it in text or binary
[13:57] <Wes-> ashb: that changes fs-base
[13:57] <ashb> it already has a binary flat doesn't it?
[13:57] <Wes-> I want something that fs-base can return, so we can build other stuff on top of it
[13:57] <ashb> also fs-base not set in stone
[13:57] <ashb> oh i see
[13:57] <ashb> i.e. fs-base should only return binary streams?
[13:58] <Wes-> I think that's probably reasonable - you can layer a text stream on top without cost
[13:58] <ashb> tho you could optimize it to deal with text too, but you want something that could in theory be done on top of fs-base in pure js?
[13:58] <Wes-> yes
[13:58] <ashb> k
[13:58] <Wes-> js + Binary/F, js + Binary/B, or js + Encodings
[13:58] <Wes-> (binary/F with my ammendments)
[13:59] <Wes-> readInto() should probably be supported too
[13:59] <Wes-> decrease gc churn
[14:00] <ashb> probably - but i'd like to keep the API surface as small as is reasonable
[14:00] <Wes-> Yeah - actually, readInto() could replace read()
[14:00] <Wes-> but I think read-up-to-\n should be in the bottom layer
[14:01] <Wes-> possibly read-up-to-arbitrary-byte instead though
[14:01] <ashb> well yeah.
[14:01] <ashb> but does it have to?
[14:01] <ashb> read 4k - check. etc?
[14:01] <ashb> since that way you could look for multiple bytes
[14:01] <ashb> far less common case mind
[14:01] <Wes-> I'm more concerned about the optimizing the case where we read a line at a time
[14:02] <Wes-> since it's such a common pattern
[14:02] <ashb> true.
[14:02] <Wes-> readInto() will support the multibyte case with additional logic
[14:03] <Wes-> How about -- readInto(buf) -- read as much as we can without blocking into buf, readUpto(buf, byte) -- read until buf is full or we read a matching byte, blocking
[14:03] <Wes-> or readIntoUntil
[14:03] <ashb> dunno.
[14:03] <ashb> i think we should get a list of use cases we want to support
[14:03] <ashb> then work out an API
[14:03] * Wes- nods
[14:04] * ashb goes back to workoung out stop-loss orders and what not
[14:04] <Wes-> For me, they are reading arbitrary data from sockets, reading text files a line at a time, and reading the whole file
[14:04] <ondras> this is the case with binary as well imho
[14:04] <ondras> people want it to be asi universal as possible
[14:04] <ondras> => too many features
[14:04] <ondras> => long std process
[14:04] <ondras> not good for development
[14:39] <Wes-> ondras: most interesting problem we have now is -- which binary do binary streams use, heh
[14:39] <ashb> thats why text files would be easier to deal with >_>
[14:39] <ashb> Wes-: but does it actually matter which they use?
[14:40] <Wes-> ashb: It matters what they use because you need to know how to toString() at the very least
[14:41] <Wes-> ashb: but text-only streams a) waste memory b) waste cycles if we needs Strings, and worst yet, make handling true binary data a royal pain -- I really think text should not be a bottom layer
[14:44] <ondras> Wes-: yeah
[14:44] <ondras> ashb: precisely, text files are a good place to start :)
[14:45] <ashb> Wes-: text-only streams dont waste memory if text is what you want out
[14:45] <Wes-> ashb: Sorry, I mean "unless we need Strings"
[14:46] <Wes-> even writing something like grep would be silly without binary streams, who want to convert 100% of a file when you only want a few liens?
[21:10] <Dantman> kriskowal, Did you want implementations list at the top of specs, or a lower section?
[21:36] <kriskowal> Dantman i think it would be good to see either way
[21:36] <kriskowal> it depends on how condensed it can be
[21:37] <kriskowal> it might be good to have a full list at the bottom, and a summary inline on top, something that maxes out at about 3em tall
[21:37] <Dantman> For starters, http://wiki.commonjs.org/wiki/Implementations/Narwhal
[21:40] <kriskowal> Dantman, nominally that would contain a list of specs that Narwhal implements?
[21:40] <Dantman> Yup, it will soon, auto generated
[21:40] <kriskowal> ok, neat. i look forward to seeing that.
[21:40] <Dantman> I wanted to know where I should locate the template on the individual specs that'll cause them to be generated
[21:41] <Dantman> Ideally it'll also replace that table on the front page
[21:41] <kriskowal> yes, that'd be good
[21:41] <Dantman> T_T Right now I'm wrestling with usernames vs. real names.
[21:41] <kriskowal> yeah
[21:41] <ashb> Dantman: template on the user page perhaps?
[21:41] <Dantman> Mhmm
[21:41] <ashb> also i'd like to say that you can't implement a spec (beyond trial stage) unless there is a (recognised/accepted?) test suite
[21:42] <kriskowal> yeah, claiming compliance without a compliance test suite is premature
[21:45] <Dantman> iirc Fluspferd had a umlaut or something; http://wiki.commonjs.org/wiki/Implementations/Flusspferd
[21:45] <Dantman> Just fix the name=
[21:52] <ashb> no umlauts in the project name
[21:53] <ashb> Ruediger can have an umlaut: Ru?diger or Ruediger
[21:54] <ashb> Embeddings listing C++ seems odd
[21:54] <ashb> you probably want two fields
[21:54] <ashb> 1 for JS engine(s) and another for API language(s)
[21:54] <ashb> s/API/extension/
[21:56] <Dantman> Meh, I think leaving embeddings like that will work nicest with drilldown
[21:56] <ashb> why is flusspferd the only one with a language in it?
[21:57] <Dantman> It's not
[21:57] <Dantman> http://wiki.commonjs.org/wiki/Implementations
[21:57] <Dantman> It's the ones embedding SpiderMonkey that note what language it's in.
[21:58] <Dantman> So far SM users are the only ones varying in implementation language.
[21:58] <ashb> guess so
[21:58] <ashb> still not sure Embeddings is the right term
[21:59] <Dantman> Meh, that's what was used on the main page
[22:01] <Wes--> Personally I don't see what the implementation language of the embedding has to do with anything
[22:01] <Wes--> At least from the CJS POV
[22:02] <Wes--> flusspferd has a nice C++ API that replaces spidermonkey's clunky JSAPI
[22:02] <Wes--> but that's not a CJS feature
[22:04] <MisterN> it may matter to users.
[22:31] <Dantman> ^_^ For starters this looks fancy; http://wiki.commonjs.org/wiki/Modules/1.0
[22:33] <Dantman> Based off a simple "Chiron, Flusspferd, GPSEE, Narwhal=0.1, Persevere, RingoJS, SproutCore, node.js, v8cgi", note that SproutCore is displayed as SproutCore 1.1/Tiki
[22:44] <Dantman> Agh, "APPROVED BY DISCUSSION PARTICIPANTS" doesn't fit well into my status line
[23:08] <Dantman> Agh, my spec category isn't getting populated.
[23:36] <ashb> Danits also on the long side
[23:37] <ashb> dantmen isn't here Dave.
[23:41] <MisterN> ashb: Dave isn't here either.
[23:41] <ashb> Everyone's dead, Dave

 

 

Logs by date :