November 2015 - Haskell-Cafe

Type-level lazy bool operations
by Dmitry Olshansky 16 Nov '15

16 Nov '15

Hello, cafe! There are some type-level boolean operation (If, &&, ||, Not) in Data.Type.Bool. Are they lazy enough? I faced with problem and it seems that the reason is non-lazy "If". I.e. both (on-True and on-False) types are trying to be calculated. Does it work in this way really? Could it be changed? Then, looking into source I see such definition for (&&) -- | Type-level "and" type family a && b where 'False && a = 'False 'True && a = a a && 'False = 'False a && 'True = a a && a = a Why we need the last three rules? Does it mean that an order of type calculation is totaly undefined? Dmitry

2 1

wxHaskell can now be run multiple times in GHCi
by Henk-Jan van Tuyl 15 Nov '15

15 Nov '15

L.S., Good news for people who want to develop wxHaskell programs by experimenting in GHCi: wxHaskell programs can now be run multiple times in GHCi (GHC 7.10.2, 32 bit). Running a wxHaskell program in the 64 bit version of the interpreter results in the message: addDLL: could not load DLL This is caused by a GHC bug and is reported in GHC bug ticket 3242 [0], it should be solved in GHC 8.0.1 (The 32 bit GHCi crashes when exited, after running a wxHaskell program, but this is not a problem for application developers.) Regards, Henk-Jan van Tuyl [0] https://ghc.haskell.org/trac/ghc/ticket/3242 -- 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://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming --

1 0

Mono-whatever
by David Feuer 15 Nov '15

15 Nov '15

Does any package define a type like this? data X :: * -> k -> k -> * where X :: b -> X b t t So instance (MonoFoldable b, Element b ~ t) => Foldable (X b t) where foldMap f (X b) = ofoldMap f b

1 0

Daunting heap profile when using (<>)
by martin 14 Nov '15

14 Nov '15

Hello all, I have a Logger which produces log entries and a new version of itself newtype Logger evt dom log = Lgr {runLogger :: Timed evt -> dom -> (log, Logger evt dom log)} Loggers are used in a function like this runSim :: (Ord evt, Monoid log) => SimBehaviour evt dom log -> SimState evt dom log -> SimState evt dom log runSim (!lgr, !hdr, xtp) (!log,!dom,!evq) = case step of Nothing -> (log, dom, evq) -- end of simulation Just (newEvq, newDom, newHdr, newLgr, newLog) -> runSim (newLgr,newHdr,xtp) (newLog,newDom,newEvq) where -- check for end conditions or run handler step = do (evt, evts) <- H.view evq -- no more Events -> Nothing if xtp (evt,dom) then Nothing else let (evq', dom', hdr') = runHandler hdr evt dom (log',lgr') = runLogger lgr evt dom' -- <-- -- append new event and new log entries in return (evq'<>evts, dom', hdr', lgr', log'<>log) -- <-- I then wrote a function to combine two Loggers addLgr (lgr1) (lgr2) = Lgr lgr where lgr tev dom = let (log1', lgr1') = runLogger lgr1 tev dom (log2', lgr2') = runLogger lgr2 tev dom (!log') = log2' <> log1' -- x -- -- in (log2', addLgr lgr1' lgr2') in (log', addLgr lgr1' lgr2') When called a million times, this produces a heap profile which climbs steadily (with or without the stricness annotation in line x). When I omit the (<>) as in the commented line, the heap stays flat. My log is really just a list of strings and most of the time the loggers do not produce any output, i.e. they return an empty list. Am I on the right track, that this trouble is probably caused by laziness and that forcing strictness is the way to go? Could it be that this is because ! does not fully evaluate its argument, but just to WHNF? Or is there a more obvious reason, I just fail to see. Where to go from here?

2 5

test coverage of Parsec parsers
by Aaron VonderHaar 14 Nov '15

14 Nov '15

Hi, I'm adding HUnit tests to a parser that uses Parsec, and I wanted to see test coverage of my parser. I've successfully used hpc to get a coverage report, but it has a significant deficiency: An expression in my parser will show as covered if the expression is ever evaluated, but I'd really like to see branch coverage of the parser monads. For example, if I have a single test that parses the string "*" with the following parser: plusOrStar = do result <- (string "+" <|> string "*") _ <- (many $ string " ") return result then hpc will report that all the code is covered, but I'd like to be able to see the fact that (string "+") only ever failed, and that (string "*") only ever succeeded. Are there any existing tools for getting that sort of coverage report for parsers or monads? Is there an approach other than hpc that I should be considering to get confidence in my test suite? If not, I understand that hpc works by doing source-code transformation--does it seem like a reasonable endeavor to try to customize it to do what I am interested in? Thanks, --Aaron V.

1 0

Do I Need To Write An Instance for Assertable Here?
by Michael Litchard 13 Nov '15

13 Nov '15

Below is some test code I am writing for my game, the link to the entire codebase, the error message and some discussion main :: IO () main = defaultMain [ testGroup "EventNetwork Input" [testBuffer "bBuffer" Populated] ] testBuffer :: String -> BufferState -> Test testBuffer name Populated = testCase name $ assert $ bufferPopulated (UAC (PlayerCommand (Move (ToPlanetName Mongo)) (AID (Data.Text.pack "100")))) testBuffer name Empty = testCase name $ assert $ bufferEmptied (UAC (PlayerCommand (Move (ToPlanetName Mongo)) (AID (Data.Text.pack "100")))) bufferPopulated :: UAC -> MomentIO Bool bufferPopulated ev = do let eInput = ev <$ never eValidated = toVAC <$> eInput bBufferMap <- (buffer eValidated eClear) :: MomentIO (Behavior BufferMap) let r2 = [(Just $ BufferMap $ M.insert (AID (Data.Text.pack "100")) (toVAC ev) (M.empty :: M.Map AID VAC))] r1 <- liftIO $ ((interpret (eBuffer bBufferMap) []) :: IO [Maybe BufferMap]) return $ r1 == r2 bufferEmptied :: UAC -> MomentIO Bool bufferEmptied ev = undefined eBuffer :: Behavior BufferMap -> Event a -> Event BufferMap eBuffer bBufferMap nvr = bBufferMap <@ (() <$ nvr) eClear = Clear <$ (() <$ never) When I run stack build I get tests/Spec.hs:26:19: No instance for (Test.HUnit.Base.Assertable (MomentIO Bool)) arising from a use of ‘assert’ In the expression: assert In the second argument of ‘($)’, namely ‘assert $ bufferPopulated (UAC (PlayerCommand (Move (ToPlanetName Mongo)) (AID (pack "100"))))’ In the expression: testCase name $ assert $ bufferPopulated (UAC (PlayerCommand (Move (ToPlanetName Mongo)) (AID (pack "100")))) The problem lies with buffer. It relies on accumB which requires the MomentIO monad. I considered writing an instance for Assertable, but I think that's a red-herring and the answer lies elsewhere. I need to reconcile the fact that assert wants an IO Bool, but accumB wants a MomentIO. Maybe I do need to write an instance for Assertable. Here's the link to the project:https://github.com/mlitchard/emporos/tree/banana-1.0.0/src

2 2

Where did these threads come from?
by David Turner 13 Nov '15

13 Nov '15

Hi all, I'm working on a server process that has (by design) fairly high memory usage but serves relatively few requests and spends most of its time idle. By 'fairly high' I mean 100s of MB, nothing ridiculous. I'm trying to improve its quiescent CPU usage as this is currently the limiting factor for how cheaply we can run this service - we're aiming for the cheapest t-class EC2 machine we can get. The quiescent CPU usage is currently about 50%. This seems to be largely due to the idle GC, because running with -I0 cuts it down to about 0.3%. Pretty much every time any thread wakes up it triggers the idle GC a short while later and because of the high memory usage these GCs are somewhat expensive. Using threadscope I found the biggest problem was the reaper thread in resource-pool which wakes up every second whether there's anything to reap or not. Fortunately this was easy to spot as the reaper thread labels itself as such. I've replaced this with an event-driven reaper that only wakes up on demand and cut the baseline from 50% down to just under 10%. There are two more threads I can now see waking up periodically in threadscope, with respective periods approximately 10 sec and 30 sec. I have a hunch what the 30-sec one is but no idea about the 10-sec one. If I can kill off the 10 sec one then that should take CPU usage down to <5% which would be just fine. My question: is there any reliable way to determine where these threads came from, in terms of the location of the forkIO call that made them? I've just been looking for likely candidates and labelling threads and this is rather tedious. Cheers, David

2 2

Registration now open: Haskell in Leipzig (Germany) December 4/5
by Johannes Waldmann 13 Nov '15

13 Nov '15

Register now - for Amazing Talks and Thrilling Tutorials: HaL-10 Haskell in Leipzig December 4/5 http://nfa.imn.htwk-leipzig.de/HAL2015/ Opens with an invited talk by Joachim Breitner on MonadFix, closes with a presentation of Liquid Haskell by Michael Beaumont. - Johannes Waldmann. PS: HaL-1 (in 2006, on quite the same day) also had a MonadFix talk. Well of course, this has something to do with recurrence...

1 0

Haskell Platform Plans
by Gershom B 13 Nov '15

13 Nov '15

Dear all, As you know, Mark has passed on the Haskell Platform maintainer hat to me. I wanted to give a heads-up on current plans to keep folks in the loop. This message has three sections, first the 7.10.3 release, next the 8.0 release, and finally some general musings on fiddly details and future plans. 1) 7.10.3 The 7.10.3 release candidates have been out for windows and unix for a bit. As I understand it there is still work underway on the mac build, but that will hopefully be coming shortly. The plan is to release a new platform roughly simultaneously. This platform will work essentially as in the past, for two reasons. First, because it is the last release in the 7.10 series and should be seen like the 7.10.3 compiler as just incorporating some necessary patches rather than any serious changes. Furthermore, the future plans underway rely on a few patches to cabal which have been merged, but are not yet in any existing cabal-install release. A few packages have received minor version bumps, as follows: PACKAGE 7.10.2-a latest ------------------------------------------- case-insensitive 1.2.0.4 1.2.0.5 fgl 5.5.2.0 5.5.2.3 GLUT 2.7.0.1 2.7.0.3 GLURaw 1.5.0.1 1.5.0.2 HUnit 1.2.5.2 1.3.0.0 OpenGL 2.12.0.1 2.13.1.0 OpenGLRaw 2.5.1.0 2.6.0.0 primitive 0.6 0.6.1.0 syb 0.5.1 0.6 scientific 0.3.3.8 0.3.4.2 StateVar 1.1.0.0 1.1.0.1 A few packages were held back due to dependency issues (notably zlib) and additionally, packages shipped with ghc were held back to the versions that will be shipped with 7.10.3. 2) 8.0 We also plan to ship a new platform concurrently with the ghc 8.0 that should be released early next year. That platform will implement some long-discussed and requested changes. First, the platform already ships with msys on windows. However, it does not do so in a way that lets you, as with minGHC, install the network library directly, or for that matter install directly other libraries that use build-type configure. This is because the msys binaries don't get placed into the path, by design. The new platform will ship with a newer cabal, incorporating a patch (pull request #2480) that uses the extra-prog-path setting for build-type: configure. This should allow network and other things reliant on build-type: configure to directly cabal install. The goal for the platform on windows will be that any packages binding to msys libraries _should_ be cabal installable without hassle. If you maintain a library that you think would be a good test-case for this, please drop a line so we can work together towards this goal. Second, the default platform will be _minimal_. That is to say that it will _only_ install into the global package database those packages that are directly shipped with ghc, and not any additional platform packages. "Blessed" platform packages will however still be shipped as a "default user cabal.config" file, so in a setting where users want to work unsandboxed, their versions of platform libs will remain pegged to those chosen by the platform, should they not choose to alter their settings. In a sandboxed setting, or in the presence of a local cabal.config generated by a freeze, those constraints will be disregarded. Furthermore, it is likely but not certain that the "nix-like cabal" or "no-reinstall cabal" will be available for the 8.0 release. If this is the case, users will be able to operate in an unsandboxed environment without conflicts, as multiple instances of the same version of a package, with different dependency choices, will be able to live side-by-side. Third, the platform will ship not only with cabal-install, but also with the stack tool, so that users can choose either workflow, depending on their project or preferences. A number of people have adopted the stack tool, and many beginners have reported success with it as well, so it will be good to provide that functionality out of the box with every platform install. Time and resources permitting we would also like to ship a platform version _with_ the platform libraries prebuilt and included, as that is also a use case that some people continue to like. However, this is a secondary priority, and contingent on us getting our build infrastructure into a good enough shape to make this not too much extra hassle. I'm excited about these changes, and confident we can get their in a timespan that matches the 8.0 release of ghc. 3) Generalities As I mentioned, it would be good to have a more uniform build infrastructure. Generally, I have put out some feelers and am working towards extending the ghc nightly buildbot infrastructure to both cover more platforms and also cover more tools -- not only ghc, but cabal, the platform, perhaps haddock, ghcjs, etc. This way we can get an economy of scale and many of our core tools will be able to all share regular automated builds across many platforms. If you like CI/buildbot systems and would like to help out with this project, please reach out. Also, once we've modernized and fixed up the core platform installer tech, it would be nice to move back to the process of making the platform a good set of blessed libraries -- taking more proposals for additions to it, looking to cull libraries that are no longer widely used, etc. As part of this I intend to move the haskell-platform list off our deprecated community.haskell.org infrastructure and onto mail.haskell.org with our other active lists. Finally, I'm happy to be maintainer of the platform through this period of change and transition, but at some future point, as things get sorted out and the release process becomes more standard and mechanical, I would very much like to pass this responsibility on. I have had some nibbles of offers, but if other people want to begin to get involved, please let me know and we can start to get small contributions from you so that you can become familiar with the various tech and systems involved. The Haskell ecosystem is a team effort, a collective project, and volunteer driven. In my modest experience hacking on the various systems involved (cabal, cabal-install, hackage, the platform build, etc.) some are a bit confusing, but I have always found helpful contributors willing to explain things and review patches, and to help think about and diagnose problems. And none of the code has been as confusing as things I've had to wade through for employment-related purposes :-). So when this stuff doesn't work as well as we'd like, we can investigate together, and then put our heads together and figure out how to improve it together. Furthermore, it can be very satisfying to do so, because the impact of those improvements makes itself widely felt. I look forward to more people joining in! Best, Gershom

1 0

Re: [Haskell-cafe] haskell-src-exts maintenance
by Matthew Pickering 12 Nov '15

12 Nov '15

Peter, Please can you do the release. I completed the work updating HSE several months ago, a much better version of HSE has been waiting on the master branch since then. I thank you for providing helpful review for the patches I submitted but since then I have sent three emails asking about the release. After the second you promised to do a release at the end of October but that never happened. It is a shame that the user's of HSE have had to live with many long standing bugs when they have been fixed for months. If you can not do it for whatever reason then please can you add me as a maintainer on hackage and the github repo so that users can get an updated version of HSE. Best wishes, Matt On Tue, Jul 28, 2015 at 11:35 PM, Peter A Jonsson <jonsson.peter.a(a)gmail.com> wrote: > I’m not even going to bother to CC haskell-cafe since that will just bounce or go into a black hole. > > I exchanged a couple of mails with David (Lemmih) and my impression was that he was going to act upon some things but I didn’t follow up on that so there was probably some miscommunication between the two of us. > > I’ve merged some things and reviewed some patches. I agree with Neil that stable things should be merged and the yearly release of HSE should be made. I don’t want to rush things out through the door at any cost though—I believe HSE’s users are better served by something that is a strict improvement and contains more features than the last release compared to something that has even more features but is a bit shaky and requires a new major version of HSE in just a month or two which would force the client code to be re-tested and re-released. > > Best Wishes, > > Peter > >> On 28 Jul 2015, at 17:49, Neil Mitchell <ndmitchell(a)gmail.com> wrote: >> >> As a very heavy HSE user (HLint and Hoogle), who has had a reasonably >> close working relationship with all of Niklas (my SoC mentor and my >> SoC mentee), Roman and Peter (a fellow supercompiler developer) and >> Matt (currently hacking on HLint), I thought I should weigh in. >> >> The current state of HSE is a little forlorn - there are 22 open pull >> requests, everything from reducing algorithm complexity (an accidental >> n^3), fixing the default encoding (should be UTF8) and lots of actual >> parser fixes. A lot of this is good stuff, and the high level of >> external contributions is a really good sign. But they need to be >> merged and reviewed, and it seems the bandwidth just isn't there at >> the moment. Given Matt's comments on the existing tickets, and the >> triage he's already performing on the repo, I have high hopes that >> Matt could provide a bit more of the time and attention. Peter, >> perhaps a co-maintainer would be good for a little while? >> >>> If it's not soon then please could you add myself and Christian to the >>> maintainers so that we can perform some short term maintenance. My >>> immediate plan of action would be >>> >>> 1. Immediately cut a 1.17 release from the master branch as it >>> contains much better parsing of lifted constructors which are becoming >>> more prevalent. >>> 2. Review and merge recent pull requests. >>> 3. Update the parser as far as possible with missing features. >>> 4. Release 1.18 with these improvements within 1 month. >> >> Awesome! Although as a preference I'd go for as much of 2 as you can >> in a couple of days before doing 1 - a lot of the patches are simple >> and valuable, and a 2 day wait isn't going to be too problematic. >> >> Thanks, Neil >

1 0