development branch for the v1.07-beta.3 ?

[egonw]

There is a beta out for v1.0.7 and I was wondering if you had plans for a jna-inchi development branch for the upcoming release?

[dan2097]

I just became aware of this from the mailing list. I'll try and find the time to test this on a branch within the next week.

[dan2097]

@egonw I've only tested on Windows thus far, but all bar one unit tests pass. The failing unit tests involves reading an InChI using IXA_MOL_ReadInChI and gives an "Invalid memory access" Error from this method call. From the source code I don't think the molecule reading logic has actually changed, but the relevant source file now includes https://github.com/IUPAC-InChI/InChI/blob/main/INCHI-1-SRC/INCHI_BASE/src/bcf_s.h which if I understand correctly potentially will enable bounds checking and hence flag up functions that are writing out of bounds.

I'll see whether I can figure out the cause and then flag it up with the InChI devs.

[BobHanson]

I am not clear on the distinction between JNI and JNA, but I am looking for an update to jni-inchi-0.7-jar-with-dependencies.jar, which is what I am using in Jmol, and its WASM equivalent, which I am using in JSmol.

[email protected] produced these.

[egonw]

I am not clear on the distinction between JNI and JNA

I never looked at the differences, but https://stackoverflow.com/questions/1556421/use-jni-instead-of-jna-to-call-native-code has some useful pointers.

looking for an update to jni-inchi-0.7-jar-with-dependencies.jar, which is what I am using in Jmol

For the CDK we have migrated to the JNA version. If the JNI version is essential, then this is indeed not right place, I guess.

[dan2097]

I am not clear on the distinction between JNI and JNA, but I am looking for an update to jni-inchi-0.7-jar-with-dependencies.jar, which is what I am using in Jmol, and its WASM equivalent, which I am using in JSmol.

[email protected] produced these.

JNA (https://github.com/java-native-access/jna) is a library that simplifies calls to naive code by allowing you to write the interfacing code purely in Java. I anticipated writing and maintanining a wrapper using using JNA would be simpler than using JNI directly, especially as I wanted to utilize InChI's more extensive IXA API.

Sam Adams wrote JNI-InChI (https://jni-inchi.sourceforge.net/) but has not been maintaining this, which motivated the development of this project.

I'll have a look at 1.07 this weekend. Before a release I'll probably need to reach out to get InChI 1.07 binaries built for the system architectures that I don't have access to and are not provided by the InChI team

[egonw]

@dan2097, I can test the version in the CDK and Bacting. Ping me when you have something I can test. But I only have GNU/Linux 64 bit.

About the binaries, now that they have everything on GitHub, maybe they can set up actions to compile binaries for the various platforms. We should file that as a feature request?

[dan2097]

The issue I encountered when testing the pre-release version fortunately has been fixed on the released version (IUPAC-InChI/InChI#9).
I've tested the official binaries on Windows-64 bit and WSL (Ubuntu-22.04).

About the binaries, now that they have everything on GitHub, maybe they can set up actions to compile binaries for the various platforms. We should file that as a feature request?

Especially for macOS it would be nice if the InChI distribution included official libraries. The official distribution covers Windows and Linux 32/64-bit and that's what's on the branch thus far. If I understood correctly it provides binaries for macOS but not a library.
I'll follow up with @mjw99 and @johnmay

[johnmay]

I'll try and find time this week to build them