doesn't show accurate line number at web browser about debug

[constantx]

👍 if we can get correct line numbers with debug in the browser log ;)

[fijiwebdesign]

I started on a possible fix for this #273.

[TooTallNate]

You mean in the web browser?

[atian25]

yes

[TooTallNate]

Ya... I'm not sure if there's a way around this. We may be able to fix it in V8 using the stack trace API, but don't expect anything cross-browser.

[atian25]

well, I only care about Android WebView (2.2 ~ 4.4+)

[atian25]

I found angular.$log got the same problem, angular/angular.js#2975
is there any workaround like that ? bind

[TooTallNate]

I tried out the bind technique but the problem is that we do our own processing of the given arguments before calling the bound log function, so even still, it just points to the debug code rather than the user code that called the function.

I'm still pondering this but I'm not sure if there's a fix still...

[nicolashery]

Yes I noticed that too.

I've used bows before, and it seemed to show correct line numbers in the browser. I'm not sure what they are doing differently?

[manikantag]

@nicolashery Thanks for pointing to bows! It is logging correct line numbers. But I m not sure it's features complements 'debug.js' features, though.

[ProLoser]

The issue is that logs are deferred, do they really need to be? Can we just make deferring an optional argument flag?

[TooTallNate]

The issue is that logs are deferred, do they really need to be? Can we just make deferring an optional argument flag?

What makes you think that?

[ProLoser]

Isn't that what the stack traces shows? If I could just jump halfway up the stack trace and figure out where I called the log it would be fine. Or is it wrapped in a try catch? I don't remember, I created this issue #2975 over a year ago.

[TooTallNate]

It really just wraps the console.log call. It's not deferred using setTimeout or anything like that.

The problem is that the console will only display the call-site of the console.log() call, which always happens in the same place in debug, as opposed to the call-site of the debug() call, which is what we're actually interested in. Unfortunately I haven't come up with a solution for that.

[ProLoser]

@TooTallNate I meant they used to be deferred and executed in batch (like part of the $scope.$apply() stuff) This may have changed or I may have been confused from poking around the src code/stack trace, etc.

Can't we just move up the stack trace to see where the debug() was called? I mean if that worked it wouldn't be an issue, but from my recollection that just isn't the case.

[TooTallNate]

Ya AFAIK they've never been deferred.

Can't we just move up the stack trace to see where the debug() was called? I mean if that worked it wouldn't be an issue, but from my recollection that just isn't the case.

console.log() doesn't give you a trace though. You could switch to console.error() to get a trace, but then all the logs calls are red.

[b1rdex]

There is console.trace and it produces debug formatted messages (with colors and so on) and trace stack. Works in chrome, firefox and ie 11. Here is demo:

The one bad thing here — stack traces are not collapsed by default and log window is harder to read.

[wildermuthn]

I use a browserify transform that overrides the console.log() and inserts the line number. Works pretty well for my purposes, except my regex doesn't handle all cases correctly.

This also automates enabling of each file included in my browserify bundle (related to #154).

var through = require('through2');
var _ = require('underscore');

module.exports = function(file) {
  return through(function(buf, enc, next) {
    var parts = file.split('/');
    var filename = parts[parts.length - 1];
    if (filename === 'index.js') {
      filename = parts[parts.length - 2] + '-dir';
    }
    var bufString = buf.toString('utf8');
    var lines = bufString.split(/\r\n|\r|\n/);
    _.each(lines, function(line, i) {
      if (line.match('console') && file.match('app')) {
        var regExp = /\((.*)\)/;
        var insideParens = regExp.exec(line)[1];
        var lineNumber = '"Line ' + String(i + 1) + '"';
        lines[i] = line.replace('(' + insideParens + ')', '(' + insideParens + ',' + lineNumber + ')');
      }
    });
    if (file.match('app')) {
      var string = "var console = {log: require('debug')('" + filename + "')}\n\n" + lines.join("\r\n");
      this.push(string);
    }
        else {
            this.push(lines.join("\r\n"));
        }
    next();
  });
}

[TooTallNate]

That's pretty cool Nate :)

On Fri, Feb 20, 2015 at 10:27 AM, Truong Nguyen [email protected]
wrote:

[image: 👍] if we can get correct line numbers with debug in the
browser log ;)

—
Reply to this email directly or view it on GitHub
#105 (comment).

[AxelDelmas]

In Chrome you can now have the correct file and line number by blackboxing 'debug.js' script in the DevTool;
https://gist.github.com/paulirish/c307a5a585ddbcc17242

Only (quite annoying) problem is that it doesn't work if the script you blackbox is bundled together in a single file with your code. I hope chrome improves this behaviour in the future.

Meanwhile it might be a good ides to expose a standalone build, since this solution won't work if you require 'debug.js' in your code.

[binarykitchen]

@wildermuthn interesting code of yours. care to make it a npm package?

@TooTallNate yeah, this is tricky, tough problem to crack. any success at all yet?

[binarykitchen]

correction: bows does not seem to preserve line number

[binarykitchen]

that's a compromise i can live with for now:

    // workaround: since we cannot overwrite console.log without having the correct file and line number
    // we'll use groupCollapsed() and trace() instead to get these.
    function debug() {
        console.groupCollapsed(arguments)
        console.trace('Trace')
        console.groupEnd()
    }

[d-simon]

I will have to correct @binarykitchen, we just switched to bows because it indeed does indeed show the line number.
We'd actually prefer debug, but alas, for now we'll stay with bows.
👍 for this issue.

[airtonix]

We have an internal module we created to log stuff, it reveals the line in the source code it logged from.

Policy prevents me from dumping the source code, but I can clue you into how it's done for webkit/blink and ie:

isFunction (func)->
  return typeof func is 'function'

class Logger
  methods: [
    'log', 'error', 'debug', 'trace'
  ]
  constructor: ->
    (@bind(method) for method in @methods)

  bind: (method)->
    target = window.console[method]
    if isFunction(target) && isFunction(target.bind)
      @[method] = target.bind console
    else
      @[method] = Function.prototype.bind.call target, console


debug = new Logger().log

debug 'module start'

So the reason why debug will never show the source line number is because the exported function we all use after setting a namespace isn't a rebound function of console.log. It is instead a wrapper around some other complex logic wherein console.log is called with your arguments (which is why you see debug.js:117).

Showing line numbers from source, will require a complete rewrite.

[neojp]

I just tried #273. It works.

[thebigredgeek]

feel free to discuss further here. I think this should be something we handle with V3 #370