July 2004 - Glasgow-haskell-users

RE: Dynamic loading problem
by Simon Marlow 18 Feb '05

18 Feb '05

On 30 April 2004 11:26, Duncan Coutts wrote: > Could someone remind me what the remaining issues are in getting ghc > to build Haskell modules/packaged into unix .so shared libraries? > > As I recall it seems to nearly work. Andre Pang got them to load and > function but it was a bit fragile and the rts would complain after a > short while: > http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg03923.h tml It might be possible to do this, but only if you want to do dlopen()-style linking at runtime. Linking a haskell binary against Haskell .so libraries still isn't possible - I had another look at this recently, and although one of the obstacles has been removed, there are others (details available on request). Any remaining issues to do with dlopen()ing a Haskell .so library are probably to do with CAFs. The dynamically loaded code needs to call newDynCAF() instead of newCAF() in a CAF's entry code - this is normally arranged by the RTS linker, but for a .so you'll have to do it some other way, like getting the compiler to emit the different call, or doing some CPP magic (but only for -fvia-C). Any reasonable patches to implement this will be incorporated. Oh, and strictly speaking we should run the __stginit_Foo() function from each dynamically loaded module. But the RTS linker still doesn't do this. Cheers, Simon

4 3

RE: hPutBuf synchronous?
by Simon Marlow 04 Aug '04

04 Aug '04

On 27 July 2004 11:17, David Roundy wrote: > I've been trying to track down a "Bus error" that one of my users is > getting on the macintosh, and am at the point of having just one idea > as to what might be causing it. > > The error happens during garbage collection, as far as I can tell. He > compiled darcs using ghc 6.2.1. > > My only theory is that perhaps hGetBuf (or maybe hPutBuf) isn't > actually synchronous on some platforms? If this were the case, of > course, using h{Get,Put}Buf on a pointer within withForeignPtr might > be dangerous, since the ForeignPtr could be GCed before the hGetBuf > actually takes place. It's hard to imagine that this actually is the > case, but I'm really running out of ideas as to what could cause this > bus error he's seeing. It's not 100% reproducible, but goes away if > he makes the GC triggered less often (in darcs I trigger GCs manually > before doing a large mallocForeignPtr to keep memory usage down), and > when we added a debug message finalizer, he sees it considerably less > often. Alas, I've been unable to reproduce it myself, and his > repository that displays this behavior contains private data. > > Any suggestions and/or insight would be welcome. hGetBuf is synchronous; the system will not write to the buffer after hGetBuf returns. hPutBuf is also synchronous, in the sense that the data to be written is copied out of the buffer passed in, and either written right away or placed in the Handle's buffer ready to be written at a later time. So I don't think your hypothetical scenario is happening, sounds like it must be something else. There has been one GC bug found since 6.2.1, which could perhaps be the cause. Try getting your user to compile up an RTS from the latest CVS sources of the 6.2 branch and see if that helps. Cheers, Simon

2 1

ghci: catching up with hugs?-)
by Claus Reinke 30 Jul '04

30 Jul '04

