00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:10:07  <indutny>ok, enough rust for today :)
00:10:11  <indutny>time for sleeping
00:10:12  * indutny&
00:10:12  <LOUDBOT>AND APPARENTLY (SHOCKINGLY) THE RESULTS ON STACKOVERFLOW ARE WRONG
00:16:14  * kevinswiberjoined
00:16:18  * mikealquit (Quit: Leaving.)
00:20:30  * kevinswiberquit (Remote host closed the connection)
00:22:18  * mikealjoined
00:31:25  * mikealquit (Quit: Leaving.)
00:32:33  * rjepart ("Leaving")
00:32:53  * jmar777quit (Remote host closed the connection)
00:34:50  * EhevuTovquit (Quit: This computer has gone to sleep)
00:36:12  * rjejoined
00:40:31  <dap>HI LOUDBOT
00:40:31  <LOUDBOT>I HAVE SO MUCH GAS RIGHT NOW THAT I JUST SET A LEATHER SOFA ON FIRE
00:44:05  * qardquit (Quit: Leaving.)
00:44:48  * piscisaureus_joined
00:54:26  * inolenquit (Quit: Leaving.)
00:55:56  * inolenjoined
00:56:17  * inolenquit (Client Quit)
01:02:08  * mikealjoined
01:11:55  * mikealquit (Ping timeout: 264 seconds)
01:13:06  * mikealjoined
01:16:59  * dapquit (Quit: Leaving.)
01:18:13  * mmaleckichanged nick to mmalecki[zzz]
01:18:41  <creationix>tjfontaine: congrats on being an official part of the team
01:25:48  * piscisaureus_quit (Ping timeout: 252 seconds)
01:27:14  * mikealquit (Quit: Leaving.)
01:28:41  * mikealjoined
01:41:34  * indexzerojoined
01:41:34  * indexzeroquit (Client Quit)
01:41:56  * Benvie_joined
01:44:31  * mbroadstjoined
01:46:17  <mbroadst>hey I'm interested in what reasons there were for not implementing node's core modules as v8::Extensions, was pointed here from #node.js though I understand that libuv can exist independent of node..
01:48:21  <mbroadst>does anyone here know why, or is that one of the great node mysteries :)
02:04:29  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
02:07:51  * abraxasjoined
02:14:35  * qardjoined
02:18:58  * dominictarrjoined
02:19:07  * qardquit (Ping timeout: 264 seconds)
02:24:07  * brsonquit (Quit: leaving)
02:44:50  * kazuponjoined
03:07:23  * brsonjoined
03:10:31  * brsonquit (Client Quit)
03:19:56  * dominictarrquit (Quit: dominictarr)
03:26:12  * c4miloquit (Remote host closed the connection)
03:26:39  * c4milojoined
03:31:07  * c4miloquit (Ping timeout: 258 seconds)
03:44:19  * st_lukejoined
03:50:58  * inolenjoined
03:56:26  * st_lukequit (Remote host closed the connection)
03:59:48  * mikealquit (Quit: Leaving.)
04:07:20  * defunctzombiechanged nick to defunctzombie_zz
04:09:12  * kazuponquit (Remote host closed the connection)
04:10:56  * kazuponjoined
04:11:49  * mikealjoined
04:16:04  <kellabyte>any ideas what this means? I'm trying to use the uv_work_queue()
04:17:01  <kellabyte>Assertion failed: req->type == UV_WORK, file src\win\threadpool.c, line 45
04:17:59  <tjfontaine>the request you passed in wasn't the right type?
04:22:48  * dominictarrjoined
04:23:05  <kellabyte>tjfontaine: what is "the request" mean in this context? the method to call? the uv_work_t?
04:23:28  <tjfontaine>the uv_work_t, brb laundry
04:27:26  <kellabyte>tjfontaine: anything look wrong with this? I followed the example on the libuv website, obviously got something wrong :P https://gist.github.com/kellabyte/5493726
04:29:59  <tjfontaine>kellabyte: your uv_work_t goes out of scope in that function and results in invalid memory?
04:32:42  <kellabyte>ah crap thats probably it
04:32:47  <kellabyte>damn I hate my C noob skills
04:32:57  <tjfontaine>:)
04:33:33  <kellabyte>is there a way to new that on the heap?
04:34:11  <tjfontaine>in C that would be malloc
04:34:16  <kellabyte>ok
04:35:09  <kellabyte>thanks for being tolerant of my noob C problems unrelated to libuv :P
04:35:27  <tjfontaine>haha we all have to start somewhere
04:37:27  <DrPizza>oh hey
04:37:29  <DrPizza>haha
04:37:32  <DrPizza>I have been idling in here all this time
04:39:26  <kellabyte>DrPizza: how long is all this time? :P
04:39:37  <DrPizza>several years.
04:41:26  <kellabyte>holy crap
04:48:45  <DrPizza>?
04:49:49  <DrPizza>kellabyte: if you're running on Windows you really should use C++ and not C, because you should be using Visual Studio, and while its C++ support is mostly decent, its C support is not.
04:49:56  <DrPizza>I keep asking when they will implement C99.
04:49:58  <DrPizza>They keep not answering.
04:51:49  <kellabyte>lol
04:52:15  <kellabyte>in one project I'm messing with mostly C++, in this one C
04:52:30  <DrPizza>as a practical matter, C is literally devoid of merit
04:52:34  <DrPizza>especially C89/C90
04:52:44  <DrPizza>Can't even mix declarations and code.
05:04:11  <kellabyte>oh boy I'm doing some real bad things somewhere LOL
05:04:35  <kellabyte>HEAP[hello_world.exe]: HEAP: Free Heap block 000000F7387EDCB0 modified at 000000F7387EDD00 after it was freed
05:04:37  <kellabyte>:P
05:07:51  <tjfontaine>heh
05:13:52  <kellabyte>I wonder what that means, I'm just doing a malloc
05:13:55  <kellabyte>uv_write_t* write_req = (uv_write_t *)malloc(sizeof(*write_req));
05:14:10  <DrPizza>don't cast the return value of malloc
05:14:21  <DrPizza>but the reason that malloc is failing is that there is previous heap corruption
05:14:31  <DrPizza>but it only checks the heap's integrity when you call malloc or free
05:14:52  <kellabyte>DrPizza: won't compile in VS if I don't, works fine without uv_work_queue(), only exceptions when I use uv_work_queue()
05:15:02  <kellabyte>ah, I didn't know thats how the integrity check worked, cool
05:15:11  * mikealquit (Quit: Leaving.)
05:16:14  <kellabyte>what kinds of things cause heap corruption?
05:18:47  <kellabyte>is this indicating I'm doing a free where I shouldn't be?
05:23:17  <DrPizza>it will compile
05:23:21  <DrPizza>if you include the right header
05:23:25  <DrPizza>that's why you shouldn't cast the return value
05:23:40  <DrPizza>because it masks the problem
05:23:44  <DrPizza>(and can result in pointer truncation)
05:26:10  <kellabyte>DrPizza: interesting, it does compile but intellisense still complains and puts a red line under it
05:26:19  <DrPizza>intellisense only understands C++
05:27:24  * mikealjoined
05:28:23  <kellabyte>DrPizza: ah! I didn't know that :)
05:30:08  <kellabyte>ok another assertion is happening in libuv, so I'm doing something bad
05:30:23  <kellabyte>its 1:30am so back at it tomorrow, thanks for the help :) night!
05:33:16  * dominictarrquit (Ping timeout: 252 seconds)
05:34:09  * bajtosjoined
05:39:22  * octetcloudjoined
05:54:51  * mikealquit (Quit: Leaving.)
05:58:46  * mikealjoined
06:05:25  * dominictarrjoined
06:07:08  * timoxleyjoined
06:08:41  * octetcloudquit (Ping timeout: 256 seconds)
06:12:29  * pquernaquit (Remote host closed the connection)
06:12:30  * rphillipsquit (Quit: ZNC - http://znc.in)
06:17:18  * rphillipsjoined
06:20:03  * rphillipsquit (Client Quit)
06:29:53  * rphillipsjoined
06:31:48  * kazuponquit (Remote host closed the connection)
06:34:51  * rendarjoined
06:36:31  * stagasjoined
06:42:36  * dpemmonsquit (Ping timeout: 272 seconds)
06:42:54  * kazuponjoined
06:43:20  * dpemmonsjoined
06:43:52  * dominictarrquit (Quit: dominictarr)
06:46:04  * timoxleyquit (Quit: Computer has gone to sleep.)
06:57:35  * stolsmajoined
07:07:30  * wolfeidauquit (Remote host closed the connection)
07:44:49  * bnoordhuisjoined
07:58:29  * benoitcquit (Excess Flood)
08:08:48  * benoitcjoined
08:09:33  * bajtosquit (Read error: Operation timed out)
08:09:47  * bajtosjoined
08:22:12  * bajtosquit (Quit: Nettalk6 - www.ntalk.de)
08:25:54  <bnoordhuis>indutny: ping
08:26:32  * dominictarrjoined
08:54:59  * dominictarrquit (Quit: dominictarr)
08:55:50  * stagasquit (Ping timeout: 256 seconds)
08:56:13  * stagasjoined
09:06:39  * stagasquit (Ping timeout: 252 seconds)
09:07:13  * stagasjoined
09:24:06  * dominictarrjoined
09:36:22  * hzjoined
10:05:25  * piscisaureus_joined
10:05:32  * dominictarrquit (Quit: dominictarr)
10:18:09  <piscisaureus_>good afternoon
10:22:55  * stagas_joined
10:36:07  <bnoordhuis>piscisaureus_: sup bertje?
10:36:21  <piscisaureus_>bnoordhuis: nothing. Just thought I'd say hi :)
10:50:10  * dominictarrjoined
11:03:48  * bnoordhuisquit (Ping timeout: 264 seconds)
11:08:16  * piscisaureus_quit (Ping timeout: 246 seconds)
11:22:16  * kazuponquit (Remote host closed the connection)
11:27:44  * piscisaureus_joined
11:32:30  * rjequit (Ping timeout: 264 seconds)
11:33:14  * rjejoined
11:41:42  * stagas_quit (Ping timeout: 245 seconds)
12:09:43  * bnoordhuisjoined
12:14:17  * bnoordhuisquit (Ping timeout: 255 seconds)
12:15:11  * abraxasquit (Remote host closed the connection)
12:19:16  * wolfeidaujoined
12:44:39  <indutny>bnoordhuis: pong
12:49:55  * AvianFluquit
12:56:05  * piscisaureus_quit (Ping timeout: 248 seconds)
13:19:41  * piscisaureus_joined
13:24:15  * mmalecki[zzz]changed nick to mmalecki
13:25:15  * kevinswiberjoined
13:34:54  * bnoordhuisjoined
13:38:38  <bnoordhuis>indutny: sup?
13:39:03  <indutny>idk
13:39:10  <indutny>everything is ok
13:39:12  <indutny>you pang me
13:39:22  <indutny>like 5 hours ago
13:39:28  <bnoordhuis>indeed, i pung you
13:39:40  <bnoordhuis>it's about the openssl thing
13:39:52  <indutny>please continue :)
13:39:55  <bnoordhuis>i cc'ed you on a gist i created
13:40:08  <bnoordhuis>tl;dr it's not node, it's openssl
13:40:34  <bnoordhuis>when i disable sni, i can talk to user-service.condenast.com, else it hangs
13:40:44  <bnoordhuis>but with openssl 1.0.0f it Just Works(TM)
13:40:44  <indutny>yes!
13:40:45  <indutny>I knew it
13:40:49  <indutny>ok, I can figure it out
13:40:52  <indutny>where is the gist?
13:40:57  <indutny>I haven't received anything
13:41:05  <bnoordhuis>https://gist.github.com/bnoordhuis/deb34f193e349615a0c1
13:41:22  <indutny>ok
13:42:07  * defunctzombie_zzchanged nick to defunctzombie
13:45:03  * c4milojoined
13:50:48  <mbroadst>hey I was poking around here last night trying to find out if anyone knew why core node modules weren't implemented as v8::Extensions, any takers?
13:51:27  * kevinswiberquit (Remote host closed the connection)
13:51:34  <bnoordhuis>mbroadst: why should they be?
13:52:08  <indutny>wait
13:52:12  <indutny>there's some shit happening there
13:52:18  <indutny>I'll gist it in a couple of minutes
13:52:48  <indutny>ah
13:52:49  <indutny>no
13:52:49  <indutny>its ok
13:53:04  <mbroadst>bnoordhuis: as far as my reading it seemed to be the "right way" to natively extend the context, I'm trying to figure out if I'm completely wrong about that
13:53:05  <bnoordhuis>"some shit" - i like your precise choice of words, fedor :)
13:54:01  <bnoordhuis>mbroadst: what is your definition of a module? maybe we're talking about two different things
13:55:42  <mbroadst>bnoordhuis: like "os" for instance
13:56:27  <bnoordhuis>mbroadst: that module is part js, part native code
13:56:33  <bnoordhuis>as are most things in node
13:57:19  <mbroadst>bnoordhuis: right, and the v8::Extension ctor requires a name variable, as well as js code to integrate the native code
13:58:14  <mbroadst>I guess I'm just trying to figure out if a) this didn't exist when node was first written, or b) there is some huge oversight I'm making in terms of something like performance going with this approach
13:59:42  <bnoordhuis>mbroadst: i don't think it did
14:00:13  <bnoordhuis>also, the extensions system is arguably not as flexible as the current module+bindings approach
14:00:52  <mbroadst>ah, how so?
14:01:45  * kevinswiberjoined
14:02:49  <indutny>https://gist.github.com/indutny/51bcf9a7f7b1851052a1
14:02:57  <indutny>spot the difference
14:03:05  <indutny>hint: only ciphersuite
14:03:12  * wavdedjoined
14:03:21  <indutny>and elliptic curves
14:03:22  <indutny>but meh
14:03:25  <indutny>I don't think it matters
14:04:39  <indutny>err
14:04:44  <indutny>except that I missed namings
14:04:47  <indutny>first one is working
14:04:49  <indutny>and last isn't
14:05:01  <wavded>would you guys expect a exceeding of file descriptors for a node process to lock the process at 100% (linux/ubuntu server), this happened yesterday for us and after we found out the issue it made me wonder if any safeguards should be put in place (running node 0.10.5)
14:05:11  <wavded>100% CPU that is
14:05:57  <bnoordhuis>mbroadst: i'm not 100% sure about this but one limitation iirc is that you can only export functions, not variables
14:06:34  <bnoordhuis>well, unless you start getting creative with snprintf()
14:07:05  <bnoordhuis>maybe i should reword that as 'i never found a good way to do that' :)
14:08:26  <bnoordhuis>indutny: hrm, maybe it's choking on 1.[12] ciphers. that sounds plausible (and easy to test)
14:08:27  <indutny>yep
14:08:29  <indutny>that's ciphers
14:08:34  <indutny>I've verified
14:08:47  <indutny>now lets figure out what particular ciphers is responsible for it
14:08:57  <indutny>s/is/are/
14:09:22  <indutny>is there any option to disable latest ciphers?
14:09:27  <indutny>just curious
14:09:33  <indutny>like NO_TLS12?
14:09:38  <indutny>or something like that
14:09:46  <bnoordhuis>wavded: SSL_OP_NO_TLSv1_2
14:09:50  <bnoordhuis>and 1_1
14:09:55  <indutny>ok, and it works?
14:09:57  <bnoordhuis>but that didn't work for me
14:09:59  <bnoordhuis>so no :)
14:10:07  <bnoordhuis>SSL_OP_NO_TLSv1 works
14:10:12  <indutny>ok
14:10:12  <bnoordhuis>but that's a bit drastic
14:10:14  <indutny>yep
14:10:15  <indutny>so
14:10:16  <indutny>https://gist.github.com/indutny/60a794ff91e293bf1119
14:10:17  <indutny>here is proof
14:10:26  <indutny>handshake1 is patched handshake2 with old ciphers
14:10:30  <indutny>try switching them and running
14:11:35  <wavded>bnoordhuis: you'll have to explain more or point me somewhere, i'm not sure what you are asking (ref: SSL_OP_NO_TLS)
14:12:06  <bnoordhuis>wavded: oh sorry, that was for indutny
14:12:18  <wavded>bnoordhuis: oh haha
14:12:39  <bnoordhuis>wavded: re your question, there are some failsafes in place but they're not perfect
14:13:01  <piscisaureus_>what is our current policy towards throwing from the binding layer?
14:13:08  <bnoordhuis>piscisaureus_: verboten
14:13:15  <bnoordhuis>in new code, at least
14:13:34  <piscisaureus_>bnoordhuis: I'm looking at:
14:13:34  <piscisaureus_> return ThrowException(Exception::RangeError(String::New("options->gid is out of range")));
14:13:43  <piscisaureus_>which I have to move around/duplicate for spawnSync
14:14:17  <bnoordhuis>it's not a strict policy but throwing from js is preferred
14:14:18  <piscisaureus_>bnoordhuis: you would suggest to setting errno to EINVAL in the binding layer?
14:14:24  <bnoordhuis>yep
14:14:29  <bnoordhuis>or return an exception object
14:14:50  <bnoordhuis>but errno is better
14:15:43  <piscisaureus_>I wish there was a good way for this
14:15:55  <piscisaureus_>one that is consistent and convenient
14:16:27  <bnoordhuis>indutny: ciphers: 'RC4:HIGH:!MD5:!aNULL:!EDH' <- fixes it :/
14:16:36  <indutny>so
14:16:39  <indutny>no elliptic stuff?
14:16:49  <bnoordhuis>nope, just plain tls 1.0 ciphers
14:16:51  <indutny>ah
14:16:57  <indutny>great
14:16:59  <indutny>I told you
14:17:08  <indutny>may be we can just recommend it to users?
14:17:12  * kazuponjoined
14:17:14  <indutny>because their cases are really specific
14:17:22  <bnoordhuis>yeah...
14:17:38  <bnoordhuis>i guess the bottom line is that we're dealing with a buggy tls server here
14:17:54  <bnoordhuis>conde nast owes us >:-(
14:20:09  * kenperkinsquit (Quit: Textual IRC Client: http://www.textualapp.com/)
14:20:37  <bnoordhuis>okay, i'm reverting the downgrade
14:20:55  <indutny>great
14:20:59  <indutny>I've stubbed some test code
14:21:05  <indutny>will try to figure out which particular cipher is causing it
14:21:10  <bnoordhuis>nice
14:26:17  * stagasquit (Quit: ChatZilla 0.9.90-rdmsoft [XULRunner 1.9.0.17/2009122204])
14:30:09  * mikealquit (Quit: Leaving.)
14:30:18  * loladirojoined
14:30:23  <indutny>0044
14:30:28  <indutny>its seems that it is it
14:30:41  <bnoordhuis>is that hex or octal? :)
14:30:49  <indutny>ah no
14:30:51  <indutny>hex
14:31:05  <indutny>0096
14:31:07  <indutny>and 00041
14:31:09  <indutny>err
14:31:09  <indutny>0041
14:31:11  <indutny>all hex
14:31:16  <indutny>without them it seems to be working
14:31:47  <indutny>so
14:31:47  <indutny>TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
14:31:53  <indutny>TLS_RSA_WITH_SEED_CBC_SHA
14:31:57  <bnoordhuis>indutny: ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH
14:31:59  <indutny>and TLS_DH_RSA_WITH_ARIA_256_CBC_SHA384
14:32:03  <bnoordhuis>that's the default cipher list right now
14:32:26  <indutny>hm...
14:32:32  <piscisaureus_>bnoordhuis: any objections to exposing some form of uv_err_new ?
14:32:34  <indutny>and?
14:32:38  <indutny>what are you trying to say?
14:32:49  <piscisaureus_>bnoordhuis: or rather, uv_new_artificial_error
14:32:50  <bnoordhuis>hm, i thought we didn't compile in camellia?
14:33:16  <indutny>interesting thing is that they doesn't play well with other cipher suites
14:33:17  <indutny>I mean
14:33:24  <indutny>if I'll take cipher list from working tls connection
14:33:25  <bnoordhuis>indutny: oh, that it should be one of those ciphers that conde nast finds offensive
14:33:28  <piscisaureus_>camellia isn't in there
14:33:38  <piscisaureus_>atleast, I thought I removed it :)
14:33:42  <bnoordhuis>yeah
14:33:44  <indutny>and add them one by one
14:33:45  <indutny>it fails
14:33:45  <bnoordhuis>neither is seed
14:33:47  <indutny>but if I'll use
14:33:49  <indutny>cs + cipher1
14:33:51  <indutny>cs + cipher2
14:33:52  <indutny>and etc
14:33:54  <indutny>it'll work
14:33:59  <indutny>so its a combination of ciphers
14:34:43  <bnoordhuis>err
14:34:49  <bnoordhuis>when i pass in 'ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH', it works
14:35:04  <bnoordhuis>hrm
14:35:11  <indutny>hehe
14:35:13  <bnoordhuis>does that mean we're advertising ciphers we don't support
14:35:19  <indutny>no
14:35:24  <indutny>server isn't replying
14:35:25  <bnoordhuis>and then have the remote end trip up when it tries to use them?
14:35:36  <indutny>so server don't know them
14:35:41  <indutny>and for some reason not ignoring them
14:35:47  <indutny>probably, because its badly written
14:36:08  <indutny>anyway
14:36:12  <indutny>removing 004100430044
14:36:14  <indutny>helps too
14:36:15  <indutny>so
14:36:17  <bnoordhuis>okay but i want to get this right. i'm blaming conde nast in the commit log :)
14:36:19  <indutny>I'm not sure what to think
14:36:20  * kevinswiberquit (Remote host closed the connection)
14:36:25  <indutny>oh
14:36:27  <indutny>I have an idea
14:36:46  <indutny>hahahaha
14:36:47  <indutny>yes
14:36:48  <indutny>that's it
14:36:51  <indutny>oh my god
14:36:59  <indutny>it just doesn't work with long ciphersuite list
14:37:05  <indutny>if I'll remove any 3 ciphers - it'll work
14:37:08  <piscisaureus_>hahahaha
14:37:09  <kellabyte>looking for some guidance, I'm getting: Assertion failed: ((handle))->activecnt >= 0, file src\win\tcp.c, line 1038 when I try to uv_write(), without uv_work_queue() it works, with it I get that, any hints on what I'm probably not handling correctly? :)
14:37:14  <bnoordhuis>hah, really?
14:37:16  <indutny>yes
14:37:18  <bnoordhuis>what the hell?
14:37:21  <indutny>wanna see the code?
14:37:26  <indutny>bnoordhuis: lets hack it :)
14:37:29  <bnoordhuis>yes please
14:37:31  <indutny>I believe there is some stack overflow
14:37:49  <indutny>https://gist.github.com/indutny/54f429ea658643e1cbc3
14:38:00  <bnoordhuis>kellabyte: are you calling uv_write() from inside your work cb? don't do that
14:38:07  <piscisaureus_>kellabyte: you can't call uv_write from a "foreign" thread, and uv_queue_work enqueues something to the thread pool
14:38:15  <piscisaureus_>kellabyte: so in short, you can't mix those
14:38:26  <indutny>wait
14:38:28  <indutny>let me modify it
14:38:57  <indutny>ok, here it comes https://gist.github.com/indutny/54f429ea658643e1cbc3
14:38:58  * kevinswiberjoined
14:39:02  <indutny>on line https://gist.github.com/indutny/54f429ea658643e1cbc3#file-test-js-L57
14:39:07  <indutny>replace .length with .length - 3
14:39:11  <indutny>and it'll work in all cases
14:39:16  <indutny>note that cipher list is almost randomized
14:39:18  <indutny>I mean
14:39:26  <indutny>order is changed on every run
14:39:41  <indutny>god
14:39:42  <bnoordhuis>hah, what did you use async for?
14:39:43  <indutny>that's really fun
14:39:48  <indutny>bnoordhuis: I was using it
14:39:50  <indutny>you can remove it
14:40:07  <indutny>updated gist
14:40:53  <bnoordhuis>cool
14:40:53  * pquernajoined
14:40:54  * pquernaquit (Changing host)
14:40:54  * pquernajoined
14:40:55  <indutny>so it seems like they're allocating 64 bytes for ciphersuite+len
14:41:06  <indutny>because noone will ever exceed it
14:41:35  <kellabyte>piscisaureus_: ah, hrm. so how do I handle dispatching to handlers, getting a response, then writing the response back with uv_write()?
14:41:38  <indutny>or idk
14:41:47  <indutny>probably they allocate space for whole handshake
14:41:47  <bnoordhuis>sounds plausible
14:41:51  <bnoordhuis>and hilariously awful
14:41:55  <indutny>because disabling extensions works too
14:41:56  <indutny>right?
14:42:05  <kellabyte>piscisaureus_: I'm dispatching via the thread pool
14:42:06  <bnoordhuis>yeah
14:42:12  <indutny>ok, so...
14:42:12  <bnoordhuis>it worked as soon as i disabled sni
14:42:16  <indutny>ok
14:42:34  <indutny>so what can we do about it :)
14:42:45  <indutny>disable server name
14:42:50  <bnoordhuis>nothing. i believe tjfontaine knows one or two people at conde nast
14:42:51  <indutny>disable sessions
14:42:55  <bnoordhuis>let them fix their crap
14:42:59  <indutny>ah
14:43:01  <indutny>great
14:43:02  <indutny>meanwhile
14:43:05  <indutny>lets hack them
14:43:06  <indutny>:)
14:43:15  <indutny>considering that it isn't replying back to us
14:43:19  <bnoordhuis>hah, spoken as a true russian
14:43:20  <indutny>some overflow is happening there
14:43:41  <indutny>just kidding
14:43:45  <indutny>I love my work and family
14:43:56  <indutny>no need in illegal activities
14:44:05  <bnoordhuis>unless they're hugely profitable
14:44:20  <bnoordhuis>okay, i'm pushing the undowngrade
14:44:21  <indutny>bnoordhuis: can you please revert downgrade then?
14:44:23  <indutny>yeah
14:44:24  <indutny>great
14:44:39  * indutnygoes back to his erlang jit compiler
14:44:41  <piscisaureus_>bnoordhuis: was it only conde nast that was seeing these problems?
14:44:58  <indutny>what's conde nast?
14:45:12  <indutny>http://www.condenast.com/ ?
14:45:59  <piscisaureus_>kellabyte: well, eh, hard question... You probably want to pass the handler "response" back to the main thread and send from there
14:46:36  <piscisaureus_>kellabyte: I guess if you want to build a proper multithreaded http server you'll need to use multiple threads with their own event loop
14:47:17  <bnoordhuis>indutny: yep
14:47:24  <MI6>joyent/node: Ben Noordhuis v0.10 * 2cf7e5d : Revert "deps: downgrade openssl to v1.0.0f" - http://git.io/KAUS1A
14:47:32  <indutny>is it like your clients?
14:47:38  <bnoordhuis>no
14:47:39  * indutnyjust don't get why do we care that much
14:47:43  <bnoordhuis>you already asked that yesterday :)
14:48:05  <bnoordhuis>they were just a particular good example of the connection issues people were reporting
14:48:10  <piscisaureus_>good work btw indutny
14:48:19  <bnoordhuis>yep, well done
14:48:22  <indutny>thanks
14:48:39  <piscisaureus_>actually which issue is this?
14:49:05  <bnoordhuis>oh, only the openssl upgrade/downgrade issue everyone was worked up about
14:49:13  <wavded>bnoordhuis: it would be nice if we had a process.lsof or something to report how many file descriptors are in use, i see there is lsof module but it basically does a cp.exec
14:49:29  <indutny>wavded: why should we do it?
14:49:33  <indutny>there is lsof
14:49:36  <indutny>and a lof other utilities
14:49:40  <bnoordhuis>wavded: what's stopping you from writing a module?
14:49:46  <kellabyte>piscisaureus_: that was my original idea, but whats different between writing a response on another uv_loop and trying to write a response on the thread pool thread? both are different threads than the thread that the original uv_loop that received the on_connect happened?
14:50:17  <wavded>bnoordhuis: well we have memory usage, you'd recommend cp.exec every time you wanted to see how many are using (if reporting metrics)?
14:50:39  <bnoordhuis>wavded: sorry, what i mean is: why should it be in core?
14:50:45  <wavded>bnoordhuis: a module has been written - node-lsof
14:50:53  <piscisaureus_>kellabyte: libuv doesn't do any internal locking. So if you uv_write from another thread libuv's internal bookkeeping gets messed up by concurrent updates.
14:51:34  <bnoordhuis>wavded: our policy is to push everything into modules unless core is the only place where you reasonably implement it
14:51:35  <kellabyte>piscisaureus_: so how do I accept connections on the main uv_loop but pass it to other uv_loops?
14:51:50  <kellabyte>piscisaureus_: I don't want to open like 4 different ports
14:51:52  <piscisaureus_>kellabyte: ehm, that's hard :)
14:52:01  <piscisaureus_>kellabyte: you create an ipc pipe between the loops
14:52:02  <wavded>bnoordhuis: right, i know we want to keep core small, i was just thinking about how we provide node.memoryUsage() in core, since node is so I/O intensive, having an easy tap on your open FD would be nice
14:52:12  <piscisaureus_>kellabyte: and you can uv_write2 socket objects over it
14:52:24  <wavded>cp. exec to do that seems expensive, but that is just me
14:52:31  <piscisaureus_>kellabyte: note however that this model currently doesn't do very well in performance terms on windows ...
14:52:58  <bnoordhuis>wavded: memoryUsage() is an artifact from our younger, wilder days when we didn't know any better
14:52:58  <piscisaureus_>kellabyte: something that is bound to change because node is moving to this strategy too (although it'll transfer sockets between processes and not loops)
14:53:12  <kellabyte>piscisaureus_: ok.. let me propose an in between way, and see what you think
14:53:13  <piscisaureus_>(which is also the reason you have to deal with such a complicated api for transferring sockets)
14:53:16  <bnoordhuis>wavded: i'd happily kill it off if it weren't for backwards compatibility
14:53:21  <piscisaureus_>kellabyte: good
14:53:50  <bnoordhuis>piscisaureus_: that reminds me, maybe we should bring back uv_import() and uv_export()
14:54:00  <bnoordhuis>sharing handles between loops is a royal pita right now
14:54:11  <piscisaureus_>bnoordhuis: yeah, you're right
14:55:02  <kellabyte>piscisaureus_: I'm reading and writing at a fast pace, I'm more worried the consumers of the requests will do silly things in the handlers, so I can dispatch the req struct to them, get the response bytes, then write it using the main uv_loop
14:55:24  <kellabyte>piscisaureus_: so I'm in the uv_worker_queue() thread, how do I then write on the main uv_loop thread?
14:55:56  <wavded>bnoordhuis: so would you recommend cp. exec or doing some binding to pull for that?
14:56:04  <bnoordhuis>wavded: a binding
14:56:06  <piscisaureus_>bnoordhuis: or maybe we could have some sort of 'uv_async' like functionality which implements a proper queue and allows passing of handles and pointers
14:56:49  <piscisaureus_>kellabyte: somehow store the data you want to write inside the uv_work_t struct or on the heap
14:56:59  <piscisaureus_>kellabyte: then do the write in the after_cb ?
14:57:19  <kellabyte>piscisaureus_: ah, the after_cb is on the uv_loop thread?
14:57:26  <piscisaureus_>kellabyte: yep
14:57:27  <kellabyte>ah!
14:58:20  <kellabyte>piscisaureus_: ok I'll try that, thank you :) I think I'd still love fully threaded but maybe that gets easier later on, I think this may be good enough for now
14:58:43  <piscisaureus_>kellabyte: yeah, we also need to make that a bit easier
14:58:51  <kellabyte>piscisaureus_: that would rock :)
14:59:05  <piscisaureus_>bnoordhuis: so, thoughts on exposing uv_new_artificial_error ?
14:59:19  <piscisaureus_>bnoordhuis: uv_err_init would be better imo btw
14:59:48  <bnoordhuis>piscisaureus_: why?
14:59:57  * loladiroquit (Quit: loladiro)
15:00:06  <piscisaureus_>bnoordhuis: well I need to return uv_err_t objects from a function in the node binding layer
15:01:54  <bnoordhuis>piscisaureus_: why's that?
15:03:46  <bnoordhuis>off to pick up mees, biab
15:04:47  * kesslerjoined
15:05:30  * mcavagejoined
15:05:36  * mcavagequit (Remote host closed the connection)
15:05:44  * mcavagejoined
15:06:23  <rendar>what is the purpose of uv_write2? is that an undocumented function?
15:07:57  * bnoordhuisquit (Ping timeout: 245 seconds)
15:08:58  <kessler>hi guys, wanted to ask if the problem with node cluster on linux where one process is favoured over others happens in windows as well
15:10:09  <rendar>kellabyte: btw, why you want to accept connections in an uv_loop and manage read/writes in another uv_loop?
15:15:31  * kazuponquit (Remote host closed the connection)
15:15:41  <kellabyte>rendar: I don't want to open multiple HTTP ports, but I need to dispatch to request handlers, but with the new approach I'm going to dispatch but but still write on the uv_loop for now
15:15:57  * rphillipsquit (Quit: ZNC - http://znc.in)
15:15:57  * pquernaquit (Read error: Connection reset by peer)
15:19:29  <rendar>kellabyte: hmmm
15:19:43  <piscisaureus_>#%%$ who decided that uv_process_options_t.file has to be const :(
15:21:29  <MI6>nodejs-v0.10: #168 UNSTABLE windows-ia32 (7/581) windows-x64 (8/581) smartos-x64 (2/581) http://jenkins.nodejs.org/job/nodejs-v0.10/168/
15:21:43  * kesslerquit (Ping timeout: 245 seconds)
15:21:45  * rphillipsjoined
15:21:46  * pquernajoined
15:21:47  * pquernaquit (Changing host)
15:21:47  * pquernajoined
15:23:11  <rendar>kellabyte: what about using one unique uv_loop which both accepts connections and dispatch to request handlers? what is the new approach?
15:26:02  <kellabyte>rendar: it sounds like handing off handles from one uv_loop to another is not so simple right now
15:26:17  <rendar>yeah, exactly
15:27:16  <rendar>but i still can't understand what is the purpose of moving off handles from uv_loop to another instead of using 1 unique uv_loop :) i guess that 1 uv_loop can manage all the stuff..
15:28:22  <kellabyte>well I can dispatch using the worker queue to handlers, populate the struct with the response, then in the callback write using the main uv_loop
15:28:32  <rendar>hmm
15:29:56  <rendar>ok, i got it!
15:30:46  <kellabyte>:)
15:41:07  * mikealjoined
15:41:33  * dapjoined
15:45:01  * loladirojoined
15:46:56  <piscisaureus_>indutny: isaacs: you are the http experts right? :)
15:47:36  <piscisaureus_>res.writeHead(200, {'Content-Type': 'text/plain', 'Transfer-Encoding': 'chunked'});
15:47:36  <piscisaureus_> res.end('Hello World\n');
15:47:50  <piscisaureus_>^-- If I do that ab complains that responses have length errors
15:48:11  <piscisaureus_>Without the transfer-encoding header the server doesn't do keepalive
15:48:22  <piscisaureus_>What am I doing wrong?
15:50:15  * mikealquit (Quit: Leaving.)
15:53:46  <piscisaureus_>--- ahh nevermind scratch that ---
15:56:53  <isaacs>piscisaureus_: figured it out?
15:57:07  <piscisaureus_>isaacs: yeah, it was ab that expects all responses to be the same length
15:57:28  <isaacs>piscisaureus_: wtf?
15:57:36  <isaacs>god, ab is such a shit show
15:57:46  <piscisaureus_>I should probably migrate to wrk :-p
15:57:49  <isaacs>yes
15:57:50  <isaacs>you should
15:57:57  <isaacs>does wrk work on windows at all?
15:58:10  <piscisaureus_>no
15:58:11  <isaacs>it'd be nice to run our benchmarks there
15:58:14  <isaacs>yeah, that's expected
15:58:20  <isaacs>we should migrate it to libuv :)
15:58:29  * loladiroquit (Quit: loladiro)
15:58:40  <isaacs>of course, if we use libuv+http_parser to benchmark node, then, well... that's kind of verging on invalid self-testing
15:58:47  <isaacs>may as well just use Node to test Node at that point
15:59:18  <isaacs>i guess it's fine if we accept that we're really only testing the V8/JS bits
15:59:26  <piscisaureus_>isaacs: yeah you're right although I think we could write a benchmarking tool with uv + http_parser that's much better than ab :)
15:59:52  <piscisaureus_>s/then/than/
16:00:06  <isaacs>ew could write a benchmarking tool with toothpicks and chewing gum that's much better than ab
16:01:32  <piscisaureus_>I have to make the run home
16:01:35  <piscisaureus_>bbiab
16:04:19  <tjfontaine>indutny: so was it SNI or a cipher list to blame?
16:04:41  * wavdedquit (Quit: Nighty night)
16:04:41  * wavdedquit (Quit: Nighty night)
16:05:13  * timoxleyjoined
16:06:48  * piscisaureus_quit (Ping timeout: 245 seconds)
16:06:58  * defunctzombiechanged nick to defunctzombie_zz
16:08:38  * mikealjoined
16:09:09  * TooTallNatejoined
16:10:34  * mikealquit (Client Quit)
16:10:49  * octetcloudjoined
16:12:18  * loladirojoined
16:13:43  * defunctzombie_zzchanged nick to defunctzombie
16:14:13  * bnoordhuisjoined
16:15:32  <isaacs>indutny, bnoordhuis: I see you reverted the openssl downgrade, but i dont' see a fix for the condenast thing... is that coming? did you guys figure out what it was?
16:16:15  <tjfontaine>from reading the backlog it appears to be broken-software/misconfiguration for them, not sure if it's soley SNI or a broken cipher list
16:19:09  <trevnorris>morning
16:19:16  <tjfontaine>morn
16:20:15  * stagasjoined
16:20:36  <TooTallNate>mo
16:24:52  <bnoordhuis>isaacs: what tjfontaine said
16:25:20  <tjfontaine>bnoordhuis: so both tweaking the cipher list and disabling sni solve it for them?
16:25:20  * st_lukejoined
16:25:42  * loladiroquit (Quit: loladiro)
16:25:45  <bnoordhuis>tjfontaine: yeah. our current working hypothesis is that it uses a fixed-size buffer for processing tls handshakes
16:26:03  <bnoordhuis>if the handshake frame is bigger, it hangs
16:26:06  <tjfontaine>sounds reasonable, or they have a firewall rule on first packet being too large
16:26:12  * kazuponjoined
16:26:17  <bnoordhuis>yep, something like that
16:26:47  <tjfontaine>isaacs: your scrum is all set?
16:26:59  <isaacs>tjfontaine: yep
16:27:19  <tjfontaine>bnoordhuis: when I get response back from the conde nast folk I'll give them the updated information
16:27:21  <tjfontaine>isaacs: thanks
16:29:29  * timoxleyquit (Quit: Computer has gone to sleep.)
16:30:48  * kazuponquit (Ping timeout: 264 seconds)
16:30:49  <isaacs>bnoordhuis, tjfontaine: So, any further action on our part? do we need to sniff for tls 1.2 being disabled, and also disable sni or something?
16:32:37  <tjfontaine>isaacs: there's nothing we can do on this issue, it's totally the other ends fault, openssl is behaving fine, and at least our tls throws a RESET
16:35:56  * inolenquit (Quit: Leaving.)
16:41:03  <isaacs>kie dokie
16:42:53  <isaacs>sounds good
16:43:19  <tjfontaine>we could try our best to limit our handhsake size
16:43:32  <isaacs>so, sounds like i'm unblocked, i'll drop a 0.10 and then get to work on the crypto hash perf stuff.
16:43:48  <tjfontaine>excellent
16:44:05  <isaacs>the thing that sucks is that it'll still be gros if you're using buffers, but meh. maybe trevnorris and piscisaureus can fix that in 0.12 or 1.0 :)
16:44:42  <isaacs>actually... now that i look at it.. there's really not much here to release for.
16:45:20  * TooTallNatequit (Quit: Computer has gone to sleep.)
16:45:21  <isaacs>just documentation and a single debugger fix. i'd thought that the openssl change would require some more work for us to do.
16:45:48  <isaacs>gonna kick 0.10.5 down the road a bit further, get right to crypto stuff
16:46:10  <tjfontaine>yup, that would be a nice headline to have for the next release
16:46:34  <trevnorris>buffer what?
16:48:12  * loladirojoined
16:48:24  * kevinswiberquit (Remote host closed the connection)
16:49:13  <tjfontaine>trevnorris: buffer all the things
16:51:35  * kevinswiberjoined
16:51:42  * amartensjoined
16:55:14  * inolenjoined
16:56:54  * inolenquit (Client Quit)
16:57:12  * mikealjoined
17:00:36  * trevnorrisstarts to buffer allz da thingz
17:01:06  <trevnorris>just didn't follow what would still be gross to buffer.
17:01:36  <tjfontaine>he's not saying it'll be gross to buffer, but the usage of the hash perf fixes will be slightly uglier if you want to use buffers
17:03:33  * TooTallNatejoined
17:03:55  <trevnorris>ah, ok. hm. if we were to know the user wanted a string back then it'd be easy to get around the buffer perf hit.
17:05:44  * piscisaureus_joined
17:08:39  <trevnorris>TooTallNate: so I've figured out a way around the if instanceof check in Buffer, but it involves using __proto__
17:10:50  <bnoordhuis>trevnorris: what instanceof check?
17:11:17  <trevnorris>bnoordhuis: top of function Buffer there's an "if (!(this instanceof Buffer)) return new Buffer(...)"
17:11:38  <trevnorris>necessary if you always want to return a new Buffer, even if the user doesn't use the "new" keyword
17:11:50  <bnoordhuis>yes
17:12:06  <bnoordhuis>is there a problem with that?
17:12:23  <trevnorris>which, using __proto__ or the instanceof check?
17:12:35  * kevinswiberquit (Remote host closed the connection)
17:12:36  <bnoordhuis>both
17:12:56  <trevnorris>it was more academic conversation than anything.
17:13:10  <bnoordhuis>ah okay
17:13:32  * st_lukequit (Remote host closed the connection)
17:13:33  * qardjoined
17:14:42  <trevnorris>bnoordhuis: oh sure you saw v8 released fix for the bug you mentioned. upgrade node, or no hurry?
17:15:43  <tjfontaine>is there an existing type (that's not buffers) with an internal field count of >= 1 I can hijack?
17:16:39  <trevnorris>tjfontaine: well, if you inherit from ObjectWrap then it'll automatically create a new persistent from an object template and throw in the class instance.
17:16:52  <tjfontaine>I explicitly do not want to inherit objectwrap :)
17:16:56  <trevnorris>lol.
17:17:00  <trevnorris>what are you trying to do?
17:17:18  <tjfontaine>I wanted to do a quick mock up to test my persistent pool idea
17:19:33  <trevnorris>tjfontaine: probably just easiest to create a new persistent ObjectTemplate rather than try to use anything existing.
17:19:54  <tjfontaine>nod
17:32:00  <bnoordhuis>trevnorris: there's no real hurry. it's a bad bug but it's only in 3.18 (i.e. master)
17:32:16  <trevnorris>coolio
17:34:18  * inolen1joined
17:34:38  <tjfontaine>oh 0xbaddeaf how I despise you
17:37:42  <MI6>joyent/libuv: Ben Noordhuis v0.10 * 794d8e0 : unix: fix EMFILE error handling - http://git.io/utWF4Q
17:38:07  <MI6>joyent/libuv: Ben Noordhuis v0.10 * b3ab332 : unix: fix EMFILE error handling - http://git.io/gOHDIQ
17:38:13  <bnoordhuis>^ added bug #
17:39:33  <bnoordhuis>it's kind of weird that child_process.spawn() throws exceptions rather than emit them as errors
17:41:59  <MI6>libuv-v0.10: #48 UNSTABLE windows (5/187) osx (1/187) smartos (3/186) linux (1/186) http://jenkins.nodejs.org/job/libuv-v0.10/48/
17:45:30  <MI6>libuv-v0.10-gyp: #11 UNSTABLE windows-x64 (4/187) linux-ia32 (1/186) smartos-ia32 (3/186) osx-x64 (1/187) smartos-x64 (3/186) linux-x64 (1/186) windows-ia32 (4/187) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/11/
17:46:31  <trevnorris>bnoordhuis: so not that I'd do it any time in the near future, but you be open to writing our own builtins and making them available though a ./configure flag?
17:47:07  <MI6>libuv-v0.10: #49 UNSTABLE windows (6/187) osx (2/187) smartos (3/186) linux (1/186) http://jenkins.nodejs.org/job/libuv-v0.10/49/
17:49:44  <MI6>libuv-node-integration: #38 FAILURE http://jenkins.nodejs.org/job/libuv-node-integration/38/
17:50:28  <tjfontaine>heh, failed by a force push
17:50:39  * mikealquit (Quit: Leaving.)
17:51:12  * rvagg_joined
17:51:36  <MI6>libuv-v0.10-gyp: #12 UNSTABLE windows-x64 (4/187) smartos-ia32 (3/186) osx-x64 (1/187) smartos-x64 (4/186) windows-ia32 (4/187) osx-ia32 (2/187) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/12/
17:52:28  * dominictarrquit (Quit: dominictarr)
17:52:39  * rvaggquit (*.net *.split)
17:52:39  * isaacsquit (*.net *.split)
17:52:39  * rvagg_changed nick to rvagg
17:52:50  * st_lukejoined
17:54:12  * isaacsjoined
17:54:37  * isaacschanged nick to Guest67833
17:54:45  <Guest67833>bnoordhuis: you get that? looks like my irc hiccuped
17:55:32  * dominictarrjoined
17:55:55  * Guest67833changed nick to isaacs
17:57:49  <bnoordhuis>isaacs: get what?
17:58:22  <isaacs>guess not :)
17:58:25  * dominictarrquit (Client Quit)
17:58:42  <isaacs>17:50 <@isaacs> bnoordhuis: re the C++ StringDecoder RIAA class idea..
17:58:42  <isaacs>17:50 <@isaacs> bnoordhuis: I feel a bit funny about having the void* data arg be maybe-not-null and specify how much to write.
17:58:45  <isaacs>17:50 <@isaacs> bnoordhuis: what happens if the amount i want to write to it is too big? then what? the string doesn't get written?
17:58:48  <isaacs>17:52 <@isaacs> bnoordhuis: like, DecodeDataFromString(bigString, UTF8, smallBuffer, 2)
17:58:51  <isaacs>17:52 <@isaacs> er, int len=2;DecodeDataFromString(bigString, UTF8, smallBuffer, &len) rather
17:58:54  <isaacs>17:53 <@isaacs> bnoordhuis: would it make sense to have it just say, "Sorry, that's not big enough, I'm gonna put it in a different place"?
17:59:39  <bnoordhuis>yeah, that's a possibility
18:00:15  <isaacs>i think, first pass, i'm going to do it just for what i need. i can certaily see the value of "put that string here" if you already have the space set up.
18:00:31  <isaacs>but that seems like a potential later optimization.
18:00:42  <isaacs>and if we wrap in a riaa class, we can always do that later without changing anything else.
18:00:52  <bnoordhuis>exactly
18:00:59  <bnoordhuis>only it's raii, not riaa :)
18:01:08  <isaacs>oh, right.
18:01:18  <isaacs>riaa is some macromedia thingie
18:01:20  <isaacs>:)
18:01:47  <isaacs>oh, no, it's the evil recording industry thing
18:01:59  <isaacs>pirate-hunters
18:02:21  <isaacs>k, thanks, should have something kinda workable later today
18:02:28  * loladiroquit (Quit: loladiro)
18:03:45  <isaacs>it's occurring to me that require('string_decoder') is kind of odd. it's actually ENcoding a to a string, not DEcoding from a string
18:04:06  * isaacslobs another complaint back in time to ryah...
18:04:15  <isaacs>not sure why that never seemed strange to me before.
18:05:11  <trevnorris>isaacs: just curious. would it be too much a change to cleanup the naming conventions for the v2 release?
18:05:33  <isaacs>v2 or v12?
18:05:39  <isaacs>ie, 2.0 or 0.12
18:05:49  <trevnorris>v2.0
18:06:00  <isaacs>trevnorris: that's probably fine
18:06:07  <trevnorris>unless you think it could b e done for v0.12. ;-)
18:06:20  <isaacs>trevnorris: we could even do that for 1.0, if we kept backwards compatible shims in place.
18:06:27  <isaacs>but i'd like to stabilize what we have first, probabbly.
18:06:40  <isaacs>we could put a fresh coat of paint on all the bikesheds between 0.12 and 1.0 :)
18:06:46  <tjfontaine>bnoordhuis: template <class S> explicit V8_INLINE(Persistent(Handle<S> that)) : Handle<T>(*that) { } --- do I need to specify the T or just rely on the compiler to do the right thing
18:06:52  <trevnorris>heh, sounds good to me.
18:08:09  <trevnorris>tjfontaine: if I understand what you're trying to do, it would be Persistent<Something> handle(arg);
18:08:35  <tjfontaine>ya, that's what I'm doing, I'm just trying to figure out if that's my problem
18:09:40  <trevnorris>how do you mean your problem? It's just that the <Type> of "arg" must match Persistent<Type>
18:10:12  <trevnorris>so, if you're receiving a Value, but you want an Object. would have to do something like Persistent<Object> handle(arg.As<Object>())
18:10:13  * bnoordhuisquit (Ping timeout: 248 seconds)
18:10:14  <tjfontaine>trevnorris: no my problem is that I'm not returning the object, and making the runtime unhappy
18:10:29  <trevnorris>well, is "arg" already a Persistent?
18:10:33  <tjfontaine>yes
18:11:49  <trevnorris>hm. sorry. not too good at helping w/o code. :)
18:11:51  * loladirojoined
18:12:09  <tjfontaine>I can post it, I'm sure it's probably something simple like my value going out of scope
18:13:23  * brsonjoined
18:16:42  <trevnorris>acupuncture. biab
18:16:44  * trevnorris&
18:16:44  <LOUDBOT>ERNIE VALENTINE WAS A WOMAN THREE DAYS AGO
18:19:49  <indutny>tjfontaine: isaacs : it was bad server
18:20:05  <indutny>ah I see you've already figured it out
18:20:12  <tjfontaine>indutny: ya, thanks
18:20:35  <MI6>libuv-node-integration: #39 UNSTABLE smartos-x64 (1/581) windows-x64 (8/581) windows-ia32 (8/581) linux-ia32 (1/581) http://jenkins.nodejs.org/job/libuv-node-integration/39/
18:22:14  <indutny>you're welcome
18:22:39  <tjfontaine>when the conde nast guys respond I'll inform them of the updated information
18:23:05  <tjfontaine>if this isn't a hardware terminator issue, it may be a firewall rule that they put in place
18:30:37  <isaacs>i'm off to class, but if anyone cares to review: https://gist.github.com/isaacs/5497196
18:37:02  * mikealjoined
18:40:55  <piscisaureus_>isaacs: i can't comment on that file...
18:42:47  <indutny>isaacs: style man
18:42:48  <indutny>style
18:47:08  <isaacs>piscisaureus_: why not?
18:47:18  <isaacs>indutny: do we have a style fixer for c++?
18:47:23  <indutny>fixer?
18:47:25  <piscisaureus_>isaacs: you can't comment on lines in a gist
18:47:26  <isaacs>yeah
18:47:26  <tjfontaine>linter
18:47:29  <indutny>aaah
18:47:30  <isaacs>like make jslintfix
18:47:35  <indutny>nope
18:47:38  <isaacs>piscisaureus_: oh... right.
18:47:45  <isaacs>k, i'll push it in a proper commit when i get back
18:48:03  * kevinswiberjoined
18:53:19  * octetcloudquit (Ping timeout: 264 seconds)
18:57:19  * qardquit (Quit: Leaving.)
18:57:31  * stagasquit (Read error: Connection reset by peer)
18:59:36  * kevinswiberquit (Remote host closed the connection)
19:01:20  * dominictarrjoined
19:01:39  * mikealquit (Quit: Leaving.)
19:02:14  * kevinswiberjoined
19:12:47  * loladiroquit (Quit: loladiro)
19:16:44  * bnoordhuisjoined
19:21:42  * bnoordhuisquit (Ping timeout: 264 seconds)
19:27:48  * defunctzombiechanged nick to defunctzombie_zz
19:37:09  * octetcloudjoined
19:37:39  * mikealjoined
19:42:06  * mikealquit (Ping timeout: 264 seconds)
19:45:31  * kevinswiberquit (Remote host closed the connection)
19:57:51  * trevnorrisfg
19:58:58  <trevnorris>indutny: thought we did, but it was disabled since there are too many errors.
20:00:00  * kevinswiberjoined
20:00:13  * TooTallNatequit (Quit: Computer has gone to sleep.)
20:04:25  * TooTallNatejoined
20:09:58  * defunctzombie_zzchanged nick to defunctzombie
20:11:06  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
20:16:17  * abraxasjoined
20:20:57  * abraxasquit (Ping timeout: 256 seconds)
20:21:02  * mikealjoined
20:29:05  <trevnorris>isaacs: not sure this is what you were talking about, but if you run "make lint" it'll show you all the syntax errors in c++.
20:33:01  * EhevuTovjoined
20:44:05  * rendarquit
20:49:42  * groundwaterjoined
20:53:19  * octetcloudquit (Ping timeout: 264 seconds)
20:54:26  * octetcloudjoined
20:54:45  * timoxleyjoined
20:56:36  * qardjoined
21:05:07  * kevinswiberquit (Remote host closed the connection)
21:06:15  * bnoordhuisjoined
21:07:42  * stolsmaquit (Ping timeout: 256 seconds)
21:13:19  * timoxleyquit (Read error: Connection reset by peer)
21:16:01  <trevnorris>bnoordhuis: to conserve mem, I'm realloc'ing. working fine but valgrind has a hernia about mismatched free/delete.
21:16:05  <trevnorris>anything I can do about that?
21:17:24  * wavdedjoined
21:18:56  <bnoordhuis>trevnorris: use free rather than delete
21:19:47  <trevnorris>bnoordhuis: problem is it's in the make weak callback for allocations. and everything else uses "new"
21:19:48  <tjfontaine>use delete with new, and free with [re|m]alloc
21:20:22  <bnoordhuis>yep. for portability's sake, assume that malloc/free and new/delete use different heaps
21:20:36  <trevnorris>suck.
21:21:45  <trevnorris>it's part of my work to remove the slab allocator: http://git.io/FwDqVA
21:22:12  <trevnorris>almost have performance the exact same as it is now.
21:23:03  <tjfontaine>the amount that github iterates on their UI is frustrating
21:23:29  <trevnorris>heh
21:23:34  <trevnorris>so it's happening on #L3L242
21:23:52  * defunctzombiechanged nick to defunctzombie_zz
21:23:58  <trevnorris>basically it's malloc'ing the 64kB for the request, but don't want to hang on to what's not being used.
21:24:27  <trevnorris>not sure how it'll perform on other OS's but no performance hit on my linux box.
21:28:19  * timoxleyjoined
21:28:47  * wavdedquit (Quit: Hasta la pasta)
21:33:41  <indutny>trevnorris: what?
21:34:18  <trevnorris>indutny: were you and isaacs talking before about a c++ linter?
21:34:29  <indutny>ah, yes
21:34:32  <indutny>we've linter in node
21:34:33  <indutny>actually
21:36:32  * isaacsfg
21:36:47  <isaacs>tjfontaine: fo rreals
21:36:52  <trevnorris>ok, for anyone. architecture Q: created a generic make weak callback that will delete [] memory. want to use realloc, but valigrind hates me for it. so do I create a specialized function set just for this case, or what?
21:36:57  <isaacs>tjfontaine: especially since they're so NOT interating on anything that actually mattes.
21:36:58  <tjfontaine>isaacs: re: github ui?
21:37:00  <isaacs>tjfontaine: yes.
21:37:04  <tjfontaine>yup
21:37:07  <isaacs>tjfontaine: like, I STILL CANT TAG PULL REQS
21:37:11  <isaacs>wtf. srsly
21:37:24  <tjfontaine>but if we make it pretty people will like us!
21:37:32  <isaacs>and if they're gonna make ui changes, how about fixing the back button on issue tabs?
21:37:38  <tjfontaine>github -- like a woman addicted to plastic surgery
21:38:08  <isaacs>i already love github. with all my heart. it breaks my heart to see it do this to itself.
21:38:17  <isaacs>anyway..
21:40:30  <trevnorris>isaacs: so have a branch that's removed the slab allocator. except in a few cases it's running the same speed on net/http benchmarks.
21:42:05  <isaacs>indutny: what style things were you referring to? cpplint complains about a lot of stuff we don't actually follow.
21:43:57  * EhevuTovquit (Quit: This computer has gone to sleep)
21:44:03  <indutny>isaacs: well arguments on next line
21:44:36  <indutny>public first, private later
21:44:54  <indutny>arguments line up
21:45:13  <indutny>if you move any argument to next line - place every argument on next line
21:45:13  <isaacs>indutny: we frequently put the args on the next line when they're a long list, and always just indent another 2 spaces.
21:45:27  <indutny>I meant function declaration
21:45:30  <isaacs>indutny: i'm following the style of stream_wrap.cc and node_buffer.cc
21:45:30  <isaacs>yeah
21:45:40  <indutny>well, then its wrong :)
21:45:42  <indutny>c'mon
21:45:45  * bnoordhuisconcurs
21:45:46  <indutny>we've node_crypto.cc
21:45:53  <indutny>and its not following a lot of stuff too
21:46:00  <isaacs> static void OnReadCommon(uv_stream_t* handle, ssize_t nread,
21:46:00  <isaacs> uv_buf_t buf, uv_handle_type pending);
21:46:12  <indutny>that's a total shit
21:46:37  <isaacs>how would you liek that styled? for bonus points, find me a linter that will enforce it, and i'll enforce it.
21:46:38  <indutny>and I've already fixed it in many places
21:46:56  <indutny>oh god
21:47:03  <indutny>bnoordhuis: want to weigh in?
21:47:07  <bnoordhuis>yeah
21:47:08  <isaacs>the reason why our style is consistent in JS but not in C++
21:47:19  <bnoordhuis>i veto any and all c++ linters
21:47:22  * EhevuTovjoined
21:47:24  <isaacs>is because we have `make jslint` and `make jslintfix` so it always passes and is always linted
21:47:32  <isaacs>ok, then you're going to have inconsistent styles.
21:47:38  <trevnorris>since I had to do so much rewrite on node_buffer, I've tried to follow the google style guide best I could. hopefully you guys will pick out anything I missed.
21:48:10  <indutny>isaacs: surely you can do whatever you want, but… look at libuv
21:48:11  <isaacs>the only sane way to handle style persnicketiness is to have a program that enforces it.
21:48:14  <indutny>its so pure and clean
21:48:18  <isaacs>indutny: libuv is C, not C++
21:48:19  <indutny>and in one style
21:48:20  <indutny>and I like it
21:48:21  <isaacs>sure
21:48:25  <indutny>and so what?
21:48:27  <isaacs>or look at node's *.js
21:48:32  <indutny>exactly
21:48:37  <indutny>there're looking similarly
21:48:39  <isaacs>so, let's use a linter.
21:48:43  <indutny>sure
21:48:44  <isaacs>why not?
21:48:53  <isaacs>everyone hates our cpplint we have now.
21:48:55  <isaacs>and it's awful
21:48:56  <indutny>we already have one in tools/
21:49:05  <isaacs>and no one actually uses it, and it has never passed
21:49:11  <indutny>yes
21:49:17  <isaacs>so let's rip out cpplint, and get a btter one that isn't stupid
21:49:20  <isaacs>bnoordhuis: ?
21:49:44  <isaacs>or just accept that node's style is closer to V8's than to libuv's, and be ok with node's C++ being a little more lax.
21:50:21  <bnoordhuis>we fix up style issues as we go along
21:50:33  <bnoordhuis>it'll eventually get there
21:50:36  <isaacs>can you point me to what node's C++ style guide actually is?
21:50:40  * kevinswiberjoined
21:50:46  <bnoordhuis>mostly google styleguide-ish
21:50:48  <isaacs>i cannot express to you how little ic are about this.
21:50:52  * kevinswiberquit (Remote host closed the connection)
21:50:53  <isaacs>bnoordhuis: that's not a guide.
21:51:31  <isaacs>bnoordhuis: there are approximately zero cpplint passing files in node/src/
21:51:47  <isaacs>and cpplint is the codified authority on google's style guide.
21:51:53  <bnoordhuis>yeah. and i don't care
21:52:03  <isaacs>so, what's our style guide? i think we don't have one.
21:52:16  <bnoordhuis>like i said, we fix up style violations as we go along
21:52:29  <isaacs>what is a "violation"? do we even have a list of rules?
21:52:44  <isaacs>it sounds like our c++ style guide is "the whim of ben noordhuis"
21:52:52  <isaacs>which is fine, and easy to check for, if you're ben noordhuis
21:54:00  <isaacs>but the reason why i took a few hours and made all our js pass lint back in 0.7, was because the only way to have sanity with this stuff is to just do it all at once, and have a programmatic way to keep it in line.
21:54:15  <isaacs>otherwise it's an unnecessary hurdle to contributions.
21:54:22  <bnoordhuis>sure, but i don't care about that
21:54:31  <bnoordhuis>if you fix up all the style issues in a single commit
21:54:37  <bnoordhuis>you'll probably be touching 50% of all c++ code
21:54:39  <indutny>isaacs: v8's style is pretty strict
21:54:41  <indutny>and I'm actually using it
21:54:47  <indutny>and was talking about it
21:55:09  <isaacs>indutny: but you also have extra rules that are not in that style guide, or at least, not enforced by cpplint.
21:55:20  <isaacs>indutny: and we frequently violate the #include rules
21:55:21  <indutny>probably
21:55:57  <indutny>but ben is right about touching 50% of code
21:56:23  <isaacs>yeah, linting the js touched just about every js file, as well. sometimes rather extensively.
21:56:40  <indutny>well
21:56:44  <indutny>the problem is backporting :)
21:56:47  <indutny>actually
21:56:50  <indutny>porting forward
21:56:53  <indutny>from 0.10 to 0.11
21:56:59  <isaacs>and this is just silly: src/string_decoder.cc:39: Missing username in TODO; it should look like "// TODO(my_username): Stuff." [readability/todo] [2]
21:57:07  <indutny>that's not bad, actually
21:57:14  <indutny>but pretty silly, yes
21:57:26  <trevnorris>isaacs: get's better. have a variable named "string" and it bitches about not including <string.h>
21:57:27  <isaacs>indutny: we dont' assign our TODOs, and if you want to know who wrote it, check git blame
21:57:33  <indutny>that's not assignment
21:57:39  <indutny>its like
21:57:44  <indutny>I think this stuff must be done
21:57:48  <indutny>with specifying who I am
21:57:53  <indutny>but yes
21:57:55  <indutny>its silly
21:57:59  <isaacs>right. we should not put data in the file that is better handled by source control.
21:58:00  <indutny>and redundant
21:58:09  <bnoordhuis>convenient though
21:58:14  <indutny>isaacs: this line could be moved
21:58:14  <bnoordhuis>saves having to sift through git blame
21:58:19  <indutny>and source control won't help you
21:58:31  <bnoordhuis>possibly multiple git blames in case people have been landing all kinds of lint patches :)
21:58:41  <indutny>hahah
21:58:43  <indutny>yes :)
21:58:49  <isaacs>either the thing should be done, or it shouldn't be. if you decide it shouldn't be, then remove the TODO. if you decide it should be, then who cares who wrote the line?
21:58:54  <isaacs>that's unnecessary clutter.
21:59:03  <isaacs>it's the same reason you don't comment out code.
21:59:22  <isaacs>it is *node* saying that this or that needs to be done.
22:00:19  <bnoordhuis>ah, midnight
22:00:26  <indutny>I care
22:00:27  <indutny>its like
22:00:30  <indutny>TODO: fix this stuff
22:00:31  <bnoordhuis>signing off, have a good night everyone
22:00:37  <indutny>bnoordhuis: sleep tight
22:00:41  <trevnorris>night
22:00:42  <indutny>and then someone finds it
22:00:48  <indutny>and wonders "what stuff?"
22:00:50  * bnoordhuisquit (Quit: leaving)
22:01:04  <indutny>and starts finding person who wrote it
22:02:59  * c4miloquit (Remote host closed the connection)
22:03:04  * EhevuTovquit (Quit: This computer has gone to sleep)
22:03:25  * c4milojoined
22:04:03  <isaacs>g'nite bn
22:04:06  <isaacs>g'nite bnoordhuis
22:04:21  <isaacs>indutny: well, i mean, that's justa bad todo message :)
22:04:31  <isaacs>indutny: the answer there is to not do that :)
22:04:39  <indutny>well
22:04:50  <indutny>that's not that hard to put username here
22:05:03  <indutny>and it isn't clobbering code *that* much
22:05:05  <indutny>but helps a lot
22:05:08  <indutny>sometimes
22:05:22  <indutny>and I agree that usually in such times comment is just badly written
22:05:33  * timoxleyquit (Ping timeout: 240 seconds)
22:05:34  <indutny>and it should be filtered at review
22:07:35  * EhevuTovjoined
22:07:40  * c4miloquit (Ping timeout: 246 seconds)
22:11:14  <isaacs>anyway... if ben and you both want to use cpplint, then fine, i'll put (isaacs) in TODO comments.
22:11:40  <isaacs>it's just frustrating to say "style issues" without pointing to what specific rules our style requires, you know?
22:11:56  <isaacs>and if we use cpplint, then fine, but let's disable the rules we don't actually care about, like header ordering
22:12:08  <isaacs>and perhaps add in any that are missing.
22:12:40  <indutny>sure, I agree
22:12:46  <indutny>but header ordering looks good to me
22:13:38  * kenperkinsjoined
22:13:50  * kellabytequit (Ping timeout: 258 seconds)
22:15:10  <isaacs>also, and i really mean this, i have NO personal opinion about any specific style rules, except that they should be clear, and easy to follow.
22:15:22  <isaacs>i write modules in every conceivable style.
22:23:16  * kellabytejoined
22:24:40  <isaacs>indutny: why is reinterpret_cast<foo>(obj) better than (foo)obj
22:24:52  <indutny>because there're a lot of different casts
22:24:55  <isaacs>indutny: i don't get this thing's objection to c-style casts.
22:25:09  <indutny>c-style casts are just compatibility stuff
22:26:03  <isaacs>it seems like reinterpet_cast is basically identical to c-style casts, though
22:26:17  <isaacs>"Here's some memory, interpret it as this sort of thing"
22:26:55  <trevnorris>but (foo)(bar) doesn't imply reinterpret_cast
22:27:50  <isaacs>i guess, i mean, the typical use case is if you have a void* and you know that it's actually some other kind of thing.
22:27:58  <isaacs>loose typing in C
22:28:17  <amartens>the best kind of typing
22:29:06  <trevnorris>yeah. and I don't have anything against them. imho it's all about consistency. like semicolons in js. I know I don't _need_ them everywhere. but don't like to have to remember the list of rules of when (not) to.
22:30:20  <tjfontaine>List<? extends NodeProperty<?>>
22:30:30  <tjfontaine>oh yes, java how I love you
22:30:40  <tjfontaine>LOUDBOT: how do we feel about javur?
22:30:40  <LOUDBOT>tjfontaine: BECAUSE I'M THAT KIND OF FRIEND
22:31:51  * piscisaureus_joined
22:34:30  * stagasjoined
22:36:57  * kellabytequit (Ping timeout: 256 seconds)
22:37:39  <isaacs>trevnorris: the rules are actually super simple.
22:37:50  <isaacs>trevnorris: before any [ or ( at the start of a line.
22:37:55  <isaacs>that's basically the whole ruleset.
22:38:50  <isaacs>(ok, if you want to get technical, it's /^[[(+*-]/ and / where it's not a regexp, but the other cases are kind of ridiculous)
22:39:48  <trevnorris>:)
22:40:44  * qardpart
22:41:11  <isaacs>LOUDBOT: search java
22:41:12  <LOUDBOT>isaacs: <ew73:#stimutacs> JAVASCRIPT WORKS BECAUSE PROTOTYPES
22:41:14  <isaacs>LOUDBOT: search java
22:41:15  <LOUDBOT>isaacs: <HighBit:##church-of-loudbot> HEY GUYS GUESS WHAT JAVA HAS CLOSURES NOW!... MADE YOU LOOK
22:41:25  <isaacs>LOUDBOT: next
22:41:26  <LOUDBOT>isaacs: <nkk:#peltkore> IS THAT JAVA IANK :OO
22:41:28  <isaacs>LOUDBOT: next
22:41:28  <LOUDBOT>isaacs: <YTZ:##church-of-loudbot> JAVA NEEDS TO STEP THE FUCK UP AND BE SOMETHING
22:41:32  <isaacs>LOUDBOT: next
22:41:32  <LOUDBOT>isaacs: <machinaut:#ncsulug> USE ALL THE CDN-HOSTED HIPSTER JAVASCRIPT FRAMEWORKS
22:41:35  <isaacs>LOUDBOT: next
22:41:35  <LOUDBOT>isaacs: <isaacs:#stackvm> HOORAY FOR HORROR JAVASCRIPT!
22:41:37  <isaacs>LOUDBOT: next
22:41:38  <LOUDBOT>isaacs: <spiffytech:#ncsulug> JAVASCRIPT CAN GO DIE IN A FIRE
22:41:41  <isaacs>LOUDBOT: next
22:41:41  <LOUDBOT>isaacs: <frijole:##turtles> ... REACTIVATION AFTER THE ONE YEAR. REACTIVATION PROCESS IS THROUGH SHORT SMS CODE. SERVER SIDE WILL ENABLE ME TO FILL SHORT SMS CODE AND MESSAGE CONTENT. GREAT DESIGN AND LOOKS BUT LIGHT IN SIZE AND DATA TRANSMISSION. SEND ME A QUOTE. I NEED VERSION FOR BLACKBERRY,ANDROID,SYMBIAN,S40 AND S60 JAVA PHONES.
22:42:08  <tjfontaine>heh
22:42:38  <tjfontaine>##church-of-loudbot sounds amusing
22:43:10  <isaacs>oh, it is
22:43:15  <isaacs>you must speak in all caps, or you get booted
22:43:24  <tjfontaine>haha
22:43:41  <tjfontaine>I'm surprised it doesn't also require nicks to be caps
22:46:46  * piscisaureus_quit (Ping timeout: 268 seconds)
22:50:14  <TooTallNate>lol
22:50:17  <TooTallNate>i got kicked
22:50:43  <tjfontaine>you thought it was a joke :0
22:51:34  <TooTallNate>just testing the system :)
22:51:43  <TooTallNate>IT WORKSS!!!
22:51:43  <LOUDBOT>GAD DANGIT BILL, WE'RE TALKIN' 'BOUT PROPANE
22:52:32  <tjfontaine>heh
22:52:41  <tjfontaine>endless amounts of fun
22:53:05  * piscisaureus_joined
22:59:20  * wolfeidauquit (Remote host closed the connection)
22:59:37  <trevnorris>tjfontaine: you still working on the persisting persistents thing?
23:01:55  <tjfontaine>trevnorris: I took a break to do some javur, but I'm considering looking at it again
23:02:20  <tjfontaine>trevnorris: my previous error was silly, I was just missing a scope.Close
23:02:34  <trevnorris>tjfontaine: coolio. if you figure anything else out let me know.
23:03:18  <trevnorris>i'm pushing the limits on my end, and just need a little more to get performance up-to-par w/o the SlabAllocator
23:04:28  <tjfontaine>my next stumbling block was trying to convince Buffer::HasInstance I know what I'm doing
23:06:30  <trevnorris>isaacs: right now v8 external string resources are hidden by a flag, but feel like those could offer some noticable perf gains.
23:06:56  <trevnorris>tjfontaine: heh. took me ~3 days to figure out my implementation. and still not sure if it was correct.
23:07:57  <isaacs>piscisaureus_: you around?
23:08:15  <tjfontaine>trevnorris: this of course doesn't work at all right now, but if you wanted to see what my idea was, https://gist.github.com/tjfontaine/aac4a2226c9f15d12ab5
23:10:16  <DrPizza>isaacs: C++ casts are easier to search for, and prevent you from doing things accidentally e.g. removing const when you don't intend to
23:10:28  <isaacs>DrPizza: that's fair, i guess
23:10:43  <trevnorris>tjfontaine: ooh yeah. working around the current buffer cruft will be difficult. might want to try it around the new allocator: http://git.io/EEZuSA
23:11:45  <DrPizza>isaacs: plus C casts can't do dynamic_cast
23:11:57  <trevnorris>tjfontaine: those also don't use ObjectWrap.
23:12:43  <tjfontaine>trevnorris: ya, I was just curious with how little impact I could do it with, as if it was a measurable impact it could be back ported without much fear
23:12:59  <trevnorris>tjfontaine: ah, see what you're saying. good point.
23:13:07  <piscisaureus_>isaacs: sup? is it a long question or a short one?
23:13:27  <isaacs>piscisaureus_: depends on how well you answer it :)
23:13:29  <isaacs>piscisaureus_: so, https://github.com/isaacs/node/commit/0a5dda14ab2f811c003055bc1fa87476169a89ab
23:13:45  <isaacs>piscisaureus_: one problem with this, if i was to replace StreamWrap's WriteStringImpl stuff with this
23:13:56  <tjfontaine>trevnorris: but anyway, I was mostly curious if we gain anything by lumping the persistent allocations together
23:14:24  <isaacs>piscisaureus_: need to pass the StringDecoder* around, so that i know when to delete it. OR, need to have StringDecoder not be RAII, and just say that the consumer is responsible for deleting the char* data
23:14:49  * st_lukequit (Remote host closed the connection)
23:16:13  <piscisaureus_>isaacs: what's the purpose of that class?
23:16:34  <piscisaureus_>isaacs: is node::Buffer going to embed it?
23:16:46  <isaacs>piscisaureus_: well, we have a bunch of places where it'd be nice to implement the same logic as StreamWrap::WriteStringImpl
23:16:58  <isaacs>piscisaureus_: eg, crypto, zlib, etc.
23:17:10  <isaacs>piscisaureus_: save a new Buffer() in JS-land for string writes
23:17:17  <piscisaureus_>isaacs: I would not make StringDecoder a class.
23:17:29  <piscisaureus_>isaacs: or, I would make it a class but not one to instantiate
23:17:29  <isaacs>what approach would you use?
23:17:43  <isaacs>sure. class-as-namespace
23:18:10  <isaacs>so, you'd suggest just a function that returns the data pointer, and you pass it an int* for it to write the length for you?
23:18:11  * wolfeidaujoined
23:18:34  <isaacs>(or returns a uv_buf struct, i guess, would be simpler)
23:18:36  <piscisaureus_>isaacs: well two things first, one of the WriteWrap tricks (other than the GetStorageSize trick) is to avoid unnecessary malloc calls
23:18:54  <piscisaureus_>isaacs: so if you make this a class to instantiate then you'll lose this
23:18:56  <piscisaureus_>I would just do:
23:19:01  <isaacs>yeah, true that
23:19:03  <piscisaureus_>(wherever you need this functionality)
23:19:06  <isaacs>feels cleaner, but it's actually clumsy
23:22:01  <piscisaureus_>size_t size = StringDecoder::GetStorageSize(str, kUtf8);
23:22:01  <piscisaureus_>// Allocate space for storage here. Might malloc, might piggyback onto another allocation
23:22:01  <piscisaureus_>StringDecoder::Write(str, kUtf8);
23:22:36  <piscisaureus_>er.
23:22:36  <piscisaureus_>StringDecoder::Write(str, kUtf8, storage)
23:24:04  <piscisaureus_>isaacs: the problem with your approach is also that it always decodes into the storage_ field, so if you want to turn this decoded string into a buffer then you'll need to copy it again, *or* you'd have to embed StringDecoder into the new buffer instance and change the `data` field to be the `string_decoder.storage_` field. Not ideal.
23:24:33  <isaacs>right
23:24:51  <isaacs>what about that thing it's doing with +15 and then rounding up to the nearest 16?
23:25:05  <isaacs>is that actually necessary?
23:25:13  <isaacs>(or rather, actually relevant)
23:25:23  <piscisaureus_>isaacs: very marginally relevant
23:25:55  <piscisaureus_>isaacs: but there are easier tricks to come up with
23:25:59  <isaacs>seems like the better API would be: size_t data_len = StringDecoder::Write(str, encoding, storage)
23:26:09  <isaacs>but then you also need to know how many bytes offset it is.
23:26:19  <piscisaureus_>isaacs: also when malloc()ing directly it probably makes no sense at all (you'll get a 16-byte aligned pointer anyway)
23:26:23  <isaacs>i guess you could do that yourself, and the StringDecoder class could not know about it.
23:26:59  <piscisaureus_>isaacs: no you need to disconnect the GetStorageSize from the Write method
23:27:15  <isaacs>you know... every time i think RAII is a great idea, and i mean, it kinda it sounds great, it just makes things sorta overly clever and complicated.
23:27:17  <piscisaureus_>isaacs: oh - you probably didn't mean to kill that
23:27:30  <isaacs>piscisaureus_: right, i mean, you could do something like this:
23:28:38  <isaacs>size = StringDecoder::GetStorageSize(str, encoding); char* storage = new char[size + 15]; data = ROUND_UP(storage, 16); StringDecoder::Write(str, encoding, data);
23:28:49  <isaacs>if you really want to do the 16 byte alignment trick
23:29:02  <isaacs>or you could just use malloc like a gentleman
23:29:21  <piscisaureus_>isaacs: well new char[] is basically malloc so that'd be okay
23:29:33  <piscisaureus_>but what we do with wraps is (and here it's somewhat relevant)
23:29:58  <isaacs>i guess we're actually stuffing the WriteReq in the first few bytes, right?
23:30:08  <isaacs>so they might fit in the 15?
23:30:47  <isaacs>er, no, we ad 15 on top of that, nvm
23:32:33  <piscisaureus_>Wrap* createWrap(Handle<String> s, enum encoding enc) {
23:32:33  <piscisaureus_> size_t string_offset = ROUD_UP(sizeof(Wrap), 16);
23:32:33  <piscisaureus_> size_t string_len = StringDecoder::GetStorageSize(s, enc);
23:32:33  <piscisaureus_> char* storage = new char[string_offset + string_len];
23:32:33  <piscisaureus_> return new (storage) Wrap(storage + string_offset);
23:32:34  <piscisaureus_>}
23:33:50  <piscisaureus_>.// and I'm missing just before the return statement:
23:33:51  <piscisaureus_>StringDecoder::Write(s, enc, storage + string_offset);
23:34:09  * kenperkinsquit (Quit: Computer has gone to sleep.)
23:34:24  <isaacs>you're talking about this:
23:34:25  <isaacs> char* storage = new char[sizeof(WriteWrap) + storage_size + 15];
23:34:25  <isaacs> WriteWrap* req_wrap = new(storage)WriteWrap();
23:34:26  <isaacs>yes?
23:34:47  <trevnorris>isaacs: is there a set-ish time when v0.12 will be released?
23:34:52  <piscisaureus_>isaacs: yes, although now I think that indiscriminately adding 15 to the size is kinda lame
23:34:54  <isaacs>trevnorris: when it's ready, as always
23:34:57  <piscisaureus_>we can do better than that :)
23:35:01  <isaacs>piscisaureus_: yes.
23:35:09  <trevnorris>isaacs: coolio. :)
23:35:15  <piscisaureus_>which I did with ROUND_UP in the snippet I posted
23:36:22  <isaacs>i see
23:36:49  <isaacs>and the `new (pointer) Type(args)` creates a new `Type` thing at the data referenced by pointer?
23:37:11  <isaacs>s/data/memory location/
23:37:52  * kenperkinsjoined
23:39:09  * timoxleyjoined
23:40:01  <piscisaureus_>isaacs: yessir
23:40:08  <isaacs>k
23:41:06  <isaacs>so the new char[..] gets the memory (without a malloc) and guarantees that string_offset will be at a %16 boundary
23:41:19  <isaacs>piscisaureus_: and then later, when you do `delete wrap`, it freesit
23:41:44  <piscisaureus_>isaacs: well - that's not how you do it :)
23:42:05  <piscisaureus_>isaacs: delete both calls the destructor and frees, which assumes that the object was deleted using normal new
23:42:17  <piscisaureus_>isaacs: usually you would call the destructor explicitly
23:42:22  <isaacs>right
23:42:22  <isaacs> req_wrap->~WriteWrap();
23:42:26  <piscisaureus_>yes
23:42:27  <isaacs> delete[] storage;
23:42:48  <piscisaureus_>yes
23:42:53  <isaacs>or:
23:42:53  <isaacs> req_wrap->~WriteWrap();
23:42:53  <isaacs> delete[] reinterpret_cast<char*>(req_wrap);
23:43:04  <isaacs>ok, i think i get this.
23:43:06  <piscisaureus_>yes you need the reinterpret_cast
23:43:13  <piscisaureus_>otherwise it will call the WriteWrap destructor again
23:43:17  <isaacs>right
23:43:24  <isaacs>ok, so:
23:43:35  <piscisaureus_>technically delete req_wrap should work :)
23:43:44  <isaacs>size_t StringDecoder::GetStorageSize(Handle<String>, StringEncoding enum)
23:43:57  <piscisaureus_>static
23:43:57  <isaacs>that tells you how big a thing it's going to need
23:44:02  <isaacs>k, whatever.
23:44:06  <piscisaureus_>yes
23:44:14  <isaacs>then you make the thing, malloc/new, your pleasure
23:44:40  <piscisaureus_>compute where the string goes, or just drop in the the malloced area
23:45:05  <isaacs>then you call: static size_t StringDecoder::WriteString(Handle<String>, StringEncoding enum, char* data);
23:45:18  <piscisaureus_>yes
23:45:24  <isaacs>and it writes the bytes to the pointer you give it, and tells you how much it wrote
23:45:34  <piscisaureus_>exactly
23:45:34  <isaacs>and hten it's on you to delete or free or whatever you do with that.
23:45:40  <piscisaureus_>yep
23:45:48  <isaacs>and the data can be (storage + sizeof(blerg) + 123) for all it cares.
23:46:11  <isaacs>ok, this is simpler. fuck riaa, man. always trying to keep the mp3 pirates down.
23:46:11  <piscisaureus_>StringDecoder doesn't give a shit, the caller is responsible for allocating a large enough chunk of memory
23:46:15  <isaacs>right
23:46:27  <piscisaureus_>isaacs: this is not a violation of RIAA I think
23:46:52  <piscisaureus_>er, raii
23:47:21  <isaacs>well, no, because it's not an instantiation
23:47:34  <isaacs>and there's no initialization, per se.
23:47:41  <isaacs>it's just two related functions on a namespace.
23:48:02  <isaacs>no one's sharing mp3s with anybody
23:48:41  <piscisaureus_>isaacs: so StringDecoder just becomes a container for helper functions
23:48:48  <isaacs>yep
23:48:51  <isaacs>i like it
23:48:55  <isaacs>feels more c-like :)
23:49:00  <isaacs>simpler.
23:49:08  <piscisaureus_>isaacs: you *might* want to make it instantiated but it should have no fields in that case
23:49:17  <isaacs>piscisaureus_: what would be teh value of that?
23:49:25  <piscisaureus_>isaacs: if you were to implement StringEncoder you would need it :)
23:49:49  <piscisaureus_>isaacs: so if you are planning to do that too then you might want to make the interfaces as similar as possible
23:49:54  <isaacs>piscisaureus_: but we don't need to implement StringEncoder, becuase v8::String::New
23:49:55  <piscisaureus_>but, shrug
23:50:59  <piscisaureus_>isaacs: well, true, except that the StringDecoder in node does more because it considers multibyte characters at chunk boundaries
23:51:24  <piscisaureus_>isaacs: also note that your StringDecoder does exactly the opposite as what the string_decoder module does ...
23:51:45  <isaacs>piscisaureus_: yeah, that was another thing i realized...
23:51:55  <isaacs>piscisaureus_: require('string_decoder') isn't decoding strings.
23:52:00  <isaacs>piscisaureus_: it's ENcoding strings.
23:52:02  <piscisaureus_>it is
23:52:08  <piscisaureus_>it is decoding buffer data into strings
23:52:11  <piscisaureus_>:)
23:52:15  <piscisaureus_>anyway, that ship has sailed
23:52:44  <isaacs>require('interpret_data_as_string').DataInterpreterAsString()
23:52:49  <isaacs>yeah
23:52:55  <isaacs>tempted to just pick a completely new name for this class.
23:52:57  <isaacs>like "Fred"
23:53:01  <isaacs>Fred's a great name.
23:53:05  <piscisaureus_>DecodeBinaryDataToString
23:53:10  <isaacs>or maybe Roberta
23:54:05  <piscisaureus_>Call it Isaacs1
23:55:04  <trevnorris>is there a minimal webserver written in libuv? google is failing me. every example is crap.
23:57:41  <isaacs>trevnorris: ping kellabyte
23:57:58  <trevnorris>isaacs: thx
23:58:09  <isaacs>ircretary: where's kellabyte
23:58:10  <ircretary>isaacs: I'm not sure what to do with that command. Ask for help in PM.
23:58:16  <isaacs>ircretary: where is kellabyte
23:58:17  <ircretary>isaacs: kellabyte was last seen at 2013-05-01T22:23:16.772Z, joining #libuv
23:58:28  <isaacs>trevnorris: or on the twitters
23:58:39  <trevnorris>ah, I forget that exists.
23:58:50  <isaacs>trevnorris: making a database with http and libuv and stuff, i believe.
23:59:09  <isaacs>someone should totally build node.c, btw
23:59:13  <isaacs>(and no, libuv is not node.c)
23:59:25  * timoxleyquit (Quit: Computer has gone to sleep.)
23:59:36  <isaacs>like, with a module system, and easy http bindings, etc.
23:59:48  <trevnorris>isaacs: well, that was easy. first thing on his github. :)
23:59:56  <isaacs>trevnorris: her :)