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

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

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

by stepharo

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' <http://localhost:1701/random%27>. > > 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 >

June 16, 2014

Re: [Pharo-dev] Announcer>>#when:send:to:

by stepharo

On 15/6/14 18:40, Sven Van Caekenberghe wrote: > The method Announcer>>#when:send:to: seems new in Pharo 3 (it does exist in Pharo 2, but inherited from Object, doing something else), while the older equivalent Announcer>>#on:send:to: does exist in Pharo 2, but is deprecated in Pharo 3. This poses a problem for x-platform code targeting both platforms. the reason was to clearly identify announcement (by opposition to event triggering that we would like to remove but some widgets are using it) and Exception. Using on:do: was a bad idea. > > Could Announcer>>#when:send:to: not be backported/added to Pharo 2 ? yes. We should check because 20 is not really maintained > > It is not a major problem, but it is annoying. > > Sven > > >

June 16, 2014

WhatsUp from: 2014-06-16 until: 2014-06-30

by seaside＠rmod.lille.inria.fr

Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS ### What's next, until 2014-06-30 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION (*) we'll be expecting results by then ;)

June 16, 2014