- Glasgow-haskell-users

Fwd: how to get ghci to load compiled modules in 7.8?
by Evan Laforge 14 Jul '14

14 Jul '14

I sent this to haskell-cafe, but there was no response. On stackoverflow there was no response either. I'm trying one last time, but adding ghc-users (which I should have done at the beginning!). Surely it can't be that no one knows how to load modules in ghci? I know a lot of work was done to enable this, as in https://ghc.haskell.org/trac/ghc/wiki/DynamicByDefault, it seems a waste if no one actually knows how to use it! The 7.8.1 release notes make reference to -dynamic-too, and an unexplained "Dynamic Ghci", but implies ghci should just work. Do I need to compile ghci myself in a dynamic way? The DynamicByDefault page also implies that, but I assumed the binary distributions would come with it compiled the right way. This has almost disabled ghci for my work (it can be used, but very slowly and with much retyping of commands, and I find myself avoiding the REPL now), so it's a big regression from 7.6! I added another paragraph from the stackoverflow question. Also, I can't get this to work on linux either, not just OS X. BTW, I got a nice bump in my profiles after upgrading, so 7.8 is mostly good news. Just this one awkward thing keeps it from being all good news. ---------- Forwarded message ---------- I recently upgraded to 7.8.2 and I have a silly question. How do you get ghci to load compiled modules? When I try this: % cat >T.hs module T where x :: Int x = 42 % ghc -c -dynamic-too T.hs % s T.dyn_hi T.dyn_o T.hi T.hs T.o % ghci GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package filepath-1.3.0.2 ... linking ... done. Prelude> :l T [1 of 1] Compiling T ( T.hs, interpreted ) Ok, modules loaded: T. *T> It still loads the file interpreted, even though there is a .dyn_o present. What am I doing wrong? This is on x86-64 OS X. There is one other thing which may be related. Since I load everything interpreted now, I've noticed that the input gets very laggy when I have a hundred or so modules loaded. Also the haskeline state gets confused, e.g. I hit escape k to get the previous line, but then it spontaneously goes back into insert mode again. It stays balky and awkward for about 15 seconds before returning to normal slightly. It's almost as if, after loading all the bytecode, it's still doing tons of work in the background, with constant GC freezes. But what work could it be doing? The bytecode is loaded and I haven't asked it to do anything yet! I don't know if this is new to 7.8, or if it's a result of loading bytecode instead of binary. Update: loading with -fobject-code to force compilation reduces some of the balkiness, but some is still there! So maybe this is a regression from 7.6?

2 5

Re: Installing ghc-7.8.3 OS X bindist fails on Xcode 4 CLI-only machine
by Christiaan Baaij 14 Jul '14

14 Jul '14

Thanks, the work-around did the trick. On 14 July 2014 16:34, Mark Lentczner <mark.lentczner(a)gmail.com> wrote: > Yes - this is a known problem in GHC (#9257 > <https://ghc.haskell.org/trac/ghc/ticket/9257>) > The problem is that there is one gcc invocation in the "make install" step > (!) and that the clang/gcc detection isn't applied at bindist configuire > time. Hence, that gcc invocation is based on the compiler of the machine > that built the bindist (clang), not the compiler of the machine it is being > installed on (gcc). > > Note that this doesn't affect the installed GHC system: The compiler > detection at bindist configure time *is* applied to the ghc tree it > installs, just not the bindist make itself! > > Work around is very easy: > > make install CC_CLANG_BACKEND=0 > > > - Mark > >

1 0

Fwd: Installing ghc-7.8.3 OS X bindist fails on Xcode 4 CLI-only machine
by Brandon Allbery 14 Jul '14

14 Jul '14

FWIW Mark had this reply but is apparently not subscribed to, or being rejected by, ghc-users and asked me to forward it. ---------- Forwarded message ---------- From: Mark Lentczner <mark.lentczner(a)gmail.com> Date: Mon, Jul 14, 2014 at 7:34 AM Subject: Re: Installing ghc-7.8.3 OS X bindist fails on Xcode 4 CLI-only machine To: Christiaan Baaij <christiaan.baaij(a)gmail.com> Cc: glasgow-haskell-users <glasgow-haskell-users(a)haskell.org> Yes - this is a known problem in GHC (#9257 <https://ghc.haskell.org/trac/ghc/ticket/9257>) The problem is that there is one gcc invocation in the "make install" step (!) and that the clang/gcc detection isn't applied at bindist configuire time. Hence, that gcc invocation is based on the compiler of the machine that built the bindist (clang), not the compiler of the machine it is being installed on (gcc). Note that this doesn't affect the installed GHC system: The compiler detection at bindist configure time *is* applied to the ghc tree it installs, just not the bindist make itself! Work around is very easy: make install CC_CLANG_BACKEND=0 - Mark -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

1 0

Installing ghc-7.8.3 OS X bindist fails on Xcode 4 CLI-only machine
by Christiaan Baaij 14 Jul '14

14 Jul '14

Hi, I'm having problems installing the OS X bindist of GHC 7.8.3 on my machine. Here are the specs for my machine: Hardware: MacBook Pro, 13-inch, Mid 2009 Operating System: OS X 10.8.5 gcc: i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) Note that I only have the Xcode 4 CLI tools installed, not Xcode 4 itself. The line that fails is: > /usr/bin/gcc -E -m64 -undef -traditional -Wno-invalid-pp-token -Wno-unicode -Wno-trigraphs -P -DINSTALLING -DLIB_DIR='"/opt/ghc/7.8.3/lib/ghc-7.8.3"' -DINCLUDE_DIR='"/opt/ghc/7.8.3/lib/ghc-7.8.3/include"' -DPAPI_INCLUDE_DIR="" -DPAPI_LIB_DIR="" -DFFI_INCLUDE_DIR= -DFFI_LIB_DIR= '-DFFI_LIB="Cffi"' -x c -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header rts/package.conf.in -o rts/dist/package.conf.install.raw > cc1: error: unrecognized command line option "-Wno-invalid-pp-token" > cc1: error: unrecognized command line option "-Wno-unicode" > make[2]: *** [rts/dist/package.conf.install] Error 1 > make[1]: *** [install] Error 2 > make: *** [install] Error 2 Earlier in the configuration process I see: > checking XCode version... xcode-select: Error: No Xcode is selected. Use xcode-select -switch <path-to-xcode>, or see the xcode-select manpage (man xcode-select) for further information. > not found (too old?) Could that be the culprit? The entire installation log can be found here: https://gist.github.com/christiaanb/ec06e93fa16fdfdb5fa3 -- Christiaan

2 1

ANNOUNCE: GHC version 7.8.3
by Austin Seipp 11 Jul '14

11 Jul '14

============================================================== The (Interactive) Glasgow Haskell Compiler -- version 7.8.3 ============================================================== The GHC Team is pleased to announce a new patchlevel release of GHC, 7.8.3. This is an important bugfix release relative to 7.8.2 (with over 50 defects fixed), so we highly recommend upgrading from the previous 7.8 releases. The full release notes are here: https://www.haskell.org/ghc/docs/7.8.3/html/users_guide/release-7-8-3.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: https://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://ghc.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://ghc.haskell.org/trac/ghc/wiki/Platforms http://ghc.haskell.org/trac/ghc/wiki/CodeOwners Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug Hashes & Signatures ~~~~~~~~~~~~~~~~~ Included in this email is a signed copy of the SHA256 hashes for the tarballs, using my GPG key (keyid 0x3B58D86F). -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

ghc -M
by Christian Maeder 09 Jul '14

09 Jul '14

Hi, using "ghc -M" with ghc-7.8.2 under linux. I got a message: You must specify at least one -dep-suffix (and a failure). http://www.haskell.org/ghc/docs/7.8.1/html/users_guide/separate-compilation… I've stopped using "ghc -M" now, but I think it should be documented better. Maybe dynamic linking complicated matters. Cheers Christian

1 1

ARM64 Task Force
by Luke Iannini 08 Jul '14

08 Jul '14

Howdy all, Would anyone like to team up on getting ARM64 support into GHC? Cheers Luke

1 0

GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
by Luite Stegeman 06 Jul '14

06 Jul '14

hi all, I've added some code [1] [2] to GHCJS to make it run Template Haskell code on node.js, rather than using the GHC linker. GHCJS has supported TH for a long time now, but so far always relied on native (host) code for it. This is the main reason that GHCJS always builds native and JavaScript code for everything (another is that Cabal Setup.hs scripts need to be compiled to some host-runnable form, but that can also be JavaScript if you have node.js) Now besides the compiler having to do twice the work, this has some other disadvantages: - Our JavaScript code has the same dependencies (packages) as native code, which means packages like unix or Win32 show up somewhere, depending on the host environment. This also limits our options in choosing JS-specific packages. - The Template Haskell code runs on the host environment, which might be slightly different from the target, for example in integer size or operating system specific constants. Moreover, building native code made the GHCJS installation procedure more tricky, making end users think about libgmp or libiconv locations, since it basically required the same preparation as building GHC from source. This change will make installing much easier and more reliable (we still have to update the build scripts). How it works is pretty simple: - When any code needs to be run on the target (hscCompileCoreExpr, through the Hooks API new in GHC 7.8), GHCJS starts a node.js process with the thrunner.js [3] script, - GHCJS sends its RTS and the Template Haskell server code [1] to node.js, the script starts a Haskell thread running the server, - for every splice, GHCJS compiles it to JavaScript and links it using its incremental linking functionality. The code for the splice, including dependencies that have not yet been sent to the runner (for earlier splices), is then sent in a RunTH [4] message, - the runner loads and runs the code in the Q monad, can send queries to GHCJS for reification, - the runner sends back the result as a serialized Template Haskell AST (using GHC.Generics for the Binary instances). All Template Haskell functionality is supported, including recent additions for reifying modules and annotations. I still need to clean up and push the patches for the directory and process packages, but after that, the TH code can read/write files, run processes and interact with them and make network connections, all through node.js. Now since this approach is in no way specific to JavaScript, I was wondering if there's any interest in getting this functionality into GHC 7.10 for general cross compilation. The runner would be a native (target) program with dynamic libraries (or object files) being sent over to the target machine (or emulator) for the splices. Thanks to Andras Slemmer from Prezi who helped build the initial proof of concept (without reification) at BudHac. cheers, Luite [1] https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261… [2] https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812… [3] https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261… [4] https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812…

9 16

ghc, tls, gmp
by Joachim Breitner 05 Jul '14

05 Jul '14

Hi, in Debian, we have the (well-known) problem of linking against libraries using libgmp, in this case haskell-curl, which links against libcurl, which links against gnutls, which uses libgmp since the latest release: https://lists.debian.org/debian-haskell/2014/07/msg00000.html Are there any viable solutions to this problem that I might not be aware of? Are there any solutions to be expected in the near future? (My best idea so far is to use libcurl linked against openssl, but this causes licensing issues.) Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata

1 0

GHC and Haskell-Platform on OpenBSD
by Matthias Kilian 04 Jul '14

04 Jul '14

Hi, I'd like to know wether anyone here is using GHC on OpenBSD *and* relying on the Haskell-Platform meta package for OpenBSD. If there's no need for the HP meta package, I could just start to update GHC and all related packages for OpenBSD, but if there are a lot of people who prefer to stick to the HP, I'd to wait until the official update of the HP. So, if you love running pkg_add haskell-platform on OpenBSD, please speak up. And if you don't care an just run pkg_add ghc please speak up too ;-) Ciao, Kili

1 0