00:31:25
| * Frippe | joined |
00:47:23
| * Frippe | quit (Quit: Computer has gone to sleep.) |
02:16:01
| * bnoordhuis | quit (Ping timeout: 248 seconds) |
03:22:03
| * bnoordhuis | joined |
03:23:35
| * C-Man | quit (Quit: Connection reset by beer) |
03:27:06
| * bnoordhuis | quit (Ping timeout: 264 seconds) |
06:47:38
| * xan_ | joined |
06:58:42
| * Alex_Gaynor | quit (Ping timeout: 252 seconds) |
06:59:11
| * sanjoyd | quit (Ping timeout: 252 seconds) |
07:49:29
| * Frippe | joined |
07:53:21
| * Frippe | quit (Client Quit) |
07:56:06
| * Frippe | joined |
08:08:08
| * Alex_Gaynor | joined |
08:22:10
| * guor | quit (Remote host closed the connection) |
08:22:50
| * guor | joined |
08:45:11
| * stampho_ | changed nick to stampho |
09:12:41
| * faceleg | joined |
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
| * sanjoyd | joined |
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-Man | joined |
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
| * Net147 | joined |
11:24:29
| * tellnes | joined |
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
| * ager | quit (Remote host closed the connection) |
12:30:03
| * bnoordhuis | joined |
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
| * bnoordhuis | quit (Ping timeout: 245 seconds) |
13:34:15
| * Net147 | quit (Read error: Connection reset by peer) |
13:57:55
| * bnoordhuis | joined |
14:06:19
| * bnoordhuis | quit (Ping timeout: 252 seconds) |
14:12:29
| * carif | joined |
14:36:33
| * heath | quit (Read error: Connection reset by peer) |
14:36:49
| * heath | joined |
14:36:49
| * heath | quit (Changing host) |
14:36:49
| * heath | joined |
14:52:28
| * c4milo | joined |
14:59:31
| * bnoordhuis | joined |
15:38:46
| * RT|Chatzilla | quit (Quit: ChatZilla 0.9.86.1 [Firefox 2.0.0.22pre/2009081014]) |
16:14:16
| * Frippe | changed nick to Frippe2 |
16:30:24
| * Frippe2 | quit (Quit: Computer has gone to sleep.) |
17:00:29
| * tellnes | part ("WeeChat 0.3.9.2") |
17:39:23
| * carif | quit (Quit: Ex-Chat) |
17:45:42
| * bnoordhuis | quit (Ping timeout: 264 seconds) |
18:10:14
| * C-Man | quit (Ping timeout: 255 seconds) |
18:10:45
| * C-Man | joined |
18:10:46
| * C-Man | quit (Remote host closed the connection) |
18:51:30
| * bnoordhuis | joined |
18:55:54
| * bnoordhuis | quit (Ping timeout: 252 seconds) |
19:11:38
| * michael-robinson | joined |
19:11:48
| <michael-robinson> | Hello? |
19:11:54
| * michael-robinson | changed nick to faceleg|work |
19:32:42
| * bnoordhuis | joined |
19:35:33
| * carif | joined |
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
| * carif | quit (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
| * carif | joined |
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
| * bnoordhuis | quit (Ping timeout: 276 seconds) |
21:37:35
| * bnoordhuis | joined |
21:43:35
| * Net147 | joined |
22:03:11
| * Net147 | quit (Quit: I love my HydraIRC -> http://www.hydrairc.com <-) |
22:16:24
| * stalled | quit (Ping timeout: 264 seconds) |
22:26:26
| * RT|Chatzilla | joined |
22:26:45
| * carif | quit (Quit: Ex-Chat) |
22:41:15
| * stalled | joined |
23:23:03
| * c4milo | quit (Remote host closed the connection) |