September 2006 - Glasgow-haskell-users

Help with unregisterised build
by Jeremy Wazny 25 Sep '06

25 Sep '06

Hello GHC users, I've attempted to build an installation of GHC which uses unregisterised libraries, but have not had much success. I am new to GHC's build system and would be grateful for some advice. I'm trying to build the 6.4.2 source distribution on an x86 linux machine, using GHC 6.4.2 (the "Generic Linux with glibc2.3" version on the download page.) The target is the same machine. I've created a mk/build.mk file containing just the line: GhcUnregisterised = YES which, according to the comment in mk/config.mk, ought to build the unregisterised libraries that I'm after (and use them by default.) I run configure as follows: ./configure --prefix="$HOME"/ghc_u and then simply "make". After some time, the build fails with the following: ------------------------------------------------------------------------ ==fptools== make all -wr; in /mnt/raid/home/jeremyrw/src/src/ghc-6.4.2/libraries/base ------------------------------------------------------------------------ ../../ghc/compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude -"#include" HsBase.h -funbox-strict-fields -ignore-package base -O -Rghc-timing -fgenerics -fgenerics -split-objs -c GHC/Err.lhs-boot -o GHC/Err.o-boot -ohi GHC/Err. hi-boot <<ghc: 13862608 bytes, 4 GCs, 102828/102828 avg/max bytes residency (1 samples), 18M in use, 0.00 INIT (0.00 elapsed), 0.03 MUT (0.03 elapsed), 0.00 GC (0.02 elapsed) :ghc>> rm -f GHC/Base.o; if [ ! -d GHC/Base_split ]; then mkdir GHC/Base_split; else /usr/bin/find GHC/Base_split -name '*.o' -print | xargs rm -f __rm_food; fi; ../../ghc/compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude -"#include" HsBase.h -funbox-strict-fields -ignore-package base -O Rghc-timing -fgenerics -fgenerics -split-objs -c GHC/Base.lhs -o GHC/Base.o -ohi GHC/Base.hi /tmp/ghc4237.s: Assembler messages: /tmp/ghc4237.s:17: Error: symbol `__stg_split_marker' is already defined /tmp/ghc4237.s:29: Error: symbol `__stg_split_marker' is already defined /tmp/ghc4237.s:41: Error: symbol `__stg_split_marker' is already defined /tmp/ghc4237.s:53: Error: symbol `__stg_split_marker' is already defined .... This goes on for a while ... /tmp/ghc4237.s:16568: Error: symbol `__stg_split_marker' is already defined /tmp/ghc4237.s:16614: Error: symbol `__stg_split_marker' is already defined /tmp/ghc4237.s:16660: Error: symbol `__stg_split_marker' is already defined /tmp/ghc4237.s:16706: Error: symbol `__stg_split_marker' is already defined <<ghc: 124912780 bytes, 12 GCs, 808164/1513632 avg/max bytes residency (2 samples), 19M in use, 0.00 INIT (0.00 elapsed), 0.59 MUT (2.39 elapsed), 0.10 GC (0.09 elapsed) :ghc>> make[2]: *** [GHC/Base.o] Error 1 make[1]: *** [all] Error 1 make[1]: Leaving directory `/mnt/raid/home/jeremyrw/src/src/ghc-6.4.2/libraries' make: *** [build] Error 1 I've also tried with the following build.mk (I was guessing the -fvia-C might avoid the above assembler problem.): GhcUnregisterised = YES GhcLibHcOpts = -O -fvia-C but it fails in the same way. I'm not sure what to do at this point. Am I missing something in the build.mk? My ultimate goal is to link a Haskell object, which exports one of its functions via the FFI, with some other objects, into a single shared object. To do this I will need to compile everything with gcc's -fPIC flag, hence the need for unregisterised libraries. To go that extra step (to get relocatable GHC libraries), I'm guessing that I'll need to extend the GhcLibHcOpts line in build.mk with: -optc -fPIC. Will I need to do that for the run-time system as well? i.e. adding a line like: GhcRtsHcOpts = -fvia-C -optc '-fPIC' Is there likely to be anything else that needs to be tweaked? Has anybody had any success with this sort of thing before? Regards, Jeremy ____________________________________________________ On Yahoo!7 Answers: 25 million answers and counting. Learn something new today http://www.yahoo7.com.au/answers

