On 2013-10-16 19:26, H. S. Teoh wrote:

> Yeah, this is exactly what makes Javascript a royal pain in the neck to
> work with.  I have the dubious pleasure of having to work on a large
> non-trivial JS codebase at work, and it has a reputation of simply
> displaying a blank page when something goes wrong. Worse yet, there is
> some default error handler somewhere that swallows all JS errors, so no
> errors get logged to the browser's JS console at all -- you have to
> debug the entire 50k or so lines of JS with a blank page as your only
> clue as to what blew up.

Yeah, you really need to use the browser's developer tools to have any chance when working with JavaScript.

> (And don't get me started on IE6, which used to be the de facto standard
> demanded by every customer some years ago, which doesn't even *have* an
> error console. Fortunately, the world has moved on since.)

Actually, just a couple of weeks ago I found Firebug Lite. It's like Firebug but it's a booklet in pure JavaScript (ironically). That means you can use it in any browser, include IE6 (yes it works in IE6), iOS and other browsers missing developer tools.

I have also used remote debugging when I debugged a site in the iPhone simulator. It uses web sockets (I think) to send the data to another browser where the actual developer tools are.

-- 
/Jacob Carlborg

On 2013-10-16 21:08, simendsjo wrote:

> Remove all would probably be more in sync with getAttributes that
> returns all attributes, but removing only the first would allow greater
> flexibility. It's easy to remove all if you have a way to remove one,
> but the other way around isn't as easy :)

How would you remove all? I guess something like this:

!@(foo, foo)

But how can that be generalized? Unless we get a trait for removing attributes.

-- 
/Jacob Carlborg

On Wednesday, 16 October 2013 at 19:19:26 UTC, Jacob Carlborg wrote:
> On 2013-10-16 21:08, simendsjo wrote:
>
>> Remove all would probably be more in sync with getAttributes that
>> returns all attributes, but removing only the first would allow greater
>> flexibility. It's easy to remove all if you have a way to remove one,
>> but the other way around isn't as easy :)
>
> How would you remove all? I guess something like this:
>
> !@(foo, foo)
>
> But how can that be generalized? Unless we get a trait for removing attributes.

Yes, sorry. I was thinking about a new __trait and running a loop.
Is this when we should be dreaming of the all-powerful AST macros again?

On 2013-10-16 21:23, simendsjo wrote:

> Yes, sorry. I was thinking about a new __trait and running a loop.
> Is this when we should be dreaming of the all-powerful AST macros again?

Yes, AST macros will solve everything :)

-- 
/Jacob Carlborg

On 10/16/2013 8:37 AM, Sean Kelly wrote:
> I'm reasonably okay with dynamic languages so long as you can require a
> variable to be declared before it's used.  Those that implicitly declare on
> first assignment are a nightmare however. I once spent an entire day
> debugging a Lua app that turned out to be broken because of a typo in an
> assignment. Never again.

Implicit declaration is such a bad idea; I wonder why it keeps reappearing in every new dynamic language du jour.

On Wed, 16 Oct 2013 10:26:37 -0700
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
> 
> (And don't get me started on IE6, which used to be the de facto standard demanded by every customer some years ago, which doesn't even *have* an error console. Fortunately, the world has moved on since.)
> 

I remember going through the same hell with Safari. (I assume that's
been fixed by now, though.)

On Wednesday, 16 October 2013 at 20:20:18 UTC, Nick Sabalausky wrote:

> I remember going through the same hell with Safari. (I assume that's
> been fixed by now, though.)

It has similar developer tools like Chrome has.

--
/Jacob Carlborg

On Wed, Oct 16, 2013 at 09:26:13PM +0200, Jacob Carlborg wrote:
> On 2013-10-16 21:23, simendsjo wrote:
> 
> >Yes, sorry. I was thinking about a new __trait and running a loop. Is this when we should be dreaming of the all-powerful AST macros again?
> 
> Yes, AST macros will solve everything :)
[...]

Including world hunger and world peace. :P


T

-- 
Маленькие детки - маленькие бедки.

On Wednesday, 16 October 2013 at 17:27:54 UTC, H. S. Teoh wrote:

> some default error handler somewhere that swallows all JS errors

That would be function bound to window.onerror event. Remove it, or put breakpoint in it;

Also "use strict"; on new code. But it might be valuable to find out if it pays of putting it to use on old code (if it isn't too much warnings ->  refactoring needed). One benefit, among few others, is that assignment to undeclared variable throws exception.

On Wednesday, 16 October 2013 at 20:43:30 UTC, H. S. Teoh wrote:
> On Wed, Oct 16, 2013 at 09:26:13PM +0200, Jacob Carlborg wrote:
>> On 2013-10-16 21:23, simendsjo wrote:
>> 
>> >Yes, sorry. I was thinking about a new __trait and running a loop.
>> >Is this when we should be dreaming of the all-powerful AST macros
>> >again?
>> 
>> Yes, AST macros will solve everything :)
> [...]
>
> Including world hunger and world peace. :P
>
>
> T

"I would change the world, but God won't release the source code" :)