[patch] Win32 enchaments

Esa Ilari Vuokko eivuokko at gmail.com
Thu May 11 06:42:20 EDT 2006


On 5/10/06, Ross Paterson <ross at soi.city.ac.uk> wrote:
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: win32-filemapping-fixes.dpatch.gz
Type: application/x-gzip
Size: 1559 bytes
Desc: not available
Url : http://www.haskell.org//pipermail/libraries/attachments/20060511/74f1deef/win32-filemapping-fixes.dpatch-0001.bin


More information about the Libraries mailing list