I mentioned in another thread. #crLog, #logCr are intuitive and perfectly fine. Also hook Loggers first class into the system ( Toothpick ) and make it default to Transcript with these messages routed to the Logger. Transcript cr / current #crLog is akin to cout / System.out.println .. mostly deprecated in enterprise coding practices. On Mon, May 6, 2013 at 3:04 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:

On 05 May 2013, at 21:42, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

Hi guys

Stupidly I introduced log: a while ago to replace Transcript show:. Now is the current situation.

I still want to remove all the use of Transcript show:

Now since I thought I did a mistake with log: because it overload Integer>>log: I introduced trace: and traceCr:

Now I do not like traceCr: because it is not a cool message.

So what do we do:

1) we use crLog:, logCr: and deprecated log:

2) we use crTrace:, trace: and traceCr:

I really prefer solution 1 but I would like to hear from you.

Stef

I am for 1 as well, but I find #crLog: or #logCr: confusing - there should only be one system wide approach. Also, whether or not to add a Cr to a log message (or before or after it) is not a decision a client/user should have to make. Maybe Cr makes no sense, for example when log messages are added to a collection.

So I am for #log: as a simple and clear message.

The conflict with Number>>#log: is less important than that IMHO. Either we live with the conflict or we rename Number>>#log: to Number>>#logBase: or something like that.

I also like the convention of #value being sent by #log: to its argument. That allows for blocks that are not evaluated when logging is disabled.

My 2c.

Sven

-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

I think that Cr is useless because they are to separate line in text and I want to kill text and just get objects (that can produce text but from a list of objects I easily can add a cr between their printstring :) Stef On May 5, 2013, at 11:34 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:

On 05 May 2013, at 21:42, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

Hi guys

Stupidly I introduced log: a while ago to replace Transcript show:. Now is the current situation.

I still want to remove all the use of Transcript show:

Now since I thought I did a mistake with log: because it overload Integer>>log: I introduced trace: and traceCr:

Now I do not like traceCr: because it is not a cool message.

So what do we do:

1) we use crLog:, logCr: and deprecated log:

2) we use crTrace:, trace: and traceCr:

I really prefer solution 1 but I would like to hear from you.

Stef

I am for 1 as well, but I find #crLog: or #logCr: confusing - there should only be one system wide approach. Also, whether or not to add a Cr to a log message (or before or after it) is not a decision a client/user should have to make. Maybe Cr makes no sense, for example when log messages are added to a collection.

So I am for #log: as a simple and clear message.

The conflict with Number>>#log: is less important than that IMHO. Either we live with the conflict or we rename Number>>#log: to Number>>#logBase: or something like that.

I also like the convention of #value being sent by #log: to its argument. That allows for blocks that are not evaluated when logging is disabled.

My 2c.

Sven

-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

I like this proposal. Doru On May 6, 2013, at 8:00 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:

Hello.

What about logging levels?

I like "logInfo:", "logDebug:", "logTrace:". Or maybe it is better to split log with levels: "self log info:", "self log debug:", "self log trace:"

Best regards, Denis

2013/5/5 Stéphane Ducasse <stephane.ducasse@inria.fr> Hi guys

Stupidly I introduced log: a while ago to replace Transcript show:. Now is the current situation.

I still want to remove all the use of Transcript show:

Now since I thought I did a mistake with log: because it overload Integer>>log: I introduced trace: and traceCr:

Now I do not like traceCr: because it is not a cool message.

So what do we do:

1) we use crLog:, logCr: and deprecated log:

2) we use crTrace:, trace: and traceCr:

I really prefer solution 1 but I would like to hear from you.

Stef

-- www.tudorgirba.com "Don't give to get. Just give."

On 06 May 2013, at 08:00, Denis Kudriashov <dionisiydk@gmail.com> wrote:

I like "logInfo:", "logDebug:", "logTrace:". Or maybe it is better to split log with levels: "self log info:", "self log debug:", "self log trace:"

