00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:03:38  <mordy__>what do you know; it works :)
00:03:45  <mordy__>well, the casting to a char thing, that is
00:04:10  <mordy__>tjfontaine: is this any more helpful?
00:04:22  <mordy__>the culprit is the second "CAS: (H): <hex>"
00:05:06  <tjfontaine>it's not more helpful, without seeing it in context of the code
00:05:45  <mordy__>hrm..
00:05:52  <tjfontaine>not v8, but your plugin
00:05:56  <tjfontaine>*addon
00:11:20  <mordy__>alrighty; the actual object i'm trying to print is created here
00:11:34  <mordy__>(i'm using the _LP64 variant)
00:12:27  <mordy__>so the path for this is normally..:
00:12:48  <mordy__>https://github.com/mnunberg/couchnode/blob/master/src/cookie.cc
00:13:53  <mordy__>libcouchbase calls into one of the callbacks defined on the bottom of the file. each of those callbacks create a new ResponseInfo object on the stack, populating it with the relevant info
00:14:19  <tjfontaine>there's no External in that file
00:14:34  <mordy__>oh right
00:14:40  <mordy__>i didn't send the link for the External
00:14:54  <mordy__>https://github.com/mnunberg/couchnode/blob/master/src/cas.cc
00:15:52  <tjfontaine>that dereference is needed there? External::Cast(*obj)
00:16:20  <mordy__>tjfontaine: nope. i've changed it to obj.As<External>()->Value()
00:16:28  <mordy__>but that's not where it's crashing
00:16:34  <tjfontaine>k, I'm just looking through it
00:16:45  <mordy__>yeah. it's probably not your simplest node addon
00:18:03  <tjfontaine>oh I see, it's a slight abuse
00:19:09  <mordy__>actually.. let me check if things magically behave if i -DCOUCHNODE_NO_CASINTPTR
00:19:27  * bnoordhuisquit (Ping timeout: 240 seconds)
00:20:05  <tjfontaine>so you're creating things with out a handlescope because couchbase calls back in?
00:20:23  <mordy__>tjfontaine: so this is what i was explaining earlier
00:20:28  <mordy__>it has a handlescope
00:20:34  <mordy__>the ResponseInfo has a HandleScope member
00:20:39  <mordy__>and it's always the first thing created
00:20:52  <mordy__>it's a bit "clever" unfortunately.. but i hate boilerplate more than cleverness
00:21:05  <tjfontaine>until it's impossible to debug
00:21:20  <tjfontaine>anyway still reading
00:21:36  <tjfontaine>is libcouchbase single threaded?
00:21:50  <mordy__>yeah
00:21:57  <mordy__>it's not that clever actually
00:22:04  <mordy__>all the callback stuff is very simple from the C side
00:22:30  <mordy__>the *spooled stuff is broken
00:22:36  <mordy__>but that's not the path being followed anyway
00:24:21  <tjfontaine>I vote you recompile with --debug
00:24:24  * TooTallNatejoined
00:24:37  <tjfontaine>because that stack trace is basically useless, at least on that platform
00:25:26  <mordy__>hrm, and it works on the 32 bit variant
00:26:00  <tjfontaine>the 32bit is doing somethign significantly different, I wonder if it would behave better if you didn't abuse uint64_t as a pointer
00:26:16  <mordy__>tjfontaine: afaik nothing is reading from it
00:26:40  <mordy__>and the 'cas' value is never handled at the application level
00:26:49  <mordy__>it's just an opaque token sent to and from the network
00:26:53  <tjfontaine>like, do `uint64_t *v = new uint64_t; *v = cas; External::New(v)`
00:27:06  <tjfontaine>mordy__: but v8 may be expecting things to be aligned or whatever
00:27:27  * TooTallNatequit (Client Quit)
00:27:28  <mordy__>even for "External" data? hrm.
00:27:41  <mordy__>the 32 bit version abuses the cas as an 8 byte character array
00:27:53  <mordy__>via 'new'
00:28:39  <tjfontaine>yes, I'm not sure why you're using two different paths for this
00:28:50  <mordy__>hrm, let's see how it performs here
00:29:00  <mordy__>the thing is that the CAS is not really inspected by the application
00:29:46  <tjfontaine>also casDtor could just pass the pointer and avoid the GetIndexedProperties...
00:33:06  <mordy__>tjfontaine: in my benchmarks the 32 bit version performs a bit slower.. 21k/sec with External; 20k with Object
00:33:58  <mordy__>and for whatever reason, ends up using 65M of memory rather than 15M
00:34:56  <mordy__>but i can live with it
00:54:11  * TooTallNatejoined
01:17:26  * amartensquit (Quit: Leaving.)
02:01:51  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
02:08:19  * c4milojoined
02:09:34  * TooTallNatejoined
02:25:04  * julianduquejoined
03:15:14  * dominictarrjoined
03:27:09  * kazuponjoined
03:29:38  * mburnsquit (Ping timeout: 264 seconds)
03:47:16  * brsonjoined
03:55:49  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
04:06:51  * kazuponquit (Remote host closed the connection)
04:14:12  * ircretaryquit (Ping timeout: 276 seconds)
04:22:54  * c4miloquit (Remote host closed the connection)
04:28:26  * c4milojoined
04:48:20  * dominictarrquit (Quit: dominictarr)
04:52:16  * mburnsjoined
05:17:10  * mburnsquit (Read error: Connection reset by peer)
05:18:28  * mburnsjoined
05:23:00  * MI6quit (Remote host closed the connection)
05:23:12  * MI6joined
05:24:21  * jmar777joined
05:37:18  * jmar777quit (Remote host closed the connection)
05:53:28  * st_lukejoined
06:30:35  * mikealquit (Quit: Leaving.)
06:35:58  * mikealjoined
06:44:52  * groundwaterquit (Quit: groundwater)
06:47:52  <MI6>nodejs-v0.10-windows: #175 UNSTABLE windows-x64 (7/597) windows-ia32 (7/597) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/175/
06:51:22  * jmar777joined
06:54:50  * c4miloquit (Remote host closed the connection)
07:10:28  * st_lukequit (Remote host closed the connection)
07:11:06  * st_lukejoined
07:15:07  * st_lukequit (Ping timeout: 246 seconds)
07:16:34  * hzjoined
07:22:03  * st_lukejoined
07:37:14  * rendarjoined
07:50:04  * brsonquit (Quit: leaving)
07:52:21  * kazuponjoined
07:59:33  * st_lukequit (Remote host closed the connection)
08:00:12  * st_lukejoined
08:04:54  * st_lukequit (Ping timeout: 264 seconds)
08:04:57  * rendarquit
08:06:36  * rendarjoined
08:18:07  * jmar777quit (Remote host closed the connection)
08:18:59  * kazupon_joined
08:19:24  * kazuponquit (Read error: Connection reset by peer)
08:21:36  * jmar777joined
08:34:33  * jmar777quit (Remote host closed the connection)
08:39:23  * rendarquit (Ping timeout: 260 seconds)
08:57:33  * rendarjoined
09:06:41  * defunctzombiechanged nick to defunctzombie_zz
09:08:09  * dominictarrjoined
09:27:39  * roxlujoined
09:36:11  * kazupon_quit (Remote host closed the connection)
09:46:42  * rendar_joined
09:46:43  * bnoordhuisjoined
09:47:11  * Dasmylle1joined
09:47:50  * rendarquit (Ping timeout: 240 seconds)
09:48:37  * Dasmyllerquit (Ping timeout: 260 seconds)
09:53:03  * rendar_quit (Ping timeout: 245 seconds)
10:41:57  * kazuponjoined
10:45:04  <indutny>hello
10:48:27  <MI6>nodejs-v0.10: #1447 UNSTABLE osx-ia32 (1/597) smartos-x64 (2/597) http://jenkins.nodejs.org/job/nodejs-v0.10/1447/
10:56:37  <bnoordhuis>hello fedor
10:56:56  <bnoordhuis>api decision time
10:57:09  <bnoordhuis>libuv sets SO_REUSEPORT if available on udp sockets
10:57:31  <bnoordhuis>the thing is that linux >= 3.9 has that flag but it does something different from the BSDs
10:57:51  <bnoordhuis>on the bsds, it's basically SO_REUSEADDR but it also lets you steal the port
10:58:10  <bnoordhuis>on linux, it turns on fair load distribution
10:58:29  <bnoordhuis>iow, on the bsds, the last process to bind, gets all the traffic
10:58:45  <bnoordhuis>while on linux, all the processes get traffic
10:59:52  <bnoordhuis>i like the linux behavior but it's fundamentally different
11:00:08  <bnoordhuis>so i'm thinking we should stop setting SO_REUSEPORT on linux :-/
11:00:11  <bnoordhuis>opinions?
11:00:32  <bnoordhuis>indutny: ^
11:00:51  <indutny>щр
11:00:57  <indutny>oh
11:01:13  <indutny>hm...
11:01:29  <indutny>I think we might want to incorporate that in API
11:01:47  <indutny>or ship libuv with kernel modules
11:01:48  <indutny>:)
11:02:16  <indutny>I mean, that we probably can create an API that would make that differences irrelevant
11:02:23  <indutny>and invisible for users
11:02:29  <indutny>as we already do for many stuff on windows
11:13:02  <bnoordhuis>i'm not sure if my point is getting across :)
11:14:54  <bnoordhuis>the thing with SO_REUSEPORT is that your program will behave different on linux 3.8 vs 3.9
11:15:03  <bnoordhuis>to say nothing of the BSDs and solaris
11:15:37  * kazuponquit (Remote host closed the connection)
11:19:48  * kazuponjoined
11:24:47  * kazuponquit (Ping timeout: 240 seconds)
11:32:45  * kazuponjoined
11:35:33  * bnoordhuisquit (Ping timeout: 276 seconds)
11:40:27  * dominictarrquit (Ping timeout: 260 seconds)
11:47:44  * dominictarrjoined
11:58:48  * hzquit (Ping timeout: 256 seconds)
12:01:58  * kazuponquit (Remote host closed the connection)
12:23:00  * kazuponjoined
12:24:04  * kazuponquit (Read error: Connection reset by peer)
12:24:21  * kazuponjoined
12:30:41  * kazuponquit (Remote host closed the connection)
12:41:03  * bnoordhuisjoined
12:46:24  * bnoordhuisquit (Ping timeout: 276 seconds)
12:51:13  * kevinswiberjoined
13:08:38  * kevinswiberquit (Remote host closed the connection)
13:25:44  * pachet_joined
13:27:29  * kevinswiberjoined
13:27:31  * DrPizza_joined
13:28:20  * othiym23`joined
13:29:09  * jez0990_joined
13:29:24  * DrPizzaquit (Write error: Broken pipe)
13:29:26  * kuplatupsuquit (Write error: Broken pipe)
13:29:26  * Dasmylle1quit (Read error: Operation timed out)
13:29:27  * othiym23quit (Ping timeout: 240 seconds)
13:29:28  * jez0990quit (Read error: Operation timed out)
13:29:28  * pachetquit (Ping timeout: 240 seconds)
13:29:28  * Domenic_quit (Ping timeout: 240 seconds)
13:29:52  * Dasmyllerjoined
13:29:55  * kuplatupsujoined
14:05:24  * AvianFlujoined
14:39:11  * kazuponjoined
14:57:41  * kevinswiberquit (Remote host closed the connection)
15:19:58  * kazuponquit (Remote host closed the connection)
15:20:48  <MI6>nodejs-master: #478 UNSTABLE linux-ia32 (7/636) smartos-x64 (10/636) osx-ia32 (3/636) smartos-ia32 (3/636) osx-x64 (2/636) linux-x64 (2/636) http://jenkins.nodejs.org/job/nodejs-master/478/
15:26:54  * kazuponjoined
15:30:27  * rendarjoined
15:37:53  * Domenic_joined
15:39:12  * hzjoined
15:42:14  * kazuponquit (Ping timeout: 264 seconds)
15:46:27  * kazupon_joined
15:47:51  * kazupon_quit (Read error: Connection reset by peer)
15:48:33  * kazuponjoined
15:59:45  * kevinswiberjoined
16:27:12  * TooTallNatejoined
16:31:51  * bnoordhuisjoined
16:32:14  * kevinswiberquit (Remote host closed the connection)
16:41:53  <tjfontaine>bnoordhuis: if we don't set it by default, maybe we need an extra api for someone who might want to?
16:43:17  * kazupon_joined
16:45:38  * kazuponquit (Ping timeout: 241 seconds)
16:50:49  <MI6>joyent/node: Bert Belder master * 87405b0 : process_wrap: don't coerce process exit code to int32_t - http://git.io/aCZ_YA
16:50:58  * piscisaureus_joined
16:53:08  <piscisaureus_>bnoordhuis: https://github.com/andrewlow/node/blob/v0.10.16-release-ppc/deps/uv/src/unix/aix.c <-- you seen that?
16:53:40  <tjfontaine>I have a draft email about upstreaming those things
16:53:59  <tjfontaine>also about making their v8 branch a real fork from github.com/v8/v8
16:54:39  <piscisaureus_>the code looks clean although they didn't do the errno refactor so it seems
16:54:46  <tjfontaine>yup
16:54:56  <mordy__>hrm, does obj->Get() return Undefined if there isn't a value?
16:55:05  <tjfontaine>it's a pretty straight forward port
16:55:09  <tjfontaine>v8 aside
16:55:14  <piscisaureus_>mordy__: yes
16:55:33  <piscisaureus_>tjfontaine: yeah, v8 is only a minor nuisance huh :)
16:55:33  <mordy__>hrm
16:56:05  <tjfontaine>piscisaureus_: I mean that as a compliment to libuv :P (and the work that aprock... already did) :P
16:56:30  <tjfontaine>mordy__: you may want to also check IsEmpty()
16:57:35  <mordy__>tjfontaine: that's what i was doing before, but i realize now that IsEmpty never actually returns true
16:58:14  <tjfontaine>mk
16:59:24  <tjfontaine>http://jenkins.nodejs.org/queue/api/json I have scheduled just a few builds
16:59:27  <mordy__>http://paste.scsys.co.uk/266529
16:59:37  <tjfontaine>those have been running for just over 12 hours :)
16:59:54  <mordy__>i guess i can use 'Has' + 'Get'
17:00:15  <mordy__>or maybe something more contrived by just iterating over the property names
17:00:37  <piscisaureus_>mordy__: what do you want to check?
17:01:11  <piscisaureus_>mordy__: truthy-ness? Undefined?
17:02:48  <mordy__>piscisaureus_: in this case i have a bunch of "ParamSlot" objects, each of which define their own semantics of truthiness or undefinedness etc. etc. (and each of them has an implementation of a "parseValue" which applies these semantics
17:03:06  <mordy__>but i want the paramSlot to only execute if the item is in fact found within the objectg
17:04:02  <piscisaureus_>mordy__: so - you want 'in' or 'hasOwnProperty' semantics
17:04:21  <mordy__>ahh yes
17:04:21  <piscisaureus_>(besides - redefining truthiness and undefined-ness, man I dunno)
17:04:28  <piscisaureus_>mordy__: which one?
17:05:09  <piscisaureus_>mordy__: but in the latter case, you can just use obj->HasOwnProperty(String::New("myprop"))
17:05:21  <mordy__>piscisaureus_: 'in'. i'm not redfining truthiness
17:05:48  <piscisaureus_>mordy__: ah so you were lyning :-p
17:07:52  <mordy__>but, some options distinguish between a "Value" existing but being "Undefined", while some don't care
17:08:07  <piscisaureus_>mordy__: well, use IsUndefined() or HasRealNamedProperty()
17:08:32  <piscisaureus_>I'd suggest IsUndefined if you want to pretend an "explicit" undefined is equal to a property that doesn't exist
17:08:36  <mordy__>piscisaureus_: the concern is the impact of doing a ->Has[...]() and then doing a ->Get().. this is kind of a hot path
17:09:38  <piscisaureus_>actually, I said something dumb
17:09:54  <MI6>nodejs-master: #479 UNSTABLE linux-ia32 (1/636) smartos-x64 (15/636) osx-ia32 (2/636) smartos-ia32 (9/636) osx-x64 (1/636) linux-x64 (2/636) http://jenkins.nodejs.org/job/nodejs-master/479/
17:10:02  <mordy__>what about "GetRealNamedProperty" ?
17:10:04  <piscisaureus_>just use Get() and define semantics such that the lack of a property, and it being set to undefined, means the same
17:11:08  <piscisaureus_>mordy__: in that case you'd do:
17:11:09  <piscisaureus_>Local<Value> v = obj->GetRealNamedProperty(...);
17:11:09  <piscisaureus_>if (v->IsEmpty()) { not set } else { set }
17:11:21  <piscisaureus_>mordy__: IsEmpty() is very fast
17:12:44  <mordy__>hrm, GetRealNamedProperty seems nice
17:12:52  <mordy__>and it's made my thing faster too
17:13:41  * bnoordhuisquit (Ping timeout: 248 seconds)
17:14:06  <mordy__>yeah i found IsEmpty in the header. it just checks T.val_ == NULL
17:14:15  <mordy__>and it's inline blah blah
17:14:34  * mikealquit (Quit: Leaving.)
17:17:04  <mordy__>i've also just discovered ForceSet, which makes things even quicker, too
17:17:36  <MI6>nodejs-master-windows: #270 UNSTABLE windows-x64 (19/636) windows-ia32 (18/636) http://jenkins.nodejs.org/job/nodejs-master-windows/270/
17:17:57  * jmar777joined
17:17:57  <mordy__>btw, does v8 have a Number/Integer cache for small values?
17:18:05  <mordy__>something like NewSymbol, but for numbers
17:18:27  <tjfontaine>well it has SMI
17:22:52  <Domenic_>tjfontaine: sorry about @-mentioning you on that commit, I guess GitHub probably emails you every time I force-push huh.
17:23:38  <tjfontaine>heh ya, it's alright
17:23:46  <piscisaureus_>peepz
17:24:10  <mordy__>hrm, i couldn't find clear documentation on SMI but it seems it does some special integer to pointer mapping
17:24:51  <tjfontaine>mordy__: if it's small enough for your arch it will encode the immediate representation, otherwise you get a heapobject
17:24:51  <piscisaureus_>suppose I would do something like "execSync('mybinary', [], { stdio: [ { type: 'pipe', input: 'echo hello' }, 'pipe', 'pipe' ] })"
17:25:03  * pachet_quit (Quit: [ +++ ])
17:25:16  <piscisaureus_>... but mybinary would fail to to consume the input ('echo hello')
17:25:25  <piscisaureus_>so stdin blows up with EPIPE
17:25:36  <piscisaureus_>should execSync report success, or failure?
17:26:00  <tjfontaine>return a proper errno object?
17:26:15  <piscisaureus_>tjfontaine: well the result value for execSync would be something like
17:26:23  <mordy__>tjfontaine: hrm, you mean Value->val_ will contain the integer value rather than the heap object
17:26:35  <mordy__>which might explain why v8 is sensitive about pointers
17:26:38  <piscisaureus_>{
17:26:38  <piscisaureus_> exit_code: 0,
17:26:38  <piscisaureus_> term_sig: 0,
17:26:38  <piscisaureus_> stdout: 'foo',
17:26:38  <piscisaureus_> stderr: 'bar' }
17:26:53  <mordy__>since it does something more with val_ than treat it as a memory address
17:27:22  <tjfontaine>piscisaureus_: right, I think you could just have an error field
17:27:29  <piscisaureus_>tjfontaine: I don't really want to report a status for every individual pipe ...
17:27:47  <tjfontaine>no but the Error could report which pipe?
17:28:13  <tjfontaine>exit code will be non zero in this case,r ight?
17:28:23  <piscisaureus_>tjfontaine: that was my question :)
17:28:38  <piscisaureus_>tjfontaine: mybinary might not care. It could just succeed
17:28:43  <tjfontaine>so the question is if failing to read stdin when supplied is an error?
17:28:50  <piscisaureus_>yes
17:28:58  <piscisaureus_>e.g. people could spawn bash with
17:29:04  <piscisaureus_>"exit 0\necho hello"
17:29:31  <tjfontaine>stdin can only ever be a buffer/string and not a readable, right?
17:29:55  <piscisaureus_>tjfontaine: right now it can only be a buffer, although we can convert from strings in the binding layer.
17:30:02  <tjfontaine>nod
17:30:21  <tjfontaine>I don't think it should be an error
17:30:22  <piscisaureus_>tjfontaine: (it could be a wrap or an fd - that'd be technically a libuv api violation but it'd work)
17:30:32  <tjfontaine>will it have a timeout field for execSync?
17:30:44  <piscisaureus_>it doesn't have it - yet - but that's very doable
17:31:55  <tjfontaine>I'm leaning on the side of ignoring the stdin epipe
17:31:56  <MI6>joyent/node: piscisaureus created branch execSync-wip - http://git.io/euolTQ
17:32:09  <piscisaureus_>tjfontaine: I know I said it worked earlier, although I found many bugs later.
17:32:16  <tjfontaine>hehe
17:32:21  <piscisaureus_>tjfontaine: but there is the wip ^^
17:32:33  <tjfontaine>piscisaureus_: thanks!
17:32:42  * abraxasjoined
17:33:17  <tjfontaine>naughty 80 col violater ;) ben will be so disappointed
17:33:30  <piscisaureus_>first things first tj
17:33:50  <tjfontaine>hehe I'm just yankin your chain
17:34:14  <piscisaureus_>it also has printfs
17:35:01  * kazupon_quit (Ping timeout: 248 seconds)
17:35:47  <piscisaureus_>wait
17:35:52  <piscisaureus_>this isn't the final patch
17:35:59  <piscisaureus_>or ehm
17:36:03  <piscisaureus_>not even the one I am working on
17:36:40  <MI6>joyent/node: Bert Belder execSync-wip * 980bd6b : execSync spawnSync WIP - http://git.io/RWsY_g
17:36:45  <piscisaureus_>^-- tjfontaine: meilleur
17:37:06  * abraxasquit (Ping timeout: 245 seconds)
17:38:06  * kazuponjoined
17:40:03  <tjfontaine>piscisaureus_: so far everything makes sense
17:40:24  <MI6>node-review: #70 ABORTED http://jenkins.nodejs.org/job/node-review/70/
17:40:26  <piscisaureus_>conceptually it's very simple although it involves a lot of code
17:40:38  <tjfontaine>ya, the stdio helper class is nice
17:40:46  <piscisaureus_>because all the piping logic needs to be done in c++
17:40:50  <tjfontaine>yup
17:40:54  <piscisaureus_>there was no other way
17:41:06  <piscisaureus_>although actually I couldn't kill the process on stdio error right now
17:41:20  <piscisaureus_>because there is no way to look up the process object from the OnRead callback
17:41:37  <piscisaureus_>I have to add some sort of spawn_sync_context object for that
17:42:25  <tjfontaine>I'm exceedingly happy that we're likely to get this in for 0.12 :)
17:43:33  <piscisaureus_>tjfontaine: well who knows
17:43:49  <piscisaureus_>tjfontaine: I also have to come up with an user facing API for it
17:43:57  <piscisaureus_>which involves a lot of arbirary choices
17:44:35  <tjfontaine>nod
17:44:46  <piscisaureus_>e.g. will execSync throw if the process returns nonzero like .exec ?
17:44:46  <tjfontaine>but I'm sure we can all come to a reasonable set of features
17:45:07  <tjfontaine>since we have a state object being returned I don't think throwing will be necessary
17:45:08  <piscisaureus_>I fear some pain in this area. our current child process apis are kind of wonky in some regards
17:45:31  <piscisaureus_>tjfontaine: well - that'd break consistency
17:45:44  * mikealjoined
17:46:01  <piscisaureus_>you'd expect the synchronous version of a function to throw when the async version drops an error
17:46:23  <piscisaureus_>we could also do a low-level spawnSync but spawnSync is a weird name
17:46:23  <tjfontaine>but those don't return complex objects generally
17:46:49  <piscisaureus_>maybe execSync should just get a string back?
17:46:56  <piscisaureus_>that'd be good enough for most cases
17:48:39  <piscisaureus_>question is if we'd want to merge stdout and stderr or report separately
17:48:57  <piscisaureus_>or maybe even hide stderr except in case of an error, and add it to the error object
17:49:00  <piscisaureus_>ok - time out-
17:49:12  <tjfontaine>well, spawnSync could return the complex I guess, separated out, and execSync could return stdout and throw on non-zero
17:50:59  * kevinswiberjoined
17:52:58  <tjfontaine>var e = new Error(whatWentWrong); e.state = spawnSyncResult; seems reasonable, or util._extend(e, spawnSyncResult)
17:53:47  * piscisaureus_quit (Ping timeout: 260 seconds)
17:58:51  * kevinswiberquit (Remote host closed the connection)
18:05:18  * hzquit
18:05:49  * mikealquit (Quit: Leaving.)
18:06:06  * mikealjoined
18:10:10  * pachetjoined
18:10:54  <MI6>node-review: #71 FAILURE windows-x64 (21/636) windows-ia32 (22/636) http://jenkins.nodejs.org/job/node-review/71/
18:11:29  * piscisaureus_joined
18:12:14  <piscisaureus_>tjfontaine: yeah, that'd work
18:12:54  <piscisaureus_>tjfontaine: or we could add a simple 'stderr' option which would take 'merge', 'inherit' to override default behaviour
18:13:20  <piscisaureus_>ideally whatever we do should be back-applicable to the async version
18:15:53  <tjfontaine>indeed
18:20:10  <MI6>libuv-master: #193 FAILURE windows (3/193) http://jenkins.nodejs.org/job/libuv-master/193/
18:20:17  <tjfontaine>er
18:20:33  <tjfontaine>oh, just jenkins/java NPE again
18:21:07  * mikealquit (Quit: Leaving.)
18:22:02  * mikealjoined
18:26:08  * mikealquit (Client Quit)
18:26:29  * mikealjoined
18:30:36  * mikealquit (Client Quit)
18:30:50  * mikealjoined
18:36:28  * kazuponquit (Remote host closed the connection)
18:36:41  * mikealquit (Quit: Leaving.)
18:36:58  * mikealjoined
18:40:05  * jmar777quit (Remote host closed the connection)
18:48:11  <MI6>nodejs-master-windows: #271 UNSTABLE windows-x64 (20/636) windows-ia32 (18/636) http://jenkins.nodejs.org/job/nodejs-master-windows/271/
19:01:26  * leonvvjoined
19:03:07  * c4milojoined
19:06:30  <piscisaureus_>in c++, what happens if exceptions are disabled and `operator new` fails because of OOM ?
19:07:04  <tjfontaine>aren't you supposed to use nothrow?
19:07:15  * bnoordhuisjoined
19:07:53  <piscisaureus_>well - we're compiling with exceptions disabled right?
19:07:56  <tjfontaine>yes
19:08:01  * AvianFluquit (Remote host closed the connection)
19:08:11  <tjfontaine>if I took a guess I'd say null pointer
19:08:11  <piscisaureus_>so what happens on out of memory
19:08:12  <piscisaureus_>e.g.
19:08:15  <tjfontaine>but maybe abort()
19:08:27  <piscisaureus_>char* bar = new char[230948]
19:08:37  <piscisaureus_>will bar be NULL like in c ?
19:08:56  <tjfontaine>http://stackoverflow.com/questions/6049563/with-fno-exceptions-what-happens-with-new-t
19:10:52  <tjfontaine>so you can still throw, but the unwinding code is different it seems
19:11:33  * leonvvquit (Remote host closed the connection)
19:11:59  <piscisaureus_>so what is a good pattern for dealing with this?
19:12:17  <piscisaureus_>Constructor() {
19:12:17  <piscisaureus_> bar_ = new char[1234];
19:12:17  <piscisaureus_> baz_ = new int[12345];
19:12:17  <piscisaureus_>}
19:12:30  <tjfontaine>I think if you're worried about it you're supposed to use (nothrow)
19:12:31  <piscisaureus_>maybe I should take a c++ class
19:12:41  <piscisaureus_>what do I include to be able to use that?
19:13:09  <tjfontaine><new>
19:13:33  <piscisaureus_>thanks tjfontaine
19:13:36  <piscisaureus_>you saved my day
19:13:38  <tjfontaine>yw
19:13:46  <bnoordhuis>piscisaureus_: OOM with -fno-exceptions will simply abort
19:14:08  <bnoordhuis>"terminate the runtime" if you want to be pedantic
19:14:51  <bnoordhuis>if you want to handle OOM, use something like v8's Malloced class
19:15:08  <piscisaureus_>it's not that I actually care
19:15:14  <MI6>joyent/libuv: Ben Noordhuis master * 9bf9edd : linux: don't turn on SO_REUSEPORT socket option - http://git.io/BABuHw
19:15:20  <piscisaureus_>I just want to know how it would be done if I did
19:15:30  <bnoordhuis>well, like that :)
19:16:01  <bnoordhuis>the way v8 does it is by having classes inherit from a base class that does malloc() + placement new
19:16:10  <bnoordhuis>if malloc fails, it returns NULL instead
19:16:25  <bnoordhuis>meaning you have to check new Foo() for NULL-ness
19:16:26  <piscisaureus_>so that's basically what you'd get from (nothrow) as well right
19:17:20  <piscisaureus_>bnoordhuis: but I'll just move all that to the Initialize() function
19:17:32  <piscisaureus_>whateva
19:18:49  <bnoordhuis>piscisaureus_: yes, std::nothrow does pretty much the same thing
19:19:04  <bnoordhuis>i've never actually seen that used in real code however :)
19:19:22  <tjfontaine>haha
19:23:15  <MI6>libuv-master-gyp: #132 UNSTABLE windows-x64 (3/193) windows-ia32 (4/193) smartos-ia32 (4/192) linux-x64 (1/192) linux-ia32 (2/192) smartos-x64 (3/192) http://jenkins.nodejs.org/job/libuv-master-gyp/132/
19:25:34  <MI6>libuv-master: #194 UNSTABLE linux (1/192) windows (4/193) smartos (11/192) http://jenkins.nodejs.org/job/libuv-master/194/
19:27:36  <piscisaureus_>why are you all working on sunday
19:28:03  <piscisaureus_>I am outta here!
19:28:38  <piscisaureus_>I have a girlfriend to please.
19:28:46  <piscisaureus_>Ben's girlfriend, that is.
19:28:49  <piscisaureus_>\o
19:29:06  <tjfontaine>hehe
19:29:09  <tjfontaine>later bert
19:33:25  * piscisaureus_quit (Ping timeout: 248 seconds)
19:39:17  <MI6>joyent/libuv: Ben Noordhuis master * 9d60f1e : linux: don't turn on SO_REUSEPORT socket option - http://git.io/RpTZMg
19:39:29  <bnoordhuis>(yes, i force-pushed - updated a comment)
19:43:29  <kellabyte>bnoordhuis: is there a libuv API for thread local storage? I need to store something on a per thread basis
19:44:01  <bnoordhuis>kellabyte: not at the moment. i've thought about adding one
19:45:49  <kellabyte>bnoordhuis: yeah. I need to have a cache of something per thread, I don't want to lock a shared resource
19:47:08  <bnoordhuis>kellabyte: if you open an issue, we can look into it. will be something of a medium-term project though
19:47:16  <bnoordhuis>unless you volunteer to implement it, of course :)
19:47:33  <bnoordhuis>shouldn't be that hard, i think
19:47:49  <bnoordhuis>on unices, you can wrap the relevant pthread functions
19:47:53  <kellabyte>bnoordhuis: ok, I'll take a stab at it but not that great at C yet, super noob still lol
19:48:25  <bnoordhuis>oh, don't worry. that's what code reviews are for
19:49:23  <kellabyte>ok I'll see what I can come up with, I'll log the issue now first
19:49:59  <MI6>libuv-master: #195 UNSTABLE linux (2/192) windows (3/193) smartos (10/192) http://jenkins.nodejs.org/job/libuv-master/195/
19:52:23  <MI6>libuv-master-gyp: #133 UNSTABLE windows-x64 (4/193) windows-ia32 (3/193) smartos-ia32 (4/192) linux-x64 (2/192) linux-ia32 (1/192) smartos-x64 (2/192) http://jenkins.nodejs.org/job/libuv-master-gyp/133/
19:54:11  * Brett19quit (Ping timeout: 245 seconds)
20:00:45  <MI6>joyent/libuv: Ben Noordhuis master * d3308c2 : include: update uv_udp_open() / uv_udp_bind() docs - http://git.io/vU3u5A
20:00:59  <MI6>libuv-node-integration: #179 FAILURE smartos-ia32 (10/636) linux-x64 (4/636) linux-ia32 (4/636) http://jenkins.nodejs.org/job/libuv-node-integration/179/
20:01:46  <tjfontaine>oh that's the force push failure
20:13:42  <MI6>libuv-master-gyp: #134 UNSTABLE windows-x64 (3/193) windows-ia32 (3/193) smartos-ia32 (4/192) linux-ia32 (2/192) smartos-x64 (2/192) http://jenkins.nodejs.org/job/libuv-master-gyp/134/
20:15:05  <MI6>libuv-master: #196 UNSTABLE linux (2/192) windows (3/193) smartos (10/192) http://jenkins.nodejs.org/job/libuv-master/196/
20:17:13  * pachetquit (Ping timeout: 245 seconds)
20:26:28  * mikealquit (Quit: Leaving.)
20:37:23  * ryahquit (Quit: Lost terminal)
20:44:35  <MI6>libuv-node-integration: #180 UNSTABLE smartos-x64 (12/636) smartos-ia32 (9/636) linux-x64 (3/636) linux-ia32 (2/636) http://jenkins.nodejs.org/job/libuv-node-integration/180/
20:55:21  * Brett19joined
21:02:19  * Brett19quit (Ping timeout: 264 seconds)
21:02:38  * pachetjoined
21:02:51  * Brett19joined
21:03:02  * pachetchanged nick to Guest42317
21:10:37  * c4miloquit (Remote host closed the connection)
21:13:27  <bnoordhuis>kellabyte: are you a windows user? if yes, feel like being a guinea pig for https://github.com/joyent/libuv/pull/906 ?
21:13:40  * c4milojoined
21:22:46  * brsonjoined
21:23:57  * kenperkinsjoined
21:31:44  <MI6>libuv-node-integration: #181 UNSTABLE smartos-x64 (11/636) smartos-ia32 (10/636) osx-ia32 (2/636) linux-x64 (4/636) linux-ia32 (4/636) http://jenkins.nodejs.org/job/libuv-node-integration/181/
21:36:11  * kenperkinsquit (Quit: Computer has gone to sleep.)
21:48:34  * AvianFlujoined
21:49:34  * AvianFluquit (Remote host closed the connection)
21:49:38  * rendarquit (Quit: Leaving)
21:54:23  * st_lukejoined
22:01:24  * Domenic_changed nick to Domenic
22:01:33  * Domenicchanged nick to Domenic_
22:15:01  <kellabyte>bnoordhuis: jesus! did you just implement that now? lol
22:21:13  <kellabyte>buffer 5
22:22:11  <bnoordhuis>^ vi user
22:22:17  <kellabyte>lol
22:23:04  <kellabyte>checking out the checkin for learning
22:24:55  <kellabyte>any reason why you set NULL as the destructor argument to pthread_key_create()? I thought you might have to provide a callback or something so people can free memory?
22:26:45  <bnoordhuis>kellabyte: the destructor is purely optional on posix platforms and i don't know of a way to emulate it on windows
22:27:40  <kellabyte>bnoordhuis: ah gotcha. so how does someone free the memory and avoid a leak?
22:28:00  <bnoordhuis>kellabyte: by calling uv_key_delete() :)
22:28:30  <bnoordhuis>or if you mean 'how do i do that on a per-thread basis?'
22:28:49  <bnoordhuis>by cleaning up manually before the thread exits
22:28:51  <kellabyte>yeah, like in pthreads the destructor is called when the thread is going to exit I believe to free all the TLS
22:32:16  * TooTallNatequit (Quit: Computer has gone to sleep.)
22:35:54  * jmar777joined
22:35:58  <kellabyte>bnoordhuis: I'll try this out though and let you know! thanks so much :)
22:36:41  <bnoordhuis>no problem :)
22:37:53  <kellabyte>how long have you been writing C for?
22:50:08  * st_lukequit (Remote host closed the connection)
22:50:29  * jmar777quit (Remote host closed the connection)
22:50:50  * st_lukejoined
22:51:52  * jmar777joined
22:53:22  * st_lukequit (Remote host closed the connection)
22:57:18  * dominictarrquit (Quit: dominictarr)
23:00:45  * c4miloquit (Remote host closed the connection)
23:09:25  * jmar777quit (Remote host closed the connection)
23:21:42  * TooTallNatejoined
23:22:45  * c4milojoined
23:33:43  * jmar777joined
23:34:03  <bnoordhuis>kellabyte: over 15 years now, i think?
23:34:24  <bnoordhuis>oh, 1.30 am - guess i should be getting to bed
23:34:34  <bnoordhuis>have a good night everyone
23:37:27  * jmar777quit (Remote host closed the connection)
23:39:06  * bnoordhuisquit (Ping timeout: 264 seconds)
23:39:19  * c4miloquit (Remote host closed the connection)
23:50:58  * c4milojoined