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

2010-04-23:

[1:06] <kriskowal> ashb konobi yeah, all future dev on the unit tests will be going into the github commonjs/commonjs
[1:13] <jbrantly> kriskowal: I was just looking at the unit testing unit test. I notice it has "require('os')" in it. Is that kosher?
[1:17] <kriskowal> oh, really? no, that's not commonjs
[1:19] <kriskowal> jbrantly^
[1:19] <kriskowal> ah, i see.
[1:19] <jbrantly> kriskowal: that's what I thought. http://github.com/commonjs/commonjs/blob/master/tests/unit-testing/1.0/program.js#L161
[1:19] <kriskowal> yeh
[1:19] <kriskowal> an artifact of running on narwhal
[1:21] <jbrantly> also, as I mentioned earlier, I have some 1.1.1 unit tests. They're not complete or anything, but they may inspire you. http://github.com/jbrantly/yabble/tree/master/tests/modules1.1.1/tests
[1:23] <kriskowal> feel free to fork the commonjs tests
[2:20] <konobi> kriskowal: is there a standard prefi to use for implementation specific features?
[2:20] <konobi> *prefix
[2:21] <kriskowal> what do you mean?
[2:21] <kriskowal> on object properties or module names
[2:21] <konobi> module names
[2:21] <kriskowal> i'm using the platform as the name space
[2:21] <kriskowal> e.g., narwhal/
[2:21] <kriskowal> i've recommended that node move stuff into node/
[2:22] <kriskowal> and i'm in the process of moving all of narwhal-lib into the narwhal/ namespace so it can work gracefully on more engines.
[2:22] <konobi> hhhmmm... projects changes names
[2:22] <kriskowal> yeah, so relative module identifiers are a big win
[2:22] <konobi> eh?
[2:23] <konobi> oh i see... so you can easily map back to the new one?
[2:23] <kriskowal> at least internally. kriszyp's mappings proposal should alleviate some of the migration woes when projects change names.
[2:23] <kriskowal> you can easily move the directory to rename the entire tree.
[2:23] <kriskowal> and use mappings to help migrate other projects to the new name.
[2:24] <kriskowal> e.g., s/narwhal/isopod/
[2:24] <konobi> i suppose the question then is should I search for implementation specifc stuff first, or user directories first
[2:24] <kriskowal> like ~/.node stuff?
[2:24] <konobi> um... native bindings
[2:25] <kriskowal> in narwhal package/*/lib -> engine/<engine>/lib -> lib
[2:26] <konobi> so... sys, posix, other stuff tht doesn't actually have js lying underneath
[2:26] <kriskowal> but that's because we provide default implementations later down the chain, and permit users to override
[2:27] <konobi> meh... my stuff first it is
[2:27] <konobi> =0)
[2:50] <konobi> kriskowal: then there's the question of stuff that's not a "standard", but could be, etc.
[2:50] <kriskowal> yeah, that's something i need to propose?
[2:50] <kriskowal> i've had that on my mind.
[2:51] <kriskowal> i'm moving narwhal in the direction of not presuming anything about future standards by keeping non-standard things namespaced under narwhal
[2:51] <kriskowal> but there's also the possibility of "provisional names"
[2:51] <kriskowal> like, Binary/B could have a provisional name of "binary-b"
[2:51] <kriskowal> or binary/b
[2:52] <Wes-> I strongly encourage that
[2:52] <kriskowal> yeah, it's kinduh a no-brainer
[2:52] <Wes-> because I am writing *real world code* around binary/b
[2:52] <Wes-> I don't want it to break just because something different gets ratified
[2:52] <kriskowal> yeah, and others are writing real world code on binary/f
[2:52] <Wes-> yep!
[2:52] <kriskowal> then there's the matter of fs-base
[2:52] <Wes-> I found that having a resizable buffer for generating PDUs was handy, fwiw
[2:53] <kriskowal> might have to call that fs/a/0
[2:53] <Wes-> fs-base is great, except the streams API sucks. ;)
[2:53] <kriskowal> io/a?
[2:53] <Wes-> something like that
[2:53] <Wes-> I'm finding that I am no longer so gung-ho on unifying streams, though
[2:53] <kriskowal> then there's system/1.0
[2:53] <Wes-> this is because I am doing sockets with node's API
[2:54] <kriskowal> we really need to go back to the drawing board and create a holistic strategy for these names
[2:54] <Wes-> agreed
[2:54] <kriskowal> i see.
[2:54] <Wes-> I think what it boils down to is that streams for sync and async are *so different*
[2:55] <kriskowal> yeh, pretty much. promises can make them look very similar though.
[2:55] <Wes-> have you used node's net api?
[2:55] <Wes-> just get events with data in 'em
[2:55] * Wes- hasn't coded anythign around promises yet
[2:55] <Wes-> I'm game, though!
[2:55] <kriskowal> but i'm not advocating a mandate on a promise-based async io by any means. i think ryan's latest api's are starting to look okay
[2:55] <deanlandolt> events with data in 'em is pretty hard to spec :-/
[2:55] <konobi> Wes-: you weren't at jsconf, right?
[2:56] <Wes-> Sometime this year I intend to have a full-fledged reactor around a GPSEE embedding
[2:56] <Wes-> konobi: no
[2:56] <konobi> ah... gd gd... just as long as I didn't not place you
[2:56] <Wes-> deanlandolt: take a look at ryan's docs. His data is just strings, I would like to be able to register for bytestrings too
[2:56] <deanlandolt> i'm pretty scared by the whole drain stuff...i'm not gonna lie -- i'm pretty stupid
[2:56] <kriskowal> binary/f buffers more likely, but then things get interesting
[2:56] <konobi> streams generally work on Buffers in node i believe
[2:57] <Wes-> deanlandolt: implementing that was a little tricky, but you don't actually need to listen to the drain even if you don't need it
[2:57] <deanlandolt> Wes-: oh really? that makes me slightly less creeped out
[2:57] <Wes-> kriskowal: sure, binary/f buffers are fine. GPSEE allows copyless casting between binary types, 6 of one.. half a dozen of the other. :D
[2:57] <kriskowal> yeah, i follow
[2:58] <Wes-> deanlandolt: Yeah. What it boils down to is he shoves out only what can go without blocking, then finishes the rest up (assuming he can) on the next pass of the reactor loop
[2:58] <kriskowal> anyhow, if someone's got the time to write a proposal for a nomenclature reboot, i'm in favor
[2:59] <Wes-> deanlandolt: at least, that's how I implemented from the docs, who knows, I could be an illiterate b*stard ;)
[2:59] <kriskowal> gha, i should do it. i just don't have time in short order.
[2:59] * Wes- nods and sighs in deep understanding
[3:00] <kriskowal> deanlandolt, i also have reservations about ryah's throttling strategy, but i'm not really in the mood for picking more fights
[3:01] <deanlandolt> heh :)
[3:01] <kriskowal> there are real potential performance gains, and real performance hazards
[3:01] <deanlandolt> just seems like it's something that doesn't belong at the js level
[3:01] <kriskowal> a provisional spec would be in order.
[3:11] <Wes-> I have to admit, I am not confident that the drain event is a good way to implement throttling
[3:12] <Wes-> OTOH it can't hurt to give the JS user input about what's going on
[3:16] <deanlandolt> Wes-: i was under the impression drain wasn't actually to throttle (that's what pause/resume is for)
[3:17] <Wes-> deanlandolt: I recall reading that he suggested throttling based on drain event -- are you maybe thinking of HTTP level? I haven't implement that yet, only TCP (now require("net"))
[3:18] <deanlandolt> AFAICT drain is just an event that throws seemingly random extra data at you..it's kinda like when you're putting ikea furniture together and you have extra parts
[3:18] <Wes-> lol
[3:18] <Wes-> it's not completely random, though
[3:18] <Wes-> say you wanted to shove a 1MB file down the pipe
[3:18] <deanlandolt> i know -- then it'd make a good rng :)
[3:19] <Wes-> you don't want the write buffer in the reactor holding that 1MB file
[3:19] <Wes-> so, you memory map it, and say whack 20 pages at a time every time the drain event fires
[3:19] <Wes-> HMM
[3:19] <deanlandolt> yeah...
[3:20] <Wes-> the only problem with that, is that there might not be a way to tell for sure (via the current API) if 20 pages is enough to make it go into the mode where it's draining via the reator
[3:20] <Wes-> the first N bytes always go out immediately
[3:20] <Wes-> where N is the number of bytes the kernel will take without blocking
[3:20] <Wes-> probably somewhere around MTU - 54
[3:20] <deanlandolt> yep -- you can't control it, you can only hope to capture it
[3:21] <deanlandolt> i don't understand how a drain /event/ could possibly control throttling though
[3:21] <Wes-> he could update the API, though, make write return a bool that indicates if whole buffer is gone already or not
[3:21] <Wes-> ondrain = setTimeout(send more data, 100)
[3:22] <deanlandolt> i was wondering if setTimeout might be a decent api for throttling
[3:22] <Wes-> depends what your throttling goal is
[3:22] <Wes-> if it's to achieve a pariticular throughput, possibly
[3:22] <Wes-> If it's to avoid saturating your own NIC, you need drain too
[3:22] * deanlandolt has a lotta reading to do :-/
[3:23] <Wes-> deanlandolt: Not reading so much as visualization
[3:24] <Wes-> A good visualization tool might be to try and write node.js's net API if you can
[3:24] <Wes-> I found it very enlightening
[3:25] <deanlandolt> i'm pretty sure i'm lacking a whole bunch of foundational knowledge around this stuff though
[3:29] <Wes-> deanlandolt: If you ever make it up to my place... we can get some water, some plastic buckets, a soldering iron and build a crazy rube goldberg machine
[3:29] <Wes-> rube goldberg machine: async javascript
[3:31] <deanlandolt> Wes-: heh! the weird part is i /get/ the async stuff (took me quite a while)...i just don't get the /streams/ stuff, at least as far as node's net api is concerned
[3:32] <Wes-> deanlandolt: Ah - I haven't gotten that far up the food chain yet. The net module just sends you data events, with strings in 'em.
[3:33] <konobi> Buffers
[3:33] <deanlandolt> yeah (and the strings could be buffers)
[3:33] <konobi> deanlandolt: you should read Higher Order Perl
[3:33] <deanlandolt> but what kills me is the bidirectional aspect of it...data in, data out, async on both sides, and controlling the two
[3:34] <konobi> especially the stream processing stuff
[3:34] <deanlandolt> konobi: thanks -- i'll queue that up
[3:34] <konobi> lots of functional language techniques, etc.
[3:35] <deanlandolt> i'll definitely check that out
[8:33] <tlrobinson_> in case anyone is interesting, i packaged up that bundler i was talking about yesterday http://github.com/tlrobinson/minibundler
[9:46] <hannesw> tlrobinson (and kriskowal, in case you're reading):
[9:46] <hannesw> any plans to update narwhal's file module to the current filesystem proposal?
[9:47] <hannesw> we updated, and this currently breaks most narwhal libs and packages for us
[9:48] <hannesw> i might do some backwards compatibility hack - unless you're planning to update, that is
[12:27] <Wes-> hannesw: IIUC Kris is planning to port to fs-base
[12:29] <hannesw> yes, i think fs-base is there already
[12:30] <hannesw> problem is, until the old "file" module is there people will continue to use it
[12:32] <hannesw> well, it's pretty easy to fix:
[12:32] <hannesw> http://gist.github.com/376498
[16:34] <rektide> bah kk just left; come back
[19:13] <kuya_> ashb: still around?
[19:22] <ashb> yupo
[19:23] <ashb> kuya_: what's up?
[19:25] <kuya_> i want to do some comet type stuff and im wondering how zest is implemented
[19:25] <ashb> its built around boost's ASIO
[19:25] <kuya_> that sounds like a yes
[19:26] <ashb> thats a yes but not quite yet
[19:26] <ashb> i need to tweak a few things
[19:26] <kuya_> im thinking websockets
[19:26] <ashb> the main thing thats stopping me is working out what the JS api should be
[19:26] <ashb> (on the server)
[19:26] <kuya_> doesnt websockets define the client api?
[19:27] <ashb> yes. i mean i need to know how to expose the stream ability on from Zest
[19:27] <kuya_> ah i see
[19:28] <kuya_> i would be most interested in being a test case if you feel like it :)
[19:28] <ashb> how about you look at the possible APIs and work out which one is best :)
[19:28] <ashb> then i'll give a go implementing it
[19:28] <kuya_> that sounds like a deal
[19:28] <kuya_> :)
[19:30] <ashb> there was something about async jsgi on narhwall list very recently
[19:30] <ashb> then of course there is node
[19:30] <deanlandolt> kuya_: have a look at pintura's comet stuf
[19:30] <deanlandolt> stuff
[19:31] <kuya_> is that the notifyers on models?
[19:31] <deanlandolt> you don't really need to have async to do comet -- it's just better that way
[19:31] <deanlandolt> yeah, that's one...
[19:31] <kuya_> yea - i just dnt want complex client stuff - websockets would be fine :]
[19:32] <deanlandolt> oh, well, that's something entirely different...there are a bunch of options for node there
[19:33] <deanlandolt> but this is a pretty good example of how to do it in jsgi: http://github.com/kriszyp/pintura/blob/master/lib/jsgi/comet.js
[19:34] <kuya_> i need to learn about this promise stuff ...
[19:35] <deanlandolt> i need to write "the idiots guide to promises" ... i am perhaps the most qualified to write that :)
[19:35] <ashb> i personally donlt like promises all that much
[19:36] <deanlandolt> ashb: there's like /nothing/ to them -- i like it a lot more than callback soup
[19:36] <deanlandolt> i'd rather just code syncronously but sometimes that's just not a good option
[19:36] <ashb> deanlandolt: i (think)i understand them, just don't like the style
[19:36] <deanlandolt> what do you prefer?
[19:36] <ashb> dunno :) never came up
[19:36] <deanlandolt> heh
[19:37] <ashb> it might be the best idea
[19:37] <ashb> but i don't like it that much
[19:37] <deanlandolt> i've looked at the various continuables approaches -- they bother me too
[19:37] <deanlandolt> heh...fair enough
[19:38] <deanlandolt> promises are the closest thing i know of to at least come close to a syncronous style
[19:38] <deanlandolt> other than this, of course: http://www.croczilla.com/blog/17
[19:38] <kuya_> where is the source for promise?
[19:38] <deanlandolt> got a meeting...back in a bit
[19:38] <kuya_> doh
[19:38] <kuya_> :]
[19:39] <kuya_> tell me later if you think of it
[21:31] <deanlandolt> kuya_: http://github.com/kriszyp/narwhal/blob/master/lib/promise.js
[21:56] <jbrantly> am I mistaken in thinking that this is a typo?http://wiki.commonjs.org/wiki/Unit_Testing/1.0#Assert point 4 says "this statement is equivalent to assert.equal(true, guard, message_opt);" Shouldn't it be assert.equal(guard, true, message_opt)?
[21:57] <kriskowal> ah, yeah
[21:57] <kriskowal> jbrantly we changed the arg order late in the process.
[21:57] <kriskowal> i think you can fix that on the wiki without anyone being offended
[21:58] <jbrantly> alright, will do
[22:12] <DanielFriesen> O_o Jhuni has a twisted sense of programming conventions
[22:13] <jhuni> DanielFriesen: hi
[22:14] <kriskowal> DanielFrisen as people who are still writing javascript, it's safe to say that it's amazing what people can get used to.
[22:14] <DanielFriesen> "standard indentation"? double spacing? and replacing for loops with while loops in a rev with a comment "the code was written very poorly"?
[22:14] <jhuni> you talking about the add thing?
[22:15] <jhuni> Its generally a good convention to cache your lengths
[22:15] <DanielFriesen> I've never seen it done that way...
[22:15] <jhuni> and also returning your first argument if you have only one isn't something an add function should do
[22:16] <kriskowal> yeh, the idiom i've seen is for (var i = 0, ii = x.length; i < ii; i++)
[22:16] <jhuni> I like the while loop because javascript has function-based scoping, so when you declare a variable in the for its still accesible afterwards
[22:16] <DanielFriesen> If I'm doing premature optimization on a loop, I go for a reverse iteration; for (var i = x.length-1; i >= 0; --i )
[22:17] <kriskowal> that's orthogonal
[22:17] <jhuni> In general its good to have only one var statement per function
[22:17] <jbrantly> the whole code change was orthogonal, I thought
[22:17] <jhuni> was bored I guess =/
[22:17] <jbrantly> and Daniel: for (var i = x.length; i--;) {} :)
[22:17] <kriskowal> ah, i'm out of context, speaking generally
[22:17] * DanielFriesen needs to memorize the definition of "orthogonal"
[22:18] <jhuni> In terms of my programming style I use JSLINT
[22:18] <jhuni> it has an option "allow only one var statement per function"
[22:18] <jhuni> http://www.jslint.com/
[22:18] <DanielFriesen> jbrantly, I don't like placing --i i-- ++i or i++ anywhere where it means something... makes reading code slower for me.
[22:19] <jhuni> If I was writing perl6 I would just say [+] @_;
[22:19] <jbrantly> DanielFriesen: sure, but you were talking about optimization. That form is faster than yours.
[22:20] <DanielFriesen> ^_^ Meh, "premature optimization"
[22:20] <kriskowal> orthogonal: the shadow of a point moving along one line does not move along the ground. it's perpendicularity in a more general sense, but in programming means unrelated
[22:20] <jhuni> sub add { [+] @_ }
[22:20] <DanielFriesen> Math.sum.apply(Math, arr)
[22:21] <jhuni> Math.sum is a function?
[22:21] <kriskowal> arr.reduce(add, 0)
[22:21] <DanielFriesen> ^_^ I already added a Math.sum to Wrench.js
[22:21] <jhuni> you can't do reduce on arguments cause its not an array lol design mistake
[22:21] <jhuni> Array.prototype.reduce.call(arguments,function(){return a+b;});
[22:21] <DanielFriesen> I created reduceNative for that purpose
[22:22] <DanielFriesen> So that arr.reduceNative(Math.max) would work.
[22:22] <kriskowal> aye, aye jhuni
[22:22] <DanielFriesen> It's basically reduce but only uses the first two args.
[22:22] <kriskowal> no basis?
[22:23] <DanielFriesen> Though iirc there was one broken case.
[22:24] <jhuni> DanielFriesen: When I said standard identation of four spaces I was refering to Douglas Crockford's Coding conventions and JSLINT and the fact that a spacing of four lets you line up your var statements
[22:26] <DanielFriesen> What happened to the good ole universal tab?
[22:27] <jhuni> DanielFriesen: amazingly, tabs aren't displaced in a standard manner, so if you line up your vars with tabs then your code might look really messed up, actually happened to me on some code on github
[22:27] <jhuni> s/displaced/displayed/
[22:27] <DanielFriesen> You're not suppose to line up var statements with tabs, thats misuse of tabs
[22:27] <DanielFriesen> tabs are for leading indentation, not char specific indentation.
[22:28] <jbrantly> oh boy, this debate again
[22:28] <DanielFriesen> jbrantly, ^_^ for however endless this debate is, I've never actually participated in one before...
[22:29] <jhuni> DanielFriesen: I merely prefer the JSLINT crockford-style, doesn't mean you have to use tabs...
[22:32] <DanielFriesen> Oh right, my Math.avg behaved strangely with reduceNative... oh well, not really a good idea to try to use reduce with an avg method anyways.
[22:34] <DanielFriesen> ^_^ the prospect of my moving in a few weeks is more interesting than indentation or reduceNative issues anyways...
[22:37] <jbrantly> me too! Got a job with Ext JS, moving out to the bay area. Apparently thats where everybody else lives too.
[22:38] <DanielFriesen> I'm moving out of a room which is taller than it is wide, and getting a master bedroom!
[22:40] <jbrantly> congrats
[22:43] <DanielFriesen> And I'll be able to take the Skytrain instead of the WCE, so I can actually eat breakfast at home and not be an hour or two late if I sleep in 5 minutes.
[23:37] <jbrantly> it looks like Unit Testing/1.0 doesn't include an API for async tests. I'm not thinking of a way around this without some kind of proprietary API. Am I missing something?
[23:37] <kriskowal> jbrantly, no, you're dead on. we deferred the issue
[23:38] <jbrantly> thanks
[23:38] <kriskowal> i did start working on a version that allowed the test functions to return promises.
[23:38] <kriskowal> didn't finish it.
[23:39] <jbrantly> sucks because it makes it hard to write tests for require.ensure, for example
[23:39] <kriskowal> aye
[23:39] <dmachi> DOH (dojo's unit test harness) does do async tests, could probably copy/port some of that too
[23:40] <kriskowal> there's also QUnit; it does them
[23:40] <jbrantly> dmachi: the problem isn't so much the implementation but that I was hoping to write some tests for Async/A using Unit Testing/1.0
[23:40] <kriskowal> aye
[23:40] <dmachi> right, figured, just thought i'd mention any prior art on the aysnc side :)
[23:41] <jbrantly> dmachi: gotcha, thanks. I'm familiar with QUnit's approach
[23:41] <kriskowal> jbrantly, you might run a proposal by commonjs
[23:41] <kriskowal> there are several camps on the async issue
[23:42] <kriskowal> callbacks only, thenables, and Q
[23:42] <jbrantly> kriskowal: Q?
[23:42] <kriskowal> Promises/B is the Q API
[23:43] <dmachi> yeah doh is still dojo.deferred based, though we have a promise impl over in dojo now too.
[23:43] <dmachi> but seems still to be some shakeout on which people will adopt
[23:43] <kriskowal> presumably Promises/A ("thenables")
[23:44] <kriskowal> eugene mentioned that dojo had already proceeded significantly down the Promises/A route
[23:44] <dmachi> yeah
[23:45] <dmachi> though i think since we provide back compatibility its fairly straight foward to adjust (aside from getting the community to keep adjusting...active users and all )
[23:45] <kriskowal> aye
[23:45] <jbrantly> it seems that any async unit testing proposal will require changes to assert.* since they throw right now
[23:47] <jbrantly> what I mean by that is the "logger" mechanism. Which I guess wouldn't change any assert.* APIs or even unit tests. Should be transparent.
[23:47] <dmachi> hmm, thats how dojo works (doh.assert* throws), but deferreds made that pretty easy to handle, i'm not all that experienced with promises yet but presumably we can handle that as well
[23:48] <kriskowal> jbrantly, i see what you're saying.
[23:48] <kriskowal> catch blocks won't catch in future turns
[23:49] <jbrantly> exactly
[23:49] <kriskowal> returned rejections would work fine.
[23:49] <kriskowal> tricky.
[23:49] <kriskowal> and logged errors would work fine. take a look at narwhal's version of assert.
[23:50] <kriskowal> it passes a child of the assert module into each test runner as a logging assertion system
[23:50] <kriskowal> that was one of the other things we deferred in the unit test discussion
[23:50] <kriskowal> how to support both fail-early and fail-log assertions
[23:51] <jbrantly> which would change the behavior of assert.*, no? fail-long would mean no throwing
[23:51] <kriskowal> fail-log
[23:51] <kriskowal> aye
[23:51] <kriskowal> take a look; it's not a big change.
[23:51] <kriskowal> there's a logger implementation at the bottom.
[23:51] <kriskowal> and take a look at the "test" module too; that's where the Log is defined.
[23:55] <jbrantly> right
[23:55] <kriskowal> need to do some experiments with either callbacks or promises or both
[23:55] <kriskowal> but when it comes time to argue about async testing, that's the direction i'm looking to go
[23:56] <kriskowal> need to vet the callback approach since that's the most likely common ground; people can do whatever on top of a solid callback system
[23:56] <jbrantly> I'll put some thought into it and maybe throw something up. QUnit's approach seems simple enough.

 

 

Logs by date :