On 27/04/2010 15:01, Petr Rockai wrote:
Simon Marlow<[email protected]> 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
starting point?
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.
Cheers,
Simon
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