2 1

instance overlap in 6.6 candidate
by Serge D. Mechveliani 25 Sep '06

25 Sep '06

To my request on overlapping instances in 6.6 candidate Simon Peyton-Jones <simonpj(a)microsoft.com> writes on 4 Sep 2006 > [..] > > GHC 6.6's story is that an instance declaration can only be overlapped > if you compile that module with -fallow-overlapping-instances. Since > the list instance for Show was not compiled in this way, you can't > overlap it. > > You may think this is annoying -- but it does mean that you can look at > an instance declaration and see whether it might be overlapped, just by > look at the flags for that module. But why to restrict the user, why one needs to detect which library instance can be overlapped? Why not to allow all of them to overlap? Here is an example of how I alayws was using overlaps with standard instances. ------------------------------------------------ data Equation = ... instance Show Equation where ... instance Show [Equation] where showsPrec _ eqs = <certain program which prints a list of equation in a `nicer' way than by the default list printing > ------------------------------------------------ This gives the user possibility to redefine a certain part of the library instance. Is not ghc-6.4.1 better at this point? ----------------- Serge Mechveliani mechvel(a)botik.ru

7 8

compiler change
by Christian Maeder 25 Sep '06

25 Sep '06

I have to port the following piece of code to ghc-6.6: [...] addSimpleFallOut :: IO a -> IO (Either String a) simpleFallOutId :: ObjectID (simpleFallOutId, addSimpleFallOut) = mkSimpleFallOut mkSimpleFallOut :: (ObjectID,IO a -> IO (Either String a)) mkSimpleFallOut = unsafePerformIO newFallOut {-# NOINLINE mkSimpleFallOut #-} newFallOut :: IO (ObjectID, IO a -> IO (Either String a)) [...] ghc-6.5.20060919 reports: Couldn't match expected type `forall a. IO a -> IO (Either String a)' against inferred type `IO a -> IO (Either String a)' Expected type: (ObjectID, forall a1. IO a1 -> IO (Either String a1)) Inferred type: (ObjectID, IO a -> IO (Either String a)) In the expression: mkSimpleFallOut In a pattern binding: (simpleFallOutId, addSimpleFallOut) = mkSimpleFallOut I can make the code compile by rewriting the pair as: simpleFallOutId = fst mkSimpleFallOut addSimpleFallOut = snd mkSimpleFallOut However, in this case I have inlined mkSimpleFallOut manually! Does this matter? If so, how could I rewrite the above code? Cheers Christian

3 5

Re: Packages in GHC 6.6
by Peter Tanski 24 Sep '06

24 Sep '06

