console API

[Irakli Gozalishvili]

What about ratifying console API ?

It's almost identical across major browsers at least the ones used by developers :)

http://getfirebug.com/wiki/index.php/Console_API
http://developer.apple.com/safari/library/documentation/AppleApplications/Reference/WebKitDOMRef/Console_idl/Classes/Console/index.html

either console can be a global or can be available as module
--
Irakli Gozalishvili
Web: http://rfobic.wordpress.com/
Phone: +31 614 205275
Address: Taksteeg 3 - 4, 1012PB Amsterdam, Netherlands

[Christoph Dorn]

Irakli Gozalishvili wrote:
> What about ratifying console API ?
>
> It's almost identical across major browsers at least the ones used by
> developers :)
>
> http://getfirebug.com/wiki/index.php/Console_API
> http://developer.apple.com/safari/library/documentation/AppleApplications/Reference/WebKitDOMRef/Console_idl/Classes/Console/index.html
>
> either console can be a global or can be available as module

+10 global
+9 module

Christoph

[Kris Kowal]

On Wed, Mar 10, 2010 at 4:57 PM, Irakli Gozalishvili <rfo...@gmail.com> wrote:
> What about ratifying console API ?
>
> It's almost identical across major browsers at least the ones used by
> developers :)
>
> http://getfirebug.com/wiki/index.php/Console_API

Sure. Can you write it up? I'm pretty sure it needs to be a module;
not another free-var. We might want to pick and chose which parts
should be feature-tested before use.

Kris Kowal

[Christoph Dorn]

I think console.log() can replace print() and I would rather have
"console" as a free variable than "print".

Being able to get debug messages with nicer formatting to a place where
you can view them is essential for newcomers I think. Each engine can
provide a console implementation that directs messages to the
appropriate destination and formats logged objects such as Errors by
attaching stack traces etc...

I use Firebug's console API when working with narwhal on xulrunner and
it is real nice to be able to inspect objects and not just see printed
strings. I envision debuggers connected to the console API that can
inspect object graphs even on server-side programs.

Christoph

[Wes Garland]

> I think console.log() can replace print() and I would rather have "console" as a free variable than "print".

Neither console nor print should be CommonJS-mandated free variables if you ask me.  Print tends to fall out because many embeddings include it.

I'm also not conviced a console module is the right place for log -- why not system?  Whose to say I have a console? 

What do you see the logging API looking like?  I personally would like to see a fairly full-featured deal like log4j.  I have a very tiny subset implemented now with syslog. It works very well.  It would be nice if I could connect to multiple logging facilities with it, but syslog is all I've implemented.

Don't take this as a negative message -- I welcome things like logging APIs -- I just don't like free variables or assumptions about the environment CJS programs are running in.  Unless, of course, the goal is talk about what a CommonJS console looks like -- in which case, I would advocate:
 1 - The console provider inject the console object
 2 - That console.log() be overrideable with something like  console.log = require("log4cjs").syslog("myprog", LOG_PID | LOG_NDELAY, LOG_MAIL);

Incidentally, a CommonJS console should not be conflated with the output from print. And, FWIW, I like the propsed system.print that's in the wiki, mandating system.stdout dereferencing and replaceability is a clever option.

Wes

--
You received this message because you are subscribed to the Google Groups "CommonJS" group.
To post to this group, send email to comm...@googlegroups.com.
To unsubscribe from this group, send email to commonjs+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/commonjs?hl=en.

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

[Hannes Wallnoefer]

2010/3/11 Wes Garland <w...@page.ca>:

>
> What do you see the logging API looking like?  I personally would like to
> see a fairly full-featured deal like log4j.  I have a very tiny subset
> implemented now with syslog. It works very well.  It would be nice if I
> could connect to multiple logging facilities with it, but syslog is all I've
> implemented.

