Re: BoxedRep UNPACK pragma

[Mikolaj Konarski]

On Sat, Aug 12, 2023 at 5:20 PM Brandon Allbery  wrote:
>
> The warning sounds correct to me: `Maybe` has two constructors?

It says at 
https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/pragmas.html#unpack-pragma

"Since 9.6.1, data types with multiple constructors can also be
unpacked, effectively transforming the field into an unboxed sum of
the unpackings of each constructor (see UnboxedSums)."

> On Sat, Aug 12, 2023 at 10:25 AM Alan & Kim Zimmerman
>  wrote:
> >
> > I have seen the following warning on master for some time
> >
> > compiler/GHC/Core/TyCon.hs:1540:5: warning:
> > • Ignoring unusable UNPACK pragma
> > on the first argument of ‘BoxedRep’
> > • In the definition of data constructor ‘BoxedRep’
> >   In the data type declaration for ‘PrimRep’
> >  |
> > 1540 |   | BoxedRep {-# UNPACK #-} !(Maybe Levity) -- ^ Boxed, heap value
> >  | ^^^
> >
> > Is it something that needs to be fixed? Can the code be updated to remove 
> > the warning?
> >
> > Alan
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
> --
> brandon s allbery kf8nh
> allber...@gmail.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 development asks too much of the host system

[Mikolaj Konarski]

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

Package https://hackage.haskell.org/package/hasktags does it all
for you automatically at buffer save IIRC. I don't even remember
how it works, because I've never had a problem in years.
OTOH, I use the same haskell-mode as 10 years ago, having
decided after a few botched upgrades that it's good enough.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Haddock needs help

[Mikolaj Konarski]

Talking as a Haskell user, but also a cabal maintainer:
the Haddock work Hécate describes is crucial for the health
and efficiency of the whole ecosystem and the sooner
we can start it, the less drag it's going to have on the rest.

Given that GHC expertise is not necessary for many
of the tasks involved, could we forward this message
to other media? I don't think there is shame in disclosing
technical debt (as opposed to hiding it) and I think the way
it's worded, it may be viewed as a challenge, not a turn-off.
Still, are there any suggestions on how to tweak the text
before an announcement on discourse, reddit, etc.?
Would, e.g., HF, like to chime in early in each of the ensuing
discussions? If so, how would we know where it gets posted to?

Cheers,
Mikolaj

On Thu, May 26, 2022 at 4:39 PM Hécate  wrote:
>
> Hi everyone,
>
> Haddock needs help.
>
> Since I joined the Haddock team to help triage the tickets and interact
> with the community, we lost all of our experts, and I didn't have time
> to level up quickly enough to handle the mass of incoming tickets, let
> alone actually reduce the number of tickets to number below two hundred.
>
> As things stand now, the Haddock code base is in a disastrous state,
> largely not understood and its CI is in shambles.
> There are things that we can improve on the short and longer term – see
> https://github.com/haskell/haddock/issues/1465 – but the greater lack of
> expertise means that any project involving some core business logic is
> bound to be utterly and unnecessarily painful. The Hi Haddock GSOC
> proposal, whilst fully implemented in GHC, cannot be brought in Haddock
> at this moment in a reasonable timeline without any help.
>
> At present time, I need:
>
> * People who can refactor the code base, following modern software
> engineering practices, like domain-driven design and test-driven
> development.
> * UI developers, proficient in CSS and web accessibility.
>
> If you feel like you fit some of these criteria, please do contact me at
> this address. If your company can spare some engineering hours for you
> to give a hand, you're most welcome to do so.
>
> Just so we are clear, I am immensely grateful to the people who have
> submitted fixes and patches these past months, but this situation is
> untenable.
>
> Hécate ✨
> : @TechnoEmpress
> IRC: Hecate
> WWW: https://glitchbra.in
> RUN: BSD
>
> ___
> 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: regression in ghc / cabal integration in 9.2.1

[Mikolaj Konarski]

Hi George,

Have you looked at the ticket I gave you? Here's one linked from it
mentioning the topic of ghc-pkg compatibility with v2-install:
https://github.com/haskell/cabal/issues/6508

I'm afraid we don't have any systematic exposition of cabal history
with rationale for its major changes, but there's a changelog and the
commit log. If you'd like to contribute something better, please do.

Why the difference between GHC versions, I don't know, or whether
upgrading your cabal would help (I doubt it). Regarding your workflow,
perhaps ask around or look up in cabal tickets how other people do
this now? I never run ghc directly, so I don't know.

Best,
Mikolaj

On Sat, Oct 30, 2021 at 9:44 PM Brandon Allbery  wrote:
>
> Wasn't there specifically a new cabal version released to deal with
> 9.2.1? 3.4.1.0 / 3.6.2.0?
>
> On Sat, Oct 30, 2021 at 3:24 PM George Colpitts
>  wrote:
> >
> > Thanks for the quick response Mikolaj. Sorry for the confusion, with cabal 
> > install I did use --lib but accidentally omitted that in my original email. 
> > In 9.0.1 this results in a successful compilation but in 9.2.1 it does not 
> > thus I believe this is a regression.
> >
> > Here's the output I got in 9.2.1:
> >
> > bash-3.2$ cabal install vector --lib
> > Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.4.0.0 supports
> > 'ghc' version < 9.1): /usr/local/bin/ghc is version 9.2.1
> > Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.4.0.0 supports
> > 'ghc' version < 9.1): /usr/local/bin/ghc is version 9.2.1
> > Resolving dependencies...
> > Up to date
> > bash-3.2$ ghc buggc.hs
> > [1 of 1] Compiling Main ( buggc.hs, buggc.o )
> >
> >
> > buggc.hs:2:1: error:
> > Could not find module ‘Data.Vector’
> > Perhaps you meant Data.Functor (from base-4.16.0.0)
> > Use -v (or `:set -v` in ghci) to see a list of the files searched for.
> >   |
> > 2 | import Data.Vector
> >
> >
> > However I did figure out a workaround: cabal v1-install.
> >
> > As far as I can tell cabal (v2-) install breaks ghc-pkg and compilation. 
> > With cabal (v2-) install the workaround for ghc-pkg is to add the option 
> > "-f $HOME/.cabal/store/ghc-9.2.1/package.db" to the end of the command 
> > "ghc-pkg list". For compilation the workaround is to add "-package-db 
> > $HOME/.cabal/store/ghc-9.2.1/package.db" to the ghc-pkg. I don't understand 
> > why it was necessary for  cabal v2-install to be incompatible with cabal 
> > v1-install. Is there a link to any documentation and justification for 
> > these incompatible changes?
> >
> > Thanks again,
> > George
> >
> >
> >
> > On Sat, Oct 30, 2021 at 3:38 PM Mikolaj Konarski  
> > wrote:
> >>
> >> Hi George,
> >>
> >> Since many versions of cabal, `install` only installs executables, not
> >> libraries, so if that worked for you, you must have had an old version
> >> of cabal.
> >>
> >> Please see https://github.com/haskell/cabal/issues/6481 for some
> >> context and to help you find a new workflow that works for you
> >> (ideally, a standard one).
> >>
> >> Kind regards,
> >> Mikolaj
> >>
> >> On Sat, Oct 30, 2021 at 5:40 PM George Colpitts
> >>  wrote:
> >> >
> >> > Thanks Ben!
> >> >
> >> > There seems to be a regression in ghc / cabal integration in 9.2.1.
> >> >
> >> > In 9.2.1 if I do
> >> >
> >> > cabal install vector
> >> >
> >> > Compilation of a file containing
> >> >
> >> >
> >> > import Data.Vector
> >> >
> >> >
> >> > main = undefined
> >> >
> >> >
> >> > fails with
> >> >
> >> >  Could not find module ‘Data.Vector’
> >> > Perhaps you meant Data.Functor (from base-4.16.0.0)
> >> > Use -v (or `:set -v` in ghci) to see a list of the files searched 
> >> > for.
> >> >   |
> >> > 2 | import Data.Vector
> >> >   | ^^
> >> >
> >> > The preceding works on ghc 9.0.1
> >> >
> >> > Should I file a bug against Cabal?
> >> >
> >> > Thanks
> >> > George
> >> >
> >> > On Fri, Oct 29, 2021 at 12:54 PM Ben Gamari  wrote:
> >> >>
> >> >> Hi all,
> >> >>
> >> >> The GHC developers are

