- Glasgow-haskell-users

online docs for GHC head seem to be stale
by Carter Schonwald 24 Feb '13

24 Feb '13

Hey All, I've been looking around in the documentation online for the current ghc head, and it looks to lack any information on the new SIMD ops. then i noticed the time stamp: http://www.haskell.org/ghc/dist/current/docs/html/libraries/ so those docs are from December? Whats needed to be done to bring those to be more up to date?

1 0

Quasi quoting and global names (for haskell-src-exts-qq)
by L Corbijn 18 Feb '13

18 Feb '13

Hello, In the haskell-src-exts quasi quoter there is some code to convert all names in `dataToQa` to global names. The reasoning is according to the source: -- | The generic functions in 'Language.Haskell.TH.Quote' don't use global -- names for syntax constructors. This has the unfortunate effect of breaking -- quotation when the haskell-src-exts syntax module is imported qualified. -- The solution is to set the flavour of all names to 'NameG'. qualify :: Name -> Name -- Need special cases for constructors used in string literals. Assume nearly -- all else is a datatype defined in Syntax module of haskell-src-exts. qualify n | ":" <- nameBase n = '(:) {- snip: quite some excluded constructors -} | otherwise = Name (mkOccName (nameBase n)) flavour {- snip: some code for the flavour -} For the full source code see [1]. When fixing the pattern quasi quoter this qualification caused a long error (when using the quasi quoter). So in a simple attempt to fix it I replaced `qualify` with `id` and it all worked. Now assuming that the qualification code was needed for some past version of GHC I would like to make the implementation dependent on the version of GHC. The only problem is that I haven't found the right version of GHC where this behaviour changed. Does somebody know at what version it was needed? Greetings, Lars Corbijn [1] http://hackage.haskell.org/package/haskell-src-exts-qq-0.6.1

2 1

Building the GHC library without building GHC
by C Rodrigues 15 Feb '13

15 Feb '13

Hi, I was going to do some hacking on Haddock. Haddock depends on the GHC API from the development version of GHC, however, stage2 crashes on my system when I try to build the newest GHC from the repository. Since I don't actually need to compile with the new GHC, I'm hoping there's a workaround. Is there a way to build only the GHC library so that I can get back to Haddock?

2 1

How to compile ghc 7.6.2 with llvm?
by Magicloud Magiclouds 13 Feb '13

13 Feb '13

Hi, I am using Linuxmint Nadia with clang and llvm-3.0 installed. Then I `mv build.mk.sample build.mk`, set "BuildFlavour = perf-llvm", add "GhcWithLlvmCodeGen = YES". Finally `./configure --with-gcc=/usr/bin/llvm-gcc`. Configure output attached. After make, I tried `inplace/bin/ghc-stage2 –info`, it is still using native code generator. What should I do? config.log<https://docs.google.com/file/d/0BzTVWOyY2ZO4SXRqdnUzdE5WREk/edit> -- 竹密岂妨流水过山高哪阻野云飞 And for G+, please use magiclouds#gmail.com.

3 6

I cannot compile ghc-7.6.2
by Magicloud Magiclouds 12 Feb '13

12 Feb '13

