Pattern checker status

[David Feuer]

Could you possibly give us an update about the current status of your 
pattern checker work? I know the number of tickets may seem a bit 
overwhelming; please reach out to the ghc-devs list, or individual 
developers, to get whatever help you need. Knocking out some of 
these 
tickets is a priority for 8.2, and the freeze is coming up fast. In my 
mind, 
the top priorities for GHC 8.2 should probably be #10746 and #12949. 
We really want to get those squashed. I think #11195 is also a fairly 
high 
priority (if it's still an issue!).

#10746 is a serious correctness issue, and Simon's suggested fix 
sounds 
straightforward. Have you run into trouble?

#12949 is also a serious correctness issue. You're right that desugaring 
doesn't happen till after type checking, but I believe the type checker 
should have already worked out what it needs to be able to desugar 
the 
overloading. It would be worth asking how you might access that 
information.

#11195 looks like a practically important and serious performance 
problem. I know you spent some time investigating it months ago; do 
you have any more recent progress to report? Do you know if the 
problem is still there?

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

Re: nofib on Shake

[Gracjan Polak]

My time for this ticket run out and for the foreseeable future I won't be
able to do much. We can discuss ideas if you have some.

The part of nofib that is called fibno should be replaced with latest
version of packages and permanently connected to the test suite. Or
removed. This is the only sure conclusion I came to. Everything else is up
for debate.



W dniu wt., 10.01.2017 o 20:43 Michal Terepeta 
napisał(a):

> On Tue, Jan 10, 2017 at 11:35 AM Gracjan Polak 
> wrote:
> > I was looking nearby recently and you might want to take into account my
> > discoveries described in https://ghc.haskell.org/trac/ghc/ticket/11501
>
> Thanks a lot for mentioning it! (I didn't see this ticket/discussion)
>
> I don't want to get in your way - did you already start working on
> something? Do you have some concrete plans wrt. nofib?
>
> From my side, I was recently mostly interested in using nofib to
> measure the performance of GHC itself. Nofib already tries to do that,
> but it's super flaky (it only compiles things once and most modules
> are small).  So I was thinking of improving this, but when I started
> to look into it a bit closer, I decided that it might be better to
> start with the build system ;) And then add options to compile things
> more than once, add some compile-time only benchmarks, etc.
>
> Thanks,
> Michal
>
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: nofib on Shake

[Michal Terepeta]

On Tue, Jan 10, 2017 at 11:35 AM Gracjan Polak 
wrote:
> I was looking nearby recently and you might want to take into account my
> discoveries described in https://ghc.haskell.org/trac/ghc/ticket/11501

Thanks a lot for mentioning it! (I didn't see this ticket/discussion)

I don't want to get in your way - did you already start working on
something? Do you have some concrete plans wrt. nofib?

>From my side, I was recently mostly interested in using nofib to
measure the performance of GHC itself. Nofib already tries to do that,
but it's super flaky (it only compiles things once and most modules
are small).  So I was thinking of improving this, but when I started
to look into it a bit closer, I decided that it might be better to
start with the build system ;) And then add options to compile things
more than once, add some compile-time only benchmarks, etc.

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

Re: Trac to Phabricator (Maniphest) migration prototype

[Ben Gamari]

Matthew Pickering  writes:

> Dear devs,
>
> I have completed writing a migration which moves tickets from trac to
> phabricator. The conversion is essentially lossless. The trac
> transaction history is replayed which means all events are transferred
> with their original authors and timestamps. I welcome comments on the
> work I have done so far, especially bugs as I have definitely not
> looked at all 12000 tickets.
>
We discussed this a bit in this week's GHC call and the general feeling
was that it would be nice to have a comprehensive list of the pros and
cons somewhere. I pasted my notes on the Wiki [1] as a starting point.

Matthew, would you like to add your thoughts there as well?

Cheers,

- Ben

[1] https://ghc.haskell.org/trac/ghc/wiki/Phabricator/Maniphest


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

