Re: Can't build GHC any more

[Brandon Allbery]

I can confirm that recent ghc doesn't work with 9.6.x. I upgraded my
updater/booter script to configure with 9.10.1 and the build was much
happier,

On Tue, Oct 22, 2024 at 9:38 AM Sebastian Graf  wrote:

> It is likely that anyone who cannot reproduce the issue is using a boot
> compiler > 9.6.2.
> I think Simon has the exact same issue I was having, so !13469 is a cure.
>
> Am Di., 22. Okt. 2024 um 13:33 Uhr schrieb Hécate via ghc-devs <
> ghc-devs@haskell.org>:
>
>> I can confirm that using my good old update() function in the
>> repository, I don't encounter the problem (but also I clean the tree all
>> the time):
>>
>> update () {
>>  git pull upstream master
>>  git submodule update --recursive
>> }
>>
>> Le 22/10/2024 à 12:54, Mikolaj Konarski a écrit :
>> > Maybe
>> >
>> > git submodule update --init --recursive
>> >
>> > would help, as said in
>> > https://gitlab.haskell.org/ghc/ghc/-/wikis/building/getting-the-sources
>> ?
>> >
>> > If not that, a "hadrian/build distclean" maybe?
>> >
>> > On Tue, Oct 22, 2024 at 12:34 PM Simon Peyton Jones
>> >  wrote:
>> >> Friends
>> >>
>> >> On all my builds, using
>> >> ./boot; ./configure; ./hadrian/build
>> >> I am getting the crash below. What should I do?  My boot compiler is
>> ghc-9.6.
>> >>
>> >> I can't build GHC at all right now, so this is somewhat urgent.
>> >>
>> >> Thank you!
>> >>
>> >> Simon
>> >>
>> >>
>> >> ]0;Running for 5m11s [11771/39023], predicted 49s
>> (86%)(/home/simonpj/code/HEAD) ]0;Running for 5m16s [11771/39023],
>> predicted 49s (86%)(/home/simonpj/code/HEAD)
>> >> ghc/GHCi/UI.hs:1704:5: warning: [GHC-53633] [-Woverlapping-patterns]
>> >>  Pattern match is redundant
>> >>  In a case alternative: _ -> ...
>> >>   |
>> >> 1704 | _ -> pure ()
>> >>   | 
>> >> | Run Ghc CompileHs (Stage0 InTreeLibs): ghc/Main.hs =>
>> _build/stage0/ghc/build/Main.o
>> >> | Run Ghc LinkHs (Stage0 InTreeLibs): _build/stage0/ghc/build/Main.o
>> (and 6 more) => _build/stage0/bin/ghc
>> >> Command line: /home/simonpj/.ghcup/bin/ghc -Wall -Wcompat -hisuf hi
>> -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db
>> '-package-env -' '-package-db _build/stage0/lib/package.conf.d'
>> '-this-unit-id ghc-bin-9.13.20241015-inplace' '-this-package-name ghc-bin'
>> '-package-id array-0.5.5.0' '-package-id base-4.18.0.0' '-package-id
>> bytestring-0.11.4.0' '-package-id containers-0.6.7' '-package-id
>> deepseq-1.4.8.1' '-package-id directory-1.3.9.0-inplace' '-package-id
>> exceptions-0.10.7' '-package-id filepath-1.5.2.0-inplace' '-package-id
>> ghc-9.13-inplace' '-package-id ghc-boot-9.13-inplace' '-package-id
>> ghc-prim-0.10.0' '-package-id ghci-9.13-inplace' '-package-id
>> haskeline-0.8.2.1' '-package-id process-1.6.25.0-inplace' '-package-id
>> time-1.14-inplace' '-package-id transformers-0.6.1.0' '-package-id
>> unix-2.8.5.1-inplace' -i -i/home/simonpj/code/HEAD/_build/stage0/ghc/build
>> -i/home/simonpj/code/HEAD/_build/stage0/ghc/build/ghc/autogen
>> -i/home/simonpj/code/HEAD/ghc -I_build/stage0/ghc/build
>> -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/process-1.6.17.0/include
>> -I/home/simonpj/code/HEAD/compiler
>> -I/home/simonpj/code/HEAD/_build/stage0/compiler/build
>> -I/home/simonpj/code/HEAD/libraries/process/include
>> -I/home/simonpj/code/HEAD/_build/stage0/libraries/process/build/include
>> -I/home/simonpj/code/HEAD/libraries/directory
>> -I/home/simonpj/code/HEAD/_build/stage0/libraries/directory/build
>> -I/home/simonpj/code/HEAD/libraries/unix/include
>> -I/home/simonpj/code/HEAD/_build/stage0/libraries/unix/build/include
>> -I/home/simonpj/code/HEAD/libraries/time/lib/include
>> -I/home/simonpj/code/HEAD/_build/stage0/libraries/time/build/lib/include
>> -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/directory-1.3.8.1/include
>> -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/include
>> -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/time-1.12.2/include
>> -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/bytestring-0.11.4.0/include
>> -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/base-4.18.0.0/include
>> -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/ghc-bignum-1.3/include
>> -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/rts-1.0.2/include
>> -optP-include -optP_build/stage0/ghc/build/ghc/autogen/cabal_macros.h
>> -optP-DHAVE_INTERNAL_INTERPRETER -outputdir _build/stage0/ghc/build
>> -fdiagnostics-color=always -Wall -Wnoncanonical-monad-instances
>> -Wnoncanonical-monoid-instances -rtsopts=all '-with-rtsopts=-K512M -H -I5
>> -T' -threaded -XGHC2021 -XNoImplicitPrelude -XScopedTypeVariables
>> -XBangPatterns -no-auto-link-packages -rtsopts -optc-Wno-error=inline
>> _build/stage0/ghc/build/Main.o _build/stage0/ghc/build/GHCi/Leak.o
>> _build/stage0/ghc/bu

Re: New GitLab account approval

[Brandon Allbery]

Approved.

On Sun, Sep 22, 2024 at 8:10 AM Мария Мухина  wrote:

> Hello,
>
> I would like to get my GitLab account approved.
> My username is maria.
>
> Best regards,
> Maria
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: HIE using ideclImplicit

[Brandon Allbery]

Anyone with comments?

On Sat, Aug 10, 2024 at 10:50 PM Brandon Allbery 
wrote:

> I've been sitting on a potential proposal to enable per-import disabling
> of -Wunused-imports and -Wmissing-import-lists for a while now, and
> https://mail.haskell.org/pipermail/haskell-cafe/2024-August/136852.html
> has me thinking of moving forward with it.
>
> It turns out that this would be very easy to implement within ghc, as the
> ideclImplicit field of ideclExt (itself a field of ImportDecl) already does
> what's needed; it exists to track the implicit Prelude import, and would be
> almost trivial to set when parsing an import. I did a check to see if
> anything used it as a proxy for "this is the Prelude", and everything that
> wants that explicitly looks for the Prelude module, with one exception: HIE
> information excludes anything from an import with ideclImplicit set.
>
> My questions are:
> 1. Is this (omitting imports with ideclImplicit) even sane? What happens
> with HIE information when Prelude definitions are used in the module?
> 2. Is this use of ideclImplicit going to cause problems with my proposed
> use?
> 2a. Should HIE be checking explicitly for Prelude as other things do, or
> is it more correct for other imports with ideclImplicit set to be treated
> the same way?
>
> --
> brandon s allbery kf8nh
> allber...@gmail.com
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

HIE using ideclImplicit

[Brandon Allbery]

I've been sitting on a potential proposal to enable per-import disabling of
-Wunused-imports and -Wmissing-import-lists for a while now, and
https://mail.haskell.org/pipermail/haskell-cafe/2024-August/136852.html has
me thinking of moving forward with it.

It turns out that this would be very easy to implement within ghc, as the
ideclImplicit field of ideclExt (itself a field of ImportDecl) already does
what's needed; it exists to track the implicit Prelude import, and would be
almost trivial to set when parsing an import. I did a check to see if
anything used it as a proxy for "this is the Prelude", and everything that
wants that explicitly looks for the Prelude module, with one exception: HIE
information excludes anything from an import with ideclImplicit set.

My questions are:
1. Is this (omitting imports with ideclImplicit) even sane? What happens
with HIE information when Prelude definitions are used in the module?
2. Is this use of ideclImplicit going to cause problems with my proposed
use?
2a. Should HIE be checking explicitly for Prelude as other things do, or is
it more correct for other imports with ideclImplicit set to be treated the
same way?

-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

submodules update warning?

[Brandon Allbery]

I got several of these while updating my local ghc checkout:
```
Fetching submodule libraries/binary
remote: error: MIDX does not contain the BTMP chunk
remote: warning: unable to load pack:
'pack-1d2d40f15dad726ad220801f9d5bd5b527bc7493.idx', disabling pack-reuse

>From https://gitlab.haskell.org/ghc/packages/binary
 * [new branch]  wip/edsko  -> origin/wip/edsko
```
Is this something I need to worry about?
-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Cabal woe

[Brandon Allbery]

You can also `cabal init -n` to get a minimal cabal file, then `cabal repl
-b primitive` or whatever.

On Tue, Jul 9, 2024 at 10:12 AM Oleg Grenrus  wrote:

