Re: Interface for an external GUI

This is a multi-part message in MIME format.
--===============3710375061350932993==
Content-Type: multipart/alternative;
 boundary="------------Mmkxs70N5DE3TqmYljN6jZtG"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------Mmkxs70N5DE3TqmYljN6jZtG
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable

On Tue, 7 Feb 2023 15:26:35 +0100, T=C3=B5ivo Leedj=C3=A4rv wrote:

>> Option 1: recompile the Unison binary (with only the text UI) for
>> Android and call that from the GUI.
> I know this or something similar has been done
> (https://urldefense.com/v3/__https://github.com/bcpierce00/unison/wiki/So=
ftware-for-use-with-Unison__;!!IBzWLUs!RLHa3A2snTpIeRCQOWDMiu0DNPhEWg-3ZTB2=
XetsviJmlWbRwyWXiM3q1DrmXcm6ICeg-k2sgkiTn07YNd5e84Q_7oQ$=20=20
> ) but I can't see this being a long-term stable and flexible solution.
Indeed, even the author says: =E2=80=9C*Caution:* Although I use Gunison da=
ily,=20
it is less reliable than Unison itself (and will always be, if only=20
because it parses Unison=E2=80=99s human-readable output).=E2=80=9D That is=
 an issue=20
with any CLI, unless it explicitly distinguishes between what git calls=20
plumbing and porcelain =E2=80=93 plumbing is intended to be called by other=
=20
programs, therefore console output is in a format that is sufficiently=20
well-defined and stable to be parsed by a program. Then again, parsing=20
CLI output might not be the most elegant way to begin with.
> 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.
That is quite close to what I am attempting to do.
> 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).

Actually I was thinking of something far less complex:

unison -just-report-diffs-without-touching-anything <profile>

unison {-left-to-right|-right-to-left} -lefthash <hash> -righthash=20
<hash><path> <profile> # once for each file that is not skipped

=E2=80=93 basically, a plumbing-style CLI, but that isn=E2=80=99t exactly e=
legant. It=20
would have been a quick win, had Unison already provided the necessary=20
functionality =E2=80=93 but if I need to modify Unison anyway, it=E2=80=99s=
 not worth=20
the effort. Better turn it into a library with a somewhat well-defined=20
API that a frontend can call.

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

I haven=E2=80=99t dug deeply yet into the Objective-C to OCaml bindings, bu=
t I=20
see the Mac GUI does a few things involving thread creation and the=20
like, which I interpret to mean that it=E2=80=99s not as simple as a few=20
function/method calls. But with the assumption of the clean universal=20
API, this would be my preferred architecture.

So challenges for me would be:

* compiling Unison for Android in the first place (through one of Greg=E2=
=80=99s=20
links I discovered https://urldefense.com/v3/__https://github.com/vouillon/=
opam-android-repository__;!!IBzWLUs!XRYhymUdJQzornokn_snO3BE4GBc1BNVFDOcLc6=
QSiwC2mBN4pgM4wOAEUhRAbtZAHdniwJz7-lQCGy0_CmWOC64ysEnA0af$=20=20
and just saw that Jer=C3=B4me, the author, is also a Unison contributor and=
=20
even mentions Unison in one of the examples)

* figuring out how the Mac GUI interfaces with the rest of the Unison code

* figuring out if I can just call OCaml code directly from Java via JNI,=20
or if I need to first create a C wrapper around it

* if necessary, write the C wrapper

* get the toolchain to build a library of the OCaml code =E2=80=93 and the =
C=20
wrapper, if necessary

After that, I would build the Android UI around the library =E2=80=93 after=
=20
mastering the previous challenges, that part would just be routine.

--------------Mmkxs70N5DE3TqmYljN6jZtG
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF-8=
">
  </head>
  <body>
    <pre class=3D"moz-quote-pre" wrap=3D"">On Tue, 7 Feb 2023 15:26:35 +010=
