- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Logging API discussion

by Denis Kudriashov

2016-04-27 21:12 GMT+02:00 stepharo <stepharo(a)free.fr>: > extra qualities. >> > > My problem with such approach is that it forces me to create hierarchy of > log events as subclasses of base log component. > > > not necessary > we could have Log being a potential wrapper. But what about my example below? > Imaging that my application already provide hierarchy of events but they > have no timestamps. How to log them? Should I use some WrapperSignal? > Now imaging that application uses some library which provides events too. > But this events are log entries themselves. What I will see in my logs? > I will see mix of WrapperSignal's and normal events. It would be not easy > to analize such log. > > Do you think it is not problem? > > That's why I want unified log entries. I would model it with single class > LogEntry which nobody needs to subclass. It would contain logging domain > information: timestamp, importance level, user message and whatever. And it > would have *content *property to keep logging object. So our tools can > rely on this structure to make it easy to work with logs. And when anybody > will look at particular log he will be sure that logging object is inside > "content" variables of each record > >

April 28, 2016

Re: [Pharo-dev] Logging API discussion

by Denis Kudriashov

2016-04-27 21:11 GMT+02:00 stepharo <stepharo(a)free.fr>: > > There is one problem with this approach when we split preparation and > emitting of log object. It will always produce garbage. If no logs will > have interest in myDomainObject or #warning-level messages application will > continue create log entries. > > Denis I do not get what you mean with the sentence above. With SystemLogger we would write: anObject asLog emit. And your code will always create Log instance which would be useless garbage when nobody interested in it (not logs want it). Same with Beacon: anObject asBeaconSignal log. And especially it is problem when we log thisContext: ContextStackSignal log It will always extract full stack information although not logs will record it. I think it is important to address this issue: logging code should be not expensive when nobody use logs.

April 28, 2016

Re: [Pharo-dev] Logging API discussion

by Tudor Girba

Hi, > On Apr 28, 2016, at 10:55 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-04-28 10:20 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > What I am talking about is that I don't want create MySpecialLog for any MySpecialDomainObject which I want to log. > > Traits? > > Put you logging api in a Trait instead of Object and let your MySpecialDomainObject use this trait ? > > Really? > Try remember usual workflow when we investigate some problems with code when we can't use debugger. We put kind of "Transcript show:" in multiple places to see state of our objects at concrete point of time. With object logging we will log our objects directly without converting to strings. Do you want to stop your "debugging workflow" every time you need to log objects which not support it? (to add special trait). This is a totally different scenario than the one of logging for an unforeseen situation. For this purpose, in Beacon we have dedicated signals such as those that capture the stack or the context and we can imagine several more. It is more powerful than Transcript and requires no string. Furthermore, because we have the type signal, we can also easily have an inspector that shows the relevant information. > But anyway with Trait you can't add timestamp to your domain object which is always required for logs (I think we all agree about timestamp). We can indeed agree on timestamp, but as Sven said, we might need flexibility on how to capture it (DateAndTime vs ZTimestamp). Cheers, Doru -- www.tudorgirba.com www.feenk.com "What is more important: To be happy, or to make happy?"

April 28, 2016

Re: [Pharo-dev] Logging API discussion

by Tudor Girba

Hi Denis, > On Apr 27, 2016, at 2:16 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2016-04-27 10:43 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: > I must confess I cannot follow you completely. What we were/are talking about is that the assumption a logging entry needs timestamp, log level and such is not appropriate. If you have legacy syslog style logging in mind it appears natural but for a lot of use cases it is not. > > Could you provide example where it is not? I just did a project in which I needed to understand a real-time parallel system that had 3 layers of abstractions. The code already had in place a log system based on log levels. If I opened the #debug level, I would get a ton of information, even though I wanted to focus on exactly one layer, or sometimes only one a certain type of leg entries. This is a common place scenario and it is time we can pick events based on their nature. The numbered layers come from languages where false=0, so letâs not use that as the standard we want to build on :). > Even if you could say that a timestamp is part of the logging domain it is not said if that timestamp needs to be part of the log object or the logger consuming this object. This question arises for every quality of a logging object. Even the logging level could be some behavioral quality that a logger matches to log levels. Contrary to this is logging thisContext which has to be done in the log object. > I think the hard part is the way of distribution of log objects and filtering of them. While the former is being discussed with Beacon the latter is mostly ignored while being really important. Not having default qualities of a log object is good on one hand but on the other hand the filtering is much harder. > In SystemLogger we didn't go far enough at first. The Log class contained level and such. That was the reason for me to split it into BasicLog consisting of timestamp and a message object and Log which contains the extra qualities. > > My problem with such approach is that it forces me to create hierarchy of log events as subclasses of base log component. But, you do not have to. Only if you want to distinguish between different log signals based on types. It is exactly the same type of problem that you have when you design the Exceptions in your system, or the domain-level Announcements in your system. Do you want to have fine grained types or use one single generic Exception? Do you want to have fine-grained or use plain Announcements? You can do it both ways, but it turns out you understand your system better if you use the types. Nevertheless, for prototyping purposes, you can certainly use quick logging. > Imaging that my application already provide hierarchy of events but they have no timestamps. How to log them? Should I use some WrapperSignal? > Now imaging that application uses some library which provides events too. But this events are log entries themselves. What I will see in my logs? > I will see mix of WrapperSignal's and normal events. It would be not easy to analize such log. > That's why I want unified log entries. I would model it with single class LogEntry which nobody needs to subclass. It would contain logging domain information: timestamp, importance level, user message and whatever. And it would have content property to keep logging object. So our tools can rely on this structure to make it easy to work with logs. And when anybody will look at particular log he will be sure that logging object is inside "content" variables of each record Signals are announcements. If you will have some events, those should be announcements. We could add to Announcements the ability to decorate an Announcement object (or at least a Signal one), we can tackle your scenario in a different way. Announcements is the unifying platform, not the logging. Logging is just an application of Announcements. But, the other point of view is that we should work to add instance variable filtering to Announcements, ideally in a way that does not pose performance penalty when you filter only by class. Once we do that we can have any combination you want. Also, just because you use Announcements does not put any limitation on the concrete domain objects you want to log. In any logging system you will have some wrapping object that will hold the concrete object. An Announcement is a great wrapping object exactly because it comes with the mechanism of transportation throughout the image, which is a technical prerequisite for logging anyway. Cheers, Doru -- www.tudorgirba.com www.feenk.com "Don't give to get. Just give."

