June 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [ann] beacon - a slim announcement-based logging engine

by Tudor Girba

Hi Sven, On Mon, Jun 16, 2014 at 11:54 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 16 Jun 2014, at 10:53, Tudor Girba <tudor(a)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"

June 16, 2014

Re: [Pharo-dev] [ann] beacon - a slim announcement-based logging engine

by Sven Van Caekenberghe

On 16 Jun 2014, at 10:53, Tudor Girba <tudor(a)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.

June 16, 2014

Re: [Pharo-dev] [ann] beacon - a slim announcement-based logging engine

by kilon alios

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(a)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(a)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(a)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(a)hartl.name> >> wrote: >> >>> Stef, >>> >>> Am 16.06.2014 um 08:52 schrieb stepharo <stepharo(a)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" >> > > >

June 16, 2014

Re: [Pharo-dev] [ann] beacon - a slim announcement-based logging engine

by Norbert Hartl

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(a)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(a)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(a)hartl.name> wrote: > Stef, > > Am 16.06.2014 um 08:52 schrieb stepharo <stepharo(a)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" >

June 16, 2014

Re: [Pharo-dev] WhatsUp from: 2014-06-16 until: 2014-06-30

by Tudor Girba

> > ### Here's what I've been up to since the last WhatsUp: > - Showed GTInspector at speakerconf.com - Gave a talk about Pharo at NDC Oslo: http://vimeo.com/channels/ndc2014/97315968 - Fixed with Andrei the Rubric performance problem with syntax highlighting - Implemented an Announcement based logging engine to start a discussion in this direction: http://www.humane-assessment.com/blog/beacon > > ### What's next, until 2014-06-30 (*): > > - Try to use logging for a couple of examples and explore analyses opportunities in this space -- www.tudorgirba.com "Every thing has its own flow"

June 16, 2014

Re: [Pharo-dev] [ann] beacon - a slim announcement-based logging engine

by Tudor Girba

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(a)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(a)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(a)hartl.name> >> wrote: >> >>> Stef, >>> >>> Am 16.06.2014 um 08:52 schrieb stepharo <stepharo(a)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"

June 16, 2014

Re: [Pharo-dev] [ann] beacon - a slim announcement-based logging engine

by kilon alios

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(a)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(a)hartl.name> wrote: > >> Stef, >> >> Am 16.06.2014 um 08:52 schrieb stepharo <stepharo(a)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" >

June 16, 2014

Re: [Pharo-dev] [ann] beacon - a slim announcement-based logging engine

by Norbert Hartl

Am 16.06.2014 um 10:57 schrieb Tudor Girba <tudor(a)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

June 16, 2014

Re: [Pharo-dev] Where is the postcard with syntax?

by Yuriy Tymchuk

I guess itâs here: http://files.pharo.org/media/flyer-cheat-sheet.pdf I think that it would be interesting to put the syntax on a postcard. It can work as a proof of concept, some addition cheat-sheet for newcomers and also as some king of souvenir. Uko On 16 Jun 2014, at 10:36, stepharo <stepharo(a)free.fr> wrote: > you have the flyer of Damien (no idea where it is) but no real postcard. > > Stef > > On 16/6/14 09:35, Yuriy Tymchuk wrote: >> Hi guys, >> >> we all are talking about the syntax fitting in a postcard, but was there any real postcard with Pharo syntax prototype? This would be really interesting. >> >> Uko >> >> > >

June 16, 2014

Re: [Pharo-dev] [ann] beacon - a slim announcement-based logging engine

by Tudor Girba

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(a)hartl.name> wrote: > Stef, > > Am 16.06.2014 um 08:52 schrieb stepharo <stepharo(a)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"

June 16, 2014