December 2017 - Haskell-Cafe

Question about ST arrays
by Jean-Marc Alliot 29 Dec '17

29 Dec '17

Hi, This is my first post to this list so I apologize in advance if I don't use it properly, or if my question is too simple or inapropriate. I come from the Caml world and I am quite new to Haskell (but not to functional programming). I am currently trying to get the hang of Haskell arrays. I have gone through regular arrays, IO Arrays and I am now working with ST Arrays. This is the problem I am currently stuck with. I write the following code: arr = newArray (-1, 1) 0 :: ST s (STArray s Int Int) get :: Int -> Int get i = runST (arr >>= (\b -> readArray b i)) Here everything is perfectly OK. Now I want a more general version that could deal with any array like arr. So I write: get2 :: ST s (STArray s Int Int) -> Int -> Int get2 tab i = runST (tab >>= (\b -> readArray b i)) And the compiler is clearly very upset by my code: Couldn't match type ‘s’ with ‘s1’ ‘s’ is a rigid type variable bound by the type signature for: get2 :: forall s. ST s (STArray s Int Int) -> Int -> Int at testst.hs:17:9 ‘s1’ is a rigid type variable bound by a type expected by the context: forall s1. ST s1 Int at testst.hs:18:14 Expected type: ST s1 Int Actual type: ST s Int I am pretty sure that the compiler is right and I am wrong, but I don't get why... Anyone could help? Thanks

5 8

[Call for Project Ideas] Haskell.org Google Summer of Code 2018
by Jasper Van der Jeugt 25 Dec '17

25 Dec '17

Google Summer of Code will take place again in 2018 [1]. Last year, Haskell.org was not selected, and we decided to run our own program [2], which ended very successfully [3]. This year, we would like to apply to Google Summer of Code again, since their sponsorship is very significant. The main feedback we received from Google last year was that we didn't really have a great homepage for Summer of Code with ideas for students (things were very rushed and we ended up submitting a link to an outdated bug tracker -- not ideal!). We already started fixing that last year by building a nicer webpage to host ideas [4]. We would now like to call on the community to submit ideas for the students. If you are the maintainer or the user of a Haskell project, and you have an improvement in mind which a student could work on during the summer, please submit an idea here: https://summer.haskell.org/ideas.html Or contact Niki Vazou (nvazou [AT] cs.umd.edu) or myself (m [AT] jaspervdj.be) directly. For context, Google Summer of Code is a program where Google sponsors students to work on open-source projects during the summer. Haskell.org has taken part in this program from 2006 until 2015. Many important improvements to the ecosystem have been the direct or indirect result of Google Summer of Code projects, and it has also connected new people with the existing community. Projects should benefit as many people as possible -- e.g. an improvement to GHC will benefit more people than an update to a specific library or tool, but both are definitely valid. New libraries and applications written in Haskell, rather than improvements to existing ones, are also accepted. Projects should be concrete and small enough in scope such that they can be finished by a student in three months. Best, Niki Vazou & Jasper Van der Jeugt for the Haskell.org Committee [1]: https://opensource.googleblog.com/2017/09/announcing-google-summer-of-code-… [2]: https://summer.haskell.org/news/2017-02-28-2017-announce.html [3]: https://summer.haskell.org/news/2017-09-15-final-results.html [4]: https://summer.haskell.org/ideas.html

1 0

Trouble building happy/alex with Stack lts-9.20
by Eric McCorkle 25 Dec '17

25 Dec '17

Hi folks, I'm trying to update my language project to happy >= 9.16, so I can use typeclass-based parsers. Unfortunately, I'm running into build errors after switching to lts-9.20. The log file is attached. I see similar problems when trying to build alex (the lexer generator). It seems to be claiming that there is no cabal file, which is odd, as there clearly is one (in the source at least). Has anyone else seen this problem, and if so, what is the workaround?

3 4

Supporting Haskell.org
by Tikhon Jelvis 25 Dec '17

25 Dec '17

A significant part of the Haskell community infrastructure—including the haskell.org website, Hackage, Hoogle and the build infrastructure for GHC—runs on donations from the Haskell community administered by haskell.org . You can donate right now using several methods including PayPal and check: https://wiki.haskell.org/Donate_to_Haskell.org Haskell.org can also accept donations through employers via Benevity using the unique ID 475236502. As Haskell.org is a 501(c)(3) non-profit, donations are tax-deductible. This year marked the second Haskell Summer of Code program which provided grants for 15 students working on open source Haskell projects over the summer. The projects improved Haskell tooling and libraries as well as supporting Haskell education through improvements to code.world. A detailed retrospective can be found on summer.haskell.org: https://summer.haskell.org/news/2017-09-15-final-results.html With look forward to continuing this work with your support in 2018 as well as exploring new projects to improve the Haskell community infrastructure. Best wishes, Tikhon Jelvis on behalf of the haskell.org committee.

