February 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] SystemLogger unrevealed :)

by Norbert Hartl

Am 23.02.2014 um 13:32 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 23 Feb 2014, at 12:23, Norbert Hartl <norbert(a)hartl.name> wrote: > >> One of the core ideas is âlogging objects and not stringsâ. > > I am missing a clear example of that though. I am wondering what the expect interface is, how difficult/easy it is to fit in a new object as log (event). The âmessageâ instVar in Log is supposed to be any object not just strings. So the easiest way to âlogâ your object is myObject asLog emit What it does is to wrap a Log class around myObject being the message then. The creation of the Log class is dispatch through myObjects class so every business object can decide its own preferred log vehicle which can act as a bridge between special log objects and common log behavior. Does that answer your question? Norbert

Feb. 23, 2014

Re: [Pharo-dev] SystemLogger unrevealed :)

by Norbert Hartl

Am 23.02.2014 um 13:47 schrieb GÃ¶ran Krampe <goran(a)krampe.se>: > On 02/23/2014 01:21 PM, Norbert Hartl wrote: >>> Am 23.02.2014 um 13:02 schrieb GÃ¶ran Krampe <goran(a)krampe.se>: >>> Further, regarding class behaviors or not - in SimpleLog an instance of SLLog is the "log book". And you can have several if you like so the logging behavior should IMHO definitely be on the instance side. >>> >>> BUT... we simply added a Defauly class var and mirrored the public interface on the SLLog class side. Thus for most people, you just use the class side behaviors. >>> >>> Not sure why Stephane didn't do something similar. >>> >> Hmm, I thought it is just like that. Log class side being just easy access instance creation methods > > Ok, my bad in that case - I was merely referring to another post here that sounded like the class was the "log book" and the instance was the "log entry". I may be wrong, I haven't had time to look at the code. There are class side instance creations. An âemitâ on the instance side makes the log object emit through the log dispatcher where all the possible loggers are configured. Norbert

Feb. 23, 2014

Re: [Pharo-dev] SystemLogger unrevealed :)

by GÃ¶ran Krampe

On 02/23/2014 01:21 PM, Norbert Hartl wrote: >> Am 23.02.2014 um 13:02 schrieb GÃ¶ran Krampe <goran(a)krampe.se>: >> Further, regarding class behaviors or not - in SimpleLog an instance of SLLog is the "log book". And you can have several if you like so the logging behavior should IMHO definitely be on the instance side. >> >> BUT... we simply added a Defauly class var and mirrored the public interface on the SLLog class side. Thus for most people, you just use the class side behaviors. >> >> Not sure why Stephane didn't do something similar. >> > Hmm, I thought it is just like that. Log class side being just easy access instance creation methods Ok, my bad in that case - I was merely referring to another post here that sounded like the class was the "log book" and the instance was the "log entry". I may be wrong, I haven't had time to look at the code. regards, GÃ¶ran

Feb. 23, 2014

Re: [Pharo-dev] SystemLogger unrevealed :)

by Sven Van Caekenberghe

On 23 Feb 2014, at 12:23, Norbert Hartl <norbert(a)hartl.name> wrote: > One of the core ideas is âlogging objects and not stringsâ. I am missing a clear example of that though. I am wondering what the expect interface is, how difficult/easy it is to fit in a new object as log (event).

Feb. 23, 2014

Re: [Pharo-dev] SystemLogger unrevealed :)

by Norbert Hartl

