- Glasgow-haskell-users

Memory leak in FFI callback: GHC 6.6
by SevenThunders 06 Nov '06

06 Nov '06

I'm not sure if this is a bug, but it sure seems that way to me. When using the "wrapper" technique for creating a Haskell callback function it seems that freeHaskellFunPtr is not properly freeing the resource. Here is an example program <leaky.hs> module Main where import Foreign import Foreign.Ptr import Foreign.Storable -- | A convenient type synonym for storable arrays type Darr = Ptr (Double) -- | Function type for mapping doubles to doubles type Dfunc = Double -> Double -- | A convenient type synonym for monad containing storable arrays type IODarr = IO (Darr) foreign import ccall "wrapper" mkDfunc :: Dfunc -> IO (FunPtr Dfunc) foreign import ccall "cleaky.h cfunc" cfunc :: (FunPtr Dfunc) -> IO ( Double ) dadd :: Dfunc dadd x = x + 1.0 getleaky :: Dfunc -> IO () getleaky cf = do pcf <- mkDfunc cf -- pd <- cfunc pcf print pcf freeHaskellFunPtr pcf main = sequence_ [getleaky dadd | q <- [1..500000]] It's compiled with ghc -fglasgow-exts -fffi -prof -auto -I. --make leaky.hs cleaky.o A possible cleaky.c and cleaky.h are #include <math.h> #include <stdio.h> #include "cleaky.h" double state = 1.0 ; double cfunc(DFptr fptr) { // printf("In cfunc, fptr: %p\n", fptr) ; state = (*fptr) (state) ; // printf("state: %g\n", state) ; return(state) ; } typedef double (*DFptr) (double) ; double cfunc(DFptr) ; though they are not used. leaky.exe grows the heap linearly without bound on windows XP 64. The profiler never reports this correctly either. calling leaky +RTS -hc -RTS does not show the increase in the memory usage. -- View this message in context: http://www.nabble.com/Memory-leak-in-FFI-callback%3A-GHC-6.6-tf2565446.html… Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

2 3

Failed OccName lookup in RnEnv with Template Haskell Hack
by Clemens Fruhwirth 04 Nov '06

04 Nov '06

I have written a set of function that generates hsSyn data structures, in particular HsExpr. I want run these functions at compile time, so it can generate user code. I do this via Template Haskell and an ugly hack in TH. TcSplice.lhs expects an ExpQ monad as result for splice expressions. I hesitate to rewrite my functions to generate a TH.Exp hierarchy instead of a (HsExpr RdrName) hierarchy. The hack is to extend TH.Exp with a new constructor InternalE (HsExpr RdrName) and to add a pattern to hsSyn/Convert.lhs in ctvl :: TH.Exp -> CvtM (LHsExpr RdrName) cvt (InternalE expr) = return expr This effectively percises the whole TH.Exp -> HsExpr conversion by providing a Exp constructor with a HsExpr payload, and extending the conversion to just unwrap this payload. This enables me to hand HsExpr to the compiler via Template Haskell via this elegant ugly hack: foobar = $(return (InternalE <function that generates an HsExpr Tree)) Ok, are you still with me? Not running screaming? Fine. The problem is that the RdrNames carried in the HsExpr are not found in the Renamer environment. To give you an example foobar = $(return (InternalE (HsVar (mkUnqual varName (mkFastString "myfoo"))))) which should in the overall result "foobar = myfoo" Running this gives me a "Not in scope" error but the myfoo variable is obviously in the global environment as running this with -ddump-rn-trace shows: test.hs:49:7: Not in scope: `myfoo{v}' Global envt is: [cut] myfoo{v}: main:MyAdd.myfoo{v rI9} imported from MyAdd at test.hs:13:20-24 [cut] In contrast, the TH variant works without any flaws: $(return (VarE (mkName "myfoo"))) I assert that the VarE variant and the InternalE variant are converted to exactly the same HsExpr by hsSyn/Convert.lhs. Using -ddump-slices -dppr-debug shows that both splices generate "myfoo{v}". Using a few more hacks, I even made sure that the printed FastStrings "myfoo" are equal in terms of "getKey# (getUnique str)", this pretty much rules out a bug in UniqFM.hs. Does anyone (especially the developers that are intimate with TH and HsSyn) know what could be the cause? I spent twelve fruitless hours searching for the cause. Many thanks in advance, --- Fruhwirth Clemens - http://clemens.endorphin.org for robots: sp4mtrap(a)endorphin.org

2 2

Re: ghc-6.6 under sparc-sun-solaris
by Christian Maeder 03 Nov '06

03 Nov '06

Duncan Coutts schrieb: >> So "ghc -split-objs" works now with either -optc-mcpu=v8 or >> -opta-mcpu=v9 (or even -opta-mcpu=ultrasparc). >> >> Where should I place what so that my stage1 inplace-compiler works >> without "SplitObjs=NO" in mk/build.mk? > > Try SRC_HC_OPTS = -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc With this I've produced a binary saying: -bash-3.00$ ghc --version ghc-6.6: schedule: re-entered unsafely. Perhaps a 'foreign import unsafe' should be 'safe'? Two further questions: 1. Without "SplitObjs=NO" in mk/build.mk, will every file be compiled as if -split-objs were on ghc's command line? 2. Will the options given in SRC_HC_OPTS be burned into the final stage2 compiler or will I have to supply these options explicitely again? Thanks Christian P.S. building under solaris requires over 2GB memory (and takes a day)

2 5

moving to ghc-6.6
by Johannes Waldmann 02 Nov '06

02 Nov '06

Hello. I just move a larger project to ghc-6.6 (from 6.4) http://dfa.imn.htwk-leipzig.de/auto/ (ca. 1000 modules) I had to modify my sources in several places. Perhaps the following list of observations is useful. tools: cabal/ghc work nicely, including building for profiling and haddockumentation. (I'm still missing cabal support for building docs that I want to access not via the file system but via a web server.) when "ghc --make" finds a source file that starts wrongly (e. g. "modul Foo" instead of "module Foo") (might occur from unobserved CVS merge conflicts) it just says <no location info>: file name does not match module name `Main' and it is quite impossible to find out which file is to blame (even "ghc -v" does not give any information?) type system: In some places I found it convenient to write type decls like foo ( x :: a ) ( y :: [ b ] ) = ... because this gave me at least some kind of documentation while I was too lazy to figure out all the type class requirements that I would need for a full signature. This is now impossible (a and b can no longer be declared by the line above?). But on the other hand this is more a question of coding style, not of compilation. Still the above method gave me the easiest way of getting some programs to compile. I cannot just remove all type sigs because then parts of the program might be ambiguous. To disambiguate, I am now forced to be more verbose. (Which may be a good thing.) Sometimes the type class restrictions in my code are larger than the actual program ... Yes, I introduce "constraint collection classes", e.g. http://141.57.11.163/cgi-bin/cvsweb/box/src/Rewriting/Approximation/Genet.h… I guess I have too much overlapping instances in my code already, and now ghc seems to enforce that this be declared earlier (at the class definition, not usage)? the "coverage condition not satisfied" error message (with functional dependencies) should include a hint that "-fallow-undecidable-instances" might help. library changes: Network.CGI is new, but we have Network.CGI.Compat. Which however refers to Text.XHtml, not Text.Html, so I had to change these imports as well. source encoding: it is annoying that ghc only accepts UTF-8 now. sure I can use "iconv" but I rather not touch my sources at all. with "javac", I can just say "-encoding latin1". Best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------

3 2

ANNOUNCE: GHC version 6.6
by Ian Lynagh 01 Nov '06

01 Nov '06

=========================================================== The (Interactive) Glasgow Haskell Compiler -- version 6.6 =========================================================== The GHC Team is pleased to announce a new release of GHC. There have been many changes since the 6.4.2 release. For details, see the release notes here: http://haskell.org/ghc/docs/6.6/html/users_guide/release-6-6.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; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. 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://www.haskell.org/ghc/docs/latest/html/building/building-guide.html 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

2 1

instance Data (Complex a)
by Chad Scherrer 01 Nov '06

01 Nov '06

I was playing around with the Data.Generics stuff, and I'm getting an error that says No instance for (Data (Complex Double)) Looking at the source for Data.Complex, I see it is an instance of Typeable, but not of Data. Is there a reason not to add "deriving Data" on the end of this? Thanks, Chad

2 1

RE: Proposal for stand-alone deriving declarations?
by Simon Peyton-Jones 01 Nov '06

01 Nov '06

The thread about "stand-alone" deriving is long-ish now, so I have summarised the issues here: http://haskell.org/haskellwiki/GHC/StandAloneDeriving Perhaps those who are interested can add their thoughts? Bjorn is busy at the moment, but I think he'll get back to the implementation in a while, so now is a good time to refine the design. I've tried to note all the issues that came up by email, but I might have missed. I put it on the GHC wiki, because I'm not proposing it for Haskell'. (Someone else is free to do so, of course.) Simon | -----Original Message----- | From: haskell-prime-bounces(a)haskell.org [mailto:haskell-prime-bounces@haskell.org] On Behalf Of | John Meacham | Sent: 30 October 2006 05:17 | To: haskell-prime(a)haskell.org | Subject: Re: Proposal for stand-alone deriving declarations? | | On Fri, Oct 06, 2006 at 10:39:39AM -0500, Michael Shulman wrote: | > On 10/6/06, John Hughes <rjmh(a)cs.chalmers.se> wrote: | > >deriving (Eq Foo, Ord Foo) | > > | > >instead of | > > | > >deriving (Eq, Ord) for Foo | > | > So what does | > | > newtype Foo a = Foo a | > newtype Bar b = Bar b | > class C a b | > deriving (C (Foo a) (Bar b)) | > | > mean? I could see it meaning any or all of the following: | > | > instance (C (Foo a) b) => (C (Foo a) (Bar b)) | > instance (C a (Bar b)) => (C (Foo a) (Bar b)) | > instance (C a b) => (C (Foo a) (Bar b)) | | | this is why we should make this explicit when deriving "complex" newtype | instances, so we would write exactly the instance we want to derive: | | > deriving (C (Foo a) b) => (C (Foo a) (Bar b)) | > deriving (C a (Bar b)) => (C (Foo a) (Bar b)) | > deriving (C a b) => (C (Foo a) (Bar b)) | | respectively. | | John | | -- | John Meacham - ⑆repetae.net⑆john⑈ | _______________________________________________ | Haskell-prime mailing list | Haskell-prime(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-prime

1 0

RE: [Hugs-users] Record puns, time for removal?
by Simon Peyton-Jones 01 Nov '06

01 Nov '06

| There was some discussion on the haskell' list about bring back | record puns, which were once in ghc. | | Record punning would have been very helpful on one of my recent | projects, where I had some large arrays of statically initialized | records. | The longFieldSelectorNamesToAvoidNamespaceClashes are just | noise is such a case. I always thought it was a mistake to remove record puns in H98. I would not be against re-introducing them into GHC, since they appear to remain in Hugs and are in Yhc. Simon

7 10

OpenGL failing with Mac Intel 6.6 distribution
by Deborah Goldsmith 31 Oct '06

31 Oct '06

I'm attempting to build frag on Mac OS X Intel with the 6.6 distribution, and I hit the following: /tmp/ghc25850_0/ghc25850_0.hc:5:22: error: HsOpenGL.h: No such file or directory A comparison of the C include directories for 6.6 and a recent 6.5 build gives: $ diff -r /usr/local/lib/ghc-6.5.20061008/include/ /usr/local/lib/ ghc-6.6/include/ Only in /usr/local/lib/ghc-6.5.20061008/include/: HsOpenGL.h Only in /usr/local/lib/ghc-6.5.20061008/include/: HsOpenGLExt.h Only in /usr/local/lib/ghc-6.5.20061008/include/: HsOpenGLTypes.h Only in /usr/local/lib/ghc-6.6/include/: HsReadline.h Only in /usr/local/lib/ghc-6.6/include/: HsReadlineConfig.h diff -r /usr/local/lib/ghc-6.5.20061008/include/ghcautoconf.h /usr/ local/lib/ghc-6.6/include/ghcautoconf.h 130c130 < #define HAVE_LIBIBERTY 1 --- > /* #undef HAVE_LIBIBERTY */ Is the fact that HSOpenGL*.h is missing in 6.6 expected? Thanks, Deborah

4 7

improving error messages
by Bulat Ziganshin 30 Oct '06

30 Oct '06

Hello glasgow-haskell-users, as you may remember, in GHC survey awkward error messages was named as one of most serious GHC drawbacks. i propose to start collecting examples of bad error messages together with what we want to see in these cases. as first contribution, i've added this text as http://hackage.haskell.org/trac/ghc/ticket/956 the following program main = do putChar 'a' putChar makes this error message:: Couldn't match expected type `IO' against inferred type `(->) Char' Probable cause: `putChar' is applied to too few arguments In the expression: putChar while the 'probable cause' is very helpful, the error message by itself is hard to understand for novices. i propose in these cases to work against known value types. in this case, we know that 'putChar' has type 'Char -> IO ()' and GHC may report smth like this: 'putChar': expression of type 'Char -> IO ()' used in context that requires expression of 'IO ()' type Probably, you've omitted parameter of type 'Char' to this expression comparing this with existing message shows that may be improved: 1) for me, it's still hard to understand what is "expected" and "inferred" means. i guess that for true beginners it's even harder. i prefer to see something more English and less Mathematic - it will be very helpful 2) instead of obscure 'IO' and `(->) Char' types, i strongly prefer to see more pragmatic 'IO ()' and 'Char -> IO ()' ones 3) 'Probable cause' may be more pleasant by telling position and type of skipped argument(s) my second example is almost the same :) main = do putChar putChar 'a' in this case error message is even worser: Couldn't match expected type `(->) Char' against inferred type `IO' Probable cause: `putChar' is applied to too many arguments In the expression: putChar 'a' afaiu, here GHC thought that putChar should have 'IO ()' type. or, it may think that operations in this monad has type 'Char -> IO ()'. anyway, it will be great if GHC will know that operations in monad usually has type 'IO a' or 'm a' and try to use this heuristic when dealing with such errors (different types of statements in 'do' block) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 1