That is actually the interface that I use, as implemented in Zinc-HTTP-Logging, together with optional block arguments. Here is a simple example: logRequest: request "Log a request that was just read" self log info: [ lastRequest := request. 'Read ', request printString ] And a more complicated one (transaction is also a log level here): logRequest: request response: response started: initialMilliseconds self log transaction: [ String streamContents: [ :stream | request requestLine printMethodAndUriOn: stream. stream space; print: response code. response hasEntity ifTrue: [ stream space; print: response entity contentLength; nextPut: $B ]. stream space; print: (Time millisecondsSince: initialMilliseconds); nextPutAll: 'ms' ] ] I think it is really useful that the block is not executed when logging is disabled. Another advantage of block arguments is that there can be an error handler around its evaluation: errors while logging are very annoying and are better handled automatically. Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

+1! That's I wanted to come to, just step by step, by introducing level as an object first, then format, and so on. -- Best regards, Dennis Schetinin 2013/5/6 Norbert Hartl <norbert@hartl.name>

Am 06.05.2013 um 08:00 schrieb Denis Kudriashov <dionisiydk@gmail.com>:

Hello.

What about logging levels?

I like "logInfo:", "logDebug:", "logTrace:". Or maybe it is better to split log with levels: "self log info:", "self log debug:", "self log trace:"

I think that opens a can of worms. What Stef wants is a "say something" method that is easy to use and commonly useful. Adding logging levels is a specialized form of logging that is not commonly useful, it's just commonly used in less reflective environments. So my proposal would be to have an equivalent to "self log" where you can return your own logging facility on which you can do "self log info: 'something'".

I changed my kind of logging some time ago. I just log objects. A log object isn't much more than to put it on top of a collection. While I'm not using strings for logging I have objects where I can attach all my use case dependent stuff. You could even put something like a log level information in those objects. I log Errors as well as progress state objects,etc. It is easy to process the whole log collection (now or afterwards) because all necessary state is still there. Another reason why I don't like strings for that is that I put the log messages as json in elasticsearch/mongo because I want to query them to find errornous behaviour. Well, sometimes I do both: Store it in a database and write it to disk. Because I don't convert it to a string at first possible time I can do that easily.

We don't put sources in files so we shouldn't put log information only there. Make logging information a first class citizen!

Norbert

Best regards, Denis

2013/5/5 Stéphane Ducasse <stephane.ducasse@inria.fr>

...

Hi guys

Stupidly I introduced log: a while ago to replace Transcript show:. Now is the current situation.

I still want to remove all the use of Transcript show:

Now since I thought I did a mistake with log: because it overload Integer>>log: I introduced trace: and traceCr:

Now I do not like traceCr: because it is not a cool message.

So what do we do:

1) we use crLog:, logCr: and deprecated log:

2) we use crTrace:, trace: and traceCr:

I really prefer solution 1 but I would like to hear from you.

Stef

Yes I have that in what I prepare. Stef On May 6, 2013, at 8:00 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:

Hello.

What about logging levels?

I like "logInfo:", "logDebug:", "logTrace:". Or maybe it is better to split log with levels: "self log info:", "self log debug:", "self log trace:"

Best regards, Denis

2013/5/5 Stéphane Ducasse <stephane.ducasse@inria.fr> Hi guys

Stupidly I introduced log: a while ago to replace Transcript show:. Now is the current situation.

I still want to remove all the use of Transcript show:

Now since I thought I did a mistake with log: because it overload Integer>>log: I introduced trace: and traceCr:

Now I do not like traceCr: because it is not a cool message.

So what do we do:

1) we use crLog:, logCr: and deprecated log:

2) we use crTrace:, trace: and traceCr:

I really prefer solution 1 but I would like to hear from you.

Stef

...

I assume crLog:/logCr: is a short and convenient form of something else. How would these be called? Basically I want to log objects

YES!!!!

and only the default in Object should use Transcript in combination with "asString". On top of the short form a convenient selector that adds a line ending makes sense.

:) We are in sync :)

There needs to be a getter for a log where one can attach all needs like logging levels, log destinations, etc. So is the plan to have only the direct replacement for "Transcript show:" or something that can be extended/used differently.

Yes!

And why do we use cr?

because of text :) But since we will have objects :)

I think it is pretty common to us NL = newline. Where does this come from? Logically a "carriage return" enables you only to print something in bold while newline enables you to print a whole page :)

Norbert