00:00:32  <ryah>https://github.com/joyent/node/blob/67706b8bb75fefc6f00b911580cc20646d0166b7/lib/net_uv.js#L90-91
00:01:07  <ryah>https://github.com/joyent/node/blob/67706b8bb75fefc6f00b911580cc20646d0166b7/src/pipe_wrap.cc#L199-209
00:04:34  * isaacsquit (Quit: isaacs)
00:20:48  * mikealjoined
00:23:15  * erickt_quit (Quit: erickt_)
00:54:32  <CIA-53>node: Ryan Dahl v0.4 * rdea49e3 / (lib/net.js test/simple/test-net-write-callbacks.js):
00:54:32  <CIA-53>node: net: Fix string-concat hot path bug
00:54:32  <CIA-53>node: Also removes functionality added in f9fec3a2d65580b7e39edc9afd5904cd4775c87c
00:54:32  <CIA-53>node: because it changes API. (That patch shouldn't have been added anyway.) - http://git.io/_Na0kA
01:04:02  <ryah>piscisaureus, igorzi: uv_pipe_init(uv_loop_t*, uv_pipe_t*, int ipc);
01:04:04  <ryah>?
01:04:16  <igorzi>ryah: yep, looks good
01:04:22  <ryah>k
01:04:34  <piscisaureus>it's what we discussed. so +1 :-)
01:20:48  <ryah>unfortunately i started drinking beer which implies programming skills drop to zero
01:25:33  <bnoordhuis>not at all, there's a correlation between alcohol intake and programmer productivity
01:25:41  <bnoordhuis>but it's a thin line to walk, takes years of practice
01:31:23  <ryah>you speak of the ballmer peak, obviously
01:31:46  <bnoordhuis>indeed i do
01:31:55  <ryah>yeah, i unfortunately cannot maintain it.
01:32:21  <bnoordhuis>when we get to SF i'll share my years of accumulated wisdom with you, ryah
01:32:33  <ryah>i look forward to it :)
01:33:00  <bnoordhuis>what kind of beer do you normally drink?
01:33:06  <ryah>budwiser
01:33:15  <ryah>(the american kind)
01:33:19  <bnoordhuis>oh, poor sod
01:33:44  <ryah>im also a fan of the gold wrapped czech kind
01:33:51  <ryah>do you have that in NL?
01:33:56  <bnoordhuis>budvar!
01:34:08  <bnoordhuis>yes, but you have to seek it out
01:34:19  <ryah>that was my favorite beer in germany
01:34:42  <bnoordhuis>i lived in the czech republic for a while, probably drank a million budvars
01:34:59  <ryah>a million is a big number
01:35:53  <bnoordhuis>i may have lost count now and again
01:36:03  <piscisaureus>here in holland we drink heineken
01:36:03  <piscisaureus>(except for bnoordhuis because he's really a provincial, they don't)
01:36:54  <bnoordhuis>gatver, heineken
01:37:14  <ryah>http://www.youtube.com/watch?v=LnyOOp85EN4 <-- good song
01:37:17  <bnoordhuis>heineken is for the people who don't know any better
01:37:20  <bnoordhuis>real men drink grolsch
01:39:10  <ryah>in twenty-seven years, i've drunk fifty thousand beers
01:39:22  <piscisaureus>hmm ryah this is one of the rare occasions where you actually posted a good song
01:39:27  <ryah>and they just wash against me, like a sea into a pier
01:41:04  <piscisaureus>although it's still a bit on the 'raw' side for me to really love it
01:41:57  <bnoordhuis>also, that guy can't sing
01:42:07  <bnoordhuis>but that's never stopped britney or madonna either
01:43:08  <piscisaureus>http://www.youtube.com/watch?v=aXLWH2IAEN0 (no happy hardcore this time, nor händel)
01:45:12  <piscisaureus>igorzi: I want to get rid of uv_xxx_endgame -- it's too messy
01:46:06  <piscisaureus>but I lack good ideas :-(
01:48:57  <piscisaureus>at least endgame should no longer be responsible for doing shutdown - we should just post queue shutdown req and make the actual shutdown call from uv_process_xxx_shutdown_req()
01:50:17  * brsonquit (Quit: leaving)
01:52:29  <piscisaureus>I'm kind of considering to build an epoll backend for uv-windows, because I don't really trust libev
01:53:33  <bnoordhuis>was that a subtle joke?
01:54:08  <piscisaureus>well... it may not be very realistic to do it
01:54:36  <piscisaureus>but it would be a nice test case for the concepts used inside libuv-win
01:55:54  <piscisaureus>if we want people to define their own stream types, it must be possible to swap the GetQueuedCompletionStatis-based uv_poll function for an epoll based one, and then write a tcp stream that works on unix
01:56:37  <bnoordhuis>i'm probably still a little fuzzy on how iocp really works
01:56:49  <piscisaureus>bnoordhuis: that should not matter too much
01:56:50  <bnoordhuis>i thought it was a "don't call us, we'll call you" kind of thing?
01:57:06  <piscisaureus>bnoordhuis: it's just a queue
01:57:26  <piscisaureus>bnoordhuis: initiate something, after it's done windows will add a message to the queue
01:58:04  <bnoordhuis>ah okay, why didn't you say so? :)
01:58:27  <piscisaureus>why didn't you ask?
01:59:58  <piscisaureus>bnoordhuis: it's practical though - if you need to run the thread pool for some reason, you can just add something to the queue yourself
02:05:06  <piscisaureus>If I had to implement libuv-unix without libev I'd give all handles 2 queues, a 'readable' queue and a 'writable' queue
02:05:41  <bnoordhuis>piscisaureus: because ... ?
02:07:06  <piscisaureus>hmm. for readable you may not actually need one.
02:09:15  <piscisaureus>bnoordhuis: never mind. another time :-)
02:10:16  <piscisaureus>bnoordhuis: ryah's vtable idea (which I am not supposed to call vtable) to let people implement their own streams is distracting me
02:10:43  <bnoordhuis>piscisaureus: vtable idea?
02:11:30  <piscisaureus>bnoordhuis: http://piscisaureus.no.de/log/2011-09-28 @ 02:26:54
02:11:38  <piscisaureus>(I should make that linkable)
02:12:12  <piscisaureus>For this it would be nice if both backends had a similar design
02:13:13  <bnoordhuis>hmm, yes maybe
02:13:32  <bnoordhuis>but why don't you break uv up in small files and select at compile time what should be linked in?
02:13:45  <piscisaureus>bnoordhuis: that would also work
02:14:28  <piscisaureus>bnoordhuis: fantazise a bit, how awesome would it be to have a gzip stream type
02:14:41  <piscisaureus>and ssl
02:15:00  <piscisaureus>you don't really want to add this to libuv core
02:15:53  <bnoordhuis>but why vtables? you can layer that on top of uv_tcp_t painlessly, just embed it in a mylib_gzip_t type
02:16:09  <bnoordhuis>juggle callbacks, done
02:20:33  <piscisaureus>bnoordhuis: so that when people do uv_close(my_gzip_handle) it gets dispatched to the right function?
02:21:05  <piscisaureus>bnoordhuis: ... and we can have uv_pump
02:27:58  <bnoordhuis>i don't trust it when a big batch of code works at the first run...
02:38:23  <piscisaureus>bnoordhuis: ?
02:38:30  <bnoordhuis>piscisaureus: ?
02:38:38  <piscisaureus>bnoordhuis: ??
02:38:41  <piscisaureus>[04:27] <bnoordhuis> i don't trust it when a big batch of code works at the first run...
02:38:54  <bnoordhuis>piscisaureus: oh, that... the http parser bindings
02:39:01  <piscisaureus>he
02:39:02  <piscisaureus>h
02:40:49  <piscisaureus>I should go. My brains are leaking.
02:40:58  <piscisaureus>bnoordhuis: don't forget to mail me some stuff tomorrow!
02:41:09  <bnoordhuis>piscisaureus: *sigh* okay
02:41:13  <piscisaureus>bnoordhuis: also, see you in Utrecht. What time you wanna be there?
02:41:17  <bnoordhuis>do i need to book the hotel too?
02:41:30  <bnoordhuis>piscisaureus: don't know, want to grab dinner first?
02:41:45  <piscisaureus>bnoordhuis: can do, I'd like it I think
02:41:50  <piscisaureus>but not for hours
02:42:03  <bnoordhuis>er?
02:42:08  <piscisaureus>bnoordhuis: ergens aan de werf?
02:42:16  <bnoordhuis>ah zo
02:42:19  <bnoordhuis>wat is de werf?
02:43:39  <piscisaureus>bnoordhuis: de werf, dat is dat lage stuk aan de gracht
02:43:45  <piscisaureus>zoals je dat hebt in utrecht
02:43:53  <bnoordhuis>ah, noemen ze dat de werf
02:43:58  <piscisaureus>yep
02:44:17  <bnoordhuis>is goed
02:44:19  <bnoordhuis>hoe laat?
02:44:24  <piscisaureus>7?
02:45:33  <bnoordhuis>doen we
02:46:32  <piscisaureus>bnoordhuis: ik kom om 18:50 aan op het station
02:46:47  <piscisaureus>(spoor 14, om precies te zijn :-p)
02:47:29  <bnoordhuis>ik kan er om 18:46 zijn dus dat sluit mooi aan
02:47:35  <piscisaureus>mooi
02:47:40  <bnoordhuis>jij komt zeker uit a'dam?
02:47:43  <piscisaureus>yep
02:48:00  <bnoordhuis>da's ook het enige goeie wat er uit 020 komt
02:48:01  <bnoordhuis>de sneltrein
02:48:14  <piscisaureus>bah
02:48:16  <piscisaureus>bnoordhuis!
02:48:18  <bnoordhuis>ja, die ben is mij er eentje
02:52:23  <CIA-53>node: Ben Noordhuis master * rfa44659 / test/common.js : test: fix typo in error message - http://git.io/M_OF1w
02:52:59  <bnoordhuis>okee, bedtijd!
02:53:02  <bnoordhuis>sleep tight, people
02:53:30  * bnoordhuisquit (Quit: Leaving)
03:39:30  * bradleymeckjoined
03:47:16  <bradleymeck>ryah is there a reason dlsym is calculating the node_module_struct's dlsym using the path of the .node file? I am working on pulling in dlls on windows and exporting things with slashes seems complex to resolve
03:58:19  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
04:15:48  * isaacsjoined
04:22:40  * isaacsquit (Quit: isaacs)
04:23:41  <indutny>good evening
04:35:30  * dmkbot1quit (*.net *.split)
04:35:31  * indutnyquit (*.net *.split)
04:44:04  * dmkbot1joined
04:44:04  * indutnyjoined
04:44:07  * DrPizzaquit (Excess Flood)
04:44:14  * DrPizzajoined
04:45:26  * isaacsjoined
04:48:29  <indutny>bradleymeck: yt?
04:59:47  <indutny>bradleymeck: it's getting basename of .node file and using it as symstr (actually, %filename%_module )
05:00:14  <indutny>bradleymeck: so only problem I see here is "/" vs "\" problem
05:00:35  <indutny>bradleymeck: I think that should be platform specific, probably, use libuv bindings
05:01:43  <indutny>bradleymeck: ok, no bindings in libuv atm :)
05:02:05  <indutny>ryah: is it reasonable for libuv to have cross-platform basename bindings?
05:03:06  <indutny>ryah: http://msdn.microsoft.com/en-us/library/e737s6tf.aspx can be used for that
05:03:09  <indutny>on win
05:06:30  * isaacs_joined
05:06:31  * isaacsquit (Read error: Connection reset by peer)
05:06:31  * isaacs_changed nick to isaacs
05:19:49  * isaacsquit (Quit: isaacs)
05:24:19  * pquernaquit (Read error: Connection reset by peer)
05:47:52  * pquernajoined
06:05:18  * erickt_joined
07:20:24  * mralephjoined
08:07:27  * mikealquit (Quit: Leaving.)
08:41:37  * mralephquit (Quit: Leaving.)
09:10:02  * mralephjoined
09:16:13  * mralephquit (Quit: Leaving.)
10:03:19  * piscisaureusjoined
10:37:06  <CIA-53>node: Alexandre Turpin master * r628fa9e / doc/api/buffers.markdown :
10:37:06  <CIA-53>node: docs: Added missing parenthesis to buffer.readUInt8 example.
10:37:06  <CIA-53>node: Fixes #1790. - http://git.io/AJmPRA
10:40:53  * dmkbot1quit (Remote host closed the connection)
10:41:00  * dmkbotjoined
10:52:03  <CIA-53>node: Marco Rogers v0.4 * r3fc01d9 / doc/api/child_processes.markdown :
10:52:03  <CIA-53>node: docs: note about empty environment in child processes
10:52:03  <CIA-53>node: Fixes #1794. - http://git.io/eDXPbQ
11:21:48  * dmkbotquit (Remote host closed the connection)
11:21:52  * dmkbotjoined
11:49:54  * dmkbotquit (Remote host closed the connection)
11:49:58  * dmkbotjoined
11:59:33  * bnoordhuisjoined
12:44:09  <piscisaureus>bnoordhuis: !
12:45:01  <indutny>piscisaureus: !
12:45:04  <indutny>haha :)
12:45:07  <indutny>good morning everyone
12:45:14  <piscisaureus>morning?
12:45:15  <piscisaureus>hehe
12:45:16  <piscisaureus>not quite
12:45:28  <indutny>piscisaureus: in which TZ are you?
12:45:31  <indutny>Germany?
12:45:34  <piscisaureus>CEST
12:45:35  <piscisaureus>yes
12:46:16  <indutny>cool
12:46:17  <indutny>close to me
12:46:19  <indutny>UTC+7
12:46:28  <indutny>much closer than NY or SF :D
12:46:30  <indutny>at least
12:47:30  <piscisaureus>that 5 hours is a lot of differenec
12:47:37  <indutny>piscisaureus: bradleymeck raised question about windows native module support
12:47:52  <bradleymeck>its working, but i have to get tooling to work w/ it
12:48:16  <bradleymeck>the basename detection for node is not xplatform though
12:48:22  <indutny>so my question is should we add uv_basename() ?
12:48:41  <piscisaureus>what's wrong with the basename detection
12:48:52  <piscisaureus>you mean path.basename?
12:48:56  <bradleymeck>wrong type of slashes SYMSTR=C:\Users\bradley\Documents\issues\hellonode_module when '/' is being searched for
12:49:04  <bradleymeck>in node.cc
12:49:25  <piscisaureus>aaah
12:49:25  <indutny>yep
12:49:32  <piscisaureus>yes we could add that to libuv
12:49:34  <indutny>and I think we need uv_dlsym
12:49:37  <indutny>or something like that
12:49:41  <indutny>that'll wrap LoadLibrary for windows
12:49:47  <indutny>and work closs-platform too
12:50:06  <indutny>what's your opinion on this question (cc bnoordhuis )
12:50:07  <piscisaureus>bradleymeck: so were you able to correctly access v8 and libuv exports in node.exe from your module?
12:50:13  <bradleymeck>the pointers are not going to be happy though with FARPROC vs void*
12:50:16  <piscisaureus>bradleymeck: or are you using a v8 and libuv dll
12:50:29  <indutny>piscisaureus: that's about node.js :)
12:50:38  <indutny>piscisaureus: https://github.com/joyent/node/blob/master/src/node.cc#L1643-1664
12:50:43  <bradleymeck>piscisaureus it linked havent tried, but thats just changing the linking
12:50:45  <indutny>piscisaureus: this code is loading ".node" native modules
12:51:00  <indutny>piscisaureus: aah, sorry, missed point
12:51:43  <piscisaureus>yes we need to add that to libuv
12:52:18  <indutny>piscisaureus: both basename and linking stuff?
12:52:45  <piscisaureus>I don't consider basename that important but it's fine to add it if needed
12:52:55  <piscisaureus>uv_dl() would be nice though
12:53:57  <indutny>heh, cool
12:54:26  <indutny>I think I should be able to implement this.
12:54:30  <bradleymeck>ok i gtg get breakfast, going to have to work on other stuff most of today so ill get back to this tonight. The tooling to get this working nicely is going to be painful.
12:54:54  <piscisaureus>bradleymeck: I'll be interested to learn if you can use v8 and libuv methods from your extension
12:56:07  <piscisaureus>phew... time sheets almost done
12:56:56  <piscisaureus>rackspace A/P is getting really nervous now
13:01:08  <bradleymeck>piscisaureus ran a quick test and i cant use em but ill try a static linked lib instead of dynamic later
13:01:19  <bradleymeck>A/P?
13:08:45  * jmp0quit (*.net *.split)
13:09:20  <piscisaureus>bradleymeck: this is the real problem you need to solve for use: how can we use exports from node.exe :-/
13:09:40  <bradleymeck>ill figure it out
13:09:45  <bradleymeck>will just take a long while
13:10:15  <piscisaureus>no worries
13:10:43  * jmp0joined
13:10:48  <piscisaureus>once this moves to the top of our priority list we'll get back to you :-)
13:11:22  <indutny>haha
13:11:50  <indutny>piscisaureus: priority things are always reaching right people in right time :P
13:11:55  <piscisaureus>It's kinda important though
13:12:04  <indutny>yeah
13:12:07  <indutny>native modules on win
13:12:15  <bradleymeck>yea, but we may end up having to do something hacky to support it
13:12:16  <indutny>sounds like a task for nodejitsu team members :P
13:12:17  <indutny>haha
13:12:34  <bradleymeck>window's loader is not happy with the idea of linking against an exe generally
13:12:50  <indutny>bradleymeck: may be create node.dll ?
13:12:55  <indutny>bradleymeck: and use it from node.exe
13:13:01  <piscisaureus>I'm not happy with that idea
13:13:05  <indutny>piscisaureus: me too
13:13:14  <indutny>but sounds that windows won't support other
13:13:21  <indutny>s/that/like
13:13:29  <piscisaureus>I don't really believe that
13:13:45  <indutny>lets see :P
13:13:59  <bradleymeck>it can support a node.dll that both the plugin and the exe pull from, but you face similar problems that you can't static link nicely to stuff outside of your dll
13:14:00  * pquernaquit (Changing host)
13:14:00  * pquernajoined
13:14:52  <piscisaureus>I'm gonna ask Garett - he ususally knows this stuff
13:35:09  * felixgejoined
13:35:09  * felixgequit (Changing host)
13:35:09  * felixgejoined
13:38:37  <DrPizza>linking against a .exe should be fine, afaik
13:38:47  <CIA-53>libuv: saghul master * rb594dba / src/unix/core.c : unix: fix memcpy when copying hints on uv_getaddrinfo - http://git.io/IKdmXQ
13:39:56  <DrPizza>piscisaureus: however, the traditional plugin model (.exe loads plugin .dll, initializes plugin .dll by hadning it a load of function pointers) seems reasonable
13:40:20  <CIA-53>libuv: Ben Noordhuis master * re53d125 / (.mailmap AUTHORS): Update AUTHORS and .mailmap - http://git.io/8PcU_w
13:40:56  <bradleymeck>DrPizza the problem is the way it works right now is you have full access to all the structures in v8 and node rather than a small number of functions to work with.
13:41:06  <bradleymeck>on posix*
13:41:08  <indutny>bradleymeck: thanks
13:41:26  <DrPizza>bradleymeck: huh, that seems kinda crazy to me
13:41:38  <DrPizza>sounds like a good way of writing really fragile plugins
13:41:41  <indutny>bradleymeck: oops, that was not for you
13:41:44  <indutny>bnoordhuis: thanks
13:41:53  <indutny>bradleymeck: is that really a problem?
13:42:16  <indutny>I mean it's good to have limited APIs
13:42:23  <indutny>but does it really cause any problem now?
13:42:49  <bradleymeck>drpizza, its just a static linking really. i think fragile plugins are fine as long as you compile them against the lib on each machine. passing plugins around is more dangerous to me than forcing recompiles
13:43:24  <piscisaureus>bradleymeck: you can't really link libuv and v8 statically
13:43:37  <piscisaureus>to your plugin
13:43:58  <piscisaureus>because they both have global state and you don't want 2 copies of that in your process
13:44:27  <bradleymeck>true, but in terms of how it acts it appears static linked when talking about using structs
13:44:32  <DrPizza>I mean, there's nothing wrong with a .exe having a load of exported symbosl
13:44:38  <DrPizza>and linking against them
13:44:41  <DrPizza>that's fine and normal
13:44:45  <indutny>DrPizza: fully agreed
13:44:50  <piscisaureus>DrPizza: exactly. that's what I want
13:45:29  <piscisaureus>DrPizza: the thing is, we need to create a .lib file that has stubs for everything node.exe exports
13:45:38  <piscisaureus>I don't exactly know how to do that
13:45:46  <DrPizza>node.exe doesn't export anything at the moment
13:45:59  <DrPizza>problem solved!
13:46:02  <piscisaureus>DrPizza: true - but that needs to be changed
13:46:13  <DrPizza>the first step will be to make it export things that you want to export
13:46:38  <piscisaureus>we'll have to force v8 to export stuff
13:46:42  <DrPizza>I suspect that for our purposes, creating a .def file is probably the easiest route
13:47:11  <piscisaureus>I am totally unfamiliar with this
13:47:42  <piscisaureus>I assume we can just run some tool agains node.exe and get a list of all exports?
13:47:43  <DrPizza>http://msdn.microsoft.com/en-us/library/hyx1zcd3%28v=VS.100%29.aspx
13:47:49  <DrPizza>no, node.exe has no exports.
13:48:03  <DrPizza>creating .def file will export the symbols named in the .def file
13:48:26  <indutny>DrPizza: omg
13:48:48  <DrPizza>but each exported function will need to be named explicitly
13:48:59  <indutny>DrPizza: that was really scary :)
13:49:04  <piscisaureus>I wonder how that works for c++
13:49:08  <indutny>we need some auto-generate tool
13:49:16  <DrPizza>piscisaureus: you can list mangled names
13:53:16  <DrPizza>piscisaureus: IIRC, once you have some exports (whether through the .def or through declspec(dllexport) or whatever), link.exe produces a .lib automatically
13:53:19  <DrPizza>even if it's a .exe
13:53:36  <piscisaureus>ah. that'd be nice
13:54:06  <DrPizza>http://msdn.microsoft.com/en-us/library/f0z8kac4.aspx
13:54:07  <piscisaureus>I wonder if we can trick v8 into dllexporting stuff but still link it statically
13:54:17  <DrPizza>"When you link a program (either an executable file or a DLL) that contains exports, LINK automatically creates an import library that describes the exports."
13:54:32  <piscisaureus>I mean, I want to be able to create a libuv dll anyway
13:54:52  <piscisaureus>that's kind of nice
13:55:04  <piscisaureus>I'd like to generate this lib as part of our build process
13:55:15  <DrPizza>right so, create a .def file
13:55:34  <piscisaureus>can we automate that? :-)
13:56:08  <DrPizza>you can dump the symbol names found in a .obj I believe
13:57:16  <DrPizza>those are the same symbol names that are used in the .def file
13:57:35  <DrPizza>but the output will probably need massaging to get it into the right format for .def fles
13:58:46  <DrPizza>piscisaureus: try dumpbin /linkermember some-v8-obj.obj
13:59:17  <DrPizza>oh hmmmm
13:59:20  <DrPizza>that wont' work with LTCG
13:59:22  * DrPizzascowls
13:59:40  * felixgequit (Quit: felixge)
14:03:04  <bradleymeck>you just have to set the flags right in v8
14:03:40  <DrPizza>bradleymeck: yes, but v8 may not let you do that witohut actually generating a .dll
14:06:21  * felixgejoined
14:06:21  * felixgequit (Changing host)
14:06:21  * felixgejoined
14:06:40  <piscisaureus>meh
14:09:04  * piscisaureusquit (Read error: Connection reset by peer)
14:09:07  * piscisaureus_joined
14:09:20  * piscisaureus_changed nick to piscisaureus
14:09:50  <indutny>ohhh
14:09:51  * bradleymeckquit (Ping timeout: 248 seconds)
14:10:01  <indutny>piscisaureus: looks like uptime thing in node.js was system-wide
14:10:09  <indutny>piscisaureus: not app's uptime
14:10:13  <piscisaureus>hmm
14:10:14  <piscisaureus>ok
14:10:23  <indutny>piscisaureus: looks like uv_uptime should be so
14:10:24  <piscisaureus>I guess there's a windows api for that
14:10:31  <indutny>yeah
14:11:02  <indutny>GetTickCount()
14:11:36  <DrPizza>no
14:11:50  <DrPizza>it should dynamically link to GetTickCount64() if available (Vista/2008 up)
14:11:58  <DrPizza>and only use GetTickCount if there's no alternative
14:12:02  <indutny>hm...
14:12:05  <indutny>right
14:12:43  <DrPizza>orrrrr
14:12:53  <indutny>DrPizza: should I check _WIN32_WINNT ?
14:12:59  <DrPizza>no
14:13:01  <DrPizza>dynamic link
14:13:16  <indutny>oh
14:13:29  <DrPizza>GetProcAddress(GetModuleHandle("kernel32.dll"), "GetTickCount64")
14:13:57  <indutny>DrPizza: hm....
14:14:00  <indutny>I don't like that
14:14:11  <indutny>we'll need FARPROC in uv_loop_s
14:14:17  <indutny>to save it
14:14:21  <DrPizza>what do you mean, you don't like it
14:14:26  <DrPizza>we already load other functions
14:14:41  <indutny>DrPizza: wow, really...
14:14:43  <indutny>:)
14:14:56  <DrPizza>I mean, what do you suggest?
14:15:18  <DrPizza>unless the server 2003 requirement has been shitcanned (which I'd love), GetProcAddress is the only safe approach
14:15:19  <indutny>nothing, looking at your code
14:15:33  <indutny>DrPizza: yep, defining constant should be better
14:15:39  <DrPizza>what constant
14:15:40  <indutny>DrPizza: but we need to do check in build system
14:15:43  <DrPizza>no
14:15:52  <indutny>DrPizza: why not?
14:15:58  <DrPizza>there is no compile-time constant that tells you what the runtime system is
14:16:23  <indutny>DrPizza: aah, forgot that most of users will use builded version of app
14:16:28  <indutny>DrPizza: windows is so strange
14:16:44  <indutny>DrPizza: right, dynamic linking should be fine, I'll see how it's already implemented in libuv, thanks
14:17:39  * felixge_joined
14:17:39  * felixge_quit (Changing host)
14:17:39  * felixge_joined
14:20:48  * felixgequit (Ping timeout: 255 seconds)
14:28:52  * felixge_quit (Read error: Connection reset by peer)
14:35:41  * erickt_quit (Quit: erickt_)
14:35:59  <indutny>DrPizza: are you libuv core member?
14:36:02  * bradleymeckjoined
14:36:31  <DrPizza>no, just an occasional contributor who knows about windows
14:36:38  <indutny>DrPizza: great
14:37:21  <indutny>DrPizza: can you take a look at this? https://github.com/joyent/libuv/pull/203
14:37:55  <bradleymeck>so going to throw up a patch to v8 tonight to allow this w/o all the hacking then going to keep moving tonight, gotta get work...
14:38:17  <indutny>bradleymeck++
14:40:42  <DrPizza>indutny: looks reasonable
14:40:50  <indutny>DrPizza: thanks
14:40:52  <indutny>piscisaureus: yt?
14:40:57  <piscisaureus>yes
14:41:00  <indutny>piscisaureus: https://github.com/joyent/libuv/pull/203
14:41:11  <DrPizza>indutny: my only other thought is, does HKEY_PERFORMANCE_DATA have an uptime value
14:41:12  <indutny>just as what node needs ;)
14:41:17  <DrPizza>and if so, does it have a non-wrapping value
14:41:25  <piscisaureus>indutny: yes, I saw that
14:41:44  <piscisaureus>indutny: the windows implementation is reasonable, but wrapping uptime is not ideal
14:42:05  <indutny>piscisaureus: where?
14:42:09  <piscisaureus>uv_now() also relies on GetTickCount but there's special protection against wrapping
14:42:18  <piscisaureus>but too bad, it's tied to a loop :-9
14:42:21  <piscisaureus>:-(
14:42:27  <piscisaureus>indutny: it wraps after 56 days or so?
14:42:30  <piscisaureus>GetTickCount
14:42:35  <indutny>GetTickCount64 doesn't
14:42:39  <indutny>thanks to DrPizza
14:42:46  <indutny>piscisaureus: I've dynamic linking in my patch
14:42:54  <indutny>piscisaureus: it'll try to use GetTickCount64 if possible
14:43:00  <piscisaureus>indutny: sure -
14:43:15  <piscisaureus>indutny: so it won't wrap on all windows versions, but it'll still wrap
14:43:35  <DrPizza>yes, but unless the registry has a better counter
14:43:38  <DrPizza>you can't avoid wrapping
14:43:39  <piscisaureus>I guess it's fine for now, but we have to figure a better way at some point
14:43:52  <DrPizza>since you don't even know how close to system start node was run
14:43:58  <DrPizza>it could already have wrapped before starting node
14:44:20  <piscisaureus>DrPizza: yes - uv_now() can't prevent that
14:44:25  <piscisaureus>so that's no go
14:44:26  <DrPizza>I mean there are two things
14:44:33  <DrPizza>1) you want it to be monotonic
14:44:35  <piscisaureus>can't we get the system start time somehow
14:44:39  <DrPizza>2) you want it to accurately represent the uptime
14:44:44  * felixgejoined
14:44:44  * felixgequit (Changing host)
14:44:44  * felixgejoined
14:44:55  <indutny>piscisaureus: HKEY_PERFORMANCE_DATA
14:45:01  <indutny>I think this is solution
14:45:14  <piscisaureus>why can't I browse that using regedit?
14:45:19  <piscisaureus>DrPizza: ^ tricks?
14:45:23  <DrPizza>bceause it's dynamic
14:45:29  <DrPizza>"browse" it using perfmon
14:45:31  <DrPizza>it's a PITA
14:46:12  <indutny>piscisaureus: http://msdn.microsoft.com/en-us/library/windows/desktop/aa373083(v=vs.85).aspx
14:47:19  <indutny>trying to figure out correct key for uptime
14:47:53  <DrPizza>I think the registry is easier than the API for this
14:47:54  <DrPizza>but maybe not
14:49:15  * felixgequit (Client Quit)
14:49:32  <DrPizza>RegQueryValueEx(HKEY_PERFORMANCE_DATA, "System Up Time", NULL, NULL, buffer, &bufferSize);
14:49:39  <indutny>oh
14:49:40  <indutny>nice
14:49:55  <indutny>lets try it
14:50:43  <indutny>http://www.michael-puff.de/Programmierung/Delphi/Code-Snippets/GetTickCountEx.shtml
14:51:33  <indutny>fck delphi
14:52:29  <indutny>that's much better: http://ssp.shillest.net/tmp/UpTime.cpp
14:52:44  <indutny>with japanese comets
14:52:48  <indutny>s/comet/comments
14:53:20  <indutny>DrPizza: why all examples I found are much more complex than just one line?
14:54:25  <DrPizza>because performance counters are a pain
14:54:43  <indutny>heh
14:55:01  <indutny>probably that's not so bad to have function that wraps on old versions of OS ?
14:55:19  <DrPizza>no, we only need 2003 and up
14:55:23  <DrPizza>so the same code can b eused for everything
14:55:45  <indutny>yes
14:56:00  <indutny>but 49.7 days doesn't sounds very bad
14:56:13  <indutny>just different behaviour on old versions of Windows ( pre-Vista)
14:56:38  <indutny>most of users will build id on Windows 7 (or 2008 server)
14:56:57  <DrPizza>right but doing the registry/PDH approach works on all systems
14:57:02  <DrPizza>so there's no point in having two code paths
14:58:17  <indutny>ok, time for some winapi pain
14:58:44  <DrPizza>ugh, I'd forgotten how much this stuff all sucked
14:59:33  <DrPizza>the japanese code looks right except for some details
14:59:45  <DrPizza>e.g. you don't need to regclosekey HKEY_PERFORMANCE_DATA
15:05:46  * piscisaureusgone
15:06:12  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
15:27:32  <rmustacc>Given that you have to look at that with perfmon, is that actually using the CPU performance counters to get the uptime?
15:27:37  <rmustacc>Or is it just confusingly named.
15:28:38  <rmustacc>If the former, isn't that going to break under most virtualization?
15:28:45  <DrPizza>no
15:28:54  <rmustacc>Ah good.
16:00:33  * bnoordhuisquit (Ping timeout: 252 seconds)
16:02:40  * piscisaureusjoined
16:27:17  * isaacsjoined
16:42:51  <ryah>isaacs: npm/unix okay on HEAD?
16:43:07  <isaacs>ryah: not sure
16:43:16  <isaacs>pulling now
16:45:17  <isaacs>ryah: https://gist.github.com/1251227 trying again after a distclean
16:45:47  * piscisaureusquit (Ping timeout: 258 seconds)
16:47:09  <ryah>isaacs: we're running on top of the new tty code now - so escape sequences should work in windows
16:47:19  * Casanjoined
16:47:23  <isaacs>that's pretty awesome
16:47:34  <isaacs>glad i never bothered to learn how to do that stuff in windows :)
16:48:01  <ryah>yeah - in windows you basically do ioctls to change color
16:48:02  <Casan>hi thanks, been looking forward to get node running
16:48:05  <ryah>it's pretty aweful
16:48:12  <isaacs>ryah: Casan here is having some issues building from head in freebsd
16:48:34  <ryah>Casan: gist us your error
16:48:49  <isaacs>https://gist.github.com/1251229
16:48:54  <isaacs>^casan's error
16:49:19  <indutny>ryah: hi!
16:49:39  <indutny>isaacs: what problems?
16:49:41  <Casan>update https://gist.github.com/1251242
16:49:43  <ryah>doesn't look like a problem
16:50:10  <indutny>Error 1 (ignored) is not a problem
16:50:42  <indutny>ryah: can you please remind me - do we have a debugger issues that I need to fix?
16:50:43  <Casan>with v0.5.7 there was, but now with this it looks better. I will continue with gmake install
16:51:08  <indutny>ryah: or only .watch()/.unwatch() thing?
16:51:32  <ryah>indutny: i haven't been debugging js lately - so i haven't run into anything
16:51:48  <indutny>ryah: ok, I meant any old issues
16:51:52  <indutny>but anyway thanks
16:51:59  <isaacs>ryah: after dist-clean: https://gist.github.com/1251250
16:52:21  <isaacs>oh joyent/master
16:52:27  <isaacs>s/oh/on
16:52:32  <ryah>isaacs: hm
16:52:40  <ryah>isaacs: are you sure you distcleaned ? :)
16:52:48  <isaacs>yep
16:52:56  <ryah>one sec...
16:52:59  <isaacs>make distclean && ./configure --debug && make install
16:53:18  <CIA-53>node: Ryan Dahl master * r005448b / Makefile : Don't ls node_g after make - it confuses people - http://git.io/_hmHZg
16:54:02  <Casan>ok, now it seems like it completed nicely. so consider it a successful manual testing report :) https://gist.github.com/1251255
16:54:55  <ryah>isaacs: yeah - this error is rather strange
16:55:04  <ryah>isaacs: are you on HEAD?
16:55:11  <isaacs>ryah: 005448bdeb5b34761780ddf600c621315945d541
16:55:17  <ryah>://
16:55:21  <ryah>osx?
16:55:34  <isaacs>yep
16:55:41  <ryah>O_O
16:55:44  <Casan>only concern is: Checking for library dl : not found
16:55:45  <Casan>Checking for openssl : not found (openssl is a part of the system in fbsd)
16:55:45  <Casan>Checking for fdatasync(2) with c++ : no
16:56:34  <ryah>isaacs:
16:56:34  <ryah>% ls -l out/Release/deps/uv/uv.a
16:56:35  <ryah>-rw-r--r-- 1 ryan staff 930664 Sep 29 09:53 out/Release/deps/uv/uv.a
16:56:54  <ryah>% md5 out/Release/deps/uv/include/uv.h
16:56:54  <ryah>MD5 (out/Release/deps/uv/include/uv.h) = 5231e86b25e2574a45a0082ac886c46f
16:57:01  <isaacs>$ ls -l out/Release/deps/uv/uv.a
16:57:02  <isaacs>-rw-r--r-- 1 isaacs staff 924928 Sep 29 09:55 out/Release/deps/uv/uv.a
16:57:12  <isaacs>$ md5 out/Release/deps/uv/include/uv.h
16:57:12  <isaacs>MD5 (out/Release/deps/uv/include/uv.h) = 5231e86b25e2574a45a0082ac886c46f
16:57:19  <ryah>wtf
16:58:25  <isaacs>i have to head out for a few. i'll be back online a little bit later.
16:58:59  <ryah>k
16:59:59  * isaacsquit (Quit: isaacs)
17:21:31  * bradleymeckquit (Ping timeout: 258 seconds)
17:27:29  <CIA-53>libuv: Ryan Dahl ipc * r72d8d76 / (4 files): wip - http://git.io/BSbAUQ
17:27:29  <CIA-53>libuv: Ryan Dahl ipc * r32151d5 / (13 files in 4 dirs): Add argument to uv_pipe_init for IPC - http://git.io/T25aRA
17:28:27  <indutny>interesting....
17:29:31  * dmkbotquit (Remote host closed the connection)
17:29:36  * dmkbotjoined
17:35:38  * dmkbotquit (Remote host closed the connection)
17:35:43  * dmkbotjoined
17:43:24  <CIA-53>libuv: Ryan Dahl ipc * r73047ab / test/run-tests.c : Add server to ipc_helper - http://git.io/nqNp1w
17:43:25  <CIA-53>libuv: Ryan Dahl ipc * r38bcd0f / include/uv.h : Add uv_write2 and uv_read2_start to header file - http://git.io/2Z44Tg
17:45:58  <indutny>hm...
17:46:10  <indutny>is anyone going to fix that annoying tty bug?
17:46:50  <indutny>after `node debug ...` tty is completely unusable
17:48:05  <ryah>indutny: what bug?
17:49:00  <indutny>ryah: I think tty's mode remain dirty after node exit
17:49:05  <indutny>ryah: try it yourself
17:49:13  <ryah>indutny: oh yeah, i know this
17:49:18  <ryah>i'll fix it in two hours
17:49:26  <indutny>great!
17:49:37  <indutny>it's so annoying
17:55:50  <igorzi>ryah: are you planning to add child_process.fork to child_process_uv?
17:56:59  * dmkbotquit (Remote host closed the connection)
17:57:03  * dmkbotjoined
17:58:17  <indutny>ryah: interesting - try opening `repl` and typing `process.stdin.pause()`
17:58:27  <ryah>igorzi: yeah
17:58:56  <ryah>igorzi: previously it was done over a separate channel - but i think given the recent ipc discussions it can be done over stdin
17:59:04  <ryah>(the message passing, that is)
18:00:04  <ryah>seems like ben and bert are not here for the call
18:00:19  <ryah>let's wait a few min..
18:00:39  <igorzi>k
18:01:43  * brsonjoined
18:18:01  * isaacsjoined
18:32:48  <ryah>igorzi: do you need to save the send_handle on uv_write_t ?
18:32:53  <ryah>igorzi: we can just have a shared member
18:33:05  <ryah>(shared between unix/win)
18:34:53  <igorzi>ryah: yep, i do need to save it, so having a shared member would be good
18:35:15  * dmkbotquit (Remote host closed the connection)
18:35:19  * dmkbotjoined
18:35:37  <indutny>ryah: https://github.com/joyent/node/pull/1800 ;)
18:35:43  <indutny>even with tests!
18:35:46  <CIA-53>node: Ryan Dahl master * r84641fc / wscript : WAF: Clean out/Release/deps/uv before build - http://git.io/S6Vu1A
18:37:31  <indutny>brb
18:45:14  * bradleymeckjoined
18:46:37  * dmkbotquit (Remote host closed the connection)
18:46:41  * dmkbotjoined
18:49:27  * isaacsquit (Quit: isaacs)
18:50:16  <CIA-53>libuv: Ryan Dahl ipc * r24399c5 / (include/uv.h src/unix/stream.c): unix: implement uv_write2 - http://git.io/x-GHOQ
19:00:57  * erickt_joined
19:01:01  * pquernaquit (Ping timeout: 240 seconds)
19:06:50  * pquernajoined
19:11:15  * pquernaquit (Ping timeout: 260 seconds)
19:12:14  * pquernajoined
19:23:24  * mralephjoined
19:25:42  * pquernaquit (Ping timeout: 258 seconds)
19:26:00  * pquerna_joined
19:30:30  * pquerna_quit (Ping timeout: 256 seconds)
19:37:35  * pquernajoined
19:44:02  * pquernaquit (Ping timeout: 258 seconds)
19:44:35  * pquernajoined
19:50:02  * Casanquit (Quit: Leaving)
19:54:43  * dmkbotquit (Remote host closed the connection)
19:54:50  * dmkbotjoined
19:56:00  * pquernaquit (Ping timeout: 258 seconds)
20:00:21  * pquernajoined
20:01:06  * pquernaquit (Changing host)
20:01:07  * pquernajoined
20:01:44  * Casanjoined
20:07:22  * pquernaquit (Remote host closed the connection)
20:09:04  * isaacsjoined
20:10:14  * isaacsquit (Client Quit)
20:12:38  * isaacsjoined
20:12:38  * pquernajoined
20:13:50  * igorziquit (Ping timeout: 252 seconds)
20:22:08  * dmkbotquit (Remote host closed the connection)
20:22:28  * dmkbotjoined
20:41:00  * dmkbotquit (Remote host closed the connection)
20:41:05  * dmkbotjoined
20:44:47  * dmkbotquit (Remote host closed the connection)
20:44:52  * dmkbotjoined
20:45:19  * dmkbotquit (Remote host closed the connection)
20:45:23  * dmkbotjoined
20:45:50  * dmkbotquit (Remote host closed the connection)
20:45:54  * dmkbotjoined
20:47:06  * dmkbotquit (Remote host closed the connection)
20:47:10  * dmkbotjoined
20:52:26  <ryah>somehow when i send an fd my process starts spinning uncontrolably
20:52:59  <ryah>43403/0xddf0e: setsockopt(13, 65535, 4) = 0 0
20:53:00  <ryah>43403/0xddf0e: bind(13, 140734799805208, 16) = 0 0
20:53:00  <ryah>43403/0xddf0e: listen(13, 12, 4294973022) = 0 0
20:53:00  <ryah>43403/0xddf0e: sendmsg(0, 140734799804912, 0) = 6 0
20:53:00  <ryah>43402/0xddf0b: kevent(4, 4296041232, 0) = 1 0
20:53:02  <ryah>43402/0xddf0b: kevent(4, 4296041232, 0) = 1 0
20:53:04  <ryah>43402/0xddf0b: kevent(4, 4296041232, 0) = 1 0
20:53:07  <ryah>43402/0xddf0b: kevent(4, 4296041232, 0) = 1 0
20:53:09  <ryah>43402/0xddf0b: kevent(4, 4296041232, 0) = 1 0
20:53:12  <ryah>43402/0xddf0b: kevent(4, 4296041232, 0) = 1 0
20:53:14  <ryah>43402/0xddf0b: kevent(4, 4296041232, 0) = 1 0
20:53:17  <ryah>43402/0xddf0b: kevent(4, 4296041232, 0) = 1 0
20:53:19  <ryah>43402/0xddf0b: kevent(4, 4296041232, 0) = 1 0
20:53:22  <ryah>43402/0xddf0b: kevent(4, 4296041232, 0) = 1 0
20:53:24  <ryah>43402/0xddf0b: kevent(4, 4296041232, 0) = 1 0
20:53:27  <ryah>43402/0xddf0b: kevent(4, 4296041232, 0) = 1 0
20:53:29  <ryah>43402/0xddf0b: kevent(4, 4296041232, 0) = 1 0
20:53:32  <ryah>43402/0xddf0b: kevent(4, 4296041232, 0) = 1 0
20:53:34  <ryah>43402/0xddf0b: kevent(4, 4296041232, 0) = 1 0
20:53:37  <ryah>43402/0xddf0b: kevent(4, 4296041232, 0) = 1 0
20:53:39  <ryah>43402/0xddf0b: kevent(4, 4296041232, 0) = 1 0
20:53:42  <ryah>sigh
20:59:06  * isaacsquit (Quit: isaacs)
21:09:07  * dmkbotquit (Remote host closed the connection)
21:09:16  * dmkbotjoined
21:14:22  <bradleymeck>well got the windows .node to be able to use v8::*, 48k filesize compared to node's 10mb in debug so thats good
21:17:05  <bradleymeck>ryah would it be possible to have a LIBUV_EXPORT that sets the appropriate macros for externs in windows? I know we have several externs already but declspec in windows is needed to actually export symbols, i can write up the patches I guess
21:17:16  <DrPizza>no it isn't.
21:17:31  <DrPizza>you don't need declspec to export a symbol.
21:17:33  <bradleymeck>its the recommended way
21:17:36  <DrPizza>You can do it with a .def.
21:17:57  <bradleymeck>i read up that .def is frowned upon
21:18:03  <bradleymeck>idk why though
21:18:10  <DrPizza>that is news to me
21:18:38  <bradleymeck>my only guess would be because you have to keep .def files up to date outside of declarations in headers
21:18:50  <DrPizza>yes, but otoh .def files can do things that dllexport cannot
21:19:03  <DrPizza>such as rename exported symbols, force a particular export order, export by ordinal, etc.
21:19:56  <bradleymeck>i didnt need those when doing that for prototype, not sure id want to change exports anyway, that would just add a layer of confusion to coders i would think
21:20:42  <DrPizza>it lets you do things like rename functions whilst exporting them under both their old and new names
21:20:56  <DrPizza>ordinal exports are faster to link against
21:21:08  <DrPizza>all useful things.
21:21:10  <bradleymeck>you mean bound exports?
21:21:29  <DrPizza>ordinal exports
21:21:38  <DrPizza>you can link by ordinal (number) rather than name
21:21:52  * bradleymeckgoes to read
21:27:09  <bradleymeck>DrPizza, interesting, but since i am not using dlsym from the plugin after linking, i think it would only work for when node looks up the symbol for init in the plugin
21:27:41  <DrPizza>I think implicit linking can still occur by ordinal too
21:29:54  <bradleymeck>looks like implicit linking is always done through ordinal... interesting...
21:30:25  <bradleymeck>i guess when i linked against the .lib generated for the .exe it just did it by ordinal even though it was originally exported by name
21:34:04  <DrPizza>yes possibly
21:34:19  <DrPizza>that would make some sense
21:35:03  <bradleymeck>cant find reference to assure that on msdn but other random sites say it so it must be true!
21:37:16  * igorzijoined
21:37:42  <indutny>ryah: yt?
21:45:34  <ryah>indutny: yo
21:46:22  <indutny>ryah: https://github.com/joyent/node/blob/master/lib/http2.js#L601
21:46:28  <indutny>ryah: why do we need this check?
21:46:37  <indutny>:)
21:46:38  <indutny>hi
21:47:01  * pquernaquit (Changing host)
21:47:01  * pquernajoined
21:51:32  <ryah>indutny: *shrug*
21:51:57  <indutny>ryah: it's causing problems with latests websockets and http-proxy
21:52:09  <indutny>ryah: I think we should consider removing it
21:53:58  <ryah>indutny: how so
21:54:16  <indutny>ryah: 'upgrade' event's argument 'head' is Buffer(0)
21:54:19  <indutny>for latest websockets
21:54:35  <ryah>and?
21:54:36  <indutny>and we're writing it
21:54:39  <indutny>:)
21:54:47  <indutny>and it's not getting wrote
21:55:02  <ryah>*written
21:55:27  <ryah>not convinced
21:55:32  <ryah>'head' is after the upgrade
21:55:55  <ryah>that shouldn't be going through http code
21:56:39  <ryah>bradleymeck: you're trying to build addons on windows?
21:57:59  <bradleymeck>i have built addons on windows
21:58:10  <bradleymeck>it needs cleanup and tooling though
21:58:55  <ryah>bradleymeck: we want to do this with gyp
21:59:13  <ryah>bradleymeck: if you'd like to contribute in this area it would be welcome
21:59:54  <bradleymeck>yea, it seems to work fine from gyp but i need to read up a bit more for figuring out the proper include/link stuff in gyp files
22:00:21  <bradleymeck>i had to use msvs to build the .dll since i didnt know gyp that well
22:00:55  <igorzi>bradleymeck: are you exporting libuv functions through node.exe? or are you building libuv into a dll?
22:01:09  <bradleymeck>through node.exe
22:01:24  <bradleymeck>then using the .lib generated from node.exe
22:01:35  <igorzi>bradleymeck: nice.. do you have a prototype?
22:02:03  <bradleymeck>not ready for deploying out to github but i have it working locally
22:02:27  <igorzi>bradleymeck: i'd like to see it if possible
22:02:58  * dmkbotquit (Remote host closed the connection)
22:02:59  <bradleymeck>tomorrow it should be on my github
22:03:04  * dmkbotjoined
22:13:37  * dmkbotquit (Remote host closed the connection)
22:13:42  * dmkbotjoined
22:22:14  * dmkbotquit (Remote host closed the connection)
22:22:18  * dmkbotjoined
22:35:59  * bradleymeckquit (Ping timeout: 248 seconds)
22:52:21  * dmkbotquit (Remote host closed the connection)
22:52:47  * dmkbotjoined
23:13:26  * bnoordhuisjoined
23:16:13  <bnoordhuis>pingety
23:16:43  <bnoordhuis>can someone give me the executive summary of today's scrum call?
23:17:15  * erickt_quit (Ping timeout: 252 seconds)
23:19:18  <igorzi>bnoordhuis: ryah -> working on ipc for unix; igorzi -> working on ipc for windows.. that's it :)
23:19:33  <bnoordhuis>igorzi: thanks :)
23:20:28  <bnoordhuis>on my part it's generalizing kqueue and optimizing the http bindings
23:21:19  * dmkbotquit (Remote host closed the connection)
23:21:27  * dmkbotjoined
23:26:34  * mralephquit (Quit: Leaving.)
23:39:04  * felixgejoined
23:39:29  * felixgequit (Client Quit)
23:39:33  * brsonquit (Ping timeout: 252 seconds)
23:40:21  <ryah>sweet https://github.com/joyent/libuv/pull/204
23:40:48  <ryah><3 open source
23:47:06  <igorzi>ryah: uv_read2_start is used to read both raw stdin data and fds, right? or does the user need to call both uv_read_start and uv_read2_start to get both?
23:49:23  <bnoordhuis>ryah: heh, you should've seen the discussion in #node.js last night
23:56:22  * indexzerojoined
23:56:24  <rmustacc>bnoordhuis: What happened?
23:56:48  <bnoordhuis>rmustacc: lots of bitching about us dropping udp multicast support
23:56:58  <bnoordhuis>lots of bitching in general, actually
23:57:16  <bnoordhuis>so i said: hey, it's open source, submit a patch
23:59:38  <rmustacc>Ah, yeah. I know that feeling pretty well.