Re: Building HEAD with HEAD fails

2015-10-22 Thread Gabor Greif 
I did not use an inplace-stage2 but had a 'make install' before and
did a boot/reconfigure.

Not sure whether this detail is relevant.

How can I debug this problem? What does the error message say precisely?

Cheers,

Gabor

On 10/22/15, Edward Z. Yang  wrote:
> So... I can't reproduce this.  I validated a copy of GHC HEAD,
> and then used the inplace ghc-stage2 to build another using
> ./configure --with-ghc=... and it built fine.
>
> Maybe, do you have some more details?
>
> Edward
>
> Excerpts from Edward Z. Yang's message of 2015-10-21 11:44:26 -0700:
>> This is likely my fault, w.r.t. to the recent Cabal submodule update.
>> I'm a bit confused why there are things in the DB that don't have ABI
>> hashes though...
>>
>> Edward
>>
>> Excerpts from Gabor Greif's message of 2015-10-21 03:51:02 -0700:
>> > Hi devs,
>> >
>> > just a heads-up (pun intended...)
>> >
>> > (After updating to TOT, boot and configure with a freshly installed
>> > TOT ghc as bootstrap compiler. Then 'make clean'.)
>> >
>> > Running 'make' gives:
>> >
>> > ...
>> > Creating includes/ghcplatform.h...
>> > Done.
>> > "rm" -f utils/hsc2hs/dist/build/.depend.haskell.tmp
>> > "/home/ggreif/bin/ghc" -M -static  -H64m -O0 -fasm   -package-db
>> > libraries/bootstrapping.conf  -hide-all-packages -i -iutils/hsc2hs/.
>> > -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen
>> > -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen
>> > -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h
>> > -package-id base-4.8.2.0 -package-id containers-0.5.6.2 -package-id
>> > directory-1.2.2.0 -package-id filepath-1.4.0.0 -package-id
>> > process-1.2.3.0 -XHaskell2010  -no-user-package-db -rtsopts  -odir
>> > utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir
>> > utils/hsc2hs/dist/build -dep-makefile
>> > utils/hsc2hs/dist/build/.depend.haskell.tmp -dep-suffix ""
>> > -include-pkg-deps  utils/hsc2hs/./Main.hs  utils/hsc2hs/./C.hs
>> > utils/hsc2hs/./Common.hs  utils/hsc2hs/./CrossCodegen.hs
>> > utils/hsc2hs/./DirectCodegen.hs  utils/hsc2hs/./Flags.hs
>> > utils/hsc2hs/./HSCParser.hs  utils/hsc2hs/./UtilsCodegen.hs
>> > : package db: duplicate packages with incompatible ABIs:
>> > binary-0.7.5.0 has ABIs: , c28f822c21e75eb270eca0870e42aaac
>> > Cabal-1.23.0.0 has ABIs: , a0a6af8f1dd909f2ee719ddb2cd65779
>> > hpc-0.6.0.2 has ABIs: , 3434375974d4bc6d14952a90ec97d0c4
>> > ghc-boot-0.0.0.0 has ABIs: , f422fc19421064f81c42815f25a11e6e
>> > hoopl-3.10.0.2 has ABIs: , 8968e2731ff8d529c37c048d65e94bf2
>> > transformers-0.4.3.0 has ABIs: , 812457c97c58693d7f8a813b1ba19a33
>> > template-haskell-2.11.0.0 has ABIs: ,
>> > 0ef51476100e9bdf96d1bf59696b98a1
>> > terminfo-0.4.0.1 has ABIs: , aa24f544c0e3614d419e63fa170ac467
>> >
>> >
>> > The only solution I could come up for now is
>> >
>> > cd libraries
>> > ln -s /home/ggreif/lib/ghc-7.11.20151020/package.conf.d
>> > bootstrapping.conf
>> >
>> > then resuming 'make' leads to success.
>> >
>> > What could this be? Has somebody seen such an error?
>> >
>> > Cheers and thanks,
>> >
>> > Gabor
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Building HEAD with HEAD fails

2015-10-22 Thread Edward Z. Yang 
Phab here: https://phabricator.haskell.org/D1355

