- ghc-devs - Haskell.org

Re: A modest proposal (re the Platform)
by Páli Gábor János 20 Jan '14

20 Jan '14

On Mon, Jan 20, 2014 at 9:29 AM, Andres Löh <andres.loeh(a)gmail.com> wrote: > I can understand the motivation of this proposal, but I'm slightly worried: +1 > (2) Simply because GHC 7.8 is itself so long delayed and so full of > new features, I think it's realistic to assume that quite a few > library glitches will appear even after it's released. Also, GHC bugs > may be found only after formal release (despite all the hammering, the > use of GHC pre release isn't quite comparable with the amount of > testing it gets afterwards; IMHO, there might very well be need for a > GHC 7.8.2). I'm all for trying to get an HP based on GHC 7.8 out as > possible, but how soon would that actually happen, realistically? > Sooner than 6 months from now? I do not think so. Waiting a couple of months after 7.8.1 is released to let the dust settle will not hurt anyway.

1 0

A modest proposal (re the Platform)
by Mark Lentczner 19 Jan '14

19 Jan '14

Looks like GHC 7.8 is pretty near release. And while I know that we really like to have a GHC out for a while, and perhaps see the .1 release, before we incorporate it into the Platform, this GHC, while including many new and anticipated things, seems pretty well hammered on. Combine that with the now two-month late (all my fault) HP release for 2013.4.0.0 isn't slated to really have all that much new in it, in part because it is the same GHC as the last HP release. Now - it would really look foolish, and taken poorly (methinks) if we release a HP this month - only to have GHC 7.8 release early Feb. Folks would really be head scratching, and wondering about the platform. SO - I'm proposing ditching the now late 2013.4.0.0 (I admit, I'm finding it hard to get excited by it!) and instead move right to putting out 2014.2.0.0 - aimed for mid-March to mid-April. This release would have several big changes: - GHC 7.8 - New shake based build for the Platform - Support for validation via package tests - Support for a "server variant" (no OpenGL or other GUI stuff if we had any) - Automated version info w/historical version matrix page - Several significant packages: I'd like to see Aeson at the very least, updated OpenGL stuff I'd also propose changes for the Mac build (though this is obviously independent): - Built from GHC source, not dist. release. (guarantees consistent release) - Only 64bit (I know, controversial...) Thoughts?

3 2

ARM64 cross-compiler and --sysroot GNU C option.
by Karel Gardas 18 Jan '14

18 Jan '14

Folks, just for fun I've built GHC cross-compiler for ARM64 platform using LLVM backend. I've documented it here: https://ghcarm.wordpress.com/2014/01/18/unregisterised-ghc-head-build-for-a… and I'm writing here just to ask if you think adding --with-gcc-sysroot option (or kind of it) to GHC's configure may be a good idea or not (i.e. you consider using shell script wrapper which passes --sysroot option to the GNU C cross compiler perfectly adequate for this job -- like I did in blog post above). See also #7754 which shows the same problem. Thanks! Karel

1 0

RE: [Haskell-cafe] GHC API: runStmt not taking into account reloaded module
by Simon Peyton Jones 17 Jan '14

17 Jan '14

That sounds odd. Can you make a small reproducible test case, open a ticket, and attach the test? Thanks SImon From: Haskell-Cafe [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of JP Moresmau Sent: 14 January 2014 20:14 To: Haskell Cafe Subject: [Haskell-cafe] GHC API: runStmt not taking into account reloaded module It's late here and I'm probably overlooking something stupid, so I'd like if somebody could put my nose on it... I'm using the GHC API to evaluate statements. I use runStmt to get a RunResult, lookupName to get the ID for the bound names, obtainTermFromId to get the term and showTerm to display it. So I can call a function from the loaded module with some parameters and get the result. Good! However, if I reload a module and I change the implementation of the function, runStmt still returns the old value! I know the reload worked because if I added new names, getNamesInScope returns the new names. What do I need to do to make sure the new function definitions are used? I've perused the source code of InteractiveEval and ghci but nothing stood out. I am calling setContext after load. Thanks a million! -- JP Moresmau http://jpmoresmau.blogspot.com/

2 4

[PATCH] platformFromTriple: fix to recognize Solaris triple (i386-pc-solaris2.11)
by Karel Gardas 16 Jan '14

16 Jan '14

--- Cabal/Distribution/System.hs | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Cabal/Distribution/System.hs b/Cabal/Distribution/System.hs index a18e491..4fc76f6 100644 --- a/Cabal/Distribution/System.hs +++ b/Cabal/Distribution/System.hs @@ -89,7 +89,7 @@ osAliases Compat Windows = ["mingw32", "win32"] osAliases _ OSX = ["darwin"] osAliases _ IOS = ["ios"] osAliases Permissive FreeBSD = ["kfreebsdgnu"] -osAliases Permissive Solaris = ["solaris2"] +osAliases _ Solaris = ["solaris2"] osAliases _ _ = [] instance Text OS where -- 1.7.3.2

4 6

Re: [commit: packages/integer-gmp] master: Allocate initial 1-limb mpz_t on the Stack and introduce MPZ# type (7bdcadd)
by Simon Marlow 16 Jan '14

16 Jan '14

On 13/01/14 13:25, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/integer-gmp > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/7bdcadda7e884edffb1427f0685493f3a… > >> --------------------------------------------------------------- > > commit 7bdcadda7e884edffb1427f0685493f3a2e5c5fa > Author: Herbert Valerio Riedel <hvr(a)gnu.org> > Date: Thu Jan 9 00:19:31 2014 +0100 > > Allocate initial 1-limb mpz_t on the Stack and introduce MPZ# type > > We now allocate a 1-limb mpz_t on the stack instead of doing a more > expensive heap-allocation (especially if the heap-allocated copy becomes > garbage right away); this addresses #8647. While this is quite cool (turning some J# back into S#), I don't understand why you've done it this way. Couldn't it be done in the Haskell layer rather than modifying the primops? The ByteArray# has already been allocated by GMP, so you don't lose anything by returning it to Haskell and checking the size there. Then all the DUMMY_BYTEARRAY stuff would go away. Cheers, Simon

3 3

Releasing containers 0.5.3.2 -- before GHC 7.8?
by Ryan Newton 16 Jan '14

16 Jan '14

Hi guys, I'm wondering if we can do a hackage release of 0.5.3.2? That "splitRoot" function is in there, and my ability to deploy parallel code that uses containers depends on people getting it! Are there any other changes since 0.5.3.1? Replacing containers seems like a real pain for end users, so it would be great if 0.5.3.2 could come with GHC 7.8. Currently, it looks like the GHC repo is up to date in that it includes 0.5.3.1. I realize it is late days for this, but: - It's been a month since we put splitRoot in; I've been using it heavily and it I'm pretty confident that it's correct. (It's so simple!) - Nothing else is touched, so there is very little liability associated with this version bump. And, as you know, if we don't make this round it's a long latency before the next chance. That is, before we can expect people to do parallel folds over Data.Set or Data.Map without installation headache. Any objections? -Ryan

5 6

PLT Redex definition of STG as per fast curry paper
by Edward Z. Yang 15 Jan '14

15 Jan '14

For those of you who aren't following the commit list, I've just pushed a PLT Redex <http://redex.racket-lang.org/> definition for an STG-like language as was defined in the fast curry paper. This language is *not* STG. The hope is that this will be a good starting point for actually formalizing STG as it exists today. I've included a hefty comment block at the top of the development summarizing ways in which this could be improved. Take a look if you're interested! Cheers, Edward

3 2

ghci verbosity
by Simon Peyton Jones 15 Jan '14

15 Jan '14

Friends ghc -interactive has just started being more verbose. The "linking...done" stuff didn't happen before. Does this ring any bells for anyone? I have not investigated at all so far; hoping someone will say "oh yes, I know and will fix". Simon bash$ ~/5builds/HEAD/inplace/bin/ghc-stage2 --interactive GHCi, version 7.7.20140114: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude>

3 3

Re: Releasing containers 0.5.3.2 -- before GHC 7.8?
by Johan Tibell 14 Jan '14

14 Jan '14

I'll make a release in the next few days. On Tue, Jan 14, 2014 at 10:33 PM, Milan Straka <fox(a)ucw.cz> wrote: > Hi Johan, > > I think releasing 0.5.4 is a good idea. Could I ask you to do the > release as usual, please? > > We added the splitRoot function, so it should really be 0.5.4 and not > only 0.5.3.2. Actually, we added Functor instance to Graph.SCC and > Functor and Applicative instances to Graph.SetM, but Graph is rarely > used, so I would deliberately break PVP and not do a major version bump. > > Thanks, > cheers, > Milan > > > -----Original message----- > > From: Ryan Newton <rrnewton(a)gmail.com> > > Sent: 14 Jan 2014, 11:41 > > > > Hi guys, > > > > I'm wondering if we can do a hackage release of 0.5.3.2? That > "splitRoot" > > function is in there, and my ability to deploy parallel code that uses > > containers depends on people getting it! Are there any other changes > since > > 0.5.3.1? > > > > Replacing containers seems like a real pain for end users, so it would be > > great if 0.5.3.2 could come with GHC 7.8. Currently, it looks like the > GHC > > repo is up to date in that it includes 0.5.3.1. > > > > I realize it is late days for this, but: > > > > - It's been a month since we put splitRoot in; I've been using it > > heavily and it I'm pretty confident that it's correct. (It's so > simple!) > > - Nothing else is touched, so there is very little liability > associated > > with this version bump. > > > > And, as you know, if we don't make this round it's a long latency before > > the next chance. That is, before we can expect people to do parallel > folds > > over Data.Set or Data.Map without installation headache. > > > > Any objections? > > -Ryan >

1 0