From jvlask at hotmail.com Mon Feb 1 00:33:40 2010 From: jvlask at hotmail.com (John Lask) Date: Mon Feb 1 00:05:34 2010 Subject: ghc rts selection and third party libraries Message-ID: Hello I hope someone can provide some guidance on how I can solve a certain problem. I have a library that taps into the ghc c rts: specifically when the rts is single threaded I am pumping events in via: stg_pending_events, when the threaded rts is used I use sendIOManagerEvent. i.e. I have two versions of the library with the same api. The problem with this is that either library is only good for one context: either threaded rts or not, and the user needs to select the appropriate library to use depending on the use context. What I want to be able to do is to have ghc automatically select the compiled library version to link in depending on the which rts option is selected: "-thread" or not does any one have any ideas? From simonpj at microsoft.com Mon Feb 1 01:50:42 2010 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Feb 1 01:22:21 2010 Subject: Quasi quoting Message-ID: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> Dear GHC users This email is to announce two proposed changes to GHC's quasi-quotation mechanism. For all I know, no one is using quasi-quotation (although it's a very cool feature, thanks to Geoff Mainland), but I didn't think I should take it for granted! The current spec is here: http://haskell.org/haskellwiki/Quasiquotation http://www.haskell.org/ghc/docs/latest/html/users_guide/template-haskell.html#th-quasiquotation A quasi-quote can appear as a (a) expression (b) pattern, and looks like this [$pads| ...blah... |] where 'pads' (of course any name will do) is a record of functions data QuasiQuoter = QuasiQuoter { quoteExp :: String -> Q Exp quotePat :: String -> Q Pat } The idea is that GHC evaluates (pads "...blah..."), and splices in the resulting Exp (or Pat) just as if that's what the user wrote in the first place. Kathleen Fisher has started to use this for her PADS system, and came up with two suggestions. 1. Allow quasi-quotes at the (top-level) declaration level, just like TH splices. So you could say, at top level [$pads| ...blah... |] and have it expand to a bunch of top level Haskell declarations. This seems like an unconditionally good idea. To support it we'd need to add a field to QuasiQuoter: data QuasiQuoter = QuasiQuoter { quoteExp :: String -> Q Exp quotePat :: String -> Q Pat quoteDec :: String -> Q [Dec] } but I don't think anyone will lose sleep over that. 2. Make the notation less noisy for the "customer". In particular, that '$' is scary, and redundant to boot. She would like to write [pads| ...blah... |] I can see the motivation here, but there are two reasons for caution. (i) The Template Haskell quote forms [t| ... |] and [d| ... |] behave rather differently. (ii) If "[pads|" is a lexeme, then some list comprehensions become illegal, such as [x|x<-xs,y<-ys]. But note that because of Template Haskell quotations, a comprehension [t|t<-ts] is already broken, and similarly with 'd', 'e'. So the proposed change will make things *more* uniform, by grabbing every "[blah|" as lexeme. For me (i) is the main issue. The differences are significant. - A TH quote can appear only where an *expression* is expected But a quasiquote can be an expression or pattern or (assuming (1)) declaration - A TH quote has type (Q Typ) or (Q [Dec]) or (Q Exp) But a quasiquote is run immediately and spliced in place of the quote - A TH splice is run during type checking But a quasiquote is run during renaming Even given all that, I'm strongly inclined to follow Kathleen's suggestion: - The differences are there all right, but in some ways the programmer thinks the same way: [lang| blah |] switches to language 'lang'. - Many users will never encounter the issue; they'll just say [pads| blah |] to wake up the PADS magic, and be oblivious to Template Haskell quotes An alternative would be to have some other cue. Ones I've considered - $[pads| ...|], but allowing the $ to be omitted on top-level declarations, top level, just as it now can for TH splices. - [pads:| ... |], with the colon distinguishing quasi-quoting from TH. My gut feel is to go with [|pads| ... |]. Of course this'd be a change from the current syntax, but I think there are few enough users that they'll switch easily enough. Any comments on any of this? Simon From nhn at Cs.Nott.AC.UK Mon Feb 1 03:36:21 2010 From: nhn at Cs.Nott.AC.UK (Henrik Nilsson) Date: Mon Feb 1 03:15:21 2010 Subject: Quasi quoting In-Reply-To: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: <4B669285.8040005@cs.nott.ac.uk> Hi Simon, > For all I know, no one is using quasi-quotation (although it's a very > cool feature, thanks to Geoff Mainland), but I didn't think I should > take it for granted! For info, My PhD student George Giorgidze and myself are using it for our EDSL Hydra for non-causal modelling and simulation of physical systems. Indeed, it is a very cool feature. Actually, for us, almost essential, as it gives us *principled* control over the syntax of the deep aspects of our embedding in a way that the usually embedding tricks just don't provide. We'll have a look. Thanks for letting us know! /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk From Malcolm.Wallace at cs.york.ac.uk Mon Feb 1 04:43:09 2010 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Mon Feb 1 04:16:28 2010 Subject: Quasi quoting In-Reply-To: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: <632EEB13-8E4E-493A-A5A2-CC5C3FA087B4@cs.york.ac.uk> > (ii) If "[pads|" is a lexeme, then some list comprehensions become > illegal, I am not myself a TH or QQ user, but it has always bothered me slightly that the syntax for them steals some valid list comprehensions. Of the alternative syntaxes you suggest... > My gut feel is to go with [|pads| ... |]. ... this one feels the nicest, because [| |] is an ascii approximation of the common syntactic brackets used in semantic specifications. In some ways, to make the correspondence even closer, pads [| ... |] might be even better, although I realise that this might present new problems. Regards, Malcolm From gtener at gmail.com Mon Feb 1 04:53:16 2010 From: gtener at gmail.com (=?UTF-8?Q?Krzysztof_Skrz=C4=99tnicki?=) Date: Mon Feb 1 04:24:53 2010 Subject: ghc rts selection and third party libraries In-Reply-To: References: Message-ID: <220e47b41002010153n2228f1a4kb4ceb66858672431@mail.gmail.com> Perhaps rtsSupportsBoundThreads can help: http://www.haskell.org/ghc/docs/6.12.1/html/libraries/base-4.2.0.0/Control-Concurrent.html#v%3ArtsSupportsBoundThreads Best regards Krzysztof Skrz?tnicki On Mon, Feb 1, 2010 at 06:33, John Lask wrote: > Hello > > I hope someone can provide some guidance on how I can solve a certain > problem. > > I have a library that taps into the ghc c rts: specifically when the rts is > single threaded I am pumping events in via: stg_pending_events, when the > threaded rts is used I use sendIOManagerEvent. > > i.e. I have two versions of the library with the same api. The problem with > this is that either library is only good for one context: either threaded > rts or not, and the user needs to select the appropriate library to use > depending on the use context. > > What I want to be able to do is to have ghc automatically select the > compiled library version to link in depending on the which rts option is > selected: "-thread" or not > > does any one have any ideas? > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From jtod at dcs.gla.ac.uk Mon Feb 1 05:24:43 2010 From: jtod at dcs.gla.ac.uk (John O'Donnell) Date: Mon Feb 1 04:56:21 2010 Subject: Quasi quoting In-Reply-To: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: <0C4BE056B517DD4FA49D9D18B07EB721971460B929@ex4.ad.dcs.gla.ac.uk> Hi, I've been experimenting with quasiquoting, and would like to see both of Kathleen's suggestions adopted. The top level quasi quotes would be useful, and reducing the notational noise would be very nice. I don't see the issue of stealing some currently-valid list comprehensions as very serious. Since [t|t<-ts] and other forms are gone, I've come to think of the syntax [foobar| as already taken for all foobar. The loss here seems minimal but the gain is that DSLs can look more natural. John O'Donnell -----Original Message----- From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Simon Peyton-Jones Sent: 01 February 2010 06:51 To: glasgow-haskell-users@haskell.org Cc: Kathleen Fisher; mainland@eecs.harvard.edu Subject: Quasi quoting Dear GHC users This email is to announce two proposed changes to GHC's quasi-quotation mechanism. For all I know, no one is using quasi-quotation (although it's a very cool feature, thanks to Geoff Mainland), but I didn't think I should take it for granted! The current spec is here: http://haskell.org/haskellwiki/Quasiquotation http://www.haskell.org/ghc/docs/latest/html/users_guide/template-haskell.html#th-quasiquotation A quasi-quote can appear as a (a) expression (b) pattern, and looks like this [$pads| ...blah... |] where 'pads' (of course any name will do) is a record of functions data QuasiQuoter = QuasiQuoter { quoteExp :: String -> Q Exp quotePat :: String -> Q Pat } The idea is that GHC evaluates (pads "...blah..."), and splices in the resulting Exp (or Pat) just as if that's what the user wrote in the first place. Kathleen Fisher has started to use this for her PADS system, and came up with two suggestions. 1. Allow quasi-quotes at the (top-level) declaration level, just like TH splices. So you could say, at top level [$pads| ...blah... |] and have it expand to a bunch of top level Haskell declarations. This seems like an unconditionally good idea. To support it we'd need to add a field to QuasiQuoter: data QuasiQuoter = QuasiQuoter { quoteExp :: String -> Q Exp quotePat :: String -> Q Pat quoteDec :: String -> Q [Dec] } but I don't think anyone will lose sleep over that. 2. Make the notation less noisy for the "customer". In particular, that '$' is scary, and redundant to boot. She would like to write [pads| ...blah... |] I can see the motivation here, but there are two reasons for caution. (i) The Template Haskell quote forms [t| ... |] and [d| ... |] behave rather differently. (ii) If "[pads|" is a lexeme, then some list comprehensions become illegal, such as [x|x<-xs,y<-ys]. But note that because of Template Haskell quotations, a comprehension [t|t<-ts] is already broken, and similarly with 'd', 'e'. So the proposed change will make things *more* uniform, by grabbing every "[blah|" as lexeme. For me (i) is the main issue. The differences are significant. - A TH quote can appear only where an *expression* is expected But a quasiquote can be an expression or pattern or (assuming (1)) declaration - A TH quote has type (Q Typ) or (Q [Dec]) or (Q Exp) But a quasiquote is run immediately and spliced in place of the quote - A TH splice is run during type checking But a quasiquote is run during renaming Even given all that, I'm strongly inclined to follow Kathleen's suggestion: - The differences are there all right, but in some ways the programmer thinks the same way: [lang| blah |] switches to language 'lang'. - Many users will never encounter the issue; they'll just say [pads| blah |] to wake up the PADS magic, and be oblivious to Template Haskell quotes An alternative would be to have some other cue. Ones I've considered - $[pads| ...|], but allowing the $ to be omitted on top-level declarations, top level, just as it now can for TH splices. - [pads:| ... |], with the colon distinguishing quasi-quoting from TH. My gut feel is to go with [|pads| ... |]. Of course this'd be a change from the current syntax, but I think there are few enough users that they'll switch easily enough. Any comments on any of this? Simon _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users The University of Glasgow, charity number SC004401 From marlowsd at gmail.com Mon Feb 1 06:43:40 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Feb 1 06:15:29 2010 Subject: Question regarding combinator call convention In-Reply-To: <201001291602.26275.twhitehead@gmail.com> References: <201001291602.26275.twhitehead@gmail.com> Message-ID: <4B66BE6C.3010200@gmail.com> On 29/01/2010 21:02, Tyson Whitehead wrote: > I was looking through the code for 6.12.1 and am a bit confused about 11.1.3 > in the runtime system documentation docs/rts/rts.tex. That's a very old document and is inaccurate in various ways. The Commentary is more up to date: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts > It says the arguments passing convention to a known combinator differs from > that of the others in that it starts the arguments with R1 instead of R2 (R1 > points to the associated memory data structure for non-combinators). The address of the closure is always passed in R1, and the arguments start at R2, if R2 is a register, or the stack otherwise. Cheers, Simon From marlowsd at gmail.com Mon Feb 1 06:56:01 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Feb 1 06:27:55 2010 Subject: building 6.12.1 with itself In-Reply-To: <20100131132832.GC7536@valhala.home> References: <20100131132832.GC7536@valhala.home> Message-ID: <4B66C151.7080909@gmail.com> I've created a ticket for this: http://hackage.haskell.org/trac/ghc/ticket/3852 Cheers, Simon On 31/01/2010 13:28, Nicolas Martyanoff wrote: > > Hi, > > By reading Matthias Kilian's scripts (thank you !), I successfully builded GHC > 6.12.1. > > GHC 6.10.4 didn't build: > > g Lexer.x > gmake[2]: g: Command not found > gmake[2]: [Lexer.hs] Error 127 (ignored) > RTS -K2m -RTS -agc --strict Parser.y > gmake[2]: RTS: Command not found > gmake[2]: *** [Parser.hs] Error 127 > Failed making boot in genprimopcode: 1 > gmake[1]: *** [boot] Error 1 > gmake: *** [stage1] Error 1 > > But GHC 6.8.3 did. I then built GHC 6.12.1. The only problem was that the > build process doesn't find the iconv lib when it's installed in /usr/local, so > the lib/include paths have to be specified when running ./configure. > > I then installed Cabal 1.9 from darcs, and cabal-install, still from darcs. I > used cabal to install hscolour, xmonad and xmonad-contrib, it worked > perfectly. > > I thought it might be good to build GHC 6.12.1 with itself just to be sure > it's working fine before make a dist, but I now get the following error: > > "/usr/local/bin/ghc" -H32m -O -package-conf libraries/bootstrapping.conf -package-name ghc-6.12.1 -hide-all-packages -i -icompiler/nativeGen -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/cprAnalysis -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/main -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage1/build -icompiler/stage1/build/autogen -Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/stage1 -Icompiler/../libraries/base/cbits -Icompiler/../libraries/base/include -Icompiler/. -Icompiler/parser -Icompiler/utils -optP-include -optPcompiler/stage1/build/autogen/cabal_macros.h -package Cabal-1.9.0 -package array-0.3.0.0 -package base-4.2.0.0 -package bin-package-db- 0.0.0.0 -package bytestring-0.9.1.5 -package containers-0.3.0.0 -package directory-1.0.1.0 -package filepath-1.1.0.3 -package hpc-0.5.0.4 -package old-time-1.0.0.3 -package process-1.0.1.2 -package unix-2.4.0.0 -DSTAGE=1 -Wall -fno-warn-name-shadowing -fno-warn-orphans -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -XRelaxedPolyRec -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -hisuf hi -osuf o -hcsuf hc -c compiler/main/Packages.lhs -o compiler/stage1/build/Packages.o > > compiler/main/Packages.lhs:233:63: > Couldn't match expected type `InstalledPackageInfo_ String' > against inferred type `Cabal-1.8.0.2:Distribution.InstalledPackageInfo.InstalledPackageInfo_ > m' > Expected type: [InstalledPackageInfo_ String] > Inferred type: [Cabal-1.8.0.2:Distribution.InstalledPackageInfo.InstalledPackageInfo_ > m] > In the second argument of `map', namely `conf' > In the first argument of `return', namely > `(map installedPackageInfoToPackageConfig conf)' > gmake[1]: *** [compiler/stage1/build/Packages.o] Error 1 > gmake: *** [all] Error 2 > > I tried to "ghc-pkg mask" Cabal-1.8.0.2, then Cabal-1.9.0, didn't change > anything. > > Does someone know what's going on here, and what can be done to fix it ? > > Regards, > > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From marlowsd at gmail.com Mon Feb 1 07:00:26 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Feb 1 06:32:13 2010 Subject: ghc rts selection and third party libraries In-Reply-To: References: Message-ID: <4B66C25A.5040407@gmail.com> On 01/02/2010 05:33, John Lask wrote: > I hope someone can provide some guidance on how I can solve a certain > problem. > > I have a library that taps into the ghc c rts: specifically when the rts > is single threaded I am pumping events in via: stg_pending_events, when > the threaded rts is used I use sendIOManagerEvent. These are RTS internal APIs, and could change under your feet. What is it you're trying to do exactly? > i.e. I have two versions of the library with the same api. The problem > with this is that either library is only good for one context: either > threaded rts or not, and the user needs to select the appropriate > library to use depending on the use context. > > What I want to be able to do is to have ghc automatically select the > compiled library version to link in depending on the which rts option is > selected: "-thread" or not Library code is generally supposed to be independent of -threaded; sometimes we do this by checking at runtime using rtsSupportsBoundThreads(). Cheers, Simon From nhn at Cs.Nott.AC.UK Mon Feb 1 07:52:25 2010 From: nhn at Cs.Nott.AC.UK (Henrik Nilsson) Date: Mon Feb 1 07:26:17 2010 Subject: Quasi quoting In-Reply-To: <4B669285.8040005@cs.nott.ac.uk> References: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> <4B669285.8040005@cs.nott.ac.uk> Message-ID: <4B66CE89.7070302@cs.nott.ac.uk> Dear all, George and I have been discussing this. We very much support the idea of allowing QQ for top-level definitions. Additionally, we think QQ should be allowed for *types*, just like TH, by extending the record of functions in the following way: data QuasiQuoter = QuasiQuoter { quoteExp :: String -> Q Exp quotePat :: String -> Q Pat quoteDec :: String -> Q [Dec] quoteType :: String -> Q Type } We have been discussing the need for this for some time, and if Kathleen hadn't effectively beaten us to it, we'd have made inquiries for the feasibility of such a facility shortly anyway. Additionally, this would make the functionality of TH and QQ more uniform. As to syntax, Both George and I prefer [name| ... |]. Yes, it clashes with list comprehensions, but users who use this facility just have to be aware of that caveat. And, as Simon says, this is already the case for TH. It is true that QQ in some ways is rather different from TH. But, from a user perspective, they're both about *meta programming*, and thus it makes sense to adopt a similar syntax for the two where "name" can be seen as a keyword to specify the kind of meta-programming one is doing. Including the empty string ([|) for the default case, basic TH expressions. Best, George and Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk From jvlask at hotmail.com Mon Feb 1 08:36:41 2010 From: jvlask at hotmail.com (John Lask) Date: Mon Feb 1 08:08:53 2010 Subject: ghc rts selection and third party libraries In-Reply-To: <4B66C25A.5040407@gmail.com> References: <4B66C25A.5040407@gmail.com> Message-ID: I understand these are internals of ghc and subject to change. The reason for their use: to support asynchronous interrupts safe with respect to the Haskell code that is being interrupted. To my knowledge (please correct me if I am wrong) there is no way to do this other than the following alternatives and the already mentioned functions. As an example, suppose I want to provide a call back to a win32 OS hook which takes a c-call-back routine. My understanding is that I cannot use a wrapped Haskell call-back routine as there are no guarantees what state the Haskell rts will be in when the routine is called. At least initially I have used the above mentioned functions to support win32 signal handling, as the ghc rts just catches (and dispatches) console events, which do not encompass all the (rather limited) c-rts signals. The obvious solution is to provide a c call-back routine, use an WIN32 event object, use a Haskell bound thread to wait on that event. another alternative would be to poll. The first alternative requires threaded rts which for various reasons I don't wish to use under all circumstances, the other alternative is inefficient or unresponsive. Discussion of either of these alternatives distract from the question "shouldn't there be a method for asynchronous call-back that is safe with respect to the Haskell rts state"? But there already exists such a method, that of the backdoor already mentioned, really, all that is required is for this to become more formalised and a single api adopted that is usable from c and consistent across threaded and un-threaded rts, but in the mean time the existing structure is quite usable for this purpose aside from the cumbersome libraries issue. And the reason for this libraries issue is that the methods exposed by the ghc-runtime to collect and post events into the ghc runtime system differ between the threaded and non-threaded runtimes, which is why short of changing ghc rts myself I can't avoid it (or adopting either of the above alternatives) As the facility (to capture arbitrary asynchronous interrupts) is generally useful I believe it to be advantageous to address it rather than side-stepping it. > On 01/02/2010 05:33, John Lask wrote: > >> I hope someone can provide some guidance on how I can solve a certain >> problem. >> >> I have a library that taps into the ghc c rts: specifically when the rts >> is single threaded I am pumping events in via: stg_pending_events, when >> the threaded rts is used I use sendIOManagerEvent. > > These are RTS internal APIs, and could change under your feet. What is > it you're trying to do exactly? > >> i.e. I have two versions of the library with the same api. The problem >> with this is that either library is only good for one context: either >> threaded rts or not, and the user needs to select the appropriate >> library to use depending on the use context. >> >> What I want to be able to do is to have ghc automatically select the >> compiled library version to link in depending on the which rts option is >> selected: "-thread" or not > > Library code is generally supposed to be independent of -threaded; > sometimes we do this by checking at runtime using > rtsSupportsBoundThreads(). > > Cheers, > Simon > > From batterseapower at hotmail.com Mon Feb 1 09:25:05 2010 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Mon Feb 1 08:56:40 2010 Subject: Quasi quoting In-Reply-To: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: <9d4d38821002010625p4a3993b9o49b660817ed9bbed@mail.gmail.com> Dominic Orchard and I have come up with a rather radical proposal for a redesign of the syntax. There are two principal options: OPTION 1 (preferred) =============== Advantages: 1) QuasiQuotes are revealed as they really are - as splices. In my opinion this is much less confusing, because a "quasiquote" is really about generating *code*, like a $(), not about generating a *data structure* like the existing [|e|], [t|t|] and [d|d|]. 2) Unifies Template Haskell and QQ into one construct 3) QQ looks like "semantic brackets" 4) No list comprehension ambiguity Disadvantages: 1) Small syntax changes to QQ and TH. Increased verbosity in some common cases. Start with GHC Haskell. Remove [|e|], [t|t|], [d|d|] and [e|..|] syntax. Add this new syntax: Syntax: [|...|] Type: String Translation: "..." (i.e. this is an alternative string literal syntax) Now change the semantics of splice, $(e), like so: ?1) If e :: Q Exp and we are in an Exp context in the code, run the computation and splice the resulting code in ?2) (.. similarly if e :: Q Typ in a Typ context or Q [Decl] in a Decl context. NB: this is what we had to do for TH before anyway) ?3) If e :: QuasiQuote then select the appropriate field from the evaluated "e" based on the context, run the Q computation it contains, and splice the resulting code in Where: data QuasiQuote = QuasiQuote { ? ?quoteExp :: Q Exp ? ?quotePat :: Q Pat ?} Now provide exports from Language.Haskell.TH: e :: String -> Exp t :: String -> Type d :: String -> [Decl] Which parse the provided string as Haskell into the usual data structure. Uses of Template Haskell quotes must be rewritten: [|..|] ==> e [|..|] [t|..|] ==> t [|...|] [d|...|] ==> d [|...|] QuasiQuotes now look like: [foo|...|] ==> $(foo [|...|]) Where foo :: String -> QuasiQuote and defines the language you want to parse. OPTION 2 (not so good) ================= Advantages: 1) Normal Template Haskell use looks almost the same as before 2) QuasiQuotes are revealed as they really are - as splices 3) Unifies [t| ... |], [d| ... |] and QQ into one construct Disadvantages compared to option 1: 1) [| |] is still a special case 3) QQ doesn't look like semantic brackets 4) List comprehension ambiguity remains As GHC Haskell, but with a new interpretation for the QuasiQuote syntax. Syntax: [e1| ... |] Types: if e1 :: String -> a, [e1| ... |] :: a Translation: e1 "..." Preserved TH syntax: [| ... |] Type: [| ... |] :: Exp Translation: ADT representing "..." parsed as a Haskell program Adopt the new semantics of $() exactly as in option 1. Now any existing uses of QQ should be rewritten as: [foo| ... |] ==> $([foo| ... |]) (You could also allow $[foo| ... |] - i.e. you may omit the brackets) In this proposal, you can then export "t" and "d" functions from Language.Haskell.TH with the type: t :: String -> Type d :: String -> [Decl] Which parse the provided string as Haskell. This allows existing any uses of Template Haskell to remain *unchanged* (as long as they imported the TH module :-). Otherwise rewrite them as: [t|..|] ==> Language.Haskell.TH.t [|...|] [d|...|] ==> Language.Haskell.TH.d [|...|] (You could potentially special case these in the compiler to generate the result of the parse at compile time, rather than running the parser at runtime. This means that the staging behaviour of TH quotes can stay unchanged) CONCLUSION =========== At the cost of changing the staging behaviour of [| |], [t| |] and [d| |] (usually, the parsing is done at compile time - in my proposal it is mostly done at runtime) and slightly changing the syntax: ?1) QQ becomes an explicit splice, which is what it should have been in the first place. ?2) QQ is revealed as the combination of two features: a new notation for String literals, and some extra overloading of the $() operator to deal with the QuasiQuote record I rather like this proposal, even though I realise the chances of such a radical option being adopted are rather low. Cheers, Dominic and Max 2010/2/1 Simon Peyton-Jones : > Dear GHC users > > This email is to announce two proposed changes to GHC's quasi-quotation mechanism. ?For all I know, no one is using quasi-quotation (although it's a very cool feature, thanks to Geoff Mainland), but I didn't think I should take it for granted! > > The current spec is here: > ? ? ? ?http://haskell.org/haskellwiki/Quasiquotation > ? ? ? ?http://www.haskell.org/ghc/docs/latest/html/users_guide/template-haskell.html#th-quasiquotation > > A quasi-quote can appear as a (a) expression (b) pattern, and looks like this > ? ? ? ?[$pads| ...blah... |] > > where 'pads' (of course any name will do) is a record of functions > ? data QuasiQuoter = QuasiQuoter { > ? ? quoteExp :: String -> Q Exp > ? ? quotePat :: String -> Q Pat > ? } > > The idea is that GHC evaluates (pads "...blah..."), and splices in the resulting Exp (or Pat) just as if that's what the user wrote in the first place. > > Kathleen Fisher has started to use this for her PADS system, and came up with two suggestions. > > 1. Allow quasi-quotes at the (top-level) declaration level, just like TH splices. So you could say, at top level > ? ? ? ?[$pads| ...blah... |] > and have it expand to a bunch of top level Haskell declarations. This seems like an unconditionally good idea. To support it we'd need to add a field to QuasiQuoter: > ? data QuasiQuoter = QuasiQuoter { > ? ? quoteExp :: String -> Q Exp > ? ? quotePat :: String -> Q Pat > ? ? quoteDec :: String -> Q [Dec] > ? } > but I don't think anyone will lose sleep over that. > > 2. ?Make the notation less noisy for the "customer". ?In particular, that '$' is scary, and redundant to boot. ?She would like to write > ? ? ? ?[pads| ...blah... |] > > I can see the motivation here, but there are two reasons for caution. > > ?(i) The Template Haskell quote forms [t| ... |] and [d| ... |] behave > ? ? ?rather differently. > > ?(ii) If "[pads|" is a lexeme, then some list comprehensions become illegal, such > ? ? ? as ?[x|x<-xs,y<-ys]. ?But note that because of Template Haskell quotations, > ? ? ? a comprehension [t|t<-ts] is already broken, and similarly with 'd', 'e'. > ? ? ? So the proposed change will make things *more* uniform, by grabbing every > ? ? ? "[blah|" as lexeme. > > For me (i) is the main issue. ?The differences are significant. > ?- A TH quote can appear only where an *expression* is expected > ? ?But a quasiquote can be an expression or pattern or (assuming (1)) declaration > > ?- A TH quote has type (Q Typ) or (Q [Dec]) or (Q Exp) > ? ?But a quasiquote is run immediately and spliced in place of the quote > > ?- A TH splice is run during type checking > ? ?But a quasiquote is run during renaming > > Even given all that, I'm strongly inclined to follow Kathleen's suggestion: > ?- The differences are there all right, but in some ways the programmer thinks > ? ?the same way: ?[lang| blah |] switches to language 'lang'. > > ?- Many users will never encounter the issue; they'll just say > ? ? ? ?[pads| blah |] > ? ?to wake up the PADS magic, and be oblivious to Template Haskell quotes > > An alternative would be to have some other cue. Ones I've considered > > ?- $[pads| ...|], but allowing the $ to be omitted on top-level declarations, > ? ?top level, just as it now can for TH splices. > > ?- [pads:| ... |], with the colon distinguishing quasi-quoting from TH. > > My gut feel is to go with [|pads| ... |]. ?Of course this'd be a change from the current syntax, but I think there are few enough users that they'll switch easily enough. > > > Any comments on any of this? > > Simon > > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > From twhitehead at gmail.com Mon Feb 1 09:45:50 2010 From: twhitehead at gmail.com (Tyson Whitehead) Date: Mon Feb 1 09:17:35 2010 Subject: Question regarding combinator call convention In-Reply-To: <4B66BE6C.3010200@gmail.com> References: <201001291602.26275.twhitehead@gmail.com> <4B66BE6C.3010200@gmail.com> Message-ID: <201002010945.56460.twhitehead@gmail.com> On February 1, 2010 06:43:40 Simon Marlow wrote: > That's a very old document and is inaccurate in various ways. The > Commentary is more up to date: > > http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts That's good to know. Thanks for the link. : ) Cheers! -Tyson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100201/8c90fe70/attachment.bin From jeff.polakow at db.com Mon Feb 1 10:06:58 2010 From: jeff.polakow at db.com (Jeff Polakow) Date: Mon Feb 1 09:38:45 2010 Subject: Quasi quoting In-Reply-To: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: Hello, > For all I know, no one is using quasi- > quotation (although it's a very cool feature, thanks to Geoff > Mainland), but I didn't think I should take it for granted! > As a point of reference, we are using quasi-quotation extensively in our machinery for generating Javascript, which we also put on Hackage as the jmacro package. A small syntax change probably wouldn't be a big deal for us. We'll think about the other proposed changes some more and offer some comments if we have anything interesting to say. thanks for the warning, Jeff --- This communication may contain confidential and/or privileged information. If you are not the intended recipient (or have received this communication in error) please notify the sender immediately and destroy this communication. Any unauthorized copying, disclosure or distribution of the material in this communication is strictly forbidden. Deutsche Bank does not render legal or tax advice, and the information contained in this communication should not be regarded as such. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100201/0c49badf/attachment-0001.html From robgreayer at gmail.com Mon Feb 1 12:20:07 2010 From: robgreayer at gmail.com (Robert Greayer) Date: Mon Feb 1 11:51:43 2010 Subject: Quasi quoting In-Reply-To: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: <4ec472cb1002010920x1f889001jfca21fb46fcfe0b0@mail.gmail.com> I like (1) quite a lot. If radical suggestions for QQ noise reduction are being entertained, here's another: quotations of the form [| .... |] (i.e. no 'language' specified) will use an implicit parameter* ('quasi', say) of type QuasiQuoter, if in scope. Otherwise, they will behave as they currently do (TH expression quotation?). Now to awaken the 'pads' magic (or some other magic), you'd do this somewhere: quasi = pads and then all your [| .... |]'s would be pads expressions/patterns/declarations. Rob * - implicit parameters fill me with a nameless dread under normal circumstances. From simonpj at microsoft.com Mon Feb 1 13:49:43 2010 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Feb 1 13:19:13 2010 Subject: Quasi quoting In-Reply-To: <4ec472cb1002010920x1f889001jfca21fb46fcfe0b0@mail.gmail.com> References: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> <4ec472cb1002010920x1f889001jfca21fb46fcfe0b0@mail.gmail.com> Message-ID: <59543203684B2244980D7E4057D5FBC10AFCE28E@DB3EX14MBXC306.europe.corp.microsoft.com> | quotations of the form [| .... |] (i.e. no 'language' specified) will | use an implicit parameter* ('quasi', say) of type QuasiQuoter, if in | scope. Otherwise, they will behave as they currently do (TH | expression quotation?). Now to awaken the 'pads' magic (or some other | magic), you'd do this somewhere: | | quasi = pads Nice idea, but won't work as specified. The thing is that the quasiquoter is run at *compile time*. So it can't be an implicit parameter, which is by definition only available at runtime f :: (?q:QuasiQuoter) => ..blah... A variant of your suggestion would be: for any quote [|..blah..|] behave as if the programmer had written [quasiQuoter| ...blah...|]. That is, simply pick up whatever record named "quasiQuoter" is in scope. Then you'd say import Pads( quasiQuoter ) and away you go. But you can only use one at a time. That might be quite convenient, but alas [|...|] has already been taken by Template Haskell quotes, meaning [e| ...|]. So you'd need something else. [*|...|] perhaps. Or we could switch to different quotation brackets altogether for quasiquotation, the obvious possibility being <|...blah...|>, and . That would not be hard, and would only affect the handful of current quasiquote users. But it'd remove "<|" and "|>" as a valid operators, at least for quasiquote customers. I don't know how bad that would be. Simon From nhn at Cs.Nott.AC.UK Mon Feb 1 14:16:38 2010 From: nhn at Cs.Nott.AC.UK (Henrik Nilsson) Date: Mon Feb 1 13:55:50 2010 Subject: Quasi quoting In-Reply-To: <59543203684B2244980D7E4057D5FBC10AFCE28E@DB3EX14MBXC306.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> <4ec472cb1002010920x1f889001jfca21fb46fcfe0b0@mail.gmail.com> <59543203684B2244980D7E4057D5FBC10AFCE28E@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: <4B672896.4050304@cs.nott.ac.uk> Hi all, Simon wrote (answering Robert Greayer): > A variant of your suggestion would be: for any quote [|..blah..|] > behave as if the programmer had written [quasiQuoter| ...blah...|]. > That is, simply pick up whatever record named "quasiQuoter" is in > scope. Then you'd say > import Pads( quasiQuoter ) > and away you go. But you can only use one at a time. Yes, I can see that (or one of the alternative forms proposed) would sometimes be convenient. But, being explicit about *which* syntax one is switching into does arguably enhance readability. Without this cue, the reader have to hunt for the appropriate binding before he or she can make sense of a piece of quasiquoted text. Also, as Simon suggests, being explicit makes it possible to use more than one quasiquoter at a time (in one module). Potentially quite useful. I can see being explicit about which quasiquoterbeing to use would be a bit of an issue in a setting with lots of very small fragments being spliced in all over the place. But at least in our experience, and what we've seen in Geoffrey's papers, quiasiquoted code fragments tend to be relatively substantial, where naming the quasiquoter doesn't add much overhead at all. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk From robgreayer at gmail.com Mon Feb 1 15:10:25 2010 From: robgreayer at gmail.com (Robert Greayer) Date: Mon Feb 1 14:42:11 2010 Subject: Quasi quoting In-Reply-To: <59543203684B2244980D7E4057D5FBC10AFCE28E@DB3EX14MBXC306.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> <4ec472cb1002010920x1f889001jfca21fb46fcfe0b0@mail.gmail.com> <59543203684B2244980D7E4057D5FBC10AFCE28E@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: <4ec472cb1002011210n47c5964ey877457c8137e54b8@mail.gmail.com> > > A variant of your suggestion would be: for any quote [|..blah..|] behave as if the programmer had written [quasiQuoter| ...blah...|]. That is, simply pick up whatever record named "quasiQuoter" is in scope. Then you'd say > import Pads( quasiQuoter ) > and away you go. But you can only use one at a time. > > That might be quite convenient, but alas [|...|] has already been taken by Template Haskell quotes, meaning [e| ...|]. So you'd need something else. [*|...|] perhaps. > Would it be possible to have [| ... |] mean [quasiQuoter| ... |] iff a 'quasiQuoter' has been imported, but otherwise mean [e| ... |]? Or does the determination to treat [something| .. blah .. |] as a quasi quote need to be made before it is possible to determine if there really is a 'something' available to process the quasi quote? You could also explicitly rely on the presence/absence of the QuasiQuotes and TemplateHaskell language options (iff QQ is on, [| ... |] means [quasiQuoter| ... |], forcing the explicit [e| ... |] for TH expression quotes). Better for one extension to steal syntax from another, perhaps, than stealing it from the base language. As Henrik points out (in his parallel reply) this only really matters if your quasi-quoted strings are quite short. I only recently came up with a use case in which a really terse quasi-quotation would be helpful; heretofore lengthy quotations were all that I had used. Nevertheless, the proposal as it stands would allow me to get away with a quasi-quotation that's only one character less terse than my 'implicit' suggestion would allow. Thanks, Rob From jason.dusek at gmail.com Mon Feb 1 17:46:35 2010 From: jason.dusek at gmail.com (Jason Dusek) Date: Mon Feb 1 17:18:09 2010 Subject: Quasi quoting In-Reply-To: <59543203684B2244980D7E4057D5FBC10AFCE28E@DB3EX14MBXC306.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> <4ec472cb1002010920x1f889001jfca21fb46fcfe0b0@mail.gmail.com> <59543203684B2244980D7E4057D5FBC10AFCE28E@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: <42784f261002011446x78baf66bg504f6759135a7ad3@mail.gmail.com> 2010/02/01 Simon Peyton-Jones : > That might be quite convenient, but alas [|...|] has already > been taken by Template Haskell quotes, meaning [e| ...|]. ?So > you'd need something else. ?[*|...|] ?perhaps. Why is that a problem? Would TH and quasi-quoting be likely to be enabled at the same time? One could decide in favour of QQs if they are enabled (though yes, this is likely horrible on the inside). > Or we could switch to different quotation brackets altogether > for quasiquotation, the obvious possibility being > <|...blah...|>, and . [...] It's true; but I suspect `<|' and `|>' are actually widely used. Wouldn't `(|' and `|)' be safer? In either case, it's easy to see how me evolve an indentational quasi-quote syntax: `[|]' or `(|)'. If the default quasi-quoter is simple string literals, then there's no need for a HEREDOC in the language. -- Jason Dusek From marlowsd at gmail.com Tue Feb 2 04:39:08 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Feb 2 04:10:53 2010 Subject: Quasi quoting In-Reply-To: <9d4d38821002010625p4a3993b9o49b660817ed9bbed@mail.gmail.com> References: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> <9d4d38821002010625p4a3993b9o49b660817ed9bbed@mail.gmail.com> Message-ID: <4B67F2BC.6030309@gmail.com> On 01/02/2010 14:25, Max Bolingbroke wrote: > Dominic Orchard and I have come up with a rather radical proposal for > a redesign of the syntax. There are two principal options: > > OPTION 1 (preferred) > =============== > > Advantages: > 1) QuasiQuotes are revealed as they really are - as splices. In my > opinion this is much less confusing, because a "quasiquote" is really > about generating *code*, like a $(), not about generating a *data > structure* like the existing [|e|], [t|t|] and [d|d|]. > 2) Unifies Template Haskell and QQ into one construct > 3) QQ looks like "semantic brackets" > 4) No list comprehension ambiguity > > Disadvantages: > 1) Small syntax changes to QQ and TH. Increased verbosity in some common cases. > > Start with GHC Haskell. Remove [|e|], [t|t|], [d|d|] and [e|..|] syntax. > > Add this new syntax: > > Syntax: [|...|] > Type: String > Translation: "..." (i.e. this is an alternative string literal syntax) > > Now change the semantics of splice, $(e), like so: > 1) If e :: Q Exp and we are in an Exp context in the code, run the > computation and splice the resulting code in Can you say precisely what it means to be "in an Exp context"? This is a bit like Simon's type-directed name resolution idea, in that it's adding in a bit of ad-hoc overloading. To understand this I think you really need to write down (or at least sketch) the type system that infers the context: e.g. you have to make clear what information is taken into account (type signatures? the results of resolving other overloading opportunities?). > 2) (.. similarly if e :: Q Typ in a Typ context or Q [Decl] in a Decl > context. NB: this is what we had to do for TH before anyway) > 3) If e :: QuasiQuote then select the appropriate field from the > evaluated "e" based on the context, run the Q computation it contains, > and splice the resulting code in > > Where: > > data QuasiQuote = QuasiQuote { > quoteExp :: Q Exp > quotePat :: Q Pat > } > > Now provide exports from Language.Haskell.TH: > > e :: String -> Exp > t :: String -> Type > d :: String -> [Decl] The TH library would have to include a Haskell parser, which presents some engineering difficulties. TH can't be mutually recursive with GHC, so either the haskell-src-exts package has to be used or TH and GHC have to be merged. Cheers, Simon From sebf at informatik.uni-kiel.de Tue Feb 2 06:03:44 2010 From: sebf at informatik.uni-kiel.de (Sebastian Fischer) Date: Tue Feb 2 05:35:23 2010 Subject: Quasi quoting In-Reply-To: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: <6FEC0686-896A-4503-ACE8-D1851BFE255E@informatik.uni-kiel.de> Dear Simon, I want to generate data type declarations using quasi quotes and hence support the proposal to allow quasi quotation at declaration level. With respect to syntax, I'd prefer [|blah| ... |] over the current [$blah| ... |] and would also be fine with [blah| ... |]. What is the reason to restrict quasi quotation to top-level declarations rather than letting it also generate local declarations? Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) From sebf at informatik.uni-kiel.de Tue Feb 2 06:12:45 2010 From: sebf at informatik.uni-kiel.de (Sebastian Fischer) Date: Tue Feb 2 05:44:21 2010 Subject: Quasi quoting In-Reply-To: <42784f261002011446x78baf66bg504f6759135a7ad3@mail.gmail.com> References: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> <4ec472cb1002010920x1f889001jfca21fb46fcfe0b0@mail.gmail.com> <59543203684B2244980D7E4057D5FBC10AFCE28E@DB3EX14MBXC306.europe.corp.microsoft.com> <42784f261002011446x78baf66bg504f6759135a7ad3@mail.gmail.com> Message-ID: On Feb 1, 2010, at 11:46 PM, Jason Dusek wrote: > Wouldn't `(|' and `|)' be safer? I like this suggestion. It avoids conflicts with Template Haskell and list comprehensions. Conor McBride also picked these brackets as idiom brackets in his preprocessor she. [$blah| ... |] could be replaced with (blah| ... |) and (| ... |) could be syntactic sugar for (quote| ... |) and use whatever definition of quote is in scope. Would this introduce severe ambiguities? I can think of (foo||bar) where you need to go to the end to see that it does not end in |). Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) From jao at gnu.org Tue Feb 2 09:51:18 2010 From: jao at gnu.org (Jose A. Ortega Ruiz) Date: Tue Feb 2 09:46:43 2010 Subject: question about hsc2hs Message-ID: <87aavr1yjd.fsf@newton.homeunix.net> Hi. I'm copying below a question i sent to another list about hsc2hs (and for which i got no response), in the hopes that it will be not be OT here. My apologies if it is! I'm trying to write a simple C binding for statfs(2). Simplifying, writing an hsc file that contains the following snippet: #include data CStatfs foreign import ccall unsafe "sys/vfs.h statfs" c_statfs :: CString -> Ptr CStatfs -> IO CInt getFileSystemStats :: String -> IO CLong getFileSystemStats path = allocaBytes (#size struct statfs) $ \vfs -> useAsCString (pack path) $ \cpath -> do res <- c_statfs cpath vfs case res of -1 -> return 0 _ -> do bsize <- (#peek struct statfs, f_bsize) vfs bcount <- (#peek struct statfs, f_blocks) vfs bfree <- (#peek struct statfs, f_bfree) vfs bavail <- (#peek struct statfs, f_bavail) vfs -- Just for demonstration: the original code creates a data structure return $ bsize + bcount + bavail + bfree gives rise, when using hsc2hs, to this translation: getFileSystemStats path = allocaBytes ((84)) $ \vfs -> useAsCString (pack path) $ \cpath -> do res <- c_statfs cpath vfs case res of -1 -> return 0 _ -> do bsize <- ((\hsc_ptr -> peekByteOff hsc_ptr 4)) vfs bcount <- ((\hsc_ptr -> peekByteOff hsc_ptr 8)) vfs bfree <- ((\hsc_ptr -> peekByteOff hsc_ptr 16)) vfs bavail <- ((\hsc_ptr -> peekByteOff hsc_ptr 24)) vfs return $ bsize + bcount + bavail + bfree (where i have deleted LINE directives). The problem is that the size and some of the offsets of the C struct statfs computed by hsc2c are wrong: i'm in a 32bit linux system, and i've checked, using a C program, that sizeof(struct statfs) is 64 (hsc2 is giving 84 -- although perhaps Haskell needs additional space for housekeeping?), and that the offsets of f_bfree and f_bavail are, respectively, 12 and 16 (not 16 and 24). Also, i know that 12 and 16 are the right values because putting them by hand gives me the correct statfs values. (This is ghc 6.10.4 on a debian/sid system) What am i doing wrong? TIA! jao -- It is hard enough to remember my opinions, without also remembering my reasons for them. -Friedrich Wilhelm Nietzsche, philosopher (1844-1900) From batterseapower at hotmail.com Tue Feb 2 10:40:57 2010 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Tue Feb 2 10:12:29 2010 Subject: Quasi quoting In-Reply-To: <4B67F2BC.6030309@gmail.com> References: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> <9d4d38821002010625p4a3993b9o49b660817ed9bbed@mail.gmail.com> <4B67F2BC.6030309@gmail.com> Message-ID: <9d4d38821002020740v6fc163edhd26a64ced8199501@mail.gmail.com> (Sorry if you see this twice, Simon - I didn't reply to the list) 2010/2/2 Simon Marlow : > Can you say precisely what it means to be "in an Exp context"? In a Type context == a HsSpliceTy constructor in the existing GHC AST In an Exp context == a HsSpliceE constructor in the existing GHC AST In a Decl context == a SpliceD constructor in the existing GHC AST >?This is a > bit like Simon's type-directed name resolution idea, in that it's adding in > a bit of ad-hoc overloading. I don't think so - it's much easier to deal with than that. What sort of context the splice is in is purely syntactic, and we already have to work it out to implement the existing Template Haskell semantics. Our proposal does not complicate this at all. > The TH library would have to include a Haskell parser, which presents some > engineering difficulties. ?TH can't be mutually recursive with GHC, so > either the haskell-src-exts package has to be used or TH and GHC have to be > merged. This is a real issue. Using src-exts would be a good fix, especially because it would mean that the numerous tools and libraries that already use the src-exts data structure could be reused in your TH programs. Unfortunately it would either: a) Have to be a boot package, so that GHC can translate the spliced Exp or whatever into GHC's HsExpr b) Or we could let $() accept a HsExpr (exported by the GHC package). Users can then use src-exts as a non-boot package, along with another non-boot package similar to src-exts-meta (see Hackage) which translates src-exts types into the GHC ones for the splice. This would let us delete a lot of code from GHC (DsMeta, Covert..). It's a big change though, and I'm not sure how I feel about it. Cheers, Max From ross at soi.city.ac.uk Tue Feb 2 11:13:19 2010 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Feb 2 10:45:20 2010 Subject: question about hsc2hs In-Reply-To: <87aavr1yjd.fsf@newton.homeunix.net> References: <87aavr1yjd.fsf@newton.homeunix.net> Message-ID: <20100202161319.GA13861@soi.city.ac.uk> On Tue, Feb 02, 2010 at 03:51:18PM +0100, Jose A. Ortega Ruiz wrote: > [...] The problem is that the size and > some of the offsets of the C struct statfs computed by hsc2c are wrong: > i'm in a 32bit linux system, and i've checked, using a C program, that > sizeof(struct statfs) is 64 (hsc2 is giving 84 -- although perhaps > Haskell needs additional space for housekeeping?), and that the offsets > of f_bfree and f_bavail are, respectively, 12 and 16 (not 16 and 24). > Also, i know that 12 and 16 are the right values because putting them by > hand gives me the correct statfs values. If you compile your C program with -D_FILE_OFFSET_BITS=64 you'll get the same numbers that hsc2hs does. From marlowsd at gmail.com Tue Feb 2 11:14:49 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Feb 2 10:46:35 2010 Subject: Quasi quoting In-Reply-To: <9d4d38821002020740v6fc163edhd26a64ced8199501@mail.gmail.com> References: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> <9d4d38821002010625p4a3993b9o49b660817ed9bbed@mail.gmail.com> <4B67F2BC.6030309@gmail.com> <9d4d38821002020740v6fc163edhd26a64ced8199501@mail.gmail.com> Message-ID: <4B684F79.3080008@gmail.com> On 02/02/2010 15:40, Max Bolingbroke wrote: > (Sorry if you see this twice, Simon - I didn't reply to the list) > > 2010/2/2 Simon Marlow: >> Can you say precisely what it means to be "in an Exp context"? > > In a Type context == a HsSpliceTy constructor in the existing GHC AST > In an Exp context == a HsSpliceE constructor in the existing GHC AST > In a Decl context == a SpliceD constructor in the existing GHC AST Ah ok, that's fine then. Cheers, Simon From ml at isaac.cedarswampstudios.org Tue Feb 2 11:18:42 2010 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Tue Feb 2 10:50:39 2010 Subject: Quasi quoting In-Reply-To: <9d4d38821002010625p4a3993b9o49b660817ed9bbed@mail.gmail.com> References: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> <9d4d38821002010625p4a3993b9o49b660817ed9bbed@mail.gmail.com> Message-ID: <4B685062.3060704@isaac.cedarswampstudios.org> Max Bolingbroke wrote: > ... > In this proposal, you can then export "t" and "d" functions from > Language.Haskell.TH with the type: > > t :: String -> Type > d :: String -> [Decl] > > Which parse the provided string as Haskell. This allows existing any > uses of Template Haskell to remain *unchanged* (as long as they > imported the TH module :-). Otherwise rewrite them as: > > [t|..|] ==> Language.Haskell.TH.t [|...|] I'm concerned in both your proposals, that single-letter names like "t" and "d" are common function parameters, thus possibly producing - shadowing warnings for all such functions in modules that happen to use TH - errors, I think, for some uses of TH inside such functions (either the function parameters must be renamed, or the TH splice module-qualified) -Isaac From batterseapower at hotmail.com Tue Feb 2 11:25:36 2010 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Tue Feb 2 10:57:10 2010 Subject: Quasi quoting In-Reply-To: <4B685062.3060704@isaac.cedarswampstudios.org> References: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> <9d4d38821002010625p4a3993b9o49b660817ed9bbed@mail.gmail.com> <4B685062.3060704@isaac.cedarswampstudios.org> Message-ID: <9d4d38821002020825y3a2d6248ga5833db8edcfeae3@mail.gmail.com> 2010/2/2 Isaac Dupree : > I'm concerned in both your proposals, that single-letter names like "t" and > "d" are common function parameters, thus possibly producing > - shadowing warnings for all such functions in modules that happen to use TH > - errors, I think, for some uses of TH inside such functions (either the > function parameters must be renamed, or the TH splice module-qualified) Yes, this is certainly an annoyance :-). However, we didn't have backcompat high up the list of priorities with these proposals - instead we wanted to look at how TH and QQ might be redesigned to work together a bit more neatly if we were starting with a clean slate today. You can of course choose more expressive names than "e" and "t" if you're going to break backcompat anyway, Cheers, Max From bulat.ziganshin at gmail.com Tue Feb 2 12:21:25 2010 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Feb 2 11:53:30 2010 Subject: Quasi quoting In-Reply-To: <9d4d38821002020825y3a2d6248ga5833db8edcfeae3@mail.gmail.com> References: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> <9d4d38821002010625p4a3993b9o49b660817ed9bbed@mail.gmail.com> <4B685062.3060704@isaac.cedarswampstudios.org> <9d4d38821002020825y3a2d6248ga5833db8edcfeae3@mail.gmail.com> Message-ID: <1776091510.20100202202125@gmail.com> Hello Max, Tuesday, February 2, 2010, 7:25:36 PM, you wrote: > You can of course choose more expressive names than "e" and "t" if > you're going to break backcompat anyway, i propose x and xs :D -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jao at gnu.org Tue Feb 2 12:24:38 2010 From: jao at gnu.org (Jose A. Ortega Ruiz) Date: Tue Feb 2 14:40:05 2010 Subject: question about hsc2hs References: <87aavr1yjd.fsf@newton.homeunix.net> <20100202161319.GA13861@soi.city.ac.uk> Message-ID: <87ock7zh2h.fsf@newton.homeunix.net> Ross Paterson writes: > On Tue, Feb 02, 2010 at 03:51:18PM +0100, Jose A. Ortega Ruiz wrote: >> [...] The problem is that the size and >> some of the offsets of the C struct statfs computed by hsc2c are wrong: >> i'm in a 32bit linux system, and i've checked, using a C program, that >> sizeof(struct statfs) is 64 (hsc2 is giving 84 -- although perhaps >> Haskell needs additional space for housekeeping?), and that the offsets >> of f_bfree and f_bavail are, respectively, 12 and 16 (not 16 and 24). >> Also, i know that 12 and 16 are the right values because putting them by >> hand gives me the correct statfs values. > > If you compile your C program with -D_FILE_OFFSET_BITS=64 you'll get the > same numbers that hsc2hs does. But when i use those offsets (16, 24) in my Haskell program (generated by hsc2hs), i get the wrong values when i inspect the struct filled by statfs() (via the call performed by Haskell's FFI), while if i put (by hand this time) the ones (12, 16) given by the C program without _FILE_OFFSET_BITS defined, the results are correct. So it looks like the C library, or the generated code, is not using that value for _FILE_OFFSET_BITS. Do i need to compile my Haskell code using a similar flag? (Sorry if i'm missing something obvious.) Thanks! jao From twanvl at gmail.com Tue Feb 2 17:21:21 2010 From: twanvl at gmail.com (Twan van Laarhoven) Date: Tue Feb 2 16:53:17 2010 Subject: Quasi quoting In-Reply-To: <9d4d38821002020825y3a2d6248ga5833db8edcfeae3@mail.gmail.com> References: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> <9d4d38821002010625p4a3993b9o49b660817ed9bbed@mail.gmail.com> <4B685062.3060704@isaac.cedarswampstudios.org> <9d4d38821002020825y3a2d6248ga5833db8edcfeae3@mail.gmail.com> Message-ID: <4B68A561.2010001@gmail.com> Max Bolingbroke wrote: > 2010/2/2 Isaac Dupree : >> I'm concerned in both your proposals, that single-letter names like "t" and >> "d" are common function parameters, thus possibly producing >> - shadowing warnings for all such functions in modules that happen to use TH >> - errors, I think, for some uses of TH inside such functions (either the >> function parameters must be renamed, or the TH splice module-qualified) > > Yes, this is certainly an annoyance :-). However, we didn't have > backcompat high up the list of priorities with these proposals - > instead we wanted to look at how TH and QQ might be redesigned to work > together a bit more neatly if we were starting with a clean slate > today. > > You can of course choose more expressive names than "e" and "t" if > you're going to break backcompat anyway, You could also do away with these names entirely, and use magic instead: instance IsString HsExpr where fromString = e Or perhaps a different typeclass for [|...|] blocks, class Quoted a where parseQuote :: String -> a -- for performance reasons: parseQuote' :: Ghc.PackedString -> a This also leaves the door open for constructions like: instance Quoted QuasiQuote where parseQuote xs = let (f,x) = splitAt '|' xs in (findParserByName f) x f = $[|foo| ... |] -- we still have to register foo somehow Twan From batterseapower at hotmail.com Tue Feb 2 19:48:27 2010 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Tue Feb 2 19:19:58 2010 Subject: Quasi quoting In-Reply-To: <4B68A561.2010001@gmail.com> References: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> <9d4d38821002010625p4a3993b9o49b660817ed9bbed@mail.gmail.com> <4B685062.3060704@isaac.cedarswampstudios.org> <9d4d38821002020825y3a2d6248ga5833db8edcfeae3@mail.gmail.com> <4B68A561.2010001@gmail.com> Message-ID: <9d4d38821002021648sf90e777vcb0decef36f61eda@mail.gmail.com> 2010/2/2 Twan van Laarhoven : > ? ?class Quoted a where > ? ? ? ?parseQuote :: String -> a > ? ? ? ?-- for performance reasons: > ? ? ? ?parseQuote' :: Ghc.PackedString -> a Great idea! Thinking about it, you can use type classes to dispose of the QuasiQuote record entirely. Instead, have: class MyLang a where myLang :: String -> Q a instance MyLang Exp where myLang = myLangSyntaxToGHCExprForSplice . myLangExpParser ... etc, MyLang instances for Pat and Type too ... And then write: $(myLang [|...|]) Now the splice $(e) typechecks e as a Q Type / Q Exp / Q Decl as required by the context it is in, and hence gets the correct instance of MyLang. So our proposal needn't change the semantics of splice at all - we can reuse the name overloading abilities of type classes. It's a shame that TH is too widely used to be amenable to refactoring into this sort of form. Cheers, Max From dan.doel at gmail.com Tue Feb 2 22:07:34 2010 From: dan.doel at gmail.com (Dan Doel) Date: Tue Feb 2 21:39:09 2010 Subject: Overlapping Instances + Existentials = Incoherent Instances Message-ID: <201002022207.34970.dan.doel@gmail.com> Greetings, I've actually known about this for a while, but while discussing it, it occurred to me that perhaps it's something I should report to the proper authorities, as I've never seen a discussion of it. But, I thought I'd start here rather than file a bug, since I'm not sure it isn't intended. Anyhow, here's the example: class C a where foo :: a -> String instance C a where foo _ = "universal" instance C Int where foo _ = "Int" bar :: a -> String bar x = foo x Now, normally bar generates a complaint, but if you enable IncoherentInstances, it's accepted, and it always generates "universal", even if called with an Int. Adding a 'C a' constraint to the type makes it give "Int" in the case of an Int. Now, IncoherentInstances is something most people would suggest you don't use (even people who are cool with OverlappingInstances). However, it turns out that ExistentialQuantification does the same thing, because we can write: data Ex = forall a. Ex a baz :: a -> String baz x = case Ex x of Ex x' -> foo x' and this is accepted, and always yields "universal", just like bar. So, things that you get out of an existential are allowed to make use of the general versions of overlapping instances if any fit. So, I never really regarded this as anything more than an oddity that's unlikely to come up. And it might be working as intended. But I thought perhaps I should ask: is this intended? One could probably build a case that baz should only be accepted if IncoherentInstances are enabled, since it's doing about the same thing. I'm not really sure how far back this behavior goes. I've probably known about it for several 6.X releases without mentioning it except as a fun party fact (apologies). Is this the way things are supposed to work? (And sorry if I just missed the discussion somewhere. I searched the trac and didn't see anything very promising.) Cheers, -- Dan From sebf at informatik.uni-kiel.de Wed Feb 3 09:07:52 2010 From: sebf at informatik.uni-kiel.de (Sebastian Fischer) Date: Wed Feb 3 08:39:21 2010 Subject: Quasi quoting In-Reply-To: <9d4d38821002021648sf90e777vcb0decef36f61eda@mail.gmail.com> References: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> <9d4d38821002010625p4a3993b9o49b660817ed9bbed@mail.gmail.com> <4B685062.3060704@isaac.cedarswampstudios.org> <9d4d38821002020825y3a2d6248ga5833db8edcfeae3@mail.gmail.com> <4B68A561.2010001@gmail.com> <9d4d38821002021648sf90e777vcb0decef36f61eda@mail.gmail.com> Message-ID: <08B627F6-C768-41F2-8822-261B0B454993@informatik.uni-kiel.de> On Feb 3, 2010, at 1:48 AM, Max Bolingbroke wrote: > 2010/2/2 Twan van Laarhoven : >> class Quoted a where >> parseQuote :: String -> a >> -- for performance reasons: >> parseQuote' :: Ghc.PackedString -> a > > Great idea! > > Thinking about it, you can use type classes to dispose of the > QuasiQuote record entirely. Instead, have: > > class MyLang a where > myLang :: String -> Q a > > instance MyLang Exp where > myLang = myLangSyntaxToGHCExprForSplice . myLangExpParser > > ... etc, MyLang instances for Pat and Type too ... With a class-based approach only one parser that creates values of the same type could be used in a program. It would not be possible to embed multiple languages that create TH.Exp to be spliced into a single program. With the current syntax, I can write [$myLang| ... |] and [$yourLang| ... |] in the same program and use different parsers although both create Exp values. > And then write: > > $(myLang [|...|]) This is more verbose than the proposed [myLang| ... |]. There seem to be different goals in the different proposals in this thread: 1. Simplify the syntax for quasi quoting (remove $, use different brackets), 2. make it more generally applicable (allow declarations and/or types to be quasi quoted), and 3. simplify and generalise its implementation (invent a single mechanism that unifies quasi quoting and TH splicing). Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) From twhitehead at gmail.com Wed Feb 3 09:20:33 2010 From: twhitehead at gmail.com (Tyson Whitehead) Date: Wed Feb 3 08:52:14 2010 Subject: Quasi quoting In-Reply-To: <9d4d38821002021648sf90e777vcb0decef36f61eda@mail.gmail.com> References: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> <4B68A561.2010001@gmail.com> <9d4d38821002021648sf90e777vcb0decef36f61eda@mail.gmail.com> Message-ID: <201002030920.39864.twhitehead@gmail.com> On February 2, 2010 19:48:27 Max Bolingbroke wrote: > It's a shame that TH is too widely used to be amenable to refactoring > into this sort of form. I thought the standard thing to do in this case was to add either a pragma that gives you the new behaviour or trigger it with an alternative syntax (such as the aforementioned (|...|)). Throw in a warning whenever the old is used, and then, after a couple of years/releases, you can depreciate support for it guilt free. : ) Cheers! -Tyson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100203/9f1ee2c7/attachment.bin From simonpj at microsoft.com Wed Feb 3 10:39:36 2010 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Feb 3 10:09:36 2010 Subject: Quasi quoting In-Reply-To: <20100202183743.DD0D16017991C@labrador.cs.tufts.edu> References: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> <4ec472cb1002010920x1f889001jfca21fb46fcfe0b0@mail.gmail.com> <59543203684B2244980D7E4057D5FBC10AFCE28E@DB3EX14MBXC306.europe.corp.microsoft.com> (sfid-H-20100201-215602-+65.00-1@multi.osbf.lua) <20100202183743.DD0D16017991C@labrador.cs.tufts.edu> Message-ID: <59543203684B2244980D7E4057D5FBC10AFCF52A@DB3EX14MBXC306.europe.corp.microsoft.com> | > Or we could switch to different quotation brackets altogether for | > quasiquotation, the obvious possibility being <|...blah...|>, and | > . That would not be hard, and would only affect the | > handful of current quasiquote users. But it'd remove "<|" and "|>" as a | > valid operators, at least for quasiquote customers. I don't know how bad | > that would be. | | Good brackets are scarce. I'd prefer to stick with one of the many | fine variations on [|...|] currently being discussed. I agree with this. My gut feel is to stick with [| ..|] and variants, and live with the fact that TH and QQ aren't using them in quite the same way. S From mechvel at botik.ru Wed Feb 3 10:44:31 2010 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Wed Feb 3 10:18:47 2010 Subject: profiling,-O in 6.12.1 Message-ID: <20100203154431.GA28848@scico.botik.ru> Dear GHC team, It looks like ghc-6.12.1 reports erroneous time profiling -- when the Main module of the project is made under -O. This is for ghc-6.12.1 made from source for Debian Linux and i386-like. Main.main calls for Complete.complete, `complete' calls for eLoop inside its source. eLoop must take almost all the time. My whole user library is made under -O -prof, and --enable-library-profiling. Main is compiled by ghc $dmCpOpt -prof --make Main and run by ./Main +RTS -M400m -pT -RTS For this key, the profiling report Main.prof looks natural and shows eLoop -- 97%. But for ghc $dmCpOpt -O -prof --make Make, it shows a different thing: zero for eLoop and 99% for `main'. How could this additional -O mislead the compiler? Also, as I recall, -O is still by default -- ? Could you explain, please? Regards, ----------------- Serge Mechveliani mechvel@botik.ru From nhn at Cs.Nott.AC.UK Wed Feb 3 11:02:08 2010 From: nhn at Cs.Nott.AC.UK (Henrik Nilsson) Date: Wed Feb 3 10:49:01 2010 Subject: Quasi quoting In-Reply-To: <59543203684B2244980D7E4057D5FBC10AFCF52A@DB3EX14MBXC306.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> <4ec472cb1002010920x1f889001jfca21fb46fcfe0b0@mail.gmail.com> <59543203684B2244980D7E4057D5FBC10AFCE28E@DB3EX14MBXC306.europe.corp.microsoft.com> (sfid-H-20100201-215602-+65.00-1@multi.osbf.lua) <20100202183743.DD0D16017991C@labrador.cs.tufts.edu> <59543203684B2244980D7E4057D5FBC10AFCF52A@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: <4B699E00.9040409@cs.nott.ac.uk> > | > But it'd remove "<|" and "|>" as a > | > valid operators, at least for quasiquote customers. I don't know > | > how bad that would be. > | > | Good brackets are scarce. I'd prefer to stick with one of the many > | fine variations on [|...|] currently being discussed. > > I agree with this. My gut feel is to stick with [| ..|] and variants, > and live with the fact that TH and QQ aren't using them in quite the > same way. Seconded. Removing "<|" and "|>" as valid operators is potentially quite bad, in my opinion worse than the interference with the list comprehensions for "quasiquote customers", because the operators may come from various external libraries that one really would like to use. The list comprehension interference is strictly confined to modules where quasiquoting is enabled. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk From stefan at cs.uu.nl Wed Feb 3 11:34:27 2010 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Wed Feb 3 11:05:56 2010 Subject: Overlapping Instances + Existentials = Incoherent Instances In-Reply-To: <201002022207.34970.dan.doel@gmail.com> References: <201002022207.34970.dan.doel@gmail.com> Message-ID: <587D36DD-A1E5-4BF5-996C-15EBA465EA41@cs.uu.nl> Dan, > class C a where > foo :: a -> String > > instance C a where > foo _ = "universal" > > instance C Int where > foo _ = "Int" [...] > Now, IncoherentInstances is something most people would suggest you > don't use > (even people who are cool with OverlappingInstances). However, it > turns out > that ExistentialQuantification does the same thing, because we can > write: > > data Ex = forall a. Ex a > > baz :: a -> String > baz x = case Ex x of > Ex x' -> foo x' > > and this is accepted, and always yields "universal", just like bar. > So, things > that you get out of an existential are allowed to make use of the > general > versions of overlapping instances if any fit. I don't think it's the same thing. The whole point of the existential is that at the creation site of any value of type Ex the type of the value being packaged is hidden. At the use site, therefore, the only suitable instance is the one for C a. In particular, there is no way for the baz to tell whether an Int is wrapped in the existential. However, if we pack a dictionary along, as in data Ex = forall a. C a => Ex a then, you'll find that baz will pick the dictionary supplied with the existential package rather than the one from the general instance. Cheers, Stefan From daniel.is.fischer at web.de Wed Feb 3 11:38:36 2010 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Wed Feb 3 11:11:55 2010 Subject: profiling,-O in 6.12.1 In-Reply-To: <20100203154431.GA28848@scico.botik.ru> References: <20100203154431.GA28848@scico.botik.ru> Message-ID: <201002031738.36212.daniel.is.fischer@web.de> Am Mittwoch 03 Februar 2010 16:44:31 schrieb Serge D. Mechveliani: > Dear GHC team, > > It looks like ghc-6.12.1 reports erroneous time profiling -- > when the Main module of the project is made under -O. > > This is for ghc-6.12.1 made from source for Debian Linux and > i386-like. > > Main.main calls for Complete.complete, `complete' calls for > eLoop inside its source. > eLoop must take almost all the time. > My whole user library is made under -O -prof, and > --enable-library-profiling. > Main is compiled by > ghc $dmCpOpt -prof --make Main > and run by ./Main +RTS -M400m -pT -RTS > For this key, the profiling report Main.prof looks natural and shows > eLoop -- 97%. > > But for ghc $dmCpOpt -O -prof --make Make, > > it shows a different thing: zero for eLoop and 99% for `main'. Could be that eLoop is inlined with -O. Try ghc $dmCpOpt -O -prof -auto-all --make That should show eLoop (if that's a top-level declaration, otherwise you'd have to insert a pragma {-# SCC "eLoop" #-} manually). > > How could this additional -O mislead the compiler? > Also, as I recall, -O is still by default -- ? No, default is "comile as fast as possible", no optimisations (-O0). > > Could you explain, please? > > Regards, > > ----------------- > Serge Mechveliani > mechvel@botik.ru From dan.doel at gmail.com Wed Feb 3 12:11:36 2010 From: dan.doel at gmail.com (Dan Doel) Date: Wed Feb 3 11:43:21 2010 Subject: Overlapping Instances + Existentials = Incoherent Instances In-Reply-To: <587D36DD-A1E5-4BF5-996C-15EBA465EA41@cs.uu.nl> References: <201002022207.34970.dan.doel@gmail.com> <587D36DD-A1E5-4BF5-996C-15EBA465EA41@cs.uu.nl> Message-ID: <201002031211.36357.dan.doel@gmail.com> On Wednesday 03 February 2010 11:34:27 am Stefan Holdermans wrote: > I don't think it's the same thing. The whole point of the existential > is that at the creation site of any value of type Ex the type of the > value being packaged is hidden. At the use site, therefore, the only > suitable instance is the one for C a. In particular, there is no way > for the baz to tell whether an Int is wrapped in the existential. > > However, if we pack a dictionary along, as in > > data Ex = forall a. C a => Ex a > > then, you'll find that baz will pick the dictionary supplied with the > existential package rather than the one from the general instance. This is (I think) exactly the behavior that IncoherentInstances enables, though, except for universal quantification. If our function has the type: forall a. a -> String then the only instance that can be picked for the parameter is the C a instance, because the function knows nothing about a; a is hidden from the function's perspective, rather from a global perspective, but the function is the one picking the instance to use, since it isn't given one. If instead we pass the dictionary explicitly: forall a. C a => a -> String the function uses that dictionary. In fact, if existentials were first class, we could directly write some isomorphic types that show the analogy: forall a. a -> String ~= (exists a. a) -> String forall a. C a => a -> String ~= (exists a. C a => a) -> String The bottom two naturally work, because we're passing the dictionary. On the top, the existential version works, but the universal version doesn't, unless we enable an extra extension. As a final data point, one can encode existential types via their universal eliminators: type Ex' = forall r. (forall a. a -> r) -> r hide :: forall a. a -> Ex' hide x k = k x open :: (forall a. a -> r) -> Ex' -> r open f ex = ex f Now we can try to write the unconstrained function: quux :: a -> String quux x = open foo (hide x) But, this gives an error telling us that we need IncoherentInstances. -- Dan From batterseapower at hotmail.com Wed Feb 3 12:13:03 2010 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Wed Feb 3 11:44:40 2010 Subject: Quasi quoting In-Reply-To: <08B627F6-C768-41F2-8822-261B0B454993@informatik.uni-kiel.de> References: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> <9d4d38821002010625p4a3993b9o49b660817ed9bbed@mail.gmail.com> <4B685062.3060704@isaac.cedarswampstudios.org> <9d4d38821002020825y3a2d6248ga5833db8edcfeae3@mail.gmail.com> <4B68A561.2010001@gmail.com> <9d4d38821002021648sf90e777vcb0decef36f61eda@mail.gmail.com> <08B627F6-C768-41F2-8822-261B0B454993@informatik.uni-kiel.de> Message-ID: <9d4d38821002030913t3a6ab827x35f19001b0bdfa81@mail.gmail.com> On 3 February 2010 14:07, Sebastian Fischer wrote: > With a class-based approach only one parser that creates values of the same > type could be used in a program. It would not be possible to embed multiple > languages that create TH.Exp to be spliced into a single program. With the > current syntax, I can write [$myLang| ... |] and [$yourLang| ... |] in the > same program and use different parsers although both create Exp values. This is not the case, because you still have an instance "Quoted String". Then you can write: $(myLang [|..|]) Where myLang :: String -> Q Exp The "Quoted Exp" instance you have in scope just determines what default semantics for $([|...|]) you get! So you can use this behaviour to change the default "language" from Haskell to whatever you like, but importing a My.Lang.Module rather than Language.Haskell.TH. This is a bit ugly though, and is more of an unintentional feature than something I was designing for :-) > This is more verbose than the proposed [myLang| ... |]. There seem to be > different goals in the different proposals in this thread: 1. Simplify the > syntax for quasi quoting (remove $, use different brackets), 2. make it more > generally applicable (allow declarations and/or types to be quasi quoted), > and 3. simplify and generalise its implementation (invent a single mechanism > that unifies quasi quoting and TH splicing). Yes - I should have made it clearer that our proposal had strayed rather far from the original goal of reducing verbosity :-). Instead it increases it in the QQ case - but in (IMHO) a good way. Cheers, Max From felipe.lessa at gmail.com Wed Feb 3 12:28:55 2010 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Wed Feb 3 12:00:41 2010 Subject: DPH and CUDA status Message-ID: <20100203172855.GA18087@kira.casa> Hello, Recently I tried to look for the status of Data Parallel Haskell with a CUDA backend. I've found [1] which mentions [2] saying that this is difficult and work was being done. That was almost two years ago. Was any progress made since then or is the work stalled? About GSoC, I wonder if there is any part of the ticket that can be done in a summer's worth of time? Thanks, guys! :) [1] http://hackage.haskell.org/trac/summer-of-code/ticket/1537 [2] http://article.gmane.org/gmane.comp.lang.haskell.cafe/37538 -- Felipe. From jeff at renci.org Wed Feb 3 12:34:39 2010 From: jeff at renci.org (Jeff Heard) Date: Wed Feb 3 12:06:28 2010 Subject: DPH and CUDA status In-Reply-To: <20100203172855.GA18087@kira.casa> References: <20100203172855.GA18087@kira.casa> Message-ID: <4165d3a71002030934o6b5d7e74kc4deacb50a878ad9@mail.gmail.com> IIRC, there has been woirk done by Manuel and his team. I'm sure he'll chime in on that. One thing though, is that CUDA is being supplanted by OpenCL in the next few years, and OpenCL can handle data parallelism on multicore CPUs as well as GPUs with the same code. It's a little more flexible overall than CUDA, and will be portable across ATI/nVidia/Intell/AMD/Sony Cell in the end, and is well supported on Linux, Mac, and Windows systems. There are two Haskell bindings right now for OpenCL, mine which is OpenCLRaw, and one that you can find IIRC on Google Code if you search for Haskell and OpenCL in the same search string. I would love to see a DPH backend in OpenCL, or failing that, something like GPipe but for computational kernels instead of graphics done in OpenCL. -- Jeff On Wed, Feb 3, 2010 at 12:28 PM, Felipe Lessa wrote: > Hello, > > Recently I tried to look for the status of Data Parallel Haskell > with a CUDA backend. ?I've found [1] which mentions [2] saying > that this is difficult and work was being done. ?That was almost > two years ago. ?Was any progress made since then or is the work > stalled? > > About GSoC, I wonder if there is any part of the ticket that can > be done in a summer's worth of time? > > Thanks, guys! :) > > [1] http://hackage.haskell.org/trac/summer-of-code/ticket/1537 > [2] http://article.gmane.org/gmane.comp.lang.haskell.cafe/37538 > > -- > Felipe. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From donnie at darthik.com Wed Feb 3 12:37:09 2010 From: donnie at darthik.com (Donnie Jones) Date: Wed Feb 3 12:08:39 2010 Subject: DPH and CUDA status In-Reply-To: <20100203172855.GA18087@kira.casa> References: <20100203172855.GA18087@kira.casa> Message-ID: Hello Felipe, I copied this email to Sean Lee & Manuel M T Chakravarty as they worked on Haskell+CUDA, maybe they can comment on the current status? Here's their paper... GPU Kernels as Data-Parallel Array Computations in Haskell http://www.cse.unsw.edu.au/~chak/papers/gpugen.pdf Hope that helps. -- Donnie On Wed, Feb 3, 2010 at 11:28 AM, Felipe Lessa wrote: > Hello, > > Recently I tried to look for the status of Data Parallel Haskell > with a CUDA backend. ?I've found [1] which mentions [2] saying > that this is difficult and work was being done. ?That was almost > two years ago. ?Was any progress made since then or is the work > stalled? > > About GSoC, I wonder if there is any part of the ticket that can > be done in a summer's worth of time? > > Thanks, guys! :) > > [1] http://hackage.haskell.org/trac/summer-of-code/ticket/1537 > [2] http://article.gmane.org/gmane.comp.lang.haskell.cafe/37538 > > -- > Felipe. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From mechvel at botik.ru Wed Feb 3 12:59:01 2010 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Wed Feb 3 12:33:14 2010 Subject: profiling,-O in 6.12.1 In-Reply-To: <201002031738.36212.daniel.is.fischer@web.de> References: <20100203154431.GA28848@scico.botik.ru> <201002031738.36212.daniel.is.fischer@web.de> Message-ID: <20100203175901.GA29456@scico.botik.ru> To my > > Dear GHC team, > > > > It looks like ghc-6.12.1 reports erroneous time profiling -- > > when the Main module of the project is made under -O. > > [..] > > This is for ghc-6.12.1 made from source for Debian Linux and > > i386-like. > > > > Main.main calls for Complete.complete, `complete' calls for > > eLoop inside its source. > > eLoop must take almost all the time. > > My whole user library is made under -O -prof, and > > --enable-library-profiling. > > Main is compiled by > > ghc $dmCpOpt -prof --make Main > > and run by ./Main +RTS -M400m -pT -RTS > > For this key, the profiling report Main.prof looks natural and shows > > eLoop -- 97%. > > > > But for ghc $dmCpOpt -O -prof --make Make, > > > > it shows a different thing: zero for eLoop and 99% for `main'. > On Wed, Feb 03, 2010 at 05:38:36PM +0100, Daniel Fischer wrote: > Could be that eLoop is inlined with -O. Thank you. I also thought about this. But the question still looks difficult. > Try > > ghc $dmCpOpt -O -prof -auto-all --make > > That should show eLoop (if that's a top-level declaration, otherwise you'd > have to insert a pragma {-# SCC "eLoop" #-} manually). > eLoop is not a top-level declaration, and I do set {-# SCC "eLoop" #-}. The key combination ghc $dmCpOpt -prof --make Main shows 95% for eLoop, and adding -O to this line shows 0% for eLoop, independently on presence of -auto-all in this line (the whole library is made under -O -prof). Yes, I recall that the effect may be of inlining. But, generally, how to detect sensibly the time consuming functions? This inlining presents a puzzle here. Is it possible to compile Main.hs and Complete.hs under -O0 -inline-not, compile all the other modules under -O ? (how?). If it is possible, will this make easier to understand the profiling report? Regards, ----------------- Serge Mechveliani mechvel@botik.ru From daniel.is.fischer at web.de Wed Feb 3 13:40:10 2010 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Wed Feb 3 13:13:30 2010 Subject: profiling,-O in 6.12.1 In-Reply-To: <20100203175901.GA29456@scico.botik.ru> References: <20100203154431.GA28848@scico.botik.ru> <201002031738.36212.daniel.is.fischer@web.de> <20100203175901.GA29456@scico.botik.ru> Message-ID: <201002031940.11025.daniel.is.fischer@web.de> Am Mittwoch 03 Februar 2010 18:59:01 schrieb Serge D. Mechveliani: > To my > > > > Dear GHC team, > > > > > > It looks like ghc-6.12.1 reports erroneous time profiling -- > > > when the Main module of the project is made under -O. > > > [..] > > > This is for ghc-6.12.1 made from source for Debian Linux and > > > i386-like. > > > > > > Main.main calls for Complete.complete, `complete' calls for > > > eLoop inside its source. > > > eLoop must take almost all the time. > > > My whole user library is made under -O -prof, and > > > --enable-library-profiling. > > > Main is compiled by > > > ghc $dmCpOpt -prof --make Main > > > and run by ./Main +RTS -M400m -pT -RTS > > > For this key, the profiling report Main.prof looks natural and shows > > > eLoop -- 97%. > > > > > > But for ghc $dmCpOpt -O -prof --make Make, > > > > > > it shows a different thing: zero for eLoop and 99% for `main'. > > On Wed, Feb 03, 2010 at 05:38:36PM +0100, Daniel Fischer wrote: > > Could be that eLoop is inlined with -O. > > Thank you. > I also thought about this. But the question still looks difficult. > > > Try > > > > ghc $dmCpOpt -O -prof -auto-all --make > > > > That should show eLoop (if that's a top-level declaration, otherwise > > you'd have to insert a pragma {-# SCC "eLoop" #-} manually). > > eLoop is not a top-level declaration, and I do set {-# SCC "eLoop" #-}. I had a similar issue recently, whether a cost centre shows in the profile depends on where exactly you put it, it might be worthwhile to move it around a bit or add {-# SCC "eLoop" #-} to a few more places in eLoop. > The key combination > ghc $dmCpOpt -prof --make Main > shows 95% for eLoop, > and adding -O to this line shows 0% for eLoop, independently on > presence of -auto-all in this line > (the whole library is made under -O -prof). > > Yes, I recall that the effect may be of inlining. > But, generally, how to detect sensibly the time consuming functions? Insert lots of cost centres. The downside is, the more cost centres you have, the less optimisations are possible. Sometimes that changes the code's behaviour much, so it is possible that things show up as consuming much time which would be optimised to low-cost without profiling. But that should be rare, in general, what shows up as expensive in the profile is also expensive in production code, just somewhat less (or more). > This inlining presents a puzzle here. > > Is it possible to > compile Main.hs and Complete.hs under -O0 -inline-not, > compile all the other modules under -O > ? > (how?). Put {-# OPTIONS_GHC -O1 #-} at the top (but after LANGUAGE pragmas) of all modules except Main and Complete. Then don't give an -O flag on the command line (touch Main.hs and Complete.hs to make sure those are recompiled, perhaps pass -fforce-recomp to recompile everything). > If it is possible, will this make easier to understand the profiling > report? Hopefully :) > > Regards, > > ----------------- > Serge Mechveliani > mechvel@botik.ru From brad.larsen at gmail.com Wed Feb 3 13:54:15 2010 From: brad.larsen at gmail.com (Brad Larsen) Date: Wed Feb 3 13:25:43 2010 Subject: DPH and CUDA status In-Reply-To: <4165d3a71002030934o6b5d7e74kc4deacb50a878ad9@mail.gmail.com> References: <20100203172855.GA18087@kira.casa> <4165d3a71002030934o6b5d7e74kc4deacb50a878ad9@mail.gmail.com> Message-ID: On Wed, Feb 3, 2010 at 12:34 PM, Jeff Heard wrote: > [...] ?One thing though, is that CUDA is being > supplanted by OpenCL in the next few years, and OpenCL can handle data > parallelism on multicore CPUs as well as GPUs with the same code. > It's a little more flexible overall than CUDA, and will be portable > across ATI/nVidia/Intell/AMD/Sony Cell in the end, and is well > supported on Linux, Mac, and Windows systems. [...] I have been told by NVIDIA folks that CUDA is not going to disappear. Its C++ API (as opposed to its ``driver interface'') is quite a bit higher level than OpenCL, suitable for (painful) application development, whereas OpenCL seems more targeted for compiler and framework writers. Sincerely, Brad From felipe.lessa at gmail.com Wed Feb 3 14:01:28 2010 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Wed Feb 3 13:33:02 2010 Subject: DPH and CUDA status In-Reply-To: References: <20100203172855.GA18087@kira.casa> Message-ID: <20100203190128.GA24117@kira.casa> On Wed, Feb 03, 2010 at 11:37:09AM -0600, Donnie Jones wrote: > Hello Felipe, > > I copied this email to Sean Lee & Manuel M T Chakravarty as they > worked on Haskell+CUDA, maybe they can comment on the current status? > > Here's their paper... > GPU Kernels as Data-Parallel Array Computations in Haskell > http://www.cse.unsw.edu.au/~chak/papers/gpugen.pdf As far as I could look for on Hackage and on Chakravarty's web site the code from the paper isn't released. So now he has DPH, Data.Array.Accelerate and GPU monad for array processing :). I wonder if he has any plans of gluing things? Thanks for the tip! -- Felipe. From jeff at renci.org Wed Feb 3 14:06:02 2010 From: jeff at renci.org (Jeff Heard) Date: Wed Feb 3 13:37:50 2010 Subject: DPH and CUDA status In-Reply-To: References: <20100203172855.GA18087@kira.casa> <4165d3a71002030934o6b5d7e74kc4deacb50a878ad9@mail.gmail.com> Message-ID: <4165d3a71002031106t9d9e94p1dbf899901f69b7d@mail.gmail.com> You're quite correct. I should say supplant for normal uses. The OpenCL drivers are built on top of CUDA, and they intend CUDA to continue to be available, but OpenCL is more portable and thus something that we should probably target at some point. On Wed, Feb 3, 2010 at 1:54 PM, Brad Larsen wrote: > On Wed, Feb 3, 2010 at 12:34 PM, Jeff Heard wrote: >> [...] ?One thing though, is that CUDA is being >> supplanted by OpenCL in the next few years, and OpenCL can handle data >> parallelism on multicore CPUs as well as GPUs with the same code. >> It's a little more flexible overall than CUDA, and will be portable >> across ATI/nVidia/Intell/AMD/Sony Cell in the end, and is well >> supported on Linux, Mac, and Windows systems. > [...] > > I have been told by NVIDIA folks that CUDA is not going to disappear. > Its C++ API (as opposed to its ``driver interface'') is quite a bit > higher level than OpenCL, suitable for (painful) application > development, whereas OpenCL seems more targeted for compiler and > framework writers. > > Sincerely, > Brad > From sebf at informatik.uni-kiel.de Wed Feb 3 18:28:45 2010 From: sebf at informatik.uni-kiel.de (Sebastian Fischer) Date: Wed Feb 3 18:00:16 2010 Subject: Quasi quoting In-Reply-To: <9d4d38821002030913t3a6ab827x35f19001b0bdfa81@mail.gmail.com> References: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> <9d4d38821002010625p4a3993b9o49b660817ed9bbed@mail.gmail.com> <4B685062.3060704@isaac.cedarswampstudios.org> <9d4d38821002020825y3a2d6248ga5833db8edcfeae3@mail.gmail.com> <4B68A561.2010001@gmail.com> <9d4d38821002021648sf90e777vcb0decef36f61eda@mail.gmail.com> <08B627F6-C768-41F2-8822-261B0B454993@informatik.uni-kiel.de> <9d4d38821002030913t3a6ab827x35f19001b0bdfa81@mail.gmail.com> Message-ID: On Feb 3, 2010, at 6:13 PM, Max Bolingbroke wrote: >> With a class-based approach only one parser that creates values of >> the same >> type could be used in a program. > > This is not the case, because you still have an instance "Quoted > String". Then you can write: > > $(myLang [|..|]) > > Where myLang :: String -> Q Exp Ah, you're right. I find an instance Quoted String a little confusing and would probably write $(myLang "..") instead. Hmm, this is more complicated if the string contains line breaks and [|..|] would be an alternative string literal syntax where line breaks don't need to be escaped. Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) From chak at cse.unsw.edu.au Wed Feb 3 19:31:53 2010 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Feb 3 19:03:27 2010 Subject: DPH and CUDA status In-Reply-To: <20100203190128.GA24117@kira.casa> References: <20100203172855.GA18087@kira.casa> <20100203190128.GA24117@kira.casa> Message-ID: Felipe Lessa: > On Wed, Feb 03, 2010 at 11:37:09AM -0600, Donnie Jones wrote: >> Hello Felipe, >> >> I copied this email to Sean Lee & Manuel M T Chakravarty as they >> worked on Haskell+CUDA, maybe they can comment on the current status? >> >> Here's their paper... >> GPU Kernels as Data-Parallel Array Computations in Haskell >> http://www.cse.unsw.edu.au/~chak/papers/gpugen.pdf > > As far as I could look for on Hackage and on Chakravarty's web > site the code from the paper isn't released. So now he has DPH, > Data.Array.Accelerate and GPU monad for array processing :). It's really only two things, as the GPU monad from the cited paper has been superseded by Data.Array.Accelerate ? ie, the latter is a revision of the former. So, the code from the cited paper will eventually be released as a CUDA backend for D.A.Accelerate. > I wonder if he has any plans of gluing things? Our intention is to bring the two together eventually, but at the moment, each project on its own is already rather challenging. As far as http://hackage.haskell.org/trac/summer-of-code/ticket/1537 is concerned, I think it is a huge amount of work, well beyond what even a group GSoC project could achieve, especially as it is not just an implementation project, but requires a large amount of research. Things may get a bit easier with the recently announced Fermi architecture, but I don't think that is going to change the picture fundamentally. I would suggest that any GSoC project in this space should be based on D.A.Accelerate (rather than DPH), simply because the code base is much smaller and more accessible. There is not much point in writing a CUDA backend, as we already have a partially working one that we are going to release in due course. However, I repeatedly had people asking for an OpenCL backend. So, there appears to be some demand for that (and it's the right thing to do, given that CUDA is tied to a single company). An OpenCL backend for D.A.Accelerate also appears to be in the scope of what a good coder can achieve in the timeframe of a GSoC project. (To be precise, I think, a good coder can implement a working backend in that timeframe, but it will probably require more work to generate well optimised code.) Manuel From brad.larsen at gmail.com Wed Feb 3 19:32:59 2010 From: brad.larsen at gmail.com (Brad Larsen) Date: Wed Feb 3 19:04:29 2010 Subject: Template Haskell pattern quotations Message-ID: I'll put my question at the very front of this message, and then give the context. My question: Are Template Haskell pattern quotations (i.e., [p| ... |]) not implemented in GHC because they are rather tricky to implement, or because there has not been demand for them? And now, the context. I am working on an embedded DSL/compiler in Haskell, and I want to make use of the recently-much-discussed quasiquoting mechanism to ease reading & writing various transformations. I read through the quasiquoting paper [1] again and played around with some simple examples. In the paper, Data.Generics is used so that the same parser can be used for quasiquoting both expressions and patterns. This requires adding constructors to the ASTs being quasiquoted for antiquotations to be possible. In my application, I don't anticipate using Data.Generics for parser reuse, for a few reasons: * I haven't read the SYB papers, and don't understand how Data.Generics or Data.Data work. * My ASTs in some cases involve GADTs with several phantom type parameters (is that the right terminology?), and DeriveDataTypeable does not work with them. * I don't want to add the extra constructors necessary to support antiquotation with the Data.Generics approach. So, I'm stuck writing separate ExpQ / PatQ parsers. (Actually, I can write the parser once, if it takes a dictionary of semantic actions as a parameter, in which case I only need to write the dictionary of ExpQ actions and the dictionary of PatQ actions.) When writing the ExpQ parser, I can use Template Haskell expression quotations, [| ... |]. When writing the PatQ parser, I have to resort to using the various pattern construction combinators, which is unfortunate! I'd like to be able to use pattern quotations instead. So, my question once again: How hard would it be to implement the pattern quotations from the Template Haskell paper in GHC? Sincerely, Brad References: [1] Geoffrey B. Mainland. Why It's Nice to be Quoted: Quasiquoting for Haskell. From robgreayer at gmail.com Wed Feb 3 19:47:25 2010 From: robgreayer at gmail.com (Robert Greayer) Date: Wed Feb 3 19:18:55 2010 Subject: Template Haskell pattern quotations In-Reply-To: References: Message-ID: <4ec472cb1002031647r4e11d234lb50164895536a4a3@mail.gmail.com> The *splicing* of patterns is considered tricky, see: http://hackage.haskell.org/trac/ghc/ticket/1476 Implementing pattern quotations might be less tricky, but I would imagine to make them useful, you'd have to allow splicing things *into* them, which requires implementing pattern splicing. That's my non-expert take on the issue. On Wed, Feb 3, 2010 at 7:32 PM, Brad Larsen wrote: > I'll put my question at the very front of this message, and then give > the context. > > My question: ?Are Template Haskell pattern quotations (i.e., [p| ... > |]) not implemented in GHC because they are rather tricky to > implement, or because there has not been demand for them? > > And now, the context. > > I am working on an embedded DSL/compiler in Haskell, and I want to > make use of the recently-much-discussed quasiquoting mechanism to ease > reading & writing various transformations. > > I read through the quasiquoting paper [1] again and played around with > some simple examples. ?In the paper, Data.Generics is used so that the > same parser can be used for quasiquoting both expressions and > patterns. ?This requires adding constructors to the ASTs being > quasiquoted for antiquotations to be possible. > > In my application, I don't anticipate using Data.Generics for parser > reuse, for a few reasons: > ?* I haven't read the SYB papers, and don't understand how > Data.Generics or Data.Data work. > ?* My ASTs in some cases involve GADTs with several phantom type > parameters (is that the right terminology?), and DeriveDataTypeable > does not work with them. > ?* I don't want to add the extra constructors necessary to support > antiquotation with the Data.Generics approach. > > So, I'm stuck writing separate ExpQ / PatQ parsers. ?(Actually, I can > write the parser once, if it takes a dictionary of semantic actions as > a parameter, in which case I only need to write the dictionary of ExpQ > actions and the dictionary of PatQ actions.) ?When writing the ExpQ > parser, I can use Template Haskell expression quotations, [| ... |]. > When writing the PatQ parser, I have to resort to using the various > pattern construction combinators, which is unfortunate! ?I'd like to > be able to use pattern quotations instead. > > So, my question once again: ?How hard would it be to implement the > pattern quotations from the Template Haskell paper in GHC? > > Sincerely, > Brad > > > References: > > [1] ?Geoffrey B. Mainland. ?Why It's Nice to be Quoted: ?Quasiquoting > for Haskell. ? > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From jao at gnu.org Wed Feb 3 19:33:39 2010 From: jao at gnu.org (Jose A. Ortega Ruiz) Date: Wed Feb 3 19:39:56 2010 Subject: question about hsc2hs References: <87aavr1yjd.fsf@newton.homeunix.net> <20100202161319.GA13861@soi.city.ac.uk> Message-ID: <87r5p1x2jg.fsf@newton.homeunix.net> Ross Paterson writes: > If you compile your C program with -D_FILE_OFFSET_BITS=64 you'll get the > same numbers that hsc2hs does. Aha, that was the key to solve my problem: programs or libraries compiled with that flag must use statfs64() instead of statfs(). Binding to the former in my .hsc produces correct results. Thanks for the hint, Ross. Cheers, jao From scooter.phd at gmail.com Thu Feb 4 00:02:12 2010 From: scooter.phd at gmail.com (scooter.phd@gmail.com) Date: Wed Feb 3 23:28:35 2010 Subject: DPH and CUDA status In-Reply-To: <4165d3a71002031106t9d9e94p1dbf899901f69b7d@mail.gmail.com> References: <20100203172855.GA18087@kira.casa><4165d3a71002030934o6b5d7e74kc4deacb50a878ad9@mail.gmail.com> <4165d3a71002031106t9d9e94p1dbf899901f69b7d@mail.gmail.com> Message-ID: <1526108574-1265259425-cardhu_decombobulator_blackberry.rim.net-56185535-@bda916.bisx.prod.on.blackberry> I'm personally pessimistic about the STI Cell, but it's a reasonable example wrt the difficulty of writing the backends. Barring the data and message orchestration, which also aflicts GPUs, there's the decision function as to when to migrate a computation to the accelerator (GPU, SPU, ...) Not so much of a problem in chip symmetric mcore, but gets pretty dicey for hybrid mcore. Been trying to wrap my head around that problem for a couple of years. -scooter Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Jeff Heard Date: Wed, 3 Feb 2010 14:06:02 To: Brad Larsen Cc: GHC Users Subject: Re: DPH and CUDA status You're quite correct. I should say supplant for normal uses. The OpenCL drivers are built on top of CUDA, and they intend CUDA to continue to be available, but OpenCL is more portable and thus something that we should probably target at some point. On Wed, Feb 3, 2010 at 1:54 PM, Brad Larsen wrote: > On Wed, Feb 3, 2010 at 12:34 PM, Jeff Heard wrote: >> [...] ?One thing though, is that CUDA is being >> supplanted by OpenCL in the next few years, and OpenCL can handle data >> parallelism on multicore CPUs as well as GPUs with the same code. >> It's a little more flexible overall than CUDA, and will be portable >> across ATI/nVidia/Intell/AMD/Sony Cell in the end, and is well >> supported on Linux, Mac, and Windows systems. > [...] > > I have been told by NVIDIA folks that CUDA is not going to disappear. > Its C++ API (as opposed to its ``driver interface'') is quite a bit > higher level than OpenCL, suitable for (painful) application > development, whereas OpenCL seems more targeted for compiler and > framework writers. > > Sincerely, > Brad > _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From simonpj at microsoft.com Thu Feb 4 02:58:06 2010 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Feb 4 02:27:33 2010 Subject: Template Haskell pattern quotations In-Reply-To: References: Message-ID: <59543203684B2244980D7E4057D5FBC10AFD0EAD@DB3EX14MBXC306.europe.corp.microsoft.com> | My question: Are Template Haskell pattern quotations (i.e., [p| ... | |]) not implemented in GHC because they are rather tricky to | implement, or because there has not been demand for them? They are tricky! The trouble is that patterns *bind variables*. I don't know how to deal cleanly with this. For example f $p = ...g... g x = ...f... Are these mutually recursive? Not if $p expands to something that binds g! But we need to sort bindings into recursive groups before type checking. But splices must be typechecked before being run, so TH splices are run by the typechecker. Unless I have a sudden revelation I don't expect to implement pattern splices anytime soon. On the other hand, pattern *quasiquotes* are fine; they are run by the renamer before scope analysis is done. So you can certainly say f [qq| ...blah.. |] = ...g... Simon From marlowsd at gmail.com Thu Feb 4 04:46:12 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Feb 4 04:17:53 2010 Subject: Quasi quoting In-Reply-To: <59543203684B2244980D7E4057D5FBC10AFCF52A@DB3EX14MBXC306.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> <4ec472cb1002010920x1f889001jfca21fb46fcfe0b0@mail.gmail.com> <59543203684B2244980D7E4057D5FBC10AFCE28E@DB3EX14MBXC306.europe.corp.microsoft.com> (sfid-H-20100201-215602-+65.00-1@multi.osbf.lua) <20100202183743.DD0D16017991C@labrador.cs.tufts.edu> <59543203684B2244980D7E4057D5FBC10AFCF52A@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: <4B6A9764.5090508@gmail.com> On 03/02/2010 15:39, Simon Peyton-Jones wrote: > |> Or we could switch to different quotation brackets altogether for > |> quasiquotation, the obvious possibility being<|...blah...|>, and > |> . That would not be hard, and would only affect the > |> handful of current quasiquote users. But it'd remove "<|" and "|>" as a > |> valid operators, at least for quasiquote customers. I don't know how bad > |> that would be. > | > | Good brackets are scarce. I'd prefer to stick with one of the many > | fine variations on [|...|] currently being discussed. > > I agree with this. My gut feel is to stick with [| ..|] and variants, and live with the fact that TH and QQ aren't using them in quite the same way. Why not provide some nice Unicode version too? ? .. ? ? .. ? ? .. ? etc. Cheers, Simon From marlowsd at gmail.com Thu Feb 4 04:50:14 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Feb 4 04:22:17 2010 Subject: profiling,-O in 6.12.1 In-Reply-To: <20100203175901.GA29456@scico.botik.ru> References: <20100203154431.GA28848@scico.botik.ru> <201002031738.36212.daniel.is.fischer@web.de> <20100203175901.GA29456@scico.botik.ru> Message-ID: <4B6A9856.3080706@gmail.com> On 03/02/2010 17:59, Serge D. Mechveliani wrote: > To my > >>> Dear GHC team, >>> >>> It looks like ghc-6.12.1 reports erroneous time profiling -- >>> when the Main module of the project is made under -O. >>> [..] >>> This is for ghc-6.12.1 made from source for Debian Linux and >>> i386-like. >>> >>> Main.main calls for Complete.complete, `complete' calls for >>> eLoop inside its source. >>> eLoop must take almost all the time. >>> My whole user library is made under -O -prof, and >>> --enable-library-profiling. >>> Main is compiled by >>> ghc $dmCpOpt -prof --make Main >>> and run by ./Main +RTS -M400m -pT -RTS >>> For this key, the profiling report Main.prof looks natural and shows >>> eLoop -- 97%. >>> >>> But for ghc $dmCpOpt -O -prof --make Make, >>> >>> it shows a different thing: zero for eLoop and 99% for `main'. >> > > > On Wed, Feb 03, 2010 at 05:38:36PM +0100, Daniel Fischer wrote: > >> Could be that eLoop is inlined with -O. > > Thank you. > I also thought about this. But the question still looks difficult. > > >> Try >> >> ghc $dmCpOpt -O -prof -auto-all --make >> >> That should show eLoop (if that's a top-level declaration, otherwise you'd >> have to insert a pragma {-# SCC "eLoop" #-} manually). >> > > eLoop is not a top-level declaration, and I do set {-# SCC "eLoop" #-}. > The key combination > ghc $dmCpOpt -prof --make Main > shows 95% for eLoop, > and adding -O to this line shows 0% for eLoop, independently on > presence of -auto-all in this line > (the whole library is made under -O -prof). There are known bugs in this area, see e.g. http://hackage.haskell.org/trac/ghc/ticket/2552 > Yes, I recall that the effect may be of inlining. Inlining should not in general affect the shape of the profile. I can't say much else here without seeing the specific code. Cheers, Simon From sebf at informatik.uni-kiel.de Thu Feb 4 05:47:43 2010 From: sebf at informatik.uni-kiel.de (Sebastian Fischer) Date: Thu Feb 4 05:19:14 2010 Subject: Template Haskell pattern quotations In-Reply-To: <59543203684B2244980D7E4057D5FBC10AFD0EAD@DB3EX14MBXC306.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC10AFD0EAD@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: <5C249D0D-C744-4098-B52E-1A58C5FA22F3@informatik.uni-kiel.de> On Feb 4, 2010, at 8:58 AM, Simon Peyton-Jones wrote: > Unless I have a sudden revelation I don't expect to implement > pattern splices anytime soon. > > On the other hand, pattern *quasiquotes* are fine; they are run by > the renamer before scope analysis is done. So you can certainly say > f [qq| ...blah.. |] = ...g... If I understand Brad correctly, then what he needs is what he called pattern quotation rather than splicing. He can write [e|True|] instead of conE (mkName "True") to implement the Exp parser of his quasi quoter but he cannot write [p|True|] instead of conP (mkName "True") to implement his Pat parser because GHC tells him that "Tempate Haskell pattern brackets are not supported yet". My impression is that the problems with pattern splicing are not affected by support for pattern brackets. We can define a quasi quoter qq to implement id :: a -> a id [$qq|x|] = x independently of whether we use pattern brackets in its definition or not. Or am I missing something? Is there a problem with adding support for pattern brackets on the right-hand side of function definitions in order to simplify the definition of quasi quoters? Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) From felipe.lessa at gmail.com Thu Feb 4 07:06:33 2010 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Thu Feb 4 06:38:06 2010 Subject: DPH and CUDA status In-Reply-To: References: <20100203172855.GA18087@kira.casa> <20100203190128.GA24117@kira.casa> Message-ID: <20100204120633.GA1596@kira.casa> On Thu, Feb 04, 2010 at 11:31:53AM +1100, Manuel M T Chakravarty wrote: > It's really only two things, as the GPU monad from the cited paper > has been superseded by Data.Array.Accelerate ? ie, the latter is a > revision of the former. So, the code from the cited paper will > eventually be released as a CUDA backend for D.A.Accelerate. Oops, thanks for clarifying things up! > I would suggest that any GSoC project in this space should be based > on D.A.Accelerate (rather than DPH), simply because the code base is > much smaller and more accessible. There is not much point in > writing a CUDA backend, as we already have a partially working one > that we are going to release in due course. However, I repeatedly > had people asking for an OpenCL backend. So, there appears to be > some demand for that (and it's the right thing to do, given that > CUDA is tied to a single company). An OpenCL backend for > D.A.Accelerate also appears to be in the scope of what a good coder > can achieve in the timeframe of a GSoC project. (To be precise, I > think, a good coder can implement a working backend in that > timeframe, but it will probably require more work to generate well > optimised code.) Thanks, that's very interesting. What about an LLVM backend, would it be useful? Perhaps it would be possible to use its vector operations to use SIMD instructions of modern CPUs (I think GHC isn't there yet, right?). This is just a thought :). Cheers! -- Felipe. From simonpj at microsoft.com Thu Feb 4 11:35:12 2010 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Feb 4 11:05:00 2010 Subject: Template Haskell pattern quotations In-Reply-To: <5C249D0D-C744-4098-B52E-1A58C5FA22F3@informatik.uni-kiel.de> References: <59543203684B2244980D7E4057D5FBC10AFD0EAD@DB3EX14MBXC306.europe.corp.microsoft.com> <5C249D0D-C744-4098-B52E-1A58C5FA22F3@informatik.uni-kiel.de> Message-ID: <59543203684B2244980D7E4057D5FBC10AFD11E7@DB3EX14MBXC306.europe.corp.microsoft.com> | If I understand Brad correctly, then what he needs is what he called | pattern quotation rather than splicing. ... | | Is there a problem with adding support for pattern brackets on the | right-hand side of function definitions in order to simplify the | definition of quasi quoters? Oh, thank you for clarifying. I'd totally missed that. No, there's no problem at all with pattern quotes. (I've just done the work and it took 10 mins.) I'm already messing with the TH stuff in pursuit of the quasi-quote changes I advertised, so I'll commit it at the same time. That is TH pattern quotes will work but TH pattern splices will continue not to exist Thanks for sorting out my misunderstanding. Simon From g9ks157k at acme.softbase.org Thu Feb 4 13:44:09 2010 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Feb 4 13:15:36 2010 Subject: GHC 6.12.1 and impredicative polymorphism In-Reply-To: <59543203684B2244980D7E4057D5FBC1061BB7CD@DB3EX14MBXC310.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC1061BA9A9@DB3EX14MBXC310.europe.corp.microsoft.com> <1256813844.2471.1641.camel@localhost> <59543203684B2244980D7E4057D5FBC1061BB7CD@DB3EX14MBXC310.europe.corp.microsoft.com> Message-ID: <201002041944.09346.g9ks157k@acme.softbase.org> Am Freitag, 30. Oktober 2009 10:51:37 schrieb Simon Peyton-Jones: > Friends > > One more update about GHC 6.12, concerning impredicative polymorphism. > > GHC has had an experimental implementation of impredicative polymorphism > for a year or two now (flag -XImpredicativePolymorphism). But > > a) The implementation is ridiculously complicated, and the complexity > is pervasive (in the type checker) rather than localized. > I'm very unhappy about this, especially as we add more stuff to > the type checker for type families. > > b) The specification (type system) is well-defined [1], but is also > pretty complicated, and it's just too hard to predict which programs will > typecheck and which will not. > > So it's time for a re-think. I propose to deprecate it in 6.12, and remove > it altogether in 6.14. We may by then have something else to put in its > place. (There is no lack of candidates [2,3,4]!) > > Fortunately, I don't think a lot of people use the feature in anger. > Please yell if you *are* using impredicative polymorphism for something > serious. But if you are, we need to think of a workaround. The current > situation seems unsustainable. > > Simon > > [1] http://research.microsoft.com/en-us/um/people/simonpj/papers/boxy/ > [2] http://research.microsoft.com/en-us/um/people/crusso/qml/ > [3] http://research.microsoft.com/en-us/um/people/daan/pubs.html > [4] http://gallium.inria.fr/~remy/mlf/ Hello Simon and others, unfortunately, I missed this e-mail. Yes, removal of impredicative polymorphism hurts me, since impredicativity plays a crucial role in the Grapefruit FRP library at the moment. This is described in section 5 of my paper ?Signals, Not Generators!? [5]. It?s probably possible to use a workaround involving a newtype wrapper, in case polymorphic fields in newtypes are still supported. However, this makes things more awkward for library users. Best wishes, Wolfgang [5] From brad.larsen at gmail.com Thu Feb 4 16:58:49 2010 From: brad.larsen at gmail.com (Brad Larsen) Date: Thu Feb 4 16:30:15 2010 Subject: Template Haskell pattern quotations In-Reply-To: <5C249D0D-C744-4098-B52E-1A58C5FA22F3@informatik.uni-kiel.de> References: <59543203684B2244980D7E4057D5FBC10AFD0EAD@DB3EX14MBXC306.europe.corp.microsoft.com> <5C249D0D-C744-4098-B52E-1A58C5FA22F3@informatik.uni-kiel.de> Message-ID: On Thu, Feb 4, 2010 at 5:47 AM, Sebastian Fischer wrote: > > On Feb 4, 2010, at 8:58 AM, Simon Peyton-Jones wrote: > >> Unless I have a sudden revelation I don't expect to implement pattern >> splices anytime soon. >> >> On the other hand, pattern *quasiquotes* are fine; they are run by the >> renamer before scope analysis is done. ?So you can certainly say >> ? ? ? ?f [qq| ...blah.. |] = ...g... > > If I understand Brad correctly, then what he needs is what he called pattern > quotation rather than splicing. > > He can write > > ? ?[e|True|] ?instead of ?conE (mkName "True") > > to implement the ?Exp ?parser of his quasi quoter but he cannot write > > ? ?[p|True|] ?instead of ?conP (mkName "True") > > to implement his ?Pat ?parser because GHC tells him that "Tempate Haskell > pattern brackets are not supported yet". > > My impression is that the problems with pattern splicing are not affected by > support for pattern brackets. We can define a quasi quoter ?qq ?to implement > > ? ?id :: a -> a > ? ?id [$qq|x|] = x > > independently of whether we use pattern brackets in its definition or not. > Or am I missing something? > > Is there a problem with adding support for pattern brackets on the > right-hand side of function definitions in order to simplify the definition > of quasi quoters? > > Sebastian > > > -- > Underestimating the novelty of the future is a time-honored tradition. > (D.G.) Yes, I think you have nailed my problem, and described it better than I did! It would be convenient to be able to use the pattern quotation in the right hand side of a definition, when implementing a quasiquoter without relying on the Data.Generics technique. Brad From chak at cse.unsw.edu.au Thu Feb 4 18:07:00 2010 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu Feb 4 17:38:29 2010 Subject: DPH and CUDA status In-Reply-To: <20100204120633.GA1596@kira.casa> References: <20100203172855.GA18087@kira.casa> <20100203190128.GA24117@kira.casa> <20100204120633.GA1596@kira.casa> Message-ID: <24A7FA93-7D05-415E-85B8-2DC969FE2ABB@cse.unsw.edu.au> Felipe Lessa: >> I would suggest that any GSoC project in this space should be based >> on D.A.Accelerate (rather than DPH), simply because the code base is >> much smaller and more accessible. There is not much point in >> writing a CUDA backend, as we already have a partially working one >> that we are going to release in due course. However, I repeatedly >> had people asking for an OpenCL backend. So, there appears to be >> some demand for that (and it's the right thing to do, given that >> CUDA is tied to a single company). An OpenCL backend for >> D.A.Accelerate also appears to be in the scope of what a good coder >> can achieve in the timeframe of a GSoC project. (To be precise, I >> think, a good coder can implement a working backend in that >> timeframe, but it will probably require more work to generate well >> optimised code.) > > Thanks, that's very interesting. What about an LLVM backend, would it > be useful? Perhaps it would be possible to use its vector operations > to use SIMD instructions of modern CPUs (I think GHC isn't there yet, > right?). This is just a thought :). I'm currently implementing an LLVM backend. I'm not planning on using SIMD instructions in the first version, but it is an interesting idea for when a basic LLVM works. Manuel From marcot at riseup.net Fri Feb 5 12:51:38 2010 From: marcot at riseup.net (=?utf-8?q?Marco_T=C3=BAlio_Gontijo_e_Silva?=) Date: Fri Feb 5 12:23:10 2010 Subject: Fwd: Still causes segfault. Message-ID: <1265391185-sup-7494@zezinho> --- Begin forwarded message from Marco T?lio Gontijo e Silva --- From: Marco T?lio Gontijo e Silva To: 557185 <557185@bugs.debian.org> Cc: debian-haskell , glasgow-haskell-users Date: Fri, 05 Feb 2010 15:26:51 -0200 Subject: Still causes segfault. Hi. I just tested building ghc6-6.12.1-4_powerpc with a registered build, that is, without those lines from debian/rules that make an unregistered build, and got a segfault just after running inplace/bin/ghc-stage2 --interactive. Just confirming that this bug is still present in this version. Greetings. --- End forwarded message --- -- marcot http://marcot.iaaeee.org/ From scooter.phd at gmail.com Fri Feb 5 17:14:44 2010 From: scooter.phd at gmail.com (Scott Michel) Date: Fri Feb 5 16:46:09 2010 Subject: DPH and CUDA status In-Reply-To: <24A7FA93-7D05-415E-85B8-2DC969FE2ABB@cse.unsw.edu.au> References: <20100203172855.GA18087@kira.casa> <20100203190128.GA24117@kira.casa> <20100204120633.GA1596@kira.casa> <24A7FA93-7D05-415E-85B8-2DC969FE2ABB@cse.unsw.edu.au> Message-ID: <258cd3201002051414i5ea5d6can7473249fd648d0c2@mail.gmail.com> Are you also planning a LLVM backend for ghc, in a general sense, or just for the accelerated work you're doing? It seems to me that ghc itself could be well served with a LLVM backend, especially if one relies on the JIT mode. That could help identify code paths in the core and runtime that are infrequently used, further optimizing ghc's overall performance. That's the gist behind Latter's work to accelerate the OpenGL stack on Mac OS. The LLVM JIT determines which code paths are actually taken, generating code for only those paths. -scooter PS: I do stand behind my assertion regarding the Cell. I'm the CellSPU backend hacker for LLVM and I've pretty much stopped work on it because IBM has more or less killed the chip. On Thu, Feb 4, 2010 at 3:07 PM, Manuel M T Chakravarty wrote: > Felipe Lessa: > >> I would suggest that any GSoC project in this space should be based > >> on D.A.Accelerate (rather than DPH), simply because the code base is > >> much smaller and more accessible. There is not much point in > >> writing a CUDA backend, as we already have a partially working one > >> that we are going to release in due course. However, I repeatedly > >> had people asking for an OpenCL backend. So, there appears to be > >> some demand for that (and it's the right thing to do, given that > >> CUDA is tied to a single company). An OpenCL backend for > >> D.A.Accelerate also appears to be in the scope of what a good coder > >> can achieve in the timeframe of a GSoC project. (To be precise, I > >> think, a good coder can implement a working backend in that > >> timeframe, but it will probably require more work to generate well > >> optimised code.) > > > > Thanks, that's very interesting. What about an LLVM backend, would it > > be useful? Perhaps it would be possible to use its vector operations > > to use SIMD instructions of modern CPUs (I think GHC isn't there yet, > > right?). This is just a thought :). > > I'm currently implementing an LLVM backend. I'm not planning on using SIMD > instructions in the first version, but it is an interesting idea for when a > basic LLVM works. > > Manuel > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100205/6e231707/attachment.html From simonpj at microsoft.com Sat Feb 6 13:12:57 2010 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Sat Feb 6 12:44:41 2010 Subject: Quasi quoting In-Reply-To: <9d4d38821002010625p4a3993b9o49b660817ed9bbed@mail.gmail.com> References: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> <9d4d38821002010625p4a3993b9o49b660817ed9bbed@mail.gmail.com> Message-ID: <59543203684B2244980D7E4057D5FBC10AFD1FE1@DB3EX14MBXC306.europe.corp.microsoft.com> Max, Dominic Thank you for the thinking you've done on this. It's true that a quasi-quote really is a splice -- that's why there's a "$" in the current syntax. But nevertheless quasiquotes and TH are quite different in other ways, and I don't think it'd be easy to merge them. * TH quotes are parsed, renamed (scope analysis), and typechecked, all by the main GHC parser, renamer, typechecker. I don't want to use some other parser, reanmer or typechecker for that or we'll get into compatibility issues quite apart from duplication. * TH splices $e work for arbitrary expressions e. The expression e must be typechecked before being run. So splices must be run by the type checker. * In contrast, quasi-quotes are effectively always well-typed, since they run the code (parser s), where 'parser' is the user-supplied parser and 's' is a string. That makes it easy to run quasi-quotes before typechecking. * Quasi-quotes can yield patterns, and so they must be run by the renamer. That way a quasiquote that expands to a pattern can bind variables, and all that binding structure is sorted out by the renamer. So a quasiquote not only *can* be run in the ranemer, it *must*. * The user interface of this stuff is important. People who write the functions that are called in splices might put up with some clumsiness, but the *invoker* of the splice (a client of the library, say) doesn't want too much clutter. So unless I'm missing something I'm not that keen. The current setup seems quite good. Simon | -----Original Message----- | From: omega.theta@gmail.com [mailto:omega.theta@gmail.com] On Behalf Of Max | Bolingbroke | Sent: 01 February 2010 14:25 | To: Simon Peyton-Jones | Cc: glasgow-haskell-users@haskell.org; Kathleen Fisher; | mainland@eecs.harvard.edu | Subject: Re: Quasi quoting | | Dominic Orchard and I have come up with a rather radical proposal for | a redesign of the syntax. There are two principal options: | | OPTION 1 (preferred) | =============== | | Advantages: | 1) QuasiQuotes are revealed as they really are - as splices. In my | opinion this is much less confusing, because a "quasiquote" is really | about generating *code*, like a $(), not about generating a *data | structure* like the existing [|e|], [t|t|] and [d|d|]. | 2) Unifies Template Haskell and QQ into one construct | 3) QQ looks like "semantic brackets" | 4) No list comprehension ambiguity | | Disadvantages: | 1) Small syntax changes to QQ and TH. Increased verbosity in some common | cases. | | Start with GHC Haskell. Remove [|e|], [t|t|], [d|d|] and [e|..|] syntax. | | Add this new syntax: | | Syntax: [|...|] | Type: String | Translation: "..." (i.e. this is an alternative string literal syntax) | | Now change the semantics of splice, $(e), like so: | ?1) If e :: Q Exp and we are in an Exp context in the code, run the | computation and splice the resulting code in | ?2) (.. similarly if e :: Q Typ in a Typ context or Q [Decl] in a Decl | context. NB: this is what we had to do for TH before anyway) | ?3) If e :: QuasiQuote then select the appropriate field from the | evaluated "e" based on the context, run the Q computation it contains, | and splice the resulting code in | | Where: | | data QuasiQuote = QuasiQuote { | ? ?quoteExp :: Q Exp | ? ?quotePat :: Q Pat | ?} | | Now provide exports from Language.Haskell.TH: | | e :: String -> Exp | t :: String -> Type | d :: String -> [Decl] | | Which parse the provided string as Haskell into the usual data | structure. Uses of Template Haskell quotes must be rewritten: | | [|..|] ==> e [|..|] | | [t|..|] ==> t [|...|] | | [d|...|] ==> d [|...|] | | QuasiQuotes now look like: | | [foo|...|] ==> $(foo [|...|]) | | Where foo :: String -> QuasiQuote and defines the language you want to parse. | | | OPTION 2 (not so good) | ================= | | Advantages: | 1) Normal Template Haskell use looks almost the same as before | 2) QuasiQuotes are revealed as they really are - as splices | 3) Unifies [t| ... |], [d| ... |] and QQ into one construct | | Disadvantages compared to option 1: | 1) [| |] is still a special case | 3) QQ doesn't look like semantic brackets | 4) List comprehension ambiguity remains | | As GHC Haskell, but with a new interpretation for the QuasiQuote syntax. | Syntax: [e1| ... |] | Types: if e1 :: String -> a, [e1| ... |] :: a | Translation: e1 "..." | | Preserved TH syntax: [| ... |] | Type: [| ... |] :: Exp | Translation: ADT representing "..." parsed as a Haskell program | | Adopt the new semantics of $() exactly as in option 1. | | Now any existing uses of QQ should be rewritten as: | | [foo| ... |] ==> $([foo| ... |]) | | (You could also allow $[foo| ... |] - i.e. you may omit the brackets) | | In this proposal, you can then export "t" and "d" functions from | Language.Haskell.TH with the type: | | t :: String -> Type | d :: String -> [Decl] | | Which parse the provided string as Haskell. This allows existing any | uses of Template Haskell to remain *unchanged* (as long as they | imported the TH module :-). Otherwise rewrite them as: | | [t|..|] ==> Language.Haskell.TH.t [|...|] | | [d|...|] ==> Language.Haskell.TH.d [|...|] | | (You could potentially special case these in the compiler to generate | the result of the parse at compile time, rather than running the | parser at runtime. This means that the staging behaviour of TH quotes | can stay unchanged) | | | CONCLUSION | =========== | | At the cost of changing the staging behaviour of [| |], [t| |] and [d| | |] (usually, the parsing is done at compile time - in my proposal it | is mostly done at runtime) and slightly changing the syntax: | ?1) QQ becomes an explicit splice, which is what it should have been | in the first place. | ?2) QQ is revealed as the combination of two features: a new notation | for String literals, and some extra overloading of the $() operator to | deal with the QuasiQuote record | | I rather like this proposal, even though I realise the chances of such | a radical option being adopted are rather low. | | Cheers, | Dominic and Max | | 2010/2/1 Simon Peyton-Jones : | > Dear GHC users | > | > This email is to announce two proposed changes to GHC's quasi-quotation | mechanism. ?For all I know, no one is using quasi-quotation (although it's a | very cool feature, thanks to Geoff Mainland), but I didn't think I should | take it for granted! | > | > The current spec is here: | > ? ? ? ?http://haskell.org/haskellwiki/Quasiquotation | > ? ? ? ?http://www.haskell.org/ghc/docs/latest/html/users_guide/template- | haskell.html#th-quasiquotation | > | > A quasi-quote can appear as a (a) expression (b) pattern, and looks like | this | > ? ? ? ?[$pads| ...blah... |] | > | > where 'pads' (of course any name will do) is a record of functions | > ? data QuasiQuoter = QuasiQuoter { | > ? ? quoteExp :: String -> Q Exp | > ? ? quotePat :: String -> Q Pat | > ? } | > | > The idea is that GHC evaluates (pads "...blah..."), and splices in the | resulting Exp (or Pat) just as if that's what the user wrote in the first | place. | > | > Kathleen Fisher has started to use this for her PADS system, and came up | with two suggestions. | > | > 1. Allow quasi-quotes at the (top-level) declaration level, just like TH | splices. So you could say, at top level | > ? ? ? ?[$pads| ...blah... |] | > and have it expand to a bunch of top level Haskell declarations. This seems | like an unconditionally good idea. To support it we'd need to add a field to | QuasiQuoter: | > ? data QuasiQuoter = QuasiQuoter { | > ? ? quoteExp :: String -> Q Exp | > ? ? quotePat :: String -> Q Pat | > ? ? quoteDec :: String -> Q [Dec] | > ? } | > but I don't think anyone will lose sleep over that. | > | > 2. ?Make the notation less noisy for the "customer". ?In particular, that | '$' is scary, and redundant to boot. ?She would like to write | > ? ? ? ?[pads| ...blah... |] | > | > I can see the motivation here, but there are two reasons for caution. | > | > ?(i) The Template Haskell quote forms [t| ... |] and [d| ... |] behave | > ? ? ?rather differently. | > | > ?(ii) If "[pads|" is a lexeme, then some list comprehensions become | illegal, such | > ? ? ? as ?[x|x<-xs,y<-ys]. ?But note that because of Template Haskell | quotations, | > ? ? ? a comprehension [t|t<-ts] is already broken, and similarly with 'd', | 'e'. | > ? ? ? So the proposed change will make things *more* uniform, by grabbing | every | > ? ? ? "[blah|" as lexeme. | > | > For me (i) is the main issue. ?The differences are significant. | > ?- A TH quote can appear only where an *expression* is expected | > ? ?But a quasiquote can be an expression or pattern or (assuming (1)) | declaration | > | > ?- A TH quote has type (Q Typ) or (Q [Dec]) or (Q Exp) | > ? ?But a quasiquote is run immediately and spliced in place of the quote | > | > ?- A TH splice is run during type checking | > ? ?But a quasiquote is run during renaming | > | > Even given all that, I'm strongly inclined to follow Kathleen's suggestion: | > ?- The differences are there all right, but in some ways the programmer | thinks | > ? ?the same way: ?[lang| blah |] switches to language 'lang'. | > | > ?- Many users will never encounter the issue; they'll just say | > ? ? ? ?[pads| blah |] | > ? ?to wake up the PADS magic, and be oblivious to Template Haskell quotes | > | > An alternative would be to have some other cue. Ones I've considered | > | > ?- $[pads| ...|], but allowing the $ to be omitted on top-level | declarations, | > ? ?top level, just as it now can for TH splices. | > | > ?- [pads:| ... |], with the colon distinguishing quasi-quoting from TH. | > | > My gut feel is to go with [|pads| ... |]. ?Of course this'd be a change | from the current syntax, but I think there are few enough users that they'll | switch easily enough. | > | > | > Any comments on any of this? | > | > Simon | > | > | > | > | > _______________________________________________ | > Glasgow-haskell-users mailing list | > Glasgow-haskell-users@haskell.org | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | > | > From simonpj at microsoft.com Sat Feb 6 13:14:27 2010 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Sat Feb 6 12:46:03 2010 Subject: Quasi quoting In-Reply-To: <6FEC0686-896A-4503-ACE8-D1851BFE255E@informatik.uni-kiel.de> References: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> <6FEC0686-896A-4503-ACE8-D1851BFE255E@informatik.uni-kiel.de> Message-ID: <59543203684B2244980D7E4057D5FBC10AFD206C@DB3EX14MBXC306.europe.corp.microsoft.com> | What is the reason to restrict quasi quotation to top-level | declarations rather than letting it also generate local declarations? Local declarations for quasi-quotation would be possible too: f x = v where [pads| ..blah..|] But it's a bit more complicated to implement. And a Q [Dec] could produce type and class declarations, which can't appear nested; that would be rejected, but it feels uncomfortable. So, reasonable suggestion, but I think I'll wait till we have a serious customer for this before taking it further. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- | users-bounces@haskell.org] On Behalf Of Sebastian Fischer | Sent: 02 February 2010 11:04 | To: Simon Peyton-Jones | Cc: glasgow-haskell-users@haskell.org; Kathleen Fisher; | mainland@eecs.harvard.edu | Subject: Re: Quasi quoting | | Dear Simon, | | I want to generate data type declarations using quasi quotes and hence | support the proposal to allow quasi quotation at declaration level. | With respect to syntax, I'd prefer [|blah| ... |] over the current | [$blah| ... |] and would also be fine with [blah| ... |]. | | What is the reason to restrict quasi quotation to top-level | declarations rather than letting it also generate local declarations? | | Sebastian | | | -- | Underestimating the novelty of the future is a time-honored tradition. | (D.G.) | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From igloo at earth.li Sat Feb 6 15:24:07 2010 From: igloo at earth.li (Ian Lynagh) Date: Sat Feb 6 14:55:29 2010 Subject: forgetting SCC In-Reply-To: <20100131190942.GA15572@scico.botik.ru> References: <20100131190942.GA15572@scico.botik.ru> Message-ID: <20100206202407.GA5699@matrix.chaos.earth.li> On Sun, Jan 31, 2010 at 10:09:42PM +0300, Serge D. Mechveliani wrote: > I have a suggestion: > is it better for GHC to report an error on the source of kind > {-# "foo" #-} > (entered by a typo instead of {-# SCC "foo" #-}) ? > Currently, GHC makes the program under (-prof) in which, the "foo" center > occurs skipped. This misleads the user: > "foo is not in the profiling head, so it takes zero cost". 6.12.1 will warn: q.hs:3:0: Unrecognised pragma by default. Thanks Ian From mechvel at botik.ru Sun Feb 7 07:06:14 2010 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Sun Feb 7 06:40:29 2010 Subject: forgetting SCC In-Reply-To: <20100207105653.GA13478@matrix.chaos.earth.li> References: <20100131190942.GA15572@scico.botik.ru> <20100206202407.GA5699@matrix.chaos.earth.li> <20100207083931.GA1349@scico.botik.ru> <20100207105653.GA13478@matrix.chaos.earth.li> Message-ID: <20100207120614.GA1531@scico.botik.ru> I am sorry, indeed, ghc-6.12.1 warns of Unrecognised pragma on {-# "foo" #-}. I have just missed this warning. The next question is: why it is a warning and not an error break? ----------------- Serge Mechveliani mechvel@botik.ru On Sun, Feb 07, 2010 at 10:56:53AM +0000, Ian Lynagh wrote: > On Sun, Feb 07, 2010 at 11:39:31AM +0300, Serge D. Mechveliani wrote: > > On Sat, Feb 06, 2010 at 08:24:07PM +0000, Ian Lynagh wrote: > > > On Sun, Jan 31, 2010 at 10:09:42PM +0300, Serge D. Mechveliani wrote: > > > > I have a suggestion: > > > > is it better for GHC to report an error on the source of kind > > > > {-# "foo" #-} > > > > (entered by a typo instead of {-# SCC "foo" #-}) ? > > > > Currently, GHC makes the program under (-prof) in which, the "foo" center > > > > occurs skipped. This misleads the user: > > > > "foo is not in the profiling head, so it takes zero cost". > > > > > > 6.12.1 will warn: > > > > > > q.hs:3:0: Unrecognised pragma > > > > > > by default. > > > > May be, you mean the version next to 6.12.1 ? > > Because this my report is exactly on 6.12.1. > > No, in 6.12.1: > > $ cat Q.hs > > module Q where > > {-# "foo" #-} > > $ ghci Q.hs > GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Loading package ffi-1.0 ... linking ... done. > [1 of 1] Compiling Q ( Q.hs, interpreted ) > > Q.hs:4:0: Unrecognised pragma > Ok, modules loaded: Q. > *Q> > > > Thanks > Ian > > From daniel.is.fischer at web.de Sun Feb 7 07:22:07 2010 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sun Feb 7 06:55:17 2010 Subject: forgetting SCC In-Reply-To: <20100207120614.GA1531@scico.botik.ru> References: <20100131190942.GA15572@scico.botik.ru> <20100207105653.GA13478@matrix.chaos.earth.li> <20100207120614.GA1531@scico.botik.ru> Message-ID: <201002071322.07805.daniel.is.fischer@web.de> Am Sonntag 07 Februar 2010 13:06:14 schrieb Serge D. Mechveliani: > I am sorry, > indeed, ?ghc-6.12.1 ?warns of ?Unrecognised pragma ?on ?{-# "foo" #-}. > I have just missed this warning. > > The next question is: ?why it is a warning and not an error break? Because it might be a valid pragma for some other implementation, so erroring on unrecognised pragmas is not a good option. It would be nice if there was a commandline switch -ferror-unrecognised-pragmas (similarly for other warnings, -ferror-incomplete-patterns, ...), but if your code is otherwise clean enough, something like -Wall -Werror -fno-warn-type-defaults -fno-warn-simple-patterns is convenient, too. From mechvel at botik.ru Sun Feb 7 08:05:48 2010 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Sun Feb 7 07:39:59 2010 Subject: forgetting SCC In-Reply-To: <201002071322.07805.daniel.is.fischer@web.de> References: <20100131190942.GA15572@scico.botik.ru> <20100207105653.GA13478@matrix.chaos.earth.li> <20100207120614.GA1531@scico.botik.ru> <201002071322.07805.daniel.is.fischer@web.de> Message-ID: <20100207130548.GA1594@scico.botik.ru> On Sun, Feb 07, 2010 at 01:22:07PM +0100, Daniel Fischer wrote: > Am Sonntag 07 Februar 2010 13:06:14 schrieb Serge D. Mechveliani: > > I am sorry, > > indeed, ?ghc-6.12.1 ?warns of ?Unrecognised pragma ?on ?{-# "foo" #-}. > > I have just missed this warning. > > > > The next question is: ?why it is a warning and not an error break? > > Because it might be a valid pragma for some other implementation, so > erroring on unrecognised pragmas is not a good option. > [..] Some of earlier implementations or only future? Do you expect for future to appear a pragma without its keyword? ----------------- Serge Mechveliani mechvel@botik.ru From daniel.is.fischer at web.de Sun Feb 7 08:16:11 2010 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sun Feb 7 07:49:19 2010 Subject: forgetting SCC In-Reply-To: <20100207130548.GA1594@scico.botik.ru> References: <20100131190942.GA15572@scico.botik.ru> <201002071322.07805.daniel.is.fischer@web.de> <20100207130548.GA1594@scico.botik.ru> Message-ID: <201002071416.11185.daniel.is.fischer@web.de> Am Sonntag 07 Februar 2010 14:05:48 schrieb Serge D. Mechveliani: > On Sun, Feb 07, 2010 at 01:22:07PM +0100, Daniel Fischer wrote: > > Am Sonntag 07 Februar 2010 13:06:14 schrieb Serge D. Mechveliani: > > > I am sorry, > > > indeed, ?ghc-6.12.1 ?warns of ?Unrecognised pragma ?on ?{-# "foo" > > > #-}. I have just missed this warning. > > > > > > The next question is: ?why it is a warning and not an error break? > > > > Because it might be a valid pragma for some other implementation, so > > erroring on unrecognised pragmas is not a good option. > > [..] > > Some of earlier implementations or only future? I know of no implementation that used {-# "string" #-} as a pragma, so future. > Do you expect for future to appear a pragma without its keyword? No. But you can't be sure, can you? > > ----------------- > Serge Mechveliani > mechvel@botik.ru From mechvel at botik.ru Sun Feb 7 12:03:48 2010 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Sun Feb 7 11:38:01 2010 Subject: forgetting SCC In-Reply-To: <201002071416.11185.daniel.is.fischer@web.de> References: <20100131190942.GA15572@scico.botik.ru> <201002071322.07805.daniel.is.fischer@web.de> <20100207130548.GA1594@scico.botik.ru> <201002071416.11185.daniel.is.fischer@web.de> Message-ID: <20100207170348.GA1696@scico.botik.ru> On Sun, Feb 07, 2010 at 02:16:11PM +0100, Daniel Fischer wrote: > Am Sonntag 07 Februar 2010 14:05:48 schrieb Serge D. Mechveliani: > > On Sun, Feb 07, 2010 at 01:22:07PM +0100, Daniel Fischer wrote: > > > Am Sonntag 07 Februar 2010 13:06:14 schrieb Serge D. Mechveliani: > > > > I am sorry, > > > > indeed, ?ghc-6.12.1 ?warns of ?Unrecognised pragma ?on ?{-# "foo" > > > > #-}. I have just missed this warning. > > > > > > > > The next question is: ?why it is a warning and not an error break? > > > > > > Because it might be a valid pragma for some other implementation, so > > > erroring on unrecognised pragmas is not a good option. > > > [..] > > > > Some of earlier implementations or only future? > > I know of no implementation that used {-# "string" #-} as a pragma, so > future. > > > Do you expect for future to appear a pragma without its keyword? > > No. But you can't be sure, can you? My idea and suggestion is: if the GHC developers take for future that each pragma must have its keyword, then this will prevent some user errors. And the question is: what might be the drawback, I wonder. ----------------- Serge Mechveliani mechvel@botik.ru From mechvel at botik.ru Sun Feb 7 12:24:43 2010 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Sun Feb 7 11:58:54 2010 Subject: keyword in pragma Message-ID: <20100207172443.GA1799@scico.botik.ru> In my last letter I wrote about the prossibility for the GHC developers to require a keyword in any pragma, "for future". I thought that pragma is a matter of the GHC language extension. But if it is of the Haskell standard, then, again I am sorry! Regards, ----------------- Serge Mechveliani mechvel@botik.ru From chak at cse.unsw.edu.au Sun Feb 7 20:21:59 2010 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Feb 7 19:53:21 2010 Subject: DPH and CUDA status In-Reply-To: <258cd3201002051414i5ea5d6can7473249fd648d0c2@mail.gmail.com> References: <20100203172855.GA18087@kira.casa> <20100203190128.GA24117@kira.casa> <20100204120633.GA1596@kira.casa> <24A7FA93-7D05-415E-85B8-2DC969FE2ABB@cse.unsw.edu.au> <258cd3201002051414i5ea5d6can7473249fd648d0c2@mail.gmail.com> Message-ID: <220ADC2A-8A82-4B0A-A57E-00B441D0C945@cse.unsw.edu.au> Scott Michel wrote, > Are you also planning a LLVM backend for ghc, in a general sense, or just for the accelerated work you're doing? It seems to me that ghc itself could be well served with a LLVM backend, especially if one relies on the JIT mode. That could help identify code paths in the core and runtime that are infrequently used, further optimizing ghc's overall performance. I had a student implementing a LLVM backend for GHC last year. You can find the details at http://www.cse.unsw.edu.au/~pls/thesis/davidt-thesis.pdf We are planning to merge this work into the main GHC repository. (At the moment, this is not using the JIT, but that would be another interesting project.) Manuel From bulat.ziganshin at gmail.com Mon Feb 8 03:13:16 2010 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Feb 8 02:51:09 2010 Subject: DPH and CUDA status In-Reply-To: <220ADC2A-8A82-4B0A-A57E-00B441D0C945@cse.unsw.edu.au> References: <20100203172855.GA18087@kira.casa> <20100203190128.GA24117@kira.casa> <20100204120633.GA1596@kira.casa> <24A7FA93-7D05-415E-85B8-2DC969FE2ABB@cse.unsw.edu.au> <258cd3201002051414i5ea5d6can7473249fd648d0c2@mail.gmail.com> <220ADC2A-8A82-4B0A-A57E-00B441D0C945@cse.unsw.edu.au> Message-ID: <1087019193.20100208111316@gmail.com> Hello Manuel, Monday, February 8, 2010, 4:21:59 AM, you wrote: > I had a student implementing a LLVM backend for GHC last year. You can find the details at what's the status of port? can it compile full-scale programs, like darcs/ghc? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From marlowsd at gmail.com Mon Feb 8 08:19:01 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Feb 8 07:50:35 2010 Subject: Fwd: Still causes segfault. In-Reply-To: <1265391185-sup-7494@zezinho> References: <1265391185-sup-7494@zezinho> Message-ID: <4B700F45.2050704@gmail.com> On 05/02/2010 17:51, Marco T?lio Gontijo e Silva wrote: > --- Begin forwarded message from Marco T?lio Gontijo e Silva --- > From: Marco T?lio Gontijo e Silva > To: 557185<557185@bugs.debian.org> > Cc: debian-haskell, glasgow-haskell-users > Date: Fri, 05 Feb 2010 15:26:51 -0200 > Subject: Still causes segfault. > > Hi. > > I just tested building ghc6-6.12.1-4_powerpc with a registered build, that is, > without those lines from debian/rules that make an unregistered build, and got > a segfault just after running inplace/bin/ghc-stage2 --interactive. > > Just confirming that this bug is still present in this version. Any PowerPC hackers out there want to take a look at this? It would be a shame if GHC was fatally broken on PowerPC due to some small or easily fixable bug. The only reason we don't support PowerPC is lack of resources, but we're more than happy to provide help/advice to anyone who wants to work on PowerPC support. Cheers, Simon From pho at cielonegro.org Mon Feb 8 10:06:06 2010 From: pho at cielonegro.org (PHO) Date: Mon Feb 8 09:37:28 2010 Subject: Still causes segfault. In-Reply-To: <4B700F45.2050704@gmail.com> References: <1265391185-sup-7494@zezinho> <4B700F45.2050704@gmail.com> Message-ID: <20100209.000606.186322295.pho@cielonegro.org> From: Simon Marlow Subject: Re: Fwd: Still causes segfault. Date: Mon, 08 Feb 2010 13:19:01 +0000 > On 05/02/2010 17:51, Marco T?lio Gontijo e Silva wrote: >> --- Begin forwarded message from Marco T?lio Gontijo e Silva --- >> From: Marco T?lio Gontijo e Silva {snip} >> I just tested building ghc6-6.12.1-4_powerpc with a registered build, >> that is, >> without those lines from debian/rules that make an unregistered build, >> and got >> a segfault just after running inplace/bin/ghc-stage2 --interactive. >> >> Just confirming that this bug is still present in this version. > > Any PowerPC hackers out there want to take a look at this? It would > be a shame if GHC was fatally broken on PowerPC due to some small or > easily fixable bug. The only reason we don't support PowerPC is lack > of resources, but we're more than happy to provide help/advice to > anyone who wants to work on PowerPC support. I'm using GHC 6.12.1 on powerpc-apple-darwin (Leopard). It works almost perfectly except for just one problem that HSghc-6.12.1.o is unavailable because of a limitation of static linker. See: http://hackage.haskell.org/trac/ghc/ticket/3260 Unfortunately I can't easily try out any Linux/PPC systems for now. _______________________________________________________ - PHO - http://cielonegro.org/ OpenPGP public key: 1024D/1A86EF72 Fpr: 5F3E 5B5F 535C CE27 8254 4D1A 14E7 9CA7 1A86 EF72 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100208/ef8f92bb/attachment.bin From choener at tbi.univie.ac.at Mon Feb 8 17:55:15 2010 From: choener at tbi.univie.ac.at (Christian =?iso-8859-1?Q?H=F6ner?= zu Siederdissen) Date: Mon Feb 8 17:26:38 2010 Subject: Text.Regex.Posix with [String] Result broken? Message-ID: <20100208225515.GA24520@workstation> Hi, are Regex'es broken or is this local to my installation? I want to blame someone else, see: http://book.realworldhaskell.org/read/efficient-file-processing-regular-expressions-and-file-name-matching.html where all result types of [a] are broken, too. Thanks, Christian What to test for: Prelude> :m Text.Regex.Posix Prelude Text.Regex.Posix> "aab" =~ "a" :: String "a" Prelude Text.Regex.Posix> "aab" =~ "a" :: [String] :1:0: No instance for (RegexContext Regex [Char] [String]) arising from a use of `=~' at :1:0-11 Possible fix: add an instance declaration for (RegexContext Regex [Char] [String]) In the expression: "aab" =~ "a" :: [String] In the definition of `it': it = "aab" =~ "a" :: [String] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100208/bba5b2c9/attachment.bin From simonpj at microsoft.com Tue Feb 9 10:01:50 2010 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Feb 9 09:33:32 2010 Subject: GHC 6.12.1 and impredicative polymorphism In-Reply-To: <201002041944.09346.g9ks157k@acme.softbase.org> References: <59543203684B2244980D7E4057D5FBC1061BA9A9@DB3EX14MBXC310.europe.corp.microsoft.com> <1256813844.2471.1641.camel@localhost> <59543203684B2244980D7E4057D5FBC1061BB7CD@DB3EX14MBXC310.europe.corp.microsoft.com> <201002041944.09346.g9ks157k@acme.softbase.org> Message-ID: <59543203684B2244980D7E4057D5FBC10AFD35DB@DB3EX14MBXC306.europe.corp.microsoft.com> | Hello Simon and others, | | unfortunately, I missed this e-mail. | | Yes, removal of impredicative polymorphism hurts me, since impredicativity | plays a crucial role in the Grapefruit FRP library at the moment. This is | described in section 5 of my paper ?Signals, Not Generators!? [5]. It?s | probably possible to use a workaround involving a newtype wrapper, in case | polymorphic fields in newtypes are still supported. However, this makes things | more awkward for library users. I plan to support impredicative polymorphism in some form; but you may need more type annotations. I'll announce when there's something to test (it'll be a couple of months). Simon From simonpj at microsoft.com Tue Feb 9 10:01:42 2010 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Feb 9 09:33:38 2010 Subject: Undeliverable: Splicing types.. should this work? Message-ID: <59543203684B2244980D7E4057D5FBC10AFD35CB@DB3EX14MBXC306.europe.corp.microsoft.com> Robert Interesting example. Here's your code: createInstance' :: Q Type -> Q Dec createInstance' t = liftM head [d| instance Foo $t where type FooType $t = String |] When TH sees a quotation, it *typechecks* it. So it tries to typecheck instance Foo $t where type FooType $t = String During typechecking, it needs something to use as the type to which $t will expand. So it uses a fresh type variable -- but a different one each time. And this is what is biting you. In general that's right. You would not expect it to work if you said instance Foo $(t 19) where type FooType $(t 19) = String seeing that 't' is applied to the same argument each time. There no special case for plain variables. So it's hardly a feature, but I can't see how to do just what you want. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Robert Greayer | Sent: 25 January 2010 23:27 | To: glasgow-haskell-users@haskell.org | Subject: Splicing types.. should this work? | | Now that type-splicing works in TH, and TH has type-family support, I | was wondering if the following example should compile (with 6.12.1): | | > {-# LANGUAGE TemplateHaskell, MultiParamTypeClasses, TypeFamilies, | > FlexibleInstances, OverlappingInstances #-} | | > module Sample where | | > import Control.Monad | > import Language.Haskell.TH | | > class Foo a where | > type FooType a | | > createInstance :: Q Type -> Q Dec | | > createInstance t = instanceD (return []) | > (conT ''Foo `appT` t) [ | > tySynInstD ''FooType [t] (conT ''String) | > ] | | > createInstance' :: Q Type -> Q Dec | > createInstance' t = liftM head [d| | > instance Foo $t where | > type FooType $t = String|] | | the function 'createInstance' compiles without a problem, but it's | (near) equivalent | written using TH quotations + splices fails with the error: | | Sample.lhs:22:10: | Type indexes must match class instance head | Found `t_aMn' but expected `t_aMl' | In the associated type instance for `FooType' | In the instance declaration for `Foo $t' | In the Template Haskell quotation | [d| | instance Foo $t where | type instance FooType $t = String |] | | The compiler seems to not be able to determine that the type spliced | in the class instance head will match the type spliced in the type | instance. | | The first version works fine for my purposes, but was curious whether | the failure of the 2nd was a bug or a feature. | | Thanks, | Rob | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From simonpj at microsoft.com Wed Feb 10 07:13:10 2010 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Feb 10 06:44:51 2010 Subject: Overlapping Instances + Existentials = Incoherent Instances In-Reply-To: <201002022207.34970.dan.doel@gmail.com> References: <201002022207.34970.dan.doel@gmail.com> Message-ID: <59543203684B2244980D7E4057D5FBC10AFD3D27@DB3EX14MBXC306.europe.corp.microsoft.com> This is a tricky one. The motivating example is this: -- Overlapping instances instance Show a => Show [a] where ... instance Show Char where ... data T where MkT :: Show a => [a] -> T f :: T -> String f (MkT xs) = show xs ++ "\n" Here it's clear that the only way to discharge the (Show [a]) constraint on 'x' is with the (Show a) dictionary stored inside the MkT. Yet doing so means ignoring the possibility that a=Char. So, for example, if we go h = case MkT "boo" of MkT xs -> show xs ++ "\n" we'll get the output string "['b','o','o']", not "boo". So yes, that's incoherent, in the sense that if we did the case-elimination we'd get (show "boo" ++ "\n"), and that would give a different result. Why does GHC have this behaviour? Because in the case of type signature, such as g :: [a] -> String g xs = show xs ++ "\n" we can change g's type signature to make it compile without having to choose which instance to use: g :: Show [a] => [a] -> String But with an existential type there is no way we can alter 'f' to make it work; it's the definition of T that would have to change. So I can't say it's perfect, but it seems too much of a Big Hammer to say IncoherentInstances for f. Anyway, that's the rationale. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Dan Doel | Sent: 03 February 2010 03:08 | To: glasgow-haskell-users@haskell.org | Subject: Overlapping Instances + Existentials = Incoherent Instances | | Greetings, | | I've actually known about this for a while, but while discussing it, it | occurred to me that perhaps it's something I should report to the proper | authorities, as I've never seen a discussion of it. But, I thought I'd start | here rather than file a bug, since I'm not sure it isn't intended. Anyhow, | here's the example: | | class C a where | foo :: a -> String | | instance C a where | foo _ = "universal" | | instance C Int where | foo _ = "Int" | | bar :: a -> String | bar x = foo x | | Now, normally bar generates a complaint, but if you enable | IncoherentInstances, it's accepted, and it always generates "universal", even | if called with an Int. Adding a 'C a' constraint to the type makes it give | "Int" in the case of an Int. | | Now, IncoherentInstances is something most people would suggest you don't use | (even people who are cool with OverlappingInstances). However, it turns out | that ExistentialQuantification does the same thing, because we can write: | | data Ex = forall a. Ex a | | baz :: a -> String | baz x = case Ex x of | Ex x' -> foo x' | | and this is accepted, and always yields "universal", just like bar. So, things | that you get out of an existential are allowed to make use of the general | versions of overlapping instances if any fit. | | So, I never really regarded this as anything more than an oddity that's | unlikely to come up. And it might be working as intended. But I thought | perhaps I should ask: is this intended? One could probably build a case that | baz should only be accepted if IncoherentInstances are enabled, since it's | doing about the same thing. | | I'm not really sure how far back this behavior goes. I've probably known about | it for several 6.X releases without mentioning it except as a fun party fact | (apologies). Is this the way things are supposed to work? (And sorry if I just | missed the discussion somewhere. I searched the trac and didn't see anything | very promising.) | | Cheers, | -- Dan | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From karel.gardas at centrum.cz Thu Feb 11 17:00:14 2010 From: karel.gardas at centrum.cz (Karel Gardas) Date: Thu Feb 11 16:31:20 2010 Subject: buildbot status Message-ID: <4B747DEE.7070709@centrum.cz> Hello, as per GHC wiki (http://hackage.haskell.org/trac/ghc/wiki/BuildBot), its buildbot should be accessible either on http://darcs.haskell.org/buildbot or on http://darcs.haskell.org:8010. The first one return 404 page not found and the second tries to connect forever. May I ask what's the correct url for buildbot web page? Thanks, Karel From garious at gmail.com Fri Feb 12 16:17:13 2010 From: garious at gmail.com (Greg Fitzgerald) Date: Fri Feb 12 15:48:35 2010 Subject: Confusion about GHC and GMP Message-ID: <1f3dc80d1002121317o39a761cese20e3862448834ea@mail.gmail.com> I wonder if someone might be able to clear a few things up for me about implementing Integer with GMP.? First, is the link below the most up-to-date information regarding GHC's situation? http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes#BinaryDropinReplacementforGMP I assume that "INTEGER_LIBRARY=integer-foo" is an option when compiling GHC itself and not when using GHC, correct? If so, what version of GHC was this added? 6.10, 6.12, HEAD? Lastly, I'm confused about GHC's posted license, should it actually be LGPL so long as it statically links GMP? Aren't there a number of companies releasing binaries that were compiled with GHC? Thanks, Greg From vw at volker-wysk.de Sat Feb 13 07:23:32 2010 From: vw at volker-wysk.de (Volker Wysk) Date: Sat Feb 13 06:56:27 2010 Subject: How to get the file descriptor of a handle? Message-ID: <20100213132332.d7b71152.vw@volker-wysk.de> Hello I'd like to know how you get the file descriptor, which is incapsulated in a handle. The libraries GHC.IO.Handle/GHC.IO.Handle.FD only provide for the other direction. The function haFD, which I've used before I've updated to the current version of GHC (6.12), appears to be in use two times in the libraries. But there isn't a definition anywhere. Any help would be appreciated. Cheers, Volker -- Volker Wysk From igloo at earth.li Sat Feb 13 09:50:30 2010 From: igloo at earth.li (Ian Lynagh) Date: Sat Feb 13 09:21:29 2010 Subject: Fw: Re: Re[2]: No more ExitException? <- documentation bug In-Reply-To: <20100128083257.adb53f74.vw@volker-wysk.de> References: <20100128083257.adb53f74.vw@volker-wysk.de> Message-ID: <20100213145030.GA9140@matrix.chaos.earth.li> On Thu, Jan 28, 2010 at 08:32:57AM +0100, Volker Wysk wrote: > > As you can see, it throws the ExitCode, not an ExitException. The documentation is faulty. Thanks for the report; fixed. Thanks Ian From igloo at earth.li Sat Feb 13 10:01:13 2010 From: igloo at earth.li (Ian Lynagh) Date: Sat Feb 13 09:32:12 2010 Subject: Confusion about GHC and GMP In-Reply-To: <1f3dc80d1002121317o39a761cese20e3862448834ea@mail.gmail.com> References: <1f3dc80d1002121317o39a761cese20e3862448834ea@mail.gmail.com> Message-ID: <20100213150113.GA9313@matrix.chaos.earth.li> On Fri, Feb 12, 2010 at 01:17:13PM -0800, Greg Fitzgerald wrote: > I wonder if someone might be able to clear a few things up for me > about implementing Integer with GMP.? First, is the link below the > most up-to-date information regarding GHC's situation? > > http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes#BinaryDropinReplacementforGMP I assume you mean http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes#CurrentStatus in which case, yes. > I assume that "INTEGER_LIBRARY=integer-foo" is an option when > compiling GHC itself and not when using GHC, correct? Yes. > If so, what > version of GHC was this added? 6.10, 6.12, HEAD? 6.12. > Lastly, I'm confused about GHC's posted license, should it actually be > LGPL so long as it statically links GMP? IANAL, but on most platforms GMP is dynamically linked, and see also http://haskell.forkio.com/gmpwindows Thanks Ian From jeremy at n-heptane.com Sat Feb 13 19:58:43 2010 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Sat Feb 13 19:30:41 2010 Subject: How to get the file descriptor of a handle? In-Reply-To: <20100213132332.d7b71152.vw@volker-wysk.de> References: <20100213132332.d7b71152.vw@volker-wysk.de> Message-ID: Hello, In GHC 6.12 there is no guarantee that a Handle is backed up by a file descriptor. That said, check out the handleToFd defined on line 141 here: http://patch-tag.com/r/mae/sendfile/snapshot/current/content/pretty/src/Network/Socket/SendFile/Internal.hs A better type might be: handleToFd :: Handle -> IO (Maybe Fd) instead of raising an exception. Having a Handle not backed by a Fd is not really an 'exceptional' condition after all. - jeremy On Feb 13, 2010, at 6:23 AM, Volker Wysk wrote: > Hello > > I'd like to know how you get the file descriptor, which is > incapsulated in a handle. The libraries GHC.IO.Handle/ > GHC.IO.Handle.FD only provide for the other direction. > > The function haFD, which I've used before I've updated to the > current version of GHC (6.12), appears to be in use two times in the > libraries. But there isn't a definition anywhere. > > > Any help would be appreciated. > > Cheers, > Volker > > > -- > Volker Wysk > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From igloo at earth.li Sun Feb 14 10:11:34 2010 From: igloo at earth.li (Ian Lynagh) Date: Sun Feb 14 09:42:30 2010 Subject: buildbot status In-Reply-To: <4B747DEE.7070709@centrum.cz> References: <4B747DEE.7070709@centrum.cz> Message-ID: <20100214151134.GA9010@matrix.chaos.earth.li> On Thu, Feb 11, 2010 at 11:00:14PM +0100, Karel Gardas wrote: > > as per GHC wiki (http://hackage.haskell.org/trac/ghc/wiki/BuildBot), its > buildbot should be accessible either on > http://darcs.haskell.org/buildbot or on http://darcs.haskell.org:8010. > The first one return 404 page not found and the second tries to connect > forever. May I ask what's the correct url for buildbot web page? I've just added this to the top of the page: Current status Buildbot is currently down, and we are working on a replacement here: http://code.haskell.org/builder/ Thanks Ian From igloo at earth.li Sun Feb 14 11:51:38 2010 From: igloo at earth.li (Ian Lynagh) Date: Sun Feb 14 11:22:34 2010 Subject: Removing/deprecating -fvia-c Message-ID: <20100214165138.GA14278@matrix.chaos.earth.li> Hi all, We are planning to remove the -fvia-c way of compiling code (unregisterised compilers will continue to compile via C only, but registerised compilers will only use the native code generator). We'll probably deprecate -fvia-c in the 6.14 branch, and remove it in 6.16. Simon Marlow has recently fixed FP performance for modern x86 chips in the native code generator in the HEAD. That was the last reason we know of to prefer via-C to the native code generators. But before we start the removal process, does anyone know of any other problems with the native code generators that need to be fixed first? Thanks Ian From dons at galois.com Sun Feb 14 12:58:35 2010 From: dons at galois.com (Don Stewart) Date: Sun Feb 14 12:29:30 2010 Subject: Removing/deprecating -fvia-c In-Reply-To: <20100214165138.GA14278@matrix.chaos.earth.li> References: <20100214165138.GA14278@matrix.chaos.earth.li> Message-ID: <20100214175835.GA31709@whirlpool.galois.com> igloo: > > Hi all, > > We are planning to remove the -fvia-c way of compiling code > (unregisterised compilers will continue to compile via C only, but > registerised compilers will only use the native code generator). > We'll probably deprecate -fvia-c in the 6.14 branch, and remove it in > 6.16. > > Simon Marlow has recently fixed FP performance for modern x86 chips in > the native code generator in the HEAD. That was the last reason we know > of to prefer via-C to the native code generators. But before we start > the removal process, does anyone know of any other problems with the > native code generators that need to be fixed first? > Do we have the blessing of the DPH team, wrt. tight, numeric inner loops? As recently as last year -fvia-C -optc-O3 was still useful for some microbenchmarks -- what's changed in that time, or is expected to change? -- Don From pumpkingod at gmail.com Sun Feb 14 14:20:30 2010 From: pumpkingod at gmail.com (Daniel Peebles) Date: Sun Feb 14 13:51:24 2010 Subject: Removing/deprecating -fvia-c In-Reply-To: <20100214175835.GA31709@whirlpool.galois.com> References: <20100214165138.GA14278@matrix.chaos.earth.li> <20100214175835.GA31709@whirlpool.galois.com> Message-ID: I thought GHC's own codegen didn't do any instruction reordering for the pipeline. I guess that ends up not being much of an issue in practice? On Sun, Feb 14, 2010 at 12:58 PM, Don Stewart wrote: > igloo: > > > > Hi all, > > > > We are planning to remove the -fvia-c way of compiling code > > (unregisterised compilers will continue to compile via C only, but > > registerised compilers will only use the native code generator). > > We'll probably deprecate -fvia-c in the 6.14 branch, and remove it in > > 6.16. > > > > Simon Marlow has recently fixed FP performance for modern x86 chips in > > the native code generator in the HEAD. That was the last reason we know > > of to prefer via-C to the native code generators. But before we start > > the removal process, does anyone know of any other problems with the > > native code generators that need to be fixed first? > > > > Do we have the blessing of the DPH team, wrt. tight, numeric inner loops? > > As recently as last year -fvia-C -optc-O3 was still useful for some > microbenchmarks -- what's changed in that time, or is expected to change? > > -- Don > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100214/9cea6b73/attachment.html From johan.tibell at gmail.com Sun Feb 14 14:25:31 2010 From: johan.tibell at gmail.com (Johan Tibell) Date: Sun Feb 14 13:56:47 2010 Subject: Removing/deprecating -fvia-c In-Reply-To: <20100214165138.GA14278@matrix.chaos.earth.li> References: <20100214165138.GA14278@matrix.chaos.earth.li> Message-ID: <90889fe71002141125v1d206f47u7857dda32b1d3613@mail.gmail.com> On Sun, Feb 14, 2010 at 5:51 PM, Ian Lynagh wrote: > > Hi all, > > We are planning to remove the -fvia-c way of compiling code > (unregisterised compilers will continue to compile via C only, but > registerised compilers will only use the native code generator). > We'll probably deprecate -fvia-c in the 6.14 branch, and remove it in > 6.16. > > Simon Marlow has recently fixed FP performance for modern x86 chips in > the native code generator in the HEAD. That was the last reason we know > of to prefer via-C to the native code generators. But before we start > the removal process, does anyone know of any other problems with the > native code generators that need to be fixed first? > > What about loop unrolling? I remember seeing some discussion about that quite a while ago. Do we have any feature requests (i.e. performance bugs) related to that? Cheers, Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100214/48a52030/attachment.html From marlowsd at gmail.com Mon Feb 15 11:37:55 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Feb 15 11:09:03 2010 Subject: Removing/deprecating -fvia-c In-Reply-To: <20100214175835.GA31709@whirlpool.galois.com> References: <20100214165138.GA14278@matrix.chaos.earth.li> <20100214175835.GA31709@whirlpool.galois.com> Message-ID: <4B797863.1000409@gmail.com> On 14/02/2010 17:58, Don Stewart wrote: > igloo: >> >> Hi all, >> >> We are planning to remove the -fvia-c way of compiling code >> (unregisterised compilers will continue to compile via C only, but >> registerised compilers will only use the native code generator). >> We'll probably deprecate -fvia-c in the 6.14 branch, and remove it in >> 6.16. >> >> Simon Marlow has recently fixed FP performance for modern x86 chips in >> the native code generator in the HEAD. That was the last reason we know >> of to prefer via-C to the native code generators. But before we start >> the removal process, does anyone know of any other problems with the >> native code generators that need to be fixed first? >> > > Do we have the blessing of the DPH team, wrt. tight, numeric inner loops? > > As recently as last year -fvia-C -optc-O3 was still useful for some > microbenchmarks -- what's changed in that time, or is expected to change? If you have benchmarks that show a significant difference, I'd be interested to see them. What I've done for 6.14.1 is to add the -msse2 flag to the x86 backend, so where previously we had to use -fvia-C -fexcess-precision -optc-O3 etc. to get reasonable floating point performance, now we can use -msse2 with the native code gen and get about the same results. In the future we have a couple of ways that things could get better: 1. The new back-end, which eventually will incorporate more optimisations at the C-- level, and potentially could produce good loop code. It will also free up some registers. 2. Compiling via LLVM. Dropping the C backend will give us more flexibility with calling conventions, letting us use more of the x86 registers for passing arguments. We can only make this change by removing -fvia-C, though. There's low hanging fruit here particularly for the x86 backend, as soon as we drop -fvia-C. There are other reasons to want to get rid of -fvia-C: - it doubles the testing surface - it's associated with a bucketload of grotesque Perl 4 code and gcc-specific hacks in the RTS headers. Cheers, Simon From luca_ciciriello at hotmail.com Mon Feb 15 12:01:11 2010 From: luca_ciciriello at hotmail.com (Luca Ciciriello) Date: Mon Feb 15 11:32:09 2010 Subject: -package Message-ID: I've imported in my module: import Control.Concurrent.STM. My question is: Have I to use -package stm in ghc command line options? Thanks in advance. Luca. From bulat.ziganshin at gmail.com Mon Feb 15 12:56:15 2010 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Feb 15 12:27:18 2010 Subject: -package In-Reply-To: References: Message-ID: <395218088.20100215205615@gmail.com> Hello Luca, Monday, February 15, 2010, 8:01:11 PM, you wrote: > I've imported in my module: import Control.Concurrent.STM. > My question is: Have I to use -package stm in ghc command line options? either use -package stm or --make. later automatically imports all required packages -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From choener at tbi.univie.ac.at Mon Feb 15 13:28:01 2010 From: choener at tbi.univie.ac.at (Christian =?iso-8859-1?Q?H=F6ner?= zu Siederdissen) Date: Mon Feb 15 12:57:49 2010 Subject: Removing/deprecating -fvia-c In-Reply-To: References: Message-ID: <20100215182801.GA24040@totalegal.domain> Hi, the things I am interested in are: foldU f init . mapU (\k -> array_1 !: (i,k) `combine` array_2 !: (k,j)) $ enumFromToU i j where (!:) = fancy_index_op with both `vector` and `uvector` (then D.V.fold etc). Since ghc 6.12 there has been no significant difference in using either backend. Then again, more time is spent indexing than optimising the tight loop. Viele Gruesse, Christian Hoener zu Siederdissen From: Ian Lynagh > > > Hi all, > > We are planning to remove the -fvia-c way of compiling code > (unregisterised compilers will continue to compile via C only, but > registerised compilers will only use the native code generator). > We'll probably deprecate -fvia-c in the 6.14 branch, and remove it in > 6.16. > > Simon Marlow has recently fixed FP performance for modern x86 chips in > the native code generator in the HEAD. That was the last reason we know > of to prefer via-C to the native code generators. But before we start > the removal process, does anyone know of any other problems with the > native code generators that need to be fixed first? > > > Thanks > Ian > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100215/46672fef/attachment.bin From dons at galois.com Mon Feb 15 13:29:20 2010 From: dons at galois.com (Don Stewart) Date: Mon Feb 15 13:00:14 2010 Subject: Removing/deprecating -fvia-c In-Reply-To: <4B797863.1000409@gmail.com> References: <20100214165138.GA14278@matrix.chaos.earth.li> <20100214175835.GA31709@whirlpool.galois.com> <4B797863.1000409@gmail.com> Message-ID: <20100215182920.GB3829@whirlpool.galois.com> marlowsd: >>> >>> Simon Marlow has recently fixed FP performance for modern x86 chips in >>> the native code generator in the HEAD. That was the last reason we know >>> of to prefer via-C to the native code generators. But before we start >>> the removal process, does anyone know of any other problems with the >>> native code generators that need to be fixed first? >>> >> >> Do we have the blessing of the DPH team, wrt. tight, numeric inner loops? >> >> As recently as last year -fvia-C -optc-O3 was still useful for some >> microbenchmarks -- what's changed in that time, or is expected to change? > > If you have benchmarks that show a significant difference, I'd be > interested to see them. I've attached an example where there's a 40% variation (and it's a floating point benchmark). Roman would be seeing similar examples in the vector code. I'm all in favor of dropping the C backend, but I'm also wary that we don't have benchmarks to know what difference it is making. Here's a simple program testing a tight, floating point loop: import Data.Array.Vector import Data.Complex main = print . sumU $ replicateU (1000000000 :: Int) (1 :+ 1 ::Complex Double) Compiled with ghc 6.12, uvector-0.1.1.0 on a 64 bit linux box. The -fvia-C -optc-O3 is about 40% faster than -fasm. How does it fair with the new sse patches? I've attached the assembly below for each case.. -- Don ------------------------------------------------------------------------ Fastest. 2.17s. About 40% faster than -fasm $ time ./sum-complex 1.0e9 :+ 1.0e9 ./sum-complex 2.16s user 0.00s system 99% cpu 2.175 total Main_mainzuzdszdwfold_info: leaq 32(%r12), %rax movq %r12, %rdx cmpq 144(%r13), %rax movq %rax, %r12 ja .L4 cmpq $1000000000, %r14 je .L9 .L5: movsd .LC0(%rip), %xmm0 leaq 1(%r14), %r14 addsd %xmm0, %xmm5 addsd %xmm0, %xmm6 movq %rdx, %r12 jmp Main_mainzuzdszdwfold_info .L4: leaq -24(%rbp), %rax movq $32, 184(%r13) movq %rax, %rbp movq %r14, (%rax) movsd %xmm5, 8(%rax) movsd %xmm6, 16(%rax) movl $Main_mainzuzdszdwfold_closure, %ebx jmp *-8(%r13) .L9: movq $ghczmprim_GHCziTypes_Dzh_con_info, -24(%rax) movsd %xmm5, -16(%rax) movq $ghczmprim_GHCziTypes_Dzh_con_info, -8(%rax) leaq 25(%rdx), %rbx movsd %xmm6, 32(%rdx) leaq 9(%rdx), %r14 jmp *(%rbp) ------------------------------------------------------------------------ Second, 2.34s $ ghc-core sum-complex.hs -O2 -fvia-C -optc-O3 $ time ./sum-complex 1.0e9 :+ 1.0e9 ./sum-complex 2.33s user 0.01s system 99% cpu 2.347 total Main_mainzuzdszdwfold_info: leaq 32(%r12), %rax cmpq 144(%r13), %rax movq %r12, %rdx movq %rax, %r12 ja .L4 cmpq $100000000, %r14 je .L9 .L5: movsd .LC0(%rip), %xmm0 leaq 1(%r14), %r14 movq %rdx, %r12 addsd %xmm0, %xmm5 addsd %xmm0, %xmm6 jmp Main_mainzuzdszdwfold_info .L4: leaq -24(%rbp), %rax movq $32, 184(%r13) movl $Main_mainzuzdszdwfold_closure, %ebx movsd %xmm5, 8(%rax) movq %rax, %rbp movq %r14, (%rax) movsd %xmm6, 16(%rax) jmp *-8(%r13) .L9: movq $ghczmprim_GHCziTypes_Dzh_con_info, -24(%rax) movsd %xmm5, -16(%rax) movq $ghczmprim_GHCziTypes_Dzh_con_info, -8(%rax) leaq 25(%rdx), %rbx movsd %xmm6, 32(%rdx) leaq 9(%rdx), %r14 jmp *(%rbp) ------------------------------------------------------------------------ Native codegen, 3.57s ghc 6.12 -fasm -O2 $ time ./sum-complex 1.0e9 :+ 1.0e9 ./sum-complex 3.57s user 0.01s system 99% cpu 3.574 total Main_mainzuzdszdwfold_info: .Lc1i7: addq $32,%r12 cmpq 144(%r13),%r12 ja .Lc1ia movq %r14,%rax cmpq $100000000,%rax jne .Lc1id movq $ghczmprim_GHCziTypes_Dzh_con_info,-24(%r12) movsd %xmm5,-16(%r12) movq $ghczmprim_GHCziTypes_Dzh_con_info,-8(%r12) movsd %xmm6,(%r12) leaq -7(%r12),%rbx leaq -23(%r12),%r14 jmp *(%rbp) .Lc1ia: movq $32,184(%r13) movl $Main_mainzuzdszdwfold_closure,%ebx addq $-24,%rbp movq %r14,(%rbp) movsd %xmm5,8(%rbp) movsd %xmm6,16(%rbp) jmp *-8(%r13) .Lc1id: movsd %xmm6,%xmm0 addsd .Ln1if(%rip),%xmm0 movsd %xmm5,%xmm7 addsd .Ln1ig(%rip),%xmm7 leaq 1(%rax),%r14 movsd %xmm7,%xmm5 movsd %xmm0,%xmm6 addq $-32,%r12 jmp Main_mainzuzdszdwfold_info From daniel.is.fischer at web.de Mon Feb 15 15:20:57 2010 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Mon Feb 15 14:53:47 2010 Subject: Removing/deprecating -fvia-c In-Reply-To: <4B797863.1000409@gmail.com> References: <20100214165138.GA14278@matrix.chaos.earth.li> <20100214175835.GA31709@whirlpool.galois.com> <4B797863.1000409@gmail.com> Message-ID: <201002152120.58253.daniel.is.fischer@web.de> Am Montag 15 Februar 2010 17:37:55 schrieb Simon Marlow: > On 14/02/2010 17:58, Don Stewart wrote: > > igloo: > >> Hi all, > >> > >> We are planning to remove the -fvia-c way of compiling code > >> (unregisterised compilers will continue to compile via C only, but > >> registerised compilers will only use the native code generator). > >> We'll probably deprecate -fvia-c in the 6.14 branch, and remove it in > >> 6.16. > >> > >> Simon Marlow has recently fixed FP performance for modern x86 chips > >> in the native code generator in the HEAD. That was the last reason we > >> know of to prefer via-C to the native code generators. But before we > >> start the removal process, does anyone know of any other problems > >> with the native code generators that need to be fixed first? > > > > Do we have the blessing of the DPH team, wrt. tight, numeric inner > > loops? > > > > As recently as last year -fvia-C -optc-O3 was still useful for some > > microbenchmarks -- what's changed in that time, or is expected to > > change? > > If you have benchmarks that show a significant difference, I'd be > interested to see them. I have a benchmark (or a couple) from the Beginners mailing list two weeks ago (thread starting in January at http://www.haskell.org/pipermail/beginners/2010-January/003356.html and continued in February at http://www.haskell.org/pipermail/beginners/2010-February/003373.html ff) which show a significant difference. Loop.hs: ======================================== {-# LANGUAGE BangPatterns #-} module Main (main) where main :: IO () main = do putStrLn "EPS: " eps <- readLn :: IO Double let !mx = (4/eps) !pi14 = pisum mx putStrLn $ "PI mit EPS "++(show eps)++" = "++ show(4*pi14) pisum :: Double -> Double pisum cut = go True 1 0 where go b n s | cut < n = if b then s+1/(2*n) else s-1/(2*n) go True n !s = go False (n+2) (s+recip n) go False n !s = go True (n+2) (s-recip n) ======================================== $ echo '1e-8' | time ./Loop ghc -O2 --make: 4.53s ghc -O2 -fexcess-precision --make: 4.54s ghc -O2 -fvia-C -optc-O3 --make: 7.52s ghc -O2 -fvia-C -optc-O3 -optc-ffast-math --make: 7.53s ghc -O2 -fvia-C -optc-O3 -optc-ffast-math -optc-fno-float-store --make: 3.02s ghc -O2 -fvia-C -optc-O3 -optc-fno-float-store --make: 3.02s ghc -O2 -fexcess-precision -fvia-C -optc-O3 --make: 3.02s The loop coded in C and compiled with gcc -O3 [-ffast-math, -fno-float- store, -msse2 make no difference there] also takes 3.02s (gcc-4.3.2), 2.70s with icc -O3 (icc 11.0). It is probably worth pointing out, however, that on Markus B?hm's box running Windows XP, the native code generator produced better code than the via-C route (NCG code was faster there than on my box [openSUSE 11.1], while -O2 -fexcess-precision -fvia-C -optc-O3 on his box was slower than NCG on mine). Similar results for Fusion.hs (uses stream-fusion package) ======================================== module Main (main) where import qualified Data.List.Stream as S main :: IO () main = do putStrLn "EPS: " eps <- readLn :: IO Double let !mx = floor (4/eps) !k = (mx+1) `quot` 2 putStrLn $ "PI mit EPS " ++ (show eps) ++ " = " ++ show (leibniz k) leibniz n = (4 *) $ S.sum $ S.take n step step :: [Double] step = S.unfoldr phi (True,1) where ? phi (sig,d) | sig = Just (1/d, (False,d+2)) ? ? ? ? ? ? ? | otherwise ? = Just (negate (1/d), (True,d+2)) ======================================== ghc -O2 [-fexcess-precision] --make: 4.22s ghc -O2 -fexcess-precision -fvia-C -optc-O3 --make: 3.02s Using lists instead of loops, List.hs ======================================== module Main (main) where import Data.List (unfoldr) main :: IO () main = do ? ? putStrLn "EPS: " ? ? eps <- readLn :: IO Double ? ? let mx = floor (4/eps) ? ? ? ? !k = (mx+1) `quot` 2 ? ? putStrLn $ "PI mit EPS " ++ (show eps) ++ " = " ++ show (leibniz k) leibniz n = (4 *) $ sum $ take n step step :: [Double] step = unfoldr phi (True,1) where ?? phi (sig,d) | sig ? ? ? ? = Just (1/d, (False,d+2)) ?? ? ? ? ? ? ? | otherwise ? = Just (negate (1/d), (True,d+2)) ======================================== things are much slower, 23.60s vs. 18.15s, but the via-C route is again significantly faster. > > What I've done for 6.14.1 is to add the -msse2 flag to the x86 backend, > so where previously we had to use -fvia-C -fexcess-precision -optc-O3 > etc. to get reasonable floating point performance, now we can use -msse2 > with the native code gen and get about the same results. Can I test whether I get about the same results as with -fvia-C ... for the above? I.e., is it in the HEAD, and would I have to pass -msse2 on the command line or is it implied by -O2 already? > > In the future we have a couple of ways that things could get better: > > 1. The new back-end, which eventually will incorporate more > optimisations at the C-- level, and potentially could produce > good loop code. It will also free up some registers. > > 2. Compiling via LLVM. > > Dropping the C backend will give us more flexibility with calling > conventions, letting us use more of the x86 registers for passing > arguments. We can only make this change by removing -fvia-C, though. > There's low hanging fruit here particularly for the x86 backend, as soon > as we drop -fvia-C. > > There are other reasons to want to get rid of -fvia-C: > > - it doubles the testing surface > > - it's associated with a bucketload of grotesque Perl 4 code and > gcc-specific hacks in the RTS headers. > > Cheers, > Simon From dons at galois.com Mon Feb 15 16:49:14 2010 From: dons at galois.com (Don Stewart) Date: Mon Feb 15 16:20:07 2010 Subject: Removing/deprecating -fvia-c In-Reply-To: <20100215182920.GB3829@whirlpool.galois.com> References: <20100214165138.GA14278@matrix.chaos.earth.li> <20100214175835.GA31709@whirlpool.galois.com> <4B797863.1000409@gmail.com> <20100215182920.GB3829@whirlpool.galois.com> Message-ID: <20100215214914.GA4590@whirlpool.galois.com> dons: > marlowsd: > >>> > >>> Simon Marlow has recently fixed FP performance for modern x86 chips in > >>> the native code generator in the HEAD. That was the last reason we know > >>> of to prefer via-C to the native code generators. But before we start > >>> the removal process, does anyone know of any other problems with the > >>> native code generators that need to be fixed first? > >>> > >> > >> Do we have the blessing of the DPH team, wrt. tight, numeric inner loops? > >> > >> As recently as last year -fvia-C -optc-O3 was still useful for some > >> microbenchmarks -- what's changed in that time, or is expected to change? > > > > If you have benchmarks that show a significant difference, I'd be > > interested to see them. > > I've attached an example where there's a 40% variation (and it's a > floating point benchmark). Roman would be seeing similar examples in the > vector code. Here's an example that doesn't use floating point: import Data.Array.Vector import Data.Bits main = print . sumU $ zipWith3U (\x y z -> x * y * z) (enumFromToU 1 (100000000 :: Int)) (enumFromToU 2 (100000001 :: Int)) (enumFromToU 7 (100000008 :: Int)) In core: main_$s$wfold :: Int# -> Int# -> Int# -> Int# -> Int# main_$s$wfold = \ (sc_s1l1 :: Int#) (sc1_s1l2 :: Int#) (sc2_s1l3 :: Int#) (sc3_s1l4 :: Int#) -> case ># sc2_s1l3 100000000 of _ { False -> case ># sc1_s1l2 100000001 of _ { False -> case ># sc_s1l1 100000008 of _ { False -> main_$s$wfold (+# sc_s1l1 1) (+# sc1_s1l2 1) (+# sc2_s1l3 1) (+# sc3_s1l4 (*# (*# sc2_s1l3 sc1_s1l2) sc_s1l1)); True -> sc3_s1l4 }; True -> sc3_s1l4 }; True -> sc3_s1l4 } Rather nice! -fvia-C -optc-O3 Main_mainzuzdszdwfold_info: cmpq $100000000, %rdi jg .L6 cmpq $100000001, %rsi jg .L6 cmpq $100000008, %r14 jle .L10 .L6: movq %r8, %rbx movq (%rbp), %rax jmp *%rax .L10: movq %rsi, %r10 leaq 1(%rsi), %rsi imulq %rdi, %r10 leaq 1(%rdi), %rdi imulq %r14, %r10 leaq 1(%r14), %r14 leaq (%r10,%r8), %r8 jmp Main_mainzuzdszdwfold_info Which looks ok. $ time ./zipwith3 3541230156834269568 ./zipwith3 0.33s user 0.00s system 99% cpu 0.337 total And -fasm we get very different code, and a bit of a slowdown: Main_mainzuzdszdwfold_info: .Lc1mo: cmpq $100000000,%rdi jg .Lc1mq cmpq $100000001,%rsi jg .Lc1ms cmpq $100000008,%r14 jg .Lc1mv movq %rsi,%rax imulq %r14,%rax movq %rdi,%rcx imulq %rax,%rcx movq %r8,%rax addq %rcx,%rax leaq 1(%rdi),%rcx leaq 1(%rsi),%rdx incq %r14 movq %rdx,%rsi movq %rcx,%rdi movq %rax,%r8 jmp Main_mainzuzdszdwfold_info .Lc1mq: movq %r8,%rbx jmp *(%rbp) .Lc1ms: movq %r8,%rbx jmp *(%rbp) .Lc1mv: movq %r8,%rbx jmp *(%rbp) Slower: $ time ./zipwith3 3541230156834269568 ./zipwith3 0.38s user 0.00s system 98% cpu 0.384 total Now maybe we need to wait on the new backend optimizations to get there? -- Don From dons at galois.com Mon Feb 15 23:56:35 2010 From: dons at galois.com (Don Stewart) Date: Mon Feb 15 23:27:35 2010 Subject: Quasi quoting In-Reply-To: <4B6A9764.5090508@gmail.com> References: <59543203684B2244980D7E4057D5FBC10AFCDC5B@DB3EX14MBXC306.europe.corp.microsoft.com> <4ec472cb1002010920x1f889001jfca21fb46fcfe0b0@mail.gmail.com> <59543203684B2244980D7E4057D5FBC10AFCE28E@DB3EX14MBXC306.europe.corp.microsoft.com> <20100202183743.DD0D16017991C@labrador.cs.tufts.edu> <59543203684B2244980D7E4057D5FBC10AFCF52A@DB3EX14MBXC306.europe.corp.microsoft.com> <4B6A9764.5090508@gmail.com> Message-ID: <20100216045635.GK6020@whirlpool.galois.com> marlowsd: > On 03/02/2010 15:39, Simon Peyton-Jones wrote: >> |> Or we could switch to different quotation brackets altogether for >> |> quasiquotation, the obvious possibility being<|...blah...|>, and >> |> . That would not be hard, and would only affect the >> |> handful of current quasiquote users. But it'd remove "<|" and "|>" as a >> |> valid operators, at least for quasiquote customers. I don't know how bad >> |> that would be. >> | >> | Good brackets are scarce. I'd prefer to stick with one of the many >> | fine variations on [|...|] currently being discussed. >> >> I agree with this. My gut feel is to stick with [| ..|] and variants, and live with the fact that TH and QQ aren't using them in quite the same way. > > Why not provide some nice Unicode version too? ? .. ? ? .. ? ? .. ? etc. > OH! That looks very nice. From marlowsd at gmail.com Tue Feb 16 09:57:52 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Feb 16 09:29:04 2010 Subject: Removing/deprecating -fvia-c In-Reply-To: <20100215182920.GB3829@whirlpool.galois.com> References: <20100214165138.GA14278@matrix.chaos.earth.li> <20100214175835.GA31709@whirlpool.galois.com> <4B797863.1000409@gmail.com> <20100215182920.GB3829@whirlpool.galois.com> Message-ID: <4B7AB270.3070007@gmail.com> On 15/02/2010 18:29, Don Stewart wrote: > marlowsd: >>>> >>>> Simon Marlow has recently fixed FP performance for modern x86 chips in >>>> the native code generator in the HEAD. That was the last reason we know >>>> of to prefer via-C to the native code generators. But before we start >>>> the removal process, does anyone know of any other problems with the >>>> native code generators that need to be fixed first? >>>> >>> >>> Do we have the blessing of the DPH team, wrt. tight, numeric inner loops? >>> >>> As recently as last year -fvia-C -optc-O3 was still useful for some >>> microbenchmarks -- what's changed in that time, or is expected to change? >> >> If you have benchmarks that show a significant difference, I'd be >> interested to see them. > > I've attached an example where there's a 40% variation (and it's a > floating point benchmark). Roman would be seeing similar examples in the > vector code. > > I'm all in favor of dropping the C backend, but I'm also wary that we > don't have benchmarks to know what difference it is making. > > Here's a simple program testing a tight, floating point loop: > > import Data.Array.Vector > import Data.Complex > > main = print . sumU $ replicateU (1000000000 :: Int) (1 :+ 1 ::Complex Double) > > Compiled with ghc 6.12, uvector-0.1.1.0 on a 64 bit linux box. > > The -fvia-C -optc-O3 is about 40% faster than -fasm. > How does it fair with the new sse patches? > > I've attached the assembly below for each case.. > > -- Don > > > ------------------------------------------------------------------------ > > Fastest. 2.17s. About 40% faster than -fasm > > $ time ./sum-complex > 1.0e9 :+ 1.0e9 > ./sum-complex 2.16s user 0.00s system 99% cpu 2.175 total > > Main_mainzuzdszdwfold_info: > leaq 32(%r12), %rax > movq %r12, %rdx > cmpq 144(%r13), %rax > movq %rax, %r12 > ja .L4 > cmpq $1000000000, %r14 > je .L9 > .L5: > movsd .LC0(%rip), %xmm0 > leaq 1(%r14), %r14 > addsd %xmm0, %xmm5 > addsd %xmm0, %xmm6 > movq %rdx, %r12 > jmp Main_mainzuzdszdwfold_info > > .L4: > leaq -24(%rbp), %rax > movq $32, 184(%r13) > movq %rax, %rbp > movq %r14, (%rax) > movsd %xmm5, 8(%rax) > movsd %xmm6, 16(%rax) > movl $Main_mainzuzdszdwfold_closure, %ebx > jmp *-8(%r13) > .L9: > movq $ghczmprim_GHCziTypes_Dzh_con_info, -24(%rax) > movsd %xmm5, -16(%rax) > movq $ghczmprim_GHCziTypes_Dzh_con_info, -8(%rax) > leaq 25(%rdx), %rbx > movsd %xmm6, 32(%rdx) > leaq 9(%rdx), %r14 > jmp *(%rbp) > > ------------------------------------------------------------------------ > > Second, 2.34s > > $ ghc-core sum-complex.hs -O2 -fvia-C -optc-O3 > $ time ./sum-complex > 1.0e9 :+ 1.0e9 > ./sum-complex 2.33s user 0.01s system 99% cpu 2.347 total > > Main_mainzuzdszdwfold_info: > leaq 32(%r12), %rax > cmpq 144(%r13), %rax > movq %r12, %rdx > movq %rax, %r12 > ja .L4 > cmpq $100000000, %r14 > je .L9 > .L5: > movsd .LC0(%rip), %xmm0 > leaq 1(%r14), %r14 > movq %rdx, %r12 > addsd %xmm0, %xmm5 > addsd %xmm0, %xmm6 > jmp Main_mainzuzdszdwfold_info > > .L4: > leaq -24(%rbp), %rax > movq $32, 184(%r13) > movl $Main_mainzuzdszdwfold_closure, %ebx > movsd %xmm5, 8(%rax) > movq %rax, %rbp > movq %r14, (%rax) > movsd %xmm6, 16(%rax) > jmp *-8(%r13) > > .L9: > movq $ghczmprim_GHCziTypes_Dzh_con_info, -24(%rax) > movsd %xmm5, -16(%rax) > movq $ghczmprim_GHCziTypes_Dzh_con_info, -8(%rax) > leaq 25(%rdx), %rbx > movsd %xmm6, 32(%rdx) > leaq 9(%rdx), %r14 > jmp *(%rbp) > > ------------------------------------------------------------------------ > > Native codegen, 3.57s > > ghc 6.12 -fasm -O2 > $ time ./sum-complex > 1.0e9 :+ 1.0e9 > ./sum-complex 3.57s user 0.01s system 99% cpu 3.574 total > > > Main_mainzuzdszdwfold_info: > .Lc1i7: > addq $32,%r12 > cmpq 144(%r13),%r12 > ja .Lc1ia > movq %r14,%rax > cmpq $100000000,%rax > jne .Lc1id > movq $ghczmprim_GHCziTypes_Dzh_con_info,-24(%r12) > movsd %xmm5,-16(%r12) > movq $ghczmprim_GHCziTypes_Dzh_con_info,-8(%r12) > movsd %xmm6,(%r12) > leaq -7(%r12),%rbx > leaq -23(%r12),%r14 > jmp *(%rbp) > .Lc1ia: > movq $32,184(%r13) > movl $Main_mainzuzdszdwfold_closure,%ebx > addq $-24,%rbp > movq %r14,(%rbp) > movsd %xmm5,8(%rbp) > movsd %xmm6,16(%rbp) > jmp *-8(%r13) > .Lc1id: > movsd %xmm6,%xmm0 > addsd .Ln1if(%rip),%xmm0 > movsd %xmm5,%xmm7 > addsd .Ln1ig(%rip),%xmm7 > leaq 1(%rax),%r14 > movsd %xmm7,%xmm5 > movsd %xmm0,%xmm6 > addq $-32,%r12 > jmp Main_mainzuzdszdwfold_info > > I manged to improve this: Main_mainzuzdszdwfold_info: .Lc1lP: addq $32,%r12 cmpq 144(%r13),%r12 ja .Lc1lS movq %r14,%rax cmpq $1000000000,%rax jne .Lc1lV movq $ghczmprim_GHCziTypes_Dzh_con_info,-24(%r12) movsd %xmm6,-16(%r12) movq $ghczmprim_GHCziTypes_Dzh_con_info,-8(%r12) movsd %xmm5,(%r12) leaq -7(%r12),%rbx leaq -23(%r12),%r14 jmp *(%rbp) .Lc1lS: movq $32,184(%r13) movl $Main_mainzuzdszdwfold_closure,%ebx addq $-24,%rbp movsd %xmm5,(%rbp) movsd %xmm6,8(%rbp) movq %r14,16(%rbp) jmp *-8(%r13) .Lc1lV: addsd .Ln1m2(%rip),%xmm5 addsd .Ln1m3(%rip),%xmm6 leaq 1(%rax),%r14 addq $-32,%r12 jmp Main_mainzuzdszdwfold_info from 9 instructions in the last block down to 5 (one instruction fewer than gcc). I haven't commoned up the two constant 1's though, that'd mean doing some CSE. On my machine with GHC HEAD and gcc 4.3.0, the gcc version runs in 2.0s, with the NCG at 2.3s. I put the difference down to a bit of instruction scheduling done by gcc, and that extra constant load. But let's face it, all of this code is crappy. It should be a tiny little loop rather than a tail-call with argument passing, and that's what we'll get with the new backend (eventually). LLVM probably won't turn it into a loop on its own, that needs to be done before the code gets passed to LLVM. Have you looked at this example on x86? It's *far* worse and runs about 5 times slower. Cheers, Simon From dons at galois.com Tue Feb 16 12:51:06 2010 From: dons at galois.com (Don Stewart) Date: Tue Feb 16 12:22:00 2010 Subject: Removing/deprecating -fvia-c In-Reply-To: <4B7AB270.3070007@gmail.com> References: <20100214165138.GA14278@matrix.chaos.earth.li> <20100214175835.GA31709@whirlpool.galois.com> <4B797863.1000409@gmail.com> <20100215182920.GB3829@whirlpool.galois.com> <4B7AB270.3070007@gmail.com> Message-ID: <20100216175106.GF8891@whirlpool.galois.com> marlowsd: > > I manged to improve this: > > Main_mainzuzdszdwfold_info: > .Lc1lP: > addq $32,%r12 > cmpq 144(%r13),%r12 > ja .Lc1lS > movq %r14,%rax > cmpq $1000000000,%rax > jne .Lc1lV > movq $ghczmprim_GHCziTypes_Dzh_con_info,-24(%r12) > movsd %xmm6,-16(%r12) > movq $ghczmprim_GHCziTypes_Dzh_con_info,-8(%r12) > movsd %xmm5,(%r12) > leaq -7(%r12),%rbx > leaq -23(%r12),%r14 > jmp *(%rbp) > .Lc1lS: > movq $32,184(%r13) > movl $Main_mainzuzdszdwfold_closure,%ebx > addq $-24,%rbp > movsd %xmm5,(%rbp) > movsd %xmm6,8(%rbp) > movq %r14,16(%rbp) > jmp *-8(%r13) > .Lc1lV: > addsd .Ln1m2(%rip),%xmm5 > addsd .Ln1m3(%rip),%xmm6 > leaq 1(%rax),%r14 > addq $-32,%r12 > jmp Main_mainzuzdszdwfold_info > > > from 9 instructions in the last block down to 5 (one instruction fewer > than gcc). I haven't commoned up the two constant 1's though, that'd > mean doing some CSE. > > On my machine with GHC HEAD and gcc 4.3.0, the gcc version runs in 2.0s, > with the NCG at 2.3s. I put the difference down to a bit of instruction > scheduling done by gcc, and that extra constant load. > > But let's face it, all of this code is crappy. It should be a tiny > little loop rather than a tail-call with argument passing, and that's > what we'll get with the new backend (eventually). LLVM probably won't > turn it into a loop on its own, that needs to be done before the code > gets passed to LLVM. Agreed. Ideally the new backend would be (starting to be?) usable about the time -fvia-C dies? Otherwise there's always going to be something that gcc spots that the current codegen won't. Then again, killing perl from the ghc toolchain, and having a funeral/dancing on its grave, would be satisfying in itself :-) > Have you looked at this example on x86? It's *far* worse and runs about > 5 times slower. x86 scares me.. :) From bayer at cpw.math.columbia.edu Tue Feb 16 13:34:40 2010 From: bayer at cpw.math.columbia.edu (Dave Bayer) Date: Tue Feb 16 13:05:28 2010 Subject: Removing/deprecating -fvia-c In-Reply-To: <20100216175106.GF8891@whirlpool.galois.com> References: <20100214165138.GA14278@matrix.chaos.earth.li> <20100214175835.GA31709@whirlpool.galois.com> <4B797863.1000409@gmail.com> <20100215182920.GB3829@whirlpool.galois.com> <4B7AB270.3070007@gmail.com> <20100216175106.GF8891@whirlpool.galois.com> Message-ID: <3ACD1A2E-9843-46E6-86C0-F51558BB57E5@math.columbia.edu> On Feb 16, 2010, at 12:51 PM, Don Stewart wrote: > about the time -fvia-C dies? I wrote more lines of raw C code in my youth than I'd care to remember, before coming to the realization that the most important benchmark is "brain time" not "cpu time". With this revelation, there is no language like Haskell. Given the choice, I vote for dedicating our precious development resources to the future of Haskell, not the past of Perl and gcc. Worrying about what we lose is important, but I'd propose that we continue to benchmark the CURRENT version of GHC using -fvia-c against FUTURE versions of GHC, however it evolves. This doesn't sound fair, but that's my entire point. GHC will get better faster, the sooner that the development team can forget about supporting -fvia-c. From rl at cse.unsw.edu.au Tue Feb 16 20:13:03 2010 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Tue Feb 16 19:43:59 2010 Subject: Removing/deprecating -fvia-c In-Reply-To: <20100214175835.GA31709@whirlpool.galois.com> References: <20100214165138.GA14278@matrix.chaos.earth.li> <20100214175835.GA31709@whirlpool.galois.com> Message-ID: On 15/02/2010, at 04:58, Don Stewart wrote: > Do we have the blessing of the DPH team, wrt. tight, numeric inner loops? FWIW, I don't think we even use -fvia-C when benchmarking. In general, -fvia-C is a dead end wrt numeric performance because gcc just doesn't optimise well enough. So even if we generated code that gcc could optimise properly (which we don't atm), we still would be way behind highly optimising compilers like Intel's or Sun's. IMO, the LLVM backend is the way to go here. Roman From chak at cse.unsw.edu.au Tue Feb 16 22:16:48 2010 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Feb 16 21:47:48 2010 Subject: Removing/deprecating -fvia-c In-Reply-To: <4B7AB270.3070007@gmail.com> References: <20100214165138.GA14278@matrix.chaos.earth.li> <20100214175835.GA31709@whirlpool.galois.com> <4B797863.1000409@gmail.com> <20100215182920.GB3829@whirlpool.galois.com> <4B7AB270.3070007@gmail.com> Message-ID: Simon Marlow: > [..] > But let's face it, all of this code is crappy. It should be a tiny little loop rather than a tail-call with argument passing, and that's what we'll get with the new backend (eventually). LLVM probably won't turn it into a loop on its own, that needs to be done before the code gets passed to LLVM. I fully agree with Simon. There is no point in doctoring around with an inherently broken approach, and to waste developer cycles tracking changes to gcc and so forth. Gladly, we have two technologies ready (the new backend and LLVM) that have the potential to significantly improve the current situation. Let's spend developer cycles on these instead. Manuel From scooter.phd at gmail.com Tue Feb 16 22:26:08 2010 From: scooter.phd at gmail.com (scooter.phd@gmail.com) Date: Tue Feb 16 21:51:42 2010 Subject: Removing/deprecating -fvia-c Message-ID: <1689583928-1266376851-cardhu_decombobulator_blackberry.rim.net-1603850547-@bda916.bisx.prod.on.blackberry> It seems to me, in the absence of any other fallback, that the C backend should stay around. Assume that one is porting to a new platform, the C backend at least gives one code from which to bootstrap. Calling convention handling: weak argument IMHO for ditching. Sounds like refactoring is required, and, yes, it's platform-specific. Perl script postprocessing foo: I haven't looked at the code, but again, it sounds like platform-specific refactoring. Yes, I've looked at the web page. There's a reason why backends are messy goo and have target triples, etc. It's like Monad: not everything is pure. My vote is to keep the C backend. If it's good enough for LLVM, it's probably good enough for GHC. -scooter ------Original Message------ From: Don Stewart Sender: glasgow-haskell-users-bounces@haskell.org To: glasgow-haskell-users@haskell.org Subject: Re: Removing/deprecating -fvia-c Sent: Feb 14, 2010 09:58 igloo: > > Hi all, > > We are planning to remove the -fvia-c way of compiling code > (unregisterised compilers will continue to compile via C only, but > registerised compilers will only use the native code generator). > We'll probably deprecate -fvia-c in the 6.14 branch, and remove it in > 6.16. > > Simon Marlow has recently fixed FP performance for modern x86 chips in > the native code generator in the HEAD. That was the last reason we know > of to prefer via-C to the native code generators. But before we start > the removal process, does anyone know of any other problems with the > native code generators that need to be fixed first? > Do we have the blessing of the DPH team, wrt. tight, numeric inner loops? As recently as last year -fvia-C -optc-O3 was still useful for some microbenchmarks -- what's changed in that time, or is expected to change? -- Don _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users Sent from my Verizon Wireless BlackBerry From scooter.phd at gmail.com Tue Feb 16 22:35:26 2010 From: scooter.phd at gmail.com (scooter.phd@gmail.com) Date: Tue Feb 16 22:00:47 2010 Subject: Removing/deprecating -fvia-c In-Reply-To: <1689583928-1266376851-cardhu_blackberry.rim.net-copy_sent_folder-1683968753-@bda916.bisx.prod.on.blackberry> References: <1689583928-1266376851-cardhu_blackberry.rim.net-copy_sent_folder-1683968753-@bda916.bisx.prod.on.blackberry> Message-ID: <730183783-1266377395-cardhu_decombobulator_blackberry.rim.net-2088753153-@bda916.bisx.prod.on.blackberry> Before the "Pile on Scooter" fest starts, bear in mind that LLVM effectively restricts you to its current backends. As the guy who started CellSPU in LLVM and who needs a good couple of research months off to finish it, think this through. Carefully. FWIW: I lead a computer systems research department for a non-for-profit in real life. Sent from my Verizon Wireless BlackBerry -----Original Message----- From: scooter.phd@gmail.com Date: Wed, 17 Feb 2010 03:26:08 To: Don Stewart; Subject: Re: Removing/deprecating -fvia-c It seems to me, in the absence of any other fallback, that the C backend should stay around. Assume that one is porting to a new platform, the C backend at least gives one code from which to bootstrap. Calling convention handling: weak argument IMHO for ditching. Sounds like refactoring is required, and, yes, it's platform-specific. Perl script postprocessing foo: I haven't looked at the code, but again, it sounds like platform-specific refactoring. Yes, I've looked at the web page. There's a reason why backends are messy goo and have target triples, etc. It's like Monad: not everything is pure. My vote is to keep the C backend. If it's good enough for LLVM, it's probably good enough for GHC. -scooter ------Original Message------ From: Don Stewart Sender: glasgow-haskell-users-bounces@haskell.org To: glasgow-haskell-users@haskell.org Subject: Re: Removing/deprecating -fvia-c Sent: Feb 14, 2010 09:58 igloo: > > Hi all, > > We are planning to remove the -fvia-c way of compiling code > (unregisterised compilers will continue to compile via C only, but > registerised compilers will only use the native code generator). > We'll probably deprecate -fvia-c in the 6.14 branch, and remove it in > 6.16. > > Simon Marlow has recently fixed FP performance for modern x86 chips in > the native code generator in the HEAD. That was the last reason we know > of to prefer via-C to the native code generators. But before we start > the removal process, does anyone know of any other problems with the > native code generators that need to be fixed first? > Do we have the blessing of the DPH team, wrt. tight, numeric inner loops? As recently as last year -fvia-C -optc-O3 was still useful for some microbenchmarks -- what's changed in that time, or is expected to change? -- Don _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users Sent from my Verizon Wireless BlackBerry From dons at galois.com Wed Feb 17 02:28:29 2010 From: dons at galois.com (Don Stewart) Date: Wed Feb 17 01:59:19 2010 Subject: Removing/deprecating -fvia-c In-Reply-To: <730183783-1266377395-cardhu_decombobulator_blackberry.rim.net-2088753153-@bda916.bisx.prod.on.blackberry> References: <1689583928-1266376851-cardhu_blackberry.rim.net-copy_sent_folder-1683968753-@bda916.bisx.prod.on.blackberry> <730183783-1266377395-cardhu_decombobulator_blackberry.rim.net-2088753153-@bda916.bisx.prod.on.blackberry> Message-ID: <20100217072829.GE11557@whirlpool.galois.com> That's a good perspective, Scooter. Let's not mythologize LLVM. Note that Simon's proposing to keep the unregisterized C backend for bootstrapping, but to avoid further work on the optimizing C backend (GCC + tailcalls + the evil mangler + lots of register hacks). The question is whether the current native codegen, plus the unregistered C "bootstrap backend" is enough for everyone -- and it may well be, esp. if work will proceed on a new native codegen. scooter.phd: > Before the "Pile on Scooter" fest starts, bear in mind that LLVM > effectively restricts you to its current backends. As the guy who > started CellSPU in LLVM and who needs a good couple of research months > off to finish it, think this through. Carefully. > > FWIW: I lead a computer systems research department for a > non-for-profit in real life. > Sent from my Verizon Wireless BlackBerry > > -----Original Message----- > From: scooter.phd@gmail.com > Date: Wed, 17 Feb 2010 03:26:08 > To: Don Stewart; > Subject: Re: Removing/deprecating -fvia-c > > It seems to me, in the absence of any other fallback, that the C > backend should stay around. Assume that one is porting to a new > platform, the C backend at least gives one code from which to > bootstrap. > > Calling convention handling: weak argument IMHO for ditching. Sounds > like refactoring is required, and, yes, it's platform-specific. > > Perl script postprocessing foo: I haven't looked at the code, but > again, it sounds like platform-specific refactoring. Yes, I've looked > at the web page. > > There's a reason why backends are messy goo and have target triples, > etc. It's like Monad: not everything is pure. > > My vote is to keep the C backend. If it's good enough for LLVM, it's > probably good enough for GHC. > > > -scooter > ------Original Message------ > From: Don Stewart > Sender: glasgow-haskell-users-bounces@haskell.org > To: glasgow-haskell-users@haskell.org > Subject: Re: Removing/deprecating -fvia-c > Sent: Feb 14, 2010 09:58 > > igloo: > > > > Hi all, > > > > We are planning to remove the -fvia-c way of compiling code > > (unregisterised compilers will continue to compile via C only, but > > registerised compilers will only use the native code generator). > > We'll probably deprecate -fvia-c in the 6.14 branch, and remove it in > > 6.16. > > > > Simon Marlow has recently fixed FP performance for modern x86 chips in > > the native code generator in the HEAD. That was the last reason we know > > of to prefer via-C to the native code generators. But before we start > > the removal process, does anyone know of any other problems with the > > native code generators that need to be fixed first? > > > > Do we have the blessing of the DPH team, wrt. tight, numeric inner loops? > > As recently as last year -fvia-C -optc-O3 was still useful for some > microbenchmarks -- what's changed in that time, or is expected to change? > > -- Don > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > Sent from my Verizon Wireless BlackBerry > From ml at isaac.cedarswampstudios.org Wed Feb 17 02:37:01 2010 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Wed Feb 17 02:07:45 2010 Subject: Removing/deprecating -fvia-c In-Reply-To: References: <20100214165138.GA14278@matrix.chaos.earth.li> <20100214175835.GA31709@whirlpool.galois.com> Message-ID: <4B7B9C9D.2040200@isaac.cedarswampstudios.org> On 02/16/10 20:13, Roman Leshchinskiy wrote: > On 15/02/2010, at 04:58, Don Stewart wrote: > >> Do we have the blessing of the DPH team, wrt. tight, numeric inner loops? > > FWIW, I don't think we even use -fvia-C when benchmarking. In general, -fvia-C is a dead end wrt numeric performance because gcc just doesn't optimise well enough. So even if we generated code that gcc could optimise properly (which we don't atm), we still would be way behind highly optimising compilers like Intel's or Sun's. IMO, the LLVM backend is the way to go here. LLVM and GCC are open-source projects that are improving over time... is there any particular reason we expect GCC to have poor numeric performance forever? [now I rehash why to remove -fvia-C anyway. Feel free to ignore me.] ...However, we think the native-code backends (and perhaps LLVM) will be good enough within the next few years to catch up with registerized via-C; and as soon as they do, it'll be an advantage to remove -fvia-C so that we're not restricted by C's calling conventions and other such restrictions. And it's much easier to predict GCC's path for just the next two years (for example). Actually, even if GCC somehow becomes the premier optimizer that we'll never be able to replicate with our own feeble efforts, it still may not be worth keeping/using/maintaining the current perl hacks for that purpose (combining the effort needed to maintain them over the time until then, and the effort needed to adapt these hacks to C with loops that let GCC optimize better... er, it probably won't be *that much* better except in things simple enough that it's easier to add optimizations inside GHC than to maintain this backend anyway). scooter.phd wrote: > Before the "Pile on Scooter" fest starts, bear in mind that LLVM effectively restricts you to its current backends. As the guy who started CellSPU in LLVM and who needs a good couple of research months off to finish it, think this through. Carefully. Currently we have - "unregisterized", using GCC. This is the most portable, fairly reliable, and will stay. - "registerized" (fvia-C), using GCC. This tends to break (e.g. registerized PowerPC is broken) - -fasm (native code generator). This can break from refactoring in GHC but not from new versions of GCC, so it is less annoying than the -fvia-C path. And we'll hopefully have - LLVM backend, with (currently) fewer supported architectures than GCC but more than GHC's native-codegens. If you finish your CellSPU work, great! GHC 6.16 or so might be able to perform well on CellSPU! If not, then the present situation of using the "unregisterized" (slow) C backend will still be available; we don't lose much by removing the few current "registerized" backends. (Actually it's likely to require some build-system fixes in porting to any new platform, even with the unregisterized backend.) (Also, if it turns out to be easier to make a GHC native-code generator backend than an LLVM backend, then maybe that will be yet another theoretical possibility!) -Isaac From marlowsd at gmail.com Wed Feb 17 04:24:40 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Feb 17 03:55:31 2010 Subject: ghc rts selection and third party libraries In-Reply-To: References: <4B66C25A.5040407@gmail.com> Message-ID: <4B7BB5D8.6070500@gmail.com> On 01/02/10 13:36, John Lask wrote: > I understand these are internals of ghc and subject to change. The > reason for their use: to support asynchronous interrupts safe with > respect to the Haskell code that is being interrupted. To my knowledge > (please correct me if I am wrong) there is no way to do this other than > the following alternatives and the already mentioned functions. > > As an example, suppose I want to provide a call back to a win32 OS hook > which takes a c-call-back routine. My understanding is that I cannot use > a wrapped Haskell call-back routine as there are no guarantees what > state the Haskell rts will be in when the routine is called. It's not clear to me that this wouldn't work. I believe it would be perfectly safe for the Win32 console handler callback to invoke Haskell functions, because the handler is executed in a separate thread, unlike Unix signals which happen in the context of one of the existing threads (which is why you can't use any inter-thread communication or synchronisation in a Unix signal handler). > At least initially I have used the above mentioned functions to support > win32 signal handling, as the ghc rts just catches (and dispatches) > console events, which do not encompass all the (rather limited) c-rts > signals. > > The obvious solution is to provide a c call-back routine, use an WIN32 > event object, use a Haskell bound thread to wait on that event. > > another alternative would be to poll. > > The first alternative requires threaded rts which for various reasons I > don't wish to use under all circumstances, the other alternative is > inefficient or unresponsive. > > Discussion of either of these alternatives distract from the question > "shouldn't there be a method for asynchronous call-back that is safe > with respect to the Haskell rts state"? > > But there already exists such a method, that of the backdoor already > mentioned, really, all that is required is for this to become more > formalised and a single api adopted that is usable from c and consistent > across threaded and un-threaded rts, but in the mean time the existing > structure is quite usable for this purpose aside from the cumbersome > libraries issue. > > And the reason for this libraries issue is that the methods exposed by > the ghc-runtime to collect and post events into the ghc runtime system > differ between the threaded and non-threaded runtimes, which is why > short of changing ghc rts myself I can't avoid it (or adopting either of > the above alternatives) > > As the facility (to capture arbitrary asynchronous interrupts) is > generally useful I believe it to be advantageous to address it rather > than side-stepping it. You might want to look at the work that Bryan O'Sullivan and Johan Tibell are doing on a new IO manager: http://github.com/bos/event/ There's no Win32 support yet, but it's designed to allow multiple backends. Cheers, Simon From rl at cse.unsw.edu.au Wed Feb 17 09:03:23 2010 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Wed Feb 17 08:34:20 2010 Subject: Removing/deprecating -fvia-c In-Reply-To: <4B7B9C9D.2040200@isaac.cedarswampstudios.org> References: <20100214165138.GA14278@matrix.chaos.earth.li> <20100214175835.GA31709@whirlpool.galois.com> <4B7B9C9D.2040200@isaac.cedarswampstudios.org> Message-ID: On 17/02/2010, at 18:37, Isaac Dupree wrote: > LLVM and GCC are open-source projects that are improving over time... is there any particular reason we expect GCC to have poor numeric performance forever? Past experience :-) GCC has been around for a while and if it doesn't optimise numeric code well by now, there is no reason to believe that it ever will. Roman From marlowsd at gmail.com Wed Feb 17 09:19:33 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Feb 17 08:50:26 2010 Subject: Removing/deprecating -fvia-c In-Reply-To: <4B7B9C9D.2040200@isaac.cedarswampstudios.org> References: <20100214165138.GA14278@matrix.chaos.earth.li> <20100214175835.GA31709@whirlpool.galois.com> <4B7B9C9D.2040200@isaac.cedarswampstudios.org> Message-ID: <4B7BFAF5.9040104@gmail.com> On 17/02/10 07:37, Isaac Dupree wrote: > On 02/16/10 20:13, Roman Leshchinskiy wrote: >> On 15/02/2010, at 04:58, Don Stewart wrote: >> >>> Do we have the blessing of the DPH team, wrt. tight, numeric inner >>> loops? >> >> FWIW, I don't think we even use -fvia-C when benchmarking. In general, >> -fvia-C is a dead end wrt numeric performance because gcc just doesn't >> optimise well enough. So even if we generated code that gcc could >> optimise properly (which we don't atm), we still would be way behind >> highly optimising compilers like Intel's or Sun's. IMO, the LLVM >> backend is the way to go here. > > LLVM and GCC are open-source projects that are improving over time... is > there any particular reason we expect GCC to have poor numeric > performance forever? The problem is not the quality of the code generator in gcc vs. LLVM; indeed gcc is generally regarded as generating better code than LLVM right now, although LLVM is improving. The reason that using gcc is worse than LLVM for us in that when GHC uses gcc as a backend it generates C, whereas the LLVM backend generates code directly from GHC's internal C-- representation. Compiling via C is a tricky business that ultimately leads to not being able to generate as good code as you want(*). It would be entirely possible to hook into gcc's backend directly from GHC as an alternative to the LLVM backend, though LLVM is really intended to be used this way and has a more polished API. Even so, LLVM doesn't let us generate exactly the code we'd like: we can't use GHC's tables-next-to-code optimisation. Measurements done by David Terei who built the LLVM backend apparently show that this doesn't matter much (~3% slower IIRC), though I'm still surprised that all those extra indirections don't have more of an effect, I think we need to investigate this more closely. It's important because if the LLVM backend is to be a compile-time option, we have to either drop tables-next-to-code, or wait until LLVM supports generating code in that style. (*) Though the main reason for this is the need to keep accurate GC information; if you're prepared to forego that (as in JHC) then you can generate much more optimisable C code. > [now I rehash why to remove -fvia-C anyway. Feel free to ignore me.] > > ...However, we think the native-code backends (and perhaps LLVM) will be > good enough within the next few years to catch up with registerized > via-C; I should point out that for most Haskell programs, the NCG is already as fast (in some cases faster) than via C. The benchmarks showing a difference are all of the small tight loop kind - which are important to some people, I don't dispute that, but I expect that most people wouldn't notice the difference. Cheers, Simon From daniel.is.fischer at web.de Wed Feb 17 10:39:07 2010 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Wed Feb 17 10:11:53 2010 Subject: Removing/deprecating -fvia-c In-Reply-To: <4B7BFAF5.9040104@gmail.com> References: <20100214165138.GA14278@matrix.chaos.earth.li> <4B7B9C9D.2040200@isaac.cedarswampstudios.org> <4B7BFAF5.9040104@gmail.com> Message-ID: <201002171639.07531.daniel.is.fischer@web.de> Am Mittwoch 17 Februar 2010 15:19:33 schrieb Simon Marlow: > I should point out that for most Haskell programs, the NCG is already as > fast (in some cases faster) than via C. ?The benchmarks showing a > difference are all of the small tight loop kind - which are important to > some people, I don't dispute that, but I expect that most people > wouldn't notice the difference. Probably. And where the tight loop takes a significant amount of the running time, one can usually write that in C and use the FFI if the NCG doesn't produce comparable code. Granted, it's not as nice, but removing the via-C route won't be a show-stopper for those loops either, I think. > > Cheers, > ????????Simon From scooter.phd at gmail.com Wed Feb 17 16:15:56 2010 From: scooter.phd at gmail.com (Scott Michel) Date: Wed Feb 17 15:46:42 2010 Subject: Removing/deprecating -fvia-c In-Reply-To: <4B7BFAF5.9040104@gmail.com> References: <20100214165138.GA14278@matrix.chaos.earth.li> <20100214175835.GA31709@whirlpool.galois.com> <4B7B9C9D.2040200@isaac.cedarswampstudios.org> <4B7BFAF5.9040104@gmail.com> Message-ID: <258cd3201002171315g27ecac00na5b2ba7e79d6cc6a@mail.gmail.com> On Wed, Feb 17, 2010 at 6:19 AM, Simon Marlow wrote: > On 17/02/10 07:37, Isaac Dupree wrote: > >> On 02/16/10 20:13, Roman Leshchinskiy wrote: >> >>> On 15/02/2010, at 04:58, Don Stewart wrote: >>> >>> Do we have the blessing of the DPH team, wrt. tight, numeric inner >>>> loops? >>>> >>> >>> FWIW, I don't think we even use -fvia-C when benchmarking. In general, >>> -fvia-C is a dead end wrt numeric performance because gcc just doesn't >>> optimise well enough. So even if we generated code that gcc could >>> optimise properly (which we don't atm), we still would be way behind >>> highly optimising compilers like Intel's or Sun's. IMO, the LLVM >>> backend is the way to go here. >>> >> >> LLVM and GCC are open-source projects that are improving over time... is >> there any particular reason we expect GCC to have poor numeric >> performance forever? >> > > The problem is not the quality of the code generator in gcc vs. LLVM; > indeed gcc is generally regarded as generating better code than LLVM right > now, although LLVM is improving. > Depends a lot on the benchmark. The FreeBSD kernel dev crowd (one of whom works for me) have seen performance improvements between 10-20% using LLVM and clang over gcc. It also depends heavily on which optimization passes you have LLVM invoke -- bear in mind that LLVM is a compiler optimization infrastructure first and foremost. The reason that using gcc is worse than LLVM for us in that when GHC uses > gcc as a backend it generates C, whereas the LLVM backend generates code > directly from GHC's internal C-- representation. Compiling via C is a > tricky business that ultimately leads to not being able to generate as good > code as you want(*). It would be entirely possible to hook into gcc's > backend directly from GHC as an alternative to the LLVM backend, though LLVM > is really intended to be used this way and has a more polished API. > Let's be a bit more specific: you can directly generate the LLVM intermediate representation (IR) and pass that off to the LLVM optimization passes. With gcc, you generate C code that then is processed by gcc command line interface. I wouldn't suggest hooking into gcc's anything. LLVM is much cleaner. > Even so, LLVM doesn't let us generate exactly the code we'd like: we can't > use GHC's tables-next-to-code optimisation. Measurements done by David Terei > who built the LLVM backend apparently show that this doesn't matter much > (~3% slower IIRC), though I'm still surprised that all those extra > indirections don't have more of an effect, I think we need to investigate > this more closely. It's important because if the LLVM backend is to be a > compile-time option, we have to either drop tables-next-to-code, or wait > until LLVM supports generating code in that style. > This sounds like an impedance mismatch between GHC's concept of IR and LLVM's. There's also the danger of trying to prematurely optimize LLVM as if it were a native backend rather than separating GHC and Haskell language-specific optimizations from LLVM's optimizations. Like thinking you can do your own register allocation better than LLVM, for example, is a common one that I've seen. Just don't -- value tracing through SSA is what LLVM is spectacularly good at. Use as many temporary variables as you like; LLVM will eventually eliminate them. All that said, if LLVM were to replace GHC's native backends, then one could shift focus to engineering the IR impedance mismatch. [disclaimer: grain of salt speculation, haven't read the code] Tables-next-to-code has an obvious cache-friendliness property, BTW. Generally, there's going to be some instruction prefetch into the cache. This is likely why it's faster. Otherwise, you have to warm up the data cache, since LLVM spills the tables into the target's constant pool. (*) Though the main reason for this is the need to keep accurate GC > information; if you're prepared to forego that (as in JHC) then you can > generate much more optimisable C code. > > > [now I rehash why to remove -fvia-C anyway. Feel free to ignore me.] >> >> ...However, we think the native-code backends (and perhaps LLVM) will be >> good enough within the next few years to catch up with registerized >> via-C; >> > > I should point out that for most Haskell programs, the NCG is already as > fast (in some cases faster) than via C. The benchmarks showing a difference > are all of the small tight loop kind - which are important to some people, I > don't dispute that, but I expect that most people wouldn't notice the > difference. > NCGs should be faster than plain old C. Trying to produce optimized C is the fool's errand, and I'm starting to agree with dropping that. My worry was that the C backend would be dropped in its entirety, also a fool's errand. -scooter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100217/5cd08cac/attachment.html From scooter.phd at gmail.com Wed Feb 17 16:24:22 2010 From: scooter.phd at gmail.com (Scott Michel) Date: Wed Feb 17 15:55:11 2010 Subject: Removing/deprecating -fvia-c In-Reply-To: <4B7B9C9D.2040200@isaac.cedarswampstudios.org> References: <20100214165138.GA14278@matrix.chaos.earth.li> <20100214175835.GA31709@whirlpool.galois.com> <4B7B9C9D.2040200@isaac.cedarswampstudios.org> Message-ID: <258cd3201002171324w1aec6d44m7b3de05d3b154670@mail.gmail.com> On Tue, Feb 16, 2010 at 11:37 PM, Isaac Dupree < ml@isaac.cedarswampstudios.org> wrote: > If you finish your CellSPU work, great! GHC 6.16 or so might be able to > perform well on CellSPU! If not, then the present situation of using the > "unregisterized" (slow) C backend will still be available; we don't lose > much by removing the few current "registerized" backends. (Actually it's > likely to require some build-system fixes in porting to any new platform, > even with the unregisterized backend.) (Also, if it turns out to be easier > to make a GHC native-code generator backend than an LLVM backend, then maybe > that will be yet another theoretical possibility!) I might be able to get to it, but the odds are low for two reasons. First, IBM has effectively stopped all development on future Cell hardware (if lack of Cell demos at Supercomputing are a good indication, plus no new IBM Cell hardware for two years and Sony looking for a new processor for the PlayStation 4.) Second, functional programming and hybrid multicore is not well understood. Sure, progress is being made on functional programming on GPUs for specific kinds of problems -- but GPUs are fundamentally a data stream model of programming. Cell is a very different hybrid multicore model that isn't entirely data stream, but has some of its characteristics, with a lot of physical limitations. A better bet would be to target a tiled array processor, such as the Tilera Tile64 (aka MIT RAW). -scooter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100217/f837ea5a/attachment.html From garious at gmail.com Wed Feb 17 19:04:16 2010 From: garious at gmail.com (Greg Fitzgerald) Date: Wed Feb 17 18:35:21 2010 Subject: Confusion about GHC and GMP In-Reply-To: <20100213150113.GA9313@matrix.chaos.earth.li> References: <1f3dc80d1002121317o39a761cese20e3862448834ea@mail.gmail.com> <20100213150113.GA9313@matrix.chaos.earth.li> Message-ID: <1f3dc80d1002171604j30fbf22ewae4ea41de16dc669@mail.gmail.com> > I assume you mean > http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes#CurrentStatus > in which case, yes. > >> I assume that "INTEGER_LIBRARY=integer-foo" is an option when >> compiling GHC itself and not when using GHC, correct? > > Yes. Great, thanks for your help Ian. Building GHC with "INTEGER_LIBRARY=integer-simple" is exactly what I was looking for. So naturally though, I'd like to avoid maintaining an internal branch of GHC. Are there any plans to make integer-simple the default integer library? I was able to build GHC on Linux with no trouble. But on Windows, I go down because (I think) the preprocessor is choking on ^M characters. I get errors like this: libraries\haskeline\.\System\Console\Haskeline\Backend\Win32.hsc:153: error: syntax error before ')' token libraries\haskeline\.\System\Console\Haskeline\Backend\Win32.hsc: In function `main': libraries\haskeline\.\System\Console\Haskeline\Backend\Win32.hsc:155: error: syntax error before ';' token compiling libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32_hsc_make.c After removing those ^M's from Win32.hsc and Win32_hsc_make.c, things are moving along, slowly but surely. The build is using the "inplace" gcc so I assume the problem is not gcc, but whatever generates those files. Any idea how the extra line feeds slip in? Thanks, Greg From davidterei at gmail.com Thu Feb 18 04:09:31 2010 From: davidterei at gmail.com (David Terei) Date: Thu Feb 18 03:40:20 2010 Subject: Removing/deprecating -fvia-c In-Reply-To: <4B7D0285.90305@gmail.com> References: <20100214165138.GA14278@matrix.chaos.earth.li> <20100214175835.GA31709@whirlpool.galois.com> <4B797863.1000409@gmail.com> <20100215182920.GB3829@whirlpool.galois.com> <20100215214914.GA4590@whirlpool.galois.com> <4B7D0285.90305@gmail.com> Message-ID: <4B7D03CB.1030005@gmail.com> Don Stewart wrote: > Here's an example that doesn't use floating point: > > import Data.Array.Vector > import Data.Bits > > main = print . sumU $ zipWith3U (\x y z -> x * y * z) > (enumFromToU 1 (100000000 :: Int)) > (enumFromToU 2 (100000001 :: Int)) > (enumFromToU 7 (100000008 :: Int)) > > In core: > > main_$s$wfold :: Int# -> Int# -> Int# -> Int# -> Int# > main_$s$wfold = > \ (sc_s1l1 :: Int#) > (sc1_s1l2 :: Int#) > (sc2_s1l3 :: Int#) > (sc3_s1l4 :: Int#) -> > case># sc2_s1l3 100000000 of _ { > False -> > case># sc1_s1l2 100000001 of _ { > False -> > case># sc_s1l1 100000008 of _ { > False -> > main_$s$wfold > (+# sc_s1l1 1) > (+# sc1_s1l2 1) > (+# sc2_s1l3 1) > (+# > sc3_s1l4 (*# (*# sc2_s1l3 sc1_s1l2) sc_s1l1)); > True -> sc3_s1l4 > }; > True -> sc3_s1l4 > }; > True -> sc3_s1l4 > } > > Rather nice! > > -fvia-C -optc-O3 > > Main_mainzuzdszdwfold_info: > cmpq $100000000, %rdi > jg .L6 > cmpq $100000001, %rsi > jg .L6 > cmpq $100000008, %r14 > jle .L10 > .L6: > movq %r8, %rbx > movq (%rbp), %rax > jmp *%rax > .L10: > movq %rsi, %r10 > leaq 1(%rsi), %rsi > imulq %rdi, %r10 > leaq 1(%rdi), %rdi > imulq %r14, %r10 > leaq 1(%r14), %r14 > leaq (%r10,%r8), %r8 > jmp Main_mainzuzdszdwfold_info > > Which looks ok. > > $ time ./zipwith3 > 3541230156834269568 > ./zipwith3 0.33s user 0.00s system 99% cpu 0.337 total > > And -fasm we get very different code, and a bit of a slowdown: > > Main_mainzuzdszdwfold_info: > .Lc1mo: > cmpq $100000000,%rdi > jg .Lc1mq > cmpq $100000001,%rsi > jg .Lc1ms > cmpq $100000008,%r14 > jg .Lc1mv > > movq %rsi,%rax > imulq %r14,%rax > movq %rdi,%rcx > imulq %rax,%rcx > movq %r8,%rax > addq %rcx,%rax > leaq 1(%rdi),%rcx > leaq 1(%rsi),%rdx > incq %r14 > movq %rdx,%rsi > movq %rcx,%rdi > movq %rax,%r8 > jmp Main_mainzuzdszdwfold_info > > .Lc1mq: > movq %r8,%rbx > jmp *(%rbp) > .Lc1ms: > movq %r8,%rbx > jmp *(%rbp) > .Lc1mv: > movq %r8,%rbx > jmp *(%rbp) > > Slower: > > $ time ./zipwith3 > 3541230156834269568 > ./zipwith3 0.38s user 0.00s system 98% cpu 0.384 total > > Now maybe we need to wait on the new backend optimizations to get there? I've been looking at some of these cases and seeing how the LLVM back-end performs. My general impression from benchmarking the LLVM back-end in the past has been that it generally performs with similar characteristics as the C code generator (that is, where the C code generator stood out compared to the NCG, so did LLVM). (On x86-32/Mac OS X 10.5, had some issues getting x64 working at moment): ./zipWith3_viac 0.72s ./zipWith3_fasm 0.65s ./zipWith3_llvm 0.38s Code that LLVM produces: _Main_mainzuzdszdwfold_entry: ## BB#0: ## %c1qP subl $12, %esp jmp LBB2_1 .align 4, 0x90 LBB2_4: ## %n1re ## Loop Depth 1 ## Loop Header is BB2_1 ## Inner Loop movl %ecx, %esi incl %ecx imull %eax, %esi incl %eax imull %edx, %esi incl %edx addl (%ebp), %esi movl %edx, 12(%ebp) movl %ecx, 8(%ebp) movl %eax, 4(%ebp) movl %esi, (%ebp) LBB2_1: ## %tailrecurse ## Loop Depth 1 ## Loop Header ## Inner Loop movl 4(%ebp), %eax cmpl $100000000, %eax jg LBB2_5 ## BB#2: ## %n1qX ## Loop Depth 1 ## Loop Header is BB2_1 ## Inner Loop movl 8(%ebp), %ecx cmpl $100000001, %ecx jg LBB2_5 ## BB#3: ## %n1r5 ## Loop Depth 1 ## Loop Header is BB2_1 ## Inner Loop movl 12(%ebp), %edx cmpl $100000008, %edx jle LBB2_4 LBB2_5: ## %c1qW movl 16(%ebp), %eax movl (%ebp), %esi addl $16, %ebp movl (%eax), %eax addl $12, %esp jmpl *%eax # TAILCALL Which is very nice. (The comments in the code are inserted by LLVM, not me). I also ran through some of the programs outlined here: http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/18151 All ran with 'echo '1e-8' | ./$PRG'. Loop.hs: ======================================== {-# LANGUAGE BangPatterns #-} module Main (main) where main :: IO () main = do putStrLn "EPS: " eps <- readLn :: IO Double let !mx = (4/eps) !pi14 = pisum mx putStrLn $ "PI mit EPS "++(show eps)++" = "++ show(4*pi14) pisum :: Double -> Double pisum cut = go True 1 0 where go b n s | cut < n = if b then s+1/(2*n) else s-1/(2*n) go True n !s = go False (n+2) (s+recip n) go False n !s = go True (n+2) (s-recip n) ======================================== ./Loops_fasm 4.53s ./Loops_viac 4.22s ./Loops_llvm 2.89s Fusion.hs (uses stream-fusion package) ======================================== module Main (main) where import qualified Data.List.Stream as S main :: IO () main = do putStrLn "EPS: " eps <- readLn :: IO Double let !mx = floor (4/eps) !k = (mx+1) `quot` 2 putStrLn $ "PI mit EPS " ++ (show eps) ++ " = " ++ show (leibniz k) leibniz n = (4 *) $ S.sum $ S.take n step step :: [Double] step = S.unfoldr phi (True,1) where phi (sig,d) | sig = Just (1/d, (False,d+2)) | otherwise = Just (negate (1/d), (True,d+2)) ======================================== ./Fusion_fasm 4.61s ./Fusion_viac 4.22s ./Fusion_llvm 3.62s List.hs ======================================== module Main (main) where import Data.List (unfoldr) main :: IO () main = do putStrLn "EPS: " eps <- readLn :: IO Double let mx = floor (4/eps) !k = (mx+1) `quot` 2 putStrLn $ "PI mit EPS " ++ (show eps) ++ " = " ++ show (leibniz k) leibniz n = (4 *) $ sum $ take n step step :: [Double] step = unfoldr phi (True,1) where phi (sig,d) | sig = Just (1/d, (False,d+2)) | otherwise = Just (negate (1/d), (True,d+2)) ======================================== ./List_fasm 18.21s ./List_viac 16.71s ./List_llvm 16.92s So with these kinds of results (obviously I'm biased though since I wrote the llvm back-end) I think the sentiment that the -fvia-C approach should be eventually removed is the right way to go since with the LLVM back-end and the new code generator there is a promising and much more interesting future. ~ David From marlowsd at gmail.com Thu Feb 18 05:13:05 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Feb 18 04:43:57 2010 Subject: Removing/deprecating -fvia-c In-Reply-To: <258cd3201002171315g27ecac00na5b2ba7e79d6cc6a@mail.gmail.com> References: <20100214165138.GA14278@matrix.chaos.earth.li> <20100214175835.GA31709@whirlpool.galois.com> <4B7B9C9D.2040200@isaac.cedarswampstudios.org> <4B7BFAF5.9040104@gmail.com> <258cd3201002171315g27ecac00na5b2ba7e79d6cc6a@mail.gmail.com> Message-ID: <4B7D12B1.7060300@gmail.com> On 17/02/2010 21:15, Scott Michel wrote: > Depends a lot on the benchmark. The FreeBSD kernel dev crowd (one of > whom works for me) have seen performance improvements between 10-20% > using LLVM and clang over gcc. It also depends heavily on which > optimization passes you have LLVM invoke -- bear in mind that LLVM is a > compiler optimization infrastructure first and foremost. Right, such benchmarks tend to be quickly out of date especially when both projects are being actively developed. I have no vested interest in either - we'll use whatever suits us better, and that seems to be LLVM. > Even so, LLVM doesn't let us generate exactly the code we'd like: we > can't use GHC's tables-next-to-code optimisation. Measurements done > by David Terei who built the LLVM backend apparently show that this > doesn't matter much (~3% slower IIRC), though I'm still surprised > that all those extra indirections don't have more of an effect, I > think we need to investigate this more closely. It's important > because if the LLVM backend is to be a compile-time option, we have > to either drop tables-next-to-code, or wait until LLVM supports > generating code in that style. > > > This sounds like an impedance mismatch between GHC's concept of IR and > LLVM's. It certainly is an impedence mismatch - there's no good reason why LLVM couldn't generate the code we want, but its IR doesn't allow us to represent it. So there's every reason to believe that this could be fixed in LLVM without too much difficulty. We can work around the impedence mismatch the other way, by not using tables-next-to-code in GHC, but that costs us a bit in performance. > [disclaimer: grain of salt speculation, haven't read the code] > Tables-next-to-code has an obvious cache-friendliness property, BTW. Oh absolutely, that's why it's not a clear win and some people argue that the code cache pollution should outweigh the negative effects of those extra indirections. Having seen the effect of branch mispredictions though I'm inclined to believe that those indirections are more expensive, though. The cost is this: every return to a stack frame takes two indirections rather than one. Of course GHC's two representations are not the only two you could choose - people have been designing clever ways to map code addresses to data structures for a long time. If returning to a stack frame is the dominant operation then you would put the return address on the stack and use a hash table to map those to info tables. That trades off mutator time against GC time, and we don't know whether it would be a win, but we do know it would take a lot of effort to find out. The tables-next-to-code representation means that you don't have to fiddle around with hash tables, so it's simpler and probably faster. > Generally, there's going to be some instruction prefetch into the cache. > This is likely why it's faster. Otherwise, you have to warm up the data > cache, since LLVM spills the tables into the target's constant pool. Not sure what "spills the tables" means, but maybe that's not important. > NCGs should be faster than plain old C. Trying to produce optimized C is > the fool's errand, and I'm starting to agree with dropping that. My > worry was that the C backend would be dropped in its entirety, also a > fool's errand. Yes, exactly. Cheers, Simon From jvlask at hotmail.com Fri Feb 19 03:15:45 2010 From: jvlask at hotmail.com (John Lask) Date: Fri Feb 19 02:46:40 2010 Subject: asynchronous call-backs In-Reply-To: <4B7BB5D8.6070500@gmail.com> References: <4B66C25A.5040407@gmail.com> <4B7BB5D8.6070500@gmail.com> Message-ID: Thanks for your response. I belabour the issue as I am not entirely comfortable that there is no issue wrt to the unthreaded rts on windows at least. Included here is a test of executing a callback from c to haskell asynchronously this test was run with both threaded rts and non threaded rts. It demonstrates (tentatively) that asynchronous call-backs seem to be safe with threaded rts and unsafe otherwise. I have run other tests with the unthreaded rts which confirms the above (eg with console events) . Details of which I can provide. It does beg the question what proof can be given that the threaded rts is safe wrt asynchronous call-backs. My thoughts go along the lines that the safety of essentially parallel evaluation of thunks depends upon there being some level of atomicity in those operations, that atomicity being under the control of the rts. My concerns boil down to whether that atomicity is broken (by the unscheduled attempt at an evaluation of a thunk) or there exists within the evaluation model of the rts some guarantee wrt the underlying architecture or by happenstance ad-hoc enforcement of atomicity/synchronisation as an implementation detail. Has this question been treated as an implementation detail or is there some literature that you could refer me to? ------------------------------------------------------------ TEST DETAILS As a test the c routine, starts an alarm thread that runs the call-back once a second On each iteration a counter is incremented and passed to the call back. the threaded rts works fine, the un-threaded rts raises an error. The error changes depending upon when the rts is interupted. In one case the error reported was: test: internal error: resurrectThreads: thread blocked in a strange way (GHC version 6.10.4 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. > module Main where > import Foreign > import Foreign.C > import System.IO > import Control.Concurrent > -- the callback to be executed assynchronous to the main loop > hsfoo :: Int -> IO () > hsfoo x = do > putStrLn ("Input was: " ++ show x) > return () > foreign import ccall safe "wrapper" mkfoo :: (Int->IO ())->IO (FunPtr (Int->IO ())) > foreign import ccall safe "registerCallback" registerCallback :: (FunPtr (Int->IO ()))->IO () > loop = do > threadDelay 1000 > mapM_ (putStrLn . show) [(0::Int)..10] > loop > main = do > foo <- mkfoo hsfoo > registerCallback foo > loop --------------------------------------------------------------------------------- the c code /* starts an alarm thread that runs the call back * once a second. * on each iteration a counter is incremented * and passed to the call back. */ #include #include #include typedef void (*callback_t)(int); static callback_t g_callback; void CALLBACK alarm_callback( unsigned long interval) { int rc; int i=0; printf("alarm thread started\n"); i=0; while (1) { i++; Sleep(1000); printf("alarm\n"); g_callback(i); }; } void registerCallback(callback_t sighandler) { printf("installing callback"); g_callback = sighandler; CreateThread(NULL,0, (LPTHREAD_START_ROUTINE)alarm_callback, (void*)0,0,0); } > On 01/02/10 13:36, John Lask wrote: >> I understand these are internals of ghc and subject to change. The >> reason for their use: to support asynchronous interrupts safe with >> respect to the Haskell code that is being interrupted. To my knowledge >> (please correct me if I am wrong) there is no way to do this other than >> the following alternatives and the already mentioned functions. >> >> As an example, suppose I want to provide a call back to a win32 OS hook >> which takes a c-call-back routine. My understanding is that I cannot use >> a wrapped Haskell call-back routine as there are no guarantees what >> state the Haskell rts will be in when the routine is called. > > It's not clear to me that this wouldn't work. > > I believe it would be perfectly safe for the Win32 console handler > callback to invoke Haskell functions, because the handler is executed in > a separate thread, unlike Unix signals which happen in the context of > one of the existing threads (which is why you can't use any inter-thread > communication or synchronisation in a Unix signal handler). > >> At least initially I have used the above mentioned functions to support >> win32 signal handling, as the ghc rts just catches (and dispatches) >> console events, which do not encompass all the (rather limited) c-rts >> signals. >> >> The obvious solution is to provide a c call-back routine, use an WIN32 >> event object, use a Haskell bound thread to wait on that event. >> >> another alternative would be to poll. >> >> The first alternative requires threaded rts which for various reasons I >> don't wish to use under all circumstances, the other alternative is >> inefficient or unresponsive. >> >> Discussion of either of these alternatives distract from the question >> "shouldn't there be a method for asynchronous call-back that is safe >> with respect to the Haskell rts state"? >> >> But there already exists such a method, that of the backdoor already >> mentioned, really, all that is required is for this to become more >> formalised and a single api adopted that is usable from c and consistent >> across threaded and un-threaded rts, but in the mean time the existing >> structure is quite usable for this purpose aside from the cumbersome >> libraries issue. >> >> And the reason for this libraries issue is that the methods exposed by >> the ghc-runtime to collect and post events into the ghc runtime system >> differ between the threaded and non-threaded runtimes, which is why >> short of changing ghc rts myself I can't avoid it (or adopting either of >> the above alternatives) >> >> As the facility (to capture arbitrary asynchronous interrupts) is >> generally useful I believe it to be advantageous to address it rather >> than side-stepping it. > > You might want to look at the work that Bryan O'Sullivan and Johan > Tibell are doing on a new IO manager: > > http://github.com/bos/event/ > > There's no Win32 support yet, but it's designed to allow multiple backends. > > Cheers, > Simon > > From marlowsd at gmail.com Fri Feb 19 17:22:57 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Feb 19 16:53:41 2010 Subject: asynchronous call-backs In-Reply-To: References: <4B66C25A.5040407@gmail.com> <4B7BB5D8.6070500@gmail.com> Message-ID: <4B7F0F41.8040409@gmail.com> On 19/02/10 08:15, John Lask wrote: > Thanks for your response. I belabour the issue as I am not > entirely comfortable that there is no issue wrt to the unthreaded rts > on windows at least. > > Included here is a test of executing a callback from c to haskell > asynchronously this test was run with both threaded rts and non threaded > rts. > > It demonstrates (tentatively) that asynchronous call-backs > seem to be safe with threaded rts and unsafe otherwise. Correct. The threaded RTS is designed to handle call-ins on multiple threads. > I have run other tests with the unthreaded rts which confirms > the above (eg with console events) . Details of which I can provide. > > It does beg the question what proof can be given that the threaded > rts is safe wrt asynchronous call-backs. > > My thoughts go along the lines that the safety of essentially parallel > evaluation of thunks depends upon there being some level of atomicity in > those operations, that atomicity being under the control of the rts. My > concerns boil down to whether that atomicity is broken (by the > unscheduled attempt at an evaluation of a thunk) or there exists within > the evaluation model of the rts some guarantee wrt the underlying > architecture or by happenstance ad-hoc enforcement of > atomicity/synchronisation as an implementation detail. Has this question > been treated as an implementation detail or is there some literature > that you could refer me to? Yes, I suggest starting with this paper, it describes the fundamental ideas behind GHC's parallel execution model: http://www.haskell.org/~simonmar/papers/multiproc.pdf Cheers, Simon > > ------------------------------------------------------------ > TEST DETAILS > > As a test the c routine, starts an alarm thread that runs the call-back > once a second On each iteration a counter is incremented > and passed to the call back. > > the threaded rts works fine, the un-threaded rts raises an > error. The error changes depending upon when the rts is interupted. > In one case the error reported was: > > test: internal error: resurrectThreads: thread blocked in a strange way > (GHC version 6.10.4 for i386_unknown_mingw32) > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > This application has requested the Runtime to terminate it in an unusual > way. > Please contact the application's support team for more information. > > > > > > module Main where > > > import Foreign > > import Foreign.C > > import System.IO > > import Control.Concurrent > > > -- the callback to be executed assynchronous to the main loop > > hsfoo :: Int -> IO () > > hsfoo x = do > > putStrLn ("Input was: " ++ show x) > > return () > > > foreign import ccall safe "wrapper" mkfoo :: (Int->IO ())->IO (FunPtr > (Int->IO ())) > > > foreign import ccall safe "registerCallback" registerCallback :: > (FunPtr (Int->IO ()))->IO () > > > > > loop = do > > threadDelay 1000 > > mapM_ (putStrLn . show) [(0::Int)..10] > > loop > > > main = do > > foo <- mkfoo hsfoo > > registerCallback foo > > loop > > --------------------------------------------------------------------------------- > > the c code > > > > > /* starts an alarm thread that runs the call back > * once a second. > * on each iteration a counter is incremented > * and passed to the call back. > */ > > #include > #include > #include > > typedef void (*callback_t)(int); > > static callback_t g_callback; > > void CALLBACK alarm_callback( unsigned long interval) { > > int rc; > int i=0; > printf("alarm thread started\n"); > i=0; > while (1) { > i++; > Sleep(1000); > printf("alarm\n"); > g_callback(i); > }; > } > > void registerCallback(callback_t sighandler) > { > printf("installing callback"); > > g_callback = sighandler; > > CreateThread(NULL,0, (LPTHREAD_START_ROUTINE)alarm_callback, > (void*)0,0,0); > > } > >> On 01/02/10 13:36, John Lask wrote: >>> I understand these are internals of ghc and subject to change. The >>> reason for their use: to support asynchronous interrupts safe with >>> respect to the Haskell code that is being interrupted. To my knowledge >>> (please correct me if I am wrong) there is no way to do this other than >>> the following alternatives and the already mentioned functions. >>> >>> As an example, suppose I want to provide a call back to a win32 OS hook >>> which takes a c-call-back routine. My understanding is that I cannot use >>> a wrapped Haskell call-back routine as there are no guarantees what >>> state the Haskell rts will be in when the routine is called. >> >> It's not clear to me that this wouldn't work. >> >> I believe it would be perfectly safe for the Win32 console handler >> callback to invoke Haskell functions, because the handler is executed >> in a separate thread, unlike Unix signals which happen in the context >> of one of the existing threads (which is why you can't use any >> inter-thread communication or synchronisation in a Unix signal handler). >> >>> At least initially I have used the above mentioned functions to support >>> win32 signal handling, as the ghc rts just catches (and dispatches) >>> console events, which do not encompass all the (rather limited) c-rts >>> signals. >>> >>> The obvious solution is to provide a c call-back routine, use an WIN32 >>> event object, use a Haskell bound thread to wait on that event. >>> >>> another alternative would be to poll. >>> >>> The first alternative requires threaded rts which for various reasons I >>> don't wish to use under all circumstances, the other alternative is >>> inefficient or unresponsive. >>> >>> Discussion of either of these alternatives distract from the question >>> "shouldn't there be a method for asynchronous call-back that is safe >>> with respect to the Haskell rts state"? >>> >>> But there already exists such a method, that of the backdoor already >>> mentioned, really, all that is required is for this to become more >>> formalised and a single api adopted that is usable from c and consistent >>> across threaded and un-threaded rts, but in the mean time the existing >>> structure is quite usable for this purpose aside from the cumbersome >>> libraries issue. >>> >>> And the reason for this libraries issue is that the methods exposed by >>> the ghc-runtime to collect and post events into the ghc runtime system >>> differ between the threaded and non-threaded runtimes, which is why >>> short of changing ghc rts myself I can't avoid it (or adopting either of >>> the above alternatives) >>> >>> As the facility (to capture arbitrary asynchronous interrupts) is >>> generally useful I believe it to be advantageous to address it rather >>> than side-stepping it. >> >> You might want to look at the work that Bryan O'Sullivan and Johan >> Tibell are doing on a new IO manager: >> >> http://github.com/bos/event/ >> >> There's no Win32 support yet, but it's designed to allow multiple >> backends. >> >> Cheers, >> Simon >> >> > From garious at gmail.com Fri Feb 19 21:11:26 2010 From: garious at gmail.com (Greg Fitzgerald) Date: Fri Feb 19 20:42:25 2010 Subject: integer-simple by default Message-ID: <1f3dc80d1002191811q63193476vf6924a5b5127fd8f@mail.gmail.com> Static linking to GMP on Windows is sending me towards a bunch of red tape at work. What can I do to make integer-simple the default integer library for GHC? Need anything more than test suite and performance metrics? Any date planned for the 6.12.2 release? Thanks, Greg From dons at galois.com Fri Feb 19 21:22:14 2010 From: dons at galois.com (Don Stewart) Date: Fri Feb 19 20:52:56 2010 Subject: integer-simple by default In-Reply-To: <1f3dc80d1002191811q63193476vf6924a5b5127fd8f@mail.gmail.com> References: <1f3dc80d1002191811q63193476vf6924a5b5127fd8f@mail.gmail.com> Message-ID: <20100220022214.GA25321@whirlpool.galois.com> garious: > Static linking to GMP on Windows is sending me towards a bunch of red > tape at work. What can I do to make integer-simple the default > integer library for GHC? Need anything more than test suite and > performance metrics? Any date planned for the 6.12.2 release? You can dynamically link libgmp on windows. That might be easier: http://haskell.forkio.com/gmpwindows From garious at gmail.com Sat Feb 20 14:11:15 2010 From: garious at gmail.com (Greg Fitzgerald) Date: Sat Feb 20 13:42:11 2010 Subject: integer-simple by default In-Reply-To: <20100220022214.GA25321@whirlpool.galois.com> References: <1f3dc80d1002191811q63193476vf6924a5b5127fd8f@mail.gmail.com> <20100220022214.GA25321@whirlpool.galois.com> Message-ID: <1f3dc80d1002201111w50d89c0s98cb14a851aa7f2f@mail.gmail.com> > You can dynamically link libgmp on windows. That might be easier: Do you know if the dynamic link escape hatch has ever held up in court? Last time I looked into it, the free software community had mixed opinions. In any case, giving GMP the boot alleviates any licensing concerns, makes the GHC build a little simpler, and allows users to create standalone executables. Is there any reason we shouldn't attempt to make integer-simple the default? -Greg From igloo at earth.li Sat Feb 20 14:37:34 2010 From: igloo at earth.li (Ian Lynagh) Date: Sat Feb 20 14:08:11 2010 Subject: integer-simple by default In-Reply-To: <1f3dc80d1002201111w50d89c0s98cb14a851aa7f2f@mail.gmail.com> References: <1f3dc80d1002191811q63193476vf6924a5b5127fd8f@mail.gmail.com> <20100220022214.GA25321@whirlpool.galois.com> <1f3dc80d1002201111w50d89c0s98cb14a851aa7f2f@mail.gmail.com> Message-ID: <20100220193734.GA9733@matrix.chaos.earth.li> On Sat, Feb 20, 2010 at 11:11:15AM -0800, Greg Fitzgerald wrote: > > In any case, giving GMP the boot alleviates any > licensing concerns, makes the GHC build a little simpler, and allows > users to create standalone executables. Is there any reason we > shouldn't attempt to make integer-simple the default? I think defaulting to a Haskell Integer would be good if we can achieve it (i.e. if we can get a library that "performs well enough", whatever that means). The algorithms in integer-simple may be too simple, although I don't think I've done any timings since http://hackage.haskell.org/trac/ghc/ticket/601#comment:14 There's also HIntegerByInt: http://www.haskell.org/pipermail/libraries/2007-August/007909.html although it would need to be changed to user lower level types etc. Thanks Ian From ml at isaac.cedarswampstudios.org Sat Feb 20 14:47:30 2010 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Sat Feb 20 14:18:01 2010 Subject: integer-simple by default In-Reply-To: <1f3dc80d1002201111w50d89c0s98cb14a851aa7f2f@mail.gmail.com> References: <1f3dc80d1002191811q63193476vf6924a5b5127fd8f@mail.gmail.com> <20100220022214.GA25321@whirlpool.galois.com> <1f3dc80d1002201111w50d89c0s98cb14a851aa7f2f@mail.gmail.com> Message-ID: <4B803C52.7060403@isaac.cedarswampstudios.org> On 02/20/10 14:11, Greg Fitzgerald wrote: >> You can dynamically link libgmp on windows. That might be easier: > > Do you know if the dynamic link escape hatch has ever held up in > court? Last time I looked into it, the free software community had > mixed opinions. GMP is under LGPL, which is designed for this very purpose: to allow proprietary code to link to it as long as it is easy to replace the Free code with a different version of Free code (for example, by replacing a dynamic library). Is there any reason to doubt the FSF's efforts? (Note that LGPL doesn't work as well for Haskell code as for C code because Haskell compilers tend to do a lot more inlining; but GMP is C code.) > In any case, giving GMP the boot alleviates any > licensing concerns, makes the GHC build a little simpler, and allows > users to create standalone executables. However the 3-clause BSD license is obviously at least somewhat simpler for lawyers. > Is there any reason we > shouldn't attempt to make integer-simple the default? If you know that none of your code or libraries are using any particularly large integers [how would you know, though?], then it should perform alright. GMP, however, is the result of years of work making operations on integers large and small be reasonably performant -- work that Haskell would be foolhardy to duplicate, I'm guessing. (Depending what our standards are... Is reasonable performance for multiplying integers less than 320 bits long, say, good enough? What happens when someone wants state-of-the-art performance? Is a nonstandard-Integer-type GMP-binding sufficient for these uses?) -Isaac From igloo at earth.li Sat Feb 20 14:47:56 2010 From: igloo at earth.li (Ian Lynagh) Date: Sat Feb 20 14:18:34 2010 Subject: Confusion about GHC and GMP In-Reply-To: <1f3dc80d1002171604j30fbf22ewae4ea41de16dc669@mail.gmail.com> References: <1f3dc80d1002121317o39a761cese20e3862448834ea@mail.gmail.com> <20100213150113.GA9313@matrix.chaos.earth.li> <1f3dc80d1002171604j30fbf22ewae4ea41de16dc669@mail.gmail.com> Message-ID: <20100220194756.GB9733@matrix.chaos.earth.li> On Wed, Feb 17, 2010 at 04:04:16PM -0800, Greg Fitzgerald wrote: > > I was able to build GHC on Linux with no trouble. But on Windows, I go > down because (I think) the preprocessor is choking on ^M characters. > > I get errors like this: > libraries\haskeline\.\System\Console\Haskeline\Backend\Win32.hsc:153: > error: syntax error before ')' token > libraries\haskeline\.\System\Console\Haskeline\Backend\Win32.hsc: In > function `main': > libraries\haskeline\.\System\Console\Haskeline\Backend\Win32.hsc:155: > error: syntax error before ';' token > compiling libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32_hsc_make.c > > > After removing those ^M's from Win32.hsc and Win32_hsc_make.c, things > are moving along, slowly but surely. The build is using the "inplace" > gcc so I assume the problem is not gcc, but whatever generates those > files. Any idea how the extra line feeds slip in? That's not ringing any bells with me. We'd need more details to work out what's going on, e.g. the commandline, what version of GHC you are bootstrapping with, what versino you're compiling, whether you are using msys or cygwin, etc. It may also help to see what the generated Win32_hsc_make.c looks like. Thanks Ian From ml at isaac.cedarswampstudios.org Sat Feb 20 14:56:53 2010 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Sat Feb 20 14:27:23 2010 Subject: integer-simple by default In-Reply-To: <20100220193734.GA9733@matrix.chaos.earth.li> References: <1f3dc80d1002191811q63193476vf6924a5b5127fd8f@mail.gmail.com> <20100220022214.GA25321@whirlpool.galois.com> <1f3dc80d1002201111w50d89c0s98cb14a851aa7f2f@mail.gmail.com> <20100220193734.GA9733@matrix.chaos.earth.li> Message-ID: <4B803E85.9070901@isaac.cedarswampstudios.org> On 02/20/10 14:37, Ian Lynagh wrote: > There's also HIntegerByInt: > http://www.haskell.org/pipermail/libraries/2007-August/007909.html > although it would need to be changed to user lower level types etc. that's true, (I wrote it), the current form uses a list-based implementation with a lot of recursion and I'd have to see how well that converts to some sort of array [at least I assume arrays are the only reasonable storage layout...]. I used a couple algorithms to make operations faster (at least multiplication -- I don't remember the details) so it might be useful code to pick up again. I have a bit of time now, if anyone's seriously interested, I could work on haskell integer code. As long as I had certain standards -what am I trying to accomplish (at least, performance-wise)? -what might be a good low-level format? (And is it important to strew unboxed ints all over the place, or is it fine to skip this and count on the optimizer?) -Isaac From fw at deneb.enyo.de Sat Feb 20 15:11:36 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat Feb 20 14:42:15 2010 Subject: integer-simple by default In-Reply-To: <1f3dc80d1002201111w50d89c0s98cb14a851aa7f2f@mail.gmail.com> (Greg Fitzgerald's message of "Sat, 20 Feb 2010 11:11:15 -0800") References: <1f3dc80d1002191811q63193476vf6924a5b5127fd8f@mail.gmail.com> <20100220022214.GA25321@whirlpool.galois.com> <1f3dc80d1002201111w50d89c0s98cb14a851aa7f2f@mail.gmail.com> Message-ID: <87635ru0p3.fsf@mid.deneb.enyo.de> * Greg Fitzgerald: >> You can dynamically link libgmp on windows. That might be easier: > > Do you know if the dynamic link escape hatch has ever held up in > court? GMP is LGPL, so if you use an official build or a private build from unmodified sources, all you need to do is to ship the sources along with your product. (In theory. Ask a lawyer to be sure.) From dons at galois.com Sat Feb 20 20:57:01 2010 From: dons at galois.com (Don Stewart) Date: Sat Feb 20 20:27:41 2010 Subject: Removing/deprecating -fvia-c In-Reply-To: <4B7D0285.90305@gmail.com> References: <20100214165138.GA14278@matrix.chaos.earth.li> <20100214175835.GA31709@whirlpool.galois.com> <4B797863.1000409@gmail.com> <20100215182920.GB3829@whirlpool.galois.com> <20100215214914.GA4590@whirlpool.galois.com> <4B7D0285.90305@gmail.com> Message-ID: <20100221015701.GD29440@whirlpool.galois.com> davidterei: > > I've been looking at some of these cases and seeing how the LLVM > back-end performs. My general impression from benchmarking the LLVM > back-end in the past has been that it generally performs with similar > characteristics as the C code generator (that is, where the C code > generator stood out compared to the NCG, so did LLVM). > > (On x86-32/Mac OS X 10.5, had some issues getting x64 working at moment): > > ./zipWith3_viac 0.72s > ./zipWith3_fasm 0.65s > ./zipWith3_llvm 0.38s Those are great numbers! I've added llvm support to ghc-core (if you compile with -fllvm, ghc-core will display the core and assembly in the pager, syntax highlighted). Unfortunately, llvm.org is down, so I can't apply patches to my llvm install at the moment, but I have managed to compile a fair few things on x86_64 -- they don't run though :-) What's the status of the x86_64 llvm backend, do you know, and are there ways to tune the optimizations that llvm applies? Should we just be using the llvm binding package on Hackage? -- Do From igloo at earth.li Sun Feb 21 13:14:08 2010 From: igloo at earth.li (Ian Lynagh) Date: Sun Feb 21 12:44:44 2010 Subject: integer-simple by default In-Reply-To: <4B803E85.9070901@isaac.cedarswampstudios.org> References: <1f3dc80d1002191811q63193476vf6924a5b5127fd8f@mail.gmail.com> <20100220022214.GA25321@whirlpool.galois.com> <1f3dc80d1002201111w50d89c0s98cb14a851aa7f2f@mail.gmail.com> <20100220193734.GA9733@matrix.chaos.earth.li> <4B803E85.9070901@isaac.cedarswampstudios.org> Message-ID: <20100221181408.GA18871@matrix.chaos.earth.li> On Sat, Feb 20, 2010 at 02:56:53PM -0500, Isaac Dupree wrote: > On 02/20/10 14:37, Ian Lynagh wrote: >> There's also HIntegerByInt: >> http://www.haskell.org/pipermail/libraries/2007-August/007909.html >> although it would need to be changed to user lower level types etc. > > that's true, (I wrote it), the current form uses a list-based > implementation with a lot of recursion and I'd have to see how well that > converts to some sort of array [at least I assume arrays are the only > reasonable storage layout...]. I used a couple algorithms to make > operations faster (at least multiplication -- I don't remember the > details) so it might be useful code to pick up again. I have a bit of > time now, if anyone's seriously interested, I could work on haskell > integer code. As long as I had certain standards > > -what am I trying to accomplish (at least, performance-wise)? I think opinions are divided on this. Performance with word-sized Integer's is definitely important. > -what might be a good low-level format? (And is it important to strew > unboxed ints all over the place, or is it fine to skip this and count on > the optimizer?) I think relying on the optimiser is OK, but don't forget that you don't have the standard (+) etc. Thanks Ian From ml at isaac.cedarswampstudios.org Sun Feb 21 13:56:54 2010 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Sun Feb 21 13:27:20 2010 Subject: integer-simple by default In-Reply-To: <20100221181408.GA18871@matrix.chaos.earth.li> References: <1f3dc80d1002191811q63193476vf6924a5b5127fd8f@mail.gmail.com> <20100220022214.GA25321@whirlpool.galois.com> <1f3dc80d1002201111w50d89c0s98cb14a851aa7f2f@mail.gmail.com> <20100220193734.GA9733@matrix.chaos.earth.li> <4B803E85.9070901@isaac.cedarswampstudios.org> <20100221181408.GA18871@matrix.chaos.earth.li> Message-ID: <4B8181F6.60704@isaac.cedarswampstudios.org> On 02/21/10 13:14, Ian Lynagh wrote: > On Sat, Feb 20, 2010 at 02:56:53PM -0500, Isaac Dupree wrote: >> -what am I trying to accomplish (at least, performance-wise)? > > I think opinions are divided on this. > > Performance with word-sized Integer's is definitely important. This is true. We could start a discussion on the Libraries list -- although I'm sure it would also not reach a clear conclusion. We could try to find out how large Integers get, in practice, in existing Haskell code (this may be difficult to find out). We could make sure there's a good non-builtin-to-ghc GMP-binding library (Is there one? Is it even possible yet, in a way that doesn't conflict with GHC's builtin GMP?). Then people would have a place to turn if they need GMP's performance for something particular. >> -what might be a good low-level format? (And is it important to strew >> unboxed ints all over the place, or is it fine to skip this and count on >> the optimizer?) > > I think relying on the optimiser is OK, but don't forget that you don't > have the standard (+) etc. oh okay, interesting. I think I'd best start by finding out where integer-simple lies in the dependency tree. -Isaac From daniel.is.fischer at web.de Sun Feb 21 14:18:38 2010 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sun Feb 21 13:51:10 2010 Subject: integer-simple by default In-Reply-To: <4B8181F6.60704@isaac.cedarswampstudios.org> References: <1f3dc80d1002191811q63193476vf6924a5b5127fd8f@mail.gmail.com> <20100221181408.GA18871@matrix.chaos.earth.li> <4B8181F6.60704@isaac.cedarswampstudios.org> Message-ID: <201002212018.38442.daniel.is.fischer@web.de> Am Sonntag 21 Februar 2010 19:56:54 schrieb Isaac Dupree: > We could try to find out how large Integers get, in practice, in > existing Haskell code (this may be difficult to find out). Just as a data-point, my code rarely exceeds 128 bits (at least, beyond that performance isn't so important anymore). From ml at isaac.cedarswampstudios.org Sun Feb 21 14:37:58 2010 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Sun Feb 21 14:08:22 2010 Subject: integer-simple by default In-Reply-To: <201002212018.38442.daniel.is.fischer@web.de> References: <1f3dc80d1002191811q63193476vf6924a5b5127fd8f@mail.gmail.com> <20100221181408.GA18871@matrix.chaos.earth.li> <4B8181F6.60704@isaac.cedarswampstudios.org> <201002212018.38442.daniel.is.fischer@web.de> Message-ID: <4B818B96.5070701@isaac.cedarswampstudios.org> On 02/21/10 14:18, Daniel Fischer wrote: > Am Sonntag 21 Februar 2010 19:56:54 schrieb Isaac Dupree: >> We could try to find out how large Integers get, in practice, in >> existing Haskell code (this may be difficult to find out). I suspect (just guessing...) that a more reliable way to find out is to instrument integer-simple to report the sizes of integers it handles. For example, if you use Rational, (even toRational/fromRational), you might be handling Integers somewhat larger than you thought you were. And this could also report on how often the integers get that large. (Also it's probably only tough operations like multiplication and division that we need to worry about for large numbers. It's easy to get linear-time addition, etc. Incidentally, for operations like Large Number plus or minus Small Number, it's possible to use a representation that has laziness and sharing to achieve amortized O(min(m,n)) time. Which is a nice property... which I believe I implemented in HIntegerByInt... but there are probably disadvantages to doing it this way too.) -Isaac From dons at galois.com Sun Feb 21 20:57:25 2010 From: dons at galois.com (Don Stewart) Date: Sun Feb 21 20:28:00 2010 Subject: Some great results on fused code with the LLVM backend Message-ID: <20100222015725.GA1870@whirlpool.galois.com> I tried out some of the vector and uvector fusion benchmarks with the new LLVM backend http://donsbot.wordpress.com/2010/02/21/smoking-fast-haskell-code-using-ghcs-new-llvm-codegen/ and got some great results for the tight loops generated through fusion. Up to 2x faster than gcc -O3 in some cases. The LLVM backend looks very promising -- considering we've not even begun to explore the optimization pipeline at the level. -- Don From twhitehead at gmail.com Sun Feb 21 23:46:11 2010 From: twhitehead at gmail.com (Tyson Whitehead) Date: Sun Feb 21 23:16:54 2010 Subject: GHC FFI stub files Message-ID: <201002212346.19241.twhitehead@gmail.com> I'm writing a perl module that interfaces some haskell code and its a bit of a pain because both perl and ghc have their own custom build system. Is there a way to get ghc to give you the gcc/as/ld options (library paths, include paths, flags, etc) required for the FFI stub files it generates? The best I've come up with so far is to extract them from GHC by telling it to use a "capture the arguments" command as the compiler and linker. Thanks! -Tyson (I could also tell the perl build system that ghc is c compiler, assembler, and linker, but then I need to do a bunch of wrapping with -optc and friends) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100221/65c21900/attachment.bin From bayer at cpw.math.columbia.edu Mon Feb 22 09:41:26 2010 From: bayer at cpw.math.columbia.edu (Dave Bayer) Date: Mon Feb 22 09:12:00 2010 Subject: Quasi quoting In-Reply-To: <59543203684B2244980D7E4057D5FBC10B0707FA@DB3EX14MBXC306.europe.corp.microsoft.com> References: <20100219194848.GA1193@emergent.ellipticsemi.com> <59543203684B2244980D7E4057D5FBC10B0707FA@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: <9C01D235-43D4-4FC6-96D4-546E21D58DBC@math.columbia.edu> Perhaps I missed this or I'm missing something, but seeing a mention of quasiquoting on another thread, I reread this entire thread just now before posting. If by "stealing syntax" we mean that the odd programmer who writes illegiblelinenoisewithoutspaceshastoaddtheoddspacehereandthere, then fine, sorry about the long post which you may freely ignore. What I read when I see "stealing syntax" is that a proposal makes some prior code impossible to write. Please clarify. I have no trouble distinguishing visually between the following forms [hex| 1.fffffp+1023 |] [ hex | hex <- [ 0..8 ] ] for two different reasons: [1] I'd never leave out the spaces for the list comprehension, while I'd always leave out the spaces for quasiquoting. [2] It's completely obvious to a human reader that the first form can't be a list comprehension, because of the trailing |] which would be a parse error. Let's recall that indentation-based parsing like we use in Haskell, Python was once radical, and still jars some people. Spaces are already significant for everyone, this just leans on them a bit more. A Lisp programmer would have no issues distinguishing these forms, because [hex| is a single token for the Lisp programmer. A freshman parser for quasiquoting would get this right by accident, failing to catch the quasiquoting that used spaces, falling correctly through to the list comprehension. More generally, humans always resolve ambiguity by parsing several ways in parallel, and accepting the highest priority parse that succeeds. I always expect computer languages to work this way, and my heart is always broken. Why can't Haskell evolve in this direction, as proposals like this increase its code density? Reading "Coders at Work", all of my coding zombie masters abandoned Lisp (as I did) because code density is a Good Thing. It's a mild nuisance to wait on the closing |] to decide, but only a mild nuisance. This reminds me of heredocs, where a traditional (e.g. Perl) heredoc help prog = < So the proposed change will make things *more* uniform, by grabbing every > "[blah|" as lexeme. On Feb 1, 2010, at 1:43 AM, Malcolm Wallace wrote: > I am not myself a TH or QQ user, but it has always bothered me slightly that the syntax for them steals some valid list comprehensions. On Feb 22, 2010, at 5:15 AM, Simon Peyton-Jones wrote: > Or, alternatively, use quasiquoting > > [hex| 1.fffffp+1023 |] From gale at sefer.org Mon Feb 22 13:52:07 2010 From: gale at sefer.org (Yitzchak Gale) Date: Mon Feb 22 13:23:08 2010 Subject: integer-simple by default In-Reply-To: <201002212018.38442.daniel.is.fischer@web.de> References: <1f3dc80d1002191811q63193476vf6924a5b5127fd8f@mail.gmail.com> <20100221181408.GA18871@matrix.chaos.earth.li> <4B8181F6.60704@isaac.cedarswampstudios.org> <201002212018.38442.daniel.is.fischer@web.de> Message-ID: <2608b8a81002221052p12054876yacf40578f346d1c0@mail.gmail.com> Isaac Dupree: >> We could try to find out how large Integers get, in practice, in >> existing Haskell code (this may be difficult to find out). Daniel Fischer wrote: > Just as a data-point, my code rarely exceeds 128 bits (at least, beyond > that performance isn't so important anymore). And Daniel, who is part of the Project Euler team, uses large integers far more than most people. As another data point, Python has also re-invented the GMP wheel, likely for the same licensing reasons. They have been using a simple implementation of Karatsuba multiplication for years. I have never heard of anyone complaining about it. Furthermore, they currently use naive multiplication and don't even bother with Karatsuba for less than about 2000 bits on most recent platforms. Regards, Yitz From garious at gmail.com Mon Feb 22 15:15:41 2010 From: garious at gmail.com (Greg Fitzgerald) Date: Mon Feb 22 14:46:31 2010 Subject: integer-simple by default In-Reply-To: <2608b8a81002221052p12054876yacf40578f346d1c0@mail.gmail.com> References: <1f3dc80d1002191811q63193476vf6924a5b5127fd8f@mail.gmail.com> <20100221181408.GA18871@matrix.chaos.earth.li> <4B8181F6.60704@isaac.cedarswampstudios.org> <201002212018.38442.daniel.is.fischer@web.de> <2608b8a81002221052p12054876yacf40578f346d1c0@mail.gmail.com> Message-ID: <1f3dc80d1002221215k463ce5cfoa3594b4a93c0a573@mail.gmail.com> > As another data point, Python has also re-invented the GMP > wheel, likely for the same licensing reasons. They have > been using a simple implementation of Karatsuba > multiplication for years. I have never heard of anyone > complaining about it Thanks for the data point. Looks like they swapped out their integer implementation for Python3: http://gmplib.org/list-archives/gmp-discuss/2008-November/003434.html Here's the code from January 30, 2010: http://svn.python.org/view/python/trunk/Objects/longobject.c?view=markup More data points: http://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic -Greg From twhitehead at gmail.com Mon Feb 22 16:34:20 2010 From: twhitehead at gmail.com (Tyson Whitehead) Date: Mon Feb 22 16:05:00 2010 Subject: Shared GHC libraries and the runtime system Message-ID: <201002221634.27387.twhitehead@gmail.com> I was working on a shared library that loads up the GHC runtime (via hs_init) and have been running into a bunch of undefined stg symbols. A bit of digging and it seems that GHC doesn't embed - the dependency libHSrts-ghc6.12.1.so, and - the associated rpath /usr/lib/ghc-6.12.1 into shared libraries that it builds. Thus, if your main executable isn't GHC generated (and hence has these), you run into unresolved symbols. I can work around this by manually adding them myself. Is there any reason GHC can't put this information by default into shared libraries though? Thanks! -Tyson PS: Further digging into the various shared libraries packaged with GHC (Debian GHC package 6.12.1-2) reveal that they are actually missing - the dependency libHSrts-ghc6.12.1.so, and - all rpaths (i.e., there are absolutely no rpaths in any of them) $ objdump -p /usr/lib/ghc-6.12.1/base-4.2.0.0/libHSbase-4.2.0.0-ghc6.12.1.so ... Dynamic Section: NEEDED libHSinteger-gmp-0.2.0.0-ghc6.12.1.so NEEDED libgmp.so.3 NEEDED libHSghc-prim-0.2.0.0-ghc6.12.1.so NEEDED libc.so.6 SONAME libHSbase-4.2.0.0-ghc6.12.1.so ... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100222/ebdc3694/attachment.bin From batterseapower at hotmail.com Mon Feb 22 17:00:25 2010 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Mon Feb 22 16:30:56 2010 Subject: Shared GHC libraries and the runtime system In-Reply-To: <201002221634.27387.twhitehead@gmail.com> References: <201002221634.27387.twhitehead@gmail.com> Message-ID: <9d4d38821002221400o6e78c672g856760514353c7d0@mail.gmail.com> Hi Tyson, This blog post (http://blog.well-typed.com/2009/05/buildings-plugins-as-haskell-shared-libs/) might help explain the motivation (actually there are a few relevant posts on the well-typed site). Essentially, I believe that this is done so that you can vary the RTS by changing LD_LIBRARY_PATH. I've never used this facility so I'm unable to say how useful this actually is (or if it actually works at the moment). Cheers, Max On 22 February 2010 21:34, Tyson Whitehead wrote: > I was working on a shared library that loads up the GHC runtime (via hs_init) > and have been running into a bunch of undefined stg symbols. > > A bit of digging and it seems that GHC doesn't embed > > ?- the dependency libHSrts-ghc6.12.1.so, and > ?- the associated rpath /usr/lib/ghc-6.12.1 > > into shared libraries that it builds. ?Thus, if your main executable isn't GHC > generated (and hence has these), you run into unresolved symbols. > > I can work around this by manually adding them myself. ?Is there any reason > GHC can't put this information by default into shared libraries though? > > Thanks! ?-Tyson > > PS: ?Further digging into the various shared libraries packaged with GHC > (Debian GHC package 6.12.1-2) reveal that they are actually missing > > ?- the dependency libHSrts-ghc6.12.1.so, and > ?- all rpaths (i.e., there are absolutely no rpaths in any of them) > > $ objdump -p /usr/lib/ghc-6.12.1/base-4.2.0.0/libHSbase-4.2.0.0-ghc6.12.1.so > ... > Dynamic Section: > ?NEEDED ? ? ?libHSinteger-gmp-0.2.0.0-ghc6.12.1.so > ?NEEDED ? ? ?libgmp.so.3 > ?NEEDED ? ? ?libHSghc-prim-0.2.0.0-ghc6.12.1.so > ?NEEDED ? ? ?libc.so.6 > ?SONAME ? ? ?libHSbase-4.2.0.0-ghc6.12.1.so > ... > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > From ml at isaac.cedarswampstudios.org Mon Feb 22 17:46:34 2010 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Mon Feb 22 17:17:07 2010 Subject: integer-simple by default In-Reply-To: <4B818B96.5070701@isaac.cedarswampstudios.org> References: <1f3dc80d1002191811q63193476vf6924a5b5127fd8f@mail.gmail.com> <20100221181408.GA18871@matrix.chaos.earth.li> <4B8181F6.60704@isaac.cedarswampstudios.org> <201002212018.38442.daniel.is.fischer@web.de> <4B818B96.5070701@isaac.cedarswampstudios.org> Message-ID: <4B83094A.9030204@isaac.cedarswampstudios.org> I think it would be great to have a benchmark, to test Integer performance at various implementations. Perhaps it could test speed of Int, Int64, Int32 as well (for computations that fit within them). I suppose tight numeric loops are key to measuring performance in a useful way (except for incredibly larger Integers). Are there existing benchmarks? (If not, is there a good benchmarking library that I ought to use if I try to write a benchmark?) On 02/22/10 15:15, Greg Fitzgerald wrote: > ... > More data points: > ... Thanks! Code re-use is nice (if we can use one of those BSD-licensed versions) ; although it may turn out useful to write our Integer implementation in Haskell if it helps the optimizer out with small-valued Integers. -Isaac From gale at sefer.org Mon Feb 22 18:04:24 2010 From: gale at sefer.org (Yitzchak Gale) Date: Mon Feb 22 17:35:16 2010 Subject: integer-simple by default In-Reply-To: <1f3dc80d1002221215k463ce5cfoa3594b4a93c0a573@mail.gmail.com> References: <1f3dc80d1002191811q63193476vf6924a5b5127fd8f@mail.gmail.com> <20100221181408.GA18871@matrix.chaos.earth.li> <4B8181F6.60704@isaac.cedarswampstudios.org> <201002212018.38442.daniel.is.fischer@web.de> <2608b8a81002221052p12054876yacf40578f346d1c0@mail.gmail.com> <1f3dc80d1002221215k463ce5cfoa3594b4a93c0a573@mail.gmail.com> Message-ID: <2608b8a81002221504v32eccdc2ra4cfff7ffdd9b879@mail.gmail.com> I wrote: >> As another data point, Python has also re-invented the GMP >> wheel, likely for the same licensing reasons. They have >> been using a simple implementation of Karatsuba >> multiplication for years. I have never heard of anyone >> complaining about it Greg Fitzgerald wrote: > Looks like they swapped out their integer implementation for Python3 Interesting! This will be new in Python 3.2 - the first changes in many years. It's not exactly swapped out, but there are many changes. At first glance, it looks like better 64-bit support, a new division algorithm via floating-point, a new exponentiation algorithm using a 5-bits-at-a-time trick in some cases, optimized Read and Show instances (pardon the expression), a few other things. A lot of the new stuff seems to be from HAC. As before, everything is fully explained in expository comments inside the code, with references; a worthwhile read. Multiplication is still the same basic idea though - naive up to about 2000 bits, followed by just Karatsuba and nothing more. Thanks, Yitz From twhitehead at gmail.com Mon Feb 22 22:44:01 2010 From: twhitehead at gmail.com (Tyson Whitehead) Date: Mon Feb 22 22:15:01 2010 Subject: Shared GHC libraries and the runtime system In-Reply-To: <9d4d38821002221400o6e78c672g856760514353c7d0@mail.gmail.com> References: <201002221634.27387.twhitehead@gmail.com> <9d4d38821002221400o6e78c672g856760514353c7d0@mail.gmail.com> Message-ID: <201002222244.27715.twhitehead@gmail.com> On February 22, 2010 17:00:25 Max Bolingbroke wrote: > Hi Tyson, > > This blog post > (/) might help explain the motivation (actually there are a few relevant > posts on the well-typed site). > > Essentially, I believe that this is done so that you can vary the RTS > by changing LD_LIBRARY_PATH. I've never used this facility so I'm > unable to say how useful this actually is (or if it actually works at > the moment). Thanks Max. Those were good write ups. I'm pleased to report that I've got GHC hooked into Perl as a shared library (i.e., can call my GHC code from Perl). I'm working on trying to get a reasonable build system solution now. So far I've been trying to build a single shared library, but I thinking the easiest/intended way might be to just get GHC to just build its own library and then specify it as a required shared library to the Perl stub library. This way I wouldn't have to mix flags from the build systems in the final link. (although a shared library of stubs to a shared library seems a bit strange) Cheers! -Tyson PS: Thanks to everyone responsible for getting shared libraries working. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100222/07dedd20/attachment.bin From simonpj at microsoft.com Tue Feb 23 03:00:01 2010 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Feb 23 02:28:07 2010 Subject: Shared GHC libraries and the runtime system In-Reply-To: <201002222244.27715.twhitehead@gmail.com> References: <201002221634.27387.twhitehead@gmail.com> <9d4d38821002221400o6e78c672g856760514353c7d0@mail.gmail.com> <201002222244.27715.twhitehead@gmail.com> Message-ID: <59543203684B2244980D7E4057D5FBC10B07E1A4@DB3EX14MBXC308.europe.corp.microsoft.com> Tyson and others Would you like to gather some of what you have learned into a user-oriented Wiki page about how to use shared libraries in GHC? The right place for this is http://haskell.org/haskellwiki/GHC under "Contributed documentation". You probably have all the material in the email thread, and it's a pity not to get full value from it. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- | users-bounces@haskell.org] On Behalf Of Tyson Whitehead | Sent: 23 February 2010 03:44 | To: Max Bolingbroke | Cc: glasgow-haskell-users@haskell.org | Subject: Re: Shared GHC libraries and the runtime system | | On February 22, 2010 17:00:25 Max Bolingbroke wrote: | > Hi Tyson, | > | > This blog post | > (/) might help explain the motivation (actually there are a few relevant | > posts on the well-typed site). | > | > Essentially, I believe that this is done so that you can vary the RTS | > by changing LD_LIBRARY_PATH. I've never used this facility so I'm | > unable to say how useful this actually is (or if it actually works at | > the moment). | | Thanks Max. Those were good write ups. I'm pleased to report that I've got | GHC hooked into Perl as a shared library (i.e., can call my GHC code from | Perl). I'm working on trying to get a reasonable build system solution now. | | So far I've been trying to build a single shared library, but I thinking the | easiest/intended way might be to just get GHC to just build its own library | and then specify it as a required shared library to the Perl stub library. | | This way I wouldn't have to mix flags from the build systems in the final | link. | | (although a shared library of stubs to a shared library seems a bit strange) | | Cheers! -Tyson | | PS: Thanks to everyone responsible for getting shared libraries working. From simonpj at microsoft.com Tue Feb 23 09:31:37 2010 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Feb 23 09:02:22 2010 Subject: FW: Installing syb(-0.1.03) package in head version of Haskell Message-ID: <59543203684B2244980D7E4057D5FBC10B08D018@DB3EX14MBXC312.europe.corp.microsoft.com> Friends Can anyone help Kathleen out? She has a cabal-install issue. I think she's on a Mac. Many thanks Simon From: Kathleen Fisher [mailto:kathleen.fisher@gmail.com] Sent: 16 February 2010 22:54 To: Simon Peyton-Jones Subject: Fwd: Installing syb(-0.1.03) package in head version of Haskell Hi Simon, I'm trying to get the PADS file we were working on compiling under the HEAD version of Haskell, but I'm having trouble getting the Data.Generics module to install. I sent the question below to the libraries@haskell.org last week, but I haven't seen any replies. Is that the right address? Or is there a different place to ask such questions? Thanks for any pointers! Kathleen Begin forwarded message: From: Kathleen Fisher > Date: February 11, 2010 2:28:20 PM PST To: libraries@haskell.org Subject: Installing syb(-0.1.03) package in head version of Haskell Hi all, I'm trying to get a program that uses the Data.Generics module to compile under the head version of GHC, but I am having trouble getting the syb package installed. I believe I am using the most recent version of cabal: kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/.cabal/bin/cabal --version cabal-install version 0.8.0 using version 1.8.0.1 of the Cabal library When I ask cabal to install the syb package, I get the following error: kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/.cabal/bin/cabal install -w ~/sw/ghc-head/bin/ghc Resolving dependencies... Downloading mtl-1.1.0.2... Configuring mtl-1.1.0.2... Preprocessing library mtl-1.1.0.2... ... Registering syb-0.1.0.3... cabal: ghc-pkg: : hGetContents: invalid argument (invalid UTF-8 byte sequence) cabal: Error: some packages failed to install: language-c-quote-0.1 depends on syb-0.1.0.3 which failed to install. syb-0.1.0.3 failed during the building phase. The exception was: exit: ExitFailure 1 The full trace is included below. Here's the version information for the ghc I am running. Kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/sw/ghc-head/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 6.13.20100210 The cabal website suggests sending questions to this list... Any suggestions for how to fix this problem? Kathleen kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/.cabal/bin/cabal install -w ~/sw/ghc-head/bin/ghc Resolving dependencies... Downloading mtl-1.1.0.2... Configuring mtl-1.1.0.2... Preprocessing library mtl-1.1.0.2... Building mtl-1.1.0.2... ...stuff deleted... src/Data/Generics.hs:40:1: Warning: The import of `Prelude' is redundant except perhaps to import instances from `Prelude' To import instances alone, use: import Prelude() Registering syb-0.1.0.3... cabal: ghc-pkg: : hGetContents: invalid argument (invalid UTF-8 byte sequence) cabal: Error: some packages failed to install: language-c-quote-0.1 depends on syb-0.1.0.3 which failed to install. syb-0.1.0.3 failed during the building phase. The exception was: exit: ExitFailure 1 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100223/8baa3216/attachment-0001.html From Alistair.Bayley at invesco.com Tue Feb 23 10:05:56 2010 From: Alistair.Bayley at invesco.com (Bayley, Alistair) Date: Tue Feb 23 09:36:26 2010 Subject: Installing syb(-0.1.03) package in head version of Haskell In-Reply-To: <59543203684B2244980D7E4057D5FBC10B08D018@DB3EX14MBXC312.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC10B08D018@DB3EX14MBXC312.europe.corp.microsoft.com> Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA911026775@GBLONXMB02.corp.amvescap.net> Just a wild guess, but the package description has this non-ascii text: author: Ralf L?mmel, Simon Peyton Jones It could well be Latin-1 encoded, rather than UTF8. Try editing the author field to this: author: Ralf Laemmel, Simon Peyton Jones and rebuilding/installing. > -----Original Message----- > From: glasgow-haskell-users-bounces@haskell.org > [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf > Of Simon Peyton-Jones > Sent: 23 February 2010 14:32 > To: GHC users > Cc: cvs-ghc@haskell.org > Subject: FW: Installing syb(-0.1.03) package in head version > of Haskell > > Friends > > > > Can anyone help Kathleen out? She has a cabal-install issue. > I think she's on a Mac. > > > > Many thanks > > > Simon > > > > From: Kathleen Fisher [mailto:kathleen.fisher@gmail.com] > Sent: 16 February 2010 22:54 > To: Simon Peyton-Jones > Subject: Fwd: Installing syb(-0.1.03) package in head version > of Haskell > > > > Hi Simon, > > > > I'm trying to get the PADS file we were working on compiling > under the HEAD version of Haskell, but I'm having trouble > getting the Data.Generics module to install. I sent the > question below to the libraries@haskell.org last week, but I > haven't seen any replies. Is that the right address? Or is > there a different place to ask such questions? > > > > Thanks for any pointers! > > > > Kathleen > > > > Begin forwarded message: > > > > > > From: Kathleen Fisher > > Date: February 11, 2010 2:28:20 PM PST > > To: libraries@haskell.org > > Subject: Installing syb(-0.1.03) package in head version of Haskell > > > > Hi all, > > I'm trying to get a program that uses the Data.Generics > module to compile under the head version of GHC, but I am > having trouble getting the syb package installed. > > I believe I am using the most recent version of cabal: > > > > > kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/ > .cabal/bin/cabal --version > > cabal-install version 0.8.0 > > using version 1.8.0.1 of the Cabal library > > > When I ask cabal to install the syb package, I get the > following error: > > > > > kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/ > .cabal/bin/cabal install -w ~/sw/ghc-head/bin/ghc > > Resolving dependencies... > > Downloading mtl-1.1.0.2... > > Configuring mtl-1.1.0.2... > > Preprocessing library mtl-1.1.0.2... > > ... > > Registering syb-0.1.0.3... > > cabal: ghc-pkg: : hGetContents: invalid argument > (invalid UTF-8 byte > > sequence) > > cabal: Error: some packages failed to install: > > language-c-quote-0.1 depends on syb-0.1.0.3 which > failed to install. > > syb-0.1.0.3 failed during the building phase. The exception was: > > exit: ExitFailure 1 > > > > The full trace is included below. > > Here's the version information for the ghc I am running. > > > > > Kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/ > sw/ghc-head/bin/ghc --version > > The Glorious Glasgow Haskell Compilation System, > version 6.13.20100210 > > > The cabal website suggests sending questions to this list... > > Any suggestions for how to fix this problem? > > Kathleen > > > > > > kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/ > .cabal/bin/cabal install -w ~/sw/ghc-head/bin/ghc > > Resolving dependencies... > > Downloading mtl-1.1.0.2... > > Configuring mtl-1.1.0.2... > > Preprocessing library mtl-1.1.0.2... > > Building mtl-1.1.0.2... > > > > ...stuff deleted... > > > > src/Data/Generics.hs:40:1: > > Warning: The import of `Prelude' is redundant > > except perhaps to import instances from `Prelude' > > To import instances alone, use: import Prelude() > > Registering syb-0.1.0.3... > > cabal: ghc-pkg: : hGetContents: invalid argument > (invalid UTF-8 byte > > sequence) > > cabal: Error: some packages failed to install: > > language-c-quote-0.1 depends on syb-0.1.0.3 which > failed to install. > > syb-0.1.0.3 failed during the building phase. The exception was: > > exit: ExitFailure 1 > > > > ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ***************************************************************** From jpm at cs.uu.nl Tue Feb 23 10:10:05 2010 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Tue Feb 23 09:40:54 2010 Subject: Installing syb(-0.1.03) package in head version of Haskell In-Reply-To: <125EACD0CAE4D24ABDB4D148C4593DA911026775@GBLONXMB02.corp.amvescap.net> References: <59543203684B2244980D7E4057D5FBC10B08D018@DB3EX14MBXC312.europe.corp.microsoft.com> <125EACD0CAE4D24ABDB4D148C4593DA911026775@GBLONXMB02.corp.amvescap.net> Message-ID: <52f14b211002230710o3c701353w2ec32aeb76c41e79@mail.gmail.com> I'm guessing that is indeed the problem, though I cannot reproduce the error (but I'm using Cabal-1.8.0.2). Assuming this is the cause of the problem, what is the best correction? Encoding the cabal file as UTF-8 or removing the accent? Do earlier versions of cabal deal well with UTF-8?... Cheers, Pedro On Tue, Feb 23, 2010 at 16:05, Bayley, Alistair wrote: > Just a wild guess, but the package description has this non-ascii text: > > author: Ralf L?mmel, Simon Peyton Jones > > It could well be Latin-1 encoded, rather than UTF8. > > Try editing the author field to this: > > author: Ralf Laemmel, Simon Peyton Jones > > and rebuilding/installing. > > > -----Original Message----- > > From: glasgow-haskell-users-bounces@haskell.org > > [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf > > Of Simon Peyton-Jones > > Sent: 23 February 2010 14:32 > > To: GHC users > > Cc: cvs-ghc@haskell.org > > Subject: FW: Installing syb(-0.1.03) package in head version > > of Haskell > > > > Friends > > > > > > > > Can anyone help Kathleen out? She has a cabal-install issue. > > I think she's on a Mac. > > > > > > > > Many thanks > > > > > > Simon > > > > > > > > From: Kathleen Fisher [mailto:kathleen.fisher@gmail.com] > > Sent: 16 February 2010 22:54 > > To: Simon Peyton-Jones > > Subject: Fwd: Installing syb(-0.1.03) package in head version > > of Haskell > > > > > > > > Hi Simon, > > > > > > > > I'm trying to get the PADS file we were working on compiling > > under the HEAD version of Haskell, but I'm having trouble > > getting the Data.Generics module to install. I sent the > > question below to the libraries@haskell.org last week, but I > > haven't seen any replies. Is that the right address? Or is > > there a different place to ask such questions? > > > > > > > > Thanks for any pointers! > > > > > > > > Kathleen > > > > > > > > Begin forwarded message: > > > > > > > > > > > > From: Kathleen Fisher > > > > Date: February 11, 2010 2:28:20 PM PST > > > > To: libraries@haskell.org > > > > Subject: Installing syb(-0.1.03) package in head version of Haskell > > > > > > > > Hi all, > > > > I'm trying to get a program that uses the Data.Generics > > module to compile under the head version of GHC, but I am > > having trouble getting the syb package installed. > > > > I believe I am using the most recent version of cabal: > > > > > > > > > > kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/ > > .cabal/bin/cabal --version > > > > cabal-install version 0.8.0 > > > > using version 1.8.0.1 of the Cabal library > > > > > > When I ask cabal to install the syb package, I get the > > following error: > > > > > > > > > > kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/ > > .cabal/bin/cabal install -w ~/sw/ghc-head/bin/ghc > > > > Resolving dependencies... > > > > Downloading mtl-1.1.0.2... > > > > Configuring mtl-1.1.0.2... > > > > Preprocessing library mtl-1.1.0.2... > > > > ... > > > > Registering syb-0.1.0.3... > > > > cabal: ghc-pkg: : hGetContents: invalid argument > > (invalid UTF-8 byte > > > > sequence) > > > > cabal: Error: some packages failed to install: > > > > language-c-quote-0.1 depends on syb-0.1.0.3 which > > failed to install. > > > > syb-0.1.0.3 failed during the building phase. The exception was: > > > > exit: ExitFailure 1 > > > > > > > > The full trace is included below. > > > > Here's the version information for the ghc I am running. > > > > > > > > > > Kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/ > > sw/ghc-head/bin/ghc --version > > > > The Glorious Glasgow Haskell Compilation System, > > version 6.13.20100210 > > > > > > The cabal website suggests sending questions to this list... > > > > Any suggestions for how to fix this problem? > > > > Kathleen > > > > > > > > > > > > kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/ > > .cabal/bin/cabal install -w ~/sw/ghc-head/bin/ghc > > > > Resolving dependencies... > > > > Downloading mtl-1.1.0.2... > > > > Configuring mtl-1.1.0.2... > > > > Preprocessing library mtl-1.1.0.2... > > > > Building mtl-1.1.0.2... > > > > > > > > ...stuff deleted... > > > > > > > > src/Data/Generics.hs:40:1: > > > > Warning: The import of `Prelude' is redundant > > > > except perhaps to import instances from `Prelude' > > > > To import instances alone, use: import Prelude() > > > > Registering syb-0.1.0.3... > > > > cabal: ghc-pkg: : hGetContents: invalid argument > > (invalid UTF-8 byte > > > > sequence) > > > > cabal: Error: some packages failed to install: > > > > language-c-quote-0.1 depends on syb-0.1.0.3 which > > failed to install. > > > > syb-0.1.0.3 failed during the building phase. The exception was: > > > > exit: ExitFailure 1 > > > > > > > > > ***************************************************************** > Confidentiality Note: The information contained in this message, > and any attachments, may contain confidential and/or privileged > material. It is intended solely for the person(s) or entity to > which it is addressed. Any review, retransmission, dissemination, > or taking of any action in reliance upon this information by > persons or entities other than the intended recipient(s) is > prohibited. If you received this in error, please contact the > sender and delete the material from any computer. > ***************************************************************** > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100223/cc000eb8/attachment.html From simonpj at microsoft.com Tue Feb 23 10:18:55 2010 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Feb 23 09:50:02 2010 Subject: Installing syb(-0.1.03) package in head version of Haskell In-Reply-To: <52f14b211002230710o3c701353w2ec32aeb76c41e79@mail.gmail.com> References: <59543203684B2244980D7E4057D5FBC10B08D018@DB3EX14MBXC312.europe.corp.microsoft.com> <125EACD0CAE4D24ABDB4D148C4593DA911026775@GBLONXMB02.corp.amvescap.net> <52f14b211002230710o3c701353w2ec32aeb76c41e79@mail.gmail.com> Message-ID: <59543203684B2244980D7E4057D5FBC10B08E351@DB3EX14MBXC312.europe.corp.microsoft.com> Thanks! I forgot to cc Kathleen herself, so I'm now doing so. Assuming that's the problem, does it reflect a bug in Cabal, or GHC, or what? And if so, can someone make a ticket?] Thanks Simon From: Jos? Pedro Magalh?es [mailto:jpm@cs.uu.nl] Sent: 23 February 2010 15:10 To: Bayley, Alistair Cc: Simon Peyton-Jones; GHC users; cvs-ghc@haskell.org Subject: Re: Installing syb(-0.1.03) package in head version of Haskell I'm guessing that is indeed the problem, though I cannot reproduce the error (but I'm using Cabal-1.8.0.2). Assuming this is the cause of the problem, what is the best correction? Encoding the cabal file as UTF-8 or removing the accent? Do earlier versions of cabal deal well with UTF-8?... Cheers, Pedro On Tue, Feb 23, 2010 at 16:05, Bayley, Alistair > wrote: Just a wild guess, but the package description has this non-ascii text: author: Ralf L?mmel, Simon Peyton Jones It could well be Latin-1 encoded, rather than UTF8. Try editing the author field to this: author: Ralf Laemmel, Simon Peyton Jones and rebuilding/installing. > -----Original Message----- > From: glasgow-haskell-users-bounces@haskell.org > [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf > Of Simon Peyton-Jones > Sent: 23 February 2010 14:32 > To: GHC users > Cc: cvs-ghc@haskell.org > Subject: FW: Installing syb(-0.1.03) package in head version > of Haskell > > Friends > > > > Can anyone help Kathleen out? She has a cabal-install issue. > I think she's on a Mac. > > > > Many thanks > > > Simon > > > > From: Kathleen Fisher [mailto:kathleen.fisher@gmail.com] > Sent: 16 February 2010 22:54 > To: Simon Peyton-Jones > Subject: Fwd: Installing syb(-0.1.03) package in head version > of Haskell > > > > Hi Simon, > > > > I'm trying to get the PADS file we were working on compiling > under the HEAD version of Haskell, but I'm having trouble > getting the Data.Generics module to install. I sent the > question below to the libraries@haskell.org last week, but I > haven't seen any replies. Is that the right address? Or is > there a different place to ask such questions? > > > > Thanks for any pointers! > > > > Kathleen > > > > Begin forwarded message: > > > > > > From: Kathleen Fisher > > > Date: February 11, 2010 2:28:20 PM PST > > To: libraries@haskell.org > > Subject: Installing syb(-0.1.03) package in head version of Haskell > > > > Hi all, > > I'm trying to get a program that uses the Data.Generics > module to compile under the head version of GHC, but I am > having trouble getting the syb package installed. > > I believe I am using the most recent version of cabal: > > > > > kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/ > .cabal/bin/cabal --version > > cabal-install version 0.8.0 > > using version 1.8.0.1 of the Cabal library > > > When I ask cabal to install the syb package, I get the > following error: > > > > > kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/ > .cabal/bin/cabal install -w ~/sw/ghc-head/bin/ghc > > Resolving dependencies... > > Downloading mtl-1.1.0.2... > > Configuring mtl-1.1.0.2... > > Preprocessing library mtl-1.1.0.2... > > ... > > Registering syb-0.1.0.3... > > cabal: ghc-pkg: : hGetContents: invalid argument > (invalid UTF-8 byte > > sequence) > > cabal: Error: some packages failed to install: > > language-c-quote-0.1 depends on syb-0.1.0.3 which > failed to install. > > syb-0.1.0.3 failed during the building phase. The exception was: > > exit: ExitFailure 1 > > > > The full trace is included below. > > Here's the version information for the ghc I am running. > > > > > Kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/ > sw/ghc-head/bin/ghc --version > > The Glorious Glasgow Haskell Compilation System, > version 6.13.20100210 > > > The cabal website suggests sending questions to this list... > > Any suggestions for how to fix this problem? > > Kathleen > > > > > > kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/ > .cabal/bin/cabal install -w ~/sw/ghc-head/bin/ghc > > Resolving dependencies... > > Downloading mtl-1.1.0.2... > > Configuring mtl-1.1.0.2... > > Preprocessing library mtl-1.1.0.2... > > Building mtl-1.1.0.2... > > > > ...stuff deleted... > > > > src/Data/Generics.hs:40:1: > > Warning: The import of `Prelude' is redundant > > except perhaps to import instances from `Prelude' > > To import instances alone, use: import Prelude() > > Registering syb-0.1.0.3... > > cabal: ghc-pkg: : hGetContents: invalid argument > (invalid UTF-8 byte > > sequence) > > cabal: Error: some packages failed to install: > > language-c-quote-0.1 depends on syb-0.1.0.3 which > failed to install. > > syb-0.1.0.3 failed during the building phase. The exception was: > > exit: ExitFailure 1 > > > > ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ***************************************************************** _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100223/98563988/attachment-0001.html From ross at soi.city.ac.uk Tue Feb 23 11:12:21 2010 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Feb 23 10:43:21 2010 Subject: Installing syb(-0.1.03) package in head version of Haskell In-Reply-To: <125EACD0CAE4D24ABDB4D148C4593DA911026775@GBLONXMB02.corp.amvescap.net> References: <59543203684B2244980D7E4057D5FBC10B08D018@DB3EX14MBXC312.europe.corp.microsoft.com> <125EACD0CAE4D24ABDB4D148C4593DA911026775@GBLONXMB02.corp.amvescap.net> Message-ID: <20100223161221.GA12250@soi.city.ac.uk> On Tue, Feb 23, 2010 at 03:05:56PM -0000, Bayley, Alistair wrote: > Just a wild guess, but the package description has this non-ascii text: > > author: Ralf L?mmel, Simon Peyton Jones > > It could well be Latin-1 encoded, rather than UTF8. No, syb-0.1.0.3/syb.cabal is UTF-8-encoded (conforming to the Cabal docs). > Try editing the author field to this: > > author: Ralf Laemmel, Simon Peyton Jones > > and rebuilding/installing. If it's a ghc-pkg problem, that might work. From naur at post11.tele.dk Tue Feb 23 12:34:45 2010 From: naur at post11.tele.dk (naur@post11.tele.dk) Date: Tue Feb 23 12:05:13 2010 Subject: integer-simple by default References: <1f3dc80d1002191811q63193476vf6924a5b5127fd8f@mail.gmail.com> <20100221181408.GA18871@matrix.chaos.earth.li> <4B8181F6.60704@isaac.cedarswampstudios.org> <201002212018.38442.daniel.is.fischer@web.de> <2608b8a81002221052p12054876yacf40578f346d1c0@mail.gmail.com> <1f3dc80d1002221215k463ce5cfoa3594b4a93c0a573@mail.gmail.com> <2608b8a81002221504v32eccdc2ra4cfff7ffdd9b879@mail.gmail.com> Message-ID: <20100223173445.WVPG9950.fep53.mail.dk@post.tele.dk> Hello, Yet another data point would be my current use of Haskell in various integer factorization activities where I would consider the performance, even for relatively large integers (say, 100-1000 decimal digits) very important. However, I wouldn't complain if some simple and manageable implementation were introduced, as long as the re-introduction of the efficient use of some well-tuned library (like GMP) were not hampered needlessly. Best regards Thorkil ----- Original meddelelse ----- > Fra: Yitzchak Gale > Til: Greg Fitzgerald > Cc: glasgow-haskell-users@haskell.org > Dato: Tir, 23. feb 2010 00:04 > Emne: Re: integer-simple by default > > I wrote: > >> As another data point, Python has also re-invented the GMP > >> wheel, likely for the same licensing reasons. They have > >> been using a simple implementation of Karatsuba > >> multiplication for years. I have never heard of anyone > >> complaining about it > > Greg Fitzgerald wrote: > > Looks like they swapped out their integer implementation for > Python3 > > Interesting! This will be new in Python 3.2 - the first changes in > many > years. It's not exactly swapped out, but there are many changes. > At first glance, it looks like better 64-bit support, a new > division > algorithm via floating-point, a new exponentiation algorithm > using a 5-bits-at-a-time trick in some cases, optimized Read > and Show instances (pardon the expression), a few other things. > A lot of the new stuff seems to be from HAC. As before, everything > is fully explained in expository comments inside the code, with > references; a worthwhile read. Multiplication is still the same > basic > idea though - naive up to about 2000 bits, followed by just > Karatsuba and nothing more. > > Thanks, > Yitz > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From jeremy at n-heptane.com Tue Feb 23 13:41:10 2010 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Tue Feb 23 13:11:38 2010 Subject: Installing syb(-0.1.03) package in head version of Haskell In-Reply-To: <20100223161221.GA12250@soi.city.ac.uk> References: <59543203684B2244980D7E4057D5FBC10B08D018@DB3EX14MBXC312.europe.corp.microsoft.com> <125EACD0CAE4D24ABDB4D148C4593DA911026775@GBLONXMB02.corp.amvescap.net> <20100223161221.GA12250@soi.city.ac.uk> Message-ID: On Tue, Feb 23, 2010 at 10:12 AM, Ross Paterson wrote: > On Tue, Feb 23, 2010 at 03:05:56PM -0000, Bayley, Alistair wrote: > > Just a wild guess, but the package description has this non-ascii text: > > > > author: Ralf L?mmel, Simon Peyton Jones > > > > It could well be Latin-1 encoded, rather than UTF8. > > No, syb-0.1.0.3/syb.cabal is UTF-8-encoded (conforming to the Cabal docs). I had similar issues when attempting to install a new version of syb over an old version[1]. I had to open this file in emacs: /usr/lib/ghc-6.13/package.conf.d/syb-0.1.0.3.conf and the do: M-x set-buffer-file-coding-system utf-8 I think there was a point in time where something wrote contains to that file as latin1 instead of utf-8 or something. - jeremy [1] it might have actually been the same version of syb, but rebuilt with a different version of the compiler or something.. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100223/f1268e60/attachment.html From Christian.Maeder at dfki.de Tue Feb 23 13:46:56 2010 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Feb 23 13:17:24 2010 Subject: Installing syb(-0.1.03) package in head version of Haskell In-Reply-To: <20100223161221.GA12250@soi.city.ac.uk> References: <59543203684B2244980D7E4057D5FBC10B08D018@DB3EX14MBXC312.europe.corp.microsoft.com> <125EACD0CAE4D24ABDB4D148C4593DA911026775@GBLONXMB02.corp.amvescap.net> <20100223161221.GA12250@soi.city.ac.uk> Message-ID: <4B8422A0.50506@dfki.de> Ross Paterson schrieb: > On Tue, Feb 23, 2010 at 03:05:56PM -0000, Bayley, Alistair wrote: >> Just a wild guess, but the package description has this non-ascii text: >> >> author: Ralf L?mmel, Simon Peyton Jones >> >> It could well be Latin-1 encoded, rather than UTF8. > > No, syb-0.1.0.3/syb.cabal is UTF-8-encoded (conforming to the Cabal docs). My guess would be that the "locale" is not properly set. The environment variable LANG should be set to something shown by "locale -a" (i.e en_GB). Other LC_* variables should not be set. The variables should not be "C" or "POSIX". (I was able to install syb-0.1.0.3 without a problem) Cheers Christian >> Try editing the author field to this: >> >> author: Ralf Laemmel, Simon Peyton Jones >> >> and rebuilding/installing. > > If it's a ghc-pkg problem, that might work. From lennart at augustsson.net Tue Feb 23 14:25:38 2010 From: lennart at augustsson.net (Lennart Augustsson) Date: Tue Feb 23 13:56:08 2010 Subject: Shared GHC libraries and the runtime system In-Reply-To: <9d4d38821002221400o6e78c672g856760514353c7d0@mail.gmail.com> References: <201002221634.27387.twhitehead@gmail.com> <9d4d38821002221400o6e78c672g856760514353c7d0@mail.gmail.com> Message-ID: The usual way to do this would be to include the dependency on the RTS in the library and then vary the RTS by using LD_PRELOAD. I think ghc does it the wrong way. -- Lennart On Mon, Feb 22, 2010 at 10:00 PM, Max Bolingbroke wrote: > Hi Tyson, > > This blog post (http://blog.well-typed.com/2009/05/buildings-plugins-as-haskell-shared-libs/) > might help explain the ?motivation (actually there are a few relevant > posts on the well-typed site). > > Essentially, I believe that this is done so that you can vary the RTS > by changing LD_LIBRARY_PATH. I've never used this facility so I'm > unable to say how useful this actually is (or if it actually works at > the moment). > > Cheers, > Max > > On 22 February 2010 21:34, Tyson Whitehead wrote: >> I was working on a shared library that loads up the GHC runtime (via hs_init) >> and have been running into a bunch of undefined stg symbols. >> >> A bit of digging and it seems that GHC doesn't embed >> >> ?- the dependency libHSrts-ghc6.12.1.so, and >> ?- the associated rpath /usr/lib/ghc-6.12.1 >> >> into shared libraries that it builds. ?Thus, if your main executable isn't GHC >> generated (and hence has these), you run into unresolved symbols. >> >> I can work around this by manually adding them myself. ?Is there any reason >> GHC can't put this information by default into shared libraries though? >> >> Thanks! ?-Tyson >> >> PS: ?Further digging into the various shared libraries packaged with GHC >> (Debian GHC package 6.12.1-2) reveal that they are actually missing >> >> ?- the dependency libHSrts-ghc6.12.1.so, and >> ?- all rpaths (i.e., there are absolutely no rpaths in any of them) >> >> $ objdump -p /usr/lib/ghc-6.12.1/base-4.2.0.0/libHSbase-4.2.0.0-ghc6.12.1.so >> ... >> Dynamic Section: >> ?NEEDED ? ? ?libHSinteger-gmp-0.2.0.0-ghc6.12.1.so >> ?NEEDED ? ? ?libgmp.so.3 >> ?NEEDED ? ? ?libHSghc-prim-0.2.0.0-ghc6.12.1.so >> ?NEEDED ? ? ?libc.so.6 >> ?SONAME ? ? ?libHSbase-4.2.0.0-ghc6.12.1.so >> ... >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From aslatter at gmail.com Tue Feb 23 15:01:23 2010 From: aslatter at gmail.com (Antoine Latter) Date: Tue Feb 23 14:31:53 2010 Subject: Installing syb(-0.1.03) package in head version of Haskell In-Reply-To: <4B8422A0.50506@dfki.de> References: <59543203684B2244980D7E4057D5FBC10B08D018@DB3EX14MBXC312.europe.corp.microsoft.com> <125EACD0CAE4D24ABDB4D148C4593DA911026775@GBLONXMB02.corp.amvescap.net> <20100223161221.GA12250@soi.city.ac.uk> <4B8422A0.50506@dfki.de> Message-ID: <694519c51002231201y5e1187eeq4a34ec5f5fdee783@mail.gmail.com> On Tue, Feb 23, 2010 at 12:46 PM, Christian Maeder wrote: > Ross Paterson schrieb: >> On Tue, Feb 23, 2010 at 03:05:56PM -0000, Bayley, Alistair wrote: >>> Just a wild guess, but the package description has this non-ascii text: >>> >>> author: ? ? ? ? ? ? ? ? Ralf L?mmel, Simon Peyton Jones >>> >>> It could well be Latin-1 encoded, rather than UTF8. >> >> No, syb-0.1.0.3/syb.cabal is UTF-8-encoded (conforming to the Cabal docs). > > My guess would be that the "locale" is not properly set. The environment > variable LANG should be set to something shown by "locale -a" (i.e > en_GB). Other LC_* variables should not be set. > The variables should not be "C" or "POSIX". > > (I was able to install syb-0.1.0.3 without a problem) > > Cheers Christian > If we're relying on the locale being set properly is the fix then to force to always read in Cabal package descriptions as UTF-8? Antoine From marlowsd at gmail.com Tue Feb 23 16:49:30 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Feb 23 16:20:01 2010 Subject: Installing syb(-0.1.03) package in head version of Haskell In-Reply-To: <4B8422A0.50506@dfki.de> References: <59543203684B2244980D7E4057D5FBC10B08D018@DB3EX14MBXC312.europe.corp.microsoft.com> <125EACD0CAE4D24ABDB4D148C4593DA911026775@GBLONXMB02.corp.amvescap.net> <20100223161221.GA12250@soi.city.ac.uk> <4B8422A0.50506@dfki.de> Message-ID: <4B844D6A.7080309@gmail.com> On 23/02/10 18:46, Christian Maeder wrote: > Ross Paterson schrieb: >> On Tue, Feb 23, 2010 at 03:05:56PM -0000, Bayley, Alistair wrote: >>> Just a wild guess, but the package description has this non-ascii text: >>> >>> author: Ralf L?mmel, Simon Peyton Jones >>> >>> It could well be Latin-1 encoded, rather than UTF8. >> >> No, syb-0.1.0.3/syb.cabal is UTF-8-encoded (conforming to the Cabal docs). > > My guess would be that the "locale" is not properly set. The environment > variable LANG should be set to something shown by "locale -a" (i.e > en_GB). Other LC_* variables should not be set. > The variables should not be "C" or "POSIX". > > (I was able to install syb-0.1.0.3 without a problem) Both Cabal and ghc-pkg explicitly use UTF-8 for handling .cabal and package configuration files, so if you end up with a Latin-1 file in your package database then something has gone wrong. If anyone can reproduce this problem then please submit a ticket. Cheers, Simon From allbery at ece.cmu.edu Tue Feb 23 23:19:46 2010 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Feb 23 22:50:15 2010 Subject: GHC FFI stub files In-Reply-To: <201002212346.19241.twhitehead@gmail.com> References: <201002212346.19241.twhitehead@gmail.com> Message-ID: <1B87CD24-4370-429A-A5C1-56D1FE136C4E@ece.cmu.edu> On Feb 21, 2010, at 23:46 , Tyson Whitehead wrote: > I'm writing a perl module that interfaces some haskell code and its > a bit of a > pain because both perl and ghc have their own custom build system. > > Is there a way to get ghc to give you the gcc/as/ld options (library > paths, > include paths, flags, etc) required for the FFI stub files it > generates? -n -v3 might be helpful. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100223/aee4515e/PGP-0001.bin From paqui.lucio at ehu.es Wed Feb 24 04:45:32 2010 From: paqui.lucio at ehu.es (Paqui Lucio) Date: Wed Feb 24 04:16:02 2010 Subject: create a DLL when using Gtk2hs Message-ID: Hi, I am trying to generate a DLL for a Haskell program that imports Graphics.UI.Gtk from the Gtk2hs package. I have try to use the files .o that are in the Gtk2hs folder created by the package installer, but it does not work. Does somebody knows, how to generate a DLL when this package is used? Thanks in advance, Paqui --------------------------------- Paqui Lucio Dpto de LSI Facultad de Inform?tica Paseo Manuel de Lardizabal, 1 20080-San Sebasti?n SPAIN --------------------------------- e-mail: paqui.lucio@ehu.es Tfn: (+34) (9)43 015049 Fax: (+34) (9)43 015590 Web: http://www.sc.ehu.es/paqui --------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100224/cda8cbc8/attachment.html From Christian.Maeder at dfki.de Wed Feb 24 05:07:26 2010 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Feb 24 04:38:00 2010 Subject: Installing syb(-0.1.03) package in head version of Haskell In-Reply-To: <4B844D6A.7080309@gmail.com> References: <59543203684B2244980D7E4057D5FBC10B08D018@DB3EX14MBXC312.europe.corp.microsoft.com> <125EACD0CAE4D24ABDB4D148C4593DA911026775@GBLONXMB02.corp.amvescap.net> <20100223161221.GA12250@soi.city.ac.uk> <4B8422A0.50506@dfki.de> <4B844D6A.7080309@gmail.com> Message-ID: <4B84FA5E.6030100@dfki.de> Simon Marlow schrieb: > On 23/02/10 18:46, Christian Maeder wrote: >> Ross Paterson schrieb: >>> On Tue, Feb 23, 2010 at 03:05:56PM -0000, Bayley, Alistair wrote: >>>> Just a wild guess, but the package description has this non-ascii text: >>>> >>>> author: Ralf L?mmel, Simon Peyton Jones >>>> >>>> It could well be Latin-1 encoded, rather than UTF8. >>> >>> No, syb-0.1.0.3/syb.cabal is UTF-8-encoded (conforming to the Cabal >>> docs). >> >> My guess would be that the "locale" is not properly set. The environment >> variable LANG should be set to something shown by "locale -a" (i.e >> en_GB). Other LC_* variables should not be set. >> The variables should not be "C" or "POSIX". >> >> (I was able to install syb-0.1.0.3 without a problem) > > Both Cabal and ghc-pkg explicitly use UTF-8 for handling .cabal and > package configuration files, so if you end up with a Latin-1 file in > your package database then something has gone wrong. If anyone can > reproduce this problem then please submit a ticket. Indeed, I have a latin-1 file /local/maeder/lib/ghc-6.13.20100211/package.conf.d/syb-0.1.0.3-2d8f18fd3343792a85816b191d973cea.conf: ISO-8859 English text and my (accidental) setting is: LANG=de_DE@euro LANGUAGE= LC_ALL=C Cheers Christian My ghc-6.12.1 uses syb-0.1.0.2 (which is ASCII) From marlowsd at gmail.com Wed Feb 24 06:22:41 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Feb 24 05:53:27 2010 Subject: Installing syb(-0.1.03) package in head version of Haskell In-Reply-To: <4B84FA5E.6030100@dfki.de> References: <59543203684B2244980D7E4057D5FBC10B08D018@DB3EX14MBXC312.europe.corp.microsoft.com> <125EACD0CAE4D24ABDB4D148C4593DA911026775@GBLONXMB02.corp.amvescap.net> <20100223161221.GA12250@soi.city.ac.uk> <4B8422A0.50506@dfki.de> <4B844D6A.7080309@gmail.com> <4B84FA5E.6030100@dfki.de> Message-ID: <4B850C01.8040800@gmail.com> On 24/02/2010 10:07, Christian Maeder wrote: > Simon Marlow schrieb: >> On 23/02/10 18:46, Christian Maeder wrote: >>> Ross Paterson schrieb: >>>> On Tue, Feb 23, 2010 at 03:05:56PM -0000, Bayley, Alistair wrote: >>>>> Just a wild guess, but the package description has this non-ascii text: >>>>> >>>>> author: Ralf L?mmel, Simon Peyton Jones >>>>> >>>>> It could well be Latin-1 encoded, rather than UTF8. >>>> >>>> No, syb-0.1.0.3/syb.cabal is UTF-8-encoded (conforming to the Cabal >>>> docs). >>> >>> My guess would be that the "locale" is not properly set. The environment >>> variable LANG should be set to something shown by "locale -a" (i.e >>> en_GB). Other LC_* variables should not be set. >>> The variables should not be "C" or "POSIX". >>> >>> (I was able to install syb-0.1.0.3 without a problem) >> >> Both Cabal and ghc-pkg explicitly use UTF-8 for handling .cabal and >> package configuration files, so if you end up with a Latin-1 file in >> your package database then something has gone wrong. If anyone can >> reproduce this problem then please submit a ticket. > > Indeed, I have a latin-1 file > > /local/maeder/lib/ghc-6.13.20100211/package.conf.d/syb-0.1.0.3-2d8f18fd3343792a85816b191d973cea.conf: > ISO-8859 English text > > and my (accidental) setting is: > > LANG=de_DE@euro > LANGUAGE= > LC_ALL=C And you got that by just 'cabal install syb'? What version of cabal-install? (cabal --version) Cheers, Simon From Christian.Maeder at dfki.de Wed Feb 24 06:35:14 2010 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Feb 24 06:05:40 2010 Subject: Installing syb(-0.1.03) package in head version of Haskell In-Reply-To: <4B850C01.8040800@gmail.com> References: <59543203684B2244980D7E4057D5FBC10B08D018@DB3EX14MBXC312.europe.corp.microsoft.com> <125EACD0CAE4D24ABDB4D148C4593DA911026775@GBLONXMB02.corp.amvescap.net> <20100223161221.GA12250@soi.city.ac.uk> <4B8422A0.50506@dfki.de> <4B844D6A.7080309@gmail.com> <4B84FA5E.6030100@dfki.de> <4B850C01.8040800@gmail.com> Message-ID: <4B850EF2.7080405@dfki.de> Simon Marlow schrieb: >>> Both Cabal and ghc-pkg explicitly use UTF-8 for handling .cabal and >>> package configuration files, so if you end up with a Latin-1 file in >>> your package database then something has gone wrong. If anyone can >>> reproduce this problem then please submit a ticket. >> >> Indeed, I have a latin-1 file >> >> /local/maeder/lib/ghc-6.13.20100211/package.conf.d/syb-0.1.0.3-2d8f18fd3343792a85816b191d973cea.conf: >> >> ISO-8859 English text >> >> and my (accidental) setting is: >> >> LANG=de_DE@euro >> LANGUAGE= >> LC_ALL=C > > And you got that by just 'cabal install syb'? What version of > cabal-install? (cabal --version) No, just by the Setup, configure, build, install procedure. "ghc-pkg describe syb" and "ghc-pkg dump" create UTF-8 output. Christian From marlowsd at gmail.com Wed Feb 24 07:14:19 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Feb 24 06:44:55 2010 Subject: Installing syb(-0.1.03) package in head version of Haskell In-Reply-To: <4B850EF2.7080405@dfki.de> References: <59543203684B2244980D7E4057D5FBC10B08D018@DB3EX14MBXC312.europe.corp.microsoft.com> <125EACD0CAE4D24ABDB4D148C4593DA911026775@GBLONXMB02.corp.amvescap.net> <20100223161221.GA12250@soi.city.ac.uk> <4B8422A0.50506@dfki.de> <4B844D6A.7080309@gmail.com> <4B84FA5E.6030100@dfki.de> <4B850C01.8040800@gmail.com> <4B850EF2.7080405@dfki.de> Message-ID: <4B85181B.4020206@gmail.com> On 24/02/2010 11:35, Christian Maeder wrote: > Simon Marlow schrieb: >>>> Both Cabal and ghc-pkg explicitly use UTF-8 for handling .cabal and >>>> package configuration files, so if you end up with a Latin-1 file in >>>> your package database then something has gone wrong. If anyone can >>>> reproduce this problem then please submit a ticket. >>> >>> Indeed, I have a latin-1 file >>> >>> /local/maeder/lib/ghc-6.13.20100211/package.conf.d/syb-0.1.0.3-2d8f18fd3343792a85816b191d973cea.conf: >>> >>> ISO-8859 English text >>> >>> and my (accidental) setting is: >>> >>> LANG=de_DE@euro >>> LANGUAGE= >>> LC_ALL=C >> >> And you got that by just 'cabal install syb'? What version of >> cabal-install? (cabal --version) > > No, just by the Setup, configure, build, install procedure. > > "ghc-pkg describe syb" and "ghc-pkg dump" create UTF-8 output. Aha, I think I see where the bug is. Thanks folks, we'll have it fixed in 6.12.2. In the meantime you should use a UTF-8 locale, eg. LANG=en_US.utf8. Cheers, Simon From Christian.Maeder at dfki.de Wed Feb 24 07:28:05 2010 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Feb 24 06:58:31 2010 Subject: Installing syb(-0.1.03) package in head version of Haskell In-Reply-To: <4B85181B.4020206@gmail.com> References: <59543203684B2244980D7E4057D5FBC10B08D018@DB3EX14MBXC312.europe.corp.microsoft.com> <125EACD0CAE4D24ABDB4D148C4593DA911026775@GBLONXMB02.corp.amvescap.net> <20100223161221.GA12250@soi.city.ac.uk> <4B8422A0.50506@dfki.de> <4B844D6A.7080309@gmail.com> <4B84FA5E.6030100@dfki.de> <4B850C01.8040800@gmail.com> <4B850EF2.7080405@dfki.de> <4B85181B.4020206@gmail.com> Message-ID: <4B851B55.7020604@dfki.de> Simon Marlow schrieb: > On 24/02/2010 11:35, Christian Maeder wrote: >> Simon Marlow schrieb: >>>>> Both Cabal and ghc-pkg explicitly use UTF-8 for handling .cabal and >>>>> package configuration files, so if you end up with a Latin-1 file in >>>>> your package database then something has gone wrong. If anyone can >>>>> reproduce this problem then please submit a ticket. >>>> >>>> Indeed, I have a latin-1 file >>>> >>>> /local/maeder/lib/ghc-6.13.20100211/package.conf.d/syb-0.1.0.3-2d8f18fd3343792a85816b191d973cea.conf: >>>> >>>> >>>> ISO-8859 English text >>>> >>>> and my (accidental) setting is: >>>> >>>> LANG=de_DE@euro Right, this is a latin1 locale and the whole compiler was created with this setting. I think "ghc-pkg upate - ..." creates the latin1 file. (I've some latin1 source files that need this setting.) >>>> LANGUAGE= >>>> LC_ALL=C The LANGUAGE variable is properly a left-over typing error and not relevant. And "LC_ALL" does not seem to take precedence over LANG on my (SuSE) system. >>> And you got that by just 'cabal install syb'? What version of >>> cabal-install? (cabal --version) >> >> No, just by the Setup, configure, build, install procedure. >> >> "ghc-pkg describe syb" and "ghc-pkg dump" create UTF-8 output. > > Aha, I think I see where the bug is. Thanks folks, we'll have it fixed > in 6.12.2. In the meantime you should use a UTF-8 locale, eg. > LANG=en_US.utf8. It is not sufficient for me to reinstall this package with this utf8 setting. (I think ghc-pkg needs to be fixed or maybe recompiled under utf8.) Cheers Christian From marlowsd at gmail.com Wed Feb 24 08:22:07 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Feb 24 07:52:45 2010 Subject: Installing syb(-0.1.03) package in head version of Haskell In-Reply-To: <4B851B55.7020604@dfki.de> References: <59543203684B2244980D7E4057D5FBC10B08D018@DB3EX14MBXC312.europe.corp.microsoft.com> <125EACD0CAE4D24ABDB4D148C4593DA911026775@GBLONXMB02.corp.amvescap.net> <20100223161221.GA12250@soi.city.ac.uk> <4B8422A0.50506@dfki.de> <4B844D6A.7080309@gmail.com> <4B84FA5E.6030100@dfki.de> <4B850C01.8040800@gmail.com> <4B850EF2.7080405@dfki.de> <4B85181B.4020206@gmail.com> <4B851B55.7020604@dfki.de> Message-ID: <4B8527FF.6090907@gmail.com> On 24/02/2010 12:28, Christian Maeder wrote: >>>> And you got that by just 'cabal install syb'? What version of >>>> cabal-install? (cabal --version) >>> >>> No, just by the Setup, configure, build, install procedure. >>> >>> "ghc-pkg describe syb" and "ghc-pkg dump" create UTF-8 output. >> >> Aha, I think I see where the bug is. Thanks folks, we'll have it fixed >> in 6.12.2. In the meantime you should use a UTF-8 locale, eg. >> LANG=en_US.utf8. > > It is not sufficient for me to reinstall this package with this utf8 > setting. (I think ghc-pkg needs to be fixed or maybe recompiled under utf8.) There was a missing hSetEncoding, so that ghc-pkg is writing this file using the current locale rather than UTF-8, but reading it back as UTF-8. So I'm surprised that temporarily setting your locale to UTF-8 doesn't work around it - what happens? Cheers, Simon From Christian.Maeder at dfki.de Wed Feb 24 09:08:08 2010 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Feb 24 08:38:35 2010 Subject: Installing syb(-0.1.03) package in head version of Haskell In-Reply-To: <4B8527FF.6090907@gmail.com> References: <59543203684B2244980D7E4057D5FBC10B08D018@DB3EX14MBXC312.europe.corp.microsoft.com> <125EACD0CAE4D24ABDB4D148C4593DA911026775@GBLONXMB02.corp.amvescap.net> <20100223161221.GA12250@soi.city.ac.uk> <4B8422A0.50506@dfki.de> <4B844D6A.7080309@gmail.com> <4B84FA5E.6030100@dfki.de> <4B850C01.8040800@gmail.com> <4B850EF2.7080405@dfki.de> <4B85181B.4020206@gmail.com> <4B851B55.7020604@dfki.de> <4B8527FF.6090907@gmail.com> Message-ID: <4B8532C8.8040909@dfki.de> Simon Marlow schrieb: > On 24/02/2010 12:28, Christian Maeder wrote: [...] >> It is not sufficient for me to reinstall this package with this utf8 >> setting. (I think ghc-pkg needs to be fixed or maybe recompiled under >> utf8.) > > There was a missing hSetEncoding, so that ghc-pkg is writing this file > using the current locale rather than UTF-8, but reading it back as > UTF-8. So I'm surprised that temporarily setting your locale to UTF-8 > doesn't work around it - what happens? No idea, the last step of installing is: Registering syb-0.1.0.3... /local/maeder/bin/ghc-pkg update - --global --no-user-package-conf -v2 The standard input passed to ghc-pkg is utf8 coded (independent of my LANG setting), but the output file written syb-0.1.0.3-2d8f18fd3343792a85816b191d973cea.conf is always ISO-8859. HTH Christian From marlowsd at gmail.com Wed Feb 24 10:05:08 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Feb 24 09:35:46 2010 Subject: Installing syb(-0.1.03) package in head version of Haskell In-Reply-To: <4B8532C8.8040909@dfki.de> References: <59543203684B2244980D7E4057D5FBC10B08D018@DB3EX14MBXC312.europe.corp.microsoft.com> <125EACD0CAE4D24ABDB4D148C4593DA911026775@GBLONXMB02.corp.amvescap.net> <20100223161221.GA12250@soi.city.ac.uk> <4B8422A0.50506@dfki.de> <4B844D6A.7080309@gmail.com> <4B84FA5E.6030100@dfki.de> <4B850C01.8040800@gmail.com> <4B850EF2.7080405@dfki.de> <4B85181B.4020206@gmail.com> <4B851B55.7020604@dfki.de> <4B8527FF.6090907@gmail.com> <4B8532C8.8040909@dfki.de> Message-ID: <4B854024.9050802@gmail.com> On 24/02/2010 14:08, Christian Maeder wrote: > Simon Marlow schrieb: >> On 24/02/2010 12:28, Christian Maeder wrote: > [...] >>> It is not sufficient for me to reinstall this package with this utf8 >>> setting. (I think ghc-pkg needs to be fixed or maybe recompiled under >>> utf8.) >> >> There was a missing hSetEncoding, so that ghc-pkg is writing this file >> using the current locale rather than UTF-8, but reading it back as >> UTF-8. So I'm surprised that temporarily setting your locale to UTF-8 >> doesn't work around it - what happens? > > No idea, the last step of installing is: > > Registering syb-0.1.0.3... > /local/maeder/bin/ghc-pkg update - --global --no-user-package-conf -v2 > > The standard input passed to ghc-pkg is utf8 coded (independent of my > LANG setting), but the output file written > syb-0.1.0.3-2d8f18fd3343792a85816b191d973cea.conf is always ISO-8859. > > HTH Christian It does, thanks. I now realise that the code is using binary mode accidentally, in fact it has an instance of this bug http://hackage.haskell.org/trac/ghc/ticket/3832 because ghc-pkg contains a copy of the code of openTempFile. I'll fix it to use openTempFileWithDefaultPermissions, which does the right thing. Cheers, Simon From choener at tbi.univie.ac.at Wed Feb 24 19:57:44 2010 From: choener at tbi.univie.ac.at (Christian =?iso-8859-1?Q?H=F6ner?= zu Siederdissen) Date: Wed Feb 24 19:28:10 2010 Subject: Easily generating efficient instances for classes Message-ID: <20100225005744.GA14966@workstation> Hi, I am thinking about how to easily generate instances for a class. Each instance is a tuple with 1 or more elements. In addition there is a second tuple with the same number of elements but different type. This means getting longer and longer chains of something like (...,x3*x2,x2,0). - template haskell? - CPP and macros? Consider arrays with fast access like Data.Vector, but with higher dimensionality. Basically, I want (!) to fuse when used in Data.Vector code. A code abstract follows -- I will put this on hackage if there is insterest. And please comment if you think of something how to improve here. Viele Gruesse, Christian -- | Primitive multidimensional tables without bounds-checking. Internally, we -- used unboxed vectors. Construction expects the highest possible index in -- each dimension, not the length (which is highest index +1). This choice -- allows for easier construction using bounded types. Consider: "fromList True -- False [] :: PrimTable Bool Bool" which creates a 2-element table. -- | Fast lookup table: `a` encodes the storage index type, while (!) only -- requires that the index value is (Enum). data PrimTable a b = PrimTable {-# UNPACK #-} !a -- ^ the highest indices (every index starts at 0 (or 0,0 ...)) {-# UNPACK #-} !a -- ^ precalculated multiplication values {-# UNPACK #-} !(V.Vector b) -- ^ storage space -- | mutable fast lookup table data MPrimTable s a b = MPrimTable {-# UNPACK #-} !a {-# UNPACK #-} !a {-# UNPACK #-} !(V.MVector s b) class (V.Unbox b) => PrimTableOperations a b e where -- | Fast index operation using precomputed multiplication data. Does -- bounds-checking only using assert. (!) :: PrimTable a b -> e -> b {-# INLINE (!) #-} new :: (PrimMonad s) => e -> s (MPrimTable (PrimState s) a b) {-# INLINE new #-} newWith :: (PrimMonad s) => e -> b -> s (MPrimTable (PrimState s) a b) {-# INLINE newWith #-} read :: (PrimMonad s) => MPrimTable (PrimState s) a b -> e -> s b {-# INLINE read #-} write :: (PrimMonad s) => MPrimTable (PrimState s) a b -> e -> b -> s () {-# INLINE write #-} fromList :: e -> b -> [(e,b)] -> PrimTable a b fromList dim init xs = runST $ do mpt <- newWith dim init mapM_ (\(k,v) -> write mpt k v) xs unsafeFreeze mpt {-# INLINE fromList #-} -- | Two-dimensional tables. instance (Enum e, V.Unbox b) => PrimTableOperations (Int,Int) b (e,e) where (PrimTable (z2,z1) (n2,n1) arr) ! (k2,k1) = arr `V.unsafeIndex` (fromEnum k2 * n2 + fromEnum k1) {-# INLINE (!) #-} new (z2',z1') = do let z2 = fromEnum z2' +1 let z1 = fromEnum z1' +1 marr <- M.new $ z2 * z1 return $ MPrimTable (z2,z1) (z1,0) marr newWith (z2,z1) v = do mpt <- new (z2,z1) mapM_ (\k -> write mpt k v) [(k2,k1) | k2 <- [toEnum 0..z2], k1 <- [toEnum 0..z1]] return mpt read (MPrimTable (z2,z1) (n2,_) marr) (k2,k1) = M.read marr (fromEnum k2 * n2 + fromEnum k1) write (MPrimTable (z2,z1) (n2,_) marr) (k2,k1) v = M.write marr (fromEnum k2 * n2 + fromEnum k1) v -- example jarr :: PrimTable (Int,Int) Double jarr = fromList (2 :: Int,2 :: Int) 0.0 [((0,0),1.0),((0,1),2.0),((1,0),3.0),((1,1),4.0)] runj = [jarr ! (k :: (Int,Int)) | k <- [(0,0),(0,1),(1,0),(1,1)]] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100224/e2d13756/attachment.bin From bulat.ziganshin at gmail.com Thu Feb 25 03:57:56 2010 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Feb 25 03:29:26 2010 Subject: Easily generating efficient instances for classes In-Reply-To: <20100225005744.GA14966@workstation> References: <20100225005744.GA14966@workstation> Message-ID: <355370815.20100225115756@gmail.com> Hello Christian, Thursday, February 25, 2010, 3:57:44 AM, you wrote: > I am thinking about how to easily generate instances for a class. Each it's called generic programing. just a few overviews on this topic: Libraries for Generic Programming in Haskell http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-025.pdf Comparing Approaches to Generic Programming in Haskell http://www.cs.uu.nl/~johanj/publications/ComparingGP.pdf Derive package is probably the easiest way Template Haskell is also good although a bit too complex. my own pets: http://www.haskell.org/bz/th3.htm http://www.haskell.org/bz/thdoc.htm -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From midfield at gmail.com Thu Feb 25 14:04:26 2010 From: midfield at gmail.com (Ben) Date: Thu Feb 25 13:34:53 2010 Subject: save-the-world or serializable continuations Message-ID: <9157df231002251104h2fba77edk2a404c9c9324e34@mail.gmail.com> hello -- i'm wondering if there is any support for a common-lisp style "save-the-world" function in GHC, or more generally serializable continuations (in the Continuation monad?) And if not, what would it take to have it? It would be very useful for long-running restartable computations, amongst other things. I realize it is a very tricky thing to do right, but even simplified approximations would be great. best, ben From twhitehead at gmail.com Thu Feb 25 15:00:11 2010 From: twhitehead at gmail.com (Tyson Whitehead) Date: Thu Feb 25 14:30:50 2010 Subject: Some great results on fused code with the LLVM backend In-Reply-To: <20100222015725.GA1870@whirlpool.galois.com> References: <20100222015725.GA1870@whirlpool.galois.com> Message-ID: <201002251500.17282.twhitehead@gmail.com> On February 21, 2010 20:57:25 Don Stewart wrote: > I tried out some of the vector and uvector fusion benchmarks with the > new LLVM backend > > http://donsbot.wordpress.com/2010/02/21/smoking-fast-haskell-code-using-ghc >s-new-llvm-codegen/ > > and got some great results for the tight loops generated through fusion. > Up to 2x faster than gcc -O3 in some cases. I had a quick scan through Davids thesis the other day and noted that he attributes a lot/at least some of the tight loops performance advantage to not having pinned the STG registers except at function entrance and exit. http://www.cse.unsw.edu.au/~pls/thesis/davidt-thesis.pdf According to what I understand from the bottom of page 42 and top of page 43, this was done through a custom calling convention whereby the first N arguments get passed in the N registers assigned to the STG virtual registers, and every function is extended to take the STG registers as their first N parameters. The net result is that, on entry to any function (there are only entries to worry about as everything is a tail call), the STG virtual registers are in the correct hardware registers, so the RTS is happy. What is interesting though, is LLVM is free to spill them between function calls. This can free up more registers for right loops, and from my understanding of the bottom of page 53 and top of page 54, this was likely crucial to getting the great tight-loop performance in some cases. I don't know if this even makes sense to ask, but could the same thing be done for the native code generator (i.e., implement global RTS registers as a calling convention instead what I presume is a don't touch approach)? Cheers! -Tyson PS: If you happen to read this list, that was a nice body of work David. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100225/2dd159a8/attachment.bin From cheecheeo at gmail.com Thu Feb 25 20:19:05 2010 From: cheecheeo at gmail.com (John Alfred Nathanael Chee) Date: Thu Feb 25 19:49:47 2010 Subject: save-the-world or serializable continuations In-Reply-To: <9157df231002251104h2fba77edk2a404c9c9324e34@mail.gmail.com> References: <9157df231002251104h2fba77edk2a404c9c9324e34@mail.gmail.com> Message-ID: <22d4c8561002251719p6f47066ak1b204ad811969acc@mail.gmail.com> On Thu, Feb 25, 2010 at 11:04, Ben wrote: > hello -- > > i'm wondering if there is any support for a common-lisp style > "save-the-world" function in GHC, or more generally serializable > continuations (in the Continuation monad?) ?And if not, what would it > take to have it? ?It would be very useful for long-running restartable > computations, amongst other things. ?I realize it is a very tricky > thing to do right, but even simplified approximations would be great. This might not be what you're looking for, but it sounds similar and might be a place to start: http://hackage.haskell.org/package/Workflow -- Love in Jesus Christ, John Alfred Nathanael Chee http://www.biblegateway.com/ http://www.sunsetpres.org/ http://web.cecs.pdx.edu/~chee/ From simonpj at microsoft.com Fri Feb 26 03:46:35 2010 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Feb 26 03:18:55 2010 Subject: Some great results on fused code with the LLVM backend In-Reply-To: <201002251500.17282.twhitehead@gmail.com> References: <20100222015725.GA1870@whirlpool.galois.com> <201002251500.17282.twhitehead@gmail.com> Message-ID: <59543203684B2244980D7E4057D5FBC10B09486F@DB3EX14MBXC312.europe.corp.microsoft.com> | What is interesting though, is LLVM is free to spill them between function | calls. This can free up more registers for right loops, and from my | understanding of the bottom of page 53 and top of page 54, this was likely | crucial to getting the great tight-loop performance in some cases. | | I don't know if this even makes sense to ask, but could the same thing be done | for the native code generator (i.e., implement global RTS registers as a | calling convention instead what I presume is a don't touch approach)? Yes, that's certainly the plan! Simon From ndmitchell at gmail.com Sun Feb 28 06:58:26 2010 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun Feb 28 06:28:42 2010 Subject: Easily generating efficient instances for classes In-Reply-To: <355370815.20100225115756@gmail.com> References: <20100225005744.GA14966@workstation> <355370815.20100225115756@gmail.com> Message-ID: <404396ef1002280358j64da77c7wf49cf8d5eba73603@mail.gmail.com> As Bulat says, the Derive package might be a good way to go. I am happy to accept any new derivations, and you get lots of things for free - including writing your code using the nice haskell-src-exts library, preprocessor support, TH support etc. Thanks, Neil On Thu, Feb 25, 2010 at 8:57 AM, Bulat Ziganshin wrote: > Hello Christian, > > Thursday, February 25, 2010, 3:57:44 AM, you wrote: > >> I am thinking about how to easily generate instances for a class. Each > > it's called generic programing. just a few overviews on this topic: > > Libraries for Generic Programming in Haskell > http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-025.pdf > > Comparing Approaches to Generic Programming in Haskell > http://www.cs.uu.nl/~johanj/publications/ComparingGP.pdf > > Derive package is probably the easiest way > > Template Haskell is also good although a bit too complex. my own pets: > http://www.haskell.org/bz/th3.htm > http://www.haskell.org/bz/thdoc.htm > > -- > Best regards, > ?Bulat ? ? ? ? ? ? ? ? ? ? ? ? ? ?mailto:Bulat.Ziganshin@gmail.com > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >