- Pharo-dev - lists.pharo.org

[experimental/in-progress] Framework agnostic pure object logging for Zinc

by Sven Van Caekenberghe

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

June 15, 2014

Re: [Pharo-dev] Survey - needing Protocol Chooser when creating methods from the debugger

by Attila Magyar

+1 organization of the protocols is part of refactoring EstebanLM wrote > For me, having to choose a protocol before creating the method is contrary > to TDD spirit of âgo to the green as fast as you can, clean laterâ. > So yes, instead enhance it, I would directly remove the protocol chooser > in that workflowâ¦ -- View this message in context: http://forum.world.st/Survey-needing-Protocol-Chooser-when-creating-methods… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 15, 2014

Re: [Pharo-dev] Survey - needing Protocol Chooser when creating methods from the debugger

by Esteban Lorenzano

For me, having to choose a protocol before creating the method is contrary to TDD spirit of âgo to the green as fast as you can, clean laterâ. So yes, instead enhance it, I would directly remove the protocol chooser in that workflowâ¦ Esteban On 15 Jun 2014, at 10:11, Ben Coman <btc(a)openInWorld.com> wrote: > Ben Coman wrote: >> Just surveying opinion, when pressing the 'Create' (method) button in the debugger, how critical do people consider the need for the Protocol Chooser at that time? Personally I find it interrupts my flow, since often I don't feel comfortable with the conventions to choose which protocol it should go in. It makes me go searching in another browser to try to determine the convention from other existing methods. A few options to start with: >> 1. Like it just the way it is. >> 2. Dump the new method in unclassified and clean up later (plus a protocol sorting refactoring tool) >> 3. Having Protocol Chooser provide a short list of suggestions, perhaps somehow indicating the rule used and weighting. For example: "accessors (100 methods matching instance variables)" ; "testing (20 items match 'is' prefix)"". >> btw, In 2.0 the Protocol Chooser came up with a massive list (actually where this survey question stems from) but in 3.0 the Protocol Chooser comes up empty for my use cases. Can anyone suggest an example in 3.0 that populates the Protocol Chooser? > doh! I only needed to start typing to populate the Protocol Chooser. Now it still presents too many choices for my sensibilities. > cheers -ben >

June 15, 2014

Re: [Pharo-dev] Survey - needing Protocol Chooser when creating methods from the debugger

by Ben Coman

Ben Coman wrote: > Just surveying opinion, when pressing the 'Create' (method) button in > the debugger, how critical do people consider the need for the > Protocol Chooser at that time? Personally I find it interrupts my > flow, since often I don't feel comfortable with the conventions to > choose which protocol it should go in. It makes me go searching in > another browser to try to determine the convention from other existing > methods. A few options to start with: > 1. Like it just the way it is. > 2. Dump the new method in unclassified and clean up later (plus a > protocol sorting refactoring tool) > 3. Having Protocol Chooser provide a short list of suggestions, > perhaps somehow indicating the rule used and weighting. For example: > "accessors (100 methods matching instance variables)" ; "testing (20 > items match 'is' prefix)"". > btw, In 2.0 the Protocol Chooser came up with a massive list (actually > where this survey question stems from) but in 3.0 the Protocol Chooser > comes up empty for my use cases. Can anyone suggest an example in 3.0 > that populates the Protocol Chooser? doh! I only needed to start typing to populate the Protocol Chooser. Now it still presents too many choices for my sensibilities. cheers -ben

June 15, 2014

[ann] beacon - a slim announcement-based logging engine

by Tudor Girba

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"

June 15, 2014

Survey - needing Protocol Chooser when creating methods from the debugger

by Ben Coman

Just surveying opinion, when pressing the 'Create' (method) button in the debugger, how critical do people consider the need for the Protocol Chooser at that time? Personally I find it interrupts my flow, since often I don't feel comfortable with the conventions to choose which protocol it should go in. It makes me go searching in another browser to try to determine the convention from other existing methods. A few options to start with: 1. Like it just the way it is. 2. Dump the new method in unclassified and clean up later (plus a protocol sorting refactoring tool) 3. Having Protocol Chooser provide a short list of suggestions, perhaps somehow indicating the rule used and weighting. For example: "accessors (100 methods matching instance variables)" ; "testing (20 items match 'is' prefix)"". btw, In 2.0 the Protocol Chooser came up with a massive list (actually where this survey question stems from) but in 3.0 the Protocol Chooser comes up empty for my use cases. Can anyone suggest an example in 3.0 that populates the Protocol Chooser? cheers -ben

June 15, 2014

Re: [Pharo-dev] ConfigurationOfIDE, ConfigurationOfMorphicUI

by stepharo

I love that. I got sick last week now I will try to allocate time to finish the widgets repackaging and your suggestions. stef On 10/6/14 22:02, Pavel Krivanek wrote: > Hi, > > I were successful in two small battles on the remodularization front. > Firstly I'm able again to build image with ConfigurationOfIDE: > > https://ci.inria.fr/pharo/view/4.0-Bootstrap/job/Pharo-4.0-Bootstrap-Step-3… > > This job takes the shrinked image and tries to load (almost) > everything back using configuration. > > The second goal I were able to reach is to take Morphic-Core image and > load the rest of Morphic packages without tools into it (only > Workspace and Transcript are present). > > https://ci.inria.fr/pharo/view/4.0-Bootstrap/job/Pharo-4.0-Bootstrap-Step-3… > > Both images are still dirty and unfinished, e.g. the second one has > some repainting problems, but we move forward. > > Cheers, > -- Pavel > >

June 15, 2014

Re: [Pharo-dev] Brainstorming Pharo4

by stepharo

Soon soon :) but in this form MyClass>>myMethod [ ^ 1 + 3 ] ;) > > MyClass>>myMethod "in accessors" > ^ 1 + 3 > > The current System Browser my also be switched to that method at the > same time, or a new System Browser opened if this is entered from > Workspace. I see some advantages for this for tutorials, where > methods are presented using the ">>" convention, and readers might > copy-paste the whole code. > > cheers -ben > >

June 15, 2014

Re: [Pharo-dev] Brainstorming Pharo4

by Ben Coman

Can some low-priority consideration be given to the compiler accepting methods of the form: MyClass>>myMethod "in accessors" ^ 1 + 3 The current System Browser my also be switched to that method at the same time, or a new System Browser opened if this is entered from Workspace. I see some advantages for this for tutorials, where methods are presented using the ">>" convention, and readers might copy-paste the whole code. cheers -ben

June 15, 2014

Re: [Pharo-dev] Brainstorming Pharo4

by Hilaire Fernandes

Agree Le 15/06/2014 09:34, stepharo a Ã©crit : > > between you and me, I always raised this point but I was not heard > (personally I'm not fan of composed keys) > So hilaire to help we should use keybinding (check the draft chapter in > pharo for the entreprise) > and kill all the hardcoded bindings. > > We could make a list and fix them one by one. -- Dr. Geo http://drgeo.eu iStoa - https://launchpad.net/istoa

June 15, 2014