00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:09:53  * julianduquequit (Ping timeout: 240 seconds)
00:10:17  * mikealquit (Quit: Leaving.)
00:11:39  * mikealjoined
00:12:57  * julianduquejoined
00:15:09  * c4milojoined
00:21:49  * mikealquit (Quit: Leaving.)
00:25:45  * mikealjoined
00:28:47  * dshaw_joined
00:29:57  * dshaw_quit (Read error: Connection reset by peer)
00:30:04  * dshaw_joined
00:31:31  * dshaw_1joined
00:31:31  * dshaw_quit (Read error: Connection reset by peer)
00:32:46  * dshaw_joined
00:32:49  * dshaw_1quit (Read error: Connection reset by peer)
00:34:15  * dshaw_1joined
00:34:27  * dshaw_quit (Read error: Connection reset by peer)
00:35:45  * dshaw_joined
00:35:48  * dshaw_1quit (Read error: Connection reset by peer)
00:37:14  * dshaw_1joined
00:37:14  <kellabyte>what does a status of -1 mean when uv_pipe_connect() calls the uv_connect_cb?
00:37:33  * dshaw_quit (Read error: Connection reset by peer)
00:38:41  * dshaw_joined
00:38:50  * dshaw_1quit (Read error: Connection reset by peer)
00:40:11  * dshaw_1joined
00:40:26  * dshaw_quit (Read error: Connection reset by peer)
00:41:31  * dshaw_1quit (Read error: Connection reset by peer)
00:41:37  * dshaw_joined
00:43:07  * dshaw_1joined
00:43:18  * dshaw_quit (Read error: Connection reset by peer)
00:44:26  * dshaw_1quit (Read error: Connection reset by peer)
00:44:34  * dshaw_joined
00:46:01  * dshaw_quit (Read error: Connection reset by peer)
00:46:03  * dshaw_1joined
00:47:32  * dshaw_joined
00:49:00  * dshaw_2joined
00:49:13  * dshaw_quit (Read error: Connection reset by peer)
00:50:28  * dshaw_joined
00:50:34  * dshaw_2quit (Read error: Connection reset by peer)
00:50:43  <mmalecki>dshaw_: daaamn dude
00:50:52  * dshaw_1quit (Ping timeout: 264 seconds)
00:51:59  * dshaw_1joined
00:52:16  * dshaw_quit (Read error: Connection reset by peer)
00:53:35  <kellabyte>grr so stuck, why isn't this IPC working!
00:56:30  * dshaw_1quit (Ping timeout: 264 seconds)
01:00:13  <kellabyte>anyone awake that knows libuv :/
01:02:35  * kazuponjoined
01:09:20  * abraxasjoined
01:10:07  * st_lukequit (Remote host closed the connection)
01:13:26  * abraxasquit (Ping timeout: 240 seconds)
01:28:59  * stagasjoined
01:35:22  * c4miloquit (Remote host closed the connection)
01:37:34  * abraxasjoined
01:39:19  * c4milojoined
01:52:29  * dshaw_joined
01:56:11  <Domenic_>Assertion failed: !(handle->flags & UV__HANDLE_CLOSING), file src\win\async.c, line 77
01:56:19  <Domenic_>I am betting this means "silly domenic, you forgot ______"
01:56:52  * dshaw_quit (Ping timeout: 246 seconds)
01:59:40  * kazuponquit (Remote host closed the connection)
02:01:48  * c4miloquit (Remote host closed the connection)
02:20:02  * julianduquequit (Ping timeout: 264 seconds)
02:23:36  * philipsquit (Quit: http://ifup.org)
02:24:46  * philipsjoined
02:26:50  * philipsquit (Changing host)
02:26:50  * philipsjoined
02:30:03  * kazuponjoined
02:52:44  * dshaw_joined
02:57:04  * dshaw_quit (Ping timeout: 246 seconds)
02:57:15  * amartensjoined
02:57:15  * amartensquit (Client Quit)
03:13:11  * st_lukejoined
03:23:30  * mikealquit (Quit: Leaving.)
03:30:32  * dshaw_joined
03:33:35  * mikealjoined
03:37:50  * kazuponquit (Remote host closed the connection)
03:42:41  * brsonjoined
03:44:06  * brsonquit (Client Quit)
03:45:57  * dshaw_quit (Quit: Leaving.)
03:46:14  * pfox__joined
03:47:32  <pfox__>ahoy ahoy. so im digging into fs operations in libuv. and for reading/writing.. is there any major advantage to using the uv_fs_* functions, instead of the stream api + uv_pipe_t?
03:51:25  * bnoordhuisjoined
03:54:11  <kellabyte>bnoordhuis: it worked!
03:54:24  <bnoordhuis>kellabyte: what did? the pipe server thing?
03:55:09  <kellabyte>bnoordhuis: yup! although its about 20% more CPU usage than running 4 processes, not sure if pipes is ultimately the best approach for this kind of thing
03:57:08  <bnoordhuis>kellabyte: separate processes that don't interact with one another are probably faster, yes
03:57:22  <kellabyte>bnoordhuis: I have no shared state thats doing any locking in this right now
03:57:32  <kellabyte>bnoordhuis: so the overhead must be coming from the IPC
03:57:45  <pfox__>bnoordhuis: hi. is there any advantage/disadvantage to using uv_fs_read/write for basic file IO, vs the stream api + uv_pipe_t?
03:57:53  <bnoordhuis>yes, that sounds plausible. it's a few extra syscalls
03:58:11  <bnoordhuis>pfox__: you want to write to a pipe?
03:58:36  <kellabyte>bnoordhuis: results here if you want, scroll up for comparison of per process results in setup 1 https://github.com/kellabyte/Haywire#setup-2
03:59:15  <pfox__>bnoordhuis: going off of what's in the uvbook, they're equivelant, right?
03:59:52  <pfox__>uv_fs_open -> create pipe from resulting fd -> use uv_write & uv_read_start/stop w/ uv_pipe_t
03:59:57  <pfox__>vs
04:00:15  <pfox__>uv_fs_open -> create reqs for each call to uv_fs_read, uv_fs_write, etc..
04:01:46  <bnoordhuis>kellabyte: not sure how to interpret the numbers but i like the pretty colors
04:02:20  <bnoordhuis>pfox__: yes, both work - though i can't vouch if the first approach always works on windows
04:02:25  <kellabyte>bnoordhuis: lol
04:02:50  <bnoordhuis>pfox__: with the second approach, the thread pool may become a bottleneck
04:03:27  <bnoordhuis>a call to uv_fs_read, uv_fs_write, etc. translates into a round trip to the thread pool
04:03:31  <pfox__>bnoordhuis: and each uv_loop_t keeps an arbitrary number of threads for the threadpool?
04:03:53  <pfox__>(as always, im a dutiful rust contributor working on io)
04:04:07  <bnoordhuis>not quite arbitrary :)
04:04:19  <kellabyte>bnoordhuis: past test 1 thread with 4 processes 40% cpu for 601K req/s and little over 800 mbps, test 2 4 threads 1 process 60% cpu for 574K req/s and just about 800 mbps, keep in mind the guaranteed network on azure is 800 mbps
04:04:24  <bnoordhuis>the current default thread pool size is 4 on linux, 256 (iirc) on windows
04:04:28  <pfox__>well, *some* number of threads beyond the application's (in this case, the rust scheduler's) control
04:04:33  <bnoordhuis>yep
04:05:20  <bnoordhuis>kellabyte: ah okay, thanks. you didn't happen to profile it, did you?
04:05:36  <bnoordhuis>i'd be curious to know if that 20% is all ipc overhead or that there's something else besides
04:06:02  <bnoordhuis>*if there's
04:06:03  <kellabyte>bnoordhuis: no but I can! its midnight here, maybe tomorrow night I can take a look
04:06:41  <pfox__>bnoordhuis: when are those threads spun up.. when the loop is created? or is it lazilly deferred until io that requires threadpool is requested?
04:06:57  <bnoordhuis>kellabyte: only if you have the time and inclination
04:07:29  <kellabyte>bnoordhuis: I'm always looking to improve the perf and get that 20% back :)
04:08:04  <kellabyte>bnoordhuis: thanks so much for the help! I was super happy I was able to bang it out today :)
04:08:04  <bnoordhuis>pfox__: they're spun up lazily
04:08:11  * kazuponjoined
04:08:39  <bnoordhuis>pfox__: the current thread pool implementation will change in due time btw
04:08:49  <bnoordhuis>but the spinning up lazily thing will stay
04:08:54  <pfox__>ok, thanks.
04:09:03  <bnoordhuis>kellabyte: no problem :)
04:09:12  <pfox__>trying to chart a course that makes sense for rust. i think "less threads beyond our control" is best
04:09:22  <pfox__>but you mention the platform consistency issue.
04:09:25  <pfox__>so, yeah.
04:09:47  <bnoordhuis>fwiw, you can limit the number of threads on unix with the UV_THREADPOOL_SIZE env var
04:10:04  <bnoordhuis>but i'll probably switch it to a scheme where threads get spun up and reaped lazily
04:10:29  <bnoordhuis>i have a work-in-progress branch that spins up anywhere between 1 and 128 "threadlets"
04:10:54  <bnoordhuis>micro-threads with a reduced stack and ultra-low priority that spend nearly all their life sleeping in syscalls
04:11:27  * groundwaterquit (Quit: groundwater)
04:11:37  <bnoordhuis>however (there's always an however), it improves some benchmarks by 5x while it slows down others by 10x :-/
04:11:51  <kellabyte>have it as an option?
04:12:06  <bnoordhuis>yeah, maybe
04:12:22  <bnoordhuis>the thing is, i want libuv to 'just work' - no endless amount of tinkering required
04:12:39  <bnoordhuis>especially because the optimal settings will vary from platform to platform
04:12:57  <kellabyte>yeah, but if you can't find something that doesn't have such drastic pros/cons
04:13:09  <kellabyte>it might make sense to have an auto mode, but a specific api if you want control?
04:13:20  <kellabyte>unless you can find a way to make that situation better
04:13:28  <bnoordhuis>yeah, the thought had crossed my mind
04:13:35  <bnoordhuis>if everything else fails, leave it to the user
04:15:45  <kellabyte>yeah
04:15:55  <kellabyte>give a simple and generally good default
04:18:06  * kazuponquit (Ping timeout: 276 seconds)
04:21:46  * mikealquit (Quit: Leaving.)
04:22:29  * mikealjoined
04:29:12  * mikealquit (Quit: Leaving.)
04:29:54  * mikealjoined
04:31:57  * groundwaterjoined
04:38:20  * mikealquit (Quit: Leaving.)
04:40:31  * mikealjoined
04:45:28  * kazuponjoined
04:49:32  * AvianFluquit (Remote host closed the connection)
04:51:39  * mikealquit (Quit: Leaving.)
04:59:11  * wolfeidaujoined
05:00:45  * wolfeidauquit (Remote host closed the connection)
05:05:06  * mikealjoined
05:05:27  * mikealquit (Client Quit)
05:06:01  * mikealjoined
05:11:31  * groundwaterquit (Quit: groundwater)
05:14:05  * st_lukequit (Remote host closed the connection)
05:20:36  * bajtosjoined
05:25:02  <bnoordhuis>bajtos: morning
05:25:25  <bajtos>bnoordhuis: good morning
05:25:30  <bnoordhuis>how's life?
05:25:35  <bajtos>bnoordhuis: getting up early?
05:25:41  <bnoordhuis>yeah :)
05:25:43  <bajtos>bnoordhuis: life is good :)
05:26:01  <bnoordhuis>okay, good :)
05:26:06  <bnoordhuis>what are you working on this week?
05:26:51  <bajtos>bnoordhuis: fix "slnode install" to handle multiple registries when installing a package via range, e.g. async >= 1.1 < 2.0
05:27:24  <bajtos>bnoordhuis: and then I am also bringing multi-registry support to npm
05:27:47  <bnoordhuis>ah okay. useful work
05:28:06  <bnoordhuis>what's edmond up to?
05:28:14  <bnoordhuis>he should come hang out in #libuv
05:28:23  <bajtos>bnoordhuis: I have no idea
05:29:02  <bajtos>bnoordhuis: he probably should. but then Sam is not hanging out in #libuv too often either, is he?
05:29:49  <bnoordhuis>no indeed
05:30:01  <bnoordhuis>slackers!
05:30:25  <bajtos>:)
05:31:09  <bajtos>I'd say it's not clear what are the benefits of hanging out here, so they don't have motivation to do so ;-)
05:31:51  * EhevuTovquit (Quit: This computer has gone to sleep)
05:49:23  <MI6>joyent/libuv: bnoordhuis created branch jenkins-review-plox - http://git.io/8WTKYQ
06:01:25  * c4milojoined
06:02:31  <bnoordhuis>c'mon jenkins
06:09:31  * st_lukejoined
06:10:21  * st_lukequit (Remote host closed the connection)
06:26:57  * felixgejoined
06:26:57  * felixgequit (Changing host)
06:26:57  * felixgejoined
06:28:16  * stagas_joined
06:28:36  <MI6>joyent/libuv: Ben Noordhuis master * c6adab2 : unix: fix uv__signal_unlock() prototype (+3 more commits) - http://git.io/oRsbzg
06:28:45  * stagasquit (Ping timeout: 276 seconds)
06:28:51  * stagas_changed nick to stagas
06:36:52  * dominictarrjoined
06:39:14  * mikealquit (Quit: Leaving.)
06:46:45  * c4miloquit (Remote host closed the connection)
06:48:50  * c4milojoined
06:57:16  <MI6>joyent/libuv: Ben Noordhuis master * 1510ce8 : unix, windows: allow NULL async callback - http://git.io/6lyFFQ
06:57:47  * c4miloquit (Remote host closed the connection)
07:05:41  * stagasquit (Remote host closed the connection)
07:06:10  * stagasjoined
07:09:23  * mikealjoined
07:22:43  * dshaw_joined
07:27:14  * dshaw_quit (Ping timeout: 264 seconds)
07:30:36  * csaohjoined
07:36:18  * dominictarrquit (Quit: dominictarr)
07:37:17  * dominictarrjoined
07:38:23  * tellnesquit (Ping timeout: 240 seconds)
07:44:14  * wolfeidaujoined
07:49:31  * felixgequit (Quit: felixge)
07:51:27  * felixgejoined
07:53:09  * wolfeidauquit (Remote host closed the connection)
07:54:17  * wolfeidaujoined
07:55:24  * bnoordhuisquit (Ping timeout: 240 seconds)
07:55:35  * wolfeida_joined
07:59:52  * wolfeidauquit (Ping timeout: 264 seconds)
08:01:45  * wolfeida_quit (Remote host closed the connection)
08:13:35  * dominictarrquit (Quit: dominictarr)
08:14:32  * dominictarrjoined
08:16:51  * dominictarrquit (Client Quit)
08:22:20  * dominictarrjoined
08:23:10  * dshaw_joined
08:27:26  * dshaw_quit (Ping timeout: 240 seconds)
08:41:52  * defunctzombiechanged nick to defunctzombie_zz
09:01:44  * bnoordhuisjoined
09:06:26  * bnoordhuisquit (Ping timeout: 256 seconds)
09:14:39  * csaohquit (Quit: csaoh)
09:22:58  * csaohjoined
09:23:18  * dshaw_joined
09:27:50  * dshaw_quit (Ping timeout: 264 seconds)
09:30:30  * dominictarrquit (Quit: dominictarr)
09:41:24  * defunctzombie_zzquit (Ping timeout: 240 seconds)
09:45:02  * defunctzombie_zzjoined
09:52:21  * dominictarrjoined
09:55:09  * skebcioquit (Read error: Connection reset by peer)
09:55:25  * skebciojoined
09:55:44  * felixgequit (Quit: felixge)
09:59:50  * piscisaureus_joined
10:11:38  * piscisaureus_quit (Ping timeout: 264 seconds)
10:18:50  * piscisaureus_joined
10:22:38  * csaohquit (Quit: csaoh)
10:23:46  * dshaw_joined
10:26:52  * felixgejoined
10:28:16  * dshaw_quit (Ping timeout: 260 seconds)
10:29:14  * abraxasquit (Remote host closed the connection)
10:45:03  * piscisaureus__joined
10:45:38  * piscisaureus_quit (Read error: Connection reset by peer)
10:46:05  * c4milojoined
10:46:52  * csaohjoined
10:49:29  * kazuponquit (Remote host closed the connection)
10:50:37  * c4miloquit (Read error: Connection reset by peer)
10:50:49  * c4milojoined
10:51:28  * c4miloquit (Read error: Connection reset by peer)
10:51:38  * c4milojoined
10:52:00  * c4miloquit (Remote host closed the connection)
10:58:05  * bajtosquit (Quit: bajtos)
10:59:19  * M28quit (Ping timeout: 264 seconds)
11:00:19  * M28joined
11:09:02  * nsmquit (Ping timeout: 240 seconds)
11:09:18  * nsmjoined
11:19:31  * wolfeidaujoined
11:24:11  * dshaw_joined
11:28:56  * dshaw_quit (Ping timeout: 260 seconds)
11:31:31  * piscisaureus__quit (Ping timeout: 256 seconds)
11:41:12  * piscisaureus_joined
11:43:27  * c4milojoined
11:52:11  * bnoordhuisjoined
12:12:50  <piscisaureus_>EventEmitter.listenerCount is insane
12:12:58  <piscisaureus_>this should just be a prototype method
12:13:31  <piscisaureus_>^-- isaacs bnoordhuis
12:14:43  <piscisaureus_>I know - mongoose - but f**k them
12:14:52  <piscisaureus_>We should not allow insanity before 1.0
12:17:31  * tellnesjoined
12:20:31  <indutny>hoya
12:20:44  <indutny>piscisaureus_: insanity
12:20:48  <indutny>piscisaureus_: tell it to fs.watch :)
12:21:04  <piscisaureus_>indutny: what's up with that?
12:21:10  <indutny>that's quite a pain point right now, working different on all systems
12:21:17  <indutny>s/different/in a different way/
12:21:26  <indutny>that's totally mad
12:21:27  <piscisaureus_>indutny: btw - do you know something about the mac fs.watch code
12:21:34  <indutny>surely, I do
12:21:36  <indutny>what's up?
12:21:39  <piscisaureus_>indutny: Ruben was reporting crashes the other day
12:21:50  <piscisaureus_>indutny: node would segfault when a watched file was removed
12:21:52  <piscisaureus_>sporadically
12:21:55  <indutny>hm...
12:21:58  <indutny>0.10.x ?
12:22:01  <piscisaureus_>yes
12:22:13  <indutny>can you ask him to open an issue?
12:22:28  <indutny>I'm doing different stuff right now
12:22:28  <piscisaureus_>indutny: I have a lot of info already
12:22:32  <indutny>and afraid to forget :)
12:22:36  <indutny>ok, great
12:22:38  <piscisaureus_>I guess
12:22:45  * pachetjoined
12:23:13  <indutny>thanks
12:23:13  <piscisaureus_>indutny: crash happens here: https://github.com/joyent/node/blob/v0.10.13/deps/uv/src/unix/fsevents.c#L139
12:23:24  <indutny>huuuh
12:23:34  <indutny>I guess NULL path
12:23:42  <piscisaureus_>indutny: we couldn't really reproduce in the debug build
12:23:44  <indutny>which is odd...
12:23:52  <piscisaureus_>indutny: but it did happen with the release build and -g
12:24:12  <indutny>interesting
12:24:13  <piscisaureus_>I have also looked at the disassembly but I couldn't find any errors in there, although it's kinda hard to inspect
12:24:21  <indutny>heh, disassembly
12:24:27  <indutny>are you debugging it on smartos?
12:24:32  <piscisaureus_>no it happens on mac
12:24:36  <indutny>aaah
12:24:36  * dshaw_joined
12:24:37  <indutny>sorry
12:24:39  <indutny>that was stupid :D
12:24:46  <piscisaureus_>kinda obvious also :)
12:24:58  <indutny>I just spent a couple of hours doing disassembly on smartos
12:25:00  <indutny>freaking mdb
12:25:18  <piscisaureus_>Voxer makes you sweat huh :)
12:26:00  <indutny>haha
12:26:20  <indutny>well, yesterday's debugging was much harder
12:26:29  <indutny>I was trying to investigate that 451 FSEvents failure
12:26:37  <indutny>did you know that you can watch only 451 different files on osx
12:26:41  <indutny>I mean on whole system
12:26:53  <indutny>that's totally mad
12:27:03  <piscisaureus_>huh
12:27:05  <piscisaureus_>no way
12:27:06  <indutny>I'm still thinking about the way to figure it out
12:27:10  <indutny>piscisaureus_: give it a try
12:27:14  <indutny>just fs.watch() the same file
12:27:15  <indutny>451 time
12:27:20  <piscisaureus_>I don't run pear os
12:27:29  <indutny>and then try 452nd from other process
12:27:31  <indutny>haha
12:27:38  <indutny>piscisaureus_: what are you running then?
12:28:01  <piscisaureus_>square holes in a wall OS
12:29:30  * dshaw_quit (Ping timeout: 276 seconds)
12:29:33  * abraxasjoined
12:30:22  <indutny>erm
12:30:40  <indutny>dubious alternative
12:34:13  * abraxasquit (Ping timeout: 248 seconds)
12:35:04  <piscisaureus_>indutny: https://github.com/joyent/node/issues/6040
12:35:12  <indutny>thanks
12:52:36  * wolfeidauquit (Remote host closed the connection)
12:57:59  <piscisaureus_>indutny: I hope you can figure out what's going on. I had no clue...
12:58:03  * piscisaureus_&
12:58:03  <LOUDBOT>WHY IS THIS CHANNEL SO MUCH FUN?
12:58:09  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
13:04:18  * mikealquit (Read error: Connection reset by peer)
13:05:08  <ik>LOUDBOT: WHOSAID
13:05:09  <LOUDBOT>peltkore in #peltkore on irc.freenode.net
13:05:18  <ik>he's not talking about you guys
13:05:27  <ik>gotta liven it up in here
13:25:01  * dshaw_joined
13:29:26  * dshaw_quit (Ping timeout: 240 seconds)
13:35:53  * bnoordhuisquit (Ping timeout: 240 seconds)
13:48:44  * bradleymeckjoined
13:53:20  * kenperkinsquit (Quit: Textual IRC Client: http://www.textualapp.com/)
14:09:33  * roxlu_joined
14:10:04  * roxlu_quit (Client Quit)
14:10:42  * roxlu_joined
14:10:45  * piscisaureus_joined
14:10:45  * roxluquit (Ping timeout: 240 seconds)
14:17:42  * c4miloquit (Remote host closed the connection)
14:19:04  <Domenic_>is there like a v8 api book. or graduated tutorial or something.
14:25:25  * dshaw_joined
14:25:38  * indexzerojoined
14:29:50  * dshaw_quit (Ping timeout: 240 seconds)
14:30:45  <roxlu_>hi guys maybe someone can share his/hers ideas about this ...
14:30:48  * c4milojoined
14:31:01  <roxlu_>I use libuv quite a lot for threading/networking/file io..
14:31:42  <roxlu_>almost all the time I'm using some other 3rd party library that calls a update() function at a specified rate (60 fps normally)
14:31:58  <roxlu_>but now I'm working on an application (Cocoa) which doesn't have this update() function.
14:32:24  <roxlu_>I can write a timer which is executed at 60 fps, but I was wondering what other approaches I can use
14:37:00  * roxlu_quit (Quit: leaving)
14:37:29  * roxlujoined
14:46:49  * dshaw_joined
14:47:01  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
14:48:13  * dshaw_quit (Read error: Connection reset by peer)
14:48:16  * dshaw_1joined
14:48:40  * kenperkinsjoined
14:52:38  * dshaw_1quit (Ping timeout: 240 seconds)
15:05:25  * bajtosjoined
15:12:00  * groundwaterjoined
15:12:53  * dshaw_joined
15:14:19  * dshaw_1joined
15:14:26  * dshaw_quit (Read error: Connection reset by peer)
15:15:30  * AvianFlujoined
15:18:05  * paulfryzeljoined
15:19:01  * dshaw_1quit (Ping timeout: 248 seconds)
15:20:56  * bnoordhuisjoined
15:25:18  * kenperkinsquit (Quit: Textual IRC Client: http://www.textualapp.com/)
15:31:58  * mikealjoined
15:32:20  * mikealquit (Client Quit)
15:34:35  <MI6>joyent/node: Ben Noordhuis master * 4ffa943 : test: fix up internet/test-dns after api change - http://git.io/TRPMgA
15:35:20  * jmar777joined
15:35:30  <pfox__>bnoordhuis: i have one more, dumb, question about io that i probably already know the answer to: if you pass NULL for the callback to the uv_fs_* functions, is it still using the threadpool and blocking in the call or is it actually doing the blocking IO on the calling thread?
15:35:46  <pfox__>(im guessing it still uses the threadpool)
15:35:56  * mikealjoined
15:36:42  <bnoordhuis>pfox__: sadly no, passing cb=NULL means "use the synchronous version"
15:36:54  <bnoordhuis>i'm not happy with that api but it is what it is
15:40:58  * c4miloquit (Remote host closed the connection)
15:41:09  * rendarjoined
15:50:24  <pfox__>bnoordhuis: so then it blocks in the calling thread?
15:51:05  <mordy__>hrm, wrt to library unload, it seems prudent that you should have actual destructor calls for both unix and windows
15:51:17  <mordy__>i caught something on windows yesterday as well when UV was being unloaded
15:51:48  <pfox__>i guess i should just look at the impl.
15:52:30  <bnoordhuis>pfox__: if cb=NULL, yes
15:53:02  <bnoordhuis>mordy__: the windows impl is piscisaureus's pigeon
15:53:17  * julianduquejoined
15:54:51  <mordy__>just curious; what is your style guidelines?
15:56:48  <bnoordhuis>mordy__: two space indent, uv-unix usually drops braces for single statement if statements, separate declaration and assignment of locals, etc.
15:57:11  <bnoordhuis>mordy__: in general, look at the surrounding code
15:57:21  <mordy__>:)
15:57:49  <mordy__>hrm, time for a uv_unload_register(void (*)())
16:03:53  * bnoordhuisquit (Ping timeout: 240 seconds)
16:14:46  * dshaw_joined
16:15:13  * amartensjoined
16:15:47  * mikealquit (Quit: Leaving.)
16:17:28  * TooTallNatejoined
16:19:18  * dshaw_quit (Ping timeout: 264 seconds)
16:22:31  * dapjoined
16:24:09  * rendarquit
16:24:20  * dshaw_joined
16:28:09  * dshaw_1joined
16:28:36  * dshaw_quit (Read error: Connection reset by peer)
16:32:30  * hzjoined
16:35:27  * kenperkinsjoined
16:39:46  * jmar777quit (Remote host closed the connection)
16:48:10  * TooTallNatequit (Quit: Computer has gone to sleep.)
16:49:36  <MI6>joyent/libuv: Timothy J Fontaine master * 1a177d7 : build: apply dtrace -G to all object files - http://git.io/fT2Xag
16:50:33  * piscisaureus_joined
16:51:30  * bnoordhuisjoined
16:51:31  <tjfontaine>hmm what's rstudio/httpuv
16:52:25  <tjfontaine>bnoordhuis: btw, I did look into soname and gyp on friday, I think it wants a 'solink' stanza for it to do the work
16:54:31  <MI6>libuv-master: #159 UNSTABLE smartos (9/192) windows (3/193) linux (1/192) http://jenkins.nodejs.org/job/libuv-master/159/
16:54:35  * Benvie_joined
16:55:35  <MI6>libuv-node-integration: #140 FAILURE http://jenkins.nodejs.org/job/libuv-node-integration/140/
16:56:37  <MI6>libuv-master-gyp: #99 UNSTABLE windows-x64 (3/193) smartos-x64 (2/192) smartos-ia32 (2/192) linux-x64 (1/192) windows-ia32 (3/193) http://jenkins.nodejs.org/job/libuv-master-gyp/99/
16:56:59  * Benviequit (Ping timeout: 260 seconds)
16:59:38  * Benvie_quit (Ping timeout: 264 seconds)
17:00:15  * c4milojoined
17:01:49  * c4miloquit (Remote host closed the connection)
17:04:49  * Benviejoined
17:05:53  <bnoordhuis>what's up with jenkins?
17:06:13  <tjfontaine>in which regard
17:06:18  * dominictarrquit (Quit: dominictarr)
17:06:21  * brsonjoined
17:06:29  <tjfontaine>this morning the frontend was locked up again
17:06:30  <bnoordhuis>tjfontaine: http://jenkins.nodejs.org/job/libuv-node-integration/140/ <- everything's red
17:06:32  * c4milojoined
17:06:44  <bnoordhuis>seems the git checkout fails somehow?
17:06:47  <tjfontaine>bnoordhuis: something is wrong with that build rule, I need to investigate further
17:07:06  * TooTallNatejoined
17:07:22  <bnoordhuis>tjfontaine: re: soname + gyp, if you can get it to work, by all means land it
17:08:01  <tjfontaine>bnoordhuis: I am not too fussed about it atm, it's only a problem for people who want shared_library on smartos while using the gyp build process
17:09:26  * csaohquit (Quit: csaoh)
17:09:40  <bnoordhuis>tjfontaine: the intersection of those three sets sounds like it's approximately zero
17:09:55  <tjfontaine>right which is why I just moved on on friday :)
17:10:02  <tjfontaine>also libuv-node-integration was totally my fault
17:10:14  <trevnorris>bnoordhuis: sup?
17:10:20  <tjfontaine>kicking off a new build, should be fine now
17:10:35  <bnoordhuis>trevnorris: nothing much, just chillin'
17:10:51  <tjfontaine>relaxin all cool, shooting some bball outside of the school?
17:11:07  <trevnorris>bnoordhuis: cool. sorry for wrecking your multi-context patch. didn't see how it'd affect until after you mentioned it
17:11:50  <bnoordhuis>trevnorris: oh, no worries. it wasn't the end of the world
17:11:53  <bnoordhuis>#Output from process `hrtime`:
17:11:53  <bnoordhuis>#Assertion failed in ../test/test-hrtime.c on line 50: diff < (uint64_t) 80 * NANOSEC / MILLISEC
17:12:03  <bnoordhuis>i wonder if i should just kill that test
17:12:11  <bnoordhuis>it's by its very definition timing sensitive
17:12:21  <MI6>libuv-node-integration: #141 FAILURE http://jenkins.nodejs.org/job/libuv-node-integration/141/
17:12:24  <tjfontaine>hm
17:12:42  * Somebodyjoined
17:12:55  * pachetquit (Quit: leaving)
17:13:25  <MI6>joyent/node: Ben Noordhuis master * 6cd7fd7 : cares_wrap: don't set oncomplete property from c++ - http://git.io/zh1_5A
17:14:12  <tjfontaine>oh hey, I have a question
17:15:00  <bnoordhuis>well?
17:15:13  <tjfontaine>https://github.com/joyent/node/blob/master/src/node_crypto.cc#L223-L257 any reason we couldn't be doing that in js and passing real ssl constants around?
17:15:52  <trevnorris>bnoordhuis: is your context patch stable enough for me to work from?
17:16:34  <bnoordhuis>trevnorris: hrm, i'm still moving things around a lot
17:17:07  <bnoordhuis>tjfontaine: SSLv2_method() and friends return pointers to structs, not simple values
17:17:35  <tjfontaine>bnoordhuis: no I mean the strcmps
17:18:10  <bnoordhuis>oh, like that. i guess so but it's an api change
17:18:30  <tjfontaine>nah we'd just do the switch in js land
17:18:40  * defunctzombie_zzchanged nick to defunctzombie
17:19:12  <bnoordhuis>what would you gain? you still need to call *_method()
17:19:42  <tjfontaine>not much about gain, aside from being a little easier on my eyes when looking at it :)
17:20:21  <bnoordhuis>well... it's possible. not sure if it's much of an improvement
17:20:24  * defunctzombiequit (Changing host)
17:20:24  * defunctzombiejoined
17:21:19  <MI6>libuv-master: #160 UNSTABLE smartos (11/192) osx (1/193) windows (4/193) linux (12/192) http://jenkins.nodejs.org/job/libuv-master/160/
17:22:32  <bnoordhuis>12 linux failures?
17:22:52  <tjfontaine>it's all timing related because node-master started at the exact same time
17:23:15  <bnoordhuis>ah
17:24:21  <roxlu>hi guys, I'm looking for a solution for the producer/consumer code I've now.. I'm generating "Work*" in my main thread, pass it into a queue and process this in a separate thread. My thread is basically polling() the queue continuously. Now I think I probably need to use a condition variable but is the uv_cond_t and its functions really cross platform already?
17:24:23  * hzquit (Ping timeout: 240 seconds)
17:25:12  <bnoordhuis>roxlu: yes
17:25:26  * piscisaureus_quit (Ping timeout: 240 seconds)
17:25:29  <roxlu>ok that's great :)
17:25:52  * hzjoined
17:26:10  <bnoordhuis>roxlu: there's some producer/consumer code in src/unix/threadpool.c that you can steal
17:26:25  <roxlu>thanks so much!
17:26:40  <roxlu>I'm still trying to fully understand semaphores/condition vars
17:26:50  <bnoordhuis>it's multiple producers/multiple consumers btw so ymmv if it's usable for you
17:27:22  <roxlu>I most often have one producer and one consumer, where the main thread produces work which is processed in a separate thread
17:28:03  * bradleymeckquit (Quit: bradleymeck)
17:28:48  <roxlu>but from the examples/articles I read online it looks like using semaphors/cond.vars work best when the producer + consumer are separate threads
17:29:19  <bnoordhuis>roxlu: well, 'separate' in the sense that the producer and consumer run on different threads
17:29:42  <bnoordhuis>your main thread and the worker thread meet that criterium :)
17:30:06  <roxlu>so it's ok to use the main thread as producer? (so I can still use the main thread to perform other work; so no blocking)
17:30:35  <bnoordhuis>yep
17:33:28  * Damn3dquit (Ping timeout: 246 seconds)
17:33:57  <bnoordhuis>indutny: ping
17:35:04  * Damn3djoined
17:35:47  * felixgequit (Quit: felixge)
17:36:20  <MI6>nodejs-master: #409 UNSTABLE linux-ia32 (10/622) osx-x64 (1/622) osx-ia32 (1/622) smartos-x64 (11/622) linux-x64 (10/622) smartos-ia32 (4/622) http://jenkins.nodejs.org/job/nodejs-master/409/
17:37:42  * hzquit
17:38:10  * mikealjoined
17:38:28  * mikealquit (Client Quit)
17:40:25  <roxlu>bnoordhuis: ok, with a cond.var I can make sure that another thread will wait until I signal it. How would I use it to add data to a queue and let my consumer thread use it
17:42:58  * jester2048joined
17:44:55  <bnoordhuis>roxlu: you always use a condvar in combination with a mutex
17:45:20  <bnoordhuis>roxlu: when you want to add data to the queue, you acquire the mutex, update the queue then signal the condvar
17:45:43  <bnoordhuis>(and unlock the mutex again, of course)
17:46:17  <jester2048>hey guys. i'm trying to use libcurl with libuv to drive the events. when attempting to uv_poll_init() though, i'm getting an assert from a call made to _get_osfhandle()
17:46:45  <bnoordhuis>roxlu: in the worker, grab the mutex, call uv_cond_wait() repeatedly until an item appears in the queue, then do whatever
17:46:56  <bnoordhuis>you may want to release the mutex after pulling the item off the queue
17:47:10  * sblomjoined
17:47:16  <roxlu>bnoordhuis: thanks, what's not really clear is how the consumer locks/unlocks
17:47:19  <bnoordhuis>in case you're wondering why that works, uv_cond_wait() atomically releases the mutex, then starts waiting on the condvar
17:47:20  <MI6>libuv-node-integration: #142 UNSTABLE smartos-x64 (8/622) osx-ia32 (1/622) smartos-ia32 (3/622) osx-x64 (1/622) linux-ia32 (4/622) linux-x64 (3/622) http://jenkins.nodejs.org/job/libuv-node-integration/142/
17:47:40  <bnoordhuis>but you need to beware of spurious wakeups, hence check if the queue has an item in it
17:47:55  <bnoordhuis>jester2048: what assert?
17:48:03  <jester2048>the assert is that the socket fd given to me from curl (let's say 680), is outside of a range 0 to 32. i'm stumped as to where this max range is decided?
17:48:27  <jester2048>(fh >= 0 && (unsigned)fh < (unsigned)_nhandle), EBADF, -1);
17:48:28  <roxlu>bnoordhuis: what happens when the consumer does: lock() wait(), unlock(). Would the mutex be locked and can't I add any more data to the queue until it unlocks?
17:49:03  <bnoordhuis>jester2048: can you post the exact message, including the filename and line?
17:49:18  <jester2048>bnoordhuis: sure, just a sec.
17:49:30  * bajtosquit (Quit: bajtos)
17:49:34  <bnoordhuis>roxlu: read carefully :) uv_cond_wait() releases the mutex upon entering, then reacquires upon returning
17:50:12  <bnoordhuis>roxlu: iow, for the duration of uv_cond_wait() the mutex is unlocked
17:50:53  <roxlu>ah ok :) I have to digest this a bit; I'm going to write a simple test app where I create some bogus queue with work
17:52:22  <bnoordhuis>roxlu: most important thing is that you hold the mutex when calling uv_cond_signal(), that's the thing most people get wrong
17:52:35  <bnoordhuis>it's not a hard error but it opens you up to race conditions
17:52:49  <roxlu>bnoordhuis: so: lock(), signal(), unlock() ?
17:53:04  <MI6>nodejs-master-windows: #207 UNSTABLE windows-x64 (22/622) windows-ia32 (24/622) http://jenkins.nodejs.org/job/nodejs-master-windows/207/
17:53:47  <jester2048>bnoordhuis: Debug Assertion Failed! File:f:\dd\vctools\crt_bld\self_x86\crt\src\osfinfo.c Line: 306 Expression: (fh >= 0 && (unsigned)fh < (unsigned)_nhandle)
17:54:02  <MI6>libuv-master: #161 UNSTABLE smartos (9/192) windows (4/193) linux (2/192) http://jenkins.nodejs.org/job/libuv-master/161/
17:54:54  <bnoordhuis>jester2048: that's an assertion in the crt, not libuv
17:55:19  <bnoordhuis>jester2048: if i were to venture a guess, i'd say that you're passing in an fd < 0
17:55:38  <bnoordhuis>maybe add some asserts to your own code and see what pops up
17:57:05  <jester2048>bnoordhuis: yeah, i understand that. i was hoping to maybe get a pointer as to where i can read up a bit more on the details of that function in osfinfo.c since libuv is using it.
17:57:49  <bnoordhuis>jester2048: that would be src/win/poll.c
17:58:04  <jester2048>bnoordhuis: the failure is actually on < _nhandle which is set at 32
17:58:29  <bnoordhuis>jester2048: ah, okay. that's still a crt thing, i think
17:58:55  <bnoordhuis>i'm reasonably sure uv-win doesn't mess with the handle limit
17:59:31  * piscisaureus_joined
17:59:50  <trevnorris>bnoordhuis: in 6cd7fd7 you missed a Local<Function> callback, line 764
17:59:51  <jester2048>bnoordhuis: ah cool, well thanks a lot for that anyway, i'll investigate further on poll.c
18:00:57  <bnoordhuis>trevnorris: so i did... i wonder why no tests are failing
18:01:01  <bnoordhuis>git log
18:01:09  <bnoordhuis>hah, fscking mac keyboard
18:01:35  <bnoordhuis>anyway, looks like we need some more coverage here
18:01:49  <trevnorris>bnoordhuis: clang just gave me a warning about an unused variable.
18:02:17  <tjfontaine>we can move to -Wall I guess :)
18:02:19  <bnoordhuis>i guess i can just remove that function altogether, it's not used anywhere
18:02:28  <trevnorris>that's what you did earlier
18:02:39  <trevnorris>just seems that callback was missed
18:02:49  <trevnorris>since it's now being set in js, no need for it
18:02:59  <bnoordhuis>okay, imma kill it
18:03:11  <roxlu>bnoordhuis: I just tested this super simple use of condition vars; can you have a peek if what I do is correct? https://gist.github.com/roxlu/f001623b1db4dffee8a3
18:03:24  <bnoordhuis>also, re -Wall, i think we have it enabled
18:03:30  <bnoordhuis>it just doesn't catch much with gcc 4.2
18:07:11  <bnoordhuis>roxlu: you need to check for spurious wakeups
18:07:25  <roxlu>bnoordhuis: what's a spurious wakeup?
18:07:27  <trevnorris>bnoordhuis: anything here that would make life hellish for you: https://github.com/joyent/node/pull/5998
18:07:50  <bnoordhuis>roxlu: that's where uv_cond_wait() wakes up without actually being signalled
18:08:00  <roxlu>oh is that possible?
18:08:38  <bnoordhuis>sadly, yes
18:08:46  <roxlu>hehe ok
18:09:01  <MI6>joyent/node: Ben Noordhuis master * e0a8e1b : cares_wrap: remove unused function getHostByName() - http://git.io/lDGxag
18:09:02  <roxlu>can you explain when it happens and how to check for that?
18:09:33  <bnoordhuis>roxlu: when your process receives a signal when it's sleeping in uv_cond_wait(), for example
18:09:46  <roxlu>ah ok, like sigint ?
18:09:51  <bnoordhuis>yes, for example
18:10:07  <bnoordhuis>you check for it by checking if there's actually something in the queue
18:10:19  <bnoordhuis>you have the mutex so that's perfectly safe
18:10:28  <bnoordhuis>trevnorris: looking
18:10:32  <roxlu>ah ok, thanks so much! It's actually pretty simple but this will save quite some cpu
18:10:36  <roxlu>bnoordhuis++
18:11:25  <trevnorris>bnoordhuis: oh, also meant to throw in the cleanup of being able to use a ; at the end of UNWRAP.
18:12:35  * bradleymeckjoined
18:18:54  <bnoordhuis>trevnorris: good :) some suggestions but generally looks okay to me
18:19:48  <bnoordhuis>roxlu: btw, in your example not checking for spurious wakeups would probably work okay
18:19:56  <trevnorris>bnoordhuis: thanks. i'll get those cleaned up :)
18:20:14  <bnoordhuis>roxlu: if i read it right, you'll just iterate over an empty vector so that's okay
18:20:26  <bnoordhuis>roxlu: it's just a good habit to get into
18:20:36  <roxlu>yeah
18:21:01  <roxlu>really good to know how this works now! my app, which was doing nothing .. only polly used way to much cpu
18:21:17  <roxlu>bnoordhuis: you don't have experience with Cocoa based apps do you?
18:22:19  <bnoordhuis>roxlu: i know next to nothing about cocoa
18:22:29  <roxlu>ok :)
18:23:05  * julianduquequit (Quit: leaving)
18:23:24  <roxlu>I'm working on an application which needs to perform these tasks, but when the consumer is ready, it needs to copy the Work* data back to the main thread so I use the data in the main thread
18:25:57  <bnoordhuis>roxlu: yeah, that's basically what uv_queue_work() does
18:26:20  <bnoordhuis>hand off some work to worker threads. when it's finished, notify the main thread and wake up the event loop
18:27:36  <jester2048>bnoordhuis: just to let you know, i sorted it out. i needed to call uv_poll_init_socket in this case and not uv_poll_init. i didn't realise there was a special function for a socket arg. that'll teach me.
18:27:41  <roxlu>bnoordhuis: does it hook into the application event loop?
18:28:00  <bnoordhuis>roxlu: if by 'application event loop' you mean 'libuv event loop', then yes, otherwise no
18:28:15  <bnoordhuis>you can integrate the libuv event loop with other event loops btw
18:28:21  <bnoordhuis>jester2048: glad you got it sorted out
18:28:23  <roxlu>hehe I meant my coca event loop
18:28:38  <roxlu>bnoordhuis: ok, I have to read up on cocoa a bit too
18:28:49  <roxlu>especially how I integrate this producer/consumer
18:37:45  <MI6>joyent/node: bnoordhuis created branch jenkins-review-plox - http://git.io/YYZmYg
18:38:18  <tjfontaine>yay it properly picked it up
18:39:09  * mikealjoined
18:39:14  * piscisaureus_quit (Ping timeout: 264 seconds)
18:40:09  <MI6>libuv-node-integration: #143 UNSTABLE smartos-x64 (10/622) osx-ia32 (1/622) smartos-ia32 (3/622) osx-x64 (1/622) linux-ia32 (3/622) linux-x64 (16/622) http://jenkins.nodejs.org/job/libuv-node-integration/143/
18:44:02  <trevnorris>bnoordhuis: this what you were talking about? https://github.com/trevnorris/node/commit/1d0e0a1
18:46:24  <MI6>nodejs-master: #410 UNSTABLE linux-ia32 (13/622) osx-x64 (2/622) osx-ia32 (3/622) smartos-x64 (11/622) linux-x64 (11/622) smartos-ia32 (2/622) http://jenkins.nodejs.org/job/nodejs-master/410/
18:47:40  * mikealquit (Ping timeout: 246 seconds)
18:49:12  <bnoordhuis>trevnorris: yep, nice!
18:49:24  <trevnorris>bnoordhuis: thanks
18:50:55  <MI6>joyent/node: Trevor Norris master * 756ae2c : src: centralize class wrap/unwrap - http://git.io/lpI_Eg
18:51:04  <bnoordhuis>tjfontaine: http://jenkins.nodejs.org/job/nodejs-master/410/ <- timing issues again, i presume?
18:51:42  <tjfontaine>ya that seems likely
18:51:57  <MI6>nodejs-master-windows: #208 UNSTABLE windows-x64 (24/622) windows-ia32 (24/622) http://jenkins.nodejs.org/job/nodejs-master-windows/208/
18:52:04  <tjfontaine>I can turn down the executors such that only one job runs at a time on a slave
18:52:15  <tjfontaine>and then ask about spinning up more nodes
18:52:44  * pachetjoined
18:54:41  <Domenic_>vm2 at https://github.com/joyent/node/pull/5918 is pretty much done, a.k.a. ready for more review :). i squashed into a few relevant commits.
18:54:57  <tjfontaine>Domenic_: congrats :)
18:55:13  <Domenic_>thanks tjfontaine, couldn't have done it without ya :D
18:55:45  <tjfontaine>Domenic_: heh, glad I was able to help when you needed it
19:01:45  <MI6>joyent/node: Ben Noordhuis master * 5725864 : src: don't obj->Set(Integer::New(...), val) - http://git.io/xq7jSA
19:10:19  <roxlu>bnoordhuis: after my little test I've just added this condition var into my app and something is going wrong now :) What happens is this:
19:10:42  <roxlu>although there is data in y "work" queue, the thread is waiting for a signal
19:10:47  <roxlu>s/y/my
19:11:19  <roxlu>I'm surprised that this is actually possible
19:12:30  <bnoordhuis>roxlu: have you signalled it?
19:12:49  <roxlu>yes, I signal it every time I add a new task
19:13:00  <bnoordhuis>can you gist your code again?
19:13:03  * EhevuTovjoined
19:14:39  * mikealjoined
19:15:25  <roxlu>bnoordhuis: I've priv msg'd you
19:20:14  <MI6>nodejs-master: #411 FAILURE linux-ia32 (12/622) osx-x64 (1/622) osx-ia32 (1/622) linux-x64 (10/622) http://jenkins.nodejs.org/job/nodejs-master/411/
19:22:21  <bnoordhuis>../src/handle_wrap.cc: In constructor 'node::HandleWrap::HandleWrap(v8::Handle<v8::Object>, uv_handle_t*)':
19:22:24  <bnoordhuis>../src/handle_wrap.cc:98:20: error: '131072' cannot be used as a function
19:22:26  <bnoordhuis>compilers!
19:22:53  <bnoordhuis>ah wait no, that actually looks broken
19:23:15  <bnoordhuis>trevnorris: ^
19:25:49  * EhevuTov_joined
19:26:18  * mcavagejoined
19:27:42  <trevnorris>looking
19:28:39  * EhevuTovquit (Ping timeout: 260 seconds)
19:30:01  <trevnorris>bnoordhuis: handle_wrap.cc doesn't include node_internals.h, could that be it?
19:33:12  * EhevuTov_quit (Quit: This computer has gone to sleep)
19:33:35  <MI6>joyent/node: trevnorris created branch fix-smartos-build-stuffs - http://git.io/vN-Tow
19:33:49  * EhevuTovjoined
19:34:37  <trevnorris>tjfontaine: how can I find the jenkins build for a branch I just pushed?
19:34:57  <bnoordhuis>trevnorris: nvm, already looking into it
19:35:22  <trevnorris>bnoordhuis: thanks
19:36:11  <MI6>node-review: #57 UNSTABLE windows-x64 (25/622) smartos-x64 (8/622) smartos-ia32 (3/622) centos-x64 (3/622) osx-x64 (1/622) osx-ia32 (1/622) linux-x64 (12/622) centos-ia32 (3/622) windows-ia32 (23/622) linux-ia32 (16/622) http://jenkins.nodejs.org/job/node-review/57/
19:37:02  * EhevuTovquit (Client Quit)
19:39:01  * Somebodyquit (Remote host closed the connection)
19:39:50  * Damn3dquit (Ping timeout: 264 seconds)
19:40:27  <MI6>nodejs-master-windows: #209 UNSTABLE windows-x64 (26/622) windows-ia32 (24/622) http://jenkins.nodejs.org/job/nodejs-master-windows/209/
19:41:00  <MI6>nodejs-master: #412 FAILURE linux-ia32 (4/622) osx-x64 (2/622) osx-ia32 (1/622) linux-x64 (3/622) http://jenkins.nodejs.org/job/nodejs-master/412/
19:44:17  <bnoordhuis>/usr/include/sys/termios.h:270:#define WRAP 0400000 <- haha :)
19:44:33  <bnoordhuis>seems WRAP is too generic a name, trevor
19:45:12  <trevnorris>heh, seems so.
19:46:22  <trevnorris>bnoordhuis: but when I add node_internals.h to the files the build is fixed: http://jenkins.nodejs.org/job/node-review/57/
19:47:07  <bnoordhuis>trevnorris: that can't be it. handle_wrap.cc includes node.h which in turn includes node_isolates.h
19:47:12  <bnoordhuis>err, node_internals.h
19:47:30  <bnoordhuis>btw, #57 is _my_ build :)
19:48:12  <bnoordhuis>solution is simple, just rename WRAP to e.g. NODE_WRAP
19:49:01  <trevnorris>... heh, too many tabs open :P
19:49:10  <trevnorris>bnoordhuis: cool, and do NODE_UNWRAP for consistency?
19:49:16  <bnoordhuis>yep
19:49:21  <trevnorris>will do, thanks.
19:51:26  * dominictarrjoined
19:55:21  * Guest85773joined
19:55:49  <indutny>bnoordhuis: pong
19:55:57  <indutny>sup?
19:56:41  <MI6>joyent/node: trevnorris created branch macro-fix-reviewme - http://git.io/nhv8_g
19:56:42  <trevnorris>bnoordhuis: ^ :)
19:56:43  <bnoordhuis>indutny: crypto and tls_wrap. what's the plan and the schedule?
19:57:00  <indutny>you mean DRYing stuff?
19:57:19  <bnoordhuis>trevnorris: yeah, that should do it. if `make cpplint` is happy, i am too
19:57:22  <bnoordhuis>indutny: yeah
19:57:33  <trevnorris>bnoordhuis: thanks
19:57:35  <indutny>well, I don't know
19:57:39  <indutny>I'll try to do it this week
19:57:42  <bnoordhuis>cool
19:58:01  <MI6>joyent/node: Trevor Norris master * 35f789b : src: fix build break from generic macro name - http://git.io/x3wlOw
20:02:06  * defunctzombiechanged nick to defunctzombie_zz
20:06:27  <pfox__>bnoordhuis: is the uv threadpool global to the process or does each loop maintain its own?
20:08:12  <bnoordhuis>pfox__: it's global
20:08:39  <MI6>nodejs-master: #413 FAILURE linux-ia32 (8/622) osx-x64 (3/622) osx-ia32 (7/622) linux-x64 (10/622) http://jenkins.nodejs.org/job/nodejs-master/413/
20:09:25  <tjfontaine>that's still ../src/handle_wrap.cc:98:20: error: '131072' cannot be used as a function
20:09:52  * mikealquit (Quit: Leaving.)
20:10:12  <tjfontaine>but I see two queued node-review's
20:10:45  <bnoordhuis>yeah, it's the second-to-last commit
20:12:09  * c4miloquit (Remote host closed the connection)
20:24:14  <trevnorris>strange, never seen this error before: "error: use 'template' keyword to treat 'As' as a dependent template name"
20:25:20  <MI6>nodejs-master: #414 UNSTABLE linux-ia32 (5/622) osx-x64 (1/622) osx-ia32 (2/622) smartos-x64 (9/622) linux-x64 (3/622) smartos-ia32 (4/622) http://jenkins.nodejs.org/job/nodejs-master/414/
20:25:30  <trevnorris>bnoordhuis: args[0].As<Object>() is causing the error I just posted, have an idea why?
20:26:37  <trevnorris>hm, but it's fine i I first assign it to a Local<Value>, eh, whatever
20:32:23  <MI6>node-review: #60 FAILURE windows-x64 (23/622) centos-x64 (3/622) osx-x64 (3/622) osx-ia32 (1/622) linux-x64 (3/622) centos-ia32 (5/622) windows-ia32 (26/622) linux-ia32 (2/622) http://jenkins.nodejs.org/job/node-review/60/
20:33:32  <MI6>nodejs-master-windows: #210 UNSTABLE windows-x64 (22/622) windows-ia32 (26/622) http://jenkins.nodejs.org/job/nodejs-master-windows/210/
20:34:59  * jmar777joined
20:39:10  <trevnorris>Domenic_: updated, if you take care of those things i'm probably fine w/ it
20:40:05  <Domenic_>trevnorris: awesome, thanks. will do tonight. still waiting on the guy who did timeouts to explain why that is causing assertion failures though.
20:40:08  * mikealjoined
20:41:44  <bnoordhuis>Domenic_: what assertion failure?
20:42:11  <tjfontaine>the uv_async handle is closing that is getting blown
20:42:19  <Domenic_>bnoordhuis: Assertion failed: !(handle->flags & UV__HANDLE_CLOSING), file src\win\async.c, line 77
20:42:35  <MI6>joyent/node: Ben Noordhuis master * 624938d : crypto: remove two unused static variables - http://git.io/FIo7LQ
20:43:04  <bnoordhuis>Domenic_: oh, that means there's a race somewhere
20:43:19  <bnoordhuis>either that or something is stomping on memory
20:43:23  <bnoordhuis>but probably a race condition
20:43:26  * sblomquit (Ping timeout: 264 seconds)
20:43:49  <tjfontaine>like a stack allocated value that went out of scope
20:44:33  <trevnorris>quick review anyone: https://github.com/trevnorris/node/compare/fix-isprimitive
20:44:49  <Domenic_>if you see anything obviously wrong with https://github.com/domenic/node/commit/426cb84519686bd01b5aaeb3cd8b48444f5ac06d#diff-1 then that would probably help
20:45:06  * mikealquit (Ping timeout: 264 seconds)
20:46:38  * pachetquit (Quit: leaving)
20:46:45  * EhevuTovjoined
20:47:21  <trevnorris>if no one objects in the next 3 mins i'm pushing it
20:47:35  <trevnorris>honestly, not even sure this one is review worthy :P
20:47:39  <tjfontaine>is that how it works? I'll just make sure to do fun things when no one is around :P
20:47:59  <trevnorris>haha, just for uber trivial stuff ;)
20:48:13  <tjfontaine>it doesn't seem objectionable to me
20:48:19  <trevnorris>i'll take it!
20:49:07  * bnoordhuislooks
20:50:36  <bnoordhuis>trevnorris: that's an awesome patch, trevor. damn sexy code
20:50:43  <tjfontaine>heh
20:50:50  <trevnorris>bnoordhuis: i was trained by the best ;)
20:50:57  <tjfontaine>it's almost as if bnoordhuis mentioned it in the issue
20:51:01  <MI6>joyent/node: Trevor Norris master * d66d840 : util: fix isPrimitive check - http://git.io/7pOTtA
20:51:03  <bnoordhuis>trevnorris: you can combine the null and undefined check
20:51:07  <bnoordhuis>aw, too late
20:51:20  <bnoordhuis>just arg == null checksfor both
20:51:30  <trevnorris>ah, you're right :/
20:54:39  <trevnorris>bnoordhuis: but seriously, tjfontaine and I had the conversation little while ago that he can tell you trained me up.
20:55:00  <trevnorris>i said something about a project not having consistent styles, and it made my eyes bleed. something like that
20:55:10  <bnoordhuis>hah :)
20:55:27  <bnoordhuis>then i've done at least one good thing in my life
20:56:16  * defunctzombie_zzchanged nick to defunctzombie
21:06:30  * julianduquejoined
21:13:42  <MI6>nodejs-master: #415 UNSTABLE linux-ia32 (9/622) osx-x64 (1/622) osx-ia32 (1/622) smartos-x64 (10/622) linux-x64 (11/622) smartos-ia32 (3/622) http://jenkins.nodejs.org/job/nodejs-master/415/
21:14:49  * felixgejoined
21:18:48  <MI6>nodejs-master-windows: #211 UNSTABLE windows-x64 (21/622) windows-ia32 (23/622) http://jenkins.nodejs.org/job/nodejs-master-windows/211/
21:24:24  <isaacs>ok, worked out how to know when to send the trailers: https://gist.github.com/isaacs/6215412
21:25:06  * julianduquequit (Ping timeout: 276 seconds)
21:25:08  <isaacs>mocked-up example of how to tell when you're on the last _write, or when a write isn't pending in the end() method, along with the complexity of deferring until we have a socket.
21:25:20  <isaacs>tjfontaine: we should release a 0.10.16 soon
21:25:38  <tjfontaine>if (state.ending && state.buffer.length === 1) {
21:25:44  <tjfontaine>isaacs: heh did he ping you too?
21:25:59  <isaacs>tjfontaine: who ping me?
21:26:07  <isaacs>tjfontaine: i mean, no. who pinged you?
21:26:07  <tjfontaine>oh chris *just* pinged me :P
21:26:10  <isaacs>haha
21:26:11  <isaacs>nice!
21:27:06  <tjfontaine>it will need to be tomorrow or wednesday, as I'll be doing the oHIo thing thur->mon
21:28:32  * julianduquejoined
21:29:12  <isaacs>tomorrow would be good
21:29:19  <isaacs>tuesday is peak internet traffic
21:29:28  <isaacs>visiting family?
21:29:41  <tjfontaine>indeed
21:31:54  * st_lukejoined
21:32:22  * sblomjoined
21:32:28  <MI6>nodejs-master: #416 UNSTABLE linux-ia32 (6/622) osx-x64 (2/622) osx-ia32 (1/622) smartos-x64 (9/622) linux-x64 (6/622) smartos-ia32 (3/622) http://jenkins.nodejs.org/job/nodejs-master/416/
21:36:01  * bradleymeckquit (Quit: bradleymeck)
21:38:17  * bradleymeckjoined
21:40:41  * mikealjoined
21:41:15  * bradleymeckquit (Client Quit)
21:42:30  * dshaw_1quit (Quit: Leaving.)
21:45:54  * mikealquit (Ping timeout: 276 seconds)
21:47:00  * jmar777quit (Remote host closed the connection)
21:51:19  <MI6>joyent/node: Ben Noordhuis master * d4ad5d1 : crypto: use consistent conn object unwrapping (+1 more commits) - http://git.io/au6Mng
22:04:04  <MI6>nodejs-master-windows: #212 UNSTABLE windows-x64 (22/622) windows-ia32 (24/622) http://jenkins.nodejs.org/job/nodejs-master-windows/212/
22:06:33  * AvianFlu_joined
22:07:14  * AvianFlu_quit (Remote host closed the connection)
22:10:42  * AvianFluquit (Ping timeout: 276 seconds)
22:12:03  <MI6>nodejs-master: #417 UNSTABLE linux-ia32 (5/622) osx-x64 (1/622) osx-ia32 (1/622) smartos-x64 (9/622) linux-x64 (2/622) smartos-ia32 (3/622) http://jenkins.nodejs.org/job/nodejs-master/417/
22:12:04  * dshaw_joined
22:14:12  <trevnorris>tjfontaine: here you go: https://github.com/trevnorris/buffer-dispose
22:14:23  <trevnorris>got tired of trying to make it work in all the core edge cases :P
22:14:58  <tjfontaine>hehe
22:15:18  <tjfontaine>trevnorris: you should make it work with v0.10 and v0.8 as well :)
22:15:32  <trevnorris>tjfontaine: ... i'm going to pretend you didn't say that
22:15:39  <tjfontaine>hehe
22:16:17  <tjfontaine>trevnorris: so um, won't this make things that have their own cb defined angry?
22:16:37  <trevnorris>tjfontaine: i'm not worried about that. it's not the use case.
22:16:51  <trevnorris>tjfontaine: it's made for when data comes in, you do something quickly with it, and don't need it anymore.
22:17:06  <trevnorris>not even going to worry about the transform cases. just gets too complex too quickly.
22:17:13  <tjfontaine>sure I didn't mean that
22:17:33  <tjfontaine>but I meant more what if someone has (mistakenly) allocated a buffer with stack memory or memory you otherwise can't free :P
22:17:42  <tjfontaine>but it's certainly an odd case
22:18:17  <trevnorris>i tried to make it clear in the README that it'll cause they're system to explode if they use it that way.
22:18:28  <tjfontaine>hehe
22:18:54  * mikealjoined
22:18:54  <trevnorris>it has one use case, to increase throughput when doing stuff like writing directly to disk or piping the data elsewhere.
22:20:05  * perezdjoined
22:24:41  * bnoordhu1sjoined
22:24:47  * dominictarrquit (Quit: dominictarr)
22:26:42  * groundwaterquit (Read error: Connection reset by peer)
22:26:43  * groundwa_joined
22:27:07  * bnoordhuisquit (Ping timeout: 246 seconds)
22:29:37  <trevnorris>tjfontaine: what i'm saying about ObjectWrap make sense?
22:29:46  <tjfontaine>I hear you, I just commented
22:29:56  <tjfontaine>the destructor isn't called though until `delete wrap` happens
22:30:33  * stagas_joined
22:31:05  * abraxasjoined
22:33:04  * stagasquit (Ping timeout: 246 seconds)
22:33:13  * stagas_changed nick to stagas
22:34:49  <tjfontaine>trevnorris: heh, I wasn't trying to wear you down :P
22:35:47  * abraxasquit (Ping timeout: 260 seconds)
22:39:05  * st_lukequit (Read error: Connection reset by peer)
22:39:16  * st_lukejoined
22:42:06  * brsonquit (Quit: Lost terminal)
22:42:52  * brsonjoined
22:42:57  <trevnorris>bnoordhu1s: have a sec for api question?
22:43:27  * bnoordhu1schanged nick to bnoordhuis
22:43:27  * indexzeroquit (Quit: indexzero)
22:43:29  <bnoordhuis>trevnorris: sure
22:45:17  <trevnorris>bnoordhuis: in my node.c api i'm trying to replicate the .on() event way of doing things. so i'm creating a server and add a listener for "listening" and "error", now if an error occurs while attempting to start the server would it be better to call the "error" callback, or "listening" callback with the error code?
22:46:17  <bnoordhuis>trevnorris: depends on whether you want to mimic node or something sane
22:46:28  <trevnorris>hah, let's do something sane
22:46:41  <bnoordhuis>then i guess you'd emit 'listening' with an error object
22:46:47  <trevnorris>cool, thanks.
22:46:47  <bnoordhuis>node emits 'error'
22:47:00  <bnoordhuis>i suppose both have their pros and their cons
22:47:14  <bnoordhuis>emitting 'listening' keeps everything in place though
22:48:03  <trevnorris>sounds good. i'm trying to make node.c close to node, but avoiding everything that was found to be wrong.
22:48:31  <MI6>nodejs-master-windows: #213 UNSTABLE windows-x64 (20/622) windows-ia32 (22/622) http://jenkins.nodejs.org/job/nodejs-master-windows/213/
22:56:00  <bnoordhuis>Domenic_: i didn't do an in-depth review just now, just a quick glance
23:00:32  <trevnorris>bnoordhuis: you about to sign off?
23:02:03  <bnoordhuis>trevnorris: well, i'm about to stop doing something and start doing nothing
23:02:06  <bnoordhuis>is that the same thing?
23:02:42  <trevnorris>heh, maybe. just wanted some feedback on a sample server I wrote up using the theoretical node.c api.
23:04:25  <bnoordhuis>ping me tomorrow and i'll take a look
23:04:44  <trevnorris>thanks, see you then
23:04:53  <bnoordhuis>for now, i think i'll eat some cereals and read about people being wrong on the internet
23:05:15  <trevnorris>awesome. enjoy your cereal.
23:07:29  <bnoordhuis>thanks :)
23:08:35  * leonvvjoined
23:09:51  * inolenjoined
23:13:04  * jester2048quit (Quit: Leaving)
23:13:43  * AvianFlujoined
23:26:36  * txdvquit (Read error: Operation timed out)
23:26:50  * txdvjoined
23:29:47  <MI6>nodejs-master-windows: #214 UNSTABLE windows-x64 (23/622) windows-ia32 (24/622) http://jenkins.nodejs.org/job/nodejs-master-windows/214/
23:34:32  <Domenic_>is there anything shorter than FIXED_ONE_BYTE_STRING(node_isolate, "ContextifyContext")?
23:34:46  <Domenic_>causing serious wrapping issues transitioning from String::New to ... that monstronsity.
23:34:46  <trevnorris>nope, sorry
23:35:01  <Domenic_>ah well
23:35:54  <Domenic_>I can reuse the same Local<String> multiple times in a function, I assume? Current code is doing String::New() twice, but that seems unnecessary.
23:39:24  <trevnorris>you can
23:39:36  * trevnorris&
23:39:37  <LOUDBOT>ICH BIN DER MUSIKANT MIT TASCHENRECHNER IN DER HAND
23:39:44  * EhevuTovquit (Quit: This computer has gone to sleep)
23:41:52  * brson_joined
23:41:52  * brsonquit (Read error: Connection reset by peer)
23:42:28  * dshaw_quit (Quit: Leaving.)
23:47:18  * hueniversequit (Ping timeout: 264 seconds)
23:47:30  * hueniversejoined
23:48:42  * brson_quit (Ping timeout: 264 seconds)
23:50:09  * brsonjoined
23:51:47  <Domenic_>is args[999]->IsUndefined() true or does that blow up horribly
23:54:12  * groundwa_quit (Quit: groundwa_)
23:56:24  <bnoordhuis>Domenic_: true
23:56:49  <Domenic_>bnoordhuis: aww those nice v8 guys they thought of everything
23:58:02  <bnoordhuis>well, at least they made it follow js semantics :)