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 > 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 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
> > Simon, Malcolm, here's a solution (at risk of more bikeshedding on syntax). > >e { foo } > > * The braces say 'here comes a record'. > * Also say 'expect funny business with names'. > * The absence of `=` says this is getFld, not update. > * This is not currently valid syntax [**], so we don't break code. > * It's postfix. (And only a couple more chars than infix dot.) > * So perhaps an IDE can see the opening brace and prompt for fields? >(Perhaps some IDE's do this already for record update?) I like it. It fits with the existing syntax. Nested records are chained: foo{bar}{subbar}{zed} > Possible future development: > >e { foo, bar, baz } -- produces a tuple ( _, _, _ ) > -- with fields in order given > -- _not_ 'canonical' order in the data type > > * By coincidence, that syntax is per one of the dialects for >relational algebra projection over a tuple. Not quite so keen on this. I would argue that in relational algebra (which I use a lot, although with a dynamically-type API, rather than strongly-typed), the ordering of columns and rows is never significant, and should never be exposed to the user directly. I long for the day when we can offer a strong-typing to Relations, but it would be worse to pretend that something is kind-of relation-like, without the underlying properties that make it powerful. 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 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 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 ). >> * From the application (h x) we learn that x's type has >> shape (F [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
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: Why not allow empty record updates?
On 14 Nov 2011, at 22:09, Simon Peyton-Jones wrote: > Trouble is, what type does this have? > > f x = x {} f :: a -> a Empty record patterns {} are permitted, even for types that are not declared with named fields. So I don't see why an empty record update should require the type to be declared with named fields either. 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 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 > > GhcStage1H
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
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: 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: 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: Language extensions - backwards compatibility
Any sort of preprocessing at the beginning of a file appears to insert enough noise to inhibit recognition of file-header pragmas. (Cpphs doesn't appear to help here.) 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? Regards, Malcolm ___ 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: 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: 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: 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 ... : 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 wrote: > 2009/3/27 Simon Marlow : > > 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" 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: how dynamic stack approximation works
Peter Hercek 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: ./T and ./T >& log
Simon Marlow 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
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: 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
Re: Type signature inside an instance declaration
"Kwanghoon Choi" 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 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: pseq strictness properties
Duncan Coutts <[EMAIL PROTECTED]> wrote: > I guess we can try to simplify it to something like "evaluation > happens here" (pseq) vs "evaluation happens here or before" (seq). No, that is not correct, or at least it is highly misleading. The key difference between them is that: (x `pseq` y) = if y is not yet in WHNF, the compiler guarantees that x will be evaluated to WHNF before y. (x `seq` y) = if y is not yet in WHNF, the compiler can choose whether to evaluate y to WHNF before x, or x before y. In other words, pseq guarantees sequencing (given a side condition), whilst seq does not guarantee sequencing. 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
> 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
> 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
- Why does NHC98 break so often? Is it because people are checking in code that is not Haskell 98 compatible? Yes, there is a bit of that. Also, as you point out, there is quite a lot of CPP conditionally compiled code in the libraries, and I would say that it is the major contributor to breakage. It is often unclear which parts of the code are shared and which separate, so a lot of breakage arises from e.g. exporting a name that is defined for ghc only. In addition, there are some (once obscure) bugs in nhc98 that are now triggered increasingly frequently. (We can't blame anyone except nhc98 for those of course.) These include complex import renaming resolution, and contexts on pattern variables. - It seems to me that implementations "share" libraries using CPP. That seems like a bad approach to me. Agreed. The CPP was always intended to be as temporary as possible, with the goal to share as much as possible. One of the problems is that the primitives provided by compilers are different. Really, there should be a package below 'base' in the dependency tree, specific to each compiler, and non-shared. Then everything from base upwards would be cleaner and more portable. If it's so difficult to share code without continuously breaking the build then we're better of keeping the code separate. I don't agree. The only way to achieve convergence is to start from some semi-merged point, and work to eliminate the differences. Igloo is doing a fantastic job of determining the dependencies and gradually moving stuff around to enable this to happen. 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: Build system idea
Simon Marlow <[EMAIL PROTECTED]> wrote: > This means we still get to use 'make', we still get to use the .cabal > files as metadata, but the build system is more private to GHC, more > extensible, and hopefully more understandable and modifiable. This is essentially the same approach that nhc98 currently takes to building libraries. The Cabal file holds all the metadata, but the build system is Makefile-driven. There is a small separate tool (CabalParse) that extracts metadata from the cabal file. The Cabal *library* could be used to implement that extraction tool, but currently ours is hand-rolled. (One of the benefits of open specifications of file formats is that you can have multiple implementations for different purposes.) Here is an example of how it works: CABALFILE = $(shell ls *.cabal | head -n 1 ) READ = $(CABALPARSE) $(CABALFILE) -quiet MAP= $(LOCAL)map THISPKG= $(shell $(READ) name | cut -c2- ) VERSION= $(shell $(READ) version) SEARCH = $(shell $(READ) build-depends | $(MAP) "echo -package" ) \ $(shell $(READ) include-dirs | $(MAP) "echo -i" | cut -c1,2,4-) \ $(shell $(READ) hs-source-dir | $(MAP) "echo -I" | cut -c1,2,4-) \ $(shell $(READ) hs-source-dirs | $(MAP) "echo -I" | cut -c1,2,4-) CINCLUDES = $(shell $(READ) include-dirs | $(MAP) "echo -I" | cut -c1,2,4-) SRCS = $(shell $(READ) -slash exposed-modules) EXTRA_SRCS = $(shell $(READ) -slash other-modules) SRCS_C = $(shell $(READ) c-sources) DIRS = $(shell $(READ) -slash exposed-modules other-modules \ | $(MAP) dirname | sort | uniq ) EXTRA_C_FLAGS = $(shell $(READ) cc-options) EXTRA_H_FLAGS = $(shell $(READ) nhc98-options) 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: Version control systems
I seriously hope the plan is to move all *core* libraries (including GHC's cabal repo) etc over to git, too. * one build system * one vcs This is a chance to make a big step towards accessibility, let's make that step. Ultimately, I don't think git would make ghc any more accessible to new contributors. Darcs is not especially offputting to any beginner who already knows something about VCS in general. What the move to git is about, is making life easier for the *existing* HQ and core contributors. Evaluate it on that basis, and not in terms of unknown (and unknowable) benefits to current non- contributors. Indeed, you should also consider how many contributors you might lose in a move. I do hear some significant current contributors having doubts. I can certainly appreciate that having to run 2 VCS in parallel might be confusing and simply make matters worse than at present. The libraries question is a difficult one. We have made a lot of effort over the last 5 years to build infrastructure and code that is shared and portable across multiple implementations of the language. Is this the time to fork those supposedly "common" core libraries into ghc versions vs the rest? As someone who is not a contributor to GHC, and has never experienced anything more than trivial problems with darcs, I have not felt qualified to comment on the proposal to change GHC's VCS. But as a frequent fixer of breakage in the core libraries, I would be reluctant to have to move to a different VCS there. If the core libraries do move, it will be increasingly difficult to avoid also needing to move nhc98 and Hugs and goodness-knows how many other libraries. For me, it would be un-forced, annoying, and I may not have the extra time available to keep up. So there is a danger that the community will be left with a single (albeit very high quality) compiler, with no need for a Haskell Prime (or any other Standard) in future. If there are technical solutions that can reduce the pain, whilst keeping multiple stake-holders happy, then I think they should be investigated. 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]> 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: 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]> 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: scripts on unix
Sven Panne <[EMAIL PROTECTED]> wrote: > And 'runhs' is actually not a very good name to run nhc98, > runnhc or runnhc98 would be much better IMHO. Well, I chose 'runhs', because it can equally well invoke ghc, hbc, yhc nhc98, or whatever. It is an extension of hmake, which is compiler-independent. You can configure which compiler get invoked by fiddling with your hmake-config options. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: scripts on unix
Frederik Eaton <[EMAIL PROTECTED]> wrote: > What is the proper technique for creating a Haskell script on a Unix > system? > > $ cat test > #!/usr/bin/env runhaskell > module Main where > main = do > putStrLn "hello world" If you install hmake, and change 'runhaskell' to runhs, it works. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org 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: 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: 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
Ross Paterson <[EMAIL PROTECTED]> wrote: > When I've used seq, it's to ensure that a function is strict in that > argument, and therefore has been evaluated before the function is > called. (If the language had unlifted types, I might have used those > instead). Beyond that, I don't care exactly when it was evaluated; it > might be long before, thanks to propagation of strictness information. When I use `seq`, it is sometimes in a construction like unsafePerformIO (emit "squawk!) `seq` x where I am trying to force the impure side-effect to happen, exactly and immediately before x is evaluated. Whilst this is not good style in a general sense, I argue that it is perfectly safe inside certain kinds of library (e.g. for calculating coverage information, or for emitting tracing information). But if the language itself cannot guarantee this exact placement of side-effects, then it becomes impossible to write computation-reflective tools like Hat and hpc for Haskell, in Haskell. That would surely be a sad state of affairs. 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 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: Build failures in packages built with GHC 6.6
> Over the weekend Lennart Kolmodin tested all of Gentoo's Haskell > packages with the latest GHC 6.6 RC snapshot. Here is his report of > what failed, and how: Thanks for the useful heads-up - a very valuable service. To fix HaXml to work with ghc-6.6, I have pushed two new versions: 1.17 is the development branch, and 1.13.2 is the stable branch. 1.13.2: http://www.haskell.org/HaXml 1.17:http://www.cs.york.ac.uk/fp/HaXml-devel Hopefully this will enable some other packages to build now as well. I note hmake's failure, and have pushed a possible fix to the darcs repo, but will not make a release until I have tested it more thoroughly. 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: 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: Data.FiniteMap
Duncan Coutts <[EMAIL PROTECTED]> wrote: > Is it too late to ask that Data.FiniteMap not die just yet? FWIW, I'm in favour of retaining Data.FiniteMap for ghc-6.6, to be removed only in 6.8. > There are a number of progs/libs that this affects. It's not that > people do not want to use the new Data.Map, but people are worried > about having to drop support for earlier compilers. I'll add my support to this argument. > I think there is a wrapper somewhere that provides the old > Data.FiniteMap in terms of the Data.Map implementation. Darcs patch attached, if it is of interest. Regards, Malcolm 20060904134021-6871e-359d97db8563acc3a2868666494b8f52a9c3a7f1.gz Description: Binary data ___ 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]'
Duncan Coutts <[EMAIL PROTECTED]> wrote: > We have a reformulation of hylo fusion which we use for the > Data.ByteString library. That would cover lists too (and would make it > easy to fuse conversions String<->ByteString). > > I forget, does hylo fusion cover (++) efficiently? For our system it > works but is slower than we'd like. Well, there is a fairly straightforward RULE for (++) which essentially discovers the listy-ness of both arguments simultaneously, and deforests them together. xs ++ ys = foldr (:) ys xs RULES foldr f z (foldr (:) (foldr (:) [] s0) s1) = foldr f (foldr f z s0) s1 However this is not ideal, since it only deals well with a single (++), not a chain of them. But there is a separate set of RULES for deforesting concat/concatMap, especially as used in list comprehensions. It is relatively easy to convert a chain of (++)s to a single application of concat. I am still working on the details of the formulation of concatMap as a hylo-like structure, so no performance results yet. I hope to get it all finished and written up within a few weeks. 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? 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: 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: Lookup module and package defining <?
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
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: 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
RULES pragmas
I have a question about {-# RULES #-} pragmas. Here is a very simple attempt to use them: module Simplest where {-# RULES "simplestRule" forall x. id (id x) = x #-} myDefn = id (id 42) I want to verify whether ghc-6.4.1 does actually fire this rule, but have so far been unable to do so. According to the manual (section 7.10.5), the flag -ddump-rules should list "simplestRule" if it has been parsed correctly, and -ddump-simpl-stats should list the number of times it has fired. But it does not appear in either listing. Reasoning that I have the syntax wrong, I have tried numerous variations on the indentation, added type signatures, etc., all to no avail. 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? 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