From bcpierce at seas.upenn.edu Tue Oct 21 10:08:49 2014 From: bcpierce at seas.upenn.edu (bcpierce at seas.upenn.edu) Date: Tue, 21 Oct 2014 10:08:49 -0400 Subject: [Unison-hackers] [unison-svn] r532 - trunk/src Message-ID: <201410211408.s9LE8ncX003204@yaws.seas.upenn.edu> Author: bcpierce Date: 2014-10-21 10:08:49 -0400 (Tue, 21 Oct 2014) New Revision: 532 Modified: trunk/src/RECENTNEWS trunk/src/mkProjectInfo.ml Log: * Preparing for new beta release Modified: trunk/src/RECENTNEWS =================================================================== --- trunk/src/RECENTNEWS 2014-10-21 14:06:20 UTC (rev 531) +++ trunk/src/RECENTNEWS 2014-10-21 14:08:49 UTC (rev 532) @@ -1,3 +1,8 @@ +CHANGES FROM VERSION 2.48.0 + +* Preparing for new beta release + +------------------------------- CHANGES FROM VERSION 2.47.4 * Preparing for new beta release Modified: trunk/src/mkProjectInfo.ml =================================================================== --- trunk/src/mkProjectInfo.ml 2014-10-21 14:06:20 UTC (rev 531) +++ trunk/src/mkProjectInfo.ml 2014-10-21 14:08:49 UTC (rev 532) @@ -5,8 +5,8 @@ let projectName = "unison" let majorVersion = 2 -let minorVersion = 47 -let pointVersionOrigin = 526 (* Revision that corresponds to point version 0 *) +let minorVersion = 48 +let pointVersionOrigin = 531 (* Revision that corresponds to point version 0 *) (* Documentation: This is a program to construct a version of the form Major.Minor.Point, @@ -96,3 +96,4 @@ + From bcpierce at seas.upenn.edu Tue Oct 21 10:09:59 2014 From: bcpierce at seas.upenn.edu (bcpierce at seas.upenn.edu) Date: Tue, 21 Oct 2014 10:09:59 -0400 Subject: [Unison-hackers] [unison-svn] r533 - trunk/src Message-ID: <201410211409.s9LE9xqu003243@yaws.seas.upenn.edu> Author: bcpierce Date: 2014-10-21 10:09:58 -0400 (Tue, 21 Oct 2014) New Revision: 533 Modified: trunk/src/RECENTNEWS trunk/src/mkProjectInfo.ml Log: * Preparing for new beta release Modified: trunk/src/RECENTNEWS =================================================================== --- trunk/src/RECENTNEWS 2014-10-21 14:08:49 UTC (rev 532) +++ trunk/src/RECENTNEWS 2014-10-21 14:09:58 UTC (rev 533) @@ -1,3 +1,8 @@ +CHANGES FROM VERSION 2.48.-1 + +* Preparing for new beta release + +------------------------------- CHANGES FROM VERSION 2.48.0 * Preparing for new beta release Modified: trunk/src/mkProjectInfo.ml =================================================================== --- trunk/src/mkProjectInfo.ml 2014-10-21 14:08:49 UTC (rev 532) +++ trunk/src/mkProjectInfo.ml 2014-10-21 14:09:58 UTC (rev 533) @@ -6,7 +6,7 @@ let projectName = "unison" let majorVersion = 2 let minorVersion = 48 -let pointVersionOrigin = 531 (* Revision that corresponds to point version 0 *) +let pointVersionOrigin = 533 (* Revision that corresponds to point version 0 *) (* Documentation: This is a program to construct a version of the form Major.Minor.Point, @@ -97,3 +97,4 @@ + From bcpierce at seas.upenn.edu Tue Oct 21 10:10:27 2014 From: bcpierce at seas.upenn.edu (bcpierce at seas.upenn.edu) Date: Tue, 21 Oct 2014 10:10:27 -0400 Subject: [Unison-hackers] [unison-svn] r534 - in branches: . 2.48/src Message-ID: <201410211410.s9LEARQC003272@yaws.seas.upenn.edu> Author: bcpierce Date: 2014-10-21 10:10:26 -0400 (Tue, 21 Oct 2014) New Revision: 534 Added: branches/2.48/ branches/2.48/src/RECENTNEWS branches/2.48/src/mkProjectInfo.ml Removed: branches/2.48/src/RECENTNEWS branches/2.48/src/mkProjectInfo.ml Log: New release branch Deleted: branches/2.48/src/RECENTNEWS =================================================================== --- trunk/src/RECENTNEWS 2014-10-21 14:08:49 UTC (rev 532) +++ branches/2.48/src/RECENTNEWS 2014-10-21 14:10:26 UTC (rev 534) @@ -1,10 +0,0 @@ -CHANGES FROM VERSION 2.48.0 - -* Preparing for new beta release - -------------------------------- -CHANGES FROM VERSION 2.47.4 - -* Preparing for new beta release - -------------------------------- Copied: branches/2.48/src/RECENTNEWS (from rev 533, trunk/src/RECENTNEWS) =================================================================== --- branches/2.48/src/RECENTNEWS (rev 0) +++ branches/2.48/src/RECENTNEWS 2014-10-21 14:10:26 UTC (rev 534) @@ -0,0 +1,15 @@ +CHANGES FROM VERSION 2.48.-1 + +* Preparing for new beta release + +------------------------------- +CHANGES FROM VERSION 2.48.0 + +* Preparing for new beta release + +------------------------------- +CHANGES FROM VERSION 2.47.4 + +* Preparing for new beta release + +------------------------------- Deleted: branches/2.48/src/mkProjectInfo.ml =================================================================== --- trunk/src/mkProjectInfo.ml 2014-10-21 14:08:49 UTC (rev 532) +++ branches/2.48/src/mkProjectInfo.ml 2014-10-21 14:10:26 UTC (rev 534) @@ -1,99 +0,0 @@ -(* Program for printing project info into a Makefile. Documentation below. *) - -(* FIX: When the time comes for the next alpha-release, remember to - increment the archive version number first. See update.ml. *) - -let projectName = "unison" -let majorVersion = 2 -let minorVersion = 48 -let pointVersionOrigin = 531 (* Revision that corresponds to point version 0 *) - -(* Documentation: - This is a program to construct a version of the form Major.Minor.Point, - e.g., 2.10.4. - The Point release number is calculated from the Subversion revision number, - so it will be automatically incremented on svn commit. - The Major and Minor numbers are hard coded, as is the revision number - corresponding to the 0 point release. - - If you want to increment the Major or Minor number, you will have to do a - little thinking to get the Point number back to 0. Suppose the current svn - revision number is 27, and we have below - - let majorVersion = 2 - let minorVersion = 11 - let pointVersionOrigin = 3 - - This means that the current Unison version is 2.11.24, since 27-3 = 24. - If we want to change the release to 3.0.0 we need to change things to - - let majorVersion = 3 - let minorVersion = 0 - let pointVersionOrigin = 28 - - and then do a svn commit. - - The first two lines are obvious. The last line says that Subversion - revision 28 corresponds to a 0 point release. Since we were at revision - 27 and we're going to do a commit before making a release, we - will be at 28 after the commit and this will be Unison version 3.0.0. -*) - -(* ---------------------------------------------------------------------- *) -(* You shouldn't need to edit below. *) - -let revisionString = "$Rev$";; - -let pointVersion = - Scanf.sscanf revisionString "$Rev: %d " (fun x -> x) - pointVersionOrigin;; - -Printf.printf "MAJORVERSION=%d.%d\n" majorVersion minorVersion;; -Printf.printf "VERSION=%d.%d.%d\n" majorVersion minorVersion pointVersion;; -Printf.printf "NAME=%s\n" projectName;; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Copied: branches/2.48/src/mkProjectInfo.ml (from rev 533, trunk/src/mkProjectInfo.ml) =================================================================== --- branches/2.48/src/mkProjectInfo.ml (rev 0) +++ branches/2.48/src/mkProjectInfo.ml 2014-10-21 14:10:26 UTC (rev 534) @@ -0,0 +1,100 @@ +(* Program for printing project info into a Makefile. Documentation below. *) + +(* FIX: When the time comes for the next alpha-release, remember to + increment the archive version number first. See update.ml. *) + +let projectName = "unison" +let majorVersion = 2 +let minorVersion = 48 +let pointVersionOrigin = 533 (* Revision that corresponds to point version 0 *) + +(* Documentation: + This is a program to construct a version of the form Major.Minor.Point, + e.g., 2.10.4. + The Point release number is calculated from the Subversion revision number, + so it will be automatically incremented on svn commit. + The Major and Minor numbers are hard coded, as is the revision number + corresponding to the 0 point release. + + If you want to increment the Major or Minor number, you will have to do a + little thinking to get the Point number back to 0. Suppose the current svn + revision number is 27, and we have below + + let majorVersion = 2 + let minorVersion = 11 + let pointVersionOrigin = 3 + + This means that the current Unison version is 2.11.24, since 27-3 = 24. + If we want to change the release to 3.0.0 we need to change things to + + let majorVersion = 3 + let minorVersion = 0 + let pointVersionOrigin = 28 + + and then do a svn commit. + + The first two lines are obvious. The last line says that Subversion + revision 28 corresponds to a 0 point release. Since we were at revision + 27 and we're going to do a commit before making a release, we + will be at 28 after the commit and this will be Unison version 3.0.0. +*) + +(* ---------------------------------------------------------------------- *) +(* You shouldn't need to edit below. *) + +let revisionString = "$Rev$";; + +let pointVersion = + Scanf.sscanf revisionString "$Rev: %d " (fun x -> x) - pointVersionOrigin;; + +Printf.printf "MAJORVERSION=%d.%d\n" majorVersion minorVersion;; +Printf.printf "VERSION=%d.%d.%d\n" majorVersion minorVersion pointVersion;; +Printf.printf "NAME=%s\n" projectName;; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + From bcpierce at cis.upenn.edu Tue Oct 21 10:18:26 2014 From: bcpierce at cis.upenn.edu (Benjamin C. Pierce) Date: Tue, 21 Oct 2014 10:18:26 -0400 Subject: [Unison-hackers] Unison 2.48.1 beta release candidate now available for testing Message-ID: <27D03F1E-6C05-44CC-AF22-57A8BF722604@cis.upenn.edu> OK, I?ve fixed the problem that was biting people with OCaml 4.02. Since there have been a lot of other improvements over the past months, this seems like a good moment for a new beta-release. I?ll announce it on unison-users after I hear that it?s working for a few people, and I?ll try to promote it to stable pretty soon, since the current stable release doesn?t work with the most current OCaml compiler. Please post a message if you notice any issues. - Benjamin Download address: http://www.cis.upenn.edu/~bcpierce/unison/download.html Changes in Version 2.48.1 Changes since 2.45: * Incorporated a patch from Christopher Zimmermann to replace the Uprintf module (which doesn't work with OCaml 4.02, causing Unison to crash) with equivalent functionality from the standard library. * Incorporated a refresh of the OSX GUI, contributed by Alan Shutko. * Added a maxsizethreshold option, which prevents the transfer of files larger than the size specified (in Kb). * Added a "copyonconflict" preference, to make a copy of files that would otherwise be overwritten or deleted in case of conflicting changes. (This makes it possible to automatically resolve conflicts in a fairly safe way when synchronizing continuously, in combination with the "repeat = watch" and "prefer = newer" preferences. * File system monitoring: + The file watcher now fails when unable to watch a directory, rather than silently ignoring the issue. + File system monitoring: more robust communication with the helper program (in socket mode, the unison server will still work properly despite unexpected unison client disconnections). + A bytecode version of unison-fsmonitor is now produced by "make NATIVE=false" + Improved search for unison-fsmonitor + Detect when the helper process exits. + More robust file watching helper programs for Windows and Linux. They communicate with Unison through pipes (Unison redirects stdin and stdout), using a race-free protocol. + Retries paths with failures using an exponential backoff algorithm. + The information returned by the file watchers are used independently for each replica; thus, when only one replica has changes, Unison will only rescan this replica. + When available, used by the graphical UIs to speed up rescanning (can be disabled by setting the new watch preference to + Small fix to the way fsmonitor.py gets invoked when using the file watching functionality, suggested by Josh Berdine. Unison will now look for fsmonitor.py in the same directory where the Unison executable itself lives. * Minor: + Fixed a bug in export procedure that was messing up documentation strings. + Incorporated a patch from Ir?nyossy Knoblauch Art?r to make temp file names fit within 143 characters (to make eCryptFS happy). + Added a string to the Conflict direction to document the reason of the conflict. + Log conflicts and problems in the text UI even if nothing is propagated. + Use hash function from OCaml 3.x for comparing archives, even when compiled with OCaml 4.x. + Do not restart Unison in case of uncaught exception when the repeat preference is set. This seems safer. And it does not work, for instance, in case of lost connection. + Fix Unix.readlink invalid argument error under Windows + Fix a crash when the output of the diff program is too large. + Fixed Makefile for cross-compiling towards Windows (updated to MinGW-w64) Changes since 2.40.63: * New preference fastercheckUNSAFE, which can be used (with care!) to achieve much faster update detection when all the common files in the two replicas are known to be identical. See the manual for more information. This feature should still be considered experimental, but it's ready for other people to try out. * Added option clientHostName. If specified, it will be used to as the client host name, overriding UNISONLOCALHOSTNAME and the actual host name. * OS X GUI: + fix crash under Lion, because of problems with the toolbar, using the fix suggested in http://blitzbasic.com/Community/posts.php?topic=95778. + uimacnew09 is now the standard graphical interface on OSX + A small improvement to the uimacnew09 interface from Alan Schmitt and Steve Kalkwarf: when Unison is run with the -batch flag, the interface will now automatically propagate changes and terminate, without waiting for user interaction. + Show a modal warning window if there is no archive for the hosts. The user can then choose to exit or proceed (proceed is the default). The window is not shown if the batch preference is true. + file details panel selectable * GTK GUI: + New version of uigtk2.ml from Matt Zagrabelny that reorganizes the icons in a slightly more intuitive way. * Minor fixes: + Setting the prefer preference to older or newer now propagates deletions when there is no conflict. + Correctly quote the path when running merge commands. + Add quotes to paths when calling external file watcher utility. + Incorporate a patch to fsmonitor.py (the external filewatcher utility) from Tomasz Zernicki to make it work better under Windows. + Incorporated new version of fsmonitor.py from Christophe Gohle + Fixed incompatibility with OpenSSH 5.6. + Fixed fingerprint cache: do not cache file properties + Some spelling corrections in documentation and comments from Stephane Glondu + Fixed O_APPEND mode for open under Windows + Fixed String.sub invalid argument error when an AppleDouble file does not contain a finder information field + Trim duplicate paths when using "-repeat watch" + Unison now passes path arguments and -follow directives to fsmonitor.py. This seems to work except for one small issue with how fsmonitor.py treats -follow directives for directories that don't exist (or maybe this is an issue with how it treats any kind of monitoring when the thing being monitored doesn't exist?). If we create a symlink to a nonexistant directory, give Unison (hence fsmonitor.py) a 'follow' directive for the symlink, start unison, and then create the directory, fsmonitor.py misses the change. + Lines added in profile files by unison always start at a new line Changes since 2.40.1: * Added "BelowPath" patterns, that match a path as well as all paths below (convenient to use with nodeletion,update,creationpartial preferences) * Added a "fat" preference that makes Unison use the right options when one of the replica is on a FAT filesystem. * Allow "prefer/force=newer" even when not synchronizing modification times. (The reconciler will not be aware of the modification time of unchanged files, so the synchronization choices of Unison can be different from when "times=true", but the behavior remains sane: changed files with the most recent modification time will be propagated.) * Minor fixes and improvements: + Compare filenames up to decomposition in case sensitive mode when one host is running MacOSX and the unicode preference is set to true. + Rsync: somewhat faster compressor + Make Unicode the default on all architectures (it was only the default when a Mac OS X or Windows machine was involved). Changes since 2.32: * Major enhancement: Unicode support. + Unison should now handle unicode filenames correctly on all platforms. + This functionality is controlled by a new preference unicode. + Unicode mode is now the default when one of the hosts is under Windows or MacOS. This may make upgrades a bit more painful (the archives cannot be reused), but this is a much saner default. * Partial transfer of directories. If an error occurs while transferring a directory, the part transferred so far is copied into place (and the archives are updated accordingly). The "maxerrors" preference controls how many transfer error Unison will accept before stopping the transfer of a directory (by default, only one). This makes it possible to transfer most of a directory even if there are some errors. Currently, only the first error is reported by the GUIs. Also, allow partial transfer of a directory when there was an error deep inside this directory during update detection. At the moment, this is only activated with the text and GTK UIs, which have been modified so that they show that the transfer is going to be partial and so that they can display all errors. * Improvement to the code for resuming directory transfers: + if a file was not correctly transferred (or the source has been modified since, with unchanged size), Unison performs a new transfer rather than failing + spurious files are deleted (this can happen if a file is deleted on the source replica before resuming the transfer; not deleting the file would result in it reappearing on the target replica) * Experimental streaming protocol for transferring file contents (can be disabled by setting the directive "stream" to false): file contents is transfered asynchronously (without waiting for a response from the destination after each chunk sent) rather than using the synchronous RPC mechanism. As a consequence: + Unison now transfers the contents of a single file at a time (Unison used to transfer several contents simultaneously in order to hide the connection latency.) + the transfer of large files uses the full available bandwidth and is not slowed done due to the connection latency anymore + we get performance improvement for small files as well by scheduling many files simultaneously (as scheduling a file for transfer consume little ressource: it does not mean allocating a large buffer anymore) * Changes to the internal implementation of the rsync algorithm: + use longer blocks for large files (the size of a block is the square root of the size of the file for large files); + transmit less checksum information per block (we still have less than one chance in a hundred million of transferring a file incorrectly, and Unison will catch any transfer error when fingerprinting the whole file) + avoid transfer overhead (which was 4 bytes per block) For a 1G file, the first optimization saves a factor 50 on the amount of data transferred from the target to the source (blocks are 32768 bytes rather than just 700 bytes). The two other optimizations save another factor of 2 (from 24 bytes per block down to 10). * Implemented an on-disk file fingerprint cache to speed-up update detection after a crash: this way, Unison does not have do recompute all the file fingerprints from scratch. + When Unison detects that the archive case-sensitivity mode does not match the current settings, it populates the fingerprint cache using the archive contents. This way, changing the case-sensitivity mode should be reasonably fast. * New preferences "noupdate=root", "nodeletion=root", "nocreation=root" that prevent Unison from performing files updates, deletions or creations on the given root. Also 'partial' versions of 'noupdate', 'nodeletion' and 'nocreation' * Limit the number of simultaneous external copy program ("copymax" preference) * New "links" preference. When set to false, Unison will report an error on symlinks during update detection. (This is the default when one host is running Windows but not Cygwin.) This is better than failing during propagation. * Added a preference "halfduplex" to force half-duplex communication with the server. This may be useful on unreliable links (as a more efficient alternative to "maxthreads = 1"). * Renamed preference "pretendwin" to "ignoreinodenumbers" (an alias is kept for backwards compatibility). * Ignore one-second differences when synchronizing modification time. (Technically, this is an incompatible archive format change, but it is backward compatible. To trigger a problem, a user would have to synchronize modification times on a filesystem with a two-second granularity and then downgrade to a previous version of Unison, which does not work well in such a case. Thus, it does not seem worthwhile to increment the archive format number, which would impact all users.) * Do not keep many files simultaneously opened anymore when the rsync algorithm is in use. * Add "ignorearchives" preference to ignore existing archives (to avoid forcing users to delete them manually, in situations where one archive has gotten deleted or corrupted). * Mac OS + fixed rsync bug which could result in an "index out of bounds" error when transferring resource forks. + Fixed bug which made Unison ignore finder information and resource fork when compiled to 64bit on Mac OSX. + should now be 64 bit clean (the Growl framework is not up to date, though) + Made the bridge between Objective C and Ocaml code GC friendly (it was allocating ML values and putting them in an array which was not registered with the GC) + use darker grey arrows (patch contributed by Eric Y. Kow) * GTK user interface + assistant for creating profiles + profile editor + pop up a summary window when the replicas are not fully synchronized after transport + display estimated remaining time and transfer rate on the progress bar + allow simultaneous selection of several items + Do not reload the preference file before a new update detection if it is unchanged + disabled scrolling to the first unfinished item during transport. It goes way too fast when lot of small files are synchronized, and it makes it impossible to browse the file list during transport. + take into account the "height" preference again + the internal list of selected reconciler item was not always in sync with what was displayed (GTK bug?); workaround implemented + Do not display "Looking for change" messages during propagation (when checking the targe is unchanged) but only during update detection + Apply patch to fix some crashes in the OSX GUI, thanks to Onne Gorter. * Text UI + During update detection, display status by updating a single line rather than generating a new line of output every so often. Should be less confusing. * Windows + Fastcheck is now the default under Windows. People mostly use NTFS nowadays and the Unicode API provides an equivalent to inode numbers for this filesystem. + Only use long UNC path for accessing replicas (as '..' is not handled with this format of paths, but can be useful) + Windows text UI: now put the console into UTF-8 output mode. This is the right thing to do when in Unicode mode, and is no worse than what we had previously otherwise (the console use some esoteric encoding by default). This only works when using a Unicode font instead of the default raster font. + Don't get the home directory from environment variable HOME under Windows (except for Cygwin binaries): we don't want the behavior of Unison to depends on whether it is run from a Cygwin shell (where HOME is set) or in any other way (where HOME is usually not set). * Miscellaneous fixes and improvements + Made a server waiting on a socket more resilient to unexpected lost connections from the client. + Small patch to property setting code suggested by Ulrich Gernkow. + Several fixes to the change transfer functions (both the internal ones and external transfers using rsync). In particular, limit the number of simultaneous transfer using an rsync (as the rsync algorithm can use a large amount of memory when processing huge files) + Keep track of which file contents are being transferred, and delay the transfer of a file when another file with the same contents is currently being transferred. This way, the second transfer can be skipped and replaced by a local copy. + Experimental update detection optimization: do not read the contents of unchanged directories + When a file transfer fails, turn off fastcheck for this file on the next sync. + Fixed bug with case insensitive mode on a case sensitive filesystem: o if file "a/a" is created on one replica and directory "A" is created on the other, the file failed to be synchronized the first time Unison is run afterwards, as Unison uses the wrong path "a/a" (if Unison is run again, the directories are in the archive, so the right path is used); o if file "a" appears on one replica and file "A" appears on the other with different contents, Unison was unable to synchronize them. + Improved error reporting when the destination is updated during synchronization: Unison now tells which file has been updated, and how. + Limit the length of temporary file names + Case sensitivity information put in the archive (in a backward compatible way) and checked when the archive is loaded + Got rid of the 16mb marshalling limit by marshalling to a bigarray. + Resume copy of partially transferred files. Changes since 2.31: * Small user interface changes + Small change to text UI "scanning..." messages, to print just directories (hopefully making it clearer that individual files are not necessarily being fingerprinted). * Minor fixes and improvements: + Ignore one hour differences when deciding whether a file may have been updated. This avoids slow update detection after daylight saving time changes under Windows. This makes Unison slightly more likely to miss an update, but it should be safe enough. + Fix a small bug that was affecting mainly windows users. We need to commit the archives at the end of the sync even if there are no updates to propagate because some files (in fact, if we've just switched to DST on windows, a LOT of files) might have new modtimes in the archive. (Changed the text UI only. It's less clear where to change the GUI.) + Don't delete the temp file when a transfer fails due to a fingerprint mismatch (so that we can have a look and see why!) We've also added more debugging code togive more informative error messages when we encounter the dreaded and longstanding "assert failed during file transfer" bug + Incorrect paths ("path" directive) now result in an error update item rather than a fatal error. + Create parent directories (with correct permissions) during transport for paths which point to non-existent locations in the destination replica. Changes since 2.27: * If Unison is interrupted during a directory transfer, it will now leave the partially transferred directory intact in a temporary location. (This maintains the invariant that new files/directories are transferred either completely or not at all.) The next time Unison is run, it will continue filling in this temporary directory, skipping transferring files that it finds are already there. * We've added experimental support for invoking an external file transfer tool for whole-file copies instead of Unison's built-in transfer protocol. Three new preferences have been added: + copyprog is a string giving the name (and command-line switches, if needed) of an external program that can be used to copy large files efficiently. By default, rsync is invoked, but other tools such as scp can be used instead by changing the value of this preference. (Although this is not its primary purpose, rsync is actually a pretty fast way of copying files that don't already exist on the receiving host.) For files that do already exist on (but that have been changed in one replica), Unison will always use its built-in implementation of the rsync algorithm. + Added a "copyprogrest" preference, so that we can give different command lines for invoking the external copy utility depending on whether a partially transferred file already exists or not. (Rsync doesn't seem to care about this, but other utilities may.) + copythreshold is an integer (-1 by default), indicating above what filesize (in megabytes) Unison should use the external copying utility specified by copyprog. Specifying 0 will cause ALL copies to use the external program; a negative number will prevent any files from using it. (Default is -1.) Thanks to Alan Schmitt for a huge amount of hacking and to an anonymous sponsor for suggesting and underwriting this extension. * Small improvements: + Added a new preference, dontchmod. By default, Unison uses the chmod system call to set the permission bits of files after it has copied them. But in some circumstances (and under some operating systems), the chmod call always fails. Setting this preference completely prevents Unison from ever calling chmod. + Don't ignore files that look like backup files if the backuplocation preference is set to central + Shortened the names of several preferences. The old names are also still supported, for backwards compatibility, but they do not appear in the documentation. + Lots of little documentation tidying. (In particular, preferences are separated into Basic and Advanced! This should hopefully make Unison a little more approachable for new users. + Unison can sometimes fail to transfer a file, giving the unhelpful message "Destination updated during synchronization" even though the file has not been changed. This can be caused by programs that change either the file's contents or the file's extended attributes without changing its modification time. It's not clear what is the best fix for this - it is not Unison's fault, but it makes Unison's behavior puzzling - but at least Unison can be more helpful about suggesting a workaround (running once with fastcheck set to false). The failure message has been changed to give this advice. + Further improvements to the OS X GUI (thanks to Alan Schmitt and Craig Federighi). * Very preliminary support for triggering Unison from an external filesystem-watching utility. The current implementation is very simple, not efficient, and almost completely untested--not ready for real users. But if someone wants to help improve it (e.g., by writing a filesystem watcher for your favorite OS), please make yourself known! On the Unison side, the new behavior is very simple: + use the text UI + start Unison with the command-line flag "-repeat FOO", where FOO is name of a file where Unison should look for notifications of changes + when it starts up, Unison will read the whole contents of this file (on both hosts), which should be a newline-separated list of paths (relative to the root of the synchronization) and synchronize just these paths, as if it had been started with the "-path=xxx" option for each one of them + when it finishes, it will sleep for a few seconds and then examine the watchfile again; if anything has been added, it will read the new paths, synchronize them, and go back to sleep + that's it! To use this to drive Unison "incrementally," just start it in this mode and start up a tool (on each host) to watch for new changes to the filesystem and append the appropriate paths to the watchfile. Hopefully such tools should not be too hard to write. * Bug fixes: + Fixed a bug that was causing new files to be created with permissions 0x600 instead of using a reasonable default (like 0x644), if the 'perms' flag was set to 0. (Bug reported by Ben Crowell.) + Follow maxthreads preference when transferring directories. From bcpierce at seas.upenn.edu Tue Oct 21 10:06:20 2014 From: bcpierce at seas.upenn.edu (bcpierce at seas.upenn.edu) Date: Tue, 21 Oct 2014 10:06:20 -0400 Subject: [Unison-hackers] [unison-svn] r531 - in trunk: doc src src/ubase Message-ID: <201410211406.s9LE6L3b003144@yaws.seas.upenn.edu> Author: bcpierce Date: 2014-10-21 10:06:20 -0400 (Tue, 21 Oct 2014) New Revision: 531 Removed: trunk/src/ubase/uprintf.ml trunk/src/ubase/uprintf.mli Modified: trunk/doc/changes.tex trunk/src/NEWS trunk/src/RECENTNEWS trunk/src/mkProjectInfo.ml trunk/src/osx.ml trunk/src/strings.ml Log: * Preparing for new beta release Modified: trunk/doc/changes.tex =================================================================== --- trunk/doc/changes.tex 2014-09-28 16:48:05 UTC (rev 530) +++ trunk/doc/changes.tex 2014-10-21 14:06:20 UTC (rev 531) @@ -1,3 +1,62 @@ +\begin{changesfromversion}{2.45} +\item Incorporated a patch from Christopher Zimmermann to replace the + Uprintf module (which doesn't work with OCaml 4.02, causing Unison to crash) with equivalent + functionality from the standard library. +\item Incorporated a refresh of the OSX GUI, contributed by Alan Shutko. +\item Added a {\tt maxsizethreshold} option, which prevents the transfer of + files larger than the size specified (in Kb). +\item Added a "copyonconflict" preference, to make a copy of files that would + otherwise be overwritten or deleted in case of conflicting changes. + (This makes it possible to automatically resolve conflicts in a + fairly safe way when synchronizing continuously, in combination + with the "{\tt repeat = watch}" and "{\tt prefer = newer}" preferences. +%%%%% +\item File system monitoring: +\begin{itemize} +\item +The file watcher now fails when unable to + watch a directory, rather than silently ignoring the issue. +\item File system monitoring: more robust communication with the helper program + (in socket mode, the unison server will still work properly despite + unexpected unison client disconnections). +\item A bytecode version of unison-fsmonitor is now produced by "make NATIVE=false" +\item Improved search for unison-fsmonitor +\item Detect when the helper process exits. +\item More robust file watching helper programs for Windows and Linux. + They communicate with Unison through pipes (Unison redirects stdin + and stdout), using a race-free protocol. +\item Retries paths with failures using an exponential backoff algorithm. +\item The information returned by the file watchers are used + independently for each replica; thus, when only one replica has + changes, Unison will only rescan this replica. +\item When available, used by the graphical UIs to speed up rescanning + (can be disabled by setting the new {\tt watch} preference to +\item Small fix to the way fsmonitor.py gets invoked when using the file + watching functionality, suggested by Josh Berdine. Unison will now + look for {\tt fsmonitor.py} in the same directory where the Unison + executable itself lives. +\end{itemize} +%%%%% +\item Minor: +\begin{itemize} +\item Fixed a bug in export procedure that was messing up documentation +strings. +\item Incorporated a patch from Ir\'anyossy Knoblauch Art\'ur to make temp file + names fit within 143 characters (to make eCryptFS happy). +\item Added a string to the Conflict direction to document the reason of + the conflict. +\item Log conflicts and problems in the text UI even if nothing is propagated. +\item Use hash function from OCaml 3.x for comparing archives, even when + compiled with OCaml 4.x. +\item Do not restart Unison in case of uncaught exception when the repeat + preference is set. This seems safer. And it does not work, for + instance, in case of lost connection. +\item Fix Unix.readlink invalid argument error under Windows +\item Fix a crash when the output of the {\tt diff} program is too large. +\item Fixed Makefile for cross-compiling towards Windows (updated to MinGW-w64) +\end{itemize} +\end{changesfromversion} + \begin{changesfromversion}{2.40.63} \item New preference {\tt fastercheckUNSAFE}, which can be used (with care!) to achieve {\em much} faster update detection when all the common files in Modified: trunk/src/NEWS =================================================================== --- trunk/src/NEWS 2014-09-28 16:48:05 UTC (rev 530) +++ trunk/src/NEWS 2014-10-21 14:06:20 UTC (rev 531) @@ -1,6 +1,65 @@ -Changes in Version 2.47.1 +Changes in Version 2.47.4 + Changes since 2.45: + * Incorporated a patch from Christopher Zimmermann to replace the + Uprintf module (which doesn't work with OCaml 4.02, causing Unison + to crash) with equivalent functionality from the standard library. + * Incorporated a refresh of the OSX GUI, contributed by Alan Shutko. + * Added a maxsizethreshold option, which prevents the transfer of + files larger than the size specified (in Kb). + * Added a "copyonconflict" preference, to make a copy of files that + would otherwise be overwritten or deleted in case of conflicting + changes. (This makes it possible to automatically resolve conflicts + in a fairly safe way when synchronizing continuously, in + combination with the "repeat = watch" and "prefer = newer" + preferences. + * File system monitoring: + + The file watcher now fails when unable to watch a directory, + rather than silently ignoring the issue. + + File system monitoring: more robust communication with the + helper program (in socket mode, the unison server will still + work properly despite unexpected unison client + disconnections). + + A bytecode version of unison-fsmonitor is now produced by + "make NATIVE=false" + + Improved search for unison-fsmonitor + + Detect when the helper process exits. + + More robust file watching helper programs for Windows and + Linux. They communicate with Unison through pipes (Unison + redirects stdin and stdout), using a race-free protocol. + + Retries paths with failures using an exponential backoff + algorithm. + + The information returned by the file watchers are used + independently for each replica; thus, when only one replica + has changes, Unison will only rescan this replica. + + When available, used by the graphical UIs to speed up + rescanning (can be disabled by setting the new watch + preference to + + Small fix to the way fsmonitor.py gets invoked when using the + file watching functionality, suggested by Josh Berdine. Unison + will now look for fsmonitor.py in the same directory where the + Unison executable itself lives. + * Minor: + + Fixed a bug in export procedure that was messing up + documentation strings. + + Incorporated a patch from Ir?nyossy Knoblauch Art?r to make + temp file names fit within 143 characters (to make eCryptFS + happy). + + Added a string to the Conflict direction to document the + reason of the conflict. + + Log conflicts and problems in the text UI even if nothing is + propagated. + + Use hash function from OCaml 3.x for comparing archives, even + when compiled with OCaml 4.x. + + Do not restart Unison in case of uncaught exception when the + repeat preference is set. This seems safer. And it does not + work, for instance, in case of lost connection. + + Fix Unix.readlink invalid argument error under Windows + + Fix a crash when the output of the diff program is too large. + + Fixed Makefile for cross-compiling towards Windows (updated to + MinGW-w64) + Changes since 2.40.63: * New preference fastercheckUNSAFE, which can be used (with care!) to achieve much faster update detection when all the common files in Modified: trunk/src/RECENTNEWS =================================================================== --- trunk/src/RECENTNEWS 2014-09-28 16:48:05 UTC (rev 530) +++ trunk/src/RECENTNEWS 2014-10-21 14:06:20 UTC (rev 531) @@ -1,187 +1,5 @@ -CHANGES FROM VERSION 2.47.2 +CHANGES FROM VERSION 2.47.4 -* Incorporate a small patch from Christopher Zimmermann to replace the - Uprintf module (which doesn't work with OCaml 4.02) with equivalent - functionality from the standard library. +* Preparing for new beta release - ------------------------------- -CHANGES FROM VERSION 2.47.1 - -* Fixed a bug in export procedure that was messing up documentation strings - - -------------------------------- -CHANGES FROM VERSION 2.47.0 - -* Incorporated a refresh of the OSX GUI, contributed by Alan Shutko. - -* Update dates in copyright notices - -* Tidying for beta-release - -------------------------------- -CHANGES FROM VERSION 2.46.20 - -* Incorporated patch from Ir??nyossy Knoblauch Art??r to make temp file - names fit within 143 characters (to make eCryptFS happy). - - -------------------------------- -CHANGES FROM VERSION 2.46.18 - -* Incorporated patch from Ir??nyossy Knoblauch Art??r to make temp file - names fit within 143 characters (to make eCryptFS happy). - -* Adapting the GTK UI to the new Conflict type. For the moment, the - string carried is not used. - -------------------------------- -CHANGES FROM VERSION 2.46.13 - -* Log conflicts and problems in the text UI even if nothing is propagated. -* Added a string to the Conflict direction to document the reason of - the conflict. The text UI has been adapted to this change, the other - UIs need to be modified. -* Adding the maxsizethreshold option which prevents the transfer of - files larger than the size specified (in Kb) - -------------------------------- -CHANGES FROM VERSION 2.46.12 - -* File system monitoring: the file watcher now fails when unable to - watch a directory, rather than silently ignoring the issue - -------------------------------- -CHANGES FROM VERSION 2.46.10 - -* File system monitoring: more robust communication with the helper program - (in socket mode, the unison server will still work properly despite - unexpected unison client disconnections) - -------------------------------- -CHANGES FROM VERSION 2.46.9 - -* Use hash function from OCaml 3.x for comparing archives, even when - compiled with OCaml 4.x - -------------------------------- -CHANGES FROM VERSION 2.46.8 - -* Filesystem monitoring: do not use filters on maps, for compatibility - with OCaml 3.11 - -------------------------------- -CHANGES FROM VERSION 2.46.6 - -* A bytecode version of unison-fsmonitor is now produced by "make NATIVE=false" - -------------------------------- ->>>>>>> .r525 -CHANGES FROM VERSION 2.46.4 - -* Windows/lwt: correctly deals with Sys.Break exceptions when sleeping -* File system monitoring: improved search for unison-fsmonitor -* File system monitoring: detect when the helper process exits -* Do not restart Unison in case of uncaught exception when the repeat - preference is set. This seems safer. And it does not work, for - instance, in case of lost connection. - -------------------------------- -CHANGES FROM VERSION 2.46.3 - -* Add a note to the 'new archives not identical' error message - explaining that this can happen because Unison binaries compiled - with OCaml 3 and OCaml 4 are incompatible. - - -------------------------------- -CHANGES FROM VERSION 2.46.2 - -* Fix Unix.readlink invalid argument error under Windows - -------------------------------- -CHANGES FROM VERSION 2.46.1 - -* More robust file watching helper programs for Windows and Linux. - They communicate with Unison through pipes (Unison redirects stdin - and stdout), using a race-free protocol. - -------------------------------- -CHANGES FROM VERSION 2.46.0 - -* Added a "copyonconflict" preference, to make a copy of files that would - otherwise be overwritten or deleted in case of conflicting changes. - (This makes it possible to automatically resolve conflicts in a - fairly safe way when synchronizing continuously, in combination - with the "repeat = watch" and "prefer = newer" preferences. - -------------------------------- -CHANGES FROM VERSION 2.46.-1 - -* Bumped version number: incompatible protocol changes -* Improvements to the file watching functionality: - - retries paths with failures using an exponential backoff algorithm - - the information returned by the file watchers are used - independently for each replica; thus, when only one replica has - changes, Unison will only rescan this replica - - when available, used by the graphical UIs to speed up rescanning - (can be disabled by setting the new 'watch' preference to false) - -------------------------------- -CHANGES FROM VERSION 2.45.15 - -* transfer.ml: updated debugging code; in particular, turns an - assertion failure into a more friendly transient failure - -------------------------------- -CHANGES FROM VERSION 2.45.14 - -* Function External.readChannelTillEof now tail recursive - (prevents a crash when the output of the diff program is too large) - -------------------------------- -CHANGES FROM VERSION 2.45.13 - -* Fixed Makefile for cross-compiling towards Windows (updated to MinGW-w64) - -------------------------------- -CHANGES FROM VERSION 2.45.12 - -* fsmonitor.py: fixed busy wait under Windows -* fsmonitor.py: make sure this helper program exits when Unison terminates - (now, fsmonitor.py exits when stdin is closed, and Unison redirects stdin) - -------------------------------- -CHANGES FROM VERSION 2.45.11 - -* Fix bug in Lwt_unix.sleep - -------------------------------- -CHANGES FROM VERSION 2.45.9 - -* Added some more debugging code in transfer.ml -------------------------------- -CHANGES FROM VERSION 2.45.7 - -* Small fix to the way fsmonitor.py gets invoked when using the file - watching functionality, suggested by Josh Berdine. Unison will now - look for fsmonitor.py in the same directory where the Unison - executable itself lives. -------------------------------- -CHANGES FROM VERSION 2.45.7 - -* Small fix to the way fsmonitor.py gets invoked when using the file - watching functionality, suggested by Josh Berdine. Unison will now - look for fsmonitor.py in the same directory where the Unison - executable itself lives. - -* Fix bug in last commit - -* Added some debugging code in transfer.ml - -* Display full stack backtraces when printing exceptions, per comment - from Jerome - -- fixed a bug in the lookup of the host name on the server - Modified: trunk/src/mkProjectInfo.ml =================================================================== --- trunk/src/mkProjectInfo.ml 2014-09-28 16:48:05 UTC (rev 530) +++ trunk/src/mkProjectInfo.ml 2014-10-21 14:06:20 UTC (rev 531) @@ -95,3 +95,4 @@ + Modified: trunk/src/osx.ml =================================================================== --- trunk/src/osx.ml 2014-09-28 16:48:05 UTC (rev 530) +++ trunk/src/osx.ml 2014-10-21 14:06:20 UTC (rev 531) @@ -206,7 +206,8 @@ | `DIRECTORY -> { ressInfo = NoRess; finfo = "D" } | _ -> { ressInfo = NoRess; finfo = "" } -let noTypeCreator = String.make 10 '\000' +(* BCP: dead code + let noTypeCreator = String.make 10 '\000' *) (* Remove trailing zeroes *) let trim s = Modified: trunk/src/strings.ml =================================================================== --- trunk/src/strings.ml 2014-09-28 16:48:05 UTC (rev 530) +++ trunk/src/strings.ml 2014-10-21 14:06:20 UTC (rev 531) @@ -4,7 +4,7 @@ let docs = ("about", ("About Unison", "Unison File Synchronizer\n\ - Version 2.47.1\n\ + Version 2.47.4\n\ \n\ ")) :: @@ -2768,9 +2768,68 @@ \n\ ")) :: - ("news", ("Changes in Version 2.47.1", - "Changes in Version 2.47.1\n\ + ("news", ("Changes in Version 2.47.4", + "Changes in Version 2.47.4\n\ \n\ + \032 Changes since 2.45:\n\ + \032 * Incorporated a patch from Christopher Zimmermann to replace the\n\ + \032 Uprintf module (which doesn't work with OCaml 4.02, causing Unison\n\ + \032 to crash) with equivalent functionality from the standard library.\n\ + \032 * Incorporated a refresh of the OSX GUI, contributed by Alan Shutko.\n\ + \032 * Added a maxsizethreshold option, which prevents the transfer of\n\ + \032 files larger than the size specified (in Kb).\n\ + \032 * Added a \"copyonconflict\" preference, to make a copy of files that\n\ + \032 would otherwise be overwritten or deleted in case of conflicting\n\ + \032 changes. (This makes it possible to automatically resolve conflicts\n\ + \032 in a fairly safe way when synchronizing continuously, in\n\ + \032 combination with the \"repeat = watch\" and \"prefer = newer\"\n\ + \032 preferences.\n\ + \032 * File system monitoring:\n\ + \032 + The file watcher now fails when unable to watch a directory,\n\ + \032 rather than silently ignoring the issue.\n\ + \032 + File system monitoring: more robust communication with the\n\ + \032 helper program (in socket mode, the unison server will still\n\ + \032 work properly despite unexpected unison client\n\ + \032 disconnections).\n\ + \032 + A bytecode version of unison-fsmonitor is now produced by\n\ + \032 \"make NATIVE=false\"\n\ + \032 + Improved search for unison-fsmonitor\n\ + \032 + Detect when the helper process exits.\n\ + \032 + More robust file watching helper programs for Windows and\n\ + \032 Linux. They communicate with Unison through pipes (Unison\n\ + \032 redirects stdin and stdout), using a race-free protocol.\n\ + \032 + Retries paths with failures using an exponential backoff\n\ + \032 algorithm.\n\ + \032 + The information returned by the file watchers are used\n\ + \032 independently for each replica; thus, when only one replica\n\ + \032 has changes, Unison will only rescan this replica.\n\ + \032 + When available, used by the graphical UIs to speed up\n\ + \032 rescanning (can be disabled by setting the new watch\n\ + \032 preference to\n\ + \032 + Small fix to the way fsmonitor.py gets invoked when using the\n\ + \032 file watching functionality, suggested by Josh Berdine. Unison\n\ + \032 will now look for fsmonitor.py in the same directory where the\n\ + \032 Unison executable itself lives.\n\ + \032 * Minor:\n\ + \032 + Fixed a bug in export procedure that was messing up\n\ + \032 documentation strings.\n\ + \032 + Incorporated a patch from Ir\225nyossy Knoblauch Art\250r to make\n\ + \032 temp file names fit within 143 characters (to make eCryptFS\n\ + \032 happy).\n\ + \032 + Added a string to the Conflict direction to document the\n\ + \032 reason of the conflict.\n\ + \032 + Log conflicts and problems in the text UI even if nothing is\n\ + \032 propagated.\n\ + \032 + Use hash function from OCaml 3.x for comparing archives, even\n\ + \032 when compiled with OCaml 4.x.\n\ + \032 + Do not restart Unison in case of uncaught exception when the\n\ + \032 repeat preference is set. This seems safer. And it does not\n\ + \032 work, for instance, in case of lost connection.\n\ + \032 + Fix Unix.readlink invalid argument error under Windows\n\ + \032 + Fix a crash when the output of the diff program is too large.\n\ + \032 + Fixed Makefile for cross-compiling towards Windows (updated to\n\ + \032 MinGW-w64)\n\ + \n\ \032 Changes since 2.40.63:\n\ \032 * New preference fastercheckUNSAFE, which can be used (with care!) to\n\ \032 achieve much faster update detection when all the common files in\n\ Deleted: trunk/src/ubase/uprintf.ml =================================================================== --- trunk/src/ubase/uprintf.ml 2014-09-28 16:48:05 UTC (rev 530) +++ trunk/src/ubase/uprintf.ml 2014-10-21 14:06:20 UTC (rev 531) @@ -1,94 +0,0 @@ -(***********************************************************************) -(* *) -(* Objective Caml *) -(* *) -(* Xavier Leroy, projet Cristal, INRIA Rocquencourt *) -(* *) -(* Copyright 1996 Institut National de Recherche en Informatique et *) -(* en Automatique. All rights reserved. This file is distributed *) -(* under the terms of the GNU Library General Public License. *) -(* *) -(***********************************************************************) - -external caml_format_int: string -> int -> string = "caml_format_int" -external caml_format_float: string -> float -> string = "caml_format_float" - -let fprintf outchan doafter format = - let format = (Obj.magic format : string) in - let rec doprn i = - if i >= String.length format then - (doafter(); Obj.magic ()) - else begin - let c = String.unsafe_get format i in - if c <> '%' then begin - output_char outchan c; - doprn (succ i) - end else begin - let j = skip_args (succ i) in - match String.unsafe_get format j with - '%' -> - output_char outchan '%'; - doprn (succ j) - | 's' -> - Obj.magic(fun s -> - if j <= i+1 then - output_string outchan s - else begin - let p = - try - int_of_string (String.sub format (i+1) (j-i-1)) - with Failure _ -> - invalid_arg "fprintf: bad %s format" in - if p > 0 && String.length s < p then begin - output_string outchan - (String.make (p - String.length s) ' '); - output_string outchan s - end else if p < 0 && String.length s < -p then begin - output_string outchan s; - output_string outchan - (String.make (-p - String.length s) ' ') - end else - output_string outchan s - end; - doprn (succ j)) - | 'c' -> - Obj.magic(fun c -> - output_char outchan c; - doprn (succ j)) - | 'd' | 'i' | 'o' | 'x' | 'X' | 'u' -> - Obj.magic(fun n -> - output_string outchan - (caml_format_int (String.sub format i (j-i+1)) n); - doprn (succ j)) - | 'f' | 'e' | 'E' | 'g' | 'G' -> - Obj.magic(fun f -> - output_string outchan - (caml_format_float (String.sub format i (j-i+1)) f); - doprn (succ j)) - | 'b' -> - Obj.magic(fun b -> - output_string outchan (string_of_bool b); - doprn (succ j)) - | 'a' -> - Obj.magic(fun printer arg -> - printer outchan arg; - doprn(succ j)) - | 't' -> - Obj.magic(fun printer -> - printer outchan; - doprn(succ j)) - | c -> - invalid_arg ("fprintf: unknown format") - end - end - - and skip_args j = - match String.unsafe_get format j with - '0' .. '9' | ' ' | '.' | '-' -> skip_args (succ j) - | c -> j - - in doprn 0 - -let printf doafter fmt = fprintf stdout doafter fmt -and eprintf doafter fmt = fprintf stderr doafter fmt - Deleted: trunk/src/ubase/uprintf.mli =================================================================== --- trunk/src/ubase/uprintf.mli 2014-09-28 16:48:05 UTC (rev 530) +++ trunk/src/ubase/uprintf.mli 2014-10-21 14:06:20 UTC (rev 531) @@ -1,75 +0,0 @@ -(***********************************************************************) -(* *) -(* Objective Caml *) -(* *) -(* Xavier Leroy, projet Cristal, INRIA Rocquencourt *) -(* *) -(* Copyright 1996 Institut National de Recherche en Informatique et *) -(* en Automatique. All rights reserved. This file is distributed *) -(* under the terms of the GNU Library General Public License. *) -(* *) -(***********************************************************************) - -(* Modified for Unison *) - - -(* Module [Printf]: formatting printing functions *) - -val fprintf: out_channel -> (unit->unit) -> ('a, out_channel, unit) format -> 'a - (* [fprintf outchan doafter format arg1 ... argN] formats the arguments - [arg1] to [argN] according to the format string [format], - outputs the resulting string on the channel [outchan], and then - executes the thunk [doafter]. - - The format is a character string which contains two types of - objects: plain characters, which are simply copied to the - output channel, and conversion specifications, each of which - causes conversion and printing of one argument. - - Conversion specifications consist in the [%] character, followed - by optional flags and field widths, followed by one conversion - character. The conversion characters and their meanings are: -- [d] or [i]: convert an integer argument to signed decimal -- [u]: convert an integer argument to unsigned decimal -- [x]: convert an integer argument to unsigned hexadecimal, - using lowercase letters. -- [X]: convert an integer argument to unsigned hexadecimal, - using uppercase letters. -- [o]: convert an integer argument to unsigned octal. -- [s]: insert a string argument -- [c]: insert a character argument -- [f]: convert a floating-point argument to decimal notation, - in the style [dddd.ddd] -- [e] or [E]: convert a floating-point argument to decimal notation, - in the style [d.ddd e+-dd] (mantissa and exponent) -- [g] or [G]: convert a floating-point argument to decimal notation, - in style [f] or [e], [E] (whichever is more compact) -- [b]: convert a boolean argument to the string [true] or [false] -- [a]: user-defined printer. Takes two arguments and apply the first - one to [outchan] (the current output channel) and to the second - argument. The first argument must therefore have type - [out_channel -> 'b -> unit] and the second ['b]. - The output produced by the function is therefore inserted - in the output of [fprintf] at the current point. -- [t]: same as [%a], but takes only one argument (with type - [out_channel -> unit]) and apply it to [outchan]. -- [%]: take no argument and output one [%] character. -- Refer to the C library [printf] function for the meaning of - flags and field width specifiers. - - Warning: if too few arguments are provided, - for instance because the [printf] function is partially - applied, the format is immediately printed up to - the conversion of the first missing argument; printing - will then resume when the missing arguments are provided. - For example, [List.iter (printf "x=%d y=%d " 1) [2;3]] - prints [x=1 y=2 3] instead of the expected - [x=1 y=2 x=1 y=3]. To get the expected behavior, do - [List.iter (fun y -> printf "x=%d y=%d " 1 y) [2;3]]. *) - -val printf: (unit->unit) -> ('a, out_channel, unit) format -> 'a - (* Same as [fprintf], but output on [stdout]. *) - -val eprintf: (unit->unit) -> ('a, out_channel, unit) format -> 'a - (* Same as [fprintf], but output on [stderr]. *) - From schmitta at seas.upenn.edu Thu Oct 23 02:49:39 2014 From: schmitta at seas.upenn.edu (schmitta at seas.upenn.edu) Date: Thu, 23 Oct 2014 02:49:39 -0400 Subject: [Unison-hackers] [unison-svn] r535 - in branches/2.48/src/uimac14: . uimacnew.xcodeproj Message-ID: <201410230649.s9N6ne2o007338@yaws.seas.upenn.edu> Author: schmitta Date: 2014-10-23 02:49:38 -0400 (Thu, 23 Oct 2014) New Revision: 535 Modified: branches/2.48/src/uimac14/cltool.c branches/2.48/src/uimac14/uimacnew.xcodeproj/project.pbxproj Log: remove a couple warnings Modified: branches/2.48/src/uimac14/cltool.c =================================================================== --- branches/2.48/src/uimac14/cltool.c 2014-10-21 14:10:26 UTC (rev 534) +++ branches/2.48/src/uimac14/cltool.c 2014-10-23 06:49:38 UTC (rev 535) @@ -32,15 +32,15 @@ if (status) { if (status == kLSApplicationNotFoundErr) { fprintf(stderr,"Error: can't find the Unison application using the Launch Services database.\n"); - fprintf(stderr,"Try launching Unison from the Finder, and then try this again.\n",status); + fprintf(stderr,"Try launching Unison from the Finder, and then try this again.\n"); } - else fprintf(stderr,"Error: can't find Unison application (%ld).\n",status); + else fprintf(stderr,"Error: can't find Unison application (%d).\n",(int)status); exit(1); } status = FSRefMakePath(&fsref,(UInt8 *)buf,BUFSIZE); if (status) { - fprintf(stderr,"Error: problem building path to Unison application (%ld).\n",status); + fprintf(stderr,"Error: problem building path to Unison application (%d).\n",(int)status); exit(1); } Modified: branches/2.48/src/uimac14/uimacnew.xcodeproj/project.pbxproj =================================================================== --- branches/2.48/src/uimac14/uimacnew.xcodeproj/project.pbxproj 2014-10-21 14:10:26 UTC (rev 534) +++ branches/2.48/src/uimac14/uimacnew.xcodeproj/project.pbxproj 2014-10-23 06:49:38 UTC (rev 535) @@ -83,7 +83,7 @@ B5B44C1F09DF61A4000DC7AF /* table-right-green.tif in Resources */ = {isa = PBXBuildFile; fileRef = B5B44C1709DF61A4000DC7AF /* table-right-green.tif */; }; B5B44C2009DF61A4000DC7AF /* table-skip.tif in Resources */ = {isa = PBXBuildFile; fileRef = B5B44C1809DF61A4000DC7AF /* table-skip.tif */; }; B5E03B3909E38B9E0058C7B9 /* rescan.tif in Resources */ = {isa = PBXBuildFile; fileRef = B5E03B3809E38B9E0058C7B9 /* rescan.tif */; }; - BB1ADE26114AEB1100575BFC /* Growl.framework in CopyFiles */ = {isa = PBXBuildFile; fileRef = BBE2BCAC11355CDD00B187F2 /* Growl.framework */; }; + BB1ADE26114AEB1100575BFC /* Growl.framework in CopyFiles */ = {isa = PBXBuildFile; fileRef = BBE2BCAC11355CDD00B187F2 /* Growl.framework */; settings = {ATTRIBUTES = (CodeSignOnCopy, ); }; }; BBE2BCAE11355CDD00B187F2 /* Growl.framework in Frameworks */ = {isa = PBXBuildFile; fileRef = BBE2BCAC11355CDD00B187F2 /* Growl.framework */; }; DE2444D610C294EA007E1546 /* MainMenu.xib in Resources */ = {isa = PBXBuildFile; fileRef = DE2444D410C294EA007E1546 /* MainMenu.xib */; }; /* End PBXBuildFile section */ @@ -419,7 +419,7 @@ 29B97313FDCFA39411CA2CEA /* Project object */ = { isa = PBXProject; attributes = { - LastUpgradeCheck = 0410; + LastUpgradeCheck = 0610; }; buildConfigurationList = 2A3C3F2C0992245300E404E9 /* Build configuration list for PBXProject "uimacnew" */; compatibilityVersion = "Xcode 3.2"; @@ -609,7 +609,7 @@ 2A3C3F290992245300E404E9 /* Development */ = { isa = XCBuildConfiguration; buildSettings = { - ARCHS = "$(ARCHS_STANDARD_64_BIT)"; + COMBINE_HIDPI_IMAGES = YES; COPY_PHASE_STRIP = NO; FRAMEWORK_SEARCH_PATHS = ( "$(FRAMEWORK_SEARCH_PATHS)", @@ -651,7 +651,7 @@ 2A3C3F2A0992245300E404E9 /* Deployment */ = { isa = XCBuildConfiguration; buildSettings = { - ARCHS = "$(ARCHS_STANDARD_64_BIT)"; + COMBINE_HIDPI_IMAGES = YES; COPY_PHASE_STRIP = YES; FRAMEWORK_SEARCH_PATHS = ( "$(FRAMEWORK_SEARCH_PATHS)", @@ -690,7 +690,7 @@ 2A3C3F2B0992245300E404E9 /* Default */ = { isa = XCBuildConfiguration; buildSettings = { - ARCHS = "$(ARCHS_STANDARD_64_BIT)"; + COMBINE_HIDPI_IMAGES = YES; FRAMEWORK_SEARCH_PATHS = ( "$(FRAMEWORK_SEARCH_PATHS)", "$(SRCROOT)", From alan.schmitt at polytechnique.org Thu Oct 23 02:51:12 2014 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Thu, 23 Oct 2014 08:51:12 +0200 Subject: [Unison-hackers] Unison 2.48.1 beta release candidate now available for testing In-Reply-To: <27D03F1E-6C05-44CC-AF22-57A8BF722604@cis.upenn.edu> (Benjamin C. Pierce's message of "Tue, 21 Oct 2014 10:18:26 -0400") References: <27D03F1E-6C05-44CC-AF22-57A8BF722604@cis.upenn.edu> Message-ID: On 2014-10-21 10:18, "Benjamin C. Pierce" writes: > OK, I?ve fixed the problem that was biting people with OCaml 4.02. > Since there have been a lot of other improvements over the past > months, this seems like a good moment for a new beta-release. I?ll > announce it on unison-users after I hear that it?s working for a few > people, and I?ll try to promote it to stable pretty soon, since the > current stable release doesn?t work with the most current OCaml > compiler. > > Please post a message if you notice any issues. As there were a couple minor warning when building cltool.c, I committed a fix. It's building fine here, I'll test is tonight. Best, Alan -- OpenPGP Key ID : 040D0A3B4ED2E5C7 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 494 bytes Desc: not available URL: From andrex at utexas.edu Thu Oct 23 04:36:57 2014 From: andrex at utexas.edu (Andrew Schulman) Date: Thu, 23 Oct 2014 04:36:57 -0400 Subject: [Unison-hackers] Unison 2.48.1 beta release candidate now available for testing References: <27D03F1E-6C05-44CC-AF22-57A8BF722604@cis.upenn.edu> Message-ID: > OK, I?ve fixed the problem that was biting people with OCaml 4.02. Since > there have been a lot of other improvements over the past months, this > seems like a good moment for a new beta-release. I?ll announce it on > unison-users after I hear that it?s working for a few people, and I?ll try > to promote it to stable pretty soon, since the current stable release > doesn?t work with the most current OCaml compiler. > > Please post a message if you notice any issues. In Cygwin x86_64 with OCaml 4.01.1, the build fails with "Unbound module System_impl.Fs.W": ocamlopt: lwt/win/lwt_unix_impl.ml ---> lwt/win/lwt_unix_impl.cmx ocamlopt -g -I lwt -I ubase -I system -I fsmonitor -I fsmonitor/linux -I fsmonitor/windows -I system/generic -I lwt/generic -c ./lwt/win/lwt_unix_impl.ml File "./lwt/win/lwt_unix_impl.ml", line 655, characters 35-57: Error: Unbound module System_impl.Fs.W Makefile.OCaml:429: recipe for target 'lwt/win/lwt_unix_impl.cmx' failed make: *** [lwt/win/lwt_unix_impl.cmx] Error 2 From alan.schmitt at polytechnique.org Fri Oct 24 14:13:02 2014 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Fri, 24 Oct 2014 20:13:02 +0200 Subject: [Unison-hackers] Unison 2.48.1 beta release candidate now available for testing In-Reply-To: <27D03F1E-6C05-44CC-AF22-57A8BF722604@cis.upenn.edu> (Benjamin C. Pierce's message of "Tue, 21 Oct 2014 10:18:26 -0400") References: <27D03F1E-6C05-44CC-AF22-57A8BF722604@cis.upenn.edu> Message-ID: On 2014-10-21 10:18, "Benjamin C. Pierce" writes: > OK, I?ve fixed the problem that was biting people with OCaml 4.02. > Since there have been a lot of other improvements over the past > months, this seems like a good moment for a new beta-release. I?ll > announce it on unison-users after I hear that it?s working for a few > people, and I?ll try to promote it to stable pretty soon, since the > current stable release doesn?t work with the most current OCaml > compiler. > > Please post a message if you notice any issues. I just did a big synchronization between two Yosemite machines and everything went fine. Best, Alan -- OpenPGP Key ID : 040D0A3B4ED2E5C7 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 494 bytes Desc: not available URL: From bertalan at princeton.edu Fri Oct 24 15:19:58 2014 From: bertalan at princeton.edu (Tom Bertalan) Date: Fri, 24 Oct 2014 15:19:58 -0400 Subject: [Unison-hackers] Unison 2.48.1 beta release candidate now available for testing In-Reply-To: References: <27D03F1E-6C05-44CC-AF22-57A8BF722604@cis.upenn.edu> Message-ID: On Fri, Oct 24, 2014 at 2:13 PM, Alan Schmitt < alan.schmitt at polytechnique.org> wrote: > On 2014-10-21 10:18, "Benjamin C. Pierce" writes: > > > OK, I?ve fixed the problem that was biting people with OCaml 4.02. > > Since there have been a lot of other improvements over the past > > months, this seems like a good moment for a new beta-release. I?ll > > announce it on unison-users after I hear that it?s working for a few > > people, and I?ll try to promote it to stable pretty soon, since the > > current stable release doesn?t work with the most current OCaml > > compiler. > > > > Please post a message if you notice any issues. > > I just did a big synchronization between two Yosemite machines and > everything went fine. > > Best, > > Alan > > -- > OpenPGP Key ID : 040D0A3B4ED2E5C7 > > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From moonkid at posteo.org Fri Oct 24 23:29:57 2014 From: moonkid at posteo.org (moonkid at posteo.org) Date: Sat, 25 Oct 2014 05:29:57 +0200 Subject: [Unison-hackers] BugTracker? Message-ID: <20141025033001.DA8D925ACC2C@mx02.posteo.de> Is there a official BugTracker where I can see open Bugs and FeauterRequests? From crestani at informatik.uni-tuebingen.de Sat Oct 25 02:35:37 2014 From: crestani at informatik.uni-tuebingen.de (Marcus Crestani) Date: Sat, 25 Oct 2014 08:35:37 +0200 Subject: [Unison-hackers] Unison 2.48.1 beta release candidate now available for testing In-Reply-To: <27D03F1E-6C05-44CC-AF22-57A8BF722604@cis.upenn.edu> (Benjamin C. Pierce's message of "Tue, 21 Oct 2014 10:18:26 -0400") References: <27D03F1E-6C05-44CC-AF22-57A8BF722604@cis.upenn.edu> Message-ID: >>>>>"BCP" == Benjamin C Pierce writes: BCP> Please post a message if you notice any issues. Just for the record: It builds and works fine in Yosemite, except the problem with the new OS X port (UISTYLE=uimac14) I've reported before: http://lists.seas.upenn.edu/pipermail/unison-hackers/2014-May/001704.html As before, the crash is reproducible for me and does not occur when using the UISTYLE=gtk2 or the UISTYLE=text builds. I've attached Yosemite's crash logs, as they seem to contain more information than the ones from Mavericks. -- Marcus -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: crash-unison-mac-gui.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: crash-unison-mac-gui-unison.log.zip Type: application/zip Size: 211319 bytes Desc: not available URL: From bcpierce at cis.upenn.edu Sat Oct 25 06:00:38 2014 From: bcpierce at cis.upenn.edu (Benjamin C. Pierce) Date: Sat, 25 Oct 2014 06:00:38 -0400 Subject: [Unison-hackers] BugTracker? In-Reply-To: <20141025033001.DA8D925ACC2C@mx02.posteo.de> References: <20141025033001.DA8D925ACC2C@mx02.posteo.de> Message-ID: <85E51A6E-217C-4DEC-8F32-37914BED37DF@cis.upenn.edu> (Also answered this on unison-users, but in case there?s anybody that reads this and not that?) We don?t currently have a bug tracking system, mainly because we only have small number of people wanting to spend time investigating and fixing bugs at the moment and we don?t want to spend any of their time setting up infrastructure. If there?s a standard one that doesn?t take too much time to get going, I wouldn?t object, but for the moment the best place to look for both bugs and feature request is the archives of the unison-users and unison-hackers mailing lists. Best, - Benjamin On Oct 24, 2014, at 11:29 PM, moonkid at posteo.org wrote: > Is there a official BugTracker where I can see open Bugs and > FeauterRequests? > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From bcpierce at cis.upenn.edu Sat Oct 25 06:16:45 2014 From: bcpierce at cis.upenn.edu (Benjamin C. Pierce) Date: Sat, 25 Oct 2014 06:16:45 -0400 Subject: [Unison-hackers] Unison 2.48.1 beta release candidate now available for testing In-Reply-To: References: <27D03F1E-6C05-44CC-AF22-57A8BF722604@cis.upenn.edu> Message-ID: I?m not set up to compile on Windows, but it looks like ./system/win/system_impl.ml is where this should be coming from? On Oct 23, 2014, at 4:36 AM, Andrew Schulman wrote: >> OK, I?ve fixed the problem that was biting people with OCaml 4.02. Since >> there have been a lot of other improvements over the past months, this >> seems like a good moment for a new beta-release. I?ll announce it on >> unison-users after I hear that it?s working for a few people, and I?ll try >> to promote it to stable pretty soon, since the current stable release >> doesn?t work with the most current OCaml compiler. >> >> Please post a message if you notice any issues. > > In Cygwin x86_64 with OCaml 4.01.1, the build fails with "Unbound module > System_impl.Fs.W": > > ocamlopt: lwt/win/lwt_unix_impl.ml ---> lwt/win/lwt_unix_impl.cmx > ocamlopt -g -I lwt -I ubase -I system -I fsmonitor -I fsmonitor/linux -I > fsmonitor/windows -I system/generic -I lwt/generic -c > ./lwt/win/lwt_unix_impl.ml > File "./lwt/win/lwt_unix_impl.ml", line 655, characters 35-57: > Error: Unbound module System_impl.Fs.W > Makefile.OCaml:429: recipe for target 'lwt/win/lwt_unix_impl.cmx' failed > make: *** [lwt/win/lwt_unix_impl.cmx] Error 2 > > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From moonkid at posteo.org Sat Oct 25 09:11:23 2014 From: moonkid at posteo.org (moonkid at posteo.org) Date: Sat, 25 Oct 2014 15:11:23 +0200 Subject: [Unison-hackers] BugTracker? In-Reply-To: <85E51A6E-217C-4DEC-8F32-37914BED37DF@cis.upenn.edu> References: <20141025033001.DA8D925ACC2C@mx02.posteo.de> <85E51A6E-217C-4DEC-8F32-37914BED37DF@cis.upenn.edu> Message-ID: <20141025131139.0ACAE25A3DD6@mx02.posteo.de> On 2014-10-25 06:00 "Benjamin C. Pierce" wrote: > We don?t currently have a bug tracking system, > ... > I wouldn?t object, but for > the moment the best place to look for both bugs and feature request > is the archives of the unison-users and unison-hackers mailing lists. Ok, I understand this. But does anyone manage a list of the currently open bugs and requests? Let's try the other way: ;) Please give me the simplest open bug you have currently. I try to became warm with Unison and Ocaml and want to spend the time effective. From moonkid at posteo.org Sat Oct 25 09:37:11 2014 From: moonkid at posteo.org (moonkid at posteo.org) Date: Sat, 25 Oct 2014 15:37:11 +0200 Subject: [Unison-hackers] [FeauterRequest] doc: improving build-unix Message-ID: <20141025133728.3F3E425A3DC6@mx02.posteo.de> While I tried to build Unison from scratch with the current documentation I found some problems. I would suggest some improvements of the relevant docu-part. 1. make targets There is no explanation of the possible make targets. There is just a simple sentence with make-calls that should be made but without explanation what they are exactly doing. And how would "make install" affect a parallel existing Unison stable-version (or different version)? Or why are the doc-files (pdf & html) not "build" while "make"? There is a Makefile in the doc-folder but never touched as I saw. 2. foreign build There are to much informations about non-unison build-processes. How to build OCaml, some libs, etc. This confuses some readers (me! ;) ) and creates redundant informations. A simple link to the information how to build something should be enough there. 3. build libs needful? The docu suggest that everything (ocaml, libs, ...) should be build from scratch. This is to much work and not needed (as I see in my case). I installed everything from my Ubuntu-repositories. The formulation of the text should be changed in a way that the reader know that he can but don't need to build all the needed parts. 4. detailed parts description Including my points below generally there should be more structured(!) information about all needed parts. A point-by-point list. 5. Pango There is no word about Pango. What is it why do I need it, etc. The gui-build doesn't work without it. And I did a lot of work to found out which of my repository packages I needed. What do you thing about this modifications? I would implement them. Do I understand it right that all relevant doc-files are build from "docs/unison-manual.tex"? So I should modify it. Or did I miss any other files? From bcpierce at cis.upenn.edu Sun Oct 26 12:44:13 2014 From: bcpierce at cis.upenn.edu (Benjamin C. Pierce) Date: Sun, 26 Oct 2014 12:44:13 -0400 Subject: [Unison-hackers] BugTracker? In-Reply-To: <20141025131139.0ACAE25A3DD6@mx02.posteo.de> References: <20141025033001.DA8D925ACC2C@mx02.posteo.de> <85E51A6E-217C-4DEC-8F32-37914BED37DF@cis.upenn.edu> <20141025131139.0ACAE25A3DD6@mx02.posteo.de> Message-ID: > Let's try the other way: ;) > Please give me the simplest open bug you have currently. Here?s an amusing one that came up quite recently. It?s not completely simple, but not extremely hard to fix either, I think. John Hughes and I decided (with Thomas Arts and Ulf Norell) to do a little QuickCheck-style property based random testing of Unison. We used their Erlang version of QuickCheck, which has very nice support for generating state-machine-like test sequences. And, lo and behold, in the first two hours of testing we found a significant (and subtle) bug! What QuickCheck discovered was that, if Unison propagates a changed version of a file and, on the receiving replica, this file is immediately (within one second) overwritten by some other process with new contents of exactly the same size, then running Unison again will not propagate the newest change back to the first side. Best, - Benjamin -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcpierce at cis.upenn.edu Sun Oct 26 12:44:19 2014 From: bcpierce at cis.upenn.edu (Benjamin C. Pierce) Date: Sun, 26 Oct 2014 12:44:19 -0400 Subject: [Unison-hackers] [FeauterRequest] doc: improving build-unix In-Reply-To: <20141025133728.3F3E425A3DC6@mx02.posteo.de> References: <20141025133728.3F3E425A3DC6@mx02.posteo.de> Message-ID: <2C98964E-20AF-4B7F-BD30-992B99024C80@cis.upenn.edu> Hi, > I would suggest some improvements of the relevant docu-part. > Improvements always welcome! > What do you thing about this modifications? > I would implement them. These all seem like good improvements. > Do I understand it right that all relevant doc-files are build from > "docs/unison-manual.tex"? So I should modify it. Or did I miss any > other files? Yes, this is the one. You would need lynx and (a particular version of) hevea to process the files into text strings, but you can just fix the tex version and let me do the rest. - Benjamin From bcpierce at cis.upenn.edu Sun Oct 26 12:55:40 2014 From: bcpierce at cis.upenn.edu (Benjamin C. Pierce) Date: Sun, 26 Oct 2014 12:55:40 -0400 Subject: [Unison-hackers] BugTracker? In-Reply-To: References: <20141025033001.DA8D925ACC2C@mx02.posteo.de> <85E51A6E-217C-4DEC-8F32-37914BED37DF@cis.upenn.edu> <20141025131139.0ACAE25A3DD6@mx02.posteo.de> Message-ID: <678451A0-707A-4461-BAA7-86EDC36BA528@cis.upenn.edu> (Sorry ? hit Send too soon?) Clearly, the best way to solve this problem is to get more accurate mtime information from the OS. I know that at least some modern Linuxes can give mtimes in nanoseconds, which should really be good enough. I?m not sure about OSX or Windows. Another simple way would be to make Unison re-fingerprint each file that it?s transferred (on both source and target sides) after waiting for one second (or two seconds, on FAT32 filesystems) and take appropriate action if things have changed out from under it. A less simple but perhaps more robust way is: While reconciling, record the ?last synchronized time? for each file in the archive. On the next sync, if a file?s last sync time is equal to its modtime, then fingerprint it again just to be sure (rather than trusting the ?equal mtimes and equal inode numbers? optimization). Anybody have thoughts about this? (Either the proposed solutions or the seriousness or not of the basic problem.) - B On Oct 26, 2014, at 12:44 PM, Benjamin C. Pierce wrote: >> Let's try the other way: ;) >> Please give me the simplest open bug you have currently. > > Here?s an amusing one that came up quite recently. It?s not completely simple, but not extremely hard to fix either, I think. > > John Hughes and I decided (with Thomas Arts and Ulf Norell) to do a little QuickCheck-style property based random testing of Unison. We used their Erlang version of QuickCheck, which has very nice support for generating state-machine-like test sequences. And, lo and behold, in the first two hours of testing we found a significant (and subtle) bug! > > What QuickCheck discovered was that, if Unison propagates a changed version of a file and, on the receiving replica, this file is immediately (within one second) overwritten by some other process with new contents of exactly the same size, then running Unison again will not propagate the newest change back to the first side. > > Best, > > - Benjamin > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From moonkid at posteo.org Sun Oct 26 13:44:00 2014 From: moonkid at posteo.org (moonkid at posteo.org) Date: Sun, 26 Oct 2014 18:44:00 +0100 Subject: [Unison-hackers] [FeauterRequest] doc: improving build-unix In-Reply-To: <2C98964E-20AF-4B7F-BD30-992B99024C80@cis.upenn.edu> References: <20141025133728.3F3E425A3DC6@mx02.posteo.de> <2C98964E-20AF-4B7F-BD30-992B99024C80@cis.upenn.edu> Message-ID: <20141026174510.A9E4525A3DC8@mx02.posteo.de> On 2014-10-26 12:44 "Benjamin C. Pierce" wrote: > These all seem like good improvements. Can you explain to me the Pango-thing? I think it is not enough just to tell that it is in the debian-/ubuntu-package xqz.deb and can be installed with apt-get. There should be a bit background info (like with gtk2) to make the user able to found out itself which package is needed on his own system. Do I describe it correct that it is a part of Gtk2? This hint for example would result (for me) in a bash-call like this "apt-cache search pango | grep gtk2" ;) > fix the tex version and let me do the rest. No prob. I am fine with *TeX. From bcpierce at cis.upenn.edu Sun Oct 26 17:02:54 2014 From: bcpierce at cis.upenn.edu (Benjamin C. Pierce) Date: Sun, 26 Oct 2014 17:02:54 -0400 Subject: [Unison-hackers] [FeauterRequest] doc: improving build-unix In-Reply-To: <20141026174510.A9E4525A3DC8@mx02.posteo.de> References: <20141025133728.3F3E425A3DC6@mx02.posteo.de> <2C98964E-20AF-4B7F-BD30-992B99024C80@cis.upenn.edu> <20141026174510.A9E4525A3DC8@mx02.posteo.de> Message-ID: <6B4A0CAA-02E4-42E0-B3B7-3EFE37DEBEAC@cis.upenn.edu> I?m afraid I?m not up on the internals of the gtk2 interface. Maybe someone else can answer? - B On Oct 26, 2014, at 1:44 PM, wrote: > On 2014-10-26 12:44 "Benjamin C. Pierce" wrote: >> These all seem like good improvements. > > Can you explain to me the Pango-thing? > > I think it is not enough just to tell that it is in the > debian-/ubuntu-package xqz.deb and can be installed with apt-get. > There should be a bit background info (like with gtk2) to make the user > able to found out itself which package is needed on his own system. > > Do I describe it correct that it is a part of Gtk2? This hint for > example would result (for me) in a bash-call like this > "apt-cache search pango | grep gtk2" > > ;) > >> fix the tex version and let me do the rest. > > No prob. I am fine with *TeX. > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From ats at acm.org Mon Oct 27 10:59:41 2014 From: ats at acm.org (Alan Shutko) Date: Mon, 27 Oct 2014 09:59:41 -0500 Subject: [Unison-hackers] [FeauterRequest] doc: improving build-unix In-Reply-To: <6B4A0CAA-02E4-42E0-B3B7-3EFE37DEBEAC@cis.upenn.edu> References: <20141025133728.3F3E425A3DC6@mx02.posteo.de> <2C98964E-20AF-4B7F-BD30-992B99024C80@cis.upenn.edu> <20141026174510.A9E4525A3DC8@mx02.posteo.de> <6B4A0CAA-02E4-42E0-B3B7-3EFE37DEBEAC@cis.upenn.edu> Message-ID: Pango is a text-rendering library that is a dependency of GTK 2. In general, each distribution family has a way to install the GTK dev libraries in a single command, including all the dependencies like Pango. I don?t know each of them offhand anymore (it?s been a while since I ran Linux on the desktop). For Redhat and derived distributions (e.g. Centos, Fedora) it?s something like yum install gtk2-devel For Debian-based distributions, it?s often something like apt-get install libgtk2.0-dev My suggestion would be to do some checking for the major distributions and put in specific instructions for each. > On Oct 26, 2014, at 4:02 PM, Benjamin C. Pierce > wrote: > > I?m afraid I?m not up on the internals of the gtk2 interface. Maybe someone else can answer? > > - B > -------------- next part -------------- An HTML attachment was scrubbed... URL: From moonkid at posteo.org Mon Oct 27 16:44:31 2014 From: moonkid at posteo.org (moonkid at posteo.org) Date: Mon, 27 Oct 2014 21:44:31 +0100 Subject: [Unison-hackers] [FeauterRequest] doc: improving build-unix In-Reply-To: References: <20141025133728.3F3E425A3DC6@mx02.posteo.de> <2C98964E-20AF-4B7F-BD30-992B99024C80@cis.upenn.edu> <20141026174510.A9E4525A3DC8@mx02.posteo.de> <6B4A0CAA-02E4-42E0-B3B7-3EFE37DEBEAC@cis.upenn.edu> Message-ID: <20141027204444.C2B7725AF505@mx02.posteo.de> On 2014-10-27 09:59 Alan Shutko wrote: > In general, each distribution family has a way to install the GTK dev > libraries in a single command, including all the dependencies like > Pango. But the bindings to Ocaml are missing. That was the problem. > apt-get install libgtk2.0-dev I did some tests and found out. libgtk2.0-dev is not enough. On Ubuntu (14.04.1) you need "liblablgtk-extras-ocaml-dev", too. With its dependencies Ocaml itself is installed, too. But I can't found any "Pango" in the package-details. ;) But this (un- or bad-documented packages) is a Debian problem. I will deal with it in the new doc. From moonkid at posteo.org Mon Oct 27 16:48:04 2014 From: moonkid at posteo.org (moonkid at posteo.org) Date: Mon, 27 Oct 2014 21:48:04 +0100 Subject: [Unison-hackers] BugTracker? In-Reply-To: <678451A0-707A-4461-BAA7-86EDC36BA528@cis.upenn.edu> References: <20141025033001.DA8D925ACC2C@mx02.posteo.de> <85E51A6E-217C-4DEC-8F32-37914BED37DF@cis.upenn.edu> <20141025131139.0ACAE25A3DD6@mx02.posteo.de> <678451A0-707A-4461-BAA7-86EDC36BA528@cis.upenn.edu> Message-ID: <20141027204812.A607225A2126@mx02.posteo.de> Dear Benjamin, if this is really the "easiest bug" you currently have - Unison is nearly perfect. :D The problem you described is kind of to hot for me. I wrote some sync-stuff for myself, too and know how disastrous small modifications could be (losing TBs of data!). I am not sure but maybe it is a little bit to much for me to start. But... Is there a detailed documentation about the sync-process, the checkings and decisions of the algorithm? Is there a human readble text (not the code) to understand how the algorithm work? From bcpierce at cis.upenn.edu Mon Oct 27 17:25:01 2014 From: bcpierce at cis.upenn.edu (Benjamin C. Pierce) Date: Mon, 27 Oct 2014 17:25:01 -0400 Subject: [Unison-hackers] BugTracker? In-Reply-To: <20141027204812.A607225A2126@mx02.posteo.de> References: <20141025033001.DA8D925ACC2C@mx02.posteo.de> <85E51A6E-217C-4DEC-8F32-37914BED37DF@cis.upenn.edu> <20141025131139.0ACAE25A3DD6@mx02.posteo.de> <678451A0-707A-4461-BAA7-86EDC36BA528@cis.upenn.edu> <20141027204812.A607225A2126@mx02.posteo.de> Message-ID: <50ED250B-D5D1-4505-A5D7-81F441A71A46@cis.upenn.edu> There are certainly other bugs and missing features (check the archives of the mailing lists for suggestions ? there?s also a TODO file, but it?s pretty old), but this is the only correctness-critical one that I?m aware of at the moment. For a good overview of how Unison works internally, see the tech report ?What?s in Unison? by me and Jerome. - Benjamin On Oct 27, 2014, at 4:48 PM, wrote: > Dear Benjamin, > > if this is really the "easiest bug" you currently have - Unison is > nearly perfect. :D > > The problem you described is kind of to hot for me. I wrote some > sync-stuff for myself, too and know how disastrous small modifications > could be (losing TBs of data!). > > I am not sure but maybe it is a little bit to much for me to start. > > But... > Is there a detailed documentation about the sync-process, the checkings > and decisions of the algorithm? Is there a human readble text (not the > code) to understand how the algorithm work? > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From tim at loqu8.com Mon Oct 27 17:35:37 2014 From: tim at loqu8.com (E. Timothy Uy) Date: Mon, 27 Oct 2014 14:35:37 -0700 Subject: [Unison-hackers] BugTracker? In-Reply-To: <50ED250B-D5D1-4505-A5D7-81F441A71A46@cis.upenn.edu> References: <20141025033001.DA8D925ACC2C@mx02.posteo.de> <85E51A6E-217C-4DEC-8F32-37914BED37DF@cis.upenn.edu> <20141025131139.0ACAE25A3DD6@mx02.posteo.de> <678451A0-707A-4461-BAA7-86EDC36BA528@cis.upenn.edu> <20141027204812.A607225A2126@mx02.posteo.de> <50ED250B-D5D1-4505-A5D7-81F441A71A46@cis.upenn.edu> Message-ID: I would propose something standard like GitHub to host everything and track bugs. On Mon, Oct 27, 2014 at 2:25 PM, Benjamin C. Pierce wrote: > There are certainly other bugs and missing features (check the archives of > the mailing lists for suggestions ? there?s also a TODO file, but it?s > pretty old), but this is the only correctness-critical one that I?m aware > of at the moment. > > For a good overview of how Unison works internally, see the tech report > ?What?s in Unison? by me and Jerome. > > - Benjamin > > > > On Oct 27, 2014, at 4:48 PM, > wrote: > > > Dear Benjamin, > > > > if this is really the "easiest bug" you currently have - Unison is > > nearly perfect. :D > > > > The problem you described is kind of to hot for me. I wrote some > > sync-stuff for myself, too and know how disastrous small modifications > > could be (losing TBs of data!). > > > > I am not sure but maybe it is a little bit to much for me to start. > > > > But... > > Is there a detailed documentation about the sync-process, the checkings > > and decisions of the algorithm? Is there a human readble text (not the > > code) to understand how the algorithm work? > > _______________________________________________ > > Unison-hackers mailing list > > Unison-hackers at lists.seas.upenn.edu > > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers > > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcpierce at cis.upenn.edu Tue Oct 28 05:33:57 2014 From: bcpierce at cis.upenn.edu (Benjamin C. Pierce) Date: Tue, 28 Oct 2014 05:33:57 -0400 Subject: [Unison-hackers] BugTracker? In-Reply-To: References: <20141025033001.DA8D925ACC2C@mx02.posteo.de> <85E51A6E-217C-4DEC-8F32-37914BED37DF@cis.upenn.edu> <20141025131139.0ACAE25A3DD6@mx02.posteo.de> <678451A0-707A-4461-BAA7-86EDC36BA528@cis.upenn.edu> <20141027204812.A607225A2126@mx02.posteo.de> <50ED250B-D5D1-4505-A5D7-81F441A71A46@cis.upenn.edu> Message-ID: Yes, moving to Github might be a reasonable step at this point ? it would certainly simplify issue tracking, among other things. One specific technical issue needs to be sorted out to make this happen: The way that Unison?s version number is embedded in the code (so that the binary knows which version of the source it was built from) is quite SVN-specific. If people feel motivated to help with a move to github, taking a look at how this might best be done in the Git context (manually? by somehow approximating what SVN does? by some different automatic mechanism?) would be a big step in the right direction. The file mkProjectInfo.ml is the place to look. Should be self-explanatory. - Benjamin On Oct 27, 2014, at 5:35 PM, E. Timothy Uy wrote: > I would propose something standard like GitHub to host everything and track bugs. > > On Mon, Oct 27, 2014 at 2:25 PM, Benjamin C. Pierce wrote: > There are certainly other bugs and missing features (check the archives of the mailing lists for suggestions ? there?s also a TODO file, but it?s pretty old), but this is the only correctness-critical one that I?m aware of at the moment. > > For a good overview of how Unison works internally, see the tech report ?What?s in Unison? by me and Jerome. > > - Benjamin > > > > On Oct 27, 2014, at 4:48 PM, wrote: > > > Dear Benjamin, > > > > if this is really the "easiest bug" you currently have - Unison is > > nearly perfect. :D > > > > The problem you described is kind of to hot for me. I wrote some > > sync-stuff for myself, too and know how disastrous small modifications > > could be (losing TBs of data!). > > > > I am not sure but maybe it is a little bit to much for me to start. > > > > But... > > Is there a detailed documentation about the sync-process, the checkings > > and decisions of the algorithm? Is there a human readble text (not the > > code) to understand how the algorithm work? > > _______________________________________________ > > Unison-hackers mailing list > > Unison-hackers at lists.seas.upenn.edu > > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers > > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers > > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers -------------- next part -------------- An HTML attachment was scrubbed... URL: From moonkid at posteo.org Wed Oct 29 12:34:21 2014 From: moonkid at posteo.org (moonkid at posteo.org) Date: Wed, 29 Oct 2014 17:34:21 +0100 Subject: [Unison-hackers] BugTracker? In-Reply-To: <50ED250B-D5D1-4505-A5D7-81F441A71A46@cis.upenn.edu> References: <20141025033001.DA8D925ACC2C@mx02.posteo.de> <85E51A6E-217C-4DEC-8F32-37914BED37DF@cis.upenn.edu> <20141025131139.0ACAE25A3DD6@mx02.posteo.de> <678451A0-707A-4461-BAA7-86EDC36BA528@cis.upenn.edu> <20141027204812.A607225A2126@mx02.posteo.de> <50ED250B-D5D1-4505-A5D7-81F441A71A46@cis.upenn.edu> Message-ID: <20141029172655.0577F25B17D3@mx02.posteo.de> On 2014-10-27 17:25 "Benjamin C. Pierce" wrote: > check the archives of the mailing lists for suggestions I steped back to 2011 but found nothing. Maybe the reason is that the Bug-postings are not marked (e.g. "[BUG]"). I can not read all thread-opening posts in the archive. :) > For a good overview of how Unison works internally, see the tech > report ?What?s in Unison? by me and Jerome. Awesome stuff... From moonkid at posteo.org Wed Oct 29 13:26:28 2014 From: moonkid at posteo.org (moonkid at posteo.org) Date: Wed, 29 Oct 2014 18:26:28 +0100 Subject: [Unison-hackers] [Bug] Website: "(Non-)development status": unluky formulation Message-ID: <20141029172655.0576525AF529@mx02.posteo.de> My Bug-Report depends on the current version of this page . It describe the current development status of Unison. I read it and understand it. I understand what the author means. But for persons who are not familar with Unison could have false beliefs about the status. For example the german Ubuntu-Wiki-Page for Unison tell the reader that Unison is not active and wont be improved in the future. The read understand there: Unison is dead! You see? First of all the first two sentences should reformulated. They have "negative" sound. Make them "positive". My english is bad and so I am not able to give you a nice and well formulated example. e.g. The development goals are reached. The plan is fulfilled so that currently there is no plan (and no need!) for big new features, etc. All active(!) developers and helpers are doing their work in freetime without schedule. Sometimes with much time capacity sometimes with less. Understand what I mean? ;) From moonkid at posteo.org Wed Oct 29 13:59:40 2014 From: moonkid at posteo.org (moonkid at posteo.org) Date: Wed, 29 Oct 2014 18:59:40 +0100 Subject: [Unison-hackers] [maybe-BUG] unison-manual.tex only with make Message-ID: <20141029180005.65BD9258D279@mx02.posteo.de> It costs me time to find out how to build unsion-manual.tex. I can only build it with "make". It makes sence in a source-repository of course. But there should be a way or a informative error message when someone try to build a tex-file the usual way - with a tex-environment. "textdirectives.tex not found." No hint about it where or what it is! I think the simplest way would be to some tex-code where it is \input'ed with a message like "Don't use your tex-environment. Please use 'make' to build unison-manual.tex." What do you think? From moonkid at posteo.org Thu Oct 30 13:23:31 2014 From: moonkid at posteo.org (moonkid at posteo.org) Date: Thu, 30 Oct 2014 18:23:31 +0100 Subject: [Unison-hackers] [PATCH] doc/local.tex (was: [maybe-BUG] unison-manual.tex only with make) In-Reply-To: <20141029180005.65BD9258D279@mx02.posteo.de> References: <20141029180005.65BD9258D279@mx02.posteo.de> Message-ID: <20141030172352.6DCC225A3DCD@mx02.posteo.de> On 2014-10-29 18:59 wrote: > It costs me time to find out how to build unsion-manual.tex. > > I can only build it with "make". It makes sence in a source-repository > of course. > > But there should be a way or a informative error message when someone > try to build a tex-file the usual way - with a tex-environment. > > "textdirectives.tex not found." I build made a patch for this. What do you think? PS: Is this way of creating and distributing a patch ok? -------------- next part -------------- A non-text attachment was scrubbed... Name: local.tex.diff Type: text/x-patch Size: 685 bytes Desc: not available URL: From moonkid at posteo.org Thu Oct 30 13:49:41 2014 From: moonkid at posteo.org (moonkid at posteo.org) Date: Thu, 30 Oct 2014 18:49:41 +0100 Subject: [Unison-hackers] [FeauterRequest] doc: improving build-unix In-Reply-To: <2C98964E-20AF-4B7F-BD30-992B99024C80@cis.upenn.edu> References: <20141025133728.3F3E425A3DC6@mx02.posteo.de> <2C98964E-20AF-4B7F-BD30-992B99024C80@cis.upenn.edu> Message-ID: <20141030174959.620C1258D247@mx02.posteo.de> On 2014-10-26 12:44 "Benjamin C. Pierce" wrote: > Improvements always welcome! My english is far from perfect and I think some persons would modify my text before patching it to the sources. So I would suggest that the "admin" should open a construction-like page on the Unison-wiki. It would be a nice base to see, discuss and modify the text. And it is possible to review the modifications in the page history. After uploading the patch the page can be deleted of course. Maybe: "Construction.unix-build-doc" From bcpierce at cis.upenn.edu Thu Oct 30 14:15:49 2014 From: bcpierce at cis.upenn.edu (Benjamin C. Pierce) Date: Thu, 30 Oct 2014 14:15:49 -0400 Subject: [Unison-hackers] [PATCH] doc/local.tex (was: [maybe-BUG] unison-manual.tex only with make) In-Reply-To: <20141030172352.6DCC225A3DCD@mx02.posteo.de> References: <20141029180005.65BD9258D279@mx02.posteo.de> <20141030172352.6DCC225A3DCD@mx02.posteo.de> Message-ID: <5EE37099-49C6-406A-A6C3-945BE1611605@cis.upenn.edu> Thanks ? I?ve put it in (my local copy of) the trunk. - B On Oct 30, 2014, at 1:23 PM, moonkid at posteo.org wrote: > On 2014-10-29 18:59 wrote: >> It costs me time to find out how to build unsion-manual.tex. >> >> I can only build it with "make". It makes sence in a source-repository >> of course. >> >> But there should be a way or a informative error message when someone >> try to build a tex-file the usual way - with a tex-environment. >> >> "textdirectives.tex not found." > > I build made a patch for this. > What do you think? > > PS: Is this way of creating and distributing a patch ok?_______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From bcpierce at cis.upenn.edu Thu Oct 30 14:16:31 2014 From: bcpierce at cis.upenn.edu (Benjamin C. Pierce) Date: Thu, 30 Oct 2014 14:16:31 -0400 Subject: [Unison-hackers] [FeauterRequest] doc: improving build-unix In-Reply-To: <20141030174959.620C1258D247@mx02.posteo.de> References: <20141025133728.3F3E425A3DC6@mx02.posteo.de> <2C98964E-20AF-4B7F-BD30-992B99024C80@cis.upenn.edu> <20141030174959.620C1258D247@mx02.posteo.de> Message-ID: Unless there are going to be a lot of changes, I think the simplest way is for you to just make them, send me a patch file, and let me check the edits. I can do minor English cleanup. - B On Oct 30, 2014, at 1:49 PM, moonkid at posteo.org wrote: > On 2014-10-26 12:44 "Benjamin C. Pierce" wrote: >> Improvements always welcome! > > My english is far from perfect and I think some persons would modify my > text before patching it to the sources. > > So I would suggest that the "admin" should open a construction-like > page on the Unison-wiki. It would be a nice base to see, discuss and > modify the text. And it is possible to review the modifications in the > page history. > After uploading the patch the page can be deleted of course. > Maybe: "Construction.unix-build-doc" > > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From moonkid at posteo.org Thu Oct 30 17:20:53 2014 From: moonkid at posteo.org (moonkid at posteo.org) Date: Thu, 30 Oct 2014 22:20:53 +0100 Subject: [Unison-hackers] [PATCH] doc/local.tex (was: [maybe-BUG] unison-manual.tex only with make) In-Reply-To: <5EE37099-49C6-406A-A6C3-945BE1611605@cis.upenn.edu> References: <20141029180005.65BD9258D279@mx02.posteo.de> <20141030172352.6DCC225A3DCD@mx02.posteo.de> <5EE37099-49C6-406A-A6C3-945BE1611605@cis.upenn.edu> Message-ID: <20141030212141.7CEF2258D243@mx02.posteo.de> On 2014-10-30 14:15 "Benjamin C. Pierce" wrote: > Thanks ? I?ve put it in (my local copy of) the trunk. I am not sure with "hevea" but it looks like that a HTML can not be build with hevea because of my patch. But the default build system doesn't build a HTML file. So I think it is no big deal.