<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>