August 2014 - Glasgow-haskell-users

cabal repl failing silently on missing exposed-modules
by cheater00 . 08 Aug '14

08 Aug '14

Hi, I have just spent some time trying to figure out why all of a sudden "cabal repl" silently exits without an error message. What helped was to take a project that could launch the repl and compare the cabal files to my new project. It turns out the exposed-modules entry was missing. I was wondering whether this behaviour was intentional, as I don't recollect this happening before, but I don't have older systems to test this on. The reason I wanted to run a repl without editing exposed modules was to test some dependencies I pulled in to the sandbox with cabal install. The package in question didn't have any code of its own yet. In this case I would just expect ghci to load with the Prelude. Thanks!

3 5

Re: Overlapping and incoherent instances
by Ben Millwood 07 Aug '14

07 Aug '14

On Sat, Aug 02, 2014 at 08:51:57PM +0100, Ben Millwood wrote: >On Sat, Aug 02, 2014 at 04:27:14PM +0100, Ben Millwood wrote: >>On Thu, Jul 31, 2014 at 07:20:31AM +0000, Simon Peyton Jones wrote: >>>My main motivation was to signal the proposed deprecation of the global per-module flag -XoverlappingInstances. Happily people generally seem fine with this. It is, after all, precisely what deprecations are for ("the old thing still works for now, but it won't do so for ever, and you should change as soon as is convenient"). >> >>Here's one concern I have with the deprecation of >>-XOverlappingInstances: I don't like overlapping instances, I find >>them confusing and weird and prefer to use code that doesn't >>include them, because they violate my expectations about how type >>classes work. When there is a single LANGUAGE pragma, that's a >>simple, easily-checkable signpost of "this code uses techniques >>that Ben doesn't understand". When it is all controlled by pragmas >>I basically have to check every instance declaration individually. >> >>On a largely unrelated note, here's another thing I don't >>understand: when is OVERLAPPABLE at one instance declaration >>preferable to using only OVERLAPPING at the instance declarations >>that overlap it? In the latter model, as long as none of the >>instances I write have pragmas, I can be sure none of them overlap. >>In the former model, any instance I write for an existing typeclass >>might overlap another instance, even if I don't want it to. Do we >>have any specific use cases in mind for OVERLAPPABLE? >>_______________________________________________ >>Libraries mailing list >>Libraries(a)haskell.org >>http://www.haskell.org/mailman/listinfo/libraries > >When I originally sent this mail I wasn't subscribed to the GHC >lists, so I went and fixed that and am now resending. Good grief, and then I sent from the wrong address. Sorry for the noise. >Addendum: I was surprised by the behaviour of overlapping instances >when I went and looked closer at it. > > {-# LANGUAGE FlexibleInstances #-} > module M where > class C a where f :: a -> a > instance C a where f x = x > instance C Int where f x = x + 1 > >I suspect many people have the intuition that NoOverlappingInstances >should forbid the above, but in fact OverlappingInstances or no only >controls instance *resolution*. I imagine you all already knew this >but I did not until I carefully reread things. > >As someone who dislikes overlapping type class instances, I am >finding them harder to avoid than I at first thought :(

4 4

Old code broken by new Typeable class
by Volker Wysk 05 Aug '14

05 Aug '14

Hi! I've been working with GHC-4.6.3, and updating to GHC-4.8.3 breaks my code, because the Typeable class has been changed. The compiler produces this message: --------- src/HsShellScript/ProcErr.chs:2294:4: ‘typeOf’ is not a (visible) method of class ‘Typeable’ --------- I want to define System.Posix.Process.ProcessStatus to be an instance of Typeable, so I can throw and catch it as an exception. ProcessStatus isn't typeable by default. Is it still possible to make ProcessStatus a member of Typeable? How? Obviously, you can't accomplish it by deriving Typeable, because the definition can't be changed any longer. This is the spot in question: ---------- import System.Posix.Process import Data.Typeable {- data ProcessStatus = Exited ExitCode / | Terminated Signal/ / | Stopped Signal/ deriving (Eq, Ord, Show) -} instance Typeable ProcessStatus where typeOf = const tyCon_ProcessStatus tyCon_ProcessStatus = mkTyConApp (mkTyCon3 "hsshellscript" "HsShellScript.ProcErr" "Posix.ProcessStatus") [] instance Exception ProcessStatus ---------- Thanks, V.W.

5 9

Cross compiling for Cortex A9
by Michael Jones 05 Aug '14

05 Aug '14

I am having problems building a GHC cross compiler for Linux (Yocto on a Wandboard) running on a Cortex A9, and need some advice on how to debug it. The cross compiler produces an executable that runs on the Target, but fails to print. So I need help coming up with a strategy to narrow down the root cause. Some details: The application: main = do putStrLn "Haskell start" The command line options work. The program runs, and I can step through assembly. Debug data is printed to the console. But putStrLn fails, and program enters an infinite loop. I compile my app as follows: arm-unknown-linux-gnueabi-ghc -debug -static Main.hs Using -threaded does not fix the problem. Let me compare debug data from a run on my HOST, with a run on my TARGET. First, a run from my HOST: created capset 0 of type 2 created capset 1 of type 3 cap 0: initialised assigned cap 0 to capset 0 assigned cap 0 to capset 1 cap 0: created thread 1 cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (suspended while making a foreign call) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (finished) cap 0: created thread 2 cap 0: running thread 2 (ThreadRunGHC) cap 0: thread 2 stopped (finished) cap 0: starting GC cap 0: GC working cap 0: GC idle cap 0: GC done cap 0: GC idle cap 0: GC done cap 0: GC idle cap 0: GC done cap 0: GC idle cap 0: GC done cap 0: all caps stopped for GC cap 0: finished GC removed cap 0 from capset 0 removed cap 0 from capset 1 cap 0: shutting down deleted capset 0 deleted capset 1 And, it prints properly. So this is my referenced for what it should do on the TARGET. When I run on my TARGET, I get: created capset 0 of type 2 created capset 1 of type 3 cap 0: initialised assigned cap 0 to capset 0 assigned cap 0 to capset 1 cap 0: created thread 1 cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (heap overflow) cap 0: starting GC cap 0: GC working cap 0: GC idle cap 0: GC done cap 0: GC idle cap 0: GC done cap 0: GC idle cap 0: GC done cap 0: all caps stopped for GC cap 0: finished GC cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) ... And the debug data goes on forever, just as debugging assembly demonstrated an infinite loop. Clearly, the following does not occur: cap 0: thread 1 stopped (suspended while making a foreign call) And there are overflows. If I had to guess, it is possible that some code is in a loop retrying to foreign call, and failing. Certainly, it is in some kind of a loop, because I found a place I can put a break point and and telling GDB to continue will cause the break over and over at the same place. So somewhere there is a loop. I can step through the application with GDB and see names of files and offsets in assembly. But without a true source code debug, that is a bit rough, especially for someone that does not know the RTS code. If there was a way to compile such that C source code was available and a place to break, that would help. However, I suspect since it never makes a foreign call, there is no place in C to place the breakpoint anyway. So I am also assuming there is no direct way to debug with GDB. But, I can see debug output printed to the console. My hope is there is a way to enable more printing, or a place I can add more print functions to help find the problem. So I think I need one of the following: - A solution from someone that has seen this before, perhaps on the iPhone - How to enable more debug logging - Where in the source code to add debug statements to narrow down the problem Thanks for any help you can give. Mike

4 22