[console] Console Module Proposal

[Kris Kowal]

This one should be easy. I've drafted a specification for (basically)
the "console" object you already know and love.

https://wiki.mozilla.org/ServerJS/API/console

I threw in a generalized "print" method and a couple log levels that
are handy for displaying unit tests in my experience. I also threw
some verbiage in there to avoid embrace-and-extend nomenclature
collisions in the future, and to encourage the standardization of
generally useful stuff.

Kris Kowal

[Davey Waterson]

Nice.

I usually like to have a setLevel or just a console.level property that
sets the verbosity of the logs, so that
debug logging statements can be enabled as required.

in jaxer we allowed our modules to have individual levels so that you
could just up the logging on the DB api to track
db stuff but not get drowned in, for example, request handling debug
messages.

[Ondrej Zara]

This one should be easy.  I've drafted a specification for (basically)
the "console" object you already know and love.

This "console" stuff seems to me as a strange hybrid between a "logger" module (as per previous discussion in logger thread) and an "assert" module (pass, fail). I am not sure whether I want to have these two mixed together.

For instance, I created a simple "assert" module for v8cgi, which is used like:

var assert = require("assert");
assert.assertEquals(1, "1", "type inequality");
assert.assertThrows( function() { throw new Error(); }, "exception throwing");
assert.fail("epic");

These test functions throw exceptions with appropriate messages, should their tests fail.

To report these errors to user, I would use either a simple "System.stdout" call, or some logger module (with its output set to "stdout" or similar, as needed).


To sum this up: I am not a big fan of porting a JS console calls to server "just because it exists on client" :)


Ondrej

[Tom Robinson]

I agree regarding the "pass"/"fail" levels.

In general, I'm for having this available for compatibility with
browser, but I don't think it should be the whole logging story. As we
discussed in the other thread, there's a lot of room for improvement,
and console.log is about as basic as it gets.

As such, I would stick with the basic error/warn/log/info/debug
methods available in the browsers, and make a real logger available in
a separate module.

Perhaps console.log etc could simply use the more advanced logger
module.

-Tom

[Kris Kowal]

On Mon, Apr 13, 2009 at 11:54 PM, Tom Robinson <tlrob...@gmail.com> wrote:
> On Apr 13, 2009, at 11:29 PM, Ondrej Zara wrote:
>> This "console" stuff seems to me as a strange hybrid between a
>> "logger" module (as per previous discussion in logger thread) and an
>> "assert" module (pass, fail). I am not sure whether I want to have
>> these two mixed together.
>

> I agree regarding the "pass"/"fail" levels.

Ok.

> As such, I would stick with the basic error/warn/log/info/debug
> methods available in the browsers, and make a real logger available in
> a separate module.
>
> Perhaps console.log etc could simply use the more advanced logger
> module.

This should be an explicit requirement, I think. The console module
should be a pure-javascript module in the standard library that always
defers to the logging module.

Kris Kowal

[George Moschovitis]

I don't think 'console' is a suitable name on the server side.
Typically logged messages are accumulated in a log file.
Maybe the implementation should be split in Logger and Assert modules.
Perhaps a higher level Console module could combine theses (and offer
compatibility with Client side)

-g.

[Wes Garland]

Kris:

Anything to do with console (and console-ish things like logging) should have a way to pass in a print function, which is then used internally by the module.

This is particularly important when writing curses applications; a straight stdout printer does not suffice.  I found this out when importing the MozShell module stuff in to GPSEE; MozShell being the functionality available from the Mozilla JS Shell (like a bytecode disassembler, gc heap dumper, etc).  In order to target the correct TUI window, I had to pass a JS print function into my native code, and replace printf-and-friends with calls into JavaScript.    (sample_programs/jsie.js shows the technique although the code in there is a little sloppy on the organizational side of things).

Wes

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

[Kris Zyp]

George Moschovitis wrote:
> I don't think 'console' is a suitable name on the server side.
> Typically logged messages are accumulated in a log file.
> Maybe the implementation should be split in Logger and Assert modules.
> Perhaps a higher level Console module could combine theses (and offer
> compatibility with Client side)
>
> -g.
>
>
>

I think it would be fine to give the module a different name.
Implementations that wish to provide compatibility with existing scripts
written for the web could still do:
console = require("Logger");
In order to provide the standard console.* functions. I suppose they
could also copy the functions from an Assert module on to the console
object as well.
Kris

[Daniel Friesen]

Seconded, `console` means console, it has nothing to do with logging
unless it has to do with always sending something out on stderr.
I'd sooner put stdin, stdout, and stderr inside of `console` than I
would put generic logging facilities inside of it.
It only makes sense in the browser where console is the FireBug console.

This would probably just get in the way considering I've been debating
on putting the actual console related stuff like stdout in a `console`
global in MonkeyScript.

~Daniel Friesen (Dantman, Nadir-Seen-Fire)

[Kris Kowal]

I think that all of the comments have been fair. Kris Zyp and others
trying to migrate code from client-side to server-side would be served
just as well by having a module by another name that they can bind to
the name "console" locally. I redact my request for "pass" and "fail"
log levels (even thought they're really pretty when /used/ by a "test"
module to visualize test results). Would someone be willing to
subsume the log/info/warn/error interface into a logging module, such
that it would be compatible with client "console" objects?

https://wiki.mozilla.org/ServerJS/API/console

Kris Kowal