From andrex at utexas.edu Fri Sep 4 10:00:14 2020 From: andrex at utexas.edu (Andrew Schulman) Date: Fri, 04 Sep 2020 10:00:14 -0400 Subject: [Unison-hackers] OCaml version mismatch breaks Unison 2.48.4 References: <22fnkfd80djs5gh3fg2nvbfcg2gs8ck31f@4ax.com> <0265c23f-c4c1-1af5-bfc9-3da59c7446ab@glondu.net> <6b2569ec-c894-f918-22eb-2c755d0876d5@glondu.net> Message-ID: > Now, what I will do (I am the Unison maintainer in Debian) is embed the > OCaml version in the package name (e.g. unison-2.52+4.08.1) so that one > can have many combinations co-installed... but there will always be a > single OCaml version in the official Debian archive for a given suite. I'm willing to do this too for Cygwin. For now I'm planning to package unison2.48+4.04.2 unison2.48+4.08.1 but that can change. For the poor users who are trying to sync between, say, Cygwin and Debian, I think it would help if the package versions were the same in different distros. Then a user can just look and see that, for example, unison2.52+4.08.1 is available on both sides, and just install that and not have to worry about which OCaml versions are compatible with which others. So if you know which versions you're planning to package for Debian, please tell us here so I can package the same ones. And if the Unison maintainers from other distros are also reading this list, it'd be good if we all packaged the same versions. BTW according to David Allsop on the Cygwin list[1], the first incompatibility in OCaml's marshaling came in OCaml 4.08, and the next one is coming in 4.11, although that one may not matter for Unison. So we probably only need one pre-4.08 and one post-4.08 package for each Unison version. Andrew [1] https://cygwin.com/pipermail/cygwin/2020-September/246101.html From steph at glondu.net Sat Sep 5 01:47:48 2020 From: steph at glondu.net (=?UTF-8?Q?St=c3=a9phane_Glondu?=) Date: Sat, 5 Sep 2020 07:47:48 +0200 Subject: [Unison-hackers] OCaml version mismatch breaks Unison 2.48.4 In-Reply-To: References: <22fnkfd80djs5gh3fg2nvbfcg2gs8ck31f@4ax.com> <0265c23f-c4c1-1af5-bfc9-3da59c7446ab@glondu.net> <6b2569ec-c894-f918-22eb-2c755d0876d5@glondu.net> Message-ID: <78810a08-c00a-0d1b-f051-b4ed4c196f7c@glondu.net> Le 04/09/2020 ? 16:00, Andrew Schulman a ?crit?: >> Now, what I will do (I am the Unison maintainer in Debian) is embed the >> OCaml version in the package name (e.g. unison-2.52+4.08.1) so that one >> can have many combinations co-installed... but there will always be a >> single OCaml version in the official Debian archive for a given suite. > > I'm willing to do this too for Cygwin. For now I'm planning to package > > unison2.48+4.04.2 > unison2.48+4.08.1 > > but that can change. > > For the poor users who are trying to sync between, say, Cygwin and Debian, > I think it would help if the package versions were the same in different > distros. Then a user can just look and see that, for example, > unison2.52+4.08.1 is available on both sides, and just install that and not > have to worry about which OCaml versions are compatible with which others. > > So if you know which versions you're planning to package for Debian, please > tell us here so I can package the same ones. And if the Unison maintainers > from other distros are also reading this list, it'd be good if we all > packaged the same versions. At the moment, in testing/unstable, there is "unison-2.48" (compiled with OCaml 4.08.1). Since the next version of OCaml to be packaged in Debian will be 4.11.1 and unison-2.48 does not compile with it, I think I will let this unison-2.48 branch die and instead package the soon-to-be-released 2.52.0 as "unison-2.52+4.11.1". > BTW according to David Allsop on the Cygwin list[1], the first > incompatibility in OCaml's marshaling came in OCaml 4.08, and the next one > is coming in 4.11, although that one may not matter for Unison. So we > probably only need one pre-4.08 and one post-4.08 package for each Unison > version. My plan is to stop using OCaml marshalling altogether. This may introduce new dependencies, though, that I guess will have somehow to be packaged for Cygwin. What's your take on this? I am thinking about ppx_bin_prot (in opam, but has many dependencies), ppx_protobuf (in opam, less dependencies, but does not support bigarrays so it won't work on 32-bit) or maybe a custom ppx with no new dependencies. Cheers, -- St?phane From bcpierce at cis.upenn.edu Sat Sep 5 20:19:03 2020 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Sat, 5 Sep 2020 20:19:03 -0400 Subject: [Unison-hackers] OCaml version mismatch breaks Unison 2.48.4 In-Reply-To: <78810a08-c00a-0d1b-f051-b4ed4c196f7c@glondu.net> References: <22fnkfd80djs5gh3fg2nvbfcg2gs8ck31f@4ax.com> <0265c23f-c4c1-1af5-bfc9-3da59c7446ab@glondu.net> <6b2569ec-c894-f918-22eb-2c755d0876d5@glondu.net> <78810a08-c00a-0d1b-f051-b4ed4c196f7c@glondu.net> Message-ID: <638E2DE3-DD35-4A89-9EAF-E21710BA5553@cis.upenn.edu> > My plan is to stop using OCaml marshalling altogether. This may > introduce new dependencies, though, that I guess will have somehow to be > packaged for Cygwin. What's your take on this? I am thinking about > ppx_bin_prot (in opam, but has many dependencies), ppx_protobuf (in > opam, less dependencies, but does not support bigarrays so it won't work > on 32-bit) or maybe a custom ppx with no new dependencies. I like "no new dependencies?! -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrex at utexas.edu Tue Sep 8 11:29:40 2020 From: andrex at utexas.edu (Andrew Schulman) Date: Tue, 08 Sep 2020 11:29:40 -0400 Subject: [Unison-hackers] OCaml version mismatch breaks Unison 2.48.4 References: <22fnkfd80djs5gh3fg2nvbfcg2gs8ck31f@4ax.com> <0265c23f-c4c1-1af5-bfc9-3da59c7446ab@glondu.net> <6b2569ec-c894-f918-22eb-2c755d0876d5@glondu.net> <78810a08-c00a-0d1b-f051-b4ed4c196f7c@glondu.net> Message-ID: > Le 04/09/2020 ? 16:00, Andrew Schulman a ?crit?: > >> Now, what I will do (I am the Unison maintainer in Debian) is embed the > >> OCaml version in the package name (e.g. unison-2.52+4.08.1) so that one > >> can have many combinations co-installed... but there will always be a > >> single OCaml version in the official Debian archive for a given suite. > > > > I'm willing to do this too for Cygwin. For now I'm planning to package > > > > unison2.48+4.04.2 > > unison2.48+4.08.1 > > > > but that can change. > > > > For the poor users who are trying to sync between, say, Cygwin and Debian, > > I think it would help if the package versions were the same in different > > distros. Then a user can just look and see that, for example, > > unison2.52+4.08.1 is available on both sides, and just install that and not > > have to worry about which OCaml versions are compatible with which others. > > > > So if you know which versions you're planning to package for Debian, please > > tell us here so I can package the same ones. And if the Unison maintainers > > from other distros are also reading this list, it'd be good if we all > > packaged the same versions. > > At the moment, in testing/unstable, there is "unison-2.48" (compiled > with OCaml 4.08.1). Since the next version of OCaml to be packaged in > Debian will be 4.11.1 and unison-2.48 does not compile with it, I think > I will let this unison-2.48 branch die and instead package the > soon-to-be-released 2.52.0 as "unison-2.52+4.11.1". Good, I'll do the same. Maybe other distros will follow. > > BTW according to David Allsop on the Cygwin list[1], the first > > incompatibility in OCaml's marshaling came in OCaml 4.08, and the next one > > is coming in 4.11, although that one may not matter for Unison. So we > > probably only need one pre-4.08 and one post-4.08 package for each Unison > > version. > > My plan is to stop using OCaml marshalling altogether. This may > introduce new dependencies, though, that I guess will have somehow to be > packaged for Cygwin. What's your take on this? I am thinking about > ppx_bin_prot (in opam, but has many dependencies), ppx_protobuf (in > opam, less dependencies, but does not support bigarrays so it won't work > on 32-bit) or maybe a custom ppx with no new dependencies. Not sure, as I don't maintain any OCaml packages for Cygwin, and am not sure of the right way to package them. So like Benjamin, I'd prefer fewer dependencies. But do what you need to do, we'll figure it out. Andrew From steph at glondu.net Wed Sep 9 11:00:51 2020 From: steph at glondu.net (=?UTF-8?Q?St=c3=a9phane_Glondu?=) Date: Wed, 9 Sep 2020 17:00:51 +0200 Subject: [Unison-hackers] OCaml version mismatch breaks Unison 2.48.4 In-Reply-To: <638E2DE3-DD35-4A89-9EAF-E21710BA5553@cis.upenn.edu> References: <22fnkfd80djs5gh3fg2nvbfcg2gs8ck31f@4ax.com> <0265c23f-c4c1-1af5-bfc9-3da59c7446ab@glondu.net> <6b2569ec-c894-f918-22eb-2c755d0876d5@glondu.net> <78810a08-c00a-0d1b-f051-b4ed4c196f7c@glondu.net> <638E2DE3-DD35-4A89-9EAF-E21710BA5553@cis.upenn.edu> Message-ID: Le 06/09/2020 ? 02:19, Benjamin Pierce a ?crit?: >> My plan is to stop using OCaml marshalling altogether. This may >> introduce new dependencies, though, that I guess will have somehow to be >> packaged for Cygwin. What's your take on this? I am thinking about >> ppx_bin_prot (in opam, but has many dependencies), ppx_protobuf (in >> opam, less dependencies, but does not support bigarrays so it won't work >> on 32-bit) or maybe a custom ppx with no new dependencies. > > I like "no new dependencies?! I managed to rewrite the marshalling functions into something that does not depend on the OCaml version without introducing new dependencies: https://github.com/glondu/unison/tree/umarshal For now, I am testing it: I have started using it in my daily sync task. Other testers are welcome. In a few weeks (and after the release of 2.52.0), I will submit a merge request. Note that Unison uses Digest from OCaml standard library, which could change in theory (as is weak). In my opinion, that usage should also be left out if we want to be independent of the OCaml version. I propose to use SHA256 instead. What do you think? Cheers, -- St?phane From bcpierce at cis.upenn.edu Wed Sep 9 11:14:36 2020 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Wed, 9 Sep 2020 11:14:36 -0400 Subject: [Unison-hackers] OCaml version mismatch breaks Unison 2.48.4 In-Reply-To: References: <22fnkfd80djs5gh3fg2nvbfcg2gs8ck31f@4ax.com> <0265c23f-c4c1-1af5-bfc9-3da59c7446ab@glondu.net> <6b2569ec-c894-f918-22eb-2c755d0876d5@glondu.net> <78810a08-c00a-0d1b-f051-b4ed4c196f7c@glondu.net> <638E2DE3-DD35-4A89-9EAF-E21710BA5553@cis.upenn.edu> Message-ID: Fantastic! Changing from Digest to something more stable like SHA256 sounds reasonable, but would we expect any difference in performance? I believe the point of md5 was that it was cheap to compute even for huge amounts of data? From mikebohde at gmail.com Wed Sep 9 11:49:46 2020 From: mikebohde at gmail.com (Mike Bohde) Date: Wed, 9 Sep 2020 11:49:46 -0400 Subject: [Unison-hackers] OCaml version mismatch breaks Unison 2.48.4 In-Reply-To: References: <22fnkfd80djs5gh3fg2nvbfcg2gs8ck31f@4ax.com> <0265c23f-c4c1-1af5-bfc9-3da59c7446ab@glondu.net> <6b2569ec-c894-f918-22eb-2c755d0876d5@glondu.net> <78810a08-c00a-0d1b-f051-b4ed4c196f7c@glondu.net> <638E2DE3-DD35-4A89-9EAF-E21710BA5553@cis.upenn.edu> Message-ID: >From my understanding of the two methods SHA256 will be slower. If speed was the only concern sha1 and crc32 are objectively faster than even md5. If we were all dealing with the compute ability of machines 10 years ago or comparing datasets in the dozens of terabytes with massive changes I would be concerned. In casual to soho use I doubt there to be much of a difference that an average end user would notice. Realistically I do not see a problem with a synchronization comparison taking 10 or 20% more time. On Wed, Sep 9, 2020 at 11:14 AM Benjamin Pierce wrote: > Fantastic! > > Changing from Digest to something more stable like SHA256 sounds > reasonable, but would we expect any difference in performance? I believe > the point of md5 was that it was cheap to compute even for huge amounts of > data? > > _______________________________________________ > 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 bcpierce at cis.upenn.edu Wed Sep 9 13:30:46 2020 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Wed, 9 Sep 2020 13:30:46 -0400 Subject: [Unison-hackers] OCaml version mismatch breaks Unison 2.48.4 In-Reply-To: References: <22fnkfd80djs5gh3fg2nvbfcg2gs8ck31f@4ax.com> <0265c23f-c4c1-1af5-bfc9-3da59c7446ab@glondu.net> <6b2569ec-c894-f918-22eb-2c755d0876d5@glondu.net> <78810a08-c00a-0d1b-f051-b4ed4c196f7c@glondu.net> <638E2DE3-DD35-4A89-9EAF-E21710BA5553@cis.upenn.edu> Message-ID: <963A83FD-5681-4F8F-B308-4CD4EB092F6F@cis.upenn.edu> 10-20% more time is probably not a dealbreaker, but even that much will be a problem for some people: we regularly hear from folks whose first sync takes more than a day! > On Sep 9, 2020, at 11:49 AM, Mike Bohde wrote: > > From my understanding of the two methods SHA256 will be slower. If speed was the only concern sha1 and crc32 are objectively faster than even md5. If we were all dealing with the compute ability of machines 10 years ago or comparing datasets in the dozens of terabytes with massive changes I would be concerned. > In casual to soho use I doubt there to be much of a difference that an average end user would notice. Realistically I do not see a problem with a synchronization comparison taking 10 or 20% more time. > > On Wed, Sep 9, 2020 at 11:14 AM Benjamin Pierce > wrote: > Fantastic! > > Changing from Digest to something more stable like SHA256 sounds reasonable, but would we expect any difference in performance? I believe the point of md5 was that it was cheap to compute even for huge amounts of data? > > _______________________________________________ > 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 mikebohde at gmail.com Wed Sep 9 14:16:11 2020 From: mikebohde at gmail.com (Mike Bohde) Date: Wed, 9 Sep 2020 14:16:11 -0400 Subject: [Unison-hackers] OCaml version mismatch breaks Unison 2.48.4 In-Reply-To: <963A83FD-5681-4F8F-B308-4CD4EB092F6F@cis.upenn.edu> References: <22fnkfd80djs5gh3fg2nvbfcg2gs8ck31f@4ax.com> <0265c23f-c4c1-1af5-bfc9-3da59c7446ab@glondu.net> <6b2569ec-c894-f918-22eb-2c755d0876d5@glondu.net> <78810a08-c00a-0d1b-f051-b4ed4c196f7c@glondu.net> <638E2DE3-DD35-4A89-9EAF-E21710BA5553@cis.upenn.edu> <963A83FD-5681-4F8F-B308-4CD4EB092F6F@cis.upenn.edu> Message-ID: Benjamin, To get right to the point, you make a great tool. If there are things that can be done to make it faster awesome. However, sometimes in the name of sanity some decisions must be made. People do need to realize dealing with storage in scale takes time. My TrueNAS (FreeNAS) scrub takes four hours for my main pool. A sync to a new hard disk for my backup can take 10-12 hours between sum creation and copy. I do have an idea on how to make large pools and non-local storage faster. I'm not sure how feasible it would be to create independent source hash records and import them to save time would be. On Wed, Sep 9, 2020 at 1:31 PM Benjamin Pierce wrote: > 10-20% more time is probably not a dealbreaker, but even that much will be > a problem for some people: we regularly hear from folks whose first sync > takes more than a day! > > > On Sep 9, 2020, at 11:49 AM, Mike Bohde wrote: > > From my understanding of the two methods SHA256 will be slower. If speed > was the only concern sha1 and crc32 are objectively faster than even md5. > If we were all dealing with the compute ability of machines 10 years ago or > comparing datasets in the dozens of terabytes with massive changes I would > be concerned. > In casual to soho use I doubt there to be much of a difference that an > average end user would notice. Realistically I do not see a problem with a > synchronization comparison taking 10 or 20% more time. > > On Wed, Sep 9, 2020 at 11:14 AM Benjamin Pierce > wrote: > >> Fantastic! >> >> Changing from Digest to something more stable like SHA256 sounds >> reasonable, but would we expect any difference in performance? I believe >> the point of md5 was that it was cheap to compute even for huge amounts of >> data? >> >> _______________________________________________ >> 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 steph at glondu.net Sun Sep 13 03:08:33 2020 From: steph at glondu.net (=?UTF-8?Q?St=c3=a9phane_Glondu?=) Date: Sun, 13 Sep 2020 09:08:33 +0200 Subject: [Unison-hackers] OCaml version mismatch breaks Unison 2.48.4 In-Reply-To: References: <22fnkfd80djs5gh3fg2nvbfcg2gs8ck31f@4ax.com> <0265c23f-c4c1-1af5-bfc9-3da59c7446ab@glondu.net> <6b2569ec-c894-f918-22eb-2c755d0876d5@glondu.net> <78810a08-c00a-0d1b-f051-b4ed4c196f7c@glondu.net> <638E2DE3-DD35-4A89-9EAF-E21710BA5553@cis.upenn.edu> Message-ID: Le 09/09/2020 ? 17:14, Benjamin Pierce a ?crit?: > Fantastic! > > Changing from Digest to something more stable like SHA256 sounds reasonable, but would we expect any difference in performance? Probably. Note that I also expect some difference in performance with my changes in marshalling functions. In practice, the difference is imperceptible (in my use case, I/O is the limiting factor) and the archive size is even smaller. > I believe the point of md5 was that it was cheap to compute even for huge amounts of data? ... But it is easy to make collisions (probably not accidentally, though). In the case of Unison, if I understand correctly, that would mean potential changes not being detected in the case of an attack. Anyway, whatever the hash function, I think it should be more standardized than just "OCaml's Digest module". If we insist on no new dependencies (do we?), that hash function would have to be in Unison sources. And my marshalling implementation changes everything in an incompatible way, so it's in my opinion a good time to change the hash function. And as a person doing cryptography in my day job, I cannot imagine using MD-5 or SHA-1 today. CRC-32 could fit some purpose, but I don't think it's what we want here. Cheers, -- St?phane From bcpierce at cis.upenn.edu Sun Sep 13 12:47:05 2020 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Sun, 13 Sep 2020 12:47:05 -0400 Subject: [Unison-hackers] OCaml version mismatch breaks Unison 2.48.4 In-Reply-To: References: <22fnkfd80djs5gh3fg2nvbfcg2gs8ck31f@4ax.com> <0265c23f-c4c1-1af5-bfc9-3da59c7446ab@glondu.net> <6b2569ec-c894-f918-22eb-2c755d0876d5@glondu.net> <78810a08-c00a-0d1b-f051-b4ed4c196f7c@glondu.net> <638E2DE3-DD35-4A89-9EAF-E21710BA5553@cis.upenn.edu> Message-ID: > Anyway, whatever the hash function, I think it should be more > standardized than just "OCaml's Digest module". If we insist on no new > dependencies (do we?), that hash function would have to be in Unison > sources. Depends what you mean by ?insist?. :-) IMO, restricting Unison to depend only on the standard OCaml installation has served us well over the years by making it pretty easy for people who needed to compile from scratch to do so. But if the OCaml world has reached the point where there are really easy ways of satisfying dependencies on other packages (across all the platforms Unison runs on!), then I?d be happy to know about them. I?m a bit out of date on best practices. In any case, though, if we?re just talking about adding one file to the Unison distribution (and it has an appropriate license so that we can do so), then why wouldn?t we take that route? > And my marshalling implementation changes everything in an > incompatible way, so it's in my opinion a good time to change the hash > function. And as a person doing cryptography in my day job, I cannot > imagine using MD-5 or SHA-1 today. CRC-32 could fit some purpose, but I > don't think it's what we want here. If that?s your day job, I am very happy to follow your lead here! From chad at apartmentlines.com Sun Sep 13 13:40:36 2020 From: chad at apartmentlines.com (Chad Phillips) Date: Sun, 13 Sep 2020 10:40:36 -0700 Subject: [Unison-hackers] Orderly shutdown of Unison Message-ID: Cross-posting this from the users list, as I'm hoping to get some developer guidance in order to put together a PR: I've built a Pacemaker cluster with two nodes in an active/passive configuration, with the active node running the Unison service. The service runs continuously with 'watch' enabled, in order to sync files to another region. Both the Unison users's home directory and the sync'd files directory are on shared storage. During a failover from one node to another, this process is followed. 1. Stop Unison service on old node. 2. Unmount shared storage on old node. 3. Mount shared storage on new node. 4. Start Unison service on new node. This *mostly* works, but I sometimes get errors when starting Unison on the new node, mostly to do with corrupted archive files ('end of file exception'). I suspect this is due to the way the Unison service is stopped on the old node, which leaves the archive files in a corrupted state. Given that the Unison process is continuously running with 'watch', is there some recommended way to stop it such that the archives on both the sync source and destination are left in a clean state? Over on the user's list, Benjamin suggested that some code could be added to Unison to catch a signal that would then shut it down in an orderly way. I don't mind taking a crack at that, but I have zero experience in the Unison code base, so it would be helpful if someone could maybe give me some high-level tips about approach and where to start digging in the code? Chad -------------- next part -------------- An HTML attachment was scrubbed... URL: From steph at glondu.net Tue Sep 15 08:25:31 2020 From: steph at glondu.net (=?UTF-8?Q?St=c3=a9phane_Glondu?=) Date: Tue, 15 Sep 2020 14:25:31 +0200 Subject: [Unison-hackers] Release candidate for Unison 2.51.3 Message-ID: <8bf13720-ff11-0201-4099-95bf4a05cdae@glondu.net> Hello, I've just made a release candidate for the next version of Unison, which should be 2.51.3. Changes since 2.51.2: * Some nontrivial changes to profile parsing (G.raud Meyer) + ?=? has been considered whitespace until now: several following chars are considered as only one; trailing chars are discarded; any non emty sequence of char is splitting. This is non standard and leads to confusion, for example -ignore== ?Name .*=*? is valid when -ignore=?Name .*=*? is not, and worse -ignore=?Name *=? is the same as -ignore=?Name *?. The parser now takes just a single ?=? as delimiter after the option name. Other = characters are considered as part of the value being assigned to the option. * Numerous improvements to the text user-interface (G.raud Meyer) + New key-commands that restrict the display to a set of "matching" items: ones that are offering to propagate changes in a particular direction, conflicts, files to be merged, etc., plus several more useful key-commands. Type "?" to Unison to see all available commands. This version should be compatible with the previous one, 2.51.2, and compile with modern versions of OCaml. Both ends should be compiled with the same version of OCaml, though. You can download its sources at: https://github.com/bcpierce00/unison/releases/tag/v2.51.3_rc1 Please test and report any issues! Enjoy, -- St?phane From bcpierce at cis.upenn.edu Tue Sep 15 16:15:46 2020 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Tue, 15 Sep 2020 16:15:46 -0400 Subject: [Unison-hackers] Release candidate for Unison 2.51.3 In-Reply-To: <8bf13720-ff11-0201-4099-95bf4a05cdae@glondu.net> References: <8bf13720-ff11-0201-4099-95bf4a05cdae@glondu.net> Message-ID: <75700F90-5E9B-4C2F-8D29-C32E3BE812F2@cis.upenn.edu> On behalf of the whole community, many thanks to St?phane for getting this release out the door (and to Greg Troxel for a ton of curation on GitHub issues, etc.)!! - Benjamin > On Sep 15, 2020, at 8:25 AM, St?phane Glondu wrote: > > Hello, > > I've just made a release candidate for the next version of Unison, which > should be 2.51.3. > > Changes since 2.51.2: > * Some nontrivial changes to profile parsing (G.raud Meyer) > + ?=? has been considered whitespace until now: several > following chars are considered as only one; trailing chars are > discarded; any non emty sequence of char is splitting. This is > non standard and leads to confusion, for example -ignore== > ?Name .*=*? is valid when -ignore=?Name .*=*? is not, and > worse -ignore=?Name *=? is the same as -ignore=?Name *?. The > parser now takes just a single ?=? as delimiter after the > option name. Other = characters are considered as part of the > value being assigned to the option. > * Numerous improvements to the text user-interface (G.raud Meyer) > + New key-commands that restrict the display to a set of > "matching" items: ones that are offering to propagate changes > in a particular direction, conflicts, files to be merged, > etc., plus several more useful key-commands. Type "?" to > Unison to see all available commands. > > This version should be compatible with the previous one, 2.51.2, and > compile with modern versions of OCaml. Both ends should be compiled with > the same version of OCaml, though. > > You can download its sources at: > > https://github.com/bcpierce00/unison/releases/tag/v2.51.3_rc1 > > Please test and report any issues! > > > Enjoy, > > -- > St?phane > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at LISTS.SEAS.UPENN.EDU > https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers