Re: x86-64 unknown-linux

[Austin Seipp]

On Linux, the builds are keyed by the OS name they were built on. This is
because systems like CentOS have different versions of libgmp, glibc than
e.g. Debian derivatives. So they actually refer to different paths, are
built against different APIs depending on what's available, etc. That's why
the names are distinguished; in the past only Debian-based builds were
offered, but I started building CentOS versions in the 7.8.x era.

The debian-based builds are normally the 'lowest common denominator' that
works on all modern systems. Given that, you want:

https://downloads.haskell.org/~ghc/8.0.1/ghc-8.0.1-x86_64-deb8-linux.tar.xz

If you have a problem, just yell.

On Sun, Jun 5, 2016 at 9:31 PM, Richard Eisenberg  wrote:

> Hi devs,
>
> I would like to download GHC 8 binaries for Arch Linux on an x86-64
> architecture. I assume I'm looking for an unknown-linux build, and it looks
> like what I want is a Tier 1 platform, according to
> https://ghc.haskell.org/trac/ghc/wiki/Platforms   Yet I don't see this
> release in https://downloads.haskell.org/~ghc/8.0.1/
>
> Can you help?
>
> Thanks!
> Richard
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>


-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

x86-64 unknown-linux

[Richard Eisenberg]

Hi devs,

I would like to download GHC 8 binaries for Arch Linux on an x86-64 
architecture. I assume I'm looking for an unknown-linux build, and it looks 
like what I want is a Tier 1 platform, according to 
https://ghc.haskell.org/trac/ghc/wiki/Platforms   Yet I don't see this release 
in https://downloads.haskell.org/~ghc/8.0.1/

Can you help?

Thanks!
Richard___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Template Haskell determinism

[Edward Z. Yang]

I must admit, I am a bit confused by this discussion.

It is true that every Name is associated with a Unique.  But you don't
need the Unique to equality/ordering tests; the names also contain
enough (stable) information for stable comparisons of that sort.  So
why don't we expose that instead of the Unique?

Edward

Excerpts from Michael Sloan's message of 2016-06-04 18:44:03 -0700:
> On Thu, Jun 2, 2016 at 4:12 AM, Simon Peyton Jones 
> wrote:
> 
> > If names get different ordering keys when reified from different modules
> > (seems like they'd have to, particularly given ghc's "-j"), then we end up
> > with an unpleasant circumstance where these do not compare as equal
> >
> >
> >
> > The I believe that global, top level names (NameG) are not subject to this
> > ordering stuff, so I don’t think this problem can occur.
> >
> 
> True, top level names are NameG.  The reified Info for a top level Dec may
> include NameU, though.  For example, the type variables in 'Maybe' are
> NameU:
> 
> $(do TyConI (DataD _ _ [KindedTV (Name _ nf) _] _ _ _) <- reify ''Maybe
>  lift (show nf))
> 
> The resulting expression is something like "NameU 822083586"
> 
> > This is a breaking change and it doesn't fix the problem that NameFlavour
> > is
> >
> > not abstract and leaks the Uniques. It would break at least:
> >
> >
> >
> > But why is NameU exposed to clients?   GHC needs to know, but clients
> > don’t.  What use are these packages making of it?
> >
> 
> It's being leaked in the public inteface via Ord.  The Eq instance is fine,
> because these are Uniques, so the results should be consistent.
> 
> There are two goals in contention here:
> 
> 1) Having some ordering on Names so that they can be used in Map or Set
> 2) Having law-abiding Eq / Ord instances.  We'd need a 'PartialOrd' to
> really handle these well.  In that case, the ordering would be based on
> everything but the NameU int, but 'Eq' would still follow it
> 
> A few ideas for different approaches to resolving this:
> 
> 1) Document it.  Less appealing than fixing it in the API, but still would
> be good.
> 
> 2) Remove the 'Ord' instance, and force the user to pick 'NamePartialOrd'
> newtype (partial ord on the non-unique info), or 'UnstableNameOrd' newtype
> (current behavior).  A trickyness of this approach is that you'd need
> containers that can handle (PartialOrd k, Eq k) keys.  In lots of cases
> people are using the 'Ord' instance with 'Name's that are not 'NameU', so
> this would break a lot of code that was already deterministic.
> 
> 3) Some approaches like this ordering key, but I'm not sure how it will
> help when comparing NameUs from different modules?
> 
> > S
> >
> >
> >
> >
> >
> > *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of 
> > *Michael
> > Sloan
> > *Sent:* 02 June 2016 02:07
> > *To:* Bartosz Nitka 
> > *Cc:* ghc-devs Devs 
> > *Subject:* Re: Template Haskell determinism
> >
> >
> >
> > +1 to solving this.  Not sure about the approach, but assuming the
> > following concerns are addressed, I'm (+1) on it too:
> >
> >
> >
> > This solution is clever!  However, I think there is some difficulty to
> > determining this ordering key.  Namely, what happens when I construct the
> > (Set Name) using results from multiple reifies?
> >
> >
> >
> > One solution is to have the ordering key be a consecutive supply that's
> > initialized on a per-module basis.  There is still an issue there, though,
> > which is that you might store one of these names in a global IORef that's
> > used by a later TH splice.  Or, similarly, serialize the names to a file
> > and later load them.  At least in those cases you need to use 'runIO' to
> > break determinism.
> >
> >
> >
> > If names get different ordering keys when reified from different modules
> > (seems like they'd have to, particularly given ghc's "-j"), then we end up
> > with an unpleasant circumstance where these do not compare as equal.  How
> > about having the Eq instance ignore the ordering key?  I think that mostly
> > resolves this concern.  This implies that the Ord instance should also
> > yield EQ and ignore the ordering key, when the unique key matches.
> >
> >
> >
> > One issue with this is that switching the order of reify could
> > unexpectedly vary the behavior.
> >
> >
> >
> > Does the map in TcGblEnv imply that a reify from a later module will get
> > the same ordering key?  So does this mean that the keys used in a given
> > reify depend on which things have already been reified?  In that case, then
> > this is also an issue with your solution.  Now, it's not a big problem at
> > all, just surprising to the user.
> >
> >
> >
> >
> >
> > If the internal API for Name does change, may as well address
> > https://ghc.haskell.org/trac/ghc/ticket/10311 too.  I agree with SPJ's
> > suggested solution of having both the traditional package identifier and
> > package keys in 'Name'.
> >
> >
> >
> >