Re: The reason for non-GHC boot dependencies

[Artem Pelenitsyn]

> I think they could be statically linked. But those boot libraries don't
> change much and generally
> don't really cause us nor users pain so it seems like there is little
> reason to do so to me.

There once was a sizeable patch to Haddock to switch from xhtml to Lucid,
and it was rejected, seemingly, solely on the grounds that Lucid can't be
added to boot libraries [1].
Since then Lucid dropped the heavier part of its dependency tree, so it's
maybe not an issue anymore,
but my point is that there's more to this story than what you mentioned:
the need for keeping Haddock and HPC's
dependencies in the set of boot libraries may slow down development of
those tools.

[1]: https://github.com/haskell/haddock/pull/1598#issuecomment-1621765685

On Wed, Jul 10, 2024 at 12:10 PM Andreas Klebinger via ghc-devs <
ghc-devs@haskell.org> wrote:

> I think they could be statically linked. But those boot libraries don't
> change much and generally
> don't really cause us nor users pain so it seems like there is little
> reason to do so to me.
>
>  > Surely the size of binaries can't be the only concern, otherwise we'd
> use upx¹ on them when distributing them.
>
> I believe Ben experimented with executable compression tools in the past
> with little success.
> But there were segfaults, executables being flagged by antivirus and
> perhaps more issues I forgot
> which just made using it unrealistic at the time.
>
> But perhaps the tooling has matured in the meantime.
>
> Since our distributions are already compressed purely for *distribution*
> purposes I would expect the gains there to be rather slim anyway.
>
> So it's not really that we don't care about size, just that these tools
> seemed not reliable enough for the benefits they offer in the past.
>
> Am 10/07/2024 um 11:01 schrieb Hécate via ghc-devs:
> > Hi devs,
> >
> > I had a chat earlier today with someone and found myself unable to
> > explain the reason why GHC came with boot dependencies like xhtml,
> > that are dependencies of Haddock and HPC.
> >
> > Obviously, the binaries are (haskell-)dynamically linked when
> > distributed, but what is the reason why haddock, hpc, etc can't be
> > (haskell-)statically linked when distributed?
> >
> > Surely the size of binaries can't be the only concern, otherwise we'd
> > use upx¹ on them when distributing them.
> >
> > Cheers,
> >
> > Hécate
> >
> >
> > 1: https://upx.github.io
> >
> ___
> 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: Cabal woe

[Artem Pelenitsyn]

Hi Simon,

