00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:02:23  * mikolalysenkojoined
00:16:07  * quijotejoined
00:20:53  * quijotequit (Ping timeout: 258 seconds)
00:21:36  <othiym23>so looks like 0.12 is going to ship with a non-flagged, busted built-in Promise implementation
00:22:59  * mikolalysenkoquit (Ping timeout: 245 seconds)
00:23:34  <nathan7>othiym23: that's fairly depressing
00:24:03  <nathan7>othiym23: busted how?
00:24:37  <othiym23>nathan7: indeed, but the choices Node has are to a. revert to an older version of V8, b. delay the release of 0.12 until V8 upstream fixes the bugs in their implementation or c. decides fuckit
00:24:53  <nathan7>othiym23: how are they busted
00:25:19  * evantahlerpart
00:25:26  <othiym23>nathan7: sec, finding the gist
00:25:50  <othiym23>nathan7: https://twitter.com/getify/status/463405715575406592
00:27:18  <nathan7>othiym23: oh man, that's fucking gnarly
00:28:00  <nathan7>othiym23: not something I'll hit, but damn
00:28:15  <AvianFlu>I don't even understand what's happening there
00:28:56  * daviddiasquit (Remote host closed the connection)
00:28:59  <othiym23>AvianFlu: lots of weird, but well-documented, edge cases in the Promises/A+ spec around what happens when you pass bare values instead of functions to .then()
00:29:07  <nathan7>it's quite simple, it's doing if (fn != null) or just if (fn) instead of if (typeof fn != 'function')
00:29:17  <AvianFlu>oh
00:29:18  <nathan7>othiym23: how are those spec edge cases?
00:29:22  <AvianFlu>so the erroring case is actually correct?
00:29:32  * daviddiasjoined
00:29:34  <nathan7>no, it should ignore anything non-fn
00:29:39  <AvianFlu>ignore?
00:29:44  <AvianFlu>like "do completely nothing"?
00:29:47  <nathan7>yeah
00:29:48  <AvianFlu>or like "pretend it's null"
00:30:15  * dap_quit (Quit: Leaving.)
00:30:18  <nathan7> this.onFulfilled = typeof onFulfilled === 'function' ? onFulfilled : null
00:30:18  <nathan7> this.onRejected = typeof onRejected === 'function' ? onRejected : null
00:30:26  <nathan7>that's my code in then/promise
00:31:29  * kazuponjoined
00:32:15  * dap_joined
00:33:24  * andrehjrjoined
00:33:49  * daviddiasquit (Ping timeout: 245 seconds)
00:33:55  * kellabytejoined
00:35:42  * AlexisMocha_joined
00:35:50  * kazuponquit (Ping timeout: 255 seconds)
00:37:38  * AlexisMochaquit (Ping timeout: 255 seconds)
00:46:06  * calvinfojoined
00:49:22  * mikolalysenkojoined
00:53:37  * mrvisserquit (Remote host closed the connection)
00:55:06  * mikolalysenkoquit (Ping timeout: 276 seconds)
00:56:13  * petka_quit (Quit: Connection closed for inactivity)
00:57:44  * AlexisMochajoined
00:59:57  * AlexisMocha_quit (Ping timeout: 252 seconds)
01:16:53  * quijotejoined
01:21:19  * quijotequit (Ping timeout: 245 seconds)
01:22:58  <isaacs>tjfontaine: ready to push a npm 1.4.10, working from the "update right after a release, rather than right before one"
01:24:04  <MI6>joyent/node: isaacs v0.10 * 120f7cf : npm: upgrade to 1.4.10 - http://git.io/TSYIGA
01:31:01  * cosnisjoined
01:31:08  * cosnisquit (Max SendQ exceeded)
01:32:14  * kazuponjoined
01:35:56  <tjfontaine>isaacs: changelog link?
01:36:36  <AlsoDirkson>Hi guys! Trying to run my new libuv server. What does this mean? src/unix/stream.c:625: uv_listen: Assertion `0' failed.
01:36:42  * seldo_quit (Remote host closed the connection)
01:36:59  * kazuponquit (Ping timeout: 252 seconds)
01:38:42  <tjfontaine>AlsoDirkson: go to the line number and you'll see what the actual error was
01:38:51  <tjfontaine>AlsoDirkson: but basically you didn't initialize somethign properly
01:39:04  <AlsoDirkson>tjfontaine: Is this a line number within libuv, or something else?
01:39:31  <tjfontaine>that's the file in libuv with the assert()
01:42:05  <isaacs>tjfontaine: i just added to commit message
01:42:24  <isaacs>tjfontaine: i'm using 1.4.10 now, so any issues will spring up, i'm sure
01:42:36  <AlsoDirkson>tjfontaine: Ok. Looks like stream->type wasn't a UV_TCP or a UV_NAMED_PIPE... Somehow. I don't understand how that's possible.
01:42:52  * cosnisjoined
01:42:55  * cosnisquit (Max SendQ exceeded)
01:43:33  * cosnisjoined
01:43:57  * cosnisquit (Max SendQ exceeded)
01:44:35  * cosnisjoined
01:44:38  * cosnisquit (Max SendQ exceeded)
01:45:00  <isaacs>tjfontaine: but also, https://github.com/npm/npm/releases/tag/v1.4.10
01:45:14  <isaacs>tjfontaine: mostly, the intent here is to fix a few minor bugs before we refactor a whole ton of crap
01:45:16  * cosnisjoined
01:45:23  <tjfontaine>so last fix for 0.10?
01:45:48  <tjfontaine>well I guess technically for 0.12 as well -- I mean the intent is to follow normal dependency rules
01:45:54  <isaacs>tjfontaine: sure.
01:46:12  <tjfontaine>and hopefully turn the dial up on node releases if feasible
01:46:24  <tjfontaine>minors that is
01:46:30  <isaacs>tjfontaine: i'll keep updating npm as needed. if you wanna do like a weekly train or something again, then that's fine with me
01:46:52  <isaacs>tjfontaine: it drastically cuts down the threat of each release when they come very quickly
01:46:55  <isaacs>and keeps quality higher, imo
01:47:08  <isaacs>also: https://github.com/joyent/node/pull/7563 <-- artisanal hand-crafted rebase
01:47:13  <tjfontaine>only so long as our downstream users continue to keep up
01:47:23  <tjfontaine>if anyone pins everyone loses
01:47:30  <isaacs>tjfontaine: logs show that people do generally use the most recent node version
01:47:45  <AlsoDirkson>tjfontaine: Got it. I was passing a pointer to a pointer accidentally, rather than simply a pointer, like uv_listen requires.
01:47:47  <isaacs>tjfontaine: judging from user-agent strings hitting the registry. folks are on either latest 0.10 or latest 0.8
01:47:49  <tjfontaine>logs of developers, which is not the same thing as people in production unfortunately -- despite my pleading
01:48:18  <isaacs>tjfontaine: lots of my logs are folks in production. a *shocking* number of people do "npm install" as part of their deployments
01:48:43  <isaacs>tjfontaine: i've seen teh IP blocks of Heroku and AWS sending massive traffic our way :)
01:48:56  <tjfontaine>certainly twitter complaints indicate there are a lot of people doing that -- but it's not all and there are just as many shocking people on out dated versions of 0.10 and 0.8
01:49:08  <isaacs>yeah, there's a few of those.
01:49:23  <isaacs>but still, the best answer is still the same
01:49:31  <AlsoDirkson>tjfontaine: Worth noting that I'm creating a new implementation, but I've decided to do it on the 0.10 branch, because my distro doesn't provide 0.11. You fix that, you'll probably fix a lot of your outdated problems : )
01:49:37  <isaacs>the faster releases come, the less scary they are, and the higher the quality is, and the more likely people are to upgrade.
01:49:55  <tjfontaine>the faster releases come the more resistance there are by some companies to defer
01:50:14  <isaacs>nah, just push out a release every tuesday or something
01:50:24  <isaacs>even if someone's 3 releases behind, they're only going to be a few weeks back, then
01:50:43  <isaacs>and it makes the overall quality rise, which reduces the burden
01:51:23  <tjfontaine>that's not been the feedback from the companies I've been speaking to, but I'm not looking to be slow on releases, I just want releases with quality fixes in them -- not releases to just keep the churn happening
01:51:38  <AlsoDirkson>I think you're likely to see linux adoption mostly following what's available in the distro - And that will vary based on distro. Debian people are always going to be behind archlinux people, for example.
01:51:56  <tjfontaine>AlsoDirkson: you mean binary distros are usually behind source distros
01:52:04  <tjfontaine>AlsoDirkson: that's only true for when they first install it
01:52:43  <tjfontaine>beyond that there's rarely a compelling reason for them to actually upgrade -- until they hit an actual production problem -- then as a first hope they'll upgrade to see if its fixed
01:52:53  <AlsoDirkson>tjfontaine: I think archlinux is a binary distro, mainly. Sure, I'll grant that most source distros are faster than most binary distros, but there's also rolling vs static release cylces, and just plain internal-distro politics.
01:53:29  <AvianFlu>lolololol the bugged CLA bot didn't recognize isaacs XD
01:53:42  <tjfontaine>google docs api is unhappy with my bot
01:53:45  <tjfontaine>I haven't had time to fix it
01:55:22  <AvianFlu>where's the code live?
01:55:30  <AlsoDirkson>tjfontaine: You make a good point that the first line of defense when encountering a potential api bug is to upgrade.
01:55:39  <tjfontaine>the ugly disaster code sits in http://github.com/tjfontaine/jankins
01:59:10  * cosnis_joined
01:59:15  * cosnis_quit (Max SendQ exceeded)
01:59:32  <AvianFlu>how much do you know about the bug?
01:59:57  * cosnis_joined
02:00:02  * cosnis_quit (Max SendQ exceeded)
02:00:19  <tjfontaine>that out of band it seems to work fine, but when doing it with the information provided in a github webhook it seems to fail
02:00:26  <tjfontaine>that is to say
02:00:38  <tjfontaine>if you hit the cla rest api end points you get valid data back
02:00:55  * AlexisMocha_joined
02:00:58  <tjfontaine>but somehow in line of pullrequest.js checking either the github information provided has changed, or the context is wrong
02:02:05  * AlexisMochaquit (Ping timeout: 264 seconds)
02:02:09  * cosnisquit (Ping timeout: 245 seconds)
02:03:40  * cosnisjoined
02:03:44  * cosnisquit (Max SendQ exceeded)
02:04:10  * mrvisserjoined
02:04:13  * brsonjoined
02:04:23  * cosnisjoined
02:09:51  * mrvisserquit (Ping timeout: 276 seconds)
02:17:38  * quijotejoined
02:17:58  * seldo_joined
02:19:12  * AlsoDirksonchanged nick to Dirkson
02:20:13  <AvianFlu>tjfontaine: was there supposed to be an actual line number in that last message?
02:21:54  * quijotequit (Ping timeout: 240 seconds)
02:22:51  * seldo_quit (Ping timeout: 276 seconds)
02:31:42  * rmgquit (Remote host closed the connection)
02:32:55  * cosnisquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
02:32:59  * kazuponjoined
02:33:52  * cosnisjoined
02:33:55  * cosnisquit (Max SendQ exceeded)
02:34:33  * cosnisjoined
02:37:21  * brsonquit (Ping timeout: 258 seconds)
02:37:38  * kazuponquit (Ping timeout: 240 seconds)
02:38:21  * mikolalysenkojoined
02:38:55  * brsonjoined
02:40:15  * mikolalysenkoquit (Read error: Connection reset by peer)
02:43:26  * mikolalysenkojoined
02:45:52  * mikolalysenkoquit (Read error: Connection reset by peer)
02:48:26  * mikolalysenkojoined
02:49:52  * mikolalysenkoquit (Read error: Connection reset by peer)
02:53:24  * mikolalysenkojoined
02:54:46  * mikolalysenkoquit (Read error: Connection reset by peer)
02:55:45  * AlexisMochajoined
02:56:58  * AlexisMocha_quit (Ping timeout: 240 seconds)
02:58:26  * mikolalysenkojoined
02:59:43  * mikolalysenkoquit (Read error: Connection reset by peer)
03:03:27  * mikolalysenkojoined
03:04:27  * bradleymeckjoined
03:04:39  * mikolalysenkoquit (Read error: Connection reset by peer)
03:05:09  * brsonquit (Quit: leaving)
03:05:22  * cosnis_joined
03:06:00  <tjfontaine>AvianFlu: heh no, lemme just spend some time on it
03:06:37  <AvianFlu>I'm happy to take a look, it just looked like you might have left a word out there
03:06:45  <AvianFlu>and if you meant to point to one but left it out I'd want to know XD
03:07:27  * cosnisquit (Ping timeout: 252 seconds)
03:08:27  * mikolalysenkojoined
03:09:00  <Dirkson>When a TCP user disconnects, what exactly is happening? Is there something I'm expected to be doing? (Asking because currently my libuv crashes with an error about trying to close a unknown handle type)
03:09:44  * mikolalysenkoquit (Read error: Connection reset by peer)
03:13:00  <Ralith>Dirkson: https://upload.wikimedia.org/wikipedia/commons/5/55/TCP_CLOSE.svg
03:13:26  * rosskquit
03:13:29  * mikolalysenkojoined
03:13:36  <tjfontaine>trying to close an unknown handle type sounds more like memory corruption though
03:13:44  <Dirkson>Well, drat.
03:13:55  <tjfontaine>but yes familiarize yourself with the OSI layer stuff, and the TCP lifecycle semantics
03:13:56  <Ralith>Dirkson: at the API level, this means that the remote peer shuts down their end of the connection, you need to shut down yours
03:14:21  <Dirkson>Ralith: Right. Is there something in libuv I'm meant to do that with, or is libuv supposed to be taking care of that for me?
03:15:07  * mikolalysenkoquit (Read error: Connection reset by peer)
03:15:59  * AlexisMochaquit (Ping timeout: 265 seconds)
03:16:00  <Ralith>Dirkson: see uv_shutdown
03:16:33  <Ralith>Dirkson: be sure to close after shutting down, too.
03:17:23  <Ralith>shutdown cleanly terminates the TCP connection, ensuring that all of your data gets there first. close frees the local resources.
03:17:45  <Ralith>if you close before shutdown succeeds, you have no guarantee that the data you've written won't get truncated
03:17:59  <AvianFlu>tjfontaine: so I think it might be this https://github.com/tjfontaine/jankins/blob/master/cla.js#L138
03:18:18  <AvianFlu>cause I think that means that a single-email query comes out as "email = email OR"
03:18:25  * quijotejoined
03:18:36  * mikolalysenkojoined
03:18:39  <AvianFlu>I might just be sql nooby though, I can't remember at this point
03:18:56  <tjfontaine>well this isn't technically sql
03:19:26  <AvianFlu>oh you're right
03:19:28  <AvianFlu>it's their api
03:19:34  <AvianFlu>I got confused cause of the sqlite elsewhere
03:19:35  <tjfontaine>but it could well be this
03:19:41  <AvianFlu>still, it stuck out to me
03:19:41  <AvianFlu>yeah
03:19:51  <AvianFlu>it's also a line of code not hit by the rest api
03:20:30  <tjfontaine>yup
03:21:32  <AvianFlu>so how do you test this?
03:21:48  <tjfontaine>point a personal instance at it
03:22:01  <tjfontaine>you can't really test the cla part though, because you need api keys
03:23:14  * quijotequit (Ping timeout: 255 seconds)
03:26:36  * mikolalysenkoquit (Read error: Connection reset by peer)
03:26:54  * mikolalysenkojoined
03:27:07  <AvianFlu>tjfontaine: try this, if you can test it https://github.com/AvianFlu/jankins/compare/tjfontaine:master...master
03:27:16  <AvianFlu>I'm not really in a position where I can set all that up
03:27:44  <Dirkson>Ralith: I don't get how uv_shutdown is supposed to help me. It more looks like what I'd used if I wanted to shutdown a client connection.
03:28:18  <Ralith>Dirkson: it's not supposed to help you, it's supposed to initiate a shutdown.
03:28:42  <Dirkson>Ralith: Right - Is this something I'm expected to do when a client disconnects?
03:28:53  * mikolalysenkoquit (Read error: Connection reset by peer)
03:29:47  * bradleymeckquit (Quit: bradleymeck)
03:30:05  <Ralith>Dirkson: as I described above, you need to shutdown your end of a TCP connection when you have finished writing to it for any reason.
03:30:10  * AlexisMochajoined
03:30:34  <Dirkson>Ralith: Including "The client vanished on his own"?
03:31:42  <Ralith>if by "vanished on its own" you mean timed out or RST, then no, you'd move directly to a close
03:31:57  * mikolalysenkojoined
03:32:10  * rmgjoined
03:32:36  <Dirkson>Ralith: In my situation here - The client software has crashed. This then causes the server software to crash. I'm trying to work out if that's expected behavior because I've missed some "Oh, and don't crash when a client disconnects" callback somewhere.
03:33:21  <Ralith>Dirkson: as tjfontaine says, it's more likely that there exists a bug in your application logic.
03:33:53  <Dirkson>Ralith: Ok, cool. I will keep your shutdown comments in mind when it comes time for the server to be able to disconnect clients, though : )
03:34:00  * kazuponjoined
03:34:04  <Ralith>or respond correctly to a client's disconnection.
03:34:14  * AlexisMochaquit (Ping timeout: 245 seconds)
03:34:23  <Dirkson>Ralith: You see, now you're worrying me again :D
03:34:25  * AlexisMochajoined
03:34:33  <tjfontaine>AvianFlu: after actually looking at the logs, it's pretty straight forward error
03:34:45  <Ralith>Dirkson: as an aside, I find clang/gcc4.8+'s address sanitizer to be an incredible asset to hunting down memory errors.
03:34:51  <tjfontaine>AvianFlu: "stack": "UnauthorizedError: <HTML>\n<HEAD>\n<TITLE>Token expired</TITLE>
03:34:57  <Ralith>the undefined behavior sanitizer is also useful
03:35:03  <Dirkson>Ralith: Clang? Address sanitizer?
03:35:19  <Dirkson>Ralith: Er... Should be way more specific. I currently use clang. I'm unsure what an address sanitizer is.
03:35:21  <AvianFlu>tjfontaine: oh lol
03:35:26  <AvianFlu>that would do it
03:35:55  <Ralith>Dirkson: http://clang.llvm.org/docs/AddressSanitizer.html
03:36:13  * kellabytequit (Quit: Connection closed for inactivity)
03:36:48  <Ralith>note somewhat oudated documentation
03:37:11  * rmgquit (Ping timeout: 255 seconds)
03:37:26  <Ralith>Dirkson: in general: http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation
03:38:20  <Ralith>note that clang 3.4 asan has a bug that mangles debug info
03:38:21  * kazuponquit (Ping timeout: 240 seconds)
03:38:29  <Ralith>so don't use it and expect to debug at the same time
03:38:35  <tjfontaine>AvianFlu: ok -- well restarted the beast, let's see what happens :)
03:39:02  * nickleeflyquit (Quit: Connection closed for inactivity)
03:39:31  <Dirkson>Ralith: *Reads* Under casual inspection, this looks like it could be a valgrind-alike that doesn't kill my code's excecution speed... I would dearly love that ^^;
03:39:57  <Ralith>it also tends to be more reliable and helpful than valgrind
03:40:40  <Dirkson>Ralith: ... I need to repay a huge debt. What could I give you? ... Firstborn child? Do people still give those?
03:41:35  <Ralith>I'll settle for a beer if we ever run into eachother
03:41:54  * mikolalysenkoquit (Read error: Connection reset by peer)
03:42:02  <Dirkson>Ralith: I have five gallons of beer within 20 feet of me. I think I can accommodate this ^.^
03:42:11  * mikolalysenkojoined
03:45:38  * mikolalysenkoquit (Read error: Connection reset by peer)
03:47:11  * mikolalysenkojoined
03:48:23  * mikolalysenkoquit (Read error: Connection reset by peer)
03:49:55  <Dirkson>Ralith: Got it working, but it mostly seems to hand me addresses where gdb hands me line numbers. Still, it's so easy to implement that I'm sure I'll find a few uses for it.
03:50:24  <Ralith>Dirkson: asan on clang 3.4 should give you line numbers and symbol names
03:50:34  <Dirkson>Ralith: Gotcha. Updating ^^
03:50:37  <Ralith>previous to that, you'll need to follow the instructions in the documentation to enable the symbolizer
03:50:41  * AlexisMochaquit (Ping timeout: 264 seconds)
03:50:41  * AlexisMocha_joined
03:52:08  * mikolalysenkojoined
03:53:25  * mikolalysenkoquit (Read error: Connection reset by peer)
03:54:59  <Dirkson>Ralith: Clang 3.4 compiles my code CONSIDERABLY faster than 3.3.
03:55:32  <Dirkson>Ralith: And now I've got line numbers. This is nice. This is very nice.
03:57:11  * mikolalysenkojoined
03:59:45  <Ralith>\o/
04:00:38  <Dirkson>Ralith: But now I've turned on ALL the fun stuff, and it's totally throwing errors at me that I don't understand. It may be finding a bug in the nvidia drivers...?
04:00:58  <Ralith>oh dear, you're doing graphics?
04:01:06  <Dirkson>Ralith: www.scrumbleship.com
04:01:14  <Ralith>oh, I thought I recognized your nick from somewhere
04:01:19  <Ralith>I have a license to that
04:01:28  <Dirkson>Really? Small internet! ^.^
04:01:47  <Ralith>anyway, GPU drivers are somewhat notorious for doing nasty things with memory that confuse error checkers
04:01:52  <Ralith>also, for containing bugs
04:02:04  * rmgjoined
04:02:05  <Dirkson>Ralith: Yeah, I've sorta been suspecting that : )
04:02:18  <Ralith>if you get a lot of spam from nvidia, consider applying asan's whitelisting
04:02:21  <Dirkson>Ralith: Well, currently I'm working on swapping the libenet backend out for libuv. I strongly suspect that the change will result in a better network stack.
04:02:42  <Ralith>certainly a better maintained one
04:03:05  <Dirkson>Hear Hear.
04:03:35  <Ralith>the native support for async filesystem IO is a killer feature for me
04:03:38  <Dirkson>I had nothing but problems with libenet. I still have problems with libuv, but they're 100% documentation challenges - The actual underlying library appears to do its job pretty well.
04:03:55  <Ralith>you will, of course, be responsible for implementing your own reliability layer
04:04:02  <Dirkson>Ralith: Yup. That should do some very nice things for how the server hands out ships to clients.
04:04:14  <Dirkson>Ralith: Define "reliability" here?
04:04:23  <Ralith>retransmission of dropped datagrams
04:04:30  <Ralith>sequencing, if desirable
04:04:31  <Dirkson>Ralith: I thought TCP did that automagically.
04:04:36  <Ralith>oh, you're using TCP?
04:04:51  <Ralith>that's not a very common choice for games, but it will do that, yes
04:04:54  <Dirkson>A mix. Using UDP for the small stuff that doesn't need retransmission or sequencing, and tcp for everything else.
04:06:34  <Dirkson>I figure for things like chat messages and block update events, the practical difference between TCP and UDP is pretty minimal, except I get the nice sequencing and retransmission things for TCP. Also, sending /files/ over TCP is going to be a huge performance boost - Vanilla libenet transmits at a TINY fraction of modern internet speeds.
04:07:27  <Ralith>TCP isn't that great at making full utilization of a high-bandwidth connection either--though I suspect it won't be hard pressed to outdo enet
04:07:53  <Dirkson>Really? That surprises me - TCP is sort of the building block of the modern internet, is it not?
04:08:07  <Ralith>for certain values of "the internet"
04:08:22  <Ralith>and its failings are one of the reason why it still takes whole-number seconds to load a webpage
04:08:25  <Ralith>reasons*
04:08:28  <Dirkson>Fair point.
04:08:49  * mikolalysenkoquit (Read error: Connection reset by peer)
04:08:49  <Ralith>of course, that has more to do with setup and teardown than anything, but the throughput limitations remain
04:08:57  <Dirkson>Don't worry - For anything truly time-sensitive, I intend to use UDP instead : )
04:09:05  <Ralith>that's good
04:09:06  * mikolalysenkojoined
04:09:20  <Dirkson>As a side benefit of this, (And because I can't work out any other way to do it) this will mean all udp traffic will be encrypted.
04:09:39  <Ralith>TCP will do just fine for bulk data transfer, too--there's a large difference between suboptimal and unacceptable
04:09:47  <Ralith>Dirkson: why's that?
04:09:48  <Dirkson>Right.
04:10:29  <Ralith>it's not clear to me how encryption follows
04:11:40  <Dirkson>Ralith: Well, I need some way of linking each udp packet to a user in a way that can't be screwed around with... And the easiest way to do that is just to reuse some encryption code I've got hanging around for user-identification. Encrypt each UDP packet with a shared secret based on the initial handshake between the client and server. It's also only a few hours work to ensure that private messages between
04:11:42  <Dirkson>users are encrypted so that no one but those users can listen in.
04:12:27  <Ralith>so to identify the session of a datagram, you attempt to decrypt it according to the secret associated with every active session?
04:12:37  <Dirkson>Ralith: I think you've got it, aye : )
04:12:55  <Ralith>that seems expensive
04:13:02  <Ralith>normally one just maintains a lookup table based on remote IP and port
04:13:43  <Dirkson>Ralith: Ahhh, but remote IP on UDP packets can be easily faked.
04:13:58  <Dirkson>Ralith: It MIGHT be expensive - Testing will need to happen. NaCL encryption is a lot cheaper than most traditional encryption options.
04:14:28  <Ralith>easily faked if you have an unfiltered connection to the WAN, yes; such are not generally available.
04:14:41  <Ralith>ISPs drop packets with spoofed source addresses as corrupted.
04:14:45  <Dirkson>Ralith: Fair point.
04:15:37  * kazuponjoined
04:15:52  <Dirkson>Ralith: Maybe I'll just rely on that, then. I'll ask networking what they think about relying on that too.
04:16:39  <Dirkson>Ralith: #scrumbleship on irc.scrumbleship.com , if you want to join the lurkers, btw : )
04:17:46  * mikolalysenkoquit (Read error: Connection reset by peer)
04:17:55  <Ralith>noted, though I'm in enough IRC channels as it is
04:18:02  * mikolalysenkojoined
04:18:16  <Dirkson>Ralith: *stares at 23 channels* Yeah. Yeah.
04:19:10  * quijotejoined
04:19:24  * mikolalysenkoquit (Read error: Connection reset by peer)
04:23:08  * mikolalysenkojoined
04:23:49  * quijotequit (Ping timeout: 245 seconds)
04:24:36  * mikolalysenkoquit (Read error: Connection reset by peer)
04:28:07  * mikolalysenkojoined
04:29:47  * mikolalysenkoquit (Read error: Connection reset by peer)
04:30:44  * mikolalysenkojoined
04:34:20  * seldo_joined
04:37:38  * mikolalysenkoquit (Read error: Connection reset by peer)
04:37:54  * mikolalysenkojoined
04:43:57  * petka_joined
04:47:48  * mikolalysenkoquit (Read error: Connection reset by peer)
04:48:02  * mikolalysenkojoined
05:04:38  * bradleymeckjoined
05:13:17  * mikolalysenkoquit (Read error: Connection reset by peer)
05:13:32  * mikolalysenkojoined
05:16:09  * quijotejoined
05:16:28  * cosnis_quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
05:18:34  * mikolalysenkoquit (Ping timeout: 240 seconds)
05:34:55  * cosnisjoined
05:40:12  * cosnisquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
05:40:41  * kazuponquit (Remote host closed the connection)
05:44:22  * octetcloudquit (Ping timeout: 265 seconds)
05:44:32  * bradleymeckquit (Quit: bradleymeck)
05:48:45  <MI6>joyent/node: Alexis Campailla merge-review * f0517c4 : test: add test-http-destroyed-socket-write2 (+4 more commits) - http://git.io/qeH_uA
05:53:31  * cosnisjoined
05:54:32  * mikealjoined
05:59:09  * mikealquit (Ping timeout: 252 seconds)
05:59:20  * seldo_quit (Remote host closed the connection)
05:59:35  * m76joined
06:06:07  * AlexisMochajoined
06:06:57  * AlexisMocha_quit (Ping timeout: 250 seconds)
06:09:11  * AlexisMocha_joined
06:10:18  * AlexisMochaquit (Ping timeout: 240 seconds)
06:15:35  * quijotequit (Ping timeout: 255 seconds)
06:27:28  * AlexisMochajoined
06:29:18  * AlexisMocha_quit (Ping timeout: 240 seconds)
06:29:42  * seldo_joined
06:34:38  * seldo_quit (Ping timeout: 240 seconds)
06:36:05  * calvinfoquit (Quit: Leaving.)
06:41:23  * kazuponjoined
06:44:44  * calvinfojoined
06:46:23  * kazuponquit (Ping timeout: 250 seconds)
06:50:24  * calvinfoquit (Quit: Leaving.)
06:52:38  * mikealjoined
06:57:15  * mikealquit (Ping timeout: 258 seconds)
07:02:53  * wolfeidauquit (Remote host closed the connection)
07:06:15  * kazuponjoined
07:16:57  * AlexisMocha_joined
07:17:41  * AlexisMochaquit (Ping timeout: 264 seconds)
07:23:22  * rmgquit (Remote host closed the connection)
07:23:28  * bajtosjoined
07:26:33  * wolfeidaujoined
07:28:13  * wolfeidauquit (Remote host closed the connection)
07:36:50  * hzjoined
07:53:53  * rmgjoined
07:59:58  * rmgquit (Ping timeout: 240 seconds)
08:18:59  * AlexisMochajoined
08:19:14  * AlexisMocha_quit (Ping timeout: 245 seconds)
08:27:24  * daviddiasjoined
08:31:43  * seldo_joined
08:32:02  <indutny>hey people
08:36:09  * seldo_quit (Ping timeout: 258 seconds)
08:42:06  * cosnis_joined
08:42:13  * cosnis_quit (Max SendQ exceeded)
08:42:36  * quijotejoined
08:43:00  * cosnis_joined
08:43:05  * cosnis_quit (Max SendQ exceeded)
08:43:44  * cosnis_joined
08:45:31  * cosnisquit (Ping timeout: 252 seconds)
08:57:13  * AlexisMocha_joined
08:59:38  * AlexisMochaquit (Ping timeout: 265 seconds)
09:02:42  * AlexisMochajoined
09:03:13  * AlexisMocha_quit (Ping timeout: 252 seconds)
09:19:11  * kazuponquit (Remote host closed the connection)
09:22:49  * nickleeflyjoined
09:22:59  * guilleiguaran_quit (Ping timeout: 245 seconds)
09:23:30  * Domenic_quit (Read error: Connection reset by peer)
09:23:55  * Domenic_joined
09:24:03  * guilleiguaran_joined
09:25:36  * quijotequit (Ping timeout: 258 seconds)
09:33:37  * quijotejoined
09:46:11  * chummmjoined
09:50:41  * chummm_quit (*.net *.split)
09:50:41  * zz_karupaquit (*.net *.split)
09:57:49  * daviddiasquit (Remote host closed the connection)
09:58:22  * daviddiasjoined
09:59:06  * daviddia_joined
09:59:06  * daviddiasquit (Read error: Connection reset by peer)
09:59:17  * zz_karupajoined
10:01:40  * AlexisMocha_joined
10:02:57  * AlexisMochaquit (Ping timeout: 265 seconds)
10:07:53  * bajtosquit (Quit: bajtos)
10:09:53  * cosnis_quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
10:13:05  * quijotequit (Ping timeout: 250 seconds)
10:17:05  * daviddia_quit (Remote host closed the connection)
10:17:40  * daviddiasjoined
10:20:26  * Kakerajoined
10:21:44  * daviddiasquit (Ping timeout: 245 seconds)
10:28:07  * LeftWing__joined
10:29:26  * LeftWingquit (Remote host closed the connection)
10:32:44  * seldo_joined
10:37:45  * seldo_quit (Ping timeout: 265 seconds)
10:39:40  * quijotejoined
10:44:07  * sinclair|workjoined
10:44:11  * quijotequit (Ping timeout: 258 seconds)
11:03:19  <indutny>hey mmalecki
11:03:20  <indutny>yt?
11:11:40  * mrvisserjoined
11:13:26  * WalrusPony1joined
11:14:41  * WalrusPonyquit (Ping timeout: 264 seconds)
11:22:26  * bajtosjoined
11:28:11  * wolfeidaujoined
11:39:58  * quijotejoined
11:44:13  * daviddiasjoined
11:44:40  * wolfeidauquit (Remote host closed the connection)
11:45:42  * daviddiasquit (Remote host closed the connection)
11:49:43  * rjequit (Ping timeout: 258 seconds)
11:51:16  * rjejoined
11:57:28  * janjongboomjoined
11:57:59  * m76quit (Ping timeout: 265 seconds)
11:58:42  * rmgjoined
12:02:03  * quijotequit (Ping timeout: 252 seconds)
12:03:24  * rmgquit (Ping timeout: 245 seconds)
12:06:05  * bajtosquit (Quit: bajtos)
12:07:24  * AlexisMochajoined
12:08:01  * AlexisMocha_quit (Ping timeout: 252 seconds)
12:13:02  * AlexisMocha_joined
12:13:14  * AlexisMochaquit (Ping timeout: 240 seconds)
12:19:15  * rjequit (Ping timeout: 258 seconds)
12:19:49  * rjejoined
12:24:19  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
12:24:22  * kellabytejoined
12:30:54  * rjequit (Ping timeout: 258 seconds)
12:30:54  * rjejoined
12:34:21  * wolfeidaujoined
12:36:34  * seldo_joined
12:40:54  * seldo_quit (Ping timeout: 240 seconds)
12:45:35  * mikolalysenkojoined
12:47:53  * mrvisserquit (Ping timeout: 252 seconds)
12:48:24  * rjequit (*.net *.split)
12:55:17  * rjejoined
12:57:17  * mrvisserjoined
12:58:26  * quijotejoined
13:02:54  * quijotequit (Ping timeout: 240 seconds)
13:02:55  * Kakeraquit (Ping timeout: 252 seconds)
13:04:45  <MI6>joyent/node: taojie.hjp master * 34318a6 : timers: fix spelling mistake - http://git.io/RrbkzA
13:05:58  <MI6>joyent/node: Adrian Lang master * 044da47 : doc: correct check for failed child_process.spawn - http://git.io/4rDcZA
13:10:02  * m76joined
13:13:49  <indutny>escrow transactions are fun https://blockchain.info/address/1J3TrsPYPDVGtdpeViHtzjw6wPqsbwXWHE
13:15:06  * m76quit (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/)
13:16:58  * AlexisMocha_quit (Ping timeout: 240 seconds)
13:17:02  * AlexisMochajoined
13:18:28  * m76joined
13:20:19  * kazuponjoined
13:28:42  * daviddiasjoined
13:34:57  * mikolalysenkoquit (Ping timeout: 276 seconds)
13:34:58  * c4milojoined
13:39:47  <tjfontaine>remember to have real names in commit messagse
13:39:56  * quijotejoined
13:41:57  * AlexisMocha_joined
13:42:54  * AlexisMochaquit (Ping timeout: 240 seconds)
13:44:14  * quijotequit (Ping timeout: 245 seconds)
13:44:50  <MI6>joyent/node: Alexis Campailla master * 1ab98a1 : test: replace http-destroyed-socket-write - http://git.io/58M0uQ
13:48:34  * kazuponquit
13:48:47  * AlexisMochajoined
13:48:51  * kazuponjoined
13:49:58  * AlexisMocha_quit (Ping timeout: 240 seconds)
14:04:19  <MI6>joyent/node: Vladimir Kurchatkin merge-review * 82fca91 : stream: don't try to finish if buffer is not empty - http://git.io/UAYR-A
14:05:06  <tjfontaine>AlexisMocha: blah I made a mistake on your destroyed-socket test, what's the difference between ECONNRESET vs ECONNABORTED
14:05:18  * mrvisserquit (Remote host closed the connection)
14:08:44  * Kakerajoined
14:14:33  * mrvisserjoined
14:14:59  * TooTallNatejoined
14:18:00  * AlexisMocha_joined
14:18:55  * AlexisMochaquit (Ping timeout: 252 seconds)
14:31:02  * jmar777joined
14:32:40  * WalrusPonyjoined
14:33:35  * WalrusPony1quit (Ping timeout: 252 seconds)
14:33:57  * julianduquequit (Ping timeout: 252 seconds)
14:35:33  * julianduquejoined
14:35:38  * ryah_quit (Ping timeout: 240 seconds)
14:36:30  * ryahjoined
14:40:47  * quijotejoined
14:42:31  * quijote_joined
14:42:34  * quijotequit (Read error: Connection reset by peer)
14:47:05  * quijote_quit (Ping timeout: 264 seconds)
14:50:42  * AlexisMochajoined
14:51:46  <AlexisMocha>tjfontaine: At least at the winsock level, I think WSACONNRESET means the other endpoint abrubtely closed the conneciton. WSACONNABORTED means a local error.
14:52:50  <AlexisMocha>I suppose we could handle both
14:52:57  * AlexisMocha_quit (Ping timeout: 276 seconds)
14:53:08  * TooTallNatequit (Quit: Computer has gone to sleep.)
14:53:51  * c4miloquit (Remote host closed the connection)
14:54:06  * c4milojoined
14:57:59  * mikolalysenkojoined
15:06:01  * bajtosjoined
15:12:37  * kazuponquit (Remote host closed the connection)
15:13:06  * c4miloquit (Remote host closed the connection)
15:18:40  * mrvisserquit (Remote host closed the connection)
15:28:00  * kazuponjoined
15:31:49  * TooTallNatejoined
15:32:00  * TooTallNatequit (Client Quit)
15:32:41  * kazuponquit (Ping timeout: 255 seconds)
15:36:41  * c4milojoined
15:41:15  * quijotejoined
15:42:21  * rosskjoined
15:42:42  * rosskquit (Remote host closed the connection)
15:42:49  * rosskjoined
15:43:36  * c4miloquit (Remote host closed the connection)
15:43:45  * rmgjoined
15:52:48  * mrvisserjoined
15:54:46  * bradleymeckjoined
16:09:07  * calvinfojoined
16:15:47  <bradleymeck>mornin
16:17:58  <nathan7>MORNIN'
16:18:39  <indutny>hey hey
16:28:29  * TooTallNatejoined
16:33:38  * quijotequit (Ping timeout: 240 seconds)
16:39:02  * seldo_joined
16:41:08  * calvinfoquit (Quit: Leaving.)
16:42:12  * octetcloudjoined
16:43:57  * seldo_quit (Ping timeout: 250 seconds)
16:49:02  * nickleeflyquit (Quit: Connection closed for inactivity)
16:55:16  * AlexisMocha_joined
16:56:45  * AlexisMochaquit (Ping timeout: 240 seconds)
16:57:23  * Ralithquit (Ping timeout: 250 seconds)
16:59:49  * AlexisMochajoined
17:00:31  * quijotejoined
17:01:20  * AlexisMocha_quit (Ping timeout: 255 seconds)
17:02:02  * m76quit (Read error: Connection reset by peer)
17:04:56  * quijotequit (Ping timeout: 255 seconds)
17:06:09  * TooTallNatequit (Quit: Computer has gone to sleep.)
17:20:23  * c4milojoined
17:24:01  * LeftWing__changed nick to LeftWing
17:27:13  * quijotejoined
17:30:39  * c4miloquit (Remote host closed the connection)
17:38:01  * bajtosquit (Quit: bajtos)
17:38:38  <tjfontaine>AlexisMocha: so you think it's reasonable to handle both?
17:39:34  <AlexisMocha>yes, I have seen both being raised in similar conditions
17:39:52  <tjfontaine>ok I'll add that
17:42:42  * TooTallNatejoined
17:47:59  <MI6>joyent/node: Timothy J Fontaine merge-review * 41d8e10 : test: http-destroyed-socket-write win32 may ABORT - http://git.io/FZ5esA
17:53:40  * Ralithjoined
17:54:10  * calvinfojoined
17:55:29  * bradleymeckquit (Quit: bradleymeck)
18:01:30  * quijotequit (Read error: Connection reset by peer)
18:01:49  * quijotejoined
18:05:22  * janjongboomjoined
18:06:27  * seldo_joined
18:06:56  <MI6>joyent/node: Timothy J Fontaine master * 41d8e10 : test: http-destroyed-socket-write win32 may ABORT (+1 more commits) - http://git.io/0f7tOQ
18:09:58  * janjongboomquit (Read error: Connection reset by peer)
18:10:11  * mrvisserquit (Ping timeout: 250 seconds)
18:10:39  * seldo_quit (Ping timeout: 252 seconds)
18:12:14  * AlexisMocha_joined
18:12:46  * seldo_joined
18:14:05  * AlexisMochaquit (Ping timeout: 250 seconds)
18:14:47  * mrvisserjoined
18:25:28  * TooTallNatequit (Quit: Computer has gone to sleep.)
18:25:45  * bajtosjoined
18:32:39  * mrvisserquit (Read error: Connection timed out)
18:33:16  * mrvisserjoined
18:33:30  * bradleymeckjoined
18:39:20  * m76joined
18:40:39  * piscisaureusjoined
18:46:30  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
18:51:43  * quijotequit (Ping timeout: 265 seconds)
18:56:21  * daviddiasquit (Remote host closed the connection)
18:56:56  * daviddiasjoined
19:00:37  * AlexisMochajoined
19:01:15  * daviddiasquit (Ping timeout: 252 seconds)
19:02:18  * AlexisMocha_quit (Ping timeout: 240 seconds)
19:38:43  * bajtosquit (Quit: bajtos)
19:41:11  * Kakeraquit (Ping timeout: 250 seconds)
19:47:36  * quijotejoined
19:51:58  * quijotequit (Ping timeout: 240 seconds)
19:57:33  * c4milojoined
20:03:27  * Kakerajoined
20:23:44  * c4miloquit (Remote host closed the connection)
20:29:13  * brsonjoined
20:34:59  * AlexisMocha_joined
20:37:27  * AlexisMochaquit (Ping timeout: 276 seconds)
20:38:30  * ryancolejoined
20:39:01  * AlexisMochajoined
20:41:21  * AlexisMocha_quit (Ping timeout: 276 seconds)
20:41:43  * AlexisMocha_joined
20:43:22  * AlexisMochaquit (Ping timeout: 265 seconds)
20:45:47  * jmar777quit (Remote host closed the connection)
20:48:21  * quijotejoined
20:51:00  * ryancolequit (Read error: Connection reset by peer)
20:51:20  * ryancolejoined
20:53:02  * quijotequit (Ping timeout: 265 seconds)
20:54:08  <Dirkson>If I run uv_run without any listeners, is it supposed to crash?
20:55:01  * m76quit (Read error: Connection reset by peer)
20:56:38  * AlexisMochajoined
20:57:52  <Dirkson>Also - When users disconnect, I have some cleanup work to do before the tcp connection should be freed. Is there any callback provided by libuv that'll allow me to do that?
20:58:02  * AlexisMocha_quit (Ping timeout: 255 seconds)
21:01:53  * c4milojoined
21:02:14  * taibhsequit (Quit: WeeChat 0.4.4-dev)
21:02:41  * c4miloquit (Remote host closed the connection)
21:06:50  * bradleymeckquit (Quit: bradleymeck)
21:12:14  * octetcloudquit (Quit: WeeChat 0.4.3)
21:14:03  <indutny>Dirkson: it isn't supposed to crash
21:14:14  <indutny>Dirkson: it should just return immediately
21:14:25  <indutny>Dirkson: uv_close() has a cb argument
21:14:36  <indutny>anyway, you are freeing stuff yourself
21:15:27  <Dirkson>indutny: Well, I'm not calling uv_close, am I? The connection goes down unexpectedly, libuv appears to do /something/ to clean up its own structures, but is currently leaving me out of the loop.
21:15:44  * octetcloudjoined
21:15:44  <indutny>you need to close it anyway
21:15:48  <Dirkson>indutny: My "without any listeners" guess is wrong. I'm getting a crash, but I can't work out what's causing it.
21:15:50  <indutny>it doesn't clean up anything
21:15:56  <Dirkson>indutny: Oh. Maybe that's why things are breaking :D
21:16:05  <indutny>you should close it when you get -1 status in read_cb()
21:16:12  <Dirkson>indutny: AHHHH
21:16:23  <indutny>assuming that it is not UV_EOF
21:16:24  <indutny>well
21:16:25  <indutny>not -1
21:16:27  * mikolalysenkoquit (Ping timeout: 252 seconds)
21:16:28  <indutny>just negative
21:16:33  <indutny>status < 0
21:17:59  <Dirkson>indutny: In the read_cb(), I don't think I have status, just the number of items read. I thought when it went to -1, I was supposed to check if the last error was uv_eof and, if so, close the connection.
21:18:40  * mikealjoined
21:18:45  <indutny>UV_EOF is not really a error
21:18:59  <indutny>it just means that other side won't write anything
21:19:17  <indutny>you should be still able to write to that TCP socket
21:20:03  <Dirkson>indutny: So EOF doesn't mean the connection is closed, just that it's not currently writing anything?
21:20:12  <indutny>not currently
21:20:24  <indutny>other side won't write anything up until the closure of socket
21:20:36  <indutny>i.e. it has called uv_shutdown()
21:21:44  * yunongquit
21:22:02  * yunongjoined
21:23:38  <Dirkson>indutny: This ( http://pastebin.com/LvXWfLtA ) is what I do when I get a "NumberRead" less than 0 for the tcp stream read callback. Is it the right thing to do? Am I supposed to do anything more? (My new connection callback stuffs some data into Stream->data)
21:23:55  <indutny>no, this is not going to work
21:24:09  <indutny>you better free stuff in `uv_close()`'s callback
21:24:17  <indutny>well, it may work
21:24:22  <indutny>but I would recommend you to do so :)
21:24:35  <indutny>not a big fan of synchronous closure
21:24:41  <Dirkson>Gotcha.
21:24:58  <Dirkson>Currently, the next time I run uv_run after this block of code, my program crashes.
21:27:10  <Dirkson>Ok. So the uv_close_cb style is handed a uv_handle_t instead of a uv_stream_t. What do I do with the uv_handle_t?
21:29:28  * bradleymeckjoined
21:29:36  <indutny>you could cast it to uv_stream_t
21:29:44  <indutny>(uv_stream_t*) handle
21:29:48  <indutny>if you need to
21:29:58  <indutny>it is the same pointer essentially
21:29:59  * bradleymeckquit (Client Quit)
21:30:01  <Dirkson>So I should cast the handle back to a stream, free my data structure within it, free it, and then return?
21:30:18  <indutny>yep, that's fine
21:30:26  * bradleymeckjoined
21:30:28  <Dirkson>CoolCool. Just a tick
21:31:30  <Dirkson>indutny: While I've got your ear - This whole "many structs in libuv are freely castable to other libuv structs" thing has got me REALLY confused. Is there a reason it's like that? Is there any easy way for me to tell which structs should be typecastable as other structs?
21:31:47  <indutny>you could take a look at uv.h
21:31:53  <indutny>generally structs have something like
21:31:55  <indutny>UV_HANDLE
21:31:57  <indutny>inside it
21:32:04  <indutny>or UV_STREAM
21:32:15  <indutny>if they do - they could be casted to it
21:32:27  <Dirkson>What happens to the extra data?
21:34:47  <indutny>hm?
21:34:49  <indutny>it is still there
21:34:59  <indutny>it is just a pointer cast
21:36:04  <Dirkson>I don't think I understand enough to ask questions to clear my confusion :D
21:36:53  * bradleymeckquit (Ping timeout: 252 seconds)
21:37:01  <indutny>Dirkson: well
21:37:04  <indutny>imagine chunk of memory
21:37:07  <indutny>it has some data in it
21:37:12  <indutny>and has an address like this
21:37:17  <indutny>0x1ade1345123510
21:37:19  <indutny>well
21:37:21  <indutny>may be not like this
21:37:23  <indutny>but anyway
21:37:28  <Dirkson>Following so far : )
21:37:37  <indutny>you may have `uv_stream_t* s` pointing to this chunk
21:37:41  <indutny>or `uv_handle_t*`
21:37:51  <indutny>the accessed memory chunk is still the same
21:37:58  <indutny>when you are working with `s` or `handle`
21:38:08  <indutny>so practically you just see less fields
21:38:19  <Dirkson>Ahhhh.
21:38:21  <indutny>and able to pass uv_stream_t* to the function that works with uv_handle_t*
21:38:34  <indutny>and vice versa
21:39:43  <Dirkson>So they're subsets of one another. uv_handle_t contains more fields, which many functions don't need, so you cast to, say, uv_stream_t to reduce the amount that those functions can alter - Ensuring those struct fields have scope. But whether you free a uv_stream_t* or a uv_handle_t* doesn't matter, because it's the same size of memory block being pointed to.
21:40:48  <Dirkson>An interesting approach! Also explains why I've never encountered it in my own code - I've always used recursive structs to solve the same problem.
21:42:07  <Dirkson>Although I think you guys are using that too : ) I.e. casting a uv_handle_t to a uv_stream_t is the same as passing uv_handle_t->stream_t (or whatever in proper syntax).
21:42:52  * mikolalysenkojoined
21:47:09  <Dirkson>indutny: That change did fix my crash - And probably made the thing more performant. Thank you!
21:47:42  <indutny>np
21:47:44  <indutny>you are welcome
21:47:59  * mikolalysenkoquit (Ping timeout: 252 seconds)
21:49:06  * quijotejoined
21:53:29  * quijotequit (Ping timeout: 258 seconds)
22:14:39  * quijotejoined
22:17:07  * ryancolequit
22:18:54  * quijotequit (Ping timeout: 240 seconds)
22:43:24  * bradleymeckjoined
22:43:39  * mikolalysenkojoined
22:45:40  <bradleymeck>lesson: don’t try to create a multi-context and use it in C++… or… its going to be a while
22:46:42  * jmar777joined
22:48:14  <tjfontaine>heh
22:48:54  * mikolalysenkoquit (Ping timeout: 240 seconds)
22:49:15  * qardjoined
22:49:23  * bradleymeckquit (Quit: bradleymeck)
22:52:38  * Kakeraquit (Ping timeout: 240 seconds)
22:53:40  * calvinfoquit (Quit: Leaving.)
23:00:46  * mrvisserquit
23:01:06  * mrvisserjoined
23:13:59  * nathan7quit (Read error: Connection reset by peer)
23:15:20  * quijotejoined
23:16:42  * quijotequit (Read error: Connection reset by peer)
23:17:08  * quijotejoined
23:21:35  * quijotequit (Ping timeout: 252 seconds)
23:23:16  * nathan7joined
23:26:13  * petka_quit (Quit: Connection closed for inactivity)
23:29:05  * nathan7quit (Quit: brb)
23:30:39  * AlexisMocha_joined
23:30:45  * AlexisMochaquit (Ping timeout: 240 seconds)
23:31:37  * mikolalysenkojoined
23:32:21  * c4milojoined
23:34:04  * mrvisserquit (Remote host closed the connection)
23:38:50  * AlexisMochajoined
23:41:05  * AlexisMocha_quit (Ping timeout: 264 seconds)
23:46:34  * octetcloudquit (Ping timeout: 258 seconds)
23:53:15  * calvinfojoined