Re: type error formatting
On 24 Oct 2015, at 09:17, Joachim Breitner wrote: > For example in > >>Relevant bindings include >> syllables :: [(a1, Syllable)] >> (bound at Derive/Call/India/Pakhawaj.hs:141:16) >> best_match :: [(a1, Syllable)] >> -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) >> (bound at Derive/Call/India/Pakhawaj.hs:141:5) > > Also, unless the programmer is doing weird things with shadowing, is > the "bound at" information really valuable? I’d say no: Usually, the > programmer knows his bindings, and even if not, she will not have any > problems finding the right binding. As someone who spends a lot of time maintaining code that I did not write, I have to say that it is not enough that the "programmer knows his bindings". She might, but I do not. This kind of helpful signposting of exactly what file + linenumber + character position to look at, is really useful for someone who is not familiar with the code. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] RFC: Native -XCPP Proposal
Exactly. My post was an attempt to elicit response from anyone to whom it matters. There is no point in worrying about hypothetical licensing problems - let's hear about the real ones. Regards, Malcolm On 7 May 2015, at 22:15, Tomas Carnecky wrote: That doesn't mean those people don't exist. Maybe they do but are too afraid to speak up (due to corporate policy or whatever). On Thu, May 7, 2015 at 10:41 PM, Malcolm Wallace malcolm.wall...@me.com wrote: I also note that in this discussion, so far not a single person has said that the cpphs licence would actually be a problem for them. Regards, Malcolm On 7 May 2015, at 20:54, Herbert Valerio Riedel wrote: On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote: [...] Regarding licensing issues: perhaps we should simply ask Malcolm Wallace if he would consider changing the license for the sake of GHC? Or perhaps he could grant a custom-tailored license to the GHC project? After all, the project page [1] says: If that's a problem for you, contact me to make other arrangements. Fyi, Neil talked to him[1]: | I talked to Malcolm. His contention is that it doesn't actually change | the license of the ghc package. As such, it's just a single extra | license to add to a directory full of licenses, which is no big deal. [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1e5n3 ___ Haskell-Cafe mailing list haskell-c...@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] RFC: Native -XCPP Proposal
On 8 May 2015, at 00:06, Richard A. O'Keefe wrote: I think it's important that there be *one* cpp used by Haskell. fpp is under 4 kSLOC of C, and surely Haskell can do a lot better. FWIW, cpphs is about 1600 LoC today. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: RFC: Native -XCPP Proposal
I also note that in this discussion, so far not a single person has said that the cpphs licence would actually be a problem for them. Regards, Malcolm On 7 May 2015, at 20:54, Herbert Valerio Riedel wrote: On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote: [...] Regarding licensing issues: perhaps we should simply ask Malcolm Wallace if he would consider changing the license for the sake of GHC? Or perhaps he could grant a custom-tailored license to the GHC project? After all, the project page [1] says: If that's a problem for you, contact me to make other arrangements. Fyi, Neil talked to him[1]: | I talked to Malcolm. His contention is that it doesn't actually change | the license of the ghc package. As such, it's just a single extra | license to add to a directory full of licenses, which is no big deal. [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1e5n3 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.10 regression when using foldr
On 20 Jan 2015, at 11:20, Björn Peemöller wrote: The reason is the usage of foldr, which changed its type from foldr :: (a - b - b) - b - [a] - b -- GHC 7.8.4 to foldr :: Foldable t = (a - b - b) - b - t a - b -- GHC 7.10.1 Thus, the use of foldr is now ambiguous. I can fix this by providing a type signature convert :: ([a], String) - (List a, String) However, is this breaking change intended? I believe this kind of breakage was predicted by those opposed to the change of signature. That is not quite the same thing as being intended or desired. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - feedback on Mac OS
On 1 Jan 2015, at 13:58, George Colpitts wrote: Configuring cpphs-1.13... Building cpphs-1.13... Warning: cpphs.cabal: Unknown fields: build-depends (line 5) Could not find module ‘Prelude’ It is a member of the hidden package ‘base-4.8.0.0’. Perhaps you need to add ‘base’ to the build-depends in your .cabal file. The two statements unknown field build-depends and add package to build-depends seem rather contradictory. How can this be fixed? Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: The future of the haskell2010/haskell98 packages - AKA Trac #9590
How about doing the honest thing, and withdrawing both packages in ghc-7.10? Haskell'98 is now 15 years old, and the 2010 standard was never really popular anyway. Regards, Malcolm On 30 Sep 2014, at 21:21, Austin Seipp aus...@well-typed.com wrote: Hello developers, users, friends, I'd like you all to weigh in on something - a GHC bug report, that has happened as a result of making Applicative a superclass of Monad: https://ghc.haskell.org/trac/ghc/ticket/9590 The very condensed version is this: because haskell2010/haskell98 packages try to be fairly strictly conforming, they do not have modules like Control.Applicative. Unfortunately, due to the way these packages are structured, many things are simply re-exported from base, like `Monad`. But `Applicative` is not, and cannot be imported if you use -XHaskell2010 and the haskell2010 package. The net result here is that haskell98/haskell2010 are hopelessly broken in the current state: it's impossible to define an instance of `Monad`, because you cannot define an instance of `Applicative`, because you can't import it in the first place! This leaves us in quite a pickle. So I ask: Friends, what do you think we should do? I am particularly interested in users/developers of current Haskell2010 packages - not just code that may *be* standard Haskell - code that implies a dependency on it. There was a short discussion between me and Simon Marlow about this in the morning, and again on IRC this morning between me, Duncan, Edward K, and Herbert. Basically, I only see one of two options: - We could make GHC support both: a version of `Monad` without `Applicative`, and one with it. This creates some complication in the desugarer, where GHC takes care of `do` syntax (and thus needs to be aware of `Monad`'s definition and location). But it is, perhaps, quite doable. - We change both packages to export `Applicative` and follow the API changes in `base` accordingly. Note that #1 above is contingent on three things: 1) There is interest in this actually happening, and these separate APIs being supported. If there is not significant interest in maintaining this, it's unclear if we should go for it. 2) It's not overly monstrously complex (I don't think it necessarily will be, but it might be.) 3) You can't like `haskell2010` packages and `base` packages together in the general case, but, AFAIK, this wasn't the case before either. I'd really appreciate your thoughts. This must be sorted out for 7.10 somehow; the current situation is hopelessly busted. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ 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
Re: RFC: changes to -i flag for finding source files
On 25 Apr 2014, at 14:17, Simon Marlow wrote: The problem we often have is that when you're writing code for a library that lives deep in the module hierarchy, you end up needing a deep directory structure, where the top few layers are all empty. I don't see how this is a problem at all. Navigating the vacuous structure is as simple as pressing the tab key a few times. But if you change the mapping convention between files and module names, you need to do it for all tools, not just the compiler. I imagine all of the following tools would need to know about it: cabal, hoogle, haddock, happy, alex, hat, hsc2hs and probably a few more. The feature seems like a very low power-to-weight ratio, so -1 from me. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Mac CPP problem with ghc-clang-wrapper
Yes, this is a known problem. I intend to put out a fresh version of HaXml soon to fix it. Regards, Malcolm On 18 Mar 2014, at 15:17, Christian Maeder wrote: Hi, under mavericks using the ghc-clang-wrapper (ghc-7.6) or using ghc-7.8.20140130 I can no longer install the HaXml package. The source line: putStrLn $ part of HaXml-++show MAJOR.MINOR seems to put spaces around the decimal point between MAJOR and MINOR and fails as shown below. Is this already a known problem? Cheers Christian [14 of 42] Compiling Text.XML.HaXml.Wrappers ( src/Text/XML/HaXml/Wrappers.hs, dist/build/Text/XML/HaXml/Wrappers.o ) src/Text/XML/HaXml/Wrappers.hs:34:36: Couldn't match type ‛[Char]’ with ‛b0 - c0’ Expected type: b0 - c0 Actual type: String Possible cause: ‛show’ is applied to too many arguments In the first argument of ‛(.)’, namely ‛show 1’ In the second argument of ‛(++)’, namely ‛show 1 . 24’ src/Text/XML/HaXml/Wrappers.hs:34:36: Couldn't match expected type ‛[Char]’ with actual type ‛a0 - c0’ In the second argument of ‛(++)’, namely ‛show 1 . 24’ In the second argument of ‛($)’, namely ‛part of HaXml- ++ show 1 . 24’ In a stmt of a 'do' block: putStrLn $ part of HaXml- ++ show 1 . 24 Failed to install HaXml-1.24 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cascading type errors in ghc
On 6 Aug 2013, at 20:03, Evan Laforge wrote: I don't know how others like to work, but I like when a compiler bails early, because I fix errors one at a time, and I search for the easiest looking ones before worrying about the complicated looking ones. With C compilers, it is often the case that only the first error is real, and the subsequent errors are consequences of not being able to recover from the first one. However, one of the really nice things about GHC is that the list of type errors is complete and coherent. I often start at the bottom of the list and work my way up fixing them in a single pass (upwards, in order to give myself the best chance that the line numbers are still correct after I have fixed the later errors). There are not many compilers you can do that with, and I like it when I can. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overloaded record fields
On 28 Jun 2013, at 12:16, AntC wrote:
Thanks Simon, I'm a little puzzled what your worry is.
f r b = r.foo b
With dot-notation baked in (non-orthogonally), f would get the type
f :: (r { foo::Bool }) = r - Bool - Bool
With the orthogonal proposal, f is equivalent to
f r b = foo r b
I believe Simon's point is that, if dot is special, we can infer the Has type
above, even if the compiler is not currently aware of any actual record types
that contain a foo field. If dot is not special, then there *must* be some
record containing foo already in scope, otherwise you cannot infer that type
- you would get a name not in scope error instead.
The former case, where you can use a selector for a record that is not even
defined yet, leads to good library separation. The latter case couples
somewhat-polymorphic record selectors to actual definitions.
Unless you require the type signature to be explicit, instead of inferred.
(For the record, I deeply dislike making dot special, so I would personally go
for requiring the explicit type signature in this situation.)
Regards,
Malcolm
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Strange behavior in GHC-compiled code
Unless you show us the code, any answers will be guesses in the dark. Does your program use unsafePerformIO unsafely perhaps? Or a version of a library that happens to have a known bug? On 25/05/2012, at 14:33, Mark Conway Wirt markcw...@gmail.com wrote: I have a piece of Haskell code that's been laying around on my computer for about a year, and I recently decided to dust it off. The problem is that it used to work fine, but in the interim (in which I both upgraded OS versions/GHC versions and went from 32 bit to 64 bit) the code stopped working reliably. [...] Any guidance/pointers would be very much appreciated. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Error while installing new packages with GHC 7.4.1
On 29 Feb 2012, at 09:53, Antoras wrote: I updated my GHC version from 7.0.3 to 7.4.1. But after that GHC is unable to install some required packages. containers-0.4.2.1 (reinstall) changes: array-0.4.0.0 - 0.3.0.3 binary-0.5.1.0 (reinstall) changes: array-0.4.0.0 - 0.3.0.3 I believe you can't rebuild packages that shipped as part of your install of ghc, including containers and binary. The downgrade of the array package looks worrying too. I think array-0.4.0.0 is shipped with ghc-7.4.1, so where did the dependency on array-0.3.0.3 come from? Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Posting etiquette, was Re: Records in Haskell
Sorry to pick on your post in particular Matthew, but I have been seeing a lot
of this on the Haskell lists lately.
I find it completely unreasonable for a reply to a very long post to quote the
entire text, only to add a single line at the bottom (or worse, embedded in the
middle somewhere). In this case, there are 7 pages of quotation before your
one-sentence contribution. (That is on my laptop. I dread to think how many
pages it represents on a smartphone screen...) Usually, if I need to scroll
even to the second page-worth of quotation and have still not found any new
text, I now just delete the post without reading it.
It is a failure to communicate well, on the part of the writer who values their
own time more highly than that of their intended readers. Even the
much-maligned top-posting style, as forced upon Outlook users (and as I am
doing right here), is preferable to the failure to trim, or to get to the point
quickly. My inbox has 1600 unread messages in it, and life is just too short.
So I offer this plea as a constructive social suggestion - if you want your
ideas to reach their intended audience, don't annoy them before they have even
seen what you want to say.
Regards,
Malcolm
On 15 Jan 2012, at 20:33, Matthew Farkas-Dyck wrote:
On 13/01/2012, Simon Peyton-Jones simo...@microsoft.com wrote:
Thanks to Greg for leading the records debate. I apologise that I
don't have enough bandwidth to make more than an occasional
contribution. Greg's new wiki page, and the discussion so far has
clarified my thinking, and this message tries to express that new
clarity. I put a conclusion at the end.
Simon
Overview
It has become clear that there are two elements to pretty much all the
proposals we have on the table. Suppose we have two types, 'S' and 'T',
both with a field 'f', and you want to select field 'f' from a record 'r'.
Somehow you have to disambiguate which 'f' you mean.
(Plan A) Disambiguate using qualified names. To select field f, say
(S.f r) or (T.f r) respectively.
(Plan B) Disambiguate using types. This approach usually implies
dot-notation.
If (r::S), then (r.f) uses the 'f' from 'S', and similarly if
(r::T).
Note that
* The Frege-derived records proposal (FDR), uses both (A) and (B)
http://hackage.haskell.org/trac/ghc/wiki/Records/NameSpacing
* The Simple Overloaded Record Fields (SORF) proposal uses only (B)
http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields
* The Type Directed Name Resolution proposal (TDNR) uses only (B)
http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution
I know of no proposal that advocates only (A). It seems that we are agreed
that we must make use of types to disambigute common cases.
Complexities of (Plan B)
Proposal (Plan B) sounds innocent enough. But I promise you, it isn't.
There has ben some mention of the left-to-right bias of Frege type
inference engine; indeed the wohle explanation of which programs are
accepted and which are rejected, inherently involves an understanding
of the type inference algorithm. This is a Very Bad Thing when the
type inference algorithm gets complicated, and GHC's is certainly
complicated.
Here's an example:
type family F a b
data instance F Int [a] = Mk { f :: Int }
g :: F Int b - ()
h :: F a [Bool] - ()
k x = (g x, x.f, h x)
Consider type inference on k. Initially we know nothing about the
type of x.
* From the application (g x) we learn that x's type has
shape (F Int something).
* From the application (h x) we learn that x's type has
shape (F something else [Bool])
* Hence x's type must be (F Int [Bool])
* And hence, using the data family we can see which field
f is intended.
Notice that
a) Neither left to right nor right to left would suffice
b) There is significant interaction with type/data families
(and I can give you more examples with classes and GADTs)
c) In passing we note that it is totally unclear how (Plan A)
would deal with data families
This looks like a swamp. In a simple Hindley-Milner typed language
you might get away with some informal heuristics, but Haskell is far
too complicated.
Fortunately we know exactly what to do; it is described in some detail
in our paper Modular type inference with local assumptions
http://www.haskell.org/haskellwiki/Simonpj/Talk:OutsideIn
The trick is to *defer* all these decisions by generating *type constraints*
and solving them later. We express it like this:
G, r:t1 |- r.f : t2, (Has t1 f t2)
This says that if r is in scope with type t1, then (r.f) has type t2,
plus the constraint (Has t1 f t2), which we read as saying
Type t1 must have a field f of type t2
We gather up all the constraints and solve them. In solving them
we may figure out t1 from some *other* constraint (to the left or
right,
Re: Composition operator [was: Re: Records in Haskell]
On 12 Jan 2012, at 18:41, Evan Laforge wrote: Unicode dot (∘) would be optimal, since that's what it's for. Is ∘ (U+2218 RING OPERATOR)* in Prelude yet? We should propose that.** However, changing the composition operator from (.) will involve huge amounts of changes to source code. Indeed. It strikes me that it should be the _new_ feature that takes the new syntax, rather than stealing the old syntax and disrupting all the existing code that happily uses . for function composition. So, who is up for proposing centred dot as the new record-field syntax? Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: integer-simple
I notice that ghci is loading integer-simple before loading base. This at least explains why it cannot find a symbol from the base package - it hasn't been loaded yet. So the question is why does integer-simple use any function from the base package at all? I'm fairly sure that the dependency graph is such that it should not. On 30/07/2011, at 22:37, Chris Dornan ch...@chrisdornan.com wrote: Hi All, I thought I may as well try the same experiment 7.2.1-RC1 on completely different hardware (a network v-server running CentOS 5 with ghc-6.12.3 installed) and indeed: ghci GHCi, version 7.2.0.20110728: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-simple ... linking ... ghc: /usr/local/ghc/7.2.0.20110728/lib/ghc-7.2.0.20110728/integer-simple-0.1.0.0/HSinteger-simple-0.1.0.0.o: unknown symbol `base_ControlziExceptionziBase_patError_info' ghc: unable to load package `integer-simple' This has to be the way I am configuring the build – as y’all can see I am configuring with a non-standard prefix, but otherwise it is a case of a clean build from virginal sources with the appended build.mk. I think I am going to have to start looking at the failure mechanism… Chris snipety-snip # - # A Sample build.mk # # Uncomment one of the following BuildFlavour settings to get the desired # overall build type, and then tweak the options in the relevant section # below. # Uncomment one of these to select a build profile below: # Full build with max optimisation (slow build) #BuildFlavour = perf # Fastest build (libs unoptimised): BuildFlavour = quickest # Fast build with optimised libraries: #BuildFlavour = quick # Profile the stage2 compiler: #BuildFlavour = prof # A development build, working on the stage 1 compiler: #BuildFlavour = devel1 # A development build, working on the stage 2 compiler: #BuildFlavour = devel2 GhcLibWays = v # 1. A Performance/Distribution build ifeq $(BuildFlavour) perf # perf matches the default settings, repeated here for comparison: SRC_HC_OPTS = -O -H64m GhcStage1HcOpts = -O -fasm GhcStage2HcOpts = -O2 -fasm GhcHcOpts = -Rghc-timing GhcLibHcOpts= -O2 -XGenerics GhcLibWays += p ifeq $(PlatformSupportsSharedLibs) YES GhcLibWays += dyn endif endif # A Fast build -- ifeq $(BuildFlavour) quickest SRC_HC_OPTS= -H64m -O0 -fasm GhcStage1HcOpts= -O -fasm GhcStage2HcOpts= -O0 -fasm GhcLibHcOpts = -O0 -fasm SplitObjs = NO HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO endif # A Fast build with optimised libs -- ifeq $(BuildFlavour) quick SRC_HC_OPTS= -H64m -O0 -fasm GhcStage1HcOpts= -O -fasm GhcStage2HcOpts= -O0 -fasm GhcLibHcOpts = -O -fasm SplitObjs = NO HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO endif # Profile the stage2 compiler --- ifeq $(BuildFlavour) prof SRC_HC_OPTS= -H64m -O0 -fasm GhcStage1HcOpts= -O -fasm GhcStage2HcOpts= -O -fasm GhcLibHcOpts = -O -fasm GhcLibWays += p GhcProfiled= YES SplitObjs = NO HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO endif # A Development build (stage 1) - ifeq $(BuildFlavour) devel1 SRC_HC_OPTS= -H64m -O -fasm GhcLibHcOpts = -O -dcore-lint GhcStage1HcOpts= -Rghc-timing -O0 -DDEBUG GhcStage2HcOpts= -Rghc-timing -O -fasm SplitObjs = NO HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO endif # A Development build (stage 2) - ifeq $(BuildFlavour) devel2 SRC_HC_OPTS= -H64m -O -fasm GhcLibHcOpts = -O -dcore-lint GhcStage1HcOpts= -Rghc-timing -O -fasm GhcStage2HcOpts= -Rghc-timing -O0 -DDEBUG SplitObjs = NO HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO endif #
Re: GHC and Haskell 98
As one of the few people who has habitually used Haskell'98 wherever possible, I favour plan A. As I recently discovered, in ghc 7 it is already very fragile to attempt to depend on both the base and haskell98 packages simultaneously. In most cases it simply doesn't work. Removing those few remaining cases where it happens to work by accident would be a good move. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to install GhC on a Mac without registering?
On 10 Jun 2011, at 02:15, Manuel M T Chakravarty wrote: Anybody who is halfway serious about developing software on a Mac will have Xcode installed anyway. As the original poster clarified, the motivating use-case is education (specifically a class of 12-13 year olds.) These are not serious developers, but they have the potential to become serious. Placing unnecessary hurdles in their way will diminish the chances of their discovering Haskell to be a beautiful language. Having said that, I do think that Hugs (or maybe Helium) would be a more appropriate environment for teaching the basics to young students. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to install GhC on a Mac without registering?
On 6 Jun 2011, at 13:49, Lyndon Maydwell wrote: I would be fantastic if XCode wasn't a dependency. ... Not to detract at all from the work of the wonderful GHC and Haskell Platform contributors in any way. For me it would just make it that much easier to convince mac-using friends to give Haskell a try. The ghc team already bundle a copy of gcc in their Windows distribution, precisely because it can be fiddly to get a working copy of gcc for that platform otherwise. I wonder if they would consider the possibility of shipping gcc on Mac too? (There may be good reasons not to do that, but let's have the discussion.) Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hsc2hs on Mac
hsc2hs converts (#const sizeof(struct stat)) (#peek struct stat, st_mtimespec) to 108 36 but the correct values are 144 32. Is this a bug of hsc2hs? Not directly. hsc2hs calls the C compiler to determine these numbers. It seems it is calling gcc-4.0 rather than gcc-4.2. It might be a bug that it is calling the wrong compiler, but that might just be misconfiguration in your environment, or in the Haskell Platform. gcc-4.0 says sizeof (struct stat) is 108 while gcc-4.2 (default) says that is 144. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hoogling GHC
Ranjit, I'd like to build a hoogle database that indexes the GHC source. Can anyone point me to how I might do that? (Or better, to a preexisting database?) The author of Hoogle, Neil Mitchell, is currently on holiday, but I'm sure he will have some good advice for you when he returns. In the meantime, the relevant portion of the Hoogle manual is here: http://www.haskell.org/haskellwiki/Hoogle#Database_Creation and a blog post with instructions is here: http://neilmitchell.blogspot.com/2008/08/hoogle-database-generation.html (I've noticed that make haddock generates a bunch of .txt files. Is there some easy way to scour the directories and build a single Hoogle database from them?) I imagine some simple shell scripting would achieve that, starting with find haddockBaseDir -name *.txt -print | ... Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hoogling GHC
The final stumbling block is getting the local webserver (hoogle server) to also search the above database. I'm sure there must be some simple way I can pass the name of the database as an argument when I boot up the server, but I can't seem to find it... Have you found the various versions of the web deployment procedure yet? deploy.txt: instructions to follow manually (seems to be up-to-date) deploy.sh: a shell script version to run locally (may be old) Deploy.hs: a haskell version to run remotely (may also be old) Obviously those scripts are tailored to the official installation, but there are some clues in there, for instance the steps cabal configure --datadir=/srv/web/haskell.org/hoogle/ -- datasubdir=datadir -O2 and Upload datadir/resources to /srv/web/haskell.org/hoogle/datadir/ resources Upload datadir/databases/* to /srv/web/haskell.org/hoogle/datadir/ databases Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
On 10 Jan 2011, at 22:37, Daniel Peebles wrote: So the basic point seems to be: if you know how to use a tool, you don't usually curse and swear when you use it. If you don't, you tend to swear a lot! There is a meta-point though - how easy is it to learn the tool? Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
On 10 Jan 2011, at 14:02, Gregory Collins wrote: +1. I don't have a lot of skin in this particular game (I'm not currently a GHC contributor and am unlikely to become one in the near future), but I can offer some anecdotal evidence: As another non-GHC contributor, my opinion should probably also count for little, but my experience with git has been poor. I have used git daily in my job for the last year. Like Simon PJ, I struggle to understand the underlying model of git, despite reading quite a few tutorials. I have a high failure rate with attempting anything beyond the equivalents of darcs record, push, and pull. When I use darcs, my local workflow typically involves lots of amend- record, cherry-picking, and multiple repos/branches. I have tried to do these things in git a few times and failed miserably. I am an old- fashioned unix command-line lover, but I find using the git command- line is next to impossible, and as a consequence do almost everything in git gui. If the gui interface does not let me do an action, then I often can't work out how to do it at all, even after googling. Mind you, some other people at work somehow manage to use git's support for branching reasonably successfully. But we have occasional mishaps where a repo is made totally unusable by somebody making a tiny mistake with their branching commands. Our standard advice at work for people who get their repo muddled is to throw it away, re- clone the master, and manually re-code their local changes from scratch (with the help of diff). If I were considering contributing minor patches to a project, the use of git would probably not deter me too much - I can cope with the simple stuff. But if I wanted more major involvement, git would definitely cause me to think twice about whether to bother. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC ParseTree Module
You will be more likely to get an answer on the ghc-users mailing list (cc'ed). The ghc developers rarely follow -cafe. On 1 Jan 2011, at 20:36, Jane Ren wrote: Hi, Does anyone know what GHC module gets the AST and type info of some source code? This is the GHC module that converts all of Haskell into an AST with a small number of pattern cases, where each AST node is annotated with the Haskell type. Thanks ___ Haskell-Cafe mailing list haskell-c...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Quasi quoting
(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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Language extensions - backwards compatibility
The flag -P for traditional gnu cpp (or --noline for stand-alone
cpphs) should suppress the initial #line noise.
Does ghc still fail to recognise a module-start pragma, even if the
only characters preceding it are whitespace?
I intended to give an example.
file foo.h
#if __GLASGOW_HASKELL__ == 604
#define PRAGMA(foo) {-# OPTIONS_GHC -X foo #-}
#else
#define PRAGMA(foo) {-# LANGUAGE foo #-}
file Bar.hs
#include foo.h
PRAGMA(MyLanguageOption)
module Bar where
result
$ ghc-6.8.2 -E -cpp -optP-P Bar.hs
$ cat Bar.hspp
{-# LINE 1 Bar.hs #-}
{-# LANGUAGE MyLanguageOption #-}
module Bar where
$ ghc-6.4.1 -E -cpp -optP-P Bar.hs
$ cat Bar.hspp
{-# OPTIONS_GHC -X MyLanguageOption #-}
module Bar where
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Poll: Error message spans
Would you find the extra information useful, or just noise? i.e. should we show error spans by default? I certainly wouldn't find it distracting, and I think it could be quite useful in many cases. I vote for turning it on by default. I agree. +1. It is a feature I have always found useful in other tools. (Although ghc does usually quote the entire literal source expression denoted by the span, so perhaps the info is slightly redundant.) Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Where did the GHC API go?
Too late. We had a stable link, I used it, Google used it, blog posts were written that linked to it, I've emailed my wife links to it, I've put them in Word documents, I've posted them on internal intranets. You can't create a link, put content behind it, then move the content - it just breaks the whole web. And incidentally, the _ghc_docs_ themselves continue to use these stable links to library docs, most of which are currently broken. All of the following links from documentation for ghc-6.12.1 give a 404 Not Found. (I do not claim the list is exhaustive.) from http://www.haskell.org/ghc/docs/latest/html/users_guide/packages.html section 4.8 links to http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal/Distribution-Simple.html section 4.8.8 links to http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal/Distribution-InstalledPackageInfo.html# %tInstalledPackageInfo http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal/Distribution-License.html#t :License from http://www.haskell.org/ghc/docs/latest/html/users_guide/using-concurrent.html section 4.12 links to http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html from http://www.haskell.org/ghc/docs/latest/html/users_guide/primitives.html section 7.2 links to http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-prim/GHC-Prim.html from http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html section 7.3.10 links to http://www.haskell.org/ghc/docs/latest/html/libraries/base/GHC-Exts.html from http://www.haskell.org/ghc/docs/latest/html/users_guide/arrow-notation.html section 7.10 links twice to http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Arrow.html from http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html section 7.13.1 links to http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal/Language-Haskell-Extension.html from http://www.haskell.org/ghc/docs/latest/html/users_guide/special-ids.html section 7.15 links to http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-prim/GHC-Prim.html from http://www.haskell.org/ghc/docs/latest/html/users_guide/lang-parallel.html section 7.18.1 links to http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html section 7.18.2 links to http://www.haskell.org/ghc/docs/latest/html/libraries/stm/Control-Concurrent-STM.html section 7.18.4 links to http://www.haskell.org/ghc/docs/latest/html/libraries/parallel/Control-Parallel.html http://www.haskell.org/ghc/docs/latest/html/libraries/parallel/Control-Parallel-Strategies.html from http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi.html section 8 incorrectly links to http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html where the real link ought to be http://www.haskell.org/ghc/docs/latest/html/libraries/base/Foreign.html from http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html section 8.2.4.2 links to http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html from http://www.haskell.org/ghc/docs/latest/html/users_guide/ghci-windows.html section 11.2 links to http://www.haskell.org/ghc/docs/latest/html/libraries/base/GHC-ConsoleHandler.html Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Qualified names in import lists
module Main where import Foo (Bar.bar) GHC apparently accepts this code, but I can find no mention of such a feature in the GHC docs. It certainly is an extension beyond Haskell'98 and Haskell 2010, which do not permit qualified names in import lists. I cannot think for any use for such a feature, never mind a good one. If ghc really does accept the example given, I would like to know what entity Bar.bar refers to, since it cannot possibly be exported by Foo. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.12.1
I've the 6.10.4 version installed on my MacOS X 10.6 OS. Have I to uninstall this version of GHC before installing the Mac .pkg for the 6.12.1? Most installer packages (_except_ for MacOS) allow you to have multiple previous versions of ghc - they are simply left in place (but must now be accessed as e.g. ghc-6.10.4 rather than plan ghc, which now points to the new version). However, there is an unfortunate feature/bug of the MacOS installer packages that they forceably delete any previous versions of ghc that you had on your machine. This is undesirable for many reasons, but as far as I know, it has not yet been fixed. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
-package-name flag in 6.10.x
The ghc documentation at http://www.haskell.org/ghc/docs/latest/html/users_guide/packages.html says the following: -package-name foo Tells GHC the the module being compiled forms part of package foo. If this flag is omitted (a very common case) then the default package main is assumed. Note: the argument to -package-name should be the full package identifier for the package, that is it should include the version number. For example: -package mypkg-1.2. I observe that the example uses -package rather than -package-name, and wonder if this is a mistake. Moreover, when I attempt to use the flag, like so: $ ghc -package-name hat-2.06 ... command line: cannot parse 'hat-2.06' as a package identifier This used to work with ghc-6.6.x and ghc-6.8.x, but seems to have stopped working with ghc-6.10.x. I surmise that the leading zero after the version point separator is to blame? It seems an unfortunate regression. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: What is the mutator?
Say you are implementing a network server, for example -- you don't want to have big spikes in the request latency due to GC. We think concurrent GC is unlikely to be practical in the Haskell setting, due to the extra synchronisation needed in the mutator. -- Simon Marlow It is perfectly possible to do real-time concurrent garbage collection for Haskell, in an incremental fashion that guarantees a small maximum bound on each packet of GC work. The tradeoff is that the percentage of time devoted to GC in total is much greater, and the mutator must do more work to co-operate with the GC. In other words, the program runs slower. This tradeoff is the same for all real-time garbage collection schemes as far as I am aware, in any language - either you can have responsiveness, or you can have better overall application speed, but you cannot have both. So I wonder, to what degree is GC latency controllable in Haskell? It seems that, pending further research, we can not hope for concurrent GC. There have been several papers on real-time GC in Haskell (including one of my own). There is no technical problem, only performance worries. This is what I think Simon means by unlikely to be practical. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: What is the mutator?
i'm not an expert, but: once value of thunk is evaluated, it's written back by code called mutator Whilst that is indeed mutation, it is not what is usually referred to as the mutator in the context of garbage collection. Quite simply, the mutator is the actual running program, as opposed to the GC, which is part of the underlying runtime system. Conceptually, the mutator and GC are the two mutually-exclusive threads of control that modify the heap. Usually one must halt while the other runs. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Data.List permutations
Your function is not equivalent: perm _|_ = _|_ permutations _|_ = _|_ : _|_ I have a vague memory that the library version diagonalises properly, so that if you give it a lazy infinite input, it still generates sensible output lazily. If so, this important property should be noted in the haddocks. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to save a haskell data structure in C?
In C code, I want to save a complex data strcuture defined in haskell and pass it back to a haskell function at certain time. Look up StablePtr in Haskell's FFI spec. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Proposal: Deprecate ExistentialQuantification
I would hereby like to propose that the ExistentialQuantification extension is deprecated. It is worth pointing out that all current Haskell implementations (to my knowledge) have ExistentialQuantification, whilst there is only one Haskell implementation that has the proposed replacement feature, GADTs. Of course, that in itself is not an argument to avoid desirable change to the language, but it is one factor to consider. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Under OS X 10.5.6: GHC 6.10.1 Release Candidate 1
Max Bolingbroke batterseapo...@hotmail.com wrote: 2009/3/27 Simon Marlow marlo...@gmail.com: I have a fix for num012 (the test is broken), but I still don't know what's going on with num009. num009 has been broken on OS X for as long as I can remember :-). If it is any help, I can confirm that num009 works correctly on a PowerPC Mac with both ghc-6.8.2 and 6.10.1, but it fails on an Intel Mac at least as far back as ghc-6.8.3. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Int vs Word performance?
Claus Reinke claus.rei...@talk21.com wrote: A while ago, I needed lots of fairly small positive numbers, together with a small number of flags for each, so I thought I'd switch from Int to Word, and map the flags to bits. Since there are few guarantees about the size of a Word (or Int), surely it would be better to choose a definitely sized basic type, e.g. Word8 or Word16? I vaguely recall that ghc used to generate better code for definitely sized WordN than the generic unguaranteed-size Word. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ./T and ./T log
Simon Marlow marlo...@gmail.com wrote: stdout should be flushed when the program exits, regardless of whether it exits as a result of a clean exit or an exception. I've just checked the code, and that's certainly what is supposed to happen. If anyone has evidence to the contrary, please submit a bug report! I believe flushing of file handles on program exit is handled by finalizers attached to the handle. Until recently, ghc did not guarantee that any finalizer would ever run. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: how dynamic stack approximation works
Peter Hercek pher...@gmail.com wrote: http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack I was writing about a way how to maintain the stack as described in point 6 of the page (provided that point is about dynamic stack). The whole page (including point 6) is about explicitly maintaining a (simulated) lexical call stack, not the dynamic one. As I already said in other emails, I would rather choose dynamic stack over lexical one if I was forced to choose only one of them. Actually, I almost do not care about lexical stack and still do not understand why people want it. In a lazy language, the dynamic stack rarely tells you anything of interest for debugging. For the value at the top of the stack, you get one of many possible _demand_ chains, rather than the creation chain. The demanding location is pretty-much guaranteed not to be the site of the bug. But you can think of the lexical call stack as what _would_ have been the dynamic call stack, if only the language were completely strict rather than lazy. Most people find the latter notion more intuitive for the purposes of finding program errors. Sure, but the plan to maintain an approximate debugging dynamic stack depends on one thing: There is no need to approximate the dynamic stack. It is directly available to the RTS, in full detail. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hsc2hs and HsFFI.h
Currently, hsc2hs (as shipped with GHC) cannot be used with just hsc2hs Foo.hsc as it cannot find HsFFI.h The hsc2hs repo includes a shell script (yes, I know, no good on Windows) called hsc2hs.wrapper that already adds some default arguments. (nhc98 has a modified version of the script, adding a -I$(includedir)) Another option would be for the user to tell hsc2hs which compiler they're using, e.g. hsc2hs --compiler=/usr/bin/ghc Foo.hsc On my system, hsc2hs is already installed as hsc2hs-ghc, in addition to the plain hsc2hs, so if I want the compiler-specific tool, I can use it directly. (nhc98 should do the same thing, i.e. install hsc2hs-nhc98, but I believe for historical reasons, it simply avoids installing hsc2hs at all, to avoid conflicts with the ghc one.) Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
bug in ghc specialiser?
Here is an apparent bug in ghc's specialisation rules. The rewrite rule
generated by a SPECIALISE pragma seems to want to pattern-match on exact
dictionaries (as well as types). But the compiler is not necessarily
able to fully resolve dictionaries before the rules are supposed to
fire.
First, the source code we want to specialise:
{-# SPECIALISE
hedgehog :: Float - Vector3 Float
- [Cell_8 (Coord3 Float)]
- [Cell_8 (Vector3 Float)]
- [(Coord3 Float, Coord3 Float)]
#-}
hedgehog :: ( Fractional a, Cell cell vert, Eq vert
, Geom coord, Geom vector, Embed vector coord ) =
a - vector a
- [cell (coord a)]
- [cell (vector a)]
- [(coord a, coord a)]
And the core + interface generated for this module contains the rule:
SPEC Hedgehog.hedgehog ALWAYS forall
Hedgehog.hedgehog @ GHC.Float.Float
@ RectGrid.Cell_8
@ CellTypes.MyVertex
@ Geometries.Coord3
@ Graphics.Rendering.OpenGL.GL.CoordTrans.Vector3
GHC.Float.$f16
RectGrid.$f2
CellTypes.$f1
Geometries.$f5
Geometries.$f3
Geometries.$f1
= Hedgehog.hedgehog1
But in a different module, here is what the usage site looks like just
before the specialisation rules are supposed to fire:
hedgehog_a4wy =
Hedgehog.hedgehog
@ GHC.Float.Float
@ RectGrid.Cell_8
@ CellTypes.MyVertex
@ Geometries.Coord3
@ Graphics.Rendering.OpenGL.GL.CoordTrans.Vector3
$dFractional_a4xP
RectGrid.$f2
CellTypes.$f1
(Dataset.$p2Embed
@ Graphics.Rendering.OpenGL.GL.CoordTrans.Vector3
@ Geometries.Coord3
Geometries.$f1)
(Dataset.$p1Embed
@ Graphics.Rendering.OpenGL.GL.CoordTrans.Vector3
@ Geometries.Coord3
Geometries.$f1)
Geometries.$f1
Notice how there are several dictionary selector functions sitting
there, so although some of the dictionaries match, not all do, and the
rule does not fire. However, later the worker-wrapper transformation
is able to resolve those outstanding dictionaries, giving:
hedgehog_a4wy =
Hedgehog.$whedgehog
@ GHC.Float.Float
@ RectGrid.Cell_8
@ CellTypes.MyVertex
@ Geometries.Coord3
@ Graphics.Rendering.OpenGL.GL.CoordTrans.Vector3
GHC.Float.$f16
RectGrid.$f2
Geometries.$f5
Geometries.$f3
Geometries.$f1
So I'm left calling the worker for the polymorphic version of the
function, rather than the specialised monomorphic code I wanted. Given
how many dictionaries are involved, and that this is the inner loop of
the program, I'm hoping there is a big performance win waiting for me,
if only I can get that specialised code to run!
Regards,
Malcolm
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Type signature inside an instance declaration
Kwanghoon Choi lazysw...@gmail.com wrote: = instance Arg a = Arg [a] where pr _ = [ ++ pr (undefined :: a) ++ ] = You want to use `asTypeOf`, with a lazy pattern to name a value of type 'a'. pr xs = [ ++ pr (undefined `asTypeOf` x) ++ ] where (x:_) = xs or pr ~(x:_) = [ ++ pr (undefined `asTypeOf` x) ++ ] Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded [slowdown]
It seems that the problem you have is that moving to the multithreaded runtime imposes an overhead on the communication between your two threads, when run on a *single CPU*. But performance on a single CPU is not what you're interested in - you said you wanted parallelism, and for that you need multiple CPUs, and hence multiple OS threads. Well, I'm interested in getting an absolute speedup. If the threaded performance on a single core is slightly slower than the non-threaded performance on a single core, that would be OK provided that the threaded performance using multiple cores was better than the same non-threaded baseline. However, it doesn't seem to work like that at all. In fact, threaded on multiple cores was _even_slower_ than threaded on a single core! Here are some figures: ghc-6.8.2 -O2 apply MVarstrict thr-N2 thr-N1 silicium 7.307.95 7.23 15.25 14.71 neghip4.254.43 4.186.67 6.48 hydrogen 11.75 10.8210.99 13.45 12.96 lobster 55.851.5 57.676.6 74.5 The first three columns are variations of the program using slightly different communications mechanisms, including threads/MVars with the non-threaded RTS. The final two columns are for the MVar mechanism with threaded RTS and either 1 or 2 cores. -N2 is slowest. I suspect the underlying problem in your program is that the communication is synchronous. To get good parallelism you'll need to use asynchronous communication, otherwise even on multiple CPUs you'll see little parallelism. I tried using Chans instead of MVars, to provide for different speeds of reader/writer, but the timings were even worse. (Add another 15-100%.) When I have time to look at this again (probably in the New Year), I will try some other strategies for communication that vary in their synchronous/asynchronous chunk size, to see if I can pin things down more closely. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded [slowdown]
Simon Marlow marlo...@gmail.com wrote: Malcolm Wallace wrote: For the only application I tried, using the threaded RTS imposes a 100% performance penalty - i.e. computation time doubles, compared to the non-threaded RTS. This was with ghc-6.8.2, and maybe the overhead has improved since then? This is a guess, but I wonder if this program is concurrent, and does a lot of communication between the main thread and other threads? Exactly so - it hits the worst case behaviour. This was a naive attempt to parallelise an algorithm by shifting some work onto a spare processor. Unfortunately, there is a lot of communication to the main thread, because the work that was shifted elsewhere computes a large data structure in chunks, and passes those chunks back. The main thread then runs OpenGL calls using this data -- and I believe OpenGL calls must run in a bound thread. This all suggests that one consequence of ghc's RTS implementation choices is that it will never be cheap to compute visualization data in parallel with rendering it in OpenGL. That would be a shame. This was exactly the parallelism I was hoping for. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: IMCROSS and ghc
basically, IMCROSS installs a couple new gccs with names like /usr/local/bin/i386-mingw-gcc and so forth, is there some way to get ghc to use said non-native compiler as its back end? I don't know about IMCROSS specifically, but earlier this year Sylvain Nahas adapted the build system of nhc98 to allow it to become a cross-compiler. At configure time, you simply give some additional arguments to point to the C cross-compilation toolchain, e.g. ./configure --target=i386-mingw --hostcc=i386-mingw-gcc --hoststrip=... --endian=-DLOW_BYTE_FIRST --ccoption=... --ldoption=... Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[2]: ghci and ghc -threaded broken with pipes forking
Had you deprecated the non-threaded RTS, we would probably have no problems described in ticket #2848 :-/ I think you'll have to deprecate it anyway, because it will be more and more difficult to maintain two versions of code, we may conduct small survey on amount of usage of old RTS (i mean ask this in haskell-cafe) For the only application I tried, using the threaded RTS imposes a 100% performance penalty - i.e. computation time doubles, compared to the non-threaded RTS. This was with ghc-6.8.2, and maybe the overhead has improved since then? Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't compile GHC 6.8.2
The suggested remedy of commenting out the line reading SRC_HC_OPTS += -fvia-C in the Makefile won't work, as that line isn't there anyway. In case it is not obvious from what other people have said, way back in the days of ghc-6.2, you got -fvia-C by default, whether it was specified on the command-line or not. To override via-C, you needed to explicitly choose the opposite (-fasm). With more recent versions of the compiler, the default flipped over to -fasm. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.10.1 type puzzler
test2 :: Box a - a - [a]
test2 box x = go x
where
-- go :: a - [a]
go y = [(val box), y]
Couldn't match expected type `a1' against inferred type `a'
You need to turn on {-# ScopedTypedVariables #-}.
See
http://www.haskell.org/ghc/docs/latest/html/users_guide/other-type-extensions.html#scoped-type-variables
Your first example works without this extension, because the local
definition 'go' is fully polymorphic. However, in the second example,
the type variable 'a' in the signature of 'go' is not fully polymorphic
- it must be exactly the _same_ 'a' as in the top-level signature.
Regards,
Malcolm
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unicode's greek lambda
When the -XUnicodeSyntax option is specified, GHC accepts some Unicode characters including left/right arrows. Unfortunately, the letter greek lambda cannot be used. Are there any technical reasons to not accept it? The greek lambda is a normal lower-case alphabetic character - it can be used in identifier names. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Build system idea
John Meacham [EMAIL PROTECTED] wrote: (bring back hmake! :) ). It never went away... http://www.cs.york.ac.uk/fp/hmake I even have the idea to allow hmake to read the .cabal file format for configuration data (although that is waiting for a delivery of round tuits). Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
Manuel wrote: | It is worth pointing out that I *never* validate against ghc head when | I commit to the core libraries. Sorry, but I think the only reason its halfway acceptable is that Malcolm didn't break the GHC build yet. If he does, I'll be screaming as loudly as for anybody else. Whilst I'm in no way saying that a working nhc98 head is anything like as important as a working ghc head, are you saying that I should scream louder everytime someone breaks nhc98 too? It is happening several times a week at the moment. It can be jolly frustrating when I have other things I could be doing. But I accept that it is simply the price to pay for keeping up-to-date with the libraries everyone else is using. Ghc has no monopoly on the core libraries. They are a shared resource. to be honest, I don't think its a valid reason for us to go to the trouble of having two vcs for ghc. Well indeed, I don't want to stand in the way of ghc. There are far more people contributing to it, so their needs have greater weight. But I am raising the libraries question, because I think it has an impact much more widely than just ghc (or Hugs or nhc98, for that matter). Git may turn out to be sufficiently easy to use that this will all seem like a storm in a teacup once the dust has settled. (I'm not filled with confidence by blog postings that say granted, git is a usability disaster zone, and [you] may find git to be hostile, unfriendly and needlessly complex, but those seem to be minority opinions.) Regards, Malcolm Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
I don't think that is the right policy. Everybody (including Malcolm) should validate. If you contribute code to the linux kernel, comprehensive testing of the code is a requirement, too. The analogy is flawed. It is like asking the developers of _gcc_ to ensure that the Linux kernel still builds after every modification to the gcc project code base. The projects are different, so the suggested requirement would be an unreasonable burden. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
I think an even better analogy is probably comparing it to developer of GCC changing the libc implementation of another compiler or vice versa. Our shared libraries do not belong to any one compiler. They are joint creations, with a lot of community (non-compiler-hacker) involvement. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
On 12 Aug 2008, at 01:35, Manuel M T Chakravarty wrote: Ah, good point! Changing ghc to git means *all* developers of boot libraries need to use git *regardless* of what repo format the boot libraries are in. After all, they need to validate against the current ghc head before pushing. It is worth pointing out that I *never* validate against ghc head when I commit to the core libraries. (Actually, I don't even keep any checkout of ghc head.) Generally I'm fixing something that has unintentionally broken the nhc98 build of the libraries, *despite* the breaking-patch being validated against ghc. To be honest I don't particularly care if my fixing patch then breaks ghc again. Why not? Because the chain of blame effectively leads back past me to the earlier patch. (In practice, re-breaking ghc is very rare.) Now, there is only one person taking care of nhc98 (me), and probably I'm its only user as well, but I do still think it is worth the 30 secs or so every day it takes to check the nightly build logs and the 30mins it occasionally takes to fix breakage when necessary. Building a full Haskell'98 compiler is a significant undertaking, and it would be a great shame to simply discard it because the libraries are no longer available in a shared format. Who knows, maybe someone will find it easier to port to their iPhone than ghc. :-) What I'm not really prepared to do is to extend the fixing time by an extra 30mins just to validate against ghc. I might be prepared to learn a new VCS, but from what I've seen so far, git looks rather complex and difficult to use. It is also worth noting that where a larger community of developers has gathered around a core library (e.g. Cabal), ghc has found it necessary to branch off a ghc-only version of that library, so that commits to the library head do not need to be validated against ghc head. Igloo takes care of merging across a large bunch of patches every once in a while. This model seems to work well. In theory, the core library head could remain in darcs, with the ghc branch of it in git. All the pain of merging would be dumped on one person (sorry Igloo!) but everyone else gets the benefit. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: git and sync-all: Why not merge in libraries?
With the upcoming switchover to git, has any thought gone into merging in the libraries into the main ghc tree The libraries are going to remain under darcs, because they are shared with other haskell compilers. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Optimization beyond the Module Border
I'd be interested in any progress here -- we noticed issues with optimisations in the stream fusion package across module boundaries that we never tracked down. If there's some key things not firing, that would be good to know. I suspect that if all modules are compiled -O0, then you recompile one module with -O2, high up in the dependency graph (i.e. it depends on many lower-level modules), plus all things that in turn depend on it (--make), you will not get the good performance you expect. None of the lower-level functions will have exported inlinings or fusion rules into the interface file. _All_ modules must be recompiled with -O2, especially the bottom of the dependency chain, to get the best benefit from optimisation. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: binary-dists for ghc-6.8.2
I've built binary distributions for Mac OS 10.4 (Tiger) based on (better supported) GMP and GNUreadline frameworks and for Solaris 10. http://www.dfki.de/sks/hets/mac/versions/ghc-6.8.2-powerpc-apple-darwin.tar.bz2 http://www.dfki.de/sks/hets/intel-mac/versions/ghc-6.8.2-i386-apple-darwin.tar.bz2 The frameworks under http://www.haskell.org/ghc/dist/mac_frameworks/mac_e.htm should do. Are these going to be added to the main ghc-6.8.2 downloads page? Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Case of Language pragma - bug?
Yes at the moment we allow LANGUAGE language but not Language or LanGUAge Being allowed to write Language would be nice I concur. Surely it is easy to just (map toLower) over the pragma identifier before comparison with known pragma names? Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to use qualified name ModuleName.(.!.) ?
Marc Weber [EMAIL PROTECTED] wrote: print $ M.(.!.) [1,2] 1 -- (2) The parens must enclose the whole varop: print $ (M..!.) [1,2] 1 -- (2) Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Seemingly subtle change causes large performance variation
Matthew Danish [EMAIL PROTECTED] wrote: I've been playing with the INTEST problem on SPOJ which demonstrates the ability to write a program which processes large quantities of input data. http://www.spoj.pl/problems/INTEST/ I don't know if anyone replied to this already, so here is my attempt to explain the space leak. doLine :: Int - Int - IO Int doLine r _ = B.getLine = testDiv r testDiv r l | int l `divisibleBy` k = return (r + 1) | otherwise = return r But when I make a slight modification, the program chews up a ton more memory and takes more time: doLine :: Int - Int - IO Int doLine r _ = B.getLine = return . testDiv r -- 'return' moved here ^^ testDiv r l | int l `divisibleBy` k = r + 1 | otherwise = r In the first version, the strictness of the IO monad ensures that 'testDiv' must be evaluated, at least sufficiently to find the 'return' monadic action inside it. In particular, this forces the evaluation of the guard, and therefore the call of `divisibleBy`. Whereas in the latter version, the 'return' is wrapped _outside_ the call to 'testDiv', so the monadic action is found immediately, whilst the value being returned in in the monad is still lazily calculated. Thus, a collection of 'testDiv r' applications builds up until the Int values are actually used, at which point they are reduced. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Prelude not in haskell98?
Iavor Diatchki wrote: Just curious, what external modules does the Prelude depend on? I'm not really sure what you mean by external modules. In GHC the Prelude is comprised almost entirely of re-exports from other modules. Just to note that, although ghc's inversion of the expected dependency relationship is mildly confusing the first time you come across it, that design decision is not the only one possible. Other compilers, such as nhc98, treat the haskell98 Prelude more like it is specified in the Report, as a stand-alone module that depends on nothing else. In such a compiler, the 'base' package does not (and cannot) contain the Prelude, which necessarily lives at a lower more basic level in the library hierarchy. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Why do we have stack overflows?
Adrian Hey [EMAIL PROTECTED] wrote: Failing because the stack has grown beyond some arbitrary (and typically small) size seems bad to me. Just FYI, nhc98 has a single memory area in which the stack and heap grow towards each other. Memory exhaustion only happens when the stack and heap meet in the middle and GC fails to reclaim any space. However, it can only do this because it is single-threaded. As soon as you need a separate stack for each thread in a multi-threaded system, this nice one-dimensional model breaks down. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
I wrote: So, should I push my patch for building System.Posix.Types with nhc98 (i.e. without autoconf, with hsc2hs)? OK, I have pushed a revised patch, which should not alter the behaviour for ghc at all. I moved the invocation of hsc2hs into the NHC.* hierarchy, and just re-export that module from System.Posix.Types instead. Regards, Malcolm ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
Simon Marlow [EMAIL PROTECTED] wrote: Also after the base reorg we might find we have no hsc2hs-generated code left in base and we can disable hsc2hs to prevent this happening again. Ah. I was about to checkin a replacement for System.Posix.Types (in base) that uses hsc2hs instead of autoconf. Will that cause a problem? I'm guessing that even the autoconf'd sources are currently bootstrapped on the host rather than the target, so maybe the changeover will make no difference? Regards, Malcolm ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
Simon Marlow [EMAIL PROTECTED] wrote: I suppose we could add a dependency on another Haskell compiler just to run hsc2hs, but that's a pain. I'm hoping that by the end of this summer, nhc98 will be able to compile the whole of ghc. :-) Also, and alternatively, the yhc chaps have mooted the idea of moving from nhc98's front end to ghc's, which might eventually give you a fully portable bytecode route to bootstrapping ghc on new machines. Pipe dreams for now though. Regards, Malcolm ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
Simon Marlow [EMAIL PROTECTED] writes: Ah. I was about to checkin a replacement for System.Posix.Types (in base) that uses hsc2hs instead of autoconf. Anyway, to answer your question, using hsc2hs in System.Posix.Types will cause problems for bootstrapping GHC, yes, because we can't run hsc2hs on the target without GHC, but we can run configure. But it is only a problem for cross-compiling - yes? And no more of a problem than ghc already has? So, should I push my patch for building System.Posix.Types with nhc98 (i.e. without autoconf, with hsc2hs) or not? At the moment, the lack of System.Posix.Types is breaking the nightly builds of Cabal/nhc98. Regards, Malcolm ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Become a GHC build slave!
Wilson MacGyver [EMAIL PROTECTED] wrote: there is no reason for multiple build-bot for the same platform is there? If you have two or three slaves for each platform, then the buildbot is robustified against downtime of any of the machines (intentional, like going on holiday for a couple of weeks, or unintentional when the machine just dies). Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: OPTIONS_GHC -auto-all
Serge D. Mechveliani [EMAIL PROTECTED] wrote:
{-# OPTIONS_GHC -fglasgow-ext -prof -auto-all #-}
LemmaSearch.hs:
unknown flags in {-# OPTIONS #-} pragma: -fglasgow-ext -prof -auto-all
You have spelled the first option wrongly: should be -fglasgow-exts.
Regards,
Malcolm
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hsman
Seth Kurtzberg [EMAIL PROTECTED] writes: how about searching code that's outside of the standard library? Hoogle doesn't seem to know about HaXml, or haskelldb for example (maybe I am missing something obvious) You want to distinguish between capabilities, and the fact that the database for hoogle may not include all the data that is available. If the issue is only the availability of the data, perhaps the best option is to add the data to hoogle. Don't forget that, as well as a web engine, Hoogle is also a command-line tool. You can download it, and populate its database with all (and exactly) the libraries you have installed. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: seq vs. pseq
Simon Marlow [EMAIL PROTECTED] wrote: When I use `seq`, it is sometimes in a construction like unsafePerformIO (emit squawk!) `seq` x My take on this kind of thing is that if you want a specific operational behaviour, then you're doing something implementation-specific. We shouldn't mandate any kind of operational behaviour across Haskell implementations. Yes, I'm saying you can't do this portably, and it is good that you can't, because it gives implementations more flexibility. Hmmm. I absolutely agree with the general point that Haskell should, as much as possible, not mandate any specific operational behaviour. But what if I want to _observe_ or record the actual operational behaviour of some particular implementation? For instance, to generate a heap profile, or a computational trace, or a coverage log, or something. The results may well be different for every different implementation, and I am perfectly happy with that. I may actually want to see the differences. But do you really want to say The Haskell language provides the programmer no mechanism to observe this? Use some other language, or some compiler-specific hack? To me, it is unacceptable to be prevented from write an observational tool for a language in the language itself. Especially since we already have a couple of features in the language that _do_ affect the operational behaviour. They are warts, yes, but if we have to have them, I want them to be genuinely useful. We should bite the bullet and specify in what way they affect the operational semantics, without implying any more specific operational behaviour elsewhere in the language. Regards, Malcolm P.S. Actually, as Ross points out, there is an implied operational semantics of the I/O monad. Maybe that is where the Report needs to become more specific, and mandate certain behaviours. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: seq vs. pseq
Simon Marlow [EMAIL PROTECTED] wrote: The report is in general very careful to say absolutely *nothing* about evaluation order, leaving the implementation free to choose, Yes, this is a highly desirable goal. However, having said all that, arguably an exception should be made in this case. The main use of seq (and strictness annotations) is to control operational behaviour, rather than to change the semantics of the program Indeed, `seq` is widely viewed as a wart on the language _because_ it specifies the evaluation order, which is something otherwise avoided in the Report. So the doubly bizarre thing is that, actually, `seq` does not control the evaluation order (which is the only valid reason for wanting to use it in the first place), but nevertheless it undesirably changes the semantics of programs such that equational reasoning no longer holds. I think if we are going to allow ourselves the luxury of semantic breakage, it should at least be worth the cost - we should get some real and definite operational control in return. That is why I think this: the evaluation-order property of seq should be a strong hint, not a requirement - otherwise we fall into the trap of mandating evaluation order. is not strong enough. `seq` should guarantee sequential evaluation. If you want a strong (but not mandatory) hint to the compiler about strictness, than that should be a different construct at the user level. At the moment, these alternatives are named `pseq` and `seq`. One suggestion is just to reverse their sense. Another is to use bang patterns for hints. Another might be to introduce strictness hints in type signatures. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: OpenGL failing with Mac Intel 6.6 distribution
Deborah Goldsmith [EMAIL PROTECTED] wrote: I checked and the Mac OS X PowerPC binary distribution does not have this problem; only Mac OS X Intel. Is it possible that the Intel distro built the OpenGL package using Cabal, but the PowerPC distro used Makefiles? I seem to recall there was some issue with Cabal failing to copy C header files to the final installed location? Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: seq vs. pseq
Simon Marlow [EMAIL PROTECTED] wrote: The difference is subtle. The semantics of seq and pseq are identical; however, GHC can see that seq is strict in both its arguments and hence could choose to evaluate them in either order, whereas pseq is only strict in its first argument as far as the strictness analyser is concerned. The point is that pseq is useful for controlling evaluation order, which is what you want for adding parallelism to a program. seq, on the other hand, is not useful for controlling evaluation order. This is a rather weird thing, and I would consider it a bug in the Haskell Report, rather than a bug in ghc. (It bites hard when you are trying to implement something like HPC.) The very name 'seq' surely suggests that you are controlling the evaluation order. Please evaluate this thing on the left first. But that is _not_ what the Haskell Report says! Ghc takes the Report literally, and so the thing on the right is just as likely to be evaluated before the thing on the left! Surely the language designers did not intend this consequence. For Haskell-prime, can we fix this bug, and ensure that 'seq' really implies ordering of evaluation? [ If you just want strictness annotations, with the compiler free to reorder computations, I would say ($!) is a better bet, and could be redefined to use not the natural `seq`, but the strict-in-both-arguments variation. ] Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Debugging on Mac OS X
Luke Worth [EMAIL PROTECTED] wrote: I just installed GHC 6.6 using the PPC binary installer on Mac OS X. I'm having some trouble getting debuggers to work; I have tried both plargleflarp (buddha) and Hat. Neither of them will compile on GHC 6.6 on Mac yet. As an interim measure, I have just made available a 'snapshot' release of Hat-2.05, specifically to ensure that it compiles with ghc-6.6. This is very much a stop-gap. There have been huge changes in the standard base library package since the last full release of Hat, which are not reflected in 2.05. (For example, Parsec and Data.FiniteMap are no longer in base, whilst Data.Map, Data.Set and so on have been added. Hat still has the older API.) The Hat team is planning to rectify these problems shortly, but we are unlikely to be able to make a full release before the end of the year. I hope the 2.05 release is sufficient to meet at least some people's needs in the meantime. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cvs commit: hugs98 Makefile RPM.mk hugs98/libraries/tools convert_libraries
HaXml (no longer builds) In what way does HaXml fail to build for Hugs? Is it easily fixable? ... and there's the famous Data.FiniteMap. So does anyone have any objections if I go ahead and commit the replacement (compatibility) implementation of Data.FiniteMap to the main repository for packages/base? Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FiniteMap
So does anyone have any objections if I go ahead and commit the replacement (compatibility) implementation of Data.FiniteMap to the main repository for packages/base? I'd rather see HaXml updated to use Data.Map, perhaps with a compatibility layer for older GHCs. OK, I've looked more closely at all uses of Data.FiniteMap in HaXml, and they are far from critical, so have reverted them to using simpler lookup structures. As far as I can tell, none of my other software now depends on FiniteMap either, so I withdraw the threat to resuscitate it. (Sorry Duncan!) Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[2]: [GHC] #876: stack overflow on 'length . filter odd $ [0 .. 999999999]'
Bulat Ziganshin [EMAIL PROTECTED] wrote: It makes sense to me that the above behaviour is seen: length is now a good consumer, but it generates 1+(1+(1+(1+... as it is consuming, and this causes a stack overflow. I don't think we can fix this while staying with fold/build fusion, so it looks to me like the patch should be reverted and the whole problem looked at post-6.6. in general, for any function we can either implement 1) good consumer based on using foldr 2) tail-recursion are you agree? I'd like to point out that, if you are prepared to abandon foldr/build fusion in favour of hylo fusion, you can code good consumers using either foldr or foldl. (Length is a foldl, because it uses an accumulator.) Foldl is tail-recursive, but this does not prevent it being a good consumer, provided your framework of fusion laws is sufficiently flexible. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC compile times (was Re: GHC 6.4.3 is stalled)
Joel Reymont [EMAIL PROTECTED] wrote: Thanks for the tip! I'm _really_ interested in why it takes 55 min on Linux and 3+ hours on Mac Intel, though. Any clues? Building a compiler generally reads/touches/creates a very large number of files. So one possibility is the relative efficiency of the OS filesystem implementation. Apple's HFS+ is reputed to be fairly slow, as are the Microsoft filesystems (VFAT, NTFS), at least compared to the various unix-derived filesystems (UFS, ext2 etc). I recall from a few years back that building nhc98 took twice as long under Windows as under linux, on the very same machine, with the same versions of boot-compilers. The only major variable I could think of at the time was VFAT vs ext2. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC compile times (was Re: GHC 6.4.3 is stalled)
Joel Reymont [EMAIL PROTECTED] wrote: Thanks for the tip! I'm _really_ interested in why it takes 55 min on Linux and 3+ hours on Mac Intel, though. Any clues? Another thought. The ghc HACKING guide has this to say: The GHC build tree is set up so that, by default, it builds a compiler ready for installing and using. That means full optimisation, and the build can take a *long* time. If you unpack your source tree and right away say ./configure; make, expect to have to wait a while. For hacking, you want the build to be quick - quick to build in the first place, and quick to rebuild after making changes. Tuning your build setup can make the difference between several hours to build GHC, and less than an hour. Here's how to do it. http://cvs.haskell.org/cgi-bin/cvsweb.cgi/~checkout~/fptools/ghc/HACKING?content-type=text%2Fplain Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Lookup module and package defining x?
Marc Weber [EMAIL PROTECTED] wrote: My purpose: After having found the a function I want to use it without having to search where does it belong to and where does it come from. I want it beeing as up to date as the installed libraries. You can download Hoogle as a command-line tool, and give it your complete installed libraries to index. Then it will be accurate for your own setup. Of course, you would need to manually update it every time you install a new library. That's why I thought it might be best to integrate it into ghc? This kind of tool, though useful, has almost nothing in common with the compiler. Although I suppose it would be useful if Hoogle could read the ghc-pkg file format when indexing all locally-available modules. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RULES pragmas
[EMAIL PROTECTED] (Donald Bruce Stewart) wrote: So what am I doing wrong? And is there any way to ask the compiler to give a warning if the RULES pragma contains errors? In this case, it's because it's missing -fglasgow-exts, I think. Ah, thank you. The missing (and undocumented) option. Is there any reason why -fglasgow-exts should be required? Judging by the flag reference material in section 4.17.15, -frules-off is used to turn RULES off explicitly, but there is no corresponding flag to turn them on - hence I assumed they would be enabled by default when -O or -O2 is set. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RULES pragmas
Malcolm Wallace [EMAIL PROTECTED] wrote: Ah, thank you. The missing (and undocumented) option. Actually, now I came to submit a patch to the manual, I discover that it /is/ documented, but at the beginning of section 7. (But on the index page on the web, the link to section 7 is two whole screenfuls away from the link to 7.10, so it is no wonder I didn't think to look there first.) Maybe there are other subsections of 7 that could usefully gain a similar pointer to the need for -fglasgow-exts? For instance, are other pragmas (INCLUDE, INLINE, UNPACK) only activated by -fglasgow-exts? Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: -threaded
Christian Maeder [EMAIL PROTECTED] wrote: It doesn't work under solaris and under linux [1] my nightly compilation jobs are killed every tuesday morning (!) for some reason that i cannot reproduce. I suspect the threaded RTS and heavy load. I had no such problems with ghc-6.4.1 before. A process can be Killed by the operating system if the machine runs out of virtual memory. I suspect someone else is running a cron job on Tuesdays that fills memory. It is unlikely to be (only) ghc's fault. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] GHC Hackathon
I think many would be grateful if a podcast were made of this event such that those who missed it can still watch the presentations. +1. A podcast would be perfect, posting minutes would be next in line. If the Hackathon goes ahead, recording a video podcast of the event should be straightforward. (I've been playing with streaming web media lately, and can volunteer to do that side of things. The quality can be surprisingly good.) Mind you, even the compressed web streams will not be small - approx 150Mb per hour. A one day tutorial could easily stretch to over 1Gb. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.5 on Mac Os X
Chris Brown [EMAIL PROTECTED] writes: ld: Undefined symbols: _TypeRep_AClass_stauic_info I have noticed that there are spelling mistakes in these error messages. _TypeRep_AClass_stauic_info should be _TypeRep_AClass_static_info Earlier there was something with DISCASD instead of DISCARD If you are cutting and pasting these error messages (rather than typing them by hand), then this strongly suggests a faulty low bit in memory. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: darcs switchover
John Goerzen [EMAIL PROTECTED] writes: Meanwhile, I noted that the HaXml repo on darcs.haskell.org seems to be a verbatim copy of the darcs repo at York. Ahh. You are correct. Re-converting now, since you've presumably committed patches to the darcs side, is probably not going to be practical. Actually, the way I have been working is to commit changes to CVS first, then to (forget to) propagate them into darcs. AFAIK, the two repositories are in synch right now, but if there is ever any discrepancy, I always treat the CVS one as correct. Thus, now would be an excellent time to re-convert, and I would then throw away my own darcs repo and switch to treating the darcs.haskell.org repo as the master. I can't remember where the rest of the ghc conversion process has reached - is it also about ready to switch over to darcs-as-master yet? Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC vs. GCC on raw vector addition
Sven Moritz Hallberg [EMAIL PROTECTED] writes: I'm running GHC and GCC head-to-head on the task of adding a bunch of long IOUArray-Vectors really fast. My machine is a Linux-ppc PowerBook and gets a runtime for the GHC-compiled binary that's about 10x as long as for GCC. Is it possible that gcc is making use of the ppc AltiVec instructions, and ghc is not? Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: darcs switchover
John Goerzen wrote: * I will re-convert all of the top-level directories in the current libraries darcs repo, except for: doc, mk, and Cabal * Each new repo will be under darcs.haskell.org/packages Inspired by the new browsable interface to the libraries repo at http://darcs.haskell.org/darcsweb/ I have installed a similar darcsweb interface for the software currently distributed through darcs at York: http://www.cs.york.ac.uk/fp/darcs/ including cpphs, hoogle, yhc, Blobs and so on. Meanwhile, I noted that the HaXml repo on darcs.haskell.org seems to be a verbatim copy of the darcs repo at York. This this right? I was slightly disappointed, since I think I made a bit of a mess of the CVS - darcs conversion of HaXml, and was secretly hoping that when the fptools conversion happened, it would make a cleaner job of it, based on the full CVS history... Just wondering? Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: darcs switchover
Sven Panne [EMAIL PROTECTED] writes: I've been looking at the cvs configuration file CVSROOT/modules. I /think/ the procedure is something like changing this: nhc98src-d nhc98 nhc98 nhc98libraries -d nhc98/src/libraries fptools/libraries nhc98 -a nhc98src nhc98libraries to this: nhc98src-d nhc98 nhc98 nhc98libraries -o darcs get --reponame=nhc98/src/libraries \ http://cvs.haskell.org/darcs/libraries nhc98 -a nhc98src nhc98libraries and then a fresh cvs checkout of the nhc98 would be required in order to pick up the new location. As already mentioned on the cvs-all list this morning, this does not work... :-( No? I've tested it (using nhc98cpphs rather than nhc98libraries), and it seems to work for me. What is the problem? (Of course, I'm not trying to do a two-way synchronisation, just grafting a darcs repo into the cvs tree.) Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: darcs switchover
Simon Marlow [EMAIL PROTECTED] writes: But how about having a separate repository for each library package? The time to mention this would have been a few weeks ago when I proposed the current scheme :-) Err, I think I did... I think it /would/ actually be nicer to split up the repository into separate packages. However, of the two ways to do this that John mentioned, only the second is practical IMO - that is, generate the repositories from CVS. So it's entirely up to John whether he wants to put the effort in or not. Is there more to this job than just running either cvs2darcs or tailor, then waiting a few days (:-) for it to finish? Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: darcs switchover
[EMAIL PROTECTED] (Donald Bruce Stewart) writes: One thing it occurs to me to ask is what will be happening to CVS commit messages, once the switchover to darcs happens? I originally wrote this script as a temporary fix until darcs supported post-apply hooks. If it does now, perhaps there's no need for the wrapper, and instead a mail program can be invoked by darcs itself as a hook (i.e. just the core of darcs-mail can be `hooked'). Ah, yes I have just upgraded to darcs 1.05 (from 1.03), and there are posthooks available for every command now. However, there is one wrinkle that means we can't use a stripped-down version of your darcs-mail script directly. The command invoked by the posthook does not, AFAICS, get to look at the patch bundle. This means the posthook can only report a single patch per bundle, something like this: darcs changes -s --last=1 | mail -s darcs commit `cat mailinglist` where previously, the --last argument could in fact determine a fully accurate count of patches contained in the bundle. I'm not sure from the documentation whether multiple patches are normally submitted simultaneously from one repository to another, but I suspect the answer is yes. Any ideas? Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: darcs switchover
Simon Marlow [EMAIL PROTECTED] writes: The aim is to eventually switch over to using darcs for our revision control. The point of this message is to find out what constraints people have that will affect when we can throw the switch. One thing it occurs to me to ask is what will be happening to CVS commit messages, once the switchover to darcs happens? I have investigated this briefly, and it seems that darcs does not yet directly support mailing out commit messages from a repository. There is a wrapper script at darcs get http://www.cse.unsw.edu.au/~dons/code/darcs-mail but this requires administration privileges on the hosting machine, since you need to rename the darcs binary proper, then install the wrapper in its place. Also, it is unclear to me whether this wrapper works equally well in all situations, e.g. with 'darcs apply' on the hosting machine, 'darcs push' from a separate repository on the same host, or 'darcs push' from a remote machine with ssh. Anyone sufficiently familiar with this to shed any light? Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: darcs switchover
Ross Paterson [EMAIL PROTECTED] writes: No problem for me if you switch over at any time. But how about having a separate repository for each library package? Seconded. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: darcs switchover
Simon Marlow [EMAIL PROTECTED] writes: Malcolm, Ross - since you both also use the CVS libraries tree, is it going to be possible for you to switch to using darcs to get the libraries? Any idea how long you'll need? I've been looking at the cvs configuration file CVSROOT/modules. I /think/ the procedure is something like changing this: nhc98src-d nhc98 nhc98 nhc98libraries -d nhc98/src/libraries fptools/libraries nhc98 -a nhc98src nhc98libraries to this: nhc98src-d nhc98 nhc98 nhc98libraries -o darcs get --reponame=nhc98/src/libraries \ http://cvs.haskell.org/darcs/libraries nhc98 -a nhc98src nhc98libraries and then a fresh cvs checkout of the nhc98 would be required in order to pick up the new location. Has anyone else tried this kind of tweak before and confirm that it is likely to work? If not, I might test it out with the smaller cpphs module initially. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Optimizations for mutable structures?
Simon Marlow [EMAIL PROTECTED] writes: In the general case, for some arbitrary actions between the write and the read (excluding another write of course), there is no guarantee that the IORef remains unmodified. This is an analysis that's performed all the time in C compilers, it's quite straightforward to do a good approximation. One simple algorithm is: a store can be forwarded to a matching read as long as there are no intervening writes that may alias, or function calls. C does this and C has threads, so what's the difference? There is a big difference between C variables and IORefs. For one thing, a C variable can have scope local to a procedure. If so, then the suggested transformation is entirely valid even in the presence of threads, because no other thread is permitted access to the local variable. M[fp+offset(x)] - v ... w - M[fp+offset(x)] === M[fp+offset(x)] - v ... w - v Global variables are more tricky, but I guess it is probably common to permit the elimination of the 'read' there as well, even though technically this is unsafe in the presence of threads. My guess is that this behaviour is the cause of a lot of thread unsafeness in common C libraries however. M[address(x)] - v ... w - M[address(x)] === M[address(x)] - v ... w - v Haskell has neither local nor global variables in the same sense as C. IORefs more closely resemble C pointers. A pointer has indeterminate lifetime and scope. It can be passed around from procedure to procedure, and from thread to thread. There can be aliases to the same memory location in multiple other contexts. If I'm writing a hardware driver, the pointer address might be memory-mapped to a device register, in which case writing to that address and immediately reading back from it may not be an identity. I've certainly dealt with devices where the same hardware port when written to, expects control data, but when read from delivers status data. So here: M[M[x]] - v ... w - M[M[x]] it would be totally incorrect for the compiler to eliminate the read. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Optimizations for mutable structures?
Jan-Willem Maessen [EMAIL PROTECTED] writes: - Fetch elimination for imperative reads: writeIORef r e acts readIORef r === writeIORef r e acts return e This transformation is valid only on single-threaded systems. If there is any possibility of an IORef being shared across threads, you are out of luck. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Optimizations for mutable structures?
Simon Marlow [EMAIL PROTECTED] writes: I should have said that if 'acts' blocks, then the transformation is invalid. Well that is exactly what I was assuming when I said that the transformation is invalid. In the general case, for some arbitrary actions between the write and the read (excluding another write of course), there is no guarantee that the IORef remains unmodified. If you want to restrict the intermediate actions to be non-blocking, such that another thread cannot run, then that is an extra (and significant) proof obligation. And AFAICS your non-blocking argument only applies to co-operative scheduling. If pre-emption is permitted (e.g. interrupt-handling), then all bets are off, because an arbitrary thread could write to the IORef at any moment. I don't think so. Malcolm asserted that the transformation was invalid in a multi-threaded implementation; I disagree - it's just as valid in a multi-threaded implementation as a single-threaded one. I think what I said was correct in general. You need quite a lot of side-conditions to assert the opposite. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Optimizations for mutable structures?
[previously sent by mistake to Simon only - new para at end] Simon Marlow [EMAIL PROTECTED] writes: Now, take the original program, but change the creation of m2 to newMVar (), i.e. m2 starts off full. Is the transformation valid now? Well maybe, because in some interleavings acts does not block, and we can prove that at compilation time. I don't think it is valid for a compiler to say that one possible execution path permits me to remove some code, therefore I will remove that code on all possible execution paths. The example I had in mind was a GUI where the action writeIORef r e acts readIORef r is intended to capture a situation where first we record some global configuration data for the application, then permit some arbitrary GUI actions to occur, and then we retrieve the configuration data again. My expectation is that the config data /will/ have been changed by some other GUI thread. Surely it cannot be OK for the compiler to silently deliver the original unchanged data here - it goes against the programmer's intention. Surely, if a Haskell programmer is going to write code that explicitly reads from a reference after writing to it, that sequence must 9/10 be intentional: otherwise wouldn't she have just used a let-binding? Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
