Re: [SPAM] Re: Analyzing Haskell call graph (was: Thread on Discourse - HIE file processing)

Hi Tristan, ⁣I wouldn't do this with Core (cf inlining issue and issue associating what you find with source syntax). I think you should use the output of the renamer instead. Either with a GHC plugin using `renamedResultAction` or just by dumping the renamed AST (fully qualified) with

Re: Performance of small allocations via prim ops

One complication is that currently GHC has no way to know the value of LARGE_OBJECT_THRESHOLD (which is a runtime system macro). Typically to handle this sort of thing we use utils/deriveConstants to generate a Haskell binding mirroring the value of the C declaration. However, as GHC becomes

Re: Almost all tests fail after 08bf28819b

With devel2 only the static libs are built. Hence the RTS linker is used. https://gitlab.haskell.org/ghc/ghc/-/commit/08bf28819b78e740550a73a90eda62cce8d21c#de77f4916e67137b0ad5e12cc6c2704c64313900 made some symbols public (newArena, arenaAlloc, arenaFree) but they weren't added to

Re: Hadrian problem

Hi Simon, Matt should have fixed it with https://gitlab.haskell.org/ghc/ghc/-/merge_requests/8556 Sylvain On 12/07/2022 14:24, Simon Peyton Jones wrote: I'm in a GHC tree, built with Hadrian, I'm getting this red problem.  But compilation has got way past compiling base. why is it

Re: Hadrian

Hi Simon, You have to re-run `./configure` in cases like this. It's because `compiler/ghc.cabal` is generated from `compiler/ghc.cabal.in` by `./configure`. This isn't tracked by Hadrian. >Surely that should not happen?I'll try make clean; but isn't this a bug? Hopefully when `make` build

Re: What to do with gmp wasm fixes

Hi Cheng, Couldn't the changes be upstreamed into libgmp directly? Other projects may benefit from being able to compile libgmp into wasm. Or are the changes specific to GHC? > - Send a PR to gmp-tarballs, including our patch (doesn't alter behavior on native archs) and the updated tarball

"Modularizing GHC" paper

Hi GHC devs, With John Ericson and Jeffrey Young we wrote a paper about the modularization of GHC. It gives a global picture for the refactorings we have been performing (c.f. e.g. #17957) and some potential future ones. Announce blog post:

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

The unfolding is present if you add `-fno-omit-interface-pragmas` and dump with `-ddump-simpl`. CorePrep drops unfoldings, see Note [Drop unfoldings and rules] in GHC.CoreToStg.Prep. The logic for unfolding exposition by Tidy is now in:

Re: Coping with multiple meanings of `<>`

Hi Norman, Usually in the compiler Semigoup's <> is imported qualified. But I agree it's ugly. The trouble with Outputable's <> is that: 1) it doesn't have the same associativity as Semigroup's <> 2) <+> interacts weirdly with <> (cf

Re: Compiling "primitive" with ghc head

Hi, We now always use Word64# to implement Word64. You can find the patch for primitive and many other packages in head.hackage: https://gitlab.haskell.org/ghc/head.hackage/-/blob/master/patches/primitive-0.7.3.0.patch Cheers, Sylvain ⁣ Le 26 nov. 2021 à 20:35, à 20:35, Harendra Kumar a

Re: -O* does more than what's in optLevelFlags?

Hi, Indeed the optimisation level is directly queried in a few places (e.g. grep "optLevel" and "opt_level"). Especially in Core opt pipeline getCoreToDo returns:     core_todo = if opt_level == 0 then    [ static_ptrs_float_outwards, CoreDoSimplify max_iter

Re: please help with ghc package-db flags

Hi, Could you try with `-package-env -` to disable package environment misfeature. Especially with Asterius as it may mix packages for the host with target packages that use WebAssembly... (I have been bitten by this 2 years ago IIRC). Sylvain On 27/09/2021 22:50, Norman Ramsey wrote:

Re: primitive (byte) string literal with length?

Hi, You can use cstringLength# which has a constant-folding rules for literals. That's what we use in GHC to build FastString literals. ⁣ Le 24 août 2021 à 06:34, à 06:34, Viktor Dukhovni a écrit: > >Is there any GHC syntax for constructing a primitive string literal >with a known (not hand

Re: Fwd: GHC Module change database

> Having a 'single source of truth' database will help with this. Don't hesitate to make a PR to https://gitlab.haskell.org/haskell/ghc-api-compat so that at least the DB and the .cabal files live in the same repo. I have created this package but I don't use it so anyone should really feel

Re: Where else do I need to register fixity declarations?

> What am I doing wrong? Is filling the `mi_fixities` field of the `ModIface` not enough to let importers see the correct fixities? It seems like the renamer is looking for the fixities via `mi_fix_fn (mi_final_exts iface)`, not `mi_fixities`. You should try to replace:   , mi_final_exts =

Re: Loading a typechecked module and then using it immediately as a package

Hi, This part of the API is still awful and a bit in flux to make it less so. Modifying the UnitState directly isn't currently supported and seems difficult to do correctly (e.g. in your code snippet below you don't modify the moduleNameProvidersMap field), so it would probably be better to

GHC releases and versions

Hi devs, We currently have 4 branches of GHC in flight: 8.10, 9.0, 9.2 and HEAD Latest releases: - 8.10.4: 2021/02/06 - 9.0.1: 2021/02/04 - 9.2.1-alpha2: 2021/04/23 Considering: 1) 8.10 branch should be stable but a lot of stuff has been merged for 8.10.5. To the point that 8.10.5 should

Re: Errors in haddock git fetch

error: cannot lock ref 'refs/remotes/origin/wip/hsyl20/dynflags': 'refs/remotes/origin/wip/hsyl20/dynflags/exception' exists; cannot create 'refs/remotes/origin/wip/hsyl20/dynflags' This one is because I've removed some of my wip branches already merged upstream. Their names were conflicting

Generalising KnowNat/Char/Symbol?

Hi, I would like to have a KnownWord constraint to implement a type-safe efficient sum type. For now [1] I have: data V (vs :: [Type]) = Variant !Word Any where Word is a tag used as an index in the vs list and Any a value (unsafeCoerced to the appropriate type). Instead I would like to

Re: Build failure -- missing dependency? Help!

Thank you! Don’t forget to comment it – especially because it is fake. Done in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5265 Make build system doesn't respect package dependencies, only module dependencies (afaik) Does Hadrian suffer from this malady too? Are the fake imports

Re: Build failure -- missing dependency? Help!

Hi Simon, The issue is that: 1. Make build system doesn't respect package dependencies, only module dependencies (afaik) 2. The build system isn't aware that most modules implicitly depend on GHC.Num.Integer/Natural (to desugar Integer/Natural literals) That's why we have several fake

Re: Pointer-or-Int 63-bit representations for Integer

Hi Chris, It has been considered in the past. There are some traces in the wiki: https://gitlab.haskell.org/ghc/ghc/-/wikis/replacing-gmp-notes >> The suggestion discussed by John Meacham , Lennart Augustsson

Re: Use of forall as a sigil

I don't know if this has been discussed but couldn't we reuse the lambda abstraction syntax for this? That is instead of writing: forall a -> Write: \a -> Sylvain On 03/12/2020 17:21, Vladislav Zavialov wrote: There is no *implicit* universal quantification in that example, but there is an

Perf test viewer

Hello everyone, Since testsuite performance results are stored into Git notes, they are more difficult to visualize. At least with values in .T files we could see the changes over time, but now increase/decrease are only indicated into commit messages (but not necessarily by how much). The

Re: msys woes

Could you share the contents of "missing-win32-tarballs" log file? Thanks, Sylvain On 08/10/2020 16:51, Shayne Fletcher wrote: Hi Phyx, On Thu, Oct 8, 2020 at 9:10 AM Phyx > wrote: > `./configure --enable-tarballs-autodownload` GHC build step on Windows

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

By the time we do CorePrep, the hi files should already have been written. I don't think so. When we generate real code we write the interface after the backend has generated the output object. See Note [Writing interface files] in GHC.Driver.Main Cheers, Sylvain On 17/09/2020 12:17, Cheng

Re: Parser depends on DynFlags, depends on Hooks, depends on TcM, DsM, ...

Hi Sebastian, Last month I tried to make a DynFlags-free parser. The branch is here: https://gitlab.haskell.org/hsyl20/ghc/-/commits/hsyl20/dynflags/parser (doesn't build iirc) 1) The input of the parser is almost DynFlags-free thanks to Alec's patch [1]. On that front, we just have to move

Re: Breakage on master

I can't reproduce the issue. Is it on a specific branch? If it's in a branch with new ASSERTs, you should just have to import GHC.Utils.Panic to fix the issue or is there something else? Sylvain On 19/08/2020 10:24, Simon Peyton Jones via ghc-devs wrote: | Strangely, `./validate --legacy

Re: Using a development snapshot of happy

Hi, For solution b, Happy doesn't have to be a submodule. You can add it to hadrian/stack.yaml if you build with stack. See https://gitlab.haskell.org/ghc/ghc/-/commit/90e0ab7d80d88463df97bc3514fc89d2ab9fcfca where I had to do this.  It may be possible to do the same for Cabal with

Re: [ghc-lib] internal error after removal of integer-simple

Hi, I would think it's more related to the linear types patch given that it added ghc-prim:GHC.Types.One (wired-in). Could you open a ticket with a way to reproduce the failure? Thanks, Sylvain On 19/06/2020 23:55, Shayne Fletcher via ghc-devs wrote: With the recent MR that removes

Re: Receiving type information from environment instead of hardcoding.

FYI ghc-bignum has been merged yesterday. Cheers, Sylvain On 15/06/2020 11:28, Rinat Stryungis wrote: In light of the mentioned patch, I prefer to freeze my activity about the unification of Nat and Natural up to the merging this patch. After that, I am going to rebase my branch and make MR.

Re: Search in GitLab

> Does Google index our repo?  Can I use Google to search it somehow? In google you can type: site:gitlab.haskell.org "<>" Cheers, Sylvain On 15/06/2020 11:48, Simon Peyton Jones via ghc-devs wrote: Does anyone know how to search better in GitLab. Currently I’m using the standard GitLab

Re: keepAlive# primop

//gitlab.haskell.org/ghc/ghc/-/wikis/proposal/with-combinator#option-e-tag-core-case-expression-with-kept-alive-variables [2] https://gitlab.haskell.org/hsyl20/ghc/-/commits/hsyl20-keepalive On 13/04/2020 19:51, Ben Gamari wrote: Ccing ghc-devs@ since this discussion is something of general

Re: 8.12 plans

Hi Ben, ghc-bignum (!2231) is ready to be merged for 8.12. We are just waiting for bytestring/text maintainers to merge 2 simple patches. Thanks, Sylvain On 05/05/2020 20:12, Ben Gamari wrote: Hi everyone, The time is again upon us to start thinking about release planning for the next

Re: Hadrian build with DWARF information doesn't contain as much debug information as I would expect

I wonder how gdb knows which shared objects to load and what addresses to use Perhaps it reads /proc/PID/maps (or /proc/PID/map_files/*)? Cheers, Sylvain On 03/05/2020 09:55, Matthew Pickering wrote: Thanks Adam for the tip about dynamic linking, as always. He was right that the debug

Re: T13456

Simon !2600 doesn't contain the fix introduced by !3121. You should rebase it. Sylvain On 28/04/2020 09:50, Simon Peyton Jones via ghc-devs wrote: Ben I'm still getting framework failures from the testsuite, as below. But now it's not just me: it's CI! See !2600 which is failing in this

Spam projects on gitlab

Hi, I've just noticed these spam projects on our gitlab: - https://gitlab.haskell.org/craigonaldson/lumaslim - https://gitlab.haskell.org/AnthonyMussen/survey-of-evianne-cream - https://gitlab.haskell.org/RobertoHeard/robertoheard -

Re: TcTypeNats

Hi Simon, Not an omission, it will be moved into GHC.Builtin.Types.Literals with the next renaming MR (!3072). It is only imported by PrelInfo and GHC.IfaceToCore Sylvain On 14/04/2020 15:48, Simon Peyton Jones wrote: Sylvain TcTypeNats still exists in compiler/typecheck/ An omission?

Re: Module Renaming: GHC.Core.Op

makes sense. To me anyway. If people reject the renaming your suggestion would still be an improvement over .Op though. Cheers, Andreas Sylvain Henry schrieb am 03.04.2020 um 23:29: Hi Andreas, "Op" stands for "Operation" but it's not very obvious (ironically when I star

Re: Module Renaming: GHC.Core.Op

Hi Andreas, "Op" stands for "Operation" but it's not very obvious (ironically when I started this renaming work one of the motivation was to avoid ambiguous acronyms... failed). The idea was to separate Core types from Core transformations/analyses/passes. I couldn't find something better

Re: stage2 build fails

Which stage 0 compiler are you using? It seems to be <= 8.10 and still has 8038cbd96f4 merged which seems contradictory. Anyway the alternative seems to be redundant from the beginning and should have been removed IMO. I have opened https://gitlab.haskell.org/ghc/ghc/merge_requests/2564 to

Re: Marge bot review link

It seems that we just have to add `add-part-of: true` in marge bot config file according to https://github.com/smarkets/marge-bot Cheers Sylvain On 12/01/2020 10:10, Ben Gamari wrote: It likely is possible. However, I have been a bit reluctant to touch Marge since it is supposed to be a

Re: Question about negative Integers

Alright. Thanks everyone for the convincing answers. I will keep the current behavior and I will document that operations may be slower than could be expected. Cheers, Sylvain On 16/11/2019 12:04, Joachim Breitner wrote: Hi, Am Freitag, den 15.11.2019, 17:04 +0100 schrieb Sylvain Henry

Question about negative Integers

Hi GHC devs, As some of you may know, I am working on fixing several longstanding issues with GHC's big numbers implementation (Integer, Natural). You can read more about it here: https://gitlab.haskell.org/hsyl20/ghc/raw/hsyl20-integer/libraries/ghc-bignum/docs/ghc-bignum.rst To summarize,

Re: How to navigate around the source tree?

of the modules would still clash. If there is some other recommended way to jump to a module then that would also work for me. Matt On Wed, Oct 23, 2019 at 12:08 PM Sylvain Henry wrote: Hi, How do you generate your tags file? It seems to be a shortcoming of the generator to not take into accou

Re: How to navigate around the source tree?

Hi, How do you generate your tags file? It seems to be a shortcoming of the generator to not take into account the location of the definition file. > Perhaps `HsUtils` and `StgUtils` would be appropriate to disambiguate`Hs/Utils` and `StgToCmm/Utils`. We are promoting the module prefixes

Re: ByteArray# as a foreign import argument?

10:32, Sylvain Henry wrote: > But I can't find such a ByteArray type definition in today's common packages. What's the rationale for this piece of code? Doing some archeology they seem to have been removed from ghc/lib/std/PrelArr.lhs in e921b2e307532e0f30eefa88b11a124be592bde4 (1999):  d

Re: ByteArray# as a foreign import argument?

> But I can't find such a ByteArray type definition in today's common packages. What's the rationale for this piece of code? Doing some archeology they seem to have been removed from ghc/lib/std/PrelArr.lhs in e921b2e307532e0f30eefa88b11a124be592bde4 (1999):  data Ix ix => Array ix elt       

Re: GHC's module hierarchy

Hi all, We are back at considering an overhaul of the module structure of GHC. Ticket #13009 [1] is the place where the discussion takes place: this is a call for participation to this discussion! Thanks, Sylvain PS: this work was supposed

Re: GHC 8.10.1 Release Plan

Hi Ben, I think we should complete https://gitlab.haskell.org/ghc/ghc/issues/13009 for 8.10 (to avoid a release with inconsistent module hierarchy and to make backporting easier). Cheers, Sylvain On 18/09/2019 22:07, Ben Gamari wrote: tl;dr. If you have unmerged work that you would like to

Re: Any ways to test a GHC build against large set of packages (including test suites)?

Hi, I've never used stackage-curator but "curator 2.0" [1] seems to generate a stack.yaml file that can be used by Stack to build all the packages of the selected snapshot. As Stack supports installing GHC bindists and Stack 2.0 even supports building and installing GHC from a GIT

Re: CI execution

were also MRs were built twice. I'm not sure there is a way to manually trigger the CI pipeline. If you really want to you could modify the .gitlab-ci.yml file on your branch. If you want your commit to be built you could make a MR? Cheers, Matt On Mon, Apr 8, 2019 at 2:22 PM Sylvain Henry

CI execution

Hi devs, It seems that the CI doesn't check branches in GHC forks on Gitlab anymore. Is is intentional? Is there a way to trigger a CI execution manually on a specific branch? Thanks, Sylvain ___ ghc-devs mailing list ghc-devs@haskell.org

Re: Help with cabal

Hi Simon, Hackage on haskell.org is down: https://www.reddit.com/r/haskell/comments/b99cef/hackage_downtime/ Sylvain On 04/04/2019 11:51, Simon Peyton Jones via ghc-devs wrote: I’m setting up my GHC builds on a new machine, and this time I’m using WSL (windows subsystem for Linux).

Re: Haddock tree spongled

Why don't we just put Haddock into GHC's repository? It was proposed in a previous discussion in February [1] and it would avoid the bad experience of having it as a submodule while keeping it in sync. With the following commands we can keep the whole commit history: In Haddock repo: > mkdir

Re: [Haskell-cafe] Final steps in GHC's Trac-to-GitLab migration

I use it to track tickets and I would also like to see it continued. Sylvain On 06/03/2019 12:33, Ara Adkins wrote: Personally I would like to see it continued, but it may not be worth the work if I’m in a minority here. A potential stopgap would be to ‘watch’ the GHC project on our gitlab

Re: WIP branches

I don't feel the pain from the current mode -- it just seems suboptimal). What is the advantage of having ghc-wip instead of having all devs just have their own forks? Thanks, Richard On Feb 5, 2019, at 11:36 AM, Sylvain Henry wrote: Hi, Every time we fetch the main GHC repository, we get

WIP branches

Hi, Every time we fetch the main GHC repository, we get *a lot* of "wip/*" branches. That's a lot of noise, making the bash completion of "git checkout" pretty useless for instance: > git checkout zsh: do you wish to see all 945 possibilities (329 lines)? Unless I'm missing something, they

Re: GHC | Some refactoring in tcInferApps (!116)

> Thanks.  But none of the pictures arrived, so I can’t interpret what you say. They probably have been filtered by the ML... They can seen with the script here: https://gist.github.com/hsyl20/912b0a5fec9e7c621d8ac82e46b88d93 ___ ghc-devs

Fwd: [commit: ghc] master: Use https links in user-facing startup and error messages (a1c0b70)

Hi Ben, I've just noticed that when you commit a diff from phab (as below), you are assigned both as committer and *author* (see also here https://git.haskell.org/ghc.git/commitdiff/a1c0b70638949a73bbd404c11797f2edf28f5965). Reviewers and subscribers to the phab diff are indicated in the

Re: ghc-prim package-data.mk failed

Hi Simon, IIRC you have to delete "libraries/ghc-prim/configure" which is a left-over after d7fa8695324d6e0c3ea77228f9de93d529afc23e Sylvain On 26/10/2018 13:42, Simon Peyton Jones via ghc-devs wrote: This has started happening when I do ‘sh validate –no-clean’ "inplace/bin/ghc-cabal"

Re: Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms

of patterns. The question is this: Is there a set s in S such that Ps is a superset of s? If yes, then the match is complete. What do we think of this design? Of course, the challenge is in building C, but we'll tackle that next. Richard On Oct 26, 2018, at 5:20 AM, Sylvain Henry <mailto:s

Re: Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms

or me to extol...) I feel I must be missing something here. Thanks, Richard On Oct 25, 2018, at 12:24 PM, Sylvain Henry <mailto:sylv...@haskus.fr>> wrote: > In the case where all the patterns are polymorphic, a user must > provide a type signature but we accept the definition

Re: Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms

In the case where all the patterns are polymorphic, a user must provide a type signature but we accept the definition regardless of the type signature they provide. Currently we can specify the type *constructor* in a COMPLETE pragma: pattern J :: a -> Maybe apattern J a = Just apattern N ::

Type constraint: isOneOf

Hi, Motivating example: I have an open sum type (Variant, or V) which can be used to store values of different types: x,y :: V '[String,Int] x = V "test" y = V @Int 10 f :: V '[String,Int] -> String f = \case    V s        -> "Found string: " ++ s    V (i :: Int)   -> "Found int: " ++

Re: Failure to Build

When something like this fails, I usually do: make maintainer-clean git submodule update --init ./boot ./configure make -j On 31/07/2018 16:34, Ara Adkins wrote: Hey Devs, I'm having trouble building the head of the ghc-8.6 branch (`26a7f850d1`) on my Arch Linux machine. The essence of the

Re: CI builds failing

It should be ok with the following revert: https://git.haskell.org/ghc.git/commitdiff/0e37361392a910ccbbb2719168f4e8d8272b2ae2 On 17/04/2018 02:54, David Feuer wrote: On Monday, April 16, 2018 9:16:37 PM EDT Simon Peyton Jones wrote: I wonder if you are compiling with 8.2.1? It's broken.

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

Hi, You can try with foreign primops, it should be faster than the FFI: In IsDoubleNanPrim.s: .global isDoubleNan_prim isDoubleNan_prim:    xor %rbx,%rbx    ucomisd %xmm1, %xmm1    lahf    testb $68, %ah    jnp .Lout    mov $1, %rbx .Lout:    jmp * (%rbp) In IsDoubleNan.hs: {-# LANGUAGE

Re: Help with build ordering issue

On 26/02/2018 19:19, Ben Gamari wrote: Sylvain Henry <sylv...@haskus.fr> writes: On 25/02/2018 21:30, Ben Gamari wrote: Hmm, I'm afraid that's not particularly illuminating. It would be helpful to see the output from -ddump-if-trace as this will tell you why GHC is trying t

Re: Help with build ordering issue

On 25/02/2018 21:30, Ben Gamari wrote: Hmm, I'm afraid that's not particularly illuminating. It would be helpful to see the output from -ddump-if-trace as this will tell you why GHC is trying to load this interface file. Thanks, it has been helpful. The relevant trace is: Need decl for

Re: Help with build ordering issue

On 20/02/2018 03:25, Ben Gamari wrote: Sylvain Henry <sylv...@haskus.fr> writes: Hi, @Bodigrim is working on a patch (https://phabricator.haskell.org/D4212) to fix #14170. The build fails because of interface file errors: "bad interface file" for GHC.Natural and "fai

Help with build ordering issue

Hi, @Bodigrim is working on a patch (https://phabricator.haskell.org/D4212) to fix #14170. The build fails because of interface file errors: "bad interface file" for GHC.Natural and "failed to load interface" for GHC.Types. I suspect it is a wired-in module build ordering issue but I

Re: pattern signatures

Or maybe "pattern ascription"? "type-ascription" is implied as "ascription" isn't commonly used for something else (AFAIK). Sylvain On 08/01/2018 13:59, Simon Peyton Jones via ghc-devs wrote: I like the idea of distinguishing “signatures” from “annotations”. But then what is currently a

Re: GHC HEAD now needs extra tools to build libffi?

I don't know if it helps, but upgrading my ArchLinux installation yesterday broke my builds because of linker issues with stack. I now have to specify "ghc-build: nopie" in stack.yaml file. (cf https://github.com/commercialhaskell/stack/issues/2712) Could your error be related to PIE too?

Re: New primitive types?

Hi, I also think we should do this but it has a lot of ramifications: contant folding in Core, codegen, TH, etc. Also it will break codes that use primitive types directly, so maybe it's worth a ghc proposal. Sylvain On 01/08/2017 15:37, Michal Terepeta wrote: Hi all, I'm working on

Re: `dump-core` a prettier GHC core viewer

Hi, It would be awesome to have a more clever tool that helps further with these sorts of low level optimizations---at present I find it to be a rather unpleasant task and so avoid it when I can :-) A few weeks ago I worked on a similar tool. I have just uploaded a demo:

Re: Trac to Phabricator (Maniphest) migration prototype

Nice work! Would it be possible to convert comment references too? For instance in http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com/T10547#182793 "comment:21" should be a link to the label #178747 If we do the transfer, we should redirect:

OpenSearch with GHC manual

Hi, Search engines often reference old versions of the GHC user guide. For instance with Google and the request "ghc unboxed tuples" I get the manual for 7.0.3, 5.04.1 and 6.8.2 as first results. With DuckDuckGo I get 6.12.3 and then "latest" versions of the manual. So I have made a custom

Re: 177 unexpected test failures on a new system -- is this yet another linker issue?

ithout any errors. So I can't reproduce it right now. I'll try the patch sometime later today when I have the other laptop with me. Sylvain, do you have any ideas on what difference may be causing this? I'm pasting gcc and ld versions but I'm not sure if they're relevant at all. 2016-11-11 11:55 GM

Re: 177 unexpected test failures on a new system -- is this yet another linker issue?

My bad, in fact we do. Could you try with the attached patch? It shows the failing filename in the archive. On 11/11/2016 17:18, Sylvain Henry wrote: It seems like we don't bypass the special filename "/" (symbol lookup table) in rts/Linker.c https://en.wikipedia.org/wik

Re: Fwd: Reducing boilerplate

remove the last glitch: https://github.com/hsyl20/ViperVM/blob/master/WritingBindings.md Btw, the Vector part is inspired from what you did here: https://github.com/expipiplus1/vulkan/pull/1 (thanks!) Cheers, Sylvain 2016-03-11 16:51 GMT+01:00 Ben Gamari <b...@well-typed.com>: > Sylvain H

Fwd: Reducing boilerplate

do we know that it means [a_ap6 -> X] in class P (and not [a -> X])?) 2) maybe I should go a different way and store only the derived instance methods as we store class default methods? Any insight appreciated! Thanks, Sylvain -- Forwarded message -- From: Sylvain Henry <hsy

RTS linker refactoring

Hi devs, I have made a patch to refactor the RTS linker, especially to drastically reduce its memory usage: https://phabricator.haskell.org/D1470 We need to test it on differrent OS/architectures before it can be merged. Here is the current state: - Linux/x86-64: OK (Harbormaster and I) -

Re: Re: [commit: ghc] ghc-7.10: base: fix #10298 #7695 (25b8478)

Summary: This applies a patch from Reid Barton and Sylvain Henry, which fix a disasterous infinite loop when iconv fails to load locale files, as specified in #10298. The fix is a bit of a hack but should be fine - for the actual reasoning behind it, see `Note [Disaster

Re: [Haskell-cafe] Anonymous FFI calls

Hi, The FFI pages on the wiki are not really in a good shape in my opinion (especially for newcomers). I have started a fresh one here: https://wiki.haskell.org/Foreign_Function_Interface_(FFI) This is just the first draft. I will improve it, probably split it in several pages and merge

Re: [Haskell-cafe] Anonymous FFI calls

2015-02-11 16:18 GMT+01:00 Francesco Mazzoli f...@mazzo.li: Relatedly, if I have some function pointer known at runtime that addresses a C function that takes some arguments, I have no way to invoke it from Haskell, since all FFI imports must be declared at compile-time, and I don't know the