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 :
> 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 :
> 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=closed&status=merge&status=patch&milestone=7.8.3&group=resolution&col=id&col=summary&col=owner&col=type&col=priority&col=component&col=version&order=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 :
> |  > 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 Marlow :
> 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 mailto:johan.tib...@gmail.com>>:
>>> On Fri, Feb 8, 2013 at 6:28 AM, Simon Marlow >> <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]

Simon Peyton-Jones :
> 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]

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 :
> On Fri, Feb 8, 2013 at 6:28 AM, Simon Marlow  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 :
> 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 :
>> 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 :
> 2012-08-26 08:03, Manuel M T Chakravarty skrev:
>> Emil Axelsson :
>>> 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 :
> 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 :
> 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]

Bryan O'Sullivan :
> On Mon, Jun 18, 2012 at 9:32 PM, John Lato  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

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 :
> 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

[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" 
> Betreff: Re: GHC, Clang & XCode 4.2
> Datum: 15 October 2011 12:32:36 
> An: Manuel M T Chakravarty 
> 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 
> Sender: glasgow-haskell-users-boun...@haskell.org
> Date: Thu, 13 Oct 2011 13:11:40 
> To: Simon Marlow
> Cc: GHC Users Mailing List
> 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: 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 IM

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: 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: 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 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 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,

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: GHC HEAD broken on OS X

[Manuel M T Chakravarty]

See http://www.haskell.org/pipermail/cvs-ghc/2011-June/063399.html

austin seipp:
> After doing a 'git pull origin master && ./sync-all pull origin
> master', I get the following build failure when stage1 attempts to
> compile the RTS code:
> 
> http://paste.debian.net/121097/
> 
> A quick glance at the errors seem to indicate this work is related to
> the new events stuff for GHC. Duncan was working on this last I think
> - is anybody else experiencing this failure?
> 
> -- 
> Regards,
> Austin
> 
> ___
> 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]

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]

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 v

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  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: GHC on Snow Leopard: best practices?

[Manuel M T Chakravarty]

Barney Stratford:
So far, the sticking point has been getting the interactive linker  
to work. Snow Leopard has much tighter security than its  
predecessors, so we have to use mmap. Unfortunately, the mmap  
version of GHC's linker also requires mremap, which is a Linux-only  
extension that Snow Leopard doesn't have.


Did you mean to say that Snow Leopard in 64-bit mode has tighter  
security?  After all, a Leopard-compiled 32-bit version of ghci works  
just fine on SL.


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  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  [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=new&status=assigned&status=reopened&priority=high&priority=highest&milestone=6.10.2&order=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/").  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/").  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: "dataflow rewriting engine"

[Manuel M T Chakravarty]

Deborah Goldsmith:
Has there been any thought about working with the LLVM project? I  
didn't find anything on the wiki along those lines.


I have only had a rather brief look at LLVM, but my understanding at  
the moment is that LLVM would not be able to support one of GHC's  
current code layout optimisations.  More precisely, with LLVM, it  
would not be possible to enforce that the meta data for a closure is  
placed right before (in terms of layout in the address space) the code  
executing the "eval" method of that same closure.  GHC uses that to  
have the closure code pointer point directly to the "eval" code (and  
hence also by an appropriate offset) to the various fields of the meta  
data.  If that layout cannot be ensured, GHC needs to take one more  
indirection to execute "evals" (which is a very frequent operation) -  
this is what an unregistered build does btw.


However, I am not convinced that this layout optimisation is really  
gaining that much extra performance these days.  In particular, since  
dynamic pointer tagging, very short running "evals" (for which the  
extra indirection incurs the largest overhead) have become less  
frequent.  Even if there is a slight performance regression, I think,  
it would be worthwhile to consider giving up on the described layout  
constraint.  It is the Last Quirk that keeps GHC from using standard  
compiler back-ends (such as LLVM), and I suspect, it is not worth it  
anymore.


When we discussed this last, Simon Marlow planned to run benchmarks to  
determine how much performance the layout optimisation gains us these  
days.  Simon, did you ever get around to that?


Manuel



On Aug 26, 2008, at 10:57 AM, Don Stewart wrote:


I think we're all rather excited about seeing this stuff land.
What's the expected timeline, wrt. ghc 6.10's release?

-- Don

t-jodias:

I've added some text and links to point the reader in the right
direction. Here's the new text, cribbed from the Wiki:

Dataflow optimization: We can define a new optimization simply by
defining a lattice of dataflow facts (akin to a specialized logic)  
and

then writing the dataflow-transfer functions found in compiler
textbooks. Handing these functions to the dataflow engine produces a
new optimization that is not only useful on its own, but that can
easily be composed with other optimizations to create an integrated
"superoptimization" that is strictly more powerful than any sequence
of individual optimizations, no matter how many times they are re- 
run.

The dataflow engine is based on (Lerner, Grove, and Chambers 2002
http://citeseer.ist.psu.edu/old/lerner01composing.html); you can  
find

a functional implementation of the dataflow engine presented in
(Ramsey and Dias 2005
http://www.cs.tufts.edu/~nr/pubs/zipcfg-abstract.html).

Let me know how I can further clarify the text,
-j


-Original Message-
From: Simon Peyton-Jones
Sent: Tuesday, August 26, 2008 1:32 PM
To: Norman Ramsey; John Dias
Cc: Chad Scherrer; GHC Users
Subject: RE: "dataflow rewriting engine"

Norman, John

Would you care to respond to this? (Perhaps by amplifying the wiki
page?)  A good starting point is perhaps Craig's paper.

Simon

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:glasgow-
[EMAIL PROTECTED] On
| Behalf Of Chad Scherrer
| Sent: 22 August 2008 22:21
| To: GHC Users
| Subject: "dataflow rewriting engine"
|
| Hello GHC,
|
| This page
|
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Integrated
CodeGen
| mentions a to-be-developed "dataflow rewriting engine". Can  
someone

| please send a description of what this will do?
|
| Thanks!
| --
|
| Chad Scherrer
|
| "Time flies like an arrow; fruit flies like a banana" --  
Groucho Marx

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


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

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]

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]

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]

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]

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]

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]

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]

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 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, I completely agree with you.  I love the darcs vcs model, too.   
However, we have three discussions here:


(1) Do we want darcs vcs model?

Except Thomas Schilling, who seems to be dead set to get rid of  
darcs, everybody who voiced their opinion seems to be in favour of the  
darcs model.


(2) Is the current implementation of darcs up to a project the size of  
ghc?


Due to problems in the past & performance regressions with  
darcs2, a serious number of (important) people believe that the  
current implementation is not good enough.


(3) If we change the vcs for the ghc repo, do we change the vcs for  
the boot libs, too.


This is just an open-source project maintenance question.  It has  
nothing to do with which vcs is better.


This is the only point I have been arguing: *if* GHC's repo  
changes, all boot lib repos must change, too.


Manuel

Ian Lynagh:

On Sun, Aug 10, 2008 at 08:17:50PM -0400, Norman Ramsey wrote:

On Sat, Aug 09, 2008 at 06:56:23PM -0400, Norman Ramsey wrote:



personally I would much prefer to see money spent on making darcs
better, for reasons I won't repeat again.


I missed them and wouldn't mind receiving a private note.


OK, I'll send to the list so that I have somewhere convenient to point
people if this comes up in the future:

* A lot of darcs's functionality could be refactored into generally
 usable Haskell libraries, e.g. LCS-finding, downloading-with-libcurl.

* darcs was once a flagship Haskell application, supporting the idea
 that Haskell can be used in the real world. That image has mostly
 faded away now due to the problems it has, but I think we can get it
 back if we can get a high quality darcs out there. That would be good
 for the community's image.