Simon, >> ... At the moment, >> the only packages you can add in this way are: >> >> ALUT, HGL, HUnit, OpenAL, OpenGL, QuickCheck, X11, cgi, >> fgl, haskell-src, html, mtl, network, parsec, time, xhtml > > ... instead include smaller and more "fundamental" > packages: ByteString, regexps, Collections, Edisson, Filepath, Time, > networking, web. I agree with your original idea and Bulat's: the libraries packaged with a compiler should, as a general rule, be those that support the core features of the language or usage of the language itself. Not far off from that are things like being able to work with the operating system--these are essentially related to I/O--because without them your machinations would only be able to operate on themselves. Without getting philosophical about what is and is not necessary for a language to "speak," I'm just looking at the general big-libraries packaged with mature languages like Ada and C++. So here is my vote: Top priority: those you already mentioned, with Bulat's vote for Edison, ByteString, Filepath and Time; I vote for fgl (in my experience fgl is as useful in its own way as Data.Map), mtl, and haskell-src. So the core list might be: *base, haskell98, template-haskell, stm, mtl, haskell-src, *ByteString, Edison, fgl --only because for Edison and fgl there are no reasonable alternatives, so these are in a sense "standard" *readline, unix, Win32, Filepath and Time (they really complement unix and Win32) *Cabal--though this is an extraordinary convenience, it is not strictly necessary (Haskell-GHC users could always be forced to Include everything outside of a standard system directory. I don't mean a GHC-system directory--there are far too many language-specific directory structures crawling around, it's like trying to hide from Wal-Mart.) ... well, that's how I had started the email, but I think your original idea is right: stick with only what you absolutely need and with what is part of the Haskell "standard" library: *base, haskell98, template-haskell, stm, mtl, haskell-src and Cabal are fine; the rest can go together in a special "distribution." Why add mtl and haskell-src? Those seem to be situations where you would have to install a specific library (mtl, say) and specially integrate it into your build of another. At some point the dependencies merit the adoption of a "standard." Extra-Haskell parsing is a good example of leaving things out. HaXml's parser (HuttonMeijerWallace, PolyLazy) is roughly interchangeable with Parsec in many ways--though reasonable people may differ on which is actually better--and installing or uninstalling either would be easy. Things that are missing... There are some library systems that really should come standard and therefore need development. The most specific I can think of are deep-core Haskell debugging libraries (would you think of grabbing gcc without gdb?)--a GHC "HAT." Things that allow specialised code such as haskell-src-exts's dynamic loading modules would also be good--this is like having dynamic libraries for Haskell. Sorry for the length; I've been literally bugged-out with getting a commercially and GPL-usable comparable replacement for GMP going... Personally I would love to give GHC a built-in interface to a real high-level math library (vectors, arbitrary-precision Reals?) but that would be as bad as forcing all gcc users to uninstall a hypothetical gcc-BLAS before they could install their own system- tuned or more precise library. I have been realising more and more that Integers are not a math-library but a data-type (hence bitwise operations). -Pete

7 8

HOpenAL and Haskore
by Juan Rodríguez Hortalá 24 Sep '06

24 Sep '06

Hello everybody, I have a suggestion and a question. The first is about Haskore, I think it would be cool if it could be included in the distribution of GHC. And the later is about HOpenAL. Some information is found in http://www.haskell.org/HOpenGL/newAPI/index.html , on the entry for Sound, but I wonder if there is some tutorial or additional documentation anywhere. Because in http://www.haskell.org/communities/11-2005/html/report.html it is said that "The OpenAL and ALUT packages have not been released yet, but they are already usable and almost feature-complete", and the are supplied with GHC, so maybe I could start learning HOpenAL right now. I have searched for the HOpenAL home page in http://haskell.org/haskellwiki/Libraries_and_tools/Music_and_sound and in google but I haven't found it. Can anybody help me? Thanks in advance -- ________________________________________________________________________ Juan Rodríguez Hortalá

2 1

Re: User preferences lost between Hugs upgrades on Windows
by Claus Reinke 24 Sep '06

24 Sep '06

[some possibly shared hugs/ghci concerns] > The settings on Windows are stored under a registry key for each > specific release. This means that if you install WinHugs, carefully > set up everything, then upgrade, you loose all your settings. part of the reason was also to enable multiple independent versions of Hugs to be installed, I think? So: a) shouldn't there be a way from within Hugs (or GHCi) to export/import settings? b) shouldn't there be an installation option checking for compatible old settings and offering to copy them? c) given the move towards cabal, shouldn't there be a way for new Hugs/GHC installs to take over existing library install setups (provided that the libraries sources haven't been removed, and that the rebuild is possible with the new Haskell implementation)? while on the subject of user preferences, does the current round of Hugs/GHC releases on Windows do away with that "we take over the handling of Haskell files, no matter what the user wanted"? - it's a pain to have Hugs and GHCi compete with each other on this - I don't want either to be the default handler for .hs/.lhs files; not only do I tend to have several versions of Haskell implementations installed at any time (usually including 2 ghcs), I want Haskell files to open in my favourite editor, not in any of those Haskell implementations (and no, going via WinHugs :e is not an option, eg when browsing files from some darcs repo on the web) any chance of Haskell implementations being less greedy and more cooperative on Windows this time round?-) cheers, claus

