Proposal for configurable recursion depth in `console.log()` and friends.

Showing 1-26 of 26 messages
Proposal for configurable recursion depth in `console.log()` and friends. Nathan Rajlich 8/16/11 11:25 AM
Often times, when debugging or developing, I want to print out a large object to the console so I can look at it on my terminal. A large, deep, JSON object is a good example of what I am talking about. The default `console.log` depth (3 is it?) sucks, and I'm often doing this dance:

    console.log(require('util').inspect(obj, true, 50));

So my proposal is to add a `console.depth` Number variable, that defaults to 3 or whatever, but is configurable by the user. `console.log`, `console.error`, etc. will use that Number to specify the recursion depth in util.inspect().

That's it; a relatively small change. I can prepare a patch if you all think it's a good idea.
Re: Proposal for configurable recursion depth in `console.log()` and friends. tjholowaychuk 8/16/11 11:31 AM
+1 I find this often too when I just need to quickly print out an AST.
Having the others would be nice too, console.colors = Boolean could be
pretty handy for CLI stuff as well, tools like cloudhead's
String.prototype colors thing could all utilize this unified flag
Re: [node-dev] Re: Proposal for configurable recursion depth in `console.log()` and friends. Bradley Meck 8/16/11 11:34 AM
for debugging and such console.error helps by doing an inspect and
also by being easily searched for when removing debugging. having this
might lead to people clobbering each other's console.depth in modules
but i can see its usefulness.

+0

Re: [node-dev] Re: Proposal for configurable recursion depth in `console.log()` and friends. Dean Landolt 8/16/11 11:35 AM


On Tue, Aug 16, 2011 at 2:31 PM, tjholowaychuk <tjholo...@gmail.com> wrote:
+1 I find this often too when I just need to quickly print out an AST.
Having the others would be nice too, console.colors = Boolean could be
pretty handy for CLI stuff as well, tools like cloudhead's
String.prototype colors thing could all utilize this unified flag


Node's console object goes a long way to align with the de facto firebug methods. +1 to having this configurable, but couldn't it be done somewhere else without pissing in the console namespace pool?
Re: Proposal for configurable recursion depth in `console.log()` and friends. tjholowaychuk 8/16/11 11:36 AM
it's not something you would leave in, at least I wouldn't personally,
just a quicker way to alter the default
Re: [node-dev] Re: Proposal for configurable recursion depth in `console.log()` and friends. Isaac Schlueter 8/16/11 11:45 AM
TJ, didn't you have a patch a while back that had it check members on
the "console" object?  That was a nice approach, I thought.  We should
resurrect that.
Re: Proposal for configurable recursion depth in `console.log()` and friends. tjholowaychuk 8/16/11 11:50 AM
Yeah I had something similar but you pointed out some unnecessary
accessors I had that could have just been regular props, and then I
dont know what happened haha.

On Aug 16, 11:45 am, Isaac Schlueter <i...@izs.me> wrote:
> TJ, didn't you have a patch a while back that had it check members on
> the "console" object?  That was a nice approach, I thought.  We should
> resurrect that.
>
>
>
>
>
>
>
Re: [node-dev] Re: Proposal for configurable recursion depth in `console.log()` and friends. Nathan Rajlich 8/16/11 11:50 AM
Yeah, I think of `console` as a debugging tool, I wouldn't expect these values to be changed to people's modules.
Re: Proposal for configurable recursion depth in `console.log()` and friends. mscdex 8/16/11 12:57 PM
On Aug 16, 2:50 pm, Nathan Rajlich <nat...@tootallnate.net> wrote:
> Yeah, I think of `console` as a debugging tool, I wouldn't expect these
> values to be changed to people's modules.

Agreed. If modules need more verbose output, they can always call
util.inspect() manually.

I'm +1 to having configurable options passed to util.inspect from
console.dir and the like.
Re: [node-dev] Re: Proposal for configurable recursion depth in `console.log()` and friends. Isaac Schlueter 8/16/11 1:14 PM
Yeah, we could do it like:

console.colors = true;
console.depth = 7;
console.showHidden = true;
console.log(someObject);

Don't need accessors or anything fancy.

Re: [node-dev] Re: Proposal for configurable recursion depth in `console.log()` and friends. Dean Landolt 8/16/11 1:44 PM


On Tue, Aug 16, 2011 at 4:14 PM, Isaac Schlueter <i...@izs.me> wrote:
Yeah, we could do it like:

console.colors = true;
console.depth = 7;
console.showHidden = true;
console.log(someObject);

Couldn't these go in a config object?

