[Devel] Feature request: error/debug message extension.

[Gabriel M. Beddingfield]

On 01/14/2012 02:48 PM, David Robillard wrote:
>> a. Adopt sprintf() syntax, which I don't believe can be implemented
>>      in a RT-safe manner.
[snip]
>
> Obviously standard syntax would be used.
>
> It is certainly possible to implement in an RT-safe manner, though the
> stdlib functions may not be.

So we want to put *THAT* complexity on the host??

> Regardless, that argument is basically "this is hard, so we should force
> plugins to do it", which is backwards.  Like it or not, code is going to
> have to do format-string-like things in order to print anything useful.
> To say otherwise is like saying "nobody will need to print numbers".

OK, but the plugin can use a simplified syntax for dynamic strings.

Proof of concept:  RtString<T> 
http://gitorious.org/composite/composite-labs/blobs/master/200912-rtstring/RtString.hpp

>> That's why I suggest that a callback to the plugin (or an event) is
>> required.  When the logging level changes, the plugin is notified of the
>> change.
>
> I guess this would do.  Yet more complexity...

...and optional complexity on the part of the plugin.  If they want to 
use a slow-ass query function, they can have at it.

>> I disagree.  Logging dynamic strings *can* be done RT-safe and with
>> miniscule overhead.
>
> Yes, but this again ignores the overwhelmingly important issue that only
> being able to print a single string *isn't useful*.  People simply need
> to print numbers and such.

You've misunderstood me, I think.  My dynamic strings I mean, "strings 
that can be manipulated to print numbers and sunch."

> Let's be realistic - not providing a useful print API capable of dealing
> with parameters means that people will resort to the solution you did -
> using snprintf on a static buffer.  If this isn't realtime safe either,
> what's been won?
>
> As always, where there is a choice, complexity belongs in the host.
> Making every plugin include a realtime-safe printf implementation would
> be absurd.

The plugins have the option of NOT using printf & co. for their 
strings... but can still have string formatting.

> If we want to avoid requiring the implementation of that entirely, we
> can simply just forbid using any arguments in the realtime thread.  No
> sense castrating the API in other contexts for this border case.

OK with me.

-gabriel