Excerpts from Edward Z. Yang's message of 2015-10-22 13:09:25 -0700:
> Scratch that, I managed to reproduced. (As you said, it occurs only when
> you do the bindist.)  I'll debug.
> 
> Edward
> 
> Excerpts from Gabor Greif's message of 2015-10-21 23:47:37 -0700:
> > I did not use an inplace-stage2 but had a 'make install' before and
> > did a boot/reconfigure.
> > 
> > Not sure whether this detail is relevant.
> > 
> > How can I debug this problem? What does the error message say precisely?
> > 
> > Cheers,
> > 
> > Gabor
> > 
> > On 10/22/15, Edward Z. Yang  wrote:
> > > So... I can't reproduce this.  I validated a copy of GHC HEAD,
> > > and then used the inplace ghc-stage2 to build another using
> > > ./configure --with-ghc=... and it built fine.
> > >
> > > Maybe, do you have some more details?
> > >
> > > Edward
> > >
> > > Excerpts from Edward Z. Yang's message of 2015-10-21 11:44:26 -0700:
> > >> This is likely my fault, w.r.t. to the recent Cabal submodule update.
> > >> I'm a bit confused why there are things in the DB that don't have ABI
> > >> hashes though...
> > >>
> > >> Edward
> > >>
> > >> Excerpts from Gabor Greif's message of 2015-10-21 03:51:02 -0700:
> > >> > Hi devs,
> > >> >
> > >> > just a heads-up (pun intended...)
> > >> >
> > >> > (After updating to TOT, boot and configure with a freshly installed
> > >> > TOT ghc as bootstrap compiler. Then 'make clean'.)
> > >> >
> > >> > Running 'make' gives:
> > >> >
> > >> > ...
> > >> > Creating includes/ghcplatform.h...
> > >> > Done.
> > >> > "rm" -f utils/hsc2hs/dist/build/.depend.haskell.tmp
> > >> > "/home/ggreif/bin/ghc" -M -static  -H64m -O0 -fasm   -package-db
> > >> > libraries/bootstrapping.conf  -hide-all-packages -i -iutils/hsc2hs/.
> > >> > -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen
> > >> > -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen
> > >> > -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h
> > >> > -package-id base-4.8.2.0 -package-id containers-0.5.6.2 -package-id
> > >> > directory-1.2.2.0 -package-id filepath-1.4.0.0 -package-id
> > >> > process-1.2.3.0 -XHaskell2010  -no-user-package-db -rtsopts  -odir
> > >> > utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir
> > >> > utils/hsc2hs/dist/build -dep-makefile
> > >> > utils/hsc2hs/dist/build/.depend.haskell.tmp -dep-suffix ""
> > >> > -include-pkg-deps  utils/hsc2hs/./Main.hs  utils/hsc2hs/./C.hs
> > >> > utils/hsc2hs/./Common.hs  utils/hsc2hs/./CrossCodegen.hs
> > >> > utils/hsc2hs/./DirectCodegen.hs  utils/hsc2hs/./Flags.hs
> > >> > utils/hsc2hs/./HSCParser.hs  utils/hsc2hs/./UtilsCodegen.hs
> > >> > : package db: duplicate packages with incompatible ABIs:
> > >> > binary-0.7.5.0 has ABIs: , c28f822c21e75eb270eca0870e42aaac
> > >> > Cabal-1.23.0.0 has ABIs: , a0a6af8f1dd909f2ee719ddb2cd65779
> > >> > hpc-0.6.0.2 has ABIs: , 3434375974d4bc6d14952a90ec97d0c4
> > >> > ghc-boot-0.0.0.0 has ABIs: , f422fc19421064f81c42815f25a11e6e
> > >> > hoopl-3.10.0.2 has ABIs: , 8968e2731ff8d529c37c048d65e94bf2
> > >> > transformers-0.4.3.0 has ABIs: , 812457c97c58693d7f8a813b1ba19a33
> > >> > template-haskell-2.11.0.0 has ABIs: ,
> > >> > 0ef51476100e9bdf96d1bf59696b98a1
> > >> > terminfo-0.4.0.1 has ABIs: , aa24f544c0e3614d419e63fa170ac467
> > >> >
> > >> >
> > >> > The only solution I could come up for now is
> > >> >
> > >> > cd libraries
> > >> > ln -s /home/ggreif/lib/ghc-7.11.20151020/package.conf.d
> > >> > bootstrapping.conf
> > >> >
> > >> > then resuming 'make' leads to success.
> > >> >
> > >> > What could this be? Has somebody seen such an error?
> > >> >
> > >> > Cheers and thanks,
> > >> >
> > >> > Gabor
> > >
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Context for typed holes

