- ghc-devs - Haskell.org

GHC Trac donw
by Simon Peyton Jones 03 Apr '14

03 Apr '14

Accessing the GHC Trac yields https://ghc.haskell.org/trac/ghc/ Error TracError: The Trac Environment needs to be upgraded. Run "trac-admin /home/trac/ghc upgrade" Simon

2 1

RE: [GHC] #8953: Inner Thigh Slimming Exercises for Women
by Simon Peyton Jones 03 Apr '14

03 Apr '14

Folks, The GHC Trac is attracting spam. Does anyone know enough to stop it? Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of | GHC | Sent: 03 April 2014 05:26 | Cc: ghc-tickets(a)haskell.org | Subject: [GHC] #8953: Inner Thigh Slimming Exercises for Women | | #8953: Inner Thigh Slimming Exercises for Women | ------------------------------------+----------------------------------- | ------------------------------------+-- | Reporter: szxdai1 | Owner: | Type: bug | Status: new | Priority: normal | Milestone: | Component: Compiler | Version: 7.6.3 | Keywords: | Operating System: | Unknown/Multiple | Architecture: Unknown/Multiple | Type of failure: None/Unknown | Difficulty: Unknown | Test Case: | Blocked By: | Blocking: | Related Tickets: | | ------------------------------------+----------------------------------- | ------------------------------------+-- | How To Decline Thigh Coefficient or retrogress weight swift around your | thighs offers quite a bit to do with intrinsic helping slimming | exercises. | The easiest method to worsen weight from your thighs would be to do | exercises that aim your minify body. Inside serving slimming workouts | are those workouts that mostly rivet on the fat around your exclusive | thighs. | Virtuous some any portion training contributes to losing helping | coefficient mostly. When you essential to worsen coefficient around your | privileged thighs and immobile up, You may penury to accomplish several | special exercises that alter on this region. I am achievement to part | with you two of the most operative helping slimming exercises. | [http://tryabsolutegarciniacambogia.com/ ABSOLUTE GARCINIA CAMBOGIA] | Decline unit accelerated Around Your Thighs Workouts Leg Butterfly | Broad: -This use works rise for broad the intrinsical thighs, Making | yourself solon elastic and in acquisition it helps with the toning of | the thighs. To perform this workout, You instrument hump to sit on a | carpeted story after which juncture your soles from the feet together. | Your legs is accomplishment to be unstoppered but both of the feet | instrument attack apiece other. When you're in this berth, Countenance | the knees to alter to the flooring. Lessen your knees towards the | flooring as much as you can for the way pliable you are. Spell | performing this recitation, rub both hands stretchability around your | privileged thighs. | Intrinsical Serving Firmer Workout: -You give feature to fulfill this | helping slimming learn part a small layer and also be certain you | somebody a towel or a dinky wide to relax your brain on. To fulfil this | workout, Lie in your sinistral indorse and urinate careful your surface | is resting on a folded departed towel or bittie encompassing. This | truly is to coil. | And protect your manus leg change to the base, Slowly flex the best leg | towards the deceiver individuals. Now you gift essential to uprise your | unexhausted leg for active six inches off the level and suppress it for | many transactions. Then petty it to the turn item and now cultivate it | as existence presently as it touches the mat {other tract endorse. Do | that sleazy portion workout on the sides with the similar repeating. | These serving slimming workouts are painless to fulfil and they could | be comfortably through from the status of your own asylum. If you are | disagreeable to chant up and get narrow thighs, Then I suggest that you | do aerophilic exercises too. Recollect your fasting as what you eat | counts for your upbeat too. For statesman useful message on how to | retrograde serving coefficient in the subordinate part of your body, | Impose Privileged helping slimming exercises beneath. Recede metric | firm around your thighs is about punish in both consumption a growing | fasting organisation and regular workout.'''ABSOLUTE GARCINIA | CAMBOGIA''' | Decline metric allegro around your thighs else finest workouts which | are outgo extricated permit functional, Jogging and aquatics. They are | fun to do exercises that you ought to sicken benefit of. Don't think | that visiting the gym is the exclusive way to total serving slimming | exercises. | Keep your expensive gym body money and remain physically energetic by | exertion from base and doing fun aerophilous workouts inaccurate. | http://tryabsolutegarciniacambogia.com/ | | -- | Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8953> | GHC <http://www.haskell.org/ghc/> | The Glasgow Haskell Compiler | _______________________________________________ | ghc-tickets mailing list | ghc-tickets(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-tickets

