> The reason of my refactoring is to have a shared lib that can be used
> e.g. in Python. To do a direct fprintf in a library is not a good
> idea. I added a hook where the application can register a callback
> function which is in the style of vfprintf. In avrdude main.c then the final
> fprintf is done ... and if I want to do it Python, the messages can easily go
> to a Tkinter window after registering the python callback.
My reason was just less typing and save a level of indentation ;)
>
> >>
> >> Which one would be the preffered solution a) or b).
> > b).
> >
> > Also, I would propose that the macro prints the programmer name (if >the
> > message is generated by a programmer) or "avrdude: " if it is >generated by
> > "general" code.
>
> This is a good idea, that the module identifies itself within the generated
> message.
>
> I also added a severity level, which is currently INFO, WARNING, ERROR
> and is also given to the callback function (so the callback implementer could
> colorize or filter the output).
Maybe it is a good idea to introduce such levels in avrdude in general?
For example instead of writing
if(verbose > x) // x is a developer-defined constant, for example 2
fprintf(stder, ...);
one could write
if(verbose > WARNING)
...
In my opinion, this makes code much easier to read and it would be clear(er) to
(new) developers which verbosity level to use for a certain message.
>
> > What do you think about printing the function name and line number by
> >directly by the macro, if the verbosity level is high enough (3 or so)?
>
> Definitely I would like this idea. Is there a way to evaluate the current
> function name automatically by the preprocessor? (Like the __LINE__ or
> __FILE__ macros do?)
Yes: __func__.
>
>
> On 20.07.2012 20:40, Weddington, Eric wrote:
>> Why do you need to encapsulate these statements behind a macro? (That then
>> has to be written and then interpreted by developers when modifications are
>> made...)
>
Well, there is no "need" as such. Apart from the argument with the usage in a
library, I would argue less code. I don't think understanding of such a macro
by developers poses a problem, if it's intention is documented in the source
code (or if it is named properly).
Do you have other concerns than developers having to familiarize themselves
with the code?
>
>> What advantages does it bring, other than shorter typing?
>
> Beside shorter typing, a macro is a method where you can
> decouple things, well it might be regarded as german overengineering,
> but thats why I was asking.
I think we should discuss in more detail, what is done in a macro and what is
done in the callback.
Obviously, providing line numbers and function name (if desired) requires to be
put in a macro.
Coloring, if desired, could be implemented in either a callback
("print-function") or a macro.
I don't know print the programmers name, though.
Cheers,
Hannes
_______________________________________________
avrdude-dev mailing list
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
