Re: [v8-users] Adding functions to prototype template via SetAccessorProperty
Ok, now I see: Template::Set() still accepts templates, so Template::Set()
can still be used, just not with a function instance. I read the earlier
thread I referenced as saying we should use SetAccessorProperty() with the
template, as I did in my second code snippet, which of course doesn't work.
Thanks!
On Sunday, June 5, 2016 at 8:14:30 PM UTC-7, Toon Verwaest wrote:
>
> If you want the value to be an instance of a template, you should just Set
> the value to the template itself rather than the result of instantiating
> the template. (So drop GetFunction())
>
> Regards,
> Toon
>
> On Mon, Jun 6, 2016, 02:13 Mark Logan <ma...@artillery.com >
> wrote:
>
>> This is a very similar (perhaps identical) question to:
>> https://groups.google.com/forum/#!searchin/v8-users/SetAccessorProperty/v8-users/_u6dmOLAEnY/p3ErLIpoAAAJ,
>>
>> but unfortunately I couldn't learn enough from that thread. (Also: The v8
>> embedder's guide is out of date, and I read all the uses of
>> Template::SetAccessorProperty in the v8 tests but found no help there.)
>>
>> One used to be able to do the following:
>>
>> Local ctor = FunctionTemplate::New(...); // make a
>> constructor
>> auto prototype = ctor->PrototypeTemplate();
>> prototype->Set(String::NewFromUtf8("functionName"),
>> FunctionTemplate::New(...)->GetFunction());
>>
>> Now that Set is banned from accepting non-primitive values, we're
>> directed to use SetAccessorProperty for this sort of thing. My reading of
>> the thread that I linked above suggests that I should write the following:
>>
>> Local ctor = FunctionTemplate::New(...); // make a
>> constructor
>> auto prototype = ctor->PrototypeTemplate();
>> prototype->SetAccessorProperty(String::NewFromUtf8("functionName"),
>> FunctionTemplate::New(...));
>>
>> However, according to my reading of the API, this shouldn't work, because
>> we'd need to pass in a FunctionTemplate for a getter function that returns
>> the function I actually want to install. And indeed, this code doesn't seem
>> to work - the handler I provide for the FunctionTemplate is called with 0
>> arguments, just as if a getter were expected here.
>>
>> Creating a FunctionTemplate for a getter that returns a function is, as
>> far as I can tell, impossible to do easily and efficiently in the v8 API
>> (how do you create the function in advance and make it available to the
>> getter? A lambda won't work.)
>>
>> What's the right way to do this?
>>
>> Thanks,
>> Mark
>>
>> --
>> --
>> v8-users mailing list
>> v8-u...@googlegroups.com
>> http://groups.google.com/group/v8-users
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "v8-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to v8-users+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[v8-users] Adding functions to prototype template via SetAccessorProperty
This is a very similar (perhaps identical) question to:
https://groups.google.com/forum/#!searchin/v8-users/SetAccessorProperty/v8-users/_u6dmOLAEnY/p3ErLIpoAAAJ,
but unfortunately I couldn't learn enough from that thread. (Also: The v8
embedder's guide is out of date, and I read all the uses of
Template::SetAccessorProperty in the v8 tests but found no help there.)
One used to be able to do the following:
Local ctor = FunctionTemplate::New(...); // make a
constructor
auto prototype = ctor->PrototypeTemplate();
prototype->Set(String::NewFromUtf8("functionName"),
FunctionTemplate::New(...)->GetFunction());
Now that Set is banned from accepting non-primitive values, we're directed
to use SetAccessorProperty for this sort of thing. My reading of the thread
that I linked above suggests that I should write the following:
Local ctor = FunctionTemplate::New(...); // make a
constructor
auto prototype = ctor->PrototypeTemplate();
prototype->SetAccessorProperty(String::NewFromUtf8("functionName"),
FunctionTemplate::New(...));
However, according to my reading of the API, this shouldn't work, because
we'd need to pass in a FunctionTemplate for a getter function that returns
the function I actually want to install. And indeed, this code doesn't seem
to work - the handler I provide for the FunctionTemplate is called with 0
arguments, just as if a getter were expected here.
Creating a FunctionTemplate for a getter that returns a function is, as far
as I can tell, impossible to do easily and efficiently in the v8 API (how
do you create the function in advance and make it available to the getter?
A lambda won't work.)
What's the right way to do this?
Thanks,
Mark
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[v8-users] V8_WARN_UNUSED_RESULT on DefineOwnProperty?
I'm migrating some code to v8 5.0.71 (node v6.1.0), and replacing deprecated calls to ForceSet with DefineOwnProperty/CreateDataProperty. I'm a little confused as to why V8_WARN_UNUSED_RESULT is present in these declarations, when it wasn't present for ForceSet. Is there some new reason why I should not ignore the return value? Or, is ignoring the return value from DefineOwnProperty (or CreateDataProperty) no more dangerous than it was to ignore the return value from ForceSet? Thanks, Mark -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] Extracting correct stack traces on windows
On Friday, September 25, 2015 at 4:26:34 AM UTC-7, Ben Noordhuis wrote: > > > The machine code that V8 generates uses a custom calling convention > that's neither cdecl nor stdcall. I'm not aware of any tooling (that > works on Windows) that knows how to decode the stack trace. > Is the calling convention just similar enough to cdecl that stack traces on OS X / Linux work by chance? I've never had a problem with gdb/lldb. -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[v8-users] Extracting correct stack traces on windows
Is there any way to get a correctly decoded native (i.e. not js) stack trace, on Windows, from within C++ code that is called from javascript via the v8 api? I've noticed that stack traces captured by a crash reporter like BugSplat are bogus, and that the MSVS debugger is also incapable of decoding stacks that contain v8 frames. I assume that v8 uses cdecl, not stdcall, but I don't see why that would interfere with at least decoding return addresses correctly. However, all the stack traces I see wander off into nonsensical addresses, and never arrive back at main(), or whatever the thread entry point was. I've attached an example from the MSVS debugger at the end of the email. Thanks, Mark iojs.dll!v8::internal::FunctionCallbackArguments::Call(void (const v8::FunctionCallbackInfo &) * f) Line 34 C++ iojs.dll!v8::internal::HandleApiCallHelper<0>(v8::internal::Isolate * isolate, v8::internal::`anonymous-namespace'::BuiltinArguments<1> & args) Line C++ iojs.dll!v8::internal::Builtin_HandleApiCall(int args_length, v8::internal::Object * * args_object, v8::internal::Isolate * isolate) Line 1128 C++ 02300e9060bf() Unknown iojs.dll!v8::internal::Builtin_HandleApiCall(int args_length, v8::internal::Object * * args_object, v8::internal::Isolate * isolate) Line 1128 C++ 02300e9196f5() Unknown 00a64644ed68() Unknown 0319801a4019() Unknown 00bcd6a695d9() Unknown 02300e933a50() Unknown 03198019b831() Unknown 02300e906001() Unknown 00a64644ed20() Unknown 00a64644edc8() Unknown 02300ecaa7b5() Unknown 03198019b831() Unknown 037fd67299b9() Unknown 02d3013fdec1() Unknown 03198019b831() Unknown 00bcd6a695d9() Unknown 0319801a43c9() Unknown 037fd67286a1() Unknown 031980104131() Unknown 037fd66d9dd1() Unknown 037fd66d7b19() Unknown 00a64644ee20() Unknown 02300eaebfa6() Unknown 037fd67086e1() Unknown 037fd67274d9() Unknown 031980104111() Unknown 031980104131() Unknown 037fd66d9dd1() Unknown 031980104131() Unknown 037fd67274d9() Unknown 037fd6708a49() Unknown 037fd6708719() Unknown 00a64644ee68() Unknown 02300eabda57() Unknown 037fd6706ab1() Unknown 03198018c559() Unknown 0001() Unknown 037fd6727281() Unknown 0002() Unknown 00bcd6ae8181() Unknown 00bcd6a70139() Unknown 00a64644ef18() Unknown 02300e98018c() Unknown 037fd6706ab1() Unknown 0319801043a1() Unknown 037fd6708ab1() Unknown 031980104131() Unknown 00bcd6ae8181() Unknown 01fe3fe73271() Unknown 0319801043a1() Unknown 031980104131() Unknown 0319801043a1() Unknown 0319801043a1() Unknown 031980104111() Unknown 037fd6706da1() Unknown 031980104131() Unknown 031980104131() Unknown 0001() Unknown 037fd6708ab1() Unknown 031980104131() Unknown 037fd6727249() Unknown 01fe3fe73271() Unknown 00bcd6a70139() Unknown 00a64644ef50() Unknown 02300eadc1f0() Unknown 03198017ae89() Unknown 037fd6706ab1() Unknown 01fe3fe73271() Unknown 00bcd6aec989() Unknown 00bcd6ab1639() Unknown 00a64644efa0() Unknown 02300eab4318() Unknown 037fd6706ab1() Unknown 037fd6706c91() Unknown 031980104131() Unknown 00bcd6aec989() Unknown 00bcd6aceb51() Unknown 031980104361() Unknown 00bcd6af2bf1() Unknown 00bcd6aceb51() Unknown 00a64644f000() Unknown 02300ea88119() Unknown 037fd6706ab1() Unknown 037fd6706c91() Unknown 00bcd6aec989() Unknown 031980104131() Unknown 00bcd6af2bf1() Unknown 037fd6727161() Unknown 037fd6727099() Unknown 00bcd6aec989() Unknown 00bcd6a6a721() Unknown 00bcd6aceb51() Unknown 00a64644f038() Unknown 02300e919f23() Unknown 0319801a43c9() Unknown 00bcd6a6a721() Unknown 02300e919e21() Unknown 0008() Unknown -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[v8-users] Re: ArrayBuffer API triggers unnecessary mark-and-sweep events.
Thanks! Bug filed at https://code.google.com/p/v8/issues/detail?id=4409 -Mark On Tuesday, September 1, 2015 at 11:13:06 PM UTC-7, Michael Lippautz wrote: > > Hi Mark, > > The limits should be adjusted during Externalize(). Feel free to create a > bug. > > We have changes queued on this area that are to be landed soonish though. > Chances are good that it gets fixed right away. > > -Michael > -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[v8-users] ArrayBuffer API triggers unnecessary mark-and-sweep events.
If I iterate the following steps: auto contents = buffer->Externalize(); buffer->Neuter(); auto newBuffer = ArrayBuffer::New(isolate, contents.Data(), contents.ByteLength(), v8::ArrayBufferCreationMode::kInternalized); V8 repeatedly triggers full mark-and-sweep GC passes even though the size of the external heap is not increasing. This is because creating an internalized ArrayBuffer from existing memory adjusts v8s external heap estimate upward, but externalizing/neutering the same array does not appear to adjust that estimate downward. (See api.cc and runtime-typedarray.cc). I have a reproduction using iojs-3.2.0 (v8 version 4.4.63) here: https://github.com/mlogan/arraybuffer-gc This seems undesirable, although I can imagine there might be other cases where this is desirable behavior. Let me know if this should be considered a bug, I'm happy to file it. Thanks, Mark -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
