On 3/14/14 at 3:02 PM, fitz...@gmail.com (Nick Fitzgerald) wrote:
I feel very strongly that users debugging their sources that were
compiled to js should be able to set watch expressions and conditional
breakpoints in their source language.
My experience with debuggers says the while the vast
The accuracy of this aside, history shows that most of my users are
not satisfied by 'just debug the JS, it's fairly readable'. Maybe
emscripten, gwt, etc. users are more fluent in JS and don't mind
debugging it, but based on what I've seen, maybe not...
I do think it's important that source maps
K. Gadd wrote:
The accuracy of this aside, history shows that most of my users are
not satisfied by 'just debug the JS, it's fairly readable'. Maybe
emscripten, gwt, etc. users are more fluent in JS and don't mind
debugging it, but based on what I've seen, maybe not...
I do think it's important
I'm not married to the AST format I proposed.
I do feel very strongly that each language targeting JS shouldn't have
to write a browser devtools extension for every browser its users want
to debug.
I feel very strongly that users debugging their sources that were
compiled to js should be able to
As the maintainer of the ClojureScript compiler this doesn't sound like
much of a simplification. The sum total of source map support in
ClojureScript is 400 lines of Clojure. To support what's being proposed
would add a significant amount of complexity for something we don't care
about at all -
4) Browsers are still all over the place in how they report Error stack trace
information.
We (Firefox Developer Tools) purposefully don't expose source mapped
stacks to the web because it would require adding some kind of API to
know when source maps are done being fetched or blocking(!) on
I agree that the current source maps format does a poor job of
handling many translation/transpiling/js-as-compilation-target
scenarios. I do think it is worthwhile to try and build on the
existing format instead of reinvent it or significantly overhaul it,
though. The things it does, it does a
On Wed, Mar 12, 2014 at 2:00 PM, Nick Fitzgerald fitz...@gmail.com wrote:
If a debug format for targeting JavaScript were to be standardized, it
should do more than simply file/line/column translation. My thoughts
on this subject outgrew an email reply, so I have collected them here:
On Fri, Mar 7, 2014 at 8:52 PM, Peter van der Zee e...@qfox.nl wrote:
I think you want to take a look at source maps. They're specifically
designed to deal with this problem.
The problem is that a function like compileShader would look like this:
var compileShader(source){
var shader =
You may like to take a look at how the traceur compiler (
https://github.com/google/traceur-compiler) works. It allows one to write
code like
var statement = parseStatement `${result}[${index}++] = ${expression};`;
where the ${} syntax surrounds variables from the caller that are
substituted
not against preprocessing in any flavor if
that's your cup-o-tea. The problem rather is that one explicit usecase of
multiline strings (aka templates) is to make it easier to write DSLs. But
if you write DSLs and embedd the strings in your JS source somewhere,
you're gonna have to deal
. Well as fine a source maps ever work ;-)
That's a fine approach, and I'm not against preprocessing in any flavor if
that's your cup-o-tea. The problem rather is that one explicit usecase of
multiline strings (aka templates) is to make it easier to write DSLs. But
if you write DSLs and embedd
but it could source code just as well. And source maps work fine for our
code. Well as fine a source maps ever work ;-)
That's a fine approach, and I'm not against preprocessing in any flavor
if that's your cup-o-tea. The problem rather is that one explicit usecase
of multiline strings (aka templates
On Sat, Mar 8, 2014 at 11:14 AM, Mark Miller erig...@gmail.com wrote:
[...]
To see these for yourself in your own browsers, visit
http://google-caja.googlecode.com/svn/trunk/src/com/google/caja/ses/explicit.html
.
and click of the last two [+]s to expand these.
--
Cheers,
--MarkM
On Mar 8, 2014, at 11:05 AM, Mark S. Miller wrote:
[1] A more correct expansion is:
var whatsThis = func(
Object.freeze({
raw:Object.freeze(['', ' + ', '\\n = ', '']),
cooked: Object.freeze(['', ' + ', '\n = ', ''])
}),
x,
y,
x + y
);
On Fri, Mar 7, 2014 at 8:56 AM, Florian Bösch pya...@gmail.com wrote:
There's two complications with that. A string doesn't carry the line number
it comes from. Also, myfile.js might get concated with other files. And
lastly strings might get pasted together from smaller snippets.
I think you
I'm sorry if that's been asked before (I looked trough the archives trough
to 2012 and couldn't find a thread on it).
Are there any plans on adding multiline strings?
Some examples of multiline strings below.
Lua:
foo = [[A
Multiline
String]]
Python:
foo = '''A
Multiline
String
:
I'm sorry if that's been asked before (I looked trough the archives trough to
2012 and couldn't find a thread on it).
Are there any plans on adding multiline strings?
Some examples of multiline strings below.
Lua:
foo = [[A
Multiline
String]]
Python:
foo = '''A
Multiline
18 matches
Mail list logo
