- ghc-devs - Haskell.org

[PATCH] Haddockify some comments in compiler/hsSyn/HsBinds.lhs
by Mateusz Kowalczyk 13 Jul '13

13 Jul '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have turned some comments in compiler/hsSyn/HsBinds.lhs into Haddock format. They were just sitting there, hidden from the world (to spite anyone scratching their heads when looking through the generated docs, like myself). They were already written so why not use them? See attachment. I trust that they're right but I cannot guarantee it. - -- Mateusz K. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRsQ3TAAoJEM1mucMq2pqX9lQP/Al86/rfrr+Q6yLf8HtudIeT +vBDu/r4wClZmNzKKxrtgECELl5UoRX33EUdY2ydHAh0VyPFQZwK1G2Xzktg6zjS 8DSvPhHWDvlces3EWdQOyScwMG+jm+/ezdhU7LVQjCEPvfSQ21csIrDkdRgGH918 qD6wThZ7lZMfccJkkFxya8MIN9XJxQCW65XGUobVgpY5OyQTmy5Dj5teYz+GW/7O VWUUDyNQP6OtlmefhdvHEjrq88Gl+YylAa6x4B27mavRxmdV2gzMxcApfcwj5vkD 1T8+Azl8zpAOwOLa02is7yb0gsuIo/naropcicSeyz67S+Bivp/XO/Z66n6BEAhW iIr+fCTJeArU2NZ5erT/Awkcw9yam8hD3/3wJgaME07Q6Qmfd0l1NoXm4u/6M/Hr yLFhinnRBe/NiENf9wxWzSCky/lkvZjmWcchxPYFN1ZtmOKnP07S1YnjKZ+XEwwW X72XIMAbKzUkhm615UkV//Z09ueTEXpHvA7JRiCVpCivpHX8mXWwe5Su5tlrvL6t /DO2uUawD9OcPpSgarqI1/j+JmWmDq0/ayGI2Wj5PQmp5gFZS8EfYANYXDOCa4nx bZh32ZIgh+agoMvo/XqhRdO0oj/rTd9V3mrh3Na1Yu0KcC3uRwkiBfj0S0C/Wb92 bjxukm7b56XtazyUk2BX =0okt -----END PGP SIGNATURE-----

2 2

package installation woes with Template Haskell / dynamic libraries
by Richard Eisenberg 13 Jul '13

13 Jul '13

Hi all, --- tl;dr: cabal fails to install a package where one module in the package uses another module via Template Haskell, requiring a .dyn_o file. The compilation order, though, makes .o files before .dyn_o files, so installation fails. Is this my fault or cabal's? --- I've built and installed HEAD (as of Apr 8), on Mac OS 10.8.2, without specifying a build.mk file (i.e., using the defaults). I then tried to install the singletons package. This package has multiple modules, one of which uses another in some Template Haskell code. The TH code also uses the syb and mtl packages. - A simple `cabal install singletons` fails when compiling the module that uses TH, because there are no .dylib files for the syb or mtl libraries. I add 'shared: True' to my ~/.cabal/config file, "dangerous"ly reinstall mtl and syb and try again. - Now, `cabal install singletons` still fails during compilation, because the TH code looks for Singletons.dyn_o, which doesn't exist. The problem is that the vanilla build happens before the shared build, and TH seems to require the shared build. - I try `cabal install singletons --disable-library-vanilla`, and everything compiles, but then I get this: Installing library in /Users/rae/Library/Haskell/ghc-7.7.20130407/lib/singletons-0.8.5/lib cabal: dist/build/HSsingletons-0.8.5.o: does not exist - In the hopes that cabal kept the .dyn_o files around, I try regular `cabal install singletons`, but cabal seems to have discarded the .dyn_o files and I get the same error as before. - So, I `cabal unpack singletons`, go into the singletons folder, and run `cabal install --disable-library-vanilla`, and get the installation error as before. But, the compile worked and the .dyn_o files are kept! So, a final `cabal install` now works. Phew. I have a relatively weak understanding of cabal. My question is: Is the problem I've run into here based on local settings that need to be fixed? Is there a moving part somewhere that needs to be upgraded? Or, is this a real bug somewhere? If the problem isn't local, I see three separate bugs here: 1) I had to "dangerous"ly reinstall mtl and syb to get the shared libraries after updating my ~/.cabal/config. I think it should be possible to augment an existing package installation with a new "way" without reinstalling. 2) If a package uses TH and depends on another package, and if TH requires dynamic linking, cabal should automatically install dynamic versions of the library, overriding settings in ~/.cabal/config. Or, if overriding settings is a no-no, it should give a stern warning. It would make sense if this dependency were required to be stated in the package's .cabal file. 3) If a package uses TH and depends on itself, similar logic should apply (requiring a dynamic build), and the order of compilation should be fixed. I can understand (but, without more knowledge, would disagree with) an argument discarding 1) and 2) as natural consequences of a silly user, but 3) -- especially the compilation order -- seems more fundamental. I don't know of a way of installing singletons now without unpacking it and dancing around this problem. What do you think? Are these bugs? Am I a silly user? Or both? Thanks! Richard

2 1

foreign import from RTS into GHC source
by Nicolas Frisby 13 Jul '13

13 Jul '13

I'm adding a foreign import in a GHC module from the RTS. I'm using a CPP directive to avoid the import in the stage1 compiler, since the RTS function I need doesn't necessarily exist in that version of the RTS. > #if STAGE < 2 > … -- make do without the import > #else > … -- do the import and use it > #endif Do you have any criticism of this overall design? EG Is there a preference to use Config.cStage instead of CPP and the STAGE symbol? Thanks. P.S. — for some context, this is for Solution 1 at http://ghc.haskell.org/trac/ghc/wiki/Plugins/ReinitializeGlobals

