From nlisker at gmail.com  Sun Oct  2 21:31:41 2022
From: nlisker at gmail.com (Nir Lisker)
Date: Mon, 3 Oct 2022 00:31:41 +0300
Subject: GUI wrapper for jextract
Message-ID: <CA+0ynh-QQrdhWCf650ZLivxkGs0sXiNYddiYQPW3hV0HTno56Q@mail.gmail.com>

Hi,

After a short talk with Maurizio off-list, I started making a GUI wrapper
for jextract. I have several question/comments that came up during
development:

1. In order to help the user give the correct inputs, is there more info
somewhere on what each command accepts exactly? For example, what does '-I
<path>' look for exactly in the path? What does '-D <macro>' look for?
2. What are the default values for options that aren't specified and have
to have a default, like the output path, package name, and header class
name?
3. I think that having a capital I and a lowercase l options is confusing
in many fonts. Is there a reason not to use lowercase or uppercase on
everything?
4. I execute jextract using a java.lang.Process object and read its output
and error streams. I noticed that the process writes the output of
'--version' and '--help' to the error stream, while it makes more sense to
write them to the output stream. I'm on Windows in case it's OS dependent.
5. When analyzing the symbols of a header using the dump option, I need to
read the file that jextract creates from disk and then delete it. Is there
a way to read the jextract output directly? Either through the output
stream, or writing to a file in memory? Dealing with disk I/O is
cumbersome, comes with permission restrictions, and might be slow if done
for many files in a batch.
6. What file formats, except for .h, can jextract expect as a target? .c?
.hh?

Thanks,
Nir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20221003/4b96dee7/attachment.htm>

From sundararajan.athijegannathan at oracle.com  Mon Oct  3 03:34:26 2022
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Mon, 3 Oct 2022 03:34:26 +0000
Subject: GUI wrapper for jextract
In-Reply-To: <CA+0ynh-QQrdhWCf650ZLivxkGs0sXiNYddiYQPW3hV0HTno56Q@mail.gmail.com>
References: <CA+0ynh-QQrdhWCf650ZLivxkGs0sXiNYddiYQPW3hV0HTno56Q@mail.gmail.com>
Message-ID: <DM6PR10MB2954D700607DCE3E43719F64EA5B9@DM6PR10MB2954.namprd10.prod.outlook.com>

  1.  & 2 You may want to checkout https://github.com/openjdk/jextract
  2.
