- Glasgow-haskell-users

Discovery of source dependencies without --make
by Lars Hupel 14 Dec '15

14 Dec '15

(cross-posted from [haskell-cafe]) Hi, I've got a problem in our – admittedly complex – build process. We're running an automated grading system for student-submitted homework exercises. The compilation proceeds in stages: 1) Compile a library file, marked as trustworthy 2) Compile student submissions using Safe Haskell, able to access a whitelisted set of packages and the previously compiled library files 3) Compile the test suite 4) Link everything together into an executable The invocation is similar to this: ghc -c -outputdir "$OUT" -XTrustworthy Library.hs ghc -c -outputdir "$OUT" -i"$OUT" -XSafe "$SUBMISSION" ghc -c -outputdir "$OUT" -i"$OUT" Test_Suite.hs ghc -outputdir "$OUT" -i"$OUT" -o "$OUT/runner" The second stage works well under the assumption that there's just one single submitted file. If there's more than one, I need to specify them in topological order wrt their module dependencies. Consider two simple modules: A.hs > module A where > > import B > import Library B.hs > module B where Invoking GHC with "A.hs" "B.hs" will fail: A.hs:3:1: Failed to load interface for ‘B’ My naive attempt at solving that problem was to just insert "--make" into the compiler flags. No luck, because according to [1, §4.7.3], "--make" will only look at source files and will ignore the "Library.hi" file from the previous compilation stage. If I give the path to "Library.hs" as well, GHC insists on recompiling it with changed flags ("-XSafe" instead of "-XTrustworthy"). Reading a bit further, I discovered the '-M' flag, however, not only does it output Makefile-formatted output, it also ignores .hi files. Is there any way to get the dependency discovery of '--make' without the rest? I know I could probably make it work if I made a package out of the first build stage, but I really want to avoid that in order to not increase the build complexity even further. Cheers Lars [1] <https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/separate-com…>

8 15

Optimization of IORefs and STRefs - comparison to g++
by Mateusz Kłoczko 11 Dec '15

11 Dec '15

Hello! I've performed a few simple tests using Haskell and C++ on primitives. I've compilled all Haskell programs with -O2 optimizations, and C++ ones with -O3 ghc version - 7.10.2, gcc version : 5.1.1 I'm sending the codes in the zip file. *Problem1* - 100 000 000 iterations. Time of execution (in seconds): *Int pure tail recursion*: 6.911011299962411e-2 *Int# pure tail recursion *: 4.587398100011342e-2 *IORef for loop* 1.1533970820000832 *IORef 'tail' recursion* 1.0696569040001123 *STRef for loop* 1.1545546840006864 *STRef tail recursion* 1.1110019479992843 *C++ *: 2.7e-07 The llvm version could be as fast as C++ one in this problem. Buuut... then there's *problem 2* (using if or case) - 100 000 000 iterations: *Int# tail recursion* 1.315346227000191 *IORef for loop*: 2.6442542390004746 *STRef for loop*: 2.669217500999366 *C++*: 0.158056 Here haskell is about 9 times slower than C++. *Problem 4* - executing the same functionality using bit operations - 100 000 000 iterations: *Int# tail recursion:* 0.12361123500068061 *C++:* 0.131141 So, Haskell here is as fast as C++. My question is: can IORefs and STRefs be optimized ? I would like very much to rely on them, but I would like to achieve great speeds. Also, is can one achieve good speeds of execution when using cases or ifs ? If not, what is the other way to do it ? Compiler flags, Cmm optimizations - they are all welcome. And the final question - how hard would it be to implement such optimizations in ghc compiler? Regards, Mateusz Kłoczko

3 2

[ANNOUNCE] Glasgow Haskell Compiler version 7.10.3
by Ben Gamari 10 Dec '15

10 Dec '15

Hello everyone, We are pleased to announce the release of GHC 7.10.3: https://downloads.haskell.org/~ghc/7.10.3/ There can be found source tarballs and binary distributions for 64-bit and 32-bit modern Linux (GMP 5.0 or later), CentOS (GMP 4.0), Windows, and 64-bit Mac OS X platforms. These binaries and tarballs have an accompanying SHA256SUMS file signed by my GPG key id (0x97DB64AD). Significant fixes in release include changes to the simplifier's treatment of rules, the handling of Mac OS X frameworks, and support for response files to work around the restrictive command line length limit on Windows. As always, a full accounting of the changes present in this release can be found in the release notes [1]. The previous release, 7.10.2, was well-behaved save a couple notable bugs; while we have merged a good number of bug fixes in 7.10.3 they were were largely low risk and so we expect that this release should be similiarly stable. A notable exception is the upgrade of the Windows compiler toolchain to GCC 5.2. Typically we would refrain from making such large changes in a point release but Windows users have been long suffering at the hand of the old toolchain (e.g. lack of response file support, #8596, and lack of SEH support). We expect that this change should fix far more than breaks. Unfortunately, due to some oversights in the release process there are two source tarballs for this release. The first, ghc-7.10.3-src.tar.{bz2,xz}, does not include the release notes in the users guide. This is fixed in the second patchlevel release, ghc-7.10.3a-src.tar.{bz2,xz}. It is recommended that users wanting a source release use the ghc-7.10.3a-src tarballs. GHC 7.10.3 will very likely be the last release in the GHC 7 series. In the coming weeks we will be beginning the release process for GHC 8.0, which will include a number of exciting features including the merger of kinds with types, injective type families, imporved DWARF debugging information, applicative-do syntax, a Strict language extension synonyms mechanism, and more. See the GHC 8.0.1 status page for details [2]. Happy compiling! Cheers, - Ben [1] http://downloads.haskell.org/~ghc/7.10.3/docs/html/users_guide//release-7-1… [2] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1

5 5

Re: [Haskell-cafe] [ANNOUNCE] Glasgow Haskell Compiler version 7.10.3
by Ben Gamari 09 Dec '15

09 Dec '15

Ivan Lazar Miljenovic <ivan.miljenovic(a)gmail.com> writes: > On 9 December 2015 at 23:17, Ben Gamari <ben(a)well-typed.com> wrote: >> >> >> [1] http://downloads.haskell.org/~ghc/7.10.3/docs/html/users_guide//release-7-1… > > The links to Trac issues in that page seem to redirect to the same page. > Indeed, I'm trying to work out what went wrong here. I am quite looking forward to being able to drop DocBook in 8.0. Cheers, - Ben

1 0

build ghc without ghci libraries?
by Jeremy 07 Dec '15

07 Dec '15

I'm currently removing *.o after building ghc to save space (I don't need them for what I'm doing). Is there a straightforward way to tell GHC not to build them in the first place, such as --disable-library-for-ghci does for cabal, instead of deleting them after the fact? (I do need ghci support for template haskell.) To clarify, I'm building GHC itself, not using GHC to build a package. -- View this message in context: http://haskell.1045720.n5.nabble.com/build-ghc-without-ghci-libraries-tp582… Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

2 2

Re: [Haskell-beginners] DOOM rewritten in the Haskell programming language.
by Alexander Berntsen 07 Dec '15

07 Dec '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 David, I think it would be more valuable to make a DOOM-like game than to remake DOOM. Especially if you are going to aim for funding. The free software community has had this problem for years, where we point to remakes of old games as evidence to viability. It isn't. Nobody will be swayed by Haskell DOOM. (Although I would, personally, think it interesting.) Good luck with your project. - -- Alexander alexander(a)plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWZWV0AAoJENQqWdRUGk8B0bMQAKu/4hBeS7Iz23IMIatrc5Jd hkWm/bG8FRCtiLyETiH9NtUL5RPtmS+s3+o05h6fZZ1VFFfzucygsmOTw27kWApc ZpZiypv22y7uJsrbyxFgXVp2w6vfp6rrdA+vRSOUp/dmJ+vnn7jVeGUInnlAKX50 WAsEUPx0q4IhGnF/2O3kBuKw/baGvp2kne2IjrgdAJ5qptVEvVoAEpIG3WveTnlP LQMBwTLrB+TkdTIZWTYUT/e8MYZorU5x6LN+GtKuO28PEEG0jS2IgfNeUnzZjalF p37Av84UCiIhTQD3LV6Eq1sQThQMVMm/S+qkqZrNL3I/+TbS3Ztf6q7u7zDRCsnr vum2JR0f9vtGfpd5j3hGVXjQTd0jU3uFdY1kHM0ISGTSKYrOGYs4qsCL/VxPubo8 Lh7YfCltXY+LQkz/Q2FElcd9eM9xYWSOBhPhiudXZ3f+PnkBNRwH03eWk/LHgmhB MByAdf2WCAU4DK7xpJKkCVsyOlsC17t8CtKDIfnt/RkPUr8108i6KOh6zvDR94Du lJyQWuCbL7FFb7uXVO7cKTeWJFejd/K5GrQBTBpVEy3xA15c8Kj+9ALWrdJAlion ktS85eEcp/3IzrNpPby8lhjJvujwzbzny+a9Jdn8ZcybBwpF3+IRSARnb7lJ4Yba Ca972BfXJnFZXiYARfov =mGnp -----END PGP SIGNATURE-----

2 1

Re: [Haskell-cafe] [Haskell-beginners] DOOM rewritten in the Haskell programming language.
by Oliver Charles 07 Dec '15

07 Dec '15

On Sun, Dec 6, 2015 at 5:19 PM Henk-Jan van Tuyl <hjgtuyl(a)chello.nl> wrote: > On Sun, 06 Dec 2015 16:21:15 +0100, David Blubaugh > <davidblubaugh2000(a)yahoo.com> wrote: > > > TO ALL, > > Hello My name is David Allen Blubaugh. I am currently considering > > starting a kick-starter project in redeveloping the DOOM source code > > with the Haskell Programming language using the power of > > functional-oriented programming...... > > I know that John Carmack was interested in the Haskell programming > > language and had even recreated wolfenstein 3D using the Haskell > > programming language. Does anybody have a copy of John Carmack's > > recreation of wolfenstein 3D using haskell ??? Also would anybody enjoy > > working with this project ??? What benefits would DOOM have enjoyed had > > ID software created the DOOM source code in 1993 with Haskell or some > > other functional-oriented programming language instead of C/assembly > > programming languages ??? Thanks, > > David Allen BlubaughElectrical EngineerATR Associate > > I don't know about his source code, but the Games page[0] lists: > - hadoom > A clone of Doom, using reactive-banana, GTK, and the "diagrams" > library. > https://github.com/ocharles/hadoom Possibly worth noting that hadoom is not a source-port of Doom - it's inspired by Doom's approach to level editing (2.5D), but beyond that there isn't much cross over. For example, I use full triangulation for rendering via OpenGL, rather than building my own rendering engine. The level format is also different from WAD. <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe> Ollie

1 0

Segfault when doing hs_init()/hs_exit() multiple times
by Alp Mestanogullari 02 Dec '15

02 Dec '15