>
> On 9.7.2024 15.23, Sebastian Graf wrote:
> > I can't simply pass `-fforce-recomp -ddump-simpl -O`
>
> You can, `cabal build --ghc-options= "-fforce-recomp -ddump-simpl -O"`
> should work (though it applies to all packages).
>
>  > and remember all the fields that need to be set. (
>
> `cabal init` is your friend. That said, there are very little fields to
> be set for minimal package, `cabal-version, name, version` and the
> library pragma with `build-depends` and `exposed-modules`.
>
> After you have done such package few times, you will remember those
> easily. I'd argue a lot more easily that remembering how to use `cabal
> install --lib` properly.
>
> - Oleg
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: BoxedRep UNPACK pragma

[Brandon Allbery]

The warning sounds correct to me: `Maybe` has two constructors?

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



-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GitLab partial outage - attempting to mitigate

[Brandon Allbery]

Isn't it just "move /nix out of the way, bind mount a new one from a
larger drive, use rsync to move the data"?

On Mon, Mar 20, 2023 at 9:25 AM Ben Gamari  wrote:
>
> Bryan Richter via ghc-devs  writes:
>
> > I eventually resorted to a server reboot, which cleared up all the problems
> > I was seeing. I think we're back in business.
> >
> The root partition was close to running out of disk space yesterday. The
> problem appears to be that /nix is located on the small system drive. We
> should really address this although moving /nix is sadly not easy and
> will certainly require downtime.
>
> Cheers,
>
> - Ben
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Installing GHC on my MacBook Air

[Brandon Allbery]

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 
>  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 
>>  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  
>>> 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 
  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 
>  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-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

`ideclImplicit` in compiler/GHC/Iface/Ext/Ast.hs?

[Brandon Allbery]

I'm researching a potential GHC proposal to allow "Prelude-like"
imports, which in practice means silencing warnings about implicit use
of symbols from them (-Wmissing-import-lists and similar).

So far, it looks like `ideclImplicit` does almost exactly what I want
and all I need is syntax to set it on imports other than the implicit
Prelude import. With one notable exception: around
compiler/GHC/Iface/Ext/Ast.hs line 326 (HEAD as of Saturday) there is
a use that appears to intend to exclude the implicit Prelude import,
without conditionalizing on Prelude like e.g.
compiler/GHC/Tc/Module.hs lines 1685--1687. I have several questions
about it.

1. The implicit import, but not explicit imports, are excluded from
the extended .hi file? This seems wrong-ish to me; I'm wondering if
it's actually looking to do something else such as strip it down to
only the symbols in use. But I don't really know what the code here is
supposed to do.

2. Should other "implicit" imports also be excluded the same way?

-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Milestones page is missing or has inaccurate dates

[Brandon Allbery]

I think 9.2.4 got released early because of
https://gitlab.haskell.org/ghc/ghc/-/issues/21708, and the milestone
needs to be updated.

On Thu, Oct 13, 2022 at 7:57 AM George Colpitts
 wrote:
>
> Hi Ben
>
> Thanks for the very quick response which addresses my concerns ! However I'm 
> confused by
>
> my colleague Zubin will be working on 9.2.4 next week, hopefully for
>release the following week
>
> Zubin sent mail on July 28th with a subject line of  "[Haskell] [ANNOUNCE] 
> GHC 9.2.4 released". I'm running it
>
>  $ ghc --version
> The Glorious Glasgow Haskell Compilation System, version 9.2.4
>
> Thanks again
> George
>
> On Wed, Oct 12, 2022 at 8:51 PM Ben Gamari  wrote:
>>
>> George Colpitts  writes:
>>
>> > Hi
>> >
>> > The Milestones page  is
>> > missing many dates or has inaccurate dates:
>> >
>> >- Most milestones don't have any associated completion date.
>> >- As far as I know 9.4.2 and 9.2.4 are released but the milestones pages
>> >doesn't seem to show that.
>> >
>> > Can the page be updated so we have an idea of what is coming when?
>> >
>> > There has been a lot of great work done and I know a lot is being worked
>> > on. It would be great if the milestones page could be updated to better
>> > reflect that.
>> >
>> I have updated the dates of 9.4.2, 9.4.3, 9.2.4, and 9.6.1. In short,
>>
>>  * 9.6.1 is scheduled for some time in January 2023; we plan to fork for
>>this release next month
>>
>>  * I am actively working on backports for 9.4.3 as we speak
>>
>>  * my colleague Zubin will be working on 9.2.4 next week, hopefully for
>>release the following week
>>
>>  * 9.4.2 was released in late August
>>
>> There are quite a few other milestones which lack dates; for the most
>> part these are releases which don't have a formal timeline yet.
>>
>> Cheers,
>>
>>  - Ben
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: A macOS static linking mystery

[Brandon Allbery]

One peculiarity with the ordering is that linkers only search static
archives for existing undefined references. If the reference to `Cffi`
actually comes first, then nothing should be required from it yet and
*it shouldn't be linked* (absent options like GNU ld's
`--whole-archive`).

This said, ghc also passes a bunch of explicitly undefined symbols
(`-Wl,-u…`) to ld; if those include symbols from `-lCffi` then it will
in fact be linked in.

On Tue, Aug 9, 2022 at 9:59 PM Ryan Scott  wrote:
>
> I believe I've figured out what is happening here. This will take a bit of 
> explanation, so bear with me.
>
> First, it's important to note that this behavior depends on whether your GHC 
> was configured with the `--with-system-libffi` flag or not. If it was 
> configured with this flag, then GHC will always link against your system's 
> version of libffi, and the behavior seen in this thread would not occur. I am 
> using a bindist provided by ghcup which was _not_ configured with 
> `--with-system-libffi`, so GHC bundles its own copy of libffi. Interestingly, 
> there appear to be at least two copies of libffi that are bundled: one 
> dynamic library, simply named libffi.dylib, and one static library, which is 
> named libCffi.a [1]. Remember the name libCffi.a, since it will come up again 
> later.
>
> Next, let's take a look at how GHC performs the final linking step when 
> compiling an executable. GHC will call the C compiler to perform this final 
> linking step, which will have roughly the following shape on macOS:
>
> gcc ... -L/rts  -lCffi  
> -Wl,-dead_strip_dylibs -o Main
>
> I'm omitting quite a few details here, but the important bits are that (1) 
> -lCffi comes before any of the C libraries listed in an `extra-libraries` 
> stanza in a .cabal file, and (2) GHC on macOS will pass 
> -Wl,-dead_strip_dylibs, which causes the linker to remove any references to 
> shared libraries that go unused.
>
> In the particular case of libffi.cabal, we have `extra-libraries: ffi`, so 
> the C compiler is given `-lCffi -lffi` as arguments, in that order. Recall 
> that -libCffi.a (i.e., -lCffi) is a statically linked copy of libffi, whereas 
> libffi.dylib (i.e., -lffi) is a dynamically linked version. The linker will 
> resolve all of its references to libffi functionality from libCffi.a because 
> it appears first, and since the linker never needs to resolve anything from 
> libffi.dylib, the -Wl,-dead_strip_dylibs will remove the reference to 
> libffi.dylib entirely. The result is that the final executable will 
> statically link against libffi. This is why this phenomenon only occurs with 
> libffi and not with other C libraries, since only libffi is given special 
> treatment within GHC like this.
>
> Why, then, does this only happen on macOS and not on, say, Linux? On Linux, 
> the final linking step looks slightly different. Instead of passing 
> -Wl,-dead_strip_dylibs (which is a macOS-specific option), it will pass 
> -Wl,--no-as-needed. Note that -Wl,--no-as-needed has the entirely _opposite_ 
> effect of -Wl,-dead_strip_dylibs: even if a shared library never gets 
> referenced, the linker will still declare a dynamic dependency on it. That is 
> exactly what happens here, as the -lCffi argument will still take precedence 
> over the -lffi argument on Linux, but there will be a useless dynamic 
> dependency on a dynamic libffi library due to -Wl,--no-as-needed.
>
> At this point, I realized that one consequence of all this is that if you 
> want to statically link against against libffi, and you are using a GHC 
> configured without ` --with-system-libffi`, then it suffices to simply 
> compile your program without any `extra-libraries` at all. That is because 
> the final link step will pass `-lCffi` no matter what, so the resulting 
> executable will always statically link against libffi by way of libCffi.a. 
> Moreover, libCffi is provided on all platforms, not just macOS, so this trick 
> is reasonably portable.
>
> -
>
> Having explained all this, I am forced to wonder if this is intended behavior 
> of GHC, or if it is a series of coincidences. The fact that macOS and Linux 
> pass -Wl,-dead_strip_dylibs and -Wl,--no-as-needed, two flags with completely 
> opposite behavior, is certainly a little unusual. But these choices appear to 
> be deliberate, as they are explained in Notes in the GHC source code here [2] 
> (for macOS) and here [3] (for Linux). The other possibly unusual thing is 
> that GHC always passes -lCffi before any of the `extra-libraries`. That could 
> very well be just a coincidence—I'm not sure if there's a particular reason 
> for -lCffi to come first.
>
> The reason that I'm looking so deeply into this matter is that I'm trying to 
> see what it would take to reliably link against libffi statically in the 
> Haskell bindings [4]. I've discovered a trick above to make it work for most 
> versions of GHC: just rely on `-lCffi`. Does this trick seem like it would 
> co

Re: A macOS static linking mystery

[Brandon Allbery]

https://developer.apple.com/forums/thread/692383 is what I'm thinking
of, but in this case there would still be library references shown by
"otool -L", so I guess that's not what you're seeing.

On Mon, Aug 8, 2022 at 7:49 PM Ryan Scott  wrote:
>
> Possibly? I'm not familiar with the system cache you're referring to, but 
> it's a more solid lead than what I have currently. Do you know how one would 
> confirm if this is the case or not?
>
> Ryan



-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: A macOS static linking mystery

[Brandon Allbery]

Any chance this is related to the weird system cache thing for system
dylibs that came in with the most recent OS X releases? I don't think
those show up in the normal way.

On Mon, Aug 8, 2022 at 7:33 PM Ryan Scott  wrote:
>
> I should clarify that I'm using a borrowed macOS on which I don't have admin 
> privileges, so I'm unable to install pkg-config. As a result, I'm commenting 
> out the pkgconfig-depends: line in libffi.cabal and manually specifying the 
> extra-lib-dirs and include-dirs via a cabal.project.local file.
>
> I've configured the project to use both the macOS system libffi (located at 
> /usr/lib/libffi.dylib) as well as the version that Homebrew provides. Both 
> configurations exhibit the strange, apparently-statically-linked behavior. 
> Even stranger, the macOS system libffi _only_ provides a .dylib file, not an 
> .a file. If I examine the x86 code of the compiled executable using `objdump 
> -d`, I can see various libffi definitions (e.g., _ffi_call), so perhaps these 
> definitions are being inlined through some kind of link-time optimization? 
> I'm really not sure how else to explain what's happening.
>
> Ryan
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: regression in ghc / cabal integration in 9.2.1

[Brandon Allbery]

Wasn't there specifically a new cabal version released to deal with
9.2.1? 3.4.1.0 / 3.6.2.0?

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

Re: Meaning of -i and -hidir

[Brandon Allbery]

I would expect that to be -I and for -i to specify module paths (which
might well mean .hi).

On Sat, Oct 23, 2021 at 2:32 PM Carter Schonwald 
wrote:

> I would assume the -i is for include c header search paths but I could be
> wrong
>
> On Sat, Oct 23, 2021 at 6:00 AM Oleg Grenrus  wrote:
>
>> This looks like a bug.
>>
>> -hidir documentation says
>>
>> > Redirects all generated interface files into ⟨dir⟩, instead of the
>> default.
>> > Please also note that when doing incremental compilation (by ghc --make
>> or ghc -c), this directory is where GHC looks into to find interface files.
>>
>> And documentation for -i doesn't mention looking for interface files.
>>
>> So by doing
>>
>> % ghc -dynamic-too -c lib/Lib.hs -odir odir -hidir hidir_Lib
>> % ghc -dynamic-too -c Main.hs -odir odir -hidir hidir_Main -ihidir_Lib
>> 1
>> % ghc odir/Lib.o odir/Main.o -o Demo
>> % ./Demo
>> True
>>
>> everything compiles, TH is run, and demo works. The result files are
>>
>> % find .
>> .
>> ./Demo
>> ./Main.hs
>> ./hidir_Main
>> ./hidir_Main/Main.dyn_hi
>> ./hidir_Main/Main.hi
>> ./odir
>> ./odir/Main.dyn_o
>> ./odir/Main.o
>> ./odir/Lib.dyn_o
>> ./odir/Lib.o
>> ./hidir_Lib
>> ./hidir_Lib/Lib.dyn_hi
>> ./hidir_Lib/Lib.hi
>> ./lib
>> ./lib/Lib.hs
>>
>> ---
>>
>> The confusing error is caused by Lib module in libiserv:
>> https://hackage.haskell.org/package/libiserv
>> which GHC picks!
>>
>> If we rename your Lib module to Library, the error is way better: Could
>> not find module ‘Library’
>>
>> I also tried using same -hidir when compiling both modules, then GHC
>> still cannot find the Library interface, even the documentation says it
>> should.
>>
>> Please open a GHC issue at https://gitlab.haskell.org/ghc/ghc/-/issues
>>
>>
>>
>> - Oleg
>> On 22.10.2021 19.16, Domínguez, Facundo wrote:
>>
>> Dear devs,
>>
>> I'm confused about the meaning of -hidir and -i. Here's my experiment
>> with both ghc-9.2.0 and ghc-8.10.4.
>>
>> > $ find
>> > ./Main.hs
>> > ./lib/Lib.hs
>> >
>> > $ ghc -dynamic-too -c lib/Lib.hs -odir odir -hidir hidir_Lib
>> >
>> > $ ghc -dynamic-too -c Main.hs -odir odir -ihidir_Lib -hidir hidir_Main
>> >
>> > Main.hs:3:1: error:
>> > Bad interface file: hidir_Main/Lib.hi
>> > hidir_Main/Lib.hi: openBinaryFile: does not exist (No such file
>> or directory)
>> >   |
>> > 3 | import Lib
>> >   | ^^
>>
>> If I only use -hidir, it still fails with another error
>>
>> > $ ghc -dynamic-too -c Main.hs -odir odir -hidir hidir_Lib
>> >
>> > Main.hs:7:29: error: Variable not in scope: f
>> >   |
>> > 7 | main = print $(runIO (print f) >> [| True |])
>> >   | ^
>>
>> If I use both -i and -hidir pointing to the same folder, then it works!
>>
>> > $ ghc -dynamic-too -c Main.hs -odir odir -ihidir_Lib -hidir hidir_Lib
>>
>> Now, is this behavior a bug or a feature? And if it is a bug, what is the
>> expected behavior?
>>
>> Programs copied below.
>>
>> Thank you!
>> Facundo
>>
>> > $ cat lib/Lib.hs
>> > module Lib where
>> >
>> > f :: Int
>> > f = 1
>> >
>> > $ cat Main.hs
>> > {-# LANGUAGE TemplateHaskell #-}
>> >
>> > import Lib
>> > import Language.Haskell.TH 
>> >
>> > main :: IO ()
>> > main = print $(runIO (print f) >> [| True |])
>>
>> ___
>> ghc-devs mailing 
>> listghc-devs@haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: where to go for HLS details?

[Brandon Allbery]

For what it's worth, I use hexchat. You may prefer to use IRC via matrix,
though.

On Tue, Oct 12, 2021 at 2:22 PM Norman Ramsey  wrote:

>  > In general #haskell-language-server on libera is a good place to
>  > ask these questions.
>
> Can you recommend an IRC client?  I tried using the web-based client,
> got limited response, and then the client destroyed all history.
>

-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: please help with ghc package-db flags

[Brandon Allbery]

Not necessarily filesystem; also check GHC_PACKAGE_PATH in the environment.

On Mon, Sep 27, 2021 at 4:51 PM Norman Ramsey  wrote:

> I've traced some troubles to a problem with GHC's response
> to the -clear-package-db and -package-db flags.  I would very much
> like to know if others can duplicate this issue.
>
> All that is needed is for you to try the following commands, or
> whatever variations may be appropriate for whatever ghc versions you
> have installed on your system:
>
>   ghc-pkg init /tmp/empty-package-db
>   ghc-clear-package-db -package-db /tmp/empty-package-db/ -v
>   ghc-9.0.1  -clear-package-db -package-db /tmp/empty-package-db/ -v
>   ghc-8.10.7 -clear-package-db -package-db /tmp/empty-package-db/ -v
>
> On my system at this present moment, ghc-8.10.7 respects the commands,
> but ghc-9.0.1 does not.  The output from the `-v` options show what's
> happening: if GHC finds any packages that are *not* "wired-in," then
> something is broken.  As examples, I attach the sample outputs from my
> own system.
>
> I think the issue is being caused by something mysterious in my filesystem.
> Last Friday, ghc 9.0.1 was respecting those flags.  But today it is not.
> Before I try to figure out what is going on, I would *very* much
> appreciate learning if anyone else can duplicate the issue.
>
> Please try running GHC with an empty package database and let me know
> what happens.
>
>
> Norman
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Trying to speedup GHC compile times...Help!

[Brandon Allbery]

They don't work in Chrome either. A quick inspection of the links indicates
that the ones in the TOC have anchors of the form "#org-NN" while their
targets have forms derived from the heading strings.

On Thu, Jul 8, 2021 at 4:53 PM Jaro Reinders 
wrote:

> Hi Jeff,
>
> For some reason none of the links in the table of contents work for me in
> Firefox.
>
> It seems some other pages use [[_TOC_]] to generate it automatically.
>
> Cheers,
>
> Jaro
>
> On 08-07-2021 22:04, Jeffrey Young wrote:
> > Hi everyone,
> >
> >
> > I've created a wiki page here
> > <
> https://gitlab.haskell.org/ghc/ghc/-/wikis/Adventures-in-GHC-compile-times>
>
> > that collected your suggestions and tracks my work. I'll be regularly
> updating
> > it. Any comments welcome.
> >
> >
> > - Jeff
> >
> >
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC and the future of Freenode

[Brandon Allbery]

Pasting directly into the channel is generally a no-no on IRC. Things like
Matrix or IRCCloud convert to pastebins automatically.

On Sun, Jun 6, 2021 at 2:07 PM Viktor Dukhovni 
wrote:

> On 19 May 2021, at 11:48 am, Carter Schonwald 
> wrote:
>
> > I personally vote for irc.  Perhaps via Libera.
>
> Perhaps I'm too much of an IRC noob, but I still found it it rather
> surprising to be banned from libera.chat (my IP is blacklisted) for
> pasting a 25-line build script for building GHC via hadrian on FreeBSD
> into the #ghc channel.
>
> This was in response to a discussion about issues with the bindist,
> how the port is built, ... and while perhaps I'm expected to use a
> paste bin, the abrupt ban was rather a harsh response.
>
> The ban appears to have been "temporary", an hour or so later I am
> able to reconnect, but this does not leave a good impression.
>
> --
> Viktor.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Is referring to GHC-proposals in GHC user manual bad practice or not?

[Brandon Allbery]

I'm inclined to agree with this, especially given the argument that it'll
depend on the state of a proposal at a given time.

On Wed, Mar 17, 2021 at 2:36 PM Richard Eisenberg  wrote:

> My vote is that the manual should be self-standing. References to
> proposals are good, but as supplementary/background reading only. My gold
> standard always is: if we lost all the source code to GHC and all its
> compiled versions, but just had the manual and Haskell Reports (but without
> external references), we could re-create an interface-equivalent
> implementation. (I say "interface-equivalent" because we do not specify all
> the details of e.g. optimizations and interface files.) We are very, very
> far from that gold standard. Yet I still think it's a good standard to aim
> for when drafting new sections of the manual.
>
> Of course, authors are quite free to copy-and-paste from proposal text to
> form a new manual chapter.
>
> If we agree about this, it would be good to lay this out somewhere,
> perhaps in the "care and feeding" chapter.
>
> Richard
>
> > On Mar 17, 2021, at 1:21 PM, Oleg Grenrus  wrote:
> >
> > I forgot to link a bit of relevant discussion from
> > https://github.com/ghc-proposals/ghc-proposals/pull/406,
> > is there a (silent) consensus on the issue?
> >
> > - Oleg
> >
> > On 17.3.2021 19.15, Oleg Grenrus wrote:
> >> I have a following question:
> >> My lexer rules related proposal was recently accepted. The biggest part
> >> of getting it in is writing documentation for it. While looking at
> >> Divergence from Haskell 98 and Haskell 2010 section of the user manual,
> >> in particular Lexical syntax, it already has See "GHC Proposal #229 for
> >> the precise rules.".
> >>
> >> Can I just the same? (I think there was an implicit acceptance of that
> >> practice in e.g.
> >> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/1664#note_238759)
> >>
> >> However, I think that referring to proposals text for "essential" bits
> >> of information is a bad practice.
> >> Because GHC proposals are sometimes amended, one have to look into
> >> GitHub history to find out what were there for a particular time point
> >> of a GHC release. Very laborous.
> >>
> >> ---
> >>
> >> Currently there is 23 references to about a dozen of proposals. An
> >> example are passages like
> >>
> >> In 9.0, the behavior of this extension changed, and now we require
> >> that a negative literal must not be preceded by a closing token (see
> >> `GHC Proposal #229
> >> <
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0229-whitespace-bang-patterns.rst
> >`__
> >> for the definition of a closing token).
> >>
> >> or
> >>
> >>  a future release will be
> >>  turned off by default and then possibly removed. The reasons for
> >> this and
> >>  the deprecation schedule are described in `GHC proposal #30
> >>
> >> <
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0030-remove-star-kind.rst
> >`__.
> >>
> >> And there are better examples, which are references for more
> information,
> >> not essential one, like
> >>
> >>  See the proposal `DuplicateRecordFields without ambiguous field
> access
> >>
> >> <
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0366-no-ambiguous-field-access.rst
> >`_
> >>  and the documentation on :extension:`DuplicateRecordFields` for
> >> further details.
> >>
> >> (I'd put the internal user manual link first), or
> >>
> >> But these automatic eta-expansions may silently change the semantics
> >> of the user's program,
> >> and deep skolemisation was removed from the language by
> >> `GHC Proposal #287
> >> <
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst
> >`__.
> >> This proposal has many more examples.
> >>
> >> ---
> >>
> >> So to boil down my question, can I write
> >>
> >> Lexical syntax of identifiers and decimal numbers differs slightly
> >> from the Haskell report.
> >> See GHC Proposal #403 for the precise rules and differences.
> >>
> >> - Oleg
> >> ___
> >> ghc-devs mailing list
> >> ghc-devs@haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Pattern matching desugaring regression? Re: [Haskell-cafe] Why does my module take so long to compile?

[Brandon Allbery]

They already said something about waiting on dependencies to catch up with
ghc9, IIRC.

On Mon, Feb 15, 2021 at 2:22 PM Carter Schonwald 
wrote:

> Don’t forget ghc 9 is already out! :)
>
> On Mon, Feb 15, 2021 at 2:10 PM Troels Henriksen  wrote:
>
>> It is very likely that issue 17386 is the issue.  With
>>
>> {-# OPTIONS_GHC -Wno-overlapping-patterns -Wno-incomplete-patterns
>> -Wno-incomplete-uni-patterns -Wno-incomplete-record-updates #-}
>>
>> my module(s) compile very quickly.  I'll wait and see if GHC 9 does
>> better before I try to create a smaller case (and now I at least have a
>> workaround).
>>
>> Sebastian Graf  writes:
>>
>> > Hi,
>> >
>> > I'm not sure I see all the context of the conversation, but it is
>> entirely
>> > possible that code with many local constraints regresses the
>> pattern-match
>> > checker (which is accounted to Desugaring in the profile emitted by
>> -v2),
>> > I'm afraid. That simply has to do with the fact that we now actually
>> care
>> > about them, previously they were mostly discarded.
>> >
>> > I'd be glad if you submitted a relatively isolated reproducer of what is
>> > fast with 8.8 and slow with 8.10 (even better 9.0).
>> > I hope that things have improved since we fixed
>> > https://gitlab.haskell.org/ghc/ghc/-/issues/17836, which is part of
>> 9.0 but
>> > not of 8.10.
>> >
>> > Cheers,
>> > Sebastian
>> >
>> > Am Mo., 15. Feb. 2021 um 19:04 Uhr schrieb Troels Henriksen <
>> > at...@sigkill.dk>:
>> >
>> >> Carter Schonwald  writes:
>> >>
>> >> > Ccing ghc devs since that’s a better forum perhaps
>> >> > Crazy theory:
>> >> >
>> >> > this is a regression due the the partial changes to pattern matching
>> >> > coverage checking in 8.10 that finished / landed in ghc 9
>> >> >
>> >> > Why:
>> >> > Desugaring is when pattern/ case statement translation happens I
>> think?
>> >> > And the only obvious “big thing” is that you have some huge , albeit
>> sane
>> >> > for a compiler, pattern matching
>> >> >
>> >> > I’d first check if the new ghc 9 release doesn’t have that
>> regression in
>> >> > build time that you experienced.  And if it does file a ticket.
>> >> >
>> >> > I may be totally wrong, but that seems like a decent likelihood !
>> >>
>> >> You may be right!  Another module that regressed is also mainly
>> >> characterised by large-but-not-insane case expressions:
>> >>
>> >>
>> https://github.com/diku-dk/futhark/blob/d0839412bdd11884d75a1494dd5de5191833f39e/src/Futhark/Optimise/Simplify/Rules.hs
>> >>
>> >> I'll try to split these modules up a little bit (I should have done so
>> a
>> >> while ago anyway) and maybe that will make the picture even clearer.
>> >>
>> >> --
>> >> \  Troels
>> >> /\ Henriksen
>> >> ___
>> >> ghc-devs mailing list
>> >> ghc-devs@haskell.org
>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >>
>>
>> --
>> \  Troels
>> /\ Henriksen
>>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Weird "missing hi file" problem with a serializable Core patch

[Brandon Allbery]

Without looking at the implementation, it looks to me like the filename is
doubled for some reason. This may suggest places to look.

On Wed, Sep 16, 2020 at 2:57 PM Cheng Shao  wrote:

> Hi all,
>
> Following a short chat in #ghc last week, I did a first attempt of
> reusing existing Iface logic to implement serialization for
> codegen-related Core. The implementation is included in the attached
> patch (~100 loc). As a quick and dirty validation of whether it works,
> I also modified the codegen pipeline logic to do a roundtrip: after
> CorePrep, the Core bits are converted to Iface, then we immediately
> convert it back and use it for later compiling.
>
> With the patch applied, stage-1 GHC would produce a "missing hi file"
> error like:
>
> : Bad interface file: _build/stage1/libraries/ghc-prim/build/GHC/Types.hi
>   _build/stage1/libraries/ghc-prim/build/GHC/Types.hi:
> openBinaryFile: does not exist (No such file or directory)
>
> The error surprises me, since by the time we perform the Core-to-Core
> roundtrip, the .hi file should already have been written to disk. Is
> there anything obviously wrong with the implementation? I'd appreciate
> any pointers or further questions, thanks a lot!
>
> Best regards,
> Cheng
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Parsing funny arrows

[Brandon Allbery]

Another way to figure it out is the shift/reduce conflict on @, which tells
you it had two ways to recognize it. "Reduce" here means returning to your
parser rule, so "shift" means btype wanted to recognize the @. Inspecting
btype would then have shown that it was looking for a type application.

On Sat, Aug 29, 2020, 03:17 Csongor Kiss 
wrote:

> Thanks a lot Vlad and Shayne, that indeed did the trick!
>
> Out of curiosity, how could I have figured out that this was the culprit?
> The parse
> error I got was a bit puzzling, and I couldn't find any flags that would
> give more information
> (I think I was looking for the parser equivalent of -ddump-tc-trace).
>
> Best,
> Csongor
>
> On 29 Aug 2020, at 00:51, Shayne Fletcher 
> wrote:
>
>
>
> On Fri, Aug 28, 2020 at 7:48 PM Shayne Fletcher <
> shayne.fletcher...@gmail.com> wrote:
>
>>
>>
>> On Fri, Aug 28, 2020 at 7:38 PM Vladislav Zavialov 
>> wrote:
>>
>>> Hi Csongor,
>>>
>>> I believe the reason for this failure is that  a -> @m b  gets parsed
>>> as  a -> @(m b).
>>> Why is that? Because a ‘btype’ includes type-level application.
>>>
>>> If you replace the ‘btype’ after PREFIX_AT with an ‘atype’, this
>>> particular issue should go away. At least that’s my hypothesis, I haven’t
>>> tested it.
>>>
>>>
>> I confirm that this is correct and with that change the example string
>> reduces as hoped.
>>
>>
>> - Vlad
>>>
>>
> Also, with that correction there are no new shift/reduce conflicts. The
> original rule gave rise to 3.
>
> --
> Shayne Fletcher
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC Logo

[Brandon Allbery]

Sounds like a missing font to me. It rendered sans-serif here, but I have
that set as default.

On Sun, Aug 16, 2020 at 1:39 PM Merijn Verstraaten 
wrote:

>
>
> > On 16 Aug 2020, at 16:02, Ben Gamari  wrote:
> >
> > Carter Schonwald  writes:
> >
> >> I def like the serif / times new Roman version
> >>
> > I'm not aware of a serif version and in general I would be hesitant to
> > introduce one given that:
>
> The one you send out renders using a serif font for GHC on my system (and,
> presumably, Carter's).
>
> Cheers,
> Merijn
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Question about binary distributions

[Brandon Allbery]

It's only relocatable given some assumptions which are violated by
various distributions (AIX was already mentioned; and the bin and lib
directories may not be next to each other with some distributions'
preferred configurations). Basically the configure mechanism gives us
some flexibility not otherwise available, without requiring a full
build from source (which is fairly involved and requires an existing
ghc).

On 8/7/20, John Cotton Ericson  wrote:
> Per https://gitlab.haskell.org/ghc/ghc/issues/17191 I do hope to break
> up our configure script soon.[1] Then the bindist will need not ship the
> "entire" configure script, but just what is necessary to fill in the
> settings file(s) which have that information Ben mentions.
>
> I think that will improve the optics of the situation a bit; for
> example, I don't think the reduced bindist configure script should need
> to worry about directories at all since GHC is relocatable (when built
> by Hadrian).
>
> John
>
> [1]: I will be able to resume work on that once I get to the bottom of
> https://gitlab.haskell.org/ghc/ghc/merge_requests/1102. All help greatly
> appreciated!
>
> On 8/7/20 11:15 AM, Ben Gamari wrote:
>> "Mathieu Boespflug"  writes:
>>
>>> Hi all,
>>>
>>> GHC currently has 3 tier-1 platforms: Linux, macOS and Windows. I'll
>>> focus the dicussion below on these three platforms. The binary
>>> distributions for Linux and macOS are designed to be unpacked, then
>>> the user types ./configure && make install. This is not the case for
>>> Windows.
>>>
>>> On all platforms it's possible to create "relocatable" installations,
>>> such that GHC doesn't really care where it's installed, and commands
>>> will still work if the install directory changes location on the
>>> filesystem. So my question is, why do we have a ./configure step on
>>> Linux and macOS? Why could we not have bindists for all platforms that
>>> work like the Windows one? I.e. a binary distribution that you just
>>> unpack, in any directory of your choice, without any configuration or
>>> installation step.
>> There are a few reasons:
>>
>>   * Relocatable GHC builds have only been supported for only a few
>> releases now and only under the Hadrian build system, which is not
>> currently used to produce our binary distributions (hopefully this
>> will change for 9.2).
>>
>>   * On Windows we have the luxury of having a very well-controlled
>> environment as we rely on essentially nothing from the host
>> system. We provide our own mingw toolchain, statically link
>> against libc, and have no additional dynamic dependencies.
>>
>> By contrast, on Linux we have to deal with a much larger
>> configuration space:
>>
>>  * several linkers, each with their own bugs
>>
>>  * several C compilers, supporting various subsets of functionality
>>and quirks (e.g. some distributions enable -pie by default, others
>>do not)
>>
>>  * various LLVM packaging schemes
>>
>> Since it would be quite expensive to probe the toolchain
>> characteristics on every compiler invocation, we rather do this once
>> in the configure script during bindist installation and package the
>> result in the installed `settings` file.
>>
>>   * On Linux we may have additional dynamic dependencies (e.g. libdw,
>> numactl) which we check for during configuration time, lest the user
>> be faced with an unsightly linker error if they happen to be missing
>> a library.
>>
>> In principle we could perhaps avoid the need for many of these checks
>> by creating one binary distribution per operating system distribution.
>> However, we will first need to move to Hadrian to build our binary
>> distributions.
>>
>> Cheers,
>>
>> - Ben
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: AW: RE: Hi. I'm new to this mailing list and have a few questions.

[Brandon Allbery]

It's represented the same way but handled differently; my point, though,
was more about it being consistent with the rest of the language, which is
less about how the compiler handles it than about how it looks to the
programmer. In this case, _ is consistently used to mean a wildcard of some
kind, even though it has to be handled by the compiler in multiple places
including TypeApplications and PartialTypeSignatures (others include
patterns, typed holes, and let bindings as an extension of simple patterns).

On Tue, Aug 4, 2020 at 2:27 PM Anselm Schüler (conversations subemail) <
conversat...@anselmschueler.com> wrote:

> That’s true, but type wildcards without PartialTypeSignatures throw an
> error, while this doesn’t need that (which suggests that they’re
> represented differently internally — I don’t know, of course). Also, there
> are other drawbacks discussed in the ghc-proposals Proposal
> 0042-named-type-args
> <https://github.com/ghc-proposals/ghc-proposals/pull/196> that was
> mentioned by Vladislav Zavialov . Which is, I
> think, it seems, where the discussion should take place (?).
>
>
>
> *Anselm Schüler*
>
> *www.anselmschueler.com* <http://www.anselmschueler.com>
>
> *m...@anselmschueler.com* 
>
>
>
> *From: *Brandon Allbery 
> *Sent: *Tuesday, August 4, 2020 20:16
> *To: *Anselm Schüler (conversations subemail)
> 
> *Cc: *Rowan Goemans ; ghc-devs@haskell.org
> *Subject: *Re: AW: RE: Hi. I'm new to this mailing list and have a few
> questions.
>
>
>
> _ already has the meaning of a type wildcard (generalized from its use as
> a wildcard in patterns), so this
>
> is consistent with its use in other type signatures. The problem I see
> with your proposal is that it assumes
>
> you know the names of the type variables in the original declaration.
>
>
>
> On Tue, Aug 4, 2020 at 2:12 PM Anselm Schüler (conversations subemail) <
> conversat...@anselmschueler.com> wrote:
>
> And also, it’s really weird and seems like a feature that should be
> removed IMO. It kind of looks like the type variable _ is always
> in-scope, and it’s unclear if the type of the resulting function is just
> type variables without an explicit forall or if _ has a special meaning.
>
>
>
> *Anselm Schüler*
>
> *www.anselmschueler.com <http://www.anselmschueler.com>*
>
>
>
> *From: *Anselm Schüler (conversations subemail)
> 
> *Sent: *Tuesday, August 4, 2020 20:09
> *To: *Rowan Goemans ; ghc-devs@haskell.org
> *Subject: *RE: AW: RE: Hi. I'm new to this mailing list and have a few
> questions.
>
>
>
> True, but this makes the type less readable since id @_ :: _ -> _.
>
>
>
> *Anselm Schüler*
>
> *www.anselmschueler.com <http://www.anselmschueler.com>*
>
>
>
> *From: *Rowan Goemans 
> *Sent: *Tuesday, August 4, 2020 19:59
> *To: *ghc-devs@haskell.org 
> *Subject: *Re: AW: RE: Hi. I'm new to this mailing list and have a few
> questions.
>
>
>
> Just as a heads up. You can achieve what you want already by doing:
>
> f @_ @([String]) *:: forall a. (a, [String]) -> ([String], a**) *
>
> Best regards,
>
> Rowan Goemans
>
> On 8/4/20 7:45 PM, Anselm Schüler (conversations subemail) wrote:
>
> Thank you for the nice introduction :) !
>
> I will check out the GHC proposals site.
>
> And following Simon’s (I hope addressing with first name is OK)
> suggestion, I’m going to give an outline of the idea.
>
>
>
> The idea is to extend type application syntax to enable explicit
> assignment of types to specific type variables.
>
> For instance, say I have f :: forall a b. (a, b) -> (b, a), and I want to
> apply the type [String] to it. My only option is to do
>
> f @([String]) *:: forall b. ([String], b) -> (b, [String]) *
>
> —but what if, instead, I want a function of type forall a. (a, [String])
> -> ([String], a)?
>
> I propose the following syntax:
>
> f @{b = [String]} *:: forall a. ([String], b) -> (b, [String])*
>
> This wouldn’t break any existing programs since using record syntax here
> is already disallowed and met with an error message.
>
> A question is of course the symbol used for assignment (~, =, ::, or ->?).
>
>
>
> I hope the code shows up as a monospace font on your end. I used the IBM
> Plex Mono font, which is open-source <https://github.com/IBM/plex>.
>
>
>
> *Anselm Schüler*
>
> *wwwanselmschueler.com <http://www.anselmschueler.com>*
>
> *m...@anselmschueler.com *
>
>
>
> *From: *Simon Peyton Jones 
> *Sent: *Tuesday, August 4, 2020 18:44
> *To: *Richard Eisenberg ; "Anselm Schüler
> (conversations subemail)&quo

Re: AW: RE: Hi. I'm new to this mailing list and have a few questions.

[Brandon Allbery]

_ already has the meaning of a type wildcard (generalized from its use as a
wildcard in patterns), so this
is consistent with its use in other type signatures. The problem I see with
your proposal is that it assumes
you know the names of the type variables in the original declaration.

On Tue, Aug 4, 2020 at 2:12 PM Anselm Schüler (conversations subemail) <
conversat...@anselmschueler.com> wrote:

> And also, it’s really weird and seems like a feature that should be
> removed IMO. It kind of looks like the type variable _ is always
> in-scope, and it’s unclear if the type of the resulting function is just
> type variables without an explicit forall or if _ has a special meaning.
>
>
>
> *Anselm Schüler*
>
> *www.anselmschueler.com *
>
>
>
> *From: *Anselm Schüler (conversations subemail)
> 
> *Sent: *Tuesday, August 4, 2020 20:09
> *To: *Rowan Goemans ; ghc-devs@haskell.org
> *Subject: *RE: AW: RE: Hi. I'm new to this mailing list and have a few
> questions.
>
>
>
> True, but this makes the type less readable since id @_ :: _ -> _.
>
>
>
> *Anselm Schüler*
>
> *www.anselmschueler.com *
>
>
>
> *From: *Rowan Goemans 
> *Sent: *Tuesday, August 4, 2020 19:59
> *To: *ghc-devs@haskell.org
> *Subject: *Re: AW: RE: Hi. I'm new to this mailing list and have a few
> questions.
>
>
>
> Just as a heads up. You can achieve what you want already by doing:
>
> f @_ @([String]) *:: forall a. (a, [String]) -> ([String], a**) *
>
> Best regards,
>
> Rowan Goemans
>
> On 8/4/20 7:45 PM, Anselm Schüler (conversations subemail) wrote:
>
> Thank you for the nice introduction :) !
>
> I will check out the GHC proposals site.
>
> And following Simon’s (I hope addressing with first name is OK)
> suggestion, I’m going to give an outline of the idea.
>
>
>
> The idea is to extend type application syntax to enable explicit
> assignment of types to specific type variables.
>
> For instance, say I have f :: forall a b. (a, b) -> (b, a), and I want to
> apply the type [String] to it. My only option is to do
>
> f @([String]) *:: forall b. ([String], b) -> (b, [String]) *
>
> —but what if, instead, I want a function of type forall a. (a, [String])
> -> ([String], a)?
>
> I propose the following syntax:
>
> f @{b = [String]} *:: forall a. ([String], b) -> (b, [String])*
>
> This wouldn’t break any existing programs since using record syntax here
> is already disallowed and met with an error message.
>
> A question is of course the symbol used for assignment (~, =, ::, or ->?).
>
>
>
> I hope the code shows up as a monospace font on your end. I used the IBM
> Plex Mono font, which is open-source .
>
>
>
> *Anselm Schüler*
>
> *wwwanselmschueler.com *
>
> *m...@anselmschueler.com *
>
>
>
> *From: *Simon Peyton Jones 
> *Sent: *Tuesday, August 4, 2020 18:44
> *To: *Richard Eisenberg ; "Anselm Schüler
> (conversations subemail)" 
> *Cc: *ghc-devs@haskell.org
> *Subject: *RE: Hi. I'm new to this mailing list and have a few questions.
>
>
>
> Welcome Anselm  ghc-devs is a very informal mailing list, and we welcome
> newcomers.
>
>
>
> For example, I have a feature idea in the back of my mind, which I imagine
> would be easy to implement
>
>
>
> What Richard says is right, but you should feel free to fly the kite on
> this list if you want – or on Haskell Café – to get some idea of whether
> others seem warm about the idea, before writing a full proposal.
>
>
>
> Simon
>
>
>
> *From:* ghc-devs 
>  *On Behalf Of *Richard Eisenberg
> *Sent:* 04 August 2020 16:05
> *To:* "Anselm Schüler (conversations subemail)"
>  
> *Cc:* ghc-devs@haskell.org
> *Subject:* Re: Hi. I'm new to this mailing list and have a few questions.
>
>
>
> Hi Anselm,
>
>
>
> Welcome!
>
>
>
> A good way of getting used to a list like this one is to wait a little
> while and observe what kind of messages others send; this will give you a
> feel for how the list is used. If you're impatient, you can also check out
> the archives at https://mail.haskell.org/pipermail/ghc-devs/
> 
> .
>
>
>
> As for a feature request: if your feature changes the language GHC accepts
> (most do), the right place to post is at
> https://githubcom/ghc-proposals/ghc-proposals
> .
> There is a description of how to proceed on that page. Proposals submitted
> there get d

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

[Brandon Allbery]

On Fri, Jan 24, 2020 at 11:58 PM Ben Gamari  wrote:

>  * A number of improvements in code generation, including changes
>

This seems like it's missing some detail.

-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Linking stage 2 compiler with non-threaded RTS using Make?

[Brandon Allbery]

There are some hidden dependencies, in particular ghci requires GhcThreaded
last I checked (and ghci == ghc --interactive, not a separate program that
could be linked threaded). You may also have to disable the entire bytecode
backend, which would take TH and runghc with it as well as ghci.

On Thu, Jan 9, 2020 at 8:02 AM Ömer Sinan Ağacan 
wrote:

> Anyone know how to link stage 2 with non-threaded RTS using Make build
> system?
> There's a variable GhcThreaded, but setting it "NO" makes no difference,
> stage 2
> compiler is still threaded.
>
> So far the only way I could find is to redirect build system output to a
> file,
> find the step that linked ghc-stage2, repeat that command but without
> -threaded.
> It's really painful as I have to repeat this step after every rebuild.
>
> Any tips?
>
> Thanks,
>
> Ömer
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Multiple instance pragmas

[Brandon Allbery]

TBH I'd have expected INCOHERENT to cover OVERLAPPABLE, i.e. all bets are
off and you've allowed anything including overlaps.

On Mon, Nov 25, 2019 at 11:26 AM Domínguez, Facundo <
facundo.doming...@tweag.io> wrote:

> Dear devs,
>
> I have a program [1] which depends on the ability to specify some
> instances to be both overlappable and incoherent.
>
> GHC so far, allows only one of the OVERLAPPABLE or INCOHERENT pragmas to
> be specified per instance. One can still have an overlappable and
> incoherent instance by using -XIncoherenInstances, but this extension is
> deprecated.
>
> Is there any chance that a patch is accepted to allow multiple instance
> pragmas? And if not, what would the reason for this constraint?
>
> Thanks,
> Facundo
>
> [1]
> https://gist.github.com/facundominguez/2c0292bf6a721b450c46486ff3b71f24
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Compiling binaries of bytecode: ever been considered?

[Brandon Allbery]

Lots of people have had such ideas… until they looked at the bco
implementation. Consider yourself warned.

On Mon, Nov 4, 2019 at 9:02 AM Andreas Klebinger 
wrote:

> I've heard the idea come up once or twice. But I'm not aware of any
> efforts going further than that.
>
>
>
> Christopher Done schrieb am 04.11.2019 um 14:59:
> > Hi all,
> >
> > I was just wondering: has a compiler output mode ever been considered
> > that would dump bytecode to a file, dynamic link to the ghc runtime,
> > and then on start-up that program would just interpret the bytecode
> > like ghci does?
> >
> > The purpose would be simply faster compile-and-restart times.
> >
> > Cheers,
> >
> > Chris
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: validate-x86_64-darwin failing

[Brandon Allbery]

Apple makes that annoyingly difficult; someone has to in effect donate a
Mac to the cause, preferably one with enough memory and fast CPU. (Not
literally: one can keep the Mac physically, but would more or less lose use
of it for any other purpose.)
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: slow load and typecheck

[Brandon Allbery]

If they are loading each other, they likewise need .hi files. .o files are
optional if you aren't linking them.

On Tue, Oct 8, 2019 at 10:59 AM Sam Halliday  wrote:

> Brandon Allbery  writes:
>
> > you really do want those .hi files, otherwise it must compile the
> > dependency module to generate one.
>
> Right, exactly! But I thought that's what targetAllowObjCode=True was
> doing, is it not? Is there another setting that I'm missing?
>
> Should I use that for all my modules and not just the dependencies?
>
> --
> Best regards,
> Sam
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: slow load and typecheck

[Brandon Allbery]

It reuses the .hi files already built for other modules. Those aren't in
the source directory but under a build directory. If they don't exist
there, it will build the dependencies to create them.

On Tue, Oct 8, 2019 at 10:57 AM Sam Halliday  wrote:

> Brandon Allbery  writes:
>
> > It's doing what you — but not ghc — consider "extra work", though. ghc
> > expects to be compiling code, and doesn't have a separate code path for
> > "load symbols from an external module by parsing its source code" instead
> > of "load symbols from an external module by loading its .hsc file and
> > object code", aside from HscInterpreted.
>
>
> I'm confused: it sounds like you saying that only HscInterpreted can
> load symbols of dependencies from object code. Then how does cabal+ghc
> do this when I make a change to one file in my project and do a
> recompile of the package?
>
> BTW, I am seeing modules going through CodeGen that are not part of the
> file's dependency graph... LoadUpTo is behaving more like LoadAll.
>
> --
> Best regards,
> Sam
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: slow load and typecheck

[Brandon Allbery]

I already mentioned needing .hi (I may have said hsc, whoops; Haskell
Interface files) from dependencies; you really want to turn that part on,
at least. And possibly ensure your other options are compatible with
existing .hi files, so they can be loaded directly. I think the .o isn't
used until link time, which should be irrelevant for you; but you really do
want those .hi files, otherwise it must compile the dependency module to
generate one.

On Tue, Oct 8, 2019 at 10:51 AM Sam Halliday  wrote:

> Matthew Pickering  writes:
>
> > Are you writing interface files (-fwrite-interface)? It makes no sense
> > for HscInterpreted to be faster than HscNothing.
>
> Nope, not writing anything like that (I just checked the ghc flags from
> hie-bios to confirm)... and I agree that this makes no sense.
>
>
> --
> Best regards,
> Sam
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: slow load and typecheck

[Brandon Allbery]

It's doing what you — but not ghc — consider "extra work", though. ghc
expects to be compiling code, and doesn't have a separate code path for
"load symbols from an external module by parsing its source code" instead
of "load symbols from an external module by loading its .hsc file and
object code", aside from HscInterpreted.

On Tue, Oct 8, 2019 at 10:37 AM Sam Halliday  wrote:

> Thanks Brandon,
>
> Brandon Allbery  writes:
> > Cabal will build all that stuff the first time and then reuse it the
> next,
> > so it's not quite the same thing. Since you told ghc no object code,
>
> Sorry, I meant that I used targetAllowObjCode=True for everything,
> except the file under inspection. Do you mean that if I used
> targetAllowObjCode=False for just one module it will invalidate the
> object code for everything it depends on? That is unexpected.
>
>
> > In short, you may want to rethink this; ghc is a compiler, not an IDE,
> and
> > doesn't quite work the way you had hoped.
>
> How would you suggest rethinking it? Bare in mind that the api is
> working exactly the way I want from a functional point of view (just
> slow) with HscNothing... and seems to work exactly the way I want with
> HscInterpreted (but with all the ghci caveats like unboxed tuples etc).
>
> --
> Best regards,
> Sam
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: slow load and typecheck

[Brandon Allbery]

I think the only path for loading a dependency that doesn't involve loading
object code of some kind is the {-# SOURCE #-} hack as part of .hs-boot
files, which isn't general enough to be reused here as I understand it. A
decent chunk of the compiler would need to be duplicated to avoid this, and
it might use a fair amount of memory and end up generating at least part of
the object into memory.

Also recall that if any TH or quasiquotation is involved, it'll need to
load object code in support of that; and it might well need to prepare for
this in the general case rather than again having to duplicate a bunch of
code to support different no-TH and TH paths.

Cabal will build all that stuff the first time and then reuse it the next,
so it's not quite the same thing. Since you told ghc no object code, it
discards what it generates here and may not use existing compiled modules;
or you may have specified settings incompatible with any it did find.

In short, you may want to rethink this; ghc is a compiler, not an IDE, and
doesn't quite work the way you had hoped.

On Tue, Oct 8, 2019 at 10:15 AM Sam Halliday  wrote:

> Hello all,
>
> I am writing an interactive tool using the ghc api. It is able to load
> and typecheck a source file in a user's package.
>
> I obtain the flags that cabal uses to compile the user's package via the
> hie-bios trick, and I `parseDynamicFlagsCmdLine' them inside my tool,
> then I `setTargets' all the home modules (with targetAllowObjCode=True).
>
> I use HscNothing and NoLink because I only want access to the trees, I
> don't want to produce any output files.
>
> For the file that I wish to inspect, I `removeTarget' the module and
> `addTarget` it again but this time providing the full path to the file
> and don't allow object code.
>
> Then I LoadUpTo and typecheck. For the sake of simplicity, let's assume
> that the file under inspection only has a module definiton and no
> imports or top levels.
>
> Functionally, my code is working great and I am able to do what I want
> with the typechecked tree.
>
> However, load is very slow (~10 seconds user time) on large projects.
> Here is a cpu time trace of my program (milliseconds):
>
>   main  1
>   parse flags  93
>   load  20436
>   typecheck 20437
>
> I can enable a bit more ghc timing info via -Rghc-timings and I see
>
>   !!! Chasing dependencies: finished in 157.20 milliseconds, allocated
>   528.112 megabytes
>
> This seems fine, anything sub-second is ok.
>
> But then I see a bunch of home modules in CodeGen that I was not expecting:
>
>!!! CodeGen [My.Module.Dependency]:
>finished in 3335.62 milliseconds, allocated 270.615 megabytes
>
> So it looks like the targetAllowObjCode is being ignored... is there any
> way to force it? Actually I'd prefer to fail fast than to ever compile
> or codegen a dependency module.
>
>
> I know that it should be possible to load the module a lot faster
> because if I make a small change in the file under inspection and ask
> cabal to recompile the module it is super fast (less than a second).
>
> Could somebody who understands how incremental/partial compiles work
> please help me out?
>
>
> PS: If this textual description is confusing, I could put together a
> minimal reproduction and example project but it will take me some time
> to do that.
>
> --
> Best regards,
> Sam
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Coercible questions

[Brandon Allbery]

I think there's some work going on to expose the representations, which
would enable some ability to coerce. But possibly not this much, as they're
separate RuntimeReps so you don't combine signed and unsigned numbers
inadvertently; currently that's a little magical inside ghc iirc, with the
RuntimeRep the only way to distinguish at all and that vanishing
post-typechecking.

On Sat, Oct 5, 2019 at 12:30 PM Michal Terepeta 
wrote:

> Adding +ghc-devs  to continue the thread
>
> Hi Sandy,
>
> Thanks for the answer! Do you think there is some fundamental reason for
> this? Or just a matter of implementing this in GHC? It seems to me that
> this should work just fine as long as the runtime representation is the
> same.
>
> And a related question--is it safe to `unsafeCoerce` an `Int` to a `Word`?
> The only reason for why this could be problematic that comes to my mind is
> that there could be an assumption that different `data`s do not alias each
> other (although `newtype`s can due to `Coercible` functionality). But I'm
> not sure this is ever used by GHC? Are there any other reasons why this
> could be problematic?
>
> Thanks!
>
> - Michal
>
>
>
> On Sat, Oct 5, 2019 at 5:27 PM Sandy Maguire 
> wrote:
>
>> Hi Michal,
>>
>> Datas aren't coercible, only newtypes. This is why you can't coerce Ints
>> and Words, and why Foo and Bar don't work.
>>
>> Sandy
>>
>> On Sat, Oct 5, 2019 at 4:17 PM Michal Terepeta 
>> wrote:
>>
>>> Hi,
>>>
>>> I've started looking into using `Data.Coerce` (and the `Coercible`
>>> type-class) for a personal project and was wondering why coercing between
>>> `Int` and `Word` is not allowed? I don't see any fundamental reason why
>>> this shouldn't work...
>>>
>>> Perhaps, it's just a matter of GHC's implementation details leaking out?
>>> IIRC internally GHC has separate `RuntimeRep`/`PrimRep` for a `Word#` and
>>> for an `Int#`. If that's the case, would it make sense to unify these?
>>> Their actual runtime representation should be the same and I'd expect most
>>> (all?) of their differences should be attached to `PrimOp`s.
>>>
>>> And that leads me to another question--what exactly goes wrong here:
>>> ```
>>> data Foo = Foo Int#
>>> data Bar = Bar Int#
>>>
>>> test :: Bar
>>> test = coerce (Foo 42#)
>>> ```
>>> Which fails with: "Couldn't match representation of type ‘Foo’ with
>>> that of ‘Bar’ arising from a use of ‘coerce’"
>>>
>>> Perhaps I'm just misunderstanding exactly how `Coercible` works?
>>>
>>> Thanks in advance!
>>>
>>> - Michal
>>>
>>> PS. The ability to coerce through things like lists is amazing :)
>>> ___
>>> ghc-devs mailing list
>>> ghc-devs@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>
>>
>> --
>> I'm currently travelling the world, sleeping on people's couches and
>> doing full-time collaboration on Haskell projects. If this seems
>> interesting to you, please consider signing up as a host!
>> https://isovector.github.io/erdos/
>>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC/StgToCmm/Con.hs