2 1

ANN: progress-meter 1.0.0
by esz＠posteo.de 25 Dec '17

25 Dec '17

Hi everybody, I have just released a complete API rewrite of the `progress-meter` package: * <https://hackage.haskell.org/package/progress-meter> * <https://github.com/esoeylemez/progress-meter> With this package you can easily add live diagnostics to any long-running application from a simple progress bar to full task monitoring. The `System.Progress` module contains a tutorial. Features: * update progress from multiple threads, * non-progress diagnostics that just scroll by (e.g. logging), * breaking the state apart for individual threads, so they can update their relevant portion of the progress bar without interfering with each other ("zooming"), * smart throttling (no updates drawn when nothing is happening, and only ever drawn at a maximum rate). Here is a very simple example: import Control.Concurrent import System.Progress main = withProgress_ "" id $ \pm -> do -- Set the progress bar: setMeter pm "Working..." -- Do some "work": threadDelay 3000000 -- Print something while temporarily hiding the progress bar: putMsgLn pm "Some extra diagnostics that scrolls by" setMeter pm "Almost done..." threadDelay 1000000 putMsgLn pm "Done." The first argument of 'withProgress_' is the initial state and the second is a renderer for the current state: render :: Int -> String render p = "Progress: " ++ show p ++ "%" withProgress_ 0 render $ \pm -> do threadDelay 1000000 setMeter pm 10 threadDelay 8900000 setMeter pm 99 -- The famous last percent: threadDelay 10000000 putMsgLn pm "Done." Progress-meter will do The Right Thing when you update the state or produce log messages from multiple threads. Happy holidays ertes

1 0

Hackage / Stackage Idea
by alex＠centromere.net 23 Dec '17

23 Dec '17

Hi all, I use Haskell in production, and when choosing a library I wonder, "Is this package production-ready?". In addition to evaluating the quality of the code, I consider various factors such as the most recent upload date, number of downloads, the age of the last commit, the author's reputation, the number of packages which depend on that package, and the number of issues open and closed. I think it would be interesting to add a feature to Hackage and/or Stackage which allows companies to advertise that they use a package in production. If they elect to be anonymous, only the count would increase. I believe that this data would not only help inform my library choices, but also help communicate Haskell's merits to industry. What do you all think? Alex

2 1

Code runs 7x FASTER with profiling
by Neil Mayhew 23 Dec '17

23 Dec '17

I was writing a simple utility and I decided to use regexps to parse filenames. (I know, now I have two problems :-) ) I was surprised at how slow it ran, so I did a profiling build. The profiled code runs reasonably quickly, and is 7x faster, which makes it a bit hard to figure out where the slowdown is happening in the non-profiled code. I’m wondering if I’m doing something wrong, or if there’s a bug in |regex-tdfa| or in ghc. I’ve pared my code down to just the following: |import Text.Regex.TDFA ((=~)) main :: IO () main = do entries <- map parseFilename . lines <$> getContents let check (Right (_, t)) = last t == 'Z' check _ = False print $ all check entries parseFilename :: String -> Either String (String, String) parseFilename fn = case (fn =~ pattern :: [[String]]) of [[_, full, _, time]] -> Right $ (full, time) _ -> Left fn where pattern = "^\\./duplicity-(full|inc|new)(-signatures)?\\.\ \([0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]T[0-9][0-9][0-9][0-9][0-9][0-9]Z)\\." | The relevant part of my |.cabal| file looks like this: |executable DuplicityAnalyzer main-is: DuplicityAnalyzer.hs build-depends: base >=4.6 && <4.11, regex-tdfa >= 1.0 && <1.3 default-language: Haskell2010 ghc-options: -Wall -rtsopts | To run the profiling, I do: |cabal clean cabal configure --enable-profiling cabal build dist/build/DuplicityAnalyzer/DuplicityAnalyzer <names.in +RTS -sprofiling-summary.out -p | The |MUT| time in the non-profiling build is 7x bigger, and the |%GC| time goes from 8% to 21%. I’ve put the actual output in a gist <https://gist.github.com/neilmayhew/247a30738c0e294902e7c2830ca2c6f5>. I’ve also put my test input file there, in case anyone wants to try this themselves. I’ve done my testing with NixOS (ghc 8.0.2) and Debian with the Haskell Platform (ghc 8.2.1) and the results are basically the same. I even tried using Docker containers with Debian Jessie and Debian Stretch, just to eliminate any OS influence, and the results are still the same. I’ve tried it on an i5-2500K, i5-3317U and Xeon E5-1620. I also wrote a dummy implementation of |=~| that ignores the regex pattern and does a hard-coded manual parse, and that produces times just slightly better than the profiled ones. So I don’t think there’s a problem in my outer code that uses |=~|.

5 11

Re: [Haskell-cafe] [ANNOUNCE] GHC 8.4.1-alpha1 available
by Ben Gamari 22 Dec '17

