- ghc-devs - Haskell.org

Request for input on #7253: Top-level bindings in GHCI
by Alex Rozenshteyn 24 Aug '15

24 Aug '15

I'm thinking of working on this ticket ( https://ghc.haskell.org/trac/ghc/ticket/7253) so, as per mpickering's suggestion (https://phabricator.haskell.org/chatlog/channel/3/?at=1353572) I'm emailing the list to solicit input. My first instinct was to treat declarations like "a = 1" in GHCI as equivalent to "let a = 1"; this would be a straightforward matter of parsing. On the other hand, as thoughtpolice comments, let-bound variables are treated subtly differently than top-level bindings, so the proper solution may be more involved. Comments?

3 2

Access to class defaults and derived instances
by David Feuer 24 Aug '15

24 Aug '15

>From time to time, a library lacks an instance for something that I want. For example, I may need to convert data Foo = Bar (Vector Baz) to FishFood, but (to avoid unreasonable dependencies) Vector doesn't have a ToFishFood instance, so I can't just write instance ToFishFood Foo and (using Generic magic) be done with it. Instead, I must write the instance completely by hand, which could be painful. I *could* write an orphan instance, but orphans are evil. What I wish I could do: newtype Vec a = Vec (Vector a) instance ToFishFood a => (newtype Vec) a where -- if needed toFishFood (v :: Vector a) = ... That is, I want to write a super-secret orphan instance for Vector and transfer it to Vec via GND precisely when it is legal to do so. The secret instance could itself be derived (if the constructors are visible) or could make use of default member definitions.

2 2

Releasing resources associated with a RTS worker thread?
by Joe Hendrix 24 Aug '15

24 Aug '15

I am working on FFI bindings to C++ code that associates several memory pools to each thread using the library. When a thread is done using the library, it can call a C function to release the memory pool objects. In the Haskell bindings, I’d like to be able to attach a finalizer that called this cleanup code whenever an RTS OS thread is shutdown. It appeared that the main place that happens is here: https://github.com/ghc/ghc/blob/master/rts/Capability.c#L562-L577 I did not see a way to register a finalizer that is run before the call to shutdownThread. Could this be something worth adding to the RTS? It seems like the most straightforward way would be to add a finalizer list to each task object, and expose a C function for adding callbacks to it. As a fallback, it should be possible to modify the memory pools in the C++ code so that they can be disabled. According to the author of the C++ code, this should have about a 10% slowdown on execution, so it would be nice if I could keep them enabled without a risk of memory leaks. Regards, Joe

1 0

How is this Generic-based instance implementation optimized by GHC?
by Ömer Sinan Ağacan 23 Aug '15

23 Aug '15

Hi all, I'm very confused by an optimization GHC is doing. I have this code: data Tree a = Leaf a | Branch (Tree a) (Tree a) deriving (Generic, Show, NFData) data Tree1 a = Leaf1 a | Branch1 (Tree1 a) (Tree1 a) deriving (Show) instance NFData a => NFData (Tree1 a) where rnf (Leaf1 a) = rnf a rnf (Branch1 t1 t2) = rnf t1 `seq` rnf t2 When I benchmarked rnf calls I realized that they're too close, and I looked at simplifier outputs. I believe these are relevant parts: Rec { Main.$fNFDataTree_$crnf [Occ=LoopBreaker] :: forall a_ab5v. NFData a_ab5v => Tree a_ab5v -> () Main.$fNFDataTree_$crnf = \ (@ a17_ab5v) ($dNFData_ab5w :: NFData a17_ab5v) (eta_B1 :: Tree a17_ab5v) -> case eta_B1 of _ [Occ=Dead] { Leaf g1_aaHO -> ($dNFData_ab5w `cast` (Control.DeepSeq.NTCo:NFData[0] <a17_ab5v>_N :: NFData a17_ab5v ~R# (a17_ab5v -> ()))) g1_aaHO; Branch g1_aaHP g2_aaHQ -> case Main.$fNFDataTree_$crnf @ a17_ab5v $dNFData_ab5w g1_aaHP of _ [Occ=Dead] { () -> Main.$fNFDataTree_$crnf @ a17_ab5v $dNFData_ab5w g2_aaHQ } } end Rec } Rec { Main.$fNFDataTree1_$crnf [Occ=LoopBreaker] :: forall a_abd4. NFData a_abd4 => Tree1 a_abd4 -> () Main.$fNFDataTree1_$crnf = \ (@ a17_abd4) ($dNFData_abd5 :: NFData a17_abd4) (eta_B1 :: Tree1 a17_abd4) -> case eta_B1 of _ [Occ=Dead] { Leaf1 a18_a4tg -> ($dNFData_abd5 `cast` (Control.DeepSeq.NTCo:NFData[0] <a17_abd4>_N :: NFData a17_abd4 ~R# (a17_abd4 -> ()))) a18_a4tg; Branch1 t1_a4th t2_a4ti -> case Main.$fNFDataTree1_$crnf @ a17_abd4 $dNFData_abd5 t1_a4th of _ [Occ=Dead] { () -> Main.$fNFDataTree1_$crnf @ a17_abd4 $dNFData_abd5 t2_a4ti } } end Rec } First one is generated by GHC and second one is hand-written. If you compare, you'll see that they're identical. This looks like some serious magic, because first one is generated from a default method that uses Generic methods and types. Does anyone know how is that possible? Which optimization passes are involved in this? Thanks.

2 2

armv7 "invalid instruction" problem building cabal
by Ben Burdette 21 Aug '15

21 Aug '15

I've been trying to get going with ghc 7.10.2 on armv7 debian, problem is described here: http://stackoverflow.com/questions/32124334/ghc-armv7-binary-cabal-illegal-… thanks for any help! Ben

2 5

Record syntax for pattern synonyms
by Matthew Pickering 21 Aug '15

21 Aug '15

I was looking at implementing #8582 but before I got too far I thought it best to clear up a few design points. A summary can be found below and a more fleshed out version with some examples can be found on the wiki page[1]. My main question is about how best to deal with record updates. Say that Foo is a record pattern synonym then how would we expect the following program to behave? ``` foo a@Foo{..} = a {bar = baz} ``` Then say that `pattern Foo{bar} = Just bar`, how should the following two programs behave? Is this partiality any different to that caused by ordinary use of pattern synonyms? (At least partiality in patterns is warned but how comprehensive is the coverage?) ``` foo :: Maybe a -> Maybe Int foo x = x {bar = 5} -- error as `bar` unique determines that we need Foo bar = Nothing {bar = 5} ``` Abandoning record updates seems to make record syntax for pattern synonyms far less useful and confusing to users. Is this design how others have imagined it? I have cced Gergő who originally implemented the extension and created #8582. Matt ---- Unidirectional patterns * Provide the same ability to match as normal records (RecordWildcards etc) * Provide selector functions Bidirectional patterns * Provide the constructor which can be used as normal record constructors Record Updates - unclear * Generalise update syntax to arbitrary expressions? [1]: https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms#RecordPatternSynonyms

4 6

RE: Building on Windows
by Tamar Christina 21 Aug '15

21 Aug '15

Hmm no that doesn't seem familiar to me. It looks like some Windows style paths are being passed around but don't know why.. Are you running the non-emulating shells? E.g. The MinGW-w64 Win64 Shell bat? ------------------------------ From: Michael Snoyman <michael(a)snoyman.com> Sent: ‎8/‎21/‎2015 8:27 To: Tamar Christina <lonetiger(a)gmail.com> Cc: ghc-devs(a)haskell.org Subject: Re: Building on Windows That worked, and got me much farther. If you don't mind one more newb question, I'm now seeing the following. Any thoughts? ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all /usr/bin/install -c -m 755 utils/hp2ps/dist/build/tmp/hp2ps.exe inplace/bin/hp2ps.exe cp driver/ghc-usage.txt inplace/lib/ghc-usage.txt cp driver/ghci-usage.txt inplace/lib/ghci-usage.txt "inplace/bin/ghc-stage1.exe" -o driver/ghci/dist/build/tmp/ghci.exe -hisuf hi -osuf o -hcsuf hc -static -H32m -O -i -idriver/ghci/. -idriver/ghci/dist/build -idriver/ghci/dist/build/autogen -Idriver/ghci/dist/build -Idriver/ghci/dist/build/autogen -no-user-package-db -rtsopts -odir driver/ghci/dist/build -hidir driver/ghci/dist/build -stubdir driver/ghci/dist/build -static -H32m -O -i -idriver/ghci/. -idriver/ghci/dist/build -idriver/ghci/dist/build/autogen -Idriver/ghci/dist/build -Idriver/ghci/dist/build/autogen -no-user-package-db -rtsopts -no-auto-link-packages -no-hs-main driver/ghci/dist/build/ghci.o driver/ghci/dist/build/../utils/cwrapper.o driver/ghci/dist/build/../utils/getLocation.o driver/ghci/ghci.res Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main. Call hs_init_ghc() from your main() function to set these options. gcc.exe: error: driverghcidistbuildghci.o: No such file or directory gcc.exe: error: driverghcidistbuild..utilscwrapper.o: No such file or directory gcc.exe: error: driverghcidistbuild..utilsgetLocation.o: No such file or directory gcc.exe: error: driverghcighci.res: No such file or directory gcc.exe: error: C:msys64-2tmpghc6528_0ghc_4.o: No such file or directory gcc.exe: error: C:msys64-2tmpghc6528_0ghc_2.o: No such file or directory driver/ghci/ghc.mk:39: recipe for target 'driver/ghci/dist/build/tmp/ghci.exe' failed make[1]: *** [driver/ghci/dist/build/tmp/ghci.exe] Error 1 Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 On Fri, Aug 21, 2015 at 8:18 AM, Michael Snoyman <michael(a)snoyman.com> wrote: > Awesome, thanks for the quick response Tamar. Cloning now. > > On Fri, Aug 21, 2015 at 8:16 AM, Tamar Christina <lonetiger(a)gmail.com> > wrote: > >> Hi Michael, >> >> Those instructions are for the GHC head. For 7.10 and earlier this page >> https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources/Legacy >> should have been updated but it seems it never was.. >> >> To get the tarballs on that version do >> git clone git://git.haskell.org/ghc-tarballs.git >> >> I will update the legacy page later. >> >> Regards, >> Tamar >> ------------------------------ >> From: Michael Snoyman <michael(a)snoyman.com> >> Sent: ‎8/‎21/‎2015 7:06 >> To: ghc-devs(a)haskell.org >> Subject: Building on Windows >> >> I'm trying to test a patch I wrote for Windows builds[1]. I'm following >> the preparation guide[2], but my configure step fails[3] with config.log >> contents[4]. Note that I'm building on the ghc-7.10 branch, not master. Is >> it possible that this would contribute to the unrecognized >> --enable-tarballs-autodownload option, and/or the inability to compile C >> files? >> >> [1] https://phabricator.haskell.org/D1158, handles long linker command >> line arguments >> [2] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows >> [3] http://lpaste.net/139330 >> [4] http://lpaste.net/139331 >> > >

3 4

RE: Building on Windows
by Tamar Christina 21 Aug '15

21 Aug '15

Hi Michael, Those instructions are for the GHC head. For 7.10 and earlier this page https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources/Legacy should have been updated but it seems it never was.. To get the tarballs on that version do git clone git://git.haskell.org/ghc-tarballs.git I will update the legacy page later. Regards, Tamar ------------------------------ From: Michael Snoyman <michael(a)snoyman.com> Sent: ‎8/‎21/‎2015 7:06 To: ghc-devs(a)haskell.org Subject: Building on Windows I'm trying to test a patch I wrote for Windows builds[1]. I'm following the preparation guide[2], but my configure step fails[3] with config.log contents[4]. Note that I'm building on the ghc-7.10 branch, not master. Is it possible that this would contribute to the unrecognized --enable-tarballs-autodownload option, and/or the inability to compile C files? [1] https://phabricator.haskell.org/D1158, handles long linker command line arguments [2] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows [3] http://lpaste.net/139330 [4] http://lpaste.net/139331

2 2

Building on Windows
by Michael Snoyman 21 Aug '15

21 Aug '15

I'm trying to test a patch I wrote for Windows builds[1]. I'm following the preparation guide[2], but my configure step fails[3] with config.log contents[4]. Note that I'm building on the ghc-7.10 branch, not master. Is it possible that this would contribute to the unrecognized --enable-tarballs-autodownload option, and/or the inability to compile C files? [1] https://phabricator.haskell.org/D1158, handles long linker command line arguments [2] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows [3] http://lpaste.net/139330 [4] http://lpaste.net/139331

1 0

Deleting sync-all
by Thomas Miedema 20 Aug '15

20 Aug '15

Hello ghc-devs, I would like to delete the file sync-all <https://ghc.haskell.org/trac/ghc/wiki/Building/SyncAll> from the GHC repository. It should not have been necessary to use it for about a year now. To get the sources <https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources>: git clone --recursive git://git.haskell.org/ghc.git cd ghc git clone git://git.haskell.org/ghc-tarballs.git # Windows only To update an existing tree <https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#Upd…>: git pull --rebase git submodule update --init To update an existing tree <https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#git…>, without the possibility to forget to run `git submodule update --init`: git config --global alias.pullall '!f(){ git pull --ff-only "$@" && git submodule update --init --recursive; }; f' # Run once git pullall --rebase Please speak up if you want those 1000 lines of buggy Perl a.k.a. sync-all to stay for some reason, or if you have questions about a certain git submodules workflow. The source code (./boot no longer suggests it) and the wiki are already sync-all free, except for a few historical pages. Discussion period: 1 month. Thomas

3 5