[Brandon Allbery]

"Con.hs" (or the same with any other extension) is a reference to the
console device on Windows. Same for Prn.whatever and other filenames that
overlap device names.

On Sat, Sep 14, 2019 at 3:17 PM Shayne Fletcher via ghc-devs <
ghc-devs@haskell.org> wrote:

> Anyone understand what's going on here (HEAD) on Windows?
> ```
> 2019-09-14T19:06:40.1438283Z # Running: git clone
> https://gitlab.haskell.org/ghc/ghc.git
> 2019-09-14T19:06:40.1879263Z Cloning into 'ghc'...
> 2019-09-14T19:07:02.4403717Z error: unable to stat just-written file
> compiler/GHC/StgToCmm/Con.hs: No such file or directory
> ```
>
> --
> *Shayne Fletcher*
> Language Engineer */* +1 917 699 7663
> *Digital Asset* , creators of *DAML
> *
>
> This message, and any attachments, is for the intended recipient(s) only,
> may contain information that is privileged, confidential and/or proprietary
> and subject to important terms and conditions available at
> http://www.digitalasset.com/emaildisclaimer.html. If you are not the
> intended recipient, please delete this message.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC: Policy on -O flags?

[Brandon Allbery]

I think at first you just give it a -f flag, and let experience determine
whether it should be part of -O or -O2.

On Tue, Aug 27, 2019 at 12:10 PM Andreas Klebinger 
wrote:

> Hello ghc-devs and haskell users.
>
> I'm looking for opinions on when an optimization should be enabled by
> default.
>
> -O is currently the base line for an optimized build.
> -O2 adds around 10-20% compile time for a few % (around 2% if I remember
> correctly) in performance for most things.
>
> The question is now if I implement a new optimization, making code R%
> faster but slowing
> down the compiler down by C% at which point should an optimization be:
>
> * Enabled by default (-O)
> * Enabled only at -O2
> * Disabled by default
>
> Cheap always beneficial things make sense for -O
> Expensive optimizations which add little make sense for -O2
>
> But where exactly is the line here?
> How much compile time is runtime worth?
>
> If something slows down the compiler by 1%/2%/5%
> and speeds up code by 0.5%/1%/2% which combinations make sense
> for -O, -O2?
>
> Can there even be a good policy with the -O/-O2 split?
>
> Personally I generally want code to either:
> * Typecheck/Run at all (-O0, -fno-code, repl)
> * Not blow through all my RAM when adding a few Ints while developing: -O ?
> * Make a reasonable tradeoff between runtime/compiletime: -O ?
> * Give me all you got: -O2 (-O9)
>
> The use case for -O0 is rather clear, so is -O2.
> But what do people consider the use case for -O
>
> What trade offs seem acceptable to you as a user of GHC?
>
> Is it ok for -O to become slower for faster runtimes? How much slower?
> Should all new improvements which might slow down compilation
> be pushed to -O2?
>
> Or does an ideal solution add new flags?
> Tell me what do you think.
>
> Cheers,
> Andreas Klebinger
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Linker error when adding a new source file

[Brandon Allbery]

>From the looks of it, you're building with a bootstrap compiler (stage 0).
Does the build compiler need to have this in its runtime libraries for the
built compiler to work? This will require you to work it in in multiple
versions, the first providing it without using it and the next using the
provided one.

On Fri, Aug 23, 2019 at 12:03 PM Jan van Brügge  wrote:

> Hi,
>
> in order to clean up my code, I've moved a bunch of stuff to a new
> source file, `TcRowTys.hs` that works similar to `TcTypeNats.hs`. But
> when trying to compile a clean build of GHC, I get a linker error:
>
> ```
>
> | Run Ghc LinkHs Stage0: _build/stage0/ghc/build/c/hschooks.o (and 1
> more) => _build/stage0/bin/ghc
>
> _build/stage0/lib/../lib/x86_64-linux-ghc-8.6.5/ghc-8.9.0.20190722/libHSghc-8.9.0.20190722.a(PrelInfo.o)(.text+0x2814):
> error: undefined reference to 'ghc_TcRowTys_rowTyCons_closure'
>
> _build/stage0/lib/../lib/x86_64-linux-ghc-8.6.5/ghc-8.9.0.20190722/libHSghc-8.9.0.20190722.a(PrelInfo.o)(.data+0x578):
> error: undefined reference to 'ghc_TcRowTys_rowTyCons_closure'
>
> _build/stage0/lib/../lib/x86_64-linux-ghc-8.6.5/ghc-8.9.0.20190722/libHSghc-8.9.0.20190722.a(TcHsType.o)(.data+0xdd8):
> error: undefined reference to 'ghc_TcRowTys_rnilTyCon_closure'
> collect2: Fehler: ld gab 1 als Ende-Status zurück
> `gcc' failed in phase `Linker'. (Exit code: 1)
>
> ```
>
> I had a look at the Wiki including the FAQ, but did not fine anything
> about that topic. Does someone know what I have to do for this to work?
>
> Cheers,
> Jan
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Conveniently searching GitLab

[Brandon Allbery]

You can define them in the settings; what's odd about them is that it's
part of "Manage search engines". Which is at the bottom of the right click
menu in the location bar (with "edit" instead of "manage", so it should be
just as easy to do.

On Tue, Aug 6, 2019 at 12:41 PM Ben Gamari  wrote:

> Hello everyone,
>
> I've long found GitLab's search interface to be rather clunky. Several
> of the issues I've noted have been reported upstream but progress in
> resolving them seems to be slow.
>
> Consequently, I have implemented a workaround [1] which addresses most of
> my typical use-cases. This is essentially a thin wrapper around GitLab's
> various search facilities which intelligently routes requests according
> to a simple (and hopefully intuitive) query syntax. For instance, to
>
>  * navigate to GHC issue #123:
>search for `#123`
>
>  * search for GHC issues related to unboxed tuples:
>search for `# unboxed tuples`
>
>  * navigate to the `ghc/head.hackage` project:
>search for `ghc/head.hackage>`
>
>  * navigate to merge request !3 of the `ghc/head.hackage` project:
>search for `ghc/head.hackage!3`
>
>  * navigate to commit e130fb57f7991575d848612abafe9ad10129131c of the
>`ghc/ghc` project:
>search for `ghc/ghc@e130fb57f7991575d848612abafe9ad10129131c`
>
>  * search for merge requests of `haskell/ghcup` pertaining to Darwin:
>search for `haskell/ghcup! Darwin`
>
> Note that, as seen in the first two examples, the project name defaults
> to `ghc/ghc` if omitted.
>
> This interface is best used via your browser's search keywords feature
> [2]. To add a search keyword in Firefox you can right click on the
> search query input field and select "Add search keyword". To my
> surprise I didn't find a similarly convenient shortcut in Chromium.
>
> If you can think of any way in which the service can be improved, feel
> free to open a pull request against the upstream repository [3].
>
> Cheers,
>
> - Ben
>
>
> [1] https://search.gitlab.haskell.org/
> [2] http://kb.mozillazine.org/Using_keyword_searches
> [3] https://gitlab.haskell.org/bgamari/gitlab-search-service
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: api to access .hi files

[Brandon Allbery]

No, those are in base. But I don't think you would be seeing imported names
as such there, come to think of it, only names declared locally.

On Fri, Aug 2, 2019 at 4:06 PM Sam Halliday  wrote:

> Brandon Allbery  writes:
>
> > At a guess, because the ghc package defaults to being hidden (it's
> creating
> > a new ghc instance at runtime, so the visibility of the ghc package when
> > compiling your code is not relevant) you need to do the ghc-api
> equivalent
> > of "-package ghc". Or for testing just "ghc-pkg expose ghc".
>
> Hmm, would that also explain why the Prelude and Control.Monad modules
> are not shown either?
>
> Is there a way to expose all modules programmatically?
>
>
> >
> > On Fri, Aug 2, 2019 at 3:47 PM Sam Halliday 
> wrote:
> >
> >> To answer my own question with a solution and another question:
> >>
> >> Sam Halliday writes:
> >> > I'm mostly interested in gathering information about symbols and their
> >> > type signatures. As a first exercise: given a module+import section
> >> > for a haskell source file, I want to find out which symbols (and their
> >> > types) are available. Like :browse in ghci, but programmatically.
> >>
> >> This is answered by Stephen Diehl's blog post on the ghc api! How lucky
> >> I am: http://www.stephendiehl.com/posts/ghc_01.html
> >>
> >> He points to getNamesInScope
> >>
> >> Unfortunately I'm getting zero Names back when loading a file that
> >> imports several modules from ghc. Is there something I'm missing in the
> >> following?
> >>
> >> module Main where
> >>
> >> import   Control.Monad
> >> import   Control.Monad.IO.Class
> >> import   GHC
> >> import   GHC.Paths  (libdir)
> >>
> >> main = runGhc (Just libdir) $ do
> >>   dflags <- getSessionDynFlags
> >>   void $ setSessionDynFlags $ dflags {
> >>   hscTarget = HscInterpreted
> >> , ghcLink   = LinkInMemory
> >> }
> >>   addTarget $ Target (TargetFile "exe/Main.hs" Nothing) False Nothing
> >>   res <- load LoadAllTargets
> >>   liftIO $ putStrLn $ showPpr dflags res
> >>   names <- getNamesInScope
> >>   liftIO $ putStrLn $ "seen " <> (show $ length names) <> " Names"
> >>
> >>
> >> --
> >> Best regards,
> >> Sam
> >> ___
> >> ghc-devs mailing list
> >> ghc-devs@haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >>
> >
> >
> > --
> > brandon s allbery kf8nh
> > allber...@gmail.com
>
> --
> Best regards,
> Sam
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: api to access .hi files

[Brandon Allbery]

At a guess, because the ghc package defaults to being hidden (it's creating
a new ghc instance at runtime, so the visibility of the ghc package when
compiling your code is not relevant) you need to do the ghc-api equivalent
of "-package ghc". Or for testing just "ghc-pkg expose ghc".

On Fri, Aug 2, 2019 at 3:47 PM Sam Halliday  wrote:

> To answer my own question with a solution and another question:
>
> Sam Halliday writes:
> > I'm mostly interested in gathering information about symbols and their
> > type signatures. As a first exercise: given a module+import section
> > for a haskell source file, I want to find out which symbols (and their
> > types) are available. Like :browse in ghci, but programmatically.
>
> This is answered by Stephen Diehl's blog post on the ghc api! How lucky
> I am: http://www.stephendiehl.com/posts/ghc_01.html
>
> He points to getNamesInScope
>
> Unfortunately I'm getting zero Names back when loading a file that
> imports several modules from ghc. Is there something I'm missing in the
> following?
>
> module Main where
>
> import   Control.Monad
> import   Control.Monad.IO.Class
> import   GHC
> import   GHC.Paths  (libdir)
>
> main = runGhc (Just libdir) $ do
>   dflags <- getSessionDynFlags
>   void $ setSessionDynFlags $ dflags {
>   hscTarget = HscInterpreted
> , ghcLink   = LinkInMemory
> }
>   addTarget $ Target (TargetFile "exe/Main.hs" Nothing) False Nothing
>   res <- load LoadAllTargets
>   liftIO $ putStrLn $ showPpr dflags res
>   names <- getNamesInScope
>   liftIO $ putStrLn $ "seen " <> (show $ length names) <> " Names"
>
>
> --
> Best regards,
> Sam
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC native bootstrap

[Brandon Allbery]

IIRC another way to do this, which was and possibly still is used on ARM,
is to compile on the host with -fllvm, saving the LLVM IR output, and then
run opt on the target. This requires the target have an LLVM toolchain at
the same (or at least IR compatible, but note that they make few if any
guarantees about this) version as the host.

On Mon, Jul 22, 2019 at 9:52 AM Ben Gamari  wrote:

> Igor Chudov  writes:
>
> > Thanks, Ben!
> >
> > I read old docs and found that it was mentioned that it's possible to
> > start bootstrap with GHC 4.08.2 and HC files supplied. I performed
> > "./configure && make" stage on x86_64 machine and moved sources to the
> > desired machine (and successfully patched some files to work with
> > exotic C compiler) but encountered
>
> Oh dear; I missed the fact that you lack a cross-compiling toolchain.
> Things are much easier if you can cross-compile.
>
> Given your situation your approach is probably the best you can do.
> I have never done a native bootstrap like this and consequently have no
> idea what challenges lay in wait. It sounds like it may be a long road,
> however.
>
> Cheers,
>
> - Ben
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: gitlab sometimes slow

[Brandon Allbery]

I rather suspect it'd be more like "per some period" than a one-time fee,
and "$100/month" is rather harder than "$100".

On Wed, Jul 17, 2019 at 11:20 AM Richard Eisenberg  wrote:

> Hi all,
>
> GitLab is sometimes a bit slow. I understand we host this ourselves, and
> faster is more expensive. My question: how much more expensive? That is, if
> we throw $100 at the problem, will gitlab be speedy? Will it take $1,000?
> $10,000? If it's the first one, then let's just blast ahead. If it's not,
> perhaps knowing what it would take would either help me accept the status
> quo (I know that every time my page loads slowly, the Haskell community has
> saved several dollars) or we could contemplate chipping in somehow.
>
> Thanks!
> Richard
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Issue weight migration

[Brandon Allbery]

Isn't there already a "needs triage" label separate from this? Which would
make that plus explicit priority a suggested priority to guide whoever's
doing triage. (I expect triage goes beyond simply priority setting, e.g.
making sure it has the right component(s) and maybe assigning specific
people who know that component.)

On Mon, Jul 8, 2019 at 6:43 AM Ben Gamari  wrote:

> Simon Peyton Jones via ghc-devs  writes:
>
> > Thanks Ben.   Did we agree to have
> >
> > * 3 explicit labels (high, normal, low)
> >
> > * With absence of a label indicating "has not been assigned a priority"
> >   which you can also read as "needs triage".
> >
> > I would strongly prefer not to have
> >   "no label" = "low priority"
> > as I described earlier
> >
> We actually have four labels (highest, high, normal, low), mirroring
> Trac. On further reflection I agree with you; "no label" = "normal
> priority" left a bit too much implicit.
>
> Regardless, whether we want to equate the lack of a priority label with
> "needs triage" is another decision. I'm not opposed to this but I do
> wonder whether issue reporters might be tempted to set the ticket
> priority, thereby inadvertently circumventing the usual triage process.
>
> Cheers,
>
> - Ben
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Gitlab workflow

[Brandon Allbery]

For one, merge commits tend to be big, annoying, and a problem for anyone
who finds themself working on something that someone else just blew away or
rewrote because they weren't checking back and you can't pick only part of
the merge commit unless it's itself broken into multiple commits per file
or sub-change (yes ideally they all would be the latter, but then you just
made big changes like refactorings impossible). The more distributed the
project is, the more rebase makes a lot of sense vs. merge commits; you
need a lot more central planning and organization for merge commits to work
well. Which itself seems kinda anti-git.

On Sat, Jul 6, 2019 at 1:06 PM Bryan Richter  wrote:

> I can't help but notice that there are a lot of issues caused by
> adhering to a rebase-only workflow. I understand that lots of projects
> use this workflow, but I still don't understand its popularity. Git is
> just not designed to be used this way (although I admit that git is
> flexible enough to make that statement contentious).
>
> For instance, this current issue is due to how git tracks revisions. Git
> doesn't care about Merge Requests or Issue Numbers. It just knows the
> cryptographic hashes of the worktree's contents including the set of
> commits leading up to the current commit. If you change commits by
> rebasing, git just sees brand-new commits.
>
> GitHub and GitLab seem to be making things worse by relying on git's
> design while layering features on top that are only sort-of compatible.
> Brand-new commits created by a rebase are no longer tied to the original
> Merge Request, since it is reliant on the very hashes that got
> obliviated by the rebase. But it's not just GitLab that gets stymied: A
> bunch of handy git commands like `git branch --contains` end up being
> useless as well. I will resist the urge to stand up even taller on my
> soapbox and list all the other convenient features of git that get
> broken by rebasing, so suffice to say that the downsides to Plain Old
> Merges that do exist seem nonetheless trivial in comparison.
>
> Rather than argue against GHC's current practices, however, I would like
> to understand them better. What issues led to a rebase-only workflow?
> Which expert opinions were considered? What happy stories can people
> relate? We recently switched away from a rebase-only workflow at
> $workplace, and it's already made life so much nicer for us -- so I'm
> curious what unforeseen pain we might be in for. :)
>
> -Bryan
>
> On 7/5/19 3:14 PM, Matthew Pickering wrote:
> > The target branch is already correct. The way to get the merge status
> > is to first rebase the branch before pushing the merge commit.
> > Unfortunately the rebase API is very slow and buggy so we had to stop
> > using it.
> >
> >
> > On Fri, Jul 5, 2019 at 1:05 PM Elliot Cameron 
> wrote:
> >> Could Marge change the target branch of an MR before merging it?
> Perhaps this would convince GitLab to show the right info.
> >>
> >> On Fri, Jul 5, 2019, 6:18 AM Simon Peyton Jones via ghc-devs <
> ghc-devs@haskell.org> wrote:
> >>> |  You believe the one which marge posts telling you that the patch is
> >>> |  merged, the commit it links to is on master so you can clearly see
> the
> >>> |  patch has been committed.
> >>>
> >>> OK.  The earlier one, also from Marge, not the Discussion stream but
> rather in the panel at the top, says
> >>>
> >>>  Closed by Marge Bot 8 hours ago
> >>>  The changes were not merged into master
> >>>
> >>> So that is an outright lie?   Yes it is closed, but contrary to the
> statement it _has_ been merged.
> >>>
> >>> It's unfortunate that this misleading display is right at top, in the
> summary material, while the truth (that it has been merged) is buried in
> the Discussion stream.
> >>>
> >>> Alas.  But thank you for clarifying.
> >>>
> >>> Is this something we can raise with the Gitlab folk?  It seems so
> egregiously wrong.
> >>>
> >>> Simon
> >>>
> >>>
> >>> |  -Original Message-
> >>> |  From: Matthew Pickering 
> >>> |  Sent: 05 July 2019 10:55
> >>> |  To: Simon Peyton Jones 
> >>> |  Cc: ghc-devs 
> >>> |  Subject: Re: Gitlab workflow
> >>> |
> >>> |  It's not possible to make the MR status merged and also have a
> reliable
> >>> |  merge bot. We used to try to make the status merged but it caused
> too
> >>> |  much instability.
> >>> |
> >>> |  Merge trains might eventually work but the current iteration is not
> >>> |  suitable as it doesn't work with forks.
> >>> |
> >>> |  You believe the one which marge posts telling you that the patch is
> >>> |  merged, the commit it links to is on master so you can clearly see
> the
> >>> |  patch has been committed.
> >>> |
> >>> |  Matt
> >>> |
> >>> |  On Fri, Jul 5, 2019 at 10:43 AM Simon Peyton Jones
> >>> |   wrote:
> >>> |  >
> >>> |  > |  No it is not possible due to the use of Marge to merge patches.
> >>> |  > | Gitlab
> >>> |  >
> >>> |  > By "it" is not possible, you mean that it's not possible to make

Re: Hadrian: Suddenly a full build fails with: Rules may not be recursive

[Brandon Allbery]

"-c" is a bad option that conflates configuration and build, and leads to
this when certain kinds of configuration changes happen and alter the build
rules that are already running. Stop using "-c" and reconfigure properly
(./boot etc.). Yes, it's "convenient", right up until this happens. And
eventually this *will* happen, because configuration should not be done via
build rules.

On Fri, Jun 21, 2019 at 12:55 PM Roland Senn  wrote:

> Hi,
>
> Suddenly I'm unable to build! As usual, I did:
>
> git pull upstream master --recurse-submodules=yes
> git submodule update --init --recursive
>
>
> $ hadrian/build.sh clean
> Up to date
> | Removing Hadrian files...
> | Remove directory _build/stage0
> | Remove directory _build/stage1
> | Remove directory _build/stage2
> | Remove directory _build/stage3
> | Remove directory sdistprep
> | Remove directory _build (after build completes)
> | Done.
>
> ... + statistics
>
> $ hadrian/build.sh -c --flavour=devel2 -j2
> Up to date
> | Running boot...
> Error when running Shake build system:
>   at action, called at src/Rules.hs:68:19 in main:Rules
>   at apply1, called at
> src/Development/Shake/Internal/Rules/Oracle.hs:159:32 in shake-0.18.2-
> fca156899176fbf7a9b05f30b3ec991784b3e60af38a503ea1cb277fd96f971e:Develo
> pment.Shake.Internal.Rules.Oracle
> * Depends on: OracleQ (KeyValue ("hadrian/cfg/system.config","host-
> os"))
>   at need, called at src/Hadrian/Oracles/TextFile.hs:90:9 in
> main:Hadrian.Oracles.TextFile
> * Depends on: hadrian/cfg/system.config
>   at &%>, called at src/Rules/Configure.hs:21:5 in main:Rules.Configure
> * Depends on: hadrian/cfg/system.config mk/config.h compiler/ghc.cabal
> rts/rts.cabal
>   at apply1, called at
> src/Development/Shake/Internal/Rules/Oracle.hs:159:32 in shake-0.18.2-
> fca156899176fbf7a9b05f30b3ec991784b3e60af38a503ea1cb277fd96f971e:Develo
> pment.Shake.Internal.Rules.Oracle
> * Depends on: OracleQ (KeyValue ("hadrian/cfg/system.config","host-
> os"))
> * Raised the exception:
> Build system error - recursion detected:
>   Key type:   OracleQ KeyValue
>   Key value:  OracleQ (KeyValue ("hadrian/cfg/system.config","host-
> os"))
> Rules may not be recursive
>
>
> OS is Linux Debian 9 (x86_64)
>
> Any ideas what's wrong??
>
> Many thanks and kind regards
>Roland
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Pushing to gitlab.haskell.org

[Brandon Allbery]

Exactly. Also it makes some sense to use https for fetch but ssh for push;
that's how I have my own repos and those for various other projects set up.

On Mon, Jun 3, 2019 at 12:34 PM Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> |  You probably need to use the "git@" remote.
> |
> |  g...@gitlab.haskell.org:ghc/ghc.git
> |
> |  git remote set-url origin g...@gitlab.haskell.org:ghc/ghc.git
>
> Correct!  I don't know how this worked before. (Maybe it never did; this
> is a relatively new machine.)
>
> Maybe we should change the guidance on
> https://gitlab.haskell.org/ghc/ghc/wikis/building/getting-the-sources
>
> to give the git url?  Or does that /require/ ssh and hence exclude some
> folk?
>
> Simon
>
> |  -Original Message-
> |  From: Matthew Pickering 
> |  Sent: 03 June 2019 15:08
> |  To: Simon Peyton Jones 
> |  Subject: Re: Pushing to gitlab.haskell.org
> |
> |  You probably need to use the "git@" remote.
> |
> |  g...@gitlab.haskell.org:ghc/ghc.git
> |
> |  git remote set-url origin g...@gitlab.haskell.org:ghc/ghc.git
> |
> |
> |  On Mon, Jun 3, 2019 at 3:04 PM Simon Peyton Jones via ghc-devs  |  d...@haskell.org> wrote:
> |  >
> |  > Devs
> |  >
> |  > Suddenly I can’t push to (a non-master branch on) gitlab.haskell.org.
> |  >
> |  > In .git/config I have
> |  >
> |  > [remote "origin"]
> |  >
> |  >   url =
> |  >
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
> |  > ab.haskell.org%2Fghc%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com
> %
> |  > 7C186b15a68a134060a1bd08d6e82ce8b3%7C72f988bf86f141af91ab2d7cd011db47%
> |  > 7C1%7C0%7C636951676910548930&sdata=cTjUrROo3Dje%2FlbiFdtUPadlFUPsN
> |  > 2OWUgLIOYv%2BL8o%3D&reserved=0
> |  >
> |  >   fetch = +refs/heads/*:refs/remotes/origin/*
> |  >
> |  > [branch "master"]
> |  >
> |  >   remote = origin
> |  >
> |  >   merge = refs/heads/master
> |  >
> |  > An attempt to push leads to a request for a username.  If I enter
> one, a
> |  request for a password.
> |  >
> |  > simonpj@MSRC-3645512:~/code/HEAD$ git push origin wip/T16735
> |  >
> |  > Username for
> |  '
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.
> |  haskell.org&data=02%7C01%7Csimonpj%40microsoft.com
> %7C186b15a68a134060a
> |
> 1bd08d6e82ce8b3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6369516769105
> |
> 48930&sdata=O%2F%2B7WovumSLxe8%2FXrh1NpowWs%2FYVqhdEsDCsM5diz%2Bk%3D&a
> |  mp;reserved=0':   C-c C-c
> |  >
> |  > I thought I had SSH keys uploaded.  But in fact I found that my
> |  id_rsa.pub was a bit different to the one in gitlab.  Not sure _how_
> that
> |  happened, or why it hasn’t bitten before.
> |  >
> |  > So I uploaded a new id_rsa.pub key.
> |  >
> |  > Same behaviour.
> |  >
> |  > So I tried ssh -v gitlab.haskell.org, and got the output below.   It
> |  seems to skip id_dsa, but doesn’t even try id_rsa.
> |  >
> |  > Can anyone help? This is tiresome.
> |  >
> |  > Thanks
> |  >
> |  > Simon
> |  >
> |  >
> |  >
> |  > simonpj@MSRC-3645512:~/code/HEAD$ ssh -v gitlab.haskell.org
> |  >
> |  > OpenSSH_7.6p1 Ubuntu-4, OpenSSL 1.0.2n  7 Dec 2017
> |  >
> |  > debug1: Reading configuration data /home/simonpj/.ssh/config
> |  >
> |  > debug1: Reading configuration data /etc/ssh/ssh_config
> |  >
> |  > debug1: /etc/ssh/ssh_config line 19: Applying options for *
> |  >
> |  > debug1: Connecting to gitlab.haskell.org [2604:1380:0:8900::3] port
> 22.
> |  >
> |  > debug1: Connection established.
> |  >
> |  > debug1: identity file /home/simonpj/.ssh/id_rsa type 0
> |  >
> |  > debug1: key_load_public: No such file or directory
> |  >
> |  > debug1: identity file /home/simonpj/.ssh/id_rsa-cert type -1
> |  >
> |  > debug1: identity file /home/simonpj/.ssh/id_dsa type 1
> |  >
> |  > debug1: key_load_public: No such file or directory
> |  >
> |  > debug1: identity file /home/simonpj/.ssh/id_dsa-cert type -1
> |  >
> |  > debug1: key_load_public: No such file or directory
> |  >
> |  > debug1: identity file /home/simonpj/.ssh/id_ecdsa type -1
> |  >
> |  > debug1: key_load_public: No such file or directory
> |  >
> |  > debug1: identity file /home/simonpj/.ssh/id_ecdsa-cert type -1
> |  >
> |  > debug1: key_load_public: No such file or directory
> |  >
> |  > debug1: identity file /home/simonpj/.ssh/id_ed25519 type -1
> |  >
> |  > debug1: key_load_public: No such file or directory
> |  >
> |  > debug1: identity file /home/simonpj/.ssh/id_ed25519-cert type -1
> |  >
> |  > debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4
> |  >
> |  > debug1: Remote protocol version 2.0, remote software version
> |  > OpenSSH_7.9
> |  >
> |  > debug1: match: OpenSSH_7.9 pat OpenSSH* compat 0x0400
> |  >
> |  > debug1: Authenticating to gitlab.haskell.org:22 as 'simonpj'
> |  >
> |  > debug1: SSH2_MSG_KEXINIT sent
> |  >
> |  > debug1: SSH2_MSG_KEXINIT received
> |  >
> |  > debug1: kex: algorithm: curve25519-sha...@libssh.org
> |  >
> |  > debug1: kex: host key algorithm: ssh-ed25519
> |  >
> |  >

Re: setsockopt IPV2_TCLASS 8

[Brandon Allbery]

A quick search suggests this is a WSL shortcoming and is harmless.

On Mon, Jun 3, 2019 at 12:48 PM Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> I’m getting a lot of these messages from ssh when using git
>
> setsockopt IPV6_TCLASS 8: Operation not permitted:
>
> (Same thing when directly invoking ssh g...@gitlab.haskell.org)
>
> Should I worry?
>
> Simon
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Container type classes

[Brandon Allbery]

I was talking in general about why you don't find instances of Monad, etc.
for Set or Map which require an additional constraint on the key.

On Thu, May 30, 2019 at 5:36 PM Andrey Mokhov 
wrote:

> Hi Brandon,
>
>
>
> Could you show the code?
>
>
>
> I have no idea how indexed monads could possibly be related here. All I
> want is to have a type class that unifies these two methods:
>
>
>
> singleton :: a -> Set a
>
> map :: Ord b => (a -> b) -> Set a -> Set b
>
>
>
> singleton :: Int -> IntSet
>
> map :: (Int -> Int) -> IntSet -> IntSet
>
>
>
> Cheers,
>
> Andrey
>
>
>
> *From:* Brandon Allbery [mailto:allber...@gmail.com]
> *Sent:* 30 May 2019 22:32
> *To:* Andrey Mokhov 
> *Cc:* Artem Pelenitsyn ; Andreas Klebinger <
> klebinger.andr...@gmx.at>; ghc-devs@haskell.org
> *Subject:* Re: Container type classes
>
>
>
> They can, with more work. You want indexed monads, so you can describe
> types that have e.g. an ordering constraint as well as the Monad constraint.
>
>
>
> On Thu, May 30, 2019 at 5:26 PM Andrey Mokhov <
> andrey.mok...@newcastle.ac.uk> wrote:
>
> Hi Artem,
>
>
>
> Thanks for the pointer, but this doesn’t seem to be a solution to my
> challenge: they simply give up on overloading `map` for both Set and
> IntSet. As a result, we can’t write polymorphic functions over Set and
> IntSet if they involve any mapping.
>
>
>
> I looked at the prototype by Andreas Klebinger, and it doesn’t include the
> method `setMap` either.
>
>
>
> Perhaps, Haskell’s type classes just can’t cope with this problem.
>
>
>
> *ducks for cover*
>
>
>
> Cheers,
>
> Andrey
>
>
>
> *From:* Artem Pelenitsyn [mailto:a.pelenit...@gmail.com]
> *Sent:* 30 May 2019 20:56
> *To:* Andrey Mokhov 
> *Cc:* ghc-devs@haskell.org; Andreas Klebinger 
> *Subject:* Re: Container type classes
>
>
>
> Hi Andrey,
>
>
>
> FWIW, mono-traversable (
> http://hackage.haskell.org/package/mono-traversable) suggests decoupling
> IsSet and Funtor-like.
>
>
>
> In a nutshell, they define the IsSet class (in Data.Containers) with
> typical set operations like member and singleton, union and intersection.
> And then they tackle a (seemingly) independent problem of mapping
> monomorphic containers (like IntSet, ByteString, etc.) with a separate
> class MonoFunctor (in Data.MonoTraversable):
>
>
>
> class MonoFunctor mono where
> omap :: (Element mono -> Element mono) -> mono -> mono
>
>
>
> And gazillion of instances for both polymorphic containers with a fixed
> type parameter and monomorphic ones.
>
>
>
> --
>
> Best wishes,
>
> Artem
>
>
>
> On Thu, 30 May 2019 at 20:11, Andrey Mokhov 
> wrote:
>
> Hi all,
>
> I tried to use type classes for unifying APIs of several similar data
> structures and it didn't work well. (In my case I was working with graphs,
> instead of sets or maps.)
>
> First, you rarely want to be polymorphic over the set representation,
> because you care about performance. You really want to use that
> Very.Special.Set.insert because it has the right performance
> characteristics for your task at hand. I found only *one* use-case for
> writing polymorphic functions operating on something like IsSet: the
> testsuite. Of course, it is very nice to write a single property test like
>
> memberInsertProperty x set = (member x (insert x set) == True)
>
> and then use it for testing all set data structures that implement
> `member` and `insert`. Here you don't care about performance, only about
> correctness!
>
> However, this approach leads to problems with type inference, confusing
> error messages, and complexity. I found that it is much nicer to use
> explicit dictionary passing and write something like this instead:
>
> memberInsertProperty SetAPI{..} x set = (member x (insert x set) == True)
>
> where `member` and `insert` come from the SetAPI record via
> RecordWildCards.
>
> Finally, I'm not even sure how to create a type class covering Set and
> IntSet with the following two methods:
>
> singleton :: a -> Set a
> map :: Ord b => (a -> b) -> Set a -> Set b
>
> singleton :: Int -> IntSet
> map :: (Int -> Int) -> IntSet -> IntSet
>
> Could anyone please enlighten me about the right way to abstract over this
> using type classes?
>
> I tried a few approaches, for example:
>
> class IsSet s where
> type Elem s
> singleton :: Elem s -> s
> map :: Ord (Elem t) => (Elem s -> Elem t) -> s -> t
>
> Looks ni

Re: Container type classes

[Brandon Allbery]

They can, with more work. You want indexed monads, so you can describe
types that have e.g. an ordering constraint as well as the Monad constraint.

On Thu, May 30, 2019 at 5:26 PM Andrey Mokhov 
wrote:

> Hi Artem,
>
>
>
> Thanks for the pointer, but this doesn’t seem to be a solution to my
> challenge: they simply give up on overloading `map` for both Set and
> IntSet. As a result, we can’t write polymorphic functions over Set and
> IntSet if they involve any mapping.
>
>
>
> I looked at the prototype by Andreas Klebinger, and it doesn’t include the
> method `setMap` either.
>
>
>
> Perhaps, Haskell’s type classes just can’t cope with this problem.
>
>
>
> *ducks for cover*
>
>
>
> Cheers,
>
> Andrey
>
>
>
> *From:* Artem Pelenitsyn [mailto:a.pelenit...@gmail.com]
> *Sent:* 30 May 2019 20:56
> *To:* Andrey Mokhov 
> *Cc:* ghc-devs@haskell.org; Andreas Klebinger 
> *Subject:* Re: Container type classes
>
>
>
> Hi Andrey,
>
>
>
> FWIW, mono-traversable (
> http://hackage.haskell.org/package/mono-traversable) suggests decoupling
> IsSet and Funtor-like.
>
>
>
> In a nutshell, they define the IsSet class (in Data.Containers) with
> typical set operations like member and singleton, union and intersection.
> And then they tackle a (seemingly) independent problem of mapping
> monomorphic containers (like IntSet, ByteString, etc.) with a separate
> class MonoFunctor (in Data.MonoTraversable):
>
>
>
> class MonoFunctor mono where
> omap :: (Element mono -> Element mono) -> mono -> mono
>
>
>
> And gazillion of instances for both polymorphic containers with a fixed
> type parameter and monomorphic ones.
>
>
>
> --
>
> Best wishes,
>
> Artem
>
>
>
> On Thu, 30 May 2019 at 20:11, Andrey Mokhov 
> wrote:
>
> Hi all,
>
> I tried to use type classes for unifying APIs of several similar data
> structures and it didn't work well. (In my case I was working with graphs,
> instead of sets or maps.)
>
> First, you rarely want to be polymorphic over the set representation,
> because you care about performance. You really want to use that
> Very.Special.Set.insert because it has the right performance
> characteristics for your task at hand. I found only *one* use-case for
> writing polymorphic functions operating on something like IsSet: the
> testsuite. Of course, it is very nice to write a single property test like
>
> memberInsertProperty x set = (member x (insert x set) == True)
>
> and then use it for testing all set data structures that implement
> `member` and `insert`. Here you don't care about performance, only about
> correctness!
>
> However, this approach leads to problems with type inference, confusing
> error messages, and complexity. I found that it is much nicer to use
> explicit dictionary passing and write something like this instead:
>
> memberInsertProperty SetAPI{..} x set = (member x (insert x set) == True)
>
> where `member` and `insert` come from the SetAPI record via
> RecordWildCards.
>
> Finally, I'm not even sure how to create a type class covering Set and
> IntSet with the following two methods:
>
> singleton :: a -> Set a
> map :: Ord b => (a -> b) -> Set a -> Set b
>
> singleton :: Int -> IntSet
> map :: (Int -> Int) -> IntSet -> IntSet
>
> Could anyone please enlighten me about the right way to abstract over this
> using type classes?
>
> I tried a few approaches, for example:
>
> class IsSet s where
> type Elem s
> singleton :: Elem s -> s
> map :: Ord (Elem t) => (Elem s -> Elem t) -> s -> t
>
> Looks nice, but I can't define the IntSet instance:
>
> instance IsSet IntSet where
> type Elem IntSet = Int
> singleton = IntSet.singleton
> map = IntSet.map
>
> This fails with: Couldn't match type `t' with `IntSet' -- and indeed, how
> do I tell the compiler that in the IntSet case s ~ t in the map signature?
> Shall I add more associated types, or "associated constraints" using
> ConstraintKinds? I tried and failed, at various stages, repeatedly.
>
> ...And then you discover that there is Set.cartesianProduct :: Set a ->
> Set b -> Set (a, b), but no equivalent in IntSet and things get even more
> grim.
>
> Cheers,
> Andrey
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Overloaded names for Map/Set?

[Brandon Allbery]

For what it's worth, the Edison packages provide such interfaces for many
structures. You might want to ask about experiences.
http://hackage.haskell.org/package/EdisonCore

On Fri, May 24, 2019, 10:12 Andreas Klebinger 
wrote:

> Hello devs,
>
> I would appreciate feedback on the idea in
> https://gitlab.haskell.org/ghc/ghc/merge_requests/934
>
> Maps/Sets in GHC for the most part offer the same basic functionality
> but their interfaces differ.
> In order to make this easier to work with I propose using overloading
> via IsSet/IsMap classes.
>
> The goal is to make working with these data structures simpler by having
> a uniform interface
> when it comes to names and argument orders.
>
> There are downsides, but to me they seem minor. Error messages can be
> more confusing when one
> get's the types wrong. We have to import the class to use it and the like.
> However overall I think making code easier by not having to remember the
> naming scheme + argument order
> for the different possible instances would make this worthwhile.
>
> But GHC isn't my project but one of the community so please voice your
> opinion on the matter on the
> merge request!
>
> Cheers
> Andreas
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Cabal woes

[Brandon Allbery]

But it fails this way instead, because 3.x works differently. Probably
should have checked docs given it's a new major version of cabal-install.

On Mon, Apr 15, 2019 at 6:44 PM Simon Peyton Jones 
wrote:

> Simon has a cabal-install that claims to be 3.0.0.0
>
>
> Ah yes, I installed it thus:
>
> ·sudo add-apt-repository ppa:hvr/ghc-wsl
>
> ·sudo apt-get update
>
> ·sudo apt install cabal-install-3.0
>
>
>
> Why did I do that?  Because earlier versions of cabal crashed with a
> mysterious “The futex facility returned an unexpected” something like this
> https://github.com/Microsoft/WSL/issues/3881 or this
> https://github.com/reflex-frp/reflex-platform/issues/293
>
>
>
> Apparently Herbert’s 3.0 does not fail in this way.
>
>
>
> Simon
>
>
>
> *From:* ghc-devs  *On Behalf Of *Brandon
> Allbery
> *Sent:* 15 April 2019 23:24
> *To:* Oleg Grenrus 
> *Cc:* ghc-devs@haskell.org Devs 
> *Subject:* Re: Cabal woes
>
>
>
> The facts here are in the original message: Simon has a cabal-install that
> claims to be 3.0.0.0, and is treating "install" as "v2-install". So
> evidently *someone* has released it in some fashion, perhaps
> inappropriately.
>
>
>
> On Mon, Apr 15, 2019 at 6:22 PM Oleg Grenrus  wrote:
>
> cabal-install-3 isn't released. Please check the facts.
>
> - Oleg
>
> On 16.4.2019 1.17, Brandon Allbery wrote:
>
> I vaguely recall seeing that bug come up with respect to v2-install. And
> in fact am a bit surprised that 3 has been released, since this is
> highlighting that neither it nor the Haskell ecosystem is quite ready for
> it.
>
>
>
> I'd also have expected (and thought I'd seen) "cabal install" in recent
> 2.x warn that it would be "v1-install" in the future.
>
>
>
> On Mon, Apr 15, 2019 at 6:13 PM Simon Peyton Jones 
> wrote:
>
> Aha!  That works.  I would never in a million years have found that by
> myself.  Thank you.
>
>
>
> But
>
>- It is terribly mysterious that “cabal install hspec” doesn’t, well,
>install hspec.
>- It must surely be a bug that “cabal install –lib hspec” simply
>crashes.
>
>
>
> Simon
>
>
>
> *From:* Brandon Allbery 
> *Sent:* 15 April 2019 23:03
> *To:* Simon Peyton Jones 
> *Cc:* ghc-devs@haskell.org
> *Subject:* Re: Cabal woes
>
>
>
> Yes, I think a lot of documentation will need to be updated because this.
> You want "cabal v1-install" with cabal 3.
>
>
>
> On Mon, Apr 15, 2019 at 6:00 PM Simon Peyton Jones 
> wrote:
>
> Thanks.  But alas I have no clue about whether I want a v1-install or a
> v2-install, nor how to achieve them if I knew what they were.  I just want
> to install ‘hspec’ so that I can use it when compiling a program.  How
> would I do that?
>
>
>
> The instructions here https://wiki.haskell.org/Cabal-Install
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.haskell.org%2FCabal-Install&data=02%7C01%7Csimonpj%40microsoft.com%7C2fdeabc1bf0049584e9708d6c1f11cb5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636909638652533306&sdata=pJb05mqT1A0ceYxJ26%2FkMhJCYQ9S7%2Bupn89xZSl7y2I%3D&reserved=0>
> just say “cabal install hspec” which is what I tried.  Those instructions
> are pointed to from here
> https://wiki.haskell.org/Cabal/How_to_install_a_Cabal_package
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.haskell.org%2FCabal%2FHow_to_install_a_Cabal_package&data=02%7C01%7Csimonpj%40microsoft.com%7C2fdeabc1bf0049584e9708d6c1f11cb5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636909638652533306&sdata=mBDZQXgEtvQLuiTCFCKLtREPmImnr3ljNTHq%2B4A4Nf4%3D&reserved=0>,
> which in turn are pointed to from the main Cabal home page
> https://www.haskell.org/cabal/
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.haskell.org%2Fcabal%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C2fdeabc1bf0049584e9708d6c1f11cb5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636909638652533306&sdata=scKnLWjyw1X5N1VPpBukOq4PXDoeHcYTXa3gT5bKK7E%3D&reserved=0>
> .
>
>
>
> I must be missing something.
>
>
>
> Simon
>
>
>
> *From:* Brandon Allbery 
> *Sent:* 15 April 2019 22:54
> *To:* Simon Peyton Jones 
> *Cc:* ghc-devs@haskell.org
> *Subject:* Re: Cabal woes
>
>
>
> I think you wanted v1-install to install a library into the user package
> database, since your cabal is 3.x and the v2-* commands are now the default
> (that is, you did what used to be cabal new-install or cabal v2-install).
>
>
>
> On Mon, Apr 15, 2019 at 5:47 PM Simon P

Re: Cabal woes

[Brandon Allbery]

Mikhail, the use case not addressed here is people who are used to v1-style
and want to keep using it — and possibly aren't in a great position to
rewire their setup to fit how v2 thinks. Personally, I have situations
where I use v2 and others where v1 works better.

On Mon, Apr 15, 2019 at 6:43 PM Mikhail Glushenkov <
mikhail.glushen...@gmail.com> wrote:

> Hello Simon,
>
> On Mon, 15 Apr 2019 at 23:14, Simon Peyton Jones via ghc-devs
>  wrote:
> >
> > It is terribly mysterious that “cabal install hspec” doesn’t, well,
> install hspec.
>
> In the cabal v2-* model [1] installing libraries globally is no longer
> the recommended mode of operation, which is why you now need to pass
> --lib to 'install' to do that.
>
> There are now better alternatives for most use cases of 'install --lib':
>
> * For just trying out some set of libraries in REPL, you can use
> `cabal new-repl --build-depends=foo,bar,baz` outside of a project
> instead of ghci. [2] If you have .ghc.environment file generation
> turned on, you can also use plain ghci inside your project, and it
> will pick up the project context. [3]
> * For running Haskell scripts that expect extra libraries in the
> global package DB you can use `#! cabal` instead of `#! runghc`. [4]
>
> > It must surely be a bug that “cabal install –lib hspec” simply crashes.
>
> This is a bug that we haven't fixed yet [5]. Should've just worked.
>
>
> [1] https://cabal.readthedocs.io/en/latest/nix-local-build-overview.html
> [2]
> https://cabal.readthedocs.io/en/latest/nix-local-build.html#cabal-v2-repl
> [3]
> https://cabal.readthedocs.io/en/latest/nix-local-build.html#cfg-field-write-ghc-environment-files
> [4]
> https://cabal.readthedocs.io/en/latest/nix-local-build.html#cabal-v2-run
> [5] https://github.com/haskell/cabal/issues/5990
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Cabal woes

[Brandon Allbery]

The facts here are in the original message: Simon has a cabal-install that
claims to be 3.0.0.0, and is treating "install" as "v2-install". So
evidently *someone* has released it in some fashion, perhaps
inappropriately.

On Mon, Apr 15, 2019 at 6:22 PM Oleg Grenrus  wrote:

> cabal-install-3 isn't released. Please check the facts.
>
> - Oleg
>
> On 16.4.2019 1.17, Brandon Allbery wrote:
>
> I vaguely recall seeing that bug come up with respect to v2-install. And
> in fact am a bit surprised that 3 has been released, since this is
> highlighting that neither it nor the Haskell ecosystem is quite ready for
> it.
>
> I'd also have expected (and thought I'd seen) "cabal install" in recent
> 2.x warn that it would be "v1-install" in the future.
>
> On Mon, Apr 15, 2019 at 6:13 PM Simon Peyton Jones 
> wrote:
>
>> Aha!  That works.  I would never in a million years have found that by
>> myself.  Thank you.
>>
>>
>>
>> But
>>
>>- It is terribly mysterious that “cabal install hspec” doesn’t, well,
>>install hspec.
>>- It must surely be a bug that “cabal install –lib hspec” simply
>>crashes.
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* Brandon Allbery 
>> *Sent:* 15 April 2019 23:03
>> *To:* Simon Peyton Jones 
>> *Cc:* ghc-devs@haskell.org
>> *Subject:* Re: Cabal woes
>>
>>
>>
>> Yes, I think a lot of documentation will need to be updated because this.
>> You want "cabal v1-install" with cabal 3.
>>
>>
>>
>> On Mon, Apr 15, 2019 at 6:00 PM Simon Peyton Jones 
>> wrote:
>>
>> Thanks.  But alas I have no clue about whether I want a v1-install or a
>> v2-install, nor how to achieve them if I knew what they were.  I just want
>> to install ‘hspec’ so that I can use it when compiling a program.  How
>> would I do that?
>>
>>
>>
>> The instructions here https://wiki.haskell.org/Cabal-Install
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.haskell.org%2FCabal-Install&data=02%7C01%7Csimonpj%40microsoft.com%7C9dba03cd18af405d806208d6c1ee1601%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636909625657350786&sdata=81SaQYxWkpF9nYalL%2B%2FSCbcGMMkYsMnFnpylDncDXu0%3D&reserved=0>
>> just say “cabal install hspec” which is what I tried.  Those instructions
>> are pointed to from here
>> https://wiki.haskell.org/Cabal/How_to_install_a_Cabal_package
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.haskell.org%2FCabal%2FHow_to_install_a_Cabal_package&data=02%7C01%7Csimonpj%40microsoft.com%7C9dba03cd18af405d806208d6c1ee1601%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636909625657350786&sdata=ougOkZ0Dd%2Fep%2FshvVChLiGb9MEhEOW1sYxGnK8KJ8ww%3D&reserved=0>,
>> which in turn are pointed to from the main Cabal home page
>> https://www.haskell.org/cabal/
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.haskell.org%2Fcabal%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C9dba03cd18af405d806208d6c1ee1601%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636909625657360794&sdata=I1SnV%2F4c2d05K39NLK%2FQ%2BLdfRoGRRCcKIGXHkNKMGH8%3D&reserved=0>
>> .
>>
>>
>>
>> I must be missing something.
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* Brandon Allbery 
>> *Sent:* 15 April 2019 22:54
>> *To:* Simon Peyton Jones 
>> *Cc:* ghc-devs@haskell.org
>> *Subject:* Re: Cabal woes
>>
>>
>>
>> I think you wanted v1-install to install a library into the user package
>> database, since your cabal is 3.x and the v2-* commands are now the default
>> (that is, you did what used to be cabal new-install or cabal v2-install).
>>
>>
>>
>> On Mon, Apr 15, 2019 at 5:47 PM Simon Peyton Jones via ghc-devs <
>> ghc-devs@haskell.org> wrote:
>>
>> I’m trying to install ‘hspec’ on my WSL (Windows subsystem for Linux)
>> system.
>>
>> But I fail; see below.
>>
>> For some reason cabal complains about installing a library.  (That seems
>> peculiar – isn’t that what cabal is for?)  But it helpfully suggests adding
>> –lib.
>>
>> Alas, cabal then crashes outright, which should never happen.
>>
>> So I’m stuck.  What should I do?
>>
>> Thanks
>>
>> Simon
>>
>>
>>
>> simonpj@MSRC-9870733:~$ cabal --version
>>
>> cabal-install version 3.0.0.0
>>
>> compiled using version 3.0.0.0 of the Cabal library
>>
>> simonpj@MSRC-

Re: Cabal woes

[Brandon Allbery]

I vaguely recall seeing that bug come up with respect to v2-install. And in
fact am a bit surprised that 3 has been released, since this is
highlighting that neither it nor the Haskell ecosystem is quite ready for
it.

I'd also have expected (and thought I'd seen) "cabal install" in recent 2.x
warn that it would be "v1-install" in the future.

On Mon, Apr 15, 2019 at 6:13 PM Simon Peyton Jones 
wrote:

> Aha!  That works.  I would never in a million years have found that by
> myself.  Thank you.
>
>
>
> But
>
>- It is terribly mysterious that “cabal install hspec” doesn’t, well,
>install hspec.
>- It must surely be a bug that “cabal install –lib hspec” simply
>crashes.
>
>
>
> Simon
>
>
>
> *From:* Brandon Allbery 
> *Sent:* 15 April 2019 23:03
> *To:* Simon Peyton Jones 
> *Cc:* ghc-devs@haskell.org
> *Subject:* Re: Cabal woes
>
>
>
> Yes, I think a lot of documentation will need to be updated because this.
> You want "cabal v1-install" with cabal 3.
>
>
>
> On Mon, Apr 15, 2019 at 6:00 PM Simon Peyton Jones 
> wrote:
>
> Thanks.  But alas I have no clue about whether I want a v1-install or a
> v2-install, nor how to achieve them if I knew what they were.  I just want
> to install ‘hspec’ so that I can use it when compiling a program.  How
> would I do that?
>
>
>
> The instructions here https://wiki.haskell.org/Cabal-Install
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.haskell.org%2FCabal-Install&data=02%7C01%7Csimonpj%40microsoft.com%7C9dba03cd18af405d806208d6c1ee1601%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636909625657350786&sdata=81SaQYxWkpF9nYalL%2B%2FSCbcGMMkYsMnFnpylDncDXu0%3D&reserved=0>
> just say “cabal install hspec” which is what I tried.  Those instructions
> are pointed to from here
> https://wiki.haskell.org/Cabal/How_to_install_a_Cabal_package
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.haskell.org%2FCabal%2FHow_to_install_a_Cabal_package&data=02%7C01%7Csimonpj%40microsoft.com%7C9dba03cd18af405d806208d6c1ee1601%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636909625657350786&sdata=ougOkZ0Dd%2Fep%2FshvVChLiGb9MEhEOW1sYxGnK8KJ8ww%3D&reserved=0>,
> which in turn are pointed to from the main Cabal home page
> https://www.haskell.org/cabal/
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.haskell.org%2Fcabal%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C9dba03cd18af405d806208d6c1ee1601%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636909625657360794&sdata=I1SnV%2F4c2d05K39NLK%2FQ%2BLdfRoGRRCcKIGXHkNKMGH8%3D&reserved=0>
> .
>
>
>
> I must be missing something.
>
>
>
> Simon
>
>
>
> *From:* Brandon Allbery 
> *Sent:* 15 April 2019 22:54
> *To:* Simon Peyton Jones 
> *Cc:* ghc-devs@haskell.org
> *Subject:* Re: Cabal woes
>
>
>
> I think you wanted v1-install to install a library into the user package
> database, since your cabal is 3.x and the v2-* commands are now the default
> (that is, you did what used to be cabal new-install or cabal v2-install).
>
>
>
> On Mon, Apr 15, 2019 at 5:47 PM Simon Peyton Jones via ghc-devs <
> ghc-devs@haskell.org> wrote:
>
> I’m trying to install ‘hspec’ on my WSL (Windows subsystem for Linux)
> system.
>
> But I fail; see below.
>
> For some reason cabal complains about installing a library.  (That seems
> peculiar – isn’t that what cabal is for?)  But it helpfully suggests adding
> –lib.
>
> Alas, cabal then crashes outright, which should never happen.
>
> So I’m stuck.  What should I do?
>
> Thanks
>
> Simon
>
>
>
> simonpj@MSRC-9870733:~$ cabal --version
>
> cabal-install version 3.0.0.0
>
> compiled using version 3.0.0.0 of the Cabal library
>
> simonpj@MSRC-9870733:~$ cabal install hspec
>
> Resolving dependencies...
>
> Up to date
>
> Warning: You asked to install executables, but there are no executables in
>
> target: hspec. Perhaps you want to use --lib to install libraries instead.
>
> simonpj@MSRC-9870733:~$ cabal install --lib hspec
>
> Resolving dependencies...
>
> Up to date
>
> Distribution/Simple/GHC.hs:1959:5-56: Irrefutable pattern failed for
> pattern Just ghcPkgProg
>
>
>
> simonpj@MSRC-9870733:~$ which ghc
>
> /opt/ghc/bin/ghc
>
> simonpj@MSRC-9870733:~$ which ghc-pkg
>
> /opt/ghc/bin/ghc-pkg
>
> simonpj@MSRC-9870733:~$
>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> <https://nam06.safelinks.protection.out

Re: Cabal woes

[Brandon Allbery]

Yes, I think a lot of documentation will need to be updated because this.
You want "cabal v1-install" with cabal 3.

On Mon, Apr 15, 2019 at 6:00 PM Simon Peyton Jones 
wrote:

> Thanks.  But alas I have no clue about whether I want a v1-install or a
> v2-install, nor how to achieve them if I knew what they were.  I just want
> to install ‘hspec’ so that I can use it when compiling a program.  How
> would I do that?
>
>
>
> The instructions here https://wiki.haskell.org/Cabal-Install just say
> “cabal install hspec” which is what I tried.  Those instructions are
> pointed to from here
> https://wiki.haskell.org/Cabal/How_to_install_a_Cabal_package, which in
> turn are pointed to from the main Cabal home page
> https://www.haskell.org/cabal/.
>
>
>
> I must be missing something.
>
>
>
> Simon
>
>
>
> *From:* Brandon Allbery 
> *Sent:* 15 April 2019 22:54
> *To:* Simon Peyton Jones 
> *Cc:* ghc-devs@haskell.org
> *Subject:* Re: Cabal woes
>
>
>
> I think you wanted v1-install to install a library into the user package
> database, since your cabal is 3.x and the v2-* commands are now the default
> (that is, you did what used to be cabal new-install or cabal v2-install).
>
>
>
> On Mon, Apr 15, 2019 at 5:47 PM Simon Peyton Jones via ghc-devs <
> ghc-devs@haskell.org> wrote:
>
> I’m trying to install ‘hspec’ on my WSL (Windows subsystem for Linux)
> system.
>
> But I fail; see below.
>
> For some reason cabal complains about installing a library.  (That seems
> peculiar – isn’t that what cabal is for?)  But it helpfully suggests adding
> –lib.
>
> Alas, cabal then crashes outright, which should never happen.
>
> So I’m stuck.  What should I do?
>
> Thanks
>
> Simon
>
>
>
> simonpj@MSRC-9870733:~$ cabal --version
>
> cabal-install version 3.0.0.0
>
> compiled using version 3.0.0.0 of the Cabal library
>
> simonpj@MSRC-9870733:~$ cabal install hspec
>
> Resolving dependencies...
>
> Up to date
>
> Warning: You asked to install executables, but there are no executables in
>
> target: hspec. Perhaps you want to use --lib to install libraries instead.
>
> simonpj@MSRC-9870733:~$ cabal install --lib hspec
>
> Resolving dependencies...
>
> Up to date
>
> Distribution/Simple/GHC.hs:1959:5-56: Irrefutable pattern failed for
> pattern Just ghcPkgProg
>
>
>
> simonpj@MSRC-9870733:~$ which ghc
>
> /opt/ghc/bin/ghc
>
> simonpj@MSRC-9870733:~$ which ghc-pkg
>
> /opt/ghc/bin/ghc-pkg
>
> simonpj@MSRC-9870733:~$
>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csimonpj%40microsoft.com%7C49de1a60a36e4a04bbe208d6c1ecdac9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636909620364700618&sdata=dMUKGqIICFPisw%2Feskzb98WxcG9kfNFMOkZfd9fB7YU%3D&reserved=0>
>
>
>
>
> --
>
> brandon s allbery kf8nh
>
> allber...@gmail.com
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Cabal woes

[Brandon Allbery]

I think you wanted v1-install to install a library into the user package
database, since your cabal is 3.x and the v2-* commands are now the default
(that is, you did what used to be cabal new-install or cabal v2-install).

On Mon, Apr 15, 2019 at 5:47 PM Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> I’m trying to install ‘hspec’ on my WSL (Windows subsystem for Linux)
> system.
>
> But I fail; see below.
>
> For some reason cabal complains about installing a library.  (That seems
> peculiar – isn’t that what cabal is for?)  But it helpfully suggests adding
> –lib.
>
> Alas, cabal then crashes outright, which should never happen.
>
> So I’m stuck.  What should I do?
>
> Thanks
>
> Simon
>
>
>
> simonpj@MSRC-9870733:~$ cabal --version
>
> cabal-install version 3.0.0.0
>
> compiled using version 3.0.0.0 of the Cabal library
>
> simonpj@MSRC-9870733:~$ cabal install hspec
>
> Resolving dependencies...
>
> Up to date
>
> Warning: You asked to install executables, but there are no executables in
>
> target: hspec. Perhaps you want to use --lib to install libraries instead.
>
> simonpj@MSRC-9870733:~$ cabal install --lib hspec
>
> Resolving dependencies...
>
> Up to date
>
> Distribution/Simple/GHC.hs:1959:5-56: Irrefutable pattern failed for
> pattern Just ghcPkgProg
>
>
>
> simonpj@MSRC-9870733:~$ which ghc
>
> /opt/ghc/bin/ghc
>
> simonpj@MSRC-9870733:~$ which ghc-pkg
>
> /opt/ghc/bin/ghc-pkg
>
> simonpj@MSRC-9870733:~$
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Getting Rewrite Rules from ModGuts

[Brandon Allbery]

You might need to enable optimization for RULES to get picked up at all.

On Thu, Apr 11, 2019 at 11:03 PM Bill Hallahan 
wrote:

> Hi,
>
> I'm trying to use the GHC API (8.2.2) to extract the rewrite rules from a
> module, but have run into some difficulties.  I've written the following
> code (all code is also attached as files):
>
> module Main where
>
> import GHC
> import GHC.Paths
> import HscTypes
>
> main :: IO ()
> main = do
> loadProj "Test.hs"
>
> loadProj :: FilePath -> IO ()
> loadProj src = do
> modgutss <- runGhc (Just libdir) $ do
> flags <- getSessionDynFlags
> _ <- setSessionDynFlags flags
>
> target <- guessTarget src Nothing
> _ <- setTargets [target]
> _ <- load LoadAllTargets
>
> mod_graph <- getModuleGraph
> parsed_mods <- mapM parseModule mod_graph
> typed_mods <- mapM typecheckModule parsed_mods
> desug_mods <- mapM desugarModule typed_mods
>
> return $ map coreModule desug_mods
>
> let rules = map (\mg -> ( moduleNameString . moduleName $
> mg_module mg
> , length $ mg_rules mg)
> ) modgutss
> print $ rules
>
> return ()
>
> It loads Test.hs (see below my signature) which contains a single rewrite
> rule.  Then, it obtains the ModGuts, and prints a tuple of the name of the
> module, and the length of the rule list.  I would expect this to be
> ("Test", 1), but, in fact, what gets printed is ("Test", 0).  For some
> reason, the ModGuts does not have the rewrite rule from the file.
>
> I'm guessing I'm misunderstanding something about how the GHC API works.
> If anyone has any advice about how to fix this code to load rewrite rules
> (or even where to begin looking) I would appreciate it!
>
> Thanks,
> Bill Hallahan
>
> Test.hs:
> module Test where
>
> import Prelude hiding (map)
>
> map :: (a -> b) -> [a] -> [b]
> map f (x:xs) = f x:map f xs
> map _ [] = []
> {-# NOINLINE [0] map #-}
>
> {-# RULES
>  "map/map"   forall f g xs . map f (map g xs) = map (f . g) xs
>   #-}
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[Brandon Allbery]

Nix instead of system, but roughly yes.

On Fri, Mar 29, 2019 at 5:46 AM Oleg Grenrus  wrote:

> To clarify: You mean different installations of same-version GHC? E.g.
> /opt/ghc/8.4.4/bin/ghc (HVR's) and /usr/bin/ghc (System default) which
> both happen to be 8.4.4 (so some other version)?
>
> - Oleg
>
> On 29.3.2019 5.44, Brandon Allbery wrote:
> > FWIW I've run into this one myself, and use (clones, if necessary, of)
> > v1 sandboxes for it currently.
> >
> > I've also been both bitten by, and helped by, environment files. The
> > former is somewhat nastier, especially if you have multiple versions
> > of ghc around and a given environment file was generated by a
> > different ghc.
> >
> > I also have a somewhat weird setup, because of how I ended up cobbling
> > this machine together: the global and user package dbs for my default
> > ghc are more or less "owned" by xmonad development, anything else is
> > in v2, a sandbox, or otherwise a different ghc version. Including nix,
> > also operating as a sandbox (that is, I use an alias to set up nix
> > within specific shells, rather than unconditionally loading its
> > config). Plus that "default ghc" is via wrappers around hvr's ghc
> > repos for Ubuntu. Which means I have lots of different ghcs around,
> > depending on which shell window I'm in. Not that I'm expecting anyone
> > to directly support this mess, but environment files seem to play
> > especially badly with multiple ghc versions with different packages
> > installed.
> >
> > On Thu, Mar 28, 2019 at 11:33 PM  > <mailto:amin...@gmail.com>> wrote:
> >
> >
> > > El 28 mar 2019, a las 3:26 PM, Richard Eisenberg
> >  escribió:
> > >
> >
> > [...]
> >
> > > 2. I get pilloried every time I say it, but I vastly prefer
> > global package databases to local ones.
> >
> > I'll second this in one specific context. v2-build has been
> > amazing at work and in general for project-based development, but
> > – and maybe simply because I don't know the right incantations – a
> > step backwards for impromptu coding where I don't want to set up a
> > whole project to start messing with an idea.
> >
> > I've actually fallen back to v1-install for this specific usecase:
> > I have a set of ~15 packages, all installed from local git repos,
> > some of which depend on others, that I *always* want when I'm in
> > GHCi. It's basically my base. I may simply be doing it wrong but
> > I've been unable to use the "global ghc.env file" trick successfully.
> >
> > Tom
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> >
> >
> > --
> > brandon s allbery kf8nh
> > allber...@gmail.com <mailto:allber...@gmail.com>
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[Brandon Allbery]

FWIW I've run into this one myself, and use (clones, if necessary, of) v1
sandboxes for it currently.

I've also been both bitten by, and helped by, environment files. The former
is somewhat nastier, especially if you have multiple versions of ghc around
and a given environment file was generated by a different ghc.

I also have a somewhat weird setup, because of how I ended up cobbling this
machine together: the global and user package dbs for my default ghc are
more or less "owned" by xmonad development, anything else is in v2, a
sandbox, or otherwise a different ghc version. Including nix, also
operating as a sandbox (that is, I use an alias to set up nix within
specific shells, rather than unconditionally loading its config). Plus that
"default ghc" is via wrappers around hvr's ghc repos for Ubuntu. Which
means I have lots of different ghcs around, depending on which shell window
I'm in. Not that I'm expecting anyone to directly support this mess, but
environment files seem to play especially badly with multiple ghc versions
with different packages installed.

On Thu, Mar 28, 2019 at 11:33 PM  wrote:

>
> > El 28 mar 2019, a las 3:26 PM, Richard Eisenberg 
> escribió:
> >
>
> [...]
>
> > 2. I get pilloried every time I say it, but I vastly prefer global
> package databases to local ones.
>
> I'll second this in one specific context. v2-build has been amazing at
> work and in general for project-based development, but – and maybe simply
> because I don't know the right incantations – a step backwards for
> impromptu coding where I don't want to set up a whole project to start
> messing with an idea.
>
> I've actually fallen back to v1-install for this specific usecase: I have
> a set of ~15 packages, all installed from local git repos, some of which
> depend on others, that I *always* want when I'm in GHCi. It's basically my
> base. I may simply be doing it wrong but I've been unable to use the
> "global ghc.env file" trick successfully.
>
> Tom
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Discussion: Hadrian's defaults

[Brandon Allbery]

I feel like you didn't read this completely. I used make as the example,
but hadrian is also a build system and will have some version of the same
problem: configure's dependencies are also its outputs. Hadrian might be
able to handle this, if it recomputes the entire dependency tree after
every operation — but any mistakes in the dependencies will lead to loops.

And none of this addresses the point that if configure is in any way
automatic, including as a separate initialization operation before
dependencies are computed, it's going to make life difficult for developers
who want to restart a build. Granting the viewpoint that says that
end-builder ease is more important than developer ease, but even there if
you make things too difficult for developers, a project that is already
short on developers may become even more short on developers and/or
developer time.

(I also think decisions like whether and how to run configure and/or the
build tooling should be part of my local configuration, because my own
needs will differ from others'. We already see this with devs who prefer
e.g. quick vs. perf builds.)

By far the safest approach is to keep configure separate.

On Tue, Mar 19, 2019 at 4:42 AM Spiwack, Arnaud 
wrote:

> On Fri, Mar 15, 2019 at 4:52 PM Brandon Allbery 
> wrote:
>
>> Newcomers to autoconf-based ecosystems often add a rule to run configure
>> to their Makefiles, as a "shortcut". At some time thereafter, they discover
>> that there's a problem when configure alters the build plan make is
>> executing. There's no sane way to integrate this properly if the build plan
>> changes enough, even if configure is always the very first thing executed
>> as part of the original build plan. This generally results in forcing make
>> to abort after running autoconf, since trying to be more clever results in
>> looping over configure. The only other way that works is arranging for
>> 2-stage Makefiles where the outer one amounts to "configure && make -f
>> Makefile.real". Which makes it noticeably more error-prone to tweak
>> something and do a fast rebuild, since configure will often cause it to be
>> a full rebuild instead. If you try to give configure dependencies so that
>> it doesn't get re-run, you discover that it's dependent in some sense on
>> its own outputs and again can cause loops.
>>
>> Trying to integrate configure with hadrian runs the same risk, heightened
>> by hadrian not using anything like Makefiles, so it would be even easier
>> for it to either miss changes made by configure or end up looping on it. Or
>> worse, the same with autoconf — or for ghc, the boot script which runs
>> autoconf, among other things, and thus has even nastier risks in terms of
>> missing important changes made thereby or causing loops.
>>
>
>  Aha! But is Hadrian doesn't use Make. And the shortcoming of Make which
> make autoconf necessary as a separate tools are ones that Shake fix. Making
> it a breeze to integrate a configure script without hassle.
>
> I'll be honest, so far, so far, the thread doesn't have much convincing
> arguments in favour of keeping `-c`. The argument which I understand is
> Ben's in [ https://github.com/snowleopard/hadrian/issues/457 ], who saw
> the arguments he passed to ./configure overwritten by Hadrian. This is
> surprising and unnecessary.
>
> But you have to realise what you are advocating for: the most typical
> workflow (not passing special arguments to ./configure) is the one which is
> special cased. We should rather take this as a challenge: how do we fix the
> limitations of `-c` so that it can be made the default; rather than giving
> up. A possibility would be to record the arguments passed to the configure
> script in a file, and make Hadrian pass these arguments to `./configure`.
> For instance.
>
> I'd also like to impart a bit of urgency to this: we are breaking
> everybody's habit now, so now is the time to discuss changes. When we're
> used to the new build system and it isn't new anymore, it will become much
> harder to justify change.
>
> By the way, on the default flavour: in addition to Ocaml's Dune, it
> appears that Bazel (Google's newish multi-language build system) also has
> the developers' build be the default. It's not enough data to establish
> that this default is the consensus. But I'm quite warming up to the
> position myself.
>
> Best,
> Arnaud
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ambiguous occurrence bug?]

[Brandon Allbery]

I'm guessing, but I suspect currently the only way to look up a symbol
either requires explicit qualification of the symbol name or that the
symbol be part of a class or instance declaration that implicitly qualifies
method and associated type names. So for the implicit export list to
retrieve the local symbol definition, it would have to explicitly request
the local one instead of simply passing the name. (But getting the local
names, without their definitions, wouldn't hit this. Maybe that should
return explicitly qualified names, but I could see that causing problems
with ghci; consider ":browse". And that it already handles qualification
somewhat oddly because multiple modules can be in scope; "import" doesn't
mean quite the same thing in ghci as in ghc, and can't without making its
interactive use rather more painful when multiple modules are in scope.)

On Sun, Mar 17, 2019 at 2:30 PM Shayne Fletcher 
wrote:

>
> On Sun, Mar 17, 2019 at 2:23 PM Brandon Allbery 
> wrote:
>
>> Hm. You're probably right that it should only consider the locally
>> defined one,
>>
>
> Cool.
>
>
>> but I can see why it would do this
>>
> Can you elaborate? Perhaps,
>
>
>> and wonder if there's even a good way to constrain that check currently.
>>
>>
> indicates that you can see why it might be so based on knowledge of the
> implementation?
>
> --
> Shayne Fletcher
> Language Engineer
> c: +1 917 699 7763
> e: shayne.fletc...@daml.com
> Digital Asset Holdings, LLC
> 4 World Trade Center
>   150 Greenwich Street, 47th Floor
> <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
> New York, NY 10007, USA
> <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
> digitalasset.com <http://www.digitalasset.com/>
>
>
> This message, and any attachments, is for the intended recipient(s) only,
> may contain information that is privileged, confidential and/or proprietary
> and subject to important terms and conditions available at
> http://www.digitalasset.com/emaildisclaimer.html. If you are not the
> intended recipient, please delete this message.



-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ambiguous occurrence bug?]

[Brandon Allbery]

Hm. You're probably right that it should only consider the locally defined
one, but I can see why it would do this and wonder if there's even a good
way to constrain that check currently.

On Sun, Mar 17, 2019 at 2:16 PM Shayne Fletcher 
wrote:

> Hi Brandon,
>
> On Sun, Mar 17, 2019 at 2:09 PM Brandon Allbery 
> wrote:
>
>> No contradiction: "not those that are imported" means a module which
>> imports names does not automatically re-export those names to other modules
>> that import it. So T does indeed export "main", which is imported
>> unqualified by Main
>>
>
> No argument with anything said there.
>
>
>> and thereby causes an ambiguous occurrence.
>>
>
> This I don't get. I presume the ambiguous occurrence is due to the
> question what `main` is `Main.hs` exporting (or in this case is the
> "entry-point" for the program)? My reading of the above is that only the
> local `main` can be exported  (or again, in this case, "considered" for the
> "entry-point") so where is the ambiguity?
>
> --
> Shayne Fletcher
> Language Engineer
> c: +1 917 699 7763
> e: shayne.fletc...@daml.com
> Digital Asset Holdings, LLC
> 4 World Trade Center
>   150 Greenwich Street, 47th Floor
> <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
> New York, NY 10007, USA
> <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
> digitalasset.com <http://www.digitalasset.com/>
>
>
> This message, and any attachments, is for the intended recipient(s) only,
> may contain information that is privileged, confidential and/or proprietary
> and subject to important terms and conditions available at
> http://www.digitalasset.com/emaildisclaimer.html. If you are not the
> intended recipient, please delete this message.



-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ambiguous occurrence bug?]

[Brandon Allbery]

No contradiction: "not those that are imported" means a module which
imports names does not automatically re-export those names to other modules
that import it. So T does indeed export "main", which is imported
unqualified by Main and thereby causes an ambiguous occurrence. But if T
had imported "main" from a third module, it would not be exported for Main
to import unless the export from T was explicit.

On Sun, Mar 17, 2019 at 1:50 PM Shayne Fletcher via ghc-devs <
ghc-devs@haskell.org> wrote:

> Sorry in advance if I should be posting questions of this kind elsewhere
> (please tell me if so!).
>
> Consider this two file program:
> ```
> module T where
> main = undefined
>
> module Main where
> import T
> main = putStrLn "Hello world!"
> ```
>
> Both 8.4.3 and 8.6.3 agree:
> ```
> Main.hs:1:1: error:
> Ambiguous occurrence ‘main’
> It could refer to either ‘T.main’,
>  imported from ‘T’ at Main.hs:2:1-8
>  (and originally defined at Main.hs:2:1-4)
>   or ‘Main.main’, defined at Main.hs:5:1
> ```
>
> Is this expected behavior? Does it not contradict "If the export list is
> omitted, all values, types and classes defined in the module are exported,
> but not those that are imported" (
> https://www.haskell.org/onlinereport/haskell2010/haskellch5.html)? If the
> latter, is this a bug? What am I missing?
>
> --
> Shayne Fletcher
> Language Engineer
> c: +1 917 699 7763
> e: shayne.fletc...@daml.com
> Digital Asset Holdings, LLC
> 4 World Trade Center
>   150 Greenwich Street, 47th Floor
> 
> New York, NY 10007, USA
> 
> digitalasset.com 
>
>
> This message, and any attachments, is for the intended recipient(s) only,
> may contain information that is privileged, confidential and/or proprietary
> and subject to important terms and conditions available at
> http://www.digitalasset.com/emaildisclaimer.html. If you are not the
> intended recipient, please delete this message.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Discussion: Hadrian's defaults

[Brandon Allbery]

Expanding on Moritz a bit:

configure creates a build plan, hadrian runs it.

Newcomers to autoconf-based ecosystems often add a rule to run configure to
their Makefiles, as a "shortcut". At some time thereafter, they discover
that there's a problem when configure alters the build plan make is
executing. There's no sane way to integrate this properly if the build plan
changes enough, even if configure is always the very first thing executed
as part of the original build plan. This generally results in forcing make
to abort after running autoconf, since trying to be more clever results in
looping over configure. The only other way that works is arranging for
2-stage Makefiles where the outer one amounts to "configure && make -f
Makefile.real". Which makes it noticeably more error-prone to tweak
something and do a fast rebuild, since configure will often cause it to be
a full rebuild instead. If you try to give configure dependencies so that
it doesn't get re-run, you discover that it's dependent in some sense on
its own outputs and again can cause loops.

Trying to integrate configure with hadrian runs the same risk, heightened
by hadrian not using anything like Makefiles, so it would be even easier
for it to either miss changes made by configure or end up looping on it. Or
worse, the same with autoconf — or for ghc, the boot script which runs
autoconf, among other things, and thus has even nastier risks in terms of
missing important changes made thereby or causing loops.

Really, don't try to conflate these; someone is going to end up very
unhappy.

On Fri, Mar 15, 2019 at 9:35 AM Moritz Angermann 
wrote:

> Hi Arnaud,
>
> > On Mar 15, 2019, at 8:32 PM, Spiwack, Arnaud 
> wrote:
> >
> > On Thu, Mar 14, 2019 at 7:20 PM Herbert Valerio Riedel <
> hvrie...@gmail.com> wrote:
> > I don't have the ticket number at my fingertips but it should be fairly
> easy to find.
> >
> > I'm afraid it doesn't appear to be. Could you share your arguments in
> this thread?
> This was the last one that lead to the current `-c` state:
> - https://github.com/snowleopard/hadrian/issues/457
> There is also
> - https://github.com/snowleopard/hadrian/issues/655
>
> if you look through the issues on snowleopard/hadrian and sort by comment
> frequency
> you'll likely find quite a lot of further discussion about not making
> configure and
> boot the default.
>
> >
> > On Fri, Mar 15, 2019 at 3:10 AM Moritz Angermann <
> moritz.angerm...@gmail.com> wrote:
> > It's magically conflating two different phases with `-c`. The configure
> phase and
> > the build phase. Making this the default means it's always magic. I
> don't like magic!
> >
> > Unfortunately, I really don't understand what you are saying. What's
> magic about combining the phases?
>
> We have two phases:
>
> Phase 1: autoconf
>
>   This phase is essentially a code-generation phase, where specific
> templates are
>   instantiated to configure time value.  Which again can be split into two
> specific
>   subproblems:
>
>   - Generation of the configure script from the configure.ac and
> aclocal.m4 files
> using autoconf.
>   - Generating code using the configure script by computing configure time
> calues
> and filling those into the `.in` files producing the files that lack
> the `.in`
> extension.
>
> Phase 2: building
>
>   This has been traditionally the job of make, and this is what hadrian
> should
>   replace.
>
>
> By subsuming the configure phase (by invoking ./configure) from hadrian we
> loose
> the phase distinction and if the `-c` flag is optional, users will *not
> even see*
> a flag that indicates that the system will run `./configure` for them.
> This is the
> magic I'm referring to and to which I strongly object.  If we can retire
> autoconf
> and do the whole configuration in hadrian, that story may change.  But as
> long as
> we are using an autoconf based configuration we should *not* run that
> magically.
> The `-c` flag is at least there to show that hadrian is explicilty
> instructed to
> run configure.
>
> ./configure supports its own set of flags, if hadrian subsumes those, we'd
> need
> some generic way of passing flags to ./configure, at which point I have to
> ask
> why do we do this in the first place and try to call ./configure from
> within hadrian?
>
> Unless you want to reconfigure ghc, or hack on it's autoconf part, you are
> likely
> going to run the following only:
>
> ./boot --hadrian
> ./configure 
> ./hadrian/build.sh -j ...
> ./hadrian/build.sh -j ...
> ./hadrian/build.sh -j ...
> ./hadrian/build.sh -j ...
> ...
>
> the configure step is required, and should be explicit. That is where you
> configure
> your ghc build. Set host/build/target values, and other configure flags
> that
> influence how you want your ghc to be configure. Hadrian is there to build
> that
> configuration.  Mixing both may be convenient but hides the fact that
> there is a
> ./configure step.  I consider this hiding to be magic which is meant to
> benefi

Re: github ghc.git broken on libraries/binary

[Brandon Allbery]

As yet mirroring github from gitlab is broken, I think (various parts of
the migration are not yet complete); you should use the gitlab upstream.

On Thu, Mar 14, 2019 at 2:44 PM Shayne Fletcher via ghc-devs <
ghc-devs@haskell.org> wrote:

> `git clone g...@github.com:ghc/ghc.git` followed by `git submodule update
> --init --recursive` results in
> ```
>
> error: Server does not allow request for unadvertised object
> 94855814e2e4f7a0f191ffa5b4c98ee0147e3174
>
> Fetched in submodule path 'libraries/binary', but it did not contain
> 94855814e2e4f7a0f191ffa5b4c98ee0147e3174. Direct fetching of that commit
> failed.
> ```
> --
> Shayne Fletcher
> Language Engineer
> c: +1 917 699 7763
> e: shayne.fletc...@daml.com
> Digital Asset Holdings, LLC
> 4 World Trade Center
>   150 Greenwich Street, 47th Floor
> 
> New York, NY 10007, USA
> 
> digitalasset.com 
>
>
> This message, and any attachments, is for the intended recipient(s) only,
> may contain information that is privileged, confidential and/or proprietary
> and subject to important terms and conditions available at
> http://www.digitalasset.com/emaildisclaimer.html. If you are not the
> intended recipient, please delete this message.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: git clone https://gitlab.haskell.org/ghc/ghc.git on travis doesn't work

[Brandon Allbery]

I think the public name is pointed to the staging site because the main one
is down for the trac to github migration.

On Sat, Mar 9, 2019 at 8:59 PM Michael Sloan  wrote:

> Whoah, I can't get https://ghc.haskell.org/ to load at all - it's also
> trying to use the gitlab.staging.haskell.org cert.  I can't get chrome
> to ignore the cert error because it's using HSTS - HTTP Strict
> Transport Security.
>
> On Sat, Mar 9, 2019 at 5:53 PM Michael Sloan  wrote:
> >
> > I just encountered this when doing a "git pull" on my Ubuntu 18.04.1
> machine:
> >
> > > fatal: unable to access 'https://gitlab.haskell.org/ghc/ghc/': server
> certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt
> CRLfile: none
> >
> > Chrome also believes that the certificate of
> > https://gitlab.haskell.org/ghc/ghc is invalid and I have to click the
> > "Proceed to ... (unsafe)" link.  Chrome's certificate viewer shows
> > that the certificate is for "gitlab.staging.haskell.org" whereas the
> > domain is "gitlab.haskell.org", so I'm guessing that's the problem.
> > I'm not very experienced with such cert stuff, but  perhaps a wildcard
> > cert like "*.haskell.org" could allow using the same cert regardless
> > of whether it's on staging vs prod.
> >
> > For now I've just done "git config --global http.sslverify false"
> > temporarily to do the pull.  Perhaps this is Shayne Fletcher's cheeky
> > workaround? :)
> >
> > -Michael
> >
> > On Fri, Mar 8, 2019 at 10:23 PM Ben Gamari  wrote:
> > >
> > > Shayne Fletcher via ghc-devs  writes:
> > >
> > > > I appreciate this isn't really "our" problem :) Nonetheless, if
> there's any
> > > > config we can do on the repo on gitlab, that would be cool. Other
> URLs
> > > > (like github) for example are fine - something specific to gitlab.
> > > >
> > > I feel like I'm missing something here. I recall you mentioned this in
> > > your previous message but there I'm still lacking crucial context. Can
> > > you offer any additional details? How exactly does it fail?
> > >
> > > In principle there is no reason why cloning from gitlab.haskell.org
> from
> > > Travis shouldn't work. I'd be happy to fix the issue if there is one
> but
> > > without knowing more I'm pretty powerless to change the situation.
> > >
> > > Cheers,
> > >
> > > - Ben
> > >
> > > ___
> > > ghc-devs mailing list
> > > ghc-devs@haskell.org
> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: "resource exhausted" in CI

[Brandon Allbery]

Um, also this seems to have jumped threads; the subject of this message was
a different issue, about disk space. Is that part of the confusion?

On Thu, Jan 24, 2019 at 5:53 PM Brandon Allbery  wrote:

> Rebase is more or less stashing and removing all local commits, upgrading
> the underlying branch to current, then re-applying the local commits. This
> changes the commit hashes for any re-applied commit that lands on a change
> to the underlying branch, meaning that old commit hashes can be invalid
> afterward.
>
> (This is also why force-pushing causes problems, since this is only
> visible in a local tree *unless* force-pushed upstream, meaning now those
> changed/deleted commits affect anyone else who has checked out that
> upstream branch. The normal process of upstreaming commits can't expose
> local changes like that, since it all goes upstream as a group and becomes
> a permanent part of the branch's history. Unless someone force-pushes the
> branch afterward, forcibly overwriting that history with a different one
> and leaving anyoneelse who'd checked out the branch with dangling commits
> that no longer exist.)
>
> Here, CI is making a copy of someone's branch and testing each commit in
> turn to ensure consistency between multiple branches that touch the same
> code, whose commits may end up interleaved. If the branch is rebased or
> force-pushed during that testing, intermediate commits may become invalid
> as above and CI would need to start over with a new list of commits.
>
> On Thu, Jan 24, 2019 at 5:43 PM Simon Peyton Jones via ghc-devs <
> ghc-devs@haskell.org> wrote:
>
>> | Ah, yes -- I did push a rebase. OK: good to know that this is expected
>> | behavior after rebasing (makes sense).
>>
>> Does not make sense (yet) to me.
>>
>> Can someone explain (and perhaps document) the workflow here?
>>
>> Simon
>>
>> | -Original Message-
>> | From: ghc-devs  On Behalf Of Richard
>> | Eisenberg
>> | Sent: 24 January 2019 19:22
>> | To: Ben Gamari 
>> | Cc: GHC developers 
>> | Subject: Re: "resource exhausted" in CI
>> |
>> | Ah, yes -- I did push a rebase. OK: good to know that this is expected
>> | behavior after rebasing (makes sense).
>> |
>> | Thanks,
>> | Richard
>> |
>> | > On Jan 24, 2019, at 2:01 PM, Ben Gamari  wrote:
>> | >
>> | > Richard Eisenberg  writes:
>> | >
>> | >> Something is awry:
>> |
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha
>> | skell.org%2Frae%2Fghc%2F-
>> | %2Fjobs%2F16908&data=02%7C01%7Csimonpj%40microsoft.com
>> %7C375c6daea23444
>> |
>> 7c3d2808d682314861%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63683954552
>> |
>> 1260172&sdata=8OYI5PAk7B6P%2B%2BoJbqgeqPbTR%2BMH6F8Wm34ThdBhRL0%3D&
>> | reserved=0 never got off the ground.
>> | >>
>> | > It is possible that you pushed a rebase? This error generally means
>> that
>> | > the commit is no longer accessible which may happen when you push a
>> | > rebase.
>> | >
>> | > I believe I cited the job for the current version of the patch [1] in
>> my
>> | > previous email. Note that the commit SHA is different between [1] and
>> | > the job you cited.
>> | >
>> | > Cheers,
>> | >
>> | > - Ben
>> | >
>> | >
>> | > [1]
>> |
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha
>> | skell.org%2Frae%2Fghc%2F-
>> | %2Fjobs%2F16913&data=02%7C01%7Csimonpj%40microsoft.com
>> %7C375c6daea23444
>> |
>> 7c3d2808d682314861%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63683954552
>> |
>> 1260172&sdata=wM0hlN60tQmsDtsXS%2BIqLzeAqhgK6RmUoEDzYG2b%2FhI%3D&re
>> | served=0
>> |
>> | ___
>> | ghc-devs mailing list
>> | ghc-devs@haskell.org
>> |
>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haske
>> | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
>> | devs&data=02%7C01%7Csimonpj%40microsoft.com
>> %7C375c6daea234447c3d2808d68
>> |
>> 2314861%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636839545521260172&
>> |
>> ;sdata=R2PHyXMyWDG4mmusi1KLmklGR0b%2FXAE%2BNp%2BwS4ZOmp8%3D&reserved=0
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
>
> --
> brandon s allbery kf8nh
> allber...@gmail.com
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: "resource exhausted" in CI

[Brandon Allbery]

Rebase is more or less stashing and removing all local commits, upgrading
the underlying branch to current, then re-applying the local commits. This
changes the commit hashes for any re-applied commit that lands on a change
to the underlying branch, meaning that old commit hashes can be invalid
afterward.

(This is also why force-pushing causes problems, since this is only visible
in a local tree *unless* force-pushed upstream, meaning now those
changed/deleted commits affect anyone else who has checked out that
upstream branch. The normal process of upstreaming commits can't expose
local changes like that, since it all goes upstream as a group and becomes
a permanent part of the branch's history. Unless someone force-pushes the
branch afterward, forcibly overwriting that history with a different one
and leaving anyoneelse who'd checked out the branch with dangling commits
that no longer exist.)

Here, CI is making a copy of someone's branch and testing each commit in
turn to ensure consistency between multiple branches that touch the same
code, whose commits may end up interleaved. If the branch is rebased or
force-pushed during that testing, intermediate commits may become invalid
as above and CI would need to start over with a new list of commits.

On Thu, Jan 24, 2019 at 5:43 PM Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> | Ah, yes -- I did push a rebase. OK: good to know that this is expected
> | behavior after rebasing (makes sense).
>
> Does not make sense (yet) to me.
>
> Can someone explain (and perhaps document) the workflow here?
>
> Simon
>
> | -Original Message-
> | From: ghc-devs  On Behalf Of Richard
> | Eisenberg
> | Sent: 24 January 2019 19:22
> | To: Ben Gamari 
> | Cc: GHC developers 
> | Subject: Re: "resource exhausted" in CI
> |
> | Ah, yes -- I did push a rebase. OK: good to know that this is expected
> | behavior after rebasing (makes sense).
> |
> | Thanks,
> | Richard
> |
> | > On Jan 24, 2019, at 2:01 PM, Ben Gamari  wrote:
> | >
> | > Richard Eisenberg  writes:
> | >
> | >> Something is awry:
> |
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha
> | skell.org%2Frae%2Fghc%2F-
> | %2Fjobs%2F16908&data=02%7C01%7Csimonpj%40microsoft.com
> %7C375c6daea23444
> |
> 7c3d2808d682314861%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63683954552
> |
> 1260172&sdata=8OYI5PAk7B6P%2B%2BoJbqgeqPbTR%2BMH6F8Wm34ThdBhRL0%3D&
> | reserved=0 never got off the ground.
> | >>
> | > It is possible that you pushed a rebase? This error generally means
> that
> | > the commit is no longer accessible which may happen when you push a
> | > rebase.
> | >
> | > I believe I cited the job for the current version of the patch [1] in
> my
> | > previous email. Note that the commit SHA is different between [1] and
> | > the job you cited.
> | >
> | > Cheers,
> | >
> | > - Ben
> | >
> | >
> | > [1]
> |
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha
> | skell.org%2Frae%2Fghc%2F-
> | %2Fjobs%2F16913&data=02%7C01%7Csimonpj%40microsoft.com
> %7C375c6daea23444
> |
> 7c3d2808d682314861%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63683954552
> |
> 1260172&sdata=wM0hlN60tQmsDtsXS%2BIqLzeAqhgK6RmUoEDzYG2b%2FhI%3D&re
> | served=0
> |
> | ___
> | ghc-devs mailing list
> | ghc-devs@haskell.org
> |
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haske
> | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
> | devs&data=02%7C01%7Csimonpj%40microsoft.com
> %7C375c6daea234447c3d2808d68
> |
> 2314861%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636839545521260172&
> |
> ;sdata=R2PHyXMyWDG4mmusi1KLmklGR0b%2FXAE%2BNp%2BwS4ZOmp8%3D&reserved=0
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Glasgow Haskell Compiler | Fix #16133 by checking for TypeApplications in rnExpr (!77)

[Brandon Allbery]

For what it's worth, the !77 seems to mean
https://gitlab.haskell.org/ghc/ghc/merge_requests/77 which is also the
"View it on GitLab" link target. And in general the "!" seems to indicate a
merge request, per reference to "!82" mentioning this one. So this does
seem to be a new merge request, and presumably the third part is the
requested merge from a personal WIP branch to master.

On Sun, Jan 6, 2019 at 4:19 PM Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> I am now getting lots of email from GitLab, and I’m trying to figure out
> what they all mean.  They come in various forms.
>
>
>
> Here’s one puzzler:
>
>- what does the email below mean?  Is it a new merge request?
>- what is the “!77”?
>- What does “*RyanGlScott/ghc:wip/T16133 → ghc/ghc:master” *mean?
>
>
>
> Simon
>
>
>
> *From:* Ryan Scott 
> *Sent:* 05 January 2019 17:46
> *To:* Simon Peyton Jones 
> *Subject:* Glasgow Haskell Compiler | Fix #16133 by checking for
> TypeApplications in rnExpr (!77)
>
>
>
> *Project:Branches: RyanGlScott/ghc:wip/T16133 → ghc/ghc:master *
>
> We had a validity check, typeAppErr, for visible *kind* applications (in
> rnHsTyKi), but didn't extend the same treatment to visible *type*
> applications (in rnExpr). Easily fixed by also invoking typeAppErr from
> rnExpr.
>
> Fixes https://ghc.haskell.org/trac/ghc/ticket/16133
> 
> .
>
> —
> View it on GitLab
> .
>
> You're receiving this email because of your account on gitlab.haskell.org.
> If you'd like to receive fewer emails, you can unsubscribe
> 
> from this thread or adjust your notification settings.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Gitlab pain

[Brandon Allbery]

On Fri, Jan 4, 2019 at 1:02 PM Ben Gamari  wrote:

> As mentioned by others, discussions that have been marked as "resolved"
> are collapsed by default. If you search for the text "Toggle discussion"
> you will find that the collapsed discussions have link on their
> right-hand side which you can click on to expand the hidden comments.
>

The problem there being there's a lot of such, and no way to tell which one
is relevant unless you have both original links and enough context. Finding
stuff like that absent context doesn't look at all easy. :/

-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: The Trac Wiki and the GitLab Migration

[Brandon Allbery]

The original announcement said wiki migration still has a few hitches to be
ironed out, but is generally looking good.

On Fri, Dec 28, 2018 at 1:04 PM Ara Adkins  wrote:

> Hey All,
>
> I’ve been doing a decent amount of thinking about the GitLab migration and
> realised that I’d not seen any discussion of what we plan to do with all
> the information in the Trac Wiki. If there has been some and I’ve missed it
> I apologise.
>
> In essence, I’m wondering what the current plan is! Will we leave it in
> place, or so we plan to move the content to a wiki on GitLab?
>
> Best.
> _ara
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC (API?) question: GHC Core for Base libraries

[Brandon Allbery]

It's more complicated than that, because unless your'e just doing some
transient experimentation this will bite you over and over. What you'll
want to do is check the stage during compilation (it should be available as
macros via the CPP extension) and disable the plugin for stage 1. Then (I
think; it's even worse if not...) use the base built during stage 2.

The comlication there being that it may use the stage 1 compiler to build
the stage 2 base. In this case, you probably can't e.g. get this integrated
into ghc, because it has to be possible to get it in stage 1 and ideally
stage 2 (some platforms can't do stage 2 builds yet; ARM at least used to
be in this category, hence e.g. no ghci or TH). Which places limits on what
features can be used in the base package.

On Tue, Dec 4, 2018 at 1:37 PM Bill Hallahan 
wrote:

> Joachim Breitner's veggies(https://github.com/nomeata/veggies) project is
> a good example of using a vanilla ghc installation to compile standard
> libraries like base.
>
> Thanks Cheng, this looks interesting and helpful!  I'm still trying to
> understand it fully, but it seems like the important pieces for building
> base are in the boot and Setup scripts?
>
> The problem here is that you're using a stage 1 build, and stage 1 lacks
> support for the bytecode backend used by TH, plugins, ghci, etc. A base
> build with a stage 2 compiler should work.
>
> Thanks Brandon.  Is there a recommended/documented way to build base with
> a stage 2 compiler?  I haven't been able to find anything about this on the
> wiki.
>
> On Dec 3, 2018, at 11:10 PM, Brandon Allbery  wrote:
>
> The problem here is that you're using a stage 1 build, and stage 1 lacks
> support for the bytecode backend used by TH, plugins, ghci, etc. A base
> build with a stage 2 compiler should work.
>
> On Mon, Dec 3, 2018 at 9:11 PM Bill Hallahan 
> wrote:
>
>> Hi,
>>
>> I'm writing a program analyzer that operates on GHC Core.  Currently, I'm
>> using the GHC API to get Core from .hs files.  I'd like to be able to run
>> this analysis on the standard libraries that come with GHC, which requires
>> getting those as Core.
>>
>> Unfortunately, the build process for these libraries is not entirely
>> straightforward, and relies on a make script.  I eventually came up with
>> the plan of writing a GHC plugin, which, rather than performing any
>> optimizations, would simply run the analysis, and then print the results
>> out to a file.  I was able to write the plugin successfully, and test it on
>> several files that were *not* from the base library.
>>
>> Then, i turned to modify the GhcLibHcOpts flag in mk/build.mk, so that
>> the make script would call the plugin.  I ended up with the following:
>>
>> GhcLibHcOpts = -package-db /usr/local/lib/ghc-8.0.2/package.conf.d
>> -package-db /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d
>> -package hplugin -fplugin HPlugin.Plugin -v
>>
>> The two package databases are to get to (1) the GHC API and (2) the
>> plugin ("hplugin") itself.  With this I get an error message, which I have
>> not been able to find a way to resolve:
>>
>> "inplace/bin/ghc-stage1" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O
>> -Wall  -this-unit-id ghc-prim-0.5.0.0 -hide-all-packages -i
>> -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build
>> -ilibraries/ghc-prim/dist-install/build/autogen
>> -Ilibraries/ghc-prim/dist-install/build
>> -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/.
>> -optP-include
>> -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h
>> -package-id rts -this-unit-id ghc-prim -XHaskell2010 -package-db
>> /usr/local/lib/ghc-8.0.2/package.conf.d -package-db
>> /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d -package
>> hplugin -fplugin HPlugin.Plugin  -no-user-package-db -rtsopts
>> -Wno-trustworthy-safe -Wno-deprecated-flags
>> -Wnoncanonical-monad-instances  -odir libraries/ghc-prim/dist-install/build
>> -hidir libraries/ghc-prim/dist-install/build -stubdir
>> libraries/ghc-prim/dist-install/build -split-objs  -dynamic-too -c
>> libraries/ghc-prim/./GHC/Types.hs -o
>> libraries/ghc-prim/dist-install/build/GHC/Types.o -dyno
>> libraries/ghc-prim/dist-install/build/GHC/Types.dyn_o
>> : not built for interactive use - can't load plugins
>> (HPlugin.Plugin)
>> make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1
>> make: *** [all] Error 2
>>
>> So I'm now wondering (an answer to either of these two questions would be
>> helpf

Re: GHC (API?) question: GHC Core for Base libraries

[Brandon Allbery]

The problem here is that you're using a stage 1 build, and stage 1 lacks
support for the bytecode backend used by TH, plugins, ghci, etc. A base
build with a stage 2 compiler should work.

On Mon, Dec 3, 2018 at 9:11 PM Bill Hallahan 
wrote:

> Hi,
>
> I'm writing a program analyzer that operates on GHC Core.  Currently, I'm
> using the GHC API to get Core from .hs files.  I'd like to be able to run
> this analysis on the standard libraries that come with GHC, which requires
> getting those as Core.
>
> Unfortunately, the build process for these libraries is not entirely
> straightforward, and relies on a make script.  I eventually came up with
> the plan of writing a GHC plugin, which, rather than performing any
> optimizations, would simply run the analysis, and then print the results
> out to a file.  I was able to write the plugin successfully, and test it on
> several files that were *not* from the base library.
>
> Then, i turned to modify the GhcLibHcOpts flag in mk/build.mk, so that
> the make script would call the plugin.  I ended up with the following:
>
> GhcLibHcOpts = -package-db /usr/local/lib/ghc-8.0.2/package.conf.d
> -package-db /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d
> -package hplugin -fplugin HPlugin.Plugin -v
>
> The two package databases are to get to (1) the GHC API and (2) the plugin
> ("hplugin") itself.  With this I get an error message, which I have not
> been able to find a way to resolve:
>
> "inplace/bin/ghc-stage1" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O
> -Wall  -this-unit-id ghc-prim-0.5.0.0 -hide-all-packages -i
> -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build
> -ilibraries/ghc-prim/dist-install/build/autogen
> -Ilibraries/ghc-prim/dist-install/build
> -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/.
> -optP-include
> -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h
> -package-id rts -this-unit-id ghc-prim -XHaskell2010 -package-db
> /usr/local/lib/ghc-8.0.2/package.conf.d -package-db
> /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d -package
> hplugin -fplugin HPlugin.Plugin  -no-user-package-db -rtsopts
> -Wno-trustworthy-safe -Wno-deprecated-flags
> -Wnoncanonical-monad-instances  -odir libraries/ghc-prim/dist-install/build
> -hidir libraries/ghc-prim/dist-install/build -stubdir
> libraries/ghc-prim/dist-install/build -split-objs  -dynamic-too -c
> libraries/ghc-prim/./GHC/Types.hs -o
> libraries/ghc-prim/dist-install/build/GHC/Types.o -dyno
> libraries/ghc-prim/dist-install/build/GHC/Types.dyn_o
> : not built for interactive use - can't load plugins
> (HPlugin.Plugin)
> make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1
> make: *** [all] Error 2
>
> So I'm now wondering (an answer to either of these two questions would be
> helpful):
> (1) Is this a viable path?  That is, is it possible to use a plugin when
> building Base?  If so, does anyone know what I might be doing wrong/what
> could be causing this error message?
> (2) Is there some other better/easier way I could get Core representations
> of the standard libraries?  I guess, in theory, it must be possible to
> compile the standard libraries with the GHC API, but I have no idea
> how/where to look to figure out how?
>
> Thanks,
> Bill
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Treatment of unknown pragmas

[Brandon Allbery]

Yeh, I'd missed it was a normal comment and not a new pragma.

Pretty much every solution has some screw case; sometimes you get to choose
between a bunch of "simple, elegant, and wrong" options and have to decide
which "and wrong" will be least expensive (or least frustrating). And a
problem with normal comments (behind why I'd missed this was one) is I'm
not sure they can be as firmly anchored to transformed ASTs; the ANN
mechanism at least has that in its favor.

Pragmas can as well, as indicated by e.g. {-# UNPACK #-}. Is this 100% true
of random comments? And if it is, at what cost to compilations that don't
care? I think this needs more than just a SrcSpan, at least for tools like
hlint or Liquid Haskell that really want to associate these with AST nodes
and maintain them across transformations.

On Tue, Oct 16, 2018 at 7:01 PM  wrote:

> I think Brandon may have misread your example as "{-# HLINT ... #-}".
>
> One problem with "{- HLINT" (although I'm personally not in favor of the
> special-casing) is that if it's just a Haskell comment then it itself is
> vulnerable to typos. E.g. if I type "{- HILNT foo -}" (L and I swapped),
> hlint the tool will miss it.
>
> Tom
>
> El 16 oct 2018, a las 18:44, Simon Peyton Jones via ghc-devs <
> ghc-devs@haskell.org> escribió:
>
> I’m still not getting it.  GHC *ignores* everything between {- and -}.
> Why would I  need to produce a new GHC if someone wants to us {- WIMWAM
> blah -}?
>
>
>
> Simon
>
>
>
> *From:* Brandon Allbery 
> *Sent:* 16 October 2018 23:39
> *To:* Simon Peyton Jones 
> *Cc:* Simon Marlow ; Neil Mitchell <
> ndmitch...@gmail.com>; ghc-devs@haskell.org Devs 
> *Subject:* Re: Treatment of unknown pragmas
>
>
>
> One problem is you have to release a new ghc every time someone comes up
> with a new pragma-using tool that starts to catch on. Another is that the
> more of these you have, the more likely a typo will inadvertently match
> some tool you don't even know about but ghc does.
>
>
>
> On Tue, Oct 16, 2018 at 6:34 PM Simon Peyton Jones via ghc-devs <
> ghc-devs@haskell.org> wrote:
>
> I’m still not understanding what’s wrong with
>
>
>
> {- HLINT blah blah -}
>
>
>
> GHC will ignore it.  HLint can look at it.  Simple.
>
>
>
> I must be missing something obvious.
>
>
>
> Simon
>
>
>
> *From:* ghc-devs  *On Behalf Of *Simon
> Marlow
> *Sent:* 16 October 2018 21:44
> *To:* Neil Mitchell 
> *Cc:* ghc-devs 
> *Subject:* Re: Treatment of unknown pragmas
>
>
>
> I suggested to Neil that he add the {-# HLINT #-} pragma to GHC. It seemed
> like the least worst option taking into account the various issues that
> have already been described in this thread. I'm OK with adding HLINT; after
> all we already ignore OPTIONS_HADDOCK, OPTIONS_NHC98, a bunch of other
> OPTIONS, CFILES (a Hugs relic), and several more that GHC ignores.
>
>
>
> We can either
>
> (a) not protect people from mistyped pragmas, or
>
> (b) protect people from mistyped pragma names, but then we have to bake in
> the set of known pragmas
>
>
>
> We could choose to have a different convention for pragmas that GHC
> doesn't know about (as Ben suggests), but then of course we don't get any
> protection for mistyped pragma names when using that convention.
>
>
>
> Cheers
>
> Simon
>
>
>
>
>
> On Tue, 16 Oct 2018 at 21:12, Neil Mitchell  wrote:
>
> > A warning flag is an interesting way to deal with the issue. On the
> > other hand, it's not great from an ergonomic perspective; afterall, this
> > would mean that all users of HLint (and any other tool requiring special
>
> Yep, this means every HLint user has to do an extra thing. I (the
> HLint author) now have a whole pile of "how do I disable warnings in
> Stack", and "what's the equivalent of this in Nix". Personally, it ups
> the support level significantly that I wouldn't go this route.
>
> I think it might be a useful feature in general, as new tools could
> use the flag to prototype new types of warning, but I imagine once a
> feature gets popular it becomes too much fuss.
>
> > > I think it makes a lot of sense to have a standard way for
> third-parties
> > > to attach string-y information to Haskell source constructs. While it's
> > > not strictly speaking necessary to standardize the syntax, doing
> > > so minimizes the chance that tools overlap and hopefully reduces
> > > the language ecosystem learning curve.
> >
> > This sounds exactly like the existing A

Re: Treatment of unknown pragmas

[Brandon Allbery]

One problem is you have to release a new ghc every time someone comes up
with a new pragma-using tool that starts to catch on. Another is that the
more of these you have, the more likely a typo will inadvertently match
some tool you don't even know about but ghc does.

On Tue, Oct 16, 2018 at 6:34 PM Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> I’m still not understanding what’s wrong with
>
>
>
> {- HLINT blah blah -}
>
>
>
> GHC will ignore it.  HLint can look at it.  Simple.
>
>
>
> I must be missing something obvious.
>
>
>
> Simon
>
>
>
> *From:* ghc-devs  *On Behalf Of *Simon
> Marlow
> *Sent:* 16 October 2018 21:44
> *To:* Neil Mitchell 
> *Cc:* ghc-devs 
> *Subject:* Re: Treatment of unknown pragmas
>
>
>
> I suggested to Neil that he add the {-# HLINT #-} pragma to GHC. It seemed
> like the least worst option taking into account the various issues that
> have already been described in this thread. I'm OK with adding HLINT; after
> all we already ignore OPTIONS_HADDOCK, OPTIONS_NHC98, a bunch of other
> OPTIONS, CFILES (a Hugs relic), and several more that GHC ignores.
>
>
>
> We can either
>
> (a) not protect people from mistyped pragmas, or
>
> (b) protect people from mistyped pragma names, but then we have to bake in
> the set of known pragmas
>
>
>
> We could choose to have a different convention for pragmas that GHC
> doesn't know about (as Ben suggests), but then of course we don't get any
> protection for mistyped pragma names when using that convention.
>
>
>
> Cheers
>
> Simon
>
>
>
>
>
> On Tue, 16 Oct 2018 at 21:12, Neil Mitchell  wrote:
>
> > A warning flag is an interesting way to deal with the issue. On the
> > other hand, it's not great from an ergonomic perspective; afterall, this
> > would mean that all users of HLint (and any other tool requiring special
>
> Yep, this means every HLint user has to do an extra thing. I (the
> HLint author) now have a whole pile of "how do I disable warnings in
> Stack", and "what's the equivalent of this in Nix". Personally, it ups
> the support level significantly that I wouldn't go this route.
>
> I think it might be a useful feature in general, as new tools could
> use the flag to prototype new types of warning, but I imagine once a
> feature gets popular it becomes too much fuss.
>
> > > I think it makes a lot of sense to have a standard way for
> third-parties
> > > to attach string-y information to Haskell source constructs. While it's
> > > not strictly speaking necessary to standardize the syntax, doing
> > > so minimizes the chance that tools overlap and hopefully reduces
> > > the language ecosystem learning curve.
> >
> > This sounds exactly like the existing ANN pragma, which is what I've
> wanted LiquidHaskell to move towards for a long time. What is wrong with
> using the ANN pragma?
>
> Significant compilation performance penalty and extra recompilation.
> ANN pragmas is what HLint currently uses.
>
> >  I'm a bit skeptical of this idea. Afterall, adding cases to the
> > lexer for every tool that wants a pragma seems quite unsustainable.
>
> I don't find this argument that convincing. Given the list already
> includes CATCH and DERIVE, the bar can't have been _that_ high to
> entry. And yet, the list remains pretty short. My guess is the demand
> is pretty low - we're just whitelisting a handful of additional words
> that aren't misspellings.
>
> Thanks, Neil
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Treatment of unknown pragmas

[Brandon Allbery]

Maybe the right answer is to ignore unknown OPTIONS_* pragmas and then use
OPTIONS_HLINT?

On Tue, Oct 16, 2018 at 4:44 PM Simon Marlow  wrote:

> I suggested to Neil that he add the {-# HLINT #-} pragma to GHC. It seemed
> like the least worst option taking into account the various issues that
> have already been described in this thread. I'm OK with adding HLINT; after
> all we already ignore OPTIONS_HADDOCK, OPTIONS_NHC98, a bunch of other
> OPTIONS, CFILES (a Hugs relic), and several more that GHC ignores.
>
> We can either
> (a) not protect people from mistyped pragmas, or
> (b) protect people from mistyped pragma names, but then we have to bake in
> the set of known pragmas
>
> We could choose to have a different convention for pragmas that GHC
> doesn't know about (as Ben suggests), but then of course we don't get any
> protection for mistyped pragma names when using that convention.
>
> Cheers
> Simon
>
>
> On Tue, 16 Oct 2018 at 21:12, Neil Mitchell  wrote:
>
>> > A warning flag is an interesting way to deal with the issue. On the
>> > other hand, it's not great from an ergonomic perspective; afterall, this
>> > would mean that all users of HLint (and any other tool requiring special
>>
>> Yep, this means every HLint user has to do an extra thing. I (the
>> HLint author) now have a whole pile of "how do I disable warnings in
>> Stack", and "what's the equivalent of this in Nix". Personally, it ups
>> the support level significantly that I wouldn't go this route.
>>
>> I think it might be a useful feature in general, as new tools could
>> use the flag to prototype new types of warning, but I imagine once a
>> feature gets popular it becomes too much fuss.
>>
>> > > I think it makes a lot of sense to have a standard way for
>> third-parties
>> > > to attach string-y information to Haskell source constructs. While
>> it's
>> > > not strictly speaking necessary to standardize the syntax, doing
>> > > so minimizes the chance that tools overlap and hopefully reduces
>> > > the language ecosystem learning curve.
>> >
>> > This sounds exactly like the existing ANN pragma, which is what I've
>> wanted LiquidHaskell to move towards for a long time. What is wrong with
>> using the ANN pragma?
>>
>> Significant compilation performance penalty and extra recompilation.
>> ANN pragmas is what HLint currently uses.
>>
>> >  I'm a bit skeptical of this idea. Afterall, adding cases to the
>> > lexer for every tool that wants a pragma seems quite unsustainable.
>>
>> I don't find this argument that convincing. Given the list already
>> includes CATCH and DERIVE, the bar can't have been _that_ high to
>> entry. And yet, the list remains pretty short. My guess is the demand
>> is pretty low - we're just whitelisting a handful of additional words
>> that aren't misspellings.
>>
>> Thanks, Neil
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Treatment of unknown pragmas

[Brandon Allbery]

The problem with ANN is it's part of the plugins API, and as such does
things like compiling the expression into the program in case a plugin
generates code using its value, plus things like recompilation checking end
up assuming plugins are in use and doing extra checking. Using it as a
compile-time pragma is actually fairly weird from that standpoint.

On Tue, Oct 16, 2018 at 4:29 PM Eric Seidel  wrote:

> > > This sounds exactly like the existing ANN pragma, which is what I've
> wanted LiquidHaskell to move towards for a long time. What is wrong with
> using the ANN pragma?
> >
> > Significant compilation performance penalty and extra recompilation.
> > ANN pragmas is what HLint currently uses.
>
> The extra recompilation is annoying for HLint, true, since you probably
> don't care about your annotations being visible from other modules, whereas
> LiquidHaskell does.
>
> But I'm surprised by the compilation performance penalty. I would have
> expected ANN to be fairly cheap. That seems worthy of a bug report,
> regardless of the current discussion about unknown pragmas.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Scripts merged for easily loading and running GHC in GHCi, for fast development iterations

[Brandon Allbery]

If you're working on e.g. ARM, you may not have a lot of say in how much
RAM you can put into it.

On Wed, Aug 8, 2018 at 6:54 PM Michael Sloan  wrote:

> Good point, I have added a note about it to the wiki page.  Surprising
> that it would be hard to kill.  Do you have swap setup?
>
> For me it takes ~2.7GB initially and 3.5GB after the first reload.  In
> the past I've seen it get all the way up to 9GB so there may be some
> memory leakage.
>
> I have 40GB of ram in my laptop, so I don't notice this much.  I
> highly recommend investing in more memory if it's within your
> financial means.  The productivity boon of being able to use GHCi on
> large projects, or run multiple concurrent docker containers or VMs,
> is huge.
>
> A bit off topic, but sometimes folks are surprised that I spend
> hundreds of dollars on keyboards like the kinesis advantage 2 (which
> is fantastic, btw) or the keyboard.io (really nice too!).  My answer
> is that if I'm using some equipment many hours per day, the cost
> amortizes out.  I ask myself "Would I pay 3 cents to use this keyboard
> for an hour?", in the case of those keyboards, my answer is an
> emphatic YES!  I apply similar reasoning to my main computer hardware,
> though people are used to that being $$$ vs the surprise of $350
> keyboards.
>
> -Michael
>
> On Wed, Aug 8, 2018 at 3:31 PM, Matthew Pickering
>  wrote:
> > In practice, how much memory does this use?
> >
> > I find that with 4gb of memory that it is unusable and hard to kill.
> > Perhaps we should add some sort of warning to the page about this.
> >
> > Cheers
> >
> > Matt
> >
> > On Wed, Aug 8, 2018 at 11:12 PM, Michael Sloan 
> wrote:
> >> Now that [D5015] is merged (thanks, monoidal!), -fobject-code no
> >> longer needs to be provided manually.  This also means that you can
> >> run [ghcid] directly in the root of the repo without any arguments.  I
> >> have updated https://ghc.haskell.org/trac/ghc/wiki/Building/InGhci to
> >> use the simpler invocations.
> >>
> >> [D5015]: https://phabricator.haskell.org/D5015
> >> [ghcid]: https://github.com/ndmitchell/ghcid
> >>
> >> On Mon, Aug 6, 2018 at 1:03 AM, Michael Sloan 
> wrote:
> >>> Thanks a bunch for updating the wiki page, Artem!  It was on my todo
> >>> list, but it's been a rather busy week.  I've added an update
> >>> mentioning that it will be possible to run "ghcid" directly without
> >>> args once D5105 is merged.
> >>>
> >>> On Mon, Aug 6, 2018 at 12:55 AM, Artem Pelenitsyn
> >>>  wrote:
>  I added this to the wiki. It would be nice to have a wrapper similar
> to
>  `run.sh` but for starting ghcid, I believe.
> 
>  --
>  Best wishes,
>  Artem
> 
>  On Sun, 29 Jul 2018 at 10:41 Matthew Pickering <
> matthewtpicker...@gmail.com>
>  wrote:
> >
> > Can you please update the wiki page?
> >
> > https://ghc.haskell.org/trac/ghc/wiki/Building/InGhci
> >
> > Matt
> >
> > On Sun, Jul 29, 2018 at 6:18 AM, Michael Sloan 
> wrote:
> > > Hello GHC developers!
> > >
> > > Now that D4904 and D4986 are merged, if you have recently built GHC
> > > then you can use "./utils/ghc-in-ghci/run.sh -fobject-code" to load
> > > GHC into GHCi (throwing on a "-j8" helps too).  For me, this makes
> > > development far more pleasant, as often I can make a change and
> try it
> > > out in only 15 or 20 seconds.  Thanks to Csongor Kiss for writing
> the
> > > initial ghci script, and Matthew Pickering for posting about it to
> the
> > > mailinglist, as otherwise I probably wouldn't have known about it.
> > >
> > > I wrote a blog post about the topic on my new blog:
> > > http://www.mgsloan.com/posts/ghcinception/
> > >
> > > Once D5015 is merged, the explicit "-fobject-code" won't be needed.
> > > Once https://ghc.haskell.org/trac/ghc/ticket/15454 is addressed,
> it
> > > might not be needed at all, leading to even faster loading ;)
> > >
> > > Happy ghci-ing!
> > > -Michael
> > > ___
> > > ghc-devs mailing list
> > > ghc-devs@haskell.org
> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Question about indirectees of BLACKHOLE closures

[Brandon Allbery]

I think I can at least answer the why: we're talking about threads
referring to suspended computations within a thread whose stack is being
"unwound". Those computations won't be resumable after the unwind (which
makes their context go away). So they have to be overwritten with something
to cause the referencing threads to abort if they need the
no-longer-computable results of those suspended computations.

On Sat, Mar 24, 2018 at 3:27 PM, Ömer Sinan Ağacan 
wrote:

> Hi Rahul,
>
> I'm still confused. The code that walks the stack and updates UPDATE_FRAMEs
> only makes indirections point to the "raise" closure, not to thunks or
> anything
> else (I also don't understand why this is needed but I guess that's another
> topic). I still don't see how can a BLACKHOLE point to a THUNK.
>
> Ömer
>
> 2018-03-23 18:51 GMT+03:00 Rahul Muttineni :
> > Hi Omer,
> >
> > As per my understanding, a BLACKHOLE can point to a THUNK when an
> exception
> > is thrown. An exception walks up the stack and overwrites the blackholes
> > pointed to by the update frames as it walks with an stg_raise closure.
> That
> > way, if any concurrent thread happens to evaluate a thunk that was
> walked,
> > it'll evaluate the thunk which will blow up as well thereby throwing the
> > exception on the other thread(s) too.
> >
> > Definition of stg_raise:
> > https://github.com/ghc/ghc/blob/ba5797937e575ce6119de6c07703e9
> 0dda2557e8/rts/Exception.cmm#L424-L427
> >
> > raiseExceptionHelper dealing with update frames:
> > https://github.com/ghc/ghc/blob/d9d463289fe20316cff12a8f0dbf41
> 4db678fa72/rts/Schedule.c#L2864-L2875
> >
> > In general, yes, you can think that a BLACKHOLE will point to a non-THUNK
> > object assuming that everything went right.
> >
> > Hope that helps,
> > Rahul
> >
> > On Fri, Mar 23, 2018 at 5:48 PM, Ömer Sinan Ağacan  >
> > wrote:
> >>
> >> Thanks Simon, that's really helpful.
> >>
> >> A few more questions:
> >>
> >> As far as I understand the difference between
> >>
> >> - BLACKHOLE pointing to a TSO
> >> - BLACKHOLE pointing to a BLOCKING_QUEUE
> >>
> >> is that in the former we don't yet have any threads blocked by the
> >> BLACKHOLE
> >> whereas in the latter we have and the blocking queue holds all those
> >> blocked
> >> threads. Did I get this right?
> >>
> >> Secondly, can a BLACKHOLE point to a THUNK? I'd expect no, because we
> >> BLACKHOLE
> >> a closure when we're done evaluating it (assuming no eager blackholing),
> >> and
> >> evaluation usually happens up to WHNF.
> >>
> >> Thanks,
> >>
> >> Ömer
> >>
> >> 2018-03-20 18:27 GMT+03:00 Simon Marlow :
> >> > Added comments: https://phabricator.haskell.org/D4517
> >> >
> >> > On 20 March 2018 at 14:58, Simon Marlow  wrote:
> >> >>
> >> >> Hi Omer,
> >> >>
> >> >> On 20 March 2018 at 13:05, Ömer Sinan Ağacan 
> >> >> wrote:
> >> >>>
> >> >>> Hi,
> >> >>>
> >> >>> I've been looking at BLACKHOLE closures and how the indirectee field
> >> >>> is
> >> >>> used
> >> >>> and I have a few questions:
> >> >>>
> >> >>> Looking at evacuate for BLACKHOLE closures:
> >> >>>
> >> >>> case BLACKHOLE:
> >> >>> {
> >> >>> StgClosure *r;
> >> >>> const StgInfoTable *i;
> >> >>> r = ((StgInd*)q)->indirectee;
> >> >>> if (GET_CLOSURE_TAG(r) == 0) {
> >> >>> i = r->header.info;
> >> >>> if (IS_FORWARDING_PTR(i)) {
> >> >>> r = (StgClosure *)UN_FORWARDING_PTR(i);
> >> >>> i = r->header.info;
> >> >>> }
> >> >>> if (i == &stg_TSO_info
> >> >>> || i == &stg_WHITEHOLE_info
> >> >>> || i == &stg_BLOCKING_QUEUE_CLEAN_info
> >> >>> || i == &stg_BLOCKING_QUEUE_DIRTY_info) {
> >> >>> copy(p,info,q,sizeofW(StgInd),gen_no);
> >> >>> return;
> >> >>> }
> >> >>> ASSERT(i != &stg_IND_info);
> >> >>> }
> >> >>> q = r;
> >> >>> *p = r;
> >> >>> goto loop;
> >> >>> }
> >> >>>
> >> >>> It seems like indirectee can be a TSO, WHITEHOLE,
> >> >>> BLOCKING_QUEUE_CLEAN,
> >> >>> BLOCKING_QUEUE_DIRTY, and it can't be IND. I'm wondering what does
> it
> >> >>> mean for
> >> >>> a BLACKHOLE to point to a
> >> >>>
> >> >>> - TSO
> >> >>> - WHITEHOLE
> >> >>> - BLOCKING_QUEUE_CLEAN
> >> >>> - BLOCKING_QUEUE_DIRTY
> >> >>
> >> >>
> >> >> That sounds right to me.
> >> >>
> >> >>>
> >> >>> Is this documented somewhere or otherwise could someone give a few
> >> >>> pointers on
> >> >>> where to look in the code?
> >> >>
> >> >>
> >> >> Unfortunately I don't think we have good documentation for this, but
> >> >> you
> >> >> should look at the comments around messageBlackHole in Messages.c.
> >> >>
> >> >>>
> >> >>> Secondly, I also looked at the BLACKHOLE entry code, and it seems
> like
> >> >>> it
> >> >>> has a
> >> >>> different assumption about what can indirectee field point to:
> >> >>>
> >> >>> INFO_TABLE(stg_BLACKHOLE,1,0,BLACKHOLE,"BLACKHOLE",

Re: FFI-free NaN checks? (isDoubleNan and friends)

[Brandon Allbery]

I'd in general expect good C code to optimize a little better; and in
particular, decomposing an IEEE float is almost certainly more expensive in
Haskell than in C, because unions let you cheat. (And I recall looking at
the implementation of decodeFloat once; it's significantly longer than that
C.) But I have to wonder if that code would be better done with something
more native; the implementation may be a portable default, and you might be
able to find something x86-specific that is faster.

On Tue, Mar 6, 2018 at 5:35 AM, Mateusz Kowalczyk 
wrote:

> On 03/05/2018 10:23 PM, Brandon Allbery wrote:
> > If the FFI version is done with "safe", consider using "unsafe" instead.
> > There are technical reasons why this is slightly incorrect, but unless
> > you're fiddling with the CPU's FP control flags they're mostly irrelevant
> > and you can treat isNaN as pure and non-side-effectful, significantly
> > reducing the overhead. You may also be able to use "ccall" to take
> > advantage of C compiler level optimizations, or simply to directly
> invoke a
> > CPU-based test with asm(); but you'll need to hide that in a C
> preprocessor
> > #define, so that it looks syntactically like a function call to the FFI.
> >
> > (One of the technical reasons is that various OSes have been known to
> > introduce bugs in their FP register and state handling across system
> calls,
> > in which case the "safe" version may turn "complete FP chaos" into merely
> > "wrong answer". It's your call whether, or which side, of this bothers
> you.)
>
> Perhaps I was a little unclear. The FFI-using isDoubleNaN is something
> GHC does!
>
> ```
> libraries/base/GHC/Float.hs:foreign import ccall unsafe "isDoubleNaN"
> isDoubleNaN :: Double -> Int
> ```
> ```
> HsInt
> isDoubleNaN(HsDouble d)
> {
>   union stg_ieee754_dbl u;
>
>   u.d = d;
>
>   return (
> u.ieee.exponent  == 2047 /* 2^11 - 1 */ &&  /* Is the exponent all
> ones? */
> (u.ieee.mantissa0 != 0 || u.ieee.mantissa1 != 0)
> /* and the mantissa non-zero? */
> );
> }
> ```
>
> My question is whether it could do better by not doing FFI and instead
> computing natively and if not, why not?
>
> > On Mon, Mar 5, 2018 at 4:53 PM, Mateusz Kowalczyk <
> fuuze...@fuuzetsu.co.uk>
> > wrote:
> >
> >> Hi,
> >>
> >> Recently at a client I was profiling some code and isDoubleNaN lit up.
> >> We were checking a lot of doubles for NaN as that's what customer would
> >> send in.
> >>
> >> I went to investigate and I found that FFI is used to achieve this. I
> >> was always under the impression that FFI costs a little. I had at the
> >> time replaced the code with a hack with great results:
> >>
> >> ```
> >> isNaN' :: Double -> Bool
> >> isNaN' d = d /= d
> >> ```
> >>
> >> While this worked and provided good speedup in my case, this fails
> >> catastrophically if the program is compiled with -ffast-math. This is
> >> expected. I have since reverted it. Seeking an alternative solution I
> >> have thought about re-implementing the C code with a native Haskell
> >> version: after all it just checks a few bits. Apparently unsafeCoerce#
> >> and friends were a big no-no but I found
> >> https://phabricator.haskell.org/D3358 . I have implemented the code at
> >> the bottom of this post. Obviously it's missing endianness (compile-time
> >> switch).
> >>
> >> This seems to be faster for smaller `mkInput` list than Prelude.isNaN
> >> but slower slightly on the one below. The `/=` version is the fastest
> >> but very fragile.
> >>
> >> My question to you all is whether implementing a version of this
> >> function in Haskell makes sense and if not, why not? The
> >> stgDoubleToWord64 is implemented in CMM and I don't know anything about
> >> the costs of that.
> >>
> >> * Is there a cheaper alternative to FFI way?
> >> * If yes, does anyone know how to write it such that it compiles to same
> >> code but without the call overhead? I must have failed below as it's
> >> slower on some inputs.
> >>
> >> Basically if a faster way exists for isNaN, something I have to do a
> >> lot, I'd love to hear about it.
> >>
> >> I leave you with basic code I managed to come up with. 8.4.x only.
> >>
> >>
> >> ```
> >> {-# LANGUAG

Re: FFI-free NaN checks? (isDoubleNan and friends)

[Brandon Allbery]

If the FFI version is done with "safe", consider using "unsafe" instead.
There are technical reasons why this is slightly incorrect, but unless
you're fiddling with the CPU's FP control flags they're mostly irrelevant
and you can treat isNaN as pure and non-side-effectful, significantly
reducing the overhead. You may also be able to use "ccall" to take
advantage of C compiler level optimizations, or simply to directly invoke a
CPU-based test with asm(); but you'll need to hide that in a C preprocessor
#define, so that it looks syntactically like a function call to the FFI.

(One of the technical reasons is that various OSes have been known to
introduce bugs in their FP register and state handling across system calls,
in which case the "safe" version may turn "complete FP chaos" into merely
"wrong answer". It's your call whether, or which side, of this bothers you.)

On Mon, Mar 5, 2018 at 4:53 PM, Mateusz Kowalczyk 
wrote:

> Hi,
>
> Recently at a client I was profiling some code and isDoubleNaN lit up.
> We were checking a lot of doubles for NaN as that's what customer would
> send in.
>
> I went to investigate and I found that FFI is used to achieve this. I
> was always under the impression that FFI costs a little. I had at the
> time replaced the code with a hack with great results:
>
> ```
> isNaN' :: Double -> Bool
> isNaN' d = d /= d
> ```
>
> While this worked and provided good speedup in my case, this fails
> catastrophically if the program is compiled with -ffast-math. This is
> expected. I have since reverted it. Seeking an alternative solution I
> have thought about re-implementing the C code with a native Haskell
> version: after all it just checks a few bits. Apparently unsafeCoerce#
> and friends were a big no-no but I found
> https://phabricator.haskell.org/D3358 . I have implemented the code at
> the bottom of this post. Obviously it's missing endianness (compile-time
> switch).
>
> This seems to be faster for smaller `mkInput` list than Prelude.isNaN
> but slower slightly on the one below. The `/=` version is the fastest
> but very fragile.
>
> My question to you all is whether implementing a version of this
> function in Haskell makes sense and if not, why not? The
> stgDoubleToWord64 is implemented in CMM and I don't know anything about
> the costs of that.
>
> * Is there a cheaper alternative to FFI way?
> * If yes, does anyone know how to write it such that it compiles to same
> code but without the call overhead? I must have failed below as it's
> slower on some inputs.
>
> Basically if a faster way exists for isNaN, something I have to do a
> lot, I'd love to hear about it.
>
> I leave you with basic code I managed to come up with. 8.4.x only.
>
>
> ```
> {-# LANGUAGE MagicHash#-}
> {-# OPTIONS_GHC -O2 -ddump-simpl -ddump-stg -ddump-to-file -ddump-asm #-}
> module Main (main) where
>
> import GHC.Float
> import GHC.Prim
>
> isNaN' :: Double -> Bool
> isNaN' d = d /= d
>
> isNaNBits :: Double -> Bool
> isNaNBits (D# d) = case (bits `and#` expMask) `eqWord#` expMask of
>   1# -> case bits `and#` mantissaMask of
> 0## -> False
> _ -> True
>   _ -> False
>   where
> bits :: Word#
> bits = stgDoubleToWord64 d
>
> expMask, mantissaMask :: Word#
> expMask = 0x7FF0##
> mantissaMask = 0x000F##
>
> main :: IO ()
> main = sumFilter isNaN {-isNaN'-} {-isNaNBits-} (mkInput 1)
> `seq` pure ()
>   where
> nan :: Double
> nan = log (-1)
>
> mkInput :: Int -> [Double]
> mkInput n = take n $ cycle [1, nan]
>
> sumFilter :: (Double -> Bool) -> [Double] -> Double
> sumFilter p = Prelude.sum . Prelude.filter (not . p)
> ```
>
> --
> Mateusz K.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: tigetnum etc -- help!

[Brandon Allbery]

Do you have configure / build log output for the terminfo package?

On Mon, Mar 5, 2018 at 4:25 AM, Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> My stage-1 build (from clean) has started failing thus (on Linux).  Any
> ideas?  It’s pretty disabling because I can’t build GHC any more.
>
> Simon
>
>
>
> make
>
> ===--- building phase 0
>
> make --no-print-directory -f ghc.mk phase=0 phase_0_builds
>
> make[1]: Nothing to be done for 'phase_0_builds'.
>
> ===--- building phase 1
>
> make --no-print-directory -f ghc.mk phase=1 phase_1_builds
>
> "/usr/local/bin/ghc" -o utils/ghc-pkg/dist/build/tmp/ghc-pkg -hisuf hi
> -osuf  o -hcsuf hc -static  -O0 -H64m -Wall   -package-db
> libraries/bootstrapping.conf  -hide-all-packages -i -iutils/ghc-pkg/.
> -iutils/ghc-pkg/dist/build -Iutils/ghc-pkg/dist/build
> -iutils/ghc-pkg/dist/build/ghc-pkg/autogen 
> -Iutils/ghc-pkg/dist/build/ghc-pkg/autogen
> -optP-DWITH_TERMINFO -optP-include 
> -optPutils/ghc-pkg/dist/build/ghc-pkg/autogen/cabal_macros.h
> -package-id Cabal-2.1.0.0 -package-id base-4.10.0.0 -package-id
> binary-0.8.5.1 -package-id bytestring-0.10.8.2 -package-id
> containers-0.5.10.2 -package-id directory-1.3.0.2 -package-id
> filepath-1.4.1.2 -package-id ghc-boot-8.5 -package-id process-1.6.1.0
> -package-id terminfo-0.4.1.1 -package-id unix-2.7.2.2 -XHaskell2010
> -no-user-package-db -rtsopts-odir utils/ghc-pkg/dist/build -hidir
> utils/ghc-pkg/dist/build -stubdir utils/ghc-pkg/dist/build -static  -O0
> -H64m -Wall   -package-db libraries/bootstrapping.conf  -hide-all-packages
> -i -iutils/ghc-pkg/. -iutils/ghc-pkg/dist/build -Iutils/ghc-pkg/dist/build
> -iutils/ghc-pkg/dist/build/ghc-pkg/autogen 
> -Iutils/ghc-pkg/dist/build/ghc-pkg/autogen
> -optP-DWITH_TERMINFO -optP-include 
> -optPutils/ghc-pkg/dist/build/ghc-pkg/autogen/cabal_macros.h
> -package-id Cabal-2.1.0.0 -package-id base-4.10.0.0 -package-id
> binary-0.8.5.1 -package-id bytestring-0.10.8.2 -package-id
> containers-0.5.10.2 -package-id directory-1.3.0.2 -package-id
> filepath-1.4.1.2 -package-id ghc-boot-8.5 -package-id process-1.6.1.0
> -package-id terminfo-0.4.1.1 -package-id unix-2.7.2.2 -XHaskell2010
> -no-user-package-db -rtsoptsutils/ghc-pkg/dist/build/Main.o
> utils/ghc-pkg/dist/build/Version.o
>
> /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/
> build/libHSterminfo-0.4.1.1.a(Base.o):r6De_info: error: undefined
> reference to 'tigetnum'
>
> /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/
> build/libHSterminfo-0.4.1.1.a(Base.o):r6Df_info: error: undefined
> reference to 'tigetflag'
>
> /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/
> build/libHSterminfo-0.4.1.1.a(Base.o):r6Dg_info: error: undefined
> reference to 'tigetstr'
>
> /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/
> build/libHSterminfo-0.4.1.1.a(Base.o):s6Gn_info: error: undefined
> reference to 'set_curterm'
>
> /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/
> build/libHSterminfo-0.4.1.1.a(Base.o):s6Gb_info: error: undefined
> reference to 'set_curterm'
>
> /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/
> build/libHSterminfo-0.4.1.1.a(Base.o):s6I7_info: error: undefined
> reference to 'tparm'
>
> /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/
> build/libHSterminfo-0.4.1.1.a(Base.o):s6JP_info: error: undefined
> reference to 'set_curterm'
>
> /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/
> build/libHSterminfo-0.4.1.1.a(Base.o):s6JA_info: error: undefined
> reference to 'setupterm'
>
> /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/
> build/libHSterminfo-0.4.1.1.a(Base.o):s6Jn_info: error: undefined
> reference to 'set_curterm'
>
> /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/
> build/libHSterminfo-0.4.1.1.a(Base.o):s6KR_info: error: undefined
> reference to 'tputs'
>
> /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/
> build/libHSterminfo-0.4.1.1.a(Base.o)(.data+0xdc8): error: undefined
> reference to 'del_curterm'
>
> collect2: error: ld returned 1 exit status
>
> `gcc' failed in phase `Linker'. (Exit code: 1)
>
> utils/ghc-pkg/ghc.mk:70: recipe for target 
> 'utils/ghc-pkg/dist/build/tmp/ghc-pkg'
> failed
>
> make[1]: *** [utils/ghc-pkg/dist/build/tmp/ghc-pkg] Error 1
>
> Makefile:122: recipe for target 'all' failed
>
> make: *** [all] Error 2
>
> simonpj@cam-05-unx:~/5builds/HEAD-1$
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>


-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: DoAndIfThenElse

[Brandon Allbery]

Huh. I wonder if a section went missing; seems like none of the extensions
that alter or relax layout are documented currently.
(AlternativeLayoutRule, AlternativeLayoutRuleTransitional, DoAndIfThenElse,
NondecreasingIndentation, RelaxedLayout)

IIRC DoAndIfThenElse relaxes a condition implied by layout but that
normally only matters in "do": that if you break it into multiple lines,
the "then" and "else" must be indented farther than the "if" or layout will
consider them distinct new expressions (and thereby syntax errors).

On Thu, Feb 8, 2018 at 9:24 PM, Harendra Kumar 
wrote:

> Hi,
>
> I recently found a mention of DoAndIfThenElse extension somewhere. I
> looked inside the ghc user guide and could not find any such extension.
> Then I looked in the ghc man page, no mention. I googled and found a very
> sparse references to it here and there. Then I tried using the extension
> with ghc and ghc seems to accept it. What's the story behind this, why is
> it not documented but accepted?
>
> thanks,
> harendra
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>


-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [Haskell-cafe] rolling span and groupBy for lists

[Brandon Allbery]

We have two groups of "leaders", with partially opposing goals. This is a
disaster looking for an excuse to happen.

On Mon, Feb 5, 2018 at 2:29 PM, Harendra Kumar 
wrote:

> On 6 February 2018 at 00:33, Sergiu Ivanov  wrote:
>
>> Thus quoth  Harendra Kumar  on Mon Feb 05 2018 at 18:30 (+0100):
>> > Yes, Hayoo seems to be giving better results, I found more variants
>> having
>> > the behavior I want, it seems this variant is quite popular but still
>> not
>> > in any standard libraries.
>> >
>> > Interestingly the problem of too many choices and no standard one that
>> can
>> > be discovered applies to search engines as well. In this case there are
>> > only two choices but still it is of the same nature. I knew about hayoo
>> but
>> > forgot to use it in this case. How much time should one spend on
>> finding a
>> > trivial function before giving up and making the choice to write their
>> own?
>> > I wish there was a standard, quick, good quality way of discovering
>> what to
>> > use.  It seems the Haskell ecosystem DNA encourages more and more
>> > fragmentation rather than consolidation. I think the community/leaders
>> > should acknowledge this problem and work on making things better in the
>> > short/long run.
>>
>> A Single Liberal Unified Registry of Haskell Packages (SLUPR), an effort
>> in this direction, has been recently announced:
>>
>
> Unfortunately, in my opinion, SLURP is taking things exactly in the
> opposite direction. I was talking about the problem of choice above and
> SLURP is giving even more choices  and therefore encouraging more
> fragmentation. We should have just one good choice to stop wasting time and
> energy finding the best choice among millions available. Everyone should
> focus on making that one choice better rather spending energy in creating
> their own alternatives. This is where the Haskell ecosystem philosophy
> differs, it provides many choices in all aspects, it may be good in some
> cases but not always. SLURP is a technology solution which exactly fits in
> the same DNA. Technology can help us achieve the tasks that we set out to
> do but technology cannot motivate and influence us in what we choose to do
> and therefore ti cannot make the community focus on one goal - that
> requires real people leadership. If we do not focus on one goal, even with
> the best technology we may not succeed. Just my 2 cents.
>
> -harendra
>
>
>
>>
>>
>> > -harendra
>> >
>> > On 5 February 2018 at 22:02, Sergiu Ivanov  wrote:
>> >
>> >> Hello Harendra,
>> >>
>> >> Thus quoth  Harendra Kumar  on Mon Feb 05 2018 at 16:43 (+0100):
>> >> >
>> >> > The irony is that theoretically you can find a Haskell package or
>> >> > implementation of whatever you can imagine but quite often it takes
>> more
>> >> > time to discover it than writing your own.
>> >>
>> >> Sometimes Hayoo! helps me out in such situations:
>> >>
>> >>   http://hayoo.fh-wedel.de/?query=groupBy
>> >>
>> >> utility-ht shows up.
>> >>
>> >> --
>> >> Sergiu
>> >>
>>
>>
>> --
>> Sergiu
>>
>
>
> ___
> 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.
>



-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: rolling span and groupBy for lists

[Brandon Allbery]

Why do I suddenly catch a whiff of https://xkcd.com/927/ ?

On Mon, Feb 5, 2018 at 1:13 PM, Harendra Kumar 
wrote:

> According to hayoo there seem to be 7 different implementations of this
> same function. Yours is 8th and mine is 9th and other people may have more
> not uploaded or maybe the ones that hayoo is not able to find. Does that
> make a case for including this in some standard place?
>
> -harendra
>
> On 5 February 2018 at 12:22, Evan Laforge  wrote:
>
>> I have my own list library with a bunch of things like this.  I think
>> it's what most people do, and some upload them to hackage, e.g.
>> utility-ht or the split package, or data-ordlist.
>>
>> Specifically, I think rollingGroupBy is what I call splitWith:
>>
>> -- | Split @xs@ before places where @f@ matches.
>> --
>> -- > split_with (==1) [1,2,1]
>> -- > --> [[], [1, 2], [1]]
>> split_with :: (a -> Bool) -> [a] -> NonNull [a]
>> -- ^ output is non-null, and the contents are also, except the first
>> one
>>
>> You can probably find something like this in 'split', or if not, that
>> might be a good place to contribute it.
>>
>> I have a bunch of grouping functions too, which I use all the time, so
>> if there's some kind of general list grouping package then maybe I
>> could put them there.
>>
>> On the other hand, this sort of thing is pretty individual, so it
>> doesn't seem so bad for each person to have their own local library.
>> That way you know it fits your style.  Ultimately I think that's why
>> none of the split functions made it into Data.List, every person has a
>> slightly different idea of what it should be.
>>
>> On Sun, Feb 4, 2018 at 7:50 PM, Harendra Kumar 
>> wrote:
>> > Hi,
>> >
>> > For a small problem, I was looking for a groupBy like function that
>> groups
>> > based on a predicate on successive elements but I could not find one. I
>> > wrote these little functions for that purpose:
>> >
>> > -- | Like span, but with a predicate that compares two successive
>> elements.
>> > The
>> > -- span ends when the two successive elements do not satisfy the
>> predicate.
>> > rollingSpan :: (a -> a -> Bool) -> [a] -> ([a], [a])
>> > rollingSpan _ xs@[] = (xs, xs)
>> > rollingSpan _ xs@[_] = (xs, [])
>> > rollingSpan p (x1:xs@(x2:_))
>> > | p x1 x2 =
>> > let (ys, zs) = rollingSpan p xs
>> > in (x1 : ys, zs)
>> > | otherwise = ([x1], xs)
>> >
>> > -- | Like 'groupBy' but with a predicate that compares two successive
>> > elements.
>> > -- A group ends when two successive elements do not satisfy the
>> predicate.
>> > rollingGroupBy :: (a -> a -> Bool) -> [a] -> [[a]]
>> > rollingGroupBy _ [] = []
>> > rollingGroupBy cmp xs =
>> > let (ys, zs) = rollingSpan cmp xs
>> > in ys : rollingGroupBy cmp zs
>> >
>> > Are there any existing functions that serve this purpose or is there any
>> > simpler way to achieve such functionality? If not, where is the right
>> place
>> > for these, if any. Can they be included in Data.List in base?
>> >
>> > Thanks,
>> > Harendra
>> >
>> > ___
>> > ghc-devs mailing list
>> > ghc-devs@haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >
>>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>


-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: pattern signatures

[Brandon Allbery]

Further complicated by the fact that that form used to be called a "pattern
signature" with accompanying extension, until that was folded into
ScopedTypeVariables extension.

On Fri, Jan 5, 2018 at 9:41 AM, Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> Ah yes. I think we started with "pattern synonym signature" for (b) but
> have since denenerated to "pattern signature" which is quite confusing.
>
> User advice would be good!
>
> S
>
> |  -Original Message-
> |  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
> |  Richard Eisenberg
> |  Sent: 05 January 2018 13:48
> |  To: GHC 
> |  Subject: pattern signatures
> |
> |  Hi devs,
> |
> |  Is a pattern signature
> |
> |  a) something you put after `pattern P ::` ?
> |  b) something you put after `::` in a pattern, as in `foo (Proxy ::
> |  Proxy a)` ?
> |
> |  I've seen the term "pattern signature" apply to both, and I've been
> |  tripped up by this. Does anyone have terminology that unambiguously
> |  separates these two constructs that we can all adopt?
> |
> |  Thanks!
> |  Richard
> |  ___
> |  ghc-devs mailing list
> |  ghc-devs@haskell.org
> |  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
> |  askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
> |  devs&data=02%7C01%7Csimonpj%40microsoft.com%7Cbc86346cc90f4a9516d108d5
> |  5442f5a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6365075689386605
> |  89&sdata=gvjnHyGAojz982UEV1u0hZPKH%2B%2F3UjiDlQm10%2BRZ7r8%3D&reserved
> |  =0
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Can't push to staging area?

