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