- Glasgow-haskell-users

bug in mallocForeignPtrBytes (both 6.4 and 6.6)
by Bulat Ziganshin 27 Sep '06

27 Sep '06

Hello glasgow-haskell-users, the attached program show up the bug in mallocForeignPtrBytes (and newPinnedByteArray#) implementation - it allocates two times more memory as requested. The bug seen both on 6.6rc and june 6.4 windows builds, namely: http://www.haskell.org/ghc/dist/current/dist/ghc-6.5.20060901-i386-unknown-… http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4.2.20060609-i386-unknown… after program prints "40 mb allocated" look at Task Manager indication - it shows that two times more memory actually in use. it seems that problem is only with allocating memory buffers whose sizes are powers of 2 or very close - bug shows for bufsize = 4kb, 1mb or 4095, but not not for 4000 or 10^6 -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

4 5

ANNOUNCE: GHC 6.6 Release Candidate
by Simon Marlow 27 Sep '06

27 Sep '06

Only a week late, we are pleased to announce the Release Candidate phase for GHC 6.6. Snapshots beginning with 6.5.20060831 are release candidates for 6.6 Download snapshots from here: http://www.haskell.org/ghc/dist/current/dist/ Right now we have the source bundles: http://www.haskell.org/ghc/dist/current/dist/ghc-6.5.20060831-src.tar.bz2 http://www.haskell.org/ghc/dist/current/dist/ghc-6.5.20060831-src-extralibs… Only the first of these is necessary. The "extralibs" package contains various extra packages that we normally supply with GHC (and a couple of new ones) - unpack the extralibs tarball on top of the source tree to add them, they will be included in the build automatically. There are also currently binary distributions for x86_64/Linux (Fedora Core 5), i386/Linux (RedHat 7(!)), and Windows. More may appear later. Please test as much as possible, bugs are much cheaper if we find them before the release! Which brings me on to the release itself: we had planned to release before ICFP, but that only leaves just over a week, which isn't really enough time to test the RC thoroughly, so it's looking like the 6.6 release will happen after ICFP now. In the meantime we have the RC to play with, so enjoy... Cheers, Simon

7 11

more extra-libs for ghc 6.6
by Bulat Ziganshin 27 Sep '06

27 Sep '06

Hello glasgow-haskell-users, how about adding to the list of extra libs the following very useful ones: regex-* FilePath MissingH Edison ? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

4 4

TArray
by Bulat Ziganshin 25 Sep '06

25 Sep '06

Hello glasgow-haskell-users, can someone try to compile this one-line module: import Control.Concurrent.STM.TArray with a recent 6.5 builds, preferably mingw32 ones? it doesn't work for me, although TVar and other modules import without any problems; and i see TArray.hi module along with TVar.hi and so on. the message is: Failed to load interface for `Control.Concurrent.STM.TArray': locations searched: Control/Concurrent/STM/TArray.hi Control/Concurrent/STM/TArray.hi-boot compiler is, again, http://www.haskell.org/ghc/dist/current/dist/ghc-6.5.20060901-i386-unknown-… -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

3 2

internal error: asyncRead#, ghci and fps (windows) (trac 806)
by Rene de Visser 25 Sep '06

25 Sep '06

Is there anyway to turn off that ghci runs in threaded mode on windows? fps 0.8 (and software that uses fps) triggers trac error #806. This means that I cannot run such things interactively :-( Rene.

2 1

threadDelay not ending
by Rich Fought 25 Sep '06

25 Sep '06

I've got some unit test code that forks off test processes using the 'system' function and then delays using 'threadDelay' to synchronize with the test process. This has worked fine until I upgraded to 6.4.2, now some of the 'threadDelay' calls never return - it's like they are stuck in limbo. Any ideas? What would have changed between 6.4 and 6.4.2 that would cause this behavior? Thanks, Rich

5 6

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