- Glasgow-haskell-users

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

How to save a haskell data structure in C?
by Shu Wu 03 Jul '09

03 Jul '09

Hey, folks. I've got a problem which I've thought about for days. I need to write a program that mixes C and haskell code. And the C code controls the procedure. In C code, I want to save a complex data strcuture defined in haskell and pass it back to a haskell function at certain time. Like the following: in haskell: data A = A {...} -- very very complex data structure initA :: A initA = A {...} func :: A -> A func a = ... -- return a new 'A' in C: main { a = initA ... take some actions a = func a; ... take some other actions a = func a; ... ... } Different from most cross-language programs, this C program doesn't alter the data in haskell, just saves it and passes it on. So I'm wondering if there's some convienent way other than marshalling the data in haskell? BTW, mashalling data requires all work done in IO monad, which will change the program stucture. So I really don't want to mashal it. Thank you!

2 1

better generation of vi ctags in ghci
by Peter Hercek 02 Jul '09

02 Jul '09

Hi GHC and VI users, I got frustrated with vi tags not working after some unrelated code is edited in a source file. Moreover non-exported top level declarations were not available in vi tags file. Here is an attempt to fix it: http://www.hck.sk/users/peter/pub/ghc/betterCTags.patch Why would you want the new implementation of :ctags ghci command? * Tags are searched based on the line content. This is what Exuberant Ctags do for other languages and it is the other posix way to do it. This makes the positioning to work well even when the source code was edited (on places unrelated to the tag location). More complicated Ex statements can be used to improve it even more but then it does not work well with :tselect (it screws up tag kinds, at least with my version of vim 7.2.65). * All top level symbols defined in a module are added to the tags file. Even the non-exported ones. These are marked as static (file:) so the default tag selection (Ctrl-]) works fine based on the file you started the search from. * Tags get kinds added so you can select whether you want to get to a type constructor or a data constructor (that is if you share names between the two). * In general it is a nice addition to vim haskellmode. If you search for help on symbols in libraries then opening haddock is cool. If you search for help on a symbol in your project then opening the tag in a preview window (Ctrl-W} or ptselect) is cool. Problems: * It needs somebody to check that emacs tags were not broken. I'm not an emacs user but some tag generation code is shared for vim and emacs. I tried to keep emacs tags exactly the way they were (only the exported symbols, original file format). * If your code happens to have definitions on lines which happen to exist more times in one source file then it may put you at an incorrect location. I doubt it will ever happen but if anybody thinks it is really bad we can keep the original format of vim tags too. Then e.g. :ctags would generate tags with line numbers and :ctags! would generate tags with search expressions. If there is any support for this and ghc team decides to merge it I can provide darcs patch. I can do changes needed to get it merged. Peter.

3 5