[v8-users] Is it "okay" to use v8::Object::SetPrototype? Scary warnings about using Object.setPrototypeOf()..

2016-02-11 Thread Zac Hansen 
I want to do the equivalent of Object.create() in javascript from C++, but 
I don't see any way to specify the prototype of a new v8::Object from the 
API.

I was planning on creating the object with v8::Object::New and then calling 
v8::Object::SetPrototype() on it, until I saw this:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/setPrototypeOf

Warning: Changing the [[Prototype]] of an object is, by the nature of how 
modern JavaScript engines optimize property accesses, a very slow 
operation, in *every* browser and JavaScript engine. The effects on 
performance of altering inheritance are subtle and far-flung, and are not 
limited to simply the time spent in obj.__proto__ = ... statement, but may 
extend to *any* code that has access to *any* object whose [[Prototype]] has 
been altered. If you care about performance you should avoid setting the 
[[Prototype]] of an object. Instead, create a new object with the desired 
[[Prototype]] using Object.create() 

.


That's a pretty terrifying situation, so I want to make sure that using 
SetPrototype() doesn't incur that kind of penalty - at least on a newly 
created and unused object.

Thank you.

--Zac

-- 
-- 
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] Re: Exception::Error result is Local

2016-02-11 Thread Alex Kodat 
Would it be a waste of everyone's time if I created an issue and submitted 
a change to make Error return Local? FWIW, my inclination would 
make Factory::NewError return a JSObject and go from there though if people 
fee that's a bridge too far, I'd just put a checked cast into api.cc. It 
just seems kinda crazy for Factor::NewError to happily return to its caller 
if the situation is so grim it can't return an error object. In fact, I 
kinda wonder about it catching an exception thrown by the native 
constructor and returning that to the caller. It's really hard to picture 
what would be going on in such a scenario and if there's anything sensible 
to do beyond falling on one's sword.

Or maybe this is all too trivial to bother with in which case I appreciate 
the discussion, anyway.  

On Thursday, February 11, 2016 at 4:10:39 AM UTC-8, Yang Guo wrote:
>
> The issue is... with other parts of the API, when we return a MaybeLocal, 
> it may have thrown an exception, in which process we created an Error 
> object, and return an empty handle as result.
>
> This case is special. We want to create an Error object. If that itself 
> fails, throwing an exception makes no sense, since we cannot create another 
> Error object. We don't expect this to happen unless bootstrapping hasn't 
> finished yet, or we ran out of stack space, or something to that effect.
>
> I guess we could turn that into a MaybeLocal, but I don't really 
> think we should break the API for this small detail. That's just my opinion 
> though.
>
> Yang
>
> On Wednesday, February 10, 2016 at 6:39:44 PM UTC+1, Alex Kodat wrote:
>>
>> First, I'll confess I'm not a huge fan of MaybeLocal but, leaving that 
>> aside, even if I accept the utility of MaybeLocal I would expect it to be 
>> used for errors for which there's a reasonable hope of recovery and some 
>> way of actually testing the recovery code.
>>
>> If Exception::Error returns an empty result, the world (or at least the 
>> Isolate) has turned to yogurt and I feel I can't rely on any API calls 
>> actually working so it seems like there's not much for me to do other than 
>> crashing and I would have preferred the crash closer to the point where the 
>> construction of Error actually failed (Factory::NewError). Beyond that, 
>> short of an extremely artificial test where I say hack the Error native 
>> constructors, I can't see how I could possibly test any error recovery code 
>> for an Exception::Error failure. To me this sort of error seems closer to 
>> out of storage errors than unusual results errors.
>>
>> All that said, I guess MaybeLocal Exception::Error is better than 
>> Local or MaybeLocal as it better documents what an embedder 
>> should expect though the former might be accompanied by a comment that the 
>> ToLocalChecked on the return value should only ever fail in the event of 
>> catastrophic errors so you might not want to expend much bandwidth on 
>> worrying about it.
>>
>> On Wednesday, February 10, 2016 at 7:55:01 AM UTC-8, Daniel Vogelheim 
>> wrote:
>>>
>>> Generally, the API tries hard to pass errors up.
>>>
>>> I wonder if we should return MaybeLocal, then. There's been a 
>>> huge APi refactoring in the past to deprecate returning empty Locals (or 
>>> Undefined, or so) as error markers, and instead signal all such failures by 
>>> returning an empty MaybeLocal. Not quite what Alex asks for, but IMHO more 
>>> consistent with the remainder of the API.
>>>
>>>
>>> On Wed, Feb 10, 2016 at 4:26 PM, Alex Kodat  
>>> wrote:
>>>
 Thanks for that. I suspected as much. Is v8 really doing embedder's a 
 favor by exposing such a catastrophe to them? Presumably, if 
 Factory::NewError fails, we're out of storage (which v8 correctly doesn't 
 do embedders the favor of exposing to them), there's some other 
 catastrophic failure (like say the embedder's code has run amok clobbering 
 the v8 heap), or the native Error constructors have a problem 
 (inconceivable except maybe if a developer was fiddling with them). 

 None of these seem like cases where it's useful to share the pain with 
 the embedder code, especially as the situation is presumably that the 
 embedder code wants to reflect an error to the JS but whoops, all it can 
 get is an undefined from Exception::Error. Now what?

 Could I/should I open an issue for this? Sorry if this is a stupid 
 question, I'm still not quite sure when it's appropriate to post to the 
 list or open an issue. While I know you can code the change about as fast 
 as I can hit the Post button, I'd be happy to make the change myself. 
 FWIW, 
 I'd do the type-checking and cast in Factory::NewError and have it (them) 
 return a JSObject as it seems like it might be useful for other V8 code to 
 be able to count on NewError giving it an object (like for example, the 
 JSON parser?). Maybe this is too trivial to waste anyone's bandwidth on?

>>

Re: [v8-users] Building V8 Older versions

2016-02-11 Thread hitesh mehata 
Yeap, I completely understand. This is for the test purpose and I got few
dependencies which requires me to use this version. I see programs used to
compile with this version now fail to compile with newer versions, and
can't change/modify these programs.

Thanks,
Hitesh


On Thu, Feb 11, 2016 at 3:25 PM, Jakob Kummerow 
wrote:

> 3.9.24, are you sure? That's a daily development snapshot from almost 4
> years ago! I'd strongly advise against using it for anything, as it is
> probably full of bugs, including security vulnerabilities. I wouldn't be
> surprised if it didn't even compile any more with modern compilers, as
> toolchains tend to get stricter over time.
>
> I realize that this isn't what you wanted to hear. Sorry about that.
>
> On Thu, Feb 11, 2016 at 8:16 AM, hitesh mehata 
> wrote:
>
>> Hi,
>>
>> I am very new to v8, by looking at documentation, I could compile the
>> latest version of v8 javascript engine and as well able to write some
>> sample C++ programs.
>>
>> But my requirement is to build version 3.9.24 for x86/x64 Linux platform.
>> I couldn't find any steps and no clue how can I proceed further.
>>
>> Any help is much appreciated.
>>
>> Thanks,
>> Hitesh
>>
>> --
>> --
>> 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 mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "v8-users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/v8-users/DF6-TGtlX-Q/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> v8-users+unsubscr...@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.

Re: [v8-users] Re: Exception::Error result is Local

2016-02-11 Thread Yang Guo 
The issue is... with other parts of the API, when we return a MaybeLocal, 
it may have thrown an exception, in which process we created an Error 
object, and return an empty handle as result.

This case is special. We want to create an Error object. If that itself 
fails, throwing an exception makes no sense, since we cannot create another 
Error object. We don't expect this to happen unless bootstrapping hasn't 
finished yet, or we ran out of stack space, or something to that effect.

I guess we could turn that into a MaybeLocal, but I don't really 
think we should break the API for this small detail. That's just my opinion 
though.

Yang