Re: Debugging GHC with GHCi

[Thomas Jakway]

Thanks very much, I'll give that a shot.


On 01/09/2017 08:12 AM, Simon Marlow wrote:
On 9 January 2017 at 04:51, Ben Gamari > wrote:


Thomas Jakway > writes:

> I want to be able to load certain GHC modules in interpreted mode in
> ghci so I can set breakpoints in them.  I have tests in the
testsuite
> that are compiled by inplace/bin/ghc-stage2 with -package ghc. 
I can

> load the tests with ghc-stage2 --interactive -package ghc but
since ghc
> is compiled I can only set breakpoints in the tests themselves. 
Loading

> the relevant files by passing them as absolute paths to :l loads
them
> but ghci doesn't stop at the breakpoints placed in them (I'm
guessing
> because ghci doesn't realize that the module I just loaded is
meant to
> replace the compiled version in -package ghc).
>
> So if I use
>
> inplace/bin/ghc-stage2 --interactive -package ghc mytest.hs
> then
> :l abs/path/to/AsmCodeGen.hs
>
> and set breakpoints, nothing happens.
>
Many of us would love to be able to load GHC into GHCi. Unfortunately,
we aren't currently in a position where this is possible. The only
thing
standing in our way is the inability of GHC's interpreter to run
modules
which use unboxed tuples. While there are a few modules within GHC
which
use unboxed tuples, none of them are particularly interesting for
debugging purposes, so compiling them with -fobject-code should be
fine.
In principle this could be accomplished by,