> Am 23.02.2014 um 13:02 schrieb GÃ¶ran Krampe <goran(a)krampe.se>: > > Hey! > >> On 02/23/2014 11:34 AM, Norbert Hartl wrote: >> Sure, seems so nobody knew about it then :) > > Nobody? I have posted about SimpleLog to Pharo-dev 7 times I think, first in 2009 or something. And in 2010, 2012, 2013 :) > > And its on SqueakMap, so if I were to write a new logging framework I would have searched the "usual places" for inspiration - but perhaps Stephane did. > > It was written with Gjallar a looong time ago. > >>> - Using syslog levels, it is very standard and logging these days of clouds do NOT stay on the local machine. >>> - Stealing the syslog emitter, it is just 20 lines of code. >> >> That is a nice extension to SystemLogger. >> >>> - Stealing log file rotation perhaps? I think its in there. >> >> Are you are using this? I think it is not too common to do that in your application because there are tools like logrotate that do those things way better with compressing, deleting files, etc.. The only thing it needs is that the filestream sees when the file is gone and reopens. > > Yeah, I know logrotate. I don't recall exactly why we wrote it, it was a long time ago. > > Further, regarding class behaviors or not - in SimpleLog an instance of SLLog is the "log book". And you can have several if you like so the logging behavior should IMHO definitely be on the instance side. > > BUT... we simply added a Defauly class var and mirrored the public interface on the SLLog class side. Thus for most people, you just use the class side behaviors. > > Not sure why Stephane didn't do something similar. > Hmm, I thought it is just like that. Log class side being just easy access instance creation methods Norbert >> This is also a nice extension to the SystemLogger. The goal of the framework is simplicity _and_ extendability so you can add your use case with ease. >> I personally decided against using fluentd because I try to avoid much of the system complexity if I donât need it (I have not even close to 50000 reqs/s). Putting the logs from within the image into syslog only to have it transported to fluentd wouldnât be a clever thing to do. First you squeeze your object into a string just to have the fluentd tool apply a filter to create a json object of it. So converting a log to JSON and put it directly into fluentd would be the way to go. This way you can have fluentd for the buffering and for the single point of configuration for the log sink. >> If you look at the FormattingLogger it does provide the hooks for this. There is a conversion and a storing method because these are two things you want to adjust if you need a different format like JSON and a different way of storing (sockets, http,â¦). >> I use the SystemLogger to put all the logs into elasticsearch directly. > > I personally do not use Fluentd, I just mentioned it. Further, AFAICT there is no specific JSON format, instead it wants something like: > > <timestamp> > <tag> > { ...a JSON object... } > > > regards, GÃ¶ran > > PS. Regarding syslog levels or not - I don't really care but the concept is very known to developers. And it is also a fairly neat way of selecting "how much" you want to see. On the other hand, having the sender class or similar in the logged entries - and a search UI like we added - that was super useful. >

Feb. 23, 2014

Re: [Pharo-dev] SystemLogger unrevealed :)

by Norbert Hartl

> Am 23.02.2014 um 13:02 schrieb GÃ¶ran Krampe <goran(a)krampe.se>: > > Hey! > >> On 02/23/2014 11:34 AM, Norbert Hartl wrote: >> Sure, seems so nobody knew about it then :) > > Nobody? I have posted about SimpleLog to Pharo-dev 7 times I think, first in 2009 or something. And in 2010, 2012, 2013 :) > > And its on SqueakMap, so if I were to write a new logging framework I would have searched the "usual places" for inspiration - but perhaps Stephane did. > At the moment it is just me being ignorant :) Sorry Norbert > It was written with Gjallar a looong time ago. > >>> - Using syslog levels, it is very standard and logging these days of clouds do NOT stay on the local machine. >>> - Stealing the syslog emitter, it is just 20 lines of code. >> >> That is a nice extension to SystemLogger. >> >>> - Stealing log file rotation perhaps? I think its in there. >> >> Are you are using this? I think it is not too common to do that in your application because there are tools like logrotate that do those things way better with compressing, deleting files, etc.. The only thing it needs is that the filestream sees when the file is gone and reopens. > > Yeah, I know logrotate. I don't recall exactly why we wrote it, it was a long time ago. > > Further, regarding class behaviors or not - in SimpleLog an instance of SLLog is the "log book". And you can have several if you like so the logging behavior should IMHO definitely be on the instance side. > > BUT... we simply added a Defauly class var and mirrored the public interface on the SLLog class side. Thus for most people, you just use the class side behaviors. > > Not sure why Stephane didn't do something similar. > >> This is also a nice extension to the SystemLogger. The goal of the framework is simplicity _and_ extendability so you can add your use case with ease. >> I personally decided against using fluentd because I try to avoid much of the system complexity if I donât need it (I have not even close to 50000 reqs/s). Putting the logs from within the image into syslog only to have it transported to fluentd wouldnât be a clever thing to do. First you squeeze your object into a string just to have the fluentd tool apply a filter to create a json object of it. So converting a log to JSON and put it directly into fluentd would be the way to go. This way you can have fluentd for the buffering and for the single point of configuration for the log sink. >> If you look at the FormattingLogger it does provide the hooks for this. There is a conversion and a storing method because these are two things you want to adjust if you need a different format like JSON and a different way of storing (sockets, http,â¦). >> I use the SystemLogger to put all the logs into elasticsearch directly. > > I personally do not use Fluentd, I just mentioned it. Further, AFAICT there is no specific JSON format, instead it wants something like: > > <timestamp> > <tag> > { ...a JSON object... } > > > regards, GÃ¶ran > > PS. Regarding syslog levels or not - I don't really care but the concept is very known to developers. And it is also a fairly neat way of selecting "how much" you want to see. On the other hand, having the sender class or similar in the logged entries - and a search UI like we added - that was super useful. >