console.config = {
  console.colors: true,
  console.depth: 7,
  console.showHidden: true,
  console.writer: require("util").inspect

Hell, you could clean this up even better by offering up a higher-order function in util to build your own writer:

console.config = {
   console.writer: require("util").buildWriter({colors: true, depth: 7, showHidden: true})
}

It'd be great to have the console._writer functionality exposed as a documented API surface. This isn't anything fancy (okay, maybe buildWriter is a little fancy, but it's not at all necessary).

While we're at it, it would be nice to be able to control what streams the standard logger functions are written to -- we should be able to provide our own, or hook at least hook into the stream. The ones currently selected are pretty arbitrary -- with console.warn actually freakin' blocking (really?!). Can we at least have a map of some kind for users to provide streams for specific log levels?

I'll happily provide patches and tests for any of this that sounds reasonable.

Oh, and less reasonable comment: this is a good example of where a promise-based API would be very helpful. Callbacks don't really work here because you may be trying to log a callback function. The only sane way to find out when a log write completes is with something like a promise, right? This is necessary to sequence log writes -- not all that compelling of a use case, especially because it's easy enough to roll your own, but interesting as far as API expressibility goes.


Don't need accessors or anything fancy.

On Tue, Aug 16, 2011 at 12:57, mscdex <msc...@gmail.com> wrote:
> On Aug 16, 2:50 pm, Nathan Rajlich <nat...@tootallnate.net> wrote:
>> Yeah, I think of `console` as a debugging tool, I wouldn't expect these
>> values to be changed to people's modules.
>
> Agreed. If modules need more verbose output, they can always call
> util.inspect() manually.
>
> I'm +1 to having configurable options passed to util.inspect from
> console.dir and the like.

Re: [node-dev] Re: Proposal for configurable recursion depth in `console.log()` and friends. Isaac Schlueter 8/16/11 4:54 PM
On Tue, Aug 16, 2011 at 13:44, Dean Landolt <de...@deanlandolt.com> wrote:
> Hell, you could clean this up even better by offering up a higher-order

You should stop and go back 3 steps at the words of "higher-order".

Absurdly simple, or nothing.  I'm pretty sure those are the options.

Re: [node-dev] Re: Proposal for configurable recursion depth in `console.log()` and friends. Dean Landolt 8/16/11 6:08 PM



Yes, and I also said this just two sentences later: "okay, maybe buildWriter is a little fancy, but it's not at all necessary". It was just an API idea I was throwing out, but I shouldn't have as it distracted from the meat of what I was really proposing -- documenting the console._writer feature and giving it a good home.

But come on, since when did a function returning a function become so complicated? Shall we strip out every closure in node-core -- this requires higher-order functions. Oh, and callback APIs are higher-order too :)
Re: [node-dev] Re: Proposal for configurable recursion depth in `console.log()` and friends. Guillermo Rauch 8/16/11 6:16 PM
export NODE_CONSOLE_DEBUG_MAX_DEPTH_LEVEL=7
--
Guillermo Rauch
LearnBoost CTO
http://devthought.com

Re: [node-dev] Re: Proposal for configurable recursion depth in `console.log()` and friends. Isaac Schlueter 8/17/11 1:45 AM
>> Yes, and I also said this just two sentences later: "okay, maybe
>> buildWriter is a little fancy, but it's not at all necessary".

:)

>> But come on, since when did a function returning a function become so
>> complicated? Shall we strip out every closure in node-core -- this requires
>> higher-order functions. Oh, and callback APIs are higher-order too :)

That's true.  But console.log should be very very simple.  There are
already a few really nice inspectors with fancy features.

Re: Proposal for configurable recursion depth in `console.log()` and friends. tjholowaychuk 8/17/11 10:12 AM
@guillermo that would be nicer actually, not sure if core would go for
it but that beats chucking a console.depth= at the top of your script
and forgetting to take it out or something.

console.depth = parseInt(process.env.NODE_CONSOLE_DEPTH, 10) || 3;

I dont know
Re: Proposal for configurable recursion depth in `console.log()` and friends. Marco Rogers 8/17/11 1:44 PM
+1 to some simple extensions to console.

But why is there even a restriction on depth? Console and inspect are for debugging, who cares how long it takes?
Re: [node-dev] Re: Proposal for configurable recursion depth in `console.log()` and friends. Evan Larkin 8/17/11 1:47 PM
Personally, it's harder to read a long output than a short output.

In other words, I tend to do this:

inspect(something)
{
        a: {
                b: {
                        c: too deep
inspect(a.b.c)

etc etc.

It's easier for me to understand what I'm seeing in small chunks like that. I may be an unusual case....

-Evan


On Aug 17, 2011, at 3:44 PM, Marco Rogers wrote:

> +1 to some simple extensions to console.
>
> But why is there even a restriction on depth? Console and inspect are for debugging, who cares how long it takes?

Re: Proposal for configurable recursion depth in `console.log()` and friends. mscdex 8/17/11 3:02 PM
On Aug 17, 4:44 pm, Marco Rogers <marco.rog...@gmail.com> wrote:
> But why is there even a restriction on depth? Console and inspect are for
> debugging, who cares how long it takes?

My guess is for cyclic pointers, which could be traversed to an
infinite depth?
Re: [node-dev] Re: Proposal for configurable recursion depth in `console.log()` and friends. Isaac Schlueter 8/17/11 3:08 PM
No, cycles are detected.

The recursion depth is because we sometimes have very deep objects,
and you might not want to inspect req.socket.pair.encrypted.socket.etc

Re: [node-dev] Re: Proposal for configurable recursion depth in `console.log()` and friends. Matt Ranney 8/17/11 5:59 PM
On Tue, Aug 16, 2011 at 10:14 AM, Isaac Schlueter <i...@izs.me> wrote:
console.colors = true;
console.depth = 7;
console.showHidden = true;

+1 to that.  Simple and useful.

Re: [node-dev] Re: Proposal for configurable recursion depth in `console.log()` and friends. Charlie Robbins 8/22/11 11:12 PM
I'm inclined to agree with Bradley here and reluctantly -1 this feature (as an extension to the global console object). I say reluctantly because I actually use eyes.js (http://github.com/cloudhead/eyes) a lot because I want these features, but eyes has an API similar to that which Dean was suggesting:

var inspect = require('eyes').inspector({
    styles: {
        all: 'magenta',
        special: 'bold'
    },
    maxLength: 512
});

Adding options like `depth`, `showHidden`, etc. to this configuration object makes sense to me, but if it were global it would be an area of contention. Both for module developers or even within core (depending on what debugging preferences various core team members had). 

--Charlie
Re: Proposal for configurable recursion depth in `console.log()` and friends. seebees 8/23/11 2:08 PM
Why not use the format string?

console.log('%7', {largeObj});

On Aug 22, 11:12 pm, Charlie Robbins <charlie.robb...@gmail.com>
wrote:
> I'm inclined to agree with Bradley here and reluctantly -1 this feature (as
> an extension to the global console object). I say reluctantly because I
> actually use eyes.js (http://github.com/cloudhead/eyes) a lot because I want
> these features, but eyes has an API similar to that which Dean was
> suggesting:
>
> var inspect = require('eyes').inspector({
>     styles: {
>         all: 'magenta',
>         special: 'bold'
>     },
>     maxLength: 512
>
> });
>
> Adding options like `depth`, `showHidden`, etc. to this configuration object
> makes sense to me, but if it were global it would be an area of contention.
> Both for module developers or even within core (depending on what debugging
> preferences various core team members had).
>
> --Charlie
>
> On Wed, Aug 17, 2011 at 8:59 PM, Matthew Ranney <matt.ran...@gmail.com>wrote:
Re: [node-dev] Re: Proposal for configurable recursion depth in `console.log()` and friends. Nathan Rajlich 8/23/11 2:10 PM
Here's the real link, btw: https://github.com/cloudhead/eyes.js

Well eyes.js doesn't seem to use the native `util.inspect()` anyways, so I'm not sure how this proposal would affect that module.

However, the proposed additions only affect "end-users". That is, if a module has console.log calls scattered all over the place (or any other kind of non-configurable logging), I'm simply not going to use it. IMHO, `console.log` and friends are for the end-user ONLY, and on top of that, usually only for development/debugging.

That's why I'm +1 for initial values being read from `process.env` (so that I can just set it in my .bashrc and forget about it),
and +1 for `console.maxDepth`, `console.colors`, `console.showHidden` after the fact (in case I want to change it quickly in the REPL).
Re: [node-dev] Re: Proposal for configurable recursion depth in `console.log()` and friends. Pau Ramon 8/24/11 3:56 AM
I would add a different method, something like `console.inspect(object, config)`. 

I don't think is a good idea to allow modules to configure `console`. IMO, Core tools should be stateless.

// third-party module A
console.colors = true;

// module B
require('A');
console.log(foo); // colors! :(
Re: [node-dev] Re: Proposal for configurable recursion depth in `console.log()` and friends. Charlie Robbins 8/26/11 10:39 AM
I am +1 to this being configurable from process.env. In this way the configuration is absolute and not dependent on any code that might be included from a user-land module.
More topics »