00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:15:17  * wolfeidauquit (Read error: Connection reset by peer)
00:25:11  * bradleymeckquit (Quit: bradleymeck)
00:25:46  * Raltquit (Remote host closed the connection)
00:29:56  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
00:30:55  * piscisaureus_joined
00:31:09  <piscisaureus_>going to bed
00:31:12  <piscisaureus_>goodbye peepz
00:31:51  <piscisaureus_>bnoordhuis: you should too :-)
00:31:54  * piscisaureus_quit (Client Quit)
00:47:27  * ericktjoined
01:03:15  * ericktquit (Quit: erickt)
01:11:52  * pooyaquit (Quit: pooya)
01:20:27  * indexzerojoined
01:21:04  * Chip_Zeroquit (Ping timeout: 244 seconds)
01:22:20  * Chip_Zerojoined
01:30:08  * sblomquit (Ping timeout: 245 seconds)
01:30:31  <indutny>bnoordhuis: not sleeping?
01:33:49  * Benviequit
01:39:25  * hzquit
01:41:22  * Benviejoined
01:43:53  * bradleymeckjoined
01:44:58  <isaacs>g'nite piscisaureus
01:45:01  <isaacs>and bnoordhuis
01:45:10  <isaacs>and indutny and sblom and isaacs
01:45:13  <isaacs>good night node
01:45:16  <indutny>g'nite
01:46:02  <MI6>joyent/node: Ryunosuke SATO master * 697484d : domain: speed up domain.create Use `EventEmitter.call` instead of `Event - http://git.io/8L5UQw
01:46:57  <MI6>joyent/node: Ryunosuke SATO master * fde338b : stream: speed up instantiation of readable stream - Stream.apply -> Stre - http://git.io/Q0lRXw
01:59:34  * wolfeidaujoined
02:22:04  <MI6>joyent/node: bentaber master * e576208 : net: socket.readyState corrections socket.readyState, .readable, and .wr - http://git.io/emrW4A
02:34:44  * piscisaureus_joined
02:34:53  * piscisaureus_quit (Client Quit)
02:40:12  <MI6>joyent/node: Luke Arduini master * 192192a : Colorize API stabilitity index headers in docs Noted in @shtylman's #389 - http://git.io/7wmCkw
03:13:21  * ericktjoined
03:14:56  * indexzeroquit (Quit: indexzero)
03:24:55  * indexzerojoined
03:34:27  * ericktquit (Quit: erickt)
04:16:49  * qmx|awaychanged nick to qmx
04:17:16  * indexzeroquit (Quit: indexzero)
04:37:06  * bradleymeckquit (Quit: bradleymeck)
04:46:16  * mjr_joined
04:55:11  * bradleymeckjoined
05:25:06  * mjr_quit (Quit: mjr_)
05:25:35  * mjr_joined
05:41:24  * indexzerojoined
05:41:34  * indexzeroquit (Client Quit)
05:41:57  * indexzerojoined
05:55:50  * wolfeidauquit (Remote host closed the connection)
06:07:01  * qmxchanged nick to qmx|away
06:10:41  * mjr_quit (Quit: mjr_)
06:10:47  * AvianFluquit (Remote host closed the connection)
06:51:27  * mmaleckichanged nick to mmalecki[zzz]
06:51:44  * mmalecki[zzz]changed nick to mmalecki
07:23:33  * mmaleckichanged nick to mmalecki[zzz]
07:23:37  * stagasjoined
07:24:36  * rendarjoined
07:27:51  * loladirojoined
08:13:30  * mikealquit (Quit: Leaving.)
08:18:51  * mikealjoined
08:19:27  * `3rdEdenjoined
08:38:40  * mikealquit (Read error: Connection reset by peer)
08:39:23  * mikealjoined
08:49:27  * indexzeroquit (Quit: indexzero)
08:50:18  * pooyajoined
09:31:15  * hzjoined
10:33:19  * TheJHjoined
10:45:28  * joshthecoderquit (Quit: Linkinus - http://linkinus.com)
11:04:52  * benoitcquit (Excess Flood)
11:05:35  * benoitcjoined
11:24:52  * wolfeidaujoined
11:33:39  * benoitcquit (Excess Flood)
11:36:35  * benoitcjoined
11:38:40  * benoitcquit (Excess Flood)
11:39:04  * benoitcjoined
11:48:11  <MI6>joyent/libuv: Ben Noordhuis master * 69ab328 : sunos: fix !defined(PORT_SOURCE_FILE) build - http://git.io/ekE1hA
11:49:57  * travis-cijoined
11:49:57  <travis-ci>[travis-ci] joyent/libuv#983 (master - 69ab328 : Ben Noordhuis): The build passed.
11:49:57  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/3164f1ea6927...69ab328d9f38
11:49:57  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/3854189
11:49:57  * travis-cipart
11:54:30  * bentkusjoined
11:54:36  <bentkus>hello
11:54:47  <bentkus>bnoordhuis: how are you doing?
11:59:10  * benoitcquit (Excess Flood)
12:04:05  * `3rdEdenquit (Remote host closed the connection)
12:04:46  <bentkus>privet indutny
12:07:05  * benoitcjoined
12:14:14  <bentkus>nice monologue
12:20:22  <indutny>heya
12:20:55  <MI6>joyent/node: Ben Noordhuis master * a329729 : buffer: speed up base64 encoding by 20% Remove a lot of branches from th - http://git.io/owwLxw
12:21:26  <bnoordhuis>bentkus: in general or pertaining to libuv/node?
12:23:00  <bentkus>first general, since it is christmass, then libuv xD
12:23:58  <rendar>if i'd wrap libuv in an object oriented fashion, say for instance i'll have a File class, should all the operations be syncronous or asynchronous based on some flag that i give to the object contructor, or would using both sync/async operations toghether make sense in some cases?
12:24:10  <bnoordhuis>bentkus: ora et labora but, sadly, mostly labora. re libuv: applying micro-optimizations
12:24:51  <bnoordhuis>rendar: it's your api, you're best qualified to answer that
12:25:14  <bentkus>rendar: does your language have a base class library with all blocking standard operations?
12:25:33  <bentkus>I didn't even expose the threading stuff in C# because it is in the BCL
12:25:38  <rendar>bentkus: the language is C++
12:25:54  <indutny>bnoordhuis: hello ben
12:25:59  <bnoordhuis>indutny: sup fedor
12:26:06  <indutny>bnoordhuis: just saying
12:26:14  <rendar>bnoordhuis: well, i know, but usually when one want async i/o want _only_ async, or there are cases in which they want both?
12:26:56  <bentkus>I guess std:: has all the blocking stuff
12:27:13  <rendar>bentkus: yeah
12:27:23  <bentkus>rendar: I give you the most obvious case when people want sync in async
12:27:37  <bentkus>there is no async library to solve a particular problem
12:27:54  <bentkus>and you don't want to write an entire library
12:28:25  <bentkus>but as I already said, in your case, std provides all the functionality you need
12:29:52  <rendar>the most obvious case that come to my mind is that when someone open a file, in the on_open callback doesn't want an async function to get the file size, but a sync one
12:31:41  <bnoordhuis>rendar: mixing sync and async in that fashion is usually a recipe for tears
12:32:09  <indutny>ben's tears
12:32:50  <indutny>bnoordhuis: btw, has bert done something about running uv's loop inside uv's loop?
12:33:09  <dscape>indutny: just voxered you :P
12:33:15  <indutny>dscape: ahahaha
12:33:41  <bnoordhuis>indutny: um... is that a 'i heard you like x so we put a x in your x so you can x while you x' joke?
12:33:45  <dscape>its taking a long time cause engineers over there are not good at HTTPS :P
12:33:58  <indutny>dscape: no, I just turned off wifi
12:34:01  <indutny>dscape: :)
12:34:06  <dscape>yeah right ^^
12:34:09  <bentkus>C++ is a recipe for tears
12:34:37  <bentkus>I think that if someone uses libuv from c++, then he will be sophisticated enough to know when to do a sync call or not
12:35:19  <bentkus>just put this in your docs: if you do sync in an async callback, you block the loop, spin up a thread and do your sync call
12:36:25  <bentkus>indutny: what is the benefit of running a uv loop inside of a uv loop?
12:36:36  <indutny>bentkus: you can run some actions synchronously
12:36:44  <indutny>bentkus: like spawn new loop inside you current one
12:36:49  <indutny>enqueue some async action
12:36:54  <indutny>and wait for it to complete
12:37:03  <indutny>synchronously
12:37:29  <bentkus>You can do that with threads + uv_async
12:37:45  <indutny>well...
12:37:47  <indutny>sure you can
12:37:53  <indutny>but it would be slower
12:37:55  <indutny>and more complex
12:38:09  <indutny>I think pisci did some work on it
12:38:20  <bentkus>why would it be slower
12:38:46  <indutny>because bouncing between threads isn't fast? :)
12:38:54  <indutny>you need synchronization
12:38:59  <indutny>writing to async handle
12:39:01  <indutny>and all the stuff
12:40:28  <bentkus>is writing to an async handle slow?
12:42:09  <bnoordhuis>bentkus: not really unless you have lots of threads writing to lots of async handles
12:42:31  <bentkus>I have one async per loop for syncronization stuff
12:42:47  <bnoordhuis>you can check for yourself, there's a couple of benchmarks that stress-test that
12:42:47  <bentkus>in uv#
12:42:58  <bentkus>I don't know why someone would need more than one async handle
12:44:39  <bentkus>it is like my pause/resume proposal for writing
12:44:57  <bentkus>Yeah, you can do it, but what is the benefit of having more than one async handle per loop?
12:46:05  * pooyaquit (Quit: pooya)
12:46:18  <bnoordhuis>bentkus: many-to-many communication between event loops?
12:47:00  <bnoordhuis>131 github emails to go...
12:47:05  <bentkus>what do you mean by many to many commcunications
12:47:30  <bnoordhuis>bentkus: say you have M event loops and each event loop talks to every other event loop
12:47:47  <bentkus>In that case only one async handle per event loop is needed
12:48:05  <bentkus>My question was: why > 1 async handle per loop
12:48:11  <bentkus>not why > 1 async handle at all
12:48:39  <bnoordhuis>to avoid contention. M threads all writing to the same async handle might be sub-optimal
12:48:49  <bnoordhuis>though of course you'd have to benchmark it to be sure
12:50:03  <indutny>dscape: have you received reply?
12:50:24  <indutny>:)
12:50:31  <bentkus>is it possible to stop an async write on windows?
12:50:39  <bentkus>i'm talking about the iocp write
12:50:51  <bnoordhuis>ircretary: tell piscisaureus can you review https://github.com/joyent/libuv/pull/665 ? it lgtm but what do i know
12:50:51  <ircretary>bnoordhuis: I'll be sure to tell piscisaureus
12:51:14  <bnoordhuis>bentkus: no. uv_cancel() is only implemented on unix at the moment and only for certain request types
12:51:20  <indutny>ircretary: tell isaacs that my v8 patch has been LGTMed and will be landed in v8's trunk soon https://chromiumcodereview.appspot.com/11676005/
12:51:21  <ircretary>indutny: I'll be sure to tell isaacs
12:51:45  <bnoordhuis>bentkus: cancelling uv_write is the easiest thing to do on unix btw but i didn't want the feature gap to grow too large :)
12:52:21  <bentkus>yeah i know it from ev
12:52:44  <bentkus>I was just wondering if iocp write could be canceled, then it would be possible to implement my useless write pausing
12:53:00  <bnoordhuis>i discussed it with bertje a while ago
12:53:11  <bnoordhuis>i think the conclusion was "it's complicated"
12:53:59  <bentkus>did you discuss in what particular situation this would be beneficial?
12:54:29  <bnoordhuis>not sure what you mean but we discussed it in the context of uv_cancel()
12:54:41  <bentkus>o ok
12:55:19  <bentkus>Who is using uv_cancel?
12:55:41  <bnoordhuis>ryan apparently, he was quite pleased with it :)
12:55:49  <bentkus>what did he do with it?
12:56:04  <bnoordhuis>don't know but he was thrilled enough to comment on the commit
12:56:12  <bnoordhuis>it was some other guy that requested it
12:56:28  <bentkus>currently uv_req is hidden in my binding
12:56:40  <bentkus>exposing uv_cancel would force me to expose that class
12:57:05  <bnoordhuis>do what i do
12:57:10  <bnoordhuis>i.e. nothing until someone asks for it
12:57:37  <bentkus>My wrapper is currently being followed by 12 people
12:57:48  <bentkus>this is never going to happen
13:01:12  * bentkusquit (Read error: No route to host)
13:01:55  * benoitcquit (Excess Flood)
13:06:13  <bnoordhuis>why is that Integer::Value() returns a int64_t but Integer::New() only takes a int32_t?
13:06:20  <bnoordhuis>*why is it
13:06:36  <bnoordhuis>oh well
13:06:49  <txdv>in v8?
13:06:51  <indutny>hahaha
13:07:09  <indutny>bnoordhuis: you know what
13:07:19  <indutny>bnoordhuis: because 1e11 might be converted to int64_t
13:07:37  <indutny>and I think Integer::New(double val) is a bad idea
13:07:42  <indutny>it will confuse people
13:08:02  <indutny>anyone: how to make iphone display notifications only about important google mail
13:08:05  <indutny>not about every incoming
13:09:08  <bnoordhuis>indutny: what would be so bad about converting 1e11? it fits easily in 63 bits
13:09:13  <txdv>create filters for not important mails filtering them out of inbox
13:09:15  <indutny>yes
13:09:24  <indutny>bnoordhuis: but it's lossy conversion
13:09:26  <indutny>well
13:09:29  <indutny>I mean
13:09:31  <indutny>double is lossy
13:09:38  <bnoordhuis>sure
13:09:50  <indutny>anyway
13:09:50  <bnoordhuis>but i'd expect Integer::New(int64_t)
13:09:59  <indutny>but it won't work that way
13:10:04  <indutny>btw
13:10:08  <indutny>you can do this in Candor
13:10:09  <indutny>:)
13:10:23  <bnoordhuis>you mean because it returns a heap-allocated double?
13:10:37  * benoitcjoined
13:10:52  <indutny>bnoordhuis: yes
13:11:01  <indutny>bnoordhuis: so conversion is lossy
13:11:03  <bnoordhuis>okay, i see the logic in that
13:11:12  <bnoordhuis>but why then does Integer::Value() return an int64_t?
13:11:34  <bnoordhuis>i guess it's because the other constructor takes a uint32_t
13:11:44  <bnoordhuis>NewFromUnsigned() i mean
13:11:57  <indutny>I don't see logic here
13:12:05  <indutny>:)
13:12:22  <indutny>I think idea behind this signature is that double values might be actually integers
13:12:30  <indutny>just long integers, i.e. 64bit
13:12:33  <bnoordhuis>if Integer::Value() returned a int32_t you couldn't have NewFromUnsigned(uint32_t)
13:12:42  <indutny>ah
13:12:45  <indutny>hm...
13:12:49  <indutny>idk
13:19:50  <indutny>bnoordhuis: I think vms are complicated shit
13:19:56  <indutny>bnoordhuis: noone really understands them
13:20:06  <indutny>but everyone loves scripting
13:20:20  <bnoordhuis>indutny: i heard lars bak knows a thing or two about 'em
13:20:53  <indutny>two
13:20:58  <indutny>that's what I heard
13:21:06  <indutny>he knows how to design them
13:21:11  <indutny>and how to optimize them
13:34:34  <txdv>but that language of hius
13:34:35  <txdv>sucks
13:41:18  <indutny>hius?
13:41:46  <indutny>you meant french word?
13:45:46  * felixgequit (Quit: http://www.debuggable.com/)
14:08:36  <txdv>his language
14:08:42  <txdv>like that new google language for the browser
14:08:45  <txdv>what was it called
14:08:47  <txdv>dork or something
14:14:19  <indutny>ah, dart
14:14:37  <indutny>well, while I'm pretty conservative
14:14:48  <indutny>I'm starting to think that it might be a good idea
14:14:55  <indutny>considering how they are going to apply it
14:15:40  * ericktjoined
14:27:41  * c4milojoined
14:31:13  * c4milo_joined
14:31:48  * c4miloquit (Ping timeout: 248 seconds)
14:36:16  <txdv>indutny: what about dart is good?
14:36:26  <txdv>except like the obvious stuff that it is a faster language
14:36:27  <indutny>weak type inference
14:36:30  <txdv>vm
14:39:05  <txdv>so basically the var keyword
14:40:01  <txdv>?
14:40:05  <txdv>AM I RIGHT?
14:40:31  <txdv>this bot is a genius
14:40:34  <txdv>who has coded it
14:41:03  * AvianFlujoined
14:45:39  * Raltjoined
14:46:03  * ericktquit (Quit: erickt)
14:53:51  * ericktjoined
14:56:38  * ericktquit (Client Quit)
15:02:35  <MI6>joyent/libuv: Saúl Ibarra Corretgé master * 9614d51 : unix: reset errno when using sendfile emulation A common way to check if - http://git.io/QWUStQ
15:02:55  * ericktjoined
15:04:22  * travis-cijoined
15:04:23  <travis-ci>[travis-ci] joyent/libuv#984 (master - 9614d51 : Saúl Ibarra Corretgé): The build passed.
15:04:23  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/69ab328d9f38...9614d5113526
15:04:23  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/3856474
15:04:23  * travis-cipart
15:08:10  <bnoordhuis>ircretary: tell piscisaureus let's discuss https://github.com/joyent/libuv/issues/635 some time
15:08:11  <ircretary>bnoordhuis: I'll be sure to tell piscisaureus
15:08:16  <bnoordhuis>ircretary: you're a doll
15:08:16  <ircretary>bnoordhuis: I'm not sure what to do with that command. Ask for help in PM.
15:08:31  <bnoordhuis>isaacs needs to program his bots better
15:08:37  <bnoordhuis>ircretary: ^
15:08:38  <ircretary>bnoordhuis: I'm not sure what to do with that command. Ask for help in PM.
15:08:40  <bnoordhuis>see?
15:08:52  <bnoordhuis>we're still a long way off from skynet
15:11:57  <tjfontaine>http://dl.dropbox.com/u/35720/29c3-day2-lightning-sshdb.png
15:12:39  * AvianFluquit
15:13:08  * AvianFlujoined
15:15:12  * ericktquit (Quit: erickt)
15:15:36  * ericktjoined
15:15:58  * Chip_Zeroquit (Ping timeout: 245 seconds)
15:22:02  * Chip_Zerojoined
15:27:38  * mjr_joined
15:31:01  * benoitcquit (Excess Flood)
15:31:43  <indutny>tjfontaine: so what? :)
15:32:05  <tjfontaine>indutny: nothing it's an interesting concept, an extension of their ssl work
15:32:53  * `3rdEdenjoined
15:36:44  <indutny>dnssec?
15:36:54  <indutny>yeah, I like it
15:37:03  <indutny>it's the main weakness point in the internet so far
15:37:07  <indutny>I mean dns
15:37:10  * benoitcjoined
15:37:17  <tjfontaine>well it's a weakness and a strength
15:37:18  <indutny>well, it doesn't hurts much
15:37:32  <indutny>s/hurts/hurt
15:37:52  <indutny>since we have TLS certs and other stuff
15:38:03  <indutny>tjfontaine: what is the strength of non-secure dns?
15:38:13  <indutny>it just doesn't hurt
15:38:18  <indutny>but it's not secure :)
15:38:44  <tjfontaine>indutny: no you said dns is the main weakness in the internet, and I said it's a strength :)
15:38:52  <indutny>ah
15:38:55  <indutny>in this sense
15:38:58  <indutny>well, yes
15:39:32  <bnoordhuis>dns is why i still religiously update my hosts file every day
15:39:35  <tjfontaine>as far as making people believe they have valid data yes, there is work to be done, but dns itself is an excellent fault tolerante distributed system
15:39:39  <bnoordhuis>admittedly, it's getting pretty big by now
15:41:04  * AvianFluquit (Quit: Leaving)
15:41:33  * AvianFlujoined
15:44:36  <MI6>joyent/node: Ryunosuke SATO master * c4fc0fe : https: optimize https.createConnection() Stop using `arguments` for perf - http://git.io/oZS1gg
15:47:02  * ericktquit (Quit: erickt)
15:47:42  <indutny>bnoordhuis: I think it's the most biggest distributed system in the world
15:48:08  <tjfontaine>he meant his hosts file :P
15:48:21  <indutny>bnoordhuis: ah, that file
15:48:29  <indutny>bnoordhuis: why not just use tls?
15:48:37  <bnoordhuis>thread-local storage?
15:48:46  <indutny>no not that one
15:48:56  <indutny>forgot that you're oldschool guy
15:48:58  <indutny>SSL
15:49:04  <bnoordhuis>ah, _that_ tls
15:49:13  <indutny>Transport Layer Security
15:49:27  <indutny>much more correct than Secure Sockets Layer
15:49:36  <indutny>because it's not related to sockets at all
15:49:42  <bnoordhuis>my main beef with tls/ssl is that it's only as secure as the issuers of certificates
15:49:52  <indutny>indeed it is
15:49:54  <indutny>but
15:50:06  <tjfontaine>and the people who verify the certificates
15:50:09  <indutny>if they'll f^ck up everything, hosts file won't save you
15:50:17  <indutny>because anyone will be able to decode your traffic anyway
15:50:44  <bnoordhuis>indutny: that's why i always use 1337 sp34k
15:51:00  <bnoordhuis>let the nsa try to decipher that!
15:51:38  * TheJHquit (Ping timeout: 255 seconds)
15:51:42  <indutny>erh
15:51:50  <indutny>well
15:51:59  <indutny>you're using well-known protocols anyway
15:52:05  <indutny>SMTP
15:52:10  <indutny>IRC
15:52:10  <indutny>SSH
15:52:19  <indutny>last one is not the case, but you know
15:52:25  <indutny>your hackery won't help much
15:52:46  <indutny>ok, your trolling on me has gone too far
15:52:49  <bnoordhuis>indutny: you hear that whooshing sound?
15:52:51  <bnoordhuis>indeed :)
15:53:01  * indutnysends missles
15:53:27  <bnoordhuis>hm, i know you ex-soviets have thousands of those lying around
15:53:30  <indutny>https://www.google.com/webhp?hl=xx-hacker
15:53:35  <indutny>bnoordhuis: yes
15:53:41  <indutny>that's pretty scary actually
15:53:56  <indutny>a people are finding abandoned bases
15:53:59  <indutny>all around the country
15:54:14  <bnoordhuis>yeah. worrisome
15:55:03  <indutny>nothing dangerous
15:55:08  <indutny>but anyway...
15:55:59  * benoitcquit (Excess Flood)
15:56:01  <txdv>is vert.x still faster than node?
15:56:56  <indutny>do you care?
15:57:03  <indutny>I suppose it is
15:57:10  * benoitcjoined
15:57:10  <indutny>especially after streams2 has landed
15:57:14  <txdv>xD
15:57:22  <txdv>why streams2 if it makes it slower
15:57:46  <bnoordhuis>txdv: presumably the performance drop will get fixed in the next few weeks
15:57:48  <indutny>you know, that's what I'm asking myself
15:57:55  <indutny>yes, what ben said
15:57:59  <indutny>it's js
15:58:07  <indutny>easy to optimize
15:58:17  <indutny>and abstraction is really good
15:58:20  <bnoordhuis>re vert.x, it's easy to be faster if you only implement a subset of your competitor's functionality
15:58:38  <txdv>subset?
15:58:50  <txdv>i thought they had like scalable stuff on multiple cores
15:59:00  <indutny>txdv: tell me about it
15:59:06  <bnoordhuis>i'm talking about stuff like http request/response parsing
15:59:15  <txdv>a ok
15:59:34  <txdv>I have to write an http parser in c# too
15:59:37  <txdv>and I am not amused
15:59:42  <bnoordhuis>it's a pain
15:59:55  <tjfontaine>txdv: why not grab the mono implementation?
15:59:55  <bnoordhuis>but that's probably true for any protocol people actually use
16:00:04  <indutny>bnoordhuis: not, for every
16:00:09  <bnoordhuis>name one
16:00:12  <indutny>bnoordhuis: spdy is pretty cool
16:00:23  <txdv>Not well designed for async/callback based parsing
16:00:25  <indutny>bnoordhuis: you can implement it in a couple of days
16:00:34  <indutny>bnoordhuis: implementing "true" http parser lasts days
16:00:36  <tjfontaine>they all start out simple then grow warts as implementations diverge
16:00:42  <bnoordhuis>indutny: it's something of a stretch to say that spdy is something people use on a daily basis
16:00:50  <bnoordhuis>indutny: some people, yes. all people, no
16:00:52  <indutny>bnoordhuis: we do
16:01:02  <indutny>bnoordhuis: many people are using it on daily basis
16:01:03  <txdv>in soviet russia ...
16:01:08  <bnoordhuis>hah
16:01:21  <indutny>bnoordhuis: every major browser supports it
16:01:30  <indutny>bnoordhuis: plus twitter/google servers
16:01:32  <bnoordhuis>indutny: internet explorer?
16:01:34  <indutny>and amazon silk
16:01:39  <indutny>bnoordhuis: does it use http anyway?
16:01:52  <txdv>internet explorer?
16:01:52  <bnoordhuis>indutny: don't evade the question :)
16:01:53  <indutny>:)
16:02:03  <bnoordhuis>you get my point
16:02:05  <txdv>isn't the internet explorer there so you can bash it and say 'haha, ie doesn't have this feature'
16:02:07  <indutny>well
16:02:20  <bnoordhuis>of all the people in this world, maybe 1% uses spdy on a daily basis
16:02:28  <indutny>txdv: I'm not a browser man, not anymore
16:02:29  <bnoordhuis>but it's probably a lot less than 1%
16:02:37  <indutny>bnoordhuis: I'm sure that much more than 1%
16:02:42  <txdv>what do you mean by browser man?
16:02:50  <bnoordhuis>indutny: how much do you want to bet?
16:02:54  <indutny>well, I do not do front-end stuff
16:02:55  <txdv>Like you don't care about what trademark browser you are using?
16:02:58  <indutny>bnoordhuis: one bottle of beer
16:03:01  <bnoordhuis>indutny: note carefully we're talking _daily_ use here
16:03:25  <indutny>bnoordhuis: mean?
16:03:33  <indutny>bnoordhuis: root square?
16:03:34  <indutny>:)
16:03:43  <tjfontaine>bnoordhuis: oh oh I know, icmp! :P
16:03:52  <bnoordhuis>indutny: if my hip, web 2.0 browser doesn't connect to a spdy-enabled server at least once a day, i'm not using spdy daily
16:03:54  * `3rdEdenquit (Remote host closed the connection)
16:03:55  <txdv>http will never go away
16:03:59  <txdv>i hate this about IT
16:04:12  <txdv>it was the first standard which was shit hacked together
16:04:20  <bnoordhuis>txdv: it's not that bad. uucp only took twenty years to die
16:04:21  <txdv>and now it will stay forever
16:04:27  <bnoordhuis>well, maybe more like 30
16:04:32  <bnoordhuis>anyway
16:04:36  <indutny>just 30
16:04:38  <indutny>it's ok
16:04:44  <indutny>we'll live forever by then
16:04:52  <bnoordhuis>indutny: back to spdy, still want to bet that bottle?
16:05:00  <indutny>bnoordhuis: how would we account it? :)
16:05:03  <indutny>ask mike?
16:05:09  <bnoordhuis>which mike?
16:05:15  <indutny>bnoordhuis: belsche
16:05:23  <indutny>belshe*
16:05:24  <txdv>bottle of beer?
16:05:26  <txdv>why not vodka?
16:05:39  <indutny>bottle of heineken
16:05:40  <txdv>1l bottle from russia
16:05:41  <bnoordhuis>i don't like strong liquor
16:05:41  <indutny>haha
16:05:49  <bnoordhuis>i also don't like heineken :)
16:05:50  <txdv>thats the point
16:05:54  <indutny>bnoordhuis: why not?
16:05:55  <txdv>the looser drinks the bottle
16:05:59  <indutny>bnoordhuis: it's made in the city you live in
16:06:15  <bnoordhuis>indutny: 1) i don't live in amsterdam, 2) it tastes like cat piss
16:06:21  <bnoordhuis>it's good for selling to tourists though
16:06:22  <txdv>xD
16:06:40  <indutny>bnoordhuis: I like franziskaner
16:06:51  <bnoordhuis>weissbier? yeah, me too
16:07:03  <indutny>not sure what your word means, but ok
16:07:10  <txdv>jutes altes deutches weissbier
16:07:18  <bnoordhuis>i guess it means wheat beer
16:07:22  <indutny>ah
16:07:27  <indutny>that's much clearer
16:07:29  <txdv>weizenbier
16:07:31  <indutny>yeah, its' really good
16:07:32  <txdv>is the proper german term
16:07:43  <bnoordhuis>not that americans could recognize a decent wheat beer if it hit them in the face
16:08:11  <indutny>oh, I used to drunk some mexican beer in one pub
16:08:16  <indutny>it was pretty nice
16:08:20  <indutny>not solid, but no
16:08:26  <indutny>s/but no/but nice
16:08:35  <txdv>if heineken is cat piss... i don't know what american beer has to be
16:08:38  <bnoordhuis>an interesting observation i made a while ago in SF
16:08:55  <bnoordhuis>the kind of beer that is drunk by turtle-neck tooting SF hipsters in CA
16:09:05  <bnoordhuis>is the same kind of beer we serve to homeless alcoholics here
16:09:09  <bnoordhuis>not sure what to make of that
16:09:13  <tjfontaine>haha
16:09:23  <txdv>xD
16:09:24  <tjfontaine>make of it: americans have terrible taste
16:09:36  <txdv>I guess it wasn't mainstream
16:09:45  <txdv>What brand is that tjfontaine?
16:09:47  <indutny>tjfontaine: ++
16:10:02  <indutny>tjfontaine: really bad taste
16:10:13  <indutny>tjfontaine: sometimes I can't even look at what people are eating there
16:10:20  <tjfontaine>hah
16:10:23  <indutny>tjfontaine: though, tomatos in USA are pretty decent
16:10:33  <indutny>really decent
16:10:36  <tjfontaine>bnoordhuis: but as far as hipsters go, they were probably drinking it to be "ironic"
16:10:44  <txdv>what about russian beer?
16:10:47  <bnoordhuis>tjfontaine: well, they succeeded
16:10:52  <txdv>IMO they didn't quite get it right either
16:11:29  <txdv>indutny: is there a good russian beer brand?
16:11:37  <txdv>We in lithuania can buy some of the stuff from russia
16:12:03  <indutny>txdv: nope
16:12:19  <txdv>they all taste like they put caramel in it or smth
16:12:46  <indutny>nope
16:12:52  * TheJHjoined
16:12:58  <indutny>heineken is pretty good comparing to russian beer
16:13:07  <indutny>though russian is much cheeper
16:13:19  <indutny>there're is one outstanding beer, however
16:13:23  <indutny>it's called Baltika
16:13:29  <indutny>and have a digit postfix
16:13:30  <txdv>lol
16:13:32  <indutny>from 0 to 9
16:13:41  <indutny>0 means 0% alcohol
16:13:44  <indutny>9 means vodka
16:13:50  <indutny>really outstanding
16:14:05  <txdv>you know that lithuania is one of the 3 baltic states
16:14:08  <indutny>you can always track how much you're alcoholic
16:14:15  <indutny>txdv: surely, I know
16:14:21  <indutny>txdv: I'm estonian by nationality
16:14:31  <indutny>though, I never been there
16:14:41  <txdv>wtf
16:14:46  <txdv>do you speak estonian?
16:14:56  <indutny>nope
16:15:10  <indutny>my mother is estonian
16:15:16  <indutny>well, actually half-estonian
16:15:21  <indutny>but, that's what in her passport
16:15:27  <txdv>does she speak?
16:16:00  <indutny>nope
16:16:01  <indutny>:)
16:16:11  <indutny>grandpa has left her family when she was a child
16:16:29  <txdv>bad grandpa
16:16:40  <indutny>idk, don't want to judge people I've never seen
16:16:54  <indutny>usually, things are much more complicated than they seem to be
16:16:56  <txdv>so you live permanently in russia but you have the est nationality
16:17:08  <indutny>well, I don't have estonian nationality...
16:17:12  <indutny>because I'm 1/4 estonian
16:17:19  <indutny>and because my father is russian
16:17:30  <bnoordhuis>idk, don't want to judge people I've never seen <- i never have a problem with that
16:17:43  <txdv>fuck linus torvalds
16:17:44  <indutny>bnoordhuis: you mean bill gates
16:17:48  <indutny>bnoordhuis: or linus
16:17:54  <indutny>txdv: ah, you already said it
16:18:02  <txdv>no he is actually a funny guy
16:18:04  <indutny>in my opinion
16:18:05  <txdv>i like his rants
16:18:07  <bnoordhuis>indutny: oh, just about anyone. i'm an equal opportunities hater
16:18:11  <indutny>linus is an ultimate moron
16:18:19  <txdv>because they are not personal, they are all about TECH
16:18:20  <indutny>with successful product
16:18:28  <bnoordhuis>nah, i don't agree
16:18:54  <bnoordhuis>the issue is the nerd media hype it up because he is linus torvalds
16:19:08  <bnoordhuis>lots of people complain about e.g. kde
16:19:16  <bnoordhuis>but it's only news when linus rants about it
16:19:27  <indutny>when, those people are morons too
16:19:38  <indutny>(see, not judging people)
16:20:17  <indutny>ok, I need to talk with him first
16:21:02  <indutny>I think it's time for me to sleep
16:21:04  <indutny>ttyl guys
16:21:13  <indutny>36 hours later
16:21:20  <indutny>may be even 40
16:21:40  <txdv>why are people ranting about kde/gnome
16:21:45  <txdv>just don't use it if you don't like it
16:21:52  <txdv>seriously, i am using the awesome window manager
16:21:56  <txdv>because obviously i am awesome
16:21:58  <bnoordhuis>indutny: sleep tight
16:22:26  <bnoordhuis>txdv: i don't understand that either. but window managers / desktop environments is something people can get really riled up about
16:22:58  <txdv>I used to be that kid who used fluxbox because it was cool
16:23:15  <txdv>now i just use awm because it is just the easiest to use of the keyboard controlled managers
16:23:46  <bnoordhuis>same here, kind of. i switch back and forth between awesome and gnome
16:23:59  <bnoordhuis>i don't really care either way because i just need a terminal and a browser
16:24:05  <bnoordhuis>both do the job fine
16:25:08  <tjfontaine>amen.
16:25:12  * ericktjoined
16:25:53  * Sh4rKjoined
16:25:58  <Sh4rK>hi
16:26:08  <bnoordhuis>turns out i'm switching between awesome and lxde actually. just goes to demonstrate my point :)
16:26:12  <Sh4rK>I'm trying to use uv_run2 with UV_RUN_ONCE
16:26:13  <bnoordhuis>Sh4rK: hi
16:26:27  <Sh4rK>and it does a strange thing
16:26:44  <Sh4rK>it returns 0 sometimes. but after alling it again, it doesn't
16:26:59  <Sh4rK>oops
16:27:01  <Sh4rK>typing fail
16:27:04  <Sh4rK>so
16:27:12  <Sh4rK>it returns 0 when it shouldn't
16:27:27  <Sh4rK>(0 means there are no more events
16:27:28  <Sh4rK>)
16:27:54  <tjfontaine>Sh4rK: do you have a reproducible case?
16:28:22  <Sh4rK>in my little test, it always does that
16:28:43  <tjfontaine>can you pastebin/gist it?
16:28:46  <Sh4rK>it doesn't even do anything, because it exits before any work is done
16:28:53  * TheJHquit (Ping timeout: 255 seconds)
16:28:55  <Sh4rK>I'll try to narrow it down a bit
16:36:09  <txdv>AMEN
16:40:06  <Sh4rK>tjfontaine: http://pastebin.com/ArvbyTa8
16:40:27  <Sh4rK>maybe I'm simply doing something wrong, in that case can you tell me what it is? :D
16:42:27  * bradleymeckquit (Quit: bradleymeck)
16:55:49  * benoitcquit (Excess Flood)
16:56:23  <tjfontaine>Sh4rK: there aren't anymore requests to process, the uv_fs_open succeeded?
17:00:41  * benoitcjoined
17:03:27  <Sh4rK>but that one event should cause both lines to be printed
17:03:40  <Sh4rK>once in the callback, and once in the loop body
17:03:50  <Sh4rK>and it is only printed from the callback
17:03:52  <tjfontaine>no, because it blocks while waiting for the request
17:04:07  <Sh4rK>yeah, and?
17:04:36  <tjfontaine>it blocks waiting for uv_fs_open to finsih, then when that's done there are no more requests because nothing was scheduled inside uv_fs_open's callback, thus returns 0 and the loop body is never called
17:04:39  <Sh4rK>oh I think I got it just now
17:04:48  <Sh4rK>yeah
17:04:51  <Sh4rK>hmm
17:05:10  <Sh4rK>for some reason I thought it returned 1 if there were any event
17:05:14  <Sh4rK>and 0 if no
17:06:38  <Sh4rK>actually what I want to do is to write a pull style api on top of libuv
17:07:06  * mikealquit (Quit: Leaving.)
17:07:35  <Sh4rK>where you can do something like event = waitForEvent()
17:07:53  <Sh4rK>how should I do that?
17:08:15  <tjfontaine>I'm not entirely sure what you mean
17:10:01  <Sh4rK>that instead of libuv calling callbacks when events occur, I can poll for events
17:10:03  <MI6>joyent/libuv: Ben Noordhuis master * 92a19a1 : unix: ensure done_cb gets called after uv_cancel() Wake up the event loo - http://git.io/OTgZdg
17:11:47  * travis-cijoined
17:11:47  <travis-ci>[travis-ci] joyent/libuv#985 (master - 92a19a1 : Ben Noordhuis): The build passed.
17:11:47  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/9614d5113526...92a19a19dd87
17:11:47  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/3858630
17:11:47  * travis-cipart
17:12:13  <bnoordhuis>Sh4rK: you probably want to call uv_run2(loop, UV_RUN_NOWAIT) from time to time
17:12:40  <bnoordhuis>UV_RUN_ONCE will block until there's at least one event ready
17:13:07  <Sh4rK>yeah, but these will still call the callbacks, instead of returning an event
17:13:24  <Sh4rK>what I want is get the event returned
17:13:48  <tjfontaine>that's a signficant change in design, and doesn't match how node.js (the main consumer) integrates
17:13:52  <bnoordhuis>Sh4rK: oh, like that. i've got bad news for you: that's not possible :(
17:14:02  * ericktquit (Quit: erickt)
17:14:55  <Sh4rK>then I'll have to come up with something myself :D
17:25:11  <MI6>joyent/node: Ben Noordhuis master * 910e24b : fs: remove fs.sendfile() Said function has been broken (and useless) sin - http://git.io/UW6cAg
17:26:43  * qmx|awaychanged nick to qmx
17:28:43  * mikealjoined
17:35:26  <MI6>joyent/node: Ben Noordhuis master * c6e958d : fs: make 'end' work with ReadStream without 'start' Make `fs.createReadS - http://git.io/lqhVXw
17:36:41  <isaacs>bnoordhuis: yeah, ircretary's not so bright, really
17:37:11  <bnoordhuis>isaacs: fix that? you don't want google to one-up you, do you?
17:37:17  <isaacs>bnoordhuis: ha
17:37:18  * ericktjoined
17:37:41  <isaacs>bnoordhuis: so, i've been comparing my http-speedup branch against master right before merging streams2
17:38:00  <bnoordhuis>isaacs: and?
17:38:07  <isaacs>bnoordhuis: it's still about 10% slower, but it's a huge improvement. i'm growing suspicious of the numbers i'm seeing in some cases, though
17:38:21  <bnoordhuis>why?
17:38:24  <isaacs>it's 10% slower on my mac, butonly 2% slower on smartos, and on linux, i'm sure that i'm hitting some kind of arbitrary limit.
17:38:36  <isaacs>because the requests-per-second are way too low
17:39:03  <isaacs>that box has 8gb of ram and lots of cpu, and it's not doing anything, but my macbook is outperforming it by a wide margin
17:39:06  <isaacs>that seems wrong.
17:39:17  <bnoordhuis>well, it's smartos you know
17:39:23  <isaacs>nono, linux is actually worse
17:39:49  <isaacs>the smartos zone is getting close to the same perf as my laptop, and they're comparable on ram
17:40:20  <isaacs>ie, they both have 8gb of ram, but the smartos box has more cpu
17:41:05  <bnoordhuis>isaacs: is it virtualized or dedicated?
17:41:25  <isaacs>well, the smartos is a zone, but yes, the linux box is a vm
17:41:31  <isaacs>so maybe that makes sense, then
17:42:08  <bnoordhuis>network i/o usually suffers terribly on virtualized instances
17:42:17  <isaacs>ah, ok
17:42:25  <bnoordhuis>though it's interesting that there's significant differences between xen, vmware and kvm
17:42:53  <tjfontaine>vmware probably matters a lot if you're using E1000 or VMXNET3 driver
17:44:10  <isaacs>well, in that case, the linux performance is apparently comparable enough that it's maxing out the vm, which is nice
17:44:23  <isaacs>but http_simple on my laptop is still weak sauce
17:46:30  <isaacs>the thing that sucks about smartos only being a 2% diff at this point is that it makes the flamegraphs less useful
17:46:45  <isaacs>because there's really not any more obvious losses.
17:47:06  <bnoordhuis>flame graphs are for designers, real men look at the raw v8.log files
17:47:22  <tjfontaine>shiver
17:48:41  <bnoordhuis>okay, off to dinner. may pop in later tonight
17:54:43  * joshthecoderjoined
17:56:44  <isaacs>bnoordhuis: oh, btw, i fixed a bug which was causing http sockets to buffer all data forever.
17:57:04  <isaacs>bnoordhuis: well, not forever, but for the life of the socket
17:57:08  <isaacs>bnoordhuis: it's much faster without that
17:58:34  <rendar>question: since epoll or kqueue tells us only if there is new data to read, the actual read() or write() of such data is blocking and synchronous right? but libuv performs it in different threads - am i right?
18:04:41  * Raltquit (Remote host closed the connection)
18:07:38  <isaacs>rendar: it depends.
18:07:54  <rendar>isaacs: hmm, about what?
18:08:03  <isaacs>rendar: sockets and files are different there
18:08:13  <isaacs>rendar: libuv does fs io in separate threads
18:11:11  <rendar>isaacs: oh yeah, well, for sockets i/o is easy to make read()/write() not blocking..isn't just setting the socket not blocking with an ioctl?, let's not consider sockets for a moment, but what about files i/o ? in unix the 2 possibilities are: 1 - using a threadpool with normal sync read() and write() or 2 - use that posix AIO* structures, right?
18:11:48  <isaacs>rendar: we use a thread pool with traditional posix read/write
18:12:01  <isaacs>rendar: AIO is not viale
18:12:04  <isaacs>*viable
18:12:50  <rendar>why?
18:17:13  <rendar>isaacs: you mean its broken?
18:17:47  <isaacs>rendar: ask bnoordhuis about AIO some time.
18:17:57  <isaacs>there are a lot of cases where it falls back to being synchronous, isn't portable, etc.
18:18:00  <isaacs>threads are fin there.
18:18:02  <rendar>i'm reading that with AIO stuff you have to poll, or the kernel will start a new thread for each call
18:18:05  <isaacs>*fine
18:19:31  <rendar>so the best thing is just normal read() but in the threadpool, so you can maintain occupied all cpu cores
18:27:46  * indexzerojoined
18:37:16  * ericktquit (Quit: erickt)
18:38:22  * c4milo_quit (Remote host closed the connection)
18:38:26  * lohkeyjoined
18:39:34  * ericktjoined
18:45:12  * ericktquit (Quit: erickt)
18:46:46  * c4milojoined
19:00:09  * piscisaureus_joined
19:02:35  <piscisaureus_>ohai
19:02:36  <piscisaureus_>ircretary: notes
19:03:10  <piscisaureus_>bnoordhuis: yes I want to discuss dualstack with you. vocally
19:16:22  * benoitcquit (Excess Flood)
19:17:14  * loladiro_joined
19:18:42  * benoitcjoined
19:20:11  * loladiroquit (Ping timeout: 260 seconds)
19:20:11  * loladiro_changed nick to loladiro
19:20:28  <isaacs>piscisaureus_: hola
19:20:35  <piscisaureus_>hi isaacs
19:20:43  <isaacs>piscisaureus_: so, i'm within 10% now on all three operating systems https://docs.google.com/spreadsheet/ccc?key=0AganzoeqkiHddE9uRlA5WS0xSF9NTGN1QS0zZ3FRSWc#gid=1
19:20:49  <isaacs>piscisaureus_: no idea how windows is performing.
19:21:56  <piscisaureus_>isaacs: so I should try http-speedup?
19:22:19  <isaacs>piscisaureus_: yeah. on my fork, not joyent/
19:22:37  <isaacs>piscisaureus_: i want to tweak the benchmark/http-flameraph.sh a bit
19:22:41  <isaacs>so it produces more useful svgs
19:23:03  <piscisaureus_>isaacs: sure What do you think is wrong with the atm?
19:23:45  <isaacs>the atm?
19:23:52  <piscisaureus_>haha
19:23:53  <piscisaureus_>er
19:24:02  <piscisaureus_>what is wrong with them atm ?
19:24:10  <piscisaureus_>the atm no give me money
19:24:23  <isaacs>oh, well, there's a lot of vertical space given to tiny <1px stacks
19:24:38  <isaacs>so i'm writing a little node script to remove those, and shift everything up higher
19:24:45  <piscisaureus_>ah right
19:25:00  <isaacs>v8 often has very deep, very rare stacks
19:25:09  <isaacs>but that's not really what i'm interested in anyway
19:25:27  <piscisaureus_>maybe make that an option? But it seems fine yes
19:25:39  <piscisaureus_>I often have problems seeing which function a frame represents
19:25:44  <piscisaureus_>because it's hard to hover
19:26:02  <piscisaureus_>or select
19:26:14  * loladiro_joined
19:28:45  <isaacs>yeah
19:28:51  <isaacs>it needs more designer love
19:28:59  <isaacs>maybe ditch svg for raphael or something
19:29:06  <isaacs>or d3 or whatever
19:29:36  * loladiroquit (Ping timeout: 264 seconds)
19:29:36  * loladiro_changed nick to loladiro
19:30:00  <piscisaureus_>raphael AAARGH
19:30:06  <piscisaureus_>isaacs: ok, windows score
19:30:19  <piscisaureus_>v0.8: 18700 r/s (with -c 100 -k bytes/1)
19:30:27  <piscisaureus_>http-speedup: 16000 r/s
19:30:32  <isaacs>not terrible
19:30:43  <chrisdickinson>would be neat to implement a slippy-map style interface
19:30:46  <piscisaureus_>so now it's down by < 10%
19:30:55  <isaacs>yep
19:30:57  <isaacs>comparable with the other three
19:30:58  <isaacs>that's good
19:35:14  <isaacs>we really gotta get into the habit of naming our functions more often
19:35:42  <piscisaureus_>esp. in the http code :-)
19:35:50  <isaacs>(anon) as (2202 samples) 41.69%)
19:35:54  <isaacs>yeah
19:36:02  <isaacs>maybe i'll do some naming today
19:36:38  <isaacs>here's what the pruned output looks like on http-speedup right now: http://static.izs.me/flamegraphs/streams2-2012-12-28-19-33-17.svg
19:43:01  <piscisaureus_>net.onread is still kinda expensive
19:43:05  <piscisaureus_>and _addHeaderLine
19:43:11  <piscisaureus_>and MakeCallback :-)
19:43:50  <piscisaureus_>and the http parser too
19:57:23  * indexzeroquit (Quit: indexzero)
20:00:23  * TooTallNatejoined
20:23:12  * `3rdEdenjoined
20:23:17  <isaacs>here's a verison with every function named: http://static.izs.me/flamegraphs/streams2-names-2012-12-28-20-21-21.svg
20:23:50  * indexzerojoined
20:24:12  <isaacs>i'm kind of wondering what Socket._write(chunk,cb) is spending so much time on
20:24:23  <isaacs>i abstracted out the writeReq creation to a separate function, but there's a lot left
20:25:05  <isaacs>i suspect timers.active(this);
20:25:10  <isaacs>but i don't know
20:28:29  <TooTallNate>isaacs: net socket optimizations?
20:31:35  <isaacs>hm, no, timers.active(this) is the chunk off to the right there..
20:32:28  * indexzeroquit (Quit: indexzero)
20:41:58  * brsonjoined
20:43:36  * pooyajoined
20:47:04  <bnoordhuis>back
21:00:28  <piscisaureus_>chest
21:03:15  * qmxchanged nick to qmx|away
21:13:29  <txdv>Sh4rK: you need microthreads?
21:18:21  <MI6>joyent/libuv: Ben Noordhuis master * 546387f : include: add note about SIGRT0 and SIGRT1 on linux - http://git.io/M5zpSw
21:20:17  * travis-cijoined
21:20:18  <travis-ci>[travis-ci] joyent/libuv#986 (master - 546387f : Ben Noordhuis): The build was broken.
21:20:18  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/92a19a19dd87...546387fc47fc
21:20:18  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/3862176
21:20:18  * travis-cipart
21:20:22  <bnoordhuis>broken?
21:20:25  <tjfontaine>heh
21:20:47  <tjfontaine>fuck opening that travis url crashed my browser
21:21:00  <bnoordhuis>`consumer_producer` failed: timeout <- annoying test
21:21:39  <piscisaureus_>yeah that happens for me all the time too
21:22:02  <Sh4rK>txdv: WHAT DO YOU MEAN?
21:22:07  <Sh4rK>sorry
21:22:13  <bnoordhuis>i'm 90% sure it's because travis runs in a single-core vm
21:22:14  <Sh4rK>no caps
21:22:19  <txdv>xD
21:23:04  <Sh4rK>I don't necessarily need microthreads
21:23:22  <Sh4rK>I just want to get events as returned by a function
21:23:35  <Sh4rK>instead of libuv calling callbacks for me
21:24:10  <txdv>w00t
21:24:17  <txdv>you want blocking calls?
21:25:01  <txdv>bnoordhuis piscisaureus_ it's christmas and I got no presents
21:25:02  <txdv>:(
21:25:15  <tjfontaine>no he wants foreach (event in poll()) { event() }
21:25:29  <bnoordhuis>txdv: i have some turkey left you can have
21:25:47  <txdv>That will be hard to send
21:26:00  <bnoordhuis>i've a blender
21:26:15  <txdv>hm
21:26:17  <txdv>will it blend?
21:26:35  <bnoordhuis>i'm pretty sure it will, that thing is vicious
21:27:44  <txdv>a comment will suffice
21:27:56  <txdv>preferably under a very specific issue of mine
21:28:05  <txdv>i even gathered all the info in one place
21:28:52  <piscisaureus_>I need to talk to bnoordhuis on that one
21:29:19  <txdv>a ok
21:29:40  <txdv>i'm a little pain in the ass, I know
21:29:50  <piscisaureus_>bnoordhuis are you even here?
21:29:58  <bnoordhuis>piscisaureus_: i am
21:30:06  <piscisaureus_>maybe we can do a hangout
21:30:18  <bnoordhuis>my laptop's downstairs
21:30:28  <piscisaureus_>does hangouts not work on your desktop?
21:30:32  <txdv>like over skype or what?
21:30:48  <bnoordhuis>no doubt it works but my desktop doesn't have a cam or a mic
21:30:55  <piscisaureus_>https://plus.google.com/hangouts/_/9a4908aae6d7c0657a89e9e5ae8e9839532ff170?authuser=0&hl=en#
21:30:58  <piscisaureus_>aah
21:31:17  <txdv>Sh4rK: why would you want to do that?
21:31:22  <bnoordhuis>i should probably amend that: my laptop is downstairs and in use
21:31:26  <piscisaureus_>I like to use unproven technology
21:31:39  <bnoordhuis>by my girlfriend, to watch desperate housewives on
21:31:41  <piscisaureus_>bnoordhuis: next time we see each other I will donate you a webcam with builtin usb mic
21:31:44  <bnoordhuis>or maybe sex and the city: the movie
21:32:09  <piscisaureus_>or maybe grey's anatomy
21:32:22  <bnoordhuis>possibly bridget jones' diary
21:32:24  <txdv>a blended turkey
21:32:26  <piscisaureus_>possibly 50 shades of grey: the movie
21:32:32  <bnoordhuis>is it out yet?
21:32:37  <piscisaureus_>haha I don't think so
21:32:40  <Sh4rK>txdv: if you know the reason, can you do something about it? :D
21:32:43  <piscisaureus_>but no shit it will be
21:32:58  <bnoordhuis>but speak up bertje, what did you want to discuss
21:33:03  <Sh4rK>btw, to make a binding for libuv, where callbacks are not viable
21:33:11  <piscisaureus_>bnoordhuis: txdv's dualstack thing
21:33:24  <piscisaureus_>bnoordhuis: iow, The Future Of Bind APIs
21:33:28  <bnoordhuis>ah, that
21:33:36  <piscisaureus_>but we can punt on it :-)
21:33:49  <piscisaureus_>it just means that you will have to deflect txdv from now on
21:34:02  * bnoordhuisenters lurk mode
21:34:14  <txdv>i'm good at stalking
21:35:32  * TheJHjoined
21:35:35  <txdv>Sh4rK: well, I am interested at what this allow the user to do
21:35:45  <txdv>if i find it interesting enough, I could try to write a patch
21:36:12  <Sh4rK>then here it goes
21:36:40  <Sh4rK>LuaJIT has an FFI that is very fast for lua to c calls
21:36:52  <Sh4rK>the call gets compiled too
21:37:02  <Sh4rK>but in the other direction it's slow
21:37:24  <Sh4rK>and not even possible in some scenarios
21:37:52  <Sh4rK>so what I'd like to do is make a binding to uv, when the event loop and dispatching is written in lua
21:38:24  <txdv>hm
21:38:29  <txdv>your own dispatcher
21:38:34  <rendar>isn't that already exist? luvit
21:39:19  <txdv>does it already exist in luvit?
21:39:26  <Sh4rK>no
21:39:37  <Sh4rK>it uses ordinary lua bindings
21:39:51  <txdv>So it is slow?
21:39:58  <Sh4rK>and has lots of C code too
21:40:14  * mjr_quit (Quit: mjr_)
21:40:20  <Sh4rK>I it's not that it's slow
21:40:25  <rendar>whats the difference between ordinary lua bindings and the bindings you want to do
21:40:25  <rendar>?
21:40:25  <txdv>o you want to write an ffi binding, that is the point
21:40:32  <Sh4rK>yeah
21:40:35  <txdv>he wants to write the binding in pure lua
21:41:06  <rendar>i see
21:41:29  <txdv>in that case
21:41:32  <txdv>you can do it already
21:41:35  <txdv>no need for changes
21:41:47  <Sh4rK>how?
21:41:52  <txdv>wait
21:42:00  <txdv>computing
21:44:59  <txdv>basically by reimplementing uv_run and all the dispatching on the libuv level
21:45:14  <txdv>I assume you can reference pointers and stuff in libuv
21:45:46  <Sh4rK>but isn't that level in libuv platform specific?
21:46:21  <txdv>yes it is
21:46:35  <txdv>uv_buf_t is platform specific too
21:46:42  <Sh4rK>yeah
21:46:49  <Sh4rK>nut that's a minor thing
21:46:54  <Sh4rK>*but
21:47:31  <txdv>why this obsession with lua
21:49:39  <piscisaureus_>isaacs: should we give sblom commit access? Then I can just tell him lgtm :-)
21:50:04  <txdv>platform independent
21:50:33  <txdv>Sh4rK: why do you want it to be with ffi?
21:52:29  <Sh4rK>because it's fast :P
21:52:35  <Sh4rK>and elegant
21:53:00  <txdv>how do you if it is fast
21:53:12  <txdv>do you have a benchmark?
21:53:13  <tjfontaine>fast is not something that is usually associated with ffi
21:54:27  * `3rdEdenquit (Remote host closed the connection)
21:56:41  <Sh4rK>tjfontaine: LuaJIT is a jit compiler for lua, that's really fast, and it has a built-in ffi, that is able to compile the calls to external code into the jit compiled lua code
21:57:12  <txdv>it must be jittastic
21:57:49  <tjfontaine>Sh4rK: I understand the flow, but there is a certain amount of overhead incurred with each ffi call, that can be avoided with hand tuned bindings, it's always give and take
21:59:09  <txdv>my bindings for C# are ffi too
21:59:17  <txdv>and I Was like thinking writing a module for mono
21:59:27  <tjfontaine>that doesn't make you very portable
21:59:35  <tjfontaine>but would be useful none the less
21:59:47  <txdv>tjfontaine: why doesn't it make me very portable?
22:00:27  <tjfontaine>txdv: well you would need to compile that for each mono platform, instead of being able to rely on the .so/dylib/dll for your pinvoke
22:00:34  <Sh4rK>tjfontaine: but using ordinary api for lua (which you can use to bind something) also has an overhead, which in this case is larger than the ffi
22:00:46  <txdv>O you mean the mono module, yes
22:01:02  <txdv>you are right and I am totally too lozy to reinvent the wheel
22:01:14  <txdv>just because it could be a little faster
22:01:46  * rendarquit
22:01:58  <tjfontaine>it would be useful for mono to use for its underlying async work
22:02:27  <txdv>async work?
22:03:12  <txdv>what do you mean by that
22:03:21  <tjfontaine>all that silly .net based async, like what you're doing, but system wide
22:03:22  * c4miloquit (Remote host closed the connection)
22:04:01  <Sh4rK>txdv: I didn't say YOU have to do anything
22:04:42  <txdv>tjfontaine: can you give me an example?
22:05:23  <Sh4rK>If you can/want to help, I appreciate it, but if you can't / don't want to, you don't have to say anything :)
22:06:05  <txdv>i'll talk anyway
22:06:51  <Sh4rK>ok
22:13:00  * indexzerojoined
22:17:59  * TooTallNatequit (Ping timeout: 260 seconds)
22:24:06  * c4milojoined
22:25:10  * piscisaureusjoined
22:33:27  * hzquit
22:33:46  * indexzeroquit (Quit: indexzero)
22:33:49  * qmx|awaychanged nick to qmx
22:34:17  * brsonquit (Ping timeout: 255 seconds)
22:48:02  * qmxchanged nick to qmx|away
22:56:52  * piscisaureusquit (Ping timeout: 248 seconds)
22:57:10  * piscisaureusjoined
23:03:43  * ericktjoined
23:07:21  * indexzerojoined
23:19:48  * ericktquit (Ping timeout: 248 seconds)
23:27:40  * indexzeroquit (Quit: indexzero)