January 2005 - Glasgow-haskell-users

profiling usage
by Serge D. Mechveliani 24 Jan '05

24 Jan '05

Dear GHC experts, I have questions about the profiling usage in ghc-6.2.2. I have set {-# SCC .. #-} at several points in my large program. The report in a.out.prof is (I have re-formatted it, for the lines were too long) --------------------------------------------------------------------- Mon Jan 24 10:30 2005 Time and Allocation Profiling Report (Final) a.out +RTS -M40m -p -RTS total time = 9.04 secs (452 ticks @ 20 ms) total alloc = 1,047,303,220 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc nubCommut Prelude5 90.0 88.8 isReducibleAtTop Reduce 9.1 9.8 individual inherited COST CENTRE MODULE no. entries %time %alloc %time %alloc MAIN MAIN 1 0 0.0 0.0 100.0 100.0 CAF Main 242 3 0.0 0.0 0.0 0.0 ... ... operatorOccurs Prelude3 250 19526 0.0 0.2 0.0 0.2 concat in nextTermLevel Prelude5 249 183 0.0 0.2 98.7 98.1 isReducibleAtTop Reduce 257 4525 8.4 9.0 8.4 9.0 orderIfCommut Prelude5 256 7052 0.2 0.1 0.2 0.1 nubCommut Prelude5 255 4582 90.0 88.8 90.0 88.8 vectorsOfDepthOfSorts Prelude5 251 379 0.0 0.0 0.0 0.0 vectorsUnderDepthOfSorts Prelude5 254 260 0.0 0.0 0.0 0.0 isReducibleAtTop Reduce 248 314 0.6 0.8 0.6 0.8 ------------------------------------------------------------------------- 1. There was set a single point of {-# SCC "isReducibleAtTop" #-}. Why the report prints the two different lines for it? What is the meaning of such duplication? 2. It prints six number columns instead of 5 explained in the User Guide 5.00 (I am looking into now). The second column looks new. What does it mean? 3. Consider the line "concat in nextTermLevel" Prelude5 249 183 0.0 0.2 98.7 98.1 This center was set in the following style: ... Just class_s -> {-# SCC "concat in nextTermLevel" #-} concat [ofTop f | f <- ops, coarity f == s .. ] where ofTop f = ... ... nubCommut (t:ts) = {-# SCC "nubCommut" #-} ... Now, the line meaning is as follows. (a) This center was entered 249 times. (b) What does this mean 183 ? (c) This very point itself takes almost zero time. (d) The computation tree below this point (caused by this call) takes 98.7% of the total time. Right? The `nubCommut' call is the part of the tree below "concat in nextTermLevel". And its line shows that it takes 90% by itself. So, the main expense is by nubCommut, and the rest of "concat in nextTermLevel" adds about 9% to it. These 9% include, in particular, the cost of the (++) calls. Right? Thank you in advance for the explanation. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Problem with handles in GHC from CVS
by Krasimir Angelov 24 Jan '05

24 Jan '05

Cabal uses something like system "ghc --version >tmp" in order to determine the version of GHC. After the last changes in CVS the above line no longer produces the right result. The temporary file is created but it is empty. It seems like the stdout/stderr handles are flushed in GHC.TopHandler.runMainIO but only if the program terminates without exception. I tried to flush handles in the catch clause but this doesn't help. Any ideas? Cheers, Krasimir

3 3

newbie: GHC 6.3 build problem
by Alson Kemp 24 Jan '05

24 Jan '05

All, Okay, I've done due diligence on this problem and haven't found any solution, so I figured that I'd spam the list for help. System: Gentoo Linux (freshly emerged...) Pentium 3 GCC 3.3.4 I'm trying to build cvs-HEAD and am having problems. The build completes just fine, but the built GHC 6.3 does not include the "-I" include directories option for GCC. "ghc -O2 -v program.hs" shows that gcc is called thusly: gcc -x c /tmp/ghc10338.hc -o /tmp/ghc10338.raw_s -DDONT_WANT_WIN32_DLL_SUPPORT -fno-defer-pop -fomit-frame-pointer -fno-builtin -DSTOLEN_X86_REGS=4 -v -S -Wimplicit -O -D__GLASGOW_HASKELL__=603 -ffloat-store -I . If I use the Gentoo-built 6.2.2, then the call to gcc is: gcc -x c /tmp/ghc32417.hc -o /tmp/ghc32417.raw_s -DDONT_WANT_WIN32_DLL_SUPPORT -fno-defer-pop -mno-omit-leaf-frame-pointer -fomit-frame-pointer -fno-builtin -DSTOLEN_X86_REGS=4 -v -S -Wimplicit -O -D__GLASGOW_HASKELL__=602 -nopie -fno-stack-protector -fno-stack-protector-all -ffloat-store -I . -I . -I /usr/lib/ghc-6.2.2/include Help! How do I build GHC to include the proper "-I" flags when calling gcc? -Alson Kemp

2 3

RE: Dynamic linking under Windows
by Simon Marlow 21 Jan '05

21 Jan '05

On 21 January 2005 09:13, Santoemma Enrico wrote: > I don't understand from the manual whether it is possible to have a > short .exe file and the rest as a dynamic linking part, or not yet. Not at the moment. It was possible in the past, and it might be possible again shortly in the future: Wolfgang Thaller has been doing lots of work on dynamic linking support, which will be in GHC 6.4. It probably won't be completely supported on Windows by 6.4, though. Cheers, Simon

1 0

Dynamic linking under Windows
by Santoemma Enrico 21 Jan '05

21 Jan '05

Hello, I don't understand from the manual whether it is possible to have a short .exe file and the rest as a dynamic linking part, or not yet. Thanks, Enrico

1 0

[ ghc-Feature Requests-1097471 ] amd64: adjustor creation not supported
by SourceForge.net 20 Jan '05

20 Jan '05

Feature Requests item #1097471, was opened at 2005-01-06 21:55 Message generated for change (Comment added) made by wthaller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1097471&group_… Category: None Group: None Status: Open Priority: 3 Submitted By: Thomas Pasch (aanno) Assigned to: Nobody/Anonymous (nobody) Summary: amd64: adjustor creation not supported Initial Comment: Hello, when trying to use wxhaskell on ghc-6.2.2 on an amd64 (unregistered gentoo build) the following happend: $ ./a.out a.out: internal error: adjustor creation not supported on this platform Please report this as a bug to glasgow-haskell-bugs(a)haskell.org, or http://www.sourceforge.net/projects/ghc/ I'm not sure if this is a bug because amd64 is not officially supported. ---------------------------------------------------------------------- >Comment By: Wolfgang Thaller (wthaller) Date: 2005-01-20 23:29 Message: Logged In: YES user_id=566359 The StgFunPtr that is passed to createAdjustor is a pointer to a normal C function (using the standard C calling convention) that takes as it's first argument the StgStablePtr hptr, a second "dummy" argument of the same size that is ignored (this is to help the implementation for the x86 ABI), and then all the arguments that were passed from the constructor. Note that if you need to do something to the stack after the function returns (rather than just tail-calling the function), you should arrange for the function to return to some static piece of code (see obscure_ccall_ret_code for x86) rather than to the adjustor itself. This is because the function might deallocate the adjustor. ---------------------------------------------------------------------- Comment By: Thomas Pasch (aanno) Date: 2005-01-20 21:20 Message: Logged In: YES user_id=349837 OK, I will have a try on this. I sort of understand x86 and x86_64 abi at the moment. There is only one question left at the moment: After I jump to StgFunPtr (a StgFun?) what will happen? Is this (a) a normal C land function that will require its argument (StgStablePtr hptr) as a 1st argument of the "universal" calling convention OR (b) some other kind of magic (from what source code?) that will pop its argument from the stack? Any answer would be appreciated. aanno ---------------------------------------------------------------------- Comment By: Gour (ggd) Date: 2005-01-08 11:34 Message: Logged In: YES user_id=728695 Hi! Just to add it's important issue for me since it affects the general gui-availability for Haskell language on amd64 platform since gtk2hs bindings also depend on it. Pls. raise this priority a little bit - amd64 is really a very 'natural' platform for Haskell :-) Sincerely, Gour ---------------------------------------------------------------------- Comment By: Wolfgang Thaller (wthaller) Date: 2005-01-06 22:48 Message: Logged In: YES user_id=566359 Yes, this is just a "missing feature". A small piece of platform specific code (<50 lines) is required to get foreign import "wrapper" declarations to work, and wxhaskell uses them a lot. A volunteer who wants to fix this would need enough knowledge about assembly language in general to really understand a calling convention (literature on amd64's particular calling convention is available somewhere). Most of the amd64-specific details can be picked up on the job. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1097471&group_…

1 0

[ ghc-Feature Requests-1097471 ] amd64: adjustor creation not supported
by SourceForge.net 20 Jan '05

20 Jan '05

Feature Requests item #1097471, was opened at 2005-01-06 21:55 Message generated for change (Comment added) made by aanno You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1097471&group_… Category: None Group: None Status: Open Priority: 3 Submitted By: Thomas Pasch (aanno) Assigned to: Nobody/Anonymous (nobody) Summary: amd64: adjustor creation not supported Initial Comment: Hello, when trying to use wxhaskell on ghc-6.2.2 on an amd64 (unregistered gentoo build) the following happend: $ ./a.out a.out: internal error: adjustor creation not supported on this platform Please report this as a bug to glasgow-haskell-bugs(a)haskell.org, or http://www.sourceforge.net/projects/ghc/ I'm not sure if this is a bug because amd64 is not officially supported. ---------------------------------------------------------------------- >Comment By: Thomas Pasch (aanno) Date: 2005-01-20 21:20 Message: Logged In: YES user_id=349837 OK, I will have a try on this. I sort of understand x86 and x86_64 abi at the moment. There is only one question left at the moment: After I jump to StgFunPtr (a StgFun?) what will happen? Is this (a) a normal C land function that will require its argument (StgStablePtr hptr) as a 1st argument of the "universal" calling convention OR (b) some other kind of magic (from what source code?) that will pop its argument from the stack? Any answer would be appreciated. aanno ---------------------------------------------------------------------- Comment By: Gour (ggd) Date: 2005-01-08 11:34 Message: Logged In: YES user_id=728695 Hi! Just to add it's important issue for me since it affects the general gui-availability for Haskell language on amd64 platform since gtk2hs bindings also depend on it. Pls. raise this priority a little bit - amd64 is really a very 'natural' platform for Haskell :-) Sincerely, Gour ---------------------------------------------------------------------- Comment By: Wolfgang Thaller (wthaller) Date: 2005-01-06 22:48 Message: Logged In: YES user_id=566359 Yes, this is just a "missing feature". A small piece of platform specific code (<50 lines) is required to get foreign import "wrapper" declarations to work, and wxhaskell uses them a lot. A volunteer who wants to fix this would need enough knowledge about assembly language in general to really understand a calling convention (literature on amd64's particular calling convention is available somewhere). Most of the amd64-specific details can be picked up on the job. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1097471&group_…

1 0

Implicit parameters:
by Keean Schupke 19 Jan '05

19 Jan '05

Question regarding implicit parameters... The GHC manual says: "Dynamic binding constraints behave just like other type class constraints in that they are automatically propagated." But the following code produces an error: --------------------------------------------------------------------------------------------------------- main = do var <- newIORef (0::Int) let ?global_counter = var in f f = do a <- get_unique putStr (showInt a "\n") b <- get_unique putStr (showInt b "\n") c <- get_unique putStr (showInt c "\n") get_unique :: (?global_counter :: IORef Int) => IO Int get_unique = readIORef ?global_counter ---------------------------------------------------------------------------------------------------------- If "(?global_counter :: IORef Int)" were a class constraint the type signature for 'f' could be derived automatically... but we get: Unbound implicit parameter (?global_counter::IORef a) arising from use of `get_unique' at Test.hs:17:13-22 Is this a bug? Is there some reason why this is not possible? (and if it is not possible shouldn't the documentation be changed to reflect this)... Keean.

2 2

RE: [Haskell-cafe] GHC for .NET?
by Simon Peyton-Jones 19 Jan '05

19 Jan '05

| "The GHC compiler for .NET is currently under development at | Microsoft Research, Cambridge". | | Hmm. That location sounds familiar :-) Does anyone know if this is | actually going to happen? Or if there's any code anywhere, however | experimental, to try? It'd make a lot of sense to give GHC a .NET back end, and it's a question that comes up regularly. The reason that we haven't done it here, at GHC HQ, is because it's a more substantial undertaking than might at first appear (see below). Furthermore, it'd permanently add a complete new back-end platform for us to maintain. Given our rather limited development effort (= Simon and me), we have so far not bitten the bullet, and we have no immediate plans to do so. It'd be a good, well-defined project for someone else to tackle, and there is some good groundwork already done: * Sigbjorn Finne did a simple interop implementation that allows a Haskell program to be compiled to native code (as now) but to call .NET programs via a variant of the FFI. I don't think this work is in active use, and I'd be surprised if it worked out of the box, but it could probably be revived with modest effort * Andre Santos and his colleagues at UFPE in Brazil are working on a .NET back end, that generates CLR IL, though I don't know where they are up to. * GHC.Net would be extra attractive if there was a Visual Studio integration for GHC. Substantial progress on this has been made in 2004 by Simon Marlow, Krasimir Angelov, and Andre Santos and colleagues. There may be others that I don't know of. If anyone wants to join in this effort, do contact the above folk. And please keep us informed! Simon Here's a summary of why it's a non-trivial thing to do: - The first thing is to generate native CLR Intermediate Language (IL). That's not really hard. Requires thinking about representations for thunks and functions, and it may not be particularly efficient, but it can surely be done. An open question is about whether to generate verifiable IL or not. The trouble here is that Haskell's type system is more expressive than the CLR's in some ways, notably the use of higher-kinded type variables. So, to generate verifiable IL one is bound to need some run-time casts, and it's not clear how to minimise these. At first blush this is *all* you need do. But it isn't! - Next, you need to think about how to inter-operate with .NET libraries. You don't really want to write "foreign import..." for each and every import. You'd like GHC to read the CLR meta-data directly. But there are lots of tricky issues here; see the paper that Mark Shields and I wrote about "Object-oriented style overloading for Haskell". - Now you need to figure out how to implement GHC's primitive operations: the I/O monad arbitrary precision arithmetic concurrency exceptions finalisers stable pointers software transactional memory Not all of these are necessary, of course, but many are used in the libraries. The CLR supports many of them (e.g. concurrency) but with a very different cost model. - Last, you have to figure out what to do for the libraries. GHC has a pretty large library, and you either have to implement the primops on which the library is based (see previous point), or re-implement it. For example, GHC's implementation of I/O uses mutable state, concurrency, and more besides. For each module, you need to decide either to re-implement it using .NET primitives, or to implement the stuff the module is based on. These challenges are mostly broad rather than deep. But to get a production quality implementation that runs a substantial majority of Haskell programs "out of the box" requires a decent stab at all of them.

2 1

RE: package installation
by Simon Marlow 19 Jan '05

19 Jan '05

On 17 January 2005 22:53, Sean Bowman wrote: > I'm trying to install HUnit to use with ghci and hugs and having some > trouble. It works if I use the -i option with ghci, but I'd rather > not have to specify that on the command line every time. Putting it > in a ~/.ghci file doesn't seem to work. How can I set the search path > for 3rd party Haskell modules? You have two choices: use the -i option, or make a package. The "right way" to use 3rd party libraries is to make a package. We're making it easier to build packages with Cabal (http:///www.haskell.org/cabal/). Incedentally, GHC 6.4 will come with HUnit. And I believe there's a Cabal version floating around somewhere that should install with GHC 6.2.2. Cheers, Simon

1 0