Discussions forum for users of the Unison file synchronization tool

Josh Berdine | 27 May 2012 20:32

Re: fsmonitor.py high CPU load?

This watch feature of unison is very interesting, so I have been playing with it a bit.

I am also seeing this CPU behavior.  As a small test I set up two local directories on a windows machine and
executed "unison test1 test2 -repeat watch".  Files get correctly synced between the test1 and test2
directories.  While unison is running, there are two python processes consuming one core each, and when
unison is terminated, they survive and continue to consume a core each.  I have also tested syncing between
machines over ssh, and the behavior is similar except that there is only a single run-away python per
windows machine.

For the record, I'm using python 2.7.2 msvc and pywin32-217, unison r480, ocaml 3.12.1, windows 7.

I'm not much of a python programmer, so haven't made any progress on diagnosing what the cause is, but in case
another report is helpful...

FYI, I also had to change uitext.ml slightly to get things working on my system:

--- uitext.ml	(revision 480)
+++ uitext.ml	(working copy)
 <at>  <at>  -723,7 +723,9  <at>  <at> 
let paths = Safelist.map Path.toString !originalValueOfPathsPreference in
let followpaths = Pred.extern Path.followPred in
let follow = Safelist.map (fun s -> "--follow '"^s^"'") followpaths in
-  let cmd = Printf.sprintf "fsmonitor.py %s --outfile %s --statefile %s %s %s\n"
+  let fsmonfile = Filename.concat (Filename.dirname Sys.executable_name) "fsmonitor.py" in
+  let cmd = Printf.sprintf "python \"%s\" \"%s\" --outfile \"%s\" --statefile \"%s\" %s %s\n"
+              fsmonfile
            root
            (System.fspathToPrintString changefile)
            (System.fspathToPrintString statefile)

(Continue reading)

headers

swiind | 7 Jun 2012 07:07

Re: fsmonitor.py high CPU load?


This seems to be an easy fix.
In fsmonitor.py change:
from time import time
to
from time import time, sleep

Then add sleep(1) to the end of the while 1 block beneath def win32watcherThread.

I also put a sleep(1) in the other loop below, in def win32watcher.

In fact it's also quite annoying how python.exe doesn't terminate when Unison does, so I tweaked that whole
main loop in win32watcher:

        me = psutil.Process(os.getpid())
        try:
            while 1:
                unison = me.parent.parent
                if unison is None:
                    sys.exit()
                sleep(1)

This particular bit requires installing psutil though, and putting 'import psutil' at the top. I looked
for a solution that didn't require a dependency... but I didn't look very hard.

Unfortunately I discovered a major flaw after getting this going myself. fsmonitor.py is passed all the
correct parameters on the initiating side (I inspect Python.exe with Process Explorer), but when
fsmonitor.py is automatically launched on the other side none of the paths normally at the end of the
argument list are passed. The consequences are one-sided monitoring, and/or maybe worse things... I
thought I saw files in the root (instead of specified paths) being synced but I could be mistaken.

(Continue reading)

headers

Benjamin C. Pierce | 10 Jun 2012 16:33

Re: fsmonitor.py high CPU load?

Thanks for this -- very useful.  Could you drop me a copy of your whole fsmonitor.py?  

> Unfortunately I discovered a major flaw after getting this going myself. fsmonitor.py is passed all the
correct parameters on the initiating side (I inspect Python.exe with Process Explorer), but when
fsmonitor.py is automatically launched on the other side none of the paths normally at the end of the
argument list are passed. The consequences are one-sided monitoring, and/or maybe worse things... I
thought I saw files in the root (instead of specified paths) being synced but I could be mistaken.

This is surprising: the initiating process should be sending the settings of the preferences across to the
server process as part of the startup sequence, so the server should have all the correct paths.  All the
code for this is in uitext.ml -- the function suckOnFileWatcherLocal is what gets run on each side
whenever Unison is ready to process new change notifications (it starts the fsmonitor.py process if
necessary), and this gets called ultimately from the function 'start' at the bottom of the file; before
this happens, however, the start function calls Uicommon.uiInit, which calls (some functions that
call) Globals.propagatePrefs, which does the propagation of preferences.

Best way to proceed is probably to add some printing in some of these places to verify what's happening when
(in particular, to see what the preferences actually look like on the server when the fsmonitor process is
created).  If you're up for trying this, I'm happy to answer questions.

    - Benjamin

On Jun 7, 2012, at 1:07 AM, swiind wrote:

> 
> 
> This seems to be an easy fix.
> In fsmonitor.py change:
> from time import time
> to

(Continue reading)

headers

Christopher Galpin | 10 Jun 2012 17:43

Re: fsmonitor.py high CPU load? [1 Attachment]

I'd be more than happy to, see attached. Requires installing the psutil module.

I'd love to experiment with patching this on Unison's side, except I have quite the problem, I don't know how to compile Unison fornative win32, which is what fsmonitor.py is currently tailored for.

All of the instructions online and on this group seem to be for compiling Unison for cygwin on win32 (even if they imply it's native), which is not the same thing, the paths are different and so forth. (It's easy for me to spot the difference because the native binary has an icon, and the unison folder is in %UserProfile%\.unison (C:\Users\Chris\.unison on my Win7 machine), rather than C:\cygwin\home\Chris as it is with the cygwin build.

I can compile it for cygwin very easily, with cygwin's ocaml and no fuss whatsoever by running 'make UISTYLE=text' in a cygwin terminal.

To compile for native win32, I followed the instructions in INSTALL.win32-msvc and although the prerequisites are different, I don't quite see how performing 'make UISTYLE=text' from a cygwin terminal is any different from the exact same step used to compile it for cygwin. The only real difference seems to be the version of ocaml - perhaps that's the ticket or maybe there's something more. I installed a win32 native version of ocaml as per the instructions, and put it before cygwin's in my PATH so the correct one would be called (and it is) but I encounter an error.

Specifically:

File "mkProjectInfo.ml", line 48, characters 2-14:

Unbound value Scanf.sscanf

I see this error referenced on the group but the only solution given is to go about compiling for cygwin instead of native win32 by using cygwin's ocaml, and that's not useful.

And truthfully I don't see where the setup I did for Visual C++ or MASM32 from the INSTALL.win32-msvc instructions are entering at all. Perhaps my procedure is wrong and thus the error is irrelevant anyways.

Bottom line, I'm lost with compiling it for native win32.

Truth is I could probably code fsmonitor.py to work for the cygwin version, as I made some headway weeks ago, but I'm not ready for that route yet.

Addendum: I'm corresponding with someone seeking Unicode support for fsmonitor.py (Turkish file & folder names) and this doesn't seem very difficult to implement with Python so I may have some more additions to fsmonitor.py soon.

Ugh pardon duplicate emails, used wrong email address.

On Sun, Jun 10, 2012 at 8:33 AM, Benjamin C. Pierce <bcpierce <at> cis.upenn.edu> wrote:

Thanks for this -- very useful. Could you drop me a copy of your whole fsmonitor.py?

> Unfortunately I discovered a major flaw after getting this going myself. fsmonitor.py is passed all the correct parameters on the initiating side (I inspect Python.exe with Process Explorer), but when fsmonitor.py is automatically launched on the other side none of the paths normally at the end of the argument list are passed. The consequences are one-sided monitoring, and/or maybe worse things... I thought I saw files in the root (instead of specified paths) being synced but I could be mistaken.

This is surprising: the initiating process should be sending the settings of the preferences across to the server process as part of the startup sequence, so the server should have all the correct paths. All the code for this is in uitext.ml -- the function suckOnFileWatcherLocal is what gets run on each side whenever Unison is ready to process new change notifications (it starts the fsmonitor.py process if necessary), and this gets called ultimately from the function 'start' at the bottom of the file; before this happens, however, the start function calls Uicommon.uiInit, which calls (some functions that call) Globals.propagatePrefs, which does the propagation of preferences.

Best way to proceed is probably to add some printing in some of these places to verify what's happening when (in particular, to see what the preferences actually look like on the server when the fsmonitor process is created). If you're up for trying this, I'm happy to answer questions.

- Benjamin

On Jun 7, 2012, at 1:07 AM, swiind wrote:

>
>
> This seems to be an easy fix.
> In fsmonitor.py change:
> from time import time
> to
> from time import time, sleep
>
> Then add sleep(1) to the end of the while 1 block beneath def win32watcherThread.
>
> I also put a sleep(1) in the other loop below, in def win32watcher.
>
>
> In fact it's also quite annoying how python.exe doesn't terminate when Unison does, so I tweaked that whole main loop in win32watcher:
>
> me = psutil.Process(os.getpid())
> try:
> while 1:
> unison = me.parent.parent
> if unison is None:
> sys.exit()
> sleep(1)
>
> This particular bit requires installing psutil though, and putting 'import psutil' at the top. I looked for a solution that didn't require a dependency... but I didn't look very hard.
>
>
>
> Unfortunately I discovered a major flaw after getting this going myself. fsmonitor.py is passed all the correct parameters on the initiating side (I inspect Python.exe with Process Explorer), but when fsmonitor.py is automatically launched on the other side none of the paths normally at the end of the argument list are passed. The consequences are one-sided monitoring, and/or maybe worse things... I thought I saw files in the root (instead of specified paths) being synced but I could be mistaken.
>
> At least with syncing entire roots it works beautifully. It seems like patching this might take modifying Unison rather than fsmonitor.py. I'm not experienced there, just with Python.
>
>
>
> --- In unison-users <at> yahoogroups.com, Josh Berdine <jjb <at> ...> wrote:
>>
>> This watch feature of unison is very interesting, so I have been playing with it a bit.
>>
>> I am also seeing this CPU behavior. As a small test I set up two local directories on a windows machine and executed "unison test1 test2 -repeat watch". Files get correctly synced between the test1 and test2 directories. While unison is running, there are two python processes consuming one core each, and when unison is terminated, they survive and continue to consume a core each. I have also tested syncing between machines over ssh, and the behavior is similar except that there is only a single run-away python per windows machine.
>>
>> For the record, I'm using python 2.7.2 msvc and pywin32-217, unison r480, ocaml 3.12.1, windows 7.
>>
>> I'm not much of a python programmer, so haven't made any progress on diagnosing what the cause is, but in case another report is helpful...
>>
>> FYI, I also had to change uitext.ml slightly to get things working on my system:
>>
>> --- uitext.ml (revision 480)
>> +++ uitext.ml (working copy)
>> <at> <at> -723,7 +723,9 <at> <at>
>> let paths = Safelist.map Path.toString !originalValueOfPathsPreference in
>> let followpaths = Pred.extern Path.followPred in
>> let follow = Safelist.map (fun s -> "--follow '"^s^"'") followpaths in
>> - let cmd = Printf.sprintf "fsmonitor.py %s --outfile %s --statefile %s %s %s\n"
>> + let fsmonfile = Filename.concat (Filename.dirname Sys.executable_name) "fsmonitor.py" in
>> + let cmd = Printf.sprintf "python \"%s\" \"%s\" --outfile \"%s\" --statefile \"%s\" %s %s\n"
>> + fsmonfile
>> root
>> (System.fspathToPrintString changefile)
>> (System.fspathToPrintString statefile)
>>
>> This quotes filenames to protect against spaces, but still does not work if fsmonitor.py has spaces in it's name. Also, this invokes python and passes fsmonitor.py to it since I can't seem to get windows to robustly associate .py with python.exe.
>>
>> Cheers, Josh
>>
>>
>> --- In unison-users <at> yahoogroups.com, "Benjamin C. Pierce" <bcpierce <at> > wrote:
>>>
>>> Yes, this sounds like it needs to be fixed. And it wouldn't be a surprise if fsmonitor.py were misbehaving -- it's one of the newest and least tested parts of Unison.
>>>
>>> But I'm a little confused by your message… this is happening when the "-repeat watch" flag is *not* set?
>>>
>>> - Benjamin
>>>
>>>
>>> On Feb 20, 2012, at 2:18 AM, Bill Gouveros wrote:
>>>
>>>>
>>>>
>>>> Hello, and congrats to B.Pierce and other contributors for this awesome piece of software that is Unison.
>>>>
>>>> I've been experimenting with setting up Unison 2.44.9 and its repeat watch functionality on a Windows 7 64bit machine. However, whenever I leave Unison running with repeat watch off, the python process corresponding to the fsmonitor.py script consumes the whole CPU core it's been assigned to. (So, on a 2-core CPU, that's 50% load) If another Unison process happens to fire off another instance of the fsmonitor.py script, another python process is spawned, consuming the other core. So, with 100% load, the PC is unusable and I have to kill the python processes to get it to stabilize. Has anyone else experienced such behavior?
>>>>
>>>> (I'm sorry for posting here, since it's probably a python problem, but I haven't been able to find a general complaint about python CPU usage. Suspecting there must be some fault with the fsmonitor.py script, and considering it's most extensive usage that I know of is by Unison, I thought I'd start tracking down the problem from this mailing list.)
>>>>
>>>> Thanks
>>>> Bill
>>>
>>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
> <*> To visit your group on the web, go to:
> http://groups.yahoo.com/group/unison-users/
>
> <*> Your email settings:
> Individual Email | Traditional
>
> <*> To change settings online go to:
> http://groups.yahoo.com/group/unison-users/join
> (Yahoo! ID required)
>
> <*> To change settings via email:
> unison-users-digest <at> yahoogroups.com
> unison-users-fullfeatured <at> yahoogroups.com
>
> <*> To unsubscribe from this group, send an email to:
> unison-users-unsubscribe <at> yahoogroups.com
>
> <*> Your use of Yahoo! Groups is subject to:
> http://docs.yahoo.com/info/terms/
>

Attachment(s) from Christopher Galpin

1 of 1 File(s)

fsmonitor.py

__._,_.___

Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___

headers

Benjamin C. Pierce | 19 Jun 2012 15:22

Re: fsmonitor.py high CPU load?

I'd be more than happy to, see attached.

Thanks.

Requires installing the psutil module.

I wonder how much of a problem this is for potential users. Is there a way to get the installation to happen automatically (e.g., by embedding a copy of psutil in fsmonitor.py to be used if none is provided), or at least to provide feedback that this is what is needed?

I'm not a windows compilation expert, so can't help with the rest -- maybe somebody on the list can advise. Is the only difficulty in mkProjectInfo? (If so, it should be easy to code around.)

- Benjamin

I'd love to experiment with patching this on Unison's side, except I have quite the problem, I don't know how to compile Unison fornative win32, which is what fsmonitor.py is currently tailored for.

All of the instructions online and on this group seem to be for compiling Unison for cygwin on win32 (even if they imply it's native), which is not the same thing, the paths are different and so forth. (It's easy for me to spot the difference because the native binary has an icon, and the unison folder is in %UserProfile%\.unison (C:\Users\Chris\.unison on my Win7 machine), rather than C:\cygwin\home\Chris as it is with the cygwin build.

I can compile it for cygwin very easily, with cygwin's ocaml and no fuss whatsoever by running 'make UISTYLE=text' in a cygwin terminal.

To compile for native win32, I followed the instructions in INSTALL.win32-msvc and although the prerequisites are different, I don't quite see how performing 'make UISTYLE=text' from a cygwin terminal is any different from the exact same step used to compile it for cygwin. The only real difference seems to be the version of ocaml - perhaps that's the ticket or maybe there's something more. I installed a win32 native version of ocaml as per the instructions, and put it before cygwin's in my PATH so the correct one would be called (and it is) but I encounter an error.

Specifically:

File "mkProjectInfo.ml", line 48, characters 2-14:

Unbound value Scanf.sscanf

I see this error referenced on the group but the only solution given is to go about compiling for cygwin instead of native win32 by using cygwin's ocaml, and that's not useful.

And truthfully I don't see where the setup I did for Visual C++ or MASM32 from the INSTALL.win32-msvc instructions are entering at all. Perhaps my procedure is wrong and thus the error is irrelevant anyways.

Bottom line, I'm lost with compiling it for native win32.

Truth is I could probably code fsmonitor.py to work for the cygwin version, as I made some headway weeks ago, but I'm not ready for that route yet.

Addendum: I'm corresponding with someone seeking Unicode support for fsmonitor.py (Turkish file & folder names) and this doesn't seem very difficult to implement with Python so I may have some more additions to fsmonitor.py soon.

Ugh pardon duplicate emails, used wrong email address.

On Sun, Jun 10, 2012 at 8:33 AM, Benjamin C. Pierce <bcpierce <at> cis.upenn.edu> wrote:
Thanks for this -- very useful. Could you drop me a copy of your whole fsmonitor.py?

> Unfortunately I discovered a major flaw after getting this going myself. fsmonitor.py is passed all the correct parameters on the initiating side (I inspect Python.exe with Process Explorer), but when fsmonitor.py is automatically launched on the other side none of the paths normally at the end of the argument list are passed. The consequences are one-sided monitoring, and/or maybe worse things... I thought I saw files in the root (instead of specified paths) being synced but I could be mistaken.

This is surprising: the initiating process should be sending the settings of the preferences across to the server process as part of the startup sequence, so the server should have all the correct paths. All the code for this is in uitext.ml -- the function suckOnFileWatcherLocal is what gets run on each side whenever Unison is ready to process new change notifications (it starts the fsmonitor.py process if necessary), and this gets called ultimately from the function 'start' at the bottom of the file; before this happens, however, the start function calls Uicommon.uiInit, which calls (some functions that call) Globals.propagatePrefs, which does the propagation of preferences.

Best way to proceed is probably to add some printing in some of these places to verify what's happening when (in particular, to see what the preferences actually look like on the server when the fsmonitor process is created). If you're up for trying this, I'm happy to answer questions.

- Benjamin

On Jun 7, 2012, at 1:07 AM, swiind wrote:

>
>
> This seems to be an easy fix.
> In fsmonitor.py change:
> from time import time
> to
> from time import time, sleep
>
> Then add sleep(1) to the end of the while 1 block beneath def win32watcherThread.
>
> I also put a sleep(1) in the other loop below, in def win32watcher.
>
>
> In fact it's also quite annoying how python.exe doesn't terminate when Unison does, so I tweaked that whole main loop in win32watcher:
>
> me = psutil.Process(os.getpid())
> try:
> while 1:
> unison = me.parent.parent
> if unison is None:
> sys.exit()
> sleep(1)
>
> This particular bit requires installing psutil though, and putting 'import psutil' at the top. I looked for a solution that didn't require a dependency... but I didn't look very hard.
>
>
>
> Unfortunately I discovered a major flaw after getting this going myself. fsmonitor.py is passed all the correct parameters on the initiating side (I inspect Python.exe with Process Explorer), but when fsmonitor.py is automatically launched on the other side none of the paths normally at the end of the argument list are passed. The consequences are one-sided monitoring, and/or maybe worse things... I thought I saw files in the root (instead of specified paths) being synced but I could be mistaken.
>
> At least with syncing entire roots it works beautifully. It seems like patching this might take modifying Unison rather than fsmonitor.py. I'm not experienced there, just with Python.
>
>
>
> --- In unison-users <at> yahoogroups.com, Josh Berdine <jjb <at> ...> wrote:
>>
>> This watch feature of unison is very interesting, so I have been playing with it a bit.
>>
>> I am also seeing this CPU behavior. As a small test I set up two local directories on a windows machine and executed "unison test1 test2 -repeat watch". Files get correctly synced between the test1 and test2 directories. While unison is running, there are two python processes consuming one core each, and when unison is terminated, they survive and continue to consume a core each. I have also tested syncing between machines over ssh, and the behavior is similar except that there is only a single run-away python per windows machine.
>>
>> For the record, I'm using python 2.7.2 msvc and pywin32-217, unison r480, ocaml 3.12.1, windows 7.
>>
>> I'm not much of a python programmer, so haven't made any progress on diagnosing what the cause is, but in case another report is helpful...
>>
>> FYI, I also had to change uitext.ml slightly to get things working on my system:
>>
>> --- uitext.ml (revision 480)
>> +++ uitext.ml (working copy)
>> <at> <at> -723,7 +723,9 <at> <at>
>> let paths = Safelist.map Path.toString !originalValueOfPathsPreference in
>> let followpaths = Pred.extern Path.followPred in
>> let follow = Safelist.map (fun s -> "--follow '"^s^"'") followpaths in
>> - let cmd = Printf.sprintf "fsmonitor.py %s --outfile %s --statefile %s %s %s\n"
>> + let fsmonfile = Filename.concat (Filename.dirname Sys.executable_name) "fsmonitor.py" in
>> + let cmd = Printf.sprintf "python \"%s\" \"%s\" --outfile \"%s\" --statefile \"%s\" %s %s\n"
>> + fsmonfile
>> root
>> (System.fspathToPrintString changefile)
>> (System.fspathToPrintString statefile)
>>
>> This quotes filenames to protect against spaces, but still does not work if fsmonitor.py has spaces in it's name. Also, this invokes python and passes fsmonitor.py to it since I can't seem to get windows to robustly associate .py with python.exe.
>>
>> Cheers, Josh
>>
>>
>> --- In unison-users <at> yahoogroups.com, "Benjamin C. Pierce" <bcpierce <at> > wrote:
>>>
>>> Yes, this sounds like it needs to be fixed. And it wouldn't be a surprise if fsmonitor.py were misbehaving -- it's one of the newest and least tested parts of Unison.
>>>
>>> But I'm a little confused by your message… this is happening when the "-repeat watch" flag is *not* set?
>>>
>>> - Benjamin
>>>
>>>
>>> On Feb 20, 2012, at 2:18 AM, Bill Gouveros wrote:
>>>
>>>>
>>>>
>>>> Hello, and congrats to B.Pierce and other contributors for this awesome piece of software that is Unison.
>>>>
>>>> I've been experimenting with setting up Unison 2.44.9 and its repeat watch functionality on a Windows 7 64bit machine. However, whenever I leave Unison running with repeat watch off, the python process corresponding to the fsmonitor.py script consumes the whole CPU core it's been assigned to. (So, on a 2-core CPU, that's 50% load) If another Unison process happens to fire off another instance of the fsmonitor.py script, another python process is spawned, consuming the other core. So, with 100% load, the PC is unusable and I have to kill the python processes to get it to stabilize. Has anyone else experienced such behavior?
>>>>
>>>> (I'm sorry for posting here, since it's probably a python problem, but I haven't been able to find a general complaint about python CPU usage. Suspecting there must be some fault with the fsmonitor.py script, and considering it's most extensive usage that I know of is by Unison, I thought I'd start tracking down the problem from this mailing list.)
>>>>
>>>> Thanks
>>>> Bill
>>>
>>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
> <*> To visit your group on the web, go to:
> http://groups.yahoo.com/group/unison-users/
>
> <*> Your email settings:
> Individual Email | Traditional
>
> <*> To change settings online go to:
> http://groups.yahoo.com/group/unison-users/join
> (Yahoo! ID required)
>
> <*> To change settings via email:
> unison-users-digest <at> yahoogroups.com
> unison-users-fullfeatured <at> yahoogroups.com
>
> <*> To unsubscribe from this group, send an email to:
> unison-users-unsubscribe <at> yahoogroups.com
>
> <*> Your use of Yahoo! Groups is subject to:
> http://docs.yahoo.com/info/terms/
>

<fsmonitor.py>

__._,_.___

__,_._,___

headers

Benjamin C. Pierce | 19 Jun 2012 15:25

Re: fsmonitor.py high CPU load?

I wonder how much of a problem this is for potential users. Is there a way to get the installation to happen automatically (e.g., by embedding a copy of psutil in fsmonitor.py to be used if none is provided), or at least to provide feedback that this is what is needed?

… or could the functionality that depends on psutil be made optional?

- Benjamin

I'm not a windows compilation expert, so can't help with the rest -- maybe somebody on the list can advise. Is the only difficulty in mkProjectInfo? (If so, it should be easy to code around.)

- Benjamin

I'd love to experiment with patching this on Unison's side, except I have quite the problem, I don't know how to compile Unison fornative win32, which is what fsmonitor.py is currently tailored for.

All of the instructions online and on this group seem to be for compiling Unison for cygwin on win32 (even if they imply it's native), which is not the same thing, the paths are different and so forth. (It's easy for me to spot the difference because the native binary has an icon, and the unison folder is in %UserProfile%\.unison (C:\Users\Chris\.unison on my Win7 machine), rather than C:\cygwin\home\Chris as it is with the cygwin build.

I can compile it for cygwin very easily, with cygwin's ocaml and no fuss whatsoever by running 'make UISTYLE=text' in a cygwin terminal.

To compile for native win32, I followed the instructions in INSTALL.win32-msvc and although the prerequisites are different, I don't quite see how performing 'make UISTYLE=text' from a cygwin terminal is any different from the exact same step used to compile it for cygwin. The only real difference seems to be the version of ocaml - perhaps that's the ticket or maybe there's something more. I installed a win32 native version of ocaml as per the instructions, and put it before cygwin's in my PATH so the correct one would be called (and it is) but I encounter an error.

Specifically:

File "mkProjectInfo.ml", line 48, characters 2-14:

Unbound value Scanf.sscanf

I see this error referenced on the group but the only solution given is to go about compiling for cygwin instead of native win32 by using cygwin's ocaml, and that's not useful.

And truthfully I don't see where the setup I did for Visual C++ or MASM32 from the INSTALL.win32-msvc instructions are entering at all. Perhaps my procedure is wrong and thus the error is irrelevant anyways.

Bottom line, I'm lost with compiling it for native win32.

Truth is I could probably code fsmonitor.py to work for the cygwin version, as I made some headway weeks ago, but I'm not ready for that route yet.

Addendum: I'm corresponding with someone seeking Unicode support for fsmonitor.py (Turkish file & folder names) and this doesn't seem very difficult to implement with Python so I may have some more additions to fsmonitor.py soon.

Ugh pardon duplicate emails, used wrong email address.

On Sun, Jun 10, 2012 at 8:33 AM, Benjamin C. Pierce <bcpierce <at> cis.upenn.edu> wrote:
Thanks for this -- very useful. Could you drop me a copy of your whole fsmonitor.py?

> Unfortunately I discovered a major flaw after getting this going myself. fsmonitor.py is passed all the correct parameters on the initiating side (I inspect Python.exe with Process Explorer), but when fsmonitor.py is automatically launched on the other side none of the paths normally at the end of the argument list are passed. The consequences are one-sided monitoring, and/or maybe worse things... I thought I saw files in the root (instead of specified paths) being synced but I could be mistaken.

This is surprising: the initiating process should be sending the settings of the preferences across to the server process as part of the startup sequence, so the server should have all the correct paths. All the code for this is in uitext.ml -- the function suckOnFileWatcherLocal is what gets run on each side whenever Unison is ready to process new change notifications (it starts the fsmonitor.py process if necessary), and this gets called ultimately from the function 'start' at the bottom of the file; before this happens, however, the start function calls Uicommon.uiInit, which calls (some functions that call) Globals.propagatePrefs, which does the propagation of preferences.

Best way to proceed is probably to add some printing in some of these places to verify what's happening when (in particular, to see what the preferences actually look like on the server when the fsmonitor process is created). If you're up for trying this, I'm happy to answer questions.

- Benjamin

On Jun 7, 2012, at 1:07 AM, swiind wrote:

>
>
> This seems to be an easy fix.
> In fsmonitor.py change:
> from time import time
> to
> from time import time, sleep
>
> Then add sleep(1) to the end of the while 1 block beneath def win32watcherThread.
>
> I also put a sleep(1) in the other loop below, in def win32watcher.
>
>
> In fact it's also quite annoying how python.exe doesn't terminate when Unison does, so I tweaked that whole main loop in win32watcher:
>
> me = psutil.Process(os.getpid())
> try:
> while 1:
> unison = me.parent.parent
> if unison is None:
> sys.exit()
> sleep(1)
>
> This particular bit requires installing psutil though, and putting 'import psutil' at the top. I looked for a solution that didn't require a dependency... but I didn't look very hard.
>
>
>
> Unfortunately I discovered a major flaw after getting this going myself. fsmonitor.py is passed all the correct parameters on the initiating side (I inspect Python.exe with Process Explorer), but when fsmonitor.py is automatically launched on the other side none of the paths normally at the end of the argument list are passed. The consequences are one-sided monitoring, and/or maybe worse things... I thought I saw files in the root (instead of specified paths) being synced but I could be mistaken.
>
> At least with syncing entire roots it works beautifully. It seems like patching this might take modifying Unison rather than fsmonitor.py. I'm not experienced there, just with Python.
>
>
>
> --- In unison-users <at> yahoogroups.com, Josh Berdine <jjb <at> ...> wrote:
>>
>> This watch feature of unison is very interesting, so I have been playing with it a bit.
>>
>> I am also seeing this CPU behavior. As a small test I set up two local directories on a windows machine and executed "unison test1 test2 -repeat watch". Files get correctly synced between the test1 and test2 directories. While unison is running, there are two python processes consuming one core each, and when unison is terminated, they survive and continue to consume a core each. I have also tested syncing between machines over ssh, and the behavior is similar except that there is only a single run-away python per windows machine.
>>
>> For the record, I'm using python 2.7.2 msvc and pywin32-217, unison r480, ocaml 3.12.1, windows 7.
>>
>> I'm not much of a python programmer, so haven't made any progress on diagnosing what the cause is, but in case another report is helpful...
>>
>> FYI, I also had to change uitext.ml slightly to get things working on my system:
>>
>> --- uitext.ml (revision 480)
>> +++ uitext.ml (working copy)
>> <at> <at> -723,7 +723,9 <at> <at>
>> let paths = Safelist.map Path.toString !originalValueOfPathsPreference in
>> let followpaths = Pred.extern Path.followPred in
>> let follow = Safelist.map (fun s -> "--follow '"^s^"'") followpaths in
>> - let cmd = Printf.sprintf "fsmonitor.py %s --outfile %s --statefile %s %s %s\n"
>> + let fsmonfile = Filename.concat (Filename.dirname Sys.executable_name) "fsmonitor.py" in
>> + let cmd = Printf.sprintf "python \"%s\" \"%s\" --outfile \"%s\" --statefile \"%s\" %s %s\n"
>> + fsmonfile
>> root
>> (System.fspathToPrintString changefile)
>> (System.fspathToPrintString statefile)
>>
>> This quotes filenames to protect against spaces, but still does not work if fsmonitor.py has spaces in it's name. Also, this invokes python and passes fsmonitor.py to it since I can't seem to get windows to robustly associate .py with python.exe.
>>
>> Cheers, Josh
>>
>>
>> --- In unison-users <at> yahoogroups.com, "Benjamin C. Pierce" <bcpierce <at> > wrote:
>>>
>>> Yes, this sounds like it needs to be fixed. And it wouldn't be a surprise if fsmonitor.py were misbehaving -- it's one of the newest and least tested parts of Unison.
>>>
>>> But I'm a little confused by your message… this is happening when the "-repeat watch" flag is *not* set?
>>>
>>> - Benjamin
>>>
>>>
>>> On Feb 20, 2012, at 2:18 AM, Bill Gouveros wrote:
>>>
>>>>
>>>>
>>>> Hello, and congrats to B.Pierce and other contributors for this awesome piece of software that is Unison.
>>>>
>>>> I've been experimenting with setting up Unison 2.44.9 and its repeat watch functionality on a Windows 7 64bit machine. However, whenever I leave Unison running with repeat watch off, the python process corresponding to the fsmonitor.py script consumes the whole CPU core it's been assigned to. (So, on a 2-core CPU, that's 50% load) If another Unison process happens to fire off another instance of the fsmonitor.py script, another python process is spawned, consuming the other core. So, with 100% load, the PC is unusable and I have to kill the python processes to get it to stabilize. Has anyone else experienced such behavior?
>>>>
>>>> (I'm sorry for posting here, since it's probably a python problem, but I haven't been able to find a general complaint about python CPU usage. Suspecting there must be some fault with the fsmonitor.py script, and considering it's most extensive usage that I know of is by Unison, I thought I'd start tracking down the problem from this mailing list.)
>>>>
>>>> Thanks
>>>> Bill
>>>
>>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
> <*> To visit your group on the web, go to:
> http://groups.yahoo.com/group/unison-users/
>
> <*> Your email settings:
> Individual Email | Traditional
>
> <*> To change settings online go to:
> http://groups.yahoo.com/group/unison-users/join
> (Yahoo! ID required)
>
> <*> To change settings via email:
> unison-users-digest <at> yahoogroups.com
> unison-users-fullfeatured <at> yahoogroups.com
>
> <*> To unsubscribe from this group, send an email to:
> unison-users-unsubscribe <at> yahoogroups.com
>
> <*> Your use of Yahoo! Groups is subject to:
> http://docs.yahoo.com/info/terms/
>

<fsmonitor.py>

__._,_.___

__,_._,___

headers

Tomasz Zernicki | 20 Jun 2012 18:44

Re: fsmonitor.py high CPU load?

Dnia Sun, 10 Jun 2012 17:43:33 +0200, Christopher Galpin  
<unison <at> swin.oib.com> napisał:

[...]
> And truthfully I don't see where the setup I did for Visual C++ or MASM32
> from the INSTALL.win32-msvc instructions are entering at all. Perhaps my
> procedure is wrong and thus the error is irrelevant anyways.
>
> Bottom line, I'm lost with compiling it for *native *win32.
[...]

Here is a procedure of compiling 'native' win32 unison version on windows  
which works for me.
Follow the instructions in INSTALL.win32-msvc with these exceptions:
- install Visual C++ Express Edition
- open Visual Studio Command Prompt
- enter: make UISTYLE=text NATIVE=false OSARCH=win32

the last option "OSARCH=win32" is very important and it is not included in  
INSTALL.win32-msvc file. Perhaps such file/manual should be updated?

I hope that this will work for you.

Regards,
Tomasz

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/unison-users/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/unison-users/join
    (Yahoo! ID required)

<*> To change settings via email:
    unison-users-digest <at> yahoogroups.com 
    unison-users-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    unison-users-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

headers

Pierce Benjamin C. | 20 Jun 2012 19:38

Re: fsmonitor.py high CPU load?

>> Here is a procedure of compiling 'native' win32 unison version on windows which works for me.
> Follow the instructions in INSTALL.win32-msvc with these exceptions:
> - install Visual C++ Express Edition
> - open Visual Studio Command Prompt
> - enter: make UISTYLE=text NATIVE=false OSARCH=win32
> 
> the last option "OSARCH=win32" is very important and it is not included in INSTALL.win32-msvc file.
Perhaps such file/manual should be updated?

I'd be happy to replace the current version by a corrected one!  Perhaps you can send me the whole file,
including whatever corrections you found you needed?

   - Benjamin

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/unison-users/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/unison-users/join
    (Yahoo! ID required)

<*> To change settings via email:
    unison-users-digest <at> yahoogroups.com 
    unison-users-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    unison-users-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

headers

swiind | 30 Jul 2012 04:34

Re: fsmonitor.py high CPU load?


Unfortunately: 

C:\cygwin\home\Chris\unison-2.45.4>make UISTYLE=text NATIVE=false OSARCH=win32
TAIL: lseeki64() failed 22
I/O error: Invalid argument
Fatal error: exception Sys_error("Invalid argument")
TAIL: lseeki64() failed 22
ocamlc -o mkProjectInfo unix.cma str.cma mkProjectInfo.ml
File "mkProjectInfo.ml", line 48, characters 2-14:
Unbound value Scanf.sscanf
UISTYLE = text
Building for Windows
NATIVE = false
THREADS = false
STATIC = false
OSTYPE =
OSARCH = win32
ocamlc: ubase/rx.mli ---> ubase/rx.cmi
ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/rx.mli
ocamlc: ubase/rx.ml ---> ubase/rx.cmo
ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/rx.ml
ocamlc: unicode_tables.ml ---> unicode_tables.cmo
ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./unicode_tables.ml
ocamlc: unicode.mli ---> unicode.cmi
ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./unicode.mli
ocamlc: unicode.ml ---> unicode.cmo
ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./unicode.ml
File "./unicode.ml", line 1858, characters 5-6:
Syntax error
Makefile.OCaml:411: recipe for target `unicode.cmo' failed
make: *** [unicode.cmo] Error 2

C:\cygwin\home\Chris\unison-2.45.4>ocamlc -v
The Objective Caml compiler, version 3.04
Standard library directory: C:\Program Files\Objective Caml\lib

--- In unison-users <at> yahoogroups.com, "Tomasz Zernicki" <tzernicki <at> ...> wrote:
>
> Dnia Sun, 10 Jun 2012 17:43:33 +0200, Christopher Galpin  
> <unison <at> ...> napisaÅ:
> 
> [...]
> > And truthfully I don't see where the setup I did for Visual C++ or MASM32
> > from the INSTALL.win32-msvc instructions are entering at all. Perhaps my
> > procedure is wrong and thus the error is irrelevant anyways.
> >
> > Bottom line, I'm lost with compiling it for *native *win32.
> [...]
> 
> Here is a procedure of compiling 'native' win32 unison version on windows  
> which works for me.
> Follow the instructions in INSTALL.win32-msvc with these exceptions:
> - install Visual C++ Express Edition
> - open Visual Studio Command Prompt
> - enter: make UISTYLE=text NATIVE=false OSARCH=win32
> 
> the last option "OSARCH=win32" is very important and it is not included in  
> INSTALL.win32-msvc file. Perhaps such file/manual should be updated?
> 
> I hope that this will work for you.
> 
> Regards,
> Tomasz
>

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/unison-users/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/unison-users/join
    (Yahoo! ID required)

<*> To change settings via email:
    unison-users-digest <at> yahoogroups.com 
    unison-users-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    unison-users-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

headers

Alan Schmitt | 1 Aug 2012 10:00

Re: Re: fsmonitor.py high CPU load?

"swiind" <unison <at> swin.oib.com> writes:

> C:\cygwin\home\Chris\unison-2.45.4>ocamlc -v
> The Objective Caml compiler, version 3.04
> Standard library directory: C:\Program Files\Objective Caml\lib

Ocaml 3.04 is almost 10 years old. You might have better luck with a
more recent version.

Alan

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/unison-users/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/unison-users/join
    (Yahoo! ID required)

<*> To change settings via email:
    unison-users-digest <at> yahoogroups.com 
    unison-users-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    unison-users-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

headers

Christopher Galpin | 1 Aug 2012 11:20

Re: Re: fsmonitor.py high CPU load?

Good suggestion. I fair worse with 4.00.0 I'm afraid:

C:\cygwin\home\Chris\unison-2.45.4>make UISTYLE=text NATIVE=false OSARCH=win32

TAIL: lseeki64() failed 22

ocamlc -o mkProjectInfo unix.cma str.cma mkProjectInfo.ml

./mkProjectInfo > Makefile.ProjectInfo

TAIL: lseeki64() failed 22

UISTYLE = text

Building for Windows

NATIVE = false

THREADS = false

STATIC = false

OSTYPE =

OSARCH = win32

ocamlc: unicode.ml ---> unicode.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./unicode.ml

File "./unicode.ml", line 1:

Error: unicode_tables.cmi

is not a compiled interface for this version of OCaml.

It seems to be for an older version of OCaml.

Makefile.OCaml:411: recipe for target `unicode.cmo' failed

make: *** [unicode.cmo] Error 2

C:\cygwin\home\Chris\unison-2.45.4>ocamlc -v

The OCaml compiler, version 4.00.0

Standard library directory: C:\OCaml\lib

I also tried 3.12.1, and I believe results were similar to my last post.

I'm tempted to load a virtual machine and try compiling in a clean environment but I haven't gotten there yet, was rather hoping someone would provide insight. I also don't believe my configuration is the culprit, but a clean environment wouldn't hurt. If I can get this to compile I'm going to fix the bug I experience on win32, patch up the win32 section of the Python monitoring script, and write up any special notes (if there are any) on building it on win32 so it can all be public.

On Wed, Aug 1, 2012 at 2:00 AM, Alan Schmitt <alan.schmitt <at> polytechnique.org> wrote:

"swiind" <unison <at> swin.oib.com> writes:

> C:\cygwin\home\Chris\unison-2.45.4>ocamlc -v
> The Objective Caml compiler, version 3.04
> Standard library directory: C:\Program Files\Objective Caml\lib

Ocaml 3.04 is almost 10 years old. You might have better luck with a
more recent version.

Alan

__._,_.___

__,_._,___

headers

Alan Schmitt | 1 Aug 2012 12:00

Re: Re: fsmonitor.py high CPU load?

Christopher Galpin <unison <at> swin.oib.com> writes:

> Good suggestion. I fair worse with 4.00.0 I'm afraid:

We haven't tested with 4.0 yet, so I'm not sure it's compatible.

> C:\cygwin\home\Chris\unison-2.45.4>make UISTYLE=text NATIVE=false
> OSARCH=win32
> TAIL: lseeki64() failed 22
> TAIL: lseeki64() failed 22
> ocamlc -o mkProjectInfo unix.cma str.cma mkProjectInfo.ml
> ./mkProjectInfo > Makefile.ProjectInfo
> TAIL: lseeki64() failed 22
> TAIL: lseeki64() failed 22
> UISTYLE = text
> Building for Windows
> NATIVE = false
> THREADS = false
> STATIC = false
> OSTYPE =
> OSARCH = win32
> ocamlc: unicode.ml ---> unicode.cmo
> ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g
> -c ./unicode.ml
> File "./unicode.ml", line 1:
> Error: unicode_tables.cmi
> is not a compiled interface for this version of OCaml.
> It seems to be for an older version of OCaml.
> Makefile.OCaml:411: recipe for target `unicode.cmo' failed
> make: *** [unicode.cmo] Error 2

Just to be sure: did you do a make clean first?

> I also tried 3.12.1, and I believe results were similar to my last
> post.

This is strange, it should definitely work there.

Alan

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/unison-users/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/unison-users/join
    (Yahoo! ID required)

<*> To change settings via email:
    unison-users-digest <at> yahoogroups.com 
    unison-users-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    unison-users-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

headers

Christopher Galpin | 1 Aug 2012 12:08

Re: Re: fsmonitor.py high CPU load?

Whoa good call. I'm relatively certain I did a 'make clean' when testing the previous versions, but just a moment ago trying 4.00.0 I hadn't.

But now I have. It went much further.

C:\cygwin\home\Chris\unison-2.45.4>make UISTYLE=text NATIVE=false OSARCH=win32 >

installlog.txt

TAIL: lseeki64() failed 22

File "./test.ml", line 373, characters 2-58:

Warning 21: this statement never returns (or has an unsound type.)

'i686-w64-mingw32-gcc' is not recognized as an internal or external command,

operable program or batch file.

make: *** [system/system_win_stubs.obj] Error 2

C:\cygwin\home\Chris\unison-2.45.4>ocamlc -v

The OCaml compiler, version 4.00.0

Standard library directory: C:\OCaml\lib

I dumped stdout to a text file this time as it was greater than the display buffer:

ocamlc -o mkProjectInfo unix.cma str.cma mkProjectInfo.ml

./mkProjectInfo > Makefile.ProjectInfo

UISTYLE = text

Building for Windows

NATIVE = false

THREADS = false

STATIC = false

OSTYPE =

OSARCH = win32

ocamlc: ubase/rx.mli ---> ubase/rx.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/rx.mli

ocamlc: ubase/rx.ml ---> ubase/rx.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/rx.ml

ocamlc: unicode_tables.ml ---> unicode_tables.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./unicode_tables.ml

ocamlc: unicode.mli ---> unicode.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./unicode.mli

ocamlc: unicode.ml ---> unicode.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./unicode.ml

ocamlc: bytearray.mli ---> bytearray.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./bytearray.mli

ocamlc: bytearray.ml ---> bytearray.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./bytearray.ml

ocamlc: system/system_generic.ml ---> system/system_generic.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./system/system_generic.ml

ocamlc: system/system_win.ml ---> system/system_win.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./system/system_win.ml

ocamlc: system/win/system_impl.ml ---> system/win/system_impl.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./system/win/system_impl.ml

ocamlc: system/system_intf.ml ---> system/system_intf.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./system/system_intf.ml

ocamlc: system.mli ---> system.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./system.mli

ocamlc: system.ml ---> system.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./system.ml

echo 'let myName = "'unison'";;' > ubase/projectInfo.ml

echo 'let myVersion = "'2.45.4'";;' >> ubase/projectInfo.ml

echo 'let myMajorVersion = "'2.45'";;' >> ubase/projectInfo.ml

ocamlc: ubase/projectInfo.ml ---> ubase/projectInfo.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/projectInfo.ml

ocamlc: ubase/myMap.mli ---> ubase/myMap.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/myMap.mli

ocamlc: ubase/myMap.ml ---> ubase/myMap.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/myMap.ml

ocamlc: ubase/safelist.mli ---> ubase/safelist.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/safelist.mli

ocamlc: ubase/safelist.ml ---> ubase/safelist.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/safelist.ml

ocamlc: ubase/uprintf.mli ---> ubase/uprintf.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/uprintf.mli

ocamlc: ubase/uprintf.ml ---> ubase/uprintf.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/uprintf.ml

ocamlc: ubase/util.mli ---> ubase/util.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/util.mli

ocamlc: ubase/util.ml ---> ubase/util.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/util.ml

ocamlc: ubase/uarg.mli ---> ubase/uarg.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/uarg.mli

ocamlc: ubase/uarg.ml ---> ubase/uarg.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/uarg.ml

ocamlc: ubase/prefs.mli ---> ubase/prefs.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/prefs.mli

ocamlc: ubase/prefs.ml ---> ubase/prefs.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/prefs.ml

ocamlc: ubase/trace.mli ---> ubase/trace.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/trace.mli

ocamlc: ubase/trace.ml ---> ubase/trace.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/trace.ml

ocamlc: ubase/proplist.mli ---> ubase/proplist.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/proplist.mli

ocamlc: ubase/proplist.ml ---> ubase/proplist.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/proplist.ml

ocamlc: lwt/pqueue.mli ---> lwt/pqueue.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lwt/pqueue.mli

ocamlc: lwt/pqueue.ml ---> lwt/pqueue.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lwt/pqueue.ml

ocamlc: lwt/lwt.mli ---> lwt/lwt.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lwt/lwt.mli

ocamlc: lwt/lwt.ml ---> lwt/lwt.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lwt/lwt.ml

ocamlc: lwt/lwt_util.mli ---> lwt/lwt_util.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lwt/lwt_util.mli

ocamlc: lwt/lwt_util.ml ---> lwt/lwt_util.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lwt/lwt_util.ml

ocamlc: lwt/win/lwt_unix_impl.ml ---> lwt/win/lwt_unix_impl.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lwt/win/lwt_unix_impl.ml

ocamlc: lwt/lwt_unix.mli ---> lwt/lwt_unix.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lwt/lwt_unix.mli

ocamlc: lwt/lwt_unix.ml ---> lwt/lwt_unix.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lwt/lwt_unix.ml

ocamlc: case.mli ---> case.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./case.mli

ocamlc: case.ml ---> case.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./case.ml

ocamlc: pred.mli ---> pred.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./pred.mli

ocamlc: pred.ml ---> pred.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./pred.ml

ocamlc: uutil.mli ---> uutil.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./uutil.mli

ocamlc: uutil.ml ---> uutil.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./uutil.ml

ocamlc: fileutil.mli ---> fileutil.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fileutil.mli

ocamlc: fileutil.ml ---> fileutil.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fileutil.ml

ocamlc: name.mli ---> name.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./name.mli

ocamlc: name.ml ---> name.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./name.ml

ocamlc: path.mli ---> path.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./path.mli

ocamlc: path.ml ---> path.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./path.ml

ocamlc: fspath.mli ---> fspath.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fspath.mli

ocamlc: fspath.ml ---> fspath.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fspath.ml

ocamlc: fs.mli ---> fs.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fs.mli

ocamlc: fs.ml ---> fs.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fs.ml

ocamlc: fingerprint.mli ---> fingerprint.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fingerprint.mli

ocamlc: fingerprint.ml ---> fingerprint.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fingerprint.ml

ocamlc: abort.mli ---> abort.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./abort.mli

ocamlc: abort.ml ---> abort.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./abort.ml

ocamlc: osx.mli ---> osx.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./osx.mli

ocamlc: osx.ml ---> osx.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./osx.ml

ocamlc: external.mli ---> external.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./external.mli

ocamlc: external.ml ---> external.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./external.ml

ocamlc: props.mli ---> props.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./props.mli

ocamlc: props.ml ---> props.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./props.ml

ocamlc: fileinfo.mli ---> fileinfo.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fileinfo.mli

ocamlc: fileinfo.ml ---> fileinfo.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fileinfo.ml

ocamlc: os.mli ---> os.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./os.mli

ocamlc: os.ml ---> os.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./os.ml

ocamlc: lock.mli ---> lock.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lock.mli

ocamlc: lock.ml ---> lock.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lock.ml

ocamlc: clroot.mli ---> clroot.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./clroot.mli

ocamlc: clroot.ml ---> clroot.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./clroot.ml

ocamlc: common.mli ---> common.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./common.mli

ocamlc: common.ml ---> common.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./common.ml

ocamlc: tree.mli ---> tree.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./tree.mli

ocamlc: tree.ml ---> tree.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./tree.ml

ocamlc: checksum.mli ---> checksum.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./checksum.mli

ocamlc: checksum.ml ---> checksum.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./checksum.ml

ocamlc: terminal.mli ---> terminal.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./terminal.mli

ocamlc: terminal.ml ---> terminal.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./terminal.ml

ocamlc: transfer.mli ---> transfer.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./transfer.mli

ocamlc: transfer.ml ---> transfer.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./transfer.ml

ocamlc: xferhint.mli ---> xferhint.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./xferhint.mli

ocamlc: xferhint.ml ---> xferhint.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./xferhint.ml

ocamlc: remote.mli ---> remote.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./remote.mli

ocamlc: remote.ml ---> remote.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./remote.ml

ocamlc: globals.mli ---> globals.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./globals.mli

ocamlc: globals.ml ---> globals.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./globals.ml

ocamlc: fpcache.mli ---> fpcache.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fpcache.mli

ocamlc: fpcache.ml ---> fpcache.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fpcache.ml

ocamlc: update.mli ---> update.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./update.mli

ocamlc: update.ml ---> update.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./update.ml

ocamlc: copy.mli ---> copy.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./copy.mli

ocamlc: copy.ml ---> copy.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./copy.ml

ocamlc: stasher.mli ---> stasher.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./stasher.mli

ocamlc: stasher.ml ---> stasher.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./stasher.ml

ocamlc: files.mli ---> files.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./files.mli

ocamlc: files.ml ---> files.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./files.ml

ocamlc: sortri.mli ---> sortri.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./sortri.mli

ocamlc: sortri.ml ---> sortri.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./sortri.ml

ocamlc: recon.mli ---> recon.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./recon.mli

ocamlc: recon.ml ---> recon.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./recon.ml

ocamlc: transport.mli ---> transport.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./transport.mli

ocamlc: transport.ml ---> transport.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./transport.ml

ocamlc: strings.mli ---> strings.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./strings.mli

ocamlc: strings.ml ---> strings.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./strings.ml

ocamlc: uicommon.mli ---> uicommon.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./uicommon.mli

ocamlc: uicommon.ml ---> uicommon.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./uicommon.ml

ocamlc: uitext.mli ---> uitext.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./uitext.mli

ocamlc: uitext.ml ---> uitext.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./uitext.ml

ocamlc: test.mli ---> test.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./test.mli

ocamlc: test.ml ---> test.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./test.ml

ocamlc: main.ml ---> main.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./main.ml

ocamlc: linktext.ml ---> linktext.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./linktext.ml

ocamlopt: system/system_win_stubs.c ---> system/system_win_stubs.obj

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -ccopt /Fo./system/system_win_stubs.obj -c ./system/system_win_stubs.c

Makefile.OCaml:419: recipe for target `system/system_win_stubs.obj' failed

I will now try 3.12.1 again, making sure to do a 'make clean' first.

On Wed, Aug 1, 2012 at 4:00 AM, Alan Schmitt <alan.schmitt <at> polytechnique.org> wrote:

Christopher Galpin <unison <at> swin.oib.com> writes:

> Good suggestion. I fair worse with 4.00.0 I'm afraid:

We haven't tested with 4.0 yet, so I'm not sure it's compatible.

> C:\cygwin\home\Chris\unison-2.45.4>make UISTYLE=text NATIVE=false
> OSARCH=win32
> TAIL: lseeki64() failed 22
> TAIL: lseeki64() failed 22
> ocamlc -o mkProjectInfo unix.cma str.cma mkProjectInfo.ml
> ./mkProjectInfo > Makefile.ProjectInfo
> TAIL: lseeki64() failed 22
> TAIL: lseeki64() failed 22
> UISTYLE = text
> Building for Windows
> NATIVE = false
> THREADS = false
> STATIC = false
> OSTYPE =
> OSARCH = win32
> ocamlc: unicode.ml ---> unicode.cmo
> ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g
> -c ./unicode.ml
> File "./unicode.ml", line 1:
> Error: unicode_tables.cmi
> is not a compiled interface for this version of OCaml.
> It seems to be for an older version of OCaml.
> Makefile.OCaml:411: recipe for target `unicode.cmo' failed
> make: *** [unicode.cmo] Error 2

Just to be sure: did you do a make clean first?

> I also tried 3.12.1, and I believe results were similar to my last
> post.

This is strange, it should definitely work there.

Alan

__._,_.___

__,_._,___

headers

Christopher Galpin | 1 Aug 2012 13:32

Re: Re: fsmonitor.py high CPU load?

So very close:

C:\cygwin\home\Chris\unison-2.45.4>make UISTYLE=text NATIVE=false OSARCH=win32 >

out.txt

TAIL: lseeki64() failed 22

File "_none_", line 1, characters 0-1:

Error: I/O error: Invalid argument

Fatal error: exception Sys_error("Invalid argument")

TAIL: lseeki64() failed 22

File "./test.ml", line 373, characters 2-58:

Warning 21: this statement never returns (or has an unsound type.)

Access is denied.

make: *** [system/system_win_stubs.obj] Error 2

C:\cygwin\home\Chris\unison-2.45.4>ocamlc -v

The Objective Caml compiler, version 3.12.1

Standard library directory: C:\Program Files (x86)\OCaml\lib

ocamlc -o mkProjectInfo unix.cma str.cma mkProjectInfo.ml

./mkProjectInfo > Makefile.ProjectInfo

UISTYLE = text

Building for Windows

NATIVE = false

THREADS = false

STATIC = false

OSTYPE =

OSARCH = win32

ocamlc: ubase/rx.mli ---> ubase/rx.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/rx.mli

ocamlc: ubase/rx.ml ---> ubase/rx.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/rx.ml

ocamlc: unicode_tables.ml ---> unicode_tables.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./unicode_tables.ml

ocamlc: unicode.mli ---> unicode.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./unicode.mli

ocamlc: unicode.ml ---> unicode.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./unicode.ml

ocamlc: bytearray.mli ---> bytearray.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./bytearray.mli

ocamlc: bytearray.ml ---> bytearray.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./bytearray.ml

ocamlc: system/system_generic.ml ---> system/system_generic.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./system/system_generic.ml

ocamlc: system/system_win.ml ---> system/system_win.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./system/system_win.ml

ocamlc: system/win/system_impl.ml ---> system/win/system_impl.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./system/win/system_impl.ml

ocamlc: system/system_intf.ml ---> system/system_intf.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./system/system_intf.ml

ocamlc: system.mli ---> system.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./system.mli

ocamlc: system.ml ---> system.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./system.ml

echo 'let myName = "'unison'";;' > ubase/projectInfo.ml

echo 'let myVersion = "'2.45.4'";;' >> ubase/projectInfo.ml

echo 'let myMajorVersion = "'2.45'";;' >> ubase/projectInfo.ml

ocamlc: ubase/projectInfo.ml ---> ubase/projectInfo.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/projectInfo.ml

ocamlc: ubase/myMap.mli ---> ubase/myMap.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/myMap.mli

ocamlc: ubase/myMap.ml ---> ubase/myMap.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/myMap.ml

ocamlc: ubase/safelist.mli ---> ubase/safelist.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/safelist.mli

ocamlc: ubase/safelist.ml ---> ubase/safelist.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/safelist.ml

ocamlc: ubase/uprintf.mli ---> ubase/uprintf.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/uprintf.mli

ocamlc: ubase/uprintf.ml ---> ubase/uprintf.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/uprintf.ml

ocamlc: ubase/util.mli ---> ubase/util.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/util.mli

ocamlc: ubase/util.ml ---> ubase/util.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/util.ml

ocamlc: ubase/uarg.mli ---> ubase/uarg.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/uarg.mli

ocamlc: ubase/uarg.ml ---> ubase/uarg.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/uarg.ml

ocamlc: ubase/prefs.mli ---> ubase/prefs.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/prefs.mli

ocamlc: ubase/prefs.ml ---> ubase/prefs.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/prefs.ml

ocamlc: ubase/trace.mli ---> ubase/trace.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/trace.mli

ocamlc: ubase/trace.ml ---> ubase/trace.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/trace.ml

ocamlc: ubase/proplist.mli ---> ubase/proplist.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/proplist.mli

ocamlc: ubase/proplist.ml ---> ubase/proplist.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/proplist.ml

ocamlc: lwt/pqueue.mli ---> lwt/pqueue.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lwt/pqueue.mli

ocamlc: lwt/pqueue.ml ---> lwt/pqueue.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lwt/pqueue.ml

ocamlc: lwt/lwt.mli ---> lwt/lwt.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lwt/lwt.mli

ocamlc: lwt/lwt.ml ---> lwt/lwt.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lwt/lwt.ml

ocamlc: lwt/lwt_util.mli ---> lwt/lwt_util.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lwt/lwt_util.mli

ocamlc: lwt/lwt_util.ml ---> lwt/lwt_util.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lwt/lwt_util.ml

ocamlc: lwt/win/lwt_unix_impl.ml ---> lwt/win/lwt_unix_impl.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lwt/win/lwt_unix_impl.ml

ocamlc: lwt/lwt_unix.mli ---> lwt/lwt_unix.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lwt/lwt_unix.mli

ocamlc: lwt/lwt_unix.ml ---> lwt/lwt_unix.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lwt/lwt_unix.ml

ocamlc: case.mli ---> case.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./case.mli

ocamlc: case.ml ---> case.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./case.ml

ocamlc: pred.mli ---> pred.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./pred.mli

ocamlc: pred.ml ---> pred.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./pred.ml

ocamlc: uutil.mli ---> uutil.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./uutil.mli

ocamlc: uutil.ml ---> uutil.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./uutil.ml

ocamlc: fileutil.mli ---> fileutil.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fileutil.mli

ocamlc: fileutil.ml ---> fileutil.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fileutil.ml

ocamlc: name.mli ---> name.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./name.mli

ocamlc: name.ml ---> name.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./name.ml

ocamlc: path.mli ---> path.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./path.mli

ocamlc: path.ml ---> path.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./path.ml

ocamlc: fspath.mli ---> fspath.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fspath.mli

ocamlc: fspath.ml ---> fspath.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fspath.ml

ocamlc: fs.mli ---> fs.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fs.mli

ocamlc: fs.ml ---> fs.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fs.ml

ocamlc: fingerprint.mli ---> fingerprint.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fingerprint.mli

ocamlc: fingerprint.ml ---> fingerprint.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fingerprint.ml

ocamlc: abort.mli ---> abort.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./abort.mli

ocamlc: abort.ml ---> abort.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./abort.ml

ocamlc: osx.mli ---> osx.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./osx.mli

ocamlc: osx.ml ---> osx.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./osx.ml

ocamlc: external.mli ---> external.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./external.mli

ocamlc: external.ml ---> external.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./external.ml

ocamlc: props.mli ---> props.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./props.mli

ocamlc: props.ml ---> props.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./props.ml

ocamlc: fileinfo.mli ---> fileinfo.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fileinfo.mli

ocamlc: fileinfo.ml ---> fileinfo.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fileinfo.ml

ocamlc: os.mli ---> os.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./os.mli

ocamlc: os.ml ---> os.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./os.ml

ocamlc: lock.mli ---> lock.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lock.mli

ocamlc: lock.ml ---> lock.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lock.ml

ocamlc: clroot.mli ---> clroot.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./clroot.mli

ocamlc: clroot.ml ---> clroot.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./clroot.ml

ocamlc: common.mli ---> common.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./common.mli

ocamlc: common.ml ---> common.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./common.ml

ocamlc: tree.mli ---> tree.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./tree.mli

ocamlc: tree.ml ---> tree.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./tree.ml

ocamlc: checksum.mli ---> checksum.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./checksum.mli

ocamlc: checksum.ml ---> checksum.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./checksum.ml

ocamlc: terminal.mli ---> terminal.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./terminal.mli

ocamlc: terminal.ml ---> terminal.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./terminal.ml

ocamlc: transfer.mli ---> transfer.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./transfer.mli

ocamlc: transfer.ml ---> transfer.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./transfer.ml

ocamlc: xferhint.mli ---> xferhint.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./xferhint.mli

ocamlc: xferhint.ml ---> xferhint.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./xferhint.ml

ocamlc: remote.mli ---> remote.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./remote.mli

ocamlc: remote.ml ---> remote.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./remote.ml

ocamlc: globals.mli ---> globals.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./globals.mli

ocamlc: globals.ml ---> globals.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./globals.ml

ocamlc: fpcache.mli ---> fpcache.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fpcache.mli

ocamlc: fpcache.ml ---> fpcache.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fpcache.ml

ocamlc: update.mli ---> update.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./update.mli

ocamlc: update.ml ---> update.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./update.ml

ocamlc: copy.mli ---> copy.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./copy.mli

ocamlc: copy.ml ---> copy.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./copy.ml

ocamlc: stasher.mli ---> stasher.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./stasher.mli

ocamlc: stasher.ml ---> stasher.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./stasher.ml

ocamlc: files.mli ---> files.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./files.mli

ocamlc: files.ml ---> files.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./files.ml

ocamlc: sortri.mli ---> sortri.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./sortri.mli

ocamlc: sortri.ml ---> sortri.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./sortri.ml

ocamlc: recon.mli ---> recon.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./recon.mli

ocamlc: recon.ml ---> recon.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./recon.ml

ocamlc: transport.mli ---> transport.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./transport.mli

ocamlc: transport.ml ---> transport.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./transport.ml

ocamlc: strings.mli ---> strings.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./strings.mli

ocamlc: strings.ml ---> strings.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./strings.ml

ocamlc: uicommon.mli ---> uicommon.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./uicommon.mli

ocamlc: uicommon.ml ---> uicommon.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./uicommon.ml

ocamlc: uitext.mli ---> uitext.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./uitext.mli

ocamlc: uitext.ml ---> uitext.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./uitext.ml

ocamlc: test.mli ---> test.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./test.mli

ocamlc: test.ml ---> test.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./test.ml

ocamlc: main.ml ---> main.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./main.ml

ocamlc: linktext.ml ---> linktext.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./linktext.ml

ocamlopt: system/system_win_stubs.c ---> system/system_win_stubs.obj

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -ccopt /Fo./system/system_win_stubs.obj -c ./system/system_win_stubs.c

Makefile.OCaml:419: recipe for target `system/system_win_stubs.obj' failed

"Access is denied." ? That's strange, so I check with Process Monitor and it's gcc.exe.

I check and for some reason Cygwin's gcc.exe symlink doesn't have execute permission.

After fixing that, instead of "Access Denied" my stderr looks like this:

C:\cygwin\home\Chris\unison-2.45.4>make UISTYLE=text NATIVE=false OSARCH=win32 >

out.txt

TAIL: lseeki64() failed 22

File "_none_", line 1, characters 0-1:

Error: I/O error: Invalid argument

Fatal error: exception Sys_error("Invalid argument")

This version of C:\cygwin\bin\gcc.exe is not compatible with the version of Wind

ows you're running. Check your computer's system information to see whether you

need a x86 (32-bit) or x64 (64-bit) version of the program, and then contact the

software publisher.

make: *** [system/system_win_stubs.obj] Error 2

I started down the road of working with gcc-mingw as per http://stackoverflow.com/questions/3776098/cygwin-how-to-actually-use-gcc-mingw

But then it occurred to me, isn't this where Visual Studio C++ Express Edition is supposed to step in, not Cygwin's gcc?

Isn't that why I'm running this from Visual Studio's command prompt with the variables in vcvars.bat set?

I'm too tired to keep at it... but I'm tenacious and experienced so we will get it eventually. The gears are turning but I need sleep.

On Wed, Aug 1, 2012 at 4:08 AM, Christopher Galpin <unison <at> swin.oib.com> wrote:

Whoa good call. I'm relatively certain I did a 'make clean' when testing the previous versions, but just a moment ago trying 4.00.0 I hadn't.
But now I have. It went much further.

C:\cygwin\home\Chris\unison-2.45.4>make UISTYLE=text NATIVE=false OSARCH=win32 >

installlog.txt

TAIL: lseeki64() failed 22

TAIL: lseeki64() failed 22

TAIL: lseeki64() failed 22

TAIL: lseeki64() failed 22

File "./test.ml", line 373, characters 2-58:

Warning 21: this statement never returns (or has an unsound type.)

'i686-w64-mingw32-gcc' is not recognized as an internal or external command,

operable program or batch file.

make: *** [system/system_win_stubs.obj] Error 2

C:\cygwin\home\Chris\unison-2.45.4>ocamlc -v

The OCaml compiler, version 4.00.0

Standard library directory: C:\OCaml\lib

I dumped stdout to a text file this time as it was greater than the display buffer:

ocamlc -o mkProjectInfo unix.cma str.cma mkProjectInfo.ml

./mkProjectInfo > Makefile.ProjectInfo

UISTYLE = text

Building for Windows

NATIVE = false

THREADS = false

STATIC = false

OSTYPE =

OSARCH = win32

ocamlc: ubase/rx.mli ---> ubase/rx.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/rx.mli

ocamlc: ubase/rx.ml ---> ubase/rx.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/rx.ml

ocamlc: unicode_tables.ml ---> unicode_tables.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./unicode_tables.ml

ocamlc: unicode.mli ---> unicode.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./unicode.mli

ocamlc: unicode.ml ---> unicode.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./unicode.ml

ocamlc: bytearray.mli ---> bytearray.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./bytearray.mli

ocamlc: bytearray.ml ---> bytearray.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./bytearray.ml

ocamlc: system/system_generic.ml ---> system/system_generic.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./system/system_generic.ml

ocamlc: system/system_win.ml ---> system/system_win.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./system/system_win.ml

ocamlc: system/win/system_impl.ml ---> system/win/system_impl.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./system/win/system_impl.ml

ocamlc: system/system_intf.ml ---> system/system_intf.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./system/system_intf.ml

ocamlc: system.mli ---> system.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./system.mli

ocamlc: system.ml ---> system.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./system.ml

echo 'let myName = "'unison'";;' > ubase/projectInfo.ml

echo 'let myVersion = "'2.45.4'";;' >> ubase/projectInfo.ml

echo 'let myMajorVersion = "'2.45'";;' >> ubase/projectInfo.ml

ocamlc: ubase/projectInfo.ml ---> ubase/projectInfo.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/projectInfo.ml

ocamlc: ubase/myMap.mli ---> ubase/myMap.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/myMap.mli

ocamlc: ubase/myMap.ml ---> ubase/myMap.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/myMap.ml

ocamlc: ubase/safelist.mli ---> ubase/safelist.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/safelist.mli

ocamlc: ubase/safelist.ml ---> ubase/safelist.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/safelist.ml

ocamlc: ubase/uprintf.mli ---> ubase/uprintf.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/uprintf.mli

ocamlc: ubase/uprintf.ml ---> ubase/uprintf.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/uprintf.ml

ocamlc: ubase/util.mli ---> ubase/util.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/util.mli

ocamlc: ubase/util.ml ---> ubase/util.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/util.ml

ocamlc: ubase/uarg.mli ---> ubase/uarg.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/uarg.mli

ocamlc: ubase/uarg.ml ---> ubase/uarg.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/uarg.ml

ocamlc: ubase/prefs.mli ---> ubase/prefs.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/prefs.mli

ocamlc: ubase/prefs.ml ---> ubase/prefs.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/prefs.ml

ocamlc: ubase/trace.mli ---> ubase/trace.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/trace.mli

ocamlc: ubase/trace.ml ---> ubase/trace.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/trace.ml

ocamlc: ubase/proplist.mli ---> ubase/proplist.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/proplist.mli

ocamlc: ubase/proplist.ml ---> ubase/proplist.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./ubase/proplist.ml

ocamlc: lwt/pqueue.mli ---> lwt/pqueue.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lwt/pqueue.mli

ocamlc: lwt/pqueue.ml ---> lwt/pqueue.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lwt/pqueue.ml

ocamlc: lwt/lwt.mli ---> lwt/lwt.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lwt/lwt.mli

ocamlc: lwt/lwt.ml ---> lwt/lwt.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lwt/lwt.ml

ocamlc: lwt/lwt_util.mli ---> lwt/lwt_util.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lwt/lwt_util.mli

ocamlc: lwt/lwt_util.ml ---> lwt/lwt_util.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lwt/lwt_util.ml

ocamlc: lwt/win/lwt_unix_impl.ml ---> lwt/win/lwt_unix_impl.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lwt/win/lwt_unix_impl.ml

ocamlc: lwt/lwt_unix.mli ---> lwt/lwt_unix.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lwt/lwt_unix.mli

ocamlc: lwt/lwt_unix.ml ---> lwt/lwt_unix.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lwt/lwt_unix.ml

ocamlc: case.mli ---> case.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./case.mli

ocamlc: case.ml ---> case.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./case.ml

ocamlc: pred.mli ---> pred.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./pred.mli

ocamlc: pred.ml ---> pred.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./pred.ml

ocamlc: uutil.mli ---> uutil.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./uutil.mli

ocamlc: uutil.ml ---> uutil.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./uutil.ml

ocamlc: fileutil.mli ---> fileutil.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fileutil.mli

ocamlc: fileutil.ml ---> fileutil.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fileutil.ml

ocamlc: name.mli ---> name.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./name.mli

ocamlc: name.ml ---> name.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./name.ml

ocamlc: path.mli ---> path.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./path.mli

ocamlc: path.ml ---> path.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./path.ml

ocamlc: fspath.mli ---> fspath.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fspath.mli

ocamlc: fspath.ml ---> fspath.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fspath.ml

ocamlc: fs.mli ---> fs.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fs.mli

ocamlc: fs.ml ---> fs.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fs.ml

ocamlc: fingerprint.mli ---> fingerprint.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fingerprint.mli

ocamlc: fingerprint.ml ---> fingerprint.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fingerprint.ml

ocamlc: abort.mli ---> abort.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./abort.mli

ocamlc: abort.ml ---> abort.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./abort.ml

ocamlc: osx.mli ---> osx.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./osx.mli

ocamlc: osx.ml ---> osx.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./osx.ml

ocamlc: external.mli ---> external.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./external.mli

ocamlc: external.ml ---> external.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./external.ml

ocamlc: props.mli ---> props.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./props.mli

ocamlc: props.ml ---> props.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./props.ml

ocamlc: fileinfo.mli ---> fileinfo.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fileinfo.mli

ocamlc: fileinfo.ml ---> fileinfo.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fileinfo.ml

ocamlc: os.mli ---> os.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./os.mli

ocamlc: os.ml ---> os.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./os.ml

ocamlc: lock.mli ---> lock.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lock.mli

ocamlc: lock.ml ---> lock.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./lock.ml

ocamlc: clroot.mli ---> clroot.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./clroot.mli

ocamlc: clroot.ml ---> clroot.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./clroot.ml

ocamlc: common.mli ---> common.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./common.mli

ocamlc: common.ml ---> common.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./common.ml

ocamlc: tree.mli ---> tree.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./tree.mli

ocamlc: tree.ml ---> tree.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./tree.ml

ocamlc: checksum.mli ---> checksum.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./checksum.mli

ocamlc: checksum.ml ---> checksum.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./checksum.ml

ocamlc: terminal.mli ---> terminal.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./terminal.mli

ocamlc: terminal.ml ---> terminal.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./terminal.ml

ocamlc: transfer.mli ---> transfer.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./transfer.mli

ocamlc: transfer.ml ---> transfer.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./transfer.ml

ocamlc: xferhint.mli ---> xferhint.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./xferhint.mli

ocamlc: xferhint.ml ---> xferhint.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./xferhint.ml

ocamlc: remote.mli ---> remote.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./remote.mli

ocamlc: remote.ml ---> remote.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./remote.ml

ocamlc: globals.mli ---> globals.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./globals.mli

ocamlc: globals.ml ---> globals.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./globals.ml

ocamlc: fpcache.mli ---> fpcache.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fpcache.mli

ocamlc: fpcache.ml ---> fpcache.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./fpcache.ml

ocamlc: update.mli ---> update.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./update.mli

ocamlc: update.ml ---> update.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./update.ml

ocamlc: copy.mli ---> copy.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./copy.mli

ocamlc: copy.ml ---> copy.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./copy.ml

ocamlc: stasher.mli ---> stasher.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./stasher.mli

ocamlc: stasher.ml ---> stasher.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./stasher.ml

ocamlc: files.mli ---> files.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./files.mli

ocamlc: files.ml ---> files.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./files.ml

ocamlc: sortri.mli ---> sortri.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./sortri.mli

ocamlc: sortri.ml ---> sortri.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./sortri.ml

ocamlc: recon.mli ---> recon.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./recon.mli

ocamlc: recon.ml ---> recon.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./recon.ml

ocamlc: transport.mli ---> transport.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./transport.mli

ocamlc: transport.ml ---> transport.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./transport.ml

ocamlc: strings.mli ---> strings.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./strings.mli

ocamlc: strings.ml ---> strings.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./strings.ml

ocamlc: uicommon.mli ---> uicommon.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./uicommon.mli

ocamlc: uicommon.ml ---> uicommon.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./uicommon.ml

ocamlc: uitext.mli ---> uitext.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./uitext.mli

ocamlc: uitext.ml ---> uitext.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./uitext.ml

ocamlc: test.mli ---> test.cmi

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./test.mli

ocamlc: test.ml ---> test.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./test.ml

ocamlc: main.ml ---> main.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./main.ml

ocamlc: linktext.ml ---> linktext.cmo

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -c ./linktext.ml

ocamlopt: system/system_win_stubs.c ---> system/system_win_stubs.obj

ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g -ccopt /Fo./system/system_win_stubs.obj -c ./system/system_win_stubs.c

Makefile.OCaml:419: recipe for target `system/system_win_stubs.obj' failed

I will now try 3.12.1 again, making sure to do a 'make clean' first.

On Wed, Aug 1, 2012 at 4:00 AM, Alan Schmitt <alan.schmitt <at> polytechnique.org> wrote:

Christopher Galpin <unison <at> swin.oib.com> writes:

> Good suggestion. I fair worse with 4.00.0 I'm afraid:

We haven't tested with 4.0 yet, so I'm not sure it's compatible.

> C:\cygwin\home\Chris\unison-2.45.4>make UISTYLE=text NATIVE=false
> OSARCH=win32
> TAIL: lseeki64() failed 22
> TAIL: lseeki64() failed 22
> ocamlc -o mkProjectInfo unix.cma str.cma mkProjectInfo.ml
> ./mkProjectInfo > Makefile.ProjectInfo
> TAIL: lseeki64() failed 22
> TAIL: lseeki64() failed 22
> UISTYLE = text
> Building for Windows
> NATIVE = false
> THREADS = false
> STATIC = false
> OSTYPE =
> OSARCH = win32
> ocamlc: unicode.ml ---> unicode.cmo
> ocamlc -I lwt -I ubase -I system -I system/win -I lwt/win -custom -g
> -c ./unicode.ml
> File "./unicode.ml", line 1:
> Error: unicode_tables.cmi
> is not a compiled interface for this version of OCaml.
> It seems to be for an older version of OCaml.
> Makefile.OCaml:411: recipe for target `unicode.cmo' failed
> make: *** [unicode.cmo] Error 2

Just to be sure: did you do a make clean first?

> I also tried 3.12.1, and I believe results were similar to my last
> post.

This is strange, it should definitely work there.

Alan

__._,_.___

__,_._,___

headers

Alan Schmitt | 1 Aug 2012 14:31

Re: Re: fsmonitor.py high CPU load?

Christopher Galpin <unison <at> swin.oib.com> writes:

> I started down the road of working with gcc-mingw as
> per http://stackoverflow.com/questions/3776098/cygwin-how-to-actually-use-
> gcc-mingw
> But then it occurred to me, isn't this where Visual Studio C++ Express
> Edition is supposed to step in, not Cygwin's gcc?
> Isn't that why I'm running this from Visual Studio's command prompt
> with the variables in vcvars.bat set?
> I'm too tired to keep at it... but I'm tenacious and experienced so we
> will get it eventually. The gears are turning but I need sleep.

Maybe you could look into using the Windows installer for Ocaml 4.0:
http://alan.petitepomme.net/cwn/2012.07.31.html#3

Alan

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/unison-users/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/unison-users/join
    (Yahoo! ID required)

<*> To change settings via email:
    unison-users-digest <at> yahoogroups.com 
    unison-users-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    unison-users-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/