On Wednesday, February 10, 2016 at 6:39:44 PM UTC+1, Alex Kodat wrote:
>
> First, I'll confess I'm not a huge fan of MaybeLocal but, leaving that 
> aside, even if I accept the utility of MaybeLocal I would expect it to be 
> used for errors for which there's a reasonable hope of recovery and some 
> way of actually testing the recovery code.
>
> If Exception::Error returns an empty result, the world (or at least the 
> Isolate) has turned to yogurt and I feel I can't rely on any API calls 
> actually working so it seems like there's not much for me to do other than 
> crashing and I would have preferred the crash closer to the point where the 
> construction of Error actually failed (Factory::NewError). Beyond that, 
> short of an extremely artificial test where I say hack the Error native 
> constructors, I can't see how I could possibly test any error recovery code 
> for an Exception::Error failure. To me this sort of error seems closer to 
> out of storage errors than unusual results errors.
>
> All that said, I guess MaybeLocal Exception::Error is better than 
> Local or MaybeLocal as it better documents what an embedder 
> should expect though the former might be accompanied by a comment that the 
> ToLocalChecked on the return value should only ever fail in the event of 
> catastrophic errors so you might not want to expend much bandwidth on 
> worrying about it.
>
> On Wednesday, February 10, 2016 at 7:55:01 AM UTC-8, Daniel Vogelheim 
> wrote:
>>
>> Generally, the API tries hard to pass errors up.
>>
>> I wonder if we should return MaybeLocal, then. There's been a 
>> huge APi refactoring in the past to deprecate returning empty Locals (or 
>> Undefined, or so) as error markers, and instead signal all such failures by 
>> returning an empty MaybeLocal. Not quite what Alex asks for, but IMHO more 
>> consistent with the remainder of the API.
>>
>>
>> On Wed, Feb 10, 2016 at 4:26 PM, Alex Kodat  
>> wrote:
>>
>>> Thanks for that. I suspected as much. Is v8 really doing embedder's a 
>>> favor by exposing such a catastrophe to them? Presumably, if 
>>> Factory::NewError fails, we're out of storage (which v8 correctly doesn't 
>>> do embedders the favor of exposing to them), there's some other 
>>> catastrophic failure (like say the embedder's code has run amok clobbering 
>>> the v8 heap), or the native Error constructors have a problem 
>>> (inconceivable except maybe if a developer was fiddling with them). 
>>>
>>> None of these seem like cases where it's useful to share the pain with 
>>> the embedder code, especially as the situation is presumably that the 
>>> embedder code wants to reflect an error to the JS but whoops, all it can 
>>> get is an undefined from Exception::Error. Now what?
>>>
>>> Could I/should I open an issue for this? Sorry if this is a stupid 
>>> question, I'm still not quite sure when it's appropriate to post to the 
>>> list or open an issue. While I know you can code the change about as fast 
>>> as I can hit the Post button, I'd be happy to make the change myself. FWIW, 
>>> I'd do the type-checking and cast in Factory::NewError and have it (them) 
>>> return a JSObject as it seems like it might be useful for other V8 code to 
>>> be able to count on NewError giving it an object (like for example, the 
>>> JSON parser?). Maybe this is too trivial to waste anyone's bandwidth on?
>>>
>>> On Wednesday, February 10, 2016 at 5:25:29 AM UTC-8, Yang Guo wrote:

 This probably never happens, but in case creating the error object 
 fails, undefined is returned.

 On Monday, February 8, 2016 at 9:03:42 PM UTC+1, Alex Kodat wrote:
>
> This must have been asked before but can't find an explanation so ... 
> just curious why Exception::Error et al are declared to have a 
> Local 
> result instead of Local. A not uncommon pattern is to create a 
> new 
> Error object and then set some properties on it which requires a 
> ->ToObject 
> or Local::Cast on the Exception::Error result. Trivial, but it 
> just 
> seems odd that it's necessary.
>
> Thanks
>
 -- 
>>> -- 
>>> 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" gro

Re: [v8-users] Building V8 Older versions

2016-02-11 Thread Jakob Kummerow 
3.9.24, are you sure? That's a daily development snapshot from almost 4
years ago! I'd strongly advise against using it for anything, as it is
probably full of bugs, including security vulnerabilities. I wouldn't be
surprised if it didn't even compile any more with modern compilers, as
toolchains tend to get stricter over time.

I realize that this isn't what you wanted to hear. Sorry about that.

On Thu, Feb 11, 2016 at 8:16 AM, hitesh mehata 
wrote:

> Hi,
>
> I am very new to v8, by looking at documentation, I could compile the
> latest version of v8 javascript engine and as well able to write some
> sample C++ programs.
>
> But my requirement is to build version 3.9.24 for x86/x64 Linux platform.
> I couldn't find any steps and no clue how can I proceed further.
>
> Any help is much appreciated.
>
> Thanks,
> Hitesh
>
> --
> --
> 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 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] Any way to throw an uncatchable (to javascript) exception from a FunctionTemplate callback function?

