Re: Phabricator diffs not viewable by non-logged in users
The error message was fairly self explanatory: it mentions the restriction was on the Build Plan object, not the Differential revision (if you view it in private/incognito mode). In Phabricator, various objects can have their own policies. Objects can be attached to others, like builds to diffs. Diffs had been set to be public on creation, but for some reason, all the Harbormaster build plans required 'All Users' to view them, which requires a login. I've fixed this by changing all the build plans to be public, which they should have been in the first place. On Thu, Sep 1, 2016 at 12:30 AM, Ben Gamari <b...@well-typed.com> wrote: > "Edward Z. Yang" <ezy...@mit.edu> writes: > > > For example, if I am not logged in (try an incognito/private > > browsing session), https://phabricator.haskell.org/D2501 reports > > an error. > > > Indeed I had noticed this as well and it has been on my list of things > to look in to. I agree that you shouldn't need to be logged in to view > differentials. > > Austin, do you have any idea why this is the case? > > Cheers, > > - Ben > > -- 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
Re: [Diffusion] [Committed] rCABAL2863a628f857: Add two local type signatures
No, this is a Phabricator bug due to some changes in how commit imports are
handled. I just upgraded earlier; I'm tracking it down now.
At minimum, I'll find a way to turn off the email spam.
On Fri, Jul 8, 2016 at 2:46 PM, Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:
> I don’t believe I made this commit, or the ones around it. Mysterious; I
> hope I’m not being impersonated!
>
>
>
> Simon
>
>
>
> *From:* nore...@phabricator.haskell.org [mailto:
> nore...@phabricator.haskell.org]
> *Sent:* 08 July 2016 20:43
> *To:* Simon Peyton Jones <simo...@microsoft.com>
> *Subject:* [Diffusion] [Committed] rCABAL2863a628f857: Add two local type
> signatures
>
>
>
> simonpj committed rCABAL2863a628f857: Add two local type signatures
> (authored by simonpj).
>
>
>
> Add two local type signatures
>
> I'm adding these type signatures to satisfy the "do not generalise
> local let/where" rule that GHC is taking on.
>
> The signatures are clearly correct, but I was surprised at the
> polymorphism needed. For example
>
> parseOptVersion :: ReadP r Version
> parseOptVersion = parseQuoted ver <++ ver
>
> where ver :: ReadP r Version
>
> ver = parse <++ return noVersion
>
> noVersion = Version{ versionBranch=[], versionTags=[] }
>
> Note that 'ver' really is called at two different types! That
> in turn is because of the type of (<++)
>
> (<++) :: ReadP a a -> ReadP r a -> ReadP r a
>
> (+++) :: ReadP r a -> ReadP r a -> ReadP r a
>
> Note the "a a" in the first arg, which is very unusual.
> For example, compare the type of (+++).
>
> Changing it to match the type of (+++) makes ReadP fail to compile,
> though, so I assume it's right as it stands. But surely this deserves
> a comment?!
>
>
>
> *AFFECTED FILES*
>
> /Distribution/ParseUtils.hs
>
>
>
> *USERS*
>
> simonpj (Author)
>
>
>
> *COMMIT*
>
> https://phabricator.haskell.org/rCABAL2863a628f857
>
>
>
> *EMAIL PREFERENCES*
>
> https://phabricator.haskell.org/settings/panel/emailpreferences/
>
>
>
> *To: *simonpj
>
> ___
> 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
Re: x86-64 unknown-linux
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 <e...@cis.upenn.edu> 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
Re: Every GHC-compiled program seg-fault (HEAD)
Travis can't build on Windows, I'm afraid. I'm sort of mitigating another crisis right now, but here's a shot in the dark - based on my Very Amazing Deductive Skills[1], completed in mere seconds, I'm guessing that perhaps e68195a96529cf1cc2d9cc6a9bc05183fce5ecea is relevant, one of Simon's latest commits? e.g., just try, as a shot in the dark $ git revert e68195a96529cf1cc2d9cc6a9bc05183fce5ecea And build again. [1] Note: my Very Amazing Deductive Skills in this case, are as follows. Look at git log for the last few days. See that some C code was changed. Immediately become suspicious that is the culprit, because it's C code. So, yes, a complete shot in the dark, but it's one that's served me well, too. :) On Wed, Apr 27, 2016 at 3:36 PM, Simon Peyton Jones <simo...@microsoft.com> wrote: > Does anyone feel able to look at > > https://ghc.haskell.org/trac/ghc/ticket/11988 > > The symptom is that every single GHC-compiled binary now seg-faults on > Windows (with HEAD). > > That’s pretty serious. > > Can Travis pinpoint the offending commit? > > Simon -- 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
Re: [Diffusion] [Build Failed] rGHC2acfaae9a99d: Comments only
I'm looking into Harbormaster today (following Joachim's email earlier). Not sure why the machine is running out of memory... On Fri, Apr 15, 2016 at 9:37 AM, Simon Peyton Jones <simo...@microsoft.com> wrote: > Bizarre. Harbourmaster says: > > ghc-stage1: ghc-stage1: out of memory (requested 1048576 bytes) > out of memory (requested 1048576 bytes) > > I have no idea what is going on > > SImon > > | -Original Message- > | From: nore...@phabricator.haskell.org > | [mailto:nore...@phabricator.haskell.org] > | Sent: 15 April 2016 15:35 > | To: Simon Peyton Jones <simo...@microsoft.com> > | Subject: [Diffusion] [Build Failed] rGHC2acfaae9a99d: Comments only > | > | Harbormaster failed to build B9176: rGHC2acfaae9a99d: Comments only! > | > | BRANCHES > |master > | > | USERS > |simonpj (Author) > |GHC - Core/System FC (Auditor) > | > | COMMIT > |https://phabricator.haskell.org/rGHC2acfaae9a99d > | > | EMAIL PREFERENCES > |https://phabricator.haskell.org/settings/panel/emailpreferences/ > | > | To: simonpj, GHC - Core/System FC, Harbormaster > ___ > 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
Re: GHC 8 and Template Haskell
Here's a question, on top of this one: why don't we require template-haskell changes for most corresponding syntax changes? We tend to play catch up with template-haskell sometimes and it's relatively strange. I mean, in some sense, we could have said a while back "This needs another revision, please add template haskell support" and avoided it all. Richard has a better insight into this than I do, I'm sure, but it seems - to me, anyway - like template-haskell support is a reasonable bar for most surface-level syntax change to cross, before getting merged. My intuition tells me that, most of the time, a lot of us simply forget to make the changes, or ask for them in reviews, and so it goes. On Thu, Apr 14, 2016 at 1:12 PM, Ben Gamari <b...@well-typed.com> wrote: > Iavor Diatchki <iavor.diatc...@gmail.com> writes: > >> Hello, >> >> Now that "OVERLAPPING" and "OVERLAPPABLE" are pragmas on the instances, do >> we have a way to generate instances with such pragmas using Template >> Haskell? I can't seem to find a way to do this, which is unfortunate. >> >> If I am not missing anything, would there be objections to adding it to the >> TH library before the next release---I would volunteer to do the change >> ASAP. >> > Indeed this is an unfortunate gap. Given that this shouldn't be a > terribly invasive change I would be alright with this if Richard approves. > > Cheers, > > - Ben > > > ___ > Libraries mailing list > librar...@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -- 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
Re: GHC 8.0.1-rc3 source tarball availability
diek/hobsub-generic.sty))
> (/usr/local/texlive/2015/texmf-dist/tex/generic/ifxetex/ifxetex.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/oberdiek/auxhook.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/oberdiek/kvoptions.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/hyperref/pd1enc.def)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/latexconfig/hyperref.cfg)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/url/url.sty))
>
> Package hyperref Message: Driver (autodetected): hxetex.
>
> (/usr/local/texlive/2015/texmf-dist/tex/latex/hyperref/hxetex.def
> (/usr/local/texlive/2015/texmf-dist/tex/latex/hyperref/puenc.def)
> (/usr/local/texlive/2015/texmf-dist/tex/generic/oberdiek/stringenc.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/oberdiek/rerunfilecheck.sty))
> (/usr/local/texlive/2015/texmf-dist/tex/latex/oberdiek/hypcap.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/caption/newfloat.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/capt-of/capt-of.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/needspace/needspace.sty))
> (/usr/local/texlive/2015/texmf-dist/tex/latex/multirow/multirow.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/eqparbox/eqparbox.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/environ/environ.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/trimspaces/trimspaces.sty)))
> (/usr/local/texlive/2015/texmf-dist/tex/latex/fontspec/fontspec.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/l3kernel/expl3.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/l3kernel/expl3-code.tex)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/l3kernel/l3unicode-data.def)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/l3kernel/l3xdvipdfmx.def))
> (/usr/local/texlive/2015/texmf-dist/tex/latex/l3packages/xparse/xparse.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/fontspec/fontspec-patches.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/fontspec/fontspec-xetex.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/base/fontenc.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/euenc/eu1enc.def)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/euenc/eu1lmr.fd))
> (/usr/local/texlive/2015/texmf-dist/tex/xelatex/xunicode/xunicode.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/tipa/t3enc.def
> (/usr/local/texlive/2015/texmf-dist/tex/latex/euenc/eu1lmss.fd)))
> (/usr/local/texlive/2015/texmf-dist/tex/latex/fontspec/fontspec.cfg)))kpathsea:make_tex:
> .
>
>
>
> !
> ! fontspec error: "font-not-found"
> !
> ! The font "DejaVu Sans" cannot be found.
> !
> ! See the fontspec documentation for further information.
> !
> ! For immediate help type H .
> !...
>
> l.23 \setsansfont{DejaVu Sans}
>
> ?
>
> On Sun, Apr 10, 2016 at 12:05 PM Ben Gamari <b...@well-typed.com> wrote:
>>
>> tl;dr: If you would like to produce a binary distribution for GHC
>>8.0.1-rc3 then let us know, grab the source distribution and
>>start building. The binary distributions will be all released one
>>week from today.
>>
>>
>> Hello GHC packagers,
>>
>> Austin and I are happy to announce the release of the 8.0.1-rc3 source
>> distribution to binary packagers. You will find the tarball and usual
>> assortment of signatures at
>>
>> http://downloads.haskell.org/~ghc/8.0.1-rc3/
>>
>> This release is the first where we are following our new release policy
>> [1], where a one-week delay will be introduced between the release of
>> the source and binary distributions. The goal of this policy is to give
>> all platforms the opportunity for support from the first day of a
>> release.
>>
>> If all of the expected binary releases are submitted before the
>> week-long delay is through, we can move forward with the release ahead
>> of schedule. Given how late release candidate 3 is, we'd naturally like
>> to get the binary releases out as soon is possible: The sooner we can
>> get this -rc out the door the sooner we can get to the final release.
>> Moreover, it would be appreciated if you could confirm that you intend
>> to offer a binary distribution this release.
>>
>> Otherwise, let either Austin or I know if you have any trouble building
>> your distribution. I have yet to push the 8.0.1-rc3 tag in case we
>> encounter unexpected issues but all of my builds with this tarball
>> thusfar have gone quite well.
>>
>> Good luck and thanks for all of your work!
>>
>> Cheers,
>>
>> - Ben
>>
>>
>> [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> ___
> 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
Re: Trouble with first GHC patch submission: uncommitted changes
On Wed, Apr 6, 2016 at 7:11 PM, Conal Elliott <co...@conal.net> wrote: > I'm trying to get through my first GHC patch submission, using git and > Phabricator, following directions at > https://ghc.haskell.org/trac/ghc/wiki/Phabricator. "git status" shows two > unstaged changes: "deleted:test spaces" and "modified: > ../libraries/bytestring (modified content)" (in a submodule). I don't know > where either change came from. When I use "arc diff" to submit my intended > change to the compiler, I get asked about these to uncommitted changes. I > say to ignore the submodule change and do not amend my commit with the "test > spaces" deletion, I get "Usage Exception: You can not continue with > uncommitted changes. Commit or discard them before proceeding." I don't know > how to discard (nor whether safe), and I don't think I want to commit. I'm not sure about the 'test spaces' change. That should be added to .gitignore I think. I'll try to see if I can get that done for you. It should be fine to discard the changes; the spaces thing is an artifact of the build system testing a binary distribution (I assume you did ./validate ?) The bytestring change might be because there were some left over files from the build system lingering, that might not be in .gitignore. Just try running 'git status' in libraries/bytestring and seeing what it shows. > Note: the directions say to use "arc diff~" (rather than "arc diff"), to > which arc replied "(Assuming 'diff~' is the British spelling of 'diff'.)". Ugh, sorry. That's a clerical error. I must have typo'd that... Assuming you want to submit the latest patch, on your current branch, you want: $ arc diff HEAD~ The first argument to 'diff' is essentially the commit to start as the 'base' commit. You then get a diff generated, from the 'base' commit against the head commit of your working copy. In other words, when you say "arc diff XXX", that's basically a way of saying "Send the diff between XXX..HEAD". In this case, you can see that if you say "git log HEAD~..HEAD", which would only contain one commit (presumably, what you want). Arcanist can always tell you exactly what it will do, in a detailed way, before doing it. Instead of running 'arc diff', run 'arc which' $ arc which HEAD~ That will tell you exactly what arcanist will do, in a detailed manner. E.g. it will tell you if it will create a new diff, or update an old one, and exactly the commits it will use to create or update that diff. You can use further flags/arguments to 'arc diff' or 'arc which' to override the behavior as you want. > Thanks for any help! > > -- Conal > > ___ > 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
Re: GHC 8.0.1 release plan
Hello all, I just wanted to follow up on this. Yesterday, Ben and I spent some time and went over the current bug list[1]. If you saw that email yesterday - please refresh that page, we've trimmed the hedges a little bit. Please note that, barring any huge bugs in 8.0.1-rc3, we really aren't intending on putting anything else into the queue. So, if you're a developer: Please take a look at the tickets! Try to fix something. If you're a user: if you want something done for 8.0.1 that isn't done already, you better make a *really* good case for it, email us ASAP, and help us fix it! Realistically, we're going to be spending most of our time on the high/highest priority bugs. The remaining 'normal' bugs would be 'nice to have', and some may even be promoted - so if you can, maybe take a look. Otherwise we're going to be working on getting the remaining critical bugs fixed and out of the way and move forward. Thanks! [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1#Ticketsslatedfor8.0.1 On Mon, Mar 28, 2016 at 2:16 PM, Ben Gamari <b...@well-typed.com> wrote: > Ben Gamari <b...@well-typed.com> writes: > >> Hello GHCers, >> >> After numerous delays, I think we may finally be converging on a >> (hopefully final) 8.0.1 release candidate. Thanks to the tireless >> efforts of Richard Eisenberg, Simon PJ, and many others almost all of >> the release blocking tickets [1] have now been resolved. There are a few >> patches currently waiting for review that should hopefully be mergeable >> within the next few days. >> >> After these last patches have been merged I'll proceed in cutting >> the source distribution for GHC 8.0.1 release candidate 3. This release >> candidate will be made available immediately, although, in accordance >> with our new release policy [2], binary distributions won't be available >> until seven days later. >> > Oops, forgot the reference here. The new release timing policy was > described here, > > [2] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html > > ___ > 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
Re: Fwd: Is anything being done to remedy the soul crushing compile times of GHC?
The better approach, I think, might be to section off certain times in
a release period where we only allow such changes. Only for a month or
so, for example, and you're just encouraged to park your current work
for a little while, during that time, and just improve things.
The only problem is, it's not clear if people will want to commit as
much if the hard rule is just to fix bugs/improve performance for a
select time. Nobody is obligated to contribute, so it could easily
fall into a lull period if people get tired of it. But maybe the
shared sense of community in doing it would help.
Whatever we do, it has to be strict in these times, because in
practice we have a policy like this ("just bug/perf fixes") during the
time leading up to the RC, but we always slip and merge other things
regardless. So, if we do this, we must be quite strict about it in
practice and police ourselves better, I think.
On Wed, Feb 17, 2016 at 7:35 AM, Tuncer Ayaz <tuncer.a...@gmail.com> wrote:
> Here's a thought: has anyone experience with limiting a certain major
> release to just bug fixes and perf regression fixes, while postponing
> all feature patches? It sounds like a good idea on paper, but has
> anyone seen it work, and would this be something to consider for GHC?
> I'm not suggesting the even/odd versioning scheme, if anyone wonders.
> These don't work so well and nobody tests odd versions.
> ___
> 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
Phabricator upgrade - CI will be down for a short time
Hi *, TL;DR Phabricator will go down for about 5 minutes later today, but the CI will be off for a while longer. I wanted to alert everyone: I'll be upgrading Phabricator shortly this morning, after doing a bunch of testing to make sure our upgrade will go smoothly. Luckily, it will go quite smoothly. The upgrade on the database backup I performed went without a hitch, and everything still seems to work quite well. You shouldn't really notice a huge difference in day-to-day usage... However, it will require redoing some pieces of the CI system, so when I do the upgrade, _Harbormaster won't work for a short time_. That means your patches won't get built - do not be alarmed by this. I tested this before, but we'll have to do some other changes to make it happen 'for real' this time (including some CDN fiddling). Ben also recently rewrote the terrible build script I originally wrote, so I'd like to deploy it instead if possible. Thomas has also rightfully prodded me about some of the current CI complaints, so hopefully these can be sorted out too. This upgrade has been long in the tooth, but luckily you shouldn't notice much beyond a minor hitch here, and CI being gone for a little while. Hopefully it should be done by the end of the day. In the mean time, I'll give Ben access to the newer (20 core) buildbot, so he'll be able to validate your changes quite quickly for integration. I'll reply to this email with updates. -- 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
Re: Phabricator upgrade - CI will be down for a short time
The upgrade is complete. I'll keep everyone updated on the pending Harbormaster situation. On Thu, Jan 21, 2016 at 10:12 AM, Austin Seipp <aus...@well-typed.com> wrote: > Hello *, > > The server will be going down in just a moment for the upgrade. I > turned off jobs earlier this morning so the build queue is now empty. > Hold tight. > > On Thu, Jan 21, 2016 at 7:07 AM, Austin Seipp <aus...@well-typed.com> wrote: >> Hi *, >> >> TL;DR Phabricator will go down for about 5 minutes later today, but >> the CI will be off for a while longer. >> >> I wanted to alert everyone: I'll be upgrading Phabricator shortly this >> morning, after doing a bunch of testing to make sure our upgrade will >> go smoothly. >> >> Luckily, it will go quite smoothly. The upgrade on the database backup >> I performed went without a hitch, and everything still seems to work >> quite well. You shouldn't really notice a huge difference in >> day-to-day usage... >> >> However, it will require redoing some pieces of the CI system, so when >> I do the upgrade, _Harbormaster won't work for a short time_. That >> means your patches won't get built - do not be alarmed by this. >> >> I tested this before, but we'll have to do some other changes to make >> it happen 'for real' this time (including some CDN fiddling). Ben also >> recently rewrote the terrible build script I originally wrote, so I'd >> like to deploy it instead if possible. Thomas has also rightfully >> prodded me about some of the current CI complaints, so hopefully these >> can be sorted out too. >> >> This upgrade has been long in the tooth, but luckily you shouldn't >> notice much beyond a minor hitch here, and CI being gone for a little >> while. Hopefully it should be done by the end of the day. >> >> In the mean time, I'll give Ben access to the newer (20 core) >> buildbot, so he'll be able to validate your changes quite quickly for >> integration. >> >> I'll reply to this email with updates. >> >> -- >> Regards, >> >> Austin Seipp, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ -- 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
Re: Phabricator upgrade - CI will be down for a short time
By the way, this might be a good time to upgrade your Arcanist as well: $ arc upgrade You can then do: $ arc version Which should give you output something like this: $ arc version arcanist b87138356a9c71ad5e08eaa05399d0233529bc71 (15 Jan 2016) libphutil c3fd3a8bb2c319982279ead972354c8bf760145c (14 Jan 2016) On Thu, Jan 21, 2016 at 10:21 AM, Austin Seipp <aus...@well-typed.com> wrote: > The upgrade is complete. I'll keep everyone updated on the pending > Harbormaster situation. > > On Thu, Jan 21, 2016 at 10:12 AM, Austin Seipp <aus...@well-typed.com> wrote: >> Hello *, >> >> The server will be going down in just a moment for the upgrade. I >> turned off jobs earlier this morning so the build queue is now empty. >> Hold tight. >> >> On Thu, Jan 21, 2016 at 7:07 AM, Austin Seipp <aus...@well-typed.com> wrote: >>> Hi *, >>> >>> TL;DR Phabricator will go down for about 5 minutes later today, but >>> the CI will be off for a while longer. >>> >>> I wanted to alert everyone: I'll be upgrading Phabricator shortly this >>> morning, after doing a bunch of testing to make sure our upgrade will >>> go smoothly. >>> >>> Luckily, it will go quite smoothly. The upgrade on the database backup >>> I performed went without a hitch, and everything still seems to work >>> quite well. You shouldn't really notice a huge difference in >>> day-to-day usage... >>> >>> However, it will require redoing some pieces of the CI system, so when >>> I do the upgrade, _Harbormaster won't work for a short time_. That >>> means your patches won't get built - do not be alarmed by this. >>> >>> I tested this before, but we'll have to do some other changes to make >>> it happen 'for real' this time (including some CDN fiddling). Ben also >>> recently rewrote the terrible build script I originally wrote, so I'd >>> like to deploy it instead if possible. Thomas has also rightfully >>> prodded me about some of the current CI complaints, so hopefully these >>> can be sorted out too. >>> >>> This upgrade has been long in the tooth, but luckily you shouldn't >>> notice much beyond a minor hitch here, and CI being gone for a little >>> while. Hopefully it should be done by the end of the day. >>> >>> In the mean time, I'll give Ben access to the newer (20 core) >>> buildbot, so he'll be able to validate your changes quite quickly for >>> integration. >>> >>> I'll reply to this email with updates. >>> >>> -- >>> Regards, >>> >>> Austin Seipp, Haskell Consultant >>> Well-Typed LLP, http://www.well-typed.com/ >> >> >> >> -- >> Regards, >> >> Austin Seipp, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ -- 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
Re: Phabricator upgrade - CI will be down for a short time
Hello *, The server will be going down in just a moment for the upgrade. I turned off jobs earlier this morning so the build queue is now empty. Hold tight. On Thu, Jan 21, 2016 at 7:07 AM, Austin Seipp <aus...@well-typed.com> wrote: > Hi *, > > TL;DR Phabricator will go down for about 5 minutes later today, but > the CI will be off for a while longer. > > I wanted to alert everyone: I'll be upgrading Phabricator shortly this > morning, after doing a bunch of testing to make sure our upgrade will > go smoothly. > > Luckily, it will go quite smoothly. The upgrade on the database backup > I performed went without a hitch, and everything still seems to work > quite well. You shouldn't really notice a huge difference in > day-to-day usage... > > However, it will require redoing some pieces of the CI system, so when > I do the upgrade, _Harbormaster won't work for a short time_. That > means your patches won't get built - do not be alarmed by this. > > I tested this before, but we'll have to do some other changes to make > it happen 'for real' this time (including some CDN fiddling). Ben also > recently rewrote the terrible build script I originally wrote, so I'd > like to deploy it instead if possible. Thomas has also rightfully > prodded me about some of the current CI complaints, so hopefully these > can be sorted out too. > > This upgrade has been long in the tooth, but luckily you shouldn't > notice much beyond a minor hitch here, and CI being gone for a little > while. Hopefully it should be done by the end of the day. > > In the mean time, I'll give Ben access to the newer (20 core) > buildbot, so he'll be able to validate your changes quite quickly for > integration. > > I'll reply to this email with updates. > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ -- 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
Re: runghc fails on Windows with GHC HEAD
Definitely a bug, the in-place runghc should properly use the in-place compiler. Not sure when it regressed though, but it wouldn't be surprising if this has been happening for a while. On Tue, Dec 8, 2015 at 5:19 PM, Ryan Scott <ryan.gl.sc...@gmail.com> wrote: > Actually, this might not be Windows-related at all. It turns out that runghc > was failing because there wasn't a ghc.exe located in inplace/bin (just > ghc-stage1.exe and ghc-stage2.exe). Adding a ghc.exe symlink to > ghc-stage2.exe made runghc.exe work correctly. > > Is this a bug, or the intended behavior? > > Ryan S. > > ___ > 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
Re: The GHC 8.0 feature freeze is coming
On Thu, Dec 3, 2015 at 7:50 AM, Ben Gamari <b...@well-typed.com> wrote: > Luite Stegeman <stege...@gmail.com> writes: > >> Is Simon's remote GHCi patch planned to go in before the fork? I'm still >> working on upgrading GHCJS to work with the master branch, but I haven't >> quite finished yet. This change would clearly require some restructuring of >> GHCJSi and Template Haskell in GHCJS, and I'm not sure if a week is enough >> to test the changes. Also the recent removal of boot file merging >> reintroduces a problem with that I'm not sure can be fixed without adding a >> new hook. >> > Simon, what do you think about this? > > I'm a bit worried that this patch is quite late and breaks users like > Luite. Nevertheless, I am willing to hear arguments for merging. I think this is one we're best off leaving in HEAD. It's a very large change, and I'm a bit scared of bringing it in right at the finish line, so to speak. I think it might be best to just get it in sometime after the branch IMO... >> What's the policy on adding hooks or GHC API tweaks after the freeze? >> > We'll need to work that out when we get to that point. It largely > depends upon how confined and "safe" a change appears to be. That being > said, given how much other churn has happened for this release, I don't > think we want to be sloppy with merge discipline this time around. > > Austin, what do you think? > > Cheers, > > - Ben > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > Hrm. If possible I would like to avoid any breaking changes past the first RC, which has normally been my policy... Generally it's just easier for everyone this way and people typically don't like too many mid-flight changes, once things are in RC-mode. That said, if it's something game-breaking for, say, GHCJS, I'd be open to it. But we should try to fix it ASAP, not in the middle of February. So it would be best if we could find out what hooks or tweaks we needed Very Soon. -- 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
HEADS UP: Moving Phabricator to a new server soon
Hello all, As I said about a week or two ago[1], I still have plans to move the Phabricator server. I'd like to do this tonight. I plan on starting this around 10pm CST or so. This is late at night in the US and quite early in the EU, so I'm hoping to avoid causing problems for anyone. I'll follow up with more emails in response to this one later tonight, as things move forward. Thanks! [1] https://mail.haskell.org/pipermail/ghc-devs/2015-November/010519.html -- 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
HEADS UP: Phabricator will be moving to a new server soon.
Hi *, After talking with Ben today, I'll be moving the Phabricator server to a new host Real Soon. Our current load has outgrown the very basic server we've been using for the past year. It's worked fine, but occasionally it cuts into swap space, causing things like request timeouts or errors. This is particularly noticeable on things like extremely large diffs, which we tend to have a handful of. This is also the first step in a two-part upgrade to the system, which I'd like to carry out sometime within the next week. The next step will be to upgrade our Phabricator to the latest version available upstream. Why have we held off on this? The primary reason is that Harbormaster, the component that does our builds, has undergone a very large rewrite. This was expected to happen, and for the most part the new implementation is *far* better in many measurable ways. It has taken some time, but I think it's now in a usable state for replacing our current system. I didn't want to upgrade it and take away one of the more useful features in the mean time. I will reply to this email with an exact time slot on the server migration. I'll have to push over a few gigs of data and resync it after taking down the HTTP server, so I imagine the downtime window will be small (< 1hr). The upgrade to Phabricator itself will come with many benefits, including: - The patch-build process will be more robust - buildbots should no longer need 'arc patch'. Phabricator will stage diffs in a special 'staging area' repository it manages, and you will be able to 'git pull' patches people post, directly into your tree! - More scalable build machine management. We will transparently be able to add new devices into a 'pool' of machines. For example, there could be 3 ARM devices in the 'ARM pool' and 10 x86 machines in the 'x86 pool'. These pools have machines leased out appropriately to build jobs. That means if you have *any* internet-addressable machine with some spare disk space/CPU, it can be added easily at a low cost, expanding our infrastructure. - A Mac Mini is now available for us to do builds on! I'll be turning it on along with this. And if you have your *own*, internet-addressable Mac - we can use that too! - Better build security, and CI builds for 'master' will be separated (on different machines) from (possibly hostile) patch builds. - We should be able to afford a significantly better set of Linux build machines. Harbormaster can do patches and commits in about ~30 minutes. Why not go for ~10min in the common case? :) - Remarkup now supports 'figlet' and 'cowsay' syntax, allowing you to Moo to your hearts desire, or give someone advice with large, 8-bit retro-style ASCII font rendering. There will be some other fun stuff coming down the pipe soon (a 'merge this patch' button directly in Phabricator, and on-demand build machines for even better performance are two examples). That's all for now! -- 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
Re: too many lines too long
Lots of good replies in this thread. I just wanted to follow up on my suggestion from earlier and give some insight as to why I suggested this: The _only_ reason I really suggested a hard enforcement is because, roughly speaking, maintaining code is roughly ~infinitely more expensive than actually writing it. Abiding by a column limit, if enforced, seems really really trivial to many people and very stupid to reject a patch over. But it is far more useful to the tons of people who may read it later, because the labor balance is asymmetrical. The author of a patch must spend some amount of effort N writing it, where N is roughly linear in the size of the change. But the 'maintenance effort' for that patch is, instead, at least linear in the _lifetime of the project_. Basically: code is very cheap, but maintenance is extremely costly. All that said, I'm not going to lose sleep over this, and it's not a stylistic hill that's worth dying on. And again, if GHC only had a few occurrences of this, it would be easier to fix, but that's not the case, and hampers contributors a bit. If anything, a more pressing stylistic concern is our odd naming scheme that has very little consistency, and that does make it harder to find and read things I think. :) On Mon, Nov 9, 2015 at 3:15 PM, Austin Seipp <aus...@well-typed.com> wrote: > Something like this might be possible. It'd just require implementing > a new arcanist linter, I think, and enabling it in .arclint > > In general I really sympathize with this. The problem 90% of people > hit is that they touch a line that was *already* over 80 columns, so > 'arc lint' warns them and gets annoyed, but they don't want to fix or > split up a bunch of stuff to avoid it. It's an issue of having to do > 'boring work' which nobody likes, and seems very tedious, regardless > of the mechanism of how they do the change. > > Really, I'm more inclined to begin a policy of rejecting reviews that > do not pass the linter. Exceptions can be made, but in general we need > to start *enforcing it* with the red button I think. And it would > require us to be more diligent about merging patches quickly to reduce > the scope of merge conflicts (because fixing an 80col violation > normally, almost always, adds more LOC). > > However, there are people who in general think the contribution > barrier is already too high, and I fear that enforcing this with a > hard rule may make people 'give up' because it seems like a pointless > thing to mandate to block their changes. I'm not sure how people feel > about that, but it is worth keeping in mind the developer economics. > > I hope suggesting the possibility of being more forceful against 80col > violations doesn't derail this too much. :) > > On Mon, Nov 9, 2015 at 3:02 PM, Richard Eisenberg <e...@cis.upenn.edu> wrote: >> Hi devs, >> >> We seem to be uncommitted to the ideal of 80-character lines. Almost every >> patch on Phab I look through has a bunch of "line too long" lint errors. No >> one seems to do much about these. And Phab's very very loud indication of a >> lint error makes reviewing the code harder. >> >> I like the ideal of 80-character lines. I aim for this ideal in my patches, >> falling short sometimes, of course. But I think the current setting of >> requiring everyone to "explain" away their overlong lines during `arc diff` >> and then trying hard to ignore the lint errors during code review is wrong. >> And it makes us all inured to more serious lint errors. >> >> How about this: after `arc diff` is run, it will count the number of >> overlong lines before and after the patch. If there are more after, have the >> last thing `arc diff` outputs be a stern telling-off of the dev, along the >> lines of >> >>> Before your patch, 15 of the edited lines were over 80 characters. >>> Now, a whopping 28 of them are. Can't you do better? Please? >> >> Would this be ignored more or followed more? Who knows. But it would sure be >> less annoying. :) >> >> What do others think? >> >> 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/ -- 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
Re: too many lines too long
Something like this might be possible. It'd just require implementing a new arcanist linter, I think, and enabling it in .arclint In general I really sympathize with this. The problem 90% of people hit is that they touch a line that was *already* over 80 columns, so 'arc lint' warns them and gets annoyed, but they don't want to fix or split up a bunch of stuff to avoid it. It's an issue of having to do 'boring work' which nobody likes, and seems very tedious, regardless of the mechanism of how they do the change. Really, I'm more inclined to begin a policy of rejecting reviews that do not pass the linter. Exceptions can be made, but in general we need to start *enforcing it* with the red button I think. And it would require us to be more diligent about merging patches quickly to reduce the scope of merge conflicts (because fixing an 80col violation normally, almost always, adds more LOC). However, there are people who in general think the contribution barrier is already too high, and I fear that enforcing this with a hard rule may make people 'give up' because it seems like a pointless thing to mandate to block their changes. I'm not sure how people feel about that, but it is worth keeping in mind the developer economics. I hope suggesting the possibility of being more forceful against 80col violations doesn't derail this too much. :) On Mon, Nov 9, 2015 at 3:02 PM, Richard Eisenberg <e...@cis.upenn.edu> wrote: > Hi devs, > > We seem to be uncommitted to the ideal of 80-character lines. Almost every > patch on Phab I look through has a bunch of "line too long" lint errors. No > one seems to do much about these. And Phab's very very loud indication of a > lint error makes reviewing the code harder. > > I like the ideal of 80-character lines. I aim for this ideal in my patches, > falling short sometimes, of course. But I think the current setting of > requiring everyone to "explain" away their overlong lines during `arc diff` > and then trying hard to ignore the lint errors during code review is wrong. > And it makes us all inured to more serious lint errors. > > How about this: after `arc diff` is run, it will count the number of overlong > lines before and after the patch. If there are more after, have the last > thing `arc diff` outputs be a stern telling-off of the dev, along the lines of > >> Before your patch, 15 of the edited lines were over 80 characters. >> Now, a whopping 28 of them are. Can't you do better? Please? > > Would this be ignored more or followed more? Who knows. But it would sure be > less annoying. :) > > What do others think? > > 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
Re: A big patch
Sure. I'm looking at it now; I'll try and get a copy onto Phab shortly. On Tue, Nov 3, 2015 at 10:54 AM, Simon Peyton Jones <simo...@microsoft.com> wrote: > Ben, Austin > > I wonder if one of you could put up a big patch on Phab for me? > > I started about two months ago on a modest refactoring of HsType and > friends, to clarify and tidy up exactly where quantification takes place in > types. Although initially driven by making the implementation of wildcards > more tidy (and fixing a number of bugs), I gradually got drawn into a > pretty big process, which I’ve been doing on and off for quite a long time. > It’s time to finish! > > I could just commit, but it’s good practice to put it on Phab first. Could > you do that for me? > > · It’s in branch wip/spj-wildcard-refactor > > · It’s up to date with HEAD from a day or two back > > · The principal driving change is described in Note [HsType binders] > in HsType. Worth reading! Those data type changes drive almost everything > else. > > · There are some uninteresting knock-on changes in Haddock, which > are in wip/spj-wildcard-refactor in utils/haddock. I’ve done the submodule > commit thing so the ghc-repo branch should refer correctly to the Haddock > branch. > > · The commit log on the branch is of no interest; just dump it > entirely. I will write a proper commit message in due course. > > · A handful of tests are failing. I’m working on that, but I want > to get this onto Phab now awyway. > > You could include this email as the Phab description. > > Thanks! > > Simon -- 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
Re: [ANNOUNCE] GHC 7.10.3 release candidate 1
Yeah, I really need to work a trigger into the downloads machine so that we can clear the CDN cache when we upload/update files... It's about a mile down my TODO list though (since it bites somewhat rarely for these cases) - so anyone who wants to do a little JSON API chatting with Fastly should talk to me. :) On Mon, Nov 2, 2015 at 2:49 PM, Ben Gamari <b...@smart-cactus.org> wrote: > Páli Gábor János <pali.ga...@gmail.com> writes: > >> 2015-11-02 19:27 GMT+01:00 Joachim Breitner <m...@joachim-breitner.de>: >>> Isn’t such a mail a requirement for those wo build the various binaries >>> to get active in the first place? >> >> I think that would require at least an accessible source tarball in >> the first place :-) But apparently there are no files under the >> specified directory. >> > It may appear that way but this is merely an unfortunate side-effect of > our content delivery network. Try adding some extra `/` characters to > the URL, e.g., > > https://downloads.haskell.org/~ghc/7.10.3-rc1// > > This is usually enough to fool the CDN info refreshing. > > Cheers, > > - Ben > > ___ > 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
Re: [ANNOUNCE] GHC 7.10.3 release candidate 1
Yeah, so in the past Tier 1 platforms (OS X, Win, Lin, FreeBSD) are always available, but I rarely (if ever) held up RCs for anything besides that. I do have a list of people to alert, though... (Karel takes care of Solaris for example as time permits). Even then, I wasn't always the one doing the builds... Gabor takes care of FreeBSD for me. And Mark was doing the OS X builds before, because he had an excellent test farm that allowed him to test a release across an array of OS X versions. Right now we're working on getting a Mac. I'll have short-term access to one by tomorrow thankfully, and be getting a new machine soon. So hopefully this won't be a problem going forward, although some knowledge transfer from Mark might be in order. :) On Mon, Nov 2, 2015 at 12:27 PM, Joachim Breitner <m...@joachim-breitner.de> wrote: > Hi, > > Am Montag, den 02.11.2015, 13:21 -0500 schrieb Richard Eisenberg: >> Personally, I would love delaying announcements such as these until >> binaries are available, at least for Linux, Mac, and Windows. > > it’s a release candidate, announced on the developer mailing list. > Isn’t such a mail a requirement for those wo build the various binaries > to get active in the first place? Or is all done by Ben these days. > > I’m happy to get the announcement as quickly as possible, as I was > waiting for the source tarball :-) > > Greetings, > Joachim > > > -- > Joachim “nomeata” Breitner > m...@joachim-breitner.de • http://www.joachim-breitner.de/ > Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F > Debian Developer: nome...@debian.org > > > ___ > 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
Re: Can't build on Windows
(Resending to list properly) Hrm, I can't see anything off hand in the past few weeks that would have caused this at a glance. Can you try bisecting it perhaps? You can probably do something like: $ git bisect start $ git bisect bad $ git bisect good dcc342870b4d8a739ccbed3ae26e84dcc3579914 $ git bisect run ./validate This will probably take a while, though. The commit 'dcc342870b4d8a739ccbed3ae26e84dcc3579914' was chosen randomly, however. Any idea when this started happening? If it's the past few weeks, the above might work On Mon, Oct 26, 2015 at 4:19 PM, Simon Peyton Jones <simo...@microsoft.com> wrote: > Gurgah. GHC is broken on my windows laptop. See below. Anyone have any > ideas? Frustrating. > > Oddly the symbol is defined in the .exe > > bash$ nm inplace/bin/ghc-stage2.exe | grep stg_upd_frame > > 02c248e0 T _stg_upd_frame_info > > This is admittedly on a branch that I have modified; but I have only > modified stuff in the front end, nothing in the RTS etc. I suppose I will > try to build a unmodified HEAD too. > > can anyone help? Thanks! > > Simon > > > > bash$ c:/code/HEAD/inplace/bin/ghc-stage2 --interactive > > GHCi, version 7.11.20151026: http://www.haskell.org/ghc/ :? for help > > ghc-stage2.exe: unable to load package `ghc-prim-0.4.0.0' > > ghc-stage2.exe: > C:\code\HEAD\libraries\ghc-prim\dist-install\build\HSghc-prim-0.4.0.0.o: > unknown symbol `_stg_upd_frame_info' > > HEAD $ > > > ___ > 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
Re: Request to reopen the issue of 7.8 on El Capitan
Thank you Mark! I was going to ask you since I know you have like 6 OS X virtual machines, so you have much better coverage. :) I'm getting my hands on a mac now to test it, and I'll let everyone know when it's ready (I have to do the other annoying stuff of like making the proper bug and a milestone, etc.) On Fri, Oct 16, 2015 at 12:33 AM, Mark Lentczner <mark.lentcz...@gmail.com> wrote: > I can build a 7.8.5 binary for release if someone can put the patch in the > GHC tree. (Having a soft spot in my heart for the 7.8 line!) > I'm leaving on a short trip, and will be back on Tuesday and build middle of > next week. > - Mark -- 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
Re: Kind equalities update
Hey Richard, Thanks a lot. I'm very eager to see this land ASAP! It's exciting. But... Looking at the page, I really, really am still not a fan of using 'type' in place of *, and I still think (as I mentioned on Reddit I believe) that 'Type' is the best choice for this. I mentioned this to Simon earlier, and I kind of hate to make even more work for you, but my basic reasoning is: - '*' is not a good choice because it's a lexical wart. But in terms of 'theory', the statement '* :: *' is completely OK, or 'type :: type' or or 'U :: U' or 'Type :: Type'. That is, the reason star is bad is because it's a lexical problem that leads to weird ambiguous parsing, not that it's necessarily confusing or using any particular word I think. - 'type' is not a good choice, because while in theory any name is kind of arbitrary, it's very confusing for Haskell IMO - we have _chosen_ the distinction between type variables and type constructors through the use of capitalization. I think it's a bit strange to say '*' or what have you has type 'type' yet 'type' is not an actual variable, nor a keyword in a meaningful sense, but an actual type on its own. Yet 0-arity type constructors of all sorts (like Int or Bool) have this lexical capitalization! That is, 'type' isn't confusing because it's a lexical wart, or has bad parsing - but because it violates how we syntactically distinguish type variables from constructors of types. - (Correct if I'm wrong) As far as I understand, 'Type' doesn't need to be reserved unless -XTypeInType is enabled, correct? I think it is fairly reasonable to say that extensions may take up parts of your namespace should you enable them - for example, -XStaticPointers steals the term 'static' for itself, which I think is OK! - As far as code breakage goes, I think the prior point makes the outright breakage minimal-to-none if true, which is great. Even GHC uses the name `Type`, but we wouldn't even be able to use -XTypeInType for another few years at best! So we have plenty of time to address that when we want to use it... I suppose #2 is a little 'feels-y', since 'violating' how we expect to read Haskell is maybe subjective. But I figure I might as well make a last ditch effort at the cost of a little stirring. I think that mostly sums it up. I'm still reading over the full page, I just got to this point and decided to shout. (Wadler's Law strikes again!) On Tue, Oct 13, 2015 at 12:32 PM, Richard Eisenberg <e...@cis.upenn.edu> wrote: > Hi devs, > > In a chat with Simon this morning about kind equalities, he expressed that > you all might want to know about the plans for kind equalities in 8.0. > > The wiki page both for user-facing changes and for implementation notes is > here: https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1 > It is my intent that all user-facing changes mentioned there will be > available in 8.0. I am hard at work getting my branch ready to merge, and > hope to do so mid-November. > > Note: this is almost fully backward-compatible. Here are some areas where > there are known incompatibilities: > - Template Haskell will have to be updated. But there's a raft of changes > there, anyway. > - GHC will do a more careful job of checking for termination of instances > regarding the use of kind variables. This may require new > UndecidableInstances declarations. But the fact that these definitions (like > `instance (C a, C b) => C (a b)` for a polykinded C) were accepted previously > could be called a bug. > > That's actually all I know of so far. > > You can take kind equalities for a spin at github.com/goldfirere/ghc, on the > "nokinds" branch. Note that this hasn't been merged with `master` since > December of last year, so expect a little strange behavior compared with > 7.10. These wrinkles will get smoothed out, of course. > > 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
Re: Request to reopen the issue of 7.8 on El Capitan
I wasn't aware it completely broke on El Capitan, but I think that's a pretty extreme case (where a completely usable release simply breaks because a hugely popular OS changes) that would warrant a 7.8.5 release, to be honest. Presumably, this would really be the only change, so mostly OS X users would be affected by its availability. In general people like to use the last 3 GHC releases anyway, and we haven't even *released* 8.0 yet. And at that point, 7.8.x will be the last 'in the chain' - so I can assume people would _still_ want 7.8 on OS X presumably, even more than a year from today until 8.2! At that point (8.2-ish era) if Apple keeps breaking things, we may not do another release, but in this case I think the timescale for user/library support is probably worth it. Otherwise OS X users are going to have to fix it themselves, and it might be ugly (propagating random fixes around the internet isn't going to work well, and we'll just keep getting bug reports about this because of that - we've already done this dance with OS X.) I'll note this down and think about it more this week, since we'd like to get 7.10.3 out soon as well... On Tue, Oct 13, 2015 at 7:55 PM, Adam Foltzer <acfolt...@gmail.com> wrote: > 7.8.4 is was released only ten months ago; it surprises me that we'd > consider it acceptable to have such a recent release fail to work on new > machines when the fix is so small as to not even require a patch to the > source tree. In particular, I remember hearing proponents of 7.10's changes > reassure detractors that if they choose, they can continue to use 7.8.4, > which is no longer an option. > > I'd ask that we (1) reconsider the decision to stop 7.8 releases, and (2) if > we stand by the decision, document the mitigations for users who would like > to build their own working version of the compiler. I just finished a build > from a source dist with `unix-2.7.1.0` and it still triggers the El Capitan > error, so I suspect it's not as simple as just dropping the new package into > `/libraries/unix/`. > > On Tue, Oct 13, 2015 at 4:19 PM, Carter Schonwald > <carter.schonw...@gmail.com> wrote: >> >> There are no plans to do a new 7.8 release at this Time. Even doing a >> point release for 7.10.3 is still speculative. >> >> We should reflect the capitan issue in the installation documentation. >> And or remark that only 7.10 or newer is supported on El Capitan. >> >> If a user needs a 7.8 build that works on capitan, they will need to build >> a source dist with an updated UNIX package. >> >> >> On Tuesday, October 13, 2015, Adam Foltzer <acfolt...@gmail.com> wrote: >>> >>> Hello, >>> >>> The issue was brought up on this list [1] that the released versions of >>> GHC 7.8 do not work on El Capitan due to an older `unix` package. In a >>> subsequent GHC weekly news [2], it was announced that since El Capitan >>> wasn't yet released, it wasn't worthwhile to put more developer time into >>> 7.8. >>> >>> Now that El Capitan is out, and the existing 7.8 binaries continue to not >>> work, I'd like to reopen this issue and request a point release with an >>> updated `unix` package. >>> >>> Thank you, >>> >>> Adam Foltzer >>> Research Engineer >>> Galois, Inc. >>> >>> [1]: https://mail.haskell.org/pipermail/ghc-devs/2015-July/009403.html >>> [2]: >>> https://ghc.haskell.org/trac/ghc/blog/weekly20150721#MacOSXElCapitansupport > > > > ___ > 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
HEADS UP (devs, users): 8.0.1 Roadmap
Hi *, I've returned from vacation, and last week Simon, Simon and I met up again after a long break, and talked a bit about the upcoming release. The good news is that it is going to be an exciting one! The flip side is, there's a lot of work to be done! The current plan we'd roughly like to follow is... - November: Fork the new `ghc-8.0` STABLE branch - At this point, `master` development will probably slow as we fix bugs. - This gives us 2 months or so until branch, from Today. - This is nice as the branch is close to the first RC. - December: First release candidate - Mid/late February: Final release. Here's our current feature roadmap (in basically the same place as all our previous pages): https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1 As time goes on, this page will be updated to reflect Reality™ and track it as closely as possible. So keep an eye on it! It's got the roadmap (near top) and large bug list (bottom). Now, there are some things we need, so depending on who you are, please... - *Users*: please look over the bug list! If there's a bug you need fixed that isn't there, set it to the 8.0.1 milestone (updated in Trac). If this bug is critical to you, please let us know! You can bump the priority (if we disagree, or it's workaround-able, it might get bumped down). We just need a way to see what you need, so please let us know somehow! As a reminder, our regular policy is this: if a bug is NOT marked highest or high priority, it is essentially 100% the case we will not look at it. So please make sure this is accurate. Or if you can, write a patch yourself! - *Developers*: double check the roadmap list, _and if you're responsible for something, make sure it is accurate!_ There are some great things planned to land in HEAD, but we'll have to work for it. Onward! - A better LLVM backend for Tier-1 platforms - Types are kinds and kind equality - Overloaded record fields! - Enhancements to DWARF debugging - ApplicativeDo - ... and many more... Thanks everyone! -- 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
HEADS UP: Need 7.10.3?
Hi *, (This is an email primarily aimed at users reading this list and developers who have any interest). As some of you may know, there's currently a 7.10.3 milestone and status page on our wiki: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.3 The basic summary is best captured on the above page: "We have not yet decided when, or even whether, to release GHC 7.10.3. We will do so if (but only if!) we have documented cases of "show-stoppers" in 7.10.2. Namely, cases from users where - You are unable to use 7.10.2 because of some bug - There is no reasonable workaround, so you are truly stuck - We know how to fix it - The fix is not too disruptive; i.e. does not risk introducing a raft of new bugs" That is, we're currently not fully sold on the need for a release. However, the milestone and issue page serve as a useful guide, and also make it easier to keep track of smaller, point-release worthy issues. So in the wake of the 8.0 roadmap I just sent: If you *need* 7.10.3 because the 7.10.x series has a major regression or problem you can't work around, let us know! - Find or file a bug in Trac - Make sure it's highest priority - Assign it to the 7.10.3 milestone - Follow up on this email if possible, or edit it on the status page text above - it would be nice to get some public feedback in one place about what everyone needs. Currently we have two bugs on the listed page in the 'show stopper category', possibly the same bug, which is a deal-breaker for HERMIT I believe. Knowing of anything else would be very useful. Thanks all! -- 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
Re: HEADS UP: interface file format change, full rebuild required
A long time coming. Congratulations! On Wed, Sep 2, 2015 at 10:57 PM, Jan Stolarek <jan.stola...@p.lodz.pl> wrote: > I just pushed injective type families patch, which changes interface file > format. Full rebuild of > GHC is required after you pull. > > Jan > > ___ > 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
Re: Proposal: accept pull requests on GitHub
ry single incoming patch, based on the source file paths in the tree, using the Owners tool. Technically, we could do that today if we wanted, it's just a little more effort to add more Herald rules. This will be far, far more robust than anything GitHub can offer, and eliminates point #3. - Styling, linting etc errors being included, because reviews are hard to create: This is tangential IMO. We need to just bite the bullet on this and settle on some lint and coding styles, and apply them to the tree uniformly. The reality is *nobody ever does style changes on their own*, and they are always accompanied by a diff, and they always have to redo the work of pulling them out, Phab or not. Literally 99% of the time we ask for this, it happens this way. Perhaps instead we should just eliminate this class of work by just running linters over all of the source code at once, and being happy with it. Doing this in fact has other benefits: like `arc lint` will always _correctly_ report when linting errors are violated. And we can reject patches that violate them, because they will always be accurate. - As for some of the quotes, some of them are funny, but the real message lies in the context. :) In particular, there have been several cases (such as the DWARF work) where the idea was "write 30 commits and put them on Phabricator". News flash: *this is bad*, no matter whether you're using Phabricator or not, because it makes reviewing the whole thing immensely difficult from a reviewer perspective. The point here is that we can clear this up by being more communicative about what we expect of authors of large patches, and communicating your intent ASAP so we can get patches in as fast as possible. Writing a patch is the easiest part of the work. And more: - Clean up the documentation, it's a mess. It feels nice that everything has clear, lucid explanations on the wiki, but the wiki is ridiculously massive and we have a tendancy for 'link creep' where we spread things out. The contributors docs could probably stand to be streamlined. We would have to do this anyway, moving to GitHub or not. - Improve the homepage, directly linking to this aforementioned page. - Make it clear what we expect of contributors. I feel like a lot of this could be explained by having a 5 minute drive-by guide for patches, and then a longer 10-minute guide about A) How to style things, B) How to format your patches if you're going to contribute regularly, C) Why it is this way, and D) finally links to all the other things you need to know. People going into Phabricator expecting it to behave like GitHub is a problem (more a cultural problem IMO but that's another story), and if this can't be directly fixed, the best thing to do is make it clear why it isn't. Those are just some of the things OTTOMH, but this email is already way too long. This is what I mean though: fixing most of these is going to have *seriously smaller cost* than moving to GitHub. It does not account for "The GitHub factor" of people contributing "just because it's on GitHub", but again, that value has to outweigh the other costs. I'm not seriously convinced it does. I know it's work to fix these things. But GitHub doesn't really magically make a lot of our needs go away, and it's not going to magically fix things like style or lint errors, the fact Travis-CI is still pretty insufficient for us in the long term (and Harbormaster is faster, on our own hardware, too), or that it will cause needlessly higher amounts of spam through Trac and GitHub itself. I don't think settling on it as - what seems to be - a first resort, is a really good idea. On Wed, Sep 2, 2015 at 4:09 PM, Niklas Hambüchen <m...@nh2.me> wrote: > On 02/09/15 22:42, Kosyrev Serge wrote: >> As a wild idea -- did anyone look at /Gitlab/ instead? > > Hi, yes. It does not currently have a sufficient review functionality > (cannot handle multiple revisions easily). > > On 02/09/15 20:51, Simon Marlow wrote: >> It might feel better >> for the author, but discovering what changed between two branches of >> multiple commits on github is almost impossible. > > I disagree with the first part of this: When the UI of the review tool > is good, it is easy to follow. But there's no open-source implementation > of that around. > > I agree that it is not easy to follow on Github. > ___ > 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
NOTE: Going on a vacation for a while...
Hi *, A few weeks ago, as the close of the 7.10.2 release came closer, I decided to take a vacation; one I've needed for a little while now. Well, it's been a bit long in the tooth with the last RC (and my terrible home internet has blocked me for the past day at least) - but that time has come! After the release of 7.10.2 RC2 today, I'm provisionally be gone until the end of August. This week is basically done, so I'm mostly going to be gone. I plan on making my return at ICFP 2015, more or less (end of August in Vancouver). I say gone with finger quotes, because I will still be around - but not doing GHC stuff every day for work. I am still part of the Haskell.org Infrastructure team, so I'm still going to be around every week. You can still catch me on IRC, email, or elsewhere. I'll just have a higher latency. My laptop will be around. If you have a problem with Phabricator, emails seem to not get delivered, or server instability - please do CC me directly in an email! That'll make sure it hits my inbox so I can at least respond by the next day. I hope to actually fix some infrastructure issues, so again, please do contact me if something is wrong. But for GHC? In particular, for the interim, Ben Gamari, who has recently joined us at Well-Typed, will be filling in for me. Ben has a lot of experience working on GHC and we're happy to have him - he'll be doing the final 7.10.2 release here in a week or two I think, and I'm sure things will go just fine in the mean time after that. Ben is already subscribed to every GHC patch that comes in on Phabricator, so he'll be doing a lot of code review for the things that come through Phabricator. You can keep me on the reviewer list as a habit - you don't need to change anything here. In the aftermath of this after August, I'll return, and Ben and I plan to keep doing our thing together, and we'll all move towards 7.12.1. But in the mean time, I'll be relaxing. I might find some time for a recreational patch or two as well, but we'll see! Thanks * -- 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
ANNOUNCE: GHC 7.10.2 Release Candidate 2
We are pleased to announce the first release candidate for GHC 7.10.2: https://downloads.haskell.org/~ghc/7.10.2-rc2 https://downloads.haskell.org/~ghc/7.10.2-rc2/docs/html/ This includes the source tarball and bindists for Windows, and Debian Linux. FreeBSD, OS X and Solaris binaries will follow soon. These binaries and tarballs have an accompanying SHA256SUMS file signed by my GPG key id (0x3B58D86F). We plan to make the 7.10.2 final release in a week or two - so please test as much as possible; bugs are much cheaper if we find them before the release! -- 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
Re: [Diffusion] [Build Failed] rGHCc45f8ceb0de0: Elaborate test for Trac #10403
Strange stuff. I just pushed this, so the builds should start going green again soon. On Fri, Jun 19, 2015 at 2:39 AM, Simon Peyton Jones simo...@microsoft.com wrote: I think 4945 is failing again -- although not on my machine. Can someone mark it expect_broken again? I'm on a train S | -Original Message- | From: nore...@phabricator.haskell.org | [mailto:nore...@phabricator.haskell.org] | Sent: 19 June 2015 00:09 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHCc45f8ceb0de0: Elaborate test for | Trac #10403 | | Harbormaster failed to build B4473: rGHCc45f8ceb0de0: Elaborate test for | Trac #10403! | | BRANCHES | master | | USERS | simonpj (Author) | GHC - Testsuite (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHCc45f8ceb0de0 | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Testsuite ___ 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
Re: ANNOUNCE: GHC 7.10.2 Release Candidate 1
Yes, as noted on the ticket, I've bumped the priority and we'll be looking into this - and hopefully have a fix in time for 7.10.2. There are some similar tickets where we get large explosions of terms, so it may be in the same ballpark. On Sun, Jun 14, 2015 at 11:18 PM, Rob Everest rober...@cse.unsw.edu.au wrote: We plan to make the 7.10.2 final release at the end of this coming week - so please test as much as possible; bugs are much cheaper if we find them before the release! Could I possibly draw attention to #10491? It's a regression in the simplifier that is causing considerable pain for Accelerate, namely a compile time of many hours for a 300 line module. It would be unfortunate if this couldn't be resolved for the 7.10.2 release. -- 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
Re: ANNOUNCE: GHC 7.10.2 Release Candidate 1
Not in particular - I guess we didn't get everything we precisely needed for the RC. I've filed a ticket: #10530 On Sun, Jun 14, 2015 at 10:25 PM, Andrés Sicard-Ramírez a...@eafit.edu.co wrote: On 14 June 2015 at 19:16, Austin Seipp aus...@well-typed.com wrote: We are pleased to announce the first release candidate for GHC 7.10.2: Since transformers is a GHC-include library, is there any particular reason why GHC 7.10.2 RC1 didn't include the latest version of the transformers library, i.e. transformers-0.4.3.0? -- Andrés -- 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
Re: ANNOUNCE: GHC 7.10.2 Release Candidate 1
Grrr... I could have *swore* I fixed it this time, and even to be double-sure I did a `git clean` and everything.. Yes, we should have a sanity check somewhere, and also double check the testsuite is clean. I'll noodle on it for the release (since apparently the last version didn't work). On Mon, Jun 15, 2015 at 6:11 AM, Jens Petersen juhpeter...@gmail.com wrote: We are pleased to announce the first release candidate for GHC 7.10.2: Thanks! https://downloads.haskell.org/~ghc/7.10.2-rc1 The testsuite src tarball still (like in 7.10.1) includes this large binary executable file: -rwxrwxr-x a/a 7873779 Mar 16 17:34 2015 ghc-7.10.0.20150316/testsuite/mk/ghc-config Can it be removed it for 7.10.2? Jens ps It might be good to have some tarball size sanity check to avoid these kind of problems recurring. -- 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
ANNOUNCE: GHC 7.10.2 Release Candidate 1
We are pleased to announce the first release candidate for GHC 7.10.2: https://downloads.haskell.org/~ghc/7.10.2-rc1 https://downloads.haskell.org/~ghc/7.10.2-rc1/docs/html/ This includes the source tarball and bindists for Windows, Mac OS X, and Debian Linux. FreeBSD and Solaris binaries will follow soon. These binaries and tarballs have an accompanying SHA256SUMS file signed by my GPG key id (0x3B58D86F). We plan to make the 7.10.2 final release at the end of this coming week - so please test as much as possible; bugs are much cheaper if we find them before the release! -- 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
Test message, please ignore
If you can see this, it probably works. -- 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
ANNOUNCE: GHC 7.10.2 Release Candidate 1
We are pleased to announce the first release candidate for GHC 7.10.2: https://downloads.haskell.org/~ghc/7.10.2-rc1 https://downloads.haskell.org/~ghc/7.10.2-rc1/docs/html/ This includes the source tarball and bindists for Windows, Mac OS X, and Debian Linux. FreeBSD and Solaris binaries will follow soon. These binaries and tarballs have an accompanying SHA256SUMS file signed by my GPG key id (0x3B58D86F). We plan to make the 7.10.2 final release at the end of this coming week - so please test as much as possible; bugs are much cheaper if we find them before the release! -- 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
Test message, please ignore
If you can see this, it probably works. -- 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
Re: Broken build: Documentation mistake
I'm afraid I have no idea... I pushed several documentation patches to the ghc-7.10 branch: https://phabricator.haskell.org/diffusion/GHC/history/ghc-7.10/ Can you try reverting some of those 'More 7.10.2 release notes commits'? That's the only thing I can think that might be the culprit... On Sun, Jun 14, 2015 at 10:08 AM, Páli Gábor János pali.ga...@gmail.com wrote: Hi Austin, Looks like the build is failing again, with another error message from LaTeX [1]: snip Build users_guide.ps latex failed users_guide.tex:17168: Undefined control sequence \Colon. users_guide.tex:17168: leading text: } Unexpected error occured Missing character #x2919; Missing character #x291a; Missing character #x291b; Missing character #x291c; [ -f docs/users_guide/users_guide.ps ] docs/users_guide/ghc.mk:26: recipe for target 'docs/users_guide/users_guide.ps' failed gmake[1]: *** [docs/users_guide/users_guide.ps] Error 1 Makefile:102: recipe for target 'all' failed gmake: *** [all] Error 2 Do you have any ideas why this is happening? Thanks, Gábor [1] http://haskell.inf.elte.hu/builders/freebsd-i386-head/650/10.html -- 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
Re: GHC build failure
OK, so I think the reason is because this commit:
https://phabricator.haskell.org/rGHC3b55659d4f54e503f4e550d762bc55a2650ed13d
actually changed the ghc-bin.cabal.in file under ghc/. Which we use to
generate ghc-bin.cabal, which is actually fed to Cabal to build the
'ghc' executable. The build system generates these files from .in
files (from autoconf) very early so 'make' doesn't track the
dependencies here, and it can't rebuild the files from the .in files.
That means you need to regenerate the .cabal file from the .in file to
pick up 'deepseq', which was added to Build-Depends.
The reason this gets 'fixed' with ./validate is precisely because
validate cleans the entire tree and re-boots it before continuing. So
it happens automatically.
TL;DR you should re-./boot and re-./configure again, as Herbert said.
In practice this shouldn't cost you much time, because even though GHC
will re-run the build steps, most of the results of those steps will
be cached compilations, which it can skip. If that doesn't work, then
distclean and start over - which sucks, but you won't have to do it
again ('make' will work fine to rebuilt).
On Thu, Jun 11, 2015 at 11:23 AM, Simon Peyton Jones
simo...@microsoft.com wrote:
I got the same thing on my 7.10 branch. But when I said sh validate (which
starts with make distclean etc) all was well.
S
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
| Wolfgang Jeltsch
| Sent: 11 June 2015 16:20
| To: ghc-devs@haskell.org
| Subject: Re: GHC build failure
|
| Hi again,
|
| it still fails with the same error message.
|
| All the best,
| Wolfgang
|
| Am Donnerstag, den 11.06.2015, 18:17 +0300 schrieb Wolfgang Jeltsch:
| Hi,
|
| I did not care about the submodules; so this could be the reason of
| the failure. That said, running
|
| git submodule update --init
|
| now only showed a message regarding utils/haddock, which causes me
| some doubts that it will really fix the issue with deepseq. Let’s
| see.
|
| All the best,
| Wolfgang
|
| Am Donnerstag, den 11.06.2015, 16:49 +0200 schrieb Thomas Miedema:
|Maybe you forgot `git submodule init` or `git submodule update`?
| See
|this page for a simple trick to never forget again:
|
| https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodu
|les#UsingaGitalias
|
|
|If that didn't work, do a `make maintainer-clean` and try again.
|
|
|
|On Thu, Jun 11, 2015 at 4:37 PM, Wolfgang Jeltsch
|g9ks1...@acme.softbase.org wrote:
|Hi,
|
|I just updated my GHC HEAD copy via git pull and tried to
|rebuild GHC
|with BuildFlavour set to devel2. I got the following error
|message:
|
|ghc/InteractiveUI.hs:68:8: error:
|Could not find module ‘Control.DeepSeq’
|It is a member of the hidden package
|‘deepseq-1.4.1.1@deeps_6vMKxt5sPFR0XsbRWvvq59’.
|Use -v to see a list of the files searched for.
|
|Any ideas what to do?
|
|All the best,
|Wolfgang
|
|
| ___
| ghc-devs mailing list
| ghc-devs@haskell.org
| http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
|
|
| ___
| ghc-devs mailing list
| ghc-devs@haskell.org
| http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
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
GHC Weekly News - 2015/06/10
(This post is available online at https://ghc.haskell.org/trac/ghc/blog/weekly20150610) Hi *, Welcome for the latest entry in the GHC Weekly News. The past week, GHC HQ met up for a quick catch up on 7.10.2 (which you'll want to read up on, see below), and some other technical nonsense about some work we've been doing. As a result the current weekly notes have been slow - the current priority is the next release though, which leads us to... == 7.10.2 status == 7.10.2 is '''going to be out soon''' - our current plan is to have a release candidate on '''the weekend of Saturday the 13th''', and the final release '''the next week'''. That means if you want something fixed, you'd better hollar ''very'' soon, or we're just not going to get to it! If you're wondering what's currently been fixed/scheduled, the [https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2 status page] shows the current set of tickets we've fixed and plan on fixing. == List chatter == - Edward Z. Yang has written up a new wiki page to clearly explain and document all the various confusion around package keys, package ids, etc as a result of all the new Backpack work. If you're interested in this, it's definitely worth a read. https://mail.haskell.org/pipermail/ghc-devs/2015-June/009173.html - Mark Lentczner sez: The Haskell Platform has finally outgrown Travis-CI, now going beyond the 50 minute build limit. Mark asks what alternatives we can use going forward. https://mail.haskell.org/pipermail/ghc-devs/2015-June/009174.html - Jan Stolarek asks: in some cases, GHC will generate default instances or values, but that source code has no textual information location (for example, consider an `instance` clause without the `where`) - what do people think about fixing this, and are there anythings to look out for? https://mail.haskell.org/pipermail/ghc-devs/2015-June/009202.html - David Luposchainsky has opened a new thread - about moving `fail` out of `Monad` and into its own typeclass, `MonadFail`. This change is a request that's very long in the tooth (older than the AMP or FTP changes by a landslide), but David's proposal has a clearly set out goal to tackle compatibility, warnings, and implementation. https://mail.haskell.org/pipermail/ghc-devs/2015-June/009186.html == Noteworthy commits == - Commit 19ec6a84d6344c2808d0d41da11956689a0e4ae9 - Fix for CAF retention when dynamically loading unloading code - Commit 4a0b7a10442eec3747d5f95ef186a79bb0648754 - Build: run autoreconf jobs in parallel == Closed tickets == #10460, #7672, #9252, #9506, #10294, #5316, #10408, #10386, #9960, #10145, #9259, #10386, #9507, #8723, #10442, #5014, #4215, #10443, #8244, #10499, #10500, #10428, #10488, #10489, #10406, #10501, #10441, #10406, #10502, #9101, #9663, and #9945. -- 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
Re: Broken build: Documentation mistake
Yes, please try the patch here - I think it should fix it (it carries an explanation too): https://phabricator.haskell.org/D970 On Tue, Jun 9, 2015 at 2:10 AM, Páli Gábor János pali.ga...@gmail.com wrote: 2015-06-08 23:19 GMT+02:00 Austin Seipp aus...@well-typed.com: Sigh. I'll revert this. I couldn't reproduce this on my two machines, but I should have figured it would have broken something. I took a chance. :) So the documentation builds fine for you? I believed the FreeBSD builders failed only because the they always try to build the documentation as well, while that might not be the part of the standard validation pass. I'll try it on FreeBSD before pushing. I can help with this, you do not have to struggle with FreeBSD just because of this -- just send me the patch to try. However, I think this may not be fully an operating system-related issue, perhaps the documentation toolchain is not up-to-date enough. For example, I have this version of the latex command installed currently: pdfTeX 3.14159265-2.6-1.40.15 (Web2C 2014) kpathsea version 6.2.0 [..] Compiled with libpng 1.6.16; using libpng 1.6.16 Compiled with zlib 1.2.3; using zlib 1.2.3 Compiled with xpdf version 3.03 -- 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
Re: Broken build: Documentation mistake
Sigh. I'll revert this. I couldn't reproduce this on my two machines,
but I should have figured it would have broken something. I took a
chance. :)
I'll try it on FreeBSD before pushing.
On Mon, Jun 8, 2015 at 2:07 PM, Páli Gábor János pali.ga...@gmail.com wrote:
Hello there,
Looks like there is some problem with one of the recent changes to The
User's Guide source code as it cannot be built any more [1] (since
about June 4). Here is the error message, hopefully it helps with
fixing the cause:
[..]
Build users_guide.ps
latex failed
users_guide.tex:15584: Cannot determine size of graphic in
docs/users_guide//prof_scc.png (no BoundingBox).
users_guide.tex:15584: leading text:
...width=645pt,height=428pt]{prof_scc.png}
Unexpected error occured
[ -f docs/users_guide/users_guide.ps ]
docs/users_guide/ghc.mk:26: recipe for target
'docs/users_guide/users_guide.ps' failed
gmake[1]: *** [docs/users_guide/users_guide.ps] Error 1
Makefile:102: recipe for target 'all' failed
gmake: *** [all] Error 2
Thanks,
Gábor
[1] http://haskell.inf.elte.hu/builders/freebsd-amd64-head/652/10.html
___
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
GHC Weekly News - 2015/06/03
(This post is available online at https://ghc.haskell.org/trac/ghc/blog/weekly20150603) Hi *, It's that time once again - to get some info on what's happening in the world of GHC! It's been a quiet few weeks as a UK Holiday punted one of GHC HQ's meetings off, and this week we were only partially there. The main point of discussion was 7.10.2, and continuing work on compiler performance. The good news is, the past few weeks have seen good work on both these fronts! == 7.10.2 status == 7.10.2 is swimming along very nicely - the [https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2 status page] shows the current set of tickets we've fixed and plan on fixing. Not much has changed from last time, except we've fixed even more bugs! We're currently sitting at about 85 bugs fixed, some of them pretty important - code generation bugs, compiler performance fixes, some RTS and event manager work. Your author is actually quite happy with what GHC 7.10.2 looks like, at this rate. == List chatter == - Austin Seipp announced that GHC 7.10.2 will be release soon, and developers/users should get bugs they want fixed reported to us ASAP so we can do something. https://mail.haskell.org/pipermail/ghc-devs/2015-June/009150.html - Mark Lentczner announced a Haskell Platform alpha featuring GHC 7.10.2 https://mail.haskell.org/pipermail/ghc-devs/2015-June/009128.html - Facundo Dominguez asks: sometimes we want to create a `static` pointer in a function with a local definition, how can we do that? The current problem is the desugarer gets in the way and current approaches are currently rejected, but Facundo has some ideas/questions about a fix. https://mail.haskell.org/pipermail/ghc-devs/2015-May/009110.html - David Macek has made great progress on getting native MSYS2 packages for windows working - which should be a great boon to all our Windows users! https://mail.haskell.org/pipermail/ghc-devs/2015-May/009089.html - Joachim Breitner announced the new GHC performance dashboard, which can be used to track all of GHC's performance-based tests over time. Whoohoo! https://mail.haskell.org/pipermail/ghc-devs/2015-May/009032.html - Joachim Breitner asked: is there a way to programmatically 'Raise a Concern' on a Phabricator commit? With the new https://perf.haskell.org/ghc/ work, it'd be nice if regressions could be automatically flagged. The current problem is there is no API endpoint, but one can be built. https://mail.haskell.org/pipermail/ghc-devs/2015-June/009128.html - Adam Gundry asked ghc-devs about some input on changes to the new typechecker plugins API. After some discussion and elbow grease, the new changes have already landed in HEAD and will be in 7.12.1. https://mail.haskell.org/pipermail/ghc-devs/2015-May/009097.html == Noteworthy commits == - Commit 45d9a15c4b85a2ed89579106bdafd84accf2cb39 - Fix a huge space leak in the mighty simplifier - Commit c89bd681d34d3339771ebdde8aa468b1d9ab042b - Fix quadratic behavior in `tidyOccName` - Commit b03f074fd51adfb9bc4f5275294712ee62741aed - ghci: Allow `:back` and `:forward` to take counts - Commit 8e4dc8fb63b8d3bfee485c1c830776f3ed704f4d - Greatly speed up `nativeCodeGen/seqBlocks` - Commit c256357242ee2dd282fd0516260edccbb7617244 - Speed up `elimCommonBlocks` by grouping blocks also by outgoing labels - Commit f5188f3acd73a07b648924a58b9882c2d0a3dbcb - Fix weird behavior of `-ignore-dot-ghci` and `-ghci-script` - Commit 4fffbc34c024231c3c9fac7a2134896cc09c7fb7 - New handling of overlapping instances in Safe Haskell - Commit f16ddcee0c64a92ab911a7841a8cf64e3ac671fd - Support stage 1 Template Haskell (non-quasi) quotes, fixes #10382 - Commit cf7573b8207bbb17c58612f3345e0b17d74cfb58 - More accurate allocation stats for `:set -s` == Closed tickets == #10407, #10408, #10177, #10359, #10403, #10248, #9579, #10415, #10419, #10427, #10429, #10397, #10422, #10335, #10366, #10110, #10397, #10349, #10244, #8555, #8799, #9131, #10396, #10354, #10278, #9899, #3533, #9950, #10092, #9950, #10430, #9682, #9584, #10446, #10410, #10298, #10449, #10399, #7695, #10261, #8292, #10360, #10126, #10317, #10101, #10322, #10313, #10471, #10473, #7170, #10473, #10423, #10466, #8695, #10461, #10052, #10370, #10425, #10452, #10474, -- 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
Re: API to “raise concern” in Phabricator
Hi Joachim, (Sorry for the late reply). There may not be an API directly for this, but we can probably write one pretty easily - Phabricator's API endpoints can also be customized by library extensions, so we can extend libphutil-haskell (the repository with our extensions) to contain some outward facing Conduit API calls. I'll talk to upstream about this as well, in case they have any ideas or other approaches. On Wed, May 20, 2015 at 3:34 AM, Joachim Breitner m...@joachim-breitner.de wrote: Hi, with https://perf.haskell.org/ghc/ up and running I’m wondering about the best way to notify us about regressions. A mail to ghc-commits is one possibility, but maybe it’s neater to integrate that into Phabricator. How hard would it be comment and optionally “raise concern” with a commit automatically? Or, put differently, I want a script that takes a git commit, a comment, and a flag that indicated whether a concern should be raised, and then does that on Phabricator. It seems that https://phabricator.haskell.org/conduit/ is an entry point, but I only see methods for attaching comments to DRs. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org ___ 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
HEADS UP: Final call for 7.10.2 is soon
Hi *, I've just finished merging all the latest patches for GHC 7.10.2 into the STABLE branch. All in all, we've fixed a lot of bugs (over 80 tickets closed)! So, we'll probably be doing a 7.10.2 release here in a few weeks. The tentative plan was around the 14th, although it's not set in stone. (At worst, it would be pushed from the 14th to the 21st). With that in mind, if I could quickly direct your attention to the GHC bug tracker and the status page[1] - it would be really helpful if you check if the things you want are fixed! Specifically, if you want something fixed for the 7.10.2 release: - Make sure there is a ticket. It really needs to exist or we'll just forget! - If your bug is critical, please explain why! We really want to kill showstoppers ASAP, because bugs are much cheaper to fix early. If that's the case we can bump the priority if it's necessary to make things clear. - Set the milestone to 7.10.2. It'll automatically appear on the status page. That should be it - we'll be monitoring the status page regularly to keep track of new things. The current bug list is pretty small - we may move some of them out, or fix several more. So just try to let us know. As a sidenote, I'm quite happy with this release - it's fixed dozens of tricky bugs, improved some nasty corner cases in compiler performance, and overall seems like it will be high quality. Thanks to everyone who submitted patches! I'll send out another email next week as another reminder. [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2 -- 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
Re: Travis builds failing
Looks like: collect2: ld terminated with signal 9 [Killed] which I'd say with fair certainty means that the jobs failed because the linker ran out of memory on Travis, and the OOM killed it. So, that's a thing now. Perhaps for travis builds, we could disable SplitObjs by default to relieve the memory pressure? I'm not sure if it's on during Travis's builds, but it's a thought. On Mon, Jun 1, 2015 at 1:30 PM, Alan Kim Zimmerman alan.z...@gmail.com wrote: I suspect this is different, I am building a local master now, at current HEAD a27fb46ff1ea46a45e0084c3db92a24475e3bab5 to see what I find. Alan On Mon, Jun 1, 2015 at 8:22 PM, Joachim Breitner m...@joachim-breitner.de wrote: Hi, Am Montag, den 01.06.2015, 13:44 +0200 schrieb Alan Kim Zimmerman: On Mon, Jun 1, 2015 at 1:25 PM, Joachim Breitner m...@joachim-breitner.de wrote: yay, travis is green again. Thanks to Alan for fixing this. With a lot of help from @thomie .. hmm, looks like it is not fixed after all: Unexpected failures: ghc-api T6145 [bad exit code] (normal) ghc-api T8628 [bad exit code] (normal) ghc-api T8639_api [bad exit code] (normal) ghc-api/annotations T10278 [bad exit code] (normal) ghc-api/annotations T10313 [bad exit code] (normal) ghc-api/annotations T10354 [bad exit code] (normal) ghc-api/annotations T10396 [bad exit code] (normal) ghc-api/annotations T10399 [bad exit code] (normal) ghc-api/annotations boolFormula [bad exit code] (normal) ghc-api/annotations-literals parsed [bad exit code] (normal) https://s3.amazonaws.com/archive.travis-ci.org/jobs/64945879/log.txt Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ 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
Re: Travis builds failing
On Mon, Jun 1, 2015 at 2:34 PM, Joachim Breitner m...@joachim-breitner.de wrote: Hi, Am Montag, den 01.06.2015, 14:26 -0500 schrieb Austin Seipp: I don't think there's any built-in way to do that in the current testsuite infrastructure, other than setting THREADS=1, which, if it isn't set already, would probably push us back over the Travis build limit. we are running validate with CPU=2, which I believe translates to THREADS=1. It's actually the opposite - if you check ./validate, CPU=2 translates to THREAD=3! The reasoning is 'CPUS' is the number of physical cores you have, and it adds 1 to saturate all your cores, while the extra thread gets scheduled during I/O overlap on the underlying disk from the other threads, overall improving throughput. Normally it's a win on a completely un-contested machine, as some overlap exists. But we never had memory problems before, and 3GB is still quite a bit. Are we sure that there is no bug here? Or is our official requirement now above 3GB? Well, it's possible there's something else lurking here. Maybe the merge of D913 caused things to spike for some reason, during the cleanup? Possible there was an error in the refactoring. But given that the buildbot only has 3GB and executed (in essence) with THREADS=3, I'm almost certain that it's just because they all ran at once, and the OOM killed them. We may have just gotten lucky? Also, Thomas has alerted me that the testsuite actually has an option called `high_memory_usage` which will serialize the tests and run them one at a time. So actually, that can work as a solution too! Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org ___ 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
Re: Travis builds failing
I don't think there's any built-in way to do that in the current testsuite infrastructure, other than setting THREADS=1, which, if it isn't set already, would probably push us back over the Travis build limit. I wonder if we could just ask if they'd increase the limit for our project... On Mon, Jun 1, 2015 at 2:23 PM, Alan Kim Zimmerman alan.z...@gmail.com wrote: Is is possible to limit the number of concurrent tests? Instead of running on all available cores. On Mon, Jun 1, 2015 at 9:16 PM, Austin Seipp aus...@well-typed.com wrote: Looks like: collect2: ld terminated with signal 9 [Killed] which I'd say with fair certainty means that the jobs failed because the linker ran out of memory on Travis, and the OOM killed it. So, that's a thing now. Perhaps for travis builds, we could disable SplitObjs by default to relieve the memory pressure? I'm not sure if it's on during Travis's builds, but it's a thought. On Mon, Jun 1, 2015 at 1:30 PM, Alan Kim Zimmerman alan.z...@gmail.com wrote: I suspect this is different, I am building a local master now, at current HEAD a27fb46ff1ea46a45e0084c3db92a24475e3bab5 to see what I find. Alan On Mon, Jun 1, 2015 at 8:22 PM, Joachim Breitner m...@joachim-breitner.de wrote: Hi, Am Montag, den 01.06.2015, 13:44 +0200 schrieb Alan Kim Zimmerman: On Mon, Jun 1, 2015 at 1:25 PM, Joachim Breitner m...@joachim-breitner.de wrote: yay, travis is green again. Thanks to Alan for fixing this. With a lot of help from @thomie .. hmm, looks like it is not fixed after all: Unexpected failures: ghc-api T6145 [bad exit code] (normal) ghc-api T8628 [bad exit code] (normal) ghc-api T8639_api [bad exit code] (normal) ghc-api/annotations T10278 [bad exit code] (normal) ghc-api/annotations T10313 [bad exit code] (normal) ghc-api/annotations T10354 [bad exit code] (normal) ghc-api/annotations T10396 [bad exit code] (normal) ghc-api/annotations T10399 [bad exit code] (normal) ghc-api/annotations boolFormula [bad exit code] (normal) ghc-api/annotations-literals parsed [bad exit code] (normal) https://s3.amazonaws.com/archive.travis-ci.org/jobs/64945879/log.txt Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ 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/ -- 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
Re: [GHC] #10370: Compile time regression in OpenGLRaw
Will do. On Fri, May 22, 2015 at 9:23 AM, Simon Peyton Jones simo...@microsoft.com wrote: Austin: I have validated, but I am now going on holiday for a week. Can you monitor and revert if there's a major problem? Simon | -Original Message- | From: ghc-tickets [mailto:ghc-tickets-boun...@haskell.org] On Behalf | Of GHC | Sent: 22 May 2015 15:21 | Cc: ghc-tick...@haskell.org | Subject: Re: [GHC] #10370: Compile time regression in OpenGLRaw | | #10370: Compile time regression in OpenGLRaw | -+ | -- | -+--- | Reporter: michalt | Owner: | Type: bug | Status: new | Priority: normal| Milestone: | Component: Compiler | Version: | 7.10.1 |Resolution:|Keywords: | Operating System: Unknown/Multiple |Architecture: | Type of failure: Compile-time | Unknown/Multiple |performance bug| Test Case: |Blocked By:|Blocking: | Related Tickets:| Differential Revisions: | -+ | -- | -+--- | | Comment (by simonpj): | | The commit messages tell the story. Reid's example in comment:3 | showed up TWO separate, substantial non-linear performance holes in | GHC, both of which I have now fixed. Reid, your example was | amazingly helpful. | | '''Austin''' I have not added a `perf/compiler` test case. Could you | do so please? I wasn't sure that a 20-second compile time was | acceptable. | I'm leaving the ticket open for that reason. | | Simon | | -- | Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10370#comment:13 | GHC http://www.haskell.org/ghc/ | The Glasgow Haskell Compiler | ___ | ghc-tickets mailing list | ghc-tick...@haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets ___ 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
Re: [Diffusion] [Build Failed] rGHCfc8c5e7a5168: Test Trac #8799, #8555
I've reverted this change - it also passes perfectly fine on my machine, which is why I reverted so I could investigate further, so it wouldn't hold up any patches people submit (it's much more important to have HEAD always building because of that!) I can look into it on the buildbot soon. At the very least, this build machine seems to be very good at exposing weird edge cases... On Tue, May 19, 2015 at 6:31 AM, Simon Peyton Jones simo...@microsoft.com wrote: Devs, The failure seems to be for ghci.debugger/print007. I can't see the build log on Phabricator, so I can't see what went wrong. Works on my machine. I do see print007.stderr no location info: Warning: -O conflicts with --interactive; -O ignored. which seems odd. Why not fix the test? Simon | -Original Message- | From: nore...@phabricator.haskell.org | [mailto:nore...@phabricator.haskell.org] | Sent: 19 May 2015 12:20 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHCfc8c5e7a5168: Test Trac #8799, | #8555 | | Harbormaster failed to build B4076: rGHCfc8c5e7a5168: Test Trac #8799, | #8555! | | USERS |simonpj (Author) |GHC - Testsuite (Auditor) | | COMMIT |https://phabricator.haskell.org/rGHCfc8c5e7a5168 | | EMAIL PREFERENCES |https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Testsuite ___ 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
Re: Revert revert revert
Yep, I was going to recommend what Eric said, if you want to reapply
them all. `git cherry-pick`, if given multiple arguments, will pick
multiple commits in the same order you specify them. So you could say:
$ git cherry-pick 8da785d 130e93a 5910a1bc8 ...
... with all the commit hashes I previously reverted.
That said, the main drawback here is re-applying these commits as they
were will cause the build to break again, only to be fixed by a later
commit, which hurts bisect. If you want, you can 'amend' the commits
using rebase to make sure every individual commit builds. I'm not sure
if anyone else has a strong opinion here, though!
On Fri, May 15, 2015 at 12:16 PM, Eric Seidel e...@seidel.io wrote:
You could use `git cherry-pick`
(http://git-scm.com/docs/git-cherry-pick) to re-apply each commit
individually.
I think it would just be a simple
$ git cherry-pick commit
for each commit in the reverted list. cherry-pick accepts multiple
commits per invocation, but I'm not sure if it will squash them all
together into a single commit..
On Fri, May 15, 2015, at 09:51, Simon Peyton Jones wrote:
Devs, Austin
I've found out what the problem was, and fixed it.
What is the right way to re-do all this? My thought:
* git revert 3cf8ecd
I think this will re-apply all my patches, in one go.
(call this new path 'foogle')
* apply the fix as a new patch
* validate
The history will look odd. In particular, if someone does 'git blame'
then lots of unrelated changes will all map to 'foogle'. And 'foogle's
commit message will say revert a revert of 10 patches. Which is not
helpful.
Best would be to re-apply the patches one by one I suppose. How could I
do that?
Simon
| -Original Message-
| From: ghc-tickets [mailto:ghc-tickets-boun...@haskell.org] On Behalf
| Of GHC
| Sent: 14 May 2015 22:26
| Cc: ghc-tick...@haskell.org
| Subject: Re: [GHC] #10359: Tuple constraint synonym led to asymptotic
| performance lossage
|
| #10359: Tuple constraint synonym led to asymptotic performance lossage
| -+
| --
| -+---
| Reporter: axch | Owner:
| Type: bug | Status:
| closed
| Priority: normal| Milestone:
| Component: Compiler | Version: 7.6.3
|Resolution: fixed |Keywords:
| Operating System: Linux |Architecture:
| x86_64
| Type of failure: Runtime | (amd64)
|performance bug| Test Case:
|Blocked By:| perf/should_run/T10359
| Related Tickets:|Blocking:
| | Differential Revisions:
| -+
| --
| -+---
|
| Comment (by Austin Seipp austin@…):
|
| In [changeset:3cf8ecdc70cb295a2b9606080a1c7b5fa8eb16f4/ghc]:
| {{{
| #!CommitTicketReference repository=ghc
| revision=3cf8ecdc70cb295a2b9606080a1c7b5fa8eb16f4
| Revert multiple commits
|
| This reverts multiple commits from Simon:
|
| - 04a484eafc9eb9f8774b4bdd41a5dc6c9f640daf Test Trac #10359
| - a9ccd37add8315e061c02e5bf26c08f05fad9ac9 Test Trac #10403
| - c0aae6f699cbd222d826d0b8d78d6cb3f682079e Test Trac #10248
| - eb6ca851f553262efe0824b8dcbe64952de4963d Make the matchable-
| given
| check happen first
| - ca173aa30467a0b1023682d573fcd94244d85c50 Add a case to
| checkValidTyCon
| - 51cbad15f86fca1d1b0e777199eb1079a1b64d74 Update haddock submodule
| - 6e1174da5b8e0b296f5bfc8b39904300d04eb5b7 Separate transCloVarSet
| from fixVarSet
| - a8493e03b89f3b3bfcdb6005795de050501f5c29 Fix imports in HscMain
| (stage2)
| - a154944bf07b2e13175519bafebd5a03926bf105 Two wibbles to fix the
| build
| - 5910a1bc8142b4e56a19abea104263d7bb5c5d3f Change in capitalisation
| of error msg
| - 130e93aab220bdf14d08028771f83df210da340b Refactor tuple
| constraints
| - 8da785d59f5989b9a9df06386d5bd13f65435bc0 Delete commented-out
| line
|
| These break the build by causing Haddock to fail mysteriously when
| trying to examine GHC.Prim it seems.
| }}}
|
| --
| Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10359#comment:9
| GHC http://www.haskell.org/ghc/
| The Glasgow Haskell Compiler
| ___
| ghc-tickets mailing list
| ghc-tick...@haskell.org
| http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
NOTE: Phabricator is down for a moment
All, Phabricator is down for a few minutes - in my latest update it looks like we may have gotten hit by a bug. I'm working with upstream to fix it now. -- 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
Re: RFC: Native -XCPP Proposal
On Wed, May 6, 2015 at 6:08 AM, Herbert Valerio Riedel
hvrie...@gmail.com wrote:
Hello *,
As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension
currently relies on the system's C-compiler bundled `cpp` program to
provide a traditional mode c-preprocessor.
This has caused several problems in the past, since parsing Haskell code
with a preprocessor mode designed for use with C's tokenizer has caused
already quite some problems[1] in the past. I'd like to see GHC 7.12
adopt an implemntation of `-XCPP` that does not rely on the shaky
system-`cpp` foundation. To this end I've created a wiki page
https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp
to describe the actual problems in more detail, and a couple of possible
ways forward. Ideally, we'd simply integrate `cpphs` into GHC
(i.e. plan 2). However, due to `cpp`s non-BSD3 license this should be
discussed and debated since affects the overall-license of the GHC
code-base, which may or may not be a problem to GHC's user-base (and
that's what I hope this discussion will help to find out).
So please go ahead and read the Wiki page... and then speak your mind!
Thanks for writing this up, btw! It's nice to put the mumblings we've
had for a while down 'on paper'.
Thanks,
HVR
[1]: ...does anybody remember the issues Haskell packages ( GHC)
encountered when Apple switched to the Clang tool-chain, thereby
causing code using `-XCPP` to suddenly break due to subtly
different `cpp`-semantics?
There are two (major) differences I can list, although I can only
provide some specific examples OTTOMH:
1) Clang is more strict wrt language specifications. For example,
GCC is lenient and allows a space between a macro identifier and the
parenthesis denoting a parameter list; so saying 'FOO (x, y)' is valid
with GCC (where FOO is a macro), but not with Clang. Sometimes this
trips up existing code, but I've mostly seen it in GHC itself.
2) The lexing rules for C and Haskell simply are not the same in
general. For example, what should FOO(a' + b') parse to? Well, in
Haskell, 'prime' is a valid component from an identifier and in this
case the parse should be a prime + b prime, but in C the ' character
is identified as beginning the start of a single-character literal,
and a strict preprocessor like Clang's will reject that.
In practice, I think people have mostly just avoided arcane lexer
behaviors that don't work, and the only reason this was never a
problem was because GCC or some variant was always the 'standard' C
compiler GHC could rely on.
___
Glasgow-haskell-users mailing list
glasgow-haskell-us...@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
--
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
HCAR DUE SOON: Please help edit!
Hi *, (Apologies for the caps lock cruise-control in the title.) After sitting on it for a bit, it dawned on me today that the may HCAR report is due soon - in about two weeks! So, it's that time of the year again, and I'd like you all to take a quick glance at the page and edit some stuff in about what you're all working on, because I can't possibly keep up with it all. :) https://ghc.haskell.org/trac/ghc/wiki/Status/May15 Note that I've already put some boilerplate on the page, but some of it is old, from the last report - but some other things slipped, so maybe it's not old! The best case is you will read this page in 5 minutes and it will look OK. At worst, you may need to tweak a paragraph or write a new one - so please read and contribute! Note: I'll continue editing this page as time goes on, to prepare it for submission. -- 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
Re: DocBook to AsciiDoc
Hey Daniel, Thanks! Quick notes: 1) Yes, please file a ticket about this and refer to it in Phabricator when you make revisions. For this issue, I'd suggest just having one ticket, and every single commit references that one ticket. Adding a bunch of tickets just makes it all harder. 2) You can just add 'austin' and 'hvr' as reviewers. 3) You'll need to do some prodding with the build system: we need 'asciidoc' to be picked up by ./configure, etc. If you need help with this, just holler. I like the idea of one file at a time. If we can get by with that, I think we should. Thanks for helping! On Wed, Apr 15, 2015 at 2:50 PM, Daniel Bergey ber...@teallabs.org wrote: I just read that GHC wants to convert the manual to asciidoc. If no one else has yet volunteered to do this, I hearby volunteer myself. I haven't contributed to the GHC manual before, nor to GHC. I guess that I will need to learn my way around Phabricator? I expect to be proof-reading sections that I haven't read before, about GHC features I don't use. I don't expect this to be a problem, since the goal is just to match the current HTML output. I do have some experience with DocBook, Asciidoc, and Pandoc, which should be helpful. Is there anything I should convert that isn't in under the users_guide folder?[1] It looks as though the users guide gets frequent commits.[2] Does one `arc diff` per file, approximately, sound reasonable, to keep merge conflicts manageable? Anything else I should know before I begin? Who to list as reviewers? A Trac ticket to link all the asciidoc commits together? Thanks, Daniel Footnotes: [1] http://git.haskell.org/ghc.git/tree/HEAD:/docs/users_guide [2] http://git.haskell.org/ghc.git/history/HEAD:/docs/users_guide ___ 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
GHC Weekly News - 2015/04/14
(You can find a copy of this post online at https://ghc.haskell.org/trac/ghc/blog/weekly20150414) Hi *, It's been a few weeks since the last news bulletin - your editor apologizes about that. It's actually been a relatively slow few weeks here too, and busy-ness outside of GHC has attracted some of my attention. Despite that, GHC 7.10.1 was released, a new HP alpha is out, and things are moving along smoothly. Now that the release is done, things are quitely moving along in `HEAD` - with people committing code with reckless abandon, of course. This week, GHC HQ met up, but it's been very light since the 7.10.1 release. Currently there isn't anything pushing us to do a 7.10.2 release at least for a few more weeks it looks like - but see below. - We puzzled a bit about the release status of 7.10.2, and thought: it's only holding up people who are depending on it. So, who's depending on it, and what do they need fixed? See below for more. - We also talked a bit about performance - it seems the compiler has been getting much slower over time since the 7.8.x release series, and it's time to reign it in. Austin will be spending his week investigating a bit of this, and the causes. == 7.10.2 Status == So, you may be wondering when the 7.10.2 release is. The trick is it happens when you tell us it should happen! So far, taking a look at milestone:7.10.2, we've fixed about half the bugs we currently have marked down to fix. But we're probably going to punt some of those - and we're not sure all the ones that are there should be. So this is a call: **If you need something to be fixed during 7.10.2, please file a ticket, set the milestone, and alert us**. The sooner the better, because it'll inform us as to when we should release. Emailing `ghc-devs@haskell.org` is also a sure-fire way to get our attention. And remember: you can always find out the latest about the next release at the Status page (in this case, for 7.10.2) - https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2 == Call for help: DocBook to AsciiDoc == The GHC team needs some help. A few months ago, we put out a poll to convert our DocBook-based manual to AsciiDoc. The poll had a mostly lukewarm reception, with the idea that it will A) make life easier for people who frequently modify the users guide, and B) make life easier for people who add things irregularly, as a lower barrier to entry. It looks like we still **want** to do this - but alas, many of us don't have time! So, we're asking the public: Is anyone willing to step up and help here? For example, it may be possible to get a long ways with just `pandoc`, but we need someone to finish it - and in return, we'll help along the way! == List chatter == - Austin Seipp announced GHC 7.10.1. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008700.html - Mark Lentczner announced an alpha Haskell Platform release. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008724.html - David Macek announced MSYS2 packages for GHC on Windows, and also asked for some help with continuous windows building - Windows hackers should help out! https://mail.haskell.org/pipermail/ghc-devs/2015-March/008735.html - Jan Stolarek reports about increased memory usage with GHC 7.10.1. https://mail.haskell.org/pipermail/ghc-devs/2015-April/008751.html - Thomas Miedema chimed into a thread started by Karel Gardas about better parallelizing the GHC build - and hopefully we can get something good out of it. https://mail.haskell.org/pipermail/ghc-devs/2015-April/008749.html - Austin Seipp made a call for help on working on and improving the GHC homepage, and luckily Sergey Bushnyak answered the call and has helped out! https://mail.haskell.org/pipermail/ghc-devs/2015-April/008762.html - Ozgun Ataman kicked off a thread about slower compilation times, with some nasty numbers. It's becoming more clear compiler performance should be a priority for 7.12, and we've let some things slip away from us: https://mail.haskell.org/pipermail/ghc-devs/2015-April/008766.html - A GHC user, Dave, asked the list about some questions with Cross Compilation, as he's attempting to get GHC to work natively inside the Open Embedded build environment. Unfortunately, things haven't been going well so far, and any input from enterprising hackers is appreciated: https://mail.haskell.org/pipermail/ghc-devs/2015-April/008774.html - Dan Aloni has started a discussion about improving GHC's error messages, spurred by a popular blog post he wrote and posted on Reddit about some Happy/GHC improvements he's made. This is a difficult area (error messages in general are hard) to work on, so thanks to Dan for helping! https://mail.haskell.org/pipermail/ghc-devs/2015-April/008778.html - Simon Peyton Jones started a discussion about `GeneralizedNewtypeDeriving` and Safe Haskell, in particular
Help wanted: working on the GHC webpage
Hello *, For a while now, I've been wanting to do a facelift on the GHC homepage, but among many other things it's been a low priority. I'd like for people to help, so I've tried to get the ball rolling. The webpages existed in a Darcs repository previously (which wasn't available online), but earlier today I converted them to a git repository which you can find here: https://github.com/haskell-infra/ghc-homepage The site is currently composed of a set of server side include files that have a crude form of HTML templating. So it's mostly just pretty verbose to add or refactor anything, and the sites templating and styling is quite old (it dates back at least 10 years!) So, I'm making an official call for some help. At the very least, I'd like to at least end up converting the site to something like Hakyll which is doable without me causing a lot of damage to the stylesheets, but for the actual page itself I'd really appreciate it if anyone could help out! Please send pull requests or file issues, it's much appreciated. -- 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
Re: GHC 7.10.1 html docs all flat?
Hi Randy, This is due to an upstream Haddock bug I didn't manage to fix before the release; see https://ghc.haskell.org/trac/ghc/ticket/10206 - we really need to fix this for 7.10.2. I believe the problem we need to fix is in Haddock. The fact that the non-hierarchical version appears on the website is just so people can browse it (and FWIW, the 'correct links' are there, but obviously the hyperlinks *to* the proper places are broken...) On Tue, Mar 31, 2015 at 1:20 PM, Randy Polen randyhask...@outlook.com wrote: The HP build expects that the html docs for the ghc-bundled packages will be in heirarchical directories, based on the package name (e.g., GHC.Magic docs in libraries/ghc-prim-0.3.1.0/GHC-Magic.html) which is how it has been for many ghc releases. In 7.10.1, I thought it was an error but it seems the haskell.org docs reflect this new, flat way (e.g,. GHC.Magic docs in libraries/GHC-Magic.html). Just want to make sure this is what is expected, and then change the HP build code accordingly. Follow up question: should the HP-bundled docs do the same thing? Is the flat model the way to go for all the docs? Won't this cause collisions for updated packages? Randy ___ 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
ANNOUNCE: GHC version 7.10.1
== The (Interactive) Glasgow Haskell Compiler -- version 7.10.1 == The GHC Team is pleased to announce a new major release of GHC. There have been a number of significant changes since the last major release, including: * Several new language features and changes have been implemented: - Applicative is now a superclass of Monad and in the Prelude. - Many prelude combinators have been generalized - Static pointers * GHC now has preliminary and experimental support for DWARF based debugging. * `integer-gmp` has been completely rewritten. * Type-checking plugins can now extend the type checker. * Support for partial type signatures * Many bugfixes and other performance improvements. * Preliminary support for 'backpack' features like signatures. * Typeable is now generated by default for all data types automatically. We've also fixed a handful of issues reported since RC3: - A bug in the call arity analysis that would result in invalid core was fixed (#10176) - A bug in the Win32 package causing it to fail to load was fixed (#10165) - ghc-prim has (correctly) been bumped to version 0.4.0.0, to comply with the PVP. - Several libraries have been bumped to their latest available versions after coordination. The full release notes are here: https://downloads.haskell.org/~ghc/7.10.1/docs/html/users_guide/release-7-10-1.html How to get it ~ The easy way is to go to the web page, which should be self-explanatory: https://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://ghc.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: https://ghc.haskell.org/trac/ghc/wiki/Platforms https://ghc.haskell.org/trac/ghc/wiki/CodeOwners Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: https://ghc.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: https://ghc.haskell.org/trac/ghc/ Mailing lists ~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at https://www.haskell.org/mailman/listinfo/glasgow-haskell-users https://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 https://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: https://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: https://www.haskell.org/ghc/reportabug Hashes Signatures ~ On https://downloads.haskell.org/~ghc/7.10.1/ you will find a signed copy of the SHA256 hashes for the tarballs, using my GPG key (0F8F 3AA9 9235 C704 ADA0 B419 B942 AEE5 3B58 D86F). -- 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
Note: please write down your tentative plans for GHC 7.12
Hi *, I plan on shipping GHC 7.10.1 Real Soon Now (a bit later today). In light of this - we should think about what we want to get done for 7.12! I've set up a new status page about GHC 712. It's got a lot of tickets on it; I'll probably prune them later: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.12.1 At the top, you can see a list of tentative plans for what we want to implement. This list is short and I'm surely missing some things (for example - Edward, what might be on the Backpack roadmap? Worth mentioning?) Please feel free to add to this list liberally - I'll be reusing it for the 2015 HCAR, which will be due in a month or so. Thanks all, and happy hacking. -- 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
Re: Backporting srcLoc to the GHC 7.10 branch
Hi Michael, I actually tried to adopt this patch into 7.10, because I thought it was needed for another dependent patch we wanted. Unfortunately, the backtrace-via-implicit-params patch seems to depend on some prior work by Simon PJ in the typechecker (-fwarn-redundant-constraints, a rather large patch), which we *did not* want in 7.10 (the *textual* diff applied fine, but there were some API changes the backtrace patch needed, so it failed to build). So, in the end, it was easier to surgically remove this patch from the one that depended on it, and it had a much lower 'surface area' of changes, than adopting both. Hope that makes sense. Also, as Simon said, we don't normally do big changes like this in point releases, so I think this is unlikely to happen. So the short story is afraid not. But a backport should be possible, if you're willing to get your hands a bit dirty (any conflict will likely be fairly easy to fix, but it will involve some textual munging). On Mon, Mar 23, 2015 at 6:49 AM, Michael Snoyman mich...@snoyman.com wrote: It looks like the srcLoc change[1] is something that some of our (FP Complete's) customers would be quite interested in getting access to sooner rather than later. Would there be any possibility of getting that patch merged into the 7.10 branch of GHC? I'm not sure if I'd try my luck at actually including it in 7.10.1, but would it be on the table for 7.10.2? We do of course have the option of backporting it ourselves and including it in a custom GHC we provide customers, but we generally try to stay as close to upstream as possible. [1] https://ghc.haskell.org/trac/ghc/ticket/9049 ___ 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
Re: Shake fails test with GHC 7.10 RC3
Yes, this was what I was afraid of; an introduced regression in the RC 2-to-3 period, which IMO makes the bug a bit more serious. Also, this bug in particular looks like it manifests in a fairly nasty way, and having it catch people for the final release seems a bit worrisome. I also just remembered that the Haddock documentation for 7.10.1 is still broken; I've been tracking the bug today, but I need to sync up with the Haddock maintainers to discuss more. I really think this one needs to be fixed. So I also suggest we postpone for a few days to fix these two things, if possible. On Sat, Mar 21, 2015 at 6:55 AM, Neil Mitchell ndmitch...@gmail.com wrote: Interesting result. I've just attached a much smaller test case to the ticket - it would be good to see if that fails or passes with RC2, or breaks at the same point. The fact that there does seem to be a regression between RC2 and RC3 (either a regression itself, or making a previous bug easier to hit) makes me think that a release might not be such a great idea. Thanks, Neil On Sat, Mar 21, 2015 at 11:35 AM, Herbert Valerio Riedel hvrie...@gmail.com wrote: On 2015-03-21 at 08:21:20 +0100, Herbert Valerio Riedel wrote: On 2015-03-21 at 07:56:32 +0100, Neil Mitchell wrote: [...] 3) I tested with GHC RC1 and GHC RC2, both of which were fine. The fact no one else hit this with RC2 might just be because its a very recent regression. We -- and by that I don't mean myself... :) -- could git-bisect between RC2 and RC3 here (semi-)automatically (i.e. maybe unattended if it's scriptable) if your test-case (even if it's not minimal) reliably triggers the bug... I scripted up a test and git-bisected between RC2 and RC3, and the following commit is the one where `shake-test oracle test` starts failing http://git.haskell.org/ghc.git/commitdiff/6f46fe15af397d448438c6b93babcdd68dd78df8 ...which sadly is a rather large patch :-/ -- 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
Re: GHC Trac
Should be back online now. I think we're getting hit by bots, and we can't handle the load from some of them as they incur expensive CPU operations on Trac. We really need to fix this... On Fri, Mar 20, 2015 at 6:21 PM, Christopher Allen c...@bitemyapp.com wrote: Yes, has been for a good chunk of the day for myself and others. On Fri, Mar 20, 2015 at 6:20 PM, Simon Peyton Jones simo...@microsoft.com wrote: Is it just me, or is GHC’s Trac super-slow (again)? Actually it’s not just slow but offline from where I am. Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ 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
Re: Minor doc patch for ghc 7.10 + did I submit the patch correctly/follow the process?
Hi Doug, On Tue, Mar 17, 2015 at 2:54 PM, Doug Burke dburke...@gmail.com wrote: 1) I did not create a ticket; should I have done so? The existing documentation assumes that you are fixing a bug. It's not clearto me if RFE to the docs should be treated the same way We like to have tickets for every revision. This is mostly because a ticket has more metadata; for example, I very regularly find out what I need to merge into the stable branch using tickets, not Phabricator. This occurs when people submit patches there, and change the status of the related ticket on Trac. This ensures I don't forget them, and it leaves a nice history in Trac about what-was-fixed-when. For small documentation changes like this, not having a ticket is fine; for future patches, you can simply use your better judgement on whether you think a full ticket is necessary. I don't think it is here. 2) since the master branch doesn't contain the 7.10 doc file, and the newcomer guide assumes you are working from the master branch, I did # downloading the submodules seems excessive for a doc-only patch % git config --global url.git://github.com/ghc/packages-.insteadOf git://github.com/ghc/packages/ % git clone --recursive git://github.com/ghc/ghc % cd git % arc install-certificate ... enter in the token as requested % git checkout ghc-7.10 # as I'm on a very slow download link the repository needed to be updated, so % git fetch origin % git pull origin ghc-7.10 FWIW, all of these steps can really be condensed into one: $ git clone -b ghc-7.10 --recursive git://git.haskell.org/ghc.git ghc-7.10 $ cd ghc-7.10/ $ ... hack hack hack ... This clones the 7.10 branch and all subrepositories. A similar incantation without the '-b' works for HEAD. In general, it's a bit easier to manage the branches by just using separate directories. You can use one directory, which is totally fine but it's easy to forget things like 'git submodule update' when you 'git checkout', and that's a bit annoying unfortunately. We should definitely fix the docs up a bit here. # since some of these were in need of updating and 'arc diff' complained % git submodule update ... edit docs/users_guide/7.10.1-notes.xml # just to check I didn't make any obvious snafus % xmllint 7.10.1-notes.xml % git diff % git add 7.10.1-notes.xml % git commit -m '...' # finally get to arc; the first time I tried it complained about a missing branch # so I guessed it made sense to use the branch I had started with, rather than the # suggested one (which I think was master) % arc diff ghc-7.10 ... edit the file and guess at what to put in for reviewers (which I just left as blank and fortunately it looks like it defaults to something sensible). The easiest way to submit a review, although there are several workflows, is, IMO: $ git checkout -b my-new-branch $ ... hack hack hack ... $ git commit -sm new thing $ arc diff HEAD~ This basically says Send the latest patch against my current branch to Phabricator, which is normally what most people want, since they're just sending up a small diff. Then you can keep saying: $ ... hack hack hack ... $ git commit -am fix some things $ arc diff $ ... hack hack hack ... $ git commit -am fix some things $ arc diff which will keep updating that particular review. You can also always say: $ arc which which will tell you the logic Arcanist used to compute diffs and why it did something. I've been meaning to clean up the Phabricator documentation on the wiki for a while; there are a few particular things that can handle 99% of workflows, but right now the doc page is a bit crammed. Which is a rather heavy weight process when all I wanted to do was re-organize several paragraphs of a text file! Note that I was lazy and didn't try building ghc since it really is a simple doc change and I didn't want to go and spend even more time working out what I needed to build ghc documentation. FWIW, you should just need DocBook, dblatex, etc. There are docs here: https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation But also, we need to make it possible to build the documentation 'standalone', since right now it requires the build system (in some bizarre ways). Hopefully this will become easier when we move to AsciiDoc... In general our onboarding documentation could use a refactoring on this front. All suggestions appreciated! -- 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
Re: ANNOUNCE: GHC 7.10.1 Release Candidate 3
Neil, this has been fixed. On Tue, Mar 17, 2015 at 7:52 AM, Neil Mitchell ndmitch...@gmail.com wrote: All of the mingw links give me 403 forbidden errors. Do they have permission issues? Thanks, Neil On Mon, Mar 16, 2015 at 8:30 PM, Austin Seipp aus...@well-typed.com wrote: We are pleased to announce the third release candidate for GHC 7.10.1: https://downloads.haskell.org/~ghc/7.10.1-rc3 https://downloads.haskell.org/~ghc/7.10.1-rc3/docs/html/ This includes the source tarball and bindists for Windows and Debian Linux. FreeBSD, CentOS and Mac OS X binary distributions will follow soon. These binaries and tarballs have an accompanying SHA256SUMS file signed by my GPG key id (0x3B58D86F). We plan to make the 7.10.1 final release at the end of this week - so please test as much as possible; bugs are much cheaper if we find them before the release! The list of issues we plan on fixing can always be found in an up-to-date form here: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 -- 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 -- 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
Re: Spurious harbormaster failures
There was actually a misconfiguration of the disk storage that I fixed morning that caused this, I think; some other commits etc failed - I've since restarted the builds and they've worked. I've fixed this (hopefully for good this time), so we'll wait and see. On Sat, Mar 7, 2015 at 1:29 PM, Edward Z. Yang ezy...@mit.edu wrote: Here is a recent Harbormaster build, where the validate succeeded, but after the storage failed. https://phabricator.haskell.org/harbormaster/build/3329/ Edward ___ 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
Re: Windows build broken
This must be fallout from the VEH handler change I pushed earlier - 5200bdeb26c5ec98739b14b10fc8907296bceeb9. I'll try to fix/revert shortly. On Tue, Mar 3, 2015 at 4:30 PM, Simon Peyton Jones simo...@microsoft.com wrote: AAARGH! Windows build is broken again. Please can someone fix? In file included from rts\RtsMain.c:12:0: rts\PosixSource.h:31:0: error: __USE_MINGW_ANSI_STDIO redefined c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/_mingw.h:280:0: note: this is the location of the previous definition rts/ghc.mk:243: recipe for target 'rts/dist/build/RtsMain.o' failed make[1]: *** [rts/dist/build/RtsMain.o] Error 1 ___ 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
GHC Weekly News - 2015/03/03
(This post is available online at https://ghc.haskell.org/trac/ghc/blog/weekly20150303) Hi *, It's that time again! Today GHC HQ met on a Tuesday to avoid some scheduling conflicts, and that means it's time to send some news to people. Just a quick reminder from last week: we're hoping to make our third GHC 7.10.1 release candidate on '''Friday, March 13th''', with the final release on '''Friday, March 27th'''. Today, GHC HQ met up and mostly discussed the current status of GHC 7.10 and its bugs, which you can find on the Status page: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 But we've also had a little more list activity this week than we did before: - Simon PJ showed up to tell everyone he'd be a bit busy due to upcoming ICFP deadlines! However, since it's passed as of last Friday, it looks like the coming weeks will be more normal. https://mail.haskell.org/pipermail/ghc-devs/2015-February/008420.html - Michael Snoyman started a thread about a serious bug that has eluded attention during the 7.10 RC period: `cabal haddock --hoogle` does not work! https://mail.haskell.org/pipermail/ghc-devs/2015-February/008412.html - Jan Bracker is working on using the new type-checking plugins infrastructure, and had a question about the usage of what the typechecker calls `EvTerms`. Adam swooped in to respond. https://mail.haskell.org/pipermail/ghc-devs/2015-February/008414.html - Ben Gamari has been working on #9661, but while trying to do so hit a very painful set of conditions due to the import dependency graph of the compiler, making his fix much more difficult. Simon responds with his thoughts. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008432.html - After returning from an ICFP-writing-induced hiatus, Simon alerted us to a new paper of his describing his new, GADT-aware pattern matching checker. As usual, he'd love comments! The implementation will hopefully land in HEAD soon. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008437.html - Nikita Karetnikov was kind enough to alert the list that he's gotten a nice, Nix/NixOS based solution to building GHC, which he's documented on the wiki. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008445.html Some noteworthy commits that went into `ghc.git` in the past week include: - Commit aead01902e1c41e85b758dbafd15e60d08956374 - the `-fwarn-unused-binds` warning was split into 3 warnings, fixing #17 (one of our oldest open tickets). - Commit 5be8ed4da1963ed2d45a65fb61d761c977707cce - restores `integer-gmp` compatibility with GMP 4.x. This will be part of GHC 7.10. - Commit 31d4f2e9c89e22a91f98b4a4aa0f80af6b07b60f - `make test` in the top-level directory now works as expected. - Commit 5200bdeb26c5ec98739b14b10fc8907296bceeb9 - Replace Windows SEH handlers with VEH handlers, working uniformly across x86 and x86_64. Closed tickets the past week include: #9586, #10122, #10026, #8896, #10090, #10123, #10128, #10025, #10024, #10125, #9994, #9962, #10103, #10112, #10122, #9901, #10130, #10129, #9044, #8342, #8780, #10003, #17, #2530, #8274, and #10107. -- 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
Re: GHC 7.8.4 for Windows 32bit
Sorry about that; at the time I was having trouble with my build bots and I've continuously had trouble remoting into the Win32 machines I have... The 64bit build bots worked fine, but the 32 ones consistently had flaky internet connectivity, to the point I couldn't bootstrap GHC itself. I tried yesterday again, and seem to have fallen pray to something else (which makes it so I cannot RDP in at all right now, it seems). I've actually assembled a new PC here (that I have not yet installed Windows on) however, so hopefully I can shortly get binaries up. On Tue, Mar 3, 2015 at 7:51 AM, Neil Mitchell ndmitch...@gmail.com wrote: Hi, GHC 7.8.4 was released a little while ago, but there still isn't a Windows 32bit version available. With my MinGHC maintainer hat on we're getting quite a lot of requests for a 32bit 7.8.4 version. With my using Haskell commercially hat on the lack of a 32bit build is causing delays to infrastructure upgrades. Any timeline for a 32bit Windows build? Anything you're stuck on? Going forward, it seems the 32bit Windows version remains popular, so if all releases and release candidates came with such a version it would be great. I note there wasn't (and still might not be) a 7.10 RC, and as a result I've only tested my packages on Linux. Thanks, Neil -- 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
Re: MAC builds of 7.8.4 and 7.10.1 RC2
I'll get them online with signed hashes today. On Thu, Feb 12, 2015 at 8:20 AM, Ozgur Akgun ozgurak...@gmail.com wrote: This is great. What would one have to do to get this added to https://www.haskell.org/ghc/download_ghc_7_8_4 ? Ozgur On 11 February 2015 at 06:16, Mark Lentczner mark.lentcz...@gmail.com wrote: My build procedure is very minimal: export MACOSX_DEPLOYMENT_TARGET=10.6 ./configure 21 | tee ../conf.log cat mk/build.mk END V=1 SplitObjs=YES SupportsSplitObjs=YES HADDOCK_DOCS=YES LATEX_DOCS=NO HSCOLOUR_SRCS=YES BUILD_DOCBOOK_HTML=YES BUILD_DOCBOOK_PDF=NO BUILD_DOCBOOK_PS=NO BeConservative=YES END time make -j4 21 | tee ../make.log time make binary-dist 21 | tee ../bd.log That is all! ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/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://www.haskell.org/mailman/listinfo/ghc-devs
GHC Weekly News - 2015/02/10
, #10048, #10057, #10054, #10060, #10017, #10038, #9937, #8796, #10030, #9988, #10066, #7425, #7424, #7434, #10041, #2917, #4834, #10004, #10050, #10020, #10036, #9213, and #10047. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: stack traces when debugging GHC
Looks like you want https://ghc.haskell.org/trac/ghc/wiki/Debugging/Compiler - the first section mentions -DDEBUG, but not -fprof-auto. Probably worth adding a few sentences about what you've found to the top of the page. Thanks! On Sun, Feb 8, 2015 at 8:51 PM, Richard Eisenberg e...@cis.upenn.edu wrote: Hi devs, I've just made a miraculous discovery and I want to share! It has happened many times that I create some bizarre error in GHC and have no clue where it comes from. In the past, I've ended up using pprTrace to label all calls of the failing function, sometimes recursively, until I get an idea of what's going on. This is terribly painful. And then, I noticed that the function Debug.Trace.traceStack (just in the `base` package, not part of GHC) will print out a stack trace, when profiling is enabled. So, I tried building a profiled build of GHC, with -DDEBUG and -fprof-auto (just by editing the prof section of build.mk). And then, voila, ASSERTs now print stack traces! And, with a small change in Outputable, I can get pprTrace to print stack traces, too! Hooray! I'd love to put this on the wiki. Any clue where this might be found? Richard ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/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://www.haskell.org/mailman/listinfo/ghc-devs
Re: Delaying 7.10?
After thinking about it a little, I'm fine with pushing the release out to March. I think #9858 is the more serious of our concerns vs a raging debate, too. My only concern really is dealing with the merging of such a patch. For example, if the patch to fix this is actually as wide ranging as we believe to the type hacker, I can definitely foresee a merge conflict, with, say, the recent -fwarn-redundant-constraints, which I've managed to leave out of 7.10 so far. In any case, with some more time, we can work those details out. On Thursday, January 29, 2015, Simon Peyton Jones simo...@microsoft.com wrote: Friends In a call with a bunch of type hackers, we were discussing https://ghc.haskell.org/trac/ghc/ticket/9858 This is a pretty serious bug. It allows a malicious person to construct his own unsafeCoerce, and so completely subverts Safe Haskell. Actually there are two bugs (see comment:19). The first is easily fixed. But the second is not. We explored various quick fixes, but the real solution is not far out of reach. It amounts to this: ·Every data type is automatically in Typeable. No need to say “deriving(Typeable)” or “AutoDeriveTypeable” (which would become deprecated) ·In implementation terms, the constraint solver treats Typeable specially, much as it already treats Coercible specially. It’s not a huge job. It’d probably take a couple of days of implementation work, and some time for shaking out bugs and consequential changes. The biggest thing might be simply working out implementation design choices. (For example, there is a modest code-size cost to making everything Typeable, esp because that includes the data constructors of the type (which can be used in types, with DataKinds). Does that matter? Should we provide a way to suppress it? If so, we’d also need a way to express whether or not the Typable instance exists in the interface file.) But it is a substantial change that will touch a lot of lines of code. Moreover, someone has to do it, and Iavor (who heroically volunteered) happens to be travelling next week. So it’s really not the kind of thing we would usually do after RC2. But (a) it’s serious and, as it happens, (b) there is also the BBP Prelude debate going on. Hence the question: should we simply delay 7.10 by, say, a month? After all, the timetable is up to us. Doing so might give a bit more breathing space to the BBP debate, which might allow time for reflection and/or implementation of modest features to help the transition. (I know that several are under discussion.) Plus, anyone waiting for 7.10 can simply use RC2, which is pretty good. Would that be a relief to the BBP debate? Or any other opinions. Simon PS: I know, I know: there is endless pressure to delay releases to get stuff in. If we give in to that pressure, we never make a release. But we should know when to break our own rules. Perhaps this is such an occasion. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Make one-shot a per-registration property
You won't have permissions to push it to 7.10. I can try to get to it soon, but I make no guarantees until next week (out of town atm). CC Herbert, who can probably get to it more promptly than I can. On Thursday, January 29, 2015, Ben Gamari b...@smart-cactus.org wrote: Kazu Yamamoto k...@iij.ad.jp javascript:; writes: Hi, This is just confirmation. Ben's one-shot patch (*1) is included in master but not included in the ghc-7.10 branch. Is this intentional? Is it supposed to be merged in GHC 7.12? I merged it to master, asked thoughtpolice on #ghc how I should merge it to the 7.10 branch and promptly forgot about it, sadly. Thanks for mentioning this, Kazu. Austin, should I just cherry-pick it now? Cheers, - Ben -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
GHC Weekly News - 2015/01/27
Hi *, It's time for the weekly GHC news. Over at GHC HQ, we discussed some things this week including: - Austin took the time the past week to check `./validate --slow` failures, and is planning on filing bugs and fixes for the remaining failures soon. Afterwords, we'll immediately begin enabling `--slow` on Phabricator, so developers get their patches tested more thoroughly. - The 7.10 release looks like it will likely not have a 3rd Release Candidate, and will be released in late Feburary of 2015, as we originally expected. - The 7.10 branch currently has two showstopping bugs we plan on hitting before the final release. And we'd really like for users to test so we can catch more! - Austin Seipp will likely be gone for the coming week in a trip to New York City from the 28th to the 4th, meaning (much to the dismay of cheering crowds) you'd better catch him beforehand if you need him! (Alternatively Austin will be held back due to an intense snowstorm developing in NYC. So, we'll see!) - Austin is planning on helping the LLVM support in HEAD soon; after coordinating with Ben Gamari, we're hoping to ship GHC 7.12 with (at least) LLVM 3.6 as an officially supported backend, based on the documentation described in https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend - lots of thanks to Ben for working with upstream to file bugs and improve things! And in other news, through chatter on the mailing list and Phabricator, we have: - Austin Seipp announced GHC 7.10.1 RC2: https://www.haskell.org/pipermail/ghc-devs/2015-January/008140.html - Peter Trommler posted his first version of a native Linux/PowerPC 64bit code generator! There's still a lot more work to do, but this is a significantly improved situation over the unregisterised C backend. Curious developers can see the patch at Phab:D629. - A long, ongoing thread started by Richard Eisenberg about the long-term plans for the vectorisation code have been posted. The worry is that the vectoriser as well as DPH have stagnated in development, which costs other developers any time they need to build GHC, make larger changes, or keep code clean. There have been a lot of varied proposals in the thread from removing the code to commenting it out, to keeping it. It's unclear what the future holds, but the discussion still rages on. https://www.haskell.org/pipermail/ghc-devs/2015-January/007986.html - Karel Gardas is working on reviving the SPARC native code generator, but has hit a snag where double float load instructions were broken. https://www.haskell.org/pipermail/ghc-devs/2015-January/008123.html - Alexander Vershilov made a proposal to the GHC team: can we remove the `transformers` dependency? It turns out to be a rather painful dependency for users of the GHC API and of packages depending on `transformers`, as you cannot link against any version other than the one GHC ships, causing pain. The alternative proposal involves splitting off the `transformers` dependency into a package of Orphan instances. The final decision isn't yet clear, nor is a winner in clear sight yet! https://www.haskell.org/pipermail/ghc-devs/2015-January/008058.html - Konstantine Rybnikov has a simple question about GHC's error messages: can they say `Error:` before anything else, to be more consistent with warnings? It seems like a positive change - and it looks like Konstantine is on the job to fix it, too. https://www.haskell.org/pipermail/ghc-devs/2015-January/008105.html - Simon Marlow has started a long thread about the fate of records in future GHC versions. Previously, Adam Gundry had worked on `OverloadedRecordFields`. And now Nikita Volkov has introduced his `records` library which sits in a slightly different spot in the design space. But now the question is - how do we proceed? Despite all prior historical precedent, it looks like there's finally some convergence on a reasonable design that can hit GHC in the future. https://www.haskell.org/pipermail/ghc-devs/2015-January/008049.html Closed tickets the past two weeks include: #9889, #9384, #8624, #9922, #9878, #, #9957, #7298, #9836, #10008, #9856, #9975, #10013, #9949, #9953, #9856, #9955, #9867, #10015, #9961, #5364, #9928, and #10028. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Request for assistance from Haskell-oriented startup: GHCi performance
are executing the very same machine instructions! The overheads of the GHC API to compile and run the expression “main” are pretty small. I’m copying ghc-devs in case anyone else has any ideas. Simon From: Konrad Gądek [mailto:kga...@gmail.com] Sent: 14 January 2015 13:59 To: Simon Peyton Jones Cc: Piotr Młodawski; kga...@flowbox.io Subject: Request for assistance from Haskell-oriented startup: GHCi performance Dear Mr Jones, My name is Konrad Gądek and I'm one of the programmers at Flowbox ( http://flowbox.io ), a startup that is to bring a fresh view on image composition in movie industry. We proudly use Haskell in nearly all of our development. I believe you may remember our CEO, Wojciech Daniło, from discussions like in this thread: https://phabricator.haskell.org/D69 . What can be interesting for you is that to achieve our goals as a company, we started developing a new programming language - Luna. Long story short, we believe that Luna could be as beneficial for the Haskell community as Elixir is for Erlang. However, we found some major performance problems with the code that are as critical for us as they are cryptic. We have found difficulties in pinpointing the actual issue, not to mention solving it. We're getting a bit desperate about that, nobody so far has been able to help us, and so we would like to ask you for help. We would be really really grateful if you could take a look, maybe your fresh ideas could shed some light on the issue. Details are attached below. Is there any chance we could arrange eg. a Skype call so we could further discuss the matter? Thank you in advance! Background Currently Luna is trans-compiled to Haskell and then compiled to bytecode by GHC. Furthermore, we use ghci to evaluate expressions (the flow graph) interactively. We use accelerate library to perform high-performance computations with the help of graphic cards. The problem Executing some of the functions from libraries compiled with -O2 (especially from accelerate) is much slower than calling it from compiled executable (see http://stackoverflow.com/questions/27541609/difference-in-performance-of-compiled-accelerate-code-ran-from-ghci-and-shell and https://github.com/AccelerateHS/accelerate/issues/227). Maybe there is some other way to interactively evaluate Haskell code, which is more lightweight/more customizable ie. would not require all ghc-api features which are probably slowing down the whole process? Is it possible to just use ghc linker and make function calls simpler and more time efficient? Details We feed ghci with statements (using ghc-api) and declarations (using runStmt and runDecls). We can also change imports and language extensions before each call. The overall process is as follows: on init: · set ghcpath to one with our custom installation of ghc with preinstalled graphic libraries set imports to our libraries enable/disable appropriate language extensions for each run: · generate haskell code (including datatype declarations, using lenses and TemplateHaskell) and load it to ghci using runDecls for each expression: o run statements that use freshly generated code bind (lazy) results to variables evaluate values from bound variables, and get it from GhcMonad to runtime of our interpreter (see http://hackage.haskell.org/package/hint–0.4.2.1/docs/Language-Haskell-Interpreter.html#v:interpret) This behaviour was observed when using GHC 7.8.3 (with D69 patch) on Fedora 20 (x86-64), Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz Tried so far Specializing nearly everything in accelerate library, specializing calls to accelearate methods (no speedup). Load precompiled, optimised code to ghci (no speedup). Truth to be told, we have no idea what to try next. -- Konrad Gądek typechecker team-leader in Flowbox ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/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://www.haskell.org/mailman/listinfo/ghc-devs
RC2 Cutoff at the end of this week
Hi *, I just wanted to let everyone know we plan on releasing RC2 at the end of this week, on Friday. We're hoping this will be the final RC before we do the actual release, so if you want to get your fixes in for users to test - now is the time! Specifically, here are a few things: - Edward, can you please merge D614 and D603? I think we should pull these into the 7.10 branch. - Erik, can you follow up on D599? It would be nice to have this in early. - Alan, I'll get D538 D620 into 7.10 today, it just requires a more delicate merge I think (there are probably some parent commits to pick up). - Peter W, I'll get to #9961 later today, but if you don't mind, please post future things to Phabricator - it makes it much easier for a proper review (although your fix looks good still!) - Peter T, D622 looks OK to go into 7.10 and HEAD to me, so I can merge it. I'll follow up with a curated list of Trac tickets for the final release (in another email). Let me know if you have questions. Thanks. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
HEADS UP: Enabling --slow validate on Phabricator
Hi *, This is just a warning that soon, I'd like to enable --slow ./validate on Phabricator. What does this mean? It means that builds will take longer, but GHC will be tested much more thoroughly with each commit and with each patch that's submitted. Unfortunately, the bad news is that we've been pretty sloppy about making sure the --slow configuration always works... last I tried it (admittedly a little while ago) there were quite a few extra failures. However, this is just a pre-emptive warning that things may take longer, and a few things may break more soon. Particularly, there's now the chance Harbormaster will see failures that you did not see before! (for example, if you changed the code generator and broke the profiling build). But that's probably a good thing, since you can defer to checking slow tests afterwords. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
GHC Weekly News - 2015/01/19
Hi *, It's time for some more GHC news! The GHC 7.10 release is closing in, which has been the primary place we're focusing our attention. In particular, we're hoping RC2 will be Real Soon Now. Some notes from the past GHC HQ meetings this week: - GHC 7.10 is still rolling along smoothly, and it's expected that RC2 will be cut this Friday, January 23rd. Austin sent out an email about this to `ghc-devs`, so we can hopefully get all the necessary fixes in. - Our status page for GHC 7.10 lists all the current bullet points and tickets we hope to address: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 - Currently, GHC HQ isn't planning on focusing many cycles on any GHC 7.10 tickets that aren't '''highest priority'''. We're otherwise going to fix things as we see fit, at our leisure - but a highest priority bug is a showstopper for us. This means if you have something you consider a showstopper for the next release, you should bump the priority on the ticket and yell at us! - We otherwise think everything looks pretty smooth for 7.10.1 RC2 - our libraries are updated, and most of the currently queued patches (with a few minor exceptions) are done and merged. Some notes from the mailing list include: - Austin announced the GHC 7.10.1 RC2 cutoff, which will be on '''Friday the 23rd'''. https://www.haskell.org/pipermail/ghc-devs/2015-January/008026.html - Austin has alerted everyone that soon, Phabricator will run all builds with `./validate --slow`, which will increase the time taken for most builds, but will catch a wider array of bugs in commits and submitted patches - there are many cases the default `./validate` script still doesn't catch. https://www.haskell.org/pipermail/ghc-devs/2015-January/008030.html - Johan Tibell asked about some clarifications for the `HsBang` datatype inside GHC. In response, Simon came back with some clarifications, comments, and refactorings, which greatly helped Johan. ttps://www.haskell.org/pipermail/ghc-devs/2015-January/007905.html - Jens Petersen announced a Fedora Copr repo for GHC 7.8.4: https://www.haskell.org/pipermail/ghc-devs/2015-January/007978.html - Richard Eisenberg had a question about the vectoriser: can we disable it? DPH seems to have stagnated a bit recently, bringing into question the necessity of keeping it on. There hasn't been anything done yet, but it looks like the build will get lighter, with a few more modules soon: https://www.haskell.org/pipermail/ghc-devs/2015-January/007986.html - Ben Gamari has an interesting email about trying to optimize `bytestring`, but he hit a snag with small literals being floated out causing very poor assembly results. Hopefully Simon (or anyone!) can follow up soon with some help: https://www.haskell.org/pipermail/ghc-devs/2015-January/007997.html - Konrad Gądek asks: why does it seem the GHC API is slower at calling native code than a compiled executable is? Konrad asks as this issue of performance is particularly important for their work. https://www.haskell.org/pipermail/ghc-devs/2015-January/007990.html - Jan Stolarek has a simple question: what English spelling do we aim for in GHC? It seems that while GHC supports an assortment of British and American english syntactic literals (e.g. `SPECIALIZE` and `SPECIALISE`), the compiler sports an assortment of British/American identifiers on its own! https://www.haskell.org/pipermail/ghc-devs/2015-January/007999.html - Luis Gabriel has a question about modifying the compiler's profiling output, particularly adding a new CCS (Cost Centre Structure) field. He's hit a bug it seems, and is looking for help with his patch. https://www.haskell.org/pipermail/ghc-devs/2015-January/008015.html Closed tickets the past few weeks include: #9966, #9904, #9969, #9972, #9934, #9967, #9875, #9900, #9973, #9890, #5821, #9984, #9997, #9998, #9971, #1, #10002, #9243, #9889, #9384, #8624, #9922, #9878, #, #9957, #7298, and #9836. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1
Hi Jens, This was a result of https://ghc.haskell.org/trac/ghc/ticket/9652, which Edward fixed and I'll be merging into the 7.10 branch for RC2. On Fri, Jan 16, 2015 at 7:19 AM, Jens Petersen juhpeter...@gmail.com wrote: On 23 December 2014 at 23:36, Austin Seipp aus...@well-typed.com wrote: We are pleased to announce the first release candidate for GHC 7.10.1: Thanks! Maybe this is already fixed in git, but it seems to me that RC1 is not able to build itself? ghc-cabal: '/usr/bin/ghc-pkg' exited withghc-cabal: '/usr/bin/ghc-pkg' exited with an error: ghc-pkg: ghc no longer supports single-file style package databases (/builddir/build/BUILD/ghc-7.10.0.20141222/libraries/bootstrapping.conf) use 'ghc-pkg init' to create the database with the correct format. an error: ghc-pkg: ghc no longer supportutils/hsc2hs/ghc.mk:15: recipe for target 'utils/hsc2hs/dist/package-data.mk' failed make[1]: *** [utils/hsc2hs/dist/package-data.mk] Error 1 make[1]: *** Waiting for unfinished jobs s single-file style package databases (/builddir/build/BUILD/ghc-7.10.0.20141222/libraries/bootstrapping.conf) use 'ghc-pkg init' to create the database with the correct format. libraries/binary/ghc.mk:3: recipe for target 'libraries/binary/dist-boot/package-data.mk' failed make[1]: *** [libraries/binary/dist-boot/package-data.mk] Error 1 Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 (See current https://copr-be.cloud.fedoraproject.org/results/petersen/ghc-7.10/fedora-rawhide-x86_64/ghc-7.10.0.20141222-0.2.fc21/ for the full buildlog.) Is that a known issue? Jens -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
GHC Weekly News - 2015/01/07
Hi *, it's time for another GHC Weekly News! This week's edition will actually be covering the last two/three weeks; your editor has missed the past few editions due to Holiday madness (and also some relaxation, which is not madness). It's also our first news posting in 2015! So let's get going without any further delay! GHC HQ met this week after the Christmas break; some of our notes include: - Austin Seipp announced the GHC 7.8.4 release on behalf of the GHC development team. https://www.haskell.org/pipermail/haskell/2014-December/024395.html - Austin Seipp ''also'' announced the GHC 7.10.1 RC on behalf of the GHC team, as well. https://www.haskell.org/pipermail/ghc-devs/2014-December/007781.html - Since Austin is back, he'll be spending some time finishing up all the remaining binary distributions for GHC 7.8.4 and GHC 7.10.1 RC1 (mostly, FreeBSD and OS X builds). - We've found that 7.10.1 RC1 is working surprisingly well for users so far; to help users accomodate the changes, Herbert has conveniently written a migration guide for users for their most common problems when upgrading to 7.10.1: https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10 - We're aiming to release the 2nd Release Candidate for GHC 7.10.1 on January 19th. We're hoping this will be the last RC, with 7.10.1 final popping up in the middle of February. - GHC HQ may tentatively be working to release **another** GHC 7.8 release, but only for a specific purpose: to allow it to compile with 7.10.1. This will make it significantly easier for users to compile old GHCs (perhaps on newer platforms). However, we're not yet 100% decided on this, and we will likely only do a 'very minor release' of the source tarball, should this be the case. Thanks to Edward Yang for helping with this. - For future GHC releases on Windows, we're looking into adopting Neil Mitchell's new binary distribution of GHC, which is a nice installer that includes Cabal, MSYS and GHC. This should significantly lower the burden for Windows users to use GHC and update, ship or create packages. While we're not 100% sure we'll be able to have it ready for 7.10.1, it looks promising. Thanks Neil! (For more info, read Neil's blog post here: http://neilmitchell.blogspot.co.at/2014/12/beta-testing-windows-minimal-ghc.html ) There's also been some movement and chatter on the mailing lists, as usual. - GHC 7.10 is coming close to a final release, planned in February; to help keep track of everything, users and developers are suggested to look at the GHC 7.10.1 status page as a source of truth from GHC HQ: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 - Jan Stolark is currently working on injective type families for GHC, but ran into a snag with Template Haskell while trying to understand GHC's `DsMeta` module. Richard chimed in to help: https://www.haskell.org/pipermail/ghc-devs/2014-December/007719.html - Austin Seipp opened a fun vote: what naming convention should we use for GHC buildbots? After posting the vote before the holidays, the results are in: GHC's buildbots will take their names from famous logicians and computer scientists: https://www.haskell.org/pipermail/ghc-devs/2014-December/007723.html - Carter Schonwald asked a simple question: are pattern synonyms usable in GHCi? The answer is 'no', but it seems Gergo is on the case to remedy that soon enough: https://www.haskell.org/pipermail/ghc-devs/2014-December/007724.html - Anton Dessiatov has a question about GHC's heap profiler information, but unfortunately his question has lingered. Can any GHC/Haskell hackers out there help him out? https://www.haskell.org/pipermail/ghc-devs/2014-December/007748.html - Joachim Breitner made an exciting announcement: he's working on a new performance dashboard for GHC, so we can more easily track and look at performance results over time. The current prototype looks great, and Joachim and Austin are working together to make this an official piece of GHC's infrastructure: https://www.haskell.org/pipermail/ghc-devs/2015-January/007885.html - Over the holiday, Simon went and implemented a nice new feature for GHC: detection of redundant constraints. This means if you mention `Ord` in a type signature, but actually use nothing which requires that constraint, GHC can properly warn about it. This will be going into 7.12: https://www.haskell.org/pipermail/ghc-devs/2015-January/007892.html - Now that GHC 7.10 will feature support for DWARF based debugging information, Johan Tibell opened a very obvious discussion thread: what should we do about shipping GHC and its libraries with debug support? Peter chimed in with some notes - hopefully this will all be sorted out in time for 7.10.1 proper: https
Re: Random holiday fun: Vote for buildbot naming conventions!
Hi all, I closed the polls on this a few days ago, and the results are in. By popular vote, the candidates from first to third place are: 1) Famous logicians and Computer Scientists - 21 out of 40 votes. 2) Boring and descriptive names - 19 out of 40 votes. 3) NSA Surveillance Tools - 15 out of 40 votes. So it looks like our bots will be paying homage to our predecessors and will be named after them. :) Thanks to the 40 people who voted! On Thu, Dec 18, 2014 at 11:47 AM, Carter Schonwald carter.schonw...@gmail.com wrote: dont forget you can vote for more than one! On Thu, Dec 18, 2014 at 12:08 AM, Austin Seipp aus...@well-typed.com wrote: Hi *, Everyone has been working hard getting things ready for the branch/RC later this week - and that's really appreciated! As always, GHC wouldn't be what it is without you. But it's the holidays - that's stressful for some, and real time consuming for others. So to keep things light and a little interesting, and if you have a minute as an experiment, I'd like to ask you all something: What naming conventions should we use for GHC buildbots? We've been adding more bots recently, and we've just gotten hold of some new hardware this week. Currently, GHC buildbots don't have any reserved name or identifier, or DNS entries. I'd like to change that - we mostly refer to them by IP, but this is annoying A) to remember and B) to tell other people. We'll likely begin to lease out these machines to developers so they can test and debug - meaning they'll be mentioned more. I'd like to propose a theme for naming buildbots - this theme would be used to populate DNS entries under the *.ghc.haskell.org domain. The question is: what naming convention do we use? So I created a poll for this. You can see that poll and vote for your favorite options on Phabricator: - https://phabricator.haskell.org/V3 It's an approval vote rather than a plurality; so feel free to select multiple choices. The winner with the most votes will get selected. Note: the selection of options is relatively random and pre-selected; there is an upper limit on the number of choices - 10 max - so I merely picked some categories I thought would work and be generic enough. I imagine this vote will be open for about a week or so. I'd like it if developers could vote on their favorites, or simply leave comments on the vote for further suggestion - we could institute a vote with better names. Thanks all - and be sure to have happy holidays. P.S I did not know RFC 1178 existed before today. Seems like there's one for everything... -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/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://www.haskell.org/mailman/listinfo/ghc-devs
Re: New performance dashboard front-end
Joachim, This looks awesome! Yes, we can set up you up with a small server soon to do all this and keep it running in public. FWIW, I'd rather not make a virtual proxy at ghc.haskell.org point to your backend server, by routing '/speed' out to another server. What about a new domain - https://speed.ghc.haskell.org ? This falls in line with the new buildbot naming conventions we voted on a few weeks ago, it's trivial to add (only a DNS entry), and is nicer IMO. On Wed, Jan 7, 2015 at 3:54 AM, Simon Peyton Jones simo...@microsoft.com wrote: Sounds amazing, thank you! Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Joachim | Breitner | Sent: 06 January 2015 23:21 | To: ghc-devs@haskell.org | Subject: New performance dashboard front-end | | Hi, | | over the holidays I’ve been working on a new and custom-made¹ front-end | for our performance data, mainly to work around limitations of codespeed | when it comes to understanding git, but also to add other features that | I happen to want. | | I put a (not automatically updated) preview on | http://deb.haskell.org/speed/ | The code is not yet online, and there are some features missing (most | notably: Working with multiple builders, the per-benchmark-graphs.) | | I’d like to have this hosted somewhere properly, so this is a request | for the infrastructure team. | | I am a big fan of static content, so the system is a (shake-driven) | batch process that generates a bunch of .json file. These can be served | statically, together with the completely static index.html and a few | javascript libraries. So it’s all very CDN-friendly. | | So all I need is | * shell access to some machine, preferably with ghc installed | * some disk space (actually quite a bit due to all the build logs, |although that could be reduced by gzipping or reading them directly |from the git repo²) | * a new virtual host or a subdirectory of http://ghc.haskell.org/ |where I can deploy my files to. | * the possibility to either run a cronjob to poll for new logs, or |maybe (later) some more sophisticated trigger. | | Would that be possible? | | Greetings, | Joachim | | ¹ It is still a generic display of values per git commit, and I hope | I can keep it that way – maybe other projects can use it as well. | | ² currently at https://github.com/nomeata/ghc-speed-logs | If the above becomes official, this probably also should move to | git.haskell.org. The repo is 250M, but 7,2G checked out. I plan to | make my code read the logs directly from the repo, and link to the | cgit web interface to show the logs, so that it never has to be | checked out. | | -- | Joachim “nomeata” Breitner | m...@joachim-breitner.de • http://www.joachim-breitner.de/ | Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F | Debian Developer: nome...@debian.org ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/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://www.haskell.org/mailman/listinfo/ghc-devs
ANNOUNCE: GHC version 7.8.4
== The (Interactive) Glasgow Haskell Compiler -- version 7.8.4 == The GHC Team is pleased to announce a new patchlevel release of GHC, 7.8.4. This is an important bugfix release relative to 7.8.3 (with over 30 defects fixed), so we highly recommend upgrading from the previous 7.8 releases. The full release notes are here: https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_guide/release-7-8-4.html How to get it ~ The easy way is to go to the web page, which should be self-explanatory: https://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://ghc.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://ghc.haskell.org/trac/ghc/wiki/Platforms http://ghc.haskell.org/trac/ghc/wiki/CodeOwners 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://ghc.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://ghc.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 Hashes Signatures ~ On https://downloads.haskell.org/~ghc/7.8.4/ you will find a signed copy of the SHA256 hashes for the tarballs, using my GPG key (keyid 0x3B58D86F). -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
ANNOUNCE: GHC 7.10.1 Release Candidate 1
We are pleased to announce the first release candidate for GHC 7.10.1: https://downloads.haskell.org/~ghc/7.10.1-rc1/ This includes the source tarball and bindists for 64bit/32bit Linux and Windows. Binary builds for other platforms will be available shortly. (CentOS 6.5 binaries are not available at this time like they were for 7.8.x). These binaries and tarballs have an accompanying SHA256SUMS file signed by my GPG key id (0x3B58D86F). We plan to make the 7.10.1 release sometime in February of 2015. We expect another RC to occur during January of 2015. Please test as much as possible; bugs are much cheaper if we find them before the release! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
HEADS UP: Tickets have been triaged a bit
Hi *, As many of you will probably notice, I have bulk modified a lot of Trac tickets and moved their milestone out. You might be wondering why; the reasoning is that since 7.10.1 RC1 is out (see other email), we need to start prioritizing what gets done. So, I moved all tickets that were a) set to 7.10.1 milestone, b) not closed, and c) had below 'high priority', to the 7.12.1 milestone. There are some tickets in 'normal' that probably should be moved back. If you're CC'd on a ticket and think it should be fixed for 7.10.1, please: - Set the milestone back to 7.10.1 - And if you can, take ownership! GHC HQ will probably only have time to organize efforts to take on the most high priority tickets - so any help you can offer is always appreciated. You can see the current list of tickets here. We'll put notes on the page at the top as time goes on to keep people up to date. https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Fatal: Reference is not a tree
| cleanly. | Applied patch utils/haddock cleanly. | warning: 2 lines add whitespace errors. | Submodule 'libffi-tarballs' () registered for path 'libffi-tarballs' | Submodule 'libraries/Cabal' () registered for path 'libraries/Cabal' | Submodule 'libraries/Win32' () registered for path 'libraries/Win32' | Submodule 'libraries/array' () registered for path 'libraries/array' | Submodule 'libraries/binary' () registered for path | 'libraries/binary' | Submodule 'libraries/bytestring' () registered for path | 'libraries/bytestring' Submodule 'libraries/containers' () | registered | for path 'libraries/containers' Submodule 'libraries/deepseq' () | registered for path 'libraries/deepseq' Submodule | 'libraries/directory' () registered for path 'libraries/directory' | Submodule 'libraries/dph' () registered for path 'libraries/dph' | Submodule 'libraries/filepath' () registered for path | 'libraries/filepath' | Submodule 'libraries/haskeline' () registered for path | 'libraries/haskeline' Submodule 'libraries/hoopl' () registered for | path 'libraries/hoopl' Submodule 'libraries/hpc' () registered for | path 'libraries/hpc' | Submodule 'libraries/parallel' () registered for path | 'libraries/parallel' | Submodule 'libraries/pretty' () registered for path | 'libraries/pretty' | Submodule 'libraries/primitive' () registered for path | 'libraries/primitive' Submodule 'libraries/process' () registered | for | path 'libraries/process' Submodule 'libraries/random' () registered | for path 'libraries/random' Submodule 'libraries/stm' () registered | for path 'libraries/stm' | Submodule 'libraries/terminfo' () registered for path | 'libraries/terminfo' | Submodule 'libraries/time' () registered for path 'libraries/time' | Submodule 'libraries/transformers' () registered for path | 'libraries/transformers' Submodule 'libraries/unix' () registered | for | path 'libraries/unix' Submodule 'libraries/vector' () registered for | path 'libraries/vector' Submodule 'libraries/xhtml' () registered | for | path 'libraries/xhtml' Submodule 'nofib' () registered for path | 'nofib' | Submodule 'utils/haddock' () registered for path 'utils/haddock' | Submodule 'utils/hsc2hs' () registered for path 'utils/hsc2hs' | Submodule path 'libraries/Cabal': checked out | '82d2fe1f5083e56f0b2d2c2409a3f673a56a5fe4' Submodule path | 'libraries/containers': checked out | 'ddf4e4a7abbfb81161251437a6a5bbe8167a7cde' Submodule path | 'libraries/directory': checked out | 'bcb8c40b5e0a17030bcc085b46bf8718ea713107' Submodule path | 'libraries/hoopl': checked out | 'a90a3af92be400af8912555bce21b041a1c48ad4' | Submodule path 'libraries/pretty': checked out | '110b105c491387a73dd37b4f86a686ed131767b2' Submodule path | 'libraries/random': checked out | '180aa65507d5b7c63d9f438ff908774bafc88d0d' | fatal: reference is not a tree: | d809f9d656780273f4f79e7a9fb934f783f79702 | Unable to checkout 'd809f9d656780273f4f79e7a9fb934f783f79702' in | submodule path 'utils/haddock' OKAY Successfully committed patch. | simonpj@cam-05-unx:~/code/HEAD-2$ git fetch git fetch | simonpj@cam-05-unx:~/code/HEAD-2$ git submodule update git submodule | update simonpj@cam-05-unx:~/code/HEAD-2$ git status git status # On | branch arcpatch-D202 # Untracked files: | # (use git add file... to include in what will be committed) | # | # flat-skol-diff | # foo | # foo2 | # index.html.1 | # index.html.2 | # index.html.3 | # resume | # spj-patch | # spj-patch-save | # | testsuite/mk/ghcconfig_home_simonmar_fp_bin_x86_64-unknown- | linux_ghc.mk # | testsuite/tests/simplCore/should_compile/T8538.hs | # testsuite/tests/simplCore/should_compile/T9073.hs | # tmp-patch | # untch-patch | nothing added to commit but untracked files present (use git add | to | track) simonpj@cam-05-unx:~/code/HEAD-2$ | ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/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://www.haskell.org/mailman/listinfo/ghc-devs
Re: Triggering a Harbourmaster build on a given commit
Bah, this is some bunk permission error. I'll try to fix it shortly. In the mean time, I ran it for you: https://phabricator.haskell.org/B2742 On Mon, Dec 22, 2014 at 9:44 AM, Dr. ERDI Gergo ge...@erdi.hu wrote: Hi, Thanks for the detailed instructions -- it looks like something that should be on some wiki somewhere! However, I got stuck on step 4: it says I do not have permission to manage Harbormaster build plans and I need an adult^Wadministrator. How do I proceed? Thanks, Gergo On Mon, 22 Dec 2014, Austin Seipp wrote: Unfortunately it's a bit hidden in the UI. I'll try to explain: 1) Go to https://phabricator.haskell.org/harbormaster 2) On the left side, click on 'Manage Build Plans' 3) Click on 'Plan 2 - GHC Continuous Integration', which builds commits 4) On the right-hand side, click 'Run Plan Manually' 5) In the box, enter the 'object name'. NOTE: the object name is DIFFERENT than the raw commit SHA1. In Phabricator, a 'commit object' is identified fully by the repository callsign plus the SHA1. In your case, you want to test commit 20acaa7785. Therefore, the full object name would be 'rGHC20acaa785', just like it appears in the URL you posted. This should do the job. Hope that helps! On Sun, Dec 21, 2014 at 6:47 AM, Dr. ERDI Gergo ge...@erdi.hu wrote: Hi, Given a concrete commit on a non-master branch (e.g. https://phabricator.haskell.org/rGHC20acaa7785d910d36d46c4eae9e9cce4000635d1), how do I manually trigger a Harbourmaster build + validation? Thanks, Gergo -- .--= ULLA! =-. \ http://gergo.erdi.hu \ `---= ge...@erdi.hu =---' A man's best friend is his dogma. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- .--= ULLA! =-. \ http://gergo.erdi.hu \ `---= ge...@erdi.hu =---' Óvakodj a kliséktől: tizenkettő belőlük egy tucat! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Fatal: Reference is not a tree
On Mon, Dec 22, 2014 at 11:22 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote: Haddock is on Phabricator and has an .arcconfig file. All you need to do is submit a revision like normally, just run 'arc diff' in the Haddock directory. But this will create a separate revision for haddock, right? My changes in haddock are related to revision I am working on. What I would want to do is somehow have my haddock changes uploaded as part of the diff. This simply isn't possible when using submodules with any code review tool I know of, because submodules do not contain content, only *pointers* to content elsewhere in another repository. To accomplish what you want you we would instead need to use 'git subtree' instead of submodules, which essentially allows multiple git repositories to live under a unified umbrella. But that comes with some other problems (the least of which is that 'git subtree' is not an official Git tool; it is a 'contrib' tool). -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Can we rename completion to autocomplete
I'd say just move it under utils/. We really need to organize the top-folder more, but that's for another day. On Thu, Dec 18, 2014 at 11:18 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote: Bump. Any decisions on this one? If not then I'll move that folder somewhere else because it's getting in the way. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/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://www.haskell.org/mailman/listinfo/ghc-devs
Random holiday fun: Vote for buildbot naming conventions!
Hi *, Everyone has been working hard getting things ready for the branch/RC later this week - and that's really appreciated! As always, GHC wouldn't be what it is without you. But it's the holidays - that's stressful for some, and real time consuming for others. So to keep things light and a little interesting, and if you have a minute as an experiment, I'd like to ask you all something: What naming conventions should we use for GHC buildbots? We've been adding more bots recently, and we've just gotten hold of some new hardware this week. Currently, GHC buildbots don't have any reserved name or identifier, or DNS entries. I'd like to change that - we mostly refer to them by IP, but this is annoying A) to remember and B) to tell other people. We'll likely begin to lease out these machines to developers so they can test and debug - meaning they'll be mentioned more. I'd like to propose a theme for naming buildbots - this theme would be used to populate DNS entries under the *.ghc.haskell.org domain. The question is: what naming convention do we use? So I created a poll for this. You can see that poll and vote for your favorite options on Phabricator: - https://phabricator.haskell.org/V3 It's an approval vote rather than a plurality; so feel free to select multiple choices. The winner with the most votes will get selected. Note: the selection of options is relatively random and pre-selected; there is an upper limit on the number of choices - 10 max - so I merely picked some categories I thought would work and be generic enough. I imagine this vote will be open for about a week or so. I'd like it if developers could vote on their favorites, or simply leave comments on the vote for further suggestion - we could institute a vote with better names. Thanks all - and be sure to have happy holidays. P.S I did not know RFC 1178 existed before today. Seems like there's one for everything... -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
GHC Weekly News - 2014/12/16
Hi *, time for another piece of the GHC weekly news! - Joachim Breitner has gotten the new GHC 7.8.4 package to tentatively build on ARM quite easily for Debian. Austin also took the liberty of merging all the needed patches; they'll be part of the 7.8.4 release https://www.haskell.org/pipermail/ghc-devs/2014-December/007608.html - Greg Weber announced he's taken the time to set up a Docker image for GHC development - if you're on Linux, Greg's image should help you get up to speed with a GHC development environment in minutes! https://www.haskell.org/pipermail/ghc-devs/2014-December/007606.html - Lennart Kolmodin has spent time working on autocompletion for GHC, and 7.10 will ship with bash completion scripts - which package maintainers and distributions can now ship for their users. Thank you Lennart! https://www.haskell.org/pipermail/ghc-devs/2014-December/007614.html - Adam Gundry has a question about the new type checker plugin infrastructure; in particular - how do we deal with the serialization of type checker evidence that plugins may want to create or pass around on their own? Richard, Simon and Iavor weigh in. https://www.haskell.org/pipermail/ghc-devs/2014-December/007626.html - For the past few days, Richard Eisenberg has been hunting a performance regression in the compiler. After profiling, discussion on IRC and elsewhere, Richard has finally made some headway, and discovered one of the 'hot spots' in his patch. Unfortunately the battle isn't quite over just yet, and the hunt for a few more % increase remains. https://www.haskell.org/pipermail/ghc-devs/2014-December/007645.html - David Spies has hit a very strange situation with GHC 7.8.3 running out of memory. But it turned out this was a change in 7.8, in relation to how stacks were managed. Phew! https://www.haskell.org/pipermail/ghc-devs/2014-December/007646.html - Austin made a final call for 7.8.4 bugfixes. He plans on making the final release this week, if nobody has any other major complaints. https://www.haskell.org/pipermail/ghc-devs/2014-December/007684.html Finally, in a slight change, we'll also be covering some notes from this week's meeting between GHC HQ (Austin, Simon PJ, SimonM, Herbert and Mikolaj), including... - The 7.10 RC1 looks like it's scheduled to occur this week still; all of our libraries and submodules are up-to-date, and we've taken the time to alert all of our maintainers about this. Thanks to Herbert for taking control of this! - We'll soon be implementing a new 'push hook' for the `ghc.git` repository: no more trailing whitespace. Since we've recently detabbed, and de-lhs-ified the tree, a knock-on effect was deleting trailing whitespace. Now that we've done a lot of this, we should take the time to enforce it - so they can't slip back in. - Austin will be landing Phab:D169 and Phab:D396 soon to get it into 7.10.1 RC1. - This week, Austin managed to secure two sponsors for GHC/Haskell.org. We've been given a wonderful set of ARM buildbots (running in the cloud!) and a new, incredibly powerful POWER8 machine to use (with over 170 hardware threads available, for scalability testing). Hooray for our friends at Online.net and RunAbove.com for helping us out! Closed tickets this week include: #9871, #9808, #9870, #9605, #9874, #9872, #9090, #9404, #8240, #9567, #9566, #9583, #9117, #9882, #9884, #9372, #7942, #8951, #9817, #9620, #9336, #9523, #9552, #8988, #9390, #9415, #9371, #7143, #9563, #8778, #4428, #4896, #9393, #9169, #7015, #8943, #8621, #9132, #9857, #8024, #9831, and #9888. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Last call for 7.8.4
Hello *, I've just pushed a final round of patches to the 7.8 branch, including the notorious Cabal fix for the -fPIC bug that was discussed earlier in the week, and a handful of other bugfixes for ARM among other things (/cc Joachim :) I am planning on making the final 7.8.4 release this week; barring any pending minor issues (e.g. build wibbles) in the tree (which I do not think should be needed), the only thing I will commit is A) release notes and B) the version number changes. There will not likely be a 7.8.4-rc2, so this is a last call for any bugs you'd like to see fixed. I may have missed something -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Diffusion] [Build Failed] rGHC3f87866ad536: Fix dll-split problem with patch 'Make Core Lint check for locally-bound…
Yeah, this was what I was referring to when we were talking when I said I'm going to kick myself if I broke the build this morning :) I broke the build. Therefore, I will fix it and then kick myself. Fix incoming. On Mon, Dec 15, 2014 at 11:42 AM, Simon Peyton Jones simo...@microsoft.com wrote: This failure is in STM!! I don't think that can be my fault :-( | -Original Message- | From: nore...@phabricator.haskell.org | [mailto:nore...@phabricator.haskell.org] | Sent: 15 December 2014 17:28 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHC3f87866ad536: Fix dll-split | problem with patch 'Make Core Lint check for locally-bound… | | Harbormaster failed to build B2627: rGHC3f87866ad536: Fix dll-split | problem with patch 'Make Core Lint check for locally-bound…! | | USERS |simonpj (Author) |GHC - Core/System FC (Auditor) |GHC - Driver (Auditor) |GHC - Type checker/inferencer (Auditor) | | COMMIT |https://phabricator.haskell.org/rGHC3f87866ad536 | | EMAIL PREFERENCES |https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Core/System FC, GHC - Driver, GHC - Type | checker/inferencer ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/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://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Diffusion] [Build Failed] rGHC3f87866ad536: Fix dll-split problem with patch 'Make Core Lint check for locally-bound…
Should be fixed, sorry for the annoyance! On Mon, Dec 15, 2014 at 11:43 AM, Austin Seipp aus...@well-typed.com wrote: Yeah, this was what I was referring to when we were talking when I said I'm going to kick myself if I broke the build this morning :) I broke the build. Therefore, I will fix it and then kick myself. Fix incoming. On Mon, Dec 15, 2014 at 11:42 AM, Simon Peyton Jones simo...@microsoft.com wrote: This failure is in STM!! I don't think that can be my fault :-( | -Original Message- | From: nore...@phabricator.haskell.org | [mailto:nore...@phabricator.haskell.org] | Sent: 15 December 2014 17:28 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHC3f87866ad536: Fix dll-split | problem with patch 'Make Core Lint check for locally-bound… | | Harbormaster failed to build B2627: rGHC3f87866ad536: Fix dll-split | problem with patch 'Make Core Lint check for locally-bound…! | | USERS |simonpj (Author) |GHC - Core/System FC (Auditor) |GHC - Driver (Auditor) |GHC - Type checker/inferencer (Auditor) | | COMMIT |https://phabricator.haskell.org/rGHC3f87866ad536 | | EMAIL PREFERENCES |https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Core/System FC, GHC - Driver, GHC - Type | checker/inferencer ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
GHC Weekly News - 2014/12/08
Hi *, Once more, it's time for some news about GHC! This week's regularly scheduled programming (get it?) has brought you... - As of last week, GHC officially has no more `.lhs` files in its source repository; instead, they've all been converted to `.hs` and are now much more consistent with each other: https://www.haskell.org/pipermail/ghc-devs/2014-December/007552.html - Joachim Breitner has reported that the `linker_unload` test in GHC has been failing, but it's been surprisingly hard to reproduce reliably on our build machines! https://www.haskell.org/pipermail/ghc-devs/2014-December/007528.html - Moritz Angermann posted a proposal about the Out of Process Template Haskell project, started by the GHCJS developers. In short, they want to work out how to get Template Haskell working in a stage2 GHC for things like iOS or Browser devices: https://www.haskell.org/pipermail/ghc-devs/2014-December/007555.html - Lennart Augustsson has an inquiry about his program: why is it running out of memory? But the stranger thing: why does it only run out if heap profiling ''is not enabled''? Nobody has quite figured out, but if you're a guru, it may be a good chance to help out: https://www.haskell.org/pipermail/ghc-devs/2014-December/007582.html - Yuras Shumovich tracked down some nasty bugs in the typechecker's linter, causing several programs to fail to work when compiled by GHC. A quick diagnosis, but no fix has been merged quite yet: https://www.haskell.org/pipermail/ghc-devs/2014-December/007580.html - Richard Eisenberg wants feedback on a what he thinks is a design wart in the use of `-XStandaloneDeriving`, and he's not only proposed a solution, but wants to know what people think; typechecking fans are surely puzzling away already: https://www.haskell.org/pipermail/ghc-devs/2014-December/007589.html - David Spies has run into an interesting situation: why does -O make his program **slower** instead of faster? Well, nobody has quite figured out why yet, but it's an interesting question - maybe on a lazy monday developer can help figure out: https://www.haskell.org/pipermail/ghc-devs/2014-December/thread.html - Richard E. has another thread on the list, this time about development work flows: what do we do about painful merges? https://www.haskell.org/pipermail/ghc-devs/2014-December/007586.html Closed tickets this week include: #9850, #9005, #9828, #9833, #9582, #8935, #9186, #9480, #9497, #7908, #4347, #3977, #3859, #3844, #3814, #3771, #3739, #2182, #9812, #4921, #7947, #9240, #5401, #3625, #3517, #9444, #9142, #3447, #8894, #3065, #3191, #2697, #2836, #5443, #7736, #2489, #2456, #2204, #9777, #9859, #9869, #9808 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
