00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:03:34  * dapquit (Quit: Leaving.)
00:04:23  * piscisaureus_joined
00:08:30  * piscisaureus_quit (Client Quit)
00:19:58  * Kakeraquit (Ping timeout: 250 seconds)
00:28:10  * hzquit
00:30:23  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:31:03  * TooTallNatejoined
00:41:25  * dominictarrjoined
01:16:54  * isaacsfg
01:21:38  * mraleph1quit (Read error: Operation timed out)
01:21:47  * mralephjoined
01:32:56  * stagasquit (Ping timeout: 245 seconds)
01:44:45  * brsonjoined
01:48:24  * EhevuTovjoined
01:48:52  * EhevuTovquit (Remote host closed the connection)
02:07:04  * dominictarrquit (Ping timeout: 245 seconds)
02:08:01  * dominictarrjoined
02:35:10  <MI6>joyent/node: isaacs v0.10 * 21a9966 : uv: Upgrade to 5462dab - http://git.io/mGnwEw
02:48:10  <MI6>nodejs-v0.10: #6 UNSTABLE windows-ia32 (4/557) windows-x64 (5/557) osx-x64 (1/557) http://jenkins.nodejs.org/job/nodejs-v0.10/6/
02:50:49  * TooTallNatequit (Quit: Computer has gone to sleep.)
03:15:51  * AvianFlujoined
03:21:03  * brsonquit (Quit: leaving)
03:53:38  * AvianFlu_joined
03:54:16  * AvianFluquit (Disconnected by services)
03:54:19  * AvianFlu_changed nick to AvianFlu
03:58:34  * dominictarrquit (Quit: dominictarr)
04:12:18  * loladirojoined
04:17:27  * sblomjoined
04:20:21  <sblom>How's 0.10 looking on Windows? (I'm not in front of a real computer right now.)
04:20:58  <sblom>In fact, I'm in a shopping mall on my Surface in front of a Microsoft store. (Feel free to make fun.)
04:21:25  <sblom>One really ridiculous thing is that they're blocking logs.libuv.org for some damn reason.
04:22:15  <sblom>So I can't read what I've missed lately. :(
04:22:23  <sblom>I'll go see if the Apple store blocks me.
04:43:51  * brsonjoined
05:08:35  * sblomquit (Ping timeout: 255 seconds)
05:09:35  * TooTallNatejoined
05:09:37  * TooTallNatequit (Client Quit)
05:10:21  <isaacs>ircretary: tell sblom You can go to logs.nodejs.org and get the same content :)
05:10:21  <ircretary>isaacs: I'll be sure to tell sblom
05:11:02  <isaacs>ircretary: tell sblom piscisaureus fixed the assertion error, but it's not the cause of any of the other bugs where we are shutting down sockets before their time.
05:11:02  <ircretary>isaacs: I'll be sure to tell sblom
05:18:10  * sblomjoined
05:40:03  * sblomquit (Ping timeout: 260 seconds)
06:04:02  * dr34dl0ckjoined
06:14:36  * dr34dl0ckquit (Quit: Colloquy for iPad - http://colloquy.mobi)
06:17:56  * AvianFluquit (Remote host closed the connection)
06:28:55  * brsonquit (Quit: leaving)
07:12:00  * dominictarrjoined
07:34:23  * dominictarrquit (Ping timeout: 255 seconds)
07:40:51  * rendarjoined
07:51:46  * dominictarrjoined
07:56:17  * mikealjoined
07:56:29  * loladiroquit (Quit: loladiro)
08:12:50  * stagasjoined
08:16:36  * dominictarrquit (Quit: dominictarr)
08:17:25  * stagasquit (Ping timeout: 248 seconds)
08:25:00  * txdvquit (Remote host closed the connection)
08:25:07  * txdvjoined
08:26:48  * stagasjoined
08:45:07  * Raltjoined
09:18:07  * mmalecki[zzz]changed nick to mmalecki
10:38:49  * Raltquit (Remote host closed the connection)
10:42:45  * hzjoined
10:45:55  * Raltjoined
10:47:38  * Raltquit (Remote host closed the connection)
10:49:02  * Raltjoined
10:50:22  * Raltquit (Remote host closed the connection)
10:58:56  * Kakerajoined
11:06:27  * hzquit
11:07:00  * hzjoined
11:07:11  * hzquit (Client Quit)
11:12:22  * hzjoined
11:27:07  * hzquit
11:32:42  * loladirojoined
11:32:45  * loladiroquit (Client Quit)
12:41:27  * piscisaureus_joined
12:41:52  <piscisaureus_>ircretary: notes
12:41:57  * piscisaureus_changed nick to piscisaureus
12:42:01  <piscisaureus>ircretary: notes
12:42:34  <piscisaureus>#define struct union
12:52:09  <indutny>hoya
12:52:19  <piscisaureus>heyo
12:55:18  <indutny>how are you?
12:57:04  * piscisaureusquit (Ping timeout: 252 seconds)
13:15:08  * karupaneruraquit (Ping timeout: 276 seconds)
13:21:40  <roxlu>hi guys!
13:22:17  <roxlu>I've got a couple of threads which I want to shutdown nicely when my application exits. Can I use a variable like: must_stop() and have a thread loop like: while(!must_loop) ... ?
13:25:44  <indutny>uv_sem_trywait() should help you
13:26:05  <indutny>that's what I usually use
13:26:10  <indutny>but must_loop should work too
13:26:20  <indutny>make sure that it's volatile
13:27:00  <indutny>yeah, fuck uv_sem_trywait(). use volatile int
13:29:58  * piscisaureusjoined
13:30:04  * piscisaureuschanged nick to piscisaureus_
13:31:13  <roxlu>indutny: thanks, wikipedia says this about volatile: Operations on volatile variables are not atomic,
13:31:34  <indutny>but you don't need atomicity
13:31:58  <indutny>i.e. must_stop will eventually get that assigned value
13:32:02  <roxlu>hmm but changing must_loop must be atomic?
13:32:09  <roxlu>ah yeah
13:32:14  <indutny>are you going to change it concurrently?
13:32:22  <roxlu>no only once actually
13:32:34  <indutny>yes, that's why you don't need atomicity
13:32:38  <roxlu>so why does it need to be `volatile then ?
13:32:38  <roxlu>yep
13:32:48  <indutny>well, just to be sure that it'll get written
13:33:01  <indutny>and won't be optimized out
13:33:07  <indutny>which _should not_ happen
13:33:14  <indutny>but I think possible
13:33:17  <roxlu>ah ok
13:33:22  <roxlu>thanks!
13:33:38  <indutny>np
13:33:51  <roxlu>just to be sure: volatile int must_stop; <-- like that right?
13:33:57  * roxlunever uses volatile
13:33:59  <indutny>yes
13:47:47  * felixgequit (Read error: Connection reset by peer)
14:08:15  * Kakeraquit (Ping timeout: 260 seconds)
14:43:51  * kazuponjoined
14:44:54  <piscisaureus_>C:\Users\Bert Belder>ping foo.bar
14:44:54  <piscisaureus_>Pinging foo.bar [67.215.65.132] with 32 bytes of data:
14:44:54  <piscisaureus_>Reply from 67.215.65.132: bytes=32 time=165ms TTL=57
14:44:54  <piscisaureus_>Reply from 67.215.65.132: bytes=32 time=66ms TTL=57
14:44:54  <piscisaureus_>Reply from 67.215.65.132: bytes=32 time=19ms TTL=57
14:44:55  <piscisaureus_>Reply from 67.215.65.132: bytes=32 time=55ms TTL=57
14:45:02  <piscisaureus_>Never use the internet in a public library :(
14:49:38  * Raltjoined
14:51:05  * stagasquit (Ping timeout: 240 seconds)
14:53:10  * Kakerajoined
14:53:42  * Raltquit (Remote host closed the connection)
15:02:01  <indutny>hahahaha
15:02:06  <indutny>and what's foo.bar there?
15:02:23  <piscisaureus_>it resolves to nxdomain.opendns.org
15:02:35  <piscisaureus_>why they use that is a complete mystery to me though
15:03:15  <indutny>god
15:04:02  <piscisaureus_>say what mortal?
15:07:28  * kazuponquit (Remote host closed the connection)
15:11:10  <indutny>shit
15:11:16  <indutny>that bootcamp partition is too small
15:12:01  <piscisaureus_>ha!
15:12:04  <piscisaureus_>dumb :-p
15:14:32  * Raltjoined
15:30:25  * piscisaureus_quit (Read error: No route to host)
15:36:03  * piscisaureus_joined
15:43:04  <indutny>yep
15:43:09  <indutny>reinstalling everything
15:43:12  <indutny>what could be worse
15:45:05  * piscisaureus_quit (Ping timeout: 248 seconds)
15:48:35  * felixgejoined
15:55:20  <tjfontaine>ircretary: tell piscisaureus_ foo.bar doesn't use opendns, your (upstream?) resolvers are using opendns
15:55:20  <ircretary>tjfontaine: I'll be sure to tell piscisaureus_
16:00:44  * piscisaureus_joined
16:01:34  <piscisaureus_>tjfontaine: true. that's why i said don't use public library internet ;-)
16:02:17  * Raltquit (Remote host closed the connection)
16:02:26  <tjfontaine>heh
16:11:39  * felixgequit (Ping timeout: 245 seconds)
16:17:55  * kazuponjoined
16:23:35  * kazuponquit (Ping timeout: 260 seconds)
16:28:48  <isaacs>good morning
16:32:04  <piscisaureus_>morning isaacs
16:32:25  <piscisaureus_>isaacs: why does everything in npm go through registry-client except the actual tarball download?
16:37:32  <isaacs>piscisaureus_: because... i'm not sure?
16:37:45  <isaacs>piscisaureus_: oh, because the tarball might actually be from somewhere else, some day?
16:38:02  <isaacs>piscisaureus_: like, a cdn or something
16:38:10  <isaacs>but all that stuff's getting rewritten soon-ish anyway
16:41:26  * piscisaureus_quit (Read error: Connection reset by peer)
16:45:36  <isaacs>indutny: re on('end')
16:46:43  <isaacs>indutny: the issue is that you can do stuff like server.listen(function(q,s){ sessionCheckDb(q, function(ok) { if (ok) { q.on('data', blah); q.on('end', endIt) } else { s.end('log in') }) })
16:46:52  <isaacs>indutny: so, the 'end' is lost.
16:47:05  <isaacs>that was actually the case that raised this issue
16:48:00  <MI6>joyent/node: koichik v0.10 * c9a4ec9 : http: ServerRequest does not timeout after 'end' Fixes #4967 (+1 more commits) - http://git.io/-MyVhQ
17:01:27  * mikealquit (Quit: Leaving.)
17:04:20  <MI6>nodejs-v0.10: #7 UNSTABLE windows-ia32 (4/557) osx-ia32 (1/557) linux-x64 (1/557) windows-x64 (4/557) http://jenkins.nodejs.org/job/nodejs-v0.10/7/
17:06:29  <MI6>joyent/node: Julian Gruber v0.10 * 738347b : events: Handle missing error obj when domains in use so `ee.emit('error' - http://git.io/oW8GEw
17:12:36  <indutny>whoa
17:12:36  <indutny>done
17:12:40  <indutny>this time it was really much faster
17:12:47  <isaacs>indutny: oh?
17:12:54  <indutny>reinstalled windows :)
17:12:56  <isaacs>oh, you reinstalled the world?
17:12:57  <indutny>30gb is too small for it
17:12:57  <isaacs>nice
17:13:01  <indutny>yes
17:13:30  <isaacs>indutny: re: on('end'): https://github.com/joyent/node/pull/4969#issuecomment-14684432
17:13:36  <indutny>I disagree
17:13:45  <indutny>you won't get 'end' event if you won't read
17:13:56  <isaacs>yes you will, if there's no data.
17:14:03  <indutny>oh gosh
17:14:08  <isaacs>push(null) emits end *right now* if length == 0
17:14:15  <isaacs>(or, on nextTick, maybe)
17:14:17  <indutny>may be its not that good?
17:14:33  <isaacs>and, requiring a read() in order to get 'end' is oddball
17:14:37  <indutny>why?
17:14:41  <isaacs>we just changed requirng a read() in order to get 'readable'
17:14:49  <isaacs>but i guess you expect readable to happen BEFORE reading
17:14:50  <indutny>ah
17:14:55  <indutny>well
17:14:56  <indutny>anyway
17:14:58  <isaacs>so readable triggers read(0)
17:15:00  <indutny>there should not be any end
17:15:03  <indutny>event
17:15:06  <indutny>if noone was reading
17:15:09  <isaacs>so, you think, defer end until someone reads
17:15:13  <isaacs>that would also fix the problem, i guess.
17:15:28  <indutny>yeah, emitting 'end' event when adding listener seems to be a terrible hack to me
17:15:30  <isaacs>just need to add a "calledRead" flag or something
17:15:38  <isaacs>well, it doesn't emit('end') again
17:15:43  <isaacs>it just calls that listener
17:15:43  <indutny>yeah
17:15:44  <indutny>I know
17:15:51  <indutny>but there're a lot of other events :)
17:15:53  <indutny>like 'finish'
17:15:56  <indutny>'close'
17:16:05  <indutny>you're creating inconsistency
17:16:08  <isaacs>'close' is implementation specific
17:16:13  <isaacs>and finish can't happen until YOU make it happen
17:16:19  <isaacs>'end' happens when the other side says so
17:16:19  <indutny>yes
17:16:24  <indutny>no
17:16:27  <indutny>not always
17:16:32  <isaacs>so we can hold off on calling end until someone somewhere has called read()
17:16:34  <indutny>it won't happen if there is some data to read
17:16:38  <isaacs>right
17:16:42  <isaacs>so that's really the inconsistency
17:16:51  <isaacs>one sec, i'll do this other patch
17:16:56  <indutny>cool
17:17:00  <indutny>thanks for listening :)
17:18:15  <isaacs>indutny: i think we should also handle it in pipe() then
17:18:25  <isaacs>indutny: piping from an ended stream should just call the onend() function right away
17:18:29  <isaacs>(or next tick or whatever)
17:18:39  <indutny>yes
17:18:59  <indutny>that's the second part of fix
17:19:36  <MI6>nodejs-v0.10: #8 UNSTABLE windows-ia32 (5/558) osx-ia32 (1/558) windows-x64 (4/558) linux-ia32 (1/558) http://jenkins.nodejs.org/job/nodejs-v0.10/8/
17:29:54  <isaacs>indutny: https://github.com/isaacs/node/commit/335c17779720451ba49f55d0808f5eacaa902d17
17:29:59  <isaacs>(running tests now)
17:31:06  <isaacs>indutny: can you look at https://github.com/joyent/node/pull/4968 as well? the issue is that you can have a stream with a very high hwm, and it calls push(Buffer(1)) or something every time in _read
17:31:23  <isaacs>indutny: we try to fill up to the hwm, so that means a lot of nextTick calls, and warnings
17:31:51  <isaacs>indutny: fixed by using a while loop instead
17:31:59  <indutny>this commit is beautiful
17:32:01  <indutny>first one
17:32:04  <indutny>looking at PR
17:33:49  <isaacs>aww, thanks :)
17:34:25  <indutny>LGTM
17:35:30  <isaacs>indutny: whoops.. the pipe-after-end is causing a lot of timeouts in some tests.
17:35:43  <indutny>oh...
17:36:52  <isaacs>indutny: oh, but it's just the "added 'end' but nevre read()" problem
17:37:03  <indutny>aha!
17:37:06  <isaacs>indutny: so... this commit makes that slightly worse, i guess.
17:37:10  <isaacs>but only in dumb tests.
17:37:15  <indutny>aha! :)
17:37:19  <indutny>well, its API change
17:37:58  <isaacs>calling the handler after the fact is somewhat lower-impact. but you have to read() from reqs anyway, if you're adding an 'end' listener, because they might have POST data or something, and they'll never end.
17:38:13  <isaacs>this just makes it *consistently* a problem instead of *inconsistently* :)
17:38:33  <indutny>hehe
17:38:57  <indutny>so, basically, theese tests was working before by accident
17:39:24  <isaacs>ohh... no, this is also kind of bad, actually..
17:39:40  <isaacs>need a bit of a fix in http.
17:39:43  <isaacs>ok, one second
17:41:05  * hzjoined
17:52:10  <isaacs>all fixed. running tests again.
17:52:40  * kazuponjoined
17:53:46  <isaacs>indutny: i'm afraid about this read()/'end' thing
17:53:58  <isaacs>indutny: i'ts going to break a lot of people's stuff.
17:54:06  <isaacs>but i gues it's better to break consistently than inconsistently
18:03:25  <isaacs>indutny: ok, passing all tests now: https://github.com/isaacs/node/commit/b2c41b1c69482ccc2760e8126d310ac5506742bf
18:03:39  <isaacs>er, rather: https://github.com/isaacs/node/commit/8590f02840e98c35c4e6abb0dcc1ec67c444ec12
18:03:44  <isaacs>(jslint)
18:04:37  <indutny>great
18:04:57  <indutny>well, I'm a little bit afraid
18:04:59  <indutny>too
18:05:04  <indutny>but I agree with you
18:05:08  <indutny>consistency is better
18:05:25  <indutny>I hope there're not much existing streams2 stuff
18:05:35  <indutny>and streams1-mode should work as it was before
18:05:40  <indutny>i.e. no 'end' change
18:06:08  <isaacs>indutny: well, if you care about 'end', but not 'data', it'll break your programs
18:06:17  <isaacs>indutny: because the stream starts out life "paused"
18:06:24  <isaacs>so, if you never read from it, you never get EOF
18:06:30  <isaacs>but really, that kind of makes more sense, i think
18:06:40  <isaacs>like, if you open a file, it doesn't tell you EOF right away.
18:06:44  <isaacs>you have to try to read() it
18:06:56  <indutny>yep
18:07:57  <MI6>joyent/node: isaacs v0.10 * cd2b9f5 : stream: Avoid nextTick warning filling read buffer In the function that - http://git.io/SwBIRw
18:08:08  <rendar>yeah that makes sense, like normal open() and read() on unix
18:17:01  * kazuponquit (Remote host closed the connection)
18:19:12  * isaacsneeds to go buy some coffee beans
18:19:26  <isaacs>bbiab, then 0.10 release building time!
18:19:41  * `3rdEdenjoined
18:21:46  * Raltjoined
18:22:06  <MI6>nodejs-v0.10: #9 UNSTABLE windows-ia32 (6/558) windows-x64 (5/558) http://jenkins.nodejs.org/job/nodejs-v0.10/9/
18:24:25  * Raltquit (Remote host closed the connection)
18:32:23  * isaacs_mobilejoined
18:36:12  <MI6>joyent/node: isaacs v0.10 * 327b6e3 : stream: Don't emit 'end' unless read() called This solves the problem of - http://git.io/4mbTXg
18:47:24  * kazuponjoined
18:48:11  <KiNgMaR>:o
18:50:30  <MI6>nodejs-v0.10: #10 UNSTABLE windows-ia32 (4/559) osx-ia32 (2/559) windows-x64 (4/559) http://jenkins.nodejs.org/job/nodejs-v0.10/10/
18:56:35  * kazuponquit (Ping timeout: 255 seconds)
18:59:27  * stagasjoined
18:59:44  <Kakera>is cygwin still supported?
18:59:51  <tjfontaine>ugh
19:00:09  <tjfontaine>you ask questions that always hurt me, Kakera :)
19:00:28  <Kakera>how so?
19:00:45  <tjfontaine>makefiles on windows, mingw and cygwin and no vs
19:01:35  <Kakera>well there are mentions of cygwin in years-old issues but not in the current readme
19:01:39  <Kakera>I guess I'll just try it
19:02:08  <tjfontaine>I'm guessing not, the point of libuv was to be able to use the event loop on windows without needing unix emulation
19:18:29  <isaacs>Kakera: No, cygwin is definitely not supported, by node or npm
19:18:55  <tjfontaine>he's doing libuv stuff afaik
19:18:59  <isaacs>Kakera: we used to try to sort of make it work
19:19:16  <isaacs>Kakera: if it works, it's by accident :)
19:19:28  <isaacs>tjfontaine: it's also not supported by libuv :)
19:19:32  <Kakera>http://pastebin.com/D1B96xCG hmm
19:19:39  <tjfontaine>isaacs: most certainly :)
19:20:31  <isaacs>Kakera: Resolved: WONTFIX
19:20:34  <isaacs>Kakera: don't use cygwin
19:20:51  <isaacs>Kakera: ifyou want unix cli tools, use msys stuff that installs with git
19:21:05  <isaacs>Kakera: then you cna type `bash` and enjoy a proper shell
19:21:29  <tjfontaine>he wants to use libuv with is project via makefiles generated by gyp on windows
19:21:30  <Kakera>mingw is fine but gyp doesn't support it
19:21:57  <tjfontaine>Kakera: libuv's default makefile does work with mingw, can't you write your own makefile? it's not that hard
19:22:03  <tjfontaine>certainly easier than teaching gyp about mingw
19:23:30  <Kakera>I have no idea how makefiles work
19:24:34  <tjfontaine>all:\n\tg++ <normal compiler shtuff>
19:26:21  * isaacschanged nick to _isaacs_away_lea
19:28:49  <wolfeidau>tjfontaine: That is an amazingly short intro to make files
19:29:31  <tjfontaine>wolfeidau: the rest is just sugar :P
19:29:47  <wolfeidau>ROFL
19:29:50  * loladirojoined
19:30:59  <tjfontaine>Kakera: really makefile's are just fancy bash scripts, there are a bazillion and one tutorials and examples to follow on the interwebs, way more documentation and examples surrounding them than gyp, and considering your project isn't particularly convulted based on your other gyp that you showed before I am not sure you care too much about those features of gyp
19:31:14  * mikealjoined
19:34:46  * hzquit
19:36:33  * isaacs_mobilequit (Ping timeout: 248 seconds)
19:38:04  * hzjoined
19:40:44  * mikealquit (Quit: Leaving.)
19:51:33  * isaacs_mobilejoined
19:53:17  <isaacs_mobile>Having logs in the header is really handy for mobile irc clients.
19:53:22  * kazuponjoined
19:54:12  <tjfontaine>isaacs_mobile: once upon a time I hacked together an irssi plugin that exported your irssi screen via websocket, so you had exactly what the irssi buffer was, but it was particularly lacking in the ui front
19:55:04  <isaacs_mobile>Limechat mobile is a pretty yo
19:55:14  <isaacs_mobile>Yo = yo
19:55:16  <isaacs_mobile>Ui
19:55:18  <tjfontaine>heh
19:55:27  <isaacs_mobile>Damn autocorrect is persistent.
19:59:04  <tjfontaine>I knew I had it in dropbox somewhere https://dl.dropbox.com/u/35720/ipw.png decidedly unpretty
19:59:52  <isaacs_mobile>Not too terrible.
20:00:11  <tjfontaine>it was jquery-ui, so it was a pain
20:00:29  <tjfontaine>but I do have a little js parser for the irssi color markup that they use
20:00:49  <tjfontaine>so the theme you use on your shell would match the theme you use in the webclient
20:02:20  <isaacs_mobile>Yikes
20:03:23  <tjfontaine>tar: pax_global_header: typeflag 'g' not recognized, converting to regular file
20:03:30  <tjfontaine>sad-face, ancient tar on smartos
20:03:44  <tjfontaine>I'm sure mentioning that will earn me a demerit
20:04:22  * tjfontaineadds an alias for gtar
20:04:43  <isaacs_mobile>Yeah, Solaris posix tar is terrible.
20:06:43  <isaacs_mobile>I thought smart os zones had gtar already.
20:07:01  <tjfontaine>they have gtar, but /usr/bin/tar is first
20:07:54  * kazuponquit (Ping timeout: 264 seconds)
20:13:48  <isaacs_mobile>Oh, wild. Should set /{opt,usr}/local/bin firs in path
20:25:38  * isaacs_mobilequit (Remote host closed the connection)
20:31:35  * isaacs_mobilejoined
20:36:41  * KiNgMaRquit (Ping timeout: 245 seconds)
20:38:23  * KiNgMaRjoined
20:42:06  * isaacs_mobilequit (Remote host closed the connection)
20:42:50  * piscisaureus_joined
21:00:11  * mikealjoined
21:04:32  * kazuponjoined
21:08:46  * kazuponquit (Ping timeout: 252 seconds)
21:24:07  * mikealquit (Quit: Leaving.)
21:33:05  * piscisaureus_quit (Read error: Connection reset by peer)
21:35:48  * rendarquit
21:39:19  * wavded_quit (Read error: Operation timed out)
21:40:57  * _isaacs_away_leafg
21:41:01  * _isaacs_away_leachanged nick to isaacs
21:44:26  * loladiroquit (Quit: loladiro)
21:54:24  * TooTallNatejoined
22:04:57  * kazuponjoined
22:11:38  * kazuponquit (Ping timeout: 256 seconds)
22:41:44  * brsonjoined
22:48:01  * stagas_joined
22:49:15  * stagasquit (Ping timeout: 276 seconds)
22:50:41  * stagasjoined
22:52:17  * rvaggquit (Ping timeout: 248 seconds)
22:54:23  * stagas_quit (Ping timeout: 248 seconds)
22:54:30  <Kakera>I think I'll learn cmake instead
22:54:35  <Kakera>it looks really promising so far
22:57:22  * mikealjoined
22:59:27  * rvaggjoined
23:00:42  * loladirojoined
23:04:21  * mikealquit (Quit: Leaving.)
23:06:22  * isaacs_mobilejoined
23:06:31  * isaacs_mobilequit (Client Quit)
23:07:21  * kazuponjoined
23:12:39  * kazuponquit (Ping timeout: 276 seconds)
23:21:19  <pquerna>https://github.com/jmatthewsr-ms/node-slab-memory-issues <- was thinking if a slab has less than x% used to compact it, but... i guess we assume buffers can be used in another threads etc etc :|
23:21:29  <pquerna>(compcat on someone releasing part of the slab)
23:33:58  <wolfeidau>pquerna: Very interesting project I wonder how other services which use buffers get around this.. cant be isolated to node I am guessing
23:38:09  * wavded_joined
23:42:12  * `3rdEdenquit (Remote host closed the connection)
23:42:20  * Kakeraquit (Ping timeout: 255 seconds)
23:54:27  * TooTallNatequit (Quit: Computer has gone to sleep.)
23:57:12  * hzquit (Ping timeout: 264 seconds)