00:02:32  * xaqquit (Remote host closed the connection)
00:02:49  <tjfontaine>bradleymeck: I am unaware of such a thing
00:03:13  <bradleymeck>i have just heard rumors
00:04:54  * mikealquit (Quit: Leaving.)
00:12:23  * felixgequit (Quit: felixge)
00:12:53  * mikealjoined
00:15:11  * mikealquit (Client Quit)
00:19:36  <bnoordhuis>tjfontaine: https://github.com/joyent/node/issues/3673#issuecomment-6863655
00:19:49  <bnoordhuis>compiler bugs are great fun
00:20:11  <tjfontaine>jesus.
00:20:18  <tjfontaine>that's utter insanity
00:20:27  <bnoordhuis>it is, isn't it?
00:20:33  <bnoordhuis>i'm off to drink hard now
00:20:35  <tjfontaine>my minimal vote is simply go to O2 :)
00:20:43  <tjfontaine>that's how gcc always makes me feel
00:31:32  <isaacs>bnoordhuis: Do you know what the point of the "program" make target is?
00:32:06  * chobi_e_changed nick to chobi_e
00:32:47  * mikealjoined
00:34:50  * EhevuTovquit (Quit: Leaving)
00:35:04  * chobi_echanged nick to chobi_e_
00:43:12  * dshaw_quit (Quit: Leaving.)
00:44:19  <CIA-108>node: isaacs reviewme * rfbfb2f5 / Makefile : build: Regenerate docs for tarball and releases - http://git.io/m8GoLg
00:44:29  <isaacs>bnoordhuis: ^?
00:44:49  * dshaw_joined
00:52:41  * mikealquit (Quit: Leaving.)
01:08:55  * arlolraquit (Quit: Linkinus - http://linkinus.com)
01:09:08  * dshaw_quit (Quit: Leaving.)
01:13:32  * bnoordhuisquit (Ping timeout: 264 seconds)
01:13:54  * mikealjoined
01:34:46  * beachdogjoined
01:35:24  * abraxasjoined
01:38:19  <c4milo>what's the version of ev_unref(EV_DEFAULT_UC); in libuv?
01:38:57  <TooTallNate>c4milo: uv_unref(), but now you ref/unref handles, not loops
01:39:11  <c4milo>ok
01:43:19  <c4milo>no uv_is_pending()?
01:45:32  * ericktquit (Ping timeout: 246 seconds)
01:48:21  <c4milo>also, do I need to call uv_close() after uv_poll_stop()?
01:53:50  * ericktjoined
02:21:39  <pquerna>isaacs: in spain, travelling today ,on irc in 24 hrs i guess
02:22:13  <isaacs>pquerna: kewl. small question, i think i managed to work around the issue.
02:22:24  <isaacs>pquerna: but you guys stiill using the --always-auth flag in npm?
02:22:39  <isaacs>and, would that stop working if it started sending a AuthSession cookie instead of a BasicAuth header?
02:22:44  <pquerna>isaacs: honestly, we have stopped using a private NPM repo
02:22:49  <isaacs>ok, kewl
02:22:58  <pquerna>it was too much of a bitch
02:23:03  <isaacs>yeah, it's a pita
02:42:29  <bradleymeck>isaacs we use a private npm a lot
02:42:43  <bradleymeck>as long as there is a way to set the auth via cli we can adapt
02:43:16  <isaacs>bradleymeck: i'm gonna make it so that everythign still keeps working
02:43:30  <isaacs>bradleymeck: but, you'll need to have the latest design doc to use the latest npm
02:43:32  <bradleymeck>right now we use an ugly --_auth :(
02:43:38  <isaacs>eew
02:43:41  <bradleymeck>s'fine we replicate
02:43:48  <isaacs>you know you can --username --_password, right?
02:43:57  <isaacs>or just do `npm adduser` and have it in the .npmrc file?
02:44:20  <bradleymeck>i forget why, but there is some legacy reason i think in the 0.4.x npm that wants _auth
02:44:58  <bradleymeck>though luckily only 1 more month of that it looks like
02:45:30  * brsonquit (Quit: leaving)
02:54:38  * ericktquit (Quit: erickt)
02:56:20  * mikealquit (Quit: Leaving.)
03:09:04  * mikealjoined
03:18:00  <nathansobo>TooTallNate: i wanted to talk to you about your thoughts / experience integrating libuv into another run loop, like CFRunLoop for example
03:18:50  <nathansobo>had you considered running the event loop on another thread like is facilitated by libeio / libev?
03:18:54  * mikealquit (Quit: Leaving.)
03:18:57  <nathansobo>(talked about this in here last night)
03:19:17  <nathansobo>but i know you were thinking about that for NodObjC
03:28:37  * brsonjoined
03:33:09  * ericktjoined
03:41:28  <TooTallNate>nathansobo: ya, it's a problem i've yet to solve
03:41:55  <TooTallNate>nathansobo: https://github.com/TooTallNate/NodObjC/issues/2
03:41:56  <nathansobo>TooTallNate you seen the "thread locking" example in the libev docs?
03:42:02  <nathansobo>yeah i saw that issue in my research
03:42:29  <nathansobo>i was hoping you had solved it :-)
03:42:40  <nathansobo>but i'd be curious to discuss it
03:43:47  <TooTallNate>nathansobo: the closest thing so far is running both loops in parallel, having the CFRunLoop drive the program, and call uv_run_once() very frequently
03:43:56  <isaacs>indutny: Hey, you around?
03:43:59  <TooTallNate>which is very non-optimal
03:44:04  <isaacs>indutny: SSL problem for you.
03:44:08  <nathansobo>yeah it sounds non-optimal to me too
03:44:15  <isaacs>indutny: if you feel like having even more pain :)
03:44:21  <TooTallNate>it's essentially a busy-loop :D
03:44:38  <nathansobo>what about this approach: http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#THREAD_LOCKING_EXAMPLE
03:44:53  <nathansobo>tl;dr -> he runs the event loop in a separate thread
03:45:08  <nathansobo>it's the official docs of libev so it seems pretty legit
03:45:37  <nathansobo>and i found some discussion where someone was trying to do single thread integration and he said "don't do that, use a thread"
03:45:46  <nathansobo>and pointed them at that section of the docs
03:45:52  <TooTallNate>nathansobo: well that's probably the best way to go, if you're in charge on which thread libuv runs on
03:46:01  <TooTallNate>unfortunately for node, it is always the main thread
03:46:09  <TooTallNate>which is the same thread that the Apple stuff needs to run on
03:46:23  * EhevuTovjoined
03:46:26  <nathansobo>yeah… but that seems pretty hackable though?
03:46:35  <nathansobo>after all, it's just node::Start
03:46:55  <TooTallNate>well everywhere that referenced uv_default_loop() would need changing
03:47:13  <nathansobo>yeah it would need to be protected by a mutex
03:47:24  <nathansobo>when you wanted to modify the loop
03:47:32  <nathansobo>alternatively
03:47:38  <nathansobo>i was looking at libuv
03:47:50  <nathansobo>and it only refers to loop->ev in a few places
03:48:12  <nathansobo>so maybe an option could be added to uv to provide an acquire and release callback around that access
03:48:43  <nathansobo>windows would need another solution
03:48:52  <nathansobo>but it could work on unix
03:49:01  <nathansobo>like handle it at the uv layer instead of node
03:49:13  <nathansobo>tell uv "run your libev loop on another thread so you don't block my main event loop"
03:49:30  <nathansobo>that would be a good step toward making libev a more embeddable library
03:53:06  * dapquit (Quit: Leaving.)
03:56:02  * mikealjoined
03:56:37  * mikealquit (Client Quit)
03:56:41  * c4miloquit (Remote host closed the connection)
03:56:49  * mjr_quit (Quit: mjr_)
03:57:36  * mikealjoined
04:05:04  <nathansobo>i guess i see what you mean in your case… you're starting with node
04:05:10  <nathansobo>and it's on the main thread
04:05:15  <nathansobo>i'm trying to embed node, so i have more control
04:05:20  <nathansobo>sorry for misunderstanding that
04:06:20  * philips-quit (Excess Flood)
04:07:17  * mattstevensquit (Quit: mattstevens)
04:07:21  * philips_joined
04:10:01  <TooTallNate>nathansobo: ya it sounds like you're in a situation where you have more options
04:11:00  <nathansobo>TooTallNate: what if Node's libuv event loop were not on the main thread? like as an option you could pass to the process?
04:11:21  <nathansobo>then you could presumably fire up a CFRunLoop without getting into trouble
04:11:24  <nathansobo>but..
04:11:34  <nathansobo>i guess that's sticky because you have to signal the run loop to run your callbacks
04:11:40  <nathansobo>yeah it's harder to start with node.
04:11:48  <TooTallNate>i don't really want that, ya
04:12:04  <nathansobo>man i was hoping we could have an alliance :-)
04:12:12  <nathansobo>to make libuv embeddable
04:12:16  <TooTallNate>the only *true* solution for my situation is to have another libuv backend that used CFRunLoop behind the scnenes
04:12:27  <nathansobo>yikes
04:12:29  <TooTallNate>which is a rather big undertaking
04:12:49  <TooTallNate>it's too bad apple abstracts their stuff away so much
04:12:50  <nathansobo>what if you just made libuv / node really easy to embed from objective c?
04:13:04  <nathansobo>like you could distribute something that would literally generate a main.m
04:13:18  <nathansobo>that fired up node and wired it into GCD to run your callbacks
04:13:27  <nathansobo>it's not quite as cool as an npm module i suppose
04:13:39  <TooTallNate>i've been trying to stay away from custom binaries as much as possible
04:13:46  <nathansobo>but it might actually be more pragmatic for developers in the sense they could easily ship with an embedded node
04:13:53  <nathansobo>okay, i understand
04:47:11  * ericktquit (Quit: erickt)
05:25:12  * arlolrajoined
05:40:04  * paddybyersjoined
06:13:29  * TooTallNatequit (Quit: Computer has gone to sleep.)
06:14:13  * nathansoboquit (Quit: nathansobo)
06:26:33  * arlolraquit (Quit: Linkinus - http://linkinus.com)
06:56:00  * stephankquit (Quit: *Poof!*)
07:19:16  * mmaleckijoined
07:21:29  * rendarjoined
07:40:02  * brsonquit (Quit: leaving)
08:08:06  * hzjoined
08:08:50  * hzquit (Read error: Connection timed out)
08:13:34  * hzjoined
08:36:22  * EhevuTovquit (Quit: This computer has gone to sleep)
09:24:48  * abraxasquit (Read error: Connection reset by peer)
09:25:21  * abraxasjoined
09:37:53  * loladirojoined
09:48:27  * dshaw_joined
09:50:03  * sj26joined
09:53:16  * dshaw_quit (Client Quit)
10:02:01  * AlbireoXchanged nick to AlbireoX`Away
10:16:00  * loladiro_joined
10:18:20  * loladiroquit (Ping timeout: 264 seconds)
10:18:20  * loladiro_changed nick to loladiro
10:33:04  <indutny>isaacs: sorry
10:33:09  <indutny>just got internet in Moscow
10:34:04  <mmalecki>indutny: hey
10:34:07  <indutny>mmalecki: hoi
10:34:17  <mmalecki>indutny: you said you'll be travelling, want to visit Poland?
10:34:27  <indutny>mmalecki: I don't think so
10:34:31  <indutny>mmalecki: we won't have enough time
10:34:34  * piscisaureus_joined
10:34:37  <indutny>and Poland, you know, is like Russia
10:34:40  <indutny>in some sense
10:34:43  <mmalecki>indutny: lol, yeah
10:34:46  <indutny>mmalecki: probably, later
10:34:50  <indutny>piscisaureus_: hey man
10:34:53  <indutny>piscisaureus_: howdy?
10:35:23  <piscisaureus_>indutny: hai
10:36:07  <piscisaureus_>indutny: so for this ssl stuff... I am not really up to date with it
10:36:15  <indutny>piscisaureus_: with which one?
10:36:18  <indutny>async sessions?
10:36:29  <piscisaureus_>indutny: are you / we planning to put this shared ssl cache in node?
10:36:31  * abraxasquit (Remote host closed the connection)
10:36:38  <indutny>I think so
10:36:41  <piscisaureus_>indutny: or will people always need to use redis?
10:36:43  <piscisaureus_>ah
10:36:45  <indutny>not redis
10:36:46  <piscisaureus_>that's cool
10:36:46  <indutny>:D
10:36:55  <indutny>that's just an example
10:37:10  <indutny>people may send messages to master process to synchronize sessions
10:37:19  <piscisaureus_>maybe we can use the IPC channel to pass some name shared memory around
10:37:37  <indutny>hm...
10:37:51  <piscisaureus_>or, maybe send some fd around that all processes can mmap
10:37:54  <indutny>this sounds like a deal, but is it really related to async stuff?
10:38:01  <piscisaureus_>no
10:38:08  <indutny>piscisaureus_: but yeah, sharing buffers
10:38:08  <piscisaureus_>I am just thinking ahead :-)
10:38:13  <indutny>sounds interesting
10:38:13  <indutny>:)
10:38:19  <piscisaureus_>maybe SharedBuffer object
10:38:22  <indutny>though mmap isn't fast enough
10:38:25  <piscisaureus_>well
10:38:41  <piscisaureus_>if you have to do it only once per server it's okay
10:38:48  <indutny>well, yes
10:39:02  <indutny>it's like we may say: "Yes it's slow, but you're in charge of that"
10:39:19  <indutny>good idea
10:39:27  <piscisaureus_>we could also do something rad
10:39:31  <piscisaureus_>like a SharedBuffer object
10:39:39  <piscisaureus_>that you can send over an IPC channel
10:39:48  <piscisaureus_>by reference so to speak
10:39:53  <piscisaureus_>comes with a builtin mutex
10:39:57  <indutny>oooh
10:40:07  <indutny>even that
10:40:11  <piscisaureus_>like
10:40:32  <indutny>like every access to it should be wrapped in mutex
10:40:41  <piscisaureus_>indutny: well, if you want to
10:40:43  <piscisaureus_>that's up to the user
10:41:04  <indutny>hm...
10:41:14  <indutny>ok, API like: .lock() .unlock() may work
10:41:16  <piscisaureus_>var buf = new buffer.SharedBuffer(1024*1024);
10:41:17  <piscisaureus_>buf.lock();
10:41:17  <piscisaureus_>buf[1234] = 3;
10:41:17  <piscisaureus_>buf.unlock()
10:41:19  <indutny>or .lock(function() { })
10:41:27  <piscisaureus_>oh, async
10:41:30  <piscisaureus_>:-)
10:41:37  <indutny>hahaha
10:41:54  <indutny>yeah, we can create a special libuv API for that
10:42:05  <indutny>like spawning thread and waiting for mutex to unlock
10:42:18  <indutny>then sending async message to loop and sending it back to unlock mutex
10:42:22  <piscisaureus_>buf.lockSync()
10:42:24  <piscisaureus_>:-)
10:42:27  <indutny>hahahaha
10:42:29  <indutny>for now
10:42:40  <indutny>well, that's API
10:42:52  <piscisaureus_>I think this is what yandex needed ;-)
10:42:56  <indutny>hahaha
10:42:59  <indutny>just in time
10:43:36  <indutny>I don't really know what they needed
10:43:42  <indutny>it's still hard for me to get
10:44:32  <indutny>so, would you like to prototype this sir
10:44:38  <indutny>or was that offloading work on me?
10:44:39  <indutny>:D
10:44:45  <piscisaureus_>well, you worked at yandex right :-)
10:44:57  <piscisaureus_>indutny: well, umm, this is not offloading
10:45:04  <piscisaureus_>indutny: of course this needs some discussion etc
10:45:10  <piscisaureus_>with ben and the likes
10:45:14  <indutny>well, I would like to do this
10:45:17  <piscisaureus_>I know how to do it on windows but not on unix
10:45:22  <indutny>just asking if you're already implementing it
10:45:23  <indutny>aaah
10:45:29  <indutny>I forgot that you're the Windows guy overhere
10:45:33  <indutny>sorry
10:45:35  <piscisaureus_>haha
10:45:43  <piscisaureus_>I know some stuff about unix
10:45:58  <piscisaureus_>I would know how to implement libuv as it is now
10:46:07  <piscisaureus_>but shared memory is such a mess on unix
10:46:14  <indutny>yes, it is
10:46:21  <piscisaureus_>it seems that there are ten or so broken ways to do it
10:46:27  <piscisaureus_>so I need Ben's expertise
10:46:29  <indutny>I think we'll met many caveats here
10:46:40  <indutny>like different behaviour on different platforms
10:46:54  <indutny>I suppose semaphores in shared memory should work in almost every platform
10:47:14  <piscisaureus_>we might also want to use an srw lock instead of a mutex
10:47:24  <indutny>yeah
10:47:48  <piscisaureus_>although then I would have to implement that for windows xp
10:47:55  <piscisaureus_>because it has no native support for that
10:48:10  <indutny>ohhh
10:48:24  <piscisaureus_>but I can hack something together with undocumented apis
10:48:26  <piscisaureus_>keyed events
10:48:43  <indutny>oh crap
10:48:51  <indutny>are you going to store buffers in event keys?
10:49:06  <indutny>ah, you're talking about locks
10:49:09  <piscisaureus_>yeah
10:49:14  <piscisaureus_>Yeah
10:49:18  <piscisaureus_>shared memory is easy
10:49:32  <piscisaureus_>you can just create an anonymous mapping
10:49:35  <piscisaureus_>and have a HANDLE for it
10:49:58  <indutny>and then send it via messages?
10:50:05  <piscisaureus_>as much as the ipc channel cares, it's undistinguishable from a file
10:50:10  <piscisaureus_>yeah
10:50:22  <piscisaureus_>same can be done with mutexes btw
10:52:24  <indutny>interesting
10:52:42  <indutny>I'm afraid there're some good APIs in windows anyway
10:52:51  <indutny>because same thing is really borked on linux
10:53:02  <piscisaureus_>well, linux has eventfd etc
10:53:09  <piscisaureus_>the problem is unix
10:54:00  <indutny>piscisaureus_: so what about code review for my async session stuff? :)
10:54:19  <piscisaureus_>indutny: so did isaacs try it? did it work?
10:54:30  <indutny>isaacs: did you?
10:54:36  <piscisaureus_>he's asleep
10:54:37  <indutny>piscisaureus_: he did, but I don't know results
10:54:40  <indutny>indeed
10:54:48  <indutny>4am at PST
10:58:14  <indutny>piscisaureus_: the question is - is it faster to use shared buffers? :)
10:58:25  <indutny>what people may need that for?
10:58:34  <piscisaureus_>indutny: well, to do ssl session caching :-p
10:58:47  <indutny>well, sessions are about 1kb in size
10:59:05  <indutny>you should be able to pass gigabytes back and forth, easily
10:59:11  <piscisaureus_>nah
10:59:17  <indutny>additionally, I haven't found any benchmarks for session caching
10:59:18  <indutny>:(
10:59:20  <piscisaureus_>the copying is not so expensive
10:59:25  <indutny>indeed
10:59:41  <indutny>so it's like a new API with a lot of work for implementing it
10:59:41  <piscisaureus_>but sending a message to the master requesting a stored session, and sending it back
10:59:53  <indutny>that's how it'll work anyway
10:59:56  <piscisaureus_>the latency is probably pretty big
11:00:00  <piscisaureus_>not really
11:00:11  <indutny>you should request buffer
11:00:15  <piscisaureus_>well
11:00:22  <piscisaureus_>what if we use a big buffer
11:00:24  <piscisaureus_>per server
11:00:31  <indutny>well, you may use cache-per-fork
11:00:36  <indutny>which is a RB-tree
11:00:40  <piscisaureus_>yeah
11:00:46  <piscisaureus_>huh
11:00:46  <piscisaureus_>no
11:00:46  <indutny>and save both in master and in fork
11:00:51  <piscisaureus_>no
11:00:57  <piscisaureus_>just put the RB tree in a big buffer
11:01:03  <indutny>oh my gosh
11:01:04  <piscisaureus_>that is shared across all processes
11:01:19  <indutny>synchronization will kill us
11:01:23  <piscisaureus_>nah
11:01:24  <indutny>ah
11:01:25  <indutny>rwlocks
11:01:28  <piscisaureus_>I don't think so
11:01:35  <indutny>well, it will :)
11:01:48  <indutny>but not as hard as if we'll use non-rw mutexes
11:01:59  <piscisaureus_>well, okay, without locks it would be better
11:02:19  <indutny>the thing is that writes are occuring much often then reads
11:02:20  <piscisaureus_>but lets face it, how do think IPC works? there's also locking involved there, right
11:02:27  <piscisaureus_>but it's hidden
11:02:39  <indutny>oh, really?
11:02:43  <piscisaureus_>of course
11:02:52  <piscisaureus_>when you write to a pipe, the pipe's buffer is locked
11:02:54  <indutny>I thought we're just writing to fd and reading from it?
11:02:55  <piscisaureus_>and then stuff gets copied
11:02:58  <piscisaureus_>yes
11:02:59  <indutny>ah, internally
11:03:11  <indutny>well, this structure may be implemented without locks
11:03:20  <indutny>one writer - multiple readers
11:03:36  <piscisaureus_>I feel that you are too scared of locking
11:03:48  <piscisaureus_>but maybe I am wrong :-)
11:04:12  <indutny>I'm really scared
11:04:29  <indutny>btree that I wrote is really suffering because of it
11:04:42  <piscisaureus_>where's the code?
11:04:49  <indutny>https://github.com/indutny/bplus ?
11:04:49  <piscisaureus_>also, what is the locking pattern
11:04:59  <indutny>rwlocks
11:05:07  <indutny>for whole db
11:05:10  <piscisaureus_>how many lookups can you do per second
11:05:22  <indutny>57000
11:05:30  <piscisaureus_>that's enough right?
11:05:33  <indutny>well, yes
11:05:39  <indutny>with multithreaded it's about 120000
11:05:52  <indutny>but that's not because of rwlocks
11:05:57  <piscisaureus_>I would be a happy man when we can do 57000 handshakes per second
11:05:59  <indutny>I have a quite good cache over here
11:06:02  <indutny>hahahahaha
11:06:11  <indutny>you think that's possible?
11:06:18  <piscisaureus_>no
11:06:19  <indutny>on a not 16 core server
11:06:29  <indutny>well, 2 core mac can accept 1000 req/sec
11:07:00  <indutny>so I suppose it can accept 4000-5000 req/sec on xeon
11:07:12  <indutny>which is not as bad as it may be
11:07:26  <indutny>plus sessions are actually creating a lot of overhead
11:07:31  <indutny>I don't have a statistical information
11:07:43  <indutny>but for me it looks like writes should occur much often than reads
11:07:53  <indutny>and there're also a good thing overhere
11:07:59  <indutny>knowns as TLS session tickets
11:08:04  <indutny>piscisaureus_: have you heard about that?
11:08:07  <piscisaureus_>no
11:08:13  <piscisaureus_>indutny: I know about nothing about ssl
11:08:19  <indutny>it's like sessions, but all data is stored in ticket
11:08:24  <indutny>which clients sends back to server
11:08:30  <indutny>so no storage is required on server
11:08:41  <indutny>not sure if that works in browsers
11:08:46  <piscisaureus_>sounds cool
11:08:46  <piscisaureus_>I am getting dragged out for lunch, brb
11:08:49  <indutny>http://www.ietf.org/rfc/rfc5077
11:08:52  <indutny>hahah
11:08:53  <indutny>ok
11:16:32  * loladiroquit (Ping timeout: 264 seconds)
11:22:36  * loladirojoined
11:36:01  <indutny>piscisaureus_: so I rewrote example to use process.send instead of redis storage
11:36:28  <indutny>piscisaureus_: https://gist.github.com/3082799
11:36:30  <indutny>isaacs: ^
11:36:49  * chobi_e_changed nick to chobi_e
11:46:17  <indutny>piscisaureus_: sorry, I'm completely wasted today
11:46:32  <indutny>if I won't appear online today - will talk to you tomorrow
11:46:52  <indutny>ircretary: tell isaacs to email me with that ssl stuff, please ;)
11:46:53  <ircretary>indutny: I'll be sure to tell isaacs
11:53:16  * hzquit (Ping timeout: 272 seconds)
11:54:50  <piscisaureus_>indutny: that's okay
11:57:04  * c4milojoined
12:10:17  * hzjoined
12:15:25  * bnoordhuisjoined
12:16:20  <CIA-108>libuv: Fedor Indutny v0.8 * r3726dee / (include/uv-private/uv-unix.h src/unix/thread.c): unix: thread: use mach semaphores on osx - http://git.io/Sxa0lw
12:18:22  * travis-cijoined
12:18:22  <travis-ci>[travis-ci] joyent/libuv#490 (v0.8 - 3726dee : Fedor Indutny): The build is still failing.
12:18:22  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/3a548053b8d7...3726dee5e932
12:18:22  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1825553
12:18:22  * travis-cipart
12:36:13  <indutny>well, not sleeping now
12:36:14  <indutny>:)
12:36:22  <indutny>I'm on the "guest-internet"
12:36:33  <indutny>which is my neighboor's open wifi
12:39:31  <indutny>brb
12:46:28  * hzquit (Ping timeout: 272 seconds)
13:28:17  <tjfontaine>To quote: <cryogen > tjfontaine: so, my new favourite things of right now are gyp and libuv
13:40:24  <piscisaureus_>I know what it feels like
13:40:54  <tjfontaine>fwiw piscisaureus_, he's mostly thankful to your windows work so he comfortably develop in vs
13:41:11  <piscisaureus_>I'm a hero
13:41:27  <tjfontaine>indeed
13:41:30  * piscisaureus_jumps off the roof, flapping his superhero wings
13:42:54  <piscisaureus_>But some modesty is due.
13:43:05  <piscisaureus_>It was just the occasion
13:43:23  <piscisaureus_>Really, every super genious could have done this.
13:43:57  * mattstevensjoined
13:44:00  <tjfontaine>clearly.
14:19:29  * ericktjoined
14:22:51  * ericktquit (Client Quit)
14:32:48  * nathansobojoined
14:37:27  * theColejoined
14:37:32  <CIA-108>node: Ivan Torres v0.8 * r8146f2e / doc/api/fs.markdown : doc: clarify fs.symlink and fs.symlinkSync parameters - http://git.io/BRpxFQ
14:57:03  <isaacs>indutny: hey
14:57:42  <isaacs>indutny: so, we dont' give any reasonable way to check if a SSL cert is actually issued to the host your'e requesting.
14:57:47  <isaacs>bnoordhuis: ^
14:58:19  <isaacs>on the cert, there's a CN, and then maybe also a subjectaltname
14:58:32  <isaacs>we check if the cert is valid, and signed by a trusted CA, but that's it
15:00:03  <tjfontaine>isaacs: btw, that question pompted me to check the docs which list the version as 0.8.1
15:00:19  <isaacs>tjfontaine: yeah, i know.
15:00:23  <tjfontaine>k
15:00:30  <tjfontaine>not that it's terribly important
15:00:43  <isaacs>brittleness in the build system. if i build the docs before bumping the version, then building the tarball won't re-generate them
15:00:57  <tjfontaine>heh
15:01:53  <isaacs>oh, i didn't fix the ones in teh /docs/v0.8.2 folder
15:01:55  <isaacs>uploading now
15:03:03  <isaacs>there we go
15:03:35  <CIA-108>node: isaacs v0.8 * rfecebe1 / Makefile : build: Regenerate docs for tarball and releases - http://git.io/xNtHcg
15:03:36  * theColequit (Quit: theCole)
15:03:38  <isaacs>tjfontaine: ^
15:03:45  <tjfontaine>thanks! :)
15:04:28  <isaacs>bnoordhuis: oh, whoops, just saw your additional note after pushing
15:06:10  <bnoordhuis>isaacs: oh, no worries
15:06:25  <bnoordhuis>i don't think it matters much
15:06:32  <isaacs>yeah
15:06:42  <isaacs>there aren't many people building tarballs or running "make doc"
15:07:10  <isaacs>the important thing is that it's idiot-proof/me-proof to do a build.
15:07:14  <bnoordhuis>:)
15:07:19  * theColejoined
15:07:26  <bnoordhuis>re cert checking, that area of node could use an overhaul
15:07:33  <isaacs>yes
15:09:56  <isaacs>it looks like the only thing that really needs to be added is checking the CN and/or subjectaltname fields against the Host header.
15:10:00  <isaacs>which is not so bad, really
15:11:12  <mmalecki>isaacs: hey. https://github.com/joyent/node/pull/3635 might be relevant to your area of interests (http refactor)
15:11:17  * bitprobejoined
15:11:23  <isaacs>i think we can add that in v0.8 even, and just have it set the res.client.authorizationError if it doesn't match.
15:11:41  <isaacs>in v0.9, i'd like a way to set strict: true on the https.request() options, and have it emit an error for errors.
15:17:30  * felixgejoined
15:24:11  * theColequit (Quit: theCole)
15:33:29  <isaacs>mmalecki: yes, we cannot remove that.
15:33:30  <isaacs>sorry
15:33:46  * ericktjoined
15:34:29  <mmalecki>isaacs: why's that?
15:34:44  <isaacs>mmalecki: because the API is marked stable.
15:34:55  <isaacs>mmalecki: there are proxies in the wild that might be using it
15:35:13  <mmalecki>>.<
15:35:15  <isaacs>mmalecki: remember, until 0.6, it was the only possible wya to set the ordering of headers, or the same header more than once.
15:35:24  <isaacs>(maybe 0.4? i forget when it landed)
15:35:24  <mmalecki>that's just silly.
15:35:32  <isaacs>well, it's a silly world, my friend.
15:35:46  <isaacs>context. it's why we can't have nice things.
15:36:26  <mmalecki>oh, no, world is not silly, world is straight up fucked. but API stability is silly
15:37:26  <mmalecki>isaacs: actually, I can do what you described in https://github.com/joyent/node/pull/3635#issuecomment-6878818
15:37:49  <mmalecki>unless you want to do that refactor
15:38:22  <bradleymeck>isaacs do you know if node-gyp has a way to override where .node-gyp goes besides HOME (nobody user does not have privileges in HOME for us) ?
15:38:34  <isaacs>mmalecki: i want to start with the parser.
15:38:42  <isaacs>bradleymeck: i don't know.
15:38:46  <bradleymeck>thx
15:39:04  <isaacs>bradleymeck: it's not a big program, so rtfs is not out of the question, but TooTallNate will be here soon, probably
15:39:08  <mmalecki>isaacs: http parser in js?
15:39:27  <isaacs>mmalecki: yeah
15:39:28  <bradleymeck>i have a prototype http parser built for speed, but need to get tests to match
15:39:37  <mmalecki>isaacs: I kinda like writing parsers too
15:39:53  <bradleymeck>hence issue i just added to http-parser heh
15:40:01  <mmalecki>oh well, looks like I won't have to :D
15:40:06  <isaacs>if you can write an http parser that passes all of node's tests, and all the tests in deps/http_parser then i'll take it
15:40:12  <isaacs>oh, if it's also fast.
15:40:20  <isaacs>ie, as fast as deps/http_parser
15:40:28  <bradleymeck>bench for that somewhere?
15:40:42  <isaacs>bradleymeck: fast means node's benchmark/http.sh
15:40:54  <isaacs>bradleymeck: the benchmarks in node, when it's used.
15:41:08  <bradleymeck>isaacs sure, give me the weekend
15:41:10  <isaacs>bradleymeck: this parser you wrote, is it on github somewhere?
15:41:29  <bradleymeck>not yet, need to write more tests, but i can add you to private repo while i work
15:41:34  <mmalecki>bradleymeck is a real badass
15:41:53  <isaacs>bradleymeck: why make it private? why not just make it public?
15:42:02  <isaacs>is there trade secrets in there or something?
15:42:15  <bradleymeck>cause i like to keep things private until they are up to my liking
15:42:19  <bradleymeck>sec
15:42:28  <isaacs>right, but once you publicize it, all the "not up to your liking" commits are public anyway
15:42:38  <isaacs>better to just put a disclaimer in teh readme, and dev in the open
15:42:52  <isaacs>no shame, man. everybody poops.
15:44:30  <tjfontaine>I poop all the time
15:44:59  <piscisaureus_>I never poop
15:45:09  <mmalecki>piscisaureus_: but you're a super hero
15:45:18  <piscisaureus_>I know
15:45:22  <isaacs>mmalecki: it's becuase he's from nederlandia
15:45:28  <bradleymeck>https://github.com/bmeck/node-protocols/blob/master/http/lib/parser.js , can still get it a bit faster
15:45:38  <isaacs>mmalecki: they don't poop there. that's why it's so clean.
15:45:42  <piscisaureus_>have to reboot
15:45:44  <piscisaureus_>:-)
15:45:45  <piscisaureus_>macs
15:45:50  <isaacs>also, not enough poopin
15:45:55  <bradleymeck>its a first pass so might need more edge cases fixed
15:46:11  <mmalecki>bradleymeck: first thing, don't use an eventemitter here
15:46:18  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
15:46:32  <mmalecki>bradleymeck: I'd go for this.onBodyStart or something
15:46:47  <bradleymeck>mmalecki: sure, but its not ready for the big leagues yet
15:46:59  * mattstevenspart
15:47:17  <mmalecki>right
15:47:23  <mmalecki>just saying tho
15:47:39  <mmalecki>wow, that repo is pretty cool
15:47:41  <bradleymeck>but yea, we should move everything we can to straight property lookups
15:47:58  <isaacs>bradleymeck: yeah, this is missing about 90% of http's edge cases.
15:48:18  <tjfontaine>https://github.com/bmeck/node-protocols/blob/master/dns.js ack duplication of effort
15:48:19  <isaacs>bradleymeck: and i suspect that the switch will be too slow, but i'm not sure.
15:48:31  <bradleymeck>isaacs switch on int is fast
15:48:46  <bradleymeck>unless that changed sometime
15:48:47  <isaacs>bradleymeck: it's going to have to get a lot bigger.
15:48:55  <isaacs>bradleymeck: and it depends :)
15:49:07  <isaacs>but, we shouldn't talk about speed in absence of benchmarks.
15:49:18  <bradleymeck>i do use some fallthroughs already, i was just testing against ab
15:49:22  <isaacs>that's why i'm careful to say that i suspect. i could be wrong. we're probably both wrong, even though we're saying opposite things.
15:49:39  <bradleymeck>without edgecases benchmarks are less valid though
15:49:53  <isaacs>well, you have correctness and speed.
15:49:57  <isaacs>we have to build for both.
15:50:12  <bradleymeck>yep
15:50:15  <isaacs>the "get correct then get fast" approach doesn't actually make sense if "get fast" means rewriting the whole thing
15:50:36  <bradleymeck>tjfontaine: my dns server / all of these are lower level than their counterparts in npm
15:50:38  <isaacs>so you have to have a suite of correctness tests, and also be testing performance along the way, and backtrack when something regresses.
15:50:48  <tjfontaine>bradleymeck: http://github.com/tjfontaine/node-dns
15:50:51  * stephankjoined
15:51:03  <tjfontaine>bradleymeck: not quite, we're on the same level there
15:51:43  <bradleymeck>tjfontaine: nice, meh, i like doing this stuff for now
15:51:50  <bradleymeck>yours is waaay better
15:52:03  <tjfontaine>well, I've been working on it longer :P
15:52:24  <isaacs>writing parsers can be very fun
15:52:31  <isaacs>there's no reason we can't have lots and lots of them
15:52:39  <mmalecki>finite state machines <3
15:53:11  <isaacs>i think, though, for a JS parser, written in node, designed to handle very high load, felixge's node-mysql is probably the approach to copy.
15:54:30  <isaacs>ok, i've gotta commute. bbiab.
15:55:08  <bradleymeck>i like his abstraction / encapsulation, but for http i just thought it overkill, but time will tell, im just afraid of cost of allocating objects vs cost of slicing a buffer
15:56:09  <tjfontaine>incidentally I got tired of constantly rewriting the same pattern of tracking position in a buffer, so I wrote this guy https://github.com/tjfontaine/node-buffercursor
15:57:39  <tjfontaine>should someone else find it helpful
15:57:47  <bradleymeck>i would enjoy that
16:00:02  <mmalecki>I'd write something
16:00:09  <mmalecki>but I'm too tired to do it :/
16:00:13  <mmalecki>#devopsproblems
16:00:24  <bradleymeck>have to test it against my `var i` though
16:03:59  * brsonjoined
16:07:32  <felixge>bradleymeck: only performance testing will show if an abstraction is problematic
16:07:56  <felixge>the main lesson I learned from redoing node-mysql was that performance was super unintuitive
16:07:57  <bradleymeck>indeed
16:08:09  <felixge>that is: I got away with things I thought would be super expensive
16:08:21  <felixge>while I also got surprised by some things I thought would be fast, but were not
16:09:30  <felixge>tjfontaine: buffercursor looks nice
16:09:31  * piscisaureus_joined
16:09:38  <felixge>IMO it needs the ability to append buffers
16:10:12  <tjfontaine>felixge: I've been thinking about that, it shouldn't be impossible but I think it would be a different data structure
16:10:34  <felixge>tjfontaine: what do you mean, different datastructure ?
16:10:51  <felixge>tjfontaine: https://github.com/felixge/node-mysql/blob/master/lib/protocol/Parser.js#L60
16:10:55  <felixge>^--- this is what I do in node-mysql
16:11:15  <tjfontaine>felixge: instead of BufferCursor there would be another BufferCursorGrowable, becuase i rely on the boundary in dns to set the truncation
16:11:23  <felixge>which has an optimization that avoids creating a new buffer if there is enough space in the beginning of the old buffer
16:11:28  <felixge>(that is, before the current offset)
16:11:38  <felixge>tjfontaine: fair enough
16:11:40  <beachdog>minor typo in https://github.com/tjfontaine/node-dns/blob/master/lib/platform.js at line 64 'realod'
16:11:55  <tjfontaine>beachdog: heh, thanks
16:12:07  <tjfontaine>felixge: but I see benefits in your approach as well
16:12:38  <felixge>tjfontaine: you deal with udp messages right?
16:12:57  <felixge>in that case - yeah, my approach doesn't apply, these guys are atomic already
16:12:58  <tjfontaine>felixge: yup
16:13:11  <felixge>but for tcp streams, it makes a lot of sense
16:13:16  <tjfontaine>indeed
16:13:32  * dshaw_joined
16:13:53  <tjfontaine>oh hey look, mountain lion gm uninstalled my git again good thing I already redownloaded xcode
16:14:25  <felixge>why does everybody fuck with these OS pre-release versions? :)
16:14:26  <felixge>I never got the appeal
16:14:40  <tjfontaine>felixge: someone has to make sure things work when it's final :)
16:14:44  <felixge>: p
16:14:55  <felixge>that's why I write JS
16:15:00  <felixge>it just works (tm)
16:15:01  <felixge>:P
16:15:03  <tjfontaine>ya but if nodejs doesn't work :P
16:15:12  <felixge>that's turtles below my turtle !
16:15:26  <felixge>: )
16:16:39  <ik>c/,,\
16:16:41  <ik>i like turtles
16:23:42  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
16:25:17  * bitprobequit (Quit: Computer has gone to sleep.)
16:25:36  * dshaw_quit (Quit: Leaving.)
16:37:17  * dshaw_joined
16:37:38  * dshaw_quit (Client Quit)
16:40:31  * ericktquit (Quit: erickt)
16:42:49  * brsonquit (Ping timeout: 250 seconds)
16:45:46  * brsonjoined
16:46:10  * dshaw_joined
16:46:34  * dshaw_quit (Client Quit)
16:51:20  * theColejoined
16:52:28  * perezdjoined
16:55:21  * dshaw_joined
16:56:23  * dshaw_quit (Client Quit)
17:02:11  * dapjoined
17:07:55  * TooTallNatejoined
17:09:51  * ericktjoined
17:10:28  * piscisaureus_joined
17:11:04  * TooTallNatequit (Read error: Connection reset by peer)
17:11:29  * TooTallNatejoined
17:20:44  * TooTallNatequit (Ping timeout: 264 seconds)
17:29:13  * mikealquit (Quit: Leaving.)
17:29:17  * dshaw_joined
17:31:57  * mikealjoined
17:33:32  * TooTallNatejoined
17:40:44  * bitprobejoined
17:47:48  <piscisaureus_>Hey bnoordhuis
17:47:55  <piscisaureus_>what are you working on these days?
17:48:59  * dshaw_quit (Quit: Leaving.)
17:53:51  * AndreasMadsenjoined
18:01:22  * AndreasMadsenquit (Read error: Connection reset by peer)
18:01:23  * madsonjoined
18:04:11  * madsonquit (Remote host closed the connection)
18:05:57  * hzjoined
18:08:11  * AndreasMadsenjoined
18:08:57  <isaacs>felixge: http://static.izs.me/felix-nodeconf-2012.key
18:09:26  * xaqjoined
18:19:50  * EhevuTovjoined
18:20:22  * mjr_joined
18:21:37  * perezdquit (Quit: perezd)
18:22:23  * perezdjoined
18:23:07  * dshaw_joined
18:24:27  * `3rdEdenjoined
18:28:54  * thr4shjoined
18:30:24  * AndreasMjoined
18:30:30  * AndreasMquit (Client Quit)
18:34:32  * piscisaureus_quit (Ping timeout: 264 seconds)
18:35:04  * perezdquit (Quit: perezd)
18:36:07  * perezdjoined
18:37:51  * piscisaureus_joined
18:38:36  * piscisaureus_quit (Read error: Connection reset by peer)
18:39:01  * piscisaureus_joined
18:43:32  * piscisaureus_quit (Ping timeout: 264 seconds)
18:49:16  * felixgequit (Quit: felixge)
18:59:57  * hzquit
19:02:23  * loladiroquit (Quit: loladiro)
19:05:17  * c4miloquit (Remote host closed the connection)
19:05:51  * c4milojoined
19:08:06  * `3rdEdenquit (Quit: Leaving...)
19:10:32  * c4miloquit (Ping timeout: 264 seconds)
19:11:30  * johnm1234joined
19:24:45  * c4milojoined
19:30:57  * mikealquit (Quit: Leaving.)
19:46:50  * TooTallNatequit (Quit: Computer has gone to sleep.)
19:47:57  * TooTallNatejoined
19:54:53  * theColequit (Quit: theCole)
20:09:50  * dshaw_quit (Quit: Leaving.)
20:11:47  * mikealjoined
20:20:26  <bnoordhuis>github y u so slow?
20:29:41  <creationix>so as part of the http refactor for node, I propose we emit "upgrade" on the request object, not the server object
20:29:56  <creationix>having to have the server object to handle websocket requests is stupid
20:30:14  <creationix>it's a per-request thing, a header and a protocol change
20:30:32  <creationix>or just emit on both if we want backwards compat
20:30:56  <bradleymeck>+1
20:33:11  * mikealquit (Quit: Leaving.)
20:34:33  * AndreasMadsenquit (Remote host closed the connection)
20:36:49  * AlbireoX`Awaychanged nick to AlbireoX
20:38:37  * nathansobo_joined
20:38:38  * nathansoboquit (Read error: Connection reset by peer)
20:38:38  * nathansobo_changed nick to nathansobo
20:44:10  * loladirojoined
20:45:36  <CIA-108>node: Shigeki Ohtsu master * r76104f3 / lib/timers.js : timer: change new Date to Date.now for performance - http://git.io/zB85Gw
20:49:11  * `3rdEdenjoined
20:50:48  * mjr___joined
20:50:50  * mjr_quit (Read error: Connection reset by peer)
20:50:50  * mjr___changed nick to mjr_
20:55:03  * arlolrajoined
21:00:43  * perezdquit (Quit: perezd)
21:01:39  * perezdjoined
21:04:53  <TooTallNate>isaacs: node-gyp v0.5.8 adds a workaround for the npm-sudo problem
21:05:13  <isaacs>TooTallNate: kewl
21:05:20  <isaacs>i'm gonna release a 0.6.20 with an npm update soon
21:05:44  <TooTallNate>sounds good
21:05:55  <tjfontaine>I need to figure out what's going on with gyp and mountain lion and 0.8.x locally
21:06:11  <TooTallNate>tjfontaine: well… what's going on? :p
21:06:29  <tjfontaine>TooTallNate: first glance it seems like gyp isn't generating the makefile appropriately
21:06:47  <TooTallNate>tjfontaine: is there an issue open?
21:07:14  <tjfontaine>TooTallNate: I haven't gone to look yet, but it was working pre gold master update, so it's definitely weird :)
21:08:01  <tjfontaine>make -C build/
21:08:01  <tjfontaine> CXX(target) Release/obj.target/binding/src/binding.o
21:08:01  <tjfontaine>make: c++: No such file or directory
21:08:02  <tjfontaine>make: *** [Release/obj.target/binding/src/binding.o] Error 1
21:08:41  <TooTallNate>and is `c++` in your $PATH?
21:09:00  <tjfontaine>no, and it's never used "c++" before :)
21:10:15  <tjfontaine>setting CXX to clang++ which is in hte path renders similar results
21:10:25  <tjfontaine>er wait, hold one
21:10:44  <tjfontaine>dear xcode wtf, where's the symlink to clang++
21:11:05  <TooTallNate>ya, `c++` has always been used afaik
21:11:10  <TooTallNate>" c++ '-D_LARGEFILE_SOURCE' '-D_FILE_OFFSET_BITS=64' '-D_DARWIN_USE_64_BIT_INODE=1' '-DENABLE_DEBUGGER_SUPPORT' '-DV8_TARGET_ARCH_X64' -I../deps/v8/src -O3 -gdwarf-2 -Wnewline-eof -mmacosx-version-min=..."
21:11:42  <tjfontaine>ok adding the clang symlink fixed it, but I do wonder why xcode command line tools fubard that
21:11:43  <TooTallNate>tjfontaine: do you only have the Command line tools and not Xcode installed or something?
21:12:10  <tjfontaine>TooTallNate: nope, both are installed
21:12:18  <TooTallNate>weird...
21:12:21  <tjfontaine>quite.
21:13:11  <tjfontaine>anyway, if you see a similar error pop up, have them check for clang++ :P
21:13:46  <tjfontaine>clang++ is a symlink to clang of course
21:13:46  <kohai>clang has 1 beer
21:30:02  * dshaw_joined
21:34:27  <TooTallNate>tjfontaine: hopefully apple notices before the final release ;)
21:36:15  * rendarquit
21:36:38  * dshaw_quit (Read error: Connection reset by peer)
21:36:59  * dshaw_1joined
21:37:44  * perezdquit (Quit: perezd)
21:40:57  * mikealjoined
21:45:25  * `3rdEdenquit (Quit: Linkinus - http://linkinus.com)
21:45:52  * piscisaureus_joined
21:46:03  <piscisaureus_>hello
21:46:23  <piscisaureus_>bnoordhuis: hey
21:46:37  <piscisaureus_>bnoordhuis: what are you working on nowadays?
21:48:39  <bnoordhuis>piscisaureus_: hey bertje
21:48:48  <piscisaureus_>hey bennetje
21:49:08  <bnoordhuis>piscisaureus_: multi-loop signals, making node print useful crash dump info, coroutines
21:49:15  <bnoordhuis>the coro stuff is just for fun though
21:49:26  <piscisaureus_>bnoordhuis: cool
21:49:33  <piscisaureus_>multiloop signals +5
21:49:36  <piscisaureus_>coros?
21:49:48  <piscisaureus_>are you redoing node-fiber?
21:49:53  <piscisaureus_>bnoordhuis: ^?
21:50:02  <creationix>how expensive are coros?
21:50:04  <bnoordhuis>piscisaureus_: sort of - just to see if i can get it to work
21:50:21  <piscisaureus_>bnoordhuis: does v8 already support yield etc?
21:50:38  <piscisaureus_>I would like to support that sort of stuff :-)
21:50:38  <creationix>not that I know of
21:50:42  <bnoordhuis>creationix: it's implemented in c
21:50:47  <bnoordhuis>creationix: i'm pleasantly surprised at how fast makecontext and swapcontext are
21:50:53  <creationix>but luvmonkey does
21:50:54  <creationix>;)
21:51:07  <creationix>the concerns I heard is they use too much memory
21:51:09  <bnoordhuis>stack space / address space is the big issue of course
21:51:18  <creationix>right
21:51:25  <creationix>so 100,000 coros is a bad idea
21:51:26  <piscisaureus_>bnoordhuis: yeah. You should allocate stack frames on the heap
21:51:44  <piscisaureus_>instead of putting them in a linearly allocated chunk of memory
21:51:57  <bnoordhuis>piscisaureus_: i'm mmap'ing them in the available address space and pray they don't grow too big :-/
21:51:59  <creationix>I guess the question is how much do they cost compared to javascript closures
21:52:11  <piscisaureus_>yeah
21:52:25  <piscisaureus_>that's why I said: put 'em on the heap :-)
21:52:56  <creationix>so since generators are single-frame, they are a lot cheaper right?
21:53:24  <piscisaureus_>are they
21:53:38  <piscisaureus_>I think the ES6 proposal has something like "deferred yield"
21:53:38  <creationix>no idea, just what I've been told
21:53:55  <creationix>to me harmony generators and lua coroutines look a lot alike
21:54:01  <creationix>you suspend something and resume it later
21:54:04  <creationix>passing data both ways
21:54:08  <bnoordhuis>i don't see how that would work, i.e. being single frame
21:54:30  <bnoordhuis>i mean, they're a lot like closures right?
21:55:08  <creationix>function* () { var i = 0; while (true) { yield i++; }}
21:55:13  <piscisaureus_>oh "delegating yield"
21:55:18  <piscisaureus_>so they are not single frame
21:55:30  <piscisaureus_>http://wiki.ecmascript.org/doku.php?id=harmony:generators#delegating_yield
21:55:35  <piscisaureus_>Totally agree tho
21:55:40  <piscisaureus_>that would make them useless
21:55:50  <piscisaureus_>being single frame
21:56:13  <creationix>I see, so how is this not a full coroutine?
21:56:45  <piscisaureus_>it is
21:57:18  <piscisaureus_>so hopefully it's not that every coro would need a stack of it's own
21:57:41  <bnoordhuis>no, just a copy of the environment, like closures have
21:58:13  <piscisaureus_>+1 for first class citizen coros
21:59:35  * perezdjoined
22:00:04  <piscisaureus_>ok, bnoordhuis, thanks for your update
22:00:13  <piscisaureus_>Now I am going to bed :-)
22:00:18  <bnoordhuis>piscisaureus_: so what have you been up to, bertje?
22:00:25  <piscisaureus_>bnoordhuis: sad that nowadays we really have no overlap in working hours
22:00:35  <bnoordhuis>i'll try to get up early tomorrow :)
22:00:37  <piscisaureus_>bnoordhuis: masm port for openssl routines
22:00:46  <bnoordhuis>ah, sweet. how's that coming along?
22:01:00  <piscisaureus_>bnoordhuis: finishing the release tools for libuv (do we want to make releases for the 0.8 branch?)
22:01:08  <bnoordhuis>piscisaureus_: we could just bundle gas.exe :)
22:01:11  <piscisaureus_>bnoordhuis: re masm: crashing ...
22:01:21  <piscisaureus_>bnoordhuis: probably a bug in my conversion tool
22:01:29  <bnoordhuis>sweet debugging fun!
22:01:32  <piscisaureus_>yeah
22:01:33  <piscisaureus_>not
22:01:52  <piscisaureus_>bnoordhuis: ok, cool for getting up early tomorrow :-)
22:02:08  <bnoordhuis>i'll do my best :)
22:02:22  <piscisaureus_>bnoordhuis: I tool a large amount of melatonin last saturday to reset my biological clock, and that worked very well
22:02:34  <piscisaureus_>Im sorta tired now and want to sleep
22:03:10  <bnoordhuis>go ahead
22:03:22  <piscisaureus_>cool
22:03:27  <piscisaureus_>bnoordhuis: you should too
22:03:33  <piscisaureus_>bnoordhuis: go live a normal life :-)
22:03:46  <piscisaureus_>Ok, I'm off, ttyl guys
22:03:52  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
22:11:21  <isaacs>you guys aren't talking about putting coros in node, are you?
22:12:21  <creationix>isaacs, you know you want 'em ;)
22:12:31  <isaacs>creationix: i know that i do not want em
22:13:01  <creationix>well, I don't know by bnoordhuis is researching them, but I was talking about what's coming in harmony and what's already in lua
22:13:09  <creationix>I have no intentions to add coros myself to v8
22:13:25  * hzjoined
22:13:33  <isaacs>harmony generators...
22:13:34  * isaacsshudder
22:13:52  <creationix>yeah, I'm still on the fence on coros
22:14:11  <creationix>they can solve many hard problems, but introduce new ones
22:14:24  <creationix>and harmony generators are just another form of coros
22:14:29  <creationix>with a really strange syntax
22:14:47  <isaacs>yep.
22:15:01  <isaacs>i don't agree that they actually solve any problems any better than memoized loops.
22:15:08  <isaacs>i mean, that's all they really are, but with stupid weird syntax.
22:15:21  <isaacs>completely unnecessary.
22:15:24  <creationix>well, the stack preservation is nice
22:15:25  <isaacs>"looping is hard" is not a real problem.
22:15:30  <creationix>and exceptions are catchable
22:15:32  <isaacs>it's not nice. it's magical.
22:15:48  <isaacs>and throwing exceptions is not an appropriate way to stop a loop
22:15:52  <creationix>I'd say complex, not magical
22:16:05  <creationix>coros in luvit are really hard to understand sometimes
22:16:12  <creationix>I usually stay far away from them
22:16:28  * EhevuTovquit (Quit: This computer has gone to sleep)
22:16:47  <isaacs>magical = clever obtuse "solution" to a problem no one actually has.
22:17:39  <creationix>to me coroutines are just another tool, the only disingenuous part is they appear very simple, but are actually quite complex
22:17:46  <creationix>just like callbacks and closures
22:17:51  <creationix>but those are simple to understand
22:19:09  <creationix>isaacs, I agree, exceptions should only be used for "exceptional" cases, not generic control-flow
22:20:38  * arlolraquit (Quit: Linkinus - http://linkinus.com)
22:21:32  * hzquit (Ping timeout: 272 seconds)
22:26:40  * bitprobequit (Quit: Computer has gone to sleep.)
22:27:33  * thr4shquit (Quit: Linkinus - http://linkinus.com)
22:32:14  * dshaw_1quit (Read error: Connection reset by peer)
22:32:18  * dshaw_joined
22:35:36  * johnm1234quit (Quit: Leaving.)
22:49:59  * paddybyersquit (Quit: paddybyers)
23:06:20  * c4miloquit (Ping timeout: 264 seconds)
23:15:30  * mikealquit (Read error: Connection reset by peer)
23:15:48  * mikealjoined
23:17:53  <CIA-108>node: isaacs v0.6 * rae5a209 / (407 files in 56 dirs): npm: Upgrade to 1.1.37 - http://git.io/Yaiusg
23:17:53  <CIA-108>node: isaacs v0.6 * r17061d9 / .gitignore : .gitignore: Don't ignore node_modules (breaks npm) - http://git.io/ZRhVOA
23:20:16  <mmalecki>so, I'm trying to dtrace some stuff in node. is connect(2) returning -1 in pretty much every call something normal?
23:23:54  * davispquit (Ping timeout: 252 seconds)
23:24:34  <mmalecki>(errno == 150)
23:26:14  <CIA-108>node: isaacs v0.6.20-release * r952e513 / (ChangeLog src/node_version.h): 2012.07.10 Version 0.6.20 (maintenance) - http://git.io/75L3Nw
23:26:21  <isaacs>anyone wanna review that?
23:26:30  <isaacs>(anyone care about 0.6?)
23:26:41  <isaacs>mmalecki: might be relevant to your interests
23:26:51  <isaacs>tons of tests fail, but whatever. 0.6 never was clean.
23:27:04  <isaacs>well, not tons, but a few
23:27:08  * davisp-joined
23:27:32  <mmalecki>isaacs: thanks, I'm too drunk to deploy it anyway
23:27:39  <isaacs>haha
23:28:28  <mmalecki>gotta celebrate going public :)
23:29:08  <isaacs>totally
23:29:39  <mmalecki>isaacs: btw, did I tell you how node 0.8 cut down our load balancer response time in half in some cases?
23:29:53  <isaacs>mmalecki: yeah, i think you mentioned that
23:29:56  <isaacs>that's fantastic!
23:30:17  <mmalecki>yeah, I deployed node 0.8 to them, went to our internal dashboard and was like
23:30:23  <mmalecki>UHM, 3 MS ROUND TRIP?!
23:30:40  <isaacs>what was it before?
23:30:48  <isaacs>6?
23:31:02  <mmalecki>5 ms was really good, usually 8 - 12
23:31:29  <mmalecki>it went up now, since we're handling more traffic
23:31:32  <isaacs>nice
23:31:45  * theColejoined
23:31:46  <isaacs>good thing you upgraded before the announcemnet :)
23:31:59  <mmalecki>also, it got much better since migration to joyent
23:32:07  <mmalecki>so, like, <3
23:33:42  <mmalecki>AvianFlu: do you recall what was the mean time on rackspace? like 25 ms or so, given the same DC?
23:34:17  <isaacs>jesus
23:34:20  <isaacs>that's so slow!
23:34:23  <isaacs>;P
23:34:26  <AvianFlu>hahahahhhahaha
23:34:32  <AvianFlu>"given the same dc" he says
23:34:39  <isaacs>tenS of ms!?
23:34:46  <isaacs>waaaaaooowww
23:34:48  <mmalecki>yeah, rackspace would put our servers in random datacenters
23:34:52  <AvianFlu>well we had so many servers, colocation was a problem
23:35:01  <mmalecki>so, we ended up with few servers in UK
23:35:02  <AvianFlu>a sometimes transatlantic problem
23:35:20  <mmalecki>with traceroute going through Texas, for some reason
23:35:21  <isaacs>actually, i dno't really know the complexity that goes into all that
23:35:28  <AvianFlu>me neither
23:35:34  <isaacs>i'm sure there are plenty of hard tradeoffs to be made. shoudln't poke fun
23:35:40  <AvianFlu>apparently their new API solves a lot of these problems
23:35:43  <isaacs>kewl
23:35:54  <mmalecki>AvianFlu: you mean they got a new API?
23:35:59  <AvianFlu>yeah, the nova thing
23:36:03  <AvianFlu>it sounded really sweet
23:36:08  <mmalecki>like one which doesn't start responding with 500 during a massive deploy?
23:36:09  <AvianFlu>except, now I'm solving problems on a new OS
23:36:34  <mmalecki>yeah, smartos is really fun
23:36:48  <AvianFlu>well, without new problems life is just boring
23:36:50  <AvianFlu>I'd go sane or something
23:36:52  <AvianFlu>...
23:36:54  <mmalecki>lol
23:37:07  <mmalecki>no, I mean, I like running with an extinguisher
23:37:28  <mmalecki>also, dtrace <3
23:38:11  <mmalecki>oh my, that bottle is empty
23:38:46  <AvianFlu>as if it weren't apparent
23:39:08  <mmalecki>I got another one in my freezer, 1 L
23:39:24  <mmalecki>and since I really want to celebrate, I'll go and get it now
23:39:40  <mmalecki>then I'll get emotional
23:44:36  * loladiroquit (Quit: loladiro)
23:49:24  <isaacs>bnoordhuis: feel like testing it? http://nodejs.org/dist/v0.6.20/node-v0.6.20.tar.gz
23:50:43  <bnoordhuis>isaacs: sure
23:50:55  <isaacs>bnoordhuis: note: several tests fail. we're not going to fix them.
23:51:00  <isaacs>but if anything seems super bad, lmk
23:51:20  <bnoordhuis>isaacs: iwlyk
23:51:34  <isaacs>bnoordhuis: changelog: http://nodejs.org/dist/v0.6.20/email.md
23:51:51  <isaacs>a few of those can probably be omitted.
23:51:57  <isaacs>buti find myself not caring much about 0.6 these days
23:51:57  <bnoordhuis>isaacs: core: use proper #include directives (Ben Noordhuis) <- that's hardly worth mentioning :)
23:52:13  <isaacs>bnoordhuis: it's AT LEAST as relevant as * benchmark: Backport improvements made in master (isaacs)
23:52:20  <bnoordhuis>haha, okay
23:52:22  <indutny>isaacs: hey man
23:52:25  <indutny>bnoordhuis: hi
23:52:28  <isaacs>i had to cherry pick TWO WHOLE COMMITS
23:52:31  <bnoordhuis>sup fedor
23:52:38  <isaacs>indutny: whatup
23:52:55  <bnoordhuis>indutny: back in the ex-USSR?
23:52:57  <indutny>isaacs: you pang me about some SSL stuff
23:53:00  <indutny>bnoordhuis: haha, yes
23:53:02  <indutny>exactly
23:53:23  <isaacs>indutny: oh, yeah, i was wondering if you had any thoughts about https://github.com/joyent/node/issues/3680
23:54:21  <indutny>oh god
23:54:25  <indutny>ok, I'll do that
23:54:27  <isaacs>it seems like we could do something pretty easily in JS. the reference implementations are all in C and that's just not a good language for doing string comparison stuff.
23:55:05  <isaacs>basically, it should set the response.client.certificateError or whatever we do for invalid certs, based on the Host header we used, and the CN/subjectaltname fields.
23:55:11  <isaacs>it's kinda tedious but not horrible.
23:55:38  <indutny>yes
23:55:40  <indutny>agreed
23:55:50  <indutny>it's 4am in Moscow
23:55:56  <indutny>so I'll probably do it later today :)
23:58:37  <bnoordhuis>isaacs, indutny: on that subject, i was thinking we should have more direct openssl bindings, possibly internally
23:58:49  <indutny>bnoordhuis: obviously
23:58:53  <bnoordhuis>(internally as in 'not exposed')
23:58:56  <indutny>we ain't exposing anything like that right now
23:59:04  <indutny>and that's odd
23:59:14  <indutny>encryption without security
23:59:20  <bnoordhuis>it would let us do more work in js land where it belongs
23:59:29  <isaacs>bnoordhuis: +
23:59:30  <isaacs>++
23:59:50  <mmalecki>bnoordhuis: ++, let's do it properly
23:59:52  <kohai>bnoordhuis has 19 beers