headers
Dubiousjim | 21 May 2013 08:02
Favicon

Re: porting to uClibc-based 686 Linux

Just to follow-up on my earlier emails about trying to port GHC to a
uClibc-based Linux, I finally did get this working, on both x86 and
x86_64.

There were a bunch of small stumbling blocks and one big one that I
finally traced to the fact that the native gcc on my target system had
the Gentoo hardening patches, and one needed to supply a "-nopie" option
to selectively disable these. (This was counter-intuitive because the
error messages made it seem that what was wanted was to *enable* PIE
compiling, not to disable it.) I finally identified this issue when
reading http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml.

Anyway, I've written up what it took to port GHC to our system on our
distro's wiki:

http://wiki.alpinelinux.org/wiki/Porting_GHC_to_Alpine

Perhaps that might help others attempting similar feats, or might help
the ghc devs working on the build system to make this less painful in
the future.
--

-- 
dubiousjim <at> gmail.com
Permalink | Reply | 0 comments |
headers
Henning Thielemann | 20 May 2013 09:10
Picon

nightly builds: empty directory


The page

    http://www.haskell.org/ghc/download

refers to directories for the nightly builds, that are actually empty:

    http://www.haskell.org/ghc/dist/current/dist/
    http://www.haskell.org/ghc/dist/stable/dist/

:-(
Permalink | Reply | 2 comments |
headers
Akio Takano | 13 May 2013 04:47
Picon

A type not inferred with RankNTypes

Hi,

The attached program does not typecheck if I don't include a type signature for 'bar' (the line C). I can't figure out if this is a limitation in the type system or a bug in GHC. One thing that confuses me is that replacing the line (B) with (A) makes the program typecheck.

Could anyone help me figuring out what is going on?

I'm using GHC 7.6.2. The error was:

 % ghc forall.hs
[1 of 1] Compiling Foo              ( forall.hs, forall.o )

forall.hs:18:11:
    Could not deduce (Fractional a) arising from the literal `0.1'
    from the context (Num (Scalar t), Scalar t ~ a)
      bound by a type expected by the context:
                 (Num (Scalar t), Scalar t ~ a) => AD t
      at forall.hs:18:7-13
    Possible fix:
      add (Fractional a) to the context of
        a type expected by the context:
          (Num (Scalar t), Scalar t ~ a) => AD t
        or the inferred type of bar :: a
    In the first argument of `foo', namely `0.1'
    In the expression: foo 0.1
    In an equation for `bar': bar = foo 0.1

Regards,
Takano Akio
Attachment (forall.hs): application/octet-stream, 546 bytes
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Permalink | Reply | 2 comments |
headers
Mateusz Kowalczyk | 12 May 2013 14:10
Picon

Missing snapshots


Greetings,

On the GHC download page [1], there are no available snapshots. Both
HEAD and STABLE branch dist directories are empty.

Any idea what the deal is?

[1] - http://www.haskell.org/ghc/download
--

-- 
Mateusz K.
Permalink | Reply | 3 comments |
headers
Herbert Valerio Riedel | 6 May 2013 13:29
Picon
Gravatar

Why do remaining HECs busy-wait during unsafe-FFI calls?

Hello,

Recently, I stumbled over E.Z.Yang's "Safety first: FFI and
threading"[1] post and then while experimenting with unsafe-imported FFI
functions I've noticed a somewhat surprising behaviour:

Consider the following contrived program:

--8<---------------cut here---------------start------------->8---
import Foreign.C
import Control.Concurrent
import Control.Monad
import Data.Time.Clock.POSIX (getPOSIXTime)

foreign import ccall unsafe "unistd.h sleep" c_sleep_unsafe :: CUInt -> IO CUInt

main :: IO ()
main = do
    putStrLnTime "main started"
    _ <- forkIO (sleepLoop 10 >> putStrLnTime "sleepLoop finished")
    yield
    putStrLnTime "after forkIO"
    threadDelay (11*1000*1000) -- 11 seconds
    putStrLnTime "end of main"
  where
    putStrLnTime s = do
	t <- getPOSIXTime
        putStrLn $ init (show t) ++ "\t" ++ s

    sleepLoop n = do
        n' <- c_sleep_unsafe n
        unless (n' == 0) $ do
            putStrLnTime "c_sleep_unsafe got interrupted"
            sleepLoop n'

--8<---------------cut here---------------end--------------->8---

When compiled with GHC-7.6.3/linux/amd64 with "-O2 -threaded" and
executed with "+RTS -N4", the following output is emitted:

 1367838802.137419	main started
 1367838812.137727	after forkIO
 1367838812.137783	sleepLoop finished
 1367838823.148733	end of main

which shows that the forkIO of the unsafe ccall effectively blocks the
main thread;

Moreover, when looking at the process table, I saw that 3 threads were
occupying 100% CPU time each for 10 seconds until the 'after forkIO' was
emitted.

So what is happening here exactly, why do the 3 remaining HECs busy-wait
during that FFI call instead of continuing the execution of the main
thread?

Do *all* foreign unsafe ccalls (even short ones) cause N-1 HECs to spend
time in some kind of busy looping?

 [1]: http://blog.ezyang.com/2010/07/safety-first-ffi-and-threading/

Cheers,
  hvr
Permalink | Reply | 2 comments |
headers
Conal Elliott | 1 May 2013 23:13
Gravatar

Simplifying Core pretty-printing via GHC API?

I'm using the GHC API to compile Haskell source code to Core. I'd like to pretty-print the result with the sort of simplifications I get with -dsuppress-type-applications, -dsuppress-uniques, etc (used in combination with -ddump-simpl on ghc's command line). How can I set these options via the GHC API? Has the answer changed since 7.4.1 (which I'm currently using)?

Thanks.  - Conal
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Permalink | Reply | 2 comments |
headers
Ian Lynagh | 21 Apr 2013 15:23
Favicon

ANNOUNCE: GHC version 7.6.3


   =============================================================
    The (Interactive) Glasgow Haskell Compiler -- version 7.6.3
   =============================================================

The GHC Team is pleased to announce a new patchlevel release of GHC, 7.6.3.

This is a bugfix release relative to 7.6.2, so we recommend upgrading.

Full release notes are here:

  http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/release-7-6-3.html

How to get it
~~~~~~~~~~~~~

The easy way is to go to the web page, which should be self-explanatory:

        http://www.haskell.org/ghc/

We supply binary builds in the native package format for many
platforms, and the source distribution is available from the same
place.

Packages will appear as they are built - if the package for your
system isn't available yet, please try again later.

Background
~~~~~~~~~~

Haskell is a standard lazy functional programming language.

GHC is a state-of-the-art programming suite for Haskell.  Included is
an optimising compiler generating good code for a variety of
platforms, together with an interactive system for convenient, quick
development.  The distribution includes space and time profiling
facilities, a large collection of libraries, and support for various
language extensions, including concurrency, exceptions, and foreign
language interfaces (C, whatever).  GHC is distributed under a
BSD-style open source license.

A wide variety of Haskell related resources (tutorials, libraries,
specifications, documentation, compilers, interpreters, references,
contact information, links to research groups) are available from the
Haskell home page (see below).

On-line GHC-related resources
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Relevant URLs on the World-Wide Web:

GHC home page              http://www.haskell.org/ghc/
GHC developers' home page  http://hackage.haskell.org/trac/ghc/
Haskell home page          http://www.haskell.org/

Supported Platforms
~~~~~~~~~~~~~~~~~~~

The list of platforms we support, and the people responsible for them,
is here:

   http://hackage.haskell.org/trac/ghc/wiki/Contributors

Ports to other platforms are possible with varying degrees of
difficulty.  The Building Guide describes how to go about porting to a
new platform:

    http://hackage.haskell.org/trac/ghc/wiki/Building

Developers
~~~~~~~~~~

We welcome new contributors.  Instructions on accessing our source
code repository, and getting started with hacking on GHC, are
available from the GHC's developer's site run by Trac:

  http://hackage.haskell.org/trac/ghc/

Mailing lists
~~~~~~~~~~~~~

We run mailing lists for GHC users and bug reports; to subscribe, use
the web interfaces at

    http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
    http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

There are several other haskell and ghc-related mailing lists on
www.haskell.org; for the full list, see

    http://www.haskell.org/mailman/listinfo/

Some GHC developers hang out on #haskell on IRC, too:

    http://www.haskell.org/haskellwiki/IRC_channel

Please report bugs using our bug tracking system.  Instructions on
reporting bugs can be found here:

    http://www.haskell.org/ghc/reportabug
Permalink | Reply | 2 comments |
headers
Mikhail Glushenkov | 20 Apr 2013 10:55
Picon
Gravatar

Why is GHC so much worse than JHC when computing the Ackermann function?

Hi all,

This came up on StackOverflow [1]. When compiled with GHC (7.4.2 &
7.6.2), this simple program:

main = print $ ack 4 1
  where ack :: Int -> Int -> Int
        ack 0 n = n+1
        ack m 0 = ack (m-1) 1
        ack m n = ack (m-1) (ack m (n-1))

consumes all available memory on my machine and slows down to a crawl.
However, when compiled with JHC it runs in constant space and is about
as fast as the straightforward Ocaml version (see the SO question for
benchmark numbers).

I was able to fix the space leak by using CPS-conversion, but the
CPS-converted version is still about 10 times slower than the naive
version compiled with JHC.

I looked both at the Core and Cmm, but couldn't find anything
obviously wrong with the generated code - 'ack' is compiled to a
simple loop of type 'Int# -> Int# -> Int#'. What's more frustrating is
that running the program with +RTS -hc makes the space leak
mysteriously vanish.

Can someone please explain where the space leak comes from and if it's
possible to further improve the runtime of this program with GHC?
Apparently it's somehow connected to the stack management strategy,
since running the program with a larger stack chunk size (+RTS -kc1M)
makes the space leak go away. Interestingly, choosing smaller stack
chunk sizes (256K, 512K) causes it to die with an OOM exception:

$ time ./Test +RTS -kc256K
Test: out of memory (requested 2097152 bytes)

[1] http://stackoverflow.com/questions/16115815/ackermann-very-inefficient-with-haskell-ghc/16116074#16116074

--

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments
Permalink | Reply | 8 comments |
headers
Felipe Almeida Lessa | 15 Apr 2013 21:57
Picon
Gravatar

mask, catch, myThreadId, throwTo

Hey!

I have some code that is not behaving the way I thought it should.

The gist of it is

  sleeper =
    mask_ $
    forkIOWithUnmask $ \restore ->
      forever $
        restore sleep `catch` throwBack

  throwBack (Ping tid) = myThreadId >>= throwTo tid . Pong
  throwBack (Pong tid) = myThreadId >>= throwTo tid . Ping

Since (a) throwBack is executed on a masked state, (b) myThreadId is
uninterruptible, and (c) throwTo is uninterruptible, my understanding
is that the sleeper thread should catch all PingPong exceptions and
never let any one of them through.

However, that's not what I am seeing.  Running with -threaded and at
least -N2 I can reliably get sleeper to be killed.  Please see the
complete code at:

  https://gist.github.com/meteficha/5390079

The expected result is 100 Pongs and 0 Pings.  Running with -N1 that's
what I get.  Running with -N2 I get a few Pongs and then 1 Ping.
Running with -N3 or more usually gives me just 1 Ping and not a single
Pong.

I'm testing with GHC 7.4.1.  I've tried to download 7.7 but---either
because of haskell.org or my ISP---I'm not being able to download it.

(Note that this problem is not academic as I've been bitten by it on
my production code.)

Thanks! =D

--
Felipe.
Permalink | Reply | 5 comments |
headers
Roman Cheplyaka | 12 Apr 2013 12:26
Gravatar

Using old code generator

Hi,

I'm looking for a workaround for #7574 [1] (I run into it when trying to
build the 'statistics' package with profiling enabled with GHC HEAD.)

The symptom is

  ghc-stage2: panic! (the 'impossible' happened)
    (GHC version 7.7.20130407 for i386-unknown-linux):
    allocateRegsAndSpill: Cannot read from uninitialized register
      %vI_cCdO

[1]: http://hackage.haskell.org/trac/ghc/ticket/7574

Do I understand correctly that this bug is specific to the new codegen?
If so, is it possible to ask the compiler to use the old codegen?
Is it okay to mix together packages compiled with both codegens?

Thanks,
Roman
Permalink | Reply | 2 comments |
headers
Dubiousjim | 1 Apr 2013 19:11
Favicon

porting to uClibc-based 686 Linux

My preferred system is a 686 Linux distro based on uClibc. No ghc
binaries available yet there. I'd like to remedy that.

I have ghc 7.4.2 running on an 686 Linux distro based on glibc (and also
on two different versions of Mac OS X, but they seem more distant and so
less likely to be helpful). In fact, ghc 7.6.2 binaries are also
available for that system, but I'd like to keep in synch with the last
released Haskell platform (which is what I've got on the Macs). That's
supposed to be updated in May, so if it's only possible to port ghg >=
7.6.x to my target system, that won't be so terrible. I'm hoping though
to be able to port a ghc < 7.8.x, because I don't expect to see that
version in any soon-to-be-released Haskell platform. (I mention this
because
http://hackage.haskell.org/trac/ghc/wiki/CrossCompilation says:
"Support for cross-compilation works reasonably well in 7.8.1. Previous
versions had various issues which are usually work-aroundable.")

Ok, so I'm getting stuck trying to build a version of ghc that will run
on the target, uClibc-based system. I have a working cross-compiler. (In
fact, I have two, one built using crosstools-NG, the other built using
buildroot.) My target identifier is "i686-buildroot-linux-uclibc".

I've tried the method for cross-compiling ghc posted here:
http://hackage.haskell.org/trac/ghc/wiki/Building/CrossCompiling
I had to tweak the configure script to not complain about the
"buildroot" vendor id. Here is the content of my mk/build.mk file:

    BuildFlavour = unreg
    ...
    ifeq "$(BuildFlavour)" "unreg"

    GhcUnregisterised    = YES
    GhcWithNativeCodeGen = NO

    # SRC_HC_OPTS          = -O -H64m
    # GhcStage1HcOpts      = -O
    # GhcStage2HcOpts      = -O2
    # GhcLibHcOpts         = -O2
    SRC_HC_OPTS          = -O -H64m -fasm
    GhcStage1HcOpts      = -O -fasm
    GhcStage2HcOpts      = -O2 -fasm
    GhcHcOpts            = -Rghc-timing
    GhcLibHcOpts         = -O2 -fasm
    SplitObjs            = NO
    HADDOCK_DOCS         = NO
    BUILD_DOCBOOK_HTML   = NO
    BUILD_DOCBOOK_PS     = NO
    BUILD_DOCBOOK_PDF    = NO

    endif

Using the following commands:

    $ export PATH=${PATH}:/path/to/my/cross/compiler
    $ make clean
    $ ./configure --target=i686-buildroot-linux-uclibc
    $ make

will successfully build ghc. However, the inplace/lib/ghc-stage2 it
generates won't run on the target system. (Neither will the
utils/ghc-pkg/dist/build/ghc-pkg, this will be relevant later.) Checking
these with
ldd says "not a dynamic executable." Checking them with objdump -p gives
NEEDED lines like this:

    ...
    NEEDED               libc.so.6
    ...

which indicates that they're linking against the glibc on my host,
rather
than the uClibc of my cross-compiler toolchain.

Perhaps I'm doing something wrong, or perhaps the build system
distributed with ghc 7.4.2 just doesn't yet properly support
cross-compiling. It's strange though that the build completes without
any errors. grepping the Makefiles doesn't show any evidence that it's
using my cross-compiler. Do I need to make links using the target
identifier "i386-unknown-linux-..." to my actual tools
"i686-buildroot-linux-uclibc-..."?

The web instructions say:

    If you need to specify the tools explicitly, then you can say

        $ ./configure --target=<target> --with-gcc=<gcc> \
        --with-ld=<ld> --with-nm=<nm> --with-objdump=<objdump>

However, if I specify my cross-compiler tools in this way, the build
breaks already at the configure step, because the binaries generated
won't run on the host.

Alright, that isn't working. I also tried instead to use the older
instructions at
http://hackage.haskell.org/trac/ghc/wiki/Building/Porting

This requires some tweaking, then at a certain point in this process I
also get stuck.

What I had to tweak:

* The instructions say to copy an executable pwd to
  utils/ghc-pwd/ghc-pwd on the target, then run:

      $ perl boot
      $ ./configure --enable-hc-boot --build=<plat> \
      --host=<plat> --target=<plat>

  However, the configure process still tries to build ghc-pwd
  and of course fails, since there's no ghc on the target to build
  it with. I comment out the line in the configure script which
  tries to build ghc-pwd and make sure that GHC_PWD points to
  my replacement pwd (which can't be at the location
  the configure script tries to make GHC_PWD point to, since that
  keeps getting clobbered).

* Ok, so we get past the ghc-pwd issue and the configure continues.
  But then I get stuck with ghc-pkg:

      $ ./configure --enable-hc-boot --build=i386-unknown-linux \
      --host=i386-unknown-linux --target=i386-unknown-linux
      ...
      checking for ghc... no
      checking build system type... i386-unknown-linux-gnu
      checking host system type... i386-unknown-linux-gnu
      checking target system type... i386-unknown-linux-gnu
      GHC build  : i386-unknown-linux
      GHC host   : i386-unknown-linux
      GHC target : i386-unknown-linux
      configure: Building in-tree ghc-pwd
      checking for path to top of build tree... /home/jim/ghc-7.4.2
      checking for gcc... /usr/bin/gcc
      ...
      checking for i386-unknown-linux-gcc... /usr/bin/gcc
      checking whether the C compiler works... yes
      ...
      checking whether we are cross compiling... no
      ...
      checking version of gcc... 4.7.2
      ...
      checking for ghc-pkg matching ... configure: error: Cannot find
      matching ghc-pkg

  Well of course there's no ghc-pkg, because I'm trying to port ghc to
  this system!

  I checked the ghc-pkg I (tried to) build with the cross-compiler
  toolchain, earlier, but this (contrary to my intention) links against
  the libc on its host, and so won't run on the target either.

* Ok, so let's hack the configure script to skip building ghc-pkg too.
  Then configure completes successfully on the target. The next step
  is to:

      $ cd libraries/integer-gmp
      $ ./configure
      $ cd ..
      $ make bootstrapping-files

  However, this fails at the following point:

      ""  -fno-stack-protector -DNO_REGS -DUSE_MINIINTERPRETER
      -D__GLASGOW_HASKELL__=704 -Iincludes -DNO_REGS
      -DUSE_MINIINTERPRETER
      -Iincludes -Iincludes/dist-derivedconstants/header
      -Iincludes/dist-ghcconstants/header -Irts -DNOSMP -c
      includes/mkDerivedConstants.c -o
      includes/dist-derivedconstants/build/mkDerivedConstants.o
      /bin/sh: : Permission denied
      make[1]: ***
      [includes/dist-derivedconstants/build/mkDerivedConstants.o]
      Error 127
      make: *** [bootstrapping-files] Error 2

  I don't know if it's a variable that's supposed to point to $CC that's
  coming up "", or one that's supposed to point to ghc. I'm guessing the
  latter. I can't proceed with the porting instructions at this point
  because includes/dist-derivedconstants is empty (just an empty build
  dir), and includes/dist-ghcconstants doesn't exist yet.

Any advice on how to proceed further using either of the strategies I
described (cross-compiling, or bootstrapping using using unregisterised
intermediate C files), would be welcomed.

-- 
Dubiousjim
dubiousjim <at> gmail.com
--

-- 
dubiousjim <at> gmail.com
Permalink | Reply | 4 comments |

Gmane