Just a quick note, I thought JNA did work fine on Android, I am sure I
have seen android binaries for it.
However i can see advantages in what you have done, particularly in
making it more how Java code would be expected to work and making it
thread safe.
Michael Whapples
On 04/01/2016 15:52, Dave Mielke wrote:
[quoted lines by Christian Egli on 2016/01/04 at 11:34 +0100]
Did you write a java wrapper or did you use one of the existing ones?I had a look at liblouis-java, but I had two problems with it. The physical one
was that it's built on top of JNA, which looked like it'd be a lot of work to
port to Android. The philosophical one was that it, by virtual of being built
on top of JNA, does, in large part, try to present a C view in Java. My code,
now largely finished, presents a Java view in Java, and is actually a lot less
code - 150 lines in C, and 1100 lines in Java.
Note that about 500 lines of the Java code is an enumeration of the 109 *.ctb
tables themselves, including a description for each table, so that Java
programmers can refer to a table by a properly defined object rather than by
its character string name. So, in fact, if we subtract that from the original
Java line count, that leaves us with 600 Java lines.
Other perks: There are synchronization locks around the JNi calls so that a
multi-thread application won't run into trouble if liblouis uses static
variables. Also, package reinstallation (e.g. for upgrading) supports safe
table replacement so that an already-running application won't encounter an
instance where the new tables are only partially in place. It'll continue using
the old tables until the new ones are ready. When they're ready, the JNI lock
is established, and, within it, the tables are swapped and lou_free() is
called.
At the moment I'm a bit reluctant to just hand out push access to the repo.I can understand that, especially since you don't know me from anyone.
Yes. If it were me, I wouldn't publish the big config.h. What I'd do instead isNow, for the more complicated one: The liblouis.h header needs to be derived>from liblouis.h.in for exactly one small reason:
#define widechar @WIDECHAR_TYPE@Hm, I had never thought of that solution. If I understand correctly
Is this because having liblouis.h include config.h is seen as undesirable? As I
see it, either liblouis.h could include config.h or it could include some other
very small header that just #defines widechar. This would eliminate the need to
save a whole separate copy of liblouis.h just for that one line.
we would have to define a config.h.in and define WIDECHAR_TYPE in
there or alternatively we would have to AC_DEFINE widechar in
configure.ac, because at the moment it doesn't seem to be defined in
config.h. Also presumably config.h will not be installed. How are
other libs going to know the size of widechar? That would direct
towards your second suggestion of extracting the #defines widechar
into a very small header file.
create a small extra one, maybe named liblouis-config.h(.in), with only
widechar in it,and publish that one.
