- ghc-devs - Haskell.org

Re: Submitting a patch for hsc2hs
by Ryan Scott 04 Nov '16

04 Nov '16

Hi Erik, I'm not sure if the hsc2hs repo [1] has "official" Phabricator integration, but what I did when I submitted a patch to hsc2hs was: 1. Commit your changes 2. Because the hsc2hs repo doesn't have an .arcconfig file, you have to manually point arcanist to the right URL by running: arc diff --conduit-uri=https://phabricator.haskell.org Ryan S. ----- [1] http://git.haskell.org/hsc2hs.git

3 3

Submitting a patch for hsc2hs
by Erik de Castro Lopo 04 Nov '16

04 Nov '16

HI all, How would I go about submitting a patch to hsc2hs? Patch below. Erik >From 446e43994e39c763e2fcc3a3accea3e61c3ce767 Mon Sep 17 00:00:00 2001 From: Erik de Castro Lopo <erikd(a)mega-nerd.com> Date: Fri, 4 Nov 2016 20:08:06 +1100 Subject: [PATCH] Fix type signature of main test function During C compiler feature testing, the `main` function was defined with a parameter list of `(int argc, char *argv [])` but these parameters were not used. This results in compiler warnings when the generated file is compiled with the `-Wextra` warning flag added to the `cc-options` of the cabal file. --- DirectCodegen.hs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/DirectCodegen.hs b/DirectCodegen.hs index 37564ee..2a88784 100644 --- a/DirectCodegen.hs +++ b/DirectCodegen.hs @@ -63,7 +63,7 @@ outputDirect config outName outDir outBase name toks = do outTemplateHeaderCProg (cTemplate config)++ concatMap outFlagHeaderCProg flags++ concatMap outHeaderCProg specials++ - "\nint main (int argc, char *argv [])\n{\n"++ + "\nint main (void)\n{\n"++ outHeaderHs flags (if needsH then Just outHName else Nothing) specials++ outHsLine (SourcePos name 0)++ concatMap outTokenHs toks++ -- 2.10.1 -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

1 0

Building with recent binutils require --no-pie
by Alan & Kim Zimmerman 04 Nov '16

04 Nov '16

Hi all For anyone building on Debian testing or similar and getting linker failures, there is currently a workaround in progress by Ben Gamari that can be used. It is based on first applying D2672, D2673, and D2674 and then configuring with ./configure \ CONF_CC_OPTS_STAGE2=-fno-PIE \ CONF_GCC_LINKER_OPTS_STAGE2=-no-pie \ CONF_LD_LINKER_OPTS_STAGE2=-no-pie \ CONF_CC_OPTS_STAGE0=-no-pie \ CONF_GCC_LINKER_OPTS_STAGE0=-no-pie \ CONF_LD_LINKER_OPTS_STAGE0=-no-pie \ CONF_HC_OPTS_STAGE0=-optl=-no-pie See https://gist.github.com/alanz/570eb6f1c0ae7e989f493f1b69904c28 for a more legible version. Regards Alan

2 2

simple diagrams about GHC development flow
by Takenobu Tani 04 Nov '16

04 Nov '16

Hi cafe, For myself and new contributors, I drew overview diagrams about GHC development flow. GHC development flow http://takenobu-hs.github.io/downloads/ghc_development_flow.pdf https://github.com/takenobu-hs/ghc-development-flow Let's enjoy :) Regards, Takenobu

1 0

Compilation optimisation performance example - HaRe
by Alan & Kim Zimmerman 01 Nov '16

01 Nov '16

At the moment HaRe has -O0 set for the library. Here are some timing differences on my machine with optimisation on and off With normal optimisation, we get $ rm -fr dist-newstyle/ $ cabal new-configure --enable-test $ time cabal new-build real 6m54.778s user 7m3.156s sys 0m4.504s With -O0, the timing for the same commands is real 0m36.427s user 0m41.448s sys 0m2.544s So optimisation slows it down from 36 seconds to 7 minutes. Alan

1 0

Specialization plugin
by Ryan Trinkle 31 Oct '16

31 Oct '16

Hi everyone, I'm trying my hand at writing a GHC plugin to generate specializations for all uses of a particular typeclass, and I've run into some trouble. I'd appreciate it if someone could point me in the right direction! I'm new to GHC development, so I may just be overlooking some simple stuff. The original problem: Reflex's interface is presented as a typeclass, which allows the underlying FRP engine to be selected by instance resolution. Although some programs make use of this (particularly the semantics test suite), most only ever use one implementation. However, since their code is typically written polymorphically, the implementation cannot be inlined and its rewrite rules cannot fire. This means that the typeclass My attempted solutions: * Initially, I wrote a plugin that adds INLINABLE pragmas to everything. This helped; small programs now generally see the inlining/rule-firings I was hoping for. However, in large programs, this does not occur. I'm looking into this, but also trying another approach: * Now, I am attempting to write a plugin that adds a SPECIALIZE pragma to every binding whose type mentions Reflex. The trouble: Since SPECIALIZE pragmas seem to be removed during typechecking (DsBinds.dsSpec), I can't directly add them. I would like to, perhaps, invoke Specialise.specBind; however, I'm not sure how to obtain the necessary instance - as mentioned here <https://github.com/ghc/ghc/blob/c36904d66f30d4386a231ce365a056962a881767/co…>, "only the type checker can conjure [dictionaries] up". Perhaps it's possible to explicitly create that dictionary somewhere and extract it for use during the plugin pass? Thanks, Ryan

4 5

[Help needed] GHC HCAR Submission Contributors
by Ben Gamari 29 Oct '16

29 Oct '16

Hello everyone, Haskell Communities and Activities Report submission season is once again upon us. If you are receiving this message then you have a major contribution listed on the GHC 8.2 status page and therefore should have a corresponding entry in GHC's HCAR submission. I've collected some notes for our submission in the usual place [1]. Please have a look and refine as you see fit. In particular, I'd really like to see some text added by, * Edward Yang: Backpack * Ryan Scott: Deriving strategies, new classes * Simon Marlow: NUMA and schduler changes * Bartosz Nitka: Determinism Thanks for your help! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Status/Oct16

1 1

Dynamic Linking help
by lonetiger＠gmail.com 28 Oct '16

28 Oct '16

Hi *, I’ve been working the past 4 or so months on reviving dynamic linking support for Windows in a way that has the most chance of working. My first patch in the series is up on Phabricator and with this patch dynamic linking work again, but only for the threaded RTS. The reason for this is because the core libraries that get distributed with GHC get compiled with -threaded and shared libraries on Windows can’t have dangling symbols. In any case, I’m at the point now where I need to be able to delay the selection of the runtime library till the final link. E.g. when the exe or dll is made. The problem however is that when linked normally, dependencies are satisfied by the Windows loader, before the program is run. One way I could do this is with Window’s equivalent to SONAME. Unfortunately this only works with SxS Assemblies, and I’ll need Admin rights to be able to register the shared libraries. This is a problem for running tests in the testsuite using the inplace GHC. Typically on Windows the way you would do this is by delay loading the dll. This allows me to write some code on startup and manually load the runtime dll. The Windows loader would then just use the loaded dll. Unfortunately delay loading does not support const extern data. Such as const extern RtsConfig defaultRtsConfig; The RTS/GHC is full of such usage so it won’t be easy to change. Though I’d only have to change those exposed by Rts.h. So I have two options: 1) Replace all const externs with a function call. This would work, but isn’t ideal because it would break if someone in the future adds a new data entry instead of a function. And we have an extra function call everywhere. 2) I could do some hacks on the Windows side, e.g. compile the program to a shared library, embed the shared library inside the exe and on startup after loading the propert rts, load the DLL from (mmapped) memory and run the code. I don’t like either approach and am hoping someone here has a better solution for me. Thanks, Tamar

2 4

Linker reorganization
by Ben Gamari 28 Oct '16

28 Oct '16

Hello RTS people, Today I finally grew frustrated enough with my constant battle with the 7000 line tangle of CPP that is rts/Linker.c to do something about it. The result is D2643 through D2650. In short, I took the file and chopped it into more managable pieces: * linker/PEi386.[ch]: PE loading * linker/MachO.[ch]: MachO loading * linker/Elf.[ch]: ELF loading * linker/CacheFlush.[ch]: Platform-specific icache flushing logic * linker/SymbolExtras.[ch]: Symbol extras support logic * Linker.c: Everything necessary to glue all of the above together * LinkerInternals.h: Declarations shared by the above and declarations for Linker.c For the most part this involved just shuffling code around since there was some rough platform abstraction already in place. In fact, I tried quite hard to avoid performing any more intricate refactoring to keep the scope of the project in check. Consequently, this is only a start and the design is in places a bit awkward; there is still certainly no shortage of work remaining to be done. Regardless, I think this change an improvement over the current state of affairs. One concern that I have is that the RTS's header file structure (where everything is #include'd via Rts.h) doesn't work very well for this particular use, where we have a group of headers specific to a particular subsystem (e.g. linker/*.h). Consequently, these header files currently lack enclosing `extern "C"` blocks (as well as Begin/EndPrivate blocks). It would be easy to add these, but I was curious to hear if others had any better ideas. The refactoring was performed over several small-ish commits, so review shouldn't be so bad. I expect to rebase the LoadArchive.c refactoring performed in D2642 on top of this set once it has been merged. I will also offer to rebase DemiMarie's recent error-handling patch (D2652). I have tested the set on a variety of platforms, * x86-64 Linux * x86-64 Darwin * x86-64 FreeBSD * x86-64 Windows * ARM Linux What do you think? Cheers, - Ben

4 4

setnumcapabilities001 failure
by Ben Gamari 28 Oct '16

28 Oct '16

Hi Simon, It seems that setnumcapabilities001 still occassionally fails, although this time by a different mode: https://phabricator.haskell.org/harbormaster/build/14485/?l=100 Cheers, - Ben

3 8