Hello everyone, I'm currently calling Haskell code from C. My goal is to apply a Haskell function to each element of some dataset that I get from outside Haskell-land. For now, before I make this fancier and more efficient, the plan is to just bring the RTS up with hs_init, call my Haskell function (exporter to C with 'foreign export ccall [...]') on the element and finally shut the RTS down, doing this for every element. When running this, I realized the RTS was running into a segfault when calling the Haskell function on the second element. This led me to believe it wasn't possible to call hs_init()/hs_exit() multiple times in the same program. But then I checked the Haskell 2010 report, FFI section [1], and it says: *The function hs_init() initialises the Haskell system and provides it with the available command line arguments. Upon return, the arguments solely intended for the Haskell runtime system are removed (i.e., the values that argc and argv point to may have changed). This function must be called during program startup before any Haskell function is invoked; otherwise, the system behaviour is undefined. Conversely, the Haskell system is deinitialised by a call to hs_exit(). Multiple invocations of hs_init() are permitted, provided that they are followed by an equal number of calls to hs_exit() and that the first call to hs_exit() is after the last call to hs_init(). In addition to nested calls to hs_init(), the Haskell system may be de-initialised with hs_exit() and be re-initialised with hs_init() at a later point in time. This ensures that repeated initialisation due to multiple libraries being implemented in Haskell is covered. * Which means, if I understand correctly, that what I want, while very inefficient, should work fine. I've put together a minimal example that exhibits the problem, which can be found at https://github.com/alpmestan/simple-c-export : - https://github.com/alpmestan/simple-c-export/blob/master/run-haskell.c shows the C code that brings the RTS up and down, with some printf statements to show what's going on. - https://github.com/alpmestan/simple-c-export/blob/master/Foo.hs shows the trivial Haskell function I'm exposing. - https://github.com/alpmestan/simple-c-export/blob/master/simple-c-export.ca… contains the build options I'm compiling the code with When running this on my machine (OS X, ghc 7.8.3 and 7.10.2), I always get: $ cabal run simple-c Preprocessing executable 'simple-c' for simple-c-export-0.1... Linking dist/build/simple-c/simple-c ... Running simple-c... #0 - Launching RTS... #0 - RTS started! Calling Haskell function... 0 #0 - Killing RTS now... #0 - RTS killed! #1 - Launching RTS... #1 - RTS started! Calling Haskell function... Segmentation fault: 11 Is there something special I should do to make this work, that I'm overlooking? Or is this a bug (that I should report on Trac, I guess) ? Thanks in advance for any clarification on this. -- Alp Mestanogullari

2 3

ghci - running functions defined in a where clause
by Harendra Kumar 01 Dec '15

01 Dec '15

In ghci, is there a way to address and run functions defined in the where clause of a function? I do not see those functions available in the scope. Is this supported? I can imagine two classes of functions in a where clause. Functions which refer to the bindings in the surrounding scope and those which do not refer to any outside bindings. I guess the latter should be easier to support if we can refer to it or bring it in the current scope somehow. Thanks, harendra

1 0

Running GHC LLVM output through LLVM bitcode linker first
by Clinton Mead 23 Nov '15

23 Nov '15

Is there a way to run the LLVM code (both generated by Haskell and provided by the user) though the LLVM bitcode linker to perform intermodule optimizations (like inlining) http://llvm.org/docs/CommandGuide/llvm-link.html Here's some example code: -- Main.hs -- {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} {-# LANGUAGE GHCForeignImportPrim #-} {-# LANGUAGE ForeignFunctionInterface #-} {-# LANGUAGE UnliftedFFITypes #-} {-# LANGUAGE BangPatterns #-} import GHC.Exts(Word(W#)) import GHC.Prim(Word#) foreign import ccall llvmid :: Word# -> Word# main = do line1 <- getLine let !(W# x1) = read line1 let !r1 = llvminc x1 print (W# r1) -- funcs.ll -- define fastcc i64 @llvminc(i64 inreg %x) { %r = add i64 %x, 1 ret i64 %r } When I compile like the following: ghc -O2 -fllvm -keep-s-files Main.hs funcs.ll I get an executable that performs correctly, but when I look at the assembly output in Main.s I get the following: callq suspendThread movq %rax, %rbp movq %rbx, %rdi callq llvminc movq %rax, %rbx movq %rbp, %rdi callq resumeThread This leads me to believe that this is being done like a c call through registers, but not inlined, though I'm not sure about this. I also suspect sending the "Main.ll" and "funcs.ll" files through the LLVM bitcode linker and then sending the resulting one bitcode to the LLVM compiler would perform these intramodule optimisations. Is there anyway to get GHC to use the LLVM bitcode linker to link all the LLVM files (both user provided and resulting from GHC compilation) though the LLVM bitcode linker first before the system linker?

2 1