From ben at well-typed.com  Tue Aug  1 02:19:06 2017
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 31 Jul 2017 22:19:06 -0400
Subject: GHC release timing and future build infrastructure
Message-ID: <8760e8m3mt.fsf@ben-laptop.smart-cactus.org>


Hello everyone,

I just posted a pair of posts on the GHC blog [1,2] laying out some
thoughts on the GHC release cycle timing [1] and how this relates to the
in-progress Jenkins build infrastructure [2]. When you have a some time
feel free to give them a read and comment (either here or on the Reddit
thread [3]).

Cheers,

- Ben


[1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule
[2] https://ghc.haskell.org/trac/ghc/blog/jenkins-ci
[3] https://www.reddit.com/r/haskell/comments/6qt0iv/ghc_blog_reflections_on_ghcs_release_schedule/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20170731/7ef9a455/attachment.sig>

From allbery.b at gmail.com  Tue Aug  1 16:30:17 2017
From: allbery.b at gmail.com (Brandon Allbery)
Date: Tue, 1 Aug 2017 12:30:17 -0400
Subject: GHC release timing and future build infrastructure
In-Reply-To: <8760e8m3mt.fsf@ben-laptop.smart-cactus.org>
References: <8760e8m3mt.fsf@ben-laptop.smart-cactus.org>
Message-ID: <CAKFCL4VmUCCU_qDYeH6UTT1cdv6wHQMad1Mg+HRMvfLOmxX6YA@mail.gmail.com>

On Mon, Jul 31, 2017 at 10:19 PM, Ben Gamari <ben at well-typed.com> wrote:

> I just posted a pair of posts on the GHC blog [1,2] laying out some
> thoughts on the GHC release cycle timing [1] and how this relates to the
> in-progress Jenkins build infrastructure [2]. When you have a some time
> feel free to give them a read and comment (either here or on the Reddit
> thread [3]).
>

This release was actually a bit unusual for recent releases, in that a
significant delay did *not* come from working around a major breaking
behavior change in a Tier 1 platform; recent examples being macOS's load
commands limit and Ubuntu defaulting to position-independent executables.

I think this might be relevant to the question of slipping extra stuff into
releases: it's become so common to have extra time courtesy of Tier 1
platforms breaking things on us that slipping extra stuff in is now
expected.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20170801/cdf0ed17/attachment.html>

From qdunkan at gmail.com  Thu Aug  3 19:31:40 2017
From: qdunkan at gmail.com (Evan Laforge)
Date: Thu, 3 Aug 2017 12:31:40 -0700
Subject: 8.2.1 changes to iface/FlagChecker.hs
Message-ID: <CACbaDy6RW8zTRz=GTifPHKcW7CDZd8QEdvP9MX9kE39+PExM0g@mail.gmail.com>

My program uses the GHC API to provide a REPL, and upgrading to 8.2.1
broke that... well, just made it really slow.  Where it used to
quickly load the compiled files, it now wants to recompile everything
as bytecode which makes 1s startup time go to 1m.  The reason was it
now thinks flags have changed.  I tracked it down to changes in
FlagChecker.hs, documented with
https://ghc.haskell.org/trac/ghc/ticket/11798 and
https://ghc.haskell.org/trac/ghc/ticket/10923, which add -fhpc and -O
to the tracked flags.  -fhpc means loading tests in ghci can never
work, because ghci rejects the -fhpc flag, and likewise -O means ghci
can never load optimized files for the same reason.

It seems like the easiest solution might be to just have ghci not
reject -fhpc and -O.  Of course we could also revert those changes,
but they're justified in the trac tickets.

Of course this means I'm loading optimized code together with bytecode
compiled code and maybe that's a bad thing (or for tests, -fhpc with
non-hpc).  But I've been doing this for something like 7 years and
it's been fine.


