- Glasgow-haskell-users

Link error under solaris 8
by Christian Maeder 08 Nov '06

08 Nov '06

Hi, I get a link error under sparc sun Solaris 8, when linking my stage2 compiler. I have "undefined reference to" a couple of mathematical function like powf, tanhf, coshf, sinhf, atanf, acosf, asinf, tanf, cosf, sinf, sqrtf, logf, and expf Is libm version 2 needed? The stage1 compiler was content with libm version 1. Cheers Christian -bash-3.00$ uname -a SunOS euklid 5.8 Generic_117350-41 sun4u sparc SUNW,Ultra-4 -bash-3.00$ ldd compiler/stage1/ghc-6.6 libdl.so.1 => /usr/lib/libdl.so.1 libm.so.1 => /usr/lib/libm.so.1 libgmp.so.3 => /usr/local/lib/libgmp.so.3 libc.so.1 => /usr/lib/libc.so.1 /usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1 ../compiler/stage1/ghc-inplace -o stage2/ghc-6.6 -H16m -O -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc -package ghc -Istage2 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -Rghc-timing -DGHCI -DBREAKPOINT -threaded stage2/main/Main.o /home/maeder/haskell/solaris/ghc-6.6/libraries/base/libHSbase.a(Float__151.o): In function `s9W7_info': ghc29001_0.hc:(.text+0x290): undefined reference to `powf' /home/maeder/haskell/solaris/ghc-6.6/libraries/base/libHSbase.a(Float__152.o): In function `s9Wv_info': ghc29001_0.hc:(.text+0x28c): undefined reference to `tanhf' /home/maeder/haskell/solaris/ghc-6.6/libraries/base/libHSbase.a(Float__153.o): In function `s9WK_info': ghc29001_0.hc:(.text+0x288): undefined reference to `coshf' /home/maeder/haskell/solaris/ghc-6.6/libraries/base/libHSbase.a(Float__154.o): In function `s9WZ_info': ghc29001_0.hc:(.text+0x288): undefined reference to `sinhf' [...] /home/maeder/haskell/solaris/ghc-6.6/libraries/base/libHSbase.a(Float__237.o): In function `s85X_info': ghc29001_0.hc:(.text+0x974): undefined reference to `atanf' collect2: ld returned 1 exit status <<ghc: 19353284 bytes, 3 GCs, 100700/100700 avg/max bytes residency (1 samples), 15M in use, 0.01 INIT (0.00 elapsed), 0.33 MUT (34.47 elapsed), 0.03 GC (0.09 elapsed) :ghc>> gmake[3]: *** [stage2/ghc-6.6] Error 1 gmake[3]: Leaving directory `/home/maeder/haskell/solaris/ghc-6.6/compiler' gmake[2]: *** [stage2/ghc-6.6] Error 2 gmake[2]: Leaving directory `/home/maeder/haskell/solaris/ghc-6.6/compiler' gmake[1]: *** [stage2] Error 2 gmake[1]: Leaving directory `/home/maeder/haskell/solaris/ghc-6.6' gmake: *** [bootstrap2] Error 2

1 1

Parallelism in 6.6 and seq vs. pseq
by Simon Marlow 08 Nov '06

08 Nov '06

I just noticed, thanks to some testing of the parallelism support in 6.6 by Satnam Singh, that Control.Parallel exports seq when in fact it should probably export pseq. The difference is subtle. The semantics of seq and pseq are identical; however, GHC can see that seq is strict in both its arguments and hence could choose to evaluate them in either order, whereas pseq is only strict in its first argument as far as the strictness analyser is concerned. The point is that pseq is useful for controlling evaluation order, which is what you want for adding parallelism to a program. seq, on the other hand, is not useful for controlling evaluation order. The documentation in 6.6 is also incorrect on this point. pseq is currently not exported by Control.Parallel, this is an oversight on my part, you have to import it from GHC.Conc for now. For 6.8 we'll export pseq from Control.Parallel instead of seq. Incedentally, the fixity of par is also wrong in 6.6: it should be infixr 0, but in fact it has the default fixity of infixl 0. This means if you write an expression like 'x `par` y `seq` z', it isn't doing what you think. Workaround: either use parentheses, or define your own par with the right fixity. Cheers, Simon

4 15

hsman
by Frederik Eaton 07 Nov '06

07 Nov '06

Hello, I have a perl script which I call 'hsman', which indexes Haddock-generated HTML files, and allows users to search for functions and also GHC manual topics. For instance, I can run: $ hsman foldl to open the documentation on 'foldl'. There is also tab-completion in zsh. If people think this would be useful to others, then I can polish it up to be included with 'ghc' distribution. Does that sound like a good idea? Best, Frederik -- http://ofb.net/~frederik/

7 11

Template Haskell quotion for []
by Krasimir Angelov 07 Nov '06

07 Nov '06

Hello, I had this example that was working with earliest versions of GHC but it doesn't work with GHC-6.6. $(deriveReflectable ''[]) Above this isn't a double quote but two single quotes. It may not be clear with some fonts. Is this a bug or just there is a change in the syntax? The error that I get is: src/Database/HarmonyDB/Instances.hs:1:0: Illegal variable name: `[]' When splicing generated code into the program Regards, Krasimir

1 0

make option suggestion
by Frederik Eaton 07 Nov '06

07 Nov '06

Hello, I have a proposal for ghc. I think that it should take a new option, say "--make-command". This will specify a command to be run whenever a source file is read in by ghc. The command will be passed an argument, which is the name of the source file. The idea is that the command can be used to create auto-generated "source" files when ghc needs them. The purpose of this would be the following. Suppose I have a source file, say Source.hs, which is generated from some template, say Source.hs.in. If I edit Source.hs.in, and compile my program with 'ghc --make', then the copy of Source.hs which ghc uses will be out of date. That's because ghc doesn't know about the fact that Source.hs is generated from Source.hs.in. If I use ghc, then I'll have to remember to manually generate a new version of Source.hs every time I modify Source.hs.in. But under the present proposal, I would simply write a Makefile with the rules for generating Source.hs, and then pass --make-command=make to ghc. For instance, my Makefile might say: Source.hs: Source.hs.in $(TAC) < $< > $@ Then every time I run ghc, and Source.hs is out of date, an up-to-date version of Source.hs will be generated automatically - because ghc will call 'make Source.hs' before reading it in. Does this sound like a good idea? Frederik -- http://ofb.net/~frederik/

5 7

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