Having mostly been converted from hugs to ghci (due to working with too large programs or libraries more readily supported there), I've come to find it quite indispensible for Haskell development. However, there are a few corners where I still miss Hugs functionality that doesn't seem to be available in ghci, and I wonder whether there are any plans to remedy this (or whether there are any fundamental obstacles): - especially when working with gui libs, I often find myself wanting to know which instances some type belongs to (as that determines the attributes/properties/etc one may use with that type). in hugs, a simple ":info <type>" gives me the answer: Prelude> :info Bool -- type constructor data Bool -- constructors: False :: Bool True :: Bool -- instances: instance Eq Bool instance Ord Bool instance Ix Bool instance Enum Bool instance Read Bool instance Show Bool instance Bounded Bool in fact, I can even ask by class, using ":info <class>": Prelude> :i Enum -- type class class Enum a where succ :: a -> a pred :: a -> a toEnum :: Int -> a fromEnum :: a -> Int enumFrom :: a -> [a] enumFromThen :: a -> a -> [a] enumFromTo :: a -> a -> [a] enumFromThenTo :: a -> a -> a -> [a] -- instances: instance Enum () instance Enum Char instance Enum Int instance Enum Integer instance Enum Float instance Enum Double instance Integral a => Enum (Ratio a) instance Enum Bool instance Enum Ordering in ghci, such useful info seems absent, and I find myself hunting the haddocs. shouldn't ghci be able to provide this info as well? - since ghc now keeps better source location info, how about ":find <name>"? in hugs, that calls a configurable external command (usually an editor) with the filename and linenumber of <name>'s definition. this is very useful, even more so for Haskell IDEs that communicate with hugs to implement "jump to definition" instead of relying on outdated or non- existent tag files. in ghci, that could simply pass filename and linenumber to a configurable Haskell function (:: String -> Int -> IO ()) - well, if we have the source code.. so we need an indication of whether ghci knows where to find the source, and if not, we need the package and full hierarchical module and item name, so that the user-supplied "find" function could eg. try to open the corresponding haddoc entry if the source is not available, before giving up. simplified example: myfind :: Maybe (FilePath,Int) -> (String,String) -> IO ExitCode myfind (Just (filepath,line)) _ = system $ editor++" +"++show line++" "++filepath myfind Nothing (package,mp) = system $ browser++" "++haddocBase++sep++package++sep++mp++".html" :set find myfind :find MVar -- goes off to open "<somewhere>\base\Control.Concurrent.MVar.html" [ghci already offers source location information as part of ":info", *if* it has seen the source code; I'm just asking for a more convenient interface, as well as infomation in the common case of no source code] - the ":set <something>" command in ghci "feeds" the ghc command line, but how can I figure out the current settings (especially paths and packages)? in hugs ":set" would list all settings; in ghci that doesn't seem to happen. Especially the first two (instance info and configurable source/doc link would help me with frequently recurring work patterns during Haskell code development. Cheers, Claus

3 2

Existential type... problem...
by Scott West 27 Jul '04

27 Jul '04

Hello all, Just got an interesting error, which I can't really understand (but that DOES happen a lot...). Trying to work with existention types, record types, and wrapping the whole thing up in a nice IORef for my uses: data ETable = forall a. EditableTable a => ETable a data GuiRecord = GuiRecord {gtable :: ETable, moz :: MozEmbed, pos :: Position, ent :: Entry} type GuiState = IORef (GuiRecord) Generates the following error: Couldn't match `* -> Type bx' against `*' In the type synonym declaration for `GuiState' Anyone have any ideas?? Thanks in advance! Regards, Scott

2 1

hPutBuf synchronous?
by David Roundy 27 Jul '04

27 Jul '04

Hello all, I've been trying to track down a "Bus error" that one of my users is getting on the macintosh, and am at the point of having just one idea as to what might be causing it. The error happens during garbage collection, as far as I can tell. He compiled darcs using ghc 6.2.1. My only theory is that perhaps hGetBuf (or maybe hPutBuf) isn't actually synchronous on some platforms? If this were the case, of course, using h{Get,Put}Buf on a pointer within withForeignPtr might be dangerous, since the ForeignPtr could be GCed before the hGetBuf actually takes place. It's hard to imagine that this actually is the case, but I'm really running out of ideas as to what could cause this bus error he's seeing. It's not 100% reproducible, but goes away if he makes the GC triggered less often (in darcs I trigger GCs manually before doing a large mallocForeignPtr to keep memory usage down), and when we added a debug message finalizer, he sees it considerably less often. Alas, I've been unable to reproduce it myself, and his repository that displays this behavior contains private data. Any suggestions and/or insight would be welcome. -- David Roundy http://www.abridgegame.org

1 0

reading ghc core files in vim
by John Meacham 23 Jul '04

23 Jul '04

I have found the following filetype plugin for vim to be incredibly useful when reading core files. unfortunatly the translation is one-way, so if you are in the habit of editing core and feeding it back into ghc, you will be disapointed, but for the (more common?) case of reading core to determine what optimizations have been performed, this is quite nice. you can also copy haskell.vim to ~/.vim/syntax/ghc_core.vim to get basic color syntax highlighting. Is there a way to tell ghc to format core files assuming the screen is very wide? the code ends up in a small ribbon along the right side of the screen at pretty low nesting depths making it harder to read.. John --- add to ~/.vim/filetype.vim if exists("did_load_filetypes") finish endif augroup filetypedetect au! BufNewFile,BufRead *.hsc setfiletype haskell au! BufNewFile,BufRead *.as setfiletype haskell au! BufNewFile,BufRead *.pappy setfiletype haskell au! BufNewFile,BufRead *.las setfiletype haskell au! BufNewFile,BufRead *.hcr setfiletype ghc_core augroup END --- ghc_core.vim, place in ~/.vim/ftplugins if exists("s:loaded_ghc_core") finish endif let s:loaded_ghc_core = 1 augroup GhcCore autocmd BufReadPost *.hcr cal s:GhcCoretoUTF8() "autocmd BufWritePre *.hcr cal s:UTF8toGhcCore() " autocmd BufWritePost *.hcr cal s:GhcCoretoUTF8() augroup END function s:UTF8toGhcCore() " we can't do this reversably endfunction function s:GhcCoretoUTF8() silent %s/ZL/(/eg silent %s/ZR/)/eg silent %s/ZM/[/eg silent %s/ZN/]/eg silent %s/ZC/:/eg silent %s/ZZ/Z/eg silent %s/zz/z/eg silent %s/za/&/eg silent %s/zb/|/eg silent %s/zc/^/eg silent %s/zd/$/eg silent %s/ze/=/eg silent %s/zg/>/eg silent %s/zh/#/eg silent %s/zi/./eg silent %s/zl/</eg silent %s/zm/-/eg silent %s/zn/!/eg silent %s/zp/+/eg silent %s/zq/'/eg silent %s/zr/\\/eg silent %s/zs/\//eg silent %s/zt/*/eg silent %s/zu/_/eg silent %s/zv/%/eg silent %s/Z0T/()/eg silent %s/Z2T/(,)/eg silent %s/Z3T/(,,)/eg silent %s/Z4T/(,,,)/eg silent %s/Z5T/(,,,,)/eg silent %s/Z6T/(,,,,,)/eg silent %s/Z1H/(# #)/eg silent %s/Z2H/(#,#)/eg silent %s/Z3H/(#,,#)/eg silent %s/Z4H/(#,,,#)/eg silent %s/Z5H/(#,,,,#)/eg silent %s/Z6H/(#,,,,,#)/eg " these are debatable, but make things less cluttered. silent %s/GHC\.Prim\.//eg silent %s/GHC\.Base\.//eg silent %s/GHC\.IOBase\.//eg endfunction do GhcCore BufRead -- John Meacham - ⑆repetae.net⑆john⑈

2 1

RE: deriving Typeable
by Simon Peyton-Jones 21 Jul '04

21 Jul '04

| newtype Y e = Y { unY :: (e (Y e)) } | deriving(Data,Typeable,Show,Read,Eq) | | gives | E.hs:64: | Can't make a derived instance of `Typeable (Y e)' | (`Y' is parameterised over arguments of kind other than `*') | When deriving instances for type `Y' | | Is there any way around this limitation other than manually expanding Y | everywhere I want to use it (which I really don't want to do)? Is the | limitation inherent to the way Typeable works, or is it just that no one | has implemented it yet? You'll want to read "Scrap more boilerplate" in my home page, for an account of the Typeable classes. In this case you can make Y Typeable easily enough, like this (compile with -fglasgow-exts to make the scoped type variable work): newtype Y e = Y { unY :: (e (Y e)) } instance Typeable1 e => Typeable (Y e) where typeOf _ = mkTyConApp yTc [typeOf1 (undefined :: e ())] yTc :: TyCon yTc = mkTyCon "Main.Y" This could be automated, but there's always an arbitrary limit on the complexity of the kinds of the arguments -- until we get kind polymorphism, that is! Making Y an instance of Data is harder. I'm not sure how to do that. You'd need something like instance Data1 e => Data (Y e) and we don't have a Data1 class yet. Simon

1 0

RE: "Stricts _"
by Simon Peyton-Jones 21 Jul '04

21 Jul '04

I've fixed this now. Thanks for pointing it out. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Ian Lynagh | Sent: 13 July 2004 15:43 | To: Simon Marlow | Cc: glasgow-haskell-users(a)haskell.org; Peter Simons | Subject: Re: "Stricts _" | | On Tue, Jul 13, 2004 at 03:16:39PM +0100, Simon Marlow wrote: | > On 13 July 2004 15:02, Peter Simons wrote: | > | > > ghci-6.3 (from CVS) shows me strictness information when I | > > request :info for a data type, like: | > > | > > [...] Send Mailbox Stricts: _ [...] | > > | > > I have no idea how to read that output, and it doesn't seem | > > to be documented in the manual either. Does the underscore | > > signify that (in the example above) Mailbox is a strict | > > value? Or is it the opposite? | > > | > > Sorry if this is a dumb question, but I simply don't know | > > it. :-) | > | > I don't think :info is working properly in the HEAD right now. It's | > something we need to fix before 6.4. I suggest just ignoring the | > spurious output for now. | | Based on ":info Maybe" and ":info Complex.Complex" the info looks right | to me, with _ meaning non-strict and ! meaning strict. Presumable you | mean that it should print just "Send Mailbox" or "Send !Mailbox"? I | assume this is just what you told GHC when you defined the type, though, | rather than telling you anything about optimisations GHC has done. | | Also, it looks like :info doesn't work for tuples: | | Prelude> :info (,,) | -- *** Exception: No match in record selector TyCon.algTyConRhs | | | Thanks | Ian | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

defaulting vs instance declarations
by Robert Dockins 20 Jul '04

20 Jul '04

Hello all, Is is possible to apply numeric defaulting while looking for matching instance declarations? For example, I'd like the following code to work without having to explicitly specify the type of "7": module Main where class Stuff a b c | a b -> c where hi :: a -> b -> c instance Stuff Integer Bool Bool where hi a b = if b then True else a == 0 instance Stuff Float Bool Bool where hi a b = if b then False else a < 12.0 main = do --putStrLn $ show $ hi 7 True -- doesn't work putStrLn $ show $ hi (7::Integer) True -- works Under normal circumstances, the value of 7 would default to 7::Integer, but this doesn't occur when type classes are involved this way. Instead GHC complains of 'No instance for (Stuff a Bool c)' Obviously, I can just insert '::Integer' everywhere, but that is the problem defaulting was designed to solve, and besides, its really irritating and ugly. BTW I already tried using Data.Typeable to determine the correct types and cast at runtime, but GHC won't default over the constraint: (Typeable a, Num a) because, I suppose, Typeable is not a standard type class (Haskell Report section 4.3.4) Any ideas? Thanks, Robert

1 0

RE: Release plans
by Simon Marlow 20 Jul '04

20 Jul '04

On 20 July 2004 01:43, Bernie Pope wrote: > Since you are working on the backend is there any chance that GHC > could support symbol names in the heap? > > I tried to add this previously and failed miserably. > > I would be happy with a flag, such as '-debug-symbols' or somesuch, > that keeps source symbol names, at least for data constructors, and > possibly functions. > > This would be a BIG win for buddha and possibly other debugging tools. > > Currently I have to turn on -prof which is a bad hack. This is a good suggestion, but it's unlikely that we'll have time to add it before the release. I'd like to see us support more debugging information, preferably in a way that can be stripped from a binary. I'm not sure that we want to have yet another "way" to build libraries. Debugging is something that should be easy, otherwise the effort is too much and we resort to using Debug.trace (I'm guilty of this - I confess to never having tried any of the available debuggers simply because they're not immediate enough). > Will there be any big changes to the heap representation of objects > with the new backend? No change at all. Cheers, Simon

3 2