On 15 Jun 2014, at 15:04, Tudor Girba <[email protected]> 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.
>
> 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.
Here is some of my feedback:
- Like I said in my document and like I tried to show in my implementation for
Zinc, I want framework agnostic pure object logging, so I don't want to
subclass from anything (I do from Announcement, but that is an implementation
detail, the technique how #emit is done), can you deal with the ZnNewLogEvents
as the are ?
- I find what you did in StackSignal very interesting, when putting Exceptions
in log objects, a natural thing to do, the same problems occur. I think we are
just exploring this area and have lots to learn (debugging in the past).
- The fact that FuelBeacon creates a new file for every signal does not strike
me as efficient enough for real world use. Also, using the #printString as
filename is weird for me.
- I am also wondering whether the fact that Announcements are synchronous (I
mean distributed to consumers on the same thread as the one that produced them)
is good or not because like this, slow backend processing for whatever reason
will kill performance of the producing code.
- In your blog post (very good as usual ;-) I am still bothered by the usage of
strings in the examples (I know you also use the stack signal, but that is more
advanced). That way, reader will still think about text. We need better
examples that show the power of object logging. I'll see if I can come up with
something.
- Small code change
StringStreamBeacon>>#handle: anAnnoucement
self stream
nextPutAll: anAnnoucement printString;
cr
would be more efficient (no intermediate string) as
StringStreamBeacon>>#handle: anAnnoucement
self stream
print: anAnnoucement;
cr
or even
StringStreamBeacon>>#handle: anAnnoucement
anAnnoucement printOn: self stream.
self stream cr
to emphasise the double dispatch.
> Cheers,
> Doru
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