Feb. 23, 2014

Re: [Pharo-dev] SystemLogger unrevealed :)

by GÃ¶ran Krampe

Hey! On 02/23/2014 11:34 AM, Norbert Hartl wrote: > Sure, seems so nobody knew about it then :) Nobody? I have posted about SimpleLog to Pharo-dev 7 times I think, first in 2009 or something. And in 2010, 2012, 2013 :) And its on SqueakMap, so if I were to write a new logging framework I would have searched the "usual places" for inspiration - but perhaps Stephane did. It was written with Gjallar a looong time ago. >> - Using syslog levels, it is very standard and logging these days of clouds do NOT stay on the local machine. >> - Stealing the syslog emitter, it is just 20 lines of code. > > That is a nice extension to SystemLogger. > >> - Stealing log file rotation perhaps? I think its in there. > > Are you are using this? I think it is not too common to do that in your application because there are tools like logrotate that do those things way better with compressing, deleting files, etc.. The only thing it needs is that the filestream sees when the file is gone and reopens. Yeah, I know logrotate. I don't recall exactly why we wrote it, it was a long time ago. Further, regarding class behaviors or not - in SimpleLog an instance of SLLog is the "log book". And you can have several if you like so the logging behavior should IMHO definitely be on the instance side. BUT... we simply added a Defauly class var and mirrored the public interface on the SLLog class side. Thus for most people, you just use the class side behaviors. Not sure why Stephane didn't do something similar. > This is also a nice extension to the SystemLogger. The goal of the framework is simplicity _and_ extendability so you can add your use case with ease. > I personally decided against using fluentd because I try to avoid much of the system complexity if I donât need it (I have not even close to 50000 reqs/s). Putting the logs from within the image into syslog only to have it transported to fluentd wouldnât be a clever thing to do. First you squeeze your object into a string just to have the fluentd tool apply a filter to create a json object of it. So converting a log to JSON and put it directly into fluentd would be the way to go. This way you can have fluentd for the buffering and for the single point of configuration for the log sink. > If you look at the FormattingLogger it does provide the hooks for this. There is a conversion and a storing method because these are two things you want to adjust if you need a different format like JSON and a different way of storing (sockets, http,â¦). > I use the SystemLogger to put all the logs into elasticsearch directly. I personally do not use Fluentd, I just mentioned it. Further, AFAICT there is no specific JSON format, instead it wants something like: <timestamp> <tag> { ...a JSON object... } regards, GÃ¶ran PS. Regarding syslog levels or not - I don't really care but the concept is very known to developers. And it is also a fairly neat way of selecting "how much" you want to see. On the other hand, having the sender class or similar in the logged entries - and a search UI like we added - that was super useful.

Feb. 23, 2014

Re: [Pharo-dev] SystemLogger unrevealed :)

