Re: Reconsidering -Wall and -Wcompat

[Manuel M T Chakravarty]

Just as one data point, the Swift compiler is by default showing warnings about 
upcoming changes. Just like deprecation warnings, I do find that helpful. Based 
on that experience, including -Wcompat in -Wall seems like a good plan to me.

Manuel

> Ben Gamari :
> 
> tl;dr. GHC has a new set of warnings, -Wcompat, intended to give users
>   advance notice of coming library changes. We want to know whether
>   you think this set should be included in -Wall. See the Wiki [4]
>   and voice your opinion via the linked poll.
> 
> 
> Hello everyone,
> 
> GHC 8.0.1 will include a new warning group, -Wcompat, which arose out of
> the MonadFail proposal discussion [1] late last year. This warning set
> is intended to provide a means of informing users of coming changes in
> GHC's core libraries.
> 
> We would like to solicit the community's feedback on whether this new
> flag set should be implied by -Wall.
> 
> This proposal is motivated by concern expressed by some that -Wcompat
> would see little usage unless it is placed in one of the warning sets
> typically used during development. One such set is -Wall, which enables
> a generous fraction of GHC's warning collectionand is is intended [2]
> for use during development.
> 
> Unfortunately, despite the (albeit only recently stated) intent of
> flag, -Wall is widely used outside of development [3], often with the
> expectation that the result be warning-clean across multiple GHC
> versions. While we hope that -Wall will see less use in this context in
> the future, given its current role we wouldn't want to add options to it
> that would cause undue burden for users.
> 
> So, we are asking for your opinion: should -Wcompat be implied by -Wall?
> You can find a more thorough description of the precise proposal on the
> GHC Wiki [4]. It would be very much appreciated if you could take a few
> minutes familiarize yourself with the options and provide your thoughts
> via this quick poll,
> 
>
> https://docs.google.com/forms/d/1BmIQvhHcnDB79LgBvaWl_xXpS1q0dMHe3Gq9JeU9odM/viewform
> 
> Feel free to discuss the issue further in this thread.
> 
> Thank you for sharing,
> 
> - Ben
> 
> 
> 
> [1] https://mail.haskell.org/pipermail/ghc-devs/2015-October/010101.html
> 
> [2] https://mail.haskell.org/pipermail/ghc-devs/2016-January/010955.html
> 
> [3] In a rather unscientific study, nearly half of packages on Hackage
>include it in ghc-options,
> 
>$ tar -xf ~/.cabal/packages/00-INDEX.tar
>$ (for pkg in $(ls); do ls $pkg/*/*.cabal | sort -r | head -n1; done) 
> | xargs grep -L '\-Wall' | wc -l
>4352
>$ ls | wc -l 
>9347
>   
> [4] https://ghc.haskell.org/trac/ghc/wiki/Design/Warnings/Wcompat
> ___
> ghc-devs mailing list
> ghc-d...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Associated type instances

[Manuel M T Chakravarty]

Simon,

I’m not sure when this ”feature” was added, but I’m pretty sure that my 
original implementation of associated types was exactly what you describe in 
the solution. Or did I miss anything?

Manuel

Simon Peyton Jones simo...@microsoft.com:
 Friends
 
 I want to make withdraw (or, rather, simplify) a little-known feature in GHC, 
 but before I do so I want to check that no one is going to have a heart 
 attack.
 
 Relevant bits of the user manual: 
 http://www.haskell.org/ghc/docs/latest/html/users_guide/type-families.html#assoc-decl
 
 All of this arose when thinking about fixing Trac #9063.
 
 I believe that this change will affect essentially nobody, and I propose to 
 implement forthwith in HEAD (and hence 7.10). 
 
 Does anyone object?
 
 Thanks
 
 Simon
 
  
 
 The issue
 
 Consider this:
 
 class C a where
type T a b :: *
  
 instance C [x] where
type T [x] b = x - b
 That is just what you’d expect.  But currently this is allowed too:
 
 instance C [x] where
type T [x] Int = x - Int
type T [x] Bool = Bool - x
 That is, GHC 7.8 allows many associated type instances, provided they don’t 
 overlap.  But, oddly you can’t further instantiate the instance pattern. This 
 would make just as much sense, but isn’t allowed:
 
 instance C [x] where
type T [Int] b = b - Int
type T [Bool] b = Bool - b
 Moreover, as the user manual says, for an open kind like *, none of this 
 really makes sense. It really only makes sense for a closed kind. Something 
 like
 
 class D a where
type S (b :: Bool) a :: *
 Now this would make some kind of sense:
 
 instance D [x] where
type S True [x] = x - x
type S False [x] = x
 But for closed kinds, you really want a closed type family.  So this would be 
 better:
 
 instance D [x] where
type S b [x] = SHelp x b
  
 type family SHelp x b where
   SHelp x True = x - x
   SHelp x False = x
  
 So yes, you do have to declare a named helper type, but you get something 
 much more perspicuous and explicit in exchange.
 
 All of this also applies to the default declaration(s) which you can supply 
 for an associated type (see 7.7.3.2 in the link above), only it’s a bit more 
 complicated and indirect.
 
 My solution
 
 I propose to simplify substantially, as follows:
 
 · The “shared arguments” of an associated type are the argument 
 positions that mention a type variable from the class header.  So in class C 
 above, the first argument position of T is “shared”; and in class D, the 
 second argument position of S is shared.
 
 · A instance for an associated type (in a class instance declaration) 
 cf 7.7.3.1 must have
 
 o   type variables in the non-shared argument positions, and
 
 o   an exact copy of the corresponding instance header type in the shared 
 positions
 
 · For each associated type you can have
 
 o   at most one default declaration in the class declaration
 
 o   at most one type instance declaration in the class instance declaration
 
  
 
  
 
 ___
 ghc-devs mailing list
 ghc-d...@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC 7.8.3 release

[Manuel M T Chakravarty]

I believe #9078 affects all EDSLs that use Andy Gill’s stable name method to 
implement observable sharing. It certainly crashes Accelerate.

I would very much appreciate if 7.8.3 would be released in time to make it into 
the upcoming Haskell Platform. (If the platform would ship with 7.8.2., that 
would be a quite bad for all affected EDSL libraries.)

Do we know the projected release date for the platform?

Manuel

PS: For Accelerate, the situation is actually rather awkward right now. Due to 
the changes re ambiguous signatures in GHC 7.8, Accelerate needs to introduce a 
breaking API change to compile with 7.8. However, we can’t really fully 
transition to 7.8 until #9078 is fixed.

Austin Seipp aus...@well-typed.com:
 Hello all,
 
 After a long week, I've finally gotten a little time to reply to
 emails, and I mainly have one question I'd like to ask.
 
 First, please direct your attention to this:
 
 https://ghc.haskell.org/trac/ghc/query?status=closedstatus=mergestatus=patchmilestone=7.8.3group=resolutioncol=idcol=summarycol=ownercol=typecol=prioritycol=componentcol=versionorder=priority
 
 This is the 7.8.3 milestone, but it only considers things that are:
 
 - 1) Fixed
 - 2) Going to be merged
 - 3) Are a patch to be still merged.
 
 That is, it is a solid representation of the difference between 7.8.2
 and the 7.8 branch tip.
 
 The question is: when should we do the release? There are several bugs
 there that seem quite problematic for users - #9045, #7097, #9001,
 #8768 and #9078 in particular.
 
 If these bugs are really problematic (and I sort of feel they are)
 then the release can happen soon. I can do it within a week from now,
 and we could punt more to a 7.8.4 release.
 
 I ask this because my time to dedicate to GHC is a bit thin right now,
 so you must help me decide what's important! So please let me know -
 just a general vote in favor of doing it within some X timeframe (even
 'real soon' or 'a week would be great') would be nice.
 
 PS: I apologize for the lack of status updates and brief email - my
 time for GHC has been in very short order the past two weeks in
 particular, and I've finally just returned to a computer (not mine)
 for right now to ask this.
 
 PPS: This might also impact the 7.10 schedule, but last Simon and I
 talked, we thought perhaps shooting for ICFP this time (and actually
 hitting it) was a good plan. So I'd estimate on that a 7.8.4 might
 happen a few months from now, after summer.
 
 -- 
 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: GHC 7.8 release?

[Manuel M T Chakravarty]

Simon Peyton-Jones simo...@microsoft.com:
 |   You may ask what use is a GHC release that doesn't cause a wave of 
 updates?
 |  And hence that doesn't work with at least some libraries.  Well, it's a 
 very useful
 |  forcing function to get new features actually out and tested.
 |  
 |  But the way you test new features is to write programs that use them,
 |  and programs depend on libraries.
 
 That is of course ideal, but the ideal carries costs.  A half way house is a 
 release whose library support will be patchy.  Not such good testing, but 
 much lower costs.  But still (I think) a lot more testing than compile HEAD 
 gives us.

I don't think so. In my experience, library support is not patchy, but 
virtually non-existent as some of the very widely used libraries (like Text) 
break, and everything else depends on them in one way or another.

If we don't make sure that the commonly used libraries work with these 
preview releases, I don't think those releases are worth the effort.

I understand that we can't really guarantee API backwards compatibility for the 
GHC API (but that's ok as few packages depend on that). Critical are all the 
libraries bundled with GHC. Adding to them is fine, but no API definitions 
should change or be removed.

Manuel


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC 7.8 release?

[Manuel M T Chakravarty]

Simon Peyton-Jones simo...@microsoft.com:
 If there's a path to having a release strategy as Manuel suggests, and having 
 an intermediate release  with the new vector primops, type extensions and 
 such goodness, then I'm all for it.  A lot of these bits are things ill start 
 using almost immediately in production / real software, esp if I'm not 
 needing to patch every stable library beyond maybe relaxing versioning 
 constraints.
 
 Let me suggest once more a possible path, along the lines you suggest
 ·For people who value stability: use the Haskell Platform.  Ignore 
 GHC releases.
 ·For people who want as many features as possible: use GHC releases.
 ·For people who want to live on the bleeding edge: build HEAD from 
 source
  
 The Haskell Platform decides which GHC release to use, advertises that to 
 package authors who do whatever updates are needed.  HP may perfectly 
 sensibly skip an entire release entirely.
  
 In short, I think we already have the situation that you desire.  Perhaps we 
 just need to market it better? 
  
 Or am I mistaken?

There is one kink: for GHC releases to be *useful* substitutes for the HP for 
people who want medium stability, they must not change (expect maybe add to) 
the APIs in GHC versions that do not coincide with HP releases. 

Why? If they change APIs, many of the packages on Hackage will not build with 
these intermediate GHC releases, which makes them useless for anything, but 
testing GHC.

Otherwise, I am perfectly happy with your suggestion. However, this is not the 
status quo. All (major) GHC releases do break critical packages on Hackage.

Manuel


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC 7.8 release?

[Manuel M T Chakravarty]

Simon Marlow marlo...@gmail.com:
 I agree too - I think it would be great to have non-API-breaking releases 
 with new features.  So let's think about how that could work.
 
 Some features add APIs, e.g. SIMD adds new primops.  So we have to define 
 non-API-breaking as a minor version bump in the PVP sense; that is, you can 
 add to an API but not change it.
 
 As a straw man, let's suppose we want to do annual API releases in September, 
 with intermediate non-API releases in February.  Both would be classed as 
 major, and bump the GHC major version, but the Feb releases would only be 
 allowed to bump minor versions of packages. (except perhaps the version of 
 the GHC package, which is impossible to keep stable if we change the 
 compiler).
 
 So how to manage the repos.  We could have three branches, but that doesn't 
 seem practical.  Probably the best way forward is to develop new features on 
 separate branches and merge them into master at the appropriate time - i.e. 
 API-breaking feature branches could only be merged in after the Feb release.
 
 Thoughts?

That sounds sensible to me. 

Related to this, then, is the management of branches, which, I think, we can 
improve in two ways:

(1) Make all library packages into submodules.
(2) Fork-instead-of-branch and use GitHub pull requests.

Re (1): submodules make tracking of synchronised branches across multiple repos 
simpler. Yes, they also have their pitfalls, but given that we are already 
using submodules extensively, we need to deal with those pitfalls anyway. So, 
why not reap the benefits, too?

Re (2): we should encourage contributors to fork the GHC repos on GitHub and 
work in those. That makes it easy for everybody to build forks (which will be 
longer-lived under the above policy) and creating a fork doesn't require any 
special privileges in GHC repos. Finally, we can use GitHub pull requests to 
track contributions that are pending integration. This is IMHO also much nicer 
than attaching patches at Trac tickets.

Manuel

 On 09/02/13 02:04, Manuel M T Chakravarty wrote:
 I completely agree with Johan. The problem is to change core APIs too
 fast. Adding, say, SIMD instructions or having a new type extension
 (that needs to be explicitly activated with a -X option) shouldn't break
 packages.
 
 I'm all for restricting major API changes to once a year, but why can't
 we have multiple updates to the code generator per year or generally
 release that don't affect a large number of packages on Hackage?
 
 Manuel
 
 Johan Tibell johan.tib...@gmail.com mailto:johan.tib...@gmail.com:
 On Fri, Feb 8, 2013 at 6:28 AM, Simon Marlow marlo...@gmail.com
 mailto:marlo...@gmail.com wrote:
 
For a while we've been doing one major release per year, and 1-2
minor releases.  We have a big sign at the top of the download
page directing people to the platform.  We arrived here after
various discussions in the past - there were always a group of
people that wanted stability, and a roughly equally vocal group of
people who wanted the latest bits.  So we settled on one
API-breaking change per year as a compromise.
 
Since then, the number of packages has ballooned, and there's a
new factor in the equation: the cost to the ecosystem of an
API-breaking release of GHC.  All that updating of packages
collectively costs the community a lot of time, for little
benefit.  Lots of package updates contributes to Cabal Hell.  The
package updates need to happen before the platform picks up the
GHC release, so that when it goes into the platform, the packages
are ready.
 
So I think, if anything, there's pressure to have fewer major
releases of GHC.  However, we're doing the opposite: 7.0 to 7.2
was 10 months, 7.2 to 7.4 was 6 months, 7.4 to 7.6 was 7 months.
We're getting too efficient at making releases!
 
 
 I think we want to decouple GHC major releases (as in, we did lots
 of work) from API breaking releases. For example, GCC has lots of
 major (or big) releases, but rarely, if ever, break programs.
 
 I'd be delighted to see a release once in a while that made my
 programs faster/smaller/buggy without breaking any of them.
 
 -- Johan
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 parallel-haskell group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to parallel-haskell+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.
 
 


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC 7.8 release?

[Manuel M T Chakravarty]

I completely agree with Johan. The problem is to change core APIs too fast. 
Adding, say, SIMD instructions or having a new type extension (that needs to be 
explicitly activated with a -X option) shouldn't break packages.

I'm all for restricting major API changes to once a year, but why can't we have 
multiple updates to the code generator per year or generally release that don't 
affect a large number of packages on Hackage?

Manuel

Johan Tibell johan.tib...@gmail.com:
 On Fri, Feb 8, 2013 at 6:28 AM, Simon Marlow marlo...@gmail.com wrote:
 For a while we've been doing one major release per year, and 1-2 minor 
 releases.  We have a big sign at the top of the download page directing 
 people to the platform.  We arrived here after various discussions in the 
 past - there were always a group of people that wanted stability, and a 
 roughly equally vocal group of people who wanted the latest bits.  So we 
 settled on one API-breaking change per year as a compromise.
 
 Since then, the number of packages has ballooned, and there's a new factor in 
 the equation: the cost to the ecosystem of an API-breaking release of GHC.  
 All that updating of packages collectively costs the community a lot of time, 
 for little benefit.  Lots of package updates contributes to Cabal Hell.  The 
 package updates need to happen before the platform picks up the GHC release, 
 so that when it goes into the platform, the packages are ready.
 
 So I think, if anything, there's pressure to have fewer major releases of 
 GHC.  However, we're doing the opposite: 7.0 to 7.2 was 10 months, 7.2 to 7.4 
 was 6 months, 7.4 to 7.6 was 7 months.  We're getting too efficient at making 
 releases!
 
 I think we want to decouple GHC major releases (as in, we did lots of work) 
 from API breaking releases. For example, GCC has lots of major (or big) 
 releases, but rarely, if ever, break programs.
 
 I'd be delighted to see a release once in a while that made my programs 
 faster/smaller/buggy without breaking any of them.
 
 -- Johan

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Mailing list reorganisation

[Manuel M T Chakravarty]

Good plan!

Ian Lynagh i...@well-typed.com:
 Hi all,
 
 Following a recent discussion, we propose to reorganise the GHC-related
 mailing lists so that we end up with:
 
glasgow-haskell-users
For user discussions
 
ghc-devs
For developer discussions
 
ghc-commits
For automated commit messages from the git repositories
 
ghc-builds
For automated nightly build reports
 
ghc-tickets
For automated messages from trac
 
 We would remove
cvs-ghc cvs-libraries cvs-other glasgow-haskell-bugs
 but leave the archives in place, and for now forwarding messages to
 cvs-* to ghc-devs, and glasgow-haskell-bugs to ghc-tickets.
 (cvs-libraries and cvs-other are included in this list, because we think
 they are mainly used by libraries that GHC HQ maintains, or by GHC's
 lagging repos of libraries that other people maintain).
 
 The initial subscriber lists for ghc-devs, ghc-commits and ghc-builds
 would be the union of the subscribers of cvs-ghc, cvs-libraries and
 cvs-other. For ghc-tickets it would be the subscriber list for
 glasgow-haskell-bugs.
 
 Does that sound reasonable? Does anyone have any further questions or
 comments?
 
 
 Thanks
 Ian
 
 
 ___
 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: Dynamic libraries by default and GHC 7.8

[Manuel M T Chakravarty]

Simon Marlow marlo...@gmail.com:
 This has some advantages and some disadvantages, so we need to make a
 decision about what we want to do in GHC 7.8. There are also some policy
 questions we need to answer about how Cabal will work with a GHC that
 uses dynamic libraries by default. We would like to make these as soon
 as possible, so that GHC 7.6.2 can ship with a Cabal that works
 correctly.
 
 The various issues are described in a wiki page here:
 http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault
 
 Thanks for doing all the experiments and putting this page together, it
 certainly helps us to make a more informed decision.
 
 If you have a few minutes to read it then we'd be glad to hear your
 feedback, to help us in making our decisions
 
 My personal opinion is that we should switch to dynamic-by-default on all 
 x86_64 platforms, and OS X x86. The performance penalty for x86/Linux is too 
 high (30%), and there are fewer bugs affecting the linker on that platform 
 than OS X.
 
 I am slightly concerned about the GC overhead on x86_64/Linux (8%), but I 
 think the benefits outweigh the penalty there, and I can probably investigate 
 to find out where the overhead is coming from.

I agree with your opinion.

Firstly, correctness is more important than performance. (It's Haskell, after 
all.) Secondly, the RTS linker is an unnecessary time sink, and developer 
cycles are precious. Thirdly, when shipping production systems, people can 
always link statically to get best performance.

Manuel


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Comparing StableNames of different type

[Manuel M T Chakravarty]

Emil Axelsson e...@chalmers.se:
 2012-08-26 08:03, Manuel M T Chakravarty skrev:
 Emil Axelsson e...@chalmers.se:
 2012-08-24 11:08, Simon Marlow skrev:
 On 24/08/2012 07:39, Emil Axelsson wrote:
 Hi!
 
 Are there any dangers in comparing two StableNames of different type?
 
   stEq :: StableName a - StableName b - Bool
   stEq a b = a == (unsafeCoerce b)
 
 I could guard the coercion by first comparing the type representations,
 but that would give me a `Typeable` constraint that would spread
 throughout the code.
 It should be safe even if the types are
 different, but I presume you expect the types to be the same, since
 otherwise the comparison would be guaranteed to return False, right?
 
 No, I want to do observable sharing of heterogeneously typed expressions 
 which means I will be comparing expressions of different type.
 
 You may like to have a look at how we have done this in the Accelerate EDSL:
 
   
 https://github.com/AccelerateHS/accelerate/blob/master/Data/Array/Accelerate/Smart.hs
 
 In particular, the Eq instance for stable names of AST nodes is at
 
   
 https://github.com/AccelerateHS/accelerate/blob/master/Data/Array/Accelerate/Smart.hs#L763
 
 Hm, doesn't this impose a `Typeable` constraint on all AST nodes (which is 
 what I'm trying to avoid)?

Yes, you need Typeable, but arguably that is cleaner than unsafeCoerce.

In any case, as I am not aware of any other system than Accelerate that 
implements observable sharing on typed ASTs, you may find the Accelerate code 
to be a helpful source of inspiration.

Manuel


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Comparing StableNames of different type

[Manuel M T Chakravarty]

Emil Axelsson e...@chalmers.se:
 2012-08-24 11:08, Simon Marlow skrev:
 On 24/08/2012 07:39, Emil Axelsson wrote:
 Hi!
 
 Are there any dangers in comparing two StableNames of different type?
 
   stEq :: StableName a - StableName b - Bool
   stEq a b = a == (unsafeCoerce b)
 
 I could guard the coercion by first comparing the type representations,
 but that would give me a `Typeable` constraint that would spread
 throughout the code.
 It should be safe even if the types are
 different, but I presume you expect the types to be the same, since
 otherwise the comparison would be guaranteed to return False, right?
 
 No, I want to do observable sharing of heterogeneously typed expressions 
 which means I will be comparing expressions of different type.

You may like to have a look at how we have done this in the Accelerate EDSL:

  
https://github.com/AccelerateHS/accelerate/blob/master/Data/Array/Accelerate/Smart.hs

In particular, the Eq instance for stable names of AST nodes is at

  
https://github.com/AccelerateHS/accelerate/blob/master/Data/Array/Accelerate/Smart.hs#L763

You may be able to use our entire scheme. (We have started to write it up as a 
paper, but the write up isn't in a coherent state yet.)

Manuel


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GADTs in the wild

[Manuel M T Chakravarty]

Most academic papers do use the eval example, but it is a practical example. 
This use of GADTs is nice for embedded languages. For example, Accelerate uses 
a supercharged version of it to catch as many errors as possible during Haskell 
host program compile-time (as opposed to Accelerate compile time, which is 
Haskell runtime).

Manuel


Simon Peyton-Jones simo...@microsoft.com:
 Friends
 
 I’m giving a series of five lectures at the Laser Summer School (2-8 Sept), 
 on “Adventures with types in Haskell”.  My plan is:
 1.   Type classes
 2.   Type families [examples including Repa type tags]
 3.   GADTs
 4.   Kind polymorphism
 5.   System FC and deferred type errors
  
 This message is to invite you to send me your favourite example of using a 
 GADT to get the job done.  Ideally I’d like to use examples that are (a) 
 realistic, drawn from practice (b) compelling and (c) easy to present without 
 a lot of background.  Most academic papers only have rather limited examples, 
 usually eval :: Term t - t, but I know that GADTs are widely used in 
 practice.
  
 Any ideas from your experience, satisfying (a-c)?  If so, and you can spare 
 the time, do send me a short write-up. Copy the list, so that we can all 
 benefit.
  
 Many thanks
 
 Simon
 ___
 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: parallel garbage collection performance

[Manuel M T Chakravarty]

I wonder, do we have a Repa FAQ (or similar) that explain such issues? (And is 
easily discoverable?)

Manuel


Ben Lippmeier b...@ouroborus.net:
 On 19/06/2012, at 24:48 , Tyson Whitehead wrote:
 
 On June 18, 2012 04:20:51 John Lato wrote:
 Given this, can anyone suggest any likely causes of this issue, or
 anything I might want to look for?  Also, should I be concerned about
 the much larger gc_alloc_block_sync level for the slow run?  Does that
 indicate the allocator waiting to alloc a new block, or is it
 something else?  Am I on completely the wrong track?
 
 A total shot in the dark here, but wasn't there something about really bad 
 performance when you used all the CPUs on your machine under Linux?
 
 Presumably very tight coupling that is causing all the threads to stall 
 everytime the OS needs to do something or something?
 
 This can be a problem for data parallel computations (like in Repa). In Repa 
 all threads in the gang are supposed to run for the same time, but if one 
 gets swapped out by the OS then the whole gang is stalled.
 
 I tend to get best results using -N7 for an 8 core machine. 
 
 It is also important to enable thread affinity (with the -qa) flag. 
 
 For a Repa program on an 8 core machine I use +RTS -N7 -qa -qg
 
 Ben.
 
 
 
 ___
 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: parallel garbage collection performance

[Manuel M T Chakravarty]

Bryan O'Sullivan b...@serpentine.com:
 On Mon, Jun 18, 2012 at 9:32 PM, John Lato jwl...@gmail.com wrote:
 
 I had thought the last core parallel slowdown problem was fixed a
 while ago, but apparently not?
 
 Simon Marlow has thought so in the not too distant past (since he did the 
 work), if my recollection is correct.

It may very well be fixed for non-dataparallel programs. For dataparallel 
programs the situation is more tricky as we rely on all threads participating 
in a DP computation to be scheduled simultaneously. If one Core is currently 
tied up by the OS, then GHC's RTS can't do anything about that.  As it has no 
concept of gang scheduling (but treats the threads participating in a DP 
computation individually), it also doesn't know that scheduling a subset of the 
threads in the gang is counterproductive.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[ANN] Accelerate version 0.12: GPU computing with Haskell

[Manuel M T Chakravarty]

We just released version 0.12 of Data.Array.Accelerate, the GPGPU[1] library 
for Haskell:

  http://justtesting.org/gpu-accelerated-array-computations-in-haskell

This is a beta release. The library is not perfect, but it is definitely 
usable, and we are looking for early adopters.

Manuel

[1] Currently only NVIDIA GPUs are supported via NVIDIA's CUDA framework.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Fwd: GHC, Clang XCode 4.2

[Manuel M T Chakravarty]

I think, you meant to reply to the list and not just to me.

 Von: B. Scott Michel scooter@gmail.com
 Betreff: Re: GHC, Clang  XCode 4.2
 Datum: 15 October 2011 12:32:36 
 An: Manuel M T Chakravarty c...@cse.unsw.edu.au
 Antwort an: scooter@gmail.com
 
 Simon:
 
 What are the performance penalties, specifically? I ask because I might still 
 have commit privs to llvm from the errors of a misspent post-doc era, so 
 could probably help push a patch to llvm if needed.
 
 That said, though, FreeBSD moved to llvm because itKs not GPL and it 
 generates better code.
 
 -scooter
 Sent from my Verizon Wireless BlackBerry
 
 -Original Message-
 From: Manuel M T Chakravarty c...@cse.unsw.edu.au
 Sender: glasgow-haskell-users-boun...@haskell.org
 Date: Thu, 13 Oct 2011 13:11:40 
 To: Simon Marlowmarlo...@gmail.com
 Cc: GHC Users Mailing Listglasgow-haskell-users@haskell.org
 Subject: Re: GHC, Clang  XCode 4.2
 
 Just FYI, Xcode 4.2 is live in the Mac App Store now, and it has some nice 
 goodies (i.e., many who develop for iOS and probably also OS X will probably 
 adopt it soon).
 
 Manuel
 
 PS: Sorry for not having participated in the discussion on how to solve this, 
 but I have too many loose ends right now.
 
 
 Simon Marlow:
 On 11/10/2011 18:45, David Peixotto wrote:
 Ok, I have attached a set of patches to support building the GHC
 runtime with llvm-gcc. The patches are based off of commit
 29a97fded4010bd01aa0a17945c84258e285d421 which was last Friday's HEAD.
 These patches are also available from my github repository on the
 llvm-gcc branch at
 
   git://github.com/dmpots/ghc.git
 
 There are three patches:
 
 0001- Uses pthread_getspecific and pthread_setspecfic to
access gct when the `llvm_CC_FLAVOR` CPP macro is
set
 
 0002- Modifies the configure scripts to set the
`llvm_CC_FLAVOR` macro when compiling with an llvm
based compile (either llvm-gcc or clang)
 
 0003- Passes the gct variable as a parameter in the GC. This
change is parameterized with CPP macros so that it
is only in effect when compiling for an llvm-based
compiler.
 
 The patches 0001 and 0002 provide the minimal support needed to build
 GHC with llvm-gcc. The 0003 patch is there to limit the performance
 hit we get by going through pthread functions to access the gct. I
 think the 0001 and 0002 patches should not be very controversial, but
 the 0003 patch is a more invasive change and perhaps Simon Marlow will
 want to clean it up before it is applied.
 
 Thanks, I'll take a look at these soon.
 
 Just a thought, but someone might want to write a blog post about how 
 Apple's choice to move to llvm-gcc is imposing a performance penalty on us 
 here, and get it up on Reddit.  That would give the issue some publicity 
 (they love that sort of thing on Reddit), and might result in some action.  
 I'd be happy to proof read a blog post before publication.  Some simple 
 benchmarks would be needed - one option is to use GHC itself with the 
 various combinations of compilers + RTS changes, or there are a small set of 
 GC benchmarks in nofib/gc.
 
 Cheers,
  Simon
 
 
 
 I ran a validate with the patches, and found one additional failure
 when going through an llvm-based compiler. There were no additional
 failures when using a gcc compiler even with my patches applied. The
 additional failure is the cgrun071 test which tests the popCnt
 primitives. I'm going to look into why that test fails, but I think
 the patches should be safe to apply as it would only show up when
 compiling with llvm-gcc, which is currently impossible without these
 patches.
 
 -David
 
 
 
 
 
 
 On Oct 7, 2011, at 10:30 AM, David Peixotto wrote:
 
 
 On Oct 6, 2011, at 7:32 AM, Simon Marlow wrote:
 
 On 05/10/2011 09:46, austin seipp wrote:
 There has been recent discussion on the Homebrew bug tracker
 concerning the upcoming XCode 4.2 release by Apple, which has
 apparently just gone GM (meaning they're going to make a real release
 on the app store Real Soon Now.)
 
 The primary concern is that XCode will no longer ship GCC 4.2 at all,
 it seems. XCode 4.0   4.1 merely set 'llvm-gcc' as the default
 compiler, and GHC's `configure` script was adjusted to find the
 `gcc-4.2` binary. If you have old XCode's installed, then you may have
 the binaries laying around, but I doubt they'll be on your $PATH, and
 anybody doing a fresh install is SOL.
 
 It seems Clang 3.0 will now be the default compiler, with llvm-gcc as
 a deprecated option, probably removed in XCode 4.3. It doesn't matter
 really, because both of them do not work with GHC, because of its use
 of either A) Global register variables of any kind, or B) the __thread
 storage modifier.
 
 David Peixotto did some work on this not too long ago as the issue of
 compiling with Clang was raised. His branches include changes which
 make the 'gct' variable use

Re: GHC, Clang XCode 4.2

[Manuel M T Chakravarty]

Just FYI, Xcode 4.2 is live in the Mac App Store now, and it has some nice 
goodies (i.e., many who develop for iOS and probably also OS X will probably 
adopt it soon).

Manuel

PS: Sorry for not having participated in the discussion on how to solve this, 
but I have too many loose ends right now.


Simon Marlow:
 On 11/10/2011 18:45, David Peixotto wrote:
 Ok, I have attached a set of patches to support building the GHC
 runtime with llvm-gcc. The patches are based off of commit
 29a97fded4010bd01aa0a17945c84258e285d421 which was last Friday's HEAD.
 These patches are also available from my github repository on the
 llvm-gcc branch at
 
git://github.com/dmpots/ghc.git
 
 There are three patches:
 
  0001- Uses pthread_getspecific and pthread_setspecfic to
 access gct when the `llvm_CC_FLAVOR` CPP macro is
 set
 
  0002- Modifies the configure scripts to set the
 `llvm_CC_FLAVOR` macro when compiling with an llvm
 based compile (either llvm-gcc or clang)
 
  0003- Passes the gct variable as a parameter in the GC. This
 change is parameterized with CPP macros so that it
 is only in effect when compiling for an llvm-based
 compiler.
 
 The patches 0001 and 0002 provide the minimal support needed to build
 GHC with llvm-gcc. The 0003 patch is there to limit the performance
 hit we get by going through pthread functions to access the gct. I
 think the 0001 and 0002 patches should not be very controversial, but
 the 0003 patch is a more invasive change and perhaps Simon Marlow will
 want to clean it up before it is applied.
 
 Thanks, I'll take a look at these soon.
 
 Just a thought, but someone might want to write a blog post about how Apple's 
 choice to move to llvm-gcc is imposing a performance penalty on us here, and 
 get it up on Reddit.  That would give the issue some publicity (they love 
 that sort of thing on Reddit), and might result in some action.  I'd be happy 
 to proof read a blog post before publication.  Some simple benchmarks would 
 be needed - one option is to use GHC itself with the various combinations of 
 compilers + RTS changes, or there are a small set of GC benchmarks in 
 nofib/gc.
 
 Cheers,
   Simon
 
 
 
 I ran a validate with the patches, and found one additional failure
 when going through an llvm-based compiler. There were no additional
 failures when using a gcc compiler even with my patches applied. The
 additional failure is the cgrun071 test which tests the popCnt
 primitives. I'm going to look into why that test fails, but I think
 the patches should be safe to apply as it would only show up when
 compiling with llvm-gcc, which is currently impossible without these
 patches.
 
 -David
 
 
 
 
 
 
 On Oct 7, 2011, at 10:30 AM, David Peixotto wrote:
 
 
 On Oct 6, 2011, at 7:32 AM, Simon Marlow wrote:
 
 On 05/10/2011 09:46, austin seipp wrote:
 There has been recent discussion on the Homebrew bug tracker
 concerning the upcoming XCode 4.2 release by Apple, which has
 apparently just gone GM (meaning they're going to make a real release
 on the app store Real Soon Now.)
 
 The primary concern is that XCode will no longer ship GCC 4.2 at all,
 it seems. XCode 4.0   4.1 merely set 'llvm-gcc' as the default
 compiler, and GHC's `configure` script was adjusted to find the
 `gcc-4.2` binary. If you have old XCode's installed, then you may have
 the binaries laying around, but I doubt they'll be on your $PATH, and
 anybody doing a fresh install is SOL.
 
 It seems Clang 3.0 will now be the default compiler, with llvm-gcc as
 a deprecated option, probably removed in XCode 4.3. It doesn't matter
 really, because both of them do not work with GHC, because of its use
 of either A) Global register variables of any kind, or B) the __thread
 storage modifier.
 
 David Peixotto did some work on this not too long ago as the issue of
 compiling with Clang was raised. His branches include changes which
 make the 'gct' variable use pthread_getspecific rather than __thread
 for TLS and then as an optimization use inline ASM to grab the value
 out of the variable, with an impact of about 9% it seems, but that's
 on nofib and I don't know if it was -threaded. He also included a
 version which passes the 'gct' around as a parameter to all GCC
 functions which is a bit uglier but may give some better performance I
 guess. (The discussion is from here IIRC.) I suppose the real perf
 killer here is probably -threaded code.
 
 https://github.com/dmpots/ghc
 
 Was there ever any decision on which route to take for this issue? The
 parameter passing solution looks quite uglier IMO but it may be
 necessary for performance.
 
 I'm happy to incorporate the parameter-passing changes if necessary.  I 
 think it should only be important in the inner loop of the GC 
 (scavenge_block/evacuate and the functions called from there).  If someone 
 sends me a working patch, I 

Re: Two Proposals

[Manuel M T Chakravarty]

Roman Leshchinskiy:
 Simon Peyton-Jones wrote:
 
 I'm not sure if this plan would support [(fred,45), (bill,22)] :: Map
 String Int.  Probably not.   Maybe that's a shortcoming... but such Maps
 are a rather surprising use of list literals.
 
 What data structures other than lists do we want to construct using list
 literals? I'm not really sure what the use cases are.

Parallel arrays! (I want to get rid of our custom syntax.)

Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Two Proposals

[Manuel M T Chakravarty]

Roman Leshchinskiy:
 Manuel M T Chakravarty wrote:
 Roman Leshchinskiy:
 
 What data structures other than lists do we want to construct using list
 literals? I'm not really sure what the use cases are.
 
 Parallel arrays! (I want to get rid of our custom syntax.)
 
 Why? Don't you think it is useful to have a visual indication of which
 data structure you are using and what is going to be evaluated in
 parallel?

Whether a computation is parallel depends on the type.  That is still the case.

In Haskell, it is usually hard to reason about performance without a good 
understanding of the involved types and their representation.  Syntax alone is 
usually not very helpful.  I think it is fine if that is the same for data 
parallelism.

 In any case, if we want to get rid of the parallel array syntax, we have
 to overload list literals, enumerations and list comprehensions. We have
 the generic monadic desugaring for the latter but recovering an efficient
 DPH program from that sn't trivial.

At ICFP, George suggested that we might use RULES to transform the patterns of 
generic monadic desugaring into the form that we need for parallel arrays.  We 
need to check whether that really works out, of course.

Manuel


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC version 7.2.1

[Manuel M T Chakravarty]

At the request of the Haskell Platform folks, we are shipping the Data Parallel 
Haskell libraries separately from GHC (i.e., they are not bundled in the GHC 
distribution, nor will they be bundled in any Haskell Platform distribution).  
To use DPH with GHC 7.2.1, you need to install the DPH libraries separately 
from Hackage — for details, see

  http://pls.posterous.com/data-parallel-haskell-and-repa-for-ghc-721

Manuel

Ian Lynagh:
 
   =
The (Interactive) Glasgow Haskell Compiler -- version 7.2.1
   =
 
 The GHC Team is pleased to announce a new major release of GHC, 7.2.1.
 
 The 7.2 branch is intended to be more of a technology preview than
 normal GHC stable branches; in particular, it supports a significantly
 improved version of DPH, as well as new features such as compiler
 plugins and safe Haskell. The design of these new features may evolve
 as we get more experience with them. See the release notes for more
 details of what's new and what's changed.
 
 We are also using this branch as an opportunity to work out the best
 workflows to use with git.
 
 We expect the 7.2 branch to be short-lived, with 7.4.1 coming out
 shortly after ICFP as normal.
 
 
 Full release notes are here:
 
  http://www.haskell.org/ghc/docs/7.2.1/html/users_guide/release-7-2-1.html
 
 How to get it
 ~
 
 The easy way is to go to the web page, which should be self-explanatory:
 
http://www.haskell.org/ghc/
 
 We supply binary builds in the native package format for many
 platforms, and the source distribution is available from the same
 place.
 
 Packages will appear as they are built - if the package for your
 system isn't available yet, please try again later.
 
 
 Background
 ~~
 
 Haskell is a standard lazy functional programming language.
 
 GHC is a state-of-the-art programming suite for Haskell.  Included is
 an optimising compiler generating good code for a variety of
 platforms, together with an interactive system for convenient, quick
 development.  The distribution includes space and time profiling
 facilities, a large collection of libraries, and support for various
 language extensions, including concurrency, exceptions, and foreign
 language interfaces (C, whatever).  GHC is distributed under a
 BSD-style open source license.
 
 A wide variety of Haskell related resources (tutorials, libraries,
 specifications, documentation, compilers, interpreters, references,
 contact information, links to research groups) are available from the
 Haskell home page (see below).
 
 
 On-line GHC-related resources
 ~~
 
 Relevant URLs on the World-Wide Web:
 
 GHC home page  http://www.haskell.org/ghc/
 GHC developers' home page  http://hackage.haskell.org/trac/ghc/
 Haskell home page  http://www.haskell.org/
 
 
 Supported Platforms
 ~~~
 
 The list of platforms we support, and the people responsible for them,
 is here:
 
   http://hackage.haskell.org/trac/ghc/wiki/Contributors
 
 Ports to other platforms are possible with varying degrees of
 difficulty.  The Building Guide describes how to go about porting to a
 new platform:
 
http://hackage.haskell.org/trac/ghc/wiki/Building
 
 
 Developers
 ~~
 
 We welcome new contributors.  Instructions on accessing our source
 code repository, and getting started with hacking on GHC, are
 available from the GHC's developer's site run by Trac:
 
  http://hackage.haskell.org/trac/ghc/
 
 
 Mailing lists
 ~
 
 We run mailing lists for GHC users and bug reports; to subscribe, use
 the web interfaces at
 
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
 
 There are several other haskell and ghc-related mailing lists on
 www.haskell.org; for the full list, see
 
http://www.haskell.org/mailman/listinfo/
 
 Some GHC developers hang out on #haskell on IRC, too:
 
http://www.haskell.org/haskellwiki/IRC_channel
 
 Please report bugs using our bug tracking system.  Instructions on
 reporting bugs can be found here:
 
http://www.haskell.org/ghc/reportabug
 
 
 ___
 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: ANNOUNCE: GHC 7.2.1 Release Candidate 1

[Manuel M T Chakravarty]

Ian Lynagh:
 On Sat, Jul 30, 2011 at 10:57:40PM +1000, Manuel M T Chakravarty wrote:
 
 The RC unfortunately doesn't build on Lion (OS X 10.7).
 
 I've put the latest 7.2 source here, along with OS X builds:
http://www.haskell.org/ghc/dist/7.2.1-rc2/
 
 My guess is that the bindists will work on Lion, but that the installers
 will use the wrong gcc.

I tested the 64-bit bindists and compiled the source from scratch on Lion.  It 
all works.  You are right that the bindists use the default gcc (i.e., the one 
with the LLVM backend).  That is ok, though, as GHC supplies the stack 
unwinding linker option.

When compiling the source, the build system picks gcc-4.2 (as it should, 
otherwise the RTS wouldn't compile).

I still think that the bindists should use gcc-4.2 as well.  However, that's 
nothing that should hold up the 7.2.1 release.

Cheers,
Manuel
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 7.2.1 Release Candidate 1

[Manuel M T Chakravarty]

Ian Lynagh:
 On Mon, Aug 08, 2011 at 11:20:18PM +1000, Manuel M T Chakravarty wrote:
 Ian Lynagh:
 You are right that the bindists use the default gcc (i.e., the one with the 
 LLVM backend).  That is ok, though, as GHC supplies the stack unwinding 
 linker option.
 
 Do you really mean the bindists (i.e. the .tar.bz2 files), rather than
 the installers (.pkg)?

Yes, I mean the tar.bz2 file.  When I unpack it on Lion and run ./configure, 
configure picks '/usr/bin/gcc' and not '/usr/bin/gcc-4.2' as the C compiler.  
(I can force it to use gcc-4.2 with '--with-gcc=/usr/bin/gcc-4.2'.)

Manuel

P.S.: The .pkg package uses a bindist internally. (At least, that was how my 
original implementation of the packaging worked.)  So, the two should usually 
behave the same.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 7.2.1 Release Candidate 1

[Manuel M T Chakravarty]

Ian,

The RC unfortunately doesn't build on Lion (OS X 10.7).  It needs two patches I 
recently pushed to the master branch (and suggested to be merged into stable).  
They are the following patches:

  eb01af6ba964fe74375e461723b83597ef97155d (On OS X, use gcc-4.2 with Xcode 4 
and up)
  30ccc9f39dd2cf1ad14e6116778aa1fd94526c19 (On OS X x86_64, use -Wl,-no_pie 
and -Wl,-no_compact_unwind to avoid linker warnings)

Manuel


Ian Lynagh:
 
 We are pleased to announce the first release candidate for GHC 7.2.1:
 
http://www.haskell.org/ghc/dist/7.2.1-rc1/
 
 This includes the source and testsuite tarballs, installers for OS X and
 Windows, and bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and
 i386/FreeBSD.
 
 Please test as much as possible; bugs are much cheaper if we find them
 before the release!
 
 
 Thanks
 Ian, on behalf of the GHC team
 
 
 ___
 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: How to install GhC on a Mac without registering?

[Manuel M T Chakravarty]

malcolm.wallace:
 For use at high school level, I would imagine that you would want to build a 
 special distribution anyway. One that for example already includes packages, 
 such as Gloss, that would be useful in teaching children programming in 
 Haskell without they having to go through learning to use cabal (which is a 
 bigger hurdle than installing Xcode IMHO).
 
 But I wonder, would those students not use school equipment (which 
 supposedly would have all software pre-installed)? Do they bring their own 
 Macs? (I'd be surprised to find a whole class of 6th graders all owning 
 Macs...)
  
 
 As a further data point, yesterday one of my colleagues gave his 17-yr-old 
 daughter a copy of the Learn you a Haskell for Great Good book.  She 
 started to read it, and wanted to play with Haskell on her MacBook Air.  
 First step, download ghc.  Discover that it will not install on Leopard.  
 Step two: upgrade the operating system to Snow Leopard.  One hour later, 
 attempt to install ghc again.  Discover that it requires XCode.  Step three: 
 buy XCode from the mac App Store, and wait two hours for the 4Gb download 
 over a hotel wifi connection  Step four: hotel wifi access runs out before 
 the download is complete, so give up and go back to watching the movie she 
 downloaded earlier, but has not been able to watch whilst all this 
 downloading and upgrading has been happening.

That is a nice story, but it doesn't change what I wrote earlier:

* It would be nice to have a lightweight Haskell learner's distro (for your 
colleagues 17-yr-old daughter and others), preferably with libraries like a web 
framework, Gloss, etc included — an all in one package.

* The standard, production-ready Haskell distro shouldn't duplicate tools 
already provided by the platform vendor, especially not C compiler and 
libraries that quickly lead to subtly hard to find bugs in projects that use 
these tools also directly (and not just via GHC).

Manuel


___
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?

[Manuel M T Chakravarty]

Malcolm Wallace:
 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.

For use at high school level, I would imagine that you would want to build a 
special distribution anyway.  One that for example already includes packages, 
such as Gloss, that would be useful in teaching children programming in Haskell 
without they having to go through learning to use cabal (which is a bigger 
hurdle than installing Xcode IMHO).

But I wonder, would those students not use school equipment (which supposedly 
would have all software pre-installed)?  Do they bring their own Macs?  (I'd be 
surprised to find a whole class of 6th graders all owning Macs...)

 Having said that, I do think that Hugs (or maybe Helium) would be a more 
 appropriate environment for teaching the basics to young students.

That or a customised version of GHC with the right libraries pre-installed etc, 
and editor included, etc.

Manuel


___
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?

[Manuel M T Chakravarty]

Sean Leather:
 On Fri, Jun 10, 2011 at 03:15, Manuel M T Chakravarty wrote:
 Ian Lynagh:
  On Mon, Jun 06, 2011 at 03:47:57PM +0100, Malcolm Wallace wrote:
  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.)
 
  I'm pretty sure we aren't allowed to redistribute XCode.
 
  As well as gcc and friends, I think XCode also includes various headers
  and/or libraries that we need.
 
  If there is an alternative - especially one that allows us to support
  multiple versions of OS X more easily - then using it may make sense.
 
 You are right, the Xcode install includes many tools as well as headers etc.
 
 What would be the advantage of including gcc and all these other things in 
 GHC?
 
 To simplify the process of installing GHC and to support people with versions 
 of Mac OS X older than the most current. We want to spread the Haskell love 
 as far as possible.

The only simplification is that people who haven't got Xcode yet need to 
install two packages instead of just one.

However, for people who already have got Xcode installed, it means that they 
get two versions of all the dev tools, headers, etc.  Then, compiling a C file 
(eg, as part of a Haskell project) by directly invoking gcc or by compiling it 
via ghc will use different compilers, headers, etc.  That quickly leads to 
annoying and hard to debug problems.

Given that almost every developer on a Mac will be in the second group, you are 
not simplifying matters, you are complicating them.

 Anybody who is halfway serious about developing software on a Mac will have 
 Xcode installed anyway.
 
 You could say the same about people halfway serious about developing software 
 on Windows. But GHC doesn't require you to install MinGW, Cygwin, or Virtual 
 Studio.

No.  A serious Windows dev will have Visual Studio installed.  That won't help 
with installing GHC at all AND the GHC-bundled Unix tools do not interfere with 
Visual Studio in the same way that custom installs of Unix tools interfere with 
Xcode.

 Besides, as Xcode updates are now available from the Mac App Store,
 
 Not for older versions of Mac OS X.

Well, then get the DVDs bundled with your Mac and install Xcode from those, or 
sign up at developer.apple.com and get it there.   BTW, Mac users (and esp 
devs) upgrade very quickly, much faster than, say, Windows users.

 you don't even need to register as a developer with Apple anymore — yes, you 
 need to pay the nominal $5 for the 4GB download.  If you don't want to do 
 that, install the (probably older) version of Xcode that came with the 
 install DVDs of your Mac.
 
 This doesn't solve the problem if the GHC package only supports later 
 versions of Xcode. There has already been at least one difference between 
 Xcode 3 and 4 ( http://hackage.haskell.org/trac/ghc/ticket/5011 ) that caused 
 a problem and there may be others in the future.

That was arguably a bug in GHC's build setup.  It hardcoded a particular SDK 
version and died when Apple didn't ship that with the default install anymore.  
Nevertheless, new versions of Xcode will require adaptations in GHC, just like 
new gcc and GNU tool/lib versions require fixes in GHC on Linux.

Bundling doesn't solve that problem; it shifts it due to the mismatch of 
system-wide and GHC-installed compilers, tools, and libs.

 I don't think you can compare this with the situation on Windows.  Microsoft 
 does not distribute a canonical set of Unix tools that all developers use.
 
 No, but Cygwin and MinGW are available for free and have been around for a 
 long time. Why does GHC bundle MinGW instead of expecting the user to install 
 it herself? Convenience?

Again, this is a different situation.  Window's standard dev environment is 
Visual Studio, you cannot expect devs to have MinGW installed.  Mac OS X's 
standard dev environment is Xcode and you can expect devs to have that 
installed.

 I think there is a clear benefit to supporting older versions of Mac OS X. 
 Not everybody upgrades at the same rate that Apple releases new versions. 
 Indeed, Apple's updates occasionally change architecture requirements or 
 break applications, so some people cannot upgrade.

Most people upgrade quickly on the Mac platform and, anyway, it does not matter 
if they have Xcode already installed, which is the case for the majority of 
devs.  In fact, that majority is inconvenienced by the additional complexity

Re: How to install GhC on a Mac without registering?

[Manuel M T Chakravarty]

Lars Viklund:
 On Fri, Jun 10, 2011 at 09:24:41PM +1000, Manuel M T Chakravarty wrote:
 Well, then get the DVDs bundled with your Mac and install Xcode from those, 
 or sign up at developer.apple.com and get it there.   BTW, Mac users (and 
 esp devs) upgrade very quickly, much faster than, say, Windows users.
 
 I disagree with the assumption that OS X people are quick to upgrade.
 The last set of figures I saw on adoption were something along the lines
 of 15% on 10.6, with almost a third of the users on 10.4 and below,
 taken from some article I read the other week on the rising wave of OS X
 viruses and countermeasures.

Those numbers sound completely wrong and I'd like to see a credible source 
before I believe them.  As just one data point on Snow Leopard adoption, have a 
look at

 http://daringfireball.net/2009/09/snow_leopard_adoption_rate

I would say that readers of Daring Fireball are fairly tech savvy people with 
an above average percentage of developers.  But consider this, 

 it took about five days for 10.6 to pass 10.5

Five days from the release of the OS for 50% of the DF readers to upgrade to 
Snow Leopard.

Manuel


___
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?

[Manuel M T Chakravarty]

[Ian, sorry for the duplicate — wrong sender email at first.]

Ian Lynagh:
 On Mon, Jun 06, 2011 at 03:47:57PM +0100, Malcolm Wallace wrote:
 
 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.)
 
 I'm pretty sure we aren't allowed to redistribute XCode.
 
 As well as gcc and friends, I think XCode also includes various headers
 and/or libraries that we need.
 
 If there is an alternative - especially one that allows us to support
 multiple versions of OS X more easily - then using it may make sense.

You are right, the Xcode install includes many tools as well as headers etc.

What would be the advantage of including gcc and all these other things in GHC? 
 Anybody who is halfway serious about developing software on a Mac will have 
Xcode installed anyway.  Besides, as Xcode updates are now available from the 
Mac App Store, you don't even need to register as a developer with Apple 
anymore — yes, you need to pay the nominal $5 for the 4GB download.  If you 
don't want to do that, install the (probably older) version of Xcode that came 
with the install DVDs of your Mac.

I don't think you can compare this with the situation on Windows.  Microsoft 
does not distribute a canonical set of Unix tools that all developers use.

Manuel


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: RFC: migrating to git

[Manuel M T Chakravarty]

I agree with Roman's position.  I would prefer to stay with darcs (it has its 
advantages and disadvantages, but has definitely been improving much in the 
past).

In any case, all of GHC including all dependencies must be available and 
patchable with a *single* VCS.  Mixing VCS' will lead to madness.

Manuel

PS: This talk about contributing to a project if it changes its VCS seems a bit 
lame to me.  You contribute to a project in a serious way because you care 
about the project and because you need whatever improvements you are 
implementing, not because you like the VCS.


Roman Leshchinskiy:
 On 10/01/2011, at 13:27, Simon Marlow wrote:
 
 On 10/01/2011 13:02, Max Bolingbroke wrote:
 However, I remember the last time this came up there were some issues
 that might make migration painful. From the top of my head:
 
 1) Some people expressed concern that they would have to use two
 revision control systems to work on GHC, because not all GHC
 dependencies would be git-based.
 
 It would be a prerequisite to switching that a GHC developer only has to use 
 one VCS.  So we either migrate dependencies to git, or mirror them in 
 GHC-specific git branches.
 
 I'm not sure how that is going to work. It might well be possible to build 
 GHC using only git. But most GHC developers also contribute to various 
 libraries which are often quite intimately linked to GHC. In particular, GHC 
 patches are often accompanied by library patches. Unless all those libraries 
 switch to git, too, we'll have to use both git and darcs which would be 
 *really* annoying.
 
 Personally, I rather dislike git, mostly for the reasons that Malcolm already 
 mentioned. Compared to darcs, it seems to get in the way much too often. It 
 also seems to make finding buggy patches rather hard. But maybe I just don't 
 know how to use it properly. In any case, a switch to git wouldn't deter me 
 from contributing to GHC, but neither would a switch to any other VCS. I 
 would certainly swear more often while developing, though.
 
 Roman
 
 
 
 ___
 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: packaging options for Mac OS X

[Manuel M T Chakravarty]

Ian Lynagh:
 On Sun, Nov 28, 2010 at 12:56:00PM -0800, Mark Lentczner wrote:
 
 Outstanding question is what should this framework be called? I would like 
 to continue to call it GHC.framework, but change the version to something 
 like 7.0.1+HP-i386,
 
 I think it ought to be called Haskell-Platform.framework.

The GHC.framework inside the Haskell Platform should still be the 
GHC.framework.  The rest of the Haskell Platform might be in a different 
framework (or further, more specific frameworks identifying the individual 
components inside).  A Mac OS X framework is *not* a unit of distribution.  It 
is more like a library with associated meta data and tools.  You wouldn't 
rename glibc to, say, ubuntulibc just because you happen to get it via an 
Ubuntu install.

 [*] The binary GHC distribution could be
  - built by the GHC team, and asking them for a tarball (as Duncan 
 suggested)
 
 I do make framework-pkg to build the OS X installer, but it's
 essentially a black box to me. We're happy to accept patches that make
 this also produce a bindist, though.
 
 Now that we have the Haskell Platform, perhaps we should stop making GHC
 OS X installers, and only make plain old unix bindists.

Especially given that the Haskell Platform is released many months after GHC, 
please keep making GHC OS X installers.  At the very least, that will lead to 
more GHC installs and *testing* on OS X between the GHC release and Haskell 
Platform release.

Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

ANN: Data.Array.Accelerate 0.8.0.0 — an EDSL for accelerated array computations

[Manuel M T Chakravarty]

Data.Array.Accelerate defines an embedded language of array computations for 
high-performance computing. Computations on multi-dimensional, regular arrays 
are expressed in the form of parameterised collective operations (such as maps, 
reductions, and permutations).  Version 0.8.0.0 of Accelerate includes a mostly 
feature-complete backend generating code for NVIDIA's CUDA language for 
general-purpose GPU computing.  More on this release is at

 http://justtesting.org/second-beta-release-for-the-cuda-backend-of-a

On Hackage: http://hackage.haskell.org/package/accelerate

If you are keen on Haskell on GPUs, give this a spin!

Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Removing/deprecating -fvia-c

[Manuel M T Chakravarty]

Simon Marlow:
 [..]
 But let's face it, all of this code is crappy.  It should be a tiny little 
 loop rather than a tail-call with argument passing, and that's what we'll get 
 with the new backend (eventually).  LLVM probably won't turn it into a loop 
 on its own, that needs to be done before the code gets passed to LLVM.

I fully agree with Simon.  There is no point in doctoring around with an 
inherently broken approach, and to waste developer cycles tracking changes to 
gcc and so forth.  Gladly, we have two technologies ready (the new backend and 
LLVM) that have the potential to significantly improve the current situation.  
Let's spend developer cycles on these instead.

Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: DPH and CUDA status

[Manuel M T Chakravarty]

Scott Michel wrote,
 Are you also planning a LLVM backend for ghc, in a general sense, or just for 
 the accelerated work you're doing? It seems to me that ghc itself could be 
 well served with a LLVM backend, especially if one relies on the JIT mode. 
 That could help identify code paths in the core and runtime that are 
 infrequently used, further optimizing ghc's overall performance.

I had a student implementing a LLVM backend for GHC last year.  You can find 
the details at

  http://www.cse.unsw.edu.au/~pls/thesis/davidt-thesis.pdf

We are planning to merge this work into the main GHC repository.

(At the moment, this is not using the JIT, but that would be another 
interesting project.)

Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: DPH and CUDA status

[Manuel M T Chakravarty]

Felipe Lessa:
 I would suggest that any GSoC project in this space should be based
 on D.A.Accelerate (rather than DPH), simply because the code base is
 much smaller and more accessible.  There is not much point in
 writing a CUDA backend, as we already have a partially working one
 that we are going to release in due course.  However, I repeatedly
 had people asking for an OpenCL backend.  So, there appears to be
 some demand for that (and it's the right thing to do, given that
 CUDA is tied to a single company).  An OpenCL backend for
 D.A.Accelerate also appears to be in the scope of what a good coder
 can achieve in the timeframe of a GSoC project.  (To be precise, I
 think, a good coder can implement a working backend in that
 timeframe, but it will probably require more work to generate well
 optimised code.)
 
 Thanks, that's very interesting.  What about an LLVM backend, would it
 be useful?  Perhaps it would be possible to use its vector operations
 to use SIMD instructions of modern CPUs (I think GHC isn't there yet,
 right?).  This is just a thought :).

I'm currently implementing an LLVM backend.  I'm not planning on using SIMD 
instructions in the first version, but it is an interesting idea for when a 
basic LLVM works.

Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: DPH and CUDA status

[Manuel M T Chakravarty]

Felipe Lessa:
 On Wed, Feb 03, 2010 at 11:37:09AM -0600, Donnie Jones wrote:
 Hello Felipe,
 
 I copied this email to Sean Lee  Manuel M T Chakravarty as they
 worked on Haskell+CUDA, maybe they can comment on the current status?
 
 Here's their paper...
 GPU Kernels as Data-Parallel Array Computations in Haskell
 http://www.cse.unsw.edu.au/~chak/papers/gpugen.pdf
 
 As far as I could look for on Hackage and on Chakravarty's web
 site the code from the paper isn't released.  So now he has DPH,
 Data.Array.Accelerate and GPU monad for array processing :).

It's really only two things, as the GPU monad from the cited paper has been 
superseded by Data.Array.Accelerate — ie, the latter is a revision of the 
former.  So, the code from the cited paper will eventually be released as a 
CUDA backend for D.A.Accelerate.

 I wonder if he has any plans of gluing things?

Our intention is to bring the two together eventually, but at the moment, each 
project on its own is already rather challenging.  As far as

  http://hackage.haskell.org/trac/summer-of-code/ticket/1537

is concerned, I think it is a huge amount of work, well beyond what even a 
group GSoC project could achieve, especially as it is not just an 
implementation project, but requires a large amount of research.  Things may 
get a bit easier with the recently announced Fermi architecture, but I don't 
think that is going to change the picture fundamentally.

I would suggest that any GSoC project in this space should be based on 
D.A.Accelerate (rather than DPH), simply because the code base is much smaller 
and more accessible.  There is not much point in writing a CUDA backend, as we 
already have a partially working one that we are going to release in due 
course.  However, I repeatedly had people asking for an OpenCL backend.  So, 
there appears to be some demand for that (and it's the right thing to do, given 
that CUDA is tied to a single company).  An OpenCL backend for D.A.Accelerate 
also appears to be in the scope of what a good coder can achieve in the 
timeframe of a GSoC project.  (To be precise, I think, a good coder can 
implement a working backend in that timeframe, but it will probably require 
more work to generate well optimised code.)

Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC 6.12 + zlib + Mac OS 10.6

[Manuel M T Chakravarty]

Antoine Latter:
 On Sat, Nov 28, 2009 at 3:54 PM, Yusaku Hashimoto nonow...@gmail.com wrote:
 I think you installed zlib without proper flags to link with 32-bit
 libraries. configuring with ./Setup configure
 --with-hsc2hs='--cc-flag=-m32 --ld-flag=-m32' should do the tricks.
 
 See also http://hackage.haskell.org/trac/ghc/ticket/3681.
 
 HTH
 -~nwn
 
 The following worked like a charm:
 
 cabal install --hsc2hs-options='--cc-flag=-m32 --ld-flag=-m32'

Which version of 6.12 are you running?  These options or manually patching the 
hsc2hs wrapper should not be necessary with 6.12 anymore.  (They are only a 
temporary workaround to use the old 6.10 release on Snow Leopard.)

Manuel___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: 6.12.1 release

[Manuel M T Chakravarty]

Simon Marlow:
Or, we could just make a 6.12.1 RC2, and advertise it with the same  
caveats, putting out 6.12.1 when cabal-install works and we've had a  
chance to see the state of Hackage and alert package authors.


Simon and I favour the RC2 option.  What do others think?


I agree.  I don't think anybody benefits from an earlier, but buggier  
release.


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 6.12.1 Release Candidate 1

[Manuel M T Chakravarty]

Barney Stratford:

this one built and installed fine on Mac OS X 10.6 :).

Interesting, I thought there were still problems there.
I assume that's a 32-bit version. The problems manifest themselves  
only when you compile a 64-bit GHC.


That's incorrect.  The 32-bit version is only partially working.  GHCi  
dies with a bus error (after package loading) and various features  
that need the interpreter/dynamic loading (such as TH and annotations)  
die under certain circumstances.


Disclaimer: I didn't actually test this with 6.12.1RC1, but with  
6.13.  However, there shouldn't be any difference as I am not aware of  
any 6.12.1-specific Mac fixes.


Manuel

PS: I am chasing these bugs, but I don't have a lot of time for that  
at the moment, they are tricky bugs, and my Mac-fu is still pretty  
limited.  So, if anybody else likes to have a go with gdb and dtrace,  
please do so.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC on Snow Leopard: best practices?

[Manuel M T Chakravarty]

David Menendez:

Is there any consensus about what needs to be done to get a working
ghc installation on a Snow Leopard (Mac OS X 10.6) system? The Mac OS
X wiki page[1] currently links to a blog post[2] that recommends
manually patching /usr/bin/ghc, but I have also seen recommendations
that people patch ghci, runhaskell, runghc, and hsc2hs. Is that also
recommended? If so, there should probably be an updated how-to on the
wiki.


Patching /usr/bin/ghc is sufficient to get a version of GHC that  
passes the regression tests suite in fast mode (the same setting  
that the validate script uses).  If you want to use hsc2hs, you need  
to patch that, too.  I haven't found a need to patch the interpreter,  
though.


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Snow Leopard GHC

[Manuel M T Chakravarty]

Simon Marlow:

On 24/09/2009 23:54, Barney Stratford wrote:

I've tried just letting the dynamic linker (dyld) sort everything out
for us, but this failed because not all symbols are dynamically  
linked,

and the statically linked ones are invisible to it.

One change that will be necessary in any case: towards the end of
rts/Linker.c, change
case X86_64_RELOC_SIGNED:
ASSERT(reloc-r_pcrel);
thing += value - baseValue;
break;

to

case X86_64_RELOC_SIGNED:
case X86_64_RELOC_SIGNED_1:
case X86_64_RELOC_SIGNED_2:
case X86_64_RELOC_SIGNED_4:
ASSERT(reloc-r_pcrel);
thing += value - baseValue;
break;


Manuel, maybe you could validate and push this one?


I am happy to take care of funnelling Barney's changes into the main  
repo.  However, I think there was at least one more mentioned in  
another email.


Barney, do you have a comprehensive set of the changes that you made  
(ideally against the HEAD repo, or a nightly snapshot, but if that's  
difficult, then against 6.10)?  And did you try to run the testsuite http://darcs.haskel.org/testsuite 
 with the compiler that you generated?


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC API: How to determine Type.Type equality when using type operators?

[Manuel M T Chakravarty]

Christiaan Baaij:
I believe that you are asking about type functions.  Specifically,  
I think what you are asking is this:


How can I normalise a type, by rewriting it exhaustively using
the top-level type-function definitions


That is indeed a better formulation of my original question

I think the function TcTyFuns.tcNormaliseFamInst (rather an odd  
name!) does this.  But it's not very helpful to you because it's in  
the main typechecker monad.


At the moment it is not such a big problem that it is in the  
typechecker
monad, as we run some parts of our compiler in a GHC Monad, and can  
thus

initialize a typechecker monad with the function TcRnMonad.initTc.

However, at the moment I can't get to normalise the types as far as I
had hoped. Here is an example of my debug output:

Before normalisation:
Types.Data.Num.Decimal.Literals.D4
Types.Data.Num.Ops.:*: Types.Data.Num.Decimal.Literals.D3

After normalisation:
Types.Data.Num.Decimal.Digits.Dec
 (Types.Data.Num.Decimal.Digits.DecN
  Types.Data.Num.Ops.:. Types.Data.Num.Decimal.Digits.Dec4)
Types.Data.Num.Ops.:*: Types.Data.Num.Decimal.Digits.Dec
(Types.Data.Num.Decimal.Digits.DecN
 Types.Data.Num.Ops.:.  
Types.Data.Num.Decimal.Digits.Dec3)


So, currently I can normalize the synonyms D4 and D3, but I can't
normalize the type function :*:. Maybe it has something to do with  
how I

load the module and its dependencies.


Yes, it has something to do with module loading and the type-checker  
monad.  It's not enough to load the modules, you also need to  
initialise those components of the type-checker monad that contain the  
environment of visible type instance declarations.  The component is  
called tcg_fam_inst_env and you can see in the function  
TcRnDriver.tcRnImports how to extend it.  You did well in remembering  
to load the orphan modules, but you also ought to call  
FamInst.checkFamInstConsistency to check for overlapping instances in  
the modules that you are loading (it's used right at the end of  
TcRnDriver.tcRnImports).


Hope that helps a bit.

Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: 6.10.3 plans

[Manuel M T Chakravarty]

Ian Lynagh:

On Fri, Apr 24, 2009 at 11:08:38AM +0100, Simon Marlow wrote:


We do have a WARNING pragma, incedentally:

http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#warning-deprecated-pragma


I don't think that using it for this would be a good idea, though. It
would mean that people who really do want
   Foreign.ForeignPtr.{newForeignPtr,addForeignPtrFinalizer}
would not be able to write warning-free code.


I agree.

Manuel
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: No last core parallel slowdown on OS X

[Manuel M T Chakravarty]

Dave Bayer:
In that paper, they routinely benchmark N-1 cores on an N core Linux  
box, because of a noticeable falloff using the last core, which can  
do more harm than good. I had confirmed this on my four core Linux  
box, but was puzzled that my two core MacBook showed no such  
falloff. Hey, two cores isn't representative of many cores, cache  
issues yada yada, so I waited.

[..]
Compared to 2 cores, using 3, 4 cores on an equivalent four core box  
running OS X gives speedups of


1.45x, 1.9x


As another data point, in our work on Data Parallel Haskell, we ran  
benchmarks on an 8-core Xserve (OS X) and an 8-core Sun T2 (Solaris).   
On both machines, we had no problem using all 8 cores.


Manuel
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1

[Manuel M T Chakravarty]

jutaro:
This is the first answer I got from the gtk2hs mailing list. Please  
consider

this issue seriously.


Well there is a simple fix as Simon Marlow wrote,
The fix is fiarly easy: use Foreign.Concurrent.mkForeignPtr with a  
foreign import.


In fact, if as Axel writes, these finalisers are Haskell functions  
that are exported using foreign import wrapper, then using  
Foreign.Concurrent.mkForeignPtr is actually the *simpler* thing to do  
(you don't need any wrapping and exporting).


Manuel


Axel Simon wrote:



Phew,

I think we're doomed. We have many, many little methods that take a
user-given function, wrap it into a foreign export wrapper which is
freed by using an on-destroy callback to Haskell. These functions are
most likely installed into some widgets (or other reference-counted
objects) that will be eventually destroyed by the Haskell garbage
collector. So, basically, we can't easily change Gtk2Hs. It will
involve many modifications. I can understand that not allowing
callbacks during GC is a great simplification in the runtime but it
seemed to be common practice to free Stable and function pointers
from within Haskell using a callback.

So, unless I'm wrong on why finalizers call back into Haskell land,
then this means that Gtk2Hs is fundamentally broken for the
foreseeable future.

Axel.


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Adding DPH to HEAD

[Manuel M T Chakravarty]

Colin Paul Adams:

I tried following the advice on the DPH wiki:

./sync-all --dph get

This wouldn't run because of permissions, so I tried putting sh in
front of the command. This produced a lot of error messages:


Some guy by the handle of Megacz added this to the page.  No idea  
why.  I'll change that.


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Deep fmap with GADTs and type families.

[Manuel M T Chakravarty]

David Menendez:

On Thu, Mar 5, 2009 at 10:07 PM, Dan Doel dan.d...@gmail.com wrote:


But we've so far not been able to find a way of merely annotating  
the original
into working. So, I was wondering if any of the more knowledgeable  
folks here
could illuminate what's going wrong here, and whether I should  
expect my

original code to work or not.


I'll bet the problem has to do with the fact that f only appears in
Nest n f a, so the type checker can't figure out what f is.


Exactly.  In other words, the signature is ambiguous.

Manuel
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: DPH Questions

[Manuel M T Chakravarty]

Roman Cheplyaka:
* Manuel M T Chakravarty c...@cse.unsw.edu.au [2009-02-12  
12:16:26+1100]

Also - there are several papers which mention foldP as being part of
the (prospective) implementation, but I couldn't find this in any of
the modules.  Has this one not been implemented yet?


Up to now, the implementation of operations in the special-purpose
Prelude and the array library was essentially driven by the  
examples we

coded so far:

 http://darcs.haskell.org/packages/dph/examples/

So if we didn't actually use a function somewhere, we probably didn't
implement it.  Again, the motivation was to get simple examples  
working

before making any attempt at completing the set of supported language
features or library functions.


It is present here [1] -- so at least it has been implemented.

 1. 
http://www.haskell.org/ghc/docs/latest/html/libraries/base/GHC-PArr.html#v%3AfoldlP


That's an old library, not the one used for vectorised code.

Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: DPH Questions

[Manuel M T Chakravarty]

James Swaine:
I was wondering if anyone could point me to a more in-depth  
explanation of why we are (currently) restricted to using a special- 
purpose standard Prelude when writing vectorised code with DPH.


The reason is simply that the standard version of the Prelude uses  
Haskell features that are not yet supported by the vectoriser; in  
particular, type classes and unboxed values.  There is no deep reason  
for this.  It's simply that our priority was to get simple programs  
completely working with vectorisation from source down to runtime  
support before widening the path by supporting more language features  
- ie, we know how to implement these features, but didn't get around  
to doing it yet.


We're prototyping using several data-parallel languages for a  
research project here at Northwestern University, and wanted to get  
a better idea how we might go about adding vectorisation support for  
addtional types/operations.


There are certain simple operations which don't appear to be  
supported for primitive types yet (e.g. the ^ and ** operators for  
an Int type).  These are the kinds of things we'd like to look into  
as a first step.


Also - there are several papers which mention foldP as being part of  
the (prospective) implementation, but I couldn't find this in any of  
the modules.  Has this one not been implemented yet?


Up to now, the implementation of operations in the special-purpose  
Prelude and the array library was essentially driven by the examples  
we coded so far:


  http://darcs.haskell.org/packages/dph/examples/

So if we didn't actually use a function somewhere, we probably didn't  
implement it.  Again, the motivation was to get simple examples  
working before making any attempt at completing the set of supported  
language features or library functions.


Generally, we are always keen to hear what (potential) users need  
most.  Where possible, we take these preferences into account in our  
work plan.  If you are able to add some functionality yourself, that  
would of course be even better and we would be more than happy to  
receive patches to include into the distribution.


Adding functionality to the special-purpose Prelude should usually be  
fairly straight forward; eg, support for more data types mostly  
requires to copy and slightly adapt existing code and new  
functionality can often be achieved by taking code from either GHC's  
standard Prelude (but remember the restriction on type classes and  
unboxed values in the current version of the vectoriser) or the  
Prelude section of the Haskell 98 report.


The difficulty of extending the array library depends very much on the  
functions that you like to add.  Some things are easy as they can be  
implemented by reusing and adapting existing code, but some  
functionality requires a clear understanding of the internals of the  
library.  In any case, please feel free to ask if you encounter any  
problems.  We are currently working on automatically generating parts  
of the repetitive boilerplate of the core array library.  This will  
hopefully simplify adding new functionality.


Finally, would you mind telling us a bit more about your research  
project and what you might want to use DPH for?  We are always curious  
about concrete usage scenarios.  If you don't want to discuss this on  
the list, just send me a personal email.


Cheers,
Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Plans for GHC 6.10.2

[Manuel M T Chakravarty]

Ian wrote,

This is just a quick summary of our plans for GHC 6.10.2.


While it is possible that we will fix some others, for the 6.10.2
release we mainly intend to look at the high-priority bugs in the  
6.10.2

milestone. They are listed here:

   
http://hackage.haskell.org/trac/ghc/query?status=newstatus=assignedstatus=reopenedpriority=highpriority=highestmilestone=6.10.2order=priority


#2658 really needs input from the reporter (see my last comment on the  
ticket).


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Type checker loops with type families, overlapping and undecidable instances

[Manuel M T Chakravarty]

As Lennart wrote, with UndecideableInstances all bets are off.

Concerning the fixed-depth recursion stack.  It is currently only used  
for the simplification of class instance declarations, but if  
improvement rules are involved (either FDs or TFs) that check will not  
catch all cases anyway.


The interaction between solving class constraints and equalities with  
type families is currently rather ad hoc.  We are currently re- 
designing that interaction and may then make the fixed-depth  
restriction more broadly applicable.  However, as Tom already  
mentioned, the cycle does not involve type families in your example  
anyway.


Manuel

José Pedro Magalhães:

Hello Lennart,

Yes, but according to the manual (http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html#undecidable-instances 
), Termination is ensured by having a fixed-depth recursion stack.  
So I would expect at least termination, which I'm not getting (but I  
guess that can be due to the type families).



Thanks,
Pedro

On Thu, Dec 4, 2008 at 15:10, Lennart Augustsson [EMAIL PROTECTED] 
 wrote:

Turning on UndecidableInstances is the same as saying: OK typechcker,
you can loop if I make a mistake.
I've not looked closely at your code, but if you turn on that flag,
looping is probably not a bug.

 -- Lennart

2008/12/4 José Pedro Magalhães [EMAIL PROTECTED]:
 Hello all,

 Please consider the following code:

 {-# OPTIONS -Wall #-}
 {-# LANGUAGE FlexibleContexts #-}
 {-# LANGUAGE FlexibleInstances#-}
 {-# LANGUAGE TypeOperators#-}
 {-# LANGUAGE TypeFamilies #-}
 {-# LANGUAGE OverlappingInstances #-}
 {-# LANGUAGE UndecidableInstances #-}

 module Test where

 -- Some view
 class Viewable a where
   type View a
   to   :: a - View a

 -- Structural representations
 data Unit= Unit
 data a :+: b = L a | R b

 instance Viewable Unit where
   type View Unit = Unit
   to = id

 instance (Viewable a, Viewable b) = Viewable (a :+: b) where
   type View (a :+: b) = a :+: b
   to = id

 -- Worker class
 class F' a where
   f' :: a - ()

 instance F' Unit where
   f' Unit = ()

 instance (F a, F b) = F' (a :+: b) where
   f' (L x) = f x
   f' (R x) = f x


 -- Dispatcher class
 class (Viewable a, F' (View a)) = F a where
   f :: a - ()
   f = f' . to

 instance F Unit where
   f = f'

 instance (F a, F b) = F (a :+: b) where
   f = f'

 -- All generic instances
 instance (Viewable a, F' (View a)) = F a


 -- A recursive datatype
 data Nat = Zero | Succ Nat

 -- Instance of Viewable
 instance Viewable Nat where
   type View Nat = Unit :+: Nat
   to = undefined

 -- Uncommenting the line below causes the typechecker to loop  
(GHC 6.10.1,

 Windows)
 --test = f Zero


 Is this expected behavior or a bug?


 Thanks,
 Pedro

 ___
 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


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Using Data Parallel Haskell

[Manuel M T Chakravarty]

As previously announced, GHC 6.10.1 includes a technology preview of  
Data Parallel Haskell.  However, so far, there was no documentation on  
how to use it. That is different now:


  http://haskell.org/haskellwiki/GHC/Data_Parallel_Haskell

Please keep in mind that this is a very preliminary version of the  
system with limited functionality.  However, we are very interested in  
feedback from interested users.


Happy Vectorising!
Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC version 6.10.1 - MacOS installer

[Manuel M T Chakravarty]

Jason Dagit:
On Wed, Nov 5, 2008 at 5:36 PM, Manuel M T Chakravarty [EMAIL PROTECTED] 
 wrote:

Ian Lynagh:

On Tue, Nov 04, 2008 at 09:02:12PM -0500, Brandon S. Allbery KF8NH  
wrote:

On 2008 Nov 4, at 20:26, Jason Dagit wrote:
On Tue, Nov 4, 2008 at 4:26 PM, Manuel M T Chakravarty
[EMAIL PROTECTED] wrote:

Are you sure it does deinstall the 6.8 compiler?

After installing 6.10, there should be a 608/ and a 610/
directory.  This
certainly happens on my Mac and I am not aware of an option to
change that
behaviour.

I expect if you used the OSX installer then /Library/Receipts is
screwing you (it wipes the old files listed in the .bom file).  Try
finding and removing the receipt directory and bom file before
installing.

The only file I can see that looks relevant is
  /Library/Receipts/boms/ 
org.haskell.glasgowHaskellCompiler.ghc.pkg.bom


Wouldn't removing it make uninstall impossible?

In fact, if you did manage to get 2 versions installed, how would
  /Library/Frameworks/GHC.framework/Tools/Uninstaller
know which version to uninstall? Wouldn't it only know how to  
uninstall

the version it came with? I'd suggest that the overlapping file
Uninstaller could be why the older version gets removed, but that
wouldn't explain why Manuel can install both at once.

A current limitation of the MacOS package system is that it does not  
support uninstalling of packages; cf


 http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Managed_Installs/chapter_5_section_7.html#/ 
/apple_ref/doc/uid/1145i-CH6-DontLinkElementID_29


This is not a big drama on MacOS, as MacOS encourages the  
distribution of software packages as bundles:


 
http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/CFBundles.html

This essentially means that instead of sprinkling files all over the  
file system (as is common in other OSes), MacOS applications and  
frameworks (Mac-speak for libraries) are kept in a single  
directory.  Uninstalling then means doing an rm -rf on that directory.


Unfortunately, some applications (including GHC and Apple's Xcode  
IDE) can't be entirely contained in a single directory.  In the case  
of GHC, we want symlinks in /usr/bin.  The established way of  
uninstalling such applications is by supplying an Uninstaller  
script, just as I did for GHC.  (Apple does the same for Xcode.)


The purpose of the Uninstaller script is too completely remove  
GHC.framework from a machine - not just to remove one version.  In  
fact, if more than one version of GHC is installed, the Uninstaller  
will refuse to run and require the manual removal of all versions,  
but the current (easily achieved by a rm -rf /Library/Frameworks/ 
GHC.framework/Versions/version).  The main feature of the  
Uninstaller script is to get rid of all symlinks pointing into  
GHC.framework.  The framework itself is just deleted by a rm -rf  
as expected.  (It also removes the above mentioned receipt file.)


So, to directly answer the above questions:
* The package manger (which uses the receipts) can't uninstall and  
the uninstaller script doesn't need the receipt.  So, even after  
deleteing the receibt, you can still uninstall.
* The Uninstaller can uninstall any version (at least as long as no  
symlinks are put into new directories outside of the bundle that the  
Uninstaller doesn't know about).


Is there an update on this thread?  I would still like to have my  
cake and eat it too, meaning ghc 6.8.3 and ghc 6.10.1.  As far as I  
know the installer hasn't been updated and if I try again I will  
lose my copy of 6.8.3.


Sorry, but for the moment, my (rather limited knowledge) of the MacOS  
packaging system is exhausted, and currently I don't have the time to  
search the web or experiment to try to learn more.  It would be  
helpful to have the input of somebody who has more experience with  
MacOS packages.


Manuel___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC version 6.10.1 - MacOS installer

[Manuel M T Chakravarty]

Ian Lynagh:
On Tue, Nov 04, 2008 at 09:02:12PM -0500, Brandon S. Allbery KF8NH  
wrote:

On 2008 Nov 4, at 20:26, Jason Dagit wrote:

On Tue, Nov 4, 2008 at 4:26 PM, Manuel M T Chakravarty
[EMAIL PROTECTED] wrote:


Are you sure it does deinstall the 6.8 compiler?

After installing 6.10, there should be a 608/ and a 610/
directory.  This
certainly happens on my Mac and I am not aware of an option to
change that
behaviour.


I expect if you used the OSX installer then /Library/Receipts is
screwing you (it wipes the old files listed in the .bom file).  Try
finding and removing the receipt directory and bom file before
installing.


The only file I can see that looks relevant is
   /Library/Receipts/boms/ 
org.haskell.glasgowHaskellCompiler.ghc.pkg.bom


Wouldn't removing it make uninstall impossible?

In fact, if you did manage to get 2 versions installed, how would
   /Library/Frameworks/GHC.framework/Tools/Uninstaller
know which version to uninstall? Wouldn't it only know how to  
uninstall

the version it came with? I'd suggest that the overlapping file
Uninstaller could be why the older version gets removed, but that
wouldn't explain why Manuel can install both at once.


A current limitation of the MacOS package system is that it does not  
support uninstalling of packages; cf


 http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Managed_Installs/chapter_5_section_7.html#/ 
/apple_ref/doc/uid/1145i-CH6-DontLinkElementID_29


This is not a big drama on MacOS, as MacOS encourages the distribution  
of software packages as bundles:


  
http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/CFBundles.html

This essentially means that instead of sprinkling files all over the  
file system (as is common in other OSes), MacOS applications and  
frameworks (Mac-speak for libraries) are kept in a single directory.   
Uninstalling then means doing an rm -rf on that directory.


Unfortunately, some applications (including GHC and Apple's Xcode IDE)  
can't be entirely contained in a single directory.  In the case of  
GHC, we want symlinks in /usr/bin.  The established way of  
uninstalling such applications is by supplying an Uninstaller script,  
just as I did for GHC.  (Apple does the same for Xcode.)


The purpose of the Uninstaller script is too completely remove  
GHC.framework from a machine - not just to remove one version.  In  
fact, if more than one version of GHC is installed, the Uninstaller  
will refuse to run and require the manual removal of all versions, but  
the current (easily achieved by a rm -rf /Library/Frameworks/ 
GHC.framework/Versions/version).  The main feature of the  
Uninstaller script is to get rid of all symlinks pointing into  
GHC.framework.  The framework itself is just deleted by a rm -rf as  
expected.  (It also removes the above mentioned receipt file.)


So, to directly answer the above questions:
* The package manger (which uses the receipts) can't uninstall and the  
uninstaller script doesn't need the receipt.  So, even after deleteing  
the receibt, you can still uninstall.
* The Uninstaller can uninstall any version (at least as long as no  
symlinks are put into new directories outside of the bundle that the  
Uninstaller doesn't know about).


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC version 6.10.1 - MacOS installer

[Manuel M T Chakravarty]

Jason Dagit:

On Tue, Nov 4, 2008 at 10:11 AM, Ian Lynagh [EMAIL PROTECTED] wrote:


How to get it
~

The easy way is to go to the web page, which should be self- 
explanatory:


  http://www.haskell.org/ghc/

We supply binary builds in the native package format for many
platforms, and the source distribution is available from the same
place.

Packages will appear as they are built - if the package for your
system isn't available yet, please try again later.


I'm on OSX and I currently have ghc-6.6.1 and ghc-6.8.3 (installed
from a pkg). I would like to add ghc-6.10.1 to my system.  I tried to
do this with RC1 of 6.10, but I found that it uninstalled my
ghc-6.8.3.

What will I need to do to get both 6.8.3 and 6.10.1?


Are you sure it does deinstall the 6.8 compiler?  Or does it just  
overwrite the symbolic links in /usr/bin?  To check, have a look at


  /Library/Frameworks/GHC.framework/Versions

After installing 6.10, there should be a 608/ and a 610/ directory.   
This certainly happens on my Mac and I am not aware of an option to  
change that behaviour.


And while we are at it...a BIG FAT WARNING:

  If you installed the 6.10.200081007 pre-release installer package,
  uninstall that *before* installing the 6.10.1 package.

For reasons, I don't understand, the installer otherwise half removes  
the old package, but doesn't seem to install the new one.  Can a Mac  
expert shed any light on that behaviour?


If you tried installing 6.10.1 before reading that, just remove the  
partial installation you are left with, and install again.


Manuel
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Illegal type synonym family application in instance (Was: Breakage with 6.10)

[Manuel M T Chakravarty]

Niklas Broberg:

On 10/11/08, David Menendez [EMAIL PROTECTED] wrote:

On Fri, Oct 10, 2008 at 8:40 PM, Niklas Broberg
[EMAIL PROTECTED] wrote:

src\HSX\XMLGenerator.hs:71:0
  Illegal type synonym family application in instance: XML m
  In the instance declaration for `EmbedAsChild m (XML m)´
---

Could someone help me point out the problem here? The relevant  
code is:


instance XMLGen m = EmbedAsChild m (XML m) where
asChild = return . return . xmlToChild

class XMLGen m = EmbedAsChild m c where
asChild :: c - GenChildList m

class Monad m = XMLGen m where
type XML m


This works fine with 6.8.3, so what's new in 6.10, and what would  
I do

to solve it?



I'm guessing there was a bug in 6.8.3 that allowed this. (The
implementation of type families is present but not supported in 6.8,
presumably because of problems like this.)

I don't have 6.10, so I can't test anything, but you might try
rewriting the EmbedAsChild instances like so:

   instance (XMLGen m, XML m ~ x) = EmbedAsChild m x where ...


Thanks a lot David, that's indeed what I needed.

I'm not sure I see why the style I used previously was illegal though,
it seemed perfectly natural to me. And it works that way for
`EmbedAsChild m (Child m)´, where `Child m´ is a data type family and
not a synonym, so why not for a synonym too? But hey, as long as
there's a way to do what I want. :-)


As suggested, it was a bug in 6.8.3 that you could make a class  
instance where the head involved a type synonym family.  We cannot  
allow synonym families in class instances heads as it is impossible to  
check for overlap of such instances; eg, consider


  type family F a
  type instance F Bool = Int

  class C a

  instance C Int
  instance C (F a)

Now a context (C (F Bool)) would match both instances.  This is  
especially bad, as the type instance for F Bool may be defined in a  
different module as the instances for C; so, it is even in principle  
impossible to check for such overlap.


The situation is different for data families as they are data types  
and not type synonyms.


Moreover,

  instance (XMLGen m, XML m ~ x) = EmbedAsChild m x where ...

is fine as it clearly overlaps with any other instance of EmbedAsChild.

I hope that clarifies the situation.

Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Version control systems

[Manuel M T Chakravarty]

Ian Lynagh:
On Mon, Aug 18, 2008 at 12:21:47PM +1000, Manuel M T Chakravarty  
wrote:

From what you are saying, it seems that one advantage of git (in-
place branch switching) is not going to be useful to GHC in any case


Yes.


(because we use nested repositories).


That does make it harder, but the main problem is that switching  
between

branches changes the timestamp of files that differ, meaning the build
system thinks that recompilation needs to be done.

Also, if you have 2 in-place branches of GHC then only one of them can
be built at any one time, as they share a working directory.


That doesn't sound like GHC-specific issues.  So, if inplace branches  
are useful for other projects -such as the Linux kernel- why shouldn't  
it be useful for us?


Manuel
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Version control systems

[Manuel M T Chakravarty]

Gregory Wright:

On Aug 14, 2008, at 9:12 PM, Manuel M T Chakravarty wrote:

Moreover, as I wrote a few times before, some reasons for switching  
in the first place are invalidated by not having the core libraries  
in git, too.  For example, one complaint about darcs is that it  
either doesn't build (on the Sun Solaris T1 and T2 machines) or is  
buggy (on Mac OS with MacPorts), and hence people have trouble  
getting the sources out of darcs in the first place.  How is that  
going to be addressed if some crucial code still needs to be  
obtained using darcs?




Regarding darcs on OS X from MacPorts, I am not aware (or have been  
sent any bug reports) that there
are problems with the latest darcs-2.0.0 port.  Is there something  
that I should know (and try to fix)?


The latest port defaults to wget instead of libcurl since I have  
noticed darcs spinning endlessly when
using libcurl.  I haven't had time to dtrace what is going on but  
I'm guessing the underlying problem is likely
some misunderstanding of the signal handling API or some corner case  
of blocking/nonblocking IO.


Well, that spinning endlessly is the bug I am referring to.  I re- 
checked my MacPorts darcs2 installation and, you are right, there was  
an update that removes the use of libcurl.  It seems to work *much*  
better now.


Thanks for the fix!

You may want to publicise this a bit further.  When I asked on #darcs  
about the problem a few days ago, nobody knew about this update to the  
port.


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Version control systems

[Manuel M T Chakravarty]

From what you are saying, it seems that one advantage of git (in- 
place branch switching) is not going to be useful to GHC in any case  
(because we use nested repositories).


Manuel

Ian Lynagh:

On Fri, Aug 15, 2008 at 01:01:08PM +0100, Max Bolingbroke wrote:

2008/8/15 Isaac Dupree [EMAIL PROTECTED]:
So let's figure out how it would work (I have doubts too!) So,  
within the
directory that's a git repo (ghc), we have some other repos, git  
(testsuite)
and darcs (some libraries).  Does anyone know how git handles  
nested repos

even natively?


You can explicitly tell Git about nested Git repos using
http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html.
This essentially associates a particular version of each subrepo with
every version of the repo that contains them, so e.g. checking out  
GHC

from 2 weeks ago could check out the libraries from the same point in
time.


We were talking about this last night on #ghc, and AIUI this doesn't
play well with the in-tree branching style that is advocated, e.g. if
you want to branch ghc and base then as you change between ghc  
branch X

and Y, git won't automatically change base between branches X' and Y'.


Then, adding complexity, git branches are normally done by
switching in-place.  So how does this interact with VCS like darcs  
that

doesn't have a concept of in-place switching of branches?


The in-tree branching style also sounds like it won't work well with
trees you are working in: If you have a tree built with branch X, and
then you swap to branch Y for a minute and then back to branch X, then
the timestamps on any source files that differ between the branches  
will
have changed, so the build won't think it is up-to-date any more and  
you

will get needless recompilation.

Working only in the master branch, and using different repos for
branches (i.e. doing what we do with darcs), is an option, although  
git

users seem to think it is a worse way to work; I'm not really clear on
the main reasons why.

One way that it is worse is that you will get a lot more automatic
merge commits when you pull changes from the central repo into a repo
in which you have local commits. I don't think that there is anything
bad about these, as such; they're just noise in the history. (I'm not
sure if it's possible to automatically rebase these away, or
something?).

Hopefully a git person will correct me if I've got something wrong!


Thanks
Ian

___
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: Version control systems

[Manuel M T Chakravarty]

Ian Lynagh:

On Fri, Aug 15, 2008 at 04:24:12PM +0100, Ian Lynagh wrote:

On Fri, Aug 15, 2008 at 05:09:55PM +0200, Thomas Schilling wrote:

On Fri, Aug 15, 2008 at 4:38 PM, Ian Lynagh [EMAIL PROTECTED] wrote:

One way that it is worse is that you will get a lot more automatic
merge commits when you pull changes from the central repo into a  
repo
in which you have local commits. I don't think that there is  
anything
bad about these, as such; they're just noise in the history. (I'm  
not

sure if it's possible to automatically rebase these away, or
something?).


This is the use case for git pull --rebase.  Instead of creating  
an

automatic merge commit, it rebases your local changes on top of the
newly pulled changes


Hmm, last night the conversation went:

 nominolo malcolmw: so i'm advocating git pull --rebase for
   that use case
 glguy_ rebasing can be less successful than merging when
 dealing with big changes
 glguy_ since the rebase happens one commit
 at a time

so I'm confused as to what the best practice is.


We discussed this in #ghc, and the conclusion seems to be:

If you have lots of local changes (e.g. the sorts of long-running  
branch

that gives darcs 1 problems), then you need to use merge. If you use
rebase then you might end up with lots of conflicts to manually  
resolve.


Using merge gives you automatic merge commits, If you think these are
ugly (opinion is divided on that amongst git people; I guess for GHC
we'd want to make a global decision about that) then you can use  
rebase

when you have few local changes, and thus you are unlikely to get many
conflicts.

Using merge you also get a more accurate reflection of the project
history, i.e. you can see that the two branches were being developed
independently.


Sorry for being a git n00b, but does using merge mean that we need to  
use in-place branch switching (which you earlier said won't work well  
for ghc anyways)?


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Version control systems

[Manuel M T Chakravarty]

Max Bolingbroke:

Then, adding complexity, git branches are normally done by
switching in-place.  So how does this interact with VCS like darcs  
that

doesn't have a concept of in-place switching of branches?


Since we will set up Git to ignore the contents of the Darcs repos, it
will simply leave them unmodified. This is exactly like the current
situation, where rolling back / patching the GHC repo does not affect
the others. If you want Darcs-like behaviour (one branch per repo) you
are free to do this in Git as well, in which case since you never
switch branches the nested Darcs repos should never be inappropriate
for your branch.


This ignores that the ability to have branches, switch between them,  
and merge has been cited as one of the reasons for switching to git.   
Embedded darcs library repos would hence nullify, or at least reduce,  
one of the advantages.


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Version control systems

[Manuel M T Chakravarty]

Duncan Coutts:

On Mon, 2008-08-11 at 13:57 +0100, Simon Marlow wrote:
 - Performance.  darcs2 regressed in performance for many  
operations we
   commonly use.  I've submitted some measurements for some things,  
but
   it's pretty easy to find your own test cases: things like darcs  
add,
   darcs whatsnew, darcs unrecord are all slower than darcs 1.   
When
   simple operations take multiple seconds to complete, it really  
slows

   down your workflow.


Turns out that the reason for slow darcs whatsnew is ghc bug #2093

http://hackage.haskell.org/trac/ghc/ticket/2093

because getSymbolicLinkStatus is broken on 32bit systems in 6.8.2 it
means that the 'stat' optimisation does not work so darcs has to read
the actual contents of many files. Obviously that's very slow,
especially over nfs. That explains why it worked for me in 0.2 seconds
but for you took several seconds user time and (even more real time  
due

to nfs).


LOL - that is funny.  GHC devel slowed down by slow darcs due to GHC  
bug.


The bug is fixed, isn't it?  So, recompiling darcs with 6.8.3 should  
improve matters.


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Version control systems

[Manuel M T Chakravarty]

Neil Mitchell:

If it really makes the life easier for people who are having lots of
VCS pain at the moment, then its hard to object. But many of the
comments in this discussion, about how everyone is going to flock to
GHC just as soon as it switches to Git, seem overly optimistic. I
think GHC is a few years off becoming drive-by hacker friendly, for
many other reasons.


It's not about becoming drive-by hacker friendly.  It is about not  
becoming even less friendly as it is right now.


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Version control systems

[Manuel M T Chakravarty]

Thomas Schilling:

Are you advocating for ease of use by new developers or for existing
developers? Current GHC hackers have to learn Git anyways and know
Darcs already. Library patches still have to be recorded separately,
so it would be a bit weird, but not much harder, really.


I am arguing for both.  It would be more than weird.  For example, if  
you branch ghc, you usually need to branch the core libraries, too.   
Doing that in two different vcs sounds like a mess to me.


Moreover, as I wrote a few times before, some reasons for switching in  
the first place are invalidated by not having the core libraries in  
git, too.  For example, one complaint about darcs is that it either  
doesn't build (on the Sun Solaris T1 and T2 machines) or is buggy (on  
Mac OS with MacPorts), and hence people have trouble getting the  
sources out of darcs in the first place.  How is that going to be  
addressed if some crucial code still needs to be obtained using darcs?


Manuel

On Fri, Aug 15, 2008 at 1:59 AM, Manuel M T Chakravarty
[EMAIL PROTECTED] wrote:

Neil Mitchell:


If it really makes the life easier for people who are having lots of
VCS pain at the moment, then its hard to object. But many of the
comments in this discussion, about how everyone is going to flock to
GHC just as soon as it switches to Git, seem overly optimistic. I
think GHC is a few years off becoming drive-by hacker friendly, for
many other reasons.


It's not about becoming drive-by hacker friendly.  It is about not
becoming even less friendly as it is right now.


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Version control systems

[Manuel M T Chakravarty]

Simon Marlow:

Manuel M T Chakravarty wrote:
To be honest, if you ask me, I'd go back to the old makefile based  
system and remove Cabal from everywhere except building of the  
library packages.


I wouldn't object to dropping the use of Cabal for other tools in  
the build tree; the reasons for using it elsewhere are certainly not  
as compelling as for packages.


Ian, I realise this means backing out a lot of the work you've been  
doing recently, and it would mean that we'd lose a lot of time in  
the runup to 6.10.1, but perhaps it's a step that we need to take to  
get us back on the right track again?


I do realise that this would mean backing out a lot of Ian recent  
work, and that's why I haven't proposed going back to the old system  
before you explicitly asked.  However, I am increasingly getting the  
feeling that the move to Cabal was pre-mature, and the overall loss  
will be minimised by backing out now.


In a sense, it was an interesting experiment and it should still be  
useful to the development of Cabal.  In fact, I see no reason why the  
experiment cannot be continued on a branch.  Who knows, maybe Cabal is  
sufficiently mature in a year to make a switch worthwhile?  I just  
object to using the whole GHC developer community as guinea pigs.


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Version control systems

[Manuel M T Chakravarty]

Ian Lynagh:
On Tue, Aug 12, 2008 at 10:20:14AM +1000, Manuel M T Chakravarty  
wrote:


To be honest, if you ask me, I'd go back to the old makefile based
system and remove Cabal from everywhere except building of the  
library

packages.

Manuel

PS: Just for some more collateral damage.  Did anybody check whether
the Mac OS installer support and the -unfortunately, only partially
working- support to compile for older OS X versions that I added to
the *makefiles* still works with the Cabal-based system?  I doubt it.
Took me quite a while to get all this going, and I am not very well
motivated to spend a lot of time to figure out how it might work with
Cabal.  IMHO using Cabal for anything but the libraries was a step
back for no good reason.


Do you mean the rebuilding the tools with stage2 stuff? If so,  
that's
an interesting example to pick, as that was the impetus behind  
changing

how the build system worked for all the non-libraries/ghc.


Rebuilding with stage1 was already needed to build GHC with a builtin  
readline.  In general, it is a bad idea to build distributed binaries  
of Haskell programs with the *bootstrap compiler*.  It must be done  
with the stage1 compiler.  (If you are unsure why, I'll happily  
elaborate.)


What I was mainly refer to is the building of GHC.framework with  
xcodebuild and the accompanying packing with packagemaker.  Building  
for older versions of Mac OS X requires the MACOSX_DEPLOYMENT_TARGET  
and related infrastructure.



Those changes made the build non-idempotent: we would build something
with the bootstrapping compiler, build some other stuff, then come  
back,

clean it, and build it again with the in-tree compiler. This was a
little annoying at the best of times, as e.g. rerunning make at the  
top

level would needlessly rebuild some stuff.

However, when my local changes meant that programs built by GHC
segfaulted, it was especially irritating to find that after  
(hopefully)

fixing the bug I couldn't just run make in compiler/ or rts/, because
ghc-pkg etc now just segfaulted!

It was at that point that I half-reverted the changes, and later I
reimplemented something similar using Cabal. Now we make, for example,
ghc-pkg with the bootstrapping compiler in utils/ghc-pkg/dist-inplace,
and then later on we make it with the stage1 compiler in
utils/ghc-pkg/dist-install.


It's of course much cleaner to build inplace versions of everything  
with the bootstrap compiler and separate distributeable versions with  
stage1.  I think we briefly talked about that during the run up to  
6.8.3.


To answer your actual question: No, not having OS X yet I haven't  
tested
it, but I did make an effort to keep it working. In mk/cabal- 
flags.mk we

say:

USE_STAGE_CONFIGURE_FLAGS = \
   ...
   $(addprefix --cc-option=,$(MACOSX_DEPLOYMENT_CC_OPTS)) \
   $(addprefix --ld-option=,$(MACOSX_DEPLOYMENT_LD_OPTS))

which will hopefully do the trick, and (IMO) in a much cleaner, more
maintainable way than would have been possible with the old build
system.


I appreciate that you tried to preserve it, but things like those  
usually don't work until explicitly tested and debugged.  I think this  
illustrates the issue I am having with the current process.  I don't  
think large changes that have not been properly tested should be  
committed to the head.  I appreciate that you cannot test everything  
for every patch and don't have all the platforms at hand.  That's why  
major rejigging of the build system should be done on a branch.  Then,  
you can ask other people to test it, once it is all working well for  
you.  Ripping the guts out of the head and leaving some of them on the  
floor just means everybody else is going to trip over them.


Manuel
 
 
___

Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Version control systems

[Manuel M T Chakravarty]

Simon Peyton-Jones:

2.  The version control system (VCS)

GHC needs core libraries without which it cannot be built.  It is
obviously highly desirable that a developer can build GHC with just
one VCS, which suggests that the core libraries should be in git too.
But those same core libraries are used by nhc98 and Hugs (I think
that's all), and the last thing we want to do is to impose new costs
on other implementations.


What are these costs?  I don't believe there are serious costs for  
those developers.  Malcolm told us that all he contributes to the core  
libraries is fixing them for nhc when they break.  He doesn't even  
validate, so I am sure he doesn't use branches or anything similar.   
The cost for him is to learn how to get, record  push with git.


AFAIK, the only person who works on Hugs is Ross.  He contributes to  
GHC, too, and hopefully validates his library patches before pushing.   
So, he'll have to learn to use git anyway.



It's unclear exactly what to do about this.  The most plausible
possibility is to keep the core libraries that are shared with other
implementations in darcs as now, and mirror them in git for GHC
developers.  That will impose pain on GHC developers to keep the git
stuff in sync with the darcs master copies; but at least other
developers would be unaffected.


Everybody who contributes to the boot/core libraries needs to validate  
their patches.  If the GHC version of the libraries is in git, then  
all library code needs to be validated against the git version of the  
libraries before it can enter the master repository.  I don't see how  
that makes anything easier for anybody.


As I said before, I believe there is exactly one sane solution: all  
boot libraries use the same vcs as ghc.


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Version control systems

[Manuel M T Chakravarty]

Malcolm Wallace:
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 am not advocating to move.  I am just saying, if ghc moves, every  
component needs to move on which the HEAD build depends and that is  
needed in its current development form (eg, *not* alex, happy, cabal).


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.


It is confusing and it is going to make matters worse as two failure  
points are worse than one.  And two extra tools to learn worse than one.


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?


It would be a pity to fork, but to be honest, I'd rather fork the libs  
than have to use two vcs for GHC.  The only other alternative is to  
decouple more library releases from ghc releases.


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Version control systems

[Manuel M T Chakravarty]

Jason Dagit:
On Sat, Aug 9, 2008 at 10:44 PM, Roman Leshchinskiy [EMAIL PROTECTED] 
 wrote:


Maybe investing some time in fixing the most obvious darcs problems  
would be a better solution?


We're working on that over at Darcs HQ, but there is no guarantee  
that we'd come close to fixing the problems within the 4-5 week  
window that Ian mentioned.  Supposing that the main problems GHC has  
with darcs 2 format get solved in the next month, would that give  
GHC reason enough to keep using darcs?  It seems many of you are  
eager to use git; perhaps even if darcs was working to satisfaction.


People will be working on making darcs work better with the GHC repo  
as a test case either way.  And personally, since I'm not a GHC dev,  
the decision doesn't affect my life.  Having said that, I'm still  
obviously biased.  I'd love for darcs to work well enough that this  
never came up.


Same here, and fwiw I won't change any of my many other darcs repos  
any time soon.


However, as I have said before, if ghc is to switch, it must be a  
clean switch, and no messy use of two vcs at the same time for ghc and  
boot libs.



Let me throw out one more idea:
What if, as a GHC contributor, I could pick equally between git and  
darcs?  My understanding is that, while not optimal, you could use  
tailor[1] to synchronize a darcs repository with a git one.  Offer  
up both repositories and keep them in sync.  Let the masses decide?


I don't think that this technical feasible.  I used tailor once to  
convert a CVS repo to darcs, and while that was better than throwing  
away the history, it was pretty messy and nothing that you would want  
to do on a regular basis.  Besides, even if the actual conversion  
would work smoothly (which I strongly doubt), you'd immediately be  
faced with problems of atomicity and associated race conditions of  
commits to the two repos.


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Version control systems

[Manuel M T Chakravarty]

Ian Lynagh:
On Sun, Aug 10, 2008 at 02:16:25PM +1000, Manuel M T Chakravarty  
wrote:

Duncan Coutts:


I don't especially relish having to learn another vcs tool or  
raising
the bar for contributions to Cabal either (we have lots of people  
who

make small one-off contributions).


I don't think it matters what vcs Cabal uses.  GHC does already for a
while use a separate repo for its version of Cabal, and the GHC Cabal
repo needs to be explicitly updated to ensure that changes to Cabal  
do

not randomly break GHC.  To be honest, if I had to say anything, I
would say that GHC has to uses fixed, stable versions of Cabal (like
it does of gmp).  So, it really doesn't matter what vcs Cabal uses.


Unless we do get to a point where we are literally using tarballs[1]  
of

Cabal, I don't think using a mixture of VCSs for Cabal is a good idea.
Having to convert patches from one VCS format to the other sounds  
like a

recipe for a lot of pain and suffering.

[1] which I think is a bad idea anyway, as it makes it a lot more  
hassle

to fix Cabal bugs that GHC+bootlibs expose.


The hassle that having two different repo types for Cabal head and  
Cabal GHC is part of the price of switching from darcs to git for  
ghc.  Incidentally, that you are concerned about Cabal devel in the  
GHC tree is a consequence out of using GHC as a guinea pig for Cabal  
development, which by itself is IMHO a Very Bad Idea.  Cabal is  
supposed to be a tool like Happy or Alex.  If Cabal *were* mature  
enough to be used in GHC's build system in the way it is now, GHC  
would just use the latest stable release of Cabal and we wouldn't have  
a problem.


So, let's please not use one bad idea (using an immature and  
constantly changing build tool whose use in GHC's build tree barely  
anybody understands) to justify another bad idea (using two vcs for  
one project).


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Version control systems

[Manuel M T Chakravarty]

Thomas Schilling:
I had my share of problems with Darcs;  working on the GHC API I  
constantly have to avoid conflicts.  My temporary workaround is to  
not update at all.  Maybe switching to Darcs 2 format would help  
here, but there are other issues.


I initially converted GHC to Git to be able to more easily checkout  
older versions (e.g., to find a build bug using git-bisect) but with  
external core libraries this just doesn't work.  Right now, there is  
simply no practical way to check out an old, building version of GHC!


Correct me if I am wrong, but this sounds as if you support my point  
that switching the GHC repo to git without doing the same for the core  
libs (in an integrated way) would not address the problems you  
experienced with darcs.


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Version control systems

[Manuel M T Chakravarty]

Duncan Coutts:

On Sat, 2008-08-09 at 15:46 +1000, Manuel M T Chakravarty wrote:


Raising the bar for developers to contribute to a project has been
proven to be a very bad idea many times.  Let's not take GHC down  
that

path.


I don't especially relish having to learn another vcs tool or raising
the bar for contributions to Cabal either (we have lots of people who
make small one-off contributions).


I don't think it matters what vcs Cabal uses.  GHC does already for a  
while use a separate repo for its version of Cabal, and the GHC Cabal  
repo needs to be explicitly updated to ensure that changes to Cabal do  
not randomly break GHC.  To be honest, if I had to say anything, I  
would say that GHC has to uses fixed, stable versions of Cabal (like  
it does of gmp).  So, it really doesn't matter what vcs Cabal uses.


A completely different matter are libraries like base which are deeply  
connected to GHC.


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Version control systems

[Manuel M T Chakravarty]

Ian Lynagh:
On Sat, Aug 09, 2008 at 03:46:50PM +1000, Manuel M T Chakravarty  
wrote:

I am not talking about all libs, I am talking about the core libs.
Most developers of the core libs are also GHC developers.


I'm not sure that's true. e.g. Malcolm and Ross both commit to the
bootlibs, and we get a lot of patches from various people in the
community.


Ross does commit patches to ghc (according to darcs changes).  So,  
either he stops that or has to learn git anyway.


I don't think we are talking about random contributions from the  
community.  If anything, we need to compare two numbers


(1) developers who need to start using git when the ghc repo changes and
(2) library developers (ie, people with commit bits regularly  
contributing to the boot libs) who do not contribute to ghc and hence  
could avoid learning git if the boot libs stay in a darcs repo.



I *strongly* object to moving to git before this isn't sorted out.


FWIW, personally I would prefer staying with darcs. I prefer its
underlying philosophy, and I find its UI far more intuitive and easy  
to

use.


Personally, I am more than happy to stay with darcs, too, but my  
understanding was that at least the Simons decided that we are going  
to move from darcs to git.  All I am saying is that whatever vcs ghc  
uses, you need to be able to *easily* get, modify, and commit patches  
to the HEAD and the boot libs with *just one* vcs.  Using two vcs is  
going to make the current situation worse, not better.


For example, SimonPJ said one reason for switching vcs is that interns  
had trouble getting started because they did have trouble obtaining  
the head as darcs caused them grief.  If the boot libs stay under  
darcs control.  Nothing is one, the same interns still won't get going  
any quicker.  Presumably, they are going to take even longer, because  
they can now get into trouble with darcs and git.


We want to lower the barrier to entry, not raise it.  By effectively  
adding a complications (namely git) and not removing any, matters will  
get worse.


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Version control systems

[Manuel M T Chakravarty]

Ian Lynagh:
On Fri, Aug 08, 2008 at 12:04:15PM +1000, Manuel M T Chakravarty  
wrote:


I seriously hope the plan is to move all *core* libraries (including
GHC's cabal repo) etc over to git, too.  In other word, everything
that you need to build the development version of GHC should come via
git.  Having a mix of VCSs would be the worst option of all.


No, the plan is to move only the GHC and testsuite repos to git, as  
the

others are also used by hugs, nhc98, etc.

It would be possible to move GHC's Cabal repo over too, as that is
private to GHC, but given the other libraries will be using darcs  
anyway

I think it is simpler to keep all darcs repos using the same VCS.


I think all *core* libraries must switch.  Seriously, requiring GHC  
developer to use a mix of two vcs during development is a Very Bad  
Idea.  Don was excited about getting more people to look at the source  
when it is in git (see the comments he posted from reddit).  By  
requiring two vcs you will get *less* people to look at the source.


This is not only to get the sources to hack them, but you effectively  
require developers to learn the commands for two vcs (when they are  
already reluctant to learn one).  For example, often enough somebody  
who changes something in GHC will modify the base package, too.  Then,  
to commit the overall work, you need to commit using both vcs.  If you  
need to branch for your work, you need to create branches in two vcs  
(no idea whether the semantics of a branch in git and darcs is  
anywhere similar).  When you merge your branch, you need to merge in  
both vcs.  You can't seriously propose such a set up!


Duncan wrote,

If there's some way of having automated git mirrors of the upstream
darcs repos then that's might be convenient for people building ghc.
Asking the maintainers of all other libs to switch is a bit much
though.


I am not talking about all libs, I am talking about the core libs.   
Most developers of the core libs are also GHC developers.  So, you ask  
them to change already by changing the vcs of GHC.  Asking them to  
work with two vcs at the same time is worse IMHO.


I *strongly* object to moving to git before this isn't sorted out.  As  
Roman said before, GHC is heading into a dangerous direction.  It gets  
progressively harder to contribute to the project at the moment.   
First, changing the build system to Cabal.  Now, proposing to use two  
vcs.  Somebody who is new to the project not only has to learn the  
internals of GHC, but they also have to learn two new vcs, and if they  
need to change the build system, they need to learn a new build tool.   
Raising the bar for developers to contribute to a project has been  
proven to be a very bad idea many times.  Let's not take GHC down that  
path.


Manuel
 
___

Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Version control systems

[Manuel M T Chakravarty]

Max Bolingbroke:

2008/8/6 Duncan Coutts [EMAIL PROTECTED]:

On Tue, 2008-08-05 at 22:12 -0700, Don Stewart wrote:

marlowsd:
Following lots of useful discussion and evaluation of the  
available DVCSs
out there, the GHC team have made a decision: we're going to  
switch to git.


Hooray, this will generate a lot of open source good will, and  
help make

GHC more accessible to the outside world.


Heh, you still need darcs to build it, because all the libs are using
darcs, and that's not going to change any time soon.


One thing that might be a good idea is setting up Git mirrors of the
libraries etc that we cannot convert to Git since other people depend
on them. This would give us nice integration with Gits submodule
support, allowing us to check out a consistent snapshot of the entire
tree (including the libraries, Cabal etc) at any point in time
straightforwardly. Of course, as a bonus you wouldn't have to install
Darcs to clone.


I seriously hope the plan is to move all *core* libraries (including  
GHC's cabal repo) etc over to git, too.  In other word, everything  
that you need to build the development version of GHC should come via  
git.  Having a mix of VCSs would be the worst option of all.


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC version 6.8.3 - Mac OS X, Intel/Leopard

[Manuel M T Chakravarty]

Ian Lynagh:

  =
   The (Interactive) Glasgow Haskell Compiler -- version 6.8.3
  =

The GHC Team is pleased to announce a new patchlevel release of GHC.
This release contains a number of bugfixes relative to 6.8.2, so we
recommend upgrading.


An installer package for Mac OS X, Intel/Leopard, is available at

  http://www.cse.unsw.edu.au/~chak/haskell/GHC-6.8.3-i386.pkg

The packages requires Xcode 3.0 to be already installed.  You can find  
Xcode 3.0 on your Leopard installation DVD (or at http://developer.apple.com 
.)


IF you installed one of the pre-release packages AND the final release  
package doesn't install properly, just remove the pre-release first by  
executing


  sudo /Library/Frameworks/GHC.framework/Tools/Uninstaller

(You can remove any other GHC installer package in the same way.)

Manuel

PS: I will post instructions on how to create a PPC/Leopard installer  
package in the next few days (unfortunately, the 6.8.3 release tar  
ball is not sufficient).  Package creation does not currently work for  
Tiger.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 6.8.3 Release Candidate - MacOS X (Intel/Leopard) installer, updated!

[Manuel M T Chakravarty]

Here is an updated release candidate for the MacOS X installer for  
Intel/Leopard:


  http://www.cse.unsw.edu.au/~chak/haskell/GHC-6.8.2.20080604-i386.pkg

It includes readline support statically linked.  Unless we receive any  
bug reports, these are basically the bits you'll get for the 6.8.3  
release.  So, please test it thoroughly.


Manuel

PS: I am not very hopeful about having a 10.4 (Tiger) version of the  
installer for 6.8.3.  I am currently missing a method to identify the  
symbols in an executable that lead to the bus error (invariably at  
_calloc_initialize) that signals an attempt to execute a Leopard  
binary on Tiger.  If any Mac guru here knows how to identify these  
symbols, let me know.  (I know about DYLD_PRINT_BINDINGS and friends,  
but that didn't help me so far.)  Alternatively, grab http://www.cse.unsw.edu.au/~chak/haskell/GHC-6.9.20080526-i386.dmg 
 -my currently best effort at cross-compiling for 10.4- and tell me  
why it won't run on Tiger.


Manuel M T Chakravarty:
A Mac installer version of the release candidate for Intel/Leopard  
Macs is at


 http://www.cse.unsw.edu.au/~chak/haskell/GHC-6.8.2.20080529-i386.pkg

This version of GHC includes neither editline nor readline at the  
moment (this will be fixed for the final release).  It also only  
works for Leopard (MacOS X 10.5) as I haven't managed to get cross  
compiling for older OS versions fully functional yet.


In any case, please test this if you have an Intel/Leopard Mac and  
are interested in a one-click installer with no dependencies other  
than a recent version of Xcode.


The packages comes with an uninstall script located at

 /Library/Frameworks/GHC.framework/Tools/Uninstaller

It will overwrite other 6.8.x versions of GHC installed from an  
installer package, but peacefully coexist with other distributions  
of 6.8 and with GHC versions other than 6.8 independent of how they  
were installed.


Manuel



We are pleased to announce the Release Candidate phase for GHC 6.8.3.

  Snapshots beginning with 6.8.2.20080527 are release candidates  
for 6.8.3


You can download snapshots from here:

  http://www.haskell.org/ghc/dist/stable/dist/

Right now we have the source bundles:

http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080527-src.tar.bz2
http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080527-src-extralibs.tar.bz2


Only the first of these is necessary. The extralibs package  
contains

various extra packages that are often supplied with GHC - unpack the
extralibs tarball on top of the source tree to add them, and they  
will

be included in the build automatically.

There is also currently an installer for i386/Windows and binary
distributions for x86_64/Linux and i386/Linux. More may appear later.

Please test as much as possible; bugs are much cheaper if we find  
them

before the release!

We expect to release in a few days, assuming no major issues are
discovered.


Thanks
Ian, on behalf of the GHC team

___
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


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 6.8.3 Release Candidate

[Manuel M T Chakravarty]

A Mac installer version of the release candidate for Intel/Leopard  
Macs is at


  http://www.cse.unsw.edu.au/~chak/haskell/GHC-6.8.2.20080529-i386.pkg

This version of GHC includes neither editline nor readline at the  
moment (this will be fixed for the final release).  It also only works  
for Leopard (MacOS X 10.5) as I haven't managed to get cross compiling  
for older OS versions fully functional yet.


In any case, please test this if you have an Intel/Leopard Mac and are  
interested in a one-click installer with no dependencies other than a  
recent version of Xcode.


The packages comes with an uninstall script located at

  /Library/Frameworks/GHC.framework/Tools/Uninstaller

It will overwrite other 6.8.x versions of GHC installed from an  
installer package, but peacefully coexist with other distributions of  
6.8 and with GHC versions other than 6.8 independent of how they were  
installed.


Manuel



We are pleased to announce the Release Candidate phase for GHC 6.8.3.

   Snapshots beginning with 6.8.2.20080527 are release candidates  
for 6.8.3


You can download snapshots from here:

   http://www.haskell.org/ghc/dist/stable/dist/

Right now we have the source bundles:

http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080527-src.tar.bz2
http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080527-src-extralibs.tar.bz2


Only the first of these is necessary. The extralibs package contains
various extra packages that are often supplied with GHC - unpack the
extralibs tarball on top of the source tree to add them, and they will
be included in the build automatically.

There is also currently an installer for i386/Windows and binary
distributions for x86_64/Linux and i386/Linux. More may appear later.

Please test as much as possible; bugs are much cheaper if we find them
before the release!

We expect to release in a few days, assuming no major issues are
discovered.


Thanks
Ian, on behalf of the GHC team

___
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: Type checker loops with innocent looking associated type synonym

[Manuel M T Chakravarty]

Stefan Holdermans:
Should I report this a bug? Or is it perhaps already been taken care  
of in the head?


Probably the latter.

But really as, Bulat wrote, type families in 6.8 are unsupported.   
Please test your code with a HEAD snapshot.  If that goes wrong, a bug  
report on Trac would be most appreciated.


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Inconsistent .hi files with associated types?

[Manuel M T Chakravarty]

Niklas,


=
$ runhaskell Setup build
Preprocessing library hsp-hjscript-0.3.4...
Building hsp-hjscript-0.3.4...
[1 of 1] Compiling HSP.HJScript ( HSP/HJScript.hs,
dist\build/HSP/HJScript.o )
C:\Program\Haskell\hsp-0.3.5\ghc-6.8.2/HSP/Monad.hi
Declaration for $f35
Unfolding of HSP.Monad.$f35:
 Can't find interface-file declaration for type constructor or class
HSP.Monad.:CoF:R32XML
   Probable cause: bug in .hi-boot file, or inconsistent .hi file
   Use -ddump-if-trace to get an idea of which file caused the error
C:\Program\Haskell\hsp-0.3.5\ghc-6.8.2/HSP/Monad.hi
Declaration for $f6
Unfolding of HSP.Monad.$f6:
 Can't find interface-file declaration for type constructor or class
HSP.Monad.:CoF:R5SetResult
   Probable cause: bug in .hi-boot file, or inconsistent .hi file
   Use -ddump-if-trace to get an idea of which file caused the error

C:\Program\ghc-6.8.2\bin\ar.exe: creating dist\build\libHShsp- 
hjscript-0.3.4.a

=


Could you check whether the problem also occurs with the current GHC  
6.9 (development version)?  There has been at least on bug that may  
cause this sort of problem been fixed in 6.9, which may not have been  
merged back to 6.8.  (Remember that we unfortunately cannot support  
type families (and hence associated types) fully in 6.8 - this has  
been discussed previously on this and/or the Haskell lists.)


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Bug or not-yet-supported?

[Manuel M T Chakravarty]

Niklas Broberg:

I haven't payed much attention to how much of type families is/should
be implemented for 6.8.2. What of equality constraints? The following
parses alright, but can't be used it seems.


module Foo where

class C a where
proof :: a

instance (a ~ Int) = C a where
proof = 1


% ghci -fglasgow-exts -XUndecidableInstances Foo.hs
GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
Loading package base ... linking ... done.
[1 of 1] Compiling Foo  ( Foo.hs, interpreted )
Ok, modules loaded: Foo.
*Foo proof :: Int
: panic! (the 'impossible' happened)
 (GHC version 6.8.2 for i386-unknown-mingw32):
   nameModule $dC{v aoz}

Please report this as a GHC bug:  http://www.haskell.org/ghc/ 
reportabug



I would follow that last advice if I knew this was *supposed* to  
work. :-)


It is supposed to work in 6.9.  I am sorry, but type families are not  
an officially supported feature in 6.8.x, and hence, any bug fixes  
that requires invasive changes in the type checker will not be merged  
into the 6.8 branch (and by now the 6.8 and 6.9 code bases diverged  
quite a bit).  This is simply to ensure the stability of the stable  
branch.  Type families will be properly supported in 6.10.


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Tiger installer [was: Re: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)]

[Manuel M T Chakravarty]

Christian Maeder:

Manuel M T Chakravarty wrote:

Christian Maeder:

export MACOSX_DEPLOYMENT_TARGET=10.4


Specifically, I am seeing

 dyld: bind: ghc-6.9.20080219:_fcntl$UNIX2003$lazy_ptr =
libSystem.B.dylib:_fcntl$UNIX2003, *0x0108a413 = 0x92c7b7bc


what tells you that this is Leopard specific?


http://lists.apple.com/archives/darwin-dev/2007/Nov/msg00108.html


 -optl-isysroot -optl/Developer/SDKs/MacOSX10.4u.sdk
-optl-mmacosx-version-min=10.4


Interesting, in contrast to you I had a problem with
-mmacosx-version-min and had to use MACOSX_DEPLOYMENT_TARGET when
building user programs on Leopard using my Tiger bindist.

http://www.haskell.org/pipermail/glasgow-haskell-users/2008-January/014093.html


I made a similar observation.  Using -syslibroot in addition, fixed  
the problem for me.



-optl-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk

on all CC and LD targets, I don't seem to have any Leopard symbols
anymore.  FWIW, Xcode 3.0 also seem to use explicit SDK options.


I haven't built ghc on Leopard, yet, but I'll expect to use -isysroot
and -syslibroot then, too.


Hold off another day or two and you get that automatically by just  
using --with-macos-deployment-target=10.4 with GHC's ./configure.   
(This will even enable you to generate a GHC build for 10.4 from a  
bootstrap compiler for 10.5, which is non-trivial due to the programs  
in utils/ and some other stuff.)


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Tiger installer [was: Re: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)]

[Manuel M T Chakravarty]

Christian Maeder:

Manuel M T Chakravarty wrote:

$ ./HelloWorld-Tiger
Hello World!
$ ./HelloWorld-Leopard
Bus error


only setting

 export MACOSX_DEPLOYMENT_TARGET=10.4

on Leopard during compilation should make it run on a Tiger, too.


I tried that, too, but it somehow only works partially.  If I build  
ghc with that environment setting, the GHC binary still has some  
Leopard symbols in it (though much less than without that setting).   
Specifically, I am seeing


  dyld: bind: ghc-6.9.20080219:_fcntl$UNIX2003$lazy_ptr =  
libSystem.B.dylib:_fcntl$UNIX2003, *0x0108a413 = 0x92c7b7bc


on running

  env DYLD_PRINT_BINDINGS= compiler/stage2/ghc-6.9.20080219

Any idea why that may be?  In contrast, if I instruct GHC's build  
system to use


  -optl-isysroot -optl/Developer/SDKs/MacOSX10.4u.sdk -optl-mmacosx- 
version-min=10.4 -optl-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk


on all CC and LD targets, I don't seem to have any Leopard symbols  
anymore.  FWIW, Xcode 3.0 also seem to use explicit SDK options.


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC build failures on Mac OS X Leopard: ppc x86

[Manuel M T Chakravarty]

Sean Leather:

I tried to build GHC stable on my two computers, a PowerBook G4 and
a MacBook, both running 10.5.2. This is the first time I've ever
tried, so I'm somewhat clueless about a lot of it. I went with the
basic instructions (./configure; make) with no 'mk/build.mk' and no
configure options other than '--prefix'.

[..]

The MacBook build apparently completed stage1 and failed in trying to
build stage2 (i.e. -o stage2/ghc-inplace).


I can't help you with the PPC, but on the MacBook try building with

  make EXTRA_AR_ARGS=-s

It's a known bug with Cabal.

Manuel



 x86 build output


../compiler/stage1/ghc-inplace -no-user-package-conf -cpp
stage2/ghc-inplace.c -o stage2/ghc-inplace

ld: in /Users/leather/Projects/ghc-stable/ghc/libraries/haskell98/ 
dist/build/libHShaskell98-1.0.1.0.a,

archive has no table of contents

collect2: ld returned 1 exit status

make[2]: *** [stage2/ghc-inplace] Error 1
make[1]: *** [stage2] Error 2
make: *** [bootstrap2] Error 2

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC build failures on Mac OS X Leopard: ppc x86

[Manuel M T Chakravarty]

Sean Leather:

Manuel M T Chakravarty:

I can't help you with the PPC, but on the MacBook try building with

  make EXTRA_AR_ARGS=-s

It's a known bug with Cabal.


Thanks, Manuel, it builds now.

Afterwards, I ran 'make' in 'testsuite/tests/ghc-regress' and got  
this:


OVERALL SUMMARY for test run started at Mon Feb 18 17:55:20 CET 2008
   2084 total tests, which gave rise to
  10640 test cases, of which
  0 caused framework failures
   2160 were skipped

   7487 expected passes
372 expected failures
  0 unexpected passes
621 unexpected failures

That seems like a large number of unexpected failures; however, I
haven't seen a summary from a build of Mac OS X on x86, so I don't
know what to expect.

At a glance, many of the failures refer to ghci (at least that's what
I assume the (ghci) next to the name means). Here is a sample:


I haven't run the full test suite on the 6.8 branch.  Try

  make Validating=YES fast stage=2 CLEANUP=1

That should go through (sometimes when test outputs changes due to  
changes on the HEAD), it takes a while until the tests are adapted to  
expect different outputs for 6.8.


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: problems with ghc-6.8.2-powerpc-apple-darwin.tar.bz2 from GHC home page

[Manuel M T Chakravarty]

Christian Maeder:

Chris Kuklewicz wrote:

The ./setup build causes a segmentation fault.  This is for every
project I try (including ones with very default Setup.hs contents).


I can at least reproduce the segmentation fault by running my PPC- 
Tiger

binary on an i386-Leopard, by compiling with additional options
-optc-arch -optcppc -opta-arch -optappc -optl-arch -optlppc.

m29:fastcgi-3001.0.1 maeder$ ghc -opta-arch -optappc -optl-arch - 
optlppc

--make Setup.lhs
Linking Setup ...
m29:fastcgi-3001.0.1 maeder$ ./Setup configure
Configuring fastcgi-3001.0.1...
Warning: No license-file field.
m29:fastcgi-3001.0.1 maeder$ ./Setup build
Segmentation fault


I can't see how ghc can generate a correct executable if you pass  
these cross-compilation options to GHC.  Even if you can get GHC to  
generate proper PPC code, it will link against *Haskell* libraries  
that contain i386 code.  (The options -optl-arch -optlppc will give  
you the PPC versions of the system libraries, but not the GHC  
packages.)  Or am I missing something?



and even (after adding the above options to the bin/ghc-6.8.2 script)

m29:fastcgi-3001.0.1 maeder$ runghc Setup.lhs build
Preprocessing library fastcgi-3001.0.1...
Building fastcgi-3001.0.1...
[1 of 1] Compiling Network.FastCGI  ( dist/build/Network/FastCGI.hs,
dist/build/Network/FastCGI.o )
ar: creating archive dist/build/libHSfastcgi-3001.0.1.a
ld: atom sorting error for
_fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuStream_closure_tbl and
_fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuRequest_closure_tbl in
dist/build/Network/FastCGI.o
ld: atom sorting error for
_fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuStream_closure_tbl and
_fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuRequest_closure_tbl in
dist/build/Network/FastCGI.o


According to Wolfgang Thaller's answer to a previous post by yourself,  
these atom sorting errors are harmless:


  
http://www.haskell.org/pipermail/glasgow-haskell-users/2008-January/013988.html

Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)

[Manuel M T Chakravarty]

Chris Kuklewicz:

Manuel M T Chakravarty wrote:
The above package is for Intel Leopard.  I expect that a separate  
PPC version is easy to build (but cross-compilation and fat  
binaries are not supported by GHC).


I have not seen any announcement that GHC 6.8.x is working on OS X  
Leopard running on PPC.  I would be pleased to be corrected.


Sorry, but my statement was only wrt to the mechanism used to build  
installer packages.  If general compilation problems still persist,  
they will prevent you from constructing installer packages as well.   
(I haven't got a PPC, so I didn't keep track of that.)


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Tiger installer [was: Re: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)]

[Manuel M T Chakravarty]

The above package is for Intel Leopard... it should be possible to
build packages on Leopard that run on both Tiger and Leopard.  (I
could give that a try if anybody with a Tiger box is willing to play
guinea pig.)


I volunteer. What do I need to do?



Try this
  http://www.cse.unsw.edu.au/~chak/haskell/GHC-6.9.20080213-i386.dmg

It's a quick build of todays HEAD with only the boot libraries.  Have  
a look whether that installs on Tiger (I am pretty sure it will) and  
whether you can run /usr/bin/ghci (not so sure about that).  If it  
works that far, please compile some small Haskell program and see  
whether you can run the compiled program.  If we are very lucky and  
all of this works, please try to compile ghc itself with the compiler  
in the package.


Thanks,
Manuel

PS: It's a dmg this time around, because apparently only 10.5 packages  
are single file archives.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)

[Manuel M T Chakravarty]

Ladies and Gentlemen,

Finally, you can have the glorious GHC in a format satisfying the  
discerning Mac user:


  http://www.cse.unsw.edu.au/~chak/haskell/GHC-6.8.2.20080211-i386.pkg

Installation instructions: nil

This is *not* the same compiler as in the official 6.8.2 release.  It  
is the state of the 6.8 branch at the 11th of February - hence, the  
funny version number.  Once, 6.8.3 is being released, there'll be a  
clean release package.


The package includes all extra libraries and full documentation.  It  
installs GHC systemwide and requires an admin password.


Happy Installing!
Manuel

-=- Extra details for the curious -=-

GHC is being packaged as a framework bundle - GHC.framework - that is  
installed in /Library/Frameworks/.  As far as I can tell this is the  
most appropriate way of bundling a compiler environment on the Mac.   
Frameworks are versioned and we use GHC's integer version number to  
assign framework versions - ie, the present package installs version  
608.  This is in line with Apple's recommendation to use version  
numbers that signify API changes for frameworks.  The package installs  
appropriate links in /usr/bin, /usr/man/man1, and /usr/share/doc to  
make the binaries, ghc manpage, and html documentation easily  
accessible.  Furthermore, it comes with a shell script that removes  
the GHC.framework and all symbolic links into the framework.


The framework is currently not relocatable and an admin password is  
needed to install it.  Contributions improving this situation would be  
most welcome.


The GHC binary in the package links statically against GNU readline  
(to provide editing capabilities at the GHCi prompt).  This is fine as  
GHC's BSD3 licence is compatible with readline's GPL, and it does  
*not* affect programs compiled with GHC at all.


The above package is for Intel Leopard.  I expect that a separate PPC  
version is easy to build (but cross-compilation and fat binaries are  
not supported by GHC).  I am less sure about building packages on  
Tiger as I don't know whether the underlying Xcode project requires  
Xcode 3.0 - Tiger only has 2.5.  However, it should be possible to  
build packages on Leopard that run on both Tiger and Leopard.  (I  
could give that a try if anybody with a Tiger box is willing to play  
guinea pig.)


Further information on GHC installer packages as well as instructions  
on how to build your own are at


  http://hackage.haskell.org/trac/ghc/wiki/Building/MacOSX/Installer
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)

[Manuel M T Chakravarty]

Don Stewart:

Great!

Does this mean we can submit GHC to be distributed from Apple's
hackage, http://www.apple.com/downloads/ ?  (Click the Submit  
Downloads button).


Yes, I was thinking about that, too.  However, I think we should wait  
until 6.8.3 and until we have a stable download url for the package.   
I'd also be nice to have a cool logo/icon.


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Bootstrapping for Leopard

[Manuel M T Chakravarty]

Things are complicated because

 - on Cygwin, pwd gives you /cygdrive/c/...
 - on MSYS, pwd gives you /c/...

(remember we still support MSYS), and we want c:/...

So we used to use cygpath on cygwin, and some horrible sed command  
on MSYS, IIRC.  It was a mess, and frequently went wrong.


Sure there are other ways to do it, but I think at the time it  
seemed simpler to write a Haskell program.  In hindsight, probably a  
C program (compiled using mingw gcc) would be better for  
bootstrapping.  A shell script would be problematic for the reasons  
above, I'm guessing.


I understand that this is a difficult issues, but as it is booting  
from HC files and hence porting is simply broken.  So, I wonder what  
the way forward is...


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Bootstrapping for Leopard

[Manuel M T Chakravarty]

Philip K.F. Hölzenspies:
I'm trying toupdate the Portfile so that ghc-6.8.2 can be built  
using MacPorts

(handy for installing other ghc-dependent material from MacPorts like
gtk2hs). The problem seems to be that the available bootstrap binary
http://www.haskell.org/ghc/dist/6.6/ghc-6.6-i386-apple-darwin-bootstrap.tar.bz2
causes a segfault on Leopard (below are the steps I took in my  
attempt to

build ghc with this bootstrap binary).

Using Manuel Chakravarty's binary distribution of ghc-6.8.1-i386- 
apple-darwin
building ghc-6.8.2 works fine. It seemed to me that the easiest way  
to fix

the bootstrap problem is to boot from C as described on the wiki
(http://hackage.haskell.org/trac/ghc/wiki/Building/Porting). Two  
things were

wrong, however.

make hc-file-bundle

Making the hc-file-bundle target failed, because not all rts/*.cmm had
rts/*.hc counterparts after the build. The make fails because of this
fragment from the Makefile (part of the hc-file-bundle target,  
starting from

line 513):

for f in `$(FIND) ghc-$(ProjectVersion)/compiler
ghc-$(ProjectVersion)/rts -name *.cmm -follow -print` ; do \
 if test x$$f !=3D x; then \
   echo `echo $$f | sed 's/cmm$$/hc/g' `  hc-files-to-go ; \
 fi; \
done;

This adds some non-existing .hc files to the hc-files-to-go list  
that tar will
not find, later on, causing an error. I just added a test to see  
whether the
file exists. If it does not, I call make for that .hc file  
explicitly, which
solves the problem for most files. The files that don't have a make  
target, I
simply omitted from the hc-files-to-go. I haven't been able to test  
the

severity of this, because of the second problem.


I am not sure what the problem is here.  Simon?  Ian?


checking for ld... /usr/bin/ld
checking for path to top of build tree... ./configure: line 2651: - 
v0: command

not found
./configure: line 2655: utils/pwd/pwd: No such file or directory
configure: error: cannot determine current directory

Upon inspection of the configure script, I found out that line 2651  
uses the

variable designating the ghc compiler.


This is due to a change of the configure stage that AFAIK was made to  
easy building on windows.  Instead, of using shell commands/scripts  
(as GHC did previously) to obtain some configuration information (here  
the file path at which the top of the GHC build tree is located), the  
build system now uses small Haskell programs/scripts.  This makes the  
build more portable ** if there is already a Haskell compiler on the  
system **.  It however messes everything up if you want to build from  
HC files (and so don't have a Haskell compiler).  I am not sure  
whether anybody thought about this problem when the change to using  
Haskell scripts instead of shell scripts was made.  Ian?  Simon?


The only solution that I see is to replace the Haskell scripts by  
vanilla shell scripts in HC bundles.  Even if that causes problems on  
windows (without cygwin), it would make HC bundles viable on Unix  
systems again.


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Integrating editline with ghc

[Manuel M T Chakravarty]

Christian Maeder:

Manuel M T Chakravarty wrote:

Christian Maeder:
1. a _new_ readline package that only contains the interface that  
can be
implemented using libeditline _or_ libreadline. If this package is  
call
readline (with a new version number) most libraries i.e. like  
Shellac

would not need modifications.


I disagree.  Readline should stay as it is.  (Why force existing
readline users who use functionality not supported by editline's
emulation layer to change the package they are using?)


Your point is also supported by Yitz Gale, my point by Malcolm.

Where are the users that use the functionality not supported by
editline's emulation layer? (Shout now or be quiet ever after)


Are you seriously suggesting that we mess up users who do not read the  
various mailing lists constantly to defend the APIs they are using?


Manuel
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Re[4]: bindist for Intel MacOS X 10.4 (Tiger) with static libs

[Manuel M T Chakravarty]

Yitzchak Gale:

Bulat Ziganshin wrote:

for me, GMP is much more problematic issue. strictly speaking, we
can't say that GHC is BSD-licensed because it includes LGPL-licensed
code (and that much worse, it includes this code in run-time libs)


Manuel M T Chakravarty wrote:

..binary distributions of GHC that include libgmp.a and statically
link it into compiled code...  All
that is needed to make this legal is to (a)...
(b) give users access to another version of
the proprietary program that links GMP dynamically.


Wow, I didn't realize that. Now I understand Bulat. In a
project of any serious size and complexity, the use
of static or dynamic linking is often architechted in and
cannot be changed. So LGPL is really bad for a general
purpose compiler like GHC. We've got to make GMP
optional, or get rid of it.


Well, I think you misunderstood what I was trying to say.

My point is that the LGPL is *no* reason to worry.  As Isaac wrote,  
there are a number of ways in which a vendor of a proprietary program  
can successfully work with LGPL'ed code.  My proposal of providing a  
dynamically linked version of the software as an option is just one of  
these ways (which I think is especially easy to realise).  Other ways  
include distributing the dynamically linked binary in the first place  
and providing access to .o file to link with a different version of  
the library (as Isaac outlined).  BTW, when I write dynamically linked  
binary I mean a binary that links dynamically to the LGPL'ed code (ie,  
here GMP).  All other libraries can still be linked statically.


As a case in point for my argument, please consider Apple.  Mac OS X  
contains a lot of GPL'ed and LGPL'ed code.  Now you can argue that  
that's a simpler situation because it's a whole OS and many of the  
programs with GNU licenses are standalone, such as gcc.  Now just for  
fun, go to your nearest Apple store, grab an ipod touch and have a  
look at its Copyright menu.  There is lots of LGPL'ed code in there,  
too.  I am sure they had a trillion lawyers making sure that they  
comply with the licence terms, so that the FSF is not going to come  
after them.


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Integrating editline with ghc

[Manuel M T Chakravarty]

Alex Young:

Yitzchak Gale wrote:

Isaac Dupree wrote:

GHC is in no legal trouble whatsoever... only if proprietary Haskell
code uses the readline library and doesn't switch to using the  
editline

backend.

Agreed. I didn't mean that GHC itself was ever in any
legal trouble. But as a compiler, it must be possible for
users to compile with it without getting into legal trouble.


Yes.  I'm still learning Haskell, and it's my intention to use GHC  
to produce commercial plugins for an application on Windows (and  
possibly OS X, haven't decided yet).  This whole discussion makes me  
worry - not because I have any intention to break any licences, but  
because I might do so by accident.  At this point in my learning,  
I've got no idea what will cause problem packages (problems from  
my point of view being ones that cause a phone call to a lawyer) to  
be linked in to my binaries.  It would be enormously helpful if  
there was a wiki page somewhere that said To use GHC/mingw as a  
compiler for commercial software, it's likely you want to avoid  
these modules and command-line flags or alternatively To guarantee  
that no LGPL or GPL libraries are linked, use these flags.


The last thing I want is to cause myself extra work when someone  
chucks my plugin through a hex editor, sees a whole load of GMP  
symbols (for example) and demands some form of compliance that  
commercially I'd rather avoid.


The Haskell package system Cabal has a package description format that  
includes an entry stating the packages license.  You can browse  
packages at


  http://hackage.haskell.org/packages/hackage.html

and the package entries include the license field.  For example, the  
entry for readline


  http://hackage.haskell.org/cgi-bin/hackage-scripts/package/readline-1.0.1.0

says it is GPL'ed - ie, you may not link it into proprietary code.

I agree that a wiki page explaining this and the situation with static  
versus dynamic linking of LGPL'ed code would be helpful.


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Integrating editline with ghc

[Manuel M T Chakravarty]

Christian Maeder:

Judah Jacobson wrote:
- System.Console.Editline.Readline contains the readline APIs  
provided

by the editline library (mostly a cut/paste of
System.Console.Readline).


I would like to see a restructuring of the old readline
package:

1. a _new_ readline package that only contains the interface that  
can be
implemented using libeditline _or_ libreadline. If this package is  
call
readline (with a new version number) most libraries i.e. like  
Shellac

would not need modifications.


I disagree.  Readline should stay as it is.  (Why force existing  
readline users who use functionality not supported by editline's  
emulation layer to change the package they are using?)


Instead, we should have a new module whose interface coincides with  
editline's readline emulation.  Everybody who wants to use editline  
when available and readline only if editline is not available can then  
use that new module (which I called EditReadline in my previous  
post).  GHC will be one of these programs.


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: gmp

[Manuel M T Chakravarty]

Yitzchak Gale:

OK for the time
being, but it would be really, really good to be able to compile
ghc without gmp.


Well, just go ahead and write an alternative portable  high- 
performance implementation of Integer.



This idea of a Mac OS X binary with statically-linked
gmp is nice, it is really convenient. But someone needs
to completely clarify the license issues in that case, and
make it completely clear to all users.


I completely agree that we need to document the situation clearly.   
Otherwise, I don't really see what the fuss is about.  Most GHC users  
don't care whether GMP is linked into their code (as its either only  
used internally or has a GPL-compatible license anyway).


If a company wants to distribute GHC compiled binaries of non-GPL  
compatible code, well, they have to compile their own version of GHC  
on the Mac that links GMP dynamically, and then, use that version of  
GHC to link their final product.  That is going to be a trivial task  
compared to developing that product in the first place.  So, who cares?


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: bindist for Intel MacOS X 10.4 (Tiger) with static libs

[Manuel M T Chakravarty]

Thorkil Naur:

Hello,

On Tuesday 08 January 2008 15:07, Christian Maeder wrote:

Hi,

I've succeeded in building a binary distribution that uses static
libraries for gmp and readline. libreadline.a, libncurses.a and  
libgmp.a

with corresponding header files are included. (For license issues ask
someone else.)


On http://gmplib.org/ we find:

GMP is distributed under the GNU LGPL. This license makes the  
library free to
use, share, and improve, and allows you to pass on the result. The  
license
gives freedoms, but also sets firm restrictions on the use with non- 
free

programs.

I have not attempted to check whether your distribution fulfills the
requirements of the LGPL.


It does fullfil them.  The source code of all components of the system  
is available enabling users to build the same software with a  
different version of GMP.  That's all that the LGPL requires of  
software linked against a LGPL library.


Further, on http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html:

Readline is free software, distributed under the terms of the GNU  
General
Public License, version 2. This means that if you want to use  
Readline in a
program that you release or distribute to anyone, the program must  
be free

software and have a GPL-compatible license.

For your distribution to adhere to this, it appears to require GHC  
to have a

GPL-compatible license. I don't believe it does.


It does.  GHC's codebase is a mix of BSD3, LGLP, and GPL.  They are  
perfectly compatible.  See http://www.fsf.org/licensing/licenses/index_html 
.


Manuel
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Re[4]: bindist for Intel MacOS X 10.4 (Tiger) with static libs

[Manuel M T Chakravarty]

Bulat Ziganshin:

for me, GMP is much more problematic issue. strictly speaking, we
can't say that GHC is BSD-licensed because it includes LGPL-licensed
code (and that much worse, it includes this code in run-time libs)


Of course, GHC is BSD3 licensed.  It includes the GMP code as part of  
its tar ball to save people from the hassle to separately install GMP  
on platforms that don't have it by default (ie, essentially all non- 
Linux OSes). That doesn't change the license of GHC at all.  It is a  
mere aggregation of different projects.


Even binary distributions of GHC that include libgmp.a and statically  
link it into compiled code are not a problem.  You may even use such  
GHC distributions to compile proprietary code and distribute it.  All  
that is needed to make this legal is to (a) properly acknowledge the  
use of GMP in the code and (b) give users access to another version of  
the proprietary program that links GMP dynamically.  Point (b) is  
sufficient to comply with Section 4(d) of the LGPL, which requires you  
to enable users to swap one version of GMP for another in a program  
that uses GMP.


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Integrating editline with ghc

[Manuel M T Chakravarty]

Judah Jacobson:

Hackage link: 
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/editline-0.1
Haddock: http://code.haskell.org/editline/dist/doc/html/editline/

As I've mentioned before, there are two independent modules:
- System.Console.Editline is a very basic (and experimental) interface
to the native editline APIs.
- System.Console.Editline.Readline contains the readline APIs provided
by the editline library (mostly a cut/paste of
System.Console.Readline).

Currently I'm using just the latter as a drop-in replacement for
System.Console.Readline in ghci.  I have added a --with-editline flag
to ghc's configure script, which has no effect if it's not specified,
and otherwise does the following:

- Throw an error (at configure time) if editline isn't present (as
$hardtop/libraries/editline)
- Use the editline package instead of readline when building ghc  
stage 2

- Use CPP to make InteractiveUI.hs (the main ghci loop) import
System.Console.Editline.Readline instead of System.Console.Readline.

Does that sound like the right way to handle this?  If so, I'll send a
darcs patch.


Sounds good to me.

Also, should editline be made a boot-package or an extra-package (or  
neither)?


Given that we like this to be the default on some platforms, I believe  
it belongs into boot-packages (just like readline).


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: readline package with libedit

[Manuel M T Chakravarty]

Judah,

I completely agree that, at the least on the Mac, using editline is  
the best solution (as long all necessary functionality is supported).


I am wondering, though, whether you are testing on Tiger or Leopard.   
When looking at the readline-emulation API of editline after upgrading  
to Leopard, I had the impression that it included much more  
functionality than it did on Tiger.


Manuel

On Jan 9, 2008 12:59 AM, Christian Maeder [EMAIL PROTECTED]  
wrote:


By the way I've the following lines in my ~/.ghci
from
http://hackage.haskell.org/trac/ghc/ticket/998

:m +System.Console.Readline Data.List
getCompleterWordBreakCharacters = setCompleterWordBreakCharacters .
Data.List.delete '/'
:m -System.Console.Readline Data.List

Does this work with libedit, too?

Christian


Hm... It runs, but doesn't have any effect.  It looks like you need to
use setBasicWordBreakCharacters instead of
setCompleterWordBreakCharacters.  (ghci sets both, which is why I
didn't notice this before.)

Note that with my fix to #998 (sent to cvs-ghc), that hack should no
longer be necessary.

-Judah


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users