[Brandon Allbery]

"sudo: a password is required"

Can't even tell if that's local (beware e.g. Ubuntu defaults) or remote
(which would be a configuration problem on the remote end, not to mention
seeming like a bad idea).

On Wed, Jan 3, 2018 at 6:36 PM, Bartosz Nitka  wrote:

> I'm trying to update a diff and I run into this:
>
> $ arc diff
> Linting...
>  LINT OKAY  No lint problems.
> Running unit tests...
> No unit test engine is configured for this project.
>  PUSH STAGING  Pushing changes to staging area...
> sudo: a password is required
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and the repository exists.
>  STAGING FAILED  Unable to push changes to the staging area.
> Usage Exception: Failed to push changes to staging area. Correct the
> issue, or use --skip-staging to skip this step.
>
>
> I believe that it worked for me before with my setup, and I seem to be
> in compliance with
> https://ghc.haskell.org/trac/ghc/wiki/Phabricator#Startingoff:
> Fixingabugsubmittingareview
>
> Any ideas?
>
> Thanks,
> Bartosz
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Haskell Platform 8.2.2 - virus?

[Brandon Allbery]

"Hitman" sounds rather self-descriptive. Not sure I'd allow such a thing
onto any system under my control; it sounds pretty much like malware in its
own right.

On Thu, Dec 28, 2017 at 6:09 PM,  wrote:

>
>
> We have fixed this though, GHC 8.4 shouldn’t have this problem
> specifically.
>
>
>
> The issue is that hitman pro is injecting itself into every process by
> throwing a signal,
>
> Prior to 8.4 we were pretty aggressive in how we treated first chance
> exceptions. We’ve now relaxed this.
>
>
>
> That said I find the behavior of HitmanPro to be quite intrusive and I
> wouldn’t trust anything injecting code
>
> Into my address space.
>
>
>
> Fyi, this is what it caused:
>
>
>
> ExceptionAddress: 7ffcc2b368ce (ntdll!RtlVirtualUnwind+
> 0x001e)
> ExceptionCode: c005 (Access violation)
> ExceptionFlags: 
> NumberParameters: 2
> Parameter[0]: 
> Parameter[1]: 046710f6
> Attempt to read from address 046710f6
> 0:000> lmvm hmpalert
> Browse full module list
> start end module name
> 7ffc`ba4b 7ffc`ba595000 hmpalert (export symbols) hmpalert.dll
> Loaded symbol image file: hmpalert.dll
> Image path: C:\Windows\System32\hmpalert.dll
> Image name: hmpalert.dll
> Browse all global symbols functions data
> Timestamp: Mon Jul 17 15:53:17 2017 (596CCF5D)
> CheckSum: 000F490C
> ImageSize: 000E5000
> File version: 3.6.8.604
> Product version: 3.6.8.604
> File flags: 0 (Mask 3F)
> File OS: 40004 NT Win32
> File type: 2.0 Dll
> File date: .
> Translations: 0400.04b0
> CompanyName: SurfRight B.V.
> ProductName: HitmanPro.Alert
> InternalName: hmpalert.dll
> OriginalFilename: hmpalert_x64.dll
> ProductVersion: 3.6.8.604
> FileVersion: 3.6.8.604
> FileDescription: HitmanPro.Alert 64-bit Support Library
> LegalCopyright: © 2013-2017 SurfRight, a Sophos company
> Comments: Incorporates Threatstar Exploit Mitigation Platform (EMP)
>
>
>
> *From: *Gershom B 
> *Sent: *Thursday, December 28, 2017 22:24
> *To: *ghc-devs@haskell.org Devs 
> *Subject: *RE: Haskell Platform 8.2.2 - virus?
>
>
>
> Note that HitmanPro has caused plenty of problems with GHC in the
>
> past, and should be avoided by Haskell devs:
>
>
>
> https://www.reddit.com/r/haskell/comments/77from/
> gettting_segmentation_fault_on_stackcabal_any/
>
>
>
> https://github.com/commercialhaskell/intero/issues/436
>
> ___
>
> ghc-devs mailing list
>
> ghc-devs@haskell.org
>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>


