Hi, I even reviewed this post :).
Of course, you can just use plain Announcements, but I still need to nuance your too strong statement. A framework is worthwhile when there is a recurrent need that it can serve. And when it comes to logging there are several such needs. For example: - reusing typical events (e.g., logging an exception) - reusing storage possibilities - having a timestamp for events I think it is worthwhile to have support out of the box for handling these. Cheers, Doru > On Apr 19, 2016, at 3:44 PM, Sven Van Caekenberghe <s...@stfx.eu> wrote: > > You might want to read > > > https://medium.com/concerning-pharo/lampsort-revisited-visualised-6652055ef858 > > that discusses object logging and what you can do with it. > > My take on this is that if you write your code to produce log events (as > Announcements), you can do whatever you want in the end. There is no real > need to depend on some framework. > >> On 19 Apr 2016, at 15:34, Tudor Girba <tu...@tudorgirba.com> wrote: >> >> Hi, >> >> Beacon is being used systematically. We even said we will integrate it in >> the image for Pharo 5 at the end of last year, but after the agitated start >> of the year, I did not push it anymore to not increase the level of >> agitation. >> >> The only class name that encountered some opposition was BoundedBeacon. >> >> We also agreed that the only things we want from SystemLogger were the >> concrete connections to external storage. This was not done, but the idea >> was that we should first integrate them and then allow people to extend it >> with bindings to external storage. >> >> I use Beacon on a regular basis, and I extended it recently with a couple of >> more Signal types that can capture exceptions and stack information. You now >> also have a better integration in the inspector to be able to start/pause an >> in-memory log stream. In the process I also added the possibility to remove >> Announcements from an AnnouncementSet and I would like to push this in Pharo >> 6.0. One thing I would work on is to add to Annoucements the possibility of >> filtering announcements based on instances not just types. This is a longer >> term plan. >> >> Another thing to do is to ensure that the log signals are not expensive to >> create. For example, the ExceptionSignal, ContextStackSignal and >> MethodStackSignal manipulate thisContext right at creation time, while this >> should happen only when we actually capture it in a BoundedBeacon to >> manipulate/store it in a specific way. This part should be refined. >> >> @Dennis: it would be great to join efforts. The two frameworks look similar, >> but there are 2 significant differences: >> 1. SystemLogger has its own log events propagation mechanism, Beacon uses >> Announcements. >> 2. SystemLogger relies on levels of filtering, Beacon uses the mechanisms >> from Announcements to pick and choose at a fine grain level which log >> signals should be logged. >> >> For reference: >> - description: http://www.humane-assessment.com/blog/beacon/ >> - repository: http://www.smalltalkhub.com/#!/~Pharo/Beacon >> >> Cheers, >> Doru >> >> >>> On Apr 19, 2016, at 2:59 PM, stepharo <steph...@free.fr> wrote: >>> >>> >>> >>> Le 18/4/16 18:28, Denis Kudriashov a écrit : >>>> Hello. >>>> >>>> Year ago Beacon and SystemLogger were announced. There was big discussion >>>> about them. And there were plans to provide single solution. What was done >>>> around that? >>> >>> Nothing. We should have done it at Cambridge and we just discussed. >>> I did not like some Beacon class names because they are totally confusing. >>>> >>>> What exactly should be merged between this libraries? Was Beacon or >>>> SystemLogger planned to be end solution? >>> We planned to merge SystemLogger into Beacon to use announcements >>>> We definitely need legacy logging tool for Pharo. And I am going to work >>>> on this direction. >>>> Personally I prefer metaphor and names from Beacon. But both libraries >>>> implement similar idea. >>> Remember that you want to have them short especially for the main one. This >>> is why in SystemLogger >>> we have Log instead of what it is LogObject if I remember correctly. >>>> >>>> Best regards, >>>> Denis >>> >>> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> “Live like you mean it." >> >> > > -- www.tudorgirba.com www.feenk.com "Problem solving efficiency grows with the abstractness level of problem understanding."
