00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:02  <tjfontaine>trevnorris: the man page doesn't indicate that it would return less, but it does say it returns how much was written, defensive coding may need to take effect
00:00:09  * ircretaryjoined
00:00:41  <trevnorris>tjfontaine: thanks.
00:01:05  <mordy_>ok.. finally i have my DLL
00:01:19  <tjfontaine>the linux man page says different than osx of course
00:01:20  <tjfontaine>The number of bytes written may be less than count if, for example, there is insufficient space on the underlying physical medium, or the RLIMIT_FSIZE resource limit is encountered (see setrlimit(2)), or the call was interrupted by a signal handler after having written less than count bytes
00:01:44  <trevnorris>bnoordhuis: ok. all updated have occurred to the file linked here: https://github.com/trevnorris/node/commit/fc312d1#diff-2
00:02:27  <trevnorris>tjfontaine: ok. problem there is I don't allow users to specify a substring. so if the write length is < string byte length they'll have to write the entire thing again.
00:02:57  <tjfontaine>trevnorris: the upper api may not support it, but your call could?
00:03:16  <trevnorris>tjfontaine: you mean writing a substring?
00:03:25  <tjfontaine>handling the retry
00:04:11  <trevnorris>tjfontaine: retrying was my first thought, but in the case of disk being full then retrying would be bad.
00:05:45  <trevnorris>i'm cool w/ the idea of handling it more gracefully, but between not knowing the best solution and it not having been supported before, not going to worry about it for this pr. :)
00:07:33  <tjfontaine>trevnorris: checking for ENOSPC or EFBIG and other things are appropriate
00:08:18  <tjfontaine>in those cases you're getting -1 back, which is probably already handled for you
00:08:39  * loladirojoined
00:10:16  <trevnorris>tjfontaine: yeah it is. good point.
00:10:22  * loladiroquit (Client Quit)
00:11:34  <tjfontaine> 1 osx-x64.tap:not ok - test-tls-client-verify.js
00:11:34  <tjfontaine> 1 smartos-x64.tap:not ok - test-tls-client-verify.js
00:11:34  <tjfontaine> 1 windows-x64.tap:not ok - test-tls-client-verify.js
00:11:34  <tjfontaine> 2 linux-ia32.tap:not ok - test-tls-client-verify.js
00:11:34  <tjfontaine> 2 linux-x64.tap:not ok - test-tls-client-verify.js
00:11:36  <tjfontaine> 2 smartos-ia32.tap:not ok - test-tls-client-verify.js
00:11:39  <tjfontaine> 6 osx-ia32.tap:not ok - test-tls-client-verify.js
00:11:50  <tjfontaine>ok, finally worked that job out so I could see useful things
00:12:40  <tjfontaine>I really need to do a post-process job with node-tap and turn them into json blobs
00:16:40  * trevnorris&
00:16:41  <LOUDBOT>GOOGLE CORRECTS OTHER PEOPLE'S SPELLINGS AS WELL AS YOUR OWN
00:31:36  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:41:29  * amartensquit (Quit: Leaving.)
00:41:55  * qardquit (Quit: Leaving.)
00:42:22  * qardjoined
00:45:20  * piscisaureus_joined
00:46:08  * piscisaureus_quit (Client Quit)
00:46:33  * qardquit (Ping timeout: 246 seconds)
00:49:48  * TooTallNatejoined
00:58:25  * bradleymeckjoined
01:03:51  * abraxasjoined
01:05:27  * timoxleyquit (Quit: Computer has gone to sleep.)
01:06:51  * loladirojoined
01:20:34  * TooTallNatequit (Quit: Computer has gone to sleep.)
01:25:20  * amartensjoined
01:25:48  * bradleymeckquit (Quit: bradleymeck)
01:39:28  * M28quit (Read error: Connection reset by peer)
01:39:43  * M28joined
01:41:30  <bnoordhuis>41 files changed, 1691 insertions(+), 3071 deletions(-) <- seriously, wtf?
01:42:03  <tjfontaine>jesus.
01:42:05  <tjfontaine>that's a lot of touch
01:42:30  <bnoordhuis>i removed v8_typed_array* tough
01:42:43  <bnoordhuis>it was beyond salvation and v8 has native typed arrays now
01:42:52  <bnoordhuis>*though
01:43:15  <tjfontaine>indeed
02:14:42  * M28quit (Read error: Connection reset by peer)
02:15:59  * M28joined
02:18:31  * hij1nxquit (Ping timeout: 264 seconds)
02:30:08  * AvianFluquit (Read error: Connection reset by peer)
02:30:38  * groundwaterjoined
02:30:45  * AvianFlujoined
02:34:28  * brsonquit (Quit: leaving)
02:39:18  * appu_joined
02:45:06  * dap1quit (Read error: Connection reset by peer)
02:45:11  * timoxleyjoined
02:46:03  * dapjoined
02:49:49  <bnoordhuis>from simple/test-buffer: // check that the base64 decoder ignores illegal chars
02:50:14  <tjfontaine>hm
02:50:22  <bnoordhuis>maybe the base64 decoder does. String::AsciiValue however doesn't anymore :(
02:50:46  <bnoordhuis>i'm hitting asserts in v8 left and right
02:50:58  <bnoordhuis>oh well, there's always tomorrow
02:57:17  * dapquit (Quit: Leaving.)
02:57:37  * dapjoined
03:04:15  * appu_quit (Quit: appu_)
03:23:09  * dapquit (Quit: Leaving.)
03:28:28  * kazuponjoined
03:33:31  * dapjoined
03:33:37  * dapquit (Client Quit)
03:36:22  * M28quit (Read error: Connection reset by peer)
03:36:35  * M28joined
03:36:35  * appu_joined
03:39:11  * appu_quit (Client Quit)
03:42:42  * TooTallNatejoined
03:47:13  * M28quit (Remote host closed the connection)
03:47:28  * M28joined
03:50:14  * groundwaterquit (Quit: groundwater)
03:57:16  * defunctzombiechanged nick to defunctzombie_zz
03:58:28  * bnoordhuisquit (Ping timeout: 256 seconds)
04:06:20  * timoxleyquit (Quit: Textual IRC Client: www.textualapp.com)
04:07:17  * bajtosjoined
04:08:22  * timoxleyjoined
04:19:47  * hij1nxjoined
04:20:35  * bradleymeckjoined
04:45:33  * appu_joined
05:04:41  * bnoordhuisjoined
05:06:16  <tjfontaine>trevnorris: specifically the conversation is about bumping that number as convention per each release, part of the problem is that we internally have a poorly defined process for that number changing
05:06:51  <tjfontaine>I think this continues to fall into the category that addons and the api for them are still largely undefined
05:10:07  * bnoordhuisquit (Ping timeout: 276 seconds)
05:12:17  * bradleymeckquit (Quit: bradleymeck)
05:16:06  <trevnorris>tjfontaine: understood. guess for me it's always been, expect breakage every dev release and keep stable, well, stable.
05:16:15  <trevnorris>so never bothered w/ that value
05:16:37  <tjfontaine>well, depending on what's going on, a prebuilt .node will still load presuming the symbols are still there
05:16:44  <tjfontaine>however
05:17:00  <tjfontaine>all hell can break loose in unexpected ways, or in very subtle ways
05:17:21  <tjfontaine>which makes it difficult for module authors to diagnose issues as they come into their project
05:17:33  <trevnorris>yeah. well this dev cycle is going to be full of all hell breaking loose constantly
05:18:16  <tjfontaine>sure, which is why it's important that we work out our policy for such things, as it would take a very severe issue for that number to ever change in a stable releas
05:18:19  <tjfontaine>e
05:18:53  <tjfontaine>the only time that number will change with regularity is in the unstable branch
05:19:04  <trevnorris>imho it'd be a pre-req to standardizing what api we actually support
05:19:37  <tjfontaine>I don't disagree, I plan on writing down some of my thoughts on that this weekend and attaching it to the issue
05:20:03  <trevnorris>you know if ben has his current v8 changes online somewhere?
05:20:34  <trevnorris>oh, and rvagg didn't even hit half the current changes.
05:20:45  <tjfontaine>https://github.com/bnoordhuis/node/compare/upgrade-v8 it may be this one
05:21:05  <tjfontaine>trevnorris: so we really need to keep that doc up to date in lockstep with our commits
05:21:30  <trevnorris>ok. i'll throw up at least what changes have happened.
05:21:42  <rvagg>there was a bump in 0.10, or perhaps it was 0.8, I can't remember the context but there will be occasion where it may be necessary to bump it in stable
05:22:23  <tjfontaine>as this issue is concerned for rvagg, my position would be that we only update that number IFF something has changed since the last unstable point release, not just because it's a point release, and that number should only ever bump once per release
05:22:48  <trevnorris>would it also count for js api changes, or just cc level changes?
05:22:51  <tjfontaine>rvagg: right, a bump in a stable of 0.8 or 0.10 would indicate we released too soon
05:22:55  <rvagg>that's fine as long as you have a relatively strict process for doing it and that people actually do it
05:23:00  <tjfontaine>trevnorris: no, this is specifically for binary addons
05:23:04  <trevnorris>ok
05:23:09  <tjfontaine>trevnorris: if this number changes and you require() it will refuse to load
05:23:23  <trevnorris>alright. i'm updating the wikipage now
05:23:31  <tjfontaine>rvagg: yes, I agree, this is a failure of our internal process imo
05:26:20  <tjfontaine>if we've released a version of node (unstable or otherwise) and then we've changed an api that modules depend on, or changed the abi, regardless of the fact it's the unstable channel, we *should* update the node_module_version
05:27:07  <tjfontaine>akin to that, we need to actually work at actually integrating addon tests into the test suite, so it's easier for us to identify when we've failed
05:27:43  <tjfontaine>I will file an issue for that (if it's not already there) and assign it to myself
05:28:24  <trevnorris>fwiw v8 has been changing so fast that we'd have to had removed half the changes currently in place
05:28:46  <tjfontaine>that's ok
05:29:08  <tjfontaine>I'd rather have churn on that wiki page than to miss something come time to release 0.12
05:30:31  <rvagg>trevnorris: what's the deal with deprecating Handle? are we supposed to be using just Local and Persistent now? what if we need a generic version of both of those?
05:31:10  <trevnorris>rvagg: there's no generic version. that's part of the pain ben is going through right now updating core to 3.20
05:31:26  <rvagg>yikes, so Local and Persistent are no longer related?
05:31:39  <trevnorris>yup. no class inheritance going on
05:31:46  <rvagg>oh my
05:32:07  <trevnorris>so they have to be explicitly cast, and that also means a lot more function declarations if you want to support both.
05:33:13  <rvagg>I guess that's going to make it harder to miss a non-Disposed Persistent then
05:46:47  * stagasjoined
05:47:51  <trevnorris>tjfontaine: how's this: https://github.com/joyent/node/wiki/API-changes-between-v0.10-and-v0.12
05:49:31  <tjfontaine> Buffer.dipose() have been added
05:49:35  <tjfontaine>that did go in?
05:49:56  <trevnorris>Buffer.dispose() but now Buffer#dispose()
05:50:00  <trevnorris>s/now/not
05:50:33  <tjfontaine>so <instance>.dispose()?
05:50:42  <trevnorris>no. that isn't in
05:51:00  <tjfontaine>ok so what does the "static method" in this case do?
05:51:32  <trevnorris>var b = {}; Buffer.alloc(5, b); /* use b for stuff */ Buffer.dispose(b);
05:51:49  * TooTallNatequit (Quit: Computer has gone to sleep.)
05:51:51  <tjfontaine>oh
05:51:58  <trevnorris>it's an api specifically for module authors. not used in core.
05:52:07  <tjfontaine>hm
05:52:22  <trevnorris>actually, wait. mis spoke
05:52:47  <trevnorris>the underlying mechanism is used in core, but I just exposed it via simple class methods
05:53:02  <tjfontaine>right
05:53:13  <tjfontaine>what happens if I Buffer.dispose(<instance of buffer>)
05:53:19  <trevnorris>throws
05:53:28  <trevnorris>put in a check specific for that
05:53:31  <tjfontaine>mk
05:53:52  <tjfontaine>I may have asked that question before :P
05:54:07  <trevnorris>nope, not yet. :)
05:54:42  <M28>I need some clarifications about uv_tcp_connect
05:54:57  <trevnorris>tjfontaine: here's the doc entries: http://git.io/pRsCZQ
05:55:03  <M28>the first handle, what is it? A handle to the connection, so do I need to store it?
05:55:12  <tjfontaine>so I wonder if there's a better name of these alloc/dispose methods, or if we can/should attach them to a separate "class" to avoid confusion
05:56:14  <trevnorris>I was considering it by exposing a require('smalloc'). forget why I opted against it.
05:56:23  <tjfontaine>in principle I agree they are part and parcel to how Buffer works, but what they create isn't exactly compatible
05:57:17  <trevnorris>M28: this help at all: http://nikhilm.github.io/uvbook/networking.html#client
05:57:26  <M28>already looked into it
05:57:45  <M28>it doesn't explain the arguments or anything...
05:58:07  <trevnorris>tjfontaine: it'd be simple enough to do.
05:59:14  <tjfontaine>trevnorris: we should mull it over some more
05:59:37  <trevnorris>yeah. being labeled experimental it can be changed w/o much fuss.
06:01:34  <tjfontaine>M28: uv_connect_t is similar to a write or read request it's valid while the connection is in progress, the uv_tcp_t is what represents the connection as a whole
06:02:19  <tjfontaine>trevnorris: well, we assign stability by module, not by method
06:02:32  <trevnorris>M28: have you looked at uv.h yet? I mean like http://git.io/ws3sxQ
06:02:50  <M28>I'm even looking at the test cases
06:02:58  <tjfontaine>M28: did my explanation make sense?
06:03:00  <M28>"/* uv_connect_t is a subclass of uv_req_t */" doesn't help a lot
06:03:01  <trevnorris>tjfontaine: true true. then it should probably be resolved fairly quickly.
06:03:04  <M28>yeah it kinda did
06:03:12  <tjfontaine>trevnorris: ya, need to think on it some more
06:03:29  <M28>the problem is that I'm sending a write request, and the callback for it is never getting called, and the server isn't receiving the request
06:04:13  <trevnorris>M28: it was more about the fields in the struct than the actual explination I found useful.
06:04:50  <tjfontaine>M28: if you're still around tomorrow I will walk through your code, if it's updated since last you gist'd it please make sure to let me know, or if there's a new location for it
06:05:05  <M28>alright
06:05:34  <tjfontaine>for now, I'll sleep, see you gents on the morrow
06:05:40  <trevnorris>night
06:05:48  <M28>good night
06:06:37  <M28>the weird thing is that if I pass the wrong thing to uv_write, it manages to send the message, but then it crashes
06:06:55  <M28>if I pass the right thing it just doesn't send anything and doesn't crash or anything
06:06:56  <M28>sigh
06:07:49  * mikealquit (Quit: Leaving.)
06:08:37  <trevnorris>M28: have you taken a look how node uses it?
06:09:00  <M28>no
06:09:06  <M28>I'm looking at the benchmark atm
06:09:11  <M28>(this one https://github.com/joyent/libuv/blob/master/test/benchmark-tcp-write-batch.c)
06:09:49  * mikealjoined
06:09:57  <M28>I can't see anything really different from my code to that benchmark (aside from the fact I'm using C++ ofc)
06:10:39  <trevnorris>M28: so check out this method: http://git.io/_ZGyGA
06:11:15  <trevnorris>and see how it's used by being passed to uv_tcp_connect in TCPWrap::Connect
06:12:07  <M28>the problem is that the code is so mixed with v8 wrappers that it's hard to decipher
06:12:30  <M28>my code is connecting just fine, the problem is actually writing the message, which for some reason doesn't work
06:12:39  <M28>here's the current code: https://gist.github.com/Matheus28/eda2984452929cd6dbb7
06:12:42  <trevnorris>heh, yeah. unless you're used to that it it confusing.
06:13:16  <M28>it prints "Writing\n" but doesn't print anything after that. The loop is running just fine though
06:13:41  <M28>(I didn't paste some of the code that doesn't have a lot to do with the problem)
06:16:40  <M28>I'm pretty sure that the problem is in that code, because I can telnet to the server just fine, and one time I accidentally passed &m_Connect instead of req to uv_write and it actually wrote the message before crashing
06:17:10  <trevnorris>M28: can you include the code for AllocBufferCallback?
06:17:25  <M28>it's just "return uv_buf_init((char*)malloc(sizeof(char) * suggested_size), suggested_size);"
06:17:59  <M28>I found an error in my code, but it's not related to this problem
06:18:20  <M28>nevertheless, the line with "uv_read_start" should be "req->handle" instead of "req"
06:19:14  <trevnorris>why the malloc(sizeof(char) * suggested_size) instead of just malloc(suggested_size)?
06:19:29  <M28>I like to include the type
06:19:33  <M28>just personal preference
06:19:46  <trevnorris>what about OnConnectionData?
06:20:09  <M28>it's fine, it's called with -1 when I shutdown the server, but I'm gonna paste the code anyways... sec
06:20:17  <M28>https://gist.github.com/Matheus28/2871c92df9de8a01e5c3
06:22:55  <trevnorris>ok. so OnConnectionData is properly receiving data as it comes in?
06:23:26  <M28>I'm not sending data from the server yet, but it properly receives status = -1 when I shut down the server while the client is running
06:27:32  <M28>I've been scratching my head for hours and I still can't figure out why it doesn't work
06:27:44  <trevnorris>M28: have you tried simplifying it by just running a for loop or such in OnConnect writing out data with uv_write?
06:28:36  <M28>I mean... I can't see it being any simpler than that
06:35:03  <M28>oh
06:35:06  <M28>I found the problem
06:35:07  <M28>uh
06:35:21  <M28>a litte typo that cost me hours...
06:35:29  <M28>in the struct write_req_t
06:35:33  <trevnorris>heh, i've had those before.
06:35:55  <M28>who hasn't...
06:50:35  <trevnorris>wtf is going on w/ the new v8 FunctionCallbackInfo api?
06:52:18  <trevnorris>ircretary: tell bnoordhuis this new api better offset some freaky awesome performance gains for such a ridiculously drastic change.
06:52:18  <ircretary>trevnorris: I'll be sure to tell bnoordhuis
06:56:43  <ik>america
06:56:46  <ik>we won
07:01:09  * rendarjoined
07:19:30  * loladiroquit (Read error: Connection reset by peer)
07:21:15  * loladirojoined
07:26:30  * csaohjoined
07:28:23  * dominictarrquit (Quit: dominictarr)
07:32:39  * AvianFluquit (Remote host closed the connection)
07:33:53  * stagasquit (Ping timeout: 245 seconds)
07:45:12  * stagasjoined
07:50:45  * stagasquit (Quit: Bye)
07:56:39  * amartensquit (Quit: Leaving.)
08:01:31  <rvagg>whaaaat? https://github.com/bnoordhuis/node/commit/d7c32ea5042c7a4703f4a071bfafd1f0c3c5d846
08:01:38  <rvagg>anyone got links to the new v8 stuff that's going on here?
08:01:58  <rvagg>v8::FunctionCallbackInfo and the removal of Handle particularly
08:04:18  * groundwaterjoined
08:19:53  * AvianFlujoined
08:26:41  <indutny>rvagg: no handle, only Local
08:27:02  <indutny>and no return value :)
08:27:10  <indutny>only through FunctionCallbackInfo
09:02:04  * loladiroquit (Quit: loladiro)
09:06:45  <rvagg>indutny: is this all on the v8 dev list? is there somewhere that documents all these changes? google's no help
09:06:54  <indutny>hm...
09:06:58  <indutny>I don't really know
09:07:03  <indutny>I'm usually looking at v8.h
09:07:35  * groundwaterquit (Quit: groundwater)
09:08:06  <rvagg>I wonder what the rationale for removing Handle is, and why the shift to FunctionCallbackInfo
09:11:25  <indutny>handle is useless
09:11:32  <indutny>and returning it is a bit pain
09:11:43  <indutny>its much simplier to give users structure
09:11:47  <indutny>and ask them to fill it
09:12:03  <indutny>and also allows you to write functions without `return statement`
09:12:30  <rvagg>yeah, but Handle gives you a common parent of Local and Persistent.. it did anyway
09:13:39  <trevnorris>indutny: is there a reason doing "Local<Value> val = *some_persistent_val;" is no good?
09:14:00  <indutny>well, it looks terrible :)
09:14:06  <indutny>and uses explicit constructor
09:14:08  <indutny>err
09:14:10  <indutny>implicit
09:14:22  <trevnorris>how do you mean?
09:14:31  <trevnorris>(2am here, brain's wearing out :)
09:17:19  <trevnorris>indutny: my main curiosity is why ben chose the following way instead of the above: https://github.com/bnoordhuis/node/commit/d7c32ea#L27R165
09:18:52  <indutny>oh gosh
09:18:56  <indutny>that's total ben's fail
09:20:05  <indutny>trevnorris: using direct value's location is unsafe
09:20:14  <indutny>and *some_persisten_val is equivalent to val.location()
09:22:57  * rendar_joined
09:22:58  * rendar_quit (Excess Flood)
09:23:19  * rendar_joined
09:23:53  <trevnorris>indutny: ok. in v8.h it says for "V8_INLINE(T* operator*() const) { return val_; }" in class Persistent that it will be removed.
09:24:04  <indutny>yeah
09:24:06  <trevnorris>so does that mean *some_persistent_val won't work anymore?
09:24:07  <indutny>it should be
09:24:10  <indutny>yes
09:24:13  <indutny>its unsafe
09:24:21  <indutny>if you'll try to play with this value
09:24:30  <indutny>or keep it in hands while gc is running
09:24:38  <indutny>it'll point into nowhere
09:24:53  <trevnorris>hm. so what's the correct way to retrieve the Local the Persistent pionts to?
09:27:30  <trevnorris>also I can't figure out the difference between "Persistent<Value> val(Isolate*, Local<Value>);" and "Persistent<Value> val = Persistent<Value>::New(Isolate*, Local<Value>);"
09:32:06  * rendarquit (*.net *.split)
09:32:09  * defunctzombie_zzquit (*.net *.split)
09:32:53  * defunctzombie_zzjoined
09:45:32  * rendar_quit
09:45:50  * rendarjoined
10:22:01  * bajtosquit (Quit: bajtos)
10:24:35  * csaohquit (Quit: csaoh)
10:29:20  * timoxleyquit (Quit: Computer has gone to sleep.)
10:31:54  * abraxasquit (Remote host closed the connection)
10:47:03  * bajtosjoined
10:47:31  * bajtosquit (Client Quit)
10:56:07  * bnoordhuisjoined
11:00:37  * csaohjoined
11:01:22  <bnoordhuis>indutny: re: use of persistent, i'm going to eradicate it eventually
11:01:48  <bnoordhuis>that class in node_internals.h is an intermediate thingy to stop the build from breaking completely
11:02:40  * loladirojoined
11:03:24  * loladiroquit (Client Quit)
11:04:53  <indutny>heh
11:05:07  <indutny>still you're shooting yourself in a leg
11:05:23  * timoxleyjoined
11:14:54  * kazuponquit (Remote host closed the connection)
11:18:36  <bnoordhuis>indutny: well, it works for now
11:18:53  <bnoordhuis>and i don't intend on having it stay around for long
11:19:07  <bnoordhuis>i'm open to suggestions though
11:19:18  <bnoordhuis>the easy solution is to remove our use of Persistent altogether
11:41:07  <indutny>hehe
11:41:10  <indutny>it should be possible
11:41:17  <indutny>but will be pretty strange
11:41:26  <indutny>ok
11:41:27  <indutny>gtg
12:08:01  * appu_quit (Ping timeout: 248 seconds)
12:19:39  <bnoordhuis>338 unread github emails... ye gods, there is no keeping up
12:21:01  * timoxleyquit (Quit: Computer has gone to sleep.)
12:42:00  * timoxleyjoined
12:53:32  * bradleymeckjoined
12:56:30  * kazuponjoined
13:14:00  <`3rdEden>bnoordhuis: why don't you just filter them?
13:21:42  <bnoordhuis>`3rdEden: i do but that doesn't mean i don't have to go through them :-/
13:22:16  <bnoordhuis>okay, lunch break. biab
13:26:29  * bnoordhuisquit (Ping timeout: 248 seconds)
13:26:49  * kazuponquit (Remote host closed the connection)
13:40:57  * piscisaureus_joined
13:45:12  * jameshowejoined
13:45:33  <jameshowe>hello
13:46:18  <MI6>joyent/libuv: Miroslav Bajtoš master * fd45f87 : linux,darwin,win: link-local IPv6 addresses - http://git.io/QbhOEw
13:46:30  <jameshowe>after i've uv_queue_work(), is there any way to get an id or index for the thread it ends up executing on?
13:47:04  <jameshowe>as for the library i'm trying to use, one is supposed to maintain thread-local data
13:48:22  <piscisaureus_>jameshowe: I don't really understand what you mean if they say you're supposed to maintail thread-local data for them.
13:48:54  <piscisaureus_>jameshowe: there's no interface for that although you could run uv_thread_self() as part of the job
13:49:18  <piscisaureus_>jameshowe: what library is that btw?
13:49:34  <jameshowe>in-house
13:50:04  <jameshowe>there's a detector class, of which you're supposed to make an instance of for each thread
13:50:18  <jameshowe>as the detection process requires state
13:51:28  <MI6>libuv-master: #143 UNSTABLE windows (3/192) smartos (2/191) http://jenkins.nodejs.org/job/libuv-master/143/
13:52:35  <MI6>libuv-master-gyp: #81 UNSTABLE windows-x64 (4/192) smartos-ia32 (2/191) smartos-x64 (2/191) windows-ia32 (3/192) http://jenkins.nodejs.org/job/libuv-master-gyp/81/
13:52:44  <jameshowe>uv_thread_self() returns an integer I should be able to use in a map?
13:58:13  <piscisaureus_>jameshowe: well - yes
13:58:36  <piscisaureus_>jameshowe: but libuv might clean up worker threads at will and there's no hook for it
13:58:49  <piscisaureus_>jameshowe: so it sounds like you might leak memory
13:59:05  <jameshowe>not ideal
13:59:16  <piscisaureus_>jameshowe: also you could use actual TLS instead of implementing it yourself :)
14:00:06  <jameshowe>actual as in...
14:00:20  <piscisaureus_>jameshowe: also I would be surprised if you library was thread-safe. You probably are better off creating a dedicated thread.
14:01:24  <jameshowe>it's designed and tested for a single database and multiple detectors
14:02:18  <jameshowe>and I want the increased throughput of having multiple detectors, without the massive memory footprint of having multiple databases (which is what i have now)
14:05:06  <jameshowe>there's no way to get a thread by its id, so I could peridically check for removed threads?
14:06:32  <MI6>libuv-node-integration: #132 UNSTABLE smartos-x64 (7/609) smartos-ia32 (1/609) http://jenkins.nodejs.org/job/libuv-node-integration/132/
14:08:47  <jameshowe>alternatively, are pthread_setspecific et. al going to just work if I use them in the work callbacks?
14:09:18  <piscisaureus_>jameshowe: if you are on a platform that has pthreads, yes
14:10:09  <piscisaureus_>jameshowe: but still - if you instantiate a new object and assign it's pointer to a tls variable, the memory leak risk isn't gone
14:11:04  <jameshowe>the destructor on pthread_key_create won't work?
14:11:42  <piscisaureus_>jameshowe - oh - sure
14:11:44  <piscisaureus_>that works
14:11:58  <jameshowe>right, sorted then
14:12:17  <jameshowe>i'm too used to cross-platform programming I didn't think of this first
14:14:06  <piscisaureus_>we should add tls w/ destructor to libuv
14:14:10  <piscisaureus_>this is such a pita in windows
14:14:29  * jmar777joined
14:14:59  <jameshowe>called TlsAlloc on windows i think
14:15:11  <jameshowe>don't know the details though
14:16:48  * jmar777quit (Remote host closed the connection)
14:16:53  <piscisaureus_>yes but doesn't support destructors...
14:17:16  * jmar777joined
14:18:11  <jameshowe>indeed sounds like a job for libuv then
14:18:34  <jameshowe>thanks for assisting my realisation of how to do this
14:18:52  <trevnorris>i'm so confused how ben plans on removing Persistent completely. especially when resource cleanup is required (e.g. external memory)
14:19:40  * kazuponjoined
14:21:52  * jameshowequit (Quit: Leaving)
14:21:53  * jmar777quit (Ping timeout: 248 seconds)
14:32:50  * bnoordhuisjoined
14:34:11  * kazuponquit (Remote host closed the connection)
14:37:21  * bnoordhuisquit (Ping timeout: 248 seconds)
14:41:57  * AvianFluquit (Remote host closed the connection)
14:42:40  <piscisaureus_>trevnorris: maybe it does Context::Current()->global()->Get("save_objects").As<Array>->Push(object) :)
14:52:31  * bnoordhuisjoined
15:00:30  * bradleymeckquit (Quit: bradleymeck)
15:01:00  * hzjoined
15:06:07  * AvianFlujoined
15:18:02  <tjfontaine>piscisaureus_: lgtm, ship it
15:27:00  <bnoordhuis>trevnorris: still working things out
15:27:39  <bnoordhuis>but i think i have, if you will forgive me the pun, a handle on it now
15:28:23  <tjfontaine>oh god
15:28:45  <tjfontaine>you were waiting *days* to drop that one, weren't you :)
15:29:38  <bnoordhuis>not at all. just a flash of brilliant inspiration
15:30:00  <tjfontaine>heh
15:37:08  * dominictarrjoined
15:38:49  * appu_joined
15:39:15  * appu_quit (Client Quit)
15:44:40  * kazuponjoined
15:48:07  * hzquit
15:50:22  * kazuponquit (Ping timeout: 276 seconds)
15:55:11  * kazuponjoined
16:02:29  * timoxleyquit (Quit: Computer has gone to sleep.)
16:07:03  * dapjoined
16:08:17  * dapquit (Client Quit)
16:15:12  * arlolrajoined
16:19:22  * appu_joined
16:20:41  <piscisaureus_>waiting for days would have been very persistent
16:24:10  * amartensjoined
16:27:44  * pachetjoined
16:29:32  <tjfontaine>oh man
16:32:58  * bnoordhuisquit (Ping timeout: 246 seconds)
16:39:24  * mikealquit (Quit: Leaving.)
16:42:13  * loladirojoined
16:47:14  * AvianFluquit (Read error: Connection reset by peer)
16:47:48  * AvianFlujoined
16:48:27  * stagasjoined
16:54:08  * qardjoined
16:54:49  * TooTallNatejoined
16:55:36  * dsantiagoquit (Quit: Computer has gone to sleep.)
16:57:10  * csaohquit (Quit: csaoh)
17:08:46  * mikealjoined
17:12:52  * appu_quit (Quit: appu_)
17:30:39  * defunctzombie_zzchanged nick to defunctzombie
17:30:42  * defunctzombiequit (Changing host)
17:30:42  * defunctzombiejoined
17:39:00  * groundwaterjoined
18:01:00  * hzjoined
18:04:10  * stagas_joined
18:05:55  * stagasquit (Ping timeout: 264 seconds)
18:06:05  * stagas_changed nick to stagas
18:06:13  * stagasquit (Client Quit)
18:08:37  * bradleymeckjoined
18:08:59  * bradleymeckquit (Client Quit)
18:13:46  * kazuponquit (Remote host closed the connection)
18:14:14  * kazuponjoined
18:18:39  * kazuponquit (Ping timeout: 246 seconds)
18:25:33  * bajtosjoined
18:31:53  * bajtosquit (Ping timeout: 240 seconds)
18:44:18  * inolenquit (Quit: Leaving.)
18:56:28  * mikealquit (Quit: Leaving.)
19:02:23  * qardquit (Quit: Leaving.)
19:02:38  * mikealjoined
19:14:55  * kazuponjoined
19:16:51  * bnoordhuisjoined
19:19:33  * kazuponquit (Ping timeout: 248 seconds)
19:22:51  * defunctzombiechanged nick to defunctzombie_zz
19:23:08  * mikealquit (Quit: Leaving.)
19:26:15  * groundwaterquit (Quit: groundwater)
19:29:19  * mikealjoined
19:35:52  * joshthecoder_joined
19:36:52  * arlolra_joined
19:37:23  * arlolraquit (Read error: Connection reset by peer)
19:37:46  * qardjoined
19:39:04  * joshthecoderquit (Ping timeout: 248 seconds)
19:41:07  * rphillipsquit (Ping timeout: 248 seconds)
19:44:06  * rphillipsjoined
19:45:15  * dominictarr_joined
19:45:45  * kellabytequit (Ping timeout: 276 seconds)
19:45:59  * jmar777joined
19:46:02  * kellabytejoined
19:46:59  * philipsquit (Ping timeout: 276 seconds)
19:47:00  * MI6quit (Ping timeout: 276 seconds)
19:47:20  * MI6joined
19:47:45  * mikealquit (Quit: Leaving.)
19:48:16  * dominictarrquit (Ping timeout: 276 seconds)
19:48:17  * dominictarr_changed nick to dominictarr
19:52:26  * ircretaryquit (Ping timeout: 276 seconds)
19:54:11  * philipsjoined
20:10:08  * jmar777quit (Remote host closed the connection)
20:10:36  * jmar777joined
20:15:34  * jmar777quit (Ping timeout: 276 seconds)
20:15:43  * kazuponjoined
20:20:25  * kazuponquit (Ping timeout: 268 seconds)
20:32:58  <M28>why does libuv throw so many warnings in msvc when compiling for x64? :S
20:35:09  <tjfontaine>you mean
20:35:09  <tjfontaine>src\win\fs.c(1923): warning C4244: 'return' : conversion from 'ssize_t' to 'int', possible loss of data [g:\jenkins\workspace\libuv-v0.10-gyp\1d92f228\libuv.vcxproj]
20:35:31  <M28>many of those
20:35:42  <M28>also
20:35:43  <M28>1>src\win\pipe.c(869): warning C4244: 'function' : conversion from 'ULONG_PTR' to 'DWORD', possible loss of data
20:35:48  * groundwaterjoined
20:35:50  <tjfontaine>right
20:35:54  <tjfontaine>all the same basic thing though
20:36:06  <tjfontaine>I was just checking if you were seeing something different
20:37:23  <M28>so...
20:37:26  <M28>shouldn't it be fixed?
20:39:04  <tjfontaine>some of them are unavoidable, but you can feel free to submit PRs where appropriate
20:43:54  * kuplatup1uchanged nick to kuplatupsu
20:50:31  * mikealjoined
20:52:34  * `3rdEdenchanged nick to `3E|Zzz
20:53:34  * defunctzombie_zzchanged nick to defunctzombie
20:57:11  * mikealquit (Quit: Leaving.)
20:58:37  * mikealjoined
21:02:44  * mikealquit (Client Quit)
21:05:41  * rendarquit
21:08:30  * jmar777joined
21:16:16  * kazuponjoined
21:21:13  * kazuponquit (Ping timeout: 276 seconds)
21:22:47  * pachetquit (Ping timeout: 256 seconds)
21:30:50  * arlolrajoined
21:30:51  * arlolra_quit (Read error: Connection reset by peer)
21:33:16  * qardquit (Quit: Leaving.)
21:33:39  * qardjoined
21:37:23  * arlolraquit (Ping timeout: 240 seconds)
21:52:21  * mikealjoined
22:01:54  * mikealquit (Ping timeout: 264 seconds)
22:06:14  * dominictarrquit (Quit: dominictarr)
22:07:00  <trevnorris>bnoordhuis: hey dude, done anymore work on the 3.20 upgrade?
22:07:06  * kellabytequit (Changing host)
22:07:07  * kellabytejoined
22:08:06  <tjfontaine>[07-04] 15:27:00 < bnoordhuis> trevnorris: still working things out
22:08:06  <tjfontaine>[07-04] 15:27:39 < bnoordhuis> but i think i have, if you will forgive me the pun, a handle on it now
22:08:23  <trevnorris>tjfontaine: yeah. got that. :)
22:08:36  <tjfontaine>:P
22:11:28  <trevnorris>the puns were good. :)
22:11:43  <tjfontaine>don't encourage them :
22:11:45  <tjfontaine>er :)
22:16:57  * kazuponjoined
22:19:04  <trevnorris>you know, switching away from github's issue tracker sounds better everyday. I like their hosting, but man. the issue tracker doesn't work well for medium to large projects.
22:21:14  <tjfontaine>I'm not really even that fond of their hosting
22:21:43  * kazuponquit (Ping timeout: 256 seconds)
22:21:45  <trevnorris>heh
22:25:04  <trevnorris>wtf. where's ircretary?
22:27:15  <bnoordhuis>ai, v8 sure has become a lot more picky
22:27:42  <bnoordhuis>spent 30 minutes tracking down a segfault that turns out is a missing HandleScope::Close() in SetupProcessObject()
22:27:59  <trevnorris>whoa.
22:28:03  <tjfontaine>jeepers.
22:29:52  <trevnorris>bnoordhuis: if you get bored w/ that over the weekend mind giving this another quick review: https://github.com/joyent/node/pull/5747
22:30:07  <trevnorris>I force pushed since the change set is small
22:30:28  <bnoordhuis>ah, okay
22:30:40  <bnoordhuis>probably not tonight, pretty tired already
22:30:49  <trevnorris>heh, didn't expect it. :)
22:30:57  <trevnorris>i'm still wrapping my head around the changes in v8
22:31:35  <trevnorris>still can't see if there's a difference between "Persistent<>::New(Isolate*, ...)" and "Persistent<> val(Isolate*,...)"
22:32:27  <trevnorris>and github has been freakin slow today getting changes.
22:32:53  <bnoordhuis>trevnorris: Persistent<T>::New(...) is gone
22:33:16  <bnoordhuis>how it works now is that you create a Persistent and Reset() it
22:33:38  <bnoordhuis>then, when you need the object it points to, you do Local<Object>::New(isolate, persistent_handle)
22:33:48  <bnoordhuis>well, not persistent_handle, of course :-/
22:34:01  <bnoordhuis>(on account of it no longer being a handle)
22:34:07  <trevnorris>oy. and it seems Persistent's need to always be passed by reference
22:34:17  <trevnorris>because if you pass by value it will create another Persistent.
22:34:21  <bnoordhuis>yeah, they don't have a copy constructor anymore
22:37:12  <trevnorris>bnoordhuis: so what's up w/ the "Extremely evil" code in smalloc? no better way to grab the Local<> that the Persistent is pointing to?
22:39:08  <bnoordhuis>trevnorris: oh, i removed that already
22:39:16  <bnoordhuis>wait, let me push the latest and greatest
22:40:26  <trevnorris>awesome thanks.
22:40:33  <bnoordhuis>trevnorris: pushed
22:44:51  <trevnorris>bnoordhuis: cool. going to review that over the weekend. hopefully i'll understand it all by monday. :)
22:54:14  <bnoordhuis>[19:29|% 94|+ 538|- 28] and then the test runner dies... oh well, it's progress
22:56:16  * mikealjoined
22:59:42  * hzquit
23:14:47  * groundwaterquit (Quit: groundwater)
23:17:32  * kazuponjoined
23:22:43  * kazuponquit (Ping timeout: 264 seconds)
23:24:04  <bnoordhuis>[09:09|% 100|+ 578|- 18]: Done <- release build fares a little better
23:24:29  <tjfontaine>9 mins, so at least 1/2 of those failures are timeouts?
23:25:14  <bnoordhuis>yep
23:28:50  * mikealquit (Quit: Leaving.)
23:33:06  * mikealjoined
23:45:49  <bnoordhuis>trevnorris: ping
23:49:35  * st_lukejoined
23:55:55  <kellabyte>does libuv expose a cross platform way for getting date/time string? :P