Re: Still problems building ghc 6.5 with ghc 6.4
Simon Marlow wrote: Michael Marte wrote: Yes, I synced my working copy of ghc 6.5 yesterday with darcs pull. Are there any requirements as to which exact version of ghc 6.4 I am supposed to use? I am using the plain 6.4 release but I am able to build the head of the 6.4 branch. BTW. Am I supposed to run configure after syncing the working copy and/or clean the source tree before issueing the make command? The *safest* thing to do after pulling is to completely make clean, autoreconf, and build from scratch. You may be able to avoid being that drastic if you know what you're doing. There are quite a few dependencies in the GHC tree that aren't tracked explicitly, for practical reasons; for example, the build system doesn't know that when the .hi format changes you need to rebuild all your libraries. I suspect something is out of date in your case, but I'm not sure what.If you don't want to rebuild everything, you could try just rebuilding ghc/lib/compat, and then remove ghc/stage1/parser/Lexer.o, build stage 1, and then carry on with stage 2. Cheers, Simon I did as you said (make clean; autoreconf; configure; make) but it didn't help; I get the same error as before. Michael ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Still problems building ghc 6.5 with ghc 6.4
Michael Marte wrote: I did as you said (make clean; autoreconf; configure; make) but it didn't help; I get the same error as before. Ok, could you try this: $ size ghc/lib/compat/cbits/unicode.o $ size ghc/lib/compat/Compat/Unicode.o there should be some code in those modules if the build system is working properly. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[2]: Message GHC/PrimopWrappers.hs:133:29: Not in scope: `GHC.Prim.quotInteger2Exp#' building GHC with additional primitive operation
Hello Thorkil, Wednesday, March 29, 2006, 2:15:05 AM, you wrote: Thorkil, i can't understand why you can't just use FFI to import functions you required? why you need to patch the PrimOps list? As I wrote earlier, using FFI is also a candidate for getting access to additional GMP functions. However, presently, I am not aware of a method of doing this that does not involve some potentially significant additional overhead. After all, Haskell Integers are not directly supported in C, so some sort of marshalling and/or intricate access to internal GHC Haskell structures would seem to be required. primitives work with just the same internal structures. i thinl that only real advantage of adding primop instead of adding FFI import is that PrimOps.cmm contains already implemented wrappers for calling GMP functions while for FFI you should implement them from scratch -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Still problems building ghc 6.5 with ghc 6.4
Simon Marlow wrote: Michael Marte wrote: I did as you said (make clean; autoreconf; configure; make) but it didn't help; I get the same error as before. Ok, could you try this: $ size ghc/lib/compat/cbits/unicode.o $ size ghc/lib/compat/Compat/Unicode.o there should be some code in those modules if the build system is working properly. Cheers, Simon Yes, there is code, i.e. the text segments are not empty. Michael ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Still problems building ghc 6.5 with ghc 6.4
Michael Marte wrote: Simon Marlow wrote: Michael Marte wrote: I did as you said (make clean; autoreconf; configure; make) but it didn't help; I get the same error as before. Ok, could you try this: $ size ghc/lib/compat/cbits/unicode.o $ size ghc/lib/compat/Compat/Unicode.o there should be some code in those modules if the build system is working properly. Cheers, Simon Yes, there is code, i.e. the text segments are not empty. I stared at the code some more, and I think I've found the problem and pushed a patch for it. You'll need to 'darcs pull', make in ghc/lib, rm ghc/compiler/stage1/parser/Lexer.o, make stage 1, and then make stage 2. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Still problems building ghc 6.5 with ghc 6.4
Simon Marlow wrote: Michael Marte wrote: Simon Marlow wrote: Michael Marte wrote: I did as you said (make clean; autoreconf; configure; make) but it didn't help; I get the same error as before. Ok, could you try this: $ size ghc/lib/compat/cbits/unicode.o $ size ghc/lib/compat/Compat/Unicode.o there should be some code in those modules if the build system is working properly. Cheers, Simon Yes, there is code, i.e. the text segments are not empty. I stared at the code some more, and I think I've found the problem and pushed a patch for it. You'll need to 'darcs pull', make in ghc/lib, rm ghc/compiler/stage1/parser/Lexer.o, make stage 1, and then make stage 2. Cheers, Simon Now I get the following error: GHC/PrimopWrappers.hs:565:20: Not in scope: `GHC.Prim.forkOn#' I think this problem may be releated to the other changes I pulled. Michael ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Still problems building ghc 6.5 with ghc 6.4
Michael Marte wrote:
Now I get the following error:
GHC/PrimopWrappers.hs:565:20: Not in scope: `GHC.Prim.forkOn#'
I think this problem may be releated to the other changes I pulled.
You probably need to rebuild some stuff. If your stage 1 compiler is up
to date, then remove libraries/base/GHC/Base.{o,hi} and build in
libraries/base. That *should* be enough, but if not just 'make clean'
in libraries/base.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.2 release candidates
On Tue, 2006-03-28 at 12:34 +0100, Simon Marlow wrote: Hi Folks, We're finally in release-candidate mode for 6.4.2. Please grab a snapshot and try it out: http://www.haskell.org/ghc/dist/stable/dist/ (scroll to the bottom for the latest). The available builds are: x86_64-unknown-linux (Fedora Core 5), i386-unknown-linux (glibc 2.3 era), and Windows (i386-unknown-mingw32). There's a source snapshot if you want to build yourself - please try this if you can, we need to make sure the source bundle builds cleanly. One thing that Don, Ian and I were discussing was having a tarball of the testsuite and nofib performance suite to go along with the official 6.4.2 release. This would make it easier for us to be consistent. Having the testsuite go with the ghc release will mean we can be sure about which tests we expect to fail on x86/amd64 and we can use that as a comparison for the other arch ports. If we could get a tarball of the testsuite out before the release then we can send in our results for various arches and that could be included into the know failures files for the testsuite that goes official release. It'd give us a better sense of the state of things on each arch. Perhaps we could record testsuite results for different arches on the ghc wiki somewhere. Having a known benchmark like that would be very good to see if we're breaking things eg in porting, getting registerised builds working, gcc upgrades etc. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.5 on Mac Os X
On 28-Mar-06, at 4:52 AM, Simon Marlow wrote: This seems very strange indeed - I immediately suspect something odd with your hardware. Try swapping out RAM, if you can. Strange that it only seems to affect Perl (Perl is running the mangler that generates that .s file). I suppose it's possible there could be something strange with your Perl - maybe try replacing that? If you run GHC with -keep-tmp-files, you can capture the erroneous .s file for later inspection; that might give us more clues. We went through that off-list on the weekend. Perl really seems to be misbehave in a strange, non-deterministic way on Christopher's machine. I, too, suspect a strange hardware problem, but the fact is that I am clueless. Did you know that the Catholic Church still has trained exorcists? Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.5 on Mac Os X
Hi, I have managed to get through stage1 of the compilation - but now I get link errors! ... TcTyDecls.o stage1/typecheck/TcType.o stage1/typecheck/TcUnify.o stage1/types/Class.o stage1/types/FunDeps.o stage1/types/ Generics.o stage1/types/InstEnv.o stage1/types/Kind.o stage1/types/ TyCon.o stage1/types/Type.o stage1/types/TypeRep.o stage1/types/ Unify.o stage1/utils/Bag.o stage1/utils/Binary.o stage1/utils/ BitSet.o stage1/utils/BufWrite.o stage1/utils/Digraph.o stage1/ utils/Encoding.o stage1/utils/FastMutInt.o stage1/utils/ FastString.o stage1/utils/FastTypes.o stage1/utils/FiniteMap.o stage1/utils/IOEnv.o stage1/utils/ListSetOps.o stage1/utils/ Maybes.o stage1/utils/OrdList.o stage1/utils/Outputable.o stage1/ utils/Panic.o stage1/utils/Pretty.o stage1/utils/StringBuffer.o stage1/utils/UniqFM.o stage1/utils/UniqSet.o stage1/utils/Util.o stage1/parser/hschooks.o ld: Undefined symbols: _TypeRep_AClass_stauic_info ghc: 13296096 bytes, 3 GCs, 166208/166208 avg/max bytes residency (1 samples), 15M in use, 0.10 INIT (0.00 elapsed), 0.06 MUT (3.31 elapsed), 0.04 GC (0.04 elapsed) :ghc make: *** [stage1/ghc-6.5.20060117] Error 1 Could this also have something todo with the mangler? Chris. On 29 Mar 2006, at 20:01, Wolfgang Thaller wrote: On 28-Mar-06, at 4:52 AM, Simon Marlow wrote: This seems very strange indeed - I immediately suspect something odd with your hardware. Try swapping out RAM, if you can. Strange that it only seems to affect Perl (Perl is running the mangler that generates that .s file). I suppose it's possible there could be something strange with your Perl - maybe try replacing that? If you run GHC with -keep-tmp-files, you can capture the erroneous .s file for later inspection; that might give us more clues. We went through that off-list on the weekend. Perl really seems to be misbehave in a strange, non-deterministic way on Christopher's machine. I, too, suspect a strange hardware problem, but the fact is that I am clueless. Did you know that the Catholic Church still has trained exorcists? Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Possible runtime overhead of wrapping the IO monad?
Brian Hulley wrote:
With -O2 enabled, __ccall_GC duma_vertex3f is indeed called directly
instead of vertex3f, from a different module, so that proves that
different monads can indeed be used to wrap IO operations without any
performance penalty at all.
However I've just discovered there *is* a penalty for converting between
callback functions that return a different monad from the IO monad. For
example, if I have a RenderM monad that allows primitives to be drawn to the
screen, and a callback:
newtype RenderM a = RenderM (IO a) deriving (Functor, Monad, MonadIO)
type RenderCallback = Int - Int - RenderM ()
where the intention is that the callback will take the width and height of
the window and return a RenderM action, the problem is that because the FFI
does not allow RenderM to appear in a foreign type, the actual render
function has to be converted into a function which returns an IO action
instead of a RenderM action eg by:
type RenderCallbackIO = Int - Int - IO ()
dropRenderM :: RenderCallback - RenderCallbackIO
dropRenderM f x y = let RenderM io = f x y in io
foreign import ccall duma_onRender :: FunPtr RenderCallbackIO - IO
()
foreign import ccall wrapper mkRenderCallbackIO
:: RenderCallbackIO - IO (FunPtr RenderCallbackIO)
onRender :: RenderCallback - IO ()
onRender f = mkRenderCallbackIO (dropRenderM f) = duma_onRender
With -O2 optimization, GHC does not seem to be able to optimize out the call
to dropRenderM even though this just changes the return value of f from
RenderM (IO a) to IO a, so RenderM is not transparent after all:
Duma.onRender = \ (f :: Duma.RenderCallback)
(eta :: GHC.Prim.State# GHC.Prim.RealWorld) -
case (# GHC.Prim.State# GHC.Prim.RealWorld, () #)
Duma.mkRenderCallbackIO
(Duma.dropRenderM f) eta
of wild { (# new_s, a86 #) -
case (# GHC.Prim.State# GHC.Prim.RealWorld, () #) a86
of ds { GHC.Ptr.FunPtr ds1 -
case (# GHC.Prim.State# GHC.Prim.RealWorld,
() #) {__ccall_GC duma_onRender GHC.Prim.Addr#
- GHC.Prim.State# GHC.Prim.RealWorld
- (# GHC.Prim.State# GHC.Prim.RealWorld #)}
ds1 new_s
of wild1 { (# ds2 #) -
(# ds2, GHC.Base.() #)
}
}
}
I must admit I'm not at all clear how to read the -ddump-simpl output so I
may have got this wrong, but since Duma.dropRenderM is mentioned, I think
this means this has not been optimized out.
Therefore there does seem to be an overhead for using different monads at
the moment (?)
Regards, Brian.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Possible runtime overhead of wrapping the IO monad?
On Thu, Mar 30, 2006 at 03:50:06AM +0100, Brian Hulley wrote: where the intention is that the callback will take the width and height of the window and return a RenderM action, the problem is that because the FFI does not allow RenderM to appear in a foreign type. it should, the types in foreign declarations should see through newtypes. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
