Re: a better workflow?

[Jan Stolarek]

Hi Richard,

I think it's been around two years since I last built GHC, but back in the days 
I could get a full 
build time around 17 minutes on my laptop. Not sure how much the build times 
have increased since 
then but I suspect you should be able to build GHC faster than in 45 minutes. 
The trick I used 
wasn't really much of a trick, it was simply about having good hardware: an SSD 
drive, a good CPU 
(I have Xeon), and lots of RAM. And then I had:

1. several separate source trees. This means being able to work on your own 
stuff in one source 
tree and being able to review MRs in another without a need to do a full 
rebuild when you want to 
switch between the two (or more). Downside of this setup was when you wanted to 
bootstrap from 
different GHC versions in different source trees, but with enough scripting 
this is definitely 
doable.

2. build trees separated from the source trees. If I really wanted to squeeze 
max performance I 
would map the build tree onto a ramdisk - that's why you want lots of RAM. It 
definitely made the 
build faster but I can't recall how much it improved the testsuite runs. The 
downside of course 
is that you lose the build when you switch off your machine, so I simply 
wouldn't switch off 
mine, only suspend it to RAM.

Janek

PS. A friend of mine recently told me that his company was considering using 
AWS but after 
calculating the costs it turned out that buying and maintaining their own 
servers will be 
cheaper.
 

--- 
Politechnika Łódzka 
Lodz University of Technology 

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. 
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę 
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. 

This email contains information intended solely for the use of the individual 
to whom it is addressed. 
If you are not the intended recipient or if you have received this message in 
error, 
please notify the sender and delete it from your system. 


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

Re: Convenient URL alias for Trac tickets

[Jan Stolarek]

One can also create bookmark with a keyword, as described on GHC wiki:

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

Janek
 

--- 
Politechnika Łódzka 
Lodz University of Technology 

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. 
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę 
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. 

This email contains information intended solely for the use of the individual 
to whom it is addressed. 
If you are not the intended recipient or if you have received this message in 
error, 
please notify the sender and delete it from your system. 


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

Re: Dataflow analysis for Cmm

[Jan Stolarek]

> I don't entirely agree. I personally find it very hard to review large
> patches as the amount of mental context generally seems to grow
> super-linearly in the amount of code touched. Moreover, I think it's
> important to remember that the need to read patches does not vanish the
> moment the patch is committed. To the contrary, review is merely the
> first of many instances in which a patch will be read. Other instances
> include,
I wholeheartedly agree with everything you say. I don't see it as contradicting 
in any way 
principles that I outlined. It's just that sometimes doing a single logical 
change to the code 
requires a large patch and breaking it artificially into smaller patches might 
actually make 
matters worse. I believe this would be the case for this scenario. And honestly 
speaking I don't 
think that the patch here will be very big. But like you say, there's a 
compromise to be struck.

Janek


>
>  * when the patch is backported
>
>  * when someone is trying to rebase one of their own changes on top of
>the patch
>
>  * when another contributor is trying to follow the evolution of a piece
>of the compiler
>
>  * when someone is later trying to understand a bug in the patch
>
> Consequently, I think it is fairly important not to throw out the
> structure that multiple, sensibly sized commits provides. Of course
> there is a compromise to be struck here: we don't want dozens of
> five-line patches; however I think that one mega-patch swings too far to
> the other extreme in the case of most features.
>
> Cheers,
>
> - Ben


 

--- 
Politechnika Łódzka 
Lodz University of Technology 

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. 
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę 
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. 

This email contains information intended solely for the use of the individual 
to whom it is addressed. 
If you are not the intended recipient or if you have received this message in 
error, 
please notify the sender and delete it from your system. 


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

Re: Dataflow analysis for Cmm

[Jan Stolarek]

> (did you intend to send two identical links?)
No :-) The branches should be js-hoopl-cleanup-v1 and js-hoopl-cleanup-v2

> Yes, the end result would be the same - I'm merely asking what would be
> preferred by GHC devs (i.e., I don't know how fine grained patches to GHC
> usually are).
I don't think this should be visible in your final patch. In a perfect world 
each repositrory 
commit shouyld provide exactly one functionality - not more and not less. So 
your final patch 
should not reflect intermediate steps you took to implement some functionality 
because they are 
not really relevant. For the purpose of development and review it is fine to 
have a branch with 
lots of small commits but before merging you should just squash them into one.

Janek
 

--- 
Politechnika Łódzka 
Lodz University of Technology 

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. 
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę 
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. 

This email contains information intended solely for the use of the individual 
to whom it is addressed. 
If you are not the intended recipient or if you have received this message in 
error, 
please notify the sender and delete it from your system. 


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

Re: Dataflow analysis for Cmm

[Jan Stolarek]

Michał,

Dataflow module could indeed use cleanup. I have made two attempts at this in 
the past but I don't 
think any of them was merged - see [1] and [2]. [2] was mostly type-directed 
simplifications. It 
would be nice to have this included in one form or another. It sounds like you 
also have a more 
in-depth refactoring in mind. Personally as long as it is semantically correct 
I think it will be 
a good thing. I would especially support removing dead code that we don't 
really use.

[1] https://github.com/jstolarek/ghc/commits/js-hoopl-cleanup-v2
[2] https://github.com/jstolarek/ghc/commits/js-hoopl-cleanup-v2

> Second question: how could we merge this? (...)
I'm not sure if I understand. The end result after merging will be exactly the 
same, right? Are 
you asking for advice what is the best way of doing this from a technical point 
if view? I would 
simply edit the existing module. Introducing a temporary second module seems 
like unnecessary 
extra work and perhaps complicating the patch review.

> I’m happy to export the code to Phab if you prefer - I wasn’t sure what’s
> the recommended workflow for code that’s not ready for review…
This is OK but please remember to set status of revision to "Planned changes" 
after uploading it 
to Phab so it doesn't sit in reviewing queue.

Janek

Dnia niedziela, 16 października 2016, Michal Terepeta napisał:
> Hi,
>
> I was looking at cleaning up a bit the situation with dataflow analysis for
> Cmm.
> In particular, I was experimenting with rewriting the current
> `cmm.Hoopl.Dataflow` module:
> - To only include the functionality to do analysis (since GHC doesn’t seem
> to use
>   the rewriting part).
>   Benefits:
>   - Code simplification (we could remove a lot of unused code).
>   - Makes it clear what we’re actually using from Hoopl.
> - To have an interface that works with transfer functions operating on a
> whole
>   basic block (`Block CmmNode C C`).
>   This means that it would be up to the user of the algorithm to traverse
> the
>   whole block.
>   Benefits:
>   - Further simplifications.
>   - We could remove `analyzeFwdBlocks` hack, which AFAICS is just a
> copy
> of `analyzeFwd` but ignores the middle nodes (probably for efficiency
> of analyses that only look at the blocks).
>   - More flexible (e.g., the clients could know which block they’re
> processing;
> we could consider memoizing some per block information, etc.).
>
> What do you think about this?
>
> I have a branch that implements the above:
> https://github.com/michalt/ghc/tree/dataflow2/1
> It’s introducing a second parallel implementation (`cmm.Hoopl.Dataflow2`
> module), so that it's possible to run ./validate while comparing the
> results of
> the old implementation with the new one.
>
> Second question: how could we merge this? (assuming that people are
> generally
> ok with the approach) Some ideas:
> - Change cmm/Hoopl/Dataflow module itself along with the three analyses
> that use
>   it in one step.
> - Introduce the Dataflow2 module first, then switch the analyses, then
> remove
>   any unused code that still depends on the old Dataflow module, finally
> remove
>   the old Dataflow module itself.
> (Personally I'd prefer the second option, but I'm also ok with the first
> one)
>
> I’m happy to export the code to Phab if you prefer - I wasn’t sure what’s
> the
> recommended workflow for code that’s not ready for review…
>
> Thanks,
> Michal


 

--- 
Politechnika Łódzka 
Lodz University of Technology 

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. 
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę 
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. 

This email contains information intended solely for the use of the individual 
to whom it is addressed. 
If you are not the intended recipient or if you have received this message in 
error, 
please notify the sender and delete it from your system. 


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

Re: Suggesting RankNTypes for ill-formed types

[Jan Stolarek]

It doesn't really matter whether we suggest ExplicitForAll, ScopedTypeVariables 
or RankNTypes. The 
code in question is plainly wrong and should be a parse error. I skimmed the 
parser code and I 
see no easy way of doing this without breaking the fix for #3155 at the same 
time.

What I would try, I think, is to find a different solution to #3155.

Janek


