- Libraries - Haskell.org

What platform is GHC for Windows built on?
by Bryan O'Sullivan 14 May '09

14 May '09

I'm trying to solve a knotty problem with the network package on Windows at the moment: http://trac.haskell.org/network/ticket/5 This looks innocuous - the getaddrinfo function isn't available - but it's proving tricky to actually fix. In addition, I'm worried that if I do fix it (i.e. I can get autoconf to notice that getaddrinfo is really present), that the next binary release of GHC or the Platform on Windows might accidentally not work on releases of Windows older than XP, depending on what kind of host the code is built on.

3 5

Takusen clashing with extensible-exceptions?
by Don Stewart 14 May '09

14 May '09

While building haskeline-0.6.1.5: Setup.hs:16:7: Could not find module `Control.Exception.Extensible': it was found in multiple packages: Takusen-0.8.4 extensible-exceptions-0.1.1.0 Hmm...

2 1

One-click Hackage
by Bulat Ziganshin 13 May '09

13 May '09

Hello Haskell, it's well-known that large class of users (including haskell developers) prefer to use visual tools. for hackage/cabal-install this means that they need a GUI that allow them to find libs they need and install them. this mean some sort of GUI frontend to cabal-install, that isn't yet written. but we can go other way now Hackage web site by itself provides good enough GUI for library search. the only problem is that after finding something useful, user needs to type in "cabal install Foo" in her cmdline - and that's in the best case when she know about cabal-install and had it installed i think that we are just one click away of full GUI support - all that's reuired is to publish on Hackage page for Foo library file Foo.hackage and associate this extension with Cabal. by clicking on such file user will auto download it, and then cabal will read name of package to installed from the file going further, Hackage may provide links to execution of "cabal update" and other commands, becoming sort of GUI for cabal-install. this may be provided as files with the same hackage extension -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

3 2

Stepping back: what do we want from platform releases?
by Duncan Coutts 13 May '09

13 May '09

All, On reflection, we (Don and I) think we've asked a question that has too many assumptions behind it that are not universally agreed. Perhaps we would do better to look at the slightly more general issue. The question we asked about API stability in minor releases already assumes a lot about the frequency of major and minor releases and indeed what a major or minor release actually is; what their purpose is. We've actually started out backwards, we've assumed major and minor timetables and a version number scheme and then asked everyone what should fit that. Instead we should agree what the purpose of Haskell Platform releases are. Once we have decided that, then working out how frequent releases should be and the precise rules and version number schemes will be details that will be much easier to agree. So, what is the purpose of platform releases? Remember that we already have a system whereby any maintainer can make releases of their packages at any time and end users can download and install those releases. So what is the additional purpose of platform releases? * Bundling everything into nice easy end-user installers. This is certainly one purpose. For achieving just this we do not need anything more than a working snapshot of packages from hackage. * Testing. Making sure a set of packages work together. * Getting new features into the hands of users. Not everyone wants to download the latest and greatest from hackage. They want to use things tested together but still want new stuff occasionally. These points we think we all agree on, but none of them really tell us much about how frequent releases should be, as long as they're not so far apart that it defeats the third point about getting new features into the hands of users. * Telling distributions what they should package and telling users what they should have to be able to run the majority of relatively recent Haskell code. These are two purposes but closely related. * Telling developers what set of libs to test against to maximise their potential audience. These are about trying to make sure that users and developers are using the "same" stuff so that people can write programs and know that other people can run them. These require that the releases are the "same" between various operating systems (which the first 3 purposes to not strictly require) but more so that they should be the same between many users and many developers over some non-trivial period of time. This is the stability argument. If we agree with these purposes then we have to consider the balance between stability and progress in terms of new packages, new features and sometimes changing some things in incompatible ways. Note that these points do imply that new features (even compatible ones) cannot be added too frequently. Otherwise developers will write programs using those new features and users will not be able to run them. We would be asking users to upgrade too frequently. One strategy for balancing stability and change is to compress changes into specific points -- major releases -- rather than trickling them out every month. This is in contrast to Hackage which allows for very rapid change and feedback. * Synchronise cross-package changes. Reduce chaotic transitions, eg switching old-time -> time, or new exceptions. This is more ambitious. This implies some community process to decide on these kinds of cross-package changes and buy-in from package maintainers to follow through on the community decision in time for a particular platform release. -------- So we must consider what we are asking users, distributors, developers and maintainers to do. Remember also that we are not preventing developers from releasing new features in their Hackage releases and that the platform gives end users the tools necessary to get those latest and greatest releases. So in comparison to other systems we actually have a much better release valve for the pressure to get new features to users quickly. Duncan and Don

6 5

Re: [Haskell-cafe] Removing mtl from the Haskell Platform
by Henning Thielemann 13 May '09

13 May '09

Sittampalam, Ganesh wrote: > roconnor(a)theorem.ca wrote: > >> I think that use of the mtl should be deprecated so that we move on >> to improved monad transformer libraries. Having the mtl in the >> Haskell Platform does the opposite by further entrenching its use, >> possibly to the point where we may not be able to get rid of it for >> years. > >> If I had to recommend a replace library, I would pick monadLib. However, >> there are other libraries, such as the mmtl and transformers >> and it's related packages that I haven't looked at, and may also make >> fine replacements for the mtl. > > We've discussed replacing it with transformers+monads-fd+an mtl > compatiblity layer on libraries@. Ross and I plan to propose doing this > for the second release of the platform - I vote for that route! > it's not fair to disrupt the first release at this stage.

1 0

[network] #4: sIsReadable and sIsWritable return true after socket is closed.
by network 13 May '09

13 May '09

#4: sIsReadable and sIsWritable return true after socket is closed. ---------------------+------------------------------------------------------ Reporter: igloo | Owner: Type: defect | Status: new Priority: major | Milestone: Component: network | Version: Keywords: | ---------------------+------------------------------------------------------ First reported here: http://hackage.haskell.org/trac/ghc/ticket/2774 ---- {{{ > import Network.Socket > s <- socket AF_INET Stream 6 Loading package parsec-2.1.0.1 ... linking ... done. Loading package network-2.2.0.1 ... linking ... done. > bindSocket s (SockAddrInet 0 0) > listen s 1 > sClose s > sIsReadable s True > sIsWritable s True }}} sIsReadable and sIsWritable return true when the !SocketStatus is Connected or Listening. sClose does not change the status. Perhaps a new status Closed should be added to !SocketStatus. -- Ticket URL: <http://trac.haskell.org/network/ticket/4> network <http://projects.haskell.org/network/> Networking-related facilities

1 1

[network] #10: Network.Socket.connect: support for sockets w/ bound local endpoints
by network 13 May '09

13 May '09

#10: Network.Socket.connect: support for sockets w/ bound local endpoints ---------------------+------------------------------------------------------ Reporter: tibbe | Owner: Type: defect | Status: new Priority: major | Milestone: Component: network | Version: Keywords: | ---------------------+------------------------------------------------------ Just in case this isn't taken care of by the ongoing rewrite of 'network', but there's an age-old limitation in the implementation of Network.Socket.connect -- it balks at being given a socket where the local endpoint (port,iface) has already been bound. i.e., it socket status test ought to be not (currentStatus elem [NotConnected?,Bound]) The workaround of manually resetting SocketStatus? always leaves me feeling icky. (Copied from http://hackage.haskell.org/trac/ghc/ticket/3143) -- Ticket URL: <http://trac.haskell.org/network/ticket/10> network <http://projects.haskell.org/network/> Networking-related facilities

1 1

[network] #5: getAddrInfo and addrFamily not in scope on Windows GHC 6.8
by network 13 May '09

13 May '09

#5: getAddrInfo and addrFamily not in scope on Windows GHC 6.8 ---------------------+------------------------------------------------------ Reporter: igloo | Owner: Type: defect | Status: new Priority: major | Milestone: Component: network | Version: Keywords: | ---------------------+------------------------------------------------------ Originally reported here: http://hackage.haskell.org/trac/ghc/ticket/2726 ---- import Network.Socket ... getAddrInfo ... addrFamily -- gives me not in scope on Windows. The same code works on Unix. ---- Looking at the code, these are only available if `IPV6_SOCKET_SUPPORT` is defined. I don't know more than that off the top of my head. -- Ticket URL: <http://trac.haskell.org/network/ticket/5> network <http://projects.haskell.org/network/> Networking-related facilities

1 2

[network] #1: unpackFamily on Windows fails match
by network 13 May '09

13 May '09

#1: unpackFamily on Windows fails match ------------------------+--------------------------------------------------- Reporter: igloo | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: component1 | Version: Keywords: | ------------------------+--------------------------------------------------- Initially reported here: http://hackage.haskell.org/trac/ghc/ticket/2250 ---- In the HostEntry returned by Network.BSD.getHostByName, evaluating the hostFamily field causes the following error, which is pointing at the unpackFamily function: {{{ *** Exception: Network/Socket.hsc:(1711,17)-(1777,13): Non-exhaustive patterns in case }}} This occurs with 6.8.2 and 6.9.20080323 i386. The machine is running Windows Server 2008 x64. ---- I modified Network/BSD.hs to trace out the h_addrtype variable in Storable `HostEntry`'s peek, and it had the value 0x40002. The corresponding variable in the C struct should be a short, but is inferred to be CInt in the Haskell source, probably thanks to unpackFamily having type CInt -> Family. Due to that, it reads the family as an int, consuming the following length field as well. I hacked past this by giving the peek of h_addrtype an annotation of ":: IO CShort" and adding a fromIntegral at the call to unpackFamily to convert it to the CInt that the unpackFamily function expects. ---- Great stuff, thanks! It looks like it should be `CSaFamily` rather than `CInt`. Likewise `packFamily`, and I expect the whole library could do with an audit. ---- I can reproduce the exact bug on the following combinations: - GHC 6.8.2, x86, Windows XP - GHC 6.8.3, x86, Windows XP - GHC 6.8.2, x86, Windows Vista - GHC 6.8.3, x86, Windows Vista - GHC 6.8.2, x64, Windows Vista - GHC 6.8.3, x64, Windows Vista -- Ticket URL: <http://trac.haskell.org/network/ticket/1> network <http://projects.haskell.org/network/> Networking-related facilities

1 7

Re: [Haskell-cafe] Removing mtl from the Haskell Platform
by Don Stewart 13 May '09

13 May '09

(Platform discussion on libraries@ please) Right, so the Haskell Platform can be a mechanism by which we move the community forward. You could propose to remove mtl (which would involve deprecating for a major (or two? or many more?) releases, before we actually rip it out. Equivalent functionality for something so fundamental would also have to be found. We would need a new monad library, documented, in use, with a migration story for developers ideally. Identifying the candidate that provides equivalent functionality (and better) is strongly desirable. File a ticket, so we don't forget you've proposed this. http://trac.haskell.org/haskell-platform/wiki -- Don roconnor: > I wanted to pass this idea around the cafe to get some thoughts before > submitting a trac on this topic. > > I'd like to see the mtl removed from the Haskell Platform. > > The mtl was a tremendous step forward when it was developed. However, we > have learned a few things about monad transformers since the development > of the mtl, and it is time that we moved forward. > > There are at least 3 significant problem with the mtl. > > 1) `pass' should not be a member functions of the MonadWriter class. It > is my understanding that there is no `MonadWriter w m => MonadWriter w > (ContT s m)' instance because the `pass' function cannot be implemented. > I'm also highly suspicious of some other methods too (I'm looking at you > `local'). > > 2) The `StateT s (Cont r a)' instance of callCC is wrong. The paper on > modular monad transformers > <http://www.cs.nott.ac.uk/~mjj/pubs/mmt/mmt.pdf> describes why this is > wrong. > > 3) I am told by many people that the order of the state and value pair in > `State' is backwards. Actually, I'm not entirely sure what the issue is > here, but I trust the people who say this. > > I think that use of the mtl should be deprecated so that we move on to > improved monad transformer libraries. Having the mtl in the Haskell > Platform does the opposite by further entrenching its use, possibly to > the point where we may not be able to get rid of it for years. > > If I had to recommend a replace library, I would pick monadLib. However, > there are other libraries, such as the mmtl and transformers and it's > related packages that I haven't looked at, and may also make fine > replacements for the mtl. > > -- > Russell O'Connor <http://r6.ca/> > ``All talk about `theft,''' the general counsel of the American Graphophone > Company wrote, ``is the merest claptrap, for there exists no property in > ideas musical, literary or artistic, except as defined by statute.'' > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0