00:09:31  * mikealquit (Quit: Leaving.)
00:14:09  * mikealjoined
00:29:05  * bnoordhuisjoined
00:30:13  * joeandaverdequit (Ping timeout: 240 seconds)
00:36:12  * txdvquit (Read error: Connection reset by peer)
01:04:55  * mikealquit (Quit: Leaving.)
01:13:55  * joeandaverdejoined
01:34:25  * mikealjoined
01:39:55  * abraxasjoined
01:47:06  * bnoordhuisquit (Read error: Operation timed out)
01:50:46  * mikealquit (Quit: Leaving.)
01:51:48  * beachdogjoined
01:54:11  * mikealjoined
02:08:03  * joeandaverdequit (Ping timeout: 255 seconds)
02:08:18  * blackorzarjoined
02:08:38  <tjfontaine>mitsuhiko: and that method is deprecated in mountain lion
02:18:28  * dshaw_joined
02:20:47  * AvianFluquit (Quit: Leaving)
02:21:38  * mmaleckichanged nick to mmalecki[zzz]
02:33:16  * ericktjoined
02:42:43  * brsonquit (Ping timeout: 255 seconds)
02:54:14  * avalanche123quit (Read error: Connection reset by peer)
02:54:58  * dshaw_1joined
02:56:41  * dshaw_quit (Ping timeout: 244 seconds)
02:57:09  * ericktquit (Quit: erickt)
02:59:06  * avalanche123joined
03:20:22  * avalanche123quit (Quit: Computer has gone to sleep.)
03:21:31  * avalanche123joined
03:21:33  * blackorzarquit (Ping timeout: 240 seconds)
03:41:31  * blackorzarjoined
04:04:27  * joeandaverdejoined
04:06:08  * avalanche123quit (Quit: Computer has gone to sleep.)
04:14:29  * ericktjoined
04:23:19  * joeandaverdepart ("Leaving")
04:29:42  * mikealquit (Quit: Leaving.)
05:33:46  * AvianFlujoined
05:56:53  * mikealjoined
06:00:46  * mikealquit (Client Quit)
06:01:41  * dshaw_1quit (Ping timeout: 255 seconds)
06:02:50  * ericktquit (Quit: erickt)
06:32:54  * mikealjoined
06:38:10  * paddybyersjoined
07:10:58  * `3rdEdenjoined
07:13:43  * txdvjoined
07:19:09  * rendarjoined
07:28:54  * mikealquit (Quit: Leaving.)
07:34:22  * `3rdEdenquit (Quit: Leaving...)
07:34:47  * `3rdEdenjoined
07:49:10  * isaacstopic: Liber. Uni. Veloci. http://piscisaureus.no.de/libuv/latest
07:52:24  * mmalecki[zzz]changed nick to mmalecki
08:22:19  * mikealjoined
08:24:13  * blackorzarquit (Ping timeout: 240 seconds)
08:41:49  * dshaw_joined
08:53:37  * piscisaureus_joined
08:54:06  <piscisaureus_>hello
08:54:38  <mmalecki>hi
08:57:00  <mitsuhiko>tjfontaine: our yearly depreaction warning give us apple
08:57:20  <mitsuhiko>tjfontaine: do we have to do objective c now?
08:58:50  <piscisaureus_>git clone http://git.chromium.org/external/gyp.git
08:58:57  <piscisaureus_>google is maintaining proper git mirrors now
08:59:04  <piscisaureus_>I think chromium is switching to git \o/
09:01:42  <CIA-108>libuv: Bert Belder v0.8 * r1d5eb91 / test/test-tcp-unexpected-read.c : Avoid compiler warning - http://git.io/ZX5coA
09:03:34  * travis-cijoined
09:03:35  <travis-ci>[travis-ci] joyent/libuv#504 (v0.8 - 1d5eb91 : Bert Belder): The build is still failing.
09:03:35  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/4fe1916926f9...1d5eb9147429
09:03:35  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1988974
09:03:35  * travis-cipart
09:11:09  <ryah>piscisaureus_: really?
09:11:10  <ryah>nice
09:13:58  <piscisaureus_>ryah: I'm not sure, but in some issue they were mentioning setting their svn to read only
09:14:22  <piscisaureus_>(and they are doing crazy shit with git filter branch... srsly, why not just start a new repo if your old one gets too bit)
09:14:24  <piscisaureus_>*big
09:18:18  <mmalecki>hey guys, what do you think about this API? https://github.com/joyent/node/issues/3795
09:20:14  <piscisaureus_>mmalecki: I don't think you can do a pr for libuv... execSync is blocked on multi-loop signal handling support that bnoordhuis is now working on
09:20:36  * paddybyersquit (Quit: paddybyers)
09:20:39  <mmalecki>piscisaureus_: actually, why not just waitpid?
09:20:43  <piscisaureus_>mmalecki: wrt the api... I see the point but it makes it very inconsistent...
09:21:30  <piscisaureus_>mmalecki: node needs to consume the processes output, so waitpid won't help
09:21:50  <piscisaureus_>mmalecki: if node doesn't read from the pipe and the child tries to write, it'll deadlock
09:22:32  <mmalecki>piscisaureus_: ah, I see. so waitpid is no go. what's inconsitent in the API?
09:22:42  <piscisaureus_>mmalecki: wait() is
09:23:13  <piscisaureus_>maybe you can convince isaacs, api consistency doesn't seem to bother him so much
09:23:36  <mmalecki>okay, thanks for the input
09:24:06  <piscisaureus_>mmalecki: we could also do:
09:24:07  <piscisaureus_>var x = socket.write("bla");
09:24:07  <piscisaureus_>x.wait();
09:24:07  <piscisaureus_>but we don't :-)
09:24:35  <mmalecki>piscisaureus_: ah, so you want to make it consistent with stream APIs?
09:24:46  <piscisaureus_>mmalecki: that's why I like execSync() better
09:25:06  <mmalecki>right, that's fair enough
09:42:30  * dominictarrjoined
09:43:18  * paddybyersjoined
10:01:58  <piscisaureus_>ouch
10:02:06  <piscisaureus_>src/win/fs.c is full of leaks
10:22:39  * V1joined
10:22:46  * V1quit (Client Quit)
10:37:27  * hzjoined
10:40:31  <piscisaureus_>is anyone using the uv_fs_t.path field ?
10:40:35  <piscisaureus_>I want to make that private
10:40:40  <piscisaureus_>creationix: ^ ?
10:44:19  <saghul>piscisaureus_ i think I'm exposing that
10:44:22  <saghul>let me check
10:46:01  <saghul>yes, I'm exposing it in the operation callbacks, though I don't mind if you remove it
10:46:28  <piscisaureus_>Yeah... I suppose I'll have to keep it around in 0.8 anyway, since we can't break binary compatibility
10:46:33  <piscisaureus_>it's also not that bad to capture it
10:47:00  <piscisaureus_>but what I typically do is convert it to utf16 immediately, so libuv itself has no need to keep the original path
10:47:26  <saghul>i see
10:48:10  <piscisaureus_>And I have to plug many leaks, better do it properly this time :_)
10:55:42  * beachdogquit (Remote host closed the connection)
11:27:16  * theColejoined
11:28:10  <mitsuhiko>piscisaureus_: +1 on getting rid of that
11:35:09  * hzquit (Ping timeout: 272 seconds)
11:52:27  * bnoordhuisjoined
11:55:21  * charlies_joined
11:56:45  * charlies_changed nick to charliesome_
12:10:47  * pfox__quit (Quit: leaving)
12:11:54  * pfox__joined
12:22:39  <bnoordhuis>piscisaureus_: can 5342bac4 be moved into uv-win.h?
12:22:59  <bnoordhuis>that's the ssize_t define in uv.h
12:23:08  <piscisaureus_>!GH 5342bac4
12:23:16  <piscisaureus_>hmm how did that work again...
12:23:37  <piscisaureus_>bnoordhuis: probably not
12:24:04  <piscisaureus_>bnoordhuis: typedef void (*uv_read_cb)(uv_stream_t* stream, ssize_t nread, uv_buf_t buf);
12:24:13  <piscisaureus_>bnoordhuis: that needs ssize_t before we include uv.h
12:24:47  <bnoordhuis>piscisaureus_: but that's way after uv-win.h is included
12:25:21  <piscisaureus_>true
12:25:31  <piscisaureus_>Yeah, it seems that that'd be fine
12:25:39  <piscisaureus_>I wonder why we put it in uv.h in the first place then
12:25:47  <bnoordhuis>s/we/you/ :)
12:25:58  <piscisaureus_>bnoordhuis: we = me + ryah
12:25:59  <bnoordhuis>i'll move it and let you review it
12:26:45  <mmalecki>piscisaureus_: !gh joyent/libuv@5342bac4
12:26:50  <mmalecki>!gh joyent/libuv@5342bac4
12:26:50  <kohai>mmalecki, https://github.com/joyent/libuv/commit/5342bac4
12:28:22  <bnoordhuis>!gh bnoordhuis/libuv@4eccb2e
12:28:34  <bnoordhuis>c'mon kohai
12:28:47  <mmalecki>now that's interesting...
12:28:55  <bnoordhuis>piscisaureus_: https://github.com/bnoordhuis/libuv/commit/4eccb2e
12:29:00  <mmalecki>kohai: stupid bot?
12:29:00  <kohai>'Bot' is a derogatory term, and I'm offended.
12:29:29  <piscisaureus_>kohai: stupid african american
12:29:30  <kohai>I am Kohai, semi-useful communications-facilitating pseudointelligence!
12:29:54  <piscisaureus_>african american is not a derogatory term, apparently
12:30:05  <piscisaureus_>bnoordhuis: well review after I plug these leaks
12:30:13  <mmalecki>there goes the foolproofness of multiprocess architecture...
12:30:31  <piscisaureus_>kohai: stfu!
12:30:37  <kohai>I am Kohai, semi-useful communications-facilitating pseudointelligence!
12:30:45  <mmalecki>!gh joyent/node#1
12:30:45  <kohai>mmalecki, https://github.com/joyent/node/issues/1
12:30:54  <mmalecki>actually, bnoordhuis, you might be not-authed
12:31:06  <piscisaureus_>!gh joyent/node#0
12:31:15  <piscisaureus_>do it, kohai!
12:31:18  <mmalecki>(and yeah, kohai needs a total refactor)
12:31:24  <mmalecki>why are you speaking in color, sir?
12:31:25  <piscisaureus_>it's not even working
12:31:33  <piscisaureus_>I like grey
12:31:37  <mmalecki>lol ok
12:31:58  <piscisaureus_>,01aaaaa
12:32:01  <piscisaureus_>,01aaaa
12:32:14  <piscisaureus_>trillian is really buggy
12:32:35  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
12:33:11  * piscisaureus_joined
12:33:20  <piscisaureus_>maybe it's sane again now
12:33:59  <piscisaureus_>!gh joyent/node#1
12:33:59  <kohai>piscisaureus_, https://github.com/joyent/node/issues/1
12:34:02  <piscisaureus_>!gh joyent/node#0
12:34:03  <kohai>piscisaureus_, https://github.com/joyent/node/issues/0
12:34:24  <piscisaureus_>!gh joyent/node@xyzabc
12:34:24  <kohai>piscisaureus_, https://github.com/joyent/node
12:34:33  <piscisaureus_>!gh x
12:34:33  <kohai>piscisaureus_, https://github.com/x
12:34:45  <piscisaureus_>!gh \x1f
12:34:45  <kohai>piscisaureus_, https://github.com/x1f
12:35:12  <piscisaureus_>I don't think kohai needs a refactor
12:35:17  <piscisaureus_>it's like 3 regexes
12:35:46  <mmalecki>piscisaureus_: architectural refactor. with hook.io it sometimes gets up to 600 MB of memory usage. I find it pretty sad.
12:36:00  <piscisaureus_>wut?
12:36:47  <mmalecki>yeah, lol. it's an older version of hook.io tho, I think newer ones are not affected
12:37:14  <piscisaureus_>mmalecki: but c'mon, this bot does nothing
12:37:42  <piscisaureus_>it replaces, '!gh ' by http://github.com
12:37:52  <mmalecki>piscisaureus_: well, it also gives beers to people!
12:37:56  <piscisaureus_>and @ becomes /commit/ and # becomes /issues/
12:38:14  <piscisaureus_>wow
12:38:26  <mmalecki>!insult kohai
12:38:26  <kohai>kohai is like one of those callbacks that just won't fire.
12:38:32  <mmalecki>does that too
12:39:36  <piscisaureus_>var m = /(\w+)\+\+/.exec(s)
12:39:36  <piscisaureus_>if (m) {
12:39:36  <piscisaureus_> beers[m[1]] = 1 + (beers[m[1]] || 0)
12:39:36  <piscisaureus_> irc.say(chan, m[1] + ' has ' + beers[m[1]] + ' beers!');
12:39:36  <piscisaureus_>}
12:39:53  <piscisaureus_>mmalecki: wow, yoy need 5 lines to maintain beers :-p
12:39:57  <mmalecki>lol
12:40:12  <`3rdEden>but it's webscale
12:42:41  * beachdogjoined
12:42:51  <piscisaureus_>your mum's butt is webscale
12:43:05  <bnoordhuis>hah, what?
12:43:13  * piscisaureus_practicing his troll skills
12:43:20  <bnoordhuis>you're away for a couple of minutes and the discussion degrades immediately
12:44:13  <mmalecki>piscisaureus_: actually, I want kohai to do some devops tasks too
12:44:32  <mmalecki>I used to build microbots for that, 100 lines at max
12:45:15  <piscisaureus_>bnoordhuis: ha! I remember this too well -> http://piscisaureus.no.de/libuv/2012-02-03#23:08:49.296
12:45:41  <bnoordhuis>heh, okay - touche
12:45:55  <piscisaureus_>mmalecki: I want it to get the newspaper from the post box. Can you do that?
12:46:08  <piscisaureus_>er, mailbox :-)
12:46:29  <`3rdEden>tsss
12:47:14  <mmalecki>piscisaureus_: dunno, do you still read paper newspapers?
12:47:34  <piscisaureus_>mmalecki: no I need them to light up the fireplace
12:47:46  <piscisaureus_>mmalecki: although I'm slowly moving over to bank notes
12:48:16  <mmalecki>piscisaureus_: yeah, they light up pretty quickly. I have nothing to do with them anyway
13:14:22  * mmaleckichanged nick to mmalecki[food]
13:46:59  <piscisaureus_>bnoordhuis: are people supposed to call uv_fs_cleanup after calling a sync uv_fs function?
13:47:43  <bnoordhuis>piscisaureus_: i guess the answer is yes
13:47:48  <piscisaureus_>ok, cool
13:52:28  * ericktjoined
14:05:02  * ericktquit (Quit: erickt)
14:07:06  * charliesome_quit (Quit: Textual IRC Client: www.textualapp.com)
14:08:15  <bnoordhuis>hrm
14:08:42  <bnoordhuis>it's getting pretty hard these days to build a slimmed down kernel that actually boots up a distro
14:12:06  * AvianFluquit (Quit: This computer has gone to sleep)
14:13:20  <piscisaureus_>bnoordhuis: huh, what do you want?
14:14:02  <piscisaureus_>bnoordhuis: maybe you can try to compile with -fno-empty-for-loops
14:15:14  <piscisaureus_>This would be good for april first
14:15:38  <piscisaureus_>-fhide-gpl-violations: obfuscate generated code to hide the fact that we're using gnu code
14:17:18  <piscisaureus_>-fvegetarian: fill unallocated memory with 0xDEADl34F instead of 0xDEADBEEF
14:19:36  * c4milojoined
14:21:18  * abraxasquit (Remote host closed the connection)
14:25:44  * blackorzarjoined
14:47:50  <piscisaureus_>bnoordhuis: hey
14:48:09  <bnoordhuis>piscisaureus_: ho
14:48:14  <bnoordhuis>have you lgtm'd https://github.com/bnoordhuis/libuv/commit/4eccb2e already?
14:48:39  <piscisaureus_>bnoordhuis: on unix, if a node process has no (valid) fd 0, 1, or 2, will uv_spawn succeed ?
14:48:53  <piscisaureus_>bnoordhuis: when inherit is specified that is
14:49:50  <piscisaureus_>bnoordhuis: https://github.com/joyent/node/issues/3779 <-- that happens because the parent proces has no valid stdio :-(
14:50:13  <bnoordhuis>piscisaureus_: dunno. valid 0-2 fds is not required for execve() to succeed
14:50:21  <piscisaureus_>bnoordhuis: I mean, in libuv
14:50:29  <bnoordhuis>i'd have to check that
14:51:05  <piscisaureus_>bnoordhuis: I am considering to just ignore these errors and make spawn succeed
14:51:18  <piscisaureus_>maybe only for fd 0-2
14:51:41  <piscisaureus_>so if you'd specify to inherit fd 55 and it doesn't exist, it would fail anyway
14:52:30  <piscisaureus_>or we could make node set up some dummy stdin when it is started without stdin
14:52:47  <bnoordhuis>piscisaureus_: checked, it's going to fail
14:53:05  <bnoordhuis>when UV_INHERIT_FD is set, that is
14:53:11  <piscisaureus_>yeah, I see
14:56:58  <piscisaureus_>Delegating to redmond: https://github.com/joyent/node/issues/3779#issuecomment-7370643
14:59:36  * mmalecki[food]changed nick to mmalecki
15:01:38  <bnoordhuis>hah
15:02:48  <isaacs>g'morning
15:03:05  <bnoordhuis>g'afternoon
15:06:03  * pieternjoined
15:09:43  * dshaw_quit (Quit: Leaving.)
15:10:27  * dapjoined
15:12:40  * AvianFlujoined
15:14:27  * blackorzar_joined
15:17:03  * blackorzarquit (Ping timeout: 244 seconds)
15:17:45  * kujoined
15:23:07  * chobi_e_changed nick to chobi_e
15:23:57  * dapquit (Quit: Leaving.)
15:31:29  <CIA-108>node: isaacs v0.8 * rb3cf3f3 / (6 files in 3 dirs): Report errors properly from --eval and stdin - http://git.io/JFvDtw
15:39:09  <creationix>for my car? http://www.myplates.com/Images/Plates/PLPC207?plateText=NODEJS
15:40:33  <isaacs>piscisaureus_, bnoordhuis: How would you feel about exposing either a) the fd, or b) some arbitrary unique int on uv streams?
15:40:34  * `3rdEdenquit (Quit: meh)
15:41:57  <bnoordhuis>isaacs: i know why you ask but i see no compelling reason to
15:42:08  <bnoordhuis>besides, there's no such thing as the fd on windows
15:43:30  <dominictarr>creationix, do it
15:44:09  <isaacs>bnoordhuis: well, why i ask is for dtrace scripts to grab ahold of something.
15:44:42  <isaacs>they can use remoteHost:remotePort, but that's a string, and a little less awesome to compare against.
15:44:50  <bnoordhuis>isaacs: yes, dap asked about that. he should use a monotonic counter
15:45:34  <creationix>dominictarr, ooh, or the green recycle themed one. software is all about reusing bits after all.
15:45:36  <isaacs>so just slap his own numeric thing on each request? why can't node/libuv do that?
15:46:29  <bnoordhuis>isaacs: why should node/libuv do that?
15:46:47  <bnoordhuis>it's useless except for this very specific use case
15:47:09  <isaacs>"it's useless except for this use case"
15:47:11  <isaacs>;P
15:47:19  <tjfontaine>a use case that only applies to smartos :)
15:47:47  <bnoordhuis>exactly. i stress the 'very specific' bit
15:48:01  <isaacs>tjfontaine: well, it applies to all illumos variants, but yes. it could also apply to os x, if people were using that.
15:48:27  <isaacs>ie, it's not dependent on the ustack helper bits
15:48:43  <mmalecki>isaacs: I'm definitely +1 on that, I had a hard time tracking those in my dtrace scripts
15:49:20  <isaacs>iow, it's not just for joyent cloud analytics, it's for anyone writing dtrace scripts who wants to track latency of the http request/response cycle
15:49:57  <piscisaureus_>I don't really see the merit of it
15:50:06  <piscisaureus_>can't use use the _handle pointer?
15:51:43  <bnoordhuis>or monkey-patch lib/net.js
15:52:21  <bnoordhuis>there's enough cruft in there already that at some time was considered a good idea
15:52:42  <bnoordhuis>i don't particularly want to pile on more
15:53:21  * stephankjoined
15:53:35  <isaacs>k, thanks for the feedback. dap's offline atm. i'll suggest that.
15:54:16  <mmalecki>monkey-punching lib/net.js doesn't sound like a long-term solution
15:54:39  <isaacs>yeah, the _handle pointer sounds like it should be just as unique and avoids the string comparison
15:55:05  <dominictarr>I don't know, the texas one you linked is pretty bad ass.
15:55:12  <mmalecki>yeah, at least as unique as fd
15:55:39  <dominictarr>creationix, the recycling one would be more appealing if you where from a less ass kicking state.
15:57:05  <piscisaureus_>bnoordhuis: https://docs.google.com/a/c9.io/document/d/1QbEyALWdI0YPagdlg50rHh_rl6_bZr5wZK3yjrkHKco/edit <-- what do we pick?
16:00:19  <bnoordhuis>god, google accounts is so annoying (when you have more than one account)
16:01:43  <piscisaureus_>you can merge them tho
16:03:19  <bnoordhuis>hmm, historic figures... team goebbels has a certain ring to it, not sure if fabian will appreciate that though
16:03:26  <bnoordhuis>you know how touchy germans are about the war
16:03:41  <isaacs>what's this for?
16:03:56  <bnoordhuis>c9 team names
16:04:15  <bnoordhuis>piscisaureus_: were you the one that proposed famous delft university figures?
16:04:36  <piscisaureus_>bnoordhuis: sure
16:04:42  <piscisaureus_>bnoordhuis: just trolling lennart en zef
16:06:15  <bnoordhuis>piscisaureus_: Famous Belgian politicians from the early 60s. <- ho ho
16:06:38  <piscisaureus_>bnoordhuis: I like the uuids better
16:18:46  <CIA-108>libuv: Ben Noordhuis master * r4eccb2e / (include/uv-private/uv-win.h include/uv.h): include: move ssize_t workaround to uv-win.h - http://git.io/UlU5Vg
16:18:55  <piscisaureus_>bnoordhuis: did you test it?
16:19:34  <bnoordhuis>piscisaureus_: yes, insofar that mingw doesn't choke on that particular bit
16:19:57  <piscisaureus_>bnoordhuis: so, the answer is no :-)
16:20:01  <piscisaureus_>where does it choke btw
16:20:30  <bnoordhuis>piscisaureus_: lots of things, want a gist or an issue?
16:20:40  * travis-cijoined
16:20:40  <travis-ci>[travis-ci] joyent/libuv#505 (master - 4eccb2e : Ben Noordhuis): The build is still failing.
16:20:40  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/be1032431d50...4eccb2ee525d
16:20:40  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1992167
16:20:40  * travis-cipart
16:20:42  <piscisaureus_>bnoordhuis: a gist
16:21:07  <bnoordhuis>src/win/error.c: In function �uv_translate_sys_error�:
16:21:07  <bnoordhuis>src/win/error.c:115:10: error: �ERROR_SYMLINK_NOT_SUPPORTED� undeclared (first use in this function)
16:21:07  <bnoordhuis>src/win/error.c:115:10: note: each undeclared identifier is reported only once for each function it appears in
16:21:09  <bnoordhuis>^ the main one
16:21:53  <piscisaureus_>ah
16:21:56  <piscisaureus_>will fix
16:22:01  <bnoordhuis>however
16:22:05  * bnoordhuiscreates gist
16:22:25  <bnoordhuis>piscisaureus_: https://gist.github.com/2697ffe2de1b913b954b
16:22:31  <piscisaureus_>#ifndef ERROR_SYMLINK_NOT_SUPPORTED
16:22:31  <piscisaureus_>#define ERROR_SYMLINK_NOT_SUPPORTED 1464L
16:22:31  <piscisaureus_>#endif
16:22:31  <piscisaureus_>^-- add to winapi.h
16:22:45  <piscisaureus_>ah
16:22:50  <piscisaureus_>only that :-)
16:22:51  <piscisaureus_>good
16:23:45  <bnoordhuis>out for a walk, biab
16:23:49  <piscisaureus_>ERROR_SXS_CANT_GEN_ACTCTX
16:35:44  <creationix>isaacs, ok, two questions about readable-stream?
16:35:54  <creationix>so I see you have (n) bytes in read
16:36:06  <creationix>does it wait for n bytes or return partial responses?
16:37:24  <creationix>also, I see that you require end to be on another tick from the read call (after read returns)
16:37:34  <creationix>I see why, but then all streams are forces to use multiple ticks
16:37:38  <creationix>*forced
16:38:45  <creationix>I guess now that nextTick is faster, that's ok
16:43:51  <creationix>isaacs, I'm going to assume that the (n) in read(n) is an optional maxBytes like we discussed before. (if left out, returns all bytes available, if specefied, will slice the bytes if they are bigger than the requested size).
16:44:27  <creationix>so only question left is what happens where there is more data (two chunks and no n) or (one large chunk larger than n)
16:44:43  <creationix>will it emit "readable" on nextTick and expect you to call read again?
16:45:25  <creationix>or assume you'll call read in a loop and never emit "readable"?
16:46:41  * stagasjoined
16:48:44  * mmaleckichanged nick to mmalecki[away]
16:51:30  * EhevuTovjoined
16:56:08  * EhevuTov_joined
16:59:12  * EhevuTovquit (Ping timeout: 240 seconds)
17:03:40  * ericktjoined
17:05:54  <isaacs>creationix: it returns whatever it has if it doesn't have n bytes
17:06:06  <isaacs>creationix: nextTick is immediate, yes.
17:06:28  * dshaw_joined
17:06:31  <isaacs>creationix: it only emits 'readable' when it *becomes* readable.
17:06:37  <isaacs>(that's a SHOULD, not a MUST, imo)
17:06:48  <isaacs>creationix: so, if you don't consume all the bytes, it won't ever emit 'readable'
17:06:56  <isaacs>just like, if write() never returns false, it'll never emit 'drain'
17:07:06  <isaacs>otherwise you'd be emitting 'drain' with every write() call
17:07:09  <isaacs>which is silly
17:07:25  * mikealquit (Quit: Leaving.)
17:08:16  <isaacs>creationix: also, it's somewhat tbd what read(undefined) returns - ie, should it return the full buffer always? or maybe just this.buffer[0]?
17:08:28  <isaacs>i'm tempted to say that it's up to the implementation.
17:08:50  <isaacs>ie, it MAY return up to n bytes, or any number of bytes > 0 if n is not specified.
17:08:59  <isaacs>if it returns null, then it MUST emit'readable' when more bytes are available.
17:09:05  <isaacs>but beyond that, whatever.
17:09:27  <creationix>right, but the important thing is how does a consumer safely read the data
17:09:45  <creationix>while (data = stream.read()) { /* handle data */ }
17:09:49  <creationix>is that while loop required?
17:10:01  <isaacs>yes.
17:10:33  <creationix>and supposing I'm writing a protocol parser, I really want read(n, callback(err, bytes) since I can't do anything till I have n bytes
17:10:42  <creationix>but that can be layered on top easy enough
17:10:53  <isaacs>eeew
17:10:54  * TooTallNatejoined
17:11:06  <isaacs>what happens if that many bytes never come in? you call the cb on end as well?
17:11:12  <isaacs>call read() multiple times until it fills up?
17:11:33  <creationix>well, if an end happens while waiting for bytes, then emit an error
17:11:49  <creationix>or if the connection just died, then it will be a timeout error of some sort
17:11:55  <isaacs>or just emit what you've got maybe.
17:11:56  <creationix>either way, there will eventually be n bytes or error
17:11:58  <isaacs>or zero-fill
17:12:10  <isaacs>i mean, i do thi now with block-stream, primarily for parsing tarballs
17:12:12  <creationix>for protocol parsing, I only want valid data
17:12:32  <creationix>i guess in some cases I would want the partial data for error reporting or recovery
17:12:33  <isaacs>so that i only ever get 512-byte data chunks
17:13:15  * dshaw_quit (Quit: Leaving.)
17:13:42  <creationix>either way, this doesn't belong in the spec or core
17:13:51  <creationix>it's easy enough to wrap this on top of your interface
17:14:03  <creationix>the (n) arg makes it a lot easier
17:16:57  <CIA-108>node: Shigeki Ohtsu v0.8 * r5b37da2 / doc/api/domain.markdown : doc: fix domains example - http://git.io/lHWeLQ
17:19:05  <isaacs>creationix: agreed
17:19:27  <creationix>isaacs, i think the new api is ok, and it looks like it has an easy upgrade path
17:19:39  <creationix>only experience will tell for sure
17:19:44  <isaacs>yep
17:19:49  <piscisaureus_>hmm
17:19:51  <isaacs>i've been playing with it in a few little stream programs i have.
17:19:58  <creationix>I'll have to change how I do proxy streams in vfs
17:20:01  <piscisaureus_>can we not publish a module first and tell people to use that?
17:20:21  <isaacs>piscisaureus_: it is published ;) npm install readable-stream
17:20:23  <txdv>the signature of uv_unref changed from uv_loop to uv_handle
17:20:30  <piscisaureus_>yes
17:21:07  <creationix>isaacs, so the vfs case is I want to call vfs.readfile(path, options, callback), and callback has a readable stream (it's like vfs-createReadStream)
17:21:09  <isaacs>piscisaureus_: but i'm also going to experiment on a branch with making our stream impls use this, just to see how it is.
17:21:15  <creationix>but the stream source can be on a remote machine
17:21:42  <creationix>can't make sync calls like .read since it's over async rpc
17:22:05  <isaacs>creationix: you can override _read(n, cb) and let it handle buffering for you
17:22:21  <isaacs>creationix: ie, the same code that's going to be used for fs read streams, and libuv tcp streams, will be available for you to us
17:22:24  <isaacs>e
17:22:39  <creationix>of course, I can make it work. I'd just rather not have to wrap streams explicitly
17:22:43  * mikealjoined
17:23:05  <creationix>.read([maxBytes], callback(err, data){}) would work without modifications since my rpc supports one-shot callbacks
17:23:06  <isaacs>creationix: well, vfs.ReadStream can inherit from Readable, and override the _read() method
17:23:27  <isaacs>creationix: just spell it _read instead of read, and you get the Readable API for free.
17:23:42  <creationix>I only control the transport, the api and the caller are both users of my code
17:23:56  <creationix>so I need to wrap stock streams and present them as stock streams
17:24:00  <isaacs>creationix: what do they do now, .on('data')?
17:24:15  <isaacs>creationix: or .pipe(dest)?
17:24:18  <isaacs>some mix of the two?
17:24:30  <creationix>isaacs, https://github.com/c9/vfs/blob/master/socket/consumer.js#L99-156
17:24:43  <creationix>the rpc only supports one-shot callbacks (to prevent memory leaks)
17:24:52  <creationix>dnode "fixed" the memory leak by using harmony proxies
17:24:56  <creationix>I'm not willing to require harmony
17:25:04  <creationix>err, not proxies, webkmaps
17:25:07  <creationix>*weakmaps
17:25:22  <isaacs>arggg. right. we DO have to set those stupid @!#$! boolean flags.
17:25:24  <isaacs>oh well.
17:26:04  <isaacs>creationix: i think this will still work just fine
17:26:15  <creationix>but basically I add .write(streamId, chunk), end(streamId), onData(streamId, chunk), etc to both sides of the rpc channel
17:26:17  <isaacs>creationix: if you add a 'data' listener, it switches into old-stream auto-reading mode.
17:26:19  <creationix>and proxy everything manually
17:26:26  <isaacs>k
17:26:32  <creationix>yeah, it should work fine with the old interface
17:26:51  <creationix>I was just hoping to not need the layer on top of rpc to support streams
17:26:55  <isaacs>but, you can also refactor your own code to use the new interface, or expose a read(n) method or a _read(n, cb) method
17:27:07  <creationix>but that would require .read(bytes, callback) to be the main interface
17:27:17  * isaacsdoesn't grok your vfs problem enough to speak to that
17:27:23  <creationix>plus it would be slow, since the read request would take time to get from one end to the other
17:27:38  <isaacs>creationix: the problem is that read(bytes, callback) is really clunky to use for a lot of use cases.
17:27:56  <isaacs>creationix: but if you set a low water mark, and have _read(n, cb) filling up the buffer for you, who cares?
17:28:06  <creationix>isaacs, more clunks than on("readable", function () { stream.read()})
17:28:16  <isaacs>creationix: yes.
17:28:19  <creationix>isaacs, it's more traffic on the wire
17:28:29  <isaacs>creationix: why is it more traffic on the wire? it's exactly the same!
17:28:51  <isaacs>in fact, depending on how you set the low water mark and the buffer size, and the cost of framing, it might be less.
17:29:04  <creationix>currently, using the old stream api, caller sends readfile(path, callbackid) and then the provider send callbackId, streamID, followed by streamID, data
17:29:06  <creationix>all pipelined
17:29:32  <creationix>if I had to call read for each chunk, then the caller would send more than just the initial readfile
17:29:59  * isaacsnot getting why this is any different
17:30:15  <creationix>sorry for being confusing
17:30:21  <isaacs>:)
17:30:29  <creationix>basically the callback api I want doesn't work for my vfs use case
17:30:43  <creationix>it causes extra overhead
17:31:04  <creationix>but makes it less code for me to write
17:31:13  <creationix>so we plan to deprecate the old interface?
17:31:20  <isaacs>not any time terribly soon.
17:31:24  <isaacs>i mean, deprecate, but not remove
17:31:25  <creationix>if not, then I'm fine, the old way works fine for vfs
17:31:34  <creationix>I just have to buffer events manually in a few cases
17:31:46  <isaacs>there's way too much code to even consider removing on('data') any time this year.
17:32:05  <isaacs>creationix: ie, you can probably just leave everything as-is, and i'tll keep Just Working
17:32:19  <isaacs>creationix: since you've made it work with .on(data)
17:32:24  <creationix>even if I was forces to use .read() and "readable" I'd just wrap it
17:32:38  * brsonjoined
17:32:47  <creationix>I had to hack things up to get backpressure working correctly
17:32:54  <creationix>it's the rpc's own transport that really matters
17:33:01  <creationix>not the stream itself
17:33:28  <creationix>if the source can't write data to the tcp or websocket I'm using for rpc, then it doesn't matter what state the disk on the remote side is in
17:33:47  <creationix>I have to exert backpressure using the rpc transport
17:34:38  * dapjoined
17:35:37  <isaacs>creationix: wait, but doesn't the backpressure all just work by default, since you're going to be trying to write to a backed-up TCP stream if the consumer hasn't called read() yet?
17:35:52  <isaacs>ie, the write() returns false, and then you wait for 'drain', just like you do now
17:35:56  <isaacs>just as if it was paused
17:36:21  * mikealquit (Quit: Leaving.)
17:36:30  <creationix>I don't send drain events across the wire
17:36:41  <creationix>in effect I'm inserting a link inside the stream
17:36:50  <isaacs>no, you don't have to, but you stop calling write() when it returns false, right?
17:36:51  <isaacs>on the client
17:36:55  <creationix>so stream from A -> B becomes A -> RPC -> B
17:37:04  <isaacs>and RPC is some kind of TCP thing, yes?
17:37:13  <creationix>RPC is over some sort of socket
17:37:15  <creationix>usually tcp
17:37:22  <isaacs>so it's a.pipe(rpc) and on the other end, it's rpc.pipe(b)
17:37:23  <creationix>can be pipe
17:37:32  <isaacs>k, same difference
17:37:36  * lohkeyjoined
17:37:56  <isaacs>so, a.pipe(rpc)~{{{internet}}}~rpc.pipe(b)
17:38:01  <creationix>except A and B are userspace inside the rpc worls
17:38:03  <creationix>*world
17:38:06  <creationix>they can't see the rpc
17:38:08  <isaacs>sure
17:38:26  <isaacs>the API you present is that you give me a writable stream, and i pipe (for example) an fs.readstream into it
17:38:39  <isaacs>a = fs.createReadStream(path); a.pipe(meta.stream)
17:38:59  <isaacs>meta.stream is an abstract writable stream that takes each chunk and sends it along the RPC wire
17:39:02  <isaacs>yes?
17:39:04  <creationix>vfs.mkfile(path, {stream: fs.createReadStream}, callback)
17:39:09  <creationix>for uploading a file
17:39:25  <isaacs>oh.. so the callback doesn't get a writable stream corresponding to the made file?
17:39:28  <creationix>or vfs.readfile(path, {}, function (err, meta) { meta.stream.pipe(foo) })
17:39:40  <creationix>isaacs, it used to, but I changed it
17:39:48  <creationix>make the API a lot harder to use
17:39:51  <creationix>*made
17:40:14  <isaacs>does vfs.mkfile(path,{},function(er,meta){foo.pipe(meta.stream)}) still work?
17:40:21  <isaacs>the docs seem to imply that it does..
17:40:35  <creationix>heh, need to update the docs
17:40:38  <creationix>it's a recent change
17:40:47  <creationix>not even sure c9.io is using the new api yet
17:40:50  * arlolrajoined
17:40:52  <isaacs>well, vfs.mkfile(path, {stream:foo}, cb) then?
17:40:57  <creationix>yep
17:41:00  <isaacs>and you do foo.pipe(RPCThingie)?
17:41:16  <isaacs>once you've sent the header yadda yadda?
17:41:19  <creationix>the docs are up-to-date https://github.com/c9/vfs/blob/master/example/test-child-streams.js
17:41:32  <creationix>no, I can't pipe to the rpc's transport
17:41:48  <creationix>it has to be encoded specially to multiplex with all the other data
17:41:55  <isaacs>how do you get the bytes from foo into the rpc socket?
17:42:03  <isaacs>vfs.mkfile(path, options, callback)
17:42:03  <isaacs>Saves a file stream to the vfs. Always first creates a tmp file and then renames for atomic writes.
17:42:06  <isaacs>There are no options for this function.
17:42:08  <isaacs>meta in the response can include:
17:42:11  <isaacs>meta.stream - a writable stream to the filesystem.
17:42:11  <creationix>vfs-socket does all the encoding and decoding
17:42:13  <isaacs>meta.tmpPath - the actual filepath of the tmpfile
17:42:15  <creationix>it's transparent
17:42:29  <isaacs>so why can't vfs-socket just give you a writable stream, if it's transparent?
17:42:39  <creationix>it can, and it used to
17:42:55  <creationix>but then the caller would have to buffer their input stream till I called their callback
17:43:03  <creationix>now I buffer internally and then call pipe internally
17:43:14  <creationix>and I don't call the callback till the file is fully saved and renamed
17:43:19  <creationix>it's much easier to use now
17:43:32  <isaacs>sure, it's an onComplete instead of a onStart
17:43:37  <isaacs>that's probably better.
17:43:45  <creationix>makes error handling a lot easier
17:43:49  <isaacs>but somewhere, you're calling .pipe(someKindOfStream)?
17:43:50  <creationix>all errors go to the same callback
17:43:53  <creationix>yes
17:43:53  <isaacs>or do you actually buffer all the data?
17:44:27  <creationix>https://github.com/c9/vfs/blob/master/local/localfs.js#L885
17:44:35  <creationix>everything is streaming in vfs
17:44:37  <creationix>even readdir
17:44:40  <isaacs>ok
17:44:50  <isaacs>(that's good, it's silly otherwise ;)
17:44:56  <creationix>since I multiplex all data over a single connection, large data chunks cause problems
17:45:19  <isaacs>creationix: ok, so, then this is actually better for you
17:45:59  <isaacs>creationix: assuming that the readable is a new-fangled read() style core read stream, you an do readable.bufferSize = 1024; readable.lowWaterMark=0; readable.pipe(stream)
17:46:11  <isaacs>creationix: and you'll never get a chunk bigger than 1024, or anything buffered unnecessarily
17:46:46  <creationix>right
17:46:48  <isaacs>and if the write() takes a while, then the readable will just not load any more bytes until you're ready for it
17:46:52  <creationix>64k chunks are kinda a problem
17:46:56  <isaacs>sure
17:47:03  <isaacs>1024 is probably excessively smal.
17:47:07  <isaacs>but you get the idea.
17:47:21  <creationix>yeah, the framing and rpc overhead is ~ 12bytes / chunk
17:47:24  <isaacs>smaller than blocksize is silly
17:48:07  <creationix>ideally I'll be just under the max tcp chunk size
17:48:25  <creationix>but that changes
17:51:25  * `3rdEdenjoined
17:55:17  <isaacs>sure
17:55:30  <isaacs>you can gradually increase it until write() starts returning false, even, then back off or do some other clever stuff
17:55:41  <isaacs>the point is, it's actually better this way :)
17:56:06  <isaacs>if there's a use case where it's *not* better for some reason, then we need to take a close look at that.
17:56:13  * xaqjoined
17:56:19  <isaacs>so far, piping to multiple dests is the only real pain point
17:58:56  * mikealjoined
18:02:57  <CIA-108>node: isaacs v0.8 * rf8dab6a / doc/api/child_process.markdown : doc: Remove timeout arg in child_process.fork - http://git.io/bS1U1Q
18:11:38  <creationix>well, in real physical plumbing, you don't pipe to one thing, and then add another
18:11:51  <creationix>you connect to a multi-join adapter and connect each of it's endpoints
18:12:05  <creationix>and you never re-pipe a live pipe (once the water is flowing)
18:15:10  * dshaw_joined
18:24:02  * mmalecki[away]changed nick to mmalecki
18:26:07  * TheJHjoined
18:26:20  * theColequit (Quit: theCole)
18:28:38  <dominictarr>creationix, granted, if where a plumber with a magical samuari sword that could cut off a pipe, and melt the cut together then you probably would.
18:29:10  <dominictarr>but I'm coming to agree about the tee adapter
18:29:45  <creationix>a tee tool isn't hard to write, just don't burden the core interface with supporting it
18:30:16  <dominictarr>no, isaacs has demonstrated that it's possible, and that is enough.
18:30:46  <dominictarr>or should that be yes, ...
18:31:01  <dominictarr>we agree
18:31:08  <dominictarr>oh, I get what you mean.
18:31:36  <dominictarr>with a tee pipe, you'd connect each fork at the same time.
18:33:23  <dominictarr>not "re-pipe a live pipe"... although, you could disconnect a branch, if you had a tap in the right place.
18:37:17  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
18:37:55  <CIA-108>libuv: Bert Belder winfs * r33bdd1b / (include/uv-private/uv-win.h include/uv.h src/win/fs.c): Windows: fix memory leaks in fs - http://git.io/Z8HLaw
18:38:01  * piscisaureus_joined
18:38:21  <piscisaureus_>bnoordhuis: ^-- review ?
18:38:39  * piscisaureus_quit (Client Quit)
18:40:11  * travis-cijoined
18:40:11  <travis-ci>[travis-ci] joyent/libuv#506 (winfs - 33bdd1b : Bert Belder): The build failed.
18:40:11  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/commit/33bdd1ba0c5a
18:40:11  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1993171
18:40:11  * travis-cipart
18:53:19  * EhevuTov_quit (Ping timeout: 250 seconds)
18:56:40  * stagas_joined
18:58:20  * EhevuTov_joined
18:59:22  * stagasquit (Ping timeout: 250 seconds)
18:59:33  * stagas_changed nick to stagas
19:03:10  * theColejoined
19:03:36  * theColequit (Client Quit)
19:03:46  * stagas_joined
19:05:26  * stagasquit (Ping timeout: 255 seconds)
19:05:55  * stagasjoined
19:08:12  * stagas_quit (Ping timeout: 240 seconds)
19:11:16  * EhevuTov_quit (Quit: Leaving)
19:18:44  * piscisaureus_joined
19:19:56  * `3rdEdenquit (Quit: Leaving...)
19:25:58  <piscisaureus_>aand baack
19:27:19  * brsonquit (Read error: Operation timed out)
19:28:23  * chobi_echanged nick to chobi_e_
19:34:31  * indexzerojoined
19:39:10  * `3rdEdenjoined
19:39:32  * arlolraquit (Quit: Linkinus - http://linkinus.com)
19:47:09  * indexzeroquit (Quit: indexzero)
19:57:30  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
20:07:16  * avalanche123joined
20:08:10  * indexzerojoined
20:17:14  * theColejoined
20:21:34  * theColequit (Client Quit)
20:30:11  * theColejoined
20:32:57  * theColequit (Client Quit)
20:35:03  * `3rdEdenquit (Quit: Zzzz gnite <3)
20:45:12  * kuquit (Quit: leaving)
20:49:14  * theColejoined
20:52:04  * pieternquit (Quit: pietern)
20:53:28  * theColequit (Client Quit)
20:59:40  * indexzeroquit (Quit: indexzero)
20:59:51  * loladirojoined
21:00:58  * pieternjoined
21:04:29  * loladiropart
21:05:02  * loladirojoined
21:08:40  * xaqquit (Remote host closed the connection)
21:09:07  * xaqjoined
21:10:25  * avalanche123quit (Quit: Computer has gone to sleep.)
21:11:00  * AlbireoXquit (Ping timeout: 240 seconds)
21:11:03  * xaq_joined
21:11:14  * AlbireoXjoined
21:13:02  * hzjoined
21:14:08  * xaqquit (Ping timeout: 250 seconds)
21:21:50  * xaq_quit (Read error: Connection reset by peer)
21:22:23  * xaqjoined
21:39:50  * theColejoined
21:40:24  * hzquit
21:44:22  * piscisaureus_joined
21:44:59  <piscisaureus_>bnoordhuis: sure
21:45:01  <piscisaureus_>?
21:48:38  <piscisaureus_>bnoordhuis: enum is practically always an int right?
21:48:48  <piscisaureus_>or is there anything I should know
21:49:47  <tjfontaine>I thought it was practically always uint
21:49:56  <tjfontaine>unless it hit a negative case
21:51:33  * dominictarrquit (Quit: Leaving)
21:52:15  <piscisaureus_>right, ok
21:52:19  <piscisaureus_>that doesn't matter here
21:52:30  <piscisaureus_>I was just curious if chaning an int for an enum was going to break teh ABI
21:52:34  <piscisaureus_>but I suppose that won't happen
21:53:47  * dominictarrjoined
21:53:54  <CIA-108>libuv: Bert Belder v0.8 * r73096da / (include/uv-private/uv-win.h include/uv.h src/win/fs.c): windows: fix memory leaks in fs - http://git.io/rxTndA
21:55:57  * travis-cijoined
21:55:57  <travis-ci>[travis-ci] joyent/libuv#507 (v0.8 - 73096da : Bert Belder): The build is still failing.
21:55:57  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/1d5eb9147429...73096da21b5c
21:55:57  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1994840
21:55:57  * travis-cipart
21:59:41  * brsonjoined
22:04:06  <CIA-108>libuv: Ben Noordhuis v0.8 * rc803c65 / (include/uv-private/uv-win.h include/uv.h): include: move ssize_t workaround to uv-win.h - http://git.io/3g4wqQ
22:04:06  <CIA-108>libuv: Bert Belder v0.8 * r7e6b335 / src/win/fs.c : windwos: remove unreachable code from fs.c - http://git.io/VvVgwA
22:04:06  <CIA-108>libuv: Bert Belder v0.8 * r81a9826 / include/uv.h : common: uv_fs_t.path should be constant - http://git.io/SNldnw
22:05:58  * travis-cijoined
22:05:59  <travis-ci>[travis-ci] joyent/libuv#508 (v0.8 - 81a9826 : Bert Belder): The build is still failing.
22:05:59  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/73096da21b5c...81a9826d79e0
22:05:59  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1994909
22:05:59  * travis-cipart
22:06:11  <piscisaureus_>crap
22:06:13  <piscisaureus_>typos
22:06:15  <CIA-108>libuv: Bert Belder v0.8 * r514265e / (include/uv-private/uv-win.h include/uv.h src/win/fs.c): windows: fix memory leaks in fs - http://git.io/bZFFKQ
22:06:15  <CIA-108>libuv: Ben Noordhuis v0.8 * r4168855 / (include/uv-private/uv-win.h include/uv.h): include: move ssize_t workaround to uv-win.h - http://git.io/it7ipQ
22:08:04  * travis-cijoined
22:08:04  <travis-ci>[travis-ci] joyent/libuv#509 (v0.8 - 4168855 : Ben Noordhuis): The build is still failing.
22:08:04  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/81a9826d79e0...4168855da57f
22:08:04  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1994922
22:08:04  * travis-cipart
22:09:20  <piscisaureus_>ok really time to head out now
22:09:26  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
22:12:58  * c4miloquit (Remote host closed the connection)
22:16:14  * mikealquit (Quit: Leaving.)
22:17:10  * paddybyersquit (Quit: paddybyers)
22:19:54  * mikealjoined
22:24:17  * brsonquit (Quit: leaving)
22:24:35  * brsonjoined
22:32:51  * loladiropart
22:32:59  * EhevuTovjoined
22:45:50  * piscisaureus_joined
22:59:53  * xaqquit (Remote host closed the connection)
23:00:20  * xaqjoined
23:04:13  * pieternquit (Quit: pietern)
23:11:54  * stagasquit (Quit: ChatZilla 0.9.88-rdmsoft [XULRunner])
23:12:43  * dshaw_1joined
23:13:31  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
23:14:09  * dshaw_quit (Ping timeout: 250 seconds)
23:14:52  * pieternjoined
23:18:58  * avalanche123joined
23:21:47  * xaqquit (Ping timeout: 260 seconds)
23:25:47  * theColequit (Quit: theCole)
23:28:21  * theColejoined
23:33:25  <CIA-108>libuv: Alan Gutierrez master * r8f66bfc / README.md : doc: add 'Intro to libuv' link to README - http://git.io/5QSKvw
23:35:21  * travis-cijoined
23:35:21  <travis-ci>[travis-ci] joyent/libuv#510 (master - 8f66bfc : Alan Gutierrez): The build is still failing.
23:35:21  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/4eccb2ee525d...8f66bfcee05f
23:35:21  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1995353
23:35:21  * travis-cipart
23:40:05  * mikealquit (Quit: Leaving.)
23:51:27  * scizojoined
23:51:49  <scizo>Does the build system support building a dynamic library?
23:53:55  <scizo>I looked around the Makefile and it looks like it only supports making a libuv.a. I wanted to ask and make sure though.
23:54:14  <scizo>Thanks in advance for any help.
23:56:07  * rendarquit