Dnia czwartek, 18 sierpnia 2016, Richard Eisenberg napisał:
> I tend to agree with Oleg that suggesting `ScopedTypeVariables` may be more
> helpful to users, even though `ExplicitForAll` is more principled.
>
> Richard
>
> > On Aug 11, 2016, at 2:45 PM, Oleg Grenrus  wrote:
> >
> > FWIW. Often when I encounter that error, I want `ScopedTypeVariables`,
> > yet my code doesn’t always has the scoped type variable used.
> > So even GHC could parse further and propose it to me, there isn’t
> > anything from to do it :(
> >
> > I don’t know if many use /just/ `ExplicitForAll`...
> >
> > - Oleg
> >
> >> On 11 Aug 2016, at 20:30, Karolina Drobnik  >> > wrote:
> >>
> >> Hello everyone,
> >>
> >> I am working on my first ticket (#11669, linked below)
> >> and I have some doubts after a little bit of hacking.
> >>
> >> There was a hint that an error message should be
> >> changed from the one suggesting RankNTypes to ExplicitForall.
> >> In my opinion it would be quite confusing for the user, especially where
> >> the type is ill-formed. A plain parse error should be shown here.
> >>
> >> It is clear that it should be done in such a way after turning on one
> >> of the extensions, but what about the situation where proposed
> >> fix (suggesting RankNTypes/ExplicitForall) won't work?
> >> We should be able to distinguish ill-formed type from the correct one,
> >> even before the extension activation. To be honest - I don't know how to
> >> do it.
> >>
> >> Additionally, I am not sure if we can assume that an user wants
> >> to use arbitrary rank (which implies ExplicitForall) or just a forall
> >> keyword. I am for the second one, but it is just my assumption.
> >>
> >> And the last minor thing - a type formed in this way also rises an error
> >> suggesting using RankNTypes (as we know that wouldn't solve the
> >> problem):
> >>
> >> f :: a. -> Int
> >> f = undefined
> >>
> >> Maybe we could treat it as a typo (simple parse error) and propose
> >> an extension activation only when forall was parsed earlier?
> >> That could be tricky.
> >>
> >> I'd appreciate some thoughts on this issue because I felt a bit lost
> >> after digging around the parser.
> >>
> >> Best regards,
> >>
> >> Karolina
> >> -
> >> #11669 - https://ghc.haskell.org/trac/ghc/ticket/11669
> >> 
> >> ___
> >> 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

 

--- 
Politechnika Łódzka 
Lodz University of Technology 

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. 
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę 
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. 

This email contains information intended solely for the use of the individual 
to whom it is addressed. 
If you are not the intended recipient or if you have received this message in 
error, 
please notify the sender and delete it from your system. 


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

Re: GHC HEAD (built with itself) blows allocation stats :-(

[Jan Stolarek]

Sanity check: was the stage0 compiler built using "perf" settings?

Janek

Dnia poniedziałek, 30 maja 2016, Gabor Greif napisał:
> Hi devs,
>
> I get some pretty bad allocation statistics when testing GHC HEAD. Not sure
> why, but this is with a stage-0 compiler that is also GHC HEAD. (I doubt
> that that is the reason, though.)
>
> I see on a linux x64 system (RHEL6) :
>
> Unexpected stat failures:
>/tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T10370  T10370 [stat
> not good enough] (optasm)
>/tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T10547  T10547 [stat
> not good enough] (normal)
>/tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T1969   T1969 [stat
> not good enough] (normal)
>/tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T3064   T3064 [stat
> not good enough] (normal)
>/tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T3294   T3294 [stat
> not good enough] (normal)
>/tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T4801   T4801 [stat
> not good enough] (normal)
>/tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5030   T5030 [stat
> not good enough] (normal)
>/tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5321FD T5321FD [stat
> not good enough] (normal)
>/tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5321FunT5321Fun
> [stat not good enough] (normal)
>/tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5631   T5631 [stat
> not good enough] (normal)
>/tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5642   T5642 [stat
> not good enough] (normal)
>/tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5837   T5837 [stat
> not good enough] (normal)
>/tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T6048   T6048 [stat
> not good enough] (optasm)
>/tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T783T783 [stat
> not good enough] (normal)
>/tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9020   T9020 [stat
> not good enough] (optasm)
>/tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9233   T9233 [stat
> not good enough] (normal)
>/tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9675   T9675 [stat
> not good enough] (optasm)
>/tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9872a  T9872a [stat
> not good enough] (normal)
>/tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9872b  T9872b [stat
> not good enough] (normal)
>/tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9872c  T9872c [stat
> not good enough] (normal)
>/tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9872d  T9872d [stat
> not good enough] (normal)
>/tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9961   T9961 [stat
> not good enough] (normal)
>/tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/parsing001  parsing001
> [stat not good enough] (normal)
>/tmp/ghctest/ayiNBP/1/2/3/./perf/space_leaks/T4029T4029 [stat
> not good enough] (ghci)
>
>
> Some of the tests look like this:
>
> cd /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9872a &&
> "ghc-head-x86_64/inplace/test   spaces/ghc-stage2" -c T9872a.hs
> -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts
> -fno-warn-tabs -fno-warn-missed-specialisations -fshow-warning-groups
> -fno-ghci-history   +RTS -V0 -tT9872a.comp.stats --machine-readable
> -RTS > T9872a.comp.stderr 2>&1
> bytes allocated value is too high:
> ExpectedT9872a(normal) bytes allocated:  3352882080 +/-5%
> Lower bound T9872a(normal) bytes allocated:  3185237976
> Upper bound T9872a(normal) bytes allocated:  3520526184
> Actual  T9872a(normal) bytes allocated: 13260131240
> Deviation   T9872a(normal) bytes allocated:   295.5 %
> *** unexpected stat test failure for T9872a(normal)
>
> Around 300% looks really bad. Can anybody reproduce this? For
> reference, this is the test command I run:
>
> $ make test TEST="T9961 T10547 T10370 T3064 T4029 T5642 parsing001
> T783 T3294 T9872d T9872b T9872c T9872a T1969 T5321Fun T5837 T5631
> T5321FD T5030 T4801 T6048 T9675 T9233 T9020"
>
> The testsuite works nicely otherwise.
>
> Cheers and thanks,
>
> Gabor
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


 

--- 
Politechnika Łódzka 
Lodz University of Technology 

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. 
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę 
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. 

This email contains information intended solely for the use of the individual 
to whom it is addressed. 
If you are not the intended recipient or if you have received this message in 
error, 
please notify the sender and delete it from your system. 


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

Re: 8.0.1 source tarballs available (yet again)

[Jan Stolarek]

This time my build went through without problems on openSUSE 11.4.

Janek

Dnia wtorek, 17 maja 2016, Ben Gamari napisał:
> tl;dr: We are giving this release another attempt. Cross your fingers
>and try building again.
>
> Hello GHC packagers,
>
> Thanks for your help in the last few days working through what were
> hopefully the last issues in the release. I've uploaded a new set of
> source tarballs at,
>
> http://downloads.haskell.org/~ghc/8.0.1/
>
> These tarballs are derived from,
>
> 787900138b94790ddd13d76c2853d789d3335a5d
>
> This commit differs from the previous tarball in a number of ways,
>
>  * a variety of packaging issues surrounding haddock's documentation
>have been fixed
>
>  * the ghc-boot library has been split up. It was pointed out quite late
>that the previous structure of ghc-boot greatly increased the
>dependency footprint of the template-haskell package, which would
>have made it nearly impossible to upgrade the bytestring and binary
>packages.
>
>  * a pair of fixes for crashes on PowerPC have been merged
>
>  * a patch addressing a serious performance issue in parallel garbage
>collection has been merged
>
>  * the bytestring module has been bumped to 0.8.10.1, fixing a rather
>serious correctness issue on big-endian systems
>
> We'll have the usual one-week build window for binary distributions.
> As always, let either Austin or I know if you have any trouble building
> your distribution. I have yet to push the ghc-8.0.1 tag in case we
> encounter unexpected issues but all of my builds with this tarball
> thusfar have gone quite well (then again, so did those of the previous
> tarball).
>
> Good luck and thanks for all of your work!
>
> Cheers,
>
> - Ben

 

--- 
Politechnika Łódzka 
Lodz University of Technology 

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. 
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę 
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. 

This email contains information intended solely for the use of the individual 
to whom it is addressed. 
If you are not the intended recipient or if you have received this message in 
error, 
please notify the sender and delete it from your system. 


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

Re: [ANNOUNCE] GHC 8.0.1 source tarball available

[Jan Stolarek]

I did `pip install alabaster` but keep getting the same error. Unless I need to 
rebuild everything 
from scratch (in which case I'll probably disable the docs).

Janek

Dnia sobota, 14 maja 2016, Ben Gamari napisał:
> Jan Stolarek <jan.stola...@p.lodz.pl> writes:
> > I am getting a build error under openSUSE 11.4:
> >
> > make -C utils/haddock/doc html SPHINX_BUILD=/usr/bin/sphinx-build
> > /usr/bin/sphinx-build -b html . .build-html
> > Running Sphinx v1.2.3
> > loading translations [en]... done
> > loading pickled environment... not yet created
> >
> > Theme error:
> > no theme named 'alabaster' found (missing theme.conf?)
> > make[2]: *** [html] Error 1
> > make[1]: *** [html_utils/haddock/doc] Error 2
> > make: *** [all] Error 2
> >
> > Any suggestions how to fix it?
>
> Yes, it seems that the theme that haddock requests was first introduced
> to Sphinx in version 1.3. I have encountered this issue myself as well
> and yesterday pushed a patch vendorizing the alabaster repository to
> ensure that we can build with earlier Sphinx versions. Without this
> patch the workaround is to `pip install alabaster` or disable building
> of Sphinx documentation.
>
> So, be we yet again have the question of how to deal with this change. I
> really don't know what I want to let Haddock's documentation hold up the
> GHC release any more than it already has. As I indicated earlier, the
> prospect of releasing binaries which weren't derived from the official
> source
> release isn't terribly attractive but may be the best we can do here.
> The alternative would be do release 8.0.1 as-is with some notes in the
> release notes and immediately start preparing an 8.0.2 after its is
> released.
>
> Thoughts?
>
> Cheers,
>
> - Ben

 

--- 
Politechnika Łódzka 
Lodz University of Technology 

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. 
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę 
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. 

This email contains information intended solely for the use of the individual 
to whom it is addressed. 
If you are not the intended recipient or if you have received this message in 
error, 
please notify the sender and delete it from your system. 


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

Re: [ANNOUNCE] GHC 8.0.1 source tarball available

[Jan Stolarek]

I am getting a build error under openSUSE 11.4:

make -C utils/haddock/doc html SPHINX_BUILD=/usr/bin/sphinx-build
/usr/bin/sphinx-build -b html . .build-html
Running Sphinx v1.2.3
loading translations [en]... done
loading pickled environment... not yet created

Theme error:
no theme named 'alabaster' found (missing theme.conf?)
make[2]: *** [html] Error 1
make[1]: *** [html_utils/haddock/doc] Error 2
make: *** [all] Error 2

Any suggestions how to fix it?

Janek


Dnia środa, 11 maja 2016, Ben Gamari napisał:
> > [ Unknown signature status ]
>
> tl;dr: If you would like to produce a binary distribution for GHC
>8.0.1 then let us know, grab the source distribution and start
>building. The binary distributions will be all released one week
>from today.
>
>
> Hello GHC packagers,
>
> I am happy to at long last announce the release of the 8.0.1 source
> distribution to binary packagers. You will find the usual artifacts at
>
> http://downloads.haskell.org/~ghc/8.0.1/
>
> These tarballs are derived from GHC commit
>
> e99c1e2516aeb283172c7e6898508238e33cf065.
>
> For this release we are again following our new release policy [1],
> with a one-week delay between the release of the source and binary
> distributions. The goal of this policy is to give all platforms the
> opportunity for support from the first day of a release.
>
> If all of the expected binary releases are submitted before the
> week-long delay has elapsed, we will move forward with the release of
> the binaries on an accelerated schedule. It would be appreciated if you
> could reply to this message confirming that you intend to offer a binary
> distribution for this release.
>
> Otherwise, let either Austin or I know if you have any trouble building
> your distribution. As usual I'll hold off on pushing the release git tag
> until we have a few binaries built in case we encounter unexpected
> issues.
>
> Good luck and thanks for all of your work!
>
> Cheers,
>
> - Ben
>
>
> [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html

 

--- 
Politechnika Łódzka 
Lodz University of Technology 

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. 
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę 
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. 

This email contains information intended solely for the use of the individual 
to whom it is addressed. 
If you are not the intended recipient or if you have received this message in 
error, 
please notify the sender and delete it from your system. 


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

Re: Potentially confusing syntax for injective type families

[Jan Stolarek]

> I don't have a solution and I hate bike-shedding. I just made this
> message to make sure the fact had been considered before release.
Yes, I bumped into this issue quite early. After some discussion it was decided 
that this 
potential ambiguity is an acceptable trade-off.

Janek

Dnia niedziela, 14 lutego 2016, Matthew Pickering napisał:
> I guess my point is that the most natural parsing of
>
> class Hcl a b where
>  type Ht a b = r | r -> a b
>
> is  (type Ht a b = r) (| r -> a b) rather than (type Ht a b) (= r | r -> a
> b).
>
> A concrete example, in the case of functional dependencies, the
> vertical bar is used to signal what we expect *additional* optional
> information. In this case, adding the injectivity annotation
> completely changes the meaning of what came before.
>
> I don't have a solution and I hate bike-shedding. I just made this
> message to make sure the fact had been considered before release.
>
> Matt
>
> On Sun, Feb 14, 2016 at 9:28 AM, Jan Stolarek <jan.stola...@p.lodz.pl> wrote:
> >> 2. Without the infectivity annotation, this declares an associate type
> >> synonym default. This isn't valid because Ht is not declared as an
> >> associated type before hand and r is not mentioned on the LHS.
> >>
> >> class Hcl a b where
> >> type Ht a b = r
> >
> > Indeed, this is invalid and GHC rejects this, so I think we're OK here.
> > In case of associated types if you want to declare injectivity you need
> > to provide the "| r -> " part. Otherwise you're declaring a default.
> > This is documented in the User's Guide for 8.0.
> >
> > Janek
> >
> > ---
> > Politechnika Łódzka
> > Lodz University of Technology
> >
> > Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> > Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
> > pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
> >
> > This email contains information intended solely for the use of the
> > individual to whom it is addressed. If you are not the intended recipient
> > or if you have received this message in error, please notify the sender
> > and delete it from your system.


---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Potentially confusing syntax for injective type families

[Jan Stolarek]

> 2. Without the infectivity annotation, this declares an associate type
> synonym default. This isn't valid because Ht is not declared as an
> associated type before hand and r is not mentioned on the LHS.
>
> class Hcl a b where
> type Ht a b = r
Indeed, this is invalid and GHC rejects this, so I think we're OK here. In case 
of associated 
types if you want to declare injectivity you need to provide the "| r -> " 
part. Otherwise 
you're declaring a default. This is documented in the User's Guide for 8.0.

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez 
pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

GHC performance dashboard question

[Jan Stolarek]

Joachim, what do I need to do to have my wip/ branch picked up by the 
performance dashboard? I'm 
thinking about branch wip/js-hoopl-cleanup, which was pushed yesterday but 
still hasn't been 
measured for performance.

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Dropping bzip2 release tarballs?

[Jan Stolarek]

> it appears that essentially everyone uses the xz distributions. If this 
> really is the
> case, then I would ask why are we spending the disk space, effort,
> bandwidth, and complexity preparing the bzips.
I stayed quite in this discusion so far, but I am one of the people still using 
bz2 rather than 
xz. Why? Because I use a fairly old Linux distro and my GUI tool for working 
with archives does 
not recognize xz format. I'll live without bz2, but my life will be less 
comfortable.

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Best practices for merging?

[Jan Stolarek]

> If there are multiple commits then a merge commit can serve to logically
> group them.
The cost of this is non-linear history. But I am still not sure what the actual 
benefit is? If the 
commits come one after another they are still logically grouped, with or 
without a merge commit.

I also wonder what is the preferred way of viewing history for most of the 
people. I either use 
`git log` or github, but rarely resort to gitk. Only the latter makes the 
non-linear commits 
explicitly visible. The former two just collapse everything into a linear 
history and is such a 
setting merge commits are a major clutter. So perhaps that's why I don't like 
them. Perhaps 
people who tend to use gitk are more keen on merge commits?

Janek


> For instance, in the case of Geoff's recent fix, 
>
> $ git log --graph --oneline origin/master
> * e5a0a89 Suppress substitution assertions to fix tests
> * a883c1b Missing @since annotations in GHC.Generics
> * f8e2b7e Minor doc fixes to GHC.Generics
> * 34519f0 When encountering a duplicate symbol, show source of the
> first symbol *   669cbef Fix Trac issue #11487.
>
> |\
> | * 6544f8d Properly track live registers when saving the CCCS.
> | * 90f688e Code formatting cleanup.
> | * 4d0e4fe Add type signatures.
> |/
>
> * b61f5f7 Put docs in /usr/share/doc/ghc-
>
> Here we see that those three commits were developed on a feature branch,
> which was then merged into master in 669cbef.
>
> For what it's worth I quite like this practice. That being said, in GHC
> we rarely have changes broken up into multiple commits like this, in
> part due to Phab's poor support for fine-grained changes.
>
> Cheers,
>
> - Ben


---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Best practices for merging?

[Jan Stolarek]

> rebase onto master, and then merge with an empty merge commit, i..e, *not* 
> fast-forward.
I was under the impression - perhaps incorrect - that it is our policy to avoid 
merge commits, ie. 
do only fast-forward merges. And when I look at git history I see very few 
merge commits. 

> This lets me look at the repo history and easily see where a feature branch 
> landed and get a
> good idea of what changes it contains.
I always considered merge commits to be obscuring history, both making it hard 
to read and 
understand. Two commits instead of one does not sound desirable. And you can 
always see what 
changes were introduced by a patch, with or without merge commit. But perhaps I 
am missing 
something here.

Janek

> This lets me look at the repo history 
> and easily see where a feature branch landed and get a good idea of what
> changes it contains. I have used this approach in the past with GHC,
> e.g., SIMD support and typed TH.
>
> For smaller sets of changes, I might skip the merge commit, but I still
> break up my changes into discreet bits, which helps anyone reading the
> change set to see what's going on.
>
> It seems the current policy is to submit changes via Phab and then,
> after approval, squash everything into a single patch and apply it with
> arc. At least that is my reading of
> https://ghc.haskell.org/trac/ghc/wiki/Phabricator/Extras#Landingreviews.
> Is that what I should be doing?
>
> For feature branches, is that also what is advised?
>
> Thanks,
> Geoff
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez 
pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Special treatment of family and role in the parser

[Jan Stolarek]

I'll take a look at the parser, see if we can do better.

> I also suggest that keywords introduced by GHC extensions should be lexed as 
> keywords regardless
> of  whether extension is enabled or not: this way users won't get spurious 
> errors if they
> suddenly enable extension and it turns out that some of their identifiers 
> have become keywords.
I would be cautious here. Patch I am working on right now will use "kind" as a 
reserved 
identifier. It will only be allowed after `data` keyword. Making it a reserved 
word everywhere 
would be a major issue as many people doing type-level programming have 
variables named "kind". 
You ar right that problem would be much smaller if the keyword was "datakind" 
but somehow I am 
reluctant to seeing things like "datakindmember", "typeinstance", etc. What 
others think about 
this proposal?

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Special treatment of family and role in the parser

[Jan Stolarek]

Yes, I have seen the note, but thank you nevertheless :-)

Janek

Dnia czwartek, 21 stycznia 2016, Alan & Kim Zimmerman napisał:
> At the risk of stating the obvious, have you looked at
> https://github.com/ghc/ghc/blob/master/compiler/parser/Parser.y#L2993?
>
> Alan
>
> On 21 Jan 2016 4:50 PM, "Jan Stolarek" <jan.stola...@p.lodz.pl> wrote:
> > I'll take a look at the parser, see if we can do better.
> >
> > > I also suggest that keywords introduced by GHC extensions should be
> >
> > lexed as keywords regardless
> >
> > > of  whether extension is enabled or not: this way users won't get
> >
> > spurious errors if they
> >
> > > suddenly enable extension and it turns out that some of their
> >
> > identifiers have become keywords.
> > I would be cautious here. Patch I am working on right now will use "kind"
> > as a reserved
> > identifier. It will only be allowed after `data` keyword. Making it a
> > reserved word everywhere
> > would be a major issue as many people doing type-level programming have
> > variables named "kind".
> > You ar right that problem would be much smaller if the keyword was
> > "datakind" but somehow I am
> > reluctant to seeing things like "datakindmember", "typeinstance", etc.
> > What others think about
> > this proposal?
> >
> > Janek
> >
> > ---
> > Politechnika Łódzka
> > Lodz University of Technology
> >
> > Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> > Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
> > pomyłkę
> > prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
> >
> > This email contains information intended solely for the use of the
> > individual to whom it is addressed.
> > If you are not the intended recipient or if you have received this
> > message in error,
> > please notify the sender and delete it from your system.
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Phab failing to apply patches

[Jan Stolarek]

> * you validate locally (in a different build directory, so you can keep
> using build flavour = devel2 in your development directory)
> * fork the ghc github repository, push your branch there, and let Travis
> validate it: https://ghc.haskell.org/trac/ghc/wiki/TestingPatches#Travis
> * ask Austin for some special Phabricator syntax that you could add when
> you submit the patch, to request Harbormaster not to rebase onto HEAD
> before validating
Second option is an acceptable workaround for me, but having the third one 
would be even better. I 
definitely want to avoid the first one - computing power of my machine is 
limited.

> Side note: I think we should go back to using Phabricator for finished
> patches only.
What if we could set the default state of upload patch to "planned changes"? 
This way patches 
would end up in the review queue only when someone explicitly sets them to 
"Request Review". 
Wouldn't that solve the problem?

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Phab failing to apply patches

[Jan Stolarek]

> If you are working from an old base commit, either rebase your patch before
> submitting to Phabricator (painful? you will have to do it before pushing
> anyway, might as well do it now), or ignore the Harbormaster validate
> result.
I am typically working on some non-trivial features (ie. rebases tend to be 
painful). Having 
Harbormaster build results is a useful way of telling whether I broke something 
or not. Even if 
it is for some older commit. Rebases take time and if I know my feature will 
not be finished in 
the next couple of weeks I want to save myself from unnecessary rebasing. Why 
rebase all the time 
if I can do it just once at the end?

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Phab failing to apply patches

[Jan Stolarek]

Can we somehow force Phab to apply a patch against a base commit from which the 
patch was created? 
Current setting does not seem very useful - it will probably force me to rebase 
my patches once a 
week or so. That will be very painful.

Janek

Dnia piątek, 15 stycznia 2016, Thomas Miedema napisał:
> It changed some time last year.
>
> Before, Harbormaster would sometimes try to build some bizarro intermediate
> mix of base commit + patch + master. See
> https://ghc.haskell.org/trac/ghc/ticket/9855.
>
>
> On Fri, Jan 15, 2016 at 7:06 PM, Jan Stolarek <jan.stola...@p.lodz.pl>
>
> wrote:
> > Somehow I always I believed that Harbormaster does not apply a patch onto
> > master but onto the
> > revision it was created from. Has there been any change in this behaviour
> > recently?
> >
> > Janek
> >
> > Dnia piątek, 15 stycznia 2016, Thomas Miedema napisał:
> > > "Unable to apply patch!" means just that. Harbormaster is unable to
> > > apply the patch (to master). You can test it yourself by running 'arc
> > > patch --nobranch D1778` on an up-to-date checkout of the master branch,
> > > and it will fail in the same way.
> > >
> > > Solution: rebase your patch onto master, and update the Diff. You'll
> >
> > notice
> >
> > > there are indeed merge problems.
> > >
> > >
> > > On Fri, Jan 15, 2016 at 6:49 PM, Jan Stolarek <jan.stola...@p.lodz.pl>
> > >
> > > wrote:
> > > > It seems that Phab is once again failing to apply patches (eg. D1778,
> > > > which built perfectly fine
> > > > until latest update). Is anyone else experiencing this?
> > > >
> > > > Janek
> > > >
> > > > ---
> > > > Politechnika Łódzka
> > > > Lodz University of Technology
> > > >
> > > > Treść tej wiadomości zawiera informacje przeznaczone tylko dla
> >
> > adresata.
> >
> > > > Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją
> > > > przez pomyłkę
> > > > prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
> > > >
> > > > This email contains information intended solely for the use of the
> > > > individual to whom it is addressed.
> > > > If you are not the intended recipient or if you have received this
> > > > message in error,
> > > > please notify the sender and delete it from your system.
> > > > ___
> > > > ghc-devs mailing list
> > > > ghc-devs@haskell.org
> > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> > ---
> > Politechnika Łódzka
> > Lodz University of Technology
> >
> > Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> > Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
> > pomyłkę
> > prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
> >
> > This email contains information intended solely for the use of the
> > individual to whom it is addressed.
> > If you are not the intended recipient or if you have received this
> > message in error,
> > please notify the sender and delete it from your system.



---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Phab failing to apply patches

[Jan Stolarek]

It seems that Phab is once again failing to apply patches (eg. D1778, which 
built perfectly fine 
until latest update). Is anyone else experiencing this?

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Phab failing to apply patches

[Jan Stolarek]

Somehow I always I believed that Harbormaster does not apply a patch onto 
master but onto the 
revision it was created from. Has there been any change in this behaviour 
recently?

Janek

Dnia piątek, 15 stycznia 2016, Thomas Miedema napisał:
> "Unable to apply patch!" means just that. Harbormaster is unable to apply
> the patch (to master). You can test it yourself by running 'arc patch
> --nobranch D1778` on an up-to-date checkout of the master branch, and it
> will fail in the same way.
>
> Solution: rebase your patch onto master, and update the Diff. You'll notice
> there are indeed merge problems.
>
>
> On Fri, Jan 15, 2016 at 6:49 PM, Jan Stolarek <jan.stola...@p.lodz.pl>
>
> wrote:
> > It seems that Phab is once again failing to apply patches (eg. D1778,
> > which built perfectly fine
> > until latest update). Is anyone else experiencing this?
> >
> > Janek
> >
> > ---
> > Politechnika Łódzka
> > Lodz University of Technology
> >
> > Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> > Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
> > pomyłkę
> > prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
> >
> > This email contains information intended solely for the use of the
> > individual to whom it is addressed.
> > If you are not the intended recipient or if you have received this
> > message in error,
> > please notify the sender and delete it from your system.
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Injective type families

[Jan Stolarek]

> I'm joining this conversation late, but I favor TypeFamilyDependencies over
> InjectiveTypeFamilies. We use the annotations for things other than
> injectivity! For example,
>
> > type family Plus a b = r | r a -> b, r b -> a
>
> is not injective under any common understanding of the word.
But that is not implemented yet and thus will not make it into GHC 8.0. 
Following earlier 
argumentation, once we have generalized injectivity we should put it into a 
separate extension. 
So I'd say we stick with InjectiveTypeFamilies for currently implemented 
features and put the new 
ones in TypeFamilyDependencies.

That said, I don't like the idea that every addition to a language extension 
means creating a 
separate language extension.

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Injective type families

[Jan Stolarek]

Ben,

>   1. Should this feature be placed behind a LANGUAGE pragma?
No, I don't think it should. I consider it a tiny addition to TypeFamilies that 
is not worth 
having its separate pragma. Injective TFs are fully backwards compatible, so no 
existing code 
will be broken.

>   2. Could you perhaps add some text to better motivate the feature in
>  the users guide?
Done. Tell me whether you like the new version.

BTW do we still have nightly builds of User's Guide?

Janek

>  Referring to the paper for the details of 
>  semantics of the feature and its implementation is fine, but
>  expecting a new user to refer to the paper to even know *why* they
>  might want to use it seems a bit unfriendly.
>
> Thanks!
>
> Cheers,
>
> - Ben



---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Injective type families

[Jan Stolarek]

> If I actually want to write backward-compatible type family code using 
> GHC-8.0, I'd prefer
> to be able to enable TypeFamilies yet not InjectiveTypeFamilies, and have GHC 
> check that I am in
> the common subset.
Good point. I wonder if others agree.

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Injective type families

[Jan Stolarek]

> Is "InjectiveTypeFamilies" a good name for this?  Or 
> "TypeFamilyDependencies"?  Or what?
My vote for "InjectiveTypeFamilies".

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Open data kinds

[Jan Stolarek]

I rewrote the wiki page to include open data kinds proposal:

https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindsWithoutData

It would be a Good Thing to agree on the syntax before it gets implemented. So 
if anyone wants to 
express their preference or have a constuctive argument for/against some 
particular proposal now 
is a good time.

I would like to start working on the implementation sometime soonish.

Janek

Dnia czwartek, 17 grudnia 2015, Richard Eisenberg napisał:
> Janek and I discussed this issue this morning, and I would like to state my
> opinion and state my case:
>
>  * In `kind K = T`, `T` should live in the data-level namespace.
>
> Of course, if `T` is used in a term-level expression, an error should be
> issued, because T logically lives only in types.
>
> To explain why I feel this way, it's helpful to reflect on the 4 namespaces
> Haskell currently has. I will refer to these by number.
>
> 1. Term-level data constructors and pattern synonyms
> 2. Types, classes, and type constructors
> 3. Term-level variables and globals
> 4. Type variables
>
> The debate at hand only involves 1 and 2. We are adding a new feature to
> the language. Should it go in namespace 1 or namespace 2? To help decide,
> it would be nice to have a general principle of what goes in 1 and what
> goes in 2. Here is one possible principle:
>
> A. Namespace 1 contains runtime things; namespace 2 contains compile-time
> things.
>
> Principle A has served us well for some time. But it's failing us now. With
> DataKinds, we can use namespace-1 things at compile-time. And some of us
> have been scheming for a way to use namespace-2 things at runtime. So
> Principle A doesn't seem quite right. Instead, I propose
>
> B. Namespace 1 contains data constructors (and, closely related, pattern
> synonyms); namespace 2 contains datatypes (and, closely related, classes).
>
> Up until DataKinds, Principles A and B have coincided. But now they have
> diverged, and only Principle B serves to describe what's going on.
>
> (Aside: When you say True in a type, and it's in scope, that's because GHC
> looks in namespace 2 first; failing that, it looks in namespace 1.
> DataKinds never copies namespace-1 things into namespace 2.)
>
> If we thus adopt Principle B, then we indeed want `T` from the example to
> live in namespace 1. It is a data constructor. One might argue that this is
> a misnomer, because T lives only at compile time. T indeed does live only
> at compile time, but it still is a data constructor -- it constructs
> compile-time data. (Just like using 'True in a type doesn't make 'True any
> less of a data constructor.)
>
> A noted drawback of Principle B is that it means that compile-time only
> definitions "pollute" namespace 1. That's true. But it need be only local,
> as you're free to make namespace-2 type synonyms that refer to namespace-1
> data constructors. And it's quite straightforward to ensure that `T` is
> never present at runtime -- it's just a straightforward check in the
> typechecker.
>
> Thus, according to general Principle B, `T` should be in namespace 1.
>
> What do you think?
>
> Richard
>
> On Dec 16, 2015, at 2:21 PM, Jan Stolarek <jan.stola...@p.lodz.pl> wrote:
> > Devs,
> >
> > I plan to work on implementing open data kinds (#11080). The idea is that
> > users will be allowed to declare open kinds and then populate them with
> > member types. Perhaps I will also implement closed data kinds. This is
> > already possible using DataKinds, but the idea is to declare a data kind
> > without corresponding data type - see #6024.
> >
> > Now, consider this declaration (syntax subject to bikeshedding):
> >
> >  kind K = T
> >
> > In what namespace should T go: type namespace or data constructor
> > namespace? If we put it in type namespace then it is possible for the
> > user to declare a data constructor T that is completely unrelated to type
> > T belonging to kind K. This might be confusing. If we put T in the data
> > namespace then we miss the point of #6024.
> >
> > Thoughts?
> >
> > Janek
> >
> > ---
> > Politechnika Łódzka
> > Lodz University of Technology
> >
> > Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> > Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
> > pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
> >
> > This email contains information intended solely for the use of the
> > individual to whom it is addressed. If you are not the intended recipient
> > or if you have received this message in error, please notify the sender
>

Re: Open data kinds

[Jan Stolarek]

> There is no language support to define a 
> "closed datatype" but it is possible to do so by not exporting any of
> the constructors used to make the datatype.
Data types are closed in a sense that if you define

data Foo = MkFoo1

then you cannot add new data constructor, say MkFoo2, that will also create 
values of type Foo. So 
being open/closed is not about creating new values of a data type but about 
extending the 
definition with new constructors. Does that answer your question?

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Open data kinds

[Jan Stolarek]

Devs,

I plan to work on implementing open data kinds (#11080). The idea is that users 
will be allowed to 
declare open kinds and then populate them with member types. Perhaps I will 
also implement closed 
data kinds. This is already possible using DataKinds, but the idea is to 
declare a data kind 
without corresponding data type - see #6024.

Now, consider this declaration (syntax subject to bikeshedding):

  kind K = T

In what namespace should T go: type namespace or data constructor namespace? If 
we put it in type 
namespace then it is possible for the user to declare a data constructor T that 
is completely 
unrelated to type T belonging to kind K. This might be confusing. If we put T 
in the data 
namespace then we miss the point of #6024.

Thoughts?

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Unused type variables with non-linear patterns

[Jan Stolarek]

> Is there a ticket?
#10982

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC 8.0 feature freeze imminent

[Jan Stolarek]

I would love to land my fix for #10828, but now that the wildcard refactor and 
no-kinds have been 
merged it will require a substantial rewrite. I'll try to do that on Wednesday 
and hopefully 
there will be enough time for a review before feature freeze.

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Unused type variables with non-linear patterns

[Jan Stolarek]

An intersting thing came up when implementing warnings for unused type 
variables in type family 
patterns (#10982 / D1576):

type family X a b where
  X a a = Int 

Should we emit a warning that `a` is unused? It does not appear in the RHS but 
it is actually used 
because of non-linear pattern. We can fix this by prefixing both appearances of 
`a` with an 
underscore - this silences the warning and maintains semantics. Nevertheless, 
if a variable is 
unused it should be perfectly valid to replace it with an underscore - that is 
not the case in 
this example. Thoughts?

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: A GHC Library

[Jan Stolarek]

> How do you suggest getting around copyright issues?
LIke Eric said - by posting pre-prints. I think this should be legal.

Note also these two clauses in the ACM Copyright Agreement:

1. "Copyright to the Work (...)  is hereby transferred to the ACM (...) 
effective as of the date 
of this agreement" - which means that until you sign the agreement you can do 
whatever you want 
with your work, including posting it on arXiv. This does not help with any 
papers published in 
the past but I suppose it's worth noting for the future papers.

2. "Permitted Uses (...) Post the Accepted Version of the Work on (...) any 
repository legally 
mandated by an agency funding the research on which the Work is based." So if 
anyone manages to 
convice their university that they require all published papers to be posted to 
arXiv, then it 
will be legal to post the accepted versions of the paper on arXiv :-)

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: A GHC Library

[Jan Stolarek]

I know this is a bit old, but I just had a thought that perhaps we could 
archive GHC papers on 
arxiv.org? This should be permanent and with a bit of effort we can get around 
copyright issues 
(I think). Surprisingly little Haskell research can be found on arXiv and 
perhaps it is time we 
changed that?

Janek

Dnia środa, 29 lipca 2015, Richard Eisenberg napisał:
> Done -- merged into ReadingList.
>
> On Jul 28, 2015, at 9:39 PM, Richard Eisenberg  wrote:
> > On Jul 28, 2015, at 5:23 PM, Simon Peyton Jones  
> > wrote:
> >> Good plan; maybe you can merge your list into the existing Reading List
> >> that Jan pointed you to?
> >>
> >> I think there would be merit in actually snapshotting the bits into one
> >> safe place.  Links go dead etc, and having a single archive location
> >> might be a very good thing.  If anyone feels like doing that.
> >
> > That was actually my original intent. But then I worried about copyright
> > issues. So instead I just pointed to doi.org links, which should at least
> > give our future selves a fighting shot at getting the original resource.
> >
> > Will merge with the other page (which I was clearly unaware of) tomorrow.
> > I actually think most of my entries are distinct from those on the other
> > page, so my work wasn't wasted.
> >
> > Richard
> >
> >> Simon
> >>
> >> | -Original Message-
> >> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
> >> | Richard Eisenberg
> >> | Sent: 28 July 2015 16:15
> >> | To: ghc-devs Devs
> >> | Subject: A GHC Library
> >> |
> >> | Hi devs,
> >> |
> >> | It has struck me that we have a vast trove of documentation about GHC
> >> | in the form of academic papers, but little organization to this trove.
> >> | The papers are scattered across authors' websites, and sometimes it is
> >> | hard to remember what a paper is titled when searching for it.
> >> |
> >> | I have thus started a wiki page here:
> >> | https://ghc.haskell.org/trac/ghc/wiki/Library
> >> |
> >> | I would love for this page to be the Definitive List of GHC-related
> >> | papers. The list I've included is, of course, woefully short, but it
> >> | is a starting point. Please add to it!
> >> |
> >> | Have you written a GHC paper? If so, make sure it's included.
> >> |
> >> | 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



---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Wildcards in type functions vs. named wild cards

[Jan Stolarek]

Simon,

One of my students (Michał, CCd) is hacking on #10982 and he noticed a rather 
unexpected 
behaviour. If I say:

{-# LANGUAGE TypeFamilies #-}

module T10982 where

type family F a where
F _t = Int

Then everything is fine. But if I enable NamedWildCards extension then suddenly 
this code is 
rejected:

T10982.hs:7:7: error:
Unexpected wild card: ‘_t’
In the declaration for type synonym ‘F’

I am 99% sure this is a bug and the program should be accepted even with 
NamedWildCards. Am I 
correct? Does this interact in any way with your upcomming refactoring of 
wildcards?

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Wildcards in type functions vs. named wild cards

[Jan Stolarek]

> If F _a = .. is allowed at all, I guess it should mean just the same as an
> ordinary type variable.
Yes, exactly. I want type-level behaviour to mimic term level here.

> Would you like to implement that, and document it?
Michał is working on that.

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Can't build current HEAD

[Jan Stolarek]

I am unable to build current HEAD. I'm getting a build error in Outputable 
module:

compiler/utils/Outputable.hs:1046:28:
Not in scope: type constructor or class ‘CallStack’

compiler/utils/Outputable.hs:1047:23: Not in scope: ‘showCallStack’

The most likely culprit is 80d7ce8038a100f6797a89755c893c6f67f18a30, which 
added this:

#if __GLASGOW_HASKELL__ >= 710
pprSTrace :: (?location :: CallStack) => SDoc -> a -> a 
 
pprSTrace = pprTrace (showCallStack ?location)
#else
pprSTrace :: SDoc -> a -> a
pprSTrace = pprTrace "no callstack info"
#endif

The most interesting thing is that if I change the definition of pprSTrace in 
the first branch of 
#if to be identical to the definition in the second branch, then I get warnings 
that GHC.Stack 
and GHC.Exception imports are redundant. Any ideas what might be going on here? 
I'm compiling 
using GHC 7.10.1. This happens in a clean build tree.

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Can't build current HEAD

[Jan Stolarek]

I just verified this does not happen when building with GHC 7.8.4, so if our 
build machines 
(harbormaster, travis) are building using 7.8.4 this might not show up in the 
logs.

Janek

Dnia piątek, 13 listopada 2015, Jan Stolarek napisał:
> I am unable to build current HEAD. I'm getting a build error in Outputable
> module:
>
> compiler/utils/Outputable.hs:1046:28:
> Not in scope: type constructor or class ‘CallStack’
>
> compiler/utils/Outputable.hs:1047:23: Not in scope: ‘showCallStack’
>
> The most likely culprit is 80d7ce8038a100f6797a89755c893c6f67f18a30, which
> added this:
>
> #if __GLASGOW_HASKELL__ >= 710
> pprSTrace :: (?location :: CallStack) => SDoc -> a -> a
> pprSTrace = pprTrace (showCallStack ?location)
> #else
> pprSTrace :: SDoc -> a -> a
> pprSTrace = pprTrace "no callstack info"
> #endif
>
> The most interesting thing is that if I change the definition of pprSTrace
> in the first branch of #if to be identical to the definition in the second
> branch, then I get warnings that GHC.Stack and GHC.Exception imports are
> redundant. Any ideas what might be going on here? I'm compiling using GHC
> 7.10.1. This happens in a clean build tree.
>
> Janek
>
> ---
> Politechnika Łódzka
> Lodz University of Technology
>
> Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
> pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
>
> This email contains information intended solely for the use of the
> individual to whom it is addressed. If you are not the intended recipient
> or if you have received this message in error, please notify the sender and
> delete it from your system.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Pretty-printing TH data types

[Jan Stolarek]

Devs,

Module Language.Haskell.TH.Ppr defines Ppr instances for Template Haskell data 
types. What is the 
fastest way of testing these instances, ie. pretty-printing TH data types? I 
want to make sure 
that the instances I added print the data type in the way that I expect.

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Pretty-printing TH data types

[Jan Stolarek]

Yes, that does the job. Thanks.

Janek

Dnia środa, 11 listopada 2015, Richard Eisenberg napisał:
> Does this Template Haskell template work for you?
>
> > {-# LANGUAGE TemplateHaskell #-}
> >
> > module TestTH where
> >
> > import Language.Haskell.TH.Ppr
> > import Language.Haskell.TH
> >
> > $( do expr <- [| \x -> case x of True -> not; False -> id |]
> >   runIO $ putStrLn $ pprint expr
> >   return [] )
>
> Richard
>
> On Nov 11, 2015, at 6:14 AM, Jan Stolarek <jan.stola...@p.lodz.pl> wrote:
> > Devs,
> >
> > Module Language.Haskell.TH.Ppr defines Ppr instances for Template Haskell
> > data types. What is the fastest way of testing these instances, ie.
> > pretty-printing TH data types? I want to make sure that the instances I
> > added print the data type in the way that I expect.
> >
> > Janek
> >
> > ---
> > Politechnika Łódzka
> > Lodz University of Technology
> >
> > Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> > Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
> > pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
> >
> > This email contains information intended solely for the use of the
> > individual to whom it is addressed. If you are not the intended recipient
> > or if you have received this message in error, please notify the sender
> > and delete it from your system.
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Building stage1 only

[Jan Stolarek]

> it's very easy to end up in a state where `make` simply can't build, and only
> easy fix is a `make clean`
Out of sheer curiosity: in what situations does that happen for you? *If* you 
are working on a 
single branch, ie. you're not switching back and forth between master and your 
feature branches, 
this should not happen (and even if you switch between branches it should still 
be safe for most 
of the time). Richard already gave you a trick (cd ghc/ && make 2) that allows 
to build only 
stage 2 compiler without rebuilding stage 1 or any of the libraries. One 
situation that comes to 
my mind that can really require a full rebuild is changing format of interface 
files. But other 
than that you shouldn't have to do a full rebuild too often.

I know how you feel. When I started working on GHC I had to do a full rebuild 
very often. But now 
I improved my workflow and only do a full build after a major rebase of my 
branch against master. 

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: is this change in TH error message intentional?

[Jan Stolarek]

Ömer, can you show us the source of Main.hs?

Janek

Dnia poniedziałek, 19 października 2015, Ömer Sinan Ağacan napisał:
> Hi all,
>
> I realized this change in TH error messages:
>
> GHC 7.10.2:
>
> ➜  th-test  ghc --make Main.hs
> [1 of 1] Compiling Main ( Main.hs, Main.o )
>
> Main.hs:13:15:
> Not in scope: ‘locaton’
> Perhaps you meant ‘location’ (imported from
> Language.Haskell.TH.Syntax) In the splice: $locaton
>
> Main.hs:13:15:
> GHC stage restriction:
>   ‘locaton’ is used in a top-level splice or annotation,
>   and must be imported, not defined locally
> In the expression: locaton
> In the splice: $locaton
>
> I think both error messages are quite useful in this context. I don't see
> second one as redundant.
>
> However, with HEAD:
>
> ➜  th-test  ghc-stage2 --make Main.hs
> [1 of 1] Compiling Main ( Main.hs, Main.o )
>
> Main.hs:13:15: error:
> Variable not in scope: locaton :: ExpQ
> Perhaps you meant ‘location’ (imported from
> Language.Haskell.TH.Syntax)
>
> I think this new message is quite worse than previous one. First, "In the
> splice ..." part is missing. Second, "It must be imported, not defined
> locally" message is not given at all.
>
> Was this change intentional? May I ask why it's changed?
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Unlifted data types

[Jan Stolarek]

> Top-level variables may not have an unlifted type
Ah, that makes much more sense now. Thanks.

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

Re: Unlifted data types

[Jan Stolarek]

I think the wiki page is imprecise when it says:

> data unlifted UBool = UTrue | UFalse
>
> Intuitively, if you have x :: UBool in scope, you are guaranteed to have 
> UTrue or UFalse, and
> not bottom.  

But I still can say:

foo :: UBool
foo = foo

and now foo contains bottom. I know that any attempt to use foo will lead to 
its immediate 
evaluation, but that is not exactly the same as "not containing a bottom". Or 
am I missing 
something here?

Janek

Dnia wtorek, 8 września 2015, Richard Eisenberg napisał:
> I have put up an alternate set of proposals on
>
>   https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes
>
> These sidestep around `Force` and `suspend` but probably have other
> problems. They make heavy use of levity polymorphism.
>
> Back story: this all was developed in a late-evening Haskell Symposium
> session that took place in the hotel bar. It seems Edward and I walked away
> with quite different understandings of what had taken place. I've written
> up my understanding. Most likely, the Right Idea is a combination of this
> all!
>
> See what you think.
>
> Thanks!
> Richard
>
> On Sep 8, 2015, at 3:52 AM, Simon Peyton Jones  wrote:
> > |  And to
> > |  be honest, I'm not sure we need arbitrary data types in Unlifted;
> > |  Force (which would be primitive) might be enough.
> >
> > That's an interesting thought.  But presumably you'd have to use
> > 'suspend' (a terrible name) a lot:
> >
> > type StrictList a = Force (StrictList' a)
> > data StrictList' a = Nil | Cons !a (StrictList a)
> >
> > mapStrict :: (a -> b) -> StrictList a -> StrictList b
> > mapStrict f xs = mapStrict' f (suspend xs)
> >
> > mapStrict' :: (a -> b) -> StrictList' a -> StrictList' b
> > mapStrict' f Nil = Nil
> > mapStrict' f (Cons x xs) = Cons (f x) (mapStrict f xs)
> >
> >
> > That doesn't look terribly convenient.
> >
> > | ensure that threads don't simply
> > |  pass thunks between each other. But, if you have unlifted types, then
> > |  you can have:
> > |
> > |  data UMVar (a :: Unlifted)
> > |
> > |  and then the type rules out the possibility of passing thunks through
> > |  a reference (at least at the top level).
> >
> > Really? Presumably UMVar is a new primitive? With a family of operations
> > like MVar?  If so can't we just define newtype UMVar a = UMV (MVar a)
> > putUMVar :: UMVar a -> a -> IO ()
> > putUMVar (UMVar v) x = x `seq` putMVar v x
> >
> > I don't see Force helping here.
> >
> > 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: D1182: Implement improved error messages for ambiguous type variables (#10733)

[Jan Stolarek]

> In general we shouldn't commit anything that breaks validate, because
> this causes problems for other developers.  The right thing to do would
> be to mark it expect_broken before committing.
Sorry for that. I was actually thinking about marking the test as 
expect_broken, but then the 
problem would be completely hidden> I wanted to discuss a possible solution 
with Simon and Edward 
first but it looks like Thomas already found a workaround.

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

HEADS UP: interface file format change, full rebuild required

[Jan Stolarek]

I just pushed injective type families patch, which changes interface file 
format. Full rebuild of 
GHC is required after you pull.

Jan

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

Re: A GHC Library

[Jan Stolarek]

 I have thus started a wiki page here:
 https://ghc.haskell.org/trac/ghc/wiki/Library
Oh no... we aleady have such a page:

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

And, actually, we used to have two:

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

But I made an effort last year and merged the contents of these two pages into 
one.

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez 
pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Adding location information to derived code

[Jan Stolarek]

 Please open a ticket for your test case, and (if you can) fix it.  The
 location for the implicit instance should jolly well be the instance
 declaration for 'instance C Int'!
The fix is trivial and I have it on my injectivity branch. I'm really not sure 
if that problem 
manifests itself without injectivity.

Janek


 Thanks for spotting this.

 Simon

 | -Original Message-
 | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Jan
 | Stolarek
 | Sent: 10 June 2015 14:12
 | To: ghc-devs@haskell.org
 | Subject: Adding location information to derived code
 |
 | Hi devs,
 |
 | say I have:
 |
 |   class C a where
 | type F a
 | type F a = a
 |
 |   instance C Int
 |
 | During compilation of instance C Int GHC will derive a default
 | associated type instance F Int =
 | Int. That instance has no location information and so any errors that it
 | might cause will have a
 | very uninformative source code location 1:1. I want to fix this but I'm
 | not sure whether it is a
 | good idea to add location information to automatically generated code. Do
 | we make any assumptions
 | that derived code should have no location information?
 |
 | Janek
 |
 | ---
 | Politechnika Łódzka
 | Lodz University of Technology
 |
 | Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
 | Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
 | pomyłkę
 | prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
 |
 | This email contains information intended solely for the use of the
 | individual to whom it is addressed.
 | If you are not the intended recipient or if you have received this
 | message in error,
 | please notify the sender and delete it from your system.
 | ___
 | ghc-devs mailing list
 | ghc-devs@haskell.org
 | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Adding location information to derived code

[Jan Stolarek]

Hi devs,

say I have:

  class C a where
type F a
type F a = a

  instance C Int

During compilation of instance C Int GHC will derive a default associated 
type instance F Int = 
Int. That instance has no location information and so any errors that it might 
cause will have a 
very uninformative source code location 1:1. I want to fix this but I'm not 
sure whether it is a 
good idea to add location information to automatically generated code. Do we 
make any assumptions 
that derived code should have no location information?

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: RFC: Native -XCPP Proposal

[Jan Stolarek]

One thing to keep in mind is that while cpphs will solve some problems of 
system-cpp, it will also 
bring problems of its own. I, for one, have run into problems with it when 
installing Agda. There 
is a very long thread here:

https://lists.chalmers.se/pipermail/agda/2014/006975.html

and twice as more on my private inbox. We've reached no conclusion about the 
cause and the only 
solution was to use system-cpp.

Regarding licensing issues: perhaps we should simply ask Malcolm Wallace if he 
would consider 
changing the license for the sake of GHC? Or perhaps he could grant a 
custom-tailored license to 
the GHC project? After all, the project page [1] says:  If that's a problem 
for you, contact me 
to make other arrangements.

Janek

[1] http://projects.haskell.org/cpphs/

Dnia środa, 6 maja 2015, Herbert Valerio Riedel napisał:
 Hello *,

 As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension
 currently relies on the system's C-compiler bundled `cpp` program to
 provide a traditional mode c-preprocessor.

 This has caused several problems in the past, since parsing Haskell code
 with a preprocessor mode designed for use with C's tokenizer has caused
 already quite some problems[1] in the past. I'd like to see GHC 7.12
 adopt an implemntation of `-XCPP` that does not rely on the shaky
 system-`cpp` foundation. To this end I've created a wiki page

   https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp

 to describe the actual problems in more detail, and a couple of possible
 ways forward. Ideally, we'd simply integrate `cpphs` into GHC
 (i.e. plan 2). However, due to `cpp`s non-BSD3 license this should be
 discussed and debated since affects the overall-license of the GHC
 code-base, which may or may not be a problem to GHC's user-base (and
 that's what I hope this discussion will help to find out).

 So please go ahead and read the Wiki page... and then speak your mind!


 Thanks,
   HVR


 [1]: ...does anybody remember the issues Haskell packages ( GHC)
  encountered when Apple switched to the Clang tool-chain, thereby
  causing code using `-XCPP` to suddenly break due to subtly
  different `cpp`-semantics?

 ___
 Glasgow-haskell-users mailing list
 glasgow-haskell-us...@haskell.org
 http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users



---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: RFC: Native -XCPP Proposal

[Jan Stolarek]

 I want to emphasize that cpphs is actively maintained as it's pointed
 out in https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCp. The
 Agda team has found some cpphs bugs which have been *quickly* fixed by
 cpphs's author, Malcolm Wallace.
Yes. It was not my intention to imply in any way that cpphs suffers from 
maintanance issues.

 Unfortunately I have not been able to track down the problem mentioned by 
 Janek Stolarek.
Yes, and that's what gets me worried. I suppose the problem was somehow related 
to my locale 
settings although we were unable to track down the cause. I also recall someone 
else reported 
being affected by the same problem. So, until that problem is solved I would 
say it is a blocker 
as it would essentialy make development of GHC impossible for some people.

Janek



 On 6 May 2015 at 06:38, Jan Stolarek jan.stola...@p.lodz.pl wrote:
  One thing to keep in mind is that while cpphs will solve some problems of
  system-cpp, it will also bring problems of its own. I, for one, have run
  into problems with it when installing Agda. There is a very long thread
  here:
 
  https://lists.chalmers.se/pipermail/agda/2014/006975.html
 
  and twice as more on my private inbox. We've reached no conclusion about
  the cause and the only solution was to use system-cpp.
 
  Regarding licensing issues: perhaps we should simply ask Malcolm Wallace
  if he would consider changing the license for the sake of GHC? Or perhaps
  he could grant a custom-tailored license to the GHC project? After all,
  the project page [1] says:  If that's a problem for you, contact me to
  make other arrangements.
 
  Janek
 
  [1] http://projects.haskell.org/cpphs/
 
  Dnia środa, 6 maja 2015, Herbert Valerio Riedel napisał:
  Hello *,
 
  As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension
  currently relies on the system's C-compiler bundled `cpp` program to
  provide a traditional mode c-preprocessor.
 
  This has caused several problems in the past, since parsing Haskell code
  with a preprocessor mode designed for use with C's tokenizer has caused
  already quite some problems[1] in the past. I'd like to see GHC 7.12
  adopt an implemntation of `-XCPP` that does not rely on the shaky
  system-`cpp` foundation. To this end I've created a wiki page
 
https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp
 
  to describe the actual problems in more detail, and a couple of possible
  ways forward. Ideally, we'd simply integrate `cpphs` into GHC
  (i.e. plan 2). However, due to `cpp`s non-BSD3 license this should be
  discussed and debated since affects the overall-license of the GHC
  code-base, which may or may not be a problem to GHC's user-base (and
  that's what I hope this discussion will help to find out).
 
  So please go ahead and read the Wiki page... and then speak your mind!
 
 
  Thanks,
HVR
 
 
  [1]: ...does anybody remember the issues Haskell packages ( GHC)
   encountered when Apple switched to the Clang tool-chain, thereby
   causing code using `-XCPP` to suddenly break due to subtly
   different `cpp`-semantics?
 
  ___
  Glasgow-haskell-users mailing list
  glasgow-haskell-us...@haskell.org
  http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
 
  ---
  Politechnika Łódzka
  Lodz University of Technology
 
  Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
  Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
  pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
 
  This email contains information intended solely for the use of the
  individual to whom it is addressed. If you are not the intended recipient
  or if you have received this message in error, please notify the sender
  and delete it from your system.
  ___
  ghc-devs mailing list
  ghc-devs@haskell.org
  http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Tracking bugs for libraries

[Jan Stolarek]

I just noticed that bugs for several of our libraries can either be tracked on 
Trac (there is a 
corresponding entry in the Component field) or on github (issue tracking for 
that library is 
enabled in the repo). These libraries are: directory, hoopl, old-time, pretty, 
process, random 
and unix. I don't like the idea of spreading bug reports in two separate 
places, unless there is 
a good reason for doing this (eg. because we actually use our own copies of 
these libraries). So, 
is this duplication intended or accidental?

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Tracking bugs for libraries

[Jan Stolarek]

 As of a couple of months ago, we updated

 https://wiki.haskell.org/Library_submissions

 to include the definitive source for where issues should be tracked on a
 package by package basis for all of the core libraries. As we spread
 maintainership of these packages around, we found more and more people
 preferred using github issue tracking to the legacy trac.
That makes perfect sense. Thanks for clarifying. However, Hoopl is not included 
on the wiki page. 
Is that accidental or intentional omission?

Janek



 There may well wind up with parallel trac items for some items in a
 separate project issue tracker, but the primary reason for such would be
 when ghc has to respond to an external change. Most (if not all) of the
 remaining duplicate issues were pushed out to the corresponding external
 trackers.

 As we clear out the remaining issues, we might look at removing these as
 component selections in the trac.

 -Edward

  Janek
 
  ---
  Politechnika Łódzka
  Lodz University of Technology
 
  Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
  Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
  pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
 
  This email contains information intended solely for the use of the
  individual to whom it is addressed. If you are not the intended recipient
  or if you have received this message in error, please notify the sender
  and delete it from your system.
  ___
  ghc-devs mailing list
  ghc-devs@haskell.org
  http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Hoopl question

[Jan Stolarek]

 Also Ning Wang and Andreas Voellmy have taken over maintainership of Hoopl
Sadly, this is not what Hackage says.

Janek

 , 
 so they would be good people to talk to.

 Simon

 From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Michal
 Terepeta Sent: 02 May 2015 14:21
 To: ghc-devs@haskell.org
 Subject: Hoopl question

 Hi,

 I've just read through the Hoopl paper and then noticed
 https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/HooplPerformance
 which is really interesting. But it seems that there were no updates to the
 page in like 3 years, yet the new codegen seems to be using Hoopl... Does
 anyone know what is the current status of this?

 Thanks,
 Michal



---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Hoopl question

[Jan Stolarek]

 Which reminds me about another question I had -- the main reason to have
 the specialized module in GHC (instead of relying on the Hoopl one) is
 performance,
 right?
Yes. If you're interested you might look at ghc-devs archives from July and 
August 2013 - I was 
doing MSR internship at that time and I had some questions about Hoopl. You 
might find these 
helpful or interesting (well, answers, not questions :-) ).

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Hoopl question

[Jan Stolarek]

Michał,

one of my students is currently working on this:

https://ghc.haskell.org/trac/ghc/wiki/Hoopl/Cleanup

as his BSc thesis (see #8315). It might turn out that he will also have enough 
time to focus on 
performance issues in Hoopl but at this point it is hard to tell.

Janek

Dnia sobota, 2 maja 2015, Michal Terepeta napisał:
 Hi,

 I've just read through the Hoopl paper and then noticed
 https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/HooplPerformance
 which is really interesting. But it seems that there were no updates to the
 page
 in like 3 years, yet the new codegen seems to be using Hoopl... Does anyone
 know
 what is the current status of this?

 Thanks,
 Michal



---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Building patches that change format of interface files

[Jan Stolarek]

GHC Devs,

Once I compile GHC I use the cd ghc; make 2 trick to re-compile any changes. 
That however does 
not work if my code changes modify the format of interface files - the 
resulting compiler is 
unusable. In fact the only way to get a working compiler after interface format 
change that I am 
aware of is to rebuild everything from scratch. Needless to say, this takes a 
lot of time. Is 
there a better way? I'd like to test D841 but if this means rebuilding 
everything then I'll have 
to pass.

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Phabricator as bug tracker system (off topic)

[Jan Stolarek]

 we need to move Agda's bug tracker system from Google Code to something else.
Finally! I disliked Google Code so much that if I found a bug in Agda I either 
mailed it to the 
discussion list or did not report it at all.

And now on topic:
- the only project I've been using Trac for is GHC. It seems to lack some more 
advanced features 
but from a developer's perspective it conatins everything necessary to do the 
job. It can be 
customized to the needs of a project. I think the only major downside of Trac 
is that a single 
installation can only run a single project. Probably not a problem for Agda.
- GitHubs issue tracker lacks many fetures that might be essential for a larger 
project. For 
example you can't assign related issues or blocked issues. There is no way to 
add attachments or 
customize it in any way (eg. GHC Trac can list test names for a given ticket 
and connects tickets 
to phabricator). Still better than Google Code IMO.
- I've been also using and administrating Redmine. It is feature rich and much 
more intuitive than 
Trac (at least for me). One instance can run multiple projects. Major downside: 
it starts slowly 
(ie. if no one was using it recently and someone visits it the instance must be 
started and that 
takes several seconds).
- I've been also using Bugzilla, mostly to report bugs for some open-source 
project. For a pearson 
that only reports bugs it was OK. Not sure how it works for a developer.

HTH

Janek


 From some preliminary investigation, it seems Phabricator bug tracker
 system (Maniphest) is more robust than GitHub one.

 I would appreciate some feedback related to Maniphest or other bug
 tracker system.

 Thanks,



---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Phabricator as bug tracker system (off topic)

[Jan Stolarek]

 I'm using Trac for managing 5 independent internal projects without a
 problem and this is a single installation.
It looks like I'm not up to date with latest administrative Trac features. 
Sorry.

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: ANNOUNCE: GHC version 7.10.1

[Jan Stolarek]

Austin, links to x86_64 linux versions for CentOS don't work.

Janek


Dnia piątek, 27 marca 2015, Austin Seipp napisał:
 ==
 The (Interactive) Glasgow Haskell Compiler -- version 7.10.1
 ==

 The GHC Team is pleased to announce a new major release of GHC. There
 have been a number of significant changes since the last major
 release, including:

   * Several new language features and changes have been implemented:
 - Applicative is now a superclass of Monad and in the Prelude.

 - Many prelude combinators have been generalized

 - Static pointers

   * GHC now has preliminary and experimental support for DWARF based
 debugging.

   * `integer-gmp` has been completely rewritten.

   * Type-checking plugins can now extend the type checker.

   * Support for partial type signatures

   * Many bugfixes and other performance improvements.

   * Preliminary support for 'backpack' features like signatures.

   * Typeable is now generated by default for all data types automatically.

 We've also fixed a handful of issues reported since RC3:

   - A bug in the call arity analysis that would result in invalid core
 was fixed (#10176)
   - A bug in the Win32 package causing it to fail to load was fixed
 (#10165) - ghc-prim has (correctly) been bumped to version 0.4.0.0, to
 comply with the PVP.
   - Several libraries have been bumped to their latest available
 versions after coordination.

 The full release notes are here:

 https://downloads.haskell.org/~ghc/7.10.1/docs/html/users_guide/release-7-1
0-1.html


 How to get it
 ~

 The easy way is to go to the web page, which should be self-explanatory:

 https://www.haskell.org/ghc/

 We supply binary builds in the native package format for many
 platforms, and the source distribution is available from the same
 place.

 Packages will appear as they are built - if the package for your
 system isn't available yet, please try again later.


 Background
 ~~

 Haskell is a standard lazy functional programming language.

 GHC is a state-of-the-art programming suite for Haskell.  Included is
 an optimising compiler generating good code for a variety of
 platforms, together with an interactive system for convenient, quick
 development. The distribution includes space and time profiling
 facilities, a large collection of libraries, and support for various
 language extensions, including concurrency, exceptions, and foreign
 language interfaces (C, whatever). GHC is distributed under a
 BSD-style open source license.

 A wide variety of Haskell related resources (tutorials, libraries,
 specifications, documentation, compilers, interpreters, references,
 contact information, links to research groups) are available from the
 Haskell home page (see below).


 On-line GHC-related resources
 ~~

 Relevant URLs on the World-Wide Web:

 GHC home page  http://www.haskell.org/ghc/
 GHC developers' home page  http://ghc.haskell.org/trac/ghc/
 Haskell home page  http://www.haskell.org/


 Supported Platforms
 ~~~

 The list of platforms we support, and the people responsible for them,
 is here:

https://ghc.haskell.org/trac/ghc/wiki/Platforms
https://ghc.haskell.org/trac/ghc/wiki/CodeOwners

 Ports to other platforms are possible with varying degrees of
 difficulty.  The Building Guide describes how to go about porting to a
 new platform:

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


 Developers
 ~~

 We welcome new contributors.  Instructions on accessing our source
 code repository, and getting started with hacking on GHC, are
 available from the GHC's developer's site run by Trac:

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


 Mailing lists
 ~

 We run mailing lists for GHC users and bug reports; to subscribe, use
 the web interfaces at

 https://www.haskell.org/mailman/listinfo/glasgow-haskell-users
 https://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

 There are several other haskell and ghc-related mailing lists on
 www.haskell.org; for the full list, see

 https://www.haskell.org/mailman/listinfo/

 Some GHC developers hang out on #haskell on IRC, too:

 https://www.haskell.org/haskellwiki/IRC_channel

 Please report bugs using our bug tracking system.  Instructions on
 reporting bugs can be found here:

 https://www.haskell.org/ghc/reportabug


 Hashes  Signatures
 ~

 On https://downloads.haskell.org/~ghc/7.10.1/ you will find a signed
 copy of the SHA256 hashes for the tarballs, using my GPG key (0F8F
 3AA9 9235 C704 ADA0  B419 B942 AEE5 3B58 D86F).



---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o 

Extracting kind variables from LHsTyVarBndr

[Jan Stolarek]

forall hi,

is there a function somewhere in the source code that extracts kind variable 
names from 
LHsTyVarBndr? I couldn't find anything. Writing one seems a bit scary given the 
fact that not all 
fields in HsType constructors are obvious to me.

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Hoopl advice: How to extend the graph?

[Jan Stolarek]

 What function I should reach for when I want to look at each block (or
 each Last node) in an CmmGraph, possibly modifying it and possibly
 adding auxillary nodes on the way?
Take a look at Compiler.Hoopl.Block in hoopl library - it has some useful 
functions for working on 
blocks. blockSplitTail might be what you're looking for if you want to look at 
the last block. If 
you want to look at each block in a graph you most likely need postorderDfs 
from CmmUtils. I 
suggest studying one of existing Cmm passes to see how to traverse a Cmm graph 
and operate on it. 
CmmContFlowOpt seems to be a good candidate - good comments, fairly short, uses 
many functions 
that you should learn if you want to work with Cmm.

 It seems that one could use dataflowPassFwd for it, but
  * I could not find any use of it, and
  * I do not need to run an analysis along, I just want to rewrite
the blocks,
 so I am not sure if this is the right thing.
You most likely don't want to use Hoopl's machinery for doing analyses and 
optimisation passes. 
From what I know Hoopl is very slow compared to hand-written graph traversals 
and 
transformations - Edward's CmmRewriteAssignments is a good example here [1].

Does that help?

Janek

[1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Hoopl/Examples

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Arrow Development

[Jan Stolarek]

 There was a rewrite mentioned here [2]. The deSugar/DsArrows.hs [3] looks
 convoluted. Any progress or work needed?
Take a look at #7828 ticket. There was an intention to rewrite arrow desugarer 
and I worked on it 
for some time but eventually abandoned it. Sophie Taylor was planning to take 
up that work but I 
don't think she did (or at least she's been quiet for the past few months).

 Or are Arrows not used much and not worth the effort?
There are several open tickets about arrows (#5267, #5333, #5777, #344 and of 
course #7828) but at 
the moment it seems that no one really complains about these. If you use arrows 
and have a good 
idea how they work then perhaps you could fix these bugs?

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Building vector with GHC HEAD

[Jan Stolarek]

Devs,

I'm not sure if this is the best place to ask this question but I'm almost 
certain someone here 
will have the answer. I want to build upstream master branch of vector library 
using GHC HEAD and 
cabal 1.22. Alas my attempts have failed:

$ git clone g...@github.com:haskell/vector.git
$ cd vector
$ cabal sandbox init
$ cabal install -w /dane/projekty/ghc/build/inplace/bin/ghc-stage2
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: vector-0.11.0.0 (user goal)
trying: base-4.8.0.0/installed-inp... (dependency of vector-0.11.0.0)
next goal: deepseq (dependency of vector-0.11.0.0)
rejecting: deepseq-1.4.0.0/installed-inp..., 1.4.0.0 (conflict: vector =
deepseq=1.1  1.4)
rejecting: deepseq-1.3.0.2 (conflict: base==4.8.0.0/installed-inp..., deepseq
= base=4.3  4.8)
trying: deepseq-1.3.0.1
next goal: array (dependency of deepseq-1.3.0.1)
rejecting: array-0.5.0.1/installed-inp..., 0.5.0.0 (conflict: deepseq =
array=0.1  0.5)
rejecting: array-0.4.0.1 (conflict: base==4.8.0.0/installed-inp..., array =
base=4.2  4.7)
rejecting: array-0.4.0.0 (conflict: base==4.8.0.0/installed-inp..., array =
base=4.2  4.6)
rejecting: array-0.3.0.3 (conflict: base==4.8.0.0/installed-inp..., array =
base=4.2  4.5)
rejecting: array-0.3.0.2, 0.3.0.1 (conflict: base==4.8.0.0/installed-inp...,
array = base=4.2  4.4)
rejecting: array-0.3.0.0 (conflict: base==4.8.0.0/installed-inp..., array =
base=3  4.4)
rejecting: array-0.2.0.0, 0.1.0.0 (conflict: base==4.8.0.0/installed-inp...,
array = base4.3)
Dependency tree exhaustively searched.

The problem arises from vector requiring deepseq  1.4 when intree package db 
contains deepseq 
1.4. Removing the upper bound on deepseq in vector.cabal allows to resolve 
dependencies but ends 
with a build error:

Data/Vector/Primitive/Mutable.hs:78:10:
No instance for (GHC.Generics.Generic (MVector s a))
  arising from a use of ‘Control.DeepSeq.$gdmrnf’
In the expression: Control.DeepSeq.$gdmrnf
In an equation for ‘rnf’: rnf = Control.DeepSeq.$gdmrnf
In the instance declaration for ‘NFData (MVector s a)’

Fixing this error (importing GHC.Generics  deriving `Generic` instance for 
`MVector s a`) leads 
to another one:

Data/Vector/Primitive/Mutable.hs:80:10:
No instance for (Control.DeepSeq.GNFData (Rep (MVector s a)))
  arising from a use of ‘Control.DeepSeq.$gdmrnf’
In the expression: Control.DeepSeq.$gdmrnf
In an equation for ‘rnf’: rnf = Control.DeepSeq.$gdmrnf
In the instance declaration for ‘NFData (MVector s a)’

This time I have no idea how to fix it since GNFData is an internal class of 
Control.Deepseq 
module. Help?

Aside: at first I thought vector is one of the boot libraries since it is kept 
in the source tree. 
But then I realized it is not being build during bootstrapping. Why do we keep 
it in the source 
tree then?

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Put Error: before error output

[Jan Stolarek]

 error is not always shown last on multi-core build.
Somewhat related: #9219

Janek


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

Re: vectorisation code?

[Jan Stolarek]

Would it be possible to turn vectorisation into a compiler plugin? This would 
kill two birds with 
one stone: vectorisation would be removed from GHC sources and at the same time 
the code could be 
maintained by Geoffrey or anyone else who would want to take it up. I'm not 
sure what would 
happen with DPH in that scenario.

Janek

Dnia czwartek, 22 stycznia 2015, Manuel M T Chakravarty napisał:
 Thanks for the offer, Geoff.

 Under these circumstances, I would also very much prefer for Geoff getting
 the code in order and leaving it in GHC.

 Manuel

  Geoffrey Mainland mainl...@apeiron.net:
 
  I'm sorry I'm a bit late to the game here, but there is also the option
  of reconnecting DPH to the build.
 
  When I patched DPH for the new version of the vector library, I did not
  perform this step---now I'm sorry I didn't.
 
  I am willing to get DPH in working order again---I believe the required
  work will be minimal. However, that only makes sense if we 1) re-enable
  DPH in the nightly builds (and also by default for validate?), and 2)
  folks will not object too strenuously to having DPH stick around.
 
  My fear is that without making it part of the nightly builds,
  accumulated bitrot will make it extremely difficult to ever re-integrate
  DPH. I would hate to see that happen.
 
  Geoff
 
  On 01/21/2015 04:11 PM, Simon Peyton Jones wrote:
  I’ve had a chat to Manuel.  He is content for us to remove DPH code
  altogether (not just CPP/comment it out), provided we are careful to
  signpost what has gone and how to get it back.
 
 
 
  I am no Git expert, so can I leave it to you guys to work out what to
  do?  The specification is:
 
  ·It should be clear how to revert the change; that is, to
  re-introduce the deleted code.  I guess that might be “git revert
  some horrible hash”
 
  ·If someone trips over more DPH code later, and wants to
  remove that too, it should be clear how to add it to the list of
  things to be revertred.
 
  ·We should have a Trac ticket “Resume work on DPH and
  vectorisation” or something like that, which summarises the reversion
  process.
 
 
 
  Just to be clear, this does not indicate any lack of interest in DPH
  on my part.  (Quite the reverse.)   It’s just that while no one is
  actually working on it, we should use our source code control system
  to move it out of the way, as others on this thread have persuasively
  argued.
 
 
 
  Manuel, yell if I got anything wrong.
 
 
 
  Thanks!
 
 
 
  Simon
 
 
 
 
 
 
 
 
 
 
 
  *From:*ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of
  *Carter Schonwald
  *Sent:* 21 January 2015 03:32
  *To:* RodLogic
  *Cc:* Manuel M T Chakravarty; ghc-devs@haskell.org
  *Subject:* Re: vectorisation code?
 
 
 
  moving it to its own submodule is just a complicated version of
  cutting a branch that has the code Right before deleting it from master.
 
  afaik, the amount of love needed is roughly one or more full time
  grad students really owning it, though i could be wrong.
 
 
 
 
 
  On Tue, Jan 20, 2015 at 5:39 AM, RodLogic d...@rodlogic.net
  mailto:d...@rodlogic.net wrote:
 
 (disclaimer: I know nothing about the vectorization code)
 
 
 
 Now, is the vectorization code really dead code or it is code that
 needs love to come back to life? By removing it from the code
 base, you are probably sealing it's fate as dead code as we are
 limiting new or existing contributors to act on it (even if it's a
 commit hash away). If it is code that needs love to come back to
 life, grep noise or conditional compilation is a small price to
 pay here, imho.
 
 
 
 As a compromise, is it possible to move vectorization code into
 it's own submodule in git or is it too intertwined with core GHC?
 So that it can be worked on independent of GHC?
 
 
 
 
 
 On Tue, Jan 20, 2015 at 6:47 AM, Herbert Valerio Riedel
 hvrie...@gmail.com mailto:hvrie...@gmail.com wrote:
 
 On 2015-01-20 at 09:37:25 +0100, Jan Stolarek wrote:
  Here's an alternate suggestion: in SimplCore, keep the call
 
 to vectorise
 
  around, but commented out
 
  Yuck. Carter and Brandon are right here - we have git, let
 
 it do the
 
  job. I propose that we remove vectorization code, create a
 
 Trac ticket
 
  about vectorization  DPH needing love and record the commit
 
 hash in
 
  the ticket so that we can revert it easily in the future.
 
 I'm also against commenting out dead code in the presence of a
 VCS.
 
 Btw, here's two links discussing the issues related to
 commenting out if
 anyone's interested in knowing more:
 
  -

  http://programmers.stackexchange.com/questions/190096/can-commented-out-
 code-be-valuable-documentation
 
  -

  http://programmers.stackexchange.com/questions/45378/is-commented-out-co
 de-really-always-bad
 
 
 Cheers,
   hvr

Re: vectorisation code?

[Jan Stolarek]

 Here's an alternate suggestion: in SimplCore, keep the call to vectorise
 around, but commented out
Yuck. Carter and Brandon are right here - we have git, let it do the job. I 
propose that we remove 
vectorization code, create a Trac ticket about vectorization  DPH needing love 
and record the 
commit hash in the ticket so that we can revert it easily in the future.

Janek

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

Re: vectorisation code?

[Jan Stolarek]

Out of curiosity I removed vectorisation code and did a devel2 build. Build 
time on my laptop went 
down from 25 minutes to 24 minutes - a modest 4% improvement. Of course there 
is more to be 
gained by avoiding recompilations later during development.

 I would obviously prefer to leave the code in, in the hope that we will be 
 able to return to it.
Is this just hope or are there any actual plans to attempt to return to DPH? (I 
assume this has to 
do with funding.)

Janek

Dnia piątek, 16 stycznia 2015, Simon Peyton Jones napisał:
 |  What's the plan for DPH and 7.10? Is it bitrotting or abandoned, and
 |  does this mean there weren't enough users of it to notice and help
 |  maintain it?

 For 7.10, DPH is definitely not supported, I'm afraid.

 For a longer term vision I defer to Manuel!

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

API Annotations question

[Jan Stolarek]

Alan, devs,

since API annotations were added some data types in the source code have extra 
comments related to 
these annotations, eg.

-- | A type or class declaration.
data TyClDecl name
  = -- | @type/data family T :: *-*@
--
--  - 'ApiAnnotation.AnnKeywordId' : 'ApiAnnotation.AnnType',
-- 'ApiAnnotation.AnnData',
-- 'ApiAnnotation.AnnFamily','ApiAnnotation.AnnWhere',
-- 'ApiAnnotation.AnnOpen','ApiAnnotation.AnnDcolon',
-- 'ApiAnnotation.AnnClose'
FamDecl { tcdFam :: FamilyDecl name }

I'm totally clueless about what these comments mean. Where can I find an 
explanation? Couldn't 
find anything on the wiki.

Janek

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

Re: API Annotations question

[Jan Stolarek]

 I am not sure what the best way is to add an internal source code link to
 it too without disturbing the haddock. I am open for suggestions.
For me as a developer the most important thing is when and how do I need to 
add/modify these 
comments when working with the source code? First place where I started looking 
was the wiki but 
surprisingly I couldn't find a page about API annotations. Does such a page 
exist?
The best thing IMO would be to add for each data type reference to a Note that 
explains how to 
work with these annotations. But I'm not sure if that's feasible. How many data 
types have these 
annotations?

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

Re: API Annotations question

[Jan Stolarek]

 and the Wiki page is https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations
I read this page and I don't feel it answers my questions as it mostly seems to 
talk about the 
design. As a side note I don't understand the discussion of the design either. 
Eg. the wiki page 
lists four helper functions in the parser - gj, gl, aa, ams - but does not show 
how to use them 
and omits several other functions from the parser.

 They need to be updated whenever the Parser.y changes in a way that one of
 the keywords that is not otherwise captured in the AST is introduced, or
 moved.

1. How should I update the comment? For example I see that the list of 
annotations in the comment 
is preceeded with a dash. Is that mandatory? Why some annotations are separated 
by a colon and 
some by a comma:

--  - 'ApiAnnotation.AnnKeywordId' : 'ApiAnnotation.AnnType',
-- 'ApiAnnotation.AnnData',

2. How can I verify that my comments is correct? How do errors manifest?

Is there a source code note that answers these questions? Are there any 
examples showing what to 
do when?

All in all I feel totally lost with annotations. When changing the parser I'm 
mostly doing trial 
and error because I still don't know how to use all annotation functions in the 
parser. I'm 
struggling to understand this but haddock comments in the parser don't suffice 
for me.

Janek


 Alan

 On Thu, Jan 15, 2015 at 3:48 PM, Jan Stolarek jan.stola...@p.lodz.pl

 wrote:
   I am not sure what the best way is to add an internal source code link
   to it too without disturbing the haddock. I am open for suggestions.
 
  For me as a developer the most important thing is when and how do I need
  to add/modify these
  comments when working with the source code? First place where I started
  looking was the wiki but
  surprisingly I couldn't find a page about API annotations. Does such a
  page exist?
  The best thing IMO would be to add for each data type reference to a Note
  that explains how to
  work with these annotations. But I'm not sure if that's feasible. How
  many data types have these
  annotations?
 
  Janek



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

Re: vectorisation code?

[Jan Stolarek]

I share Richard's opinion.

Janek

Dnia wtorek, 13 stycznia 2015, Richard Eisenberg napisał:
 Hi devs,

 There's a sizable number of modules in the `vectorise` subdirectory of GHC.
 I'm sure these do all sorts of wonderful things. But what, exactly? And,
 does anyone make use of these wonderful things?

 A quick poking through the code shows a tiny link between the vectorise
 code and the rest of GHC -- the function `vectorise` exported from the
 module `Vectorise`, which is named in exactly one place from SimplCore.
 From what I can tell, the function will be called only when `-fvectorise`
 is specified, and then it seems to interact with a {-# VECTORISE #-}
 pragma. However, `{-# VECTORISE #-}` doesn't appear in the manual at all,
 and `-fvectorise` is given only a cursory explanation. It seems these work
 with DPH... which has been disabled, no? Searching online finds several
 hits, but nothing more recent than 2012.

 I hope this question doesn't offend -- it seems that vectorisation probably
 has amazing performance gains. Yet, the feature also seems unloved. In the
 meantime, compiling (and recompiling, and recompiling...) the modules takes
 time, as does going through them to propagate changes from elsewhere. If
 this feature is truly orphaned, unloved, and unused at the moment, is it
 reasonable to consider putting it on furlough?

 Thanks,
 Richard
 ___
 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: Deprecating functions

[Jan Stolarek]

 I agree. You'll get rid of the redundancy in the library by removing it but
 you're users will have to live with (...)
That's why I want to deprecate them first and give users one release cycle to 
switch to new 
functions. I assumed that's enough but we could make this two or three release 
cycles. The reall 
question is how to remember that we should remove this at some point?

Janek


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

Deprecating functions

[Jan Stolarek]

I want to deprecate some Template Haskell functions in GHC 7.12 and then remove 
them in GHC 7.14 
(or whatever version that comes after 7.12). Do we have any workflow for 
remembering these kind 
of things? I was thinking about adding a conditional error:

#if __GLASGOW_HASKELL__  712
#error Remove functions foo bar from TH
#endif

Is this a good way of doing this? Or should I do it differently?

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

Re: Deprecating functions

[Jan Stolarek]

 We could file a tracking bug against the 7.14 milestone.
I was considering that but we don't have 7.14 milestone yet.

 Just curious, is there a way to keep these functions for backwards compat
 in 7.14 or is that unfeasible?
They could stay, technically that's not a problem. But I'm adding new functions 
that can do the 
same thing (and more), so we have redundancy.

Janek


 On Fri, Jan 9, 2015 at 10:22 AM, Jan Stolarek jan.stola...@p.lodz.pl

 wrote:
  I want to deprecate some Template Haskell functions in GHC 7.12 and then
  remove them in GHC 7.14
  (or whatever version that comes after 7.12). Do we have any workflow for
  remembering these kind
  of things? I was thinking about adding a conditional error:
 
  #if __GLASGOW_HASKELL__  712
  #error Remove functions foo bar from TH
  #endif
 
  Is this a good way of doing this? Or should I do it differently?
 
  Janek
  ___
  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: Deprecating functions

[Jan Stolarek]

 I think Java's (!) policy for deprecation is good
I think it's not. It keeps the library code a mess and many times I have seen 
users using 
functions that have been deprecated for years just because it's easier to 
suppress a warning than 
change the code. I don't want Haskell to go down that path and I'm strongly in 
favour of removing 
these functions. Especially that we're talking about internal TH module - I'll 
be surprised if 
there are more than 10 users.

Janek

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

Re: Bash completion in GHC 7.10

[Jan Stolarek]

Reported this as #9963.

Janek

Dnia sobota, 3 stycznia 2015, Sergei Trofimovich napisał:
 On Wed, 10 Dec 2014 16:43:57 +0400

 Lennart Kolmodin kolmo...@gmail.com wrote:
  Hi everybody!
 
  TL;DL GHC 7.10 will have better bash completion, try it out! I'd like
  your help to verify the categorisation of DynFlags into ghc / ghci /
  shared or hidden flags.

 Thank you! On the way to users :)
 https://github.com/gentoo-haskell/gentoo-haskell/commit/d6f63341693063e6016
8bbddffb0806621696689

   sf / # ghc --print-liTABENTER
   /usr/lib64/ghc-7.10.0.20141222

   sf / # ghci --print-liTABENTER
   ghc: panic! (the 'impossible' happened)
 (GHC version 7.10.0.20141222 for x86_64-unknown-linux):
   ghc: panic! (the 'impossible' happened)
 (GHC version 7.10.0.20141222 for x86_64-unknown-linux):
   v_unsafeGlobalDynFlags: not initialised
   Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
   Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

 Absolutely not your fault, just makes such things more discoverable :]
 Thanks again!



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

How do I investigate parser conflicts?

[Jan Stolarek]

I noticed that changes I made to the Parser on my branch increase the number of 
reduce/reduce 
conflicts. Are there any tools/techniques/etc I can use to investigate this? Or 
do I just have to 
use trial and error (possibly guided with some knowledge of parsing)? 
Specifically, is there any 
way I can check which productions are causing conflicts?

Janek

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

Re: How do I investigate parser conflicts?

[Jan Stolarek]

Yes, that's probably what I was looking for. Thanks. 

Janek

PS. Only 55K lines of log to analyze...
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Fatal: Reference is not a tree

[Jan Stolarek]

That's because I updated haddock submodule but that update was not pushed to 
Phab. I was able to 
do a quick build of my patch without updating haddock so it should only be a 
problem if you try 
to validate.

That said, is there a way I can push changes in a submodule to a phab revision?

Janek

Dnia poniedziałek, 22 grudnia 2014, Simon Peyton Jones napisał:
 Dear devs

 When doing 'arc patch' I got

 fatal: reference is not a tree: d809f9d656780273f4f79e7a9fb934f783f79702
 Unable to checkout 'd809f9d656780273f4f79e7a9fb934f783f79702' in submodule
 path 'utils/haddock'

 Should I worry?

 Simon


 simonpj@cam-05-unx:~/code/HEAD-2$ arc patch D202
 arc patch D202
 You have untracked files in this working copy.

   Working copy: /home/simonpj/code/HEAD-2/

   Untracked files in working copy:
 flat-skol-diff
 foo
 foo2
 index.html.1
 index.html.2
 index.html.3
 resume
 spj-patch
 spj-patch-save
 testsuite/mk/ghcconfig_home_simonmar_fp_bin_x86_64-unknown-linux_ghc.mk
 testsuite/tests/simplCore/should_compile/T8538.hs
 testsuite/tests/simplCore/should_compile/T9073.hs
 tmp-patch
 untch-patch

 Since you don't have '.gitignore' rules for these files and have not listed
 them in '.git/info/exclude', you may have forgotten to 'git add' them to
 your commit.


 Do you want to amend these files to the commit? [y/N] n
 n

 Created and checked out branch arcpatch-D202.
 Checking patch compiler/basicTypes/MkId.hs...
 Checking patch compiler/basicTypes/NameEnv.hs...
 Checking patch compiler/basicTypes/VarSet.hs...
 Checking patch compiler/deSugar/DsMeta.hs...
 Checking patch compiler/hsSyn/Convert.hs...
 Checking patch compiler/hsSyn/HsDecls.hs...
 Checking patch compiler/hsSyn/PlaceHolder.hs...
 Checking patch compiler/iface/BuildTyCl.hs...
 Checking patch compiler/iface/IfaceSyn.hs...
 Checking patch compiler/iface/MkIface.hs...
 Checking patch compiler/iface/TcIface.hs...
 Checking patch compiler/main/GHC.hs...
 Checking patch compiler/main/HscTypes.hs...
 Checking patch compiler/parser/ApiAnnotation.hs...
 Checking patch compiler/parser/Parser.y...
 Checking patch compiler/parser/RdrHsSyn.hs...
 Checking patch compiler/prelude/TysPrim.hs...
 Checking patch compiler/rename/RnSource.hs...
 Checking patch compiler/rename/RnTypes.hs...
 Checking patch compiler/typecheck/FamInst.hs...
 Checking patch compiler/typecheck/TcEnv.hs...
 Checking patch compiler/typecheck/TcEvidence.hs...
 Checking patch compiler/typecheck/TcInstDcls.hs...
 Checking patch compiler/typecheck/TcRnDriver.hs...
 Checking patch compiler/typecheck/TcRnMonad.hs...
 Checking patch compiler/typecheck/TcSplice.hs...
 Checking patch compiler/typecheck/TcTyClsDecls.hs...
 Checking patch compiler/typecheck/TcTypeNats.hs...
 Checking patch compiler/typecheck/TcValidity.hs...
 Checking patch compiler/types/CoAxiom.hs...
 Checking patch compiler/types/Coercion.hs...
 Checking patch compiler/types/FamInstEnv.hs...
 Checking patch compiler/types/Kind.hs...
 Checking patch compiler/types/OptCoercion.hs...
 Checking patch compiler/types/TyCon.hs...
 Checking patch compiler/types/TypeRep.hs...
 Checking patch compiler/types/TypeRep.hs-boot...
 Checking patch compiler/utils/Outputable.hs...
 Checking patch compiler/vectorise/Vectorise/Generic/PADict.hs...
 Checking patch compiler/vectorise/Vectorise/Generic/PAMethods.hs...
 Checking patch compiler/vectorise/Vectorise/Type/Env.hs...
 Checking patch compiler/vectorise/Vectorise/Utils/PADict.hs...
 Checking patch libraries/template-haskell/Language/Haskell/TH.hs...
 Checking patch libraries/template-haskell/Language/Haskell/TH/Lib.hs...
 Checking patch libraries/template-haskell/Language/Haskell/TH/Ppr.hs...
 Checking patch libraries/template-haskell/Language/Haskell/TH/PprLib.hs...
 Checking patch libraries/template-haskell/Language/Haskell/TH/Syntax.hs...
 Checking patch testsuite/tests/ghci/scripts/T6018ghci.script...
 Checking patch testsuite/tests/ghci/scripts/T6018ghci.stdout...
 Checking patch testsuite/tests/ghci/scripts/T6018ghcifail.script...
 Checking patch testsuite/tests/ghci/scripts/T6018ghcifail.stderr...
 Checking patch testsuite/tests/ghci/scripts/T6018ghcirnfail.script...
 Checking patch testsuite/tests/ghci/scripts/T6018ghcirnfail.stderr...
 Checking patch testsuite/tests/ghci/scripts/all.T...
 Checking patch testsuite/tests/rename/should_fail/T6018rnfail.hs...
 Checking patch testsuite/tests/rename/should_fail/T6018rnfail.stderr...
 Checking patch testsuite/tests/rename/should_fail/all.T...
 Checking patch testsuite/tests/typecheck/should_compile/T6018.hs...
 Checking patch testsuite/tests/typecheck/should_compile/T6018.hs-boot...
 Checking patch testsuite/tests/typecheck/should_compile/T6018.stderr...
 Checking patch testsuite/tests/typecheck/should_compile/T6018a.hs...
 Checking patch testsuite/tests/typecheck/should_compile/all.T...
 Checking patch testsuite/tests/typecheck/should_fail/T6018Afail.hs...
 Checking patch 

Re: Fatal: Reference is not a tree

[Jan Stolarek]

 Haddock is on Phabricator and has an .arcconfig file. All you need to
 do is submit a revision like normally, just run 'arc diff' in the
 Haddock directory.
But this will create a separate revision for haddock, right? My changes in 
haddock are related to 
revision I am working on. What I would want to do is somehow have my haddock 
changes uploaded as 
part of the diff.

 Also, since you have push access to the repository, you can always
 just push your Haddock changes to a branch; for example, commit them
 to 'wip/my-cool-thing' and push that branch publicly. Then point your
 utils/haddock to that SHA1, and 'arc diff'. The rest should work just
 fine when you run 'arc patch' or 'arc diff', or when Harbormaster
 builds it.
Ok, I suppose this will suffice.

Janek

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

Re: Can we rename completion to autocomplete

[Jan Stolarek]

Done. I moved completion/ directory to utils/

Janek

Dnia czwartek, 18 grudnia 2014, Austin Seipp napisał:
 I'd say just move it under utils/. We really need to organize the
 top-folder more, but that's for another day.

 On Thu, Dec 18, 2014 at 11:18 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote:
  Bump. Any decisions on this one? If not then I'll move that folder
  somewhere else because it's getting in the way.
 
  Janek
 
  ___
  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 we rename completion to autocomplete

[Jan Stolarek]

Bump. Any decisions on this one? If not then I'll move that folder somewhere 
else because it's 
getting in the way.

Janek

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

RFC: Remove -fwarn-unticked-promoted-constructors from -Wall

[Jan Stolarek]

We recently got a new warning -fwarn-unticked-promoted-constructors (see #9778 
and D534). This 
warning is enabled with -Wall but I think that this is not a good idea. I 
strongly propose to 
remove it with -Wall.

Rationale:
1. I feel that ticks add unnecessary noise:

prDictOfPReprInstTyCon :: Type - CoAxiom 'Unbranched - [Type] - VM CoreExpr

To me it feels awkward to have Unbranched with a tick but CoreExpr without a 
tick (both are types 
after all). Moreover, ticks also trip many syntax highlighters, which further 
degrades code 
readability.

2. I've been refactoring some of GHC code to use promoted types instead of 
empty data types (see 
CoAxiom.BranchList). This would have been a fairly local change, except that I 
have to add ticks 
in every place that mentiones promoted types. That's a Royal Pain and a good 
example how this 
warning can get in people's way.

Janek

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

Understanding DsMeta module

[Jan Stolarek]

I'm implementing Template Haskell support for injective type families and I'm 
struggling to 
understand DsMeta module. It seems that all functions in that module delegate 
their calls to 
functions in Language.Haskell.TH.Lib via wired-in names and the `DsMeta.rep2` 
function. I'm 
puzzled by this design and I'd appreciate if someone could explain why things 
are done this way. 
Take this function example:

repPlainTV :: Core TH.Name - DsM (Core TH.TyVarBndr)
repPlainTV (MkC nm) = rep2 plainTVName [nm]

where `plainTvName` is a name of `Language.Haskell.TH.Lib.plainTV`:

plainTV :: Name - TyVarBndr
plainTV = PlainTV

Why not implement repPlainTV like this: ?

repPlainTV :: Core TH.Name - DsM (Core TH.TyVarBndr)
repPlainTV (MkC nm) = return $ MkC (TH.PlainTV nm)

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

Re: Understanding DsMeta module

[Jan Stolarek]

Thanks. That helps but I still don't understand why the calls are delegated to 
template-haskell 
library. Couldn't all of this be done locally?

Janek

Dnia środa, 17 grudnia 2014, Richard Eisenberg napisał:
 On Dec 17, 2014, at 12:29 PM, Jan Stolarek jan.stola...@p.lodz.pl wrote:
  Why not implement repPlainTV like this: ?
 
  repPlainTV :: Core TH.Name - DsM (Core TH.TyVarBndr)
  repPlainTV (MkC nm) = return $ MkC (TH.PlainTV nm)

 In short, that's ill typed. We have

  newtype Core a = MkC CoreExpr

 The idea behind this type is that its (phantom) type parameter tracks the
 type of the expression stored within. Of course, the thing within is always
 just a core expression. TH.PlainTV takes a TH.Name and produces a
 TH.TyVarBndr. But, nm is a CoreExpr and MkC is expecting a CoreExpr, so
 your suggestion wouldn't type check.

 The higher-level answer is that you're mixing levels. The goal in DsMeta is
 *not* to create the TH AST. It's to create *core expressions* that create
 the TH AST.

 Does this help?

 Richard


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

Re: performance regressions

[Jan Stolarek]

 Using this combinator instead of writing the algorithm directly cost me 30%
 allocation overhead!
What does your algorithm look like when you write it directly? Something like 
this:

flatten_many fmode roles tys
 = unzip `liftM` mapM go (zip roles tys)
 where
   go (Nominal,ty)  = flatten_one (fmode { fe_eq_rel = NomEq }) ty
   go (Representational,ty) = flatten_one (fmode { fe_eq_rel = ReprEq }) ty
   go (Phantom, ty) = -- See Note [Phantoms in the flattener]
  return (ty, mkTcPhantomCo ty ty)

?

Maybe this has something to do with `zipWithAndUnzipM` not being tail-recursive 
vs. direct version 
being able to fuse intermediate lists?

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

Customizing Phab

[Jan Stolarek]

After working with Phab for a while I realize I'd like to customize layout of a 
revision. When I 
work with a revision I most often read comments and source code and write my 
replies (often based 
on comments). The problem is that comments are located at the top of a page 
whereas the text 
field for writing a reply is located at the bottom. I wonder if there is a way 
to:

a) collapse Revision Update History, Local Commits, Table of Contents and 
Open Revisions 
Affecting These Files?
b) or move them below Leap Into Action section ?

I can't find any such settings so I suppose that's not possible by default. Is 
there any way to 
extend Phab's functionality do allow customizing layout in a way described 
above?

Janek

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

Re: Customizing Phab

[Jan Stolarek]

 Not a direct answer to your question, but have you tried the 'z' hotkey
 (or keyboard shortcut) while in a revision? It cycles comment panel
 haunting modes (see '?' hotkey for a list of other useful hotkeys).
I wasn't aware of that. This helps to some extent. Being able to hide unused 
panels would still be 
nice.

Janek

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

Re: Reachable modules from DynFlags out of date

[Jan Stolarek]

 I suspect you need to add all of
I believe Simon needs to figure out the diff, ie. which modules are displayed 
in the dependency 
list but are missing in the compiler/ghc.mk file. I recall I had to done the 
same in one of my 
commits:

https://github.com/jstolarek/ghc/commit/53948f915140396acd1b80c6a7a252b2d1e12635#diff-ba0ee6a425ab9ec6d7a2ef6c394ba455

Janek

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

Re: -O/-O2 causes program to run too slow

[Jan Stolarek]

While I don't know how to help with your problem I encourage you to attach your 
code example to 
#1168. This will certainly be helpful in working on that bug.

Janek

Dnia niedziela, 7 grudnia 2014, David Spies napisał:
 Ok, so I found that it was an instance of this:
 https://ghc.haskell.org/trac/ghc/ticket/1168
 and I read through this whole thread:
 https://www.haskell.org/pipermail/glasgow-haskell-users/2008-February/01425
9.html

 I don't understand the state-hack optimization.  It's clearly not safe and
 I'm not convinced that it actually is an optimization.  In what
 circumstances does the state-hack identify a single-entry function that
 can't be identified as single-entry by some other (safe) method?

 On Sun, Dec 7, 2014 at 10:52 AM, David Spies dnsp...@gmail.com wrote:
  I have a program I wrote to submit for the Car Game problem on Kattis:
  https://open.kattis.com/problems/cargame
  but it runs over the 5-second time-limit
 
  I downloaded the test data and found that on GHC 7.8.3, if I switch from
  -O2 to -O0, it runs three times faster (almost certainly fast enough for
  Kattis to accept).  Can someone tell me what's going on?  Is this a bug?


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

Re: ghc.haskell.org slow?

[Jan Stolarek]

Works fine for me.

Janek

Dnia poniedziałek, 8 grudnia 2014, Simon Peyton Jones napisał:
 Is it just me, or is access to ghc.haskell.org and git.haskell.org very
 slow?

 I guess it could be at my end; I don't know how to tell.  But git pull and
 Trac access takes tens of seconds, even minutes

 Simon



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

Re: HEADS UP: I'm removing the remaining .lhs files in compiler/ soon

[Jan Stolarek]

 me and Herbert really really wanted to remove all the .lhs files in the 
 compiler.
I'll only say one thing:

   FINALLY !

Janek

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

Re: Possible error with strict_mark in Parser.y

[Jan Stolarek]

Looking at the source code comments it seems that you're right:

data HsBang
  = HsUserBang   -- The user's source-code request
   (Maybe Bool)   -- Just True{-# UNPACK #-}
  -- Just False   {-# NOUNPACK #-}
  -- Nothing  no pragma
   Bool   -- True = '!' specified


Can anyone confirm?

Janek

Dnia niedziela, 30 listopada 2014, Alan  Kim Zimmerman napisał:
 If I look at the production for strict_mark in the parser

 https://github.com/ghc/ghc/blob/master/compiler/parser/Parser.y#L1355

 strict_mark :: { Located ([AddAnn],HsBang) }

 : '!'{ sL1 $1 ([],HsUserBang Nothing

 True) }

 | '{-# UNPACK' '#-}' { sLL $1 $ ([mo $1,mc $2],HsUserBang

 (Just True)  False) }

 | '{-# NOUNPACK' '#-}'   { sLL $1 $ ([mo $1,mc $2],HsUserBang

 (Just False) True) } -- ***Correct?

 | '{-# UNPACK' '#-}' '!' { sLL $1 $ ([mo $1,mc $2],HsUserBang

 (Just True)  True) }

 | '{-# NOUNPACK' '#-}' '!'   { sLL $1 $ ([mo $1,mc $2],HsUserBang

 (Just False) True) }

 I would expect the final True or False value to reflect the presence of the
 '!' mark.

 But the second line has no '!' but returns True.

 I suspect this is an error.

 Alan



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

Re: Performance regression on typechecking type families?

[Jan Stolarek]

I personally have run into exponential compile times with type families. 
Unfortunately I have not 
had the time yet to reduce my test case to something tractable.

Janek

Dnia sobota, 29 listopada 2014, Dr. ERDI Gergo napisał:
 Hi,

 Prompted by this question:
 http://stackoverflow.com/questions/26538595/more-efficient-type-level-compu
tations-using-type-families I wrote some code today using closed type
 families and datakinds. Also, as a baseline, I typechecked the code using
 open type families from
 the original question.

 The two files are here:

 https://gist.github.com/gergoerdi/727f028e4c1ed158ac9a
 https://gist.github.com/gergoerdi/f96d1a9a58f5e3dccc18

 On GHC 7.8.3, typechecking took about 45 seconds for each. However, on a
 'perf' build of GHC 7.9 d8c437b3, with ghc-stage2, the first one took 1m3s
 and the second one 1m12s. A 40% and 60% increase in typechecking time,
 respectively!

 Is this some known regression, something surprising, or is 'perf' simply
 not the right build flavour for this kind of comparison?

 Bye,
   Gergo
 ___
 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: Back-porting pattern synonym type signature syntax for GHC 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1]

[Jan Stolarek]

 My instinct is that (a)-(c) overwhelm (d); i.e. let sleeping dogs lie.
These arguments look convincing. I suppose the relevant section in the User's 
Guide should inform 
about changes planned for 7.10? To a limited extent this would address (d).

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

Re: More flexible literate Haskell extensions (Trac #9789), summary on wiki

[Jan Stolarek]

.lhs = Literate Haskell

So maybe .mhs = Markdown Haskell instead of .lhs+md?

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

Error handling in the renamer

[Jan Stolarek]

I'm improving my patch for injective type families and I have a question about 
error handling in 
the renamer. If I write this incorrect definition:

  type family F a b = r | r - c

I get these errors:

  T6018rnfail.hs:36:1: Not in scope: type variable ‘c’

  T6018rnfail.hs:36:26:
Unexpected type variable on the RHS of injectivity condition: ‘c’
All variables should be bound in type family head and appear at most once 
in exactly the same 
order as they were bound.

I don't want to report two errors here, just the first one. This means I have 
to first run the 
renaming using RnTypes.rnTyVar and check if it reports errors. If it does I 
don't report the 
extra error. The question is how do I check if this piece of code returns 
errors:

injFrom' - rnTyVar True injFrom
injTo'   - mapM (rnTyVar True) injTo

I found some combinators in TcRnMonad (tryTc and friends) but I don't know how 
to use them. 
Ideally I'd want `TcRn a - TcRn (Messages, a)` + isEmptyMessages but the 
existing combinators 
return `TcRn a - TcRn (Messages, Maybe a)`. I'm not at all happy with getting 
Nothing - even if 
renaming fails my function has to return a result.

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

HEADS UP: Keeping the Newcomers wiki page alive

[Jan Stolarek]

HEADS UP: if you see a ticket that is easy enough to be tackled by a newcomer 
please tag it 
using newcomer keyword.

I already added newcomer keyword to tickets that were listed on the Newcomers 
page and replaced 
the static list with dynamicaly generated one. I decided to filter out tickets 
that have an owner 
so that people are not redirected to tickets that are being worked on.

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