On 5/10/06, Ross Paterson 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

On 5/11/06, Ross Paterson wrote:

On Thu, May 11, 2006 at 01:42:20PM +0300, Esa Ilari Vuokko wrote:

...

If there's nobody else that'd like to check and commit changes in, yes, I can volunteer.

I should warn you that the graphics part doesn't quite work with GHC.

I haven't been terribly interested in that part yet. The stuff that I have played with it did work (some simple windowing). [snip versioning stuff]

But in you increment the version number every time you add something to the interface, you'll use a lot of version numbers. I'd prefer to use setup sdist --snapshot to get incremental versioning between releases.

I think we have quite diffrent model for versioning. :-) I wasn't going to up version all the time, just this once, until release (probably ghc 6.6), so that packages that want to be ready for it, could have correct package deps already. Then, after release, first changes should up the number again until next release. But that's not important, if upping on release is the common way here, I have no problem with it. And thank you, Ross, for reviewing, beautifying and commiting my patches. --Esa