* darcs has (in my opinion, at least) a much simpler, more intuitive
 interface than the other version control systems. I don't think I'm
 alone here, as I think this is where a lot of the resistance against
 moving to git is coming from.

* I think darcs is the Obvious, Right way to do version control.
 Phil Wadler (at least, I think it was him; and probably many others
 too) has said that the lambda calculus is universal, in the sense  
that
 if we were to meet a sufficiently advanced alien culture, it is  
almost

 inconceivable that they would not have also discovered the lambda
 calculus. Darcs-style patch theory, before conflicting patches are
 introduced, falls into the same category in my opinion. (I'm not yet
 sure if it can be extended to include some definition of conflictors
 too). By contrast, the heuristics and multiple merge algorithms of
 other systems feels very ad-hoc.


Thanks
Ian


___
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:10:31AM +0100, Malcolm Wallace wrote:


On 12 Aug 2008, at 01:35, Manuel M T Chakravarty wrote:

Ah, good point!  Changing ghc to git means *all* developers of boot
libraries need to use git *regardless* of what repo format the boot
libraries are in.  After all, they need to validate against the
current ghc head before pushing.


It is worth pointing out that I *never* validate against ghc head  
when

I commit to the core libraries.


Also, all of the people who send us patches don't need to validate  
(and
I suspect most of them don't), as we validate the patches before  
pushing

them.


Well, its up to you whether you want to validate for other people, but  
I don't think that is the right policy.  Everybody (including Malcolm)  
should validate.


If you contribute code to the linux kernel, comprehensive testing of  
the code is a requirement, too.  It's not as if it were a strange  
requirement of GHC as an open source project to ask people to test  
their code properly.  In fact, I even tell my first year students that  
they should test their code properly.  Maybe we should hand books to  
introductory software engineering out to potential ghc and library  
contributors.  (Sorry to get cynic, but I can't believe that we are  
even discussing that.)


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:
| It is worth pointing out that I *never* validate against ghc head  
when

| I commit to the core libraries.

I think that's perfectly reasonable for the reasons you explain.


Sorry, but I think the only reason its halfway acceptable is that  
Malcolm didn't break the GHC build yet.  If he does, I'll be screaming  
as loudly as for anybody else.


What Malcolm is basically saying is that he doesn't contribute to the  
functionality of the boot libraries, he simply makes sure they compile  
with nhc98.  That's a valuable contribution, of course, but to be  
honest, I don't think its a valid reason for us to go to the trouble  
of having two vcs for ghc.


Manuel

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

Re: Build system idea

[Manuel M T Chakravarty]

Duncan Coutts:

On Tue, 2008-08-12 at 11:11 +0100, Simon Marlow wrote:


I propose we do this:

 - Extract the code from Cabal that generates Makefiles, and treat  
it as

   part of the GHC build system.  Rather than generating a Makefile
   complete with build rules, we generate a Makefile that just
   has the package-specific metadata (list of modules, etc.), and put
   the code to actually build the package in the GHC build system.


As you know, I've been trying to get rid of that code ever since it
arrived :-)

It will probably mean that we have a tighter dependency on Cabal,  
because
we use it as a library rather than a black box; but hopefully we  
can keep

our branch of Cabal more stable and not have to update it so often.


If you don't need to update so often it would make life easier for  
Cabal

hackers and Manuel would be pleased :-)


Yes!

Anyway, this is an idea that I think is interesting.  Obviously it  
needs a
lot more fleshing out to be a real proposal, but I'm interested in  
whether
anyone thinks this idea is worth persuing, or whether there are  
better

alternatives.


I think this is definitely an interesting idea.  At the moment, it  
seems to me that all the metadata handling of Cabal is what's most  
useful to GHC, whereas the actual build procedure and its  
inflexibility causes a lot of grief, especially if you want to do  
something non-standard.  The proposed idea would pick the best of both  
worlds (Cabal's metadata handling and make's build flexibility plus  
the fact that many more people know how to tweak makefiles even if it  
is a pain, but its pretty well understood pain).


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:

