00:01:44  * mjr_quit (Client Quit)
00:04:22  * isaacsquit (Remote host closed the connection)
00:04:35  * isaacsjoined
00:05:50  * isaacsquit (Remote host closed the connection)
00:06:02  * isaacsjoined
00:17:15  * isaacsquit (Remote host closed the connection)
00:17:32  * isaacsjoined
00:18:01  * pieternjoined
00:24:24  <txdv>how do I attach code in an issue?
00:24:29  <txdv>to an issue
00:24:38  <sh1mmer>you do a pull request
00:24:54  <sh1mmer>or you can do markdown code inline I believe
00:25:10  <sh1mmer>if you do a pull request it's best to do it from a branch rather than your fork of head
00:26:18  <isaacs>ryah, piscisaureus_: ok with you guys to land the zlib cleanups? (will squash into one)
00:29:39  * `3rdEdenquit (Quit: zzzzz)
00:34:32  <txdv>but if i create a pull request, it won't be tied to the issue
00:34:38  <txdv>wtf github, y u no userfriendly
00:35:14  <ryah>isaacs: link?
00:35:34  <sh1mmer>txdv: I think there is a way to do that, but I can never remember because it's not obvious
00:35:36  <isaacs>https://gist.github.com/1591238
00:35:40  <isaacs>ryah: ^
00:35:43  * AvianFluquit (Ping timeout: 255 seconds)
00:36:06  <mrb_bk>hey hey
00:36:24  <mrb_bk>I'm playing around with stuff related to https://github.com/joyent/node/issues/2478
00:36:35  <mrb_bk>Trying to add slab allocation similar to stream_wrap to udp_wrap
00:36:46  <ryah>isaacs: i thought we said uv_work_t instead of WorkReqWrap ?
00:36:55  <isaacs>ryah: yeah, that's what the 4th commit does.
00:37:12  <isaacs>er, no, the 3rd
00:37:30  <isaacs>https://gist.github.com/1591238#file_0003_zlib_remove_unnecessary_work_req_wrap.patch
00:37:34  <isaacs>probably more atomic than necessary.
00:38:25  <ryah>and the Ref/Unref stuff?
00:40:14  <ryah>assuing all the test pass - this looks fine. still need to Ref/Unref the zlib object while it's in the TP
00:40:41  <ryah>mrb_bk: godo :)
00:41:00  <mrb_bk>ryah: yeah I haven't hacked on node/v8 before, so I have a lot to learn
00:41:09  <mrb_bk>and I haven't used C++ in years and years so I'm rusty
00:41:36  <ryah>mrb_bk: should be a lot of copy and pasting from src/stream_Wrap.cc into src/udp_wrap.cc
00:42:13  <mrb_bk>ryah: yeah seems that way -- i think i copied everything that needs copying
00:42:19  <isaacs>ryah: ref/unref is landed already by bnoordhuis
00:42:40  <ryah>isaacs: oh okay
00:42:42  <isaacs>i'll squash and land on v0.6 then.
00:46:20  * dapquit (Quit: Leaving.)
00:49:05  * AvianFlujoined
01:07:06  <txdv>ok awesome
01:07:14  <txdv>C# + libuv + ncurses, a lot of love
01:17:09  <isaacs>keepalive, debugger client, and full-http-response tests all failing on os x
01:17:16  * pieternquit (Quit: pietern)
01:17:22  <isaacs>[30:05|% 100|+ 675|- 13]: Done
01:18:05  <isaacs>same before and after the zlib patch, though. i'm landing it.
01:18:51  <CIA-115>node: isaacs v0.6 * r8cca30f / src/node_zlib.cc : (log message trimmed)
01:18:51  <CIA-115>node: zlib binding cleanup
01:18:51  <CIA-115>node: * Add assert to prevent parallel writes
01:18:51  <CIA-115>node: * Embed request object instead of using new/delete
01:18:51  <CIA-115>node: * Remove unnecessary WorkReqWrap in favor of uv_work_t
01:18:52  <CIA-115>node: * Use container_of instead of req->data
01:18:52  <CIA-115>node: Along with 2d8af39accc6e1a863aa60ed80289508f3df50e8 and
01:22:26  * mikealjoined
01:23:24  <mrb_bk>ryah: muahahah it works
01:26:29  <mrb_bk>memory use is totally in check
01:26:42  * travis-cijoined
01:26:42  <travis-ci>[travis-ci] joyent/node#222 (v0.6 - 8cca30f : isaacs): The build was fixed.
01:26:42  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/290bc0c...8cca30f
01:26:42  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/504939
01:26:42  * travis-cipart
01:26:49  <mrb_bk>i had forgotten to get rid of the stuff in ReleaseMemory
01:27:04  <isaacs>hooray, i fixed the build
01:27:26  <isaacs>that's gotta be some kind of race or something
01:27:33  <isaacs>because the failure had nothing to do with zlib
01:31:12  * piscisaureus_part
01:40:18  * pieternjoined
02:11:00  * perezdquit (Quit: perezd)
02:14:19  * mikealquit (Quit: Leaving.)
02:14:49  * mikealjoined
02:17:04  * mikeal1joined
02:17:11  * mikealquit (Read error: Connection reset by peer)
02:25:46  * pieternquit (Quit: pietern)
02:32:21  * bradleymeckjoined
02:37:53  * perezdjoined
02:41:46  * mikeal1quit (Read error: Connection reset by peer)
02:43:04  * mikealjoined
02:47:18  <bradleymeck>mmm if i get a FD in libuv how would i listen for writes it looks like uv_pipe_init, but then what?
02:58:46  * bradleymeckquit (Ping timeout: 240 seconds)
03:02:47  * piscisaureus_joined
03:04:18  * dshaw_quit (Ping timeout: 252 seconds)
03:10:46  * piscisaureus_quit (Ping timeout: 240 seconds)
03:25:39  * mikealquit (Quit: Leaving.)
03:41:45  * TooTallNatequit (Quit: Linkinus - http://linkinus.com)
04:29:22  * mrb_bkquit (Remote host closed the connection)
04:29:22  * Raynosquit (Remote host closed the connection)
04:59:09  * Raynosjoined
05:19:29  * mrb_bkjoined
05:24:35  * perezdquit (Quit: perezd)
05:25:28  * Raynosquit (Remote host closed the connection)
05:36:20  * mrb_bkquit (Remote host closed the connection)
05:44:05  * TooTallNatejoined
05:44:11  * TooTallNatequit (Client Quit)
05:45:52  * Raynosjoined
06:33:58  * paddybyersjoined
06:38:52  * mrb_bkjoined
07:40:28  * ErikCorryV8joined
08:11:01  * slaskisjoined
08:16:28  * benviequit
08:33:11  * mikealjoined
08:48:14  <mrb_bk>mikeal: sup bro
08:49:23  <mikeal>heya
08:50:05  * bnoordhuisjoined
08:50:37  <mikeal>long day
08:50:41  <mikeal>looking forward to crashing
08:50:52  <mikeal>it's crazy late in new york, what are you doin up :)
08:51:18  <mikeal>wait, are you in NYC?
08:52:36  <mikeal>or are you traveling some more
08:53:55  <indutny>isaacs: yt?
08:54:04  <mrb_bk>travelling
08:54:14  <mrb_bk>i'm up early, not up late -- dad lyfe
08:54:15  <isaacs>indutny: heading to bed. what's up?
08:54:16  <indutny>isaacs: I found that all node-spdy issues was related to that bug, not to zlib leaks
08:54:21  <isaacs>haha
08:54:23  <isaacs>nice :)
08:54:25  <indutny>isaacs: ah, it's late in SF, I forgot
08:54:29  <isaacs>we fixed those bugs for nothing!!??!?
08:54:31  <indutny>isaacs: sorry :) sleep tight
08:54:38  <isaacs>;)
08:54:41  <indutny>isaacs: looks like so, but I found much larger bug
08:54:45  <isaacs>kewl
08:54:47  <mrb_bk>mikeal: long days are good, let's catch up tomorrow
08:54:50  <indutny>isaacs: and I'm using zlib pool now
08:54:59  <isaacs>it's being kinda leaky still anyway.
08:55:02  <mrb_bk>is valgrind ./node failing for other people?
08:55:04  <isaacs>need to figure out
08:55:10  <isaacs>anyway, i'm out.
08:55:12  <mrb_bk>on v0.6
08:55:12  * isaacsquit (Remote host closed the connection)
08:55:23  <indutny>isaacs: :) see you
08:55:32  <mrb_bk>because that's making me want to go back to bed
08:55:58  <mrb_bk>mikeal: doing my first experiments contributing to node C++
08:56:04  <mikeal>awesome
08:56:17  <mikeal>i'm writing a new deployment system
08:57:36  <mrb_bk>nice
08:58:15  <mrb_bk>okay you reminding me that i shouldn't be awake is making me want to try to sleep more
08:58:16  <mikeal>i wish i didn't have to, but i do, so i am :)
08:58:21  <mrb_bk>mikeal: HAVE TO?
08:58:23  <mikeal>hehe, cool
08:58:35  <mikeal>yeah, long story
08:58:39  <mrb_bk>hahah word
08:58:47  <mrb_bk>i'd like to hear more soon, i'll catch you in here?
08:59:03  <mikeal>yeah, i auto-join
08:59:07  <mrb_bk>cool
08:59:09  <mrb_bk>peace dudes
08:59:27  * mikealquit (Quit: Leaving.)
09:01:26  <CIA-115>node: Andreas Madsen master * rc8108aa / (lib/cluster.js test/simple/test-child-process-internal.js): child_process: fix typo in internal message event name - http://git.io/ZoBhZQ
09:04:02  <bnoordhuis>mrb_bk: failing in what respect?
09:11:04  <indutny>bnoordhuis: morning!
09:11:13  <bnoordhuis>indutny: hey
09:11:21  <indutny>bnoordhuis: https://github.com/joyent/node/pull/2508
09:11:33  <indutny>bnoordhuis: please take a look at comments
09:11:49  <bnoordhuis>i will (eventually)
09:11:58  <bnoordhuis>working to my github notification emails right now
09:12:01  <bnoordhuis>*through
09:12:58  * travis-cijoined
09:12:58  <travis-ci>[travis-ci] joyent/node#223 (master - c8108aa : Andreas Madsen): The build is still failing.
09:12:58  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/4d49469...c8108aa
09:12:58  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/505780
09:12:58  * travis-cipart
09:16:57  <CIA-115>libuv: Daisuke Murase master * re8494dd / src/unix/core.c :
09:16:57  <CIA-115>libuv: unix: use EVRUN_ONCE in uv_run_once()
09:16:57  <CIA-115>libuv: EVRUN_NOWAIT means "poll and don't block". Use EVRUN_ONCE instead, "wait for
09:16:57  <CIA-115>libuv: single event". - http://git.io/pJczAg
09:18:33  * travis-cijoined
09:18:34  <travis-ci>[travis-ci] joyent/libuv#25 (master - e8494dd : Daisuke Murase): The build is still failing.
09:18:34  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/51ea46d...e8494dd
09:18:34  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/505818
09:18:34  * travis-cipart
09:43:47  <CIA-115>node: Maciej Małecki v0.6 * rb073989 / Makefile :
09:43:47  <CIA-115>node: makefile: ignore `lib/punycode.js` while linting
09:43:47  <CIA-115>node: `punycode` is a third party code which generates a lot of lint errors.
09:43:47  <CIA-115>node: Upstream was contacted in order to fix it in bestiejs/punycode.js#6, but
09:43:47  <CIA-115>node: request was denied.
09:43:48  <CIA-115>node: Therefore, it's reasonable to exclude this file from linting process.
09:43:49  <CIA-115>node: Ref #2456. - http://git.io/88Rr7Q
09:43:51  <CIA-115>node: Mathias Bynens master * r8abb73e / lib/punycode.js : punycode: Update to v0.3.0 - http://git.io/6PhnLQ
09:45:57  * dshaw_joined
09:51:33  <bnoordhuis>indutny: ping
09:51:38  * travis-cijoined
09:51:39  <travis-ci>[travis-ci] joyent/node#224 (v0.6 - b073989 : Maciej Małecki): The build was broken.
09:51:39  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/8cca30f...b073989
09:51:39  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/505908
09:51:39  * travis-cipart
09:55:29  * travis-cijoined
09:55:29  <travis-ci>[travis-ci] joyent/node#225 (master - 8abb73e : Mathias Bynens): The build is still failing.
09:55:29  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/c8108aa...8abb73e
09:55:29  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/505917
09:55:29  * travis-cipart
09:59:48  <indutny>bnoordhuis: pong
10:00:42  <bnoordhuis>indutny: re #2508
10:01:03  <indutny>bnoordhuis: ok, what do you want to know?
10:01:04  <indutny>:)
10:01:17  <bnoordhuis>for the record, do you see the zlib destructor being called?
10:01:37  <bnoordhuis>i mean, one destructor call for every constructor call
10:03:25  <indutny>bnoordhuis: with proposed patch? yes?
10:03:33  <indutny>bnoordhuis: w eio poll req limit, no
10:03:38  <indutny>bnoordhuis: I see only 10 destructors
10:04:02  <bnoordhuis>did you test it with master or v0.6?
10:04:29  <indutny>bnoordhuis: it fails with master, and works fine with v0.6
10:04:58  <indutny>bnoordhuis: because of uv changes
10:05:02  <indutny>bnoordhuis: I think ^
10:05:24  <bnoordhuis>yes, that sounds plausible
10:05:41  <indutny>bnoordhuis: may be consider removing that limitation
10:05:51  <indutny>bnoordhuis: tests are passing w/o it, at least on my side
10:06:02  <indutny>bnoordhuis: if you still want a limit - you can use timeout limit
10:06:22  <bnoordhuis>it's been a while but i remember that limit being added for a reason
10:06:29  <bnoordhuis>i'll look into it
10:06:30  <indutny>bnoordhuis: there're eio-race test
10:07:11  <indutny>bnoordhuis: ok
10:07:12  <indutny>thank you!
10:18:28  <indutny>bnoordhuis: btw, we should merge v0.6 into master before 0.7.0
10:18:42  <indutny>bnoordhuis: and it'll be good if my zlib's .reset() patch will be merged too
10:18:55  <bnoordhuis>indutny: yes, i'm going to do that today
10:19:06  <indutny>bnoordhuis: k
10:19:10  <bnoordhuis>you should discuss that zlib patch with isaacs
10:19:22  <indutny>he was up for .reset()
10:19:26  <indutny>not sure about C++ style
10:19:30  <indutny>but lets wait for him
10:19:34  <indutny>anyway
10:48:00  <indutny>bnoordhuis: what bout process.stdin issue
10:48:12  <indutny>bnoordhuis: can you please remind me what we decided yesterday about it?
11:08:55  <bnoordhuis>indutny: that it starts unref'd and that .resume() refs it
11:16:16  <indutny>bnoordhuis: ah, great
11:16:23  <indutny>bnoordhuis: so you can accept my patch? :)
11:18:37  <indutny>bnoordhuis: or better change .pause to .unref here https://github.com/joyent/node/pull/2500 ?
11:18:50  <indutny>bnoordhuis: if you're up for that I can push it myself ;)
11:44:04  * ljacksonquit (*.net *.split)
11:44:04  * txdvquit (*.net *.split)
11:47:07  * piscisaureus_joined
11:47:55  * ljacksonjoined
11:47:55  * txdvjoined
12:09:51  <indutny>bnoordhuis: ping
12:10:18  <bnoordhuis>indutny: pong
12:11:22  <indutny>bnoordhuis: review?
12:11:38  <bnoordhuis>sorry, i'm busy - trying to track down a bug
12:12:01  <indutny>bnoordhuis: need my help?
12:12:30  <indutny>feel free to ping me if I can help you
12:12:40  <bnoordhuis>well... https://gist.github.com/1590128
12:12:50  <bnoordhuis>there seem to be two bugs, really
12:13:17  <bnoordhuis>sometimes the event loop quits prematurely and sometimes the loop hangs at the end of the script
12:14:03  <bnoordhuis>apparently because a single timer doesn't get collected - but it's quite non-deterministic
12:14:03  <indutny>bnoordhuis: ok, I'll look at it
12:15:25  <bnoordhuis>indutny: btw, i remember what the trouble with unref'ing process.stdin is
12:16:11  <bnoordhuis>https://gist.github.com/70252aefa4d34899f38e <- try it with `node -e process.stdin` and `cat | node -e process.stdin`
12:16:23  <piscisaureus_>bnoordhuis: https://github.com/joyent/node/issues/2507#issuecomment-3445657
12:16:35  <piscisaureus_>bnoordhuis: can you see if on unix the error is the same?
12:16:57  <indutny>bnoordhuis: ok, one sec
12:19:16  <piscisaureus_>bnoordhuis: re the ref bug - we should really have that libuv patch that tracks refed/unrefed handles
12:20:31  <indutny>bnoordhuis: so what's about that bug?
12:20:37  <bnoordhuis>piscisaureus_: what patch is that?
12:20:38  <bnoordhuis>indutny: ?
12:20:53  <indutny>bnoordhuis: about stdin
12:21:00  <piscisaureus_>bnoordhuis: the patch you were working on a couple of weeks ago
12:21:49  <bnoordhuis>piscisaureus_: oh, that one - i can merge it later today
12:21:59  <bnoordhuis>indutny: have you tested the patch?
12:22:43  <bnoordhuis>the issue is that .unref() doesn't quite work if stdin is a pipe (or, presumably, a file)
12:23:03  <indutny>bnoordhuis: oh
12:26:54  <indutny>bnoordhuis: I can't see how it's different from 'cat | node'
12:27:37  <indutny>bnoordhuis: or 'cat | python'
12:27:38  <indutny>;)
12:31:41  <indutny>bnoordhuis: am I missing something?
12:32:27  <bnoordhuis>indutny: `node -e process.stdin` <- stdin is a tty
12:32:40  <bnoordhuis>`cat | node -e process.stdin` <- stdin is a pipe
12:32:51  <bnoordhuis>if it's a tty, process.stdin is a tty.ReadStream
12:32:57  <bnoordhuis>if it's a pipe, it's a net.Stream
12:33:31  <bnoordhuis>oh, and with `node -e process.stdin < /dev/null` it's a fs.ReadStream
12:33:45  <indutny>bnoordhuis: we can handle that
12:33:56  <indutny>bnoordhuis: few lines above in your patch
12:34:14  <indutny>bnoordhuis: in case 'TTY': section
12:34:36  * piscisaureus_quit (Ping timeout: 276 seconds)
12:34:39  <bnoordhuis>... yes ... but then it's still broken for pipes and files
12:34:54  * piscisaureus_joined
12:35:15  <indutny>bnoordhuis: but howwww??
12:35:39  <indutny>bnoordhuis: can you explain please? should .unref and .ref be implemented for them?
12:35:43  <indutny>or what?
12:36:35  <indutny>bnoordhuis: ./node -e 'process.stdin.on("data", function(c) {console.log(c);})'< /tmp/1.js
12:36:42  <indutny>bnoordhuis: ^ will output nothing
12:36:52  <indutny>bnoordhuis: ./node -e 'process.stdin.on("data", function(c) {console.log(c);});process.stdin.resume()'< /tmp/1.js
12:36:57  <bnoordhuis>indutny: you need to call process.stdin.resume() first
12:36:57  <indutny>bnoordhuis: ^ will output buffer
12:37:13  <bnoordhuis>yes...
12:37:15  <indutny>bnoordhuis: yes, that's how it works for both tty and streams
12:37:18  <bnoordhuis>okay, let's take a step back
12:37:43  <bnoordhuis>the problem is that simply referencing process.stdin makes the event loop not quit
12:38:00  <indutny>not only
12:38:06  <indutny>that is a consequence
12:38:10  <bnoordhuis>well?
12:38:13  <indutny>of low-level API change
12:38:27  <indutny>:)
12:38:40  <bnoordhuis>so what is the problem according to you?
12:39:36  <indutny>bnoordhuis: process.stdin should not receive anything until .resume() will be called
12:39:46  <indutny>bnoordhuis: so it's kinda paused initially
12:40:06  <indutny>bnoordhuis: and that behaviour is broken
12:40:18  <bnoordhuis>how so?
12:40:37  <indutny>bnoordhuis: ahh, snap . sorry, I was wrong
12:40:44  <indutny>bnoordhuis: it's still paused
12:40:57  <indutny>ok, I agree with you
12:41:00  <bnoordhuis>good
12:41:21  <bnoordhuis>now the problem is that process.stdin can be three different object types
12:41:42  <bnoordhuis>it's easy for tty.ReadStream, simply unref it
12:41:51  <indutny>as I can see two non-TTY types works fine without unrefing, right?
12:42:26  <bnoordhuis>does `cat | node -e process.stdin` hang for you?
12:43:10  <indutny>until ctrl+c
12:43:15  <indutny>or ctrl+d
12:43:21  <bnoordhuis>exactly
12:43:32  <indutny>same behaviour with 'cat | node'
12:43:47  <bnoordhuis>yes, but `node` without arguments starts the repl
12:44:06  <indutny>bnoordhuis:
12:44:20  <indutny>~/Code/git/indutny/node > cat | ~/.node/0.4.12/bin/node
12:44:20  <indutny>readline.js:80
12:44:20  <indutny> tty.setRawMode(true);
12:44:20  <indutny> ^
12:44:20  <indutny>Error: ENOTTY, Inappropriate ioctl for device
12:44:22  <indutny> at new Interface (readline.js:80:9)
12:44:25  <indutny> at Object.createInterface (readline.js:38:10)
12:44:32  <bnoordhuis>okay, bother piscisaureus_ about it - i'm off shopping, the wife's waiting :)
12:44:40  <indutny>heh
12:44:44  <indutny>have a nice shopping day :)
12:44:48  <indutny>and good luck
12:44:53  <bnoordhuis>back in an hour or so
12:45:38  <txdv>sounds like his wife is shopping
12:54:04  * piscisaureus_quit (Read error: Operation timed out)
13:09:20  <txdv>is BUILDING_UV_SHARED used at all?
13:09:24  <txdv>\doesnt seem to me like that
13:16:27  <indutny>bnoordhuis: I'm not sure if that helps you
13:16:49  <indutny>bnoordhuis: but if you'll insert clearTimeout(to) before this line https://gist.github.com/1590128#L20
13:16:53  <indutny>bnoordhuis: test will be fixed
13:17:32  * ljacksonquit (Ping timeout: 240 seconds)
13:20:57  * ljacksonjoined
13:28:48  <indutny>bnoordhuis: no, it won't be
13:29:08  <indutny>bnoordhuis: that has helped reusing Timer, instead of creating new one
13:36:50  <bnoordhuis>indutny: indeed
13:41:49  <indutny>bnoordhuis: welcome bck :)
13:42:12  <bnoordhuis>thank you :)
13:43:01  <txdv>speed shopping
13:43:35  <mmalecki>bnoordhuis has an algorithm for that!
13:43:39  <mmalecki>also, morning!
13:51:01  * bradleymeckjoined
13:56:30  <txdv>no saurus here
13:56:31  <txdv>:(
13:56:32  <indutny>bnoordhuis: it's odd, but I added logging to timer's state change
13:56:44  <indutny>bnoordhuis: and not every ref is followed by unref
13:56:56  <indutny>bnoordhuis: actually, refs count = unrefs count + 1
13:57:05  <bnoordhuis>indutny: it's odd, innit?
13:57:09  * bradleymeckquit (Ping timeout: 276 seconds)
13:57:16  <indutny>bnoordhuis: yes
13:57:22  <indutny>bnoordhuis: odd that loop exits
13:57:43  <indutny>bnoordhuis: going to add logging to uv_unref
13:58:34  <indutny>bnoordhuis: sorry, this time I'll go shopping with my wife
13:58:35  <indutny>:D
13:59:00  <txdv>bnoordhuis: I removed that 'dead code' in the read_watcher
13:59:01  <bnoordhuis>tell her i said hi
13:59:08  <bnoordhuis>and that last night was really fun
13:59:18  <txdv>fixed that already but most probably pushed it to the wrong branch
13:59:43  <bnoordhuis>txdv: i haven't made up my mind about that patch yet
13:59:58  <indutny>bnoordhuis: ?
14:00:03  <mmalecki>lol
14:00:24  <indutny>bnoordhuis: be careful :) I'm quite agressive when someone is talking about my wife
14:00:24  <bnoordhuis>indutny: just teasing :)
14:00:36  <mmalecki>bnoordhuis: thanks for landing my patch and sorry about not looking for other typos - I'm pretty sure I did some grepping :/
14:00:47  <bnoordhuis>txdv: one thing i don't like is that it adds another field
14:00:54  <indutny>bbiab
14:00:57  <txdv>just like with read/read2
14:00:57  <bnoordhuis>mmalecki: oh well, it happens - i should've paid more attention
14:01:00  <mmalecki>indutny: see ya!
14:01:10  <bnoordhuis>txdv: yeah, i don't really like read2 either
14:01:13  <mmalecki>bnoordhuis: looking at my history, I made a typo in a typo XD
14:01:17  <txdv>bnoordhuis: xD
14:02:41  <txdv>bnoordhuis: what other solution could be there? have two fields, one for the callback, the other for the type of the callback?
14:03:13  <bnoordhuis>txdv: maybe, i don't know
14:03:22  <bnoordhuis>my other objection is that we (as in node) don't need it
14:03:41  <bnoordhuis>and i don't really want to add (and have to maintain) code that we don't use
14:03:42  <txdv>node-ncurses needs it
14:04:19  <txdv>because for now node-ncurses is a hack that works only on unix
14:04:28  <bnoordhuis>sure, but as long as we're bundling libev, you can use ev's read watcher, right?
14:04:33  <bnoordhuis>don't tell me you intend to support windows
14:05:03  <txdv>i dont know if it is possible to implement the read watcher for windows, because I do not know how IOCP works
14:06:10  <txdv>ncurses supports windows, this patch would make it possible to ship node-ncurses for windows
14:06:16  <txdv>if the windows counter part would exist
14:07:43  <bnoordhuis>the windows part would need a bit of effort
14:07:52  * ljacksonquit (Ping timeout: 240 seconds)
14:07:58  <bnoordhuis>and since we don't use it ourselves...
14:08:51  <txdv>who is that ourselves
14:09:17  <txdv>you know ryah is a big ncurses fan xD I guess he will appreciate this
14:09:33  <txdv>once im at my main machine, ill look into the windows bits
14:11:30  * ljacksonjoined
14:22:06  <bnoordhuis>txdv: like i said, i'm not sold yet
14:22:08  <bnoordhuis>there
14:22:27  <bnoordhuis>*there's probably a better solution, like a handle type that lets you watch arbitrary file descriptors
14:22:37  <bnoordhuis>but there are downsides to that approach too
14:31:36  * bradleymeckjoined
14:40:50  <indutny>back
14:52:43  <indutny>bnoordhuis: any luck with timers?
14:53:09  <bnoordhuis>indutny: no, i'm working on something else atm
14:55:19  <indutny>л
14:55:21  <indutny>k
15:07:16  * benviejoined
15:15:48  <txdv>bnoordhuis: what downsides can you come up on the fly?
15:18:17  <bnoordhuis>txdv: for example that a kqueue fd is not embeddable in another kqueue
15:26:30  <indutny>bnoordhuis: fck, that timer bug isn't showing when running through gdb
15:26:44  <bnoordhuis>indutny: it's annoying, isn't it? :)
15:26:55  <txdv>bugs learned how to troll developers
15:27:28  <indutny>bnoordhuis: yeah
15:29:48  <indutny>bnoordhuis: oh, looks like uv_unref is often called when ev->activecnt == 1
15:30:43  * AndreasMadsenjoined
15:40:20  * mattstevensjoined
15:48:38  <txdv>bnoordhuis: why not then a function call for streams which returns a read watcher, it is then already tight to the loop
15:52:19  <txdv>bnoordhuis: basically a handle type that lets you watcher arbitrary streams?
15:52:49  <indutny>bnoordhuis: what about eio queue limit, btw?
15:52:55  <indutny>ryah: yt?
15:57:32  <indutny>bnoordhuis: looks like that timers bug is going below zero activecnt
15:57:45  <indutny>bnoordhuis: I referenced loop 3 times before testing
15:57:48  <indutny>bnoordhuis: and still exits :)
15:58:35  <bnoordhuis>indutny: yes, the ev loop's activecnt field is -1 when it hangs
15:59:09  * piscisaureus_joined
16:00:11  <indutny>bnoordhuis: it's should be much lower
16:00:15  <indutny>:0
16:00:21  <indutny>bnoordhuis: does it hangs in ev_verify?
16:00:44  <bnoordhuis>no, in epoll_wait
16:00:59  <indutny>oh
16:01:15  <indutny>bnoordhuis: btw, no hang ups on osx
16:03:12  <bnoordhuis>indutny: you mean it never hangs after printing "exiting properly after 100 iterations"?
16:03:32  <indutny>bnoordhuis: yes
16:03:37  <indutny>bnoordhuis: on osx
16:04:09  <indutny>oh, random bugs are so random
16:05:26  <indutny>oohh
16:05:30  <indutny>I'm seeing boggarts! :)
16:06:26  <indutny>bnoordhuis:
16:06:32  <indutny>#0 ev_unref (loop=0x100559940) at src/unix/ev/ev.c:2552
16:06:32  <indutny>#1 0x00000001003130f9 in ev_stop (loop=0x100559940, w=0x100a0f388) at src/unix/ev/ev.c:2654
16:06:35  <indutny>#2 0x00000001003133eb in ev_timer_stop (loop=0x100559940, w=0x100a0f388) at src/unix/ev/ev.c:2752
16:06:38  * piscisaureus_quit (Ping timeout: 260 seconds)
16:06:39  <indutny>#3 0x0000000100312488 in timers_reify (loop=0x100559940) at src/unix/ev/ev.c:2200
16:06:42  <indutny>that's the traceof boggart
16:06:58  <indutny>activecnt=-1 here
16:07:03  <bnoordhuis>yes, i saw that too
16:07:21  <indutny>bnoordhuis: so probably our enemy is timer_reify
16:07:36  <indutny>it seems to be conditionally unreferencing loop
16:07:45  <bnoordhuis>well... node and libuv both ref/unref timers
16:07:54  <bnoordhuis>also conditionally
16:07:55  <indutny>bnoordhuis: node does that right
16:08:14  <indutny>bnoordhuis: and somewhere inside libuv things becomes broken
16:08:39  <indutny>bnoordhuis: probably node does it in places where it should not do
16:08:47  <indutny>hm...
16:08:52  <bnoordhuis>it's probably something like that
16:08:59  <bnoordhuis>the question is, why does it only happen sometimes? :/
16:09:00  <indutny>but logic seems to be so correct...
16:09:03  <indutny>:)
16:09:25  <indutny>bnoordhuis: that happens when timer expires
16:09:38  <indutny>i.e. reify stops timer when it's time < now
16:10:24  <indutny>bnoordhuis: and we are catching state changes only between our own actions
16:10:28  <indutny>not that internal stuff
16:10:49  <bnoordhuis>it's probably a libuv bug
16:11:02  <bnoordhuis>because it still happens if you disable all the refs and unrefs in node
16:11:55  <indutny>bnoordhuis: really?
16:11:59  <indutny>bnoordhuis: it hangs for me
16:12:03  <indutny>bnoordhuis: if I do so
16:12:52  <indutny>bnoordhuis: I'll try disabling that unreferencing in ev
16:14:19  <indutny>bnoordhuis: I think we should not rely on ->active in node
16:14:28  <indutny>bnoordhuis: as it may change w/o our actions
16:14:40  <indutny>verifying it before and after action is ok
16:14:50  <indutny>but between actions seems to be buggy
16:15:12  <bnoordhuis>well, that's easy to test
16:15:55  <indutny>bnoordhuis: yeah, lets add assertions
16:16:11  <indutny>assert(active_ = uv_is_active())
16:18:56  <indutny>bnoordhuis: or even better, just do StateChange before actions too
16:19:10  <indutny>but I may be wrong
16:23:58  <bnoordhuis>indutny: got it
16:25:11  <bnoordhuis>indutny: https://gist.github.com/0000731c7df6b7876601
16:26:06  <indutny>bnoordhuis: so not relying on internal state was helpful? :)
16:26:27  <bnoordhuis>apparently
16:26:37  <bnoordhuis>though i still don't quite understand how libev manages to fuck it up
16:26:44  <indutny>bnoordhuis: haha
16:26:56  <indutny>bnoordhuis: yes, but at least you've caught a boggart! :)
16:27:27  <indutny>good job, man
16:27:49  <bnoordhuis>thanks :)
16:28:28  <bnoordhuis>now i'll go and try to minimize the patch
16:28:53  <indutny>k
16:29:19  <indutny>please take a look at my eio queue issue, as we'll discuss it once ryah will be online
16:29:22  <indutny>bnoordhuis: ^
16:29:26  * dshaw_quit (Quit: Leaving.)
16:32:14  <bnoordhuis>indutny: sure
16:43:34  <txdv>bnoordhuis: do you want to see an implementation where you can create a read_watcher handle from a stream?
17:02:51  * isaacsjoined
17:05:41  * perezdjoined
17:05:42  * perezdquit (Excess Flood)
17:05:57  * perezdjoined
17:05:57  * perezdquit (Excess Flood)
17:06:30  * perezdjoined
17:06:55  <mmalecki>any word on a release?
17:10:24  <AndreasMadsen>Please remind ryah about https://github.com/joyent/node/pull/2470
17:13:46  <isaacs>indutny: https://github.com/joyent/node/pull/2508 <-- nice find
17:18:24  * slaskisquit (Quit: slaskis)
17:19:42  <isaacs>mmalecki: waiting on this, mostly: http://codereview.chromium.org/9148006/#ps3001 /cc ErikCorryV8 indutny
17:19:56  <isaacs>mmalecki: that's the highest priority issue for 0.6.8
17:20:30  <mmalecki>isaacs: I mean 0.7.0
17:20:52  <isaacs>oh, that
17:20:56  <isaacs>soon, i think
17:21:08  <isaacs>this week or next week, last i heard.
17:21:34  <isaacs>mmalecki: but what's on master is basically what's going to be in 0.7.0, if you wnat to start testing it out
17:21:53  <mmalecki>isaacs: I want to upload 0.7.0 to travis asap
17:22:09  <mmalecki>isaacs: so that people can start testing their stuff out
17:22:15  <mmalecki>and I'm running master already :)
17:22:27  <isaacs>awesome. also, i'm not sure it's decided, but we might abandon the even/odd thing, in favor of just branching, and whatever the most recent branch is is the "stable api" branch
17:22:28  * ErikCorryV8quit (Ping timeout: 258 seconds)
17:22:46  <isaacs>probably no one's going to use 0.7, since it's odd ):
17:22:56  * dapjoined
17:23:03  <isaacs>even when 0.7.10 is the most stable version of node ever.
17:23:06  <mmalecki>isaacs: I will :)
17:23:25  <isaacs>and then 0.8 will come out, and be different, and unstable, and they'll all be upset.
17:23:26  <isaacs>oh well.
17:24:14  <mmalecki>isaacs: well, I don't want to find myself porting all stuff again, that's why I decided to use master
17:24:25  <isaacs>yep. good move :)
17:24:34  <isaacs>i need another round of npm testing on it, too
17:24:46  <pquerna>i think there is value in odds
17:24:52  <mmalecki>isaacs: actually, I might have a bug report for you
17:24:52  <pquerna>saying you can break the api between patches
17:24:58  <pquerna>while in evens not breaking them
17:25:16  <pquerna>things like the cluster api which were changed a few times right?
17:25:23  <isaacs>pquerna: but only on master.
17:25:29  <isaacs>once 0.7 branches, it'll be locked.
17:25:34  <isaacs>further api experimentation will be done on master.
17:25:45  <mmalecki>oh, damn, I don't
17:25:47  <isaacs>i think v8 is a good model to follow here.
17:25:47  <pquerna>but you'd never have a release of the unstable api then?
17:26:01  <isaacs>right.
17:26:04  <indutny>isaacs: thanks :)
17:26:06  <isaacs>the "unstable api" will be master.
17:26:11  <pquerna>sure
17:26:11  <AndreasMadsen>pquerna: the cluster API has changed very little in between 0.6 and 0.7
17:26:19  <isaacs>and we'll need to just release a lot more often.
17:26:30  <isaacs>like, every month or 6 weeks or so.
17:26:43  <pquerna>just do the chrome thing?
17:26:47  <indutny>isaacs: I ported number collision fix to 3.6
17:26:47  <isaacs>basically, yes.
17:27:01  <indutny>isaacs: waiting for ErikCorry to review it
17:27:06  <isaacs>indutny: yeah, i saw.
17:27:11  <indutny>isaacs: what about zlib reset?
17:27:16  <pquerna>prolly just line up with chrome's cycles too
17:27:21  <isaacs>once that gets the stamp of approval, we'll move forward on 0.6.8
17:27:25  <pquerna>because i'd imagine v8 tries to hit those too right :) ?
17:27:30  <isaacs>pquerna: if we can manage it, yes.
17:27:36  <isaacs>each release should correlate to a new drop of v8
17:27:54  <isaacs>indutny: zlib reset i'm philosophically ok with, but it needs to not go in 0.6
17:27:57  <isaacs>indutny: adds api
17:28:17  <indutny>isaacs: yes, agreed
17:28:26  <indutny>isaacs: what about style changes?
17:28:28  <isaacs>indutny: i haven't reviewed the code carefully, but it looked fairly straightforward. all i'd say is split the style fixes into a separate commit from the feature add.
17:28:42  <indutny>isaacs: yeah, I'll do
17:28:46  <isaacs>indutny: maybe even just put the style fixes into 0.6
17:28:51  <isaacs>since they dont' really change anything.
17:29:08  <isaacs>and then it'll be easier to merge into master and put the zlib reset on top of that. sound reasonable?
17:29:19  * isaacshas bad c++ styles
17:29:56  <indutny>isaacs: yes, sounds good
17:30:02  <indutny>style fixes first, reset later
17:41:02  <indutny>isaacs: &(*in) ?
17:41:07  <indutny>isaacs: what's that ^
17:42:06  <isaacs>indutny: not sure without context. and i gotta run. but it looks like the memory address of (the item in the memory address contained in (the variable named "in"))
17:42:17  <indutny>oh
17:42:20  <isaacs>indutny: so... probably the same as just "in"
17:42:24  <indutny>:)
17:42:24  <isaacs>i dunno
17:42:27  <indutny>ok
17:42:28  <mmalecki>can we backport AndreasMadsen's silent: true patch for fork to 0.6?
17:42:29  <indutny>I'll run tests
17:42:32  <isaacs>k
17:42:34  * dshaw_joined
17:42:53  <isaacs>indutny: my guess would be some kind of type-coercion compiler trick thing
17:44:58  <indutny>k
17:48:07  <indutny>isaacs: done, https://github.com/joyent/node/pull/2514
17:48:29  <isaacs>thanks
17:48:32  <isaacs>i'll review today
17:49:03  <indutny>л
17:49:05  <indutny>k
17:49:06  <indutny>gtg
17:49:18  * isaacsquit (Remote host closed the connection)
17:49:19  <indutny>ttyl
17:49:31  * slaskisjoined
18:11:34  * dapquit (Quit: Leaving.)
18:14:30  * dapjoined
18:17:07  <AndreasMadsen>Please remind ryah about https://github.com/joyent/node/pull/2470
18:21:25  * TooTallNatejoined
18:43:36  * `3rdEdenjoined
18:52:58  <bnoordhuis>remind me... why are the timeout and repeat parameters to the uv_timer_*() functions signed? does it make sense to have a timeout or repeat < 0?
18:53:51  * dapquit (Quit: Leaving.)
18:55:02  <mmalecki>bnoordhuis: well, in case you want to run node on something moving with speed higher than speed of light...
18:55:33  <bnoordhuis>damn tachyons!
18:56:57  <bnoordhuis>"As applications become more dependent on real-time information, developers are looking for the easiest way to build fast, scalable network applications, which is driving tremendous growth in adoption of Node.js," said Ryan Dahl, creator of Node.js and senior engineer at Joyent. "This award illustrates the power of Node.js as the platform of choice for mobile, gaming and e-commerce applications."
18:57:04  <bnoordhuis>^ doesn't really sound like ryah
18:57:33  <bnoordhuis>ryah would've said something like "well... umm... yeah... so... people are like"
18:57:52  <bnoordhuis>joyent's marketing division at work!
18:58:09  <bnoordhuis>it's from http://www.marketwatch.com/story/nodejs-selected-by-infoworld-for-2012-technology-of-the-year-award-2012-01-11 btw
18:58:10  <mmalecki>marketing?
18:58:19  <mmalecki>these funny people in suits?
18:58:55  * dapjoined
18:59:31  <AndreasMadsen>I like that the write Joyent twice
18:59:45  <AndreasMadsen>and InfoWorld
19:03:00  * mikealjoined
19:05:59  <txdv>im not sure, but I think that uv messes around with the callback pointers
19:06:31  <txdv>and this bug doesn't reveal itself if you provide only the same callback pointer to write actions
19:06:58  <bnoordhuis>txdv: what / where?
19:09:40  <txdv>if I do uv_write with different callbacks all the time (pointing to different functions), after 20 times or so it calls some older callbacks instead of the new provided once
19:09:40  * `3rdEdenquit (Read error: Connection reset by peer)
19:10:20  * `3rdEdenjoined
19:10:33  * mikealquit (Quit: Leaving.)
19:10:35  <bnoordhuis>txdv: it's possible that the write callbacks come back in a different order
19:10:57  <igorzi>txdv: is this on windows?
19:11:03  <txdv>linux
19:11:28  <txdv>im not 100% sure yet, but ill post some issue once i am
19:13:46  * mikealjoined
19:13:47  <txdv>so fustrating, not being able to use gdb
19:16:34  <txdv>libuv.so(+0x12862) [0x7fd862] // does someone know how i am supposed to debug something like this?
19:17:12  <rmustacc>Did you strip the dwarf out of libuv?
19:17:26  <txdv>the what?
19:17:37  <rmustacc>The debug information.
19:17:49  <txdv>no
19:17:53  <rmustacc>gdb needs dwarf debug information to understand it.
19:18:04  * bradleymeckquit (Remote host closed the connection)
19:18:06  <rmustacc>If it has it, it should be able to do translations.
19:18:13  <txdv>im running mono and dynamically loading libuv.so with it
19:18:15  <rmustacc>But bnoordhuis would understand gdb much better than me, I just use mdb.
19:18:27  <txdv>this is not a gdb issue, it is a mono issue
19:18:47  <rmustacc>Oh, I misunderstood, I thought you were saying gdb couldn't understand that.
19:21:21  <TooTallNate>mmalecki: so precompiled binaries are working well on travis
19:21:22  <TooTallNate>http://travis-ci.org/rbranson/node-ffi/builds/508055
19:24:10  <mmalecki>TooTallNate: oh? compiled on what system?
19:24:25  <TooTallNate>well, ubuntu, so it's not that impressive :p
19:24:34  <mmalecki>TooTallNate: :)
19:26:32  * slaskisquit (Quit: slaskis)
19:29:43  <mrb_bk>bnoordhuis: re: valgrind failure https://gist.github.com/09b336042c106dd1fe28
19:30:01  <txdv>this bug ... it makes me crazy, doesn't happen when I only read, doesn't happen when I only write, but once I write and read to the same udp socket 20 times, boom
19:30:25  * slaskisjoined
19:35:08  <indutny>igorzi: ya back?
19:35:20  <igorzi>indutny: yep
19:35:52  <indutny>oy
19:35:54  <indutny>yo
19:35:56  <indutny>:)
19:35:57  <indutny>sorry
19:36:08  <indutny>I meant isaacs
19:38:48  <indutny>bnoordhuis: can I merge that?
19:38:54  <indutny>bnoordhuis: https://github.com/joyent/node/pull/2514
19:39:13  <indutny>bnoordhuis: rebased it and commented on function declaration
19:39:47  <bnoordhuis>indutny: commit f79be9d?
19:39:56  <indutny>bnoordhuis: right
19:40:15  <bnoordhuis>indutny: why do you need those typecasts? size_t is wide enough
19:41:09  <indutny>bnoordhuis: ah, got it
19:41:19  <indutny>bnoordhuis: readed your comment wrong
19:42:18  <indutny>bnoordhuis: 825a50e
19:42:22  <indutny>updated
19:43:04  <bnoordhuis>indutny: lgtm
19:43:18  <indutny>bnoordhuis: k
19:45:00  <CIA-115>node: Fedor Indutny v0.6 * r07701e7 / src/node_zlib.cc : zlib: C++ style fixes - http://git.io/mtfjJw
19:45:09  <indutny>woot :)
19:45:39  <indutny>bnoordhuis: may be merge master with 0.6 ?
19:45:54  <indutny>bnoordhuis: going to implement .reset() on top of it
19:46:19  <bnoordhuis>indutny: you mean the other way around? merge v0.6 into master?
19:46:40  <indutny>bnoordhuis: yes
19:46:54  <indutny>bnoordhuis: merging master into v0.6 is interesting though
19:46:55  <indutny>:)
19:47:58  <indutny>bnoordhuis: so?
19:49:08  <bnoordhuis>indutny: go ahead, you're a committer now, right?
19:49:14  <txdv>:(ok it was my fault after all
19:49:15  <txdv>xD
19:51:18  <mmalecki>bringing it up again - would it be possible to backport {silent: true} patch for fork?
19:53:13  * travis-cijoined
19:53:13  <travis-ci>[travis-ci] joyent/node#226 (v0.6 - 07701e7 : Fedor Indutny): The build was fixed.
19:53:13  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/b073989...07701e7
19:53:13  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/508183
19:53:13  * travis-cipart
19:53:41  <AndreasMadsen>Sorry for spaming but:
19:53:41  <AndreasMadsen>Please remind ryah about https://github.com/joyent/node/pull/2470
19:54:32  <mrb_bk>seroiusly?
19:54:53  <mrb_bk>bnoordhuis: I have a patch for the udp issue
19:55:31  <bnoordhuis>mrb_bk: Illegal opcode at address 0x1000 <- odd
19:55:39  <mrb_bk>bnoordhuis: right?
19:55:39  <bnoordhuis>what udp issue?
19:56:00  <mrb_bk>bnoordhuis: I added slab allocation for udp
19:56:04  <mrb_bk>to udp_wrap
19:56:18  <mrb_bk>fixes the issue with fragmented memory and messed up RSS measurement
19:56:21  <bnoordhuis>oh, good
19:56:24  <bnoordhuis>can you PR it?
19:56:28  * mikealquit (Quit: Leaving.)
19:56:31  <mrb_bk>bnoordhuis: sure thing
19:56:41  <mrb_bk>bnoordhuis: I'm new to V8 and out of practice with C++, so be gentle ;)
19:57:07  <mrb_bk>bnoordhuis: it merges cleanly with the v0.6 branch, should work on master too
19:57:10  <bnoordhuis>i'm always gentle
19:57:13  <bnoordhuis>... the first five minutes
19:57:29  <bnoordhuis>but colour me curious
19:57:55  <mrb_bk>hahah
19:58:19  <mrb_bk>bnoordhuis: actually I have one question that maybe you could help me out with
19:58:21  * `3rdEdengets his box crayons
19:58:24  <bnoordhuis>sure, fire away
19:58:53  <mrb_bk>bnoordhuis: it's in re: https://github.com/joyent/node/blob/master/src/udp_wrap.cc#L341
19:59:32  <mrb_bk>bnoordhuis: and https://github.com/joyent/node/blob/master/src/stream_wrap.cc#L219
20:00:02  <bnoordhuis>yes?
20:00:14  <mrb_bk>bnoordhuis: the ReleaseMemory function is not necessary with the slab allocation
20:00:34  <mrb_bk>or at least in the way it's implemented there
20:00:38  <bnoordhuis>yes
20:01:10  <mrb_bk>so the patch I have now comments out that line in ReleaseMemory
20:01:28  <mrb_bk>which actually seems to be fine
20:02:08  <bnoordhuis>if you use slab allocation, that whole function would / should go
20:02:13  <mrb_bk>but I'm wondering if I need to explicitly release it by some means as it's done in stream_wrap
20:02:49  <mrb_bk>bnoordhuis: actually this is stupid, let me just make the PR and we can handle it there
20:02:57  <bnoordhuis>sounds like a plan :)
20:03:43  <indutny>bnoordhuis: can you please review this? https://github.com/indutny/node/commit/9a4329dca4c07c36a5e89e632164b45794ab9071
20:03:52  <mrb_bk>i just anticipate needing a little help with the cleanup methods and getting rid of all of the traces of ReleaseMemory
20:04:06  <indutny>oh, one second
20:04:09  <indutny>don't do it now
20:06:42  <indutny>bnoordhuis: https://github.com/indutny/node/commit/07abc893dcd4f19923ed6fcdb6bbfcd799b8d828
20:06:46  <indutny>that's correct one ^
20:07:12  <indutny>commit text will be different, of course ;)
20:08:00  <bnoordhuis>indutny: lgtm, i think. what were the conflicts?
20:08:28  <indutny>bnoordhuis: # both modified: src/handle_wrap.cc
20:08:28  <indutny># both modified: src/node_zlib.cc
20:08:30  <indutny># both modified: src/process_wrap.cc
20:08:37  <bnoordhuis>yes, i saw that :)
20:08:44  <bnoordhuis>i mean, what conflicted?
20:09:26  <indutny>bnoordhuis: uv_default_loop and Loop
20:09:31  <indutny>bnoordhuis: dictionary in zlib
20:09:38  * isaacsjoined
20:09:44  <bnoordhuis>oh okay, trivial stuff iow
20:09:51  <indutny>bnoordhuis: yes
20:09:56  <bnoordhuis>go ahead and finish it
20:10:21  <indutny>I'm going to run make -j4 and tools/test.py -j4 first
20:11:32  * ljacksonquit (Ping timeout: 240 seconds)
20:14:24  * ljacksonjoined
20:18:30  <indutny>please don't push anything
20:18:33  <indutny>merge in a minute
20:21:20  <CIA-115>node: Fedor Indutny master * r07701e7 / src/node_zlib.cc : zlib: C++ style fixes - http://git.io/mtfjJw
20:21:21  <CIA-115>node: Fedor Indutny master * r9e6957b / (10 files in 4 dirs):
20:21:21  <CIA-115>node: Merge branch 'v0.6'
20:21:21  <CIA-115>node: Conflicts:
20:21:21  <CIA-115>node: src/handle_wrap.cc
20:21:21  <CIA-115>node: src/node_zlib.cc
20:21:21  <CIA-115>node: src/process_wrap.cc - http://git.io/FJmlLA
20:21:24  <indutny>done
20:21:57  <indutny>ryah: yt?
20:27:39  <indutny>bnoordhuis: https://github.com/indutny/node/commit/7d9fc6ddcca8512c8a2d605b7dccd7ab7b0d73b4
20:27:42  <indutny>review?
20:30:09  * isaacsquit (Remote host closed the connection)
20:32:13  <bnoordhuis>indutny: that should probably be three commits: style fixes, .reset() and SetDictionary()
20:32:58  <indutny>bnoordhuis: set dictionary is already implemented
20:33:18  <indutny>bnoordhuis: but I agree, and I'm writing a test right now
20:33:19  * travis-cijoined
20:33:20  <travis-ci>[travis-ci] joyent/node#227 (master - 9e6957b : Fedor Indutny): The build is still failing.
20:33:20  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/8abb73e...9e6957b
20:33:20  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/508327
20:33:20  * travis-cipart
20:33:33  * mikealjoined
20:33:39  <bnoordhuis>indutny: you're adding a new method for it, right?
20:33:55  <indutny>bnoordhuis: yes
20:35:33  * mikealquit (Client Quit)
20:36:03  <bnoordhuis>indutny: right, i see how SetDictionary() ties in with .reset()
20:36:19  <bnoordhuis>sorry, just keep it in a single commit but split off the style fixes
20:36:38  <indutny>bnoordhuis: ok, should I add test in same commit as .reset() ?
20:36:44  <bnoordhuis>indutny: yes
20:36:49  <indutny>k
20:44:19  <indutny>bnoordhuis: https://github.com/joyent/node/pull/2516
20:44:59  <indutny>bnoordhuis: I wonder why all methods on ZCtx class are static, btw
20:45:04  <indutny>bnoordhuis: C-style class
20:45:04  <indutny>:D
20:46:53  <bnoordhuis>yeah, it's just glue for js and zlib
20:48:28  <benvie>weeeee awesome job on node-ffi, playing around with it on Windows
20:49:53  <benvie>oops, TooTallNate: awesome job on node-ffi!
20:50:14  <TooTallNate>benvie: :)
20:50:15  <TooTallNate>thanks
20:50:22  <indutny>bnoordhuis: so should I change it?
20:50:25  <TooTallNate>ya it works fucking beautifully
20:50:31  <TooTallNate>100% tests pass
20:51:05  <TooTallNate>benvie: and it's fun playing around with the kernel32 APIs :p
20:51:13  <benvie>just starting to play around with it now, you did masterfully getting it going crossplatform AND precompiled everywhere
20:51:47  <TooTallNate>benvie: i wanna get some more platforms precompiled, but then i'm gonna be releasing 0.5.0 really soon
20:51:48  <bnoordhuis>indutny: what / why?
20:52:25  <benvie>yeah I figured once you had it ready for OS X it'd be pushed to npm and node-ffi master
20:53:28  <TooTallNate>mmalecki: what platform/arch are the nodejitsu machines?
20:53:50  <TooTallNate>i need to get sunos for the no.de machines
20:53:57  <TooTallNate>but they're not on 0.6.x yet I think
20:55:23  <mmalecki>TooTallNate: sec, I'll check
20:55:35  <mmalecki>TooTallNate: we've 0.6 deployment today :)
20:55:54  <TooTallNate>oh nice timing :)
20:56:29  * slaskisquit (Quit: slaskis)
20:57:33  <mmalecki>TooTallNate: it's Ubuntu. any idea how do I check architecture on Linux?
20:57:50  <bnoordhuis>mmalecki: uname -m
20:58:05  <mmalecki>bnoordhuis: thanks :)
20:58:09  <mmalecki>TooTallNate: x86_64
20:58:31  <TooTallNate>mmalecki: cool thanks
20:58:48  <mmalecki>TooTallNate: not sure if compiling stuff will work - we may not be providing libffi, checking that
20:59:07  <TooTallNate>mmalecki: it's ok, it'll be precompiled, statically bundled
20:59:28  <TooTallNate>so it'll "just work"
20:59:31  <mmalecki>TooTallNate: ok, let's hope it'll work! :)
20:59:36  <mmalecki>TooTallNate: well...
20:59:42  <TooTallNate>well it worked for travis
20:59:55  <TooTallNate>and since I'll be compiling on Ubuntu 64-bit it should be ok
21:00:02  <TooTallNate>but I am curious about other OSs
21:00:06  <TooTallNate>Fedora
21:00:09  <TooTallNate>for example
21:00:10  <indutny>bnoordhuis: vm
21:00:14  <indutny>bnoordhuis: pushing?
21:00:22  <TooTallNate>bnoordhuis: what linux do you use?
21:00:25  <mmalecki>TooTallNate: it's 10.04 LTS
21:00:26  <indutny>bnoordhuis: s/vm/nvm
21:02:42  <bnoordhuis>indutny: ca2a4ed is part style fix, part feature
21:02:50  <bnoordhuis>TooTallNate: also 10.04 lts
21:03:11  <TooTallNate>bnoordhuis: ok thanks
21:03:27  <TooTallNate>i want somewith with a more obsure distro to try my precompiled module
21:03:39  <mmalecki>TooTallNate: fedora works?
21:03:45  <TooTallNate>mmalecki: i haven't tried
21:03:52  <TooTallNate>don't have a VM on my machine for it
21:03:58  <mmalecki>TooTallNate: ok, what do I do to test it?
21:04:14  <TooTallNate>just clone the node-ffi repo
21:04:19  <TooTallNate>checkout the gyp branch
21:04:29  <TooTallNate>npm install (to get the devDeps)
21:04:35  <TooTallNate>and npm test to run the tests
21:04:36  <indutny>bnoordhuis: oh crap
21:04:41  <mmalecki>oh, it has a binary checked in? :(
21:04:44  <indutny>bnoordhuis: you're right
21:05:01  <TooTallNate>mmalecki: im open to a better suggestion
21:05:07  <TooTallNate>this keeps it pretty simple though
21:05:14  <TooTallNate>don't you think?
21:05:49  <mmalecki>TooTallNate: we've already had a nerdfight about that, didn't we :D ?
21:06:02  <TooTallNate>mmalecki: ya :p
21:06:12  <TooTallNate>but still, idk a better solution
21:06:41  <TooTallNate>would you rather have had me say "go to the Downloads tab on GitHub and download the binary for your platform and architecture"?
21:06:50  <mmalecki>TooTallNate: that'd work, yeah
21:07:05  <mmalecki>TooTallNate: testing in a second, just updating node version here
21:07:17  <mmalecki>TooTallNate: but most likely, I'd just compile it
21:07:31  <TooTallNate>mmalecki: exactly, that's what any "advanced" user would do
21:07:39  <TooTallNate>these precompiled binaries are for the n00bs
21:07:42  <TooTallNate>imo
21:08:09  <TooTallNate>just like the precompiled node binaries are for the n00bs
21:08:40  <mmalecki>TooTallNate: ++
21:08:40  <kohai>TooTallNate has 2 beers
21:09:52  * einarosquit (Ping timeout: 248 seconds)
21:13:48  <indutny>bnoordhuis: last one https://github.com/joyent/node/pull/2516
21:14:30  * `3rdEdenquit (Quit: Zzzz)
21:14:49  <indutny>bnoordhuis: woot! https://github.com/bnoordhuis/libuv/commit/1c527d2
21:18:15  <bnoordhuis>indutny: lgtm. maybe as an extra sanity check run the test both with a fresh and a recycled deflate stream
21:18:34  * mmaleckinervously looks at http://github-high-scores.heroku.com/joyent/node/high_scores/
21:18:36  <indutny>bnoordhuis: ok
21:19:49  <indutny>bnoordhuis: pushing
21:19:58  <CIA-115>node: Fedor Indutny master * r71ae175 / (3 files in 3 dirs):
21:19:58  <CIA-115>node: zlib: reset() method for deflate/inflate streams
21:19:58  <CIA-115>node: * ammended test-zlib-dictionary to cover reusing streams - http://git.io/NRBwnQ
21:19:59  <CIA-115>node: Fedor Indutny master * r89556f5 / src/node_zlib.cc : zlib: C++ style fixes for dictionary - http://git.io/Pef9Xw
21:20:02  <bnoordhuis>and i'm signing off for today
21:20:15  <indutny>bnoordhuis: ttyl
21:20:26  <indutny>thanks
21:20:31  <bnoordhuis>my pleasure
21:20:36  <bnoordhuis>sleep tight, fedor
21:20:44  <indutny>oh, yeah
21:20:49  <indutny>time to sleep, definitely
21:20:53  <indutny>you too
21:21:02  <indutny>bye everyone!
21:21:33  <mmalecki>night!
21:21:43  * jklabojoined
21:22:59  <indutny>ryah: please consider looking at https://github.com/joyent/node/pull/2508#issuecomment-3443207 when you'll be online
21:25:59  * jklabopart
21:26:27  <mmalecki>TooTallNate: oh damn, it has no x86_64 binding
21:27:29  * indutnyquit (Ping timeout: 248 seconds)
21:27:37  <TooTallNate>oh :p
21:27:41  <TooTallNate>afraid of that
21:27:46  <TooTallNate>lemme try to compile one real quick
21:27:53  <TooTallNate>what os are you on?
21:29:00  <mmalecki>TooTallNate: fedora
21:29:07  <TooTallNate>cool
21:29:08  <mmalecki>TooTallNate: but try compiling on Ubuntu :)
21:29:16  <TooTallNate>ya, that's what I'm doing
21:29:53  * AndreasMadsenquit (Remote host closed the connection)
21:32:52  * travis-cijoined
21:32:52  <travis-ci>[travis-ci] joyent/node#228 (master - 71ae175 : Fedor Indutny): The build is still failing.
21:32:52  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/9e6957b...71ae175
21:32:52  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/508478
21:32:52  * travis-cipart
21:36:44  <TooTallNate>mmalecki: ok, pull and try again please :)
21:38:04  <mmalecki>TooTallNate: I'm surprised, but tests pass
21:38:18  <TooTallNate>mmalecki++ :)
21:38:18  <kohai>mmalecki has 43 beers
21:38:20  <mmalecki>looks like I might have to revisit my opinions about portability
21:39:12  <TooTallNate>that's pretty sweet :)
21:39:12  <mmalecki>TooTallNate: just curious, what's your glibc version?
21:39:21  <TooTallNate>mmalecki: how do I check?
21:41:26  <TooTallNate>mmalecki: looks like "EGLIBC 2.13-20ubuntu5"
21:41:50  <TooTallNate>omg ubuntu unity is like the worst thing ever
21:41:59  <TooTallNate>what were they thinking
21:42:17  <mmalecki>TooTallNate: ls /lib64/libc-*.so
21:43:38  <TooTallNate>mmalecki: no matches found :\
21:43:55  <mmalecki>TooTallNate: try with s/lib64/lib/
21:45:28  * piscisaureus_joined
21:46:12  <TooTallNate>mmalecki: would it be /lib64/ld-linux-x86-64.so.2
21:46:13  * mikealjoined
21:46:28  <TooTallNate>i dunno, but the file is listed when I `ldd ffi_bindings.node`
21:46:52  <TooTallNate>mmalecki: oh no, it's: libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
21:48:06  <mmalecki>ah, ubuntu has some retarded structure there
21:48:12  <TooTallNate>ya, lol
21:49:37  <mmalecki>well, anyway, I'm glad it works :)
21:49:59  <TooTallNate>mmalecki: cool, ya me too. thanks for testing
21:51:23  <mmalecki>TooTallNate: my pleasure :)
21:55:33  * mikealquit (Quit: Leaving.)
22:00:05  * mikealjoined
22:12:23  * ljacksonquit (Quit: Leaving)
22:48:12  <TooTallNate>is ryah online yet?
22:52:24  <piscisaureus_>igorzi: that stat patch looks good to me. Still not completely did away with the crt but fair enough :-)
22:53:19  <piscisaureus_>igorzi: I think it is actually possible to fill out the st_nlink attribute but I guess it is not really worth the effort and overhead
22:53:25  <piscisaureus_>igorzi++
22:53:26  <kohai>igorzi has 1 beer
23:01:07  <igorzi>piscisaureus_: thx for reviewing
23:02:55  * mikealquit (Quit: Leaving.)
23:14:13  <piscisaureus_>igorzi: btw, does that patch work with long filenames?
23:20:47  <piscisaureus_>igorzi: actually, how many syscalls does it make per stat() now?
23:21:57  <piscisaureus_>igorzi: I bet the answer is 3 :-s
23:28:35  <piscisaureus_>ghe
23:28:39  <piscisaureus_>http://msdn.microsoft.com/en-us/library/ms974559.aspx
23:29:04  <piscisaureus_>"If we Microsoft® Scripting Guys were smart (well, let's face it: if we were smart we'd be the Microsoft Highly-Paid Executive Guys rather than the Microsoft Scripting Guys) you would think that at some point we would learn not to make offhand remarks, unless we were ready and able to back them up. "
23:30:05  <txdv>how do I run a specific test?
23:31:04  * isaacsjoined
23:31:30  <bnoordhuis>txdv: out/Debug/run-tests name-of-test
23:32:02  <txdv>o piscisaureus_ hello, I have a question for you: you introduced BUILDING_UV_SHARED into the code, I assume you did not add support in the makefile system for that?
23:32:04  <bnoordhuis>or `out/Debug/run-tests name-of-test name-of-test` (doesn't start a child process or helpers)
23:32:35  <piscisaureus_>txdv: correct
23:33:02  <piscisaureus_>txdv: BUILDING_UV_SHARED just marks the uv public api as __declspec(dllexport)
23:33:15  <piscisaureus_>txdv: we do not actually support building a dll at this point
23:33:45  <txdv>yeah, that is why I created this issue which should add that support xD
23:33:52  <piscisaureus_>txdv: we only use it for node.exe because node.exe exports stuff for use by native extensions the same way a dll would
23:34:07  <piscisaureus_>txdv: well it kinda is like "we take patches"
23:34:15  <piscisaureus_>txdv: I would take a patch for that
23:35:10  <txdv>piscisaureus_: well, I have added the macros for unix/gcc, but I guess one has to fiddle a lot with make to make something like "make libuv.so" happen
23:35:43  <txdv>nevermind for now
23:35:57  <txdv>im trying to run-tests a specific test and 'it doesn't work'
23:35:57  * piscisaureus__joined
23:35:57  * piscisaureus_quit (Read error: Connection reset by peer)
23:36:14  <txdv>how do I run for example tcp-write-alot.c with run-tests?
23:36:32  <txdv>bentkus@elegancy:node-v0.6.5: ~/Projects/c/libuv $ ./out/Debug/run-tests test-tcp-writealot
23:36:35  <txdv>`test-tcp-writealot` failed: No test with that name: test-tcp-writealot
23:36:55  <piscisaureus__>txdv: probably the test name is called tcp_writealot
23:37:04  <piscisaureus__>txdv: look in test/test-list.h to find all the names
23:37:19  <txdv>indeed, thanks
23:38:26  <paddybyers>txdv piscisaureus__: I want UV_EXTERN to do something on linux because on Android I build with visibility(hidden) by default
23:38:32  <paddybyers>I have a patch for that: https://github.com/paddybyers/node/commit/2721ba1d734e17330efd7c63255c0dea325ce452
23:39:48  <piscisaureus__>paddybyers: you have to split that up
23:40:07  <piscisaureus__>paddybyers: the libuv part goes into libuv, not node
23:40:31  * mattstevensquit (Quit: mattstevens)
23:40:41  * mikealjoined
23:40:41  <paddybyers>Yes I know, I'll do a PR from libuv if it'll get accepted
23:40:59  <piscisaureus__>bnoordhuis: what do you think about paddybyers visibility(default) patch above?
23:41:22  <txdv>https://github.com/txdv/libuv/commit/ae9b5f5acec113fc18cda9aa123b8ad715ce871f
23:41:45  <bnoordhuis>piscisaureus__, paddybyers: it needs a gcc 4 check but apart from that i'm in favour
23:42:36  <piscisaureus__>txdv: why do you set visibility(default) when USING_UV_SHARED is set?
23:43:01  <paddybyers>Oh because GCC < 4 doesn't support that attribute?
23:43:20  <txdv>there are 2 options: default or hidden
23:43:45  <txdv>every function marked by UV_EXTERN should be visibile?
23:43:53  <piscisaureus__>txdv: I don't think that matters when you import stuff from a shared library?
23:44:12  <bnoordhuis>paddybyers: i'm 99% sure it's a gcc 4.0 feature
23:44:43  <piscisaureus__>bnoordhuis: do you also think we should build with -fvisibility=hidden when available?
23:44:44  <paddybyers>ok; I have a similar issue for node as well, obviously
23:45:13  <bnoordhuis>piscisaureus__: it's good practice but not essential
23:45:56  <txdv>in boost/python it made loading times faster for shared libraries, but I don't think that we will have the same problem with libuv/c anytime soon
23:47:36  <txdv>if we want to add support for the shared library symbol visibility and the creation of shared libraries, we will have to create 2 sets of object files
23:47:37  <paddybyers>bnoordhuis: yes, it's gcc4; so it's #if __GNUC__ >= 4
23:48:36  <paddybyers>txdv: no, we just need 1 binary the selectively exports the symbols that are needed by addons
23:48:44  <paddybyers>(that)
23:49:53  <txdv>node-ncurses for example relies on the fact that all the ev functions are exported for now
23:50:42  <piscisaureus__>I guess node-ncurses needs an update then :-)
23:51:51  <piscisaureus__>paddybyers: txdv: you figure it out :-) We need separate patches for node and libuv. To actually build an so/dll you need to do some gyp patches. And node will not use a shared library - all the stuff exported from libuv needs to be visible from the node binary.
23:52:26  <txdv>node-ncurses works only for linux, because it is using ev_read_watcher object which indicates that there is something to read but doesn't actually read anything which is missing on the uv implementation
23:52:55  <paddybyers>piscisaureus__: yes, understood
23:53:07  <txdv>piscisaureus__: what do you want to be visible? only the UV_EXTERN marked functions have to be visible?
23:53:51  <paddybyers>txdv: yes, and then only when ! BUILDING_NODE_EXTENSION
23:54:22  <txdv>when not building not extensions?
23:54:27  <txdv>when not building node extensions?
23:54:42  <paddybyers>txdv: because the extension doesn't need to export the symbol
23:54:58  <paddybyers>node needs to export the symbols, for the extension to link to
23:55:52  <txdv>yeah ok, but should node export all the symbols like uv__ and ev_ and stuff
23:56:50  <paddybyers>txdv: no, the symbols that need to be exported are already marked with NODE_EXTERN, UV_EXTERN, V8_EXTERN etc
23:57:35  <paddybyers>bnoordhuis: do you want this for master or what?
23:58:23  <txdv>in that case you will break node-ncurses
23:59:46  <bnoordhuis>paddybyers: yes, for master