Re: ANNOUNCE: GHC version 7.10.2
Hi, On 29 July 2015 at 17:26, Ben Gamari b...@well-typed.com wrote: [...] The full release notes including a complete listing of the changes in this release can be found here, https://downloads.haskell.org/~ghc/7.10.2/docs/html/users_guide/release-7-10-2.html This gives me error 404. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: RFC: Native -XCPP Proposal
On 6 May 2015 at 14:25, Austin Seipp aus...@well-typed.com wrote: 2) The lexing rules for C and Haskell simply are not the same in general. One area where this is irritating is that it makes it impossible to use Haskell multiline strings together with CPP. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - problem with latest cabal-install
Hi, On 1 January 2015 at 19:00, George Colpitts george.colpi...@gmail.com wrote: Thanks, there seems to be dependency issues: Try also adding '--allow-newer=bytestring,deepseq'. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: include a cabal-install executable in future GHC releases
Hi, On 23 February 2014 05:48, Carter Schonwald carter.schonw...@gmail.com wrote: Bump! have we reached any consensus on the different variations of this proposal? a) i seem to recall some of the cabal maintainers expressing interest in hosting binaries for major platforms Austin promised to provide us with build bots for 3/4 of the tier 1 platforms. I assume that he is busy with preparing with the 7.8 release now. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: --split-objs
Hi, On Mon, Jan 20, 2014 at 11:50 AM, Simon Marlow marlo...@gmail.com wrote: There is nothing fundamental about -split-objs that prevents it from working with executables. I expect that GHC doesn't take it into account during its link step when linking an executable with -split-objs, though. That would be a reasonable enhancement - open a ticket? Thanks. Ticket created: https://ghc.haskell.org/trac/ghc/ticket/8685 -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: include a cabal-install executable in future GHC releases
Hi, On Mon, Jan 20, 2014 at 1:02 AM, Carter Schonwald carter.schonw...@gmail.com wrote: point being: It'd be great for haskell usability (and egads amounts of config time, even by seasoned users) the ghc bindists / installers included a cabal-install binary For Windows, we provide a stand-alone cabal.exe on the Cabal site [1]. I guess we could do the same for Linux and OS X. [1] http://www.haskell.org/cabal/download.html -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: include a cabal-install executable in future GHC releases
Hi, On Mon, Jan 20, 2014 at 1:14 AM, Carter Schonwald carter.schonw...@gmail.com wrote: that still requires some discovery though! The idea (i'd hope) would be to make the my first ghc install on a vm (for experts and new folks both) Regardless, I think it should be the Cabal developers' job to provide pre-built cabal-install binaries. The choice of whether or not to ship them with the GHC binary tarballs falls to GHC HQ. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: --split-objs
Hi, The problem in https://github.com/haskell/cabal/issues/1611 is with that we have a module (say, A) from which we're only importing a single value, and this module is a part of the cabal-install source tree. It would be nice if the whole contents of A weren't linked with the final executable. So I tried to compile cabal-install with --split-objs, but apparently this doesn't work because in this case the linker's input is A.o instead of A_split_0.o A_split_1.o ... A_split_N.o. And apparently that's why the documentation says that --split-objs doesn't make sense for executables. Note that if cabal-install was split into an executable and a library, then this would work. So the question is why --split-objs only works for libraries and whether this behaviour can be fixed. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 7.8 Release Update
Hi, On Mon, Sep 9, 2013 at 10:11 PM, Simon Marlow marlo...@gmail.com wrote: I think Kazu is saying that when he builds something with profiling using cabal-install, it fails because cabal-install tries to build a dynamic version too. We don't want dyanmic/profiled libraries (there's no point, you can't load them into GHCi). Perhaps this is something that needs fixing in cabal-install? Aren't they needed when compiling libraries that are using Template Haskell for profiling? The issue sounds like it could be TH-related. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 7.8 Release Update
Hi, On Mon, Sep 9, 2013 at 11:21 PM, Edward Z. Yang ezy...@mit.edu wrote: Hello Mikhail, It is a known issue that Template Haskell does not work with profiling (because GHCi and profiling do not work together, and TH uses GHCi's linker). [1] Actually, with the new linker patches that are landing soon we are not too far off from having this work. Thanks, that clears things up a bit. Kazu (or someone else), can you please file a ticket on the Cabal bug tracker [1] if you think that this a Cabal bug? [1] https://github.com/haskell/cabal/issues/ -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Why is GHC so much worse than JHC when computing the Ackermann function?
Hi all, This came up on StackOverflow [1]. When compiled with GHC (7.4.2 7.6.2), this simple program: main = print $ ack 4 1 where ack :: Int - Int - Int ack 0 n = n+1 ack m 0 = ack (m-1) 1 ack m n = ack (m-1) (ack m (n-1)) consumes all available memory on my machine and slows down to a crawl. However, when compiled with JHC it runs in constant space and is about as fast as the straightforward Ocaml version (see the SO question for benchmark numbers). I was able to fix the space leak by using CPS-conversion, but the CPS-converted version is still about 10 times slower than the naive version compiled with JHC. I looked both at the Core and Cmm, but couldn't find anything obviously wrong with the generated code - 'ack' is compiled to a simple loop of type 'Int# - Int# - Int#'. What's more frustrating is that running the program with +RTS -hc makes the space leak mysteriously vanish. Can someone please explain where the space leak comes from and if it's possible to further improve the runtime of this program with GHC? Apparently it's somehow connected to the stack management strategy, since running the program with a larger stack chunk size (+RTS -kc1M) makes the space leak go away. Interestingly, choosing smaller stack chunk sizes (256K, 512K) causes it to die with an OOM exception: $ time ./Test +RTS -kc256K Test: out of memory (requested 2097152 bytes) [1] http://stackoverflow.com/questions/16115815/ackermann-very-inefficient-with-haskell-ghc/16116074#16116074 -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Why is GHC so much worse than JHC when computing the Ackermann function?
Hi, On Sat, Apr 20, 2013 at 12:08 PM, Christopher Done chrisd...@gmail.com wrote: JHC compiles to C and last time I tried this it looked very much like the original C version: http://www.reddit.com/r/haskell/comments/1bcru7/damn_lies_and_haskell_performance/c9689a3 This is the same thing. Yes, but with the Fibonacci example GHC wasn't consuming all available memory and running 10 times slower. Surely it must be possible to make the GHC version at least 2x as slow as Ocaml/GHC? -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Why is GHC so much worse than JHC when computing the Ackermann function?
On Sat, Apr 20, 2013 at 12:23 PM, Mikhail Glushenkov the.dead.shall.r...@gmail.com wrote: Surely it must be possible to make the GHC version at least 2x as slow as Ocaml/GHC? s|Ocaml/GHC|Ocaml/JHC| -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Why is GHC so much worse than JHC when computing the Ackermann function?
Hi, On 20 April 2013 14:20, Dan Doel dan.d...@gmail.com wrote: There's something strange going on in this example. For instance, setting (-M) heap limits as low as 40K seems to have no effect, even though the program easily uses more than 8G. Apparently the only things it allocates is stack chunks. I managed to produce a version of this program that runs approximately as fast as the Ocaml one by manually unrolling the main loop [1], but it still has to be run with +RTS -kc1M to avoid the memory leak. [1] https://gist.github.com/23Skidoo/5425891 -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Newtype wrappers
Hello, On Mon, Jan 14, 2013 at 8:14 PM, Andrea Vezzosi sanzhi...@gmail.com wrote: Have you considered the effect on types like Data.Set that use the uniqueness of typeclass instances to maintain invariants? e.g. even when we have newtype X = X Y coercing Set X to Set Y can produce a tree with the wrong shape for the Ord instance of Y. But isn't this already possible via GeneralizedNewtypeDeriving? -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Separating build tree from the source tree
Hi Jan, On Sat, Dec 15, 2012 at 4:08 PM, Jan Stolarek jan.stola...@p.lodz.pl wrote: Dear list, I have a GHC source tree in ghc-working. I would like to have a separate build tree in ghc-build, so I did something like this: mkdir ghc-build cd ghc-build lndir ../ghc-working Now, I have two different machines. On openSUSE with git 1.8.0 I get something like this: [killy@xerxes : /dane/uczelnia/projekty/ghc-build] ./configure IIRC, you should run something like ../ghc/configure instead of ./configure. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Where has the special built-in inline function gone?
Hi Johan, On Tue, Nov 13, 2012 at 6:34 PM, Johan Tibell johan.tib...@gmail.com wrote: Hi all, For the first time, I wanted to use the special built-in inline function. To my dismay, I can't find it anywhere! On my system (GHC 7.4.2), it is accessible through GHC.Exts. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Potential GSoC proposal: Reduce the speed gap between 'ghc -c' and 'ghc --make'
Hello Simon, On Wed, Apr 25, 2012 at 9:57 AM, Simon Marlow marlo...@gmail.com wrote: Is this a good idea? How hard it would be to implement this optimisation? [...] Personally I think it's at best very ambitious, and at worst not at all practical. Thanks. I'll look into how to optimise .hi loading by more traditional means, then. I briefly looked at how marshalling is implemented in Ocaml (byterun/intern.c), and it looks like even though the Marshal module is unsafe and saves the data in an opaque format, the deserialisation algorithm is less radical than what I proposed. They go through the input buffer looking at the tag and size of the each object, and copy them to the heap buffer one-by-one. One interesting detail is that the heap buffer is allocated only once, because its size is known in advance. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Potential GSoC proposal: Reduce the speed gap between 'ghc -c' and 'ghc --make'
Hello Simon, Sorry for the delay. On Tue, Apr 10, 2012 at 1:03 PM, Simon Marlow marlo...@gmail.com wrote: Questions: Would implementing this optimisation be a worthwhile/realistic GSoC project? What are other potential ways to bring 'ghc -c' performance up to par with 'ghc --make'? My guess is that this won't have a significant impact on ghc -c compile times. The advantage of squashing the .hi files for a package together is that they could share a string table, which would save a bit of space and time, but I think the time saved is small compared to the cost of deserialising and typechecking the declarations from the interface, which still has to be done. In fact it might make things worse, if the string table for the whole base package is larger than the individual tables that would be read from .hi files. I don't think mmap() will buy very much over the current scheme of just reading the file into a ByteArray. Thank you for the answer. I'll be working on another project during the summer, but I'm still interested in making interface files load faster. The idea that I currently like the most is to make it possible to save and load objects in the GHC heap format. That way, deserialisation could be done with a simple fread() and a fast pointer fixup pass, which would hopefully make running many 'ghc -c' processes as fast as a single 'ghc --make'. This trick is commonly employed in the games industry to speed-up load times [1]. Given that Haskell is a garbage-collected language, the implementation will be trickier than in C++ and will have to be done on the RTS level. Is this a good idea? How hard it would be to implement this optimisation? Another idea (that I like less) is to implement a build server mode for GHC. That way, instead of a single 'ghc --make' we could run several ghc build servers in parallel. However, Evan Laforge's efforts in this direction didn't bring the expected speedup. Perhaps it's possible to improve on his work. [1] http://www.gamasutra.com/view/feature/132376/delicious_data_baking.php?print=1 -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Potential GSoC proposal: Reduce the speed gap between 'ghc -c' and 'ghc --make'
Hi all,
[Hoping it's not too late.]
During my work on parallelising 'ghc --make' [1] I encountered a
stumbling block: running 'ghc --make' can be often much faster than
using separate compile ('ghc -c') and link stages, which means that
any parallel build tool built on top of 'ghc -c' will be significantly
handicapped [2]. As far as I understand, this is mainly due to the
effects of interface file caching - 'ghc --make' only needs to parse
and load them once. One potential improvement (suggested by Duncan
Coutts [3]) is to produce whole-package interface files and load them
in using mmap().
Questions:
Would implementing this optimisation be a worthwhile/realistic GSoC project?
What are other potential ways to bring 'ghc -c' performance up to par
with 'ghc --make'?
[1] https://github.com/23Skidoo/ghc-parmake
[2] https://gist.github.com/1360470
[3]
http://www.reddit.com/r/haskell/comments/qwj5j/the_cabal_of_my_dreams/c41a5gx
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: parallelizing ghc
Hi, On Tue, Jan 24, 2012 at 4:53 AM, Evan Laforge qdun...@gmail.com wrote: [...] So ghc --make provides two things: a dependency chaser and a way to keep the compiler resident as it compiles new files. Since the dependency chaser will never be as powerful as a real build system, it occurs to me that the only reasonable way forward is to split out the second part, by adding an --interactive flag to ghc. It would then read filenames on stdin, compiling each one in turn, only exiting when it sees EOF. There is in fact an '--interactive' flag already, 'ghc --interactive' is a synonym for 'ghci'. So I'm wondering, does this seem reasonable and feasible? Is there a better way to do it? Even if it could be done, would it be worth it? If the answers are yes, maybe not, and maybe yes, then how hard would this be to do and where should I start looking? I'm assuming start at GhcMake.hs and work outwards from there... I'm also interested in a build server mode for ghc. I have written a parallel wrapper for 'ghc --make' [1], but the speed gains are not as impressive [2] as I hoped because of the duplicated work. [1] https://github.com/23Skidoo/ghc-parmake [2] https://gist.github.com/1360470 -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: parallelizing ghc
Hi, On Tue, Jan 24, 2012 at 4:53 AM, Evan Laforge qdun...@gmail.com wrote: So ghc --make provides two things: a dependency chaser and a way to keep the compiler resident as it compiles new files. Since the dependency chaser will never be as powerful as a real build system, it occurs to me that the only reasonable way forward is to split out the second part, by adding an --interactive flag to ghc. It would then read filenames on stdin, compiling each one in turn, only exiting when it sees EOF. Then a separate program, ghc-fe, can wrap ghc and acts like a drop-in replacement for ghc. One immediate problem I see with this is linking - 'ghc --make Main.hs' is able to figure out what packages a program depends on, while 'ghc Main.o ... -o Main' requires the user to specify them manually with -package. So you'll either need to pass this information back to the parent process, or use 'ghc --make' for linking (which adds more overhead). -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: parallelizing ghc
Hi, On Tue, Jan 24, 2012 at 7:04 PM, Evan Laforge qdun...@gmail.com wrote: I'm also interested in a build server mode for ghc. I have written a parallel wrapper for 'ghc --make' [1], but the speed gains are not as impressive [2] as I hoped because of the duplicated work. Was the duplicated work rereading .hi files, or was there something else? I think so - according to the GHC manual, the main speed improvement comes from caching the information between compilations. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
