- Libraries - Haskell.org

non-ASCII filepaths in a C function
by Henning Thielemann 25 Jul '15

25 Jul '15

In my 'soxlib' package I have written a binding to sox_format_t * sox_open_read( char const * path, sox_signalinfo_t const * signal, sox_encodinginfo_t const * encoding, char const * filetype); I construct the C filepath "path" from a Haskell FilePath using Foreign.C.String.withCString. This works for ASCII and non-ASCII characters in Linux. However, non-ASCII characters let sox_open_read fail on Windows. What is the correct way to convert FilePath to "char *"?

3 4

Proposal: Migrate Data.Functor.{Sum, Product, Compose} from transformers to base.
by Edward Kmett 25 Jul '15

25 Jul '15

As part of GHC 7.10 we moved Data.Functor.Identity from transformers into base. (We'd previously had a private, equivalent definition buried in Data.Traversable that we didn't export.) In a similar vein, I hereby propose moving Data.Functor.Sum, Data.Functor.Product, Data.Functor.Compose, and Data.Functor.Classes into base as they exist in transformers, without unduly bikeshedding their APIs. This would effectively reduce the role of transformers to simply supplying actual transformers and continue the general pattern of universal constructions migrating into base. Without bikeshedding their implementations this migration becomes a no-op for existing users. The most awkward of these is the Data.Functor.Classes API, but it affects a number of their instances, and without it, those instances would have to be orphans, so my gut reaction would be to say yes, we should move that as well. There are also some in-flight API changes in the works in the HEAD version of transformers for which a base-based version of the API could exploit DefaultSignatures to ease migration. I'm rather deliberately not including Data.Functor.Constant in this proposal as when it has been discussed in the past, Const from Control.Applicative has effectively grown to subsume that role. That said, we if we bring in the rest of this stuff we could migrate it to Data.Functor.Const and simply re-export it from Control.Applicative to avoid breakage. So, as a concrete proposal I propose that we: 1.) Move Data.Functor.Sum, Data.Functor.Product, Data.Functor.Compose and Data.Functor.Classes into base. 2.) Move Control.Applicative's Const into Data.Functor.Const, but continue to re-export it from Control.Applicative. 3.) Add whatever missing, sensible, instances make sense after the transition that were ruled out by these modules' previous placement. *e.g.* Data, Generic, Generic1. Discussion Period: 2 weeks -Edward Kmett

8 9

Intention to takeover glpk-hs
by Jean-Philippe Bernardy 25 Jul '15

25 Jul '15

Hi, I intend to take over the glpk-hs package from Louis, who did not respond to my direct request, made June 22nd. The last update to the package was made in 2012 and it does not compile with ghc 7.10. Cheers, JP.

3 2

Re: Proposal: Migrate Data.Functor.{Sum, Product, Compose} from transformers to base.
by Ryan Scott 24 Jul '15

24 Jul '15

I really like this proposal, especially since having convenient Eq1, Ord1, Read1, Show1, etc. instances is something I've wanted for a while. I have some questions about some specifics: 1. Just to verify, you're proposing a breaking change in which Data.Functor.Constant no longer exports Constant, but rather Const? 2. You mentioned that the additions to base could use DefaultSignatures. Could you give an example of how this would work?

3 3

Re: [Haskell-cafe] ANN: haddock-2.16.1
by Chris Wong 24 Jul '15

24 Jul '15

On Fri, Jul 24, 2015 at 10:24 PM, Tomas Carnecky <tomas.carnecky(a)gmail.com> wrote: > Will hackage rebuild all existing documentation or only when I upload a new > version? IIRC, it will only build a package when its documentation is not present. > If not automatically, can I manually tell hackage to rebuild the > docs? Go to the package page, and click the "edit package information" link at the bottom. There should be an option to clear and rebuild the docs. > > On Wed, Jul 22, 2015 at 11:43 PM Matthew Pickering > <matthewtpickering(a)gmail.com> wrote: >> >> The curious can see an example of this new hyperlinked source here[1]. >> >> Great work Łukasz and Mateusz! >> >> [1]: >> https://hackage.haskell.org/package/ghc-exactprint-0.3/docs/src/Language.Ha… >> >> On Wed, Jul 22, 2015 at 11:17 PM, Mateusz Kowalczyk >> <fuuzetsu(a)fuuzetsu.co.uk> wrote: >> > Hi, >> > >> > We're glad to announce Haddock 2.16.1. It is mostly a bugfix release: I >> > inline the changelog at the bottom. It should work fine with 7.10.x GHC >> > family. The packages are already on Hackage: haddock for the executable, >> > haddock-api for the guts and use from Haskell and haddock-library which >> > is the comment parser. >> > >> > It should also be shipping with GHC 7.10.2. >> > >> > I think two things are worth mentioning before: >> > >> > * The pending mathjax PR[1] is going to be included in future release of >> > Haddock. As it is likely to break the interface file version, I am >> > putting it off a bit to bundle with other possibly interface-breaking >> > changes. >> > >> > * Our GSOC student has successfully completed first part of his >> > project[2]. It involves native source code highlighting and perhaps more >> > excitingly, source hyperlinking: you should now be able to click on >> > identifiers to be taken to their definitions. This change is not in >> > 2.16.1 as it is rather recent so we erred on the side of safety when >> > picking what to release with GHC 7.10.2. You can try it by building >> > current Haddock master, should work with 7.10.x family. >> > >> > As usual, if you want to contribute, please do so on GitHub. We're also >> > on IRC under #haddock. >> > >> > Thanks! >> > >> > Changes in version 2.16.1 >> > >> > * Don't default to type constructors for out-of-scope names (#253 and >> > #375) >> > >> > * Fix Hoogle display of constructors (#361) >> > >> > * Fully qualify names in Hoogle instances output (#263) >> > >> > * Output method documentation in Hoogle backend (#259) >> > >> > * Don't print instance safety information in Hoogle (#168) >> > >> > * Expand response files in arguments (#285) >> > >> > * Build the main executable with -threaded (#399) >> > >> > * Use SrcSpan of declarations for inferred type sigs (#207) >> > >> > * Fix cross-module instance locations (#383) >> > >> > * Fix alignment of Source link for instances in Firefox (#384) >> > >> > [1]: https://github.com/haskell/haddock/pull/397 >> > [2]: https://github.com/haskell/haddock/pull/410 >> > >> > -- >> > Mateusz K. >> > _______________________________________________ >> > Libraries mailing list >> > Libraries(a)haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Chris Wong (https://lambda.xyz) "Humans find such fascinating ways to waste their time." -- Steven Universe

