- Glasgow-haskell-users

non-linear complexity of :reload combined with :module in ghci
by Simon Hengel 12 Jul '11

12 Jul '11

Hi all, I realized that ghci shows non-linear time complexity for a sequence of :module and :reload commands, say we do multiple times: :module *Foo :reload Steps to reproduce: time for i in {1..10}; do echo -e ':m Prelude\n:r'; done |ghci time for i in {1..99}; do echo -e ':m Prelude\n:r'; done |ghci On my system the first run uses 1 second of CPU time, the second 39 seconds. Is this considered a bug? Cheers, Simon

2 2

Locating extra-libraries
by Greg Steuck 12 Jul '11

12 Jul '11

Hello, I am integrating ghc-7.0.3 into our build system running on Linux-amd64. One of the features of said build system is full isolation from the host system. This means we do not use the default compilers and library paths. We further have separation between runtime and compile time paths. This means that libm.so is only available in the compile environment and is not anywhere in rpath of the ghc binary. Now, I try to compile a simple TH based program. GHC fails pretty quickly: <command line>: user specified .o/.so/.DLL could not be loaded (libm.so: cannot open shared object file: No such file or directory) Whilst trying to load: (dynamic) m Additional directories searched: (none) After some head scratching I add -L$(dirname $lib.so) to my GHC command line. Life is good? Not quite, the next blow is harder, if I try to compile a slightly more complicated project which requires run time loading of unix package, I get: Loading package unix-2.4.2.0 ... <command line>: can't load .so/.DLL for: pthread (libpthread.so: cannot open shared object file: No such file or directory) The unix package config file lists: extra-libraries: rt util dl pthread This seems to be the logical consequence of "we agreed that all extra-libraries should be found either on the search path or on the package's library-dirs." (http://hackage.haskell.org/trac/ghc/ticket/3930) Unfortunately my environment does not satisfy the preconditions. I will also be hard pressed to pinpoint the compile environment location ahead of time. Sticking the path into the package .conf is hard. All the compiler paths are set up with -pgm flags when I invoke GHC. So, I resort to making this patch diff --git a/ghc/compiler/ghci/Linker.lhs b/ghc/compiler/ghci/Linker.lhs index bd0bb35..192d416 100644 --- a/ghc/compiler/ghci/Linker.lhs +++ b/ghc/compiler/ghci/Linker.lhs @@ -1026,7 +1026,7 @@ linkPackages' dflags new_pks pls = do linkPackage :: DynFlags -> PackageConfig -> IO () linkPackage dflags pkg = do - let dirs = Packages.libraryDirs pkg + let dirs = Packages.libraryDirs pkg ++ libraryPaths dflags let libs = Packages.hsLibraries pkg -- The FFI GHCi import lib isn't needed as This effectively extends the extra-libraries search path to also include any -L paths specified on the command lines. Is there a better way to do what I'm doing? Is there any chance such a patch can be applied? Thanks Greg

2 3

Profile: zero total time
by Matthew Farkas-Dyck 11 Jul '11

11 Jul '11

I am trying to take a profile of a program, but when I run it, the total time (as given in the profiling report file) is zero! total time = 0.00 secs (0 ticks @ 20 ms) However, the -s option yields the following data: 3,429,300,984 bytes allocated in the heap 210,760,024 bytes copied during GC 23,647,224 bytes maximum residency (13 sample(s)) 3,536,968 bytes maximum slop 58 MB total memory in use (0 MB lost due to fragmentation) Generation 0: 6339 collections, 0 parallel, 1.14s, 1.42s elapsed Generation 1: 13 collections, 0 parallel, 0.28s, 0.34s elapsed INIT time 0.00s ( 0.00s elapsed) MUT time 96.60s (124.50s elapsed) GC time 1.42s ( 1.75s elapsed) RP time 0.00s ( 0.00s elapsed) PROF time 0.00s ( 0.00s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 98.02s (126.25s elapsed) %GC time 1.4% (1.4% elapsed) Alloc rate 35,498,347 bytes per MUT second Productivity 98.5% of total user, 76.5% of total elapsed The time taken by each cost centre is also zero. The program is compiled with options "-prof -auto-all -caf-all" by GHC 7.0.3 and run with RTS options "-p -s". The true time taken is certainly NOT zero. How is this possible? Thanks. Cheers, Matthew Farkas-Dyck

4 5

Reloading and templates
by Jonas Almström Duregård 11 Jul '11

11 Jul '11

Hi, In ghci, if you change a module that exports a TH template it will not recompile modules that use the template. Example: -- In A.hs {-#LANGUAGE TemplateHaskell#-} module A where import Language.Haskell.TH a = [d|x = 5|] -- in B.hs {-#LANGUAGE TemplateHaskell#-} import A a -- As expected in ghci B.hs: *Main> x 5 -- But if i change the def. of a to [d|x = 4|] and do :r [1 of 2] Compiling A ( A.hs, interpreted ) Ok, modules loaded: A, Main. *Main> x 5 The only workaround i know is to reload all modules. I assume you have the same problem when compiling with ghc. This has caused headaches for me on several occasions lately, is there a ticket for it or should i submit one? Regards, Jonas

2 1

Mysterious slowness/crashing in GHCi
by Simon Marlow 06 Jul '11

06 Jul '11

Hi folks, GHCi has some weird behaviour sometimes with one or more of these symptoms: - becoming very slow and/or unresponsive - gobbling up memory - crashing with "thread blocked indefinitely on MVar" Some people have reported this happening when they weren't even doing anything, GHCi was just sitting at the prompt. e.g. this ticket: http://hackage.haskell.org/trac/ghc/ticket/4245 All the reports were Windows, but I've seen it happen on Mac too (but not Linux). I really need a way to reproduce this. If anyone has any clues, or can offer any more information (even if it's just a "me too, on platform X"), please let us know. Cheers, Simon

1 0

Network.HaskellNet.IMAP over SSL connection
by HP Wei 29 Jun '11

29 Jun '11

I tried to use Network.HaskellNet.IMAP to read emails and failed: user error (NO: Plaintext authentication disallowed on non-secure (SSL/TLS) connections.) Any solution for reading emails over SSL connection ?? thanks HP

1 0

Testsuite failures and some easy fixes
by Daniel Fischer 28 Jun '11

28 Jun '11

Today's HEAD produced 49 unexpected failures, most of which are caused by trivia. - tcrun006 and tcrun029 use datatype contexts which were removed from HEAD (7 ways each), can be fixed by adding a language pragma (cf. also http://hackage.haskell.org/trac/ghc/ticket/5229) - ghcpk01.stdout hasn't yet been updated to include the new trusted field - ffi005 fails to compile (7 ways) due to an ambiguous occurrence of unsafePerformIO (Foreign and System.IO.Unsafe) - cg005 and T4059 have unexpected stderr due to a warning about unsafePerformIO going to be removed from Foreign - T4437 fails to compile due to a type change: T4437.hs:9:39: Couldn't match expected type `(String, CmdLineParser.FlagSafety, ExtensionFlag, DynFlags.TurnOnFlag -> DynFlags.DynP ())' with actual type `(t0, t1, t2)' In the pattern: (ext, _, _) In a stmt of a list comprehension: (ext, _, _) <- xFlags In the expression: [ext | (ext, _, _) <- xFlags] Those are easily fixed by the attached patches (but some may need a more principled fix). Further, 17 unexpected failures are due to hpc output being formatted differently from the expectation (5x hpc_fork, 6x hpc001, 6x tough). Two unexpected failures (T4809, cgrun068) are due to mtl not being built the dyn way. The remaining 5 are - T4801 (allocating too little because there are fewer Generic instances for tuples) - dph-diophantine-opt (3 ways) - dph-words-opt On my 32-bit box, also T3294 unexpectedly fails since about a week ago due to too little allocation (a bit below 690M, minimum allowed 800M). If that's reproducible and not known to be temporary, the bounds should be adjusted. Cheers, Daniel

2 1

Hoopl: Combining CheckingFuelMonad with State?
by Justin Bailey 27 Jun '11

27 Jun '11

I'd like to carry around some state when rewriting. It seems like CheckingFuelMonad, etc. are set up to use with other monads but I can't get the types to agree. Using MTL I've managed to come up with these types: > newtype RewriteOnce a = R (State Bool a) > deriving (Monad) > > instance MonadState s (CheckingFuelMonad RewriteOnce) where > get = undefined > put = undefined But I cannot write the definitions for get and put. Is this possible or am I misundersanding CheckingFuelMonad? Is there a better approach altogether? Thanks in advance for any help! Justin

2 2

GHC HEAD broken on OS X
by austin seipp 27 Jun '11

27 Jun '11

After doing a 'git pull origin master && ./sync-all pull origin master', I get the following build failure when stage1 attempts to compile the RTS code: http://paste.debian.net/121097/ A quick glance at the errors seem to indicate this work is related to the new events stuff for GHC. Duncan was working on this last I think - is anybody else experiencing this failure? -- Regards, Austin

3 3

Experiencing libffi related problem with GHC HEAD on Ubuntu 11.04
by Ryan Newton 27 Jun '11

27 Jun '11

Has anyone seen this one before? # libffi.so needs to be built with the correct soname. # NOTE: this builds libffi_convience.so with the incorrect # soname, but we don't need that anyway! cd libffi && \ "cp" build/libtool build/libtool.orig; \ sed -e s/soname_spec=.*/soname_spec="libHSffi-ghc7.1.20110609.so<http://libhsffi-ghc7.1.20110609.so/>"/ build/libtool.orig > build/libtool cp: cannot stat `build/libtool': No such file or directory sed: can't read build/libtool.orig: No such file or directory make[2]: *** [libffi/stamp.ffi.configure] Error 2 make[1]: *** [all_libffi] Error 2 make[1]: Leaving directory `/home/newton/build/haskell2/ghc-validate' make: *** [all] Error 2 Thanks, -Ryan P.S. It's not new. I just did a "git pull origin master && ./sync-all pull origin master" and got this error but I also got the same error on this machine back on June 9th. However, this package has built GHC HEAD in the past. It has the standard ubuntu libffi-dev and libffi5 packages installed.

1 0