00:00:16  <txdv_>just had to make sure i understood the api
00:00:28  <txdv_>ill write it down uvbook
00:11:07  * c4milojoined
00:12:08  * EhevuTovquit (Quit: This computer has gone to sleep)
00:18:50  * kazuponjoined
00:19:33  * perezdquit (Quit: perezd)
00:20:18  * perezdjoined
00:25:08  * kazuponquit (Ping timeout: 246 seconds)
00:25:29  * bnoordhuissigns off
00:29:35  * bnoordhuisquit (Ping timeout: 240 seconds)
00:39:48  * perezdquit (Quit: perezd)
00:40:22  * c4miloquit (Remote host closed the connection)
00:47:33  * perezdjoined
00:51:44  * kazuponjoined
00:51:52  * kazuponquit (Remote host closed the connection)
00:51:58  * kazuponjoined
01:12:54  * c4milojoined
01:13:12  * perezdquit (Quit: perezd)
01:15:25  * c4miloquit (Remote host closed the connection)
01:19:39  * brsonjoined
01:39:49  <MI6>joyent/node: Nathan Rajlich v0.8 * 59c166c : repl: move "isSyntaxError()" definition to the bottom fixes lint "line l - http://git.io/8QfKcA
01:40:37  * c4milojoined
01:45:31  * hzquit
02:04:18  * AvianFlujoined
02:13:50  * c4miloquit (Remote host closed the connection)
02:56:56  * brsonquit (Ping timeout: 256 seconds)
02:58:12  * kazuponquit (Remote host closed the connection)
03:39:26  * brsonjoined
04:06:08  * brsonquit (Quit: leaving)
05:06:45  * creationixquit (Ping timeout: 246 seconds)
05:09:10  * creationixjoined
05:09:46  * kazuponjoined
05:26:44  * mmaleckijoined
05:36:50  * mmaleckiquit (Ping timeout: 260 seconds)
05:57:29  * ericktjoined
05:58:14  * ericktquit (Client Quit)
06:00:35  * ericktjoined
06:07:12  * ericktquit (Quit: erickt)
06:10:38  * AvianFluquit (Remote host closed the connection)
06:42:17  * mmaleckijoined
06:51:04  * TheJHjoined
06:52:18  * `3rdEdenjoined
06:54:31  * mmaleckiquit (Ping timeout: 264 seconds)
06:56:44  * `3rdEdenquit (Ping timeout: 246 seconds)
06:57:10  * rendarjoined
07:01:51  * kazuponquit (Remote host closed the connection)
07:07:10  * kristatejoined
07:31:11  * stagasjoined
08:04:40  * mmaleckijoined
08:10:44  * mmaleckiquit (Ping timeout: 260 seconds)
08:14:34  * `3rdEdenjoined
08:15:20  * TooTallNatequit (Quit: Computer has gone to sleep.)
08:22:45  * paddybyersjoined
08:41:06  * paddybyersquit (Ping timeout: 256 seconds)
08:41:43  * stagasquit (Ping timeout: 245 seconds)
08:48:28  * chobi_e_quit (Ping timeout: 256 seconds)
09:08:09  <indutny>so that was not tlsnappy making siege hang
09:08:12  <indutny>but node's master
09:08:48  <indutny>very nice
09:14:39  * hzjoined
09:16:42  * mmaleckijoined
09:20:59  * mmaleckiquit (Ping timeout: 245 seconds)
09:40:16  <txdv_>saghul: did you expose functionality associated with threading in pyuv?
09:40:39  <saghul>txdv_ nope, since Python itself already has it
09:41:05  <saghul>txdv_ that is the only thing I didn't expose, with the uv_dlopen stuff
09:41:23  <saghul>byt the threadpool is exposed
09:42:38  <txdv_>how did you expose the threadpool?\
09:47:42  * stagasjoined
09:50:21  <txdv_>saghul: o man
09:50:27  <txdv_>you exposed the only thing
09:50:33  <txdv_>that exact function makes the entire mono vm hang
09:50:48  <saghul>oh
09:50:57  <saghul>I recall I had trouble with it
09:51:20  <saghul>I hadn't started the Python VM thread state or something
09:51:57  <txdv_>i'm not wrapping it on a c level, so i can't access anything in the vm
09:52:11  <saghul>however in Python I'm limited by the GIL, so even if you put 10 functions there they all need to get the GIL to execute
09:52:21  <saghul>oh, you are doing the ffi dance right?
09:54:22  <txdv_>since it is default mechanism supported by both mono and .net
09:55:40  <saghul>I see. And how does it hang? Does it happen if you don't set any callback?
09:56:15  <txdv_>it executes the code, leaves the main function in the .net world and then the mono vm doesn't finish
09:56:21  <txdv_>6 active threads
09:57:47  <saghul>where does the extra thread come from, mono?
09:57:54  <txdv_>yeah
09:58:33  <txdv_>mono has its own threading classes including a threadpool
09:59:04  <txdv_>i guess ill just cut all the libuv threading/locking stuff out of my wrapper
10:00:07  * stagasquit (Remote host closed the connection)
10:00:27  * stagasjoined
10:00:54  <saghul>I dont't know about mono, but I Python I never needed it
10:01:36  <txdv_>with python you can
10:01:56  <txdv_>yeah the threading classes in the .net BCL are pretty beafy and cover everything
10:04:30  <txdv_>saghul: does python have symbol lookups?
10:04:56  <txdv_>dlsym?
10:05:05  <saghul>with ctypes
10:05:14  <saghul>so yeah
10:05:31  <saghul>you can lust open lib or libm and use their functions
10:05:37  <saghul>and now there is cffi
10:07:45  <txdv_>mono supports only accessing functions
10:07:47  <txdv_>not variables
10:13:45  <saghul>in types / cffi you can access anything AFAIK
10:14:03  <saghul>we did a gnutls wrapper with types
10:14:10  <saghul>types, that is
10:19:29  * `3rdEdenquit (Remote host closed the connection)
10:35:33  * stagasquit (Ping timeout: 252 seconds)
10:48:18  <txdv_>uv_pipe_pending_instances is only available for pipe servers/listeners, the handles that used bind and listen?
11:19:54  * `3rdEdenjoined
11:24:18  * `3rdEdenquit (Ping timeout: 245 seconds)
11:32:05  * Raltjoined
11:37:56  * Raltquit (Remote host closed the connection)
11:38:28  * Raltjoined
11:44:26  * Raltquit (Ping timeout: 264 seconds)
12:03:37  * kazuponjoined
12:09:58  * stagasjoined
12:25:26  * mmaleckijoined
12:42:20  * kazuponquit (Remote host closed the connection)
12:47:41  * AndreasMadsenjoined
12:55:03  * AvianFlujoined
13:06:00  * `3rdEdenjoined
13:06:01  * kazuponjoined
13:20:27  * V1joined
13:23:19  * `3rdEdenquit (Ping timeout: 256 seconds)
13:44:52  * bnoordhuisjoined
13:53:58  * kazuponquit (Remote host closed the connection)
14:01:15  * AndreasMadsenquit (Remote host closed the connection)
14:01:44  * V1quit (Remote host closed the connection)
14:02:01  * paddybyersjoined
14:02:35  * stagasquit (Ping timeout: 240 seconds)
14:05:30  * V1joined
14:09:19  * AndreasMadsenjoined
14:10:35  <txdv_>weekend
14:10:43  <txdv_>isaacs: do you work on libuv?
14:16:22  * paddybyersquit (Ping timeout: 256 seconds)
14:25:54  <bnoordhuis>netbsd... if you want colored ls output, you have to make -C /usr/pkgsrc/misc/gnuls and wait 30 minutes for it to download and compile half the world
14:26:19  <bnoordhuis>i don't think 2012 will be the year of netbsd on the desktop
14:26:59  <bnoordhuis>txdv_: isaacs looks on from a distance, in (presumably) admiration
14:27:12  <bnoordhuis>libuv is mostly bert and i
14:28:02  <indutny>bnoordhuis: indeed
14:28:23  <bnoordhuis>indutny sends in a lot of patches though :)
14:28:25  <indutny>bnoordhuis: that was really selfish
14:28:32  <indutny>ok
14:28:35  <indutny>no like that
14:28:41  <bnoordhuis>some that admittedly take some time to review
14:29:00  <indutny>hahaha
14:29:02  <indutny>ok ok
14:29:12  <indutny>btw
14:29:20  <indutny>it seeems that tlsnappy is finally faster than https
14:29:20  <bnoordhuis>yes, i'll look at uv_wait
14:29:27  <bnoordhuis>yes? very good
14:29:33  <bnoordhuis>so what was the bottleneck?
14:29:36  <indutny>https://docs.google.com/spreadsheet/ccc?key=0AhEDnA4M4EKGdDIwb3VYZTd1alA5T1pTVnlQWl9wanc
14:29:38  <indutny>idk
14:29:48  <indutny>I think event-loop's thread is too busy to process all incoming data
14:30:41  <bnoordhuis>what tab should i be looking at?
14:30:41  <indutny>bnoordhuis: lock-less siege
14:30:41  <indutny>there was some interference
14:30:41  <indutny>in https benchmark
14:30:41  <indutny>but you should see correct numbers
14:30:54  <bnoordhuis>indutny: lots of peaks - or rather, valleys
14:31:25  <bnoordhuis>load average is a nice curve though
14:31:45  <indutny>haha
14:31:57  <indutny>you see interference in https
14:32:08  <indutny>load average
14:32:08  <indutny>a big peak
14:32:11  <indutny>where https was low on rps
14:32:34  <indutny>so as you can see it doesn't ate too much cpu
14:32:40  <indutny>in comparison to https and nginx
14:32:53  <indutny>basically that's becase main thread was 100% CPU busy
14:34:50  <indutny>and all other threads about 30-40%
14:34:51  <indutny>but doing BIO_write and SSL_read at the same time
14:34:51  <indutny>is really good thing
14:37:32  <bnoordhuis>one more thing about netbsd... i expect make -C /usr/pkgsrc/misc/git to install git, not some damn file browser
14:47:05  <mmalecki>wtf...
14:49:05  * bradleymeckjoined
14:49:15  <bnoordhuis>mmalecki: it's because git is in /usr/pkgsrc/devel/gitscm-base
14:49:40  <bnoordhuis>netbsd gets zero points for discoverability
14:50:35  <mmalecki>bnoordhuis: obviously
14:51:03  <bradleymeck>anyone seen `ar` called without a type of archive when depending on libuv with smartos?
14:51:07  <bradleymeck>via gyp*
14:51:29  <mmalecki>bnoordhuis: smartos has gitscm package
14:51:48  <bnoordhuis>mmalecki: no surprise, smartos uses netbsd's pkgsrc
14:52:08  <bnoordhuis>bradleymeck: what's the exact line?
14:52:13  <indutny>haha
14:52:34  <bradleymeck>bnoordhuis: https://gist.github.com/5f89e46901c43e50a5ff
14:52:45  <indutny>mmalecki: wanna help me with benchmarking?
14:53:06  <indutny>:)
14:53:06  <bnoordhuis>bradleymeck: can you run make V=1?
14:53:06  <mmalecki>indutny: yeah
14:54:05  <bradleymeck> bnoordhuis https://gist.github.com/5f89e46901c43e50a5ff
14:54:20  <indutny>mmalecki: do you know what to do? :)
14:55:01  <mmalecki>indutny: I have no idea. tell me please
14:56:31  <bradleymeck>V=1 added the rm line, still not too helpful, dont see what ar was actually called with, sigh
14:57:27  <bnoordhuis>bradleymeck: what platform is that?
14:57:49  <bnoordhuis>bradleymeck: btw, it calls ar crsT
14:57:56  <bnoordhuis>and apparently it doesn't like the -T switch
14:58:05  <bradleymeck>smartos64
14:58:30  <bnoordhuis>bradleymeck: maybe smartos doesn't support thin archives?
14:59:08  <bnoordhuis>bradleymeck: ah, i think -T means something different with sun's ar
14:59:55  <bnoordhuis>bradleymeck: what happens when you run make AR=gar?
15:00:39  * kazuponjoined
15:03:33  <bradleymeck>cant find it sec
15:07:30  <bradleymeck>well no idea on how to get gar easily ill tackle this later
15:10:06  * ericktjoined
15:16:27  * V1quit (Remote host closed the connection)
15:16:53  <bnoordhuis>bradleymeck: gar is gnu ar, you may already have it installed somewhere
15:17:22  <bradleymeck>i know but it did not appear to come with gcc-compiler or gmake
15:27:08  <MI6>joyent/libuv: Ben Noordhuis master * 7833df1 : freebsd, openbsd: don't use fdatasync() The fdatasync() system call does - http://git.io/Kt3sHw
15:27:18  <bnoordhuis>bradleymeck: you probably need to install the binutils package
15:29:27  <bradleymeck>conflicts with gcc-tools, but sec
15:30:12  * travis-cijoined
15:30:14  <travis-ci>[travis-ci] joyent/libuv#778 (master - 7833df1 : Ben Noordhuis): The build passed.
15:30:15  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/7aa126176921...7833df14ba7c
15:30:15  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/2689194
15:30:15  * travis-cipart
15:30:32  <bradleymeck>no change
15:35:44  <AndreasMadsen>bradleymeck: perhaps this (https://gist.github.com/3732950) helps, it dosn't tell you how to compile libuv, but node instead. I can't imagine that the difference is big.
15:37:55  * kazuponquit (Remote host closed the connection)
16:23:28  * TooTallNatejoined
16:36:20  * TheJHquit (Ping timeout: 256 seconds)
16:36:50  * TheJHjoined
16:37:00  <TooTallNate>isaacs: yt?
16:38:22  * TheJHquit (Read error: Connection reset by peer)
16:44:41  * TheJHjoined
16:45:14  * c4milojoined
16:46:01  * paddybyersjoined
16:46:07  * AndreasMadsenquit (Remote host closed the connection)
16:48:24  * kazuponjoined
16:49:02  * AndreasMadsenjoined
16:53:45  * kazuponquit (Ping timeout: 246 seconds)
17:06:39  * paddybyersquit (Ping timeout: 260 seconds)
17:09:19  * AndreasMadsenquit (Remote host closed the connection)
17:12:32  <txdv_>hei bnoordhuis
17:18:04  <txdv_>not many changes in the api in master
17:18:13  <txdv_>only cond vars exposed
17:18:27  <txdv_>bnoordhuis: how is the ripping out of libev going on?
17:33:50  * stagasjoined
17:47:00  <txdv_>hey
17:47:01  <txdv_>i was wondering
17:47:06  <txdv_>i can ref and unref handles
17:47:25  <txdv_>but what if i want to use my own threadpool and write my own implementation of queuework
17:47:33  <txdv_>how do i gonna tell the loop, wait, don't stop
17:54:18  <txdv_>how do i gonna tell the loop, wait, don't stop
17:54:22  <txdv_>o sry
17:58:02  * loladirojoined
17:59:22  * c4miloquit (Remote host closed the connection)
18:10:01  * ericktquit (Quit: erickt)
18:18:02  * paddybyersjoined
18:19:13  * AndreasMadsenjoined
18:25:53  * ericktjoined
18:32:05  * paddybyersquit (Ping timeout: 246 seconds)
18:40:00  * V1joined
18:42:36  * paddybyersjoined
18:58:41  * paddybyersquit (Ping timeout: 246 seconds)
19:53:51  * bradleymeckquit (Quit: bradleymeck)
19:56:19  * kuplatupsuquit (*.net *.split)
19:56:19  * hzquit (*.net *.split)
19:56:19  * KiNgMaRquit (*.net *.split)
19:56:19  * einarosquit (*.net *.split)
19:57:02  * kuplatup1ujoined
19:57:02  * hzjoined
19:57:02  * KiNgMaRjoined
19:57:17  * einarosjoined
20:01:40  * kuplatup1uquit (*.net *.split)
20:01:40  * hzquit (*.net *.split)
20:01:40  * KiNgMaRquit (*.net *.split)
20:02:05  * kuplatup1ujoined
20:02:05  * hzjoined
20:02:05  * KiNgMaRjoined
20:06:29  <txdv_>hey saghul
20:06:51  <saghul>hey txdv_
20:07:08  <txdv_>saghul: you are trying to use queuework and it results in crashes?
20:07:08  * joshthecoderjoined
20:07:56  <saghul>txdv_ well, I didn't crash, but since the libeio removal I'm seeing some weird crashes, hard to reproduce
20:08:09  <saghul>but the crash happens inside libuv
20:08:28  <saghul>txdv_ https://github.com/joyent/libuv/issues/580
20:08:48  * brsonjoined
20:09:16  <txdv_>but you are invoking queue_work in pyuv?
20:09:38  * V1quit (Remote host closed the connection)
20:09:39  <saghul>yes
20:09:53  <saghul>that works fine
20:10:16  <txdv_>doesn't the GIL kinda defeat the purpose of queue_work?
20:10:31  <saghul>yeah
20:10:59  <saghul>but since it was there I just wrapped it :-)
20:11:02  <txdv_>you said yourself that you would just use the python thread pool
20:11:11  <txdv_>I wrapped it too, but mono crashes
20:11:18  <saghul>well, you can build a threadpool
20:11:33  <saghul>but queue_work takes care of reporting the result in the calling thread
20:11:39  <saghul>so that was convenient
20:11:49  * erickt_joined
20:11:50  <saghul>so I wrapped it :-)
20:12:28  <txdv_>i just used the .net threadpool to emulate queue_work and it works fine
20:13:04  <saghul>if that works I wouldn't bother with queue_work
20:13:17  <saghul>I may remove it some day
20:13:23  <saghul>for now it doesn't bother me
20:14:02  <txdv_>it worked
20:14:10  <txdv_>the loop didn't block though at first
20:14:29  <txdv_>but i have an async object always created with the loop interthread communication
20:14:42  <txdv_>so i created a ref and unref functionality for the loop
20:15:33  <bnoordhuis>saghul: do you get the crash locally?
20:15:40  <txdv_>on travis
20:15:47  <saghul>bnoordhuis now I do
20:15:50  <saghul>on OSX
20:15:55  <saghul>can't make it happen on Linux
20:16:10  * paddybyersjoined
20:16:12  <bnoordhuis>saghul: is your os x binary 32 bits?
20:16:18  <saghul>seems ray because it happens at different points, but always on fs operations
20:16:44  <saghul>nope, 64
20:16:56  <bnoordhuis>hmm okay
20:17:49  * loladiroquit (Quit: loladiro)
20:27:44  * c4milojoined
20:32:37  <MI6>joyent/libuv: Ben Noordhuis master * b152b12 : unix: fix scandir filter prototype again The only platforms where the di - http://git.io/Jf6Uvg
20:34:39  * travis-cijoined
20:34:39  <travis-ci>[travis-ci] joyent/libuv#779 (master - b152b12 : Ben Noordhuis): The build passed.
20:34:39  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/7833df14ba7c...b152b1277278
20:34:39  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/2691178
20:34:39  * travis-cipart
20:35:34  * mmaleckiquit (Quit: PARTY)
20:43:15  * mmaleckijoined
20:43:33  * mmaleckichanged nick to mmalecki[away]
20:56:13  * AvianFluquit (Remote host closed the connection)
21:00:14  <MI6>joyent/libuv: Ben Noordhuis master * b9ed1a6 : unix: don't abort() on EINVAL in threadpool.c The FreeBSD implementation - http://git.io/qUi6eQ
21:02:22  * travis-cijoined
21:02:23  <travis-ci>[travis-ci] joyent/libuv#780 (master - b9ed1a6 : Ben Noordhuis): The build passed.
21:02:23  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/b152b1277278...b9ed1a6dbf0e
21:02:23  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/2691409
21:02:23  * travis-cipart
21:02:23  <bnoordhuis>libuv on freebsd is in pretty good shape, all things considering
21:10:45  * paddybyersquit (Ping timeout: 260 seconds)
21:15:03  * ericktquit (Quit: erickt)
21:15:04  * erickt_changed nick to erickt
21:18:11  <bnoordhuis>what's up with pummel/test-https-ci-reneg-attack taking so long in debug mode?
21:18:28  <bnoordhuis>it's not particularly busy, it's only using 25% of one core
21:19:51  <bnoordhuis>the reneg protection probably isn't working but if that's the case, why doesn't it use more cpu?
21:20:05  * V1joined
21:24:45  * V1quit (Ping timeout: 260 seconds)
21:32:37  * AvianFlujoined
21:38:10  * rendarquit
21:38:11  * AndreasMadsenquit (Remote host closed the connection)
21:40:06  * TooTallNatequit (Quit: Computer has gone to sleep.)
21:48:48  * kristatequit (Ping timeout: 260 seconds)
22:16:35  * paddybyersjoined
22:24:29  * paddybyersquit (Ping timeout: 246 seconds)
22:34:44  * c4miloquit (Remote host closed the connection)
22:37:24  * AvianFluquit (Remote host closed the connection)
22:41:55  * brsonquit (Quit: leaving)
22:48:43  * erickt_joined
22:48:45  <MI6>joyent/node: Ben Noordhuis master * 621caa7 : Update LICENSE file. (+1 more commits) - http://git.io/7Vod0g
22:55:24  * erickt_quit (Quit: erickt_)
22:59:14  * loladirojoined
23:06:41  * ericktquit (Quit: erickt)
23:12:03  * AvianFlujoined
23:16:57  * ericktjoined
23:20:58  * ericktquit (Client Quit)
23:50:38  * bradleymeckjoined
23:58:12  * TheJHquit (Ping timeout: 255 seconds)