The direct answer to your particular problem is that cabal-install-3.10.1
(which you're using) does not add `base` in the package environment created
by `install --lib` by default.
So, to fix the problem you'd need to say `cabal install --lib base
hashtables primitive` instead.
Better yet, you could upgrade your cabal-install to version 3.10.3
(recommended by GHCup), where this behavior was reversed (base is added by
default).

To add to how brittle `install --lib` is: the 3.10.1 behavior (no base by
default) bothered people [1] and was changed in 3.10.3 [2]. But the 3.10.3
behavior (add base by default) also bothers people [3]!
And note that although you have an easy way to solve your issue (add base
in the list of libraries in the call to install --lib), the users of 3.10.3
who don't want base added by default don't have such an easy way.
(By easy I mean using only cabal CLI and don't edit env files manually, for
example.)

More general, I think, it's possible to develop a mental model for today's
`install --lib` (either 3.10.1 or 3.10.3, doesn't matter in the grand
scheme),
and use it effectively for "little experiments" as advocated by Richard in
the above-mentioned issue [4] (note that the issue was solved since!).
The prerequisite for that is to understand GHC environment files and that
`install --lib` is mostly a (n incomplete) CLI interface to them.

Yet, people argue for a more holistic "environment" experience, see, e.g.,
the above mentioned [5] (*the* cabal-env issue)
or a very recent push from the old cabal sandboxes perspective:
https://github.com/haskell/cabal/issues/10098
or this thread :-)

Also, (much in the spirit of *Carthago delenda est*) I try to conclude my
every reply about install --lib with what's already mentioned by Tom:
*always* use `cabal install --lib` with `--package-env=.` It will save you
a bunch of pain related to the "global state" (not all of it, perhaps).

--
Best, Artem

[1]: https://github.com/haskell/cabal/issues/8894
[2]: https://github.com/haskell/cabal/pull/8903
[3]: https://github.com/haskell/cabal/issues/9672
[4]: https://github.com/haskell/cabal/issues/7832
[5]: https://github.com/haskell/cabal/issues/6481

On Tue, Jul 9, 2024 at 4:58 AM Simon Peyton Jones <
simon.peytonjo...@gmail.com> wrote:

> Friends
>
> I'm trying to repro #25064 with my development build of GHC.  The test
> case depends on packages `primitive` and `hashtables`.  So I try this (see
> below).
>
> Alas, apparently after the `cabal install`, it can't find Prelude.
>
> What should I do?  I tried removing the "environments" file, whatever that
> is, which then meant it could find Prelude -- but the libraries were no
> longer installed.
>
> I lack a decent model of what is going on with installing packages for my
> development builds.   Is there a write up anywhere?
>
> Thanks
>
> Simon
>
>
> bash$ cabal install --lib hashtables primitive --with-compiler
> $HOME/code/HEAD/$s2
> Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.10.1.0
> supports
> 'ghc' version < 9.8): /home/simonpj/code/HEAD/_build/stage1/bin/ghc is
> version
> 9.11.20240517
> Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.10.1.0
> supports
> 'ghc' version < 9.8): /home/simonpj/code/HEAD/_build/stage1/bin/ghc is
> version
> 9.11.20240517
> Resolving dependencies...
> bash$  ~/code/HEAD/$s2 -c T25064.hs
> Loaded package environment from
> T25064.hs:1:8: error: [ ]8;;https://errors.haskell.org/messages/GHC-87110
> \GHC-87110 ]8;; \]
> Could not load module ‘Prelude’.
> It is a member of the hidden package ‘base-4.20.0.0’.
> Use -v to see a list of the files searched for.
>   |
> 1 | module Bug where
>   |^^^
>
> bash$ rm /home/simonpj/.ghc/x86_64-linux-9.11.20240517/environments/default
> bash$ ~/code/HEAD/$s2 -c T25064.hs
> T25064.hs:3:1: error: [ ]8;;https://errors.haskell.org/messages/GHC-61948
> \GHC-61948 ]8;; \]
> Could not find module ‘Control.Monad.Primitive’.
> Perhaps you meant Control.Monad.Writer (from mtl-2.3.1)
> Use -v to see a list of the files searched for.
>   |
> 3 | import Control.Monad.Primitive
>   | ^^
>
> T25064.hs:4:1: error: [ ]8;;https://errors.haskell.org/messages/GHC-87110
> \GHC-87110 ]8;; \]
> Could not find module ‘Data.HashTable.ST.Basic’.
> Use -v to see a list of the files searched for.
>   |
> 4 | import qualified Data.HashTable.ST.Basic as H
>   | ^
>
>
> ___
> 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: GHC development asks too much of the host system

[Artem Pelenitsyn]

Thanks Ben, very interesting, especially the cloud Shake stuff.

> If everyone were to use, e.g.,
>   ghc.nix this could be largely mitigated, but this isn't the world in
>   which we live.

I don't know why you'd want everyone to use it necessarily to improve
things.
If there was a clear statement that you may elect to use ghc.nix and get X%
speedup,
that would be a good start. And then people can decide, based on their setup
and their aversion to tools like Nix, etc. in general.

The real issue is that currently you don't benefit much from ghc.nix
because the main
performance sink is the GHC tree itself. The way out is to use a cloud
build system, most likely
Cloud Shake, which, as you describe, has a couple of issues in this case:

1) Native dependencies. This should be possible to solve via Nix, but
unfortunately,
this is not quite there yet because Shake doesn't know about Nix (afaik). I
think to actually get
there, you'd need some sort of integration between Nix and Shake akin to
what Tweag
built for Nix and Bazel (cf. rules_nixpkgs [1]). Their moto is: Nix for
"external" or "system"
components, and Bazel for "internal" or "local" ones.

2) Bootstrapping aspect. Maybe this is a challenge for rebuilds after
modification,
but I think people on this thread were quoting the "time to first build"
more.
I don't see how avoiding to build master locally after a fresh (worktree)
checkout by
downloading build results from somewhere, connects to bootstrapping. I
think it doesn't.

As for rebuilds. People are already using --freeze1 (you suggested it
earlier in this very thread!),
so I don't see how saying "freezing stage 1 is dangerous even if faster"
connects to practise of
GHC development. Of course, you may not find a remote cache with relevant
artefacts after
local updates, but that's not the point. The point is to not have to build
`master`, not
`feaure-branch-t12345`. Rebuilds should be rather pain-free in comparison.

--
Best, Artem

[1]: https://github.com/tweag/rules_nixpkgs


On Tue, 19 Jul 2022 at 18:03, Ben Gamari  wrote:

> Artem Pelenitsyn  writes:
>
> > Hey everyone! I'm not a frequent contributor but I observed similar
> > challenges as Hécate. I notice couple points.
> >
> > ### HLS and other editor integrations
> >
> > I've never tried HLS for GHC development but it absolutely chokes on
> > Cabal for me (a $2K laptop), so I'm not surprised it's having troubles
> > with GHC. I've never tried to dig into it, but I heard before that
> > disabling plugins is a good start.
> >
> > Ghcid (after the introduction of ghc-in-ghci) was interesting but still
> on
> > a slow side.
> >
> > I once tried to generate ETAGS and use them from Emacs (with plain
> > haskell-mode): this was quite nice. As Moritz, I didn't use much above
> > syntax coloring, but ETAGS allowed jumping to definitions, which is
> > important. Maintaining tags wasn't fun, on the other hand.
> >
> > In all fairness, I think that's an issue with HLS more than with GHC.
> >
> > ### Build Times
> >
> > I have been using a dedicated server for this, but this still was
> > painful at times (even git clone takes non-negligible amount of time,
> > and I never got used to git worktree because of a hoop you have to
> > jump over, which I already forgot but I know it can be looked up in
> > Andreas Herrmann's presentation on developing GHC). I'm surprised no
> > one seems to try to challenge the status quo.
> >
> IMHO, `git worktree` is indispensible. Not only does it make cloning
> cheaper but it makes it trivial to share commits between work trees,
> which is incredibly helpful when cleaning up branch history,
> backporting, and other common tasks. I just wish it also worked
> transparently for submodules.
>
> > Hadrian is a Shake application. How is Cloud Shake doing? In the era
> > of Nix and Bazel you start assuming niceties like remote caching. It'd
> > be great to improve on this front as it just feels very wrong
> > rebuilding master again and again on every contributor's computer.
> > Especially after so much effort put into GHC modularity, which, I
> > believe, should make it easier to cache.
>
> Sadly using Cloud Shake in Hadrian ran into some rather fundamental
> difficulties:
>
>  * GHC has native dependencies (namely, the native toolchain, ncurses,
>gmp, and possible libdw and libnuma). If everyone were to use, e.g.,
>ghc.nix this could be largely mitigated, but this isn't the world in
>which we live.
>
>  * GHC is a bootstrapped compiler. Consequently, most changes will
>

Re: GHC development asks too much of the host system

[Artem Pelenitsyn]

Hey everyone! I'm not a frequent contributor but I observed similar
challenges
as Hécate. I notice couple points.

### HLS and other editor integrations

I've never tried HLS for GHC development but it absolutely chokes on Cabal
for me (a $2K laptop), so I'm not surprised it's having troubles with GHC.
I've never tried to dig into it, but I heard before that disabling plugins
is a
good start.

Ghcid (after the introduction of ghc-in-ghci) was interesting but still on
a slow side.

I once tried to generate ETAGS and use them from Emacs (with plain
haskell-mode): this
was quite nice. As Moritz, I didn't use much above syntax coloring, but
ETAGS
allowed jumping to definitions, which is important. Maintaining tags wasn't
fun,
on the other hand.

In all fairness, I think that's an issue with HLS more than with GHC.

### Build Times

I have been using a dedicated server for this, but this still was painful at
times (even git clone takes non-negligible amount of time, and I never got
used
to git worktree because of a hoop you have to jump over, which I already
forgot
but I know it can be looked up in Andreas Herrmann's presentation on
developing
GHC). I'm surprised no one seems to try to challenge the status quo.

Hadrian is a Shake application. How is Cloud Shake doing? In the era of Nix
and
Bazel you start assuming niceties like remote caching. It'd be great to
improve
on this front as it just feels very wrong rebuilding master again and again
on every
contributor's computer. Especially after so much effort put into GHC
modularity,
which, I believe, should make it easier to cache.

It's sad that GHC still needs ./boot && ./configure: this can preclude any
remote caching technology that I can imagine. At one point it seemed like
configure could go into Hadrian, but it didn't really happen.

In the bright future I see Hadrian doing the whole job and using remote
cache
on GitLab CI. Not sure how big of a task that would be.

--
Cheers, Artem


On Tue, 19 Jul 2022 at 15:11, Ben Gamari  wrote:

> Hécate  writes:
>
> > Hello ghc-devs,
> >
> > I hadn't made significant contributions to the GHC code base in a while,
> > until a few days ago, where I discovered that my computer wasn't able to
> > sustain running the test suite, nor handle HLS well.
> >
> > Whether it is my OS automatically killing the process due to oom-killer
> > or just the fact that I don't have a war machine, I find it too bad and
> > I'm frankly discouraged.
>
> Do you know which process was being killed? There is one testsuite tests
> that I know of which does have quite a considerable memory footprint
> (T16992) due to its nature; otherwise I would expect a reasonably recent
> machine to pass the testsuite without much trouble. It's particularly
> concerning if this is a new regression; is this the first time you have
> observed this particular failure?
>
> > This is not the first time such feedback emerges, as the documentation
> > task force for the base library was unable to properly onboard some
> > people from third-world countries who do not have access to hardware
> > we'd consider "standard" in western Europe or some parts of North
> > America. Or at least "standard" until even my standard stuff didn't cut
> > it anymore.
> >
> > So yeah, I'll stay around but I'm afraid I'm going to have to focus on
> > projects for which the feedback loop is not on the scale of hours , as
> > this is a hobby project.
> >
> > Hope this will open some eyes.
> >
> Hi Hécate,
>
> I would reiterate that the more specific feedback you can offer, the
> better.
>
> To share my some of my own experience: I have access to a variety of
> hardware,
> some of which is quite powerful. However, I find that I end up doing
> much of my development on my laptop which, while certainly not a slouch
> (being a Ryzen 4750U), is also not a monster. In particular, while a
> fresh build takes nearly twice as long on my laptop than some of the
> other hardware I have, I nevertheless find ways to make it worthwhile
> (due to the ease of iteration compared to ssh). If you routinely have
> multi-hour iteration times then something isn't right.
>
> In particular, I think there are a few tricks which make life far
> easier:
>
>
>  * Be careful about doing things that would incur
>significant amounts of rebuilding. This includes:
>
> * After modifying, e.g., `compiler/ghc.cabal.in` (e.g. to add a new
>   module to GHC), modify `compiler/ghc.cabal` manually instead of
>   rerunning `configure`.
>
> * Be careful about pulling/rebase. I generally pick a base commit to
>   build off of and rebase sparingly: Having to stop what I'm doing to
>   wait for full rebuild is an easy way to lose momentum.
>
> * Avoid switching branches; I generally have a GHC tree per on-going
>   project.
>
>  * Take advantage of Hadrian's `--freeze1` flag
>
>  * Use `hadrian/ghci` to typecheck changes
>
>  * Use the stage1 compiler instead of stage2 to smoke-test changes when

Re: GHC 9.4.1-alpha1 now available

[Artem Pelenitsyn]

Thanks a lot, devs!

A bug in the docs, it seems:

https://downloads.haskell.org/ghc/9.4.1-alpha1/docs/html/

references User Guide as

https://downloads.haskell.org/ghc/9.4.1-alpha1/docs/html/users_guide/index.html

but this url gives 404. Same with the GHC API link.

--
Best, Artem

On Sun, May 1, 2022, 7:18 PM Ben Gamari  wrote:

>
> The GHC developers are happy to announce the availability of the first
> alpha release of the GHC 9.4 series. Binary distributions, source
> distributions, and documentation are available at downloads.haskell.org:
>
>https://downloads.haskell.org/ghc/9.4.1-alpha1
>
> This major release will include:
>
>  - A new profiling mode, `-fprof-late`, which adds automatic cost-center
>annotations to all top-level functions *after* Core optimisation has
>run. This incurs significantly less performance cost while still
>providing informative profiles.
>
>  - A variety of plugin improvements including the introduction of a new
>plugin type, *defaulting plugins*, and the ability for typechecking
>plugins to rewrite type-families.
>
>  - An improved constructed product result analysis, allowing unboxing of
>nested structures, and a new boxity analysis, leading to less reboxing.
>
>  - Introduction of a tag-check elision optimisation, bringing
>significant performance improvements in strict programs.
>
>  - Generalisation of a variety of primitive types to be levity
>polymorphic. Consequently, the `ArrayArray#` type can at long last be
>retired, replaced by standard `Array#`.
>
>  - Introduction of the `\cases` syntax from [GHC proposal 0302]
>
>  - A complete overhaul of GHC's Windows support. This includes a
>migration to a fully Clang-based C toolchain, a deep refactoring of
>the linker, and many fixes in WinIO.
>
>  - Support for multiple home packages, significantly improving support
>in IDEs and other tools for multi-package projects.
>
>  - A refactoring of GHC's error message infrastructure, allowing GHC to
>provide diagnostic information to downstream consumers as structured
>data, greatly easing IDE support.
>
>  - Significant compile-time improvements to runtime and memory consumption.
>
>  - ... and much more
>
> We would like to thank Microsoft Azure, GitHub, IOHK, the Zw3rk
> stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous
> contributors whose on-going financial and in-kind support has
> facilitated GHC maintenance and release management over the years.
> Finally, this release would not have been possible without the hundreds
> of open-source contributors whose work comprise this release.
>
> As always, do give this release a try and open a [ticket] if you see
> anything amiss.
>
> Happy testing,
>
> - Ben
>
>
> [GHC proposal 0302]:
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-cases.rst
> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
> ___
> 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: downloading ghc head version

[Artem Pelenitsyn]

Hey Harendra,

How do you feel about Nix? This simple one-command-away way always worked
for me great:

https://github.com/mpickering/ghc-artefact-nix

(Modulo a caveat with the newer versions of Nix
https://github.com/mpickering/ghc-artefact-nix/issues/16 which is easily
fixed by changing the command in README from `nix run` to `nix shell`).

Interestingly, this Nix expression seems to work okay currently. It uses
fedora builds, not deb ones. But when I tried to reconstruct the link it is
supposed to use, I also couldn't download anything there:

https://gitlab.haskell.org/ghc/ghc/-/jobs/artifacts/master/raw/ghc-x86_64-fedora33-linux.tar.gz?job=validate-x86_64-linux-fedora33

--
Best, Artem

On Mon, 31 Jan 2022 at 17:43, Harendra Kumar 
wrote:

> It seems the latest artifacts download link
> (https://gitlab.haskell.org/ghc/ghc/-/jobs/artifacts/...) at GHC
> gitlab is not working.
>
> If this is not the right place to ask this, can someone point me to
> the right place?
>
> -harendra
>
> On Wed, 26 Jan 2022 at 18:38, Harendra Kumar 
> wrote:
> >
> > Hi,
> >
> > I am trying to set up a CI for ghc head version. I am not sure what is
> > the official supported method to install a nightly/head version of
> > GHC. haskell/actions/setup on github seems to support it via ghcup.
> > But it almost always fails, I saw it succeeding once till now. It
> > tries to download it from the following URL, but fails with 404 not
> > found:
> >
> > downloading:
> https://gitlab.haskell.org/ghc/ghc/-/jobs/artifacts/master/raw/ghc-x86_64-deb9-linux-integer-simple.tar.xz?job=validate-x86_64-linux-deb9-integer-simple
> >
> > I tried this link in the browser and I get the same error. Is that the
> > right way to install it? If not, can someone suggest a reliable way to
> > get the head version, other than building it myself?
> >
> > Thanks,
> > Harendra
> ___
> 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: DWARF support

[Artem Pelenitsyn]

Thanks everyone! A blog post would be awesome, indeed.

Ben, I didn't have anything particular in mind, just curious about possibly
more ergonomic alternatives to profiling builds for getting this sort of
information. (Motivation similar to Richard's, I think.)

On Fri, Nov 19, 2021, 1:57 AM Sven Tennie  wrote:

> Am Fr., 19. Nov. 2021 um 01:09 Uhr schrieb Ben Gamari <
> b...@smart-cactus.org>:
>
>> Artem Pelenitsyn  writes:
>>
>> > Another question would be where do I read about Haskell-native stack
>> > unwinder. The issue and MR Ben referenced have descriptions, but the MR
>> > didn't touch anything inside `docs` which is a bit scary. Are there any
>> > good recourses to dive into it besides the source code in the MR?
>> >
>> Indeed the user's guide documentation surrounding info table provenance
>> should be updated to note this new capability.
>>
>
> Hey Ben, Hey Artem, Hey all,
>
> Thanks for bringing this up! I'll add some documentation to the user's
> guide and will likely write a blog post covering the "material" from notes
> in a more approachable way.
>
> Two details to note regarding the IPE based backtrace mechanism:
>
> - It's based on return frames on the STG stack. So, it doesn't work for
> trivial programs. A return frame is produced when the scrutinee of a case
> expression is evaluated.
> The test [1] shows a working example.
>
> - To get backtraces containing references in libraries, those have to be
> compiled with `-finfo-table-map`, too.
>
> Now that I've got the attention of many GHC-Devs: A big Thank-You! goes to
> Ben and Matthew that were always reachable and always very helpful during
> the whole development process of this feature!
>
> Best regards,
>
> Sven
>
> [1] -
> https://gitlab.haskell.org/ghc/ghc/-/blob/aed98ddaf72cc38fb570d8415cac5de9d818/testsuite/tests/rts/decodeMyStack.hs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: DWARF support

[Artem Pelenitsyn]

Another question would be where do I read about Haskell-native stack
unwinder. The issue and MR Ben referenced have descriptions, but the MR
didn't touch anything inside `docs` which is a bit scary. Are there any
good recourses to dive into it besides the source code in the MR?

--
Best, Artem

On Thu, Nov 18, 2021, 11:31 AM Chris Smith  wrote:

> Just to satisfy my curiosity here, when talking about backtraces here, are
> you talking about a lexical call stack, or an execution stack?
>
> On Thu, Nov 18, 2021 at 11:24 AM Richard Eisenberg 
> wrote:
>
>>
>>
>> On Nov 18, 2021, at 10:29 AM, Ben Gamari  wrote:
>>
>> At this point, for backtrace support I would rather put my money is on a
>> native Haskell stack unwinder (such as Sven Tennie's work [3,4]). Not only
>> is it more portable but it is also more robust (whereas with DWARF any
>> single object lacking debug information would break unwinding), and is
>> significantly less costly since we know much more about the structure of
>> our stack than a DWARF unwinder would.
>>
>>
>> Interesting -- this is helpful to know. I had heard about DWARF support
>> for some years and thought that it would deliver stack traces. Now I will
>> look for other sources. All good -- I understand how this is hard! -- and
>> nice to know about.
>>
>> Thanks for the writeup, Ben.
>>
>> Richard
>> ___
>> 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

Re: Another hadrian option you might want to use

[Artem Pelenitsyn]

Is there a reason to not add (some of) these to the flavor=Quick?

—
Best, Artem

On Thu, Oct 21, 2021 at 11:18 AM Norman Ramsey  wrote:

>  > Perhaps it would be too niche of a resource, but what about collecting
>  > these options either in a Wiki page in GHC
>
> In the interests of "done now is better than perfect later," I have
> added a note about these options to
> https://gitlab.haskell.org/ghc/ghc/-/wikis/building/hadrian.
> This is where the command
>
>  > `--flavour=default+no_profiled_libs+omit_pragmas`
>
> is already documented.
>
>
> Norman
> ___
> 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: GHC and the future of Freenode

[Artem Pelenitsyn]

I've been using the recently created Types Zulip (for academic PL) -- my
first experience with this platform -- and also found it unusual at first
but then quite liked the dynamic topics thing (exactly for reasons Mario
describes).

Zulip or anything from 21st century would be a huge improvement on status
quo (i.e. IRC) in terms of attraction of new contributors. Think the
Phabricator –> GitLab transition but in the IM space.

--
Best, Artem

On Wed, May 19, 2021, 10:26 PM Mario Carneiro 
wrote:

> Speaking as a *heavy* user of the Rust and Lean zulip instances, I find it
> a huge improvement over the alternatives of Gitter and Discord, and I think
> IRC although I have not used IRC much. It takes some getting used to, but
> the topic threading is absolutely essential once you reach a certain size.
> Looking at other chat platforms, overlapping conversations are a major
> problem when you have more than around 10 people online at once. Rust
> routinely has 50 or more online at once, and channels help but even then
> you will have multiple topics in a single channel, and that extra level of
> organization is absolutely warranted. It also helps when you want to look
> back at the discussion (or even just find it again!) or continue an old
> conversation from a year ago. Most of these activities I couldn't even
> imagine doing in a Gitter/Discord style chat platform.
>
> I have no stake in this discussion, but I thought I should balance out the
> Zulip downvotes with some positive experiences. (Also, I would definitely
> be more likely to participate on a haskell Zulip than an IRC or Matrix
> instance, FWIW.)
>
> Mario Carneiro
>
> On Wed, May 19, 2021 at 9:58 PM Carter Schonwald <
> carter.schonw...@gmail.com> wrote:
>
>> I definitely find Zulip confusing and have failed to use it every time
>> I’ve tried
>>
>> If normal threading is lasagna layers, Zulip threading is like trying to
>> hold cooked spaghetti in your ha d.
>>
>> On Wed, May 19, 2021 at 2:40 PM Alex Rozenshteyn 
>> wrote:
>>
>>> (I'm a little ashamed that I lurk on this list but the thing that brings
>>> me out of lurking is a post on communication technologies)
>>>
>>> Not Zulip.
>>>
>>> Please not Zulip.
>>>
>>> I've used Zulip once many years ago, and once this year. Both times, its
>>> interface felt clunky, and it felt like it was trying to get the best of
>>> IRC, Slack, and a BBS and instead getting the worst of all the worlds.
>>> Synchronous communication was confusing, asynchronous communication was
>>> limited, and topics and channels didn't really do anything to organize
>>> things.
>>>
>>> I have two alternatives to add to consideration:
>>> * Mattermost: it's an open-source clone of Slack, which has its
>>> advantages and disadvantages, but at least it's familiar and heavily used UI
>>> * Discourse: it's an asynchronous communication tool, but that may
>>> acceptable or preferable, and there is already a Haskell Discourse set up (
>>> https://discourse.haskell.org/)
>>>
>>> On Wed, May 19, 2021 at 11:59 AM Ben Gamari  wrote:
>>>
 Carter Schonwald  writes:

 > I personally vote for irc.  Perhaps via Libera.
 >
 > What are some example vibrant  technical communities on matrix? I’ve
 > experienced such on irc but less so via more recent / newer platforms
 >
 I know that many subcommunities within the Rust community use Matrix. I
 have had quite good interactions in this context. Frankly I think that
 most of these newer options are technically much more conducive to
 technical collaboration than IRC.

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

Re: Compiling libraries

[Artem Pelenitsyn]

Yes, in particular, this:
https://gitlab.haskell.org/ghc/head.hackage

Readme there has some documentation…

On Thu, Apr 29, 2021 at 3:19 PM Carter Schonwald 
wrote:

> There’s hackage head, which has some docs on the gitlab instance. Though
> I’m not up to date on how to use it.
>
> On Thu, Apr 29, 2021 at 4:24 AM Simon Peyton Jones via ghc-devs <
> ghc-devs@haskell.org> wrote:
>
>> Ben and other friends
>>
>> What is the approved way to build libraries with (and for) a compiler
>> that I’ve just built?
>>
>> I tried this:
>>
>> bash$ cabal v2-install
>> --with-ghc=/home/simonpj/code/ghc-9.2-branch/inplace/bin/ghc-stage2
>> streamly --allow-newer
>>
>> but it failed with
>>
>> Data/Primitive/Types.hs:273:844: error:
>>
>> • Couldn't match expected type ‘Word#’ with actual type ‘Word8#’
>>
>> • In the fourth argument of ‘shimmedSetWord8Array#’, namely ‘x#’
>>
>> (This was for a compiler built from the ghc-9.2 branch.)
>>
>> I’d like to be able to do the same for HEAD.
>>
>> I need to do this to help with the numerous tickets asking about library
>> regressions.  For example, I want to be able repoduce @harendra’s example
>> , but I
>> can’t because I can’t build streamly.
>>
>> Thanks!
>>
>> 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
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Call for GHC Maintainers

[Artem Pelenitsyn]

Hello devs,

I may be under-qualified for this sort of task but I’d be happy to pitch in
if you find it useful.

—
Best regards,
Artem Pelenitsyn

On Mon, Aug 10, 2020 at 10:10 PM Moritz Angermann <
moritz.angerm...@gmail.com> wrote:

> Hi there!
>
> As it stands right now, Ben is the one who works tirelessly trying to
> cut releases. Not just for the most recent version, but also for
> previous versions. Most recently 8.10.2, but we have 9.0 coming up as
> well.
>
> I know that there are some people who deeply care for personal or
> professional reasons for older releases, 8.4, 8.6, 8.8, ... Some of
> them have stacks of patches applied, or proprietary extensions. I'd
> argue that most of those applied patches are backports of bug fixes
> and rarely language features, as language features will break
> compatibility (due to ghc, base, and other library versions anyway).
>
> I would therefore like drum up a group of people who will take care
> (ideally 2+ per release) of backporting and making minor partch
> releases. This does not have to go on forever, but it would take much
> needed load off of Ben to focus on what ever happens in ghc HEAD.
>
> So what would this work actually look like? It would consist of
> - going through the list of MRs and tagging those which are relevant
> for backporting to a certain release.
> - backport MRs where the MR does not cleanly apply.
> - fixup any test-suite failures.
> - agree on a date to cut/make the release.
>
> This is not a permanent commitment. I hope we can attract more people
> to the ghc release managers.
>
> I'm looking forward to great many responses. And I'm sure Ben will be
> able to help mentor us through cutting the first releases. I'll
> volunteer to be part of the 8.6 branch maintainers for now.
>
> Cheers,
>  Moritz
>
> PS: There is a slightly related discussion about release cadence and
> versions and how other projects deal with this in this ticket:
> https://gitlab.haskell.org/ghc/ghc/-/issues/18222
> ___
> 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: Search in GitLab

[Artem Pelenitsyn]

As a side note, the idea of making a taxonomy of errors with unique tagging
has been brought up on ghc-proposals recently, although marked as
out-of-scope (maybe rightly so):
https://github.com/ghc-proposals/ghc-proposals/pull/325
The ease of searching is among the major motivations behind it.

--
Best, Artem

On Mon, Jun 15, 2020, 5:07 PM Hécate  wrote:

> On 15/06/2020 19:50, Ben Gamari wrote:
> > Frankly, this makes me wonder whether we should change the output
> > produced for loops. The current error is essentially un-Googleable, as
> > we see here. I know I have personally struggled with this same issue in
> > the past.
>
> I wholeheartedly agree with this suggestion. Maybe we could even start a
> little taxonomy of errors by adding an error code
> to the message that would be more searchable? Something like E5032?
>
> ___
> 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: Strange library git glitch

[Artem Pelenitsyn]

Hey Simon,

This is nicely explained by Ryan in the message for the latest commit to
exceptions:

Add dist-boot to .gitignore

This is generated by GHC when building `exceptions` now that it has
been made a stage-0 boot library (as of commitghc/ghc@3027241
).


https://github.com/ekmett/exceptions/commit/23c0b8a50d7592af37ca09beeec16b93080df98f

Best, Artem

On Fri, May 15, 2020, 11:02 AM Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> Thanks.  It does have a directory dist-install/ in it – but that’s put
> there by the build system, so if I remove it, it’ll just come back.  And
> other libraries (like deepseq) has dist-install too but does not complain.
> So mysterious.
>
>
>
> On the other hand git submodule update –recursive **did** fix it.  Seems
> odd.  I’m already saying “submodules” and I don’ think any submodules have
> further submodules – or do they?
>
>
>
> Simon
>
>
>
> *From:* ghc-devs  *On Behalf Of *Hécate
> *Sent:* 15 May 2020 15:37
> *To:* ghc-devs@haskell.org
> *Subject:* Re: Strange library git glitch
>
>
>
> My bad, it seems like this is another issue.
>
> I found this StackOverflow page quite helpful in explaining the hows and
> whys:
>
> https://stackoverflow.com/questions/4873980/git-diff-says-subproject-is-dirty
>
> Cheers,
>
> Hécate
>
> Le 15/05/2020 à 16:30, Hécate a écrit :
>
> Hi Simon,
>
> I usually manage to get it to disappear by using `git submodule update
> --recursive`.
> Is it a flag you've used in your previous attempts?
>
> Cheers,
>
> Hécate.
>
> Le 15/05/2020 à 16:24, Simon Peyton Jones via ghc-devs a écrit :
>
> No amount of git submodule update makes it go away.  Any ideas?
>
>
>
> ___
>
> 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

Re: GHC 8.10.1 Release Plan

[Artem Pelenitsyn]

Hello Ben,

I hope to push the threaded RTS by default MR over the line now when the
GHC proposal has been accepted.

Here is the MR: https://gitlab.haskell.org/ghc/ghc/merge_requests/538

It has some unstable test suite failures: they appear only in some
configurations.
Notably, validate-x86_64-linux-deb9-debug fails more than others:
https://gitlab.haskell.org/ulysses4ever/ghc/pipelines/10289
I'd appreciate if someone could take a look and suggest a path forward.

--
Best wishes,
Artem


On Wed, 18 Sep 2019 at 16:08, Ben Gamari  wrote:

> tl;dr. If you have unmerged work that you would like to be in GHC 8.10
> please
>reply to this email and submit it for review in the next couple
>of weeks.
>
>
> Hello everyone,
>
> Now that GHC 8.8.1 is behind us it is time that we begin thinking about
> 8.10. There seems to be broad consensus within the subset of the
> community that I sampled that we should try to hold to the usual release
> date near the end of year for 8.10.1. I believe that this is a feasible
> goal with the caveat that we push the final release back by a couple of
> weeks in recognition that busy schedules of the holiday season tends to
> throw unexpected wrenches into the release process.
>
> In particular I would suggest the following concrete schedule:
>
> October  18 2019:  start of one week freeze in preparation for
> branching
> October  25 2019:  ghc-8.10 branch cut
> November 8  2019:  8.10.1-alpha1
> November 22 2019:  8.10.1-alpha2
> December 6  2019:  8.10.1-alpha3
> December 20 2019:  8.10.1-rc1
> January  10 2020:  Final 8.10.1 release
>
> If you have yet-unmerged work that you would like to see in GHC 8.10
> please do be in touch and open a merge request ASAP.
>
>
> One obvious question is how we will avoid the many delays that plagued
> the 8.8.1 release. Without delving too deep into the specific reasons for
> these delays, the reasons fell into two buckets:
>
>  1. delays due to CI stabilization
>  2. coordination delays with upstream libraries
>  3. fallout from MonadFail changes which landed only late in the release
> cycle
>
> Of these, (1) is largely behind us and (3) will be avoided by ensuring
> that core libraries changes are landed *before* the branch date.
>
> This leaves consideration (2). The problem of upstream library
> coordination has always been a tricky one but has grown more acute as
> our release schedule has accelerated. While no technical solution will
> eliminate the issue entirely, we believe that decoupling GHC's release
> schedule from those of its dependencies' is an important mitigation.
> We will be discussing this with upstream library maintainers in
> the coming weeks to establish how we can ensure that releases are
> available well ahead of the GHC 8.10 release, ideally by alpha2.
>
> 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

Stream Simon's report on HIW?

[Artem Pelenitsyn]

Hello devs,

Could someone at ICFP maybe stream Simon's report on the progress GHC made
last year? I'm pretty sure many would like to check it out.

Conference management streamed the main event but not the workshops. And
workshops videos are such a pain: HIW 2018 is still not up on the ICFP
youtube channel, although HIW 2017 and 2016 are:
https://www.youtube.com/channel/UCwRL68qZFfub1Ep1EScfmBw/playlists
(And Haskell 2018 playlist there has only 8 videos…)

--
Kind regards,
Artem
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Gitlab's disk full again

[Artem Pelenitsyn]

Hello,

Is there a reason to keep more than one backup of GitLab ever?

--
Best, Artem

On Sat, Aug 10, 2019, 4:49 AM Ömer Sinan Ağacan 
wrote:

> Hi,
>
> Just yesterday Gitlab was giving 500 because the disk was full. Ben
> deleted some
> files, but in less than 24h it's full again. This started happening
> regularly, I
> wonder if we could do something about this.
>
> The reason this time seems to be that Gitlab started generating 22G-large
> backups daily since the 7th. I'm not sure how important those backups are
> so I'm
> not deleting them.
>
> There's also a large docker-registry directory (101G).
>
> I think it might be good to set up some kind of downtime monitoring or
> maybe
> something on the Gitlab server to send an email when the disk is nearly
> full. It
> could send an email to people who has access to the server.
>
> It'd also be good to come up with an action plan when this happens. I have
> access to the server, but I have no idea which files are important.
> Documenting
> Gitlab setup (and the server details) in more details might be helpful.
>
> Does anyone have any other ideas to keep the server running?
>
> Ömer
> ___
> 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: LoadAllTargets not loading dependencies

[Artem Pelenitsyn]

Hello Sam,

It'd be easier to help if you posted the complete example somewhere (e.g.
Github).

--
Best, Artem

On Wed, 7 Aug 2019 at 15:39, Sam Halliday  wrote:

> Hello all,
>
> I've been following along with Stephen Diehl's blog series on the ghc
> api and I am using `load LoadAllTargets` on a .hs file (let's call it
> Wibble.hs) and then typechecking.
>
> All seems well until I add a second module (let's call it Wobble.hs) in
> the same package and import it from Wibble.
>
> I can see that the load has correctly calculated the dependency graph
> and includes Wobble in the dependencies of Wibble. But if I try to
> typecheck Wibble, then I get an error:
>
> Could not find module ‘Wobble’
> Use -v to see a list of the files searched for.
>   |
> 4 | import   Wobble
>   | ^^^
>
> I have separately compiled the package, and can see its packagedb is
> listed in the .ghc.env file. What else do I need to do so that Wibble
> can see Wobble?
>
> --
> Best regards,
> Sam
> ___
> 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: ModuleInfo.minf_rdr_env not exposed

[Artem Pelenitsyn]

Hey Sam,

I think the thing you propose hardly qualifies as a new feature (in the
sense of page you referenced), so not much of a hassle should be involved.
As long as it is a 3-lines change, I'd say go ahead and create an Issue and
an MR on Gitlab: you might be better off with getting feedback there.

--Best, Artem

On Tue, 6 Aug 2019 at 15:52, Sam Halliday  wrote:

> Hello,
>
> I would like to submit a patch to ghc 8.8 adding a function that exposes a
> field that is useful for tooling authors and can already be reached, albeit
> in a very awkward way.
>
> The process documented at
>
> https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/adding-features
> seems very heavyweight for the patch that I was planning to propose,
> which is just adding the following to GHC.hs (and exporting it):
>
>   modInfoRdrEnv :: ModuleInfo -> Maybe GlobalRdrEnv
>   modInfoRdrEnv = minf_rdr_env
>
> Without this accessor, we must reparse and typecheck the file to get the
> GlobalRdrElts, which is very inefficient and uses fields named "internal"
> so I'm guessing that's not a good thing to build a tool on top of.
>
> My colleague already wrote a tool using a workaround, see
> https://gitlab.com/tseenshe/hsinspect/blob/503cd48faba5b308be29ed44a12f7d6b22105f2b/exe/Main.hs#L53-61
>
> How should I go about submitting this? Do I need to write a test or is
> this trivial enough not to bother?
>
> Sam Halliday  writes:
>
> > Hi all,
> >
> > Is there a reason why minf_rdr_env (a field in ModuleInfo) is not
> > exposed?
> >
> > It's possible to reconstruct it in 8.4.4 (the only version I'm looking
> > at) with a TypecheckedModule via
> >
> >   let (tc_gbl_env, _) = GHC.tm_internals_ tmod
> >   minf_rdr_env = tcg_rdr_env tc_gbl_env
> >
> >
> > It's a useful thing to have for editor tooling (e.g. to get the correct
> > qualified imported symbols that may be autocompleted).
> >
> > --
> > Best regards,
> > Sam
>
> --
> Best regards,
> Sam
> ___
> 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: api to access .hi files

[Artem Pelenitsyn]

Hey Sam,

Starting from the implementation of :browse and going through the call
graph in:
https://gitlab.haskell.org/ghc/ghc/blob/master/ghc/GHCi/UI.hs
gave the following, which works for me:

module Main where

import   Control.Monad
import   Control.Monad.IO.Class

import   BasicTypes
import   DynFlags
import   GHC
import   GHC.Paths  (libdir)
import   Maybes
import   Panic

main = runGhc (Just libdir) $ do
  dflags <- getSessionDynFlags
  void $ setSessionDynFlags $ dflags {
  hscTarget = HscInterpreted
, ghcLink   = LinkInMemory
}
  t <- guessTarget "Main.hs" Nothing
  setTargets [t]
  _ <- load LoadAllTargets

  graph <- getModuleGraph
  mss <- filterM (isLoaded . ms_mod_name) (mgModSummaries graph)
  let m = ms_mod ms
  ms = head mss
  liftIO . putStrLn $ (show . length $ mss) ++ " modules loaded"
  mi <- getModuleInfo m
  let mod_info = fromJust mi
  dflags <- getDynFlags
  let names = GHC.modInfoTopLevelScope mod_info `orElse` []

  liftIO $ putStrLn $ "seen " <> (show $ length names) <> " Names"

--
Best, Artem

On Fri, 2 Aug 2019 at 15:47, Sam Halliday  wrote:

> To answer my own question with a solution and another question:
>
> Sam Halliday writes:
> > I'm mostly interested in gathering information about symbols and their
> > type signatures. As a first exercise: given a module+import section
> > for a haskell source file, I want to find out which symbols (and their
> > types) are available. Like :browse in ghci, but programmatically.
>
> This is answered by Stephen Diehl's blog post on the ghc api! How lucky
> I am: http://www.stephendiehl.com/posts/ghc_01.html
>
> He points to getNamesInScope
>
> Unfortunately I'm getting zero Names back when loading a file that
> imports several modules from ghc. Is there something I'm missing in the
> following?
>
> module Main where
>
> import   Control.Monad
> import   Control.Monad.IO.Class
> import   GHC
> import   GHC.Paths  (libdir)
>
> main = runGhc (Just libdir) $ do
>   dflags <- getSessionDynFlags
>   void $ setSessionDynFlags $ dflags {
>   hscTarget = HscInterpreted
> , ghcLink   = LinkInMemory
> }
>   addTarget $ Target (TargetFile "exe/Main.hs" Nothing) False Nothing
>   res <- load LoadAllTargets
>   liftIO $ putStrLn $ showPpr dflags res
>   names <- getNamesInScope
>   liftIO $ putStrLn $ "seen " <> (show $ length names) <> " Names"
>
>
> --
> Best regards,
> Sam
> ___
> 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: Invalid link in the wiki page "Building GHC on Windows"

[Artem Pelenitsyn]

Hey Joan,

Thanks for spotting this! Should be fixed now.
Also, wiki is now back to public access for editing (it was closed for
technical reasons last several days). So you can fix if anything pops up in
the future.

--
Best wishes, Artem

On Mon, 29 Jul 2019 at 08:36, Joan Karadimov 
wrote:

> Inside this wiki page:
> https://gitlab.haskell.org/ghc/ghc/wikis/building/preparation/windows
>
> ... there is a link to the latest cabal release. The link is:
>
> https://www.haskell.org/cabal/release/cabal-install-2.4.1.0/cabal-install-2.4.1.0-${arch}-unknown-mingw32.zip
>
>
> That link is not valid. It should be something like:
>
> https://downloads.haskell.org/cabal/cabal-install-2.4.1.0/cabal-install-2.4.1.0-${arch}-unknown-mingw32.zip
>
> The latter link is taken from https://www.haskell.org/cabal/download.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

Re: gitlab subject lines

[Artem Pelenitsyn]

Hey all,

Long uninformative prefixes are indeed a huge pain. If emails are something
you GitLab masters are going to look at, I have one more suggestion. It
would be nice if there was a way to tell email notifications about MRs from
ones about issues. It was trivial before when we had Phab vs Trac. But now
I can't find a way to make them go into different direvtories. It turns
out, Gmail filters, for one, can't target individual symbols. like ! vs #
(there is even an SE question about exactly telling apart Gitlab's emails
https://webapps.stackexchange.com/q/52828/70750).

I also used to be subscribed for notifications about Trac Wiki. Is it
possible to have those from the Gitlab Wiki? I understand wiki is mirrored
from https://gitlab.haskell.org/ghc/ghc-wiki-mirror but if you start
watching it, it won't notify about regular commits to master, only about
MRs/issues, but no one opens those on that repo.

--
Kind regards,
Artem


On Tue, Jul 23, 2019, 7:04 AM Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> A big +1 from me.  The "GHC" part is already uninformative, but adding
> "Glasgow Haskell Compiler" consumes _all_ the pixels on my laptop's
> message-list display, leaving no clue whatsoever about which ticket this is.
>
> Thanks
>
> Simon
>
> |  -Original Message-
> |  From: ghc-devs  On Behalf Of Richard
> |  Eisenberg
> |  Sent: 22 July 2019 18:29
> |  To: Ben Gamari 
> |  Cc: Simon Peyton Jones via ghc-devs 
> |  Subject: gitlab subject lines
> |
> |  Hi Ben,
> |
> |  Since the recent GitLab upgrade, all GitLab emails have "GHC | Glasgow
> |  Haskell Compiler | " prefixed to their subject lines. This reduces the
> |  bandwidth of information in my mail reader. Is there a way of going back
> |  to just "GHC |"?
> |
> |  Thanks! :)
> |  Richard
> |  ___
> |  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

Re: Guarded Impredicativity

[Artem Pelenitsyn]

Hello Ryan,

Your example seems to work out of the box with the GI branch.

With the oneliner Matthew posted before:
nix run -f
https://github.com/mpickering/ghc-artefact-nix/archive//master.tar.gz \
ghc-head-from -c ghc-head-from \
https://gitlab.haskell.org/mpickering/ghc/-/jobs/114593/artifacts/raw/ghc-x86_64-fedora27-linux.tar.xz
It is really easy to check. Also, I didn't see anywhere mentioned that one
need to provide -XImpredicativeTypes. The whole example, therefore, is:

{-#LANGUAGE ImpredicativeTypes, ConstraintKinds #-}



module M where
type F f = (Functor f, forall a. Eq (f a))

--
Best, Artem

On Fri, 19 Jul 2019 at 09:18, Ryan Scott  wrote:

> I have another interesting application of guarded impredicativity that
> I want to bring up. Currently, GHC #16140 [1] makes it rather
> inconvenient to use quantified constraints in type synonyms. For
> instance, GHC rejects the following example by default:
>
> type F f = (Functor f, forall a. Eq (f a))
>
> This is because F is a synonym for a constraint tuple, so mentioning a
> quantified constraint in one of its arguments gets flagged as
> impredicative. In the discussion for #16140, we have pondered doing a
> major rewrite of the code in TcValidity to permit F. But perhaps we
> don't need to! After all, the quantified constraint in the example
> above appears directly underneath a type constructor (namely, the type
> constructor for the constraint 2-tuple), which should be a textbook
> case of guarded impredicativity.
>
> I don't have the guarded impredicativity branch built locally, so I am
> unable to test if this hypothesis is true. In any case, I wanted to
> mention it as another motivating use case.
>
> Ryan S.
> -
> [1] https://gitlab.haskell.org/ghc/ghc/issues/16140
> ___
> 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: Cloning (Shayne Fletcher)

[Artem Pelenitsyn]

Hello Jost,

Thanks for researching this! In fact, Arnaud did his own research on this
topic and submitted !1309 [1] to switch to the absolute paths. The MR has
been approved by Ben swiftly and now awaits merging.

I believe we should default to the common case, which is to use abs paths
making the life of, presumably, many people easier, and let those who
understand submodules hack their way through them.

[1]: https://gitlab.haskell.org/ghc/ghc/merge_requests/1309

--
Best wishes,
Artem


On Mon, 1 Jul 2019 at 12:17, Jost Berthold  wrote:

> Just on this detail in the previous mails:
>
> On 6/25/19 10:00 PM, ghc-devs-requ...@haskell.org wrote:
> >> More generally, I'm actually wondering, why GHC's .gitsubmodules use
> > relative paths.  Why not make them absolute?
> >
> > I continue to wonder about that and if switching to absolute paths might
> > remove this wrinkle. Can anyone chime in?
>
> I remember the relative paths for submodules were added to make working
> with several clones of the GHC repo (to lower rebuild cost for
> simultaneous branches or similar) easier.
>
> With relative paths, one can make a second local clone from the first
> one and all references to all submodules will share local data.
>
> That said, this does get in the way sometimes. I changed back to
> absolute paths in my GHC fork quite a while back.
>
>
> / Jost
>
> ___
> 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: Cloning

[Artem Pelenitsyn]

Actually, I forgot to pull:

git remote add tdammers g...@gitlab.haskell.org:tdammers/ghc.git
> git pull tdammers
git checkout tdammers some-branch

And to post changes to, say, GHC's main repo:

git push origin some-branch

-- Artem

On Tue, 25 Jun 2019 at 12:04, Artem Pelenitsyn 
wrote:

> Dear Simon,
>
> In order for submodules to work, you still have to jump through the main
> repo. That is,
>
> git clone --recursive https://gitlab.haskell.org/ghc/ghc tdammers
> cd tdammers
> git remote add tdammers g...@gitlab.haskell.org:tdammers/ghc.git
> git checkout tdammers some-branch
>
> Dear ghc-devs,
> More generally, I'm actually wondering, why GHC's .gitsubmodules use
> relative paths.  Why not make them absolute?
>
> --
> Best wishes,
> Artem
>
> On Tue, 25 Jun 2019 at 11:52, Simon Peyton Jones via ghc-devs <
> ghc-devs@haskell.org> wrote:
>
>> What is the right procedure for cloning from someone else’s repo.
>>
>> For example, I wanted to see what was going wrong for Tobias in #16615,
>> so after some detective work I tried
>>
>> git clone --recursive g...@gitlab.haskell.org:tdammers/ghc.git tdammers
>>
>> but I got lots of errors:
>>
>> Cloning into '/home/simonpj/code/tdammers/libffi-tarballs'...
>>
>> setsockopt IPV6_TCLASS 8: Operation not permitted:
>>
>> > GitLab: The project you were looking for could not be found.
>>
>> fatal: Could not read from remote repository.
>>
>>
>>
>> Please make sure you have the correct access rights
>>
>> and the repository exists.
>>
>> fatal: clone of 'g...@gitlab.haskell.org:tdammers/libffi-tarballs.git'
>> into submodule path '/home/simonpj/code/tdammers/libffi-tarballs' failed
>>
>> Failed to clone 'libffi-tarballs'. Retry scheduled
>>
>> Cloning into '/home/simonpj/code/tdammers/libraries/Cabal'...
>>
>> setsockopt IPV6_TCLASS 8: Operation not permitted:
>>
>> > GitLab: The project you were looking for could not be found.
>>
>> fatal: Could not read from remote repository.
>>
>>
>>
>> Please make sure you have the correct access rights
>>
>> and the repository exists.
>>
>> fatal: clone of 'g...@gitlab.haskell.org:tdammers/packages/Cabal.git'
>> into submodule path
>>
>> etc etc.
>>
>> So:
>>
>>- What is a reliable way to get a MR onto my machine to test?
>>- If I make a fix, what is the workflow to push that fix back to the
>>author -- presumably I can’t push to their repo?
>>
>> Thanks
>>
>> 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

Re: Cloning

[Artem Pelenitsyn]

Dear Simon,

In order for submodules to work, you still have to jump through the main
repo. That is,

git clone --recursive https://gitlab.haskell.org/ghc/ghc tdammers
cd tdammers
git remote add tdammers g...@gitlab.haskell.org:tdammers/ghc.git
git checkout tdammers some-branch

Dear ghc-devs,
More generally, I'm actually wondering, why GHC's .gitsubmodules use
relative paths.  Why not make them absolute?

--
Best wishes,
Artem

On Tue, 25 Jun 2019 at 11:52, Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> What is the right procedure for cloning from someone else’s repo.
>
> For example, I wanted to see what was going wrong for Tobias in #16615, so
> after some detective work I tried
>
> git clone --recursive g...@gitlab.haskell.org:tdammers/ghc.git tdammers
>
> but I got lots of errors:
>
> Cloning into '/home/simonpj/code/tdammers/libffi-tarballs'...
>
> setsockopt IPV6_TCLASS 8: Operation not permitted:
>
> > GitLab: The project you were looking for could not be found.
>
> fatal: Could not read from remote repository.
>
>
>
> Please make sure you have the correct access rights
>
> and the repository exists.
>
> fatal: clone of 'g...@gitlab.haskell.org:tdammers/libffi-tarballs.git'
> into submodule path '/home/simonpj/code/tdammers/libffi-tarballs' failed
>
> Failed to clone 'libffi-tarballs'. Retry scheduled
>
> Cloning into '/home/simonpj/code/tdammers/libraries/Cabal'...
>
> setsockopt IPV6_TCLASS 8: Operation not permitted:
>
> > GitLab: The project you were looking for could not be found.
>
> fatal: Could not read from remote repository.
>
>
>
> Please make sure you have the correct access rights
>
> and the repository exists.
>
> fatal: clone of 'g...@gitlab.haskell.org:tdammers/packages/Cabal.git' into
> submodule path
>
> etc etc.
>
> So:
>
>- What is a reliable way to get a MR onto my machine to test?
>- If I make a fix, what is the workflow to push that fix back to the
>author -- presumably I can’t push to their repo?
>
> Thanks
>
> 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

Re: Container type classes

[Artem Pelenitsyn]

Hi Andrey,

FWIW, mono-traversable (http://hackage.haskell.org/package/mono-traversable)
suggests decoupling IsSet and Funtor-like.

In a nutshell, they define the IsSet class (in Data.Containers) with
typical set operations like member and singleton, union and intersection.
And then they tackle a (seemingly) independent problem of mapping
monomorphic containers (like IntSet, ByteString, etc.) with a separate
class MonoFunctor (in Data.MonoTraversable):

class MonoFunctor mono where
omap :: (Element mono -> Element mono) -> mono -> mono

And gazillion of instances for both polymorphic containers with a fixed
type parameter and monomorphic ones.

--
Best wishes,
Artem

On Thu, 30 May 2019 at 20:11, Andrey Mokhov 
wrote:

> Hi all,
>
> I tried to use type classes for unifying APIs of several similar data
> structures and it didn't work well. (In my case I was working with graphs,
> instead of sets or maps.)
>
> First, you rarely want to be polymorphic over the set representation,
> because you care about performance. You really want to use that
> Very.Special.Set.insert because it has the right performance
> characteristics for your task at hand. I found only *one* use-case for
> writing polymorphic functions operating on something like IsSet: the
> testsuite. Of course, it is very nice to write a single property test like
>
> memberInsertProperty x set = (member x (insert x set) == True)
>
> and then use it for testing all set data structures that implement
> `member` and `insert`. Here you don't care about performance, only about
> correctness!
>
> However, this approach leads to problems with type inference, confusing
> error messages, and complexity. I found that it is much nicer to use
> explicit dictionary passing and write something like this instead:
>
> memberInsertProperty SetAPI{..} x set = (member x (insert x set) == True)
>
> where `member` and `insert` come from the SetAPI record via
> RecordWildCards.
>
> Finally, I'm not even sure how to create a type class covering Set and
> IntSet with the following two methods:
>
> singleton :: a -> Set a
> map :: Ord b => (a -> b) -> Set a -> Set b
>
> singleton :: Int -> IntSet
> map :: (Int -> Int) -> IntSet -> IntSet
>
> Could anyone please enlighten me about the right way to abstract over this
> using type classes?
>
> I tried a few approaches, for example:
>
> class IsSet s where
> type Elem s
> singleton :: Elem s -> s
> map :: Ord (Elem t) => (Elem s -> Elem t) -> s -> t
>
> Looks nice, but I can't define the IntSet instance:
>
> instance IsSet IntSet where
> type Elem IntSet = Int
> singleton = IntSet.singleton
> map = IntSet.map
>
> This fails with: Couldn't match type `t' with `IntSet' -- and indeed, how
> do I tell the compiler that in the IntSet case s ~ t in the map signature?
> Shall I add more associated types, or "associated constraints" using
> ConstraintKinds? I tried and failed, at various stages, repeatedly.
>
> ...And then you discover that there is Set.cartesianProduct :: Set a ->
> Set b -> Set (a, b), but no equivalent in IntSet and things get even more
> grim.
>
> Cheers,
> Andrey
>
> ___
> 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: Commit searching

[Artem Pelenitsyn]

Hi chessai,

What I usually do for this is open up the corresponding GitHub page, e.g.:

https://github.com/ghc/ghc/commit/bb3fa2d18686d0c08b57c66a90a9ea1b4e4482ee

where I see the list of branches the commit was added to, below the commit
message (note that you have to click "..." to see the full list of
branches). The branches ending with `-release` (e.g. ghc-8.6.5-release)
answer your question, I believe.

--
Best, Artem


On Sat, 11 May 2019 at 23:01, chessai .  wrote:

> Devs,
>
> Is there a way to take the sha1 of a git commit and find which
> released version of GHC contains that commit, without resorting to a
> manual cross-reference?
>
> Is it possible there could be some sort of webpage where this
> information could be made accessible, just by pasting in a commit?
> ___
> 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: Question about Gitlab MR workflow.

[Artem Pelenitsyn]

I fixed the numbering and added some spaces here and there.

-- Best, Artem

On Thu, 9 May 2019 at 18:50, Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> Thanks. That page is one click from the "Working conventions" page which
> is listed in the sidebar.  (I wonder if "Working conventions" is the right
> title?)
>
> The numbering of the "Contributing a patch" page is deeply strange.
> 1,2,1,1,1,2,3,4.
>
>
>
> |  -Original Message-
> |  From: ghc-devs  On Behalf Of David
> Eichmann
> |  Sent: 09 May 2019 16:47
> |  To: Ben Gamari ; ghc-devs@haskell.org
> |  Subject: Re: Question about Gitlab MR workflow.
> |
> |
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h
> |  askell.org%2Fghc%2Fghc%2Fwikis%2Fworking-conventions%2Ffixing-
> |  bugs&data=01%7C01%7Csimonpj%40microsoft.com
> %7C7615e39c98f84ae42e3008d6
> |
> d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=NYp8yLUc52uZZWRY
> |  cMISbebwx5frQBxXCSCHMbElm6s%3D&reserved=0
> |
> |  On 5/9/19 3:47 PM, Ben Gamari wrote:
> |  > David Eichmann  writes:
> |  >
> |  >> I've added a blurb in the wiki page about rebasing MRs:
> |  >>
> |  > Which Wiki page specifically?
> |  >
> |  > - Ben
> |
> |  --
> |  David Eichmann, Haskell Consultant
> |  Well-Typed LLP,
> |
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.well-
> |  typed.com&data=01%7C01%7Csimonpj%40microsoft.com
> %7C7615e39c98f84ae42e3
> |
> 008d6d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=aYW0kB6YAKF
> |  A6g2acauodtQ%2BIHnR5UuZuNQ7AW%2FNRvE%3D&reserved=0
> |
> |  Registered in England & Wales, OC335890
> |  118 Wymering Mansions, Wymering Road, London W9 2NF, England
> |
> |  ___
> |  ghc-devs mailing list
> |  ghc-devs@haskell.org
> |
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
> |  ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
> |  devs&data=01%7C01%7Csimonpj%40microsoft.com
> %7C7615e39c98f84ae42e3008d6
> |
> d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=37tW3oFiBnCz93Hp
> |  %2BblddDl35Ac83YpVNDJyk%2Fw9Rtg%3D&reserved=0
> ___
> 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: Cabal woes

[Artem Pelenitsyn]

Hi,

Just wanted to note that the initial Simon's post also mentioned the
outdated pages on haskell.org. It'd be good not to forget to purge them,
maybe inserting links to cabal.readthedocs.

--
Best, Artem

On Tue, 16 Apr 2019 at 07:27 Mikhail Glushenkov <
mikhail.glushen...@gmail.com> wrote:

> Hi,
>
> On Mon, 15 Apr 2019 at 23:56, Simon Peyton Jones via ghc-devs
>  wrote:
> >
> > That’s a tremendously helpful summary, thank you Iavor.  And Michail’s
> summary was also very helpful.
> >
> >
> >
> > Most of this is doubtless well-known to habitual cabal users, but it
> might be useful to explain the user model, in a way that covers these
> points, somewhere close to the Cabal home page.
>
> If anyone reading this is interested in helping out with website and
> documentation, we'll gladly accept PRs.
>
> Documentation for Cabal lives at
> https://github.com/haskell/cabal/tree/master/Cabal/doc and the website
> sources are at https://github.com/haskell/cabal-website/ (see also the
> feature/next branch).
> ___
> 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

[Artem Pelenitsyn]

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: Trac to GitLab migration underway

[Artem Pelenitsyn]

Hi Richard,

Good catch! What troubles me in that issue, is (subjectively) the
passive-aggressive form of the initial post. Given that it is email that we
are worrying about, not the browser tabs, maybe it is better to start over
with a new issue referencing that one in passing.

--
Best, Artem

On Mon, 11 Mar 2019 at 11:56 Richard Eisenberg  wrote:

> This old ticket might be related:
> https://gitlab.com/gitlab-org/gitlab-ce/issues/1734   It advocates for
> moving numbers to the front of tab names, too. Looks like it was shut down
> by judgment call. Perhaps if we raise our voices in chorus against this
> decision, we can get some action (or a new configuration switch).
>
> On Mar 11, 2019, at 10:25 AM, Artem Pelenitsyn 
> wrote:
>
> Hello,
>
> I just wanted to thank Ben and everyone involved for this transition. And
> also reiterate Richard's point about having !123 / #12345 in the front of
> mail subjects — I think, this is small but quite important detail to ease
> navigating the flow of notifications.
>
> --
> Best regards,
> Artem
>
> On Mon, Mar 11, 2019, 9:13 AM Richard Eisenberg 
> wrote:
>
>> Thanks to all who have made this happen. Looking forward to having
>> everything in one place!
>>
>> Do we have any ability to edit the formatting of subject lines of ticket
>> emails? It would be great if we could get the (!234) or (#12345) up front,
>> as this is the effective summary of what's to follow.
>>
>> I'd also like to second Simon's request, in particular, of having a clear
>> path from an issue to an MR. Getting from an MR to an issue is normally
>> easier -- when the MR is created, most devs would automatically mention the
>> issue number somewhere in the description -- but going from an issue to an
>> MR is harder. It would be a shame to have to search through the commentary
>> looking for the link. I used the old "Phab:D1234" links in the top of a
>> Trac ticket quite often.
>>
>> I also second the request for a test-case field. This field, to me, is
>> most useful as a reminder to the author that they need to add a test case.
>> But I think the issue-to-MR link is more important than the test-case field.
>>
>> Thanks!
>> Richard
>>
>> > On Mar 11, 2019, at 6:17 AM, Matthew Pickering <
>> matthewtpicker...@gmail.com> wrote:
>> >
>> > I wrote !509 in the ticket which then made gitlab display the "Related
>> > Merge Request" bit underneath. I don't know what happens if you
>> > mention a MR in a comment.
>> >
>> > On Mon, Mar 11, 2019 at 10:14 AM Simon Peyton Jones
>> >  wrote:
>> >>
>> >> |  > * Back on the tickets front, how do I record the test cases(s)
>> for a
>> >> |  ticket?
>> >> |
>> >> |  I don't believe there is a way other than via the commit
>> referencing the
>> >> |  ticket.
>> >>
>> >> That's sad. It's a useful discipline to fill in that field before
>> closing the ticket.  And it's useful later when looking for the test cases
>> for the ticket.
>> >>
>> >> Is this just a straight loss, or is there a longer term plan to
>> recover it?  Do we need a self-imposed discipline, e.g. to ALWAYS add a
>> comment that lists the test cases (and does nothing else) before closing an
>> issue?
>> >>
>> >> |  > * How do I record the MR for a ticket?  (When it has one.)
>> >> |
>> >> |  When you mention a ticket in a MR then a reference should be
>> created from
>> >> |  it to the ticket.
>> >> |
>> >> |  For example, when I mentioned !509 on this ticket it now displays
>> in the
>> >> |  UI.
>> >>
>> >> I don't get it.  You manually added "Corresponding MR !509" to the
>> issue Description.  Or are you saying that that apparently-user-written
>> line was added by GitLab? If you have many MRs taht mention (perhaps en
>> passant) the same issue, will there be many such lines?
>> >>
>> >> Or is it another discipline we could impose on ourselves?
>> >>
>> >> Simon
>> >>
>> >> |  -Original Message-
>> >> |  From: Matthew Pickering 
>> >> |  Sent: 11 March 2019 09:37
>> >> |  To: Simon Peyton Jones 
>> >> |  Cc: Ben Gamari ; GHC developers <
>> ghc-devs@haskell.org>
>> >> |  Subject: Re: Trac to GitLab migration underway
>> >> |
>> >> |  > * That

Re: Trac to GitLab migration underway

[Artem Pelenitsyn]

Hello,

I just wanted to thank Ben and everyone involved for this transition. And
also reiterate Richard's point about having !123 / #12345 in the front of
mail subjects — I think, this is small but quite important detail to ease
navigating the flow of notifications.

--
Best regards,
Artem

On Mon, Mar 11, 2019, 9:13 AM Richard Eisenberg  wrote:

> Thanks to all who have made this happen. Looking forward to having
> everything in one place!
>
> Do we have any ability to edit the formatting of subject lines of ticket
> emails? It would be great if we could get the (!234) or (#12345) up front,
> as this is the effective summary of what's to follow.
>
> I'd also like to second Simon's request, in particular, of having a clear
> path from an issue to an MR. Getting from an MR to an issue is normally
> easier -- when the MR is created, most devs would automatically mention the
> issue number somewhere in the description -- but going from an issue to an
> MR is harder. It would be a shame to have to search through the commentary
> looking for the link. I used the old "Phab:D1234" links in the top of a
> Trac ticket quite often.
>
> I also second the request for a test-case field. This field, to me, is
> most useful as a reminder to the author that they need to add a test case.
> But I think the issue-to-MR link is more important than the test-case field.
>
> Thanks!
> Richard
>
> > On Mar 11, 2019, at 6:17 AM, Matthew Pickering <
> matthewtpicker...@gmail.com> wrote:
> >
> > I wrote !509 in the ticket which then made gitlab display the "Related
> > Merge Request" bit underneath. I don't know what happens if you
> > mention a MR in a comment.
> >
> > On Mon, Mar 11, 2019 at 10:14 AM Simon Peyton Jones
> >  wrote:
> >>
> >> |  > * Back on the tickets front, how do I record the test cases(s) for
> a
> >> |  ticket?
> >> |
> >> |  I don't believe there is a way other than via the commit referencing
> the
> >> |  ticket.
> >>
> >> That's sad. It's a useful discipline to fill in that field before
> closing the ticket.  And it's useful later when looking for the test cases
> for the ticket.
> >>
> >> Is this just a straight loss, or is there a longer term plan to recover
> it?  Do we need a self-imposed discipline, e.g. to ALWAYS add a comment
> that lists the test cases (and does nothing else) before closing an issue?
> >>
> >> |  > * How do I record the MR for a ticket?  (When it has one.)
> >> |
> >> |  When you mention a ticket in a MR then a reference should be created
> from
> >> |  it to the ticket.
> >> |
> >> |  For example, when I mentioned !509 on this ticket it now displays in
> the
> >> |  UI.
> >>
> >> I don't get it.  You manually added "Corresponding MR !509" to the
> issue Description.  Or are you saying that that apparently-user-written
> line was added by GitLab? If you have many MRs taht mention (perhaps en
> passant) the same issue, will there be many such lines?
> >>
> >> Or is it another discipline we could impose on ourselves?
> >>
> >> Simon
> >>
> >> |  -Original Message-
> >> |  From: Matthew Pickering 
> >> |  Sent: 11 March 2019 09:37
> >> |  To: Simon Peyton Jones 
> >> |  Cc: Ben Gamari ; GHC developers <
> ghc-devs@haskell.org>
> >> |  Subject: Re: Trac to GitLab migration underway
> >> |
> >> |  > * That the old ticket repo be put in read-only mode.  I've just
> modified
> >> |  the old #16344, but I should have modified the new one.
> >> |
> >> |  That is tracked
> >> |
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h
> >> |  askell.org%2Fbgamari%2Fgitlab-
> >> |  migration%2Fissues%2F14&data=02%7C01%7Csimonpj%40microsoft.com
> %7Cac356
> >> |
> d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
> >> |
> 36878938597242017&sdata=XnY%2Fo62mCkz849XKLKe8V3stFe8sorBQkqI9%2FY%2By
> >> |  CdI%3D&reserved=0
> >> |
> >> |  It seems that there are still some problems to iron out though.
> >> |
> >> |  > * Back on the tickets front, how do I record the test cases(s) for
> a
> >> |  ticket?
> >> |
> >> |  I don't believe there is a way other than via the commit referencing
> the
> >> |  ticket.
> >> |
> >> |  >
> >> |  > * How do I record the MR for a ticket?  (When it has one.)
> >> |
> >> |  When you mention a ticket in a MR then a reference should be created
> from
> >> |  it to the ticket.
> >> |
> >> |  For example, when I mentioned !509 on this ticket it now displays in
> the
> >> |  UI.
> >> |
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h
> >> |  askell.org
> %2Fghc%2Fghc%2Fissues%2F16417&data=02%7C01%7Csimonpj%40micro
> >> |  soft.com
> %7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011
> >> |
> db47%7C1%7C0%7C636878938597242017&sdata=s5%2FfsXsx5t%2FuRIeq6AJZU5sr8P
> >> |  FJpNt6nkr%2BObzRAmk%3D&reserved=0
> >> |
> >> |  >
> >> |  > * That the banner (on the wiki at least) saying "This site has been
> >> |  deprecated and is in read-only mode" should describe how to get to
> the
> >>

GitHub Mirror is broken

[Artem Pelenitsyn]

Hello devs,

This is just to let you know that the latestes commit on GitHub ghc/ghc
repo dates back to 22th of January. Personally, I find GitHub mirror quite
useful for ocasional searches over the code base. Therefore, I'd
appreciated repairing the mirror.

--
Best of luck,
Artem Pelenitsyn
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Status of downloads.haskell.org/~ghc/master/

[Artem Pelenitsyn]

Hello devs,

What is the status of this directory [1]? It doesn't seem to be the tip of
the master branch in the repo. In the documentation [2] it says:

> GHC 8.5.20180424 User's Guide

I'm asking because it has broken links to the base haddocks in it (here [3]
try clicking on any link to the library docs, e.g. GHC.Conc.par), and
Google happily indexes and spits out as results of search queries
everything laying here and there, including these pages. Broken links could
lead “outsiders” to a somewhat underwhelming impression of the state of
infrastructure.

[1]: http://downloads.haskell.org/~ghc/master/
[2]: http://downloads.haskell.org/~ghc/master/users-guide/index.html
[3]:
http://downloads.haskell.org/~ghc/master/users-guide/runtime_control.html#rts-options-gc

--
Best wishes,
Artem
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Gitlab pain

[Artem Pelenitsyn]

It seems you'd want the "Toggle All" button. There is an issue for that:

https://gitlab.com/gitlab-org/gitlab-ce/issues/19149

There is even a beautiful workaround given there with typing the following
command in the JavaScript console in a browser:
$(".discussion-toggle-button:has(i.fa-chevron-down)").click()
After that, indeed, I could Ctrl+F the phrase referenced by Simon ("Another
module should reference the symbol") while before I could not.

--
Best, Artem

On Fri, 4 Jan 2019 at 21:48 Ben Gamari  wrote:

> Quite right. I will bring this up with upstream.
>
> On January 4, 2019 1:04:43 PM EST, Brandon Allbery 
> wrote:
>>
>> On Fri, Jan 4, 2019 at 1:02 PM Ben Gamari  wrote:
>>
>>> As mentioned by others, discussions that have been marked as "resolved"
>>> are collapsed by default. If you search for the text "Toggle discussion"
>>> you will find that the collapsed discussions have link on their
>>> right-hand side which you can click on to expand the hidden comments.
>>>
>>
>> The problem there being there's a lot of such, and no way to tell which
>> one is relevant unless you have both original links and enough context.
>> Finding stuff like that absent context doesn't look at all easy. :/
>>
>> --
>> brandon s allbery kf8nh
>> allber...@gmail.com
>>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> ___
> 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: Current Stable Release = 8.6.2 on haskell.org

[Artem Pelenitsyn]

Also,

https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/index.html

still points to 8.6.2

--
Best, Artem

On Tue, 25 Dec 2018 at 02:05 Artem Pelenitsyn 
wrote:

> Thank you, Ben! Your job is much appreciated!
>
> -- Artem
>
> On Mon, 24 Dec 2018, 17:27 Ben Gamari,  wrote:
>
>> On December 23, 2018 7:19:41 PM EST, Iavor Diatchki <
>> iavor.diatc...@gmail.com> wrote:
>> >Given that 8.6.3 does not work at all on Windows (seems to hang when TH
>> >is
>> >involved), we should probably not make it the current stable release.
>> >See
>> >16071, I also just run into that and had to revert to 8.6.2.
>> >
>> >Iavor
>> >
>> >On Sun, Dec 23, 2018, 4:08 PM Ben Gamari > >
>> >> Artem Pelenitsyn  writes:
>> >>
>> >> > Hello devs,
>> >> >
>> >> > I assume, the version of the current release should be bumped up to
>> >8.6.3
>> >> > here [1]?
>> >> >
>> >> Yes, quite right.
>> >>
>> >> I'll handle this soon.
>> >>
>> >> Cheers,
>> >>
>> >> - Ben
>> >> ___
>> >> ghc-devs mailing list
>> >> ghc-devs@haskell.org
>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >>
>>
>> For the record, the plan here is to revert the regressing patch on
>> ghc-8.6 and cut a small 8.6.4 release. Unfortunately this will mean that
>> profiling will be broken for this release but this is the best we can do at
>> the moment.
>>
>> I've been spent a large fraction of the last several weeks improving our
>> CI story on Windows so future releases should have significantly better
>> coverage on this platform.
>
>
>>
>> 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
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Current Stable Release = 8.6.2 on haskell.org

[Artem Pelenitsyn]

Thank you, Ben! Your job is much appreciated!

-- Artem

On Mon, 24 Dec 2018, 17:27 Ben Gamari,  wrote:

> On December 23, 2018 7:19:41 PM EST, Iavor Diatchki <
> iavor.diatc...@gmail.com> wrote:
> >Given that 8.6.3 does not work at all on Windows (seems to hang when TH
> >is
> >involved), we should probably not make it the current stable release.
> >See
> >16071, I also just run into that and had to revert to 8.6.2.
> >
> >Iavor
> >
> >On Sun, Dec 23, 2018, 4:08 PM Ben Gamari  >
> >> Artem Pelenitsyn  writes:
> >>
> >> > Hello devs,
> >> >
> >> > I assume, the version of the current release should be bumped up to
> >8.6.3
> >> > here [1]?
> >> >
> >> Yes, quite right.
> >>
> >> I'll handle this soon.
> >>
> >> Cheers,
> >>
> >> - Ben
> >> ___
> >> ghc-devs mailing list
> >> ghc-devs@haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >>
>
> For the record, the plan here is to revert the regressing patch on ghc-8.6
> and cut a small 8.6.4 release. Unfortunately this will mean that profiling
> will be broken for this release but this is the best we can do at the
> moment.
>
> I've been spent a large fraction of the last several weeks improving our
> CI story on Windows so future releases should have significantly better
> coverage on this platform.
>
> 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

Current Stable Release = 8.6.2 on haskell.org

[Artem Pelenitsyn]

Hello devs,

I assume, the version of the current release should be bumped up to 8.6.3
here [1]?

[1]: https://www.haskell.org/ghc/download.html

--
Best wishes,
Artem
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: References for GHC usage of multiple capabilities

[Artem Pelenitsyn]

Thank you all for the feedback again! I managed to make use of only basic
papers in time. The result is here:

github repo: https://github.com/ulysses4ever/CS7600-Survey-Paper
current PDF:
https://github.com/ulysses4ever/CS7600-Survey-Paper/releases/download/v1.0.0/CS7600__Survey_Paper.pdf

--
Best, Artem


On Fri, 7 Dec 2018 at 13:23 Artem Pelenitsyn  wrote:

> Thanks, Tom! I didn't realize that this one was merged into GHC. I wonder
> if the work presented on Haskell Symposium this year about a libuv-based
> I/O manager (https://dl.acm.org/citation.cfm?id=3242759) will go
> somewhere…
>
> --
> Best, Artem
>
> On Fri, 7 Dec 2018 at 12:00 Tom Murphy  wrote:
>
>> There's also "Mio: A High-Performance Multicore IO Manager for GHC"
>>
>> http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask035-voellmy.pdf
>>
>> On 12/7/18, Artem Pelenitsyn  wrote:
>> > Thanks for heads up, Ben! This is useful stuff to take into account. I
>> also
>> > wonder how is this list (mine ++ yours) is relevant to what GHC actually
>> > has these days. But maybe that's harder to answer quickly.
>> >
>> > --
>> > Best wishes,
>> > Artem
>> >
>> >
>> >
>> >
>> > On Thu, Dec 6, 2018 at 10:47 AM Ben Gamari 
>> wrote:
>> >
>> >> Artem Pelenitsyn  writes:
>> >>
>> >> > Hello devs,
>> >> >
>> >> > I've been working on a short survey devoted to a topic of
>> >> > multithreading
>> >> > inside the GHC compiler and runtime. So far I was mostly looking at
>> the
>> >> > following three papers
>> >> >
>> >> > [1] P. W. Trinder, K. Hammond, J. S. Mattson, Jr., A. S. Partridge,
>> and
>> >> S.
>> >> > L. Peyton Jones. Gum: A portable parallel implementation of Haskell.
>> >> PLDI
>> >> > ’96
>> >> >
>> >> > [2] Tim Harris, Simon Marlow, and Simon Peyton Jones. Haskell on a
>> >> > shared-memory multiprocessor. Haskell ’05
>> >> >
>> >> > [3] Simon Marlow, Simon Peyton Jones, and Satnam Singh. Runtime
>> support
>> >> for
>> >> > multicore Haskell. ICFP ’09
>> >> >
>> >> > Can you suggest any other papers adding insights on how GHC uses
>> >> > multiple
>> >> > capabilities for anything from GC to the implementation of
>> >> > Parallel/Concurrent Haskell? Perhaps, something more recent than the
>> >> above,
>> >> > but preferably published in academic venues.
>> >> >
>> >> Here are a few others but I may have missed a few:
>> >>
>> >>  * Parallel Generational-Copying Garbage Collection with a
>> >> Block-Structured Heap (Simon Marlow, Tim Harris, Roshan P. James, Simon
>> >> Peyton Jones) In ISMM '08: Proceedings of the 7th international
>> symposium
>> >> on Memory management, Tucson, Arizona, ACM, June 2008
>> >>  * Concurrent Haskell, Simon Peyton Jones, Andrew Gordon, Sigbjorn
>> Finne.
>> >>  * Composable Memory Transactions, Tim Harris, Simon Marlow, Simon
>> >> Peyton-Jones, and Maurice Herlihy. In Proceedings of the tenth ACM
>> >> SIGPLAN
>> >> symposium on Principles and practice of parallel programming (PPoPP
>> '05)
>> >>  * Transactional Memory with Data Invariants, Tim Harris and Simon
>> Peyton
>> >> Jones. In TRANSACT '06
>> >>
>> >> 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
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: References for GHC usage of multiple capabilities

[Artem Pelenitsyn]

Thanks, Tom! I didn't realize that this one was merged into GHC. I wonder
if the work presented on Haskell Symposium this year about a libuv-based
I/O manager (https://dl.acm.org/citation.cfm?id=3242759) will go somewhere…

--
Best, Artem

On Fri, 7 Dec 2018 at 12:00 Tom Murphy  wrote:

> There's also "Mio: A High-Performance Multicore IO Manager for GHC"
>
> http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask035-voellmy.pdf
>
> On 12/7/18, Artem Pelenitsyn  wrote:
> > Thanks for heads up, Ben! This is useful stuff to take into account. I
> also
> > wonder how is this list (mine ++ yours) is relevant to what GHC actually
> > has these days. But maybe that's harder to answer quickly.
> >
> > --
> > Best wishes,
> > Artem
> >
> >
> >
> >
> > On Thu, Dec 6, 2018 at 10:47 AM Ben Gamari  wrote:
> >
> >> Artem Pelenitsyn  writes:
> >>
> >> > Hello devs,
> >> >
> >> > I've been working on a short survey devoted to a topic of
> >> > multithreading
> >> > inside the GHC compiler and runtime. So far I was mostly looking at
> the
> >> > following three papers
> >> >
> >> > [1] P. W. Trinder, K. Hammond, J. S. Mattson, Jr., A. S. Partridge,
> and
> >> S.
> >> > L. Peyton Jones. Gum: A portable parallel implementation of Haskell.
> >> PLDI
> >> > ’96
> >> >
> >> > [2] Tim Harris, Simon Marlow, and Simon Peyton Jones. Haskell on a
> >> > shared-memory multiprocessor. Haskell ’05
> >> >
> >> > [3] Simon Marlow, Simon Peyton Jones, and Satnam Singh. Runtime
> support
> >> for
> >> > multicore Haskell. ICFP ’09
> >> >
> >> > Can you suggest any other papers adding insights on how GHC uses
> >> > multiple
> >> > capabilities for anything from GC to the implementation of
> >> > Parallel/Concurrent Haskell? Perhaps, something more recent than the
> >> above,
> >> > but preferably published in academic venues.
> >> >
> >> Here are a few others but I may have missed a few:
> >>
> >>  * Parallel Generational-Copying Garbage Collection with a
> >> Block-Structured Heap (Simon Marlow, Tim Harris, Roshan P. James, Simon
> >> Peyton Jones) In ISMM '08: Proceedings of the 7th international
> symposium
> >> on Memory management, Tucson, Arizona, ACM, June 2008
> >>  * Concurrent Haskell, Simon Peyton Jones, Andrew Gordon, Sigbjorn
> Finne.
> >>  * Composable Memory Transactions, Tim Harris, Simon Marlow, Simon
> >> Peyton-Jones, and Maurice Herlihy. In Proceedings of the tenth ACM
> >> SIGPLAN
> >> symposium on Principles and practice of parallel programming (PPoPP '05)
> >>  * Transactional Memory with Data Invariants, Tim Harris and Simon
> Peyton
> >> Jones. In TRANSACT '06
> >>
> >> 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
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: References for GHC usage of multiple capabilities

[Artem Pelenitsyn]

Thanks for heads up, Ben! This is useful stuff to take into account. I also
wonder how is this list (mine ++ yours) is relevant to what GHC actually
has these days. But maybe that's harder to answer quickly.

--
Best wishes,
Artem




On Thu, Dec 6, 2018 at 10:47 AM Ben Gamari  wrote:

> Artem Pelenitsyn  writes:
>
> > Hello devs,
> >
> > I've been working on a short survey devoted to a topic of multithreading
> > inside the GHC compiler and runtime. So far I was mostly looking at the
> > following three papers
> >
> > [1] P. W. Trinder, K. Hammond, J. S. Mattson, Jr., A. S. Partridge, and
> S.
> > L. Peyton Jones. Gum: A portable parallel implementation of Haskell.
> PLDI
> > ’96
> >
> > [2] Tim Harris, Simon Marlow, and Simon Peyton Jones. Haskell on a
> > shared-memory multiprocessor. Haskell ’05
> >
> > [3] Simon Marlow, Simon Peyton Jones, and Satnam Singh. Runtime support
> for
> > multicore Haskell. ICFP ’09
> >
> > Can you suggest any other papers adding insights on how GHC uses multiple
> > capabilities for anything from GC to the implementation of
> > Parallel/Concurrent Haskell? Perhaps, something more recent than the
> above,
> > but preferably published in academic venues.
> >
> Here are a few others but I may have missed a few:
>
>  * Parallel Generational-Copying Garbage Collection with a
> Block-Structured Heap (Simon Marlow, Tim Harris, Roshan P. James, Simon
> Peyton Jones) In ISMM '08: Proceedings of the 7th international symposium
> on Memory management, Tucson, Arizona, ACM, June 2008
>  * Concurrent Haskell, Simon Peyton Jones, Andrew Gordon, Sigbjorn Finne.
>  * Composable Memory Transactions, Tim Harris, Simon Marlow, Simon
> Peyton-Jones, and Maurice Herlihy. In Proceedings of the tenth ACM SIGPLAN
> symposium on Principles and practice of parallel programming (PPoPP '05)
>  * Transactional Memory with Data Invariants, Tim Harris and Simon Peyton
> Jones. In TRANSACT '06
>
> 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

References for GHC usage of multiple capabilities

[Artem Pelenitsyn]

Hello devs,

I've been working on a short survey devoted to a topic of multithreading
inside the GHC compiler and runtime. So far I was mostly looking at the
following three papers

[1] P. W. Trinder, K. Hammond, J. S. Mattson, Jr., A. S. Partridge, and S.
L. Peyton Jones. Gum: A portable parallel implementation of Haskell.  PLDI
’96

[2] Tim Harris, Simon Marlow, and Simon Peyton Jones. Haskell on a
shared-memory multiprocessor. Haskell ’05

[3] Simon Marlow, Simon Peyton Jones, and Satnam Singh. Runtime support for
multicore Haskell. ICFP ’09

Can you suggest any other papers adding insights on how GHC uses multiple
capabilities for anything from GC to the implementation of
Parallel/Concurrent Haskell? Perhaps, something more recent than the above,
but preferably published in academic venues.

The survey is meant to be of interest for systems folks. Therefore, I'm not
paying so much attention to the programming model and how it is used in
programs.

--
Best wishes,
Artem
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC's Fall 2018 HCAR submission

[Artem Pelenitsyn]

Ben,

I assume, writing a Pandoc writer for TracWiki shouldn't be that hard.
Would that be of any help?

--
Best, Artem

On Mon, 29 Oct 2018 at 16:39 Ben Gamari  wrote:

> Artem Pelenitsyn  writes:
>
> > Hi Ben,
> >
> > I see. Have you considered using online converting tools like
> > try-pandoc[1]? Is it still painful?
> >
> I do use Pandoc to convert from Markdown to Latex. However, Pandoc does
> not support Trac's wiki syntax.
>
> Cheers,
>
> - Ben
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC's Fall 2018 HCAR submission

[Artem Pelenitsyn]

Hi Ben,

I see. Have you considered using online converting tools like
try-pandoc[1]? Is it still painful?

[1]: https://pandoc.org/try/

On Mon, 29 Oct 2018 at 15:32 Ben Gamari  wrote:

> Artem Pelenitsyn  writes:
>
> > On Mon, 29 Oct 2018 at 14:25 Evan Laforge  wrote:
> >
> >> Also, when I copy paste the links in the "At the time of writing"
> >> section, the backslashes in the search query mess it up.  Maybe a
> >> markdown rendering step would remove those?
> >>
> >
> > I'm not sure It makes much sense to use {{{...}}} to format the document
> in
> > the first place. Maybe use normal wiki-text? I can decorate links if this
> > is approved.
> >
> This is what I have done in the past. However, it is unfortunately quite
> labor intensive since I need to convert the document to Wiki markup,
> then back to TeX for submission.
>
> Instead with this iteration I have decided to try just writing the thing
> in Markdown and convert to TeX at the end. I was hoping to install a
> Trac processor for Markdown rendering but sadly Trac put up resistance.
>
> Cheers,
>
> - Ben
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC's Fall 2018 HCAR submission

[Artem Pelenitsyn]

On Mon, 29 Oct 2018 at 14:25 Evan Laforge  wrote:

> Also, when I copy paste the links in the "At the time of writing"
> section, the backslashes in the search query mess it up.  Maybe a
> markdown rendering step would remove those?
>

I'm not sure It makes much sense to use {{{...}}} to format the document in
the first place. Maybe use normal wiki-text? I can decorate links if this
is approved.

--
Best, Artem


> On Sun, Oct 28, 2018 at 6:24 PM Ben Gamari  wrote:
> >
> > Hello everyone,
> >
> > The Haskell Community Activities Report is coming up and I have prepared
> > the skeleton for GHC's contribution [1]. If you have a project cooking
> > or have recently had a patch land do have a look to make sure it's
> > recognized in the submission.
> >
> > Cheers,
> >
> > - Ben
> >
> >
> > https://ghc.haskell.org/trac/ghc/wiki/Status/Oct18
> > ___
> > 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

Re: [Haskell] Treatment of unknown pragmas

[Artem Pelenitsyn]

Hello Daniel,

Annotations API was discussed earlier in this thread. Main points against
are:

Neil:
Significant compilation performance penalty and extra recompilation. ANN
pragmas is what HLint currently uses.

Brandon:
The problem with ANN is it's part of the plugins API, and as such does
things like compiling the expression into the program in case a plugin
generates code using its value, plus things like recompilation checking end
up assuming plugins are in use and doing extra checking. Using it as a
compile-time pragma is actually fairly weird from that standpoint.

--
Best, Artem
On Sat, 27 Oct 2018 at 22:12 Daniel Wagner  wrote:

> I don't have a really strong opinion, but... isn't this (attaching
> string-y data to source constructs) pretty much exactly what GHC's
> annotation pragma is for?
> ~d
>
> On Tue, Oct 16, 2018 at 3:14 PM Ben Gamari  wrote:
>
>> Vladislav Zavialov  writes:
>>
>> > What about introducing -fno-warn-pragma=XXX? People who use HLint will
>> > add -fno-warn-pragma=HLINT to their build configuration.
>> >
>> A warning flag is an interesting way to deal with the issue. On the
>> other hand, it's not great from an ergonomic perspective; afterall, this
>> would mean that all users of HLint (and any other tool requiring special
>> pragmas) include this flag in their build configuration. A typical
>> Haskell project already needs too much such boilerplate, in my opinion.
>>
>> I think it makes a lot of sense to have a standard way for third-parties
>> to attach string-y information to Haskell source constructs. While it's
>> not strictly speaking necessary to standardize the syntax, doing
>> so minimizes the chance that tools overlap and hopefully reduces
>> the language ecosystem learning curve.
>>
>> Cheers,
>>
>> - Ben
>> ___
>>
> Haskell mailing list
>> hask...@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>>
> ___
> Haskell mailing list
> hask...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.4.4 released

[Artem Pelenitsyn]

David, when you say "dataToTag# issue", you mean #15696? It seems from the
discussion there that it is still under investigation.

--
Best, Artem

On Fri, 26 Oct 2018 at 17:02 David Feuer  wrote:

> On Fri, Oct 26, 2018 at 4:43 PM Carter Schonwald
>  wrote:
> >
> > Hey David, i'm looking at the git history andit doesn't seem to have any
> commits between 8.4.3 and 8.4.4 related to the dataToTag issue
> >
> > does any haskell code in the while trigger the bug on 8.4 series?
>
> I don't think anyone knows. It seems clear that it's considerably
> easier to trigger the bug in 8.6, but
> as far as I can tell, there's no reason to believe that it couldn't be
> triggered by realistic code in
> 8.4.
> ___
> 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: typed holes inferring very polymorphic types

[Artem Pelenitsyn]

Hello Sreenidhi,

This looks like a valid Trac ticket to me. Maybe, open one?

--
Best, Artem

On Mon, 1 Oct 2018 at 13:25 Sreenidhi Nair  wrote:

> Hello,
>
> We tried the following code with ghc-8.6.1
>
> testFailure :: Char
> testFailure =
>   let x = Prelude.id _
>   in  x
>
> which gave the following suggestion
>
> /home/sreenidhi/Work/typeql/typeql-dbrecord/test/Test/Database/Postgres/Read/Combinator.hs:83:22:
> error:
> • Found hole: _ :: a
>   Where: ‘a’ is a rigid type variable bound by
>the inferred type of x :: a
>at
> /home/sreenidhi/Work/typeql/typeql-dbrecord/test/Test/Database/Postgres/Read/Combinator.hs:83:7-22
>
> And then this
>
> testSuccess :: Char
> testSuccess = _
>
> which gave a much better suggestion
>
> /home/sreenidhi/Work/typeql/typeql-dbrecord/test/Test/Database/Postgres/Read/Combinator.hs:87:15:
> error:
> • Found hole: _ :: Char
> • In the expression: _
>   In an equation for ‘testSuccess’: testSuccess = _
>
> Is there any way to get better suggestions with 'let' version?
>
>
>
> ___
> 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: Hadrian

[Artem Pelenitsyn]

Hello Simon, Andrey,

For “How to use Hadrian wikipage”, maybe Simon wanted this one from the GHC
Wiki:

https://ghc.haskell.org/trac/ghc/wiki/Building/Hadrian/QuickStart

It does mention the verbose flag, but does not really explain that you can
get what Simon wants, I believe.

--
Best wishes,
Artem
чт, 30 авг. 2018 г. в 7:25, Andrey Mokhov :

> Simon,
>
> If you want to see all command lines, you can pass '--verbose' or '-V'
> flag to Hadrian and it will then print out everything it does.
>
> But you can also choose which particular command lines to print in
> UserSettings, see:
>
>
> https://github.com/snowleopard/hadrian/blob/master/doc/user-settings.md#verbose-command-lines
>
> So, you can do:
>
> verboseCommand = input "//GHC/Real.hs"
>
> Or, alternatively,
>
> verboseCommand = output "//GHC/Real.hi"
>
> Both should produce the same result (in theory).
>
> In general, we have the following documents on Hadrian:
>
> The README: https://github.com/snowleopard/hadrian/blob/master/README.md
> How to use UserSettings:
> https://github.com/snowleopard/hadrian/blob/master/doc/user-settings.md
> An overview of build flavours:
> https://github.com/snowleopard/hadrian/blob/master/doc/flavours.md
>
> I hope the more Hadrian gets used, the more complete the documentation
> will become.
>
> Cheers,
> Andrey
>
> From: Simon Peyton Jones [mailto:simo...@microsoft.com]
> Sent: 30 August 2018 12:19
> To: Simon Peyton Jones ; Alp Mestanogullari <
> a...@well-typed.com>; Andrey Mokhov 
> Cc: ghc-devs 
> Subject: RE: Hadrian
>
> Sigh.  As an inconvenient workaround, I tried adding {-# OPTIONS_GHC
> -dverbose-core2core #-} to GHC.Real, and then doing
> cabal new-run hadrian -- -c -j4 --flavour=quick --directory=".."
> in hadrian/
> That did recompile GHC.Real - but all the debug output disappeared!
> I tried adding {-# OPTIONS_GHC -ddebug-output #-} as well, but that didn't
> work.
> I'm stuck - any ideas?
> Simon
>
> From: ghc-devs  On Behalf Of Simon Peyton
> Jones via ghc-devs
> Sent: 30 August 2018 12:12
> To: Alp Mestanogullari ; Andrey Mokhov <
> andrey.mok...@newcastle.ac.uk>
> Cc: ghc-devs 
> Subject: Hadrian
>
> Alp, Andrey
> The old build system printed out every command line; and I often
> copy-paste that info to build single modules.
> Eg currently, when trying to understand #15570 I see a suspicious
> GHC.Real.hi.  So I want to manually recompile GHC.Real (from base), adding
> some debug flags.  How can I get the right command line to do that from the
> build log?
> Where is the "how to use Hadrian" wiki page?  I know you've been writing
> one.
> 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

Re: CI constanly fails on clonning

[Artem Pelenitsyn]

Ouch, indeed! Thank you, Matt!

--
Best, Artem

On Tue, 14 Aug 2018 at 19:21 Matthew Pickering 
wrote:

> It fails because you are using `--skip-staging`. It sounds like you
> haven't set up your SSH keys properly on your new hardware?
>
> Matt
>
> On Tue, Aug 14, 2018 at 5:01 PM, Artem Pelenitsyn
>  wrote:
> > Hello, devs,
> >
> > Could someone point me where I go wrong in the following? My
> Differentials
> > constantly fail to CI with the messages like this one:
> >
> > exception 'PhabricatorWorkerPermanentFailureException' with message
> 'Lease
> > "PHID-DRYL-sydepw7hjxlnim325sdu" never activated.' in
> >
> /opt/phabricator/src/applications/harbormaster/step/HarbormasterLeaseWorkingCopyBuildStepImplementation.php:91
> > Stack trace:
> > #0
> >
> /opt/phabricator/src/applications/harbormaster/worker/HarbormasterTargetWorker.php(70):
> >
> HarbormasterLeaseWorkingCopyBuildStepImplementation->execute(Object(HarbormasterBuild),
> > Object(HarbormasterBuildTarget))
> > #1
> >
> /opt/phabricator/src/infrastructure/daemon/workers/PhabricatorWorker.php(123):
> > HarbormasterTargetWorker->doWork()
> > #2
> >
> /opt/phabricator/src/infrastructure/daemon/workers/storage/PhabricatorWorkerActiveTask.php(171):
> > PhabricatorWorker->executeTask()
> > #3
> >
> /opt/phabricator/src/infrastructure/daemon/workers/PhabricatorTaskmasterDaemon.php(22):
> > PhabricatorWorkerActiveTask->executeTask()
> > #4 /opt/libphutil/src/daemon/PhutilDaemon.php(219):
> > PhabricatorTaskmasterDaemon->run()
> > #5 /opt/libphutil/scripts/daemon/exec/exec_daemon.php(131):
> > PhutilDaemon->execute()
> > #6 {main}
> >
> > Examples:
> > https://phabricator.haskell.org/harbormaster/build/50735/
> > https://phabricator.haskell.org/harbormaster/build/51066/
> > https://phabricator.haskell.org/harbormaster/build/51616/
> >
> > I googled this and found a similar topic on Phab's bug tracker:
> > https://secure.phabricator.com/T10982
> > Not particularly helpful 'cause I don't really understand the internals
> of
> > Phab.
> >
> > This started to happen roughly when I moved my ghc hacking setup to a new
> > hardware this summer. Maybe, that's connected. Also, what suspicious is
> that
> > `arc diff` tries to push changes in master right away, so I have to pass
> > --skip-staging. This wasn't the case before, I believe.
> >
> > --
> > Best, Artem
> > Best, Artem
> >
> >
> > ___
> > 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 constanly fails on clonning

[Artem Pelenitsyn]

Hello, devs,

Could someone point me where I go wrong in the following? My Differentials
constantly fail to CI with the messages like this one:

exception 'PhabricatorWorkerPermanentFailureException' with message 'Lease
"PHID-DRYL-sydepw7hjxlnim325sdu" never activated.' in
/opt/phabricator/src/applications/harbormaster/step/HarbormasterLeaseWorkingCopyBuildStepImplementation.php:91
Stack trace:
#0
/opt/phabricator/src/applications/harbormaster/worker/HarbormasterTargetWorker.php(70):
HarbormasterLeaseWorkingCopyBuildStepImplementation->execute(Object(HarbormasterBuild),
Object(HarbormasterBuildTarget))
#1
/opt/phabricator/src/infrastructure/daemon/workers/PhabricatorWorker.php(123):
HarbormasterTargetWorker->doWork()
#2
/opt/phabricator/src/infrastructure/daemon/workers/storage/PhabricatorWorkerActiveTask.php(171):
PhabricatorWorker->executeTask()
#3
/opt/phabricator/src/infrastructure/daemon/workers/PhabricatorTaskmasterDaemon.php(22):
PhabricatorWorkerActiveTask->executeTask()
#4 /opt/libphutil/src/daemon/PhutilDaemon.php(219):
PhabricatorTaskmasterDaemon->run()
#5 /opt/libphutil/scripts/daemon/exec/exec_daemon.php(131):
PhutilDaemon->execute()
#6 {main}

Examples:
https://phabricator.haskell.org/harbormaster/build/50735/
https://phabricator.haskell.org/harbormaster/build/51066/
https://phabricator.haskell.org/harbormaster/build/51616/

I googled this and found a similar topic on Phab's bug tracker:
https://secure.phabricator.com/T10982
Not particularly helpful 'cause I don't really understand the internals of
Phab.

This started to happen roughly when I moved my ghc hacking setup to a new
hardware this summer. Maybe, that's connected. Also, what suspicious is
that `arc diff` tries to push changes in master right away, so I have to
pass --skip-staging. This wasn't the case before, I believe.

--
Best, Artem
Best, Artem
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Any ways to test a GHC build against large set of packages (including test suites)?

[Artem Pelenitsyn]

Hello Ömer,

Just a week ago I asked very similar question: how to install the test
suite dependencies after breaking changes in GHC:

https://mail.haskell.org/pipermail/ghc-devs/2018-August/016075.html

But no one replied :(

The task seems to be not solvable even if an affected package (stm in your
case and primitive in mine) has already adopted in its master the breaking
change but has no corresponding release on Hackage (which will always be
the case, because how would you release depending on base which hasn't been
released yet).

Some package managers in other languages (Julia's Pkg, go install) allow
you to depend directly on master branch of a package if you wish to. I
wonder if there is a road here for cabal to take in order to support this
kind of unsafe installs.

--
Best wishes,
Artem

On Fri, 10 Aug 2018, 11:40 Ömer Sinan Ağacan,  wrote:

> Hi,
>
> This is working great, I just generated my first report. One problem is
> stm-2.4
> doesn't compile with GHC HEAD, we need stm-2.5.0.0. But that's not
> published on
> Hackage yet, and latest nightly still uses stm-2.4.5.0. I wonder if there's
> anything that can be done about this. Apparently stm blocks 82 packages (I
> don't know if that's counting transitively or just packages that are
> directly
> blocked by stm). Any ideas about this?
>
> Ömer
>
> Ömer Sinan Ağacan , 9 Ağu 2018 Per, 14:45
> tarihinde şunu yazdı:
> >
> > Ah, I now realize that that command is supposed to print that output.
> I'll
> > continue following the steps and keep you updated if I get stuck again.
> >
> > Ömer
> >
> > Ömer Sinan Ağacan , 9 Ağu 2018 Per, 13:20
> > tarihinde şunu yazdı:
> > >
> > > Hi Manuel,
> > >
> > > I'm trying stackage-head. I'm following the steps for the scheduled
> build in
> > > .circleci/config.yml. So far steps I took:
> > >
> > > - Installed ghc-head (from [1]) to ~/ghc-head
> > > - Installed stackage-build-plan, stackage-curator and stackage-head
> (with
> > >   -fdev) from git repos, using stack.
> > > - export BUILD_PLAN=nightly-2018-07-30 (from config.yml)
> > > - curl
> https://ghc-artifacts.s3.amazonaws.com/nightly/validate-x86_64-linux/latest/metadata.json
> > > --output metadata.json
> > > - curl
> https://raw.githubusercontent.com/fpco/stackage-nightly/master/$BUILD_PLAN.yaml
> > > --output $BUILD_PLAN.yaml
> > >
> > > Now I'm doing
> > >
> > > - ./.local/bin/stackage-head already-seen --target $BUILD_PLAN
> > > --ghc-metadata metadata.json --outdir build-reports
> > >
> > > but it's failing with
> > >
> > > The combination of target and commit is new to me
> > >
> > > Any ideas what I'm doing wrong?
> > >
> > > Thanks
> > >
> > > [1]:
> https://ghc-artifacts.s3.amazonaws.com/nightly/validate-x86_64-linux/latest/bindist.tar.xz
> > >
> > > Ömer
> > >
> > > Ömer Sinan Ağacan , 7 Ağu 2018 Sal, 23:28
> > > tarihinde şunu yazdı:
> > > >
> > > > Thanks for both suggestions. I'll try both and see which one works
> better.
> > > >
> > > > Ömer
> > > >
> > > > Manuel M T Chakravarty , 7 Ağu 2018 Sal, 18:15
> > > > tarihinde şunu yazdı:
> > > > >
> > > > > Hi Ömer,
> > > > >
> > > > > This is exactly the motivation for the Stackage HEAD works that we
> have pushed at Tweag I/O in the context of the GHC DevOps group. Have a
> look at
> > > > >
> > > > >   https://github.com/tweag/stackage-head
> > > > >
> > > > > and also the blog post from when the first version went live:
> > > > >
> > > > >   https://www.tweag.io/posts/2018-04-17-stackage-head-is-live.html
> > > > >
> > > > > Cheers,
> > > > > Manuel
> > > > >
> > > > > > Am 06.08.2018 um 09:40 schrieb Ömer Sinan Ağacan <
> omeraga...@gmail.com>:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I'd like to test some GHC builds + some compile and runtime flag
> combinations
> > > > > > against a large set of packages by building them and running
> test suites. For
> > > > > > this I need
> > > > > >
> > > > > > - A set of packages that are known to work with latest GHC
> > > > > > - A way to build them and run their test suites (if I could
> specify compile and
> > > > > >  runtime flags that'd be even better)
> > > > > >
> > > > > > I think stackage can serve as (1) but I don't know how to do
> (2). Can anyone
> > > > > > point me to the right direction? I vaguely remember some
> nix-based solution for
> > > > > > this that was being discussed on the IRC channel, but can't
> recall any details.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Ömer
> > > > > > ___
> > > > > > 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

Re: Scripts merged for easily loading and running GHC in GHCi, for fast development iterations

[Artem Pelenitsyn]

I added this to the wiki. It would be nice to have a wrapper similar to
`run.sh` but for starting ghcid, I believe.

--
Best wishes,
Artem

On Sun, 29 Jul 2018 at 10:41 Matthew Pickering 
wrote:

> Can you please update the wiki page?
>
> https://ghc.haskell.org/trac/ghc/wiki/Building/InGhci
>
> Matt
>
> On Sun, Jul 29, 2018 at 6:18 AM, Michael Sloan  wrote:
> > Hello GHC developers!
> >
> > Now that D4904 and D4986 are merged, if you have recently built GHC
> > then you can use "./utils/ghc-in-ghci/run.sh -fobject-code" to load
> > GHC into GHCi (throwing on a "-j8" helps too).  For me, this makes
> > development far more pleasant, as often I can make a change and try it
> > out in only 15 or 20 seconds.  Thanks to Csongor Kiss for writing the
> > initial ghci script, and Matthew Pickering for posting about it to the
> > mailinglist, as otherwise I probably wouldn't have known about it.
> >
> > I wrote a blog post about the topic on my new blog:
> > http://www.mgsloan.com/posts/ghcinception/
> >
> > Once D5015 is merged, the explicit "-fobject-code" won't be needed.
> > Once https://ghc.haskell.org/trac/ghc/ticket/15454 is addressed, it
> > might not be needed at all, leading to even faster loading ;)
> >
> > Happy ghci-ing!
> > -Michael
> > ___
> > 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

Re: PSA: You likely want to use -O2 for the stage1 compiler.

[Artem Pelenitsyn]

Thanks, Andreas!

I believe, the wiki modestly tries to suggest this here:
https://ghc.haskell.org/trac/ghc/wiki/Building/Using#Workingonanoptimizedstage2compiler.
Maybe, it should be more insistent, e.g., by adding these numbers or moving
the advice to a more visible place. Not sure.

--
Best, Artem

On Sun, 5 Aug 2018 at 01:58 Andreas Klebinger 
wrote:

> I've wondered for a good while if using O2 on stage1 might be worth it.
>
> So I did some measurements and it should be worth it for most cases.
>
> For a single "quick" flavour build they are more or less on equal footing.
> If you rebuild stage2 multiple times reusing stage1 it will be faster.
> If you build stage2 with optimizations/profiling it will be faster.
>
> Below are the timings using "time make -j9" for a quick build.
> I forgot to write down the seconds as I didn't expect them to be so close.
> But it is what it is.
>
> Timings stage1 options O1 vs O2, quick build after make clean:
>
> stage1 opt | time (wall) | time (user)
> -O1|   13m   |   53m
> -O2|   13m   |   51m
>
> I've also run the numbers for a optimized stage2 compiler a while ago,
> where stage1 with O2 was faster.
> But I no longer have these numbers around.
>
> So it seems safe to say one should use O2 if either:
> * stage2 is built with optimizations
> * you freeze stage1 and reuse it while working on stage2
>
>
> ___
> 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

How to test master after breaking changes

[Artem Pelenitsyn]

Hello devs,

Wiki page on testing says that in order to run all tests you have to
install additional packages:

https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Running#AdditionalPackages

and kindly provides a command to do this:

cabal install --with-compiler=`pwd`/inplace/bin/ghc-stage2
--package-db=`pwd`/inplace/lib/package.conf.d mtl parallel parsec primitive
QuickCheck random regex-compat syb stm utf8-string vector

After the af9b744bb

one of the packages, primitive, does not build anymore. At least, its last
released version on Hackage. I see that the problem has been fixed on
primitive's master (a2af610
).
But what should I do to actually test master branch of GHC now?

--
Best wishes,
Artem
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: accuracy of asinh and atanh

[Artem Pelenitsyn]

Thanks David! Indeed, here is the commit and ticket:

https://github.com/ghc/ghc/commit/3ea33411d7cbf32c20940cc72ca07df6830eeed7
https://ghc.haskell.org/trac/ghc/ticket/14927

This concerns only `asinh` though. The implementation is closer to what
Matt proposes in his package but simpler. Nevertheless, the original issue
about `Infinity` on large negative numbers seems to be fixed with this.

So, I guess, feel free to kill the patch.

--
Best, Artem

On Thu, 2 Aug 2018 at 23:19 David Feuer  wrote:

> Wasn't there a very recent commit to improve these functions, by
> leftaroundabout?
>
> On Thursday, August 2, 2018 8:16:10 AM EDT Artem Pelenitsyn wrote:
> > Here is the patch: https://phabricator.haskell.org/D5034
> >
> > --
> > Best, Artem
> >
> > On Thu, 2 Aug 2018 at 06:26 Artem Pelenitsyn 
> wrote:
> >
> > > I'd be willing to do this.
> > >
> > > --
> > > Best wishes,
> > > Artem
> > >
> > >
> > > On Thu, 2 Aug 2018, 04:38 Matt Peddie,  wrote:
> > >
> > >> Thanks, Ben, for chiming in.  I think calling out to C for these
> > >> functions is the way to go if it's now feasible.  (Calling out to libm
> > >> is the workaround I'm using in the application that led me to discover
> > >> the inaccuracy.)
> > >>
> > >> Matt
> > >>
> > >> On Thu, Aug 2, 2018 at 11:33 AM, Ben Gamari 
> wrote:
> > >> > Matt Peddie  writes:
> > >> >
> > >> >> Hi George,
> > >> >>
> > >> >> Not a stupid question.  I don't have a single source at hand, but I
> > >> >> think I read in a few places on the wiki that calling out to the
> > >> >> system math library is not an option due to the variety of system
> math
> > >> >> libraries on the platforms GHC supports.  It'd be great if I got
> the
> > >> >> wrong impression and this could just be a call to C.  Can anyone
> set
> > >> >> me straight on this point?
> > >> >>
> > >> > Indeed it's not a stupid question at all. Indeed this is precisely
> what
> > >> > we do for the simpler transcendentals (e.g. sin, asin, log). We very
> > >> > well could move in this direction in the case of asinh/atanh as
> well. I
> > >> > believe the reason we don't currently is that atanh was only
> > >> > standardized in C99, which we only started requiring a few releases
> ago.
> > >> > Perhaps this is ultimately the right direction.
> > >> >
> > >> > Cheers,
> > >> >
> > >> > - Ben
> > >> ___
> > >> ghc-devs mailing list
> > >> ghc-devs@haskell.org
> > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> > >>
> > >
> >
>
>
> --
> David Feuer
> Well-Typed
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: accuracy of asinh and atanh

[Artem Pelenitsyn]

Here is the patch: https://phabricator.haskell.org/D5034

--
Best, Artem

On Thu, 2 Aug 2018 at 06:26 Artem Pelenitsyn  wrote:

> I'd be willing to do this.
>
> --
> Best wishes,
> Artem
>
>
> On Thu, 2 Aug 2018, 04:38 Matt Peddie,  wrote:
>
>> Thanks, Ben, for chiming in.  I think calling out to C for these
>> functions is the way to go if it's now feasible.  (Calling out to libm
>> is the workaround I'm using in the application that led me to discover
>> the inaccuracy.)
>>
>> Matt
>>
>> On Thu, Aug 2, 2018 at 11:33 AM, Ben Gamari  wrote:
>> > Matt Peddie  writes:
>> >
>> >> Hi George,
>> >>
>> >> Not a stupid question.  I don't have a single source at hand, but I
>> >> think I read in a few places on the wiki that calling out to the
>> >> system math library is not an option due to the variety of system math
>> >> libraries on the platforms GHC supports.  It'd be great if I got the
>> >> wrong impression and this could just be a call to C.  Can anyone set
>> >> me straight on this point?
>> >>
>> > Indeed it's not a stupid question at all. Indeed this is precisely what
>> > we do for the simpler transcendentals (e.g. sin, asin, log). We very
>> > well could move in this direction in the case of asinh/atanh as well. I
>> > believe the reason we don't currently is that atanh was only
>> > standardized in C99, which we only started requiring a few releases ago.
>> > Perhaps this is ultimately the right direction.
>> >
>> > 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: accuracy of asinh and atanh

[Artem Pelenitsyn]

I'd be willing to do this.

--
Best wishes,
Artem

On Thu, 2 Aug 2018, 04:38 Matt Peddie,  wrote:

> Thanks, Ben, for chiming in.  I think calling out to C for these
> functions is the way to go if it's now feasible.  (Calling out to libm
> is the workaround I'm using in the application that led me to discover
> the inaccuracy.)
>
> Matt
>
> On Thu, Aug 2, 2018 at 11:33 AM, Ben Gamari  wrote:
> > Matt Peddie  writes:
> >
> >> Hi George,
> >>
> >> Not a stupid question.  I don't have a single source at hand, but I
> >> think I read in a few places on the wiki that calling out to the
> >> system math library is not an option due to the variety of system math
> >> libraries on the platforms GHC supports.  It'd be great if I got the
> >> wrong impression and this could just be a call to C.  Can anyone set
> >> me straight on this point?
> >>
> > Indeed it's not a stupid question at all. Indeed this is precisely what
> > we do for the simpler transcendentals (e.g. sin, asin, log). We very
> > well could move in this direction in the case of asinh/atanh as well. I
> > believe the reason we don't currently is that atanh was only
> > standardized in C99, which we only started requiring a few releases ago.
> > Perhaps this is ultimately the right direction.
> >
> > 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: submodule repos on GitHub

[Artem Pelenitsyn]

I personally consider this to be most reasonable. But maybe I oversee
something…

--
Best, Artem
вт, 17 июля 2018 г. в 22:59, Richard Eisenberg :

> Aha. I had just jumped to the chase.
>
> But is there a reason we don't just point everyone (including newcomers)
> to git://git.haskell.org/ghc.git ? That's what I always use myself, and
> it seems simpler to do so.
>
> Richard
>
>
> On Jul 17, 2018, at 3:14 PM, Matthew Pickering <
> matthewtpicker...@gmail.com> wrote:
>
> Did you do the line above as well?
>
> ```
> git config --global url."git://github.com/ghc/packages-".insteadOf
> git://github.com/ghc/packages/
> ```
>
> On Tue, Jul 17, 2018 at 8:09 PM, Richard Eisenberg 
> wrote:
>
> Hi devs,
>
> The Newcomers page (https://ghc.haskell.org/trac/ghc/wiki/Newcomers)
> recommends cloning GHC with
>
> git clone --recursive git://github.com/ghc/ghc
>
>
> I believe my students did this with success several weeks ago. But trying
> it again today leads to trouble with some submodules, e.g.:
>
> Cloning into '/Users/rae/ltemp/ghc-test/libraries/Cabal'...
> fatal: remote error:
>  ghc/packages/Cabal is not a valid repository name
>  Email supp...@github.com for help
> fatal: clone of 'git://github.com/ghc/packages/Cabal.git' into submodule
> path '/Users/rae/ltemp/ghc-test/libraries/Cabal' failed
>
>
> Is there something wrong in the internets? Or should we update the
> Newcomers page?
>
> Thanks,
> Richard
> ___
> 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

Re: submodule repos on GitHub

[Artem Pelenitsyn]

The other page

https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources

suggests:

git clone --recursive git://git.haskell.org/ghc.git

This always works to me.

--
Best wishes,
Artem

вт, 17 июля 2018 г. в 21:14, Matthew Pickering :

> Did you do the line above as well?
>
> ```
> git config --global url."git://github.com/ghc/packages-".insteadOf
> git://github.com/ghc/packages/
> ```
>
> On Tue, Jul 17, 2018 at 8:09 PM, Richard Eisenberg 
> wrote:
> > Hi devs,
> >
> > The Newcomers page (https://ghc.haskell.org/trac/ghc/wiki/Newcomers)
> recommends cloning GHC with
> >
> >> git clone --recursive git://github.com/ghc/ghc
> >
> > I believe my students did this with success several weeks ago. But
> trying it again today leads to trouble with some submodules, e.g.:
> >
> >> Cloning into '/Users/rae/ltemp/ghc-test/libraries/Cabal'...
> >> fatal: remote error:
> >>   ghc/packages/Cabal is not a valid repository name
> >>   Email supp...@github.com for help
> >> fatal: clone of 'git://github.com/ghc/packages/Cabal.git' into
> submodule path '/Users/rae/ltemp/ghc-test/libraries/Cabal' failed
> >>
> >
> > Is there something wrong in the internets? Or should we update the
> Newcomers page?
> >
> > Thanks,
> > Richard
> > ___
> > 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

Re: Trac email

[Artem Pelenitsyn]

Hello,

It stopped working for me from like Sunday and wasn't working for about two
days. Then, on Tuesday, it silently started working again. Although, I
haven't checked that I get all the emails.

--
Best, Artem

On Thu, 31 May 2018, 21:13 Simon Peyton Jones via ghc-devs, <
ghc-devs@haskell.org> wrote:

> Devs
>
> Trac has entirely stopped sending me email, so I have no idea what’s
> happening on the GHC front.  Could someone unglue it?
>
> Thanks!
>
> 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

Re: Site of ghc.haskell.org is down?

[Artem Pelenitsyn]

Another issue, not directly connected, but also with the site: the 
menu links on haskell.org/ghc (Report a bug, Request a feature, Developers 
(wiki)) point to Hackage subdomain instead of ghc one.


--
Best, Artem


On Sun, 15 Apr 2018, David Kraeutmann wrote:


It's an issue with the site---the SSL certificate seems to have expired.


On 04/15/2018 02:37 AM, Takenobu Tani wrote:

Hi devs,

When I accessed `https://ghc.haskell.org/`
, the following message is displayed:

  Your connection is not secure

I checked it with Firefox and Chrome.
Is it a matter of site setting?

Regards,
Takenobu



___
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

Guarded Impredicativity implementation

[Artem Pelenitsyn]

Dear ghc-devs,

Is there any work has been done on the latest (ttbomk) proposal for
impredicative types in Haskell:

> Guarded impredicative polymorphism by Alejandro Serrano, Jurriaan Hage,
Dimitrios Vytiniotis, Simon Peyton Jones
https://www.microsoft.com/en-us/research/wp-content/uploads/2017/07/impredicative-Jul17.pdf

Or are there any plans to do so? I wasn't able to spot any mentions of this
in either of GHC's forums (this list, Trac, wiki, ghc-proposals repo).

--
Best wishes,
Artem Pelenitsyn
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs