Re: BoxedRep UNPACK pragma

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

Re: GitLab partial outage - attempting to mitigate

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

Re: Installing GHC on my MacBook Air

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

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

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

Re: Milestones page is missing or has inaccurate dates

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

Re: A macOS static linking mystery

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,

Re: A macOS static linking mystery

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

Re: A macOS static linking mystery

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

Re: regression in ghc / cabal integration in 9.2.1

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

Re: Meaning of -i and -hidir

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: > >>

Re: where to go for HLS details?

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

Re: please help with ghc package-db flags

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

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

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

Re: GHC and the future of Freenode

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.

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

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

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

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

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

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

Re: Parsing funny arrows

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.

Re: GHC Logo

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

Re: Question about binary distributions

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

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

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@haskel

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

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

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

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

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

Re: Multiple instance pragmas

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

Re: Compiling binaries of bytecode: ever been considered?

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

Re: validate-x86_64-darwin failing

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.) ___

Re: slow load and typecheck

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

Re: slow load and typecheck

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: > > >

Re: slow load and typecheck

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

Re: slow load and typecheck

.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

Re: slow load and typecheck

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

Re: Coercible questions

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

Re: GHC/StgToCmm/Con.hs

"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

Re: GHC: Policy on -O flags?

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. >

Re: Conveniently searching GitLab

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: >

Re: api to access .hi files

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

Re: api to access .hi files

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

Re: GHC native bootstrap

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

Re: gitlab sometimes slow

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.

Re: Gitlab workflow

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

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

"-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

Re: Pushing to gitlab.haskell.org

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. >

Re: setsockopt IPV2_TCLASS 8

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

Re: Container type classes

ea 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 ::

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 wrote: > Hi Artem, > > > > Thanks for the pointer, but this doesn’t seem to be a solution to my >

Re: Overloaded names for Map/Set?

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 >

Re: Cabal woes

ed 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

Re: Cabal woes

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

Re: Cabal woes

: > 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 > highlig

Re: Cabal woes

ous 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

Re: Cabal woes

structions 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 > > > &

Re: Getting Rewrite Rules from ModGuts

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

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

r 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 > >

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

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

Re: Discussion: Hadrian's defaults

, 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 >>

Re: [ambiguous occurrence bug?]

n, 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 d

Re: [ambiguous occurrence bug?]

t 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

Re: [ambiguous occurrence bug?]

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

Re: Discussion: Hadrian's defaults

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

Re: github ghc.git broken on libraries/binary

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

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

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.

Re: "resource exhausted" in CI

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 unde

Re: "resource exhausted" in CI

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

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

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

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

uild 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

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

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

Re: Treatment of unknown pragmas

}" (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 p

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

Re: Treatment of unknown pragmas

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 >

Re: Treatment of unknown pragmas

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

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

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

Re: Question about indirectees of BLACKHOLE closures

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

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

3/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

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

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

Re: tigetnum etc -- help!

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

Re: DoAndIfThenElse

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

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

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

Re: rolling span and groupBy for lists

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

Re: pattern signatures

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

Re: Can't push to staging area?

"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

Re: Can't push to haddock

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 >

Re: Long standing annoying issue in ghci

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

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

d 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 <allber...@g

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

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

Re: Dynamically choosing the main function

On Mon, Nov 13, 2017 at 2:46 AM, Harendra Kumar wrote: > Also, the symbols are anyway exposed to the users, we just ask the users > to not look at those. > Only if you built a dynamic executable, or built for debugging. Default static executables are stripped. --

Re: Dynamically choosing the main function

On Sun, Nov 12, 2017 at 11:18 AM, Harendra Kumar wrote: > GHC allows choosing a main function at link time using the "-main-is" > option. I was wondering if there is a possibility to choose the main > function at runtime. Or even better, if something equivalent to "ghc

Re: Q: Types in GADT pattern match

On Mon, Oct 30, 2017 at 5:14 AM, Gabor Greif wrote: > My original question, though, is not answered yet, namely why not to > detect that we are about to pattern match on a GADT constructor and > allow the programmer to capture the *refined* type with her type > annotation. Sure

Re: Relocatable dist

t; 8.4. Adding new functionality for cross-compilation to the old build system > is frustrating. > > Manuel > > Brandon Allbery <allber...@gmail.com>: > > On Tue, Oct 24, 2017 at 5:02 AM, Moritz Angermann < > moritz.angerm...@gmail.com> wrote: > >

Re: Relocatable dist

On Tue, Oct 24, 2017 at 5:02 AM, Moritz Angermann < moritz.angerm...@gmail.com> wrote: > However, I am now again at the point where I start hacking on the build > system, while Hadrian is imminent. And this is quite depressing > Realistically, while Hadrian going into the tree may be imminent,

Re: Compiling natively GHC for ARMv7l softabi

On Tue, Oct 17, 2017 at 12:41 AM, wrote: > utils/ghc-cabal/ghc.mk:48: recipe for target > 'utils/ghc-cabal/dist/build/tmp/ghc-cabal' > failed > make[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Killed > The OOM killer got you. Add swap if you can. -- brandon s

Re: Can I get the internal name of a package at runtime?

the inlinings from the .hi file anyway. If you get multiple matches, you could warn about it but because you can't use the .hi inlinings in that context it won't matter which one you load. On Sat, Oct 14, 2017 at 4:19 PM, Brandon Allbery <allber...@gmail.com> wrote: > On Sat, Oct 14, 2017 at 3:59 PM

Re: Can I get the internal name of a package at runtime?

On Sat, Oct 14, 2017 at 3:59 PM, MarLinn wrote: > That sounds reasonable, but also like there *can not be* a way to obtain > that hash at runtime. And therefore, no way to discover the true package > name. > I can think of a hacky way: make sure the symbol table is still

Re: Can I get the internal name of a package at runtime?

On Sat, Oct 14, 2017 at 12:48 PM, MarLinn wrote: > So the "actual" package name seems to be "Plugin-0.0.0.0-2QaFQQzYhnKJSP > RXA7VtPe". > That leaves the random(?) characters behind the version number to be > explained. > ABI hash of that specific package build, which is

Re: Ignoring ANN Module "HLint: ..."

On Sun, Sep 24, 2017 at 1:51 AM, Moritz Angermann < moritz.angerm...@gmail.com> wrote: > > > As I understand it, ANNotations are intended for use with ghc plugins; > hlint's use of them is not *quite* an abuse, since it is relying on > haskell-src-exts handling of them rather than ghc's. > > I did

Re: Ignoring ANN Module "HLint: ..."

On Sun, Sep 24, 2017 at 1:44 AM, Moritz Angermann < moritz.angerm...@gmail.com> wrote: > can we detect annotations like `{-# ANN module "HLint: ignore Reduce > duplication" #-}` easily? > Right now this will result (without -fexternal-interpreter or a stage2 > compiler) in > > Ignoring ANN

Re: Alex install failure

On Mon, Aug 28, 2017 at 1:42 PM, Ben Gamari wrote: > Hmm, interesting. So it seems almost certain at this point that you are > not running the lock daemon. In contrast, on an NFSv3 client that I > setup I see, > This is moderately likely to be common: many people

Re: Alex install failure

On Fri, Aug 18, 2017 at 8:04 AM, Ben Gamari wrote: > Simon Peyton Jones via ghc-devs writes: > > I'm trying to update my installation of alex, on Unix (Ubuntu). But I > get the dump below > > It's complaining about a lock file being an invalid

Re: GHC release timing and future build infrastructure

On Mon, Jul 31, 2017 at 10:19 PM, Ben Gamari wrote: > I just posted a pair of posts on the GHC blog [1,2] laying out some > thoughts on the GHC release cycle timing [1] and how this relates to the > in-progress Jenkins build infrastructure [2]. When you have a some time >

Re: 8.2.1: Ord TyCon is gone?

On Sat, Jul 29, 2017 at 10:07 AM, Ben Gamari wrote: > Hmm. I am unable to reproduce this, > > $ ghci > λ> import Type.Reflection > λ> let tc = typeRepTyCon (typeRep @Int) > λ> tc == tc > True > > Does that work for you? > Maybe I'm missing something,

  1   2   >