April 28, 2016

Re: [Pharo-dev] Logging API discussion

by Denis Kudriashov

2016-04-28 10:20 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > What I am talking about is that I don't want create MySpecialLog for any >> MySpecialDomainObject which I want to log. >> > > Traits? > > Put you logging api in a Trait instead of Object and let your > MySpecialDomainObject use this trait ? > Really? Try remember usual workflow when we investigate some problems with code when we can't use debugger. We put kind of "Transcript show:" in multiple places to see state of our objects at concrete point of time. With object logging we will log our objects directly without converting to strings. Do you want to stop your "debugging workflow" every time you need to log objects which not support it? (to add special trait). But anyway with Trait you can't add timestamp to your domain object which is always required for logs (I think we all agree about timestamp).

April 28, 2016

Re: [Pharo-dev] Logging API discussion

by Denis Kudriashov

2016-04-27 20:50 GMT+02:00 stepharo <stepharo(a)free.fr>: > Beacon introduce WrapperSignal to solve it. But it only provides target > and timestamp. What I should do if I want to put little remark for my > object? And what if I want to put little remark for ThisContextSignal? > > My idea that logging should be as simple as possible and we not need > another "everything is signal" concept here: it is restriction. Everything > is object. And every object should be able to log. > > > In the minimalLog > > MinimalLog > object: MyCoolObject new; > emit > > no need of message And for my example when I want mark ThisContextSignal with extra user message how I can achieve it?

April 28, 2016

Re: [Pharo-dev] Logging API discussion

by Nicolai Hess

2016-04-28 10:13 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2016-04-27 20:50 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> >> And you say let's replace this "log object context" information with >> first class entities "typed signals". It means that for any possible case >> when I want to put something in log I should create class for new signal. >> It's just not practical. >> >> why? >> MySpecialLog >> ... >> emit >> > > What I am talking about is that I don't want create MySpecialLog for any > MySpecialDomainObject which I want to log. > Traits? Put you logging api in a Trait instead of Object and let your MySpecialDomainObject use this trait ?

April 28, 2016

Re: [Pharo-dev] Logging API discussion

by Denis Kudriashov

2016-04-27 20:50 GMT+02:00 stepharo <stepharo(a)free.fr>: > > And you say let's replace this "log object context" information with first > class entities "typed signals". It means that for any possible case when I > want to put something in log I should create class for new signal. It's > just not practical. > > why? > MySpecialLog > ... > emit > What I am talking about is that I don't want create MySpecialLog for any MySpecialDomainObject which I want to log.

April 28, 2016

Change Playground title based on the name of the first pane

by Peter UhnÃ¡k

Hi, would it be possible to change the Playground title when the first page changed? I know I can change the title through the top right corner, but just a double click might be more useful. Plus there could be some automatic naming pattern, because it would be nice to still see that it is playgroundâ¦ for example I tend to name them: "PL @ custom name". Thanks, Peter

April 28, 2016

Re: [Pharo-dev] [Pharo 5] Gettext

by Hilaire

Here are the overall process http://pharo.gemtalksystems.com/book/LanguageAndLibraries/Localisation For Dr. Geo I have bit more to decide which font to load at start up depending on the locale (This is where Pharo5's locale refactoring break it) but you should not need it for European languages. Hilaire -- Dr. Geo http://drgeo.eu

April 28, 2016