00:01:23  <isaacs>yeah, that maeks it work
00:01:59  * paddybyersquit (Ping timeout: 245 seconds)
00:02:45  <MI6>joyent/node: isaacs streams2 * 10a9fc2 : transform: Automatically read() on _write when read buffer is empty (+1 more commits) - http://git.io/WzXYjg
00:02:54  <isaacs>alright, i'm calling zlib streams done now.
00:03:03  <isaacs>it's passing all the things.
00:03:12  <isaacs>and transform stream api is pretty solid.
00:04:57  <chilts>isaacs++
00:04:59  <chilts>:)
00:05:14  <chilts>aww, we don't have a counterbot-type-thing in here :D
00:10:56  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
00:19:37  * AvianFluquit (Remote host closed the connection)
00:28:20  * stephankquit (Ping timeout: 252 seconds)
00:30:28  * ericktquit (Quit: erickt)
00:31:48  * stephankjoined
00:34:55  * ericktjoined
00:36:08  * EhevuTovjoined
00:38:43  * ericktquit (Client Quit)
00:39:29  * hzjoined
00:40:38  * stephankquit (Quit: *Poof!*)
00:43:34  * c4miloquit (Remote host closed the connection)
00:54:33  * hzquit
00:56:11  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:57:43  * c4milojoined
01:09:05  * EhevuTovquit (Quit: This computer has gone to sleep)
01:13:04  * lohkeyquit (Quit: lohkey)
01:19:47  * AvianFlujoined
01:28:07  * piscisaureus_joined
01:32:30  * piscisaureus_quit (Client Quit)
01:40:03  * piscisaureus_joined
01:43:25  * piscisaureus_quit (Client Quit)
01:45:29  * TooTallNatejoined
01:57:23  * kazuponquit (Remote host closed the connection)
01:59:16  * bnoordhuisjoined
02:14:45  * ericktjoined
02:18:17  * erickt_joined
02:40:28  * ericktquit (Quit: erickt)
02:40:28  * erickt_changed nick to erickt
02:40:43  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
02:46:56  * erickt_joined
03:01:07  * Benviequit (*.net *.split)
03:10:13  * erickt_quit (Quit: erickt_)
03:25:55  * erickt_joined
03:30:29  * indexzerojoined
03:31:03  * brsonquit (Quit: leaving)
03:34:28  * c4miloquit (Remote host closed the connection)
03:36:29  * lohkeyjoined
03:40:34  * erickt_quit (Quit: erickt_)
03:41:38  * bnoordhuisquit (Ping timeout: 248 seconds)
03:46:06  * erickt_joined
03:59:49  * tomshredsquit (Quit: Leaving...)
04:16:29  * ericktquit (Quit: erickt)
04:16:29  * erickt_changed nick to erickt
04:17:24  * ericktquit (Quit: erickt)
04:19:17  * ericktjoined
04:30:42  * mralephquit (Quit: Leaving.)
04:41:41  * erickt_joined
04:46:23  * c4milojoined
04:54:23  * Benviejoined
05:06:58  * mralephjoined
05:07:07  * mralephquit (Client Quit)
05:23:23  * paddybyersjoined
05:31:42  * indexzeroquit (Read error: Connection reset by peer)
05:36:42  * c4miloquit (Remote host closed the connection)
06:02:35  * lohkeyquit (Quit: lohkey)
06:11:11  * paddybyersquit (Ping timeout: 246 seconds)
06:16:07  * paddybyersjoined
06:33:58  * V1joined
06:34:21  * V1changed nick to `3rdEden
06:38:56  * Raltjoined
06:41:15  * Raltquit (Read error: Connection reset by peer)
06:43:51  * stagasjoined
06:45:07  * kohaijoined
06:48:08  * rendarjoined
06:51:43  * Raltjoined
07:06:00  * ericktquit (Quit: erickt)
07:06:05  * erickt_changed nick to erickt
07:47:58  * mikealquit (Quit: Leaving.)
07:50:49  * stephankjoined
08:09:27  * AvianFluquit (Remote host closed the connection)
08:21:31  * felixgejoined
08:21:31  * felixgequit (Changing host)
08:21:31  * felixgejoined
08:42:50  * perezdquit (Read error: No route to host)
08:43:06  * perezdjoined
08:45:37  * felixgequit (Quit: felixge)
08:49:19  * perezdquit (Read error: No route to host)
08:49:31  * perezdjoined
08:50:31  * perezdquit (Read error: No route to host)
08:53:28  * perezdjoined
08:54:51  * perezdquit (Read error: No route to host)
08:55:02  * perezdjoined
08:56:46  * perezdquit (Read error: No route to host)
08:57:50  * perezdjoined
09:00:57  * perezd_joined
09:01:06  * perezdquit (Read error: Connection reset by peer)
09:01:06  * perezd_changed nick to perezd
09:17:09  * perezd_joined
09:17:16  * perezdquit (Read error: Connection reset by peer)
09:17:16  * perezd_changed nick to perezd
09:18:31  * perezd_joined
09:18:40  * perezdquit (Read error: Connection reset by peer)
09:18:41  * perezd_changed nick to perezd
09:24:11  * mikealjoined
09:24:36  * perezdquit (Ping timeout: 240 seconds)
09:30:54  * paddybyers_joined
09:31:59  * paddybyersquit (Ping timeout: 245 seconds)
09:31:59  * paddybyers_changed nick to paddybyers
09:40:43  * mikealquit (Ping timeout: 256 seconds)
09:53:03  * `3rdEdenchanged nick to `3E|Lunch
09:53:17  * felixgejoined
09:53:17  * felixgequit (Changing host)
09:53:17  * felixgejoined
09:59:59  * felixgequit (Read error: Connection reset by peer)
10:03:55  * hzjoined
10:06:00  * kristatejoined
10:12:13  * stagas_joined
10:12:40  * stagasquit (Ping timeout: 244 seconds)
10:12:55  * stagas_changed nick to stagas
10:16:59  * paddybyersquit (Ping timeout: 245 seconds)
10:21:40  * felixgejoined
10:21:40  * felixgequit (Changing host)
10:21:40  * felixgejoined
10:22:47  * felixgequit (Read error: No route to host)
10:24:41  * piscisaureus_joined
10:33:03  * piscisaureus_quit (Read error: Connection reset by peer)
10:33:29  * piscisaureus_joined
10:45:22  * `3E|Lunchchanged nick to `3rdEden
10:54:19  * abraxasquit (Remote host closed the connection)
11:05:11  <MI6>joyent/libuv: Hiroaki Nakamura master * 976c8a4 : Add support for condition variables on all platforms - http://git.io/58XeJQ
11:05:19  * paddybyersjoined
11:06:53  * travis-cijoined
11:07:06  <travis-ci>[travis-ci] joyent/libuv#773 (master - 976c8a4 : Hiroaki Nakamura): The build passed.
11:07:06  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/744dc3e77c9b...976c8a4387e5
11:07:06  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/2674588
11:07:06  * travis-cipart
11:17:49  * stagasquit (Ping timeout: 245 seconds)
11:31:05  * c4milojoined
11:38:03  * bnoordhuisjoined
11:39:21  <bnoordhuis>that 'linkedin moved from rails to node' thing that's doing the rounds on HN now?
11:39:28  <bnoordhuis>i may have been responsible for that
11:41:29  <deoxxa>heh
11:41:55  <deoxxa>plenty of raging idiots from both sides of the fence commenting on those posts at the moment
11:42:05  * deoxxatips hat
11:46:41  <piscisaureus_>bnoordhuis: how did your talk go?
11:47:08  <bnoordhuis>piscisaureus_: pretty good but the live demo failed thanks to the crappy wifi
11:47:23  <piscisaureus_>bnoordhuis: good you're getting some practice :-)
11:48:06  <piscisaureus_>bnoordhuis: at 50% of the conferences wifi is unreliable, you always need a backup plan
11:48:21  <piscisaureus_>(or bring your own internet as we did as oscon)
11:48:32  <bnoordhuis>piscisaureus_: i had one: keep talking until my time was up :)
11:48:42  <piscisaureus_>haha
11:49:14  <piscisaureus_>bnoordhuis: did go better than the amsterdamjs talk?
11:49:32  <bnoordhuis>piscisaureus_: yeah, i'd prepared it a little better
11:49:41  <piscisaureus_>good
11:53:52  <piscisaureus_>bnoordhuis: btw, https://github.com/piscisaureus/libuv/commit/multisig
11:53:59  <piscisaureus_>^-- that's basically all there was to it
11:54:11  <piscisaureus_>unfortunately there's a lot of places I call abort() ...
11:55:25  <piscisaureus_>bnoordhuis: it's not done yet btw - the test is nothing
11:55:35  <piscisaureus_>bnoordhuis: but you can review this if you like, ok
11:58:19  <bnoordhuis>piscisaureus_: already doing that
12:03:12  <bnoordhuis>it's odd, i remember adding multi-loop support myself... maybe i never actually landed that
12:04:59  <piscisaureus_>bnoordhuis: you told me you never got it right
12:05:27  <bnoordhuis>i did? my memory must be declining with age
12:05:27  <piscisaureus_>bnoordhuis: tell me the branch
12:06:41  <bnoordhuis>my more-signals branch? it doesn't look quite how i remember it though
12:07:03  <bnoordhuis>well, nvm - your branchs looks okay
12:07:37  <mmalecki>MOAR SIGNALS
12:07:42  <mmalecki>ADD MOAR SIGNALS
12:07:58  <mmalecki>SOMEONE POUR ME MORE SIGNALS
12:09:38  <piscisaureus_>bnoordhuis: there's one thing I am concerned about
12:09:45  <bnoordhuis>piscisaureus_: some style issues like your wonky windows comments and braces for single-line statements
12:09:50  <bnoordhuis>but nothing serious
12:10:10  <txdv_>SIGNALZZ
12:10:26  <bnoordhuis>piscisaureus_: so what's the concern?
12:10:48  <piscisaureus_>bnoordhuis: I am assuming that sigaddset and sigdelset modify a sigset_t sort of atomically
12:11:05  <bnoordhuis>piscisaureus_: oh. they don't
12:11:19  <piscisaureus_>not really atomically, but atleast without going through an intermediate "bad" state
12:11:33  <bnoordhuis>piscisaureus_: right. there's no guarantee
12:11:43  <piscisaureus_>because right
12:11:45  <piscisaureus_>right
12:12:12  <piscisaureus_>bnoordhuis: so I probably need to signal_lock/signal_unlock around sigaddset/sigdelset calls
12:12:18  <bnoordhuis>yes
12:12:20  <piscisaureus_>that would solve it
12:13:08  <piscisaureus_>bnoordhuis: I remember promising felixge that I would fix this, a year ago
12:13:16  <piscisaureus_>(at last years jsconf)
12:13:27  <piscisaureus_>and i'm about to go there again
12:13:34  <piscisaureus_>so now I can say I didn't lie :-)
12:14:48  * piscisaureus_quit (Read error: Connection reset by peer)
12:15:11  * piscisaureus_joined
12:29:43  <bnoordhuis>paddybyers: interesting lxjs talk. too bad the demo didn't work
12:30:04  <paddybyers>bnoordhuis: :(
12:30:18  <bnoordhuis>paddybyers: everything else was good though :)
12:30:25  * paddybyersworked every time up to that point :)
12:31:01  <txdv_>what talk
12:31:06  <txdv_>video?
12:31:18  <txdv_>bnoordhuis: how went the ruby talk?
12:31:26  <paddybyers>bnoordhuis: so you weren't able to make it yourself
12:31:44  <bnoordhuis>bnoordhuis: mostly good. my demo didn't work either :)
12:31:49  <bnoordhuis>err, txdv_
12:32:27  <txdv_>don't you test the demos before?
12:32:33  <paddybyers>txdv_:http://www.youtube.com/watch?v=zLeZXSKePhQ
12:32:36  <mmalecki>NO
12:32:53  <bnoordhuis>paddybyers: well... piscisaureus_ was already doing a talk so i didn't have to
12:33:12  <bnoordhuis>txdv_: testing is for the weak. also, it was due to crappy wifi
12:33:16  <mmalecki>bnoordhuis: did you watch my talk?
12:33:20  <bnoordhuis>mmalecki: yes
12:33:28  <bnoordhuis>mmalecki: you were kind of nervous, weren't you?
12:33:37  <txdv_>so did you convince the rubists to use node/libuv?
12:33:39  <mmalecki>bnoordhuis: man. I was so hangover
12:33:50  <mmalecki>when dscape called me out, I was finishing my slides
12:34:01  <mmalecki>that's why there's vim on the beginning
12:34:12  <bnoordhuis>txdv_: actually, a lot of them had already used node
12:34:52  <mmalecki>my talk was kind of a fuckup anyway, I should've changed the topic when I got to know that I won't be speaking about libuv
12:35:13  <mmalecki>which was a week before the conference >.<
12:35:20  <bnoordhuis>mmalecki: oh well, better luck next time. it was still pretty decent
12:35:47  <txdv_>paddybyers: doesn't safari have a full screen mode?
12:35:59  <mmalecki>yeah, I'm used to doing talks drunk, hangover and sick
12:37:07  <paddybyers>txdv_: yes if course, but I was thrown by things going bad at the very start
12:38:08  <paddybyers>bnoordhuis: btw I talked to @mraleph about this addition to the v8 api:
12:38:17  <paddybyers>https://github.com/joyent/node/blob/master/deps/v8/include/v8.h#L1987
12:38:37  <paddybyers>you can now recover the isolate cheaply whenever entered from js
12:38:59  <paddybyers>wasn't there last time I looked
12:39:11  <bnoordhuis>piscisaureus_: oh, good. not that node needs it now :)
12:39:21  <bnoordhuis>damn, auto-complete fail
12:39:26  <bnoordhuis>paddybyers: ^
12:39:46  <bnoordhuis>paddybyers: how is the upgrade to 0.8 working out?
12:39:58  <paddybyers>not really got going yet
12:41:49  <bnoordhuis>paddybyers: let me know if you hit any roadblocks, i don't mind landing patches in 0.8/master that help you out (within reason of course)
12:42:12  <paddybyers>thanks - I'll defintely keep you posted
12:52:55  <indutny>bnoordhuis: hoya
12:53:02  <bnoordhuis>indutny: heya
12:53:18  <indutny>bnoordhuis: can you please review/help me with https://github.com/indutny/tlsnappy/blob/feature-no-locks/src/atomic.h ?
12:53:35  <indutny>piscisaureus_: ^^
12:53:59  <indutny>would be great to have visual studio support here too
12:55:37  <bnoordhuis>indutny: sure, in a minute
12:55:42  <indutny>bnoordhuis: thanks man
12:55:55  <indutny>bnoordhuis: btw, I'm writing directly to rings w/o calling BIO_write/BIO_read now
12:56:02  <indutny>bnoordhuis: don't see big performance boost though
12:56:29  <indutny>there're locks remaining here which I'm going to remove
12:56:38  <indutny>and if after that it'll be slower than https
12:56:43  <indutny>I don't really know what to do
12:56:48  <indutny>probably benchmark is just incorrect
13:07:06  <MI6>joyent/libuv: Ben Noordhuis master * 7aa1261 : include: fix confusing uv_tcp_keepalive comment - http://git.io/lIQ1Xw
13:08:34  * travis-cijoined
13:08:34  <travis-ci>[travis-ci] joyent/libuv#774 (master - 7aa1261 : Ben Noordhuis): The build passed.
13:08:34  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/976c8a4387e5...7aa126176921
13:08:34  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/2675911
13:08:34  * travis-cipart
13:20:54  * AvianFlujoined
13:23:13  * piscisaureus_quit (Ping timeout: 252 seconds)
13:48:52  * kazuponjoined
13:54:41  * tomshredsjoined
14:02:33  * c4miloquit (Remote host closed the connection)
14:03:44  * bettajoined
14:06:20  <txdv_>yo ladies
14:06:27  <betta>hi
14:06:31  <txdv_>i wonder if I need to always use read2 on pipes with IPC = 1
14:10:10  * c4milojoined
14:10:47  <indutny>bnoordhuis: oh, btw
14:10:55  <indutny>bnoordhuis: what do you think about refactoring async handles
14:10:59  <saghul>txdv_ if you don't use it you'll not be able to get handles sent over it
14:11:21  <indutny>I would like to write their pointers to the pipe, instead of just writing one byte and traversing all queue to search handles
14:11:34  <betta>uhm I have a question I couldn't find a answer for…
14:11:36  <indutny>it seems that writes that are less than PIPE_BUF bytes are always atomic
14:11:37  <betta>what's the best way to detect in a uv_write callback, if all existing sockets finished sending their data?
14:12:41  <betta>or do uv_write callbacks always only get called once for every call to uv_write?
14:12:55  <indutny>I think they're
14:13:45  <betta>it's because I seem to loose data when rapidly sending over slow networks
14:13:51  <betta>(using TCP)
14:13:59  * erickt_joined
14:15:21  <betta>currently I write data to a socket, and in the callback a worker will be invoked, which in turn sends the next packet of data
14:15:41  * kazuponquit (Remote host closed the connection)
14:16:01  <saghul>each call to uv_write will have its corresponding callback
14:16:12  <betta>hmm ok
14:16:12  <saghul>called, that is
14:16:24  <betta>it's just really strange
14:16:57  <betta>I don't think that my (de)compress algorithms are broken, because everything works fine on fast networks
14:17:24  <MI6>joyent/node: isaacs streams2 * 0c256c8 : streams2: fs streams (+1 more commits) - http://git.io/qPP8cg
14:17:32  <isaacs>fs streams are working, but 3 tests are failing. i think the tests are probably not valid.
14:17:48  <txdv_>wi don't understand the purpose of the UV_CREATE_PIPE flag for spawn
14:17:52  <isaacs>they seem like they're testing old inconsistent stream behavior that we all have wanted to change for some time.
14:17:54  <betta>is it possible then, that OS X drops somehow packages?
14:18:12  <indutny>txdv_: huh?
14:18:18  <indutny>txdv_: what's not clear?
14:18:49  <txdv_>does the pipe i am passing to it has to be with IPC = 1?
14:18:59  <indutny>no
14:19:13  <txdv_>how is different from UV_INHERIT_STREAM
14:19:18  <indutny>well
14:19:28  <indutny>inherit stream is reusing existing open stream
14:19:35  <indutny>while UV_CREATE_PIPE will create new one
14:21:09  <indutny>oh wait
14:21:15  <indutny>ok
14:21:18  <indutny>so the difference is
14:21:28  <indutny>that stream should be closed in case of UV_CREATE_PIPE
14:21:35  <indutny>i.e. should not have file descriptor
14:22:36  <txdv_>so if i want to just read the output of the spawned process, i need to use uv_create_pipe?
14:23:21  <saghul>if you use UV_CREATE_PIPE, the pipe must be initialized, but not bound
14:23:31  <saghul>so it has no fd assigned, as indutny said
14:23:43  <indutny>saghul: yes
14:23:53  <indutny>txdv_: I think so
14:24:07  <saghul>so, just uv_pipe_init the thing and pass it along
14:24:25  <indutny>uv_spawn will open it for you
14:25:29  <indutny>bnoordhuis: yt?
14:27:36  <txdv_>i can't get an example running where the main app just reads the output of the spawned process
14:28:19  * philips_quit (Excess Flood)
14:29:57  * philips_joined
14:30:35  * lohkeyjoined
14:30:49  * lohkeyquit (Client Quit)
14:34:19  <bnoordhuis>indutny: ih
14:34:41  <txdv_>so annoying
14:35:02  * bettapart
14:36:18  <indutny>bnoordhuis: it's on master now
14:36:19  <indutny>just in case
14:36:20  <indutny>and btw
14:36:25  <indutny>reminding you about uv_wait()
14:36:33  <bnoordhuis>indutny: what's on master?
14:36:38  <indutny>atomic stuff
14:36:43  <indutny>on tlsnappy's master
14:36:45  <bnoordhuis>ah
14:40:07  <saghul>txdv_ it's python, but I may help you: https://github.com/saghul/pyuv/blob/master/tests/test_process.py#L56
14:45:19  * tomshredsquit (Ping timeout: 245 seconds)
14:50:26  <MI6>joyent/node: isaacs streams2 * a98e5c2 : test: Correct fs writable stream 2 test (+3 more commits) - http://git.io/W578Fw
14:50:50  <txdv_>o me stuped
14:50:52  * erickt_quit (Quit: erickt_)
14:51:38  <bnoordhuis>indutny: why the memory barrier?
14:52:46  <indutny>bnoordhuis: because I want to be sure that memcpy writes were finished
14:53:29  * kazuponjoined
14:56:05  <txdv_>saghul: if i pass that stream in stdio[4] then the child process will have an fd = 4 which links to that pipe?
14:56:47  <saghul>txdv_ yep
14:56:58  <saghul>the first 3 are fds 0, 1, and 2
14:57:03  <saghul>then just keep counting
14:57:10  <txdv_>the c api is horrible
14:57:20  <txdv_>and you just mapped it in python
14:57:30  <indutny>bnoordhuis: also it seems that ring buffers is incorrect
14:57:39  <indutny>sometimes read head stalls on empty pages
14:57:46  <indutny>with both roffset and woffset = 0
14:57:48  <indutny>hm...
14:57:53  <txdv_>saghul: thanks for the help
14:58:01  <saghul>yes, if someone wants to give it a nicer look it's fine, but pyuv is just a thin wrapper :-)
14:58:08  <bnoordhuis>indutny: btw, have you measured mutex overhead?
14:58:49  <bnoordhuis>i mean, all this fiddling with lockless algorithms is pointless if mutexes aren't actually a bottleneck
15:01:19  <indutny>bnoordhuis: Idk
15:01:24  <indutny>bnoordhuis: :)
15:01:40  <indutny>bnoordhuis: I'm just trying to reduce possible stallness
15:01:55  <indutny>like when main thread writes to buffer and worker thread reads from it
15:02:07  <bnoordhuis>indutny: premature optimization, root of all evil, etc.
15:02:22  <indutny>bnoordhuis: well
15:02:27  <indutny>bnoordhuis: why is it slow then? :)
15:02:37  <indutny>bnoordhuis: I've tried almost every thing, but I can't get it
15:03:20  <bnoordhuis>indutny: profile, profile, profile
15:03:45  <indutny>bnoordhuis: nothing in profiles
15:03:47  <indutny>really nothing
15:03:51  <indutny>you can try it yourself
15:04:05  <indutny>there're openssl stuff that lasts almost 98% of time
15:04:07  <indutny>and nothing else
15:04:32  <bnoordhuis>indutny: if openssl is the bottleneck, optimizing the remaining 2% isn't going to help much
15:04:33  <indutny>that's why I thought it's wasting time in preemption
15:04:53  <indutny>bnoordhuis: well, realtime ring buffers are good anyway
15:05:05  <indutny>it should improve responsiveness
15:05:19  <indutny>at least that's the last thing I can do with it now
15:05:29  * Raltquit (Ping timeout: 240 seconds)
15:06:13  <indutny>bnoordhuis: so do you think inserting barrier is not required there?
15:06:46  <bnoordhuis>indutny: i don't think so (but i might be wrong)
15:07:01  <bnoordhuis>memory barriers are for conflicting stores/reads but i don't think that applies here
15:07:18  <indutny>bnoordhuis: why not
15:07:26  <indutny>bnoordhuis: suppose Write() and Read() happens at the same time
15:07:27  <indutny>nearly
15:07:36  <bnoordhuis>because the actual conflicting stores/reads are for the offset_ var
15:07:43  <bnoordhuis>you may need a compiler barrier though
15:07:43  <indutny>well, yes
15:07:50  <indutny>how can I do that?
15:07:54  <indutny>by using volatile?
15:08:06  <bnoordhuis>i don't know how it works for non-gcc compilers
15:08:21  <indutny>asm volatile ("":::"memory");
15:08:23  <bnoordhuis>but in gcc it's __asm__ __volatile__ ("" ::: "memory")
15:08:26  <indutny>yeah
15:08:45  <indutny>hm...
15:08:51  <indutny>that's harder than hardware ones
15:08:55  <indutny>ok
15:08:59  <indutny>gtg
15:09:04  <indutny>I'll be back in 20 minutes
15:09:12  <bnoordhuis>good luck :)
15:19:08  * paddybyersquit (Ping timeout: 240 seconds)
15:23:21  * tomshredsjoined
15:25:00  <MI6>joyent/node: isaacs streams2 * df933bb : fs.ReadStream: Don't allow non-integer bufferSize (+1 more commits) - http://git.io/NvaQ0Q
15:28:20  * stagasjoined
15:30:34  <isaacs>streams2, osx, fs and zlib using new interfaces: [02:16|% 100|+ 478|- 0]: Done
15:35:04  * `3rdEdenchanged nick to `3E|DINNER
15:39:44  <tjfontaine>excellent work
15:43:01  * paddybyersjoined
15:48:05  <indutny>back
15:48:12  <indutny>isaacs: ++
15:48:13  <kohai>isaacs has 23 beers
15:49:21  * `3E|DINNERquit (Remote host closed the connection)
15:55:39  <txdv_>dafuq
15:55:42  <txdv_>how many do I have?
15:56:19  <indutny>txdv_: --
15:56:20  <kohai>txdv_ has -1 beer
15:56:26  <indutny>zero I suppose?
15:56:28  <indutny>txdv--
15:56:28  <kohai>txdv has -1 beer
15:56:33  <indutny>definitely zero
15:56:47  * TheJHjoined
15:57:07  <txdv_>russians stealing beer
15:57:09  <txdv_>you have vodka
15:57:35  * paddybyers_joined
16:01:09  * paddybyersquit (Ping timeout: 245 seconds)
16:01:09  * paddybyers_changed nick to paddybyers
16:06:35  * mmaleckiquit (Ping timeout: 256 seconds)
16:11:02  <indutny>bnoordhuis: hm...
16:11:09  <indutny>bnoordhuis: for some reason https is faster on serving big data
16:11:18  <indutny>by big I mean 100kb pages
16:11:24  <indutny>brb
16:11:24  <indutny>tea
16:16:21  * perezdjoined
16:40:07  * ericktquit (Quit: erickt)
16:44:18  <indutny>bnoordhuis: man
16:44:32  <indutny>bnoordhuis: uv_wait() and async handle?
16:48:21  * TooTallNatejoined
16:50:19  * EhevuTovjoined
16:56:15  * ericktjoined
16:57:19  <txdv_>are there any interesting lxjs talks you can recommend me?
16:57:27  <txdv_>apart from piscisaureus talk
16:57:30  <txdv_>saw that already
16:59:54  <txdv_>indutny: maybe you can recommed me one
17:00:02  <indutny>I'm not sure
17:00:11  <indutny>I wasn't there
17:01:41  * ericktquit (Quit: erickt)
17:07:41  * paddybyersquit (Ping timeout: 246 seconds)
17:09:35  * EhevuTovquit (Quit: This computer has gone to sleep)
17:10:04  * EhevuTovjoined
17:14:54  * stagasquit (Ping timeout: 245 seconds)
17:15:52  * paddybyersjoined
17:16:39  <indutny>while (b == b->next) {}
17:16:48  <indutny>compiles in following thing
17:16:51  <indutny>v1 = b
17:16:53  <indutny>v2 = b->next
17:16:57  <indutny>while (v1 == v2) {}
17:16:59  <indutny>very nice!
17:16:59  <indutny>:)
17:18:38  * stagasjoined
17:22:36  * kazuponquit (Remote host closed the connection)
17:34:01  * paddybyersquit (Ping timeout: 245 seconds)
17:37:54  * paddybyersjoined
17:49:16  <txdv_>i'm not too happy with that process spawn api
17:59:10  * brsonjoined
17:59:33  * ericktjoined
18:07:15  <txdv_>freaking github
18:10:37  * paddybyersquit (Read error: Connection reset by peer)
18:10:43  * paddybyers_joined
18:14:39  * ericktquit (Quit: erickt)
18:14:41  * `3E|DINNERjoined
18:15:05  * `3E|DINNERchanged nick to `3rdEden
18:18:07  * ericktjoined
18:21:35  * ericktquit (Client Quit)
18:25:48  * ericktjoined
18:42:12  * `3rdEdenquit (Quit: switching machines)
18:45:08  <TooTallNate>is there a way to populate a V8::TryCatch manually? ThrowException doesn't seem to be working
18:45:33  <TooTallNate>so i need to call node's FatalException instead, but it only work's with TryCatch
18:47:37  <TooTallNate>ircretary: tell piscisaureus_ node-gyp never sets this BUILDING_NODE_EXTENSION define, is it important?
18:47:38  <ircretary>TooTallNate: I'll be sure to tell piscisaureus_
18:53:10  * kazuponjoined
18:58:08  * kazuponquit (Ping timeout: 240 seconds)
18:58:50  * ericktquit (Quit: erickt)
18:59:19  * paddybyers_quit (Ping timeout: 264 seconds)
19:04:05  * V1joined
19:22:00  * ericktjoined
19:24:50  * kazuponjoined
19:26:03  * ericktquit (Client Quit)
19:28:26  <TooTallNate>grrrr, looks like I need something like: https://gist.github.com/39f29d797c6dd8427ddb
19:28:44  <txdv_>compilation works on my system, doesn't on travis
19:28:49  <txdv_>so annoying
19:30:01  * kazuponquit (Ping timeout: 256 seconds)
19:30:10  <txdv_>how do I compile libuv into a shared library on travis?
19:30:15  <txdv_>mission impossibru
19:37:43  * V1changed nick to `3rdEden
19:57:06  * kazuponjoined
19:57:39  <bnoordhuis>indutny: what about async handles?
19:57:52  <indutny>bnoordhuis: well, I proposed writing handle pointer to pipe
19:58:01  <indutny>instead of iterating through list of handles on each read
19:58:29  <bnoordhuis>indutny: that's an option but it'll fail if the pipe is full
19:58:41  <bnoordhuis>indutny: i've been thinking of using a pipe/socketpair per async handle
19:58:54  <bnoordhuis>but that could potentially use up a lot of fds
19:59:17  <bnoordhuis>on linux, you could use eventfds but that doesn't help other platforms
20:00:04  <bnoordhuis>txdv_: how are you compiling libuv? with gyp or the makefile?
20:03:30  * kazuponquit (Ping timeout: 248 seconds)
20:09:46  <txdv_>apparently the order of the stuff i linked in was important
20:10:52  * `3rdEdenquit (Remote host closed the connection)
20:16:13  <indutny>heh
20:19:00  <indutny>indeed it is
20:20:19  <txdv_>on my system it is not
20:20:21  <txdv_>on that it is
20:24:51  <indutny>bnoordhuis: the question is
20:25:06  <indutny>bnoordhuis: how can one insert new page in a ring from writer
20:25:15  <indutny>bnoordhuis: if reader is continuing running in it
20:25:16  <indutny>:)
20:25:37  <indutny>oh
20:25:41  <indutny>probably that's not really a problem
20:25:52  <indutny>oh no
20:25:53  <indutny>it is
20:26:34  <bnoordhuis>indutny: new page == new linked list entry?
20:26:35  <txdv_>how is the stream refractoring going bnoordhuis ?
20:26:40  <indutny>bnoordhuis: yes
20:26:55  <bnoordhuis>txdv_: refractoring :)
20:26:59  <indutny>it's actually circular buffer
20:27:33  <bnoordhuis>indutny: atomic update of the next pointer should do it
20:27:40  <indutny>bnoordhuis: surely it can
20:27:44  <bnoordhuis>indutny: the reader either sees end-of-list or a new entry
20:27:45  <indutny>can not
20:27:51  * `3rdEdenjoined
20:28:07  <indutny>well the thing is that end of the list is when roffset == woffset == sizeof(page)
20:28:19  <bnoordhuis>indutny: ah, so that's two pointers?
20:28:20  <indutny>and whead and rhead are the same
20:28:25  <indutny>that's not just pointers
20:28:39  <bnoordhuis>okay, two separate variables
20:28:43  <indutny>I've circular buffer with two positions rhead and whead
20:28:53  <bnoordhuis>that's when you start using mutexes
20:28:55  <indutny>each page in a circle contains two offsets roffset and woffset
20:29:12  <indutny>bnoordhuis: wel, that kills whole idea
20:29:29  <indutny>writer writes data in whead and increments woffset
20:29:40  * kazuponjoined
20:29:48  <indutny>when woffset is equal to page size writer move whead to the next page
20:29:54  <indutny>or creates new page if next page is not empty
20:30:12  <indutny>reader reads data in rhead and increments roffset (roffset should be always < woffset)
20:30:25  <indutny>if roffset == sizeof(page) it moves rhead to the next page
20:30:41  <indutny>shit happens when both whead and rhead are moving and new page is being created by writer
20:31:00  <indutny>rhead stucks right after new whead
20:31:02  <bnoordhuis>indutny: yeah, logically. locks will make your life a lot easier
20:31:11  <indutny>bnoordhuis: fine-grained locks?
20:31:23  <indutny>bnoordhuis: like only one lock in one small situation?
20:31:26  <indutny>may be that's not as bad
20:31:29  <bnoordhuis>especially because i doubt that locking vs lockless will make any difference in performance here
20:32:25  <indutny>so I should insert locks in places where I'm moving head
20:32:37  <indutny>this should fix this issue
20:32:37  <indutny>I hope
20:32:45  <indutny>bnoordhuis: may be just spin locks?
20:33:23  <bnoordhuis>indutny: possibly but why bother? profile first, optimize second
20:33:47  <indutny>ok
20:33:51  <indutny>uv_mutex_t ftw
20:35:06  <indutny>oh
20:35:13  <indutny>I need to think about it
20:35:25  <indutny>looks like solving this with mutexes is not that simple anyway
20:35:45  * kazuponquit (Ping timeout: 246 seconds)
20:36:02  * tomshredsquit (Quit: Linkinus - http://linkinus.com)
20:37:14  <indutny>bnoordhuis: so I don't really understand pipe problem
20:37:24  <indutny>we can just loop until pipe buffer will have enough space
20:37:57  <bnoordhuis>indutny: busy-looping is always the wrong solution
20:38:02  <indutny>ah
20:38:05  <indutny>perfectionism
20:38:12  <bnoordhuis>well, it may be a while before the pipe gets drained
20:38:13  <indutny>how dare I to say that
20:38:19  <indutny>yeah, I understand
20:38:24  <indutny>ok
20:39:13  <bnoordhuis>indutny: i'm partial to the pipe/eventfd-per-async-handle solution
20:39:30  <bnoordhuis>if that means people will have to raise their ulimit, so be it
20:39:30  <indutny>bnoordhuis: yeah, that will work too
20:39:58  <indutny>bnoordhuis: I just think that looping over list of lets say few thousands async handles is not effective enough
20:40:13  <indutny>especially when we need to execute only one handle's cb
20:40:16  <bnoordhuis>no, it's not great - but it's no worse than what libev did :)
20:40:27  <indutny>I believe you
20:40:32  <indutny>:)
20:40:36  <bnoordhuis>but i welcome patches
20:41:09  <indutny>sure
20:41:13  <indutny>I'll do it for you
20:41:17  <indutny>once you'll process my previous patch
20:41:46  <txdv_>ok
20:41:47  <txdv_>this is it
20:41:52  <txdv_>how do i build a shared library with gyp?
20:43:09  <indutny>hah
20:43:13  <indutny>bnoordhuis: I fixed that problem
20:43:20  <indutny>bnoordhuis: I was just incrementing one counter ahead of time
20:43:23  <indutny>no locks!
20:45:09  <indutny>bnoordhuis: so I was relying on "total_" variable when writing and reading
20:45:15  <indutny>that's the only atomic stuff I'm doing here
20:45:24  <indutny>and I was incrementing total_ in writer before creating new page
20:46:00  <indutny>interesting thing
20:46:14  <indutny>https is as good at performance as tlsnappy is
20:46:20  <bnoordhuis>txdv_: 'type': 'shared_library'
20:46:36  <indutny>and connect time for tlsnappy is much larger
20:46:38  <indutny>on high load
20:46:46  <indutny>I wonder what this means
20:47:06  <indutny>37ms vs 5ms
20:47:11  <indutny>that's minimal connect time
20:47:14  * kristatequit (Ping timeout: 246 seconds)
20:47:18  <indutny>ah
20:47:24  <indutny>mean time is much better
20:47:49  <indutny>interesting!
20:50:18  <txdv_>this is not an option
20:50:35  <txdv_>yeah ok i see that you can do that
20:50:38  <txdv_>you ccan even pass the type to gyp
20:50:47  <txdv_>what i don't understand is how to use it all
20:52:09  <txdv_>ok it works
20:52:17  <txdv_>i need to somehow specify that type via command line
20:54:41  <bnoordhuis>txdv_: are you using the gyp_uv script?
20:55:25  <txdv_>im running ./gyp_uv and nothing happens
20:56:05  <txdv_>['-f', 'make', '/home/bentkus/Projects/mono/LibuvSharp/libuv/uv.gyp', '-I', '/home/bentkus/Projects/mono/LibuvSharp/libuv/common.gypi', '--depth=.', '-Goutput_dir=/home/bentkus/Projects/mono/LibuvSharp/libuv/out', '--generator-output', '/home/bentkus/Projects/mono/LibuvSharp/libuv/out', '-Dgcc_version=45', '-Dclang=0', '-Dtarget_arch=ia32', '-Dlibrary=static_library', '-Dcomponent=static_library'][5~
20:56:11  <txdv_>well this is being output
20:56:52  <bnoordhuis>txdv_: let me fix that
20:57:11  * hzquit (Read error: Connection reset by peer)
20:57:21  <txdv_>imossible job
20:57:25  <txdv_>to link a simple file on linux
20:57:39  * hzjoined
20:57:41  <txdv_>works on my computer, doesn't work on travis
20:57:51  <txdv_>1 and half hour for nothing
20:59:23  <txdv_>ok
20:59:35  <txdv_>don't bother bnoordhuis
20:59:47  <bnoordhuis>txdv_: no?
21:00:30  <txdv_>it generated some makefiles in out/
21:00:41  <txdv_>so i go in there and type make and it builds it
21:00:50  <txdv_>the thing is that i need to somehow specify via the command line to build a shared library
21:02:10  <bnoordhuis>txdv_: it kind of works but not quite
21:02:17  * kazuponjoined
21:02:32  <bnoordhuis>txdv_: i.e. you can run `./gyp_uv -Dlibrary=shared_library -Dcomponent=shared_library`
21:02:46  <bnoordhuis>but it needs some additional work in uv.gyp to compile successfully
21:03:42  <txdv_>travis gave me a headache
21:03:59  * EhevuTovquit (Quit: This computer has gone to sleep)
21:05:18  <indutny>bnoordhuis: for some reason siege is hanging now
21:05:22  <indutny>on tlsnappy :)
21:05:28  <indutny>so I can't benchmark with it anymore
21:05:38  <indutny>also it's segfaulting if I'm trying to terminate it
21:06:02  <indutny>it seems that it's waiting for some thread to join
21:06:05  <indutny>but that isn't happening
21:06:14  <indutny>"not my fault"
21:06:55  <indutny>ok, trying latest siege
21:07:29  <indutny>wow
21:07:32  <indutny>major improvement
21:07:36  <indutny>3600 vs 3800 req/sec
21:07:42  <indutny>lockless stuff works
21:08:02  <txdv_>hooray
21:08:48  <indutny>yeah
21:08:55  * kazuponquit (Ping timeout: 264 seconds)
21:08:56  <indutny>but may be it's just siege became faster
21:09:02  <indutny>running whole benchmarking suite again
21:09:22  <tjfontaine>not sure you can say lockless stuff works if one bench engine is hanging while trying to run :)
21:09:24  * indutnyis crossing fingers
21:09:35  <indutny>tjfontaine: it was hanging even without it
21:09:41  <indutny>tjfontaine: it has started hanging some time ago
21:09:50  <indutny>and it's not really my fault
21:10:00  <indutny>since siege is just doing pthread_join
21:10:06  <indutny>on thread that's waiting on a semaphore
21:10:13  <indutny>definitely a bug
21:10:46  <tjfontaine>I'm just harassing you
21:11:16  * AvianFluquit (Remote host closed the connection)
21:11:42  <indutny>ooh
21:11:48  <indutny>nginx is much faster with newer siege
21:11:50  <indutny>5300 req/sec
21:11:58  <indutny>that's what I was afraid of :)
21:12:05  <indutny>ok, lets wait for final results
21:14:09  * `3rdEdenquit (Remote host closed the connection)
21:15:00  <txdv_>lol
21:15:13  <txdv_>my app became faster! O no with the new siege nginx became faster too
21:15:46  <indutny>indeed
21:15:59  <indutny>bnoordhuis: you know why I need lockless structure here?
21:16:22  <indutny>bnoordhuis: because I'm doing BIO_read and SSL_read at the same time from different threads
21:16:33  <indutny>w/o locks
21:19:24  <indutny>bnoordhuis: still I don't understand why 16 threaded process works worse than 16 processes
21:19:27  <indutny>:)
21:20:06  * EhevuTovjoined
21:20:11  <bnoordhuis>indutny: what's the thread scheduling policy on your machine?
21:20:18  <indutny>bnoordhuis: how to check it?
21:20:27  <indutny>(I'm on ubuntu)
21:21:22  <indutny>I've one theory, but I don't really like it
21:21:23  <bnoordhuis>indutny: oh, no worries then - it's always PTHREAD_SCOPE_SYSTEM
21:21:39  <indutny>event loop is interrupting too much
21:21:43  <indutny>and becomes busy
21:22:05  <bnoordhuis>indutny: profile! :)
21:22:16  <indutny>bnoordhuis: you think it is that easy?! :)
21:22:49  <indutny>fixing multithreaded lock-less circular buffer structure is much easier than getting good profile
21:22:59  <indutny>bnoordhuis: have you tried running it?
21:23:16  * rendarquit
21:23:17  <bnoordhuis>it's true that meaningful profiling is something of a black art
21:23:29  <bnoordhuis>or maybe not black but arcane
21:23:57  <indutny>sentinels of light and dark
21:24:07  <indutny>came together to create good benchmarking and profiling utility
21:24:20  <indutny>but only developers were born in that process
21:24:28  <indutny>and sentinels said:
21:24:44  <indutny>"ok, fuck it! we can let them figure out this crap themselves"
21:24:52  <indutny>period
21:25:07  <indutny>bnoordhuis: am I good at writing?
21:25:27  <bnoordhuis>indutny: it's very profound
21:28:26  <txdv_>so no autotools?
21:29:12  <ryah>only fools profile
21:29:26  <ryah>oh wait.. or was it "only fools don't profile"?
21:29:27  <ryah>hm
21:29:43  <txdv_>fools profile
21:29:45  <indutny>quantum profiling
21:29:53  <indutny>it's either foolish or not
21:30:01  <indutny>until you do it
21:30:02  <txdv_>real men write perfect code the first time
21:30:55  <ryah>you know how there is this whole chuck norris meme?
21:31:08  <txdv_>who doesn't
21:31:18  <ryah>we should start a similiar meme about DJB
21:31:25  <txdv_>djb?
21:31:26  <ryah>but with programming instead of beating up people
21:31:47  <ryah>txdv_: http://en.wikipedia.org/wiki/Daniel_J._Bernstein
21:31:59  <txdv_>german surname
21:32:44  <indutny>oh
21:32:49  <indutny>siege has hanged once again
21:32:52  <ryah>Bernstein has recently[when?] explained that he is pursuing a strategy to "produce invulnerable computer systems".
21:33:03  <ryah>He concludes: "I won’t be satisfied until I've put the entire security industry out of work."[
21:33:48  * brsonquit (Quit: leaving)
21:34:51  <ryah>hmm
21:34:53  * kazuponjoined
21:35:43  <indutny>have you seen Mithgol on github
21:35:53  <indutny>he's pretty active at commenting windows cmd issues
21:36:30  <txdv_>some people specialize in compiler techniques
21:36:33  <indutny>so this guy has invented Hypertext Vector Fidonet
21:36:44  <txdv_>some people specialize in data encryption
21:36:57  <txdv_>but some people love to troll about cmd line issues
21:37:09  <ryah>mithgol sounds familiar
21:37:09  <indutny>he's not trolling
21:37:30  <ryah>great avatar
21:37:46  <indutny>http://www.google.ru/imgres?hl=en&newwindow=1&sa=X&biw=1440&bih=751&tbm=isch&prmd=imvns&tbnid=HQQ-l-SD1jkQKM:&imgrefurl=http://lurkmore.to/%25D0%259C%25D0%25B8%25D1%2586%25D0%25B3%25D0%25BE%25D0%25BB&docid=Qg4gjT3MSB8WUM&imgurl=http://lurkmore.so/images/thumb/f/fb/Mithgol_the_Webmaster_31Mar2007.jpg/180px-Mithgol_the_Webmaster_31Mar2007.jpg&w=180&h=196&ei=1VJvUPL-Cs334QTzyoDABw&zoom=1&iact=hc&vpx=
21:37:46  <indutny>517&vpy=165&dur=3664&hovh=156&hovw=144&tx=97&ty=63&sig=117084939212369259451&page=1&tbnh=128&tbnw=126&start=0&ndsp=33&ved=1t:429,r:2,s:0,i:76
21:37:50  <indutny>oops
21:37:59  <indutny>http://lurkmore.to/%D0%9C%D0%B8%D1%86%D0%B3%D0%BE%D0%BB
21:38:04  <indutny>that should be better %
21:38:49  * sgallagh_afkjoined
21:39:19  <sgallagh_afk>bnoordhuis: Hi, just wanted to ask a couple questions about what you meant when you said you were ripping out libev.
21:39:23  * sgallagh_afkchanged nick to sgallagh
21:39:56  <bnoordhuis>sgallagh: hey
21:39:57  <sgallagh>And I also thought I might suggest switching to libverto if the opportunity is there
21:40:20  <bnoordhuis>sgallagh: i'm removing libev as a dependency of uv-unix
21:40:35  <sgallagh>(Which is basically a common interface supporting libev, libtevent, libloop, etc.)
21:40:57  <sgallagh>Removing it from being needed at all, or replacing it?
21:41:06  <bnoordhuis>sgallagh: the former
21:41:08  * kazuponquit (Ping timeout: 246 seconds)
21:41:17  <bnoordhuis>it's only used now to drive the inner event loop, libuv takes care of everything else
21:41:20  <sgallagh>Oh, interesting. So there's no need for an async event loop now?
21:41:23  <ryah>bnoordhuis: first libev then libc, right?
21:41:28  <bnoordhuis>ryah: yes :)
21:41:29  <sgallagh>heh
21:41:31  <ryah>good :)
21:41:57  <sgallagh>bnoordhuis: Well, I'll admit that makes my life as a packager somewhat easier :)
21:42:21  <txdv_>libuvOS please
21:42:22  <ryah>oh god did the libuv package dynamically link to libev? sigh
21:42:35  <sgallagh>ryah: No, it statically linked it
21:42:37  <bnoordhuis>sgallagh: i like making other people's lifes easier provided it doesn't make my life harder
21:43:05  <bnoordhuis>err, lives
21:43:37  <sgallagh>bnoordhuis: Well, I recently got handed the live grenade that is "make Node.JS packagable in Fedora" and Step One was "break libuv's static link to libev".
21:44:05  <bnoordhuis>sgallagh: your life already got a little easier. as of this week we no longer use libeio
21:44:07  <indutny>1щл
21:44:08  <indutny>ok
21:44:10  <indutny>time to sleep
21:44:10  <indutny>ttyl
21:44:14  <bnoordhuis>sleep tight, fedor
21:44:20  <txdv_>so bnoordhuis decided that the right step 1 is to rip libev out
21:44:28  * TheJHquit (Ping timeout: 260 seconds)
21:44:30  * `3rdEdenjoined
21:44:45  <sgallagh>txdv_: Works for me :)
21:44:58  <indutny>bnoordhuis: uv_wait uv_wait
21:45:00  <indutny>please
21:45:06  * ryahholds his desparaging comments about linux distributions and how they've killed unix
21:45:14  <bnoordhuis>indutny: hah okay, i'll try to review it tonight
21:45:18  <indutny>thanks
21:45:23  <sgallagh>ryah: Stagnation killed unix.
21:45:25  * indutnysigns off
21:45:29  <ryah>no
21:45:34  <txdv_>i'm on linux
21:45:35  <txdv_>it is alive
21:45:37  <ryah>the opposite
21:45:51  * bnoordhuisretreats to vim
21:46:19  <sgallagh>Full disclosure: I'm a Red Hat employee. So you may assume biased answers and we can skip the debate :)
21:46:24  <txdv_>unix is dead says the dude who has a macbook
21:48:08  * sgallaghquit (Read error: Connection reset by peer)
21:48:36  <ryah>i DoSed him
21:48:40  * sgallaghjoined
21:48:47  <ryah>(jk hehe)
21:49:09  <bnoordhuis>sgallagh: is there a timeline on packaging/inclusion of node.js?
21:49:40  <bnoordhuis>i ask because we've discussed distributing rpms
21:53:05  * `3rdEdenquit (Ping timeout: 260 seconds)
21:55:39  <sgallagh>bnoordhuis: As soon as we can get it into shape.
21:55:57  <sgallagh>bnoordhuis: Basically, it's become more and more apparent that if we aren't shipping node.js in Fedora, we're ceasing to be relevant
21:56:20  <sgallagh>Fedora is predominately a developer community, and developers want node.js
21:56:24  <bnoordhuis>music to my ears
21:56:53  <bnoordhuis>so what can we do to help? i don't really want to float autotools patches for libev and libeio
21:57:10  <sgallagh>ryah: My wireless bounced, so I have no idea what you were saying "(jk hehe)" too. Maybe best that way ;-)
21:57:12  <bnoordhuis>i mean, they'd only be relevant for the 0.8 branch
21:57:55  <sgallagh>bnoordhuis: Well, from Fedora's perspective, since libuv has a separate upstream repository, it's generally considered to be a separate, packageable project.
21:58:13  <sgallagh>So the package reviewers are telling me it needs to be a shared library and not built statically in node.js
21:58:38  <sgallagh>Although I think with the removal of libeio and libev, I may be able to get them to waive that rule if it's the only bundled piece
21:59:13  <sgallagh>bnoordhuis: I've only just started looking into this today, so right now I'm mostly going from the records of my predecessors who ran out of time or motivation to take this on
21:59:31  <bnoordhuis>sgallagh: okay, but that only applies to master. the v0.8 branch will keep shipping libev/eio until its EOL
21:59:53  <bnoordhuis>which is getting nearer but that aside
22:00:09  <sgallagh>I'm willing to start from master and worry about 0.8 later if it's necessary.
22:00:23  <sgallagh>I'd rather Fedora be seen as the place with the latest and greatest, ideally :)
22:00:27  <bnoordhuis>okay, good :)
22:01:23  <sgallagh>bnoordhuis: Are there plans to make libuv a shared lib, or will node.js 0.9 still be statically linking it?
22:01:23  * ericktjoined
22:01:51  <bnoordhuis>sgallagh: i can add build infrastructure to make libuv a .so
22:02:06  <bnoordhuis>but upstream will always be shipping it in-tree and as a static dep
22:02:34  <sgallagh>bnoordhuis: Understood, but I can absorb the work there of patching their build to consume the shared lib.
22:03:02  <sgallagh>Patching in Fedora, not upstream
22:03:08  <bnoordhuis>sgallagh: right
22:03:14  <sgallagh>(Assuming they won't accept a patch to conditionalize it, of course)
22:03:28  <bnoordhuis>sgallagh: they == upstream node.js? because that's us :)
22:03:46  <sgallagh>Sorry, wasn't sure how much overlap there was in here
22:03:55  <sgallagh>That was actually going to be my next question
22:04:44  <txdv_>add the sared infra
22:04:56  <bnoordhuis>sgallagh: i can land some patches in libuv and node to a) build libuv as a .so, and b) make node link to that
22:05:14  <bnoordhuis>sgallagh: the other deps (v8, openssl, zlib, c-ares) already have support for that so why not libuv?
22:05:31  <sgallagh>You're jumping ahead in my script. I was just about to ask about those four :-D
22:06:03  <sgallagh>I still wanted to ask if you know the status of npm and http_parser bundling
22:06:23  <bnoordhuis>sgallagh: you should ask isaacs about npm
22:06:24  <sgallagh>My notes here say "npm can be removed and use an external tarball", so that's probably already solved
22:06:47  <bnoordhuis>but yes, it should be easy to ship it as a separate package
22:06:51  <sgallagh>http_parser already has a Fedora package, but I don't know if the bundled version has any node-specific changes.
22:07:19  <txdv_>http-parser available as a shared lib?
22:07:23  <bnoordhuis>sgallagh: the version that node bundles is pristine but it may be a lot newer
22:07:24  <sgallagh>Yes
22:07:33  * kazuponjoined
22:07:33  <bnoordhuis>txdv_: yeah, you can build it as a .so
22:07:34  <txdv_>how freaking freaking is that
22:07:43  <sgallagh>bnoordhuis: Fedora traditionally carries the latest of all packages
22:07:49  <txdv_>it has no deps whatsoever, ofc you can build it as an so
22:07:51  <sgallagh>So no one will complain if I upgrade it
22:08:02  <bnoordhuis>okay, cool
22:08:24  <txdv_>but it is so small i thought everybody would link it statically in
22:08:37  <bnoordhuis>txdv_: and so it was until a few months ago
22:08:42  <sgallagh>txdv_: It's not a matter of size, it's supportability
22:08:59  <sgallagh>If http_parser has a security vulnerability, it's a lot easier to patch just the .so than every package statically linking it
22:09:20  <txdv_>i guess ill have to resurect my c# wrapper of it
22:09:54  <txdv_>because no available so's are an issue
22:10:16  <bnoordhuis>txdv_: the dynamic version is a lot slower on i386 though
22:10:36  <txdv_>pfff
22:10:41  <txdv_>does it have to be i386?
22:10:45  * joshthecoderjoined
22:10:49  <sgallagh>bnoordhuis: Ok, so if node can be made to conditionally link against the http_parser shared lib, I think we've covered all the hurdles I'm aware of.
22:11:17  <sgallagh>bnoordhuis: i386 or i*86, just out of curiousity?
22:11:37  <txdv_>someone is wrong on the internet
22:11:40  <txdv_>or might be wrong
22:11:56  <bnoordhuis>sgallagh: mostly i386. http_parser is quite branch heavy, which hurts on i386 but x86_64 uses rip-relative addressing
22:12:10  <sgallagh>bnoordhuis: Sorry, I meant i386 vs i686
22:12:27  <sgallagh>But I think you've answered my question
22:13:28  <bnoordhuis>sgallagh: i benchmarked a ~10% drop in performance with the pic i386/i686 version iirc
22:13:40  <sgallagh>oof, good to know
22:13:48  * kazuponquit (Ping timeout: 255 seconds)
22:13:56  <bnoordhuis>the x86_64 version was hardly affected though
22:15:01  <sgallagh>bnoordhuis: Ok, I have to run for today. But I think if we can overcome these hurdles, we should be able to get this into Fedora 18.
22:15:18  <sgallagh>Thank you very much for answering my questions
22:15:33  <bnoordhuis>sgallagh: my pleasure. send in patches :)
22:16:09  * EhevuTovquit (Quit: This computer has gone to sleep)
22:16:22  <sgallagh>bnoordhuis: I'll take a look at the node.js code and see if I can link the http_parser similar to c-ares
22:16:33  <sgallagh>You will be hearing from me soon :)
22:16:54  * sgallaghquit (Remote host closed the connection)
22:18:10  <txdv_>i fucking hate travis
22:21:15  * ericktquit (Ping timeout: 240 seconds)
22:29:08  * paddybyersjoined
22:32:40  <txdv_>write2 and read2 - we have to use these both if IPC = 1?
22:32:45  <txdv_>or can i use write and read as well?
22:33:46  <bnoordhuis>txdv_: you can use both
22:33:56  <bnoordhuis>unless you want to send over handles, of course
22:34:24  <bnoordhuis>s/both/all four/
22:35:15  <txdv_>if i just send data and i have read2, the callback will receive UV_UKNOWN as the handletype?
22:35:59  <bnoordhuis>txdv_: yes
22:37:34  <txdv_>so I can create a seperate class for ipc pipes
22:37:57  <txdv_>if i do write2 with stream = NULL and data != null, will it send the data?
22:40:06  * kazuponjoined
22:40:46  * joshthecoderquit (Quit: Linkinus - http://linkinus.com)
22:42:19  <txdv_>why not just create uv_write_stream which just takes a handle and no data
22:46:40  * kazuponquit (Ping timeout: 256 seconds)
22:53:45  * paddybyersquit (Ping timeout: 260 seconds)
23:09:02  <txdv_>i copied it now
23:09:08  * EhevuTovjoined
23:09:09  <txdv_>if it wouldn't exist, cp would fail
23:09:11  <txdv_>but it didn't
23:09:15  <txdv_>it still can't find it
23:09:19  <bnoordhuis>txdv_: because on unices you always need to send at least one byte of data
23:09:34  <txdv_>last 3 lines wrong chan
23:09:59  <txdv_>bnoordhuis: that sucks
23:10:10  <bnoordhuis>lots of things do
23:13:02  * kazuponjoined
23:15:07  <txdv_>so you made a write2 instead of send_handle because you would need to do a a write with at least 1 byte afterwards>?
23:17:29  * perezdquit (Quit: perezd)
23:18:57  * perezdjoined
23:19:20  * kazuponquit (Ping timeout: 256 seconds)
23:19:29  <bnoordhuis>txdv_: yes
23:20:11  <txdv_>i hope linux doesnt have this limitation
23:21:35  <txdv_>can i do a uv_write2 with data == null and then a uv_write with data != null
23:39:08  * stagasquit (Ping timeout: 240 seconds)
23:43:27  * c4miloquit (Remote host closed the connection)
23:45:56  * kazuponjoined
23:48:52  <bnoordhuis>txdv_: no
23:49:08  <bnoordhuis>and yes, linux has the same limitation
23:50:49  <TooTallNate>bnoordhuis: review? https://github.com/TooTallNate/node/commit/f826b3269d62cd64439d68a145eeeb658973740c
23:52:14  * kazuponquit (Ping timeout: 246 seconds)
23:53:09  <bnoordhuis>TooTallNate: lgtm
23:53:18  <txdv_>bnoordhuis: can i use do a uv_write2 with handle != null && data == null and then a uv_write with handle == null && data != null?
23:53:21  <TooTallNate>bnoordhuis: thanks
23:53:24  <txdv_>bnoordhuis: can i use do a uv_write2 with handle != null && data == null and then a uv_write2 with handle == null && data != null?
23:53:44  <MI6>joyent/node: Nathan Rajlich v0.8 * f826b32 : doc: document the custom "inspect()" function behavior Closes #3361. - http://git.io/LHy6pw
23:53:47  <txdv_>two times calling write2
23:53:49  <bnoordhuis>txdv_: no. `man sendmsg` if you want to know why that is :)
23:54:30  <bnoordhuis>the tl;dr is if you want to send a handle, you need to send some data along with it
23:54:39  <txdv_>in the same write2 call?
23:56:04  <txdv_>bnoordhuis: how is the uv_file_t comming along?
23:56:30  <bnoordhuis>txdv_: yes, same write2 call
23:58:00  <txdv_>bnoordhuis: thanks