<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<pre class="moz-quote-pre" wrap="">On Tue, 7 Feb 2023 15:26:35 +0100, Tõivo Leedjärv wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite" style="color: #007cff;">
<pre class="moz-quote-pre" wrap="">Option 1: recompile the Unison binary (with only the text UI) for
Android and call that from the GUI.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">I know this or something similar has been done
(<a class="moz-txt-link-freetext" href="https://urldefense.com/v3/__https://github.com/bcpierce00/unison/wiki/Software-for-use-with-Unison__;!!IBzWLUs!RLHa3A2snTpIeRCQOWDMiu0DNPhEWg-3ZTB2XetsviJmlWbRwyWXiM3q1DrmXcm6ICeg-k2sgkiTn07YNd5e84Q_7oQ$">https://urldefense.com/v3/__https://github.com/bcpierce00/unison/wiki/Software-for-use-with-Unison__;!!IBzWLUs!RLHa3A2snTpIeRCQOWDMiu0DNPhEWg-3ZTB2XetsviJmlWbRwyWXiM3q1DrmXcm6ICeg-k2sgkiTn07YNd5e84Q_7oQ$</a>
) but I can't see this being a long-term stable and flexible solution.</pre>
</blockquote>
Indeed, even the author says: “<strong>Caution:</strong> Although I
use Gunison daily, it is less reliable than Unison
itself (and will always be, if only because it parses Unison’s
human-readable
output).” That is an issue with any CLI, unless it explicitly
distinguishes between what git calls plumbing and porcelain –
plumbing is intended to be called by other programs, therefore
console output is in a format that is sufficiently well-defined and
stable to be parsed by a program. Then again, parsing CLI output
might not be the most elegant way to begin with.
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Option A: linking everything into the same binary and using whatever
FFI is required to call into the OCaml code. This is basically your
option 2 but it can be done without ocamlcc. The current Mac native
GUI uses this approach.</pre>
</blockquote>
That is quite close to what I am attempting to do. <br>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Option B: some kind of IPC with some kind of serialization format to
expose an interface. Yout option 1 is one variant of this (but limited
and brittle without an interface designed specifically for this
purpose).</pre>
</blockquote>
<p>Actually I was thinking of something far less complex:</p>
<p>unison -just-report-diffs-without-touching-anything
<profile></p>
<p>unison {-left-to-right|-right-to-left} -lefthash <hash>
-righthash <hash><path> <profile> # once for
each file that is not skipped</p>
<p>– basically, a plumbing-style CLI, but that isn’t exactly
elegant. It would have been a quick win, had Unison already
provided the necessary functionality – but if I need to modify
Unison anyway, it’s not worth the effort. Better turn it into a
library with a somewhat well-defined API that a frontend can call.<br>
</p>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">As you can see, option A is already being used and seemingly working
well (I have never seen the native Mac GUI myself, though). However, I
do not suggest taking this approach right now. At least not the way
the Mac GUI does it. That's because the current implementation is
basically a bunch of duplicated code and lacks a well-defined API.
Assuming a clean universal API is defined and implemented without
(major) code duplication, I see no reason why this approach wouldn't
work in the long term.
Option B offers much more flexibility and less coupling, so without
having thought about the details at all, that's what I would go for.</pre>
</blockquote>
<p>I haven’t dug deeply yet into the Objective-C to OCaml bindings,
but I see the Mac GUI does a few things involving thread creation
and the like, which I interpret to mean that it’s not as simple as
a few function/method calls. But with the assumption of the clean
universal API, this would be my preferred architecture.</p>
<p>So challenges for me would be:</p>
<p>* compiling Unison for Android in the first place (through one of
Greg’s links I discovered
<a class="moz-txt-link-freetext" href="https://urldefense.com/v3/__https://github.com/vouillon/opam-android-repository__;!!IBzWLUs!XRYhymUdJQzornokn_snO3BE4GBc1BNVFDOcLc6QSiwC2mBN4pgM4wOAEUhRAbtZAHdniwJz7-lQCGy0_CmWOC64ysEnA0af$">https://github.com/vouillon/opam-android-repository</a> and just saw
that Jerôme, the author, is also a Unison contributor and even
mentions Unison in one of the examples)</p>
<p>* figuring out how the Mac GUI interfaces with the rest of the
Unison code</p>
<p>* figuring out if I can just call OCaml code directly from Java
via JNI, or if I need to first create a C wrapper around it</p>
<p>* if necessary, write the C wrapper<br>
</p>
<p>* get the toolchain to build a library of the OCaml code – and
the C wrapper, if necessary</p>
<p>After that, I would build the Android UI around the library –
after mastering the previous challenges, that part would just be
routine.<br>
</p>
</body>
</html>