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

Tudor Girba tudor at tudorgirba.com
Thu Apr 21 09:46:58 EDT 2016

> On Apr 20, 2016, at 9:05 PM, Ben Coman <btc at openInWorld.com> wrote:
> Sorry for not having a better reviewed understanding of both
> frameworks, but I have some thoughts from perspective of one user...
> On Thu, Apr 21, 2016 at 12:05 AM, Denis Kudriashov <dionisiydk at gmail.com> wrote:
>> Hi.
>> Thank's for answers.
>> 2016-04-20 10:53 GMT+02:00 Norbert Hartl <norbert at hartl.name>:
>>> Agreed. As I said above. If you take to point of view from legacy logging
>>> tool Beacon is not a big help. But the ideas in it are good and should be
>>> integrated somewhere. If you are talking about legacy tooling it might ok to
>>> use the terms logging as well, no? I personally like the work Beacon but in
>>> my opinion it is  wrong for this purpose. A beacon sends a uniform signal in
>>> order to be discovered. The Beacon code sends signals to a beacon. And I can
>>> register at the beacon in which signals I'm interested in. Feels wrong to
>>> me.
>> Your words are reasonable. Interesting what Tudor think about it?
>> There are few things which I not like in SystemLogger (which not means that
>> everything is good with Beacon):
>> name Log to represent records of the underlying "physical log".
>> IMHO Log means exactly end logging backend like text file, syslog or
>> external database. Log is the place where we can explore (read) what was
>> happen.
> You are considering Log as a noun, but it can also be used as a verb.
> defn "13. to enter in a log; keep a record of; e.g. to log a day's events." [1]
> Stef said: "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"
> from which I understood that Log was the client interface, to be used
> like Transcript.  I think this is a good idea.  It would create the
> LogEntry
> [1] http://www.dictionary.com/browse/log
>> And now these backends are represented by subclasses of Logger:
>> StdoutStreamLogger, SysLogSender. I would call them StdoutLog, SysLog.
>> But with such change we need to call log entry differently. It can be
>> LogRecord or LogEntry. I not understand what was the problem with such
>> names? (there was some explanation why Log was chosen for this)
> Considering a "log" being the final resting point of the logged
> objects, that is the external disk text file or database, then within
> Pharo we don't have logs, only processes that write to the external
> logs, so Logger seems appropriate.  This is except for an in memory
> log, which for backend might need both MemoryLogger and
> MemoryObjectLog.
> Log would create and send theLogEntry to SystemLogger
> which forwards theLogEntry to other registered XXXLogger backend.
>> name SystemLogger for collection based log.
>> SystemLogger makes me think that it is singleton which is used by system and
>> I should not use it for my own application.
> I guess your application would make use SystemLogger via Log at the
> front end, and registering backends with SystemLogger.
>> I would call it like ObjectLog or NativeLog (following my first sentence
>> about Log).
> NativeLog doesn't seems right.  ObjectLog might be suitable for an
> in-memory backend, like above I mention MemoryObjectLog.
>> Also it is intercepted with SysLog name and I guess that's why it was called
>> SysLogSender and not SysLogLogger.
>> name LogDispatcher.
> LogDispatcher is okay, but I'm not sure of convention to be associate
> the "doer" with the "target" rather than the "item", where
> doer=Dispatcher; item=LogEntry; target=final-backend-log;   A little
> it sounds like its dispatching a whole log rather than one log entry.
> Maybe should be LogEntryDispatcher(??) or... SystemLogger as the
> marshalling point to forward to other XXXLoggers.
>> Here same problem as Log. What means physical logs dispatching? I know it is
>> introduced around Log as log entry. But it is not intuitive for me (same as
>> Log).
> I don't think Log should be a log entry.  It should be the user
> interface that creates and sends LogEntries via some XXXLogger.
>> In context of Log as real log (FileLog, SysLog) I would call this dispatcher
>> as Logger with same responsibility to register new events in all registered
>> logs.
>> announcements LogAdded and LogRemoved in the core.
>> Why any Logger should announce every log entry?
>> I think we not need special LoggerUI app. We can just inspect SystemLogger
>> instance to look at all recorded objects. And in perspective of my
>> suggestions it will mean that we just explore particular ObjectLog. And we
>> can extend GTInspector for this.
> GTInspector would need good live updating, filtering, clearing,
> scrolling to keep cursor position as new entries arrive.

It does already. Please take a look at Beacon :).


> cheers -ben


"Obvious things are difficult to teach."

More information about the Pharo-dev mailing list