- Haskell-Cafe - Haskell.org

Hackage trustee proposal: Curating the Hackage package collection
by Adam Bergmark 31 Mar '15

31 Mar '15

Dear Haskell Community, For some time Hackage has contained a user group called "Trustees", http://hackage.haskell.org/packages/trustees/ . Description: The role of trustees is to help to curate the whole package collection. Trustees have a limited ability to edit package information, for the entire package database (as opposed to package maintainers who have full control over individual packages). Trustees can edit .cabal files, edit other package metadata and upload documentation but they cannot upload new package versions." In short, making sure that packages keep building and filling the gap between unreachable maintainers and package take-overs. Up until now we have been very careful with changes since we haven't had a defined process. Spurred by SPJ and others we have been working on a proposal for how we should operate. You can find the proposal here: https://gist.github.com/bergmark/76cafefb300546e9b90e We would now like your feedback! Some specific things from the proposal that we'd like your opinion on: * Section 1: No opt-out for restricting bounds * Section 2: Opt-out rather than opt-in procedure for loosening version constraints * Section 2: Do you care whether you are notified before or after a version constraint is loosened? * Section 3: The time frame for publishing simple source changes * Section 3: What exactly should constitute a "simple source change" We also have a github repository where YOU can file issues about broken packages, you can start doing this right now! https://github.com/haskell-infra/hackage-trustees/ Please share this with as many people as possible. We are looking forward to hear your thoughts! Sincerely, Adam Bergmark

6 8

Opt-in upper-bounds notification service?
by Joachim Breitner 31 Mar '15

31 Mar '15

Hi, I don’t always have a complete oversight of what our ecosystem provides... do we already have a way to (opt-in) get a mail when a dependency of one of my packages was uploaded in a version that is beyond the upper-bound specified by my packages? Currently I get pinged by Michael Snoyberg when that happens, e.g. in https://github.com/fpco/stackage/issues/514, but that’s always a short while after the problem, and I’d like to fix this before anyone manually notices. If someone would hack up such as service, I’d be happy to use it. Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

3 4

Template haskell and the dependencies of the generated executable
by Aldo Davide 31 Mar '15

31 Mar '15

When I use template haskell to generate some code at compile time and splice it in my program, the generated executable still depends on template haskell (in case of -dynamic), or the Template haskell library is included in my executable (in the case of -static). Isn't that unnecessary? For example. Suppose that I use the almost trivial raw-strings-qq package to implement a hello world program: {-# LANGUAGE QuasiQuotes #-} import Text.RawString.QQ (r) main = putStrLn [r|Bonjour tout le monde|] Then the r quasi quoter runs at compile time and generates a string literal. So basically, the program that gets compiled is the following: main = putStrLn "Bonjour tout le monde" Despite that template haskell is only used at compile time, the generated executable (compiled with the -dynamic flags) depends on the following libraries: libHSarray-0.5.0.0-ghc7.8.4.so libHScontainers-0.5.5.1-ghc7.8.4.so libHSdeepseq-1.3.0.2-ghc7.8.4.so libHSpretty-1.1.1.1-ghc7.8.4.so libHSraw-strings-qq-1.0.2-ghc7.8.4.so libHStemplate-haskell-2.9.0.0-ghc7.8.4.so in addition to the ones that the non template haskell version of the program depends. Shouldn't ghc avoid that?

1 0

Looking for Haskell contract work
by Alexander Berntsen 31 Mar '15

31 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hallo Haskell friends, My company[0] uses Haskell for most of our work. Speaking of work, we are currently looking for some more of it. If anyone has some work (FSVO "work" that includes hacking, advising, teaching, etc.), please contact me off-list. Thanks! [0] plaimi: <https://secure.pe.plaimi.net>. - -- Alexander alexander(a)plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlUaphUACgkQRtClrXBQc7UySwD/digSIVDgS25tRW4zUtfoO/E3 /vWOMwMRnn9nfFcirrAA/0fFsl8WogNG/J2AP188517xcV4zLV1up7YtUsbEWRnh =JbNc -----END PGP SIGNATURE-----

1 1

ANN: base-compat updated for AMP + request for collaboration
by Simon Hengel 31 Mar '15

31 Mar '15

