- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] haskell-src-exts maintenance
by malcolm.wallace 16 Nov '15

16 Nov '15

We too have been waiting a long time for a refreshed release of HSE. If Matthew has already made the edits, and we are simply awaiting the package's release to Hackage, perhaps Matthew should go ahead make that release himself, and petition the Hackage admins to accept it, in view of the official maintainers' long silence? Regards, Malcolm On 12 Nov, 2015,at 05:37 PM, Matthew Pickering <matthewtpickering(a)gmail.com> wrote: 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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

2 1

The last decade: what has changed, was has stayed the same?
by Joachim Durchholz 16 Nov '15

16 Nov '15

Hi all, I used to be interested in Haskell roughly a decade ago, then life happened. Now that I'm setting up project work, I'm interested in what has been happening in the meantime. I read a bit on the usual pages, did a quick scan of the mailing list, didn't find out what the important questions of today are and what answers exist. Some ideas of relevant questions below. Feel free to pose and answer your own questions :-) After learning the bare language, how long does it take a competent programmer to become confident in the performance of his Haskell code? After learning the bare language, how long does it take a competent programmer to know when and when not to use strictness annotations/operators? I'm seeing a lot of typesystem golf happening. Is this teachable to the average competent programmer? Is it relevant to everyday programming such as business logic, database access, or webpage generation? (If no, for what programming endeavours is it relevant?) What's the status of debugging - I dimly remember a rough consensus that stack traces are hard to interpret in a meaningful way. (I know that debugging is far less important for a referentially transparent language than for others, but it would still be interesting.) What's the status of all the "boring stuff": - logging - profiling - dialog layout - input validation - database interaction - webpage generation, webflow - multi-tiered applications On the "instant to-do" side: What would a competent programmer need to do to become a competent Haskell programmer? (I suspect the usual set of toy projects will not work. Toy projects give you only so much mileage; in particular, you don't learn anything about what patterns will hold up for larger projects and what patterns won't scale.) Regards, Jo

2 2

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 16 Nov '15

16 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 15 Nov '15

15 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 14 Nov '15

14 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