- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] SystemLogger unrevealed :)

by Norbert Hartl

Am 23.02.2014 um 08:10 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > From my point of view, the problem comes from the following forces: > - the class side wants to be a log > - the instance side wants to be a log entry > > The better solution here would be to have two classes: Log and LogEntry. This is particularly important in the light of extensibility when people will want to define their own log entries. > Iâm not sure what you consider a âlogâ. To me that are all log entries (I like log events even more) and they are named log for simplicity. The âlogâ is more tied to the logger being file logger, database logger and so on. Maybe there are some words we need to straighten out first. Norbert > > > > On Sun, Feb 23, 2014 at 1:48 AM, <btc(a)openinworld.com> wrote: > Tudor Girba wrote: >> >> Excellent, Stef! >> >> I reviewed a bit the code: >> - The name log denotes the recording of multiple events. However, the Log class models only one event, not many. Thus, a more suitable name would be LogEvent. Or maybe LogEntry (like in StarTrek :)) > Except Log as only accessed as a class, not as instances. In days of old, sailing ships had a single Log book kept in the captain's room. Also Transcript is not called TranscriptEvent. So for me the semantics of Log are fine. > cheers -ben > > >> - Similarly, SystemLogger>>logs should be something like logEvents/logEvents. >> >> I like it a log that LogEvents are full objects because we can subclass them with specific semantics. This is particularly important if we want to build tools for custom applications. The first application I have in mind is Zinc. >> >> Zinc already comes with a logging mechanism that treats LogEvents as objects, but they are all of the same type, so in the end, if you want to track the events for request/response you have to reverse engineer the text. These semantics could be preserved. >> >> From what I see, the main difference between the Zinc log system and the SystemLogger is that the latter has a dispatcher that can dispatch to multiple loggers. Is there anything else that is different? I think it would be cool to merge the two. >> >> Doru >> >> >> 2014-02-22 13:24 GMT+01:00 Pharo4Stef <pharo4Stef(a)free.fr>: >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Feb. 23, 2014

Re: [Pharo-dev] SystemLogger unrevealed :)

by Norbert Hartl

Am 22.02.2014 um 20:27 schrieb GÃ¶ran Krampe <goran(a)krampe.se>: > Super man! > > Let's just merge all the "nice stuff" from the others. My SimpleLog is definitely not something I want to maintain if there is a better one that does the same and more. > > We have to learn merging projects ;) > +1 Norbert

Feb. 23, 2014

Re: [Pharo-dev] SystemLogger unrevealed :)

by Norbert Hartl

Am 22.02.2014 um 18:49 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > Excellent, Stef! > > I reviewed a bit the code: > - The name log denotes the recording of multiple events. However, the Log class models only one event, not many. Thus, a more suitable name would be LogEvent. Or maybe LogEntry (like in StarTrek :)) I had the same objections. But I can also see the huge win of the short name because it is used all the time. Norbert > - Similarly, System > Logger>>logs should be something like logEvents/logEvents. > > I like it a log that LogEvents are full objects because we can subclass them with specific semantics. This is particularly important if we want to build tools for custom applications. The first application I have in mind is Zinc. > > Zinc already comes with a logging mechanism that treats LogEvents as objects, but they are all of the same type, so in the end, if you want to track the events for request/response you have to reverse engineer the text. These semantics could be preserved. > > From what I see, the main difference between the Zinc log system and the SystemLogger is that the latter has a dispatcher that can dispatch to multiple loggers. Is there anything else that is different? I think it would be cool to merge the two. > > Doru > > > 2014-02-22 13:24 GMT+01:00 Pharo4Stef <pharo4Stef(a)free.fr>: > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Feb. 23, 2014

Re: [Pharo-dev] SystemLogger unrevealed :)

by Norbert Hartl

Am 22.02.2014 um 18:12 schrieb GÃ¶ran Krampe <goran(a)krampe.se>: > Hi! > > On 02/22/2014 05:26 PM, Pharo4Stef wrote: >> Hi goran >> >> There are only two questions: >> 'Why when I load code do I have to open the transcript before to see the shadow and undeclared. >> and why I cannot click on an object and jump to the broken code?" >> >> Now with SimpleLogger I imagine that I cannot log compiler shadow, donât you :). > > I am not quite sure what you are saying... Ah, you mean logging objects instead of strings? Sure, I didn't say SimpleLog was BETTER, I just said you didn't look at it and thus may be missing out on nice stuff that you can steal :) > Sure, seems so nobody knew about it then :) > - 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. > - Stealing whatever else seems good. > > Having log objects in the image is great. > >> 100 timesRepeat: [Goran repeatAfter: me what: âString sucks, string are dead objectsâ] > > Well, do remember that logs in a "system world" end up getting routed through syslog (and tons of variations on that theme) and eventually end up in event collecting systems etc - just look at fluentd.org to understand what I mean. > > So actually, I would make sure that SimpleLogger could also easily log in JSON, let me quote from fluentd: > > "Fluentd treats logs as JSON, a popular machine-readable format. It is written primarily in C with a thin-Ruby wrapper that gives users flexibility. > > Fluentdâs performance has been proven in the field: its largest user currently collects logs from 5000+ servers, 5 TB of daily data, handling 50,000 msgs/sec at peak time.â 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. Norbert > >> Iâm coding in Smalltalk and not in perl! > > In fact, now that I am looking at SimpleLog I realize we could have had an emitter that collected objects and just let "message" be whatever - and send asString or asJSON to it when it reaches the emitter instead. > >> Now if you want to have syslog output this is probably one method definition in a new formatter in our nice frameworks. >> Do you have an output that shows what is needed for sysLog? because I can add a package for sysLog outputter. > > Its very short code. Just steal it. I attached all the code as an .st fileout so that you can get it trivially. Its the SLSyslogSender class. > > The SLLogWatchDog is a trivial "send an email if a certain level is reached" with some bundling etc. > > SLLogFile has log file rotation. > > SLLogMorph is the simple search and filter UI. > > regards, GÃ¶ran > > > <SimpleLog.st>

Feb. 23, 2014

R: Morphic UI designer

by Lorenzo Schiavina

Hi Steff, may I ask why Phobos is not considered as a good candidate as a basis for an interface designer? I have experience with PARTS (which is the best application in the field I have ever seen in ST environment) and I believe that it could be used as a basis for tools of this kind. If anyone is interested in PARTS (included in VSE ST) as a model, I will be pleased to send it. Lorenzo Da: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Per conto di Pharo4Stef Inviato: sabato 22 febbraio 2014 17:19 A: Pharo Development List Oggetto: Re: [Pharo-dev] Morphic UI designer On 22 Feb 2014, at 15:24, jannik laval < <mailto:jannik.laval@gmail.com> jannik.laval(a)gmail.com> wrote: Does it make sense to add energy on it ? Probably, we should investigate UIPainter. may be the first thing to do would be to convert some of the widgets to work in Pharo with announcements. I did not have the time to verify but I did the following experience I built a simple naive browser using self changed:/updates then I wanted to rewrite it using Announcement only and it did not work probably because some of our widgets are not done to be used with announcements (probably they expect changedÂ.) so it may be the same with his widgets. Stef Jannik 2014-02-21 22:02 GMT+01:00 Stephan Eggermont < <mailto:stephan@stack.nl> stephan(a)stack.nl>: At the moment I'm moving, so I have very little time to do something about it. Current state is described in a thread from end of last year: <http://forum.world.st/have-a-question-for-morphic-Designer-in-pharo-td47313 07.html> http://forum.world.st/have-a-question-for-morphic-Designer-in-pharo-td473130 7.html Stephan -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur <http://www.jannik-laval.eu/> http://www.jannik-laval.eu <http://car.mines-douai.fr/> http://car.mines-douai.fr/

Feb. 23, 2014

Re: [Pharo-dev] SystemLogger unrevealed :)

by Tudor Girba

Hi, >From my point of view, the problem comes from the following forces: - the class side wants to be a log - the instance side wants to be a log entry The better solution here would be to have two classes: Log and LogEntry. This is particularly important in the light of extensibility when people will want to define their own log entries. Cheers, Doru On Sun, Feb 23, 2014 at 1:48 AM, <btc(a)openinworld.com> wrote: > Tudor Girba wrote: > > Excellent, Stef! > > I reviewed a bit the code: > - The name log denotes the recording of multiple events. However, the Log > class models only one event, not many. Thus, a more suitable name would be > LogEvent. Or maybe LogEntry (like in StarTrek :)) > > Except Log as only accessed as a class, not as instances. In days of old, > sailing ships had a single Log book kept in the captain's room. Also > Transcript is not called TranscriptEvent. So for me the semantics of Log > are fine. > cheers -ben > > > - Similarly, SystemLogger>>logs should be something like > logEvents/logEvents. > > I like it a log that LogEvents are full objects because we can subclass > them with specific semantics. This is particularly important if we want to > build tools for custom applications. The first application I have in mind > is Zinc. > > Zinc already comes with a logging mechanism that treats LogEvents as > objects, but they are all of the same type, so in the end, if you want to > track the events for request/response you have to reverse engineer the > text. These semantics could be preserved. > > From what I see, the main difference between the Zinc log system and the > SystemLogger is that the latter has a dispatcher that can dispatch to > multiple loggers. Is there anything else that is different? I think it > would be cool to merge the two. > > Doru > > > 2014-02-22 13:24 GMT+01:00 Pharo4Stef <pharo4Stef(a)free.fr>: > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 23, 2014