Re: regression in ghc / cabal integration in 9.2.1

[Mikolaj Konarski]

Hi George,

Since many versions of cabal, `install` only installs executables, not
libraries, so if that worked for you, you must have had an old version
of cabal.

Please see https://github.com/haskell/cabal/issues/6481 for some
context and to help you find a new workflow that works for you
(ideally, a standard one).

Kind regards,
Mikolaj

On Sat, Oct 30, 2021 at 5:40 PM George Colpitts
 wrote:
>
> Thanks Ben!
>
> There seems to be a regression in ghc / cabal integration in 9.2.1.
>
> In 9.2.1 if I do
>
> cabal install vector
>
> Compilation of a file containing
>
>
> import Data.Vector
>
>
> main = undefined
>
>
> fails with
>
>  Could not find module ‘Data.Vector’
> Perhaps you meant Data.Functor (from base-4.16.0.0)
> Use -v (or `:set -v` in ghci) to see a list of the files searched for.
>   |
> 2 | import Data.Vector
>   | ^^
>
> The preceding works on ghc 9.0.1
>
> Should I file a bug against Cabal?
>
> Thanks
> George
>
> On Fri, Oct 29, 2021 at 12:54 PM Ben Gamari  wrote:
>>
>> Hi all,
>>
>> The GHC developers are very happy to at long last announce the
>> availability of GHC 9.2.1. Binary distributions, source distributions,
>> and documentation are available at
>>
>> https://downloads.haskell.org/ghc/9.2.1
>>
>> GHC 9.2 brings a number of exciting features including:
>>
>>  * A native code generation backend for AArch64, significantly speeding
>>compilation time on ARM platforms like the Apple M1.
>>
>>  * Many changes in the area of records, including the new
>>`RecordDotSyntax` and `NoFieldSelectors` language extensions, as well
>>as Support for `DuplicateRecordFields` with `PatternSynonyms`.
>>
>>  * Introduction of the new `GHC2021` language extension set, giving
>>users convenient access to a larger set of language extensions which
>>have been long considered stable.
>>
>>  * Merging of `ghc-exactprint` into the GHC tree, providing
>>infrastructure for source-to-source program rewriting out-of-the-box.
>>
>>  * Introduction of a `BoxedRep` `RuntimeRep`, allowing for polymorphism
>>over levity of boxed objects (#17526)
>>
>>  * Implementation of the `UnliftedDataTypes` extension, allowing users
>>to define types which do not admit lazy evaluation ([proposal])
>>
>>  * The new [`-hi` profiling] mechanism which provides significantly
>>improved insight into thunk leaks.
>>
>>  * Support for the `ghc-debug` out-of-process heap inspection library
>>[ghc-debug]
>>
>>  * Significant improvements in the bytecode interpreter, allowing more
>>programs to be efficently run in GHCi and Template Haskell splices.
>>
>>  * Support for profiling of pinned objects with the cost-centre profiler
>>(#7275)
>>
>>  * Faster compilation and a smaller memory footprint
>>
>>  * Introduction of Haddock documentation support in TemplateHaskell (#5467)
>>
>> Finally, thank you to Microsoft Research, 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.
>> Moreover, this release would not have been possible without the hundreds
>> of open-source contributors whose work comprise this release.
>>
>> As always, do open a [ticket] if you see anything amiss.
>>
>> Happy testing,
>>
>> - Ben
>>
>>
>> [apple-m1]: https://www.haskell.org/ghc/blog/20210309-apple-m1-story.html
>> [proposal]: 
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-unlifted-datatypes.rst
>> [-hi profiling]: 
>> https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/
>> [ghc-debug]: http://ghc.gitlab.haskell.org/ghc-debug/
>> [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
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC | Some refactoring in tcInferApps (!116)

[Mikolaj Konarski]

Richard, what you propose totally makes sense to me.

Simon, Sylvain, indeed, when I click "toggle comments for this file"
in the first patch, I can see not only an avatar, but the whole comment.
However, this is only one comment, in both diffs, out of many,
which adds to the confusion. May it be caused by new changes
invalidating old comments? That's an orthogonal issue, which I remember
being quite annoying on github.

Also, with "toggle comments for this file" unmarked (it's really hard to tell
what the state of that button is), I can see the tiny avatar and, for me,
just clicking on it reveals the full comment.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC | Some refactoring in tcInferApps (!116)

[Mikolaj Konarski]

On Mon, Jan 14, 2019 at 10:28 AM Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:
>
> I suppose we could issue guidance NEVER to resolve a discussion, but that
seems like the wrong conclusion.

It seems gitlab's "resolve discussion" action is supposed to mean
"I think nobody needs to look at these comments (in detail) any more".

So if somebody addressed your comment, he should probably
ping you with "this comment addressed", then you look at the comment,
at the old diff, at the new diff (no idea how easy it is to switch between
the old and new diffs) and then *you* resolve the discussion, if satisfied.
And if somebody resolves discussion prematurely, you unresolve it
with the button or checkbox, meaning "actually, I'd like to have
one more close look before the discussion is hidden forever".
You can even add an unresolve comment explaining why you think
the additional look is needed after all.

All this is quite troublesome if there is a lot of comments
and they need to be pinged about, resolved and unresolved
in bulk (unless I'm missing some bulk button).
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC | Some refactoring in tcInferApps (!116)

[Mikolaj Konarski]

> Yes, in the discussion tab I can.  But of course that is out of context; you 
> just get a little (non-expandable) snippet.

I lack the gitlab experience to push this any further, but I guess
an "unresolve discussion" button/checkbox would at least be
a stop-gap measure. I couldn't see such a button on the page,
probably because I don't have the required permissions for this MR.
However, the video in the ticket below (and lots of noise
elsewhere on the net) suggests such a button might exists.
Ben, or anybody, do you know anything more about that?

https://gitlab.com/gitlab-org/gitlab-ce/issues/53930
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC | Some refactoring in tcInferApps (!116)

[Mikolaj Konarski]

> Looking here
> https://gitlab.haskell.org/ghc/ghc/merge_requests/116//diffs
> I see literally NO discussions with a "toggle discussion" button.  Indeed if 
> I search for "toggle" I get no hits.

Oh, I see, you are right with respect to the link you cited now.
None of the buttons help, just as you say. I have
to navigate back from the "Changes" to the "Discussion" tab,
which gets me to the link you gave initially
(https://gitlab.haskell.org/ghc/ghc/merge_requests/116)
where the discussions are available, but I can't see them
in the context of the whole diff and none of the buttons
there let me extend the view of the diff. That's quite suboptimal.

Could you confirm that at

https://gitlab.haskell.org/ghc/ghc/merge_requests/116

(without the 'diff' at the end) you can see the collapsed discussion items?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC | Some refactoring in tcInferApps (!116)

[Mikolaj Konarski]

> Either way, I can’t see any comments whatsoever!  It says 5/5 discussions 
> resolved, but I can’t actually see them.  There is not “toggle discussion” 
> button anywhere.

Hello Simon,

Just below "5/5 discussions resolved" I can see 5 discussions
with “toggle discussion” link to the right of each one.
Is that what you can't see, or do mean a single button
that toggles all resolved discussions (I can't see any)?
Or do you mean a button that un-resolves them permanently
(neither can I see one)?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [Q] Inlining done: evtRead

[Mikolaj Konarski]

On Tue, Jan 8, 2019 at 2:10 AM Gabor Greif  wrote:
>
> Hmm, yes. So why wasn't GHC 8.4 doing this? Did some commit fix the
> inliner to respect the pragma?

Yes:
https://gitlab.haskell.org/ghc/ghc/commit/b9b1f99954e69f23e9647d00e048938d5509ec14

But it's not on 8.6 branch (yet?).
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: End of Windows Vista support in GHC-8.6?

[Mikolaj Konarski]

On Wed, Mar 7, 2018 at 8:10 AM, Phyx  wrote:
> In my experience to get a 32 bit build you need to
> install the full 32bit msys2. Not just the 32bit compiler in the 64 bit
> msys2 (two installs can co-exist).

That's also my experience on appveyor (but I'm not compiling GHC itself):

https://github.com/LambdaHack/LambdaHack/blob/master/appveyor.yml#L50

Both versions of msys2 are present and I need to set path to the 32 version
to compile for 32bit. In this way I'm able to generate both 64bit
and 32bit binaries in a single appveyor run.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Performance degradation when factoring out common code

[Mikolaj Konarski]

Hello,

I've had a similar problem that's been fixed in 8.2.1:

https://ghc.haskell.org/trac/ghc/ticket/12603

You can also use some extreme global flags, such as

ghc-options: -fexpose-all-unfoldings -fspecialise-aggressively

to get most the GHC subtlety and shyness out of the way
when experimenting.

Good luck
Mikolaj



On Fri, Sep 8, 2017 at 11:21 AM, Harendra Kumar
 wrote:
> Hi,
>
> I have this code snippet for the bind implementation of a Monad:
>
> AsyncT m >>= f = AsyncT $ \_ stp yld ->
> let run x = (runAsyncT x) Nothing stp yld
> yield a _ Nothing  = run $ f a
> yield a _ (Just r) = run $ f a <> (r >>= f)
> in m Nothing stp yield
>
> I want to have multiple versions of this implementation parameterized by a
> function, like this:
>
> bindWith k (AsyncT m) f = AsyncT $ \_ stp yld ->
> let run x = (runAsyncT x) Nothing stp yld
> yield a _ Nothing  = run $ f a
> yield a _ (Just r) = run $ f a `k` (bindWith k r f)
> in m Nothing stp yield
>
> And then the bind function becomes:
>
> (>>=) = bindWith (<>)
>
> But this leads to a performance degradation of more than 10%. inlining does
> not help, I tried INLINE pragma as well as the "inline" GHC builtin. I
> thought this should be a more or less straightforward replacement making the
> second version equivalent to the first one. But apparently there is
> something going on here that makes it perform worse.
>
> I did not look at the core, stg or asm yet. Hoping someone can quickly
> comment on it. Any ideas why is it so? Can this be worked around somehow?
>
> 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: SPECIALISE INLINE pragma

[Mikolaj Konarski]

> GHC tries hard NOT to choose an INLINE function as a loop breaker.  But if 
> you write
>
> f x = if ... then 0 else (f x')
> {-# INLINE f #-}
>
> then the only possible loop breaker is 'f', so GHC has to choose it.

Indeed.

> What else would you suggest?

A warning would be very welcome. Given that the debugging
compiler emits one, perhaps it's not too difficult to add.

Apart of that, if the heuristics is based not on INLINE pragmas,
but on available unfoldings, as Matthew suggests in his wiki article,
I'd propose to fix that, see the case below.

> What puzzling behaviour do you have in mind?

I can't reconstruct it now, but I was profiling as set of mutually
recursive functions, with -fexpose-all-unfoldings (so GHC could not
decide based on available unfoldings) and INLINE on only some
of them (I don't remember if the others had NOINLINE or nothing).
I had an impression some of the INLINEs where ignored and that
the loop breaker was not at the place I was forcing, but the impression
was based only on comparison of runtimes of different variants,
not on inspecting core. A warning would really help next time
to let me catch a concrete example to post.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: SPECIALISE INLINE pragma

[Mikolaj Konarski]

> On the same topic, I also wrote a blog post simply explaining the
> essential things to know
> about the inliner and specialiser as I don't think they are generally
> appreciated. Comments welcome!
>
> http://mpickering.github.io/posts/2017-03-20-inlining-and-specialisation.html

LGTM. I'd propose to link to this from GHC manual.

I didn't know the bit about INLINE being ignored
on a loop-breaker with no warning and no way of changing
the loop-breaker. That probably explains puzzling
and counter-intuitive results of some alternative layouts
of INLINEs in the computation-intensive parts of my code,
at least since the time I provide unfoldings for all functions
and so discounts don't help GHC in picking the intended loop-breaker.
And I don't think this ignoring of the programmer's intent
wrt INLINE is documented in the usual places.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Early inline

[Mikolaj Konarski]

Yay! Is that related to the following ("I also want to investigate
making INLINE pragmas fire in the "gentle" phase, on the grounds
that that's what the programmer said.")?

https://ghc.haskell.org/trac/ghc/ticket/12603#comment:30



On Fri, Feb 17, 2017 at 5:41 PM, Simon Peyton Jones via ghc-devs
 wrote:
> Ben, David, Reid
>
> I have been working for months (on and off, mostly off, but very ON for the
> last week or two) on a very simple idea: the simplifier should inline things
> even in the “gentle” phase.
>
> It seems so simple.  And it is: the key patch is tiny.
>
> But it stressed corners of the optimiser that were not stressed before; and
> digging into it showed opportunities I did not know about before.
>
> So I  have ended up a with a whole series of patches, which are on
> wip/spj-early-inline branch
>
> 7f14d15c0e5fc2c9a81db3d0f0b01d85857b1d87 Error message wibbles accumulated
> from the preceding patches
>
> 0499c65d9fa45e7879e1e1264fdaa15274adcba6 Improve SetLevels for join points
>
> 3b2fc0827ff6cafa34836c2d9dc710b628c990b6 Change -ddump-tc-trace output in
> TcErrors, slightly
>
> 9ffdf62b0ca72c4f35579f9d6f31a9beebf23025 Improve pretty-printing of types
>
> 3f346eac06399a79adf48425018ee949cee245bf Add VarSet.anyDVarSet, allDVarSet
>
> 912e71eb3b4ec91e805ecf2236d1033e55e2933a The Early Inline Patch
>
> 7188cd13f8e54efa764d52ca016b87b3669b29f5 Small changes to expression sizing
> in CoreUnfold
>
> bfc6fa3f377d11bdfcdbf82b65bf2f39cb00b90c Fix SetLevels for makeStaticPtr
>
> 8b1cfea089faacb5b95ffcc3511e05faeabb8076 Extend CSE to handle recursive
> bindings
>
> 50411995641802568bb27c867afe804f91e0524c Combine identical case alterantives
> in CSE
>
> 2e077ccc736a0b2a622b7f42b7929966bddb4ded Inline data constructor wrappers in
> phase 2 only
>
> b868de53dd19f639c1070089ecff21948ff33e0d Make Specialise work with casts
>
> c767ae5f04a09ef71dcb8f67a17225a52c2cc5d2 Stop uniques ending up in SPEC rule
> names
>
> b49ed1f0102f93ca7f62632c436b41bd240b501f Occurrence-analyse the result of
> rule firings
>
> 607a735dfb99bb8f0edf466ccb01e732218c42ec Add -fspec-constr-keen
>
> 67a0c1872c0515f1f12ea68097a84e02da92f45b Refactor floating of bindings
> (fiBind)
>
> e90f4d7c6d3003039fa1647a3da3dafcaa75527b More tracing in SpecConstr
>
>
>
> Much to my surprise, we get some jolly nice improvements in compiler perf:
>
> 3%   perf/compiler/T5837.runT5837 [stat too good] (normal)
>
> 7%   perf/compiler/parsing001.run   parsing001 [stat too good] (normal)
>
> 9%   perf/compiler/T12234.run   T12234 [stat too good] (optasm)
>
> 35%  perf/compiler/T9020.runT9020 [stat too good] (optasm)
>
> 9%   perf/compiler/T3064.runT3064 [stat too good] (normal)
>
> 13%  perf/compiler/T9961.runT9961 [stat too good] (normal)
>
> 20%  perf/compiler/T13056.run   T13056 [stat too good] (optasm)
>
> 5%   perf/compiler/T9872d.run   T9872d [stat too good] (normal)
>
> 5%   perf/compiler/T9872c.run   T9872c [stat too good] (normal)
>
> 5%   perf/compiler/T9872b.run   T9872b [stat too good] (normal)
>
> 7%   perf/compiler/T9872a.run   T9872a [stat too good] (normal)
>
> 5%   perf/compiler/T783.run T783 [stat too good] (normal)
>
> 35%   perf/compiler/T12227.run   T12227 [stat too good] (normal)
>
> 20%   perf/compiler/T1969.runT1969 [stat too good] (normal)
>
> 5%   perf/should_run/lazy-bs-alloc.run  lazy-bs-alloc [stat too good]
> (normal)
>
> 5%   perf/compiler/T12707.run T12707 [stat too good] (normal)
>
>
>
> 4%   perf/compiler/T3294.runT3294 [stat too good] (normal)
>
> 1.5% perf/space_leaks/T4029.run T4029 [stat too good] (ghci)
>
>
>
> So what is left?  I have sunk so much time into this and am still not QUITE
> out of the woods.   I was left with
>
> Unexpected failures:
>
>codeGen/should_compile/debug.run  debug [bad stdout] (normal)
>
>concurrent/should_run/T4030.run   T4030 [bad exit code]
> (normal)
>
> I’m re-validating having pulled from HEAD, but I THINK that’s all.
>
> Now
>
> · I don’t know how to Phab these individually
>
> · I have not sweated through which patch is responsible for which
> perf improvments.  Maybe Gipeda can tell?
>
> · I have not put each error message change with the correct patch.
> I don’t know how much that matters.
>
> So this is to say: anything you guys can do to help get this actually Done
> would be really helpful.   I’m out of time till Monday at least.
>
> It would be great to collect those performance improvements!
>
> 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: Resolving Windows 64-bit linker issues

[Mikolaj Konarski]

Resending, since Roman's and Kyril's email addresses were mangled/missing.

On Mon, Feb 16, 2015 at 3:43 PM, Simon Peyton Jones
simo...@microsoft.com wrote:
 Darren



 Excellent!  We have a Windows Task Force, consisting roughly of the folk in
 cc.  So they would be the first group to ask.



 (I think it would be very helpful to have a Windows Task Force home page, so
 that it’s easier to find the group.)



 thanks for helping with Windows.



 Simon



 From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Darren
 Grant
 Sent: 15 February 2015 07:36
 To: ghc-devs@haskell.org
 Subject: Resolving Windows 64-bit linker issues



 Hi all,



 I notice there are a series of related long-standing issues subject to
 particular cygwin64 quirks, and I'd like to offer time to help resolve these
 if possible

 At this point I've had some exposure to the GHC build process (7.8.3), and
 have poked around the GHC linker to gain some low level insight.



 Would anyone be available to fill me in on the current state of affairs with
 mingw64 GHCi linking? For instance, is there ongoing work, or perhaps a
 preferred direction but no available developer bandwidth to proceed?



 Thank you.



 Cheers,

 Darren


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

Re: T9938 and T9939 failing

[Mikolaj Konarski]

This looks like the result of the new cool patch by SPJ
that detects redundant constraints.
IIRC, it was supposed to be added to -Wall, but disabled
for validate, at least for packages out of our control.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Program runs out of memory using GHC 7.6.3

[Mikolaj Konarski]

tt may be that GHC 7.8 optimizes the program better.
Compile with -O0 and see if it runs out of memory, too.
If so, you can just optimize the program by hand.
I'd suggest making a heap profilie with -O0 or in GHC 7.6
and finding out where the memory goes.

Of course, it's possible you've hit a compiler bug,
but it makes sense not to start with that assumption.

Have fun,
Mikolaj

On Sat, Dec 13, 2014 at 10:06 AM, David Spies dnsp...@gmail.com wrote:
 I have a program I submitted for a Kattis problem:
 https://open.kattis.com/problems/digicomp2
 But I got memory limit exceeded.  I downloaded the test data and ran the
 program on my own computer without problems.  Eventually I found out that
 when compiling with GHC 7.6.3 (the version Kattis uses) rather than 7.8.3,
 this program runs out of memory.
 Can someone explain why it only works on the later compiler?  Is there a
 workaround so that I can submit to Kattis?

 Thanks,
 David


 ___
 ghc-devs mailing list
 ghc-devs@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1

[Mikolaj Konarski]

OK. In that case, let's remember to get *that* version of cabal into 7.8.4.


/me conditions himself with chocolate to help the remembering

On Sat, Dec 13, 2014 at 11:02 PM, Thomas Tuegel ttue...@gmail.com wrote:
 On Sat, Dec 13, 2014 at 3:56 PM, Mikolaj Konarski
 miko...@well-typed.com wrote:
 On Sat, Dec 13, 2014 at 8:53 PM, Carter Schonwald
 carter.schonw...@gmail.com wrote:
 Thomas and I have found some bugs in HPC on OSX, and we're in the midst of
 tracking those down,

 You mean these are regressions? If they are introduced
 in one of the non-blocker fixes in 7.8.4, we can probably
 just revert them. Anyway, thanks a lot for testing.

 Sorry, these are not regressions. It's really a bug in Cabal which
 will be fixed in 1.22. When Carter wrote this, we thought the problem
 was with the GHC side of HPC because of some very vague error
 messages.

 --
 Thomas Tuegel

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Can't compile GHC-7.8.3 from git, fails on haskell98 library

[Mikolaj Konarski]

I've brought back the old section about fingerprint.py for 7.8.*
to the GettingTheSources wiki page, updated it, to the best
of my knowledge, and added the info from the email below.
Please correct the section if I mixed up anything. I think,
for as long as 7.8.* is in widespread use, the section has to stay,
even though it's irrelevant for 7.10.

https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources#Trackingthefullrepositorystatepre-March2014e.g.the7.8.branches

On Sun, Nov 2, 2014 at 5:02 PM, Herbert Valerio Riedel
hvrie...@gmail.com wrote:
 Hello Gergo,

 On 2014-11-02 at 14:29:06 +0100, Dr. ERDI Gergo wrote:
 On Sun, 2 Nov 2014, Dr. ERDI Gergo wrote:

 On a completely clean clone, I've checked out the tag
 ghc-7.8.3-release, ran sync-all get, boot, and configure, but the
 build fails on haskell98. Any ideas what I could be doing wrong?

 I've worked around this by manually checking out the 'ghc-7.8' branch
 of various submodules until I got it to work (I think the ones I
 needed to change were dph, haskell98, haskell2010, template-haskell,
 and haddock, but I'm not sure). It seems the `ghc-7.8.3-release` tag
 is in a horrible shape in terms of reproducable building of imported
 repos. Is anyone looking into fixing this?

 Starting with GHC 7.8.x, fingerprints are written into
 annotated  gpg-signed release tags:

   http://git.haskell.org/ghc.git/tag/refs/tags/ghc-7.8.3-release

 That way you're able to restore via the fingerprint for a given release
 via:

  ./utils/fingerprint/fingerprint.py restore -f (git show ghc-7.8.3-release | 
 grep -F '|')

 I'm just surprised I couldn't find that described anywhere in the wiki,
 I was sure it was written down somewhere...

 hth,
   hvr
 ___
 ghc-devs mailing list
 ghc-devs@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Can't compile GHC-7.8.3 from git, fails on haskell98 library

[Mikolaj Konarski]

 Starting with GHC 7.8.x, fingerprints are written into
 annotated  gpg-signed release tags:

   http://git.haskell.org/ghc.git/tag/refs/tags/ghc-7.8.3-release

 That way you're able to restore via the fingerprint for a given release
 via:

  ./utils/fingerprint/fingerprint.py restore -f (git show ghc-7.8.3-release | 
 grep -F '|')

 I'm just surprised I couldn't find that described anywhere in the wiki,
 I was sure it was written down somewhere...

Oh, pretty useful. I also couldn't find it on the wiki and this page

https://ghc.haskell.org/trac/ghc/wiki/GitRepoReorganization

even claims it's going to be obsolete (starting with 7.10?).

Google shows that something related was mentioned in

https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources?version=93

but the new version of the page missed that info.

This emails refers to the no-longer available info on the wiki, too:

https://www.haskell.org/pipermail/ghc-devs/2014-January/003930.html

I wonder what happened and which info is meaningful only
for GHC  7.8 or even ==7.8 and which parts make sense
for 7.10 as well.

Cheers,
Mikolaj
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: git question

[Mikolaj Konarski]

 Now I want to rebase to clean up.  Can I just do a local rebase and then git
 push?  Nothing special about the push?

You need 'push -f' to force overwriting the old version
of your branch. Please make sure you are not forcefully
pushing while on master branch, though. ;)
(I seem to remember 'push -f' can be blocked on master,
but I don't know if it is in our repo.)

 I know that will confuse anyone who is pulling from that branch, but I’ve
 warned them!

If they do 'git fetch', they can compare the old and the new version
of the branch and mix and match at will.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: git question

[Mikolaj Konarski]

 Right!  I'm on branch wip/new-flatten-skolems-Oct14, so
 git push --force
 should push just that branch right?

Right. But don't trust me, try with --dry-run.

 If I want to be super-safe, and say push only this branch would I say

 git push --force HEAD
 or
 git push --force wip/new-flatten-skolems-Oct14
 or something like that?

The latter seems safest. Probably

git push --force origin wip/new-flatten-skolems-Oct14

would work, depending on how your remotes are named.
Again, --dry-run. :)
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: RFC: Properly stated origin of code contributions

[Mikolaj Konarski]

 The current situation is suboptimal, as it's unclear where the threshold
 for adding yourself as an author to a module header is
 (whitespace/indentation cleanups, fixing/writing docs, removing lines,
 adding a 5-line function in a 500 line module, ...?), and it's a bit
 unfair to those that have contributed far more to a module but haven't
 bothered to add themselves to the module header.

For these reasons, and due to the power of git and Phab, I think,
author annotations in module headers do not fulfill their original
purpose particularly well any more. Neither the purpose of stating who
is responsible/interested in a code fragment, nor the purpose
of giving people credit. Could we get rid of them? The annotations
already in the code would stay in git history and any future authors
are recorded in git and Phab messages. We just need to make sure
to mention original authors in git commit messages, if for whatever
reason the original commit creator git metadata would be lost
(or manually revert the loss of info via git options).

BTW, this relates to the pseudonymous contributions discussion.
The git/Phab history only helps to the extent that people identify
themselves. One less place with one less version of contributor
names/pseudonyms should actually help accounting for all
contributors on the wiki, in .cabal, etc., for the purpose of giving
public credit, for legal reasons, etc.

Best,
Mikolaj
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: git question

[Mikolaj Konarski]

On Fri, Oct 31, 2014 at 12:37 PM, Daniel Trstenjak
daniel.trsten...@gmail.com wrote:
 To ensure, that you're only operating on your current branch you can
 add to your '~/.gitconfig':

 [push]
default = simple

Oh, useful.

  (I seem to remember 'push -f' can be blocked on master,
  but I don't know if it is in our repo.)

Herbert tells me that actually 'push -f' (aka non-fast-forwards)
is forbidden in the GHC repo everywhere except wip/,
as part of a configuration that also restricts touching
named GHC version branches, handles mirroring, etc.
So it's harder to mess up a repo that in ye olde days,
though I'm sure one can still produce lots of colourful git art
(to be watched in the 'gitk' art viewer) by repeatedly merging
forward and backward two branches, without any rebasing.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: cabal error: http://hackage.haskell.org/packages/archive/00-index.tar.gz : ErrorMisc Error HTTP code: 502

[Mikolaj Konarski]

Yes, unfortunatley, hackage was down. See

https://status.haskell.org/

I think it's being brought up right now by our fearless
volunteer infrastructure rapid response team (they are drafting!).
Please try again.

On Fri, Oct 31, 2014 at 8:45 PM, George Colpitts
george.colpi...@gmail.com wrote:
 When I type

 cabal update

 I get

 http://hackage.haskell.org/packages/archive/00-index.tar.gz : ErrorMisc
 Error
 HTTP code: 502


 Anybody else seeing this?


 Thanks
 George


 ___
 ghc-devs mailing list
 ghc-devs@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Tentative high-level plans for 7.10.1

[Mikolaj Konarski]

 Our intent has always been that that the latest version on each branch is 
 solid.  There have been one or two occasions when we have knowingly abandoned 
 a dodgy release branch entirely, but not many.

Perhaps we could do the opposite. Announce beforehand that
a release branch X is going to be LTS (of Very Stable Release;
roughly 1 in 4 branches?) and so very few major new features
will be included in the release X+1 (there is just not enough
time for both, as Austin explained).
Then, on the GHC maintainers' side, put off accepting any
I rewrote the compiler commits into HEAD for long time.
On the community side, focus on bug fixes and non-disruptive,
incremental improvements. Avoid API changes, whatever that means.
Update release X many times, until very stable.

A more radical proposal would be to do the above, but announce
that X+! is going to be Very Stable Release and accept no major
new features into HEAD at all and even revert any minor new
features just before X+1 release, if non-trivial bugs in them are discovered.
Then release X can be abandoned quickly, knowing that X+! will most
probably resolve any problems in X, without introducing new ones.

In either case, the main point is the announcement and so the
focus of the community on bug-fixing and keeping HEAD close
to the named releases, to make bug-fixing and back- and forward-
porting easy.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

win32 GHC 7.8.3 works under Wine and i386-linux GHC 7.8.3 works under amd64-linux

[Mikolaj Konarski]

Well, sorf-of. A few extra unobvious parameters and workarounds
are required in each case, but it's doable, (arguably) simpler
than real cross-compilation and already exhibits problems
that real cross-compilation may in some circumstances face.

Wiki pages (kudos to all previous authors):

http://www.haskell.org/haskellwiki/GHC_under_Wine

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


Examples of both kinds of binaries, for a project with gtk2hs and TH dependency:

https://github.com/LambdaHack/LambdaHack/releases/tag/v0.4.99.0


Please share your success reports here or on the wiki and let's exchange
ideas, file concrete tickets and propose patches to make the two processes
more accessible. Some tickets are mentioned in the wikis or can be traced
from there, but there may be others I'm not aware of, so let's link them
where appropriate.

Hope this helps somebody,
Mikolaj
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: win32 GHC 7.8.3 works under Wine and i386-linux GHC 7.8.3 works under amd64-linux

[Mikolaj Konarski]

(cross-com^H^H^Hposting to glasgow-haskell-us...@haskell.org)

Well, sorf-of. A few extra unobvious parameters and workarounds
are required in each case, but it's doable, (arguably) simpler
than real cross-compilation and already exhibits problems
that real cross-compilation may in some circumstances face.

Wiki pages (kudos to all previous authors):

http://www.haskell.org/haskellwiki/GHC_under_Wine

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


Examples of both kinds of binaries, for a project with gtk2hs and TH dependency:

https://github.com/LambdaHack/LambdaHack/releases/tag/v0.4.99.0


Please share your success reports here or on the wiki and let's exchange
ideas, file concrete tickets and propose patches to make the two processes
more accessible. Some tickets are mentioned in the wikis or can be traced
from there, but there may be others I'm not aware of, so let's link them
where appropriate.

Hope this helps somebody,
Mikolaj
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: slow Trac

[Mikolaj Konarski]

 status.haskell.org

Yay, that's neat.

 I'll keep everyone posted

Thank you, Austin.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Can't install 32-bit ghc-7.8.1 on 64-bit xubuntu 14.04

[Mikolaj Konarski]

The installation (and using the 32bit GHC on a 64bit Linux, to an extent)
should now be possible, as described at

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


On Fri, Apr 11, 2014 at 08:58:51AM -0500, Austin Seipp wrote:
 Kyrill,

 I think that at the moment, you can't really install a 32-bit GHC on a
 64-bit platform. I've actually had a few reports 'in the wild' about
 there being problems with this, but I'm not sure if there's actually
 an official ticket regarding it. We should dig one up or file one if
 there isn't.

 In theory I see no reason why this should not be doable, but I can't
 imagine off the top of my head what might really be going wrong.

 Simon, do you perhaps have an idea? Or have you heard of this/tried it maybe?

 On Fri, Apr 11, 2014 at 8:17 AM, kyra ky...@mail.ru wrote:
  Sorry for flood, but it turned out the problem remains. My previous message
  was a mistake.
  Now I've removed all GHC installations from paths but this does not help.
  Did anybody successfully install 32-bit ghc-7.8.1 on 64-bit linux?
 
  Regards,
  Kyra
 
 
  On 4/11/2014 16:50, kyra wrote:
 
  Don't bother. That was a usual 32/64-bit mess when installer picked up
  something from 64-bit ghc, which was in a path.
 
  Cheers,
  Kyra
 
  On 4/11/2014 15:00, kyra wrote:
 
  ia32-libs is absent on modern Ubuntus.
 
  But if anyone is interested installing lib32ncurses5 and libgmp10:i386
  did the 'configure' trick.
 
  But now 'make install' fails with:
  utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist register
  libraries/ghc-prim dist-install
  /home/awson/data/ghc-7.8.1-i386/lib/ghc-7.8.1/bin/ghc
  /home/awson/data/ghc-7.8.1-i386/lib/ghc-7.8.1/bin/ghc-pkg
  /home/awson/data/ghc-7.8.1-i386/lib/ghc-7.8.1 ''
  '/home/awson/data/ghc-7.8.1-i386'
  '/home/awson/data/ghc-7.8.1-i386/lib/ghc-7.8.1'
  '/home/awson/data/ghc-7.8.1-i386/share/doc/ghc/html/libraries' NO
  ghc-cabal: Bad interface file: dist-install/build/GHC/CString.hi
  magic number mismatch: old/corrupt interface file? (wanted 33214052, got
  129742)
 
  Kyra
 
 
  ___
  ghc-devs mailing list
  ghc-devs@haskell.org
  http://www.haskell.org/mailman/listinfo/ghc-devs
 
 
  ___
  ghc-devs mailing list
  ghc-devs@haskell.org
  http://www.haskell.org/mailman/listinfo/ghc-devs
 



 --
 Regards,

 Austin Seipp, Haskell Consultant
 Well-Typed LLP, http://www.well-typed.com/

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs