On Fri, Feb 26, 2016 at 4:53 PM, Stefano Sanfilippo
wrote:
> I ended up following Michael's suggestion. See if this works for you:
>
> https://codereview.chromium.org/1742723003/
The patch landed in master a few hours ago, FYI.
Best,
--S
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http
On 26 February 2016 at 21:58, Yang Guo wrote:
> Imo this does have some value. E.g. the debugger depends on the code to
> have a certain structure and source positions to map to certain break
> locations. Parser changes that cause big changes in .golden expectations
> might change observable debu
Imo this does have some value. E.g. the debugger depends on the code to
have a certain structure and source positions to map to certain break
locations. Parser changes that cause big changes in .golden expectations
might change observable debug stepping behavior, and should be looked at.
We had sim
On Fri, Feb 26, 2016 at 1:05 PM, wrote:
> Hi all,
>
> I've just landed a change to the way test-bytecode-generator works which
> means it is no longer necessary to manually amend the tests when you make a
> change that affects Ignition's bytecode generation.
>
> The bytecode expectations are now
I ended up following Michael's suggestion. See if this works for you:
https://codereview.chromium.org/1742723003/
--S
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups
"v8-dev"
Yes, but then the handler tables would contain a different prediction
again. We currently don't check the prediction field IIRC so it won't make
a difference ATM. I still feel the message handler has slightly "less
impact" in semantics, but I am fine either way.
Best regards,
Michael
On Fri, Feb
I thought that if you use a non-verbose TryCatch, it would just swallow the
error?
Yang
On Fri, Feb 26, 2016, 16:38 Michael Starzinger
wrote:
> You can just override the default message reporting by adding your own
> message handler via v8::Isolate::AddMessageListener. That will suppress the
>
You can just override the default message reporting by adding your own
message handler via v8::Isolate::AddMessageListener. That will suppress the
error message and you can print your own (or none at all of you wish to).
This is way easier and doesn't have nasty side-effects as a surrounding
TryCat
Good point, that might work, thanks Yang.
On 26 February 2016 at 15:10, Yang Guo wrote:
> You can use a v8::TryCatch scope to intercept exceptions. CHECK failures
> would still lead to crash. Not sure if that's an option for you, since I
> haven't looked at how the rebaseline script works.
>
> Y
You can use a v8::TryCatch scope to intercept exceptions. CHECK failures
would still lead to crash. Not sure if that's an option for you, since I
haven't looked at how the rebaseline script works.
Yang
On Fri, Feb 26, 2016, 16:02 'Ross McIlroy' via v8-dev <
v8-dev@googlegroups.com> wrote:
> The
The errors are produced by V8 for JavaScript errors (i.e., "Uncaught
ReferenceError: x is not defined") which are for things we are explicitly
testing.
We could redirect stderr to /dev/null while the tool is running (I'm
assuming this is what you mean?), however if we did this then it would be
dif
On Fri, Feb 26, 2016 at 2:54 PM, Yang Guo wrote:
> By silencing I actually just meant printing nothing to stderr and stdout
> when running the tool :)
Yep, I got that :) I was trying to say that I am not aware of any way
to tell the runtime not to print error messages to stderr.
If you have any c
By silencing I actually just meant printing nothing to stderr and stdout
when running the tool :)
Yang
On Fri, Feb 26, 2016, 14:44 Stefano Sanfilippo
wrote:
> On Fri, Feb 26, 2016 at 12:12 PM, Yang Guo wrote:
> > Is there a way to silence these runtime errors or at least add a comment
> > expl
On Fri, Feb 26, 2016 at 12:12 PM, Yang Guo wrote:
> Is there a way to silence these runtime errors or at least add a comment
> explaining that they are benign? Otherwise you will always have people ask
> questions when they rebaseline the first time.
At the moment there is no such way, but I migh
Is there a way to silence these runtime errors or at least add a comment
explaining that they are benign? Otherwise you will always have people ask
questions when they rebaseline the first time.
Yang
On Fri, Feb 26, 2016, 13:05 wrote:
> Hi all,
>
> I've just landed a change to the way test-byt
15 matches
Mail list logo
