*LoggingEvent* >> *printBasicsOn: aStream aStream nextPutAll: LoggingEvent timestampClass now asString; nextPutAll: ' '; nextPutAll: self levelString; nextPutAll: ' - '; nextPutAll: self messageString* I will like to see the timestamp printed out akin to the log4j output.. Also I had added a Logger class that will allow* multi channel logging* of the same log outputs: transcript, stream , file , socket, based on adding to a loggerCollection class instance variable. On Tue, Apr 9, 2013 at 1:20 PM, phil@highoctane.be <phil@highoctane.be>wrote:

Hi,

No, it didn't. There are missing selectors for DateAndTime and the tests aren't right in the first place.

No, didn't change SqueakSource. Anyone is welcome to do so.

Also, some FileSystem changes have to occur.

Phil

2013/4/9 Paul DeBruicker <pdebruic@gmail.com>

...

philippeback wrote

...

I've taken the Toothpick source (as mentioned in the Collaboractive book) and put the packages in Smalltalk Hub.

There were some things with trimming blanks which I fixed.

Now, some tests aren't right (but because they use dates from 2006 and we are in 2013)

If someone could look in there, it would be nice.

http://smalltalkhub.com/#!/~philippeback/Toothpick

Phil

So just changing from 2006 to 2013 made the tests pass?

Thanks for moving the repo. Did you edit the Squeaksource page to point at it?

-- View this message in context: http://forum.world.st/Toothpick-tp4680310p4680345.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

skrish On Tue, Apr 9, 2013 at 7:42 PM, phil@highoctane.be <phil@highoctane.be>wrote:

I can add you to the repo on STH. What's your user?

2013/4/9 S Krish <krishnamachari.sudhakar@gmail.com>

...

*LoggingEvent* >>

*printBasicsOn: aStream aStream nextPutAll: LoggingEvent timestampClass now asString; nextPutAll: ' '; nextPutAll: self levelString; nextPutAll: ' - '; nextPutAll: self messageString*

I will like to see the timestamp printed out akin to the log4j output..

Also I had added a Logger class that will allow* multi channel logging*of the same log outputs: transcript, stream , file , socket, based on adding to a loggerCollection class instance variable.

On Tue, Apr 9, 2013 at 1:20 PM, phil@highoctane.be <phil@highoctane.be>wrote:

...

Hi,

No, it didn't. There are missing selectors for DateAndTime and the tests aren't right in the first place.

No, didn't change SqueakSource. Anyone is welcome to do so.

Also, some FileSystem changes have to occur.

Phil

2013/4/9 Paul DeBruicker <pdebruic@gmail.com>

...

philippeback wrote

...

I've taken the Toothpick source (as mentioned in the Collaboractive book) and put the packages in Smalltalk Hub.

There were some things with trimming blanks which I fixed.

Now, some tests aren't right (but because they use dates from 2006 and we are in 2013)

If someone could look in there, it would be nice.

http://smalltalkhub.com/#!/~philippeback/Toothpick

Phil

So just changing from 2006 to 2013 made the tests pass?

Thanks for moving the repo. Did you edit the Squeaksource page to point at it?

-- View this message in context: http://forum.world.st/Toothpick-tp4680310p4680345.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

shouldn't be better to use the newer paulepulpe or something like that done by Santiago Bragañolo? I guess he did not write it from scratch just because.... On Tue, Apr 9, 2013 at 12:47 PM, phil@highoctane.be <phil@highoctane.be>wrote:

You have been added.

Have fun.

Like your work BTW Phil

2013/4/9 S Krish <krishnamachari.sudhakar@gmail.com>

...

skrish

On Tue, Apr 9, 2013 at 7:42 PM, phil@highoctane.be <phil@highoctane.be>wrote:

...

I can add you to the repo on STH. What's your user?

2013/4/9 S Krish <krishnamachari.sudhakar@gmail.com>

...

*LoggingEvent* >>

*printBasicsOn: aStream aStream nextPutAll: LoggingEvent timestampClass now asString; nextPutAll: ' '; nextPutAll: self levelString; nextPutAll: ' - '; nextPutAll: self messageString*

I will like to see the timestamp printed out akin to the log4j output..

Also I had added a Logger class that will allow* multi channel logging*of the same log outputs: transcript, stream , file , socket, based on adding to a loggerCollection class instance variable.

On Tue, Apr 9, 2013 at 1:20 PM, phil@highoctane.be <phil@highoctane.be>wrote:

...

Hi,

No, it didn't. There are missing selectors for DateAndTime and the tests aren't right in the first place.

No, didn't change SqueakSource. Anyone is welcome to do so.

Also, some FileSystem changes have to occur.

Phil

2013/4/9 Paul DeBruicker <pdebruic@gmail.com>

...

philippeback wrote

...

I've taken the Toothpick source (as mentioned in the Collaboractive book) and put the packages in Smalltalk Hub.

There were some things with trimming blanks which I fixed.

Now, some tests aren't right (but because they use dates from 2006 and we are in 2013)

If someone could look in there, it would be nice.

http://smalltalkhub.com/#!/~philippeback/Toothpick

Phil

So just changing from 2006 to 2013 made the tests pass?

Thanks for moving the repo. Did you edit the Squeaksource page to point at it?

-- View this message in context: http://forum.world.st/Toothpick-tp4680310p4680345.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

-- Mariano http://marianopeck.wordpress.com

On 04/10/2013 03:22 AM, Mariano Martinez Peck wrote:

shouldn't be better to use the newer paulepulpe or something like that done by Santiago Bragañolo? I guess he did not write it from scratch just because....

Personally I found Toothpick complicated back when I created SimpleLog. I also felt that playing nice with the outside world was important when it comes to logging so SimpleLog reuses the syslog levels standard and has a UDP emitter into syslog as an option. And a friend added a Morphic UI with filtering etc, very nice during development! regards, Göran

Logging is a simple task with bit of complexity thrown in with multi-channel, configurability, formatting to be included. Picking up from Log4J that seems to be a standard:VisualAge has adopted it as is.. Log4S * Loggers ( capture ) * Appenders ( stream to multi channel ) * Layouts ( formatting with regex ) formatting especially in emitting the current timestamp and the class>>method automatically I feel Toothpick can be extended to the above and with clear separation of lean classes it can serve the enterprise class of apps well. While SimpleLog, seems equally good, but I have not used, seems to offer one more error level and similar appenders capability. **************************** One observation I have is for all logger libraries to adopt *same api for logging *error viz: logger level: #warn message: 'This warning' . ( category is #default and most often usable) logger category:#perf level: #warn message: 'Below threshold of 100 trans per second' . convenience messages thereafter also be the same api viz: logger info: 'This info' . logger warn: 'This warning' . logger error: 'this exception' et als.. It will make it easier to switch logging framework if so required in future. On Wed, Apr 10, 2013 at 10:12 AM, Göran Krampe <goran@krampe.se> wrote:

On 04/10/2013 03:22 AM, Mariano Martinez Peck wrote:

...

shouldn't be better to use the newer paulepulpe or something like that done by Santiago Bragañolo? I guess he did not write it from scratch just because....

Personally I found Toothpick complicated back when I created SimpleLog.

I also felt that playing nice with the outside world was important when it comes to logging so SimpleLog reuses the syslog levels standard and has a UDP emitter into syslog as an option.

And a friend added a Morphic UI with filtering etc, very nice during development!

regards, Göran

Can you elaborate the use case / details on the block argument..? On Wed, Apr 10, 2013 at 11:38 AM, Sven Van Caekenberghe <sven@stfx.eu>wrote:

On 10 Apr 2013, at 07:27, S Krish <krishnamachari.sudhakar@gmail.com> wrote:

...

convenience messages thereafter also be the same api viz: logger info: 'This info' . logger warn: 'This warning' . logger error: 'this exception' et als..

Agreed, as long as you also accept blocks as argument so that nothing happens when logging is disabled.

Sven

PS: There is a small Zinc-HTTP-Logging framework in the image as well.

-- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

formatting especially in emitting the current timestamp and the class>>method automatically

I feel Toothpick can be extended to the above and with clear separation of lean classes it can serve the enterprise class of apps well.

While SimpleLog, seems equally good, but I have not used, seems to offer one more error level and similar appenders capability.

**************************** One observation I have is for all logger libraries to adopt same api for logging error viz:

logger level: #warn message: 'This warning' . ( category is #default and most often usable) logger category:#perf level: #warn message: 'Below threshold of 100 trans per second' .

convenience messages thereafter also be the same api viz: logger info: 'This info' . logger warn: 'This warning' . logger error: 'this exception' et als..

It will make it easier to switch logging framework if so required in future.

good idea.

"Another point is, should we not allow for arbitrary objects to be logged," The core framework should not be doing this, allow extension for anyone interested to do so at their risk and understanding. I will first attempt to get Toothpick to basic expectations, to then take up additional extensions. On Wed, Apr 10, 2013 at 2:42 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:

On 10 Apr 2013, at 10:58, stephane ducasse <stephane.ducasse@free.fr> wrote:

...

...

formatting especially in emitting the current timestamp and the class>>method automatically

I feel Toothpick can be extended to the above and with clear separation of lean classes it can serve the enterprise class of apps well.

While SimpleLog, seems equally good, but I have not used, seems to offer one more error level and similar appenders capability.

**************************** One observation I have is for all logger libraries to adopt same api for logging error viz:

logger level: #warn message: 'This warning' . ( category is #default and most often usable) logger category:#perf level: #warn message: 'Below threshold of 100 trans per second' .

convenience messages thereafter also be the same api viz: logger info: 'This info' . logger warn: 'This warning' . logger error: 'this exception' et als..

It will make it easier to switch logging framework if so required in future.

good idea.

Yes, I think we should first focus on the API for the code doing the logging. It would be very cool to have one API and possibly different logging destination, with different capabilities.

I already mentioned the block trick with the optional error handling. Another point is, should we not allow for arbitrary objects to be logged, so that afterwards there is an option to inspect them (this might be dangerous wrt destructive modifications and GC) - does Gemstone not have an 'Object Log' ?

Sven

-- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

I will work on these and start some commits this weekend. I hate to read transcript for compiler warnings. I want a real object that

I can manipulate.

logger as an instance of class Logger has manipulation capability. Anything else we need to add to it..?

Logging tool. 2013/4/9 kilon <thekilon@yahoo.co.uk>

I would not mind if someone added a short description of what toothpick is about .

-- View this message in context: http://forum.world.st/Toothpick-tp4680310p4680363.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.