On 20.04.2025 17:53, ichthyo wrote:
A bit of wishful thinking: If it turned out that we do not actually need
all that sophistication... Then there could be a single static logging
function as entrance point, which dumps all messages into a ringbuffer.
And the GUI thread could pull them out and write them either to STDERR
or into a single widget related to the "primary synth"
...
On Wed, 23 Apr 2025 Kristian Amlie <krist...@amlie.name> wrote:
All the suggestions here sound reasonable to me.
Loggers are a pain point in almost every project, but a single static one
tends to be the least painful in my experience.
On 23.04.25 20:48, Will Godfrey wrote:
It hadn't even occurred to me that our logging code might not be thread-
safe :(
The extensions I added were mostly about being able to direct the output in
a more granular manner and to different destinations. Several of us had a go
at getting FLTK to put new entries at the bottom, and scroll up as
necessary. This, of course, is not need when directed to the CLI.
Many slightly problematic aspects in this code base can be
traced back to rather innocuous beginnings. This is how the Log function
looked in the first version in our Git imported by Cal 2010:
void Config::Log(string msg, bool tostderr)
{
if (showGui && !tostderr)
LogList.push_back(msg);
else
cerr << msg << endl;
}
At that time, there was one static Config instance, called "runtime".
In this shape, I'd say this is slightly sloppy, but kind-of acceptable.
The problems then gradually creped in, with the introduction of several
instances, background threads, etc, etc, etc....
Right now the interface to logging turns out to be a complication for
the task to confine the lib-MXML-dependency to some handling backend,
which requires to disentangle XML handling and config handling to some
degree. I will thus now introduce a logging functor, which can be used
as a drop-in replacement for the existing calls in XMLwrapper.
Typically, logging is only used by some kinds of functions, like file-IO
(for reporting errors). Passing such a logger directly can be a first step
to reduce the problem surface, while still keeping all functionality.
For the moment this gives some additional flexibility, without having to
address the topic of logging in general. And I'll leave it at that point.
-- Hermann
PS: For danger of stating the obvious: with logging it's typically a
good idea to separate a front-end (which quickly decides if a message
is discarded) from a back-end (which collects and consolidates messages).
Even if we decide that we /do want to retain/ an association to specific
Synth-instances, this can be achieved much simpler by placing a synth-ID
into thread-local storage to tag incoming messages.
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
