Re: ghc-paths

2008-12-12 Thread Ian Lynagh
On Mon, Dec 08, 2008 at 01:12:58PM +, Simon Marlow wrote:
> Jens Petersen wrote:
> >Are there any plans to include ghc-paths in ghc itself?
> 
> Not at present.  It's more difficult to ship it with GHC than it is to 
> build it post-installation, because it is essentially compiled code that 
> depends on an install-time variable.  Various hairbrained schemes were 
> proposed on cvs-ghc a while back, but I'm not aware of any easy solutions 
> to this problem.

Also, if you're installing with cabal-install then it should be
installed for you automatically.


Thanks
Ian

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: ghc 6.10.1 on freebsd 7 amd64 - ghci problems

2008-12-12 Thread Markus Barenhoff
On Wed 10.12 13:55, Simon Marlow wrote:

Hi!

> >>>I checked out and translated the head version of ghc today from darcs.
> >>>It compiled fine. When I now try to start the ghci I get the following:
> >>>
> >>> snip 
> >>>GHCi, version 6.11.20081126: http://www.haskell.org/ghc/  :? for help
> >>>ghc: internal error: loadObj: failed to mmap() memory below 2Gb; asked 
> >>>for 626688 bytes at 0x4000, got 0x801635000.  Try specifying an 
> >>>address with +RTS -xm -RTS
> >>>   (GHC version 6.11.20081126 for x86_64_unknown_freebsd)
> >>>   Please report this as a GHC bug:  
> >>>   http://www.haskell.org/ghc/reportabug
> >>>   Abort (core dumped) 
> >>> snip 
> >>>
> >>>If it helps somehow, you can find the core dump here:
> >>>http://www.alios.org/~alios/ghc.core.bz2
> >>That's odd, because 6.8.3 is using 0x4000 on FreeBSD and is working 
> >>fine (or is it?).
> >
> >yes, it worked, but I haven't installed anymore - so I'am not sure, where 
> >it
> >does maps its stuff into memory.
> 
> The memory map shows that there's nothing mapped in at the place we're 
> asking for memory, but still FreeBSD decides to give us memory somewhere 
> else.  I checked back in 6.8.3 and it looks like we were using MAP_FIXED - 
> now MAP_FIXED is dangerous, because it will overwrite existing mappings 
> (like the binary itself!), which is why we're not doing that now.
> 
> I've committed a patch that uses MAP_FIXED on FreeBSD if other attempts to 
> get memory below 2Gb fail.  I'd be grateful if you could test it out, the 
> patch is this one, pushed to HEAD today:
> 
> Wed Dec 10 11:57:51 GMT 2008  Simon Marlow 
>   * On FreeBSD, try MAP_FIXED if ordinary mmap() fails to give us suitable 
> memory
>   This appears to be necessary on FreeBSD.  It might be necessary on
>   other OSs too, but I'm being cautious because using MAP_FIXED can lead
>   to crashes by overwriting existing mappings, and we have no (easy) way
>   to prevent that.

I've updated my source tree today. 

But now I've problem while compiling the ghc

Here is the the build output:

[...]

/usr/home/alios/src/haskell/ghc/ghc/ghc/stage1-inplace/ghc 
-DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -package-name ghc-6.11.20081211 
-hide-all-packages -no-user-package-conf -i -idist-stage2/build -inativeGen 
-ibasicTypes -icmm -icodeGen -icoreSyn -icprAnalysis -ideSugar -ighci -ihsSyn 
-iiface -imain -iparser -iprelude -iprofiling -irename -isimplCore -isimplStg 
-ispecialise -istgSyn -istranal -itypecheck -itypes -iutils -ivectorise 
-idist-stage2/build/autogen -Idist-stage2/build/autogen -Idist-stage2/build 
-I../libffi/build/include -Istage2plus -I../libraries/base/cbits 
-I../libraries/base/include -I. -Iparser -Iutils -optP-DGHCI -optP-include 
-optPdist-stage2/build/autogen/cabal_macros.h -odir dist-stage2/build -hidir 
dist-stage2/build -stubdir dist-stage2/build -package Cabal-1.5.5 -package 
array-0.2.0.0 -package base-4.0.0.0 -package bytestring-0.9.1.4 -package 
containers-0.2.0.0 -package directory-1.0.0.2 -package filepath-1.1.0.1 
-package haskell98-1.0.1.0 -package hpc-0.5.0.2 -package old-time-1.0.0.1 
-package process-1.0.1.1 -package template-haskell-2.3.0.0 -package 
unix-2.3.1.0 -O -Wall -fno-warn-name-shadowing -fno-warn-orphans -XCPP 
-XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface 
-XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses 
-XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable 
-prof -hisuf p_hi -hcsuf p_hc -osuf p_o -idist-stage2/build  -H32m -O 
-Rghc-timing -O2  -c nativeGen/MachRegs.lhs -o dist-stage2/build/MachRegs.p_o  
-ohi dist-stage2/build/MachRegs.p_hi
ghc: panic! (the 'impossible' happened)
  (GHC version 6.11.20081211 for x86_64-unknown-freebsd):
CoreToStg.myCollectArgs
(__scc {trivColorable ghc-6.11.20081211:MachRegs !}
 ghc-6.11.20081211:MachRegs.isSqueesed{v r2FI} [gid] 0 0)
  eta_s2Ni{v} [lid]

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

<>
gmake[4]: *** [dist-stage2/build/MachRegs.p_o] Error 1
gmake[3]: *** [all] Error 1
gmake[3]: Leaving directory `/usr/home/alios/src/haskell/ghc/ghc/compiler'
gmake[2]: *** [build.stage.2] Error 2
gmake[2]: Leaving directory `/usr/home/alios/src/haskell/ghc/ghc/compiler'
gmake[1]: *** [stage2] Error 2
gmake[1]: Leaving directory `/usr/home/alios/src/haskell/ghc/ghc'
gmake: *** [bootstrap2] Error 2


Regards
Markus


-- 
Markus Barenhoff - Langemarckstr. 18 - D-48147 Münster - Germany - Europe - 
Earth
Tel. +49-251-3956651 - Mob. +49-173-7215776 - e-mail: al...@alios.org
jabber: al...@jabber.ccc.de - icq: 27998346



pgpblKr602QIa.pgp
Description: PGP signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: ghci and ghc -threaded [slowdown]

2008-12-12 Thread Malcolm Wallace
Simon Marlow  wrote:

> Malcolm Wallace wrote:
> > 
> > For the only application I tried, using the threaded RTS imposes a
> > 100% performance penalty - i.e. computation time doubles, compared
> > to the non-threaded RTS.  This was with ghc-6.8.2, and maybe the
> > overhead has improved since then?
> 
> This is a guess, but I wonder if this program is concurrent, and does
> a  lot of communication between the main thread and other threads? 

Exactly so - it hits the worst case behaviour.  This was a naive attempt
to parallelise an algorithm by shifting some work onto a spare
processor.  Unfortunately, there is a lot of communication to the main
thread, because the work that was shifted elsewhere computes a large
data structure in chunks, and passes those chunks back.  The main thread
then runs OpenGL calls using this data -- and I believe OpenGL calls must
run in a bound thread.

This all suggests that one consequence of ghc's RTS implementation
choices is that it will never be cheap to compute visualization data in
parallel with rendering it in OpenGL.  That would be a shame.  This was
exactly the parallelism I was hoping for.

Regards,
Malcolm
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: Can't compile GHC 6.8.2

2008-12-12 Thread Barney Stratford
> The right place to add this would be in rts/package.conf.in, in extra-ld-
> opts, with suitable platform-specific #ifdefs.  If you can whip up a
> patch and test it, I'll commit.
Here's the patch, which now compiles correctly.

diff -u a/rts/package.conf.in b/rts/package.conf.in
--- a/rts/package.conf.in   Mon Dec 10 18:11:32 2007
+++ b/rts/package.conf.in   Thu Dec 11 09:36:54 2008
@@ -150,6 +150,10 @@
 , "-u", "base_GHCziConc_ensureIOManagerIsRunning_closure"
 #endif
 
+#ifdef darwin_HOST_OS
+ , "-read_only_relocs", "warning"
+#endif
+
 framework-dirs:
 
 #ifdef HAVE_FRAMEWORK_GMP

Cheers,
Barney.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users