-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Haskell Platform 8.2.2 - virus?

[Brandon Allbery]

This wouldn't be the first time some program that uses heuristic execution
patterns to detect malware decided it didn't like the STG.

On Thu, Dec 28, 2017 at 4:15 PM, Matthew Lamari 
wrote:

>
> The site gave me the 5ffdaa sha256 you have below for touchy.exe.
>
> That said, I still have the 2 builds yield different results from Hitman
> Pro on the clean boxes. And Bitdefender, on my machine, (albeit being
> obtuse) chucks a fit over it. It doesn't detect the EXE files; but detects
> secondary consequences of them running.
>
>
> *I really think something is afoot here.*
>
>
>
>
> On 12/28/2017 3:00 PM, loneti...@gmail.com wrote:
>
> Upload one of the binaries it flagged to https://www.virustotal.com/en/
> and send the link.
>
>
>
> As far as I can tell, they’re all clean
>
>
>
> https://www.virustotal.com/en/file/9cc2a6032dde8d8ab572f949104124
> 2ab4c76d2b7d36eea5283c82cf9bf9fd69/analysis/
>
> https://www.virustotal.com/en/file/5ffdaa7da4381637ab2a0ec327118c
> d933398a477430e2f5d94e9d53c53f2782/analysis/
>
>
>
> *From: *Matthew Lamari 
> *Sent: *Thursday, December 28, 2017 20:29
> *To: *ghc-devs@haskell.org
> *Subject: *Haskell Platform 8.2.2 - virus?
>
>
>
>
>
> New Haskell install was tripping my Bitdefender like crazy and in weird
>
> ways - not new as that's how bitdefender rolls. However, I retested in a
>
> clean test, with (free) Hitman Pro
>
>
>
> I started from a base case with 2 clean windows 8 VMs.
>
>
>
> New 8.2.2 install - has virus
>
> Old 8.0.2 Jan 2017 - no virus
>
>
>
>
>
> According to Hitman Pro, touchy.exe, haddock-8.2.2, ghc-8.2.2.exe, and
>
> unlit.exe have some problem post-install. I went no further on the VMs.
>
>
>
> "Detection Names
>
> Kaspersky   Trojan-Downloader.Win32.Paph.fsv
>
> "
>
>
>
> Bitdefender didn't get it on install but would lock the whole thing down
>
> on the first run of "Cabal".
>
>
>
> ___
>
> ghc-devs mailing list
>
> ghc-devs@haskell.org
>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>


