February 2007 - Glasgow-haskell-users

GHC on Cray XMT?
by Chad Scherrer 26 Feb '07

26 Feb '07

The new Cray XMT seems to target exactly the same kind of analytic problems where Haskell excels: http://www.cray.com/products/xmt/ I'm not a hardware guy, but this seems like a natural fit with the recent advances in SMP Haskell. I know some compiler experts, but none of them have experience with Haskell. Can anyone tell me how big an undertaking it would this be to get GHC going on one of these? It seems to me like the fact that the absence of cache on XMT processors should simplify things, since there are less issues reasoning about locality. Thanks! Chad Scherrer "Time flies like an arrow; fruit flies like a banana" -- Groucho Marx

2 1

Re: hasktags - small patch
by Claus Reinke 23 Feb '07

23 Feb '07

> The good reason is that you do not actually want to have to specify > all the options that you need to get your program to compile, merely > to get tag information. To generate the tags for dazzle using ghci > I need to use > echo ":ctags"| ghci -v0 Main.hs -i../lib -i../lib/DData/ -fglasgow-exts -L../ -lsmilec > whereas with hasktags I'd just use > hasktags *.hs yes, that's a general problem with using ghci in real projects. of course, *.hs isn't always sufficient to find the files for a project, and the files might need pre-processing, etc. but there are advantages to not having a proper parser and just treating a project as a collection of files, to be found by globbing or find, and to be scanned for some simple patterns. it means that one can get tags for incomplete projects, even with errors in the files. but as far as the extra options are concerned, i tend to create a miniscript to set the options for a project, and use the fact that --make/--interactive switch between ghc and ghci: #!/bin/sh ghc ${mode:-"--make"} $@ -i../lib -i../lib/DData/ -fglasgow-exts -L../ -lsmilec then, to build with ghc: ./myghc.sh Main.hs or, to invoke ghci: mode="--interactive" ./myghc.sh Main.hs or, to generate tags from outside ghci (this might be worth a command alias): echo ":ctags" | mode="--interactive -v0" ./myghc.sh Main.hs such scripts wouldn't be needed if ghc/ghci could be started from cabal files - you'd just set your options and paths once and for all (there's a ticket for that somewhere). once I'm set up in ghci, as I tend to be while hacking, it is of course just :ctags rather than finding a shell and typing find . -name *hs | xargs hasktags or somesuch;-) > What I would *really* like is a Haskell parser in Exuberant Ctags... > that would mean I could directly use vim's taglist extension. another good point, but: exuberant ctags is just another tagfile generator. it is very good for other languages, but *really* teaching it about Haskell is non-trivial. whereas ghci or ghc-api already know how to type things and all the rest of Haskell's static semantics, in addition to parsing things.. as for using taglist: do you mean the vim function taglist, which gives you a dictionary with information associated with a tag? so you are probably interested in extra information about tags, beyond source location. (*) it should be a lot easier to expand the information generated by :ctags than to add a Haskell parser/type checker to exuberant ctags. the format is simply a comment (to protect old vi from choking on the extra info) followed by a list of extra fields (the dictionary) for each tag. see ":help tags-file-format" in vim, the third variant of the format. the only reasons i didn't do that right away was (a) it was my first serious attempt at using ghc api/extending ghci (Simon M had to do some reworking of my submitted code;-) and (b) i don't know how to use that kind of info in the emacs branch. have a look at ghc/compiler/ghci/InteractiveUI.hs, around listTags/TagInfo. if one knows where to get it, one could add info there (eg, the type of the tag, or whether the tag is a type/class/function/module/whatever). and the extra info ought to be written to the tags file, in collateAndWriteTags (simply ignore the extra info when writing the emacs tag file). hth, claus (*) if you want to go for broke, try ":help cursorhold-example" in vim. that will keep a preview window with the source-location of any tag your cursor remains on for long enough. so you might see the type declaration, or you might see the data type constructors belonging to a type, or .. i haven't used this as a default myself, but it is worth looking at at least once!-)