2015-10-22 Thread Manuel M T Chakravarty 
I think, this is a good point. Maybe you should make a ticket for it.

Manuel

> David Feuer :
> 
> Unless something has changed really recently that I've missed, the typed 
> holes messages are missing some really important information: instance 
> information for types in scope. When I am trying to fill in a hole, I look to 
> the "relevant bindings" to show me what pieces I have available to use. Those 
> pieces don't include contexts! Is there something fundamentally hard about 
> adding this information? I'd only want instance information for type 
> variables--providing it for concrete types would make too much noise. I'd 
> also want information on equality constraints, of course.
> 
> ___
> 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: Coercion logic

2015-10-22 Thread David Feuer 
No, I've not tested against head. I'd not heard anything new about
that! That sounds exciting. Sorry about the noise if it's all finished
already.

David

On Thu, Oct 22, 2015 at 9:57 AM, Richard Eisenberg  wrote:
> The Coercible solver has evolved steadily. It should know that (Coercible a b 
> <=> Coercible b a). Do you have a concrete example of where it's not doing 
> this? Have you tested against HEAD?
>
> Thanks,
> Richard
>
> On Oct 22, 2015, at 9:56 AM, David Feuer  wrote:
>
>> At present, any time we write a function with a `Coercible`
>> constraint, we must take great care to choose `Coercible a b` or
>> `Coercible b a` depending on which will ultimately lead to fewer silly
>> conversions. This is particularly sad because the whole Coercible
>> mechanism guarantees that these have exactly the same run-time
>> representation, and because People Wiser Than Me believe Coercible
>> should *always* remain symmetric. My (admittedly reptilian) brain
>> wonders what it would take to tell the type checker that
>>
>> forall a b . Coercible a b ~ Coercible b a
>>
>> and have it over with.
>>
>> David Feuer
>> ___
>> 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: Coercion logic

2015-10-22 Thread Richard Eisenberg 
The Coercible solver has evolved steadily. It should know that (Coercible a b 
<=> Coercible b a). Do you have a concrete example of where it's not doing 
this? Have you tested against HEAD?

Thanks,
Richard

On Oct 22, 2015, at 9:56 AM, David Feuer  wrote:

> At present, any time we write a function with a `Coercible`
> constraint, we must take great care to choose `Coercible a b` or
> `Coercible b a` depending on which will ultimately lead to fewer silly
> conversions. This is particularly sad because the whole Coercible
> mechanism guarantees that these have exactly the same run-time
> representation, and because People Wiser Than Me believe Coercible
> should *always* remain symmetric. My (admittedly reptilian) brain
> wonders what it would take to tell the type checker that
> 
> forall a b . Coercible a b ~ Coercible b a
> 
> and have it over with.
> 
> David Feuer
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

Re: [GHC] #10053: Regression on MacOS platform, error in ghci calling main after loading compiled code: "Too late for parseStaticFlags..."

2015-10-22 Thread George Colpitts 
Right, as it says in title "error  in ghci calling main after loading
compiled code"

On Thursday, October 22, 2015, GHC  wrote:

