00:31:25  * Frippejoined
00:47:23  * Frippequit (Quit: Computer has gone to sleep.)
02:16:01  * bnoordhuisquit (Ping timeout: 248 seconds)
03:22:03  * bnoordhuisjoined
03:23:35  * C-Manquit (Quit: Connection reset by beer)
03:27:06  * bnoordhuisquit (Ping timeout: 264 seconds)
06:47:38  * xan_joined
06:58:42  * Alex_Gaynorquit (Ping timeout: 252 seconds)
06:59:11  * sanjoydquit (Ping timeout: 252 seconds)
07:49:29  * Frippejoined
07:53:21  * Frippequit (Client Quit)
07:56:06  * Frippejoined
08:08:08  * Alex_Gaynorjoined
08:22:10  * guorquit (Remote host closed the connection)
08:22:50  * guorjoined
08:45:11  * stampho_changed nick to stampho
09:12:41  * facelegjoined
09:13:21  <faceleg>Hi room
09:13:36  <faceleg>My google is broken, I can't find docs for Persistent<Function>
09:13:58  <faceleg>specifically, I'm looking to find out whether I need to specify the # of args expected for a given function
09:15:53  <faceleg>uh sorry I mean "im developing a node module with v*
09:16:01  <faceleg>v8* sigh, it's been a long day
09:16:33  <faceleg>never mind, found answer here: http://nodejs.org/api/addons.html#addons_function_arguments
09:16:43  <faceleg>thanks for eventually reading this and thinking of me
09:26:49  * sanjoydjoined
09:55:18  <guor>in any case faceleg, about that escape from handle scope question
09:55:32  <guor>you only have to escape a handle if it's been created in that handle scope
09:55:52  <guor>for v8::Undefined for example that would be unnecessesary
09:57:19  <faceleg>oh ok
09:57:52  <faceleg>if I"m retunring scope.Close(someObject->handle_)
09:57:57  <faceleg>do I ned to do anything special?
09:58:18  <guor>the reason is that when a HandleScope is deconstructed, it destroys all the handles created inside that scope
09:58:27  <faceleg>ohhhhh
09:58:30  <faceleg>hmm
09:58:33  <faceleg>so if
09:58:44  <guor>if you use scope.Close on an handle inside that scope, it gets moved to the outer scope before the scope is destroyed
09:59:14  <faceleg>and if you don't, the handles get blown away?
09:59:18  <guor>yup
09:59:30  <faceleg>does ->Ref() do anything here
09:59:37  <faceleg>right
09:59:58  <faceleg>so in an async v8 func, that created some uv_work
09:59:59  <guor>not sure what ->Ref() does. Doesn't seem part of V8's API
10:00:04  <faceleg>yeah
10:00:15  <faceleg>I'm wroking with a year stagnant node module
10:00:21  <faceleg>trying to update it improve etc
10:00:28  <guor>if you want a function to be sort of like void in C, then just return undefined
10:00:35  <faceleg>hmm
10:00:58  <faceleg>in JS one will use it like: obj.functionName(int, function(error, value) {})
10:01:17  <faceleg>in this situation should I use scope.close(undef)
10:01:19  <faceleg>?
10:02:23  <guor>no. just return V8::Undefined. there is no need to close it because the handle on undefined is not created inside the handle scope
10:02:30  <faceleg>and if I assign a variable that wraps a handle_ to a struct, which is then passed as an arg to uv_queue_work, will said var still be destroyed when the main function returns?
10:02:38  <guor>undefined is a singleton in V8 and the handle to it is just always there
10:02:44  <faceleg>ok
10:02:52  <faceleg>do you mean Undefined() or Undefined
10:03:01  <guor>Undefined()
10:03:04  <faceleg>ok
10:03:06  <faceleg>thanks
10:03:08  <faceleg>so this way
10:03:21  <faceleg>to step through what I'm doing:
10:03:32  <faceleg>1. call from js to function that takes an integer and a callback
10:04:11  <faceleg>2. said function queues with uv_queue_work, with "this"'s handle_, the integer and the callback as properties of a struct
10:04:42  <faceleg>in the first uv_work method, the result variable is initialized, populated and added to the uv_work's struct
10:05:10  <faceleg>3. then in the second uv_work method, the result value is added to an arg array and passed as parameters to the callback
10:05:18  <faceleg>would I close scope on the 3rd step?
10:05:43  <faceleg>having opened it on the first? Or should I not be using HandleScope at all
10:06:20  <guor>you probably want to use persistent handles instead of local handles in here
10:06:40  <faceleg>So instead of: Local<Function> callback = Local<Function>::Cast(args[1]);
10:06:42  <faceleg> ar->callback = Persistent<Function>::New(callback);
10:06:55  <faceleg>Persistent<Function> callback = Persistent<Function>::Cast(args[1]);
10:06:57  <faceleg> ar->callback = Persistent<Function>::New(callback);
10:06:59  <faceleg>?
10:07:17  <guor>I would say yes
10:07:41  <guor>I'm not entirely sure though since I have no idea about the node.js part
10:07:45  <faceleg>haha
10:08:35  <mraleph1>faceleg: you should read through http://kkaefer.github.com/node-cpp-modules/
10:08:55  <mraleph1>it's a bit dated (back from 2011) but it gets all important parts about handles right.
10:09:02  <faceleg>ok thanks
10:09:05  <faceleg>I actually have that open
10:09:14  <faceleg>It's just hard to know which guides are still relevant
10:09:34  <faceleg>I've jumped into the diving pool and am still flailing around whildly
10:09:37  <faceleg>wildly*
10:09:45  <faceleg>thanks for your help and patience with this noob
10:13:09  * [[zzz]]joined
10:15:09  <faceleg>now I have faith in that document it starts to make more sense...
10:16:28  * [[zz]]quit (Ping timeout: 272 seconds)
10:19:16  <faceleg>hmmm
10:20:01  <faceleg>in my "Baton", should I define non primitives as Persistent<Type>?
10:20:25  <mraleph1>yes
10:20:37  <faceleg>it's like there is a light flickering
10:20:39  <mraleph1>those that come from JS side that is.
10:20:47  <faceleg>those that don't?
10:20:57  <faceleg>args.This() comes from JS, right?
10:21:06  <mraleph1>those that don't you manage yourself. yes.
10:21:29  <mraleph1>Persistent is there to tell V8: "hey, I am using this guy, to garbage collect it".
10:21:38  <faceleg>I'm coming from ObjC, what is C++ equiv to retain/release?
10:21:46  <mraleph1>"… don't garbage collect it"
10:21:51  <faceleg>mmm
10:22:01  <mraleph1>faceleg: there is none
10:22:12  <mraleph1>retain/release is a reference counting scheme.
10:22:16  <faceleg>oh
10:22:38  <mraleph1>none directly built into the language.
10:22:45  <faceleg>ah ok
10:22:53  <mraleph1>there are smart pointers that do reference counting but this is not what V8 does.
10:22:54  <faceleg>so to "retain" something, i.e. have it stick around in memory
10:22:59  <faceleg>I just don't "delete" it?
10:23:17  <mraleph1>something your allocated with "new" you just don't delete, yes.
10:23:25  <mraleph1>this is why its called manual memory management :-)
10:23:32  <faceleg>yes
10:23:48  <mraleph1>but V8 has its own garbage collector. so to tell V8 not to delete something you need to hold a handle to an object.
10:23:54  <faceleg>don't laugh, but I find retain/release confusing
10:24:10  <faceleg>this "don't delete it if you don't want it gone" seems more straight-forward
10:24:27  <mraleph1>yes, but both have their own pitfalls in practice.
10:24:34  <faceleg>I'm sure they do
10:24:41  <faceleg>Programming be like 'dat
10:25:55  <faceleg>Now I know slightly better, and having confidence in those slides linked to me
10:26:26  <mraleph1>great :-) good luck. I am afk.
10:26:43  <faceleg>Thanks for hte help, mraleph1 and guor
10:26:50  <guor>np
10:40:55  <faceleg>Does v8 have the _this = this convention ?
10:41:08  <guor>nope
10:42:53  <faceleg>hopes are dashed on the shores of segfault
11:04:04  <faceleg>another question / issue
11:04:25  <faceleg>I am intantiating a class in my asyncafter function in V8
11:04:47  <faceleg>GitCommit *out = new GitCommit()
11:04:59  <faceleg>but it seems that out->handle_ is undefined
11:05:05  <faceleg>as this is where my code is segfaulting
11:05:22  <faceleg>is there something special I must do to give an instance of a class a "handle_"?
11:13:32  * C-Manjoined
11:20:57  <faceleg>As this: GitCommit *out = new GitCommit();
11:20:59  <faceleg> Handle<Value> argv[1] = { out->handle };
11:21:01  <faceleg>is segfaulting
11:22:45  * Net147joined
11:24:29  * tellnesjoined
11:29:59  <faceleg>so I guess my question is
11:30:09  <faceleg>how do I create a js object to be passed to a js callback?
11:37:29  * agerquit (Remote host closed the connection)
12:30:03  * bnoordhuisjoined
13:31:02  <faceleg>If anyone could give me a pointer on how to do this: http://stackoverflow.com/questions/15202676/instantiate-pass-c-object-to-node-js-function-v8
13:31:06  <faceleg>I'd love them a long time
13:31:23  * bnoordhuisquit (Ping timeout: 245 seconds)
13:34:15  * Net147quit (Read error: Connection reset by peer)
13:57:55  * bnoordhuisjoined
14:06:19  * bnoordhuisquit (Ping timeout: 252 seconds)
14:12:29  * carifjoined
14:36:33  * heathquit (Read error: Connection reset by peer)
14:36:49  * heathjoined
14:36:49  * heathquit (Changing host)
14:36:49  * heathjoined
14:52:28  * c4milojoined
14:59:31  * bnoordhuisjoined
15:38:46  * RT|Chatzillaquit (Quit: ChatZilla [Firefox])
16:14:16  * Frippechanged nick to Frippe2
16:30:24  * Frippe2quit (Quit: Computer has gone to sleep.)
17:00:29  * tellnespart ("WeeChat")
17:39:23  * carifquit (Quit: Ex-Chat)
17:45:42  * bnoordhuisquit (Ping timeout: 264 seconds)
18:10:14  * C-Manquit (Ping timeout: 255 seconds)
18:10:45  * C-Manjoined
18:10:46  * C-Manquit (Remote host closed the connection)
18:51:30  * bnoordhuisjoined
18:55:54  * bnoordhuisquit (Ping timeout: 252 seconds)
19:11:38  * michael-robinsonjoined
19:11:48  <michael-robinson>Hello?
19:11:54  * michael-robinsonchanged nick to faceleg|work
19:32:42  * bnoordhuisjoined
19:35:33  * carifjoined
19:45:31  <faceleg|work>Hello?
19:55:44  <bnoordhuis>faceleg|work: hello
20:04:36  <faceleg|work>hey
20:04:44  <faceleg|work>do you have a moment to laugh at my SO question?
20:04:49  <faceleg|work>by laugh I mean solve
20:04:53  <faceleg|work>*answer
20:05:43  <faceleg|work>In case you answer in the affirmative, here it is: http://stackoverflow.com/questions/15202676/instantiate-pass-c-object-to-node-js-function-v8
20:25:49  <bnoordhuis>faceleg|work: try #node.js, it's a lot more active than #v8
20:27:19  <bnoordhuis>to answer your question, i think the issue is with ar->callback, not instance->handle_
20:27:52  <bnoordhuis>it's hard to say for sure because the snippet is incomplete
20:30:18  <faceleg|work>I'm pretty sure it's with the handle_
20:30:39  <faceleg|work>as the previous implementation used input/output vars from JS
20:30:41  <faceleg|work>and operated on them
20:30:49  <faceleg|work>i.e. GC was passed from js
20:30:53  <faceleg|work>manipulated
20:30:59  <bnoordhuis>then you should post full code. it's impossible to tell what's going on now
20:31:06  <faceleg|work>Yeah ok
20:31:09  <faceleg|work>I'll have to wait until I get home
20:31:25  <faceleg|work>didn't want to post it all, was many 10's of lines
20:31:28  <faceleg|work>is*
20:32:05  <bnoordhuis>you can check the backtrace in gdb, that should give you a hint
20:32:07  <faceleg|work>If one instantiates a C++ class within C++ though, is ob->handle_ actually set?
20:32:10  <faceleg|work>haha
20:32:11  <faceleg|work>I did
20:32:14  <faceleg|work>wasn't helpful at all
20:32:23  <bnoordhuis>if one of the handles has val_=0x0, it's been gc'ed
20:32:34  <bnoordhuis>which usually means you forgot to make it persistent
20:32:48  <bnoordhuis>btw, from what thread are you invoking Call()?
20:34:01  <bnoordhuis>"If one instantiates a C++ class within C++ though, is ob->handle_ actually set?" <- you mean new MyClass()? no
20:34:32  <bnoordhuis>if your class inherits from ObjectWrap, it needs to call ObjectWrap::Wrap(args.This()) somewhere
20:35:12  <faceleg|work>oh ok, (0x0 comment) I didn't know that, thank you
20:35:37  <faceleg|work>Ah, it goes:js(callback), C++, uv_work Work, WorkAfter
20:35:45  <faceleg|work>WorkAfter is the subject of my issues
20:36:29  <bnoordhuis>okay, good - calling into v8 from another thread will crash and burn
20:36:48  <faceleg|work>should I instantiate the GC instance in the first C++ function, the one that initialises and begins uv_queue, and add it to the uv_work's request data?
20:37:04  <faceleg|work>that way I should be able to instantiate it with GitCommit::New(args.This))
20:37:18  <faceleg|work>was struggling with where to get args.This() from in the context of the AfterWork method
20:37:37  <faceleg|work>in "work" I do some work with libgit2, which is why I want it tobe async
20:38:06  <faceleg|work>all I want to do is end up with a GC instance that has the relevant git_commit raw value encapsualted, and pass said GC instance to my JS callback function
20:38:30  <bnoordhuis>is your c++ object tied to a js constructor?
20:38:34  <faceleg|work>I was thinking I could instantiate it in the final AfterWork method, but if I need to use the args var from the Method called from JS then no problem
20:38:55  <faceleg|work>https://github.com/tbranyen/nodegit/blob/master/src/commit.cc#L22
20:39:16  <faceleg|work>Note I haven't commited the broken functionality I'm working / we're discussing now
20:39:48  * carifquit (Quit: Ex-Chat)
20:39:59  <bnoordhuis>okay, so you have a New() function that's invoked from js
20:40:11  <bnoordhuis>and it calls Wrap() which is good
20:40:46  * carifjoined
20:40:56  <faceleg|work>Ah I didn't write this, I'm taking over as maintainer, the owner has no time for such frivolities
20:41:16  <faceleg|work>Hence why I have questions that might appear stupid if you assume I wrote this entirely
20:41:38  <bnoordhuis>okay, it should be easy
20:42:01  <bnoordhuis>call Ref() before you call uv_work, call Unref() at the end of your AfterWork function
20:42:27  <bnoordhuis>that'll make sure handle_ doesn't get gc'ed
20:42:40  <faceleg|work>and should I move my GitCommit instantiation into the before uv_work section?
20:43:18  <faceleg|work>so js->function init GC output var, uv_work, work (get git_commit raw value, assign it to GC output var), after work, call callback
20:44:01  <faceleg|work>gc->Ref() (add to uv_work data) work: req->data->out->whatever = somthing; aftewr work callback(req->data->out->handle_)
20:44:17  <bnoordhuis>it's instantiated by a `new Commit` call in js land, right?
20:44:26  <faceleg|work>no
20:44:38  <faceleg|work>you could do it like:
20:45:09  <faceleg|work>aCommit.parent(function(error, parent) { // parent is what I'm struggling with - the parent of the commit, it is instantiated within v8 });
20:45:50  <bnoordhuis>oh, you probably want to instantiate it in your AfterWork function
20:45:57  <faceleg|work>the previous implementation used output var, see line: https://github.com/tbranyen/nodegit/blob/master/src/commit.cc#L299
20:46:03  <bnoordhuis>commit_constructor_function_template->NewInstance()
20:46:34  <faceleg|work>is that my "GitCommit::constructor_template"?
20:46:53  <faceleg|work>GitCommit *outputCommit = GitCommit::constructor_template->NewInstance();
20:47:02  <bnoordhuis>something like that
20:47:07  <faceleg|work>hmm ok
20:47:18  <faceleg|work>And I don't need to pass it any arguments?
20:47:25  <bnoordhuis>only you get a Local<Object>, not a GitCommit*
20:47:31  <faceleg|work>yeah
20:47:44  <faceleg|work>then how might I assign a value to a GC* property?
20:47:50  <bnoordhuis>you Unwrap() it
20:47:54  <faceleg|work>aaaaaaaaah
20:48:11  <faceleg|work>I want to skive off work and rush home to try this out
20:48:21  <bnoordhuis>i'm not stopping you :)
20:48:29  <faceleg|work>thank linus for the terminal, it renders IRC invisible no non programmers
20:49:28  <faceleg|work>Local<Object> *commit = GitCommit::constructor_template->NewInstance();
20:49:54  <bnoordhuis>just commit, not *commit. it's not a pointer
20:49:59  <faceleg|work>ok thanks
20:50:07  <faceleg|work>then unwrap it
20:50:12  <faceleg|work>assign properties whateer
20:50:12  <bnoordhuis>yep
20:50:22  <faceleg|work>then I can pass it to callback with commit->handle_
20:50:45  <bnoordhuis>correct
20:50:49  <faceleg|work>and for future reference, if I was to pass an object throw uv_work, I should call ->Ref(), then ->Unref() in the after work?
20:51:03  <bnoordhuis>yes
20:51:18  <faceleg|work>Thanks bnoordhuis, so very much. I love learning different languages etc, but the initial steps can be *so* frustrating!
20:51:43  <faceleg|work>-Ref && -Unref shold be called only on any/all non primitives, or only ObjectWraps?
20:51:59  <bnoordhuis>ObjectWrap instances only
20:52:04  <faceleg|work>ok
20:52:15  <faceleg|work>at all times right, else they get shoved off into nullspace
20:52:37  <faceleg|work>When I'm done with the learnin' I might write a V8 beginners guide for noobs
20:52:39  <bnoordhuis>even worse, they *might* get shoved off
20:52:44  <faceleg|work>hahahahahaha
20:52:47  <faceleg|work>great.
20:53:07  <faceleg|work>Like dancing on waxed razorblades
20:53:24  <bnoordhuis>yeah. it works 99 out of a 100 times but the 100th time...
20:53:45  <faceleg|work>100th time it'll happen on a user's compuer
20:53:48  <faceleg|work>computer
20:53:57  <faceleg|work>and they won't have the ability to provide helpful debuggin information
20:54:20  <bnoordhuis>we had a similar issue in node once
20:54:32  <bnoordhuis>where we forgot to root some newly created objects in a HandleScope
20:54:59  <bnoordhuis>the only place where the bug actually showed up was at big deployments like voxer
20:55:11  <bnoordhuis>because it only happened like once every few million invocations
20:55:23  <faceleg|work>ugh
20:55:56  <faceleg|work>and this is why noobs like me need to take the time to make absolutely sure the 'template' implementation of functionality that is generally repetitive is done perfectly
21:04:48  * bnoordhuisquit (Ping timeout: 276 seconds)
21:37:35  * bnoordhuisjoined
21:43:35  * Net147joined
22:03:11  * Net147quit (Quit: I love my HydraIRC -> http://www.hydrairc.com <-)
22:16:24  * stalledquit (Ping timeout: 264 seconds)
22:26:26  * RT|Chatzillajoined
22:26:45  * carifquit (Quit: Ex-Chat)
22:41:15  * stalledjoined
23:23:03  * c4miloquit (Remote host closed the connection)