- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Logging API discussion

by Denis Kudriashov

Hi 2016-04-26 20:16 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Try to look at it this way: by using objects (events, signals, > announcements, whatever) and just generating them on the spot and sending > them off somewhere, you have everything you need, without imposing any > restrictions. > If logging system will not allow me to log arbitrary object it would be restriction. And by "log object" I mean not just adding it to some log collection. But I need ability to mark objects with tags, messages and timestamps. > If you want to use log/severity levels and/or categories and/or tags, you > can do that. But I don't want to. Your objects will contain that info and > you will be able to filter on it. > Most of objects not have timestamp, tag or user message. So I can't filter them in such naked state. And instead of generating special objects with such information I want logging library take care about it. Of course for some cases I will need special objects for logs. But I should not be forced to do it every time.

April 26, 2016

Re: [Pharo-dev] Logging API discussion

by Sven Van Caekenberghe

Denis, Try to look at it this way: by using objects (events, signals, announcements, whatever) and just generating them on the spot and sending them off somewhere, you have everything you need, without imposing any restrictions. If you want to use log/severity levels and/or categories and/or tags, you can do that. But I don't want to. Your objects will contain that info and you will be able to filter on it. I take a very extreme standpoint here: there should be no requirements at all. Not for the kinds of objects that one can use, nor where/how they are sent to/handled. I even do not want a specific kind of timestamp imposed. DateAndTime is way too expensive and has either too much or not enough granularity (we have no nanosecond clock). There could be some convention (a trait maybe) that says #timestamp returns a Magnitude that can be used for that purpose. If you want a small system (builder) that makes it easier to construct and signal log events, then that could be provided, but is will always be quite specific to one person's taste. Making log events subclasses of Announcement and using an Announcer instance local to a subsystem is one easy implementation choice, but not necessarily the only one. One concrete (but not perfect) implementation of my ideas can be found in the package 'Zinc-HTTP-Logging' in your image. Sven > On 26 Apr 2016, at 17:31, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-04-26 17:28 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Please do not do that. This might make sense for C or Java (although it does not), but we have objects and we should filter based on those without relying on a rigid system based on random levels. Please. > > And I forgot mention that my proposed API is not prevent object filtering. All information is here. So it can be implemented. And it also can be implemented by announcements. > But here I just want to discuss API.

April 26, 2016

Re: [Pharo-dev] Logging API discussion

by Denis Kudriashov

2016-04-26 17:28 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Please do not do that. This might make sense for C or Java (although it > does not), but we have objects and we should filter based on those without > relying on a rigid system based on random levels. Please. And I forgot mention that my proposed API is not prevent object filtering. All information is here. So it can be implemented. And it also can be implemented by announcements. But here I just want to discuss API.

April 26, 2016

Re: [Pharo-dev] Logging API discussion

by Denis Kudriashov

Hi Tudor. 2016-04-26 15:36 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > > Let's think about logging API to log any object in the system. Most > natural way is just send message #log to object itself: > > > > anObject log > > > > It would be nice replacement for Object>>logCr. > > This type of usage should be discouraged in my opinion. We should instead > encourage people to use typed logging signals, like we should also > discourage people from using > self error: âa magic string hereâ. > > > > But when we log some information we usually want to log it with little > remark, importance level and (most important) timestamp. This information > is kind of standard for logging domain. But it requires much more methods > for logging API. > > So we need extra information to put together with objects: > > â¢ timestamp > > â¢ user message > > â¢ importance level (debug, info, error, etc.) > > Please do not do that. This might make sense for C or Java (although it > does not), but we have objects and we should filter based on those without > relying on a rigid system based on random levels. Please. Before I start to think about logging I was agree with you. Now I am not. This kind of information belongs to logging domain. It can be retrieved from application objects as default values but at the end it should be explicit part of log entries. We can read it in logs for every record to realize when and why object was added to log, what this record is about. 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. 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. And about random log levels. Their purpose is to mark log entries with importance level which is useful to explore logs. Imaging we have system which produce some events and we log them. (My and your approaches allow it. Only difference that in my approach this event will be part of log entry (as composition) and with your approach this event will be log entry itself). Now imagine that we need to explore some problem situation when particular events are appeared but they should not. I would try to find wrong places in code where events can be signalled and I would log them their. With my approach I will log them with specific importance level (#warning) and specific message to distinguish them from normal events. With my API it is super easy. With your approach I will need to create new classes to signal this situation. Also my approach allows me to configure in advance my application to put warnings in separate log. So I will not need to change app configs to simplify experiment. I will just deploy new code with extra logging and wait results in ready to use log. My proposals are not opposite to your. I just not put extra restrictions. Beacon can be based on top of it but not vice versa.

April 26, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50721 Home: https://github.com/pharo-project/pharo-core

April 26, 2016

[pharo-project/pharo-core] 930e6b: 50721

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 930e6b02f21cc22fb69d6689c3a5a83a0b7858b7 https://github.com/pharo-project/pharo-core/commit/930e6b02f21cc22fb69d6689… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-04-26 (Tue, 26 Apr 2016) Changed paths: M ConfigurationOfSton.package/ConfigurationOfSton.class/instance/symbolic versions/stable_.st A ConfigurationOfSton.package/ConfigurationOfSton.class/instance/versions/version19_.st R STON-Core.package/extension/Class/instance/stonOn_.st R STON-Core.package/extension/ClassDescription/instance/stonContainSubObjects.st A STON-Core.package/extension/TClass/instance/stonOn_.st A STON-Core.package/extension/TClassDescription/instance/stonContainSubObjects.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50720.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50721.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50720.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50721.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50721 18025 Trait Polymorphism test failing again... https://pharo.fogbugz.com/f/cases/18025 http://files.pharo.org/image/50/50721.zip

April 26, 2016

Re: [Pharo-dev] Logging API discussion

by Tudor Girba

Hi Dennis, > On Apr 26, 2016, at 3:26 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hello. > > I resumed discussion about SystemLogger and Beacon here http://forum.world.st/What-the-state-of-unifying-Beacon-with-SystemLogger-t…. > I plan to unify both approaches by saving traditional terminology from SystemLogger and cool features from Beacon. Thanks for your effort, but as I said before, the decision was to integrate Beacon and iterate on that. > Let's think about logging API to log any object in the system. Most natural way is just send message #log to object itself: > > anObject log > > It would be nice replacement for Object>>logCr. This type of usage should be discouraged in my opinion. We should instead encourage people to use typed logging signals, like we should also discourage people from using self error: âa magic string hereâ. > But when we log some information we usually want to log it with little remark, importance level and (most important) timestamp. This information is kind of standard for logging domain. But it requires much more methods for logging API. > So we need extra information to put together with objects: > â¢ timestamp > â¢ user message > â¢ importance level (debug, info, error, etc.) Please do not do that. This might make sense for C or Java (although it does not), but we have objects and we should filter based on those without relying on a rigid system based on random levels. Please. > â¢ whatever (process hash, process name for example) > â¢ sometimes it can be needed to put in log something different than object itself. (for example it can be just copy of object to not change state of log entry during app lifetime) > Here is possible API based on Object extensions. It has drawbacks but it is good to think about it too: No. This is the responsibility of the subtypes of Signal. > "it will put anObject in logs with default #info level" > anObject log > > "it will put anObject in logs with default #info level and given user message" > anObject logWith: 'something interesting was happened with anObjectâ > "inside block we can put any logging domain information from application and also override content by specific representation" > anObject logBy: [:logEntry | > logEntry message: 'something interesting to be saved with our object' > logEntry content: anotherObject] "here logs with interest about anObject will receive logEntry with anotherObject instead of anObjectâ This will just favor more strings. We want to move away from them. > And similar for different kind of levels: > > anObject logForDebug. > anObject logForDebugWith: 'some debug message' > anObject logForDebugBy: [:logEntry | ] > > anObject logAsError. > anObject logAsError: 'object computation was wrong' > anObject logAsErrorBy: [:logEntry | ] > And most general: > > anObject logAs: LogLevel warn > anObject logAs: LogLevel warn with: 'something interesting' > anObject logAs: LogLevel warn by: [:logEntry | ] I am definitely against this. > And in case of classic logging with strings only first expressions would be used: > > 'some info message' log. > 'some debug message' logForDebug > 'some error message' logAsError > 'some warn message' logAs: LogLevel warn > > Problem with this approach: it pollutes Object with 12 extra methods and it can be more. So maybe it is better to use current SystemLogger API based on class Log: > > Log info: anObject > Log info: anObject as: 'computation result' "as example" > Log info: anObject as: [:logEntry | > logEntry message: 'something interesting to be saved with our object > logEntry content: anotherObject] > > Log error: anObject > Log error: anObject as: 'computation was wrong'' > Log error: anObject as: [:logEntry | ] > > Comparing to original SystemLogger versions I separate user message from object content. It makes possible to log any object with extra user message. > But anyway it not feels very well IMHO. And it requires three methods for each log level. Maybe we can put this methods into LogLevel itself: > > Log info add: anObject > Log info add: anObject as: 'computation result' > Log info add: anObject as: [:logEntry | > logEntry message: 'something interesting to be saved with our object > logEntry content: anotherObject] > > Log error add: anObject > Log error add: anObject as: 'computation was wrong'' > Log error add: anObject as: [:logEntry | ] > > And we can make short version for default logging level (which can be object specific): > > Log add: anObject > Log add: anObject as: 'computation result' > Log add: anObject as: [:logEntry | ] > > That's all. I hope we can produce best suitable API for object logging. Then we can think how to adopt SystemLogger or Beacon for it. > Also think about this API in context that we can register specific loggers for specific objects and specific importance level. I think this is the wrong approach and I am opposing this direction in the most constructive way I can :). Cheers, Doru > Best regards, > Denis -- www.tudorgirba.com www.feenk.com "Don't give to get. Just give."

April 26, 2016

Logging API discussion

by Denis Kudriashov

Hello. I resumed discussion about SystemLogger and Beacon here http://forum.world.st/What-the-state-of-unifying-Beacon-with-SystemLogger-t… . I plan to unify both approaches by saving traditional terminology from SystemLogger and cool features from Beacon. Let's think about logging API to log any object in the system. Most natural way is just send message #log to object itself: anObject log It would be nice replacement for Object>>logCr. But when we log some information we usually want to log it with little remark, importance level and (most important) timestamp. This information is kind of standard for logging domain. But it requires much more methods for logging API. So we need extra information to put together with objects: 1. timestamp 2. user message 3. importance level (debug, info, error, etc.) 4. whatever (process hash, process name for example) 5. sometimes it can be needed to put in log something different than object itself. (for example it can be just copy of object to not change state of log entry during app lifetime) Here is possible API based on Object extensions. It has drawbacks but it is good to think about it too: "it will put anObject in logs with default #info level" anObject log "it will put anObject in logs with default #info level and given user message" anObject logWith: 'something interesting was happened with anObject' "inside block we can put any logging domain information from application and also override content by specific representation" anObject logBy: [:logEntry | logEntry message: 'something interesting to be saved with our object' logEntry content: anotherObject] "here logs with interest about anObject will receive logEntry with anotherObject instead of anObject" And similar for different kind of levels: anObject logForDebug. anObject logForDebugWith: 'some debug message' anObject logForDebugBy: [:logEntry | ] anObject logAsError. anObject logAsError: 'object computation was wrong' anObject logAsErrorBy: [:logEntry | ] And most general: anObject logAs: LogLevel warn anObject logAs: LogLevel warn with: 'something interesting' anObject logAs: LogLevel warn by: [:logEntry | ] And in case of classic logging with strings only first expressions would be used: 'some info message' log. 'some debug message' logForDebug 'some error message' logAsError 'some warn message' logAs: LogLevel warn Problem with this approach: it pollutes Object with 12 extra methods and it can be more. So maybe it is better to use current SystemLogger API based on class Log: Log info: anObject Log info: anObject as: 'computation result' "as example" Log info: anObject as: [:logEntry | logEntry message: 'something interesting to be saved with our object logEntry content: anotherObject] Log error: anObject Log error: anObject as: 'computation was wrong'' Log error: anObject as: [:logEntry | ] Comparing to original SystemLogger versions I separate user message from object content. It makes possible to log any object with extra user message. But anyway it not feels very well IMHO. And it requires three methods for each log level. Maybe we can put this methods into LogLevel itself: Log info add: anObject Log info add: anObject as: 'computation result' Log info add: anObject as: [:logEntry | logEntry message: 'something interesting to be saved with our object logEntry content: anotherObject] Log error add: anObject Log error add: anObject as: 'computation was wrong'' Log error add: anObject as: [:logEntry | ] And we can make short version for default logging level (which can be object specific): Log add: anObject Log add: anObject as: 'computation result' Log add: anObject as: [:logEntry | ] That's all. I hope we can produce best suitable API for object logging. Then we can think how to adopt SystemLogger or Beacon for it. Also think about this API in context that we can register specific loggers for specific objects and specific importance level. Best regards, Denis

April 26, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50720 Home: https://github.com/pharo-project/pharo-core

April 26, 2016

[pharo-project/pharo-core] 727e21: 50720

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 727e21dd92c93b62cc215db17d9aaf8120c3ec8f https://github.com/pharo-project/pharo-core/commit/727e21dd92c93b62cc215db1… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-04-26 (Tue, 26 Apr 2016) Changed paths: M ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/symbolic versions/stable_.st A ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/versions/v0%5F19%5F1_.st M FFI-Kernel.package/extension/ByteArray/instance/signedLongLongAt_.st M FFI-Kernel.package/extension/ByteArray/instance/signedLongLongAt_put_.st M FFI-Kernel.package/extension/ByteArray/instance/unsignedLongLongAt_.st M FFI-Kernel.package/extension/ByteArray/instance/unsignedLongLongAt_put_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50719.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50720.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50719.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50720.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M UnifiedFFI-Tests.package/FFICallbackTests.class/instance/tests/testCqsortWithByteArray.st A UnifiedFFI-Tests.package/FFICalloutMethodBuilderTest.class/instance/tests/testCallReturningEnumeration.st M UnifiedFFI-Tests.package/FFITypesTests.class/instance/tests/testSignedLongLong.st M UnifiedFFI.package/FFIExternalReferenceType.class/instance/emitting code/emitReturn_resultTempVar_context_.st M UnifiedFFI.package/FFIVoid.class/instance/testing/needsArityUnpacking.st Log Message: ----------- 50720 18103 Update UFFI to 0.19.1 https://pharo.fogbugz.com/f/cases/18103 http://files.pharo.org/image/50/50720.zip

April 26, 2016