[https://opengraph.githubassets.com/fae24ba8d2ba2540bcc8e0d3b7e967e23bfb4a570d101dbcac2074b92aeb7d9f/openjdk/jextract]<https://github.com/openjdk/jextract>
GitHub - openjdk/jextract: https://openjdk.org/projects/code-tools<https://github.com/openjdk/jextract>
Jextract. jextract is a tool which mechanically generates Java bindings from a native library headers. This tools leverages the clang C API in order to parse the headers associated with a given native library, and the generated Java bindings build upon the Foreign Function & Memory API.The jextract tool was originally developed in the context of Project Panama (and then made available in the ...
github.com

??3. Options like -I and -l try to mimic same C compiler driver options
    4. Need to check consistency with the rest of the JDK bin tools on this. Btw for embedding use case, you can use ToolProvider API which jextract supports. No need to fork a separate process and deal with streams etc.
    5. Not getting your use case. "dump" is to get all symbols from header parsed - which you can edit and use it as argument in a later jextract session. That's use the intended use case.
   6. jextract supports only C language - the file extensions that "clang" compiler accepts for C programs should work.

-Sundar

________________________________
From: jextract-dev <jextract-dev-retn at openjdk.org> on behalf of Nir Lisker <nlisker at gmail.com>
Sent: 03 October 2022 03:01
To: jextract-dev at openjdk.org <jextract-dev at openjdk.org>
Subject: GUI wrapper for jextract

Hi,

After a short talk with Maurizio off-list, I started making a GUI wrapper for jextract. I have several question/comments that came up during development:

1. In order to help the user give the correct inputs, is there more info somewhere on what each command accepts exactly? For example, what does '-I <path>' look for exactly in the path? What does '-D <macro>' look for?
2. What are the default values for options that aren't specified and have to have a default, like the output path, package name, and header class name?
3. I think that having a capital I and a lowercase l options is confusing in many fonts. Is there a reason not to use lowercase or uppercase on everything?
4. I execute jextract using a java.lang.Process object and read its output and error streams. I noticed that the process writes the output of '--version' and '--help' to the error stream, while it makes more sense to write them to the output stream. I'm on Windows in case it's OS dependent.
5. When analyzing the symbols of a header using the dump option, I need to read the file that jextract creates from disk and then delete it. Is there a way to read the jextract output directly? Either through the output stream, or writing to a file in memory? Dealing with disk I/O is cumbersome, comes with permission restrictions, and might be slow if done for many files in a batch.
6. What file formats, except for .h, can jextract expect as a target? .c? .hh?

Thanks,
Nir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20221003/fbc6f23b/attachment-0001.htm>

From mcimadamore at openjdk.org  Mon Oct  3 11:06:04 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 3 Oct 2022 11:06:04 GMT
Subject: RFR: 7903339: unsigned typedefs are not extracted
In-Reply-To: <xClOycuiV8Qpi53RlcnLY6WnvV0cTzs47viJA6PvJ8k=.c66daad4-1541-4c30-9974-456810b961b7@github.com>
References: <xClOycuiV8Qpi53RlcnLY6WnvV0cTzs47viJA6PvJ8k=.c66daad4-1541-4c30-9974-456810b961b7@github.com>
Message-ID: <wiWsgRSqEpS8m-B-GbzlVgbfkbzzLTKfiLYQTmKMbNs=.fff8607c-b8eb-48b8-9cf2-f712d927c725@github.com>

On Fri, 30 Sep 2022 15:37:50 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> unsigned, signed primitive types were not handled in OutputFactory.visitTypedef.

Looks good

-------------

Marked as reviewed by mcimadamore (Committer).

PR: https://git.openjdk.org/jextract/pull/80

From sundar at openjdk.org  Mon Oct  3 11:07:27 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Mon, 3 Oct 2022 11:07:27 GMT
Subject: Integrated: 7903339: unsigned typedefs are not extracted
In-Reply-To: <xClOycuiV8Qpi53RlcnLY6WnvV0cTzs47viJA6PvJ8k=.c66daad4-1541-4c30-9974-456810b961b7@github.com>
References: <xClOycuiV8Qpi53RlcnLY6WnvV0cTzs47viJA6PvJ8k=.c66daad4-1541-4c30-9974-456810b961b7@github.com>
Message-ID: <7URl2xb3ahVs6aiTC4BBfkKJBAiGzJlZyC_vP1I5vWo=.027360cb-71ae-4ed5-82ad-07c1c4bc3e56@github.com>

On Fri, 30 Sep 2022 15:37:50 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> unsigned, signed primitive types were not handled in OutputFactory.visitTypedef.

This pull request has now been integrated.

Changeset: 1b204ebd
Author:    Athijegannathan Sundararajan <sundar at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/1b204ebd4a0df02891973177179343d830390234
Stats:     107 lines in 3 files changed: 106 ins; 0 del; 1 mod

7903339: unsigned typedefs are not extracted

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jextract/pull/80

From sundar at openjdk.org  Mon Oct  3 14:39:49 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Mon, 3 Oct 2022 14:39:49 GMT
Subject: RFR: 7903344: refactor OutputFactory to introduce various Declaration
 Visitor classes
Message-ID: <k6sbvFNJSE5Ka_XMPMVuLTpxE6odiVvEB0tZ1xEJ1IU=.24510754-9559-4813-a8bc-943ce1044d34@github.com>

Separate visitors for each activity (duplicate removal, include symbol filtering, name mangling and output generation)

-------------

Commit messages:
 - 7903344: refactor OutputFactory to introduce various Declaration Visitor classes

Changes: https://git.openjdk.org/jextract/pull/81/files
 Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=81&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903344
  Stats: 1409 lines in 18 files changed: 914 ins; 409 del; 86 mod
  Patch: https://git.openjdk.org/jextract/pull/81.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/81/head:pull/81

PR: https://git.openjdk.org/jextract/pull/81

From sundar at openjdk.org  Mon Oct  3 15:25:35 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Mon, 3 Oct 2022 15:25:35 GMT
Subject: RFR: 7903344: refactor OutputFactory to introduce various
 Declaration Visitor classes [v2]
In-Reply-To: <k6sbvFNJSE5Ka_XMPMVuLTpxE6odiVvEB0tZ1xEJ1IU=.24510754-9559-4813-a8bc-943ce1044d34@github.com>
References: <k6sbvFNJSE5Ka_XMPMVuLTpxE6odiVvEB0tZ1xEJ1IU=.24510754-9559-4813-a8bc-943ce1044d34@github.com>
Message-ID: <A2R74IiBCPQ5uF86GRQshVnjrO-8sbooOV7ORRVFsOA=.3baa3981-e7ff-45e4-989d-b3d4ef7361d2@github.com>

> Separate visitors for each activity (duplicate removal, include symbol filtering, name mangling and output generation)

Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:

  moved getAsSignedOrUnsigned to Utils. Using Utils function isStructOrUnion instead of enum check.

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/81/files
  - new: https://git.openjdk.org/jextract/pull/81/files/8dc03ce6..41761542

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=81&range=01
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=81&range=00-01

  Stats: 31 lines in 5 files changed: 12 ins; 15 del; 4 mod
  Patch: https://git.openjdk.org/jextract/pull/81.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/81/head:pull/81

PR: https://git.openjdk.org/jextract/pull/81

From nlisker at gmail.com  Mon Oct  3 21:19:52 2022
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 4 Oct 2022 00:19:52 +0300
Subject: GUI wrapper for jextract
In-Reply-To: <DM6PR10MB2954D700607DCE3E43719F64EA5B9@DM6PR10MB2954.namprd10.prod.outlook.com>
References: <CA+0ynh-QQrdhWCf650ZLivxkGs0sXiNYddiYQPW3hV0HTno56Q@mail.gmail.com>
 <DM6PR10MB2954D700607DCE3E43719F64EA5B9@DM6PR10MB2954.namprd10.prod.outlook.com>
Message-ID: <CA+0ynh8JBtwS2v+QceOn8b4SZ_nUdUQ3yafx9fVUSUE_oT5euQ@mail.gmail.com>

>
> 1 & 2 You may want to checkout https://github.com/openjdk/jextract
>
I already read everything there. I don't see the answers there.
What happens if a package name or header class name are not specified?
What does the path of -I need to point at? A folder? What file types are
accepted?
What format does a macro for -D come as? A file?


> 3. Options like -I and -l try to mimic same C compiler driver options
>
Alright.


> 4. Need to check consistency with the rest of the JDK bin tools on this.
> Btw for embedding use case, you can use ToolProvider API which jextract
> supports. No need to fork a separate process and deal with streams etc.
>
I wasn't familiar with this API; I will study it. Thanks.


> 5. Not getting your use case. "dump" is to get all symbols from header
> parsed - which you can edit and use it as argument in a later jextract
> session. That's use the intended use case.
>
The GUI wrapper reads all the symbols and allows the user to choose which
ones they want to bind to. This replaces the need for the user to modify a
text file. Think of a tree view:

[ ] myheader.h
  [ ] funcions
    [X] myfunc1
    [ ]  myfunc2
  [X] structs
    [X] mystruct1
    [X] mystruct2

This representation is easier to work with (batch selection etc,), but to
build it, a dump output is required. When the tool gets a header, it runs
--dump-includes on it, but doesn't want a file to be created, read, and
deleted. It wants the output directly "in memory".

6. jextract supports only C language - the file extensions that "clang"
> compiler accepts for C programs should work.

Alright, thanks.

- Nir

On Mon, Oct 3, 2022 at 6:34 AM Sundararajan Athijegannathan <
sundararajan.athijegannathan at oracle.com> wrote:

>
>    1. & 2 You may want to checkout https://github.com/openjdk/jextract
>    2.
>    <https://github.com/openjdk/jextract>
>    GitHub - openjdk/jextract: https://openjdk.org/projects/code-tools
>    <https://github.com/openjdk/jextract>
>    Jextract. jextract is a tool which mechanically generates Java
>    bindings from a native library headers. This tools leverages the clang C
>    API in order to parse the headers associated with a given native library,
>    and the generated Java bindings build upon the Foreign Function & Memory
>    API.The jextract tool was originally developed in the context of Project
>    Panama (and then made available in the ...
>    github.com
>
>
> 3. Options like -I and -l try to mimic same C compiler driver options
>     4. Need to check consistency with the rest of the JDK bin tools on
> this. Btw for embedding use case, you can use ToolProvider API which
> jextract supports. No need to fork a separate process and deal with streams
> etc.
>     5. Not getting your use case. "dump" is to get all symbols from header
> parsed - which you can edit and use it as argument in a later jextract
> session. That's use the intended use case.
>    6. jextract supports only C language - the file extensions that "clang"
> compiler accepts for C programs should work.
>
> -Sundar
>
> ------------------------------
> *From:* jextract-dev <jextract-dev-retn at openjdk.org> on behalf of Nir
> Lisker <nlisker at gmail.com>
> *Sent:* 03 October 2022 03:01
> *To:* jextract-dev at openjdk.org <jextract-dev at openjdk.org>
> *Subject:* GUI wrapper for jextract
>
> Hi,
>
> After a short talk with Maurizio off-list, I started making a GUI wrapper
> for jextract. I have several question/comments that came up during
> development:
>
> 1. In order to help the user give the correct inputs, is there more info
> somewhere on what each command accepts exactly? For example, what does '-I
> <path>' look for exactly in the path? What does '-D <macro>' look for?
> 2. What are the default values for options that aren't specified and have
> to have a default, like the output path, package name, and header class
> name?
> 3. I think that having a capital I and a lowercase l options is confusing
> in many fonts. Is there a reason not to use lowercase or uppercase on
> everything?
> 4. I execute jextract using a java.lang.Process object and read its output
> and error streams. I noticed that the process writes the output of
> '--version' and '--help' to the error stream, while it makes more sense to
> write them to the output stream. I'm on Windows in case it's OS dependent.
> 5. When analyzing the symbols of a header using the dump option, I need to
> read the file that jextract creates from disk and then delete it. Is there
> a way to read the jextract output directly? Either through the output
> stream, or writing to a file in memory? Dealing with disk I/O is
> cumbersome, comes with permission restrictions, and might be slow if done
> for many files in a batch.
> 6. What file formats, except for .h, can jextract expect as a target? .c?
> .hh?
>
> Thanks,
> Nir
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20221004/3da04f8a/attachment-0001.htm>

From sundararajan.athijegannathan at oracle.com  Tue Oct  4 06:56:19 2022
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Tue, 4 Oct 2022 06:56:19 +0000
Subject: [External] : Re: GUI wrapper for jextract
In-Reply-To: <CA+0ynh8JBtwS2v+QceOn8b4SZ_nUdUQ3yafx9fVUSUE_oT5euQ@mail.gmail.com>
References: <CA+0ynh-QQrdhWCf650ZLivxkGs0sXiNYddiYQPW3hV0HTno56Q@mail.gmail.com>
 <DM6PR10MB2954D700607DCE3E43719F64EA5B9@DM6PR10MB2954.namprd10.prod.outlook.com>
 <CA+0ynh8JBtwS2v+QceOn8b4SZ_nUdUQ3yafx9fVUSUE_oT5euQ@mail.gmail.com>
Message-ID: <DM6PR10MB29541F09621F32A3A2814832EA5A9@DM6PR10MB2954.namprd10.prod.outlook.com>

jextract --help output contains these lines (also available as a table in the README.md file in the project page).



-I <path>                      specify include files path

Isn't "include files path" suggestive enough?


-D <macro>                     define a C preprocessor macro

"C preprocessor macro" as accepted by C compilers.

-D FOO=42 defines macro FOO with value 42 (as accepted by C compilers).

If you don't specify package, generated classes go into unnamed package and classes are generated in current dir . If you don't specify header class name, "file.h" is mapped as "file_h". Both of these can be seen by simple usage of jextract.

-Sundar
________________________________
From: Nir Lisker <nlisker at gmail.com>
Sent: 04 October 2022 02:49
To: Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>
Cc: jextract-dev at openjdk.org <jextract-dev at openjdk.org>
Subject: [External] : Re: GUI wrapper for jextract

1 & 2 You may want to checkout https://github.com/openjdk/jextract<https://urldefense.com/v3/__https://github.com/openjdk/jextract__;!!ACWV5N9M2RV99hQ!Mazo0n821kiGiNzdX-0dCDVNST1uXWrfqlsw-6LEUs7MfISErCA4BBdv4zZHD3DQpi9hKmF7I-S0uagm09S8z8-BtmGw$>
I already read everything there. I don't see the answers there.
What happens if a package name or header class name are not specified?
What does the path of -I need to point at? A folder? What file types are accepted?
What format does a macro for -D come as? A file?

3. Options like -I and -l try to mimic same C compiler driver options
Alright.

4. Need to check consistency with the rest of the JDK bin tools on this. Btw for embedding use case, you can use ToolProvider API which jextract supports. No need to fork a separate process and deal with streams etc.
I wasn't familiar with this API; I will study it. Thanks.

5. Not getting your use case. "dump" is to get all symbols from header parsed - which you can edit and use it as argument in a later jextract session. That's use the intended use case.
The GUI wrapper reads all the symbols and allows the user to choose which ones they want to bind to. This replaces the need for the user to modify a text file. Think of a tree view:

[ ] myheader.h
  [ ] funcions
    [X] myfunc1
    [ ]  myfunc2
  [X] structs
    [X] mystruct1
    [X] mystruct2

This representation is easier to work with (batch selection etc,), but to build it, a dump output is required. When the tool gets a header, it runs --dump-includes on it, but doesn't want a file to be created, read, and deleted. It wants the output directly "in memory".

6. jextract supports only C language - the file extensions that "clang" compiler accepts for C programs should work.
Alright, thanks.

- Nir

On Mon, Oct 3, 2022 at 6:34 AM Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com<mailto:sundararajan.athijegannathan at oracle.com>> wrote:

  1.  & 2 You may want to checkout https://github.com/openjdk/jextract<https://urldefense.com/v3/__https://github.com/openjdk/jextract__;!!ACWV5N9M2RV99hQ!Mazo0n821kiGiNzdX-0dCDVNST1uXWrfqlsw-6LEUs7MfISErCA4BBdv4zZHD3DQpi9hKmF7I-S0uagm09S8z8-BtmGw$>
  2.
[https://opengraph.githubassets.com/fae24ba8d2ba2540bcc8e0d3b7e967e23bfb4a570d101dbcac2074b92aeb7d9f/openjdk/jextract]<https://urldefense.com/v3/__https://github.com/openjdk/jextract__;!!ACWV5N9M2RV99hQ!Mazo0n821kiGiNzdX-0dCDVNST1uXWrfqlsw-6LEUs7MfISErCA4BBdv4zZHD3DQpi9hKmF7I-S0uagm09S8z8-BtmGw$>
GitHub - openjdk/jextract: https://openjdk.org/projects/code-tools<https://urldefense.com/v3/__https://github.com/openjdk/jextract__;!!ACWV5N9M2RV99hQ!Mazo0n821kiGiNzdX-0dCDVNST1uXWrfqlsw-6LEUs7MfISErCA4BBdv4zZHD3DQpi9hKmF7I-S0uagm09S8z8-BtmGw$>
Jextract. jextract is a tool which mechanically generates Java bindings from a native library headers. This tools leverages the clang C API in order to parse the headers associated with a given native library, and the generated Java bindings build upon the Foreign Function & Memory API.The jextract tool was originally developed in the context of Project Panama (and then made available in the ...
github.com<https://urldefense.com/v3/__http://github.com__;!!ACWV5N9M2RV99hQ!Mazo0n821kiGiNzdX-0dCDVNST1uXWrfqlsw-6LEUs7MfISErCA4BBdv4zZHD3DQpi9hKmF7I-S0uagm09S8z9jv0OfV$>

??3. Options like -I and -l try to mimic same C compiler driver options
    4. Need to check consistency with the rest of the JDK bin tools on this. Btw for embedding use case, you can use ToolProvider API which jextract supports. No need to fork a separate process and deal with streams etc.
    5. Not getting your use case. "dump" is to get all symbols from header parsed - which you can edit and use it as argument in a later jextract session. That's use the intended use case.
   6. jextract supports only C language - the file extensions that "clang" compiler accepts for C programs should work.

-Sundar

________________________________
From: jextract-dev <jextract-dev-retn at openjdk.org<mailto:jextract-dev-retn at openjdk.org>> on behalf of Nir Lisker <nlisker at gmail.com<mailto:nlisker at gmail.com>>
Sent: 03 October 2022 03:01
To: jextract-dev at openjdk.org<mailto:jextract-dev at openjdk.org> <jextract-dev at openjdk.org<mailto:jextract-dev at openjdk.org>>
Subject: GUI wrapper for jextract

Hi,

After a short talk with Maurizio off-list, I started making a GUI wrapper for jextract. I have several question/comments that came up during development:

1. In order to help the user give the correct inputs, is there more info somewhere on what each command accepts exactly? For example, what does '-I <path>' look for exactly in the path? What does '-D <macro>' look for?
2. What are the default values for options that aren't specified and have to have a default, like the output path, package name, and header class name?
3. I think that having a capital I and a lowercase l options is confusing in many fonts. Is there a reason not to use lowercase or uppercase on everything?
4. I execute jextract using a java.lang.Process object and read its output and error streams. I noticed that the process writes the output of '--version' and '--help' to the error stream, while it makes more sense to write them to the output stream. I'm on Windows in case it's OS dependent.
5. When analyzing the symbols of a header using the dump option, I need to read the file that jextract creates from disk and then delete it. Is there a way to read the jextract output directly? Either through the output stream, or writing to a file in memory? Dealing with disk I/O is cumbersome, comes with permission restrictions, and might be slow if done for many files in a batch.
6. What file formats, except for .h, can jextract expect as a target? .c? .hh?

Thanks,
Nir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20221004/54ccf999/attachment-0001.htm>

From maurizio.cimadamore at oracle.com  Tue Oct  4 09:18:34 2022
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 4 Oct 2022 10:18:34 +0100
Subject: GUI wrapper for jextract
In-Reply-To: <CA+0ynh-QQrdhWCf650ZLivxkGs0sXiNYddiYQPW3hV0HTno56Q@mail.gmail.com>
References: <CA+0ynh-QQrdhWCf650ZLivxkGs0sXiNYddiYQPW3hV0HTno56Q@mail.gmail.com>
Message-ID: <7f91f9eb-32df-be44-ec53-8fb0b464206e@oracle.com>

Hi Nir,

On 02/10/2022 22:31, Nir Lisker wrote:
> 5. When analyzing the symbols of a header using the dump option, I 
> need to read the file that jextract creates from disk and then delete 
> it. Is there a way to read the jextract output directly? Either 
> through the output stream, or writing to a file in memory? Dealing 
> with disk I/O is cumbersome, comes with permission restrictions, and 
> might be slow if done for many files in a batch.

I think ultimately, working with files might be not ideal for your use case.

There is a pseudo-stable API to parse jextract files, in the 
JextractTool class (in the org.openjdk.jextract package, which should be 
exported by the jextract module):

`public static Declaration.Scoped parse(List<Path> headers, String... 
parserOptions) {`

We do not make any promise (at this stage at least) on the stability of 
the API. That said, it has not changed much (at all?) in the last couple 
of years.

What you get back is a "Declaration", which is used to model vars, 
structs, unions, typedefs, functions

Then, attached to declarations, there are "Type"s, which are used... 
well, to model types. Since some type can be structured (e.g. a struct 
type), they can point back to their declaration (e.g. Type.Declared).

Jextract does all it does by defining visitors on this basic declaration 
tree, which is obtained by wrapping the results of parsing a C header 
using the clang API (e.g. clang Cursors).

We did this to "sanitize" the output of clang, as well as to make our 
implementation more robust and less dependent from clang internals.

One option for you would be to invoke the parsing process this way, then 
get the tree and look at the results (e.g. with a visitor), which sounds 
better than parsing an option file.


Cheers
Maurizio


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20221004/a8f0cf3f/attachment.htm>

From mcimadamore at openjdk.org  Tue Oct  4 12:19:38 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 4 Oct 2022 12:19:38 GMT
Subject: RFR: 7903344: refactor OutputFactory to introduce various
 Declaration Visitor classes [v2]
In-Reply-To: <A2R74IiBCPQ5uF86GRQshVnjrO-8sbooOV7ORRVFsOA=.3baa3981-e7ff-45e4-989d-b3d4ef7361d2@github.com>
References: <k6sbvFNJSE5Ka_XMPMVuLTpxE6odiVvEB0tZ1xEJ1IU=.24510754-9559-4813-a8bc-943ce1044d34@github.com>
 <A2R74IiBCPQ5uF86GRQshVnjrO-8sbooOV7ORRVFsOA=.3baa3981-e7ff-45e4-989d-b3d4ef7361d2@github.com>
Message-ID: <6X3sYQOTywhYSecTSeAKIupd0Bixzpb9VB00npgFLDs=.991b9664-3e11-4088-8e6d-e618033c24d3@github.com>

On Mon, 3 Oct 2022 15:25:35 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

>> Separate visitors for each activity (duplicate removal, include symbol filtering, name mangling and output generation)
>
> Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved getAsSignedOrUnsigned to Utils. Using Utils function isStructOrUnion instead of enum check.

The patch improves the code, by separating orthogonal concerns into different visitor passes. It would of course be great if we could go fully there with name mangling as well, but regardless, it looks like a solid step forward (perhaps name mangling can be tackled separately).

samples/libffmpeg/compile.sh line 3:

> 1: jextract -t libffmpeg \
> 2:   -I /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include \
> 3:   -I /usr/local/Cellar/ffmpeg at 4/4.4.2_4/include \

Are these changes deliberate?

src/main/java/org/openjdk/jextract/impl/CodeGenerator.java line 40:

> 38:         var nameMangler = new NameMangler(headerName);
> 39:         var transformedDecl = Stream.of(decl).
> 40:             map(new IncludeFilter(includeHelper)::transform).

Nice pipeline!

src/main/java/org/openjdk/jextract/impl/IncludeFilter.java line 45:

> 43: 
> 44:     @Override
> 45:     public Declaration.Scoped transform(Declaration.Scoped header) {

Good to see this stuff factored away

src/main/java/org/openjdk/jextract/impl/NameMangler.java line 43:

> 41:  * java safe names via lookup methods.
> 42:  *
> 43:  * NOTE: Unlike other transforming tree visitors, this one is just identify

Can't we drop the TreeTransformer implementation?

src/main/java/org/openjdk/jextract/impl/NameMangler.java line 47:

> 45:  * Subsequent code generation steps can check the collected names using getters.
> 46:  */
> 47: final class NameMangler implements TreeTransformer, Declaration.Visitor<Void, Declaration> {

As discussed offline, there is still coupling between this class and OutputFactory. We have tried several approaches none of which "clicked", so we ended up collecting state in the mangler.

A cleaner solution would be to decorate declarations with "name" attributes, but adding an attribute creates a new declaration, which means there will be types in the tree which would need fixing up. Which is also tricky.

-------------

PR: https://git.openjdk.org/jextract/pull/81

From sundar at openjdk.org  Tue Oct  4 12:50:57 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Tue, 4 Oct 2022 12:50:57 GMT
Subject: RFR: 7903344: refactor OutputFactory to introduce various
 Declaration Visitor classes [v3]
In-Reply-To: <k6sbvFNJSE5Ka_XMPMVuLTpxE6odiVvEB0tZ1xEJ1IU=.24510754-9559-4813-a8bc-943ce1044d34@github.com>
References: <k6sbvFNJSE5Ka_XMPMVuLTpxE6odiVvEB0tZ1xEJ1IU=.24510754-9559-4813-a8bc-943ce1044d34@github.com>
Message-ID: <QZEHNa6pPcb6nrg9_GvqfsAuzQk1hTvctjO4qjxo3io=.c2385982-ffcf-44ea-bcdf-5d81ebcab1e1@github.com>

> Separate visitors for each activity (duplicate removal, include symbol filtering, name mangling and output generation)

Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:

  NameMangler does not implement TreeTranformer as suggested in code review.

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/81/files
  - new: https://git.openjdk.org/jextract/pull/81/files/41761542..849a8350

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=81&range=02
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=81&range=01-02

  Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jextract/pull/81.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/81/head:pull/81

PR: https://git.openjdk.org/jextract/pull/81

From sundar at openjdk.org  Tue Oct  4 12:50:57 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Tue, 4 Oct 2022 12:50:57 GMT
Subject: RFR: 7903344: refactor OutputFactory to introduce various
 Declaration Visitor classes [v2]
In-Reply-To: <6X3sYQOTywhYSecTSeAKIupd0Bixzpb9VB00npgFLDs=.991b9664-3e11-4088-8e6d-e618033c24d3@github.com>
References: <k6sbvFNJSE5Ka_XMPMVuLTpxE6odiVvEB0tZ1xEJ1IU=.24510754-9559-4813-a8bc-943ce1044d34@github.com>
 <A2R74IiBCPQ5uF86GRQshVnjrO-8sbooOV7ORRVFsOA=.3baa3981-e7ff-45e4-989d-b3d4ef7361d2@github.com>
 <6X3sYQOTywhYSecTSeAKIupd0Bixzpb9VB00npgFLDs=.991b9664-3e11-4088-8e6d-e618033c24d3@github.com>
Message-ID: <dOs6WUOo9e68fRbT-4sn9ko6nPWSrenbDwnVliply0o=.3fb9ac36-acd7-4db3-8456-c10d8633f878@github.com>

On Tue, 4 Oct 2022 12:08:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   moved getAsSignedOrUnsigned to Utils. Using Utils function isStructOrUnion instead of enum check.
>
> samples/libffmpeg/compile.sh line 3:
> 
>> 1: jextract -t libffmpeg \
>> 2:   -I /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include \
>> 3:   -I /usr/local/Cellar/ffmpeg at 4/4.4.2_4/include \
> 
> Are these changes deliberate?

Yes. Recent home-brew update brought this specific version on my machine. I need this for testing samples.

> src/main/java/org/openjdk/jextract/impl/NameMangler.java line 43:
> 
>> 41:  * java safe names via lookup methods.
>> 42:  *
>> 43:  * NOTE: Unlike other transforming tree visitors, this one is just identify
> 
> Can't we drop the TreeTransformer implementation?

Removed TreeTransformed implementation for NameMangler.

-------------

PR: https://git.openjdk.org/jextract/pull/81

From mcimadamore at openjdk.org  Tue Oct  4 13:05:44 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 4 Oct 2022 13:05:44 GMT
Subject: RFR: 7903344: refactor OutputFactory to introduce various
 Declaration Visitor classes [v3]
In-Reply-To: <QZEHNa6pPcb6nrg9_GvqfsAuzQk1hTvctjO4qjxo3io=.c2385982-ffcf-44ea-bcdf-5d81ebcab1e1@github.com>
References: <k6sbvFNJSE5Ka_XMPMVuLTpxE6odiVvEB0tZ1xEJ1IU=.24510754-9559-4813-a8bc-943ce1044d34@github.com>
 <QZEHNa6pPcb6nrg9_GvqfsAuzQk1hTvctjO4qjxo3io=.c2385982-ffcf-44ea-bcdf-5d81ebcab1e1@github.com>
Message-ID: <gbBW886ZiF7n1wd4-SvEOq8dLRxp4oiCDM2mO25xBe0=.6167f6f7-cd2e-4506-9e38-6dea7ac06989@github.com>

On Tue, 4 Oct 2022 12:50:57 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

>> Separate visitors for each activity (duplicate removal, include symbol filtering, name mangling and output generation)
>
> Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   NameMangler does not implement TreeTranformer as suggested in code review.

Looks good

-------------

Marked as reviewed by mcimadamore (Committer).

PR: https://git.openjdk.org/jextract/pull/81

From sundar at openjdk.org  Tue Oct  4 13:15:29 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Tue, 4 Oct 2022 13:15:29 GMT
Subject: Integrated: 7903344: refactor OutputFactory to introduce various
 Declaration Visitor classes
In-Reply-To: <k6sbvFNJSE5Ka_XMPMVuLTpxE6odiVvEB0tZ1xEJ1IU=.24510754-9559-4813-a8bc-943ce1044d34@github.com>
References: <k6sbvFNJSE5Ka_XMPMVuLTpxE6odiVvEB0tZ1xEJ1IU=.24510754-9559-4813-a8bc-943ce1044d34@github.com>
Message-ID: <xQnFUvBm75JiNtbZD65q6Yof-Vs3TjdDr4kBAu7xAkg=.0c00fd2c-0631-4684-9430-b90e90fbe0c6@github.com>

On Mon, 3 Oct 2022 14:29:54 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> Separate visitors for each activity (duplicate removal, include symbol filtering, name mangling and output generation)

This pull request has now been integrated.

Changeset: db6ca9a9
Author:    Athijegannathan Sundararajan <sundar at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/db6ca9a935a4d3cde0e1d8b2dc572eb8e08fa5a0
Stats:     1433 lines in 20 files changed: 923 ins; 421 del; 89 mod

7903344: refactor OutputFactory to introduce various Declaration Visitor classes

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jextract/pull/81

From nlisker at gmail.com  Wed Oct  5 00:59:56 2022
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 5 Oct 2022 03:59:56 +0300
Subject: [External] : Re: GUI wrapper for jextract
In-Reply-To: <DM6PR10MB29541F09621F32A3A2814832EA5A9@DM6PR10MB2954.namprd10.prod.outlook.com>
References: <CA+0ynh-QQrdhWCf650ZLivxkGs0sXiNYddiYQPW3hV0HTno56Q@mail.gmail.com>
 <DM6PR10MB2954D700607DCE3E43719F64EA5B9@DM6PR10MB2954.namprd10.prod.outlook.com>
 <CA+0ynh8JBtwS2v+QceOn8b4SZ_nUdUQ3yafx9fVUSUE_oT5euQ@mail.gmail.com>
 <DM6PR10MB29541F09621F32A3A2814832EA5A9@DM6PR10MB2954.namprd10.prod.outlook.com>
Message-ID: <CA+0ynh9e1qmCVuZab27RwNn5LgUe82VD5_uwYYoZqRKdpZYTbA@mail.gmail.com>

>
> Isn't "include files path" suggestive enough?


I would say no. A path points to one file (or folder). If I have several
include files, do I specify this option multiple times? Do I point it at a
folder that contains the includes? If I can point it at a folder, does it
ignore other files in it? This isn't documented in --help or the README.

-D FOO=42 defines macro FOO with value 42 (as accepted by C compilers).
>

So the format is just a string, not a file containing the macro. If I have
multiple macros, do I specify the option once for each?

If you don't specify package, generated classes go into unnamed package and
> classes are generated in current dir . If you don't specify header class
> name, "file.h" is mapped as "file_h". Both of these can be seen by simple
> usage of jextract.


It can be tested for the current behavior, but it isn't the documented
behavior, or could be not the intended behavior. Granted, this is still in
development, but Java rarely works by "try an example and that's how it
works".

Thanks,
Nir

On Tue, Oct 4, 2022 at 9:56 AM Sundararajan Athijegannathan <
sundararajan.athijegannathan at oracle.com> wrote:

> jextract --help output contains these lines (also available as a table in
> the README.md file in the project page).
>
>
>
> -I <path>                      specify include files path
>
> Isn't "include files path" suggestive enough?
>
> -D <macro>                     define a C preprocessor macro
>
> "C preprocessor macro" as accepted by C compilers.
>
> -D FOO=42 defines macro FOO with value 42 (as accepted by C compilers).
>
> If you don't specify package, generated classes go into unnamed package
> and classes are generated in current dir . If you don't specify header
> class name, "file.h" is mapped as "file_h". Both of these can be seen by
> simple usage of jextract.
>
> -Sundar
> ------------------------------
> *From:* Nir Lisker <nlisker at gmail.com>
> *Sent:* 04 October 2022 02:49
> *To:* Sundararajan Athijegannathan <
> sundararajan.athijegannathan at oracle.com>
> *Cc:* jextract-dev at openjdk.org <jextract-dev at openjdk.org>
> *Subject:* [External] : Re: GUI wrapper for jextract
>
>
> 1 & 2 You may want to checkout https://github.com/openjdk/jextract
> <https://urldefense.com/v3/__https://github.com/openjdk/jextract__;!!ACWV5N9M2RV99hQ!Mazo0n821kiGiNzdX-0dCDVNST1uXWrfqlsw-6LEUs7MfISErCA4BBdv4zZHD3DQpi9hKmF7I-S0uagm09S8z8-BtmGw$>
>
> I already read everything there. I don't see the answers there.
> What happens if a package name or header class name are not specified?
> What does the path of -I need to point at? A folder? What file types are
> accepted?
> What format does a macro for -D come as? A file?
>
>
> 3. Options like -I and -l try to mimic same C compiler driver options
>
> Alright.
>
>
> 4. Need to check consistency with the rest of the JDK bin tools on this.
> Btw for embedding use case, you can use ToolProvider API which jextract
> supports. No need to fork a separate process and deal with streams etc.
>
> I wasn't familiar with this API; I will study it. Thanks.
>
>
> 5. Not getting your use case. "dump" is to get all symbols from header
> parsed - which you can edit and use it as argument in a later jextract
> session. That's use the intended use case.
>
> The GUI wrapper reads all the symbols and allows the user to choose which
> ones they want to bind to. This replaces the need for the user to modify a
> text file. Think of a tree view:
>
> [ ] myheader.h
>   [ ] funcions
>     [X] myfunc1
>     [ ]  myfunc2
>   [X] structs
>     [X] mystruct1
>     [X] mystruct2
>
> This representation is easier to work with (batch selection etc,), but to
> build it, a dump output is required. When the tool gets a header, it runs
> --dump-includes on it, but doesn't want a file to be created, read, and
> deleted. It wants the output directly "in memory".
>
> 6. jextract supports only C language - the file extensions that "clang"
> compiler accepts for C programs should work.
>
> Alright, thanks.
>
> - Nir
>
> On Mon, Oct 3, 2022 at 6:34 AM Sundararajan Athijegannathan <
> sundararajan.athijegannathan at oracle.com> wrote:
>
>
>    1. & 2 You may want to checkout https://github.com/openjdk/jextract
>    <https://urldefense.com/v3/__https://github.com/openjdk/jextract__;!!ACWV5N9M2RV99hQ!Mazo0n821kiGiNzdX-0dCDVNST1uXWrfqlsw-6LEUs7MfISErCA4BBdv4zZHD3DQpi9hKmF7I-S0uagm09S8z8-BtmGw$>
>    2.
>
>    <https://urldefense.com/v3/__https://github.com/openjdk/jextract__;!!ACWV5N9M2RV99hQ!Mazo0n821kiGiNzdX-0dCDVNST1uXWrfqlsw-6LEUs7MfISErCA4BBdv4zZHD3DQpi9hKmF7I-S0uagm09S8z8-BtmGw$>
>    GitHub - openjdk/jextract: https://openjdk.org/projects/code-tools
>    <https://urldefense.com/v3/__https://github.com/openjdk/jextract__;!!ACWV5N9M2RV99hQ!Mazo0n821kiGiNzdX-0dCDVNST1uXWrfqlsw-6LEUs7MfISErCA4BBdv4zZHD3DQpi9hKmF7I-S0uagm09S8z8-BtmGw$>
>    Jextract. jextract is a tool which mechanically generates Java
>    bindings from a native library headers. This tools leverages the clang C
>    API in order to parse the headers associated with a given native library,
>    and the generated Java bindings build upon the Foreign Function & Memory
>    API.The jextract tool was originally developed in the context of Project
>    Panama (and then made available in the ...
>    github.com
>    <https://urldefense.com/v3/__http://github.com__;!!ACWV5N9M2RV99hQ!Mazo0n821kiGiNzdX-0dCDVNST1uXWrfqlsw-6LEUs7MfISErCA4BBdv4zZHD3DQpi9hKmF7I-S0uagm09S8z9jv0OfV$>
>
>
> 3. Options like -I and -l try to mimic same C compiler driver options
>     4. Need to check consistency with the rest of the JDK bin tools on
> this. Btw for embedding use case, you can use ToolProvider API which
> jextract supports. No need to fork a separate process and deal with streams
> etc.
>     5. Not getting your use case. "dump" is to get all symbols from header
> parsed - which you can edit and use it as argument in a later jextract
> session. That's use the intended use case.
>    6. jextract supports only C language - the file extensions that "clang"
> compiler accepts for C programs should work.
>
> -Sundar
>
> ------------------------------
> *From:* jextract-dev <jextract-dev-retn at openjdk.org> on behalf of Nir
> Lisker <nlisker at gmail.com>
> *Sent:* 03 October 2022 03:01
> *To:* jextract-dev at openjdk.org <jextract-dev at openjdk.org>
> *Subject:* GUI wrapper for jextract
>
> Hi,
>
> After a short talk with Maurizio off-list, I started making a GUI wrapper
> for jextract. I have several question/comments that came up during
> development:
>
> 1. In order to help the user give the correct inputs, is there more info
> somewhere on what each command accepts exactly? For example, what does '-I
> <path>' look for exactly in the path? What does '-D <macro>' look for?
> 2. What are the default values for options that aren't specified and have
> to have a default, like the output path, package name, and header class
> name?
> 3. I think that having a capital I and a lowercase l options is confusing
> in many fonts. Is there a reason not to use lowercase or uppercase on
> everything?
> 4. I execute jextract using a java.lang.Process object and read its output
> and error streams. I noticed that the process writes the output of
> '--version' and '--help' to the error stream, while it makes more sense to
> write them to the output stream. I'm on Windows in case it's OS dependent.
> 5. When analyzing the symbols of a header using the dump option, I need to
> read the file that jextract creates from disk and then delete it. Is there
> a way to read the jextract output directly? Either through the output
> stream, or writing to a file in memory? Dealing with disk I/O is
> cumbersome, comes with permission restrictions, and might be slow if done
> for many files in a batch.
> 6. What file formats, except for .h, can jextract expect as a target? .c?
> .hh?
>
> Thanks,
> Nir
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20221005/32e043e4/attachment-0001.htm>

From nlisker at gmail.com  Thu Oct  6 02:21:57 2022
From: nlisker at gmail.com (Nir Lisker)
Date: Thu, 6 Oct 2022 05:21:57 +0300
Subject: GUI wrapper for jextract
In-Reply-To: <7f91f9eb-32df-be44-ec53-8fb0b464206e@oracle.com>
References: <CA+0ynh-QQrdhWCf650ZLivxkGs0sXiNYddiYQPW3hV0HTno56Q@mail.gmail.com>
 <7f91f9eb-32df-be44-ec53-8fb0b464206e@oracle.com>
Message-ID: <CA+0ynh_gK_kz6YAM1ACewAnpobhitr_pzptUBmf0ECnPcq3V-w@mail.gmail.com>

Yes, if I can interface with the tool directly it would be ideal.

How can I add jextract as an external dependency for this? The jextract
build is not a full jdk, and I'm running on jdk-19.

On Tue, Oct 4, 2022 at 12:19 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Hi Nir,
> On 02/10/2022 22:31, Nir Lisker wrote:
>
> 5. When analyzing the symbols of a header using the dump option, I need to
> read the file that jextract creates from disk and then delete it. Is there
> a way to read the jextract output directly? Either through the output
> stream, or writing to a file in memory? Dealing with disk I/O is
> cumbersome, comes with permission restrictions, and might be slow if done
> for many files in a batch.
>
> I think ultimately, working with files might be not ideal for your use
> case.
>
> There is a pseudo-stable API to parse jextract files, in the JextractTool
> class (in the org.openjdk.jextract package, which should be exported by the
> jextract module):
>
> `public static Declaration.Scoped parse(List<Path> headers, String...
> parserOptions) {`
>
> We do not make any promise (at this stage at least) on the stability of
> the API. That said, it has not changed much (at all?) in the last couple of
> years.
>
> What you get back is a "Declaration", which is used to model vars,
> structs, unions, typedefs, functions
>
> Then, attached to declarations, there are "Type"s, which are used... well,
> to model types. Since some type can be structured (e.g. a struct type),
> they can point back to their declaration (e.g. Type.Declared).
>
> Jextract does all it does by defining visitors on this basic declaration
> tree, which is obtained by wrapping the results of parsing a C header using
> the clang API (e.g. clang Cursors).
>
> We did this to "sanitize" the output of clang, as well as to make our
> implementation more robust and less dependent from clang internals.
>
> One option for you would be to invoke the parsing process this way, then
> get the tree and look at the results (e.g. with a visitor), which sounds
> better than parsing an option file.
>
>
> Cheers
> Maurizio
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20221006/6392df6d/attachment.htm>

From sundararajan.athijegannathan at oracle.com  Thu Oct  6 05:35:37 2022
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Thu, 6 Oct 2022 05:35:37 +0000
Subject: GUI wrapper for jextract
In-Reply-To: <CA+0ynh_gK_kz6YAM1ACewAnpobhitr_pzptUBmf0ECnPcq3V-w@mail.gmail.com>
References: <CA+0ynh-QQrdhWCf650ZLivxkGs0sXiNYddiYQPW3hV0HTno56Q@mail.gmail.com>
 <7f91f9eb-32df-be44-ec53-8fb0b464206e@oracle.com>
 <CA+0ynh_gK_kz6YAM1ACewAnpobhitr_pzptUBmf0ECnPcq3V-w@mail.gmail.com>
Message-ID: <DM6PR10MB295428BB4565677BC8B75630EA5C9@DM6PR10MB2954.namprd10.prod.outlook.com>

Binary download of jextract does not include org.openjdk.jextract.jmod file (although that is part of jextract build folder).

For now, you can workaround using the following:



$ cat Main.java

import org.openjdk.jextract.*;

import java.awt.*;


class Main {

  public static void main(String[] a) {

    System.out.println(Frame.class);

    System.out.println(JextractTool.class);

  }

}


# assume that the current directory is "bin" dir of

# jextract tool. It has a javac executable in it.

# We use jextract's javac but pass module-path for the

# other jdk modules not included in jextract jdk image.


$ ./javac --module-path /Library/Java/JavaVirtualMachines/jdk-19.jdk/Contents/Home/jmods --add-modules java.desktop --enable-preview --source 19  Main.java


If you're okay with building jextract from the sources, then you use JDK 19's javac with the following option:

--module-path $JEXTRACT_REPO/build/jmods


[That directory $JEXTRACT_REPO/build/jmods contains org.openjdk.jextract.jmod module file]


-Sundar
________________________________
From: jextract-dev <jextract-dev-retn at openjdk.org> on behalf of Nir Lisker <nlisker at gmail.com>
Sent: 06 October 2022 07:51
To: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
Cc: jextract-dev at openjdk.org <jextract-dev at openjdk.org>
Subject: Re: GUI wrapper for jextract

Yes, if I can interface with the tool directly it would be ideal.

How can I add jextract as an external dependency for this? The jextract build is not a full jdk, and I'm running on jdk-19.

On Tue, Oct 4, 2022 at 12:19 PM Maurizio Cimadamore <maurizio.cimadamore at oracle.com<mailto:maurizio.cimadamore at oracle.com>> wrote:

Hi Nir,

On 02/10/2022 22:31, Nir Lisker wrote:
5. When analyzing the symbols of a header using the dump option, I need to read the file that jextract creates from disk and then delete it. Is there a way to read the jextract output directly? Either through the output stream, or writing to a file in memory? Dealing with disk I/O is cumbersome, comes with permission restrictions, and might be slow if done for many files in a batch.

I think ultimately, working with files might be not ideal for your use case.

There is a pseudo-stable API to parse jextract files, in the JextractTool class (in the org.openjdk.jextract package, which should be exported by the jextract module):

`public static Declaration.Scoped parse(List<Path> headers, String... parserOptions) {`

We do not make any promise (at this stage at least) on the stability of the API. That said, it has not changed much (at all?) in the last couple of years.

What you get back is a "Declaration", which is used to model vars, structs, unions, typedefs, functions

Then, attached to declarations, there are "Type"s, which are used... well, to model types. Since some type can be structured (e.g. a struct type), they can point back to their declaration (e.g. Type.Declared).

Jextract does all it does by defining visitors on this basic declaration tree, which is obtained by wrapping the results of parsing a C header using the clang API (e.g. clang Cursors).

We did this to "sanitize" the output of clang, as well as to make our implementation more robust and less dependent from clang internals.

One option for you would be to invoke the parsing process this way, then get the tree and look at the results (e.g. with a visitor), which sounds better than parsing an option file.

Cheers
Maurizio


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20221006/35e8b71b/attachment-0001.htm>

From weijun at openjdk.org  Thu Oct  6 18:09:05 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 6 Oct 2022 18:09:05 GMT
Subject: RFR: remove blanks in output like "int x ( int y)"
Message-ID: <9LXCTThmHPHt0S-G6j1qI9r1mu_GSCRCgnwkt0nxy_c=.696797d7-021d-4f3a-89a9-c6ff27fe2358@github.com>

Unless the spaces around "(" is a special style, this patch can clean (at least some of) them up.

-------------

Commit messages:
 - remove blanks in output like "int x ( int y)"

Changes: https://git.openjdk.org/jextract/pull/82/files
 Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=82&range=00
  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jextract/pull/82.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/82/head:pull/82

PR: https://git.openjdk.org/jextract/pull/82

From nlisker at gmail.com  Thu Oct  6 19:43:20 2022
From: nlisker at gmail.com (Nir Lisker)
Date: Thu, 6 Oct 2022 22:43:20 +0300
Subject: GUI wrapper for jextract
In-Reply-To: <DM6PR10MB295428BB4565677BC8B75630EA5C9@DM6PR10MB2954.namprd10.prod.outlook.com>
References: <CA+0ynh-QQrdhWCf650ZLivxkGs0sXiNYddiYQPW3hV0HTno56Q@mail.gmail.com>
 <7f91f9eb-32df-be44-ec53-8fb0b464206e@oracle.com>
 <CA+0ynh_gK_kz6YAM1ACewAnpobhitr_pzptUBmf0ECnPcq3V-w@mail.gmail.com>
 <DM6PR10MB295428BB4565677BC8B75630EA5C9@DM6PR10MB2954.namprd10.prod.outlook.com>
Message-ID: <CA+0ynh8ArisSxxdo1ugTVq70KFU9eqbNUYBeCnAkTB63SqB6Nw@mail.gmail.com>

I tried the workaround. Compilation is fine, but during runtime I get:

Error occurred during initialization of boot layer
java.lang.module.FindException: Module java.desktop not found

What is the run command that adds all the jdk modules?

On Thu, Oct 6, 2022 at 8:35 AM Sundararajan Athijegannathan <
sundararajan.athijegannathan at oracle.com> wrote:

> Binary download of jextract does not include org.openjdk.jextract.jmod
> file (although that is part of jextract build folder).
>
> For now, you can workaround using the following:
>
>
> $ cat Main.java
>
> import org.openjdk.jextract.*;
>
> import java.awt.*;
>
>
> class Main {
>
>   public static void main(String[] a) {
>
>     System.out.println(Frame.class);
>
>     System.out.println(JextractTool.class);
>
>   }
>
> }
>
>
> # assume that the current directory is "bin" dir of
>
> # jextract tool. It has a javac executable in it.
>
> # We use jextract's javac but pass module-path for the
>
> # other jdk modules not included in jextract jdk image.
>
>
> $ ./javac --module-path
> /Library/Java/JavaVirtualMachines/jdk-19.jdk/Contents/Home/jmods
> --add-modules java.desktop --enable-preview --source 19  Main.java
>
>
> If you're okay with building jextract from the sources, then you use JDK
> 19's javac with the following option:
>
> --module-path $JEXTRACT_REPO/build/jmods
>
>
> [That directory $JEXTRACT_REPO/build/jmods contains
> org.openjdk.jextract.jmod module file]
>
>
> -Sundar
> ------------------------------
> *From:* jextract-dev <jextract-dev-retn at openjdk.org> on behalf of Nir
> Lisker <nlisker at gmail.com>
> *Sent:* 06 October 2022 07:51
> *To:* Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
> *Cc:* jextract-dev at openjdk.org <jextract-dev at openjdk.org>
> *Subject:* Re: GUI wrapper for jextract
>
> Yes, if I can interface with the tool directly it would be ideal.
>
> How can I add jextract as an external dependency for this? The jextract
> build is not a full jdk, and I'm running on jdk-19.
>
> On Tue, Oct 4, 2022 at 12:19 PM Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com> wrote:
>
> Hi Nir,
> On 02/10/2022 22:31, Nir Lisker wrote:
>
> 5. When analyzing the symbols of a header using the dump option, I need to
> read the file that jextract creates from disk and then delete it. Is there
> a way to read the jextract output directly? Either through the output
> stream, or writing to a file in memory? Dealing with disk I/O is
> cumbersome, comes with permission restrictions, and might be slow if done
> for many files in a batch.
>
> I think ultimately, working with files might be not ideal for your use
> case.
>
> There is a pseudo-stable API to parse jextract files, in the JextractTool
> class (in the org.openjdk.jextract package, which should be exported by the
> jextract module):
>
> `public static Declaration.Scoped parse(List<Path> headers, String...
> parserOptions) {`
>
> We do not make any promise (at this stage at least) on the stability of
> the API. That said, it has not changed much (at all?) in the last couple of
> years.
>
> What you get back is a "Declaration", which is used to model vars,
> structs, unions, typedefs, functions
>
> Then, attached to declarations, there are "Type"s, which are used... well,
> to model types. Since some type can be structured (e.g. a struct type),
> they can point back to their declaration (e.g. Type.Declared).
>
> Jextract does all it does by defining visitors on this basic declaration
> tree, which is obtained by wrapping the results of parsing a C header using
> the clang API (e.g. clang Cursors).
>
> We did this to "sanitize" the output of clang, as well as to make our
> implementation more robust and less dependent from clang internals.
>
> One option for you would be to invoke the parsing process this way, then
> get the tree and look at the results (e.g. with a visitor), which sounds
> better than parsing an option file.
>
>
> Cheers
> Maurizio
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20221006/fbd47b40/attachment-0001.htm>

From sundar at openjdk.org  Fri Oct  7 09:31:45 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Fri, 7 Oct 2022 09:31:45 GMT
Subject: RFR: remove blanks in output like "int x ( int y)"
In-Reply-To: <9LXCTThmHPHt0S-G6j1qI9r1mu_GSCRCgnwkt0nxy_c=.696797d7-021d-4f3a-89a9-c6ff27fe2358@github.com>
References: <9LXCTThmHPHt0S-G6j1qI9r1mu_GSCRCgnwkt0nxy_c=.696797d7-021d-4f3a-89a9-c6ff27fe2358@github.com>
Message-ID: <JkFLWRxEVjzVN4XVzYfEh1ckOdhuzry2CTl17O0fXYU=.f270ea71-7b01-49bf-90a9-d7721de22e7c@github.com>

On Thu, 6 Oct 2022 17:59:21 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Unless the spaces around "(" is a special style, this patch can clean (at least some of) them up.

LGTM

-------------

Marked as reviewed by sundar (Committer).

PR: https://git.openjdk.org/jextract/pull/82

From sundar at openjdk.org  Fri Oct  7 09:48:38 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Fri, 7 Oct 2022 09:48:38 GMT
Subject: RFR: remove blanks in output like "int x ( int y)"
In-Reply-To: <9LXCTThmHPHt0S-G6j1qI9r1mu_GSCRCgnwkt0nxy_c=.696797d7-021d-4f3a-89a9-c6ff27fe2358@github.com>
References: <9LXCTThmHPHt0S-G6j1qI9r1mu_GSCRCgnwkt0nxy_c=.696797d7-021d-4f3a-89a9-c6ff27fe2358@github.com>
Message-ID: <Yc8-xT-Q0113A7gTAa59N0cKx61DMv72KZNf-rqjTHk=.1694bd65-119b-4b3d-a025-eca9cc384e00@github.com>

On Thu, 6 Oct 2022 17:59:21 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Unless the spaces around "(" is a special style, this patch can clean (at least some of) them up.

Note that the fix is directed to master branch which is for jdk 19. If you want the fix for jextract that works with Panama jdk, then "panama" is the branch

-------------

PR: https://git.openjdk.org/jextract/pull/82

From sundar at openjdk.org  Fri Oct  7 11:18:53 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Fri, 7 Oct 2022 11:18:53 GMT
Subject: RFR: 7903347: add long name option for all single letter options and
 expand help on default values for various options
Message-ID: <bCAxPv_nyY8II9oBxnZFf-1_m1ElrssXNU8ar3Vclj4=.ce4bf4e0-4dbe-498b-9ae4-1c689c028c1a@github.com>

* long option names for -I, -l, -D (--include-dir, --library, --define-macro)
* documented default values for header class name, target package and output directory
* explanation for -l / --library option.

-------------

Commit messages:
 - 7903347: add long name option for all single letter options and expand help on default values for various options
 - fixed help message for -l/--library. Sync'ed descriptive text in README.md table with --help output.
 - long options for -I, -l, -D. document default values used for header class name, target package, output dir,

Changes: https://git.openjdk.org/jextract/pull/83/files
 Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=83&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903347
  Stats: 145 lines in 10 files changed: 102 ins; 6 del; 37 mod
  Patch: https://git.openjdk.org/jextract/pull/83.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/83/head:pull/83

PR: https://git.openjdk.org/jextract/pull/83

From jvernee at openjdk.org  Fri Oct  7 11:33:38 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 7 Oct 2022 11:33:38 GMT
Subject: RFR: 7903347: add long name option for all single letter options
 and expand help on default values for various options
In-Reply-To: <bCAxPv_nyY8II9oBxnZFf-1_m1ElrssXNU8ar3Vclj4=.ce4bf4e0-4dbe-498b-9ae4-1c689c028c1a@github.com>
References: <bCAxPv_nyY8II9oBxnZFf-1_m1ElrssXNU8ar3Vclj4=.ce4bf4e0-4dbe-498b-9ae4-1c689c028c1a@github.com>
Message-ID: <cuxb8ntJ1F5iKLEJmGPjV0ynWiXL2OHrdeOrCrC5SrU=.b0d9ebbb-a897-498f-8679-7adc9439ed1b@github.com>

On Fri, 7 Oct 2022 11:12:18 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> * long option names for -I, -l, -D (--include-dir, --library, --define-macro)
> * documented default values for header class name, target package and output directory
> * explanation for -l / --library option.

LGTM. 1 minor nit

README.md line 130:

> 128: #### Command line options
> 129: 
> 130: The `jextract` tool includes several customization options. Users can select in which package the generated code should be emitted, and what the name of the main extracted class should be. If no package is specified, classes are generated in unnamed package. If no name is specified for the main header class, then header class name is

Suggestion:

The `jextract` tool includes several customization options. Users can select in which package the generated code should be emitted, and what the name of the main extracted class should be. If no package is specified, classes are generated in the unnamed package. If no name is specified for the main header class, then the header class name is

-------------

Marked as reviewed by jvernee (no project role).

PR: https://git.openjdk.org/jextract/pull/83

From sundar at openjdk.org  Fri Oct  7 11:45:31 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Fri, 7 Oct 2022 11:45:31 GMT
Subject: RFR: 7903347: add long name option for all single letter options
 and expand help on default values for various options [v2]
In-Reply-To: <bCAxPv_nyY8II9oBxnZFf-1_m1ElrssXNU8ar3Vclj4=.ce4bf4e0-4dbe-498b-9ae4-1c689c028c1a@github.com>
References: <bCAxPv_nyY8II9oBxnZFf-1_m1ElrssXNU8ar3Vclj4=.ce4bf4e0-4dbe-498b-9ae4-1c689c028c1a@github.com>
Message-ID: <rhkK9Ag4vMHxbasGoF5Fd6wTSr6GWZQj3dwtuBf2s4Y=.42005955-b9ee-4354-8f4b-3f95b4e45486@github.com>

> * long option names for -I, -l, -D (--include-dir, --library, --define-macro)
> * documented default values for header class name, target package and output directory
> * explanation for -l / --library option.

Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:

  Update README.md
  
  Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/83/files
  - new: https://git.openjdk.org/jextract/pull/83/files/560ec003..7a66dc99

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=83&range=01
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=83&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jextract/pull/83.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/83/head:pull/83

PR: https://git.openjdk.org/jextract/pull/83

From jvernee at openjdk.org  Fri Oct  7 11:55:16 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 7 Oct 2022 11:55:16 GMT
Subject: RFR: Add section on pre-built binaries to README
Message-ID: <H4u2zuaq-mvh_nkQwcj2pBE7ju1Q1sI55b4Ce31VGgI=.a41b5fbf-187e-4171-878e-93a34045db92@github.com>

I've added a short section on where to find the pre-built binaries. I think building jextract is less important than the information on usage if people can get binaries, so I've moved the section on building and testing to the bottom.

-------------

Commit messages:
 - Spelling
 - Use markdown link for link to jextract binary
 - Add section on pre-built binaries

Changes: https://git.openjdk.org/jextract/pull/84/files
 Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=84&range=00
  Stats: 109 lines in 1 file changed: 58 ins; 47 del; 4 mod
  Patch: https://git.openjdk.org/jextract/pull/84.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/84/head:pull/84

PR: https://git.openjdk.org/jextract/pull/84

From sundar at openjdk.org  Fri Oct  7 11:55:17 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Fri, 7 Oct 2022 11:55:17 GMT
Subject: RFR: Add section on pre-built binaries to README
In-Reply-To: <H4u2zuaq-mvh_nkQwcj2pBE7ju1Q1sI55b4Ce31VGgI=.a41b5fbf-187e-4171-878e-93a34045db92@github.com>
References: <H4u2zuaq-mvh_nkQwcj2pBE7ju1Q1sI55b4Ce31VGgI=.a41b5fbf-187e-4171-878e-93a34045db92@github.com>
Message-ID: <UljdpP0llLBaseedmC0CVSHs96zJDA0UiiGJdKRBNHw=.35e86fd3-92da-4892-a31f-784f04789f4c@github.com>

On Fri, 7 Oct 2022 11:43:36 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> I've added a short section on where to find the pre-built binaries. I think building jextract is less important than the information on usage if people can get binaries, so I've moved the section on building and testing to the bottom.

Looks good

README.md line 7:

> 5: ### Getting jextract
> 6: 
> 7: Pre-built binaries for jextract are peridodically released here: https://jdk.java.net/jextract/. These binaries are built from the `master` branch of this repo, and generally target the foreign memory access and function API in the latest mainline JDK (for which binaries can also be found on [jdk.java.net](https://jdk.java.net)).

could  https://jdk.java.net/jextract/ be a link?

-------------

Marked as reviewed by sundar (Committer).

PR: https://git.openjdk.org/jextract/pull/84

From sundar at openjdk.org  Fri Oct  7 11:55:17 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Fri, 7 Oct 2022 11:55:17 GMT
Subject: RFR: Add section on pre-built binaries to README
In-Reply-To: <UljdpP0llLBaseedmC0CVSHs96zJDA0UiiGJdKRBNHw=.35e86fd3-92da-4892-a31f-784f04789f4c@github.com>
References: <H4u2zuaq-mvh_nkQwcj2pBE7ju1Q1sI55b4Ce31VGgI=.a41b5fbf-187e-4171-878e-93a34045db92@github.com>
 <UljdpP0llLBaseedmC0CVSHs96zJDA0UiiGJdKRBNHw=.35e86fd3-92da-4892-a31f-784f04789f4c@github.com>
Message-ID: <8WB7ZWNdCVgFdWyRHQGi_8R5hhGALLDLOZdlY8dvhrA=.9c149862-9dbe-4aaf-8d4f-059d91fe2da5@github.com>

On Fri, 7 Oct 2022 11:46:21 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

>> I've added a short section on where to find the pre-built binaries. I think building jextract is less important than the information on usage if people can get binaries, so I've moved the section on building and testing to the bottom.
>
> README.md line 7:
> 
>> 5: ### Getting jextract
>> 6: 
>> 7: Pre-built binaries for jextract are peridodically released here: https://jdk.java.net/jextract/. These binaries are built from the `master` branch of this repo, and generally target the foreign memory access and function API in the latest mainline JDK (for which binaries can also be found on [jdk.java.net](https://jdk.java.net)).
> 
> could  https://jdk.java.net/jextract/ be a link?

peridodically spelling

-------------

PR: https://git.openjdk.org/jextract/pull/84

From sundar at openjdk.org  Fri Oct  7 12:35:53 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Fri, 7 Oct 2022 12:35:53 GMT
Subject: RFR: 7903347: add long name option for all single letter options
 and expand help on default values for various options [v3]
In-Reply-To: <bCAxPv_nyY8II9oBxnZFf-1_m1ElrssXNU8ar3Vclj4=.ce4bf4e0-4dbe-498b-9ae4-1c689c028c1a@github.com>
References: <bCAxPv_nyY8II9oBxnZFf-1_m1ElrssXNU8ar3Vclj4=.ce4bf4e0-4dbe-498b-9ae4-1c689c028c1a@github.com>
Message-ID: <X_mkSN4oxo5Kec7HAfFpTs55G4CzSwwp4HI_xdfY-_A=.08f9ec5b-f72a-402e-99e2-45c98fcaf23c@github.com>

> * long option names for -I, -l, -D (--include-dir, --library, --define-macro)
> * documented default values for header class name, target package and output directory
> * explanation for -l / --library option.

Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:

  consistent double quote in help and README.md ('foo.h' -> "foo.h")

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/83/files
  - new: https://git.openjdk.org/jextract/pull/83/files/7a66dc99..a4b74767

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=83&range=02
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=83&range=01-02

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jextract/pull/83.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/83/head:pull/83

PR: https://git.openjdk.org/jextract/pull/83

From weijun at openjdk.org  Fri Oct  7 12:53:41 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 7 Oct 2022 12:53:41 GMT
Subject: RFR: remove blanks in output like "int x ( int y)" [v2]
In-Reply-To: <9LXCTThmHPHt0S-G6j1qI9r1mu_GSCRCgnwkt0nxy_c=.696797d7-021d-4f3a-89a9-c6ff27fe2358@github.com>
References: <9LXCTThmHPHt0S-G6j1qI9r1mu_GSCRCgnwkt0nxy_c=.696797d7-021d-4f3a-89a9-c6ff27fe2358@github.com>
Message-ID: <URP26IigprIkeTe7IVfBVrRRxVMVY3W1rh24Y9rJ7_M=.25d26c69-38d6-488c-992b-60d475708e94@github.com>

> Unless the spaces around "(" is a special style, this patch can clean (at least some of) them up.

Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/82/files
  - new: https://git.openjdk.org/jextract/pull/82/files/b626777f..b626777f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=82&range=01
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=82&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jextract/pull/82.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/82/head:pull/82

PR: https://git.openjdk.org/jextract/pull/82

From mcimadamore at openjdk.org  Fri Oct  7 13:00:33 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 7 Oct 2022 13:00:33 GMT
Subject: RFR: 7903347: add long name option for all single letter options
 and expand help on default values for various options [v3]
In-Reply-To: <X_mkSN4oxo5Kec7HAfFpTs55G4CzSwwp4HI_xdfY-_A=.08f9ec5b-f72a-402e-99e2-45c98fcaf23c@github.com>
References: <bCAxPv_nyY8II9oBxnZFf-1_m1ElrssXNU8ar3Vclj4=.ce4bf4e0-4dbe-498b-9ae4-1c689c028c1a@github.com>
 <X_mkSN4oxo5Kec7HAfFpTs55G4CzSwwp4HI_xdfY-_A=.08f9ec5b-f72a-402e-99e2-45c98fcaf23c@github.com>
Message-ID: <LZ2xOJ5ssuozXJHONoaN1qQoVseO1zJZRpI9DY9zj9c=.d33fae36-cf5d-468d-b6ac-3f94d04d39ed@github.com>

On Fri, 7 Oct 2022 12:35:53 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

>> * long option names for -I, -l, -D (--include-dir, --library, --define-macro)
>> * documented default values for header class name, target package and output directory
>> * explanation for -l / --library option.
>
> Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   consistent double quote in help and README.md ('foo.h' -> "foo.h")

Added minor nit/suggestion

README.md line 140:

> 138: | `--header-class-name <name>`                                 | name of the generated header class. If this option is not specified, then header class name is derived from the header file name. For example, class "foo_h" for header "foo.h". |
> 139: | `-t, --target-package <package>`                             | target package name for the generated classes. If this option is not specified, then unnamed package is used.  |
> 140: | `-I, --include-dir <dir>`                                    | add directory to the end of the list of include search paths |

Suggestion:

| `-I, --include-dir <dir>`                                    | append directory to the include search paths. Include search paths are searched in order. For example, if `-I foo -I bar` is specified, header files will be searched in "foo" first, then (if nothing is found) in "bar".|

-------------

Marked as reviewed by mcimadamore (Committer).

PR: https://git.openjdk.org/jextract/pull/83

From sundar at openjdk.org  Fri Oct  7 13:24:32 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Fri, 7 Oct 2022 13:24:32 GMT
Subject: RFR: 7903347: add long name option for all single letter options
 and expand help on default values for various options [v4]
In-Reply-To: <bCAxPv_nyY8II9oBxnZFf-1_m1ElrssXNU8ar3Vclj4=.ce4bf4e0-4dbe-498b-9ae4-1c689c028c1a@github.com>
References: <bCAxPv_nyY8II9oBxnZFf-1_m1ElrssXNU8ar3Vclj4=.ce4bf4e0-4dbe-498b-9ae4-1c689c028c1a@github.com>
Message-ID: <uvJyHyEkHW2WuoaPg0_AVUuWo9G3bMwsgImNpp92_6I=.82e7fd5a-c5cb-4709-9432-5a51393b927e@github.com>

> * long option names for -I, -l, -D (--include-dir, --library, --define-macro)
> * documented default values for header class name, target package and output directory
> * explanation for -l / --library option.

Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:

  Update README.md for --include-dir
  
  Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/83/files
  - new: https://git.openjdk.org/jextract/pull/83/files/a4b74767..a6bbcc3d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=83&range=03
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=83&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jextract/pull/83.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/83/head:pull/83

PR: https://git.openjdk.org/jextract/pull/83

From sundar at openjdk.org  Fri Oct  7 13:28:50 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Fri, 7 Oct 2022 13:28:50 GMT
Subject: Integrated: 7903347: add long name option for all single letter
 options and expand help on default values for various options
In-Reply-To: <bCAxPv_nyY8II9oBxnZFf-1_m1ElrssXNU8ar3Vclj4=.ce4bf4e0-4dbe-498b-9ae4-1c689c028c1a@github.com>
References: <bCAxPv_nyY8II9oBxnZFf-1_m1ElrssXNU8ar3Vclj4=.ce4bf4e0-4dbe-498b-9ae4-1c689c028c1a@github.com>
Message-ID: <LfsMnF8TVWw7BatujY-YFROAcUN39_I7mgr2u6ewMZY=.e038c864-97e9-49dc-8268-938c9ed09277@github.com>

On Fri, 7 Oct 2022 11:12:18 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> * long option names for -I, -l, -D (--include-dir, --library, --define-macro)
> * documented default values for header class name, target package and output directory
> * explanation for -l / --library option.

This pull request has now been integrated.

Changeset: 71f28d88
Author:    Athijegannathan Sundararajan <sundar at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/71f28d880912f2ff2132b4ceb5964f72f1a7a6a1
Stats:     145 lines in 10 files changed: 102 ins; 6 del; 37 mod

7903347: add long name option for all single letter options and expand help on default values for various options

Reviewed-by: jvernee, mcimadamore

-------------

PR: https://git.openjdk.org/jextract/pull/83

From weijun at openjdk.org  Fri Oct  7 15:17:22 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 7 Oct 2022 15:17:22 GMT
Subject: RFR: remove blanks in output like "int x ( int y)" [v3]
In-Reply-To: <9LXCTThmHPHt0S-G6j1qI9r1mu_GSCRCgnwkt0nxy_c=.696797d7-021d-4f3a-89a9-c6ff27fe2358@github.com>
References: <9LXCTThmHPHt0S-G6j1qI9r1mu_GSCRCgnwkt0nxy_c=.696797d7-021d-4f3a-89a9-c6ff27fe2358@github.com>
Message-ID: <nxPxxWObkt004Sv6KLE5Dj-g1bwTYNB6NTEFeMx159M=.38e72693-4ebc-40b3-ac70-3e2cac8f6ffb@github.com>

> Unless the spaces around "(" is a special style, this patch can clean (at least some of) them up.

Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision:

  redo on new branch

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/82/files
  - new: https://git.openjdk.org/jextract/pull/82/files/b626777f..9449922a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=82&range=02
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=82&range=01-02

  Stats: 3130 lines in 162 files changed: 1811 ins; 725 del; 594 mod
  Patch: https://git.openjdk.org/jextract/pull/82.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/82/head:pull/82

PR: https://git.openjdk.org/jextract/pull/82

From weijun at openjdk.org  Fri Oct  7 15:17:24 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 7 Oct 2022 15:17:24 GMT
Subject: RFR: remove blanks in output like "int x ( int y)" [v2]
In-Reply-To: <URP26IigprIkeTe7IVfBVrRRxVMVY3W1rh24Y9rJ7_M=.25d26c69-38d6-488c-992b-60d475708e94@github.com>
References: <9LXCTThmHPHt0S-G6j1qI9r1mu_GSCRCgnwkt0nxy_c=.696797d7-021d-4f3a-89a9-c6ff27fe2358@github.com>
 <URP26IigprIkeTe7IVfBVrRRxVMVY3W1rh24Y9rJ7_M=.25d26c69-38d6-488c-992b-60d475708e94@github.com>
Message-ID: <rKxXzBDa8YA8EJ49YckxgyOQ4o9LFie7JmS0iWB-3-w=.8ffacfa8-62de-4f07-9eaa-8ebf3db43b27@github.com>

On Fri, 7 Oct 2022 12:53:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Unless the spaces around "(" is a special style, this patch can clean (at least some of) them up.
>
> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

Seems like part of my code change is already in the panama branch. I've created a new patch and force pushed it to overwrite the old commits.

-------------

PR: https://git.openjdk.org/jextract/pull/82

From maurizio.cimadamore at oracle.com  Sat Oct  8 21:02:39 2022
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Sat, 8 Oct 2022 22:02:39 +0100
Subject: GUI wrapper for jextract
In-Reply-To: <CA+0ynh8ArisSxxdo1ugTVq70KFU9eqbNUYBeCnAkTB63SqB6Nw@mail.gmail.com>
References: <CA+0ynh-QQrdhWCf650ZLivxkGs0sXiNYddiYQPW3hV0HTno56Q@mail.gmail.com>
 <7f91f9eb-32df-be44-ec53-8fb0b464206e@oracle.com>
 <CA+0ynh_gK_kz6YAM1ACewAnpobhitr_pzptUBmf0ECnPcq3V-w@mail.gmail.com>
 <DM6PR10MB295428BB4565677BC8B75630EA5C9@DM6PR10MB2954.namprd10.prod.outlook.com>
 <CA+0ynh8ArisSxxdo1ugTVq70KFU9eqbNUYBeCnAkTB63SqB6Nw@mail.gmail.com>
Message-ID: <b651fc1c-3047-801e-5163-b077ff7bd8ce@oracle.com>

Hi Nir,
we have made some tweaks to the command line option description:

https://github.com/openjdk/jextract/tree/panama

Hopefully that should reflect some of the discussion in this thread.

Thanks
Maurizio


On 06/10/2022 20:43, Nir Lisker wrote:
> I tried the workaround. Compilation is fine, but during?runtime I get:
>
> Error occurred during initialization of boot layer
> java.lang.module.FindException: Module java.desktop not found
>
> What is the run command that adds all the jdk modules?
>
> On Thu, Oct 6, 2022 at 8:35 AM Sundararajan Athijegannathan 
> <sundararajan.athijegannathan at oracle.com> wrote:
>
>     Binary download of jextract does not include
>     org.openjdk.jextract.jmod file (although that is part of jextract
>     build folder).
>
>     For now, you can workaround using the following:
>
>
>     $ cat Main.java
>
>     import org.openjdk.jextract.*;
>
>     import java.awt.*;
>
>
>     class Main {
>
>     public static void main(String[] a) {
>
>     System.out.println(Frame.class);
>
>     System.out.println(JextractTool.class);
>
>     }
>
>     }
>
>
>     # assume that the current directory is "bin" dir of
>
>     # jextract tool. It has a javac executable in it.
>
>     # We use jextract's javac but pass module-path for the
>
>     # other jdk modules not included in jextract jdk image.
>
>
>     $ ./javac --module-path
>     /Library/Java/JavaVirtualMachines/jdk-19.jdk/Contents/Home/jmods
>     --add-modules java.desktop --enable-preview --source 19Main.java
>
>
>
>     If you're okay with building jextract from the sources, then you
>     use JDK 19's javac with the following option:
>
>     --module-path $JEXTRACT_REPO/build/jmods
>
>
>     [That directory $JEXTRACT_REPO/build/jmods contains
>     org.openjdk.jextract.jmod module file]
>
>
>     -Sundar
>     ------------------------------------------------------------------------
>     *From:* jextract-dev <jextract-dev-retn at openjdk.org> on behalf of
>     Nir Lisker <nlisker at gmail.com>
>     *Sent:* 06 October 2022 07:51
>     *To:* Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
>     *Cc:* jextract-dev at openjdk.org <jextract-dev at openjdk.org>
>     *Subject:* Re: GUI wrapper for jextract
>     Yes, if I can interface with the tool directly it would be ideal.
>
>     How can I add jextract as an external dependency for this? The
>     jextract build is not a full jdk, and I'm running on jdk-19.
>
>     On Tue, Oct 4, 2022 at 12:19 PM Maurizio Cimadamore
>     <maurizio.cimadamore at oracle.com> wrote:
>
>         Hi Nir,
>
>         On 02/10/2022 22:31, Nir Lisker wrote:
>>         5. When analyzing the symbols of a header using the dump
>>         option, I need to read the file that jextract creates from
>>         disk and then delete it. Is there a way to read the jextract
>>         output directly? Either through the output stream, or writing
>>         to a file in memory? Dealing with disk I/O is cumbersome,
>>         comes with permission restrictions, and might be slow if done
>>         for many files in a batch.
>
>         I think ultimately, working with files might be not ideal for
>         your use case.
>
>         There is a pseudo-stable API to parse jextract files, in the
>         JextractTool class (in the org.openjdk.jextract package, which
>         should be exported by the jextract module):
>
>         `public static Declaration.Scoped parse(List<Path> headers,
>         String... parserOptions) {`
>
>         We do not make any promise (at this stage at least) on the
>         stability of the API. That said, it has not changed much (at
>         all?) in the last couple of years.
>
>         What you get back is a "Declaration", which is used to model
>         vars, structs, unions, typedefs, functions
>
>         Then, attached to declarations, there are "Type"s, which are
>         used... well, to model types. Since some type can be
>         structured (e.g. a struct type), they can point back to their
>         declaration (e.g. Type.Declared).
>
>         Jextract does all it does by defining visitors on this basic
>         declaration tree, which is obtained by wrapping the results of
>         parsing a C header using the clang API (e.g. clang Cursors).
>
>         We did this to "sanitize" the output of clang, as well as to
>         make our implementation more robust and less dependent from
>         clang internals.
>
>         One option for you would be to invoke the parsing process this
>         way, then get the tree and look at the results (e.g. with a
>         visitor), which sounds better than parsing an option file.
>
>
>         Cheers
>         Maurizio
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20221008/b2e10af9/attachment-0001.htm>

From mcimadamore at openjdk.org  Sat Oct  8 21:19:15 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Sat, 8 Oct 2022 21:19:15 GMT
Subject: RFR: Add section on pre-built binaries to README
In-Reply-To: <H4u2zuaq-mvh_nkQwcj2pBE7ju1Q1sI55b4Ce31VGgI=.a41b5fbf-187e-4171-878e-93a34045db92@github.com>
References: <H4u2zuaq-mvh_nkQwcj2pBE7ju1Q1sI55b4Ce31VGgI=.a41b5fbf-187e-4171-878e-93a34045db92@github.com>
Message-ID: <o6XWrw69X3wjEOtL1d9u_-W9zWlq8Qtwp6PO3hKw6zc=.cc9f3f06-481c-433e-a528-c6c3b94c5ead@github.com>

On Fri, 7 Oct 2022 11:43:36 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> I've added a short section on where to find the pre-built binaries. I think building jextract is less important than the information on usage if people can get binaries, so I've moved the section on building and testing to the bottom.

README.md line 7:

> 5: ### Getting jextract
> 6: 
> 7: Pre-built binaries for jextract are periodically released here: [https://jdk.java.net/jextract](https://jdk.java.net/jextract). These binaries are built from the `master` branch of this repo, and generally target the foreign memory access and function API in the latest mainline JDK (for which binaries can also be found on [jdk.java.net](https://jdk.java.net)).

Suggestion:

Pre-built binaries for jextract are periodically released [here](https://jdk.java.net/jextract). These binaries are built from the `master` branch of this repo, and target the foreign memory access and function API in the latest mainline JDK (for which binaries can be found [here](https://jdk.java.net)).

README.md line 9:

> 7: Pre-built binaries for jextract are periodically released here: [https://jdk.java.net/jextract](https://jdk.java.net/jextract). These binaries are built from the `master` branch of this repo, and generally target the foreign memory access and function API in the latest mainline JDK (for which binaries can also be found on [jdk.java.net](https://jdk.java.net)).
> 8: 
> 9: For getting a jextract version with all the latest updates and fixes, see the section on [building](#building--testing).

Suggestion:

Alternatively, to build jextract from the latest sources (which include all the latest updates and fixes) please refer to the [building](#building--testing) section below.

README.md line 186:

> 184: ```
> 185: 
> 186: Note however that running `jtreg` task requires `cmake` to be available on the `PATH`.

Suggestion:

Note: running `jtreg` task requires `cmake` to be available on the `PATH`.

-------------

PR: https://git.openjdk.org/jextract/pull/84

From mcimadamore at openjdk.org  Sat Oct  8 21:19:44 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Sat, 8 Oct 2022 21:19:44 GMT
Subject: RFR: remove blanks in output like "int x ( int y)" [v3]
In-Reply-To: <nxPxxWObkt004Sv6KLE5Dj-g1bwTYNB6NTEFeMx159M=.38e72693-4ebc-40b3-ac70-3e2cac8f6ffb@github.com>
References: <9LXCTThmHPHt0S-G6j1qI9r1mu_GSCRCgnwkt0nxy_c=.696797d7-021d-4f3a-89a9-c6ff27fe2358@github.com>
 <nxPxxWObkt004Sv6KLE5Dj-g1bwTYNB6NTEFeMx159M=.38e72693-4ebc-40b3-ac70-3e2cac8f6ffb@github.com>
Message-ID: <Td_qptflrKQM7fKWOBYS-A6qSwyOCTvV2QyiZlS2fNY=.63e0accb-74b2-477b-9677-ea010a7381d5@github.com>

On Fri, 7 Oct 2022 15:17:22 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Unless the spaces around "(" is a special style, this patch can clean (at least some of) them up.
>
> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   redo on new branch

Marked as reviewed by mcimadamore (Committer).

-------------

PR: https://git.openjdk.org/jextract/pull/82

From nlisker at gmail.com  Sat Oct  8 22:50:15 2022
From: nlisker at gmail.com (Nir Lisker)
Date: Sun, 9 Oct 2022 01:50:15 +0300
Subject: GUI wrapper for jextract
In-Reply-To: <b651fc1c-3047-801e-5163-b077ff7bd8ce@oracle.com>
References: <CA+0ynh-QQrdhWCf650ZLivxkGs0sXiNYddiYQPW3hV0HTno56Q@mail.gmail.com>
 <7f91f9eb-32df-be44-ec53-8fb0b464206e@oracle.com>
 <CA+0ynh_gK_kz6YAM1ACewAnpobhitr_pzptUBmf0ECnPcq3V-w@mail.gmail.com>
 <DM6PR10MB295428BB4565677BC8B75630EA5C9@DM6PR10MB2954.namprd10.prod.outlook.com>
 <CA+0ynh8ArisSxxdo1ugTVq70KFU9eqbNUYBeCnAkTB63SqB6Nw@mail.gmail.com>
 <b651fc1c-3047-801e-5163-b077ff7bd8ce@oracle.com>
Message-ID: <CA+0ynh8H24fyWXnzbc701GmMfz8+wQSzYfawW3Hi1HWhEqadDg@mail.gmail.com>

Hi Maurizio,

Yes, this is much clearer! I didn't see the PR or I would have noted a few
points there. I'll do it here now:

1. For macro, the Option column is great, but the Meaning column is
cryptic: "define to (or 1 if omitted)", to what? 1 what?
2. For --library, I would write in the Meaning column what file types are
accepted. I believe they are only .dll, .so, and .dylib. If this is obvious
then you can ignore this point.
3. Since --include-dir in its Option column specifically specifies <dir>
(which is great!), I would think about being specific like that in the
other options too. --library uses <path> that actually means <file>
(although you show this in the example under Meaning); --output uses <path>
that means <dir>, although this one is rather obvious because there's no
other option; --dump-includes specifies <String>, but is it just a name or
a can it be a whole path? (The example below shows how to use it with a
name.)

On the interfacing side, I'm still stuck with the issue of dependencies.
While I can compile with jextract's javac and pointing to the jmods of the
JDK, I can't do it during runtime (execution of 'java'). I'm still using a
Process with streams in the meantime.

Thanks,
Nir

On Sun, Oct 9, 2022 at 12:02 AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Hi Nir,
> we have made some tweaks to the command line option description:
>
> https://github.com/openjdk/jextract/tree/panama
>
> Hopefully that should reflect some of the discussion in this thread.
>
> Thanks
> Maurizio
>
>
> On 06/10/2022 20:43, Nir Lisker wrote:
>
> I tried the workaround. Compilation is fine, but during runtime I get:
>
> Error occurred during initialization of boot layer
> java.lang.module.FindException: Module java.desktop not found
>
> What is the run command that adds all the jdk modules?
>
> On Thu, Oct 6, 2022 at 8:35 AM Sundararajan Athijegannathan <
> sundararajan.athijegannathan at oracle.com> wrote:
>
>> Binary download of jextract does not include org.openjdk.jextract.jmod
>> file (although that is part of jextract build folder).
>>
>> For now, you can workaround using the following:
>>
>>
>> $ cat Main.java
>>
>> import org.openjdk.jextract.*;
>>
>> import java.awt.*;
>>
>>
>> class Main {
>>
>>   public static void main(String[] a) {
>>
>>     System.out.println(Frame.class);
>>
>>     System.out.println(JextractTool.class);
>>
>>   }
>>
>> }
>>
>>
>> # assume that the current directory is "bin" dir of
>>
>> # jextract tool. It has a javac executable in it.
>>
>> # We use jextract's javac but pass module-path for the
>>
>> # other jdk modules not included in jextract jdk image.
>>
>>
>> $ ./javac --module-path
>> /Library/Java/JavaVirtualMachines/jdk-19.jdk/Contents/Home/jmods
>> --add-modules java.desktop --enable-preview --source 19  Main.java
>>
>>
>> If you're okay with building jextract from the sources, then you use JDK
>> 19's javac with the following option:
>>
>> --module-path $JEXTRACT_REPO/build/jmods
>>
>>
>> [That directory $JEXTRACT_REPO/build/jmods contains
>> org.openjdk.jextract.jmod module file]
>>
>>
>> -Sundar
>> ------------------------------
>> *From:* jextract-dev <jextract-dev-retn at openjdk.org> on behalf of Nir
>> Lisker <nlisker at gmail.com>
>> *Sent:* 06 October 2022 07:51
>> *To:* Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
>> *Cc:* jextract-dev at openjdk.org <jextract-dev at openjdk.org>
>> *Subject:* Re: GUI wrapper for jextract
>>
>> Yes, if I can interface with the tool directly it would be ideal.
>>
>> How can I add jextract as an external dependency for this? The jextract
>> build is not a full jdk, and I'm running on jdk-19.
>>
>> On Tue, Oct 4, 2022 at 12:19 PM Maurizio Cimadamore <
>> maurizio.cimadamore at oracle.com> wrote:
>>
>> Hi Nir,
>> On 02/10/2022 22:31, Nir Lisker wrote:
>>
>> 5. When analyzing the symbols of a header using the dump option, I need
>> to read the file that jextract creates from disk and then delete it. Is
>> there a way to read the jextract output directly? Either through the output
>> stream, or writing to a file in memory? Dealing with disk I/O is
>> cumbersome, comes with permission restrictions, and might be slow if done
>> for many files in a batch.
>>
>> I think ultimately, working with files might be not ideal for your use
>> case.
>>
>> There is a pseudo-stable API to parse jextract files, in the JextractTool
>> class (in the org.openjdk.jextract package, which should be exported by the
>> jextract module):
>>
>> `public static Declaration.Scoped parse(List<Path> headers, String...
>> parserOptions) {`
>>
>> We do not make any promise (at this stage at least) on the stability of
>> the API. That said, it has not changed much (at all?) in the last couple of
>> years.
>>
>> What you get back is a "Declaration", which is used to model vars,
>> structs, unions, typedefs, functions
>>
>> Then, attached to declarations, there are "Type"s, which are used...
>> well, to model types. Since some type can be structured (e.g. a struct
>> type), they can point back to their declaration (e.g. Type.Declared).
>>
>> Jextract does all it does by defining visitors on this basic declaration
>> tree, which is obtained by wrapping the results of parsing a C header using
>> the clang API (e.g. clang Cursors).
>>
>> We did this to "sanitize" the output of clang, as well as to make our
>> implementation more robust and less dependent from clang internals.
>>
>> One option for you would be to invoke the parsing process this way, then
>> get the tree and look at the results (e.g. with a visitor), which sounds
>> better than parsing an option file.
>>
>>
>> Cheers
>> Maurizio
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20221009/c5d85eb4/attachment-0001.htm>

From nlisker at gmail.com  Sun Oct  9 08:55:22 2022
From: nlisker at gmail.com (Nir Lisker)
Date: Sun, 9 Oct 2022 11:55:22 +0300
Subject: GUI wrapper for jextract
In-Reply-To: <CA+0ynh8H24fyWXnzbc701GmMfz8+wQSzYfawW3Hi1HWhEqadDg@mail.gmail.com>
References: <CA+0ynh-QQrdhWCf650ZLivxkGs0sXiNYddiYQPW3hV0HTno56Q@mail.gmail.com>
 <7f91f9eb-32df-be44-ec53-8fb0b464206e@oracle.com>
 <CA+0ynh_gK_kz6YAM1ACewAnpobhitr_pzptUBmf0ECnPcq3V-w@mail.gmail.com>
 <DM6PR10MB295428BB4565677BC8B75630EA5C9@DM6PR10MB2954.namprd10.prod.outlook.com>
 <CA+0ynh8ArisSxxdo1ugTVq70KFU9eqbNUYBeCnAkTB63SqB6Nw@mail.gmail.com>
 <b651fc1c-3047-801e-5163-b077ff7bd8ce@oracle.com>
 <CA+0ynh8H24fyWXnzbc701GmMfz8+wQSzYfawW3Hi1HWhEqadDg@mail.gmail.com>
Message-ID: <CA+0ynh-NjJ_E7KM9g3gR2p_hHOvqr+nRKG1PpETM4JOxB1ZN7g@mail.gmail.com>

Another point that I missed is: when specifying a directory path for
-include-dir, the docs don't say if the search is recursive (searches also
within folders with the directory).

On Sun, Oct 9, 2022 at 1:50 AM Nir Lisker <nlisker at gmail.com> wrote:

> Hi Maurizio,
>
> Yes, this is much clearer! I didn't see the PR or I would have noted a few
> points there. I'll do it here now:
>
> 1. For macro, the Option column is great, but the Meaning column is
> cryptic: "define to (or 1 if omitted)", to what? 1 what?
> 2. For --library, I would write in the Meaning column what file types are
> accepted. I believe they are only .dll, .so, and .dylib. If this is obvious
> then you can ignore this point.
> 3. Since --include-dir in its Option column specifically specifies <dir>
> (which is great!), I would think about being specific like that in the
> other options too. --library uses <path> that actually means <file>
> (although you show this in the example under Meaning); --output uses <path>
> that means <dir>, although this one is rather obvious because there's no
> other option; --dump-includes specifies <String>, but is it just a name or
> a can it be a whole path? (The example below shows how to use it with a
> name.)
>
> On the interfacing side, I'm still stuck with the issue of dependencies.
> While I can compile with jextract's javac and pointing to the jmods of the
> JDK, I can't do it during runtime (execution of 'java'). I'm still using a
> Process with streams in the meantime.
>
> Thanks,
> Nir
>
> On Sun, Oct 9, 2022 at 12:02 AM Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com> wrote:
>
>> Hi Nir,
>> we have made some tweaks to the command line option description:
>>
>> https://github.com/openjdk/jextract/tree/panama
>>
>> Hopefully that should reflect some of the discussion in this thread.
>>
>> Thanks
>> Maurizio
>>
>>
>> On 06/10/2022 20:43, Nir Lisker wrote:
>>
>> I tried the workaround. Compilation is fine, but during runtime I get:
>>
>> Error occurred during initialization of boot layer
>> java.lang.module.FindException: Module java.desktop not found
>>
>> What is the run command that adds all the jdk modules?
>>
>> On Thu, Oct 6, 2022 at 8:35 AM Sundararajan Athijegannathan <
>> sundararajan.athijegannathan at oracle.com> wrote:
>>
>>> Binary download of jextract does not include org.openjdk.jextract.jmod
>>> file (although that is part of jextract build folder).
>>>
>>> For now, you can workaround using the following:
>>>
>>>
>>> $ cat Main.java
>>>
>>> import org.openjdk.jextract.*;
>>>
>>> import java.awt.*;
>>>
>>>
>>> class Main {
>>>
>>>   public static void main(String[] a) {
>>>
>>>     System.out.println(Frame.class);
>>>
>>>     System.out.println(JextractTool.class);
>>>
>>>   }
>>>
>>> }
>>>
>>>
>>> # assume that the current directory is "bin" dir of
>>>
>>> # jextract tool. It has a javac executable in it.
>>>
>>> # We use jextract's javac but pass module-path for the
>>>
>>> # other jdk modules not included in jextract jdk image.
>>>
>>>
>>> $ ./javac --module-path
>>> /Library/Java/JavaVirtualMachines/jdk-19.jdk/Contents/Home/jmods
>>> --add-modules java.desktop --enable-preview --source 19  Main.java
>>>
>>>
>>> If you're okay with building jextract from the sources, then you use JDK
>>> 19's javac with the following option:
>>>
>>> --module-path $JEXTRACT_REPO/build/jmods
>>>
>>>
>>> [That directory $JEXTRACT_REPO/build/jmods contains
>>> org.openjdk.jextract.jmod module file]
>>>
>>>
>>> -Sundar
>>> ------------------------------
>>> *From:* jextract-dev <jextract-dev-retn at openjdk.org> on behalf of Nir
>>> Lisker <nlisker at gmail.com>
>>> *Sent:* 06 October 2022 07:51
>>> *To:* Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
>>> *Cc:* jextract-dev at openjdk.org <jextract-dev at openjdk.org>
>>> *Subject:* Re: GUI wrapper for jextract
>>>
>>> Yes, if I can interface with the tool directly it would be ideal.
>>>
>>> How can I add jextract as an external dependency for this? The jextract
>>> build is not a full jdk, and I'm running on jdk-19.
>>>
>>> On Tue, Oct 4, 2022 at 12:19 PM Maurizio Cimadamore <
>>> maurizio.cimadamore at oracle.com> wrote:
>>>
>>> Hi Nir,
>>> On 02/10/2022 22:31, Nir Lisker wrote:
>>>
>>> 5. When analyzing the symbols of a header using the dump option, I need
>>> to read the file that jextract creates from disk and then delete it. Is
>>> there a way to read the jextract output directly? Either through the output
>>> stream, or writing to a file in memory? Dealing with disk I/O is
>>> cumbersome, comes with permission restrictions, and might be slow if done
>>> for many files in a batch.
>>>
>>> I think ultimately, working with files might be not ideal for your use
>>> case.
>>>
>>> There is a pseudo-stable API to parse jextract files, in the
>>> JextractTool class (in the org.openjdk.jextract package, which should be
>>> exported by the jextract module):
>>>
>>> `public static Declaration.Scoped parse(List<Path> headers, String...
>>> parserOptions) {`
>>>
>>> We do not make any promise (at this stage at least) on the stability of
>>> the API. That said, it has not changed much (at all?) in the last couple of
>>> years.
>>>
>>> What you get back is a "Declaration", which is used to model vars,
>>> structs, unions, typedefs, functions
>>>
>>> Then, attached to declarations, there are "Type"s, which are used...
>>> well, to model types. Since some type can be structured (e.g. a struct
>>> type), they can point back to their declaration (e.g. Type.Declared).
>>>
>>> Jextract does all it does by defining visitors on this basic declaration
>>> tree, which is obtained by wrapping the results of parsing a C header using
>>> the clang API (e.g. clang Cursors).
>>>
>>> We did this to "sanitize" the output of clang, as well as to make our
>>> implementation more robust and less dependent from clang internals.
>>>
>>> One option for you would be to invoke the parsing process this way, then
>>> get the tree and look at the results (e.g. with a visitor), which sounds
>>> better than parsing an option file.
>>>
>>>
>>> Cheers
>>> Maurizio
>>>
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20221009/c3c43413/attachment-0001.htm>

From jvernee at openjdk.org  Sun Oct  9 14:17:59 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Sun, 9 Oct 2022 14:17:59 GMT
Subject: RFR: Add section on pre-built binaries to README [v2]
In-Reply-To: <H4u2zuaq-mvh_nkQwcj2pBE7ju1Q1sI55b4Ce31VGgI=.a41b5fbf-187e-4171-878e-93a34045db92@github.com>
References: <H4u2zuaq-mvh_nkQwcj2pBE7ju1Q1sI55b4Ce31VGgI=.a41b5fbf-187e-4171-878e-93a34045db92@github.com>
Message-ID: <ZeYbPSHSJyVxBUXA0h6bqaCrHNwX-18m4hP6aWhU7lk=.5094acec-7c7c-4e83-90bc-a689f70382c1@github.com>

> I've added a short section on where to find the pre-built binaries. I think building jextract is less important than the information on usage if people can get binaries, so I've moved the section on building and testing to the bottom.

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/84/files
  - new: https://git.openjdk.org/jextract/pull/84/files/4a8f808f..1ba7f75e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=84&range=01
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=84&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jextract/pull/84.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/84/head:pull/84

PR: https://git.openjdk.org/jextract/pull/84

From weijun at openjdk.org  Mon Oct 10 04:30:17 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 10 Oct 2022 04:30:17 GMT
Subject: Integrated: remove blanks in output like "int x ( int y)"
In-Reply-To: <9LXCTThmHPHt0S-G6j1qI9r1mu_GSCRCgnwkt0nxy_c=.696797d7-021d-4f3a-89a9-c6ff27fe2358@github.com>
References: <9LXCTThmHPHt0S-G6j1qI9r1mu_GSCRCgnwkt0nxy_c=.696797d7-021d-4f3a-89a9-c6ff27fe2358@github.com>
Message-ID: <lUmWXdJCyqLkm_FfqO3SCNJb3tNBQOz7fulHR87sVgE=.c6e4fcc1-5c7f-450e-a311-b5d416bebdfc@github.com>

On Thu, 6 Oct 2022 17:59:21 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Unless the spaces around "(" is a special style, this patch can clean (at least some of) them up.

This pull request has now been integrated.

Changeset: 29f4187a
Author:    Weijun Wang <weijun at openjdk.org>
Committer: Athijegannathan Sundararajan <sundar at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/29f4187a5e25c007dace5bbac52a1e86e9ac0106
Stats:     3 lines in 2 files changed: 0 ins; 0 del; 3 mod

remove blanks in output like "int x ( int y)"

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jextract/pull/82

From jvernee at openjdk.org  Tue Oct 11 15:01:34 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 11 Oct 2022 15:01:34 GMT
Subject: Integrated: Add section on pre-built binaries to README
In-Reply-To: <H4u2zuaq-mvh_nkQwcj2pBE7ju1Q1sI55b4Ce31VGgI=.a41b5fbf-187e-4171-878e-93a34045db92@github.com>
References: <H4u2zuaq-mvh_nkQwcj2pBE7ju1Q1sI55b4Ce31VGgI=.a41b5fbf-187e-4171-878e-93a34045db92@github.com>
Message-ID: <qjiYAj1dV_QQyme7W87Ygmem3OqWktDHo22cLZBWrlk=.e9fd5925-6039-4508-a767-53db899a3296@github.com>

On Fri, 7 Oct 2022 11:43:36 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> I've added a short section on where to find the pre-built binaries. I think building jextract is less important than the information on usage if people can get binaries, so I've moved the section on building and testing to the bottom.

This pull request has now been integrated.

Changeset: f70e8d2d
Author:    Jorn Vernee <jvernee at openjdk.org>
Committer: Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/f70e8d2dc7a7d49068c82b5039bb88fd76860dbe
Stats:     109 lines in 1 file changed: 58 ins; 47 del; 4 mod

Add section on pre-built binaries to README

Reviewed-by: sundar

-------------

PR: https://git.openjdk.org/jextract/pull/84

From sundar at openjdk.org  Wed Oct 12 11:44:53 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Wed, 12 Oct 2022 11:44:53 GMT
Subject: RFR: 7903257: jextract should generate javadoc comments
Message-ID: <WHrRF3lFFeX8f5GmQJhvL-AFQST4Oo9xCGun4bTR7bo=.54afda5f-c5e4-4b45-bf67-fe563f840628@github.com>

Generating C signature as doc comments.

-------------

Commit messages:
 - 7903257: jextract should generate javadoc comments

Changes: https://git.openjdk.org/jextract/pull/85/files
 Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=85&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903257
  Stats: 582 lines in 16 files changed: 560 ins; 3 del; 19 mod
  Patch: https://git.openjdk.org/jextract/pull/85.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/85/head:pull/85

PR: https://git.openjdk.org/jextract/pull/85

From sundar at openjdk.org  Wed Oct 12 11:58:33 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Wed, 12 Oct 2022 11:58:33 GMT
Subject: RFR: 7903257: jextract should generate javadoc comments [v2]
In-Reply-To: <WHrRF3lFFeX8f5GmQJhvL-AFQST4Oo9xCGun4bTR7bo=.54afda5f-c5e4-4b45-bf67-fe563f840628@github.com>
References: <WHrRF3lFFeX8f5GmQJhvL-AFQST4Oo9xCGun4bTR7bo=.54afda5f-c5e4-4b45-bf67-fe563f840628@github.com>
Message-ID: <In2zkJ2-r5yrCjkmxahwRD5W4v7qFcBRxpl3xTpHBu4=.afab693a-7c92-464d-b1af-b500fd008e51@github.com>

> Generating C signature as doc comments.

Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:

  fixed comment generation COMPLEX type. using correct libffmpeg version.

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/85/files
  - new: https://git.openjdk.org/jextract/pull/85/files/fc574555..deb57bf1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=85&range=01
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=85&range=00-01

  Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jextract/pull/85.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/85/head:pull/85

PR: https://git.openjdk.org/jextract/pull/85

From duke at openjdk.org  Wed Oct 12 12:04:29 2022
From: duke at openjdk.org (Per Minborg)
Date: Wed, 12 Oct 2022 12:04:29 GMT
Subject: RFR: 7903257: jextract should generate javadoc comments [v2]
In-Reply-To: <In2zkJ2-r5yrCjkmxahwRD5W4v7qFcBRxpl3xTpHBu4=.afab693a-7c92-464d-b1af-b500fd008e51@github.com>
References: <WHrRF3lFFeX8f5GmQJhvL-AFQST4Oo9xCGun4bTR7bo=.54afda5f-c5e4-4b45-bf67-fe563f840628@github.com>
 <In2zkJ2-r5yrCjkmxahwRD5W4v7qFcBRxpl3xTpHBu4=.afab693a-7c92-464d-b1af-b500fd008e51@github.com>
Message-ID: <QENd-tSNh9Pz4L0gra-bhsFSdDSVto7sozQ_h_T4EYo=.f8bcc29c-aae0-4535-88a8-b6a02da4f43c@github.com>

On Wed, 12 Oct 2022 11:58:33 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

>> Generating C signature as doc comments.
>
> Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed comment generation COMPLEX type. using correct libffmpeg version.

Marked as reviewed by minborg at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.org/jextract/pull/85

From sundar at openjdk.org  Wed Oct 12 12:12:11 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Wed, 12 Oct 2022 12:12:11 GMT
Subject: RFR: 7903257: jextract should generate javadoc comments [v3]
In-Reply-To: <WHrRF3lFFeX8f5GmQJhvL-AFQST4Oo9xCGun4bTR7bo=.54afda5f-c5e4-4b45-bf67-fe563f840628@github.com>
References: <WHrRF3lFFeX8f5GmQJhvL-AFQST4Oo9xCGun4bTR7bo=.54afda5f-c5e4-4b45-bf67-fe563f840628@github.com>
Message-ID: <bUwhbDOd089ZRMd6NQaMhu96rZIR0cUov57ehkeP10s=.10914f7a-76df-4d8c-a5af-7e24f1cec5d1@github.com>

> Generating C signature as doc comments.

Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:

  defensive code to avoid possible crashes in doc generation

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/85/files
  - new: https://git.openjdk.org/jextract/pull/85/files/deb57bf1..fab2ddb7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=85&range=02
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=85&range=01-02

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jextract/pull/85.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/85/head:pull/85

PR: https://git.openjdk.org/jextract/pull/85

From mcimadamore at openjdk.org  Wed Oct 12 12:21:35 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 12 Oct 2022 12:21:35 GMT
Subject: RFR: 7903257: jextract should generate javadoc comments [v3]
In-Reply-To: <bUwhbDOd089ZRMd6NQaMhu96rZIR0cUov57ehkeP10s=.10914f7a-76df-4d8c-a5af-7e24f1cec5d1@github.com>
References: <WHrRF3lFFeX8f5GmQJhvL-AFQST4Oo9xCGun4bTR7bo=.54afda5f-c5e4-4b45-bf67-fe563f840628@github.com>
 <bUwhbDOd089ZRMd6NQaMhu96rZIR0cUov57ehkeP10s=.10914f7a-76df-4d8c-a5af-7e24f1cec5d1@github.com>
Message-ID: <lsP1yEOYSOopSRUyfCnINJNOL8vXz2LLh6mwHUdS31s=.8bbddbfa-f3e8-4e47-9fdd-54117475d0f6@github.com>

On Wed, 12 Oct 2022 12:12:11 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

>> Generating C signature as doc comments.
>
> Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   defensive code to avoid possible crashes in doc generation

src/main/java/org/openjdk/jextract/impl/CDeclarationPrinter.java line 105:

> 103:         var ftype = d.type();
> 104:         var rtype = ftype.returnType();
> 105:         builder.append(nameAndType(rtype, ""));

I would rather add another helper function to just print a type, rather than reusing `nameAndType` here. Also, we should check that the type doesn't have a name attached.

src/main/java/org/openjdk/jextract/impl/CDeclarationPrinter.java line 149:

> 147:         indent();
> 148:         builder.append("typedef ");
> 149:         builder.append(nameAndType(d.type(), d.name()));

This use of `nameAndType` also leaves me a bit doubtful. There's var declarations, and there's just types + name. What's acceptable in both cases is different - e.g. `int a[3]` is not a valid type for a typedef. So, in cases where we just want a type, and the type should not have a name, we should have a way to say so in the code.

src/main/java/org/openjdk/jextract/impl/CDeclarationPrinter.java line 162:

> 160:     // in the result.
> 161: 
> 162:     private static String nameAndType(Type type, String name) {

Maybe we should call this "varDecl" since this is morally to be used for variable declarations.

src/main/java/org/openjdk/jextract/impl/CDeclarationPrinter.java line 231:

> 229:             }
> 230:             String res = t.returnType().accept(this, "").typeStr();
> 231:             return new TypeVisitorResult(true, res + " (" + context + ")" + argsStr);

Is there always a name attached to a function pointer? I'd say no (e.g. typedef).

src/main/java/org/openjdk/jextract/impl/CDeclarationPrinter.java line 244:

> 242:             String brackets = String.format(" %s[%s]", context,
> 243:                 t.elementCount().isPresent() ? t.elementCount().getAsLong() : "");
> 244:             return new TypeVisitorResult(true, t.elementType().accept(this, "").typeStr() + brackets);

Is there always a name attached to an array type? I would say no? (e.g. in a typedef)

-------------

PR: https://git.openjdk.org/jextract/pull/85

From mcimadamore at openjdk.org  Wed Oct 12 12:21:35 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 12 Oct 2022 12:21:35 GMT
Subject: RFR: 7903257: jextract should generate javadoc comments [v3]
In-Reply-To: <lsP1yEOYSOopSRUyfCnINJNOL8vXz2LLh6mwHUdS31s=.8bbddbfa-f3e8-4e47-9fdd-54117475d0f6@github.com>
References: <WHrRF3lFFeX8f5GmQJhvL-AFQST4Oo9xCGun4bTR7bo=.54afda5f-c5e4-4b45-bf67-fe563f840628@github.com>
 <bUwhbDOd089ZRMd6NQaMhu96rZIR0cUov57ehkeP10s=.10914f7a-76df-4d8c-a5af-7e24f1cec5d1@github.com>
 <lsP1yEOYSOopSRUyfCnINJNOL8vXz2LLh6mwHUdS31s=.8bbddbfa-f3e8-4e47-9fdd-54117475d0f6@github.com>
Message-ID: <IZ1S785ojWfnInPLbPTk3jgMQ6zVKD7RgoQTgoeiSwo=.d8169c20-226b-4a50-ba53-2c27bd558c5c@github.com>

On Wed, 12 Oct 2022 12:12:16 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   defensive code to avoid possible crashes in doc generation
>
> src/main/java/org/openjdk/jextract/impl/CDeclarationPrinter.java line 162:
> 
>> 160:     // in the result.
>> 161: 
>> 162:     private static String nameAndType(Type type, String name) {
> 
> Maybe we should call this "varDecl" since this is morally to be used for variable declarations.

It's also not super clear to me what happens when the type has a name, and the user also specified a name. Can that ever happen? Or, if this happens, both names should be the same (in which case we should assert that).

-------------

PR: https://git.openjdk.org/jextract/pull/85

From sundar at openjdk.org  Wed Oct 12 12:38:21 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Wed, 12 Oct 2022 12:38:21 GMT
Subject: RFR: 7903257: jextract should generate javadoc comments [v3]
In-Reply-To: <lsP1yEOYSOopSRUyfCnINJNOL8vXz2LLh6mwHUdS31s=.8bbddbfa-f3e8-4e47-9fdd-54117475d0f6@github.com>
References: <WHrRF3lFFeX8f5GmQJhvL-AFQST4Oo9xCGun4bTR7bo=.54afda5f-c5e4-4b45-bf67-fe563f840628@github.com>
 <bUwhbDOd089ZRMd6NQaMhu96rZIR0cUov57ehkeP10s=.10914f7a-76df-4d8c-a5af-7e24f1cec5d1@github.com>
 <lsP1yEOYSOopSRUyfCnINJNOL8vXz2LLh6mwHUdS31s=.8bbddbfa-f3e8-4e47-9fdd-54117475d0f6@github.com>
Message-ID: <IcDE2UaoiapXRyZodFyrxf8nxMpXUcwAV_Aaxdsxa0g=.3aaeb792-6810-4c88-899c-3d61d715e15f@github.com>

On Wed, 12 Oct 2022 12:16:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   defensive code to avoid possible crashes in doc generation
>
> src/main/java/org/openjdk/jextract/impl/CDeclarationPrinter.java line 149:
> 
>> 147:         indent();
>> 148:         builder.append("typedef ");
>> 149:         builder.append(nameAndType(d.type(), d.name()));
> 
> This use of `nameAndType` also leaves me a bit doubtful. There's var declarations, and there's just types + name. What's acceptable in both cases is different - e.g. `int a[3]` is not a valid type for a typedef. So, in cases where we just want a type, and the type should not have a name, we should have a way to say so in the code.

Example:

typedef int (*handler)(int x);

The type signature has buried name here ("handler")

> src/main/java/org/openjdk/jextract/impl/CDeclarationPrinter.java line 231:
> 
>> 229:             }
>> 230:             String res = t.returnType().accept(this, "").typeStr();
>> 231:             return new TypeVisitorResult(true, res + " (" + context + ")" + argsStr);
> 
> Is there always a name attached to a function pointer? I'd say no (e.g. typedef).

You're asking about parameter names? That's not present always. Hence the conditional code above.

> src/main/java/org/openjdk/jextract/impl/CDeclarationPrinter.java line 244:
> 
>> 242:             String brackets = String.format(" %s[%s]", context,
>> 243:                 t.elementCount().isPresent() ? t.elementCount().getAsLong() : "");
>> 244:             return new TypeVisitorResult(true, t.elementType().accept(this, "").typeStr() + brackets);
> 
> Is there always a name attached to an array type? I would say no? (e.g. in a typedef)

context is either empty string or has a name.

-------------

PR: https://git.openjdk.org/jextract/pull/85

From sundar at openjdk.org  Wed Oct 12 14:34:30 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Wed, 12 Oct 2022 14:34:30 GMT
Subject: RFR: 7903257: jextract should generate javadoc comments [v4]
In-Reply-To: <WHrRF3lFFeX8f5GmQJhvL-AFQST4Oo9xCGun4bTR7bo=.54afda5f-c5e4-4b45-bf67-fe563f840628@github.com>
References: <WHrRF3lFFeX8f5GmQJhvL-AFQST4Oo9xCGun4bTR7bo=.54afda5f-c5e4-4b45-bf67-fe563f840628@github.com>
Message-ID: <jcILz7bFOMerG6fAo7fSLyuJ6Rg7MCDi9lxyc-99ZqM=.d3bbabb5-d123-4cd2-aa78-34f1e70ea8ce@github.com>

> Generating C signature as doc comments.

Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:

  differentiating macros and enum constants. code cleanup in CDeclarationPrinter as suggested in review.

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/85/files
  - new: https://git.openjdk.org/jextract/pull/85/files/fab2ddb7..00f43b4c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=85&range=03
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=85&range=02-03

  Stats: 47 lines in 3 files changed: 30 ins; 1 del; 16 mod
  Patch: https://git.openjdk.org/jextract/pull/85.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/85/head:pull/85

PR: https://git.openjdk.org/jextract/pull/85

From sundar at openjdk.org  Wed Oct 12 14:43:28 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Wed, 12 Oct 2022 14:43:28 GMT
Subject: RFR: 7903257: jextract should generate javadoc comments [v5]
In-Reply-To: <WHrRF3lFFeX8f5GmQJhvL-AFQST4Oo9xCGun4bTR7bo=.54afda5f-c5e4-4b45-bf67-fe563f840628@github.com>
References: <WHrRF3lFFeX8f5GmQJhvL-AFQST4Oo9xCGun4bTR7bo=.54afda5f-c5e4-4b45-bf67-fe563f840628@github.com>
Message-ID: <bAeDkiAQgudx4x_aFv5GrbZa-8enuQmiZS6_Ppp90H0=.c001f550-0e80-4608-93ba-c4e20d8578dc@github.com>

> Generating C signature as doc comments.

Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:

  changed TestDocComments test to use ordered doc commentes (List instead of Set)

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/85/files
  - new: https://git.openjdk.org/jextract/pull/85/files/00f43b4c..74a7e32a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=85&range=04
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=85&range=03-04

  Stats: 15 lines in 1 file changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jextract/pull/85.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/85/head:pull/85

PR: https://git.openjdk.org/jextract/pull/85

From sundar at openjdk.org  Wed Oct 12 17:21:27 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Wed, 12 Oct 2022 17:21:27 GMT
Subject: RFR: 7903257: jextract should generate javadoc comments [v6]
In-Reply-To: <WHrRF3lFFeX8f5GmQJhvL-AFQST4Oo9xCGun4bTR7bo=.54afda5f-c5e4-4b45-bf67-fe563f840628@github.com>
References: <WHrRF3lFFeX8f5GmQJhvL-AFQST4Oo9xCGun4bTR7bo=.54afda5f-c5e4-4b45-bf67-fe563f840628@github.com>
Message-ID: <cqPy0xpIHE4RqIIuLhqasLjuLCgA3scVO00hrMrvwtM=.ac441988-d927-41f5-84f6-79ec0e794000@github.com>

> Generating C signature as doc comments.

Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:

  added {@snippet : } around code in javadoc comment.

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/85/files
  - new: https://git.openjdk.org/jextract/pull/85/files/74a7e32a..3af5a8cc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=85&range=05
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=85&range=04-05

  Stats: 13 lines in 2 files changed: 12 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jextract/pull/85.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/85/head:pull/85

PR: https://git.openjdk.org/jextract/pull/85

From mcimadamore at openjdk.org  Thu Oct 13 12:43:22 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 13 Oct 2022 12:43:22 GMT
Subject: RFR: 7903257: jextract should generate javadoc comments [v6]
In-Reply-To: <cqPy0xpIHE4RqIIuLhqasLjuLCgA3scVO00hrMrvwtM=.ac441988-d927-41f5-84f6-79ec0e794000@github.com>
References: <WHrRF3lFFeX8f5GmQJhvL-AFQST4Oo9xCGun4bTR7bo=.54afda5f-c5e4-4b45-bf67-fe563f840628@github.com>
 <cqPy0xpIHE4RqIIuLhqasLjuLCgA3scVO00hrMrvwtM=.ac441988-d927-41f5-84f6-79ec0e794000@github.com>
Message-ID: <f_pByKHQykF5UVMIJ0o0fHowoO3_CprgL1_nX7IF7b8=.2de7ebf9-5fb0-459b-a943-94925f0122ce@github.com>

On Wed, 12 Oct 2022 17:21:27 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

>> Generating C signature as doc comments.
>
> Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added {@snippet : } around code in javadoc comment.

Looks good

src/main/java/org/openjdk/jextract/impl/StructBuilder.java line 56:

> 54:     private final Deque<String> prefixElementNames;
> 55: 
> 56:     StructBuilder(JavaSourceBuilder enclosing, Declaration.Scoped structTree,

Should this class override `addVar` so that doc comments for getters and setters are also generated (like in the case of global vars) ?

-------------

Marked as reviewed by mcimadamore (Committer).

PR: https://git.openjdk.org/jextract/pull/85

From sundar at openjdk.org  Thu Oct 13 12:47:26 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Thu, 13 Oct 2022 12:47:26 GMT
Subject: RFR: 7903257: jextract should generate javadoc comments [v6]
In-Reply-To: <f_pByKHQykF5UVMIJ0o0fHowoO3_CprgL1_nX7IF7b8=.2de7ebf9-5fb0-459b-a943-94925f0122ce@github.com>
References: <WHrRF3lFFeX8f5GmQJhvL-AFQST4Oo9xCGun4bTR7bo=.54afda5f-c5e4-4b45-bf67-fe563f840628@github.com>
 <cqPy0xpIHE4RqIIuLhqasLjuLCgA3scVO00hrMrvwtM=.ac441988-d927-41f5-84f6-79ec0e794000@github.com>
 <f_pByKHQykF5UVMIJ0o0fHowoO3_CprgL1_nX7IF7b8=.2de7ebf9-5fb0-459b-a943-94925f0122ce@github.com>
Message-ID: <Zqf-Eyjz9J2z94_guw2M0fFVWvmB23lPE5ayA5yw5tU=.7d82660b-4691-457b-a10b-d404fb37c6bd@github.com>

On Thu, 13 Oct 2022 12:39:36 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added {@snippet : } around code in javadoc comment.
>
> src/main/java/org/openjdk/jextract/impl/StructBuilder.java line 56:
> 
>> 54:     private final Deque<String> prefixElementNames;
>> 55: 
>> 56:     StructBuilder(JavaSourceBuilder enclosing, Declaration.Scoped structTree,
> 
> Should this class override `addVar` so that doc comments for getters and setters are also generated (like in the case of global vars) ?

will check out.

-------------

PR: https://git.openjdk.org/jextract/pull/85

From sundar at openjdk.org  Thu Oct 13 13:24:29 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Thu, 13 Oct 2022 13:24:29 GMT
Subject: RFR: 7903257: jextract should generate javadoc comments [v7]
In-Reply-To: <WHrRF3lFFeX8f5GmQJhvL-AFQST4Oo9xCGun4bTR7bo=.54afda5f-c5e4-4b45-bf67-fe563f840628@github.com>
References: <WHrRF3lFFeX8f5GmQJhvL-AFQST4Oo9xCGun4bTR7bo=.54afda5f-c5e4-4b45-bf67-fe563f840628@github.com>
Message-ID: <qqyF2V-295o-gc4kZZdSWS8nl5-PT0zM7UCsEHP-gmQ=.2279e9be-42ba-4786-b7a6-b6d02d8f7344@github.com>

> Generating C signature as doc comments.

Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:

  doc comment for struct field getter and setter methods (review comment)

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/85/files
  - new: https://git.openjdk.org/jextract/pull/85/files/3af5a8cc..3e312308

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=85&range=06
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=85&range=05-06

  Stats: 20 lines in 2 files changed: 18 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jextract/pull/85.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/85/head:pull/85

PR: https://git.openjdk.org/jextract/pull/85

From mcimadamore at openjdk.org  Thu Oct 13 13:24:29 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 13 Oct 2022 13:24:29 GMT
Subject: RFR: 7903257: jextract should generate javadoc comments [v7]
In-Reply-To: <qqyF2V-295o-gc4kZZdSWS8nl5-PT0zM7UCsEHP-gmQ=.2279e9be-42ba-4786-b7a6-b6d02d8f7344@github.com>
References: <WHrRF3lFFeX8f5GmQJhvL-AFQST4Oo9xCGun4bTR7bo=.54afda5f-c5e4-4b45-bf67-fe563f840628@github.com>
 <qqyF2V-295o-gc4kZZdSWS8nl5-PT0zM7UCsEHP-gmQ=.2279e9be-42ba-4786-b7a6-b6d02d8f7344@github.com>
Message-ID: <gsRktoFNyp_S_BMDP6jMcHKlx8KKV5hQmhyY60jMBKQ=.e2d97ba4-2cca-49c6-b304-76230664a154@github.com>

On Thu, 13 Oct 2022 13:20:44 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

>> Generating C signature as doc comments.
>
> Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   doc comment for struct field getter and setter methods (review comment)

Marked as reviewed by mcimadamore (Committer).

-------------

PR: https://git.openjdk.org/jextract/pull/85

From jvernee at openjdk.org  Thu Oct 13 13:24:30 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 13 Oct 2022 13:24:30 GMT
Subject: RFR: 7903257: jextract should generate javadoc comments [v6]
In-Reply-To: <cqPy0xpIHE4RqIIuLhqasLjuLCgA3scVO00hrMrvwtM=.ac441988-d927-41f5-84f6-79ec0e794000@github.com>
References: <WHrRF3lFFeX8f5GmQJhvL-AFQST4Oo9xCGun4bTR7bo=.54afda5f-c5e4-4b45-bf67-fe563f840628@github.com>
 <cqPy0xpIHE4RqIIuLhqasLjuLCgA3scVO00hrMrvwtM=.ac441988-d927-41f5-84f6-79ec0e794000@github.com>
Message-ID: <857D50XwGfbRW-jaug3SUpozC33pqW7gOPijxEWoyoo=.a2a52416-805a-440c-b4bd-625d6b5f8ced@github.com>

On Wed, 12 Oct 2022 17:21:27 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

>> Generating C signature as doc comments.
>
> Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added {@snippet : } around code in javadoc comment.

Marked as reviewed by jvernee (no project role).

src/main/java/org/openjdk/jextract/impl/CDeclarationPrinter.java line 224:

> 222:                     // defensive. If no name is present, we don't want to crash
> 223:                     return new TypeVisitorResult(false,
> 224:                         t.name().isPresent()? t.name().get() : t.toString());

Suggestion:

                    return new TypeVisitorResult(false, t.name().orElse(t.toString()));

src/main/java/org/openjdk/jextract/impl/CDeclarationPrinter.java line 268:

> 266:         @Override
> 267:         public TypeVisitorResult visitType(Type t, String context) {
> 268:             return new TypeVisitorResult(false, t.getClass().getName());

Above in visitDelegated the default name seems to be `t.toString`. Maybe these could be factored out in some `defaultNameFor(Type type)` helper method for clarity.

-------------

PR: https://git.openjdk.org/jextract/pull/85

From sundar at openjdk.org  Thu Oct 13 13:28:29 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Thu, 13 Oct 2022 13:28:29 GMT
Subject: RFR: 7903257: jextract should generate javadoc comments [v6]
In-Reply-To: <857D50XwGfbRW-jaug3SUpozC33pqW7gOPijxEWoyoo=.a2a52416-805a-440c-b4bd-625d6b5f8ced@github.com>
References: <WHrRF3lFFeX8f5GmQJhvL-AFQST4Oo9xCGun4bTR7bo=.54afda5f-c5e4-4b45-bf67-fe563f840628@github.com>
 <cqPy0xpIHE4RqIIuLhqasLjuLCgA3scVO00hrMrvwtM=.ac441988-d927-41f5-84f6-79ec0e794000@github.com>
 <857D50XwGfbRW-jaug3SUpozC33pqW7gOPijxEWoyoo=.a2a52416-805a-440c-b4bd-625d6b5f8ced@github.com>
Message-ID: <vlxihzg5CgB6lFOBffadtaODaTSfJY8NLhAcD88T6Wk=.94c35b07-e192-4ad2-adde-617fe0b48f0f@github.com>

On Thu, 13 Oct 2022 12:56:38 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added {@snippet : } around code in javadoc comment.
>
> src/main/java/org/openjdk/jextract/impl/CDeclarationPrinter.java line 224:
> 
>> 222:                     // defensive. If no name is present, we don't want to crash
>> 223:                     return new TypeVisitorResult(false,
>> 224:                         t.name().isPresent()? t.name().get() : t.toString());
> 
> Suggestion:
> 
>                     return new TypeVisitorResult(false, t.name().orElse(t.toString()));

oops. missed your comments. Will piggyback in a later change.

-------------

PR: https://git.openjdk.org/jextract/pull/85

From sundar at openjdk.org  Thu Oct 13 13:28:30 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Thu, 13 Oct 2022 13:28:30 GMT
Subject: Integrated: 7903257: jextract should generate javadoc comments
In-Reply-To: <WHrRF3lFFeX8f5GmQJhvL-AFQST4Oo9xCGun4bTR7bo=.54afda5f-c5e4-4b45-bf67-fe563f840628@github.com>
References: <WHrRF3lFFeX8f5GmQJhvL-AFQST4Oo9xCGun4bTR7bo=.54afda5f-c5e4-4b45-bf67-fe563f840628@github.com>
Message-ID: <k3tmsFtKgPPXWNgSKQfmdDQEJmejoUnOugk7J9qFEFA=.7274ffaf-a6b5-4918-93f3-84fd2eebadfe@github.com>

On Wed, 12 Oct 2022 11:37:03 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> Generating C signature as doc comments.

This pull request has now been integrated.

Changeset: 2015ecba
Author:    Athijegannathan Sundararajan <sundar at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/2015ecbad4e67a665d39282c0415905eaabab756
Stats:     647 lines in 18 files changed: 623 ins; 3 del; 21 mod

7903257: jextract should generate javadoc comments

Reviewed-by: mcimadamore, jvernee

-------------

PR: https://git.openjdk.org/jextract/pull/85

From sundar at openjdk.org  Thu Oct 13 14:16:09 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Thu, 13 Oct 2022 14:16:09 GMT
Subject: Integrated: 7903349: int parameter in generated allocateArray method
 should be long
Message-ID: <rgSTX8uEY2wTuawKqFcbiIVudYgua8J1olbvumu9g1o=.5cd01d0f-123a-4808-9b33-757d99ef5c96@github.com>

Changing "int" param to "long" in generated allocateArray method for struct classes.

Piggybacking couple of code review suggestions missed during review for CODETOOLS-7903257

-------------

Commit messages:
 - 7903349: int parameter in generated allocateArray method should be long

Changes: https://git.openjdk.org/jextract/pull/86/files
 Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=86&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903349
  Stats: 8 lines in 2 files changed: 4 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jextract/pull/86.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/86/head:pull/86

PR: https://git.openjdk.org/jextract/pull/86

From jvernee at openjdk.org  Thu Oct 13 14:16:10 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 13 Oct 2022 14:16:10 GMT
Subject: Integrated: 7903349: int parameter in generated allocateArray
 method should be long
In-Reply-To: <rgSTX8uEY2wTuawKqFcbiIVudYgua8J1olbvumu9g1o=.5cd01d0f-123a-4808-9b33-757d99ef5c96@github.com>
References: <rgSTX8uEY2wTuawKqFcbiIVudYgua8J1olbvumu9g1o=.5cd01d0f-123a-4808-9b33-757d99ef5c96@github.com>
Message-ID: <d3OkC62kdMXh6hL0mo2eVYqR09SxevroLSQT0yyYrHs=.3b540e8d-52cb-4c28-930f-7d15af1b1d54@github.com>

On Thu, 13 Oct 2022 14:06:14 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> Changing "int" param to "long" in generated allocateArray method for struct classes.
> 
> Piggybacking couple of code review suggestions missed during review for CODETOOLS-7903257

Marked as reviewed by jvernee (no project role).

-------------

PR: https://git.openjdk.org/jextract/pull/86

From sundar at openjdk.org  Thu Oct 13 14:16:12 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Thu, 13 Oct 2022 14:16:12 GMT
Subject: Integrated: 7903349: int parameter in generated allocateArray method
 should be long
In-Reply-To: <rgSTX8uEY2wTuawKqFcbiIVudYgua8J1olbvumu9g1o=.5cd01d0f-123a-4808-9b33-757d99ef5c96@github.com>
References: <rgSTX8uEY2wTuawKqFcbiIVudYgua8J1olbvumu9g1o=.5cd01d0f-123a-4808-9b33-757d99ef5c96@github.com>
Message-ID: <BNiu9XfhKxROslXqejkYZ2O3xU-plBIfyTO-He4SmZU=.27707ec3-e071-4be7-b877-01df287b18f1@github.com>

On Thu, 13 Oct 2022 14:06:14 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> Changing "int" param to "long" in generated allocateArray method for struct classes.
> 
> Piggybacking couple of code review suggestions missed during review for CODETOOLS-7903257

This pull request has now been integrated.

Changeset: b3fcd44f
Author:    Athijegannathan Sundararajan <sundar at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/b3fcd44f52b8eef230e732241bf13ba5128ca4a8
Stats:     8 lines in 2 files changed: 4 ins; 1 del; 3 mod

7903349: int parameter in generated allocateArray method should be long

Reviewed-by: jvernee, mcimadamore

-------------

PR: https://git.openjdk.org/jextract/pull/86

From mcimadamore at openjdk.org  Thu Oct 13 14:16:11 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 13 Oct 2022 14:16:11 GMT
Subject: Integrated: 7903349: int parameter in generated allocateArray
 method should be long
In-Reply-To: <rgSTX8uEY2wTuawKqFcbiIVudYgua8J1olbvumu9g1o=.5cd01d0f-123a-4808-9b33-757d99ef5c96@github.com>
References: <rgSTX8uEY2wTuawKqFcbiIVudYgua8J1olbvumu9g1o=.5cd01d0f-123a-4808-9b33-757d99ef5c96@github.com>
Message-ID: <Yc3bdcLw6bfmfLbBI3bwwxWYP3hXmnFyAVz9YIaY9YE=.65c5aac1-25e0-4efe-9dc8-e13b9e5fa5e0@github.com>

On Thu, 13 Oct 2022 14:06:14 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> Changing "int" param to "long" in generated allocateArray method for struct classes.
> 
> Piggybacking couple of code review suggestions missed during review for CODETOOLS-7903257

Marked as reviewed by mcimadamore (Committer).

-------------

PR: https://git.openjdk.org/jextract/pull/86

From sundar at openjdk.org  Thu Oct 13 15:08:25 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Thu, 13 Oct 2022 15:08:25 GMT
Subject: RFR: Fix typo in README.md
In-Reply-To: <870tHg7tlUyA3h2GpLgOyXk0D3JyhKBkwDCot2goOBs=.9aa7d09c-0aef-443d-b25c-6c814c0f8ac1@github.com>
References: <870tHg7tlUyA3h2GpLgOyXk0D3JyhKBkwDCot2goOBs=.9aa7d09c-0aef-443d-b25c-6c814c0f8ac1@github.com>
Message-ID: <bDt2Fcn2BTNGY_T7Pf_YYjgbOsij-Q-en9qlY7l-Q-U=.fceb9f78-07f2-4dd5-8465-27525beb3b9a@github.com>

On Tue, 27 Sep 2022 07:25:24 GMT, Per Minborg <duke at openjdk.org> wrote:

> This PR removes a redundant `=` character.

LGTM

-------------

Marked as reviewed by sundar (Committer).

PR: https://git.openjdk.org/jextract/pull/78

From sundar at openjdk.org  Thu Oct 13 17:12:30 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Thu, 13 Oct 2022 17:12:30 GMT
Subject: RFR: 7903354: jextract generates redundant cast in ofAddress method
Message-ID: <uswgxfpLqR8Hvlvs6Zv1r7ZYWDvNV9DdNLk-jmPXtDE=.b6e48456-4fd1-456b-a2ea-53f218902537@github.com>

removed redundant cast

-------------

Commit messages:
 - 7903354: jextract generates redundant cast in ofAddress method

Changes: https://git.openjdk.org/jextract/pull/87/files
 Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=87&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903354
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jextract/pull/87.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/87/head:pull/87

PR: https://git.openjdk.org/jextract/pull/87

From duke at openjdk.org  Thu Oct 13 17:12:30 2022
From: duke at openjdk.org (Per Minborg)
Date: Thu, 13 Oct 2022 17:12:30 GMT
Subject: RFR: 7903354: jextract generates redundant cast in ofAddress
 method
In-Reply-To: <uswgxfpLqR8Hvlvs6Zv1r7ZYWDvNV9DdNLk-jmPXtDE=.b6e48456-4fd1-456b-a2ea-53f218902537@github.com>
References: <uswgxfpLqR8Hvlvs6Zv1r7ZYWDvNV9DdNLk-jmPXtDE=.b6e48456-4fd1-456b-a2ea-53f218902537@github.com>
Message-ID: <zo003HvdOHeSWQbXdfKDlcCI3Xh3AQ4PHb60Hy22Sk4=.45d1c113-e818-4e2c-9a43-af7916b6cb9c@github.com>

On Thu, 13 Oct 2022 14:47:59 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> removed redundant cast

Marked as reviewed by minborg at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.org/jextract/pull/87

From mcimadamore at openjdk.org  Thu Oct 13 17:12:30 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 13 Oct 2022 17:12:30 GMT
Subject: RFR: 7903354: jextract generates redundant cast in ofAddress
 method
In-Reply-To: <uswgxfpLqR8Hvlvs6Zv1r7ZYWDvNV9DdNLk-jmPXtDE=.b6e48456-4fd1-456b-a2ea-53f218902537@github.com>
References: <uswgxfpLqR8Hvlvs6Zv1r7ZYWDvNV9DdNLk-jmPXtDE=.b6e48456-4fd1-456b-a2ea-53f218902537@github.com>
Message-ID: <Yl4af3fNKGhChBVwoLi-9hvi50soyPLh2imYPYD3yPk=.1700db92-7a4b-4b51-a2c3-557b06d66e12@github.com>

On Thu, 13 Oct 2022 14:47:59 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> removed redundant cast

Marked as reviewed by mcimadamore (Committer).

-------------

PR: https://git.openjdk.org/jextract/pull/87

From sundar at openjdk.org  Thu Oct 13 17:19:52 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Thu, 13 Oct 2022 17:19:52 GMT
Subject: Integrated: 7903354: jextract generates redundant cast in ofAddress
 method
In-Reply-To: <uswgxfpLqR8Hvlvs6Zv1r7ZYWDvNV9DdNLk-jmPXtDE=.b6e48456-4fd1-456b-a2ea-53f218902537@github.com>
References: <uswgxfpLqR8Hvlvs6Zv1r7ZYWDvNV9DdNLk-jmPXtDE=.b6e48456-4fd1-456b-a2ea-53f218902537@github.com>
Message-ID: <FjsSWF_EEq3VGulxRz6J39_POmW6eYkbGJRSkojtuDM=.0a3355f0-3a6a-453a-ae6f-a11d3c150e66@github.com>

On Thu, 13 Oct 2022 14:47:59 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> removed redundant cast

This pull request has now been integrated.

Changeset: b8134b43
Author:    Athijegannathan Sundararajan <sundar at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/b8134b43d341244e63546433d08027ba553b7c59
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

7903354: jextract generates redundant cast in ofAddress method

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jextract/pull/87

From nlisker at gmail.com  Thu Oct 13 21:37:17 2022
From: nlisker at gmail.com (Nir Lisker)
Date: Fri, 14 Oct 2022 00:37:17 +0300
Subject: GUI wrapper for jextract
In-Reply-To: <CA+0ynh-NjJ_E7KM9g3gR2p_hHOvqr+nRKG1PpETM4JOxB1ZN7g@mail.gmail.com>
References: <CA+0ynh-QQrdhWCf650ZLivxkGs0sXiNYddiYQPW3hV0HTno56Q@mail.gmail.com>
 <7f91f9eb-32df-be44-ec53-8fb0b464206e@oracle.com>
 <CA+0ynh_gK_kz6YAM1ACewAnpobhitr_pzptUBmf0ECnPcq3V-w@mail.gmail.com>
 <DM6PR10MB295428BB4565677BC8B75630EA5C9@DM6PR10MB2954.namprd10.prod.outlook.com>
 <CA+0ynh8ArisSxxdo1ugTVq70KFU9eqbNUYBeCnAkTB63SqB6Nw@mail.gmail.com>
 <b651fc1c-3047-801e-5163-b077ff7bd8ce@oracle.com>
 <CA+0ynh8H24fyWXnzbc701GmMfz8+wQSzYfawW3Hi1HWhEqadDg@mail.gmail.com>
 <CA+0ynh-NjJ_E7KM9g3gR2p_hHOvqr+nRKG1PpETM4JOxB1ZN7g@mail.gmail.com>
Message-ID: <CA+0ynh-PgfzVe7EaM01Uf50EuYgfGDYCqsdGzBRTxO2i72JS9g@mail.gmail.com>

With some help, I managed to load Jextract as a dependency and interface
with it directly. When looking at the API, I found a small inconsistency:
The --include- options are function, macro, struct, union, typedef, and var.
The Declarations that match these seem to be Function, Constant,
Scoped.Kind.STRUCT, Scoped.Kind.UNION, Typedef and Variable.
Maybe the macro option and Constant Declaration should use the same
terminology. I would have thought that defining 'const' in the header file
will map to Constant, but it maps to Variable, and defining a macro with
`#define` is what maps to Constant.

- Nir

On Sun, Oct 9, 2022 at 11:55 AM Nir Lisker <nlisker at gmail.com> wrote:

> Another point that I missed is: when specifying a directory path for
> -include-dir, the docs don't say if the search is recursive (searches also
> within folders with the directory).
>
> On Sun, Oct 9, 2022 at 1:50 AM Nir Lisker <nlisker at gmail.com> wrote:
>
>> Hi Maurizio,
>>
>> Yes, this is much clearer! I didn't see the PR or I would have noted a
>> few points there. I'll do it here now:
>>
>> 1. For macro, the Option column is great, but the Meaning column is
>> cryptic: "define to (or 1 if omitted)", to what? 1 what?
>> 2. For --library, I would write in the Meaning column what file types are
>> accepted. I believe they are only .dll, .so, and .dylib. If this is obvious
>> then you can ignore this point.
>> 3. Since --include-dir in its Option column specifically specifies <dir>
>> (which is great!), I would think about being specific like that in the
>> other options too. --library uses <path> that actually means <file>
>> (although you show this in the example under Meaning); --output uses <path>
>> that means <dir>, although this one is rather obvious because there's no
>> other option; --dump-includes specifies <String>, but is it just a name or
>> a can it be a whole path? (The example below shows how to use it with a
>> name.)
>>
>> On the interfacing side, I'm still stuck with the issue of dependencies.
>> While I can compile with jextract's javac and pointing to the jmods of the
>> JDK, I can't do it during runtime (execution of 'java'). I'm still using a
>> Process with streams in the meantime.
>>
>> Thanks,
>> Nir
>>
>> On Sun, Oct 9, 2022 at 12:02 AM Maurizio Cimadamore <
>> maurizio.cimadamore at oracle.com> wrote:
>>
>>> Hi Nir,
>>> we have made some tweaks to the command line option description:
>>>
>>> https://github.com/openjdk/jextract/tree/panama
>>>
>>> Hopefully that should reflect some of the discussion in this thread.
>>>
>>> Thanks
>>> Maurizio
>>>
>>>
>>> On 06/10/2022 20:43, Nir Lisker wrote:
>>>
>>> I tried the workaround. Compilation is fine, but during runtime I get:
>>>
>>> Error occurred during initialization of boot layer
>>> java.lang.module.FindException: Module java.desktop not found
>>>
>>> What is the run command that adds all the jdk modules?
>>>
>>> On Thu, Oct 6, 2022 at 8:35 AM Sundararajan Athijegannathan <
>>> sundararajan.athijegannathan at oracle.com> wrote:
>>>
>>>> Binary download of jextract does not include org.openjdk.jextract.jmod
>>>> file (although that is part of jextract build folder).
>>>>
>>>> For now, you can workaround using the following:
>>>>
>>>>
>>>> $ cat Main.java
>>>>
>>>> import org.openjdk.jextract.*;
>>>>
>>>> import java.awt.*;
>>>>
>>>>
>>>> class Main {
>>>>
>>>>   public static void main(String[] a) {
>>>>
>>>>     System.out.println(Frame.class);
>>>>
>>>>     System.out.println(JextractTool.class);
>>>>
>>>>   }
>>>>
>>>> }
>>>>
>>>>
>>>> # assume that the current directory is "bin" dir of
>>>>
>>>> # jextract tool. It has a javac executable in it.
>>>>
>>>> # We use jextract's javac but pass module-path for the
>>>>
>>>> # other jdk modules not included in jextract jdk image.
>>>>
>>>>
>>>> $ ./javac --module-path
>>>> /Library/Java/JavaVirtualMachines/jdk-19.jdk/Contents/Home/jmods
>>>> --add-modules java.desktop --enable-preview --source 19  Main.java
>>>>
>>>>
>>>> If you're okay with building jextract from the sources, then you use
>>>> JDK 19's javac with the following option:
>>>>
>>>> --module-path $JEXTRACT_REPO/build/jmods
>>>>
>>>>
>>>> [That directory $JEXTRACT_REPO/build/jmods contains
>>>> org.openjdk.jextract.jmod module file]
>>>>
>>>>
>>>> -Sundar
>>>> ------------------------------
>>>> *From:* jextract-dev <jextract-dev-retn at openjdk.org> on behalf of Nir
>>>> Lisker <nlisker at gmail.com>
>>>> *Sent:* 06 October 2022 07:51
>>>> *To:* Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
>>>> *Cc:* jextract-dev at openjdk.org <jextract-dev at openjdk.org>
>>>> *Subject:* Re: GUI wrapper for jextract
>>>>
>>>> Yes, if I can interface with the tool directly it would be ideal.
>>>>
>>>> How can I add jextract as an external dependency for this? The jextract
>>>> build is not a full jdk, and I'm running on jdk-19.
>>>>
>>>> On Tue, Oct 4, 2022 at 12:19 PM Maurizio Cimadamore <
>>>> maurizio.cimadamore at oracle.com> wrote:
>>>>
>>>> Hi Nir,
>>>> On 02/10/2022 22:31, Nir Lisker wrote:
>>>>
>>>> 5. When analyzing the symbols of a header using the dump option, I need
>>>> to read the file that jextract creates from disk and then delete it. Is
>>>> there a way to read the jextract output directly? Either through the output
>>>> stream, or writing to a file in memory? Dealing with disk I/O is
>>>> cumbersome, comes with permission restrictions, and might be slow if done
>>>> for many files in a batch.
>>>>
>>>> I think ultimately, working with files might be not ideal for your use
>>>> case.
>>>>
>>>> There is a pseudo-stable API to parse jextract files, in the
>>>> JextractTool class (in the org.openjdk.jextract package, which should be
>>>> exported by the jextract module):
>>>>
>>>> `public static Declaration.Scoped parse(List<Path> headers, String...
>>>> parserOptions) {`
>>>>
>>>> We do not make any promise (at this stage at least) on the stability of
>>>> the API. That said, it has not changed much (at all?) in the last couple of
>>>> years.
>>>>
>>>> What you get back is a "Declaration", which is used to model vars,
>>>> structs, unions, typedefs, functions
>>>>
>>>> Then, attached to declarations, there are "Type"s, which are used...
>>>> well, to model types. Since some type can be structured (e.g. a struct
>>>> type), they can point back to their declaration (e.g. Type.Declared).
>>>>
>>>> Jextract does all it does by defining visitors on this basic
>>>> declaration tree, which is obtained by wrapping the results of parsing a C
>>>> header using the clang API (e.g. clang Cursors).
>>>>
>>>> We did this to "sanitize" the output of clang, as well as to make our
>>>> implementation more robust and less dependent from clang internals.
>>>>
>>>> One option for you would be to invoke the parsing process this way,
>>>> then get the tree and look at the results (e.g. with a visitor), which
>>>> sounds better than parsing an option file.
>>>>
>>>>
>>>> Cheers
>>>> Maurizio
>>>>
>>>>
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20221014/a6113564/attachment-0001.htm>

From sundar at openjdk.org  Fri Oct 14 14:39:09 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Fri, 14 Oct 2022 14:39:09 GMT
Subject: RFR: 7903357: add a jextract sample that uses pcre2 library
Message-ID: <tYlHj_9f1k3dLuXW7aDX2dZkMY5QsDTdFhQKRJOCJVI=.77a44130-6b47-4625-a88f-0bfbffedc3dc@github.com>

Simple sample that checks a given string for matches against the given regex

-------------

Commit messages:
 - 7903357: add a jextract sample that uses pcre2 library

Changes: https://git.openjdk.org/jextract/pull/88/files
 Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=88&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903357
  Stats: 125 lines in 8 files changed: 119 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jextract/pull/88.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/88/head:pull/88

PR: https://git.openjdk.org/jextract/pull/88

From jvernee at openjdk.org  Fri Oct 14 16:21:16 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 14 Oct 2022 16:21:16 GMT
Subject: RFR: 7903357: add a jextract sample that uses pcre2 library
In-Reply-To: <tYlHj_9f1k3dLuXW7aDX2dZkMY5QsDTdFhQKRJOCJVI=.77a44130-6b47-4625-a88f-0bfbffedc3dc@github.com>
References: <tYlHj_9f1k3dLuXW7aDX2dZkMY5QsDTdFhQKRJOCJVI=.77a44130-6b47-4625-a88f-0bfbffedc3dc@github.com>
Message-ID: <KxCXOoCkYm5uaEGl9pNNdcIg4Y3KlaP_Vl_3zfpDjps=.bb2365de-513b-4d1e-8807-b0d0ffd497a8@github.com>

On Fri, 14 Oct 2022 14:32:57 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> Simple sample that checks a given string for matches against the given regex

Looks mostly good

samples/pcre2/Pcre.h line 32:

> 30:  */
> 31: 
> 32: #define PCRE2_CODE_UNIT_WIDTH 8

Couldn't this be done with `-DPCRE2_CODE_UNIT_WIDTH=8` as well?

samples/pcre2/PcreCheck.java line 63:

> 61:         System.err.printf("regex compilation failed: %s\n",
> 62:             buffer.getUtf8String(0));
> 63:         pcre2_code_free_8(re);

Does this free do anything? `re` seems to be `NULL` here.

-------------

Marked as reviewed by jvernee (no project role).

PR: https://git.openjdk.org/jextract/pull/88

From sundar at openjdk.org  Fri Oct 14 16:34:15 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Fri, 14 Oct 2022 16:34:15 GMT
Subject: RFR: 7903357: add a jextract sample that uses pcre2 library [v2]
In-Reply-To: <tYlHj_9f1k3dLuXW7aDX2dZkMY5QsDTdFhQKRJOCJVI=.77a44130-6b47-4625-a88f-0bfbffedc3dc@github.com>
References: <tYlHj_9f1k3dLuXW7aDX2dZkMY5QsDTdFhQKRJOCJVI=.77a44130-6b47-4625-a88f-0bfbffedc3dc@github.com>
Message-ID: <s3fGhG93zZ2EW98kDMe9GgB49kNwkMPg-eEA-PUCAys=.f5132a48-fa43-4330-8b81-42cd7d74cc09@github.com>

> Simple sample that checks a given string for matches against the given regex

Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:

  review comments

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/88/files
  - new: https://git.openjdk.org/jextract/pull/88/files/d41707c6..06b1185e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=88&range=01
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=88&range=00-01

  Stats: 39 lines in 4 files changed: 2 ins; 35 del; 2 mod
  Patch: https://git.openjdk.org/jextract/pull/88.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/88/head:pull/88

PR: https://git.openjdk.org/jextract/pull/88

From sundar at openjdk.org  Fri Oct 14 16:34:15 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Fri, 14 Oct 2022 16:34:15 GMT
Subject: RFR: 7903357: add a jextract sample that uses pcre2 library [v2]
In-Reply-To: <KxCXOoCkYm5uaEGl9pNNdcIg4Y3KlaP_Vl_3zfpDjps=.bb2365de-513b-4d1e-8807-b0d0ffd497a8@github.com>
References: <tYlHj_9f1k3dLuXW7aDX2dZkMY5QsDTdFhQKRJOCJVI=.77a44130-6b47-4625-a88f-0bfbffedc3dc@github.com>
 <KxCXOoCkYm5uaEGl9pNNdcIg4Y3KlaP_Vl_3zfpDjps=.bb2365de-513b-4d1e-8807-b0d0ffd497a8@github.com>
Message-ID: <iX6KiJQjpAjlxapkWm82nP4xTG0gNkFwMUwFtrMnsfA=.8adfdf20-8d92-49c1-9bd5-6af65df0e92d@github.com>

On Fri, 14 Oct 2022 16:12:04 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments
>
> samples/pcre2/Pcre.h line 32:
> 
>> 30:  */
>> 31: 
>> 32: #define PCRE2_CODE_UNIT_WIDTH 8
> 
> Couldn't this be done with `-DPCRE2_CODE_UNIT_WIDTH=8` as well?

yes, can be simplified. will do.

> samples/pcre2/PcreCheck.java line 63:
> 
>> 61:         System.err.printf("regex compilation failed: %s\n",
>> 62:             buffer.getUtf8String(0));
>> 63:         pcre2_code_free_8(re);
> 
> Does this free do anything? `re` seems to be `NULL` here.

will fix

-------------

PR: https://git.openjdk.org/jextract/pull/88

From sundar at openjdk.org  Fri Oct 14 16:50:12 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Fri, 14 Oct 2022 16:50:12 GMT
Subject: Integrated: 7903357: add a jextract sample that uses pcre2 library
In-Reply-To: <tYlHj_9f1k3dLuXW7aDX2dZkMY5QsDTdFhQKRJOCJVI=.77a44130-6b47-4625-a88f-0bfbffedc3dc@github.com>
References: <tYlHj_9f1k3dLuXW7aDX2dZkMY5QsDTdFhQKRJOCJVI=.77a44130-6b47-4625-a88f-0bfbffedc3dc@github.com>
Message-ID: <bN3OzJmJj9xZ7qfCBLmOnukT6WVTN9MS10ZW1_-U42w=.0ece05a4-f840-43e3-b5f1-9fd105eb1af8@github.com>

On Fri, 14 Oct 2022 14:32:57 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> Simple sample that checks a given string for matches against the given regex

This pull request has now been integrated.

Changeset: 1f86c109
Author:    Athijegannathan Sundararajan <sundar at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/1f86c10974b8361735ae65c5c884ff8609a03ad7
Stats:     120 lines in 7 files changed: 120 ins; 0 del; 0 mod

7903357: add a jextract sample that uses pcre2 library

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jextract/pull/88

From sundar at openjdk.org  Mon Oct 17 07:10:29 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Mon, 17 Oct 2022 07:10:29 GMT
Subject: RFR: 7903358: jextract does not generate correct signature for
 multidimensional arrays in doc comments
Message-ID: <R5j6CJ19VCdRP-Q6Oaub1eAaQiNjtX9ejjzzTlVoyrM=.95ba81d6-4de0-49ea-9d02-1324d69d6597@github.com>

"context" was not properly handled in nested array type case.

-------------

Commit messages:
 - 7903358: jextract does not generate correct signature for multidimensional arrays in doc comments

Changes: https://git.openjdk.org/jextract/pull/89/files
 Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=89&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903358
  Stats: 11 lines in 3 files changed: 9 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jextract/pull/89.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/89/head:pull/89

PR: https://git.openjdk.org/jextract/pull/89

From duke at openjdk.org  Mon Oct 17 08:37:24 2022
From: duke at openjdk.org (Per Minborg)
Date: Mon, 17 Oct 2022 08:37:24 GMT
Subject: Integrated: Fix typo in README.md
In-Reply-To: <870tHg7tlUyA3h2GpLgOyXk0D3JyhKBkwDCot2goOBs=.9aa7d09c-0aef-443d-b25c-6c814c0f8ac1@github.com>
References: <870tHg7tlUyA3h2GpLgOyXk0D3JyhKBkwDCot2goOBs=.9aa7d09c-0aef-443d-b25c-6c814c0f8ac1@github.com>
Message-ID: <EWK_6jHWG-_m740ahR2YHgqZPEkJKdm6hnvf1h6zafs=.123db2a3-1787-44a0-b653-4191b2d2c22c@github.com>

On Tue, 27 Sep 2022 07:25:24 GMT, Per Minborg <duke at openjdk.org> wrote:

> This PR removes a redundant `=` character.

This pull request has now been integrated.

Changeset: 08e03c73
Author:    Per Minborg <pminborg at gmail.com>
Committer: Athijegannathan Sundararajan <sundar at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/08e03c738316e325f226ba4bdc393ab6af79bca7
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

Fix typo in README.md

Reviewed-by: sundar

-------------

PR: https://git.openjdk.org/jextract/pull/78

From duke at openjdk.org  Mon Oct 17 12:57:08 2022
From: duke at openjdk.org (Per Minborg)
Date: Mon, 17 Oct 2022 12:57:08 GMT
Subject: RFR: 7903358: jextract does not generate correct signature for
 multidimensional arrays in doc comments
In-Reply-To: <R5j6CJ19VCdRP-Q6Oaub1eAaQiNjtX9ejjzzTlVoyrM=.95ba81d6-4de0-49ea-9d02-1324d69d6597@github.com>
References: <R5j6CJ19VCdRP-Q6Oaub1eAaQiNjtX9ejjzzTlVoyrM=.95ba81d6-4de0-49ea-9d02-1324d69d6597@github.com>
Message-ID: <ZCP_yrUa0NZBRYYIXuQUelZvACAmqZ8T9Jlk0afqWVc=.17da5cb5-0706-42f7-a60c-bafd5dcb52e8@github.com>

On Mon, 17 Oct 2022 07:03:57 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> "context" was not properly handled in nested array type case.

LGTM

-------------

Marked as reviewed by minborg at github.com (no known OpenJDK username).

PR: https://git.openjdk.org/jextract/pull/89

From mcimadamore at openjdk.org  Mon Oct 17 13:19:10 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 17 Oct 2022 13:19:10 GMT
Subject: RFR: 7903358: jextract does not generate correct signature for
 multidimensional arrays in doc comments
In-Reply-To: <R5j6CJ19VCdRP-Q6Oaub1eAaQiNjtX9ejjzzTlVoyrM=.95ba81d6-4de0-49ea-9d02-1324d69d6597@github.com>
References: <R5j6CJ19VCdRP-Q6Oaub1eAaQiNjtX9ejjzzTlVoyrM=.95ba81d6-4de0-49ea-9d02-1324d69d6597@github.com>
Message-ID: <nzgYbxsTq_GXbFnHZIzEGGdaSZkA7AH0rtaWzYjAHrk=.15f3d0f1-0f09-4fae-a0b8-7aac6002e599@github.com>

On Mon, 17 Oct 2022 07:03:57 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> "context" was not properly handled in nested array type case.

Looks good

-------------

Marked as reviewed by mcimadamore (Committer).

PR: https://git.openjdk.org/jextract/pull/89

From sundar at openjdk.org  Mon Oct 17 14:42:08 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Mon, 17 Oct 2022 14:42:08 GMT
Subject: Integrated: 7903358: jextract does not generate correct signature for
 multidimensional arrays in doc comments
In-Reply-To: <R5j6CJ19VCdRP-Q6Oaub1eAaQiNjtX9ejjzzTlVoyrM=.95ba81d6-4de0-49ea-9d02-1324d69d6597@github.com>
References: <R5j6CJ19VCdRP-Q6Oaub1eAaQiNjtX9ejjzzTlVoyrM=.95ba81d6-4de0-49ea-9d02-1324d69d6597@github.com>
Message-ID: <4fUo_a44p3NU0Xy-9Ia5jtcU1rljbB9F_a6wvLpy1kU=.ba6e7a07-0ffa-4419-a59b-cfbacff1fa06@github.com>

On Mon, 17 Oct 2022 07:03:57 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> "context" was not properly handled in nested array type case.

This pull request has now been integrated.

Changeset: 46ddf1fe
Author:    Athijegannathan Sundararajan <sundar at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/46ddf1febe99563d336cb8068a21999136179960
Stats:     11 lines in 3 files changed: 9 ins; 0 del; 2 mod

7903358: jextract does not generate correct signature for multidimensional arrays in doc comments

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jextract/pull/89

From nlisker at gmail.com  Tue Oct 18 00:12:01 2022
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 18 Oct 2022 03:12:01 +0300
Subject: Enum as an include option
Message-ID: <CA+0ynh_sny8YXjXt88XetACEj8vcsXi1bXA4u0-2fLrafyBOPQ@mail.gmail.com>

Hi,

It looks like there is no --include- option for enum, although
Declaration.Scoped.Kind.ENUM exists. Is it part of the WIP or is there
another reason it's not an option?

- Nir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20221018/5648d9da/attachment.htm>

From sundar at openjdk.org  Tue Oct 18 06:17:23 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Tue, 18 Oct 2022 06:17:23 GMT
Subject: RFR: 7903360: jextract does not handle function pointer return type
 properly
Message-ID: <LjNFly_AQkVhiv6QF2d9aRGbHVT_uQbyi_COE8nd4TI=.85b1f732-6871-4583-8bba-0597bbb02c98@github.com>

* generating functional interface for pointer to function return types
* taking care of javadoc comment by using nameAndType function uniformly

-------------

Commit messages:
 - 7903360: jextract does not handle function pointer return type properly

Changes: https://git.openjdk.org/jextract/pull/90/files
 Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=90&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903360
  Stats: 73 lines in 5 files changed: 56 ins; 7 del; 10 mod
  Patch: https://git.openjdk.org/jextract/pull/90.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/90/head:pull/90

PR: https://git.openjdk.org/jextract/pull/90

From mcimadamore at openjdk.org  Tue Oct 18 09:17:19 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 18 Oct 2022 09:17:19 GMT
Subject: RFR: 7903360: jextract does not handle function pointer return
 type properly
In-Reply-To: <LjNFly_AQkVhiv6QF2d9aRGbHVT_uQbyi_COE8nd4TI=.85b1f732-6871-4583-8bba-0597bbb02c98@github.com>
References: <LjNFly_AQkVhiv6QF2d9aRGbHVT_uQbyi_COE8nd4TI=.85b1f732-6871-4583-8bba-0597bbb02c98@github.com>
Message-ID: <6yIxdPF4J4eyq-GBIoYQ2dGkJwqy4YqchCIYzoRHdRg=.7a10e3f7-6d4b-480a-8660-4a232623644c@github.com>

On Tue, 18 Oct 2022 06:09:21 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> * generating functional interface for pointer to function return types
> * taking care of javadoc comment by using nameAndType function uniformly

src/main/java/org/openjdk/jextract/impl/NameMangler.java line 133:

> 131:     }
> 132: 
> 133:     String getReturnFiName(Declaration.Function func) {

Why can't `getFiName` be reused here?

src/main/java/org/openjdk/jextract/impl/OutputFactory.java line 263:

> 261: 
> 262:         // return type could be a function pointer type
> 263:         Type.Function returnFunc = Utils.getAsFunctionPointer(funcTree.type().returnType());

Did you check the corner case of a function pointer having a function pointer as its return type?

-------------

PR: https://git.openjdk.org/jextract/pull/90

From maurizio.cimadamore at oracle.com  Tue Oct 18 10:01:42 2022
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 18 Oct 2022 11:01:42 +0100
Subject: Enum as an include option
In-Reply-To: <CA+0ynh_sny8YXjXt88XetACEj8vcsXi1bXA4u0-2fLrafyBOPQ@mail.gmail.com>
References: <CA+0ynh_sny8YXjXt88XetACEj8vcsXi1bXA4u0-2fLrafyBOPQ@mail.gmail.com>
Message-ID: <5b5f2ab2-8795-a29d-af74-f7471e087e4a@oracle.com>

Hi,
we did some experiments in this area:

https://git.openjdk.java.net/jextract/pull/36

But when trying it out, some issues were reported:

https://mail.openjdk.org/pipermail/panama-dev/2022-June/017073.html

So we decided to revert to previous behavior.

The main issue is that enums are "lowered" into standalone constants - 
e.g. a C enum like:

```
enum Colors { RED, GREEN, BLUE };
```

Is just translated as three constants in the main header class. There is 
no "Colors" interface generated by jextract. That's because in C enum 
constants are global, so we tried to respect that semantics with jextract.

But Duncan's email above also highlighted the fact that having an 
all-or-nothing flag for generating constants for an entire enum doesn't 
cut it: some enums might be huge, and you only want to import 2-3 constants.

So, the constant-driven filtering gives more flexibility to developers 
that really want to control how much stuff is generated by jextract. The 
alternative would be to have _two_ options, one for enum and one for 
enum constants, and then to define how the two interact which, frankly, 
seems messy.

Cheers
Maurizio



On 18/10/2022 01:12, Nir Lisker wrote:
> Hi,
>
> It looks like there is no --include- option for enum, although 
> Declaration.Scoped.Kind.ENUM exists. Is it part of the WIP or is there 
> another reason it's not an option?
>
> - Nir

From sundar at openjdk.org  Tue Oct 18 10:05:15 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Tue, 18 Oct 2022 10:05:15 GMT
Subject: RFR: 7903360: jextract does not handle function pointer return
 type properly
In-Reply-To: <6yIxdPF4J4eyq-GBIoYQ2dGkJwqy4YqchCIYzoRHdRg=.7a10e3f7-6d4b-480a-8660-4a232623644c@github.com>
References: <LjNFly_AQkVhiv6QF2d9aRGbHVT_uQbyi_COE8nd4TI=.85b1f732-6871-4583-8bba-0597bbb02c98@github.com>
 <6yIxdPF4J4eyq-GBIoYQ2dGkJwqy4YqchCIYzoRHdRg=.7a10e3f7-6d4b-480a-8660-4a232623644c@github.com>
Message-ID: <JatMkRXSF0QdL4M6unjlT6JeNOwnKOwLXeiQtcCvg5Q=.c8c39f5f-2ab1-4443-a0ff-cff385d5ccd4@github.com>

On Tue, 18 Oct 2022 09:08:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> * generating functional interface for pointer to function return types
>> * taking care of javadoc comment by using nameAndType function uniformly
>
> src/main/java/org/openjdk/jextract/impl/NameMangler.java line 133:
> 
>> 131:     }
>> 132: 
>> 133:     String getReturnFiName(Declaration.Function func) {
> 
> Why can't `getFiName` be reused here?

No, this is not a functional interface for the Function itself. It is comparable to getFiName(Declaration.Function func, int paramNum, Declaration.Variable param) - a particular parameter is of a function pointer type. Here return type is a function pointer type.

-------------

PR: https://git.openjdk.org/jextract/pull/90

From sundar at openjdk.org  Tue Oct 18 10:22:28 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Tue, 18 Oct 2022 10:22:28 GMT
Subject: RFR: 7903360: jextract does not handle function pointer return
 type properly
In-Reply-To: <6yIxdPF4J4eyq-GBIoYQ2dGkJwqy4YqchCIYzoRHdRg=.7a10e3f7-6d4b-480a-8660-4a232623644c@github.com>
References: <LjNFly_AQkVhiv6QF2d9aRGbHVT_uQbyi_COE8nd4TI=.85b1f732-6871-4583-8bba-0597bbb02c98@github.com>
 <6yIxdPF4J4eyq-GBIoYQ2dGkJwqy4YqchCIYzoRHdRg=.7a10e3f7-6d4b-480a-8660-4a232623644c@github.com>
Message-ID: <prSL7TE7bVspnxZhFcphAHYGV_JDnzEitGvfxSN-y7g=.3c963f3e-ece4-4bd8-bfd2-c07c3ca86b1a@github.com>

On Tue, 18 Oct 2022 09:08:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> * generating functional interface for pointer to function return types
>> * taking care of javadoc comment by using nameAndType function uniformly
>
> src/main/java/org/openjdk/jextract/impl/OutputFactory.java line 263:
> 
>> 261: 
>> 262:         // return type could be a function pointer type
>> 263:         Type.Function returnFunc = Utils.getAsFunctionPointer(funcTree.type().returnType());
> 
> Did you check the corner case of a function pointer having a function pointer as its return type?

While we recurse for pointer to function parameter types, we did recurse for return type. That's being fixed here.

For pointer to functions, we didn't recurse even for arguments (and also for return types).

For example, for

void (*func)(void (*f)(int));


we generate FI for "func" but not for "f".

The current fix case is seen in standard library (signal in signal.h). We can deal with recursing args and return types for function pointer types in a separate fix.

-------------

PR: https://git.openjdk.org/jextract/pull/90

From mcimadamore at openjdk.org  Tue Oct 18 10:57:29 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 18 Oct 2022 10:57:29 GMT
Subject: RFR: 7903360: jextract does not handle function pointer return
 type properly
In-Reply-To: <LjNFly_AQkVhiv6QF2d9aRGbHVT_uQbyi_COE8nd4TI=.85b1f732-6871-4583-8bba-0597bbb02c98@github.com>
References: <LjNFly_AQkVhiv6QF2d9aRGbHVT_uQbyi_COE8nd4TI=.85b1f732-6871-4583-8bba-0597bbb02c98@github.com>
Message-ID: <DEJYfi0fKKECyhe_8G8kQ3JcAhi769PabGGJvlEANnU=.3fff4936-90ff-478d-a7a1-0a6b3c835d7b@github.com>

On Tue, 18 Oct 2022 06:09:21 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> * generating functional interface for pointer to function return types
> * taking care of javadoc comment by using nameAndType function uniformly

Marked as reviewed by mcimadamore (Committer).

-------------

PR: https://git.openjdk.org/jextract/pull/90

From mcimadamore at openjdk.org  Tue Oct 18 10:57:29 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 18 Oct 2022 10:57:29 GMT
Subject: RFR: 7903360: jextract does not handle function pointer return
 type properly
In-Reply-To: <JatMkRXSF0QdL4M6unjlT6JeNOwnKOwLXeiQtcCvg5Q=.c8c39f5f-2ab1-4443-a0ff-cff385d5ccd4@github.com>
References: <LjNFly_AQkVhiv6QF2d9aRGbHVT_uQbyi_COE8nd4TI=.85b1f732-6871-4583-8bba-0597bbb02c98@github.com>
 <6yIxdPF4J4eyq-GBIoYQ2dGkJwqy4YqchCIYzoRHdRg=.7a10e3f7-6d4b-480a-8660-4a232623644c@github.com>
 <JatMkRXSF0QdL4M6unjlT6JeNOwnKOwLXeiQtcCvg5Q=.c8c39f5f-2ab1-4443-a0ff-cff385d5ccd4@github.com>
Message-ID: <7N9Ydxaa85lROR2n2Z8LvUeP6SjXYqnCg98PfyIf7GY=.7e5da503-ac11-4543-ad26-1811c03c6034@github.com>

On Tue, 18 Oct 2022 10:03:11 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

>> src/main/java/org/openjdk/jextract/impl/NameMangler.java line 133:
>> 
>>> 131:     }
>>> 132: 
>>> 133:     String getReturnFiName(Declaration.Function func) {
>> 
>> Why can't `getFiName` be reused here?
>
> No, this is not a functional interface for the Function itself. It is comparable to getFiName(Declaration.Function func, int paramNum, Declaration.Variable param) - a particular parameter is of a function pointer type. Here return type is a function pointer type.

I missed that there were (already) two variants of getFIName. Ugh.

-------------

PR: https://git.openjdk.org/jextract/pull/90

From sundar at openjdk.org  Tue Oct 18 11:03:46 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Tue, 18 Oct 2022 11:03:46 GMT
Subject: Integrated: 7903360: jextract does not handle function pointer return
 type properly
In-Reply-To: <LjNFly_AQkVhiv6QF2d9aRGbHVT_uQbyi_COE8nd4TI=.85b1f732-6871-4583-8bba-0597bbb02c98@github.com>
References: <LjNFly_AQkVhiv6QF2d9aRGbHVT_uQbyi_COE8nd4TI=.85b1f732-6871-4583-8bba-0597bbb02c98@github.com>
Message-ID: <ZZuK3Vsu9qdGKonTaD8i6XutxJc0YlMYE-_pG_hO1Zw=.0110c842-937c-4b05-b2f0-b3064d773b6c@github.com>

On Tue, 18 Oct 2022 06:09:21 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> * generating functional interface for pointer to function return types
> * taking care of javadoc comment by using nameAndType function uniformly

This pull request has now been integrated.

Changeset: b23a4fd0
Author:    Athijegannathan Sundararajan <sundar at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/b23a4fd0dd9f43e29474874eb76a84a8cb47bf23
Stats:     73 lines in 5 files changed: 56 ins; 7 del; 10 mod

7903360: jextract does not handle function pointer return type properly

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jextract/pull/90

From sundar at openjdk.org  Tue Oct 18 12:14:11 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Tue, 18 Oct 2022 12:14:11 GMT
Subject: RFR: 7903362: rename --include-macro option to be --include-constant
Message-ID: <JphT7pfyUAy4X0AcIHPGAFj-9EzQooh6yhhQrF3pizg=.d09960eb-fba8-440e-90c3-00bc3fae1449@github.com>

Option renamed. Test added for enum constant filtering.

-------------

Commit messages:
 - 7903362: rename --include-macro option to be --include-constant

Changes: https://git.openjdk.org/jextract/pull/91/files
 Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=91&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903362
  Stats: 13 lines in 5 files changed: 5 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jextract/pull/91.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/91/head:pull/91

PR: https://git.openjdk.org/jextract/pull/91

From pminborg at openjdk.org  Tue Oct 18 13:49:19 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 18 Oct 2022 13:49:19 GMT
Subject: RFR: 7903362: rename --include-macro option to be
 --include-constant
In-Reply-To: <JphT7pfyUAy4X0AcIHPGAFj-9EzQooh6yhhQrF3pizg=.d09960eb-fba8-440e-90c3-00bc3fae1449@github.com>
References: <JphT7pfyUAy4X0AcIHPGAFj-9EzQooh6yhhQrF3pizg=.d09960eb-fba8-440e-90c3-00bc3fae1449@github.com>
Message-ID: <Do3DJibDJa5uRBIOwGWPhAAHk72McGLM3XtwfEAVQAo=.3ec85aa0-213e-457c-91fd-abbe93d340dd@github.com>

On Tue, 18 Oct 2022 12:06:52 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> Option renamed. Test added for enum constant filtering.

LGTM

-------------

Marked as reviewed by pminborg (no project role).

PR: https://git.openjdk.org/jextract/pull/91

From mcimadamore at openjdk.org  Tue Oct 18 13:49:19 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 18 Oct 2022 13:49:19 GMT
Subject: RFR: 7903362: rename --include-macro option to be
 --include-constant
In-Reply-To: <JphT7pfyUAy4X0AcIHPGAFj-9EzQooh6yhhQrF3pizg=.d09960eb-fba8-440e-90c3-00bc3fae1449@github.com>
References: <JphT7pfyUAy4X0AcIHPGAFj-9EzQooh6yhhQrF3pizg=.d09960eb-fba8-440e-90c3-00bc3fae1449@github.com>
Message-ID: <R3UYArOlwjR2ttDSPpM_26AEjB8A7SgJO_-lBGabMBc=.138d8c68-1ba7-4eae-89d1-0af6a9288f2a@github.com>

On Tue, 18 Oct 2022 12:06:52 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> Option renamed. Test added for enum constant filtering.

Marked as reviewed by mcimadamore (Committer).

-------------

PR: https://git.openjdk.org/jextract/pull/91

From sundar at openjdk.org  Tue Oct 18 14:01:21 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Tue, 18 Oct 2022 14:01:21 GMT
Subject: Integrated: 7903362: rename --include-macro option to be
 --include-constant
In-Reply-To: <JphT7pfyUAy4X0AcIHPGAFj-9EzQooh6yhhQrF3pizg=.d09960eb-fba8-440e-90c3-00bc3fae1449@github.com>
References: <JphT7pfyUAy4X0AcIHPGAFj-9EzQooh6yhhQrF3pizg=.d09960eb-fba8-440e-90c3-00bc3fae1449@github.com>
Message-ID: <2Vtr_0rk-S1LP4Rr4pnJLJdGDn3r5wEwtpusYn_n5FI=.b40d6e39-33f3-4d30-a051-e5d2265fa1d3@github.com>

On Tue, 18 Oct 2022 12:06:52 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> Option renamed. Test added for enum constant filtering.

This pull request has now been integrated.

Changeset: 73e408ec
Author:    Athijegannathan Sundararajan <sundar at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/73e408ec3f15fe1e615eeca434c2ce54627adeab
Stats:     13 lines in 5 files changed: 5 ins; 0 del; 8 mod

7903362: rename --include-macro option to be --include-constant

Reviewed-by: pminborg, mcimadamore

-------------

PR: https://git.openjdk.org/jextract/pull/91

From mcimadamore at openjdk.org  Wed Oct 26 17:17:39 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 26 Oct 2022 17:17:39 GMT
Subject: RFR: 7903239: ofAddress factory of function pointer type is wrong
 for struct returns [v4]
In-Reply-To: <cTlhwM18VT-Zv9UzdC3_EmI6J_JoQ7smDsQZvW5t9Vo=.ce71ceda-21f7-45b4-a3eb-9b124411c1f0@github.com>
References: <VOQBzvWupTMIQsAccTVhA-t5RFqY36XSmpTRgqbYTnY=.ec8ee007-22ae-41bb-abbe-eeb291c899a0@github.com>
 <cTlhwM18VT-Zv9UzdC3_EmI6J_JoQ7smDsQZvW5t9Vo=.ce71ceda-21f7-45b4-a3eb-9b124411c1f0@github.com>
Message-ID: <4xMPMn-9t35lv7YnMFBp9Y9xrte3R25yTGt4WJzcxks=.99fd5ce9-f3f0-4b44-91af-535510639f9a@github.com>

On Fri, 5 Aug 2022 04:32:04 GMT, Marko <duke at openjdk.org> wrote:

>> When generating the lambda inside the `ofAddress` factory, it is missing the `SegmentAllocator` needed when the function returns a struct. This is [implemented for regular functions](https://github.com/openjdk/jextract/blob/0582eaf1b4cdba95f0ee8c2480767433bb647d0d/src/main/java/org/openjdk/jextract/impl/HeaderFileBuilder.java#L122-L127), but not for function pointers.
>
> Marko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   newline

I have not sponsored this yet as the target branch of this PR seems wrong (e.g. `master` instead of `panama` or `jdk19`).

-------------

PR: https://git.openjdk.org/jextract/pull/58

From jvernee at openjdk.org  Thu Oct 27 10:48:43 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 27 Oct 2022 10:48:43 GMT
Subject: RFR: Add Dockerfile, zero-dep reproducible builds
In-Reply-To: <OosR15f71ivNrrPDwRJ65L4L_b6TuyzajcCuU2DQNhE=.6151d677-e724-431b-bc1b-dca280aff8b8@github.com>
References: <CHc7NR_SJYeCo9pysfl5LOfqltrQIRXrF9KLnLrhxLs=.9e8875a5-ecd2-42af-bceb-3a9c38f56941@github.com>
 <OosR15f71ivNrrPDwRJ65L4L_b6TuyzajcCuU2DQNhE=.6151d677-e724-431b-bc1b-dca280aff8b8@github.com>
Message-ID: <DhM-8ZkHCaGCEiuw8wQxDBvuyruu9fo5BLBlfIiw8t8=.da4b369d-5c60-4c46-b8a3-ce99ff2a977d@github.com>

On Wed, 21 Sep 2022 15:41:42 GMT, Gavin Ray <duke at openjdk.org> wrote:

>> As title says, adds a Dockerfile that will fetch all necessary deps and build `jextract` for you on Ubuntu 22.10
>> 
>> It would be nice if some official JDK organization could put this on their Dockerhub, so that users could just do:
>> 
>> 
>> $ docker run --rm -it openjdk/jextract:latest
>> 
>> 
>> I've pushed it to my personal Dockerhub, so if anyone would like to test it out, you can use the README directions but prepend `gavinray/` before the image name:
>> 
>> 
>> $ echo "struct Foo { int a; long b; }; int use_foo(struct Foo foo);" >> sample.h
>> 
>> $ docker run --rm -it -v ${PWD}:/tmp/jextract \
>>     gavinray/jextract:latest \
>>     -I /tmp/jextract \
>>     --source \
>>     -l libfoo \
>>     --output /tmp/jextract/generated \
>>     --target-package com.example \
>
> But you already have my OCA, since last year ;..;

Hi @GavinRay97 sorry for the late reply.

After some internal discussions, we have decided not to take on this patch, or any other that adds a docker file.

A docker file pulls in several dependencies from the internet, which have to be individually vetted and approved on a per-version basis.

As we already do this for the gradle build, we are wary of adding more process overhead by adding a docker file (or other things that pull in more dependencies) to the repo as well. Besides that, it's another build configuration to maintain, and we already have 2 (gradle and make).

-------------

PR: https://git.openjdk.org/jextract/pull/74

From duke at openjdk.org  Thu Oct 27 13:45:45 2022
From: duke at openjdk.org (Gavin Ray)
Date: Thu, 27 Oct 2022 13:45:45 GMT
Subject: RFR: Add Dockerfile, zero-dep reproducible builds
In-Reply-To: <CHc7NR_SJYeCo9pysfl5LOfqltrQIRXrF9KLnLrhxLs=.9e8875a5-ecd2-42af-bceb-3a9c38f56941@github.com>
References: <CHc7NR_SJYeCo9pysfl5LOfqltrQIRXrF9KLnLrhxLs=.9e8875a5-ecd2-42af-bceb-3a9c38f56941@github.com>
Message-ID: <mwx81-mkK_rykJCtQAeVh26fJTkD4ANXSDylRmNAWxg=.62b3e4a6-719d-49ea-8b90-5f045117615c@github.com>

On Wed, 21 Sep 2022 13:55:19 GMT, Gavin Ray <duke at openjdk.org> wrote:

> As title says, adds a Dockerfile that will fetch all necessary deps and build `jextract` for you on Ubuntu 22.10
> 
> It would be nice if some official JDK organization could put this on their Dockerhub, so that users could just do:
> 
> 
> $ docker run --rm -it openjdk/jextract:latest
> 
> 
> I've pushed it to my personal Dockerhub, so if anyone would like to test it out, you can use the README directions but prepend `gavinray/` before the image name:
> 
> 
> $ echo "struct Foo { int a; long b; }; int use_foo(struct Foo foo);" >> sample.h
> 
> $ docker run --rm -it -v ${PWD}:/tmp/jextract \
>     gavinray/jextract:latest \
>     -I /tmp/jextract \
>     --source \
>     -l libfoo \
>     --output /tmp/jextract/generated \
>     --target-package com.example \

That's fair enough, maybe I could redo the PR where instead of putting the
Dockerfile in the repo,
an example definition that users can use for their own Dockerfiles if they
wish to build jextract
is provided in the documentation?

The problem I was hoping to solve is preventing users from needing to
manually install and
configure things like the right version of the LLVM toolchain for their OS,
etc

Would this be an acceptable compromise? Or is something like this still
better off in third-party land?

On Thu, Oct 27, 2022 at 6:45 AM Jorn Vernee ***@***.***>
wrote:

> Hi @GavinRay97 <https://github.com/GavinRay97> sorry for the late reply.
>
> After some internal discussions, we have decided not to take on this
> patch, or any other that adds a docker file.
>
> A docker file pulls in several dependencies from the internet, which have
> to be individually vetted and approved on a per-version basis.
>
> As we already do this for the gradle build, we are wary of adding more
> process overhead by adding a docker file (or other things that pull in more
> dependencies) to the repo as well. Besides that, it's another build
> configuration to maintain, and we already have 2 (gradle and make).
>
> ?
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jextract/pull/74#issuecomment-1293337834>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AGK7LQWDOV2ZWNR4ISKBSB3WFJMLHANCNFSM6AAAAAAQSDEKYE>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>

-------------

PR: https://git.openjdk.org/jextract/pull/74

From duncan.gittins at gmail.com  Fri Oct 28 16:37:22 2022
From: duncan.gittins at gmail.com (Duncan Gittins)
Date: Fri, 28 Oct 2022 17:37:22 +0100
Subject: New candidate JEP: 434: Foreign Function & Memory API (Second
 Preview)
In-Reply-To: <CAFtvWZOwTgR72qvbFagP=Jq7m=eN=8uUU_43zGN7vJuNgcNEeA@mail.gmail.com>
References: <20221027182957.2993754ACB3@eggemoggin.niobe.net>
 <CAFtvWZOwTgR72qvbFagP=Jq7m=eN=8uUU_43zGN7vJuNgcNEeA@mail.gmail.com>
Message-ID: <CABOqcFv4+3Cd8KEDgjysz_gT7=GzcMsM_YiU7jQtajpJz_2agw@mail.gmail.com>

Continuing the theme of Gavin's request, I think you might get more people
to try out jextract and Panama if there were easy to find download links in
https://jdk.java.net/panama/ for versions aligned the shipped JDK 17/18/19.

This means a developer could try samples for the JDK version they already
have installed without needing to build either JDK or jextract themselves.
Hopefully it only needs posting every 6 months.

Kind regards

Duncan



On Fri, 28 Oct 2022 at 00:56, Gavin Ray <ray.gavin97 at gmail.com> wrote:

> Hooray!
>
> By any chance, will there be a new release of the Panama 20ea JDK and
> jextract binaries as well?
> I've had quite some difficulties getting jextract on 20 built and it'd be
> swell to rebase some of the work I've done on the more recent API changes.
>
> On Thu, Oct 27, 2022 at 2:30 PM Mark Reinhold <mark.reinhold at oracle.com>
> wrote:
>
>> https://openjdk.org/jeps/434
>>
>>   Summary: Introduce an API by which Java programs can interoperate with
>>   code and data outside of the Java runtime. By efficiently invoking
>>   foreign functions (i.e., code outside the JVM), and by safely accessing
>>   foreign memory (i.e., memory not managed by the JVM), the API enables
>>   Java programs to call native libraries and process native data without
>>   the brittleness and danger of JNI. This is a preview API.
>>
>> - Mark
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20221028/5c2611df/attachment.htm>

From maurizio.cimadamore at oracle.com  Fri Oct 28 18:11:04 2022
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 28 Oct 2022 19:11:04 +0100
Subject: New candidate JEP: 434: Foreign Function & Memory API (Second
 Preview)
In-Reply-To: <CABOqcFv4+3Cd8KEDgjysz_gT7=GzcMsM_YiU7jQtajpJz_2agw@mail.gmail.com>
References: <20221027182957.2993754ACB3@eggemoggin.niobe.net>
 <CAFtvWZOwTgR72qvbFagP=Jq7m=eN=8uUU_43zGN7vJuNgcNEeA@mail.gmail.com>
 <CABOqcFv4+3Cd8KEDgjysz_gT7=GzcMsM_YiU7jQtajpJz_2agw@mail.gmail.com>
Message-ID: <570147f1-2ff0-b881-f06e-d58e1c54eacf@oracle.com>

Hey Duncan,
Note that we do have jextract binaries available:

https://jdk.java.net/jextract/

This works against a vanilla JDK 19.

When the first JDK 20 EA build with the new FFM API will come out, the 
above page will be updated, and a link to jextract 20 will be added.

The Panama binary download page you indicated is effectively obsolete, 
and it should probably be removed, to avoid confusion.

Maurizio

On 28/10/2022 17:37, Duncan Gittins wrote:
> Continuing the theme of Gavin's request, I think you might get more 
> people to try out jextract and Panama if there were easy to find 
> download links in https://jdk.java.net/panama/ 
> <https://urldefense.com/v3/__https://jdk.java.net/panama/__;!!ACWV5N9M2RV99hQ!NwW3xcoQINXDkZUYrgkilaKazXBg7Lbny12740ULMd93Kt9K294BZxGybUuFG_wLac9iDuQ8pzIdwG8Os7Vqo-fi_I3YxzoF$> 
> for versions aligned the shipped JDK 17/18/19.
>
> This means a developer could try samples for the JDK version they 
> already have installed without needing to build either JDK or jextract 
> themselves. Hopefully it only needs posting every 6 months.
>
> Kind regards
>
> Duncan
>
>
>
> On Fri, 28 Oct 2022 at 00:56, Gavin Ray <ray.gavin97 at gmail.com> wrote:
>
>     Hooray!
>
>     By any chance, will there be a new release of the Panama 20ea JDK
>     and jextract binaries as well?
>     I've had quite some difficulties getting jextract on 20 built and
>     it'd be swell to rebase some of the work I've done on the more
>     recent API changes.
>
>     On Thu, Oct 27, 2022 at 2:30 PM Mark Reinhold
>     <mark.reinhold at oracle.com> wrote:
>
>         https://openjdk.org/jeps/434
>
>         ? Summary: Introduce an API by which Java programs can
>         interoperate with
>         ? code and data outside of the Java runtime. By efficiently
>         invoking
>         ? foreign functions (i.e., code outside the JVM), and by
>         safely accessing
>         ? foreign memory (i.e., memory not managed by the JVM), the
>         API enables
>         ? Java programs to call native libraries and process native
>         data without
>         ? the brittleness and danger of JNI. This is a preview API.
>
>         - Mark
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20221028/3dfec924/attachment-0001.htm>

From jvernee at openjdk.org  Sat Oct 29 03:20:44 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Sat, 29 Oct 2022 03:20:44 GMT
Subject: RFR: Add Dockerfile, zero-dep reproducible builds
In-Reply-To: <CHc7NR_SJYeCo9pysfl5LOfqltrQIRXrF9KLnLrhxLs=.9e8875a5-ecd2-42af-bceb-3a9c38f56941@github.com>
References: <CHc7NR_SJYeCo9pysfl5LOfqltrQIRXrF9KLnLrhxLs=.9e8875a5-ecd2-42af-bceb-3a9c38f56941@github.com>
Message-ID: <ne9snhHm-RGOg5kf9eN079CidUZwAgqTn6DTfNDcwzw=.dfae4999-c884-49b2-a02e-90e420c75817@github.com>

On Wed, 21 Sep 2022 13:55:19 GMT, Gavin Ray <duke at openjdk.org> wrote:

> As title says, adds a Dockerfile that will fetch all necessary deps and build `jextract` for you on Ubuntu 22.10
> 
> It would be nice if some official JDK organization could put this on their Dockerhub, so that users could just do:
> 
> 
> $ docker run --rm -it openjdk/jextract:latest
> 
> 
> I've pushed it to my personal Dockerhub, so if anyone would like to test it out, you can use the README directions but prepend `gavinray/` before the image name:
> 
> 
> $ echo "struct Foo { int a; long b; }; int use_foo(struct Foo foo);" >> sample.h
> 
> $ docker run --rm -it -v ${PWD}:/tmp/jextract \
>     gavinray/jextract:latest \
>     -I /tmp/jextract \
>     --source \
>     -l libfoo \
>     --output /tmp/jextract/generated \
>     --target-package com.example \

That would suffer from the same issues I'm afraid.

-------------

PR: https://git.openjdk.org/jextract/pull/74

From duke at openjdk.org  Sat Oct 29 07:09:24 2022
From: duke at openjdk.org (Marko)
Date: Sat, 29 Oct 2022 07:09:24 GMT
Subject: RFR: 7903239: ofAddress factory of function pointer type is wrong
 for struct returns [v5]
In-Reply-To: <VOQBzvWupTMIQsAccTVhA-t5RFqY36XSmpTRgqbYTnY=.ec8ee007-22ae-41bb-abbe-eeb291c899a0@github.com>
References: <VOQBzvWupTMIQsAccTVhA-t5RFqY36XSmpTRgqbYTnY=.ec8ee007-22ae-41bb-abbe-eeb291c899a0@github.com>
Message-ID: <LP-E8IsL6M0FqpPZsnK_tuae328_t3jmAz7aqsP8M7s=.9df46f37-44ef-474d-a6ec-23c3cab46156@github.com>

> When generating the lambda inside the `ofAddress` factory, it is missing the `SegmentAllocator` needed when the function returns a struct. This is [implemented for regular functions](https://github.com/openjdk/jextract/blob/0582eaf1b4cdba95f0ee8c2480767433bb647d0d/src/main/java/org/openjdk/jextract/impl/HeaderFileBuilder.java#L122-L127), but not for function pointers.

Marko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'panama' into CODETOOLS-7903239
 - newline
 - update copyright
 - add proper tests
 - 7903239: ofAddress factory of function pointer type is wrong for struct returns

-------------

Changes: https://git.openjdk.org/jextract/pull/58/files
 Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=58&range=04
  Stats: 104 lines in 4 files changed: 103 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jextract/pull/58.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/58/head:pull/58

PR: https://git.openjdk.org/jextract/pull/58

From duke at openjdk.org  Sat Oct 29 07:09:25 2022
From: duke at openjdk.org (Marko)
Date: Sat, 29 Oct 2022 07:09:25 GMT
Subject: RFR: 7903239: ofAddress factory of function pointer type is wrong
 for struct returns [v4]
In-Reply-To: <cTlhwM18VT-Zv9UzdC3_EmI6J_JoQ7smDsQZvW5t9Vo=.ce71ceda-21f7-45b4-a3eb-9b124411c1f0@github.com>
References: <VOQBzvWupTMIQsAccTVhA-t5RFqY36XSmpTRgqbYTnY=.ec8ee007-22ae-41bb-abbe-eeb291c899a0@github.com>
 <cTlhwM18VT-Zv9UzdC3_EmI6J_JoQ7smDsQZvW5t9Vo=.ce71ceda-21f7-45b4-a3eb-9b124411c1f0@github.com>
Message-ID: <usn71Bwn6eCMh7kMcUPOQiuUc1ufbKHRIeezKa2nTa8=.b69da2d5-efbf-48c6-b3a5-892aedd7bd93@github.com>

On Fri, 5 Aug 2022 04:32:04 GMT, Marko <duke at openjdk.org> wrote:

>> When generating the lambda inside the `ofAddress` factory, it is missing the `SegmentAllocator` needed when the function returns a struct. This is [implemented for regular functions](https://github.com/openjdk/jextract/blob/0582eaf1b4cdba95f0ee8c2480767433bb647d0d/src/main/java/org/openjdk/jextract/impl/HeaderFileBuilder.java#L122-L127), but not for function pointers.
>
> Marko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   newline

Woops, should be good now.

-------------

PR: https://git.openjdk.org/jextract/pull/58