October 2014 - Glasgow-haskell-users

Thread behavior in 7.8.3
by Michael Jones 22 Jan '15

22 Jan '15

I have a general question about thread behavior in 7.8.3 vs 7.6.X I moved from 7.6 to 7.8 and my application behaves very differently. I have three threads, an application thread that plots data with wxhaskell or sends it over a network (depends on settings), a thread doing usb bulk writes, and a thread doing usb bulk reads. Data is moved around with TChan, and TVar is used for coordination. When the application was compiled with 7.6, my stream of usb traffic was smooth. With 7.8, there are lots of delays where nothing seems to be running. These delays are up to 40ms, whereas with 7.6 delays were a 1ms or so. When I add -N2 or -N4, the 7.8 program runs fine. But on 7.6 it runs fine without with -N2/4. The program is compiled -O2 with profiling. The -N2/4 version uses more memory, but in both cases with 7.8 and with 7.6 there is no space leak. I tired to compile and use -ls so I could take a look with threadscope, but the application hangs and writes no data to the file. The CPU fans run wild like it is in an infinite loop. It at least pops an unpainted wxhaskell window, so it got partially running. One of my libraries uses option -fsimpl-tick-factor=200 to get around the compiler. What do I need to know about changes to threading and event logging between 7.6 and 7.8? Is there some general documentation somewhere that might help? I am on Ubuntu 14.04 LTS. I downloaded the 7.8 tool chain tar ball and installed myself, after removing 7.6 with apt-get. Any hints appreciated. Mike

9 29

Re: GHC 7.4.2 on Ubuntu Trusty
by Yitzchak Gale 04 Jan '15

04 Jan '15

I wrote: >> This thread makes it clear what a mess >> we have inherited from the days when GHC was primarily a >> research compiler. Let's face it - GHC is now also a serious >> production compiler, and this urgently needs to be cleaned up. hvr wrote: > Are you referring to the GMP dependency or something else? > ...I'm not sure what can be done differently here. Agreed. No, not any one of those many little details. I mean the general extreme difficulty of getting almost any version of GHC working on almost any platform, unless the two were released within a fairly short time of each other. Well, that is, not counting your wonderful ppa for Ubuntu. That is fantastic - but the dire need for it is evidence for the severity of the problem. How about this: Currently, every GHC source distribution requires no later than its own version of GHC for bootstrapping. Going backwards, that chops up the sequence of GHC versions into tiny incompatible pieces - there is no way to start with a working GHC and work backwards to an older version by compiling successively older GHC sources. If instead each GHC could be compiled using at least one subsequent version, the chain would not be broken. I.e., always provide a compatibility flag or some other reasonably simple mechanism that would enable the current GHC to compile the source code of at least the last previous released version. I realize that this might be disruptive to GHC devs, because as a compiler with a research heritage, GHC experiments with its own new features on its own source code. But as a compiler that is used commercially, some general kind of backward portability is critically important. The other direction is equally problematic. Although GHC does support bootstrapping itself from a few previous releases, porting GHC to a new platform has become harder and harder as GHC becomes more complex. I think this could become a threat to the viability of GHC - technology is always changing. As a commercial developer, I am always plagued by nagging worry about GHC portability, forward and backward. Will we always be able in the future to support code we release, or will it die someday because there will no longer exist a GHC able to compile it? Will our whole technology die someday just because we can't get GHC working on a platform we need to support? Thanks, Yitz

2 3

Rules for class methods and Safe Haskell
by Wolfgang Jeltsch 13 Nov '14

13 Nov '14

Hi, the module Control.Arrow declares a set of rules for the Arrow class. It is marked “Trustworthy”, probably to allow these rules to actually fire. Now these rules are only correct for class instances that actually satisfy the arrow laws. If the author of another module defines an instance of Arrow that does not respect the laws, this other module could still be considered “Safe” by GHC, although the rules from Control.Arrow are bogus now. Is this considered a problem? All the best, Wolfgang

2 2

Recursion on TypeNats
by Barney Hilken 29 Oct '14

29 Oct '14

If you define your own type level naturals by promoting data Nat = Z | S Nat you can define data families recursively, for example data family Power :: Nat -> * -> * data instance Power Z a = PowerZ data instance Power (S n) a = PowerS a (Power n a) But if you use the built-in type level Nat, I can find no way to do the same thing. You can define a closed type family type family Power (n :: Nat) a where Power 0 a = () Power n a = (a, Power (n-1) a) but this isn't the same thing (and requires UndecidableInstances). Have I missed something? The user guide page is pretty sparse, and not up to date anyway. If not, are there plans to add a "Successor" constructor to Nat? I would have thought this was the main point of using Nat rather than Int. Barney.

