[Pharo-dev] What the state of unifying Beacon with SystemLogger?

stepharo stepharo at free.fr
Wed Apr 20 02:21:51 EDT 2016

I imagine well because I could also do it with SystemLogger.
Now one of the question I faced when I started to think about the UI was:
what is the protocol so that each event can expose domain specific 
actions to the tools browsing them
(I did not think at that time about yet another pragma)

For the compiler I would like to have

         MessageBrowser openWith: self method selection: self variables

So what we see is that we could have a pragma to describe action
but I did not like it.

So now I would have

CompilerLog packaged in Compiler
JumpToMethod packaged in CompilerExtrasTools (a package that import 
Tools and extend Compiler)

For database

And in the compilerLogItem I do not want to have reference to UI tools

PS: I do not like the name Event because I would prefer to have a 
separate domain name from UI.
>> On 19 Apr 2016, at 20:44, stepharo <stepharo at free.fr 
>> <mailto:stepharo at free.fr>> wrote:
>> What I would like and that I wanted to SystemLogger was that the 
>> compiler for example could issue a log event and that we could build
>> a tools to browse only such events and that I can click on it and 
>> jump right in the method with shadowing variables for example.
>> So to get something more than dead strings.
> Of course.
> This is already the case with Zinc.
> Just inspect
>   ZnLogEvent announcer.
> And then do
>   ZnClient new get: 'http://pharo.org' <http://pharo.org%27>.
> Now go to the first inspector and click on the Announcements tab. You 
> see events generated by the Zinc client, real objects with all kinds 
> of interesting objects inside of them:
>> Le 19/4/16 15:55, Tudor Girba a écrit :
>>> 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 <sven at stfx.eu 
>>>> <mailto:sven at 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 <tudor at tudorgirba.com 
>>>>> <mailto:tudor at 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 
>>>>> <http://www.smalltalkhub.com/#%21/%7EPharo/Beacon>
>>>>> Cheers,
>>>>> Doru
>>>>>> On Apr 19, 2016, at 2:59 PM, stepharo <stepharo at free.fr 
>>>>>> <mailto:stepharo at 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 <http://www.tudorgirba.com>
>>>>> www.feenk.com
>>>>> “Live like you mean it."
>>> --
>>> www.tudorgirba.com <http://www.tudorgirba.com>
>>> www.feenk.com
>>> "Problem solving efficiency grows with the abstractness level of 
>>> problem understanding."

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20160420/fe7d9023/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 128164 bytes
Desc: not available
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20160420/fe7d9023/attachment.png>

More information about the Pharo-dev mailing list