combination not supported: Threaded/Profiling when building NDP library
Hello Having read the papers on Nested Data Parallelism in the Haskell I wanted to play around with the de-sugared implementation in the GHC library NDP. I have built GHC from source, on RHE5, and then installed the NDP library from the tar ball. Following the build instructions in the README I got to building the library which resulted in the following error being reported: ghc-6-6.1: combination not supported: Threaded/Profiling This seems to be down to the fact that -prof and -threaded have been specified on a particular build line, although I emit not to be completely sure about this. Looking through the GHC page on its SMP support it seems to imply that the option -threaded is not needed when building code, rather when linking a parallel program, but it is unclear if this is the case when building a library such as NDP. Having scanned through the GHC source tree it seems that -prof is referenced in numerous places such that it would be a bit of a pain to have to remove these over removing the single reference to -threaded in the ndp.mk file. Thanks for any help that you can provide on this. Many Regards, Ben Benedict R. Gaster S/W Architecture Team Lead ClearSpeed Technology Plc 3110 Great Western Court Hunts Ground Road Stoke Gifford Bristol BS34 8HP -- The contents of this email and any attachments are confidential and may be legally privileged. If you have received this email in error please notify the sender immediately and refrain from copying or disclosing the contents of the email to any third party. ClearSpeed accepts no liability for any viruses which may be transmitted by this email or its attachments. ClearSpeed Technology PLC is a company registered in England under company number 05159262 whose registered office is at 3110 Great Western Court, Hunts Ground Road, Bristol BS34 8HP, UK. ClearSpeed Technology INC is a wholly owned subsidiary of ClearSpeed Technology PLC and is incorporated in the United States of America, with its principle place of business at 3031 Tisch Way, Suite 200, San Jose, CA 95128, US. Additional Company information can be found at the following: http://www.clearspeed.com/aboutus/company/index.html ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
unique id for data types
In order to make my records system practically useable, I need a type family type family NameCmp n m which totally orders datatypes. More precisely, it should return one of the following types: data NameLT = NameLT data NameEQ = NameEQ data NameGT = NameGT for each pair of datatypes n m, according to whether n m, n = m, or n m in some global ordering. This ordering needs to be independent of the context, so it can't be affected by whatever imports there are in the current module. What I want to know is: does GHC give datatypes any global id I could use to generate such an ordering? Would fully qualified names work? Secondly (assuming it's possible) how easy would it be for me to write a patch to add NameCmp to GHC? Where in the source should I start looking? Thanks, Barney. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: unique id for data types
You're asking for something tricky here. |type family NameCmp n m | | which totally orders datatypes. More precisely, it should return one | of the following types: | |data NameLT = NameLT |data NameEQ = NameEQ |data NameGT = NameGT Now, whenever you declare a new data type T, you want, magically, the following instances to spring to life type instance NameCmp T Int = NameLT type instance NameCmp T Bool = NameLT ..etc etc etc... Obviously there would be way too many instances. So you really want a built-in magic type family NameCmp, which does what you want. Furthermore, the behaviour should be predicatable across compilers; so you'd need to specify just what the result should be in a compiler-independent way. Well I suppose you might do that (via lexical comparison of fully-qualified names), but it's clearly An Extension. Type-families alone get nowhere near. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: unique id for data types
Hi Simon, thanks for the response. In fact I really only need NameCmp to be defined for datatypes of the form data T = T but it's still a lot, so I was expecting to need an extension. Lexical comparison of fully qualified names is what I had in mind, but I wanted some confirmation that such things exist! I could post a GHC feature request, but unless I get someone else interested in this, it would probably just sit in Trac indefinitely. Where should I look in the ghc source if I want to add it myself? Barney. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.8.1 from CVS
mechvel: People, please, how to download from CVS the ghc-6.8 branch ? (I need the last version of 6.8.1, the nightly built) I do the following. set $CVSROOT to :pserver:[EMAIL PROTECTED]:/cvs cd $HOME/ghc/cvs cvs login Logging in to :pserver:[EMAIL PROTECTED]:2401/cvs -- its reply CVS password: -- password: cvs -- entered password Unknown host glass.cse.ogi.edu. Thank you in advance for your help, - Hello Serge, In the past year or so we've stopped using CVS. You can now get all the source via the 'darcs' revision control system. Instructions for how to do this are on the GHC developers wiki: http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources Good luck, Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC 6.8.1 RC debugger only breaking on first evaluation of a function
Hi all, I just tried the new GHCi debugger. A great new feature of GHCi 6.8.1. When debugging a function, as for example the qsort function given as an example in the 3.5 The GHCi Debugger documentation page, the debugger will only break on first function evaluation. As haskell is pure and lazy it's probably a normal behavior (reuse last result instead of recompute) but it's not very practical in a debugger. I tried to reload (:r) but it doesn't seems to help. Is there a way to force the function to be re-evalutated without quitting, starting, loading prog and setting breakpoints again, other than making the function part of the IO monad. ;-) Thanks, Olivier. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.8.1 RC debugger only breaking on first evaluation of a function
Olivier, On 18/09/2007, at 20:26, Olivier Boudry wrote: Hi all, I just tried the new GHCi debugger. A great new feature of GHCi 6.8.1. When debugging a function, as for example the qsort function given as an example in the 3.5 The GHCi Debugger documentation page, the debugger will only break on first function evaluation. As haskell is pure and lazy it's probably a normal behavior (reuse last result instead of recompute) but it's not very practical in a debugger. I tried to reload (:r) but it doesn't seems to help. Is there a way to force the function to be re-evalutated without quitting, starting, loading prog and setting breakpoints again, other than making the function part of the IO monad. ;-) Definitely, there should be one such way. Could you paste a ghci session demonstrating the problem? Thanks in advance, we are heavily in need of feedback and bug reports reg. the debugger. pepe ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.8.1 RC debugger only breaking on first evaluation of a function
On 9/18/07, Pepe Iborra [EMAIL PROTECTED] wrote: Could you paste a ghci session demonstrating the problem? Here is a very short and simple debug session showing the problem: === *Main :l debug68.hs [1 of 1] Compiling Main ( debug68.hs, interpreted ) Ok, modules loaded: Main. *Main :break qsort Breakpoint 1 activated at debug68.hs:(1,0)-(3,55) *Main main Stopped at debug68.hs:(1,0)-(3,55) _result :: [a] = _ [debug68.hs:(1,0)-(3,55)] *Main :delete * [debug68.hs:(1,0)-(3,55)] *Main :continue [0,1,3,4,8,11,18,23] *Main :break qsort Breakpoint 2 activated at debug68.hs:(1,0)-(3,55) *Main main [0,1,3,4,8,11,18,23] === The code: === qsort [] = [] qsort (a:as) = qsort left ++ [a] ++ qsort right where (left,right) = (filter (=a) as, filter (a) as) main = do print $ qsort [8, 4, 0, 3, 1, 23, 11, 18] === The sequence is: 1: set a breakpoint at qsort 2: evaluate function main 3: execution stopped at qsort (as expected) 4: delete all breakpoints 5: set breakpoint at qsort again 6: evaluate function main 7: that lazy haskell show the result without stopping at the breakpoint Just for fun I wrote an IO qsort function: qsortIO :: (Ord a) = [a] - IO [a] qsortIO [] = return [] qsortIO (a:as) = do l - qsortIO left r - qsortIO right return $ l ++ [a] ++ r where (left, right) = (filter (=a) as, filter (a) as) and this one gets debugged on each run thanks to it's IO signature. Hope this helps, Best regards, Olivier. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: unique id for data types
On Tue, Sep 18, 2007 at 04:41:33PM +0100, Barney Hilken wrote: Hi Simon, thanks for the response. In fact I really only need NameCmp to be defined for datatypes of the form data T = T but it's still a lot, so I was expecting to need an extension. Lexical comparison of fully qualified names is what I had in mind, but I wanted some confirmation that such things exist! I could post a GHC feature request, but unless I get someone else interested in this, it would probably just sit in Trac indefinitely. Where should I look in the ghc source if I want to add it myself? As usual, Oleg solved this problem long ago. I don't remember a citation, but the gist of the procedure is: data HCons a b data HNil type family TTypeOf a :: * type instance TTypeOf Int = ...ascii code for 'I' 'n' 't' represented using HCons/HNil... ... type family Combine a b :: * type instance Combine LT a = LT type instance Combine EQ a = a type instance Combine GT a = GT type family NumCmp a b :: * type instance NumCmp HNil HNil = EQ type instance NumCmp HNil (HCons a b) = LT type instance NumCmp (HCons a b) HNil = GT type instance NumCmp (HCons a b) (HCons c d) = Combine (NumCmp a c) (NumCmp b d) type family TypeCmp a b :: * type instance TypeCmp a b = NumCmp (TTypeOf a) (TTypeOf b) The O(n) remaining instances can be automated with my Data.Derive.TTypable, if you're willing to switch back to functional dependancies. (Simon, can a TF 'wrapper' for a fundep be meaningfully done?) Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.8.1 RC debugger only breaking on first evaluation of a function
On Tue, Sep 18, 2007 at 02:26:38PM -0400, Olivier Boudry wrote: Hi all, I just tried the new GHCi debugger. A great new feature of GHCi 6.8.1. When debugging a function, as for example the qsort function given as an example in the 3.5 The GHCi Debugger documentation page, the debugger will only break on first function evaluation. As haskell is pure and lazy it's probably a normal behavior (reuse last result instead of recompute) but it's not very practical in a debugger. I tried to reload (:r) but it doesn't seems to help. Is there a way to force the function to be re-evalutated without quitting, starting, loading prog and setting breakpoints again, other than making the function part of the IO monad. ;-) There is a flag to do this, and it's even In The Manual! http://haskell.org/ghc/dist/current/docs/users_guide/ghci-set.html#id313085 3.8.1. GHCi options GHCi options may be set using :set and unset using :unset. The available GHCi options are: +r Normally, any evaluation of top-level expressions (otherwise known as CAFs or Constant Applicative Forms) in loaded modules is retained between evaluations. Turning on +r causes all evaluation of top-level expressions to be discarded after each evaluation (they are still retained during a single evaluation). This option may help if the evaluated top-level expressions are consuming large amounts of space, or if you need repeatable performance measurements. ... Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: unique id for data types
Hi Stefan, That's great! Where can I get hold of your TTypable? It's not in Hackage and Google didn't find it. I don't know where else to look... Barney. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: unique id for data types
Ah! your link lead me to the HList paper, where all questions are answered... Thanks, Barney. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