2016-02-11 Thread Ben Noordhuis 
On Thu, Feb 11, 2016 at 5:06 AM, Zac Hansen  wrote:
> I want to be able to stop the current javascript execution when a certain
> criteria is met from within a C++ function that the triggering javascript
> cannot catch.
>
> I want this information to propagate back to the c++ invoking the code
> somehow and have the data available to it, though.
>
> If I had to envision what I want, it would be
> isolate->ThrowException(some_data,
> special_magic_flag_so_javascript_does_not_see_this); but I'm open to other
> solutions.
>
> --Zac
>
> This question was asked back in 2012, but I don't see an answer.
>
> http://markmail.org/message/hee7rhmh4dk6yspx

You could use v8::Isolate::TerminateExecution() for that.  Check with
v8::Isolate::IsExecutionTerminating() or
v8::TryCatch::HasTerminated().

-- 
-- 
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] Link error in CentOS 7.2: cannot find -lstdc++

2016-02-11 Thread Daniel Brahneborg 
Thank you Louis, now it compiles and links perfectly.

Regards,
/Daniel


ons 10 feb. 2016 kl 21:56 skrev Louis Santillan :

> You're querying gcc but your build is using clang.  You can disable
> clang by doing `make x64.debug  GYPFLAGS=-Dclang=0`
>
> On Wed, Feb 10, 2016 at 11:30 AM, Daniel Brahneborg 
> wrote:
> > I'm trying to build v8 in Linux, on a quite recent CentOS.
> >
> > # cat /etc/centos-release
> > CentOS Linux release 7.2.1511 (Core)
> >
> > # rpm -q gcc
> > gcc-4.8.5-4.el7.x86_64
> >
> > # rpm -qa|grep stdc
> > libstdc++-4.8.5-4.el7.i686
> > libstdc++-devel-4.8.5-4.el7.i686
> > compat-libstdc++-33-3.2.3-72.el7.x86_64
> > libstdc++-4.8.5-4.el7.x86_64
> > libstdc++-devel-4.8.5-4.el7.x86_64
> > compat-libstdc++-33-3.2.3-72.el7.i686
> >
> > The "make x64.debug" command runs for a while, compiling lots
> > of files, and then starts to fail with this. How can it not  find
> libstdc++?
> > What have I missed?
> >
> > make[1]: Entering directory `/home/danbra/src/v8/v8/out'
> >
> > /home/danbra/src/v8/v8/third_party/llvm-build/Release+Asserts/bin/clang++
> > -B/home/danbra/src/v8/v8/third_party/binutils/Linux_x64/Release/bin
> -pthread
> > -fuse-ld=gold
> > -B/home/danbra/src/v8/v8/third_party/binutils/Linux_x64/Release/bin
> > -fuse-ld=gold
> > -B/home/danbra/src/v8/v8/third_party/binutils/Linux_x64/Release/bin -m64
> > -m64 -rdynamic -rdynamic -Wl,--threads -Wl,--thread-count=4 -Wl,--threads
> > -Wl,--thread-count=4  -o /home/danbra/src/v8/v8/out/x64.debug/mksnapshot
> > -Wl,--start-group
> >
> /home/danbra/src/v8/v8/out/x64.debug/obj.target/mksnapshot/src/snapshot/mksnapshot.o
> > /home/danbra/src/v8/v8/out/x64.debug/obj.target/tools/gyp/libv8_base.a
> >
> /home/danbra/src/v8/v8/out/x64.debug/obj.target/tools/gyp/libv8_nosnapshot.a
> >
> /home/danbra/src/v8/v8/out/x64.debug/obj.target/tools/gyp/libv8_libplatform.a
> >
> /home/danbra/src/v8/v8/out/x64.debug/obj.target/third_party/icu/libicui18n.a
> >
> /home/danbra/src/v8/v8/out/x64.debug/obj.target/third_party/icu/libicuuc.a
> > /home/danbra/src/v8/v8/out/x64.debug/obj.target/tools/gyp/libv8_libbase.a
> >
> /home/danbra/src/v8/v8/out/x64.debug/obj.target/third_party/icu/libicudata.a
> > -Wl,--end-group -ldl -lrt
> >
> /home/danbra/src/v8/v8/third_party/binutils/Linux_x64/Release/bin/ld.gold:
> > error: cannot find -lstdc++
> >
> > /Daniel
> >
> > --
> > --
> > 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 mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "v8-users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/v8-users/dLSMRRHo9Mk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> v8-users+unsubscr...@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.