3 4

status of GreenCard support
by Jefferson Heard 22 Feb '07

22 Feb '07

Hi all, I'm working on wrapping nVidia's CUDA framework for parallel computation to use with GHC and I recalled seeing something that said GreenCard was not working with GHC 6.6, the latest version. Is that correct? If so, is there some simple fix that would make code generated by GreenCard work, or is there some alternative tool that will make it work? What's the status of C2HS? -- Jeff

2 1

-fallow-incoherent-instances not working
by Marc Weber 22 Feb '07

22 Feb '07

I'm trying to learn more about HList. While setting up a small test application I got the following error.. ghc(i) tells me to add -fallow-incoherent-instances but doesn't recognize it ? Is this a bug? marc@localhost /pr/haskell/test/HList $ ghci -package HList HListTestMain.hs ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Loading package HList-0.1 ... linking ... done. [1 of 2] Compiling HListTest.HList ( HListTest/HList.hs, interpreted ) HListTest/HList.hs:12:11: Overlapping instances for HOccursMany (Maybe Int) (HCons t (HCons t1 (HCons [Char] (HCons (Maybe t2) HNil)))) arising from use of `hOccursMany' at HListTest/HList.hs:12:11-24 Matching instances: instance [overlap ok] (HOccursMany e l, HList l) => HOccursMany e (HCons e' l) -- Defined in HOccurs instance [overlap ok] (HOccursMany e l, HList l) => HOccursMany e (HCons e l) -- Defined in HOccurs (The choice depends on the instantiation of `t, t1, t2' Use -fallow-incoherent-instances to use the first choice above) In the expression: hOccursMany l1 In the second argument of `($)', namely `(hOccursMany l1 :: [Maybe Int])' In the expression: print $ (hOccursMany l1 :: [Maybe Int]) Failed, modules loaded: none. Prelude> Leaving GHCi. marc@localhost /pr/haskell/test/HList $ cat HListTest/HList.hs {-# OPTIONS -fglasgow-exts #-} {-# OPTIONS -fallow-undecidable-instances #-} {-# OPTIONS -fallow-overlapping-instances #-} {-# OPTIONS -fallow-incoherent-instances #-} -- <<<<<<<<<<<< given here module HListTest.HList where import HList l1 = 2 .*. 3 .*. "abc" .*. (Just 4) .*. HNil hlistTest = do print $ 2 .*. HNil print $ (hOccursMany l1 :: [Maybe Int]) marc@localhost /pr/haskell/test/HList $ Marc

1 1

Debugging concurrent program - no threads apparently running, but RTS still doing something.
by Alistair Bayley 22 Feb '07

22 Feb '07

Below is a test case for a threading problem I can't figure out. It models a socket server (here I've replaced the socket with an MVar, to keep it simple). The idea is to have a listener which accepts incoming requests on the socket. When one arrives, it forks a handler thread to deal with the request, and returns to listening on the socket. The handler thread is run in parallel with a timeout thread. In the test case below, the handler takes too long, so the timeout thread completes and kills the handler. The problem is that when the main thread ends, the RTS doesn't stop for another 6 or so seconds. The only thread that runs this long is the handler (waitFor (secs 8.0)) but it has already been killed. So I'm scratching my head a bit. Also, any pointers to better techniques for designing and debugging concurrent code are appreciated (is there a better way than putStrLn?) Platform: ghc-6.6, Windows XP. Thanks, Alistair --------------------------------------------------------------------- module Main where import Prelude hiding (catch) import Control.Concurrent import Control.Exception import System.IO secs :: Float -> Int secs n = round (n * 1000000) -- e.g. waitFor (secs 25) waitFor n = debug ("waitFor start " ++ show ((fromIntegral n) / 1000000.0)) >> threadDelay n >> debug ("waitFor end " ++ show ((fromIntegral n) / 1000000.0)) debug msg = myThreadId >>= ( \t -> putStrLn $ (show t) ++ ": " ++ msg ) -- Thread 1 - start server then send message main = do hSetBuffering stdout LineBuffering blockingInput <- newEmptyMVar -- like a socket; accept on a socket blocks listnr <- forkIO (listener blockingInput) putMVar blockingInput "hello" waitFor (secs 2.0) debug "main: done" -- Thread 2 - listener. -- Blocks on input; when input arrives, starts handler thread. listener blockingInput = do msg <- takeMVar blockingInput serveRequest msg -- in a real server we'd loop: --listener blockingInput debug "listener: done" -- Start threads 3 and 4 - handler and timeout. serveRequest msg = do let acquire = return () let release _ = debug "handler release action" forkIO (runTimeout 0.1 acquire release (handler msg)) return () handler msg _ = do debug ("handler start: " ++ msg) catch (waitFor (secs 8.0) >> debug "handler end") (\e -> debug ("Exception: " ++ (show e)) >> throwIO e) runTimeout timeout acquire release action = do handlerTid <- myThreadId -- Use this to ensure the timeout thread doesn't start before the handler -- i.e. give the handler a chance to start. startTimeout <- newEmptyMVar timeoutTid <- forkIO (runTimeoutThread startTimeout timeout handlerTid) bracket acquire ( \a -> release a >> killThread timeoutTid ) ( \a -> do debug "runTimeout: start handler action" putMVar startTimeout True action a debug "runTimeout: end handler action" ) runTimeoutThread startTimeout timeout handlerTid = do takeMVar startTimeout debug "runTimeoutThread: start" waitFor (secs timeout) killThread handlerTid debug "runTimeoutThread: end"

2 2

TFP 2007: Registration and Program
by TFP 2007 21 Feb '07

21 Feb '07

Dear Colleagues, You may now resgister for TFP 2007! TFP 2007 will be held April 2-4, 2007 in New York City, USA. Our invited speaker is John McCarthy, Stanford University. Further details can be found at our homepage: http://cs.shu.edu/tfp2007/ . You may register at: http://cs.shu.edu/tfp2007/registration.html . The registration deadline is March 2, 2007 (11:59 p.m. EST). Accomodations information may be found at: http://cs.shu.edu/tfp2007/accomodations.html . We kindly remind you that the deadline to make a hotel reservation at the guaranteed rates offered to TFP 2007 participants is also quickly approaching. We are proud to announce our program of accepted talks: Unifying Hybrid Types and Contracts Jessica Gronski and Cormac Flanagan A Dual Semantics for the Data Description Calculus Yitzhak Mandelbaum, Kathleen Fisher, and David Walker A Metalanguage for Structural Operational Semantics Matthew Lakin and Andrew Pitts An Arrow Based Semantics for Interactive Applications Peter Achten, Marko van Eekelen, Maarten de Mol, and Rinus Plasmeijer Dependent Types: Easy as Pie Dimitrios Vytiniotis and Stephanie Weirich Constructing Correct Circuits -- Hardware Modelling with Dependent Types Edwin Brady, James McKinna, and Kevin Hammond Why Would Extensible Dependent Types Matter Pablo Nogueira and Bruno Oliveira Bytecode Verification for Haskell Robert Dockins and Samuel Z. Guyer UnreadTVar: Extending Haskell Software Transactional Memory for Performance Nehir Sonmez, Cristian Perfumo, Srdjan Stipic, Adrian Cristal, Osman S. Unsal, and Mateo Valero A New Functional Implementation of Grover's Fast Search Algorithm Justin Stallard and Murray Gross An Inference Algorithm for Guaranteeing Safe Destruction Manuel Montenegro, Ricardo Peña, and Clara Segura Hierarchical Master/Worker Skeletons Jost Berthold, Mischa Dieterle, Rita Loogen, and Steffen Priebe Property Directed Generation of First-Order Test Data Fredrik Lindblad Refactoring for Comprehension Gustavo Villavicencio Towards a Box Calculus for Hume Gudmund Grov and Greg Michaelson Scaled Regression: A Refinement of Primitive Recursion Daniel Leivant Equality-Based Uniqueness Typing Edsko de Vries, Rinus Plasmeijer, and David Abrahamson Lightweight Static Resources: Sexy Types for Embedded and Systems Programming Oleg Kiselyov and Chung-chieh Shan Space-Efficient Gradual Typing David Herman, Aaron Tomb, and Cormac Flanagan Use-Based Reference of Polymorphism Dave King and John Hannan Designing a Generic Graph Library Using ML Functors Sylvain Conchon, Jean-Christophe Filliatre, and Julien Signoles The SCIence Joint Research Activity Kevin Hammond, Dana Petcu, Phil Trinder, Abdallah Al Zain, Steve Linton, and Greg Michaelson Generic and Index Programming Jeremy Gibbons, Meng Wang, and Bruno C d. S. Oliveira The AHA Project Marko van Eekelen, Olha Shkaravska, Ron van Kesteren, Bart Jacobs, Sjaak Smetsers, and Erik Poll Studying Helium Program Bahaviour with the Neon Library Jurriaan Hage and Peter van Keeken Design and Implementation of JFP Hao Xu Hop Client-Side Compilation Florian Loitsch Adaptive High-Level Scheduling in a Generic Parallel Runtime Environment Jost Berthold, Abyd Al-Zain, and Hans-Wolfgang Loidl Bundles Pack Tighter than Lists Francisco Lopez-Fraguas, Juan Rodriguez-Hortala, and Jaime Sanchez-Hernandez Model-Based Testing of Thin-Client Web Applications and Navigation Input Pieter Koopman, Peter Achten, and Rinus Plasmeijer We look forward to seeing you at TFP 2007! Cheers, Marco ************************************************************************************ Dr. Marco T. Morazan TFP 2007 Program Committee Chair http://cs.shu.edu/tfp2007/

1 0

Re: ghc 6.6 for mac os x (intel)
by Kirsten Chevalier 20 Feb '07

20 Feb '07

[redirecting to the list] On 2/5/07, Ariel Apostoli <apostoli(a)cs.utexas.edu> wrote: > Hello Kirsten, > > Thanks so much for your time and help so far. However, I am still stuck > on the issue when I try to do this: > > ./configure --with-readline-includes=/usr/local \ > --with-readline-libraries=/usr/local > > I get: > checking build system type... i686-apple-darwin8.8.1 > checking host system type... i686-apple-darwin8.8.1 > checking target system type... i686-apple-darwin8.8.1 > Canonicalised to: i386-apple-darwin > checking for path to top of build tree... /Users/ariel/work/ghc/ghc-6.6 > checking for ghc... no > checking for ghc-pkg matching ... no > checking for ghc-pkg... no > checking whether ghc has readline package... no > checking for nhc... no > checking for nhc98... no > checking for hbc... no > configure: error: GHC is required unless bootstrapping from .hc files. > > Do you know what should I do to avoid this? > Do you already have a binary version of GHC installed? If you want to build GHC from source, you need a binary of GHC installed already, like the error message suggests. (Unless you want to bootstrap from .hc files, but I've never done that, so I don't know.) See: http://haskell.org/ghc/download_ghc_66.html#macosxintel You didn't say what version of Mac OS X you were using; if it's anything older than 10.3, you're probably SOL. Cheers, Kirsten -- Kirsten Chevalier* chevalier(a)alum.wellesley.edu *Often in error, never in doubt "just thinking of a series of dreams" -- Bob Dylan

6 8

Re: [Haskell] Data.Hashtable operations in IO?
by Kirsten Chevalier 20 Feb '07

20 Feb '07

[redirecting to a more appropriate mailing list] On 2/20/07, ROBERT DOUGLAS HOELZ <hoelz(a)wisc.edu> wrote: > I was reading the docs for Data.Hashtable, and quickly noticed that operations on a hashtable are of the IO monad. Why is this? I should think that the operations would look like this: > > insert :: Hashtable -> key -> val -> Hashtable > lookup :: Hashtable -> key -> a If you read the source for Data.HashTable, you'll notice that the HashTable type is defined in terms of mutable arrays, which must be in the IO monad since side effects are involved. This is purely for performance reasons. If you want an analogous type whose operations are pure, look at Data.Map: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Map.html Cheers, Kirsten -- Kirsten Chevalier* chevalier(a)alum.wellesley.edu *Often in error, never in doubt "Nuclear war can ruin your whole compile." -- Karl Lehenbauer

1 0

Thoughts on the design of External Core
by Aaron Tomb 20 Feb '07

20 Feb '07

Over the last few days, I've put some more thought into the overall design of External Core. I looked through some of the GHC code some more, and I'm leaning toward a preference for using IfaceSyn throughout the whole External Core processing path. Simon, feel free to digest this at your leisure when you return. I also welcome feedback from anyone else. I don't assume that either of the following lists is complete or fully correct, and would like to hear any comments or criticism. Now, on to what I see as the pros and cons of using the Iface infrastructure for all aspects of External Core. Pros: * The input segment of this path is largely complete already. It needs a little fixing up (some of which I've already done), but the general design seems sound. * The code in HscMain that calls emitExternalCore is in the middle of the Iface processing pipeline. So, full Iface information is already available. If I understand things correctly, this means that all of the code of the current module is already in scope in IfaceSyn format. Maybe I'm wrong, though, and only type signatures are fully present? * Though I hear that the Iface typechecker generally assumes the absence of errors, the best long-term design decision might be to beef it up to the point where it can really tell you what's wrong when given ill-typed input. It is an external representation, after all. Currently, it's only likely to have come from GHC itself. Perhaps in the future other tools will also manipulate .hi files, however. Using IfaceSyn for External Core would encourage us to improve the typechecker, which would make interfacing with such tools more viable. * It looks like it would be straightforward to pretty-print IfaceSyn in ExternalCore format directly. It has almost exactly the same set of data constructors as (the old) ExternalCore does. The conversion from Core -> Abstract ExternalCore -> Concrete ExternalCore seems unnecessary. We could just do IfaceSyn -> Concrete ExternalCore. Cons: * If the Iface typechecker is indeed less than helpful in the face of errors, it will need to be improved. * I may be missing complications that would make the picture less rosy than I've implied. * One approach to the architecture of GHC (which I had in mind originally) is that all "source code", in whatever format, should somehow go through the HsSyn portion of the compiler. Thus, this part of the compiler does all of the real error checking, whereas the rest can assume certain correctness properties. Using IfaceSyn for External Core would violate this architectural assumption. Aaron

3 4

Re: [Haskell] cabal-upload build problem
by Kirsten Chevalier 19 Feb '07

19 Feb '07

You might try asking this on GHC-users instead, rather than haskell, since it's a GHC-specific question. I took the liberty of CCing this there. Cheers, Kirsten On 2/19/07, Paul Johnson <paul(a)cogito.org.uk> wrote: > > I want to upload a package to Hackage. I tried installing cabal-upload, > but got the following error: > > ! Preprocessing executables for cabal-upload-0.2... > ! Building cabal-upload-0.2... > ! > ! src/CabalUpload.hs:7:7: > ! Could not find module `Distribution.Compat.FilePath': > ! it is hidden (in package Cabal-1.1.6) > > > I tried "ghc-pkg expose Cabal-1.1.6" without success. > > I have ghc-6.6 installed on Linux (Fedora Core 6), including Cabal-1.1.6. > > (BTW I know I will also need a user id and password. That was going to > be my next step). > > Paul. > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell > -- Kirsten Chevalier* chevalier(a)alum.wellesley.edu *Often in error, never in doubt "Dare to be naive."--R. Buckminster Fuller

1 0