From bcpierce at cis.upenn.edu Mon Jan 1 17:49:59 2007 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Mon, 1 Jan 2007 17:49:59 -0500 Subject: [Unison-hackers] [unison-svn] r199 - in trunk: . doc src src/uimac Message-ID: <200701012249.l01Mnxag016861@canfield.cis.upenn.edu> Author: bcpierce Date: 2007-01-01 17:49:58 -0500 (Mon, 01 Jan 2007) New Revision: 199 Modified: trunk/Makefile trunk/doc/changes.tex trunk/src/RECENTNEWS trunk/src/abort.ml trunk/src/case.ml trunk/src/case.mli trunk/src/checksum.ml trunk/src/checksum.mli trunk/src/clroot.ml trunk/src/clroot.mli trunk/src/common.ml trunk/src/common.mli trunk/src/copy.ml trunk/src/fileinfo.ml trunk/src/fileinfo.mli trunk/src/files.mli trunk/src/fileutil.ml trunk/src/fileutil.mli trunk/src/fingerprint.ml trunk/src/fingerprint.mli trunk/src/fspath.ml trunk/src/fspath.mli trunk/src/globals.ml trunk/src/globals.mli trunk/src/linkgtk.ml trunk/src/linkgtk2.ml trunk/src/linktext.ml trunk/src/linktk.ml trunk/src/lock.ml trunk/src/lock.mli trunk/src/mkProjectInfo.ml trunk/src/uimac/Info.plist.template Log: * Incorporated yet another patch from Karl M (thanks!!) to improve the quoting of filenames in external merge commands under windows. (Also some small UI improvements to merging.) * Updated some more copyright years and deleted some $Id: strings I'd missed * Moved stuff from src/RECENTNEWS to doc/changes.tex in preparation for new release. From bcpierce at cis.upenn.edu Mon Jan 1 18:45:39 2007 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Mon, 1 Jan 2007 18:45:39 -0500 Subject: [Unison-hackers] [unison-svn] r200 - in trunk: doc src src/ubase Message-ID: <200701012345.l01NjdeD019534@canfield.cis.upenn.edu> Author: bcpierce Date: 2007-01-01 18:45:39 -0500 (Mon, 01 Jan 2007) New Revision: 200 Modified: trunk/doc/changes.tex trunk/doc/unison-manual.tex trunk/src/RECENTNEWS trunk/src/mkProjectInfo.ml trunk/src/recon.ml trunk/src/strings.ml trunk/src/ubase/prefs.ml trunk/src/ubase/uarg.ml Log: * Tidied documentation in preparation for new release. From bcpierce at cis.upenn.edu Mon Jan 1 18:49:18 2007 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Mon, 1 Jan 2007 18:49:18 -0500 Subject: [Unison-hackers] New release almost ready -- help needed with testing Message-ID: Dear Unison hackers, I'm pleased to announce that the Unison team is nearly ready to make a new beta-release. To ensure that the transition is as smooth as possible, I'd appreciate it if people could try out the current developer version and make sure it compiles in all the different configurations... If all goes well, I'll promote it to beta-release status in a few days. - Benjamin From kevin at sb.org Tue Jan 2 02:47:16 2007 From: kevin at sb.org (Kevin Ballard) Date: Tue, 2 Jan 2007 02:47:16 -0500 Subject: [Unison-hackers] New release almost ready -- help needed with testing In-Reply-To: References: Message-ID: Compiles fine on OS X, both GUI and TEXT (GUI untested, since I don't like using it, but it compiled with no problems). On Jan 1, 2007, at 6:49 PM, Benjamin Pierce wrote: > I'm pleased to announce that the Unison team is nearly ready to make > a new beta-release. To ensure that the transition is as smooth as > possible, I'd appreciate it if people could try out the current > developer version and make sure it compiles in all the different > configurations... > > If all goes well, I'll promote it to beta-release status in a few > days. -- Kevin Ballard http://kevin.sb.org kevin at sb.org http://www.tildesoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20070102/ec61b6a0/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2432 bytes Desc: not available Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20070102/ec61b6a0/smime.p7s From alan.schmitt at polytechnique.org Tue Jan 2 04:31:57 2007 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Tue, 2 Jan 2007 10:31:57 +0100 Subject: [Unison-hackers] New release almost ready -- help needed with testing In-Reply-To: References: Message-ID: On 2 janv. 07, at 00:49, Benjamin Pierce wrote: > Dear Unison hackers, > > I'm pleased to announce that the Unison team is nearly ready to make > a new beta-release. To ensure that the transition is as smooth as > possible, I'd appreciate it if people could try out the current > developer version and make sure it compiles in all the different > configurations... > > If all goes well, I'll promote it to beta-release status in a few > days. I've built it under: Gentoo i386, OS X i386 graphical, OS X PPC text, and it all worked. I've tried it and it seems to work. The GUI may have some responsiveness issues (even though Unison is propagating changes) but I'll have to further test this. One small bug: the change in the temporary names does not seem to be taken into account when detecting changes. I interrupted a sync and after restarting it, Unison proposed to synchronize some temporary files. 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: This is a digitally signed message part Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20070102/f4eb7cff/PGP.sig From zpetkovic at acm.org Fri Jan 5 03:33:10 2007 From: zpetkovic at acm.org (Zvezdan Petkovic) Date: Fri, 5 Jan 2007 03:33:10 -0500 Subject: [Unison-hackers] New release almost ready -- help needed with testing In-Reply-To: References: Message-ID: <20070105083310.GA11133@petkovic.homeip.net> On Mon, Jan 01, 2007 at 06:49:18PM -0500, Benjamin Pierce wrote: > I'm pleased to announce that the Unison team is nearly ready to make > a new beta-release. To ensure that the transition is as smooth as > possible, I'd appreciate it if people could try out the current > developer version and make sure it compiles in all the different > configurations... Two big disappointments: 1. The GTK 1 version does not build because the Makefiles have been changed. I can't build a package for OpenBSD without this because I have only lablgtk port available. Nobody made lablgtk2 port for OpenBSD, and last time I tried it was so much behind the gtk2 port (libraries) that it would not work. Since unison works fine with lablgtk I did not see the reason to pursue this further. Can we get GTK 1 back in the Makefiles? 2. The text version has created huge backup of all my files in .unison/backup although I do not have that preference set anywhere. Since when is this default? How can this be switched off? > > If all goes well, I'll promote it to beta-release status in a few days. This disables a default GUI package on OpenBSD. It has an unexpected default behavior of backup with no_x11 flavor of the package (text interface). Best regards, Zvezdan From bcpierce at cis.upenn.edu Fri Jan 5 08:10:58 2007 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Fri, 5 Jan 2007 08:10:58 -0500 Subject: [Unison-hackers] New release almost ready -- help needed with testing In-Reply-To: <20070105083310.GA11133@petkovic.homeip.net> References: <20070105083310.GA11133@petkovic.homeip.net> Message-ID: > Two big disappointments: > > 1. The GTK 1 version does not build because the Makefiles have > been changed. > I can't build a package for OpenBSD without this because I > have only lablgtk port available. > Nobody made lablgtk2 port for OpenBSD, and last time I tried > it was so much behind the gtk2 port (libraries) that it would > not work. Since unison works fine with lablgtk I did not see > the reason to pursue this further. > > Can we get GTK 1 back in the Makefiles? Of course. But I am not set up to build the GTK1 interface locally, so I'll need some help. (There have also been a few changes to the code that may possibly prevent it compiling if I got them wrong, but I hope these should be easy to fix.) > > 2. The text version has created huge backup of all my files in > .unison/backup although I do not have that preference set > anywhere. > > Since when is this default? > How can this be switched off? This is a bug: the default should be no backups. Can you please remove your ~/.unison/backup and send me a "-debug all" trace for some small part of your replica (using "-path XXX")? The behavior is supposed to be controlled by "backupcurrent", whose default is empty. - Benjamin > >> >> If all goes well, I'll promote it to beta-release status in a few >> days. > > This disables a default GUI package on OpenBSD. > It has an unexpected default behavior of backup with no_x11 flavor of > the package (text interface). > > Best regards, > > Zvezdan > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From alan.schmitt at polytechnique.org Sat Jan 6 02:57:03 2007 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Sat, 6 Jan 2007 08:57:03 +0100 Subject: [Unison-hackers] Issue with MAC OS build In-Reply-To: <459ED260.5080801@nativel.net> References: <459EA8C7.4070204@nativel.net> <2DF7F91E-62B9-4B8B-97BF-C34ECDBD884D@polytechnique.org> <459ED260.5080801@nativel.net> Message-ID: <6E474B10-AC46-459E-BFDD-E9961A85C645@polytechnique.org> I'm afraid it's a bit beyond my depth, I'm copying the Unison Hackers list. Alan On 5 janv. 07, at 23:34, Dany Nativel wrote: > Hi Alan, > > The server I'm running unison on (old Epia board based on VIA C3 > processor) doesn't support any cpu optimization above pentium (i586 > to be exact). > > I did as you suggested and got a working binary. Now during the > first sync with the MAC OS I get crashes. For information I added > the following two lines in my unison profile as suggested on unison > website : > ignore = Name .FBCIndex > ignore = Name .FBCLockFolder > > > > It's strange because the sync starts and fails in the middle with > the following trace (1) > > Then I added : > ignore = Name .DS_Store > ignore = Name ._.DS_Store > > and it worked a little bit better but still crashed (see trace (2)). > > > > > TRACE (1) > Date/Time: 2007-01-05 22:56:10.948 +0100 > OS Version: 10.4.8 (Build 8L2127) > Report Version: 4 > > Command: Unison > Path: /Users/dany/Desktop/Unison-2.26.13-X.4-i386.app/Contents/ > MacOS/Unison > Parent: WindowServer [60] > > Version: 2.26.13 (2.26.13) > > PID: 437 > Thread: 1 > > Exception: EXC_BAD_ACCESS (0x0001) > Codes: KERN_PROTECTION_FAILURE (0x0002) at 0xb001dffc > > Thread 0: > 0 libSystem.B.dylib 0x90024427 > semaphore_wait_signal_trap + 7 > 1 edu.upenn.cis.Unison 0x00002d5c Callback_checkexn + 19 > (main.m:32) > 2 edu.upenn.cis.Unison 0x0000709f -[ReconItem progress] + > 57 (ReconItem.m:217) > 3 com.apple.AppKit 0x933bf9fe -[NSTableView > _dataSourceValueForColumn:row:] + 70 > 4 com.apple.AppKit 0x933a6fc5 -[NSTableView > _drawContentsAtRow:column:clipRect:] + 346 > 5 com.apple.AppKit 0x933a602b -[NSTableView > drawRow:clipRect:] + 335 > 6 com.apple.AppKit 0x933a37ce -[NSTableView > drawRowIndexes:clipRect:] + 99 > 7 com.apple.AppKit 0x933a26a4 -[NSTableView > drawRect:] + 2499 > 8 com.apple.AppKit 0x932ce3b1 -[NSView > _drawRect:clip:] + 3228 > 9 com.apple.AppKit 0x932cd40b -[NSView > _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 614 > 10 com.apple.AppKit 0x932df36f > _recursiveDisplayInRect2 + 149 > 11 com.apple.CoreFoundation 0x9083af26 CFArrayApplyFunction + 307 > 12 com.apple.AppKit 0x932cd613 -[NSView > _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 1134 > 13 com.apple.AppKit 0x932df36f > _recursiveDisplayInRect2 + 149 > 14 com.apple.CoreFoundation 0x9083af26 CFArrayApplyFunction + 307 > 15 com.apple.AppKit 0x932cd613 -[NSView > _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 1134 > 16 com.apple.AppKit 0x932df36f > _recursiveDisplayInRect2 + 149 > 17 com.apple.CoreFoundation 0x9083af26 CFArrayApplyFunction + 307 > 18 com.apple.AppKit 0x932cd613 -[NSView > _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 1134 > 19 com.apple.AppKit 0x932cc473 -[NSView > _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisib > leRectForView:topView:] + 217 > 20 com.apple.AppKit 0x932cd041 -[NSView > _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisib > leRectForView:topView:] + 3239 > 21 com.apple.AppKit 0x932cbb78 -[NSThemeFrame > _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisib > leRectForView:topView:] + 290 > 22 com.apple.AppKit 0x932cb362 -[NSView > _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + > 523 > 23 com.apple.AppKit 0x932cac8e -[NSView > displayIfNeeded] + 439 > 24 com.apple.AppKit 0x932caa32 -[NSWindow > displayIfNeeded] + 168 > 25 com.apple.AppKit 0x9331ad6c > _handleWindowNeedsDisplay + 206 > 26 com.apple.CoreFoundation 0x9082a155 __CFRunLoopDoObservers > + 342 > 27 com.apple.CoreFoundation 0x908291f7 CFRunLoopRunSpecific + 827 > 28 com.apple.CoreFoundation 0x90828eb5 CFRunLoopRunInMode + 61 > 29 com.apple.HIToolbox 0x92dcdb90 > RunCurrentEventLoopInMode + 285 > 30 com.apple.HIToolbox 0x92dcd297 ReceiveNextEventCommon > + 385 > 31 com.apple.HIToolbox 0x92dcd0ee > BlockUntilNextEventMatchingListInMode + 81 > 32 com.apple.AppKit 0x9324f465 _DPSNextEvent + 572 > 33 com.apple.AppKit 0x9324f056 -[NSApplication > nextEventMatchingMask:untilDate:inMode:dequeue:] + 137 > 34 com.apple.AppKit 0x93248ddb -[NSApplication run] + 512 > 35 com.apple.AppKit 0x9323cd2f NSApplicationMain + 573 > 36 edu.upenn.cis.Unison 0x00002c52 _start + 216 > 37 edu.upenn.cis.Unison 0x00002b79 start + 41 > > Thread 1 Crashed: > 0 edu.upenn.cis.Unison 0x00086a87 compare_val + 9 > 1 edu.upenn.cis.Unison 0x000870e1 caml_compare + 39 > > Thread 1 crashed with X86 Thread State (32-bit): > eax: 0x00000001 ebx: 0x000870c7 ecx: 0x000fabac edx: 0xb001e080 > edi: 0x00000049 esi: 0x000f6eb0 ebp: 0xb001e058 esp: 0xb001e000 > ss: 0x0000001f efl: 0x00010286 eip: 0x00086a87 cs: 0x00000017 > ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037 > > Binary Images Description: > 0x1000 - 0x9cfff edu.upenn.cis.Unison 2.26.13 /Users/dany/ > Desktop/Unison-2.26.13-X.4-i386.app/Contents/MacOS/Unison > 0x3f3000 - 0x3f4fff com.ecamm.pluginloader Ecamm Plugin Loader > v1.0.4 (1.0.4) /Library/InputManagers/Ecamm/Ecamm Plugin > Loader.bundle/Contents/MacOS/Ecamm Plugin Loader > 0x8fe00000 - 0x8fe49fff dyld 46.9 /usr/lib/dyld > 0x90000000 - 0x9016ffff libSystem.B.dylib /usr/lib/ > libSystem.B.dylib > 0x901bf000 - 0x901c1fff libmathCommon.A.dylib /usr/lib/system/ > libmathCommon.A.dylib > 0x901c3000 - 0x901fffff com.apple.CoreText 1.1.1 (???) /System/ > Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/CoreText.framework/Versions/A/CoreText > 0x90226000 - 0x902fcfff ATS /System/Library/Frameworks/ > ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/ > Versions/A/ATS > 0x9031c000 - 0x90770fff com.apple.CoreGraphics 1.258.38 (???) / > System/Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics > 0x90807000 - 0x908cffff com.apple.CoreFoundation 6.4.6 (368.27) / > System/Library/Frameworks/CoreFoundation.framework/Versions/A/ > CoreFoundation > 0x9090d000 - 0x9090dfff com.apple.CoreServices 10.4 (???) / > System/Library/Frameworks/CoreServices.framework/Versions/A/ > CoreServices > 0x9090f000 - 0x90a02fff libicucore.A.dylib /usr/lib/ > libicucore.A.dylib > 0x90a52000 - 0x90ad1fff libobjc.A.dylib /usr/lib/libobjc.A.dylib > 0x90afa000 - 0x90b5efff libstdc++.6.dylib /usr/lib/libstdc++. > 6.dylib > 0x90bcd000 - 0x90bd4fff libgcc_s.1.dylib /usr/lib/libgcc_s.1.dylib > 0x90bd9000 - 0x90c4cfff com.apple.framework.IOKit 1.4.6 (???) / > System/Library/Frameworks/IOKit.framework/Versions/A/IOKit > 0x90c61000 - 0x90c73fff libauto.dylib /usr/lib/libauto.dylib > 0x90c79000 - 0x90f1ffff com.apple.CoreServices.CarbonCore > 682.15 /System/Library/Frameworks/CoreServices.framework/ > Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore > 0x90f62000 - 0x90fcafff com.apple.CoreServices.OSServices 4.1 / > System/Library/Frameworks/CoreServices.framework/Versions/A/ > Frameworks/OSServices.framework/Versions/A/OSServices > 0x91002000 - 0x91040fff com.apple.CFNetwork 129.19 /System/ > Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/ > CFNetwork.framework/Versions/A/CFNetwork > 0x91053000 - 0x91063fff com.apple.WebServices 1.1.3 (1.1.0) / > System/Library/Frameworks/CoreServices.framework/Versions/A/ > Frameworks/WebServicesCore.framework/Versions/A/WebServicesCore > 0x9106e000 - 0x910ecfff com.apple.SearchKit 1.0.5 /System/ > Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/ > SearchKit.framework/Versions/A/SearchKit > 0x91121000 - 0x9113ffff com.apple.Metadata 10.4.4 (121.36) / > System/Library/Frameworks/CoreServices.framework/Versions/A/ > Frameworks/Metadata.framework/Versions/A/Metadata > 0x9114b000 - 0x91159fff libz.1.dylib /usr/lib/libz.1.dylib > 0x9115c000 - 0x912fbfff com.apple.security 4.5.2 (29774) /System/ > Library/Frameworks/Security.framework/Versions/A/Security > 0x913f9000 - 0x91401fff com.apple.DiskArbitration 2.1.1 /System/ > Library/Frameworks/DiskArbitration.framework/Versions/A/ > DiskArbitration > 0x91408000 - 0x9142efff com.apple.SystemConfiguration 1.8.6 / > System/Library/Frameworks/SystemConfiguration.framework/Versions/A/ > SystemConfiguration > 0x91440000 - 0x91447fff libbsm.dylib /usr/lib/libbsm.dylib > 0x9144b000 - 0x914c4fff com.apple.audio.CoreAudio 3.0.4 /System/ > Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio > 0x91512000 - 0x91512fff com.apple.ApplicationServices 10.4 > (???) /System/Library/Frameworks/ApplicationServices.framework/ > Versions/A/ApplicationServices > 0x91514000 - 0x9153ffff com.apple.AE 314 (313) /System/Library/ > Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ > AE.framework/Versions/A/AE > 0x91552000 - 0x91626fff com.apple.ColorSync 4.4.8 /System/ > Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/ColorSync.framework/Versions/A/ColorSync > 0x91661000 - 0x916defff com.apple.print.framework.PrintCore 4.6 > (177.13) /System/Library/Frameworks/ > ApplicationServices.framework/Versions/A/Frameworks/ > PrintCore.framework/Versions/A/PrintCore > 0x9170b000 - 0x917b4fff com.apple.QD 3.10.21 (???) /System/ > Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/QD.framework/Versions/A/QD > 0x917da000 - 0x91825fff com.apple.HIServices 1.5.2 (???) /System/ > Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/HIServices.framework/Versions/A/HIServices > 0x91844000 - 0x9185afff com.apple.LangAnalysis 1.6.3 /System/ > Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis > 0x91866000 - 0x91880fff com.apple.FindByContent 1.5 /System/ > Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/FindByContent.framework/Versions/A/FindByContent > 0x9188a000 - 0x918c7fff com.apple.LaunchServices 181 /System/ > Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/LaunchServices.framework/Versions/A/LaunchServices > 0x918db000 - 0x918e7fff com.apple.speech.synthesis.framework > 3.5 /System/Library/Frameworks/ApplicationServices.framework/ > Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/ > SpeechSynthesis > 0x918ee000 - 0x91929fff com.apple.ImageIO.framework 1.5.0 / > System/Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/ImageIO.framework/Versions/A/ImageIO > 0x9193b000 - 0x919edfff libcrypto.0.9.7.dylib /usr/lib/ > libcrypto.0.9.7.dylib > 0x91a33000 - 0x91a49fff libcups.2.dylib /usr/lib/libcups.2.dylib > 0x91a4e000 - 0x91a6cfff libJPEG.dylib /System/Library/ > Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ > ImageIO.framework/Versions/A/Resources/libJPEG.dylib > 0x91a71000 - 0x91acffff libJP2.dylib /System/Library/Frameworks/ > ApplicationServices.framework/Versions/A/Frameworks/ > ImageIO.framework/Versions/A/Resources/libJP2.dylib > 0x91ae1000 - 0x91ae5fff libGIF.dylib /System/Library/Frameworks/ > ApplicationServices.framework/Versions/A/Frameworks/ > ImageIO.framework/Versions/A/Resources/libGIF.dylib > 0x91ae7000 - 0x91b64fff libRaw.dylib /System/Library/Frameworks/ > ApplicationServices.framework/Versions/A/Frameworks/ > ImageIO.framework/Versions/A/Resources/libRaw.dylib > 0x91b68000 - 0x91ba5fff libTIFF.dylib /System/Library/ > Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ > ImageIO.framework/Versions/A/Resources/libTIFF.dylib > 0x91bab000 - 0x91bc5fff libPng.dylib /System/Library/Frameworks/ > ApplicationServices.framework/Versions/A/Frameworks/ > ImageIO.framework/Versions/A/Resources/libPng.dylib > 0x91bca000 - 0x91bccfff libRadiance.dylib /System/Library/ > Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ > ImageIO.framework/Versions/A/Resources/libRadiance.dylib > 0x91bce000 - 0x91bcefff com.apple.Accelerate 1.3.1 (Accelerate > 1.3.1) /System/Library/Frameworks/Accelerate.framework/Versions/ > A/Accelerate > 0x91bd0000 - 0x91c5efff com.apple.vImage 2.5 /System/Library/ > Frameworks/Accelerate.framework/Versions/A/Frameworks/ > vImage.framework/Versions/A/vImage > 0x91c65000 - 0x91c65fff com.apple.Accelerate.vecLib 3.3.1 (vecLib > 3.3.1) /System/Library/Frameworks/Accelerate.framework/Versions/ > A/Frameworks/vecLib.framework/Versions/A/vecLib > 0x91c67000 - 0x91cc0fff libvMisc.dylib /System/Library/ > Frameworks/Accelerate.framework/Versions/A/Frameworks/ > vecLib.framework/Versions/A/libvMisc.dylib > 0x91cc9000 - 0x91cedfff libvDSP.dylib /System/Library/ > Frameworks/Accelerate.framework/Versions/A/Frameworks/ > vecLib.framework/Versions/A/libvDSP.dylib > 0x91cf5000 - 0x920fefff libBLAS.dylib /System/Library/ > Frameworks/Accelerate.framework/Versions/A/Frameworks/ > vecLib.framework/Versions/A/libBLAS.dylib > 0x92138000 - 0x924ecfff libLAPACK.dylib /System/Library/ > Frameworks/Accelerate.framework/Versions/A/Frameworks/ > vecLib.framework/Versions/A/libLAPACK.dylib > 0x92519000 - 0x92597fff com.apple.DesktopServices 1.3.5 /System/ > Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/ > DesktopServicesPriv > 0x925d8000 - 0x92808fff com.apple.Foundation 6.4.7 (567.28) / > System/Library/Frameworks/Foundation.framework/Versions/C/Foundation > 0x92914000 - 0x929f2fff libxml2.2.dylib /usr/lib/libxml2.2.dylib > 0x92a0f000 - 0x92afcfff libiconv.2.dylib /usr/lib/libiconv.2.dylib > 0x92b0c000 - 0x92b23fff libGL.dylib /System/Library/Frameworks/ > OpenGL.framework/Versions/A/Libraries/libGL.dylib > 0x92b2e000 - 0x92b86fff libGLU.dylib /System/Library/Frameworks/ > OpenGL.framework/Versions/A/Libraries/libGLU.dylib > 0x92b9a000 - 0x92b9afff com.apple.Carbon 10.4 (???) /System/ > Library/Frameworks/Carbon.framework/Versions/A/Carbon > 0x92b9c000 - 0x92bacfff com.apple.ImageCapture 3.0.4 /System/ > Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ > ImageCapture.framework/Versions/A/ImageCapture > 0x92bba000 - 0x92bc2fff com.apple.speech.recognition.framework > 3.6 /System/Library/Frameworks/Carbon.framework/Versions/A/ > Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition > 0x92bc8000 - 0x92bcdfff com.apple.securityhi 2.0.1 (24742) / > System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ > SecurityHI.framework/Versions/A/SecurityHI > 0x92bd3000 - 0x92c64fff com.apple.ink.framework 101.2.1 (71) / > System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ > Ink.framework/Versions/A/Ink > 0x92c78000 - 0x92c7bfff com.apple.help 1.0.3 (32.1) /System/ > Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ > Help.framework/Versions/A/Help > 0x92c7e000 - 0x92c9bfff com.apple.openscripting 1.2.5 (???) / > System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ > OpenScripting.framework/Versions/A/OpenScripting > 0x92cab000 - 0x92cb1fff com.apple.print.framework.Print 5.1 > (192.3) /System/Library/Frameworks/Carbon.framework/Versions/A/ > Frameworks/Print.framework/Versions/A/Print > 0x92cb7000 - 0x92d1afff com.apple.htmlrendering 66.1 (1.1.3) / > System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ > HTMLRendering.framework/Versions/A/HTMLRendering > 0x92d3e000 - 0x92d7ffff com.apple.NavigationServices 3.4.4 > (3.4.3) /System/Library/Frameworks/Carbon.framework/Versions/A/ > Frameworks/NavigationServices.framework/Versions/A/NavigationServices > 0x92da6000 - 0x92db3fff com.apple.audio.SoundManager 3.9.1 / > System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ > CarbonSound.framework/Versions/A/CarbonSound > 0x92dba000 - 0x92dbffff com.apple.CommonPanels 1.2.3 (73) / > System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ > CommonPanels.framework/Versions/A/CommonPanels > 0x92dc4000 - 0x930b6fff com.apple.HIToolbox 1.4.8 (???) /System/ > Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ > HIToolbox.framework/Versions/A/HIToolbox > 0x931bb000 - 0x931c6fff com.apple.opengl 1.4.12 /System/Library/ > Frameworks/OpenGL.framework/Versions/A/OpenGL > 0x93236000 - 0x93236fff com.apple.Cocoa 6.4 (???) /System/ > Library/Frameworks/Cocoa.framework/Versions/A/Cocoa > 0x93238000 - 0x938eefff com.apple.AppKit 6.4.8 (824.42) /System/ > Library/Frameworks/AppKit.framework/Versions/C/AppKit > 0x93c6f000 - 0x93ce9fff com.apple.CoreData 90 /System/Library/ > Frameworks/CoreData.framework/Versions/A/CoreData > 0x93d22000 - 0x93de3fff com.apple.audio.toolbox.AudioToolbox > 1.4.3 /System/Library/Frameworks/AudioToolbox.framework/Versions/ > A/AudioToolbox > 0x93e23000 - 0x93e23fff com.apple.audio.units.AudioUnit 1.4.2 / > System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit > 0x93e25000 - 0x93ff7fff com.apple.QuartzCore 1.4.9 /System/ > Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore > 0x94048000 - 0x94089fff libsqlite3.0.dylib /usr/lib/ > libsqlite3.0.dylib > 0x94091000 - 0x940cbfff libGLImage.dylib /System/Library/ > Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib > 0x94251000 - 0x94260fff libCGATS.A.dylib /System/Library/ > Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ > CoreGraphics.framework/Versions/A/Resources/libCGATS.A.dylib > 0x94267000 - 0x94272fff libCSync.A.dylib /System/Library/ > Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ > CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib > 0x942be000 - 0x942d8fff libRIP.A.dylib /System/Library/ > Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ > CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib > 0xc0000000 - 0xc0008fff com.growl.growlframework 0.7.3 /Users/ > dany/Desktop/Unison-2.26.13-X.4-i386.app/Contents/Frameworks/ > Growl.framework/Versions/A/Growl > > Model: iMac4,1, BootROM IM41.0055.B08, 2 processors, Intel Core > Duo, 2 GHz, 2 GB > Graphics: ATI Radeon X1600, ATY,RadeonX1600, PCIe, 128 MB > Memory Module: BANK 0/DIMM0, 1 GB, DDR2 SDRAM, 667 MHz > Memory Module: BANK 1/DIMM1, 1 GB, DDR2 SDRAM, 667 MHz > AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, > 0x89), 4.80.46.0 > Bluetooth: Version 1.7.9f12, 2 service, 1 devices, 1 incoming > serial ports > Network Service: Ethernet int?gr?, Ethernet, en0 > Serial ATA Device: Maxtor 6L250M0, 233.76 GB > Parallel ATA Device: PIONEER DVD-RW DVR-K05 > USB Device: USB Embedded Hub, Prolific Technology Inc., Up to 480 > Mb/sec, 500 mA > USB Device: USB Mass Storage Device, Prolific Technology Inc., Up > to 480 Mb/sec, 500 mA > USB Device: Built-in iSight, Micron, Up to 480 Mb/sec, 500 mA > USB Device: i960, Canon, Up to 480 Mb/sec, 500 mA > USB Device: CTE-640-U V4.0-3, WACOM, Up to 1.5 Mb/sec, 500 mA > USB Device: Bluetooth HCI, Up to 12 Mb/sec, 500 mA > USB Device: IR Receiver, Apple Computer, Inc., Up to 12 Mb/sec, 500 mA > > > TRACE (2) > Date/Time: 2007-01-05 23:31:38.663 +0100 > OS Version: 10.4.8 (Build 8L2127) > Report Version: 4 > > Command: Unison > Path: /Users/dany/Desktop/Unison-2.26.13-X.4-i386.app/Contents/ > MacOS/Unison > Parent: WindowServer [60] > > Version: 2.26.13 (2.26.13) > > PID: 1824 > Thread: 0 > > Exception: EXC_BAD_ACCESS (0x0001) > Codes: KERN_INVALID_ADDRESS (0x0001) at 0x813321aa > > Thread 0 Crashed: > 0 edu.upenn.cis.Unison 0x0000cb0b > camlUimacbridge__unisonRiToProgress_282 + 11 > 1 edu.upenn.cis.Unison 0x0000709f -[ReconItem progress] + > 57 (ReconItem.m:217) > 2 com.apple.AppKit 0x933bf9fe -[NSTableView > _dataSourceValueForColumn:row:] + 70 > 3 com.apple.AppKit 0x933a6fc5 -[NSTableView > _drawContentsAtRow:column:clipRect:] + 346 > 4 com.apple.AppKit 0x933a602b -[NSTableView > drawRow:clipRect:] + 335 > 5 com.apple.AppKit 0x933a37ce -[NSTableView > drawRowIndexes:clipRect:] + 99 > 6 com.apple.AppKit 0x933a26a4 -[NSTableView > drawRect:] + 2499 > 7 com.apple.AppKit 0x932ce3b1 -[NSView > _drawRect:clip:] + 3228 > 8 com.apple.AppKit 0x932cd40b -[NSView > _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 614 > 9 com.apple.AppKit 0x932df36f > _recursiveDisplayInRect2 + 149 > 10 com.apple.CoreFoundation 0x9083af26 CFArrayApplyFunction + 307 > 11 com.apple.AppKit 0x932cd613 -[NSView > _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 1134 > 12 com.apple.AppKit 0x932df36f > _recursiveDisplayInRect2 + 149 > 13 com.apple.CoreFoundation 0x9083af26 CFArrayApplyFunction + 307 > 14 com.apple.AppKit 0x932cd613 -[NSView > _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 1134 > 15 com.apple.AppKit 0x932df36f > _recursiveDisplayInRect2 + 149 > 16 com.apple.CoreFoundation 0x9083af26 CFArrayApplyFunction + 307 > 17 com.apple.AppKit 0x932cd613 -[NSView > _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 1134 > 18 com.apple.AppKit 0x932cc473 -[NSView > _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisib > leRectForView:topView:] + 217 > 19 com.apple.AppKit 0x932cd041 -[NSView > _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisib > leRectForView:topView:] + 3239 > 20 com.apple.AppKit 0x932cbb78 -[NSThemeFrame > _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisib > leRectForView:topView:] + 290 > 21 com.apple.AppKit 0x932cb362 -[NSView > _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + > 523 > 22 com.apple.AppKit 0x932cac8e -[NSView > displayIfNeeded] + 439 > 23 com.apple.AppKit 0x932caa32 -[NSWindow > displayIfNeeded] + 168 > 24 com.apple.AppKit 0x9331ad6c > _handleWindowNeedsDisplay + 206 > 25 com.apple.CoreFoundation 0x9082a155 __CFRunLoopDoObservers > + 342 > 26 com.apple.CoreFoundation 0x908291f7 CFRunLoopRunSpecific + 827 > 27 com.apple.CoreFoundation 0x90828eb5 CFRunLoopRunInMode + 61 > 28 com.apple.HIToolbox 0x92dcdb90 > RunCurrentEventLoopInMode + 285 > 29 com.apple.HIToolbox 0x92dcd297 ReceiveNextEventCommon > + 385 > 30 com.apple.HIToolbox 0x92dcd0ee > BlockUntilNextEventMatchingListInMode + 81 > 31 com.apple.AppKit 0x9324f465 _DPSNextEvent + 572 > 32 com.apple.AppKit 0x9324f056 -[NSApplication > nextEventMatchingMask:untilDate:inMode:dequeue:] + 137 > 33 com.apple.AppKit 0x93248ddb -[NSApplication run] + 512 > 34 com.apple.AppKit 0x9323cd2f NSApplicationMain + 573 > 35 edu.upenn.cis.Unison 0x00002c52 _start + 216 > 36 edu.upenn.cis.Unison 0x00002b79 start + 41 > > Thread 0 crashed with X86 Thread State (32-bit): > eax: 0x813321a6 ebx: 0xb960a5f4 ecx: 0x0009d024 edx: 0x03992a2b > edi: 0x00000000 esi: 0x0000cb00 ebp: 0xbfffdb68 esp: 0xbfffdb10 > ss: 0x0000001f efl: 0x00010282 eip: 0x0000cb0b cs: 0x00000017 > ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037 > > Binary Images Description: > 0x1000 - 0x9cfff edu.upenn.cis.Unison 2.26.13 /Users/dany/ > Desktop/Unison-2.26.13-X.4-i386.app/Contents/MacOS/Unison > 0x3f3000 - 0x3f4fff com.ecamm.pluginloader Ecamm Plugin Loader > v1.0.4 (1.0.4) /Library/InputManagers/Ecamm/Ecamm Plugin > Loader.bundle/Contents/MacOS/Ecamm Plugin Loader > 0x8fe00000 - 0x8fe49fff dyld 46.9 /usr/lib/dyld > 0x90000000 - 0x9016ffff libSystem.B.dylib /usr/lib/ > libSystem.B.dylib > 0x901bf000 - 0x901c1fff libmathCommon.A.dylib /usr/lib/system/ > libmathCommon.A.dylib > 0x901c3000 - 0x901fffff com.apple.CoreText 1.1.1 (???) /System/ > Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/CoreText.framework/Versions/A/CoreText > 0x90226000 - 0x902fcfff ATS /System/Library/Frameworks/ > ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/ > Versions/A/ATS > 0x9031c000 - 0x90770fff com.apple.CoreGraphics 1.258.38 (???) / > System/Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics > 0x90807000 - 0x908cffff com.apple.CoreFoundation 6.4.6 (368.27) / > System/Library/Frameworks/CoreFoundation.framework/Versions/A/ > CoreFoundation > 0x9090d000 - 0x9090dfff com.apple.CoreServices 10.4 (???) / > System/Library/Frameworks/CoreServices.framework/Versions/A/ > CoreServices > 0x9090f000 - 0x90a02fff libicucore.A.dylib /usr/lib/ > libicucore.A.dylib > 0x90a52000 - 0x90ad1fff libobjc.A.dylib /usr/lib/libobjc.A.dylib > 0x90afa000 - 0x90b5efff libstdc++.6.dylib /usr/lib/libstdc++. > 6.dylib > 0x90bcd000 - 0x90bd4fff libgcc_s.1.dylib /usr/lib/libgcc_s.1.dylib > 0x90bd9000 - 0x90c4cfff com.apple.framework.IOKit 1.4.6 (???) / > System/Library/Frameworks/IOKit.framework/Versions/A/IOKit > 0x90c61000 - 0x90c73fff libauto.dylib /usr/lib/libauto.dylib > 0x90c79000 - 0x90f1ffff com.apple.CoreServices.CarbonCore > 682.15 /System/Library/Frameworks/CoreServices.framework/ > Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore > 0x90f62000 - 0x90fcafff com.apple.CoreServices.OSServices 4.1 / > System/Library/Frameworks/CoreServices.framework/Versions/A/ > Frameworks/OSServices.framework/Versions/A/OSServices > 0x91002000 - 0x91040fff com.apple.CFNetwork 129.19 /System/ > Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/ > CFNetwork.framework/Versions/A/CFNetwork > 0x91053000 - 0x91063fff com.apple.WebServices 1.1.3 (1.1.0) / > System/Library/Frameworks/CoreServices.framework/Versions/A/ > Frameworks/WebServicesCore.framework/Versions/A/WebServicesCore > 0x9106e000 - 0x910ecfff com.apple.SearchKit 1.0.5 /System/ > Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/ > SearchKit.framework/Versions/A/SearchKit > 0x91121000 - 0x9113ffff com.apple.Metadata 10.4.4 (121.36) / > System/Library/Frameworks/CoreServices.framework/Versions/A/ > Frameworks/Metadata.framework/Versions/A/Metadata > 0x9114b000 - 0x91159fff libz.1.dylib /usr/lib/libz.1.dylib > 0x9115c000 - 0x912fbfff com.apple.security 4.5.2 (29774) /System/ > Library/Frameworks/Security.framework/Versions/A/Security > 0x913f9000 - 0x91401fff com.apple.DiskArbitration 2.1.1 /System/ > Library/Frameworks/DiskArbitration.framework/Versions/A/ > DiskArbitration > 0x91408000 - 0x9142efff com.apple.SystemConfiguration 1.8.6 / > System/Library/Frameworks/SystemConfiguration.framework/Versions/A/ > SystemConfiguration > 0x91440000 - 0x91447fff libbsm.dylib /usr/lib/libbsm.dylib > 0x9144b000 - 0x914c4fff com.apple.audio.CoreAudio 3.0.4 /System/ > Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio > 0x91512000 - 0x91512fff com.apple.ApplicationServices 10.4 > (???) /System/Library/Frameworks/ApplicationServices.framework/ > Versions/A/ApplicationServices > 0x91514000 - 0x9153ffff com.apple.AE 314 (313) /System/Library/ > Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ > AE.framework/Versions/A/AE > 0x91552000 - 0x91626fff com.apple.ColorSync 4.4.8 /System/ > Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/ColorSync.framework/Versions/A/ColorSync > 0x91661000 - 0x916defff com.apple.print.framework.PrintCore 4.6 > (177.13) /System/Library/Frameworks/ > ApplicationServices.framework/Versions/A/Frameworks/ > PrintCore.framework/Versions/A/PrintCore > 0x9170b000 - 0x917b4fff com.apple.QD 3.10.21 (???) /System/ > Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/QD.framework/Versions/A/QD > 0x917da000 - 0x91825fff com.apple.HIServices 1.5.2 (???) /System/ > Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/HIServices.framework/Versions/A/HIServices > 0x91844000 - 0x9185afff com.apple.LangAnalysis 1.6.3 /System/ > Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis > 0x91866000 - 0x91880fff com.apple.FindByContent 1.5 /System/ > Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/FindByContent.framework/Versions/A/FindByContent > 0x9188a000 - 0x918c7fff com.apple.LaunchServices 181 /System/ > Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/LaunchServices.framework/Versions/A/LaunchServices > 0x918db000 - 0x918e7fff com.apple.speech.synthesis.framework > 3.5 /System/Library/Frameworks/ApplicationServices.framework/ > Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/ > SpeechSynthesis > 0x918ee000 - 0x91929fff com.apple.ImageIO.framework 1.5.0 / > System/Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/ImageIO.framework/Versions/A/ImageIO > 0x9193b000 - 0x919edfff libcrypto.0.9.7.dylib /usr/lib/ > libcrypto.0.9.7.dylib > 0x91a33000 - 0x91a49fff libcups.2.dylib /usr/lib/libcups.2.dylib > 0x91a4e000 - 0x91a6cfff libJPEG.dylib /System/Library/ > Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ > ImageIO.framework/Versions/A/Resources/libJPEG.dylib > 0x91a71000 - 0x91acffff libJP2.dylib /System/Library/Frameworks/ > ApplicationServices.framework/Versions/A/Frameworks/ > ImageIO.framework/Versions/A/Resources/libJP2.dylib > 0x91ae1000 - 0x91ae5fff libGIF.dylib /System/Library/Frameworks/ > ApplicationServices.framework/Versions/A/Frameworks/ > ImageIO.framework/Versions/A/Resources/libGIF.dylib > 0x91ae7000 - 0x91b64fff libRaw.dylib /System/Library/Frameworks/ > ApplicationServices.framework/Versions/A/Frameworks/ > ImageIO.framework/Versions/A/Resources/libRaw.dylib > 0x91b68000 - 0x91ba5fff libTIFF.dylib /System/Library/ > Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ > ImageIO.framework/Versions/A/Resources/libTIFF.dylib > 0x91bab000 - 0x91bc5fff libPng.dylib /System/Library/Frameworks/ > ApplicationServices.framework/Versions/A/Frameworks/ > ImageIO.framework/Versions/A/Resources/libPng.dylib > 0x91bca000 - 0x91bccfff libRadiance.dylib /System/Library/ > Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ > ImageIO.framework/Versions/A/Resources/libRadiance.dylib > 0x91bce000 - 0x91bcefff com.apple.Accelerate 1.3.1 (Accelerate > 1.3.1) /System/Library/Frameworks/Accelerate.framework/Versions/ > A/Accelerate > 0x91bd0000 - 0x91c5efff com.apple.vImage 2.5 /System/Library/ > Frameworks/Accelerate.framework/Versions/A/Frameworks/ > vImage.framework/Versions/A/vImage > 0x91c65000 - 0x91c65fff com.apple.Accelerate.vecLib 3.3.1 (vecLib > 3.3.1) /System/Library/Frameworks/Accelerate.framework/Versions/ > A/Frameworks/vecLib.framework/Versions/A/vecLib > 0x91c67000 - 0x91cc0fff libvMisc.dylib /System/Library/ > Frameworks/Accelerate.framework/Versions/A/Frameworks/ > vecLib.framework/Versions/A/libvMisc.dylib > 0x91cc9000 - 0x91cedfff libvDSP.dylib /System/Library/ > Frameworks/Accelerate.framework/Versions/A/Frameworks/ > vecLib.framework/Versions/A/libvDSP.dylib > 0x91cf5000 - 0x920fefff libBLAS.dylib /System/Library/ > Frameworks/Accelerate.framework/Versions/A/Frameworks/ > vecLib.framework/Versions/A/libBLAS.dylib > 0x92138000 - 0x924ecfff libLAPACK.dylib /System/Library/ > Frameworks/Accelerate.framework/Versions/A/Frameworks/ > vecLib.framework/Versions/A/libLAPACK.dylib > 0x92519000 - 0x92597fff com.apple.DesktopServices 1.3.5 /System/ > Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/ > DesktopServicesPriv > 0x925d8000 - 0x92808fff com.apple.Foundation 6.4.7 (567.28) / > System/Library/Frameworks/Foundation.framework/Versions/C/Foundation > 0x92914000 - 0x929f2fff libxml2.2.dylib /usr/lib/libxml2.2.dylib > 0x92a0f000 - 0x92afcfff libiconv.2.dylib /usr/lib/libiconv.2.dylib > 0x92b0c000 - 0x92b23fff libGL.dylib /System/Library/Frameworks/ > OpenGL.framework/Versions/A/Libraries/libGL.dylib > 0x92b2e000 - 0x92b86fff libGLU.dylib /System/Library/Frameworks/ > OpenGL.framework/Versions/A/Libraries/libGLU.dylib > 0x92b9a000 - 0x92b9afff com.apple.Carbon 10.4 (???) /System/ > Library/Frameworks/Carbon.framework/Versions/A/Carbon > 0x92b9c000 - 0x92bacfff com.apple.ImageCapture 3.0.4 /System/ > Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ > ImageCapture.framework/Versions/A/ImageCapture > 0x92bba000 - 0x92bc2fff com.apple.speech.recognition.framework > 3.6 /System/Library/Frameworks/Carbon.framework/Versions/A/ > Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition > 0x92bc8000 - 0x92bcdfff com.apple.securityhi 2.0.1 (24742) / > System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ > SecurityHI.framework/Versions/A/SecurityHI > 0x92bd3000 - 0x92c64fff com.apple.ink.framework 101.2.1 (71) / > System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ > Ink.framework/Versions/A/Ink > 0x92c78000 - 0x92c7bfff com.apple.help 1.0.3 (32.1) /System/ > Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ > Help.framework/Versions/A/Help > 0x92c7e000 - 0x92c9bfff com.apple.openscripting 1.2.5 (???) / > System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ > OpenScripting.framework/Versions/A/OpenScripting > 0x92cab000 - 0x92cb1fff com.apple.print.framework.Print 5.1 > (192.3) /System/Library/Frameworks/Carbon.framework/Versions/A/ > Frameworks/Print.framework/Versions/A/Print > 0x92cb7000 - 0x92d1afff com.apple.htmlrendering 66.1 (1.1.3) / > System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ > HTMLRendering.framework/Versions/A/HTMLRendering > 0x92d3e000 - 0x92d7ffff com.apple.NavigationServices 3.4.4 > (3.4.3) /System/Library/Frameworks/Carbon.framework/Versions/A/ > Frameworks/NavigationServices.framework/Versions/A/NavigationServices > 0x92da6000 - 0x92db3fff com.apple.audio.SoundManager 3.9.1 / > System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ > CarbonSound.framework/Versions/A/CarbonSound > 0x92dba000 - 0x92dbffff com.apple.CommonPanels 1.2.3 (73) / > System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ > CommonPanels.framework/Versions/A/CommonPanels > 0x92dc4000 - 0x930b6fff com.apple.HIToolbox 1.4.8 (???) /System/ > Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ > HIToolbox.framework/Versions/A/HIToolbox > 0x931bb000 - 0x931c6fff com.apple.opengl 1.4.12 /System/Library/ > Frameworks/OpenGL.framework/Versions/A/OpenGL > 0x93236000 - 0x93236fff com.apple.Cocoa 6.4 (???) /System/ > Library/Frameworks/Cocoa.framework/Versions/A/Cocoa > 0x93238000 - 0x938eefff com.apple.AppKit 6.4.8 (824.42) /System/ > Library/Frameworks/AppKit.framework/Versions/C/AppKit > 0x93c6f000 - 0x93ce9fff com.apple.CoreData 90 /System/Library/ > Frameworks/CoreData.framework/Versions/A/CoreData > 0x93d22000 - 0x93de3fff com.apple.audio.toolbox.AudioToolbox > 1.4.3 /System/Library/Frameworks/AudioToolbox.framework/Versions/ > A/AudioToolbox > 0x93e23000 - 0x93e23fff com.apple.audio.units.AudioUnit 1.4.2 / > System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit > 0x93e25000 - 0x93ff7fff com.apple.QuartzCore 1.4.9 /System/ > Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore > 0x94048000 - 0x94089fff libsqlite3.0.dylib /usr/lib/ > libsqlite3.0.dylib > 0x94091000 - 0x940cbfff libGLImage.dylib /System/Library/ > Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib > 0x94251000 - 0x94260fff libCGATS.A.dylib /System/Library/ > Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ > CoreGraphics.framework/Versions/A/Resources/libCGATS.A.dylib > 0x94267000 - 0x94272fff libCSync.A.dylib /System/Library/ > Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ > CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib > 0x942be000 - 0x942d8fff libRIP.A.dylib /System/Library/ > Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ > CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib > 0xc0000000 - 0xc0008fff com.growl.growlframework 0.7.3 /Users/ > dany/Desktop/Unison-2.26.13-X.4-i386.app/Contents/Frameworks/ > Growl.framework/Versions/A/Growl > > Model: iMac4,1, BootROM IM41.0055.B08, 2 processors, Intel Core > Duo, 2 GHz, 2 GB > Graphics: ATI Radeon X1600, ATY,RadeonX1600, PCIe, 128 MB > Memory Module: BANK 0/DIMM0, 1 GB, DDR2 SDRAM, 667 MHz > Memory Module: BANK 1/DIMM1, 1 GB, DDR2 SDRAM, 667 MHz > AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, > 0x89), 4.80.46.0 > Bluetooth: Version 1.7.9f12, 2 service, 1 devices, 1 incoming > serial ports > Network Service: Ethernet int?gr?, Ethernet, en0 > Serial ATA Device: Maxtor 6L250M0, 233.76 GB > Parallel ATA Device: PIONEER DVD-RW DVR-K05 > USB Device: USB Embedded Hub, Prolific Technology Inc., Up to 480 > Mb/sec, 500 mA > USB Device: USB Mass Storage Device, Prolific Technology Inc., Up > to 480 Mb/sec, 500 mA > USB Device: Built-in iSight, Micron, Up to 480 Mb/sec, 500 mA > USB Device: i960, Canon, Up to 480 Mb/sec, 500 mA > USB Device: CTE-640-U V4.0-3, WACOM, Up to 1.5 Mb/sec, 500 mA > USB Device: Bluetooth HCI, Up to 12 Mb/sec, 500 mA > USB Device: IR Receiver, Apple Computer, Inc., Up to 12 Mb/sec, 500 mA > > > Alan Schmitt a ?crit : >> On 5 janv. 07, at 20:36, Dany Nativel wrote: >> >>> Hello Alan, >>> >>> Thanks again for providing binaries for Mac OS and Windows for >>> Unison 2.26.13. I just got an iMac and was very happy to find a >>> unison package for it. I usually sync between my work PC >>> (windows), server (ubuntu dapper) and now my home pc (mac). >>> >>> In my previous setup I used to have unison-2.12.15-linux-text >>> (coming from unison website) installed on my server (not from >>> debian repository). Now I can't find any binary version of >>> 2.26.13 for Linux. I don't really care about the version. I just >>> need a unison-text for Linux and unison-GUI for both windows and >>> Mac OS. Would you by chance have a linux version of what you've >>> posted ? >> >> It's attached. I guess I should put it online as well. >> >> Alan >> >> >> >> -- >> Alan Schmitt >> >> The hacker: someone who figured things out and made something cool >> happen. >> .O. >> ..O >> OOO >> >> > > > -- 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: This is a digitally signed message part Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20070106/233a4d09/PGP-0001.sig From alan.schmitt at polytechnique.org Sat Jan 6 02:59:32 2007 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Sat, 6 Jan 2007 08:59:32 +0100 Subject: [Unison-hackers] MAC OS issue ... only with the GUI version In-Reply-To: <459ED660.6010506@nativel.net> References: <459EA8C7.4070204@nativel.net> <2DF7F91E-62B9-4B8B-97BF-C34ECDBD884D@polytechnique.org> <459EBDDD.2050302@nativel.net> <459ED660.6010506@nativel.net> Message-ID: <42C9BD65-775F-4288-8ADA-8C27A15BA123@polytechnique.org> On 5 janv. 07, at 23:51, Dany Nativel wrote: > Hi Alan, > > The traces I sent you earlier on were for crashes I was having with > the GUI version. I tried the exact same set of file with the commad > line edition and it worked. Apparently the crash appears at the > very end like when everything is done... sometimes GUI crashes > sometimes not. I think I've noticed this as well. Before the latest version, the GUI could crash in the middle of synchronization. Now I often see the GUI hang during synchronization (but looking at unison.log still shows progress), and when synchronization is finished, the GUI often crashes as well. (It took me time noticing it because I usually don't watch the Unison window, I rely on Growl to know when it's done.) 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: This is a digitally signed message part Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20070106/90eb70c6/PGP.sig From bcpierce at cis.upenn.edu Sat Jan 6 22:40:32 2007 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Sat, 6 Jan 2007 22:40:32 -0500 Subject: [Unison-hackers] MAC OS issue ... only with the GUI version In-Reply-To: <42C9BD65-775F-4288-8ADA-8C27A15BA123@polytechnique.org> References: <459EA8C7.4070204@nativel.net> <2DF7F91E-62B9-4B8B-97BF-C34ECDBD884D@polytechnique.org> <459EBDDD.2050302@nativel.net> <459ED660.6010506@nativel.net> <42C9BD65-775F-4288-8ADA-8C27A15BA123@polytechnique.org> Message-ID: <373BD3CD-9D98-4A03-BC7B-D87688A2819B@cis.upenn.edu> Sigh -- sounds like our latest attempt at addressing this issue did not do the trick. Unfortunately, I'm not sure this is fixable in the short term: Trevor and Ben are the only ones that currently understand the OSX GUI and they are both very busy with other things right now. It may be possible to roll back to a previous version of the GUI code (somewhere around r119 in the svn repository), but even this will take some work, and I am swamped now with the beginning of the semester. For the moment, I think the only solution is to tear down the OSX GUI binaries and advertise Unison as text-only (or GTK2- based, if someone is willing to build it) under OSX. - Benjamin On Jan 6, 2007, at 2:59 AM, Alan Schmitt wrote: > On 5 janv. 07, at 23:51, Dany Nativel wrote: > >> Hi Alan, >> >> The traces I sent you earlier on were for crashes I was having >> with the GUI version. I tried the exact same set of file with the >> commad line edition and it worked. Apparently the crash appears at >> the very end like when everything is done... sometimes GUI crashes >> sometimes not. > > I think I've noticed this as well. Before the latest version, the > GUI could crash in the middle of synchronization. Now I often see > the GUI hang during synchronization (but looking at unison.log > still shows progress), and when synchronization is finished, the > GUI often crashes as well. (It took me time noticing it because I > usually don't watch the Unison window, I rely on Growl to know when > it's done.) > > Alan > > -- > Alan Schmitt > > The hacker: someone who figured things out and made something cool > happen. > .O. > ..O > OOO > > > > _______________________________________________ > 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 Jan 6 22:42:32 2007 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Sat, 6 Jan 2007 22:42:32 -0500 Subject: [Unison-hackers] [unison-svn] r201 - trunk/src Message-ID: <200701070342.l073gWuN010436@canfield.cis.upenn.edu> Author: bcpierce Date: 2007-01-06 22:42:31 -0500 (Sat, 06 Jan 2007) New Revision: 201 Modified: trunk/src/RECENTNEWS trunk/src/clroot.ml trunk/src/mkProjectInfo.ml Log: * Fix crash reported by Chris Greene on incorrect root specification. From zpetkovic at acm.org Sat Jan 6 23:35:00 2007 From: zpetkovic at acm.org (Zvezdan Petkovic) Date: Sat, 6 Jan 2007 23:35:00 -0500 Subject: [Unison-hackers] New release almost ready -- help needed with testing In-Reply-To: References: <20070105083310.GA11133@petkovic.homeip.net> Message-ID: <20070107043459.GA3810@petkovic.homeip.net> On Fri, Jan 05, 2007 at 08:10:58AM -0500, Benjamin Pierce wrote: > Of course. But I am not set up to build the GTK1 interface locally, > so I'll need some help. (There have also been a few changes to the > code that may possibly prevent it compiling if I got them wrong, but > I hope these should be easy to fix.) I'll compile it. I'll try to compare the stable version Makefiles with this version and see if adding LIBLABLGTK in proper places makes it work with GTK1. I tried again the port of lablgtk2. It's stuck at 2.6 version of the GTK2 libraries, while the libraries I have on OpenBSD are 2.8.x. It compiles but when I try to run examples it segfaults. I'm very busy right now, so I asked ports list of OpenBSD if some GTK expert knows why this happens. > This is a bug: the default should be no backups. Can you please > remove your ~/.unison/backup and send me a "-debug all" trace for > some small part of your replica (using "-path XXX")? The behavior is > supposed to be controlled by "backupcurrent", whose default is empty. I will do it tomorrow. Best regards, Zvezdan From alan.schmitt at polytechnique.org Sun Jan 7 02:23:41 2007 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Sun, 7 Jan 2007 08:23:41 +0100 Subject: [Unison-hackers] MAC OS issue ... only with the GUI version In-Reply-To: <373BD3CD-9D98-4A03-BC7B-D87688A2819B@cis.upenn.edu> References: <459EA8C7.4070204@nativel.net> <2DF7F91E-62B9-4B8B-97BF-C34ECDBD884D@polytechnique.org> <459EBDDD.2050302@nativel.net> <459ED660.6010506@nativel.net> <42C9BD65-775F-4288-8ADA-8C27A15BA123@polytechnique.org> <373BD3CD-9D98-4A03-BC7B-D87688A2819B@cis.upenn.edu> Message-ID: On 7 janv. 07, at 04:40, Benjamin Pierce wrote: > For the moment, I think the only solution is to tear down > the OSX GUI binaries and advertise Unison as text-only (or GTK2- > based, if someone is willing to build it) under OSX. Should I stilll propose them on my page, with a note saying they might crash, or remove them altogether? (What I like about the recent version is that I get a GUI to see what the changes are, and they are propagated, even if Unison crashes when it's done. It's an improvement compared to crashing in the middle of propagation.) 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: This is a digitally signed message part Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20070107/6a006408/PGP.sig From bcpierce at cis.upenn.edu Sun Jan 7 09:25:21 2007 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Sun, 7 Jan 2007 09:25:21 -0500 Subject: [Unison-hackers] MAC OS issue ... only with the GUI version In-Reply-To: References: <459EA8C7.4070204@nativel.net> <2DF7F91E-62B9-4B8B-97BF-C34ECDBD884D@polytechnique.org> <459EBDDD.2050302@nativel.net> <459ED660.6010506@nativel.net> <42C9BD65-775F-4288-8ADA-8C27A15BA123@polytechnique.org> <373BD3CD-9D98-4A03-BC7B-D87688A2819B@cis.upenn.edu> Message-ID: >> For the moment, I think the only solution is to tear down >> the OSX GUI binaries and advertise Unison as text-only (or GTK2- >> based, if someone is willing to build it) under OSX. > > Should I stilll propose them on my page, with a note saying they > might crash, or remove them altogether? > > (What I like about the recent version is that I get a GUI to see > what the changes are, and they are propagated, even if Unison > crashes when it's done. It's an improvement compared to crashing in > the middle of propagation.) I don't like offering people (especially naive users) a program that is known to crash. Also, if we get a lot of people using it, there are going to be a lot of questions about when the crashes are going to be fixed, but at the moment we have no one actually signed up to even think about fixing them. I agree it's a shame, but I think it's really better not to distribute the binaries. - Benjamin From kevin at sb.org Mon Jan 8 02:12:32 2007 From: kevin at sb.org (Kevin Ballard) Date: Mon, 8 Jan 2007 02:12:32 -0500 Subject: [Unison-hackers] MAC OS issue ... only with the GUI version In-Reply-To: References: <459EA8C7.4070204@nativel.net> <2DF7F91E-62B9-4B8B-97BF-C34ECDBD884D@polytechnique.org> <459EBDDD.2050302@nativel.net> <459ED660.6010506@nativel.net> <42C9BD65-775F-4288-8ADA-8C27A15BA123@polytechnique.org> <373BD3CD-9D98-4A03-BC7B-D87688A2819B@cis.upenn.edu> Message-ID: On Jan 7, 2007, at 9:25 AM, Benjamin Pierce wrote: >>> For the moment, I think the only solution is to tear down >>> the OSX GUI binaries and advertise Unison as text-only (or GTK2- >>> based, if someone is willing to build it) under OSX. >> >> Should I stilll propose them on my page, with a note saying they >> might crash, or remove them altogether? >> >> (What I like about the recent version is that I get a GUI to see >> what the changes are, and they are propagated, even if Unison >> crashes when it's done. It's an improvement compared to crashing in >> the middle of propagation.) > > I don't like offering people (especially naive users) a program that > is known to crash. Also, if we get a lot of people using it, there > are going to be a lot of questions about when the crashes are going > to be fixed, but at the moment we have no one actually signed up to > even think about fixing them. I agree it's a shame, but I think it's > really better not to distribute the binaries. I don't use the OS X GUIs (I prefer text-only, as it's much faster to fire off), but I am a Cocoa programmer. What's the problem right now, and what do you think it would take to fix? -- Kevin Ballard http://kevin.sb.org kevin at sb.org http://www.tildesoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20070108/0e1b4066/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2432 bytes Desc: not available Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20070108/0e1b4066/smime-0001.p7s From alan.schmitt at polytechnique.org Mon Jan 8 03:36:45 2007 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Mon, 8 Jan 2007 09:36:45 +0100 Subject: [Unison-hackers] MAC OS issue ... only with the GUI version In-Reply-To: References: <459EA8C7.4070204@nativel.net> <2DF7F91E-62B9-4B8B-97BF-C34ECDBD884D@polytechnique.org> <459EBDDD.2050302@nativel.net> <459ED660.6010506@nativel.net> <42C9BD65-775F-4288-8ADA-8C27A15BA123@polytechnique.org> <373BD3CD-9D98-4A03-BC7B-D87688A2819B@cis.upenn.edu> Message-ID: <12D0D2BE-5537-4A77-9643-3BD36DDADB76@polytechnique.org> On 8 janv. 07, at 08:12, Kevin Ballard wrote: > I don't use the OS X GUIs (I prefer text-only, as it's much faster > to fire off), but I am a Cocoa programmer. What's the problem right > now, and what do you think it would take to fix? The problem is the following (with the current version): the GUI stops responding during synchronization (even though unison still propagates files) and sometimes it crashes at the end of synchronization. I could take a sample of Unison the next time the GUI hangs, if it may help you. 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: This is a digitally signed message part Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20070108/4ee6f5e1/PGP.sig From alan.schmitt at polytechnique.org Mon Jan 8 03:41:12 2007 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Mon, 8 Jan 2007 09:41:12 +0100 Subject: [Unison-hackers] MAC OS issue ... only with the GUI version In-Reply-To: References: <459EA8C7.4070204@nativel.net> <2DF7F91E-62B9-4B8B-97BF-C34ECDBD884D@polytechnique.org> <459EBDDD.2050302@nativel.net> <459ED660.6010506@nativel.net> <42C9BD65-775F-4288-8ADA-8C27A15BA123@polytechnique.org> <373BD3CD-9D98-4A03-BC7B-D87688A2819B@cis.upenn.edu> Message-ID: <8F21B914-0B9C-4CE1-AB1E-C7445F56D05C@polytechnique.org> On 7 janv. 07, at 15:25, Benjamin Pierce wrote: > I don't like offering people (especially naive users) a program that > is known to crash. Also, if we get a lot of people using it, there > are going to be a lot of questions about when the crashes are going > to be fixed, but at the moment we have no one actually signed up to > even think about fixing them. I agree it's a shame, but I think it's > really better not to distribute the binaries. I have removed them. 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: This is a digitally signed message part Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20070108/3aef5913/PGP.sig From bcpierce at cis.upenn.edu Mon Jan 8 09:07:30 2007 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Mon, 8 Jan 2007 09:07:30 -0500 Subject: [Unison-hackers] MAC OS issue ... only with the GUI version In-Reply-To: References: <459EA8C7.4070204@nativel.net> <2DF7F91E-62B9-4B8B-97BF-C34ECDBD884D@polytechnique.org> <459EBDDD.2050302@nativel.net> <459ED660.6010506@nativel.net> <42C9BD65-775F-4288-8ADA-8C27A15BA123@polytechnique.org> <373BD3CD-9D98-4A03-BC7B-D87688A2819B@cis.upenn.edu> Message-ID: <2AD09D02-A321-4760-891F-73F370FE63CC@cis.upenn.edu> > I don't use the OS X GUIs (I prefer text-only, as it's much faster > to fire off), but I am a Cocoa programmer. What's the problem right > now, and what do you think it would take to fix? It would be great if you could take a look! Here's the current state of play: * A longish time ago, Trevor Jim implemented a basic OSX GUI in a combination of Objective C and OCaml. It was kind of bare bones, but it worked fine. * A few months ago, Ben Willmore enormously improved the GUI in many, many ways. Unfortunately, somewhere along the line, a bug was introduced that would cause intermittent crashes, especially with large syncs. Ben, Trevor, and I discussed the problem and decided that the likely culprit was the fact that some multithreading had been introduced on the GUI side (to make it more responsive) but that somehow locks were not being held properly when calling into the OCaml part, leading to sometimes-fatal races. But Ben did not succeed in tracking down the details. Ben's last message on the subject is appended. * A couple of months ago, Trevor proposed this: > So on the theory that threads are the problem (race conditions) > this might be relevant: > http://groups.google.com/group/fa.caml/browse_thread/thread/ > 684a6f1647fdbe3/e4ad7e1e8fca5edb? > lnk=gst&q=threads&rnum=1#e4ad7e1e8fca5edb > We are probably lacking the required locks in C code that > gets invoked by the GUI to call back into ocaml. > -Trevor * Specifically, he proposed the following simple strategy: > Somewhere in the .m files declare a lock: > > #include > pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER; > > Then, before each callback (e.g., caml_callback, caml_callback_exn): > > pthread_mutex_lock(&lock); > > And after each callback: > > pthread_mutex_unlock(&lock); * A couple of weeks ago, I implemented this suggestion -- see the file uimac/main.m (all the changes I made are in that file). Unfortunately, as we're seeing, this change seems to have made the GUI unresponsive sometimes *and* not to have fixed the underlying problem. That brings us to the present. Any thoughts you might have would be most welcome. Regards, - Benjamin ---------- Forwarded message ---------- From: Ben Willmore Date: 23-Apr-2006 19:15 Subject: Re: [Unison-hackers] mutex To: Unison hackers Well, I'm stumped. Here's the problem in detail: If thread A is running unisonSynchronize (uimacbridge.ml), and thread B calls unisonRiToDetails (also uimacbridge.ml), a crash will sometimes occur. [Removing references to the stateItem in unisonRiToDetails fixes it.] My assumption was that both threads were trying to access the same stateItem simultaneously. Either this is not the case, or I don't understand unisonSynchronize as well as I think I do. Attached is a patch that demonstrates it. It adds mutex locking in unisonRiToDetails and unisonSynchronize, and some NSLog (print) statements. Steps to reproduce the bug: Start the Mac GUI from the command line Choose two roots with a large number of different small files (I use the script below to make 500) Scroll down and select the last reconItem, using the scroll bar, *not* the down arrow (which would fetch all the details in advance). Hit Go Hold down the up arrow You will see: Usually, Unison will crash with a bus error (sometimes a segfault, occasionally something else). The mutexes have no effect in preventing this (though tests show they are locking correctly). The print statements show something like: ... 2006-04-23 11:46:44.836 Unison[8722] dS: SyncEnd: file34 2006-04-23 11:46:44.837 Unison[8722] dS: SyncStart: file340 2006-04-23 11:46:44.837 Unison[8722] dS: TransStart: file340 2006-04-23 11:46:44.838 Unison[8722] dS: TransStart: file340 file340 2006-04-23 11:46:44.841 Unison[8722] dS: SyncEnd: file340 2006-04-23 11:46:44.842 Unison[8722] dS: SyncStart: file341 2006-04-23 11:46:44.843 Unison[8722] dS: TransStart: file341 2006-04-23 11:46:44.843 Unison[8722] dS: TransStart: file341 file341 2006-04-23 11:46:44.861 Unison[8722] dS: Details: file9 2006-04-23 11:46:44.908 Unison[8722] dS: Details: file89 2006-04-23 11:46:45.011 Unison[8722] dS: Details: file88 2006-04-23 11:46:45.057 Unison[8722] dS: Details: file87 2006-04-23 11:46:45.066 Unison[8722] dS: Details: file86 2006-04-23 11:46:45.113 Unison[8722] dS: Details: file85 2006-04-23 11:46:45.160 Unison[8722] dS: Details: file84 2006-04-23 11:46:45.209 Unison[8722] dS: Details: file83 2006-04-23 11:46:45.262 Unison[8722] dS: Details: file82 2006-04-23 11:46:45.297 Unison[8722] dS: Details: file81 2006-04-23 11:46:45.327 Unison[8722] dS: Details: file80 2006-04-23 11:46:45.362 Unison[8722] dS: Details: file8 2006-04-23 11:46:45.396 Unison[8722] dS: Details: file79 Bus error The files are alphanumerically sorted, so this indicates that files file1->file340 have been synced successfully, and we're in the middle of syncing file341. Details have been displayed for files file99->file79. I.E. We haven't got close to a conflict where both the sync thread and the GUI thread access the same item. This is really annoying me. As far as I can tell, both threads are locked everywhere (relevant) that the stateItems are referenced, and the log seems to agree this is not the problem. But I can't see any reason why running unisonRiToDetails on file79 should cause a crash during synchronization of file341. Any injection of wisdom would be much appreciated. Ben ------------ #!/bin/bash # make n=$1 files containing $2 LIMIT=$1 for ((a=1; a <= LIMIT ; a++)) do echo $2 > file$a done From trevor at research.att.com Mon Jan 8 14:45:51 2007 From: trevor at research.att.com (Trevor Jim) Date: Mon, 08 Jan 2007 14:45:51 -0500 Subject: [Unison-hackers] MAC OS issue ... only with the GUI version In-Reply-To: <2AD09D02-A321-4760-891F-73F370FE63CC@cis.upenn.edu> References: <459EA8C7.4070204@nativel.net> <2DF7F91E-62B9-4B8B-97BF-C34ECDBD884D@polytechnique.org> <459EBDDD.2050302@nativel.net> <459ED660.6010506@nativel.net> <42C9BD65-775F-4288-8ADA-8C27A15BA123@polytechnique.org> <373BD3CD-9D98-4A03-BC7B-D87688A2819B@cis.upenn.edu> <2AD09D02-A321-4760-891F-73F370FE63CC@cis.upenn.edu> Message-ID: <45A29F6F.4020407@research.att.com> I've got a question in to the ocaml list about this. I think we are still missing some locks, but I need more information to figure out where, as this is not documented in ocaml. Given the constraints on how threaded ObjC programs can call into ocaml, it may be that the threads that Ben (?) added to improve responsiveness will end up being ineffective... too early to tell yet. -Trevor From trevor at research.att.com Mon Jan 8 17:19:22 2007 From: trevor at research.att.com (Trevor Jim) Date: Mon, 08 Jan 2007 17:19:22 -0500 Subject: [Unison-hackers] MAC OS issue ... only with the GUI version In-Reply-To: References: <459EA8C7.4070204@nativel.net> <2DF7F91E-62B9-4B8B-97BF-C34ECDBD884D@polytechnique.org> <459EBDDD.2050302@nativel.net> <459ED660.6010506@nativel.net> <42C9BD65-775F-4288-8ADA-8C27A15BA123@polytechnique.org> <373BD3CD-9D98-4A03-BC7B-D87688A2819B@cis.upenn.edu> Message-ID: <45A2C36A.8090004@research.att.com> Kevin Ballard wrote: > I don't use the OS X GUIs (I prefer text-only, as it's much faster to > fire off), but I am a Cocoa programmer. What's the problem right now, > and what do you think it would take to fix? I don't know that it makes sense to dive into the code just yet as we are investigating some ocaml issues. However maybe you or some other person can answer this: Is the Cocoa stuff always multi-threaded? That is, if I just compile a regular Cocoa program, say, the hello world equivalent, is the resulting binary multi-threaded? (If not, then we would have the option of removing some of the threaded code we added; but if it is always multi-threaded, that won't help.) -Trevor , From Oliver.Menge at web.de Thu Jan 11 08:58:27 2007 From: Oliver.Menge at web.de (Menge, Oliver) Date: Thu, 11 Jan 2007 14:58:27 +0100 (CET) Subject: [Unison-hackers] path length issue with NTFS Message-ID: Hi, I started to use unison (2.13.16 on WinXP) to synchronize windows network shares with my local laptop. The full filenames (including drive-letter and path) are sometimes very long (some examples with more than 200 characters). On whatever limit unison refuses (abort) to synchronize. Is there a known issue with that? Couldn't find anything. Thanks, Oliver From kevin at sb.org Sat Jan 13 05:12:56 2007 From: kevin at sb.org (Kevin Ballard) Date: Sat, 13 Jan 2007 05:12:56 -0500 Subject: [Unison-hackers] MAC OS issue ... only with the GUI version In-Reply-To: <45A2C36A.8090004@research.att.com> References: <459EA8C7.4070204@nativel.net> <2DF7F91E-62B9-4B8B-97BF-C34ECDBD884D@polytechnique.org> <459EBDDD.2050302@nativel.net> <459ED660.6010506@nativel.net> <42C9BD65-775F-4288-8ADA-8C27A15BA123@polytechnique.org> <373BD3CD-9D98-4A03-BC7B-D87688A2819B@cis.upenn.edu> <45A2C36A.8090004@research.att.com> Message-ID: On Jan 8, 2007, at 5:19 PM, Trevor Jim wrote: > I don't know that it makes sense to dive into the code just > yet as we are investigating some ocaml issues. However maybe > you or some other person can answer this: > > Is the Cocoa stuff always multi-threaded? That is, if I just > compile a regular Cocoa program, say, the hello world equivalent, > is the resulting binary multi-threaded? > > (If not, then we would have the option of removing some of the > threaded code we added; but if it is always multi-threaded, > that won't help.) Foundation, by default, doesn't do any threading. AppKit, by default, does. As soon as you start doing anything with AppKit it's going to mark the app as multithreaded, as it likes to use background "heartbeat" threads to do stuff. Similarly, things like loading URLs uses background threads, as do other tasks. That said, the GUI stuff always runs on the main thread. Any event triggered by a GUI action is going to be processed on the main thread. Similarly, any time your code wants to manipulate the GUI it should be doing it from the main thread. It's possible to do it from a background thread, as it won't complain, but there's no guarantee it will work and race conditions will almost certainly be present in your code. -- Kevin Ballard http://kevin.sb.org kevin at sb.org http://www.tildesoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20070113/c2faa6d1/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2432 bytes Desc: not available Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20070113/c2faa6d1/smime-0001.p7s From alan.schmitt at polytechnique.org Tue Jan 16 03:57:41 2007 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Tue, 16 Jan 2007 09:57:41 +0100 Subject: [Unison-hackers] Reproducible "archives not identical bug" In-Reply-To: <45AC8568.8090704@iism.uni-karlsruhe.de> References: <45AC02B6.8030007@iism.uni-karlsruhe.de> <5EA7EE07-5E9E-42A4-A619-F59EB05B5C58@polytechnique.org> <45AC8568.8090704@iism.uni-karlsruhe.de> Message-ID: On 16 janv. 07, at 08:57, Jan Schr?der (de) wrote: > Alan, > > no, am using the latest stable one along with the windows build. But > did also try all the cygwin versions with the same effect (running > unter cygwin and windows). The profile looks for example simply like > this here: > > WIN > root = C:\Programme > root = D:\backup > path = JAlbum\skins\NegiStyleFlat > > CYGWIN > root = /cygdrive/c/Programme > root = /cygdrive/d/backup > path = BitTorrent/images > > Looks pretty simple. The result in cygwin for Version 2.9.20 called as > > unison -debug=all _bak.unix 1> log.txt 2> stderr.txt > > gives the attached output which is as I am used to it from much > earlier versions not correct... > > You have any clue? I don't, so I copy the Unison hackers list. Alan > Alan Schmitt schrieb: >> On 15 janv. 07, at 23:39, Jan Schr?der (en) wrote: >> >>> Alan, >>> >>> have the same problem as you described it in >>> http://lists.seas.upenn.edu/pipermail/unison-hackers/2006-May/ >>> 000447.html. >>> >>> >>> Did you solve it up to now? Would be interested in any hint as I >>> have >>> the same problem with the latest version and cannot find an answer. >> >> Hello, >> >> I did not follow up on this, but it might have been fixed. Are you >> using the current developer version? >> >> Alan > > Preferences: > ui = graphic > server = false > prefsdocs = false > doc = > version = false > silent = false > dumbtty = true > testserver = false > rest = _bak.unix > contactquietly = false > key = > label = > expert = false > reusewindows = false > height = 20 > batch = false > auto = false > maxthreads = 20 > backups = false > prefer = > force = > sortnewfirst = false > sortbysize = false > editor = emacs > merge2 = > merge = > diff = diff > verifyTransfers = false > statusdepth = 2 > fastcheck = default > backupdir = > maxbackups = 2 > rootsName = > path = Programme/BitTorrent/images > root = /cygdrive/d/backup > root = /cygdrive/c > killserver = false > rsync = true > addversionno = false > servercmd = > rshargs = > rshcmd = rsh > sshcmd = ssh > xferbycopying = true > sshversion = > pretendwin = false > times = false > group = false > owner = false > numericids = false > perms = 0 > ignorecase = false > timers = false > terse = false > logfile = /home/uh29/unison.log > log = true > debugtimes = false > debug = all > addprefsto = > Contacting server... > [globals] Checking path 'Programme / BitTorrent / images' for > expansions > Roots: > /cygdrive/d/backup > /cygdrive/c > i.e. > /cygdrive/d/backup > /cygdrive/c > i.e. (in canonical order) > /cygdrive/c > /cygdrive/d/backup > > [props] Setting permission mask to 0 (0 and 200) > <>$Looking for changes > [update] Archive name is //majestix//cygdrive/c;//majestix// > cygdrive/c, //majestix//cygdrive/d/backup;17; hashcode is > f454141956a815eb1c29279e7e55ee9c > [update] Archive name is //majestix//cygdrive/d/backup;//majestix// > cygdrive/c, //majestix//cygdrive/d/backup;17; hashcode is > f434cea7c88db180334c407c3e2c9f82 > [update] Archive name is //majestix//cygdrive/c;//majestix// > cygdrive/c, //majestix//cygdrive/d/backup;17; hashcode is > f454141956a815eb1c29279e7e55ee9c > [update] Archive name is //majestix//cygdrive/c;//majestix// > cygdrive/c, //majestix//cygdrive/d/backup;17; hashcode is > f454141956a815eb1c29279e7e55ee9c > [update] Archive name is //majestix//cygdrive/d/backup;//majestix// > cygdrive/c, //majestix//cygdrive/d/backup;17; hashcode is > f434cea7c88db180334c407c3e2c9f82 > [update] Archive name is //majestix//cygdrive/d/backup;//majestix// > cygdrive/c, //majestix//cygdrive/d/backup;17; hashcode is > f434cea7c88db180334c407c3e2c9f82 > [update] Archive name is //majestix//cygdrive/c;//majestix// > cygdrive/c, //majestix//cygdrive/d/backup;17; hashcode is > f454141956a815eb1c29279e7e55ee9c > [update] Loading archive from /cygdrive/c/Dokumente und > Einstellungen/uh29/.unison/arf45414 > [update] Archive /cygdrive/c/Dokumente und Einstellungen/ > uh29/.unison/arf45414 not found > [update] Setting archive for //majestix//cygdrive/c > GC: 23012 > [update] Archive name is //majestix//cygdrive/d/backup;//majestix// > cygdrive/c, //majestix//cygdrive/d/backup;17; hashcode is > f434cea7c88db180334c407c3e2c9f82 > [update] Loading archive from /cygdrive/c/Dokumente und > Einstellungen/uh29/.unison/arf434ce > [update] Archive /cygdrive/c/Dokumente und Einstellungen/ > uh29/.unison/arf434ce not found > [update] Setting archive for //majestix//cygdrive/d/backup > GC: 23012 true > [update] Archive name is //majestix//cygdrive/c;//majestix// > cygdrive/c, //majestix//cygdrive/d/backup;17; hashcode is > f454141956a815eb1c29279e7e55ee9c > [update] Archive name is //majestix//cygdrive/d/backup;//majestix// > cygdrive/c, //majestix//cygdrive/d/backup;17; hashcode is > f434cea7c88db180334c407c3e2c9f82 > [update] findOnRoot /cygdrive/c > [update] findOnRoot /cygdrive/d/backup > [update] findLocal /cygdrive/c > [update] Archive name is //majestix//cygdrive/c;//majestix// > cygdrive/c, //majestix//cygdrive/d/backup;17; hashcode is > f454141956a815eb1c29279e7e55ee9c > [update] Archive name is //majestix//cygdrive/c;//majestix// > cygdrive/c, //majestix//cygdrive/d/backup;17; hashcode is > f454141956a815eb1c29279e7e55ee9c > [update] updatePathInArchive NoArchive /cygdrive/c [] [Programme/ > BitTorrent/images] > [update] updatePathInArchive NoArchive /cygdrive/c [Programme] > [BitTorrent/images] > [update] updatePathInArchive NoArchive /cygdrive/c [Programme/ > BitTorrent] [images] > [update] updatePathInArchive NoArchive /cygdrive/c [Programme/ > BitTorrent/images] [] > [pred] ignore 'Programme/BitTorrent/images' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images > [update] New directory > Programme/BitTorrent/images > [pred] ignore 'Programme/BitTorrent/images/bittorrent.ico' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > bittorrent.ico > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags > [update] New directory > [pred] ignore 'Programme/BitTorrent/images/flags/AE.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > AE.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/AR.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > AR.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/AT.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > AT.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/AU.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > AU.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/BE.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > BE.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/BG.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > BG.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/BR.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > BR.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/CA.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > CA.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/CH.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > CH.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/CL.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > CL.png > [update] Updated file > <>$[pred] ignore 'Programme/BitTorrent/images/flags/CN.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > CN.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/CO.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > CO.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/CY.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > CY.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/CZ.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > CZ.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/DE.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > DE.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/DK.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > DK.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/ES.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > ES.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/EU.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > EU.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/FI.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > FI.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/FR.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > FR.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/GB.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > GB.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/GR.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > GR.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/GT.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > GT.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/HK.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > HK.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/HU.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > HU.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/IT.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > IT.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/JP.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > JP.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/KR.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > KR.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/KW.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > KW.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/LT.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > LT.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/LV.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > LV.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/MX.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > MX.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/NA.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > NA.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/NL.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > NL.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/NO.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > NO.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/noimage.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > noimage.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/PR.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > PR.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/PT.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > PT.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/RU.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > RU.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/SE.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > SE.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/SG.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > SG.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/SI.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > SI.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/TW.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > TW.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/unknown.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > unknown.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/US.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > US.png > [update] Updated file > <>$[pred] ignore 'Programme/BitTorrent/images/flags/YU.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > YU.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/flags/ZA.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/flags/ > ZA.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/logo' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/logo > [update] New directory > [pred] ignore 'Programme/BitTorrent/images/logo/banner.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/logo/ > banner.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/logo/ > bittorrent_icon.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/logo/ > bittorrent_icon.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/logo/ > bittorrent_icon_16.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/logo/ > bittorrent_icon_16.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/logo/ > bittorrent_icon_24.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/logo/ > bittorrent_icon_24.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/logo/ > bittorrent_icon_32.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/logo/ > bittorrent_icon_32.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/logo/ > bittorrent_icon_48.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/logo/ > bittorrent_icon_48.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/themes > [update] New directory > [pred] ignore 'Programme/BitTorrent/images/themes/default' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default > [update] New directory > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > add_16.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/add_16.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > add_24.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/add_24.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > add_32.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/add_32.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/fileops' > = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/fileops > [update] New directory > [pred] ignore 'Programme/BitTorrent/images/themes/default/fileops/ > first_16.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/fileops/first_16.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/fileops/ > first_24.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/fileops/first_24.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/fileops/ > first_32.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/fileops/first_32.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/fileops/ > never_16.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/fileops/never_16.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/fileops/ > never_24.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/fileops/never_24.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/fileops/ > never_32.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/fileops/never_32.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/fileops/ > normal_16.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/fileops/normal_16.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/fileops/ > normal_24.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/fileops/normal_24.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/fileops/ > normal_32.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/fileops/normal_32.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > progressbar.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/progressbar.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > search_16.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/search_16.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > search_24.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/search_24.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > search_32.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/search_32.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > settings_16.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/settings_16.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > settings_24.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/settings_24.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > settings_32.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/settings_32.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > torrentops' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/torrentops > [update] New directory > <>Starting new major GC cycle > ![pred] ignore 'Programme/BitTorrent/images/themes/default/ > torrentops/info_16.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/torrentops/info_16.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > torrentops/info_24.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/torrentops/info_24.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > torrentops/info_32.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/torrentops/info_32.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > torrentops/launch_16.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/torrentops/launch_16.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > torrentops/launch_24.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/torrentops/launch_24.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > torrentops/launch_32.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/torrentops/launch_32.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > torrentops/remove_16.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/torrentops/remove_16.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > torrentops/remove_24.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/torrentops/remove_24.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > torrentops/remove_32.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/torrentops/remove_32.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > torrentops/resume_16.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/torrentops/resume_16.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > torrentops/resume_24.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/torrentops/resume_24.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > torrentops/resume_32.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/torrentops/resume_32.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > torrentops/stop_16.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/torrentops/stop_16.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > torrentops/stop_24.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/torrentops/stop_24.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > torrentops/stop_32.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/torrentops/stop_32.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > torrentstate' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/torrentstate > [update] New directory > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > torrentstate/complete.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/torrentstate/complete.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > torrentstate/created.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/torrentstate/created.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > torrentstate/downloading.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/torrentstate/downloading.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > torrentstate/error.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/torrentstate/error.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > torrentstate/finishing.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/torrentstate/finishing.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > torrentstate/force-seed.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/torrentstate/force-seed.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > torrentstate/paused.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/torrentstate/paused.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > torrentstate/seeding.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/torrentstate/seeding.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > torrentstate/starting.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/torrentstate/starting.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > torrentstate/stopped.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/torrentstate/stopped.png > [update] Updated file > [pred] ignore 'Programme/BitTorrent/images/themes/default/ > torrentstate/unknown.png' = false > [update] buildUpdate: /cygdrive/c/Programme/BitTorrent/images/ > themes/default/torrentstate/unknown.png > [update] Updated file > [update] Setting archive for //majestix//cygdrive/c > GC: 28513 true true > [update] findLocal /cygdrive/d/backup > [update] Archive name is //majestix//cygdrive/d/backup;//majestix// > cygdrive/c, //majestix//cygdrive/d/backup;17; hashcode is > f434cea7c88db180334c407c3e2c9f82 > [update] Archive name is //majestix//cygdrive/d/backup;//majestix// > cygdrive/c, //majestix//cygdrive/d/backup;17; hashcode is > f434cea7c88db180334c407c3e2c9f82 > [fspath] Os.findWorkingDir(/cygdrive/d/backup,Programme/BitTorrent/ > images) = (/cygdrive/d/backup/Programme/BitTorrent,images) > Fatal error: Path /cygdrive/d/backup/Programme/BitTorrent/images is > not valid because /cygdrive/d/backup/Programme/BitTorrent is not a > directory > Fatal error: Path /cygdrive/d/backup/Programme/BitTorrent/images is > not valid because /cygdrive/d/backup/Programme/BitTorrent is not a > directory > Warning: No archive files were found for these roots. This can > happen either > because this is the first time you have synchronized these roots, > or because you have upgraded Unison to a new version with a different > archive format. > > Update detection may take a while on this run if the replicas are > large. > > Unison will assume that the 'last synchronized state' of both replicas > was completely empty. This means that any files that are different > will be reported as conflicts, and any files that exist only on one > replica will be judged as new and propagated to the other replica. > If the two replicas are identical, then no changes will be reported. > Press return to continue.[] -- 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: This is a digitally signed message part Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20070116/6683d4cb/PGP-0001.sig From kevin at sb.org Sun Jan 21 10:14:02 2007 From: kevin at sb.org (Kevin Ballard) Date: Sun, 21 Jan 2007 10:14:02 -0500 Subject: [Unison-hackers] Patch to make -auto more useful Message-ID: <18D0003D-3ED0-47F1-871D-96D15DEFF9B3@sb.org> I have all my profiles set up to set auto=true by default, but sometimes I want to have more control when synchronizing. Unfortunately, if I say "no" to proceeding with updates, it just asks me again, rather than letting me pick and choose as if auto was false. The attached patch fixes this. When the user says "no" to proceeding, it turns auto off. Patch was created against r201. ? -- Kevin Ballard http://kevin.sb.org kevin at sb.org http://www.tildesoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20070121/6141cd1b/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: unison.patch Type: application/octet-stream Size: 558 bytes Desc: not available Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20070121/6141cd1b/unison.bin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20070121/6141cd1b/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2432 bytes Desc: not available Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20070121/6141cd1b/smime.p7s From bcpierce at cis.upenn.edu Sun Jan 21 11:02:35 2007 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Sun, 21 Jan 2007 11:02:35 -0500 Subject: [Unison-hackers] Patch to make -auto more useful In-Reply-To: <18D0003D-3ED0-47F1-871D-96D15DEFF9B3@sb.org> References: <18D0003D-3ED0-47F1-871D-96D15DEFF9B3@sb.org> Message-ID: <382D6201-32D3-42AA-9032-F10D17705B06@cis.upenn.edu> Good idea. Thanks, - B On Jan 21, 2007, at 10:14 AM, Kevin Ballard wrote: > I have all my profiles set up to set auto=true by default, but > sometimes I want to have more control when synchronizing. > Unfortunately, if I say "no" to proceeding with updates, it just > asks me again, rather than letting me pick and choose as if auto > was false. > > The attached patch fixes this. When the user says "no" to > proceeding, it turns auto off. Patch was created against r201. > > > > -- > Kevin Ballard > http://kevin.sb.org > kevin at sb.org > http://www.tildesoft.com > > > _______________________________________________ > 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 Jan 21 11:03:04 2007 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Sun, 21 Jan 2007 11:03:04 -0500 Subject: [Unison-hackers] [unison-svn] r202 - trunk/src Message-ID: <200701211603.l0LG34sN025889@canfield.cis.upenn.edu> Author: bcpierce Date: 2007-01-21 11:03:04 -0500 (Sun, 21 Jan 2007) New Revision: 202 Modified: trunk/src/RECENTNEWS trunk/src/TODO.txt trunk/src/mkProjectInfo.ml trunk/src/uitext.ml Log: * Incorporated a patch from Kevin Ballard that turns off the "auto" flag when the user says "No" to the "Proceed with updates" question in the text UI. (This makes 'auto' more useful.) From alan.schmitt at polytechnique.org Tue Jan 23 04:31:49 2007 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Tue, 23 Jan 2007 10:31:49 +0100 Subject: [Unison-hackers] About the current OS X GUI hanging Message-ID: Hello, I have noticed something that might help: the time when the GUI hangs on OS X is when it needs to update the column where it shows the update percentage and the "done" information, but only when it is in the visible part of list. To reproduce: have many things to synchronize, scroll down to the bottom, and start synchronization. When Unison hangs, the line showing what file has started synchronizing should correspond to the one at the top of the window (or the one just before if it's partially displayed). 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: This is a digitally signed message part Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20070123/58e3e34f/PGP.sig From michael.parsons at ucdmc.ucdavis.edu Tue Jan 23 07:00:34 2007 From: michael.parsons at ucdmc.ucdavis.edu (Michael Parsons) Date: Tue, 23 Jan 2007 04:00:34 -0800 Subject: [Unison-hackers] CN=Michael Parsons/OU=IS/OU=HS/O=UCD is out of the office. Message-ID: I will be out of the office starting 01/22/2007 and will not return until 01/24/2007. From bcpierce at cis.upenn.edu Tue Jan 23 09:21:17 2007 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Tue, 23 Jan 2007 09:21:17 -0500 Subject: [Unison-hackers] About the current OS X GUI hanging In-Reply-To: References: Message-ID: <262D4085-A7D2-49BB-A520-5D26BCAE74C0@cis.upenn.edu> Aha -- thanks, Alan! That definitely helps. So it seems clear (without looking at the code, which I don't understand in any detail) that what's happening is: - GUI thread calls OCaml to process a transfer instruction (grabbing the lock) - OCaml calls back to GUI to update the "done" information - GUI thread needs to look up some bit of information from the OCaml data structure to know how to update the screen, so it tries to call back into OCaml, but now gets stuck because the lock is already held So I guess the next question is whether it is OK simply to release the lock when the callback happens (and re-acquire it on the recursive call to OCaml), or if this is not safe because it might lead to a *different* GUI thread acquiring the lock and making a call into OCaml instead. (I have a feeling it might not be safe: if there is a saved call stack on the OCaml side, then it seems like we need to return from callbacks in the order that they were made. In which case we might fix the hang by making the lock re-entrant -- i.e., turning the lock into a counter and keeping track of the thread that is currently holding it.) Trevor? Ben? - B On Jan 23, 2007, at 4:31 AM, Alan Schmitt wrote: > Hello, > > I have noticed something that might help: the time when the GUI > hangs on OS X is when it needs to update the column where it shows > the update percentage and the "done" information, but only when it > is in the visible part of list. > > To reproduce: have many things to synchronize, scroll down to the > bottom, and start synchronization. When Unison hangs, the line > showing what file has started synchronizing should correspond to > the one at the top of the window (or the one just before if it's > partially displayed). > > Alan > > -- > Alan Schmitt > > The hacker: someone who figured things out and made something cool > happen. > .O. > ..O > OOO > > > > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From kevin at sb.org Tue Jan 23 13:40:58 2007 From: kevin at sb.org (Kevin Ballard) Date: Tue, 23 Jan 2007 13:40:58 -0500 Subject: [Unison-hackers] About the current OS X GUI hanging In-Reply-To: <262D4085-A7D2-49BB-A520-5D26BCAE74C0@cis.upenn.edu> References: <262D4085-A7D2-49BB-A520-5D26BCAE74C0@cis.upenn.edu> Message-ID: <9A805515-EFD3-410F-8095-DB51A575099C@sb.org> My inclination is to say a re-entrant lock is almost certainly what we want here. Are there any problems this could cause? I haven't looked at the source. Is this callback happening on the main thread or on a separate thread? Because if it's happening on the main thread, then a re-entrant lock won't fix the problem, as the GUI is (or at least *should* be - if not, then this is a sleeping heisenbug waiting to trigger) on the main thread, and so any OCaml calls triggered from the GUI would be on a separate thread from the callback. On Jan 23, 2007, at 9:21 AM, Benjamin Pierce wrote: > Aha -- thanks, Alan! That definitely helps. > > So it seems clear (without looking at the code, which I don't > understand in any detail) that what's happening is: > > - GUI thread calls OCaml to process a transfer instruction > (grabbing the lock) > - OCaml calls back to GUI to update the "done" information > - GUI thread needs to look up some bit of information from the > OCaml data structure to know how to update the screen, so it tries to > call back into OCaml, but now gets stuck because the lock is already > held > > So I guess the next question is whether it is OK simply to release > the lock when the callback happens (and re-acquire it on the > recursive call to OCaml), or if this is not safe because it might > lead to a *different* GUI thread acquiring the lock and making a call > into OCaml instead. > > (I have a feeling it might not be safe: if there is a saved call > stack on the OCaml side, then it seems like we need to return from > callbacks in the order that they were made. In which case we might > fix the hang by making the lock re-entrant -- i.e., turning the lock > into a counter and keeping track of the thread that is currently > holding it.) > > Trevor? Ben? -- Kevin Ballard http://kevin.sb.org kevin at sb.org http://www.tildesoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20070123/de6547d0/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2432 bytes Desc: not available Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20070123/de6547d0/smime-0001.p7s From trevor at research.att.com Tue Jan 23 15:32:58 2007 From: trevor at research.att.com (Trevor Jim) Date: Tue, 23 Jan 2007 15:32:58 -0500 Subject: [Unison-hackers] About the current OS X GUI hanging In-Reply-To: <262D4085-A7D2-49BB-A520-5D26BCAE74C0@cis.upenn.edu> References: <262D4085-A7D2-49BB-A520-5D26BCAE74C0@cis.upenn.edu> Message-ID: <45B670FA.3070009@research.att.com> > - GUI thread calls OCaml to process a transfer instruction > (grabbing the lock) > - OCaml calls back to GUI to update the "done" information > - GUI thread needs to look up some bit of information from the > OCaml data structure to know how to update the screen, so it tries to > call back into OCaml, but now gets stuck because the lock is already > held There are two issues, first is deadlock/starvation, second is crashing. I think we crash because two objc threads call in to ocaml at the same time. We need more locking, as I indicated in my previous messages. More locking of course will only increase the deadlock/starvation problems. Stepping back, what is going on is that while the ocaml thread is running, the gui would like to be responsive, so there should be communication between the ocaml thread and an objc gui thread. This communication **cannot** occur via the usual ocaml C API, that's simply not allowed because of ocaml internal reasons. Therefore simply adding reentrant locks or more locks (rather than the one lock we have now) is not sufficient to handle the gui responsiveness issue. Therefore we need two things: (1) More locking, so that there is only one call from objc through the ocaml C API at any given time (2) A different mechanism to communicate between the ocaml thread and the objc gui thread. For (2) the best solution that comes to mind is to allocate a buffer in objc, allocate a mutex in objc, and lock the mutex in ocaml or objc as needed to mediate access to the buffer, and communicate using the buffer by some messages in some format. -Trevor From hari.peddi at ge.com Tue Jan 23 20:19:35 2007 From: hari.peddi at ge.com (Peddi, Hari (GE Infra, Energy, Non-GE)) Date: Wed, 24 Jan 2007 06:49:35 +0530 Subject: [Unison-hackers] Is this possible to have Unison not delete any files and to add only new files and modify the files...while synchronizing the files... References: Message-ID: Hi all, Is this possible to have Unison not delete any files and to add only new files and modify the files...while synchronizing the files...we need unison to have this behaviour in one of our applications. You can give any inputs in this direction or suggest me if this is not the way unison should work. Regards Hari From bcpierce at cis.upenn.edu Wed Jan 24 10:54:08 2007 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Wed, 24 Jan 2007 10:54:08 -0500 Subject: [Unison-hackers] Is this possible to have Unison not delete any files and to add only new files and modify the files...while synchronizing the files... In-Reply-To: References: Message-ID: This would be a useful behavior, but it's not implemented at the moment. If someone wanted to take a crack it it, it should not be too hard -- one would modify the same function that handles -prefer and -force. - Benjamin On Jan 23, 2007, at 8:19 PM, Peddi, Hari ((GE Infra, Energy, Non-GE)) wrote: > Hi all, > Is this possible to have Unison not delete any files and to add > only new > files and modify the files...while synchronizing the files...we need > unison to have this behaviour in one of our applications. > You can give any inputs in this direction or suggest me if this is not > the way unison should work. > > Regards > Hari > _______________________________________________ > 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 Wed Jan 24 12:35:38 2007 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Wed, 24 Jan 2007 12:35:38 -0500 Subject: [Unison-hackers] About the current OS X GUI hanging In-Reply-To: <45B670FA.3070009@research.att.com> References: <262D4085-A7D2-49BB-A520-5D26BCAE74C0@cis.upenn.edu> <45B670FA.3070009@research.att.com> Message-ID: Another thing to think about is whether these calls from the GUI into OCaml while an OCaml thread is already running are really needed -- it may be that they are just looking up little bits of information that could just as easily be pre-fetched into C data structures in the main thread... - B On Jan 23, 2007, at 3:32 PM, Trevor Jim wrote: >> - GUI thread calls OCaml to process a transfer instruction >> (grabbing the lock) >> - OCaml calls back to GUI to update the "done" information >> - GUI thread needs to look up some bit of information from the >> OCaml data structure to know how to update the screen, so it tries to >> call back into OCaml, but now gets stuck because the lock is already >> held > > There are two issues, first is deadlock/starvation, second is > crashing. > > I think we crash because two objc threads call in to ocaml at the same > time. We need more locking, as I indicated in my previous messages. > > More locking of course will only increase the deadlock/starvation > problems. Stepping back, what is going on is that while the ocaml > thread is running, the gui would like to be responsive, so there > should be communication between the ocaml thread and an objc gui > thread. This communication **cannot** occur via the usual ocaml > C API, that's simply not allowed because of ocaml internal reasons. > Therefore simply adding reentrant locks or more locks (rather than > the one lock we have now) is not sufficient to handle the gui > responsiveness issue. > > Therefore we need two things: > (1) More locking, so that there is only one call from objc through > the ocaml C API at any given time > (2) A different mechanism to communicate between the ocaml thread > and the objc gui thread. > > For (2) the best solution that comes to mind is to allocate a buffer > in objc, allocate a mutex in objc, and lock the mutex in ocaml or > objc as needed to mediate access to the buffer, and communicate > using the buffer by some messages in some format. > > -Trevor > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From ralph-lehmann at gmx.net Wed Jan 24 14:12:50 2007 From: ralph-lehmann at gmx.net (Ralph Lehmann) Date: Wed, 24 Jan 2007 20:12:50 +0100 Subject: [Unison-hackers] Is this possible to have Unison not delete any files and to add only new files and modify the files...while synchronizing the files... In-Reply-To: References: Message-ID: <45B7AFB2.4070106@gmx.net> Benjamin Pierce schrieb: > This would be a useful behavior, but it's not implemented at the > moment. If someone wanted to take a crack it it, it should not be > too hard -- one would modify the same function that handles -prefer > and -force. How about "force newer"? :-) ciao Ralph From bcpierce at cis.upenn.edu Wed Jan 24 12:35:38 2007 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Wed, 24 Jan 2007 12:35:38 -0500 Subject: [Unison-hackers] About the current OS X GUI hanging In-Reply-To: <45B670FA.3070009@research.att.com> References: <262D4085-A7D2-49BB-A520-5D26BCAE74C0@cis.upenn.edu> <45B670FA.3070009@research.att.com> Message-ID: Another thing to think about is whether these calls from the GUI into OCaml while an OCaml thread is already running are really needed -- it may be that they are just looking up little bits of information that could just as easily be pre-fetched into C data structures in the main thread... - B On Jan 23, 2007, at 3:32 PM, Trevor Jim wrote: >> - GUI thread calls OCaml to process a transfer instruction >> (grabbing the lock) >> - OCaml calls back to GUI to update the "done" information >> - GUI thread needs to look up some bit of information from the >> OCaml data structure to know how to update the screen, so it tries to >> call back into OCaml, but now gets stuck because the lock is already >> held > > There are two issues, first is deadlock/starvation, second is > crashing. > > I think we crash because two objc threads call in to ocaml at the same > time. We need more locking, as I indicated in my previous messages. > > More locking of course will only increase the deadlock/starvation > problems. Stepping back, what is going on is that while the ocaml > thread is running, the gui would like to be responsive, so there > should be communication between the ocaml thread and an objc gui > thread. This communication **cannot** occur via the usual ocaml > C API, that's simply not allowed because of ocaml internal reasons. > Therefore simply adding reentrant locks or more locks (rather than > the one lock we have now) is not sufficient to handle the gui > responsiveness issue. > > Therefore we need two things: > (1) More locking, so that there is only one call from objc through > the ocaml C API at any given time > (2) A different mechanism to communicate between the ocaml thread > and the objc gui thread. > > For (2) the best solution that comes to mind is to allocate a buffer > in objc, allocate a mutex in objc, and lock the mutex in ocaml or > objc as needed to mediate access to the buffer, and communicate > using the buffer by some messages in some format. > > -Trevor > _______________________________________________ > 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 Wed Jan 24 12:35:38 2007 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Wed, 24 Jan 2007 12:35:38 -0500 Subject: [Unison-hackers] About the current OS X GUI hanging In-Reply-To: <45B670FA.3070009@research.att.com> References: <262D4085-A7D2-49BB-A520-5D26BCAE74C0@cis.upenn.edu> <45B670FA.3070009@research.att.com> Message-ID: Another thing to think about is whether these calls from the GUI into OCaml while an OCaml thread is already running are really needed -- it may be that they are just looking up little bits of information that could just as easily be pre-fetched into C data structures in the main thread... - B On Jan 23, 2007, at 3:32 PM, Trevor Jim wrote: >> - GUI thread calls OCaml to process a transfer instruction >> (grabbing the lock) >> - OCaml calls back to GUI to update the "done" information >> - GUI thread needs to look up some bit of information from the >> OCaml data structure to know how to update the screen, so it tries to >> call back into OCaml, but now gets stuck because the lock is already >> held > > There are two issues, first is deadlock/starvation, second is > crashing. > > I think we crash because two objc threads call in to ocaml at the same > time. We need more locking, as I indicated in my previous messages. > > More locking of course will only increase the deadlock/starvation > problems. Stepping back, what is going on is that while the ocaml > thread is running, the gui would like to be responsive, so there > should be communication between the ocaml thread and an objc gui > thread. This communication **cannot** occur via the usual ocaml > C API, that's simply not allowed because of ocaml internal reasons. > Therefore simply adding reentrant locks or more locks (rather than > the one lock we have now) is not sufficient to handle the gui > responsiveness issue. > > Therefore we need two things: > (1) More locking, so that there is only one call from objc through > the ocaml C API at any given time > (2) A different mechanism to communicate between the ocaml thread > and the objc gui thread. > > For (2) the best solution that comes to mind is to allocate a buffer > in objc, allocate a mutex in objc, and lock the mutex in ocaml or > objc as needed to mediate access to the buffer, and communicate > using the buffer by some messages in some format. > > -Trevor > _______________________________________________ > 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 Wed Jan 24 15:25:54 2007 From: trevor at research.att.com (Trevor Jim) Date: Wed, 24 Jan 2007 15:25:54 -0500 Subject: [Unison-hackers] About the current OS X GUI hanging In-Reply-To: References: <262D4085-A7D2-49BB-A520-5D26BCAE74C0@cis.upenn.edu> <45B670FA.3070009@research.att.com> Message-ID: <45B7C0D2.10001@research.att.com> Right. Since Ben wrote the code I was hoping he'd chip in with a spec about what it is doing, in the absence of that we'll have to reverse engineer. I guess that it is not sufficient to pre-fetch, though, we want to report on the state of the transfer (% finished, etc.). -Trevor Benjamin Pierce wrote: > Another thing to think about is whether these calls from the GUI into > OCaml while an OCaml thread is already running are really needed -- > it may be that they are just looking up little bits of information > that could just as easily be pre-fetched into C data structures in > the main thread... From bcpierce at cis.upenn.edu Fri Jan 26 22:01:25 2007 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Fri, 26 Jan 2007 22:01:25 -0500 Subject: [Unison-hackers] [unison-svn] r203 - trunk/src Message-ID: <200701270301.l0R31PF3008460@canfield.cis.upenn.edu> Author: bcpierce Date: 2007-01-26 22:01:24 -0500 (Fri, 26 Jan 2007) New Revision: 203 Modified: trunk/src/RECENTNEWS trunk/src/mkProjectInfo.ml trunk/src/uigtk2.ml Log: * Incorporated a patch from Karl M. that clears the main window in the GTK2 UI when update detection is restarted. From alan.schmitt at polytechnique.org Tue Jan 30 11:37:12 2007 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Tue, 30 Jan 2007 17:37:12 +0100 Subject: [Unison-hackers] Unison to be used in Portal? Message-ID: <5E00486B-053C-4CD6-A97F-F2ED2373D6CD@polytechnique.org> I just found this: http://mydreamapp.com/news/post/379/ I had posted about Unison in this forum during the contest, but I was not expecting them to use it. 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: This is a digitally signed message part Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20070130/aab403cc/PGP.sig