22 Dec '17

George Colpitts <george.colpitts(a)gmail.com> writes: > Probably stating what is obvious and well-know but anyways: > > - On the status page > <https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.4.1> it would be > good to have a link for "Phase 2 of the Semigroup-Monoid Proposal (Herbert > Riedel)" Good catch. I've added a link. > - Also IIRC we normally have a page on porting to the new release. It > would be good to have that also when we have a chance. > Indeed, the migration page can be found here: https://ghc.haskell.org/trac/ghc/wiki/Migration/8.4. I've added a link to the 8.4 status page. Cheers, - Ben

1 0

Happy National Mathematics Day
by Henk-Jan van Tuyl 22 Dec '17

22 Dec '17

L.S., Happy National Mathematics Day to everyone in India! Regards, Henk-Jan van Tuyl -- Message from Stanford University: Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://foldingathome.stanford.edu/ -- http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming --

1 0

Re: [Haskell-cafe] [ANNOUNCE] GHC 8.4.1-alpha1 available
by Oleg Grenrus 21 Dec '17

21 Dec '17

I copy & paste Hervert's reddit answer here [1], for ones who don't follow it: As the suffix "alpha" implies, this is a very bleeding edge release with very little guarantees regarding API stability (c.f. new GHC schedule [2] <https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Releases/NewSchedu…>). Put differently, a package that works now with GHC 8.4.1-alpha1 may not necessarily work with the final GHC 8.4.1 release. In order to support early adopters in testing GHC 8.4.1-alpha, there's a new Overlay Hackage Package Index <https://github.com/hvr/head.hackage> [3] which provides packages patched for unreleased GHCs (currently GHC 8.4.1-alpha1 & GHC 8.5/HEAD). See its README <https://github.com/hvr/head.hackage#README> [4] for instructions on how to use it; there's also a shell script included which automates common workflows; finally there's also support for HEAD.hackage in themake-travis-yml Travis CI script generator <https://github.com/haskell-hvr/multi-ghc-travis>. [5] Don't hesitate to ask if you have questions! As usual, there's already an (incomplete & work-in-progress) GHC 8.4.x Migration Guide <https://ghc.haskell.org/trac/ghc/wiki/Migration/8.4> [6] you can consult and maybe even help complete. Links: - [1]: https://www.reddit.com/r/haskell/comments/7l4b19/announce_ghc_841alpha1_ava… - [2]: https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Releases/NewSchedu… - [3]: https://github.com/hvr/head.hackage - [4]: https://github.com/hvr/head.hackage#README - [5]: https://github.com/haskell-hvr/multi-ghc-travis - [6]: https://ghc.haskell.org/trac/ghc/wiki/Migration/8.4 Cheers, Oleg On 21.12.2017 22:16, George Colpitts wrote: > Thanks Ben. I installed the Mac binaries. > > For others who are wondering, you need llvm 5 if you want to use llvm > with this. > > Needless to say, many libraries, e.g. haskell-src-exts, primitive, and > intero won't compile with this even with --allow-newer > > I'll notify those libraries about that in case they want to get > started on 8.4.1 > > Cheers > George > > On Wed, Dec 20, 2017 at 4:48 PM Ben Gamari <ben(a)well-typed.com > <mailto:ben@well-typed.com>> wrote: > > > The GHC development team is pleased to announce the first alpha > release > of the 8.4.1 release. The usual release artifacts are available from > > https://downloads.haskell.org/~ghc/8.4.1-alpha1 > <https://downloads.haskell.org/%7Eghc/8.4.1-alpha1> > > Note that this release drops compatibility with GCC 4.6 and earlier. > While we generally try to place as few constraints on system toolchain > as possible, this release depends upon the __atomic__ builtins > provided > by GCC 4.7 and later (see #14244). > > > === Notes on release scheduling === > > The 8.4.1 release marks the first release where GHC will be > adhering to > its new, higher-cadence release schedule [1]. Under this new scheme, > major releases will be made in 6-month intervals with interstitial > minor > releases as necessary. > > In order to minimize the likelihood of schedule slippage and to ensure > adequate testing, each major release will be preceeded by a number of > regular alpha releases. We will begin issuing these releases roughly > three months before the final date of the major release and will issue > roughly one every two weeks during this period. This high release > cadence will allow us to quickly get fixes in to users hands and allow > better feedback on the status of the release. > > GHC 8.4 is slated to be released in mid-February but, due to technical > constraints, we are starting the alpha-release cycle a bit later than > planned under the above schedule. For this reason, it would be greatly > appreciated if users could put this alpha through its paces to make up > for lost time. > > As always, do let us know if you encounter any trouble in the > course of > testing. Thanks for your help! > > Cheers, > > - Ben > > > [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > <mailto:Glasgow-haskell-users@haskell.org> > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

2 1