- Glasgow-haskell-users

"Could not deduce (MArray (STUArray s) Int (ST s)) from context ()" when applying runST
by Christian Klauser 21 Jul '09

21 Jul '09

Hi, I'm in the process of learning haskell and came across this problem: Using `Glasgow Haskell Compiler, Version 6.10.4, for Haskell 98, stage 2 booted by GHC version 6.10.1` Common beginning of the file ============================ {-# LANGUAGE FlexibleContexts #-} module UPSO where import Control.Monad(forM,forM_) import Control.Monad.ST.Lazy (ST,runST) import Data.Array.MArray (MArray, Ix, getBounds, newArray, readArray, writeArray) import Data.Array.ST (STArray,STUArray) minmax xs@(x:_) = foldr (\x (l,u) -> (min x l,max x u)) (x,x) xs modify a i f = do x <- readArray a i writeArray a i (f x) increment a i = modify a i (+1) decrement a i = modify a i (\x -> x - 1) uniquePermutationsM t 0 = return $! [[]] uniquePermutationsM t pos = do (l,u) <- getBounds t perms <- forM [l..u] (\d -> do count <- readArray t d -- t[d] if count == 0 then return $! [] else do decrement t d pss <- uniquePermutationsM t (pos-1) increment t d return $! (map (d:) pss) ) return $! (concat perms) Using STArray (works) ===================== mkArray :: (Int,Int) -> (ST s) (STArray s Int Int) mkArray bounds = newArray bounds 0 uniquePermutationsST :: [Int] -> ST s [[Int]] uniquePermutationsST xs = do let bounds@(l,u) = (minmax xs) t <- mkArray bounds forM_ xs (increment t) pos <- sum `fmap` mapM (readArray t) [l..u] uniquePermutationsM t pos uniquePermutations xs = runST (uniquePermutationsST xs) Using STUArray (doesn't work) ============================= But when I try to switch to unboxed arrays, I get an error message. mkArray :: (Int,Int) -> (ST s) (STUArray s Int Int) mkArray bounds = newArray bounds 0 uniquePermutationsST :: [Int] -> ST s [[Int]] uniquePermutationsST xs = do let bounds@(l,u) = (minmax xs) t <- mkArray bounds forM_ xs (increment t) pos <- sum `fmap` mapM (readArray t) [l..u] uniquePermutationsM t pos uniquePermutations xs = runST (uniquePermutationsST xs) Error messages ============== Could not deduce (MArray (STUArray s) Int (ST s)) from the context () arising from a use of 'newArray' at UPSO.hs:35:17-33 Possible fix: add (MArray (STUArray s) Int (ST s)) to the context of the type signature for 'mkArray' or add an instance declaration for (MArray (STUArray s) Int (ST s)) In the expression: newArray bounds 0 In the definition of 'mkArray': mkArray bounds = newArray bounds 0 and also: Could not deduce (MArray (STUArray s) Int (ST s)) from the context () arising from a use of 'increment' at UPSO.hs:41:14-24 After almost two hours of fiddling with the type annotations I hope someone can point me in the right direction. What on earth is going wrong? Thank you for your time.

3 4

HPC gives spurious results if sources are compiled with -cpp
by Dominic Steinitz 18 Jul '09

18 Jul '09

Trac doesn't seem to work for us so I'm sending this bug report by email. ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.1 ghc.exe -fhpc -cpp --make CommonHPC.hs -o CommonHPC commonHPC hpc markup CommonHPC --fun-entry-count This gives no entry counts for fact in Common.hs. With more complex modules, you get spurious red, yellow and green over expressions. Dominic. CommonHPC.hs: module Main (main) where import Common main = do test test test = do putStrLn $ show $ fact 4 putStrLn $ show $ fact 5 Common.hs: module Common ( fact ) where fact 0 = 1 fact n = n * fact (n-1)

4 7

Re: CLDouble serialization bug in 6.10.1
by Jeff Heard 17 Jul '09

17 Jul '09

There is a package for serializing doubles on Hackage, Data.Bunary.IEEE754. See: http://hackage.haskell.org/package/data-binary-ieee754 -- Jeff On Fri, Jul 17, 2009 at 1:57 PM, Jeff Heard<jefferson.r.heard(a)gmail.com> wrote: > Bulat, > > There is a package for serializing doubles on Hackage, > Data.Bunary.IEEE754. See: > http://hackage.haskell.org/package/data-binary-ieee754 > > -- Jeff > > On Fri, Jul 17, 2009 at 1:26 PM, Ian Lynagh<igloo(a)earth.li> wrote: >> >> Hi Bulat, >> >> On Sat, Jul 11, 2009 at 09:32:43PM +0400, Bulat Ziganshin wrote: >>> >>> > foreign import ccall unsafe "" >>> > client :: Ptr CLDouble -> IO () >> >> I'm afraid GHC has never supported CLDouble properly. It's been removed >> from the HEAD: >> http://hackage.haskell.org/trac/ghc/ticket/2793 >> and there's a ticket to add proper support: >> http://hackage.haskell.org/trac/ghc/ticket/3353 >> If it's important to you, please add a note to the ticket. >> >> >> Thanks >> Ian >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >

1 0

CLDouble serialization bug in 6.10.1
by Bulat Ziganshin 17 Jul '09

17 Jul '09

Hello glasgow-haskell-users, sorry, i tested it only with 6.6 and 6.10.1. testcase available as http://www.haskell.org/bz/ldouble-bug.zip it's as simple as > foreign import ccall unsafe "" > client :: Ptr CLDouble -> IO () > > main = with 1.0 client and > void client(long double *p) > { > printf ("%f\n",(double)(*p)); > } -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 2

buildFdSets: file descriptor out of range
by Kazu Yamamoto 16 Jul '09

16 Jul '09

Hello, If this is not a right place to ask this question, please tell me another place to ask. I'm developing a mail server with GHC 6.10.3 on Linux. The server is running well at the beginning. But after several hours, it receives an error, "buildFdSets: file descriptor out of range". Please tell me what happened? And please suggest me how to fix this problem. Here is brief description of the server. - linked with ADNS. - complied with the -threaded option since ADNS requires it. - uses forkIO to produce threads. - does not use "deamonize" of System.Posix.Daemonize since it uses forkProcess. I execute my server as foreground process. - Because there are so many nasty SMTP clients, most SMTP connections are time out. Handles of the SMTP connections disappear, so I cannot use "hClose" to close the handles. - pushes the limit of file descriptors to 65536 with setResourceLimit. --Kazu

4 10

ghci debugger: showing function argumetns when stopped at its definition
by Peter Hercek 15 Jul '09

15 Jul '09

Hi, It would be cool if ghci debugger could grab not only the free variables in the selected expression but in one case a bit more. The case is when we stop at a function definition the first time (when just entering it). In this case it should provide bindings of the function arguments. Is it doable without bad consequences? Looks to me like it should not result in some memory leak problems though I do not have idea whether it is hard to do. The reason I want it is that if it would be available I could put a break point which never stops and only continues at the start of a function I'm interested in. Then If I later stop somewhere in the function I have a pretty good chance that the correct arguments are stored in the trace history and I could retrieve them. E.g. with my GhciExt it would be as simple as: -- to strobe function arguments :count 0 <QualifiedFncName> -- and to look them up later when stopped somewhere -- in the function I could just use :locate :back <QualifiedFncName> -- ... or for a specific argument value :find :back <ArgumentName> If you are interested GhciExt is available here: http://www.hck.sk/users/peter/pub/ But other users could do it too in a bit more complicated way (e.g. by stopping at the function start manually and then continuing and then searching the trace history manually again). Of course I can make sure the function arguments get to the history even now but in much more complicated way (by putting a non-stopping break point at each first use of each argument). The problem with this approach is that: * one must look up all the places in the source code * some of the places may not be hit before we stop at some interesting place in the function so some arguments would not be visible yet Thanks, Peter.

3 5

Using the ghc-api to run more than one instance of ghc simultaneously
by Daniel Gorín 14 Jul '09

14 Jul '09

Hi I'm trying to use the GHC API to have several instances of GHC's interpreter loaded simultaneously; each with its own loaded modules, etc. However, this doesn't seem to work well when two instances have loaded modules with the same name. I'm including the code of a small(ish) example of this at the end of the message. The example launches two threads (with forkIO) and fires GHC in interpreted mode on each thread (with GHC.runGhc); then it sequentially loads file TestMain1.hs in the first and TestMain2.hs in the second one and finally tries to evaluate expression test1 defined in the first one followed by test2 defined in the second one. The output is: #./Main 1: Load succeded 2: Load succeded 3: (1,2,3) 4: Main: During interactive linking, GHCi couldn't find the following symbol: Main_test1_closure This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs(a)haskell.org Main: thread blocked indefinitely # The "thread blocked indefinitely" message is not important (comes from simplifying the original example). I tried this both in ghc 6.10.1 and ghc 6.11.20090607 with the same results. Is this a known limitation? Or should I be doing it some other way? Thanks, Daniel {-# LANGUAGE MagicHash #-} module Main where import Prelude hiding ( init ) import Control.Monad ( join, forever ) import Control.Concurrent ( forkIO ) import Control.Concurrent.Chan import GHC ( Ghc ) import qualified GHC import qualified MonadUtils as GHC import qualified GHC.Paths import qualified GHC.Exts main :: IO () main = do let test1 = "TestMain1.hs" let test2 = "TestMain2.hs" writeFile test1 "module Main where test1 = (1,2,3)" writeFile test2 "module Main where test1 = (3,2,1)" -- ghc_1 <- newGhcServer ghc_2 <- newGhcServer line "1" $ runInServer ghc_1 $ load (test1, "Main") line "2" $ runInServer ghc_2 $ load (test2, "Main") line "3" $ runInServer ghc_1 $ eval "test1" line "4" $ runInServer ghc_2 $ eval "test1" where line n a = putStr (n ++ ": ") >> a type ModuleName = String type GhcServerHandle = Chan (Ghc ()) newGhcServer :: IO GhcServerHandle newGhcServer = do pChan <- newChan let be_a_server = forever $ join (GHC.liftIO $ readChan pChan) forkIO $ ghc be_a_server return pChan where ghc action = GHC.runGhc (Just GHC.Paths.libdir) (init >> action) init = do df <- GHC.getSessionDynFlags GHC.setSessionDynFlags df{GHC.ghcMode = GHC.CompManager, GHC.hscTarget = GHC.HscInterpreted, GHC.ghcLink = GHC.LinkInMemory, GHC.verbosity = 0} runInServer :: GhcServerHandle -> Ghc a -> IO a runInServer h action = do me <- newChan writeChan h $ action >>= (GHC.liftIO . writeChan me) readChan me load :: (FilePath,ModuleName) -> Ghc () load (f,mn) = do target <- GHC.guessTarget f Nothing GHC.setTargets [target] res <- GHC.load GHC.LoadAllTargets GHC.liftIO $ putStrLn ("Load " ++ showSuccessFlag res) -- m <- GHC.findModule (GHC.mkModuleName mn) Nothing GHC.setContext [m] [] where showSuccessFlag GHC.Succeeded = "succeded" showSuccessFlag GHC.Failed = "failed" eval :: String -> Ghc () eval e = do show_e <- GHC.compileExpr $ "(show ("++ e ++")) :: String" GHC.liftIO $ putStrLn (GHC.Exts.unsafeCoerce# show_e)

3 4

Re: ANNOUNCE: GHC 6.10.4 Release Candidate 1
by Gregory Wright 14 Jul '09

14 Jul '09

Good rc1 build on OS X 10.5.7 (Leopard/intel). Couldn't run the 6.10.3 testsuite all the way through. Failed with things like =====> getGroupEntryForName(normal) cd ../../../libraries/unix/tests && '/opt/local/var/macports/build/_Users_gwright_src_macports-trunk_dports_lang_ghc-beta/work/ghc-6.10.3.20090628/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -o getGroupEntryForName getGroupEntryForName.hs -package unix >getGroupEntryForName.comp.stderr 2>&1 cd ../../../libraries/unix/tests && ./getGroupEntryForName </dev/null >getGroupEntryForName.run.stdout 2>getGroupEntryForName.run.stderr Wrong exit code (expected 0 , actual 1 ) Stdout: Stderr: getGroupEntryForName: thisIsNotMeantToExist: getGroupEntryForName: does not exist (no group name) Should I be running a different version of the tests? Best Wishes, Greg -- Gregory Wright Antiope Associates LLC 18 Clay Street Fair Haven, New Jersey 07704 USA gwright(a)antiope.com +1 (732) 924-4549 +1 (732) 345-8378 [fax]

1 0

ANNOUNCE: GHC 6.10.4 Release Candidate 1
by Ian Lynagh 13 Jul '09

13 Jul '09

We are pleased to announce the first release candidate for GHC 6.10.4: http://www.haskell.org/ghc/dist/6.10.4-rc1/ We have now fixed all the bugs that we intend to fix for 6.10.4, so if there is a bug that is important to you that hasn't been fixed in the release candidate, please let us know. The release notes are here: http://www.haskell.org/ghc/dist/6.10.4-rc1/release-6-10-4.html The directory above contains two source bundles: ghc-6.10.3.20090628-src.tar.bz2 ghc-6.10.3.20090628-src-extralibs.tar.bz2 Only the first of these is necessary. The "extralibs" package contains various extra packages that we normally supply with GHC - unpack the extralibs tarball on top of the source tree to add them, and they will be included in the build automatically. There are also installers for Windows (i386) and OS X (i386), and binary distributions for x86_64/Linux and i386/Linux. More may appear later. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team

4 3

Re[2]: CLDouble serialization bug in 6.10.1
by Bulat Ziganshin 12 Jul '09

12 Jul '09

Hello David, Sunday, July 12, 2009, 11:18:00 PM, you wrote: >>> foreign import ccall unsafe "" >>> client :: Ptr CLDouble -> IO () > The source suggests the CLDouble isn't implemented, and it just uses a > Double. This probably worked when compiling via-C and including > proper prototypes (the C compiler coerced the value). Since that > isn't done any more, it now incorrectly passes the regular double. i think the same about double. but it not worked either in 6.6.1, even with explicit -fvia-C option -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0