From bcpierce at cis.upenn.edu Sat Feb 1 07:28:28 2020 From: bcpierce at cis.upenn.edu (Benjamin C. Pierce) Date: Sat, 1 Feb 2020 07:28:28 -0500 Subject: [Unison-hackers] UI patches, build script In-Reply-To: <20200201043117.GA61419@localhost> References: <20191216221534.wu3poydzumk2j2nn@localhost> <20200130012215.GC1050@localhost> <20200201043117.GA61419@localhost> Message-ID: I did try applying the patch, but I had trouble getting it to work. (This is not a big surprise: it was the first time I?d tried patching with git.) git am --signoff < temp1.patch Applying: Test fix for confusing 'stop reconciling' UI bug error: patch failed: src/uitext.ml:607 error: src/uitext.ml: patch does not apply Unless there?s something obvious I?m doing wrong, a PR (or two, since your other fixes also seem useful) would probably be smoother. - B > On Jan 31, 2020, at 11:31 PM, frederik at ofb.net wrote: > > Thank you Benjamin. I'm not sure why a PR would make it easier, is > that like a digital signature or something? There are presumably > comments and other things that you would want to clean up by hand. I > can do it, but I'm guessing you want only the first patch. > > The comment in the second patch describes it as a "work in progress". > It tries to fix some behavior that was added recently with all the > "matching" predicates, in particular "%", but other commands need to > be changed to make them consistent. The current behavior is confusing > to me because the predicates don't apply to the current file, only the > ones after. So if you want to do something for every file, you have to > treat the first one differently from 2..n: > > $ unison a ssh://thutmose/a > Unison 2.51.2 (ocaml 4.08.1): Contacting server... > Connected [//ptolemy//home/frederik/a -> //thutmose//home/frederik/a] > Looking for changes > Waiting for changes from server > Reconciling changes > > local thutmose > new file ----> baz [f] L # list all changes > new file ----> baz > new file ----> foo > new file ----> baz [f] 1 # match all changes propagating -> > Enabling matching condition > new file ----> baz [f] / # skip matching files > new file ----> baz [f] L # foo is skipped, but not baz > new file ----> baz > > I just verified that I can apparently fix this by changing "rest" to > "ril" in "actOnMatching", but you might want to check with whoever > wrote that code (G.raud?) to make sure this is the right thing to do. > The new patch is number 3 here > https://github.com/navarum/tweaks/tree/master/unison/patches > > Thanks, > > Frederick > > On Fri, Jan 31, 2020 at 08:44:30PM -0500, Benjamin C. Pierce wrote: >> This does look like an improvement. Would you mind packaging it as a pull request? >> >> Thank you! >> >> - Benjamin >> >>> On Jan 29, 2020, at 8:22 PM, frederik at ofb.net wrote: >>> >>> I'm not sure if my emails are getting through here, but I created some patches to attempt to correct the UI behavior which I found confusing. I thought maybe I should share them in case they are useful: >>> >>> https://github.com/navarum/tweaks/tree/master/unison/patches >>> >>> The same repo contains a build script which I use to deploy Unison across different platforms. It builds a fixed version of Unison against a fixed version of OCaml. This makes it easier for me to run Unison between (say) Raspbian and Arch. Comments welcome. >>> >>> Best wishes, >>> >>> Frederick >>> >>> On Mon, Dec 16, 2019 at 02:15:34PM -0800, frederik at ofb.net wrote: >>>> Dear Unison hackers, >>>> >>>> I think I've mentioned this before, but often when using Unison I want to take a break from answering questions and just reconcile the changes that I've selected. For example in the following interaction >>>> >>>> new file <==== new file R/Makeconf [f] < >>>> new file <-?-> new file asound.conf [] s >>>> >>>> Proceed with propagating updates? [] y >>>> >>>> I selected that R/Makeconf should be propagated in one direction. Then I perused the increasingly longer list of commands and found one that looks appropriate: >>>> >>>> s stop reconciling and go to the proceed menu >>>> >>>> I'm not sure what the "proceed menu" is, but since I selected only one update I'm pretty sure that only one thing is going to happen when I "stop reconciling" and allow Unison to "proceed". However, when I hit "s" and "y" then Unison proceeds to copy a whole bunch of stuff that I didn't ask for, and I have to Ctrl-C, which doesn't even do anything, so then I have to Ctrl-Z Ctrl-C, but meanwhile a lot of files have been copied, generally making a mess that I have to spend time cleaning up. Here's a fuller summary: http://ix.io/24Dn >>>> >>>> By contrast, if I hit "/" at every prompt, to skip to the next item, then nothing is propagated. >>>> >>>> My questions: Is my use case somehow unusual? Where did I go wrong? Or is it OK for all users to have an experience like this when learning how to use your program? >>>> >>>> And what exactly does 's' do, and why doesn't it have a more accurate description in the UI? >>>> >>>> Thanks, >>>> >>>> Frederick >>>> >>> _______________________________________________ >>> Unison-hackers mailing list >>> Unison-hackers at LISTS.SEAS.UPENN.EDU >>> https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers >> >> _______________________________________________ >> Unison-hackers mailing list >> Unison-hackers at LISTS.SEAS.UPENN.EDU >> https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers >> > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at LISTS.SEAS.UPENN.EDU > https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederik at ofb.net Sat Feb 1 08:01:21 2020 From: frederik at ofb.net (frederik at ofb.net) Date: Sat, 1 Feb 2020 05:01:21 -0800 Subject: [Unison-hackers] UI patches, build script In-Reply-To: References: <20191216221534.wu3poydzumk2j2nn@localhost> <20200130012215.GC1050@localhost> <20200201043117.GA61419@localhost> Message-ID: <20200201130121.GC61419@localhost> The following steps work for me: $ git clone https://github.com/navarum/tweaks Cloning into 'tweaks'... remote: Enumerating objects: 27, done. remote: Counting objects: 100% (27/27), done. remote: Compressing objects: 100% (20/20), done. remote: Total 469 (delta 7), reused 20 (delta 5), pack-reused 442 Receiving objects: 100% (469/469), 94.89 KiB | 689.00 KiB/s, done. Resolving deltas: 100% (247/247), done. $ git clone https://github.com/bcpierce00/unison.git Cloning into 'unison'... remote: Enumerating objects: 9, done. remote: Counting objects: 100% (9/9), done. remote: Compressing objects: 100% (9/9), done. remote: Total 8959 (delta 2), reused 2 (delta 0), pack-reused 8950 Receiving objects: 100% (8959/8959), 14.00 MiB | 7.41 MiB/s, done. Resolving deltas: 100% (6842/6842), done. $ cd unison $ git config user.name "Frederick Eaton"; git config user.email "frederik at ofb.net" $ git am --signoff ../tweaks/unison/patches/000*.patch Applying: Test fix for confusing 'stop reconciling' UI bug Applying: Include current file in percent action Applying: try to fix actOnMatching I'm not sure what could have gone wrong; note they have to be applied in order. Thank you, Frederick On Sat, Feb 01, 2020 at 07:28:28AM -0500, Benjamin C. Pierce wrote: >I did try applying the patch, but I had trouble getting it to work. (This is not a big surprise: it was the first time I?d tried patching with git.) > >git am --signoff < temp1.patch > >Applying: Test fix for confusing 'stop reconciling' UI bug >error: patch failed: src/uitext.ml:607 >error: src/uitext.ml: patch does not apply > >Unless there?s something obvious I?m doing wrong, a PR (or two, since your other fixes also seem useful) would probably be smoother. > > - B > >> On Jan 31, 2020, at 11:31 PM, frederik at ofb.net wrote: >> >> Thank you Benjamin. I'm not sure why a PR would make it easier, is >> that like a digital signature or something? There are presumably >> comments and other things that you would want to clean up by hand. I >> can do it, but I'm guessing you want only the first patch. >> >> The comment in the second patch describes it as a "work in progress". >> It tries to fix some behavior that was added recently with all the >> "matching" predicates, in particular "%", but other commands need to >> be changed to make them consistent. The current behavior is confusing >> to me because the predicates don't apply to the current file, only the >> ones after. So if you want to do something for every file, you have to >> treat the first one differently from 2..n: >> >> $ unison a ssh://thutmose/a >> Unison 2.51.2 (ocaml 4.08.1): Contacting server... >> Connected [//ptolemy//home/frederik/a -> //thutmose//home/frederik/a] >> Looking for changes >> Waiting for changes from server >> Reconciling changes >> >> local thutmose >> new file ----> baz [f] L # list all changes >> new file ----> baz >> new file ----> foo >> new file ----> baz [f] 1 # match all changes propagating -> >> Enabling matching condition >> new file ----> baz [f] / # skip matching files >> new file ----> baz [f] L # foo is skipped, but not baz >> new file ----> baz >> >> I just verified that I can apparently fix this by changing "rest" to >> "ril" in "actOnMatching", but you might want to check with whoever >> wrote that code (G.raud?) to make sure this is the right thing to do. >> The new patch is number 3 here >> https://github.com/navarum/tweaks/tree/master/unison/patches >> >> Thanks, >> >> Frederick >> >> On Fri, Jan 31, 2020 at 08:44:30PM -0500, Benjamin C. Pierce wrote: >>> This does look like an improvement. Would you mind packaging it as a pull request? >>> >>> Thank you! >>> >>> - Benjamin >>> >>>> On Jan 29, 2020, at 8:22 PM, frederik at ofb.net wrote: >>>> >>>> I'm not sure if my emails are getting through here, but I created some patches to attempt to correct the UI behavior which I found confusing. I thought maybe I should share them in case they are useful: >>>> >>>> https://github.com/navarum/tweaks/tree/master/unison/patches >>>> >>>> The same repo contains a build script which I use to deploy Unison across different platforms. It builds a fixed version of Unison against a fixed version of OCaml. This makes it easier for me to run Unison between (say) Raspbian and Arch. Comments welcome. >>>> >>>> Best wishes, >>>> >>>> Frederick >>>> >>>> On Mon, Dec 16, 2019 at 02:15:34PM -0800, frederik at ofb.net wrote: >>>>> Dear Unison hackers, >>>>> >>>>> I think I've mentioned this before, but often when using Unison I want to take a break from answering questions and just reconcile the changes that I've selected. For example in the following interaction >>>>> >>>>> new file <==== new file R/Makeconf [f] < >>>>> new file <-?-> new file asound.conf [] s >>>>> >>>>> Proceed with propagating updates? [] y >>>>> >>>>> I selected that R/Makeconf should be propagated in one direction. Then I perused the increasingly longer list of commands and found one that looks appropriate: >>>>> >>>>> s stop reconciling and go to the proceed menu >>>>> >>>>> I'm not sure what the "proceed menu" is, but since I selected only one update I'm pretty sure that only one thing is going to happen when I "stop reconciling" and allow Unison to "proceed". However, when I hit "s" and "y" then Unison proceeds to copy a whole bunch of stuff that I didn't ask for, and I have to Ctrl-C, which doesn't even do anything, so then I have to Ctrl-Z Ctrl-C, but meanwhile a lot of files have been copied, generally making a mess that I have to spend time cleaning up. Here's a fuller summary: http://ix.io/24Dn >>>>> >>>>> By contrast, if I hit "/" at every prompt, to skip to the next item, then nothing is propagated. >>>>> >>>>> My questions: Is my use case somehow unusual? Where did I go wrong? Or is it OK for all users to have an experience like this when learning how to use your program? >>>>> >>>>> And what exactly does 's' do, and why doesn't it have a more accurate description in the UI? >>>>> >>>>> Thanks, >>>>> >>>>> Frederick >>>>> >>>> _______________________________________________ >>>> Unison-hackers mailing list >>>> Unison-hackers at LISTS.SEAS.UPENN.EDU >>>> https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers >>> >>> _______________________________________________ >>> Unison-hackers mailing list >>> Unison-hackers at LISTS.SEAS.UPENN.EDU >>> https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers >>> >> _______________________________________________ >> Unison-hackers mailing list >> Unison-hackers at LISTS.SEAS.UPENN.EDU >> https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers > >_______________________________________________ >Unison-hackers mailing list >Unison-hackers at LISTS.SEAS.UPENN.EDU >https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers From frederik at ofb.net Sat Feb 1 08:17:08 2020 From: frederik at ofb.net (frederik at ofb.net) Date: Sat, 1 Feb 2020 05:17:08 -0800 Subject: [Unison-hackers] UI patches, build script In-Reply-To: <20200201130121.GC61419@localhost> References: <20191216221534.wu3poydzumk2j2nn@localhost> <20200130012215.GC1050@localhost> <20200201043117.GA61419@localhost> <20200201130121.GC61419@localhost> Message-ID: <20200201131708.GD61419@localhost> (by the way, Navarum is a pseudonym - I'm not sure if that's weird, or normal, or what. I imagine if you're signing off then it doesn't really matter, and I hereby relinquish all copyright to my patches, dust to dust, and so on) On Sat, Feb 01, 2020 at 05:01:21AM -0800, frederik at ofb.net wrote: >The following steps work for me: > > $ git clone https://github.com/navarum/tweaks > Cloning into 'tweaks'... > remote: Enumerating objects: 27, done. > remote: Counting objects: 100% (27/27), done. > remote: Compressing objects: 100% (20/20), done. > remote: Total 469 (delta 7), reused 20 (delta 5), pack-reused 442 > Receiving objects: 100% (469/469), 94.89 KiB | 689.00 KiB/s, done. > Resolving deltas: 100% (247/247), done. > $ git clone https://github.com/bcpierce00/unison.git > Cloning into 'unison'... > remote: Enumerating objects: 9, done. > remote: Counting objects: 100% (9/9), done. > remote: Compressing objects: 100% (9/9), done. > remote: Total 8959 (delta 2), reused 2 (delta 0), pack-reused 8950 > Receiving objects: 100% (8959/8959), 14.00 MiB | 7.41 MiB/s, done. > Resolving deltas: 100% (6842/6842), done. > $ cd unison > $ git config user.name "Frederick Eaton"; git config user.email "frederik at ofb.net" > $ git am --signoff ../tweaks/unison/patches/000*.patch > Applying: Test fix for confusing 'stop reconciling' UI bug > Applying: Include current file in percent action > Applying: try to fix actOnMatching > >I'm not sure what could have gone wrong; note they have to be applied in order. > >Thank you, > >Frederick > >On Sat, Feb 01, 2020 at 07:28:28AM -0500, Benjamin C. Pierce wrote: >>I did try applying the patch, but I had trouble getting it to work. (This is not a big surprise: it was the first time I?d tried patching with git.) >> >>git am --signoff < temp1.patch >> >>Applying: Test fix for confusing 'stop reconciling' UI bug >>error: patch failed: src/uitext.ml:607 >>error: src/uitext.ml: patch does not apply >> >>Unless there?s something obvious I?m doing wrong, a PR (or two, since your other fixes also seem useful) would probably be smoother. >> >> - B >> >>>On Jan 31, 2020, at 11:31 PM, frederik at ofb.net wrote: >>> >>>Thank you Benjamin. I'm not sure why a PR would make it easier, is >>>that like a digital signature or something? There are presumably >>>comments and other things that you would want to clean up by hand. I >>>can do it, but I'm guessing you want only the first patch. >>> >>>The comment in the second patch describes it as a "work in progress". >>>It tries to fix some behavior that was added recently with all the >>>"matching" predicates, in particular "%", but other commands need to >>>be changed to make them consistent. The current behavior is confusing >>>to me because the predicates don't apply to the current file, only the >>>ones after. So if you want to do something for every file, you have to >>>treat the first one differently from 2..n: >>> >>> $ unison a ssh://thutmose/a >>> Unison 2.51.2 (ocaml 4.08.1): Contacting server... >>> Connected [//ptolemy//home/frederik/a -> //thutmose//home/frederik/a] >>> Looking for changes >>> Waiting for changes from server >>> Reconciling changes >>> >>> local thutmose >>> new file ----> baz [f] L # list all changes >>> new file ----> baz >>> new file ----> foo >>> new file ----> baz [f] 1 # match all changes propagating -> >>> Enabling matching condition >>> new file ----> baz [f] / # skip matching files >>> new file ----> baz [f] L # foo is skipped, but not baz >>> new file ----> baz >>> >>>I just verified that I can apparently fix this by changing "rest" to >>>"ril" in "actOnMatching", but you might want to check with whoever >>>wrote that code (G.raud?) to make sure this is the right thing to do. >>>The new patch is number 3 here >>>https://github.com/navarum/tweaks/tree/master/unison/patches >>> >>>Thanks, >>> >>>Frederick >>> >>>On Fri, Jan 31, 2020 at 08:44:30PM -0500, Benjamin C. Pierce wrote: >>>>This does look like an improvement. Would you mind packaging it as a pull request? >>>> >>>>Thank you! >>>> >>>> - Benjamin >>>> >>>>>On Jan 29, 2020, at 8:22 PM, frederik at ofb.net wrote: >>>>> >>>>>I'm not sure if my emails are getting through here, but I created some patches to attempt to correct the UI behavior which I found confusing. I thought maybe I should share them in case they are useful: >>>>> >>>>>https://github.com/navarum/tweaks/tree/master/unison/patches >>>>> >>>>>The same repo contains a build script which I use to deploy Unison across different platforms. It builds a fixed version of Unison against a fixed version of OCaml. This makes it easier for me to run Unison between (say) Raspbian and Arch. Comments welcome. >>>>> >>>>>Best wishes, >>>>> >>>>>Frederick >>>>> >>>>>On Mon, Dec 16, 2019 at 02:15:34PM -0800, frederik at ofb.net wrote: >>>>>>Dear Unison hackers, >>>>>> >>>>>>I think I've mentioned this before, but often when using Unison I want to take a break from answering questions and just reconcile the changes that I've selected. For example in the following interaction >>>>>> >>>>>> new file <==== new file R/Makeconf [f] < >>>>>> new file <-?-> new file asound.conf [] s >>>>>> >>>>>> Proceed with propagating updates? [] y >>>>>> >>>>>>I selected that R/Makeconf should be propagated in one direction. Then I perused the increasingly longer list of commands and found one that looks appropriate: >>>>>> >>>>>> s stop reconciling and go to the proceed menu >>>>>> >>>>>>I'm not sure what the "proceed menu" is, but since I selected only one update I'm pretty sure that only one thing is going to happen when I "stop reconciling" and allow Unison to "proceed". However, when I hit "s" and "y" then Unison proceeds to copy a whole bunch of stuff that I didn't ask for, and I have to Ctrl-C, which doesn't even do anything, so then I have to Ctrl-Z Ctrl-C, but meanwhile a lot of files have been copied, generally making a mess that I have to spend time cleaning up. Here's a fuller summary: http://ix.io/24Dn >>>>>> >>>>>>By contrast, if I hit "/" at every prompt, to skip to the next item, then nothing is propagated. >>>>>> >>>>>>My questions: Is my use case somehow unusual? Where did I go wrong? Or is it OK for all users to have an experience like this when learning how to use your program? >>>>>> >>>>>>And what exactly does 's' do, and why doesn't it have a more accurate description in the UI? >>>>>> >>>>>>Thanks, >>>>>> >>>>>>Frederick >>>>>> >>>>>_______________________________________________ >>>>>Unison-hackers mailing list >>>>>Unison-hackers at LISTS.SEAS.UPENN.EDU >>>>>https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers >>>> >>>>_______________________________________________ >>>>Unison-hackers mailing list >>>>Unison-hackers at LISTS.SEAS.UPENN.EDU >>>>https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers >>>> >>>_______________________________________________ >>>Unison-hackers mailing list >>>Unison-hackers at LISTS.SEAS.UPENN.EDU >>>https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers >> > >>_______________________________________________ >>Unison-hackers mailing list >>Unison-hackers at LISTS.SEAS.UPENN.EDU >>https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers > >_______________________________________________ >Unison-hackers mailing list >Unison-hackers at LISTS.SEAS.UPENN.EDU >https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers From steph at glondu.net Wed Feb 19 08:53:56 2020 From: steph at glondu.net (=?UTF-8?Q?St=c3=a9phane_Glondu?=) Date: Wed, 19 Feb 2020 14:53:56 +0100 Subject: [Unison-hackers] Exploring alternatives to OCaml's marshalling Message-ID: <9490f186-e190-fb26-f7d5-e3b4bdfc2b90@glondu.net> Hello, Currently, Unison depends on OCaml's marshalling which turns out to be not very stable across OCaml versions. As a consequence, Unison may be incompatible with itself when compiled with a different OCaml version. This makes offering a Debian package for Unison a nightmare (see for example [1] or [2]). [1] https://github.com/bcpierce00/unison/issues/94 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946041 Moreover, stability across versions is not a goal of OCaml's marshalling, which is why I think Unison should switch to something else. I can imagine several alternatives, including: 1) reimplement (or embed) one fixed version of OCaml's marshalling inside Unison, keeping a type-independent strategy; 2) implement a different type-independent marshalling function (using the Obj module); 3) implement type-oriented and "explicit" marshalling. All of them require some kind of "monitoring" of the evolution of the OCaml language or implementation. I believe 1) and 2) require monitoring of low-level details of the OCaml implementation, something an avid OCaml follower may do, but not something we can impose on Unison contributors. With 3), on the contrary, the language (and its tooling) can help with adapting to a new version of OCaml. So I decided to explore 3). The idea is to identify all types that need marshalling, and implement type-safe (un)marshalling functions for these types. This can be done by annotating each such type with an attribute that a PPX preprocessor would use to generate the functions. There exists already several such PPXs; as suggested in [1], I looked into ppx_protobuf and ppx_bin_prot (available in opam). Unison is easily adapted to both. However, ppx_protobuf uses "bytes" as buffers and does not support bigarrays or reading/writing directly to a channel, so it is impossible to handle structures that are bigger than Sys.max_string_length, which is ridiculously low on 32 bits architectures (16MB IIRC). And I easily get archives bigger than that. Ppx_bin_prot uses bigarrays as buffers and does not suffer from the Sys.max_string_length limitation, but uses a less standard binary format (albeit specified) and has much more dependencies (another Debian packaging nightmare). Being part of Jane Street stack, I am somewhat confident that it will be properly maintained in the future. But who knows. In both cases, the compatibility problem is shifted to the marshalling libraries. Contrarily to OCaml's marshalling, these libraries seem to aim stability. But, again, who knows. I've pushed both versions to my fork on GitHub: https://github.com/glondu/unison/tree/protobuf https://github.com/glondu/unison/tree/bin_prot I've been using the protobuf branch [between two (64-bit) Linux hosts] for 15 days now with no issues, so the principle of the transformation (which is the same in the bin_prot branch) looks sound. However, because of the 32-bit limitation, I've been focusing my efforts on the bin_prot branch lately. An alternative would be to change ppx_protobuf to use bigarrays. I have not tested on OSX or Windows. I am now seeking feedback about my methodology and implementation. Cheers, -- St?phane