[darcs-users] Something is seriously wrong with Darcs on Windows
marlowsd at gmail.com
Tue Apr 27 14:51:29 UTC 2010
On 27/04/2010 15:01, Petr Rockai wrote:
> Simon Marlow<marlowsd at gmail.com> writes:
>> On 27/04/2010 13:37, Petr Rockai wrote:
>>> I see. Well, indeed, strictly speaking this is not a public API. On the
>>> other hand, there's no public API that can be used to do a stat without
>>> considerable overhead. (The problem with the public API is that it uses
>>> unsafePerformIO which is *very* expensive...)
>> Which public API are you referring to? I'd recommend using System.Win32 for
>> this kind of thing on Windows if possible. If you call lstat you're already
>> going through a layer of translation, namely the msvcrt runtime.
> I was referring to things like System.Directory and
> System.Posix(Compat).Files. These seem to be the right high-level APIs
> that I am probably supposed to use, but they are hopelessly inefficient
> (even on UNIX).
Ah, I see - there are some unsafePerformIOs in the implementation of
things like System.Posix.fileMode. That is easy to fix...
> Meaning, I have to rely on System.Posix.Internals on at
> least UNIX, and for all I can tell, this is supposed to work on windows
> as well.
You're welcome to use it, by all means - but bear in mind this isn't an
API that we think of as public, so we might well remove things or change
things willy-nilly in future releases. Of course we'll respect the PVP
while doing so, so your Cabal packages won't break, but at the same time
APIs like System.Posix.Internals don't get the usual deprecation and
backwards-compatibility treatment that a public API would. The fact
that it isn't documented is a clue :-)
The best solution would be to have a public API that does what you want,
and has decent performance. Perhaps System.PosixCompat would be a good
> Although now that we need special win32 code anyway, it may
> make sense to move to System.Win32 (I will have to look into that
> ... later).
Right, in general I'd recommend avoiding the Unixy C library APIs on
Windows, because they go via either the mingw emulation layer or msvcrt,
both of which are likely to introduce either strange behaviour or poor
performance. One day we'll want a native Win32 implementation of GHC
without mingw, so dropping mingw dependencies now is a good idea.
More information about the darcs-users