00:17:32  * mikealquit (Quit: Leaving.)
00:21:22  * mikealjoined
00:24:04  * `3rdEdenquit (Quit: Zzz)
00:39:16  * mralephquit (Quit: Leaving.)
00:57:44  * piscisaureus__quit (Ping timeout: 240 seconds)
01:05:51  * bnoordhuisquit (Ping timeout: 276 seconds)
01:22:08  * AndreasMadsenquit (Remote host closed the connection)
03:18:14  * sh1mmerjoined
04:10:56  * mikealquit (Quit: Leaving.)
04:17:18  * brsonjoined
05:15:52  * mikealjoined
05:20:02  * isaacsjoined
05:20:55  * sh1mmerquit (Quit: sh1mmer)
05:36:40  * sh1mmerjoined
05:44:07  * isaacsquit (Quit: isaacs)
06:02:41  * mralephjoined
06:31:32  * mralephquit (Quit: Leaving.)
06:54:38  * sh1mmerquit (Quit: sh1mmer)
07:07:14  <indutny>bnoordhuis: that causes crashes anywa
07:07:34  <indutny>bnordhuis: actually, node gets into infinit loop when I'm trying to delete callback data
07:10:54  <indutny>has anyone seen this?
07:10:54  <indutny>node(9080,0xa0b42540) malloc: *** mmap(size=536870912) failed (error code=12)
07:10:55  <indutny>*** error: can't allocate region
07:10:55  <indutny>*** set a breakpoint in malloc_error_break to debug
07:10:55  <indutny>(libev) cannot allocate 536870912 bytes, aborting.Abort trap
07:11:08  <indutny>libev is trying to allocate 0x20000000
07:13:16  * kuebkjoined
07:29:55  * kuebk1joined
07:33:04  * kuebkquit (Ping timeout: 240 seconds)
07:35:42  <indutny>sc
07:35:44  <indutny>oops, sorry
07:35:55  * kuebk1quit (Ping timeout: 255 seconds)
07:37:58  * kuebkjoined
08:31:20  * mikealquit (Quit: Leaving.)
08:33:20  * bnoordhuisjoined
08:36:34  * brsonquit (Quit: leaving)
08:57:14  * mikealjoined
08:58:50  <bnoordhuis>indutny: node(9080,0xa0b42540) malloc: *** mmap(size=536870912) failed (error code=12) <- errno 12 is ENOMEM
08:59:25  <bnoordhuis>you probably have some per-process limit in effect that disallows large mmaps
09:00:03  <bnoordhuis>check the output of `ulimit -a`
09:04:57  <indutny>bnoordhuis: one sec
09:05:39  <indutny>core file size (blocks, -c) 0
09:05:39  <indutny>data seg size (kbytes, -d) unlimited
09:05:39  <indutny>file size (blocks, -f) unlimited
09:05:39  <indutny>max locked memory (kbytes, -l) unlimited
09:05:39  <indutny>max memory size (kbytes, -m) unlimited
09:05:56  <indutny>open files open files (-n) 256
09:05:56  <indutny>pipe size (512 bytes, -p) 1
09:05:56  <indutny>stack size (kbytes, -s) 8192
09:05:56  <indutny>cpu time (seconds, -t) unlimited
09:05:56  <indutny>max user processes (-u) 266
09:06:00  <indutny>virtual memory (kbytes, -v) unlimited
09:06:11  <indutny>bnoordhuis: ^
09:06:45  <indutny>bnoordhuis: btw, uv_close doesn't work. I mean it fires callback but I'm not able to delete data
09:06:50  <bnoordhuis>okay, maybe it's a system-wide limit
09:06:52  <indutny>probably, because I've self reference here
09:07:03  <bnoordhuis>can you link me to your code?
09:07:13  <indutny>https://github.com/joyent/node/pull/2450
09:07:49  <indutny>bnoordhuis: https://github.com/joyent/node/pull/2450/files#L4R77 <- I've stupid struct here
09:09:26  <bnoordhuis>indutny: https://github.com/joyent/node/pull/2450/files#L3R385 <- why do you unref the loop?
09:09:51  <indutny>bnoordhuis: because it keeps loop up
09:10:14  <indutny>bnoordhuis: but I need to unref it in uv_async_send callback
09:10:25  <indutny>bnoordhuis: it works just fine
09:10:38  <bnoordhuis>indutny: "it keeps loop up" <- "it" being ...?
09:10:40  <indutny>bnoordhuis: except that I use mutexes for mesage processing
09:10:50  <indutny>bnoordhuis: uv_async_init
09:11:35  <indutny>bnoordhuis: or uv_async_send, not sure
09:12:07  <bnoordhuis>indutny: yes, uv_async_init refs the loop
09:13:49  <bnoordhuis>indutny: IsolateDebugger::InitCallback() unrefs the loop of another thread if i read your PR right, that's not safe
09:14:28  <indutny>bnoordhuis: nope
09:14:40  <bnoordhuis>is i->host_->GetLoop() the loop of the current thread?
09:14:50  <indutny>bnoordhuis: in initcallback - yes
09:15:00  <bnoordhuis>okay, so IsolateDebugger::Init() runs in another thread?
09:15:08  <indutny>b https://github.com/joyent/node/pull/2450/files#L3R331
09:15:12  <indutny>bnoordhuis: right
09:15:35  <bnoordhuis>some comments there probably wouldn't hurt :)
09:15:50  <indutny>bnoordhuis: :)
09:17:10  <indutny>bnoordhuis: are mutexes ok?
09:17:42  <bnoordhuis>indutny: if you have some resource that needs mutually exclusive access, sure
09:18:34  <indutny>bnoordhuis: I've struct that I don't want to allocate dynamically :D (actually can't)
09:19:34  <bnoordhuis>indutny: https://github.com/joyent/node/pull/2450/files#L3R440 <- you lock but don't unlock the mutex here
09:19:54  <indutny>bnoordhuis: that's right, I unlock it in async callback
09:20:02  <indutny>L487
09:20:24  <bnoordhuis>indutny: that callback runs in another thread
09:21:10  <indutny>bnoordhuis: yes
09:21:19  <indutny>bnoordhuis: is that bad?
09:21:39  <bnoordhuis>yes - the thread that locks a mutex must also be the one to unlock it
09:21:53  <indutny>bnoordhuis: ohhhhh
09:21:54  <bnoordhuis>anything else is not portable
09:22:01  <indutny>bnoordhuis: lets try uv_close though
09:25:23  <indutny>bnoordhuis: can I delete c->data in it's callback?
09:26:18  <bnoordhuis>indutny: delete / delete[] itself is thread-safe if that is what you mean
09:26:58  <indutny>bnoordhuis: nope, I mean is handle used after uv_close callback or can I safely delete it
09:27:24  <bnoordhuis>indutny: you can delete it in the uv_close callback, that's the whole purpose of the callback :)
09:29:28  <indutny>bnoordhuis: :)
09:29:38  <indutny>bnoordhuis: let me try
09:39:00  <indutny>bnoordhuis: I don't know why, but sometimes it halts
09:39:08  <indutny>bnoordhuis: can you help me debugging it?
09:40:58  <bnoordhuis>indutny: sure
09:41:04  <bnoordhuis>what's the behaviour you're seeing?
09:41:38  <indutny>bnoordhuis: it halts
09:41:44  <indutny>bnoordhuis: I can't even Ctrl+C it
09:41:50  <indutny>pushing it to that PR
09:41:56  <bnoordhuis>roger
09:42:57  <CIA-111>libuv: Ben Noordhuis v0.6 * r38fc6ad / (5 files in 2 dirs):
09:42:57  <CIA-111>libuv: unix: unref fs event watcher
09:42:57  <CIA-111>libuv: Watchers were being ref-counted twice which wasn't harmful in itself but stopped
09:42:57  <CIA-111>libuv: uv_unref() from working like you'd expect it to. - http://git.io/USM3Pw
09:43:26  <indutny>bnoordhuis: https://github.com/indutny/node/commit/6ac7ab8290b3b0ec7723b094d8f296be530d7269
09:43:51  <indutny>bnoordhuis: it's on same branch https://github.com/joyent/node/pull/2450
09:44:04  <bnoordhuis>okay, give me five minutes
09:44:18  <indutny>bnoordhuis: k, try ./node debug lib/fs.js
09:44:23  * travis-cijoined
09:44:23  <travis-ci>[travis-ci] joyent/libuv#21 (v0.6 - 38fc6ad : Ben Noordhuis): The build is still failing.
09:44:23  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/43e3ac5...38fc6ad
09:44:23  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/467337
09:44:23  * travis-cipart
09:44:33  <indutny>brb
09:47:15  * paddybyersjoined
09:48:07  * piscisaureus_joined
09:48:38  * pquernaquit (Ping timeout: 252 seconds)
09:48:39  <indutny>back :)
09:49:34  <bnoordhuis>almost done
09:50:25  <CIA-111>node: Ben Noordhuis v0.6 * r41f2725 / (10 files in 5 dirs): uv: upgrade to 38fc6ad - http://git.io/3C_Vzw
09:50:26  <CIA-111>node: Ben Noordhuis v0.6 * r884f689 / test/simple/test-fs-watch.js :
09:50:26  <CIA-111>node: test: add #2293 regression test
09:50:26  <CIA-111>node: Creating a file event watcher with fs.watch({persistent:false}) should not block
09:50:26  <CIA-111>node: the event loop. - http://git.io/VA68OA
09:52:09  <indutny>going to wash dishes
09:52:16  <indutny>:D
09:52:20  <indutny>brb
09:52:20  <bnoordhuis>indutny: do mine while you're at it
09:52:30  <indutny>bnoordhuis: haha :)
09:52:39  <bnoordhuis>i'm kidding, you don't have to - i have a wife for that!
09:52:51  <bnoordhuis>mmalecki: why did you take that github irc bot offline?
09:58:02  * travis-cijoined
09:58:02  <travis-ci>[travis-ci] joyent/node#170 (v0.6 - 884f689 : Ben Noordhuis): The build passed.
09:58:02  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/c2fb062...884f689
09:58:02  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/467356
09:58:02  * travis-cipart
10:10:40  <indutny>bnoordhuis: any luck?
10:11:22  <bnoordhuis>indutny: not yet, been multi-tasking between your patch and something else
10:21:49  <indutny>bnoordhuis: np
10:26:45  <indutny>bnoordhuis: actually, it's quite random
10:27:16  <indutny>bnoordhuis: but if I won't call uv_close everything will definitely work
10:27:25  <indutny>bnoordhuis: so deletion doesn't matter here
10:54:03  <indutny>bnoordhuis: sup?
10:54:07  <indutny>:D
10:54:12  <indutny>multi-tasking?
10:54:23  <bnoordhuis>indutny: yes, sorry - working on something openssl related
11:04:58  <mmalecki>bnoordhuis: which one? dmkbot?
11:05:14  <bnoordhuis>mmalecki: the one that reported github issue changes
11:05:21  <mmalecki>bnoordhuis: it was fucked. I can write a new one using kohai.
11:05:50  <bnoordhuis>mmalecki: consider this your top priority from now on
11:05:56  <bnoordhuis>no, i kid - but it was sometimes convenient
11:06:15  <bnoordhuis>(and it made me look like i was actually doing something)
11:06:21  <mmalecki>bnoordhuis: btw, do you know you guys can enable IRC issues on github now?
11:06:45  <bnoordhuis>mmalecki: come again?
11:06:48  <mmalecki>bnoordhuis: like, ootb, no polling and stuff?
11:07:00  <mmalecki>bnoordhuis: you can enable it just like you'd enable commit messages
11:07:31  <mmalecki>bnoordhuis: https://github.com/blog/964-all-of-the-hooks
11:07:41  <bnoordhuis>you probably need to be an admin for that :(
11:07:57  <mmalecki>bnoordhuis: oh, you don't have admin rights? damn
11:08:14  <mmalecki>bnoordhuis: also, it's quite pita, you need to do it through API.
11:08:23  <mmalecki>bnoordhuis: so, I guess it's kohai for now :)
11:09:49  <bnoordhuis>oh well, i'll ask ryah
11:09:59  <mmalecki>bnoordhuis: kohai and hook.io is fun, btw, you might want to give it a try :)
11:10:35  <bnoordhuis>maybe some day (the same day when i have time to check out nodejitsu)
11:11:04  <mmalecki>bnoordhuis: it makes me quite sad
11:12:33  <bnoordhuis>mmalecki: yes, it's sad. but not as sad as, for example, a sheep with a wool allergy
11:12:50  * paddybyersquit (Quit: paddybyers)
11:12:52  <mmalecki>bnoordhuis: oh? there *are* such ships?
11:13:06  <bnoordhuis>mmalecki: sheep, not ships!
11:13:19  <mmalecki>damn, I need coffee
11:13:31  * mmaleckijust woke up
11:13:37  <bnoordhuis>another perfectly fine joke wasted...
11:13:40  <bnoordhuis>now that's sad
11:13:41  <mmalecki>lol
11:13:48  <mmalecki>bnoordhuis: let's do it again.
11:13:59  <mmalecki>bnoordhuis: it makes me quite sad.
11:14:16  <bnoordhuis>it is
11:14:36  <bnoordhuis>but not as sad as those kids were when i stood in front of the orphanage and yelled "hey! is your mother home?"
11:15:13  <mmalecki>bnoordhuis: you're a terrible man :)
11:16:13  <bnoordhuis>i am
11:16:31  <bnoordhuis>i should tell you some time about that present i got for the kid with only one leg
11:16:36  <bnoordhuis>(it was a football)
11:17:07  <mmalecki>bnoordhuis: lol. there are people playing football with one leg, btw
11:17:13  <mmalecki>I find it funny
11:17:28  <bnoordhuis>the mind boggles. how does that even work?
11:18:31  <mmalecki>bnoordhuis: http://www.youtube.com/watch?v=OuMqquFdiEk
11:19:01  <bnoordhuis>i'm not 100% positive if i want to click that link
11:19:07  <bnoordhuis>i'd rather watch cute kittens
11:19:42  <mmalecki>bnoordhuis: http://reddit.com/r/aww
11:19:56  <bnoordhuis>heh
11:21:13  <CIA-111>node: Ben Noordhuis v0.6 * r6f8839d / (src/node_crypto.cc src/node_crypto.h):
11:21:13  <CIA-111>node: crypto: add SecureContext.clearOptions() method
11:21:13  <CIA-111>node: SecureContext.setOptions() is backed by SSL_CTX_set_options() which, contrary to
11:21:13  <CIA-111>node: what the name suggests, is additive: it doesn't set options, it adds them to the
11:21:13  <CIA-111>node: already active options.
11:21:13  <CIA-111>node: Hence the need for SecureContext.clearOptions(), which lets you unset active
11:21:14  <CIA-111>node: options. - http://git.io/e3z6VQ
11:21:23  <indutny>yeaah
11:21:23  <bnoordhuis>openssl... openssl makes me sad :(
11:21:28  <mmalecki>bnoordhuis: totally offtopic, you think I'd be able to continue my education in netherlands?
11:21:29  <indutny>bnoordhuis: +1
11:21:38  <mmalecki>bnoordhuis: ++
11:21:59  <bnoordhuis>mmalecki: sure, why not?
11:22:06  <indutny>parseFloat(bnoordhuis)+-0.5
11:22:07  <mmalecki>right. I'll ask AvianFlu to bring kohai here. you guys don't even have a beer bot!
11:22:14  <bnoordhuis>indutny: :)
11:22:32  <mmalecki>I wrote the beer plugin, btw
11:22:55  <mmalecki>bnoordhuis: well, I find education quite retarded. I'd suppose my school would have to talk to my new school?
11:23:23  <bnoordhuis>mmalecki: do you want to be an exchange student or do you intend to move permanently?
11:23:40  <mmalecki>bnoordhuis: move permanently.
11:24:34  <bnoordhuis>mmalecki: not 100% sure but i think you simply find a room, pick a study and let your new school have your old school send over your details
11:24:47  <indutny>bnoordhuis: uv_close ;)
11:25:17  <mmalecki>bnoordhuis: makes sense, thanks :)
11:25:24  * pquernajoined
11:28:54  * travis-cijoined
11:28:54  <travis-ci>[travis-ci] joyent/node#171 (v0.6 - 6f8839d : Ben Noordhuis): The build passed.
11:28:54  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/884f689...6f8839d
11:28:54  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/467768
11:28:54  * travis-cipart
11:31:44  <mmalecki>bnoordhuis: btw, any chance of backporting https://github.com/joyent/node/commit/b084322f52e5ecf4a18db56dfadf16036c792918 to 0.6?
11:31:55  <mmalecki>merges cleanly, I checked it
11:32:28  <mmalecki>bnoordhuis: and I talked with Andreas, what he suggested wasn't possible
11:32:58  <bnoordhuis>i suppose so
11:33:02  <bnoordhuis>what do you need it for?
11:33:44  <mmalecki>bnoordhuis: testing haibu-carapace in vows --isolate mode
11:34:04  <CIA-111>node: Ben Noordhuis master * rc123ac0 / (19 files in 11 dirs):
11:34:04  <CIA-111>node: Merge remote-tracking branch 'origin/v0.6'
11:34:04  <CIA-111>node: Conflicts:
11:34:04  <CIA-111>node: src/udp_wrap.cc (+8 more commits...) - http://git.io/IcY0yg
11:34:28  <mmalecki>bnoordhuis: vows spawns each test file in another process and talks with them via stdout. even tho we can supress stdout, it doesn't work for fork because it doesn't use process.stdout
11:35:02  <bnoordhuis>hmm, it's a new feature, not a bug fix
11:35:14  <bnoordhuis>policy for v0.6 is to only land bug fixes, not features
11:36:08  * bnoordhuisis off to lunch
11:36:16  <mmalecki>bnoordhuis: no problem :). enjoy!
11:36:27  * mmaleckiports vows to use fork
11:45:46  * travis-cijoined
11:45:46  <travis-ci>[travis-ci] joyent/node#172 (master - c123ac0 : Ben Noordhuis): The build is still failing.
11:45:46  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/4b3824b...c123ac0
11:45:46  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/467801
11:45:46  * travis-cipart
11:45:50  <mmalecki>I'm out, end of the lesson, talk to you guys later
11:51:08  <indutny>ttyl
12:02:56  * mikealquit (Quit: Leaving.)
12:03:50  * mikealjoined
12:13:16  <indutny>bnoordhuis: ping :)
12:33:06  * piscisaureus__joined
12:48:20  * paddybyersjoined
12:53:20  * paddybyersquit (Quit: paddybyers)
13:53:55  * mikeal1joined
13:53:55  * mikealquit (Read error: Connection reset by peer)
13:58:16  * mikealjoined
13:58:17  * mikeal1quit (Read error: Connection reset by peer)
14:04:31  <piscisaureus__>http://thedailywtf.com/Articles/Classic-WTF-The-Speedup-Loop.aspx
14:04:37  <piscisaureus__>Y we don't have?
14:10:47  <indutny>magical speedup
14:10:59  <indutny>bnoordhuis: yt?
14:18:46  * piscisaureus__changed nick to piscisaureus
14:28:36  <indutny>piscisaureus:may be you can help me?
14:29:09  <piscisaureus>indutny: maybe but I am busy ... can it be dealt with quickly?
14:32:21  <indutny>piscisaureus: ah, that's not so quick
14:43:24  * paddybyersjoined
14:49:43  <indutny>bnoordhuis: looks like there're some limitations for uv_close
14:50:01  <indutny>and it should be called from same thread as uv_async_start was
14:50:10  <piscisaureus>indutny: yes
14:50:40  <indutny>piscisaureus: that's very bad
14:50:44  <piscisaureus>indutny: it's your responsibility to not use uv_async_send after the async handle was closed
14:50:56  <piscisaureus>indutny: no it's not bad
14:50:57  <indutny>piscisaureus: I'm definitely not using it
14:51:13  <indutny>piscisaureus: I'm calling uv_close in uv_async_t watcher
14:51:21  <piscisaureus>indutny: that's also not good
14:51:47  <indutny>piscisaureus: actually, I'm trying to allocate/delete uv_async_t dynamically
14:51:58  <piscisaureus>indutny: why would you do that?
14:52:13  <indutny>piscisaureus: because I need to pass messages from one thread to another
14:52:41  <piscisaureus>indutny: you can only create/delete async watchers from the main thread
14:52:53  <piscisaureus>or whatever from the uv_run() thread
14:53:06  <piscisaureus>indutny: what you need to do is just create one uv_async_t per thread
14:53:14  <indutny>piscisaureus: ok, I'll use mutexes instead
14:53:15  <piscisaureus>and implement a message queue yourself
14:53:28  <indutny>piscisaureus: I'm implementing that for node
14:53:36  <piscisaureus>ahh
14:53:39  <indutny>piscisaureus: isolate debugger, https://github.com/joyent/node/pull/2450
14:53:40  <piscisaureus>that makes a difference :-)
14:53:48  <indutny>piscisaureus: yeah, I think so too :)
14:54:12  <piscisaureus>indutny: maybe you build in a reliable queue
14:54:20  <piscisaureus>indutny: that's for unix
14:55:00  <indutny>piscisaureus: why not just use locks?
14:55:03  <piscisaureus>indutny: on windows it is very easy, we just didn't add any message argument to uv_async_send because libev doesn't support it (besides libev coalesces multiple uv_async_send invocations into a single callback)
14:55:04  <indutny>:)
14:55:44  <piscisaureus>indutny: well - locks are fine.
14:56:01  <indutny>piscisaureus: no message arguments for uv_async_send?
14:56:06  <indutny>piscisaureus: what does it mean?
14:56:12  <indutny>piscisaureus: no ->data property?
14:56:25  <piscisaureus>indutny: well there is a data property
14:56:37  <piscisaureus>indutny: but its not useful if you want to send multiple messsages
14:56:57  <indutny>piscisaureus: yes, that's what I'm talking about
14:56:58  <indutny>:D
14:57:02  <indutny>ok, I'll use mutexes
14:57:21  <piscisaureus>indutny: what you would want to do is uv_async_send(&async, (void*) mymessage)
14:57:55  <piscisaureus>I think ryan is now building some sort of pipe for this shit
14:58:17  <indutny>piscisaureus: oh, so just create one uv_async_t per isolate and send messages over it?
14:58:24  <piscisaureus>yeah
14:58:32  <piscisaureus>that would be my preference
14:58:34  <indutny>piscisaureus: and that won't work on windows :)
14:58:50  <piscisaureus>indutny: no that will be very easy to implement on windows :-)
14:58:57  <piscisaureus>indutny: that won't work on libev
14:59:59  <indutny>piscisaureus: ah, so we need to have some sort of queue inside uv_async_t
15:00:18  <piscisaureus>indutny: well that could be one solution
15:00:49  <piscisaureus>indutny: but first of all you need to coordinate your efforts with ryan, because he is working on uv_pipe_pair for the same purpose
15:01:23  <piscisaureus>indutny: but my two cents, what libev does is create a pipe and and write a byte to it to wake up the target event loop
15:01:38  <piscisaureus>indutny: and then the target event loop scans all the ev_async watchers to see which one has woken up
15:01:57  <piscisaureus>indutny: imho, we could just chop that up and actually write a pointer to that pipe
15:02:10  <piscisaureus>indutny: .. which the main thread then reads
15:02:26  <indutny>piscisaureus: hm...
15:02:41  <indutny>ryah: ping pong
15:02:48  <indutny>:D
15:02:53  <piscisaureus>indutny: ryah is definitely asleep
15:13:30  <indutny>piscisaureus: ok updated patch
15:13:34  <indutny>piscisaureus: https://github.com/joyent/node/pull/2450
15:13:56  <indutny>I've shown it to bnoordhuis
15:18:27  <indutny>brb
15:22:00  * paddybyersquit (Quit: paddybyers)
15:36:43  * kuebkpart
15:43:59  <indutny>back
16:22:24  * AndreasMadsenjoined
16:43:44  <bnoordhuis>indutny: still working on that isolates debugger?
16:47:59  <indutny>bnoordhuis:yup
16:48:14  <bnoordhuis>indutny: node: ../deps/uv/src/unix/stream.c:932: uv__read_start_common: Assertion `stream->fd >= 0' failed.
16:48:27  <indutny>bnoordhuis: mm?
16:48:35  <indutny>bnoordhuis: what's that about?
16:48:36  <bnoordhuis>is what happens at startup when i (try to) run `out/Debug/node debug lib/fs.js`
16:49:21  <indutny>bnoordhuis: ah, nvm I fixed uv_close problems
16:49:30  <indutny>bnoordhuis: by using mutex :D
16:50:08  <indutny>bnoordhuis: uv_close can be called only from same thread where uv_async_init was called
16:50:39  <indutny>bnoordhuis: btw, how is better to define struct type?
16:50:45  <bnoordhuis>indutny: yes
16:51:00  <bnoordhuis>uv_async_send is the *only* function you can safely call from another thread
16:51:22  <bnoordhuis>indutny: that typedef is superfluous, just remove it and stick with `struct foo { ... }`
16:52:06  <indutny>bnoordhuis: ok
16:53:45  <indutny>bnoordhuis: removed, pushing
16:54:27  <indutny>bnoordhuis: so I've talked with piscisaureus and he proposed to add message argument for uv_async_send (but I need to contact ryah about this first)
16:55:23  <bnoordhuis>the 'write a pointer' thing? that's a bad idea
16:55:47  <bnoordhuis>if only because the pipe may be too full to contain the entire pointer
16:55:58  <indutny>bnoordhuis: what you would want to do is uv_async_send(&async, (void*) mymessage)
16:56:04  <bnoordhuis>there's a reason why you normally only write a single byte
16:56:11  <indutny>bnoordhuis: that was quote ^^
16:56:20  <indutny>bnoordhuis: oh
16:57:09  <bnoordhuis>indutny: when you do want to pass a message, you update a mutex-protected pointer somewhere, then call uv_async_send() to wake up the other thread
16:57:40  <indutny>bnoordhuis: sounds good, is that better than my solution?
16:57:58  <bnoordhuis>indutny: your solution being uv_async_send(&async, (void*) mymessage)?
16:58:19  <indutny>bnoordhuis: nope, I'm using mutexes and one uv_async_t
16:58:56  <bnoordhuis>have you pushed your latest changes?
16:59:00  <indutny>yep
16:59:21  <indutny>force ppushed
16:59:56  <bnoordhuis>indutny: do IsolateDebugger::ReceiveMessage() and IsolateDebugger::MessageCallback() run in the same thread?
17:00:39  <indutny>bnoordhuis: yep, just added it for code style purposes, because I'm accessing class properties a lot here
17:01:25  * bradleymeckjoined
17:01:30  <bnoordhuis>indutny: you uv_async_init(), then uv_async_send() in IsolateDebugger::ReceiveMessage() - that doesn't make sense
17:01:54  <bnoordhuis>the async handle should be initialized early on in the owning thread
17:01:55  <indutny>bnoordhuis: ah, yep, one sec
17:02:33  <bradleymeck>is there a reason .fork in Node doesn't have stderr / stdout ? all modules that are printing stuff in children makes things a little crazy
17:03:28  <bnoordhuis>bradleymeck: i think you're talking about the same thing mmalecki was asking about earlier today, it's fixed in master
17:03:28  <indutny>bnoordhuis: it doesn't work for some reason
17:03:41  <bradleymeck>bnoordhuis, ooo /me goes to check
17:04:44  <bnoordhuis>bradleymeck: https://github.com/joyent/node/commit/b084322
17:04:47  <indutny>oh I see now
17:04:56  * isaacsjoined
17:05:21  <bnoordhuis>indutny: okay, so for the record
17:05:33  <bnoordhuis>you initialize the async handle early on in the owning thread
17:05:40  <bnoordhuis>you uv_async_send() from the other thread
17:05:47  <indutny>bnoordhuis: aah, that's not so simple
17:05:53  <bnoordhuis>then, the callback runs in the owning thread
17:06:01  <bnoordhuis>(and also call uv_close() from the owning thread)
17:06:23  <indutny>bnoordhuis: I think uv_async_init should be done in same thread where uv_async_send
17:06:27  <indutny>called
17:06:40  <bnoordhuis>why?
17:06:40  <bradleymeck>bnoordhuis, is it possible to listen to them for logging / debugging rather than making them non-existent (and get this in 0.6.x?) ?
17:06:42  <indutny>otherwise it brokes event loop
17:06:51  <indutny>a libev limitation
17:07:15  <bnoordhuis>bradleymeck: are you talking about b084322?
17:07:24  <bnoordhuis>indutny: what do you mean?
17:07:34  <bradleymeck>bnoordhuis, yes im talking about fork's stderr/stdout
17:08:40  <mmalecki>hint: https://github.com/joyent/node/pull/2442
17:09:08  <indutny>bnoordhuis: I don't understand libev fully, but all I see is that node becomes unresponsible when uv_async_t initialized in different thread
17:09:23  * bradleymeckgoes to check 2442
17:09:54  <bnoordhuis>mmalecki: hrm, makes sense i suppose
17:10:19  <mmalecki>bnoordhuis: thank you! :) would it be hard to implement?
17:10:20  <bnoordhuis>indutny: i assure you that's not an issue with libev or libuv :)
17:10:25  <mmalecki>as in, can I implement it?
17:10:42  <indutny>bnoordhuis: ok, so what's that?
17:10:53  <bnoordhuis>mmalecki: you should probably discuss it with ryah, he did most of the work on the current child_process module
17:11:29  <mmalecki>ryah: you around?
17:11:55  <mmalecki>scumbag timezones
17:12:49  <mmalecki>bnoordhuis: I'll give it a try if you promise it'll get me eternal fame
17:12:50  <bnoordhuis>not to mention california slackers
17:13:23  <bnoordhuis>mmalecki: eternal fame and recognition by at least five people
17:13:54  <mmalecki>bnoordhuis: sounds like a deal
17:14:19  <bnoordhuis>indutny: where/when does the IsolateDebugger constructor run?
17:14:52  <indutny>bnoordhuis: that's a good question :) it's called in host thread (i.e. thread that created isolate)
17:16:11  <indutny>bnoordhuis: I updated PR
17:16:14  <indutny>bnoordhuis: have you seen?
17:18:31  <mmalecki>bnoordhuis: but still, is there a chance of getting these fixes to v0.6?
17:21:19  <bnoordhuis>mmalecki: hrm, maybe - i don't really know what the impact is
17:21:56  <mmalecki>bnoordhuis: well, main impact: makes ninjas happy
17:21:59  <bradleymeck>bnoordhuis, unless someone is trying to read it already / really wants their child processes vomitting to the parent stderr/out
17:22:06  <bradleymeck>probably not much
17:22:39  <mmalecki>I also heard that some unicorns will be very pleased.
17:24:09  <bnoordhuis>mmalecki: bring it up tonight when ryah is around and we'll discuss it
17:24:38  <mmalecki>bnoordhuis: ok
17:24:53  <piscisaureus>bnoordhuis: I am heading home
17:25:16  <piscisaureus>bnoordhuis: that means I will not be there at 8pm but if we do the call a little later I can join
17:26:19  <bnoordhuis>indutny: you're still locking a mutex in one thread, then unlocking it in another
17:26:37  <bnoordhuis>piscisaureus: sure, 2030 or 2100?
17:26:43  <piscisaureus>i think 2100
17:26:50  <indutny>bnoordhuis: ah, yeah
17:27:11  <indutny>but how will I call uv_close from same thread where uv_async_send was called?
17:27:13  <bnoordhuis>piscisaureus: right-o, drive safely
17:27:31  <piscisaureus>bnoordhuis: I will forward the message to the train driver
17:27:55  <bnoordhuis>indutny: you don't, you call uv_close() from the owning thread
17:28:07  <indutny>bnoordhuis: owning what? :D
17:28:11  <indutny>uv_async_t?
17:28:32  <bnoordhuis>indutny: assume thread A created the uv_async_t handle and you decide in thread B that you want to close it
17:29:03  <bnoordhuis>what you do is send a message from B to A with uv_async_send() and let A close the handle
17:29:29  <indutny>bnoordhuis: but I'll need to pass handle to thread A
17:29:41  <indutny>bnoordhuis: otherwise I'll need to keep list of all handles created in A
17:30:40  <bnoordhuis>indutny: embed your uv_async_t in a struct foo { uv_mutex_t mutex_; uv_async_t handle_; bool should_delete_; }
17:31:05  <bnoordhuis>grab the mutex, set should_delete_ to true, unlock, call uv_async_send()
17:31:17  <indutny>bnoordhuis: aah, sorry
17:31:37  <indutny>bnoordhuis: forgot that we use one static mutex per class
17:31:39  <indutny>oops
17:31:43  <indutny>s/mutex/uv_async_t
17:32:27  <indutny>but idea is interesting...
17:32:31  <indutny>sorry, looks like I tired a bit
17:32:33  * piscisaureusquit (Ping timeout: 276 seconds)
17:32:36  <bnoordhuis>np
17:33:02  <bnoordhuis>grep the source for container_of and you'll find neat examples of how to embed one struct in another
17:34:04  <AndreasMadsen>bnoordhuis: is there any news on UDP port sharing?
17:34:29  <bnoordhuis>AndreasMadsen: no
17:34:51  <AndreasMadsen>Okay
17:35:02  * TooTallNatejoined
17:38:04  <bnoordhuis>ryah igorzi: crazybertje1984 wants to move the call to 2100 CEST / 1200 PST
17:39:21  <mmalecki>I lol'd way too hard
17:57:38  <indutny>bnoordhuis: container_of is really neat
17:58:40  <bnoordhuis>indutny: it is, isn't it? it's more efficient than stuffing a pointer in handle->data to boot
18:01:40  <indutny>bnoordhuis: yeah
18:01:41  <indutny>one question
18:02:04  <indutny>when I''ll call uv_async_send to invoke ho
18:02:16  <indutny>host thread to uv_close handle how will I close that original handle?
18:02:31  <indutny>I mean I'll use two handles, but how will I close both of them?
18:02:57  <bnoordhuis>indutny: which two handles?
18:03:01  <indutny>should_delete_ doesn't make sense to me
18:04:59  <bnoordhuis>indutny: oh, i just meant it as an example of how to pass messages back and forth
18:05:53  <indutny>bnoordhuis: ah
18:11:28  * AvianFlujoined
18:13:14  * `3rdEdenjoined
18:18:05  * sh1mmerjoined
18:20:39  * bnoordhuisis off to dinner
18:28:42  <indutny>bnoordhuis: once you'll get back - can you take a look at this ? https://github.com/indutny/node/commit/c09efc598532ef1ab6f13948d1edb610c1b013c3
18:29:08  <indutny>bnoordhuis: I bundled mutex inside struct and allocating it dynamically, but from what I see close_cb never gets called
18:38:38  * pquernaquit (Changing host)
18:38:38  * pquernajoined
18:42:14  <indutny>bnoordhuis: probably that's because debuggee process is suspended by v8 debugger
18:42:24  <indutny>bnoordhuis: and event loop never gets released
19:07:53  * sh1mmer_joined
19:07:53  * mralephjoined
19:08:12  * sh1mmer_quit (Remote host closed the connection)
19:08:58  * sh1mmer_joined
19:09:19  * sh1mmer_quit (Remote host closed the connection)
19:09:21  <indutny>mraleph: hey man
19:09:27  * sh1mmer_joined
19:09:57  <indutny>mraleph: can you help me please? I'm trying to find a way to return control back to event loop from DebugMessageHandler
19:10:17  * sh1mmerquit (Ping timeout: 240 seconds)
19:11:27  * sh1mmerjoined
19:13:44  * sh1mmer_quit (Ping timeout: 248 seconds)
19:13:53  * sh1mmer_joined
19:15:48  <mraleph>indutny: resume javascript execution?
19:17:16  <indutny>mraleph: no, back to even tloop
19:17:23  <indutny>mraleph: like pause javascript
19:17:42  <indutny>mraleph: not sure how it should work, probably I misunderstanding things
19:18:02  * sh1mmerquit (Ping timeout: 260 seconds)
19:18:03  * sh1mmer_changed nick to sh1mmer
19:19:19  <indutny>mraleph: for details https://github.com/joyent/node/pull/2450
19:19:48  <indutny>mraleph: here I'm trying to do action in debuggee event loop https://github.com/joyent/node/pull/2450/files#L3R494
19:20:20  <indutny>mraleph: but it's never called, because debuggee event loop is busy
19:20:36  <indutny>mraleph: and I think that v8 debugger holds it
19:24:28  <mraleph>indutny: you should not think, you should look at what happens in debugger like gdb :-)
19:24:42  <indutny>mraleph: ah, I think I should use dispatch callback
19:24:53  <indutny>mraleph: v8 debugger runs while(true) loop
19:24:58  <indutny>mraleph: which is blocking event loop
19:25:21  <mraleph>indutny: well, then the only way to return back to event loop is to exit debugger is not it?
19:25:35  <indutny>mraleph: I hope no
19:25:57  <indutny>mraleph: I may add dispatch handler
19:26:06  <indutny>mraleph: and invoke processmessages after event loop tick
19:26:40  <indutny>mraleph: that's what node was doing until I added commit in my branch :D
19:29:39  <indutny>bnoordhuis: piscisaureus_ can I invoke all queued uv async events somehow?
19:30:19  <indutny>bnoordhuis: piscisaureus_ I need some blocking method, actually
19:32:13  <mmalecki>https://gist.github.com/6695c76213a1ca56bbb4 <- possible patch for fork stdio. opinions?
19:37:25  * mjr_quit (Ping timeout: 252 seconds)
19:43:25  * mikealquit (Quit: Leaving.)
19:49:55  * mikealjoined
19:55:10  <mmalecki>bnoordhuis: you around?
19:55:41  <bnoordhuis>mmalecki: yes
19:56:02  <mmalecki>bnoordhuis: does https://gist.github.com/6695c76213a1ca56bbb4 look good to you?
19:56:25  * mikealquit (Quit: Leaving.)
19:56:28  <bnoordhuis>mmalecki: i think it's a very pretty url, yes
19:56:53  <mmalecki>lol
19:57:02  * mjr_joined
19:57:08  <TooTallNate>mmalecki: why is that needed?
19:57:29  <indutny>bnoordhuis: uv_walk() ? ;)
19:57:33  <TooTallNate>just curious
19:57:43  <mmalecki>TooTallNate: so that fork(...) can have .std{err,out}
19:57:49  <TooTallNate>also, does ben or ryan or anyone have thoughts on: https://github.com/joyent/node/pull/2443 ?
19:57:57  <bnoordhuis>indutny: sorry?
19:58:02  <mmalecki>TooTallNate: specifying -1 just disables them
19:58:10  <indutny>bnoordhuis: just found this https://github.com/joyent/libuv/issues/117
19:58:21  <mmalecki>bnoordhuis: so, thoughts?
19:58:25  <indutny>bnoordhuis: I need some way to invoke pending async watchers in a blocking way
19:58:43  <mmalecki>I should prolly specify customFds = [-1]
19:58:48  <bnoordhuis>indutny: i did some work on that, check my walk-handles branch
19:59:25  <bnoordhuis>mmalecki: you should really talk to ryah about that, he's got a more cohesive / holistic vision of how child_process is supposed to work
20:00:00  <mmalecki>bnoordhuis: well, ok
20:00:03  <bnoordhuis>TooTallNate: i've seen the PR, haven't really formed an opinion yet
20:00:33  <TooTallNate>bnoordhuis: ignore the noise from tj, it's kinda off topic
20:00:41  <TooTallNate>but ok
20:00:57  <mmalecki>ryah: heeey, you around?
20:01:26  <bnoordhuis>TooTallNate: i suppose i kind of dislike that it increases the number of arguments
20:01:59  * mikealjoined
20:02:02  <TooTallNate>bnoordhuis: and i dislike the fact that the first 2 arguments are in reverse order from util.inspect(), but I did that for backwards-compat
20:02:13  <TooTallNate>so i'm open to suggestions
20:02:15  <bnoordhuis>TooTallNate: maybe it should be an option object
20:02:20  <bnoordhuis>but this is me thinking out aloud
20:02:37  <TooTallNate>tj said the same thing, and i agree
20:03:11  <AndreasMadsen>ryah: I would like if you would review cluster2 again, unless there is a purpose with cluster.master.send I don't think it can be improved more.
20:04:02  * igorzi_joined
20:04:50  <bnoordhuis>igorzi piscisaureus_ ryah: call tonight?
20:07:10  <bnoordhuis>indutny: also, https://github.com/bnoordhuis/node/compare/v0.6...print-handles
20:08:25  <igorzi_>bnoordhuis: i won't be able to do the call today (many people in US have a day off on Monday)
20:09:02  <bnoordhuis>igorzi_: oh okay (slackers)
20:09:05  <bnoordhuis>enjoy it :)
20:09:41  <igorzi_>ryah bnoordhuis: are there plans to release 0.6.7 this week?
20:10:04  <mjr_>Still hoping my http parser bug will get fixed before 0.6.7.
20:10:13  * mjr_hopes
20:11:00  <bnoordhuis>mjr_: i understand that last patch didn't work?
20:11:05  <mjr_>sadly, no
20:11:41  * brsonjoined
20:12:05  <mmalecki>so I guess no ryah today?
20:12:20  <mmalecki>it'd be really cool to get this out in 0.6.7.
20:12:29  <indutny>bnoordhuis: oooh, interesting
20:12:42  <txdv>we have to put a gps colar on ryah
20:14:05  <mjr_>At least he bought himself an internet connection for home.
20:14:32  <mmalecki>oh, good. I can't imagine not having internet at home.
20:14:45  <mmalecki>but in my case, home === office, so, well, no way.
20:15:13  <mjr_>I have two internet connections for my home/office, just in case one breaks.
20:15:37  <mmalecki>mjr_: redundancy ftw ftw.
20:15:47  <bnoordhuis>i have neighbours with open access points for that :)
20:15:52  <mmalecki>bnoordhuis++
20:16:25  <mmalecki>AvianFlu: hm. can you bring kohai here with tweets disabled? these poor guys don't even have a beer bot :(
20:16:36  <mjr_>I live on a farm in Hawaii, so there are literally 0 visible wifi signals from my neighbors.
20:16:58  <AvianFlu>mmalecki, sure, just a second
20:17:23  <mmalecki>6 networks here. assuming that WEP === open, 3 open ones
20:17:42  <AvianFlu>lol WEP === open
20:18:17  * kohaijoined
20:18:33  <mmalecki>AvianFlu: ++
20:18:33  <kohai>AvianFlu has 27 internet points
20:18:40  <AvianFlu>tweets are off, too
20:18:49  <mmalecki>AvianFlu: thanks :)
20:19:00  <mmalecki>bnoordhuis: now you have a beer bot! enjoy!
20:19:09  <bnoordhuis>will it report github issues?
20:19:24  <mmalecki>bnoordhuis: one day, yeah
20:19:39  <mmalecki>bnoordhuis: I *can* bring my old bot here.
20:21:47  <indutny>bnoordhuis: omg, I made it
20:21:58  <indutny>ah not
20:22:00  <indutny>bus error
20:23:55  <indutny>gtg
20:23:58  <indutny>ttyl
20:24:48  <mmalecki>indutny: bye!
20:27:11  <piscisaureus_>bnoordhuis: ryah: did you guys already have a call?
20:27:16  <piscisaureus_>or is it not coming?
20:28:22  * isaacsquit (Quit: isaacs)
20:45:27  * isaacsjoined
20:55:40  * mikealquit (Quit: Leaving.)
20:58:57  * brsonquit (Quit: leaving)
21:06:12  * paddybyersjoined
21:10:30  * AndreasMadsenquit (Remote host closed the connection)
21:11:58  <bnoordhuis>piscisaureus_: i don't think los americanos are around
21:12:10  <bnoordhuis>indutny: sleep tight
21:20:30  <piscisaureus_>www.youtube.com/watch?v=h3S4dBk4E1g
21:21:45  * mralephquit (Quit: Leaving.)
21:27:14  <indutny>bnoordhuis: piscisaureus_ https://gist.github.com/ed5b063b93745de089a6
21:31:26  <piscisaureus_>indutny: so why are you allocating 1gb ?
21:33:07  <indutny>piscisaureus_: I'm not
21:33:30  <indutny>piscisaureus_: it's segfaulting on node debug lib/fs.sjs
21:33:33  <indutny>s/sjs/js
21:33:36  <indutny>sometimes
21:34:16  <piscisaureus_>indutny: this is masta I assume
21:34:37  <piscisaureus_>indutny: I am afraid you have to talk to the isolates guys about that, I am busy patching v8
21:34:51  <indutny>piscisaureus_: oh :) ok
21:34:58  <indutny>who are those isolates guys btw?
21:35:04  <piscisaureus_>ben and ryan
21:36:15  <indutny>piscisaureus_: kk
22:02:10  <sh1mmer>it's holiday today I think
22:02:17  <sh1mmer>although somehow I'm in the office
22:11:19  * paddybyersquit (Quit: paddybyers)
22:13:22  * isaacsquit (Quit: isaacs)
22:20:24  * piscisaureus__joined
22:24:33  * einarosquit (*.net *.split)
22:25:28  * einarosjoined
22:31:27  * ircretaryquit (Ping timeout: 244 seconds)
22:31:32  * ircretaryjoined
22:41:22  * pquernaquit (Ping timeout: 252 seconds)
22:42:23  * paddybyersjoined
22:42:23  * pquernajoined
22:45:15  * `3rdEdenquit (Read error: Connection reset by peer)
22:46:01  * `3rdEdenjoined
22:55:58  * AndreasMadsenjoined
22:57:46  * AndreasMadsenquit (Client Quit)
22:57:46  * AndreasMadsenjoined
22:57:46  * AndreasMadsenquit (Client Quit)
23:05:09  * paddybyersquit (Quit: paddybyers)
23:15:43  * igorzi_quit (Quit: Page closed)
23:24:09  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
23:25:52  * piscisaureus__quit (Quit: ~ Trillian Astra - www.trillian.im ~)
23:27:53  * mikealjoined
23:28:22  <bnoordhuis>indutny: re segfault: when does that happen?
23:28:40  <bnoordhuis>also, maybe you should test it with a debug build
23:33:49  <`3rdEden>silly dutch people, shouldn't you be asleep ;)?
23:34:21  <bnoordhuis>yeah, probably. i was up at 05.00 this morning :/
23:35:42  <`3rdEden>o_o
23:35:49  <`3rdEden>that's quite, early
23:37:01  <bnoordhuis>particularly since i didn't go to bed until 2.30 in the morning :)
23:37:30  <bnoordhuis>but hey, sleep is for the weak, i'll sleep when i'm dead and all that
23:38:01  <bnoordhuis>having said that... think i'll be off to bed
23:38:05  <`3rdEden>gnite ben
23:38:33  <bnoordhuis>and you, arnout
23:38:35  <`3rdEden>i'll be passing out soon as well
23:48:17  * bradleymeckquit (Ping timeout: 240 seconds)
23:48:44  * isaacsjoined
23:49:01  * bnoordhuisquit (Ping timeout: 252 seconds)