Even the current situation with Cabal is a bit of a pain, as it's easy
to forget to push patches upstream as well as GHC's repo, and that's
just with 2 repos of the same VCS.


As I said before, IMHO it is a big mistake for ghc to depend on  
development versions of Cabal.  GHC should only depend on stable Cabal  
versions.


I actually think the original plan, where only the ghc repo (plus  
one or
two others) is in git is preferable. You may have to use a different  
VCS

for different subprojects, but after that it's downhill all the way.
You don't have to worry about patches being converted from one VCS to
another, moved to another repo, converted back and merged back into  
the

first repo.


Having two vcs for one project is bad.  One reason to switch to git (I  
am told) is that people had problems with darcs on some platforms  
(windows and Solaris, for example).  How is that going to be any  
better if part of the project is still in darcs?  So, can we please  
make up our mind?  If darcs has problems on some platforms, then we  
should not use darcs at all for ghc.  If darcs does not have problems  
on some platforms, then there is one less reason to switch.


All core library developers need to use git anyway to validate their  
core library patches.  So, let's just move the ghc repo and *all core  
libraries* over to git.  If git is good enough for the ghc repo, it  
should be good enough for the core library repos as well, shouldn't it.


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]

Ross Paterson:

On Mon, Aug 11, 2008 at 04:17:59PM +0100, Simon Marlow wrote:

The main obstacle with just switching the core libraries is that they
are shared by other implementations and other maintainers.  So I  
see no

alternative but to create forks of those repositories for use by GHC,
unless/until the other projects/maintainers want to migrate to git.


Forking is much worse than using multiple vcs's, and if we don't fork,
anyone working on those libraries will have to use git at least to  
get GHC
HEAD to check that they're not breaking it.  And clearly GHC  
developers

outnumber developers of other implementations.  (I don't think a move
to git will lead to more GHC developers, but I buy the interns  
argument.)


Ah, good point!  Changing ghc to git means *all* developers of boot  
libraries need to use git *regardless* of what repo format the boot  
libraries are in.  After all, they need to validate against the  
current ghc head before pushing.


In other words, the decision to move the ghc repo affects all core  
library developers anyway.  No use pretenting that changing only the  
ghc repo (and leaving the rest in darcs) would make anything simpler  
for anybody.



My concern is that there are rather more developers of libraries and
assorted other packages, and this will place an arbitrary divide  
across

those.  Unless everyone moves to git, of course.


There are surely more developers of libraries in general than there  
are GHC developers.  However, I doubt that there are more developers  
of boot libraries, who are not also ghc developers, than there are ghc  
developers.  The change doesn't have to affect anybody, but ghc  
developers and *core* library developers.


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 Marlow:

Manuel M T Chakravarty wrote:

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!


I completely agree this is a problem.  The main obstacle with just  
switching the core libraries is that they are shared by other  
implementations and other maintainers.  So I see no alternative but  
to create forks of those repositories for use by GHC, unless/until  
the other projects/maintainers want to migrate to git.  Some of the  
repositories are not shared - for example ghc-prim, integer-gmp,  
template-haskell, and these don't need to be forked.


One way we could create the forks would be to create a git repo for  
each package with two branches: the master branch that GHC builds,  
and a separate branch that tracks the main darcs repository, and is  
synced automatically whenever patches are pushed to the main darcs  
repo.  We'd have to explicitly merge the tracking branch into the  
master branch from time to time.  When we want to make changes  
locally, we can just commit them to the GHC branch and push the  
changes upstream in a batch later (and then we'd end up having to  
merge them back in to the GHC branch... but hopefully git's merge is  
clever enough to avoid manual intervention here).  This is  
complicated and ugly of course; better suggestions welcome.


Yes, it's a pain.  However, it is better than two vcs for one project.

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.


I'm not completely convinced we need to have this all worked out  
before GHC switches, although it would be nice of course.  We  
currently have infastructure in place for the build to work with a  
mixture of darcs and git repositories, and existing developers  
already have to learn git anyway.  They just need to remember to use  
darcs for libraries and git for the main GHC repo, and this is only  
a temporary situation.


As far as I am concerned, building GHC is turning into a big mess.  We  
discussed ways to improve it again, BUT I'd rather not see it getting  
any messier before it gets better.  Hence, please let's have a  
complete plan that we are convinced will work before making any more  
changes.


As for Cabal - we had a thread on cvs-ghc last week, and as I said  
there we'd love to hear suggestions for how to improve things,  
including wild and crazy ideas for throwing it all away and starting  
again.  However, as I explained, there are good reasons for the way  
things are done now, the main one being that the build system for  
packages is not written twice.


Yes, we need cabal for packages because we don't want two build  
systems.  However, this does not justify the use of Cabal outside of  
libraries/.  Nobody explained to me why that was necessary.  Why  
change all the rest of the build system.  What is the benefit for the  
ghc project?


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  
Cab

Re: Version control systems

[Manuel M T Chakravarty]

Matthias Kilian:

On Mon, Aug 11, 2008 at 04:17:59PM +0100, Simon Marlow wrote:
[...]
As for Cabal - we had a thread on cvs-ghc last week, and as I said  
there
we'd love to hear suggestions for how to improve things, including  
wild
and crazy ideas for throwing it all away and starting again.   
However, as
I explained, there are good reasons for the way things are done  
now, the
main one being that the build system for packages is not written  
twice.


Well, at least the Makefile creation was a step (the first step?)
into the wrong direction, IMHO. I'll run a GHC build to get some
of those generated Makefiles and followup on cvs-ghc, but for a
starter, Cabal shouldn't know anything about implementation-specific
internal build systems; instead it should rely only on it's own
metadata.  Implementation-specific stuff (such as how to run the
compiler) should be supplied by the implementation, not by Cabal.

I see more and more workarounds for workarounds for an unmaintainable
(and unusable) build system, and after the latest discussions about
git vs. darcs, maintaining GHC-specific branches of libraries etc.,
I think I'll just drop maintainership from all GHC-related OpenBSD
ports until the GHC build system chaos settles down a little bit.


Thanks for demonstrating my point...

Complicated build infrastructure and lack of portability used to be a  
big problem for GHC in the past.  Over the last years, the situation  
got much better (to a large extent due to SimonM sanitising the  
makefile-based build system).  Why are we so keen to throw it all away  
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:
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]

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]

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]

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]

Listen to Don, he is a wise man!

Manuel

Don Stewart:

I agree with this.

As Audrey says, you have to lower the barrier to entry. That means:

   * one build system
   * one vcs

to build ghc (and anything it requires, such as the core libraries).

This is a chance to make a big step towards accessibility, let's  
make that step.


I just want to add to this. We're offering an unusual product: a lazy,
purely functional language. This already separates us from the
mainstream. So how to we ensure we minimise the stress of adopting
something so unfamiliar?

By ensuring that in all other respects the environment they have to
learn is familiar and simple.

I think we risk isolating oursevles yet further -- and creating new
barriers to adoption, beyond those we can't avoid -- by adding more
complicated dependencies (two revision control systems, one of which,
darcs, is now firmly out of the maintstream).

Instead, if we just use ubiquitous, common tools -- like git -- for
everything, we minimise the pain for people, and sit firmly in the
mainstream of open source.

If anything has been learnt by Spencer and I while working on xmonad,
is:
   dependencies, dependencies, dependencies

reduce these, and you gain eyeballs, and ultimately developers.  
Increase

these, and you end up isolated and marginalised.