Hi, Linuxmint Nadia, ghc-7.6.1 was built and running OK. Just downloaded ghc-7.6.2, without changing anything and environment, and boot and configure returned OK, I got these. What happened? 20130210Sun183147magicloud(a)ctu-9986008283~/s/ghc-7.6.2 $ make + test -f mk/config.mk.old + cp -p mk/config.mk mk/config.mk.old touch -r mk/config.mk.old mk/config.mk + test -f mk/project.mk.old + cp -p mk/project.mk mk/project.mk.old touch -r mk/project.mk.old mk/project.mk + test -f compiler/ghc.cabal.old + cp -p compiler/ghc.cabal compiler/ghc.cabal.old touch -r compiler/ghc.cabal.old compiler/ghc.cabal ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/package-data.mk: No such file or directory libraries/Cabal/Cabal/ghc.mk:3: libraries/Cabal/Cabal/dist-boot/ package-data.mk: No such file or directory libraries/binary/ghc.mk:3: libraries/binary/dist-boot/package-data.mk: No such file or directory libraries/bin-package-db/ghc.mk:3: libraries/bin-package-db/dist-boot/ package-data.mk: No such file or directory libraries/hoopl/ghc.mk:3: libraries/hoopl/dist-boot/package-data.mk: No such file or directory compiler/ghc.mk:450: compiler/stage1/package-data.mk: No such file or directory utils/hsc2hs/ghc.mk:14: utils/hsc2hs/dist/package-data.mk: No such file or directory ghc/ghc.mk:106: ghc/stage1/package-data.mk: No such file or directory mkdir inplace mkdir inplace/bin "rm" -f utils/ghc-pkg/Version.hs mkdir inplace/lib echo "module Version where" >> utils/ghc-pkg/Version.hs "rm" -f inplace/bin/mkdirhier echo "version, targetOS, targetARCH :: String" >> utils/ghc-pkg/Version.hs echo "version = \"7.6.2\"" >> utils/ghc-pkg/Version.hs echo '#!/bin/sh' >> inplace/bin/mkdirhier echo "targetOS = \"linux\"" >> utils/ghc-pkg/Version.hs cat utils/mkdirhier/mkdirhier.sh >> inplace/bin/mkdirhier echo "targetARCH = \"x86_64\"" >> utils/ghc-pkg/Version.hs chmod +x inplace/bin/mkdirhier "inplace/bin/mkdirhier" utils/ghc-cabal/dist/build/tmp//. "inplace/bin/mkdirhier" bootstrapping/. "inplace/bin/mkdirhier" inplace/bin//. "inplace/bin/mkdirhier" compiler/stage1/build//. "inplace/bin/mkdirhier" utils/ghc-pkg/dist/build/tmp//. "inplace/bin/mkdirhier" inplace/lib/package.conf.d/. "/usr/local/bin/ghc" -H32m -O --make utils/ghc-cabal/Main.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal \ -no-user-package-db \ -Wall \ -DCABAL_VERSION=1,16,0 \ -odir bootstrapping \ -hidir bootstrapping \ -ilibraries/Cabal/Cabal \ -ilibraries/filepath \ -ilibraries/hpc \ "rm" -f compiler/stage1/build/Config.hs Creating compiler/stage1/build/Config.hs ... done. libraries/Cabal/Cabal/Distribution/ParseUtils.hs:88:18: Could not find module `Data.Map' It is a member of the hidden package `containers-0.5.0.0'. Use -v to see a list of the files searched for. make[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Error 1 make: *** [all] Error 2 -- 竹密岂妨流水过山高哪阻野云飞 And for G+, please use magiclouds#gmail.com.

2 2

RE: GHC 7.8 release?
by Simon Peyton-Jones 10 Feb '13

10 Feb '13

It’s fairly simple in my mind. There are two “channels” (if I understand Mark’s terminology right): · Haskell Platform: o A stable development environment, lots of libraries known to work o Newcomers, and people who value stability, should use the Haskell Platform o HP comes with a particular version of GHC, probably not the hottest new one, but that doesn’t matter. It works. · GHC home page downloads: o More features but not so stable o Libraries not guaranteed to work o Worth releasing, though, as a forcing function to fix bugs, and as a checkpoint for people to test, so that by the time the HP adopts a particular version it is reasonably solid. So we already have the two channels Mark asks for, don’t we? One is called the Haskell Platform and one is called the GHC home page. That leaves a PR issue: we really don’t want newcomers or Joe Users wanting the “new shiny”. They want the Haskell Platform, and as Mark says those users should not pay the slightest attention until it appears in the Haskell Platform. So perhaps we principally need a way to point people away from GHC and towards HP? eg We could prominently say at every download point “Stop! Are you sure you want this? You might be better off with the Haskell Platform! Here’s why...”. Have I understood aright? If so, how could we achieve the right social dynamics? Our goal is to let people who value stability get stability, while the hot-shots race along in a different channel and pay the price of flat tires etc. PS: absolutely right to use 7.6.2 for the next HP. Don’t even think about 7.8. Simon From: Mark Lentczner [mailto:mark.lentczner@gmail.com] Sent: 07 February 2013 17:43 To: Simon Peyton-Jones Cc: andreas.voellmy(a)gmail.com; Carter Schonwald; GHC users; Simon Marlow; parallel-haskell; kostirya(a)gmail.com; Edsko de Vries; ghc-devs(a)haskell.org Subject: Re: GHC 7.8 release? I'd say the window for 7.8 in the platform is about closed. If 7.8 were to be release in the next two weeks that would be just about the least amount of time I'd want to see for libraries in the platform to get all stable with the GHC version. And we'd also be counting on the GHC team to be quickly responding to bugs so that there could be a point release of 7.8 mid-April. Historically, none of that seems likely. So my current trajectory is to base HP 2013.2.0.0 on GHC 7.6.2. Since 7.8 will seems like it will be released before May, we will be faced again with the bad public relations issue: Everyone will want the new shiny and be confused as to why the platform is such a laggard. We'll see four reactions: * New comers who are starting out and figure they should use the latest... Many will try to use 7.8, half the libraries on hackage won't work, things will be wonky, and they'll have a poor experience. * People doing production / project work will stay on 7.6 and ignore 7.8 for a few months. * The small group of people exploring the frontiers will know how to get things set up and be happy. * Eventually library authors will get around to making sure their stuff will work with it. I wish GHC would radically change it's release process. Things like 7.8 shouldn't be release as "7.8". That sounds major and stable. The web site will have 7.8 at the top. The warning to use the platform will fall flat because it makes the platform look out of date. Really, "7.8" should be in a different release channel, not on the front page. It should bake in that channel for six months - where only the third group of people will use it, until it is getting close to merge into main, at which point the fourth group will start to use it, so that the day it hits main, all the libraries just work. Ideally, the first two groups of people will not pay the slightest attention to it until it is further baked. While we achievements of the GHC team are great, less than half of those 7.8 features seem interesting from the viewpoint of the aims of the platform. I don't think adding syntactic or type-level features are really all that important for Haskell at this juncture. And while I do like to see improvements in generated code and run-time performance, I think even those are less important than making crucial ecosystem improvements to things like package management, cross-compilation, and libraries. - Mark

15 25

Re: GHC 7.8 release?
by Ian Lynagh 08 Feb '13

08 Feb '13

On Thu, Feb 07, 2013 at 09:42:39AM -0800, Mark Lentczner wrote: > > I wish GHC would radically change it's release process. Things like 7.8 > shouldn't be release as "7.8". That sounds major and stable. The web site > will have 7.8 at the top. The warning to use the platform will fall flat > because it makes the platform look out of date. Really, "7.8" should be in > a different release channel, not on the front page. It should bake in that > channel for six months - where only the third group of people will use it, > until it is getting close to merge into main, at which point the fourth > group will start to use it, so that the day it hits main, all the libraries > just work. Ideally, the first two groups of people will not pay the > slightest attention to it until it is further baked. It's a catch-22: We don't want people to use a new release until all the bugs have been found and fixed, and all the libraries have been updated. But if people don't use it, then the bugs won't be found and the libraries won't be updated. I think you're saying that you'd like the uptake of new GHC versions to be slower, which would mean fewer people would be using 7.6 now, but in the last few days I've seen the Debian guys have had to send mails to maintainers telling them that their packages don't work with 7.6: http://lists.debian.org/debian-haskell/2013/02/threads.html despite 7.6 having been out for 5 months and about to enter the HP. Perhaps more automatic Hackage building, with a group of people looking at the logs of failing packages and acting appropriately, is the way forward. Some cases (such as "installation failed due to dependencies not being installable") you'd want to be handled automatically. Thanks Ian

2 1

RE: Cloud Haskell and network latency issues with -threaded
by Simon Peyton-Jones 08 Feb '13

08 Feb '13

I (with help from Kazu and helpful comments from Bryan and Johan) have nearly completed an overhaul to the IO manager based on my observations and we are in the final stages of getting it into GHC This is really helpful. Thank you very much Andreas, Kazu, Bryan, Johan. Simon From: parallel-haskell(a)googlegroups.com [mailto:parallel-haskell@googlegroups.com] On Behalf Of Andreas Voellmy Sent: 06 February 2013 14:28 To: watson.timothy(a)gmail.com Cc: kostirya(a)gmail.com; parallel-haskell; glasgow-haskell-users(a)haskell.org Subject: Re: Cloud Haskell and network latency issues with -threaded Hi all, I haven't followed the conversations around CloudHaskell closely, but I noticed the discussion around latency using the threaded runtime system, and I thought I'd jump in here. I've been developing a server in Haskell that serves hundreds to thousands of clients over very long-lived TCP sockets. I also had latency problems with GHC. For example, with 100 clients I had a 10 ms (millisecond) latency and with 500 clients I had a 29ms latency. I looked into the problem and found that some bottlenecks in the threaded IO manager were the cause. I made some hacks there and got the latency for 100 and 500 clients down to under 0.2 ms. I (with help from Kazu and helpful comments from Bryan and Johan) have nearly completed an overhaul to the IO manager based on my observations and we are in the final stages of getting it into GHC. Hopefully our work will also fix the latency issues in CloudHaskell programs :) It would be very helpful if someone has some benchmark CloudHaskell applications and workloads to test with. Does anyone have these handy? Cheers, Andi On Wed, Feb 6, 2013 at 9:09 AM, Tim Watson <watson.timothy(a)gmail.com<mailto:watson.timothy@gmail.com>> wrote: Hi Kostirya, I'm putting the parallel-haskell and ghc-users lists on cc, just in case other (better informed) folks want to chip in here. ---- First of all, I'm assuming you're talking about network latency when compiling with -threaded - if not I apologise for misunderstanding! There is apparently an outstanding network latency issue when compiling with -threaded, but according to a conversation I had with the other developers on #haskell-distributed, this is not something that's specific to Cloud Haskell. It is something to do with the threaded runtime system, so would need to be solved for GHC (or is it just the Network package!?) in general. Writing up a simple C program and equivalent socket use in Haskell and comparing the latency using -threaded will show this up. See the latency section in http://haskell-distributed.github.com/wiki/networktransport.html for some more details. According to that, there *are* some things we might be able to do, but the 20% latency isn't going to change significantly on the face of things. We have an open ticket to look into this (https://cloud-haskell.atlassian.net/browse/NTTCP-4) and at some point we'll try and put together the sample programs in a github repository (if that's not already done - I might've missed previous spikes done by Edsko or others) and investigate further. One of the other (more experienced!) devs might be able to chip in and proffer a better explanation. Cheers, Tim On 6 Feb 2013, at 13:27, kostirya(a)gmail.com<mailto:kostirya@gmail.com> wrote: > Haven't you had a necessity to launch Haskell in no-threaded mode during the intense network data exchange? > I am getting the double performance penalty in threaded mode. But I must use threaded mode because epoll and kevent are available in the threaded mode only. > [snip] > > > среда, 6 февраля 2013 г., 12:33:36 UTC+2 пользователь Tim Watson написал: > Hello all, > > It's been a busy week for Cloud Haskell and I wanted to share a few of > our news items with you all. > > Firstly, we have a new home page at http://haskell-distributed.github.com, > into which most of the documentation and wiki pages have been merged. Making > sassy looking websites is not really my bag, so I'm very grateful to the > various author's whose Creative Commons licensed designs and layouts made > it easy to put together. We've already had some pull requests to fix minor > problems on the site, so thanks very much to those who've contributed already! > > As well as the new site, you will find a few of us hanging out on the > #haskell-distributed channel on freenode. Please do come along and join in > the conversation. > > We also recently split up the distributed-process project into separate > git repositories, one for each component that makes up Cloud Haskell. This > was done partly for administrative purposes and partly because we're in the > process of setting up CI builds for all the projects. > > Finally, we've moved from Github's issue tracker to a hosted Jira/Bamboo setup > at https://cloud-haskell.atlassian.net - pull requests are naturally still welcome > via Github! Although you can browse issues freely without logging in, you will > need to provide an email address and get an account in order to submit new ones. > If you have any difficulties logging in, please don't hesitate to contact me > directly, via this forum or the cloud-haskell-developers mailing list (on > google groups). > > As always, we'd be delighted to hear any feedback! > > Cheers, > Tim -- You received this message because you are subscribed to the Google Groups "parallel-haskell" group. To unsubscribe from this group and stop receiving emails from it, send an email to parallel-haskell+unsubscribe(a)googlegroups.com<mailto:parallel-haskell%2Bunsubscribe@googlegroups.com>. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "parallel-haskell" group. To unsubscribe from this group and stop receiving emails from it, send an email to parallel-haskell+unsubscribe(a)googlegroups.com<mailto:parallel-haskell+unsubscribe@googlegroups.com>. For more options, visit https://groups.google.com/groups/opt_out.

3 4

GHC 7.8 release?
by Simon Peyton-Jones 07 Feb '13

07 Feb '13

Dear GHC users, Carter: Will this RTS update make it into ghc 7.8 update thats coming up in the next monthish? Andreas: We are almost there - we are now trying to sort out a problem on mac os x. It would be helpful to know if there is a cutoff date for getting things into 7.8. Simon, Ian, and I have just been discussing 7.8, and would be interested in what you guys think. At ICFP we speculated that we'd make a release of GHC soon after Christmas to embody tons of stuff that has been included since 7.6, specifically: · major improvements in DPH (vectorisation avoidance, new vectoriser) · type holes · rebindable list syntax · major changes to the type inference engine · type level natural numbers · overlapping type families · the new code generator · support for vector (SSE/AVX) instructions Whenever it comes it would definitely be great to include Andreas & friends' work: · Scheduler changes to the RTS to improve latency The original major reason for proposing a post-Xmas release was to get DPH in a working state out into the wild. However, making a proper release imposes costs on everyone else. Library authors have to scurry around to make their libraries work, etc. Some of the new stuff hasn't been in HEAD for that long, and hence has not been very thoroughly tested. (But of course making a release unleashes a huge wave of testing that doesn't happen otherwise.) So another alternative is to leave it all as HEAD, and wait another few months before making a release. You can still use all the new stuff by compiling HEAD, or grabbing a snapshot distribution. And it makes it hard for the Haskell platform if GHC moves too fast. Many people are still on 7.4. There seem to be pros and cons each way. I don't have a strong opinion. If you have a view, let us know. Simon

10 9

Re: Cloud Haskell and network latency issues with -threaded
by Andreas Voellmy 06 Feb '13

06 Feb '13

Hi Edsko, Can you explain the figure linked to on that page a bit? E.g. how should the axes be labelled? On Wed, Feb 6, 2013 at 9:33 AM, Edsko de Vries <edsko(a)well-typed.com> wrote: > Hi, > > Just for clarity's sake (as the author of that "Latency" section that Tim > referred to): I have addressed all of the issues listed there in > Network.Transport.TCP, with the exception of the first (the -threaded > issue). As Tim points out, this is not a Cloud Haskell specific issue; I > have written this up as a short blog post at > http://www.edsko.net/2013/02/06/performance-problems-with-threaded . > > Edsko > > > > On Wednesday, 6 February 2013 14:09:22 UTC, Tim Watson wrote: > >> Hi Kostirya, >> >> I'm putting the parallel-haskell and ghc-users lists on cc, just in case >> other (better informed) folks want to chip in here. >> >> ---- >> >> First of all, I'm assuming you're talking about network latency when >> compiling with -threaded - if not I apologise for misunderstanding! >> >> There is apparently an outstanding network latency issue when compiling >> with -threaded, but according to a conversation I had with the other >> developers on #haskell-distributed, this is not something that's specific >> to Cloud Haskell. It is something to do with the threaded runtime system, >> so would need to be solved for GHC (or is it just the Network package!?) in >> general. Writing up a simple C program and equivalent socket use in Haskell >> and comparing the latency using -threaded will show this up. >> >> See the latency section in http://haskell-distributed.**github.com/wiki/* >> *networktransport.html<http://haskell-distributed.github.com/wiki/networktransport.html>for some more details. According to that, there *are* some things we might >> be able to do, but the 20% latency isn't going to change significantly on >> the face of things. >> >> We have an open ticket to look into this (https://cloud-haskell.** >> atlassian.net/browse/NTTCP-4<https://cloud-haskell.atlassian.net/browse/NTTCP-4>) >> and at some point we'll try and put together the sample programs in a >> github repository (if that's not already done - I might've missed previous >> spikes done by Edsko or others) and investigate further. >> >> One of the other (more experienced!) devs might be able to chip in and >> proffer a better explanation. >> >> Cheers, >> Tim >> >> >> On 6 Feb 2013, at 13:27, kost...(a)gmail.com wrote: >> >> > Haven't you had a necessity to launch Haskell in no-threaded mode >> during the intense network data exchange? >> > I am getting the double performance penalty in threaded mode. But I >> must use threaded mode because epoll and kevent are available in the >> threaded mode only. >> > >> >> [snip] >> >> > >> > >> > среда, 6 февраля 2013 г., 12:33:36 UTC+2 пользователь Tim Watson >> написал: >> > Hello all, >> > >> > It's been a busy week for Cloud Haskell and I wanted to share a few of >> > our news items with you all. >> > >> > Firstly, we have a new home page at http://haskell-distributed.** >> github.com <http://haskell-distributed.github.com>, >> > into which most of the documentation and wiki pages have been merged. >> Making >> > sassy looking websites is not really my bag, so I'm very grateful to >> the >> > various author's whose Creative Commons licensed designs and layouts >> made >> > it easy to put together. We've already had some pull requests to fix >> minor >> > problems on the site, so thanks very much to those who've contributed >> already! >> > >> > As well as the new site, you will find a few of us hanging out on the >> > #haskell-distributed channel on freenode. Please do come along and join >> in >> > the conversation. >> > >> > We also recently split up the distributed-process project into separate >> > git repositories, one for each component that makes up Cloud Haskell. >> This >> > was done partly for administrative purposes and partly because we're in >> the >> > process of setting up CI builds for all the projects. >> > >> > Finally, we've moved from Github's issue tracker to a hosted >> Jira/Bamboo setup >> > at https://cloud-haskell.**atlassian.net<https://cloud-haskell.atlassian.net>- pull requests are naturally still welcome >> > via Github! Although you can browse issues freely without logging in, >> you will >> > need to provide an email address and get an account in order to submit >> new ones. >> > If you have any difficulties logging in, please don't hesitate to >> contact me >> > directly, via this forum or the cloud-haskell-developers mailing list >> (on >> > google groups). >> > >> > As always, we'd be delighted to hear any feedback! >> > >> > Cheers, >> > Tim >> >> -- > You received this message because you are subscribed to the Google Groups > "parallel-haskell" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to parallel-haskell+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > >

1 0