Re: standardizing Error.stack or equivalent
Hi John, supposedly
https://developers.google.com/chrome-developer-tools/docs/javascript-debugging#breakpoints-dynamic-javascript
and
http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/#toc-sourceurl
document the emerging de facto std for providing this name to the existing
API. However, I have not seen it work on any browser. See point #5 at
https://mail.mozilla.org/pipermail/es-discuss/2014-March/036642.html. Am I
doing something wrong here that account for my not seeing this, or does it
in fact not work anywhere?
On Fri, Mar 28, 2014 at 9:41 AM, John Barton johnjbar...@google.com wrote:
Notice that the eval stack trace is not very useful in the common case
that the buffer is more complex than a single line and the eval is called
more than once. For eval, new Function(), document.write(script),
document.appendChild(script), and System.module() successful debugging --
and thus stack traces -- require unique, stable names for the buffers.
With these names, debugging with these features is no different than
normal source; without names, stack traces have limited value.
Stable automatic naming is difficult, since the code that uses these
features often does so inside of asynchronous loops (for loading). Making
it easy for developers to provide names is the simplest improvement for
these dynamic features. We could have names provided to eval() and new
Function(); we should ensure that new API has names, like System.module().
That would make a standard stack trace more useful.
jjb
On Thu, Mar 27, 2014 at 11:59 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 3/27/14 12:31 PM, Mark Miller wrote:
Mozillians, why did you add this extra information?
Looks like it was added in https://bugzilla.mozilla.org/
show_bug.cgi?id=332176
Before that, the stack claimed the url of the caller of eval() but a line
number which was the sum of the line number of the eval() call itself and
the line number of the code throwing the exception inside the eval string,
I believe, or some such insanity.
There's a lot of noise there in the discussion, but I think the key
recent part is https://bugzilla.mozilla.org/show_bug.cgi?id=332176#c40which
summarizes what I think we implemented. Note that per
https://bugzilla.mozilla.org/show_bug.cgi?id=332176#c42 we do something
similar for new Function() as well, so you can get a stack trace like so:
anonymous@http://example.com line 3 Function:1:1
@http://example.com:3:5
for a testcase like this:
script
try {
new Function(throw new Error())();
} catch (e) {
document.write(e.stack);
}
/script
-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: standardizing Error.stack or equivalent
Notice that the eval stack trace is not very useful in the common case that
the buffer is more complex than a single line and the eval is called more
than once. For eval, new Function(), document.write(script),
document.appendChild(script), and System.module() successful debugging --
and thus stack traces -- require unique, stable names for the buffers.
With these names, debugging with these features is no different than
normal source; without names, stack traces have limited value.
Stable automatic naming is difficult, since the code that uses these
features often does so inside of asynchronous loops (for loading). Making
it easy for developers to provide names is the simplest improvement for
these dynamic features. We could have names provided to eval() and new
Function(); we should ensure that new API has names, like System.module().
That would make a standard stack trace more useful.
jjb
On Thu, Mar 27, 2014 at 11:59 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 3/27/14 12:31 PM, Mark Miller wrote:
Mozillians, why did you add this extra information?
Looks like it was added in https://bugzilla.mozilla.org/
show_bug.cgi?id=332176
Before that, the stack claimed the url of the caller of eval() but a line
number which was the sum of the line number of the eval() call itself and
the line number of the code throwing the exception inside the eval string,
I believe, or some such insanity.
There's a lot of noise there in the discussion, but I think the key recent
part is https://bugzilla.mozilla.org/show_bug.cgi?id=332176#c40 which
summarizes what I think we implemented. Note that per
https://bugzilla.mozilla.org/show_bug.cgi?id=332176#c42 we do something
similar for new Function() as well, so you can get a stack trace like so:
anonymous@http://example.com line 3 Function:1:1 @http://example.com:3:5
for a testcase like this:
script
try {
new Function(throw new Error())();
} catch (e) {
document.write(e.stack);
}
/script
-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: standardizing Error.stack or equivalent
Hi John, supposedly https://developers.google.com/chrome-developer-tools/docs/javascript-debugging#breakpoints-dynamic-javascript and http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/#toc-sourceurl document the emerging de facto std for providing this name to the existing API. However, I have not seen it work on any browser. See point #5 at https://mail.mozilla.org/pipermail/es-discuss/2014-March/036642.html. Am I doing something wrong here that account for my not seeing this, or does it in fact not work anywhere? sourceURL and displayName are also working in Firefox. Not consistently yet, though. FWIW Firebug is making use of these in it's 2.0 alpha 1 version. See http://www.softwareishard.com/blog/firebug/firebug-2-support-for-dynamic-scripts/ . Would be great if these could be standardized. Sebastian ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [[Set]] and inherited readonly data properties
For the sake of examples, I honestly find current V8 hack, tested in
node.js inconsistent, kinda pointless, and quite disturbing, with or
without strict code.
```javascript
function Class(value) {
this.value = value;
}
Object.defineProperties(Class.prototype, {
value: {value: null},
method: {value: Class}
});
var a = new Class(123);
a.value; // 123 ... why?
var b = Object.create(Class.prototype);
Class.call(b, 123);
b.method(123);
b.value; // null ... I mean ... **null**
```
Even worst when it comes to default values ...
```javascript
function A(value) {
this.value = value;
}
Object.defineProperty(
A.prototype,
'value',
{value: 0}
);
function B(value) {
if (value) {
// best of all .. it won't assign
// and it won't throw neither
// congrats?
this.value = value;
}
}
Object.defineProperty(
B.prototype,
'value',
{value: 0}
);
var a = new A(123);
a.value; // 123
a.value = 456;
a.value; // 456
var b = new B;
b.value; // 0
b.value = 456;
b.value; // 0
var b = new B(123);
b.value; // 0
b.value = 456;
b.value; // 0
```
Why JavaScript engines need so much fragmentation with these kind of
unspeced behavior ... this, as a developer, I've never got it.
Best Regards
On Thu, Mar 27, 2014 at 10:28 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I know it won't get updated any time soon but unfortunately, and specially
in some emerging market, [these kind of phones](
http://www.amazon.com/LG-Navigation-OPTIMUS-ME-BLK/dp/B005HEEBQI/ref=sr_1_62?s=electronicsie=UTF8qid=1395940823sr=1-62keywords=android+phone)
are still quite common ... you guys should speed up spreading FirefoxOS on
$25 deals !!!
Anyway, I was just saying Android 2.x is like the IE6 of these days, IMO
... and I am not sure it will go away any time soon.
Best Regards
On Wed, Mar 26, 2014 at 11:36 PM, Brendan Eich bren...@mozilla.orgwrote:
Andrea Giammarchi wrote:
on Android 2.3.6 (or lower) you can [try this page](http://www.3site.eu/
jstests/configurable.html) which will show an alert like
```
Sorry for the initial false alarm, at least I am sure few didn't know
about the getters and setters bug in actually quite recent Android 2
browsers.
Android 2.3 (Gingerbread) may be quite recent on a lower-end phone, but
it is incredibly out of date and not being maintained. Especially its old
WebKit fork. V8 was backported, but that was in 2010 -- pretty sure it is
not patched up to anywhere near current level.
http://en.wikipedia.org/wiki/Android_version_history#
Android_2.2.E2.80.932.2.3_Froyo_.28API_level_8.29
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: [[Set]] and inherited readonly data properties
actually, if the value is passed, the `B` constructor will throw, but not
in `A`
Properties that has been directly assigned have no reason to be specified
as default in the prototype, if the constructor needs to directly assign
them ... right?
```javascript
function A(value) {
this.value = value || 0;
}
```
That's it, there is no reason to introduce an inconsistent behavior that
behaves in a completely unexpected way with properties maybe meant to be
inherited as non writable, as the specification, rightly or wrongly, say.
Will this ever be fixed? I start a post of 4 parts about descriptors, and
the more I write and test, the less I can explain people that ES5.1 is
actually a good standard ... there are so many little different things ...
but above one, I really don't get who even thought about it and why.
Apologies for the rant, I stop here, but I really hope this mess will be
cleaned up pretty soon.
Best Regards
On Fri, Mar 28, 2014 at 3:00 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
For the sake of examples, I honestly find current V8 hack, tested in
node.js inconsistent, kinda pointless, and quite disturbing, with or
without strict code.
```javascript
function Class(value) {
this.value = value;
}
Object.defineProperties(Class.prototype, {
value: {value: null},
method: {value: Class}
});
var a = new Class(123);
a.value; // 123 ... why?
var b = Object.create(Class.prototype);
Class.call(b, 123);
b.method(123);
b.value; // null ... I mean ... **null**
```
Even worst when it comes to default values ...
```javascript
function A(value) {
this.value = value;
}
Object.defineProperty(
A.prototype,
'value',
{value: 0}
);
function B(value) {
if (value) {
// best of all .. it won't assign
// and it won't throw neither
// congrats?
this.value = value;
}
}
Object.defineProperty(
B.prototype,
'value',
{value: 0}
);
var a = new A(123);
a.value; // 123
a.value = 456;
a.value; // 456
var b = new B;
b.value; // 0
b.value = 456;
b.value; // 0
var b = new B(123);
b.value; // 0
b.value = 456;
b.value; // 0
```
Why JavaScript engines need so much fragmentation with these kind of
unspeced behavior ... this, as a developer, I've never got it.
Best Regards
On Thu, Mar 27, 2014 at 10:28 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I know it won't get updated any time soon but unfortunately, and
specially in some emerging market, [these kind of phones](
http://www.amazon.com/LG-Navigation-OPTIMUS-ME-BLK/dp/B005HEEBQI/ref=sr_1_62?s=electronicsie=UTF8qid=1395940823sr=1-62keywords=android+phone)
are still quite common ... you guys should speed up spreading FirefoxOS on
$25 deals !!!
Anyway, I was just saying Android 2.x is like the IE6 of these days, IMO
... and I am not sure it will go away any time soon.
Best Regards
On Wed, Mar 26, 2014 at 11:36 PM, Brendan Eich bren...@mozilla.orgwrote:
Andrea Giammarchi wrote:
on Android 2.3.6 (or lower) you can [try this page](
http://www.3site.eu/jstests/configurable.html) which will show an
alert like
```
Sorry for the initial false alarm, at least I am sure few didn't know
about the getters and setters bug in actually quite recent Android 2
browsers.
Android 2.3 (Gingerbread) may be quite recent on a lower-end phone, but
it is incredibly out of date and not being maintained. Especially its old
WebKit fork. V8 was backported, but that was in 2010 -- pretty sure it is
not patched up to anywhere near current level.
http://en.wikipedia.org/wiki/Android_version_history#
Android_2.2.E2.80.932.2.3_Froyo_.28API_level_8.29
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
