00:00:18  * c4milojoined
00:17:27  * mikealjoined
00:21:28  * paddybyers_quit (Ping timeout: 246 seconds)
00:21:50  * mikealquit (Ping timeout: 252 seconds)
00:22:53  * hzquit (Disconnected by services)
00:22:56  * hzjoined
00:25:11  * stagasquit (Ping timeout: 260 seconds)
00:27:01  * stagasjoined
00:33:04  * hzquit
00:35:26  * benoitcquit (Excess Flood)
00:35:34  * indexzerojoined
00:40:23  * benoitcjoined
00:50:03  * loladirojoined
00:50:40  * loladiroquit (Client Quit)
00:58:06  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:58:34  * mikealjoined
01:00:37  * bradleymeckquit (Quit: bradleymeck)
01:03:15  * EhevuTovjoined
01:11:51  <bnoordhuis>vim bug? when colorcolumn is set, gq (wrap) ignores the value of textwidth
01:12:08  <bnoordhuis>maybe a documentation bug
01:12:14  * EhevuTovquit (Quit: This computer has gone to sleep)
01:13:24  <bnoordhuis>oh wait, maybe it's the other way around - setting textwidth seems to change colorcolumn as well
01:15:54  * TooTallNatejoined
01:18:43  * pooyajoined
01:22:00  * perezdjoined
01:26:00  * mikealquit (Quit: Leaving.)
01:35:47  * benoitcquit (Excess Flood)
01:36:23  * benoitcjoined
01:37:38  * mikealjoined
01:41:18  * c4milo_joined
01:44:17  * c4milo_quit (Remote host closed the connection)
01:47:10  * indexzeroquit (Quit: indexzero)
01:58:56  * c4miloquit (Remote host closed the connection)
02:30:15  * TooTallNatequit (Quit: Computer has gone to sleep.)
02:31:09  * stagasquit (Read error: Connection reset by peer)
02:32:38  * stagasjoined
02:36:10  * benoitcquit (Excess Flood)
02:40:54  * benoitcjoined
02:46:09  * pooyaquit (Quit: pooya)
02:54:12  <bnoordhuis>creationix: in case you're still working on ssh in c9: https://github.com/mscdex/ssh2
02:56:04  * pooyajoined
03:01:42  * indexzerojoined
03:04:51  * TooTallNatejoined
03:13:26  * EhevuTovjoined
03:19:39  * indexzeroquit (Quit: indexzero)
03:20:44  * TooTallNatequit (Quit: Computer has gone to sleep.)
03:24:47  * philips_quit (Changing host)
03:24:47  * philips_joined
03:33:36  * bradleymeckjoined
03:33:42  * bradleymeckquit (Client Quit)
03:36:29  * stagas_joined
03:36:30  * benoitcquit (Excess Flood)
03:37:27  * stagasquit (Ping timeout: 260 seconds)
03:37:39  * stagas_changed nick to stagas
03:37:57  * benoitcjoined
03:38:04  * AvianFluquit (Remote host closed the connection)
03:39:54  * pooyaquit (Quit: pooya)
03:40:51  * pooyajoined
03:51:04  * bnoordhuisquit (Read error: Operation timed out)
03:52:56  * pooyaquit (Quit: pooya)
04:04:15  * loladirojoined
04:24:30  * stagasquit (Ping timeout: 276 seconds)
04:26:09  * stagasjoined
04:28:18  * EhevuTovquit (Ping timeout: 264 seconds)
04:31:15  * indexzerojoined
04:36:52  * benoitcquit (Excess Flood)
04:45:58  * benoitcjoined
04:53:22  * abraxasjoined
05:39:19  * benoitcquit (Excess Flood)
05:43:30  * benoitcjoined
05:50:26  * loladiroquit (Quit: loladiro)
05:52:04  * loladirojoined
06:09:33  * mjr_quit (Quit: mjr_)
06:13:03  * Benviequit (Ping timeout: 276 seconds)
06:14:46  * Benviejoined
06:24:03  * Benviequit (Ping timeout: 260 seconds)
06:25:00  * Benviejoined
06:29:40  * Benviequit (Ping timeout: 248 seconds)
06:30:40  * Benviejoined
06:39:16  * benoitcquit (Excess Flood)
06:39:18  * Benviequit (Ping timeout: 245 seconds)
06:40:07  * Benviejoined
06:44:31  * benoitcjoined
06:52:23  * Benviequit (Ping timeout: 268 seconds)
07:01:25  * Benviejoined
07:12:08  * rendarjoined
07:19:05  * indexzeroquit (Quit: indexzero)
07:23:04  * Benviequit (Ping timeout: 260 seconds)
07:23:47  * paddybyersjoined
07:26:09  * Benviejoined
07:29:26  * stagasquit (Ping timeout: 255 seconds)
07:31:22  * stagasjoined
07:39:38  * benoitcquit (Excess Flood)
07:41:06  * perezdquit (Quit: perezd)
07:45:35  * `3rdEdenjoined
07:45:51  * paddybyersquit (Ping timeout: 245 seconds)
07:46:32  * benoitcjoined
07:48:07  * paddybyersjoined
07:52:32  * Raltjoined
08:01:42  * loladiroquit (Quit: loladiro)
08:20:41  * benoitcquit (Excess Flood)
08:24:31  * benoitcjoined
08:25:38  * benoitcquit (Excess Flood)
08:35:45  * mikealquit (Quit: Leaving.)
08:41:44  * mikealjoined
08:59:19  * Benviequit (Ping timeout: 260 seconds)
09:00:15  * benoitcjoined
09:01:11  * Benviejoined
09:13:51  * stagas_joined
09:24:57  * `3rdEdenquit (Quit: brbbbb)
09:32:14  * `3rdEdenjoined
09:55:13  * stagasquit (Read error: Connection reset by peer)
09:55:48  * stagasjoined
10:01:36  * sergimjoined
10:34:53  * hzjoined
10:37:20  * roxlupart
11:02:54  * hzquit (Disconnected by services)
11:02:57  * hzjoined
11:13:31  * hzquit
11:20:17  * stagas_quit (Ping timeout: 255 seconds)
11:26:09  * hzjoined
11:27:29  * stagas_joined
11:28:04  * stagasquit (Ping timeout: 246 seconds)
11:28:09  * stagas_changed nick to stagas
11:48:11  * stagasquit (Read error: Connection reset by peer)
11:48:43  * stagasjoined
11:55:31  * hzquit (Read error: Connection reset by peer)
11:55:58  * hzjoined
11:57:23  * hzquit (Read error: Connection reset by peer)
11:58:48  * hzjoined
12:00:10  * hzquit (Read error: Connection reset by peer)
12:25:15  * stagas_joined
12:27:14  * AvianFlujoined
12:28:10  * sergimquit (Quit: Computer has gone to sleep.)
12:37:48  * hzjoined
12:52:37  * sergimjoined
13:00:30  * hzquit (Ping timeout: 272 seconds)
13:05:47  * hzjoined
13:07:07  * sergimquit (Quit: Computer has gone to sleep.)
13:13:30  * sergimjoined
13:22:22  * stagasquit (Ping timeout: 260 seconds)
13:24:00  * stagas_quit (Ping timeout: 276 seconds)
13:35:02  * stagas_joined
13:35:23  * stagas__joined
13:35:43  * stagas__changed nick to stagas
13:36:00  * hzquit
13:48:26  * AvianFluquit (Remote host closed the connection)
13:48:44  * hzjoined
14:08:56  * TheJHjoined
14:21:47  * paddybyers_joined
14:24:16  * paddybyersquit (Ping timeout: 246 seconds)
14:24:17  * paddybyers_changed nick to paddybyers
14:33:19  * AvianFlujoined
14:47:28  * c4milojoined
14:53:08  * mjr_joined
14:54:53  * piscisaureus_joined
14:58:52  * bnoordhuisjoined
14:59:40  <bnoordhuis>sup all?
14:59:59  <tjfontaine>gday
15:01:12  * bradleymeckjoined
15:02:40  <Yorhel>Meh
15:02:46  * AvianFluquit (Remote host closed the connection)
15:03:30  <Yorhel>I'm trying to design a high-level stream API on top of libuv, adding support for TLS and zlib compression and being efficient enough for gbit file transfers
15:03:51  <Yorhel>but somehow that's quite a challenge
15:06:52  <piscisaureus_>hey all
15:06:56  <Yorhel>Has anyone attempted writing something similar?
15:06:58  <piscisaureus_>is it almost weekedn yet?
15:07:08  <tjfontaine>piscisaureus_: yup it's friday night
15:08:28  <Yorhel>(And, for anyone interested, here's a brainstorm of what I have in mind: http://p.blicky.net/idz4f - Hopefully it's readable.)
15:08:29  <bnoordhuis>Yorhel: i heard node.js did a pretty good job
15:11:45  * hij1nxquit (Quit: WeeChat 0.3.2)
15:11:47  <Yorhel>bnoordhuis: where do I look?
15:12:05  * hij1nxjoined
15:12:10  <bnoordhuis>Yorhel: for zlib in src/node_zlib.cc
15:12:22  <bnoordhuis>Yorhel: though admittedly node_zlib.cc farms out the work to the thread pool
15:13:11  <bnoordhuis>the ssl/tls stream api is mostly implemented in js btw
15:18:27  <piscisaureus_>bnoordhuis: why does getaddrinfo_a not do some sort of epoll notification?
15:18:56  <bnoordhuis>piscisaureus_: because that'd be too easy
15:18:57  <piscisaureus_>gaifd_create
15:19:07  <piscisaureus_>yeah
15:19:10  <piscisaureus_>too useful
15:29:31  <bnoordhuis>dtruss is such a throwback compared to strace...
15:30:31  <bnoordhuis>in before "it's open source"
15:30:59  * deoxxa[cookies]hints at it being open source
15:32:27  * sergimquit (Quit: Textual IRC Client: http://www.textualapp.com/)
15:37:53  <bnoordhuis>piscisaureus_: uv_poll_t question, does windows somehow signal a POLLHUP?
15:38:12  <piscisaureus_>bnoordhuis: umm, what do you mean?
15:38:21  <piscisaureus_>bnoordhuis: it signals it as either POLLERR or POLLRD
15:38:27  <bnoordhuis>piscisaureus_: i'm not setting EPOLLHUP on linux and filtering out EV_EOF on darwin/bsd which feels like a waste
15:38:54  <piscisaureus_>bnoordhuis: EPOLLHUP is also reported as EPOLLRDNORM right?
15:39:09  <piscisaureus_>bnoordhuis: lemme look it up to be sure
15:39:51  <bnoordhuis>piscisaureus_: you mean EPOLLRDHUP? if yes, sorry that's what i meant :)
15:40:36  <piscisaureus_>bnoordhuis: https://github.com/joyent/libuv/blob/master/src/win/poll.c#L176-183
15:41:09  <piscisaureus_>bnoordhuis: AFD_POLL_DISCONNECT (graceful close) and AFD_POLL_ABORT (hard close) are both reported as UV_READABLE
15:41:16  <bnoordhuis>ah okay
15:41:31  <bnoordhuis>maybe a future improvement for the api: UV_HANGUP
15:41:47  <bnoordhuis>or UV_DISCONNECT
15:41:54  <piscisaureus_>bnoordhuis: well we could but the select() thing doesn't support it
15:42:06  <piscisaureus_>bnoordhuis: uv-win has this fallback path
15:42:17  <piscisaureus_>in case efficient polling isn't possible
15:42:37  <bnoordhuis>piscisaureus_: ah. maybe then as an optional event
15:42:56  <bnoordhuis>if (events & UV_DISCONNECT) // don't read now, pointless
15:43:02  <piscisaureus_>ah yeah
15:43:39  <piscisaureus_>bnoordhuis: but how does the user distinguish between EOF and ECONNRESET/ECONNABORTED then ?
15:44:15  <bnoordhuis>piscisaureus_: i don't tjink those last two are reported as POLLHUP/EPOLLRDHUP/EV_EOF
15:44:18  <bnoordhuis>*think
15:44:50  <piscisaureus_>I am entirely sure, but I think AFD_POLL_DISCONNECT matches pretty well with EPOLLRDHUP
15:45:01  <piscisaureus_>but who knows, I never tested it and there's no source and no docs
15:45:09  <bnoordhuis>piscisaureus_: am or am not entirely sure?
15:45:19  <piscisaureus_>*am not
15:45:25  <bnoordhuis>right, that makes more sense :)
15:45:59  <bnoordhuis>okay, i'll open an issue so we don't forget
15:46:21  <bnoordhuis>or rather, get reminded again at some indeterminate time in the future
15:46:22  <piscisaureus_>bnoordhuis: I realize that adding another event to uv_poll on windows makes the code much more complex
15:46:42  <bnoordhuis>piscisaureus_: you mean the uv-win code or the libuv user's code?
15:46:47  <piscisaureus_>no, my code
15:46:57  <bnoordhuis>oh, i don't have a problem with that
15:47:11  * bnoordhuisducks
15:47:53  * loladirojoined
15:47:55  <piscisaureus_>bnoordhuis: I'm seeing more and more reports of people complaining that stdout gets clipped on windows.
15:48:00  * hij1nxquit (Quit: leaving)
15:48:06  <bnoordhuis>piscisaureus_: yes. you should fix that
15:48:16  * hij1nxjoined
15:48:21  <bnoordhuis>any idea what's causing that?
15:48:25  <piscisaureus_>bnoordhuis: yes
15:48:31  <piscisaureus_>bnoordhuis: it happens when you pipe the output
15:49:10  <piscisaureus_>bnoordhuis: it's just that node exits while there are still writes in the thread pool
15:49:23  <piscisaureus_>bnoordhuis: because on windows pipe-stdio is still async
15:49:47  <bnoordhuis>piscisaureus_: so the conceptually easy fix is to wait for the thread pool to drain, i presume?
15:49:55  <piscisaureus_>yes
15:50:02  <piscisaureus_>or close all libuv handles
15:50:09  <piscisaureus_>and wait for the thread pool to flush
15:50:15  <piscisaureus_>I mean, theoretically file writes could also be lost
15:50:21  <piscisaureus_>(on unix, too)
15:51:53  <piscisaureus_>bnoordhuis: man 2 setpgid -> there are 2 signatures for setpgrp()
15:52:20  <piscisaureus_>bnoordhuis: which one do I use?
15:54:07  <bnoordhuis>piscisaureus_: the (pid, pgid) one, i think
15:54:24  <tjfontaine>hm
15:54:31  <bnoordhuis>piscisaureus_: depends on what you're compiling your code as
15:54:41  <piscisaureus_>bnoordhuis: as default :-p
15:54:54  <bnoordhuis>piscisaureus_: no -D_XOPEN_SOURCE=num or anything?
15:54:54  <piscisaureus_>bnoordhuis: do I specify _BSD_SOURCE or that sort of crap
15:55:05  <piscisaureus_>ah ya
15:55:11  <bnoordhuis>piscisaureus_: yes, you should - otherwise you're at the mercy of the compiler
15:55:19  <bnoordhuis>and compilers are ruthless, evil things
16:04:36  * stagas_quit (Ping timeout: 248 seconds)
16:06:42  * stagasquit (Ping timeout: 264 seconds)
16:18:57  * mjr_quit (Quit: mjr_)
16:35:03  * `3rdEdenquit (Remote host closed the connection)
16:38:56  * stagasjoined
16:47:16  * bradleymeckquit (Ping timeout: 246 seconds)
16:50:39  * bradleymeckjoined
17:00:53  * AvianFlujoined
17:11:41  * janjongboomquit (Quit: janjongboom)
17:14:38  * stagasquit (Quit: Bye)
17:18:09  <MI6>joyent/libuv: Ben Noordhuis master * 3243e9a : test: fix (harmless) typo in function name - http://git.io/a2TsCg
17:18:50  * dapjoined
17:19:59  * travis-cijoined
17:19:59  <travis-ci>[travis-ci] joyent/libuv#869 (master - 3243e9a : Ben Noordhuis): The build passed.
17:19:59  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/625340066eba...3243e9ae673b
17:19:59  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/3165685
17:19:59  * travis-cipart
17:21:54  * AvianFluquit (Ping timeout: 240 seconds)
17:24:58  * indexzerojoined
17:32:01  <isaacs>i got really scared yesterday because streams2-net was showing numbers like 1.2-2.5 on benchmark/throughput.js, and master was around 9.0
17:32:08  <isaacs>then i rebased streams2 onto master again
17:32:16  <isaacs>something in libuv was badly broken for a little while, it seems
17:33:23  <piscisaureus_>isaacs: so what does it show now, then? 9.0 too?
17:33:31  <isaacs>piscisaureus_: close
17:33:34  <isaacs>it's about 5% slower
17:33:39  <isaacs>2-5%
17:33:52  <isaacs>so, not acceptable, but very very close.
17:34:16  <isaacs>at this point, benchmark and polish should be enough to get us there
17:34:21  <piscisaureus_>good
17:40:42  * c4miloquit (Remote host closed the connection)
17:41:11  <isaacs>hm. looks like i might need a slightly rearranged throughput.js benchmark to trakc it down, though.
17:43:40  <bnoordhuis>isaacs: any idea what the brokenness was?
17:43:40  <tjfontaine>so this guy and his timer benchmarks... https://github.com/joyent/node/issues/4273 is it worth spending time doing FreeList for Timer allocations?
17:44:08  <bnoordhuis>isaacs: btw, can it have been v8? we were compiling that at -O0 in release mode for a while
17:44:13  <bnoordhuis>tjfontaine: meh
17:44:24  <bnoordhuis>most people don't instantiate 300K timers
17:44:28  <tjfontaine>bnoordhuis: that was what I expected to hear
17:44:40  <indutny>bnoordhuis: hoya
17:44:42  <tjfontaine>bnoordhuis: that's how I've responded to most of his issues
17:44:47  <indutny>bnoordhuis: have you seen select() pull request?
17:44:49  <isaacs>some people get their teeth in a particular optimization, and just never stop
17:44:58  <tjfontaine>yes
17:45:00  <isaacs>the best response is to figure out a way to make that part of the code like 90% faster
17:45:02  <bnoordhuis>something to file under 'optimizations, future (very far)'
17:45:09  <isaacs>then they usually calm down.
17:45:26  <bnoordhuis>indutny: i'm aware of its existence, if that is what you mean :)
17:45:36  <isaacs>bnoordhuis: it very well can have been v8, yes, i had forgotten about that
17:46:01  <isaacs>bnoordhuis: the fact that this benchmark uses child processes, and must be run repeatedly, makes it very hard for jsstack to translate all the frames to js lingo
17:46:12  <isaacs>bnoordhuis: so you get a lot of 0x80beaf0
17:46:31  * TooTallNatejoined
17:46:40  <bnoordhuis>isaacs: what? you don't know the address of every symbol in node?
17:47:01  <isaacs>bnoordhuis: no, i have dutchmen for that.
17:47:07  <indutny>huh
17:47:24  <indutny>even my wife knows half of them
17:47:30  <bnoordhuis>oh, snap!
17:47:30  <isaacs>tjfontaine, bnoordhuis: My long-term goal is to remove FreeList entirely.
17:47:57  <isaacs>tjfontaine, bnoordhuis: Keeping JS objects around and re-using them is a SERIOUSLY bad code smell. it has led to pain and suffering in the past, and it will continue to cause suffering.
17:48:07  <tjfontaine>isaacs: aww, but it makes debugging so much fun
17:48:28  <isaacs>tjfontaine: it does make debugging more satisfying, yes, it's true :)
17:48:41  <isaacs>because you always know what's causing the bug :)
17:48:46  <tjfontaine>isaacs: in other block-heap style code I usually just have a flag that turns it off and makes them more traditional alloc/free's
17:48:55  <bnoordhuis>agreed that the freelist should go, eventually
17:49:19  <isaacs>before we can remove freelist, we need an http parser that is cheap to create and initialize
17:49:25  <isaacs>that's the only thing still using it
17:49:53  <indutny>indeed
17:50:09  <bnoordhuis>indutny: are you still in the ex-ussr or?
17:50:11  <isaacs>so, maybe felixge will save the day eventually :)
17:50:18  <indutny>bnoordhuis: still there
17:50:20  <indutny>bnoordhuis: ah wait
17:50:21  <indutny>bnoordhuis: no
17:50:29  <indutny>bnoordhuis: look at the window!
17:50:37  <indutny>bnoordhuis: I'm living in your garden
17:50:42  * bnoordhuisfeels a little spooked
17:50:49  <bnoordhuis>but i wish you well, hope it's not too cramped
17:51:02  <bnoordhuis>so when are you coming to +31 again?
17:51:06  * dapquit (Quit: Leaving.)
17:51:46  * dapjoined
17:53:54  <indutny>I hope soon :)
17:54:00  <indutny>I need to ask HQ
17:54:58  <bnoordhuis>okay, nice
17:55:03  <bnoordhuis>bring your wife along, i'd like to meet her
17:55:12  <indutny>surely I will
17:55:14  <indutny>bring my wife
17:55:29  <bnoordhuis>does she speak english?
17:55:33  <indutny>yeah
17:55:37  <indutny>but don't really likes it
17:55:46  <indutny>she's much better than me at it
17:55:52  <indutny>ok
17:55:54  <bnoordhuis>she prefers dutch? i understand, it's much more expressive
17:55:57  * dapquit (Client Quit)
17:55:58  <indutny>time for me to become a little bit offline
17:56:07  <indutny>bnoordhuis: :)
17:56:22  <indutny>how to say "gfy" on dutch?
17:56:23  <tjfontaine>exspressive? clearly you meant guttural :P
17:56:45  <indutny>something like this "Krijg de klere" ?
17:56:54  <indutny>no
17:56:55  <bnoordhuis>tjfontaine: ah, but the grunts and the groans convey so much meaning and intent
17:56:56  <indutny>it's too simple
17:57:20  <indutny>in russian you can say "gfy" in so many different ways
17:57:29  <indutny>see ^ russian is much more expressive
17:57:43  <indutny>that's why it's not really useful for software development
17:57:53  <indutny>people needs minimum amount of words and simple sentences
17:58:14  <indutny>so everyone is writing almost the same code, when they're thinking about the same thing
17:58:25  <indutny>ok
17:58:28  <indutny>word flow stop
17:58:30  <indutny>bb
17:58:31  * mmaleckihints at perl
18:07:02  * `3rdEdenjoined
18:14:44  * hzquit (Disconnected by services)
18:14:47  * hzjoined
18:17:21  * hzquit (Disconnected by services)
18:17:24  * hzjoined
18:22:33  <bnoordhuis>$ python tools/test.py simple
18:22:33  <bnoordhuis>[02:11|% 100|+ 475|- 0]: Done
18:22:45  <bnoordhuis>^ node master + libuv rm-ev on os x
18:23:00  <bnoordhuis>now all that remains is sunos
18:23:09  <bnoordhuis>but fortunately no one uses that anyway
18:23:59  * bradleymeckquit (Quit: bradleymeck)
18:26:45  <bnoordhuis>isaacs: pro tip: if your company wants to make programmers and admins happy, it should put bash-completion in the base package repo
18:27:06  <bnoordhuis>i know it's in pkgsrc so it can't be hard
18:27:12  <isaacs>i agree
18:27:51  * paddybyersquit (Ping timeout: 260 seconds)
18:35:14  * c4milojoined
18:35:34  * Ralt_joined
18:40:02  * Ralt_quit (Remote host closed the connection)
18:52:35  * joshthecoderjoined
18:54:46  <isaacs>wow, this is interesting. so, i wrote a new benchmark that just does a very simple measurement of throughput on an echo sever.
18:55:12  <isaacs>on master, it gets ~2.5Gbits/sec, but randomly drops down to 1.7 or 1.5 sometimes for one second
18:55:16  * EhevuTovjoined
18:55:25  <isaacs>on streams2-net, it's vry very consistently 2.1Gbits/second
18:55:47  <isaacs>oh, whoops, no, spoke too soon. it does the same behavior, it looks li.e
18:55:59  <isaacs>levels out around 1.8
18:56:07  <tjfontaine>would be interesting to see if gc is occurring around that time?
18:57:30  <isaacs>master levels out around 2.0
18:57:35  * pooyajoined
18:57:46  <isaacs>so, master's slightly faster, but the wobble is the same. that's useful :)
18:57:54  <isaacs>that's something i can profile
18:58:23  <isaacs>there shouldn't be much gc going on
18:58:42  <isaacs>it's making exactly one connection, and just sending buttloads of data over it
18:58:49  <isaacs>i guess there's buffers and stuff getting copied around
19:02:11  * EhevuTovquit (Quit: This computer has gone to sleep)
19:02:48  <isaacs>bnoordhuis, piscisaureus_, indutny, anyone else: review? https://github.com/isaacs/node/commit/7db4a5f1a9c896d6e50c7cbe6c885e7855d1cfd5
19:03:56  * lohkeyjoined
19:06:26  * stagasjoined
19:09:25  <isaacs>oh, wait, removed the toString() chunks, since i'm not using them in the bench anyway: https://github.com/isaacs/node/commit/master
19:10:49  <piscisaureus_>isaacs: why do you process.nextTick(flow) ?
19:11:20  <piscisaureus_>isaacs: btw it's just a benchmark, it looks good (lest the unused vars) so land it if it works
19:12:01  <isaacs>piscisaureus_: to prevent stack overflow when using small buffer lengths
19:12:44  <piscisaureus_>isaacs: then why don't you
19:12:54  <piscisaureus_>while (res.write(chunk));
19:13:02  <piscisaureus_>dest.once('drain', this.flow)
19:13:43  <isaacs>piscisaureus_: oh, yeah, that'd be a little more efficient
19:13:55  <isaacs>ok, flaming streams2: http://static.izs.me/streams2-throughput-flamegraph3.svg
19:13:57  <piscisaureus_>isaacs: I suppose it would be closer to it's intended use too : -)
19:14:10  * V1joined
19:14:18  <piscisaureus_>that looks pretty complicated
19:14:25  <piscisaureus_>(the flame graph)
19:14:29  <piscisaureus_>lots of moving parts
19:15:34  <isaacs>some of these functions can definitely be streamlined a bit
19:15:56  <isaacs>especially if we remove multi-pipe functionality, or make it go on a slow path when you do that, instead of forcing it to alwasy be an array.
19:16:00  * `3rdEdenquit (Disconnected by services)
19:16:06  * V1changed nick to `3rdEden
19:16:34  <isaacs>and i can probably remove the .once() usage by setting a flag to say that it's already been attached
19:16:46  <isaacs>this is really really promising. awesome stuf.
19:16:51  <isaacs><3 flamegraphs SO GODDAMN MUCH
19:17:25  * mikealquit (Quit: Leaving.)
19:17:35  <piscisaureus_>isaacs: you can probably just add a "global" process.on('drain', flow)
19:17:36  <piscisaureus_>:-0
19:17:57  <isaacs>piscisaureus_: the code int eh bench itself is not even registering on the flamegraph
19:18:02  <isaacs>piscisaureus_: so, rounding error :)
19:18:14  <isaacs>piscisaureus_: this is all in net.js and _stream_*.js
19:18:28  <piscisaureus_>isaacs: sure - it's not about the benchmark efficiency per se
19:18:40  <isaacs>and the benchmark classes are intentionally not "streams" for real, so that it's less confusing to the output
19:18:42  * mikealjoined
19:19:00  <piscisaureus_>isaacs: it also serves the purpose of the example how the api should be used
19:20:55  * brsonjoined
19:21:55  * loladiroquit (Quit: loladiro)
19:23:22  <isaacs>true that
19:23:36  <isaacs>ok, yoga time, then probably going to be offline until tomorrow, which i will call wednesday
19:23:46  * isaacscrossing the international date line
19:23:50  <isaacs>it's like time travel!
19:23:53  <piscisaureus_>isaacs: where are you then?
19:23:54  <isaacs>except sucky!
19:24:01  <isaacs>Australia, then japan, then korea
19:24:02  <CoverSlide|TPFR>yoga?
19:24:04  <piscisaureus_>ah
19:24:06  <piscisaureus_>oh that
19:24:09  <isaacs>yeah
19:24:09  <piscisaureus_>isaacs: have fun
19:24:12  <isaacs>i'll try :)
19:24:30  <piscisaureus_>isaacs: don't let the aussies get ya
19:26:50  * loladirojoined
19:32:02  * TheJHquit (Ping timeout: 252 seconds)
19:51:38  * `3rdEdenquit (Remote host closed the connection)
19:52:52  * TheJHjoined
19:57:54  * bradleymeckjoined
20:01:47  * lohkeyquit (Quit: lohkey)
20:04:22  * bradleymeckquit (Quit: bradleymeck)
20:10:19  * EhevuTovjoined
20:13:26  * c4miloquit (Remote host closed the connection)
20:15:16  * stagasquit (Ping timeout: 248 seconds)
20:18:06  * stagasjoined
20:20:30  * c4milojoined
20:21:14  * bradleymeckjoined
20:22:57  <indutny>isaacs: nice
20:32:05  * lohkeyjoined
20:36:44  * Ralt_joined
20:38:03  * bnoordhuisquit (Ping timeout: 260 seconds)
20:41:13  * indexzeroquit (Quit: indexzero)
20:41:52  * indexzerojoined
20:54:41  * bnoordhuisjoined
20:56:39  * indexzeroquit (Quit: indexzero)
21:02:30  * bnoordhuisquit (Ping timeout: 260 seconds)
21:02:43  * bnoordhuisjoined
21:04:50  * EhevuTovquit (Quit: This computer has gone to sleep)
21:10:43  * indexzerojoined
21:16:10  * `3rdEdenjoined
21:20:58  * benoitcquit (Excess Flood)
21:22:46  * indexzeroquit (Quit: indexzero)
21:24:11  * bradleymeckquit (Quit: bradleymeck)
21:24:22  * benoitcjoined
21:26:09  * pooyaquit (Quit: pooya)
21:29:05  * indexzerojoined
21:32:46  * bnoordhuisquit (Read error: Operation timed out)
21:35:45  * warzjoined
21:40:49  * `3rdEdenquit
21:40:51  * paddybyersjoined
21:44:29  <warz>how should handle scopes be used when using uv_queue_work? in an example i found, it looks like a new scope is created at the beginning of a uv_queue_work "after doing work" function.
21:44:33  <warz>example is this one, https://github.com/joyent/node/wiki/How-to-migrate-from-eio_custom-to-uv_queue_work
21:45:31  <warz>im just trying to track down a seg fault im getting in an addon im writing, using uv_queue_work. my addon exports several functions, and one is called within a callback of another. its the function being called in the callback of that other function that is causing the seg fault.
21:49:16  * Ralt_quit (Remote host closed the connection)
21:50:05  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
21:56:13  <warz>so im thinking ive got a handle scope causing issues in between function calls, or something.
21:57:09  <warz>my code is here, but it's a couple hundred lines, so i'm not really expecting anybody to quickly spot "the problem". https://github.com/ryancole/topdf/blob/master/src/topdf.cc
22:06:04  * indexzeroquit (Quit: indexzero)
22:09:46  <indutny>warz: it doesn't matter
22:09:51  <indutny>warz: just be sure that one is created
22:10:07  <indutny>but do not place one in worker function
22:10:15  <indutny>i.e. HandleScope should be created in only one thread
22:10:23  <indutny>and do_work is invoked in worker thread
22:10:36  <warz>what about the end work function?
22:10:45  <warz>is that back on the main thread
22:10:49  <indutny>warz: yes
22:11:01  <warz>hm ok so thats why that example had it there i guess
22:11:18  <warz>my seg fault may not be because of handle scope issues then
22:11:33  <indutny>can you post backtrace?
22:11:39  <indutny>what's happening?
22:12:27  <warz>it's not printing out a trace log or anything. it just says seg fault (core dumped). does it dump that to somewhere on disk? i'll explain what's happening, i think:
22:12:39  <indutny>warz: gdb --args node your-script.js
22:12:52  <warz>ah ok ill do that one sec
22:13:10  <indutny>warz: then "r"
22:13:13  <indutny>to start program
22:13:17  <indutny>and "bt" once it segfaulted
22:13:46  <warz>ok, been probably 5 years since ive booted on gdb. haha. thanks for that.
22:14:33  <warz>back trace: http://pastebin.com/zmKFXDkX
22:15:11  <warz>hm ok that points me to my setOptions function
22:15:13  <indutny>it seems that you're calling it from worker thread
22:15:24  <indutny>which is not good
22:15:30  <indutny>you can't access v8's heap from other thread
22:15:56  <warz>hm ok, i'll have to rethink my plans there then
22:17:54  * rendarquit
22:19:25  <TooTallNate>warz: is topdf_convert your worker function?
22:19:41  <warz>yea
22:19:44  <TooTallNate>warz: looks like you're calling all sorts of v8 apis in there
22:19:49  <TooTallNate> == bad
22:20:58  <warz>well, the worker function calls a function that i had intended to encapsulate a bunch of options-related setting, but my plan was to just use an Object and check it for set properties.
22:21:12  <warz>but that is bad
22:22:18  <warz>here's the topdf_convert function: https://github.com/ryancole/topdf/blob/master/src/topdf.cc#L84-129
22:24:49  <warz>yea, sure enough if i comment out the call to that setOptions function it no longer seg faults
22:26:06  <TooTallNate>warz: ThrowException is also a no-no on the thread pool
22:26:51  <TooTallNate>warz: instead use a result "int" or something and set that on the thread pool, then in the after callback, check the "result" and create an Error on the correct thread
22:28:45  * mmaleckichanged nick to mmalecki[off]]
22:28:49  * mmalecki[off]]changed nick to mmalecki[off]
22:31:40  <warz>ok. most of those are thankfully from when i was trying to track down where the error was occuring, lol. i put them everywhere.
22:31:57  <warz>but now that im armed with the gdb knowledge, hopefully i dont have to resort to that anymore :P
22:32:20  * hzquit (Disconnected by services)
22:32:23  * hzjoined
22:33:36  * TooTallNatequit (Quit: Computer has gone to sleep.)
22:36:24  * TooTallNatejoined
22:40:34  * TheJHquit (Ping timeout: 240 seconds)
22:43:36  <warz>TooTallNate: so absolutely no v8 apis in worker threads? currently ive got some String::Utf8Value items in my baton struct that goes to the worker thread. should i get those down to char* first?
22:43:59  * pooyajoined
22:44:01  <TooTallNate>warz: absolutely‚Ķ none‚Ķ
22:44:02  <warz>i saw in a mysql client addon they were using String::Utf8Value in their baton structs, so thats where i picked up that pattern
22:44:13  <TooTallNate>warz: so yes, char* first and put it in your data struct
22:44:14  <warz>ok
22:44:38  <TooTallNate>warz: bth, String::Utf8Value *might* be ok, but better safe then sorry IMO
22:45:09  <warz>sure yea, im just converting it to a char* in the worker function anyway
22:45:13  <warz>might as well do it prior
22:46:15  * stagasquit (Ping timeout: 276 seconds)
22:47:03  * indexzerojoined
22:48:26  <indutny>warz: you may get suddenly killed by such stuff
22:48:37  <indutny>for example GC may move string that you're currently trying to read
22:48:45  <indutny>or even better
22:48:51  <indutny>overwrite it's length by something else
22:48:59  <indutny>lets say 0xfffffffff
22:49:20  <warz>yea thatd be bad
22:50:10  <indutny>indeed
22:50:28  <indutny>there're VMs that support concurrent access to structures in heap
22:50:31  <indutny>like Java
22:50:36  <indutny>but not v8 and not javascript (generally)
22:51:16  <warz>what about passing callback functions into uv_queue_work? this baton struct technique seems to be common and ive seen examples that say to pin your callback function onto it.
22:51:35  <indutny>you can pass callback
22:51:35  <warz>obviously its not called until back onto the main thread, in the work done function
22:51:38  <warz>but is that ok?
22:51:38  <indutny>but you can't use it in worker
22:51:41  <indutny>yeah
22:51:48  <indutny>though you need to wrap it in persistent handle
22:51:52  <indutny>Persistent<Function> cb
22:52:06  <warz>ok, i see.
22:52:09  <indutny>that'll prevent callback from being garbage collected
22:54:43  <warz>my strategy with these nodejs addons has been to do as little as possible in v8-land, and put as much of the boilerplate in javascript as i can
22:55:19  <warz>but in this case i think it got a little out of control
22:55:30  <warz>because im just new to the apis
22:56:01  <warz>and the threading got me :(
22:56:17  * c4miloquit (Remote host closed the connection)
22:57:59  <warz>time to head home. ill be back in about an hour. thanks again.
22:58:05  * warzquit
22:58:44  * indexzeroquit (Quit: indexzero)
22:59:23  * piscisaureus_joined
23:00:16  * pooyaquit (Quit: pooya)
23:03:48  <indutny>np
23:03:50  <indutny>you're welcome
23:04:55  * indexzerojoined
23:13:25  * TheJHjoined
23:20:00  * CoverSlide|TPFRquit (*.net *.split)
23:20:00  * wavded_quit (*.net *.split)
23:21:09  * tomshredsjoined
23:26:31  * indexzeroquit (Quit: indexzero)
23:29:18  * CoverSlide|TPFRjoined
23:29:18  * wavded_joined
23:36:48  * sj26quit (Ping timeout: 245 seconds)
23:37:04  * warzjoined
23:39:33  * indexzerojoined
23:43:29  * sj26joined
23:50:45  * TheJHquit (Ping timeout: 265 seconds)
23:50:50  * indexzeroquit (Quit: indexzero)
23:51:56  * mikealquit (Quit: Leaving.)