Re: [Haskell-cafe] [ANNOUNCE] GHC 9.8.1-alpha4 is now available

[George Colpitts]

It seems unlikely that the current tests wouldn't find this bug. Is it the
case that the tests are never run on aarch64-darwin Macs?

On Fri, Sep 22, 2023 at 7:34 PM George Colpitts 
wrote:

>
>-
>#21570, Linker broken on M1 Mac, occurs on 9.8.1-alpha4. I have
>updated the bug. My guess is that it was never addressed as the info needed
>tag was never removed after the  required  info was supplied. It might be
>good to have a test for this.
><https://gitlab.haskell.org/ghc/ghc/-/issues/21570>
>-
><https://gitlab.haskell.org/ghc/ghc/-/issues/21570>
>
>
> On Wed, Sep 20, 2023 at 1:54 AM Ben Gamari  wrote:
>
>>
>> The GHC developers are very pleased to announce the availability of the
>> third alpha prerelease of GHC 9.8.1. Binary distributions, source
>> distributions, and documentation are available at
>>
>> https://downloads.haskell.org/ghc/9.8.1-alpha4
>>
>> GHC 9.8 will bring a number of new features and improvements, including:
>>
>>  * Preliminary support the `TypeAbstractions` language extension,
>>allowing types to be bound in type declarations [TypeAbstractions].
>>
>>  * Support for the `ExtendedLiterals` extension, providing syntax for
>>non-word-sized numeric literals in the surface language
>>[extended-literals]
>>
>>  * Improved rewrite rule matching behavior, allowing limited matching of
>>higher-order patterns
>>
>>  * Better support for user-defined warnings by way of the `WARNING`
>>pragma [warnings]
>>
>>  * The introduction of the new `GHC.TypeError.Unsatisfiable`
>>constraint, allowing more predictable user-defined type errors
>>[unsatisfiable]
>>
>>  * Implementation of the export deprecation proposal, allowing module
>>exports to be marked with `DEPRECATE` pragmas [deprecated-exports]
>>
>>  * The addition of build semaphore support for parallel compilation;
>>with coming support in `cabal-install` this will allow better use of
>>parallelism in multi-package builds [jsem]
>>
>>  * More efficient representation of info table provenance information,
>>reducing binary sizes by over 50% in some cases when
>>`-finfo-table-map` is in use
>>
>> A full accounting of changes can be found in the [release notes].
>> This alpha includes roughly 40 new commits relative to alpha 3,
>> including what we believe should be nearly the last changes to GHC's
>> boot libraries.
>>
>> We would like to thank GitHub, IOG, the Zw3rk stake pool,
>> Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell
>> Foundation, and other anonymous contributors whose on-going financial
>> and in-kind support has facilitated GHC maintenance and release
>> management over the years. Finally, this release would not have been
>> possible without the hundreds of open-source contributors whose work
>> comprise this release.
>>
>> As always, do give this release a try and open a [ticket] if you see
>> anything amiss.
>>
>> Happy compiling,
>>
>> ~ Ben
>>
>> [TypeAbstractions]:
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst
>> [extended-literals
>> <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst%5Bextended-literals>]:
>>
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-sized-literals.rst
>> [unsatisfiable]:
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-unsatisfiable.rst
>> [warnings]:
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-warning-pragmas-with-categories.rst
>> [deprecated-exports
>> <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-warning-pragmas-with-categories.rst%5Bdeprecated-exports>]:
>>
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-deprecating-exports-proposal.rst
>> [jsem]:
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-jsem.rst
>> [release notes]:
>> https://downloads.haskell.org/ghc/9.8.1-alpha4/docs/users_guide/9.8.1-notes.html
>> ___
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] [ANNOUNCE] GHC 9.8.1-alpha4 is now available

[George Colpitts]

   -
   #21570, Linker broken on M1 Mac, occurs on 9.8.1-alpha4. I have updated
   the bug. My guess is that it was never addressed as the info needed tag was
   never removed after the  required  info was supplied. It might be good to
   have a test for this. 
   -
   


On Wed, Sep 20, 2023 at 1:54 AM Ben Gamari  wrote:

>
> The GHC developers are very pleased to announce the availability of the
> third alpha prerelease of GHC 9.8.1. Binary distributions, source
> distributions, and documentation are available at
>
> https://downloads.haskell.org/ghc/9.8.1-alpha4
>
> GHC 9.8 will bring a number of new features and improvements, including:
>
>  * Preliminary support the `TypeAbstractions` language extension,
>allowing types to be bound in type declarations [TypeAbstractions].
>
>  * Support for the `ExtendedLiterals` extension, providing syntax for
>non-word-sized numeric literals in the surface language
>[extended-literals]
>
>  * Improved rewrite rule matching behavior, allowing limited matching of
>higher-order patterns
>
>  * Better support for user-defined warnings by way of the `WARNING`
>pragma [warnings]
>
>  * The introduction of the new `GHC.TypeError.Unsatisfiable`
>constraint, allowing more predictable user-defined type errors
>[unsatisfiable]
>
>  * Implementation of the export deprecation proposal, allowing module
>exports to be marked with `DEPRECATE` pragmas [deprecated-exports]
>
>  * The addition of build semaphore support for parallel compilation;
>with coming support in `cabal-install` this will allow better use of
>parallelism in multi-package builds [jsem]
>
>  * More efficient representation of info table provenance information,
>reducing binary sizes by over 50% in some cases when
>`-finfo-table-map` is in use
>
> A full accounting of changes can be found in the [release notes].
> This alpha includes roughly 40 new commits relative to alpha 3,
> including what we believe should be nearly the last changes to GHC's
> boot libraries.
>
> We would like to thank GitHub, IOG, the Zw3rk stake pool,
> Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell
> Foundation, and other anonymous contributors whose on-going financial
> and in-kind support has facilitated GHC maintenance and release
> management over the years. Finally, this release would not have been
> possible without the hundreds of open-source contributors whose work
> comprise this release.
>
> As always, do give this release a try and open a [ticket] if you see
> anything amiss.
>
> Happy compiling,
>
> ~ Ben
>
> [TypeAbstractions]:
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst
> [extended-literals
> ]:
>
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-sized-literals.rst
> [unsatisfiable]:
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-unsatisfiable.rst
> [warnings]:
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-warning-pragmas-with-categories.rst
> [deprecated-exports
> ]:
>
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-deprecating-exports-proposal.rst
> [jsem]:
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-jsem.rst
> [release notes]:
> https://downloads.haskell.org/ghc/9.8.1-alpha4/docs/users_guide/9.8.1-notes.html
> ___
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

on my mac 9.6.1 can't compile with ghc -prof -fprof-auto , gets error Could not find module ‘Prelude’

[George Colpitts]

Hello
On my mac, in ghc  9.6.1 can't compile with ghc -prof -fprof-auto  , I get
the error:

Could not find module ‘Prelude’Perhaps you haven't installed the
"p_dyn" libraries for package ‘base-4.18.0.0’?Use -v (or `:set -v`
in ghci) to see a list of the files searched for.

Is anybody else experiencing this?


In more detail:

> ghc -prof  -fprof-auto hello.hsLoaded package environment from 
> /Users/gcolpitts/.ghc/x86_64-darwin-9.6.1/environments/default[1 of 2] 
> Compiling Main ( hello.hs, hello.o )hello.hs:1:1: error:Could 
> not find module ‘Prelude’Perhaps you haven't installed the "p_dyn" 
> libraries for package ‘base-4.18.0.0’?Use -v (or `:set -v` in ghci) to 
> see a list of the files searched for.  |1 | main = print "hello"  | ^

hello.hs consists of

main = print "hello"

I reported this in 9.2.3 , in #21709
. At that time there was
a workaround of adding -static but that no longer works. It gives a
slightly different error message:

ghc -prof  -fprof-auto -static hello.hs
Loaded package environment from
/Users/gcolpitts/.ghc/x86_64-darwin-9.6.1/environments/default
[2 of 2] Linking hello
ld: warning: directory not found for option '-L/opt/local/lib/'
ld: library not found for -lHStyp-qlty-1-186ccc78_p
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
ghc-9.6.1: `gcc' failed in phase `Linker'. (Exit code: 1)

I have updated 21709 with the details of the problem on 9.6.1

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

Re: Installing GHC on my MacBook Air

[George Colpitts]

Type the following at the command line:

xcode-select --install

and then try ghci again.

I'm not sure what you mean by "the software" in the phrase "Should I delete
and reinstall the software you told me to install?" but in any case don't
delete anything. Please try to be as specific as possible.

When you first encounter a problem you should Google for a solution. If
that doesn't work you can send mail to me but also cc ghc-d...@haskell.org
and  glasgow-haskell-users@haskell.org

Cheers
George


On Thu, Mar 16, 2023 at 11:09 PM William McEnaney <
bill.mcenaney...@gmail.com> wrote:

> Hi, George,
>
> Sorry to bother you. Though ghc seems to run properly, here's what ghci
> prints on my screen. What mistake did I make? Should I delete and reinstall
> the software you told me to install?
>
> "GHCi, version 9.4.4: https://www.haskell.org/ghc/  :? for help
>
> xcrun: error: invalid active developer path
> (/Library/Developer/CommandLineTools), missing xcrun at:
> /Library/Developer/CommandLineTools/usr/bin/xcrun
>
> `gcc' failed in phase `gcc'. (Exit code: 1)
>
> williammcenaney@Williams-Air bin"
>
>
> Thanks.
>
>
> Bill
>
>
> Bill
>
> On Wed, Mar 15, 2023 at 7:59 AM George Colpitts 
> wrote:
>
>> Hi Bill
>>
>> Yes,GHC will run on your new MacBook Air. The cpu in that is Apple
>> Silicon , the aarch64-apple-darwin platform. Older Macs run on Intel chips,
>> the x86_64-apple-darwin platform.
>>
>> I'm not sure how you installed the compiler. I believe the standard way
>> is described on https://www.haskell.org/ghcup/. Can you tell us how you
>> installed it?
>>
>> Thanks
>> George
>>
>> On Wed, Mar 15, 2023 at 8:22 AM Simon Peyton Jones <
>> simon.peytonjo...@gmail.com> wrote:
>>
>>> Redirecting this query to ghc-devs.  Can anyone help William?  Thanks!
>>>
>>> Will GHC run on my new MacBook Air? After installing the compiler, my
>>>> laptop said its processor was wrong for the binary distribution I chose. If
>>>> there is a dmg file for MacOS 12.5.1, please please link your reply to it.
>>>>
>>>
>>> Simon
>>>
>>> On Tue, 14 Mar 2023 at 23:33, William McEnaney <
>>> bill.mcenaney...@gmail.com> wrote:
>>>
>>>> Dear Dr. Jones,
>>>>
>>>> Will GHC run on my new MacBook Air? After installing the compiler, my
>>>> laptop said its processor was wrong for the binary distribution I chose. If
>>>> there is a dmg file for MacOS 12.5.1, please please link your reply to it.
>>>>
>>>> Thanks for your help.
>>>>
>>>> Best,
>>>> Bill
>>>>
>>> ___
>>> ghc-devs mailing list
>>> ghc-d...@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Installing GHC on my MacBook Air

[George Colpitts]

Somehow I missed that it is now working for you. Great! Definitely no need
to report a bug. Haskell is a great language. Enjoy!

Cheers
George


On Wed, Mar 15, 2023 at 3:07 PM William McEnaney 
wrote:

> Hi, George,
>
> Now that the compiler runs, maybe I don't need to report a bug.
> ...
> Thanks for everything.
>
> Bill
>
> On Wed, Mar 15, 2023 at 1:17 PM George Colpitts 
> wrote:
>
>> Hi Bill,
>>
>> It's easy to forget to do replay all in gmail but it's important to do so
>> in these emails.
>>
>> In your original email you wrote:
>>
>> After installing the compiler, my laptop said its processor was wrong for
>> the binary distribution I chose. If there is a dmg file for *MacOS
>> 12.5.1,* please please link your reply to it.
>>
>>
>> Can you confirm that you no longer have the problem "of processor was
>> wrong for the binary distribution I chose." ?
>>
>> My understanding is that after that you got the error:
>>
>> libHSterminfo-0.4.1.5-ghc9.4.4.dylib” can’t be opened because Apple
>> cannot check it for malicious software.
>>
>> I then suggested you had encountered
>> https://gitlab.haskell.org/ghc/ghc/-/issues/21506#note_447206  and I
>> suggested you do:
>>
>>  rm -fr /usr/local/bin/ghc*
>> rm -fr /usr/local/lib/ghc*
>> ./configure
>> sudo xattr -rc .
>> sudo make install
>>
>>
>> You said you did and got a warning "that some program wanted to access my
>> photos when I don't have any."
>>
>> Can you repeat those steps and cut and paste your terminal session into
>> an email?
>>
>> Unfortunately I am too busy to continue replying but with the above I
>> think somebody will be able to help you.
>>
>> Cheers,
>> George
>>
>>
>> On Wed, Mar 15, 2023 at 1:59 PM William McEnaney <
>> bill.mcenaney...@gmail.com> wrote:
>>
>>> Hi, George,
>>>
>>> I'd be happy to do that for you. But I'm sure I can recall the
>>> information a GHC maintainer would need.
>>>
>>> Best,
>>> Bill
>>>
>>> On Wed, Mar 15, 2023 at 12:41 PM George Colpitts <
>>> george.colpi...@gmail.com> wrote:
>>>
>>>> Hi William
>>>>
>>>> I think it's best if you submit a bug as described here
>>>> <https://gitlab.haskell.org/ghc/ghc/-/wikis/report-a-bug>
>>>>
>>>> Whether in email or in the bug report it is critical that you
>>>> describe how the reader can reproduce the bug, i.e. starting from the
>>>> beginning,  describe what you did and what error message(s) you got.
>>>>
>>>> Regards,
>>>> George
>>>>
>>>>
>>>> On Wed, Mar 15, 2023 at 1:34 PM William McEnaney <
>>>> bill.mcenaney...@gmail.com> wrote:
>>>>
>>>>> Hi, George,
>>>>>
>>>>> Yes, I did. But I must have made a mistake. After I pasted them into a
>>>>> Terminal window, the machine warned me that some program wanted to access
>>>>> my photos when I don't have any.
>>>>>
>>>>>
>>>>> On Wed, Mar 15, 2023 at 12:26 PM George Colpitts <
>>>>> george.colpi...@gmail.com> wrote:
>>>>>
>>>>>> Bill
>>>>>>
>>>>>> For your latest problem
>>>>>>
>>>>>>  libHSterminfo-0.4.1.5-ghc9.4.4.dylib” can’t be opened because Apple
>>>>>> cannot check it for malicious software.
>>>>>>
>>>>>> Did you try what I wrote in my last email:
>>>>>>
>>>>>>  rm -fr /usr/local/bin/ghc*
>>>>>> rm -fr /usr/local/lib/ghc*
>>>>>> ./configure
>>>>>> sudo xattr -rc .
>>>>>> sudo make install
>>>>>>
>>>>>> George
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Mar 15, 2023 at 1:20 PM William McEnaney <
>>>>>> bill.mcenaney...@gmail.com> wrote:
>>>>>>
>>>>>>> Hi, everyone,
>>>>>>>
>>>>>>> Thank you for the help. Someone will tell me how to solve
>>>>>>> the problem, I hope because it stumped me.
>>>>>>>
>>>>>>> Bill
>>>>>>>
>>>>>>> On Wed, Mar 15, 2023 at

Re: Installing GHC on my MacBook Air

[George Colpitts]

Hi Bill,

It's easy to forget to do replay all in gmail but it's important to do so
in these emails.

In your original email you wrote:

After installing the compiler, my laptop said its processor was wrong for
the binary distribution I chose. If there is a dmg file for *MacOS 12.5.1,*
please please link your reply to it.


Can you confirm that you no longer have the problem "of processor was wrong
for the binary distribution I chose." ?

My understanding is that after that you got the error:

libHSterminfo-0.4.1.5-ghc9.4.4.dylib” can’t be opened because Apple cannot
check it for malicious software.

I then suggested you had encountered
https://gitlab.haskell.org/ghc/ghc/-/issues/21506#note_447206  and I
suggested you do:

 rm -fr /usr/local/bin/ghc*
rm -fr /usr/local/lib/ghc*
./configure
sudo xattr -rc .
sudo make install


You said you did and got a warning "that some program wanted to access my
photos when I don't have any."

Can you repeat those steps and cut and paste your terminal session into an
email?

Unfortunately I am too busy to continue replying but with the above I think
somebody will be able to help you.

Cheers,
George


On Wed, Mar 15, 2023 at 1:59 PM William McEnaney 
wrote:

> Hi, George,
>
> I'd be happy to do that for you. But I'm sure I can recall the information
> a GHC maintainer would need.
>
> Best,
> Bill
>
> On Wed, Mar 15, 2023 at 12:41 PM George Colpitts <
> george.colpi...@gmail.com> wrote:
>
>> Hi William
>>
>> I think it's best if you submit a bug as described here
>> <https://gitlab.haskell.org/ghc/ghc/-/wikis/report-a-bug>
>>
>> Whether in email or in the bug report it is critical that you
>> describe how the reader can reproduce the bug, i.e. starting from the
>> beginning,  describe what you did and what error message(s) you got.
>>
>> Regards,
>> George
>>
>>
>> On Wed, Mar 15, 2023 at 1:34 PM William McEnaney <
>> bill.mcenaney...@gmail.com> wrote:
>>
>>> Hi, George,
>>>
>>> Yes, I did. But I must have made a mistake. After I pasted them into a
>>> Terminal window, the machine warned me that some program wanted to access
>>> my photos when I don't have any.
>>>
>>>
>>> On Wed, Mar 15, 2023 at 12:26 PM George Colpitts <
>>> george.colpi...@gmail.com> wrote:
>>>
>>>> Bill
>>>>
>>>> For your latest problem
>>>>
>>>>  libHSterminfo-0.4.1.5-ghc9.4.4.dylib” can’t be opened because Apple
>>>> cannot check it for malicious software.
>>>>
>>>> Did you try what I wrote in my last email:
>>>>
>>>>  rm -fr /usr/local/bin/ghc*
>>>> rm -fr /usr/local/lib/ghc*
>>>> ./configure
>>>> sudo xattr -rc .
>>>> sudo make install
>>>>
>>>> George
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Mar 15, 2023 at 1:20 PM William McEnaney <
>>>> bill.mcenaney...@gmail.com> wrote:
>>>>
>>>>> Hi, everyone,
>>>>>
>>>>> Thank you for the help. Someone will tell me how to solve the problem,
>>>>> I hope because it stumped me.
>>>>>
>>>>> Bill
>>>>>
>>>>> On Wed, Mar 15, 2023 at 12:10 PM Brandon Allbery 
>>>>> wrote:
>>>>>
>>>>>> That seems unlikely; it would report a permission error in that case,
>>>>>> not that it had the wrong architecture.
>>>>>>
>>>>>> On Wed, Mar 15, 2023 at 12:04 PM George Colpitts
>>>>>>  wrote:
>>>>>> >
>>>>>> > Hi Bill
>>>>>> >
>>>>>> > I'm cc'ing GHC dev and GHC users as someone else may have a better
>>>>>> answer, catch a mistake I made etc. Please don't delete them.
>>>>>> >
>>>>>> > I believe you have encountered
>>>>>> https://gitlab.haskell.org/ghc/ghc/-/issues/21506#note_447206
>>>>>> >
>>>>>> > I believe the way to fix this is to do the following:
>>>>>> >
>>>>>> > rm -fr /usr/local/bin/ghc*
>>>>>> > rm -fr /usr/local/lib/ghc*
>>>>>> > ./configure
>>>>>> > sudo xattr -rc .
>>>>>> > sudo make install
>>>>>> >
>>>>>> >
>>>>>> > However I am unsure why you are encountering this as the issue is
>>>>>> suppos

Re: Installing GHC on my MacBook Air

[George Colpitts]

Hi William

I think it's best if you submit a bug as described here
<https://gitlab.haskell.org/ghc/ghc/-/wikis/report-a-bug>

Whether in email or in the bug report it is critical that you describe how
the reader can reproduce the bug, i.e. starting from the beginning,
describe what you did and what error message(s) you got.

Regards,
George


On Wed, Mar 15, 2023 at 1:34 PM William McEnaney 
wrote:

> Hi, George,
>
> Yes, I did. But I must have made a mistake. After I pasted them into a
> Terminal window, the machine warned me that some program wanted to access
> my photos when I don't have any.
>
>
> On Wed, Mar 15, 2023 at 12:26 PM George Colpitts <
> george.colpi...@gmail.com> wrote:
>
>> Bill
>>
>> For your latest problem
>>
>>  libHSterminfo-0.4.1.5-ghc9.4.4.dylib” can’t be opened because Apple
>> cannot check it for malicious software.
>>
>> Did you try what I wrote in my last email:
>>
>>  rm -fr /usr/local/bin/ghc*
>> rm -fr /usr/local/lib/ghc*
>> ./configure
>> sudo xattr -rc .
>> sudo make install
>>
>> George
>>
>>
>>
>>
>> On Wed, Mar 15, 2023 at 1:20 PM William McEnaney <
>> bill.mcenaney...@gmail.com> wrote:
>>
>>> Hi, everyone,
>>>
>>> Thank you for the help. Someone will tell me how to solve the problem, I
>>> hope because it stumped me.
>>>
>>> Bill
>>>
>>> On Wed, Mar 15, 2023 at 12:10 PM Brandon Allbery 
>>> wrote:
>>>
>>>> That seems unlikely; it would report a permission error in that case,
>>>> not that it had the wrong architecture.
>>>>
>>>> On Wed, Mar 15, 2023 at 12:04 PM George Colpitts
>>>>  wrote:
>>>> >
>>>> > Hi Bill
>>>> >
>>>> > I'm cc'ing GHC dev and GHC users as someone else may have a better
>>>> answer, catch a mistake I made etc. Please don't delete them.
>>>> >
>>>> > I believe you have encountered
>>>> https://gitlab.haskell.org/ghc/ghc/-/issues/21506#note_447206
>>>> >
>>>> > I believe the way to fix this is to do the following:
>>>> >
>>>> > rm -fr /usr/local/bin/ghc*
>>>> > rm -fr /usr/local/lib/ghc*
>>>> > ./configure
>>>> > sudo xattr -rc .
>>>> > sudo make install
>>>> >
>>>> >
>>>> > However I am unsure why you are encountering this as the issue is
>>>> supposed to have been fixed.
>>>> >
>>>> > Cheers
>>>> > George
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > On Wed, Mar 15, 2023 at 11:21 AM William McEnaney <
>>>> bill.mcenaney...@gmail.com> wrote:
>>>> >>
>>>> >> Hi, George,
>>>> >>
>>>> >> I got this message when I ran make install with the sudo command.
>>>> What should I do?
>>>> >>
>>>> >> libHSterminfo-0.4.1.5-ghc9.4.4.dylib” can’t be opened because Apple
>>>> cannot check it for malicious software.
>>>> >>
>>>> >>
>>>> >> What should I do now?
>>>> >>
>>>> >>
>>>> >> Thanks.
>>>> >>
>>>> >>
>>>> >> Bill
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Wed, Mar 15, 2023 at 9:29 AM William McEnaney <
>>>> bill.mcenaney...@gmail.com> wrote:
>>>> >>>
>>>> >>> Hi George,
>>>> >>>
>>>> >>> Thank you for your reply. I forget what I did to install it. But
>>>> the compiler and other ghc-related programs live in /usr/local/bin. Since I
>>>> installed the wrong binaries, I changed the directory to /usr/local/bin and
>>>> tried to empty that directory with rm -rf ghc*.*, but that didn't delete
>>>> anything. So I wonder whether I'll need to remove those programs before
>>>> reinstalling ghc.
>>>> >>>
>>>> >>> Thanks for your help, too.
>>>> >>>
>>>> >>> Best,
>>>> >>> Bill
>>>> >>>
>>>> >>> On Wed, Mar 15, 2023 at 7:59 AM George Colpitts <
>>>> george.colpi...@gmail.com

Re: Installing GHC on my MacBook Air

[George Colpitts]

Bill

For your latest problem

 libHSterminfo-0.4.1.5-ghc9.4.4.dylib” can’t be opened because Apple cannot
check it for malicious software.

Did you try what I wrote in my last email:

 rm -fr /usr/local/bin/ghc*
rm -fr /usr/local/lib/ghc*
./configure
sudo xattr -rc .
sudo make install

George




On Wed, Mar 15, 2023 at 1:20 PM William McEnaney 
wrote:

> Hi, everyone,
>
> Thank you for the help. Someone will tell me how to solve the problem, I
> hope because it stumped me.
>
> Bill
>
> On Wed, Mar 15, 2023 at 12:10 PM Brandon Allbery 
> wrote:
>
>> That seems unlikely; it would report a permission error in that case,
>> not that it had the wrong architecture.
>>
>> On Wed, Mar 15, 2023 at 12:04 PM George Colpitts
>>  wrote:
>> >
>> > Hi Bill
>> >
>> > I'm cc'ing GHC dev and GHC users as someone else may have a better
>> answer, catch a mistake I made etc. Please don't delete them.
>> >
>> > I believe you have encountered
>> https://gitlab.haskell.org/ghc/ghc/-/issues/21506#note_447206
>> >
>> > I believe the way to fix this is to do the following:
>> >
>> > rm -fr /usr/local/bin/ghc*
>> > rm -fr /usr/local/lib/ghc*
>> > ./configure
>> > sudo xattr -rc .
>> > sudo make install
>> >
>> >
>> > However I am unsure why you are encountering this as the issue is
>> supposed to have been fixed.
>> >
>> > Cheers
>> > George
>> >
>> >
>> >
>> >
>> >
>> > On Wed, Mar 15, 2023 at 11:21 AM William McEnaney <
>> bill.mcenaney...@gmail.com> wrote:
>> >>
>> >> Hi, George,
>> >>
>> >> I got this message when I ran make install with the sudo command. What
>> should I do?
>> >>
>> >> libHSterminfo-0.4.1.5-ghc9.4.4.dylib” can’t be opened because Apple
>> cannot check it for malicious software.
>> >>
>> >>
>> >> What should I do now?
>> >>
>> >>
>> >> Thanks.
>> >>
>> >>
>> >> Bill
>> >>
>> >>
>> >>
>> >>
>> >> On Wed, Mar 15, 2023 at 9:29 AM William McEnaney <
>> bill.mcenaney...@gmail.com> wrote:
>> >>>
>> >>> Hi George,
>> >>>
>> >>> Thank you for your reply. I forget what I did to install it. But the
>> compiler and other ghc-related programs live in /usr/local/bin. Since I
>> installed the wrong binaries, I changed the directory to /usr/local/bin and
>> tried to empty that directory with rm -rf ghc*.*, but that didn't delete
>> anything. So I wonder whether I'll need to remove those programs before
>> reinstalling ghc.
>> >>>
>> >>> Thanks for your help, too.
>> >>>
>> >>> Best,
>> >>> Bill
>> >>>
>> >>> On Wed, Mar 15, 2023 at 7:59 AM George Colpitts <
>> george.colpi...@gmail.com> wrote:
>> >>>>
>> >>>> Hi Bill
>> >>>>
>> >>>> Yes,GHC will run on your new MacBook Air. The cpu in that is Apple
>> Silicon , the aarch64-apple-darwin platform. Older Macs run on Intel chips,
>> the x86_64-apple-darwin platform.
>> >>>>
>> >>>> I'm not sure how you installed the compiler. I believe the standard
>> way is described on https://www.haskell.org/ghcup/. Can you tell us how
>> you installed it?
>> >>>>
>> >>>> Thanks
>> >>>> George
>> >>>>
>> >>>> On Wed, Mar 15, 2023 at 8:22 AM Simon Peyton Jones <
>> simon.peytonjo...@gmail.com> wrote:
>> >>>>>
>> >>>>> Redirecting this query to ghc-devs.  Can anyone help William?
>> Thanks!
>> >>>>>
>> >>>>>> Will GHC run on my new MacBook Air? After installing the compiler,
>> my laptop said its processor was wrong for the binary distribution I chose.
>> If there is a dmg file for MacOS 12.5.1, please please link your reply to
>> it.
>> >>>>>
>> >>>>>
>> >>>>> Simon
>> >>>>>
>> >>>>> On Tue, 14 Mar 2023 at 23:33, William McEnaney <
>> bill.mcenaney...@gmail.com> wrote:
>> >>>>>>
>> >>>>>> Dear Dr. Jones,
>> >>>>>>
>> >>>>>> Will GHC run on my new MacBook Air? After installing the compiler,
>> my laptop said its processor was wrong for the binary distribution I chose.
>> If there is a dmg file for MacOS 12.5.1, please please link your reply to
>> it.
>> >>>>>>
>> >>>>>> Thanks for your help.
>> >>>>>>
>> >>>>>> Best,
>> >>>>>> Bill
>> >>>>>
>> >>>>> ___
>> >>>>> ghc-devs mailing list
>> >>>>> ghc-d...@haskell.org
>> >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >
>> > ___
>> > ghc-devs mailing list
>> > ghc-d...@haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>>
>>
>> --
>> brandon s allbery kf8nh
>> allber...@gmail.com
>>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Installing GHC on my MacBook Air

[George Colpitts]

cc'ing others

On Wed, Mar 15, 2023 at 1:20 PM George Colpitts 
wrote:

