- Pharo-dev - lists.pharo.org

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

by kilon alios

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(a)me.com> wrote: > > On 16 Jun 2014, at 08:52, stepharo <stepharo(a)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" > > > >

June 16, 2014

Vm on Mac OS 7.5 no cairo

by Stephan Eggermont

I find I'm unable to use a recent vm with Roassal/cairo on Mac OS 7.5. The dec 12 version works, but all new ones say: failed to get a symbol address: cairo_image_surface_create Stephan

June 16, 2014

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

by Sven Van Caekenberghe

On 15 Jun 2014, at 15:04, Tudor Girba <tudor(a)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"

June 16, 2014

Where is the postcard with syntax?

by Yuriy Tymchuk

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 Norbert Hartl

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" >

June 16, 2014

Re: [Pharo-dev] [experimental/in-progress] Framework agnostic pure object logging for Zinc

by Sven Van Caekenberghe

On 16 Jun 2014, at 08:25, stepharo <stepharo(a)free.fr> wrote: > Hi sven > > Objects are the way to go. Yes ! > Will this compatible be with SystemLogger? I mean could not you use SystemLogger? I hope that SystemLogger can work with a subsystem that generates a stream of log objects, without requiring them to be subclasses of something. If so, then it will be compatible (just connect the announcer to where you want to sent the objects to). If not, then I don't understand how SystemLogger can be a pure object log. I said this before (and I miss this in the SystemLogger documentation, and even in the Beacon description): show real object based logging from the beginning, not degenerate string logging. In the case of SystemLogger, the class BasicLog already contains a message, why ? The API is also still mainly expressed with strings. (BTW, there should not be a messageText in exception, for example, being an instance of ZeroDivide or KeyNotFound with a key says it all). And like in the basic BeaconSignal, you predefine a timeStamp, why ? Is it really needed, or not ? In my other projects I don't use DateAndTime but ZTimestamp, things like that should not be forced on user. A timestamp even with high precision is not necessarily unique, that is why I added a secondary id. > Because I do not see them why I spend my time to build infrastructure. Sure, I need/want a nice backend with lots of functionality (like what Norbert was experimenting with). Also, for casual usage, some classes to inherit from are useful. Maybe a system level API as well. Second, we will probably need conventions, maybe expressed as traits of useful attributes for log objects so that we can write general analysis tools. > Stef > >> Hi, >> >> Since years, Zinc has been using its own Announcements-based logging mechanism for client and server logging. The payload of the Announcements used was still essentially text based though. >> >> In some discussions months ago with Norbert Hartl in the context of his work on SystemLogger, the concept of pure object logging as an alternative to text based logging became an interesting alternative for me. In an internal project that I did earlier this year I tried out this concept for myself and was quite happy with the result. >> >> Doru Girba had indicated several times to me that he was also interested in thinking about logging, so when he started talking about Beacon, I decided to write down my ideas a bit in a quick draft: >> >> https://github.com/svenvc/docs/blob/master/draft/logging-with-objects.md >> >> And to make this even clearer, I had to change Zinc logging to work along these principles. The current #bleedingEdge experimental/in-progress version of Zinc now contains a first working version of 'framework agnostic pure object logging'. The conversion is not yet finished - there is still much to learn here - but it already looks quite nice I think. >> >> Monitoring logging output can be done by opening an Announcement Spy. >> >> ZnNewLogEvent open. >> >> Next you run some code (start a server, do one request, stop the server). >> >> (ZnServer defaultOn: 1701) >> route: #server1; >> start. >> >> ZnClient new >> clientId: #client1; >> beOneShot; >> get: 'http://localhost:1701/random'. >> >> ZnServer stopDefault. >> >> Which give the following output (using the standard string representation). >> >> <Mail Attachment.png> >> >> However, each line is a rich object containing tons of information. Here is the highlighted line in the Explorer. >> >> <Mail Attachment.png> >> >> As you can see, all information from during the client and the server's execution is preserved, ready to be used for logging and/or debugging, right now or later on. >> >> Nowhere in the main ZnClient or ZnServer logging code is there simple string or text logging, everything being logged by announcing a log event object. >> >> I hope that this plays well with both SystemLogger, Beacon and maybe other logging frameworks out there. >> >> When I bring this approach more and more in production use, it will most probably evolve further. In the meantime, have a look: I would love feedback. >> >> Sven >> >

June 16, 2014

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

by Yuriy Tymchuk

On 16 Jun 2014, at 08:52, stepharo <stepharo(a)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" >

June 16, 2014

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

by Tudor Girba

Hi, On Mon, Jun 16, 2014 at 8:52 AM, stepharo <stepharo(a)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"

June 16, 2014

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

by stepharo

> 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"

June 16, 2014

Re: [Pharo-dev] [experimental/in-progress] Framework agnostic pure object logging for Zinc

by Tudor Girba

Hi Stef, The way I see it is that the Zinc Log Announcements will work quite well with Beacon, but less smooth with SystemLogger because you will need another layer of indirection. This is because SystemLogger is not relying directly on Announcements. I think the model of Beacon is simpler. Please note that I am not looking to start a war :). I am sure there are things I did not consider in Beacon, and this is why it would be great to work together to build a common engine that we can integrate in the image. Cheers, Doru On Mon, Jun 16, 2014 at 8:25 AM, stepharo <stepharo(a)free.fr> wrote: > Hi sven > > Objects are the way to go. > Will this compatible be with SystemLogger? I mean could not you use > SystemLogger? Because I do not see them why I spend my time > to build infrastructure. > > Stef > > > Hi, > > Since years, Zinc has been using its own Announcements-based logging > mechanism for client and server logging. The payload of the Announcements > used was still essentially text based though. > > In some discussions months ago with Norbert Hartl in the context of his > work on SystemLogger, the concept of pure object logging as an alternative > to text based logging became an interesting alternative for me. In an > internal project that I did earlier this year I tried out this concept for > myself and was quite happy with the result. > > Doru Girba had indicated several times to me that he was also interested > in thinking about logging, so when he started talking about Beacon, I > decided to write down my ideas a bit in a quick draft: > > > https://github.com/svenvc/docs/blob/master/draft/logging-with-objects.md > > And to make this even clearer, I had to change Zinc logging to work > along these principles. The current #bleedingEdge experimental/in-progress > version of Zinc now contains a first working version of 'framework agnostic > pure object logging'. The conversion is not yet finished - there is still > much to learn here - but it already looks quite nice I think. > > Monitoring logging output can be done by opening an Announcement Spy. > > ZnNewLogEvent open. > > Next you run some code (start a server, do one request, stop the server). > > (ZnServer defaultOn: 1701) > route: #server1; > start. > > ZnClient new > clientId: #client1; > beOneShot; > get: 'http://localhost:1701/random'. > > ZnServer stopDefault. > > Which give the following output (using the standard string > representation). > > > However, each line is a rich object containing tons of information. Here > is the highlighted line in the Explorer. > > > As you can see, all information from during the client and the server's > execution is preserved, ready to be used for logging and/or debugging, > right now or later on. > > Nowhere in the main ZnClient or ZnServer logging code is there simple > string or text logging, everything being logged by announcing a log event > object. > > I hope that this plays well with both SystemLogger, Beacon and maybe > other logging frameworks out there. > > When I bring this approach more and more in production use, it will most > probably evolve further. In the meantime, have a look: I would love > feedback. > > Sven > > > -- www.tudorgirba.com "Every thing has its own flow"

June 16, 2014