On 5/10/06, Ross Paterson
On Wed, May 10, 2006 at 02:34:42PM +0300, Esa Ilari Vuokko wrote:
Is this really the list for patches? http://darcs.haskell.org/packages/Win32/_darcs/prefs/email says it is.
That indicates that the package has no maintainer. I ported it to FFI, but am not able to look after it. Would you like to volunteer?
If there's nobody else that'd like to check and commit changes in, yes, I can volunteer.
Still, I've committed your patches
Thanks :)
, but re-arranged them a bit.
I see. Okey. Apologies for caused work.
Some remarks:
Thanks.
- The patch is full of ^M's -- I assume there's some way to tell darcs that you're on a CRLF system, so this doesn't happen.
As far as I can tell, no, it isn't possible - darcs maintains the idea that it doesn't touch the data. And it appears I can't find a switch that on my editor. I'll try to find a solution later.
- The natural counterpart of VOIDP is Ptr a, not Ptr (), and that saves some castPtr's, too.
As much as I like automatic type inference, I don't like it when working with something as hazardous as FFI imports. I don't really-really care, tho.
- use of Foreign.Concurrent.newForeignPtr makes System.Win32.FileMapping non-portable (do you need to keep those handles open?)
Oops, good catch. I didn't realise it was non-portable. And yeah, it seems there's no need to keep handles open, I had that in my code before, so it got carried here. Attached few more patches, there were also few debug messages left *blush*.
- why do you hide everything in System.Win32.NLS?
I assume you mean import System.Win32.NLS hiding ( LCID, LANGID, SortID, SubLANGID , PrimaryLANGID, mAKELCID, lANGIDFROMLCID , sORTIDFROMLCID, mAKELANGID, pRIMARYLANGID , sUBLANGID ) I thought this only hides these names. This is because they are re-exports from System.Win32.Types and cause warnings when exported. I didn't want to remove them from NLS export-list because that'd break modules that import just NLS. At least ghci 6.5 seems to agree with my interpretation. Those symbols are still available from System.Win32 as are NLS symbols (as compiled from my original patches.)
I also pushed version number so it's possible to use cabal versioning to fail versions without added stuff.
It's probably best to delay that until a release.
I don't see a big diffrence, except that with my patch other packages can use (somewhat) correct version dependency before release. --Esa