> Thanks Brandon. There were some earlier emails that somehow got dropped
> from this.
>
> I believe we have already solved the wrong architecture issue; this is the
> next issue.
>
> Here is the earlier email:
>
> I  just noticed that you said you installed a binary distribution. If for
> example you chose the 9.4.4 distribution at
> https://www.haskell.org/ghc/download_ghc_9_4_4.html#macosx_x86_64 you
> should choose one of:
>
>
>- ghc-9.4.4-aarch64-apple-darwin.tar.xz
>   
> <https://downloads.haskell.org/~ghc/9.4.4/ghc-9.4.4-aarch64-apple-darwin.tar.xz>
>  (187.0
>   MB, sig
>   
> <https://downloads.haskell.org/~ghc/9.4.4/ghc-9.4.4-aarch64-apple-darwin.tar.xz.sig>
>   )
>   - ghc-9.4.4-aarch64-apple-darwin.tar.bz2
>   
> <https://downloads.haskell.org/~ghc/9.4.4/ghc-9.4.4-aarch64-apple-darwin.tar.bz2>
>  (300.0
>   MB, sig
>   
> <https://downloads.haskell.org/~ghc/9.4.4/ghc-9.4.4-aarch64-apple-darwin.tar.bz2.sig>
>   )
>
> rather than
>
>
>- ghc-9.4.4-x86_64-apple-darwin.tar.xz
>   
> <https://downloads.haskell.org/~ghc/9.4.4/ghc-9.4.4-x86_64-apple-darwin.tar.xz>
>  (177.9
>   MB, sig
>   
> <https://downloads.haskell.org/~ghc/9.4.4/ghc-9.4.4-x86_64-apple-darwin.tar.xz.sig>
>   )
>   - ghc-9.4.4-x86_64-apple-darwin.tar.bz2
>   
> <https://downloads.haskell.org/~ghc/9.4.4/ghc-9.4.4-x86_64-apple-darwin.tar.bz2>
>  (281.9
>   MB, sig
>   
> <https://downloads.haskell.org/~ghc/9.4.4/ghc-9.4.4-x86_64-apple-darwin.tar.bz2.sig>
>   )
>
>
> On Wed, Mar 15, 2023 at 1:10 PM Brandon Allbery 
> wrote:
>
>> That seems unlikely; it would report a permission error in that case,
>> not that it had the wrong architecture.
>>
>> On Wed, Mar 15, 2023 at 12:04 PM George Colpitts
>>  wrote:
>> >
>> > Hi Bill
>> >
>> > I'm cc'ing GHC dev and GHC users as someone else may have a better
>> answer, catch a mistake I made etc. Please don't delete them.
>> >
>> > I believe you have encountered
>> https://gitlab.haskell.org/ghc/ghc/-/issues/21506#note_447206
>> >
>> > I believe the way to fix this is to do the following:
>> >
>> > rm -fr /usr/local/bin/ghc*
>> > rm -fr /usr/local/lib/ghc*
>> > ./configure
>> > sudo xattr -rc .
>> > sudo make install
>> >
>> >
>> > However I am unsure why you are encountering this as the issue is
>> supposed to have been fixed.
>> >
>> > Cheers
>> > George
>> >
>> >
>> >
>> >
>> >
>> > On Wed, Mar 15, 2023 at 11:21 AM William McEnaney <
>> bill.mcenaney...@gmail.com> wrote:
>> >>
>> >> Hi, George,
>> >>
>> >> I got this message when I ran make install with the sudo command. What
>> should I do?
>> >>
>> >> libHSterminfo-0.4.1.5-ghc9.4.4.dylib” can’t be opened because Apple
>> cannot check it for malicious software.
>> >>
>> >>
>> >> What should I do now?
>> >>
>> >>
>> >> Thanks.
>> >>
>> >>
>> >> Bill
>> >>
>> >>
>> >>
>> >>
>> >> On Wed, Mar 15, 2023 at 9:29 AM William McEnaney <
>> bill.mcenaney...@gmail.com> wrote:
>> >>>
>> >>> Hi George,
>> >>>
>> >>> Thank you for your reply. I forget what I did to install it. But the
>> compiler and other ghc-related programs live in /usr/local/bin. Since I
>> installed the wrong binaries, I changed the directory to /usr/local/bin and
>> tried to empty that directory with rm -rf ghc*.*, but that didn't delete
>> anything. So I wonder whether I'll need to remove those programs before
>> reinstalling ghc.
>> >>>
>> >>> Thanks for your help, too.
>> >>>
>> >>> Best,
>> >>> Bill
>> >>>
>> >>> On Wed, Mar 15, 2023 at 7:59 AM George Colpitts <
>> george.colpi...@gmail.com> wrote:
>> >>>>
>> >>>> Hi Bill
>> >>>>
>> >>>> Yes,GHC will run on your new MacBook Air. The cpu in that is Apple
>> Silicon , the aarch64-apple-darwin platform. Older Macs run on Intel chips,
>> the x86_64-apple-darwin platform.
>> >>>>
>> >>>> I'm not sure how

Re: Installing GHC on my MacBook Air

[George Colpitts]

Hi Bill

I'm cc'ing GHC dev and GHC users as someone else may have a better answer,
catch a mistake I made etc. Please don't delete them.

I believe you have encountered
https://gitlab.haskell.org/ghc/ghc/-/issues/21506#note_447206

I believe the way to fix this is to do the following:

rm -fr /usr/local/bin/ghc*
rm -fr /usr/local/lib/ghc*
./configure
sudo xattr -rc .
sudo make install


However I am unsure why you are encountering this as the issue is supposed
to have been fixed.

Cheers
George





On Wed, Mar 15, 2023 at 11:21 AM William McEnaney <
bill.mcenaney...@gmail.com> wrote:

> Hi, George,
>
> I got this message when I ran make install with the sudo command. What
> should I do?
>
> *libHSterminfo-0.4.1.5-ghc9.4.4.dylib” can’t be opened because Apple
> cannot check it for malicious software.*
>
>
> What should I do now?
>
>
> Thanks.
>
>
> Bill
>
>
>
>
> On Wed, Mar 15, 2023 at 9:29 AM William McEnaney <
> bill.mcenaney...@gmail.com> wrote:
>
>> Hi George,
>>
>> Thank you for your reply. I forget what I did to install it. But the
>> compiler and other ghc-related programs live in /usr/local/bin. Since I
>> installed the wrong binaries, I changed the directory to /usr/local/bin and
>> tried to empty that directory with *rm -rf ghc*.**, but that didn't
>> delete anything. So I wonder whether I'll need to remove those programs
>> before reinstalling ghc.
>>
>> Thanks for your help, too.
>>
>> Best,
>> Bill
>>
>> On Wed, Mar 15, 2023 at 7:59 AM George Colpitts <
>> george.colpi...@gmail.com> wrote:
>>
>>> Hi Bill
>>>
>>> Yes,GHC will run on your new MacBook Air. The cpu in that is Apple
>>> Silicon , the aarch64-apple-darwin platform. Older Macs run on Intel chips,
>>> the x86_64-apple-darwin platform.
>>>
>>> I'm not sure how you installed the compiler. I believe the standard way
>>> is described on https://www.haskell.org/ghcup/. Can you tell us how you
>>> installed it?
>>>
>>> Thanks
>>> George
>>>
>>> On Wed, Mar 15, 2023 at 8:22 AM Simon Peyton Jones <
>>> simon.peytonjo...@gmail.com> wrote:
>>>
>>>> Redirecting this query to ghc-devs.  Can anyone help William?  Thanks!
>>>>
>>>> Will GHC run on my new MacBook Air? After installing the compiler, my
>>>>> laptop said its processor was wrong for the binary distribution I chose. 
>>>>> If
>>>>> there is a dmg file for MacOS 12.5.1, please please link your reply to it.
>>>>>
>>>>
>>>> Simon
>>>>
>>>> On Tue, 14 Mar 2023 at 23:33, William McEnaney <
>>>> bill.mcenaney...@gmail.com> wrote:
>>>>
>>>>> Dear Dr. Jones,
>>>>>
>>>>> Will GHC run on my new MacBook Air? After installing the compiler, my
>>>>> laptop said its processor was wrong for the binary distribution I chose. 
>>>>> If
>>>>> there is a dmg file for MacOS 12.5.1, please please link your reply to it.
>>>>>
>>>>> Thanks for your help.
>>>>>
>>>>> Best,
>>>>> Bill
>>>>>
>>>> ___
>>>> ghc-devs mailing list
>>>> ghc-d...@haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>>
>>>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] GHC 9.6.1-alpha3 is now available

[George Colpitts]

reported as https://gitlab.haskell.org/ghc/ghc/-/issues/22993

Thanks & Regards
George

On Wed, Feb 15, 2023 at 2:04 PM George Colpitts 
wrote:

> It seems wrong to me that the configure file references Xcode.app and
> MacOSX12.1:
>
> bash-3.2$ fgrep Xcode.app configure
>
> FFIIncludeDir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/usr/include/ffi
>
> FFILibDir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/usr/lib
>
>
> On Wed, Feb 15, 2023 at 1:51 PM George Colpitts 
> wrote:
>
>>
>> Hi Ben
>>
>> Thanks for replying.
>>
>> As I mentioned in my original email I'm on Ventura,13.2.1, I just
>> upgraded to that before installing alpha3.
>>
>> I have command line tools. I did the following to reinstall them and got
>> the same results stated in my email:
>>
>>  sudo rm -rf /Library/Developer/CommandLineTools
>> Password:
>> bash-3.2$ xcode-select --install
>> xcode-select: note: install requested for command line developer tools
>>
>>
>> Looking more carefully at the error message:
>>
>> checking Xcode version... xcode-select: error: tool 'xcodebuild' requires
>> > Xcode, but active developer directory '/Library/Developer/CommandLin
>> eTools'
>> > is a command line tools instance
>> > not found (too old?)
>>
>> It seems to be saying that I need Xcode not command line tools. That's
>> also consistent with the linker warning message:
>>
>> ld: warning: directory not found for option '-L/Applications/*Xcode.app*
>> /Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/usr/lib'
>>
>>
>> There is no urgency on my part to get this resolved. We may want to just
>> wait to see if anybody else on 13.2.1 got this also.
>>
>> Thanks
>> George
>>
>>
>> On Wed, Feb 15, 2023 at 1:20 PM Ben Gamari  wrote:
>>
>>> George Colpitts  writes:
>>>
>>> > Hi
>>> >
>>> > I get a strange warning on MacOS when I do ./configure:
>>> >
>>> > checking Xcode version... xcode-select: error: tool 'xcodebuild'
>>> requires
>>> > Xcode, but active developer directory
>>> '/Library/Developer/CommandLineTools'
>>> > is a command line tools instance
>>> > not found (too old?)
>>> >
>>> >
>>> > I also get a related strange warning when I do a compile:
>>> >
>>> > ghc hello.hs
>>> > [1 of 2] Compiling Main ( hello.hs, hello.o ) [Missing
>>> object
>>> > file]
>>> > [2 of 2] Linking hello [Objects changed]
>>> > ld: warning: directory not found for option
>>> >
>>> '-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/usr/lib'
>>> >
>>> Hmm, that is indeed odd. It sounds like you Xcode installation may be
>>> broken. Did you upgrade your operating system recently? Do you have
>>> Xcode, the CLT package, or both installed?
>>>
>>> Cheers,
>>>
>>> - Ben
>>>
>>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] GHC 9.6.1-alpha3 is now available

[George Colpitts]

It seems wrong to me that the configure file references Xcode.app and
MacOSX12.1:

bash-3.2$ fgrep Xcode.app configure
FFIIncludeDir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/usr/include/ffi
FFILibDir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/usr/lib


On Wed, Feb 15, 2023 at 1:51 PM George Colpitts 
wrote:

>
> Hi Ben
>
> Thanks for replying.
>
> As I mentioned in my original email I'm on Ventura,13.2.1, I just upgraded
> to that before installing alpha3.
>
> I have command line tools. I did the following to reinstall them and got
> the same results stated in my email:
>
>  sudo rm -rf /Library/Developer/CommandLineTools
> Password:
> bash-3.2$ xcode-select --install
> xcode-select: note: install requested for command line developer tools
>
>
> Looking more carefully at the error message:
>
> checking Xcode version... xcode-select: error: tool 'xcodebuild' requires
> > Xcode, but active developer directory '/Library/Developer/CommandLin
> eTools'
> > is a command line tools instance
> > not found (too old?)
>
> It seems to be saying that I need Xcode not command line tools. That's
> also consistent with the linker warning message:
>
> ld: warning: directory not found for option '-L/Applications/*Xcode.app*
> /Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/usr/lib'
>
>
> There is no urgency on my part to get this resolved. We may want to just
> wait to see if anybody else on 13.2.1 got this also.
>
> Thanks
> George
>
>
> On Wed, Feb 15, 2023 at 1:20 PM Ben Gamari  wrote:
>
>> George Colpitts  writes:
>>
>> > Hi
>> >
>> > I get a strange warning on MacOS when I do ./configure:
>> >
>> > checking Xcode version... xcode-select: error: tool 'xcodebuild'
>> requires
>> > Xcode, but active developer directory
>> '/Library/Developer/CommandLineTools'
>> > is a command line tools instance
>> > not found (too old?)
>> >
>> >
>> > I also get a related strange warning when I do a compile:
>> >
>> > ghc hello.hs
>> > [1 of 2] Compiling Main ( hello.hs, hello.o ) [Missing
>> object
>> > file]
>> > [2 of 2] Linking hello [Objects changed]
>> > ld: warning: directory not found for option
>> >
>> '-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/usr/lib'
>> >
>> Hmm, that is indeed odd. It sounds like you Xcode installation may be
>> broken. Did you upgrade your operating system recently? Do you have
>> Xcode, the CLT package, or both installed?
>>
>> Cheers,
>>
>> - Ben
>>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] GHC 9.6.1-alpha3 is now available

[George Colpitts]

Hi Ben

Thanks for replying.

As I mentioned in my original email I'm on Ventura,13.2.1, I just upgraded
to that before installing alpha3.

I have command line tools. I did the following to reinstall them and got
the same results stated in my email:

 sudo rm -rf /Library/Developer/CommandLineTools
Password:
bash-3.2$ xcode-select --install
xcode-select: note: install requested for command line developer tools


Looking more carefully at the error message:

checking Xcode version... xcode-select: error: tool 'xcodebuild' requires
> Xcode, but active developer directory '/Library/Developer/CommandLin
eTools'
> is a command line tools instance
> not found (too old?)

It seems to be saying that I need Xcode not command line tools. That's also
consistent with the linker warning message:

ld: warning: directory not found for option '-L/Applications/*Xcode.app*
/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/usr/lib'


There is no urgency on my part to get this resolved. We may want to just
wait to see if anybody else on 13.2.1 got this also.

Thanks
George


On Wed, Feb 15, 2023 at 1:20 PM Ben Gamari  wrote:

> George Colpitts  writes:
>
> > Hi
> >
> > I get a strange warning on MacOS when I do ./configure:
> >
> > checking Xcode version... xcode-select: error: tool 'xcodebuild' requires
> > Xcode, but active developer directory
> '/Library/Developer/CommandLineTools'
> > is a command line tools instance
> > not found (too old?)
> >
> >
> > I also get a related strange warning when I do a compile:
> >
> > ghc hello.hs
> > [1 of 2] Compiling Main ( hello.hs, hello.o ) [Missing object
> > file]
> > [2 of 2] Linking hello [Objects changed]
> > ld: warning: directory not found for option
> >
> '-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/usr/lib'
> >
> Hmm, that is indeed odd. It sounds like you Xcode installation may be
> broken. Did you upgrade your operating system recently? Do you have
> Xcode, the CLT package, or both installed?
>
> Cheers,
>
> - Ben
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] GHC 9.6.1-alpha3 is now available

[George Colpitts]

Hi

I get a strange warning on MacOS when I do ./configure:

checking Xcode version... xcode-select: error: tool 'xcodebuild' requires
Xcode, but active developer directory '/Library/Developer/CommandLineTools'
is a command line tools instance
not found (too old?)


I also get a related strange warning when I do a compile:

ghc hello.hs
[1 of 2] Compiling Main ( hello.hs, hello.o ) [Missing object
file]
[2 of 2] Linking hello [Objects changed]
ld: warning: directory not found for option
'-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/usr/lib'

I'm on macOS 13.2.1. I was previously on ghc 9.4.4.

Thanks
George


On Tue, Feb 14, 2023 at 9:39 AM Ben Gamari  wrote:

>
> The GHC team is very pleased to announce the availability of GHC
> 9.6.1-alpha3.
> As usual, binaries and source distributions are available at
> downloads.haskell.org:
>
> https://downloads.haskell.org/ghc/9.6.1-alpha3/
>
> Beginning with GHC 9.6.1, GHC can be built as a cross-compiler to
> WebAssembly and JavaScript. This is an important step towards robust
> support for compiling Haskell to the Web, but there are a few caveats to
> be aware of in the 9.6 series:
>
>  - Both the Javascript and WebAssembly backends are still at an early
>stage of development and are present in this release as a technology
> preview
>
>  - Using GHC as a cross-compiler is not as easy as we would like it to
>be; in particular, there are challenges related to Template Haskell
>
>  - GHC is not yet run-time retargetable; a given GHC binary targets
>exactly one platform, and both WebAssembly and JavaScript are considered
>platforms for this purpose. Cross-compilers must be built from source by
>their users
>
> We hope to lift all of these limitations in future releases.
>
> Additionally, 9.6.1 will include:
>
>  - Significant latency improvements in the non-moving garbage collector
>
>  - Efficient runtime support for delimited continuations
>
>  - Improvements in compiler error messages
>
>  - Numerous improvements in the compiler's memory usage
>
> See the [release notes] for a comprehensive accounting of changes in this
> release.
>
> As always, one can find a [migration guide] to aid in transitioning from
> older
> releases on the GHC Wiki. We have also recently started extending our
> release process to cover a wider set of Linux distributions. In
> particular, we now offer Rocky 8 and Ubuntu 20.04 binary distributions
> which cover RedHat-derivative and distributions using older `glibc`
> releases (namely 2.27), respectively.
>
> Please do give this release a try and open a [ticket] if you see anything
> amiss.
>
> Cheers,
>
> - Ben
>
>
> [ticket]: https://gitlab.haskell.org/ghc/ghc/issues/
> [migration guide]:
> https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.6
> [release notes]:
> https://downloads.haskell.org/ghc/9.6.1-alpha3/docs/users_guide/9.6.1-notes.html
> ___
> ghc-devs mailing list
> ghc-d...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] GHC 9.6.1-alpha1 is now available

[George Colpitts]

On Sun, Jan 15, 2023 at 1:01 PM George Colpitts 
wrote:

> my original email corrected below
>
> On Sat, Jan 14, 2023 at 8:51 AM George Colpitts 
> wrote:
>
>> Hi
>>
>> I believe llvm 15 does not work in this alpha as 21936 is still open. Is
>> that correct?
>>
>> I also believe that when it does work ghc 9.6 will not be compatible
>> with earlier versions of llvm. Is that correct?
>>
>> Thanks
>> George
>>
>>
>>
>>
>> On Fri, Jan 13, 2023 at 7:02 PM Ben Gamari  wrote:
>>
>>>
>>> The GHC team is very pleased to announce the availability of GHC
>>> 9.6.1-alpha1. As usual, binaries and source distributions are available
>>> at downloads.haskell.org:
>>>
>>> https://downloads.haskell.org/ghc/9.6.1-alpha1/
>>>
>>> This is the first alpha release in the 9.6 series which will bring a
>>> number of exciting features:
>>>
>>> * A new Javascript code generation backend
>>>
>>> * A new WebAssembly code generation backend,
>>>
>>> * Significant latency improvements in the non-moving garbage collector
>>>
>>> * Support for loading of multiple components in GHCi
>>>
>>> * Efficient support for delimited continuations
>>>
>>> * Improvements in error messages
>>>
>>> * Numerous improvements in compiler-residency
>>>
>>> Note that both the Javascript and WebAssembly backends are still in a
>>> state of infancy and are present in this release as a technology
>>> preview; we hope that they will mature considerably before the final
>>> 9.6.1 release.
>>>
>>> Please give this release a try and open a [ticket] if you see anything
>>> amiss.
>>>
>>> Cheers,
>>>
>>> - Ben
>>>
>>>
>>> [ticket]: https://gitlab.haskell.org/ghc/ghc/issues/
>>>
>>> ___
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>>
>>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] GHC 9.6.1-alpha1 is now available

[George Colpitts]

my original email corrected below

On Sat, Jan 14, 2023 at 8:51 AM George Colpitts 
wrote:

> Hi
>
> I believe llvm 15 does not work in this alpha as 21936 is still open. Is
> that correct?
>
> I also believe that when it does work ghc 9.6 will not be compatible with
> earlier versions of llvm 15. Is that correct?
>
> Thanks
> George
>
>
>
>
> On Fri, Jan 13, 2023 at 7:02 PM Ben Gamari  wrote:
>
>>
>> The GHC team is very pleased to announce the availability of GHC
>> 9.6.1-alpha1. As usual, binaries and source distributions are available
>> at downloads.haskell.org:
>>
>> https://downloads.haskell.org/ghc/9.6.1-alpha1/
>>
>> This is the first alpha release in the 9.6 series which will bring a
>> number of exciting features:
>>
>> * A new Javascript code generation backend
>>
>> * A new WebAssembly code generation backend,
>>
>> * Significant latency improvements in the non-moving garbage collector
>>
>> * Support for loading of multiple components in GHCi
>>
>> * Efficient support for delimited continuations
>>
>> * Improvements in error messages
>>
>> * Numerous improvements in compiler-residency
>>
>> Note that both the Javascript and WebAssembly backends are still in a
>> state of infancy and are present in this release as a technology
>> preview; we hope that they will mature considerably before the final
>> 9.6.1 release.
>>
>> Please give this release a try and open a [ticket] if you see anything
>> amiss.
>>
>> Cheers,
>>
>> - Ben
>>
>>
>> [ticket]: https://gitlab.haskell.org/ghc/ghc/issues/
>>
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] GHC 9.6.1-alpha1 is now available

[George Colpitts]

Hi

I believe llvm does not work in this alpha as 21936 is still open. Is that
correct?

I also believe that when it does work it will require llvm 15 which will be
incompatible with earlier versions of ghc. Is that correct?

Thanks
George




On Fri, Jan 13, 2023 at 7:02 PM Ben Gamari  wrote:

>
> The GHC team is very pleased to announce the availability of GHC
> 9.6.1-alpha1. As usual, binaries and source distributions are available
> at downloads.haskell.org:
>
> https://downloads.haskell.org/ghc/9.6.1-alpha1/
>
> This is the first alpha release in the 9.6 series which will bring a
> number of exciting features:
>
> * A new Javascript code generation backend
>
> * A new WebAssembly code generation backend,
>
> * Significant latency improvements in the non-moving garbage collector
>
> * Support for loading of multiple components in GHCi
>
> * Efficient support for delimited continuations
>
> * Improvements in error messages
>
> * Numerous improvements in compiler-residency
>
> Note that both the Javascript and WebAssembly backends are still in a
> state of infancy and are present in this release as a technology
> preview; we hope that they will mature considerably before the final
> 9.6.1 release.
>
> Please give this release a try and open a [ticket] if you see anything
> amiss.
>
> Cheers,
>
> - Ben
>
>
> [ticket]: https://gitlab.haskell.org/ghc/ghc/issues/
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

ghc doesn't work after installing 9.4.1 on my Mac

[George Colpitts]

Unfortunately ghc doesn't work after installing 9.4.1 on my Mac. Does it
work for others?

After the install finishes when I do the following:

$ ghc --version
bash: /usr/local/bin/ghc: Permission denied
$ sudo chmod +x /usr/local/bin/ghc
$ghc --version
/usr/local/bin/ghc: line 1: exec: : not found
$ cat /usr/local/bin/ghc
exec "$executablename" -B"$libdir" ${1+"$@"}
$ cat /usr/local/bin/ghc-9.4.1
#!/bin/sh
exedir="/usr/local/lib/ghc-9.4.1/bin"
exeprog="ghc-9.4.1"
executablename="/usr/local/lib/ghc-9.4.1/bin/ghc-9.4.1"
bindir="/usr/local/bin"
libdir="/usr/local/lib/ghc-9.4.1/lib"
docdir="/usr/local/share/doc/ghc-9.4.1"
includedir="/usr/local/include"

exec "$executablename" -B"$libdir" ${1+"$@"}


Thanks
George



On Sun, Aug 7, 2022 at 6:30 PM Ben Gamari  wrote:

> The GHC developers are very pleased to announce the availability of GHC
> 9.4.1. Binary distributions, source distributions, and documentation are
> available at downloads.haskell.org:
>
> https://downloads.haskell.org/ghc/9.4.1
>
> This release includes:
>
>  - A new profiling mode, `-fprof-late`, which adds automatic cost-center
>annotations to all top-level functions *after* Core optimisation has
>run. This provides informative profiles while interfering
>significantly less with GHC's aggressive optimisations, making it
>easier to understand the performance of programs which depend upon
>simplification..
>
>  - A variety of plugin improvements including the introduction of a new
>plugin type, *defaulting plugins*, and the ability for typechecking
>plugins to rewrite type-families.
>
>  - An improved constructed product result analysis, allowing unboxing of
>nested structures, and a new boxity analysis, leading to less reboxing.
>
>  - Introduction of a tag-check elision optimisation, bringing
>significant performance improvements in strict programs.
>
>  - Generalisation of a variety of primitive types to be levity
>polymorphic. Consequently, the `ArrayArray#` type can at long last be
>retired, replaced by standard `Array#`.
>
>  - Introduction of the `\cases` syntax from [GHC proposal 0302].
>
>  - A complete overhaul of GHC's Windows support. This includes a
>migration to a fully Clang-based C toolchain, a deep refactoring of
>the linker, and many fixes in WinIO.
>
>  - Support for multiple home packages, significantly improving support
>in IDEs and other tools for multi-package projects.
>
>  - A refactoring of GHC's error message infrastructure, allowing GHC to
>provide diagnostic information to downstream consumers as structured
>data, greatly easing IDE support.
>
>  - Significant compile-time improvements to runtime and memory consumption.
>
>  - On overhaul of our packaging infrastructure, allowing full
>traceability of release artifacts and more reliable binary
>distributions.
>
>  - Reintroduction of deep subsumption (which was previously dropped with
> the
>*simplified subsumption* change) as a language extension.
>
>  - ... and much more. See the [release notes] for a full accounting.
>
> Note that, as 9.4.1 is the first release for which the released artifacts
> will
> all be generated by our Hadrian build system, it is possible that there
> will be
> packaging issues. If you enounter trouble while using a binary
> distribution,
> please open a [ticket]. Likewise, if you are a downstream packager, do
> consider
> migrating to [Hadrian] to run your build; the Hadrian build system can be
> built
> using `cabal-install`, `stack`, or the in-tree [bootstrap script]. See the
> accompanying
> [blog post] for details on migrating packaging to Hadrian.
>
> We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool,
> Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and
> other anonymous contributors whose on-going financial and in-kind support
> has
> facilitated GHC maintenance and release management over the years. Finally,
> this release would not have been possible without the hundreds of
> open-source
> contributors whose work comprise this release.
>
> As always, do give this release a try and open a [ticket] if you see
> anything amiss.
>
> Happy testing,
>
> - Ben
>
>
> [GHC proposal 0302]:
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-cases.rst
> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
> [bootstrap script]:
> https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian/bootstrap/README.md
> [Hadrian]:
> https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian
> [release notes]:
> https://downloads.haskell.org/~ghc/9.4.1/docs/users_guide/9.4.1-notes.html
> [blog post]:
> https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html
> ___
> ghc-devs mailing list
> ghc-d...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

Re: [Haskell] [ANNOUNCE] GHC 9.2.4 released

[George Colpitts]

Thanks Zubin, this is good news.

On a Mac when do ./configure I see

checking Xcode version... xcode-select: error: tool 'xcodebuild' requires
Xcode, but active developer directory '/Library/Developer/CommandLineTools'
is a command line tools instance

not found (too old?)

I assume I can ignore that but FWIW it's weird as I do have that
directory and it is not old:


$ ls -ld /Library/Developer/CommandLineTools
drwxr-xr-x@ 5 root  wheel  160 27 May 20:54
/Library/Developer/CommandLineTools

$ xcode-select --version
xcode-select version 2395.


On a Mac it is still necessary to do

xattr -rc .

before doing

sudo make install


this is also true for 9.4.1-rc1 which I noted in 21506
.

Thanks
George





On Thu, Jul 28, 2022 at 8:17 AM Zubin Duggal  wrote:

> The GHC developers are very happy to at announce the availability of GHC
> 9.2.4. Binary distributions, source distributions, and documentation are
> available at [`downloads.haskell.org`](
> https://downloads.haskell.org/ghc/9.2.4).
>
> Download Page: https://www.haskell.org/ghc/download_ghc_9_2_4.html
> Blog Post:
> https://www.haskell.org/ghc/blog/20220728-ghc-9.2.4-released.html
>
> This release will include:
>
>   - The new `DeepSubsumption` language extension which reverses the
> effects of the [Simplified Subsumption Proposal] introduced in GHC
> 9.0. This
> is an attempt to make GHC 9.2.4 more backwards compatible with GHC
> 8.10 and
> eases migration for users who depended on this feature.
>
> This extension is enabled by default with the `Haskell2010`
> and `Haskell98` languages but disabled with the `GHC2021`
> language originally introduced in GHC 9.2.1.
>
> See the [Deep Subsumption Proposal] for more details.
>
>   - Fixes for segfaults that may arise due to a bug in the implementation
> of the
> `keepAlive#` primop. This may regress performance for certain programs
> which
> use this primop or functions which use the primop, such as
> `withForeignPtr`.
> These regressions are mostly small, but can be larger in certain edge
> cases.
> Judicious use of `unsafeWithForeignPtr` when its argument is known not
> to
> statically diverge can mitigate these in many cases. It is our
> judgment that
> the critical correctness issues justify the regression in performance
> and that
> it is important to get a release out with the fix while we work on a
> better
> approach which will improve performance for future releases (#21708).
>
> We have a [wiki page](
> https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/with-combinator)
> that tracks possible solutions to this problem, and Ben wrote a
> [blog post](
> https://www.haskell.org/ghc/blog/20210607-the-keepAlive-story.html)
> detailing the introduction of the `keepAlive#` primop and its history.
>
>   - Fixes for a number of miscompilations on AArch64 and other platforms
> (#21624,
> #21773, #20735, #21685).
>
>   - Fixes for segfaults due to bugs in the RTS and GC (#21708, #21880,
> #21885).
>
>   - Fixing the behaviour of Ctrl-C with GHCi on Windows (#21889).
>
>- ... and much more. See the [release notes] for a full accounting.
>
> As some of the fixed issues do affect correctness users are encouraged to
> upgrade promptly.
>
> We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk
> stake pool, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation,
> and other anonymous
> contributors whose on-going financial and in-kind support has
> facilitated GHC maintenance and release management over the years.
> Finally, this release would not have been possible without the hundreds
> of open-source contributors whose work comprise this release.
>
> As always, do give this release a try and open a [ticket] if you see
> anything amiss.
>
> Happy compiling,
>
> - Zubin
>
> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
> [release notes]:
> https://downloads.haskell.org/~ghc/9.2.4/docs/users_guide/9.2.4-notes.html
> [Simplified Subsumption Proposal]:
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst
> [Deep Subsumption Proposal]:
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0511-deep-subsumption.rst
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

success on a slightly modified version of your suggestion for 21506

[George Colpitts]

Hi Ben

Thanks for the quick responses particularly on the weekend before your
vacation.

you wrote:

What happens
if you try to install to do something like (in the extracted binary
distribution),


$ ./configure --prefix=`pwd`/tmp
$ make install# this will fail
$ xattr -rc .
$ make install# perhaps this will finish successfully?
# tmp/bin/ghc --version   # GHC should be usable


success on both my machines using a slightly modified version of your
suggestion above for 21506:

 ./configure --prefix=`pwd`/tmp# specifying ./tmp seems to be critical

xattr -rc .# seems to be necessary
also

sudo make install   # seems to works , output ends
with "recache"

./tmp/bin/ghc --version  # success , although admittedly
the smallest smoke test possible

You wrote:

>
Ultimately I think we may just need to bite the bullet and start
properly notarising/codesigning releases (resolving #17418). At this point
we have
spent more time trying to avoid the notarisation requirement than
it would likely take to satisfy it. Unfortunately, this will require
that I find an Apple device somewhere which may take a few weeks.


I'm afraid I am on holiday next week but I would quite grateful if we
could arrange for a chat after I return such that we can debug this in
realtime.


Sure, we can chat when you return from your vacation.

Not sure if it is worth trying to fix the release on the basis of what I
write above. My opinion is: it is if we can get reports of at least one
other person having this issue. I am fine with not doing this for 9.4.1

I agree that we should raise the priority of "notarising/codesigning
releases (resolving #17418)". My opinion is that it is not worth delaying
9.4.1 for this.

Have a great vacation.

Cheers
George






On Sun, Jul 24, 2022 at 11:33 AM Ben Gamari  wrote:

> George Colpitts  writes:
>
> > +Kazu Yamamoto 
> >
> > Hi Ben
> >
> > My 2 machines also have:
> >
> > $ spctl --status
> > assessments enabled
> >
> Hmm, interesting. Then I am truly perplexed.
>
> > Speculations:
> >
> >
> /usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib
> > is created after xattr -rc . was run so it doesn't have the necessary
> > attributes. Is it possible that ghc developers and/or the test machines
> > have this file on another of the paths in the error message and that is
> why
> > it works for them?
> >
> I'm not sure where this would be but at this point anything is possible.
> What happens
> if you try to install to do something like (in the extracted binary
> distribution),
>
> $ ./configure --prefix=`pwd`/tmp
> $ make install# this will fail
> $ xattr -rc .
> $ make install# perhaps this will finish successfully?
> # tmp/bin/ghc --version   # GHC should be usable
>
> > I hope I didn't offend you by asking if the fix had been tested; I assume
> > it had been but I thought it was important to rule that out.
> >
> Not to worry; it's a very reasonable question to ask given the
> circumstances.
>
> > More than happy to test. I really appreciate all the work you and others
> > have put into GHC !
> >
> Ultimately I think we may just need to bite the bullet and start
> properly notarising/codesigning releases (resolving #17418). At this point
> we have
> spent more time trying to avoid the notarisation requirement than
> it would likely take to satisfy it. Unfortunately, this will require
> that I find an Apple device somewhere which may take a few weeks.
>
> I'm afraid I am on holiday next week but I would quite grateful if we
> could arrange for a chat after I return such that we can debug this in
> realtime.
>
> Cheers,
>
> - Ben
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] GHC 9.4.1-rc1 is now available

[George Colpitts]

+ address that hopefully doesn't bounce for Moritz

On Sat, Jul 23, 2022 at 11:51 AM George Colpitts 
wrote:

> +Kazu Yamamoto 
>
> Hi Ben
>
> My 2 machines also have:
>
> $ spctl --status
> assessments enabled
>
> I've duplicated the issue on both of my machines. It would be good to know
> if anybody else is seeing it. Kazu, I know you have seen this in the past.
> Do you get the same error installing rc1?
> When I run sudo make install I get a popup that says:
>
> *“libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib” cannot be opened because
> the developer cannot be verified.*
>
> When I cancel out of that I get another popup with the same error. When I
> hit cancel on that the script ends with the output:
>
> # We finally replace the original file.
> mv
> '/usr/local/lib/ghc-9.4.0.20220721/lib/package.conf.d/process-1.6.14.0.conf.copy.copy'
> '/usr/local/lib/ghc-9.4.0.20220721/lib/package.conf.d/process-1.6.14.0.conf'
> '/usr/local/lib/ghc-9.4.0.20220721/bin/ghc-pkg' --global-package-db
> "/usr/local/lib/ghc-9.4.0.20220721/lib/package.conf.d" recache
> dyld[32239]: Library not loaded:
> '@rpath/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib'
>   Referenced from:
> '/usr/local/lib/ghc-9.4.0.20220721/bin/ghc-pkg-9.4.0.20220721'
>   Reason: tried:*
> '/usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib'
> (code signature in 
> '/usr/local/lib/ghc-9.4.0.20220721/lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib'
> not valid for use in process: library load disallowed by system policy),
> '$ORIGIN/../../../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib'
> (no such file),
> '/usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib'
> (code signature in 
> '/usr/local/lib/ghc-9.4.0.20220721/lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib'
> not valid for use in process: library load disallowed by system policy),*
> '$ORIGIN/../../../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib'
> (no such file),
> '/usr/local/lib/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' (no such
> file), '/usr/lib/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' (no such
> file)
> make: *** [update_package_db] Abort trap: 6
> gcolpitts@macMini-2018 ghc-9.4.0.20220721-x86_64-apple-darwin %
>
>  Hope this helps.
>
> Speculations:
>
> /usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib
> is created after xattr -rc . was run so it doesn't have the necessary
> attributes. Is it possible that ghc developers and/or the test machines
> have this file on another of the paths in the error message and that is why
> it works for them?
>
> I hope I didn't offend you by asking if the fix had been tested; I assume
> it had been but I thought it was important to rule that out.
>
> More than happy to test. I really appreciate all the work you and others
> have put into GHC !
>
> Cheers
> George
>
> On Sat, Jul 23, 2022 at 10:03 AM Ben Gamari  wrote:
>
>> George Colpitts  writes:
>>
>> > Hi Ben
>> >
>> > /ust/bin/xattr exists on my machine. Running "xattr -rc ." manually does
>> > not fix the bug as noted at the start of 21506. It was sufficient in the
>> > past but no longer fixes this error. As noted farther down in 21506
>> >
>> > the workaround given in #17418  no longer
>> works.
>> > It did not work in 9.2.2 either. The current workaround is similar to
>> what
>> > Kazu explained in
>> > https://twitter.com/kazu_yamamoto/status/1500643489985761282
>> >
>> > sudo xattr -rc .
>> >
>> > sudo spctl --global-disable
>> >
>> > ./configure
>> >
>> > sudo make install
>> >
>> > sudo spctl --global-enable
>> >
>> > It seems there are files created during sudo make install that have an
>> > issue as xattr -rc . was never run on them. Perhaps this is related to
>> > using Hadrian. Is it possible that the fix that was made was never
>> tested?
>> >
>> I tested the change both manually and via CI on the hardware that I have
>> access to; in both cases installing the binary distribution resulted in
>> a functional compiler. However, given how the effects of SIP are
>> essentially undocumented, it is very hard to know what variables may be
>> at play here. Running spctl --status on the machine on which I tested
>> claims:
>

Re: [ANNOUNCE] GHC 9.4.1-rc1 is now available

[George Colpitts]

+Kazu Yamamoto 

Hi Ben

My 2 machines also have:

$ spctl --status
assessments enabled

I've duplicated the issue on both of my machines. It would be good to know
if anybody else is seeing it. Kazu, I know you have seen this in the past.
Do you get the same error installing rc1?
When I run sudo make install I get a popup that says:

*“libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib” cannot be opened because
the developer cannot be verified.*

When I cancel out of that I get another popup with the same error. When I
hit cancel on that the script ends with the output:

# We finally replace the original file.
mv
'/usr/local/lib/ghc-9.4.0.20220721/lib/package.conf.d/process-1.6.14.0.conf.copy.copy'
'/usr/local/lib/ghc-9.4.0.20220721/lib/package.conf.d/process-1.6.14.0.conf'
'/usr/local/lib/ghc-9.4.0.20220721/bin/ghc-pkg' --global-package-db
"/usr/local/lib/ghc-9.4.0.20220721/lib/package.conf.d" recache
dyld[32239]: Library not loaded:
'@rpath/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib'
  Referenced from:
'/usr/local/lib/ghc-9.4.0.20220721/bin/ghc-pkg-9.4.0.20220721'
  Reason: tried:*
'/usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib'
(code signature in 
'/usr/local/lib/ghc-9.4.0.20220721/lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib'
not valid for use in process: library load disallowed by system policy),
'$ORIGIN/../../../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib'
(no such file),
'/usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib'
(code signature in 
'/usr/local/lib/ghc-9.4.0.20220721/lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib'
not valid for use in process: library load disallowed by system policy),*
'$ORIGIN/../../../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib'
(no such file),
'/usr/local/lib/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' (no such
file), '/usr/lib/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' (no such
file)
make: *** [update_package_db] Abort trap: 6
gcolpitts@macMini-2018 ghc-9.4.0.20220721-x86_64-apple-darwin %

 Hope this helps.

Speculations:

/usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib
is created after xattr -rc . was run so it doesn't have the necessary
attributes. Is it possible that ghc developers and/or the test machines
have this file on another of the paths in the error message and that is why
it works for them?

I hope I didn't offend you by asking if the fix had been tested; I assume
it had been but I thought it was important to rule that out.

More than happy to test. I really appreciate all the work you and others
have put into GHC !

Cheers
George

On Sat, Jul 23, 2022 at 10:03 AM Ben Gamari  wrote:

> George Colpitts  writes:
>
> > Hi Ben
> >
> > /ust/bin/xattr exists on my machine. Running "xattr -rc ." manually does
> > not fix the bug as noted at the start of 21506. It was sufficient in the
> > past but no longer fixes this error. As noted farther down in 21506
> >
> > the workaround given in #17418  no longer works.
> > It did not work in 9.2.2 either. The current workaround is similar to
> what
> > Kazu explained in
> > https://twitter.com/kazu_yamamoto/status/1500643489985761282
> >
> > sudo xattr -rc .
> >
> > sudo spctl --global-disable
> >
> > ./configure
> >
> > sudo make install
> >
> > sudo spctl --global-enable
> >
> > It seems there are files created during sudo make install that have an
> > issue as xattr -rc . was never run on them. Perhaps this is related to
> > using Hadrian. Is it possible that the fix that was made was never
> tested?
> >
> I tested the change both manually and via CI on the hardware that I have
> access to; in both cases installing the binary distribution resulted in
> a functional compiler. However, given how the effects of SIP are
> essentially undocumented, it is very hard to know what variables may be
> at play here. Running spctl --status on the machine on which I tested
> claims:
>
> > spctl --status
> objc[48908]: Class SPExecutionPolicy is implemented in both
> /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy
> and /usr/sbin/spctl. One of the two will be used. Which one is undefined.
> objc[48908]: Class AppWrapper is implemented in both
> /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy
> and /usr/sbin/spctl. One of the two will be used. Which one is undefined.
> objc[48908]: Class AppWrapperPolicyResult is implemented in both
> /System/Library/PrivateF

Re: [ANNOUNCE] GHC 9.4.1-rc1 is now available

[George Colpitts]

Hi Ben

/ust/bin/xattr exists on my machine. Running "xattr -rc ." manually does
not fix the bug as noted at the start of 21506. It was sufficient in the
past but no longer fixes this error. As noted farther down in 21506

the workaround given in #17418  no longer works.
It did not work in 9.2.2 either. The current workaround is similar to what
Kazu explained in
https://twitter.com/kazu_yamamoto/status/1500643489985761282

sudo xattr -rc .

sudo spctl --global-disable

./configure

sudo make install

sudo spctl --global-enable

It seems there are files created during sudo make install that have an
issue as xattr -rc . was never run on them. Perhaps this is related to
using Hadrian. Is it possible that the fix that was made was never tested?

Thanks
George


On Sat, Jul 23, 2022 at 12:30 AM Ben Gamari  wrote:

> George Colpitts  writes:
>
> > Hi Ben,
> >
> > I expected https://gitlab.haskell.org/ghc/ghc/-/issues/21506
> (ghc-9.4.1-alpha1
> > does not install on macos: ghc-pkg-9.4.0-20220501 cannot be opened
> because
> > the developer cannot be verified) to be fixed in rc1 but it is not. Are
> my
> > expectations wrong? What is the ETA for fixing it?
> >
> Thanks for letting us know, George. The fix that we have [1] is present
> in 9.4.1-rc1. If that commit doesn't resolve the issue then there is
> something that we don't understand. Does `/usr/bin/xattr` exist? Running
> `xattr -rc` manually on the binary distribution allow you to run the
> compiler?
>
> Cheers,
>
> - Ben
>
>
> [1]
> https://gitlab.haskell.org/ghc/ghc/-/commit/641972d65b476aac11424bde6c3bcfda1c65aef5
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] GHC 9.4.1-rc1 is now available

[George Colpitts]

Hi Ben,

I expected https://gitlab.haskell.org/ghc/ghc/-/issues/21506 (ghc-9.4.1-alpha1
does not install on macos: ghc-pkg-9.4.0-20220501 cannot be opened because
the developer cannot be verified) to be fixed in rc1 but it is not. Are my
expectations wrong? What is the ETA for fixing it?

Thanks
George


On Fri, Jul 22, 2022 at 10:05 AM Ben Gamari  wrote:

>
> The GHC developers are happy to announce the availability of the first
> (and likely last) release candidate of GHC 9.4.1. Binary distributions,
> source
> distributions, and documentation are available at [downloads.haskell.org].
>
> This major release will include:
>
>  - A new profiling mode, `-fprof-late`, which adds automatic cost-center
>annotations to all top-level functions *after* Core optimisation has
>run. This provides informative profiles while interfering
>significantly less with GHC's aggressive optimisations, making it
>easier to understand the performance of programs which depend upon
>simplification..
>
>  - A variety of plugin improvements including the introduction of a new
>plugin type, *defaulting plugins*, and the ability for typechecking
>plugins to rewrite type-families.
>
>  - An improved constructed product result analysis, allowing unboxing of
>nested structures, and a new boxity analysis, leading to less reboxing.
>
>  - Introduction of a tag-check elision optimisation, bringing
>significant performance improvements in strict programs.
>
>  - Generalisation of a variety of primitive types to be levity
>polymorphic. Consequently, the `ArrayArray#` type can at long last be
>retired, replaced by standard `Array#`.
>
>  - Introduction of the `\cases` syntax from [GHC proposal 0302]
>
>  - A complete overhaul of GHC's Windows support. This includes a
>migration to a fully Clang-based C toolchain, a deep refactoring of
>the linker, and many fixes in WinIO.
>
>  - Support for multiple home packages, significantly improving support
>in IDEs and other tools for multi-package projects.
>
>  - A refactoring of GHC's error message infrastructure, allowing GHC to
>provide diagnostic information to downstream consumers as structured
>data, greatly easing IDE support.
>
>  - Significant compile-time improvements to runtime and memory consumption.
>
>  - On overhaul of our packaging infrastructure, allowing full
>traceability of release artifacts and more reliable binary
>distributions.
>
>  - Reintroduction of deep subsumption (which was previously dropped with
> the
>*simplified subsumption* change) as a language extension.
>
>  - ... and much more. See the [release notes] for a full accounting.
>
> Note that, as 9.4.1 is the first release for which the released artifacts
> will
> all be generated by our Hadrian build system, it is possible that there
> will be
> packaging issues. If you enounter trouble while using a binary
> distribution,
> please open a [ticket]. Likewise, if you are a downstream packager, do
> consider
> migrating to [Hadrian] to run your build; the Hadrian build system can be
> built
> using `cabal-install`, `stack`, or the in-tree [bootstrap script]. We will
> be
> publishing a blog post describing the migration process to Hadrian in the
> coming weeks.
>
> We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk
> stake pool, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell
> Foundation, and other anonymous contributors whose on-going financial
> and in-kind support has facilitated GHC maintenance and release
> management over the years. Finally, this release would not have been
> possible without the hundreds of open-source contributors whose work
> comprise this release.
>
> As always, do give this release a try and open a [ticket] if you see
> anything amiss.
>
> Happy testing,
>
> - Ben
>
> [downloads.haskell.org]: https://downloads.haskell.org/ghc/9.4.1-rc1/
> [GHC proposal 0302]:
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-cases.rst
> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
> [bootstrap script]:
> https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian/bootstrap/README.md
> [Hadrian]:
> https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian
> [release notes]:
> https://downloads.haskell.org/~ghc/9.4.1-rc1/docs/users_guide/9.4.1-notes.html
>
> ___
> ghc-devs mailing list
> ghc-d...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [Haskell] [ANNOUNCE] GHC 9.2.3 released

[George Colpitts]

Hi

https://gitlab.haskell.org/ghc/ghc/-/issues/21506, ghc-9.4.1-alpha1 does
not install on macos, exists on 9.2.3 also. The workaround given in 21506
works. Do you want a ticket for this?

Thanks
George


On Fri, May 27, 2022 at 4:41 PM Zubin Duggal  wrote:

>
> The GHC developers are very happy to at announce the availability of GHC
> 9.2.3. Binary distributions, source distributions, and documentation are
> available at [`downloads.haskell.org`](
> https://downloads.haskell.org/ghc/9.2.3).
>
> Download Page: https://www.haskell.org/ghc/download_ghc_9_2_3.html
> Blog Post:
> https://www.haskell.org/ghc/blog/20220527-ghc-9.2.3-released.html
>
> This release includes many bug-fixes and other improvements to 9.2.2
> including:
>
>   * A fix to a critical linking bug on Windows causing the 9.2.2 release
>   to be unusable (#21196).
>
>   * Numerous bug fixes for regressions and other issues in the
>   typechecker (#2147, #21515, #20582, #20820, #21130, #21479).
>
>   * Correctness bugs in the code generator and compiler backends (#21396,
>   #20959, #21465).
>
>   * Packaging fixes on many platforms (#20760, #21487, #21402).
>
>   * Many others. See the [release notes][] for a full list.
>
> As some of the fixed issues do affect correctness users are encouraged
> to upgrade promptly.
>
> We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake
> pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous
> contributors whose on-going financial and in-kind support has
> facilitated GHC maintenance and release management over the years.
> Finally, this release would not have been possible without the hundreds
> of open-source contributors whose work comprise this release.
>
> As always, do give this release a try and open a [ticket] if you see
> anything amiss.
>
> Happy compiling,
>
> - Zubin
>
>
> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
> [release notes]:
> https://downloads.haskell.org/ghc/9.2.3/docs/html/users_guide/9.2.3-notes.html
> ___
> ghc-devs mailing list
> ghc-d...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: macos install issue: ghc-pkg-9.2.2 cannot be opened because the developer cannot be verified

[George Colpitts]

It's not fixed for me so I filed
https://gitlab.haskell.org/ghc/ghc/-/issues/21506

On Mon, May 2, 2022 at 7:59 AM George Colpitts 
wrote:

> Hi
>
> Did this get fixed? Is it fixed in 9.4.1-alpha1?
>
> Thanks
> George
>
> On Mon, Mar 7, 2022 at 2:27 AM Kazu Yamamoto  wrote:
>
>> Hi George,
>>
>> FYI:
>>
>> https://twitter.com/kazu_yamamoto/status/1500643489985761282
>>
>> --Kazu
>>
>> > Thanks Ben
>> >
>> > When I do an install on macos Monterey 12.2.1 (Intel) I get
>> >
>> > ghc-pkg-9.2.2 cannot be opened because the developer cannot be verified
>> >
>> >
>> > On Sun, Mar 6, 2022 at 7:02 PM Ben Gamari  wrote:
>> >
>> >>
>> >> The GHC developers are very happy to at announce the availability of
>> GHC
>> >>
>> >> 9.2.2. Binary distributions, source distributions, and documentation
>> are
>> >>
>> >> available at downloads.haskell.org:
>> >>
>> >>https://downloads.haskell.org/ghc/9.2.2
>> >>
>> >> This release includes many bug-fixes and other improvements to 9.2.1
>> >> including:
>> >>
>> >>  * A number of bug-fixes in the new AArch64 native code generator
>> >>
>> >>  * Fixes ensuring that the `indexWord8ArrayAs*#` family of primops is
>> >> handled
>> >>correctly on platforms lacking support for unaligned memory accesses
>> >>(#21015, #20987).
>> >>
>> >>  * Improvements to the compatibility story in GHC's migration to the
>> >>XDG Base Directory Specification (#20684, #20669, #20660)
>> >>
>> >>  * Restored compatibility with Windows 7
>> >>
>> >>  * A new `-fcompact-unwind` flag, improving compatibility with C++
>> >> libraries on
>> >>Apple Darwin (#11829)
>> >>
>> >>  * Introduction of a new flag, `-fcheck-prim-bounds`, enabling runtime
>> >> bounds
>> >>checking of array primops (#20769)
>> >>
>> >>  * Unboxing of unlifted types (#20663)
>> >>
>> >>  * Numerous improvements in compiler performance.
>> >>
>> >>  * Many, many others. See the [release notes] for a full list.
>> >>
>> >> As some of the fixed issues do affect correctness users are encouraged
>> to
>> >>
>> >> upgrade promptly.
>> >>
>> >> Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake
>> >> pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous
>> >> contributors whose on-going financial and in-kind support has
>> >> facilitated GHC maintenance and release management over the years.
>> >> Moreover, this release would not have been possible without the
>> hundreds
>> >>
>> >> of open-source contributors whose work comprise this release.
>> >>
>> >> As always, do open a [ticket][] if you see anything amiss.
>> >>
>> >> Happy compiling,
>> >>
>> >> - Ben
>> >>
>> >>
>> >> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
>> >> [release notes]:
>> >>
>> https://downloads.haskell.org/ghc/9.2.2/docs/html/users_guide/9.2.2-notes.html
>> >>
>> >> ___
>> >> Glasgow-haskell-users mailing list
>> >> Glasgow-haskell-users@haskell.org
>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>> >>
>>
>>
>>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: macos install issue: ghc-pkg-9.2.2 cannot be opened because the developer cannot be verified

[George Colpitts]

Hi

Did this get fixed? Is it fixed in 9.4.1-alpha1?

Thanks
George

On Mon, Mar 7, 2022 at 2:27 AM Kazu Yamamoto  wrote:

> Hi George,
>
> FYI:
>
> https://twitter.com/kazu_yamamoto/status/1500643489985761282
>
> --Kazu
>
> > Thanks Ben
> >
> > When I do an install on macos Monterey 12.2.1 (Intel) I get
> >
> > ghc-pkg-9.2.2 cannot be opened because the developer cannot be verified
> >
> >
> > On Sun, Mar 6, 2022 at 7:02 PM Ben Gamari  wrote:
> >
> >>
> >> The GHC developers are very happy to at announce the availability of GHC
> >>
> >> 9.2.2. Binary distributions, source distributions, and documentation are
> >>
> >> available at downloads.haskell.org:
> >>
> >>https://downloads.haskell.org/ghc/9.2.2
> >>
> >> This release includes many bug-fixes and other improvements to 9.2.1
> >> including:
> >>
> >>  * A number of bug-fixes in the new AArch64 native code generator
> >>
> >>  * Fixes ensuring that the `indexWord8ArrayAs*#` family of primops is
> >> handled
> >>correctly on platforms lacking support for unaligned memory accesses
> >>(#21015, #20987).
> >>
> >>  * Improvements to the compatibility story in GHC's migration to the
> >>XDG Base Directory Specification (#20684, #20669, #20660)
> >>
> >>  * Restored compatibility with Windows 7
> >>
> >>  * A new `-fcompact-unwind` flag, improving compatibility with C++
> >> libraries on
> >>Apple Darwin (#11829)
> >>
> >>  * Introduction of a new flag, `-fcheck-prim-bounds`, enabling runtime
> >> bounds
> >>checking of array primops (#20769)
> >>
> >>  * Unboxing of unlifted types (#20663)
> >>
> >>  * Numerous improvements in compiler performance.
> >>
> >>  * Many, many others. See the [release notes] for a full list.
> >>
> >> As some of the fixed issues do affect correctness users are encouraged
> to
> >>
> >> upgrade promptly.
> >>
> >> Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake
> >> pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous
> >> contributors whose on-going financial and in-kind support has
> >> facilitated GHC maintenance and release management over the years.
> >> Moreover, this release would not have been possible without the hundreds
> >>
> >> of open-source contributors whose work comprise this release.
> >>
> >> As always, do open a [ticket][] if you see anything amiss.
> >>
> >> Happy compiling,
> >>
> >> - Ben
> >>
> >>
> >> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
> >> [release notes]:
> >>
> https://downloads.haskell.org/ghc/9.2.2/docs/html/users_guide/9.2.2-notes.html
> >>
> >> ___
> >> Glasgow-haskell-users mailing list
> >> Glasgow-haskell-users@haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> >>
>
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] GHC 9.2.2 is not available

[George Colpitts]

Thanks Ben

When I do an install on macos Monterey 12.2.1 (Intel) I get

ghc-pkg-9.2.2 cannot be opened because the developer cannot be verified


On Sun, Mar 6, 2022 at 7:02 PM Ben Gamari  wrote:

>
> The GHC developers are very happy to at announce the availability of GHC
>
> 9.2.2. Binary distributions, source distributions, and documentation are
>
> available at downloads.haskell.org:
>
>https://downloads.haskell.org/ghc/9.2.2
>
> This release includes many bug-fixes and other improvements to 9.2.1
> including:
>
>  * A number of bug-fixes in the new AArch64 native code generator
>
>  * Fixes ensuring that the `indexWord8ArrayAs*#` family of primops is
> handled
>correctly on platforms lacking support for unaligned memory accesses
>(#21015, #20987).
>
>  * Improvements to the compatibility story in GHC's migration to the
>XDG Base Directory Specification (#20684, #20669, #20660)
>
>  * Restored compatibility with Windows 7
>
>  * A new `-fcompact-unwind` flag, improving compatibility with C++
> libraries on
>Apple Darwin (#11829)
>
>  * Introduction of a new flag, `-fcheck-prim-bounds`, enabling runtime
> bounds
>checking of array primops (#20769)
>
>  * Unboxing of unlifted types (#20663)
>
>  * Numerous improvements in compiler performance.
>
>  * Many, many others. See the [release notes] for a full list.
>
> As some of the fixed issues do affect correctness users are encouraged to
>
> upgrade promptly.
>
> Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake
> pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous
> contributors whose on-going financial and in-kind support has
> facilitated GHC maintenance and release management over the years.
> Moreover, this release would not have been possible without the hundreds
>
> of open-source contributors whose work comprise this release.
>
> As always, do open a [ticket][] if you see anything amiss.
>
> Happy compiling,
>
> - Ben
>
>
> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
> [release notes]:
> https://downloads.haskell.org/ghc/9.2.2/docs/html/users_guide/9.2.2-notes.html
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: regression in ghc / cabal integration in 9.2.1

[George Colpitts]

Thanks for the quick response Mikolaj. Sorry for the confusion, with cabal
install I did use --lib but accidentally omitted that in my original email.
In 9.0.1 this results in a successful compilation but in 9.2.1 it does not
thus I believe this is a regression.

Here's the output I got in 9.2.1:

bash-3.2$ cabal install vector --lib
Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.4.0.0 supports
'ghc' version < 9.1): /usr/local/bin/ghc is version 9.2.1
Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.4.0.0 supports
'ghc' version < 9.1): /usr/local/bin/ghc is version 9.2.1
Resolving dependencies...
Up to date
bash-3.2$ ghc buggc.hs
[1 of 1] Compiling Main ( buggc.hs, buggc.o )


buggc.hs:2:1: error:
Could not find module ‘Data.Vector’
Perhaps you meant Data.Functor (from base-4.16.0.0)
Use -v (or `:set -v` in ghci) to see a list of the files searched for.
  |
2 | import Data.Vector


However I did figure out a workaround: cabal v1-install.

As far as I can tell cabal (v2-) install breaks ghc-pkg and compilation.
With cabal (v2-) install the workaround for ghc-pkg is to add the option "-f
$HOME/.cabal/store/ghc-9.2.1/package.db" to the end of the command "ghc-pkg
list". For compilation the workaround is to add "-package-db
$HOME/.cabal/store/ghc-9.2.1/package.db" to the ghc-pkg. I don't understand
why it was necessary for  cabal v2-install to be incompatible with cabal
v1-install. Is there a link to any documentation and justification for
these incompatible changes?

Thanks again,
George



On Sat, Oct 30, 2021 at 3:38 PM Mikolaj Konarski 
wrote:

> Hi George,
>
> Since many versions of cabal, `install` only installs executables, not
> libraries, so if that worked for you, you must have had an old version
> of cabal.
>
> Please see https://github.com/haskell/cabal/issues/6481 for some
> context and to help you find a new workflow that works for you
> (ideally, a standard one).
>
> Kind regards,
> Mikolaj
>
> On Sat, Oct 30, 2021 at 5:40 PM George Colpitts
>  wrote:
> >
> > Thanks Ben!
> >
> > There seems to be a regression in ghc / cabal integration in 9.2.1.
> >
> > In 9.2.1 if I do
> >
> > cabal install vector
> >
> > Compilation of a file containing
> >
> >
> > import Data.Vector
> >
> >
> > main = undefined
> >
> >
> > fails with
> >
> >  Could not find module ‘Data.Vector’
> > Perhaps you meant Data.Functor (from base-4.16.0.0)
> > Use -v (or `:set -v` in ghci) to see a list of the files searched
> for.
> >   |
> > 2 | import Data.Vector
> >   | ^^
> >
> > The preceding works on ghc 9.0.1
> >
> > Should I file a bug against Cabal?
> >
> > Thanks
> > George
> >
> > On Fri, Oct 29, 2021 at 12:54 PM Ben Gamari  wrote:
> >>
> >> Hi all,
> >>
> >> The GHC developers are very happy to at long last announce the
> >> availability of GHC 9.2.1. Binary distributions, source distributions,
> >> and documentation are available at
> >>
> >> https://downloads.haskell.org/ghc/9.2.1
> >>
> >> GHC 9.2 brings a number of exciting features including:
> >>
> >>  * A native code generation backend for AArch64, significantly speeding
> >>compilation time on ARM platforms like the Apple M1.
> >>
> >>  * Many changes in the area of records, including the new
> >>`RecordDotSyntax` and `NoFieldSelectors` language extensions, as well
> >>as Support for `DuplicateRecordFields` with `PatternSynonyms`.
> >>
> >>  * Introduction of the new `GHC2021` language extension set, giving
> >>users convenient access to a larger set of language extensions which
> >>have been long considered stable.
> >>
> >>  * Merging of `ghc-exactprint` into the GHC tree, providing
> >>infrastructure for source-to-source program rewriting out-of-the-box.
> >>
> >>  * Introduction of a `BoxedRep` `RuntimeRep`, allowing for polymorphism
> >>over levity of boxed objects (#17526)
> >>
> >>  * Implementation of the `UnliftedDataTypes` extension, allowing users
> >>to define types which do not admit lazy evaluation ([proposal])
> >>
> >>  * The new [`-hi` profiling] mechanism which provides significantly
> >>improved insight into thunk leaks.
> >>
> >>  * Support for the `ghc-debug` out-of-process heap inspection library
> >>[ghc-debug]
> >>
> >>  * Significant improvements in the bytecode interpreter, allowing 

regression in ghc / cabal integration in 9.2.1

[George Colpitts]

Thanks Ben!

There seems to be a regression in ghc / cabal integration in 9.2.1.

In 9.2.1 if I do

cabal install vector

Compilation of a file containing


import Data.Vector


main = undefined


fails with

 Could not find module ‘Data.Vector’
Perhaps you meant Data.Functor (from base-4.16.0.0)
Use -v (or `:set -v` in ghci) to see a list of the files searched for.
  |
2 | import Data.Vector
  | ^^

The preceding works on ghc 9.0.1

Should I file a bug against Cabal?

Thanks
George

On Fri, Oct 29, 2021 at 12:54 PM Ben Gamari  wrote:

> Hi all,
>
> The GHC developers are very happy to at long last announce the
> availability of GHC 9.2.1. Binary distributions, source distributions,
> and documentation are available at
>
> https://downloads.haskell.org/ghc/9.2.1
>
> GHC 9.2 brings a number of exciting features including:
>
>  * A native code generation backend for AArch64, significantly speeding
>compilation time on ARM platforms like the Apple M1.
>
>  * Many changes in the area of records, including the new
>`RecordDotSyntax` and `NoFieldSelectors` language extensions, as well
>as Support for `DuplicateRecordFields` with `PatternSynonyms`.
>
>  * Introduction of the new `GHC2021` language extension set, giving
>users convenient access to a larger set of language extensions which
>have been long considered stable.
>
>  * Merging of `ghc-exactprint` into the GHC tree, providing
>infrastructure for source-to-source program rewriting out-of-the-box.
>
>  * Introduction of a `BoxedRep` `RuntimeRep`, allowing for polymorphism
>over levity of boxed objects (#17526)
>
>  * Implementation of the `UnliftedDataTypes` extension, allowing users
>to define types which do not admit lazy evaluation ([proposal])
>
>  * The new [`-hi` profiling] mechanism which provides significantly
>improved insight into thunk leaks.
>
>  * Support for the `ghc-debug` out-of-process heap inspection library
>[ghc-debug]
>
>  * Significant improvements in the bytecode interpreter, allowing more
>programs to be efficently run in GHCi and Template Haskell splices.
>
>  * Support for profiling of pinned objects with the cost-centre profiler
>(#7275)
>
>  * Faster compilation and a smaller memory footprint
>
>  * Introduction of Haddock documentation support in TemplateHaskell (#5467)
>
> Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake
> pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous
> contributors whose on-going financial and in-kind support has
> facilitated GHC maintenance and release management over the years.
> Moreover, this release would not have been possible without the hundreds
> of open-source contributors whose work comprise this release.
>
> As always, do open a [ticket] if you see anything amiss.
>
> Happy testing,
>
> - Ben
>
>
> [apple-m1]: https://www.haskell.org/ghc/blog/20210309-apple-m1-story.html
> [proposal]:
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-unlifted-datatypes.rst
> [-hi
> 
> profiling]:
> https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/
> [ghc-debug
> ]:
> http://ghc.gitlab.haskell.org/ghc-debug/
> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
> ___
> ghc-devs mailing list
> ghc-d...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] GHC 9.2.1 now available

[George Colpitts]

Great news!

Install works on mac os if you do

xattr -rc .

before doing

make install

The mail didn't mention that nor is it mentioned in the INSTALL file.

I thought this had been fixed. I guess I'm mistaken or this is only an
issue for me.

Thanks again for getting this out! There's a lot of great stuff in the
release.

Cheers
George



On Fri, Oct 29, 2021 at 12:54 PM Ben Gamari  wrote:

> Hi all,
>
> The GHC developers are very happy to at long last announce the
> availability of GHC 9.2.1. Binary distributions, source distributions,
> and documentation are available at
>
> https://downloads.haskell.org/ghc/9.2.1
>
> GHC 9.2 brings a number of exciting features including:
>
>  * A native code generation backend for AArch64, significantly speeding
>compilation time on ARM platforms like the Apple M1.
>
>  * Many changes in the area of records, including the new
>`RecordDotSyntax` and `NoFieldSelectors` language extensions, as well
>as Support for `DuplicateRecordFields` with `PatternSynonyms`.
>
>  * Introduction of the new `GHC2021` language extension set, giving
>users convenient access to a larger set of language extensions which
>have been long considered stable.
>
>  * Merging of `ghc-exactprint` into the GHC tree, providing
>infrastructure for source-to-source program rewriting out-of-the-box.
>
>  * Introduction of a `BoxedRep` `RuntimeRep`, allowing for polymorphism
>over levity of boxed objects (#17526)
>
>  * Implementation of the `UnliftedDataTypes` extension, allowing users
>to define types which do not admit lazy evaluation ([proposal])
>
>  * The new [`-hi` profiling] mechanism which provides significantly
>improved insight into thunk leaks.
>
>  * Support for the `ghc-debug` out-of-process heap inspection library
>[ghc-debug]
>
>  * Significant improvements in the bytecode interpreter, allowing more
>programs to be efficently run in GHCi and Template Haskell splices.
>
>  * Support for profiling of pinned objects with the cost-centre profiler
>(#7275)
>
>  * Faster compilation and a smaller memory footprint
>
>  * Introduction of Haddock documentation support in TemplateHaskell (#5467)
>
> Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake
> pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous
> contributors whose on-going financial and in-kind support has
> facilitated GHC maintenance and release management over the years.
> Moreover, this release would not have been possible without the hundreds
> of open-source contributors whose work comprise this release.
>
> As always, do open a [ticket] if you see anything amiss.
>
> Happy testing,
>
> - Ben
>
>
> [apple-m1]: https://www.haskell.org/ghc/blog/20210309-apple-m1-story.html
> [proposal]:
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-unlifted-datatypes.rst
> [-hi
> 
> profiling]:
> https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/
> [ghc-debug
> ]:
> http://ghc.gitlab.haskell.org/ghc-debug/
> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
> ___
> ghc-devs mailing list
> ghc-d...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Glasgow-haskell-users Digest, Vol 212, Issue 5

[George Colpitts]

Try doing

  cabal update

and then compiling



On Mon, Oct 11, 2021 at 5:12 PM David Duke  wrote:

> Thanks Dominic George for that. I had env var set. iconv --version gives
> GNU libiconv 1.16
> I created a clean shell so env vars set other than PATH and installed
> using the tarball on the link George  provided.
> It appeared to install okay . However trying to compile throws up:
>
> cannot satisfy -package-id ghc-9.0.1
> compiling with -v:
>
>
> Loaded package environment from
> /Users/scsdjd/.ghc/x86_64-darwin-9.0.1/environments/default
>
> Glasgow Haskell Compiler, Version 9.0.1, stage 2 booted by GHC version
> 8.8.4
>
> *** initializing unit database:
>
> There is no package.cache in /usr/local/lib/ghc-9.0.1/package.conf.d,
> checking if the database is empty
>
> There are no .conf files in /usr/local/lib/ghc-9.0.1/package.conf.d,
> treating package database as empty
>
> Using binary package database:
> /Users/scsdjd/.cabal/store/ghc-9.0.1/package.db/package.cache
>
> package flags [-package-id ghc-9.0.1{unit ghc-9.0.1 True ([])},
>
> regards,
> David
>
> On Mon, Oct 11, 2021 at 3:52 PM George Colpitts 
> wrote:
>
>> Hi David
>>
>> I've also used ghc for years on Mac OS and have also never seen this
>> problem. I don't use nix. Currently I am on ghc 9.0.1. and Mac OS 11.6. I
>> installed from
>>
>> https://downloads.haskell.org/ghc/9.0.1/
>>
>> More specifically ghc-9.0.1-x86_64-apple-darwin.tar.xz
>> <https://downloads.haskell.org/ghc/9.0.1/ghc-9.0.1-x86_64-apple-darwin.tar.xz>
>>
>>
>> Are any of the following env variables defined on your system?
>>
>>LD_LIBRARY_PATH, DYLD_LIBRARY_PATH, and DYLD_FALLBACK_LIBRARY_PATH
>>
>> None are defined on my system which I think is normal.
>>
>> When you type
>>
>>   iconv --version
>>
>> What output do you get? I get
>>
>>  iconv --version
>> iconv (GNU libiconv 1.11)
>> Copyright (C) 2000-2006 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>> PURPOSE.
>> Written by Bruno Haible.
>>
>>
>> Not sure if my questions will help but I think there is something unusual
>> about your system configuration.
>>
>> Cheers
>> George
>>
>>
>>
>> On Mon, Oct 11, 2021 at 9:38 AM Dominic Steinitz 
>> wrote:
>>
>>> Hi David
>>>
>>> I am a long time user of ghc on OSX. I have seen that problem but never
>>> on native OSX only when using nix (and then I added it explicitly).
>>>
>>> Two things spring to mind:
>>>
>>>1. Add it explicitly on the compile command `-liconv`
>>>2. Use nix and then you can control the build environment in a
>>>totally controllable and reproducible manner. This is actually easier 
>>> than
>>>it sounds: `curl https://nixos.org/nix/install | sh` and `nix-env -I
>>>ghc`. If you get the same error with that then we can try adding `iconv`
>>>explicitly.
>>>
>>>  Dominic Steinitz
>>> domi...@steinitz.org
>>> http://idontgetoutmuch.org
>>> Twitter: @idontgetoutmuch
>>>
>>>
>>> I have a conundrum on which advice would be appreciate. Does
>>> anyone know how to successfully install ghc on OSX
>>> I've tried various binary instalation routes:
>>> macports, brew, direct binary downloads from haskel.org
>>> All have the same result. when I try to compile a basic hello world
>>> program
>>> I get
>>>
>>> Undefined symbols for architecture x86_64:
>>>  "_iconv", referenced from:
>>>
>>>
>>> I've triedgiong  through ghcup
>>>
>>> 8.8.4
>>> 8.6.5.
>>> 8.10.2
>>> 8.10.7
>>> 9.0.1
>>>
>>> all have the same problem.
>>> I'd be happy to build from source. Small problem: what Haskell compiler
>>> do
>>> I use?
>>>
>>> Any advice on installs that works along with any changes to paths to
>>> avoid
>>> the iconv problems would be appreciated as currently my Haskell-related
>>> activities have come to a grinding halt. Switchig to a different OS would
>>> be nice but its not a
>>> feasible option a at present.Writing a compiler is starting to look
>>> attractive..
>>>
>>> thanks
>>> David
>>>
>>> --
>>> Davi

Re: Glasgow-haskell-users Digest, Vol 212, Issue 5

[George Colpitts]

Hi David

I've also used ghc for years on Mac OS and have also never seen this
problem. I don't use nix. Currently I am on ghc 9.0.1. and Mac OS 11.6. I
installed from

https://downloads.haskell.org/ghc/9.0.1/

More specifically ghc-9.0.1-x86_64-apple-darwin.tar.xz



Are any of the following env variables defined on your system?

   LD_LIBRARY_PATH, DYLD_LIBRARY_PATH, and DYLD_FALLBACK_LIBRARY_PATH

None are defined on my system which I think is normal.

When you type

  iconv --version

What output do you get? I get

 iconv --version
iconv (GNU libiconv 1.11)
Copyright (C) 2000-2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Bruno Haible.


Not sure if my questions will help but I think there is something unusual
about your system configuration.

Cheers
George



On Mon, Oct 11, 2021 at 9:38 AM Dominic Steinitz 
wrote:

> Hi David
>
> I am a long time user of ghc on OSX. I have seen that problem but never on
> native OSX only when using nix (and then I added it explicitly).
>
> Two things spring to mind:
>
>1. Add it explicitly on the compile command `-liconv`
>2. Use nix and then you can control the build environment in a totally
>controllable and reproducible manner. This is actually easier than it
>sounds: `curl https://nixos.org/nix/install | sh` and `nix-env -I
>ghc`. If you get the same error with that then we can try adding `iconv`
>explicitly.
>
>  Dominic Steinitz
> domi...@steinitz.org
> http://idontgetoutmuch.org
> Twitter: @idontgetoutmuch
>
>
> I have a conundrum on which advice would be appreciate. Does
> anyone know how to successfully install ghc on OSX
> I've tried various binary instalation routes:
> macports, brew, direct binary downloads from haskel.org
> All have the same result. when I try to compile a basic hello world program
> I get
>
> Undefined symbols for architecture x86_64:
>  "_iconv", referenced from:
>
>
> I've triedgiong  through ghcup
>
> 8.8.4
> 8.6.5.
> 8.10.2
> 8.10.7
> 9.0.1
>
> all have the same problem.
> I'd be happy to build from source. Small problem: what Haskell compiler do
> I use?
>
> Any advice on installs that works along with any changes to paths to avoid
> the iconv problems would be appreciated as currently my Haskell-related
> activities have come to a grinding halt. Switchig to a different OS would
> be nice but its not a
> feasible option a at present.Writing a compiler is starting to look
> attractive..
>
> thanks
> David
>
> --
> David Duke
> Emeritus Professor of Computer Science
> School of Computing University of Leeds UK
> E:duke.j.da...@gmail.com
> W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke
>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] Glasgow Haskell Compiler 9.0.1-alpha1 released

[George Colpitts]

Hi Ben,

What are the current plans / schedule for 9.0.1?

Thanks
George


On Mon, Sep 28, 2020 at 4:14 PM Ben Gamari  wrote:

> Hello all,
>
> The GHC team is very pleased to announce the availability of the first
> alpha release in the GHC 9.0 series. Source and binary distributions are
> available at the usual place:
>
> https://downloads.haskell.org/ghc/9.0.1-alpha1/
>
> This first alpha comes quite a bit later than expected. However, we have
> done a significant amount of testing on this pre-release and therefore
> hope to be able to move forward quickly with a release candidate next
> week and with a final release in mid-October.
>
> GHC 9.0.1 will bring a number of new features:
>
>  * A first cut of the new LinearTypes language extension [1], allowing
>use of linear function syntax and linear record fields.
>
>  * A new bignum library (ghc-bignum), allowing GHC to be more easily
>used with integer libraries other than GMP.
>
>  * Improvements in code generation, resulting in considerable
>performance improvements in some programs.
>
>  * Improvements in pattern-match checking, allowing more precise
>detection of redundant cases and reduced compilation time.
>
>  * Implementation of the "simplified subsumption" proposal [2]
>simplifying the type system and paving the way for QuickLook
>impredicativity in GHC 9.2.
>
>  * Implementation of the QualifiedDo extension [3], allowing more
>convenient overloading of `do` syntax.
>
>  * Improvements in compilation time.
>
> And many more. See the release notes [4] for a full accounting of the
> changes in this release.
>
> Do note that there are a few things that we expect will change before
> the final release:
>
>  * We expect to sort out a notarization workflow for Apple Darwin,
>allowing our binary distributions to be used on macOS Catalina
>without hassle.
>
>Until this has been sorted out Catalina users can exempt the
>current macOS binary distribution from the notarization requirement
>themselves by running `xattr -cr .` on the unpacked tree before
>running `make install`.
>
>  * We will likely transition the Alpine binary distribution to be fully
>statically-linked, providing a convenient, distribution-independent
>packaging option for Linux users.
>
>  * We will be merging a robust solution for #17760 which will introduce
>a new primitive, `keepAlive#`, to the `base` library, subsuming
>most uses of `touch#`.
>
> As always, do test this release and open tickets for whatever issues you
> encounter. To help with this, we will be publishing a blog post
> describing use of our new `head.hackage` infrastructure to ease testing
> of larger projects with Hackage dependencies later this week.
>
> Cheers,
>
> - Ben
>
>
> [1]
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0111-linear-types.rst
> [2]
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst
> [3]
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0216-qualified-do.rst
> [4]
> https://downloads.haskell.org/ghc/9.0.1-alpha1/docs/html/users_guide/9.0.1-notes.html
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] Glasgow Haskell Compiler 8.10.1-rc1 released

[George Colpitts]

Thanks Ben, installed fine on my Mac running 10.14.6.

For the release notes I suggest we document
https://gitlab.haskell.org/ghc/ghc/issues/17341 which is associated with
https://github.com/haskell/cabal/issues/6262 and
https://github.com/haskell/cabal/issues/6104

I realize this will be controversial and may be rejected but I think the
current status is very confusing to new / inexperienced users so I felt I
should suggest it.

As I mentioned in 17341, can we add a milestone and priority to this
feature request?

Thanks again for everybody's work on GHC

Cheers
George


On Sat, Jan 25, 2020 at 12:58 AM Ben Gamari  wrote:

>
> Hello all,
>
> The GHC team is happy to announce the availability of the first release
> candidate of GHC 8.10.1. Source and binary distributions are
> available at the usual place:
>
> https://downloads.haskell.org/ghc/8.10.1-rc1/
>
> GHC 8.10.1 will bring a number of new features including:
>
>  * The new UnliftedNewtypes extension allowing newtypes around unlifted
>types.
>
>  * The new StandaloneKindSignatures extension allows users to give
>top-level kind signatures to type, type family, and class
>declarations.
>
>  * A new warning, -Wderiving-defaults, to draw attention to ambiguous
>deriving clauses
>
>  * A number of improvements in code generation, including changes
>
>  * A new GHCi command, :instances, for listing the class instances
>available for a type.
>
>  * An upgraded Windows toolchain lifting the MAX_PATH limitation
>
>  * A new, low-latency garbage collector.
>
>  * Improved support profiling, including support for sending profiler
>samples to the eventlog, allowing correlation between the profile and
>other program events
>
> This is the first and likely final release candidate. For a variety of
> reasons, it comes a few weeks later than the original schedule of
> release late December. However, besides a few core libraries
> book-keeping issues this candidate is believed to be in good condition
> for the final release. As such, the final 8.10.1 release will likely
> come in two weeks.
>
> Note that at the moment we still require that macOS Catalina users
> exempt the binary distribution from the notarization requirement by
> running `xattr -cr .` on the unpacked tree before running `make install`.
>
> In addition, we are still looking for any Alpine Linux to help diagnose
> the correctness issues in the Alpine binary distribution [1]. If you use
> Alpine any you can offer here would be greatly appreciated.
>
> Please do test this release and let us know if you encounter any other
> issues.
>
> Cheers,
>
> - Ben
>
>
> [1] https://gitlab.haskell.org/ghc/ghc/issues/17508
> [2] https://gitlab.haskell.org/ghc/ghc/issues/17418
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

GHC 8.8.1 and cabal-install 3.0 not compatible with ghc-pkg

[George Colpitts]

Unfortunately ghc 8.8.1 and cabal-install 3.0 are not compatible with
ghc-pkg as documented in
https://github.com/haskell/cabal/issues/6262#issuecomment-538850477. As
Daniel Grober wrote there:

I think this is expected behaviour, at least from the cabal side of things.
Version 3.0.0.0 switched to using v2-build by default so installed
libraries are now registered into the "default" package environment file in
.ghc/*/environments/default as well as a package-db in
.cabal/store/ghc-*/package.db which GHC doesn't know about by itself.

AFAICS ghc-pkg simply doesn't have support for listing package environments
which sort of kind of makes sense but also breaks this workflow. I think
this should be reported as a GHC bug but I'm not sure it would even be a
good idea to add pkg-env support to ghc-pkg.



I thought this might be a ghc issue but since nobody else was complaining I
assumed I must have done something wrong. Should I file a ghc bug ?

Thanks
George



On Sat, Sep 7, 2019 at 6:20 PM George Colpitts 
wrote:

> Thanks for everybody's responses. I figured out that the following
>
> cabal-install users should note that cabal-install-3.0 or later is
> required for use with GHC 8.8.
>
>
> means  I should have cabal-install-3.0 before installing 8.8.1. Once I did
> that everything is fine.
>
> Maybe configure should give an error if the user does not
> have cabal-install-3.0?
>
> Thanks
> George
>
>
> On Fri, Sep 6, 2019 at 1:48 PM Shayne Fletcher 
> wrote:
>
>> I got there by doing,
>> ```
>>   cabal v2-install --installdir=~/.cabal/bin alex
>>   cabal v2-install --installdir=~/.cabal/bin happy
>> ```
>> and things seemed to be going smoothly enough after that.
>>
>> On Fri, Sep 6, 2019 at 12:08 PM Carter Schonwald <
>> carter.schonw...@gmail.com> wrote:
>>
>>> V1 or v2 install?
>>>
>>> On Mon, Sep 2, 2019 at 11:42 AM George Colpitts <
>>> george.colpi...@gmail.com> wrote:
>>>
>>>> https://www.haskell.org/ghc/blog/20190825-ghc-8.8.1-released.html says
>>>>
>>>> cabal-install users should note that cabal-install-3.0 or later is
>>>> required for use with GHC 8.8.
>>>>
>>>> but this seems wrong or have I done something wrong?
>>>>
>>>> $ cabal install cabal-install
>>>> cabal install cabal-install
>>>> ...
>>>>
>>>> Resolving dependencies...
>>>> cabal: Could not resolve dependencies:
>>>> [__0] trying: cabal-install-3.0.0.0 (user goal)
>>>> [__1] next goal: time (dependency of cabal-install)
>>>> [__1] rejecting: time-1.9.3/installed-1.9... (conflict: cabal-install =>
>>>> base>=4.8 && <4.13, time => base==4.13.0.0/installed-4.1...)
>>>> [__1] trying: time-1.9.3
>>>> [__2] next goal: stm (dependency of cabal-install)
>>>> [__2] rejecting: stm-2.5.0.0/installed-2.5... (conflict: cabal-install
>>>> =>
>>>> base>=4.8 && <4.13, stm => base==4.13.0.0/installed-4.1...)
>>>> [__2] trying: stm-2.5.0.0
>>>> [__3] next goal: process (dependency of cabal-install)
>>>> [__3] rejecting: process-1.6.5.1/installed-1.6... (conflict:
>>>> cabal-install =>
>>>> base>=4.8 && <4.13, process => base==4.13.0.0/installed-4.1...)
>>>> [__3] trying: process-1.6.5.1
>>>> [__4] next goal: pretty (dependency of cabal-install)
>>>> [__4] rejecting: pretty-1.1.3.6/installed-1.1... (conflict:
>>>> cabal-install =>
>>>> base>=4.8 && <4.13, pretty => base==4.13.0.0/installed-4.1...)
>>>> [__4] trying: pretty-1.1.3.6
>>>> [__5] next goal: network (dependency of cabal-install)
>>>> [__5] rejecting: network-3.1.0.1/installed-CeX... (conflict:
>>>> cabal-install =>
>>>> base>=4.8 && <4.13, network => base==4.13.0.0/installed-4.1...)
>>>> [__5] trying: network-3.1.0.1
>>>> [__6] trying: hackage-security-0.5.3.0 (dependency of cabal-install)
>>>> [__7] next goal: template-haskell (dependency of hackage-security)
>>>> [__7] rejecting: template-haskell-2.15.0.0/installed-2.1... (conflict:
>>>> cabal-install => base>=4.8 && <4.13, template-haskell =>
>>>> base==4.13.0.0/installed-4.1...)
>>>> [__7] rejecting: template-haskell-2.15.0.0, template-haskell-2.14.0.0,
>>>> template-haskell-2.13.0.0, template-haskell-2.12.0.0,
>>>> template-haskell-2.11.1.0, template-haskell-2.11.0.0,
>>>> templ

Re: [ANNOUNCE] GHC 8.8.1 and cabal-install version

[George Colpitts]

Thanks for everybody's responses. I figured out that the following

cabal-install users should note that cabal-install-3.0 or later is required
for use with GHC 8.8.


means  I should have cabal-install-3.0 before installing 8.8.1. Once I did
that everything is fine.

Maybe configure should give an error if the user does not
have cabal-install-3.0?

Thanks
George


On Fri, Sep 6, 2019 at 1:48 PM Shayne Fletcher 
wrote:

> I got there by doing,
> ```
>   cabal v2-install --installdir=~/.cabal/bin alex
>   cabal v2-install --installdir=~/.cabal/bin happy
> ```
> and things seemed to be going smoothly enough after that.
>
> On Fri, Sep 6, 2019 at 12:08 PM Carter Schonwald <
> carter.schonw...@gmail.com> wrote:
>
>> V1 or v2 install?
>>
>> On Mon, Sep 2, 2019 at 11:42 AM George Colpitts <
>> george.colpi...@gmail.com> wrote:
>>
>>> https://www.haskell.org/ghc/blog/20190825-ghc-8.8.1-released.html says
>>>
>>> cabal-install users should note that cabal-install-3.0 or later is
>>> required for use with GHC 8.8.
>>>
>>> but this seems wrong or have I done something wrong?
>>>
>>> $ cabal install cabal-install
>>> cabal install cabal-install
>>> ...
>>>
>>> Resolving dependencies...
>>> cabal: Could not resolve dependencies:
>>> [__0] trying: cabal-install-3.0.0.0 (user goal)
>>> [__1] next goal: time (dependency of cabal-install)
>>> [__1] rejecting: time-1.9.3/installed-1.9... (conflict: cabal-install =>
>>> base>=4.8 && <4.13, time => base==4.13.0.0/installed-4.1...)
>>> [__1] trying: time-1.9.3
>>> [__2] next goal: stm (dependency of cabal-install)
>>> [__2] rejecting: stm-2.5.0.0/installed-2.5... (conflict: cabal-install =>
>>> base>=4.8 && <4.13, stm => base==4.13.0.0/installed-4.1...)
>>> [__2] trying: stm-2.5.0.0
>>> [__3] next goal: process (dependency of cabal-install)
>>> [__3] rejecting: process-1.6.5.1/installed-1.6... (conflict:
>>> cabal-install =>
>>> base>=4.8 && <4.13, process => base==4.13.0.0/installed-4.1...)
>>> [__3] trying: process-1.6.5.1
>>> [__4] next goal: pretty (dependency of cabal-install)
>>> [__4] rejecting: pretty-1.1.3.6/installed-1.1... (conflict:
>>> cabal-install =>
>>> base>=4.8 && <4.13, pretty => base==4.13.0.0/installed-4.1...)
>>> [__4] trying: pretty-1.1.3.6
>>> [__5] next goal: network (dependency of cabal-install)
>>> [__5] rejecting: network-3.1.0.1/installed-CeX... (conflict:
>>> cabal-install =>
>>> base>=4.8 && <4.13, network => base==4.13.0.0/installed-4.1...)
>>> [__5] trying: network-3.1.0.1
>>> [__6] trying: hackage-security-0.5.3.0 (dependency of cabal-install)
>>> [__7] next goal: template-haskell (dependency of hackage-security)
>>> [__7] rejecting: template-haskell-2.15.0.0/installed-2.1... (conflict:
>>> cabal-install => base>=4.8 && <4.13, template-haskell =>
>>> base==4.13.0.0/installed-4.1...)
>>> [__7] rejecting: template-haskell-2.15.0.0, template-haskell-2.14.0.0,
>>> template-haskell-2.13.0.0, template-haskell-2.12.0.0,
>>> template-haskell-2.11.1.0, template-haskell-2.11.0.0,
>>> template-haskell-2.10.0.0, template-haskell-2.9.0.0,
>>> template-haskell-2.8.0.0,
>>> template-haskell-2.7.0.0, template-haskell-2.6.0.0,
>>> template-haskell-2.5.0.0,
>>> template-haskell-2.4.0.1, template-haskell-2.4.0.0,
>>> template-haskell-2.3.0.1,
>>> template-haskell-2.3.0.0, template-haskell-2.2.0.0 (constraint from
>>> non-upgradeable package requires installed instance)
>>> [__7] fail (backjumping, conflict set: cabal-install, hackage-security,
>>> template-haskell)
>>> After searching the rest of the dependency tree exhaustively, these were
>>> the
>>> goals I've had most trouble fulfilling: base, cabal-install, directory,
>>> template-haskell, process, time, network, pretty, hackage-security,
>>> deepseq,
>>> HTTP, stm, cabal-install:lib
>>>
>>>
>>> On Mon, Aug 26, 2019 at 6:25 AM Ben Gamari  wrote:
>>>
>>>>
>>>> Hello everyone,
>>>>
>>>> The GHC team is pleased to announce the release candidate for GHC 8.8.1.
>>>> The source distribution, binary distributions, and documentation are
>>>> available at
>>>>
>>>> https://downloads.haskell.org/ghc/8.8.1
>>>>
>>>> This release 

Re: [ANNOUNCE] GHC 8.8.1 and cabal-install version

[George Colpitts]

https://www.haskell.org/ghc/blog/20190825-ghc-8.8.1-released.html says

cabal-install users should note that cabal-install-3.0 or later is required
for use with GHC 8.8.

but this seems wrong or have I done something wrong?

$ cabal install cabal-install
cabal install cabal-install
...

Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: cabal-install-3.0.0.0 (user goal)
[__1] next goal: time (dependency of cabal-install)
[__1] rejecting: time-1.9.3/installed-1.9... (conflict: cabal-install =>
base>=4.8 && <4.13, time => base==4.13.0.0/installed-4.1...)
[__1] trying: time-1.9.3
[__2] next goal: stm (dependency of cabal-install)
[__2] rejecting: stm-2.5.0.0/installed-2.5... (conflict: cabal-install =>
base>=4.8 && <4.13, stm => base==4.13.0.0/installed-4.1...)
[__2] trying: stm-2.5.0.0
[__3] next goal: process (dependency of cabal-install)
[__3] rejecting: process-1.6.5.1/installed-1.6... (conflict: cabal-install
=>
base>=4.8 && <4.13, process => base==4.13.0.0/installed-4.1...)
[__3] trying: process-1.6.5.1
[__4] next goal: pretty (dependency of cabal-install)
[__4] rejecting: pretty-1.1.3.6/installed-1.1... (conflict: cabal-install =>
base>=4.8 && <4.13, pretty => base==4.13.0.0/installed-4.1...)
[__4] trying: pretty-1.1.3.6
[__5] next goal: network (dependency of cabal-install)
[__5] rejecting: network-3.1.0.1/installed-CeX... (conflict: cabal-install
=>
base>=4.8 && <4.13, network => base==4.13.0.0/installed-4.1...)
[__5] trying: network-3.1.0.1
[__6] trying: hackage-security-0.5.3.0 (dependency of cabal-install)
[__7] next goal: template-haskell (dependency of hackage-security)
[__7] rejecting: template-haskell-2.15.0.0/installed-2.1... (conflict:
cabal-install => base>=4.8 && <4.13, template-haskell =>
base==4.13.0.0/installed-4.1...)
[__7] rejecting: template-haskell-2.15.0.0, template-haskell-2.14.0.0,
template-haskell-2.13.0.0, template-haskell-2.12.0.0,
template-haskell-2.11.1.0, template-haskell-2.11.0.0,
template-haskell-2.10.0.0, template-haskell-2.9.0.0,
template-haskell-2.8.0.0,
template-haskell-2.7.0.0, template-haskell-2.6.0.0,
template-haskell-2.5.0.0,
template-haskell-2.4.0.1, template-haskell-2.4.0.0,
template-haskell-2.3.0.1,
template-haskell-2.3.0.0, template-haskell-2.2.0.0 (constraint from
non-upgradeable package requires installed instance)
[__7] fail (backjumping, conflict set: cabal-install, hackage-security,
template-haskell)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: base, cabal-install, directory,
template-haskell, process, time, network, pretty, hackage-security, deepseq,
HTTP, stm, cabal-install:lib


On Mon, Aug 26, 2019 at 6:25 AM Ben Gamari  wrote:

>
> Hello everyone,
>
> The GHC team is pleased to announce the release candidate for GHC 8.8.1.
> The source distribution, binary distributions, and documentation are
> available at
>
> https://downloads.haskell.org/ghc/8.8.1
>
> This release is the culmination of over 3000 commits by over one hundred
> contributors and has several new features and numerous bug fixes
> relative to GHC 8.6:
>
>  * Visible kind applications are now supported (GHC Proposal #15)
>
>  * Profiling now works correctly on 64-bit Windows (although still may
>be problematic on 32-bit Windows due to platform limitations; see
>#15934)
>
>  * A new code layout algorithm for amd64's native code generator
>significantly improving the runtime performance of some kernels
>
>  * The introduction of a late lambda-lifting pass which may reduce
>allocations significantly for some programs.
>
>  * Further work on Trees That Grow, enabling improved code re-use of the
>Haskell AST in tooling
>
>  * Users can write `forall` in more contexts (GHC Proposal #7)
>
>  * The pattern-match checker is now more precise in the presence of
>strict fields with uninhabited types.
>
>  * A comprehensive audit of GHC's memory ordering barriers has been
>performed, resulting in a number of fixes that should significantly
>improve the reliability of programs on architectures with
>weakly-ordered memory models (e.g. PowerPC, many ARM and AArch64
>implementations).
>
>  * A long-standing linker limitation rendering GHCi unusable with
>projects with cyclic symbol dependencies has been fixed (#13786)
>
>  * Further work on the Hadrian build system
>
>  * Countless miscellaneous bug-fixes
>
> Unfortunately, due to a build issue (#17108) found late in the release
> process
> i386 Windows builds are currently unavailable. These will be provided in
> the coming weeks.
>
> As always, if anything looks amiss do let us know.
>
> Happy compiling!
>
> Cheers,
>
> - Ben
>
>
> [1]
> https://downloads.haskell.org/ghc/8.8.1/docs/html/users_guide/8.8.1-notes.html
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] GHC 8.8.1-alpha2 is now available

[George Colpitts]

Will 8.8.1 use llvm 7.0.1? I don't see it mentioned in the release notes.

Cheers
George


On Sat, Jun 15, 2019 at 4:36 PM Ben Gamari  wrote:

> Hello everyone,
>
> The GHC team is pleased to announce the second and likely last alpha
> release of GHC 8.8.1. The source distribution, binary distributions, and
> documentation are available at
>
> https://downloads.haskell.org/~ghc/8.8.1-alpha2
>
> A draft of the release notes is also available [1].
>
> This release is the culmination of over 3000 commits by over one hundred
> contributors and has several new features and numerous bug fixes
> relative to GHC 8.6:
>
>  * Profiling now works correctly on 64-bit Windows (although still may
>be problematic on 32-bit Windows due to platform limitations; see
>#15934)
>
>  * A new code layout algorithm for amd64's native code generator
>
>  * The introduction of a late lambda-lifting pass which may reduce
>allocations significantly for some programs.
>
>  * Further work on Trees That Grow, enabling improved code re-use of the
>Haskell AST in tooling
>
>  * More locations where users can write `forall` (GHC Proposal #0007)
>
>  * Further work on the Hadrian build system
>
> This release brings a number of fixes since alpha 1:
>
>  * A number of linker fixes (#16779, #16784)
>
>  * The process, binary, Cabal, time, terminfo libraries have all been
>bumped to their final release versions
>
>  * A regression rendering TemplateHaskell unusable in cross-compiled
>configurations has been fixed (#16331)
>
>  * A regression causing compiler panics on compilation of some programs
>has been fixed (#16449)
>
>  * -Wmissing-home-modules now handles hs-boot files correctly (#16551)
>
>  * A regression causing some programs to fail at runtime has been fixed
>(#16066)
>
> Due to on-going work on our release and testing infrastructure this
> cycle is proceeding at a pace significantly slower than expected.
> However, we anticipate that this investment will allow us to release a
> more reliable, easier-to-install compiler on the planned six-month
> release cadence in the future.
>
> As always, if anything looks amiss do let us know.
>
> Happy compiling!
>
> Cheers,
>
> - Ben
>
> [1]
> https://downloads.haskell.org/ghc/8.8.1-alpha2/docs/html/users_guide/8.8.1-notes.html
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] GHC 8.8.1-alpha1 is now available

[George Colpitts]

It seems as if there is no migration documentation,
https://gitlab.haskell.org/ghc/ghc/wikis/status/migration/8.8. Will that be
forthcoming?

Thanks
George


On Thu, Apr 25, 2019 at 8:51 PM Ben Gamari  wrote:

> Hello everyone,
>
> The GHC team is pleased to announce the first alpha release of GHC 8.8.1.
> The source distribution, binary distributions, and documentation are
> available at
>
> https://downloads.haskell.org/~ghc/8.8.1-alpha1
>
> A draft of the release notes is also available [1].
>
> This release is the culmination of over 3000 commits by over one hundred
> contributors and has several new features and numerous bug fixes
> relative to GHC 8.6:
>
>  * Profiling now works correctly on 64-bit Windows (although still may
>be problematic on 32-bit Windows due to platform limitations; see
>#15934)
>
>  * A new code layout algorithm for amd64's native code generator
>
>  * The introduction of a late lambda-lifting pass which may reduce
>allocations significantly for some programs.
>
>  * Further work on Trees That Grow, enabling improved code re-use of the
>Haskell AST in tooling
>
>  * More locations where users can write `forall` (GHC Proposal #0007)
>
>  * Further work on the Hadrian build system
>
> This release starts the pre-release cycle for GHC 8.8. This cycle is
> starting quite a bit later than expected due recent work on GHC's CI and
> release infrastructure. See the GHC Blog [2] for more on this.
>
> As always, if anything looks amiss do let us know.
>
> Happy compiling!
>
> Cheers,
>
> - Ben
>
>
> [1]
> https://downloads.haskell.org/ghc/8.8.1-alpha1/docs/html/users_guide/8.8.1-notes.html
> [2] https://www.haskell.org/ghc/blog/20190405-ghc-8.8-status.html
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] GHC 8.6.1 released

[George Colpitts]

Yes, it worked for me.

On Sat, Sep 22, 2018 at 7:44 PM Evan Laforge  wrote:

> Has anyone installed the OS X binary distribution?  I get:
>
> "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy
> libraries/ghc-prim dist-install "strip" '' '/usr/local'
> '/usr/local/lib/ghc-8.6.1'
> '/usr/local/share/doc/ghc-8.6.1/html/libraries' 'v p dyn'
> dyld: Library not loaded: /usr/local/opt/gmp/lib/libgmp.10.dylib
>   Referenced from:
>
> /usr/local/src/hs/ghc-8.6.1/libraries/base/dist-install/build/libHSbase-4.12.0.0-ghc8.6.1.dylib
>   Reason: image not found
>
> otool -L on libHSBase indeed shows a reference to
> /usr/local/opt/gmp/lib/libgmp.10.dylib, which of course doesn't exist,
> not being a standard location.  otool on 8.4.2's libHSBase has no
> reference to libgmp at all.  Both of them have
> @rpath/libHSinteger-gmp-1.0.2.0-ghc$version.dylib, but perhaps that's
> just ghc's binding to libgmp.
>
> I don't actually know how ghc links libgmp nowadays.  Perhaps the
> usual OS X build statically links libgmp and some flags got wrong for
> this one and it wound up dynamic?
> On Fri, Sep 21, 2018 at 5:57 PM Ben Gamari  wrote:
> >
> > Hello everyone,
> >
> > The GHC team is pleased to announce the availability of GHC 8.6.1, the
> > fourth major release in the GHC 8 series. The source distribution, binary
> > distributions, and documentation for this release are available at
> >
> > https://downloads.haskell.org/~ghc/8.6.1
> >
> > The 8.6 release fixes over 400 bugs from the 8.4 series and introduces a
> > number of exciting features. These most notably include:
> >
> >  * A new deriving mechanism, `deriving via`, providing a convenient way
> >for users to extend Haskell's typeclass deriving mechanism
> >
> >  * Quantified constraints, allowing forall quantification in constraint
> contexts
> >
> >  * An early version of the GHCi `:doc` command
> >
> >  * The `ghc-heap-view` package, allowing introspection into the
> >structure of GHC's heap
> >
> >  * Valid hole fit hints, helping the user to find terms to fill typed
> >holes in their programs
> >
> >  * The BlockArguments extension, allowing the `$` operator to be omitted
> >in some unambiguous contexts
> >
> >  * An exciting new plugin mechanism, source plugins, allowing plugins to
> >inspect and modify a wide variety of compiler representations.
> >
> >  * Improved recompilation checking when plugins are used
> >
> >  * Significantly better handling of macOS linker command size limits,
> >avoiding linker errors while linking large projects
> >
> >  * The next phase of the MonadFail proposal, enabling
> >-XMonadFailDesugaring by default
> >
> > A full list of the changes in this release can be found in the
> > release notes:
> >
> >
> https://downloads.haskell.org/~ghc/8.6.1/docs/html/users_guide/8.6.1-notes.html
> >
> > Perhaps of equal importance, GHC 8.6 is the second major release made
> > under GHC's accelerated six-month release schedule and the first set of
> > binary distributions built primarily using our new continuous
> > integration scheme. While the final 8.6 release is around three weeks
> > later than initially scheduled due to late-breaking bug reports, we
> > expect that the 8.8 release schedule shouldn't be affected.
> >
> > Thanks to everyone who has contributed to developing, documenting, and
> > testing this release!
> >
> > As always, let us know if you encounter trouble.
> >
> >
> > 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 efficient 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. 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  https://www.haskell.org/ghc/
> > GHC developers' home page  

Re: [ANNOUNCE] GHC 8.6.1-alpha1 available

[George Colpitts]

I don't see an apple/darwin binary. Not sure if that is an oversight or was
planned.

On Sat, Jun 30, 2018 at 6:26 PM Ben Gamari  wrote:

>
> The GHC development team is pleased to announce the first
> alpha release leading up to GHC 8.6.1. The usual release artifacts
> are available from
>
> https://downloads.haskell.org/~ghc/8.6.1-alpha1
>
> This is the first release (partially) generated using our new CI
> infrastructure. One known issue is that the haddock documentation is
> currently unavailable. This will be fixed in the next alpha release. Do
> let us know if you spot anything else amiss.
>
> As always, do let us know if you encounter any trouble in the course of
> testing. Thanks for your help!
>
> Cheers,
>
> - Ben
> ___
> ghc-devs mailing list
> ghc-d...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] GHC 8.4.1-alpha2 available

[George Colpitts]

installed fine on my mac
primitive can now be compiled
unordered-containers does not compile, even with allow-new. This has been
reported by Neil Mitchell
haskell-src-exts does not compile, not clear where to report this

On Sun, Jan 21, 2018 at 4:15 PM Ben Gamari  wrote:

>
> The GHC development team is pleased to announce the second alpha release
> of the 8.4.1 release. The usual release artifacts are available from
>
> https://downloads.haskell.org/~ghc/8.4.1-alpha2
>
> Note that this alpha, like alpha1, is unfortunately afflicted by #14678.
> We will try to get an alpha3 out as soon as this issue has been resolved.
> However, as this alpha has a number of fixes since alpha1, we have
> decided it would be best not to delay it any further.
>
> Also, due to user demand we now offer a binary distribution for 64-bit
> Fedora 27; this distribution links against ncurses6. This is in contrast
> to the Debian 8 distribution, which links against ncurses5. Users of
> newer distributions (Fedora 27, Debian sid) should use this distribution.
>
> Note that this release drops compatibility with GCC 4.6 and earlier.
> While we generally try to place as few constraints on system toolchain
> as possible, this release depends upon the __atomic__ builtins provided
> by GCC 4.7 and later (see #14244).
>
>
> === Notes on release scheduling ===
>
> The 8.4.1 release marks the first release where GHC will be adhering to
> its new, higher-cadence release schedule [1]. Under this new scheme,
> major releases will be made in 6-month intervals with interstitial minor
> releases as necessary.
>
> In order to minimize the likelihood of schedule slippage and to ensure
> adequate testing, each major release will be preceeded by a number of
> regular alpha releases. We will begin issuing these releases roughly
> three months before the final date of the major release and will issue
> roughly one every two weeks during this period. This high release
> cadence will allow us to quickly get fixes in to users hands and allow
> better feedback on the status of the release.
>
> GHC 8.4 is slated to be released in mid-February but, due to technical
> constraints, we are starting the alpha-release cycle a bit later than
> planned under the above schedule. For this reason, it would be greatly
> appreciated if users could put this alpha through its paces to make up
> for lost time.
>
> As always, do let us know if you encounter any trouble in the course of
> testing. Thanks for your help!
>
> Cheers,
>
> - Ben
>
>
> [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule
> ___
> ghc-devs mailing list
> ghc-d...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] GHC 8.4.1-alpha1 available

[George Colpitts]

Probably stating what is obvious and well-know but anyways:

   - On the status page
   <https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.4.1> it would be
   good to have a link for "Phase 2 of the Semigroup-Monoid Proposal (Herbert
   Riedel)"
   - Also IIRC we normally have a page on porting to the new release. It
   would be good to have that also when we have a chance.

It's great that we are getting started early.

On Thu, Dec 21, 2017 at 4:16 PM George Colpitts <george.colpi...@gmail.com>
wrote:

> Thanks Ben. I installed the Mac binaries.
>
> For others who are wondering, you need llvm 5 if you want to use llvm with
> this.
>
> Needless to say, many libraries, e.g. haskell-src-exts, primitive, and
> intero won't compile with this even with --allow-newer
>
> I'll notify those libraries about that in case they want to get started on
> 8.4.1
>
> Cheers
> George
>
> On Wed, Dec 20, 2017 at 4:48 PM Ben Gamari <b...@well-typed.com> wrote:
>
>>
>> The GHC development team is pleased to announce the first alpha release
>> of the 8.4.1 release. The usual release artifacts are available from
>>
>> https://downloads.haskell.org/~ghc/8.4.1-alpha1
>>
>> Note that this release drops compatibility with GCC 4.6 and earlier.
>> While we generally try to place as few constraints on system toolchain
>> as possible, this release depends upon the __atomic__ builtins provided
>> by GCC 4.7 and later (see #14244).
>>
>>
>> === Notes on release scheduling ===
>>
>> The 8.4.1 release marks the first release where GHC will be adhering to
>> its new, higher-cadence release schedule [1]. Under this new scheme,
>> major releases will be made in 6-month intervals with interstitial minor
>> releases as necessary.
>>
>> In order to minimize the likelihood of schedule slippage and to ensure
>> adequate testing, each major release will be preceeded by a number of
>> regular alpha releases. We will begin issuing these releases roughly
>> three months before the final date of the major release and will issue
>> roughly one every two weeks during this period. This high release
>> cadence will allow us to quickly get fixes in to users hands and allow
>> better feedback on the status of the release.
>>
>> GHC 8.4 is slated to be released in mid-February but, due to technical
>> constraints, we are starting the alpha-release cycle a bit later than
>> planned under the above schedule. For this reason, it would be greatly
>> appreciated if users could put this alpha through its paces to make up
>> for lost time.
>>
>> As always, do let us know if you encounter any trouble in the course of
>> testing. Thanks for your help!
>>
>> Cheers,
>>
>> - Ben
>>
>>
>> [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] GHC 8.4.1-alpha1 available

[George Colpitts]

Thanks Ben. I installed the Mac binaries.

For others who are wondering, you need llvm 5 if you want to use llvm with
this.

Needless to say, many libraries, e.g. haskell-src-exts, primitive, and
intero won't compile with this even with --allow-newer

I'll notify those libraries about that in case they want to get started on
8.4.1

Cheers
George

On Wed, Dec 20, 2017 at 4:48 PM Ben Gamari  wrote:

>
> The GHC development team is pleased to announce the first alpha release
> of the 8.4.1 release. The usual release artifacts are available from
>
> https://downloads.haskell.org/~ghc/8.4.1-alpha1
>
> Note that this release drops compatibility with GCC 4.6 and earlier.
> While we generally try to place as few constraints on system toolchain
> as possible, this release depends upon the __atomic__ builtins provided
> by GCC 4.7 and later (see #14244).
>
>
> === Notes on release scheduling ===
>
> The 8.4.1 release marks the first release where GHC will be adhering to
> its new, higher-cadence release schedule [1]. Under this new scheme,
> major releases will be made in 6-month intervals with interstitial minor
> releases as necessary.
>
> In order to minimize the likelihood of schedule slippage and to ensure
> adequate testing, each major release will be preceeded by a number of
> regular alpha releases. We will begin issuing these releases roughly
> three months before the final date of the major release and will issue
> roughly one every two weeks during this period. This high release
> cadence will allow us to quickly get fixes in to users hands and allow
> better feedback on the status of the release.
>
> GHC 8.4 is slated to be released in mid-February but, due to technical
> constraints, we are starting the alpha-release cycle a bit later than
> planned under the above schedule. For this reason, it would be greatly
> appreciated if users could put this alpha through its paces to make up
> for lost time.
>
> As always, do let us know if you encounter any trouble in the course of
> testing. Thanks for your help!
>
> Cheers,
>
> - Ben
>
>
> [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] GHC 8.2.2 release candidate 1

[George Colpitts]

installed fine on mac os 10.12.6 with Xcode 9.

I then installed vector, hlint, criterion and threadscope and did a smoke
test of hlint

On Sun, Oct 1, 2017 at 8:18 AM Ben Gamari  wrote:

>
> Hello everyone,
>
> The GHC team is very pleased to announce the first candidate of the
> 8.2.2 release of the Glasgow Haskell Compiler. Source and binary
> distributions are available at
>
> https://downloads.haskell.org/~ghc/8.2.2-rc1/
>
> Currently there is a slightly reduced set of binary distributions
> available; do let me know if there is a missing platform you would like
> to see built.
>
> This is the first of two release candidates leading up the final 8.2.2
> release. This release fixes approximately fifty bugs present in 8.2.1.
> See [1] for the full list.
>
> As always, please report any issues you encounter.
>
> Happy testing,
>
> - Ben
>
>
> [1]
> https://ghc.haskell.org/trac/ghc/query?status=closed=8.2.2=id=summary=status=type=priority=milestone=component=priority
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Spurious recompilations when using a compiler plugin

[George Colpitts]

is it possible that this is also connected to
https://ghc.haskell.org/trac/ghc/ticket/13604 ?

On Tue, Sep 19, 2017 at 10:00 AM Ben Gamari  wrote:

> Conal Elliott  writes:
>
> > It appears that use of GHC plugins causes client code to get needlessly
> > recompiled. (See Trac issues 12567
> >  and 7414
> > .) It’s becoming more of a
> > problem for usability of the plugin
> >  I’ve been developing,
> and
> > I’m wondering what can be done. Some questions:
> >
> >- Is there any work in progress on fixing this situation?
> >- Are there serious obstacles to fixing it?
> >- Do plugin writers or users have any workarounds?
> >
> I think the real question is what sort of interface do plugin authors
> need?
>
> I suspect there are a few distinct tasks here,
>
>  * compute and record module implementation hashes in interface files
>
>  * to include plugin implementation hashes in the recompilation check
>
>  * to provide an interface allowing a plugin to compute a hash of its
>arguments which can be included into the recompilation check. One way
>of realising this would be to add a field like the following to Plugin,
>
>pluginHash :: [CommandLineOption] -> Maybe Fingerprint
>-- Nothing would denote "always rebuild"
>
>Would this help in your case?
>
> This would allow us to fix the TH problem in #7277 and fix the plugins
> problem in #7414 and #12567 in a nearly optimal way (assuming the plugin
> author is able to precisely define a hash).
>
> None of this is terribly difficult and given Nick's recent work on his
> row types plugin, it seems like it's getting more urgent.
>
> Cheers,
>
> - Ben
> ___
> ghc-devs mailing list
> ghc-d...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: 8.2.1 changes to iface/FlagChecker.hs

[George Colpitts]

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

On Thu, Aug 3, 2017 at 4:32 PM Evan Laforge  wrote:

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

Re: [ANNOUNCE] GHC 8.2.1 release candidate 2

[George Colpitts]

Done: https://ghc.haskell.org/trac/ghc/ticket/13715#ticket

On Wed, May 17, 2017 at 1:44 PM George Colpitts <george.colpi...@gmail.com>
wrote:

> Yes, I agree, will file a bug this evening.
>
> On Wed, May 17, 2017 at 10:26 AM Ben Gamari <b...@well-typed.com> wrote:
>
>> George Colpitts <george.colpi...@gmail.com> writes:
>>
>> > Hi Ben
>> >
>> > I built from source and ran the tests on my Mac and found some
>> > problems. I'm not sure if the failing tests have been ran successfully
>> > by others on this platform. I did "make slowtest". Maybe the problem
>> > only happens on my machine.
>> >
>> Currently Harbormaster only runs `make test`, not `make slowtest`.
>> Consequently, `slowtest` is generally rather broken, even on Linux.
>> Every once in a while I look at it and try to pare down the failures,
>> but it's an up-hill battle.
>>
>> > I'm new to running the testsuite and not sure how the sleep settings on
>> my
>> > computer affect long running computations.
>> >
>> >- If I want to run a long running test such as "make slowtest"
>> overnight
>> >will my computer go to sleep preventing the test from running? i.e.
>> should
>> >I invoke it with something like "caffeinate -i make slowtest" ?
>> >
>> That sounds right to me.
>>
>> > I almost didn't run the tests assuming they had been run as part of the
>> > release process but then I guessed that maybe slowtest had not been
>> run. It
>> > would be a pain but would it be worth documenting which tests had been
>> run
>> > on which platforms?
>> >
>> I currently don't validate the binary distribution tarballs. Instead I
>> judge validation state from Harbormaster's testing of the ghc-8.2
>> branch.
>>
>> Over the summer we intend on revamping our CI infrastructure, which
>> should make it easier to do nightly runs of slowtest (and perhaps
>> provide nightly or even per-commit binary distributions).
>>
>> > I assume I should file a bug for the following?
>> >
>> That would be great. I had a quick look at this and it looks quite
>> likely that the simplifier is looping: even -fsimpl-tick-factor=1000
>> doesn't succeed. This looks like a real regression.
>>
>> Cheers,
>>
>> - Ben
>>
>>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] GHC 8.2.1 release candidate 2

[George Colpitts]

Yes, I agree, will file a bug this evening.

On Wed, May 17, 2017 at 10:26 AM Ben Gamari <b...@well-typed.com> wrote:

> George Colpitts <george.colpi...@gmail.com> writes:
>
> > Hi Ben
> >
> > I built from source and ran the tests on my Mac and found some
> > problems. I'm not sure if the failing tests have been ran successfully
> > by others on this platform. I did "make slowtest". Maybe the problem
> > only happens on my machine.
> >
> Currently Harbormaster only runs `make test`, not `make slowtest`.
> Consequently, `slowtest` is generally rather broken, even on Linux.
> Every once in a while I look at it and try to pare down the failures,
> but it's an up-hill battle.
>
> > I'm new to running the testsuite and not sure how the sleep settings on
> my
> > computer affect long running computations.
> >
> >- If I want to run a long running test such as "make slowtest"
> overnight
> >will my computer go to sleep preventing the test from running? i.e.
> should
> >I invoke it with something like "caffeinate -i make slowtest" ?
> >
> That sounds right to me.
>
> > I almost didn't run the tests assuming they had been run as part of the
> > release process but then I guessed that maybe slowtest had not been run.
> It
> > would be a pain but would it be worth documenting which tests had been
> run
> > on which platforms?
> >
> I currently don't validate the binary distribution tarballs. Instead I
> judge validation state from Harbormaster's testing of the ghc-8.2
> branch.
>
> Over the summer we intend on revamping our CI infrastructure, which
> should make it easier to do nightly runs of slowtest (and perhaps
> provide nightly or even per-commit binary distributions).
>
> > I assume I should file a bug for the following?
> >
> That would be great. I had a quick look at this and it looks quite
> likely that the simplifier is looping: even -fsimpl-tick-factor=1000
> doesn't succeed. This looks like a real regression.
>
> Cheers,
>
> - Ben
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] GHC 8.2.1 release candidate 2

[George Colpitts]

Hi Ben

I built from source and ran the tests on my Mac and found some
problems. I'm not sure if the failing tests have been ran successfully
by others on this platform. I did "make slowtest". Maybe the problem
only happens on my machine.

I'm new to running the testsuite and not sure how the sleep settings on my
computer affect long running computations.

   - If I want to run a long running test such as "make slowtest" overnight
   will my computer go to sleep preventing the test from running? i.e. should
   I invoke it with something like "caffeinate -i make slowtest" ?

I almost didn't run the tests assuming they had been run as part of the
release process but then I guessed that maybe slowtest had not been run. It
would be a pain but would it be worth documenting which tests had been run
on which platforms?

I assume I should file a bug for the following?

make TEST=dynamic-paper WAY=profasm
...
=> dynamic-paper(profasm) 1 of 1 [0, 0, 0]
cd "./dependent/should_compile/dynamic-paper.run" &&
 "/Users/gcolpitts/Downloads/ghc-8.2.0.20170507/inplace/bin/ghc-stage2" -c
dynamic-paper.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts
-fno-warn-missed-specialisations -fshow-warning-groups
-fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output  -O
-prof -static -fprof-auto
Compile failed (exit code 1) errors were:
ghc-stage2: panic! (the 'impossible' happened)
 (GHC version 8.2.0.20170507 for x86_64-apple-darwin):
Simplifier ticks exhausted
 When trying UnfoldingDone delta
 To increase the limit, use -fsimpl-tick-factor=N (default 100)
 If you need to do this, let GHC HQ know, and what factor you needed
 To see detailed counts use -ddump-simpl-stats
 Total ticks: 143842
 Call stack:
 CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in
ghc:Outputable
callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in
ghc:Outputable
pprPanic, called at compiler/simplCore/SimplMonad.hs:199:31 in
ghc:SimplMonad

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug


*** unexpected failure for dynamic-paper(profasm)

Unexpected results from:
TEST="dynamic-paper"

SUMMARY for test run started at Wed May 17 08:19:59 2017 ADT
0:00:06 spent to go through
  1 total tests, which gave rise to
  5 test cases, of which
  4 were skipped

  0 had missing libraries
  0 expected passes
  0 expected failures

  0 caused framework failures
  0 caused framework warnings
  0 unexpected passes
  1 unexpected failures
  0 unexpected stat failures

Unexpected failures:
  dependent/should_compile/dynamic-paper.run  dynamic-paper [exit code
non-0] (profasm)

It fails with  -fsimpl-tick-factor=1000 also:

make TEST=dynamic-paper WAY=profasm EXTRA_HC_OPTS='-fsimpl-tick-factor=1000'
...
cd "./dependent/should_compile/dynamic-paper.run" &&
 "/Users/gcolpitts/Downloads/ghc-8.2.0.20170507/inplace/bin/ghc-stage2" -c
dynamic-paper.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts
-fsimpl-tick-factor=1000 -fno-warn-missed-specialisations
-fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret
-dno-debug-output  -O -prof -static -fprof-auto
Compile failed (exit code 1) errors were:
ghc-stage2: panic! (the 'impossible' happened)
 (GHC version 8.2.0.20170507 for x86_64-apple-darwin):
Simplifier ticks exhausted
 When trying UnfoldingDone delta
 To increase the limit, use -fsimpl-tick-factor=N (default 100)
 If you need to do this, let GHC HQ know, and what factor you needed
 To see detailed counts use -ddump-simpl-stats
 Total ticks: 1438402
 Call stack:
 CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in
ghc:Outputable
callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in
ghc:Outputable
pprPanic, called at compiler/simplCore/SimplMonad.hs:199:31 in
ghc:SimplMonad

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug


*** unexpected failure for dynamic-paper(profasm)

Unexpected results from:
TEST="dynamic-paper"

SUMMARY for test run started at Wed May 17 08:29:43 2017 ADT
0:00:35 spent to go through
  1 total tests, which gave rise to
  5 test cases, of which
  4 were skipped

  0 had missing libraries
  0 expected passes
  0 expected failures

  0 caused framework failures
  0 caused framework warnings
  0 unexpected passes
  1 unexpected failures
  0 unexpected stat failures

Unexpected failures:
  dependent/should_compile/dynamic-paper.run  dynamic-paper [exit code
non-0] (profasm)



Cheers
George



On Mon, May 15, 2017 at 11:48 PM Ben Gamari  wrote:

>
> Hello everyone,
>
> The GHC team is very pleased to announce the second candidate of the
> 8.2.1 release of the Glasgow Haskell Compiler. Source and binary
> distributions are available at
>
> https://downloads.haskell.org/~ghc/8.2.1-rc2/
>
> This is the second of what will 

Re: GHC rewrite rules for class operations & laws

[George Colpitts]

Done: https://ghc.haskell.org/trac/ghc/ticket/13044#ticket

Not sure if it fully captures what you want so people should feel free to
edit.

Cheers
George


On Wed, Dec 28, 2016 at 8:27 PM Conal Elliott <co...@conal.net> wrote:

> Hi, George. Yes, please do add a task, hopefully to serve as a
> conversation anchor until the issues and path forward are clearer. From my
> perspective, class methods are among the most natural and useful candidates
> for rewrite rules, since they tend to have associated laws, many (but not
> all) of which are helpful in optimization. The alternative I know (and am
> using) is fairly inconvenient: replicating entire APIs just in order to
> delay inlining long enough to apply rules.
>
> Thanks,  - Conal
>
>
> On Sun, Dec 11, 2016 at 7:24 AM, George Colpitts <
> george.colpi...@gmail.com> wrote:
>
> Do you want me to add a task ticket to remove this restriction that
> rewrite rules can't be used for class methods?
>
> On Tue, Nov 22, 2016 at 8:06 AM Simon Peyton Jones via
> Glasgow-haskell-users <glasgow-haskell-users@haskell.org> wrote:
>
> Conal
>
>
>
> Is it possible to apply GHC rewrite rules to class methods?
>
>
>
> Not currently.  See https://ghc.haskell.org/trac/ghc/ticket/11688, esp
> comment:7 which gives links to similar examples.
> https://ghc.haskell.org/trac/ghc/ticket/10528 comment:13  gives more
> background.
>
>
>
> It’d be great if someone wanted to think through all this.
>
>
>
> Simon
>
>
>
> *From:* Glasgow-haskell-users [mailto:
> glasgow-haskell-users-boun...@haskell.org] *On Behalf Of *Conal Elliott
> *Sent:* 17 November 2016 16:40
> *To:* glasgow-haskell-users@haskell.org
> *Subject:* GHC rewrite rules for class operations & laws
>
>
>
> Is it possible to apply GHC rewrite rules to class methods? From what I’ve
> read and seen, class methods get eliminated early by
> automatically-generated rules. Is there really no way to postpone such
> inlining until a later simplifier stage? The GHC Users Guide docs say no
> <https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloads.haskell.org%2F~ghc%2Flatest%2Fdocs%2Fhtml%2Fusers_guide%2Fglasgow_exts.html%23how-rules-interact-with-class-methods=02%7C01%7Csimonpj%40microsoft.com%7C8678611c4c57499f97be08d40f08662a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636149976146128136=GjkFhlWdNkT6eo85FvcLKkJYoir7Dui9xJ9kMTYKVmU%3D=0>,
> and suggests instead giving a duplicate vocabulary with somewhat awkward
> names for class methods. I’ve not seen this practice in libraries. I gather
> that we cannot therefore use class laws as optimizations in the form of
> rewrite rules, which seems a terrible loss.
>
> In Control.Category and Control.Arrow, I see rules for class laws but
> also header comments saying “The RULES for the methods of class Arrow may
> never fire e.g. compose/arr; see Trac #10528”.
>
> I’d appreciate a reality check about my conclusions as well as any
> strategies for using class laws in optimization.
>
> Thanks, -- Conal
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] GHC 8.0.2 release candidate 2

[George Colpitts]

binary works fine also, same env, same testing as with compiled source

I did notice a very minor infelicity in the TOC for the pdf User's Guide. I
think it was there in rc1 also

The formatting seems to assume there are are never more than 3 digits on
lines such as the following and is missing a space when there are 4 digits,
e.g.

10.7 Pattern synonyms  . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . 267

10.8 Class and instances declarations  . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . 273

10.9 Type families  . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . 294

10.10Datatype promotion  . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . 308

10.11Kind polymorphism and Type-in-Type  . . . . . . . . . . . . . . . . .
. . . . . . . . . 311

10.12Runtime representation polymorphism  . .

On Thu, Dec 22, 2016 at 7:23 PM George Colpitts <george.colpi...@gmail.com>
wrote:

> compiled from source with no issues on Mac OS 10.12.2 with XCode 8.2.1.
> Compiled vector package with it, did some smoke testing of the runtime,
> seems fine
>
> On Thu, Dec 22, 2016 at 3:39 PM Ben Gamari <b...@well-typed.com> wrote:
>
>
> Hello everyone,
>
> The GHC team is happy to announce the second candiate of the
> 8.0.2 release of the Glasgow Haskell Compiler. Source and binary
> distributions are available at
>
> http://downloads.haskell.org/~ghc/8.0.2-rc2/
>
> This is the second and likely final release candidate leading up the
> 8.0.2 release. This release will fix a number of bugs found in 8.0.1
> including,
>
>   * Interface file build determinism (#4012).
>
>   * Compatibility with macOS Sierra and GCC compilers which compile
> position-independent executables by default
>
>   * Runtime linker fixes on Windows (see #12797)
>
>   * A compiler bug which resulted in undefined reference errors while
> compiling some packages (see #12076)
>
>   * Compatability with systems which use the gold linker
>
>   * A number of memory consistency bugs in the runtime system
>
>   * A number of efficiency issues in the threaded runtime which manifest
> on larger core counts and large numbers of bound threads.
>
>   * A typechecker bug which caused some programs using
> -XDefaultSignatures to be incorrectly accepted.
>
>   * More than two-hundred other bugs. See Trac [1] for a complete
> listing.
>
> This release candidate fixes a number of issues present in -rc1,
>
>   * #12757, which lead to broken runtime behavior and even crashes in
> the presence of primitive strings.
>
>   * #12844, a type inference issue affecting partial type signatures.
>
>   * A bump of the `directory` library, fixing buggy path
> canonicalization behavior (#12894). Unfortunately this required a
> major version bump in `directory` and minor bumps in several other
> libraries.
>
>   * #12912, where use of the `select` system call would lead to runtime
> system failures with large numbers of open file handles.
>
> If all goes well we should have a final 8.0.2 release out shortly after
> the new year. As always, let us know if you encounter trouble. Thanks to
> everyone who has contributed so far!
>
> Happy testing,
>
> - Ben
>
>
> [1]
> https://ghc.haskell.org/trac/ghc/query?status=closed=8.0.2=id=summary=status=type=priority=milestone=component=priority
> ___
> ghc-devs mailing list
> ghc-d...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] GHC 8.0.2 release candidate 2

[George Colpitts]

compiled from source with no issues on Mac OS 10.12.2 with XCode 8.2.1.
Compiled vector package with it, did some smoke testing of the runtime,
seems fine

On Thu, Dec 22, 2016 at 3:39 PM Ben Gamari  wrote:

>
> Hello everyone,
>
> The GHC team is happy to announce the second candiate of the
> 8.0.2 release of the Glasgow Haskell Compiler. Source and binary
> distributions are available at
>
> http://downloads.haskell.org/~ghc/8.0.2-rc2/
>
> This is the second and likely final release candidate leading up the
> 8.0.2 release. This release will fix a number of bugs found in 8.0.1
> including,
>
>   * Interface file build determinism (#4012).
>
>   * Compatibility with macOS Sierra and GCC compilers which compile
> position-independent executables by default
>
>   * Runtime linker fixes on Windows (see #12797)
>
>   * A compiler bug which resulted in undefined reference errors while
> compiling some packages (see #12076)
>
>   * Compatability with systems which use the gold linker
>
>   * A number of memory consistency bugs in the runtime system
>
>   * A number of efficiency issues in the threaded runtime which manifest
> on larger core counts and large numbers of bound threads.
>
>   * A typechecker bug which caused some programs using
> -XDefaultSignatures to be incorrectly accepted.
>
>   * More than two-hundred other bugs. See Trac [1] for a complete
> listing.
>
> This release candidate fixes a number of issues present in -rc1,
>
>   * #12757, which lead to broken runtime behavior and even crashes in
> the presence of primitive strings.
>
>   * #12844, a type inference issue affecting partial type signatures.
>
>   * A bump of the `directory` library, fixing buggy path
> canonicalization behavior (#12894). Unfortunately this required a
> major version bump in `directory` and minor bumps in several other
> libraries.
>
>   * #12912, where use of the `select` system call would lead to runtime
> system failures with large numbers of open file handles.
>
> If all goes well we should have a final 8.0.2 release out shortly after
> the new year. As always, let us know if you encounter trouble. Thanks to
> everyone who has contributed so far!
>
> Happy testing,
>
> - Ben
>
>
> [1]
> https://ghc.haskell.org/trac/ghc/query?status=closed=8.0.2=id=summary=status=type=priority=milestone=component=priority
> ___
> ghc-devs mailing list
> ghc-d...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: GHC rewrite rules for class operations & laws

[George Colpitts]

Do you want me to add a task ticket to remove this restriction that rewrite
rules can't be used for class methods?

On Tue, Nov 22, 2016 at 8:06 AM Simon Peyton Jones via
Glasgow-haskell-users  wrote:

> Conal
>
>
>
> Is it possible to apply GHC rewrite rules to class methods?
>
>
>
> Not currently.  See https://ghc.haskell.org/trac/ghc/ticket/11688, esp
> comment:7 which gives links to similar examples.
> https://ghc.haskell.org/trac/ghc/ticket/10528 comment:13  gives more
> background.
>
>
>
> It’d be great if someone wanted to think through all this.
>
>
>
> Simon
>
>
>
> *From:* Glasgow-haskell-users [mailto:
> glasgow-haskell-users-boun...@haskell.org] *On Behalf Of *Conal Elliott
> *Sent:* 17 November 2016 16:40
> *To:* glasgow-haskell-users@haskell.org
> *Subject:* GHC rewrite rules for class operations & laws
>
>
>
> Is it possible to apply GHC rewrite rules to class methods? From what I’ve
> read and seen, class methods get eliminated early by
> automatically-generated rules. Is there really no way to postpone such
> inlining until a later simplifier stage? The GHC Users Guide docs say no
> ,
> and suggests instead giving a duplicate vocabulary with somewhat awkward
> names for class methods. I’ve not seen this practice in libraries. I gather
> that we cannot therefore use class laws as optimizations in the form of
> rewrite rules, which seems a terrible loss.
>
> In Control.Category and Control.Arrow, I see rules for class laws but
> also header comments saying “The RULES for the methods of class Arrow may
> never fire e.g. compose/arr; see Trac #10528”.
>
> I’d appreciate a reality check about my conclusions as well as any
> strategies for using class laws in optimization.
>
> Thanks, -- Conal
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] GHC 8.0.2 release candidate 1

[George Colpitts]

I think I am very atypical as I had the Haskell Platform installed and did
an uninstall-hs before installing this release candidate. This is on the
latest Mac OS and Xcode.

At the time I got the error the file was a symbolic link, I believe to an
existing file:

install: /usr/local/share/man/man1/ghc.1: No such file or directory
make[1]: *** [install_man] Error 71
make: *** [install] Error 2
bash-3.2$  ls -l /usr/local/share/man/man1/ghc.1
lrwxr-xr-x  1 gcolpitts  admin  80 Jun 23 19:44
/usr/local/share/man/man1/ghc.1 ->
/Library/Frameworks/GHC.framework/Versions/8.0.1-x86_64/usr/share/man/man1/ghc.1
bash-3.2$  rm /usr/local/share/man/man1/ghc.1

Now after a successful install of the binary and a successful compile from
source I have:

ls -l /usr/local/share/man/man1/ghc.1
-rw-r--r--  1 root  admin  58932 Nov 26 09:16
/usr/local/share/man/man1/ghc.1
bash-3.2$ ls -l
/Library/Frameworks/GHC.framework/Versions/8.0.1-x86_64/usr/share/man/man1/ghc.1
ls -l
/Library/Frameworks/GHC.framework/Versions/8.0.1-x86_64/usr/share/man/man1/ghc.1
-rw-r--r--  1 root  wheel  58214 May 21  2016
/Library/Frameworks/GHC.framework/Versions/8.0.1-x86_64/usr/share/man/man1/ghc.1

After the binary install I did a cabal install of threadscope, hlint and
criterion and some minimal runtime testing. Everything looks fine.

Thanks
George

On Sat, Nov 26, 2016 at 9:47 AM Ben Gamari <b...@well-typed.com> wrote:

> George Colpitts <george.colpi...@gmail.com> writes:
>
> > Thanks Ben, this is great!
> >
> > Installing the binary on the Mac results in the following minor problem:
> >
> > /usr/bin/install -c -m 644  docs/users_guide/build-man/ghc.1
> > "/usr/local/share/man/man1"
> > install: /usr/local/share/man/man1/ghc.1: No such file or directory
> > make[1]: *** [install_man] Error 71
> > make: *** [install] Error 2
> >
> Thanks for the report, George! That is quite odd indeed. It sounds like
> /usr/local/share/man/man1/ghc.1 may have been a symlink to a directory
> which does not exist (possibly?). What does `ls -l
> /usr/local/share/man/man1/ghc.1` say now?
>
> Cheers,
>
> - Ben
>
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] GHC 8.0.2 release candidate 1

[George Colpitts]

Thanks Ben, this is great!

Installing the binary on the Mac results in the following minor problem:

/usr/bin/install -c -m 644  docs/users_guide/build-man/ghc.1
"/usr/local/share/man/man1"
install: /usr/local/share/man/man1/ghc.1: No such file or directory
make[1]: *** [install_man] Error 71
make: *** [install] Error 2

The error message is a bit confusing as the file does exist.
It is easily resolved by

 rm /usr/local/share/man/man1/ghc.1


I believe I encountered the same problem on ghc 8.0.1 rc1

Thanks
George




On Fri, Nov 25, 2016 at 6:39 PM Ben Gamari  wrote:

>
> Hello everyone,
>
> The GHC team is happy to (finally!) announce the first candiate of the
> 8.0.2 release of the Glasgow Haskell Compiler. Source and binary
> distributions are available at
>
> http://downloads.haskell.org/~ghc/8.0.2-rc1/
>
> This is the first of what will hopefully be only two release candidates
> leading up the final 8.0.2 release. This release will fix a number bugs
> found in 8.0.1 including,
>
>   * Interface file build determinism (#4012).
>
>   * Compatibility with macOS Sierra and GCC compilers which compile
> position-independent executables by default
>
>   * Runtime linker fixes on Windows (see #12797)
>
>   * A compiler bug which resulted in undefined reference errors while
> compiling some packages (see #12076)
>
>   * Compatability with systems which use the gold linker
>
>   * A number of memory consistency bugs in the runtime system
>
>   * A number of efficiency issues in the threaded runtime which manifest
> on larger core counts and large numbers of bound threads.
>
>   * A typechecker bug which caused some programs using
> -XDefaultSignatures to be incorrectly accepted.
>
>   * More than two-hundred other bugs. See Trac [1] for a complete
> listing.
>
> Unfortunately there is one known bug (#12757) which can result in
> runtime crashes which is still lurking in -rc1. This will be fixed in
> -rc2, which will be released in about a week.
>
> As always, let us know if you encounter trouble. Thanks to everyone who
> has contributed so far!
>
> Happy testing,
>
> - Ben
>
>
> [1]
> https://ghc.haskell.org/trac/ghc/query?status=closed=8.0.2=id=summary=status=type=priority=milestone=component=priority
> ___
> ghc-devs mailing list
> ghc-d...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

problem compiling GHC 8.0.1 release candidate 2 src on Apple

[George Colpitts]

"/usr/local/bin/ghc" -M -static  -H32m -O -Wall   -package-db
libraries/bootstrapping.conf  -this-unit-id terminfo-0.4.0.2
-hide-all-packages -i -ilibraries/terminfo/.
-ilibraries/terminfo/dist-boot/build
-ilibraries/terminfo/dist-boot/build/autogen
-Ilibraries/terminfo/dist-boot/build
-Ilibraries/terminfo/dist-boot/build/autogen -Ilibraries/terminfo/.
 -optP-include
-optPlibraries/terminfo/dist-boot/build/autogen/cabal_macros.h -package-id
base-4.9.0.0 -Wall -XHaskell2010   -no-user-package-db -rtsopts
-fno-warn-unused-imports -fno-warn-deprecated-flags  -odir
libraries/terminfo/dist-boot/build -hidir
libraries/terminfo/dist-boot/build -stubdir
libraries/terminfo/dist-boot/build -dep-makefile
libraries/terminfo/dist-boot/build/.depend-v.haskell.tmp -dep-suffix ""
-include-pkg-deps  libraries/terminfo/./System/Console/Terminfo.hs
 libraries/terminfo/./System/Console/Terminfo/Base.hs
 libraries/terminfo/./System/Console/Terminfo/Cursor.hs
 libraries/terminfo/./System/Console/Terminfo/Color.hs
 libraries/terminfo/./System/Console/Terminfo/Edit.hs
 libraries/terminfo/./System/Console/Terminfo/Effects.hs
 libraries/terminfo/./System/Console/Terminfo/Keys.hs
ghc: unrecognised flag: -this-unit-id

Usage: For basic information, try the `--help' option.
make[1]: *** [libraries/terminfo/dist-boot/build/.depend-v.haskell] Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [all] Error 2


 ghc --info
 [("Project name","The Glorious Glasgow Haskell Compilation System")
 ,("GCC extra via C opts"," -fwrapv -fno-builtin")
 ,("C compiler command","/usr/local/bin/gcc")
 ,("C compiler flags"," -m64 -fno-stack-protector")
 ,("C compiler link flags"," -m64")
 ,("Haskell CPP command","/usr/local/bin/gcc")
 ,("Haskell CPP flags","-E -undef -traditional")
 ,("ld command","/usr/bin/ld")
 ,("ld flags"," -arch x86_64")
 ,("ld supports compact unwind","YES")
 ,("ld supports build-id","NO")
 ,("ld supports filelist","YES")
 ,("ld is GNU ld","NO")
 ,("ar command","/usr/bin/ar")
 ,("ar flags","clqs")
 ,("ar supports at file","NO")
 ,("touch command","touch")
 ,("dllwrap command","/bin/false")
 ,("windres command","/bin/false")
 ,("libtool command","libtool")
 ,("perl command","/usr/bin/perl")
 ,("cross compiling","NO")
 ,("target os","OSDarwin")
 ,("target arch","ArchX86_64")
 ,("target word size","8")
 ,("target has GNU nonexec stack","False")
 ,("target has .ident directive","True")
 ,("target has subsections via symbols","True")
 ,("Unregisterised","NO")
 ,("LLVM llc command","llc")
 ,("LLVM opt command","opt")
 ,("Project version","8.0.0.20160111")
 ,("Project Git commit id","497454fc6610d67a2b2cd7902390c6497bddb483")
 ,("Booter version","7.10.2")
 ,("Stage","2")
 ,("Build platform","x86_64-apple-darwin")
 ,("Host platform","x86_64-apple-darwin")
 ,("Target platform","x86_64-apple-darwin")
 ,("Have interpreter","YES")
 ,("Object splitting supported","YES")
 ,("Have native code generator","YES")
 ,("Support SMP","YES")
 ,("Tables next to code","YES")
 ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn
thr_debug_dyn l_dyn thr_l_dyn")
 ,("RTS expects libdw","NO")
 ,("Support dynamic-too","YES")
 ,("Support parallel --make","YES")
 ,("Support reexported-modules","YES")
 ,("Support thinning and renaming package flags","YES")
 ,("Requires unified installed package IDs","YES")
 ,("Uses package keys","YES")
 ,("Dynamic by default","NO")
 ,("GHC Dynamic","YES")
 ,("GHC Profiled","NO")
 ,("Leading underscore","YES")
 ,("Debug on","False")
 ,("LibDir","/usr/local/lib/ghc-8.0.0.20160111")
 ,("Global Package DB","/usr/local/lib/ghc-8.0.0.20160111/package.conf.d")
 ]


On Sun, Feb 7, 2016 at 2:13 PM, Ben Gamari  wrote:

>
> Hello everyone,
>
> The GHC Team is very pleased to announce the second release candidate of
> the Glasgow Haskell Compiler 8.0.1 release. Source and binary
> distributions as well as the newly revised users guide and Haddock
> documentation can be found at
>
> http://downloads.haskell.org/~ghc/8.0.1-rc2/
>
> This is the second in a series of release candidates leading up to the
> 8.0.1
> release and fixes many of the issues reported in -rc1. These fixes
> include,
>
>   * A re-rewrite of the pattern checker by George Karachalias. The new
> checker should have far more predictable performance characteristics
> while sacrificing minimal reasoning power. This should resolve a
> large number of the issues felt in -rc1.
>
>   * Richard Eisenberg has been hammering out all manner of
> type-application- and TypeInType-related issues (#11335, #11416,
> #11405). There is still more work to do here, however (e.g. #11471).
>
>   * Matthew Pickering has restored support for multi-clause pattern
> synonyms (#11367)
>
>   * A latent bug in the constraint solver which popped up as a build
> failure in xmonad-contrib in -rc1 has been fixed (#11379)
>
>   * Dimitrios Vytiniotis and Simon Peyton Jones has been squashing a
> variety of older 

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

[George Colpitts]

Good news! I assume there will be a Mac OS binary distribution soon?

On Sun, Feb 7, 2016 at 2:13 PM, Ben Gamari  wrote:

>
> Hello everyone,
>
> The GHC Team is very pleased to announce the second release candidate of
> the Glasgow Haskell Compiler 8.0.1 release. Source and binary
> distributions as well as the newly revised users guide and Haddock
> documentation can be found at
>
> http://downloads.haskell.org/~ghc/8.0.1-rc2/
>
> This is the second in a series of release candidates leading up to the
> 8.0.1
> release and fixes many of the issues reported in -rc1. These fixes
> include,
>
>   * A re-rewrite of the pattern checker by George Karachalias. The new
> checker should have far more predictable performance characteristics
> while sacrificing minimal reasoning power. This should resolve a
> large number of the issues felt in -rc1.
>
>   * Richard Eisenberg has been hammering out all manner of
> type-application- and TypeInType-related issues (#11335, #11416,
> #11405). There is still more work to do here, however (e.g. #11471).
>
>   * Matthew Pickering has restored support for multi-clause pattern
> synonyms (#11367)
>
>   * A latent bug in the constraint solver which popped up as a build
> failure in xmonad-contrib in -rc1 has been fixed (#11379)
>
>   * Dimitrios Vytiniotis and Simon Peyton Jones has been squashing a
> variety of older type-checker bugs at a furious rate (#11458,
> #11248, #11330, #11408)
>
>   * Simon Peyton Jones has taught demand analysis to more precisely
> handle exceptions (#11222)
>
>   * Tamar Christina has added support for remote GHCi on Windows
> and resolved a long-standing linking issue (#11223)
>
>   * Loading of compiled modules needing shared library symbols now works
> in GHCi thanks to Peter Trommler (#10458)
>
>   * A variety of limitations in our implementation of Typeable
> implementation have been fixed (#11120) although there is still more
> to be done (#11334).
>
>   * A terrible failure of type inference due to visible type application
> has
> been fixed (#11458)
>
>   * InjectiveTypeFamilies has been renamed to TypeFamilyDependencies
>
>   * Custom type errors are now more robust (#11391) although there is
> still more work to be done (#11541)
>
>   * We now have a more conservative default warning set, as well as
> better mechanisms for managing warning changes in the future.
> (#11429, #11370)
>
>   * Compatibility with earlier Cabal versions should be a bit more
> robust.
>
>   * The user-facing interface of the (formerly "implicit") CallStack
> functionality has been reworked, hiding the implicit callstack
> parameter behind a constraint synonym.
>
>   * Online haddock documentation has been restored (#11419)
>
>   * We now offer xz archives exclusively
>
>   * A variety of miscellaneous bug-fixes have also been merged.
>
> All of these changes add up to nearly 200 commits in total. Given the
> large amount of churn between this candidate and -rc1, as well as the
> fact that there is at least one more significant patch pending (D1891,
> to fix #11471 and others), we will be releasing a third release
> candidate in a few weeks which should address more of the issues listed
> on the release status page [1]. Assuming things go well, we should be
> able to cut a final release by early March at the latest.
>
> All of the builds above were produced from the ghc-8.0.1-rc2 tag (commit
> e2230228906a1c0fa1f86a0c1aa18d87de3cc49d) *with the exception of the
> Windows builds*. Unfortunately, it was realized only too late that the
> tagged commit is broken on Windows. Consequently, the Windows builds
> were produced from the ghc-8.0.1-rc2 tag with two additional patches
> (commit 5b35c5509adb1311856faa0bc9767aec9ad5e9b7). While this would of
> course be completely unacceptable for a proper release, time constraints
> have meant that this was unfortunately the only viable option for this
> release candidate. We apologize for any confusion this may cause.
>
> At this point we are working very hard to nail the remaining bugs
> labelled as "highest" priority on the 8.0.1 status page [1]. If you have
> an issue which you'd like to see addressed in the release that does not
> appear in this list, please bring it to our attention.
>
> As always, we look forward to hearing about any issues that you
> encounter with this candidate. Thanks to everyone who has contributed so
> far!
>
> Cheers,
>
>  - Ben
>
>
> [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Increased memory usage with GHC 7.10.1

[George Colpitts]

I think this helps quite a bit. Although it still peaks briefly at over 3
GB mem usage on my Mac according to the Activity Monitor it seems to spend
much of its time using 400 - 800 mb memory use. I can't be sure as I never
tried to compile this before. I'm compiling by simply doing cabal install
 Not sure what optimization levels that uses, I assume -O1

On Sun, May 3, 2015 at 10:41 AM, Sven Panne svenpa...@gmail.com wrote:

 2015-05-02 12:01 GMT+02:00 Paolino paolo.verone...@gmail.com:
  Hello, I succeded in compiling
 
 https://hackage.haskell.org/package/OpenGLRaw-2.4.1.0/docs/src/Graphics-Rendering-OpenGL-Raw-Functions.html
  on a 32 bit machine with 2GB of memory with ghc 7.10.1. O_O

 To alleviate the pain a bit, I've uploaded a new version of OpenGLRaw
 (2.5.0.0) to Hackage, containing 2 improvements:

* 'foreign import dynamic's with the same signature are re-used,
 cutting down their number from 3062 to 864.

* Those 'foreign import dynamic's live in a separate module now.

 Travis CI seems to be happy with these changes (the VMs there don't
 have much memory, either), although Haddock still seems to eat memory
 like hell. But that's a different story...

 It would be nice to hear if the new version improved the situation for
 people who previous had trouble.
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

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

Re: Increased memory usage with GHC 7.10.1

[George Colpitts]

Should we recommend that all library developers compile their libraries
with a max heap of 4G (to pick an arbitrary number) so that we can catch
some of these issues earlier?

On Fri, May 1, 2015 at 5:42 AM, Paolino paolo.verone...@gmail.com wrote:

 Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now impossible
 with -O1 and -O2 due to ghc : out of memory error on a 4GB linux host.
 The file making memory explode is  Graphics.Rendering.OpenGL.Raw.Functions
 https://hackage.haskell.org/package/OpenGLRaw-2.4.1.0/docs/src/Graphics-Rendering-OpenGL-Raw-Functions.html.
 With -O0 it uses 600 MB.

 The file is really huge, but I could compile it with prior versions of ghc.

 Regards

 paolino

 2015-04-17 1:33 GMT+02:00 David Laing dave.laing...@gmail.com:

 Hi all,

 I've been playing around with profiling GHC recently, so I thought I'd
 chime in with a pointer that might save people searching for the right docs
 - you could configure a cabal sandbox to work with multiple version of ghc,
 which I've found useful:


 https://www.haskell.org/cabal/users-guide/installing-packages.html#sandboxes-advanced-usage

 Cheers,

 Dave

 On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta 
 michal.terep...@gmail.com wrote:

 Hi Richard,

 Thanks updating the ticket! What I did was: build GHC HEAD/7.8.4 with
 build flavor 'prof' then get the haskell-src-exts sources, install the
 dependencies and finally add +RTS -p -RTS to the cabal file and compile it,
 the resulting ghc.prof contains the profiling information.

 For anyone interested about CallArity slowness, the problem is tracked
 in https://ghc.haskell.org/trac/ghc/ticket/10293

 Cheers,
 Michal

 On Wed, Apr 15, 2015 at 1:40 AM Richard Eisenberg e...@cis.upenn.edu
 wrote:

 I've pasted Michal's numbers in #9630, which seems like a good place to
 track this. Michal, would you mind fleshing out a bit precisely what you
 did to get those numbers? That would be helpful (though you've already been
 very helpful indeed in getting the data together)!

 Thanks,
 Richard

 On Apr 14, 2015, at 9:09 PM, Joachim Breitner m...@joachim-breitner.de
 wrote:

  Hi,
 
  Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta:
  On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij
  christiaan.ba...@gmail.com wrote:
  Actually, I meant only with -fno-specialise.
 
  Done. Helps quite a bit but CallArity is still a pretty expensive.
 
  I’m on that, and I think I have a quite neat fix for it. I’ll report
 on
  that in the trac ticket:
  https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4
 
  Greetings,
  Joachim
 
  --
  Joachim “nomeata” Breitner
   m...@joachim-breitner.de • http://www.joachim-breitner.de/
   Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
   Debian Developer: nome...@debian.org
  ___
  Glasgow-haskell-users mailing list
  Glasgow-haskell-users@haskell.org
 
 http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

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


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



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



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


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

Re: Increased memory usage with GHC 7.10.1

[George Colpitts]

I'm curious why the amount of RAM is relevant as all of our OS have virtual
memory so it is only the size of the heap and the amount of swap that
should be relevant for an Out Of Memory error, right? How big is your heap?
Amount of RAM should only affect speed (i.e. if there is excessive paging)
but should not affect Out Of Memory right?

On Thu, Apr 2, 2015 at 9:47 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote:

 I will. But I was curious whether this is only me or is anyone else seeing
 similar behaviour. And
 what about performance comparisson between 7.8.4 and 7.10.1? Do we have
 any numbers?

 Janek

 Dnia czwartek, 2 kwietnia 2015, Richard Eisenberg napisał:
  Post a bug report! :)
 
  On Apr 2, 2015, at 8:19 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote:
   An update frrom my second machine, this time with 4GB of RAM. Compiling
   Agda ran out of memory (again Agda.TypeChecking.Serialise module) and I
   had to kill the build. But once I restarted the build the module was
   compiled succesfully in a matter of minutes and using around 50% of
   memory. This looks like some kind of memory leak in GHC.
  
   Janek
  
   Dnia środa, 1 kwietnia 2015, Jan Stolarek napisał:
   Forall hi,
  
   I just uprgaded both of my machines to use GHC 7.10.1. I keep
 sandboxed
   installations of GHC and this means I had to rebuild Agda and Idris
   because the binaries built with GHC 7.8.4 were stored inside
 deactivated
   7.8.4 sandbox. Sadly, I had problems building both Agda and Idris due
 to
   GHC taking up all of available memory.
  
   With Idris the problematic module was Idris.ElabTerm (~2900LOC). The
   interesting part of the story is that when I do a clean build of Idris
   GHC consumes all of memory when compiling that module and I have to
 kill
   the build. But when I restart the build after killing GHC the module
 is
   compiled using a reasonable amount of memory and within reasonable
 time.
  
   With Agda the problematic module is Agda.TypeChecking.Serialise
   (~2000LOC). The trick with killing the build and restarting it didn't
   work in this case. I had to compile Agda with GHC 7.8.4 (which works
   without problems though the mentioned module still requires a lot of
   memory) and alter my setup so that Agda binary is not stored inside
 GHC
   sandbox.
  
   I wonder if any of you came across similar issues with GHC 7.10.1? Do
 we
   have any performance data that allows to compare memory usage and
   performance of GHC 7.10.1 with previous stable releases?
  
   All of the above happened on 64bit Debian Wheezy with 2GB of RAM.
  
   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.
   ___
   Glasgow-haskell-users mailing list
   Glasgow-haskell-users@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.
   ___
   Glasgow-haskell-users mailing list
   Glasgow-haskell-users@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-d...@haskell.org
 http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 3

[George Colpitts]

Do we have an ETA for a MacOS binary distribution?

Regards
George

On Mon, Mar 16, 2015 at 5:30 PM, Austin Seipp aus...@well-typed.com wrote:

 We are pleased to announce the third release candidate for GHC 7.10.1:

 https://downloads.haskell.org/~ghc/7.10.1-rc3
 https://downloads.haskell.org/~ghc/7.10.1-rc3/docs/html/

 This includes the source tarball and bindists for Windows and Debian
 Linux. FreeBSD, CentOS and Mac OS X binary distributions will follow
 soon. These binaries and tarballs have an accompanying
 SHA256SUMS file signed by my GPG key id (0x3B58D86F).

 We plan to make the 7.10.1 final release at the end of this week - so
 please test as much as possible; bugs are much cheaper if we find them
 before the release!

 The list of issues we plan on fixing can always be found in an
 up-to-date form here:
 https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1

 --
 Regards,

 Austin Seipp, Haskell Consultant
 Well-Typed LLP, http://www.well-typed.com/
 ___
 ghc-devs mailing list
 ghc-d...@haskell.org
 http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 2

[George Colpitts]

Thanks Eric, I have the same problem with this as the RC2 I build from
source, i.e. Mac specific bug https://ghc.haskell.org/trac/ghc/ticket/10053
:

error in ghci calling main after loading compiled code -- Too late for
parseStaticFlags: call it before runGhc or runGhcT

I  have a file mainbug.hs that consists of

main =
print hello

I can reproduce it as follows:

 ghc -dynamic mainbug.hs
[1 of 1] Compiling Main ( mainbug.hs, mainbug.o )
Linking mainbug ...
bash-3.2$ ghci
GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/  :? for help
Prelude :load mainbug
Ok, modules loaded: Main.
Prelude Main :show modules
Main ( mainbug.hs, mainbug.o )
Prelude Main main
Too late for parseStaticFlags: call it before runGhc or runGhcT
*** Exception: ExitFailure 1

Loading it interpreted works fine:

rm mainbug.o
bash-3.2$ ghci
GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/  :? for help
Prelude :load mainbug
[1 of 1] Compiling Main ( mainbug.hs, interpreted )
Ok, modules loaded: Main.
*Main main
hello

Can anybody else reproduce this bug on their Mac?


On Mon, Feb 2, 2015 at 6:58 AM, Erik Hesselink hessel...@gmail.com wrote:

 On Mon, Feb 2, 2015 at 9:37 AM, Herbert Valerio Riedel h...@gnu.org
 wrote:
  Hi Mark,
 
  On 2015-01-28 at 04:31:29 +0100, Mark Lentczner wrote:
  I've just built a bindist under 10.10, but just normal not expressly
 llvm.
  I'll test this in a bit then post it -- but might be sometime tomorrow
  before it is up.
 
  How's progress on this btw? Are you also working on a GHC 7.8.4 OSX
  bindist by any chance?

 I made a bindist of RC2 (just like I did for RC1) which is here [1].
 This was built on 10.9, without anything special for llvm. If anyone
 wants me to try something or produce a different build, please let me
 know.

 Erik

 [1]
 https://docs.google.com/a/silk.co/uc?id=0B5E6EvOcuE0nVmJ3WElQZW81b1Uexport=download
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 2

[George Colpitts]

I have llvm 3.4.2. Not sure why I thought that was the supported version.
Where would that be documented? There doesn't seem to be anything on this
in
https://downloads.haskell.org/~ghc/7.10.1-rc1/docs/html/users_guide/release-7-10-1.html

There is lots of mail about llvm. I guess the following from Ben Gamari on
11/28 implies llvm 3.5. I couldn't find anything more definitive.

Once I get a definitive answer I will try again assuming the answer is not
3.4.2

To summarize,

  * it seems like LLVM 3.4 chokes on the code produced by my 3.5 rework
when the `$def` symbols are marked as internal

  * ARM is broken (again) due to a bug in the GHC calling convention
implementation; an LLVM fix is waiting to be merged

  * I have code reworking TNTC for LLVM 3.6; unfortunately LLVM 3.6
support will likely need to wait until 7.12

  * Austin's LLVM packaging proposal seems very much like the right way
forward

  * Anticipating this proposal, I have started collecting [2]
optimization passes

Cheers,



On Tue, Jan 27, 2015 at 9:52 PM, Carter Schonwald 
carter.schonw...@gmail.com wrote:

 George, what version of llvm are you using? afaik, only llvm 3.5 is
 supported for 7.10 (though I could be wrong)

 On Tue, Jan 27, 2015 at 8:39 PM, George Colpitts 
 george.colpi...@gmail.com wrote:

 Has anybody successfully build and used this on the Mac on 10.10 using
 the latest XCode? While it is better than RC1 I am still seeing the
 following two issues:


- programs compiled with llvm fail at runtime with illegal instruction
- calling main from the ghci inerpreter after loading compiled code
results in
- Prelude Main main
   Too late for parseStaticFlags: call it before runGhc or runGhcT
   *** Exception: ExitFailure 1

 Instead of solving the above, I'd be happy to switch to a Mac OS bindist
 and see if I have the same problems there. Do we have an ETA for a Mac OS
 bindist?


 Thanks

 George


 On Mon, Jan 26, 2015 at 8:13 PM, Austin Seipp aus...@well-typed.com
 wrote:

 We are pleased to announce the second release candidate for GHC 7.10.1:

 https://downloads.haskell.org/~ghc/7.10.1-rc2/

 This includes the source tarball and bindists for 64bit/32bit Linux
 and Windows. Binary builds for other platforms will be available
 shortly. (CentOS 6.5 binaries are not available at this time like they
 were for 7.8.x). These binaries and tarballs have an accompanying
 SHA256SUMS file signed by my GPG key id (0x3B58D86F).

 We plan to make the 7.10.1 release sometime in February of 2015.

 Please test as much as possible; bugs are much cheaper if we find them
 before the release!

 --
 Regards,

 Austin Seipp, Haskell Consultant
 Well-Typed LLP, http://www.well-typed.com/
 ___
 ghc-devs mailing list
 ghc-d...@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs



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



___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 2

[George Colpitts]

Has anybody successfully build and used this on the Mac on 10.10 using the
latest XCode? While it is better than RC1 I am still seeing the following
two issues:


   - programs compiled with llvm fail at runtime with illegal instruction
   - calling main from the ghci inerpreter after loading compiled code
   results in
   - Prelude Main main
  Too late for parseStaticFlags: call it before runGhc or runGhcT
  *** Exception: ExitFailure 1

Instead of solving the above, I'd be happy to switch to a Mac OS bindist
and see if I have the same problems there. Do we have an ETA for a Mac OS
bindist?


Thanks

George


On Mon, Jan 26, 2015 at 8:13 PM, Austin Seipp aus...@well-typed.com wrote:

 We are pleased to announce the second release candidate for GHC 7.10.1:

 https://downloads.haskell.org/~ghc/7.10.1-rc2/

 This includes the source tarball and bindists for 64bit/32bit Linux
 and Windows. Binary builds for other platforms will be available
 shortly. (CentOS 6.5 binaries are not available at this time like they
 were for 7.8.x). These binaries and tarballs have an accompanying
 SHA256SUMS file signed by my GPG key id (0x3B58D86F).

 We plan to make the 7.10.1 release sometime in February of 2015.

 Please test as much as possible; bugs are much cheaper if we find them
 before the release!

 --
 Regards,

 Austin Seipp, Haskell Consultant
 Well-Typed LLP, http://www.well-typed.com/
 ___
 ghc-devs mailing list
 ghc-d...@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - questions on Mac OS platform

[George Colpitts]

 at file,NO)
  ,(touch command,touch)
  ,(dllwrap command,/bin/false)
  ,(windres command,/bin/false)
  ,(libtool command,libtool)
  ,(perl command,/usr/bin/perl)
  ,(target os,OSDarwin)
  ,(target arch,ArchX86_64)
  ,(target word size,8)
  ,(target has GNU nonexec stack,False)
  ,(target has .ident directive,True)
  ,(target has subsections via symbols,True)
  ,(Unregisterised,NO)
  ,(LLVM llc command,llc)
  ,(LLVM opt command,opt)
  ,(Project version,7.10.0.20141222)
  ,(Project Git commit id,a8c556dfca3eca5277615cc2bf9d6c8f1f143c9a)
  ,(Booter version,7.8.3)
  ,(Stage,2)
  ,(Build platform,x86_64-apple-darwin)
  ,(Host platform,x86_64-apple-darwin)
  ,(Target platform,x86_64-apple-darwin)
  ,(Have interpreter,YES)
  ,(Object splitting supported,NO)
  ,(Have native code generator,YES)
  ,(Support SMP,YES)
  ,(Tables next to code,YES)
  ,(RTS ways,l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn
 thr_debug_dyn l_dyn thr_l_dyn)
  ,(Support dynamic-too,YES)
  ,(Support parallel --make,YES)
  ,(Support reexported-modules,YES)
  ,(Support thinning and renaming package flags,YES)
  ,(Uses package keys,YES)
  ,(Dynamic by default,NO)
  ,(GHC Dynamic,YES)
  ,(Leading underscore,YES)
  ,(Debug on,False)

  
 ,(LibDir,/Library/Frameworks/GHC.framework/Versions/7.10.0-rc1-x86_64/usr/lib/ghc-7.10.0.20141222)
  ,(Global Package

 DB,/Library/Frameworks/GHC.framework/Versions/7.10.0-rc1-x86_64/usr/lib/ghc-7.10.0.20141222/package.conf.d)
  ]

 On Sat, Jan 17, 2015 at 1:36 PM, George Colpitts
 george.colpi...@gmail.com wrote:
  Has anybody successfully used llvm on the Mac with 7.10.1 RC1? My
 problem is
  described below.
  Which is the recommended gcc to use when building source?
 
  GNU gcc  4.9.2
  Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
 
  When using ghci with 7.10.1 RC1 I get the following errors
 intermittently.
  Is anybody else seeing these?
 
  Too late for parseStaticFlags: call it before runGhc or runGhcT
  *** Exception: ExitFailure 1
  ld: library not found for -l:ghc31505_10.dylib
  collect2: error: ld returned 1 exit status
  phase `Linker' failed (exitcode = 1)
 
  Thanks
 
  On Fri, Jan 2, 2015 at 9:12 AM, George Colpitts 
 george.colpi...@gmail.com
  wrote:
 
  Only problem remaining is compiling with -fllvm and running resulting
  executable
 
  .
  ..
 
 
  llvm , compiling with llvm (3.4.2) gives the following warnings:
 
  $ ghc  -fllvm cubeFast.hs
  [1 of 1] Compiling Main ( cubeFast.hs, cubeFast.o )
  clang: warning: argument unused during compilation:
 '-fno-stack-protector'
  clang: warning: argument unused during compilation: '-D
  TABLES_NEXT_TO_CODE'
  clang: warning: argument unused during compilation: '-I .'
  clang: warning: argument unused during compilation: '-fno-common'
  clang: warning: argument unused during compilation: '-U __PIC__'
  clang: warning: argument unused during compilation: '-D __PIC__'
  Linking cubeFast ...
  running the resulting executable crashes (compiling without -fllvm gives
  no warnings and executable works properly)
   cat bigCube.txt | ./cubeFast  /dev/null
  Segmentation fault: 11
  Exception Type:EXC_BAD_ACCESS (SIGSEGV)
  Exception Codes:   KERN_INVALID_ADDRESS at 0xfffd5bfd8460
 
  ...
 
  Configuration details:
 
  Mac OS 10.10.1 (Yosemite)
   uname -a
  Darwin iMac27-5.local 14.0.0 Darwin Kernel Version 14.0.0: Fri Sep 19
  00:26:44 PDT 2014; root:xnu-2782.1.97~2/RELEASE_X86_64 x86_64
  llvm info:
   opt --version
  LLVM (http://llvm.org/):
LLVM version 3.4.2
Optimized build with assertions.
Built Oct 31 2014 (23:14:30).
Default target: x86_64-apple-darwin14.0.0
Host CPU: corei7
   gcc --version
  gcc (Homebrew gcc 4.9.1) 4.9.1
  Copyright (C) 2014 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.  There is
  NO
  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
  PURPOSE.
  /usr/bin/ghc --info
   [(Project name,The Glorious Glasgow Haskell Compilation System)
   ,(GCC extra via C opts, -fwrapv)
   ,(C compiler command,/usr/bin/gcc)
   ,(C compiler flags, -m64 -fno-stack-protector)
   ,(C compiler link flags, -m64)
   ,(Haskell CPP command,/usr/bin/gcc)
   ,(Haskell CPP flags,-E -undef -traditional -Wno-invalid-pp-token
  -Wno-unicode -Wno-trigraphs)
   ,(ld command,/usr/bin/ld)
   ,(ld flags, -arch x86_64)
   ,(ld supports compact unwind,YES)
   ,(ld supports build-id,NO)
   ,(ld supports filelist,YES)
   ,(ld is GNU ld,NO)
   ,(ar command,/usr/bin/ar)
   ,(ar flags,clqs)
   ,(ar supports at file,NO)
   ,(touch command,touch)
   ,(dllwrap command,/bin/false)
   ,(windres command,/bin/false)
   ,(libtool command,libtool)
   ,(perl command,/usr/bin/perl)
   ,(target os,OSDarwin)
   ,(target arch,ArchX86_64)
   ,(target word size,8)
   ,(target has GNU nonexec stack,False)
   ,(target has .ident directive,True)
   ,(target has subsections via symbols,True)
   ,(Unregisterised,NO)
   ,(LLVM llc command,llc)
   ,(LLVM

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - questions on Mac OS platform

[George Colpitts]

   - Has anybody successfully used llvm on the Mac with 7.10.1 RC1? My
   problem is described below.
   - Which is the recommended gcc to use when building source?
  - GNU gcc  4.9.2
  - Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
   - When using ghci with 7.10.1 RC1 I get the following errors
   intermittently. Is anybody else seeing these?
  - Too late for parseStaticFlags: call it before runGhc or runGhcT
  *** Exception: ExitFailure 1
  - ld: library not found for -l:ghc31505_10.dylib
  collect2: error: ld returned 1 exit status
  phase `Linker' failed (exitcode = 1)

​Thanks​

On Fri, Jan 2, 2015 at 9:12 AM, George Colpitts george.colpi...@gmail.com
wrote:

 Only problem remaining is compiling with -fllvm and running resulting
 executable

 ​.
 ​..​



- llvm , compiling with llvm (3.4.2) gives the following warnings:
   - $ ghc  -fllvm cubeFast.hs
   [1 of 1] Compiling Main ( cubeFast.hs, cubeFast.o )
   clang: warning: argument unused during compilation:
   '-fno-stack-protector'
   clang: warning: argument unused during compilation: '-D
   TABLES_NEXT_TO_CODE'
   clang: warning: argument unused during compilation: '-I .'
   clang: warning: argument unused during compilation: '-fno-common'
   clang: warning: argument unused during compilation: '-U __PIC__'
   clang: warning: argument unused during compilation: '-D __PIC__'
   Linking cubeFast ...
   - running the resulting executable crashes (compiling without
   -fllvm gives no warnings and executable works properly)
   -  cat bigCube.txt | ./cubeFast  /dev/null
   Segmentation fault: 11
   - Exception Type:EXC_BAD_ACCESS (SIGSEGV)
   Exception Codes:   KERN_INVALID_ADDRESS at 0xfffd5bfd8460


- ​...

 ​Configuration details:


- Mac OS 10.10.1 (Yosemite)
-  uname -a
Darwin iMac27-5.local 14.0.0 Darwin Kernel Version 14.0.0: Fri Sep 19
00:26:44 PDT 2014; root:xnu-2782.1.97~2/RELEASE_X86_64 x86_64
- llvm info:
-  opt --version
LLVM (http://llvm.org/):
  LLVM version 3.4.2
  Optimized build with assertions.
  Built Oct 31 2014 (23:14:30).
  Default target: x86_64-apple-darwin14.0.0
  Host CPU: corei7
-  gcc --version
gcc (Homebrew gcc 4.9.1) 4.9.1
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There
is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
- ​ /usr/bin/ghc --info
 [(Project name,The Glorious Glasgow Haskell Compilation System)
 ,(GCC extra via C opts, -fwrapv)
 ,(C compiler command,/usr/bin/gcc)
 ,(C compiler flags, -m64 -fno-stack-protector)
 ,(C compiler link flags, -m64)
 ,(Haskell CPP command,/usr/bin/gcc)
 ,(Haskell CPP flags,-E -undef -traditional -Wno-invalid-pp-token
-Wno-unicode -Wno-trigraphs)
 ,(ld command,/usr/bin/ld)
 ,(ld flags, -arch x86_64)
 ,(ld supports compact unwind,YES)
 ,(ld supports build-id,NO)
 ,(ld supports filelist,YES)
 ,(ld is GNU ld,NO)
 ,(ar command,/usr/bin/ar)
 ,(ar flags,clqs)
 ,(ar supports at file,NO)
 ,(touch command,touch)
 ,(dllwrap command,/bin/false)
 ,(windres command,/bin/false)
 ,(libtool command,libtool)
 ,(perl command,/usr/bin/perl)
 ,(target os,OSDarwin)
 ,(target arch,ArchX86_64)
 ,(target word size,8)
 ,(target has GNU nonexec stack,False)
 ,(target has .ident directive,True)
 ,(target has subsections via symbols,True)
 ,(Unregisterised,NO)
 ,(LLVM llc command,llc)
 ,(LLVM opt command,opt)
 ,(Project version,7.8.3)
 ,(Booter version,7.6.3)
 ,(Stage,2)
 ,(Build platform,x86_64-apple-darwin)
 ,(Host platform,x86_64-apple-darwin)
 ,(Target platform,x86_64-apple-darwin)
 ,(Have interpreter,YES)
 ,(Object splitting supported,YES)
 ,(Have native code generator,YES)
 ,(Support SMP,YES)
 ,(Tables next to code,YES)
 ,(RTS ways,l debug thr thr_debug thr_l thr_p dyn debug_dyn
thr_dyn thr_debug_dyn l_dyn thr_l_dyn)
 ,(Support dynamic-too,YES)
 ,(Support parallel --make,YES)
 ,(Dynamic by default,NO)
 ,(GHC Dynamic,YES)
 ,(Leading underscore,YES)
 ,(Debug on,False)

 
 ,(LibDir,/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3)
 ,(Global Package

 DB,/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3/package.conf.d)
 ]
- Not sure I found the correct instructions for building from
source,  I used the following:
   -

   $ autoreconf
   $ ./configure
   $ make
   $ make install




 On Tue, Dec 23, 2014 at 10:36 AM, Austin Seipp aus...@well-typed.com
 wrote:

 We are pleased to announce the first release candidate for GHC 7.10.1:

 https://downloads.haskell.org/~ghc/7.10.1-rc1/

 This includes

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - feedback on Mac OS

[George Colpitts]

Only problem remaining is compiling with -fllvm and running resulting
executable

Other problems below have now been solved:


   - cpphs - new version resolves problem
   - cabal install vector - upgrade to gcc (Homebrew gcc 4.9.2_1) 4.9.2
   solves problem


On Thu, Jan 1, 2015 at 9:58 AM, George Colpitts george.colpi...@gmail.com
wrote:

 I built from source on Mac OS and found the following issues:


- llvm , compiling with llvm (3.4.2) gives the following warnings:
   - $ ghc  -fllvm cubeFast.hs
   [1 of 1] Compiling Main ( cubeFast.hs, cubeFast.o )
   clang: warning: argument unused during compilation:
   '-fno-stack-protector'
   clang: warning: argument unused during compilation: '-D
   TABLES_NEXT_TO_CODE'
   clang: warning: argument unused during compilation: '-I .'
   clang: warning: argument unused during compilation: '-fno-common'
   clang: warning: argument unused during compilation: '-U __PIC__'
   clang: warning: argument unused during compilation: '-D __PIC__'
   Linking cubeFast ...
   - running the resulting executable crashes (compiling without
   -fllvm gives no warnings and executable works properly)
   -  cat bigCube.txt | ./cubeFast  /dev/null
   Segmentation fault: 11
   - Exception Type:EXC_BAD_ACCESS (SIGSEGV)
   Exception Codes:   KERN_INVALID_ADDRESS at 0xfffd5bfd8460


- ​cabal install vector fails:
- [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic (
   Data/Vector/Fusion/Stream/Monadic.hs,
   dist/build/Data/Vector/Fusion/Stream/Monadic.o )
   command line: can't load .so/.DLL for:
   
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.dylib
   
 (dlopen(/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.dylib,
   5): no suitable image found.  Did find:

   
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.dylib:
   mach-o, but wrong filetype)
- ​cabal install cpphs fails:​
-cabal install cpphs
   Resolving dependencies...
   Configuring cpphs-1.13...
   Building cpphs-1.13...
   Failed to install cpphs-1.13
   Build log ( /Users/gcolpitts/.cabal/logs/cpphs-1.13.log ):
   Warning: cpphs.cabal: Unknown fields: build-depends (line 5)
   Fields allowed in this section:
   name, version, cabal-version, build-type, license, license-file,
   license-files, copyright, maintainer, stability, homepage,
   package-url, bug-reports, synopsis, description, category, author,
   tested-with, data-files, data-dir, extra-source-files,
   extra-tmp-files, extra-doc-files
   Configuring cpphs-1.13...
   Building cpphs-1.13...
   Preprocessing library cpphs-1.13...
   - Language/Preprocessor/Cpphs.hs:1:1:
   Could not find module ‘Prelude’
   It is a member of the hidden package ‘base-4.8.0.0’.
   Perhaps you need to add ‘base’ to the build-depends in your
   .cabal file.
   Use -v to see a list of the files searched for.

   Language/Preprocessor/Cpphs/CppIfdef.hs:32:8:
   Could not find module ‘Numeric’
   It is a member of the hidden package ‘base-4.8.0.0’.
   Perhaps you need to add ‘base’ to the build-depends in your
   .cabal file.
   Use -v to see a list of the files searched for.

   Language/Preprocessor/Cpphs/CppIfdef.hs:33:8:
   Could not find module ‘System.IO.Unsafe’
   It is a member of the hidden package ‘base-4.8.0.0’.
   Perhaps you need to add ‘base’ to the build-depends in your
   .cabal file.
   Use -v to see a list of the files searched for.

   Language/Preprocessor/Cpphs/CppIfdef.hs:34:8:
   Could not find module ‘System.IO’
   It is a member of the hidden package ‘base-4.8.0.0’.
   Perhaps you need to add ‘base’ to the build-depends in your
   .cabal file.
   Use -v to see a list of the files searched for.

   Language/Preprocessor/Cpphs/MacroPass.hs:29:8:
   Could not find module ‘Control.Monad’
   It is a member of the hidden package ‘base-4.8.0.0’.
   Perhaps you need to add ‘base’ to the build-depends in your
   .cabal file.
   Use -v to see a list of the files searched for.

   Language/Preprocessor/Cpphs/MacroPass.hs:30:8:
   Could not find module ‘System.Time’
   Perhaps you meant
 System.CPUTime (needs flag -package-key base-4.8.0.0)
 System.Cmd (needs flag -package-key
   process-1.2.1.0@proce_ADbmNMhxdsoDn9NrOWjezu)
 System.Mem (needs flag -package-key base-4.8.0.0)
   Use -v to see a list of the files searched for.

   Language/Preprocessor/Cpphs/MacroPass.hs:31:8

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - feedback on Mac OS

[George Colpitts]

I built from source on Mac OS and found the following issues:


   - llvm , compiling with llvm (3.4.2) gives the following warnings:
  - $ ghc  -fllvm cubeFast.hs
  [1 of 1] Compiling Main ( cubeFast.hs, cubeFast.o )
  clang: warning: argument unused during compilation:
  '-fno-stack-protector'
  clang: warning: argument unused during compilation: '-D
  TABLES_NEXT_TO_CODE'
  clang: warning: argument unused during compilation: '-I .'
  clang: warning: argument unused during compilation: '-fno-common'
  clang: warning: argument unused during compilation: '-U __PIC__'
  clang: warning: argument unused during compilation: '-D __PIC__'
  Linking cubeFast ...
  - running the resulting executable crashes (compiling without -fllvm
  gives no warnings and executable works properly)
  -  cat bigCube.txt | ./cubeFast  /dev/null
  Segmentation fault: 11
  - Exception Type:EXC_BAD_ACCESS (SIGSEGV)
  Exception Codes:   KERN_INVALID_ADDRESS at 0xfffd5bfd8460


   - ​cabal install vector fails:
   - [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic (
  Data/Vector/Fusion/Stream/Monadic.hs,
  dist/build/Data/Vector/Fusion/Stream/Monadic.o )
  command line: can't load .so/.DLL for:
  
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.dylib
  
(dlopen(/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.dylib,
  5): no suitable image found.  Did find:

  
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.dylib:
  mach-o, but wrong filetype)
   - ​cabal install cpphs fails:​
   -cabal install cpphs
  Resolving dependencies...
  Configuring cpphs-1.13...
  Building cpphs-1.13...
  Failed to install cpphs-1.13
  Build log ( /Users/gcolpitts/.cabal/logs/cpphs-1.13.log ):
  Warning: cpphs.cabal: Unknown fields: build-depends (line 5)
  Fields allowed in this section:
  name, version, cabal-version, build-type, license, license-file,
  license-files, copyright, maintainer, stability, homepage,
  package-url, bug-reports, synopsis, description, category, author,
  tested-with, data-files, data-dir, extra-source-files,
  extra-tmp-files, extra-doc-files
  Configuring cpphs-1.13...
  Building cpphs-1.13...
  Preprocessing library cpphs-1.13...
  - Language/Preprocessor/Cpphs.hs:1:1:
  Could not find module ‘Prelude’
  It is a member of the hidden package ‘base-4.8.0.0’.
  Perhaps you need to add ‘base’ to the build-depends in your
  .cabal file.
  Use -v to see a list of the files searched for.

  Language/Preprocessor/Cpphs/CppIfdef.hs:32:8:
  Could not find module ‘Numeric’
  It is a member of the hidden package ‘base-4.8.0.0’.
  Perhaps you need to add ‘base’ to the build-depends in your
  .cabal file.
  Use -v to see a list of the files searched for.

  Language/Preprocessor/Cpphs/CppIfdef.hs:33:8:
  Could not find module ‘System.IO.Unsafe’
  It is a member of the hidden package ‘base-4.8.0.0’.
  Perhaps you need to add ‘base’ to the build-depends in your
  .cabal file.
  Use -v to see a list of the files searched for.

  Language/Preprocessor/Cpphs/CppIfdef.hs:34:8:
  Could not find module ‘System.IO’
  It is a member of the hidden package ‘base-4.8.0.0’.
  Perhaps you need to add ‘base’ to the build-depends in your
  .cabal file.
  Use -v to see a list of the files searched for.

  Language/Preprocessor/Cpphs/MacroPass.hs:29:8:
  Could not find module ‘Control.Monad’
  It is a member of the hidden package ‘base-4.8.0.0’.
  Perhaps you need to add ‘base’ to the build-depends in your
  .cabal file.
  Use -v to see a list of the files searched for.

  Language/Preprocessor/Cpphs/MacroPass.hs:30:8:
  Could not find module ‘System.Time’
  Perhaps you meant
System.CPUTime (needs flag -package-key base-4.8.0.0)
System.Cmd (needs flag -package-key
  process-1.2.1.0@proce_ADbmNMhxdsoDn9NrOWjezu)
System.Mem (needs flag -package-key base-4.8.0.0)
  Use -v to see a list of the files searched for.

  Language/Preprocessor/Cpphs/MacroPass.hs:31:8:
  Could not find module ‘System.Locale’
  Use -v to see a list of the files searched for.

  Language/Preprocessor/Cpphs/Options.hs:22:8:
  Could not find module ‘Data.Maybe’
  It is a member of the hidden package ‘base-4.8.0.0’.
  Perhaps you need to add ‘base’ to the build-depends in your
  .cabal file.
  Use -v to see a list of the files searched for.

  

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - problem with latest cabal-install

[George Colpitts]

following solves dependency problems, added a few more packages, thanks!

 cabal install
--allow-newer=base,bytestring,deepseq,unix,process,time,random -j3
cabal-install


On Thu, Jan 1, 2015 at 2:27 PM, George Colpitts george.colpi...@gmail.com
wrote:

 Thanks but that doesn't seem to work either:

  cabal install --allow-newer=base --allow-newer=bytestring,deepseq -j3
 cabal-install
 Resolving dependencies...
 cabal: Could not resolve dependencies:
 trying: cabal-install-1.20.0.6 (user goal)
 trying: base-4.8.0.0/installed-779... (dependency of
 cabal-install-1.20.0.6)
 next goal: process (dependency of cabal-install-1.20.0.6)
 rejecting: process-1.2.1.0/installed-2db... (conflict: unix==2.7.1.0,
 process
 = unix==2.7.1.0/installed-4ae...)
 trying: process-1.2.1.0
 next goal: directory (dependency of cabal-install-1.20.0.6)
 rejecting: directory-1.2.1.1/installed-b08... (conflict: directory =
 time==1.5.0.1/installed-c23..., cabal-install = time=1.1  1.5)
 rejecting: directory-1.2.1.0 (conflict: base==4.8.0.0/installed-779...,
 directory = base=4.5  4.8)
 rejecting: directory-1.2.0.1, 1.2.0.0 (conflict:
 base==4.8.0.0/installed-779..., directory = base=4.2  4.7)
 rejecting: directory-1.1.0.2 (conflict: base==4.8.0.0/installed-779...,
 directory = base=4.2  4.6)
 rejecting: directory-1.1.0.1 (conflict: base==4.8.0.0/installed-779...,
 directory = base=4.2  4.5)
 rejecting: directory-1.1.0.0 (conflict: base==4.8.0.0/installed-779...,
 directory = base=4.2  4.4)
 rejecting: directory-1.0.1.2, 1.0.1.1, 1.0.1.0, 1.0.0.3, 1.0.0.0 (conflict:
 process = directory=1.1  1.3)
 Dependency tree exhaustively searched.

 On Thu, Jan 1, 2015 at 2:15 PM, Mikhail Glushenkov 
 the.dead.shall.r...@gmail.com wrote:

 Hi,

 On 1 January 2015 at 19:00, George Colpitts george.colpi...@gmail.com
 wrote:
  Thanks, there seems to be dependency issues:

 Try also adding '--allow-newer=bytestring,deepseq'.



___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - problem with latest cabal-install

[George Colpitts]

Thanks but that doesn't seem to work either:

 cabal install --allow-newer=base --allow-newer=bytestring,deepseq -j3
cabal-install
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: cabal-install-1.20.0.6 (user goal)
trying: base-4.8.0.0/installed-779... (dependency of cabal-install-1.20.0.6)
next goal: process (dependency of cabal-install-1.20.0.6)
rejecting: process-1.2.1.0/installed-2db... (conflict: unix==2.7.1.0,
process
= unix==2.7.1.0/installed-4ae...)
trying: process-1.2.1.0
next goal: directory (dependency of cabal-install-1.20.0.6)
rejecting: directory-1.2.1.1/installed-b08... (conflict: directory =
time==1.5.0.1/installed-c23..., cabal-install = time=1.1  1.5)
rejecting: directory-1.2.1.0 (conflict: base==4.8.0.0/installed-779...,
directory = base=4.5  4.8)
rejecting: directory-1.2.0.1, 1.2.0.0 (conflict:
base==4.8.0.0/installed-779..., directory = base=4.2  4.7)
rejecting: directory-1.1.0.2 (conflict: base==4.8.0.0/installed-779...,
directory = base=4.2  4.6)
rejecting: directory-1.1.0.1 (conflict: base==4.8.0.0/installed-779...,
directory = base=4.2  4.5)
rejecting: directory-1.1.0.0 (conflict: base==4.8.0.0/installed-779...,
directory = base=4.2  4.4)
rejecting: directory-1.0.1.2, 1.0.1.1, 1.0.1.0, 1.0.0.3, 1.0.0.0 (conflict:
process = directory=1.1  1.3)
Dependency tree exhaustively searched.

On Thu, Jan 1, 2015 at 2:15 PM, Mikhail Glushenkov 
the.dead.shall.r...@gmail.com wrote:

 Hi,

 On 1 January 2015 at 19:00, George Colpitts george.colpi...@gmail.com
 wrote:
  Thanks, there seems to be dependency issues:

 Try also adding '--allow-newer=bytestring,deepseq'.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - problem with latest cabal-install

[George Colpitts]

​$ ​
cabal update
Downloading the latest package list from hackage.haskell.org
Note: *there is a new version of cabal-install available.*
To upgrade, run: cabal install cabal-install
bash-3.2$ *cabal install -j3 cabal-install *
*​...​*


*Resolving dependencies...cabal: Could not resolve dependencies:*
trying: cabal-install-1.20.0.6 (user goal)
trying: base-4.8.0.0/installed-779... (dependency of cabal-install-1.20.0.6)
next goal: process (dependency of cabal-install-1.20.0.6)
rejecting: process-1.2.1.0/installed-2db... (conflict: unix==2.7.1.0,
process
= unix==2.7.1.0/installed-4ae...)
trying: process-1.2.1.0
next goal: directory (dependency of cabal-install-1.20.0.6)
rejecting: directory-1.2.1.1/installed-b08... (conflict: directory =
time==1.5.0.1/installed-c23..., cabal-install = time=1.1  1.5)
rejecting: directory-1.2.1.0 (conflict: base==4.8.0.0/installed-779...,
directory = base=4.5  4.8)
rejecting: directory-1.2.0.1, 1.2.0.0 (conflict:
base==4.8.0.0/installed-779..., directory = base=4.2  4.7)
rejecting: directory-1.1.0.2 (conflict: base==4.8.0.0/installed-779...,
directory = base=4.2  4.6)
rejecting: directory-1.1.0.1 (conflict: base==4.8.0.0/installed-779...,
directory = base=4.2  4.5)
rejecting: directory-1.1.0.0 (conflict: base==4.8.0.0/installed-779...,
directory = base=4.2  4.4)
rejecting: directory-1.0.1.2, 1.0.1.1, 1.0.1.0, 1.0.0.3, 1.0.0.0 (conflict:
process = directory=1.1  1.3)
Dependency tree exhaustively searched.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - problem with latest cabal-install

[George Colpitts]

however still fails to install but now due to problems with cabal itself

[76 of 76] Compiling Main (
/var/folders/9b/rh4y2gy92hgdb6ktv4df1jv0gn/T/Cabal-1.20.0.3-62215/Cabal-1.20.0.3/dist/setup/setup.hs,
/var/folders/9b/rh4y2gy92hgdb6ktv4df1jv0gn/T/Cabal-1.20.0.3-62215/Cabal-1.20.0.3/dist/setup/Main.o
)
Linking
/var/folders/9b/rh4y2gy92hgdb6ktv4df1jv0gn/T/Cabal-1.20.0.3-62215/Cabal-1.20.0.3/dist/setup/setup
...
Configuring Cabal-1.20.0.3...
Building Cabal-1.20.0.3...
Preprocessing library Cabal-1.20.0.3...

on the commandline: Warning:
-package-name is deprecated: Use -this-package-key instead
ghc: ghc no longer supports single-file style package databases
(dist/package.conf.inplace) use 'ghc-pkg init' to create the database with
the correct format.
Updating documentation index
/Users/gcolpitts/Library/Haskell/share/doc/index.html
cabal: Error: some packages failed to install:
Cabal-1.20.0.3 failed during the building phase. The exception was:
ExitFailure 1
cabal-install-1.20.0.6 depends on Cabal-1.20.0.3 which failed to install.

On Thu, Jan 1, 2015 at 2:34 PM, George Colpitts george.colpi...@gmail.com
wrote:

 following solves dependency problems, added a few more packages, thanks!

  cabal install
 --allow-newer=base,bytestring,deepseq,unix,process,time,random -j3
 cabal-install


 On Thu, Jan 1, 2015 at 2:27 PM, George Colpitts george.colpi...@gmail.com
  wrote:

 Thanks but that doesn't seem to work either:

  cabal install --allow-newer=base --allow-newer=bytestring,deepseq -j3
 cabal-install
 Resolving dependencies...
 cabal: Could not resolve dependencies:
 trying: cabal-install-1.20.0.6 (user goal)
 trying: base-4.8.0.0/installed-779... (dependency of
 cabal-install-1.20.0.6)
 next goal: process (dependency of cabal-install-1.20.0.6)
 rejecting: process-1.2.1.0/installed-2db... (conflict: unix==2.7.1.0,
 process
 = unix==2.7.1.0/installed-4ae...)
 trying: process-1.2.1.0
 next goal: directory (dependency of cabal-install-1.20.0.6)
 rejecting: directory-1.2.1.1/installed-b08... (conflict: directory =
 time==1.5.0.1/installed-c23..., cabal-install = time=1.1  1.5)
 rejecting: directory-1.2.1.0 (conflict: base==4.8.0.0/installed-779...,
 directory = base=4.5  4.8)
 rejecting: directory-1.2.0.1, 1.2.0.0 (conflict:
 base==4.8.0.0/installed-779..., directory = base=4.2  4.7)
 rejecting: directory-1.1.0.2 (conflict: base==4.8.0.0/installed-779...,
 directory = base=4.2  4.6)
 rejecting: directory-1.1.0.1 (conflict: base==4.8.0.0/installed-779...,
 directory = base=4.2  4.5)
 rejecting: directory-1.1.0.0 (conflict: base==4.8.0.0/installed-779...,
 directory = base=4.2  4.4)
 rejecting: directory-1.0.1.2, 1.0.1.1, 1.0.1.0, 1.0.0.3, 1.0.0.0
 (conflict:
 process = directory=1.1  1.3)
 Dependency tree exhaustively searched.

 On Thu, Jan 1, 2015 at 2:15 PM, Mikhail Glushenkov 
 the.dead.shall.r...@gmail.com wrote:

 Hi,

 On 1 January 2015 at 19:00, George Colpitts george.colpi...@gmail.com
 wrote:
  Thanks, there seems to be dependency issues:

 Try also adding '--allow-newer=bytestring,deepseq'.




___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - problem with latest cabal-install

[George Colpitts]

I still have 7.8.3 but it doesn't seem to want to build the latest cabal:

 ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.8.3
bash-3.2$ cabal install cabal-install
Resolving dependencies...
Configuring cabal-install-1.20.0.6...
Building cabal-install-1.20.0.6...
Installed cabal-install-1.20.0.6
Updating documentation index
/Users/gcolpitts/Library/Haskell/share/doc/index.html




On Thu, Jan 1, 2015 at 2:54 PM, Edward Z. Yang ezy...@mit.edu wrote:

 If you still have your old GHC around, it will be much better to
 compile the newest cabal-install using the *old GHC*, and then
 use that copy to bootstrap a copy of the newest cabal-install.

 Edward

 Excerpts from George Colpitts's message of 2015-01-01 12:08:44 -0500:
  ​$ ​
  cabal update
  Downloading the latest package list from hackage.haskell.org
  Note: *there is a new version of cabal-install available.*
  To upgrade, run: cabal install cabal-install
  bash-3.2$ *cabal install -j3 cabal-install *
  *​...​*
 
 
  *Resolving dependencies...cabal: Could not resolve dependencies:*
  trying: cabal-install-1.20.0.6 (user goal)
  trying: base-4.8.0.0/installed-779... (dependency of
 cabal-install-1.20.0.6)
  next goal: process (dependency of cabal-install-1.20.0.6)
  rejecting: process-1.2.1.0/installed-2db... (conflict: unix==2.7.1.0,
  process
  = unix==2.7.1.0/installed-4ae...)
  trying: process-1.2.1.0
  next goal: directory (dependency of cabal-install-1.20.0.6)
  rejecting: directory-1.2.1.1/installed-b08... (conflict: directory =
  time==1.5.0.1/installed-c23..., cabal-install = time=1.1  1.5)
  rejecting: directory-1.2.1.0 (conflict: base==4.8.0.0/installed-779...,
  directory = base=4.5  4.8)
  rejecting: directory-1.2.0.1, 1.2.0.0 (conflict:
  base==4.8.0.0/installed-779..., directory = base=4.2  4.7)
  rejecting: directory-1.1.0.2 (conflict: base==4.8.0.0/installed-779...,
  directory = base=4.2  4.6)
  rejecting: directory-1.1.0.1 (conflict: base==4.8.0.0/installed-779...,
  directory = base=4.2  4.5)
  rejecting: directory-1.1.0.0 (conflict: base==4.8.0.0/installed-779...,
  directory = base=4.2  4.4)
  rejecting: directory-1.0.1.2, 1.0.1.1, 1.0.1.0, 1.0.0.3, 1.0.0.0
 (conflict:
  process = directory=1.1  1.3)
  Dependency tree exhaustively searched.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - problem with latest cabal-install

[George Colpitts]

Thanks, I seem to have got that to work

On Thu, Jan 1, 2015 at 3:37 PM, Edward Z. Yang ezy...@mit.edu wrote:

 Oh, because Cabal HQ hasn't cut a release yet.

 Try installing out of Git.  https://github.com/haskell/cabal/

 Edward

 Excerpts from George Colpitts's message of 2015-01-01 14:23:50 -0500:
  I still have 7.8.3 but it doesn't seem to want to build the latest cabal:
 
   ghc --version
  The Glorious Glasgow Haskell Compilation System, version 7.8.3
  bash-3.2$ cabal install cabal-install
  Resolving dependencies...
  Configuring cabal-install-1.20.0.6...
  Building cabal-install-1.20.0.6...
  Installed cabal-install-1.20.0.6
  Updating documentation index
  /Users/gcolpitts/Library/Haskell/share/doc/index.html
 
  On Thu, Jan 1, 2015 at 2:54 PM, Edward Z. Yang ezy...@mit.edu wrote:
 
   If you still have your old GHC around, it will be much better to
   compile the newest cabal-install using the *old GHC*, and then
   use that copy to bootstrap a copy of the newest cabal-install.
  
   Edward
  
   Excerpts from George Colpitts's message of 2015-01-01 12:08:44 -0500:
​$ ​
cabal update
Downloading the latest package list from hackage.haskell.org
Note: *there is a new version of cabal-install available.*
To upgrade, run: cabal install cabal-install
bash-3.2$ *cabal install -j3 cabal-install *
*​...​*
   
   
*Resolving dependencies...cabal: Could not resolve dependencies:*
trying: cabal-install-1.20.0.6 (user goal)
trying: base-4.8.0.0/installed-779... (dependency of
   cabal-install-1.20.0.6)
next goal: process (dependency of cabal-install-1.20.0.6)
rejecting: process-1.2.1.0/installed-2db... (conflict: unix==2.7.1.0,
process
= unix==2.7.1.0/installed-4ae...)
trying: process-1.2.1.0
next goal: directory (dependency of cabal-install-1.20.0.6)
rejecting: directory-1.2.1.1/installed-b08... (conflict: directory =
time==1.5.0.1/installed-c23..., cabal-install = time=1.1  1.5)
rejecting: directory-1.2.1.0 (conflict: base==
 4.8.0.0/installed-779...,
directory = base=4.5  4.8)
rejecting: directory-1.2.0.1, 1.2.0.0 (conflict:
base==4.8.0.0/installed-779..., directory = base=4.2  4.7)
rejecting: directory-1.1.0.2 (conflict: base==
 4.8.0.0/installed-779...,
directory = base=4.2  4.6)
rejecting: directory-1.1.0.1 (conflict: base==
 4.8.0.0/installed-779...,
directory = base=4.2  4.5)
rejecting: directory-1.1.0.0 (conflict: base==
 4.8.0.0/installed-779...,
directory = base=4.2  4.4)
rejecting: directory-1.0.1.2, 1.0.1.1, 1.0.1.0, 1.0.0.3, 1.0.0.0
   (conflict:
process = directory=1.1  1.3)
Dependency tree exhaustively searched.
  

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1

[George Colpitts]

Would it be possible to get a RC for the Mac up at
https://downloads.haskell.org/~ghc/7.8.4-rc1/ ?

Thanks
George


On Wed, Nov 26, 2014 at 10:31 AM, Herbert Valerio Riedel h...@gnu.org
wrote:

 On 2014-11-26 at 12:40:37 +0100, Sven Panne wrote:
  2014-11-25 20:46 GMT+01:00 Austin Seipp aus...@well-typed.com:
  We are pleased to announce the first release candidate for GHC 7.8.4:
 
  https://downloads.haskell.org/~ghc/7.8.4-rc1/ [...]
 
  Would it be possible to get the RC on
  https://launchpad.net/~hvr/+archive/ubuntu/ghc? This way one could
  easily test things on Travis CI.

 I'll put a 7.8.4rc .deb up soon (probably right after the GHC 7.10
 branch has been created)
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC 7.8.3 release

[George Colpitts]

+1

Stability is very important.

Also, do we have an ETA for when we will have an improved infrastructure
for automated builds and the associated tests. I think this would help a
lot with stability and  shorten the time to the next release.


On Fri, May 30, 2014 at 6:46 PM, Simon Marlow marlo...@gmail.com wrote:

 On 27/05/14 09:06, Austin Seipp wrote:

 PPS: This might also impact the 7.10 schedule, but last Simon and I
 talked, we thought perhaps shooting for ICFP this time (and actually
 hitting it) was a good plan. So I'd estimate on that a 7.8.4 might
 happen a few months from now, after summer.


 FWIW, I think doing 7.10 in October is way too soon.  Major releases
 create a large distributed effort for package maintainers and users, and
 there are other knock-on effects, so we shouldn't do them too often.  A lot
 of our users want stability, while many of them also want progress, and 12
 months between major releases is the compromise we settled on.

 The last major release slipped for various reasons, but I don't believe
 that means we should try to get back on track by having a short time
 between 7.8 and 7.10.  7.8 will be out of maintenance when it has only just
 made it into a platform release.

 Anyway, that's my opinion.  Of course if everyone says they don't mind a
 7.10 in October then I withdraw my objection :-)

 (as a data point, upgrading to 7.8 at work cost me three weeks, but we're
 probably a special case)

 Cheers,
 Simon


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

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Using Cabal to install terminfo-0.4.0.0 breaks GHC on Debian x86_64

[George Colpitts]

I was able to do cabal install of  terminfo, crypto and Yi on my mac with
ghc 7.8.2 and cabal 1.18.1.3
yi seems to work although I did very little with it


On Sun, Apr 13, 2014 at 12:08 PM, Ramin Honary ramin.hon...@gmail.comwrote:

 I am posting this to the mailing list, but it is a copy of a post I
 originally made on Haskell Reddit.


 http://www.reddit.com/r/haskell/comments/22wu92/problems_installing_ghc_782_on_debian_ubuntu_x86/


 My GHC is working fine now. But there seem to be some changes in either
 GHC 7.8.2 or Cabal-1.18.1.3 that have broken some of the older packages in
 Hackage.

 *TL;DR* I discovered the Crypto-4.2.5.1 package is broken, and trying to
 install terminfo-0.4.0.0 breaks GHC by over-writing the terminfo library
 that came with the GHC tarball because isn't in the GHC package registry.

 I downloaded the binary distribution from here:


 https://www.haskell.org/ghc/dist/7.8.2/ghc-7.8.2-x86_64-unknown-linux-deb7.tar.bz2

 and then immediately began re-building all of the packages in my
 .cabal/packages/hackage.haskell.org/ direcotry.

 I admit, all of my problems may be due to my Cabal config, but I haven't
 had any problems with it before this, as far as I know it is the default
 setup the option to build profiling libraries set to True.

 The first problem I had was that Crypto-2.5.4.1 was not building files
 correctly. *Some* of shared object files *.dyn_o were being built
 *without* their accompanying *.dyn_hi files, although some of the
 *.dyn_hi files did exist). When cabal tried to copy these *.dyn_hi
 files to the global package registry during installation it would fail with
 something about (for example) could not find RSA.dyn_hi. To solve this, I
 rebuilt every *.dyn_o file that did not have an accompanying *.dyn_hi
 by hand using the command

 ghc -dynamic --make Codec.Binary.RSA

 The resulting Codec/Binary/RSA.hi file was actually a dynamic interface
 file but it's file extension was just .hi for some reason, (I double
 checked by using ghc --show-iface) so I just copied it it the
 dist/build/Codec/Binary/ directory. I did this for every *.hi file that
 was supposed to be named *.dyn_hi. This included about 10 files. Again,
 some *.dyn_o did build correctly with an accompanying *.dyn_hi, about
 10 of the modules were built incorrectly, all the rest were OK.

 The second problem I had was with installing Yi which relies on the
 terminfo-0.4.0.0 package. The terminfo library that came with the GHC
 7.8.2 binary distribution does not show up in the output of ghc-pkg list,
 so Cabal tries to build it thinking it doesn't exist, and it overwrites the
 existing terminfo-0.4.0.0 package with a library that contains missing
 symbols. This causes GHC to completely stop working. The ghc program
 immediately fails with an error:

 symbol lookup error: 
 /usr/local/lib/ghc-7.8.2/bin/../haskeline-0.7.1.2/libHShaskeline-0.7.1.2-ghc7.8.2.so:
  \
 undefined symbol: 
 terminfozm0zi4zi0zi0_SystemziConsoleziTerminfoziCursor_moveDown5_info

 I was able to solve this problem by simply copying the contents of:

 ghc-7.8.2/libraries/terminfo/dist-install/build/*

 from the source distribution tarball to the GHC installation directory:

 /usr/local/lib/ghc-7.8.2/terminfo-0.4.0.0/

 and that solved the problem. But any program depending on terminfo
 simply will not install properly. The terminfo-0.4.0.0 package does not
 show up in the output of ghc-pkg list, even though it comes with the GHC
 7.8.2 tarball and GHC relies on it. Attempting to install Terminfo will
 build a .so file that GHC cannot use. *So don't install
 terminfo-0.4.0.0 from Hackage.*

 Fortunately, Yi is not something that is absolutely necessary. I was able
 to install every other package I needed (lens, diagrams, yesod, xmonad,
 gtk) without incident.

 But whatever changes have been made in ghc-7.8.2 and the accompanying
 Cabal-1.18.1.3 seem to have broken some of the older Hackage packages.

 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: 7.8.1, template haskell, and dynamic libraries

[George Colpitts]

Yes, in general I think the doc needs a section: Incompatible changes. The
hope is that you can take the release and just work as usual but when (for
good reasons as in this release) it is not true is is important to have
such a section. Another case that needs to be there is how to compile so
you can load compile object files into ghci as what you did in 7.6.3 won't
work in this release.


On Sun, Feb 9, 2014 at 1:11 PM, Carter Schonwald carter.schonw...@gmail.com
 wrote:

 Indeed. The problem is that many folks might have cabal config files that
 explicitly disable shared.  (For the compile times!).  They might need
 clear information about wiping that field.


 On Sunday, February 9, 2014, Brandon Allbery allber...@gmail.com wrote:

 On Sun, Feb 9, 2014 at 9:28 AM, Greg Horn gregmainl...@gmail.com wrote:

 Is --enable-shared off by default?

 It's supposed to be on by default in 7.8. That said, not sure how many
 people have played with ~/.cabal/config

 --
 brandon s allbery kf8nh   sine nomine
 associates
 allber...@gmail.com
 ballb...@sinenomine.net
 unix, openafs, kerberos, infrastructure, xmonad
 http://sinenomine.net


 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1

[George Colpitts]

wrt existing issues, is there a list of these so we can avoid reporting
them?

Thanks
George



On Mon, Feb 3, 2014 at 6:35 PM, Austin Seipp aus...@well-typed.com wrote:

 We are pleased to announce the first release candidate for GHC 7.8.1:

 http://www.haskell.org/ghc/dist/7.8.1-rc1/
 http://www.haskell.org/ghc/docs/7.8.1-rc1/html/

 This includes the source tarball and bindists for Windows, Linux, OS
 X, FreeBSD, and Solaris, on x86 and x86_64. There is a signed copy of
 the SHA256 hashes available (attached) using my GPG key (keyid
 0x3B58D86F).

 We plan to make the 7.8.1 RC2 release quite soon, as we're aware of
 some existing issues.

 Please test as much as possible; bugs are much cheaper if we find them
 before the release!

 --
 Regards,

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

 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users