2 1

Cannot log into darcs.haskell.org
by Edward Z. Yang 13 Jul '13

13 Jul '13

Is anyone else seeing this? It seems to just be rejecting my SSH key. Edward

1 0

How accessible is a dynamically-linked ghc?
by Nicolas Frisby 12 Jul '13

12 Jul '13

1) How much effort does it take for a user to install a dynamically-linked ghc executable on Tier 1 platforms? Just download the source and set DYNAMIC_GHC_PROGRAMS=YES? 2) Are the major GHC distributors planning on distributing dynamically-linked ghc by default? GHC HQ, Haskell Platform, http://www.haskell.org/ghc/distribution_packages? Bonus question: 3) How many platforms support Core plugins but not a dynamically linked ghc? I'm hoping the answer is "zero". The availability of a dynamically-linked ghc looks good, according to the wiki pages I found. It's not so clear to me regarding support on Windows. Thank you for your time. P.S. — Here's the wiki pages I read. Their up-to-dateness is not clear to me. Please let me know if you see that I missed something. === Core plugins http://ghc.haskell.org/trac/ghc/wiki/NewPlugins — nub is 2 years old === building and using shared libraries (aka "dynamic libraries") http://ghc.haskell.org/trac/ghc/wiki/Platforms — very much alive and useful http://ghc.haskell.org/trac/ghc/wiki/Status/May13#Dynamiclinking — summarizes GHCI behavior http://ghc.haskell.org/trac/ghc/wiki/SharedLibraries/PlatformSupport — 4 years old http://ghc.haskell.org/trac/ghc/ticket/5620 — good info in comments; 1.5 years old === default behavior of an entire GHC installation http://ghc.haskell.org/trac/ghc/wiki/DynamicByDefault — 8 months old especially http://ghc.haskell.org/trac/ghc/wiki/DynamicByDefault#Windows

4 5

Some more questions about Cmm pipeline
by Jan Stolarek 12 Jul '13

12 Jul '13

Hi Simon, I have two questions about the Cmm pipeline: 1. I implemented a pass that replaces tail calls with a copy of the entry block we're calling to. This is slightly extended version of loopification which will hopefully enable further optimisations. Then I noticed that loopification pass used to be implemented (cmm/CmmOpt.hs, line 418) but was commented out (d92bd17ffd8715f77fd49de0fed6e39c8d0ec28b). There's also a comment: "XXX: revisit if we actually want to do this". What was the motivation for removing loopification? Is there a reason why we might not want to do it? 2. There is a module cmm/CmmRewriteAssignments.hs, which is not used at the moment. What was the motivation for disabling that pass? Janek

3 6

use UniqSupply in FastString?
by Nicolas Frisby 11 Jul '13

11 Jul '13

Does it sound reasonable to change the FastString module to use a UniqSupply instead of using that Int for generating uniques? I've been trying to let a statically-linked compiler shares its FastString table with plugins. Status, background info, options here: http://hackage.haskell.org/trac/ghc/wiki/Plugins/ReinitializeGlobals (I got a little ahead of myself with Option 2…) Uniques for FastStrings are currently allocated linearly using a global Int variable. Because unsafePerformIO is used, it's difficult to keep the two global Ints in synch (one for the compiler, the other for the plugins). The danger is that the compiler and a plugin might allocate the same unique for distinct FastStrings — that'd break a major invariant. If we used UniqSupply, we'd avoid that danger, just about for free. I'm not sure how robust/speedy UniqSupply is though. Considering its widespread use, I figured it'd be good enough by a pretty wide margin; FastString *creation* seems relatively infrequent. Thanks for your input.

4 8

Feature Request : Qualified module exports
by Erik de Castro Lopo 10 Jul '13

10 Jul '13

Hi all, I've added a feature request ticket to the GHC trac: http://ghc.haskell.org/trac/ghc/ticket/8043 for qualified module exports. In a nutshell this would allow the following 'qualified module' export eg: module MyModule ( qualified module T ) import qualified Data.Text as T so that any module which imports MyModule has access to the symbols of Data.Text under the quaified module name T. This feature actually looks like something which I'm capable of undertaking so if nobody thinks this is a really bad idea, I'll have a crack at this. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

6 7

adding avx register support to x86_32 as well as x86_64?
by Carter Schonwald 09 Jul '13

09 Jul '13

Hey All, Is there any reasons *not* to add SSE / AVX register support to the llvm 32 bit x86 ghc calling convention? It looks like (as with x86_64) that adding additional simd registers to the calling convention would be fully backwards compatible with current ghc approach to 32bit function calls, but would allow ghc 32bit (at some future point) to have decent floating point performance when applicable. I'm ok either way, but would be helpful to get some opinions. just to recap, i'm working on getting a patch sorted out for adding AVX support to the ghc x86_64 LLVM calling convention http://ghc.haskell.org/trac/ghc/ticket/8033, and now would be a good time to add anything to the 32bit x86 calling convention thanks -Carter

2 2

Any interest in moving GHC issues / wiki to github?
by Bryan O'Sullivan 06 Jul '13

06 Jul '13

We have a repeated problem with the GHC wiki and issue tracker getting filled with spam, and the server is currently taking about a minute to respond to each attempt to load a web page. I wonder if anyone would be open to us migrating the content to github instead. (Actually, while I'm at it, cloning from github is much faster than from darcs.haskell.org, but that's a fight for another day.)

5 4