From bcpierce at cis.upenn.edu Sun Apr 1 22:38:52 2007 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Sun, 1 Apr 2007 22:38:52 -0400 Subject: [Unison-hackers] [unison-svn] r214 - in trunk: doc src Message-ID: <200704020238.l322cqvk010579@canfield.cis.upenn.edu> Author: bcpierce Date: 2007-04-01 22:38:52 -0400 (Sun, 01 Apr 2007) New Revision: 214 Modified: trunk/doc/unison-manual.tex trunk/src/RECENTNEWS trunk/src/fileinfo.ml trunk/src/mkProjectInfo.ml trunk/src/update.ml Log: * Set Fileinfo.CtimeStamp to 0, always, following suggestion by Jerome. From bcpierce at cis.upenn.edu Sun Apr 1 22:56:04 2007 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Sun, 1 Apr 2007 22:56:04 -0400 Subject: [Unison-hackers] [unison-svn] r215 - in trunk: doc src Message-ID: <200704020256.l322u4w0011379@canfield.cis.upenn.edu> Author: bcpierce Date: 2007-04-01 22:56:04 -0400 (Sun, 01 Apr 2007) New Revision: 215 Modified: trunk/doc/changes.tex trunk/doc/unison-manual.tex trunk/src/RECENTNEWS trunk/src/mkProjectInfo.ml trunk/src/update.ml Log: * Tidied documentation in preparation for new release. From bcpierce at cis.upenn.edu Sun Apr 1 22:59:07 2007 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Sun, 1 Apr 2007 22:59:07 -0400 Subject: [Unison-hackers] [unison-svn] r216 - in trunk: . src Message-ID: <200704020259.l322x7WY011518@canfield.cis.upenn.edu> Author: bcpierce Date: 2007-04-01 22:59:07 -0400 (Sun, 01 Apr 2007) New Revision: 216 Modified: trunk/Makefile trunk/src/Makefile trunk/src/RECENTNEWS trunk/src/fileinfo.ml trunk/src/mkProjectInfo.ml Log: * Small fix. From bcpierce at cis.upenn.edu Sun Apr 1 23:03:21 2007 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Sun, 1 Apr 2007 23:03:21 -0400 Subject: [Unison-hackers] [unison-svn] r217 - in branches: . 2.17 2.17/src 2.17/src/lwt 2.17/src/ubase 2.27 Message-ID: <200704020303.l3233LvL011780@canfield.cis.upenn.edu> Author: bcpierce Date: 2007-04-01 23:03:20 -0400 (Sun, 01 Apr 2007) New Revision: 217 Added: branches/2.27/ branches/2.27/.depend branches/2.27/COPYING branches/2.27/Makefile branches/2.27/doc/ branches/2.27/icons/ branches/2.27/private/ branches/2.27/publicity/ branches/2.27/src/ branches/2.27/tools/ Removed: branches/2.27/.depend branches/2.27/COPYING branches/2.27/Makefile branches/2.27/doc/ branches/2.27/icons/ branches/2.27/private/ branches/2.27/publicity/ branches/2.27/src/ branches/2.27/tools/ Modified: branches/2.17/Makefile branches/2.17/src/NEWS branches/2.17/src/lwt/depend branches/2.17/src/stasher.ml branches/2.17/src/strings.ml branches/2.17/src/ubase/depend Log: Creating branches/2.27 for new stable release From bcpierce at cis.upenn.edu Sun Apr 1 23:23:46 2007 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Sun, 1 Apr 2007 23:23:46 -0400 Subject: [Unison-hackers] Unison 2.27 promoted to stable Message-ID: Version 2.27 appears to be working well, so I have promoted it to "stable" status. I'll wait a few days before announcing it to the world, to give people time to build binaries and shake out any remaining issues... Regards, - Benjamin From Jerome.Vouillon at pps.jussieu.fr Mon Apr 2 11:32:10 2007 From: Jerome.Vouillon at pps.jussieu.fr (Jerome Vouillon) Date: Mon, 2 Apr 2007 17:32:10 +0200 Subject: [Unison-hackers] Deadlock calling Trace.log in Copy.tryCopyMovedFile In-Reply-To: References: <200703191655.l2JGtT3X002725@canfield.cis.upenn.edu> <20070320095951.GB7507@strontium.pps.jussieu.fr> Message-ID: <20070402153210.GA14847@strontium.pps.jussieu.fr> On Tue, Mar 20, 2007 at 08:58:15AM -0400, Benjamin Pierce wrote: [...] > There was one very strange one where, under windows only, the RPC > mechanism seemed to get confused by nested calls. See the comment in > Copy.tryCopyMovedFile. This might be an interesting challenge. :-) The communication between the client or the server is synchronous when either of them runs under Windows. That is, at any moment in time, they are either allowed to read or write to the socket but not both. The reason is that the Ocaml libraries does not provide any way to know under Windows whether writing or reading to a socket will block ("select" does not work under Windows). This is not that inefficient because the client is allowed to send several requests simultaneously. It then tells the server that it is allowed to write to the socket. Then, the server can send exactly the same number of replies before letting the client sending some more requests. (Note that a RPC from the server behaves the same way as a reply from the server followed by a request of the client, so there is no problem with nested call.) This works fine as long as any request from the client is always eventually followed by a corresponding reply of the server. The problem here is that Trace.log is not threaded and is calling Lwt_unix.run in order to call back the client from the server. But the function Lwt_unix.run introduces some spurious synchronizations between threads, as function calls must be properly nested. This can deadlock as follows: - thread A is blocked inside a call to function Lwt_unix.run waiting for a request from the client; - thread B is blocked in a call to Lwt_unix.run waiting for thread A to exit from the function Lwt_unix.run; - the client is blocked waiting for thread B to terminate and send a reply, in order to be able to write to the socket and send a reply to thread A. I suspect we get a deadlock only because Copy.tryCopyMovedFile is making two consecutive calls to Trace.log. Thus, a workaround would be to call Trace.log only once, after the local copy is performed. But this seems fragile. So, I'm tempted to make Trace.log and Util.warn fail in a bad way on the server (so that we can easily find any call to these functions from the server) and provide some alternative threaded versions of these functions, for instance in file remote.ml. What do you think? -- Jerome From dave at boost-consulting.com Mon Apr 2 19:44:11 2007 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 02 Apr 2007 19:44:11 -0400 Subject: [Unison-hackers] Speaking of bugs... Message-ID: <87k5wul4tw.fsf@valverde.peloton> An embedded and charset-unspecified text was scrubbed... Name: unison.log Url: http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20070402/d25f6ae8/unison-0001.txt From bcpierce at cis.upenn.edu Mon Apr 2 20:51:45 2007 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Mon, 2 Apr 2007 20:51:45 -0400 Subject: [Unison-hackers] Speaking of bugs... In-Reply-To: <87k5wul4tw.fsf@valverde.peloton> References: <87k5wul4tw.fsf@valverde.peloton> Message-ID: <816982B4-A0E5-472B-8C72-D8EBD92E8F57@cis.upenn.edu> Doesn't look like the failure is at the point of trying to write anything. I'd be interested to know whether the same thing happens with 2.27 -- a lot has changed since then! - Benjamin On Apr 2, 2007, at 7:44 PM, David Abrahams wrote: > > with unison version 2.13.16, I have been trying to sync two folders > that were copied from the same source, but have never been sync'd > before. One of them happens to be on a filesystem that's mounted > read-only, but that's the only one that's been changed since the copy, > so presumably that shouldn't make any difference. Unison dies with an > uncaught exception. > > I re-ran the sync in text mode with "-debug all" and the end of the > run looked like the enclosed. If the readonly mount is indeed the > problem, is there some other way to ensure that unison won't write > anything in one of the directory trees? > > > > TIA, > > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com > > Don't Miss BoostCon 2007! ==> http://www.boostcon.com > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From dave at boost-consulting.com Mon Apr 2 21:49:37 2007 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 02 Apr 2007 21:49:37 -0400 Subject: [Unison-hackers] Speaking of bugs... References: <87k5wul4tw.fsf@valverde.peloton> <816982B4-A0E5-472B-8C72-D8EBD92E8F57@cis.upenn.edu> Message-ID: <87ejn2kz0u.fsf@valverde.peloton> on Mon Apr 02 2007, Benjamin Pierce wrote: > Doesn't look like the failure is at the point of trying to write > anything. I'd be interested to know whether the same thing happens > with 2.27 -- a lot has changed since then! So I guess that announcement wasn't an april fools' joke after all. A big jump from 2.13 to 2.27, innit? -- Dave Abrahams Boost Consulting www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com From bcpierce at cis.upenn.edu Mon Apr 2 21:58:21 2007 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Mon, 2 Apr 2007 21:58:21 -0400 Subject: [Unison-hackers] Speaking of bugs... In-Reply-To: <87ejn2kz0u.fsf@valverde.peloton> References: <87k5wul4tw.fsf@valverde.peloton> <816982B4-A0E5-472B-8C72-D8EBD92E8F57@cis.upenn.edu> <87ejn2kz0u.fsf@valverde.peloton> Message-ID: Nope, no foolin'. And yes, it's been too long since there was a stable release!! - B On Apr 2, 2007, at 9:49 PM, David Abrahams wrote: > > on Mon Apr 02 2007, Benjamin Pierce wrote: > >> Doesn't look like the failure is at the point of trying to write >> anything. I'd be interested to know whether the same thing happens >> with 2.27 -- a lot has changed since then! > > So I guess that announcement wasn't an april fools' joke after all. A > big jump from 2.13 to 2.27, innit? > > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com > > Don't Miss BoostCon 2007! ==> http://www.boostcon.com > > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From zpetkovic at acm.org Tue Apr 3 01:08:58 2007 From: zpetkovic at acm.org (Zvezdan Petkovic) Date: Tue, 3 Apr 2007 01:08:58 -0400 Subject: [Unison-hackers] Unison 2.27 promoted to stable In-Reply-To: References: Message-ID: <20070403050857.GA3039@petkovic.homeip.net> On Sun, Apr 01, 2007 at 11:23:46PM -0400, Benjamin Pierce wrote: > Version 2.27 appears to be working well, so I have promoted it to > "stable" status. I'll wait a few days before announcing it to the > world, to give people time to build binaries and shake out any > remaining issues... Still has the same issues on OpenBSD as the 2.26: 1. Creates backup in text UI although I do not have the backups set in the preferences. I'll send the trace to Benjamin off the list. 2. Does not have gtk1 GUI in the Makefile, so I couldn't compile the GUI version to test it. OpenBSD does not have lablgtk2 port, only lablgtk. Lablgtk2 causes a segmentation fault when compiled. Does Unison still have any chance to build with lablgtk? Notice that 2.13 and 2.17 did build fine with that GUI. Zvezdan From Jerome.Vouillon at pps.jussieu.fr Tue Apr 3 10:01:33 2007 From: Jerome.Vouillon at pps.jussieu.fr (Jerome Vouillon) Date: Tue, 3 Apr 2007 16:01:33 +0200 Subject: [Unison-hackers] Speaking of bugs... In-Reply-To: <87k5wul4tw.fsf@valverde.peloton> References: <87k5wul4tw.fsf@valverde.peloton> Message-ID: <20070403140133.GA16875@strontium.pps.jussieu.fr> Hello, On Mon, Apr 02, 2007 at 07:44:11PM -0400, David Abrahams wrote: > with unison version 2.13.16, I have been trying to sync two folders > that were copied from the same source, but have never been sync'd > before. One of them happens to be on a filesystem that's mounted > read-only, but that's the only one that's been changed since the copy, > so presumably that shouldn't make any difference. Unison dies with an > uncaught exception. I suspect the problem is that the folder on the server is very large. So, after checking for updates, the server tries to send back a lot of data. But there is currently a limitation on how much Unison can send in one go over the wire. The workaround is to use the "path" directive to synchronize smaller parts at once. You only have to do this for the initial synchronization, as afterwards the server only sends the differences between the current folder state and its previous state, which is usually small. -- Jerome From ralph-lehmann at gmx.net Tue Apr 3 10:18:55 2007 From: ralph-lehmann at gmx.net (Ralph Lehmann) Date: Tue, 03 Apr 2007 16:18:55 +0200 Subject: [Unison-hackers] Speaking of bugs... In-Reply-To: <20070403140133.GA16875@strontium.pps.jussieu.fr> References: <87k5wul4tw.fsf@valverde.peloton> <20070403140133.GA16875@strontium.pps.jussieu.fr> Message-ID: <4612624F.5020104@gmx.net> Jerome Vouillon schrieb: > Hello, > > On Mon, Apr 02, 2007 at 07:44:11PM -0400, David Abrahams wrote: >> with unison version 2.13.16, I have been trying to sync two folders >> that were copied from the same source, but have never been sync'd >> before. > I suspect the problem is that the folder on the server is very large. > So, after checking for updates, the server tries to send back a lot of > data. But there is currently a limitation on how much Unison can send > in one go over the wire. Could you tell me please, how much data _concrete_ unison accepts on a single synchronization? Thanks! :-) Ralph From bcpierce at cis.upenn.edu Sat Apr 7 16:43:46 2007 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Sat, 7 Apr 2007 16:43:46 -0400 Subject: [Unison-hackers] Deadlock calling Trace.log in Copy.tryCopyMovedFile In-Reply-To: <20070402153210.GA14847@strontium.pps.jussieu.fr> References: <200703191655.l2JGtT3X002725@canfield.cis.upenn.edu> <20070320095951.GB7507@strontium.pps.jussieu.fr> <20070402153210.GA14847@strontium.pps.jussieu.fr> Message-ID: > On Tue, Mar 20, 2007 at 08:58:15AM -0400, Benjamin Pierce wrote: > [...] >> There was one very strange one where, under windows only, the RPC >> mechanism seemed to get confused by nested calls. See the comment in >> Copy.tryCopyMovedFile. This might be an interesting challenge. :-) > > The communication between the client or the server is synchronous when > either of them runs under Windows. That is, at any moment in time, > they are either allowed to read or write to the socket but not both. > The reason is that the Ocaml libraries does not provide any way to > know under Windows whether writing or reading to a socket will block > ("select" does not work under Windows). This is not that inefficient > because the client is allowed to send several requests simultaneously. > It then tells the server that it is allowed to write to the socket. > Then, the server can send exactly the same number of replies before > letting the client sending some more requests. (Note that a RPC from > the server behaves the same way as a reply from the server followed by > a request of the client, so there is no problem with nested call.) > This works fine as long as any request from the client is always > eventually followed by a corresponding reply of the server. Very sneaky. > The problem here is that Trace.log is not threaded and is calling > Lwt_unix.run in order to call back the client from the server. But > the function Lwt_unix.run introduces some spurious synchronizations > between threads, as function calls must be properly nested. This can > deadlock as follows: > - thread A is blocked inside a call to function Lwt_unix.run waiting > for a request from the client; > - thread B is blocked in a call to Lwt_unix.run waiting for thread A > to exit from the function Lwt_unix.run; > - the client is blocked waiting for thread B to terminate and send a > reply, in order to be able to write to the socket and send a reply > to thread A. > > I suspect we get a deadlock only because Copy.tryCopyMovedFile is > making two consecutive calls to Trace.log. Thus, a workaround would > be to call Trace.log only once, after the local copy is performed. > But this seems fragile. So, I'm tempted to make Trace.log and > Util.warn fail in a bad way on the server (so that we can easily find > any call to these functions from the server) and provide some > alternative threaded versions of these functions, for instance in file > remote.ml. What do you think? I don't understand the details completely, but the overall scheme sounds fine. Would it be hard to implement? Even the workaround would be an improvement over simply skipping printing those messages (people seem to like to know that files are being copied locally instead of being transferred across the network!). - Benjamin From bcpierce at cis.upenn.edu Sat Apr 7 17:27:01 2007 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Sat, 7 Apr 2007 17:27:01 -0400 Subject: [Unison-hackers] Unison 2.27 promoted to stable In-Reply-To: <20070403050857.GA3039@petkovic.homeip.net> References: <20070403050857.GA3039@petkovic.homeip.net> Message-ID: > On Sun, Apr 01, 2007 at 11:23:46PM -0400, Benjamin Pierce wrote: >> Version 2.27 appears to be working well, so I have promoted it to >> "stable" status. I'll wait a few days before announcing it to the >> world, to give people time to build binaries and shake out any >> remaining issues... > > Still has the same issues on OpenBSD as the 2.26: > > 1. Creates backup in text UI although I do not have the backups > set in the preferences. I'll send the trace to Benjamin off > the list. Looks like 2.27 is backing up current versions of all files that have the 'merge' preference set. I agree that this is counter-intuitive (the backupcurrent option is available for requesting backups of current versions) and will change it. > 2. Does not have gtk1 GUI in the Makefile, so I couldn't compile > the GUI version to test it. OpenBSD does not have lablgtk2 > port, only lablgtk. Lablgtk2 causes a segmentation fault > when compiled. Does Unison still have any chance to build > with lablgtk? Notice that 2.13 and 2.17 did build fine with > that GUI. Working on this... - B From bcpierce at cis.upenn.edu Sat Apr 7 17:30:12 2007 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Sat, 7 Apr 2007 17:30:12 -0400 Subject: [Unison-hackers] [unison-svn] r218 - branches/2.27/src Message-ID: <200704072130.l37LUCUf017506@canfield.cis.upenn.edu> Author: bcpierce Date: 2007-04-07 17:30:12 -0400 (Sat, 07 Apr 2007) New Revision: 218 Modified: branches/2.27/src/NEWS branches/2.27/src/RECENTNEWS branches/2.27/src/mkProjectInfo.ml branches/2.27/src/stasher.ml branches/2.27/src/strings.ml Log: * Unison no longer keeps backups of the current versions of files for which the 'merge' preference is set. (Use backupcurrent for this.) From bcpierce at cis.upenn.edu Mon Apr 9 10:19:51 2007 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Mon, 9 Apr 2007 10:19:51 -0400 Subject: [Unison-hackers] [unison-svn] r219 - branches/2.27/src Message-ID: <200704091419.l39EJpZx008190@canfield.cis.upenn.edu> Author: bcpierce Date: 2007-04-09 10:19:51 -0400 (Mon, 09 Apr 2007) New Revision: 219 Modified: branches/2.27/src/RECENTNEWS branches/2.27/src/mkProjectInfo.ml branches/2.27/src/uigtk.ml Log: * Make the GTK(1) user interface compile again. (Thanks to Zvezdan Petkovic.) From bcpierce at cis.upenn.edu Mon Apr 9 10:35:45 2007 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Mon, 9 Apr 2007 10:35:45 -0400 Subject: [Unison-hackers] [unison-svn] r220 - trunk/src Message-ID: <200704091435.l39EZjQK009085@canfield.cis.upenn.edu> Author: bcpierce Date: 2007-04-09 10:35:44 -0400 (Mon, 09 Apr 2007) New Revision: 220 Modified: trunk/src/Makefile.OCaml trunk/src/RECENTNEWS trunk/src/mkProjectInfo.ml trunk/src/stasher.ml trunk/src/uigtk.ml Log: * Make the GTK(1) user interface compile again. (Thanks to Zvezdan Petkovic.) From bcpierce at cis.upenn.edu Thu Apr 12 15:15:33 2007 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Thu, 12 Apr 2007 15:15:33 -0400 Subject: [Unison-hackers] [unison-svn] r221 - in trunk: . src Message-ID: <200704121915.l3CJFXf7002977@canfield.cis.upenn.edu> Author: bcpierce Date: 2007-04-12 15:15:33 -0400 (Thu, 12 Apr 2007) New Revision: 221 Modified: trunk/Makefile trunk/src/Makefile.OCaml trunk/src/RECENTNEWS trunk/src/mkProjectInfo.ml Log: * Correction to earlier patch From bcpierce at cis.upenn.edu Thu Apr 12 15:16:54 2007 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Thu, 12 Apr 2007 15:16:54 -0400 Subject: [Unison-hackers] [unison-svn] r222 - branches/2.27/src Message-ID: <200704121916.l3CJGsut003036@canfield.cis.upenn.edu> Author: bcpierce Date: 2007-04-12 15:16:54 -0400 (Thu, 12 Apr 2007) New Revision: 222 Modified: branches/2.27/src/Makefile.OCaml branches/2.27/src/NEWS branches/2.27/src/RECENTNEWS branches/2.27/src/mkProjectInfo.ml branches/2.27/src/strings.ml Log: * Make the GTK(1) user interface compile again. (Thanks to Zvezdan Petkovic.) From tsunamithecat at mac.com Thu Apr 12 18:38:11 2007 From: tsunamithecat at mac.com (Matthew Alford) Date: Thu, 12 Apr 2007 15:38:11 -0700 Subject: [Unison-hackers] stable 2.27 build - mac Message-ID: Anyone have a recent universal binary that he/she can recommend and/ or share. Thanks Matthew From alan.schmitt at polytechnique.org Fri Apr 13 05:47:29 2007 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Fri, 13 Apr 2007 11:47:29 +0200 Subject: [Unison-hackers] stable 2.27 build - mac In-Reply-To: References: Message-ID: <7E180074-EC2F-499A-98C2-248BE1438FEC@polytechnique.org> Il giorno 13/apr/07, alle ore 00:38, Matthew Alford ha scritto: > Anyone have a recent universal binary that he/she can recommend and/ > or share. I put some there (text version). It's my first use of lipo, so I hope I got it right (but it's working here). http://alan.petitepomme.net/projets/unison/index.html Alan -- Alan Schmitt The hacker: someone who figured things out and made something cool happen. .O. ..O OOO -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: =?ISO-8859-1?Q?Questa_=E8_un_messaggio_firmato_elettronicamente?= Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20070413/c4c9d267/PGP.sig From bcpierce at cis.upenn.edu Fri Apr 13 09:36:13 2007 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Fri, 13 Apr 2007 09:36:13 -0400 Subject: [Unison-hackers] 2.27 demoted to beta-release; 2.13 is again the stable release Message-ID: <9A47C89A-057D-4D3D-856C-DFF6994C148E@cis.upenn.edu> There still appear to be a couple of issues with 2.27 that should be fixed before it becomes the release everybody is using. So I have restored 2.13.16 as the stable release and made 2.27 only a beta- release. I will make a general announcement of the availability of 2.27 shortly. Regards, - Benjamin From bcpierce at cis.upenn.edu Fri Apr 13 10:30:02 2007 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Fri, 13 Apr 2007 10:30:02 -0400 Subject: [Unison-hackers] [unison-svn] r223 - branches/2.27/src Message-ID: <200704131430.l3DEU2ul007328@canfield.cis.upenn.edu> Author: bcpierce Date: 2007-04-13 10:30:01 -0400 (Fri, 13 Apr 2007) New Revision: 223 Modified: branches/2.27/src/RECENTNEWS branches/2.27/src/mkProjectInfo.ml branches/2.27/src/pty.c Log: * Make Unison compile out of the box on FreeBSD. (Thanks to Kurt Bond.) From bcpierce at cis.upenn.edu Fri Apr 13 11:43:43 2007 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Fri, 13 Apr 2007 11:43:43 -0400 Subject: [Unison-hackers] [unison-svn] r224 - in branches/2.27/src: . uimacnew Message-ID: <200704131543.l3DFhh3R010828@canfield.cis.upenn.edu> Author: bcpierce Date: 2007-04-13 11:43:42 -0400 (Fri, 13 Apr 2007) New Revision: 224 Added: branches/2.27/src/uimacbridgenew.ml branches/2.27/src/uimacnew/ branches/2.27/src/uimacnew/English.lproj/ branches/2.27/src/uimacnew/Growl.framework/ branches/2.27/src/uimacnew/Info.plist.template branches/2.27/src/uimacnew/MyController.h branches/2.27/src/uimacnew/MyController.m branches/2.27/src/uimacnew/NotificationController.h branches/2.27/src/uimacnew/NotificationController.m branches/2.27/src/uimacnew/PreferencesController.h branches/2.27/src/uimacnew/PreferencesController.m branches/2.27/src/uimacnew/ProfileController.h branches/2.27/src/uimacnew/ProfileController.m branches/2.27/src/uimacnew/ProfileTableView.h branches/2.27/src/uimacnew/ProfileTableView.m branches/2.27/src/uimacnew/ReconItem.h branches/2.27/src/uimacnew/ReconItem.m branches/2.27/src/uimacnew/ReconTableView.h branches/2.27/src/uimacnew/ReconTableView.m branches/2.27/src/uimacnew/TrevorsUnison.icns branches/2.27/src/uimacnew/Unison.icns branches/2.27/src/uimacnew/UnisonToolbar.h branches/2.27/src/uimacnew/UnisonToolbar.m branches/2.27/src/uimacnew/cltool.c branches/2.27/src/uimacnew/main.m branches/2.27/src/uimacnew/tableicons/ branches/2.27/src/uimacnew/toolbar/ branches/2.27/src/uimacnew/uimac.pbproj/ branches/2.27/src/uimacnew/uimac.xcodeproj/ Removed: branches/2.27/src/uimac/ branches/2.27/src/uimacbridge.ml branches/2.27/src/uimacnew/English.lproj/ branches/2.27/src/uimacnew/Growl.framework/ branches/2.27/src/uimacnew/Info.plist.template branches/2.27/src/uimacnew/MyController.h branches/2.27/src/uimacnew/MyController.m branches/2.27/src/uimacnew/NotificationController.h branches/2.27/src/uimacnew/NotificationController.m branches/2.27/src/uimacnew/PreferencesController.h branches/2.27/src/uimacnew/PreferencesController.m branches/2.27/src/uimacnew/ProfileController.h branches/2.27/src/uimacnew/ProfileController.m branches/2.27/src/uimacnew/ProfileTableView.h branches/2.27/src/uimacnew/ProfileTableView.m branches/2.27/src/uimacnew/ReconItem.h branches/2.27/src/uimacnew/ReconItem.m branches/2.27/src/uimacnew/ReconTableView.h branches/2.27/src/uimacnew/ReconTableView.m branches/2.27/src/uimacnew/TrevorsUnison.icns branches/2.27/src/uimacnew/Unison.icns branches/2.27/src/uimacnew/UnisonToolbar.h branches/2.27/src/uimacnew/UnisonToolbar.m branches/2.27/src/uimacnew/cltool.c branches/2.27/src/uimacnew/main.m branches/2.27/src/uimacnew/tableicons/ branches/2.27/src/uimacnew/toolbar/ branches/2.27/src/uimacnew/uimac.pbproj/ branches/2.27/src/uimacnew/uimac.xcodeproj/ Modified: branches/2.27/src/Makefile.OCaml branches/2.27/src/RECENTNEWS branches/2.27/src/mkProjectInfo.ml Log: * Rename OSX GUI from "mac" to "macnew" (in preparation for restoring old GUI and calling it "mac") From bcpierce at cis.upenn.edu Fri Apr 13 15:12:47 2007 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Fri, 13 Apr 2007 15:12:47 -0400 Subject: [Unison-hackers] [unison-svn] r225 - in branches/2.27/src: . uimac Message-ID: <200704131912.l3DJCl9W020496@canfield.cis.upenn.edu> Author: bcpierce Date: 2007-04-13 15:12:47 -0400 (Fri, 13 Apr 2007) New Revision: 225 Added: branches/2.27/src/uimac/ branches/2.27/src/uimac/Info.plist.template branches/2.27/src/uimacbridge.ml Modified: branches/2.27/src/Makefile.OCaml branches/2.27/src/RECENTNEWS branches/2.27/src/mkProjectInfo.ml branches/2.27/src/uimac/Info.plist Log: * Restored old OSX GUI from version 2.17. This UI is not nearly as pretty or featureful as the new one that's been under construction for a while, but at least it works! (The new one does not handle multiple UI threads correctly when it is calling back and forth between OCaml and Objective C, leading to UI freezes and random crashes.) Building Unison with 'make UISTYLE=mac' will build you the old, working UI. Building with 'make UISTYLE=macnew' will build you the new UI, in case you'd like to help fix it. :-) From bcpierce at cis.upenn.edu Fri Apr 13 15:33:42 2007 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Fri, 13 Apr 2007 15:33:42 -0400 Subject: [Unison-hackers] [unison-svn] r226 - in trunk/src: . uimacnew uimacnew/English.lproj uimacnew/English.lproj/MainMenu.nib uimacnew/Growl.framework uimacnew/Growl.framework/Versions uimacnew/Growl.framework/Versions/A uimacnew/Growl.framework/Versions/A/Headers uimacnew/Growl.framework/Versions/A/Resources uimacnew/tableicons uimacnew/toolbar uimacnew/uimac.pbproj uimacnew/uimac.xcodeproj Message-ID: <200704131933.l3DJXgmP021503@canfield.cis.upenn.edu> Author: bcpierce Date: 2007-04-13 15:33:39 -0400 (Fri, 13 Apr 2007) New Revision: 226 Added: trunk/src/uimacbridgenew.ml trunk/src/uimacnew/ trunk/src/uimacnew/English.lproj/ trunk/src/uimacnew/English.lproj/InfoPlist.strings trunk/src/uimacnew/English.lproj/MainMenu.nib/ trunk/src/uimacnew/English.lproj/MainMenu.nib/classes.nib trunk/src/uimacnew/English.lproj/MainMenu.nib/info.nib trunk/src/uimacnew/English.lproj/MainMenu.nib/keyedobjects.nib trunk/src/uimacnew/English.lproj/MainMenu.nib/objects.nib trunk/src/uimacnew/Growl.framework/ trunk/src/uimacnew/Growl.framework/Growl trunk/src/uimacnew/Growl.framework/Headers trunk/src/uimacnew/Growl.framework/Resources trunk/src/uimacnew/Growl.framework/Versions/ trunk/src/uimacnew/Growl.framework/Versions/A/ trunk/src/uimacnew/Growl.framework/Versions/A/Growl trunk/src/uimacnew/Growl.framework/Versions/A/Headers/ trunk/src/uimacnew/Growl.framework/Versions/A/Headers/Growl.h trunk/src/uimacnew/Growl.framework/Versions/A/Headers/GrowlApplicationBridge-Carbon.h trunk/src/uimacnew/Growl.framework/Versions/A/Headers/GrowlApplicationBridge.h trunk/src/uimacnew/Growl.framework/Versions/A/Headers/GrowlDefines.h trunk/src/uimacnew/Growl.framework/Versions/A/Resources/ trunk/src/uimacnew/Growl.framework/Versions/A/Resources/Info.plist trunk/src/uimacnew/Growl.framework/Versions/Current trunk/src/uimacnew/Info.plist.template trunk/src/uimacnew/MyController.h trunk/src/uimacnew/MyController.m trunk/src/uimacnew/NotificationController.h trunk/src/uimacnew/NotificationController.m trunk/src/uimacnew/PreferencesController.h trunk/src/uimacnew/PreferencesController.m trunk/src/uimacnew/ProfileController.h trunk/src/uimacnew/ProfileController.m trunk/src/uimacnew/ProfileTableView.h trunk/src/uimacnew/ProfileTableView.m trunk/src/uimacnew/ReconItem.h trunk/src/uimacnew/ReconItem.m trunk/src/uimacnew/ReconTableView.h trunk/src/uimacnew/ReconTableView.m trunk/src/uimacnew/TrevorsUnison.icns trunk/src/uimacnew/Unison.icns trunk/src/uimacnew/UnisonToolbar.h trunk/src/uimacnew/UnisonToolbar.m trunk/src/uimacnew/cltool.c trunk/src/uimacnew/main.m trunk/src/uimacnew/tableicons/ trunk/src/uimacnew/tableicons/table-conflict.tif trunk/src/uimacnew/tableicons/table-error.tif trunk/src/uimacnew/tableicons/table-left-blue.tif trunk/src/uimacnew/tableicons/table-left-green.tif trunk/src/uimacnew/tableicons/table-merge.tif trunk/src/uimacnew/tableicons/table-right-blue.tif trunk/src/uimacnew/tableicons/table-right-green.tif trunk/src/uimacnew/tableicons/table-skip.tif trunk/src/uimacnew/toolbar/ trunk/src/uimacnew/toolbar/add.tif trunk/src/uimacnew/toolbar/diff.tif trunk/src/uimacnew/toolbar/go.tif trunk/src/uimacnew/toolbar/left.tif trunk/src/uimacnew/toolbar/merge.tif trunk/src/uimacnew/toolbar/quit.tif trunk/src/uimacnew/toolbar/rescan.tif trunk/src/uimacnew/toolbar/restart.tif trunk/src/uimacnew/toolbar/right.tif trunk/src/uimacnew/toolbar/save.tif trunk/src/uimacnew/toolbar/skip.tif trunk/src/uimacnew/uimac.pbproj/ trunk/src/uimacnew/uimac.pbproj/project.pbxproj trunk/src/uimacnew/uimac.xcodeproj/ trunk/src/uimacnew/uimac.xcodeproj/project.pbxproj Removed: trunk/src/uimac/ trunk/src/uimacnew/English.lproj/ trunk/src/uimacnew/English.lproj/InfoPlist.strings trunk/src/uimacnew/English.lproj/MainMenu.nib/ trunk/src/uimacnew/English.lproj/MainMenu.nib/classes.nib trunk/src/uimacnew/English.lproj/MainMenu.nib/info.nib trunk/src/uimacnew/English.lproj/MainMenu.nib/keyedobjects.nib trunk/src/uimacnew/English.lproj/MainMenu.nib/objects.nib trunk/src/uimacnew/Growl.framework/ trunk/src/uimacnew/Growl.framework/Growl trunk/src/uimacnew/Growl.framework/Headers trunk/src/uimacnew/Growl.framework/Resources trunk/src/uimacnew/Growl.framework/Versions/ trunk/src/uimacnew/Growl.framework/Versions/A/ trunk/src/uimacnew/Growl.framework/Versions/A/Growl trunk/src/uimacnew/Growl.framework/Versions/A/Headers/ trunk/src/uimacnew/Growl.framework/Versions/A/Headers/Growl.h trunk/src/uimacnew/Growl.framework/Versions/A/Headers/GrowlApplicationBridge-Carbon.h trunk/src/uimacnew/Growl.framework/Versions/A/Headers/GrowlApplicationBridge.h trunk/src/uimacnew/Growl.framework/Versions/A/Headers/GrowlDefines.h trunk/src/uimacnew/Growl.framework/Versions/A/Resources/ trunk/src/uimacnew/Growl.framework/Versions/A/Resources/Info.plist trunk/src/uimacnew/Growl.framework/Versions/Current trunk/src/uimacnew/Info.plist.template trunk/src/uimacnew/MyController.h trunk/src/uimacnew/MyController.m trunk/src/uimacnew/NotificationController.h trunk/src/uimacnew/NotificationController.m trunk/src/uimacnew/PreferencesController.h trunk/src/uimacnew/PreferencesController.m trunk/src/uimacnew/ProfileController.h trunk/src/uimacnew/ProfileController.m trunk/src/uimacnew/ProfileTableView.h trunk/src/uimacnew/ProfileTableView.m trunk/src/uimacnew/ReconItem.h trunk/src/uimacnew/ReconItem.m trunk/src/uimacnew/ReconTableView.h trunk/src/uimacnew/ReconTableView.m trunk/src/uimacnew/TrevorsUnison.icns trunk/src/uimacnew/Unison.icns trunk/src/uimacnew/UnisonToolbar.h trunk/src/uimacnew/UnisonToolbar.m trunk/src/uimacnew/cltool.c trunk/src/uimacnew/main.m trunk/src/uimacnew/tableicons/ trunk/src/uimacnew/tableicons/table-conflict.tif trunk/src/uimacnew/tableicons/table-error.tif trunk/src/uimacnew/tableicons/table-left-blue.tif trunk/src/uimacnew/tableicons/table-left-green.tif trunk/src/uimacnew/tableicons/table-merge.tif trunk/src/uimacnew/tableicons/table-right-blue.tif trunk/src/uimacnew/tableicons/table-right-green.tif trunk/src/uimacnew/tableicons/table-skip.tif trunk/src/uimacnew/toolbar/ trunk/src/uimacnew/toolbar/add.tif trunk/src/uimacnew/toolbar/diff.tif trunk/src/uimacnew/toolbar/go.tif trunk/src/uimacnew/toolbar/left.tif trunk/src/uimacnew/toolbar/merge.tif trunk/src/uimacnew/toolbar/quit.tif trunk/src/uimacnew/toolbar/rescan.tif trunk/src/uimacnew/toolbar/restart.tif trunk/src/uimacnew/toolbar/right.tif trunk/src/uimacnew/toolbar/save.tif trunk/src/uimacnew/toolbar/skip.tif trunk/src/uimacnew/uimac.pbproj/ trunk/src/uimacnew/uimac.pbproj/project.pbxproj trunk/src/uimacnew/uimac.xcodeproj/ trunk/src/uimacnew/uimac.xcodeproj/project.pbxproj Modified: trunk/src/Makefile.OCaml trunk/src/RECENTNEWS trunk/src/mkProjectInfo.ml trunk/src/pty.c trunk/src/uimacbridge.ml trunk/src/uitext.ml Log: * Copying over changes from 2.27 branch to developer sources (checkpoint) From bcpierce at cis.upenn.edu Fri Apr 13 15:43:44 2007 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Fri, 13 Apr 2007 15:43:44 -0400 Subject: [Unison-hackers] [unison-svn] r227 - in trunk/src: . uimac Message-ID: <200704131943.l3DJhi9l022007@canfield.cis.upenn.edu> Author: bcpierce Date: 2007-04-13 15:43:44 -0400 (Fri, 13 Apr 2007) New Revision: 227 Added: trunk/src/uimac/ trunk/src/uimac/Info.plist.template Modified: trunk/src/RECENTNEWS trunk/src/mkProjectInfo.ml trunk/src/uimac/Info.plist Log: * Copy small fix From bcpierce at cis.upenn.edu Fri Apr 13 15:47:47 2007 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Fri, 13 Apr 2007 15:47:47 -0400 Subject: [Unison-hackers] [unison-svn] r228 - in branches/2.27: doc src src/uimac Message-ID: <200704131947.l3DJlllb022181@canfield.cis.upenn.edu> Author: bcpierce Date: 2007-04-13 15:47:47 -0400 (Fri, 13 Apr 2007) New Revision: 228 Modified: branches/2.27/doc/changes.tex branches/2.27/src/RECENTNEWS branches/2.27/src/mkProjectInfo.ml branches/2.27/src/uimac/Info.plist branches/2.27/src/uimac/Info.plist.template Log: * Small fix to last checkin. * Tidy documentation of recent changes. From bcpierce at cis.upenn.edu Fri Apr 13 16:02:33 2007 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Fri, 13 Apr 2007 16:02:33 -0400 Subject: [Unison-hackers] [unison-svn] r229 - in branches/2.27: . src Message-ID: <200704132002.l3DK2XkL022897@canfield.cis.upenn.edu> Author: bcpierce Date: 2007-04-13 16:02:32 -0400 (Fri, 13 Apr 2007) New Revision: 229 Modified: branches/2.27/Makefile branches/2.27/src/NEWS branches/2.27/src/RECENTNEWS branches/2.27/src/mkProjectInfo.ml branches/2.27/src/strings.ml Log: * Small makefile fixes to export procedure From bcpierce at cis.upenn.edu Fri Apr 13 17:29:16 2007 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Fri, 13 Apr 2007 17:29:16 -0400 Subject: [Unison-hackers] [unison-svn] r230 - in trunk: doc src Message-ID: <200704132129.l3DLTG7u026842@canfield.cis.upenn.edu> Author: bcpierce Date: 2007-04-13 17:29:15 -0400 (Fri, 13 Apr 2007) New Revision: 230 Modified: trunk/doc/changes.tex trunk/src/Makefile trunk/src/RECENTNEWS trunk/src/mkProjectInfo.ml trunk/src/uitext.ml Log: * 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 me improve it (e.g., by writing a filesystem watcher for your favorite OS), please let me know. On the Unison side, the new behavior is incredibly 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. Since I'm an OSX user, I'm particularly interested in writing a watcher tool for this platform. If anybody knows about programming against the Spotlight API and can give me a hand, that would be much appreciated. From laurent.franceschetti at settlenext.com Sat Apr 14 04:09:10 2007 From: laurent.franceschetti at settlenext.com (Laurent Franceschetti (SettleNext)) Date: Sat, 14 Apr 2007 10:09:10 +0200 Subject: [Unison-hackers] unsubscribe In-Reply-To: <200704121915.l3CJFXf7002977@canfield.cis.upenn.edu> Message-ID: <200704140809.l3E89BHt020840@smtp2.infomaniak.ch> > -----Message d'origine----- > De : unison-hackers-bounces at lists.seas.upenn.edu > [mailto:unison-hackers-bounces at lists.seas.upenn.edu] De la > part de bcpierce at cis.upenn.edu > Envoy? : jeudi, 12. avril 2007 21:16 > ? : unison-hackers at lists.seas.upenn.edu > Objet : [Unison-hackers] [unison-svn] r221 - in trunk: . src > > Author: bcpierce > Date: 2007-04-12 15:15:33 -0400 (Thu, 12 Apr 2007) New Revision: 221 > > Modified: > trunk/Makefile > trunk/src/Makefile.OCaml > trunk/src/RECENTNEWS > trunk/src/mkProjectInfo.ml > Log: > * Correction to earlier patch > > > _______________________________________________ > 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 Sun Apr 15 15:07:04 2007 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Sun, 15 Apr 2007 15:07:04 -0400 Subject: [Unison-hackers] [unison-svn] r231 - branches/2.27/src Message-ID: <200704151907.l3FJ74kG022482@canfield.cis.upenn.edu> Author: bcpierce Date: 2007-04-15 15:07:04 -0400 (Sun, 15 Apr 2007) New Revision: 231 Modified: branches/2.27/src/RECENTNEWS branches/2.27/src/mkProjectInfo.ml branches/2.27/src/update.ml Log: * Small fix to ctime (non-)handling in update detection under windows with fastcheck. This *might* fix the bug that Karl M. has reported. From bcpierce at cis.upenn.edu Sun Apr 15 15:08:37 2007 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Sun, 15 Apr 2007 15:08:37 -0400 Subject: [Unison-hackers] [unison-svn] r232 - trunk/src Message-ID: <200704151908.l3FJ8bhZ022541@canfield.cis.upenn.edu> Author: bcpierce Date: 2007-04-15 15:08:37 -0400 (Sun, 15 Apr 2007) New Revision: 232 Modified: trunk/src/RECENTNEWS trunk/src/mkProjectInfo.ml Log: * Small fix to ctime (non-)handling in update detection under windows with fastcheck. This *might* fix the bug that Karl M. has reported. (Copying fix into trunk.) From bcpierce at cis.upenn.edu Mon Apr 16 13:34:29 2007 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Mon, 16 Apr 2007 13:34:29 -0400 Subject: [Unison-hackers] [unison-svn] r233 - trunk/src Message-ID: <200704161734.l3GHYThe022938@canfield.cis.upenn.edu> Author: bcpierce Date: 2007-04-16 13:34:28 -0400 (Mon, 16 Apr 2007) New Revision: 233 Modified: trunk/src/RECENTNEWS trunk/src/fileinfo.ml trunk/src/mkProjectInfo.ml trunk/src/osx.ml trunk/src/update.ml Log: * Another fix to ctime (non-)handling From rrnewton at gmail.com Fri Apr 20 10:19:26 2007 From: rrnewton at gmail.com (Ryan Newton) Date: Fri, 20 Apr 2007 10:19:26 -0400 Subject: [Unison-hackers] Unix.sleep insufficient for -repeat! Need half seconds. Message-ID: <882DFBA1-F04B-44EE-BDF3-A7A4AB83E377@gmail.com> Hello all, I use the -repeat option *extensively* to establish a relatively low- bandwidth, poor man's distributed file system. Basically, if my connection is good enough, I do development by running emacs over X11 forwarding from the server. If it's not good enough, I run emacs locally, use unison -repeat, and compile/run the program on the server over a simple ssh terminal. I imagine many others use unison for this same purpose. The problem is: "unison -repeat 1" is too slow! And "unison -repeat 0" is too fast and too hard on both systems. I need unison -repeat 0.5. Of course, uitext.ml uses Unix.sleep, which will only sleep an integral number of seconds. To my knowledge, the standard OCaml libraries don't include anything like C's "usleep". However, I argue that wrapping usleep for Caml is easy, and worth doing! Besides, I see that the unison repository already has some dependencies on C code. Are there any objections to this small modification? I haven't hacked unison before, but I might try making this change, in which case I'll submit a patch to this list. Best, -Ryan From bcpierce at cis.upenn.edu Fri Apr 20 11:54:33 2007 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Fri, 20 Apr 2007 11:54:33 -0400 Subject: [Unison-hackers] Unix.sleep insufficient for -repeat! Need half seconds. In-Reply-To: <882DFBA1-F04B-44EE-BDF3-A7A4AB83E377@gmail.com> References: <882DFBA1-F04B-44EE-BDF3-A7A4AB83E377@gmail.com> Message-ID: <78CAA5B9-DB02-4A30-96A9-ECAA6D67CA8F@cis.upenn.edu> I'd be very happy to see this change. Couple of thoughts: * One reason that usleep is not wrapped for OCaml might be (I don't know) that Win32 doesn't offer something comparable. Whatever solution is adopted here needs to at least compile cross-platform, even if the full functionality isn't available everywhere. And it needs to degrade in a graceful way. * It might also be worth considering using the new extension of the "repeat" functionality to save processor and disk load (unless it is really just a couple of files that you want to watch) by getting the filesystem to notify Unison (via an external watcher program that, at the moment, still needs to be written!) when it should look for changes. However, making Unison sleep for fractions of a second will also be needed for this scenario, so your proposed change is the place to start. Regards, - Benjamin On Apr 20, 2007, at 10:19 AM, Ryan Newton wrote: > Hello all, > > I use the -repeat option *extensively* to establish a relatively low- > bandwidth, poor man's distributed file system. Basically, if my > connection is good enough, I do development by running emacs over X11 > forwarding from the server. If it's not good enough, I run emacs > locally, use unison -repeat, and compile/run the program on the > server over a simple ssh terminal. > > I imagine many others use unison for this same purpose. > > The problem is: "unison -repeat 1" is too slow! And "unison -repeat > 0" is too fast and too hard on both systems. I need unison -repeat > 0.5. > > Of course, uitext.ml uses Unix.sleep, which will only sleep an > integral number of seconds. To my knowledge, the standard OCaml > libraries don't include anything like C's "usleep". > > However, I argue that wrapping usleep for Caml is easy, and worth > doing! Besides, I see that the unison repository already has some > dependencies on C code. > > Are there any objections to this small modification? I haven't > hacked unison before, but I might try making this change, in which > case I'll submit a patch to this list. > > Best, > -Ryan > > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From jdunn14 at hotpop.com Fri Apr 20 18:59:10 2007 From: jdunn14 at hotpop.com (Joseph Dunn) Date: Fri, 20 Apr 2007 16:59:10 -0600 Subject: [Unison-hackers] Unix.sleep insufficient for -repeat! Need half seconds. In-Reply-To: <78CAA5B9-DB02-4A30-96A9-ECAA6D67CA8F@cis.upenn.edu> References: <882DFBA1-F04B-44EE-BDF3-A7A4AB83E377@gmail.com> <78CAA5B9-DB02-4A30-96A9-ECAA6D67CA8F@cis.upenn.edu> Message-ID: <20070420165910.273ed4d7@porkrind> On Fri, 20 Apr 2007 11:54:33 -0400 Benjamin Pierce wrote: > I'd be very happy to see this change. Couple of thoughts: > > * One reason that usleep is not wrapped for OCaml might be (I don't > know) that Win32 doesn't offer something comparable. Whatever > solution is adopted here needs to at least compile cross-platform, > even if the full functionality isn't available everywhere. And it > needs to degrade in a graceful way. > The argument to the Windows Sleep() function is in milliseconds, so if that's fine enough granularity for you then you can make a cross platform millisecond sleep without much trouble. Alternatively, people sometimes use calls to select() to do sub second timings, but it's not the best way to go. -Joseph From bcpierce at cis.upenn.edu Fri Apr 20 23:22:53 2007 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Fri, 20 Apr 2007 23:22:53 -0400 Subject: [Unison-hackers] Unix.sleep insufficient for -repeat! Need half seconds. In-Reply-To: <20070420165910.273ed4d7@porkrind> References: <882DFBA1-F04B-44EE-BDF3-A7A4AB83E377@gmail.com> <78CAA5B9-DB02-4A30-96A9-ECAA6D67CA8F@cis.upenn.edu> <20070420165910.273ed4d7@porkrind> Message-ID: <7F8293C6-F254-46D9-8CBC-2DE99FC7307D@cis.upenn.edu> Perfect. So this change should be pretty easy, then. Thanks, - B On Apr 20, 2007, at 6:59 PM, Joseph Dunn wrote: > On Fri, 20 Apr 2007 11:54:33 -0400 > Benjamin Pierce wrote: > >> I'd be very happy to see this change. Couple of thoughts: >> >> * One reason that usleep is not wrapped for OCaml might be (I don't >> know) that Win32 doesn't offer something comparable. Whatever >> solution is adopted here needs to at least compile cross-platform, >> even if the full functionality isn't available everywhere. And it >> needs to degrade in a graceful way. >> > > The argument to the Windows Sleep() function is in milliseconds, so if > that's fine enough granularity for you then you can make a cross > platform millisecond sleep without much trouble. Alternatively, > people > sometimes use calls to select() to do sub second timings, but it's not > the best way to go. > > -Joseph > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From rrnewton at gmail.com Sat Apr 21 21:27:12 2007 From: rrnewton at gmail.com (Ryan Newton) Date: Sat, 21 Apr 2007 21:27:12 -0400 Subject: [Unison-hackers] Unix.sleep insufficient for -repeat! Need half seconds. In-Reply-To: <882DFBA1-F04B-44EE-BDF3-A7A4AB83E377@gmail.com> References: <882DFBA1-F04B-44EE-BDF3-A7A4AB83E377@gmail.com> Message-ID: <0C6B4756-0885-41CC-8E33-1EFFAFF32935@gmail.com> That couldn't have been easier. (Although it would be nice if Caml had a variant of "external" which would do the simple type conversions for you (for ints, floats, chars) -- then this wouldn't require C code at all!) The below works for MacOS (intel + ppc) and linux. If the powers that be are interested in this change, I can look into a solution that works for windows as well. -Ryan usleep.c: =============================================== #include #include value unison_usleep( value msecs ) { return Val_int( usleep( Int_val(msecs))); } uitext.ml: =============================================== (* Defined in usleep.c *) external usleep : int -> int = "unison_usleep" let rec synchronizeUntilDone () = let repeatinterval = if Prefs.read Uicommon.repeat = "" then -1.0 else try float_of_string (Prefs.read Uicommon.repeat) with Failure "float_of_string" -> (* If the 'repeat' pref is not a number, switch modes... *) synchronizePathsFromFilesystemWatcher() in let exitStatus = synchronizeUntilNoFailures() in if repeatinterval < 0.0 then exitStatus else begin (* Do it again *) Trace.status (Printf.sprintf "\nSleeping for %f seconds...\n" repeatinterval); let seconds = int_of_float repeatinterval in let millisec = (int_of_float (1000000. *. repeatinterval)) - (seconds * 1000000) in (* In some implementations usleep can only sleep up to 1 second. *) (if seconds > 0 then Unix.sleep seconds); (if millisec > 0 then let _ = usleep millisec in ()); synchronizeUntilDone () end On Apr 20, 2007, at 10:54 AM, Ryan Newton wrote: > Hello all, > > I use the -repeat option *extensively* to establish a relatively > low-bandwidth, poor man's distributed file system. Basically, if > my connection is good enough, I do development by running emacs > over X11 forwarding from the server. If it's not good enough, I > run emacs locally, use unison -repeat, and compile/run the program > on the server over a simple ssh terminal. From newton at mit.edu Sat Apr 21 21:42:32 2007 From: newton at mit.edu (Ryan Newton) Date: Sat, 21 Apr 2007 21:42:32 -0400 Subject: [Unison-hackers] Unix.sleep insufficient for -repeat! Need half seconds. In-Reply-To: <7F8293C6-F254-46D9-8CBC-2DE99FC7307D@cis.upenn.edu> References: <882DFBA1-F04B-44EE-BDF3-A7A4AB83E377@gmail.com> <78CAA5B9-DB02-4A30-96A9-ECAA6D67CA8F@cis.upenn.edu> <20070420165910.273ed4d7@porkrind> <7F8293C6-F254-46D9-8CBC-2DE99FC7307D@cis.upenn.edu> Message-ID: <98F961D0-8B99-4E58-8784-9000C6C8B2B2@csail.mit.edu> Sorry, the email that just went out from me was written a couple days ago but got stalled in my outbox. Thus it didn't take into account these more recent messages. It's good to hear that this change will fly in windows too. When I get a chance, I'll give this a try myself, or maybe someone will beat me to it. Ben: Actually, the tree I'm syncing has over a thousand files. Still, unison performs admirably. I see 8% cpu utilization at a one- second repeat, and 12% utilization with half-second repeat (opteron 250, 2.4 ghz). But, I agree, a watcher program would be nice. -Ryan On Apr 20, 2007, at 11:22 PM, Benjamin Pierce wrote: > Perfect. So this change should be pretty easy, then. > > Thanks, > > - B > > > On Apr 20, 2007, at 6:59 PM, Joseph Dunn wrote: > >> On Fri, 20 Apr 2007 11:54:33 -0400 >> Benjamin Pierce wrote: >> >>> I'd be very happy to see this change. Couple of thoughts: >>> >>> * One reason that usleep is not wrapped for OCaml might be (I don't >>> know) that Win32 doesn't offer something comparable. Whatever >>> solution is adopted here needs to at least compile cross-platform, >>> even if the full functionality isn't available everywhere. And it >>> needs to degrade in a graceful way. >>> >> >> The argument to the Windows Sleep() function is in milliseconds, >> so if >> that's fine enough granularity for you then you can make a cross >> platform millisecond sleep without much trouble. Alternatively, >> people >> sometimes use calls to select() to do sub second timings, but it's >> not >> the best way to go. >> >> -Joseph >> _______________________________________________ >> 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 Sat Apr 21 23:29:39 2007 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Sat, 21 Apr 2007 23:29:39 -0400 Subject: [Unison-hackers] Unix.sleep insufficient for -repeat! Need half seconds. In-Reply-To: <98F961D0-8B99-4E58-8784-9000C6C8B2B2@csail.mit.edu> References: <882DFBA1-F04B-44EE-BDF3-A7A4AB83E377@gmail.com> <78CAA5B9-DB02-4A30-96A9-ECAA6D67CA8F@cis.upenn.edu> <20070420165910.273ed4d7@porkrind> <7F8293C6-F254-46D9-8CBC-2DE99FC7307D@cis.upenn.edu> <98F961D0-8B99-4E58-8784-9000C6C8B2B2@csail.mit.edu> Message-ID: Yes, this should definitely be added to the main sources once it's working under Windows... - B On Apr 21, 2007, at 9:42 PM, Ryan Newton wrote: > Sorry, the email that just went out from me was written a couple days > ago but got stalled in my outbox. Thus it didn't take into account > these more recent messages. > > It's good to hear that this change will fly in windows too. When I > get a chance, I'll give this a try myself, or maybe someone will beat > me to it. > > Ben: Actually, the tree I'm syncing has over a thousand files. > Still, unison performs admirably. I see 8% cpu utilization at a one- > second repeat, and 12% utilization with half-second repeat (opteron > 250, 2.4 ghz). But, I agree, a watcher program would be nice. > > -Ryan > > > On Apr 20, 2007, at 11:22 PM, Benjamin Pierce wrote: > >> Perfect. So this change should be pretty easy, then. >> >> Thanks, >> >> - B >> >> >> On Apr 20, 2007, at 6:59 PM, Joseph Dunn wrote: >> >>> On Fri, 20 Apr 2007 11:54:33 -0400 >>> Benjamin Pierce wrote: >>> >>>> I'd be very happy to see this change. Couple of thoughts: >>>> >>>> * One reason that usleep is not wrapped for OCaml might be (I don't >>>> know) that Win32 doesn't offer something comparable. Whatever >>>> solution is adopted here needs to at least compile cross-platform, >>>> even if the full functionality isn't available everywhere. And it >>>> needs to degrade in a graceful way. >>>> >>> >>> The argument to the Windows Sleep() function is in milliseconds, >>> so if >>> that's fine enough granularity for you then you can make a cross >>> platform millisecond sleep without much trouble. Alternatively, >>> people >>> sometimes use calls to select() to do sub second timings, but it's >>> not >>> the best way to go. >>> >>> -Joseph >>> _______________________________________________ >>> 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 newton at mit.edu Mon Apr 30 16:51:29 2007 From: newton at mit.edu (Ryan Newton) Date: Mon, 30 Apr 2007 16:51:29 -0400 Subject: [Unison-hackers] Treat directory as atomic? Message-ID: <638F5EC8-10A0-46EF-8930-373A268FAD84@csail.mit.edu> It would be great to be able to add patterns to an "atomic" list. Something on the atomic list would be treated as a leaf of synchronization even if it is a directory. There are many examples of directories that should be treated atomically: for example, the fsfs database for my subversion repository. Or, on the Macintosh, by convention many "files" are represented by directories -- such as keynote presentations (.key). Any ideas? Apologies if I've missed some way to do this with the current options. If someone wise could give me a bit of high-level advice on how to implement this feature, I could maybe give it a shot. Cheers, -Ryan -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3795 bytes Desc: not available Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20070430/c265b2bb/smime-0001.p7s From newton at mit.edu Mon Apr 30 23:34:45 2007 From: newton at mit.edu (Ryan Newton) Date: Mon, 30 Apr 2007 23:34:45 -0400 Subject: [Unison-hackers] Treat directory as atomic? Message-ID: It would be great to be able to add patterns to an "atomic" list. Something on the atomic list would be treated as a leaf of synchronization even if it is a directory. There are many examples of directories that should be treated atomically: for example, the fsfs database for my subversion repository. Or, on the Macintosh, by convention many "files" are represented by directories -- such as keynote presentations (.key). Any ideas? Apologies if I've missed some way to do this with the current options. If someone wise could give me a bit of high-level advice on how to implement this feature, I could maybe give it a shot. Cheers, -Ryan