[patch] Win32 enchaments

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[patch] Win32 enchaments

Esa Ilari Vuokko
Hi

Is this really the list for patches?
http://darcs.haskell.org/packages/Win32/_darcs/prefs/email
says it is.

Here's few patches to Win32.  First cabal file needed some poking
to be usable and boring-control is also nice to have.  Main patch
brings in file mapping (mmap-style api in Windows) and most of
the Time API.  There's also some few more enchaments and fixes
to warnings etc.  I quickly tested that I can get Makefile work
too, but I haven't tested it much yet.  I also pushed version
number so it's possible to use cabal versioning to fail versions
without added stuff.

Best regards,
--Esa

Tue May  9 15:35:25 FLE Standard Time 2006  Esa Ilari Vuokko
<[hidden email]>
  * Make repo buildable with cabal and add better boring-control


Wed May 10 14:18:35 FLE Standard Time 2006  Esa Ilari Vuokko
<[hidden email]>
  * Add FileMapping and Time and other tweaks.
  Upped version to 1.1
  Added System.Win32.Time - most of Time api
  Added System.Win32.FileMapping - file mapping api and helpers
  Added BY_HANDLE_FILE_INFORMATION and getFileInformationByHandle
  Added SYSTEM_INFO and getSystemInfo
  Cleaned up few warnings and bugs
  Few more cabal tweaks to options


Wed May 10 14:25:41 FLE Standard Time 2006  Esa Ilari Vuokko
<[hidden email]>
  * Update Makefile and package.conf.in

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

win32-filemap-time-2.gz (10K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [patch] Win32 enchaments

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?

Still, I've committed your patches, but re-arranged them a bit.
Some remarks:

- 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.

- The natural counterpart of VOIDP is Ptr a, not Ptr (), and that saves
  some castPtr's, too.

- use of Foreign.Concurrent.newForeignPtr makes System.Win32.FileMapping
  non-portable (do you need to keep those handles open?)

- why do you hide everything in System.Win32.NLS?

> 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.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [patch] Win32 enchaments

Esa Ilari Vuokko
On 5/10/06, Ross Paterson <[hidden email]> 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

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

win32-filemapping-fixes.dpatch.gz (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [patch] Win32 enchaments

Ross Paterson
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.

> >- 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.

I just assumed that all revision control systems did this, but it seems
not.  That would be a nuisance.

> >- why do you hide everything in System.Win32.NLS?
>
> I thought this only hides these names.

Sorry, I misread.

> >> 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.

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.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [patch] Win32 enchaments

Esa Ilari Vuokko
On 5/11/06, Ross Paterson <[hidden email]> 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
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [patch] Win32 enchaments

Simon Marlow-5
Esa Ilari Vuokko wrote:

> On 5/11/06, Ross Paterson <[hidden email]> 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.

When these packages can be installed independently of a GHC or Hugs
release, it will make sense to bump the version number more regularly.
We're not far away from that.

My plan was to bump the versions of all the packages as soon as they're
independently installable, and from then on I think we should bump minor
version numbers whenever an API change is introduced.

Cheers,
        Simon
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries