00:00:02  <bnoordhuis>piscisaureus_: btw, what exactly do you need it for?
00:00:02  <TooTallNate>i know there's packages out there that do that...
00:00:05  <mmalecki>that was what I was thinking about :)
00:00:12  * c4miloquit (Remote host closed the connection)
00:00:14  <mmalecki>which config system do you like? nconf?
00:00:23  <piscisaureus_>bnoordhuis: well, my idea is to create a simple array with loop fds
00:00:34  <mmalecki>I'm not sure what is used in npm, config-chain?
00:00:39  <piscisaureus_>bnoordhuis: and walk that list when dispatching a signal
00:00:54  * c4milojoined
00:00:58  <TooTallNate>mmalecki: i try to stick with what npm uses
00:01:01  <piscisaureus_>bnoordhuis: but if I need to expand the array (because a new loop is started) then the array needs to be resized
00:01:27  <TooTallNate>mmalecki: do you have a preference for "disturl" vs. "dist-url"
00:01:27  <bnoordhuis>piscisaureus_: you can't do that from a signal handler
00:01:30  <piscisaureus_>bnoordhuis: but I need to avoid releasing the old array while a signal handler is iterating over it
00:01:42  <piscisaureus_>bnoordhuis: why not?
00:01:44  <TooTallNate>mmalecki: there's just no config flags that currently have "-", so it looks a little werid
00:01:52  <piscisaureus_>bnoordhuis: is for( ;; ) not async signal safe these days?
00:02:06  <mmalecki>TooTallNate: I used dist-url because that seems to be a unix convention, but I have no strong feeling for that
00:02:08  <bnoordhuis>piscisaureus_: no, i thought you meant malloc() from a signal handler
00:02:35  <TooTallNate>mmalecki: in retrospect, people often try --node-dir when it's really --nodedir
00:02:44  <TooTallNate>mmalecki: support for both would be ideal :)
00:02:46  <bnoordhuis>piscisaureus_: but you want to do some compare-and-swap pointer trickery, i presume?
00:02:51  <piscisaureus_>yes
00:02:54  <mmalecki>yeah, I was wondering wtf didn't that work at first.
00:03:15  <mmalecki>TooTallNate: YOU KNOW I STILL NEED SOME SLEEP
00:03:21  <bnoordhuis>piscisaureus_: you don't have to, you can use a volatile sig_atomic_t flag
00:03:30  <mmalecki>meh, can do that
00:03:31  <TooTallNate>mmalecki: get sleep :) your patch lgtm; mergin
00:03:39  <mmalecki>so npm uses npmconf
00:03:41  <piscisaureus_>hmm
00:03:56  <TooTallNate>mmalecki: i think npmconf is a layer on top of another config system though
00:03:58  <bnoordhuis>hmm, wait
00:04:10  <mmalecki>TooTallNate: config-chain
00:04:23  <mmalecki>thanks for merging :)
00:04:51  <bnoordhuis>piscisaureus_: you need to take some care and avoid races or deadlocks
00:04:59  <piscisaureus_>bnoordhuis: yes, I know :-)
00:05:11  <piscisaureus_>bnoordhuis: i want to implement a special type of spinlock
00:06:08  <bnoordhuis>piscisaureus_: there's one issue with signals and locks of any kind, the signal handler can run as the same thread that currently holds the lock
00:06:25  <piscisaureus_>bnoordhuis: I know. Hence, a *special* type of spinlock :-)
00:07:09  <bnoordhuis>piscisaureus_: cool. it's possible, you just need to tread carefully
00:07:55  <piscisaureus_>it's sad that neither pthread_yield nor nanosleep are async signal safe
00:08:05  <piscisaureus_>yet, poll() is ...
00:10:13  <bnoordhuis>piscisaureus_: async safe as in usable from in a signal handler? if you use ppoll(), you can still sleep with nanosecond precision, async safe :)
00:10:48  <piscisaureus_>bnoordhuis: yeah, I considered that. I just think it's odd that poll would be safe but nanosleep isn't ...
00:11:25  <bnoordhuis>piscisaureus_: the motivation is that poll() is always a syscall while nanosleep could be a libc function
00:11:43  <bnoordhuis>it's not always true btw, poll() isn't a syscall on os x iirc
00:15:08  <piscisaureus_>bnoordhuis: sleep() is also safe
00:15:22  <bnoordhuis>is it? okay, bad motivation then
00:16:35  <bnoordhuis>i'll be darned. alarm() is as well
00:16:53  <piscisaureus_>bnoordhuis: it would probably be easiest to just block all signals while updating the thing btw
00:16:58  <piscisaureus_>bnoordhuis: why not just do that?
00:18:26  <piscisaureus_>bnoordhuis: http://www.gnu.org/software/libc/manual/html_node/Why-Block.html#Why-Block
00:18:30  <bnoordhuis>piscisaureus_: inside or outside of the signal handler?
00:18:37  <piscisaureus_>bnoordhuis: outsize
00:18:50  <piscisaureus_>bnoordhuis: block it in uv_signal_start/stop
00:18:57  <bnoordhuis>oh right, that could work
00:19:09  <piscisaureus_>probably even easier :-)
00:20:56  <piscisaureus_>we'd still have to ensure that we don't update any state when the signal handler is already running
00:23:00  * c4miloquit (Remote host closed the connection)
00:23:26  <bnoordhuis>piscisaureus_: that's where the sig_atomic_t comes in
00:23:58  <piscisaureus_>bnoordhuis: haha, well...
00:24:00  <piscisaureus_>bnoordhuis: how?
00:24:31  <piscisaureus_>bnoordhuis: consider the situation where one thread is trying to start a signal handler while 2 others are already running a signal handler
00:24:57  <bnoordhuis>piscisaureus_: the signal handler sets the flag, normal code checks it with while (busy); after blocking signals but before touching the array
00:25:17  <piscisaureus_>bnoordhuis: alright. now think of 2 signal handlers running at the same time
00:25:30  <piscisaureus_>bnoordhuis: you want to do:
00:25:30  <piscisaureus_>signal_handler_running++ ?
00:25:35  <piscisaureus_>bnoordhuis: that's not race free
00:25:43  <bnoordhuis>piscisaureus_: why would you have more than one signal handler touching that array?
00:26:00  <bnoordhuis>piscisaureus_: maybe you should explain what you're trying to do :)
00:26:05  <piscisaureus_>bnoordhuis: well, because 2 signal handlers could run at the same time right?
00:26:13  <piscisaureus_>bnoordhuis: if you have multiple threads
00:26:29  <piscisaureus_>one signal may be delivered to thread A and another could be delivered to thread B at the same tiem
00:27:29  <bnoordhuis>piscisaureus_: you generally let one thread handle signals
00:27:40  <bnoordhuis>piscisaureus_: and block them in the other threads
00:27:50  <bnoordhuis>note to self, i need to do that in the new thread pool
00:27:55  <piscisaureus_>bnoordhuis: I thought you told me that wasn't safe
00:28:28  <bnoordhuis>piscisaureus_: well... not for a library, because it can't assume that all threads cooperate
00:29:04  <bnoordhuis>piscisaureus_: btw, is this for libuv or runjs?
00:29:10  <piscisaureus_>bnoordhuis: libuv
00:29:15  <bnoordhuis>ah okay
00:42:34  * c4milojoined
00:44:45  <piscisaureus_>I suppose it would also be possible to implement locking using read() and dup2() :-)
00:54:48  * ericktquit (Ping timeout: 260 seconds)
00:54:48  <piscisaureus_>bnoordhuis: async signal safe lock https://gist.github.com/3815525. How hard can it be?
00:54:48  <piscisaureus_>(still have to beware of deadlocks - this can be solved with signal blocking)
00:56:12  <bnoordhuis>piscisaureus_: does it actually compile? } (while r < 0 && errno == EINTR);
00:56:22  <piscisaureus_>bnoordhuis: no it was to give you the idea
00:56:25  <piscisaureus_>bnoordhuis: didn't try
00:57:17  <bnoordhuis>piscisaureus_: okay, noted
00:57:26  <bnoordhuis>you swapped the read and write fds btw
00:57:37  <piscisaureus_>bnoordhuis: do you see any conceptual issues?
00:57:48  <piscisaureus_>I may just be overlooking something
00:58:27  <bnoordhuis>piscisaureus_: it looks simple enough. just don't call release twice :)
00:58:47  <piscisaureus_>true
01:01:35  <MI6>joyent/libuv: bnoordhuis created branch reviewme
01:01:42  <bnoordhuis>piscisaureus_: ^
01:01:50  <piscisaureus_>it lacks a link
01:01:55  <tjfontaine>heh
01:01:55  <piscisaureus_>tjfontaine: ^
01:02:18  <tjfontaine>I have to make that link up, so where would you like to be directed?
01:03:03  * travis-cijoined
01:03:03  <travis-ci>[travis-ci] joyent/libuv#753 (reviewme - b77b648 : Ben Noordhuis): The build was fixed.
01:03:03  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/commit/b77b648b0b79
01:03:03  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/2631410
01:03:03  * travis-cipart
01:04:05  <tjfontaine>piscisaureus_: for instance the github dashboard only links to https://github.com/joyent/libuv which doesn't seem so helpful
01:04:44  <tjfontaine>or would you rather https://github.com/joyent/libuv/compare/reviewme
01:05:04  <piscisaureus_>tjfontaine: that, or libuv/commits/<branchname>
01:05:51  <bnoordhuis>tjfontaine: i'd like /compare/<branch>
01:06:02  * TooTallNatequit (Quit: Computer has gone to sleep.)
01:06:11  <tjfontaine>k
01:11:03  * hzquit
01:13:52  <bnoordhuis>okay, off to bed. sleep tight everyone
01:14:42  <piscisaureus_>bnoordhuis: mostly lgtm, take care of the thread safety issue
01:17:34  <piscisaureus_>I'm off to bed too
01:17:37  <piscisaureus_>later peepz
01:18:36  * bnoordhuisquit (Ping timeout: 240 seconds)
01:18:59  <isaacs>THE DIE IS CAST! http://jsconf.com.au/speakers/isaac
01:19:12  <isaacs>I'm on the hook to talk about streams, so i have to actually finish this :)
01:20:03  * MI6quit (Remote host closed the connection)
01:20:14  * MI6joined
01:20:14  <piscisaureus_>australistan
01:20:16  <piscisaureus_>cool
01:27:59  * lohkeyjoined
01:32:35  <c4milo>what's the closest datatype to a unsigned long in V8?
01:32:37  <c4milo>Number?
01:33:00  <tjfontaine>javascript numbers are max of 48bits
01:35:10  <tjfontaine>c4milo: v8.h says NumberValue is a double though
01:35:16  <c4milo>yeah
01:36:03  <c4milo>this is what the ecmascript standard says
01:36:04  <c4milo>primitive value corresponding to a double-precision 64-bit binary format IEEE 754 value
01:36:10  <piscisaureus_>tjfontaine: javascript numbers are doubles
01:37:13  * abraxasjoined
01:37:48  <piscisaureus_>tjfontaine: but they retain integer precision up to 2^53
01:38:10  <tjfontaine>ah that's what I was looking through the rfc for, thanks
01:38:21  <tjfontaine>s/frc/standard/
01:39:14  <piscisaureus_>tjfontaine: the reason is that it has a 52-bit mantissa, plus an extra bit because it has base 2
01:40:49  <tjfontaine>right I just found some mentioning of that
01:44:23  * piscisaureus_quit (Read error: Connection reset by peer)
02:01:28  * ericktjoined
02:25:20  * piscisaureus_joined
02:25:26  * piscisaureus_quit (Client Quit)
02:41:45  * brsonquit (Quit: leaving)
02:59:36  * TooTallNatejoined
03:03:58  * TooTallNatequit (Ping timeout: 245 seconds)
03:06:33  * TooTallNatejoined
03:26:33  * lohkeyquit (Quit: lohkey)
03:53:12  * EhevuTovjoined
04:02:01  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
04:06:24  * mmaleckichanged nick to mmalecki[zzz]
04:41:53  * c4miloquit (Remote host closed the connection)
05:19:57  * MI6quit (Remote host closed the connection)
05:23:31  * Ariaquit (Remote host closed the connection)
05:31:03  * EhevuTovquit (Quit: This computer has gone to sleep)
05:37:29  * ericktquit (Ping timeout: 240 seconds)
05:42:55  * ericktjoined
05:45:53  * sj26quit (Quit: Rainbows!)
05:49:16  * stagasjoined
06:35:51  * ericktquit (Quit: erickt)
06:40:57  * kristatejoined
06:42:04  * kristatequit (Remote host closed the connection)
06:43:42  * mikealquit (Quit: Leaving.)
06:52:23  * rendarjoined
07:26:08  * mikealjoined
07:36:36  * mikealquit (Ping timeout: 260 seconds)
07:55:30  * saghuljoined
08:02:24  * mikealjoined
08:07:09  * mikealquit (Ping timeout: 240 seconds)
08:10:34  * einarosquit (Quit: reboot)
08:22:11  * einarosjoined
08:47:11  * V1joined
08:47:34  * V1changed nick to `3rdEden
09:03:00  * mikealjoined
09:08:06  * mikealquit (Ping timeout: 255 seconds)
09:18:56  * kristatejoined
09:35:39  * AvianFluquit (Remote host closed the connection)
09:54:07  * hzjoined
10:03:31  * mikealjoined
10:08:28  * mikealquit (Ping timeout: 252 seconds)
10:09:48  * stagas_joined
10:10:13  * stagasquit (Ping timeout: 245 seconds)
10:10:25  * stagas_changed nick to stagas
11:04:21  * mikealjoined
11:09:24  * mikealquit (Ping timeout: 246 seconds)
11:20:15  * stagasquit (Ping timeout: 246 seconds)
11:36:09  * mmalecki[zzz]changed nick to mmalecki
12:00:08  * MI6joined
12:04:47  * mikealjoined
12:08:34  * bnoordhuisjoined
12:09:35  * mikealquit (Ping timeout: 244 seconds)
12:09:38  * hzquit (Ping timeout: 272 seconds)
12:19:04  * hzjoined
12:33:30  * c4milojoined
12:36:08  * c4miloquit (Remote host closed the connection)
12:41:49  <MI6>joyent/libuv: Ben Noordhuis master * 2d3760a : unix: fix scandir filter prototype The dirent argument is const on syst - http://git.io/uxBW-w
12:42:34  <bnoordhuis>saghul: ping
12:43:06  <saghul>bnoordhuis back in 15
12:43:14  <bnoordhuis>roger
12:43:16  * travis-cijoined
12:43:16  <travis-ci>[travis-ci] joyent/libuv#754 (master - 2d3760a : Ben Noordhuis): The build was fixed.
12:43:16  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/8399cb1fc366...2d3760a17c58
12:43:16  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/2636361
12:43:16  * travis-cipart
12:43:46  <mmalecki>bnoordhuis: hey, what do you think about using slab allocation here https://github.com/joyent/node/blob/master/src/node_http_parser.cc#L127 ?
12:44:34  <bnoordhuis>mmalecki: show me numbers that show that it matters
12:44:44  <bnoordhuis>because it probably doesn't
12:45:41  <bnoordhuis>mmalecki: that bit of code is only executed when a header field or value is split over two packets
12:45:48  <bnoordhuis>which happens almost never
12:46:49  <mmalecki>bnoordhuis: is everytime I use `curl` against localhost "almost never"?
12:47:19  <bnoordhuis>mmalecki: why does that happen?
12:47:29  <mmalecki>bnoordhuis: I'm talking about Save, not Update
12:47:54  <mmalecki>from what I reckon, Update happens when input is split over two packets
12:48:03  <bnoordhuis>oh wait, that's ryan's code, not mine
12:48:09  <bnoordhuis>in that case anything is possible
12:48:13  <mmalecki>:)
12:48:47  <bnoordhuis>still, numbers first, optimizations second
12:48:55  <mmalecki>sure
12:57:19  <saghul>bnoordhuis pong
13:01:13  <bnoordhuis>saghul: ping
13:01:26  <saghul>bnoordhuis pong2 :-)
13:01:42  <bnoordhuis>saghul: can you run this? gdb out/Debug/run-tests fs_async_sendfile fs_async_sendfile
13:01:49  <bnoordhuis>i'm curious what error you're seeing
13:03:40  <saghul>bnoordhuis http://pastebin.com/eZp5nAYG
13:04:03  <saghul>it may be unrelated, but my pyuv test for sendfile now fails with errno 32
13:04:16  <bnoordhuis>saghul: can you try this? `f 2`, followed by `p *req`
13:04:58  <bnoordhuis>errno 32... that's EPIPE
13:05:13  <saghul>bnoordhuis http://pastebin.com/cj1VbU6U
13:05:26  * mikealjoined
13:05:52  <bnoordhuis>saghul: right, thanks
13:06:19  <bnoordhuis>a fix is in the works :)
13:07:18  <txdv_>bnoordhuis: getting rid of libeio?
13:07:27  <bnoordhuis>txdv_: yep, already done
13:07:45  <txdv_>so you are working towards uv_file_t?
13:07:52  <bnoordhuis>hah, sure
13:07:52  <saghul>bnoordhuis great
13:08:18  <txdv_>so libev is next i guess
13:08:59  <tjfontaine>bnoordhuis: interesting that the github firehose spit out your libuv push but not your node push
13:10:17  * mikealquit (Ping timeout: 246 seconds)
13:12:25  <saghul>bnoordhuis was sendfile previously broken in some weird way? I wonder why my test fails now :-S
13:12:38  <bnoordhuis>saghul: not broken, libeio always emulated i t
13:13:11  <saghul>bnoordhuis hum, I guess I need to dive deeper then
13:13:37  <bnoordhuis>saghul: i know why it's happening, that test tries to sendfile() from one regular file to another
13:14:02  <saghul>bnoordhuis is that not ok?
13:14:14  <saghul>my test does the same
13:14:25  <bnoordhuis>saghul: no, on most platforms sendfile() only supports writing from a regular file to a socket
13:14:53  <bnoordhuis>linux is the only exception, i think, and only since 2.6.33 or 2.6.38 iirc
13:14:53  <mmalecki>bnoordhuis: hm, I can't use SlabAllocator here. I guess I should write my own. should it go to a seperate file?
13:15:23  <bnoordhuis>mmalecki: have you profiled it?
13:15:45  <saghul>bnoordhuis fun. not. then maybe libeio was doing some black magic there? that thing worked on Darwin.
13:15:46  * c4milojoined
13:16:06  <bnoordhuis>saghul: yeah, that's because it never actually called sendfile - it just did a read/write loop :)
13:16:28  <mmalecki>bnoordhuis: nope, not yet
13:16:36  <bnoordhuis>mmalecki: start with that :)
13:16:58  <saghul>bnoordhuis oh, that explains!
13:17:27  <bnoordhuis>saghul: i'll be landing a patch today that falls back to a read/write loop if sendfile fails
13:18:06  <saghul>bnoordhuis cool! question: if the fd on a TCP handle is private, how is this supposed to be used?
13:18:19  <saghul>or is the fd public now?
13:19:11  <bnoordhuis>saghul: you don't use it if you want to be cross-platform
13:19:38  <bnoordhuis>saghul: i assume that relates to sendfile?
13:19:47  <saghul>bnoordhuis yes, sendfile
13:19:57  <bnoordhuis>saghul: we don't have a good story for that yet
13:20:16  <bnoordhuis>we're probably going to add some stream-like api that automatically does the Right Thing
13:20:47  <bnoordhuis>something like uv_stream(uv_handle_t* src, uv_handle_t* dst, size_t nbytes, off_t offset)
13:21:03  <bnoordhuis>(details remain tbd)
13:21:46  <saghul>bnoordhuis sounds awesome :-) I'll just disable that test on platforms other than Linux then
13:22:22  <bnoordhuis>saghul: you should be able to re-enable it later today :)
13:23:33  <saghul>bnoordhuis I'll watch the GitHub feed closely then ;-)
13:24:26  * kristatequit (Remote host closed the connection)
13:25:38  * kristatejoined
13:25:45  <mmalecki>http_bench is unstable as fuck >.<
13:25:51  <rendar>tbd ?
13:25:57  <mmalecki>rendar: to be done
13:26:00  <rendar>i see
13:27:45  * kristatequit (Remote host closed the connection)
13:32:16  * stagasjoined
13:33:01  * kristatejoined
13:33:57  * kristatequit (Remote host closed the connection)
13:35:03  * kristatejoined
13:36:22  * kristatequit (Remote host closed the connection)
13:37:10  * kristatejoined
13:48:52  * kristatequit (Remote host closed the connection)
13:49:19  * kristatejoined
13:51:47  * kristatequit (Remote host closed the connection)
13:52:14  * kristatejoined
13:53:09  * piscisaureus_joined
13:55:21  <piscisaureus_>bnoordhuis: yo
13:55:31  <bnoordhuis>piscisaureus_: sup homie?
13:55:37  <piscisaureus_>bnoordhuis: sendfile emulation - did you fix the race condition?
13:55:40  <piscisaureus_>er
13:55:44  <piscisaureus_>the threadsafety issue
13:55:52  <bnoordhuis>piscisaureus_: yes. and introduced a fork safety issue :)
13:56:10  <piscisaureus_>well, fuck that
13:56:21  <piscisaureus_>bnoordhuis: uv-unix is full of fork-safety issues
13:56:24  <indutny> /usr/bin/env: No such file or directory
13:56:26  <indutny>hm...
13:56:35  <bnoordhuis>piscisaureus_: on non-linux anyway
13:56:39  <piscisaureus_>bnoordhuis: the only way around that is a big mutex
13:56:48  <indutny>how to configure node on smartos?
13:57:03  <bnoordhuis>indutny: ./configure
13:57:04  <mmalecki>indutny: well, ./configure --prefix /opt/local
13:57:11  <mmalecki>that's what I do on smartmachines
13:57:40  <mmalecki>indutny: you want access to a configured and set up machine?
13:57:52  <indutny>mmalecki: nope
13:57:56  <indutny>mmalecki: I need my own one :)
13:58:01  <mmalecki>cool
13:58:28  * bnoordhuisis doing the groceries
13:59:02  <indutny>mmalecki: wanna proof read my blog post?
13:59:05  <indutny>ryah: ^
13:59:29  <indutny>I mean you both
13:59:31  <indutny>:)
13:59:33  <mmalecki>indutny: sure
14:00:02  <indutny>mmalecki: ok, once I'll deploy it
14:01:54  <indutny>mmalecki: oh, how slow the build is on smartos 512mb
14:02:36  <mmalecki>indutny: pretty damn slow, over 2 mins at least. get binaries maybe?
14:03:37  <mmalecki>indutny: get a 1 GB, they are fairly fast
14:03:57  * AvianFlujoined
14:05:39  <indutny>mmalecki: no, I don't want to :)
14:05:52  <mmalecki>why?
14:06:01  * mikealjoined
14:06:24  <indutny>mmalecki: 512mb is cheap
14:06:53  <mmalecki>indutny: if it's on nodejitsu account, meh, take 1 GB
14:10:30  <indutny>mmalecki: no, it's on my own
14:10:56  * mikealquit (Ping timeout: 240 seconds)
14:11:04  <mmalecki>ah, cool
14:11:51  <indutny>mmalecki:
14:11:58  <indutny>wait
14:13:14  <indutny>mmalecki: ok, it's live now
14:13:59  <indutny>mmalecki: does it works?
14:14:39  <mmalecki>yeah
14:17:22  <mmalecki>indutny: looking
14:17:50  <mmalecki>indutny: make the links actual links - "Bundling fresh version of OpenSSL" should be a link
14:17:54  <piscisaureus_>bnoordhuis: yo, why do you malloc struct signal_ctx? It seems that we could just make it static...
14:18:01  <mmalecki>so should be rest of bullet points
14:18:45  <mmalecki>"Several actions were taken"
14:18:55  <indutny>piscisaureus_:
14:18:59  <indutny>piscisaureus_: proof read, please
14:19:04  <piscisaureus_>ok
14:19:09  <indutny>mmalecki: good idea
14:19:29  <mmalecki>"as they told" -> "as they said"
14:19:35  <piscisaureus_>indutny: is there a github repo where I can comment?
14:19:57  <mmalecki>oh, yeah, that ^
14:20:10  <piscisaureus_>indutny: btw, inlined asm is still off on master
14:21:25  <indutny>piscisaureus_: hm..
14:21:33  <indutny>github repo is private so far
14:21:34  <indutny>ok
14:21:35  <indutny>lets publish it
14:21:37  <piscisaureus_>indutny: I have quite a few comments :-)
14:21:56  <indutny>mmalecki: piscisaureus_ https://github.com/indutny/blog
14:22:33  <piscisaureus_>meh, why does github not let one comment on markdown files
14:22:34  <piscisaureus_>:-(
14:22:41  <mmalecki>piscisaureus_: go to commit
14:23:19  <indutny>btw, does style looks good to you?
14:23:27  <mmalecki>yeah, it looks nice
14:23:36  <indutny>mmalecki: have you pressed +1 button?
14:23:38  <mmalecki>indutny: I'll do some gramatical nitpicking :)
14:23:39  <mmalecki>indutny: yeah
14:23:42  <indutny>mmalecki: ok
14:23:45  <indutny>so you better know
14:23:52  <indutny>it's calculating sha1 hash in the background
14:23:55  <indutny>;)
14:24:02  <indutny>not something illegal
14:24:08  <indutny>just to spend some CPU cycles
14:24:49  <mmalecki>hahaha
14:24:53  <mmalecki>nice
14:27:17  <mmalecki>indutny: there, finished my gramatical nitpicking
14:27:41  * TheJHjoined
14:28:40  <indutny>mmalecki: thanks
14:28:49  <indutny>mmalecki: what about "its slowness"
14:29:42  <mmalecki>AvianFlu: can you explain that using correct wording?
14:29:56  <mmalecki>here http://garyes.stormloader.com/its.html
14:33:36  * ericktjoined
14:36:52  * stagasquit (Quit: ChatZilla 0.9.89-rdmsoft [XULRunner])
14:44:09  <piscisaureus_>indutny: the blog should give more hints that infact it is not so much better than the builtin tls module
14:44:44  <piscisaureus_>indutny: most people don't read all text, they could easily overlook the last paragraph
14:48:44  <`3rdEden>needs a tl;dr
14:49:39  <indutny>piscisaureus_: that's what I'm counting on
14:49:42  <indutny>piscisaureus_: :)
14:49:58  <piscisaureus_>indutny: it will only lead to disappointment
14:50:50  <indutny>piscisaureus_: okok
14:50:52  <piscisaureus_>indutny: if people get the full message they'll think you are serious about this stuff. If they think tlsnappy is fast, and try it, and then it turns out to be slow, they'll just think you're a smug.
14:51:30  * mikealjoined
14:51:33  * AvianFluquit (Remote host closed the connection)
14:52:23  <indutny>piscisaureus_: word
14:53:19  * piscisaureus__joined
14:55:06  * indutnymmalecki: piscisaureus_: http://blog.indutny.com/0.benchmarking-tls
14:55:17  <indutny>mmalecki: tldr is left
14:55:20  <indutny>working on it now
14:55:51  * piscisaureus_quit (Ping timeout: 246 seconds)
14:56:51  <indutny>piscisaureus__: ^
15:00:02  * piscisaureus__quit (Ping timeout: 248 seconds)
15:00:21  * MI6quit (Remote host closed the connection)
15:00:26  * tjfontainechanged nick to mi6
15:01:43  * mi6changed nick to tjfontaine
15:02:11  * MI6joined
15:03:00  <indutny>ok, published it
15:03:03  <indutny>and posted everywhere
15:03:06  <indutny>spread the word :D
15:03:12  <indutny>ryah: http://blog.indutny.com/0.benchmarking-tls
15:07:49  * piscisaureus__joined
15:11:48  <piscisaureus__>indutny: btw - why did you call the last paragraph "Foreword" ?
15:12:25  * piscisaureus__changed nick to piscisaureus
15:22:54  <rendar>hmm, what is node.js tls? is it ssl?
15:23:54  <rendar>oh i see, its new SSL
15:23:58  * mikealquit (Quit: Leaving.)
15:24:08  <tjfontaine>almost feels like a troll question, but tls supercedes ssl http://en.wikipedia.org/wiki/Transport_Layer_Security
15:27:01  <rendar>tjfontaine: yes, i'm reading, i have asked because i couldn't find anything for a typo error, sorry
15:27:01  <rendar>:)
15:31:27  <bnoordhuis>i'm getting slightly annoyed with pread() inexplicably returning 0 on solaris...
15:34:18  <ryah>do you guys use "j" ?
15:34:39  <ryah>(for jumping around directories?)
15:35:02  <bnoordhuis>ryah: cd -
15:35:20  <piscisaureus>norton commander
15:36:27  <ryah>bnoordhuis: im a cd - user too
15:36:39  <ryah>bnoordhuis: zsh dir stacks?
15:36:47  <bnoordhuis>ryah: i don't use zsh
15:37:04  <ryah>hm you seem like the zsh type to me
15:38:21  <bnoordhuis>i've been raised on corn bread and bash
15:38:44  <bnoordhuis>talking about... dinner time!
15:38:52  <tjfontaine>I keep trying to get into zsh, but eventually turn things off to make it more bash like
15:40:56  <ryah>don't do it. it's a sad addicition
15:41:01  <ryah>best to just use bash
15:41:20  <ryah>*addiction
15:41:34  <ryah>oh i had it right..
15:42:04  <isaacs>ryah: you can do dir stacks in bash
15:42:27  <isaacs>i actually have a little php program i wrote ages ago that lets me do full on histories of dirs.
15:42:34  <isaacs>cd -3 to go back 3 dirs
15:42:44  <isaacs>or cd +2 to go forward 2
15:43:07  <ryah>php program?
15:43:11  <isaacs>ryah: yeah
15:43:29  <ryah>can you use php for non web things?
15:44:29  <isaacs>ryah: https://gist.github.com/3820263
15:44:32  <isaacs>heall yea.
15:44:37  <isaacs>php sucks for web things
15:44:47  <isaacs>it's really nice for cli scripting, though
15:44:52  <isaacs>it's like bash, but just slightly more structured.
15:45:25  <isaacs>this is probably a terrible program, i write way back before i used git for stuff.
15:45:38  <isaacs>but it's been working without any modifications since then, so that's something.
15:46:56  <isaacs>i guess you could say i use bash, but i've written a bunch of features into my bash environment, so it may as well be a different thing.
15:47:11  <isaacs>but that's more respectable, imo, than using zsh.
15:47:23  <isaacs>it's like using express, vs using coffee-script
15:47:33  <isaacs>one is a framework, the other changes the language entirely
15:48:41  <ryah>wow...
16:01:43  * codeboostjoined
16:02:08  <indutny>philips_: foreword
16:02:12  <indutny>oops
16:02:18  <indutny>piscisaureus: it should be afterword?
16:02:58  <indutny>yeah
16:03:34  <isaacs>indutny: tlsnappy makes me excited.
16:04:14  <isaacs>indutny: i think we should definitely consider just making this the thing that does tls in node.
16:04:49  <codeboost>Hello ! I have a question regarding multithreading in a node addon I'm writing.
16:04:51  <indutny>isaacs: it's not as good so far
16:05:08  <isaacs>indutny: no, but it's heading in a good direction
16:05:17  <isaacs>indutny: if not for 0.10, then for 0.12/1.0
16:06:40  <codeboost>So I have this scenario: The C++ code calls a callback from it's own thread. I use uv_queue_work() to queue a work item and then call the javascript handler when my cbComplete handler is called by libuv. So far so good.
16:07:04  <codeboost>Now the problem: I have a similar callback from C++, only this time, the C++ library expects one of the arguments' data to be modified
16:08:12  <codeboost> The function is called GetNextFrame(short* samples, int numberOfSamples) and the lib expects me to fill samples with data.
16:08:54  <codeboost>If I queue the javascript handler asynchronously, then the callback thread continues and I can't modify the data.
16:09:18  <indutny>isaacs: yeah
16:09:20  <indutny>I hope so
16:09:41  * isaacscommute time
16:11:03  * Raltquit (Ping timeout: 245 seconds)
16:11:03  <codeboost>so I tried waiting on a semaphore immediately after uv_queue_work() and then posting to that semaphore after I make the call into javascript, but I keep getting this assertion: Assertion failed: uv__has_active_reqs(loop), file c:\node-v0.8.11\deps\uv\src\wi n\../uv-common.h, line 101
16:11:50  <codeboost>If there's anyone left who's not totally confused by what I'm writing here, any hints, tips or ideas ?
16:13:09  <indutny>codeboost: ok
16:13:11  <indutny>so first of all
16:13:55  <indutny>are you calling uv_queue_work() from another thread?
16:13:55  <codeboost>indutny: yes
16:13:55  * mmaleckichanged nick to mmalecki[brb]
16:14:17  <indutny>codeboost: that's incorrect
16:14:20  <indutny>it's not thread safe
16:14:32  <indutny>codeboost: you should use uv_async_send to invoke callbacks on event loop's thread
16:14:39  * TooTallNatejoined
16:15:08  <codeboost>that's a breath of fresh air
16:15:49  <indutny>haha
16:16:54  <codeboost>so how do I use uv_async_send... is the uv_close_cb the callback I'm looking for ?
16:17:04  * brsonjoined
16:18:17  <piscisaureus>codeboost: http://nikhilm.github.com/uvbook/threads.html#inter-thread-communication
16:19:40  <indutny>piscisaureus: ++
16:20:11  * ericktquit (Quit: erickt)
16:20:43  <codeboost>wow that's great, didn't know this thing was documented
16:21:56  <indutny>it's better
16:21:58  <indutny>it's a book
16:22:36  <codeboost>ok, I'll read up on uv_async_send() then, but still this doesn't entirely solve my problem: how do you modify the data on the caller thread from the JS world?
16:23:11  <indutny>codeboost: you nee
16:23:13  <indutny>erm
16:23:24  <indutny>you can initialize semaphore
16:23:28  <indutny>and do uv_sem_post()
16:23:50  <indutny>in another thread - just wait with uv_sem_wait()
16:23:52  <indutny>on other hand
16:23:59  <codeboost>ok, so I uv_async_send() then immediately wait on a semaphore... then, after the JS call, I post to that semaphore..right ?
16:24:05  <indutny>you can just change that thread's data from libuv's thread
16:24:14  <indutny>codeboost: yes, that will work
16:24:39  <codeboost>that's great, thanks a lot !
16:24:50  <indutny>codeboost: you're welcome
16:39:37  * ericktjoined
19:26:02  * piscisaureus_topic: liberal utopian vacation ~ http://piscisaureus.no.de/libuv ~ http://groups.google.com/group/libuv
19:26:21  <piscisaureus>https://gist.github.com/0030933d015d1e77ae04 <-- note to self
19:29:42  <piscisaureus>bnoordhuis: hmm
19:29:53  <piscisaureus>bnoordhuis: actually it also isn't safe across fork()
19:31:10  * stagasjoined
19:31:55  * EhevuTov_joined
19:32:19  <bnoordhuis>piscisaureus: right
19:32:50  <piscisaureus>bnoordhuis: so that patch that you did lately to make child's stdio blocking is not a great idea ...
19:32:51  * `3rdEdenquit (Remote host closed the connection)
19:33:24  * EhevuTovquit (Ping timeout: 260 seconds)
19:33:45  <bnoordhuis>no. but non-blocking stdio isn't a great idea either
19:33:54  <bnoordhuis>i guess we'll have to reopen the tty in the child process
19:34:46  <bnoordhuis>it's kind of amusing that it works like that and then again not
19:34:47  <piscisaureus>bnoordhuis: so how's that when the child inherits something not-a-tty, e.g. pipe ?
19:36:59  * indexzerojoined
19:37:52  * Raltjoined
19:37:58  <bnoordhuis>piscisaureus: if the child process is supposed to inherit only one end of the pipe, you can make that end blocking
19:38:16  <piscisaureus>bnoordhuis: that's not what i mean
19:38:16  <bnoordhuis>it doesn't affect the other end, they're separate "files"
19:38:26  <piscisaureus>bnoordhuis: what if you use { stdio: 'inherit' } ?
19:38:44  <bnoordhuis>yeah, that's a problem
19:38:57  <piscisaureus>bnoordhuis: it probably doesn't matter much because we make stdout blocking anyway
19:39:11  <piscisaureus>bnoordhuis: and two processes reading the same stdin is insane
19:39:41  <piscisaureus>bnoordhuis: but if people e.g. try to hook a child process to a socket then we may be in trouble
19:41:01  <piscisaureus>problems like these is what make uv-win so troublesome
19:45:06  <indutny>bnoordhuis: I wonder how can I measure time spent in locks and waiting for semaphore
19:45:30  * ericktquit (Quit: erickt)
19:47:03  <bnoordhuis>indutny: mutrace?
19:47:29  <bnoordhuis>you can get ballpark figures with gprof or callgrind but mutrace is more exact
19:47:30  * EhevuTov_quit (Ping timeout: 248 seconds)
19:47:56  <indutny>bnoordhuis: mutrace
19:47:58  <indutny>thanks
19:48:17  <bnoordhuis>indutny: if you just want to know how much time is spent in locks (on linux), `strace -cfe futex`
19:48:26  <indutny>oh
19:48:30  <indutny>I can use dtrace powers
19:48:31  <indutny>right
19:48:47  <bnoordhuis>it's not quite exact if you use adaptive locks, of course
19:49:10  <indutny>what's adaptive locks?
19:50:46  <bnoordhuis>indutny: locks that start out as spinlocks before yielding
19:50:51  <indutny>ohhhh
19:50:54  <indutny>shit came real
19:53:17  * Raltquit (Remote host closed the connection)
19:53:51  * Raltjoined
19:56:53  <indutny>bnoordhuis: I think we ain't using adaptive mutexes anywhere in libuv, is it correct?
19:57:34  <bnoordhuis>indutny: not explicitly but pthread_mutex_create() might create adaptive locks by default
19:57:42  <indutny>oh
19:57:45  <indutny>even that
19:58:07  <indutny>I thought I need to set mutex to something like this PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP for that
19:58:36  * Raltquit (Ping timeout: 260 seconds)
19:59:19  <bnoordhuis>indutny: it varies. with glibc you create a pthread_mutex_attr_t and set PTHREAD_MUTEX_ADAPTIVE_NP
19:59:36  <indutny>isn't glibc default on ubuntu?
19:59:42  <bnoordhuis>the _NP bit stands for non-portable, of course :)
19:59:44  <bnoordhuis>yes
19:59:50  <indutny>ok
20:00:25  * perezdjoined
20:03:21  * MI6joined
20:04:31  <tjfontaine>ok I had to change mi6 to be pushed based to be nicer to github, so now we'll have to add a webhook service hook to the repos you want to monitor
20:06:31  <indutny>bnoordhuis: I'll try removing most of the locks from code
20:06:36  <indutny>bnoordhuis: at least from ring buffers
20:06:43  <bnoordhuis>indutny: what code? tlsnappy?
20:06:43  <indutny>bnoordhuis: I think I can implement them using instricts
20:06:49  <indutny>bnoordhuis: libuv and node.js
20:06:54  <indutny>bnoordhuis: who needs locks there
20:07:03  <indutny>bnoordhuis: of course, tlsnappy
20:07:30  * indexzeroquit (Quit: indexzero)
20:09:21  <tjfontaine>so someone with admin privs can add a webhook pointing to http://cass.atxconsulting.com:8000 or use https://gist.github.com/3794720#file_createhooks.js which would allow me to track issues and pull requests as well
20:10:09  <piscisaureus>only isaacs can do that
20:10:13  <piscisaureus>isaacs: ^
20:10:51  <isaacs>do what now?
20:10:57  <isaacs>from joyent/node?
20:11:01  <CoverSlide>the tlsnappy gains don't seem particularly significant
20:11:22  * indexzerojoined
20:11:40  <tjfontaine>isaacs: yes, joyent/node and joyent/libuv presuming those are the repos you want to show up here
20:11:55  <indutny>CoverSlide: for now yes
20:12:07  <indutny>CoverSlide: but it wasn't fully using cpus available on server
20:12:17  <indutny>CoverSlide: I think the reason is big lock contention
20:12:31  <indutny>it was much better on smaller machine (my macbook pro)
20:12:44  <CoverSlide>hmm
20:12:47  <indutny>I mean relatively better of course
20:12:56  <CoverSlide>icic
20:14:35  <indutny>CoverSlide: btw, you can give it a try on your machine
20:14:37  <indutny>CoverSlide: and benchmark it
20:14:42  <indutny>I will be really glad :)
20:14:56  <CoverSlide>k i will take a look
20:15:06  <indutny>CoverSlide: thanks
20:18:02  <creationix>is there a way in node to get a free port synchronously?
20:18:20  <creationix>right now I create a new net server, listen, read the port, and close
20:18:33  <creationix>1. I feel that's a race condition, and 2. I'd prefer a sync method if possible
20:18:49  <indutny>creationix: there're no such way
20:18:52  <indutny>unfortunatelly
20:18:59  <indutny>though you can get fd out of that listening server
20:19:01  <indutny>and reuse it
20:19:05  <indutny>listenFD or whatever
20:19:12  <indutny>this will fix race condition
20:19:23  <creationix>no, I need to use the port in an ssh config flag
20:19:26  <creationix>for port forwarding
20:19:33  <indutny>ooh
20:19:37  <indutny>well
20:19:41  <creationix>I wish ssh would just auto-select a free port for me
20:19:55  <creationix>but it only seems to work for remote forwards, not local forwards
20:20:02  <indutny>that's how I'm doing it in vock https://github.com/indutny/vock/blob/master/lib/vock/socket.js#L49
20:20:16  <indutny>find free port and mapping it
20:20:24  <indutny>not sure if it's close to your thing
20:20:46  <indutny>we should definitely add something like listenSync
20:20:53  <indutny>bnoordhuis: what do you think? ^
20:27:11  * ericktjoined
20:34:13  * indexzero_joined
20:36:36  * indexzeroquit (Ping timeout: 255 seconds)
20:36:36  * indexzero_changed nick to indexzero
20:41:01  <bnoordhuis>c'mon MI6
20:41:16  <tjfontaine>bnoordhuis: still requires some plubming from isaacs I think
20:41:34  <bnoordhuis>isaacs: ^
20:41:39  <bnoordhuis>https://github.com/joyent/libuv/compare/emul-sendfile <- review anyone?
20:42:21  * travis-cijoined
20:42:21  <travis-ci>[travis-ci] joyent/libuv#755 (emul-sendfile - ea72a68 : Ben Noordhuis): The build passed.
20:42:21  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/commit/ea72a689bdd6
20:42:21  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/2642539
20:42:21  * travis-cipart
20:43:45  <piscisaureus>bnoordhuis: why do you use select?
20:43:55  <bnoordhuis>piscisaureus: more portable than poll
20:43:58  <piscisaureus>bnoordhuis: that doesn't work with high fds right?
20:44:11  * TooTallNatequit (Quit: Computer has gone to sleep.)
20:44:49  <MI6>joyent/node: Ben Noordhuis master * 109f8e2 : node_http_parser: fix whitespace errors (+2 more commits) - http://git.io/jTm-5w
20:44:56  <isaacs>just added http://cass.atxconsulting.com:8000
20:44:59  <isaacs>seems like it's working
20:45:05  <piscisaureus>bnoordhuis: whatever - do what you want
20:45:09  <tjfontaine>isaacs: thanks
20:45:20  <isaacs>np
20:45:42  <piscisaureus>bnoordhuis: the select() stuff looks correct to me
20:46:06  <bnoordhuis>piscisaureus: yeah, but maybe using poll() is better anyway
20:46:06  <tjfontaine>sadly the web interface doesn't allow you to modify permissions to enable tracking of issues, pull reqs, or branch and tag creation
20:46:17  <bnoordhuis>FD_SETSIZE is large on most unices but not unbounded
20:46:22  * ericktquit (Quit: erickt)
20:47:02  <piscisaureus>bnoordhuis: I think 1024 is common
20:47:18  <piscisaureus>bnoordhuis: fds > 1024 tend to happen :-)
20:47:27  <bnoordhuis>piscisaureus: it's possible to bump it to 8192 but that's still not really large
20:47:29  <piscisaureus>bnoordhuis: I think poll is almost ubiquitous, except windows
20:51:10  * indexzero_joined
20:53:40  * indexzeroquit (Ping timeout: 260 seconds)
20:53:57  <txdv_>MI6 shooting down all the white spaceses
20:54:11  * indexzerojoined
20:54:39  * travis-cijoined
20:54:39  <travis-ci>[travis-ci] joyent/libuv#756 (master - 3977d1b : Ben Noordhuis): The build was broken.
20:54:39  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/2d3760a17c58...3977d1b36c68
20:54:39  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/2642689
20:54:39  * travis-cipart
20:55:10  <txdv_>don't you want to create a topic branch where you can edit out errors in pas tcommits?
20:56:21  * indexzero_quit (Ping timeout: 260 seconds)
20:56:21  <bnoordhuis>interesting that a completely unrelated test fails...
21:01:29  <saghul>bnoordhuis the emu works perfect, test is working again here :-)
21:01:43  <bnoordhuis>saghul: ah sweet :)
21:01:43  * ericktjoined
21:01:57  * TooTallNatejoined
21:07:52  <bnoordhuis>i dare you, travis-ci
21:09:04  * travis-cijoined
21:09:04  <travis-ci>[travis-ci] joyent/libuv#757 (master - b37a0f5 : Ben Noordhuis): The build was fixed.
21:09:04  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/3977d1b36c68...b37a0f5bb3d0
21:09:04  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/2642891
21:09:04  * travis-cipart
21:14:49  * lohkeyquit (Quit: lohkey)
21:25:45  * ericktquit (Quit: erickt)
21:27:16  * mikealjoined
21:28:03  <piscisaureus>bnoordhuis: yo
21:28:08  <bnoordhuis>piscisaureus: yo
21:28:13  <piscisaureus>bnoordhuis: why is the signal context not statically allocated ?
21:28:25  <bnoordhuis>there is a good reason for that
21:28:28  <bnoordhuis>that i forgot
21:28:45  <piscisaureus>bnoordhuis: sysconf(_SC_RTSIG_MAX) ?
21:28:47  <bnoordhuis>i think it's because i anticipated that it had to change later on and i didn't want to get hampered by abi compatibility
21:29:15  <piscisaureus>bnoordhuis: realistically 64 is the maximum number of signals right?
21:29:25  <bnoordhuis>piscisaureus: no
21:30:41  <piscisaureus>bnoordhuis: ok. realistically 8 * sizeof(sigset_t) is the maximum of signals, right?
21:30:43  <piscisaureus>:-)
21:31:29  * mikealquit (Ping timeout: 240 seconds)
21:33:04  * mikealjoined
21:35:42  <bnoordhuis>piscisaureus: in practice yes
21:36:45  <piscisaureus>bnoordhuis: realistically it is not possible to store more than 1 signal per bit :-)
21:36:55  * rendarquit
21:37:16  <piscisaureus>bnoordhuis: I'm wondering if any platform ever had the luminous idea of using 1 char or 1 int per signal
21:37:28  <piscisaureus>because in that case we would be vastly overestimating
21:39:23  * indexzeroquit (Quit: indexzero)
21:40:03  * perezdquit (Quit: perezd)
21:40:13  <bnoordhuis>piscisaureus: i doubt it but does it matter?
21:40:31  <piscisaureus>bnoordhuis: i might make it all static
21:40:44  <piscisaureus>bnoordhuis: unix' signal.c is more complicated than warranted by the problem
21:40:53  * perezdjoined
21:47:20  * mralephjoined
21:53:34  * loladirojoined
21:56:57  <ryah>libuv is more complicated than warrented by the problem :)
21:57:21  <piscisaureus>:'-(
21:57:31  <ryah>but i love it
21:57:46  <ryah>because now i can write apps for windows and not worry about it
21:57:51  * ericktjoined
21:57:56  <ryah>(much)
21:58:00  <piscisaureus>haha
21:58:12  <piscisaureus>well you worried about it for almost a year
21:58:19  <piscisaureus>you just did it all upfront :-)
21:59:02  <ryah>paid it forward? haha
21:59:22  * c4miloquit (Remote host closed the connection)
22:01:06  * tommybergeronquit (Quit: Leaving...)
22:08:27  * avalanche123|hjoined
22:09:03  * kristatequit (Remote host closed the connection)
22:12:31  <isaacs>ok, i'm ready to start putting these stream classes into node, i think
22:12:36  <isaacs>zlib looks like it works.
22:12:46  <isaacs>using the Transform stream class.
22:12:54  <isaacs>and the fs stuff passes a bunch of rudimentary tests.
22:15:50  * hzquit
22:17:36  <isaacs>spekaing of which:
22:17:42  <isaacs>bnoordhuis, piscisaureus: care to comment on this? https://github.com/joyent/node/pull/2524#issuecomment-9039888
22:19:01  <bnoordhuis>isaacs: *shrug*
22:19:17  * indexzerojoined
22:19:18  <bnoordhuis>if it fixes things and doesn't break other things
22:21:25  <piscisaureus>isaacs: I am for taking kochi's patch in master
22:22:15  <piscisaureus>isaacs: and I think we should advocate that all streams always emit 'close' at some point :-)
22:23:03  <isaacs>piscisaureus: we've been over this :)
22:23:16  <isaacs>i'm happy to reopen that discussion.
22:23:21  <isaacs>but it's a bigger discussion that it seems at first.
22:23:22  <piscisaureus>isaacs: we -> who ?
22:23:47  <isaacs>we = me, substack, dominictarr, raynos, mikeal, leecoltrane, and a few others
22:23:58  <Raynos>oh hi
22:24:00  <isaacs>the problem with making everythign emit close is that it's situation-dependent.
22:24:06  <isaacs>er, context-dependent
22:24:09  <isaacs>as to what it actually means
22:24:27  <isaacs>what we ought to say is that writable streams ALL emit 'finish' when they're completely written, ended, anbd flushed
22:24:37  <isaacs>and readable streams ALL emit 'end' when there are no more bytes and they've all been consumed.
22:24:44  <piscisaureus>isaacs: that would be a nice addition I suppose
22:24:45  <isaacs>that's sort of how it works already, just inconsistently.
22:24:45  <Raynos>I'm happy with writable streams emitting finish
22:24:53  <Raynos>im happy with readable streams emitting end
22:24:54  <isaacs>i mean, i don't think that's the ideal api, necessarily.
22:25:00  <piscisaureus>isaacs: that would be a nice addition I suppose
22:25:04  <Raynos>I'm happy with any stream emitting error if it's in a corrupted / uncompleted state
22:25:11  <isaacs>just paving cowpaths, because they're a lot easier to pave than forests and mountains and such :)
22:25:28  <piscisaureus>isaacs: I think that it would be nice to say that a stream will emit close as it's very last event
22:25:35  <isaacs>but you could have a duplex style stream where the readable end is one file descriptor, and the writable end is a different one.
22:25:46  <piscisaureus>isaacs: so, no more writes can happen, no more data can be read, there will be no 'error' events any more etc
22:25:55  <isaacs>piscisaureus: yeah, that'd be nice.
22:26:09  <isaacs>piscisaureus: but it's hard to enforce in the api. we should try doing it as a gentleman's agreement of sorts.
22:26:22  <Raynos>a RW can't emit close
22:26:28  <Raynos>because you don't know what end closed
22:26:31  <isaacs>Raynos: well.. it could.
22:26:40  <piscisaureus>Raynos: no
22:26:40  <isaacs>Raynos: for sockets, "closing" means both are closed.
22:26:44  <Raynos>well it would mean both closed. that's the only sensible thing
22:26:46  <piscisaureus>Raynos: for files, too
22:26:47  <isaacs>right.
22:26:52  <isaacs>piscisaureus: well, files aren't RW
22:26:53  <piscisaureus>oh we have no duplex files
22:26:59  <piscisaureus>we could :-)
22:27:01  <isaacs>because unix is a failure, that's why :)
22:27:03  <Raynos>but why have close when you know you have end & finish
22:27:05  <isaacs>we ought to have duplex files.
22:27:14  <isaacs>Raynos: end !== close
22:27:28  <Raynos>why do you care about close
22:27:29  <isaacs>Raynos: end means that no more data is coming. close means that the entire operation is shut down and cleaned up.
22:27:31  <piscisaureus>isaacs: I think it is not a much-requested feature ...
22:27:32  <isaacs>ie, the fd is closed.
22:27:56  <isaacs>piscisaureus: right, people wnat to know when the behavior will change (ie, "please stop reading" or "all writes are received")
22:28:06  <isaacs>piscisaureus: close is more informative than anything else.
22:28:31  <isaacs>there are some cases where you're doing funky things with fd's
22:28:33  <piscisaureus>isaacs: well, it's complicated, when exactly do you envision "finish" should be emitted?
22:29:00  <isaacs>piscisaureus: finish is emitted when all teh chunks that were passed to write() have been consumed by whatever underlying thing the stream is connected to.
22:29:04  <Raynos>finish means that everything you wrote to me has been correctly handled
22:29:25  <isaacs>piscisaureus: ie, if you write() a bunch of times, they'll return false, but buffer up. 'finish' happens when the buffer clears, and you have called end() at some point.
22:29:29  <piscisaureus>isaacs: in theory the close() syscall could fail with EIO (so the stream would emit error), but after close() reading is also no longer possible
22:29:38  <piscisaureus>right, ok
22:30:44  <Raynos>https://gist.github.com/32801e0a140657f1e813
22:30:44  <isaacs>piscisaureus: i think the assumption would be, with very rare exception, when you see an error, that stream is now poisonous
22:30:45  <piscisaureus>isaacs: so we could emit "finish" after all your data was successfully write()'ed and (in case of sockets) shutdown() succeeded
22:30:53  <isaacs>piscisaureus: sure, that'd be fine.
22:31:01  <isaacs>piscisaureus: i haven't started in on net streams
22:31:22  <isaacs>piscisaureus: just did fd and zlib, since they're tricky enough to work the API, but not quite so complicated as to be overly distracting.
22:31:26  * tomshredsjoined
22:31:36  * TooTallNatequit (Quit: Computer has gone to sleep.)
22:31:43  <Raynos>isaacs: Is it valid to emit error after end / finish ?
22:31:47  <isaacs>i think it's working well enough to actually attempt to merge into a feature branch.
22:31:57  <isaacs>Raynos: it's valid to emit error any time an error occurs.
22:32:03  <Raynos>the only benefit close brings is if it had the semantics of "no error can occur after close"
22:32:11  <piscisaureus>isaacs: I will not prohibit you from creating feature branches :-)
22:32:17  <isaacs>piscisaureus: hehe
22:32:41  <isaacs>piscisaureus: i'll just land all the commits around dinner time US/Pacific
22:32:51  <isaacs>"Good morning! I fixed streams! You're welcome!"
22:32:57  <Raynos>isaacs: there is value in an event that signals "there is will be no more errors in this stream. You can now send the response to the user because you dont need to wait for errors to send instead"
22:33:07  <isaacs>Raynos: sure.
22:33:08  <bnoordhuis>[% 100|+ 159|- 2]: Done. <- down to 2 failures running under valgrind
22:33:30  <isaacs>Raynos: i mean, effectively, errors can't happen unless something is either done to the stream, or pending some response.
22:33:44  <isaacs>Raynos: and close would mean that no more responses are pending
22:33:45  <bnoordhuis>btw piscisaureus, you need to stop slacking off
22:33:45  <bnoordhuis>$ git shortlog -ns | head -n3 632 Ben Noordhuis 524 Bert Belder 337 Ryan Dahl
22:34:09  <piscisaureus>bnoordhuis: I like slacking off
22:34:14  <isaacs>Raynos: finish+end means that you're done with all the reading and writing. close means that the fd or whatever is done and buried successfully.
22:34:32  * travis-cijoined
22:34:33  <travis-ci>[travis-ci] joyent/libuv#758 (master - b88f8b4 : Ben Noordhuis): The build passed.
22:34:33  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/b37a0f5bb3d0...b88f8b40d69b
22:34:33  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/2643777
22:34:33  * travis-cipart
22:34:38  <isaacs>Raynos: but like, this would cause an error to be emitted: stream.on('close', function() { stream.write('gotcha!') })
22:34:45  <isaacs>Raynos: because presumably close can't come until after end
22:37:10  <piscisaureus>bnoordhuis: I also like bragging about libuv so you better get your ass back to work
22:38:56  * c4milojoined
22:40:10  <Raynos>isaacs: errors can happen after end or finish if the stream implementation chooses to do "resource cleanup" after those events
22:45:09  * indexzeroquit (Quit: indexzero)
22:46:50  <isaacs>Raynos: right.
22:47:18  <isaacs>Raynos: but assuming that it emits 'close' when those resources are successfully cleaned up, then errors at *that* point should be extremely unlikely.
22:47:28  <isaacs>(or else they weren't "successfully" cleaned up)
22:50:30  <Raynos>yes
22:50:35  <Raynos>but writable streams dont emit close do they?
22:50:54  <Raynos>i dont know whether fswritestream emits close
22:51:07  <MI6>joyent/node: Ben Noordhuis v0.8 * f624be4 : doc: stream: clarify meaning of 'drain' event - http://git.io/8KMChw
22:52:20  * TheJHquit (Ping timeout: 244 seconds)
22:52:35  <isaacs>Raynos: writable streams can emit close, yes.
22:52:39  <isaacs>Raynos: but they don't emit end
22:52:44  <Raynos>Oh I see.
22:52:44  <isaacs>(unless they're also readable)
22:52:57  <isaacs>the worst part about streams is that we have every synonym for "ITS OVER" in the api somewhere.
22:53:06  <isaacs>and they all mean subtly different things
22:53:14  <Raynos>ideally we just fix things
22:53:18  <Raynos>so that close & end are merged
22:53:23  <Raynos>and close & finish are merged
22:53:44  <isaacs>close is a different semantic thing, thouhg
22:53:52  <Raynos>merge the semantics
22:53:56  <isaacs>can't.
22:53:59  <Raynos>your not allowed to emit end until its closed
22:54:01  <isaacs>they're fundamentally different.
22:54:09  <isaacs>that's silly though, because you usually don't care about close.
22:54:13  <isaacs>why make everyone wait around logner?
22:54:22  <bnoordhuis>piscisaureus: https://github.com/joyent/libuv/commit/f090297f62b834b8904ac1bc4f8c9c969855b1e6 <- complicated?
22:54:29  <isaacs>actually, i don't know about usually. but certainly "often" don't care about close.
22:54:51  <Raynos>true
22:55:02  <Raynos>blargh
22:55:14  <piscisaureus>bnoordhuis: yes
22:55:21  <piscisaureus>bnoordhuis: you want me to explain
22:55:23  <piscisaureus>?
22:55:25  <bnoordhuis>piscisaureus: yes
22:55:45  <piscisaureus>bnoordhuis: ok. runner.h includes <windows.h> because it uses windows functions
22:55:56  * TooTallNatejoined
22:56:13  <piscisaureus><windows.h> will, by default, load headers for winsock 1.1 (which is from the windows 3.1 era)
22:56:39  <piscisaureus>bnoordhuis: unless you fiddle with some preprocessor defines (such as WIN32_LEAN_AND_MEAN) which we don't
22:57:06  <piscisaureus>bnoordhuis: another way around this is to load <winsock2.h> *before* <windows.h>
22:57:08  <piscisaureus>which uv.h does
22:57:24  <piscisaureus>bnoordhuis: so there's your answer
22:57:30  <piscisaureus>uv.h must be included first
22:57:40  <bnoordhuis>piscisaureus: what if runner.h includes <winsock2.h>?
22:57:47  <piscisaureus>that also works
22:58:29  <tjfontaine>isaacs: when you get a chance can you also add the webhook for libuv?
23:01:42  <bnoordhuis>piscisaureus: https://github.com/joyent/libuv/commit/d796c3b <- like that?
23:04:31  <piscisaureus>bnoordhuis: lgtm
23:06:16  <bnoordhuis>okay, enough bug fixing for today, i'm off
23:06:21  * travis-cijoined
23:06:21  <travis-ci>[travis-ci] joyent/libuv#759 (master - d796c3b : Ben Noordhuis): The build passed.
23:06:21  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/b88f8b40d69b...d796c3b6f414
23:06:21  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/2644014
23:06:21  * travis-cipart
23:06:24  <bnoordhuis>have a good night everyone
23:08:31  <piscisaureus>goodnight ben
23:08:56  <TooTallNate>isaacs: can i see the zlib impl?
23:10:49  * bnoordhuisquit (Ping timeout: 240 seconds)
23:16:13  <isaacs>TooTallNate: one sec..
23:16:20  <isaacs>it's not quite working. i'm getting a stream error, which is promising.
23:16:26  <isaacs>means that there's a bug somewhere to find and fix :)
23:17:48  <isaacs>stream errors, abort traps, this is awesome :)
23:18:05  <MI6>joyent/node: isaacs created branch streams2 - http://git.io/6GDaLg
23:18:08  <isaacs>TooTallNate: pushed to streams2 branch
23:28:16  <isaacs>w00t! i got zlib working.
23:29:32  <MI6>joyent/node: isaacs streams2 * f2fdf23 : zlib: Bugfix and assertion (+1 more commits) - http://git.io/wfIDdA
23:29:33  <isaacs>TooTallNate: pushed working zlib impl
23:29:45  <piscisaureus>yay
23:30:18  <TooTallNate>nice :)
23:30:38  <isaacs>zlib.js is way simpler now. still some necessary complexity in there, to talk to the underlying binding properly, but it's basically just a very thin facade to the zlib binding function
23:32:49  * avalanche123|hquit (Quit: Computer has gone to sleep.)
23:50:57  <isaacs>hm... not passing all zlib tests.