--- Log opened Tue Sep 04 00:00:17 2012
00:39 <@piscisaureus_> ok
00:40 <@piscisaureus_> time to sleep
00:40 <@piscisaureus_> I see bnoordhuis already snuck out of here even.
00:40 < tjfontaine> sneaky bastard
00:41 <@piscisaureus_> you bet, mister
06:25 < ibobrik> hi there. can anyone explain this to me? https://gist.github.com/3617558
06:30 <@indutny> ibobrik: spagetti code?
06:30 < ibobrik> this is just an example
06:30 <@indutny> meh
06:31 <@indutny> downloading
06:33 <@indutny> ibobrik: do you see WTF?!
06:33 < ibobrik> yep
06:33 < ibobrik> from time to time
06:33 <@indutny> ibobrik: can't reproduce it on osx
06:34 <@indutny> ibobrik: what if you'll do fs.writeSync?
06:34 < mmalecki> 8 spaces?
06:34 < ibobrik> stupid textmate :)
06:34 < mmalecki> actually, those are tabs
06:35 < ibobrik> i can't reproduce on osx too, but linux box shows wtfs
06:35 < ibobrik> indutny: do you have linux to check it?
06:35 <@indutny> ibobrik: yeah, in VM
06:36 <@indutny> one sec
06:36 <@indutny> ibobrik: no wtfs for me
06:36 <@indutny> ibobrik: on ubuntu
06:36 <@indutny> ibobrik: in vbox
06:37 <@indutny> ibobrik: are you on SSD drive?
06:37 < ibobrik> no, spinning disks
06:37 < ibobrik> i tried 2 gentoo servers and 1 debian - all affected
06:37 < ibobrik> at leas after 20 tries
06:37 <@indutny> ibobrik: ok, so one thing that we can check
06:37 <@indutny> ibobrik: can you .fill('\0') your buffers
06:38 <@indutny> ibobrik: and paste what WTF will print
06:38 <@indutny> and use bigger slice
06:38 <@indutny> like (0, 40)
06:39 < ibobrik> this will not work. how can i compare buffers then?\
06:40 <@indutny> ibobrik: well, just use slices when logging
06:40 <@indutny> ibobrik: I want to see what happens
06:40 < ibobrik> 1kb of \0 is equal to another 1kb of \0
06:40 < ibobrik> always
06:40 < ibobrik> i suppose
06:40 <@indutny> ibobrik: well it should not be
06:40 <@indutny> according to your example
06:40 < ibobrik> test.toString("base64") != buf(size).toString("base64"))
06:40 <@indutny> and?
06:40 <@indutny> that's what I told
06:41 <@indutny> just fill your buffers before read and write
06:41 < ibobrik> no wtfs so far
06:41 <@indutny> ah
06:41 <@indutny> oh, I see now
06:41 <@indutny> ok
06:44 <@indutny> ibobrik: but only on ubuntu
06:45 < ibobrik> i have gentoo and debian, same results
06:45 <@indutny> i.e. linuxes
06:48 < ibobrik> yep. is this kind of bug?
06:48 <@indutny> it's hard to tell
06:49 <@indutny> probably
06:49 <@indutny> well
06:49 <@indutny> actually, it it's not a bug when read is called w/o setTimeout
06:50 <@indutny> and setTimeout doesn't guarantee that all executed writes was finished
06:50 < ibobrik> strafe output says that all pwrites finished before preads
06:50 < ibobrik> strace*
06:50 <@indutny> yeah, I see it too
06:50 <@indutny> hm...
07:07 < ibobrik> should i make an issue at github?
07:13 <@indutny> ibobrik: yeah
07:13 <@indutny> ibobrik: cc bnoordhuis there
07:19 < ibobrik> should i make nodes or libuv issue?
07:19 < ibobrik> nodejs*
07:21 < ibobrik> https://github.com/joyent/libuv/issues/544
07:34 <@indutny> ibobrik: thanks
07:35 <@indutny> ibobrik: btw
07:36 <@indutny> ibobrik: it  seems to be happening only with uninitialized buffer
07:37 <@indutny> ibobrik: I think there's something with node.js
07:37 <@indutny> ibobrik: so probably it would be better to move issue to it
07:42 <@indutny> oooh
07:42 <@indutny> ibobrik: also node seems to be pwriting from 2 thread simultaneously
07:42 <@indutny> ibobrik: this is definitely bad
07:44 <@indutny> ircretary: tell bnoordhuis to ping me
07:44 < ircretary> indutny: I'll be sure to tell bnoordhuis
07:51 <@indutny> ibobrik: yt?
07:51 <@indutny> ibobrik: what if you'll try to write 4096 bytes maximum?
08:03 < ibobrik> same results
08:10 < ibobrik> indutny: but buffer initialization helped
08:11 < ibobrik> indutny: as far as i can see. this is weird
08:15 < ibobrik> indutny: i have no idea how to "initialize" buffers that came from http request body btw
08:16 <@indutny> ibobrik: they should be already initialized I guess
08:16 <@indutny> but that's definitely a bug
08:16 <@indutny> at least as far as I can see
08:18 < ibobrik> indutny: i don't understand why pwrite even bother about calculating offsets when i give offset explicitly
08:18 <@indutny> ibobrik: that's not the case
08:18 <@indutny> you're writing more than PIPE_BUF data
08:19 <@indutny> and when doing so pwrite is not atomic
08:24 <@indutny> so that seems to be a libuv bug
08:24 <@indutny> even eio bug
08:25 < ibobrik> indutny: hm, this is buggy too: https://gist.github.com/3618478
08:26 < ibobrik> indutny: 100 writes < 4096 - same result
08:26 <@indutny> ok
08:26 <@indutny> something I'm missing there
08:26 <@indutny> definitely
10:28 < bnoordhuis> indutny: what's up?
10:34 <@indutny> bnoordhuis: hey man
10:34 <@indutny> bnoordhuis: writes are not overlapping
10:34 <@indutny> bnoordhuis: and more interestingly
10:34 <@indutny> bnoordhuis: filling buffers with data helps
10:34 <@indutny> bnoordhuis: even with a random data
10:35 < bnoordhuis> indutny: looking at the strace output, they seem to overlap
10:35 <@indutny> bnoordhuis: they should not
10:36 <@indutny> bnoordhuis: offset is increased by buffer length
10:38 < bnoordhuis> he's writing at the end of the file right?
10:39 < bnoordhuis> wait, i'll explain it in the issue
10:40 <@indutny> ok
10:44 < bnoordhuis> indutny: https://github.com/joyent/libuv/issues/544#issuecomment-8258839
10:44 < bnoordhuis> i.e. it's not a bug
10:44 < bnoordhuis> or rather, not a bug in libuv
10:45 <@indutny> bnoordhuis: oviously
10:45 <@indutny> obviously
10:45 <@indutny> the thing is that we're doing parallel pwrites
10:45 <@indutny> while we surely know that pwrite won't work correctly when called from multiple threads
10:45 < bnoordhuis> oviously... copiously egg-like?
10:46 < bnoordhuis> at worst it's a documentation issue
10:46 < bnoordhuis> i think we document it for node, maybe not libuv
10:47 <@indutny> ok
10:47 <@indutny> it's just odd that it happens concurrently
10:48 <@indutny> because it should not
10:48 < ibobrik> i see 2 solutions: 1. pre-allocating the whole big file before writing, 2. sticking fd to one io thread that will make linear pwrite calls one-after-another
10:51 < ibobrik> and 3. make write queue for every file in my own node.js code
11:10 <@indutny> bnoordhuis: Assertion failed: (handle->flags & UV_CLOSING), function uv__finish_close, file ../deps/uv/src/unix/core.c, line 129.
11:10 <@indutny> I like this! :)
11:25 <@indutny> bnoordhuis: why is this happening?
11:34 <@piscisaureus_> bnoordhuis: pwrite from multiple threads *should* be safe... we're doing it in node too
11:34 <@indutny> piscisaureus_: it isn't
11:34 <@piscisaureus_> oh - we're not doing it in node
11:35 <@piscisaureus_> indutny: so what's happening?
11:35 <@piscisaureus_> indutny: data gets written at the wrong place?
11:35 <@indutny> piscisaureus_: it's writing junk :)
11:35 <@indutny> piscisaureus_: yeah, sort of
11:35 <@piscisaureus_> indutny: so what it is - junk, or at the wrong place?
11:35 <@indutny> idk
11:35 <@indutny> but when you initalize buffers
11:35 <@indutny> everything seems to be fine
11:36 <@piscisaureus_> huh
11:36 <@piscisaureus_> indutny: which buffers?
11:36 <@piscisaureus_> indutny: so you're writing uninitialized memory and complaining that junk ends up in the file?
11:36 <@indutny> https://gist.github.com/3617558
11:36 <@indutny> piscisaureus_: well, not me
11:36 <@indutny> but the thing is I comparing read data to what was written
11:37 <@indutny> and I expect it to be equal
11:49 < bnoordhuis> CIA-130 doesn't even say bye? the nerve
11:59 <@indutny> bnoordhuis: meh
11:59 <@indutny> bunch of xml stuff
11:59 < bnoordhuis> indutny: xml? that's the new json, right?
11:59 <@indutny> oh, do not remind me about it
12:00 < ibobrik> bnoordhuis, indutny: https://gist.github.com/3620592 sequential writes, corrupted file from time to time :(
12:00 <@indutny> ha
12:00 <@indutny> I knew it!
12:07 < ibobrik> i've updated libuv issue #544
12:42 < CIA-129> node: Ben Noordhuis master * r83b1dda / (src/node.cc test/simple/test-cli-eval.js): cli: make argument to -p optional - http://git.io/_ff9Og
12:42 < CIA-129> node: Ben Noordhuis master * r19a4322 / test/simple/test-cli-eval.js : test: add extra checks in simple/test-cli-eval - http://git.io/r7sx8g
13:12 < CIA-129> node: Ben Noordhuis master * r2efa3ae / tools/install.py : installer: reapply b21c8e0b, honor --without-npm (+17 more commits...) - http://git.io/xhZiiA
13:16 < CIA-129> node: Bert Belder issue3964 * r9236230 / (56 files in 5 dirs): doc: don't use &apos; - http://git.io/ORYVNg
13:18 < bnoordhuis> piscisaureus: is the company meeting this friday?
13:18 <@piscisaureus_> bnoordhuis: yup
13:22 < CIA-129> node: Bert Belder issue3964 * r35d1da1 / (15 files in 2 dirs): doc: don't use &apos; - http://git.io/XWOdHA
13:26 < bnoordhuis> ^ that guy
13:26 < bnoordhuis> he didn't say where exactly he ran into &apos;
13:26 < bnoordhuis> i assume it's the blog but who knows
13:26 <@piscisaureus_> yeah
13:26 <@piscisaureus_> I don't know either
13:26 < bnoordhuis> also, IE
13:26 <@piscisaureus_> It was a poor bug report
13:27 <@piscisaureus_> bnoordhuis: BUT &#39 is smaller than &apos
13:27 <@piscisaureus_> LESS IS MOAR
13:28 <@piscisaureus_> CAPSLOCKBOT is really stoic today
13:28 <@piscisaureus_> HELLO CAPSLOCKBOT HOW ARE WE DOING TODAY?
13:29 < NUMLOCKBOT> 1 4M F1N3
13:53 <@piscisaureus_> bnoordhuis: how do you feel about that &apos patch btw? throw away or land?
13:57 < bentkus> Who wants to write an irc server in C? xD
13:59 < tjfontaine> bentkus: btdt
14:04 < bentkus> btdt?
14:04 < bentkus> with libuv?\
14:04 < CIA-129> node: Timothy J Fontaine master * rd3135e0 / (configure tools/gyp_node): build: add configure option to build with ninja - http://git.io/Ylh98g
14:04 < CIA-129> node: Ben Noordhuis master * r7b6d3ce / (Makefile configure): build: add ninja support to Makefile - http://git.io/afPQnA
14:06 < tjfontaine> bentkus: homegrown event loop, libevent, and we're currently doing on based on libuv
14:06 < bentkus> github link plz?
14:06 < tjfontaine> bentkus: still quite young http://github.com/oftc/oftc-ircd
14:07 < bentkus> is it a branch of the oftc server?
14:07 < bnoordhuis> piscisaureus_: land, doesn't hurt
14:07 < tjfontaine> bentkus: no oftc currently runs on oftc-hybrid
14:08 < bnoordhuis> ninja is nice
14:08 < bentkus> beafy server
14:08 < bnoordhuis> the build system, that is, not the killers for hire
14:09 < tjfontaine> killers are pretty awesome too, so long as they're not after you
14:09 < bnoordhuis> i don't know, i'd be worried about mixups
14:10 < bnoordhuis> i mean "oh sorry, wrong bloke - won't happen again" after the fact is little consolation
14:10 < tjfontaine> quite
14:11 < bnoordhuis> okay, time to take the wife out for a walk
14:25 < CIA-129> node: Bert Belder issue3964 * r12e327d / (18 files in 4 dirs): doc: don't use &apos; - http://git.io/EEDYtA
14:46 < ibobrik> indutny: i finally found it. "a+" is evil
14:46 <@indutny> oh
14:47 <@piscisaureus_> still weird tho
14:47 <@piscisaureus_> what flags does it translate to
14:47 <@piscisaureus_> O_RDWR | O_APPEND ?
14:47 <@indutny> I think so
14:48 <@piscisaureus_> looks like a linux bug to me to be honest
14:48 < ibobrik> wait a minute
14:48 < ibobrik> linux for sure
14:49 <@indutny> piscisaureus_: sure, if they used kqueue this bug wouldn't happen!
14:50 <@piscisaureus_> har har
14:50 <@indutny> s/r//g
14:50 < ibobrik> https://gist.github.com/3621892
14:51 < ibobrik> with r+ everything is okay
14:56 < ibobrik> indutny: this should not happen, should it? i mean "a+" behavior
16:13 <@piscisaureus_> https://github.com/blog/1227-status-api <--
16:13 <@piscisaureus_> wanted
16:13 <@piscisaureus_> for both CLA and Travis
16:13 <@piscisaureus_> the current Travis comments are kinda noisy
16:14 < tjfontaine> seems like travis is already configured to use it
16:21 <@piscisaureus_> https://github.com/joyent/libuv/pull/546 <-- we'll find out soon
16:30 < NUMLOCKBOT> cd /media/
16:30 < NUMLOCKBOT> ls
16:30 < tjfontaine> NUMLOCKBOT: by the way that terminal has irssi running
16:30 < tjfontaine> oh damn.
16:32 <@piscisaureus_> tjfontaine: ya that was just me. sorry
16:32 < tjfontaine> I know :)
16:34 < piscisaureus> tjfontaine: irssi should just print a big warning: 
16:34 < piscisaureus> "noooooo this is not bash:
16:35 < tjfontaine> heh, there's scripts/plugins so that you can have a terminal window in your irssi
16:35 <@piscisaureus> ghe
16:35 <@piscisaureus> how incredibly backwards
16:35 < tjfontaine> welcome to FOSS :)
19:09 <@indutny> bnoordhuis: ok man
19:09 <@indutny> fuck openssl patching
19:09 <@indutny> better rewrite it
19:09 <@indutny> meanwhile
19:09 <@indutny> lets pull that async tls session stuff in :)
19:16 < CIA-129> node: Bert Belder v0.8 * r6174ea6 / (16 files in 3 dirs): doc: don't use &apos; - http://git.io/QHUt6w
19:17 < bnoordhuis> indutny: i like the idea of rewriting openssl
19:17 < bnoordhuis> can you have it finished by four?
19:17 <@indutny> bnoordhuis: yeah, I've already started it
19:17 <@indutny> bnoordhuis: four what?
19:17 <@indutny> July?
19:17 < bnoordhuis> four am?
19:17 < tjfontaine> oclock
19:17 <@indutny> only July 4th
19:17 < bnoordhuis> pquerna was working on that
19:18 < bnoordhuis> using openssl for crypto but doing everything else async
19:18 <@indutny> bnoordhuis: no, he wasn't
19:18 <@indutny> yeah
19:18 <@indutny> only async stuff
19:26 <@indutny> I want to say
19:26 <@indutny> I love you guys
19:26 <@indutny> you're so awesome
19:27 < bnoordhuis> hah, where does that come from?
19:27 <@TooTallNate> indutny: you are loved back
19:35 <@piscisaureus_> maybe polarssl?
19:36 <@indutny> oh, yeah
19:36 <@indutny> I remember it!
19:36 <@indutny> but unfortunatelly it's not async
19:38 <@indutny> actually, I think I may repeat that off-loading-to-threads tls handshake experiment
19:39 <@indutny> bnoordhuis: https://github.com/joyent/node/pull/3661
19:39 <@indutny> updated
19:48 <@indutny> bnoordhuis: ?
20:08 < bnoordhuis> indutny: ?
20:09 < CIA-129> node: Ben Noordhuis master * r790d651 / (3 files in 3 dirs): http: make http.ServerResponse emit 'end' - http://git.io/N8GP1A
20:09 < pquerna> indutny: on that patch, clientHello always comes first, if you see anything else, shouldn't it just stop/finish() ?
20:10 < pquerna> indutny: hrm
20:12 < pquerna> indutny: what would happen on an session size of 254 say, and then bogus padding data in the extensions area
20:12 < pquerna> indutny: in practice openssl session_size is always.. 32 bytes iirc (should double check)
20:13 < pquerna> indutny: The length of the session id is 16 bytes for SSLv2 sessions and between 1 and 32 bytes for SSLv3/TLSv1
20:16 <@indutny> pquerna: well, I think it's ok to limit it there
20:16 <@indutny> pquerna: not only client hello may come first
20:16 <@indutny> bnoordhuis: review?
20:17 <@indutny> pquerna: like alert protocol
20:17 <@indutny> pquerna: or anything else
20:17 <@indutny> pquerna: this is surely not the case for https stuff
20:17 < bnoordhuis> indutny: my GP advised me to cut back on the number of reviews
20:17 < pquerna> indutny: sure, but in those cases, we should just hand of to openssl?
20:18 < pquerna> like cover the 99% case in a paranoid way
20:18 < pquerna> but don't try to cover it all imo
20:18 < pquerna> tls is a bitch (tm)
20:18 <@indutny> pquerna: hm...
20:18 < pquerna> a client sending a tls alert in the first frame is already F'ed up tbh
20:18 < pquerna> let openssl deal :)
20:19 <@indutny> pquerna: ok
20:19 <@piscisaureus> bnoordhuis: hey
20:19 <@piscisaureus> bnoordhuis: is there any way I can make valgrind stack traces longer?
20:20 < pquerna> indutny: its a neat patch though, i want to port it to apcahe now :)
20:20 <@indutny> pquerna: hahaha
20:20 <@indutny> thanks
20:20 <@indutny> pquerna: what's a use for it in httpd?
20:20 <@indutny> pquerna: I thought you're using thread pool
20:21 < pquerna> indutny: in th event mpm, we could do async memcache for the sessionc ache
20:21 <@indutny> oh
20:21 <@indutny> great
20:21 < pquerna> like keep the socket in accepting in the event loop
20:21 < pquerna> just like in node really :)
20:21 <@indutny> pquerna: sad thing is that tls tickets are widely adopted too
20:21 < pquerna> until IE does it....
20:21 <@indutny> hahaha
20:21 <@indutny> well, with tls tickets we don't need this stuff at al
20:21 <@indutny> s/al/all
20:21 < pquerna> yeah
20:21 < pquerna> its great :)
20:22 <@indutny> yeah, sure
20:22 < pquerna> need to get like, Python using tls tickets
20:22 < pquerna> for all our api clients :(
20:23 <@indutny> haha
20:23 < pquerna> hrm, actually, that would be interesting. I should get a pcap of our inbound API servers TLS connections, analyze what support numbers are for tls session tickets, etc
20:23 < pquerna> its pretty different mix that consumer browsers
20:23 <@indutny> yeah
20:23 <@indutny> that would be good
20:24 <@indutny> it should not be hard to parse this 
20:24 < pquerna> yeah
20:24 < pquerna> todo+=
20:24 < bnoordhuis> piscisaureus: yes, --num-callers=32
20:24 <@indutny> haha
20:24 <@indutny> so, what about APIs for async session storage?
20:24 <@indutny> I don't really like camel case resumeSession
20:24 <@indutny> and newSession
20:24 <@indutny> may be just 'session'
20:25 <@indutny> and a boolean argument
20:25 < bnoordhuis> vetoed
20:25 <@indutny> bnoordhuis: so what?
20:25 < bnoordhuis> so there
20:25 <@indutny> :)
20:25 <@indutny> ok, what's your proposal?
20:25 <@indutny> resumeTlsSession is definitely not shortest thing to type
20:25 <@indutny> and looks awful
20:25 < bnoordhuis> who cares? C-n ftw
20:26 < bnoordhuis> resumeSession is okay
20:26 <@indutny> ok
20:26 <@indutny> will remove Tls from it
20:27 <@indutny> bnoordhuis: are you ok with merging it?
20:28 < bnoordhuis> let me check it one more time
20:28 < bnoordhuis> that's like review round 6, i think?
20:29 < bnoordhuis> indutny: you haven't added any tests
20:29 <@indutny> bnoordhuis: heh
20:29 <@indutny> bnoordhuis: oooook
20:29 <@indutny> lam
20:35 < txdv2> HMMM HAAA
20:36 <@indutny> txdv2: hi
20:47 <@indutny> bnoordhuis: added documentation and test
20:51 < bnoordhuis> what's a decent vnc client for linux these days?
20:55 < tjfontaine> are you looking for something with a pretty gui, or just quality vnc interaction? I mostly still use tight
20:56 < bnoordhuis> oh, just basic vnc functionality, it doesn't have to be pretty
20:56 < bnoordhuis> just installed vinagre, seems to work okay
20:57 < bnoordhuis> tightvnc was my second option though :)
20:57 < mmalecki> I use vinagre
20:57 < tjfontaine> I'm old school
20:59 <@piscisaureus> any nodeconf attendees here?
21:00 <@piscisaureus> er, summercamp
21:00 < AvianFlu> piscisaureus: I'm headed there shortly, but not yet at the camp
21:00 <@piscisaureus> AvianFlu: do you happen to have Mikeal's phone number?
21:00 < AvianFlu> maybe? let me check
21:01 <@indutny> so
21:01 <@indutny> bnoordhuis: lets land it?
21:02 < bnoordhuis> indutny: i haven't reviewed it yet, will do later tonight
21:32 <@indutny> bnoordhuis: ok
21:45 <@indutny> bnoordhuis: I'm thinking about piping inside libuv
21:46 <@indutny> bnoordhuis: like creating a (sort of) socketpair from two streams and processing function
21:46 <@indutny> bnoordhuis: this looks like an API, not a conceptual change
21:46 <@indutny> though may have interesting impacts on how we deal with SSL in node
21:47 <@indutny> for example, we may have both cleartext and encrypted streams in uv and expose only sockets to node
21:47 <@indutny> which sounds really reasonable for me
21:47 <@indutny> bnoordhuis: what do you think?
22:01 < txdv2> ui is such a pain in the ass that nobody is doing it for fun
22:02 <@indutny> bnoordhuis: removed that loop
22:02 <@indutny> bnoordhuis: pushing
22:02 < CIA-129> node: Fedor Indutny master * r8e0c830 / (5 files in 4 dirs): tls: async session storage - http://git.io/0Ungvg
22:03 <@indutny> bnoordhuis: yt?
23:48 < bnoordhuis> indutny: ih
--- Log closed Wed Sep 05 00:00:22 2012