0, T=C3=B5ivo Leedj=C3=A4rv wrote:

</pre>
    <blockquote type=3D"cite">
      <blockquote type=3D"cite" style=3D"color: #007cff;">
        <pre class=3D"moz-quote-pre" wrap=3D"">Option 1: recompile the Unis=
on binary (with only the text UI) for
Android and call that from the GUI.
</pre>
      </blockquote>
      <pre class=3D"moz-quote-pre" wrap=3D"">I know this or something simil=
ar has been done
(<a class=3D"moz-txt-link-freetext" href=3D"https://urldefense.com/v3/__htt=
ps://github.com/bcpierce00/unison/wiki/Software-for-use-with-Unison__;!!IBz=
WLUs!RLHa3A2snTpIeRCQOWDMiu0DNPhEWg-3ZTB2XetsviJmlWbRwyWXiM3q1DrmXcm6ICeg-k=
2sgkiTn07YNd5e84Q_7oQ$">https://urldefense.com/v3/__https://github.com/bcpi=
erce00/unison/wiki/Software-for-use-with-Unison__;!!IBzWLUs!RLHa3A2snTpIeRC=
QOWDMiu0DNPhEWg-3ZTB2XetsviJmlWbRwyWXiM3q1DrmXcm6ICeg-k2sgkiTn07YNd5e84Q_7o=
Q$</a>=20
) but I can't see this being a long-term stable and flexible solution.</pre>
    </blockquote>
    Indeed, even the author says: =E2=80=9C<strong>Caution:</strong> Althou=
gh I
    use Gunison daily, it is less reliable than Unison
    itself (and will always be, if only because it parses Unison=E2=80=99s
    human-readable
    output).=E2=80=9D That is an issue with any CLI, unless it explicitly
    distinguishes between what git calls plumbing and porcelain =E2=80=93
    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=3D"cite">
      <pre class=3D"moz-quote-pre" wrap=3D"">Option A: linking everything i=
nto 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=3D"cite">
      <pre class=3D"moz-quote-pre" wrap=3D"">Option B: some kind of IPC wit=
h 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
      &lt;profile&gt;</p>
    <p>unison {-left-to-right|-right-to-left} -lefthash &lt;hash&gt;
      -righthash &lt;hash&gt;&lt;path&gt; &lt;profile&gt; # once for
      each file that is not skipped</p>
    <p>=E2=80=93 basically, a plumbing-style CLI, but that isn=E2=80=99t ex=
actly
      elegant. It would have been a quick win, had Unison already
      provided the necessary functionality =E2=80=93 but if I need to modify
      Unison anyway, it=E2=80=99s 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=3D"cite">
      <pre class=3D"moz-quote-pre" wrap=3D"">As you can see, option A is al=
ready 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=E2=80=99t dug deeply yet into the Objective-C to OCaml bindi=
ngs,
      but I see the Mac GUI does a few things involving thread creation
      and the like, which I interpret to mean that it=E2=80=99s not as simp=
le 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=E2=80=99s links I discovered
      <a class=3D"moz-txt-link-freetext" href=3D"https://urldefense.com/v3/=
__https://github.com/vouillon/opam-android-repository__;!!IBzWLUs!XRYhymUdJ=
Qzornokn_snO3BE4GBc1BNVFDOcLc6QSiwC2mBN4pgM4wOAEUhRAbtZAHdniwJz7-lQCGy0_CmW=
OC64ysEnA0af$">https://github.com/vouillon/opam-android-repository</a> and =
just saw
      that Jer=C3=B4me, 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 =E2=80=93 a=
nd
      the C wrapper, if necessary</p>
    <p>After that, I would build the Android UI around the library =E2=80=93
      after mastering the previous challenges, that part would just be
      routine.<br>
    </p>
  </body>
</html>

--------------Mmkxs70N5DE3TqmYljN6jZtG--

--===============3710375061350932993==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Unison-hackers mailing list
[email protected]
https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers

--===============3710375061350932993==--