-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Can't push to haddock

[Brandon Allbery]

On Tue, Dec 19, 2017 at 4:30 AM, Sven Panne  wrote:

> I think this is a question of perspective: Having the master repository on
> GitHub doesn't mean you are in immediate danger or lose your "family
> jewels". IMHO it's quite the contrary: I'm e.g. sure that in case that
> something goes wrong with GitHub, there is far more manpower behind it to
> fix that than for any self-hosted repository. And you can of course have
> some mirror of your GitHub repo in case of e.g. an earthquake/meteor/... in
> the San Francisco area... ;-)
>

You're also assuming github doesn't suddenly pull a SourceForge (or a
Gitorious for that matter). Business cares not what it steamrolls in the
name of profit.

I fail to understand why, with multiple examples of the folly of this
belief out there, people are still willing to bet on *this* company being
*different* from all others and absolutely safe to trust.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Long standing annoying issue in ghci

[Brandon Allbery]

It's indirectly already there:
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html#the-ghci-and-haskeline-files
Possibly an additional pointer needs to be in the FAQ/things to watch out
for section.

On Tue, Dec 5, 2017 at 5:13 PM, David Feuer  wrote:

> It sounds like this should be added to the GHCi documentation, even if
> it's not strictly about GHCi.
>
>
>
> David Feuer
> Well-Typed, LLP
>
>  Original message 
> From: Evan Laforge 
> Date: 12/5/17 4:49 PM (GMT-05:00)
> To: Brandon Allbery 
> Cc: ghc-devs@haskell.org
> Subject: Re: Long standing annoying issue in ghci
>
> Here's what I use:
>
> :set prompt "\ESC[46m\STX%s>\ESC[39;49m\STX "
>
> I believe \STX is a signal to haskeline for control sequences.
> Documentation is here:
> https://github.com/judah/haskeline/wiki/ControlSequencesInPrompt
>
> On Tue, Dec 5, 2017 at 12:57 PM, Brandon Allbery 
> wrote:
> > On Tue, Dec 5, 2017 at 12:36 PM, cheater00 cheater00 <
> cheate...@gmail.com>
> > wrote:
> >>
> >> without color coding the prompt so I can't really turn it off. It
> >> seems like a simple arithmetic issue somewhere in the readline
> >> implementation.
> >
> >
> > It's not arithmetic except in the sense that it's not doing *any* math.
> > Color codes in a terminal are necessarily implemented as character
> sequences
> > (this is pretty much the definition of a terminal interface), and
> haskeline
> > makes no effort to recognize them, so it treats them the same as
> displayed
> > character sequences and skips over them as if they were displayed
> > characters.
> >
> > GNU readline handles this by recognizing the character mode sequences as
> not
> > taking up character positions (this is more complex than you think given
> > that GNU readline doesn't assume all terminals obey the ANSI standard;
> as it
> > turns out, neither does haskeline, so it actually gets a bit nasty), and
> > recognizing the special behavior of carriage return, and providing \[ \]
> > escapes to declare the sequence inside as "invisible" to to character
> > positioning (and it's on the person crafting the prompt to insure that it
> > actually is). Beyond that, it'd actually have to implement a 'terminal
> > emulator' internally to get it right in all cases --- and i'd be on the
> user
> > to ensure their declared terminal type matches the actual one well enough
> > for the 'terminal emulator' to reflect the terminal's actual behavior, so
> > it'd be a potential source of even weirder behavior.
> >
> > So, (a) haskeline issue, not strictly ghc/ghci, and (b) not really
> fixable,
> > but partially work-around-able for common cases.
> >
> > --
> > brandon s allbery kf8nh   sine nomine
> associates
> > allber...@gmail.com
> ballb...@sinenomine.net
> > unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Long standing annoying issue in ghci

