debug logging

[Rel]

> That said, I think it's important we identify the categories of events
that we are interested in logging. Logging clang parameters might be a
good idea. As for parsing, I'm not too much of a fan of logging every
single parsing event - as that would lead to very very long outputs.

What do you think of:

INFO - default mode, for everything where we use System.out
SEVERE - default mode, for everything where we use System.err
FINE - debug mode (clang parameters and some other useful logs)
FINER - tracing mode (parsing events, and basically "what jextract wanted to do before it
crashed" :). I understand the importance of not giving it to the users, so it will be available only
to developers and would require to be manually enabled in logging.properties file first and then would require to build a new binary)

Do you think JUL would be a right candidate for logging in jextract?

> If my hunch is correct, I'd say that using a logger to allow for better
> debuggability when extending jextract is not the best way to do things.
> We should probably instead invest in making exceptions/errors more
meaningful

Curious to hear what others think here. The reasons why I found "tracing mode" is important are:
1. Please correct me if I am wrong: as I see, the spirit of panama branch is to use most recent Java available out there (in fact it may not be even GA yet, like right now Java 22?). Because of that, it is most likely not to be supported by IDEs (jextract requires Java 22, Eclipse last time I checked supported only Java 20)
- because of no IDE support, debugging in IDE seems not possible and so "tracing mode" can help here
2. It helps to find what is wrong when use jextract for big projects (very very long outputs can be addressed with grep)

How you debug jextract issues in panama branch now? And what would be the setup in this case (possibly such information is a good candidate for "jextract developer guide" later) so I can follow it

------- Original Message -------
On Monday, August 21st, 2023 at 2:09 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:


> Hi,
> I think adding better debugging capabilities to jextract is definitively
> helpful. I agree that right now jextract tends to be on the quiet side.
> 
> That said, I think it's important we identify the categories of events
> that we are interested in logging. Logging clang parameters might be a
> good idea. As for parsing, I'm not too much of a fan of logging every
> single parsing event - as that would lead to very very long outputs.
> 
> It almost seems like what you are looking for is some way to let
> jextract print some more info about what it wanted to do before it
> crashed. And I'm sure that this use case is mostly driven by the fact
> that you are working to extend jextract as opposed to use it.
> 
> If my hunch is correct, I'd say that using a logger to allow for better
> debuggability when extending jextract is not the best way to do things.
> We should probably instead invest in making exceptions/errors more
> meaningful (I often wished I had a way to print the specific piece of C
> header we were about to parse when some exception occurred).
> 
> And logging should instead be used for user-facing events (e.g. which
> headers are being parsed, which symbols are being excluded, which
> classes are being written, etc.).
> 
> An example of that is this:
> 
> > - Sometime you receive "Failed to parse
> > /tmp/jextract$1721579888733730008.h:" message, when you try to see
> > contents of /tmp/jextract$1721579888733730008.h to understand why it
> > is failed the file is already deleted.
> 
> 
> This is something a user should never see. E.g. if the user sees it - it
> is a bug - and you don't want better logging you (as a jextract user)
> just want it to be fixed.
> 
> Maurizio