Hi, I updated base-compat[1] for the recent AMP/Foldable/Traversable changes and base-4.8.0.0. A new version 0.6.0 is on Hackage. The purpose of base-compat is to provide a way to write code that works with multiple versions of GHC without the need for CPP. The idea is to have .Compat modules (e.g. Control.Exception.Compat) that provide the same interface across all supported versions of GHC (we test GHC 7.* on travis and I test 6.12.3 manually). The main focus of this release is to make Prelude.Compat as complete as possible to help with the AMP/Foldable/Traversable transition. Prelude.Compat now exposes the exact same interface as Prelude from base-4.8.0.0. It can be used together with -XNoImplicitPrelude to write code that works with all supported versions of GHC, e.g.: {-# LANGUAGE NoImplicitPrelude #-} import Prelude.Compat main :: IO () main = mapM_ print (Just 23) Prelude.Compat is complete and we have tests that ensure that the interface is the same for all supported versions of GHC. But other modules still need more work. In the past base-compat did not get the love it deserves, but I'm committed to put more effort into it and make it as complete as possible. Any help with that effort would be greatly appreciated. If you want to help, please open issues and pull requests on GitHub, or send me feedback by email or on IRC (solirc on Freenode). Cheers, Simon [1] http://hackage.haskell.org/package/base-compat

1 0

GHC update from 7.8.4 to 7.10.1 breaks 1, 500 packages in NixOS
by Peter Simons 31 Mar '15

31 Mar '15

Hi guys, the Nixpkgs distribution [1] contains all of Hackage -- 7,898 packages at the time of this writing --, and we regularly build these packages with GHC 7.8.4 in our CI environment [2] running NixOS Linux. About 3,000 of these builds are disabled outright, because we know they won't succeed anyway (i.e. they have dependencies we cannot fulfill), but the remaining 5,000 packages compile successfully most of the time. Now, a few days ago, we created a separate build job [2] that compiles the same package set with GHC 7.10.1, and the result is interesting: with the newer compiler, approximately 1,500 packages are broken compared to the state with 7.8.4. A detailed list of broken packages can be found at [4]. Keep in mind that those figures only approximate reality. For instance, we patch packages sometimes to make their builds succeed even though the pristine version would not, and so far much more effort has gone into fixing 7.8.4 builds than we spent on fixing 7.10.1 builds. Also, some packages may compile fine when you run "cabal install <foo>" on your workstation, but those builds may fail in the context of NixOS for whatever reason. If anyone were to repeat this experiment on Darwin, Windows, Ubuntu, or Red Hat, the results would be different from our numbers! Still, based on the information we have, it's probably fair to say that the GHC 7.10.1 update breaks approximately 30% of all Haskell builds that worked with 7.8.4. Best regards, Peter [1] https://github.com/nixos/nixpkgs [2] http://hydra.cryp.to/jobset/nixpkgs/haskell-updates [3] http://hydra.cryp.to/jobset/nixpkgs/haskell-updates-ghc7101 [4] http://hydra.cryp.to/eval/304489#tabs-still-fail

2 1

GHC 7.10.1 on OS X
by Yongqian Li 30 Mar '15

30 Mar '15

Does anyone know how to resolve this issue? When I do a "cabal build", I get error: unknown directive .macosx_version_min 10, 0 ^ <no location info>: Error running clang! you need clang installed to use theLLVM backend (or GHC tried to execute clang incorrectly) <no location info>: ghc: phase `Clang (Assembler)' failed (exitcode = 1) However, my clang is fine, as is my LLVM: % clang --version Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix % opt --version LLVM (http://llvm.org/) LLVM version 3.5.1 Optimized build with assertions. Built Jan 15 2015 (18:24:46). Default target: x86_64-apple-darwin14.1.0 Host CPU: core-avx2

2 1

linear: instance Additive (Point f) ??
by Richard Eisenberg 30 Mar '15

30 Mar '15

Hi café, I'm in the middle of responding to https://github.com/goldfirere/units/pull/45 and trying to learn the `linear` package, which I have yet to use. I have what may be a basic question: why is there an `instance Additive f => Additive (Point f)` (in the Affine module)? It would seem that the whole point of Point is that it is *not* Additive. We don't want to add Points! Could someone enlighten me? Thanks! Richard PS: Of course, this instance is directly hurting my use of the package. But it is hurting my understanding of the package, because it disagrees with the mental model I've built up of the definitions.

4 6

New Functional Programming Job Opportunities
by Functional Jobs 30 Mar '15

30 Mar '15

Here are some functional programming job opportunities that were posted recently: Full-stack Software Engineer at Capital Match http://functionaljobs.com/jobs/8802-full-stack-software-engineer-at-capital… Cheers, Sean Murphy FunctionalJobs.com

1 0

preprocessing and Parsec
by Maurizio Vitale 30 Mar '15

30 Mar '15

G'day, I'm implementing a parser for a language that has a preprocessor. It has `include, `ifdef..`else..`endif, `define and uses of the `defined fragments, which are also prefixed by '`'. I can think of two ways of doing this: a preprocess :: Stream->Stream (for String, Text, ByteString) or processing preprocessor directives as part of the"whitespace skipping" at begin of file and after each token. The first one seems cleaner/easier (and also allow parsers not to require a (restricted) IO monad for reading files). The second one, seems to make easier to give nice error messages (in the separate preprocessor way, you can add something like #line to tell where inclusions came from, but you cannot easily do this for macro replacement). My eventual goal is to give clang-like error messages with macro expansion backtrace. Any recommendations? pointers to examples of parsec-based parsers that have a pre-processing step? Thanks, Maurizio

1 0