> #10053: Regression on MacOS platform, error  in ghci calling main after
> loading
> compiled code: "Too late for parseStaticFlags..."
> -+-
> Reporter:  George|Owner:
> Type:  bug   |   Status:  new
> Priority:  normal|Milestone:  8.0.1
>Component:  GHCi  |  Version:  7.10.1-rc2
>   Resolution:| Keywords:
> Operating System:  MacOS X   | Architecture:  x86_64
>  Type of failure:  Incorrect result  |  (amd64)
>   at runtime |Test Case:
>   Blocked By:| Blocking:
>  Related Tickets:|  Differential Rev(s):
>Wiki Page:|
> -+-
> Changes (by bgamari):
>
>  * milestone:  7.10.3 => 8.0.1
>
>
> Old description:
>
> > ghci
> > GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/  :? for help
> > Prelude> :load rsa
> > Ok, modules loaded: Main.
> > Prelude Main> :show modules
> > Main ( rsa.hs, rsa.o )
> > Prelude Main> main
> > Too late for parseStaticFlags: call it before runGhc or runGhcT
> >  Exception: ExitFailure 1
> > Prelude Main>
> >
> > note, there is no failure if I load interpreted code
>
> New description:
>
>  {{{
>  $ ghci
>  GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/  :? for help
>  Prelude> :load rsa
>  Ok, modules loaded: Main.
>  Prelude Main> :show modules
>  Main ( rsa.hs, rsa.o )
>  Prelude Main> main
>  Too late for parseStaticFlags: call it before runGhc or runGhcT
>   Exception: ExitFailure 1
>  Prelude Main>
>  }}}
>
>  note, there is no failure if I load interpreted code
>
> --
>
> Comment:
>
>  This isn't going to be fixed for 7.10.3.
>
> --
> Ticket URL: 
> GHC 
> The Glasgow Haskell Compiler
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Coercion logic

2015-10-22 Thread David Feuer 
At present, any time we write a function with a `Coercible`
constraint, we must take great care to choose `Coercible a b` or
`Coercible b a` depending on which will ultimately lead to fewer silly
conversions. This is particularly sad because the whole Coercible
mechanism guarantees that these have exactly the same run-time
representation, and because People Wiser Than Me believe Coercible
should *always* remain symmetric. My (admittedly reptilian) brain
wonders what it would take to tell the type checker that

forall a b . Coercible a b ~ Coercible b a

and have it over with.

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

Re: Context for typed holes

2015-10-22 Thread Christopher Allen 
It's not just you. That's why I didn't mention holes in the book as people
suggested. It's not just confusing for new people - it drives me nuts every
time I use a hole in non-trivial code at work.

On Thu, Oct 8, 2015 at 6:25 PM, David Feuer  wrote:

> Unless something has changed really recently that I've missed, the typed
> holes messages are missing some really important information: instance
> information for types in scope. When I am trying to fill in a hole, I look
> to the "relevant bindings" to show me what pieces I have available to use.
> Those pieces don't include contexts! Is there something fundamentally hard
> about adding this information? I'd only want instance information for type
> variables--providing it for concrete types would make too much noise. I'd
> also want information on equality constraints, of course.
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>


-- 
Chris Allen
Currently working on http://haskellbook.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Context for typed holes

2015-10-22 Thread David Feuer 
I opened https://ghc.haskell.org/trac/ghc/ticket/10954 for this. #9479, by
Dominique Devriese, is complementary--she wants instance information for a
*hole* with an ambiguous type.
On Oct 23, 2015 1:28 AM, "Andres Löh"  wrote:

> Hi.
>
> On Oct 23, 2015 01:15, "Manuel M T Chakravarty" 
> wrote:
> >
> > I think, this is a good point. Maybe you should make a ticket for it.
>
> #9479, I think.
>
> Cheers,
> Andres
>
> >> David Feuer :
> >>
> >> Unless something has changed really recently that I've missed, the
> typed holes messages are missing some really important information:
> instance information for types in scope. When I am trying to fill in a
> hole, I look to the "relevant bindings" to show me what pieces I have
> available to use. Those pieces don't include contexts! Is there something
> fundamentally hard about adding this information? I'd only want instance
> information for type variables--providing it for concrete types would make
> too much noise. I'd also want information on equality constraints, of
> course.
> >>
> >> ___
> >> 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: Context for typed holes

2015-10-22 Thread Andres Löh 
Actually, #9091 was the one I was really looking for ... reported by
me. See also the discussion about "given" vs. "wanted" constraints.

Cheers,
  Andres

