Re: Win32 libraries for Haskell
At 11:15 03/02/04 +0000, Simon Peyton-Jones wrote:
I'm not sure how to make progress here. Is anyone else interested or willing to take ownership of libraries/win32? (Graham? Krasimir?) This isn't a GHC specific thing -- I believe/hope the same libraries should work equally well for Hugs.
Hmmm... I took a peek at the Library/Win32 stuff in the GHC source distribution, and it looks as if there may a steep-ish learning curve. While I'm prepared in principle to help where I can, I'm concerned about over-commitment...
The situation seems to be this:
* Sigbjorn is actively maintaining hslibs/win32 for Galois reasons, and is reluctant to transfer to libraries/win32 because it's untested (I'm assuming that the Green-Card dependency is soluble by putting the GC output in the CVS tree). Fair enough.
That might remove one learning-curve dependency... are there disadvantages to doing this? I also noted the lack of a test suite: is there one for hslibs that might be migrated? #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact
Simon:
(I'm assuming that the Green-Card dependency is soluble by putting the GC output in the CVS tree).
This would remove the dependency for those who want to use the latest cvs copy of the library but don't want to install greencard. It would also make things easier if the library depended on a particular version of greencard but that version was only available by cvs. (To be honest, I don't see the problem with having a Greencard 'dependency'. It's easy enough for public releases to include the machine-generated files and for those using cvs, they can fetch Greencard from cvs too.) Graham:
That might remove one learning-curve dependency... are there disadvantages to doing this?
Many people feel that machine generated output should not be put in cvs because: 1) 'make', 'make clean', etc. don't do a rebuild using the latest version of greencard. This mostly affects the maintainer. 2) Changes made to the generated files can be lost if the file is regenerated. Graham:
I also noted the lack of a test suite: is there one for hslibs that might be migrated?
Sadly not. My approach to testing has always been to see if the HGL still works. This does some limited testing of the interactive operations. There's no tests for things which touch disk, registry, etc. It'd be easy (but tedious) to add this. -- Alastair
At 15:18 03/02/04 +0000, Alastair Reid wrote:
(To be honest, I don't see the problem with having a Greencard 'dependency'. It's easy enough for public releases to include the machine-generated files and for those using cvs, they can fetch Greencard from cvs too.)
Part of the problem is knowing how much stuff one really needs to know about... I just took a closer look at the GreenCard docs, and from a user/build perspective it looks easier than I feared. I think the main concern for general libraries would be to stick to stable releases of GreenCard with ready-to-go binary distributions. I agree that using GreenCard does not look like a major bind.
Graham:
That might remove one learning-curve dependency... are there disadvantages to doing this?
Many people feel that machine generated output should not be put in cvs because:
1) 'make', 'make clean', etc. don't do a rebuild using the latest version of greencard. This mostly affects the maintainer. 2) Changes made to the generated files can be lost if the file is regenerated.
Fair enough.
Graham:
I also noted the lack of a test suite: is there one for hslibs that might be migrated?
Sadly not.
My approach to testing has always been to see if the HGL still works. This does some limited testing of the interactive operations.
HGL?
There's no tests for things which touch disk, registry, etc. It'd be easy (but tedious) to add this.
I'd be reasonably comfortable with a program which can be run using canned data and which gives a reasonable coverage of the functions. In many cases, it might be possible to wrap this in an HUnit test framework. My main concern would be if that created too many dependencies on other modules. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact
HGL?
A simple graphics library - used in Paul Hudak's School of Expression book. http://haskell.org/graphics/ A
participants (2)
-
Alastair Reid -
Graham Klyne