Why not have both a full featured logging API and a console log
(whatever it's called), with the console simply being an easily
available default instance of a logger? In ringojs we have a fully
featured logging system[1][2], but instantiating a logger by name
(usually require('ringo/logging).getLogger(module.id)) is often too
cumbersome, so I just end up using print(). Having a predefined logger
instance in the console or system module would definitely help.

The Firebug console API seems like a good place to start. It's
slightly extensive, so I think we might want to trim off some less
essential features. One difference to our API is we just use {} as
format string placeholder instead of typed placeholders like %s or %n.
I like this very much, and I don't think these typed placeholders make
a lot of sense in JS.

[1] http://ringojs.org/api/ringo/logging
[2] http://ringojs.org/demo/logging

hannes

[Kris Walker]

No more free variables should be added to modules.

I also think that we are talking about two modules:

1) system.print()
Which is already ratified afaik.

2) console
Containing at least console.log, which MAY be a wrapper on
system.print() or MAY be vice verse.
Although it is true that not all platforms have a "console", most
browsers have some notion of a console, making this feature a nice
convenience that we can rely on.

I use CommonJS on the server, Narwhal for general purpose programming,
and CommonJS in the browser. While system.print() is right for most
of these use cases, it does not seem appropriate for the browser.

[Jack Troughton]

Here's the problem with that. You've just broken all those systems that don't actually have a "console".

It would make more sense to just define a general purpose stream class, and let programmers of specific implementations allow redirecting a stream to some kind of logger available on their system if they so choose. If you really want to have a logging facility available to everyone, make it a subclass of stream, and just define it that stream.write() prepends a hostname, program name, and timestamp to whatever the argument is. Implementation of where it goes can be handled by the person implementing the engine on a particular platform. This means that someone writing something on a nix can do things like:


myLog = new logger("syslog");
myLog.write("he blowed up good... blowed up real good");

while someone implementing a specialized embedded version can do something like:

FactoryController = 0xF340021XC;
myLog = new logger("FactoryController");
myLog.write("This robot is endangering Will Robinson!");

without having it break because the robot has no conception of a system console of any kind... but does have a signaling system where writing a byte at a time to a particular memory address results in it showing up on a console sitting on someone's desk.

But hey, what do I know? :)

Cheers,

Jack

[Kris Kowal]

On Wed, Mar 10, 2010 at 5:32 PM, Wes Garland <w...@page.ca> wrote:
> Neither console nor print should be CommonJS-mandated free variables if you
> ask me.  Print tends to fall out because many embeddings include it.

I think I would be fine with having separate standards that give us
require("system").print, require("console").*, and
require("logging").Logger().* in lieu of free variables, leaving
implementations free to hook these up in whatever way makes sense in
the embedding. I talked myself out of having a "system" free
variable. I don't want to talk myself out of a "print" free variable
that forwards to require("system").print and then
require("system").stdout.print, but I can. My reasoning for having
"print" free is just for pedagogy; when I, say, end up teaching
Computer Merit Badge to some 11-year-old, I want the first lesson to
be:

print("Hello, World!");

Having to import a module on the first lesson can be a bit of a
buzz-kill. Other than that, I can deal with having to import "system"
if I want to print stuff. I also think it make sense for print to
write to the console in browsers by default. I don't think that
replaces the functionality of "console", and it would be useful to
have a "console" module on the server-side, and I don't think that the
server-side analog of the "console" is the same thing as the root
serial console, although there are some similarities in intent: an
output space, hidden from the user.

As for the status of these proposals:

* The System/1.0 version does not contain "print". There is a
proposal to amend it, but we have not asked for a show of hands.

* We need the requirements for a Console/A proposal on our wiki for
review. Someone needs to take responsibility for this discussion and
do the wiki-wrangling.

Thanks,

Kris Kowal

[Irakli Gozalishvili]

I wrote up a proposal for a [console module](http://wiki.commonjs.org/wiki/Console) hopefully I managed to take into account all the comments in this thread. Most of it intentionally matches Firebug's Console API.

Hope it's a good starting point.

Regarding `print`. What about system  1.1 with added print to it.

I think weather or not print / global / system should be a free variables is whole different topic and should live in separate thread.

Regards,  

--
Irakli Gozalishvili
Web: http://rfobic.wordpress.com/
Phone: +31 614 205275
Address: Taksteeg 3 - 4, 1012PB Amsterdam, Netherlands

[Pete Duncanson]

A console API spec is nicely timed. I've been working on some new server-side stuff and dragged over an old Logger class to ease some debugging and bench marking. I re-named it console though as that is now how my mind is wired up and that of my work mates and to a large extent the javascript community as a whole. I see nothing wrong with the concept of a console being a bucket for debugging messages what ever it maybe on each system or however that maybe be implemented (Firebug, HTML in a DIV, textfile, flashing lights on a patch panel?)

There is alot of mileage in using the conventions already around to ease entry into using JS full on.

My 2p worth.

Pete

[Dean Landolt]

On Sat, Mar 20, 2010 at 8:26 PM, Pete Duncanson <pete.du...@googlemail.com> wrote:

A console API spec is nicely timed. I've been working on some new server-side stuff and dragged over an old Logger class to ease some debugging and bench marking. I re-named it console though as that is now how my mind is wired up and that of my work mates and to a large extent the javascript community as a whole. I see nothing wrong with the concept of a console being a bucket for debugging messages what ever it maybe on each system or however that maybe be implemented (Firebug, HTML in a DIV, textfile, flashing lights on a patch panel?)

There is alot of mileage in using the conventions already around to ease entry into using JS full on.

Nicely put. Plus prior art means fewer paint colors to choose :)

[Joe Walker]

Minor points:

- Chrome doesn't have groupCollapsed() or assert(), Safari doesn't
have groupCollapsed(), so I think it might make sense to leave those
out, if our goal is to mirror things you can safely do in a browser.
- I wonder what we might expect of the profile*(), time*() and dir*()
methods. Can we expect all server implementations to do sane things
with those? It could be useful to have them there and be no-ops, if
browser environment compliance is important.

Joe.

On Mar 20, 9:17 pm, Irakli Gozalishvili <rfo...@gmail.com> wrote:
> I wrote up a proposal for a [console module](http://wiki.commonjs.org/wiki/Console) hopefully I managed to take into
> account all the comments in this thread. Most of it intentionally matches
> Firebug's Console API.
>
> Hope it's a good starting point.
>
> Regarding `print`. What about system  1.1 with added print to it.
>
> I think weather or not print / global / system should be a free variables is
> whole different topic and should live in separate thread.
>
> Regards,
> --
> Irakli Gozalishvili
> Web:http://rfobic.wordpress.com/
> Phone: +31 614 205275
> Address: Taksteeg 3 - 4, 1012PB Amsterdam, Netherlands
>

> > commonjs+u...@googlegroups.com<commonjs%2Bunsu...@googlegroups.com>

[Irakli Gozalishvili]

Good points @joe I took out `groupCollapsed` from proposal and actually it did not made much of a sense anyway I think. Regarding assert, what version of chrome are you looking at I'm on a beta for OSX and it works as expected, so if your version doesn't has it yet most likely next one will get it, so I'd like to keep `assert` in.

Well if dir will just print all property names and values of the message it's already useful. I actually Ended up with `print(Object.keys(obj))` I think implementing time from a module is also straight forward. Regarding profile I don't know I think platform can at leas generate module require graph and program run-time, in case of non recursive program evaluation it will be possible to get a function call stack looking at a caller.


Any other point that needs to be addressed ?

Irakli Gozalishvili
Web: http://rfobic.wordpress.com/
Phone: +31 614 205275
Address: Taksteeg 3 - 4, 1012PB Amsterdam, Netherlands

To unsubscribe from this group, send email to commonjs+u...@googlegroups.com.

[Kris Walker]

The console proposal is doing WAY too much IMO. http://wiki.commonjs.org/wiki/Console

I think this should be pared back to

.log
.debug
.info
.warn
.error

and possibly adding console.critical()

I do not deny that the rest of the console tools in the proposal are
useful, I just think they belong in other modules. Maybe even outside
of the standard modules. As it is, the current console proposal
tightly couples functionality that is only loosely related in
practice.

On the other hand, debug, info, warn, error, and critical are quite
common output abstractions in the industry at large. Some
implementations may do different things with these abstractions, but I
can't think of any platforms that would not be able to represent each
of these log types in some sort of meaningful way.

Also, like Kris Kowal, I would love to see a free print() statement.
However, I don't think it should be allowed into the spec because of
the abominable window.print() in the browsers. Unfortunately.

- Kris

[Wes Garland]

Kris:

What you've described is a log API, not a console API.

Part of the problem here is that firebug et al have conflated logging and other things with console.

Perhaps we should re-thinking what the console API is - maybe we should consider it to be compatible with the  typical browser console object, and bring out a better logging API for server-side environments.  Libraries making use of this better logging API that happen to run on the browser could then require("logging") which in turn might be implemented with firebug's console on the brower, and syslog on the client.

I have a syslog module that I use on the server that works very well. It is based on log4j, and I rather like it.

Wes

--

You received this message because you are subscribed to the Google Groups "CommonJS" group.
To post to this group, send email to comm...@googlegroups.com.
To unsubscribe from this group, send email to commonjs+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/commonjs?hl=en.

[Irakli Gozalishvili]

The whole point of console module IMO is ability to run the same code across different engines browser / server / whatever and I would like to have it exactly the way it's known already in browsers cause it's kind of de facto standard. As mentioned in proposal it does not tries to replace any other more / less powerful logging / debugging facilities.

That's my personal opinion. If I'm in minority here I can try to rethinking this.

--
Irakli Gozalishvili
Web: http://rfobic.wordpress.com/
Phone: +31 614 205275
Address: Taksteeg 3 - 4, 1012PB Amsterdam, Netherlands

[Irakli Gozalishvili]

In order to move forward, should we start voting ? Someone want's to propose alternative ?

--
Irakli Gozalishvili
Web: http://rfobic.wordpress.com/
Phone: +31 614 205275
Address: Taksteeg 3 - 4, 1012PB Amsterdam, Netherlands

[Kris Walker]

Wes,

You're right, that is a logging API, but it is a lot less than what is
on the current proposal. In your mind does console just
contain .log(). If so, I've no problem with that either.

My problem is that the proposal is going too far as it is written.
I'm not going to want all that other stuff attached to the console
object. At a MAXIMUM I can see a use for debug, info, warn, err,
critical.

- Kris

[Ash Berlin]

On 23 Mar 2010, at 20:07, Irakli Gozalishvili wrote:
> The whole point of console module IMO is ability to run the same code across different engines browser / server / whatever and I would like to have it exactly the way it's known already in browsers cause it's kind of de facto standard. As mentioned in proposal it does not tries to replace any other more / less powerful logging / debugging facilities.
>
> That's my personal opinion. If I'm in minority here I can try to rethinking this.

As a general rule, compatibility with firebug/safari console object is good. But then i never use much beyond console.log myself. The other debug, warn, err etc make sense - not sure the rest of the stuff does (but that might just be because I didn't know it was there)

-ash

[Irakli Gozalishvili]

Well I do use most of them and found them very useful I would recommend to give them a try. P.S. Keep in mind that in FB / WI if you log object you can inspect, while in nonbrowser scenarios console.log({ foo: "bar"}) most likely will dump [object Object] which is useless that's where other methods will come into a game. We can call module debug or inspector if it will justify other methods exposed by it :)

Correct me if I'm wrong but, I do believe that people who use console in browser (for not only logging) will continue using console's non commonjs-yfied features, limiting console API will just introduce a gap. While on the other hand people who use just console.log will continue using it without caring much about rest of the API. Besides proposal explicitly point's out that representation is up to a platform which means representation can be 0 to a console.dir for example, point is that my code from browser will not throw exception in other platform if I happened to use console.dir

--
Irakli Gozalishvili
Web: http://rfobic.wordpress.com/
Phone: +31 614 205275
Address: Taksteeg 3 - 4, 1012PB Amsterdam, Netherlands

--

[Kris Walker]

I also use most of the methods that are in the console proposal, and I
also find them very useful.

I see the point that Irakli is making that limiting the console API
will create a gap between CommonJS and current mainstream use of the
console API. However, I believe that the console is simply an output
at the end of the day. It is an output that could be used for
debugging, error reporting, logging and maybe other yet to be
discovered use cases. If the API is allowed to expand too far, future
extensibility is limited.

The current CommonJS console proposal looks more like a third party
library or module to fulfill a wish list.

These extra features can, and should be, provided by third party
modules that may overload the console object however they see fit.

[Irakli Gozalishvili]

Can we move somehow forward with this ? Anyone want's to create second draft of a proposal ?

--
Irakli Gozalishvili
Web: http://rfobic.wordpress.com/
Phone: +31 614 205275
Address: Taksteeg 3 - 4, 1012PB Amsterdam, Netherlands

--

[Kris Kowal]

On Thu, Apr 1, 2010 at 7:25 AM, Irakli Gozalishvili <rfo...@gmail.com> wrote:
> Can we move somehow forward with this ? Anyone want's to create second draft
> of a proposal ?

There doesn't appear to be a great deal of contention, so moving
forward with this probably doesn't require a show of hands. Let's get
some implementations and a compliance test suite. I don't intend to
implement this specification myself, but if someone wants to
contribute one, I think that would be great. When there are three
compliant implementations, it's probably as good as ratified.

Kris Kowal

[Irakli Gozalishvili]

There is one for browsers I'll contribute one for a narwhal hopefully it will find it's way to ringo as well. Should it be a part of narwhal-lib or narwhal/lib ?

--
Irakli Gozalishvili
Web: http://rfobic.wordpress.com/
Phone: +31 614 205275
Address: Taksteeg 3 - 4, 1012PB Amsterdam, Netherlands

On Thu, Apr 1, 2010 at 20:46, Kris Kowal <cowber...@gmail.com> wrote:

contention

[Alexandre Morgaut]

I agree with Kris that not all methods of the console should be
required

In Wakanda we implemented log, debug, info, warn, error, assert, and
we considered a "fatal" method because it is one of the terms used in
log4j (which is a format supported by interesting tools)
http://supportweb.cs.bham.ac.uk/documentation/tutorials/docsystem/build/tutorials/log4j/log4j.html

We also considered added a level property (setLevel, may require to
add a getLevel) and some constants so you can write :

// possibly
var console = require("console");

// next log, debug, and info messages won't be output
console.level = console.WARN;

I think log, debug, info, warn, error are must have.
They are the most used feature.

I personally didn't used much group and groupEnd in browsers because
events handlers can easily break them (I'd expect group() to return an
identifier used for groupEnd()). On Server-side it might be less a
problem and could also be used to append the namespace in the log
format.

We also thought about a target property with another st of constants
(understand readonly properties, thanx ES5 it's even easier now)

Other methods are interesting and we may add it later

On Mar 23, 2:46 pm, Kris Walker <kixxa...@gmail.com> wrote:
> The console proposal is doing WAY too much IMO.http://wiki.commonjs.org/wiki/Console

[Irakli Gozalishvili]

I've send a pull request

http://github.com/Gozala/narwhal/commit/abd96e4889594750516af7c70f910872725962f2

--
Irakli Gozalishvili
Web: http://rfobic.wordpress.com/
Phone: +31 614 205275
Address: Taksteeg 3 - 4, 1012PB Amsterdam, Netherlands

[Alexandre Morgaut]

I like the fact you provide chaining

On Apr 2, 12:13 am, Irakli Gozalishvili <rfo...@gmail.com> wrote:
> I've send a pull request
>

> http://github.com/Gozala/narwhal/commit/abd96e4889594750516af7c70f910...
>

[Jonas Pfenniger (zimbatm)]

On Tue, Mar 23, 2010 at 10:07 PM, Irakli Gozalishvili <rfo...@gmail.com> wrote:
> The whole point of console module IMO is ability to run the same code across
> different engines browser / server / whatever and I would like to have it
> exactly the way it's known already in browsers cause it's kind of de facto
> standard. As mentioned in proposal it does not tries to replace any other
> more / less powerful logging / debugging facilities.
>
> That's my personal opinion. If I'm in minority here I can try to rethinking
> this.

I understand your point, but since the console object will not be a
free variable, it's name doesn't need to be "console".

Un-modularized code will need to be adapted anyways, and can restore
the console variable.
var console = require("logger");

[Ates Goral]

On Sat, Mar 20, 2010 at 5:17 PM, Irakli Gozalishvili <rfo...@gmail.com> wrote:
> I wrote up a proposal for a [console
> module](http://wiki.commonjs.org/wiki/Console) hopefully I managed to take
> into account all the comments in this thread. Most of it intentionally
> matches Firebug's Console API.
>
> Hope it's a good starting point.

My two cents on this proposal:

1. I agree with others that perhaps using printf-style token
references (e.g. %s) is not necessary in a language where type
coercion exists. In whatever logging implementations I've done so far,
I've been quite comfortable with using Perl-style tokens. I use
{property_name} and {array_index} support simultaneously:

// Use an object's properties
console.log("The value of {name} is {value}.", { name: "foo", value: 1 });

// Use argument indices (1-based):
console.log("The value of {1} is {2}.", foo, 1);

// Mix and match!
console.log("The value of {name} is {value} as of {2}.", { name:
"foo", value: 1 }, new Date());

2. I like the idea of group() for automatic indentation / hierarchical
relation of messages. However, I think I would just let it return a
new console instance, that has the indentation/hierarchy ingrained:

console.log("Running test suite " + suite.name);

runSuite(suite, console.group());

function runSuite(suite, console) {
utils.each(suite, function (test, name) {
console.log("Running test " + name);
...
});
}