4 11

Irreducible predicates error in Template Haskell
by Sreenidhi Nair 29 Oct '14

29 Oct '14

Hello, we were trying to reify a typeclass, which had a ConstraintKind and we hit upon this error: "Can't represent irreducible predicates in Template Haskell:". It seems that there is already a ghc bug [ https://ghc.haskell.org/trac/ghc/ticket/7021 ] filed and its status is set as fixed, but there is a comment at the bottom in which the reviewer recommends against merging immediately. Does anybody know when it would get merged in? -- Yours truly, Sreenidhi Nair

2 1

Hiding module *exports*
by Tom Murphy 27 Oct '14

27 Oct '14

(Not to be confused with the "hiding import behavior" discussion also going on) -- Currently, I'm able to write "module Foo where" to export everything defined in Foo. If, though, I add to the module some definitions which I don't want to export... data Lockbox = MkLockbox Int internalFunction = ... ...I then have to explicitly enumerate everything that I *do* want the module to export, and add to that list each time I add to the module. I propose that instead, we're able to simply say what we mean: module Foo hiding (Lockbox(MkLockbox), internalFunction) where I think its semantics are immediately clear to the reader. There's a little bit of bikeshedding that needs to happen (e.g. is "hiding (Foo(..))" sufficient to hide the type Foo and not just its constructors), but are people +1 on this? I've frequently wanted this behavior. Tom

9 10

ghci balkiness on OS X?
by Evan Laforge 25 Oct '14

25 Oct '14

On my OS X, if I load a couple hundred modules into ghci as bytecode, text entry gets balky and laggy. So e.g. if I hold down a key, the letters will stream in but have frequent hiccups. This seems to adversely affect haskeline as well, such that, using vi mode, sometimes ^[ to move to command mode will be lost, or it will spontaneously go to insert mode, or ^[ followed by 'h' will be just beep and remain in insert mode. If I load most of the modules compiled, this doesn't happen, or at least is not nearly so bad. It doesn't seem to be due to background work by ghci or anything, because it doesn't matter how long I wait after loading the modules. My previous random guess was that increased memory use made the GC work more, and my pauses were due to major collections. But when I try on linux, ghci remains responsive no matter how many modules I load, so maybe it's an OS X only problem. Do any other OS X users see this effect?

3 3

Hiding import behaviour
by Malcolm Gooding 24 Oct '14

24 Oct '14

With the prelude changes that people have been discussing recently I've been wondering is there any reason why importing an identifier explicitly and unqualified doesn't automatically hide any implicit imports of the same identifier? Specifically I'm wondering about cases where you've imported an identifier explicitly from only one module, like this: module Foo (x, ...) where { ... } module Bar (x, ...) where { ... } import Bar import Foo (x) Even if you needed a pragma to enable it I can't think of any sensible reason why that shouldn't be equivalent to: import Bar hiding (x) import Foo (x) I don't know much of GHC's internals, but it seems like a pretty minimal change. Typing rules remain the same; explicit imports just shadow implicits. So importing multiple identifiers both implicitly or both explicitly would remain ambiguous.

12 30

Type checker plugins
by Adam Gundry 23 Oct '14

23 Oct '14

Hi folks, Those of you at HIW last week might have been subjected to my lightning talk on plugins for the GHC type checker, which should allow us to properly implement nifty features like units of measure or type-level numbers without recompiling GHC. I've written up a wiki page summarising the idea: https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker Feedback is very welcome, particularly if (a) you have an interesting use for this feature or (b) you think this is a terrible idea! Thanks, Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

5 11

Re: GHC 7.4.2 on Ubuntu Trusty
by Yitzchak Gale 22 Oct '14

22 Oct '14

I wrote: >> How do I get a working GHC 7.4.2 on Trusty? Thanks to all for the suggestions. Daniel Trstenjak wrote, off-list: > I can only recommend: https://launchpad.net/~hvr/+archive/ubuntu/ghc Thanks Daniel! I hadn't looked at Herbert's ppa for a while. Despite the comments, which say it is only updated for precise but should also work for trusty, the ppa actually *is* updated for trusty now. This is trivially simple to use and worked great, so that's what I ended up using. But still - something really really needs to be done about GHC portability. This thread makes it clear what a mess we have inherited from the days when GHC was primarily a research compiler. Let's face it - GHC is now also a serious production compiler, and this urgently needs to be cleaned up. Thanks, Yitz

1 0