00:00:30  <igorzi>piscisaureus: hmm.. you might be right
00:00:58  <igorzi>piscisaureus: gtg, i'll be on-line later
00:01:12  <piscisaureus>igorzi: not me. See you tomorrow.
00:05:41  * piscisaureuspart
00:06:04  * piscisaureusjoined
00:11:51  * bnoordhuisquit (Ping timeout: 252 seconds)
01:10:36  * jmp0quit (*.net *.split)
01:10:37  * brsonquit (*.net *.split)
01:10:39  * isaacsquit (*.net *.split)
01:10:40  * Casanquit (*.net *.split)
01:13:07  * DrPizzaquit (Excess Flood)
01:13:13  * Casanjoined
01:13:13  * isaacsjoined
01:13:13  * jmp0joined
01:13:25  * DrPizza_joined
01:13:35  * DrPizza_quit (Excess Flood)
01:13:53  * DrPizzajoined
01:56:24  <dmkbot>joyent/node: Southern: Added URL support for .get() in lib/http2.js and libhttps2.js; Added .valid() in lib/url.js - https://github.com/joyent/node/issues/1820
02:00:12  * isaacsquit (Quit: isaacs)
02:43:01  * bradleymeckjoined
03:05:18  * isaacsjoined
03:06:33  * piscisaureusquit (Read error: Connection reset by peer)
03:09:39  * indexzeroquit (Quit: indexzero)
03:11:09  * indexzerojoined
04:35:11  * ericktquit (Quit: erickt)
04:35:11  * erickt_changed nick to erickt
04:59:32  * bradleymeckquit (Ping timeout: 258 seconds)
05:46:12  * Casanquit (Quit: Leaving)
05:49:18  * pquernaquit (Ping timeout: 255 seconds)
05:52:45  * pquernajoined
06:20:13  * pquernaquit (Ping timeout: 258 seconds)
06:29:46  * mralephjoined
06:31:00  * pquernajoined
06:41:29  * isaacsquit (Quit: isaacs)
06:48:13  * pquernaquit (Ping timeout: 252 seconds)
06:48:48  * pquernajoined
07:02:13  * isaacsjoined
07:22:15  * pquernaquit (Changing host)
07:22:15  * pquernajoined
07:44:04  * Casanjoined
07:57:40  * mralephquit (Quit: Leaving.)
08:13:43  * pquerna_joined
08:15:31  <CIA-53>libuv: Igor Zinkovsky ipc * rcbca726 / (test/run-tests.c test/test-ipc.c): complete test-ipc - http://git.io/KtUBQQ
08:17:48  * pquernaquit (Ping timeout: 276 seconds)
08:55:09  * Casanquit (Quit: Leaving)
10:05:07  <indutny>pquerna_: yt?
10:07:01  * indexzero_joined
10:09:04  * indexzeroquit (Ping timeout: 244 seconds)
10:09:04  * indexzero_changed nick to indexzero
11:55:54  <indutny>libuv is just awesome
11:55:58  <indutny>anyone there?
11:56:09  <indutny>I was doing tcp proxying in 0.4.x
11:56:23  <dmkbot>joyent/node: kuebk: Inconsistency between path.resolve and require.resolve - https://github.com/joyent/node/issues/1822
11:56:26  <indutny>and when doing siege -c 200 I got > 400 open connections
11:56:30  <indutny>with 0.5.x
11:56:33  <indutny>it's exactly 400
11:56:34  <indutny>he
11:56:38  <indutny>s/he/heh
11:56:52  <indutny>much better socket handling
12:16:02  * Casanjoined
12:19:30  * indexzeroquit (Quit: indexzero)
12:20:06  * indexzerojoined
12:21:56  * indexzeroquit (Client Quit)
12:32:40  * bradleymeckjoined
12:38:24  * ryahwakes up
12:47:25  <indutny>morning
12:52:58  * bnoordhuisjoined
12:53:28  <bradleymeck>morning
13:03:59  <ryah>bnoordhuis: yo
13:04:15  <ryah>bnoordhuis: can i skype you?
13:06:41  <bnoordhuis>ryah: i'm fairly sure you are capable of that, yes
13:07:12  <bnoordhuis>you're up early btw
13:07:34  <ryah>actually nvermind, im going back to bed. i'll catch up later
13:08:01  <bnoordhuis>in that case, sleep tight
13:13:25  * indexzerojoined
13:25:04  * piscisaureusjoined
14:04:53  * luxigojoined
14:39:22  * ericktquit (Quit: erickt)
14:44:58  * ericktjoined
14:56:42  * indexzeroquit (Ping timeout: 252 seconds)
15:05:19  * bradleymeckquit (Ping timeout: 248 seconds)
15:21:36  * indexzerojoined
15:34:09  <indutny>hm... I've benchmarked 0.5.x against 0.4.x
15:34:15  <indutny>and I see interesting results
15:34:23  <indutny>while it's much stablier and faster
15:34:31  <indutny>0.5.x seems to be eating 3x of 0.4.x memory
15:34:43  <indutny>any ideas why?
15:39:17  <bnoordhuis>indutny: what exactly did you benchmark?
15:39:31  <indutny>bnoordhuis: net server balancing requests to two https servers
15:39:40  <indutny>actually, proxying
15:39:48  <indutny>all running in one process
15:40:01  <indutny>and servers are pushing 1mb response
15:40:32  <indutny>benchmarking using `siege`
15:40:43  <bnoordhuis>indutny: we use much larger tcp buffers now, maybe that's what you're seeing
15:40:52  <indutny>bnoordhuis: hm... probably
15:41:29  <indutny>bnoordhuis: 400 concurrent connections should allocaed quite big amount of memory, though
15:41:31  <indutny>bnoordhuis: right?
15:41:38  <indutny>s/allocaed/allocate
15:42:30  <bnoordhuis>indutny: right, that's 64K + a little extra per connection
15:42:44  <bnoordhuis>something that's scheduled to be tuned, i thinkk
15:42:50  <indutny>hm....
15:42:53  <indutny>strange
15:43:02  <indutny>I see that it's using 12% of 4gb RAM
15:43:11  <indutny>ah
15:43:15  <indutny>right
15:43:24  <indutny>it's writing 1mb buffer to each connection
15:43:32  <indutny>probably concurrency is quite better in 0.5.x
15:44:24  <indutny>btw, 0.4.x has a big problem with fd limits when opening many sockets
15:44:24  <bnoordhuis>indutny: i should hope so :)
15:44:28  <indutny>socket management is awful
15:44:42  <indutny>0.5.x works fine
15:44:42  <bnoordhuis>good thing that 0.4.x is going away eh?
15:44:47  <indutny>bnoordhuis: +1
15:44:49  <indutny>:D
15:45:06  <indutny>yep, but 0.6.x seems to be delayed
15:45:07  <indutny>right?
15:45:24  <bnoordhuis>indutny: well... we're aiming for november
15:45:31  <bnoordhuis>so in that respect we're pretty much on track
15:45:44  <indutny>of course
15:46:10  <bnoordhuis>but i think ryah's initial estimate was august so in that respect we're kind of overdue
15:46:59  <indutny>haha
15:47:01  <indutny>right :)
15:47:20  <indutny>I knew that, because landing and finishing libuv is a long-term task
15:47:39  <rmustacc>indutny: Were you able to verify that siege wasn't doing something else to mess up your benchmarking?
15:47:53  <rmustacc>I've seen many cases were seige was simply misconfigured.
15:48:07  <indutny>rmustacc: why is it working fine on 0.5.x in that case?
15:48:36  <indutny>rmustacc: I'm using siege because I need it to request predefined urls and emulate user activity
15:48:43  <indutny>rmustacc: and also I patched it to support SNI
15:48:45  <rmustacc>I'm just saying in general. This is the problem with benchmarks. Someone had numbers that looked fine for example, but they weren't happy with them. Turned out that they were doing a ton of broken stats, etc.
15:49:00  <indutny>rmustacc: I'm not benchmarking req/sec
15:49:13  <indutny>rmustacc: I'm looking how process will behave under natural load
15:49:19  <rmustacc>Doesn't matter what you're benchmarking, you still gotta make sure it'll do the right hting.
15:49:22  <rmustacc>*thing
15:49:33  <rmustacc>Just asking if you looked into it or not. Not a big deal.
15:49:37  <indutny>rmustacc: right, that's art of benchmarking :)
15:49:55  <indutny>rmustacc: ok, so what do you mean by saying `misconfigured` ?
15:49:58  <rmustacc>Which is what you said you were doing.
15:50:07  <rmustacc>Well, simply profile and see where all your time is being spent, etc.
15:50:31  <bnoordhuis>which is admittedly pretty hard to do with node
15:50:35  <indutny>haha
15:50:39  <indutny>SunOS + dtrace
15:50:53  <indutny>but I'm on linux
15:51:00  <rmustacc>Someone once had a dangling symlink that was used in that system and took a huge performance hit. You'd see that most of your time in the kernel for example was on the filesystem.
15:51:12  <rmustacc>Eh, you're letting your OS be an excuse? ;)
15:52:02  <indutny>rmustacc: hehe
15:52:12  <bnoordhuis>well... i wish linux had dtrace
15:52:24  * indutnywish that too
15:52:32  <bnoordhuis>end-to-end profiling is kind of a dark and heathen art right now
15:52:37  <indutny>rmustacc: anyway, benchmarking is incorrect word for what I'm doing
15:52:44  <indutny>rmustacc: load-testing
15:52:47  <indutny>is correct one
15:53:00  <rmustacc>Sure, but how do you know it's testing the correct load?
15:53:16  <indutny>rmustacc: it's doing a lot of random requests, and that's enough for me :D
15:53:42  <indutny>rmustacc: I don't think that I should spent more time on benchmarking, than on implementing things
15:53:45  <indutny>lol :D
15:54:28  <rmustacc>Well, depending on what you're doing, I'd certainly hope you'd spend more time quantifying and verifying what's going on then implementing.
15:54:43  <rmustacc>*than
15:56:11  <bnoordhuis>indutny: do you have any pending pull requests i should review / merge?
15:57:08  <rmustacc>Catch you folks in a bit.
15:57:25  <bnoordhuis>hf, rmustacc
15:57:33  <bnoordhuis>indutny: https://github.com/joyent/libuv/pulls <- probably these?
15:59:49  <indutny>bnoordhuis: probably
15:59:52  <indutny>lets see
15:59:57  * Casanquit (Quit: Leaving)
16:00:06  <indutny>bnoordhuis: https://github.com/joyent/libuv/pull/209
16:00:20  <indutny>bnoordhuis: https://github.com/joyent/libuv/pull/207
16:00:36  * indexzeroquit (Quit: indexzero)
16:00:37  <indutny>everything else isn't fully completed
16:01:09  <bnoordhuis>indutny: has ryah ack'd #209?
16:01:30  <bnoordhuis>looks innocent enough though
16:01:36  <indutny>I thought he asked to move all things from node_platform to libuv
16:01:44  <indutny>and node_platform has loadavg
16:02:07  <indutny>test is passing
16:02:10  <indutny>on win+linux
16:02:13  <indutny>+darwin
16:02:24  <indutny>I don't have FreeBSD, nor OpenBSD
16:02:31  <indutny>and Solaris too
16:03:16  <bnoordhuis>indutny: if you want to test against sunos in the future, sign up for a joyent smartmachine
16:03:48  <indutny>bnoordhuis: I tried installing SmartOS in Virtualbox and Vmware
16:03:55  <indutny>I'll try to use smartmachine now
16:03:56  <indutny>:)
16:11:30  <CIA-53>libuv: Fedor Indutny master * r33cb877 / (12 files in 5 dirs):
16:11:31  <CIA-53>libuv: os: implement memory bindings
16:11:31  <CIA-53>libuv: * us_get_free_memory
16:11:31  <CIA-53>libuv: * us_get_total_memory - http://git.io/8wqDwQ
16:11:51  <indutny>great
16:11:54  <indutny>bnoordhuis: thank you
16:12:07  <bnoordhuis>indutny: no, thank you :)
16:15:40  <CIA-53>libuv: Fedor Indutny master * ra35591b / (11 files in 5 dirs): os: implement loadavg (not working on cygwin/win) - http://git.io/Si8yng
16:42:34  * bradleymeckjoined
16:43:58  * erickt_joined
16:44:54  <indutny>installed dtrace on ubuntu
16:45:00  <indutny>not sure what will happen
16:45:01  <indutny>:D
16:45:43  <rmustacc>Uh, you'll probably panic.
16:45:55  <rmustacc>Pretty much the same thing as if you used SystemTap.
16:46:04  <rmustacc>Only it feel smoother and happen quicker with the DTrace one.
16:46:16  <indutny>:)
16:46:17  <rmustacc>The Linux DTrace port is pretty unsafe.
16:46:25  <rmustacc>And not really done in an way.
16:46:27  <rmustacc>*any
16:46:52  <rmustacc>But, don't let that stop you.
16:47:11  <rmustacc>You'll probably find the syscall provider works reliably.
16:47:24  <piscisaureus>But it's about time to port that bitch :-)
16:47:52  <piscisaureus>I mean, it better be done by the time you guys need to make smartos linux-based
16:47:59  <rmustacc>Buahahahaha
16:48:04  <rmustacc>No.
16:48:13  <indutny>:)
16:48:14  <rmustacc>Besides, Oracle is porting DTrace for you.
16:48:23  * pquerna_quit (Changing host)
16:48:23  * pquerna_joined
16:48:27  * erickt_quit (Ping timeout: 244 seconds)
16:48:28  * pquerna_changed nick to pquerna
16:48:31  <rmustacc>Well, at least if the tweets from Open world are anything to go by.
16:51:11  <piscisaureus>rmustacc: at some point you're gonna have to make it linux-based. As soons as Intel adds some new virtualization feature to their architecture, you guys have to put that in smartos yourselves. <-- painful
16:51:24  <piscisaureus>unless oracle does it for you
16:51:40  <rmustacc>Oracle isn't doing it for us.
16:51:51  <piscisaureus>I know
16:52:01  <piscisaureus>That's why you want to be linux-based
16:52:03  <rmustacc>piscisaureus: Sure, but we also have to port a filesystem, a dynamic tracing framework, etc.
16:52:11  <rmustacc>Virtualization is the least of our problems.
16:52:29  <rmustacc>We need a real kernel debugger, CTF, etc.
16:53:23  <rmustacc>There are probably a half dozen more technologies to get stuff working the same way on Linux.
16:53:52  <rmustacc>But honestly, I'd rather we not argue it extensively unless you really want to.
16:54:05  <piscisaureus>rmustacc: :-)
16:54:16  <piscisaureus>rmustacc: I was just trolling a bit
16:54:35  <rmustacc>I know, and I feel compelled to defend.
16:55:12  <rmustacc>Realistically we'd probably port to a bsd before linux.
16:56:01  <piscisaureus>rmustacc: I kind of believe you that your sunos-based solution is much better than what you could have achieved with linux
16:56:11  * erickt_joined
16:56:42  <rmustacc>Thanks. Hopefully that's true and we can get other folks to believe it some day.
16:57:24  <piscisaureus>rmustacc: ... but you'll have to agree with me that mainaining an entire OS with a handful of people may not be sustainable in the long term
16:58:29  <piscisaureus>anyway
16:58:43  <piscisaureus>let me get back to my own business :-)
17:00:24  * erickt_quit (Client Quit)
17:02:18  * igorziquit (Ping timeout: 252 seconds)
17:14:21  * igorzijoined
17:23:22  * stagasjoined
17:23:43  <igorzi>piscisaureus: http://msdn.microsoft.com/en-us/library/ff824013(v=vs.85).aspx
17:23:44  <stagas>how is node going to handle unix sockets in the windows build?
17:24:01  <igorzi>piscisaureus: that's the lsp that sits on winsock on my dev box
17:24:47  * CoverSlidejoined
17:26:44  <igorzi>stagas: on windows we use named pipes
17:27:38  <stagas>igorzi: is it going to be compatible with stuff written for unix sockets?
17:29:03  <bradleymeck>named pipes dont live on the fs, so I would doubt 100% compatibility
17:29:47  <CoverSlide>how are named pipes declared in Windoze?
17:29:53  <stagas>so everything will need to have a unix and a windows version to work?
17:30:12  <bradleymeck>http://msdn.microsoft.com/en-us/library/windows/desktop/aa365590(v=vs.85).aspx for more info
17:30:27  <bradleymeck>stagas not really, just have a different path when you open it
17:30:48  <bradleymeck>ironically you can use createfile to open up a namedpipe, just it cant be all over the fs
17:31:04  <igorzi>stagas: you will need to change the name of the pipe (on windows the name needs to start with "\\.\"). beyond that the node api should be the same. (using net module)
17:31:42  <CoverSlide>hmm will forward slash / backslash switching be automatic?
17:31:51  <igorzi>bradleymeck: named pipes are implemented in net module in node
17:33:02  <bradleymeck>yep, but i was just talking even if we use em we wont have 100% the same behavior since we cant much around with them on the module directory, permissions?, etc.
17:33:13  <stagas>igorzi: so whenever I open a socket like that I'd need to do: server.listen(windows ? windowsPath : unixPath);
17:33:15  <igorzi>CoverSlide: no, we decided against making that automatic, since most likely you'll be connecting to an existing application (e.g. mysql), so you'll need to specify a very specific pipe name
17:33:51  <igorzi>stagas: yeah, pretty much
17:34:25  * wankdankerjoined
17:34:52  * wankdankerpart ("Konversation terminated!")
17:35:28  <isaacs>hey, can we add process.stdout.flush()? even if it's a noop
17:36:00  <stagas>life was easier with the cygwin build
17:36:02  <stagas>:)
17:36:06  <isaacs>your life maybe :)
17:36:22  <isaacs>ryah: a lot of programs call stdout.flush(). it'd be nice if it didn't throw
17:37:16  <stagas>how hard is it to maintain a node cygwin build?
17:37:23  <stagas>where can I vote? :)
17:37:43  <CoverSlide>stagas: try it and see
17:38:01  <bradleymeck>since cygwin is not 100% and dlls are hell inside it... eventually pretty hard i would bet as more and more modules target windows
17:38:07  <CoverSlide>node is forkable
17:39:15  <ryah>isaacs: agreed
17:39:32  <isaacs>ryah: is the sync stdout stuff there yet?
17:39:37  <ryah>no
17:39:43  <ryah>https://plus.google.com/u/0/115094562986465477143/posts/VZJbdwwfiAD <-- rob pike commented on my blog
17:41:24  * erickt_joined
17:41:47  <isaacs>wowzers
17:47:07  <ryah>why can't you link to individual comments? grr..
17:47:08  <bradleymeck>fancy, and i agree (only after much time spent frustrated at some of those features).
17:52:23  <piscisaureus>stagas: bradleymeck: igorzi: there is an issue with named pipes that make it different, which is that pipes don't support shutdown()
17:52:28  * brsonjoined
17:52:49  <piscisaureus>(so you can't do graceful shutdown)
17:53:48  <bradleymeck>piscisaureus i think most people will just use a random port unless they need the permissions stuff on either once both are needing support
17:53:55  <bradleymeck>going to be interesting for npm though...
17:54:16  <bradleymeck>did you get a chance to look at the dll stuff?
17:54:31  <piscisaureus>no
17:56:03  <piscisaureus>call in 4
17:56:20  <piscisaureus>bradleymeck: I will do it tomorrow though
17:56:36  <piscisaureus>actually planned it for today but I was too messed up
17:56:57  <bradleymeck>no rush, im learning that it might just be a problem with using templates in general in plugin dlls after i did some reading
18:03:47  <piscisaureus>bradleymeck: I don't think you can really export templates in a dll. But it should be possible to export classes generated from templates.
18:04:00  <piscisaureus>I don't know how that works though
18:04:17  <piscisaureus>ryah: igorzi: bnoordhuis: no call?
18:04:43  <igorzi>piscisaureus: i'm the only one on the call..
18:04:46  <bradleymeck>yes and there in lies the problem X<Y> can be exported, but you cannot make a new template X<Z> from the plugin dll, this means ObjectWrap is pretty f'ed as well as any odd thing from v8
18:04:51  <piscisaureus>igorzi: I have this music
18:04:53  <piscisaureus>:-(
18:05:33  * bnoordhuisdials in
18:07:57  <piscisaureus>bradleymeck: I think the templates are actually in the header file so the user should just be able to generate it
18:08:05  <bnoordhuis>the leader has not yet joined
18:08:09  <bnoordhuis>followed by new age music
18:08:10  <piscisaureus>I have that too
18:08:14  <igorzi>me too
18:08:31  <igorzi>i think claudio is not calling in today..
18:08:38  <piscisaureus>hmm
18:08:44  <piscisaureus>in that case we should skype right?
18:08:51  <bnoordhuis>yep, let's
18:09:09  <piscisaureus>or someone other than claudio should be the leader :-)
18:09:16  <piscisaureus>igorzi, can't you do it?
18:09:27  <igorzi>i tried, it's asking me for a pin :)
18:09:47  <piscisaureus>okay, let's skype
18:10:02  <piscisaureus>besides us and ryah, who else should be on the call
18:10:05  <piscisaureus>?
18:11:08  <bnoordhuis>no one
18:12:49  <bnoordhuis>piscisaureus, you skype guru - why don't you start the call?
18:13:00  <piscisaureus>yes
18:14:10  <bnoordhuis>ryah: call
18:15:39  <ryah>oh shit
18:32:17  <ryah>let's just talk here
18:32:22  <piscisaureus>yay
18:32:31  <bnoordhuis>re rip out http1: yes
18:32:39  <ryah>so i think we should rip out http1
18:32:48  <piscisaureus>yes +1
18:32:51  <bnoordhuis>say the word and i'll nuke it
18:32:55  <ryah>do it
18:32:59  * bnoordhuisdoes it
18:33:00  <indutny>ryah: http://habrahabr.ru/blogs/nodejs/129766/
18:33:04  <ryah>i want to pull out src/node_stdio_win32
18:33:10  <piscisaureus>I will do it
18:33:16  <piscisaureus>I also want to rip out cygwin
18:33:18  <ryah>also lib/tty_win32.js
18:33:23  <piscisaureus>because it's not working anyway
18:33:30  <ryah>also lib/tty_posix.js
18:33:53  <ryah>indutny: two underscores for __C99_FEATURES__
18:34:01  <indutny>that's not mine
18:34:04  <ryah>oh
18:34:05  <piscisaureus>ryah: you mean, rip out legacy stdio entirely
18:34:10  <indutny>haha :)
18:34:20  <indutny>I'm not translating everything you write :)
18:34:23  <piscisaureus>igorzi: we're talking here now
18:34:32  <indutny>hasn't translated anything yet, actually
18:38:09  <CoverSlide>chrome is like the Farscape equivalent of `translator microbes`
18:53:05  <CIA-53>node: Ben Noordhuis master * rbc7cfd7 / (6 files in 2 dirs): http: remove legacy http library - http://git.io/vGNKRA
18:54:09  <ryah>bnoordhuis++
18:54:28  <ryah>Showing 6 changed files with 417 additions and 2,341 deletions.
18:54:43  <piscisaureus>omg I gotta go rip out something
18:55:05  <bnoordhuis>git doesn't track the rename all that great but oh well
18:55:16  <piscisaureus>ryah: you want to get rid of tty-legacy entirely?
18:55:27  <piscisaureus>ryah: or just rename tty_posix to tty_legacy?
19:00:45  <bnoordhuis>http://news.ycombinator.com/item?id=3070382 <- people comparing the GIL to the BKL
19:01:03  <bnoordhuis>if you don't know what you're talking about, maybe you should just stfu
19:01:20  <bnoordhuis>HN has really been going downhill in the last year :(
19:03:27  <ryah>piscisaureus: entirely
19:04:21  <ryah>sigh
19:04:24  * igorziquit (Ping timeout: 252 seconds)
19:04:28  <ryah>im being forced to write a blog post now
19:04:49  <indutny>:)
19:09:10  <indutny>pquerna: yt?
19:18:16  <indutny>pquerna: https://gist.github.com/459ff6756754f96c226a
19:18:32  <indutny>why openssl discards it w/o any error?
19:19:58  <indutny>there's nothing in spec about using duplicate hello extensions
19:20:28  * mralephjoined
19:21:22  <indutny>pquerna: however, when requesting this server with chrome I see following:
19:21:22  <indutny>(node SSL) error:140940F5:SSL routines:SSL3_READ_BYTES:unexpected record
19:24:08  <bnoordhuis>indutny: it's a tls 1.2 thing, i think
19:24:28  <indutny>bnoordhuis: what?
19:24:30  <indutny>message?
19:25:22  <bnoordhuis>indutny: openssl's tls 1.1 implementation simply ignored unknown message types
19:25:31  <bnoordhuis>but tls 1.2 actively rejects them
19:25:49  <indutny>bnoordhuis: ah, but it knows SNI
19:26:08  <indutny>bnoordhuis: it seems to become wild once it sees second SNI
19:28:13  <indutny>ah: There MUST NOT be more than one extension of the same type.
19:28:15  <indutny>fck
19:28:34  <indutny>how can I pass my data with ClientHello
19:35:33  <bnoordhuis>indutny: i don't think openssl exposes that functionality to openssl consumers
19:35:57  <indutny>bnoordhuis: i'm not using openssl for passing data
19:36:10  <indutny>bnoordhuis: but I need openssl to parse this data and not throw anything
19:36:39  <bnoordhuis>hmm, i don't think openssl will let you get away with that
19:36:42  <bnoordhuis>but let me check
19:38:05  <indutny>bnoordhuis: thanks, looks like I'll remove SNI if it exists and replace it with my own
19:38:22  <indutny>bnoordhuis: that should be simplier than anything other
19:40:45  <bnoordhuis>indutny: i think you're out of luck as far as openssl goes
19:40:50  <indutny>yeah
19:40:54  <indutny>I saw code too
19:41:02  <indutny>and every other variant will fail
19:41:15  <indutny>no hope for custom extensions or anything
19:43:43  <indutny>bnoordhuis: thanks, anyway
19:43:44  <indutny>:)
19:43:51  <bnoordhuis>indutny: np
19:44:45  <pquerna>er, what are you trying to do with the extension?
19:44:55  <pquerna>both sides MAC the contents of the handshake...
19:45:01  <pquerna>to prevent MITM of the handshake
20:05:08  <ryah>bnoordhuis: can we skype?
20:05:20  <bnoordhuis>ryah: sure
20:11:43  * bradleymeckquit (Quit: Leaving)
20:12:04  * bradleymeckjoined
20:12:34  <ryah>bnoordhuis: oops sorry for hanging up on you :)
20:12:47  <bnoordhuis>ryah: no problem :)
20:21:06  * igorzijoined
20:44:40  <igorzi>WSAIoctl(SIO_GET_EXTENSION_FUNCTION_POINTER) is not a syscall. so, I'll just do it on-demand for each socket. for a server we'll only do it once (since it just needs AcceptEx pointer)
20:44:52  <igorzi>piscisaureus ---^
20:51:41  * erickt_quit (Quit: erickt_)
21:09:42  <piscisaureus>igorzi: \o/
21:10:05  <piscisaureus>well... I'm not really happy about it but at least it's somewhat solvable
21:26:09  <ryah>bnoordhuis: merge kqueue?
21:26:24  <bnoordhuis>ryah: right on
21:29:32  <CIA-53>libuv: Ben Noordhuis master * r8e9a338 / (14 files in 5 dirs):
21:29:33  <CIA-53>libuv: unix: implement kqueue file watcher API
21:29:33  <CIA-53>libuv: kqueue fds are not embeddable into other pollsets (select, poll, kqueue).
21:29:33  <CIA-53>libuv: Hack the libev event loop to receive kqueue events with filter flags intact. - http://git.io/c765kw
21:36:09  <igorzi>ryah: can i push the windows ipc impl into the ipc branch?
21:37:21  <CoverSlide>??
21:37:32  <CoverSlide>node is adding native ipc?
21:38:06  <ryah>igorzi: yes
21:39:44  <igorzi>CoverSlide: fd-passing between node processes
21:44:38  <CIA-53>libuv: Ryan Dahl ipc * r0d20e0e / src/unix/stream.c :
21:44:38  <CIA-53>libuv: unix: return UV_UNKNOWN_HANDLE when read2 doesn't recv one
21:44:38  <CIA-53>libuv: unix passes ipc test on this comment. - http://git.io/6IVtUg
21:45:14  <ryah>igorzi: thanks for taking of the test for me
21:45:29  <ryah>seems it's working now
21:45:38  <ryah>i kind of hate this uv_write2 api, but whatever
21:46:36  <ryah>igorzi: i'd like to merge ipc into master now and upgrade node
21:46:51  <ryah>er upgrade libuv in node
21:47:15  <igorzi>ryah: ok.. we can just add stubs for the new apis
21:47:35  <igorzi>ryah: the windows stuff will be ready shortly
21:48:08  <ryah>i'll wait. starting on node bindings for the fd passing now.
22:40:16  <ryah>http://blog.nodejs.org/2011/10/04/an-easy-way-to-build-scalable-network-programs/
22:41:06  <piscisaureus>waiting for something to RT now :-0
22:44:09  * mralephquit (Quit: Leaving.)
22:45:03  * bradleymeckquit (Ping timeout: 248 seconds)
22:49:38  <piscisaureus>http://groups.google.com/group/nodejs/msg/3c3113093f1a2a96
22:51:27  <CoverSlide>holy cow
22:51:31  <CoverSlide>--balance
22:51:51  <CoverSlide>how sweer
22:53:27  <CoverSlide>is that gonna be in 0.6.x or is that for 0.7.x ?
22:53:50  <piscisaureus>I don't think it'll make it for 0.6
22:54:00  <piscisaureus>But we should not take so long to get 0.8 done
22:54:10  <piscisaureus>or whatever comes after .6
22:54:13  <CoverSlide>so basically, it makes cluster more-or-less obsolete?
22:54:19  <piscisaureus>yes
22:54:36  <CoverSlide>dayum
22:54:43  <CoverSlide>me rikey
22:56:36  <ryah>v0.5 will be feature complete by friday
22:56:42  <ryah>and will not include --balance
22:57:34  <ryah>after v0.6 i'd like to start matching the chrome release cycle
22:57:38  <ryah>i.e. 6 weeks
23:30:53  * indexzerojoined
23:33:06  <ryah>> process.versions.ares
23:33:07  <ryah>'1.7.5-DEV'
23:33:11  <ryah>^-- why DEV?
23:40:31  <ryah>indutny: uv_get_free_memory is broken on darwin
23:40:54  <ryah>the sysconf(_SC_PAGESIZE)
23:41:51  <ryah>nevermind - just misisng one header
23:44:43  <CIA-53>libuv: Ryan Dahl master * rb590e12 / src/unix/darwin.c : Fix darwin build - http://git.io/EjxAvw
23:48:39  <CIA-53>libuv: Erick Tryzelaar master * r65fa887 / src/win/udp.c : win: Fix error message. - http://git.io/GmJ3dg
23:48:39  <CIA-53>libuv: Erick Tryzelaar master * re3f2631 / (4 files in 3 dirs): unix: bad connect addresses should error with EINVAL - http://git.io/bw-ILQ
23:48:39  <CIA-53>libuv: Erick Tryzelaar master * r85368e8 / (src/unix/tcp.c src/uv-common.c src/uv-common.h src/win/tcp.c): unix,win: Start unifying shared tcp connect code. - http://git.io/PiKjZA
23:48:40  <CIA-53>libuv: Erick Tryzelaar master * r4c32906 / (6 files in 3 dirs): unix,win: Start unifying shared bind code. - http://git.io/NpMHeg
23:48:40  <CIA-53>libuv: Erick Tryzelaar master * r0303197 / src/win/udp.c :
23:48:40  <CIA-53>libuv: win: unify uv_{tcp,udp}_set_socket.
23:48:41  <CIA-53>libuv: Fixes #205. - http://git.io/A7X5cg
23:48:48  <ryah>erickt: thank you. sorry that took so long
23:55:41  <ryah>ryan@mac1234:~/projects/node% ./node test/simple/test-fs-watch.js
23:55:41  <ryah>ryan@mac1234:~/projects/node% echo $?
23:55:41  <ryah>0
23:55:43  <ryah>very nice
23:56:13  <CIA-53>node: Ryan Dahl master * r627f379 / (31 files in 8 dirs): upgrade libuv to 0303197 - http://git.io/cekMoQ
23:57:26  <bnoordhuis>ryah: re why DEV: i `git archive`-d 1.7.5 from the c-ares git repo
23:59:26  <piscisaureus>I am going
23:59:59  <bnoordhuis>piscisaureus: when you gotta go, you gotta go