by Norbert Hartl

Iâm glad there were some many responses on the SystemLogger announcement from Stef. There popped up a lot of good ideas that will help to make it even more useful. I just wanted to add some points in a more compact fashion about this logging utility. One of the core ideas is âlogging objects and not stringsâ. Strings are useless when distributing information about state/objects/values. Strings are a requirement of the output medium we put our log information onto. So what needs to be achieved is just to have a conversion to strings as late as possible. This is before writing it to a stream. Strings are not the only format we want to have our log information converted to. One more reason not to produce strings in the first place. The way it is now you can have easily three loggers: - The SystemLogger which logs the object in memory. This can be used by a UI tool to display whatever information it want from the objects - A typical file logger that converts the object to a string and puts the converted log onto that stream - A database logger that converts e.g. to JSON and puts the converted log onto a socket that is connected to a database It maybe the case that not every log entry is suitable for each logger. That is why you can filters on the loggers to make every logger consume what I can/should consume. The SystemLogger should also stay very simple and should have plenty of extensions. There are a lot of extension points in the SystemLogger already but there is surely the need to improve that. No problem just complain about it. The basic module SystemLogger should only consist of the most basic classes so there are no further dependencies to it. This should make it easy to load it into the image without much thinking because it doesnât pull a huge pile in the back of it. The extensions add support for the most common things like stream loggers, formatting and so on. Those extensions are most likely used for supporting different logging types and media. The above can be considered as it is now. I just want to raise attention for something more. The topic was already raised (I would have bet on that): Log levels. I donât think strings are good log objects and I donât think log levels are something every log information should have. What we are used to is those typical logging types. But these are syslog entries or even unix syslog entries. I really donât want that the creep into the framework. Donât get me wrong I want to have that syslog entries are properly supported because a lot of people like to use them. But I donât want the main object model spoiled by that. Ok, we made it from strings to log entries. But can we just go a little step further and make it log events? It is just something like an announcement that has a specific purpose: being catched by the log dispatcher and distribute in a certain way? Imagine logging a HTTP response object. That has already internal state about being an error or not. So a log event carrying a http response that is converted and put into syslog can answer its severity depending on the state it already has. Why? Because we are logging objects that have decent behavior. The log level is meta data about log information that is unable to carry additional information (like a string). By not logging strings we solved that problem and removed partially the need to have log levels in the way they are. I know that a lot of use cases will still need to log level instVar but I hope I could raise attention to the fact that it shouldnât be contained in _the_ log object. Norbert

Feb. 23, 2014

Re: [Pharo-dev] [OT] Where should menues go ...

by Benjamin

On 23 Feb 2014, at 11:44, MartinW <wm(a)fastmail.fm> wrote: > > The difference of Pharo (and it's UI!) was what lured me into it, not what > constituted a barrier :) And while i would also make a case for difference > only for it's own sake, i think there are very good reasons for the pop-up > menus. They are very good reasons for popup menus. The work menu is not one of them Popup menus should (mainly) be used to propose contextual options. Now take a random menu in Pharo, and look for the items that applies only in the current context. Thatâs also the reason why the menu are far too long. Ben

Feb. 23, 2014

Re: [Pharo-dev] [OT] Where should menues go ...

by MartinW

Torsten Bergmann wrote > http://www.omgubuntu.co.uk/2014/02/locally-integrated-menus-ubuntu-14-04 > > http://www.youtube.com/watch?v=teAFgtHWDso Well, are not Smalltalks pop-up menus (i.e. the world menu and all the other context menus) solving the problem in the most beautiful way possible? I was shocked when i recently read somewhere on this list that people are thinking about introducing menu bars in order to make everything look more like everything else looks. The difference of Pharo (and it's UI!) was what lured me into it, not what constituted a barrier :) And while i would also make a case for difference only for it's own sake, i think there are very good reasons for the pop-up menus. m. -- View this message in context: http://forum.world.st/OT-Where-should-menues-go-tp4745736p4745799.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 23, 2014