<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 29/08/2023 07:38, Rel wrote:<br>
</div>
<blockquote type="cite" cite="mid:Nekc66k8Lh4OmozaiAtsbdymdwIRw5sE1-9YbKhyNWjdl-QOXYhd71Fxg3kEUKxkMy3rcQUTZPUo42T4F2u_m7fIgjfnfrtE8tiv7dzI_Yc=@proton.me">
<div style="font-family: Arial, sans-serif; font-size: 14px;"><span>Hi
Sundar,</span></div>
<div style="font-family: Arial, sans-serif; font-size: 14px;"><span><br>
</span></div>
<div style="font-family: Arial, sans-serif; font-size: 14px;"><span>Thanks
for reply.<br>
</span></div>
<div><span>I suppose this means that I need to use "panama" branch
for the MR?</span></div>
</blockquote>
I believe that would be best - all new development typically happens
on that branch. Other branches are meant to be more stable.<br>
<blockquote type="cite" cite="mid:Nekc66k8Lh4OmozaiAtsbdymdwIRw5sE1-9YbKhyNWjdl-QOXYhd71Fxg3kEUKxkMy3rcQUTZPUo42T4F2u_m7fIgjfnfrtE8tiv7dzI_Yc=@proton.me">
<div><br>
</div>
<div><span>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)<br>
</span></div>
</blockquote>
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 :-)<br>
<blockquote type="cite" cite="mid:Nekc66k8Lh4OmozaiAtsbdymdwIRw5sE1-9YbKhyNWjdl-QOXYhd71Fxg3kEUKxkMy3rcQUTZPUo42T4F2u_m7fIgjfnfrtE8tiv7dzI_Yc=@proton.me">
<div><br>
</div>
<div><span>Otherwise I possibly wait until next Java 22 early
access build?</span></div>
</blockquote>
<p>I'd say waiting for the first Java 22 EA which has support for
the new FFM API would probably be the easiest option.</p>
<p>Cheers<br>
Maurizio<br>
</p>
<blockquote type="cite" cite="mid:Nekc66k8Lh4OmozaiAtsbdymdwIRw5sE1-9YbKhyNWjdl-QOXYhd71Fxg3kEUKxkMy3rcQUTZPUo42T4F2u_m7fIgjfnfrtE8tiv7dzI_Yc=@proton.me">
<div><br>
</div>
<div><span>Thank you,</span></div>
<div style="font-family: Arial, sans-serif; font-size: 14px;"><br>
</div>
<div class="protonmail_quote"> ------- Original Message -------<br>
On Monday, August 28th, 2023 at 4:22 AM, Sundararajan
Athijegannathan <a class="moz-txt-link-rfc2396E" href="mailto:sundararajan.athijegannathan@oracle.com"><sundararajan.athijegannathan@oracle.com></a>
wrote:<br>
<br>
<blockquote class="protonmail_quote" type="cite">
<div class="elementToProof" style="font-family: Calibri,
Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0,
0, 0);">
Hi,</div>
<div class="elementToProof" style="font-family: Calibri,
Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0,
0, 0);">
<br>
</div>
<div class="elementToProof ContentPasted0 ContentPasted1" style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
The "panama" branch of "jextract" repo is the bleeding edge
code. You need to build "foreign-memaccess+abi" branch of <a id="LPlnkOWALinkPreview" href="https://urldefense.com/v3/__https://github.com/openjdk/panama-foreign__;!!ACWV5N9M2RV99hQ!NvCISQMthnpsf9YAgix3aMWxMPdkQaGMXIpL4mKDl8a-V8EPSjqscJ5WvDNH9ONE8PBs2uNtdd9MRPL5C9ip4ZA$" rel="noreferrer nofollow noopener" target="_blank" moz-do-not-send="true">https://github.com/openjdk/panama-foreign</a> and
pass the built JDK for "jdk22_home" parameter for jextract
Gradle build script.</div>
<div class="elementToProof ContentPasted0 ContentPasted1" style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof ContentPasted0 ContentPasted1" style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
Hope this helps,</div>
<div class="elementToProof ContentPasted0 ContentPasted1" style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
-Sundar</div>
<div class="_Entity _EType_OWALinkPreview _EId_OWALinkPreview
_EReadonly_1">
<div style="width: 100%; margin-top: 16px; margin-bottom:
16px; position: relative; max-width: 800px; min-width:
424px;" class="LPBorder965506" id="LPBorder_GTaHR0cHM6Ly9naXRodWIuY29tL29wZW5qZGsvcGFuYW1hLWZvcmVpZ24.">
<table style="padding: 12px 36px 12px 12px; width: 100%;
border-width: 1px; border-style: solid; border-color:
rgb(200, 200, 200); border-radius: 2px;" role="presentation" id="LPContainer965506">
<tbody>
<tr style="border-spacing: 0px;" valign="top">
<td>
<div style="position: relative; margin-right:
12px; height: 120px; overflow: hidden; width:
240px;" id="LPImageContainer965506">
<a href="https://urldefense.com/v3/__https://github.com/openjdk/panama-foreign__;!!ACWV5N9M2RV99hQ!NvCISQMthnpsf9YAgix3aMWxMPdkQaGMXIpL4mKDl8a-V8EPSjqscJ5WvDNH9ONE8PBs2uNtdd9MRPL5C9ip4ZA$" id="LPImageAnchor965506" target="_blank" rel="noreferrer nofollow noopener" moz-do-not-send="true"><img style="display:
block;" alt="" id="LPThumbnailImageId965506" src="https://opengraph.githubassets.com/2ade114bd2e33dddd5b0abf2e0b7789cdf5e118da91091f53a82150011d94dcb/openjdk/panama-foreign" moz-do-not-send="true" width="240" height="120"></a></div>
</td>
<td style="width: 100%;">
<div style="font-size: 21px; font-weight: 300;
margin-right: 8px; font-family:
wf_segoe-ui_light, "Segoe UI Light",
"Segoe WP Light", "Segoe
UI", "Segoe WP", Tahoma, Arial,
sans-serif; margin-bottom: 12px;" id="LPTitle965506">
<a style="text-decoration: none;" href="https://urldefense.com/v3/__https://github.com/openjdk/panama-foreign__;!!ACWV5N9M2RV99hQ!NvCISQMthnpsf9YAgix3aMWxMPdkQaGMXIpL4mKDl8a-V8EPSjqscJ5WvDNH9ONE8PBs2uNtdd9MRPL5C9ip4ZA$" id="LPUrlAnchor965506" target="_blank" rel="noreferrer nofollow noopener" moz-do-not-send="true">GitHub -
openjdk/panama-foreign:
https://openjdk.org/projects/panama</a></div>
<div style="font-size: 14px; max-height: 100px;
font-family: wf_segoe-ui_normal, "Segoe
UI", "Segoe WP", Tahoma, Arial,
sans-serif; margin-bottom: 12px; margin-right:
8px; overflow: hidden; color: rgb(102, 102,
102);" id="LPDescription965506">
<a class="moz-txt-link-freetext" href="https://openjdk.org/projects/panama">https://openjdk.org/projects/panama</a>. Contribute
to openjdk/panama-foreign development by
creating an account on GitHub.</div>
<div style="font-size: 14px; font-weight: 400;
font-family: wf_segoe-ui_normal, "Segoe
UI", "Segoe WP", Tahoma, Arial,
sans-serif; color: rgb(166, 166, 166);" id="LPMetadata965506">
github.com</div>
</td>
</tr>
</tbody>
</table>
</div>
</div>
<div style="font-family: Calibri, Arial, Helvetica,
sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<hr tabindex="-1" style="display:inline-block;width:98%">
<div dir="ltr" id="divRplyFwdMsg"><font style="font-size:
11pt; color: rgb(0, 0, 0);" face="Calibri, sans-serif"><b>From:</b>
jextract-dev <a class="moz-txt-link-rfc2396E" href="mailto:jextract-dev-retn@openjdk.org"><jextract-dev-retn@openjdk.org></a> on
behalf of Rel <a class="moz-txt-link-rfc2396E" href="mailto:enatai@proton.me"><enatai@proton.me></a><br>
<b>Sent:</b> 27 August 2023 06:53<br>
<b>To:</b> Maurizio Cimadamore
<a class="moz-txt-link-rfc2396E" href="mailto:maurizio.cimadamore@oracle.com"><maurizio.cimadamore@oracle.com></a><br>
<b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:jextract-dev@openjdk.org">jextract-dev@openjdk.org</a>
<a class="moz-txt-link-rfc2396E" href="mailto:jextract-dev@openjdk.org"><jextract-dev@openjdk.org></a><br>
<b>Subject:</b> Re: debug logging</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Thanks for reply and sharing the
setup. <br>
<br>
I will keep tracing separately in my branch and will
not include it as part of logging Merge Request.<br>
<br>
About MR: which branch should I use?<br>
<br>
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:<br>
<br>
jextract/src/main/java/org/openjdk/jextract/clang/Index.java:74: error:
cannot find symbol<br>
MemorySegment src =
arena.allocateFrom(file);<br>
^<br>
symbol: method allocateFrom(String)<br>
location: variable arena of type Arena<br>
<br>
Java is:<br>
<br>
java -version<br>
openjdk version "22-ea" 2024-03-19<br>
OpenJDK Runtime Environment (build 22-ea+12-877)<br>
OpenJDK 64-Bit Server VM (build 22-ea+12-877, mixed
mode, sharing)<br>
<br>
This is the latest from <a href="https://urldefense.com/v3/__https://jdk.java.net/22/__;!!ACWV5N9M2RV99hQ!NvCISQMthnpsf9YAgix3aMWxMPdkQaGMXIpL4mKDl8a-V8EPSjqscJ5WvDNH9ONE8PBs2uNtdd9MRPL5Mvj70Vc$" rel="noreferrer nofollow noopener" target="_blank" moz-do-not-send="true">https://jdk.java.net/22/</a><br>
<br>
------- Original Message -------<br>
On Wednesday, August 23rd, 2023 at 12:22 PM, Maurizio
Cimadamore <a class="moz-txt-link-rfc2396E" href="mailto:maurizio.cimadamore@oracle.com"><maurizio.cimadamore@oracle.com></a>
wrote:<br>
<br>
<br>
> On 23/08/2023 02:45, Rel wrote:<br>
> <br>
> > > That said, I think it's important we
identify the categories of events<br>
> > > that we are interested in logging.
Logging clang parameters might be a<br>
> > > good idea. As for parsing, I'm not too
much of a fan of logging every<br>
> > > single parsing event - as that would
lead to very very long outputs.<br>
> > <br>
> > What do you think of:<br>
> > <br>
> > INFO - default mode, for everything where we
use System.out<br>
> > SEVERE - default mode, for everything where
we use System.err<br>
> > FINE - debug mode (clang parameters and some
other useful logs)<br>
> > FINER - tracing mode (parsing events, and
basically "what jextract wanted to do before it<br>
> > crashed" :). I understand the importance of
not giving it to the users, so it will be available
only<br>
> > to developers and would require to be
manually enabled in logging.properties file first and
then would require to build a new binary)<br>
> > <br>
> > Do you think JUL would be a right candidate
for logging in jextract?<br>
> <br>
> The classification you propose, as well as using
JUL as a starting point<br>
> doesn't seem too unreasonable.<br>
> <br>
> > > If my hunch is correct, I'd say that
using a logger to allow for better<br>
> > > debuggability when extending jextract
is not the best way to do things.<br>
> > > We should probably instead invest in
making exceptions/errors more<br>
> > > meaningful<br>
> > <br>
> > Curious to hear what others think here. The
reasons why I found "tracing mode" is important are:<br>
> > 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)<br>
> > - because of no IDE support, debugging in
IDE seems not possible and so "tracing mode" can help
here<br>
> <br>
> <br>
> I can run jextract/panama fine using IntelliJ - I
have not tried with<br>
> Eclipse.<br>
> <br>
> But your comment confirms my suspicion that,
rather than logging things<br>
> that are "interesting", we're basically trying to
debug by println<br>
> statements :-)<br>
> <br>
> I obviously understand where you are coming from
(you are just trying to<br>
> get things done) - but I'm not sure whetever
level of finer logging we<br>
> add would ever be able to replace a debugger -
I'd suggest to try and<br>
> use an IDE which works for your use case :-)<br>
> <br>
> (separately, as we have a gradle build to build
jextract, how important<br>
> it is that Eclipse understands Java N ? Maybe
you'll miss some<br>
> highlighting for the new features, but the rest
should work? Or will<br>
> Eclipse categorically refuse to debug a class
with a version number it<br>
> doesn't understand?)<br>
> <br>
> > 2. It helps to find what is wrong when use
jextract for big projects (very very long outputs can
be addressed with grep)<br>
> > <br>
> > 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<br>
> <br>
> <br>
> See above - I use IntelliJ and its Gradle
integration. I'm able to build<br>
> fine. I have also installed the jtreg plugin:<br>
> <br>
> <a href="https://urldefense.com/v3/__https://github.com/openjdk/jtreg/tree/master/plugins/idea__;!!ACWV5N9M2RV99hQ!NvCISQMthnpsf9YAgix3aMWxMPdkQaGMXIpL4mKDl8a-V8EPSjqscJ5WvDNH9ONE8PBs2uNtdd9MRPL55EvLrRY$" rel="noreferrer nofollow noopener" target="_blank" moz-do-not-send="true">https://github.com/openjdk/jtreg/tree/master/plugins/idea</a><br>
> <br>
> Which allows me to run tests and debug them.<br>
> <br>
> Finally, I have defined some execution targets to
run jextract against<br>
> some header files I've defined locally, to allow
me to debug what happens.<br>
> <br>
> I'm pretty happy with this setup, and I feel
quite productive with it.<br>
> <br>
> Hope this helps<br>
> Maurizio<br>
> <br>
> > ------- Original Message -------<br>
> > On Monday, August 21st, 2023 at 2:09 PM,
Maurizio Cimadamore <a class="moz-txt-link-abbreviated" href="mailto:maurizio.cimadamore@oracle.com">maurizio.cimadamore@oracle.com</a>
wrote:<br>
> > <br>
> > > Hi,<br>
> > > I think adding better debugging
capabilities to jextract is definitively<br>
> > > helpful. I agree that right now
jextract tends to be on the quiet side.<br>
> > > <br>
> > > That said, I think it's important we
identify the categories of events<br>
> > > that we are interested in logging.
Logging clang parameters might be a<br>
> > > good idea. As for parsing, I'm not too
much of a fan of logging every<br>
> > > single parsing event - as that would
lead to very very long outputs.<br>
> > > <br>
> > > It almost seems like what you are
looking for is some way to let<br>
> > > jextract print some more info about
what it wanted to do before it<br>
> > > crashed. And I'm sure that this use
case is mostly driven by the fact<br>
> > > that you are working to extend jextract
as opposed to use it.<br>
> > > <br>
> > > If my hunch is correct, I'd say that
using a logger to allow for better<br>
> > > debuggability when extending jextract
is not the best way to do things.<br>
> > > We should probably instead invest in
making exceptions/errors more<br>
> > > meaningful (I often wished I had a way
to print the specific piece of C<br>
> > > header we were about to parse when some
exception occurred).<br>
> > > <br>
> > > And logging should instead be used for
user-facing events (e.g. which<br>
> > > headers are being parsed, which symbols
are being excluded, which<br>
> > > classes are being written, etc.).<br>
> > > <br>
> > > An example of that is this:<br>
> > > <br>
> > > > - Sometime you receive "Failed to
parse<br>
> > > >
/tmp/jextract$1721579888733730008.h:" message, when
you try to see<br>
> > > > contents of
/tmp/jextract$1721579888733730008.h to understand why
it<br>
> > > > is failed the file is already
deleted.<br>
> > > <br>
> > > This is something a user should never
see. E.g. if the user sees it - it<br>
> > > is a bug - and you don't want better
logging you (as a jextract user)<br>
> > > just want it to be fixed.<br>
> > > <br>
> > > Maurizio<br>
</div>
</span></font></div>
</blockquote>
<br>
</div>
</blockquote>
</body>
</html>