00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:02  <trevnorris>TooTallNate: ok, back to the first question :)
00:00:11  * ircretaryjoined
00:00:40  <tjfontaine>trevnorris: consider a stream transform that wants to keep a buffer around, but another stream that has decided they're done consuming the data and want to make the world go fast
00:01:13  <trevnorris>the use case i'm thinking of is like mozilla or walmart. when using node as a data router. opening the pipe is really helpful.
00:01:44  <tjfontaine>right I get how there are people who might want it, but I'm asking about what happens when we export it from core
00:01:52  <tjfontaine>also another question
00:01:53  <trevnorris>tjfontaine: oh yeah. there are definitely those cases. but not dis-similar to running .end() on a socket or something that's being used in multiple locations, imo.
00:02:09  <tjfontaine>what happens if I .slice() but someone else .dispose()'s the parent?
00:04:11  * jmar777joined
00:07:49  <trevnorris>tjfontaine: you can't dispose the parent, technically, since the parent is a transparent backer that devs shouldn't touch.
00:08:10  <trevnorris>well. give me a minute.
00:08:20  <tjfontaine>trevnorris: no, consider someone who gets a buffer slice()'s, then someone else gets the buffer parent and .dispose()'s
00:09:59  <trevnorris>tjfontaine: all Buffer's are backed by a transparent smalloc layer. the .parent now doesn't point to the buffer instance but the smalloc allocation.
00:10:16  <trevnorris>let me write up a test.
00:12:22  <tjfontaine>var b = new Buffer(1024); var c = b.slice(10; b.dispose();
00:12:28  <tjfontaine>c.parent doesn't point to the original?
00:14:04  <MI6>joyent/node: Timothy J Fontaine master * 2fc34d7 : tls_wrap: return Error not throw for missing cert - http://git.io/tg7uog
00:14:38  <trevnorris>tjfontaine: https://gist.github.com/trevnorris/5953621
00:15:15  <tjfontaine>that is bizarre, but ok I guess
00:15:33  <tjfontaine>what is .parent for c at L:14?
00:15:42  <tjfontaine><Buffer> then?
00:16:00  <trevnorris>.parent will point to the bare smalloc object.
00:16:06  <trevnorris>not an actual buffer instance.
00:17:57  * qardquit (Quit: Leaving.)
00:18:23  <trevnorris>tjfontaine: heading home, but you have me all worried now :P going to check it out tonight
00:18:43  <tjfontaine>trevnorris: hehe
00:19:15  <tjfontaine>trevnorris: these are the scenarios I worry about though, basically people holding pieces that the person .dispose()ing didn't realize
00:19:49  * amartensquit (Quit: Leaving.)
00:19:53  <tjfontaine>trevnorris: and then even if that's relatively safe, what are the semantics of adjust external memory and the underlying free() for all the various slices that can happen
00:21:28  <MI6>nodejs-master-windows: #102 FAILURE http://jenkins.nodejs.org/job/nodejs-master-windows/102/
00:23:40  * piscisaureus_quit (Ping timeout: 268 seconds)
00:25:58  <MI6>nodejs-master: #295 UNSTABLE smartos-x64 (10/608) linux-x64 (2/608) osx-ia32 (2/608) smartos-ia32 (2/608) linux-ia32 (1/608) osx-x64 (1/608) http://jenkins.nodejs.org/job/nodejs-master/295/
00:31:02  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:41:10  * kazuponquit (Remote host closed the connection)
00:41:38  * kazuponjoined
00:41:52  * kazuponquit (Read error: Connection reset by peer)
00:42:00  * wavdedjoined
00:42:17  * kazuponjoined
00:42:32  * kazuponquit (Remote host closed the connection)
00:42:52  * qardjoined
00:43:00  * kazuponjoined
00:44:01  * jmar777quit (Remote host closed the connection)
00:44:32  * jmar777joined
00:47:36  * kazuponquit (Ping timeout: 256 seconds)
00:48:19  * timoxleyquit (Quit: Computer has gone to sleep.)
00:48:46  * jmar777quit (Ping timeout: 240 seconds)
00:50:44  * wavdedquit (Quit: Nighty night)
00:52:05  <MI6>nodejs-master-windows: #103 FAILURE http://jenkins.nodejs.org/job/nodejs-master-windows/103/
00:54:38  * TooTallNatejoined
00:54:42  * dapquit (Quit: Leaving.)
00:58:25  <MI6>nodejs-master: #296 UNSTABLE smartos-x64 (8/608) linux-x64 (1/608) smartos-ia32 (2/608) http://jenkins.nodejs.org/job/nodejs-master/296/
00:59:21  * defunctzombie_zzchanged nick to defunctzombie
01:08:33  <TooTallNate>tjfontaine: ping
01:10:13  * timoxleyjoined
01:11:07  * abraxasjoined
01:14:10  * amartensjoined
01:26:07  * TooTallNatequit (Quit: Computer has gone to sleep.)
01:29:44  * wavdedjoined
01:40:45  * wavdedquit (Quit: Nighty night)
01:44:47  * mikealquit (Quit: Leaving.)
01:45:14  * dannycoatesquit (Remote host closed the connection)
01:53:35  * kazuponjoined
01:58:16  * brsonquit (Ping timeout: 240 seconds)
01:58:38  * kazuponquit (Ping timeout: 268 seconds)
02:02:50  * c4milojoined
02:09:25  * c4miloquit (Remote host closed the connection)
02:09:46  * defunctzombiechanged nick to defunctzombie_zz
02:17:53  * TooTallNatejoined
02:22:38  * piscisaureus_joined
02:30:34  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
02:31:48  <isaacs>trevnorris: sorry i wasn't around. yes, land dispose() stuff. looks good.
02:33:05  <isaacs>tjfontaine: doing http-better as a module is kind of turning into a much bigger job than i'd like.
02:33:13  <isaacs>this is sorta nuts.
02:33:21  <isaacs>http is so interwoven into net and http_parser.
02:34:02  * jmar777joined
02:34:58  <isaacs>tjfontaine: we can do a 0.11 tomorrow also, if you want
02:35:19  <isaacs>maybe start with that one, since it's a little bit less hazardous if it gets messed up :)
02:39:19  <isaacs>tjfontaine: I just forwarded you the GlobalSign cert and instructions. this has to be done on windows, using MSIE.
02:39:34  <trevnorris>isaacs: you're tellin me. I just started w/ the http patch to buffer the headers in cc before sending them off to http_parser
02:40:22  <tjfontaine>isaacs: right
02:41:50  <tjfontaine>TooTallNate: pong btw
02:41:57  <TooTallNate>tjfontaine: haha
02:41:58  <TooTallNate>tjfontaine: nvm
02:42:00  <tjfontaine>mk
02:42:10  <TooTallNate>tjfontaine: i was trying to figure out why a http proxy wasn't speaking ssl to me
02:42:17  <TooTallNate>turns out... it just doesn't speak ssl
02:42:18  <TooTallNate>hahah
02:42:26  <TooTallNate>tjfontaine: finding an open HTTPS proxy is hard :\
02:42:36  <tjfontaine>TooTallNate: that's a GoodThing(tm) :P
02:42:43  <TooTallNate>hahaha
02:42:44  <TooTallNate>true
02:42:47  <trevnorris>isaacs: oh, and i'll assume you meant the dispose bug fix. not the Buffer#dispose() patch :)
02:42:54  <tjfontaine>TooTallNate: I say this as an irc administrator :P
02:43:02  <tjfontaine>trevnorris: that's what I assume as well :)
02:43:03  <isaacs>trevnorris: oh, right
02:43:08  <isaacs>trevnorris: whatever you were gonna land at 4 :)
02:43:14  <trevnorris>heh
02:43:57  <trevnorris>tjfontaine has me all paranoid that I missed something. writing a bunch of tests right now :P
02:44:49  <tjfontaine>the better your user module will be :P
02:45:12  <trevnorris>lol
02:45:57  <isaacs>TooTallNate: so, re your comment: https://github.com/joyent/node/pull/5615#discussion_r5075145
02:46:27  <isaacs>TooTallNate: i guess if someone does http.get({socketPath: '/foo', agent:false}), then, well, it'll break
02:46:44  <isaacs>TooTallNate: but even then, if you do agent:false, it creates a new agent.
02:46:54  <isaacs>TooTallNate: i think this is *only* for the legacy (like, pre-0.6) api
02:51:28  <trevnorris>tjfontaine: ah, there we go. took a bit but managed to get a double link list corruption.
02:51:38  <TooTallNate>isaacs: ok, i ask because, from what i can tell, the only "public api" for Agent was .addRequest() before and a few events
02:51:49  <tjfontaine>trevnorris: under which scenario?
02:51:50  <TooTallNate>isaacs: but after that commit, agent.createConnection() is called directly
02:51:57  <TooTallNate>isaacs: which i kinda don't like :p
02:52:16  <isaacs>TooTallNate: well... request does some dirty shit;
02:52:21  <isaacs>TooTallNate: as in, mikeal's request module.
02:52:32  <trevnorris>tjfontaine: this finally did it: https://gist.github.com/trevnorris/5953621
02:52:39  <tjfontaine>isaacs: btw, if better-agent as it is too painful, I may just make a ref-agent separately
02:52:43  <isaacs>TooTallNate: it relies on the agent.addRequest({ createConnection: someRandomFunction })
02:53:46  * wavdedjoined
02:53:47  <trevnorris>tjfontaine: heh, but I have a way around this ;)
02:53:54  <tjfontaine>trevnorris: oh c and d are initially slices of b
02:54:00  <trevnorris>yeah
02:54:16  <trevnorris>my first mistake was to forget that small Buffer are already part of a slice.
02:54:27  <tjfontaine>right
02:54:28  <trevnorris>and it treats slices differently than their parents
02:55:09  <trevnorris>ok. give me a minute to patch this
02:55:18  <tjfontaine>trevnorris: if I create a buffer with a cb, someone slices that and holds that reference, and then I dispose the original buffer, what happens?
02:56:13  <trevnorris>tjfontaine: right now a double linked list corruption if they try to access the slice afterwards. but have an idea.
02:56:33  * loladirojoined
02:56:55  <trevnorris>there are two things I can do. either when the parent is disposed zero out all the slices so they're all zero length
02:57:30  <trevnorris>or I can continue holding onto the memory until all slices are gone then free the memory
02:57:36  <trevnorris>tjfontaine: what would be your preference?
02:57:42  <TooTallNate>isaacs: that's fine
02:57:43  <tjfontaine>the latter
02:57:52  <trevnorris>cool. that's the easier solution.
02:58:01  <tjfontaine>because you're asking to free this memory as soon as I know it's truly free
02:58:02  * wavdedquit (Client Quit)
02:58:30  <trevnorris>true. ok cool.
02:58:31  <tjfontaine>fwiw, any and all of dispose should work that way
02:58:45  <TooTallNate>isaacs: but .addRequest() calls .createConnection()
02:59:02  <tjfontaine>trevnorris: "dear v8, I want to get rid of this memory asafp, but don't screw up anyone trying to use it now"
02:59:02  <TooTallNate>isaacs: so usually 'http' module would just call the custom createConnection through .addRequest()
02:59:09  <TooTallNate>which is what i want to maintain :)
02:59:16  <trevnorris>heh, ok
02:59:47  <creationix>tjfontaine, just saw your email about a new API for addons
03:00:35  <creationix>I'm here to help where I can, though my background is a scripter, not a C/C++ programmer
03:00:38  <tjfontaine>creationix: as I just saw yours :)
03:01:34  <tjfontaine>creationix: so SM/JSAPI is more of a guideline of how straight forward I think the API should be, and we're in agreement that it should be C
03:01:47  <creationix>have you seen the lua API?
03:02:01  <creationix>the languages are close enough in semantics, it could probably be adapted easily
03:02:04  <tjfontaine>briefly, I have spent more time with ruby and python binding interfaces
03:02:39  <creationix>the one nice *and* annoying thing about the lua API is that you *never* get pointers to objects
03:02:43  * timoxleyquit (Quit: Computer has gone to sleep.)
03:02:44  <tjfontaine>right
03:03:18  <tjfontaine>contrast that to ruby, where everything is a pointer stuck a VALUE, or well until we lied and made it an SMI
03:03:28  <tjfontaine>*stuck in a VALUE
03:03:38  <creationix>haven't done ruby bindings yet
03:03:40  <creationix>but I can imagine
03:03:50  <trevnorris>tjfontaine: now, Buffer.alloc and Buffer.dispose are safe because there's no supported API to create a slice from those.
03:03:57  <trevnorris>(just fyi)
03:04:12  <tjfontaine>trevnorris: these are the "attach to any random object some external memory" functions?
03:04:59  <trevnorris>tjfontaine: basically. i'm using them to quickly attach memory to functions when I want to share stateful flags between js and cc apis
03:05:27  * st_lukequit (Remote host closed the connection)
03:05:31  <tjfontaine>right, I kinda wish we had a better scope to stick those on, instead of Buffer, they're related up until they're not
03:05:34  <trevnorris>like what I did w/ the ticker to determine if there are any more functions in the nextTickQueue
03:05:42  <trevnorris>heh yeah.
03:05:52  <trevnorris>well, it'd be trivial to throw in a require('smalloc');
03:05:53  <creationix>tjfontaine, the one thing I hated when doing sm bindings for libuv was the JS_Class interface
03:06:07  <trevnorris>had that at first, but removed it since it was depressingly small.
03:06:10  <tjfontaine>creationix: you mean having to fill out the structures?
03:06:18  <creationix>right, and the fields you had to fill out
03:06:24  <creationix>it wasn't javascript semantics at all
03:06:27  <tjfontaine>trevnorris: right but it's easier to identify for fools like me
03:06:28  <creationix>it was something else entirely
03:06:28  <trevnorris>tjfontaine: but that would actually make more sense, since the cc api is smalloc::Alloc
03:06:33  <TooTallNate>isaacs: tjfontaine so this basically works now https://gist.github.com/TooTallNate/5952254
03:06:52  <trevnorris>tjfontaine: ok. i'll throw up a PR to move those over to their own require()
03:07:08  <tjfontaine>creationix: well, right they're kinda similar, but if you're not used to writing bindings for things like python/ruby it will seem very foreign indeed
03:07:10  <trevnorris>then the entire thing can be labeled as experimental
03:07:23  <TooTallNate>isaacs: also, you'll see why i want to keep agent.createConnection() an internal API (not called by _http_client.js)... cause I changed the signature to async
03:07:41  <tjfontaine>creationix: I would be interested to see what your ideal interface would be, so if you get time reply to the thread with a 10mile overview that'd be great
03:07:48  <isaacs>TooTallNate: wait, what?
03:07:57  <creationix>tjfontaine, any guidelines to what I should support?
03:08:04  <creationix>tjfontaine, in the proposed api
03:08:14  <trevnorris>creationix: all the thingz ;)
03:08:14  <tjfontaine>trevnorris: thanks, I'm not really that worried about those, more worried about confusion
03:08:33  <tjfontaine>creationix: well, I guess what is the api you would see yourself wanting if you were to write a new node module
03:08:35  <creationix>tjfontaine, is a lua style interface with stack positions instead of pointers out of the question?
03:08:40  <TooTallNate>isaacs: in my gist https://gist.github.com/TooTallNate/5952254
03:08:53  <TooTallNate>isaacs: that implements HTTP and HTTPS ProxyAgent classes
03:08:59  <TooTallNate>to use with node-core "http" module
03:09:04  <TooTallNate>it's pretty cool actually :D
03:09:15  <tjfontaine>creationix: not entirely, it's not a direction I was thinking of going, but it's good to think about
03:09:35  <isaacs>TooTallNate: oh, nice
03:09:37  <trevnorris>creationix: honestly I'd start by looking at what is most commonly used (e.g. node-leveldown, node-ffi, etc). imo that would lead to quicker community testing.
03:09:42  <TooTallNate>isaacs: so those are implemented based off the assumption that agent.addRequest() is the only "public" API of Agent
03:09:50  <isaacs>TooTallNate: i see.
03:09:59  <creationix>I remember not hating the V8 api
03:10:10  <creationix>other than being C++ it was accecptable to me
03:10:20  <creationix>I really liked candor's API though (I helped design that one)
03:10:21  <TooTallNate>isaacs: with your PR though, you're invoking agent.createConnection()... but frankly it's probably fine since it's in an if branch i don't think i'll hit
03:10:36  <tjfontaine>right, it's not that the v8 api is bad, it's just that more often than not C++ can feel like its getting in your way, but a C api will by nature be more verbose
03:10:37  <TooTallNate>isaacs: i guess i should just pull your code and try my agents :p
03:10:57  <isaacs>TooTallNate: hm, yeah, that'd be good :)
03:11:25  <isaacs>TooTallNate: also, i think you can either overwrite the addRequest, or overwrite createConnection and getName
03:11:45  <isaacs>TooTallNate: for example, if you do a https-over-http tunneling agent, then you need to just override the createConnection stuff
03:13:02  * timoxleyjoined
03:13:24  <TooTallNate>isaacs: well the thing is... https-over-https is harder, since the socket needs to wait for the CONNECT http method response from the proxy server
03:13:40  <TooTallNate>isaacs: hence me making my agents' .createConnection() fn async
03:14:04  <isaacs>right
03:14:21  <isaacs>right now, createConnection creates a socket, then you get an onSocket() function called
03:14:27  <isaacs>on the ClientRequest object
03:14:36  <TooTallNate>and then after that it has to create a TLS socket on top of the TLS socket connection to the proxy server
03:14:38  * TooTallNateinception
03:14:48  <isaacs>yep
03:14:49  <isaacs>:)
03:14:57  <TooTallNate>i mean i got it all working not
03:14:58  <TooTallNate>now
03:15:00  <isaacs>i gotta run, it's dinner time and dexter time
03:15:09  <isaacs>you know there are agents that do this already, right?
03:15:14  <isaacs>like, in npm, in the whild?
03:15:16  <isaacs>wild
03:15:42  <TooTallNate>mikeals' were giving me trouble
03:15:45  <isaacs>yeah
03:15:47  <isaacs>they're... not great.
03:15:53  <TooTallNate>isaacs: especially in the https-over-https scenario
03:15:56  <isaacs>TooTallNate: wanna try with http-better?
03:16:07  <isaacs>TooTallNate: see if this api makes it actually better, or worse?
03:16:25  <TooTallNate>ya i wanna try it
03:20:04  <isaacs>kk
03:21:54  * defunctzombie_zzchanged nick to defunctzombie
03:24:55  <trevnorris>tjfontaine: got it. need to add a test, but was actually a pretty simple fix.
03:25:00  <tjfontaine>good
03:26:07  * mikealjoined
03:30:45  * mikealquit (Ping timeout: 248 seconds)
03:31:10  <trevnorris>isaacs: thoughts? moving Buffer.alloc/dispose to require('smalloc'). then can label the whole thing experimental? for continuity with the cc api since users can call smalloc::Alloc/Dispose
03:31:37  <tjfontaine>maybe there's something more descriptive we can use
03:31:39  <isaacs>trevnorris: i'd prefer not to add any new public core modules.
03:31:46  <trevnorris>isaacs: coolio
03:31:54  <isaacs>trevnorris: Buffer.alloc/dispose is fine
03:32:00  <tjfontaine>really? :/
03:32:14  * timoxleyquit (Quit: Textual IRC Client: www.textualapp.com)
03:32:50  <isaacs>I guess, in this case, it's unlikely that someone is using "smalloc" on npm
03:33:06  <isaacs>it sucked breaking tjholowaychuk's cluster module
03:33:13  <tjfontaine>indeed
03:33:39  <isaacs>we can label a single function or class experimental, though
03:34:48  <tjfontaine>I just worry that some people will confuse Buffer.alloc with new Buffer() at some point, also with the other dispose conversation happening I get easily confused :)
03:37:08  <isaacs>hm.
03:37:11  <isaacs>tjfontaine: that's a good point
03:37:22  <isaacs>meh. i guess. fuck it.
03:37:28  <isaacs>trevnorris: publish something to npm as "smalloc"
03:37:35  <isaacs>trevnorris: then give us permission to clobber it :)
03:37:37  <creationix>tjfontaine, https://gist.github.com/creationix/5954513#file-simple_bindings-c
03:37:38  <tjfontaine>the other portion that worries me is that `Buffer.alloc() instanceof Buffer` doesn't work :)
03:37:43  <trevnorris>heh. ok
03:37:45  <tjfontaine>creationix: thanks
03:37:48  <creationix>just a start I'll add more example of more complicated things
03:38:06  <creationix>it's got the simplicity of the lua interface without manual stack counting
03:38:37  <tjfontaine>creationix: right, that's not that far off from what I'm considering
03:38:50  <creationix>great, I would *love* an API this simple
03:38:54  <creationix>data oriented
03:39:04  <creationix>create things, set properties, return things, etc..
03:39:12  <tjfontaine>creationix: my opinion is that this is what 90% of C modules will do
03:39:27  <tjfontaine>they'll just be interfaces to underlying native libraries
03:40:06  <creationix>my only worry is we'll be slow for never using the class constructs provided by the vms
03:40:15  <creationix>but I really don't want to expose class style interfaces
03:40:19  <creationix>js doesn't have classes
03:40:35  <creationix>it has functions, objects, properties, etc
03:40:36  <tjfontaine>creationix: what will go hand in hand is a conversation abotu "best practices"
03:41:04  <creationix>my goal is to have a C API that mimics what you would do in JS
03:41:06  * timoxleyjoined
03:41:06  <tjfontaine>creationix: this part of the "deal with primitives" conversation, where people need to stop trying to do so much heavy lifting on the native side, and let the jit do it
03:41:11  <creationix>so our JS best practices can be reused
03:41:29  <creationix>that too
03:41:57  <creationix>also once core ports to the neutral API, dropping sm is as simple as writing a shim from neutral api to sm native apis
03:41:59  <tjfontaine>people shouldn't be passing objects with properties to native, they should be breaking those out into primitive arguments, have a js shim in front that does nice things
03:42:12  <tjfontaine>creationix: ya, but that's definitely a stretch goal :P
03:42:18  <creationix>right, later on
03:42:36  <creationix>but we do need this shim for at least v8 for now right?
03:42:53  <tjfontaine>yup, something module authors can target that we can guarantee will work from release to release
03:43:18  <creationix>and we can release the shim as a library you use so your library can run on existing node versions
03:43:29  <creationix>include the shim instead of v8's headers directly
03:43:34  <tjfontaine>yup, back to v0.8 is my plan
03:43:41  <tjfontaine>creationix: yup, you've got the idea
03:43:44  <creationix>:)
03:44:21  <tjfontaine>solves the problem of "which v8.h am I actually getting right now"
03:48:16  <trevnorris>isaacs: https://npmjs.org/package/smalloc
03:51:11  * timoxleyquit (Quit: Computer has gone to sleep.)
03:53:28  * kazuponjoined
03:56:59  * mikealjoined
03:58:57  <creationix>tjfontaine, maybe "this" could be position 0 in the virtual space?
03:59:03  <creationix>1-n would be passed in args
03:59:24  <creationix>-1 - -n would be dynamic space for new values
03:59:36  * kazuponquit (Ping timeout: 246 seconds)
04:01:43  * mikealquit (Ping timeout: 264 seconds)
04:02:32  * kazuponjoined
04:03:36  <trevnorris>quick review anyone? https://github.com/trevnorris/node/compare/slice-first-parent
04:09:08  * TooTallNatequit (Quit: Computer has gone to sleep.)
04:10:45  <creationix>tj, remind me how forgiving C is with mixing number types
04:11:04  <creationix>suppose I have a function that returns "int" and I set it to a variable declared as "char"
04:11:13  <creationix>is that bad?
04:11:19  <creationix>tjfontaine, ^
04:12:35  * timoxleyjoined
04:16:40  <tjfontaine>heh, that is probably not something you want to do regularly
04:18:18  <tjfontaine>creationix: if you don't cast it, it will fail to compile, if you cast it you'll truncate and only get the size of the destination type
04:18:34  <tjfontaine>unless of course you're going to a larger type
04:18:40  <trevnorris>creationix: you'll have to answer to ben for all of that. and he's pretty specific :)
04:18:42  <creationix>I'm just wondering how many number types the API needs to be able to return
04:18:49  <creationix>I'm thinking at least int and double
04:19:08  <tjfontaine>creationix: [u]int[32|64] and double
04:19:09  * jmar777quit (Remote host closed the connection)
04:19:24  <creationix>even though js can't hold 64 bit types?
04:19:39  * jmar777joined
04:19:40  <tjfontaine>ya, because you can get 53 bits from your number
04:20:00  <creationix>fair enough
04:20:56  <creationix>is boolean a common type in C?
04:21:07  <creationix>(I know it's really just the int 0 or 1
04:21:08  <tjfontaine>depends on the version of C
04:21:15  <tjfontaine>C99 has a bool
04:21:41  <creationix>I mean, we could just add the typedef if it's not there right?
04:21:45  <creationix>or that a really bad practice?
04:21:51  <tjfontaine>yup
04:21:54  <tjfontaine>well
04:22:32  <tjfontaine>we would probably follow convention an typedef NODE_BOOL bool; else typedef NODE_BOOL uchar;
04:22:58  <tjfontaine>since it's possible someone could have a bool symbol
04:23:20  <creationix>I'll just put "bool" in my markdown, but interpret it to mean whatever we'll end up doing
04:23:31  <tjfontaine>right
04:23:53  <creationix>now strings
04:24:09  * jmar777quit (Ping timeout: 264 seconds)
04:24:11  <creationix>what should a C api return for strings?
04:24:12  <tjfontaine>that will take special care, because of stupid utf8 nonsense
04:25:30  <trevnorris>creationix: also keep in mind a string can be externalized, which will have different behavior than v8 strings.
04:25:39  <creationix>right, strings are complex
04:25:57  <creationix>but even ignoring encoding, I can't just return a const char* right?
04:26:10  <creationix>because the compiler doesn't know how large the string will be
04:26:11  <tjfontaine>const char* is more than likely the right answer
04:26:20  <tjfontaine>for at least the common usages
04:26:38  <creationix>forgive me for being a C noob.
04:26:42  <creationix>how does that even work?
04:26:53  <trevnorris>that's how we currently handle external strings. but you also need to know the encoding.
04:26:53  <creationix>I would love to return const char* if possible
04:27:03  <trevnorris>just having the const char* doesn't help you a ton
04:27:29  <trevnorris>strings can be one byte, two byte or utf8
04:27:39  <creationix>right
04:27:47  <creationix>I could have variants of the function for that though
04:27:58  * mikealjoined
04:28:20  <trevnorris>actually, what v8 does is return a const char* for utf8, const uint8_t* for one byte and const uint16_t* for two byte
04:28:59  <tjfontaine>the SM mechanism is fine, basically it normalizes internally to uchar16, but offers normal char*
04:29:05  <tjfontaine>https://developer.mozilla.org/en-US/docs/SpiderMonkey/JSAPI_Reference#Strings
04:29:27  <creationix>trevnorris, but the caller chooses which encoding to get right?
04:29:31  <tjfontaine>yes
04:29:33  <tjfontaine>well
04:29:42  <tjfontaine>you can always try and get something back that doesn't make sense :)
04:29:45  <trevnorris>not if it's an external string
04:30:13  <trevnorris>in that case you just ask for the data back.
04:30:14  <creationix>do strings know their encoding internally?
04:30:24  <creationix>if so, the shim could convert for us
04:30:35  <tjfontaine>yes, the shim can do a lot of lifting in these cases
04:30:41  <creationix>and we could have an API to ask what the encoding is
04:30:51  <creationix>for when we want to optimize and skip re-encoding
04:31:21  <trevnorris>tjfontaine: i'm not sure I like getting rid of explicit one byte (that's how i'm reading the docs). that'll make ascii/binary slower. am I reading them wrong?
04:31:36  <tjfontaine>trevnorris: for these conversations you have to divorce yourself of the knowledge of how v8 works
04:32:10  <trevnorris>only as much as I'm aware of it affecting performance
04:32:30  <tjfontaine>trevnorris: there are things we can do in the shim to make it not slow, but in the binding layer a certain amount of overhead is acceptable
04:32:33  * mikealquit (Ping timeout: 264 seconds)
04:32:46  <tjfontaine>we're not going to make it slow on purpose
04:33:00  <creationix>eventually we'd like to port core to the shim without killing performance
04:33:04  <creationix>if that's even possible
04:33:08  <tjfontaine>but when we're working on designing the shim we can't be obsessed too much with how v8 itself works
04:33:15  <tjfontaine>creationix: right
04:33:17  <trevnorris>tjfontaine: seriously? just having v8 is adding a ridiculous amount of overhead.
04:33:36  <tjfontaine>trevnorris: well, everyone has already accepted that by using node
04:33:45  <trevnorris>some of us ;)
04:33:46  <creationix>I would love a tiny js interpreter
04:33:52  <creationix>something along the size of lua
04:34:01  <trevnorris>that's what i'm working towards anyways
04:34:09  <creationix>that would be really fun for non-CPU intensive servers
04:34:27  <trevnorris>i'm fairly certain http could be delivering at least twice the requests as we're now giving it.
04:34:53  <creationix>I've gotten over 120,000 request per second with manual bindings to libuv and lua and hand-coded pipelining
04:34:59  <trevnorris>when perf is showing 85% cpu is spent in v8, something is wrong. even if that's the tech we're using.
04:35:07  <creationix>Skipping all the js sugar in node's http layer could speed things up a lot
04:35:25  <trevnorris>creationix: yeah. and i've reached 250k in straight c to libuv. but i'm maxing out at 20k in node.
04:35:47  <creationix>I do think v8 is faster than luajit (at script execution)
04:35:54  <creationix>but yeah, the js overhead is real
04:36:21  <creationix>not sure what we can do there without breaking the public API though
04:36:24  <trevnorris>actually, the painful part is working with js objects in cc. that's what's adding much of the overhead.
04:36:28  <creationix>I made luvit 20x faster by changing the API
04:36:47  <trevnorris>every request we have to create a new Persistent and tie in a bunch of properties, etc.
04:37:08  <creationix>trevnorris, the shim won't be able to help much then because it will still need to translate to V8 calls right?
04:37:40  <trevnorris>creationix: this work is below the shim. the type of stuff I've been doing for buffers.
04:37:44  <tjfontaine>the problem is core violates rule number of my "best practices" it doesn't deal only in primitives :P
04:37:53  <tjfontaine>*rule number 1
04:38:21  <trevnorris>tjfontaine: you think that'd be possible? i'm not completely sure how it could be.
04:38:43  <creationix>well, take http header parsing, for example
04:38:53  <creationix>you either build up an object in C or call js for every key and value
04:38:53  <tjfontaine>trevnorris: I think we can try harder, but I'm not going to say it's always 100% achievable
04:38:53  <trevnorris>i have. and am working on it right now :P
04:39:03  <creationix>(or write the parser in js :)
04:39:08  * tjfontainevotes for parser in js
04:39:28  <trevnorris>tjfontaine: well. I like the idea fwiw.
04:39:33  <tjfontaine>which?
04:39:50  <trevnorris>keeping arguments as "primitive" as possible.
04:39:56  <trevnorris>all the object munging kills us.
04:40:10  <tjfontaine>right, the only time we should be breaking that are for weak handles
04:40:22  <tjfontaine>which admittedly is painful and unavoidable
04:40:35  <trevnorris>but as for the http_parser i'm actually taking it in the completely opposite direction..
04:40:50  * bradleymeckquit (Quit: bradleymeck)
04:41:12  <trevnorris>i'm replacing the DoRead() callback to cache the incoming data internally until all the headers are received then passing them directly to http_parser from cc.
04:41:33  <trevnorris>basically, stay in cc until we can reach js. then when we reach js, stay there.
04:41:54  <tjfontaine>yes, that will help, I don't think anyone disagrees with that :0
04:41:55  <tjfontaine>er :)
04:42:07  <trevnorris>:0)
04:42:32  <creationix>so many functions, C sure is verbose
04:42:42  <creationix>but I'm really liking this API, I hope we can do something like it
04:43:06  <trevnorris>tjfontaine: quick review? https://github.com/trevnorris/node/compare/slice-first-parent
04:43:50  <tjfontaine>trevnorris: it looks basically right, but I haven't looked at in context yet
04:44:32  <tjfontaine>creationix: I'm hoping that we can make it slightly less verbose with some convenience macros, and a good example pattern for people to follow
04:44:42  <trevnorris>tjfontaine: it's about as complicated as it looks. just making sure there's never a buf.parent.parent. (etc) case.
04:46:53  <tjfontaine>trevnorris: do we cache the location of a slice in relation to the parent? or just cache the parent?
04:47:03  <creationix>int js_get_[int32|uint32|int64|uint64|double|boolean|string|string8|string16](js_context*)
04:47:28  <trevnorris>tjfontaine: just the parent. used to also be the location (e.g. the old .offset property), but the new slice method gets around the old pitfalls
04:47:52  <tjfontaine>trevnorris: ok, then I'm more +1 on it
04:48:49  <tjfontaine>creationix: right, more or less
04:49:03  <creationix> I'll add a sample header file to my gist
04:49:07  <creationix>them post to the mailing list
04:49:16  * qardquit (Quit: Leaving.)
04:49:34  <tjfontaine>creationix: about the only thing you haven't really thought about is what exception handling will look like :)
04:49:58  <creationix>that's almost on purpose :P
04:50:10  <creationix>but I guess there must be a way to throw and catch exceptions
04:50:36  <tjfontaine>hehe, I don't particularly care so much about throwing, but certainly if you call a function you might throw
04:50:48  <tjfontaine>or rather somethign other than you might throw
04:50:54  <creationix>is there a portable way in C to simulate throwing?
04:50:58  <creationix>longjump or something
04:51:08  <creationix>or is it best to just return a special value
04:51:19  <tjfontaine>well, we don't want to do that stuff
04:51:33  <tjfontaine>but longjump yes is what would be used
04:51:44  <creationix>I think that's what lua does, it's been a while
04:51:45  <tjfontaine>but v8 and sm signal if there are pending exceptions
04:51:48  <creationix>I never liked it
04:52:12  <creationix>I guess I could just call a special API to register the exception and then return 0
04:52:34  <creationix>return js_throw(C, "This is a printf style message", ...)
04:52:53  <tjfontaine>creationix: so one part I like about the SM api is that you return TRUE if everything is ok, and FALSE if things went wrong, and you set the return value somewhere
04:53:15  <tjfontaine>so that way it's easy to signal to composable pieces if something has gone wrong
04:53:24  <creationix>I never liked that, but I'm not opposed to it
04:53:28  <creationix>it works as well
04:53:52  <creationix>the composable argument is good
04:54:44  <creationix>though i think it's still composable with my style
04:55:02  <creationix>at least in the tail-call style case
04:55:32  <tjfontaine>ya
04:56:08  <creationix>so it could still be pretty with those semantics
04:56:20  <creationix>return js_return(C, some_value)
04:56:29  <creationix>and js_return returns TRUE
04:56:49  <creationix>that also makes returning undefined easier
04:56:52  <creationix>just `return TRUE`
04:58:25  * mikealjoined
04:59:56  <creationix>tjfontaine, I'll change to that. I do like the composability
05:00:02  * kazupon_joined
05:00:38  * defunctzombiechanged nick to defunctzombie_zz
05:00:43  <tjfontaine>creationix: heh, so basically at the moment the only difference from the SM api is that we're keeping arguments in the context and not passing in argc, argv
05:01:19  <creationix>and we never have pointers to values
05:01:23  <creationix>just virtual slots
05:02:17  <tjfontaine>well, we'll need something to reference a js_get_object concept?
05:02:35  * mikealquit (Ping timeout: 246 seconds)
05:03:07  <creationix>I expect the shim to keep a linked list or other list-like structure of created values
05:03:10  * kazuponquit (Ping timeout: 256 seconds)
05:03:36  <creationix>and when the function ends, see which one is the return value and do whatever the underlying system needs to preserve it
05:04:28  <creationix>slot 0 is "this", positive slots are arguments, negative slots are local variables/values created in the function body
05:04:34  <creationix>any of the above can be returned by slot
05:05:13  <tjfontaine>but I'm not necessarily sure how that handles generic object manipulation
05:06:55  <creationix>it works the same way it does in lua, except for the strict ordering
05:07:01  <creationix>which they do so they can return multiple values
05:07:12  <tjfontaine>right
05:07:23  <tjfontaine>I need to think on that part some more
05:07:32  <creationix>if it works, I think this would be awesome
05:07:51  <creationix>I really like bindings to never have access to js value pointers
05:08:09  <creationix>if you need to store an object in a C struct, you create a ref to it
05:08:20  <creationix>which is somewhat annoying, but it's an edge case
05:08:36  <creationix>I want the simple case to be simple
05:08:41  <tjfontaine>what's more likely is needing to attach arbitrary c-memory to an object
05:08:42  <creationix>most bindings will be binding to sync APIs
05:09:04  <trevnorris>tjfontaine: are you planning on creating a HandleScope before these are run? (just curious)
05:09:23  <creationix>tjfontaine, like wrapping a C struct as a javascript object?
05:09:42  <trevnorris>creationix: no. directly attaching external memory to an object as an array index.
05:09:50  <creationix>oh, like a buffer
05:09:55  <tjfontaine>trevnorris: in my head right now it works something like: { HandleScope scope; prologue(); actual_shim_call(); epilogue(); }
05:10:02  <trevnorris>cool
05:10:22  <tjfontaine>creationix: or a handle to some internal resource
05:10:30  <creationix>int slot = js_create_buffer(pointer, length)
05:10:40  <trevnorris>creationix: yeah. pretty much. take a look at Alloc in src/smalloc.cc for the minimal implementations
05:11:51  <trevnorris>also Use()
05:11:51  <creationix>though this does bring up passing around structs as opaque values
05:12:06  <creationix>many C apis give you a struct that they expect you to pass back in later
05:12:11  <creationix>and js needs to be able to handle that logic
05:12:11  <tjfontaine>yes
05:12:59  <creationix>also we need to be able to create closures
05:13:05  <creationix>callable functions that carry internal state
05:13:13  <creationix>not bound to "this"
05:13:16  <trevnorris>unfortunately once you pass a Persistent into js then it'll come back as a Local.
05:15:19  <trevnorris>tjfontaine: mind giving me one last lgtm? https://github.com/trevnorris/node/compare/slice-first-parent
05:19:37  <tjfontaine>that logic seems simpler
05:21:05  <trevnorris>yeah. knew it was in there. just took me a minute to see it.
05:21:57  <creationix>tjfontaine, is this what you meant by macros? https://gist.github.com/creationix/5954513#file-accessing_this-c-L16-L18 and https://gist.github.com/creationix/5954513#file-accessing_this-c-L26-L28
05:22:57  <tjfontaine>creationix: right, going along those lines
05:23:53  <tjfontaine>creationix: I expect to find more things as we start seeing the common patterns
05:24:22  <creationix>but the general idea is to put only basics as real functions and use aliases for all the combinations/shortcuts
05:24:34  <tjfontaine>yup
05:24:37  <creationix>cool
05:25:33  <creationix>maybe instead of "int" for slots, we could typedef "slot"?
05:25:52  <creationix>though "int" is unique to slots in these examples so far
05:26:02  <creationix>since the actual number types are more explicit
05:26:56  <creationix>personally I prefer less typedefs if possible
05:27:34  <tjfontaine>it will need to be a balance
05:28:48  * mikealjoined
05:31:59  <creationix>when converting C strings to js values, the C string isn't usually const right?
05:32:44  <tjfontaine>it is, because the contract would be that the underlying function wouldn't change it, it's a copy
05:33:12  <creationix>so it's up to the binding author to manually copy their string then?
05:33:36  <creationix>I'm not very clear on how to create const strings
05:34:02  <tjfontaine>no, when an author asks to store/create a js string, that will end copying the string for them
05:34:11  <creationix>in lua, you pass in mutable strings and it copies when interning them
05:34:13  <tjfontaine>there is a concept of "external" strings, where it does reuse the underlying memory
05:34:35  <creationix>ok, so for the header "char* value" is fine?
05:34:38  <trevnorris>tjfontaine: wouldn't it be easier just to use the already abstracted StringBytes api?
05:34:41  <creationix>just document that it will copy the memory
05:34:54  <trevnorris>that will automatically handle externalization and all that
05:35:04  <tjfontaine>trevnorris: for implementation we may, we're just letting creationix think through the api he would like to consume
05:35:13  <trevnorris>ah cool
05:36:11  <creationix>so for external strings, the vm doesn't copy them and the consumer is responsible to never change them?
05:36:31  <creationix>and make sure they don't get freed
05:37:06  <creationix>would the js engine free them when the object gets gc'ed
05:38:28  <tjfontaine>depends, you'd probably make it weak such that you could be notified and free it yourself
05:39:03  <trevnorris>creationix: external strings are tied to a class that is handled by v8. when the object bound to that class is gc'd the class destructor is run.
05:39:07  <creationix>so pass in a C callback for on gc?
05:39:09  * philipsquit (Ping timeout: 264 seconds)
05:39:22  <tjfontaine>creationix: right, we're going to need a generic pattern for that anyway
05:39:36  <creationix>yep for the struct wrappings
05:39:51  <trevnorris>creationix: i'm curious, what type of information are your wrapping in a struct?
05:40:05  <creationix>trevnorris, what do you mean?
05:40:15  <tjfontaine>trevnorris: for our purposes what he actually means is "opaque pointer"/external-memory
05:40:16  <creationix>most my C experience is writing libuv bindings
05:40:18  <tjfontaine>:)
05:40:40  <creationix>so I need to pass uv_handle_t instances to js somehow
05:40:52  <creationix>since many uv functions accept them as arguments
05:40:56  <trevnorris>tjfontaine: ah, ok.
05:41:57  <creationix>can C functions have multiple signatures?
05:41:59  <creationix>optional args
05:42:04  <creationix>or is that only C++
05:42:50  <tjfontaine>well, let's just say "no" :)
05:43:02  <creationix>so not portable then
05:43:23  <creationix>no problem, I'll just make *more* functions :)
05:43:29  <tjfontaine>that's the spirit :)
05:43:55  <creationix>js_create_object(js_context* C) and js_create_object_with_proto(js_context* C, int proto_slot)
05:44:11  <creationix>same for functions with a parent scope (closures)
05:44:13  * kazupon_quit (Read error: Connection reset by peer)
05:44:50  <creationix>or I could have a function for mutating the __proto__
05:44:57  <creationix>but I think that's discouraged
05:44:59  <trevnorris>eh?
05:45:07  <trevnorris>sorry, wrong window
05:46:34  * kazuponjoined
05:50:22  * philipsjoined
06:04:01  <creationix>tjfontaine, how would I write a macro that aliases `js_return_int32(C, value)` to `js_return(C, js_create_int32(C, value))`?
06:05:25  <tjfontaine>#define js_return_int32(C, value) js_return(C, js_create_int32(C, value))
06:05:38  <tjfontaine>:)
06:05:39  <creationix>oh, that's simple
06:05:53  <creationix>and I don't even need extra parens in this case because of the commas
06:06:21  <tjfontaine>there may be some other cases where more parens will be needed but for now just handle the simple expressions
06:10:39  * defunctzombie_zzchanged nick to defunctzombie
06:11:35  <trevnorris>going to land that patch.
06:12:42  <tjfontaine>I don't see a reason why not, since it's a problem just not for the dispose case
06:15:36  <MI6>joyent/node: Trevor Norris master * b8ce1da : buffer: propagate originating parent - http://git.io/npIbnQ
06:20:35  * defunctzombiechanged nick to defunctzombie_zz
06:26:46  * loladiroquit (Quit: loladiro)
06:31:32  <MI6>nodejs-master-windows: #104 FAILURE http://jenkins.nodejs.org/job/nodejs-master-windows/104/
06:37:54  * bajtosjoined
06:40:02  <MI6>nodejs-master: #297 UNSTABLE smartos-x64 (7/608) linux-x64 (1/608) osx-ia32 (1/608) smartos-ia32 (1/608) http://jenkins.nodejs.org/job/nodejs-master/297/
06:49:58  * rendarjoined
06:58:49  <creationix>alright, heading to bed, it's 2am
07:03:00  <creationix>tjfontaine, https://gist.github.com/creationix/5954513#file-js_api-h
07:03:03  <creationix>g'night
07:17:47  * pfox__joined
07:18:15  <pfox__>creationix: i couldn't help but observe that your post to the list, re: a C API, looks a lot like JSAPI
07:18:29  <creationix>yep
07:18:38  <pfox__>(im the one who replied as such, btw)
07:18:43  <pfox__>anywho. good times!
07:18:47  <pfox__>i love JSAPI, for the record.
07:18:48  <creationix>except no JS_Class in sight
07:19:20  <pfox__>yeah, building out function defs, classes, etc is tedious
07:19:41  <joshthecoder>was there a recent fix for uv_ref() crashing? Getting some random crashes in 0.10.7.
07:19:53  <creationix>pfox__, well, helper functions and macros could help a lot there
07:20:17  <pfox__>famous last words, indeed!
07:20:42  <creationix>pfox__, my main beef with jsapi (other than the docs being always wrong) was how the C semantics were very different than js semantics around objects and classes
07:21:08  <pfox__>i agree, re: the docs
07:21:28  <pfox__>do you plan to go all the way down the rabbit hole re: support prototypical inheritence?
07:21:36  <creationix>pfox__, it's there already
07:21:45  <creationix>I have an analogue to Object.create
07:22:03  <pfox__>i should just read the gist, huh. im going off of the email.
07:22:09  <creationix>it's exception handling that's giving me trouble, I'll probably just revisit and see what jsapi does there
07:22:16  * timoxleyquit (Quit: Computer has gone to sleep.)
07:24:44  <pfox__>iirc you can register a global callback for uncaught exceptions.. but exceptions that propagate up into native code have to be detected and repropagated in order to reach the global callback
07:25:20  <creationix>lua uses longjump to simulate exception stack jumping in the C side
07:25:25  <creationix>but I don't think we want that
07:26:18  <creationix>hence the manual re-propagation
07:27:31  <creationix>maybe `bool js_call(C, &result, function_slot, 0, {})`
07:28:22  <creationix>and then do `if (!js_call(...)) { result contains the exception or return value }`
07:30:03  <creationix>anyway, I'm off to bed for real this time
07:30:24  <pfox__>night
07:40:30  * wolfeidauquit (Remote host closed the connection)
07:44:10  * amartensquit (Quit: Leaving.)
08:05:57  * pooyaquit (Quit: pooya)
08:10:29  * timoxleyjoined
08:14:26  * amartensjoined
08:21:12  * amartensquit (Ping timeout: 256 seconds)
08:23:48  * wolfeidaujoined
16:08:05  <sblom>slurp: Welcome back!
16:08:09  <tjfontaine>:)
16:10:37  <trevnorris>oh man. you mean I ran down that old lady rushing into the office for nothing :P
16:11:34  * defunctzombie_zzchanged nick to defunctzombie
16:11:40  <trevnorris>bnoordhuis: so, from v8 themselves say that reinterpret_cast<Local*> is safe if it's not weak.
16:12:06  <trevnorris>seems crazy the api would go that route, but eh whatever.
16:13:30  * defunctzombiequit (Changing host)
16:13:30  * defunctzombiejoined
16:13:42  * mikealjoined
16:14:13  * isaacsback
16:15:40  <trevnorris>bnoordhuis: p_obj is a Persistent. so how could passing &p_obj be a bug?
16:18:27  <isaacs>bnoordhuis trevnorris piscisaureus sblom: google hangle outle?
16:18:45  <trevnorris>sounds good to me
16:19:45  <isaacs>we're there
16:20:05  <isaacs>should be a link in the calendar invite
16:20:05  <bnoordhuis>isaacs: i'm skipping, i'm sick
16:20:13  <tjfontaine>awww
16:20:23  <tjfontaine>bnoordhuis: feel better
16:20:56  <isaacs>bnoordhuis: :(
16:21:36  <sblom>Hmmm. My invite still claims Skype.
16:21:43  <isaacs>sblom: hmm....
16:21:52  <isaacs>sblom: https://plus.google.com/hangouts/_/5b6b53fce8c09512b15a7e7d5c2fbb51d9557288
16:21:52  <trevnorris>whoops. might have just called everyone :P
16:23:04  <isaacs>bnoordhuis: do you know if bertje is around?
16:23:19  * rjechanged nick to rje`drsappt
16:24:56  * pooya_joined
16:26:09  * pooyaquit (Ping timeout: 246 seconds)
16:26:09  * pooya_changed nick to pooya
16:26:46  <bnoordhuis>isaacs: sorry, don't know
16:28:25  <trevnorris>bnoordhuis: sorry dude. i'm not seeing the bug using &p_obj, since it's a Persistent I thought passing the handle by pointer was fine.
16:30:15  * mikealquit (Quit: Leaving.)
16:32:40  * loladirojoined
16:34:18  * defunctzombiechanged nick to defunctzombie_zz
16:37:28  <isaacs>indutny: you around?
16:37:31  <isaacs>call?
16:43:17  * amartensjoined
16:49:55  * defunctzombie_zzchanged nick to defunctzombie
16:51:42  <trevnorris>bnoordhuis: would this take care of that bug? https://gist.github.com/trevnorris/5959058
16:54:51  <bnoordhuis>trevnorris: something like this: https://github.com/bnoordhuis/node/compare/joyent:master...smalloc-fixups
16:55:12  * amartens1joined
16:55:17  <bnoordhuis>your patch has the same basic idea
16:55:54  <bnoordhuis>i added a new TargetFreeCallback to avoid the extra Local<Object>::New()
16:57:23  <bnoordhuis>okay, afk again
16:58:09  * amartensquit (Ping timeout: 248 seconds)
17:00:23  * mikealjoined
17:02:34  * bnoordhuisquit (Ping timeout: 276 seconds)
17:02:42  * mikealquit (Client Quit)
17:09:51  <isaacs>call notes: https://simple-note.appspot.com/publish/7mYRTH
17:11:35  * brsonquit (Ping timeout: 260 seconds)
17:13:08  * mikealjoined
17:17:04  <trevnorris>ircretary: tell bnoordhuis my confusion comes from usages like http://git.io/A3vPwA where they are storing Persistent<>* in the class and creating/passing it similar to how I was. is it because the life of the Persistent is only as long as the function?
17:17:05  <ircretary>trevnorris: I'll be sure to tell bnoordhuis
17:18:04  <trevnorris>isaacs: oh, add finishing this page to the list https://github.com/joyent/node/wiki/How-to-Find-Memory-Leaks
17:18:46  <trevnorris>seems the number of tickets related to memory leaks has increased lately, but maybe that's just me
17:21:56  * loladiroquit (Quit: loladiro)
17:26:13  * loladirojoined
17:30:23  * brsonjoined
17:33:30  * loladiroquit (Quit: loladiro)
17:34:35  * sblomquit (Ping timeout: 256 seconds)
17:45:21  * bajtosjoined
17:54:01  * loladirojoined
17:55:21  <MI6>joyent/node: Timothy J Fontaine v0.10 * 91698f7 : tls: only wait for finish if we haven't seen it - http://git.io/OZ_eNA
17:56:00  * wavdedquit (Quit: Nighty night)
17:57:09  * amartens1quit (Ping timeout: 246 seconds)
18:00:09  * amartensjoined
18:00:30  * `3E|DINNERchanged nick to `3rdEden
18:04:20  <trevnorris>ah, love the days when I regress back to feeling like I know nothing. I'll blame it on the long vacation. :P
18:06:23  <tjfontaine>ever watch hogans heroes?
18:06:25  <pquerna>http://tools.ietf.org/html/draft-friedl-tls-applayerprotoneg-01
18:06:39  <pquerna>erg, old one.
18:07:01  <trevnorris>haven't
18:07:07  * qardquit (Ping timeout: 260 seconds)
18:07:30  * qardjoined
18:07:44  * bnoordhuisjoined
18:08:04  <tjfontaine>trevnorris: there's a character named Sargent Schultz, and his catch phrase is "I know nothing" with an outrageous accent
18:08:20  <trevnorris>hah. sounds about right
18:08:38  <tjfontaine>http://www.youtube.com/watch?v=UgcxGFmYyPs
18:08:53  <tjfontaine>that one didn't actually have it
18:08:53  <tjfontaine>anyway
18:09:03  <tjfontaine>it's a meme before people knew it was a meme
18:10:19  <trevnorris>awesome.
18:11:16  * bnoordhuisquit (Read error: Operation timed out)
18:12:16  * rje`drsapptchanged nick to rje
18:12:31  * qardquit (Ping timeout: 264 seconds)
18:13:37  * kazuponquit (Remote host closed the connection)
18:14:04  * kazuponjoined
18:14:22  <MI6>nodejs-v0.10-windows: #101 UNSTABLE windows-ia32 (7/594) windows-x64 (8/594) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/101/
18:16:19  * AvianFluquit
18:19:01  * wavdedjoined
18:19:07  * kazuponquit (Ping timeout: 264 seconds)
18:26:38  * sakkakujoined
18:28:00  <MI6>joyent/node: Nathan Rajlich master * 48e159f : crypto: throw a helpful error message for "tls" and "crypto" (+1 more commits) - http://git.io/SvFDkg
18:35:13  * amartensquit (Read error: Connection reset by peer)
18:35:55  * amartensjoined
18:37:01  * qardjoined
18:38:08  <MI6>nodejs-master: #298 UNSTABLE smartos-x64 (9/608) linux-x64 (1/608) http://jenkins.nodejs.org/job/nodejs-master/298/
18:39:14  <trevnorris>tjfontaine: can you shed some light on what's happening with the & in: reinterpret_cast<Persistent<T>&>(that)
18:41:11  <MI6>nodejs-master-windows: #105 FAILURE http://jenkins.nodejs.org/job/nodejs-master-windows/105/
18:41:20  <tjfontaine>trevnorris: c++ references
18:41:51  <tjfontaine>:)
18:42:05  <TooTallNate>it's like pointers but... not...
18:44:09  <creationix>and people wonder why I don't like C++
18:44:53  <tjfontaine>heh
18:45:27  <creationix>C is so simple you don't even have pass-by-reference, only pass-by-pointer.
18:45:50  <tjfontaine>well that is a reference, just not the same thing as a C++ reference :)
18:45:55  <creationix>though I do share Marcel's concern that my magic "slot" system will incur a bit of overhead.
18:46:56  <tjfontaine>it is an interesting design decision, and for some people it's desirable
18:47:24  <creationix>if it's possible to make it not slow, it will be very easy for people with a JS background
18:47:51  <creationix>but if we have to shift to a moew V8 style local and persistent handle system, the rest of the API doesn't change much
18:47:51  <tjfontaine>right, but I think it can be implemented (without any extra overhead) on a low level jsapi interface
18:48:06  <tjfontaine>I'm not sure that's really necessary
18:48:21  <creationix>I want to start implementing a prototype on top of V8 right now, but I need to get back to working on js-git
18:48:37  <creationix>so many fun things to work on, so little time
18:48:49  <tjfontaine>isn't tha talways the way
18:49:12  <creationix>tjfontaine, let me know if you have any questions or want more feedback.
18:49:22  <creationix>I'm going back to my work for a while
18:49:29  <trevnorris>well.... until today I never realized there was a difference between a "reference" and a "pointer". to me they were all just memory address locations.
18:49:32  <tjfontaine>creationix: ok thanks for your feedback so far
18:49:44  <tjfontaine>trevnorris: well, in C that's mostly true
18:53:24  * qard1joined
18:56:19  * qardquit (Ping timeout: 264 seconds)
18:59:57  <trevnorris>oy. that seems really confusing
19:00:07  <trevnorris>so &val returns a pointer to val
19:00:26  <trevnorris>but int& val; is like a strange hidden reference type thing.
19:00:48  <tjfontaine>a typesafe reference, and it's generally decided by the receiving function
19:00:49  * sakkakuquit (Ping timeout: 248 seconds)
19:03:28  <trevnorris>how do you mean, it's generally decided by the receiving function?
19:04:10  <tjfontaine>so you set something to a variable, whose type is a reference, or you pass something to a method, whose type argument is a reference
19:04:20  <tjfontaine>you don't generally make a choice when passing to make it a reference
19:04:22  <tjfontaine>usually.
19:06:07  * pachetquit (Quit: leaving)
19:06:50  <trevnorris>ah, wtf. ok think I understand now: https://gist.github.com/trevnorris/5960269
19:11:44  * sakkakujoined
19:17:03  <creationix>trevnorris, I used to think that was part of plain C
19:17:11  <creationix>tried to use it last night for my APIs that need out args
19:17:20  <creationix>the C compiler didn't like it to say the least
19:17:37  <trevnorris>heh, i'm not a huge fan either
19:17:49  <creationix>it's sugar
19:18:22  <trevnorris>where i'm getting confused is by their use with Persistents and Handles in v8
19:24:10  * AvianFlujoined
19:27:59  * bajtosquit (Quit: bajtos)
19:28:55  <trevnorris>hell's yes! ok, i've learned my thing for the day.
19:29:51  * bradleymeck_joined
19:30:28  * pooyaquit (Quit: pooya)
19:35:45  * bradleymeck_changed nick to bradleymeck
19:49:41  <trevnorris>ircretary: bnoordhuis ok. think I understand. here's a fix for academic practice: https://gist.github.com/trevnorris/5959058
19:49:43  <ircretary>trevnorris: I'm not sure what to do with that command. Ask for help in PM.
19:52:12  <trevnorris>ircretary: read my mind!
19:52:14  <ircretary>trevnorris: I'm not sure what to do with that command. Ask for help in PM.
19:52:28  <tjfontaine>LOUDBOT_: THE BOTS ARE REVOLTING
19:52:28  <LOUDBOT_>tjfontaine: "WE SHOULD NAME DROP THE SHIT OUT OF THAT"
20:00:05  * rendarquit (Ping timeout: 248 seconds)
20:01:35  * Domenic_quit (*.net *.split)
20:01:35  * nsmquit (*.net *.split)
20:01:36  * jez0990quit (*.net *.split)
20:01:36  * KiNgMaRquit (*.net *.split)
20:04:48  <trevnorris>anyone planning on going to nodeconf.eu?
20:06:42  * Domenic_joined
20:06:42  * nsmjoined
20:06:42  * jez0990joined
20:06:42  * KiNgMaRjoined
20:09:03  * rendarjoined
20:09:13  <MI6>joyent/node: isaacs v0.10 * f5602bd : npm: Upgrade to 1.3.2 - http://git.io/ZkA8NA
20:11:17  * Domenic_quit (Ping timeout: 260 seconds)
20:11:33  * Domenic_joined
20:13:37  * jez0990quit (Ping timeout: 260 seconds)
20:13:51  * sakkakuquit (Remote host closed the connection)
20:14:42  * jez0990joined
20:14:44  * julianduquejoined
20:18:12  <MI6>nodejs-v0.10: #274 UNSTABLE linux-ia32 (1/594) smartos-x64 (2/594) http://jenkins.nodejs.org/job/nodejs-v0.10/274/
20:19:08  <MI6>joyent/libuv: isaacs created tag v0.10.12 - http://git.io/_8UErQ
20:19:10  <MI6>joyent/libuv: isaacs v0.10 * 3b4e0a2 : Now working on v0.10.13 (+1 more commits) - http://git.io/W64f3w
20:21:07  <MI6>joyent/node: isaacs v0.10 * 8bac885 : uv: Upgrade to v0.10.12 - http://git.io/C_5pDg
20:21:08  * dominictarrjoined
20:21:49  * dominictarrquit (Client Quit)
20:22:35  * bradleymeck__joined
20:23:47  * nsmquit (*.net *.split)
20:23:47  * KiNgMaRquit (*.net *.split)
20:23:55  * bradleymeckquit (Ping timeout: 264 seconds)
20:23:55  * bradleymeck__changed nick to bradleymeck
20:24:33  * nsmjoined
20:24:33  * KiNgMaRjoined
20:27:26  <MI6>nodejs-v0.10-windows: #102 UNSTABLE windows-ia32 (8/594) windows-x64 (7/594) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/102/
20:28:45  <MI6>libuv-review: #25 FAILURE windows-x64 (3/188) windows-ia32 (3/188) smartos-x64 (2/187) smartos-ia32 (2/187) http://jenkins.nodejs.org/job/libuv-review/25/
20:29:38  <MI6>libuv-v0.10: #103 UNSTABLE windows (6/188) smartos (2/187) http://jenkins.nodejs.org/job/libuv-v0.10/103/
20:29:55  <MI6>nodejs-v0.10: #275 UNSTABLE smartos-ia32 (1/594) smartos-x64 (1/594) linux-x64 (1/594) http://jenkins.nodejs.org/job/nodejs-v0.10/275/
20:30:51  <MI6>libuv-v0.10-gyp: #66 UNSTABLE windows-ia32 (5/188) windows-x64 (3/188) smartos-x64 (2/187) smartos-ia32 (4/187) linux-x64 (1/187) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/66/
20:30:58  * pachetjoined
20:35:35  <MI6>joyent/node: tjfontaine created branch v0.10.13-release - http://git.io/mIStWg
20:36:57  * st_lukejoined
20:38:40  * nsmquit (*.net *.split)
20:38:40  * KiNgMaRquit (*.net *.split)
20:41:44  * nsmjoined
20:41:44  * KiNgMaRjoined
20:41:54  <MI6>libuv-node-integration: #135 UNSTABLE smartos-x64 (1/594) smartos-ia32 (4/594) http://jenkins.nodejs.org/job/libuv-node-integration/135/
20:44:44  * kazuponjoined
20:51:13  * bradleymeckquit (Ping timeout: 240 seconds)
20:51:46  <MI6>nodejs-v0.10-windows: #103 UNSTABLE windows-ia32 (8/594) windows-x64 (8/594) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/103/
20:52:16  * bradleymeck_joined
20:52:22  <MI6>joyent/node: Timothy J Fontaine v0.10.13-release * e32660a : 2013.07.09, Version 0.10.13 (Stable) (+1 more commits) - http://git.io/P4-6mw
20:52:40  * kazuponquit (Ping timeout: 276 seconds)
20:53:11  * bradleymeck_changed nick to bradleymeck
21:00:50  * TooTallNatequit (Quit: Computer has gone to sleep.)
21:07:12  * mikealquit (Quit: Leaving.)
21:18:43  * kazuponjoined
21:23:30  * kazuponquit (Ping timeout: 264 seconds)
21:25:57  <MI6>joyent/node: tjfontaine created tag v0.10.13 - http://git.io/4ArTzg
21:27:11  * wolfeidaujoined
21:27:24  <trevnorris>isaacs: you going to nodeconf.eu?
21:29:30  <MI6>joyent/node: Timothy J Fontaine v0.10 * f1bb5dc : blog: Post for v0.10.13 (+4 more commits) - http://git.io/hSPV0Q
21:30:46  <rendar>hmm, i saw from tag's note that MIPS support is added to libuv, but how? shouldn't gcc builtin intructions abstracts architectures?
21:31:24  * sblomjoined
21:35:55  * sblomquit (Ping timeout: 264 seconds)
21:36:18  * dominictarrjoined
21:37:09  * c4miloquit (Remote host closed the connection)
21:37:36  * mikealjoined
21:41:09  * dominictarrquit (Client Quit)
21:42:15  * rendarquit
21:46:09  * mikealquit (Ping timeout: 248 seconds)
21:51:44  <isaacs>trevnorris: yessir
21:52:00  <trevnorris>isaacs: coolio. mozilla just bought my ticket.
21:52:12  <isaacs>sweet!
21:52:14  <isaacs>it's gonna be rad.
21:52:39  * dominictarrjoined
21:52:45  <trevnorris>looking forward to it.
21:52:51  * pachetquit (Quit: leaving)
21:52:55  <trevnorris>the sight was really cryptic about what was going on
21:53:55  <tjfontaine>get used to that :)
21:54:14  <trevnorris>heh
21:55:10  <trevnorris>s/sight/site
21:55:25  <trevnorris>me grammerz good
21:56:14  <tjfontaine>my understanding that it won't be quite the same flow as the nodeconf we just had, but it's a common pattern for the confs to keep things a secret as long as possible :)
21:57:40  <trevnorris>ah cool.
21:57:51  <trevnorris>mainly i'm just curious about the rooms.
21:58:36  <trevnorris>oh, and the speakers
21:58:43  <trevnorris>also maybe where it actually is :P
21:58:47  <tjfontaine>ah, is the ticket from mozilla a sponsor ticket or just an attendee ticket?
21:58:50  * TooTallNatejoined
21:59:15  <trevnorris>it's a mozilla sponsor ticket
21:59:54  <tjfontaine>ah, so you'll want to inquire as to the disposition of the rooms for that ticket
22:00:49  <trevnorris>ok. so it's not the same rooming as on the site. cool
22:04:58  * sblomjoined
22:06:02  * wavdedquit (Quit: Hasta la pasta)
22:13:42  <MI6>nodejs-v0.10: #276 UNSTABLE linux-ia32 (1/594) smartos-x64 (1/594) http://jenkins.nodejs.org/job/nodejs-v0.10/276/
22:13:55  * sblomquit (Ping timeout: 276 seconds)
22:14:06  * mikealjoined
22:18:16  * mikealquit (Ping timeout: 240 seconds)
22:19:35  * kazuponjoined
22:24:58  * kazuponquit (Ping timeout: 276 seconds)
22:28:57  * jmar777joined
22:28:59  <MI6>node-review: #25 UNSTABLE osx-x64 (1/594) windows-x64 (11/594) windows-ia32 (11/594) linux-ia32 (1/594) smartos-x64 (2/594) http://jenkins.nodejs.org/job/node-review/25/
22:29:03  <MI6>nodejs-v0.10-windows: #104 UNSTABLE windows-ia32 (11/594) windows-x64 (9/594) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/104/
22:43:53  * defunctzombiechanged nick to defunctzombie_zz
22:49:18  * defunctzombie_zzchanged nick to defunctzombie
22:54:06  * bradleymeckquit (Quit: bradleymeck)
22:55:02  * jmar777quit (Remote host closed the connection)
22:55:37  * jmar777joined
22:59:15  <isaacs>tjfontaine: review, please https://gist.github.com/isaacs/5962083
22:59:55  * jmar777quit (Ping timeout: 246 seconds)
23:00:40  <tjfontaine>isaacs: lgtm
23:00:53  <MI6>joyent/node: isaacs v0.10 * b3b8e74 : tools: Add next/prev version scripts - http://git.io/6j7d8A
23:05:20  * mikealjoined
23:13:38  * defunctzombiechanged nick to defunctzombie_zz
23:20:13  * kazuponjoined
23:25:18  * kazuponquit (Ping timeout: 264 seconds)
23:32:02  * dominictarrquit (Quit: dominictarr)
23:35:31  * kazuponjoined
23:37:10  * bradleymeckjoined
23:39:25  * dscape__quit (Quit: Connection closed for inactivity)
23:41:19  * kazuponquit (Ping timeout: 264 seconds)
23:41:21  * timoxleyjoined
23:43:21  * mcavagequit
23:44:03  <trevnorris>isaacs: so here's a fun one to debug. one of the v8 debugger tests causes my system to halt.
23:44:21  <tjfontaine>that shouldn't happen
23:44:23  <tjfontaine>what's going on?
23:44:46  <trevnorris>seems there's a memory leak or something. now, it's the v8 tests, not node. but still :P
23:44:59  <trevnorris>so it fills mem and starts swapping like nuts
23:44:59  <tjfontaine>oh, so "halt" as in swap itself to death?
23:45:01  <trevnorris>yeah
23:45:11  <tjfontaine>ok, i thought you were talking a panic
23:45:24  <trevnorris>hah. sorry. yeah, that would be a worse issue
23:46:21  <MI6>nodejs-v0.10-windows: #105 UNSTABLE windows-ia32 (7/594) windows-x64 (9/594) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/105/
23:48:21  <tjfontaine>trevnorris: it could be a legit memory leak/gc miss in v8 that needs to be identified
23:48:46  <trevnorris>tjfontaine: hm. you might have more experience with this. know if ulimit would work to halt a process after it's consumed too much memory?
23:49:34  <tjfontaine>after a process has started?
23:49:47  <tjfontaine>so yes, you can limit a processes memory usage
23:50:03  <tjfontaine>after its started is meh
23:50:20  <trevnorris>oh sorry, not after it's started.
23:50:30  <tjfontaine>ok yes, you can :)
23:50:34  <trevnorris>cool
23:50:36  <tjfontaine>depends on where the memory is growing
23:50:57  <tjfontaine>probably -v is the knob you need
23:51:28  <trevnorris>awesome.
23:52:32  <MI6>nodejs-v0.10: #277 UNSTABLE smartos-x64 (2/594) http://jenkins.nodejs.org/job/nodejs-v0.10/277/
23:52:41  * bradleymeckquit (Quit: bradleymeck)
23:56:55  * mikealquit (Quit: Leaving.)