Unrelatedly, I was hoping compiles would get faster, but they seem a
bit slower, from around 3m20s to around 4m :(  I can track down
per-file timing changes if it would be interesting to someone.

Also thanks to whoever put trac tickets in the comments, it makes it
really easy to find out why a change was made.

From george.colpitts at gmail.com  Thu Aug  3 19:37:23 2017
From: george.colpitts at gmail.com (George Colpitts)
Date: Thu, 03 Aug 2017 19:37:23 +0000
Subject: 8.2.1 changes to iface/FlagChecker.hs
In-Reply-To: <CACbaDy6RW8zTRz=GTifPHKcW7CDZd8QEdvP9MX9kE39+PExM0g@mail.gmail.com>
References: <CACbaDy6RW8zTRz=GTifPHKcW7CDZd8QEdvP9MX9kE39+PExM0g@mail.gmail.com>
Message-ID: <CAB-d4A7xSQyLHhMZ51QWcUUXeajRfK8CLaD9CXpy3tg+B8J=JA@mail.gmail.com>

I reported this in https://ghc.haskell.org/trac/ghc/ticket/13604

On Thu, Aug 3, 2017 at 4:32 PM Evan Laforge <qdunkan at gmail.com> wrote:

> My program uses the GHC API to provide a REPL, and upgrading to 8.2.1
> broke that... well, just made it really slow.  Where it used to
> quickly load the compiled files, it now wants to recompile everything
> as bytecode which makes 1s startup time go to 1m.  The reason was it
> now thinks flags have changed.  I tracked it down to changes in
> FlagChecker.hs, documented with
> https://ghc.haskell.org/trac/ghc/ticket/11798 and
> https://ghc.haskell.org/trac/ghc/ticket/10923, which add -fhpc and -O
> to the tracked flags.  -fhpc means loading tests in ghci can never
> work, because ghci rejects the -fhpc flag, and likewise -O means ghci
> can never load optimized files for the same reason.
>
> It seems like the easiest solution might be to just have ghci not
> reject -fhpc and -O.  Of course we could also revert those changes,
> but they're justified in the trac tickets.
>
> Of course this means I'm loading optimized code together with bytecode
> compiled code and maybe that's a bad thing (or for tests, -fhpc with
> non-hpc).  But I've been doing this for something like 7 years and
> it's been fine.
>
>
> Unrelatedly, I was hoping compiles would get faster, but they seem a
> bit slower, from around 3m20s to around 4m :(  I can track down
> per-file timing changes if it would be interesting to someone.
>
> Also thanks to whoever put trac tickets in the comments, it makes it
> really easy to find out why a change was made.
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20170803/8a26e244/attachment.html>

From qdunkan at gmail.com  Thu Aug  3 19:59:35 2017
From: qdunkan at gmail.com (Evan Laforge)
Date: Thu, 3 Aug 2017 12:59:35 -0700
Subject: 8.2.1 changes to iface/FlagChecker.hs
In-Reply-To: <CAB-d4A7xSQyLHhMZ51QWcUUXeajRfK8CLaD9CXpy3tg+B8J=JA@mail.gmail.com>
References: <CACbaDy6RW8zTRz=GTifPHKcW7CDZd8QEdvP9MX9kE39+PExM0g@mail.gmail.com>
 <CAB-d4A7xSQyLHhMZ51QWcUUXeajRfK8CLaD9CXpy3tg+B8J=JA@mail.gmail.com>
Message-ID: <CACbaDy6hX3N0aJ=AKya9J8H=8NQphjZ5Q29j1D7Gd2M6axSoKA@mail.gmail.com>

Thanks, I added my two cents to the ticket.

On Thu, Aug 3, 2017 at 12:37 PM, George Colpitts
<george.colpitts at gmail.com> wrote:
> I reported this in https://ghc.haskell.org/trac/ghc/ticket/13604
>
> On Thu, Aug 3, 2017 at 4:32 PM Evan Laforge <qdunkan at gmail.com> wrote:
>>
>> My program uses the GHC API to provide a REPL, and upgrading to 8.2.1
>> broke that... well, just made it really slow.  Where it used to
>> quickly load the compiled files, it now wants to recompile everything
>> as bytecode which makes 1s startup time go to 1m.  The reason was it
>> now thinks flags have changed.  I tracked it down to changes in
>> FlagChecker.hs, documented with
>> https://ghc.haskell.org/trac/ghc/ticket/11798 and
>> https://ghc.haskell.org/trac/ghc/ticket/10923, which add -fhpc and -O
>> to the tracked flags.  -fhpc means loading tests in ghci can never
>> work, because ghci rejects the -fhpc flag, and likewise -O means ghci
>> can never load optimized files for the same reason.
>>
>> It seems like the easiest solution might be to just have ghci not
>> reject -fhpc and -O.  Of course we could also revert those changes,
>> but they're justified in the trac tickets.
>>
>> Of course this means I'm loading optimized code together with bytecode
>> compiled code and maybe that's a bad thing (or for tests, -fhpc with
>> non-hpc).  But I've been doing this for something like 7 years and
>> it's been fine.
>>
>>
>> Unrelatedly, I was hoping compiles would get faster, but they seem a
>> bit slower, from around 3m20s to around 4m :(  I can track down
>> per-file timing changes if it would be interesting to someone.
>>
>> Also thanks to whoever put trac tickets in the comments, it makes it
>> really easy to find out why a change was made.
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

From capn.freako at gmail.com  Sun Aug 20 00:16:39 2017
From: capn.freako at gmail.com (David Banas)
Date: Sat, 19 Aug 2017 17:16:39 -0700
Subject: TH Show instance not working.
Message-ID: <648207E4-88FE-4AC0-B064-A56B171D26C5@gmail.com>

Hi all,

Does anyone know why this code:

module Language.P4.UtilTest where

import Language.P4.Util (mkShow)

data Dummy = Bogus    Char
           | Nonsense Int

$(mkShow ''Dummy)

is producing this error:

Davids-Air-2:P4 dbanas$ stack ghc -- UtilTest.hs -ddump-splices
[1 of 1] Compiling Language.P4.UtilTest ( UtilTest.hs, UtilTest.o )
UtilTest.hs:24:3-16: Splicing declarations
    mkShow ''Dummy
  ======>
    instance Show Dummy where
      show (Bogus x) = show x
      show (Nonsense x) = show x

UtilTest.hs:24:3: error:
    Conflicting definitions for ‘show’
    Bound at: UtilTest.hs:24:3-16
              UtilTest.hs:24:3-16
   |
24 | $(mkShow ''Dummy)
   |   ^^^^^^^^^^^^^^

?

The TH splice expansion looks correct to me.
If I comment out the second constructor (Nonsense Int), the code compiles without error.

Thanks,
-db

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20170819/fc484284/attachment.html>

From lysxia at gmail.com  Sun Aug 20 07:29:23 2017
From: lysxia at gmail.com (Li-yao Xia)
Date: Sun, 20 Aug 2017 09:29:23 +0200
Subject: TH Show instance not working.
In-Reply-To: <648207E4-88FE-4AC0-B064-A56B171D26C5@gmail.com>
References: <648207E4-88FE-4AC0-B064-A56B171D26C5@gmail.com>
Message-ID: <b45ab2b6-743d-1021-6306-b19d46677a2f@gmail.com>

Hi David,

mkShow is probably making two separate declarations for "show" ([FunD 
"show" _, FunD "show" _]) instead of one declaration with two clauses 
([FunD "show" [Clause ..., Clause ...]]).
Both pretty-print to the same text, but only the second one is actually 
valid. When there is only one constructor, both alternatives end up the 
same.

Li-yao

On 08/20/2017 02:16 AM, David Banas wrote:
> Hi all,
>
> Does anyone know why this code:
>
> module Language.P4.UtilTest where
>
> import Language.P4.Util (mkShow)
>
> data Dummy = Bogus    Char
>             | Nonsense Int
>
> $(mkShow ''Dummy)
>
> is producing this error:
>
> Davids-Air-2:P4 dbanas$ stack ghc -- UtilTest.hs -ddump-splices
> [1 of 1] Compiling Language.P4.UtilTest ( UtilTest.hs, UtilTest.o )
> UtilTest.hs:24:3-16: Splicing declarations
>      mkShow ''Dummy
>    ======>
>      instance Show Dummy where
>        show (Bogus x) = show x
>        show (Nonsense x) = show x
>
> UtilTest.hs:24:3: error:
>      Conflicting definitions for ‘show’
>      Bound at: UtilTest.hs:24:3-16
>                UtilTest.hs:24:3-16
>     |
> 24 | $(mkShow ''Dummy)
>     |   ^^^^^^^^^^^^^^
>
> ?
>
> The TH splice expansion looks correct to me.
> If I comment out the second constructor (Nonsense Int), the code compiles without error.
>
> Thanks,
> -db
>
>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users


From capn.freako at gmail.com  Sun Aug 20 11:13:47 2017
From: capn.freako at gmail.com (David Banas)
Date: Sun, 20 Aug 2017 04:13:47 -0700
Subject: TH Show instance not working.
In-Reply-To: <b45ab2b6-743d-1021-6306-b19d46677a2f@gmail.com>
References: <648207E4-88FE-4AC0-B064-A56B171D26C5@gmail.com>
 <b45ab2b6-743d-1021-6306-b19d46677a2f@gmail.com>
Message-ID: <43FBFDB3-24E3-4266-94E7-114697BEF46D@gmail.com>

Yep, that was it. Thanks, Li-yao!
-db

> On Aug 20, 2017, at 12:29 AM, Li-yao Xia <lysxia at gmail.com> wrote:
> 
> Hi David,
> 
> mkShow is probably making two separate declarations for "show" ([FunD "show" _, FunD "show" _]) instead of one declaration with two clauses ([FunD "show" [Clause ..., Clause ...]]).
> Both pretty-print to the same text, but only the second one is actually valid. When there is only one constructor, both alternatives end up the same.
> 
> Li-yao
> 
> On 08/20/2017 02:16 AM, David Banas wrote:
>> Hi all,
>> 
>> Does anyone know why this code:
>> 
>> module Language.P4.UtilTest where
>> 
>> import Language.P4.Util (mkShow)
>> 
>> data Dummy = Bogus    Char
>>            | Nonsense Int
>> 
>> $(mkShow ''Dummy)
>> 
>> is producing this error:
>> 
>> Davids-Air-2:P4 dbanas$ stack ghc -- UtilTest.hs -ddump-splices
>> [1 of 1] Compiling Language.P4.UtilTest ( UtilTest.hs, UtilTest.o )
>> UtilTest.hs:24:3-16: Splicing declarations
>>     mkShow ''Dummy
>>   ======>
>>     instance Show Dummy where
>>       show (Bogus x) = show x
>>       show (Nonsense x) = show x
>> 
>> UtilTest.hs:24:3: error:
>>     Conflicting definitions for ‘show’
>>     Bound at: UtilTest.hs:24:3-16
>>               UtilTest.hs:24:3-16
>>    |
>> 24 | $(mkShow ''Dummy)
>>    |   ^^^^^^^^^^^^^^
>> 
>> ?
>> 
>> The TH splice expansion looks correct to me.
>> If I comment out the second constructor (Nonsense Int), the code compiles without error.
>> 
>> Thanks,
>> -db
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> 


From gale at sefer.org  Wed Aug 30 15:34:05 2017
From: gale at sefer.org (Yitzchak Gale)
Date: Wed, 30 Aug 2017 18:34:05 +0300
Subject: How to get a heap visualization
Message-ID: <CAOrUaLbdLx8gygKNQ+_B=xia2FY2TLF5fqyEzNt7nhWc4zhK8A@mail.gmail.com>

I need a simple heap visualization for debugging purposes.
I'm using GHC 8.0.2 to compile a large and complex yesod-based
web app. What's the quickest and easiest way?

Vacuum looks simple and nice. But it has some long-outstanding
PRs against it to support GHC 7.10 and GHC 8.0 that were never
applied.

https://github.com/thoughtpolice/vacuum/issues/9

Getting ghc-vis to compile looks hopeless, for a number of reasons.
The dependencies on gtk and cairo are huge. It hasn't been updated
on Hackage for a year and a half. It requires base < 4.9. I need to run
the visualizer either on a headless Ubuntu 16.04 server, or locally on
Windows. And anyway, the fancy GUI in ghc-vis is way overkill for me.

The heap scraper backend for ghc-vis, ghc-heap-view, looks usable,
and better supported than vacuum. But is there a quick and simple
visualizer for its output, without ghc-vis?

Is there anything else? Is the best option to fork vacuum and and try
to apply the PRs?

From ezyang at mit.edu  Thu Aug 31 00:33:22 2017
From: ezyang at mit.edu (Edward Z. Yang)
Date: Wed, 30 Aug 2017 20:33:22 -0400
Subject: How to get a heap visualization
In-Reply-To: <CAOrUaLbdLx8gygKNQ+_B=xia2FY2TLF5fqyEzNt7nhWc4zhK8A@mail.gmail.com>
References: <CAOrUaLbdLx8gygKNQ+_B=xia2FY2TLF5fqyEzNt7nhWc4zhK8A@mail.gmail.com>
Message-ID: <1504139590-sup-1406@sabre>

Why not the plain old heap profiler?

Edward

Excerpts from Yitzchak Gale's message of 2017-08-30 18:34:05 +0300:
> I need a simple heap visualization for debugging purposes.
> I'm using GHC 8.0.2 to compile a large and complex yesod-based
> web app. What's the quickest and easiest way?
> 
> Vacuum looks simple and nice. But it has some long-outstanding
> PRs against it to support GHC 7.10 and GHC 8.0 that were never
> applied.
> 
> https://github.com/thoughtpolice/vacuum/issues/9
> 
> Getting ghc-vis to compile looks hopeless, for a number of reasons.
> The dependencies on gtk and cairo are huge. It hasn't been updated
> on Hackage for a year and a half. It requires base < 4.9. I need to run
> the visualizer either on a headless Ubuntu 16.04 server, or locally on
> Windows. And anyway, the fancy GUI in ghc-vis is way overkill for me.
> 
> The heap scraper backend for ghc-vis, ghc-heap-view, looks usable,
> and better supported than vacuum. But is there a quick and simple
> visualizer for its output, without ghc-vis?
> 
> Is there anything else? Is the best option to fork vacuum and and try
> to apply the PRs?

From gale at sefer.org  Thu Aug 31 15:09:57 2017
From: gale at sefer.org (Yitzchak Gale)
Date: Thu, 31 Aug 2017 18:09:57 +0300
Subject: How to get a heap visualization
In-Reply-To: <1504139590-sup-1406@sabre>
References: <CAOrUaLbdLx8gygKNQ+_B=xia2FY2TLF5fqyEzNt7nhWc4zhK8A@mail.gmail.com>
 <1504139590-sup-1406@sabre>
Message-ID: <CAOrUaLZs38SDNepq9DOtrr9i7idkUGtz0mEp=kMUg-vdPJchJA@mail.gmail.com>

I wrote:
>> I need a simple heap visualization for debugging purposes...
>> Vacuum... has some long-outstanding PRs against it...
>> that were never applied...
>> Getting ghc-vis to compile looks hopeless...
>> ghc-heap-view... is there a quick and simple
>> visualizer for its output, without ghc-vis?

Edward Z. Yang wrote:
> Why not the plain old heap profiler?

That didn't prove helpful in this case. We need to dive down
into the structure of certain large and complex objects to find
out what is happening.

My plan is to see if I can apply the vacuum PR manually locally
and see if I can get it working reasonably soon. If not, I guess
I'll try running ghc-heap-view without visualization and see if I
can make sense of the textual output.

Actually, the profiling was done by someone else, not me.
Now that you mention it, maybe I'll first give that another try
myself and see if I can get any farther.

Still, vacuum-style heap visualization is a really nice tool.
It's a shame that it has fallen into such a state of disrepair.

Thanks,
Yitz

From david.feuer at gmail.com  Thu Aug 31 15:34:50 2017
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 31 Aug 2017 11:34:50 -0400
Subject: How to get a heap visualization
In-Reply-To: <CAOrUaLZs38SDNepq9DOtrr9i7idkUGtz0mEp=kMUg-vdPJchJA@mail.gmail.com>
References: <CAOrUaLbdLx8gygKNQ+_B=xia2FY2TLF5fqyEzNt7nhWc4zhK8A@mail.gmail.com>
 <1504139590-sup-1406@sabre>
 <CAOrUaLZs38SDNepq9DOtrr9i7idkUGtz0mEp=kMUg-vdPJchJA@mail.gmail.com>
Message-ID: <CAMgWh9sWRJPq8bivBtC0UBq7hp=4OsS8yqxLczEi5YEUQYEtOA@mail.gmail.com>

Have you gotten in touch with Joachim? I think he's touched that space in
the not too murky past.

On Aug 31, 2017 11:18 AM, "Yitzchak Gale" <gale at sefer.org> wrote:

> I wrote:
> >> I need a simple heap visualization for debugging purposes...
> >> Vacuum... has some long-outstanding PRs against it...
> >> that were never applied...
> >> Getting ghc-vis to compile looks hopeless...
> >> ghc-heap-view... is there a quick and simple
> >> visualizer for its output, without ghc-vis?
>
> Edward Z. Yang wrote:
> > Why not the plain old heap profiler?
>
> That didn't prove helpful in this case. We need to dive down
> into the structure of certain large and complex objects to find
> out what is happening.
>
> My plan is to see if I can apply the vacuum PR manually locally
> and see if I can get it working reasonably soon. If not, I guess
> I'll try running ghc-heap-view without visualization and see if I
> can make sense of the textual output.
>
> Actually, the profiling was done by someone else, not me.
> Now that you mention it, maybe I'll first give that another try
> myself and see if I can get any farther.
>
> Still, vacuum-style heap visualization is a really nice tool.
> It's a shame that it has fallen into such a state of disrepair.
>
> Thanks,
> Yitz
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20170831/a6f2068d/attachment.html>