On Sep 17, 2008, at 13:44 PM, Eric Kow wrote: > > Could you kick the buildbot again?
Done. By the way, Zandr is likely to add more RAM to that (virtual) machine and reboot it soon. > I've pushed a patch to disable the entirety of the record_editor test, > since the os check seems to be correct. Previously, I had only > disabled > the last one -- there are three -- because the first two worked under > MSYS. Perhaps they do not work under Cygwin. I'll bet that it has to do with the EDITOR environment variable, or the VISUAL environment variable, or the DARCS_EDITOR environment variable, or the presence of some tool such as gvim which is installed on one machine and not another... Being "under Cygwin" as such has relatively little meaning for this test -- I think it means that the Perl interpreter is a cygwin- compile of perl and that when perl invokes a system process it goes through the cygwin bash shell. But when darcs invokes a system process it does not, so the fact that the perl interpreter is "under Cygwin" shouldn't be construed as meaning that darcs itself is operating in some foreign, non-Windows environment if you see what I mean. I feel like I'm having trouble explaining this fact about cygwin. Let me put it like this: There is a specific, limited, set of ways in which the presence of cygwin on the operating system can have any effect on darcs's functionality. Those ways are: 1. If darcs executes an executable in a subprocess, and darcs is surprised that the executable acts differently than it expected since it accidentally got a cygwin executable rather than a Windows executable. I don't think that this currently happens, although this issue with the "editor" might be a case of it, if darcs is executing a subprocess named "edit" or something. 2. If there are some funny environment variables set in the environment by tools that changed the user's environment when the tool was installed, or set in the environment by the process which invoked darcs (which in this case is perl). If this is the case, we can tell since buildbot helpfully prints out the entire contents of the environment at the top of every subprocess log, e.g.: http://buildbot.darcs.net/builders/zooko%20allmydata%20virtual2% 20Windows-XP%20i386/builds/61/steps/test/logs/stdio I'm guessing that this issue with the editor is a case of this. 3. If the process that is using darcs has different behavior with regard to pipe management, such as buffering, blocking, etc., because that process (e.g. perl running tests, or bash running tests, or a user running bash using darcs) is a cygwin app and has different assumptions than darcs has about the use of sockets. However, let me emphasize that, basically, none of these should be capable of causing darcs to fail. Let me try to put it in the affirmative sense: Running darcs "under cygwin" is exactly like running darcs "under Windows" in the following ways: 1. The x86 object code that is being executed is identical in both cases. 2. The interpretation of that object code by the CPU as managed by the operating system is indentical in both cases. 3. Any system calls that darcs makes to Windows are identical in both cases -- cygwin is incapable of intercepting system calls and causing them to behave differently. 4. Any dynamic link libraries that darcs uses are identical in both cases. 5. ? Etc. There is really only a few very specific possible reasons why being "under cygwin" can cause darcs to behave any differently than darcs behaves "under Windows". I hope I've made the point clear. I suspect that if people train themselves not to say "under cygwin" and instead say something more specific, such as "when executed as a subprocess of cygwin perl", or "when there is an environment variable named VISUAL set" then things will be clearer. Regards, Zooko --- http://allmydata.org -- Tahoe, the Least-Authority Filesystem http://allmydata.com -- back up all your files for $5/month _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
