- ghc-devs - Haskell.org

process librarry
by Simon Peyton Jones 17 Nov '15

17 Nov '15

Michael My Windows build (sh validate in a clean tree) is still falling over as follows, on Windows. Would it be possible to fix the process library to stop this happening? Thanks Simon libraries\process\System\Process\Internals.hs:106:16: warning: Defined but not used: data constructor `CGid'

2 1

Re: [ANNOUNCE] 7.10.3 release candidate 2 - problems compiling source on Mac OS with clang
by George Colpitts 17 Nov '15

17 Nov '15

I did get compiling from source to work on the Mac. Unfortunately I'm not sure what the problem was. I now see a new problem, not sure if it is a ghc problem or a library problem: cabal install HsOpenSSL ... Building HsOpenSSL-0.11.1.1... Preprocessing library HsOpenSSL-0.11.1.1... In file included from BN.hsc:45: cbits/HsOpenSSL.h:3:10: fatal error: 'openssl/asn1.h' file not found #include <openssl/asn1.h> ^ 1 error generated. compiling dist/build/OpenSSL/BN_hsc_make.c failed (exit code 1) command was: /usr/bin/gcc -c dist/build/OpenSSL/BN_hsc_make.c -o dist/build/OpenSSL/BN_hsc_make.o -m64 -fno-stack-protector -D__GLASGOW_HASKELL__=710 -Ddarwin_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 -Ddarwin_HOST_OS=1 -Dx86_64_HOST_ARCH=1 -Icbits -D PTHREAD -DCALLCONV=ccall -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -I/Users/gcolpitts/Library/Haskell/ghc-7.10.2.20151105-x86_64/lib/network-2.6.2.1/include -I/usr/local/lib/ghc-7.10.2.20151105/unix_KZL8h98IqDM57kQSPo1mKx/include -I/usr/local/lib/ghc-7.10.2.20151105/time_FTheb6LSxyX1UABIbBXRfn/include -I/usr/local/lib/ghc-7.10.2.20151105/bytes_6VWy06pWzJq9evDvK2d4w6/include -I/usr/local/lib/ghc-7.10.2.20151105/base_HQfYBxpPvuw8OunzQu6JGM/include -I/usr/local/lib/ghc-7.10.2.20151105/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I/usr/local/lib/ghc-7.10.2.20151105/include -I/usr/local/lib/ghc-7.10.2.20151105/include/ cabal: Error: some packages failed to install: HsOpenSSL-0.11.1.1 failed during the building phase. The exception was: ExitFailure 1 /usr/bin/gcc --version /usr/bin/gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/c++/4.2.1 Apple LLVM version 7.0.0 (clang-700.1.76) Target: x86_64-apple-darwin15.0.0 Thread model: posix On Mon, Nov 9, 2015 at 10:49 AM, George Colpitts <george.colpitts(a)gmail.com> wrote: > redid with just make rather than make -j5. I get > > > ... > chmod +x libraries/integer-gmp2/gmp/ln > # Their cmd invocation only works on msys. On cygwin it starts > # a cmd interactive shell. The replacement works in both environments. > mv libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh > libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh.orig > sed 's#cmd //c echo "\$1"#cmd /c "echo $1"#' < > libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh.orig > > libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh > cd libraries/integer-gmp2/gmp; (set -o igncr 2>/dev/null) && set -o igncr; > export SHELLOPTS; \ > PATH=`pwd`:$PATH; \ > export PATH; \ > cd gmpbuild && \ > CC=clang NM=/usr/bin/nm AR=/usr/bin/ar ./configure \ > --enable-shared=no \ > --host=x86_64-apple-darwin --build=x86_64-apple-darwin > /bin/sh: SHELLOPTS: readonly variable > checking build system type... /bin/sh: SHELLOPTS: readonly variable > /bin/sh: SHELLOPTS: readonly variable > x86_64-apple-darwin > checking host system type... /bin/sh: SHELLOPTS: readonly variable > /bin/sh: SHELLOPTS: readonly variable > x86_64-apple-darwin > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > /bin/sh: SHELLOPTS: readonly variable > checking for a thread-safe mkdir -p... ./install-sh -c -d > checking for gawk... no > checking for mawk... no > checking for nawk... no > checking for awk... awk > checking whether make sets $(MAKE)... yes > checking whether to enable maintainer-specific portions of Makefiles... no > checking ABI=64 > checking whether clang is gcc... yes > checking compiler clang -O2 -pedantic -fPIC -m64 ... no, gnupro alpha ev6 > char spilling > checking ABI=32 > checking whether clang is gcc... yes > *checking compiler clang -m32 -O2 -pedantic -fPIC -fomit-frame-pointer ... > no, gnupro alpha ev6 char spilling* > *checking compiler clang -O2 -pedantic -fPIC -fomit-frame-pointer ... no, > gnupro alpha ev6 char spilling* > *configure: error: could not find a working compiler, see config.log for > details* > *make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1* > *make: *** [all] Error 2* > > > On Mon, Nov 9, 2015 at 9:32 AM, Ben Gamari <ben(a)smart-cactus.org> wrote: > >> George Colpitts <george.colpitts(a)gmail.com> writes: >> >> > I get >> > >> > make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1 >> > make[1]: *** Waiting for unfinished jobs.... >> >> It looks like the build failed somewhere before this point. Could you >> provide a more complete log? >> >> Cheers, >> >> - Ben >> >> >> >

4 15

mac build for 7.10.3 RC
by Carter Schonwald 15 Nov '15

15 Nov '15

here yah go! this should fix issues with my earlier build http://www.wellposed.com/opensource/ghc/releasebuild-unofficial/ghc-7.10.2.… $ shasum -a512 ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2 6bf9c93e217a148e97884db447cbeb2d9370facecc61d81cf7e47cf1f66ad664046f79e0813117342dcd811fd0e290fa0247a34cbd26c7c577f7159f51f4bbbe ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2 for those who want the check sum

2 1

build system issue: some changes in libraries doesn't trigger required rebuilds
by Ömer Sinan Ağacan 15 Nov '15

15 Nov '15

Hi all, I'm having this annoying issue all the time: Whenever a `git pull origin master` updates a library(one of the submodules, like `Binary`) a `make` doesn't trigger required rebuilds(e.g. it doesn't rebuild libraries and tries to rebuild GHC code). I don't know how to force build libraries, so most of the time I end up doing `make distclean` and wasting 30 minutes. I was wondering if there's a way to force rebuilding libraries? Or can we fix the build system somehow?

2 1

Can't build current HEAD
by Jan Stolarek 14 Nov '15

14 Nov '15

I am unable to build current HEAD. I'm getting a build error in Outputable module: compiler/utils/Outputable.hs:1046:28: Not in scope: type constructor or class ‘CallStack’ compiler/utils/Outputable.hs:1047:23: Not in scope: ‘showCallStack’ The most likely culprit is 80d7ce8038a100f6797a89755c893c6f67f18a30, which added this: #if __GLASGOW_HASKELL__ >= 710 pprSTrace :: (?location :: CallStack) => SDoc -> a -> a pprSTrace = pprTrace (showCallStack ?location) #else pprSTrace :: SDoc -> a -> a pprSTrace = pprTrace "no callstack info" #endif The most interesting thing is that if I change the definition of pprSTrace in the first branch of #if to be identical to the definition in the second branch, then I get warnings that GHC.Stack and GHC.Exception imports are redundant. Any ideas what might be going on here? I'm compiling using GHC 7.10.1. This happens in a clean build tree. Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system.

2 2

Pre-Proposal: Introspective Template Haskell
by Richard Eisenberg 13 Nov '15

13 Nov '15

Hi devs, There's a bunch of open tickets around Template Haskell. A great many of them are attempts to make TH more like what's already in GHC. Of course, when someone improves GHC, then TH also has to be updated. But this doesn't always happen, leading to several of these tickets. I believe I have a solution to the problem: just eliminate Template Haskell and provide direct access to GHC's internal structures. The idea (still very sketchy; hence pre-proposal) is like this (numbered for easy reference, but no order is implied): 1. TH quotes would remain. DsMeta would desugar quotes into Core code that produces HsExprs. For example, [| 1 |] would have type (Q (LHsExpr Name)). (Or perhaps (Q (LHsExpr RdrName)) if that works out better for clients.) 2. TH splices would remain, working much as they do now. The expression inside, say, an expression splice would have type (Q exp) where we can satisfy the constraint (SpliceExpr exp). There would be instances for (SpliceExpr (LHsExpr Name)) and (SpliceExpr (LHsExpr RdrName)) as well as the non-located variants. Generalizing the type of expressions here allows users not to worry about un-renaming when roundtripping between quotes and splices. 3. Reification would remain, using an Info structure much like we have now. Would we expose the real GHC TyCons as the result of reification? Or is it better to give the users HsDecls? This would need to be fleshed out. 4. Lifting would remain, doing the obvious thing. 5. The template-haskell package could even remain, as a backward-compatibility shim. It would declare gobs of pattern synonyms and type synonyms to wrap the new underlying interface. This re-imagined template-haskell package would not need to be a boot library, and could be upgraded separately from GHC. We could even maintain multiple versions of the library so that TH clients wouldn't have to change their code when GHC upgrades. Perhaps someday we could think about deprecating, if that's the way the wind blows. So, the end result is a completely re-engineered TH, but I believe we could keep full backward compatibility. (I have not considered Typed TH in any depth yet. But my hope is that it's not too different from the above.) And, we're left with a significantly lower maintenance burden, especially if we eliminate template-haskell someday. And, tantalizingly, the flexibility in splices might allow us to splice in *Core* code someday. Perhaps we could also reify Core code. Then clients could write their own custom, domain-aware optimizations. Like RULES on steroids. But that's all for the next phase. (Giving due credit, this last bit is inspired by work David Christiansen is doing in Idris.) What's wrong with this idea? I feel like *something* has to be more complicated than I've made it seem! Richard

6 15

On the record pattern synonyms patch
by Edward Z. Yang 13 Nov '15

13 Nov '15

Hello Matthew, I have a question about the record pattern synonyms patch which you landed in the last month (2a74a64e8329ab9e0c74bec47198cb492d25affb). In IfaceSyn, you made the following change: data IfaceIdDetails = IfVanillaId - | IfRecSelId IfaceTyCon Bool + | IfRecSelId (Either IfaceTyCon IfaceDecl) Bool | IfDFunId I don't understand why IfRecSelIds can now store IfaceDecls. Why aren't these declarations stored at the *top level* list of declarations in an interface file? If they are, you shouldn't be storing the entire IfaceDecl structure when serializing to disk. If they are not, I am afraid I don't understand this code. I also noticed that the commit message is quite long, and many of the comments I see are not replicated anywhere in the source. Is there any reason why they should not be written down as proper notes, with cross-references from the appropriate code? Thanks, Edward

2 1

Haskell Platform Plans
by Gershom B 13 Nov '15

13 Nov '15

Dear all, As you know, Mark has passed on the Haskell Platform maintainer hat to me. I wanted to give a heads-up on current plans to keep folks in the loop. This message has three sections, first the 7.10.3 release, next the 8.0 release, and finally some general musings on fiddly details and future plans. 1) 7.10.3 The 7.10.3 release candidates have been out for windows and unix for a bit. As I understand it there is still work underway on the mac build, but that will hopefully be coming shortly. The plan is to release a new platform roughly simultaneously. This platform will work essentially as in the past, for two reasons. First, because it is the last release in the 7.10 series and should be seen like the 7.10.3 compiler as just incorporating some necessary patches rather than any serious changes. Furthermore, the future plans underway rely on a few patches to cabal which have been merged, but are not yet in any existing cabal-install release. A few packages have received minor version bumps, as follows: PACKAGE 7.10.2-a latest ------------------------------------------- case-insensitive 1.2.0.4 1.2.0.5 fgl 5.5.2.0 5.5.2.3 GLUT 2.7.0.1 2.7.0.3 GLURaw 1.5.0.1 1.5.0.2 HUnit 1.2.5.2 1.3.0.0 OpenGL 2.12.0.1 2.13.1.0 OpenGLRaw 2.5.1.0 2.6.0.0 primitive 0.6 0.6.1.0 syb 0.5.1 0.6 scientific 0.3.3.8 0.3.4.2 StateVar 1.1.0.0 1.1.0.1 A few packages were held back due to dependency issues (notably zlib) and additionally, packages shipped with ghc were held back to the versions that will be shipped with 7.10.3. 2) 8.0 We also plan to ship a new platform concurrently with the ghc 8.0 that should be released early next year. That platform will implement some long-discussed and requested changes. First, the platform already ships with msys on windows. However, it does not do so in a way that lets you, as with minGHC, install the network library directly, or for that matter install directly other libraries that use build-type configure. This is because the msys binaries don't get placed into the path, by design. The new platform will ship with a newer cabal, incorporating a patch (pull request #2480) that uses the extra-prog-path setting for build-type: configure. This should allow network and other things reliant on build-type: configure to directly cabal install. The goal for the platform on windows will be that any packages binding to msys libraries _should_ be cabal installable without hassle. If you maintain a library that you think would be a good test-case for this, please drop a line so we can work together towards this goal. Second, the default platform will be _minimal_. That is to say that it will _only_ install into the global package database those packages that are directly shipped with ghc, and not any additional platform packages. "Blessed" platform packages will however still be shipped as a "default user cabal.config" file, so in a setting where users want to work unsandboxed, their versions of platform libs will remain pegged to those chosen by the platform, should they not choose to alter their settings. In a sandboxed setting, or in the presence of a local cabal.config generated by a freeze, those constraints will be disregarded. Furthermore, it is likely but not certain that the "nix-like cabal" or "no-reinstall cabal" will be available for the 8.0 release. If this is the case, users will be able to operate in an unsandboxed environment without conflicts, as multiple instances of the same version of a package, with different dependency choices, will be able to live side-by-side. Third, the platform will ship not only with cabal-install, but also with the stack tool, so that users can choose either workflow, depending on their project or preferences. A number of people have adopted the stack tool, and many beginners have reported success with it as well, so it will be good to provide that functionality out of the box with every platform install. Time and resources permitting we would also like to ship a platform version _with_ the platform libraries prebuilt and included, as that is also a use case that some people continue to like. However, this is a secondary priority, and contingent on us getting our build infrastructure into a good enough shape to make this not too much extra hassle. I'm excited about these changes, and confident we can get their in a timespan that matches the 8.0 release of ghc. 3) Generalities As I mentioned, it would be good to have a more uniform build infrastructure. Generally, I have put out some feelers and am working towards extending the ghc nightly buildbot infrastructure to both cover more platforms and also cover more tools -- not only ghc, but cabal, the platform, perhaps haddock, ghcjs, etc. This way we can get an economy of scale and many of our core tools will be able to all share regular automated builds across many platforms. If you like CI/buildbot systems and would like to help out with this project, please reach out. Also, once we've modernized and fixed up the core platform installer tech, it would be nice to move back to the process of making the platform a good set of blessed libraries -- taking more proposals for additions to it, looking to cull libraries that are no longer widely used, etc. As part of this I intend to move the haskell-platform list off our deprecated community.haskell.org infrastructure and onto mail.haskell.org with our other active lists. Finally, I'm happy to be maintainer of the platform through this period of change and transition, but at some future point, as things get sorted out and the release process becomes more standard and mechanical, I would very much like to pass this responsibility on. I have had some nibbles of offers, but if other people want to begin to get involved, please let me know and we can start to get small contributions from you so that you can become familiar with the various tech and systems involved. The Haskell ecosystem is a team effort, a collective project, and volunteer driven. In my modest experience hacking on the various systems involved (cabal, cabal-install, hackage, the platform build, etc.) some are a bit confusing, but I have always found helpful contributors willing to explain things and review patches, and to help think about and diagnose problems. And none of the code has been as confusing as things I've had to wade through for employment-related purposes :-). So when this stuff doesn't work as well as we'd like, we can investigate together, and then put our heads together and figure out how to improve it together. Furthermore, it can be very satisfying to do so, because the impact of those improvements makes itself widely felt. I look forward to more people joining in! Best, Gershom

1 0

Re: [GHC] #11018: ApiAnnotations: Add SourceText for unicode tokens
by Alan & Kim Zimmerman 12 Nov '15

12 Nov '15

agree, as we discussed on IRC On Thu, Nov 12, 2015 at 9:30 PM, GHC <ghc-devs(a)haskell.org> wrote: > #11018: ApiAnnotations: Add SourceText for unicode tokens > -------------------------------------+------------------------------------- > Reporter: alanz | Owner: alanz > Type: bug | Status: new > Priority: normal | Milestone: 8.0.1 > Component: Compiler | Version: 7.10.2 > Resolution: | Keywords: > | ApiAnnotations > Operating System: Unknown/Multiple | Architecture: > | Unknown/Multiple > Type of failure: None/Unknown | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > -------------------------------------+------------------------------------- > > Comment (by mpickering): > > No. Go for it. > > For the purpose of this ticket, I will also add that I think adding a flag > `IsUnicodeSyntax` is better than adding `SourceText`. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11018#comment:2> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

Questions on the RTS C API regarding threads and tasks
by Nicola Gigante 12 Nov '15

12 Nov '15

Hi everybody, I’m new on this list, congratulations to everyone for the great work that you’re doing on GHC! I apologize if this is not the right list where to ask the following questions. Please point me to the correct list or IRC channel otherwise. I’m part of a small group of people who is going to work on a project that seems to need low-level handling of haskell threads. I’ve started delving into the ghc runtime API to understand if everything we need is exposed to the world or if we have to modify the runtime itself (which I would avoid if possible). I have a few questions about the functions that the runtime exports to the C world regarding the manipulation of tasks: - Fundamentally, is there a way for a C function called by a foreign call to suspend the haskell thread that called it, to be resumed later when appropriate? I see that the runtime has a concept of “blocking queue”, but I also see that the functions that work on blocking queues are not exported. I can manage a queue of TSOs myself, but then I need a way to put in sleep the task indefinitely up to a wake signal. In other words, can I sleep and awake haskell threads from a C function called by a foreign call? - I see the “suspendThread” and “resumeThread” functions exist in include/rts/Threads.h Are these the functions that I need for the point above? My main concern is that the comments in the source code for suspendThread say that these functions are used in case of a CCall, and put the thread in a specific queue, so they seems to have more specific role than what the name might suggest. - Also, I’m unable to find what a StgRegTable is (which is taken as argument by suspendThread). Thank you in advance for your help, Greetings, Nicola

3 3