Re: "Modularizing GHC" paper

[Eric Crockett]

I am very happy to see this paper. It was an enjoyable read, and accessible
to non-experts such as myself. I appreciated the effort spent on research,
and was even happier to see that you have started implementing these
suggestions and have a plan going forward. Technical debt is a hard thing
to overcome, especially in the face of a rapidly evolving language.

This paper resonates with me as both a user and one-time (as in a single
time) developer of GHC. As a user, I’ve run into issues related to the
debts you discuss. I also tried to fix a GHC bug, and remember being
overwhelmed by DynFlags.

I applaud your efforts. Thank you for this service to the Haskell community.

Eric Crockett

On Wed, May 4, 2022 at 3:51 AM Sylvain Henry  wrote:

> Hi GHC devs,
>
> With John Ericson and Jeffrey Young we wrote a paper about the
> modularization of GHC. It gives a global picture for the refactorings we
> have been performing (c.f. e.g. #17957) and some potential future ones.
>
> Announce blog post:
> https://hsyl20.fr/home/posts/2022-05-03-modularizing-ghc-paper.html
> Paper: https://hsyl20.fr/home/files/papers/2022-ghc-modularity.pdf
> Discussion on Reddit:
> https://www.reddit.com/r/haskell/comments/uhdu4l/modularizing_ghc_paper/
>
> We welcome any feedback, here or on reddit.
>
> Cheers,
> Sylvain
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Cannot build with Hadrian

[Eric Crockett]

GHC newcomer here -- attempting to work on my first patch.

I decided to try Hadrian, but ran into a problem.

I think I obtained the source using
> git clone --recursive https://gitlab.haskell.org/ghc/ghc
Then:
> ./boot && ./configure
> hadrian/build.sh -j --flavour=devel2

This ran for maybe 15 minutes, then showed the error below. Apparently I
ended up with too many tarballs? Any suggestions?

Thanks,
Eric

...

 ...

| Run Ghc CompileCWithGhc Stage1: rts/Inlines.c =>
> _build/stage1/rts/build/c/Inlines.thr_o
> | Run Cc FindCDependencies Stage1: rts/Compact.cmm =>
> _build/stage1/rts/build/cmm/Compact.o.d
> | Run Cc FindCDependencies Stage1: rts/PathUtils.c =>
> _build/stage1/rts/build/c/PathUtils.o.d
> | Run Ghc CompileHs Stage1: rts/Compact.cmm =>
> _build/stage1/rts/build/cmm/Compact.o
> | Run Ghc CompileCWithGhc Stage1: rts/PathUtils.c =>
> _build/stage1/rts/build/c/PathUtils.o
> | Remove file _build/stage1/rts/build/libHSrts-1.0.a
> | Run Ar Pack Stage1: _build/stage1/rts/build/c/Adjustor.o (and 113 more)
> => _build/stage1/rts/build/libHSrts-1.0.a
> /usr/bin/ar: creating _build/stage1/rts/build/libHSrts-1.0.a
> /---\
> | Successfully built library 'rts' (Stage1, way v). |
> | Library: _build/stage1/rts/build/libHSrts-1.0.a   |
> \---/
> | Remove file _build/stage1/rts/build/libHSrts-1.0_thr.a
> | Run Ar Pack Stage1: _build/stage1/rts/build/c/Adjustor.thr_o (and 115
> more) => _build/stage1/rts/build/libHSrts-1.0_thr.a
> /usr/bin/ar: creating _build/stage1/rts/build/libHSrts-1.0_thr.a
> /-\
> | Successfully built library 'rts' (Stage1, way thr). |
> | Library: _build/stage1/rts/build/libHSrts-1.0_thr.a |
> \-/
> | Copy file: _build/generated/ghcplatform.h =>
> _build/stage1/rts/build/ghcplatform.h
> | Copy file: _build/generated/ghcversion.h =>
> _build/stage1/rts/build/ghcversion.h
> | Copy file: _build/generated/DerivedConstants.h =>
> _build/stage1/rts/build/DerivedConstants.h
> | Copy file: _build/generated/ghcautoconf.h =>
> _build/stage1/rts/build/ghcautoconf.h
> | Remove directory _build/stage1/libffi/build
> shakeArgsWith0.000s0%
> Function shake   0.005s0%
> Database read0.000s0%
> With database0.000s0%
> Running rules  548.377s   99%  =
> Total  548.383s  100%
> Error when running Shake build system:
>   at src/Rules.hs:(35,19)-(52,17):
>   at src/Rules.hs:52:5-17:
> * Depends on: _build/stage1/lib/package.conf.d/rts-1.0.conf
>   at src/Rules/Register.hs:(94,9)-(98,34):
> * Depends on: _build/stage1/rts/build/ffi.h
>   at src/Rules/Libffi.hs:(49,7)-(52,48):
> * Depends on: _build/stage1/rts/build/ffi.h
> _build/stage1/rts/build/ffitarget.h
>   at src/Rules/Libffi.hs:52:13-48:
> * Depends on: _build/stage1/libffi/build/inst/lib/libffi.a
>   at src/Hadrian/Builder.hs:70:5-23:
> * Depends on: _build/stage1/libffi/build/Makefile
>   at src/Rules/Libffi.hs:107:9-27:
> * Depends on: _build/stage1/libffi/build/Makefile.in
> * Raised the exception:
> Exactly one LibFFI tarball is expected
> CallStack (from HasCallStack):
>   error, called at src/Hadrian/Utilities.hs:60:27 in main:Hadrian.Utilities
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Reproducing bugs without Stack

[Eric Crockett]

Devs,

I use Stack for all of my Haskell development. I recently ran into several
bugs, which I suspected to be GHC bugs. In the process of creating new
tickets, I noticed a banner reading "*Please try to provide reproduction
instructions which do not require "Stack"." *The request is reasonable to
help weed out bugs in Stack itself, but I could use some advice on how to
do that.

In particular, I'm having trouble reproducing bugs related to profiling.
For example, #16182 <https://ghc.haskell.org/trac/ghc/ticket/16182> is
about runtime crashes with the -hr profiling option. This was clearly a GHC
bug rather than a problem with stack, yet I have so far been unable to
produce the bug without Stack. Similarly, for #16166
<https://ghc.haskell.org/trac/ghc/ticket/16166>, I filed the ticket, then
after failing to reproduce the bug with cabal, assumed it must be a stack
bug. Fortunately, RyanGlScott noticed and was able to confirm that it is in
fact a GHC bug. Ryan explained that my problem reproducing with cabal is
due to differences in the profiling options used by stack and cabal.

In summary, it would be helpful to have some instructions on how to take a
bug produced using Stack to one produced without. For example, if `stack
build [--profile] foo` produces a compile bug, how should I use cabal to
definitively determine if the bug is a problem with Stack or GHC?
Presumably it would begin with `cabal sandbox init`. Are there special
options to put in the cabal.config file so that cabal uses the same
profiling options as stack? Will those options be used when building all
dependencies?

Thanks,
Eric Crockett
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Tool for minimizing examples

[Eric Crockett]

Devs: as I'm sure you know, the hardest part of reporting a GHC bug is
finding a minimal example that triggers the bug. When I initially trigger a
bug in my large code base, my workflow is something like:

 1. write a driver that triggers the bug
 2. do manual dead code elimination by removing unused files and functions
 3. "human required" step to figure out what can be trimmed to further
minimize
 4. go to step 2 until example is simple enouogh

Since I work on a large library (>60 modules) and also report a fair number
of bugs, I spend a nontrivial amount of time on step 2, which is completely
mechanical. It would be nice to have a tool that can help out.
Specifically, something that takes a "driver" file, and produces a copy of
the code contents to a new directory sans unimported files, and unused
functions from imported files.

Ideally, this tool would make a "closed universe" assumption so that
exported functions can also be eliminated as dead, if they are never used
elsewhere. A bonus feature would be to remove unused imports, and even
unused build-depends from the cabal file.

Are there any tools out there that can do any portion of this process for
me? Perhaps it is possible to output contents after the compiler does a DCE
pass?

Regards,
Eric Crockett
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Can we offer ~ without GADTs or type families?

[Eric Crockett]

As a user who frequently uses ~, but doesn't need the rest of GADTs or
TypeFamilies, I'd really like to see a TypeEqualities extension!

Eric

On Fri, Aug 5, 2016 at 3:27 PM, Adam Gundry  wrote:

> On 05/08/16 19:08, David Feuer wrote:
> > It seems to me that equality constraints could potentially be supported
> > by an implementation with neither GADTs nor type families. Type families
> > don't really seem to have much to do with it, and GADTs are strictly
> > heavier (GADTs ~= ExistentialQuantification + TypeEquality).
> >
> > Could we get a separate LANGUAGE pragma just for equality constraints?
>
> I suggested this in #10431 [1], where there is some discussion of the
> implications. I still think it is a good idea, and I don't think the
> implementation would be very difficult.
>
> All the best,
>
> Adam
>
> [1] https://ghc.haskell.org/trac/ghc/ticket/10431
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [GHC] #7803: Superclass methods are left unspecialized

[Eric Crockett]

My apologies for that. Please ignore.

On Sat, Feb 6, 2016 at 11:16 AM, Eric Crockett <ecrocke...@gmail.com> wrote:

> https://ghc.haskell.org/trac/ghc/ticket/7803#comment:12
>
> On Sat, Feb 6, 2016 at 11:14 AM, GHC <ghc-devs@haskell.org> wrote:
>
>> #7803: Superclass methods are left unspecialized
>>
>> -+-
>> Reporter:  akio  |Owner:
>> Type:  bug   |   Status:  new
>> Priority:  normal|Milestone:
>>Component:  Compiler  |  Version:  7.6.2
>>   Resolution:| Keywords:
>> Operating System:  Unknown/Multiple  | Architecture:
>>  Type of failure:  Compile-time  |  Unknown/Multiple
>>   performance bug|Test Case:
>>   Blocked By:| Blocking:
>>  Related Tickets:|  Differential Rev(s):
>>Wiki Page:|
>>
>> -+-
>>
>> Comment (by bgamari):
>>
>>  I've started a pair of builds; I'll put up nofib results once they have
>>  finished.
>>
>> --
>> Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7803#comment:12>
>> GHC <http://www.haskell.org/ghc/>
>> The Glasgow Haskell Compiler
>>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [GHC] #7803: Superclass methods are left unspecialized

[Eric Crockett]

https://ghc.haskell.org/trac/ghc/ticket/7803#comment:12

On Sat, Feb 6, 2016 at 11:14 AM, GHC  wrote:

> #7803: Superclass methods are left unspecialized
> -+-
> Reporter:  akio  |Owner:
> Type:  bug   |   Status:  new
> Priority:  normal|Milestone:
>Component:  Compiler  |  Version:  7.6.2
>   Resolution:| Keywords:
> Operating System:  Unknown/Multiple  | Architecture:
>  Type of failure:  Compile-time  |  Unknown/Multiple
>   performance bug|Test Case:
>   Blocked By:| Blocking:
>  Related Tickets:|  Differential Rev(s):
>Wiki Page:|
> -+-
>
> Comment (by bgamari):
>
>  I've started a pair of builds; I'll put up nofib results once they have
>  finished.
>
> --
> Ticket URL: 
> GHC 
> The Glasgow Haskell Compiler
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: more releases

[Eric Crockett]

Some people had asked what the users want and about typical usage, so I'll
give the my perspective. I consider myself a pretty typical user of
Haskell: PhD student (in theory, not languages), but still pushing the
boundaries of the compiler. I've filed quite a few bugs, so I have
experience with having to wait for them to get fixed. My code at various
points has been littered with "see ticket #xxx for why I'm jumping through
three hoops to accomplish this". As a result, I would be interested in
getting builds with bugfixes. For example see the discussion on #10428:
https://ghc.haskell.org/trac/ghc/ticket/10428. It's hard for a user to tell
if/when a patch will be merged. I'm using 7.10.1 at the moment, but I was
unsure if the patch for #10428 made it to 7.10.2.

Ben: I download the GHC bindist directly from the GHC page precisely
because the one on the PPA is (inevitably) ancient.

Upgrading GHC (even minor releases; I just tried 7.10.2 to confirm this) is
a pain because I have to spend an hour downloading and re-building all of
the packages I need. However, I'd certainly be willing to do that for bugs
that affect my code. Richard said, "Then a user's package library doesn't
have to be recompiled when updating". If he means that I wouldn't have to
do that, that's fantastic. However, I still wouldn't download every tiny
release due to the 100mb download+install time to fix bugs that don't
affect me (I'd only do that for bugs that *do* affect me).

In short: I'd really like to have builds for every bug (or maybe every
day/week) that I can easily download and install.


On Mon, Sep 7, 2015 at 12:05 PM, Bardur Arantsson 
wrote:

> On 09/07/2015 04:57 PM, Simon Peyton Jones wrote:
> > Merging and releasing a fix to the stable branch always carries a cost:
> > it might break something else.  There is a real cost to merging, which
> > is why we've followed the lazy strategy that Ben describes.
> >
>
> A valid point, but the upside is that it's a very fast operation to
> revert if a release is "bad"... and get that updated release into the wild.
>
> Regards,
>
> ___
> 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

Fixing anchors in GHC docs

[Eric Crockett]

I think I sent this out already, but never heard back. An issue was fixed
in HsColour regarding HTML anchors in the GHC docs, documented here:
https://github.com/haskell/hackage-server/issues/319

Apparently GHC devs upload their own documentation [to hackage], which
means HsColour needs to be updated on your end so that anchors are correct
the next time docs are generated.

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

Re: Can we fix our Trac that doesn't lose new ticket text

[Eric Crockett]

My Firefox also has this issue. So it seems the problem is the browser
itself. How can this be fixed on the server side?

On Fri, Apr 24, 2015 at 10:07 AM, Edward Z. Yang ezy...@mit.edu wrote:

 Whatever the case, it affects me, it affects SPJ, so we ought to fix it!
 (Change your browser is not a good answer :)

 Edward

 Excerpts from Eric Crockett's message of 2015-04-24 15:02:35 +0100:
  On the contrary, I did precisely that just a few days ago (
  https://ghc.haskell.org/trac/ghc/ticket/10338), and to my surprise, trac
  *did* save my new ticket text. Perhaps this is a browser-specific issue?
  I'm using 64-bit Chrome 42.0.2311.90.
 
  On Fri, Apr 24, 2015 at 9:54 AM, Edward Z. Yang ezy...@mit.edu wrote:
 
   Steps to reproduce:
  
   1. Click New Ticket
   2. Type some text into the box
   3. Press Back in your browser
   4. Press Forward in your browser
  
   If you try this with an official Trac this doesn't happen, so either
   this was fixed in a new version, or we have a plugin installed which
   is causing this to happen.
  
   Current version of Trac is 1.0.5, we're currently running 1.0.1
  
   Thanks,
   Edward
   ___
   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: Can we fix our Trac that doesn't lose new ticket text

[Eric Crockett]

On the contrary, I did precisely that just a few days ago (
https://ghc.haskell.org/trac/ghc/ticket/10338), and to my surprise, trac
*did* save my new ticket text. Perhaps this is a browser-specific issue?
I'm using 64-bit Chrome 42.0.2311.90.

On Fri, Apr 24, 2015 at 9:54 AM, Edward Z. Yang ezy...@mit.edu wrote:

 Steps to reproduce:

 1. Click New Ticket
 2. Type some text into the box
 3. Press Back in your browser
 4. Press Forward in your browser

 If you try this with an official Trac this doesn't happen, so either
 this was fixed in a new version, or we have a plugin installed which
 is causing this to happen.

 Current version of Trac is 1.0.5, we're currently running 1.0.1

 Thanks,
 Edward
 ___
 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

Fwd: [hackage-server] Duplicate anchors in source code (#319)

[Eric Crockett]

I reported a bug in HsColour (
https://github.com/haskell/hackage-server/issues/319#issuecomment-76088047)
which has been fixed in a new version. The HSColour dev thought it might be
useful to mention this new version of HsColour to the GHC devs so that
documentation for 7.10 will be marginally easier to reference.

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