Bas van Dijk | 10 Feb 00:49
Picon
Gravatar

GHCi-7.4.1: Importing a non existing module succeeds

Should I file a bug for this:

GHCi 7.2.2:

> import I.Do.Not.Exist

<no location info>:
    Could not find module `I.Do.Not.Exist'
    Use -v to see a list of the files searched for.

GHCi 7.4.1:

> import I.Do.Not.Exist
>

(and for the record: I.Do.Not.Exist does not exist)

Bas
Roel van Dijk | 9 Feb 20:56
Picon
Gravatar

Kind error in GHC-7.4.1, works in GHC-7.2.2

Hello,

I have some code that compiled fine in GHC-7.2.2 but fails in
GHC-7.4.1 with a kind error.

{-# LANGUAGE MagicHash, NoImplicitPrelude, PackageImports #-}
import "base" Data.Function ( ($) )
import "base" GHC.Exts ( Int(I#) )
import "base" Prelude ( Integral, fromIntegral, toInteger )
import "integer-gmp" GHC.Integer.Logarithms ( integerLogBase# )

intLog :: (Integral a) => a -> a
intLog x = fromIntegral $ I# $ integerLogBase# 10 (toInteger x)

This results in the following error:

    Couldn't match kind `#' against `*'
    In the second argument of `($)', namely
      `I# $ integerLogBase# 10 (toInteger x)'
    In the expression:
      fromIntegral $ I# $ integerLogBase# 10 (toInteger x)
    In an equation for `intLog':
        intLog x = fromIntegral $ I# $ integerLogBase# 10 (toInteger x)

Simply eliminating some $'s using parenthesis solves the problem:

intLog x = fromIntegral $ I# (integerLogBase# 10 (toInteger x))

Why do I get the above kind error? Could it be a bug in GHC?
(Continue reading)

Christian Maeder | 7 Feb 12:32
Picon
Favicon

auto-orphans?

Hi,

in 
http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/options-sanity.html

I've found no description for -fwarn-auto-orphans

Cheers Christian
Picon

`unregisterised' performance

Dear GHC team,

I have compared for performance on DoCon of  
                                   ghc-7.4.1  registerised and unregisterised,
both made from source by  ghc-7.4.1
(Debian Linux, GenuineIntel, Intel(R) Core(TM)2 CPU),
DoCon and its test compiled under  -O
(-O2 is not better than -O). 

`registerised' is  5.4 times faster in building DoCon, 
               is  3   times faster in running the DoCon test,
               produces 1.7 times smaller .a library file for DoCon.
All right.
Please, keep on supporting the portable (via-C) branch.

Regards, 

------
Sergei
mechvel <at> botik.ru
Picon
Picon
Favicon

Re: unregisterised and -prof

It would seem that you are building random with profiling enabled:

4. Build  random-1.0.1.1  by new by  ghc/7.4.1/instUnregis
   by
  ghc --make Setup
  ./Setup configure --prefix=/home/mechvel/ghc/7.4.1/instUnregis/lib/ghc-7.4.1 -p
  ./Setup build -v

while your non-reg'ged build of ghc has no profiling libraries.
At least that is what this error says:

* Serge D. Mechveliani <mechvel <at> botik.ru> [06.02.2012 18:20]:
> 
> System/Random.hs:97:8:
>     Could not find module `Numeric'
>     Perhaps you haven't installed the profiling libraries for package `base'?
>     Use -v to see a list of the files searched for.
> scico:~/ghc/random/random-1.0.1.1> 
> ------------------------------------------------------------

The easiest is to remove the "-p" flag, if you do not need profiling enabled.

Gruss,
Christian

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
(Continue reading)

Picon

unregisterised and -prof

Dear GHC team,

For some reason  ghc-7.4.1-unregisterised  cannot build  random-1.0.1.1
-- unlike  ghc-7.4.1-default.

This is for  ghc-7.4.1  built from source by  ghc-7.4.1  on
Debian Linux, i386-uknown.

1. I build  ghc-7.4.1  from source under the default flags, 
   by   ghc-7.4.1,  under
   configure --prefix=/home/mechvel/ghc/7.4.1/inst

2. Build  ghc-7.4.1  from source by new by  ghc/7.4.1/inst  as  unregisterised  
   by setting  
   configure --prefix=/home/mechvel/ghc/7.4.1/instUnregis ,
                                              -----------
   setting
   BuildFlavour = unreg     in  mk/build.mk   by un-commenting this line.

3. Build  random-1.0.1.1  by  ghc  of  7.4.1/inst
   by
  ghc --make Setup
  ./Setup configure --prefix=/home/mechvel/ghc/7.4.1/inst/lib/ghc-7.4.1 -p
  ./Setup build -v
  ./Setup haddock
  ./Setup install -v

It is built all right.

4. Build  random-1.0.1.1  by new by  ghc/7.4.1/instUnregis
(Continue reading)

Picon

unregisterized

People,

Please, where the build guide (.pdf, .html) can be download from?
Does the source GHC distibution include the build guide?
Does the GHC  user_guide  include the build guide?
If not, then -- why?

How to build  unregisterized ghc-7.4.1 from source?

(For many years I read "registerized" in the GHC related messages as 
"registered" and wondered of why do they care for a user to register a 
build!)

Thanks,

------
Sergei
mechvel <at> botik.ru
Picon

via-C

Dear GHC team,

I cannot understand why do you remove the C stage in GHC.
To my mind: let the result be 3 times slower, but preserve the C code.
Because it works everyhere, and there is no real need to rewrite
the same program separately for all the existing processors
(which number may become, for example, 11000). 
I am naive, and am not a specialist. 
But only an invariant program ever has sense.

Has the modern GHC a sensible compilation result level to be observed
(documented?) (graph rewriting code, or like this) ?

Regards,

------
Sergei
mechvel <at> botik.ru
Picon

ghc -C in 7.4.1

Dear GHC team,

I needed to look into the C code made by     ghc-7.4.1 
(made from source by 7.0.1 on Debian Linux)
for
  module TT (dropCWhile) where

  dropCWhile :: (Char -> Bool) -> [Char] -> [Char]
  dropCWhile p xs =  case xs of []    -> []
                                x: ys -> if p x then  dropCWhile p ys 
                                         else         xs
And applied
             ghc -C -O TT.hs
It reports
-------------------------------------------
addFlag by -C on the commandline:
    Warning: The -fvia-C flag does nothing; it will be removed in a 
future GHC release
ghc: panic! (the 'impossible' happened)
  (GHC version 7.4.1 for i386-unknown-linux):
  pipeLoop: at phase As but I wanted to stop at phase HCc

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
-------------------------------------------

1. A bug report.
2. How to see this C code? What GHC version shows it?
   If you have such a version installed, can you, please, send me the 
   C code?

(Continue reading)

Conal Elliott | 5 Feb 00:17
Gravatar

Haddock problems with GHC 7.4.1

Since installing GHC 7.4.1 (from sources), I'm getting lots of complaints from 'ghc-pkg check', of the following form:

Warning: haddock-interfaces: /usr/local/share/doc/transformers-0.2.2.0/html/transformers.haddock doesn't exist or isn't a file
Warning: haddock-html: /usr/local/share/doc/transformers-0.2.2.0/html doesn't exist or isn't a directory

Happens both on (Red Hat) Linux 5 and Mac OS 10.6.8.

Any advice?

-- Conal
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
John Meacham | 31 Jan 21:57
Favicon

Impredicative types error

Hi, I am running into an issue where some code that compiled and
worked under 6.12 is failing under 7.0, the offending code is

class DeNameable a where
    deName :: Module -> a -> a

getDeName :: Tc (DeNameable n => n -> n)
getDeName = do
    mn <- asks (tcInfoModName . tcInfo)
    return (\n -> deName mn n)

Tc is a plain typechecking monad and this returns a generic denaming
function that can be used to turn haskell names back into human
readable form before printing errors in jhc.

I have the ImpredicativeTypes LANGUAGE feature turned on.

the error I get under 7.0 is

src/FrontEnd/Tc/Monad.hs:131:29:
    Couldn't match expected type `n -> n'
                with actual type `DeNameable n'
    In the second argument of `deName', namely `n'
    In the expression: deName mn n
    In the first argument of `return', namely `(\ n -> deName mn n)'

    John

Gmane