12:18:22  <piscisaureus_>bnoordhuis: hey
12:18:39  <bnoordhuis>piscisaureus_: ho
12:18:51  <piscisaureus_>bnoordhuis: ok je bent thuis :-)
12:18:54  <bnoordhuis>jep
12:18:58  <bnoordhuis>kom morgen wel langs
12:19:07  <piscisaureus_>hmm
12:19:16  <piscisaureus_>bnoordhuis: morgen ga ik op tijd weg
12:19:22  <bnoordhuis>ah okee
12:19:26  <bnoordhuis>maandag of dinsdag dan
12:19:29  <piscisaureus_>dwz 6 uur oid
12:19:43  <AndreasMadsen>piscisaureus_: morning could you add "review disconnect patch" to your todo list :)
12:20:06  <piscisaureus_>AndreasMadsen: please paste a link. no.de killed the log server.
12:24:33  * piscisaureus_joined
12:24:33  * AndreasMadsenjoined
12:24:33  * bnoordhuisjoined
12:24:33  * mikealjoined
12:24:33  * AvianFlujoined
12:24:33  * paddybyersjoined
12:24:33  * bradleymeckjoined
12:24:33  * einarosjoined
12:24:33  * chiltsjoined
12:24:33  * txdv2joined
12:24:33  * benviejoined
12:24:33  * CIA-115joined
12:24:33  * ljacksonjoined
12:24:33  * mrb_bkjoined
12:24:33  * kohaijoined
12:24:33  * Raynosjoined
12:24:33  * rphillipsjoined
12:24:33  * CoverSlidejoined
12:24:33  * sj26joined
12:24:33  * pquernajoined
12:24:33  * mmaleckijoined
12:24:33  * russell_hjoined
12:24:33  * philipsjoined
12:24:33  * indutnyjoined
12:24:33  * ircretaryjoined
12:24:33  * DrPizzajoined
12:24:33  * arlolrajoined
12:24:33  * dannycoatesjoined
12:24:33  * raggijoined
12:33:23  <AndreasMadsen>piscisaureus_: https://github.com/joyent/node/pull/2591
13:01:12  <indutny>bnoordhuis: hello
13:02:53  <bnoordhuis>indutny: hey
13:04:37  <indutny>bnoordhuis: you were right
13:04:40  <indutny>:(
13:04:55  <bnoordhuis>indutny: i usually am, sorry about that
13:05:00  <bnoordhuis>about locking right?
13:05:02  <indutny>bnoordhuis: yes
13:05:13  <indutny>bnoordhuis: implementing 3-state referencing lock now
13:05:20  <bnoordhuis>good
13:05:48  <bnoordhuis>indutny: did you ask about pread yesterday?
13:06:19  <indutny>bnoordhuis: yes
13:06:28  <indutny>bnoordhuis: #define _XOPEN_SOURCE, right?
13:06:46  <bnoordhuis>indutny: #define _XOPEN_SOURCE 500, i think
13:06:50  <indutny>bnoordhuis: oh, yes
13:06:56  <indutny>bnoordhuis: actually, I meant this
13:08:03  <bnoordhuis>indutny: on second thought, you need _XOPEN_SOURCE 600 - pread is part of posix-2001
13:09:29  <indutny>bnoordhuis: huh?
13:09:34  <indutny>bnoordhuis: you think so?
13:09:54  <bnoordhuis>indutny: yes'
13:10:02  <indutny>NAME pread, pwrite - read from or write to a file descriptor at a given offset
13:10:03  <indutny>SYNOPSIS #define _XOPEN_SOURCE 500
13:10:10  <indutny>that's what I found in man
13:10:25  <indutny>I'll put 600
13:10:32  <indutny>but why is 500 noted in man?
13:11:22  <bnoordhuis>indutny: don't know, but _XOPEN_SOURCE is susv2
13:11:28  <bnoordhuis>and i'm pretty sure pread is part of posix-2001
13:11:35  <bnoordhuis>anyway
13:12:00  <indutny>_XOPEN_SOURCE >= 500 || _POSIX_C_SOURCE >= 200809L
13:12:08  <indutny>that's in ubuntu's man
13:12:15  <indutny>first one was from fedora's
13:12:24  <indutny>k, 600 sounds good to me
13:13:16  <indutny>bnoordhuis: can you review my refcounting code please?
13:13:23  <indutny>bnoordhuis: I'm getting in deadlocks for some reason
13:13:49  <bnoordhuis>indutny: of your bplus project? i'm kind of busy you know
13:14:22  <indutny>bnoordhuis: ok, np
13:14:36  <indutny>bnoordhuis: anyway, thank you
13:14:40  <bnoordhuis>my pleasure, fedor
13:46:48  <piscisaureus_>bnoordhuis: is there an unix command that will replace all occurences of \r\n by \n ?
13:46:58  <piscisaureus_>something with sed I would suppose
13:47:00  <piscisaureus_>but I don't speak sed
13:47:37  <bnoordhuis>piscisaureus_: fromdos or dos2unix
13:48:13  <bnoordhuis>piscisaureus_: it's in the tofrodos debian / ubuntu package
13:48:53  <bnoordhuis>piscisaureus_: `perl -i -pe 's/\r\n$/\n/' filename` should work too
13:49:10  <piscisaureus_>bnoordhuis: smartmachines have dos2unix. that suffices. thanks
13:56:59  <indutny>bnoordhuis: fixed!!!! :)
13:59:45  <bnoordhuis>piscisaureus_: https://github.com/joyent/node/pull/2611
13:59:49  <bnoordhuis>indutny: good :)
14:02:29  <piscisaureus_>bnoordhuis: are we going down that path?
14:02:44  <piscisaureus_>bnoordhuis: ok I am going to try the msi first
14:03:00  <bnoordhuis>piscisaureus_: i don't know, i'm just passing it on to you :)
14:05:12  <piscisaureus_>bnoordhuis: will the mac os installer include headers etc
14:05:27  <bnoordhuis>piscisaureus_: i think ryan is against that
14:05:31  <bnoordhuis>i on the other hand...
14:17:47  <indutny>bnoordhuis: I think I'll add arch detection for node-waf
14:18:20  <indutny>bnoordhuis: every addon is broken on osx, because 0.7.x node is building 32bit binaries by default
14:20:39  <bnoordhuis>indutny: yes, known issue
14:21:07  <bnoordhuis>it's kind of tricky to detect on os x lion though since it's a mixed environment
14:24:40  <indutny>bnoordhuis: I think 'file `which node`' should solve trick
14:24:51  <indutny>bnoordhuis: one can compile 64bit node on osx
14:25:06  <bnoordhuis>indutny: try `file /bin/sh` on lion
14:25:09  <indutny>bnoordhuis: so we should build addon for same arch that node is using
14:25:14  <indutny>bnoordhuis: I don't have lion.. :(
14:25:27  <bnoordhuis>ah
14:25:51  <bnoordhuis>the point is that binaries on lion are often multi-arch
14:25:57  <indutny>bnoordhuis: but node isn't
14:26:06  <indutny>bnoordhuis: or am I wrong?
14:26:21  <bnoordhuis>we don't compile a multi-arch node right now, no
14:26:36  <indutny>bnoordhuis: so, why not just `file` it?
14:26:43  <indutny>bnoordhuis: because we'll compile it in future?
14:26:48  <bnoordhuis>maybe
14:27:09  <indutny>bnoordhuis: can't one compile 32bit node on x86-64 os?
14:27:12  <bnoordhuis>re file: that could work but you have to make sure that you inspect the right nod ebinary
14:27:14  <bnoordhuis>*node
14:27:26  <bnoordhuis>indutny: yes, that's not the issue
14:27:39  <indutny>bnoordhuis: right node binary lays near to the node-waf
14:27:40  <bnoordhuis>but it'd be kind of neat to distribute a multi-arch installer in the future
14:27:52  <indutny>bnoordhuis: so I can get execution path of node-waf and find where node is
14:28:12  <indutny>bnoordhuis: how would addon work in case of multi-arch node?
14:28:23  <bnoordhuis>indutny: oh sure, but that's different from `which node` :)
14:28:29  <indutny>bnoordhuis: yes
14:28:35  <indutny>bnoordhuis: but that is correct, I think
14:29:03  <bnoordhuis>go ahead
14:29:06  <indutny>k
14:29:26  <indutny>should this be darwin-only?
14:30:23  <bnoordhuis>yes
14:32:02  <piscisaureus_>bnoordhuis: that patch installs too many headers. At least I want to install the bare minimum needed
14:32:20  <piscisaureus_>bnoordhuis: and I will not land it until we make a decision whether we want to install headers w/ installers
14:32:35  <bnoordhuis>piscisaureus_: that goes without saying
14:44:45  <bnoordhuis>piscisaureus_: https://github.com/joyent/libuv/pull/298/files#L3R494 <- symlink("a", "a"), does that work on windows?
14:54:04  <indutny>bnoordhuis: btw, multithreaded get from bplus is slower than one threaded...
14:54:10  <indutny>bnoordhuis: I think because it preads each page/value
14:56:43  <piscisaureus_>bnoordhuis: yes, it should
15:03:44  <bradleymeck>im seeing EPIPE when spawning a node process and trying to write to child.stdin (doesnt appear to be open yet), any way to check wait until stdin is open?
15:21:58  <bnoordhuis>bradleymeck: are you sure the child hasn't quit in the mean time?
15:22:22  <bnoordhuis>you can't really get EPIPE right after a spawn
15:23:48  <bradleymeck>if my logging is not coming back out of order on the tty its alive, but after further investigation (and a small timeout) it seems the child has EINVAL when stdin is being read. The parent has a non-tty stdin (piped in via echo) so im trying to figure out wtf is going on
15:24:04  <bradleymeck>bnoordhuis, but the process is certainly not dead, the stdin seems fed up though
15:25:16  <bnoordhuis>bradleymeck: do you a test case or a strace log i could look at?
15:25:27  <bradleymeck>let me reduce it a bit
15:35:07  <bradleymeck>bnoordhuis, EPIPE https://gist.github.com/1683299
15:35:27  <bradleymeck>still trying to reduce the EINVAL from non-tty...
15:35:39  <bnoordhuis>bradleymeck: should i try it with 0.6 or master?
15:35:58  <bradleymeck>both 0.6.* and 0.7.1 exhibit this oddness
15:37:28  <bnoordhuis>bradleymeck: btw, use spawn(process.argv[0]) instead of spawn('node')
15:37:39  <bnoordhuis>if you have multiple versions of node installed, the results can be surprising
15:38:13  <bradleymeck>bnoordhuis, i have a runner that sets all my env stuff, so i never really bothered, but i should for posterity
15:49:37  <bradleymeck>bnoordhuis, could it be that the process has started but the handle to stdin is not set up yet?
15:49:47  <bradleymeck>for js*
15:49:55  <bnoordhuis>bradleymeck: not sure yet
15:52:42  * isaacsjoined
15:56:59  <bnoordhuis>bradleymeck: well... the problem is that a read on fd 0 is failing with EINVAL
15:57:26  <bnoordhuis>the why is not exactly clear though
15:57:38  <bradleymeck>yea the why is what im trying to track down on that one
15:58:30  <bradleymeck>but the small test case does not cover the EINVAL problem, just the EPIPE
16:00:48  <bnoordhuis>bradleymeck: the EPIPE happens because the child dies of that EINVAL
16:03:08  * AndreasMadsenquit (Remote host closed the connection)
16:04:03  <bradleymeck>bnoordhuis, ugg i must be losing my mind, havent slept in a long time... sorry about that
16:10:22  <isaacs>good morning
16:11:42  <isaacs>anyone got anything for 0.6?
16:13:52  <bradleymeck>heya isaacs i found a EPIPE from child process giving an EINVAL that bnoordhuis is looking at, are you looking for anything in particular?
16:14:16  <isaacs>bradleymeck: just bug fixes or things that haven't been merged in yet that need to be.
16:15:57  <bradleymeck>isaacs, https://github.com/joyent/node/pull/2603 , circular symlinks make fs.exists odd but thats it from our end
16:16:10  <bradleymeck>well, path.exists in 0.6
16:17:18  <isaacs>bradleymeck: right
16:17:22  <isaacs>bradleymeck: and that's not changing
16:17:53  <isaacs>bradleymeck: and koichi brings up a great point: fs.exists("a/b/c/d") will return true if only a/b exists, but isn't a dir, or isn't readable.
16:21:58  <isaacs>ok, too many issues with it. closing that pull req.
16:22:05  <isaacs>it's too problematic. just use fs.stat if you care that much.
16:22:07  <isaacs>:)
16:22:49  <bradleymeck>isaacs, sure
16:25:51  <isaacs>bnoordhuis: is https://github.com/joyent/node/pull/2616 good?
16:26:46  <bnoordhuis>isaacs: maybe, haven't looked at it yet
16:37:00  * bradleymeckquit (Quit: Leaving)
16:46:14  * xaqjoined
16:51:27  <isaacs>hm... zlib is definitely still leaky.
16:51:30  <isaacs>that sucks.
17:00:22  <bnoordhuis>*sigh*
17:00:39  <bnoordhuis>bradleymeck's bug is the old close(0) bug again...
17:13:06  * dapjoined
17:14:47  * xaq_joined
17:14:47  * xaqquit (Read error: Connection reset by peer)
17:15:53  * orlandovftwjoined
17:16:08  * piscisaureus_quit (Read error: Connection reset by peer)
17:19:30  * xaq_quit (Remote host closed the connection)
17:38:59  * dshaw_joined
17:51:46  * mralephjoined
18:07:46  * orlandovftwquit (Quit: leaving)
18:08:04  * orlandovftwjoined
18:11:36  * AvianFluquit (Quit: Leaving)
18:14:16  * igorzijoined
18:14:34  * piscisaureus_joined
18:34:04  * TooTallNatejoined
18:34:09  <igorzi>bnoordhuis: hey
18:34:17  <igorzi>bnoordhuis: any progress on implementing uv_export/uv_import on unix?
18:39:16  * mikealquit (Quit: Leaving.)
18:43:31  <indutny> bnoordhuis: yt?
18:44:08  * skabbesjoined
18:47:33  * AndreasMadsenjoined
18:47:37  <skabbes>quick q for anyone who can answer
18:47:45  <AndreasMadsen>yo
18:47:57  <skabbes>if I want to use uv_queue_work, what should the proper loop be?
18:48:30  <skabbes>paddybyers mentioned to me that uv_default_loop isn't correct, since you need to choose a loop based on what isolate your code is living in
18:53:59  * mikealjoined
18:54:56  <indutny>skabbes: try Loop()
18:55:52  <indutny>skabbes: it's declared in node.h
18:55:52  <isaacs>indutny: hey, the debugger seems to not be working for me any more on mac os
18:55:52  <isaacs>indutny: 0.6
18:55:54  <skabbes>that's a global function?
18:56:09  <indutny>isaacs: oh, really?
18:56:13  <isaacs>indutny: if i run `node debug z.js`, it doesn't actually seem to run my program at all. scripts() shows only breakpoints_utf8.js
18:56:14  <indutny>isaacs: that's bad
18:56:25  <indutny>isaacs: huh?
18:56:31  <indutny>aah
18:56:32  <paddybyers>skabbes: hi
18:56:35  <indutny>you've a stray process
18:56:36  <isaacs>$ ./node_g --debug-brk z.js
18:56:36  <isaacs>debugger listening on port 5858
18:56:36  <isaacs>Failed to open socket on port 5858, waiting 1000 ms before retrying
18:56:38  <isaacs>Failed to open socket on port 5858, waiting 1000 ms before retrying
18:56:39  <indutny>shut it down
18:56:40  <isaacs>Failed to open socket on port 5858, waiting 1000 ms before retrying
18:56:42  <isaacs>^C
18:56:47  <indutny>^C
18:56:55  <indutny>you've a stray process from tests
18:57:06  <indutny>that happens time to time for some reason
18:57:09  <skabbes>paddybyers: hey
18:57:21  <indutny>skabbes: yes, it's global
18:57:21  <isaacs>ahhhh
18:57:32  <isaacs>yeah, killall node brings it back to lief.
18:57:39  <paddybyers>so in my implementation it's node::Isolate::getCurrentLoop()
18:57:43  <isaacs>we should try to figure out a way to detect and prevent that somehow.
18:57:50  <paddybyers>I'm not syncd with 0.7 yet
18:57:51  <isaacs>(or just ignore it and work around until someone else complains...)
18:58:10  <indutny>I think we should move away from processes
18:58:15  <indutny>to isolates
18:58:22  <indutny>but I'll take a look at this problem later
18:58:23  <indutny>anyway
18:58:37  <indutny>paddybyers: return Isolate::GetCurrent()->GetLoop();
18:58:43  <skabbes>paddybyers: I'm trying to find a way to push back in to node-sqlite3 and bcrypt it still work
18:58:50  <indutny>paddybyers: so node::Isolate::GetCurrent()->GetLoop()
18:59:32  <skabbes>will that still work if we're not using isolates?
18:59:58  * orlandovftwquit (Ping timeout: 245 seconds)
19:00:14  <indutny>skabbes: node::Loop() will
19:00:23  <indutny>skabbes: node::Isolate::GetCurrent() won't
19:00:52  * sh1mmerquit (Quit: sh1mmer)
19:00:57  <paddybyers>indutny: I realise that's what you do on 0.7, but I'm not on 0.7
19:00:59  <skabbes>indutny: is there a compiler flag to know which is supported so I can ifdef that?
19:01:21  * sh1mmerjoined
19:02:08  <paddybyers>indutny skabbes: so on my implementation it's node::Isolate::GetCurrentLoop()
19:02:23  <indutny>paddybyers: aah
19:02:30  <paddybyers>I will be merging with 0.7 at some point but I'm not there yet
19:02:31  <indutny>paddybyers: sorry
19:02:34  <paddybyers>np
19:02:49  <indutny>skabbes: #if defined(HAVE_ISOLATES) && HAVE_ISOLATES
19:03:07  <skabbes>indutny: thanks!
19:03:10  <indutny>np
19:03:34  <AndreasMadsen>indutny: so you want .fork to be isolates only?
19:03:58  <skabbes>paddybyers: I'd like to be able to keep from having my own fork of sqlite and bcrypt
19:04:18  <paddybyers>skabbes: right
19:04:24  <indutny>AndreasMadsen: I hadn't said that
19:04:24  <skabbes>paddybyers: so hopefully I can submit a patch to those, and have it work in both places
19:04:30  <paddybyers>so I will add 0.7-compatible apis
19:04:43  * brsonjoined
19:05:13  <AndreasMadsen>indutny: "I think we should move away from processes," I assume it is the binding then
19:05:48  <skabbes>no worries there, as long as in the long run it'll be maintainable - not forking a zillion projects
19:08:08  <AndreasMadsen>I sad "I assume it is the binding then" - with more thoughts, can't make any sense in that too
19:08:30  <piscisaureus_>igorzi: hey
19:08:45  <igorzi>piscisaureus_: hey, what's up
19:08:49  <indutny>AndreasMadsen: I was talking about debugger
19:08:55  <piscisaureus_>igorzi: did you work with that colleague that can reproduce the http server not working?
19:08:59  <piscisaureus_>(yet)
19:09:01  <AndreasMadsen>indutny: oh :=)
19:09:13  <igorzi>piscisaureus_: not yet, but i will today
19:09:21  <piscisaureus_>igorzi: cool
19:09:30  <piscisaureus_>igorzi: I don't like this uncertainty :-)
19:09:43  <igorzi>piscisaureus_: yep :)
19:10:22  <igorzi>piscisaureus_: crap.. he's actually out until monday.. i was going to debug it during nodesummit, but just couldn't find any time
19:10:33  <piscisaureus_>ah, too bad
19:10:40  <piscisaureus_>had fun?
19:11:38  <igorzi>piscisaureus_: yep.. first day was kind of boring (a lot of non-dev stuff), but 2nd day was a lot of fun
19:11:46  <skabbes>I was at nodesummit as well, curious to hear how the 2nd day went
19:12:03  <igorzi>piscisaureus_: they had a bunch of startups come up and present for 5 minutes
19:12:28  <skabbes>dammit, i missed the best part
19:12:32  <igorzi>there is a lot of cool stuff being done with node
19:12:39  <piscisaureus_>igorzi: which was the most impressive?
19:13:19  <piscisaureus_>I am also curious whether the fabric engine guys managed to convince anyone
19:13:37  <piscisaureus_>They never really convince me but that's probably because there's no demos and no source
19:13:51  <igorzi>piscisaureus_: you know.. they did a good pitch, and they grabbed a lot of attention (they actually won some award)
19:14:03  <igorzi>piscisaureus_: but i'm also still very skeptical
19:14:23  <igorzi>piscisaureus_: quizlet.com won 1st place (by attendee voting).. they were pretty impressive
19:15:21  <igorzi>feedhenry.com is also pretty nice
19:16:03  <piscisaureus_>are these all node-backed
19:16:05  <indutny>oh, looks like I reimplemented rwlock
19:16:08  <indutny>fck
19:16:15  <piscisaureus_>ghe dude
19:16:46  <igorzi>piscisaureus_: yep, most of these are 100% node
19:17:28  <indutny>piscisaureus_: do you think my hand-written implementation may be faster than libc? :P
19:17:46  <piscisaureus_>indutny: do you think libc is not hand-wriitten?
19:18:13  <indutny>piscisaureus_: it's written by machines in human-like form
19:18:25  <piscisaureus_>machiness with beards
19:18:28  <paddybyers>skabbes: https://github.com/paddybyers/node/commit/3721e95d6a9f9a5a5825615e05fb1618f8dfdd73
19:18:47  <igorzi>piscisaureus_: mapbox.com is also pretty impressive
19:19:32  <skabbes>paddybyers: brilliant! thanks
19:19:36  <piscisaureus_>igorzi: I don't actually know what mapbox does. The only thing I heardd is that they madee a windows gui app in node so I was wondering how they pulled that off.
19:20:29  <igorzi>piscisaureus_: yeah, those guys actually came up to me and started personally thanking you and me for doing the windows port :).. because that enabled them to create a windows desktop app without knowing much about windows
19:20:52  <igorzi>piscisaureus_: they run a local node http server, and they embed a chrome frame into a windows app
19:21:00  <isaacs>piscisaureus_, igorzi: yeah, they managed to figure out how to compile all kinds of stuff on windows that only has wscript files.
19:21:21  <piscisaureus_>igorzi: aah!
19:21:33  <piscisaureus_>igorzi: actually it makes sense to do it that way
19:21:48  <piscisaureus_>igorzi: you have to do nothing besides compiling that chrome stuff :-)
19:21:58  <igorzi>piscisaureus_: yep.. exactly
19:22:08  <isaacs>igorzi: that's how we used to build windows client-server apps back in the day, but it was IIS and ASP and a IE control
19:22:21  <isaacs>and vb instead of js
19:23:15  <igorzi>isaacs: yeah, that sounds like it probably took more time than just running node.exe :)
19:23:57  <igorzi>bbl
19:24:58  * bradleymeckjoined
19:25:02  <isaacs>igorzi: for sure :)
19:25:26  <piscisaureus_>isaacs: do you know what could have happened to no.de last night?
19:25:35  <bradleymeck>bnoordhuis, did you figure out the EINVAL error, or should i make an issue?
19:26:04  <isaacs>piscisaureus_: no idea.
19:26:04  <isaacs>piscisaureus_: i can ping our ops folks if you'd like
19:26:49  <piscisaureus_>isaacs: if it is not too much effort, please. It came back online this morning but I am now nervous and about to back up all the stuff in my account. piscisaureus2.no.de died once and it never resurrected.
19:32:20  * piscisaureus_bbl
19:36:37  * piscisaureus_quit (Ping timeout: 248 seconds)
19:36:40  * xaqjoined
19:37:13  * AndreasMadsenquit (Remote host closed the connection)
19:38:06  <indutny>bnoordhuis: oooh!! why you haven't told me that I can use rwlocks :D
19:40:19  * AndreasMadsenjoined
19:43:52  * orlandovftwjoined
19:50:20  * brsonquit (Ping timeout: 276 seconds)
19:51:05  <isaacs>ircretary: tell piscisaureus Emailed ops, and also fixed http://piscisaureus2.no.de/
19:51:05  <ircretary>isaacs: I'll be sure to tell piscisaureus
19:58:16  * piscisaureus_joined
19:58:39  <piscisaureus_>ircretary: tell isaacs Thanks and awesome!
19:58:39  <ircretary>piscisaureus_: I'll be sure to tell isaacs
19:58:51  <isaacs>piscisaureus_: hey
19:59:00  * piscisaureus_changed nick to piscisaureus
19:59:02  <piscisaureus>isaacs: hey
19:59:03  <isaacs>you dont' have to talk about me like i'm not here.
19:59:08  * isaacscrieds
19:59:20  <piscisaureus>isaacs: heh :-)
19:59:22  * elijah-mbpjoined
19:59:36  <isaacs>piscisaureus: yeah, piscisaureus2 died in the Great Database Snafu of 2011
19:59:46  <isaacs>when riak shot itself in the face repeatedly.
19:59:50  <elijah-mbp>piscisaureus, i'm looking around in no.de for what happened to your instance last night
19:59:56  <isaacs>elijah-mbp: hey!
20:00:00  <isaacs>i know you!
20:00:00  <elijah-mbp>hey! :-)
20:00:02  <elijah-mbp>haha
20:00:04  <elijah-mbp>yes you do
20:00:06  <piscisaureus>elijah-mbp: ah, thanks
20:00:09  <isaacs>thanks
20:00:15  * kuebkjoined
20:00:41  <elijah-mbp>i'm digging around - and we will probably add a few monitors here and there´┐Ż not of piscisaureus directly, but supporting chunks that happen to not have coverage like i'd like.
20:01:11  <piscisaureus>elijah-mbp: it looks to me like there was a network problem. Apparently my bot tried to make a connection all the time but got a DNS error
20:01:38  <piscisaureus>elijah-mbp: vice versa the machine was not reachable from outside
20:02:02  <elijah-mbp>errrr isaacs any idea why I can't hit the no.de admin portal? :-)
20:02:13  <elijah-mbp>auth backend might be pukey.
20:02:42  * AndreasMadsenquit (Remote host closed the connection)
20:02:56  <elijah-mbp>oh. it's because i'm dumb and typed the wrong password.
20:03:01  <elijah-mbp>so.. nevermind!
20:04:02  <isaacs>:)
20:05:47  <isaacs>piscisaureus: it seems like there's still a bit of a leak in zlib, but i'm completely at a loss trying to find it
20:06:04  <isaacs>piscisaureus: any ideas?
20:07:02  * piscisaureusbbiab
20:07:34  <isaacs>https://gist.github.com/1684780 is the test i'm using
20:10:35  <pquerna>indutny: hey, did the node.js binding to zlib in core in 0.6 have stuff exposed to set the initial... hmm right word, the initial window that spdy uses?
20:11:12  * piscisaureusquit (Ping timeout: 240 seconds)
20:13:02  <pquerna>indutny: hrm, looks like dictionary isn't exposed?
20:13:41  <isaacs>pquerna: i think dictionary support is in 0.7
20:14:09  <pquerna>yeah, bummer. wanted to abuse it. guess i'll live for now.
20:14:39  <isaacs>:)
20:16:52  * piscisaureusjoined
20:17:26  * piscisaureuschanged nick to piscisaureus_
20:17:30  <piscisaureus_>isaacs: re zlib - I don't know, but I will look into it. Do we have a test?
20:22:52  * piscisaureus__joined
20:23:44  <isaacs>piscisaureus_: https://gist.github.com/1684780 should not show excessive memory leaking.
20:24:01  <isaacs>that's the only test i've got atm. nothing that can be run in make test yet.
20:24:01  <piscisaureus__>isaacs: thnx
20:24:31  <indutny>oooh
20:24:43  <indutny>heya
20:24:47  <piscisaureus__>isaacs: testing memleaks in a test is very difficult. this is good enough for analysis.
20:26:44  <indutny>pquerna: hi
20:26:51  <indutny>pquerna: can you refine your question?
20:27:06  <indutny>pquerna: 0.6 has nothing to do with dictionary
20:27:21  <indutny>pquerna: I implemented dictionary support for zlib in node 0.7.x
20:33:16  <igorzi>piscisaureus__: http://nodemanual.org is from cloud9ide? it's pretty nice
20:33:44  * piscisaureus__changed nick to piscisaureus
20:34:38  <piscisaureus>igorzi: it is. Good to hear :-) I will relay your compliments.
20:35:31  <piscisaureus>igorzi: the plan is to feed back the changes we made to the reference back into the main repo
20:36:48  <igorzi>piscisaureus: i noticed that the API guide provides types (when known) for args and return values
20:36:59  <igorzi>piscisaureus: how is that obtained? automated or manually?
20:37:04  <piscisaureus>manually
20:37:18  <piscisaureus>our technical writer went over everything
20:37:41  <piscisaureus>it still needs a bit of review though, here and there I noticed some mistakes / oddities
20:46:57  <isaacs>piscisaureus_: we should also chat about how to get the api reference data into a form that cloud9 and microsoft can consume in their editors.
20:47:11  <isaacs>cc igorzi ^
20:47:50  <isaacs>since there is one microsoft employee and 2 cloud9 employees in the group of active core committers, i suggest you guys figure it out :)
20:48:05  <piscisaureus>isaacs: yeah, I think they have some sort of solution for that now. But I am not sure what it is.
20:48:12  <isaacs>igorzi: (watch out, ben has impressive reach)
20:48:17  <isaacs>i mean, if it comes to blows
20:50:18  <igorzi>isaacs: ok, good to know :)
20:50:38  * xaqquit (Remote host closed the connection)
20:53:37  * mikealquit (Quit: Leaving.)
20:55:04  * mikealjoined
20:56:54  <isaacs>bnoordhuis: yeah, i think we need to take in those udp tests. every dgram test is failing right now.
20:57:00  <isaacs>slowly, too, which is the worse :)
21:00:27  * indutnychanged nick to indutny_sleeping
21:02:05  * xaqjoined
21:17:22  * txdv2quit (Read error: Connection reset by peer)
21:17:54  * txdv2joined
21:18:33  <bnoordhuis>igorzi: https://github.com/bnoordhuis/libuv/compare/export-streams <- i think it kind of works but the test mysteriously hangs for me, haven't gotten around to figuring out why
21:19:13  <bnoordhuis>bradleymeck: i figured out what's causing the EINVAL, haven't decided how to fix it yet. if you want to open then yes please
21:23:24  * bradleymeckquit (Ping timeout: 252 seconds)
21:27:30  * xaqquit (Remote host closed the connection)
21:27:47  * mralephquit (Quit: Leaving.)
21:35:08  * piscisaureus__joined
21:35:31  * piscisaureus___joined
21:37:08  * perezdjoined
21:37:32  * piscisaureusquit (Ping timeout: 240 seconds)
21:37:48  * piscisaureus___changed nick to piscisaureus
21:38:16  * piscisaureus_quit (Ping timeout: 260 seconds)
21:44:00  * mralephjoined
21:47:41  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
21:48:58  * perezdquit (Quit: perezd)
21:51:52  * piscisaureus__quit (Quit: ~ Trillian Astra - www.trillian.im ~)
21:58:03  * AvianFlujoined
21:58:11  * mralephquit (Quit: Leaving.)
22:14:34  <pquerna>indutny_sleeping: question was is it available in 0.6; answer is no. its fine :)
22:20:40  * mikealquit (Quit: Leaving.)
22:25:25  * mikealjoined
22:27:20  * mikealquit (Client Quit)
22:28:55  * mikealjoined
22:29:46  * kuebkquit (Ping timeout: 248 seconds)
22:46:32  * brsonjoined
22:50:40  * wankdankerjoined
22:52:19  * kuebkjoined
22:54:14  <CIA-115>node: Ben Noordhuis master * rf89beaf / Makefile :
22:54:14  <CIA-115>node: build: compile release build too if BUILDTYPE=Debug
22:54:14  <CIA-115>node: It's backwards compatible with the old waf build system. If you want to compile
22:54:14  <CIA-115>node: just the debug build, run `make -C out BUILDTYPE=Debug` instead.
22:54:14  <CIA-115>node: Fixes #2615. - http://git.io/DoxfSw
22:59:23  <isaacs>bnoordhuis: you around?
22:59:30  <isaacs>bnoordhuis: all the dgram tests seem to be failing.
22:59:32  <bnoordhuis>isaacs: yes
22:59:40  <bnoordhuis>with 0.6 or master?
22:59:56  <isaacs>0.6
23:00:14  <isaacs>test-dgram-multicast-setTTL test-dgram-send-error test-dgram-multicast-multi-process etc.
23:00:16  <bnoordhuis>that's a new development...
23:00:26  <isaacs>yeah
23:00:31  <isaacs>i'm wondering if i'm insane and forgetting something
23:00:34  <bnoordhuis>are you sure your build is up to date?
23:00:45  <bnoordhuis>waf sometimes forgets to recompile node when libuv's been updated
23:01:08  <isaacs>i just did a distclean, it's making all again now
23:01:11  <bnoordhuis>rm -rf out/{Debug,Release}/{deps/uv,node}
23:01:14  <isaacs>right
23:01:14  <bnoordhuis>oh, too late!
23:01:29  <isaacs>yeah, compiling v8 even
23:01:43  <isaacs>wanted to know quickly if this is a known thing, though, or something to be concerned about.
23:02:02  <isaacs>i'll let you know in a bit if it's still busted after rebuilding. thanks!
23:02:41  <bnoordhuis>isaacs: i merged that PR from dan (wankdanker), then fixed a number of bugs afterwards
23:02:46  <bnoordhuis>iow, things should work
23:02:50  <isaacs>yeah, i saw that
23:02:54  <isaacs>which is very exciting.
23:02:56  * tjfontainejoined
23:03:20  <bnoordhuis>well... i realized it contains at least one change that may need to be reverted
23:03:23  <isaacs>we cannot release 0.6.9 wihtout that dgram stuff working. that's what everyone's excited about.
23:03:34  <isaacs>what's that?
23:04:01  <bnoordhuis>his patch sets SO_REUSEADDR on udp sockets and that changes node's behaviour in some cases
23:04:26  <isaacs>yeah, that seemed a bit odd.
23:04:34  <isaacs>what behavior does it change, and why does it have to be there?
23:04:40  <bnoordhuis>with SO_REUSEADDR set, you can "steal" a port from an already bound socket
23:04:51  <wankdanker>if i may chime in...
23:04:55  <bnoordhuis>hey dan
23:05:00  <wankdanker>hey ben.
23:05:19  <wankdanker>in my tests on linux and windows, SO_REUSEADDR with udp sockets doesn't steal the port
23:05:32  <wankdanker>each process receives the data
23:05:48  <wankdanker>unless i'm misunderstanding something
23:06:12  <isaacs>after distclean and makeall, test/simple/test-dgram-broadcast-multi-process.js still fails
23:06:21  <isaacs>Error: bind EADDRINUSE
23:06:40  <bnoordhuis>let me try it
23:07:55  <isaacs>pingpong and udp4 work. the others fail
23:08:03  <isaacs>$ ./node test/simple/test-dgram-broadcast-multi-process.js
23:08:03  <isaacs>Error: setBroadcast EBADF
23:08:14  * travis-cijoined
23:08:14  <travis-ci>[travis-ci] joyent/node#316 (master - f89beaf : Ben Noordhuis): The build is still failing.
23:08:14  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/c80abfa...f89beaf
23:08:14  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/581669
23:08:14  * travis-cipart
23:08:31  <isaacs>test/simple/test-dgram-multicast-multi-process.js throws 3 EBADFs
23:08:47  <isaacs>test/simple/test-dgram-multicast-setTTL.js also EBADF
23:08:52  <wankdanker>EBADF happened to me when the test was setting socket options before bind()
23:10:02  <wankdanker>can you gist your copy of test/simple/test-dgram-multicast-multi-process.js or somehow tell me which version you have?
23:10:37  <isaacs>wankdanker: https://gist.github.com/1685728
23:10:38  <bnoordhuis>tests pass for me, both before and after applying #2616
23:10:52  <isaacs>bnoordhuis: linux or osx?
23:10:58  <bnoordhuis>isaacs: linux
23:11:44  * zeilejoined
23:11:58  * bnoordhuisstarts up his macbook
23:13:08  * bnoordhu1sjoined
23:14:30  * bnoordhu1squit (Client Quit)
23:15:34  <bnoordhuis>right, it's pretty borked on os x
23:16:35  <wankdanker>bummer
23:18:24  * zeilepart
23:19:20  * kuebkquit (Ping timeout: 255 seconds)
23:21:03  <isaacs>bnoordhuis: any idea where to start digging? we can delay the release if necessary, but if it's a small thing to fix, we should just do it.
23:21:22  <wankdanker>http://lua-users.org/lists/lua-l/2007-09/msg00274.html
23:22:06  <isaacs>oh, blessings indeed.
23:23:01  <isaacs>but... this seems kind of weird. how was it done in 0.4?
23:23:16  <isaacs>i didn't think we had to SO_REUSEADDR for dgram before, did we?
23:23:17  <wankdanker>there were SO_REUSADDRS all over the place in 0.4
23:23:22  <isaacs>oh, ok
23:23:30  <wankdanker>as far as i remember.
23:23:58  <isaacs>but how did it work on osx on 0.4, i mean
23:24:07  <isaacs>if SO_REUSEADDR doesn't apply..
23:25:41  <isaacs>linux: [00:57|% 100|+ 320|- 6]: Done
23:25:47  <wankdanker>https://github.com/joyent/node/blob/v0.4/src/node_net.cc#L208
23:26:05  <bnoordhuis>we used SO_REUSEPORT in 0.4
23:27:02  <bnoordhuis>yep, using SO_REUSEPORT fixes it
23:27:15  <isaacs>awesome.
23:27:24  <wankdanker>joy
23:29:24  <isaacs>simple/test-regress-GH-1697 is throwing pipes at me
23:29:59  <bnoordhuis>just throw them right back
23:30:09  <bnoordhuis>that test has a tendency to leave behind stray child processes
23:30:15  <isaacs>works on mac, though
23:30:25  <isaacs>k
23:33:08  <bnoordhuis>so the question is: does SO_REUSEPORT have side effects?
23:34:52  <isaacs>http://www.softlab.ntua.gr/facilities/documentation/unix/unix-socket-faq/unix-socket-faq-4.html#ss4.12
23:34:58  * isaacsreading ^ now
23:37:21  * mikealquit (Quit: Leaving.)
23:38:19  * skabbesquit (Read error: Connection reset by peer)
23:38:24  <wankdanker>i get the impression that SO_REUSEPORT is what should be used on all systems, but i think when I tried that on linux it didn't work.
23:38:25  * skabbesjoined
23:38:54  <wankdanker>it's as if the SO_REUSEPORT behavior is actually that of SO_REUSEADDR on linux.
23:39:05  <bnoordhuis>wankdanker: linux doesn't have SO_REUSEPORT, SO_REUSEADDR is the nearest equivalent
23:39:18  <wankdanker>well. there we go!
23:39:18  <isaacs>#ifndef SO_REUSEPORT
23:39:19  <isaacs>#define SOREUSEPORT SO_REUSEADDR
23:39:19  <isaacs>#endif
23:39:30  <isaacs>would that solve our issue?
23:39:33  <bnoordhuis>wankdanker: https://gist.github.com/73e659c504915d22f99f <- that shows the port stealing behaviour i mentioned
23:39:42  <bnoordhuis>isaacs: oh, i already have a patch ready
23:40:09  <wankdanker>i see. i agree with that. that makes sense.
23:40:17  <isaacs>bnoordhuis: of course you do. because you are a true hero.
23:40:18  <wankdanker>thats all within the same process
23:40:36  <bnoordhuis>isaacs: https://github.com/bnoordhuis/libuv/commit/f32e67e
23:41:33  <bnoordhuis>wankdanker: yeah, it's not bad or wrong behaviour, it's just different from what node does now
23:42:08  <wankdanker>you mean now as in v0.4?
23:42:14  <bnoordhuis>now as in v0.6
23:42:49  <bnoordhuis>more specifically, now as in 'before your patch'
23:43:02  <wankdanker>oh. ok. that helps. :)
23:43:11  * mikealjoined
23:43:29  <wankdanker>before my patch, it would have bailed with addr in use, right?
23:43:33  <bnoordhuis>yes
23:43:46  <wankdanker>ok. i see. now i'm on the same page.
23:44:02  <wankdanker>i've always looked at this issue as a separate process thing....
23:44:31  <wankdanker>should we keep track of ports in use within the same process in dgram.js?
23:44:40  <wankdanker>we could throw an error then
23:45:01  <isaacs>well, i mean... we're well into the realm of fucking our "no api" promises.
23:45:22  <isaacs>i don't think failing to throw an EADDRINUSE in this case is as bad as failing to put dgram back.
23:45:52  <bnoordhuis>i kind of agree, stealing the port isn't necessarily bad, just different
23:46:14  <bnoordhuis>and there probably aren't that many users of that particular feature
23:46:34  <isaacs>if it wasn't for a good cause, i'd say no. but in this case, we have a bunch of people who were stranded on 0.4 because of not having dgram supported fully.
23:46:43  <isaacs>right, probably no one's program is depending on throwing EADDRINUSE
23:47:25  <bnoordhuis>okay, i'll land the patch and upgrade libuv
23:47:53  <isaacs>can i review it?
23:48:21  <CIA-115>libuv: Ben Noordhuis v0.6 * rf32e67e / src/unix/udp.c :
23:48:21  <CIA-115>libuv: unix: turn on SO_REUSEPORT for UDP sockets
23:48:21  <CIA-115>libuv: Required on OS X for UDP multicast. Without it, the bind() call fails with
23:48:21  <CIA-115>libuv: EADDRINUSE. - http://git.io/oX56Xw
23:48:37  <bnoordhuis>isaacs: you should've said that 5 seconds earlier
23:48:41  <isaacs>heh
23:48:45  <bnoordhuis>it's the commit i linked you to
23:49:56  * piscisaureus_joined
23:50:11  <isaacs>comment is slightly off. it's a BSD-ism, and apparently it's on Solaris as well.
23:50:14  <isaacs>but whatever.
23:50:26  <isaacs>lgtm
23:50:29  <bnoordhuis>you're right
23:50:37  <piscisaureus_>release test-dgram-broadcast-multi-process hangs for me
23:50:39  <bnoordhuis>solaris doesn't have it btw but it's a bsd-ism yes
23:50:57  <bnoordhuis>i'll update the commit log
23:51:20  <wankdanker>piscisaureus_: there is a pull request for that https://github.com/joyent/node/pull/2616
23:51:26  <piscisaureus_>also igorzi's patch seems to have introduced an issue where stat('c:\\') now fails
23:53:26  <bnoordhuis>github is so slow...
23:53:48  <CIA-115>libuv: Ben Noordhuis v0.6 * r9c76d0d / src/unix/udp.c :
23:53:49  <CIA-115>libuv: unix: turn on SO_REUSEPORT for UDP sockets
23:53:49  <CIA-115>libuv: Required on BSD-like systems for local UDP multicast. Without it, the bind()
23:53:49  <CIA-115>libuv: call fails with EADDRINUSE. - http://git.io/KjaO8w
23:55:39  * travis-cijoined
23:55:39  <travis-ci>[travis-ci] joyent/libuv#53 (v0.6 - 9c76d0d : Ben Noordhuis): The build is still failing.
23:55:39  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/f32e67e...9c76d0d
23:55:39  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/581870
23:55:39  * travis-cipart
23:57:40  <bnoordhuis>seriously github, wtf?
23:58:10  <bnoordhuis>does pulling/pushing work for you guys?
23:58:21  <piscisaureus_>yeah this is unworkable
23:58:43  <CIA-115>node: Ben Noordhuis v0.6 * r352febe / deps/uv/src/unix/udp.c : uv: upgrade to 9c76d0d - http://git.io/4ktGzQ
23:59:29  <bnoordhuis>well, that only took 10 minutes...
23:59:52  <wankdanker>i just pulled in seconds. east coast usa