- Glasgow-haskell-users

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

record field names vs. -fwarn-unused-binds
by Evan Laforge 04 Nov '15

04 Nov '15

[ ccing haskell-cafe since while it's a ghc flag, I'll bet most compilers have an equivalent ] I really like -fwarn-unused-binds because it frequently finds bugs where I forgot to call something or use some value. If I put an export list on, it can find dead functions I forgot to delete. However, there's one case where it frequently gives false positives, and that's unused record field names. The problem is that I sometimes use record field names as documentation, but the record itself is internal and small, so I'm comfortable using positional pattern matching to open it (and in fact that can be safer, since then warn-unused-binds will make sure I used all the fields). But GHC sees these as unused functions, so it warns about them. I can work around by putting underscores on field names I haven't used yet, but it's a hassle to go edit them when I want to use them. The warning can be useful if it indicates an unused field, but since fields can also be extracted via the positional syntax it's not reliable. The other use of the warning for dead code or functions you forgot to use doesn't apply to record accessors because they're trivial and compiler generated. So, would it be reasonable to exclude record field accessors from -fwarn-unused-binds? Or is there another way to work around it? I guess GHC doesn't have a "suppress warning" pragma like Java does, but even if we did it wouldn't be much better than changing the name, and more likely to get stale.

3 3

type error formatting
by Evan Laforge 04 Nov '15

04 Nov '15

Here's a typical simple type error from GHC: Derive/Call/India/Pakhawaj.hs:142:62: Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5) In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ I've been having more trouble than usual reading GHC's errors, and I finally spent some time to think about it. The problem is that this new "relevant bindings include" section gets in between the expected and actual types (I still don't like that wording but I've gotten used to it), which is the most critical part, and the location context, which is second most critical. Notice the same effect in the previous sentence :) After I see a type error the next thing I want to see is the where it happened, so I have to skip over the bindings, which can be long and complicated. Then I usually know what to do, and only look into the bindings if something more complicated is going on, like wonky inference. So how about reordering the message: Derive/Call/India/Pakhawaj.hs:142:62: Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5) After this, why not go one step further and set off the various sections visibly to make it easier to scan. The context section can also be really long if it gets an entire do block or record: Derive/Call/India/Pakhawaj.hs:142:62: * Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] * In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ * Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5) Or alternately, taking up a bit more vertical space: Derive/Call/India/Pakhawaj.hs:142:62: Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] ----------------------------- In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ ----------------------------- Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5) Thoughts? It seems simple enough that I could do myself, but of course not without buy-in.

9 15

Fwd: GHC 7.10.2 and 7.8.4 - optimization flags do not force recompilation.
by Mateusz Kłoczko 31 Oct '15

31 Oct '15

Hello I would like to ask one question about optimization flags. For different n, executing ghc --make -On MyCode.hs doesn't force recompilation for both GHC 7.10.2 and 7.8.4. Is this intended behaviour ? Or am I missing something ? Regards, Mateusz Kłoczko

2 1

Core libraries
by Paul van der Walt 16 Oct '15

16 Oct '15

Hello GHC users, For various reasons i'm trying to package something which is compatible with/equivalent to the Haskell Platform. I've been looking at the list posted at [0], and it turns out that GHC 7.10.2 doesn't bundle all the packages that are promised. (Or it's a case of PEBKAC and i apologise!) When i do `ghc-pkg list`, the output under ../package.conf.d provided by GHC notably has the following differences with the website list: $ diff website-list <(ghc-pkg list | ..prettify..) 2a3,4 > binary > bin-package-db 10c12,14 < haddock --- > ghc-prim > haskeline > hoopl 12,13c16 < old-locale < old-time --- > integer-gmp 15a19 > rts 16a21 > terminfo What surprises me is the lack of haddock, old-time and old-locale. Is this intentional, or a glitch on the website? I notice that these "missing" libraries are repeated in the `Additional Platform Libraries' and `Programs and Tools' sections. I guess this means that as a GHC packager, i should add these items separately? I guess what i'm saying is that i believe there is a bug in that list [0], but i'm not sure enough that i understand the situation to report it as such :). Sorry about the verbiage, and kind regards, p. 0. <https://www.haskell.org/platform/contents.html>

1 0

Handling multiple fds with GHC
by Markus Ongyerth 07 Oct '15

07 Oct '15

Hi, the last few days, I tried to get an IO-Event system running with GHC i.e. trigger an IO action when there is data to read from a fd. I looked at a few different implementations, but all of them have some downside. * using select package - This uses the select syscall. select is rather limited (fd cannot be >1024) * using GHC.Event - GHC.Event is broken in 7.10.1 (unless unsafeCoerce and a hacky trick are used) - GHC.Event is GHC internal according to hackage - Both Network libraries I looked at (networking (Network.Socket) and socket (System.Socket)) crash the application with GHC.Event - with 7.8+ I didn't see a way to create your own EventManager, so it only works with -threaded * using forkIO and threadWaitRead for each fd in a loop - needs some kind of custom control structure around it - uses a separate thread for each fd - might become pretty awkward to handle multiple events * using poll package - blocks in a safe foreign call - needs some kind of wrapper >From the above list, GHC.Event isn't usable (for me) right now. It would require some work for my usecase. The select option is usable, but suffers from the same problems as poll + the limitation mentioned, so it is strictly worse. This leaves me with two options: poll and forkIO + blocking. Those are based on two completely different approaches to event handling.. poll can be used in a rather classic event handling system with a main loop that blocks until an event occurs (or a timeout triggers) and handles the event in the loop. forkIO + blocking is closer to registering an action later that should be triggered by an event. My main questions right now are: 1. How bad is it for the (non-threaded) runtime to be blocking in a foreign call most of the time? 2. How significant will the overhead be for the forkIO version? 3. Is there a *good* way to use something like threadWaitRead that allows to wake up on other events as well? 4. Is there a better way to handle multiple fds that may get readable data at any time, in Haskell/with GHC right now? Thanks in advance, Ongy

3 5