[Libre-soc-bugs] [Bug 1224] refactor logging

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=1224

--- Comment #3 from Dmitry Selyutin <ghostmansd at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #1)
> (In reply to Dmitry Selyutin from comment #0)
> > Expectations:
> > 1. No sane logging should write to stdout. This is unconventional.
> 
> it doesn't matter. this was discussed over 4 years ago and nothing has
> changed.

Please quit this habit of "I cannot explain it now" and "it has been discussed
but I won't give any context or even the goddamn link". This is unconstructive.

> > At least choose stderr by default.
> 
> no, definitely not: it interferes with python exceptions

Exceptional cases are part of the logging. That's not a disadvantage, quite a
contrary. Stdout interferes with anything else but this didn't stop you.

> > But preferably choose NOTHING (see item 2).
> 
> set the environment variable to switch it off.
> 
> > 2. By default there's no need to write so much information unless explicitly
> > told.
> 
> yes there is.  if you have not been involved directly then it is hard to
> explain.

Please try anyway.

> > 3. There must be a possibility to tune the exact logging level per
> > component/subsystem. When debugging insndb, I don't want to see anything
> > related to SelectableInt.
> 
> if you have not been involved with the bit-level debugging, given that
> ISACaller is now a 4-year EXTREMELY complex Finite State Machine, it
> "makes no sense"

There is world besides ISACaller. The whole world is not evolving around it.

> > 4. There're standard ways of doing this. No, print is not the correct way to
> > do logging; it's good for casual debug. There's no need to reinvent the
> > wheel, Python already has a pretty well established logging.
> 
> ... which is longer and more complex to set up.
> 

Setting up a reinvented wheel is sufficiently complex to prefer standard ways
of doing the same.

> > 4. It leaves no options to have per-subsystem logging by other means than
> > making the underlying implementation aware of the subsystem. It should be up
> > to the subsystem which levels and options it supports.
> 
> should... but it needs money being paid to resolve... WITHOUT damaging
> my ability to understand one of the most complex Finite State Machines
> i have ever written.

It doesn't. In the end, it'd be the same log() incantation.

> this is not a "simple surely it should not be that way no really" task.
> making the changes you are proposing is WEEKS if not MONTHS of work
> to ensure that no damage occurs.

I think you exaggerating it. And I don't suggest to reserve any budget for
this, this is one of the infrastructure tasks meaningful mostly for us.


All in all, if you want to really persuade me, you need a technical rationale.
The overall idea I could deduce seems like "you're too young to understand it".
:-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.