So let's capitalise on this switch to git, and take the opportunity to
remove one big dependency from the system.

-- Don


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

Isaac Dupree:

Duncan Coutts wrote:

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 wonder how many of the libraries are "core" in that they need to  
be changed a lot for GHC?


The boot libraries, ie, those needed to build the HEAD of the ghc repo:

  SUBDIRS  = ghc-prim $(INTEGER_LIBRARY) base array packedstring
  SUBDIRS += containers bytestring old-locale old-time filepath  
directory

  ifeq "$(GhcLibsWithUnix)" "YES"
  SUBDIRS += unix
  endif
  ifeq "$(Windows)" "YES"
  SUBDIRS += $(wildcard Win32)
  endif
  SUBDIRS += process pretty hpc template-haskell editline Cabal  
random haskell98


Here Cabal, is ghc variant of the Cabal repo, not the actually Cabal  
head.


The whole point is to make sure that anybody who decides to hack GHC  
needs to install and learn just one vcs, not two.


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 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 .)


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:

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: 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: Tiger installer [was: Re: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)]

[Manuel M T Chakravarty]

Yitzchak Gale:

Manuel M T Chakravarty wrote:

http://www.cse.unsw.edu.au/~chak/HelloWorld.tar.bz2
It contains HelloWorld-Leopard and HelloWorld-Tiger.  Please try to
run them both.  I believe HelloWorld-Leopard will also give you a bus
error, but I hope HelloWorld-Tiger will work.


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


Great.  Then, I think I know what to do.  I'll add a new option to  
configure to specify what Apple calls the "deployment target" of a GHC  
build.  By using 10.4 as the deployment target we can then build GHC  
distributions in any form (installer, binary dist, or local installs)  
for 10.4 on a 10.5 box.  However, some extra fiddling will be required  
to make sure utilities, such as ghc-pkg, are also properly cross- 
compiled.


I'll let you know when I have got a new GHC installer using this  
approach.


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: Tiger installer [was: Re: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)]

[Manuel M T Chakravarty]

Yitzchak Gale:

Manuel M T Chakravarty wrote:

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


I got it, but there were some download problems. I hope the
file is intact. It has exactly 44740924 bytes. Perhaps you
could send me an md5sum to be certain.


The file length is correct.

wireless-139 chak 2 (/Users/chak): md5 Public/Web/haskell/ 
GHC-6.9.20080213-i386.dmg
MD5 (Public/Web/haskell/GHC-6.9.20080213-i386.dmg) =  
cc76dea615234aa83d85ef5c30021828



and whether you can run /usr/bin/ghci (not so sure about that).


It didn't.

$ /usr/bin/ghci
Bus error

In the readme, you say that I require Xcode 3.0. Tiger came with
Xcode 2.4.1, and I have not updated it. (I tried once, but the
download was so huge that I decided to forget it unless there
was some real need.) Could that be part of the problem?


If ghc worked in the past on your machine, then your Xcode version  
should be fine.  (It's really only important that we have a version of  
gcc that plays nicely with ghc.)  But you are right, I need to update  
that readme for Tiger (the recommendation for 3.0 really only applies  
to Leopard.)


I had a closer look at cross compilation for 10.4 and I think I know  
why we get the bus error and how to avoid it.  To avoid you having to  
download another GHC build, which may have problems again, I have  
compiled two versions of hello world and put them in a tar ball at


http://www.cse.unsw.edu.au/~chak/HelloWorld.tar.bz2

It contains HelloWorld-Leopard and HelloWorld-Tiger.  Please try to  
run them both.  I believe HelloWorld-Leopard will also give you a bus  
error, but I hope HelloWorld-Tiger will work.


(Interestingly HelloWorld-Tiger is about 8x bigger than HelloWorld- 
Leopard.  I don't think this has anything to do with GHC, but is due  
to Apple's cross-compilation SDK.)


Manuel

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