From geneh at shaw.ca Wed Jun 2 00:12:48 2010 From: geneh at shaw.ca (Gene Horodecki) Date: Tue, 01 Jun 2010 23:12:48 -0500 Subject: [Unison-hackers] Problem building unison under cygwin Message-ID: <4C05DA40.9070701@shaw.ca> Hi there.. I've updated my cygwin, and installed make, ocaml and ctags.. When I go to trunk/src and I try to make NATIVE=false or make UISTYLE=text I get the following error: Cannot load required shared library dllstr. Reason: dynamic loading not supported on this platform. Does anyone know what this means? What am I doing wrong? From Jerome.Vouillon at pps.jussieu.fr Wed Jun 2 04:14:00 2010 From: Jerome.Vouillon at pps.jussieu.fr (Jerome Vouillon) Date: Wed, 2 Jun 2010 10:14:00 +0200 Subject: [Unison-hackers] Problem building unison under cygwin In-Reply-To: <4C05DA40.9070701@shaw.ca> References: <4C05DA40.9070701@shaw.ca> Message-ID: <20100602081400.GA21898@pps.jussieu.fr> On Tue, Jun 01, 2010 at 11:12:48PM -0500, Gene Horodecki wrote: > Hi there.. I've updated my cygwin, and installed make, ocaml and ctags.. > When I go to trunk/src and I try to make NATIVE=false or make > UISTYLE=text I get the following error: > > Cannot load required shared library dllstr. > Reason: dynamic loading not supported on this platform. Using both NATIVE=false and UISTYLE=text is indeed the easiest way to compile under Windows. Could you try the attached patch? It should fix your problem. -- Jerome From geneh at shaw.ca Wed Jun 2 08:44:51 2010 From: geneh at shaw.ca (Gene Horodecki) Date: Wed, 02 Jun 2010 07:44:51 -0500 Subject: [Unison-hackers] Problem building unison under cygwin In-Reply-To: <20100602081400.GA21898@pps.jussieu.fr> References: <4C05DA40.9070701@shaw.ca> <20100602081400.GA21898@pps.jussieu.fr> Message-ID: <4C065243.20807@shaw.ca> On 06/02/2010 3:14 AM, Jerome Vouillon wrote: > On Tue, Jun 01, 2010 at 11:12:48PM -0500, Gene Horodecki wrote: > >> Hi there.. I've updated my cygwin, and installed make, ocaml and ctags.. >> When I go to trunk/src and I try to make NATIVE=false or make >> UISTYLE=text I get the following error: >> >> Cannot load required shared library dllstr. >> Reason: dynamic loading not supported on this platform. >> > Using both NATIVE=false and UISTYLE=text is indeed the easiest way to > compile under Windows. > > Could you try the attached patch? It should fix your problem. > > -- Jerome > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers > I didn't seem to get an attachment? From Jerome.Vouillon at pps.jussieu.fr Wed Jun 2 09:17:22 2010 From: Jerome.Vouillon at pps.jussieu.fr (Jerome Vouillon) Date: Wed, 2 Jun 2010 15:17:22 +0200 Subject: [Unison-hackers] Problem building unison under cygwin In-Reply-To: <4C065243.20807@shaw.ca> References: <4C05DA40.9070701@shaw.ca> <20100602081400.GA21898@pps.jussieu.fr> <4C065243.20807@shaw.ca> Message-ID: <20100602131722.GA32308@pps.jussieu.fr> On Wed, Jun 02, 2010 at 07:44:51AM -0500, Gene Horodecki wrote: > On 06/02/2010 3:14 AM, Jerome Vouillon wrote: > > On Tue, Jun 01, 2010 at 11:12:48PM -0500, Gene Horodecki wrote: [...] > >> Cannot load required shared library dllstr. > >> Reason: dynamic loading not supported on this platform. > > > > Could you try the attached patch? It should fix your problem. > > I didn't seem to get an attachment? Sorry, I forgot about it... -- Jerome -------------- next part -------------- Index: Makefile =================================================================== --- Makefile (r?vision 448) +++ Makefile (copie de travail) @@ -60,11 +60,11 @@ # NAME, VERSION, and MAJORVERSION, automatically generated -include Makefile.ProjectInfo -Makefile.ProjectInfo: mkProjectInfo.ml $(wildcard ../.bzr/branch/last-revision) - ocaml str.cma unix.cma ./mkProjectInfo.ml > $@ +Makefile.ProjectInfo: mkProjectInfo $(wildcard ../.bzr/branch/last-revision) + ./mkProjectInfo > $@ -#mkProjectInfo: mkProjectInfo.ml -# ocamlc -o $@ unix.cma str.cma $^ +mkProjectInfo: mkProjectInfo.ml + ocamlc -o $@ unix.cma str.cma $^ clean:: $(RM) mkProjectInfo From andrex at alumni.utexas.net Wed Jun 2 10:20:33 2010 From: andrex at alumni.utexas.net (Andrew Schulman) Date: Wed, 02 Jun 2010 10:20:33 -0400 Subject: [Unison-hackers] Problem building unison under cygwin References: <4C05DA40.9070701@shaw.ca> <20100602081400.GA21898@pps.jussieu.fr> <4C065243.20807@shaw.ca> <20100602131722.GA32308@pps.jussieu.fr> Message-ID: <2kpc06po62mquhf16oq89ou1is6cdqbp42@4ax.com> > On Wed, Jun 02, 2010 at 07:44:51AM -0500, Gene Horodecki wrote: > > On 06/02/2010 3:14 AM, Jerome Vouillon wrote: > > > On Tue, Jun 01, 2010 at 11:12:48PM -0500, Gene Horodecki wrote: > [...] > > >> Cannot load required shared library dllstr. > > >> Reason: dynamic loading not supported on this platform. > > > > > > Could you try the attached patch? It should fix your problem. > > > > I didn't seem to get an attachment? > > Sorry, I forgot about it... I've also just been trying to build unison 2.40 for Cygwin, with UISTYLE=text. Jerome, your patch gets past the first problem, but the build fails later with ocamlopt: system/system_win_stubs.c ---> system/system_win_stubs.o ocamlopt -I lwt -I ubase -I system -I system/win -I lwt/win -ccopt "-o "./system/system_win_stubs.o -c ./system/system_win_stubs.c ./system/system_win_stubs.c:19: error: expected specifier-qualifier-list before 'SOCKET' ./system/system_win_stubs.c: In function 'copy_wstring': ./system/system_win_stubs.c:31: warning: implicit declaration of function 'wcslen' ./system/system_win_stubs.c: In function 'w_create_process_native': ./system/system_win_stubs.c:453: warning: unused variable 'h' make[1]: *** [system/system_win_stubs.o] Error 2 I've tried removing system_win_stubs.c from Makefile.OCaml, by the patch below. But the linking step fails with: No implementations provided for the following modules: System_win referenced from system/win/system_impl.cmx Any ideas? One thing to know is that in Cygwin we're still stuck with ocaml 3.08.1 ATM. Several people have tried to build a later version for Cygwin, but it's a bear and no one has managed it yet. Could the build failure be because of anything missing in ocaml 3.08.1? Andrew. diff -urN unison-2.40.16.orig/Makefile.OCaml unison-2.40.16/Makefile.OCaml --- unison-2.40.16.orig/Makefile.OCaml 2010-04-15 13:29:31.000000000 -0400 +++ unison-2.40.16/Makefile.OCaml 2010-06-01 12:07:24.493984400 -0400 @@ -120,8 +120,8 @@ ifeq ($(OSARCH),win32gnuc) CWD=. EXEC_EXT=.exe - COBJS+=system/system_win_stubs$(OBJ_EXT) lwt/lwt_unix_stubs$(OBJ_EXT) - WINOBJS=system/system_win.cmo + COBJS+=lwt/lwt_unix_stubs$(OBJ_EXT) + WINOBJS= SYSTEM=win CLIBS+=-cclib win32rc/unison.res.lib STATIC=false # Cygwin is not MinGW :-( From geneh at shaw.ca Wed Jun 2 11:44:58 2010 From: geneh at shaw.ca (Gene Horodecki) Date: Wed, 02 Jun 2010 10:44:58 -0500 Subject: [Unison-hackers] Help with Visual Studio? Message-ID: <4C067C7A.2030908@shaw.ca> For myself, I don't really care if I build with visual studio or cygwin, but I'm lost with visual studio. I got this far: - install VS - install current oCAML for windows - In VS, new project with existing source - Select 'src' directory in trunk What do I need to do next? I assume I need to include the oCAML libraries somehow. Am I even on the right track? From Jerome.Vouillon at pps.jussieu.fr Wed Jun 2 12:31:10 2010 From: Jerome.Vouillon at pps.jussieu.fr (Jerome Vouillon) Date: Wed, 2 Jun 2010 18:31:10 +0200 Subject: [Unison-hackers] Problem building unison under cygwin In-Reply-To: <2kpc06po62mquhf16oq89ou1is6cdqbp42@4ax.com> References: <4C05DA40.9070701@shaw.ca> <20100602081400.GA21898@pps.jussieu.fr> <4C065243.20807@shaw.ca> <20100602131722.GA32308@pps.jussieu.fr> <2kpc06po62mquhf16oq89ou1is6cdqbp42@4ax.com> Message-ID: <20100602163110.GA3254@pps.jussieu.fr> On Wed, Jun 02, 2010 at 10:20:33AM -0400, Andrew Schulman wrote: > I've also just been trying to build unison 2.40 for Cygwin, with > UISTYLE=text. Jerome, your patch gets past the first problem, but the > build fails later [...] > I've tried removing system_win_stubs.c from Makefile.OCaml, by the patch > below. But the linking step fails with: > > No implementations provided for the following modules: > System_win referenced from system/win/system_impl.cmx That was the right thing to do, but you also need to change SYSTEM=win into SYSTEM=generic The Makefile is currently setup to use MinGW to build a standalone binary. I need to fix it so that one can also produce a Cygwin binary. -- Jerome From andrex at alumni.utexas.net Wed Jun 2 13:13:14 2010 From: andrex at alumni.utexas.net (Andrew Schulman) Date: Wed, 02 Jun 2010 13:13:14 -0400 Subject: [Unison-hackers] Problem building unison under cygwin References: <4C05DA40.9070701@shaw.ca> <20100602081400.GA21898@pps.jussieu.fr> <4C065243.20807@shaw.ca> <20100602131722.GA32308@pps.jussieu.fr> <2kpc06po62mquhf16oq89ou1is6cdqbp42@4ax.com> <20100602163110.GA3254@pps.jussieu.fr> Message-ID: > On Wed, Jun 02, 2010 at 10:20:33AM -0400, Andrew Schulman wrote: > > I've also just been trying to build unison 2.40 for Cygwin, with > > UISTYLE=text. Jerome, your patch gets past the first problem, but the > > build fails later > [...] > > I've tried removing system_win_stubs.c from Makefile.OCaml, by the patch > > below. But the linking step fails with: > > > > No implementations provided for the following modules: > > System_win referenced from system/win/system_impl.cmx > > That was the right thing to do, but you also need to change > SYSTEM=win > into > SYSTEM=generic Almost... there... + gcc -o 'unison.exe' -I'/usr/lib/ocaml' '/tmp/ASchulma/camlstartup7b2a71.o' '/usr/lib/ocaml/std_exit.o' 'linktext.o' 'main.o' 'test.o' 'uitext.o' 'uicommon.o' 'strings.o' 'transport.o' 'recon.o' 'sortri.o' 'files.o' 'stasher.o' 'copy.o' 'update.o' 'fpcache.o' 'globals.o' 'remote.o' 'xferhint.o' 'transfer.o' 'terminal.o' 'checksum.o' 'tree.o' 'common.o' 'clroot.o' 'lock.o' 'os.o' 'fileinfo.o' 'props.o' 'external.o' 'osx.o' 'abort.o' 'fingerprint.o' 'fs.o' 'fspath.o' 'path.o' 'name.o' 'fileutil.o' 'uutil.o' 'pred.o' 'case.o' 'lwt/lwt_unix.o' 'lwt/generic/lwt_unix_impl.o' 'lwt/lwt_util.o' 'lwt/lwt.o' 'lwt/pqueue.o' 'ubase/proplist.o' 'ubase/trace.o' 'ubase/prefs.o' 'ubase/uarg.o' 'ubase/util.o' 'ubase/uprintf.o' 'ubase/safelist.o' 'ubase/myMap.o' 'ubase/projectInfo.o' 'system.o' 'system/generic/system_impl.o' 'system/system_generic.o' 'bytearray.o' 'unicode.o' 'unicode_tables.o' 'ubase/rx.o' '/usr/lib/ocaml/bigarray.a' '/usr/lib/ocaml/str.a' '/usr/lib/ocaml/unix.a' '/usr/lib/ocaml/stdlib.a' '-Llwt' '-Lubase' '-Lsystem' '-Lsystem/generic' '-Llwt/generic' '-L/usr/lib/ocaml' '-lbigarray' '-lstr' '-lunix' 'lwt/lwt_unix_stubs.o' 'osxsupport.o' 'pty.o' 'bytearray_stubs.o' 'win32rc/unison.res.lib' '/usr/lib/ocaml/libasmrun.a' -lm lwt/lwt_unix_stubs.o:lwt_unix_stubs.c:(.text+0xfa): undefined reference to `_win32_maperr' lwt/lwt_unix_stubs.o:lwt_unix_stubs.c:(.text+0x109): undefined reference to `_unix_error_of_code' lwt/lwt_unix_stubs.o:lwt_unix_stubs.c:(.text+0x3b4): undefined reference to `_win32_maperr' lwt/lwt_unix_stubs.o:lwt_unix_stubs.c:(.text+0x8dc): undefined reference to `_win32_maperr' lwt/lwt_unix_stubs.o:lwt_unix_stubs.c:(.text+0xca7): undefined reference to `_WSAEventSelect at 12' lwt/lwt_unix_stubs.o:lwt_unix_stubs.c:(.text+0xcb4): undefined reference to `_WSAGetLastError at 0' lwt/lwt_unix_stubs.o:lwt_unix_stubs.c:(.text+0xcbc): undefined reference to `_win32_maperr' lwt/lwt_unix_stubs.o:lwt_unix_stubs.c:(.text+0xd4e): undefined reference to `_WSAEnumNetworkEvents at 12' lwt/lwt_unix_stubs.o:lwt_unix_stubs.c:(.text+0xd5a): undefined reference to `_WSAGetLastError at 0' lwt/lwt_unix_stubs.o:lwt_unix_stubs.c:(.text+0xd62): undefined reference to `_win32_maperr' lwt/lwt_unix_stubs.o:lwt_unix_stubs.c:(.text+0xd96): undefined reference to `_WSAEventSelect at 12' lwt/lwt_unix_stubs.o:lwt_unix_stubs.c:(.text+0xda3): undefined reference to `_WSAGetLastError at 0' lwt/lwt_unix_stubs.o:lwt_unix_stubs.c:(.text+0xdab): undefined reference to `_win32_maperr' lwt/lwt_unix_stubs.o:lwt_unix_stubs.c:(.text+0xde5): undefined reference to `_win32_maperr' lwt/lwt_unix_stubs.o:lwt_unix_stubs.c:(.text+0xe2d): undefined reference to `_win32_maperr' lwt/lwt_unix_stubs.o:lwt_unix_stubs.c:(.text+0x105f): undefined reference to `_win32_maperr' lwt/lwt_unix_stubs.o:lwt_unix_stubs.c:(.text+0x11c7): undefined reference to `_win32_maperr' lwt/lwt_unix_stubs.o:lwt_unix_stubs.c:(.text+0x1241): more undefined references to `_win32_maperr' follow lwt/lwt_unix_stubs.o:lwt_unix_stubs.c:(.text+0x127d): undefined reference to `_win_alloc_handle' lwt/lwt_unix_stubs.o:lwt_unix_stubs.c:(.text+0x128e): undefined reference to `_win_alloc_handle' lwt/lwt_unix_stubs.o:lwt_unix_stubs.c:(.text+0x1419): undefined reference to `_WSASocketA at 24' lwt/lwt_unix_stubs.o:lwt_unix_stubs.c:(.text+0x142a): undefined reference to `_WSAGetLastError at 0' lwt/lwt_unix_stubs.o:lwt_unix_stubs.c:(.text+0x1432): undefined reference to `_win32_maperr' lwt/lwt_unix_stubs.o:lwt_unix_stubs.c:(.text+0x1459): undefined reference to `_win_alloc_socket' collect2: ld returned 1 exit status Error during linking make[1]: *** [unison.exe] Error 2 From Jerome.Vouillon at pps.jussieu.fr Wed Jun 2 15:34:18 2010 From: Jerome.Vouillon at pps.jussieu.fr (Jerome Vouillon) Date: Wed, 2 Jun 2010 21:34:18 +0200 Subject: [Unison-hackers] Problem building unison under cygwin In-Reply-To: References: <4C05DA40.9070701@shaw.ca> <20100602081400.GA21898@pps.jussieu.fr> <4C065243.20807@shaw.ca> <20100602131722.GA32308@pps.jussieu.fr> <2kpc06po62mquhf16oq89ou1is6cdqbp42@4ax.com> <20100602163110.GA3254@pps.jussieu.fr> Message-ID: <20100602193418.GA3786@pps.jussieu.fr> On Wed, Jun 02, 2010 at 01:13:14PM -0400, Andrew Schulman wrote: > > On Wed, Jun 02, 2010 at 10:20:33AM -0400, Andrew Schulman wrote: > > > I've also just been trying to build unison 2.40 for Cygwin, with > > > UISTYLE=text. Jerome, your patch gets past the first problem, but the > > > build fails later > > [...] > > > I've tried removing system_win_stubs.c from Makefile.OCaml, by the patch > > > below. But the linking step fails with: > > > > > > No implementations provided for the following modules: > > > System_win referenced from system/win/system_impl.cmx > > > > That was the right thing to do, but you also need to change > > SYSTEM=win > > into > > SYSTEM=generic > > Almost... there... ...and you should remove this line entirely: COBJS+=lwt/lwt_unix_stubs$(OBJ_EXT) -- Jerome From geneh at shaw.ca Thu Jun 3 00:57:09 2010 From: geneh at shaw.ca (Gene Horodecki) Date: Wed, 02 Jun 2010 23:57:09 -0500 Subject: [Unison-hackers] File watcher: Question about state file In-Reply-To: References: <4C03073C.6090209@shaw.ca> Message-ID: <4C073625.9080501@shaw.ca> On 05/31/2010 8:19 AM, Benjamin Pierce wrote: > One thing it's used for is to tell the filewatcher when was the last time it was running, so that it can report files changed since then. That is, it will tell Unison not just what files are changing right now, but what files have changed since the last time we ran Unison with "-repeat watch" for these replicas. > > However, I don't think this scheme is safe -- it could cause us to miss changes if Unison simply trusts it. It is better to start the change detection at the moment where Unison starts up the filewatcher and then make Unison do a full scan of the filesystems itself, to make sure it finds everything that has changed since the last run. > > So I propose removing the --statefile functionality (assuming that was the only thing Christophe was using it for). > > - B > > > On May 30, 2010, at 8:47 PM, Gene Horodecki wrote: > > >> What is the --statefile for? I did not implement it in my win32 section. >> >> _______________________________________________ >> 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 > Ok I just got built on my windows machine in cygwin and one of my ubuntu machines. Can you tell me how I start up the new filewatcher functionality? From bcpierce at cis.upenn.edu Thu Jun 3 09:16:12 2010 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Thu, 3 Jun 2010 09:16:12 -0400 Subject: [Unison-hackers] File watcher: Question about state file In-Reply-To: <4C073625.9080501@shaw.ca> References: <4C03073C.6090209@shaw.ca> <4C073625.9080501@shaw.ca> Message-ID: unison -repeat watch On Jun 3, 2010, at 12:57 AM, Gene Horodecki wrote: > On 05/31/2010 8:19 AM, Benjamin Pierce wrote: >> One thing it's used for is to tell the filewatcher when was the last time it was running, so that it can report files changed since then. That is, it will tell Unison not just what files are changing right now, but what files have changed since the last time we ran Unison with "-repeat watch" for these replicas. >> >> However, I don't think this scheme is safe -- it could cause us to miss changes if Unison simply trusts it. It is better to start the change detection at the moment where Unison starts up the filewatcher and then make Unison do a full scan of the filesystems itself, to make sure it finds everything that has changed since the last run. >> >> So I propose removing the --statefile functionality (assuming that was the only thing Christophe was using it for). >> >> - B >> >> >> On May 30, 2010, at 8:47 PM, Gene Horodecki wrote: >> >> >>> What is the --statefile for? I did not implement it in my win32 section. >>> >>> _______________________________________________ >>> 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 >> > Ok I just got built on my windows machine in cygwin and one of my ubuntu > machines. Can you tell me how I start up the new filewatcher functionality? > > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From geneh at shaw.ca Thu Jun 3 16:37:00 2010 From: geneh at shaw.ca (Gene Horodecki) Date: Thu, 03 Jun 2010 15:37:00 -0500 Subject: [Unison-hackers] File watcher: Question about state file In-Reply-To: References: <4C03073C.6090209@shaw.ca> <4C073625.9080501@shaw.ca> Message-ID: <4C08126C.2010606@shaw.ca> Does the new code attempt to execute fsmonitor.py in the same directory that unison resides, or the active directory at the time of execution? On 06/03/2010 8:16 AM, Benjamin Pierce wrote: > unison -repeat watch > > On Jun 3, 2010, at 12:57 AM, Gene Horodecki wrote: > > >> On 05/31/2010 8:19 AM, Benjamin Pierce wrote: >> >>> One thing it's used for is to tell the filewatcher when was the last time it was running, so that it can report files changed since then. That is, it will tell Unison not just what files are changing right now, but what files have changed since the last time we ran Unison with "-repeat watch" for these replicas. >>> >>> However, I don't think this scheme is safe -- it could cause us to miss changes if Unison simply trusts it. It is better to start the change detection at the moment where Unison starts up the filewatcher and then make Unison do a full scan of the filesystems itself, to make sure it finds everything that has changed since the last run. >>> >>> So I propose removing the --statefile functionality (assuming that was the only thing Christophe was using it for). >>> >>> - B >>> >>> >>> On May 30, 2010, at 8:47 PM, Gene Horodecki wrote: >>> >>> >>> >>>> What is the --statefile for? I did not implement it in my win32 section. >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> Ok I just got built on my windows machine in cygwin and one of my ubuntu >> machines. Can you tell me how I start up the new filewatcher functionality? >> >> _______________________________________________ >> 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 > From geneh at shaw.ca Thu Jun 3 22:09:15 2010 From: geneh at shaw.ca (Gene Horodecki) Date: Thu, 03 Jun 2010 21:09:15 -0500 Subject: [Unison-hackers] File watcher: Question about state file In-Reply-To: References: <4C03073C.6090209@shaw.ca> <4C073625.9080501@shaw.ca> Message-ID: <4C08604B.9050301@shaw.ca> When I execute unison -repeat watch I get $ ./unison -repeat watch /bin/sh: fsmonitor.py: not found I even tried fully qualifying it in uitext.ml and rebuilding but I still get it. On 06/03/2010 8:16 AM, Benjamin Pierce wrote: > unison -repeat watch > > On Jun 3, 2010, at 12:57 AM, Gene Horodecki wrote: > > >> On 05/31/2010 8:19 AM, Benjamin Pierce wrote: >> >>> One thing it's used for is to tell the filewatcher when was the last time it was running, so that it can report files changed since then. That is, it will tell Unison not just what files are changing right now, but what files have changed since the last time we ran Unison with "-repeat watch" for these replicas. >>> >>> However, I don't think this scheme is safe -- it could cause us to miss changes if Unison simply trusts it. It is better to start the change detection at the moment where Unison starts up the filewatcher and then make Unison do a full scan of the filesystems itself, to make sure it finds everything that has changed since the last run. >>> >>> So I propose removing the --statefile functionality (assuming that was the only thing Christophe was using it for). >>> >>> - B >>> >>> >>> On May 30, 2010, at 8:47 PM, Gene Horodecki wrote: >>> >>> >>> >>>> What is the --statefile for? I did not implement it in my win32 section. >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> Ok I just got built on my windows machine in cygwin and one of my ubuntu >> machines. Can you tell me how I start up the new filewatcher functionality? >> >> _______________________________________________ >> 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 > From bcpierce at cis.upenn.edu Thu Jun 3 22:15:16 2010 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Thu, 3 Jun 2010 22:15:16 -0400 Subject: [Unison-hackers] File watcher: Question about state file In-Reply-To: <4C08604B.9050301@shaw.ca> References: <4C03073C.6090209@shaw.ca> <4C073625.9080501@shaw.ca> <4C08604B.9050301@shaw.ca> Message-ID: For the moment, Unison just asks the OS to start a program called "fsmonitor.py," so it's going to get whatever the OS can find in the standard search path. Which, I guess, should work iff typing "fsmonitor.py" directly on the command line does. (We'll need to do something more serious about this in the long run, but I'm not clear on what's the best user interface. Putting it in a preference isn't very nice because it could well be different on the two hosts, and there is no way to specify this in a preference.) - B On Jun 3, 2010, at 10:09 PM, Gene Horodecki wrote: > When I execute unison -repeat watch I get > > $ ./unison -repeat watch > /bin/sh: fsmonitor.py: not found > > I even tried fully qualifying it in uitext.ml and rebuilding but I still > get it. > > On 06/03/2010 8:16 AM, Benjamin Pierce wrote: >> unison -repeat watch >> >> On Jun 3, 2010, at 12:57 AM, Gene Horodecki wrote: >> >> >>> On 05/31/2010 8:19 AM, Benjamin Pierce wrote: >>> >>>> One thing it's used for is to tell the filewatcher when was the last time it was running, so that it can report files changed since then. That is, it will tell Unison not just what files are changing right now, but what files have changed since the last time we ran Unison with "-repeat watch" for these replicas. >>>> >>>> However, I don't think this scheme is safe -- it could cause us to miss changes if Unison simply trusts it. It is better to start the change detection at the moment where Unison starts up the filewatcher and then make Unison do a full scan of the filesystems itself, to make sure it finds everything that has changed since the last run. >>>> >>>> So I propose removing the --statefile functionality (assuming that was the only thing Christophe was using it for). >>>> >>>> - B >>>> >>>> >>>> On May 30, 2010, at 8:47 PM, Gene Horodecki wrote: >>>> >>>> >>>> >>>>> What is the --statefile for? I did not implement it in my win32 section. >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>> Ok I just got built on my windows machine in cygwin and one of my ubuntu >>> machines. Can you tell me how I start up the new filewatcher functionality? >>> >>> _______________________________________________ >>> 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 From zhangweiwu at realss.com Fri Jun 4 01:16:11 2010 From: zhangweiwu at realss.com (Zhang Weiwu) Date: Fri, 04 Jun 2010 13:16:11 +0800 Subject: [Unison-hackers] report mistake on website about distribution Message-ID: <4C088C1B.7080604@realss.com> Hello. I read on unison website "Cygwin should be able to install unison and unison-gtk2 from the Cygwin setup utility." but I just tried, and later confirmed with cygwin mailing list, that there doesn't exist unison-gtk2 for cygwin. Only the text version works on cygwin. Here is where I read it: http://www.cis.upenn.edu/~bcpierce/unison/download.html Could the webmaster update the website to correct this information? I think the hacker list is the fastest place to find webmaster to report this thus I send it here. From alan.schmitt at polytechnique.org Fri Jun 4 04:34:24 2010 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Fri, 4 Jun 2010 10:34:24 +0200 Subject: [Unison-hackers] New FAQ posted Message-ID: <3EDC8153-AE88-4BDC-A749-80D795A6C6FC@polytechnique.org> Hello, As I've had many people ask me this, I posted this (OS X specific) FAQ on the wiki. Please let me know if you want me to change or reword it. Alan Title: I installed the command line version of Unison using the "Install command-line tool" menu option, but the wrong version of Unison is being launched. The command-line tool is a very small executable that searches for an existing Unison binary to launch it. If several versions of Unison are present, one cannot predict which one will be launched. It is thus recommended to have only one version of the Unison OS X binary. From bcpierce at cis.upenn.edu Fri Jun 4 08:55:09 2010 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Fri, 4 Jun 2010 08:55:09 -0400 Subject: [Unison-hackers] report mistake on website about distribution In-Reply-To: <4C088C1B.7080604@realss.com> References: <4C088C1B.7080604@realss.com> Message-ID: <91EC6393-5B2E-4CA7-907B-69EB0181A2A1@cis.upenn.edu> Fixed -- thanks. - B On Jun 4, 2010, at 1:16 AM, Zhang Weiwu wrote: > Hello. I read on unison website "Cygwin should be able to install unison and > unison-gtk2 from the Cygwin setup utility." but I just tried, and > later confirmed with cygwin mailing list, that there doesn't exist > unison-gtk2 for cygwin. Only the text version works on cygwin. > > > Here is where I read it: > http://www.cis.upenn.edu/~bcpierce/unison/download.html > > > Could the webmaster update the website to correct this information? > > I think the hacker list is the fastest place to find webmaster to report > this thus I send it here. > > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From andrex at alumni.utexas.net Fri Jun 4 10:28:06 2010 From: andrex at alumni.utexas.net (Andrew Schulman) Date: Fri, 04 Jun 2010 10:28:06 -0400 Subject: [Unison-hackers] New FAQ posted References: <3EDC8153-AE88-4BDC-A749-80D795A6C6FC@polytechnique.org> Message-ID: > Title: I installed the command line version of Unison using the "Install command-line tool" menu option, but the wrong version of Unison is being launched. > > The command-line tool is a very small executable that searches for an existing Unison binary to launch it. If several versions of Unison are present, one cannot predict which one will be launched. It is thus recommended to have only one version of the Unison OS X binary. Just a comment on this. Different OSes have different ways of handling the version problem in Unison. In Cygwin, we have multiple packages: unison2.27, unison2.32, etc., each of which provides a different executable: /usr/bin/unison-2.27, /usr/bin/unison-2.32, etc. The user can have one or more of those packages installed at a time. To choose which version to run, we use alternatives(8) (or as it's known in Debian, update-alternatives(8))). The default priorities for the different alternatives are set to track the highest installed version. So if a user has unison2.27 and unison2.32 installed, then /usr/bin/unison is by default a symlink to /usr/bin/unison-2.32. If the user wants something different, they can either (1) explicitly run a different version, e.g. /usr/bin/unison-2.27, or (2) use alternatives(8) to change which version the symlink points to. Andrew. From andrex at alumni.utexas.net Fri Jun 4 10:55:30 2010 From: andrex at alumni.utexas.net (Andrew Schulman) Date: Fri, 04 Jun 2010 10:55:30 -0400 Subject: [Unison-hackers] Problem building unison under cygwin References: <4C05DA40.9070701@shaw.ca> <20100602081400.GA21898@pps.jussieu.fr> <4C065243.20807@shaw.ca> <20100602131722.GA32308@pps.jussieu.fr> <2kpc06po62mquhf16oq89ou1is6cdqbp42@4ax.com> <20100602163110.GA3254@pps.jussieu.fr> <20100602193418.GA3786@pps.jussieu.fr> Message-ID: > ...and you should remove this line entirely: > > COBJS+=lwt/lwt_unix_stubs$(OBJ_EXT) Thanks Jerome. Should have tried that... So with the patch below, unison 2.40 now builds successfully in Cygwin with 'make OSCOMP=cygwingnuc UISTYLE=text SYSTEM=generic'. The patch is Cygwin-specific-- I'm not sure what's the right set of #ifdef's and so on to make the changes apply only in Cygwin. Gene, I'll upload a new Cygwin unison2.40 package today. With luck it will show up in your favorite mirror by tomorrow. Andrew. From andrex at alumni.utexas.net Fri Jun 4 11:31:41 2010 From: andrex at alumni.utexas.net (Andrew Schulman) Date: Fri, 04 Jun 2010 11:31:41 -0400 Subject: [Unison-hackers] Problem building unison under cygwin References: <4C05DA40.9070701@shaw.ca> <20100602081400.GA21898@pps.jussieu.fr> <4C065243.20807@shaw.ca> <20100602131722.GA32308@pps.jussieu.fr> <2kpc06po62mquhf16oq89ou1is6cdqbp42@4ax.com> <20100602163110.GA3254@pps.jussieu.fr> <20100602193418.GA3786@pps.jussieu.fr> Message-ID: <5v6i06dpcuu9gbc604f7p2tacs91h9177n@4ax.com> > So with the patch below, unison 2.40 now builds successfully in Cygwin with > 'make OSCOMP=cygwingnuc UISTYLE=text SYSTEM=generic'. The patch is > Cygwin-specific-- I'm not sure what's the right set of #ifdef's and so on > to make the changes apply only in Cygwin. And here's the patch. --- unison-2.40.16.orig/Makefile 2010-04-15 13:29:31.000000000 -0400 +++ unison-2.40.16/Makefile 2010-06-03 17:45:41.120443200 -0400 @@ -60,11 +60,11 @@ STATIC=false # NAME, VERSION, and MAJORVERSION, automatically generated -include Makefile.ProjectInfo -Makefile.ProjectInfo: mkProjectInfo.ml $(wildcard ../.bzr/branch/last-revision) - ocaml str.cma unix.cma ./mkProjectInfo.ml > $@ +Makefile.ProjectInfo: mkProjectInfo + ./mkProjectInfo > $@ -#mkProjectInfo: mkProjectInfo.ml -# ocamlc -o $@ unix.cma str.cma $^ +mkProjectInfo: mkProjectInfo.ml + ocamlc -o $@ $^ clean:: $(RM) mkProjectInfo @@ -348,7 +348,7 @@ tags: $(ETAGS) *.mli */*.mli *.ml */*.ml */*.m *.c */*.c *.txt \ ; fi -all:: TAGS +#all:: TAGS TAGS: $(MAKE) tags --- unison-2.40.16.orig/Makefile.OCaml 2010-04-15 13:29:31.000000000 -0400 +++ unison-2.40.16/Makefile.OCaml 2010-06-03 17:45:42.432901200 -0400 @@ -120,8 +120,7 @@ else ifeq ($(OSARCH),win32gnuc) CWD=. EXEC_EXT=.exe - COBJS+=system/system_win_stubs$(OBJ_EXT) lwt/lwt_unix_stubs$(OBJ_EXT) - WINOBJS=system/system_win.cmo + WINOBJS= SYSTEM=win CLIBS+=-cclib win32rc/unison.res.lib STATIC=false # Cygwin is not MinGW :-( From alan.schmitt at polytechnique.org Fri Jun 4 13:16:18 2010 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Fri, 4 Jun 2010 19:16:18 +0200 Subject: [Unison-hackers] New FAQ posted In-Reply-To: References: <3EDC8153-AE88-4BDC-A749-80D795A6C6FC@polytechnique.org> Message-ID: <502279CF-94D0-405A-B16E-9C819B58B6AB@polytechnique.org> On 4 juin 2010, at 16:28, Andrew Schulman wrote: >> Title: I installed the command line version of Unison using the "Install command-line tool" menu option, but the wrong version of Unison is being launched. >> >> The command-line tool is a very small executable that searches for an existing Unison binary to launch it. If several versions of Unison are present, one cannot predict which one will be launched. It is thus recommended to have only one version of the Unison OS X binary. > > Just a comment on this. Different OSes have different ways of handling the > version problem in Unison. In Cygwin, we have multiple packages: > unison2.27, unison2.32, etc., each of which provides a different > executable: /usr/bin/unison-2.27, /usr/bin/unison-2.32, etc. The user can > have one or more of those packages installed at a time. > > To choose which version to run, we use alternatives(8) (or as it's known in > Debian, update-alternatives(8))). The default priorities for the different > alternatives are set to track the highest installed version. So if a user > has unison2.27 and unison2.32 installed, then /usr/bin/unison is by default > a symlink to /usr/bin/unison-2.32. If the user wants something different, > they can either (1) explicitly run a different version, e.g. > /usr/bin/unison-2.27, or (2) use alternatives(8) to change which version > the symlink points to. The problem only occurs for the OS X command-line tool installed by the GUI. This is why I posted this in the OS X specific section of the FAQ (which I should have made clearer in my mail). Alan From andrex at alumni.utexas.net Fri Jun 4 13:49:27 2010 From: andrex at alumni.utexas.net (Andrew Schulman) Date: Fri, 04 Jun 2010 13:49:27 -0400 Subject: [Unison-hackers] New FAQ posted References: <3EDC8153-AE88-4BDC-A749-80D795A6C6FC@polytechnique.org> <502279CF-94D0-405A-B16E-9C819B58B6AB@polytechnique.org> Message-ID: <30fi06hb9qccfmkcrtsnku6p4u38rtd880@4ax.com> > The problem only occurs for the OS X command-line tool installed by > the GUI. This is why I posted this in the OS X specific section of > the FAQ (which I should have made clearer in my mail). I understand. I was suggesting that there might be a better way than random for that tool to choose which version it wants to run. Just a suggestion though, take for what it's worth. Andrew. From geneh at shaw.ca Sat Jun 5 00:42:57 2010 From: geneh at shaw.ca (Gene Horodecki) Date: Fri, 04 Jun 2010 23:42:57 -0500 Subject: [Unison-hackers] File watcher: Question about state file In-Reply-To: References: <4C03073C.6090209@shaw.ca> <4C073625.9080501@shaw.ca> <4C08604B.9050301@shaw.ca> Message-ID: <4C09D5D1.3060906@shaw.ca> Yeah I was confused at first but then I realized I made the softlink to my fsmonitor.py script wrong and it wasn't on the path. I got it all to run but it is not working for me. It looks like it is sitting there waiting for something, but nothing actually gets propagated. On 06/03/2010 9:15 PM, Benjamin Pierce wrote: > For the moment, Unison just asks the OS to start a program called "fsmonitor.py," so it's going to get whatever the OS can find in the standard search path. Which, I guess, should work iff typing "fsmonitor.py" directly on the command line does. > > (We'll need to do something more serious about this in the long run, but I'm not clear on what's the best user interface. Putting it in a preference isn't very nice because it could well be different on the two hosts, and there is no way to specify this in a preference.) > > - B > > > On Jun 3, 2010, at 10:09 PM, Gene Horodecki wrote: > > >> When I execute unison -repeat watch I get >> >> $ ./unison -repeat watch >> /bin/sh: fsmonitor.py: not found >> >> I even tried fully qualifying it in uitext.ml and rebuilding but I still >> get it. >> >> On 06/03/2010 8:16 AM, Benjamin Pierce wrote: >> >>> unison -repeat watch >>> >>> On Jun 3, 2010, at 12:57 AM, Gene Horodecki wrote: >>> >>> >>> >>>> On 05/31/2010 8:19 AM, Benjamin Pierce wrote: >>>> >>>> >>>>> One thing it's used for is to tell the filewatcher when was the last time it was running, so that it can report files changed since then. That is, it will tell Unison not just what files are changing right now, but what files have changed since the last time we ran Unison with "-repeat watch" for these replicas. >>>>> >>>>> However, I don't think this scheme is safe -- it could cause us to miss changes if Unison simply trusts it. It is better to start the change detection at the moment where Unison starts up the filewatcher and then make Unison do a full scan of the filesystems itself, to make sure it finds everything that has changed since the last run. >>>>> >>>>> So I propose removing the --statefile functionality (assuming that was the only thing Christophe was using it for). >>>>> >>>>> - B >>>>> >>>>> >>>>> On May 30, 2010, at 8:47 PM, Gene Horodecki wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> What is the --statefile for? I did not implement it in my win32 section. >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> >>>>> >>>> Ok I just got built on my windows machine in cygwin and one of my ubuntu >>>> machines. Can you tell me how I start up the new filewatcher functionality? >>>> >>>> _______________________________________________ >>>> 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 >> > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers > From trevor at research.att.com Sat Jun 5 11:22:39 2010 From: trevor at research.att.com (Trevor Jim) Date: Sat, 05 Jun 2010 11:22:39 -0400 Subject: [Unison-hackers] File watcher: Question about state file In-Reply-To: References: <4C03073C.6090209@shaw.ca> <4C073625.9080501@shaw.ca> <4C08604B.9050301@shaw.ca> Message-ID: <4C0A6BBF.5050101@research.att.com> On 06/03/2010 10:15 PM, Benjamin Pierce wrote: > For the moment, Unison just asks the OS to start a program called "fsmonitor.py," If fsmonitor.py is small enough, just embed it as a string in the unison binary, and have unison start "python" with the string on the command line or something... "python" is much more likely to be set up properly. -T From bcpierce at cis.upenn.edu Sat Jun 5 13:54:47 2010 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Sat, 5 Jun 2010 13:54:47 -0400 Subject: [Unison-hackers] File watcher: Question about state file In-Reply-To: <4C0A6BBF.5050101@research.att.com> References: <4C03073C.6090209@shaw.ca> <4C073625.9080501@shaw.ca> <4C08604B.9050301@shaw.ca> <4C0A6BBF.5050101@research.att.com> Message-ID: <6C38FD6F-68D9-4EAF-9A84-1D371E0C6CA6@cis.upenn.edu> Good idea! Might be a bit by for cmd line, but we can also dump it in a file someplace. - Benjamin On Jun 5, 2010, at 11:22 AM, Trevor Jim wrote: > On 06/03/2010 10:15 PM, Benjamin Pierce wrote: >> For the moment, Unison just asks the OS to start a program called >> "fsmonitor.py," > > If fsmonitor.py is small enough, just embed it as a string in the > unison > binary, and have unison start "python" with the string on the > command line > or something... > > "python" is much more likely to be set up properly. > > -T > > _______________________________________________ > 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 Jun 5 15:06:32 2010 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Sat, 5 Jun 2010 15:06:32 -0400 Subject: [Unison-hackers] [unison-users] Re: file watcher Message-ID: <187D426A-C745-4C12-9B0E-D38D4D952716@cis.upenn.edu> Specifically: File "/Users/bcpierce/common/bin/fsmonitor.py", line 557, in macosxwatcher() File "/Users/bcpierce/common/bin/fsmonitor.py", line 371, in macosxwatcher CFRunLoopRun() File "/Users/bcpierce/common/bin/fsmonitor.py", line 302, in fsevents_callback result.extend(filelevel_approx(path)) File "/Users/bcpierce/common/bin/fsmonitor.py", line 246, in filelevel_approx st = os.lstat(full_path) OSError: [Errno 2] No such file or directory: '/Users/bcpierce/Library/Safari/lock/details.plist' From bcpierce at seas.upenn.edu Sun Jun 6 08:41:29 2010 From: bcpierce at seas.upenn.edu (bcpierce@seas.upenn.edu) Date: Sun, 6 Jun 2010 08:41:29 -0400 Subject: [Unison-hackers] [unison-svn] r454 - trunk/src Message-ID: <201006061241.o56CfTSB026509@yaws.seas.upenn.edu> Author: bcpierce Date: 2010-06-06 08:41:29 -0400 (Sun, 06 Jun 2010) New Revision: 454 Modified: trunk/src/RECENTNEWS trunk/src/mkProjectInfo.ml Log: * Fix version number Modified: trunk/src/RECENTNEWS =================================================================== --- trunk/src/RECENTNEWS 2010-05-31 13:24:33 UTC (rev 453) +++ trunk/src/RECENTNEWS 2010-06-06 12:41:29 UTC (rev 454) @@ -1,3 +1,12 @@ +CHANGES FROM VERSION 2.41.-27 + +* Fix version number + + + + + +------------------------------- CHANGES FROM VERSION 2.41.-28 * Trim duplicate paths when using "-repeat watch" Modified: trunk/src/mkProjectInfo.ml =================================================================== --- trunk/src/mkProjectInfo.ml 2010-05-31 13:24:33 UTC (rev 453) +++ trunk/src/mkProjectInfo.ml 2010-06-06 12:41:29 UTC (rev 454) @@ -6,7 +6,7 @@ let projectName = "unison" let majorVersion = 2 let minorVersion = 41 -let pointVersionOrigin = 453 (* Revision that corresponds to point version 0 *) +let pointVersionOrigin = 452 (* Revision that corresponds to point version 0 *) (* Documentation: This is a program to construct a version of the form Major.Minor.Point, @@ -101,3 +101,4 @@ + From bcpierce at seas.upenn.edu Sun Jun 6 08:43:26 2010 From: bcpierce at seas.upenn.edu (bcpierce@seas.upenn.edu) Date: Sun, 6 Jun 2010 08:43:26 -0400 Subject: [Unison-hackers] [unison-svn] r455 - trunk/src Message-ID: <201006061243.o56ChQn6026578@yaws.seas.upenn.edu> Author: bcpierce Date: 2010-06-06 08:43:26 -0400 (Sun, 06 Jun 2010) New Revision: 455 Modified: trunk/src/RECENTNEWS trunk/src/mkProjectInfo.ml Log: * Try again to fix version number Modified: trunk/src/RECENTNEWS =================================================================== --- trunk/src/RECENTNEWS 2010-06-06 12:41:29 UTC (rev 454) +++ trunk/src/RECENTNEWS 2010-06-06 12:43:26 UTC (rev 455) @@ -1,5 +1,14 @@ CHANGES FROM VERSION 2.41.-27 +* Try again to fix version number + + + + + +------------------------------- +CHANGES FROM VERSION 2.41.-27 + * Fix version number Modified: trunk/src/mkProjectInfo.ml =================================================================== --- trunk/src/mkProjectInfo.ml 2010-06-06 12:41:29 UTC (rev 454) +++ trunk/src/mkProjectInfo.ml 2010-06-06 12:43:26 UTC (rev 455) @@ -44,52 +44,6 @@ let revisionString = "$Rev: 425$";; -(* BCP (1/10): This bit was added to help with getting Unison via bazaar, but it - was never used much and I'm not confident it's working. I'll comment it out - for now, but if it hasn't been needed or fixed in a few months, the next - person that edits this file should delete it... - - (* extract a substring using a regular expression *) - let extract_str re str = - let _ = Str.search_forward (Str.regexp re) str 0 in - Str.matched_group 1 str;; - let extract_int re str = int_of_string (extract_str re str);; - - (* run the bzr tool to get version information for bzr branches *) - exception BzrException of Unix.process_status;; - let bzr args = - let bzr = (try Sys.getenv "BZR" with Not_found -> "bzr") in - let cmd = bzr ^ " " ^ args in - let inc = Unix.open_process_in cmd in - let buf = Buffer.create 16 in - (try - while true do - Buffer.add_channel buf inc 1 - done - with End_of_file -> ()); - let status = Unix.close_process_in inc in - match status with - Unix.WEXITED 0 -> Buffer.contents buf - | _ -> raise (BzrException status);; - - let pointVersion = if String.length revisionString > 5 - then Scanf.sscanf revisionString "$Rev: %d " (fun x -> x) - pointVersionOrigin - else (* Determining the pointVersionOrigin in bzr is kind of tricky: - - The mentioned revision number might not be part of this branch - - The mentioned revision number might be rhs of some merge - - The bzr-svn plugin might be outdated or not installed at all - - On the whole, getting this to work seems too much effort for now. - So we'll simply use the revno as is as the point version, - and revisit offsetting them if unison should ever move its trunk to bzr. - - let pvo = extract_int "^revno:[ \t]*\\([0-9]+\\)[ \t]*$" - (bzr ("log -r svn:" ^ - string_of_int pointVersionOrigin)) in - *) - extract_int "^\\([0-9]+\\)$" (bzr "revno") (* - pvo *);; -*) - let pointVersion = Scanf.sscanf revisionString "$Rev: %d " (fun x -> x) - pointVersionOrigin;; @@ -102,3 +56,4 @@ + From bcpierce at cis.upenn.edu Fri Jun 11 15:53:02 2010 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Fri, 11 Jun 2010 15:53:02 -0400 Subject: [Unison-hackers] New unison beta: 2.40.16 Message-ID: <206D114C-6E19-43CD-AA07-4199FA633B85@cis.upenn.edu> I've just exported a new version of the 2.40 beta release, incorporating a number of bug fixes and small improvements made since the original beta-release (2.40.1) a few weeks ago. - Benjamin From bcpierce at cis.upenn.edu Fri Jun 11 15:56:08 2010 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Fri, 11 Jun 2010 15:56:08 -0400 Subject: [Unison-hackers] [patch] high system time with BTRFS and compression... In-Reply-To: References: Message-ID: Hi Daniel, All this code has been substantially rewritten since 2.27 (so there's nowhere to apply your patch any more) -- should perform even better now! - Benjamin On May 28, 2010, at 10:13 AM, Daniel J Blueman wrote: > With unison 2.27.57 on Linux (Ubuntu 10.04 x86-64, client and server), > performing synchronisation with a BTRFS filesystem with compression > enabled takes higher system time, due to many threads performing > smaller (~4K) synchronous reads. > > Increasing the buffer size to 64K helps alleviate this, and will > provide a smaller win on other filesystems. Also, on faster networks > with larger MTU, 64K read/write to the socket provides more > throughput. > > Please consider and thanks, > Daniel > > diff -ur unison-2.27.57/remote.ml unison-2.27.57-new/remote.ml > --- unison-2.27.57/remote.ml 2008-01-18 13:53:35.000000000 +0000 > +++ unison-2.27.57-new/remote.ml 2010-05-26 12:49:00.146269467 +0100 > @@ -79,7 +79,7 @@ > let receivedBytes = ref 0. > let emittedBytes = ref 0. > > -let inputBuffer_size = 8192 > +let inputBuffer_size = 65536 > > let fill_inputBuffer conn = > assert (conn.inputLength = 0); > @@ -127,7 +127,7 @@ > > (****) > > -let outputBuffer_size = 8192 > +let outputBuffer_size = 65536 > > let rec send_output conn = > catch_io_errors > diff -ur unison-2.27.57/transfer.ml unison-2.27.57-new/transfer.ml > --- unison-2.27.57/transfer.ml 2007-04-02 04:03:20.000000000 +0100 > +++ unison-2.27.57-new/transfer.ml 2010-05-26 12:51:12.676894227 +0100 > @@ -234,8 +234,8 @@ > let send infd length showProgress transmit = > debug (fun() -> Util.msg "sending file\n"); > let timer = Trace.startTimer "Sending file using generic transmission" in > - let bufSz = 8192 in > - let bufSzFS = Uutil.Filesize.ofInt 8192 in > + let bufSz = 65536 in > + let bufSzFS = Uutil.Filesize.ofInt 65536 in > let buf = String.create bufSz in > let q = makeQueue length in > let rec sendSlice length = > @@ -298,14 +298,14 @@ > (*** PREPROCESS ***) > > (* Preprocess buffer size *) > - let preproBufSize = 8192 > + let preproBufSize = 65536 > > (* Incrementally build arg by executing f on successive blocks (of size > 'blockSize') of the input stream (pointed by 'infd'). > The procedure uses a buffer of size 'bufferSize' to load the input, > and eventually handles the buffer update. *) > let blockIter infd f arg maxCount = > - let bufferSize = 8192 + blockSize in > + let bufferSize = 65536 + blockSize in > let buffer = String.create bufferSize in > let rec iter count arg offset length = > if count = maxCount then arg else begin > @@ -363,7 +363,7 @@ > (*** DECOMPRESSION ***) > > (* Decompression buffer size *) > - let decomprBufSize = 8192 > + let decomprBufSize = 65536 > > (* For each transfer instruction, either output a string or copy one or > several blocks from the old file. *) > @@ -517,8 +517,8 @@ > > (* Compression buffer size *) > (* MUST be >= 2 * blockSize *) > - let comprBufSize = 8192 > - let comprBufSizeFS = Uutil.Filesize.ofInt 8192 > + let comprBufSize = 65536 > + let comprBufSizeFS = Uutil.Filesize.ofInt 65536 > > (* Compress the file using the algorithm described in the header *) > let rsyncCompress sigs infd srcLength showProgress transmit = > -- > Daniel J Blueman From bcpierce at cis.upenn.edu Thu Jun 17 10:31:59 2010 From: bcpierce at cis.upenn.edu (Benjamin C. Pierce) Date: Thu, 17 Jun 2010 10:31:59 -0400 Subject: [Unison-hackers] An idea for faster initial syncs Message-ID: The process of setting up a new laptop this week has brought home to me, again, the fact that unison's initial scan of the replicas is horribly slow when the replicas are big (and whose replicas aren't big these days?). I've been thinking about a small hack that might make this better. My idea is to add a switch that says to Unison "I know that the replicas are in sync already and I want to you rebuild your archives as fast as possible." When this switch is set, Unison would skip fingerprinting the contents of new files -- it would simply store a dummy fingerprint (a hash of the file's size and permissions) in the archive for each file. As long as files are never changed after this, this dummy fingerprint would never be looked at, so Unison's behavior would remain the same. If a file is changed at some point in the future, Unison will fingerprint the new contents, detect a change, and copy the new version to the other side, again behaving as it should. The one slight difference in behavior will be that if a file is really changed on one side but only touched on the other, Unison will detect a conflict rather than propagating the change. I can see a couple of potential issues with this scheme. First, if, on the initial sync, the replicas are *not* identical -- in particular, if the files at some path differ but have the same length -- Unison will miss this change. I think we could live with this, because it will be easy for users to understand this danger: they are telling Unison not to look for changes, so they won't be surprised that it doesn't. Second, more seriously, if there is some file with different sizes (or that exists on one replica and not the other), Unison will calculate a dummy fingerprint during update detection and then later think that the file hasn't been transferred correctly because the fingerprints don't match. We may need a special case in the fingerprint check at the end that recalculates the fingerprint if it is a dummy. Comments? - Benjamin From andrex at alumni.utexas.net Thu Jun 17 16:24:03 2010 From: andrex at alumni.utexas.net (Andrew Schulman) Date: Thu, 17 Jun 2010 16:24:03 -0400 Subject: [Unison-hackers] prompts require newline in Cygwin Message-ID: <6ivk16l6f3dbqgumce8onne0sr1b1g14so@4ax.com> There's a small thing about Unison in Cygwin that's been bothering me for a long time. In Linux, when I'm synchronizing and I get a prompt for what to do with a single file or to proceed with updates, I don't have to hit the enter key after my answer - I just press the key, e.g. 'y' to go ahead, and it does. But in Cygwin, after I answer the prompt, I have to also hit Enter. It's always been that way, ever since I first started building Unison for Cygwin, way back around version 2.9. It would be nice to fix that, but I don't have a clue what the reason is. Can anyone suggest a solution? Our ocaml in Cygwin is 3.08.1, BTW. Thanks, Andrew. From bcpierce at cis.upenn.edu Thu Jun 17 16:44:08 2010 From: bcpierce at cis.upenn.edu (Benjamin C. Pierce) Date: Thu, 17 Jun 2010 16:44:08 -0400 Subject: [Unison-hackers] prompts require newline in Cygwin In-Reply-To: <6ivk16l6f3dbqgumce8onne0sr1b1g14so@4ax.com> References: <6ivk16l6f3dbqgumce8onne0sr1b1g14so@4ax.com> Message-ID: If you're willing to recompile, try changing let supportSignals = Util.osType = `Unix (*|| Util.isCygwin*) in uitext.ml to let supportSignals = Util.osType = `Unix || Util.isCygwin and see if things improve... - B On Jun 17, 2010, at 4:24 PM, Andrew Schulman wrote: > There's a small thing about Unison in Cygwin that's been bothering me for a > long time. > > In Linux, when I'm synchronizing and I get a prompt for what to do with a > single file or to proceed with updates, I don't have to hit the enter key > after my answer - I just press the key, e.g. 'y' to go ahead, and it does. > > But in Cygwin, after I answer the prompt, I have to also hit Enter. It's > always been that way, ever since I first started building Unison for > Cygwin, way back around version 2.9. > > It would be nice to fix that, but I don't have a clue what the reason is. > Can anyone suggest a solution? Our ocaml in Cygwin is 3.08.1, BTW. > > Thanks, > Andrew. > > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From andrex at alumni.utexas.net Thu Jun 17 17:32:33 2010 From: andrex at alumni.utexas.net (Andrew Schulman) Date: Thu, 17 Jun 2010 17:32:33 -0400 Subject: [Unison-hackers] prompts require newline in Cygwin References: <6ivk16l6f3dbqgumce8onne0sr1b1g14so@4ax.com> Message-ID: <4q4l16hsnc7mth0lhidbnpl773o775fgrq@4ax.com> > If you're willing to recompile, try changing > > let supportSignals = Util.osType = `Unix (*|| Util.isCygwin*) > > in uitext.ml to > > let supportSignals = Util.osType = `Unix || Util.isCygwin > > and see if things improve... Yup, that fixed it. If you're agreeable, I'd like for you to incorporate that change upstream. Meanwhile, for now I'll incorporate it as a patch in the existing Cygwin packages (unison2.27, unison2.32, unison2.40). Thank you for clearing that up. After, what, 5 years of being bothered by that? Andrew. From bcpierce at cis.upenn.edu Thu Jun 17 17:37:50 2010 From: bcpierce at cis.upenn.edu (Benjamin C. Pierce) Date: Thu, 17 Jun 2010 17:37:50 -0400 Subject: [Unison-hackers] prompts require newline in Cygwin In-Reply-To: <4q4l16hsnc7mth0lhidbnpl773o775fgrq@4ax.com> References: <6ivk16l6f3dbqgumce8onne0sr1b1g14so@4ax.com> <4q4l16hsnc7mth0lhidbnpl773o775fgrq@4ax.com> Message-ID: <25DDB986-690F-4485-B5A8-69216A4CE859@cis.upenn.edu> OK, will do. On Jun 17, 2010, at 5:32 PM, Andrew Schulman wrote: >> If you're willing to recompile, try changing >> >> let supportSignals = Util.osType = `Unix (*|| Util.isCygwin*) >> >> in uitext.ml to >> >> let supportSignals = Util.osType = `Unix || Util.isCygwin >> >> and see if things improve... > > Yup, that fixed it. > > If you're agreeable, I'd like for you to incorporate that change upstream. > Meanwhile, for now I'll incorporate it as a patch in the existing Cygwin > packages (unison2.27, unison2.32, unison2.40). > > Thank you for clearing that up. After, what, 5 years of being bothered by > that? > > Andrew. > > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From andrex at alumni.utexas.net Thu Jun 17 17:51:41 2010 From: andrex at alumni.utexas.net (Andrew Schulman) Date: Thu, 17 Jun 2010 17:51:41 -0400 Subject: [Unison-hackers] prompts require newline in Cygwin References: <6ivk16l6f3dbqgumce8onne0sr1b1g14so@4ax.com> Message-ID: > If you're willing to recompile, try changing > > let supportSignals = Util.osType = `Unix (*|| Util.isCygwin*) > > in uitext.ml to > > let supportSignals = Util.osType = `Unix || Util.isCygwin > > and see if things improve... This applies to version 2.40, but not 2.27 or 2.32. It seems that the uitext.ml code has been rewritten since 2.32 - there was no supportSignals flag then. I took a quick look at it and I think I can probably work out what change is needed for Cygwin, but if you can easily suggest the comparable patch for 2.32 and earlier, please do. Thanks, Andrew. From bcpierce at cis.upenn.edu Thu Jun 17 17:53:02 2010 From: bcpierce at cis.upenn.edu (Benjamin C. Pierce) Date: Thu, 17 Jun 2010 17:53:02 -0400 Subject: [Unison-hackers] prompts require newline in Cygwin In-Reply-To: References: <6ivk16l6f3dbqgumce8onne0sr1b1g14so@4ax.com> Message-ID: No idea, I'm afraid. - B On Jun 17, 2010, at 5:51 PM, Andrew Schulman wrote: >> If you're willing to recompile, try changing >> >> let supportSignals = Util.osType = `Unix (*|| Util.isCygwin*) >> >> in uitext.ml to >> >> let supportSignals = Util.osType = `Unix || Util.isCygwin >> >> and see if things improve... > > This applies to version 2.40, but not 2.27 or 2.32. It seems that the > uitext.ml code has been rewritten since 2.32 - there was no supportSignals > flag then. I took a quick look at it and I think I can probably work out > what change is needed for Cygwin, but if you can easily suggest the > comparable patch for 2.32 and earlier, please do. Thanks, Andrew. > > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From trevor at research.att.com Fri Jun 18 00:40:06 2010 From: trevor at research.att.com (Trevor Jim) Date: Fri, 18 Jun 2010 00:40:06 -0400 Subject: [Unison-hackers] An idea for faster initial syncs In-Reply-To: References: Message-ID: <4C1AF8A6.2000701@research.att.com> On 06/17/2010 10:31 AM, Benjamin C. Pierce wrote: > The process of setting up a new laptop this week has brought home to > me, again, the fact that unison's initial scan of the replicas is > horribly slow when the replicas are big (and whose replicas aren't > big these days?). I wonder if it is worth a quick look at the efficiency of the scan. You could for example make a git repo of the repository for comparison (git init & add). This should approximate unison's initial scan. If unison does particularly badly in comparison then it would be worth optimizing, otherwise, some scheme like the one you propose would be necessary. -Trevor From Jerome.Vouillon at pps.jussieu.fr Mon Jun 28 05:41:20 2010 From: Jerome.Vouillon at pps.jussieu.fr (Jerome Vouillon) Date: Mon, 28 Jun 2010 11:41:20 +0200 Subject: [Unison-hackers] An idea for faster initial syncs In-Reply-To: References: Message-ID: <20100628094120.GD9740@pps.jussieu.fr> On Thu, Jun 17, 2010 at 10:31:59AM -0400, Benjamin C. Pierce wrote: > My idea is to add a switch that says to Unison "I know that the > replicas are in sync already and I want to you rebuild your archives > as fast as possible." When this switch is set, Unison would skip > fingerprinting the contents of new files -- it would simply store a > dummy fingerprint (a hash of the file's size and permissions) in the > archive for each file. As long as files are never changed after > this, this dummy fingerprint would never be looked at, so Unison's > behavior would remain the same. If a file is changed at some point > in the future, Unison will fingerprint the new contents, detect a > change, and copy the new version to the other side, again behaving > as it should. The one slight difference in behavior will be that if > a file is really changed on one side but only touched on the other, > Unison will detect a conflict rather than propagating the change. That's an interesting idea, indeed. It can also improve the user experience when one of the replicas is initially empty: Unison will start propagating files right away instead of spending a lot of time scanning files. There should be a way to make Unison replace in the archives the dummy fingerprints by the actual fingerprints. This requires a bit of work, as we have to make sure that the archives are updated simultaneously. But that could be implemented later. > Second, more seriously, if there is some file with different sizes > (or that exists on one replica and not the other), Unison will > calculate a dummy fingerprint during update detection and then later > think that the file hasn't been transferred correctly because the > fingerprints don't match. We may need a special case in the > fingerprint check at the end that recalculates the fingerprint if it > is a dummy. That's the most delicate part, indeed. - when the archive contains a dummy fingerprint, we should not scan the file contents do decide whether the file has been changed, whether fastcheck is set to true or false, so that Update.checkNoUpdates works properly; - Copy.paranoidCheck should just return the computed checksum in case of mismatch. Then, the appropriate action can be taken in Copy.checkContentsChangeLocal, where we will have a possibly dummy fingerprint from update detection and accurate fingerprints of the source file and temporary destination file. As we have computed the actual fingerprint during file transfer, we should put it in the archive. But that could be implemented in a second step. -- Jerome From Jerome.Vouillon at pps.jussieu.fr Mon Jun 28 07:14:12 2010 From: Jerome.Vouillon at pps.jussieu.fr (Jerome Vouillon) Date: Mon, 28 Jun 2010 13:14:12 +0200 Subject: [Unison-hackers] prompts require newline in Cygwin In-Reply-To: <4q4l16hsnc7mth0lhidbnpl773o775fgrq@4ax.com> References: <6ivk16l6f3dbqgumce8onne0sr1b1g14so@4ax.com> <4q4l16hsnc7mth0lhidbnpl773o775fgrq@4ax.com> Message-ID: <20100628111412.GA13975@pps.jussieu.fr> On Thu, Jun 17, 2010 at 05:32:33PM -0400, Andrew Schulman wrote: > > If you're willing to recompile, try changing > > > > let supportSignals = Util.osType = `Unix (*|| Util.isCygwin*) > > > > in uitext.ml to > > > > let supportSignals = Util.osType = `Unix || Util.isCygwin > > > > and see if things improve... > > Yup, that fixed it. I'm surprised this makes any difference. Are you sure the issue is not already fixed in Unison 2.40? The value of the variable "supportSignals" makes a difference only when you suspend Unison: when set to true, Unison will restore the terminal settings before getting suspended. -- Jerome From Jerome.Vouillon at pps.jussieu.fr Mon Jun 28 07:16:43 2010 From: Jerome.Vouillon at pps.jussieu.fr (Jerome Vouillon) Date: Mon, 28 Jun 2010 13:16:43 +0200 Subject: [Unison-hackers] prompts require newline in Cygwin In-Reply-To: References: <6ivk16l6f3dbqgumce8onne0sr1b1g14so@4ax.com> Message-ID: <20100628111643.GB13975@pps.jussieu.fr> On Thu, Jun 17, 2010 at 05:51:41PM -0400, Andrew Schulman wrote: > This applies to version 2.40, but not 2.27 or 2.32. It seems that the > uitext.ml code has been rewritten since 2.32 - there was no supportSignals > flag then. I took a quick look at it and I think I can probably work out > what change is needed for Cygwin, but if you can easily suggest the > comparable patch for 2.32 and earlier, please do. Thanks, Andrew. Try the following patch. -- Jerome Index: uitext.ml =================================================================== --- uitext.ml (r?vision 436) +++ uitext.ml (copie de travail) @@ -71,13 +71,13 @@ Unix.tcsetattr Unix.stdin Unix.TCSANOW state let restoreTerminal() = - if Util.osType = `Unix && not (Prefs.read dumbtty) then + if (Util.osType = `Unix || Util.isCygwin) && not (Prefs.read dumbtty) then Sys.set_signal Sys.sigcont Sys.Signal_default; defaultTerminal (); cbreakMode := None let setupTerminal() = - if Util.osType = `Unix && not (Prefs.read dumbtty) then + if (Util.osType = `Unix || Util.isCygwin) && not (Prefs.read dumbtty) then try cbreakMode := Some (Unix.tcgetattr Unix.stdin); let suspend _ = From alan.schmitt at polytechnique.org Mon Jun 28 09:24:01 2010 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Mon, 28 Jun 2010 15:24:01 +0200 Subject: [Unison-hackers] Command line arguments and OS X GUI In-Reply-To: <4BE40B86.7030609@strank.info> References: <4BE3FB04.3030100@strank.info> <4BE40B86.7030609@strank.info> Message-ID: <84B1348A-330A-470E-B90C-E3CEB8DAA121@polytechnique.org> On 7 mai 2010, at 14:45, Stefan Rank wrote: > on Friday 2010-05-07 14:00 Alan Schmitt said the following: >> On Fri, May 7, 2010 at 1:35 PM, Stefan Rank wrote: > >>> The unison binary that can be installed via the menu option of the >>> macnew GUI (to /usr/bin/unison) calls the internal Unison (capital U) >>> and accepts command-line arguments here. >> >> Yes. And this is where things fail. When I call: >> /usr/bin/unison a.tmp b.tmp >> as specified in the tutorial, I get the profile chooser. (The other >> unison, in my ~/bin directory, is a text only version and works fine.) >> >> Note that this has been reported several times by OS X users: some >> (most?) command line options work, but specifying the roots like above >> does not. > > Yes, you're right. > (Sorry for not trying exactly what you suggested right at the beginning...) > > I just never realised since I am always using profiles, only changing > options, but not directly specifying roots. > > It also accepts the version:: > > unison -root a -root b > > which has the same problem, but it gives an error if you try:: > > unison -root > /Applications/Unison.app/Contents/MacOS/Unison: option `-root' needs > an argument. > > so the option parsing seems to be ok. > I would guess the feature is simply missing from the Mac GUI? Should we try then to fix the GUI, or to change the tutorial? Alan From andrex at alumni.utexas.net Tue Jun 29 10:01:42 2010 From: andrex at alumni.utexas.net (Andrew Schulman) Date: Tue, 29 Jun 2010 10:01:42 -0400 Subject: [Unison-hackers] prompts require newline in Cygwin References: <6ivk16l6f3dbqgumce8onne0sr1b1g14so@4ax.com> <4q4l16hsnc7mth0lhidbnpl773o775fgrq@4ax.com> <20100628111412.GA13975@pps.jussieu.fr> Message-ID: <05vj26tklmdrqavuo3k7m1v9vvteain5l0@4ax.com> > On Thu, Jun 17, 2010 at 05:32:33PM -0400, Andrew Schulman wrote: > > > If you're willing to recompile, try changing > > > > > > let supportSignals = Util.osType = `Unix (*|| Util.isCygwin*) > > > > > > in uitext.ml to > > > > > > let supportSignals = Util.osType = `Unix || Util.isCygwin > > > > > > and see if things improve... > > > > Yup, that fixed it. > > I'm surprised this makes any difference. Are you sure the issue is > not already fixed in Unison 2.40? Yes, you're right. It was already fixed in 2.40. Which is great, but I'm not sure how I overlooked that. From andrex at alumni.utexas.net Tue Jun 29 10:22:29 2010 From: andrex at alumni.utexas.net (Andrew Schulman) Date: Tue, 29 Jun 2010 10:22:29 -0400 Subject: [Unison-hackers] prompts require newline in Cygwin References: <6ivk16l6f3dbqgumce8onne0sr1b1g14so@4ax.com> <20100628111643.GB13975@pps.jussieu.fr> Message-ID: > On Thu, Jun 17, 2010 at 05:51:41PM -0400, Andrew Schulman wrote: > > This applies to version 2.40, but not 2.27 or 2.32. It seems that the > > uitext.ml code has been rewritten since 2.32 - there was no supportSignals > > flag then. I took a quick look at it and I think I can probably work out > > what change is needed for Cygwin, but if you can easily suggest the > > comparable patch for 2.32 and earlier, please do. Thanks, Andrew. > > Try the following patch. No, that didn't work in 2.27 or in 2.32. I applied the patch to both, rebuilt them, and tested the prompts with a simple synchronization. Both still require an Enter after a keypress. From bcpierce at cis.upenn.edu Tue Jun 29 12:19:29 2010 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Tue, 29 Jun 2010 12:19:29 -0400 Subject: [Unison-hackers] A new failure mode... :-) Message-ID: Anybody seen this one? > ETAFailed [Music/iTunes/Mobile Applications/Cro-Mag 1.ipa]: Error in digesting subfile: > Result too large - B From Jerome.Vouillon at pps.jussieu.fr Tue Jun 29 15:56:22 2010 From: Jerome.Vouillon at pps.jussieu.fr (Jerome Vouillon) Date: Tue, 29 Jun 2010 21:56:22 +0200 Subject: [Unison-hackers] A new failure mode... :-) In-Reply-To: References: Message-ID: <20100629195622.GA30340@pps.jussieu.fr> On Tue, Jun 29, 2010 at 12:19:29PM -0400, Benjamin Pierce wrote: > Anybody seen this one? > > > ETAFailed [Music/iTunes/Mobile Applications/Cro-Mag 1.ipa]: Error in digesting subfile: > > Result too large This is the following Unix error: 34 ERANGE Numerical result out of range. A numerical result of the function was too large to fit in the available space (perhaps exceeded precision). Fingerprint.subfile is correctly using LargeFile.seek_in. It also performs some reads. I dont see why this would result in this error... The function is called for fingerprinting resource forks in AppleDouble files. You can check this by using the "-debug osx" option. The only other place it is used is for fingerprinting a file that was partially copied, to make sure that the prefix was correctly transferred. But maybe you should check your filesystem first... http://www.mail-archive.com/rdiff-backup-users at nongnu.org/msg02641.html | Ok, I have tracked this error into the Mac OS X kernel and it looks like | the ERANGE / "Result too large" message comes up when your HFS+ | filesystem is corrupted on that file. -- Jerome