Fixing 8266: How do I get a list of all dist-install/build directories?

Hello everyone, I'm trying to write a patch for #8266. Here's what I have so far: https://gist.github.com/christiaanb/6648192 It changes the name of the dynamic library to a relative path instead of an absolute one. However, now I'm getting an error while building the DPH packages (probably due

Re: Executables using GHC API require dynamic linking in GHC 7.7

and all the relevant information there in. That is the best way to promptly get folks to see it -Carter On Saturday, September 28, 2013 at 2:55 AM, Christiaan Baaij wrote: Yes, I have both the static libs and the dynamic libs. So for every library I have both the 'libHSPACKAGE

Re: [commit: packages/base] master: Expose performMinorGC (#8257) (c1491e6)

Shouldn't the last line of the patch be?: +foreign import ccall performGC performMinorGC :: IO () the rts doesn't export a function called performMinorGC. -- Christiaan On Sep 30, 2013, at 12:24 AM, g...@git.haskell.org wrote: Repository : ssh://g...@git.haskell.org/base On branch :

Re: Validate broken on Snow Leopard and Mountain Lion

The error in snow leopard is the result of my patch [1] for #8266 [2], which ensures that the original build directory is no longer referenced in installed packages/libs. The patch is just a proper implementation of the original design though. Perhaps the relative-dynlib-references procedure

Re: Validate broken on Snow Leopard and Mountain Lion

is probably the single HUGEST barrier to more people getting involved in helping GHC dev. And I think thats a huge problem we need to take more seriously. On Wed, Nov 13, 2013 at 11:09 PM, Ben Lippmeier b...@ouroborus.net wrote: On 13/11/2013, at 8:02 PM, Christiaan Baaij wrote

Re: Validate broken on Snow Leopard and Mountain Lion

. On Wed, Nov 13, 2013 at 11:09 PM, Ben Lippmeier b...@ouroborus.net wrote: On 13/11/2013, at 8:02 PM, Christiaan Baaij wrote: Does validate work for the DPH packages on Linux? sh validate runs fine on my Linux machine, but neither of my Macs. I can also run the dph tests manually

Re: Validate broken on Snow Leopard and Mountain Lion

,hpc,optasm,threaded1,threaded2,dyn,optllvm) typecheck/should_runT7861 [bad stdout or stderr] (ghci) On Nov 14, 2013, at 12:04 PM, Christiaan Baaij christiaan.ba...@gmail.com wrote: After fixing the warning in the C-code of the primitive package, validate (including dph tests) seems

Re: Validate broken on Snow Leopard and Mountain Lion

,optllvm) typecheck/should_runT7861 [bad stdout or stderr] (ghci) On Nov 14, 2013, at 12:04 PM, Christiaan Baaij christiaan.ba...@gmail.com wrote: After fixing the warning in the C-code of the primitive package, validate (including dph tests) seems to be working for me: OVERALL

Why is an irrefutable pattern desugared to a 'cast', while an incomplete pattern is not?

Dear list, When I ask for the desugaring of: module PatError where paterror :: Maybe Int - Int paterror (Just i) = i I get the following: PatError.paterror = \ (ds_dIS :: Data.Maybe.Maybe GHC.Types.Int) - break1() case ds_dIS of _ [Occ=Dead] { __DEFAULT - (\ _

Re: Many new validate failures, Synonym in TyConAppCo-related

I see that the core-lint patch calls: -- | Is this a 'TyCon' representing a type synonym (@type@)? isSynTyCon :: TyCon - Bool isSynTyCon (SynTyCon {}) = True isSynTyCon _ = False And from simon's comments it seems like he only wanted to check for normal type synonyms.

Re: Call for help on testing integer-gmp2 on non-Linux archs

Starting a build on my MAC: OS: 10.8.5 XCode: XCode 4 CLI-only (so _no_ full Xcode, that is, xcode-select fails) GCC: i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) GHC: 7.8.3 On Jul 22, 2014, at 2:02 PM, Herbert Valerio Riedel h...@gnu.org

Re: Call for help on testing integer-gmp2 on non-Linux archs

The testsuite results are here: http://paste.ubuntu.com/7836630/ On Jul 22, 2014, at 2:11 PM, Christiaan Baaij christiaan.ba...@gmail.com wrote: Starting a build on my MAC: OS: 10.8.5 XCode: XCode 4 CLI-only (so _no_ full Xcode, that is, xcode-select fails) GCC: i686-apple-darwin11-llvm

Re: Current description of Core?

Perhaps slightly off-topic. I have looked at the core-spec document, and had a question regarding the operational semantics part. Given the Core expressions: case (let r = 1 : r in r) of (x:xs) - x An interpreter following the semantics would loop on the above expression, as the

Re: Current description of Core?

Perhaps slightly off-topic. I have looked at the core-spec document, and had a question regarding the operational semantics part. Given the Core expressions: case (let r = 1 : r in r) of (x:xs) - x An interpreter following the semantics would loop on the above expression, as the

Interactions between type-checker plugins

Hi, My apologies for this rather lengthy email. I have a question about how type-checker plugins should interact. My situation is the following: I have two type-checker plugins, one that can solve equalities involving the standard type-level operations on kind Nat (+,*,-,^), and another

Re: Interactions between type-checker plugins

On 19 May 2015, at 18:44, Christiaan Baaij christiaan.ba...@gmail.com wrote: I have yet to test this properly, but I don't think your suggestions (which you happen to give with 1 minute of eachother...) play nicely with error reporting. Here is an output of my testsuite: ``` [1 of 2

Re: [commit: ghc] master: Refactor tuple constraints (ffc2150)

Hi, This patch broke the ‘Binary’ instance for ‘IfaceType’ in ‘iface/IfaceType.hs’ Specifically, it changed: ``` put_ bh (IfaceLitTy n) = do { putByte bh 30; put_ bh n } ``` to: ``` put_ bh (IfaceLitTy n) = do { putByte bh 7; put_ bh n } ``` However, the ‘get’ definition was left as:

Re: TypeChecker plugins and the TcS monad; given constraints in GHC HEAD

Beyond the changes in Phab:D909, the only thing I'm still using unsafeTcPluginTcM for is newUnique (in order to generate new skolem variables), which could easily be added to the TcPluginM interface as well. Anyone need anything else? No, In my own type-checker plugins I only use

Re: Duplicated typedef trips my gcc over

I cannot build HEAD for the same reason. Same GCC version. On 21 October 2015 at 13:08, Gabor Greif wrote: > Hi all, > > look: > > $ git grep "typedef struct LibDwSession_ " > rts/Libdw.c:typedef struct LibDwSession_ LibDwSession; > rts/Libdw.h:typedef struct LibDwSession_

Fwd: Strictness/demand analysis without worker/wrapper, or, reviving -fmax-worker-args

Forgot to also send to the list > Begin forwarded message: > > From: Christiaan Baaij <christiaan.ba...@gmail.com> > Subject: Re: Strictness/demand analysis without worker/wrapper, or, reviving > -fmax-worker-args > Date: 15 Oct 2015 17:27:21 CEST > To: Simon Peyton J

Strictness/demand analysis without worker/wrapper, or, reviving -fmax-worker-args

Hi, As a GHC API user, I would like to run GHC’s strictness and demand analysis pass, but I don’t want any worker/wrappers. My specific use-case is to generate digital circuits from Haskell code, where I’ve yet to encounter any benefit from worker/wrappers: the generated circuits do not get

Re: Why upper bound version numbers?

Given that I'm the maintainer of the 'clash' package, I wanted to say that the 'clash' package has been deprecated in favour of the 'clash-ghc' package (for some time now, and this is stated on hackage). Sadly, 'clash-ghc' will not compile on ghc 8.0.1 right now either; it only compiles

Re: GHC 8.0.1 status

Given that I was working on at least once package ( https://github.com/goldfirere/singletons/pull/142) which gave panics on GHC8-rc2, couldn't we get at least an GHC8-rc3 before doing an 8.0.1 release in 3 weeks? On 27 February 2016 at 14:57, Ben Gamari wrote: > tl;dr.

How to prevent GHC (API) from breaking large constants into multiple top-level bindings

My situation is the following, given the code: > {-# LANGUAGE GADTs, DataKinds, TypeOperators, KindSignatures #-} > module GConst where > > import GHC.TypeLits > > data Vec :: Nat -> * -> * > where > Nil :: Vec 0 a > Cons :: a -> Vec n a -> Vec (n+1) a > > infixr `Cons` > > c :: Vec 5

Re: How to prevent GHC (API) from breaking large constants into multiple top-level bindings

be a linear-time substitution to undo it? Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Christiaan Baaij | Sent: 24 March 2016 13:39 | To: ghc-devs@haskell.org | Subject: How to prevent GHC (API) from breaking large constants into

Re: Specialization plugin

One small question: what's the difference between adding INLINABLE everywhere, and just compiling with -fexpose-all-unfoldings, https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/using-optimisation.html#ghc-flag--fexpose-all-unfoldings? Is there any reason you couldn't use that flag

Re: GHC API user: How to stop simplifier from turning recursive let-bindings into mutually recursive functions

I've created a ticket for this at: https://ghc.haskell.org/trac/ghc/ticket/13663 On 8 May 2017 at 16:12, Ben Gamari <b...@smart-cactus.org> wrote: > Christiaan Baaij <christiaan.ba...@gmail.com> writes: > > > Hello GHC Devs, > > > Hi! > > > So my questi

GHC API user: How to stop simplifier from turning recursive let-bindings into mutually recursive functions

Hello GHC Devs, First some context: I'm using the GHC API to convert Haskell to digital circuit descriptions (clash compiler). When viewed as a structural description of a circuit, recursive let-bindings can be turned into feedback loops. In general, when viewed as a structural description of a

type-checker plugin API/behaviour change

Hi devs, Currently, type-checker plugins get to tell the solver its progress using a [TcPluginResult]( http://hackage.haskell.org/package/ghc-8.4.1/docs/TcRnTypes.html#t:TcPluginResult ): ``` data TcPluginResult = TcPluginContradiction [Ct] -- ^ The plugin found a contradiction. -- The

Re: Accessing 'Annotations' of modules in external packages

ghc-devs is probably a better location for GHC API questions. Anyhow, you might want to look at some code in the Clash compiler: https://github.com/clash-lang/clash-compiler/blob/6ec3ca426bfaaaddcd3692775c25614bc19482fa/clash-ghc/src-ghc/Clash/GHC/LoadInterfaceFiles.hs#L168-L225 We use that to

Class op rules

Hello, The other day I was experimenting with RULES and got this warning: src/Clash/Sized/Vector.hs:2159:11: warning: [-Winline-rule-shadowing] Rule "map Pack" may never fire because rule "Class op pack" for ‘pack’ might fire first Probable fix: add phase [n] or [~n] to the

Re: Typechecker plugin proposal, ticket #15147

I actually have conflicting needs: 1. ghc-typelits-natnormalise, a solver for type-level Nat equations, would benefits from both unflattened givens and unflattened wanteds! Why unflattened givens? because from `[G] 2*x + a ~ 2*x + b` I can derive `a ~ b` Which I could then use to solve: [W] 3*y +

Re: Class op rules

s bottoming) it gets rewritten to `test1 _ = case fromList' of {}` On Sat, 7 Mar 2020 at 02:56, Dr. ÉRDI Gergő wrote: > As a workaround, can you try this? > https://stackoverflow.com/a/32133083/477476 > > On Fri, Mar 6, 2020, 23:23 Christiaan Baaij > wrote: > >> H

Re: Class op rules

t; > > > I remember Conal raising this before, but I’ve forgotten the resolution. > I’m entirely open to changes here, if someone is willing to do the work, > including checking for consequences. > > > > Simon > > > > *From:* ghc-devs *On Behalf Of *Conal

Re: PSA: type checker plugins to be affected by upcoming changes to GHC

kell.org/ghc/ghc/-/blob/wip/derived-refactor/compiler/GHC/Tc/Types/Constraint.hs#L1678) > is the best I can offer, though it may be out of date. In the final version > of the patch, that Note will naturally be updated. Essentially, the new > plan is just to use Wanteds instead of Deriveds,

Re: PSA: type checker plugins to be affected by upcoming changes to GHC

solution, perhaps consider it for inclusion in the `ghc` package.) This way, we won't have to make the common case of simplifying type families slow, and still provide a straightforward API. On Mon, 30 Nov 2020 at 20:03, Richard Eisenberg wrote: > > > On Nov 30, 2020, at 11:41 AM, Christiaan

Re: Use of forall as a sigil

Reading proposal 281, I would be similarly confused. In point 4 of section 4.1, primary change, it states that type constructors are now allowed in the grammar of patterns; which if I understand correctly is mostly a name-resolving thing. Perhaps I read the proposal too quickly, but I couldn't

Re: PSA: type checker plugins to be affected by upcoming changes to GHC

I always forget what flattening did/does. Is it the thing where it turns a "complex" type family application: F (G y) (H z) ~ a into: G y ~ p H z ~ q F p q ~ a ? If so, then I'm all for removing that. Since I actually wrote/hacked a function that "reverts" that process (for [G]ivens only):

Re: Error message degradation for (<= :: Nat -> Nat -> Constraint) in GHC 9.2+

gt; > Simon > > > > *From:* ghc-devs *On Behalf Of *Christiaan > Baaij > *Sent:* 17 June 2021 10:44 > *To:* ghc-devs > *Subject:* Error message degradation for (<= :: Nat -> Nat -> Constraint) > in GHC 9.2+ > > > > Hi Ghc-Devs, > >

Error message degradation for (<= :: Nat -> Nat -> Constraint) in GHC 9.2+

Hi Ghc-Devs, When upgrading one of our tc plugins https://hackage.haskell.org/package/ghc-typelits-natnormalise to GHC 9.2, one of our tests, repeated here: ``` {-# LANGUAGE DataKinds, TypeFamilies, TypeOperators #-} module TestInEq where import Data.Proxy import GHC.TypeLits proxyInEq :: (a

Re: Rewriting plugins: request for feedback

Hi Sam, Thanks for picking this up, the API looks good so far. I'll try to port our https://hackage.haskell.org/package/ghc-typelits-extra package to the new API. Though first I need to upgrade https://hackage.haskell.org/package/ghc-typelits-natnormalise to the GHC 9.2+ API, which is got

Is there a way to prevent reboxing in W/W (due to OPAQUE pragma proposal)

Hi Ghc-Devs, I believe I've mostly finished the implementation of GHC proposal 0415 [1], the OPAQUE pragma, over at: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5562 The only remaining issue is that I'm unsure whether there's a way to prevent reboxing of worker arguments as witnessed

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

Somewhat off-topic: does GHC no longer use "the rapier"? I thought the InScopeSet was needed to check that we can safely skip on extending the substitution as you go under binders when the binder is not in the InScopeSet (naively you would always have to rename binders, and thus extend the

Re: Writing GHC plugin to modify AST despite failure to type-check

Another option is to use a constraint solver plugin to "tag" the locations with a coercion, and then use a CorePlugin [1] to replace the corresponding cast by a call to liftIO. I've created a constraint solver plugin to tag all the locations here:

Re: Find the ghc binary path from libdir

Calling `ghc --print-lib-dir` is the only way because the `$libdir` is actually provided on the cmdline using the -B flag: https://gitlab.haskell.org/ghc/ghc/-/blob/master/ghc/Main.hs#L110-112 That's why the `ghc` you normally execute is a shell-wrapper around the `ghc` executable applied to a

Re: What changed between GHC 8.8 and 8.10 that could cause this?

Even if MR388 ( https://gitlab.haskell.org/ghc/ghc/-/merge_requests/388 ) is the cause of the issue we're seeing with the API exposed by Clash, I still think MR388 is wrong. My reasoning is the following: In 8.8 and earlier we had: - RTS C-code contains the ground truth of what is linked. The API

Re: What changed between GHC 8.8 and 8.10 that could cause this?

case is > a bug in Clash. > > If you require shared state you should not be using the top level runGhc > wrapper but instead call unGhc yourself (or call setSession yourself). > > There is perhaps a case to be made for a runGhcShared which does this, but > runGhc itself never gu

Re: What changed between GHC 8.8 and 8.10 that could cause this?

setSession $ hsc_env { hsc_dynLinker = shared_linker } > > > Should restore the behavior. You don't need to run inside a single runGhc, > you just need to provide a single hsc_dynLinker. > > That should work. > > Kind Regards, > Tamar > > On Tue, Mar 9, 2021, 11:46 Christ

Re: GHC plugin authors?

Hi Richard, So there's multiple reasons/aspects as to why I haven't responded 1. Sam's question/seeking feedback on changing the return type for constraint solver plugins is something Sam and I discussed at HIW using ICFPs airmeet instance, as in, it was something I suggested. And the TL;DR of

Alpha-equivalence for recursive let-bindings

Hi list, I was looking at the `Eq (DeBruijn CoreExpr)` instance and I noticed that the types of recursive let-bindings aren't checked for alpha-equivalence: https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Core/Map/Expr.hs#L166-174 go (Let (Rec ps1) e1) (Let (Rec ps2) e2)

Re: Alpha-equivalence for recursive let-bindings

microsoft.com will cease to work. Use simon.peytonjo...@gmail.com > instead. (For now, it just forwards to simo...@microsoft.com.) > > > > *From:* ghc-devs *On Behalf Of *Christiaan > Baaij > *Sent:* 07 November 2021 21:08 > *To:* ghc-devs > *Subject:* Alpha-equivalence for r

Re: [clash-language] Avoiding `OtherCon []` unfoldings, restoring definitions from unfoldings

So if I understand correctly, OtherCon is only created here: https://gitlab.haskell.org/ghc/ghc/-/blob/a952dd80d40bf6b67194a44ff71d7bf75957d29e/compiler/GHC/Core/Opt/Simplify.hs#L3071-3077 simplAlt env _ imposs_deflt_cons case_bndr' cont' (Alt DEFAULT bndrs rhs) = assert (null bndrs) $ do