2 3

6.6 strikes me again :)
by Bulat Ziganshin 22 Sep '06

22 Sep '06

Hello glasgow-haskell-users, attached module compiles fine with ghc 6.4.2, hugs 2003+, but not with my ghc 6.5 snapshot. it says: 66.hs:9:0: Illegal instance declaration for `Stream m (StringReader r)' (the Coverage Condition fails for one of the functional dependencies) In the instance declaration for `Stream m (StringReader r)' -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 3

Data.FiniteMap
by Duncan Coutts 20 Sep '06

20 Sep '06

Is it too late to ask that Data.FiniteMap not die just yet? There are a number of progs/libs that this affects. It's not that people do not want to use the new Data.Map, but people are worried about having to drop support for earlier compilers. Data.Map only appeared in 6.4 iirc. So this forces packages to drop support for 5.04, 6.0 and 6.2. Perhaps 5.04 and 6.0 are not so important, but many people still use 6.2.2, particularly institutions, which tend to be slow to upgrade. I think there is a wrapper somewhere that provides the old Data.FiniteMap in terms of the Data.Map implementation. Could we use something like that in base for at least one more release? By the time of 6.8 I think people will be less concerned as 6.2 will be quite old by that time. Duncan

6 7

Update to Replacement GMP page
by Peter Tanski 20 Sep '06

20 Sep '06

Hello all, I made another update to the notes on Replacing GMP, at http:// hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes . It's pretty basic and you'd probably find it shabby, but comments, modifications appreciated. I am still in the throes of trying to *portably* beat GMP for speed and accuracy. (The portability problem comes in when I may no longer rely on Altivec/SSE/3DNow! support on other processors and need to optimise in pure C.) -Pete

1 0

small errors in ghc 6.6
by Bulat Ziganshin 20 Sep '06

20 Sep '06

Hello glasgow-haskell-users, i've put my hands on the ghc 6.6/mingw32 dated 1st september (http://www.haskell.org/ghc/dist/current/dist/ghc-6.5.20060901-i386-unknown-…) overall, compilation of my 5 kloc application was fine. on the 6.2->6.4 transition, i was bitten by two API changes, but this time all APIs and language features i used remains stable. it's great! the most funny part was that parallel arrays are still work :))) nevertheless, i've captured several minor problems: 1. ghc +RTS -A10m aborts with the message: ghc.exe: getMBlocks: VirtualAlloc MEM_COMMIT failed: The parameter is incorrect. although i guess that it was already fixed since 1st September. btw, how about adding using various RTS switches to ghc as test cases? GHC is very large program and any problems with RTS flags would be captured in this way 2. ghc compilation don't includes directory where Rts.h, Stg.h and similar files resides, "$(GHC)\lib\i386-unknown-mingw32\include" on my installation. it results in failing of via-C compilation, compilation of *stub.c files, and inclusion of "Typeable.h". i was going around this problem by using -I switch. it's possible that it's just packaging problem. again - isn't it possible to catch this problem by testsuite? imho, that this error was not catched means that windows version isn't really tested by anyone? how about trying to build various packages on mingw32 version as test before releasing 6.6? 3. ghc 6.6 includes smart relinking capability which don't relink exe file if it already exists and .hs source files was not changed. that's great but ignores other .o files that can be also linked to program, for example those that was compiled from C sources: gcc -c -o a.o a.c ghc --make Main.hs a.o this command incorrectly don't relinks executable if a.c was changed but Main.hs wasn't -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

4 4