[ann] beacon - a slim announcement-based logging engine
Hi, I like very much the new energy people are putting into creating the SystemLogger engine for Pharo. I think this is a specifically important area for which we have to have a solution out of the box. At the same time, I also think that Pharo provides an infrastructure that makes room for ideas that are otherwise hard to reach in other languages or environments. Stef asked for collaborations around this project, so here is my literally small contribution: a rather different logging engine. It is called Beacon, it is based entirely on Announcements, it has ~200 lines of code, it has no tags or levels, and in my opinion it is fully functional. You can see a detailed description here including some informal comparisons with SystemLogger: http://www.humane-assessment.com/blog/beacon Please let me know what you think. I would be happy to join forces to reach a mature solution that is both versatile and that can show how Pharo is different. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"
That looks very cool! I agree that logging objects is the way to go, and now that we have all this infrastructure we should be able to better make use of object-based logs. I was just thinking about this issue a couple of weeks ago, and beacon might just be the solution for me. I hope to find the time in a few weeks to start using it! On Jun 15, 2014, at 9:04 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I like very much the new energy people are putting into creating the SystemLogger engine for Pharo. I think this is a specifically important area for which we have to have a solution out of the box. At the same time, I also think that Pharo provides an infrastructure that makes room for ideas that are otherwise hard to reach in other languages or environments.
Stef asked for collaborations around this project, so here is my literally small contribution: a rather different logging engine. It is called Beacon, it is based entirely on Announcements, it has ~200 lines of code, it has no tags or levels, and in my opinion it is fully functional.
You can see a detailed description here including some informal comparisons with SystemLogger: http://www.humane-assessment.com/blog/beacon
Please let me know what you think. I would be happy to join forces to reach a mature solution that is both versatile and that can show how Pharo is different.
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Well written, as always :-) Alexandre On Jun 15, 2014, at 9:04 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I like very much the new energy people are putting into creating the SystemLogger engine for Pharo. I think this is a specifically important area for which we have to have a solution out of the box. At the same time, I also think that Pharo provides an infrastructure that makes room for ideas that are otherwise hard to reach in other languages or environments.
Stef asked for collaborations around this project, so here is my literally small contribution: a rather different logging engine. It is called Beacon, it is based entirely on Announcements, it has ~200 lines of code, it has no tags or levels, and in my opinion it is fully functional.
You can see a detailed description here including some informal comparisons with SystemLogger: http://www.humane-assessment.com/blog/beacon
Please let me know what you think. I would be happy to join forces to reach a mature solution that is both versatile and that can show how Pharo is different.
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi,
I like very much the new energy people are putting into creating the SystemLogger engine for Pharo. I think this is a specifically important area for which we have to have a solution out of the box. At the same time, I also think that Pharo provides an infrastructure that makes room for ideas that are otherwise hard to reach in other languages or environments.
Why Java does not have announcements?
Stef asked for collaborations around this project, so here is my literally small contribution: a rather different logging engine. I do not see how this contribute to SystemLogger. So at least please do not say it, respect the amount of time I spent design it and working with Norbert.
It is called Beacon, it is based entirely on Announcements, it has ~200 lines of code, it has no tags or levels, and in my opinion it is fully functional.
You can see a detailed description here including some informal comparisons with SystemLogger: http://www.humane-assessment.com/blog/beacon
Please let me know what you think. I would be happy to join forces to reach a mature solution that is both versatile and that can show how Pharo is different. So should we see it as a competitor to SystemLogger? (you will say of course not) but I do not understand.
Cheers, Doru
-- www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
Hi, On Mon, Jun 16, 2014 at 8:52 AM, stepharo <stepharo@free.fr> wrote:
Hi,
I like very much the new energy people are putting into creating the SystemLogger engine for Pharo. I think this is a specifically important area for which we have to have a solution out of the box. At the same time, I also think that Pharo provides an infrastructure that makes room for ideas that are otherwise hard to reach in other languages or environments.
Why Java does not have announcements?
I meant to say that Java-like systems rely to a large extent on string logging. Stef asked for collaborations around this project, so here is my literally
small contribution: a rather different logging engine.
I do not see how this contribute to SystemLogger. So at least please do not say it, respect the amount of time I spent design it and working with Norbert.
But, I do respect the time you spent on it. Just that I do not think the current implementation is the best solution. Both when SystemLogger came up and when you asked for reviewing, I said that SystemLogger should be improved and gave feedback. Then I was told to be pragmatic and not just talk. Now, I contributed a concrete solution that works out of the box to back up my arguments and I documented all decisions in the process. It is called Beacon, it is based entirely on Announcements, it has ~200
lines of code, it has no tags or levels, and in my opinion it is fully functional.
You can see a detailed description here including some informal comparisons with SystemLogger: http://www.humane-assessment.com/blog/beacon
Please let me know what you think. I would be happy to join forces to reach a mature solution that is both versatile and that can show how Pharo is different.
So should we see it as a competitor to SystemLogger? (you will say of course not) but I do not understand.
You can see it the way you want. You can see it as a competitor to the implementation of SystemLogger, but that will not lead anywhere. I prefer to see it as a possible candidate model for the future logging engine that will be integrated in the image. We are now in the position to compare and consolidate. Cheers, Doru
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
On 16 Jun 2014, at 08:52, stepharo <stepharo@free.fr> wrote:
Hi,
I like very much the new energy people are putting into creating the SystemLogger engine for Pharo. I think this is a specifically important area for which we have to have a solution out of the box. At the same time, I also think that Pharo provides an infrastructure that makes room for ideas that are otherwise hard to reach in other languages or environments.
Why Java does not have announcements?
Stef asked for collaborations around this project, so here is my literally small contribution: a rather different logging engine. I do not see how this contribute to SystemLogger. So at least please do not say it, respect the amount of time I spent design it and working with Norbert.
It is called Beacon, it is based entirely on Announcements, it has ~200 lines of code, it has no tags or levels, and in my opinion it is fully functional.
You can see a detailed description here including some informal comparisons with SystemLogger: http://www.humane-assessment.com/blog/beacon
Please let me know what you think. I would be happy to join forces to reach a mature solution that is both versatile and that can show how Pharo is different. So should we see it as a competitor to SystemLogger? (you will say of course not) but I do not understand.
Just my 2 cents: Stef, I wouldnât fight agains other projects, itâs natural that for popular environments there are different approaches to implement important tools. E.g. in Ruby there are few different web frameworks and I think logging too. And I wouldnât be angry on Doru because he mentioned SystemLogger, for me the idea is that Pharo is missing decent logger, and there is a work being done on the big project, in a while Doru proposes small yet functional tool with itâs own philosophy. Iâm trying to ignore my personal preferences here, and move attention to the point that we should make our environment modular and let people decide what they want to use. Uko
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
I could not agree more with you I am very much against "One ring to Rule them All" , it did not work for Sauron in Lord of the Rings for the exact reason why its a bad idea to put all your eggs in one basket. Once it fails in a fundamental level you are screwed forever. People reinvent the wheel because this is how evolution works, this is how our world works. You use what you have and you add something new to the recipe and hope for the best. It also gives the ability to users to choose the right tool for them. A developer of a Library can never be more smart than its users because he does not know their needs and cannot anticipate their personal desires and workflows. I have never had the pleasure of using a Logging system, but using Announcements sounds like a way I would go with it if it was me. Certainly will give it a try thanks Tudor. On Mon, Jun 16, 2014 at 10:13 AM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 16 Jun 2014, at 08:52, stepharo <stepharo@free.fr> wrote:
Hi,
I like very much the new energy people are putting into creating the SystemLogger engine for Pharo. I think this is a specifically important area for which we have to have a solution out of the box. At the same time, I also think that Pharo provides an infrastructure that makes room for ideas that are otherwise hard to reach in other languages or environments.
Why Java does not have announcements?
Stef asked for collaborations around this project, so here is my literally small contribution: a rather different logging engine.
I do not see how this contribute to SystemLogger. So at least please do not say it, respect the amount of time I spent design it and working with Norbert.
It is called Beacon, it is based entirely on Announcements, it has ~200 lines of code, it has no tags or levels, and in my opinion it is fully functional.
You can see a detailed description here including some informal comparisons with SystemLogger: http://www.humane-assessment.com/blog/beacon
Please let me know what you think. I would be happy to join forces to reach a mature solution that is both versatile and that can show how Pharo is different.
So should we see it as a competitor to SystemLogger? (you will say of course not) but I do not understand.
Just my 2 cents: Stef, I wouldnât fight agains other projects, itâs natural that for popular environments there are different approaches to implement important tools. E.g. in Ruby there are few different web frameworks and I think logging too. And I wouldnât be angry on Doru because he mentioned SystemLogger, for me the idea is that Pharo is missing decent logger, and there is a work being done on the big project, in a while Doru proposes small yet functional tool with itâs own philosophy.
Iâm trying to ignore my personal preferences here, and move attention to the point that we should make our environment modular and let people decide what they want to use.
Uko
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
@Kilon, you said almost the same thing, how comes that you do not agree with me? Uko On 16 Jun 2014, at 10:03, kilon alios <kilon.alios@gmail.com> wrote:
I could not agree more with you
I am very much against "One ring to Rule them All" , it did not work for Sauron in Lord of the Rings for the exact reason why its a bad idea to put all your eggs in one basket. Once it fails in a fundamental level you are screwed forever.
People reinvent the wheel because this is how evolution works, this is how our world works. You use what you have and you add something new to the recipe and hope for the best.
It also gives the ability to users to choose the right tool for them. A developer of a Library can never be more smart than its users because he does not know their needs and cannot anticipate their personal desires and workflows.
I have never had the pleasure of using a Logging system, but using Announcements sounds like a way I would go with it if it was me. Certainly will give it a try thanks Tudor.
On Mon, Jun 16, 2014 at 10:13 AM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 16 Jun 2014, at 08:52, stepharo <stepharo@free.fr> wrote:
Hi,
I like very much the new energy people are putting into creating the SystemLogger engine for Pharo. I think this is a specifically important area for which we have to have a solution out of the box. At the same time, I also think that Pharo provides an infrastructure that makes room for ideas that are otherwise hard to reach in other languages or environments.
Why Java does not have announcements?
Stef asked for collaborations around this project, so here is my literally small contribution: a rather different logging engine. I do not see how this contribute to SystemLogger. So at least please do not say it, respect the amount of time I spent design it and working with Norbert.
It is called Beacon, it is based entirely on Announcements, it has ~200 lines of code, it has no tags or levels, and in my opinion it is fully functional.
You can see a detailed description here including some informal comparisons with SystemLogger: http://www.humane-assessment.com/blog/beacon
Please let me know what you think. I would be happy to join forces to reach a mature solution that is both versatile and that can show how Pharo is different. So should we see it as a competitor to SystemLogger? (you will say of course not) but I do not understand.
Just my 2 cents: Stef, I wouldnât fight agains other projects, itâs natural that for popular environments there are different approaches to implement important tools. E.g. in Ruby there are few different web frameworks and I think logging too. And I wouldnât be angry on Doru because he mentioned SystemLogger, for me the idea is that Pharo is missing decent logger, and there is a work being done on the big project, in a while Doru proposes small yet functional tool with itâs own philosophy.
Iâm trying to ignore my personal preferences here, and move attention to the point that we should make our environment modular and let people decide what they want to use.
Uko
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
"I could not agree more with you" means that I agree with you 100%. Its one of the strange things of language to use a negative to imply a positive statement :D On Mon, Jun 16, 2014 at 11:09 AM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
@Kilon, you said almost the same thing, how comes that you do not agree with me?
Uko
On 16 Jun 2014, at 10:03, kilon alios <kilon.alios@gmail.com> wrote:
I could not agree more with you
I am very much against "One ring to Rule them All" , it did not work for Sauron in Lord of the Rings for the exact reason why its a bad idea to put all your eggs in one basket. Once it fails in a fundamental level you are screwed forever.
People reinvent the wheel because this is how evolution works, this is how our world works. You use what you have and you add something new to the recipe and hope for the best.
It also gives the ability to users to choose the right tool for them. A developer of a Library can never be more smart than its users because he does not know their needs and cannot anticipate their personal desires and workflows.
I have never had the pleasure of using a Logging system, but using Announcements sounds like a way I would go with it if it was me. Certainly will give it a try thanks Tudor.
On Mon, Jun 16, 2014 at 10:13 AM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 16 Jun 2014, at 08:52, stepharo <stepharo@free.fr> wrote:
Hi,
I like very much the new energy people are putting into creating the SystemLogger engine for Pharo. I think this is a specifically important area for which we have to have a solution out of the box. At the same time, I also think that Pharo provides an infrastructure that makes room for ideas that are otherwise hard to reach in other languages or environments.
Why Java does not have announcements?
Stef asked for collaborations around this project, so here is my literally small contribution: a rather different logging engine.
I do not see how this contribute to SystemLogger. So at least please do not say it, respect the amount of time I spent design it and working with Norbert.
It is called Beacon, it is based entirely on Announcements, it has ~200 lines of code, it has no tags or levels, and in my opinion it is fully functional.
You can see a detailed description here including some informal comparisons with SystemLogger: http://www.humane-assessment.com/blog/beacon
Please let me know what you think. I would be happy to join forces to reach a mature solution that is both versatile and that can show how Pharo is different.
So should we see it as a competitor to SystemLogger? (you will say of course not) but I do not understand.
Just my 2 cents: Stef, I wouldnât fight agains other projects, itâs natural that for popular environments there are different approaches to implement important tools. E.g. in Ruby there are few different web frameworks and I think logging too. And I wouldnât be angry on Doru because he mentioned SystemLogger, for me the idea is that Pharo is missing decent logger, and there is a work being done on the big project, in a while Doru proposes small yet functional tool with itâs own philosophy.
Iâm trying to ignore my personal preferences here, and move attention to the point that we should make our environment modular and let people decide what they want to use.
Uko
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
Ah, no, itâs my fault. Sometimes I implicitly skip the middle of a sentence :). Uko On 16 Jun 2014, at 10:34, kilon alios <kilon.alios@gmail.com> wrote:
"I could not agree more with you" means that I agree with you 100%. Its one of the strange things of language to use a negative to imply a positive statement :D
On Mon, Jun 16, 2014 at 11:09 AM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote: @Kilon, you said almost the same thing, how comes that you do not agree with me?
Uko
On 16 Jun 2014, at 10:03, kilon alios <kilon.alios@gmail.com> wrote:
I could not agree more with you
I am very much against "One ring to Rule them All" , it did not work for Sauron in Lord of the Rings for the exact reason why its a bad idea to put all your eggs in one basket. Once it fails in a fundamental level you are screwed forever.
People reinvent the wheel because this is how evolution works, this is how our world works. You use what you have and you add something new to the recipe and hope for the best.
It also gives the ability to users to choose the right tool for them. A developer of a Library can never be more smart than its users because he does not know their needs and cannot anticipate their personal desires and workflows.
I have never had the pleasure of using a Logging system, but using Announcements sounds like a way I would go with it if it was me. Certainly will give it a try thanks Tudor.
On Mon, Jun 16, 2014 at 10:13 AM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 16 Jun 2014, at 08:52, stepharo <stepharo@free.fr> wrote:
Hi,
I like very much the new energy people are putting into creating the SystemLogger engine for Pharo. I think this is a specifically important area for which we have to have a solution out of the box. At the same time, I also think that Pharo provides an infrastructure that makes room for ideas that are otherwise hard to reach in other languages or environments.
Why Java does not have announcements?
Stef asked for collaborations around this project, so here is my literally small contribution: a rather different logging engine. I do not see how this contribute to SystemLogger. So at least please do not say it, respect the amount of time I spent design it and working with Norbert.
It is called Beacon, it is based entirely on Announcements, it has ~200 lines of code, it has no tags or levels, and in my opinion it is fully functional.
You can see a detailed description here including some informal comparisons with SystemLogger: http://www.humane-assessment.com/blog/beacon
Please let me know what you think. I would be happy to join forces to reach a mature solution that is both versatile and that can show how Pharo is different. So should we see it as a competitor to SystemLogger? (you will say of course not) but I do not understand.
Just my 2 cents: Stef, I wouldnât fight agains other projects, itâs natural that for popular environments there are different approaches to implement important tools. E.g. in Ruby there are few different web frameworks and I think logging too. And I wouldnât be angry on Doru because he mentioned SystemLogger, for me the idea is that Pharo is missing decent logger, and there is a work being done on the big project, in a while Doru proposes small yet functional tool with itâs own philosophy.
Iâm trying to ignore my personal preferences here, and move attention to the point that we should make our environment modular and let people decide what they want to use.
Uko
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
Stef, Am 16.06.2014 um 08:52 schrieb stepharo <stepharo@free.fr>:
Hi,
I like very much the new energy people are putting into creating the SystemLogger engine for Pharo. I think this is a specifically important area for which we have to have a solution out of the box. At the same time, I also think that Pharo provides an infrastructure that makes room for ideas that are otherwise hard to reach in other languages or environments.
Why Java does not have announcements?
Stef asked for collaborations around this project, so here is my literally small contribution: a rather different logging engine. I do not see how this contribute to SystemLogger. So at least please do not say it, respect the amount of time I spent design it and working with Norbert.
I had troubles myself seeing how this can contribute to SystemLogger. It looks a lot like âI donât like yours here is mineâ. But if you remember that is the same reason why you've started SystemLogger. So you should be fair here. Now it is the time to see how we can benefit from each other. I see it as an advantage to have code to compare because a lot of discussions are usual too theoretical to make something of it. I did not have the time to look at svens and dorus code. But I will because I had the impression, too, in the beginning that the dispatching of events would be better done with announcements. We all should review the other implementations and all of us should be open minded for any reason why the own implementation is probably _not_ the way to go. I wish we can find an agreement about an optimal implementation we like to promote. Norbert
It is called Beacon, it is based entirely on Announcements, it has ~200 lines of code, it has no tags or levels, and in my opinion it is fully functional.
You can see a detailed description here including some informal comparisons with SystemLogger: http://www.humane-assessment.com/blog/beacon
Please let me know what you think. I would be happy to join forces to reach a mature solution that is both versatile and that can show how Pharo is different. So should we see it as a competitor to SystemLogger? (you will say of course not) but I do not understand.
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
Hi Norbert, Indeed it was not meant as "I donât like yours here is mine". It was meant as "I donât like yours because ... so here is my concrete proposal of how to address ..." And the goal is not SystemLogger vs Beacon either. The goal should be the one cool engine that will ship with Pharo 4. Doru On Mon, Jun 16, 2014 at 9:24 AM, Norbert Hartl <norbert@hartl.name> wrote:
Stef,
Am 16.06.2014 um 08:52 schrieb stepharo <stepharo@free.fr>:
Hi,
I like very much the new energy people are putting into creating the SystemLogger engine for Pharo. I think this is a specifically important area for which we have to have a solution out of the box. At the same time, I also think that Pharo provides an infrastructure that makes room for ideas that are otherwise hard to reach in other languages or environments.
Why Java does not have announcements?
Stef asked for collaborations around this project, so here is my literally small contribution: a rather different logging engine.
I do not see how this contribute to SystemLogger. So at least please do not say it, respect the amount of time I spent design it and working with Norbert.
I had troubles myself seeing how this can contribute to SystemLogger. It looks a lot like âI donât like yours here is mineâ. But if you remember that is the same reason why you've started SystemLogger. So you should be fair here. Now it is the time to see how we can benefit from each other. I see it as an advantage to have code to compare because a lot of discussions are usual too theoretical to make something of it. I did not have the time to look at svens and dorus code. But I will because I had the impression, too, in the beginning that the dispatching of events would be better done with announcements. We all should review the other implementations and all of us should be open minded for any reason why the own implementation is probably _not_ the way to go. I wish we can find an agreement about an optimal implementation we like to promote.
Norbert
It is called Beacon, it is based entirely on Announcements, it has ~200 lines of code, it has no tags or levels, and in my opinion it is fully functional.
You can see a detailed description here including some informal comparisons with SystemLogger: http://www.humane-assessment.com/blog/beacon
Please let me know what you think. I would be happy to join forces to reach a mature solution that is both versatile and that can show how Pharo is different.
So should we see it as a competitor to SystemLogger? (you will say of course not) but I do not understand.
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
Am 16.06.2014 um 10:57 schrieb Tudor Girba <tudor@tudorgirba.com>:
And the goal is not SystemLogger vs Beacon either. The goal should be the one cool engine that will ship with Pharo 4.
Good. That is my only goal. Norbert
I think it would be better if pharo was stripped down to core basics , excluding any logging system as well, and instead the user would be able to add the functionality he / she wants with configuration browser. I think this also will show a very clean look highly modular. On Mon, Jun 16, 2014 at 11:57 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi Norbert,
Indeed it was not meant as "I donât like yours here is mine". It was meant as "I donât like yours because ... so here is my concrete proposal of how to address ..."
And the goal is not SystemLogger vs Beacon either. The goal should be the one cool engine that will ship with Pharo 4.
Doru
On Mon, Jun 16, 2014 at 9:24 AM, Norbert Hartl <norbert@hartl.name> wrote:
Stef,
Am 16.06.2014 um 08:52 schrieb stepharo <stepharo@free.fr>:
Hi,
I like very much the new energy people are putting into creating the SystemLogger engine for Pharo. I think this is a specifically important area for which we have to have a solution out of the box. At the same time, I also think that Pharo provides an infrastructure that makes room for ideas that are otherwise hard to reach in other languages or environments.
Why Java does not have announcements?
Stef asked for collaborations around this project, so here is my literally small contribution: a rather different logging engine.
I do not see how this contribute to SystemLogger. So at least please do not say it, respect the amount of time I spent design it and working with Norbert.
I had troubles myself seeing how this can contribute to SystemLogger. It looks a lot like âI donât like yours here is mineâ. But if you remember that is the same reason why you've started SystemLogger. So you should be fair here. Now it is the time to see how we can benefit from each other. I see it as an advantage to have code to compare because a lot of discussions are usual too theoretical to make something of it. I did not have the time to look at svens and dorus code. But I will because I had the impression, too, in the beginning that the dispatching of events would be better done with announcements. We all should review the other implementations and all of us should be open minded for any reason why the own implementation is probably _not_ the way to go. I wish we can find an agreement about an optimal implementation we like to promote.
Norbert
It is called Beacon, it is based entirely on Announcements, it has ~200 lines of code, it has no tags or levels, and in my opinion it is fully functional.
You can see a detailed description here including some informal comparisons with SystemLogger: http://www.humane-assessment.com/blog/beacon
Please let me know what you think. I would be happy to join forces to reach a mature solution that is both versatile and that can show how Pharo is different.
So should we see it as a competitor to SystemLogger? (you will say of course not) but I do not understand.
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
That should happen with the modularization work started by Pavel and Stef. That is a primary goal for Pharo 4. But, at the end, we will still prebuild a handy to use image. That image should have a logging engine. Doru On Mon, Jun 16, 2014 at 11:05 AM, kilon alios <kilon.alios@gmail.com> wrote:
I think it would be better if pharo was stripped down to core basics , excluding any logging system as well, and instead the user would be able to add the functionality he / she wants with configuration browser. I think this also will show a very clean look highly modular.
On Mon, Jun 16, 2014 at 11:57 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi Norbert,
Indeed it was not meant as "I donât like yours here is mine". It was meant as "I donât like yours because ... so here is my concrete proposal of how to address ..."
And the goal is not SystemLogger vs Beacon either. The goal should be the one cool engine that will ship with Pharo 4.
Doru
On Mon, Jun 16, 2014 at 9:24 AM, Norbert Hartl <norbert@hartl.name> wrote:
Stef,
Am 16.06.2014 um 08:52 schrieb stepharo <stepharo@free.fr>:
Hi,
I like very much the new energy people are putting into creating the SystemLogger engine for Pharo. I think this is a specifically important area for which we have to have a solution out of the box. At the same time, I also think that Pharo provides an infrastructure that makes room for ideas that are otherwise hard to reach in other languages or environments.
Why Java does not have announcements?
Stef asked for collaborations around this project, so here is my literally small contribution: a rather different logging engine.
I do not see how this contribute to SystemLogger. So at least please do not say it, respect the amount of time I spent design it and working with Norbert.
I had troubles myself seeing how this can contribute to SystemLogger. It looks a lot like âI donât like yours here is mineâ. But if you remember that is the same reason why you've started SystemLogger. So you should be fair here. Now it is the time to see how we can benefit from each other. I see it as an advantage to have code to compare because a lot of discussions are usual too theoretical to make something of it. I did not have the time to look at svens and dorus code. But I will because I had the impression, too, in the beginning that the dispatching of events would be better done with announcements. We all should review the other implementations and all of us should be open minded for any reason why the own implementation is probably _not_ the way to go. I wish we can find an agreement about an optimal implementation we like to promote.
Norbert
It is called Beacon, it is based entirely on Announcements, it has ~200 lines of code, it has no tags or levels, and in my opinion it is fully functional.
You can see a detailed description here including some informal comparisons with SystemLogger: http://www.humane-assessment.com/blog/beacon
Please let me know what you think. I would be happy to join forces to reach a mature solution that is both versatile and that can show how Pharo is different.
So should we see it as a competitor to SystemLogger? (you will say of course not) but I do not understand.
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
Sure, that is the way we should follow from pharo 4.0 on. Making a modular system means making dependencies visible. If you compose your system there will be parts that are closer to the core and parts which are farther away like applications. The logging is just one thing we need to be closer to the core because it should be usable by core functionality too. May this be a description that suits you more. Norbert Am 16.06.2014 um 11:05 schrieb kilon alios <kilon.alios@gmail.com>:
I think it would be better if pharo was stripped down to core basics , excluding any logging system as well, and instead the user would be able to add the functionality he / she wants with configuration browser. I think this also will show a very clean look highly modular.
On Mon, Jun 16, 2014 at 11:57 AM, Tudor Girba <tudor@tudorgirba.com> wrote: Hi Norbert,
Indeed it was not meant as "I donât like yours here is mine". It was meant as "I donât like yours because ... so here is my concrete proposal of how to address ..."
And the goal is not SystemLogger vs Beacon either. The goal should be the one cool engine that will ship with Pharo 4.
Doru
On Mon, Jun 16, 2014 at 9:24 AM, Norbert Hartl <norbert@hartl.name> wrote: Stef,
Am 16.06.2014 um 08:52 schrieb stepharo <stepharo@free.fr>:
Hi,
I like very much the new energy people are putting into creating the SystemLogger engine for Pharo. I think this is a specifically important area for which we have to have a solution out of the box. At the same time, I also think that Pharo provides an infrastructure that makes room for ideas that are otherwise hard to reach in other languages or environments.
Why Java does not have announcements?
Stef asked for collaborations around this project, so here is my literally small contribution: a rather different logging engine. I do not see how this contribute to SystemLogger. So at least please do not say it, respect the amount of time I spent design it and working with Norbert.
I had troubles myself seeing how this can contribute to SystemLogger. It looks a lot like âI donât like yours here is mineâ. But if you remember that is the same reason why you've started SystemLogger. So you should be fair here. Now it is the time to see how we can benefit from each other. I see it as an advantage to have code to compare because a lot of discussions are usual too theoretical to make something of it. I did not have the time to look at svens and dorus code. But I will because I had the impression, too, in the beginning that the dispatching of events would be better done with announcements. We all should review the other implementations and all of us should be open minded for any reason why the own implementation is probably _not_ the way to go. I wish we can find an agreement about an optimal implementation we like to promote.
Norbert
It is called Beacon, it is based entirely on Announcements, it has ~200 lines of code, it has no tags or levels, and in my opinion it is fully functional.
You can see a detailed description here including some informal comparisons with SystemLogger: http://www.humane-assessment.com/blog/beacon
Please let me know what you think. I would be happy to join forces to reach a mature solution that is both versatile and that can show how Pharo is different. So should we see it as a competitor to SystemLogger? (you will say of course not) but I do not understand.
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
sure you guys know pharo better than me , I am sure you will make the right choice :) On Mon, Jun 16, 2014 at 12:13 PM, Norbert Hartl <norbert@hartl.name> wrote:
Sure, that is the way we should follow from pharo 4.0 on. Making a modular system means making dependencies visible. If you compose your system there will be parts that are closer to the core and parts which are farther away like applications. The logging is just one thing we need to be closer to the core because it should be usable by core functionality too. May this be a description that suits you more.
Norbert
Am 16.06.2014 um 11:05 schrieb kilon alios <kilon.alios@gmail.com>:
I think it would be better if pharo was stripped down to core basics , excluding any logging system as well, and instead the user would be able to add the functionality he / she wants with configuration browser. I think this also will show a very clean look highly modular.
On Mon, Jun 16, 2014 at 11:57 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi Norbert,
Indeed it was not meant as "I donât like yours here is mine". It was meant as "I donât like yours because ... so here is my concrete proposal of how to address ..."
And the goal is not SystemLogger vs Beacon either. The goal should be the one cool engine that will ship with Pharo 4.
Doru
On Mon, Jun 16, 2014 at 9:24 AM, Norbert Hartl <norbert@hartl.name> wrote:
Stef,
Am 16.06.2014 um 08:52 schrieb stepharo <stepharo@free.fr>:
Hi,
I like very much the new energy people are putting into creating the SystemLogger engine for Pharo. I think this is a specifically important area for which we have to have a solution out of the box. At the same time, I also think that Pharo provides an infrastructure that makes room for ideas that are otherwise hard to reach in other languages or environments.
Why Java does not have announcements?
Stef asked for collaborations around this project, so here is my literally small contribution: a rather different logging engine.
I do not see how this contribute to SystemLogger. So at least please do not say it, respect the amount of time I spent design it and working with Norbert.
I had troubles myself seeing how this can contribute to SystemLogger. It looks a lot like âI donât like yours here is mineâ. But if you remember that is the same reason why you've started SystemLogger. So you should be fair here. Now it is the time to see how we can benefit from each other. I see it as an advantage to have code to compare because a lot of discussions are usual too theoretical to make something of it. I did not have the time to look at svens and dorus code. But I will because I had the impression, too, in the beginning that the dispatching of events would be better done with announcements. We all should review the other implementations and all of us should be open minded for any reason why the own implementation is probably _not_ the way to go. I wish we can find an agreement about an optimal implementation we like to promote.
Norbert
It is called Beacon, it is based entirely on Announcements, it has ~200 lines of code, it has no tags or levels, and in my opinion it is fully functional.
You can see a detailed description here including some informal comparisons with SystemLogger: http://www.humane-assessment.com/blog/beacon
Please let me know what you think. I would be happy to join forces to reach a mature solution that is both versatile and that can show how Pharo is different.
So should we see it as a competitor to SystemLogger? (you will say of course not) but I do not understand.
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
I had troubles myself seeing how this can contribute to SystemLogger. It looks a lot like âI donât like yours here is mineâ. But if you remember that is the same reason why you've started SystemLogger.
no I started SystemLogger because - it should log objects - it should be the basis for the future logger.
So you should be fair here. Now it is the time to see how we can benefit from each other. I see it as an advantage to have code to compare because a lot of discussions are usual too theoretical to make something of it. I did not have the time to look at svens and dorus code. But I will because I had the impression, too, in the beginning that the dispatching of events would be better done with announcements.
If you have an hammer everything looks like a nail. To me it just kills my fun.
We all should review the other implementations and all of us should be open minded for any reason why the own implementation is probably _not_ the way to go. I wish we can find an agreement about an optimal implementation we like to promote.
Norbert
It is called Beacon, it is based entirely on Announcements, it has ~200 lines of code, it has no tags or levels, and in my opinion it is fully functional.
You can see a detailed description here including some informal comparisons with SystemLogger: http://www.humane-assessment.com/blog/beacon
Please let me know what you think. I would be happy to join forces to reach a mature solution that is both versatile and that can show how Pharo is different. So should we see it as a competitor to SystemLogger? (you will say of course not) but I do not understand.
Cheers, Doru
-- www.tudorgirba.com <http://www.tudorgirba.com/>
"Every thing has its own flow"
Stef, Am 17.06.2014 um 16:32 schrieb stepharo <stepharo@free.fr>:
I had troubles myself seeing how this can contribute to SystemLogger. It looks a lot like âI donât like yours here is mineâ. But if you remember that is the same reason why you've started SystemLogger.
no I started SystemLogger because - it should log objects - it should be the basis for the future logger.
ok. Here the combination of sentences is unfortunate. Iâm sorry! I know the reasons why you did it. And you know that I chimed in (not developing my own solution) because I liked the idea from the beginning (because I have thought about that often before). I just wanted to say that there are good reasons to start your own implementation (like you did). Thatâs all!
So you should be fair here. Now it is the time to see how we can benefit from each other. I see it as an advantage to have code to compare because a lot of discussions are usual too theoretical to make something of it. I did not have the time to look at svens and dorus code. But I will because I had the impression, too, in the beginning that the dispatching of events would be better done with announcements.
If you have an hammer everything looks like a nail.
Right. In my case it is just a gut feeling I had all the time. Might be it turns out that announcements are not the way to go. But I want to look at it.
To me it just kills my fun.
I understand and Iâm sorry if the mail I wrote supported that. To be really honest I had the same feeling when I talked with Sven and Doru. It appeared to me that everyone wanted to place his own solution. But I like to take the chance that we get something out where a lot of people are happy with. On the other hand SystemLogger is not final. It can be improved and we should improve it. Now it is the time to collaborate and tame our egos. Otherwise there will be three half baked approaches, one in zinc, one in GT* tools and one in pharo. That would be the worst outcome. In order to prevent that I wanted to talk. Just that! My plan is to: - look at beacon to see what Doru has in his mind. Maybe I get a good idea from it - then I would look at Svenâs new code to see the difference to Doruâs and to actual see if that works for more than a framework - finally I would like to look at the SystemLogger design again and improve it where it might be improved. - then there will be a new version of SystemLogger. Thatâs it. I personally donât plan to skip SystemLogger in favour of beacon or zinc log. beacon is a proof of concept but there are AFAIK no formatters, outputs and so on. So it is not even a replacement for SystemLogger. Zinc log is a log system for a single framework called zinc. Iâm not sure it can be useful for anything else and I donât think Sven is hitting in that direction. I want a basic logging support that either has a central access for pain free logging or it has multiple announcers (maybe one per module/framework) that can be composed to a log source that can be attached to some kind of dispatcher. I donât know. That I need to figure out Norbert
We all should review the other implementations and all of us should be open minded for any reason why the own implementation is probably _not_ the way to go. I wish we can find an agreement about an optimal implementation we like to promote.
Norbert
It is called Beacon, it is based entirely on Announcements, it has ~200 lines of code, it has no tags or levels, and in my opinion it is fully functional.
You can see a detailed description here including some informal comparisons with SystemLogger: http://www.humane-assessment.com/blog/beacon
Please let me know what you think. I would be happy to join forces to reach a mature solution that is both versatile and that can show how Pharo is different. So should we see it as a competitor to SystemLogger? (you will say of course not) but I do not understand.
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
Hi Norbert, On Tue, Jun 17, 2014 at 5:09 PM, Norbert Hartl <norbert@hartl.name> wrote: ...
If you have an hammer everything looks like a nail.
Right. In my case it is just a gut feeling I had all the time. Might be it turns out that announcements are not the way to go. But I want to look at it.
Thanks.
To me it just kills my fun.
I understand and Iâm sorry if the mail I wrote supported that. To be really honest I had the same feeling when I talked with Sven and Doru. It appeared to me that everyone wanted to place his own solution. But I like to take the chance that we get something out where a lot of people are happy with. On the other hand SystemLogger is not final. It can be improved and we should improve it. Now it is the time to collaborate and tame our egos. Otherwise there will be three half baked approaches, one in zinc, one in GT* tools and one in pharo. That would be the worst outcome. In order to prevent that I wanted to talk. Just that!
Indeed. I think nobody wants that. But the very fact that we are talking about ideas and that we all want to compare with one another will exactly lead us to one strong solution :) My plan is to:
- look at beacon to see what Doru has in his mind. Maybe I get a good idea from it - then I would look at Svenâs new code to see the difference to Doruâs and to actual see if that works for more than a framework
I think they are the same conceptually. On the one hand, Sven's code is more specific to Zinc, but the cool thing about it is that we get real use cases for typed events.
- finally I would like to look at the SystemLogger design again and improve it where it might be improved. - then there will be a new version of SystemLogger. Thatâs it.
I personally donât plan to skip SystemLogger in favour of beacon or zinc log.
Nor should you :). We should build one whatever the name is. Let's just take the time to compare the concepts and we see afterwards. beacon is a proof of concept but there are AFAIK no formatters, outputs and
so on.
I think Beacon is actually a full implementation of a logger. There are as many outputs as there are in the core of SystemLogger. As for formatters, I explicitly did not want them in the core because I think we should not favor text too prominently. I think that scrolling through a text file is not a good direction and that we should instead build logging analysis tools as I tried to explain in the blog post. The video of Sven shows how this can look in practice. So it is not even a replacement for SystemLogger. Zinc log is a log system
for a single framework called zinc. Iâm not sure it can be useful for anything else and I donât think Sven is hitting in that direction. I want a basic logging support that either has a central access for pain free logging or it has multiple announcers (maybe one per module/framework) that can be composed to a log source that can be attached to some kind of dispatcher. I donât know. That I need to figure out
Great. Doru
Norbert
We all should review the other implementations and all of us should be open minded for any reason why the own implementation is probably _not_ the way to go. I wish we can find an agreement about an optimal implementation we like to promote.
Norbert
It is called Beacon, it is based entirely on Announcements, it has ~200 lines of code, it has no tags or levels, and in my opinion it is fully functional.
You can see a detailed description here including some informal comparisons with SystemLogger: http://www.humane-assessment.com/blog/beacon
Please let me know what you think. I would be happy to join forces to reach a mature solution that is both versatile and that can show how Pharo is different.
So should we see it as a competitor to SystemLogger? (you will say of course not) but I do not understand.
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
Norbert, We are indeed all just discussing and exploring. On the other hand, Zinc has to work for real, on many Pharo versions and even on Gemstone. On 17 Jun 2014, at 17:09, Norbert Hartl <norbert@hartl.name> wrote:
Otherwise there will be three half baked approaches, one in zinc, one in GT* tools and one in pharo.
What is currently in Zinc-HTTP-Logging is just a rich hierarchy of ZnLogEvent subclasses. ZnLogEvent does indeed hold onto its own announcer, pretty standard stuff I would say. Then there are two convenience methods #logToTranscript, which basically says self announcer when: self send: #crShow: to: Transcript and #open which opens an AnnouncementSpy. That's it. This gives me 99% of what I had before and a nice GUI tool as an extra. There is a #logLevel property in ZnClient and ZnServer to control the volume of log events being generated because I am concerned about performance. We'll see about that.
That would be the worst outcome. In order to prevent that I wanted to talk. Just that!
My plan is to:
- look at beacon to see what Doru has in his mind. Maybe I get a good idea from it - then I would look at Svenâs new code to see the difference to Doruâs and to actual see if that works for more than a framework - finally I would like to look at the SystemLogger design again and improve it where it might be improved. - then there will be a new version of SystemLogger. Thatâs it.
I'll send a separate mail on how easy it is, I think, to integrate ZnLogEvent with both SystemLogger and Beacon.
I personally donât plan to skip SystemLogger in favour of beacon or zinc log. beacon is a proof of concept but there are AFAIK no formatters, outputs and so on. So it is not even a replacement for SystemLogger. Zinc log is a log system for a single framework called zinc. Iâm not sure it can be useful for anything else and I donât think Sven is hitting in that direction.
No, of course not. Again, Zinc-HTTP-Logging is just a rich hierarchy of ZnLogEvent subclasses.
I want a basic logging support that either has a central access for pain free logging or it has multiple announcers (maybe one per module/framework) that can be composed to a log source that can be attached to some kind of dispatcher. I donât know. That I need to figure out
Norbert
Sven
On 15 Jun 2014, at 15:04, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I like very much the new energy people are putting into creating the SystemLogger engine for Pharo. I think this is a specifically important area for which we have to have a solution out of the box. At the same time, I also think that Pharo provides an infrastructure that makes room for ideas that are otherwise hard to reach in other languages or environments.
Stef asked for collaborations around this project, so here is my literally small contribution: a rather different logging engine. It is called Beacon, it is based entirely on Announcements, it has ~200 lines of code, it has no tags or levels, and in my opinion it is fully functional.
You can see a detailed description here including some informal comparisons with SystemLogger: http://www.humane-assessment.com/blog/beacon
Please let me know what you think. I would be happy to join forces to reach a mature solution that is both versatile and that can show how Pharo is different.
Here is some of my feedback: - Like I said in my document and like I tried to show in my implementation for Zinc, I want framework agnostic pure object logging, so I don't want to subclass from anything (I do from Announcement, but that is an implementation detail, the technique how #emit is done), can you deal with the ZnNewLogEvents as the are ? - I find what you did in StackSignal very interesting, when putting Exceptions in log objects, a natural thing to do, the same problems occur. I think we are just exploring this area and have lots to learn (debugging in the past). - The fact that FuelBeacon creates a new file for every signal does not strike me as efficient enough for real world use. Also, using the #printString as filename is weird for me. - I am also wondering whether the fact that Announcements are synchronous (I mean distributed to consumers on the same thread as the one that produced them) is good or not because like this, slow backend processing for whatever reason will kill performance of the producing code. - In your blog post (very good as usual ;-) I am still bothered by the usage of strings in the examples (I know you also use the stack signal, but that is more advanced). That way, reader will still think about text. We need better examples that show the power of object logging. I'll see if I can come up with something. - Small code change StringStreamBeacon>>#handle: anAnnoucement self stream nextPutAll: anAnnoucement printString; cr would be more efficient (no intermediate string) as StringStreamBeacon>>#handle: anAnnoucement self stream print: anAnnoucement; cr or even StringStreamBeacon>>#handle: anAnnoucement anAnnoucement printOn: self stream. self stream cr to emphasise the double dispatch.
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
Hi, Thanks. Comments inline. On Mon, Jun 16, 2014 at 9:36 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 15 Jun 2014, at 15:04, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I like very much the new energy people are putting into creating the SystemLogger engine for Pharo. I think this is a specifically important area for which we have to have a solution out of the box. At the same time, I also think that Pharo provides an infrastructure that makes room for ideas that are otherwise hard to reach in other languages or environments.
Stef asked for collaborations around this project, so here is my literally small contribution: a rather different logging engine. It is called Beacon, it is based entirely on Announcements, it has ~200 lines of code, it has no tags or levels, and in my opinion it is fully functional.
You can see a detailed description here including some informal comparisons with SystemLogger: http://www.humane-assessment.com/blog/beacon
Please let me know what you think. I would be happy to join forces to reach a mature solution that is both versatile and that can show how Pharo is different.
Here is some of my feedback:
- Like I said in my document and like I tried to show in my implementation for Zinc, I want framework agnostic pure object logging, so I don't want to subclass from anything (I do from Announcement, but that is an implementation detail, the technique how #emit is done), can you deal with the ZnNewLogEvents as the are ?
As you can see at the end of the post, you can just use your own Announcements. There is no real magic there. So, it should be no technical problem to accommodate the logging of ZincEvents as they are. However, one thing that we should also think about is the actual analyses that we might want to do. For example, the inspector extension for RecordingBeacon uses: - timestamp, and - printOneLineContentsOn: And these requirements will grow even more as we are building more specialized tools. So, to this end, it is useful to have some common ground. Now, as far as I know, the only reason why you do not want to subclass BeaconSignal is because you want to use ZnTimestamp. I see no reason to have two Timestamps in the image anyway, so I have no problem pushing just one. Or do you have another reason?
- I find what you did in StackSignal very interesting, when putting Exceptions in log objects, a natural thing to do, the same problems occur. I think we are just exploring this area and have lots to learn (debugging in the past).
Exactly. Andrei and I already used the StackSignal for a real debugging session and I will blog about it shortly.
- The fact that FuelBeacon creates a new file for every signal does not strike me as efficient enough for real world use. Also, using the #printString as filename is weird for me.
As mentioned in the post, this is more of an example than something to be used for real. We definitely need real solutions in this space.
- I am also wondering whether the fact that Announcements are synchronous (I mean distributed to consumers on the same thread as the one that produced them) is good or not because like this, slow backend processing for whatever reason will kill performance of the producing code.
Good point. I thought about it as well, but I do not have a good solution. It would definitely be interesting to have solutions both for sync and async.
- In your blog post (very good as usual ;-) I am still bothered by the usage of strings in the examples (I know you also use the stack signal, but that is more advanced). That way, reader will still think about text. We need better examples that show the power of object logging. I'll see if I can come up with something.
I know! It pained me as well, but I did not have good examples at hand (except for the stack one that I needed first hand) and I thought that it is better to bring it up for discussion than wait until it is too late.
- Small code change
StringStreamBeacon>>#handle: anAnnoucement self stream nextPutAll: anAnnoucement printString; cr
would be more efficient (no intermediate string) as
StringStreamBeacon>>#handle: anAnnoucement self stream print: anAnnoucement; cr
or even
StringStreamBeacon>>#handle: anAnnoucement anAnnoucement printOn: self stream. self stream cr
to emphasise the double dispatch.
Good catch! Committed. Cheers, Doru
Cheers,
Doru
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
On 16 Jun 2014, at 10:53, Tudor Girba <tudor@tudorgirba.com> wrote:
- Like I said in my document and like I tried to show in my implementation for Zinc, I want framework agnostic pure object logging, so I don't want to subclass from anything (I do from Announcement, but that is an implementation detail, the technique how #emit is done), can you deal with the ZnNewLogEvents as the are ?
As you can see at the end of the post, you can just use your own Announcements. There is no real magic there. So, it should be no technical problem to accommodate the logging of ZincEvents as they are.
Yes, but even being an Announcement subclass is debatable.
However, one thing that we should also think about is the actual analyses that we might want to do. For example, the inspector extension for RecordingBeacon uses: - timestamp, and - printOneLineContentsOn:
And these requirements will grow even more as we are building more specialized tools. So, to this end, it is useful to have some common ground.
Yes, I mentioned this already several times: traits listing expected protocol would be good. Maximum polymorphism, latest possible binding, no dependencies, composable.
Now, as far as I know, the only reason why you do not want to subclass BeaconSignal is because you want to use ZnTimestamp. I see no reason to have two Timestamps in the image anyway, so I have no problem pushing just one. Or do you have another reason?
I first of all want no dependency so that different logging backends can be plugged in or used. I think that this takes away any lock-in anxiety from people like myself, which will increase adoption. BTW, it is ZTimestamp not ZnTimestamp, it has absolutely nothing to do with Zinc. ZTimestamp is second precision, UTC only, and takes half the size. It comes with cool formatting/parsing, full timezone and basic SNTP support. No, I want all users to be able to make there own choices for whatever reason (efficiency, precision, portability). The timestamp is the only concrete element we can discuss now, but there could be others.
Hi Sven, On Mon, Jun 16, 2014 at 11:54 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 16 Jun 2014, at 10:53, Tudor Girba <tudor@tudorgirba.com> wrote:
- Like I said in my document and like I tried to show in my implementation for Zinc, I want framework agnostic pure object logging, so I don't want to subclass from anything (I do from Announcement, but that is an implementation detail, the technique how #emit is done), can you deal with the ZnNewLogEvents as the are ?
As you can see at the end of the post, you can just use your own Announcements. There is no real magic there. So, it should be no technical problem to accommodate the logging of ZincEvents as they are.
Yes, but even being an Announcement subclass is debatable.
If you can announce any object, then you do not need Announcements either :).
However, one thing that we should also think about is the actual analyses that we might want to do. For example, the inspector extension for RecordingBeacon uses: - timestamp, and - printOneLineContentsOn:
And these requirements will grow even more as we are building more specialized tools. So, to this end, it is useful to have some common ground.
Yes, I mentioned this already several times: traits listing expected protocol would be good. Maximum polymorphism, latest possible binding, no dependencies, composable.
Agreed. All I said is that to find the useful protocols we need to build the tools and not stop the discussion at the recording part of the logging.
Now, as far as I know, the only reason why you do not want to subclass BeaconSignal is because you want to use ZnTimestamp. I see no reason to have two Timestamps in the image anyway, so I have no problem pushing just one. Or do you have another reason?
I first of all want no dependency so that different logging backends can be plugged in or used. I think that this takes away any lock-in anxiety from people like myself, which will increase adoption.
I do not understand that. First, we talk about a handful of lines of code. Second, actually your newest implementation already ships a more specialized version of Beacon, so from this perspective Zinc already binds me at least to Announcements. Is this a bad thing? I think it is rather pragmatic.
BTW, it is ZTimestamp not ZnTimestamp, it has absolutely nothing to do with Zinc. ZTimestamp is second precision, UTC only, and takes half the size. It comes with cool formatting/parsing, full timezone and basic SNTP support.
Yeah, my bad.
No, I want all users to be able to make there own choices for whatever reason (efficiency, precision, portability). The timestamp is the only concrete element we can discuss now, but there could be others.
Freedom is good in the sense that people should be able to customize anything they want. At the same time if you want to provide services on top, you need to find a useful commonality. In our concrete case, I see no reason to keep DateAndTime when the other one is better. Doru -- www.tudorgirba.com "Every thing has its own flow"
Am 16.06.2014 um 12:10 schrieb Tudor Girba <tudor@tudorgirba.com>:
Hi Sven,
On Mon, Jun 16, 2014 at 11:54 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 16 Jun 2014, at 10:53, Tudor Girba <tudor@tudorgirba.com> wrote:
- Like I said in my document and like I tried to show in my implementation for Zinc, I want framework agnostic pure object logging, so I don't want to subclass from anything (I do from Announcement, but that is an implementation detail, the technique how #emit is done), can you deal with the ZnNewLogEvents as the are ?
As you can see at the end of the post, you can just use your own Announcements. There is no real magic there. So, it should be no technical problem to accommodate the logging of ZincEvents as they are.
Yes, but even being an Announcement subclass is debatable.
If you can announce any object, then you do not need Announcements either :).
I agree with Sven here. I think the need to subclass another framework class is a big restriction. Announcements (as any object) have static part (class, instVars) and a dynamic part. In this case it is the infrastructure and the way they get delivered, the way I can register for receiving them etc. To me the latter is the important part. I never understood why not every object can be an announcement. This way it just leads to doubled class hierarchies just for the sake to announce anything. Norbert
However, one thing that we should also think about is the actual analyses that we might want to do. For example, the inspector extension for RecordingBeacon uses: - timestamp, and - printOneLineContentsOn:
And these requirements will grow even more as we are building more specialized tools. So, to this end, it is useful to have some common ground.
Yes, I mentioned this already several times: traits listing expected protocol would be good. Maximum polymorphism, latest possible binding, no dependencies, composable.
Agreed. All I said is that to find the useful protocols we need to build the tools and not stop the discussion at the recording part of the logging.
Now, as far as I know, the only reason why you do not want to subclass BeaconSignal is because you want to use ZnTimestamp. I see no reason to have two Timestamps in the image anyway, so I have no problem pushing just one. Or do you have another reason?
I first of all want no dependency so that different logging backends can be plugged in or used. I think that this takes away any lock-in anxiety from people like myself, which will increase adoption.
I do not understand that. First, we talk about a handful of lines of code. Second, actually your newest implementation already ships a more specialized version of Beacon, so from this perspective Zinc already binds me at least to Announcements. Is this a bad thing? I think it is rather pragmatic.
BTW, it is ZTimestamp not ZnTimestamp, it has absolutely nothing to do with Zinc. ZTimestamp is second precision, UTC only, and takes half the size. It comes with cool formatting/parsing, full timezone and basic SNTP support.
Yeah, my bad.
No, I want all users to be able to make there own choices for whatever reason (efficiency, precision, portability). The timestamp is the only concrete element we can discuss now, but there could be others.
Freedom is good in the sense that people should be able to customize anything they want. At the same time if you want to provide services on top, you need to find a useful commonality. In our concrete case, I see no reason to keep DateAndTime when the other one is better.
Doru
-- www.tudorgirba.com
"Every thing has its own flow"
I do not understand why log should be announcement. Especially since log: is in Object in SystemLogger. But I will not talk about this topic anymore because I felt insulted. Doru like do not expect that people wants to join effort on any project, if the only reaction you have when ask for help is to create a competitive solution. Stef
On 17 Jun 2014, at 16:37, stepharo <stepharo@free.fr> wrote:
I do not understand why log should be announcement. Especially since log: is in Object in SystemLogger.
Being an Announcement is not a requirement to me, it is a delivery mechanism. Log event objects should be anything, as defined by the log producer.
Am 17.06.2014 um 17:02 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 17 Jun 2014, at 16:37, stepharo <stepharo@free.fr> wrote:
I do not understand why log should be announcement. Especially since log: is in Object in SystemLogger.
Being an Announcement is not a requirement to me, it is a delivery mechanism.
Log event objects should be anything, as defined by the log producer.
Of course and that we have. Maybe it is just that you understood BasicLog>>#message to be text based instead of being an arbitrary object (and so it can be a string but it neednât). As well as we chose the approach to decorate an arbitrary object instead of having to subclass from one. I would be really glad if that turns out to be a misunderstanding. Norbert
Stef, Am 17.06.2014 um 16:37 schrieb stepharo <stepharo@free.fr>:
I do not understand why log should be announcement. Especially since log: is in Object in SystemLogger. But I will not talk about this topic anymore because I felt insulted. Doru like do not expect that people wants to join effort on any project, if the only reaction you have when ask for help is to create a competitive solution.
I wrote in my last mail that if you were insulted by me, too, I like to apologize because my mail was not written the way I think. Norbert
Hi Stef, On Tue, Jun 17, 2014 at 4:37 PM, stepharo <stepharo@free.fr> wrote:
I do not understand why log should be announcement. Especially since log: is in Object in SystemLogger.
The Log class is a carrier for the message object. The Log class is essentially doing the same thing Announcement does. So, we can just use an Announcement for that. This is not a limitation. I think it is quite beautiful.
But I will not talk about this topic anymore because I felt insulted. Doru like do not expect that people wants to join effort on any project, if the only reaction you have when ask for help is to create a competitive solution.
I am sorry you felt insulted. It was not the intention at all. Perhaps my wording stroke the wrong chord, but as I tried to explain, the goal is not to pursue Beacon, but to explore the design space. I even documented, provided examples, wrote several comments in the code. I based the implementation on the argument of Sven that using Announcement is conceptually a great opportunity for a logging system and I showed that if we do that it can indeed lead to less than half the size of the other solution. In the process, I also showed how by using Announcements we need neither level nor tags. I think it is precisely in the spirit of Pharo to be able to do more with less concepts. I cannot help it to have a different opinion, but I really do not see what else I could do to make my point and contribute. I could have just committed in the SystemLogger, but that would have meant re-writing it which would have turned out to be the same thing. Would it have been better to not do anything? I hope not. So, please, let's start over and let's keep in mind that email is a poor carrier of intention. I am here precisely because I want to work together with you guys. Cheers, Doru
Stef
-- www.tudorgirba.com "Every thing has its own flow"
participants (8)
-
Alexandre Bergel -
Johan Fabry -
kilon alios -
Norbert Hartl -
stepharo -
Sven Van Caekenberghe -
Tudor Girba -
Yuriy Tymchuk