1 0

RE: Buildbots
by Simon Peyton Jones 01 Apr '14

01 Apr '14

Friends The nightly-build infrastructure for GHC is in disarray, and we could really do with help. We really want * Continuous integration so that new test failures show up fast * Nightly builds on a variety of platforms, giving snapshots that are easy to install Originally we used Buildbot (http://buildbot.net/) Then in 2010 Ian Lynagh put a lot of work into a build-bot infrastructure, implemented in Haskell as an open-source project, GHC Builder (https://ghc.haskell.org/trac/ghc/wiki/Builder). See https://ghc.haskell.org/trac/ghc/wiki/Status/Apr10#Nightlybuilds for the reasoning at the time. As I understand it, Builder never "caught fire", and now that Ian has moved on I don't know that anyone is maintaining it; nor are the various builders working so far as I know. Perhaps competing technology has moved on, so that the original rationale no longer holds? I'm not sure. Regardless, we lack leadership in this area. Joachim Breitner has set up Travis-CI. (I don't know exactly what that is, but it sounds useful.) Others have indicated interest/willingness. But it would be fantastic to have a person, or (more plausibly) a small group who assumed leadership. An early question would be: to continue to use a DIY system (Builder), or to move to some other better-supported (but perhaps less malleable) system. I don't even know what the options are. Others will be better informed than me about all this... we'd love to hear from you. Thank you! Simon | -----Original Message----- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of harry | Sent: 01 April 2014 08:42 | To: glasgow-haskell-users(a)haskell.org | Subject: Buildbots | | It having been suggested that a buildbot for Windows may be needed, and | it | being possible that I may receive permission from management for setting | one | up in my department's server room, I set about attempting to discover | what | this actually entails. | | A Google search led me to https://ghc.haskell.org/trac/ghc/wiki/BuildBot, | which tells me that "Buildbot is currently down, and we are working on a | replacement. See Builder for more details." If I follow the 'down' link , | I | get to the GHC status April 2010 page, which says that buildbot has been | abandoned, suggesting that the page should be deleted. Could someone | confirm | before I go ahead and delete it? | | The Builder page has clear instructions on how to set up a build slave, | and | a link to the build results. The build results contains an assortment of | dud | links and builds from August and earlier. | | What is the current state of automated builds? | | | | -- | View this message in context: | http://haskell.1045720.n5.nabble.com/Buildbots-tp5746770.html | Sent from the Haskell - Glasgow-haskell-users mailing list archive at | Nabble.com. | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

11 24

Re: Haskell Support on Windows (Simon Peyton Jones)
by Kyle Van Berendonck 01 Apr '14

01 Apr '14

A couple of poor assumptions are made here. The first is that the userbase of GHC on Windows is poor. This is false. In fact, the poor state of Windows is mentioned on #haskell more frequently as of late. In the last week I've talked almost every day to (different) people who have had Windows woes with using GHC. The hacker-base isn't here at the moment - I agree, but the user-base most certainly is. Could this be a problem with the demographic, or could it just be that Windows development isn't inviting? The build system and default test failures in-particular are a source of discouragement. The second assumption is that GHC/Haskell will be worth a dime in the RealWorld without Windows as a primary tier platform. I'm going to put a crude guess that given the overwhelming magnitude of C#/F# coming up on my local careers portal that there's far more industry on Windows than on OSX or Linux. Those are all the businesses where the probability that they will ever touch Haskell goes from `probably not right now` to `impossible`. Let me also remind you that Windows still holds 89.2% of operating system market share ie the people that hackers and developers actually have to deploy their applications to. Sorry to sound fumey, but there's all this suggesting that everyone would have a better day if we dropped Windows (let's be honest, if it wasn't a primary tier platform nobody would have fixed it for 7.8), but I doubt few of the people who think it's a "great idea" or sslt have actually thought through whether it's the best thing for Haskell or just the best thing to get 7.8 into their hands a couple weeks sooner. Regards.

3 2

RE: Haskell Support on Windows
by Simon Peyton Jones 01 Apr '14

01 Apr '14

| I've been getting the impression that a lot of the stickier GHC bugs are | Windows specific, while very few GHC hackers actually use Windows, other | than to ensure that GHC works on it. ... | Perhaps it should be "demoted" to second-tier GHC support as well, at | least to the extent that Windows bugs won't hold up a release? That's true. But many, many people *use* GHC on Windows. It would be terribly sad to abandon them. What we need is more developers to volunteer to help look after the Windows version of GHC. One or two are doing so, but we need more. Please! Simon

1 0

RE: Gearing up (again) for the next release: 2014.2.0.0
by Simon Peyton Jones 31 Mar '14

31 Mar '14

| If I've understood #8736 correctly, GHCi on Windows can't load modules | that | were compiled with --dynamic-too. That's a pretty nasty regression, as | --dynamic-too will now be the default for anything used by TH. Well, five weeks ago we marked the ticket as "not a release blocker". No one commented. And it's not a regression, is it? I don't think -dynamic-too existed in 7.6. We'd welcome help with this. There is some reason it's not straightforward to fix, but I've forgotten what it is. Simon | -----Original Message----- | From: Libraries [mailto:libraries-bounces@haskell.org] On Behalf Of harry | Sent: 31 March 2014 09:21 | To: libraries(a)haskell.org | Subject: RE: Gearing up (again) for the next release: 2014.2.0.0 | | Simon Peyton Jones wrote | > We have not begun to think about when to release 7.8.2. It’ll depend | on | > what issues show up in 7.8.1 and how urgent they seem to be. We have | > delayed 7.8.1 for ages, and given masses of warning about the release, | so | > I’d be sad if there are known, show-stopping bugs in it that we already | > know about. If there really really really are, maybe we should delay | > 7.8.1 further. But that process can go on indefinitely (as we have | > already seen), so I’m pretty reluctant. | > | > But I’d certainly listen to a consensus view from the HP team. You | > represent our customers. | | If I've understood #8736 correctly, GHCi on Windows can't load modules | that | were compiled with --dynamic-too. That's a pretty nasty regression, as | --dynamic-too will now be the default for anything used by TH. | | | | -- | View this message in context: | http://haskell.1045720.n5.nabble.com/Gearing-up-again-for-the-next- | release-2014-2-0-0-tp5746660p5746686.html | Sent from the Haskell - Libraries mailing list archive at Nabble.com. | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

1 0

Looks like I broke the build. Fixing <eom>
by Johan Tibell 29 Mar '14

29 Mar '14

2 7

Re: We need to add role annotations for 7.8
by Mark Lentczner 28 Mar '14

28 Mar '14

Thank you to everyone who has been helping me understand this issue in greater depth. *tl;dr: As long as we don't expect any libraries beyond to core to annotate, I'm cool. This presumes that the extra safety isn't, in practice, dependent on transitive adoption by libraries. It also implies that representational is the only possible default, and that there can be no migration from it.* My approach to thinking about this is guided by thinking about supporting an eco-system with 1000s of libraries (hackage), a few dozen of which are heavily promoted (the platform), and a small set that are closely tied to the compiler (the core). The availability, speed of release, motivation, and even skill of the the developers varies widely over that range. I also think about the various "stances" of different developers: - *End developer*: makes use of libraries, but just builds apps - *Internal developer*: makes libraries for internal use in a project - *Casual library writer*: makes libraries, primarily for their own needs, but distributed on hackage - *Popular library writer:* actively maintains libraries which are widely used - *Core library writer: *maintainer of a core package that stays in lock step with the compiler Then, I think about, for each of these, what is the effect on a new feature on them, their existing code, and future code? Does it affect them only if they are using the feature? If they aren't using the feature? For library writers, how does the feature affect clients? If a client wants to use a feature, under what conditions does the library need to do something? This last issue of the "transitivity" the feature is often the biggest concern. *Given that... onto type roles:* The default of *representational* is the only option, because a default of *nominal* would require far too many developers to have to update their code. I don't believe that we can ever migrate to *nominal* as default. The feature implies that any abstract data type that uses a type parameter in certain ways needs annotate to get the full safety afforded now afforded. However, without annotation, the data type is still no worse off than it was before (there is added safety, but not perhaps relevant to the stand point of the library writer). Further, this (pre-existing) non-safety isn't likely a huge concern. Making sure the docs take the tone that most developers need to nothing, and when developers need to be concerned seems like an important way to ensure the right outcome. A key question here is transitivity: Is it possible for module A to not annotate a type, and then have module B by a different author use the type in A in another abstract type, that *is* annotated, and get the benefit. Seems the answer is "partially". If the answer were "no", then use of the feature would be dependent on transitive adoption, and that is where the big burden on developers comes from. The degree to which we believe this "partially" is important: If we are willing to believe that the only library writers we care about doing this are those in the core, then fine. In this case we shouldn't feel compelled to suggest to library writers that they annotate, ever. I'm good with this. If the team here thinks otherwise, that we need to start a campaign to get every library writer to eventually annotate, then I have deep objections. I read the paper, and understand how the authors felt the syntax options were all less than perfect, and choose what they did. But that choice, perhaps unwittingly, the implication that it forces -XCPP on all libraries except perhaps some of the core. This is because they all need to support previous compilers. So, a one line annotation has turned into an ugly beast, and perhaps added -XCPP where there was none, which is really unfortunate. (I, like many, consider it a defeat when one has to resort to -XCPP.) It seems to me that the paper didn't really consider less-perfect, heuristic solutions. It might have had significantly less impact on library writers were some heuristic (no constructors exported? has any type constraint on the parameter? etc..) might have allowed most data types to go without annotation at the cost of a few (where *nominal* was incorrectly inferred) requiring immediate action. In this situation, a non-language feature (pragma or other device) might have been more palatable. Finally, on the choice of terms, *nominal*, *representational*, and *phantom* all seem like clear, self-explanatory choices to me. - Mark

3 5

help understanding the validate_build_xhtml failure of ./validate for my CPP patch
by Carter Schonwald 28 Mar '14

28 Mar '14

Hey all, I'm trying to get my CPP_Setttings patch to validate, and i'm trying to understand why my validate is failing. At this point im stumped and I really could use some help! I'd appreciate some assistance digging into this, the ticket in question is https://ghc.haskell.org/trac/ghc/ticket/8683#comment:50 my current set of patches is https://github.com/cartazio/ghc/compare/ghc:ghc-7.8...rb_cpp_settings(rebas… on top of current 7.8 branch) and the confusing error in question is == Start post-install package check Timestamp 2014-03-23 17:32:46 UTC for /Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir/lib/ghc-7.8.0.20140323/package.conf.d/package.cache Timestamp 2014-03-23 17:32:46 UTC for /Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir/lib/ghc-7.8.0.20140323/package.conf.d (same as cache) using cache: /Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir/lib/ghc-7.8.0.20140323/package.conf.d/package.cache == End post-install package check ===--- building phase 0 /Applications/Xcode.app/Contents/Developer/usr/bin/make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 /Applications/Xcode.app/Contents/Developer/usr/bin/make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for `phase_1_builds'. ===--- building final phase /Applications/Xcode.app/Contents/Developer/usr/bin/make -r --no-print-directory -f ghc.mk phase=final validate_build_xhtml cd libraries/xhtml && "/Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir/bin/ghc" --make Setup [1 of 1] Compiling Main ( Setup.hs, Setup.o ) Linking Setup ... cd libraries/xhtml && ./Setup configure --with-ghc="/Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir/bin/ghc" --with-haddock="/Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir/bin/haddock" --enable-shared --disable-library-vanilla --disable-library-prof --global --builddir=dist-bindist --prefix="/Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir" Configuring xhtml-3000.2.1... cd libraries/xhtml && ./Setup build --builddir=dist-bindist Building xhtml-3000.2.1... Preprocessing library xhtml-3000.2.1... ghc: could not execute: make[1]: *** [validate_build_xhtml] Error 1 make: *** [validate_build_xhtml] Error 2 If someone could help me get to the bottom of this, I'd really really appreciate it. -Carter

2 2

Wired-in packages not found
by Maarten Faddegon 27 Mar '14

27 Mar '14

Dear GHC-devs, I want to experiment with the RTS of GHC but the compiler I built has problems finding some wired-in packages. How can I include these? This is what I did: * Download ghc-7.6.3 sources. * Make some changes in rts/ * ./configure && make * inplace/bin/ghc-stage2 --make my_example.lhs -v And this is the output produced by the last step: ... wired-in package ghc-prim mapped to ghc-prim-0.3.0.0-inplace wired-in package integer-gmp mapped to integer-gmp-0.5.0.0-inplace wired-in package base mapped to base-4.6.0.1-inplace wired-in package rts mapped to builtin_rts wired-in package template-haskell not found. wired-in package dph-seq not found. wired-in package dph-par not found. ... my_example.lhs:88:8: Could not find module `Language.Haskell.TH' Locations searched: Language/Haskell/TH.hs Language/Haskell/TH.lhs Thanks, Maarten Faddegon

4 7