Re: [ANNOUNCE] GHC 8.6.5-rc1 is now available
On Tue, 9 Apr 2019 at 02:28, Ben Gamari wrote: > The GHC team is proud to announce the first release candidate of 8.6.5. > The source distribution, binary distributions, and documentation are > available at > https://downloads.haskell.org/~ghc/8.6.5-rc1 I don't see any source tarball... Jens ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Merge Request Submission Confusion
Perhaps the current 'my fork is not available' mess is actually the root cause, then? On Mon, 8 Apr 2019 at 21:56, Artem Pelenitsyn wrote: > > On Mon, 8 Apr 2019 at 14:22 Ben Gamari wrote: >> >> Ara Adkins writes: >> >> > I don't, which is the curious thing. There's just a gap above the >> > filter dropdown where it should be. >> > >> Hmm, it's possible this is related to the fact that you had only >> reporter privileges. > > > Just a datapoint here: I have only Reporter rights, and I do see "New Merge > Request" button on the "Merge Requests" page of the ghc/ghc project. And I'm > pretty sure I had it back when I didn't have any (non-trivial) permissions. > > -- > Best, Artem > > >> >> I just gave you the developer role; have things >> changed at all? >> >> Cheers, >> >> - Ben >> >> ___ >> 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
Re: Merge Request Submission Confusion
On Mon, 8 Apr 2019 at 14:22 Ben Gamari wrote: > Ara Adkins writes: > > > I don't, which is the curious thing. There's just a gap above the > > filter dropdown where it should be. > > > Hmm, it's possible this is related to the fact that you had only > reporter privileges. Just a datapoint here: I have only Reporter rights, and I do see "New Merge Request" button on the "Merge Requests" page of the ghc/ghc project. And I'm pretty sure I had it back when I didn't have any (non-trivial) permissions. -- Best, Artem > I just gave you the developer role; have things > changed at all? > > Cheers, > > - Ben > > ___ > 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
Re: Validation Failures on aarch64
The patch I’m validating is actually to fix those memory barrier issues. It turns out these failures were all due to GHC complaining about the LLVM version on stderr; sorry for rubber ducking the list! On Mon, Apr 8, 2019 at 1:26 PM Phyx wrote: > Just a wild guess, but considering the time it's taken to run through the > testsuite you're running it on a reasonable AArch64 machine. > You may be hitting the weak memory ordering bugs > https://gitlab.haskell.org/ghc/ghc/issues/15449 , though I haven't > followed the ticket very closely... > > On Mon, Apr 8, 2019 at 8:55 PM Travis Whitaker > wrote: > >> Hello GHC devs, >> >> When attempting to validate a patch on aarch64, it seems there are a >> large number of validation failures: >> >> SUMMARY for test run started at Mon Apr 8 07:19:05 2019 UTC >> 0:15:35 spent to go through >> 6890 total tests, which gave rise to >>17169 test cases, of which >>10018 were skipped >> 41 had missing libraries >> 3151 expected passes >> 150 expected failures >> 11 caused framework failures >>0 caused framework warnings >>0 unexpected passes >> 3798 unexpected failures >>0 unexpected stat failures >> >> The failures seem consistent on recent-ish master, specifically the >> neighborhood of 6113d0d4540af7853c71e9f42a41c3b0bab386fd. Is this to be >> expected? >> >> Thanks, >> >> Travis Whitaker >> ___ >> 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
Re: Validation Failures on aarch64
Just a wild guess, but considering the time it's taken to run through the testsuite you're running it on a reasonable AArch64 machine. You may be hitting the weak memory ordering bugs https://gitlab.haskell.org/ghc/ghc/issues/15449 , though I haven't followed the ticket very closely... On Mon, Apr 8, 2019 at 8:55 PM Travis Whitaker wrote: > Hello GHC devs, > > When attempting to validate a patch on aarch64, it seems there are a large > number of validation failures: > > SUMMARY for test run started at Mon Apr 8 07:19:05 2019 UTC > 0:15:35 spent to go through > 6890 total tests, which gave rise to >17169 test cases, of which >10018 were skipped > 41 had missing libraries > 3151 expected passes > 150 expected failures > 11 caused framework failures >0 caused framework warnings >0 unexpected passes > 3798 unexpected failures >0 unexpected stat failures > > The failures seem consistent on recent-ish master, specifically the > neighborhood of 6113d0d4540af7853c71e9f42a41c3b0bab386fd. Is this to be > expected? > > Thanks, > > Travis Whitaker > ___ > 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
Re: Validation Failures on aarch64
What kinds of tests are failing? Have they always failed? On Mon, Apr 8, 2019 at 8:55 PM Travis Whitaker wrote: > > Hello GHC devs, > > When attempting to validate a patch on aarch64, it seems there are a large > number of validation failures: > > SUMMARY for test run started at Mon Apr 8 07:19:05 2019 UTC > 0:15:35 spent to go through > 6890 total tests, which gave rise to >17169 test cases, of which >10018 were skipped > 41 had missing libraries > 3151 expected passes > 150 expected failures > 11 caused framework failures >0 caused framework warnings >0 unexpected passes > 3798 unexpected failures >0 unexpected stat failures > > The failures seem consistent on recent-ish master, specifically the > neighborhood of 6113d0d4540af7853c71e9f42a41c3b0bab386fd. Is this to be > expected? > > Thanks, > > Travis Whitaker > ___ > 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
Validation Failures on aarch64
Hello GHC devs, When attempting to validate a patch on aarch64, it seems there are a large number of validation failures: SUMMARY for test run started at Mon Apr 8 07:19:05 2019 UTC 0:15:35 spent to go through 6890 total tests, which gave rise to 17169 test cases, of which 10018 were skipped 41 had missing libraries 3151 expected passes 150 expected failures 11 caused framework failures 0 caused framework warnings 0 unexpected passes 3798 unexpected failures 0 unexpected stat failures The failures seem consistent on recent-ish master, specifically the neighborhood of 6113d0d4540af7853c71e9f42a41c3b0bab386fd. Is this to be expected? Thanks, Travis Whitaker ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [ANNOUNCE] GHC 8.6.5-rc1 is now available
Hi Ben, On Mon, 8 Apr 2019 at 13:59, Andrés Sicard-Ramírez wrote: > Using > https://downloads.haskell.org/ghc/8.6.5-rc1/ghc-8.6.4.20190406-x86_64-deb8-linux.tar.xz > I running as usual > > $ ./configure --prefix= > $ make install > > I got the following error: > > ./template-haskell.cabal has been changed. Re-configuring with most recently > used options. If this fails, please run configure manually. > Configuring template-haskell-2.14.0.0... > ghc-cabal: Cannot find the program 'ghc'. User-specified path > '/builds/ghc/ghc/inplace/bin/ghc-stage1' does not refer to an executable and > the program is not on the system path. > > ghc.mk:985: recipe for target 'install_packages' failed > make[1]: *** [install_packages] Error 1 > Makefile:51: recipe for target 'install' failed > make: *** [install] Error 2 > I could install the release candidate. There was a problem with my path. Sorry for the noise. Best, -- Andrés ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Merge Request Submission Confusion
Thanks so much Ben! That seems to have done the trick. Unfortunately I seem to have hit another hurdle, as my fork doesn't seem to be in the list of potential sources at all [0]. Similarly if I try and start the MR from within my fork, the only target is my fork. It's like it's lost its parent relationship to the main GHC repo. Any idea why that would be? I did fork quite a while back, so maybe something got borked in one of the various GitLab upgrade snafus. I tried to delete the fork and fork again, figuring that I could just push my changes from my local, but the deletion has failed with "This project was scheduled for deletion, but failed with the following message: Permission denied @ rb_sysopen - /var/lib/acme/gitlab.haskell.org/registry-auth.key " Remarkably odd. Sorry to load all these things onto your plate! Best, _ara [0] https://gitlab.haskell.org/iamrecursion/ghc On Mon, 8 Apr 2019 at 19:22, Ben Gamari wrote: > > Ara Adkins writes: > > > I don't, which is the curious thing. There's just a gap above the > > filter dropdown where it should be. > > > Hmm, it's possible this is related to the fact that you had only > reporter privileges. I just gave you the developer role; have things > changed at all? > > Cheers, > > - Ben > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [ANNOUNCE] GHC 8.6.5-rc1 is now available
Hi Ben, Using https://downloads.haskell.org/ghc/8.6.5-rc1/ghc-8.6.4.20190406-x86_64-deb8-linux.tar.xz I running as usual $ ./configure --prefix= $ make install I got the following error: ./template-haskell.cabal has been changed. Re-configuring with most recently used options. If this fails, please run configure manually. Configuring template-haskell-2.14.0.0... ghc-cabal: Cannot find the program 'ghc'. User-specified path '/builds/ghc/ghc/inplace/bin/ghc-stage1' does not refer to an executable and the program is not on the system path. ghc.mk:985: recipe for target 'install_packages' failed make[1]: *** [install_packages] Error 1 Makefile:51: recipe for target 'install' failed make: *** [install] Error 2 Best, On Mon, 8 Apr 2019 at 13:28, Ben Gamari wrote: > > Hello everyone, > > The GHC team is proud to announce the first release candidate of 8.6.5. > The source distribution, binary distributions, and documentation are > available at > > https://downloads.haskell.org/~ghc/8.6.5-rc1 > > This release fixes a handful of issues with 8.6.4: > > - Binary distributions once again ship with Haddock documentation including >syntax highlighted source of core libraries (#16445) > > - A build system issue where use of GCC with `-flto` broke `configure` >was fixed (#16440) > > - An bug affecting Windows platforms wherein XMM register values could be >mangled when entering STG has been fixed (#16514) > > - Several Windows packaging issues resulting from the recent CI rework. >(#16408, #16398, #16516) > > Since this is a relatively small bugfix release we are bypassing the > alpha releases and moving right to the release candidate stage. If all > goes well the final release will be cut next week. > > As always, if anything looks amiss do let us know. > > Happy testing! > > Cheers, > > - Ben > La información contenida en este correo electrónico está dirigida únicamente > a su destinatario y puede contener información confidencial, material > privilegiado o información protegida por derecho de autor. Está prohibida > cualquier copia, utilización, indebida retención, modificación, difusión, > distribución o reproducción total o parcial. Si usted recibe este mensaje por > error, por favor contacte al remitente y elimínelo. La información aquí > contenida es responsabilidad exclusiva de su remitente por lo tanto la > Universidad EAFIT no se hace responsable de lo que el mensaje contenga. The > information contained in this email is addressed to its recipient only and > may contain confidential information, privileged material or information > protected by copyright. Its prohibited any copy, use, improper retention, > modification, dissemination, distribution or total or partial reproduction. > If you receive this message by error, please contact the sender and delete > it. The information contained herein is the sole responsibility of the sender > therefore Universidad EAFIT is not responsible for what the message contains. > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Andrés ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
[ANNOUNCE] GHC 8.6.5-rc1 is now available
Hello everyone, The GHC team is proud to announce the first release candidate of 8.6.5. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/~ghc/8.6.5-rc1 This release fixes a handful of issues with 8.6.4: - Binary distributions once again ship with Haddock documentation including syntax highlighted source of core libraries (#16445) - A build system issue where use of GCC with `-flto` broke `configure` was fixed (#16440) - An bug affecting Windows platforms wherein XMM register values could be mangled when entering STG has been fixed (#16514) - Several Windows packaging issues resulting from the recent CI rework. (#16408, #16398, #16516) Since this is a relatively small bugfix release we are bypassing the alpha releases and moving right to the release candidate stage. If all goes well the final release will be cut next week. As always, if anything looks amiss do let us know. Happy testing! Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Merge Request Submission Confusion
Ara Adkins writes: > I don't, which is the curious thing. There's just a gap above the > filter dropdown where it should be. > Hmm, it's possible this is related to the fact that you had only reporter privileges. I just gave you the developer role; have things changed at all? Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: CI execution
Yes, this is an consequence of a bug in gitlab which meant that pushes to branches which were also MRs were built twice. Oh ok! If you want your commit to be built you could make a MR? I don't like the idea of submitting a MR just to test some code. It isn't a merge request yet, yet I would like to check that I don't break something on platforms I don't have access to and check for performance regressions. I'm not sure there is a way to manually trigger the CI pipeline. If you really want to you could modify the .gitlab-ci.yml file on your branch. I've just read on [1] that we can allow this. Hence: https://gitlab.haskell.org/ghc/ghc/merge_requests/730 Cheers, Sylvain [1] https://docs.gitlab.com/ee/ci/yaml/#using-your-own-runners On 08/04/2019 15:57, Matthew Pickering wrote: Yes, this is an consequence of a bug in gitlab which meant that pushes to branches which were also MRs were built twice. I'm not sure there is a way to manually trigger the CI pipeline. If you really want to you could modify the .gitlab-ci.yml file on your branch. If you want your commit to be built you could make a MR? Cheers, Matt On Mon, Apr 8, 2019 at 2:22 PM Sylvain Henry wrote: Hi devs, It seems that the CI doesn't check branches in GHC forks on Gitlab anymore. Is is intentional? Is there a way to trigger a CI execution manually on a specific branch? Thanks, Sylvain ___ 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
Re: CI execution
Yes, this is an consequence of a bug in gitlab which meant that pushes to branches which were also MRs were built twice. I'm not sure there is a way to manually trigger the CI pipeline. If you really want to you could modify the .gitlab-ci.yml file on your branch. If you want your commit to be built you could make a MR? Cheers, Matt On Mon, Apr 8, 2019 at 2:22 PM Sylvain Henry wrote: > > Hi devs, > > It seems that the CI doesn't check branches in GHC forks on Gitlab > anymore. Is is intentional? Is there a way to trigger a CI execution > manually on a specific branch? > > Thanks, > Sylvain > > ___ > 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
CI execution
Hi devs, It seems that the CI doesn't check branches in GHC forks on Gitlab anymore. Is is intentional? Is there a way to trigger a CI execution manually on a specific branch? Thanks, Sylvain ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Merge Request Submission Confusion
I don't, which is the curious thing. There's just a gap above the filter dropdown where it should be. On Mon, 8 Apr 2019 at 13:56, Ben Gamari wrote: > > Ara Adkins writes: > > > Hey all, > > > > I'm trying to submit a minor MR as described on the wiki [0]. I can't > > seem to find the mentioned 'New Merge Request' button, however. Do I > > need a specific set of permissions to open MRs? > > > > Any pointers would be appreciated. > > > Do you see a "New merge request" button in the top right (below the > navigation bar) of this page [1]? > > You can also navigate to any page under the ghc/ghc project and there > should be a "New merge request" entry under the "+" menu in the navbar. > > Cheers, > > - Ben > > > [1] https://gitlab.haskell.org/ghc/ghc/merge_requests ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Merge Request Submission Confusion
Ara Adkins writes: > Hey all, > > I'm trying to submit a minor MR as described on the wiki [0]. I can't > seem to find the mentioned 'New Merge Request' button, however. Do I > need a specific set of permissions to open MRs? > > Any pointers would be appreciated. > Do you see a "New merge request" button in the top right (below the navigation bar) of this page [1]? You can also navigate to any page under the ghc/ghc project and there should be a "New merge request" entry under the "+" menu in the navbar. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/merge_requests signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Merge Request Submission Confusion
Hey all, I'm trying to submit a minor MR as described on the wiki [0]. I can't seem to find the mentioned 'New Merge Request' button, however. Do I need a specific set of permissions to open MRs? Any pointers would be appreciated. Best, _ara [0] https://gitlab.haskell.org/ghc/ghc/wikis/home#opening-a-merge-request ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Proposal: Don't read environment files by default
On Sun, 7 Apr 2019 at 16:57, Oleg Grenrus wrote:
>
> On 7.4.2019 17.21, Simon Marlow wrote:
> > As I understand it, the aim is to support workflows like "cabal
> > install $pkg; ghci" (amongst other things). This currently works with
> > 'cabal install' because it installs into the global package DB, but it
> > doesn't work with 'cabal new-install' which installs into
> > `~/.cabal/store`. Is the plan that 'cabal new-install' will drop a
> > .ghc-environment file in the current directory, even outside of a
> > cabal package/project? I would find that *very* surprising as a user.
>
> This is not correct.
Well, it was a question :)
> Cabal doesn't write (local) .ghc.environment files
> when you `cabal v2-install` __outside__ the project (actually it
> doesn't, even when you `v2-install` the local project either, as you
> don't build the local project then).
> - When you install an executable, say `cabal v2-install alex` it do
> nothing related to environment files (there is inference in reading them
> atm though)
> - When you install a library, say `cabal v2-install distributive --lib`,
> then `cabal` (tries to) update
> `~/.ghc/-/environments/default` (or specified
> environment), so following
> `ghci` or `(ghci -package-env=somename) could pickup that library.
>
Thanks, I wasn't aware of the default environment file. Seems perfectly
reasonable to me.
> Instead of cabal ghci -package $pkg you can do
>
> cabal v2-install $pkg1 --lib --package-env=foo
> cabal v2-install $pkg2 --lib --package-env=foo
> ...
> ghci -package-env=foo
>
> Or alternatively
>
> cabal v2-repl -b $pkg
>
> Unfortunately neither way is (known) bug free at the moment. I mostly
> use the former, with the `default` package-env (then I can omit
> --package-env flags) for all kind of experiments, e.g. to try out things
> when answering people on `#haskell` or Stack Overflow; but I have my own
> way to create environment file (i.e. I don't use v2-install --lib), as
> cabal is atm not perfect, see Cabal's issue 5888. It's however important
> to note, that `cabal` makes `ghc` ignore these global environments
> (especially the default one) in builds etc, so `cabal v2-build` works.
>
This all sounds good to me. I hope you can work out the bugs!
Cheers
Simon
> I suppose I somewhat agree with those who are calling for environment
> > files to require a command-line flag. We've gone to all this trouble
> > to make a nice stateless model for the package DB, but then we've
> > lobbed a stateful UI on top of it, which seems odd and is clearly
> > surprising a lot of people.
>
> I disagree. I created `~/.ghci` and `~/.../environments/default` because
> I want some defaults. Note: with v1-install people managed
> user-package-db, with v2-install you are supposed to manage
> environment(s). Yet, you can also only use `cabal v2-repl` or `cabal
> v2-run` (See "new-run also supports running script files that ..." in
> https://cabal.readthedocs.io/en/latest/nix-local-build.html#cabal-new-run
> ).
>
> Most of the above works (sans known bugs), and if you run Ubuntu, I
> invite you to try it out, as it's easy to install from Herbert's PPA:
> https://launchpad.net/~hvr/+archive/ubuntu/ghc
>
> >
> > Cheers
> > Simon
> >
> > On Thu, 28 Mar 2019 at 12:25, Herbert Valerio Riedel
> > mailto:hvrie...@gmail.com>> wrote:
> >
> > Matthew,
> >
> > I realize this to be a controversial issue, but what you're
> suggesting
> > is effectively an attempt at cutting this cabal V2 feature off at
> > the knees
> > ("If Cabal won't change its default let's cripple this feature on
> > GHC's
> > side by rendering it pointless to use in cabal").
> >
> > If ghc environment aren't read anymore by default they fail to have
> > the purpose they were invented for in the first place!
> >
> > At the risk of repeating things I've tried to explain already in the
> > GitHub issue let me motivate (again) why we have these env files: We
> > want to be able to provide a stateful interface providing the common
> > idiom users from non-Nix UIs are used to, and which `cabal` and `ghc`
> > already provided in the past; e.g.
> >
> >
> > ,
> > | $ cabal v1-install lens lens-aeson
> > |
> > | $ ghc --make MyProgUsingLens.hs
> > | [1 of 1] ...
> > | ...
> > |
> > | $ ghci
> > | GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help
> > | Prelude> import Control.Lens
> > | Prelude Control.Lens>
> > `
> >
> > or similarly, when you had just `cabal v1-build` something, you'd get
> > access to your projects dependencies which were installed into ghc's
> > user pkg-db.
> >
> > This is also a workflow which has been well documented for over a
> > decade
> > in Haskell's literature and instructions *and* this is the same
> > idiom as
> > used by many popular package managers out there ("${pkgmgr} install
> > somelibrary")
> >
>
