- Libraries - Haskell.org

Proposal on the platform API policy question
by Duncan Coutts 22 May '09

22 May '09

All, Thanks to everyone who took part in the recent discussion on API compatibility in minor platform releases. In response to the points raised, Don and I would like to propose the following: * Bug fix only in minor releases * Change platform version numbers to follow the PVP * 4 month major release cycles for the first 12 months * Review major release cycle frequency after 12 months We hope we can achieve consensus around this proposal. Please could people indicate if they think they can support this. Note that there are plenty of other issues that we have yet to address, so don't worry that we're not talking about those yet. We raised this issue first because we need a decision. Details: * "bug fix only" means no api changes or additions in library packages and no new user-accessible features in programs. In terms of the PVP it means only the 4th digit may increment, eg X.Y.Z.0 -> X.Y.Z.1. * Having the platform following the PVP means the next minor release will be 2009.2.0.1 (rather than 2009.2.1) to indicate that it has (or more accurately it's constituents have) the exact same API as the previous major release. In general the version will be of the form "X.Y.0.Z" with "X.Y" being the major version and Z the minor. * Initially using a 4 month major release cycle means we'll get one release before ghc 6.12 and another after (assuming 6.12 is released in November again). * After 12 months we'll review (via this mailing list) the release cycle frequency based on the experience of 4 month release cycles and with input from HP users, HP package maintainers and HP release wranglers. Duncan

7 7

network accept bug
by Bart Massey 20 May '09

20 May '09

I tried to file a bug ticket against this but the GHC trac doesn't seem to be quite working, so... It may be a known issue, but Network.accept doesn't appear to return the right port number on my 64-bit Linux box: it returns the server port rather than the client port. The connection it returns seems to work fine. On my 32-bit machines it works fine. I've reproduced the problem with ghc-6.8.3 and ghc-6.10.1, and with network-2.2.0.1 and network-2.2.1.2 (I think; is hiding the older package sufficient to force use of the newer one?). Thanks much for any advice you might have. Bart Massey bart(a)cs.pdx.edu

4 4

Cabal or haddock? Can't export documentation from hidden module
by Maurício 20 May '09

20 May '09

Hi, I opened this ticket, but then I thought that maybe it is not related to haddock but to how Distribution modules call haddock: http://trac.haskell.org/haddock/ticket/107 What do you think? When I don't expose a module in .cabal file, other modules do not show documentation imported from that module. Thanks, Maurício

2 1

Re: network-dns
by Adam Langley 19 May '09

19 May '09

It's deprecated because I'm too busy to maintain it I'm afraid. On May 18, 2009 9:31 PM, "Erik de Castro Lopo" <mle+hs(a)mega-nerd.com<mle%2Bhs(a)mega-nerd.com>> wrote: Hi all, I found this package: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/network-dns which is marked as deprecated. Is there a reason why its deprecated? Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ Libraries mailing list Libraries(a)haskell.org http://www.haskell.org/mailman/listinfo/libraries

2 3

Re: patch to process 1.0.1.1
by John Lato 19 May '09

19 May '09

Hello, Thanks very much for this patch. I also do development on OSX 10.4.11, and was very disappointed to find out that ghc-6.10.3 didn't compile for me. I didn't really have time to spend on it then, so I just went back to using 6.10.1. Did you install GNU make manually as well? The make provided with the last XCode doesn't work for me either with ghc-6.10.3. Thank you, John > > Message: 4 > Date: Tue, 19 May 2009 20:28:08 +0900 > From: Yusaku Hashimoto <nonowarn(a)gmail.com> > Subject: Re: Patch to process 1.0.1.1 > To: Neil Mitchell <ndmitchell(a)gmail.com> > Cc: libraries(a)haskell.org > Message-ID: <026A3F34-48A0-4690-8F10-056349FD14AA(a)gmail.com> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > Thank you for suggestion, Neil. > > I have created a ticket on trac. > http://hackage.haskell.org/trac/ghc/ticket/3243 > > Thanks, > Hashimoto > > > On 2009/05/19, at 19:49, Neil Mitchell wrote: > >> Hi Yusaku, >> >> So your patch doesn't get lost, can I suggest you file a GHC bug >> report and attach your patch to that? >> http://hackage.haskell.org/trac/ghc/wiki/ReportABug >> >> Thanks for the work in putting together a patch, >> >> Neil >> >> On Tue, May 19, 2009 at 11:36 AM, Yusaku Hashimoto >> <nonowarn(a)gmail.com> wrote: >>> I think I had not described context or purpose of my patch in last >>> mail. I'm going to explain the details about why the error occurs and >>> how the patch works. before and from I sent the patch, I have >>> inspected about them. So the detail was complicated but >>> interesting for me, I enjoyed it. >>> >>> Well, this patch seems to be useful only on the old-fashiond Mac OS X >>> 10.4.11, because no same error is not reported from anyone, and >>> I'm an >>> only ghc user who uses Mac OS X 10.4.11. And ghc seemed to has >>> quitted >>> to support the 10.4. This implies the patch should not be applied to >>> the repository. But if there are a few users like me, my patch and >>> report may be useful for (him|her).

2 1

New version of readline?
by Krasimir Angelov 19 May '09

19 May '09

Hi, I am currently using two functions: readHistory :: String -> IO Bool writeHistory :: String -> IO Bool from Readline. They are available in the darcs version of Readline but the package which is uploaded on Hackage is older and it doesn't have them. Does someone know what is the status of readline? Will there be a new version on Hackage soon? Readline is no longer distributed together with GHC so Hackage is the default place to take a new version. Best Regards, Krasimir

2 1

network-dns
by Erik de Castro Lopo 19 May '09

19 May '09

Hi all, I found this package: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/network-dns which is marked as deprecated. Is there a reason why its deprecated? Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

1 0

add utf8-string in haskell platform
by Simon Michael 18 May '09

18 May '09

I'd like to request that utf8-string be added to the haskell platform, so that HP users can work with non-ascii text. Thanks a lot!

8 12

template-haskell depends on packedstring
by Gwern Branwen 18 May '09

18 May '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 So I was trying to compile lambdabot with cabal-install. Lambdabot uses Template Haskell for generating some boilerplate, and it was a failed dependency. Template Haskell uses packedstring for... something... and packedstring was a failed dependency: Data/PackedString.hs:83:7: Could not find module `Data.Data': it is a member of package base, which is hidden Now this is a problem, but it's not the problem I am interested in. I am interested in: why is template-haskell using packedstring? Wasn't packedstring obsoleted years ago? I downloaded the TH tarball to see what fascinating things it was using packedstring for, and I found that it's hardly doing anything - it apparently is just encoding module (ModName) and OccName (whatever that is), and then the other functions shift back from PackedString/ModName-OccName to String. (This is all in Language/Haskell/TH/Syntax.hs) I replaced all the PackedString stuff with normal ol' String and compiled fine, and indeed seems to work fine at Template-Haskelly stuff. So here's my suggestions: 1) Remove the packedstring dep and calls from the TH code. It is useless, it shackles the package to a long obsolete one, and so on. Even if we assume that the packedstring code is still faster than native String, and that there's no performance penalty for the conversions back and forth from String to PackedString, and that the possible size increase from linking in PackedString code is not worth worrying about, and we also assume that PackedString is being used on Names large enough to make up for any overhead - even if we assume all that, TH is a compile-time process and so it doesn't matter all that much if we shave a few microseconds off one small part of the compilation process. Installability and cleaner code would be worth that price. 2) If just String is not acceptable, then I understand from dons that the reason we can't use just plain ol' ByteString is because the Names may well be in UTF-8, and ByteString's [Word8]s apparently don't treat that well. Given that, we need some sort of UTF8 bytestring. As it happens, we do in fact have such a thing: Data.ByteString.UTF8 . It looks a bit incomplete, but utf8-string in general is pretty widely-used and reliable (also builds on 6.10): just about every XMonad user uses XMonadContrib which uses utf8-string, and I can count the number of complaints because utf8-string on one hand. Thoughts? I searched thoroughly through various bug-trackers and mailing lists, but this doesn't seem to've come up before. - -- gwern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREKAAYFAkkqJTsACgkQvpDo5Pfl1oLYoQCgjRSqno+DtyZiLbAS5Pk4l8Ao sqkAn15sBq+alBy5ZVLHIMthjZ6eU6E6 =N8Qj -----END PGP SIGNATURE-----

3 6

2009.2.1: version freeze for Haskell Platform approaching on Monday
by Don Stewart 16 May '09

16 May '09

According to our release timetable, the last chance to propose bug fix version bumps for 2009.1.0 is Monday: http://trac.haskell.org/haskell-platform/wiki/ReleaseTimetable In particular, I think this affects 'network', where a number of bugs reported against the last platform have been repaired. Please ensure that, as maintainer for one of the 2009.2.x series of packages, any bug fixes are in place by Monday, or they'll be bumped to the next platform release. For a full list of packages distributed with the 2009.2.x series of the platform, see: http://trac.haskell.org/haskell-platform/wiki/2009.2.0 And please continue to propose packages for the next major release, via the bug tracker (and discussion on libraries@) -- Don

1 0