debug logging

Tue Aug 29 10:27:18 UTC 2023

On 29/08/2023 07:38, Rel wrote:
> Hi Sundar,
>
> Thanks for reply.
> I suppose this means that I need to use "panama" branch for the MR?
I believe that would be best - all new development typically happens on 
that branch. Other branches are meant to be more stable.
>
> If so, do we have any nightly builds of "foreign-memaccess+abi"? The 
> reason why I ask is that, it may really help me to focus on 
> contributing to jextract rather than building OpenJDK from scratch :) 
> Some Dockerfile with all build setup could help as well (so I then can 
> just build OpenJDK and avoid preparing environment for that)
We do not have any nightly builds for that branch. That branch is 
"bleeding-edge" and so if you want to work on that, it is assumed you 
are ok with building the panama repo. This assumption might not be 100% 
correct, but it's not 100% wrong either :-)
>
> Otherwise I possibly wait until next Java 22 early access build?

I'd say waiting for the first Java 22 EA which has support for the new 
FFM API would probably be the easiest option.

Cheers
Maurizio

>
> Thank you,
>
> ------- Original Message -------
> On Monday, August 28th, 2023 at 4:22 AM, Sundararajan Athijegannathan 
> <sundararajan.athijegannathan at oracle.com> wrote:
>
>> Hi,
>>
>> The "panama" branch of "jextract" repo is the bleeding edge code. You 
>> need to build "foreign-memaccess+abi" branch of 
>> https://github.com/openjdk/panama-foreign 
>> <https://urldefense.com/v3/__https://github.com/openjdk/panama-foreign__;!!ACWV5N9M2RV99hQ!NvCISQMthnpsf9YAgix3aMWxMPdkQaGMXIpL4mKDl8a-V8EPSjqscJ5WvDNH9ONE8PBs2uNtdd9MRPL5C9ip4ZA$> and 
>> pass the built JDK for "jdk22_home" parameter for jextract Gradle 
>> build script.
>>
>> Hope this helps,
>> -Sundar
>> <https://urldefense.com/v3/__https://github.com/openjdk/panama-foreign__;!!ACWV5N9M2RV99hQ!NvCISQMthnpsf9YAgix3aMWxMPdkQaGMXIpL4mKDl8a-V8EPSjqscJ5WvDNH9ONE8PBs2uNtdd9MRPL5C9ip4ZA$>
>> 	
>> GitHub - openjdk/panama-foreign: https://openjdk.org/projects/panama 
>> <https://urldefense.com/v3/__https://github.com/openjdk/panama-foreign__;!!ACWV5N9M2RV99hQ!NvCISQMthnpsf9YAgix3aMWxMPdkQaGMXIpL4mKDl8a-V8EPSjqscJ5WvDNH9ONE8PBs2uNtdd9MRPL5C9ip4ZA$>
>> https://openjdk.org/projects/panama. Contribute to 
>> openjdk/panama-foreign development by creating an account on GitHub.
>> github.com
>>
>>
>> ------------------------------------------------------------------------
>> *From:* jextract-dev <jextract-dev-retn at openjdk.org> on behalf of Rel 
>> <enatai at proton.me>
>> *Sent:* 27 August 2023 06:53
>> *To:* Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
>> *Cc:* jextract-dev at openjdk.org <jextract-dev at openjdk.org>
>> *Subject:* Re: debug logging
>> Thanks for reply and sharing the setup.
>>
>> I will keep tracing separately in my branch and will not include it 
>> as part of logging Merge Request.
>>
>> About MR: which branch should I use?
>>
>> I tried "panama" branch with latest changes but since we switched to 
>> Java 22 in commit "ca8942c Update jextract/panama branch to track JDK 
>> 22" the build start failing for me:
>>
>> jextract/src/main/java/org/openjdk/jextract/clang/Index.java:74: 
>> error: cannot find symbol
>>             MemorySegment src = arena.allocateFrom(file);
>>                                      ^
>>   symbol:   method allocateFrom(String)
>>   location: variable arena of type Arena
>>
>> Java is:
>>
>> java -version
>> openjdk version "22-ea" 2024-03-19
>> OpenJDK Runtime Environment (build 22-ea+12-877)
>> OpenJDK 64-Bit Server VM (build 22-ea+12-877, mixed mode, sharing)
>>
>> This is the latest from https://jdk.java.net/22/ 
>> <https://urldefense.com/v3/__https://jdk.java.net/22/__;!!ACWV5N9M2RV99hQ!NvCISQMthnpsf9YAgix3aMWxMPdkQaGMXIpL4mKDl8a-V8EPSjqscJ5WvDNH9ONE8PBs2uNtdd9MRPL5Mvj70Vc$>
>>
>> ------- Original Message -------
>> On Wednesday, August 23rd, 2023 at 12:22 PM, Maurizio Cimadamore 
>> <maurizio.cimadamore at oracle.com> wrote:
>>
>>
>> > On 23/08/2023 02:45, Rel wrote:
>> >
>> > > > 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?
>> >
>> > The classification you propose, as well as using JUL as a starting 
>> point
>> > doesn't seem too unreasonable.
>> >
>> > > > 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
>> >
>> >
>> > I can run jextract/panama fine using IntelliJ - I have not tried with
>> > Eclipse.
>> >
>> > But your comment confirms my suspicion that, rather than logging things
>> > that are "interesting", we're basically trying to debug by println
>> > statements :-)
>> >
>> > I obviously understand where you are coming from (you are just 
>> trying to
>> > get things done) - but I'm not sure whetever level of finer logging we
>> > add would ever be able to replace a debugger - I'd suggest to try and
>> > use an IDE which works for your use case :-)
>> >
>> > (separately, as we have a gradle build to build jextract, how important
>> > it is that Eclipse understands Java N ? Maybe you'll miss some
>> > highlighting for the new features, but the rest should work? Or will
>> > Eclipse categorically refuse to debug a class with a version number it
>> > doesn't understand?)
>> >
>> > > 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
>> >
>> >
>> > See above - I use IntelliJ and its Gradle integration. I'm able to 
>> build
>> > fine. I have also installed the jtreg plugin:
>> >
>> > https://github.com/openjdk/jtreg/tree/master/plugins/idea 
>> <https://urldefense.com/v3/__https://github.com/openjdk/jtreg/tree/master/plugins/idea__;!!ACWV5N9M2RV99hQ!NvCISQMthnpsf9YAgix3aMWxMPdkQaGMXIpL4mKDl8a-V8EPSjqscJ5WvDNH9ONE8PBs2uNtdd9MRPL55EvLrRY$>
>> >
>> > Which allows me to run tests and debug them.
>> >
>> > Finally, I have defined some execution targets to run jextract against
>> > some header files I've defined locally, to allow me to debug what 
>> happens.
>> >
>> > I'm pretty happy with this setup, and I feel quite productive with it.
>> >
>> > Hope this helps
>> > Maurizio
>> >
>> > > ------- 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20230829/c35fe444/attachment-0001.htm>