[Brandon Allbery]

On Tue, Dec 5, 2017 at 4:49 PM, Evan Laforge  wrote:

> I believe \STX is a signal to haskeline for control sequences.
> Documentation is here:
> https://github.com/judah/haskeline/wiki/ControlSequencesInPrompt


Huh, so they did add support for that. With a version constraint, so this
will depend also on haskeline version (and therefore ghc version, and what
works in newer ghci will therefore not work in older ones).

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Long standing annoying issue in ghci

[Brandon Allbery]

On Tue, Dec 5, 2017 at 12:36 PM, cheater00 cheater00 
wrote:

> without color coding the prompt so I can't really turn it off. It
> seems like a simple arithmetic issue somewhere in the readline
> implementation.
>

It's not arithmetic except in the sense that it's not doing *any* math.
Color codes in a terminal are necessarily implemented as character
sequences (this is pretty much the definition of a terminal interface), and
haskeline makes no effort to recognize them, so it treats them the same as
displayed character sequences and skips over them as if they were displayed
characters.

GNU readline handles this by recognizing the character mode sequences as
not taking up character positions (this is more complex than you think
given that GNU readline doesn't assume all terminals obey the ANSI
standard; as it turns out, neither does haskeline, so it actually gets a
bit nasty), and recognizing the special behavior of carriage return, and
providing \[ \] escapes to declare the sequence inside as "invisible" to to
character positioning (and it's on the person crafting the prompt to insure
that it actually is). Beyond that, it'd actually have to implement a
'terminal emulator' internally to get it right in all cases --- and i'd be
on the user to ensure their declared terminal type matches the actual one
well enough for the 'terminal emulator' to reflect the terminal's actual
behavior, so it'd be a potential source of even weirder behavior.

So, (a) haskeline issue, not strictly ghc/ghci, and (b) not really fixable,
but partially work-around-able for common cases.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How to load & parse an HI (interface) file?

[Brandon Allbery]

The problem with the API is it's complex and can break between ghc versions.
But --show-iface is even more fragile and prone to break between ghc
versions.
The history of the plugins package constitutes a record of both kinds of
pain.

On Sat, Dec 2, 2017 at 9:11 PM, Saurabh Nanda 
wrote:

> > I would be cautious about using the ghc-api hi file interfaces; hi files
> turn out to interact with a
> > lot of low-level parts in complex ways (even to the extent that they're
> a large part of why ghc
> > can't parallelize builds itself and attempts to change that have mostly
> failed).
>
> Are you cautioning against using the GHC API (as opposed to the
> --show-iface command line interface)
> or using HI files themselves?
>
> -- Saurabh.
>
>
> On Sun, Dec 3, 2017 at 2:04 AM, Brandon Allbery 
> wrote:
>
>> I would be cautious about using the ghc-api hi file interfaces; hi files
>> turn out to interact with a lot of low-level parts in complex ways (even to
>> the extent that they're a large part of why ghc can't parallelize builds
>> itself and attempts to change that have mostly failed).
>>
>> But if you must do this, you *really* want to have
>> https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler ready to hand
>> --- and go through it first so you have some idea of how it works; much of
>> it is links to the lower level details (often straight into the source).
>>
>> On Sat, Dec 2, 2017 at 10:59 AM, Saurabh Nanda 
>> wrote:
>>
>>> (GHC newbie alert -- is this the right mailing list for these kind of
>>> questions?)
>>>
>>> I"m writing some code to figure out all the instances of particular
>>> type-classes and after exploring a lot of options (hlint, haskell-src-exts,
>>> annotations, doctests, etc), I realized that the compiler had already
>>> figured it out and written it to disk for me!
>>>
>>> More digging led me to https://www.stackage.org/haddo
>>> ck/lts-9.0/ghc-8.0.2/LoadIface.html#v:loadSrcInterface after which I
>>> got stuck. How does one call this function? Specifically:
>>>
>>> * What is SDoc and how to construct a reasonable value for this argument?
>>> * IsBootInterface would mostly be False, right?
>>> * What does `Maybe FastString` represent and how does one construct it?
>>> * Finally how does one evaluate the resulting monadic action to get
>>> access to the underlying `ModIface`?
>>>
>>> -- Saurabh.
>>>
>>>
>>> ___
>>> ghc-devs mailing list
>>> ghc-devs@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>>
>>
>>
>> --
>> brandon s allbery kf8nh   sine nomine
>> associates
>> allber...@gmail.com
>> ballb...@sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>>
>
>
>
> --
> http://www.saurabhnanda.com
>



-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How to load & parse an HI (interface) file?

[Brandon Allbery]

I would be cautious about using the ghc-api hi file interfaces; hi files
turn out to interact with a lot of low-level parts in complex ways (even to
the extent that they're a large part of why ghc can't parallelize builds
itself and attempts to change that have mostly failed).

But if you must do this, you *really* want to have
https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler ready to hand ---
and go through it first so you have some idea of how it works; much of it
is links to the lower level details (often straight into the source).

On Sat, Dec 2, 2017 at 10:59 AM, Saurabh Nanda 
wrote:

> (GHC newbie alert -- is this the right mailing list for these kind of
> questions?)
>
> I"m writing some code to figure out all the instances of particular
> type-classes and after exploring a lot of options (hlint, haskell-src-exts,
> annotations, doctests, etc), I realized that the compiler had already
> figured it out and written it to disk for me!
>
> More digging led me to https://www.stackage.org/haddock/lts-9.0/ghc-8.0.2/
> LoadIface.html#v:loadSrcInterface after which I got stuck. How does one
> call this function? Specifically:
>
> * What is SDoc and how to construct a reasonable value for this argument?
> * IsBootInterface would mostly be False, right?
> * What does `Maybe FastString` represent and how does one construct it?
> * Finally how does one evaluate the resulting monadic action to get access
> to the underlying `ModIface`?
>
> -- Saurabh.
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>


-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs