- ghc-devs - Haskell.org

Mailing lists
by Ian Lynagh 24 Jan '13

24 Jan '13

Hi all, As you've probably noticed, the mailing list changes have now been made. The following new lists have been created: ghc-devs@ For developer discussions ghc-commits@ For automated commit messages from the git repositories ghc-builds@ For automated nightly build reports ghc-tickets@ For automated messages from trac These mailing lists no longer exist (but for now they forward to an appropriate new list): cvs-ghc@ cvs-libraries@ cvs-other@ glasgow-haskell-bugs@ People have been subscribed to the new lists based on which old lists they were on. If you find any web pages etc referring to the old lists, please ask the webmaster to update them (or do so yourself if e.g. it's on a wiki). Thanks Ian

2 1

Implementing primitive Bool operations
by Jan Stolarek 23 Jan '13

23 Jan '13

I want to work on implementing primitive Booleans in GHC and thus resolve trac ticket 6135 ( http://hackage.haskell.org/trac/ghc/ticket/6135 ). I haven't done any development work on GHC yet so this will be my first attempt to contribute something useful to the project. However, I need some help to get started. Right now my main problem is foreseeing consequences of introducing primitive booleans to the language. I gathered my thoughts on this subject on a wiki page ( http://hackage.haskell.org/trac/ghc/wiki/PrimBool ). I see some things that can go wrong with solutions I came up with so far. I will appreciate if someone with more knowledge could comment on them and help me decide on which approach to implementing primitive Bool should I take. Janek

1 0

Strange GNU make behavior/why are not shared libs built on Solaris?
by Karel Gardas 22 Jan '13

22 Jan '13

Hello, before making a ticket for this, I'm curious why are not shared libs build on Solaris 11 on GHC HEAD. Please note 7.6.1 release is not affected by this and shared libs are build on Solaris well (using the exactly same environment). I've tried to debug a little bit makefile machinery and the results are confusing: $ gmake show VALUE=PlatformSupportsSharedLibs gmake -r --no-print-directory -f ghc.mk show PlatformSupportsSharedLibs="YES" so here, everything is fine, Solaris is supported for shared libs (i.e. there is no broken ld presented on Solaris 11 which would disable this feature). Now: $ gmake show VALUE=GhcLibWays gmake -r --no-print-directory -f ghc.mk show GhcLibWays="v" why is that, when the code in mk/config.mk is clear enough and contains: ifeq "$(PlatformSupportsSharedLibs)" "YES" GhcLibWays += dyn endif ? Am I just simply blind and don't see obvious fact or is that really confusing behavior? BTW: Solaris 11 provided GNU make 3.81, that's what I'm using. Thanks a lot for any idea how to debug this further! Karel

2 2

Abott down?
by Simon Peyton-Jones 22 Jan '13

22 Jan '13

Is abbott (darcs.haskell.org) down? http://www.downforeveryoneorjustme.com/darcs.haskell.org says it is, and I can't access it. Urk. Simon

3 5

RE: Syntax error in perf/should_run/all.T
by Simon Peyton-Jones 21 Jan '13

21 Jan '13

That's odd. It validated for me... maybe those tests aren't run. Anyway, there was a missing paren, now fixed. Apologies Simon | -----Original Message----- | From: Edward Z. Yang [mailto:ezyang@MIT.EDU] | Sent: 18 January 2013 21:29 | To: Simon Peyton-Jones | Cc: ghc-devs(a)haskell.org | Subject: Syntax error in perf/should_run/all.T | | Looks like this hunk is not quite correct: | | commit 52234dfedb9ad07585271f33513fb2c9e5012e1a | Author: Simon Peyton Jones <simonpj(a)microsoft.com> | Date: Thu Jan 17 13:52:35 2013 +0000 | | Adjust performance bounds slightly | | diff --git a/tests/perf/should_run/all.T b/tests/perf/should_run/all.T | index 08ff230..cdb8852 100644 | --- a/tests/perf/should_run/all.T | +++ b/tests/perf/should_run/all.T | @@ -227,9 +227,10 @@ test('T5536', | 1250000000)), | # expected value: 1246287228 (i386/Linux) | if_wordsize(64, | - stats_num_field('bytes allocated', 2480000000, | - 2510000000)), | - # expected value: 2492589480 (amd64/Linux) | + stats_range_field('bytes allocated', 892399040, 5), | + # expected value: 2,492,589,480 | (amd64/Linux) | + # 17/1/13: 892,399,040 | (x86_64/Linux) | + # (new demand analyser) | | The file now syntax errors for me. | | Edward

1 0

Handling in Android in Cabal
by Nathan Hüsken 20 Jan '13

20 Jan '13

Hey, I was just looking into how to add support to detect android as the OS in Cabal. I found this comment: --TODO: decide how to handle Android and iOS. -- They are like Linux and OSX but with some differences. -- Should they be separate from linux/osx, or a subtype? -- e.g. should we have os(linux) && os(android) true simultaneously? I want to add android to the list of os known by cabal because I need to switch on it in the cabal file of haskeline to get it compiled on android. But I would think that most of the time the same settings that work for linux also work for android. So my vote would be to make android a "subtype" of linux. Regards, Nathan

1 0

Re: [commit: ghc] master: Tidy up cross-compiling (109a1e5)
by Simon Marlow 20 Jan '13

20 Jan '13

On 17/01/13 14:00, Simon Peyton-Jones wrote: > Would it be worth transferring that comment into the building guide (a cross-compiling page perhaps). The distinction is subtle and the information is useful > > There is http://hackage.haskell.org/trac/ghc/wiki/CrossCompilation > but I'm not sure it has this info Oh yes, I plan to fix the wiki. It needs more than just an update for this change though... the CrossCompilation page is really a design document, not a user guide, we need some proper documentation. Cheers, Simon > Simon > > | -----Original Message----- > | From: ghc-commits-bounces(a)haskell.org [mailto:ghc-commits- > | bounces(a)haskell.org] On Behalf Of Simon Marlow > | Sent: 17 January 2013 12:57 > | To: ghc-commits(a)haskell.org > | Subject: [commit: ghc] master: Tidy up cross-compiling (109a1e5) > | > | Repository : ssh://darcs.haskell.org//srv/darcs/ghc > | > | On branch : master > | > | http://hackage.haskell.org/trac/ghc/changeset/109a1e53287f50103e8a5b5922 > | 75940b6e3dbb53 > | > | >--------------------------------------------------------------- > | > | commit 109a1e53287f50103e8a5b592275940b6e3dbb53 > | Author: Simon Marlow <marlowsd(a)gmail.com> > | Date: Thu Jan 17 11:52:15 2013 +0000 > | > | Tidy up cross-compiling > | > | We have two cases: > | 1. building a cross-compiler > | 2. compiling GHC to run on a foreign platform > | > | These two are done with almost the same setup: (1) is the stage 1 > | compiler, and (2) is the stage 2 compiler, when CrossCompiling=YES. > | > | The only difference between (1) and (2) is that you if you set up > | the > | build for (1), then it stops before stage 2 and you can 'make > | install' > | to install stage 1. > | > | Unfortunately, (2) didn't work, and the build system code needed > | some > | tidying up. > | > | Change to the way the build is set up: > | > | Before > | ------ > | > | To build a cross-compiler: > | ./configure --target=<..> > | > | To compile a foreign GHC: > | ./configure --host=<..> --target=<..> > | > | Now > | --- > | > | To build a cross-compiler: > | ./configure --target=<..> > | And set "Stage1Only=YES" in mk/build.mk > | > | To compile a foreign GHC: > | ./configure --target=<..> > | > | aclocal.m4 | 28 ++++++++---- > | compiler/ghc.mk | 99 ++++++++++++++++++++---------------- > | ------ > | configure.ac | 35 ++++----------- > | ghc.mk | 10 ++-- > | ghc/ghc.mk | 2 +- > | libraries/primitive | 1 - > | libraries/vector | 1 - > | mk/config.mk.in | 27 +++++++----- > | rules/build-package-data.mk | 7 +++- > | settings.in | 1 + > | utils/ghc-pkg/ghc.mk | 4 +- > | 11 files changed, 107 insertions(+), 108 deletions(-) > | > | > | Diff suppressed because of size. To see it, use: > | > | git show 109a1e53287f50103e8a5b592275940b6e3dbb53 > | > | _______________________________________________ > | ghc-commits mailing list > | ghc-commits(a)haskell.org > | http://www.haskell.org/mailman/listinfo/ghc-commits >

2 9

[PATCH] do not use CLK_TCK on Solaris host
by Karel Gardas 19 Jan '13

19 Jan '13

This patch fixes Solaris cross-compilation issue as CLK_TCK is not constant on Solaris and hsc2hs chokes on it when cross-compiling from i386-solaris to x86_64-solaris. --- System/CPUTime.hsc | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/System/CPUTime.hsc b/System/CPUTime.hsc index 8934a7e..270fd13 100644 --- a/System/CPUTime.hsc +++ b/System/CPUTime.hsc @@ -39,7 +39,7 @@ import CPUTime ( getCPUTime, cpuTimePrecision ) #ifdef __GLASGOW_HASKELL__ import Foreign.Safe import Foreign.C -#if !defined(CLK_TCK) +#if !defined(CLK_TCK) || solaris2_HOST_OS import System.IO.Unsafe (unsafePerformIO) #endif @@ -187,7 +187,10 @@ cpuTimePrecision = round ((1000000000000::Integer) % fromIntegral (clockTicks)) #ifdef __GLASGOW_HASKELL__ clockTicks :: Int clockTicks = -#if defined(CLK_TCK) +-- CLK_TCK is no longer a constant on Solaris so avoid to use it +-- this way. In fact it's defined in a way like syscall below in +-- Solaris' <time.h> +#if defined(CLK_TCK) && ! solaris2_HOST_OS (#const CLK_TCK) #else unsafePerformIO (sysconf (#const _SC_CLK_TCK) >>= return . fromIntegral) -- 1.7.3.2

2 2

[PATCH 2/2] do not use timer_create function on Solaris OS
by Karel Gardas 18 Jan '13

18 Jan '13

--- rts/posix/Itimer.c | 18 ++++++++++++++++++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/rts/posix/Itimer.c b/rts/posix/Itimer.c index 80b3b56..b99ff89 100644 --- a/rts/posix/Itimer.c +++ b/rts/posix/Itimer.c @@ -73,6 +73,24 @@ * etc.). */ +#if defined(solaris2_HOST_OS) +/* USE_TIMER_CREATE is usually disabled for Solaris. In fact it is + supported well on this OS, but requires additional privilege. When + user does not have it, then the testing configure program fails + which results in USE_TIMER_CREATE not defined. + On the other hand when we cross-compile, then we optimistically + assume usage of timer_create function. The problem is that if we + cross compile for example from i386-solaris2 to x86_64-solaris2, + then the build fails with error like this: + +ghc-stage2: timer_create: Not owner + + which happens on first ghc-stage2 invocation. So to support + cross-compilation to Solaris we manually undefine USE_TIMER_CREATE + here */ +#undef USE_TIMER_CREATE +#endif /* solaris2_HOST_OS */ + #if defined(USE_TIMER_CREATE) # define ITIMER_SIGNAL SIGVTALRM #elif defined(HAVE_SETITIMER) -- 1.7.3.2

1 0

[PATCH 1/2] fix rts/Linker compilation issues on AMD64/Solaris platform
by Karel Gardas 18 Jan '13

18 Jan '13

--- rts/Linker.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/rts/Linker.c b/rts/Linker.c index fa1de89..b97a30c 100644 --- a/rts/Linker.c +++ b/rts/Linker.c @@ -4088,6 +4088,7 @@ ocResolve_PEi386 ( ObjectCode* oc ) #elif defined(x86_64_HOST_ARCH) # define ELF_TARGET_X64_64 # define ELF_64BIT +# define ELF_TARGET_AMD64 /* Used inside <elf.h> on Solaris 11 */ #elif defined(powerpc64_HOST_ARCH) # define ELF_64BIT #endif -- 1.7.3.2

1 0