{-# OPTIONS_GHC -fobject-code #-}

However, as explained in #10965, GHC sadly does not allow this. I
spent
a bit of time tonight trying to see if I could convince GHC to first
manually build object code for the needed modules, and then load
bytecode for the rest. Unfortunately recompilation checking fought
me at
every turn.

The current state of my attempt can be found here [1]. It would be
great
if someone could pick it up. This will involve,

 * Working out how to convince the GHC to use the object code for
   utils/Encoding.o instead of recompiling

 * Identifying all of the modules which can't be byte-code
compiled and
   add them to $obj_modules

 * Chassing down whatever other issues that might pop up along the way

I also wouldn't be surprised if you would need this GHC patch [2].


I would have thought that something like

:set -fobject-code
:load Main  -- or whatever
-- modify some source file
:set -fbyte-code
:load Main

should do the right thing, loading object code when it can, up to the 
first module that has been modified more recently.  Of course you 
can't have any object code modules that depend on byte-code modules, 
so if you modify something too low down in the dependency graph then 
you'll have a lot of interpreted modules, and you may end up trying to 
interpret something that can't be interpreted because it has an 
unboxed tuple.  But for simple tests it ought to work.  (I haven't 
tried this so I'm probably forgetting something...)


Cheers
Simon


Cheers,

- Ben


[1]
https://gist.github.com/bgamari/bd53e4fd6f3323599387ffc7b11d1a1e

[2]

http://git.haskell.org/ghc.git/commit/326931db9cdc26f2d47657c1f084b9903fd46246



___
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: Exhaustiveness checking for pattern synonyms

[Simon Peyton Jones via ghc-devs]

Questions

* What if there are multiple COMPLETE pragmas e.g.
  {-# COMPLETE A, B, C #-}
  {-# COMPLETE A, X, Y, Z #-}
  Is that ok?  I guess it should be!

  Will the pattern-match exhaustiveness check then succeed
  if a function uses either set?

  What happens if you use a mixture of constructors in a match
  (e.g. A, X, C, Z)?  Presumably all bets are off?

* Note that COMPLETE pragmas could be a new source of orphan modules
 module M where
   import N( pattern P, pattern Q )
   {-# COMPLETE P, Q #-}
  where neither P nor Q is defined in M.  Then every module that is
  transitively "above" M would need to read M.hi just in case its
  COMPLETE pragmas was relevant.

* Point out in the spec that COMPLETE pragmas are entirely unchecked.
  It's up to the programmer to get it right.

* Typing.  What does it mean for the types to "agree" with each other.
  E.g  A :: a -> [(a, Int)]
   B :: b -> [(Int, b)]
  Is this ok?  Please say explicitly with examples.

* I didn't really didn't understand the "Error messages" section.


Simon

|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Matthew
|  Pickering
|  Sent: 22 November 2016 10:43
|  To: GHC developers 
|  Subject: Exhaustiveness checking for pattern synonyms
|  
|  Hello devs,
|  
|  I have implemented exhaustiveness checking for pattern synonyms. The idea is
|  very simple, you specify a set of pattern synonyms (or data
|  constructors) which are regarded as a complete match.
|  The pattern match checker then uses this information in order to check
|  whether a function covers all possibilities.
|  
|  Specification:
|  
|  https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/CompleteSigs
|  
|  https://phabricator.haskell.org/D2669
|  https://phabricator.haskell.org/D2725
|  
|  https://ghc.haskell.org/trac/ghc/ticket/8779
|  
|  Matt
|  ___
|  ghc-devs mailing list
|  ghc-devs@haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell
|  .org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs=02%7C01%7Csimonpj%40microsoft.com%7C155eb2786cb040d8052908d412c453
|  b5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636154081815249356=MkQ
|  FpwJWaTU%2BdEQSYEBjXLt80BrXLkBp9V8twdKB6BI%3D=0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Trac to Phabricator (Maniphest) migration prototype

[Matthew Pickering]

There is an equivalent, it is called Phriction -
https://phabricator.haskell.org/w/

I am not proposing at this stage that we migrate the wiki contents as
well. That would certainly be a logical next step but I think trac's
wiki is quite a bit better.

Matt

On Tue, Jan 10, 2017 at 12:00 PM, Simon Peyton Jones
 wrote:
> On this Phab question, does Phab have an equivalent to Trac's wiki?  That's 
> quite important.
>
> Simon
>
> |  -Original Message-
> |  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Matthew
> |  Pickering
> |  Sent: 10 January 2017 11:59
> |  To: Richard Eisenberg 
> |  Cc: GHC developers 
> |  Subject: Re: Trac to Phabricator (Maniphest) migration prototype
> |
> |  Subprojects and Milestones are both special kinds of projects.
> |
> |  Subprojects are like projects but are associated with a parent project.
> |  Unfortunately this doesn't really show up anywhere on the UI.
> |  There is quite a long discussion about this on the upstream issue tracker -
> |  
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure.phab
> |  
> ricator.com%2FT10349=02%7C01%7Csimonpj%40microsoft.com%7Cfe21d0babfb843
> |  
> 78ec2a08d439502937%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636196463840
> |  067524=7KEVArFhp3bIBclu2Drh8hSn8d47Q1aXrhGRQVKp%2BwM%3D=0
> |
> |  Milestones are projects which are meant for tracking releases. A project 
> can
> |  only have one milestone at a time and importantly the parent project is
> |  shown on the UI with milestones.
> |
> |  I took some screenshots to show how they show up in UI.
> |
> |  https://phabricator.haskell.org/M3
> |
> |  If you're interested about projects then the best place to read is
> |  
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure.phab
> |  
> ricator.com%2Fbook%2Fphabricator%2Farticle%2Fprojects%2F=02%7C01%7Csimo
> |  
> npj%40microsoft.com%7Cfe21d0babfb84378ec2a08d439502937%7C72f988bf86f141af91a
> |  
> b2d7cd011db47%7C1%7C0%7C636196463840067524=MfqbX%2BCzMtqf4wIRhe0MUqSN4
> |  l8l7oRiDO3IUIqb8ag%3D=0
> |
> |  They are not very mature and I expect their usage will be refined in the
> |  next iteration. The UI for selecting projects could certainly be improved
> |  rather than presenting a list of amorphous labels.
> |
> |  Matt
> |
> |  On Mon, Jan 9, 2017 at 6:41 PM, Richard Eisenberg 
> |  wrote:
> |  >
> |  >> On Jan 9, 2017, at 6:41 AM, Matthew Pickering
> |   wrote:
> |  >>
> |  >> Component -> Projects
> |  >> OS -> (Sub)Projects
> |  >> Arch -> (Sub)Projects
> |  >
> |  > What is a (Sub)Project? I've been operating under the assumption that a
> |  Project is just a tag. Do these tags have structure? My best guess from 
> your
> |  discussion is that when you choose on Project, you are then forced to 
> choose
> |  one of a set of others. That seems like a good plan.
> |  >
> |  >> Keywords -> Projects
> |  >> Version -> Remove (It is a proxy for date reported)
> |  >
> |  > No no no no. I don't think either of us will convince the other on this
> |  point, but we should be clear that we need input from others to decide on
> |  this one.
> |  >
> |  >> Milestone -> Project (Milestone)
> |  >
> |  > What does this mean? What is "Project (Milestone)"?
> |  >
> |  >> I have some example emails. https://phabricator.haskell.org/M2
> |  >
> |  > Looks good. Thanks for posting this!
> |  >
> |  > Richard
> |  ___
> |  ghc-devs mailing list
> |  ghc-devs@haskell.org
> |  
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell
> |  .org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
> |  
> devs=02%7C01%7Csimonpj%40microsoft.com%7Cfe21d0babfb84378ec2a08d4395029
> |  
> 37%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636196463840067524=mRz
> |  Phhzd1Xjqfbwz%2BTtfESWg4gbdSWx5gC2HpDUtSuM%3D=0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Trac to Phabricator (Maniphest) migration prototype

[Simon Peyton Jones via ghc-devs]

On this Phab question, does Phab have an equivalent to Trac's wiki?  That's 
quite important.

Simon

|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Matthew
|  Pickering
|  Sent: 10 January 2017 11:59
|  To: Richard Eisenberg 
|  Cc: GHC developers 
|  Subject: Re: Trac to Phabricator (Maniphest) migration prototype
|  
|  Subprojects and Milestones are both special kinds of projects.
|  
|  Subprojects are like projects but are associated with a parent project.
|  Unfortunately this doesn't really show up anywhere on the UI.
|  There is quite a long discussion about this on the upstream issue tracker -
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure.phab
|  ricator.com%2FT10349=02%7C01%7Csimonpj%40microsoft.com%7Cfe21d0babfb843
|  78ec2a08d439502937%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636196463840
|  067524=7KEVArFhp3bIBclu2Drh8hSn8d47Q1aXrhGRQVKp%2BwM%3D=0
|  
|  Milestones are projects which are meant for tracking releases. A project can
|  only have one milestone at a time and importantly the parent project is
|  shown on the UI with milestones.
|  
|  I took some screenshots to show how they show up in UI.
|  
|  https://phabricator.haskell.org/M3
|  
|  If you're interested about projects then the best place to read is
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure.phab
|  ricator.com%2Fbook%2Fphabricator%2Farticle%2Fprojects%2F=02%7C01%7Csimo
|  npj%40microsoft.com%7Cfe21d0babfb84378ec2a08d439502937%7C72f988bf86f141af91a
|  b2d7cd011db47%7C1%7C0%7C636196463840067524=MfqbX%2BCzMtqf4wIRhe0MUqSN4
|  l8l7oRiDO3IUIqb8ag%3D=0
|  
|  They are not very mature and I expect their usage will be refined in the
|  next iteration. The UI for selecting projects could certainly be improved
|  rather than presenting a list of amorphous labels.
|  
|  Matt
|  
|  On Mon, Jan 9, 2017 at 6:41 PM, Richard Eisenberg 
|  wrote:
|  >
|  >> On Jan 9, 2017, at 6:41 AM, Matthew Pickering
|   wrote:
|  >>
|  >> Component -> Projects
|  >> OS -> (Sub)Projects
|  >> Arch -> (Sub)Projects
|  >
|  > What is a (Sub)Project? I've been operating under the assumption that a
|  Project is just a tag. Do these tags have structure? My best guess from your
|  discussion is that when you choose on Project, you are then forced to choose
|  one of a set of others. That seems like a good plan.
|  >
|  >> Keywords -> Projects
|  >> Version -> Remove (It is a proxy for date reported)
|  >
|  > No no no no. I don't think either of us will convince the other on this
|  point, but we should be clear that we need input from others to decide on
|  this one.
|  >
|  >> Milestone -> Project (Milestone)
|  >
|  > What does this mean? What is "Project (Milestone)"?
|  >
|  >> I have some example emails. https://phabricator.haskell.org/M2
|  >
|  > Looks good. Thanks for posting this!
|  >
|  > Richard
|  ___
|  ghc-devs mailing list
|  ghc-devs@haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell
|  .org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs=02%7C01%7Csimonpj%40microsoft.com%7Cfe21d0babfb84378ec2a08d4395029
|  37%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636196463840067524=mRz
|  Phhzd1Xjqfbwz%2BTtfESWg4gbdSWx5gC2HpDUtSuM%3D=0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Trac to Phabricator (Maniphest) migration prototype

[Matthew Pickering]

Subprojects and Milestones are both special kinds of projects.

Subprojects are like projects but are associated with a parent
project. Unfortunately this doesn't really show up anywhere on the UI.
There is quite a long discussion about this on the upstream issue
tracker - https://secure.phabricator.com/T10349

Milestones are projects which are meant for tracking releases. A
project can only have one milestone at a time and importantly the
parent project is shown on the UI with milestones.

I took some screenshots to show how they show up in UI.

https://phabricator.haskell.org/M3

If you're interested about projects then the best place to read is
https://secure.phabricator.com/book/phabricator/article/projects/

They are not very mature and I expect their usage will be refined in
the next iteration. The UI for selecting projects could certainly be
improved rather than presenting a list of amorphous labels.

Matt

On Mon, Jan 9, 2017 at 6:41 PM, Richard Eisenberg  wrote:
>
>> On Jan 9, 2017, at 6:41 AM, Matthew Pickering  
>> wrote:
>>
>> Component -> Projects
>> OS -> (Sub)Projects
>> Arch -> (Sub)Projects
>
> What is a (Sub)Project? I've been operating under the assumption that a 
> Project is just a tag. Do these tags have structure? My best guess from your 
> discussion is that when you choose on Project, you are then forced to choose 
> one of a set of others. That seems like a good plan.
>
>> Keywords -> Projects
>> Version -> Remove (It is a proxy for date reported)
>
> No no no no. I don't think either of us will convince the other on this 
> point, but we should be clear that we need input from others to decide on 
> this one.
>
>> Milestone -> Project (Milestone)
>
> What does this mean? What is "Project (Milestone)"?
>
>> I have some example emails. https://phabricator.haskell.org/M2
>
> Looks good. Thanks for posting this!
>
> Richard
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: nofib on Shake

[Gracjan Polak]

I was looking nearby recently and you might want to take into account my
discoveries described in https://ghc.haskell.org/trac/ghc/ticket/11501

2017-01-08 18:48 GMT+01:00 Michal Terepeta :

> Hi all,
>
> While looking at nofib, I've found a blog post from Neil Mitchell [1],
> which describes a Shake build system for nofib. The comments mentioned
> that this should get merged, but it seems that nothing actually happened?
> Is there some fundamental reason for that?
>
> If not, I'd be interested picking this up - the current make-based
> system is pretty confusing for me and `runstdtest` looks simply
> terrifying ;-)
> We could also create a cabal and stack files for `nofib-analyse` (making
> it possible to use some libraries for it).
>
> Thanks,
> Michal
>
> [1] http://neilmitchell.blogspot.ch/2013/02/a-nofib-build-
> system-using-shake.html
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs