That looks very nice. I wonder whether Log warm: 'the system is still running but you should have look at it'. should be Log warn: 'the system is still running but you should have look at it'. I liked the example ... withExtra: [ :log | log extensionAt: #thisContext put: thisContext] I recently have had some good debugging success using the following... Transcript crShow: thisContext printString , ' ' , thisContext sender printString , ' ' , thisContext sender sender printString , ' ' , thisContext sender sender sender printString. ...to understand some dynamic behaviour with Announcements where putting a #halt would lock the system and a #haltOnce didn't provide a broad enough picture. It would be cool to be able to do something like... Log message: 'Here' withExtra: [ :log | log contextDepth: 4 ] cheers -ben
On 22 Feb 2014, at 15:00, btc@openinworld.com wrote:
That looks very nice. I wonder whether
yes I will fix it.
Log warm: 'the system is still running but you should have look at it'. should be Log warn: 'the system is still running but you should have look at it'.
I liked the example ... withExtra: [ :log | log extensionAt: #thisContext put: thisContext]
I recently have had some good debugging success using the following... Transcript crShow: thisContext printString , ' ' , thisContext sender printString , ' ' , thisContext sender sender printString , ' ' , thisContext sender sender sender printString. ...to understand some dynamic behaviour with Announcements where putting a #halt would lock the system and a #haltOnce didn't provide a broad enough picture.
It would be cool to be able to do something like... Log message: 'Here' withExtra: [ :log | log contextDepth: 4 ]
send some doc and update the doc :)
cheers -ben
Hey! You didn't know about SimpleLog or? http://map.squeak.org/packagebyname/simplelog Not that it matters much, we can all use more logging tools ;) but... one "mistake" I think is that you don't match the standard syslog levels as described on the URL above. SimpleLog even has a Morphic tool with it. Anyway, feel free to take whatever you like from it. regards, Göran
Göran Krampe wrote:
Hey!
You didn't know about SimpleLog or?
http://map.squeak.org/packagebyname/simplelog
Not that it matters much, we can all use more logging tools ;) but... one "mistake" I think is that you don't match the standard syslog levels as described on the URL above.
SimpleLog even has a Morphic tool with it. Anyway, feel free to take whatever you like from it.
regards, Göran
SimpleLog gets a mention in the PDF. cheers -ben
On 02/22/2014 04:30 PM, btc@openinworld.com wrote:
Göran Krampe wrote:
Hey!
You didn't know about SimpleLog or?
http://map.squeak.org/packagebyname/simplelog
Not that it matters much, we can all use more logging tools ;) but... one "mistake" I think is that you don't match the standard syslog levels as described on the URL above.
SimpleLog even has a Morphic tool with it. Anyway, feel free to take whatever you like from it.
regards, Göran
SimpleLog gets a mention in the PDF. cheers -ben
Nope, that's SimpleLogger. regards, Göran
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 :). 100 timesRepeat: [Goran repeatAfter: me what: âString sucks, string are dead objectsâ] Iâm coding in Smalltalk and not in perl! 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. So we should have look at letting string habits outside of our nice house. Stef On 22 Feb 2014, at 15:51, Göran Krampe <goran@krampe.se> wrote:
Hey!
You didn't know about SimpleLog or?
http://map.squeak.org/packagebyname/simplelog
Not that it matters much, we can all use more logging tools ;) but... one "mistake" I think is that you don't match the standard syslog levels as described on the URL above.
SimpleLog even has a Morphic tool with it. Anyway, feel free to take whatever you like from it.
regards, Göran
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 :) - 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. - Stealing log file rotation perhaps? I think its in there. - 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."
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
On 22 Feb 2014, at 18:12, Göran Krampe <goran@krampe.se> wrote:
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 :)
Iâm currently :) In fact I read all the other frameworks except his ones.
- 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. - Stealing log file rotation perhaps? I think its in there. - Stealing whatever else seems good.
Yes I was reading the code and I will package that in extensions. Now I do not know UDP and others.
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.
Indeed this is orthogonal to me. And I want to kill Transcript show
So actually, I would make sure that SimpleLogger could also easily log in JSON, let me quote from fluentd:
It is just a simple formater. Norbert is using that (if Iâm correct) to collect data from his servers with SystemLogger.
"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."
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.
Yes I will. If you want I can give you access to the repo. After I want to avoid to have dependencies to morph because the tiny core should be in the core of Pharo and all the rest pluggable. I want to use SystemLogger for Opal too.
The SLLogWatchDog is a trivial "send an email if a certain level is reached" with some bundling etc.
Yes I saw :) Nice extension.
SLLogFile has log file rotation.
Yes I saw I will rewrite it to use FS.
SLLogMorph is the simple search and filter UI.
Yes I will probably steal it too.
regards, Göran
<SimpleLog.st>
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 ;) regards, Göran
create an account on SmalltalkHub. I started with SysLogSender and it is kind of coming along :) Stef On 22 Feb 2014, at 20:27, Göran Krampe <goran@krampe.se> wrote:
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 ;)
regards, Göran
Thanks you all for the discussions and ideas. Iâm merging simpleLog and this shakes a bit the frameworks so this is excellent. Stef
On 02/22/2014 09:39 PM, Pharo4Stef wrote:
create an account on SmalltalkHub.
I am already there since a long time: http://www.smalltalkhub.com/#!/~gokr regards, Göran
Am 22.02.2014 um 20:27 schrieb Göran Krampe <goran@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
Goran do you know the JSON format I meand not format but schema to be compatible with fluentd because this could be a nice extension. Stef
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."
Am 22.02.2014 um 18:12 schrieb Göran Krampe <goran@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>
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.
Am 23.02.2014 um 13:02 schrieb Göran Krampe <goran@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.
Am 23.02.2014 um 13:02 schrieb Göran Krampe <goran@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.
On 02/23/2014 01:21 PM, Norbert Hartl wrote:
Am 23.02.2014 um 13:02 schrieb Göran Krampe <goran@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
Am 23.02.2014 um 13:47 schrieb Göran Krampe <goran@krampe.se>:
On 02/23/2014 01:21 PM, Norbert Hartl wrote:
Am 23.02.2014 um 13:02 schrieb Göran Krampe <goran@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
I updated the doc and Iâm studying SimpleLog. For the level of errors if this is easy I will follow sysLog order/default because it is not worth to be different. tx for the pointer Stef PS: now the cool remark would also be to say: "Pharo is cool not only cool frameworks are developed but they come with a nice documentationâ On 22 Feb 2014, at 15:51, Göran Krampe <goran@krampe.se> wrote:
Hey!
You didn't know about SimpleLog or?
http://map.squeak.org/packagebyname/simplelog
Not that it matters much, we can all use more logging tools ;) but... one "mistake" I think is that you don't match the standard syslog levels as described on the URL above.
SimpleLog even has a Morphic tool with it. Anyway, feel free to take whatever you like from it.
regards, Göran
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 :)) - 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@free.fr>:
-- www.tudorgirba.com "Every thing has its own flow"
On 22 Feb 2014, at 18:49, Tudor Girba <tudor@tudorgirba.com> 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 :))
in the class comment :) !! Design notes. I'm named Log and not SLLogObject or whatever because I'm the main entry point for a client point of view.
- Similarly, SystemLogger>>logs should be something like logEvents/logEvents.
I changed it to logEntries. Iâm interested in extensions to stress the design and extension points of SystemLogger :) On 22 Feb 2014, at 18:49, Tudor Girba <tudor@tudorgirba.com> wrote:
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@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@free.fr>: > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"
Am 23.02.2014 um 08:10 schrieb Tudor Girba <tudor@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@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@free.fr>:
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
Am 22.02.2014 um 18:49 schrieb Tudor Girba <tudor@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@free.fr>:
-- www.tudorgirba.com
"Every thing has its own flow"
On 22 Feb 2014, at 19:07, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
What's the advantage over Log4s?
I was thinking to reply simplicity and no string bullshit but this could be impolite :) Frankly I want an extensible object logger that can be domain specific if needed. All the rest is âextensionsâ to me. I will start to integrate simpleLog as extensions Stef
Hernán
2014-02-22 9:24 GMT-03:00 Pharo4Stef <pharo4Stef@free.fr>:
Hernan do you know how we could produce an extension that can plug into Log4J and Log4s :) BTW the last time I check I could not really load Log4s :) Stef On 22 Feb 2014, at 19:07, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
What's the advantage over Log4s?
Hernán
2014-02-22 9:24 GMT-03:00 Pharo4Stef <pharo4Stef@free.fr>:
2014-02-22 15:50 GMT-03:00 Pharo4Stef <pharo4Stef@free.fr>:
Hernan
do you know how we could produce an extension that can plug into Log4J and Log4s :)
I don't know, sorry.
BTW the last time I check I could not really load Log4s :)
That's weird because I'm using in production since weeks ago from daily fresh built 3.0 images :) I've checked now from Configuration Browser and all +200 tests passes. I cannot say for 2.0, I decided to stop maintaining packages for older versions. I will check your Logger and see how it goes. Hernán
On 22 Feb 2014, at 20:05, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
2014-02-22 15:50 GMT-03:00 Pharo4Stef <pharo4Stef@free.fr>: Hernan
do you know how we could produce an extension that can plug into Log4J and Log4s :)
I don't know, sorry.
BTW the last time I check I could not really load Log4s :)
That's weird because I'm using in production since weeks ago from daily fresh built 3.0 images :) I've checked now from Configuration Browser and all +200 tests passes.
Ok good to know. it was probably an old version. I tried it when there was no configuration just the mcz sent by donald.
I cannot say for 2.0, I decided to stop maintaining packages for older versions.
I will check your Logger and see how it goes.
Hernán
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
On 23 Feb 2014, at 12:23, Norbert Hartl <norbert@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).
Am 23.02.2014 um 13:32 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 23 Feb 2014, at 12:23, Norbert Hartl <norbert@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
On 23 Feb 2014, at 14:01, Norbert Hartl <norbert@hartl.name> wrote:
Am 23.02.2014 um 13:32 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 23 Feb 2014, at 12:23, Norbert Hartl <norbert@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?
More or less, I think I understand. Is this what you do yourself or is that how SystemLogger works ? What I meant is that this needs to be added to the documentation since it is so crucial to the 'not strings but real objects' mantra, and right now it is not explained well.
Norbert
Am 23.02.2014 um 14:07 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 23 Feb 2014, at 14:01, Norbert Hartl <norbert@hartl.name> wrote:
Am 23.02.2014 um 13:32 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 23 Feb 2014, at 12:23, Norbert Hartl <norbert@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?
More or less, I think I understand. Is this what you do yourself or is that how SystemLogger works ? What I meant is that this needs to be added to the documentation since it is so crucial to the 'not strings but real objects' mantra, and right now it is not explained well.
This is how SystemLogger works. So this is missing in the documentation? I need to read again and will add this. It wonât just be the next days because Iâm on vacation then. thanks, Norbert
On 23 Feb 2014, at 14:30, Norbert Hartl <norbert@hartl.name> wrote:
Am 23.02.2014 um 14:07 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 23 Feb 2014, at 14:01, Norbert Hartl <norbert@hartl.name> wrote:
Am 23.02.2014 um 13:32 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 23 Feb 2014, at 12:23, Norbert Hartl <norbert@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?
More or less, I think I understand. Is this what you do yourself or is that how SystemLogger works ? What I meant is that this needs to be added to the documentation since it is so crucial to the 'not strings but real objects' mantra, and right now it is not explained well.
This is how SystemLogger works. So this is missing in the documentation? I need to read again and will add this. It wonât just be the next days because Iâm on vacation then.
By explained I mean, an example, all the examples now are with plain strings...
On 23 Feb 2014, at 13:32, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 23 Feb 2014, at 12:23, Norbert Hartl <norbert@hartl.name> wrote:
One of the core ideas is âlogging objects and not stringsâ.
I am missing a clear example of that though.
sven when opal is writing to the transcript that there is an undeclared or a shadow I want to get a OPALCompilationLogEvent that I can query and ask to jump in the broken code.
I am wondering what the expect interface is, how difficult/easy it is to fit in a new object as log (event).
In SystemLogger you have self handleConvertedLogEvent: (self convert: aLogEvent) and convert: can do what ever we want to convert an object into a string. Stef
But I understand, that is not my point. You just need to add a clear example to the docs to make your point, because now you don't, everything is just old school string messages. On 23 Feb 2014, at 18:41, Pharo4Stef <pharo4Stef@free.fr> wrote:
On 23 Feb 2014, at 13:32, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 23 Feb 2014, at 12:23, Norbert Hartl <norbert@hartl.name> wrote:
One of the core ideas is âlogging objects and not stringsâ.
I am missing a clear example of that though.
sven when opal is writing to the transcript that there is an undeclared or a shadow I want to get a OPALCompilationLogEvent that I can query and ask to jump in the broken code.
I am wondering what the expect interface is, how difficult/easy it is to fit in a new object as log (event).
In SystemLogger you have
self handleConvertedLogEvent: (self convert: aLogEvent)
and convert: can do what ever we want to convert an object into a string. Stef
But I understand, that is not my point.
Yes I saw it after sending and reading the other mails. This part was made by norbert and it was not obvious to me. Iâm adding the example to the chapter right now.
You just need to add a clear example to the docs to make your point, because now you don't, everything is just old school string messages.
On 23 Feb 2014, at 18:41, Pharo4Stef <pharo4Stef@free.fr> wrote:
On 23 Feb 2014, at 13:32, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 23 Feb 2014, at 12:23, Norbert Hartl <norbert@hartl.name> wrote:
One of the core ideas is âlogging objects and not stringsâ.
I am missing a clear example of that though.
sven when opal is writing to the transcript that there is an undeclared or a shadow I want to get a OPALCompilationLogEvent that I can query and ask to jump in the broken code.
I am wondering what the expect interface is, how difficult/easy it is to fit in a new object as log (event).
In SystemLogger you have
self handleConvertedLogEvent: (self convert: aLogEvent)
and convert: can do what ever we want to convert an object into a string. Stef
Am 23.02.2014 um 18:54 schrieb Pharo4Stef <pharo4Stef@free.fr>:
But I understand, that is not my point.
Yes I saw it after sending and reading the other mails. This part was made by norbert and it was not obvious to me. Iâm adding the example to the chapter right now.
If it wasnât obvious can you give an example how the OPALCompilationLogEvent would work. Maybe we still have a dissonance here. Is OPALCompilationLogEvent a subclass of Log or ist the log message from opal put into the message of a log or even done with extension? Norbert
You just need to add a clear example to the docs to make your point, because now you don't, everything is just old school string messages.
On 23 Feb 2014, at 18:41, Pharo4Stef <pharo4Stef@free.fr> wrote:
On 23 Feb 2014, at 13:32, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 23 Feb 2014, at 12:23, Norbert Hartl <norbert@hartl.name> wrote:
One of the core ideas is âlogging objects and not stringsâ.
I am missing a clear example of that though.
sven when opal is writing to the transcript that there is an undeclared or a shadow I want to get a OPALCompilationLogEvent that I can query and ask to jump in the broken code.
I am wondering what the expect interface is, how difficult/easy it is to fit in a new object as log (event).
In SystemLogger you have
self handleConvertedLogEvent: (self convert: aLogEvent)
and convert: can do what ever we want to convert an object into a string. Stef
I would define
OPALCompilationLogEvent as a subclass of Log
and add the information it wants and special behavior identify borken method. I added a description to the chapter and I updated the class comments to reflect that. Stef On 23 Feb 2014, at 19:00, Norbert Hartl <norbert@hartl.name> wrote:
Am 23.02.2014 um 18:54 schrieb Pharo4Stef <pharo4Stef@free.fr>:
But I understand, that is not my point.
Yes I saw it after sending and reading the other mails. This part was made by norbert and it was not obvious to me. Iâm adding the example to the chapter right now.
If it wasnât obvious can you give an example how the OPALCompilationLogEvent would work. Maybe we still have a dissonance here. Is OPALCompilationLogEvent a subclass of Log or ist the log message from opal put into the message of a log or even done with extension?
Norbert
You just need to add a clear example to the docs to make your point, because now you don't, everything is just old school string messages.
On 23 Feb 2014, at 18:41, Pharo4Stef <pharo4Stef@free.fr> wrote:
On 23 Feb 2014, at 13:32, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 23 Feb 2014, at 12:23, Norbert Hartl <norbert@hartl.name> wrote:
One of the core ideas is âlogging objects and not stringsâ.
I am missing a clear example of that though.
sven when opal is writing to the transcript that there is an undeclared or a shadow I want to get a OPALCompilationLogEvent that I can query and ask to jump in the broken code.
I am wondering what the expect interface is, how difficult/easy it is to fit in a new object as log (event).
In SystemLogger you have
self handleConvertedLogEvent: (self convert: aLogEvent)
and convert: can do what ever we want to convert an object into a string. Stef
Am 23.02.2014 um 19:20 schrieb Pharo4Stef <pharo4Stef@free.fr>:
I would define
OPALCompilationLogEvent as a subclass of Log
and add the information it wants and special behavior identify borken method.
I added a description to the chapter and I updated the class comments to reflect that.
Ok. So the implementation can decide if a complex object is transport in the message instVar or if the log object is extended to carry more information. My point with asLog is just that you can easy the creation of the custom log classes. It would just work for MyLogThing class>>#logClass ^ OPALCompilationLogEvent if you want to transport your object as the message or MyLogThing>>#asLog ^ self class newLog customField: self if it is supposed somewhere different. In any of those case you can access it with (myLogThingObject asLog error; tag: #opal) emit Just FYI, Norbert
On 23 Feb 2014, at 19:00, Norbert Hartl <norbert@hartl.name> wrote:
Am 23.02.2014 um 18:54 schrieb Pharo4Stef <pharo4Stef@free.fr>:
But I understand, that is not my point.
Yes I saw it after sending and reading the other mails. This part was made by norbert and it was not obvious to me. Iâm adding the example to the chapter right now.
If it wasnât obvious can you give an example how the OPALCompilationLogEvent would work. Maybe we still have a dissonance here. Is OPALCompilationLogEvent a subclass of Log or ist the log message from opal put into the message of a log or even done with extension?
Norbert
You just need to add a clear example to the docs to make your point, because now you don't, everything is just old school string messages.
On 23 Feb 2014, at 18:41, Pharo4Stef <pharo4Stef@free.fr> wrote:
On 23 Feb 2014, at 13:32, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 23 Feb 2014, at 12:23, Norbert Hartl <norbert@hartl.name> wrote:
One of the core ideas is âlogging objects and not stringsâ.
I am missing a clear example of that though.
sven when opal is writing to the transcript that there is an undeclared or a shadow I want to get a OPALCompilationLogEvent that I can query and ask to jump in the broken code.
I am wondering what the expect interface is, how difficult/easy it is to fit in a new object as log (event).
In SystemLogger you have
self handleConvertedLogEvent: (self convert: aLogEvent)
and convert: can do what ever we want to convert an object into a string. Stef
I added this kind of description to the new version of the chapter yesterday. On 24 Feb 2014, at 11:53, Norbert Hartl <norbert@hartl.name> wrote:
Am 23.02.2014 um 19:20 schrieb Pharo4Stef <pharo4Stef@free.fr>:
I would define
OPALCompilationLogEvent as a subclass of Log
and add the information it wants and special behavior identify borken method.
I added a description to the chapter and I updated the class comments to reflect that.
Ok. So the implementation can decide if a complex object is transport in the message instVar or if the log object is extended to carry more information. My point with asLog is just that you can easy the creation of the custom log classes. It would just work for
MyLogThing class>>#logClass ^ OPALCompilationLogEvent
if you want to transport your object as the message or
MyLogThing>>#asLog ^ self class newLog customField: self
if it is supposed somewhere different.
In any of those case you can access it with
(myLogThingObject asLog error; tag: #opal) emit
Just FYI,
Norbert
On 23 Feb 2014, at 19:00, Norbert Hartl <norbert@hartl.name> wrote:
Am 23.02.2014 um 18:54 schrieb Pharo4Stef <pharo4Stef@free.fr>:
But I understand, that is not my point.
Yes I saw it after sending and reading the other mails. This part was made by norbert and it was not obvious to me. Iâm adding the example to the chapter right now.
If it wasnât obvious can you give an example how the OPALCompilationLogEvent would work. Maybe we still have a dissonance here. Is OPALCompilationLogEvent a subclass of Log or ist the log message from opal put into the message of a log or even done with extension?
Norbert
You just need to add a clear example to the docs to make your point, because now you don't, everything is just old school string messages.
On 23 Feb 2014, at 18:41, Pharo4Stef <pharo4Stef@free.fr> wrote:
On 23 Feb 2014, at 13:32, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 23 Feb 2014, at 12:23, Norbert Hartl <norbert@hartl.name> wrote:
One of the core ideas is âlogging objects and not stringsâ.
I am missing a clear example of that though.
sven when opal is writing to the transcript that there is an undeclared or a shadow I want to get a OPALCompilationLogEvent that I can query and ask to jump in the broken code.
I am wondering what the expect interface is, how difficult/easy it is to fit in a new object as log (event).
In SystemLogger you have
self handleConvertedLogEvent: (self convert: aLogEvent)
and convert: can do what ever we want to convert an object into a string. Stef
participants (7)
-
btc＠openinworld.com -
Göran Krampe -
Hernán Morales Durand -
Norbert Hartl -
Pharo4Stef -
Sven Van Caekenberghe -
Tudor Girba