July 2009 - Glasgow-haskell-users

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

signals and GHC 6.10
by John Meacham 09 Jul '09

09 Jul '09

I noticed that programs compiled with GHC 6.10 seem to be eating signals and exiting with an error code of 255, rather than the proper exit code for the signal that killed the process. I can understand that the GHC runtime may need to perform some cleanup on a SIGINT or other signal, but instead of doing an exit after catching it, could it be modified to restore the original handle (which may be none) and reraise the signal via kill(getpid(), sig)? This is much friendlier and standard behavior and will also ensure any chained signal handlers are run properly. (in addition to giving proper exit codes). John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/

2 2

GHC API: How to determine Type.Type equality when using type operators?
by Christiaan Baaij 09 Jul '09

09 Jul '09

Hi all, I've been doing some work with the GHC API where I translate Haskell to VHDL, and as such I have to translate Haskell Types to VHDL Types. I store the translations in a Map as such: -- A orderable equivalent of CoreSyn's Type for use as a map key newtype OrdType = OrdType { getType :: Type.Type } instance Eq OrdType where (OrdType a) == (OrdType b) = Type.tcEqType a b instance Ord OrdType where compare (OrdType a) (OrdType b) = Type.tcCmpType a b -- A map of a Core type to the corresponding type name type TypeMap = Map.Map OrdType (AST.VHDLId, Either AST.TypeDef AST.SubtypeIn) This solution work fine for 'simple' types and ensures that the VHDL Type definitions are all unique. However, a problem rises when type operators come in to play, as Type.tcEqType does not know the 'rules' of these type operators and can thus not infer that two types are equal. Let me give some context for my problem: We use statically fixed-size vectors instead of lists, as we always want to know the static length of an array. We use a vector implementation similar to Data.Param.FSVec defined in the parameterized-data package [1], except that we use type-level integers from the tfp library [2] to define the static vector lenght. The tfp library support things like type-level multiplication, something that we use in our vector library. Now, say we have two bit vectors of length 12 defined as such: a :: Vector D12 Bit b :: Vector (D3 :*: D4) Bit The GHC type checker can infer that 'a' and 'b' are of equal type, as it knows the definitions for the ':*:' multiplication type-operator that is defined in the tfp library. Of course, the only answer Type.tcEqType can give us if we ask if the types of 'a' and 'b' are equals is False, as it does not know the context provided by the type-operator. So my question is: Is there a functions in the GHC API that I can use to check the equality of two types given the context provided by certain type operators? I have looked at the Haddock documentation, the GHC Wiki, and the GHC code itself, but have been unable to find such a function. Regards, Christiaan [1] http://hackage.haskell.org/package/parameterized-data [2] http://hackage.haskell.org/package/tfp

3 3

6.10.4-pre test
by Serge D. Mechveliani 06 Jul '09

06 Jul '09

Dear GHC developers, I have tested ghc-6.10.3.20090628 on Debian Linux, i-386-kind machine. There were only two tests: 1) making from source by itself 2) making DoCon and running its test (without profiling). It looks all right. With kind regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1