1 0

Proposal: genericReplicateM
by Ken T Takusagawa 23 Jul '15

23 Jul '15

Overloaded versions of replicateM and replicateM_ for any Integral type: genericReplicateM :: (Monad m, Integral i) => i -> m a -> m [a] genericReplicateM n = sequence . genericReplicate n genericReplicateM_ :: (Monad m, Integral i) => i -> m a -> m () genericReplicateM_ n = sequence_ . genericReplicate n --ken

1 0

Proposal: instance MonadIO Q
by Ryan Scott 23 Jul '15

23 Jul '15

Template Haskell currently has runIO :: IO a -> Q a , which allows you to run IO actions with a guarantee of IO effects' ordering in a single splice (but not necessarily the order in which all the Q splices are run). If runIO is indeed a monad morphism, then there is a law-abiding MonadIO Q instance that could be added to transformers: instance MonadIO Q where liftIO = runIO This would be useful for dealing with monad transformer stacks with Q as the base monad (for an example, see genifunctors (https://github.com/danr/genifunctors/blob/4677bb57423b1b380ce9b50cc3d765a5c…) The only catch is that transformers would have to depend on template-haskell. I think this would be okay since no quasiquotation is involved, but I wanted to hear others' opinions. Ryan

5 6

‘temporary’ takeover
by Mateusz Kowalczyk 23 Jul '15

23 Jul '15

Hi, I'm looking to take over the ‘temporary’ package. This is to address the issue of any patches/fixes into ‘temporary’ not being merged in a timely manner[1]. This caused Roman Cheplyaka to create a fork package, ‘temporary-rc’. It's less than ideal to have some packages use temporary and others use temporary-rc (PackageImports needed…) so this is in attempt to bring back temporary as the one true package to use here and let the fork fall into obscurity, preferably deprecated. The main user of temporary-rc is the popular tasty package which is Roman's. If me/him/us both/someone (reliable/available) can take over temporary, he seems to be willing to go back to using that instead of the fork[2]. CCing the current maintainer. I think until Monday (27th) is a fair notice though I point out more time elapsed on [1] without a reply. [1]: http://www.haskell.org/pipermail/libraries/2014-May/022958.html [2]: https://github.com/feuerbach/temporary/issues/1 -- Mateusz K.

6 6

Re: Proposal: instance MonadIO Q
by Ryan Scott 23 Jul '15

23 Jul '15

> Why would you make it depend on template haskell rather than the other way around? No particular reason, I'd be fine putting the instance in template-haskell instead if that's more palatable.

2 1

ANNOUNCE: fgl-5.5.2.0 and fgl-arbitrary-0.2.0.0
by Ivan Lazar Miljenovic 22 Jul '15

22 Jul '15

I'm pleased to announce that I've (finally!) just released version 5.5.2.0 of [fgl]. Major changes in this release include a test suite, refactorings, code clean-ups and the following potentially breaking changes (in that they were previously unspecified or incorrect): - `nodeRange` and `nodeRangeM` for the various graph data structures erroneously returned `(0,0)` for empty graphs (making them indistinguishable from graphs containing the single node `0`). They now match the default implementation of throwing an error. - The behaviour of `delLEdge` when dealing with multiple edges was unspecified; it now deletes only a single edge and the new function `delAllLEdge` deletes all edges matching the one provided. All changes can be found in the changelog. [fgl]: https://hackage.haskell.org/package/fgl Along with this I'm releasing version 0.2.0.0 of [fgl-arbitrary] (i.e. the "I finally build against the version on Hackage" release). [fgl-arbitrary]: https://hackage.haskell.org/package/fgl-arbitrary -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

3 3