p.k.f.holzenspies | 23 Jul 18:06 2014
Picon
Picon

GhcPlugin-writing and "finding things"

Dear GHC-ers,

I'm working on a plugin for GHC that should help compile the library with which this plugin is to ship. What
this plugin does is traverse the CoreProgram(s) to find things of types defined in my library and
optimizes them. I have worked out how to "find" things, but I was wondering whether the API could be
improved for plugin-writers.

For the sake of argument, I have the following:
 - module Foo: library for users to import, containing functions, ADTs etc
 - module Foo.Plugin: GhcPlugin that compiles out all uses of things in Foo

> module Foo where
>
> data Foo x = Foo x
>
> runFoo :: Foo x -> x
> runFoo (Foo x) = x

This example is trivial and I imagine GHC will have no trouble eliminating most cases of this, but imagine
more complex stuff. Now, if I want to traverse the CoreProgram in my plugin, I need to find occurrences of
these, so somewhere there's stuff like:

> pass tcFoo _ _ (NonRec b expr)
>   | varType b `containsTyConAnywhere` tcFoo
>     = {- clever stuff to compile out Foo -}

My problem is "getting" tcFoo in this example. Below is how I do it now. Maybe I'm being thick, or maybe
there's just no simpler way. This is my 'plugin' function in Foo.Plugin:

> plugin = Plugin $ \opts todo -> do
(Continue reading)

Jan Stolarek | 23 Jul 13:57 2014
Picon

Looking for list comprehensions use cases

Haskellers,

recently I've been looking into the possibility of creating some new optimisations for GHC. These 
would be mostly aimed at list comprehensions. Here's where I need your help:

1. Do you have complex list comprehensions usage examples from real code? By complex I mean  
nested list comprehensions, reading from more than one list ([ ...| x <- xs, y <- ys ... ]) etc.

2. Do you have list comprehensions code that you had to optimize by hand because GHC was unable to 
make them fast enough?

Janek
cheater00 . | 21 Jul 19:51 2014
Picon

Type family stopped compiling on upgrade from GHC 7.6.3 to 7.8.3

Hi, I was experimenting a bit with type families recently and ran into
a bit of an issue. Given that I don't know type families that well
yet, I was wondering if I made an error somewhere. One thing is that I
can't find any relevant changes in the GHC release notes for 7.8.1, .2
or .3.

Maybe this code contains an error which 7.6.3 simply wasn't able to find?

Thanks.

--------

-- this code compiles in 7.6.3, but breaks in 7.8.3 with the following message:
-- TypeFamilies.hs:14:31:
--     ‘End’ of kind ‘*’ is not promotable
--     In the kind ‘End’
-- In 7.6.3, using :kind!, I can see that the type synonyms contained
in the family do work the way I intend them to.

{-# Language
    GADTs
  , TypeFamilies
  , DataKinds
   #-}
module TypeFamilies where

data End = Least | Spot Float | Most
  deriving (Eq, Show)

data Interval = IntervalCons { left :: End, right :: End }
(Continue reading)

i hamsa | 20 Jul 09:26 2014
Picon

Failure compiling ghc-mtl with ghc-7.8.{2,3}

I was trying to upgrade to ghc-7.8 the other day, and got this
compilation failure when building ghc-mtl-1.2.1.0 (see the end of the
message).

I'm using the haskell overlay on Gentoo Linux straight out of the box,
no local cabal installations of anything.

Now I was told that other people can compile ghc-mtl with 7.8 just
fine, so there must be something broken in my specific configuration.
What would be an effective way to approach the situation?

In the sources I see that an instance of MonadIO GHC.Ghc does exist. I
don't understand these errors. Are there multiple different MonadIO
classes in different modules?

Thank you and happy hacking.

Now the errors:

Control/Monad/Ghc.hs:42:15:
    No instance for (GHC.MonadIO Ghc)
      arising from the 'deriving' clause of a data type declaration
    Possible fix:
      use a standalone 'deriving instance' declaration,
        so you can specify the instance context yourself
    When deriving the instance for (GHC.ExceptionMonad Ghc)

Control/Monad/Ghc.hs:46:15:
    No instance for (MonadIO GHC.Ghc)
      arising from the 'deriving' clause of a data type declaration
(Continue reading)

Evan Laforge | 17 Jul 03:32 2014
Picon

extra "ambiguous type variable" errors after a "couldn't match" error?

7.8.3 has a new behaviour where a "plain" type error will cause
"ambiguous type variable" errors, e.g.:

module M where

broken :: [Int]
broken = ()

ambiguous :: a -> [String]
ambiguous _ = map show [1..]

When imported in ghci, I get:

M.hs:4:10:
    Couldn't match expected type ‘[Int]’ with actual type ‘()’
    In the expression: ()
    In an equation for ‘broken’: broken = ()

M.hs:7:19:
    No instance for (Show a0) arising from a use of ‘show’
    The type variable ‘a0’ is ambiguous
[ ... and then more for Enum and Num ]

It seems like the 'a' type variable causes this to happen.  But I
don't see why a type error in another place should cause 'ambiguous'
to become ambiguous.
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
(Continue reading)

Brandon Simmons | 15 Jul 00:55 2014
Picon

Why no `instance (Monoid a, Applicative f)=> Monoid (f a)` for IO?

It seems to me that this should be true for all `f a` like:

  instance (Monoid a, Applicative f)=> Monoid (f a) where
      mappend = liftA2 mappend
      mempty = pure mempty

But I can't seem to find the particular `instance (Monoid a)=> Monoid
(IO a)` anywhere. Would that instance be incorrect, or does it live
somewhere else?

FWIW I noticed this when I started thinking about an instance I wanted
for 'contravariant':

  instance (Monoid a, Applicative f)=> Monoid (Op (f a) b) where
      mempty = Op $ const $ pure mempty
      mappend (Op f) (Op g) = Op (\b-> liftA2 mappend (f b) (g b))

at which point I realized (I think) all `f a` are monoidal, and so we
ought to be able to get the instance above with just a deriving
Monoid.

Brandon
Christiaan Baaij | 14 Jul 18:54 2014
Picon

Re: Installing ghc-7.8.3 OS X bindist fails on Xcode 4 CLI-only machine

Thanks, the work-around did the trick.


On 14 July 2014 16:34, Mark Lentczner <mark.lentczner <at> gmail.com> wrote:
Yes - this is a known problem in GHC (#9257)
The problem is that there is one gcc invocation in the "make install" step (!) and that the clang/gcc detection isn't applied at bindist configuire time. Hence, that gcc invocation is based on the compiler of the machine that built the bindist (clang), not the compiler of the machine it is being installed on (gcc).

Note that this doesn't affect the installed GHC system: The compiler detection at bindist configure time is applied to the ghc tree it installs, just not the bindist make itself!

Work around is very easy:

make install CC_CLANG_BACKEND=0

- Mark

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Brandon Allbery | 14 Jul 17:06 2014
Picon

Fwd: Installing ghc-7.8.3 OS X bindist fails on Xcode 4 CLI-only machine

FWIW Mark had this reply but is apparently not subscribed to, or being rejected by, ghc-users and asked me to forward it.

---------- Forwarded message ----------
From: Mark Lentczner <mark.lentczner <at> gmail.com>
Date: Mon, Jul 14, 2014 at 7:34 AM
Subject: Re: Installing ghc-7.8.3 OS X bindist fails on Xcode 4 CLI-only machine
To: Christiaan Baaij <christiaan.baaij <at> gmail.com>
Cc: glasgow-haskell-users <glasgow-haskell-users <at> haskell.org>


Yes - this is a known problem in GHC (#9257)
The problem is that there is one gcc invocation in the "make install" step (!) and that the clang/gcc detection isn't applied at bindist configuire time. Hence, that gcc invocation is based on the compiler of the machine that built the bindist (clang), not the compiler of the machine it is being installed on (gcc).

Note that this doesn't affect the installed GHC system: The compiler detection at bindist configure time is applied to the ghc tree it installs, just not the bindist make itself!

Work around is very easy:

make install CC_CLANG_BACKEND=0

- Mark
--
brandon s allbery kf8nh                               sine nomine associates
allbery.b <at> gmail.com                                  ballbery <at> sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Christiaan Baaij | 14 Jul 10:53 2014
Picon

Installing ghc-7.8.3 OS X bindist fails on Xcode 4 CLI-only machine

Hi,

I'm having problems installing the OS X bindist of GHC 7.8.3 on my machine.

Here are the specs for my machine:
Hardware: MacBook Pro, 13-inch, Mid 2009
Operating System: OS X 10.8.5
gcc: i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)

Note that I only have the Xcode 4 CLI tools installed, not Xcode 4 itself.
The line that fails is:
> /usr/bin/gcc -E  -m64 -undef -traditional -Wno-invalid-pp-token -Wno-unicode -Wno-trigraphs -P
-DINSTALLING -DLIB_DIR='"/opt/ghc/7.8.3/lib/ghc-7.8.3"'
-DINCLUDE_DIR='"/opt/ghc/7.8.3/lib/ghc-7.8.3/include"' -DPAPI_INCLUDE_DIR=""
-DPAPI_LIB_DIR="" -DFFI_INCLUDE_DIR= -DFFI_LIB_DIR= '-DFFI_LIB="Cffi"' -x c -Iincludes
-Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header
rts/package.conf.in -o rts/dist/package.conf.install.raw
> cc1: error: unrecognized command line option "-Wno-invalid-pp-token"
> cc1: error: unrecognized command line option "-Wno-unicode"
> make[2]: *** [rts/dist/package.conf.install] Error 1
> make[1]: *** [install] Error 2
> make: *** [install] Error 2

Earlier in the configuration process I see:
> checking XCode version... xcode-select: Error: No Xcode is selected. Use xcode-select -switch
<path-to-xcode>, or see the xcode-select manpage (man xcode-select) for further information.
> not found (too old?)

Could that be the culprit?

The entire installation log can be found here: https://gist.github.com/christiaanb/ec06e93fa16fdfdb5fa3

-- Christiaan
Gabriel Gonzalez | 14 Jul 04:30 2014
Picon

Avoiding BlockedIndefinitelyOnSTM exceptions

I have what may sound like an unusual request: I would like to 
automatically avoid `BlockedIndefinitelyOnSTM` exceptions with a 
primitive that looks something like this:

     safe :: STM a -> STM (Maybe a)

This hypothetical `safe` primitive would attempt a transaction, and if 
`ghc` detects that this transaction would fail because of an 
`BlockedIndefinitelyOnSTM` exception it will return `Nothing` instead of 
throwing an uncatchable exception.

I originally simulated a limited form of this behavior using 
`pipes-concurrency`.  I instrumented the garbage collector (using weak 
references) to detect when an STM variable was garbage collected and to 
safely cancel any transactions that depended on those variables.  You 
can see the implementation here:

https://github.com/Gabriel439/Haskell-Pipes-Concurrency-Library/blob/23e7e2dab472b7e4cde7bea31227a917ce5d5375/src/Pipes/Concurrent.hs#L170

The original purpose behind this was to easily read and write to a 
channel without having to count references to the channel.  I reasoned 
that the garbage collector *already knew* how many open references there 
were to channel, so I thought "why not use the garbage collector to 
gracefully cancel transactions that would block just before they would 
trigger the exception?"

This worked really well up until ghc-7.8 changed something and the above 
trick no longer works.  To be honest, I'm surprised that it ever worked 
at all, which is why I'm not requesting restoring the original 
behavior.  Instead, I think providing something like the above `safe` 
primitive would be nicer, if possible.

Would it be possible to implement something like `safe`?

Alternatively, is it possible to make the `BlockedIndefinitelyOnSTM` 
exception catchable?

P.S.  I'm also interested in learning more about what may have caused 
the change in behavior in the transition from ghc-7.6 to ghc-7.8.  What 
changes were made to the interaction between STM and weak references 
that may have triggered this?
Michael Jones | 8 Jul 06:10 2014

Cross compiling for Cortex A9

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

Gmane