On Fri, Oct 23, 2015 at 7:48 AM, David Feuer  wrote:
> I opened https://ghc.haskell.org/trac/ghc/ticket/10954 for this. #9479, by
> Dominique Devriese, is complementary--she wants instance information for a
> *hole* with an ambiguous type.
>
> On Oct 23, 2015 1:28 AM, "Andres Löh"  wrote:
>>
>> Hi.
>>
>> On Oct 23, 2015 01:15, "Manuel M T Chakravarty" 
>> wrote:
>> >
>> > I think, this is a good point. Maybe you should make a ticket for it.
>>
>> #9479, I think.
>>
>> Cheers,
>> Andres
>>
>> >> David Feuer :
>> >>
>> >> Unless something has changed really recently that I've missed, the
>> >> typed holes messages are missing some really important information: 
>> >> instance
>> >> information for types in scope. When I am trying to fill in a hole, I look
>> >> to the "relevant bindings" to show me what pieces I have available to use.
>> >> Those pieces don't include contexts! Is there something fundamentally hard
>> >> about adding this information? I'd only want instance information for type
>> >> variables--providing it for concrete types would make too much noise. I'd
>> >> also want information on equality constraints, of course.
>> >>
>> >> ___
>> >> 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: Context for typed holes

2015-10-22 Thread Andres Löh 
Hi.

On Oct 23, 2015 01:15, "Manuel M T Chakravarty" 
wrote:
>
> I think, this is a good point. Maybe you should make a ticket for it.

#9479, I think.

Cheers,
Andres

>> David Feuer :
>>
>> Unless something has changed really recently that I've missed, the typed
holes messages are missing some really important information: instance
information for types in scope. When I am trying to fill in a hole, I look
to the "relevant bindings" to show me what pieces I have available to use.
Those pieces don't include contexts! Is there something fundamentally hard
about adding this information? I'd only want instance information for type
variables--providing it for concrete types would make too much noise. I'd
also want information on equality constraints, of course.
>>
>> ___
>> 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: Type-level error messages

2015-10-22 Thread Simon Peyton Jones 
I’ve forgotten the state of your type-level error messages work.  How’s it 
going?
I think we should try to add it to 8.0.1.  The current status is that the idea 
is implemented on a branch.  Then, there were some comments and suggestions 
that maybe we should do things in a different way, implementation wise.  I 
haven't had a chance to look into these in detail, or implement them, and as 
far as I know nobody else has stepped up to make the changes.  So we could 
simply go with the current version, and if for some reason we want to change 
the implementation we could do it later, as I don't think the API will be 
affected in any way.When do the changes need to happen by, so that it makes 
it in 8.0?   I have been a bit busy, but I could probably find some time to 
make whatever changes are required for this to be merged.

OK good!  In that case

· Add it to the hoped-for features in the GHC 8.01. status page

· Write a wiki page with a specification

· Announce the proposal and seek feedback

· Meanwhile make sure the branch reflects what you want to be in it

If you don’t have time, well, no harm done… any progress you make on the above 
will still be useful.

Simon

From: Iavor Diatchki [mailto:iavor.diatc...@gmail.com]
Sent: 22 October 2015 17:42
To: Simon Peyton Jones
Cc: Augustsson, Lennart
Subject: Re: Type-level error messages

Hello,

I think we should try to add it to 8.0.1.  The current status is that the idea 
is implemented on a branch.  Then, there were some comments and suggestions 
that maybe we should do things in a different way, implementation wise.  I 
haven't had a chance to look into these in detail, or implement them, and as 
far as I know nobody else has stepped up to make the changes.  So we could 
simply go with the current version, and if for some reason we want to change 
the implementation we could do it later, as I don't think the API will be 
affected in any way.When do the changes need to happen by, so that it makes 
it in 8.0?   I have been a bit busy, but I could probably find some time to 
make whatever changes are required for this to be merged.

-Iavor






On Thu, Oct 22, 2015 at 3:47 AM, Simon Peyton Jones 
> wrote:
Iavor
I’ve forgotten the state of your type-level error messages work.  How’s it 
going?
It’s not mentioned on https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1: 
shouldn’t it be?
Simon

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