From marlowsd at gmail.com Sun Nov 1 15:05:21 2015 From: marlowsd at gmail.com (Simon Marlow) Date: Sun, 1 Nov 2015 07:05:21 -0800 Subject: Better calling conventions for strict functions (bang patterns)? In-Reply-To: References: Message-ID: <56362A31.5020307@gmail.com> Yes, I think we can probably do a better job of compiling case expressions. The current compilation strategy optimises for code size, but at the expense of performance in the fast path. We can tweak this tradeoff, perhaps under the control of a flag. Ideally the sequence should start by assuming that the closure is already evaluated, e.g. loop: tag = R2 & 7; if (tag == 1) then // code for [] else if (tag == 2) then // code for (:) else evaluate; jump back to loop The nice thing is that now that we don't need proc points, "loop" is just a label that we can directly jump to. Unfortunately this only works when using the NCG, not with LLVM, because LLVM requires proc points, so we might need to fall back to a different strategy for LLVM. Similar topics came up here: https://ghc.haskell.org/trac/ghc/ticket/8905 and I think there was another ticket but I can't find it now. Cheers Simon On 23/10/2015 19:00, Ryan Newton wrote: > 1. Small tweaks: The CMM code above seems to be /betting/ than the > thunk is unevaluated, because it does the stack check and stack > write /before/ the predicate test that checks if the thunk is > evaluated (if(R1 & 7!= 0) gotoc3aO; elsegotoc3aP;). With a > bang-pattern function, couldn't it make the opposite bet? That > is, branch on whether the thunk is evaluated first, and then the > wasted computation is only a single correctly predicted branch > (and a read of a tag that we need to read anyway). > > Oh, a small further addition would be needed for this tweak. In the > generated code above "Sp = Sp + 8;" happens /late/, but I think it could > happen right after the call to the thunk. In general, does it seem > feasible to separate the slowpath from fastpath as in the following > tweak of the example CMM? > > > * // Skip to the chase if it's already evaluated:* > * start:* > * if (R2 & 7 != 0) goto fastpath; else goto slowpath;* > * > * > * slowpath: // Formerly c3aY* > * if ((Sp + -8) < SpLim) goto c3aZ; else goto c3b0;* > * c3aZ:* > * // nop* > * R1 = PicBaseReg + foo_closure;* > * call (I64[BaseReg - 8])(R2, R1) args: 8, res: 0, upd: 8;* > * c3b0:* > * I64[Sp - 8] = PicBaseReg + block_c3aO_info;* > * R1 = R2;* > * Sp = Sp - 8;* > > * call (I64[R1])(R1) returns to fastpath, args: 8, res: 8, upd: 8;* > * // Sp bump moved to here so it's separate from "fastpath"* > * Sp = Sp + 8;* > * > * > * fastpath: // Formerly c3aO* > * if (R1 & 7 >= 2) goto c3aW; else goto c3aX;* > * c3aW:* > * R1 = P64[R1 + 6] & (-8);* > * call (I64[R1])(R1) args: 8, res: 0, upd: 8;* > * c3aX:* > * R1 = PicBaseReg + lvl_r39S_closure;* > * call (I64[R1])(R1) args: 8, res: 0, upd: 8;* > > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From ezyang at mit.edu Sun Nov 1 23:19:19 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Sun, 01 Nov 2015 15:19:19 -0800 Subject: Proposal: accept pull requests on GitHub In-Reply-To: <874mha65pr.fsf@karetnikov.org> References: <55E60DAD.503@nh2.me> <874mha65pr.fsf@karetnikov.org> Message-ID: <1446419843-sup-2330@sabre> Hello Nikita, Phabricator has a model where you can make all of your comments in a batch (unsubmitted), and then submit them at once. TBH, I've never had a workflow where I didn't want my intermediate comments to be posted immediately, but it also hasn't been too much of a bother to make my comments, and then scroll to the bottom and submit. Edward Excerpts from Nikita Karetnikov's message of 2015-10-28 14:30:56 -0700: > > I would recommend against moving code reviews to Github. > > I like it and use it all the time for my own projects, but for a large > > project like GHC, its code reviews are too basic (comments get lost in > > multi-round reviews), and its customisation an process enforcement is > > too weak; but that has all been mentioned already on the > > https://ghc.haskell.org/trac/ghc/wiki/WhyNotGitHub page you linked. > > At least you're able to submit comments! I just had my second > interaction with arc/phab and I have to say that I really hate both now. > The former is not flexible enough and lacks documentation, the latter is > just plain confusing. > > I was trying to update an existing phab diff (D1334), but I had no idea > what would be submitted, and I'm still not sure whether I did that okay > or not. Oh, slyfox tells me that I overwrote my previous changes, nice! > In the process, I also created a new revision by mistake. The web UI > didn't help either since there's so much stuff: diffs, revisions, ids. > Is it okay to have multiple diffs in a single phab differential after > updating? No idea. > > After that I was struggling to reply to rwbarton. I hit "Done" and > added my comment, but both things were marked as "Unsubmitted" (or > something). After a while I decided to click on the button at the > bottom of the page. Looks like it did the trick, but I have no idea > whether it's the right way or not. > > Not that I'm saying that GitHub is perfect, but at least it works > instead of messing up with the work I carefully tested. From marlowsd at gmail.com Mon Nov 2 02:11:23 2015 From: marlowsd at gmail.com (Simon Marlow) Date: Sun, 1 Nov 2015 18:11:23 -0800 Subject: Proposal: accept pull requests on GitHub In-Reply-To: <874mha65pr.fsf@karetnikov.org> References: <55E60DAD.503@nh2.me> <874mha65pr.fsf@karetnikov.org> Message-ID: <5636C64B.8040802@gmail.com> On 28/10/2015 14:30, Nikita Karetnikov wrote: >> I would recommend against moving code reviews to Github. >> I like it and use it all the time for my own projects, but for a large >> project like GHC, its code reviews are too basic (comments get lost in >> multi-round reviews), and its customisation an process enforcement is >> too weak; but that has all been mentioned already on the >> https://ghc.haskell.org/trac/ghc/wiki/WhyNotGitHub page you linked. > > At least you're able to submit comments! I just had my second > interaction with arc/phab and I have to say that I really hate both now. > The former is not flexible enough and lacks documentation, the latter is > just plain confusing. > > I was trying to update an existing phab diff (D1334), but I had no idea > what would be submitted, and I'm still not sure whether I did that okay > or not. Oh, slyfox tells me that I overwrote my previous changes, nice! > In the process, I also created a new revision by mistake. The web UI > didn't help either since there's so much stuff: diffs, revisions, ids. > Is it okay to have multiple diffs in a single phab differential after > updating? No idea. > > After that I was struggling to reply to rwbarton. I hit "Done" and > added my comment, but both things were marked as "Unsubmitted" (or > something). After a while I decided to click on the button at the > bottom of the page. Looks like it did the trick, but I have no idea > whether it's the right way or not. > > Not that I'm saying that GitHub is perfect, but at least it works > instead of messing up with the work I carefully tested. My guess is that the problems here were mostly because you were unfamiliar with the workflow. Did you look at the wiki page? https://ghc.haskell.org/trac/ghc/wiki/Phabricator At a high level it works like this: - create a diff (arc diff) - update it (arc diff), possibly multiple times - land it (arc land) each time you update it, Phabricator creates a new "revision", attached to the same diff, and you can look at the differences between an arbitrary pair of revisions in the UI. So at any point we can see the whole diff, or just what you changed in the latest revision. As Edward mentioned, in Phabricator you make multiple comments and then submit them all together (which sends a single email to the reviewers). To get to the submit button quickly, hit 'z'. Cheers Simon From mf at zerobuzz.net Mon Nov 2 06:13:54 2015 From: mf at zerobuzz.net (Matthias Fischmann) Date: Mon, 2 Nov 2015 07:13:54 +0100 Subject: Proposal: accept pull requests on GitHub In-Reply-To: <5636C64B.8040802@gmail.com> References: <55E60DAD.503@nh2.me> <874mha65pr.fsf@karetnikov.org> <5636C64B.8040802@gmail.com> Message-ID: <20151102061354.GD6647@lig> I would like to add that even though I'm also skeptical about and intimidated by phabricator by all the reason already discussed, I am very happy with documentation on the wiki. Submitting my first patch didn't feel any harder to me than doing a github pull request. Just to let you know not everybody out there is unhappy with phab. (-: cheers, m. On Sun, Nov 01, 2015 at 06:11:23PM -0800, Simon Marlow wrote: > Date: Sun, 1 Nov 2015 18:11:23 -0800 > From: Simon Marlow > To: Nikita Karetnikov , Niklas Hamb?chen > > Cc: "ghc-devs at haskell.org" > Subject: Re: Proposal: accept pull requests on GitHub > > On 28/10/2015 14:30, Nikita Karetnikov wrote: > >>I would recommend against moving code reviews to Github. > >>I like it and use it all the time for my own projects, but for a large > >>project like GHC, its code reviews are too basic (comments get lost in > >>multi-round reviews), and its customisation an process enforcement is > >>too weak; but that has all been mentioned already on the > >>https://ghc.haskell.org/trac/ghc/wiki/WhyNotGitHub page you linked. > > > >At least you're able to submit comments! I just had my second > >interaction with arc/phab and I have to say that I really hate both now. > >The former is not flexible enough and lacks documentation, the latter is > >just plain confusing. > > > >I was trying to update an existing phab diff (D1334), but I had no idea > >what would be submitted, and I'm still not sure whether I did that okay > >or not. Oh, slyfox tells me that I overwrote my previous changes, nice! > >In the process, I also created a new revision by mistake. The web UI > >didn't help either since there's so much stuff: diffs, revisions, ids. > >Is it okay to have multiple diffs in a single phab differential after > >updating? No idea. > > > >After that I was struggling to reply to rwbarton. I hit "Done" and > >added my comment, but both things were marked as "Unsubmitted" (or > >something). After a while I decided to click on the button at the > >bottom of the page. Looks like it did the trick, but I have no idea > >whether it's the right way or not. > > > >Not that I'm saying that GitHub is perfect, but at least it works > >instead of messing up with the work I carefully tested. > > My guess is that the problems here were mostly because you were unfamiliar > with the workflow. Did you look at the wiki page? > https://ghc.haskell.org/trac/ghc/wiki/Phabricator > > At a high level it works like this: > - create a diff (arc diff) > - update it (arc diff), possibly multiple times > - land it (arc land) > > each time you update it, Phabricator creates a new "revision", attached to > the same diff, and you can look at the differences between an arbitrary pair > of revisions in the UI. So at any point we can see the whole diff, or just > what you changed in the latest revision. > > As Edward mentioned, in Phabricator you make multiple comments and then > submit them all together (which sends a single email to the reviewers). To > get to the submit button quickly, hit 'z'. > > Cheers > Simon > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simonpj at microsoft.com Mon Nov 2 13:15:55 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 2 Nov 2015 13:15:55 +0000 Subject: process library broken on Windows Message-ID: I'm getting this on HEAD in te ' libraries\process\System\Process\Internals.hs:106:16: warning: Defined but not used: data constructor 'CGid' Indeed it looks as if CGId(..) should be exported, else createProcess is unusuable. This looks like the right change. Would someone like to check and make the change Simon diff --git a/System/Process/Internals.hs b/System/Process/Internals.hs index 5575ac4..3e23ad5 100644 --- a/System/Process/Internals.hs +++ b/System/Process/Internals.hs @@ -37,6 +37,8 @@ module System.Process.Internals ( #if !defined(mingw32_HOST_OS) && !defined(__MINGW32__) pPrPr_disableITimers, c_execvpe, ignoreSignal, defaultSignal, +#else + CGid(..), GroupID, UserID, #endif withFilePathException, withCEnvironment, translate, -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Mon Nov 2 13:17:16 2015 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 2 Nov 2015 05:17:16 -0800 Subject: process library broken on Windows In-Reply-To: References: Message-ID: I'll look into this. I just made a new release of process, and was certain I tested on Windows, but perhaps something changed between that commit and release. On Mon, Nov 2, 2015 at 5:15 AM, Simon Peyton Jones wrote: > I?m getting this on HEAD in te ? > > libraries\process\System\Process\Internals.hs:106:16: warning: > > Defined but not used: data constructor ?CGid? > > Indeed it looks as if CGId(..) should be exported, else createProcess is > unusuable. This looks like the right change. Would someone like to check > and make the change > > Simon > > diff --git a/System/Process/Internals.hs b/System/Process/Internals.hs > > index 5575ac4..3e23ad5 100644 > > --- a/System/Process/Internals.hs > > +++ b/System/Process/Internals.hs > > @@ -37,6 +37,8 @@ module System.Process.Internals ( > > #if !defined(mingw32_HOST_OS) && !defined(__MINGW32__) > > pPrPr_disableITimers, c_execvpe, > > ignoreSignal, defaultSignal, > > +#else > > + CGid(..), GroupID, UserID, > > #endif > > withFilePathException, withCEnvironment, > > translate, > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Mon Nov 2 13:33:49 2015 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 2 Nov 2015 05:33:49 -0800 Subject: process library broken on Windows In-Reply-To: References: Message-ID: I didn't read closely enough: I see now that it's a warning, not an error. I initially didn't export that constructor since it's only present on Windows for API compatibility, but will never be used. Since this is just the internals module, I can export it, but my preference would in fact be to leave it as-is with the warning. Two alternatives: 1. Create a new hidden module that creates and exports the type constructor, just to hide the warning. I'm -1 on that, since that's extra compile time everyone has to endure just for warning avoidance. 2. base could export CGid for Windows (currently, it does not). On Mon, Nov 2, 2015 at 5:17 AM, Michael Snoyman wrote: > I'll look into this. I just made a new release of process, and was certain > I tested on Windows, but perhaps something changed between that commit and > release. > > On Mon, Nov 2, 2015 at 5:15 AM, Simon Peyton Jones > wrote: > >> I?m getting this on HEAD in te ? >> >> libraries\process\System\Process\Internals.hs:106:16: warning: >> >> Defined but not used: data constructor ?CGid? >> >> Indeed it looks as if CGId(..) should be exported, else createProcess is >> unusuable. This looks like the right change. Would someone like to check >> and make the change >> >> Simon >> >> diff --git a/System/Process/Internals.hs b/System/Process/Internals.hs >> >> index 5575ac4..3e23ad5 100644 >> >> --- a/System/Process/Internals.hs >> >> +++ b/System/Process/Internals.hs >> >> @@ -37,6 +37,8 @@ module System.Process.Internals ( >> >> #if !defined(mingw32_HOST_OS) && !defined(__MINGW32__) >> >> pPrPr_disableITimers, c_execvpe, >> >> ignoreSignal, defaultSignal, >> >> +#else >> >> + CGid(..), GroupID, UserID, >> >> #endif >> >> withFilePathException, withCEnvironment, >> >> translate, >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Nov 2 13:37:13 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 2 Nov 2015 13:37:13 +0000 Subject: process library broken on Windows In-Reply-To: References: Message-ID: I?m puzzled. Internals.hs defines a newtype newtype CGid = CGid Word32 A value of this type is needed to fill in the child_group field of CreateProcess. If you don?t export it, you could never initialise this field to anything other than Nothing, so why do you have it? Looks to me as if the warning has nailed a real bug Simon From: michael.snoyman at gmail.com [mailto:michael.snoyman at gmail.com] On Behalf Of Michael Snoyman Sent: 02 November 2015 13:34 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: process library broken on Windows I didn't read closely enough: I see now that it's a warning, not an error. I initially didn't export that constructor since it's only present on Windows for API compatibility, but will never be used. Since this is just the internals module, I can export it, but my preference would in fact be to leave it as-is with the warning. Two alternatives: 1. Create a new hidden module that creates and exports the type constructor, just to hide the warning. I'm -1 on that, since that's extra compile time everyone has to endure just for warning avoidance. 2. base could export CGid for Windows (currently, it does not). On Mon, Nov 2, 2015 at 5:17 AM, Michael Snoyman > wrote: I'll look into this. I just made a new release of process, and was certain I tested on Windows, but perhaps something changed between that commit and release. On Mon, Nov 2, 2015 at 5:15 AM, Simon Peyton Jones > wrote: I?m getting this on HEAD in te ? libraries\process\System\Process\Internals.hs:106:16: warning: Defined but not used: data constructor ?CGid? Indeed it looks as if CGId(..) should be exported, else createProcess is unusuable. This looks like the right change. Would someone like to check and make the change Simon diff --git a/System/Process/Internals.hs b/System/Process/Internals.hs index 5575ac4..3e23ad5 100644 --- a/System/Process/Internals.hs +++ b/System/Process/Internals.hs @@ -37,6 +37,8 @@ module System.Process.Internals ( #if !defined(mingw32_HOST_OS) && !defined(__MINGW32__) pPrPr_disableITimers, c_execvpe, ignoreSignal, defaultSignal, +#else + CGid(..), GroupID, UserID, #endif withFilePathException, withCEnvironment, translate, _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Mon Nov 2 13:42:18 2015 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 2 Nov 2015 05:42:18 -0800 Subject: process library broken on Windows In-Reply-To: References: Message-ID: That's the goal; it's a feature that does not work on Windows, only on non-Windows systems (setuid/setgid for a child process). For POSIX systems, CGid is exported from base, and can be used. On Windows, the data type is present to give the same signature, but the constructor itself is not exported to prevent using the feature. An argument could be made for other approaches: 1. Expose the constructor, allowing users to set a value, and that value will be ignored 2. Make the fields themselves conditional on the OS being used I don't think there's a strong argument in any direction for this. On Mon, Nov 2, 2015 at 5:37 AM, Simon Peyton Jones wrote: > I?m puzzled. Internals.hs defines a newtype > > > > newtype CGid = CGid Word32 > > > > A value of this type is needed to fill in the child_group field of > CreateProcess. If you don?t export it, you could never initialise this > field to anything other than Nothing, so why do you have it? > > > > Looks to me as if the warning has nailed a real bug > > > > Simon > > > > *From:* michael.snoyman at gmail.com [mailto:michael.snoyman at gmail.com] *On > Behalf Of *Michael Snoyman > *Sent:* 02 November 2015 13:34 > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: process library broken on Windows > > > > I didn't read closely enough: I see now that it's a warning, not an error. > I initially didn't export that constructor since it's only present on > Windows for API compatibility, but will never be used. Since this is just > the internals module, I can export it, but my preference would in fact be > to leave it as-is with the warning. Two alternatives: > > > > 1. Create a new hidden module that creates and exports the type > constructor, just to hide the warning. I'm -1 on that, since that's extra > compile time everyone has to endure just for warning avoidance. > > 2. base could export CGid for Windows (currently, it does not). > > > > On Mon, Nov 2, 2015 at 5:17 AM, Michael Snoyman > wrote: > > I'll look into this. I just made a new release of process, and was certain > I tested on Windows, but perhaps something changed between that commit and > release. > > > > On Mon, Nov 2, 2015 at 5:15 AM, Simon Peyton Jones > wrote: > > I?m getting this on HEAD in te ? > > libraries\process\System\Process\Internals.hs:106:16: warning: > > Defined but not used: data constructor ?CGid? > > Indeed it looks as if CGId(..) should be exported, else createProcess is > unusuable. This looks like the right change. Would someone like to check > and make the change > > Simon > > diff --git a/System/Process/Internals.hs b/System/Process/Internals.hs > > index 5575ac4..3e23ad5 100644 > > --- a/System/Process/Internals.hs > > +++ b/System/Process/Internals.hs > > @@ -37,6 +37,8 @@ module System.Process.Internals ( > > #if !defined(mingw32_HOST_OS) && !defined(__MINGW32__) > > pPrPr_disableITimers, c_execvpe, > > ignoreSignal, defaultSignal, > > +#else > > + CGid(..), GroupID, UserID, > > #endif > > withFilePathException, withCEnvironment, > > translate, > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Nov 2 13:57:08 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 2 Nov 2015 13:57:08 +0000 Subject: process library broken on Windows In-Reply-To: References: Message-ID: Aha. It would be great to say all that in the source code!! It?s very non-obvious that you not want people ever to construct a CGId on Windows. After all, it has a newtype definition! Could you declare it differently? data CGId -- No constructors Also if so, why does the Windows-specific foreign import of c_runInteractiveProcess (lin 440-is) pas a Ptr CGId? You?d just told me that we can never create one. Also, ? It?d help to comment the #else on line 456 as being ?else if not windows? ? The #endifs on line 546 or thereabouts are mis-labelled. at the moment the second says ?GLASGOW_HASKELL? but actually it?s the first I have no opinion about the best solution; I?d just like it to compile and preferably warning free since that is our default policy. Or add a ?Wwarn at the top. thanks Simon From: michael.snoyman at gmail.com [mailto:michael.snoyman at gmail.com] On Behalf Of Michael Snoyman Sent: 02 November 2015 13:42 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: process library broken on Windows That's the goal; it's a feature that does not work on Windows, only on non-Windows systems (setuid/setgid for a child process). For POSIX systems, CGid is exported from base, and can be used. On Windows, the data type is present to give the same signature, but the constructor itself is not exported to prevent using the feature. An argument could be made for other approaches: 1. Expose the constructor, allowing users to set a value, and that value will be ignored 2. Make the fields themselves conditional on the OS being used I don't think there's a strong argument in any direction for this. On Mon, Nov 2, 2015 at 5:37 AM, Simon Peyton Jones > wrote: I?m puzzled. Internals.hs defines a newtype newtype CGid = CGid Word32 A value of this type is needed to fill in the child_group field of CreateProcess. If you don?t export it, you could never initialise this field to anything other than Nothing, so why do you have it? Looks to me as if the warning has nailed a real bug Simon From: michael.snoyman at gmail.com [mailto:michael.snoyman at gmail.com] On Behalf Of Michael Snoyman Sent: 02 November 2015 13:34 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: process library broken on Windows I didn't read closely enough: I see now that it's a warning, not an error. I initially didn't export that constructor since it's only present on Windows for API compatibility, but will never be used. Since this is just the internals module, I can export it, but my preference would in fact be to leave it as-is with the warning. Two alternatives: 1. Create a new hidden module that creates and exports the type constructor, just to hide the warning. I'm -1 on that, since that's extra compile time everyone has to endure just for warning avoidance. 2. base could export CGid for Windows (currently, it does not). On Mon, Nov 2, 2015 at 5:17 AM, Michael Snoyman > wrote: I'll look into this. I just made a new release of process, and was certain I tested on Windows, but perhaps something changed between that commit and release. On Mon, Nov 2, 2015 at 5:15 AM, Simon Peyton Jones > wrote: I?m getting this on HEAD in te ? libraries\process\System\Process\Internals.hs:106:16: warning: Defined but not used: data constructor ?CGid? Indeed it looks as if CGId(..) should be exported, else createProcess is unusuable. This looks like the right change. Would someone like to check and make the change Simon diff --git a/System/Process/Internals.hs b/System/Process/Internals.hs index 5575ac4..3e23ad5 100644 --- a/System/Process/Internals.hs +++ b/System/Process/Internals.hs @@ -37,6 +37,8 @@ module System.Process.Internals ( #if !defined(mingw32_HOST_OS) && !defined(__MINGW32__) pPrPr_disableITimers, c_execvpe, ignoreSignal, defaultSignal, +#else + CGid(..), GroupID, UserID, #endif withFilePathException, withCEnvironment, translate, _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Mon Nov 2 14:14:52 2015 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 2 Nov 2015 06:14:52 -0800 Subject: process library broken on Windows In-Reply-To: References: Message-ID: On Mon, Nov 2, 2015 at 5:57 AM, Simon Peyton Jones wrote: > Aha. It would be great to say all that in the source code!! It?s very > non-obvious that you not want people ever to construct a CGId on Windows. > After all, it has a newtype definition! > > > Good call, I'll update with some comments (though see refactoring comments below). > Could you declare it differently? > > data CGId -- No constructors > > Certainly we could. Then the question would be "why does the Windows code look so different?" There are lots of colors to this bikeshed, and I don't have any particular affinity to any of them. If you'd prefer it looked that way, I can make that change. I initially erred with making the code as similar to the POSIX code as possible. > > > Also if so, why does the Windows-specific foreign import of > c_runInteractiveProcess (lin 440-is) pas a Ptr CGId? You?d just told me > that we can never create one. > > The Windows-specific foreign import is on line ~533, and does not include those arguments. > > > Also, > > ? It?d help to comment the #else on line 456 as being ?else if > not windows? > > ? The #endifs on line 546 or thereabouts are mis-labelled. at > the moment the second says ?GLASGOW_HASKELL? but actually it?s the first > > Agreed that the code is fairly difficult to follow with the nested ifdefs. However, instead of trying to salvage that, it's probably worth a refactoring to put the Windows and POSIX code into separate modules and then just import those conditionally. > > > I have no opinion about the best solution; I?d just like it to compile and > preferably warning free since that is our default policy. Or add a ?Wwarn > at the top. > > If you're looking for a short-term solution, I can add -Wwarn to the top until some kind of refactoring takes place. > > > thanks > > > > Simon > > > > > > *From:* michael.snoyman at gmail.com [mailto:michael.snoyman at gmail.com] *On > Behalf Of *Michael Snoyman > *Sent:* 02 November 2015 13:42 > > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: process library broken on Windows > > > > That's the goal; it's a feature that does not work on Windows, only on > non-Windows systems (setuid/setgid for a child process). For POSIX systems, > CGid is exported from base, and can be used. On Windows, the data type is > present to give the same signature, but the constructor itself is not > exported to prevent using the feature. An argument could be made for other > approaches: > > > > 1. Expose the constructor, allowing users to set a value, and that value > will be ignored > > 2. Make the fields themselves conditional on the OS being used > > > > I don't think there's a strong argument in any direction for this. > > > > On Mon, Nov 2, 2015 at 5:37 AM, Simon Peyton Jones > wrote: > > I?m puzzled. Internals.hs defines a newtype > > > > newtype CGid = CGid Word32 > > > > A value of this type is needed to fill in the child_group field of > CreateProcess. If you don?t export it, you could never initialise this > field to anything other than Nothing, so why do you have it? > > > > Looks to me as if the warning has nailed a real bug > > > > Simon > > > > *From:* michael.snoyman at gmail.com [mailto:michael.snoyman at gmail.com] *On > Behalf Of *Michael Snoyman > *Sent:* 02 November 2015 13:34 > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: process library broken on Windows > > > > I didn't read closely enough: I see now that it's a warning, not an error. > I initially didn't export that constructor since it's only present on > Windows for API compatibility, but will never be used. Since this is just > the internals module, I can export it, but my preference would in fact be > to leave it as-is with the warning. Two alternatives: > > > > 1. Create a new hidden module that creates and exports the type > constructor, just to hide the warning. I'm -1 on that, since that's extra > compile time everyone has to endure just for warning avoidance. > > 2. base could export CGid for Windows (currently, it does not). > > > > On Mon, Nov 2, 2015 at 5:17 AM, Michael Snoyman > wrote: > > I'll look into this. I just made a new release of process, and was certain > I tested on Windows, but perhaps something changed between that commit and > release. > > > > On Mon, Nov 2, 2015 at 5:15 AM, Simon Peyton Jones > wrote: > > I?m getting this on HEAD in te ? > > libraries\process\System\Process\Internals.hs:106:16: warning: > > Defined but not used: data constructor ?CGid? > > Indeed it looks as if CGId(..) should be exported, else createProcess is > unusuable. This looks like the right change. Would someone like to check > and make the change > > Simon > > diff --git a/System/Process/Internals.hs b/System/Process/Internals.hs > > index 5575ac4..3e23ad5 100644 > > --- a/System/Process/Internals.hs > > +++ b/System/Process/Internals.hs > > @@ -37,6 +37,8 @@ module System.Process.Internals ( > > #if !defined(mingw32_HOST_OS) && !defined(__MINGW32__) > > pPrPr_disableITimers, c_execvpe, > > ignoreSignal, defaultSignal, > > +#else > > + CGid(..), GroupID, UserID, > > #endif > > withFilePathException, withCEnvironment, > > translate, > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rrnewton at gmail.com Mon Nov 2 14:37:13 2015 From: rrnewton at gmail.com (Ryan Newton) Date: Mon, 2 Nov 2015 09:37:13 -0500 Subject: Better calling conventions for strict functions (bang patterns)? In-Reply-To: <56362A31.5020307@gmail.com> References: <56362A31.5020307@gmail.com> Message-ID: Thanks Simon for linking that issue! Does the patch linked there already cover what you suggested in your last mail? I think no, it's a more limited change, but I'm having trouble understanding exactly what. I've also got one really basic question -- was it decided long ago that all these stack limit checks are cheaper than having a guard page at the end of each stack and faulting to grow the stack? (I couldn't find a place that this rationale was described on wiki.) Best, -Ryan On Sun, Nov 1, 2015 at 10:05 AM, Simon Marlow wrote: > Yes, I think we can probably do a better job of compiling case > expressions. The current compilation strategy optimises for code size, but > at the expense of performance in the fast path. We can tweak this > tradeoff, perhaps under the control of a flag. > > Ideally the sequence should start by assuming that the closure is already > evaluated, e.g. > > loop: > tag = R2 & 7; > if (tag == 1) then // code for [] > else if (tag == 2) then // code for (:) > else evaluate; jump back to loop > > The nice thing is that now that we don't need proc points, "loop" is just > a label that we can directly jump to. Unfortunately this only works when > using the NCG, not with LLVM, because LLVM requires proc points, so we > might need to fall back to a different strategy for LLVM. > > Similar topics came up here: https://ghc.haskell.org/trac/ghc/ticket/8905 > and I think there was another ticket but I can't find it now. > > Cheers > Simon > > On 23/10/2015 19:00, Ryan Newton wrote: > >> 1. Small tweaks: The CMM code above seems to be /betting/ than the >> thunk is unevaluated, because it does the stack check and stack >> write /before/ the predicate test that checks if the thunk is >> evaluated (if(R1 & 7!= 0) gotoc3aO; elsegotoc3aP;). With a >> bang-pattern function, couldn't it make the opposite bet? That >> is, branch on whether the thunk is evaluated first, and then the >> wasted computation is only a single correctly predicted branch >> (and a read of a tag that we need to read anyway). >> >> Oh, a small further addition would be needed for this tweak. In the >> generated code above "Sp = Sp + 8;" happens /late/, but I think it could >> happen right after the call to the thunk. In general, does it seem >> feasible to separate the slowpath from fastpath as in the following >> tweak of the example CMM? >> >> >> * // Skip to the chase if it's already evaluated:* >> * start:* >> * if (R2 & 7 != 0) goto fastpath; else goto slowpath;* >> * >> * >> * slowpath: // Formerly c3aY* >> * if ((Sp + -8) < SpLim) goto c3aZ; else goto c3b0;* >> * c3aZ:* >> * // nop* >> * R1 = PicBaseReg + foo_closure;* >> * call (I64[BaseReg - 8])(R2, R1) args: 8, res: 0, upd: 8;* >> * c3b0:* >> * I64[Sp - 8] = PicBaseReg + block_c3aO_info;* >> * R1 = R2;* >> * Sp = Sp - 8;* >> >> * call (I64[R1])(R1) returns to fastpath, args: 8, res: 8, upd: 8;* >> * // Sp bump moved to here so it's separate from "fastpath"* >> * Sp = Sp + 8;* >> * >> * >> * fastpath: // Formerly c3aO* >> * if (R1 & 7 >= 2) goto c3aW; else goto c3aX;* >> * c3aW:* >> * R1 = P64[R1 + 6] & (-8);* >> * call (I64[R1])(R1) args: 8, res: 0, upd: 8;* >> * c3aX:* >> * R1 = PicBaseReg + lvl_r39S_closure;* >> * call (I64[R1])(R1) args: 8, res: 0, upd: 8;* >> >> >> >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Mon Nov 2 14:44:41 2015 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 2 Nov 2015 06:44:41 -0800 Subject: process library broken on Windows In-Reply-To: References: Message-ID: <563776D9.1000404@gmail.com> -Wwarn shouldn't really be in source code. Since it's an Internals module, I would just export it. Maybe add a {-# WARNING #-} to discourage people from using it. Cheers Simon On 02/11/2015 06:14, Michael Snoyman wrote: > > > On Mon, Nov 2, 2015 at 5:57 AM, Simon Peyton Jones > > wrote: > > Aha. It would be great to say all that in the source code!! It?s > very non-obvious that you not want people ever to construct a CGId > on Windows. After all, it has a newtype definition!____ > > __ > > > Good call, I'll update with some comments (though see refactoring > comments below). > > __ > > Could you declare it differently?____ > > data CGId -- No constructors____ > > __ > > > Certainly we could. Then the question would be "why does the Windows > code look so different?" There are lots of colors to this bikeshed, and > I don't have any particular affinity to any of them. If you'd prefer it > looked that way, I can make that change. I initially erred with making > the code as similar to the POSIX code as possible. > > __ > > Also if so, why does the Windows-specific foreign import of > c_runInteractiveProcess (lin 440-is) pas a Ptr CGId? You?d just told > me that we can never create one.____ > > __ > > > > The Windows-specific foreign import is on line ~533, and does not > include those arguments. > > __ > > Also, ____ > > __?__It?d help to comment the #else on line 456 as being ?else if > not windows?____ > > __?__The #endifs on line 546 or thereabouts are mis-labelled. at > the moment the second says ?GLASGOW_HASKELL? but actually it?s the > first____ > > __ > > > > Agreed that the code is fairly difficult to follow with the nested > ifdefs. However, instead of trying to salvage that, it's probably worth > a refactoring to put the Windows and POSIX code into separate modules > and then just import those conditionally. > > __ > > I have no opinion about the best solution; I?d just like it to > compile and preferably warning free since that is our default > policy. Or add a ?Wwarn at the top.____ > > __ > > > If you're looking for a short-term solution, I can add -Wwarn to the top > until some kind of refactoring takes place. > > __ > > thanks____ > > __ __ > > Simon____ > > __ __ > > __ __ > > *From:*michael.snoyman at gmail.com > [mailto:michael.snoyman at gmail.com > ] *On Behalf Of *Michael Snoyman > *Sent:* 02 November 2015 13:42 > > > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: process library broken on Windows____ > > __ __ > > That's the goal; it's a feature that does not work on Windows, only > on non-Windows systems (setuid/setgid for a child process). For > POSIX systems, CGid is exported from base, and can be used. On > Windows, the data type is present to give the same signature, but > the constructor itself is not exported to prevent using the feature. > An argument could be made for other approaches:____ > > __ __ > > 1. Expose the constructor, allowing users to set a value, and that > value will be ignored____ > > 2. Make the fields themselves conditional on the OS being used____ > > __ __ > > I don't think there's a strong argument in any direction for this.____ > > __ __ > > On Mon, Nov 2, 2015 at 5:37 AM, Simon Peyton Jones > > wrote:____ > > I?m puzzled. Internals.hs defines a newtype____ > > ____ > > newtype CGid = CGid Word32____ > > ____ > > A value of this type is needed to fill in the child_group field > of CreateProcess. If you don?t export it, you could never > initialise this field to anything other than Nothing, so why do > you have it?____ > > ____ > > Looks to me as if the warning has nailed a real bug____ > > ____ > > Simon____ > > ____ > > *From:*michael.snoyman at gmail.com > > [mailto:michael.snoyman at gmail.com > ] *On Behalf Of *Michael Snoyman > *Sent:* 02 November 2015 13:34 > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: process library broken on Windows____ > > ____ > > I didn't read closely enough: I see now that it's a warning, not > an error. I initially didn't export that constructor since it's > only present on Windows for API compatibility, but will never be > used. Since this is just the internals module, I can export it, > but my preference would in fact be to leave it as-is with the > warning. Two alternatives:____ > > ____ > > 1. Create a new hidden module that creates and exports the type > constructor, just to hide the warning. I'm -1 on that, since > that's extra compile time everyone has to endure just for > warning avoidance.____ > > 2. base could export CGid for Windows (currently, it does not).____ > > ____ > > On Mon, Nov 2, 2015 at 5:17 AM, Michael Snoyman > > wrote:____ > > I'll look into this. I just made a new release of process, > and was certain I tested on Windows, but perhaps something > changed between that commit and release.____ > > ____ > > On Mon, Nov 2, 2015 at 5:15 AM, Simon Peyton Jones > > > wrote:____ > > I?m getting this on HEAD in te ?____ > > libraries\process\System\Process\Internals.hs:106:16: > warning:____ > > Defined but not used: data constructor ?CGid?____ > > Indeed it looks as if CGId(..) should be exported, else > createProcess is unusuable. This looks like the right > change. Would someone like to check and make the change____ > > Simon____ > > diff --git a/System/Process/Internals.hs > b/System/Process/Internals.hs____ > > index 5575ac4..3e23ad5 100644____ > > --- a/System/Process/Internals.hs____ > > +++ b/System/Process/Internals.hs____ > > @@ -37,6 +37,8 @@ module System.Process.Internals (____ > > #if !defined(mingw32_HOST_OS) && !defined(__MINGW32__)____ > > pPrPr_disableITimers, c_execvpe,____ > > ignoreSignal, defaultSignal,____ > > +#else____ > > + CGid(..), GroupID, UserID,____ > > #endif____ > > withFilePathException, withCEnvironment,____ > > translate,____ > > ____ > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ____ > > ____ > > ____ > > __ __ > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From marlowsd at gmail.com Mon Nov 2 14:55:15 2015 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 2 Nov 2015 06:55:15 -0800 Subject: Better calling conventions for strict functions (bang patterns)? In-Reply-To: References: <56362A31.5020307@gmail.com> Message-ID: <56377953.8020205@gmail.com> On 02/11/2015 06:37, Ryan Newton wrote: > Thanks Simon for linking that issue! Does the patch linked there > already > cover what you suggested in your last mail? I think no, it's a more > limited change, but I'm having trouble understanding exactly what. > > I've also got one really basic question -- was it decided long ago that > all these stack limit checks are cheaper than having a guard page at the > end of each stack and faulting to grow the stack? (I couldn't find a > place that this rationale was described on wiki.) Stacks would be immovable, and you need to arrange that you have enough address space to grow the stack if necessary, just like OS threads. Thus it's not really feasible on 32-bit platforms, and we would have to keep the existing stack-chunk mechanism for those platforms. Right now stacks start at 1k and are really cheap; they'd be somewhat more expensive under this scheme: at least 4K and a couple of mmap() calls. Stack chunks have another benefit: we can track whether each chunk is dirty separately, and only traverse dirty chunks in the GC. I don't think you'd be able to do this with contiguous stacks and no stack checks. Cheers Simon > > Best, > -Ryan > > > On Sun, Nov 1, 2015 at 10:05 AM, Simon Marlow > wrote: > > Yes, I think we can probably do a better job of compiling case > expressions. The current compilation strategy optimises for code > size, but at the expense of performance in the fast path. We can > tweak this tradeoff, perhaps under the control of a flag. > > Ideally the sequence should start by assuming that the closure is > already evaluated, e.g. > > loop: > tag = R2 & 7; > if (tag == 1) then // code for [] > else if (tag == 2) then // code for (:) > else evaluate; jump back to loop > > The nice thing is that now that we don't need proc points, "loop" is > just a label that we can directly jump to. Unfortunately this only > works when using the NCG, not with LLVM, because LLVM requires proc > points, so we might need to fall back to a different strategy for LLVM. > > Similar topics came up here: > https://ghc.haskell.org/trac/ghc/ticket/8905 and I think there was > another ticket but I can't find it now. > > Cheers > Simon > > On 23/10/2015 19:00, Ryan Newton wrote: > > 1. Small tweaks: The CMM code above seems to be /betting/ > than the > thunk is unevaluated, because it does the stack check > and stack > write /before/ the predicate test that checks if the > thunk is > evaluated (if(R1 & 7!= 0) gotoc3aO; elsegotoc3aP;). With a > bang-pattern function, couldn't it make the opposite > bet? That > is, branch on whether the thunk is evaluated first, and > then the > wasted computation is only a single correctly predicted > branch > (and a read of a tag that we need to read anyway). > > Oh, a small further addition would be needed for this tweak. In the > generated code above "Sp = Sp + 8;" happens /late/, but I think > it could > happen right after the call to the thunk. In general, does it seem > feasible to separate the slowpath from fastpath as in the following > tweak of the example CMM? > > > * // Skip to the chase if it's already evaluated:* > * start:* > * if (R2 & 7 != 0) goto fastpath; else goto slowpath;* > * > * > * slowpath: // Formerly c3aY* > * if ((Sp + -8) < SpLim) goto c3aZ; else goto c3b0;* > * c3aZ:* > * // nop* > * R1 = PicBaseReg + foo_closure;* > * call (I64[BaseReg - 8])(R2, R1) args: 8, res: 0, upd: 8;* > * c3b0:* > * I64[Sp - 8] = PicBaseReg + block_c3aO_info;* > * R1 = R2;* > * Sp = Sp - 8;* > > * call (I64[R1])(R1) returns to fastpath, args: 8, res: 8, > upd: 8;* > * // Sp bump moved to here so it's separate from "fastpath"* > * Sp = Sp + 8;* > * > * > * fastpath: // Formerly c3aO* > * if (R1 & 7 >= 2) goto c3aW; else goto c3aX;* > * c3aW:* > * R1 = P64[R1 + 6] & (-8);* > * call (I64[R1])(R1) args: 8, res: 0, upd: 8;* > * c3aX:* > * R1 = PicBaseReg + lvl_r39S_closure;* > * call (I64[R1])(R1) args: 8, res: 0, upd: 8;* > > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > From marlowsd at gmail.com Mon Nov 2 14:58:26 2015 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 2 Nov 2015 06:58:26 -0800 Subject: Better calling conventions for strict functions (bang patterns)? In-Reply-To: References: <56362A31.5020307@gmail.com> Message-ID: <56377A12.3080806@gmail.com> Sorry, forgot to respond to your other point: On 02/11/2015 06:37, Ryan Newton wrote: > Thanks Simon for linking that issue! Does the patch linked there > already > cover what you suggested in your last mail? I think no, it's a more > limited change, but I'm having trouble understanding exactly what. Correct, it's a more limited change. I don't have a working implementation of the scheme I described, it needs some reorganisation in the codeGen if I remember correctly. Something I think we should do is to have a gcc-like -Os flag that we could use as a hint in cases where we have a code-size vs speed tradeoff like this, there are a handful of places we could use that. Cheers Simon > I've also got one really basic question -- was it decided long ago that > all these stack limit checks are cheaper than having a guard page at the > end of each stack and faulting to grow the stack? (I couldn't find a > place that this rationale was described on wiki.) > > Best, > -Ryan > > > On Sun, Nov 1, 2015 at 10:05 AM, Simon Marlow > wrote: > > Yes, I think we can probably do a better job of compiling case > expressions. The current compilation strategy optimises for code > size, but at the expense of performance in the fast path. We can > tweak this tradeoff, perhaps under the control of a flag. > > Ideally the sequence should start by assuming that the closure is > already evaluated, e.g. > > loop: > tag = R2 & 7; > if (tag == 1) then // code for [] > else if (tag == 2) then // code for (:) > else evaluate; jump back to loop > > The nice thing is that now that we don't need proc points, "loop" is > just a label that we can directly jump to. Unfortunately this only > works when using the NCG, not with LLVM, because LLVM requires proc > points, so we might need to fall back to a different strategy for LLVM. > > Similar topics came up here: > https://ghc.haskell.org/trac/ghc/ticket/8905 and I think there was > another ticket but I can't find it now. > > Cheers > Simon > > On 23/10/2015 19:00, Ryan Newton wrote: > > 1. Small tweaks: The CMM code above seems to be /betting/ > than the > thunk is unevaluated, because it does the stack check > and stack > write /before/ the predicate test that checks if the > thunk is > evaluated (if(R1 & 7!= 0) gotoc3aO; elsegotoc3aP;). With a > bang-pattern function, couldn't it make the opposite > bet? That > is, branch on whether the thunk is evaluated first, and > then the > wasted computation is only a single correctly predicted > branch > (and a read of a tag that we need to read anyway). > > Oh, a small further addition would be needed for this tweak. In the > generated code above "Sp = Sp + 8;" happens /late/, but I think > it could > happen right after the call to the thunk. In general, does it seem > feasible to separate the slowpath from fastpath as in the following > tweak of the example CMM? > > > * // Skip to the chase if it's already evaluated:* > * start:* > * if (R2 & 7 != 0) goto fastpath; else goto slowpath;* > * > * > * slowpath: // Formerly c3aY* > * if ((Sp + -8) < SpLim) goto c3aZ; else goto c3b0;* > * c3aZ:* > * // nop* > * R1 = PicBaseReg + foo_closure;* > * call (I64[BaseReg - 8])(R2, R1) args: 8, res: 0, upd: 8;* > * c3b0:* > * I64[Sp - 8] = PicBaseReg + block_c3aO_info;* > * R1 = R2;* > * Sp = Sp - 8;* > > * call (I64[R1])(R1) returns to fastpath, args: 8, res: 8, > upd: 8;* > * // Sp bump moved to here so it's separate from "fastpath"* > * Sp = Sp + 8;* > * > * > * fastpath: // Formerly c3aO* > * if (R1 & 7 >= 2) goto c3aW; else goto c3aX;* > * c3aW:* > * R1 = P64[R1 + 6] & (-8);* > * call (I64[R1])(R1) args: 8, res: 0, upd: 8;* > * c3aX:* > * R1 = PicBaseReg + lvl_r39S_closure;* > * call (I64[R1])(R1) args: 8, res: 0, upd: 8;* > > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > From ben at well-typed.com Mon Nov 2 16:03:18 2015 From: ben at well-typed.com (Ben Gamari) Date: Mon, 02 Nov 2015 17:03:18 +0100 Subject: [ANNOUNCE] GHC 7.10.3 release candidate 1 Message-ID: <87fv0o8k3d.fsf@smart-cactus.org> We are pleased to announce the first (and hopefully only) release candidate for GHC 7.10.3: https://downloads.haskell.org/~ghc/7.10.3-rc1/ This includes the source tarball and bindists for 64-bit and 32-bit modern Linux (GMP 5.0 or later) and Windows. These binaries and tarballs have an accompanying SHA256SUMS file signed by my GPG key id (0x97DB64AD). As always, our content delivery network tends to be a bit slow on the uptake. If you see an empty directory at this URL just add a few superfluous slashes to the end; this is typically enough to fool it. The 7.10.2 release 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. The one exception to this is an upgrade of the Windows compiler toolchain to GCC 5.2. Windows users have been long suffering at the hand of our old toolchain (e.g. lack of response file support, #8596, and lack of SEH support) so we expect that this change should fix far more than breaks. We plan to make the 7.10.3 release sometime next week. Please test this as much as possible; bugs are much cheaper if we find them before the release and this will ideally be the last release of the 7.10 series. Happy testing, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From george.colpitts at gmail.com Mon Nov 2 18:18:40 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Mon, 2 Nov 2015 14:18:40 -0400 Subject: [ANNOUNCE] GHC 7.10.3 release candidate 1 In-Reply-To: <87fv0o8k3d.fsf@smart-cactus.org> References: <87fv0o8k3d.fsf@smart-cactus.org> Message-ID: Will there be a Mac release candidate also? Thanks George On Mon, Nov 2, 2015 at 12:03 PM, Ben Gamari wrote: > > We are pleased to announce the first (and hopefully only) release > candidate for GHC 7.10.3: > > https://downloads.haskell.org/~ghc/7.10.3-rc1/ > > This includes the source tarball and bindists for 64-bit and 32-bit > modern Linux (GMP 5.0 or later) and Windows. These binaries and tarballs > have an accompanying SHA256SUMS file signed by my GPG key id > (0x97DB64AD). As always, our content delivery network tends to be a bit > slow on the uptake. If you see an empty directory at this URL just add a > few superfluous slashes to the end; this is typically enough to fool it. > > The 7.10.2 release 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. > > The one exception to this is an upgrade of the Windows compiler > toolchain to GCC 5.2. Windows users have been long suffering at the hand > of our old toolchain (e.g. lack of response file support, #8596, and > lack of SEH support) so we expect that this change should fix far more > than breaks. > > We plan to make the 7.10.3 release sometime next week. > > Please test this as much as possible; bugs are much cheaper if we find > them before the release and this will ideally be the last release of the > 7.10 series. > > Happy testing, > > - Ben > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Mon Nov 2 18:21:31 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 2 Nov 2015 13:21:31 -0500 Subject: [ANNOUNCE] GHC 7.10.3 release candidate 1 In-Reply-To: References: <87fv0o8k3d.fsf@smart-cactus.org> Message-ID: <9CDB96CA-FCDC-47F9-AF19-F6E44CE75C1E@cis.upenn.edu> Personally, I would love delaying announcements such as these until binaries are available, at least for Linux, Mac, and Windows. Richard On Nov 2, 2015, at 1:18 PM, George Colpitts wrote: > Will there be a Mac release candidate also? > > Thanks > George > > > On Mon, Nov 2, 2015 at 12:03 PM, Ben Gamari wrote: > > We are pleased to announce the first (and hopefully only) release > candidate for GHC 7.10.3: > > https://downloads.haskell.org/~ghc/7.10.3-rc1/ > > This includes the source tarball and bindists for 64-bit and 32-bit > modern Linux (GMP 5.0 or later) and Windows. These binaries and tarballs > have an accompanying SHA256SUMS file signed by my GPG key id > (0x97DB64AD). As always, our content delivery network tends to be a bit > slow on the uptake. If you see an empty directory at this URL just add a > few superfluous slashes to the end; this is typically enough to fool it. > > The 7.10.2 release 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. > > The one exception to this is an upgrade of the Windows compiler > toolchain to GCC 5.2. Windows users have been long suffering at the hand > of our old toolchain (e.g. lack of response file support, #8596, and > lack of SEH support) so we expect that this change should fix far more > than breaks. > > We plan to make the 7.10.3 release sometime next week. > > Please test this as much as possible; bugs are much cheaper if we find > them before the release and this will ideally be the last release of the > 7.10 series. > > Happy testing, > > - Ben > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon Nov 2 18:27:23 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 02 Nov 2015 19:27:23 +0100 Subject: [ANNOUNCE] GHC 7.10.3 release candidate 1 In-Reply-To: <9CDB96CA-FCDC-47F9-AF19-F6E44CE75C1E@cis.upenn.edu> References: <87fv0o8k3d.fsf@smart-cactus.org> <9CDB96CA-FCDC-47F9-AF19-F6E44CE75C1E@cis.upenn.edu> Message-ID: <1446488843.1764.19.camel@joachim-breitner.de> Hi, Am Montag, den 02.11.2015, 13:21 -0500 schrieb Richard Eisenberg: > Personally, I would love delaying announcements such as these until > binaries are available, at least for Linux, Mac, and Windows. it?s a release candidate, announced on the developer mailing list. Isn?t such a mail a requirement for those wo build the various binaries to get active in the first place? Or is all done by Ben these days. I?m happy to get the announcement as quickly as possible, as I was waiting for the source tarball :-) Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From pali.gabor at gmail.com Mon Nov 2 19:46:54 2015 From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=) Date: Mon, 2 Nov 2015 20:46:54 +0100 Subject: [ANNOUNCE] GHC 7.10.3 release candidate 1 In-Reply-To: <1446488843.1764.19.camel@joachim-breitner.de> References: <87fv0o8k3d.fsf@smart-cactus.org> <9CDB96CA-FCDC-47F9-AF19-F6E44CE75C1E@cis.upenn.edu> <1446488843.1764.19.camel@joachim-breitner.de> Message-ID: 2015-11-02 19:27 GMT+01:00 Joachim Breitner : > Isn?t such a mail a requirement for those wo build the various binaries > to get active in the first place? I think that would require at least an accessible source tarball in the first place :-) But apparently there are no files under the specified directory. Cheers, G?bor From ben at well-typed.com Mon Nov 2 20:48:01 2015 From: ben at well-typed.com (Ben Gamari) Date: Mon, 02 Nov 2015 21:48:01 +0100 Subject: [ANNOUNCE] GHC 7.10.3 release candidate 1 In-Reply-To: <1446488843.1764.19.camel@joachim-breitner.de> References: <87fv0o8k3d.fsf@smart-cactus.org> <9CDB96CA-FCDC-47F9-AF19-F6E44CE75C1E@cis.upenn.edu> <1446488843.1764.19.camel@joachim-breitner.de> Message-ID: <87vb9k6sce.fsf@smart-cactus.org> Joachim Breitner writes: > Hi, > > Am Montag, den 02.11.2015, 13:21 -0500 schrieb Richard Eisenberg: >> Personally, I would love delaying announcements such as these until >> binaries are available, at least for Linux, Mac, and Windows. > > it?s a release candidate, announced on the developer mailing list. > Isn?t such a mail a requirement for those wo build the various binaries > to get active in the first place? Or is all done by Ben these days. > The Windows and Linux builds are done by me. The Mac situation is a bit more complicated as neither Austin nor I have access to an OS X machine. We are working on getting access to such a machine, but this takes time. Ideally, the first-tier platforms are supposed[1] to have a sponsor who is able to work with us to produce the builds and keep track of platform-specific issues. Sadly OS X has lacked such a person for some time. We've perhaps not broadcast the need for such a person loudly enough which is largely my fault. Regardless, it would be extremely helpful if someone familiar with OS X could step up to fill this role. To be clear, we certainly won't be cutting a 7.10.3 release until we know that the release candidate has been adequately tested on OS X. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Platforms -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ben at smart-cactus.org Mon Nov 2 20:49:53 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 02 Nov 2015 21:49:53 +0100 Subject: [ANNOUNCE] GHC 7.10.3 release candidate 1 In-Reply-To: References: <87fv0o8k3d.fsf@smart-cactus.org> <9CDB96CA-FCDC-47F9-AF19-F6E44CE75C1E@cis.upenn.edu> <1446488843.1764.19.camel@joachim-breitner.de> Message-ID: <87si4o6s9a.fsf@smart-cactus.org> P?li G?bor J?nos writes: > 2015-11-02 19:27 GMT+01:00 Joachim Breitner : >> Isn?t such a mail a requirement for those wo build the various binaries >> to get active in the first place? > > I think that would require at least an accessible source tarball in > the first place :-) But apparently there are no files under the > specified directory. > It may appear that way but this is merely an unfortunate side-effect of our content delivery network. Try adding some extra `/` characters to the URL, e.g., https://downloads.haskell.org/~ghc/7.10.3-rc1// This is usually enough to fool the CDN info refreshing. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From michael at snoyman.com Mon Nov 2 21:32:30 2015 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 2 Nov 2015 13:32:30 -0800 Subject: process library broken on Windows In-Reply-To: <563776D9.1000404@gmail.com> References: <563776D9.1000404@gmail.com> Message-ID: I'd rather not change the public API (even though it's an internal module) in a way we'll later undo to avoid a warning, when the code cleanup should achieve the goal without making that modification. I've pushed my changes to the less-cpp branch, if anyone wants to play with the changes thus far. I've also modified the Travis build to use -Wall -Werror, and added an AppVeyor Windows build that similarly uses -Werror. On Mon, Nov 2, 2015 at 6:44 AM, Simon Marlow wrote: > -Wwarn shouldn't really be in source code. Since it's an Internals > module, I would just export it. Maybe add a {-# WARNING #-} to discourage > people from using it. > > Cheers > Simon > > On 02/11/2015 06:14, Michael Snoyman wrote: > >> >> >> On Mon, Nov 2, 2015 at 5:57 AM, Simon Peyton Jones >> > wrote: >> >> Aha. It would be great to say all that in the source code!! It?s >> very non-obvious that you not want people ever to construct a CGId >> on Windows. After all, it has a newtype definition!____ >> >> __ >> >> >> Good call, I'll update with some comments (though see refactoring >> comments below). >> >> __ >> >> Could you declare it differently?____ >> >> data CGId -- No constructors____ >> >> __ >> >> >> Certainly we could. Then the question would be "why does the Windows >> code look so different?" There are lots of colors to this bikeshed, and >> I don't have any particular affinity to any of them. If you'd prefer it >> looked that way, I can make that change. I initially erred with making >> the code as similar to the POSIX code as possible. >> >> __ >> >> Also if so, why does the Windows-specific foreign import of >> c_runInteractiveProcess (lin 440-is) pas a Ptr CGId? You?d just told >> me that we can never create one.____ >> >> __ >> >> >> >> The Windows-specific foreign import is on line ~533, and does not >> include those arguments. >> >> __ >> >> Also, ____ >> >> __?__It?d help to comment the #else on line 456 as being ?else if >> not windows?____ >> >> __?__The #endifs on line 546 or thereabouts are mis-labelled. at >> the moment the second says ?GLASGOW_HASKELL? but actually it?s the >> first____ >> >> __ >> >> >> >> Agreed that the code is fairly difficult to follow with the nested >> ifdefs. However, instead of trying to salvage that, it's probably worth >> a refactoring to put the Windows and POSIX code into separate modules >> and then just import those conditionally. >> >> __ >> >> I have no opinion about the best solution; I?d just like it to >> compile and preferably warning free since that is our default >> policy. Or add a ?Wwarn at the top.____ >> >> __ >> >> >> If you're looking for a short-term solution, I can add -Wwarn to the top >> until some kind of refactoring takes place. >> >> __ >> >> thanks____ >> >> __ __ >> >> Simon____ >> >> __ __ >> >> __ __ >> >> *From:*michael.snoyman at gmail.com >> [mailto:michael.snoyman at gmail.com >> ] *On Behalf Of *Michael Snoyman >> *Sent:* 02 November 2015 13:42 >> >> >> *To:* Simon Peyton Jones >> *Cc:* ghc-devs at haskell.org >> *Subject:* Re: process library broken on Windows____ >> >> __ __ >> >> That's the goal; it's a feature that does not work on Windows, only >> on non-Windows systems (setuid/setgid for a child process). For >> POSIX systems, CGid is exported from base, and can be used. On >> Windows, the data type is present to give the same signature, but >> the constructor itself is not exported to prevent using the feature. >> An argument could be made for other approaches:____ >> >> __ __ >> >> 1. Expose the constructor, allowing users to set a value, and that >> value will be ignored____ >> >> 2. Make the fields themselves conditional on the OS being used____ >> >> __ __ >> >> I don't think there's a strong argument in any direction for this.____ >> >> __ __ >> >> On Mon, Nov 2, 2015 at 5:37 AM, Simon Peyton Jones >> > wrote:____ >> >> I?m puzzled. Internals.hs defines a newtype____ >> >> ____ >> >> newtype CGid = CGid Word32____ >> >> ____ >> >> A value of this type is needed to fill in the child_group field >> of CreateProcess. If you don?t export it, you could never >> initialise this field to anything other than Nothing, so why do >> you have it?____ >> >> ____ >> >> Looks to me as if the warning has nailed a real bug____ >> >> ____ >> >> Simon____ >> >> ____ >> >> *From:*michael.snoyman at gmail.com >> >> [mailto:michael.snoyman at gmail.com >> ] *On Behalf Of *Michael >> Snoyman >> *Sent:* 02 November 2015 13:34 >> *To:* Simon Peyton Jones >> *Cc:* ghc-devs at haskell.org >> *Subject:* Re: process library broken on Windows____ >> >> ____ >> >> I didn't read closely enough: I see now that it's a warning, not >> an error. I initially didn't export that constructor since it's >> only present on Windows for API compatibility, but will never be >> used. Since this is just the internals module, I can export it, >> but my preference would in fact be to leave it as-is with the >> warning. Two alternatives:____ >> >> ____ >> >> 1. Create a new hidden module that creates and exports the type >> constructor, just to hide the warning. I'm -1 on that, since >> that's extra compile time everyone has to endure just for >> warning avoidance.____ >> >> 2. base could export CGid for Windows (currently, it does >> not).____ >> >> ____ >> >> On Mon, Nov 2, 2015 at 5:17 AM, Michael Snoyman >> > wrote:____ >> >> I'll look into this. I just made a new release of process, >> and was certain I tested on Windows, but perhaps something >> changed between that commit and release.____ >> >> ____ >> >> On Mon, Nov 2, 2015 at 5:15 AM, Simon Peyton Jones >> > >> wrote:____ >> >> I?m getting this on HEAD in te ?____ >> >> libraries\process\System\Process\Internals.hs:106:16: >> warning:____ >> >> Defined but not used: data constructor ?CGid?____ >> >> Indeed it looks as if CGId(..) should be exported, else >> createProcess is unusuable. This looks like the right >> change. Would someone like to check and make the >> change____ >> >> Simon____ >> >> diff --git a/System/Process/Internals.hs >> b/System/Process/Internals.hs____ >> >> index 5575ac4..3e23ad5 100644____ >> >> --- a/System/Process/Internals.hs____ >> >> +++ b/System/Process/Internals.hs____ >> >> @@ -37,6 +37,8 @@ module System.Process.Internals (____ >> >> #if !defined(mingw32_HOST_OS) && !defined(__MINGW32__)____ >> >> pPrPr_disableITimers, c_execvpe,____ >> >> ignoreSignal, defaultSignal,____ >> >> +#else____ >> >> + CGid(..), GroupID, UserID,____ >> >> #endif____ >> >> withFilePathException, withCEnvironment,____ >> >> translate,____ >> >> ____ >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> < >> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cdd25a0d693de489171bb08d2e38a505d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=YdqpMC5wr2K6oUOw9WImRGpSl6EsV8zQyAK%2ba26oF9M%3d >> >____ >> >> ____ >> >> ____ >> >> __ __ >> >> >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Tue Nov 3 00:09:55 2015 From: austin at well-typed.com (Austin Seipp) Date: Mon, 2 Nov 2015 18:09:55 -0600 Subject: [ANNOUNCE] GHC 7.10.3 release candidate 1 In-Reply-To: <87si4o6s9a.fsf@smart-cactus.org> References: <87fv0o8k3d.fsf@smart-cactus.org> <9CDB96CA-FCDC-47F9-AF19-F6E44CE75C1E@cis.upenn.edu> <1446488843.1764.19.camel@joachim-breitner.de> <87si4o6s9a.fsf@smart-cactus.org> Message-ID: Yeah, I really need to work a trigger into the downloads machine so that we can clear the CDN cache when we upload/update files... It's about a mile down my TODO list though (since it bites somewhat rarely for these cases) - so anyone who wants to do a little JSON API chatting with Fastly should talk to me. :) On Mon, Nov 2, 2015 at 2:49 PM, Ben Gamari wrote: > P?li G?bor J?nos writes: > >> 2015-11-02 19:27 GMT+01:00 Joachim Breitner : >>> Isn?t such a mail a requirement for those wo build the various binaries >>> to get active in the first place? >> >> I think that would require at least an accessible source tarball in >> the first place :-) But apparently there are no files under the >> specified directory. >> > It may appear that way but this is merely an unfortunate side-effect of > our content delivery network. Try adding some extra `/` characters to > the URL, e.g., > > https://downloads.haskell.org/~ghc/7.10.3-rc1// > > This is usually enough to fool the CDN info refreshing. > > Cheers, > > - Ben > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Tue Nov 3 00:17:07 2015 From: austin at well-typed.com (Austin Seipp) Date: Mon, 2 Nov 2015 18:17:07 -0600 Subject: [ANNOUNCE] GHC 7.10.3 release candidate 1 In-Reply-To: <1446488843.1764.19.camel@joachim-breitner.de> References: <87fv0o8k3d.fsf@smart-cactus.org> <9CDB96CA-FCDC-47F9-AF19-F6E44CE75C1E@cis.upenn.edu> <1446488843.1764.19.camel@joachim-breitner.de> Message-ID: Yeah, so in the past Tier 1 platforms (OS X, Win, Lin, FreeBSD) are always available, but I rarely (if ever) held up RCs for anything besides that. I do have a list of people to alert, though... (Karel takes care of Solaris for example as time permits). Even then, I wasn't always the one doing the builds... Gabor takes care of FreeBSD for me. And Mark was doing the OS X builds before, because he had an excellent test farm that allowed him to test a release across an array of OS X versions. Right now we're working on getting a Mac. I'll have short-term access to one by tomorrow thankfully, and be getting a new machine soon. So hopefully this won't be a problem going forward, although some knowledge transfer from Mark might be in order. :) On Mon, Nov 2, 2015 at 12:27 PM, Joachim Breitner wrote: > Hi, > > Am Montag, den 02.11.2015, 13:21 -0500 schrieb Richard Eisenberg: >> Personally, I would love delaying announcements such as these until >> binaries are available, at least for Linux, Mac, and Windows. > > it?s a release candidate, announced on the developer mailing list. > Isn?t such a mail a requirement for those wo build the various binaries > to get active in the first place? Or is all done by Ben these days. > > I?m happy to get the announcement as quickly as possible, as I was > waiting for the source tarball :-) > > Greetings, > Joachim > > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From pali.gabor at gmail.com Tue Nov 3 11:28:00 2015 From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=) Date: Tue, 3 Nov 2015 12:28:00 +0100 Subject: [ANNOUNCE] GHC 7.10.3 release candidate 1 In-Reply-To: References: <87fv0o8k3d.fsf@smart-cactus.org> <9CDB96CA-FCDC-47F9-AF19-F6E44CE75C1E@cis.upenn.edu> <1446488843.1764.19.camel@joachim-breitner.de> Message-ID: 2015-11-03 1:17 GMT+01:00 Austin Seipp : > Yeah, so in the past Tier 1 platforms (OS X, Win, Lin, FreeBSD) are > always available, but I rarely (if ever) held up RCs for anything > besides that. The FreeBSD bindists are available there: http://haskell.inf.elte.hu/ghc/ghc-7.10.2.20151030-i386-portbld-freebsd.tar.bz2 http://haskell.inf.elte.hu/ghc/ghc-7.10.2.20151030-i386-portbld-freebsd.tar.xz http://haskell.inf.elte.hu/ghc/ghc-7.10.2.20151030-x86_64-portbld-freebsd.tar.bz2 http://haskell.inf.elte.hu/ghc/ghc-7.10.2.20151030-x86_64-portbld-freebsd.tar.xz along with their sha256 sums: http://haskell.inf.elte.hu/ghc/SHA256SUMS and some notes on the installation: http://haskell.inf.elte.hu/ghc/README.html Cheers, G?bor From mail at joachim-breitner.de Tue Nov 3 12:37:36 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 03 Nov 2015 13:37:36 +0100 Subject: Error: selected processor does not support ARM mode `ldrd r0,r1,[r7,#64]' Message-ID: <1446554256.1880.11.camel@joachim-breitner.de> Hi, I cannot build ghc-7.10.3 on Debian armel: "inplace/bin/ghc-stage1" -static??-H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts -dcmm-lint??????-i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen???????????-O2????-c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o /tmp/ghcd0b9_0/ghc_7.s: Assembler messages: /tmp/ghcd0b9_0/ghc_7.s:96:0: ?????Error: selected processor does not support ARM mode `ldrd r0,r1,[r3,#64]' /tmp/ghcd0b9_0/ghc_7.s:99:0: ?????Error: selected processor does not support ARM mode `strd r0,r1,[r3,#64]' /tmp/ghcd0b9_0/ghc_7.s:210:0: ?????Error: selected processor does not support ARM mode `ldrd r0,r1,[r7,#64]' /tmp/ghcd0b9_0/ghc_7.s:214:0: ?????Error: selected processor does not support ARM mode `strd r0,r1,[r7,#64]' rts/ghc.mk:236: recipe for target 'rts/dist/build/StgStartup.o' failed make[3]: *** [rts/dist/build/StgStartup.o] Error 1 Makefile:71: recipe for target 'all' failed make[2]: *** [all] Error 2 Erik, can you comment on that? Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From austin at well-typed.com Tue Nov 3 14:47:48 2015 From: austin at well-typed.com (Austin Seipp) Date: Tue, 3 Nov 2015 08:47:48 -0600 Subject: Error: selected processor does not support ARM mode `ldrd r0, r1, [r7, #64]' In-Reply-To: <1446554256.1880.11.camel@joachim-breitner.de> References: <1446554256.1880.11.camel@joachim-breitner.de> Message-ID: Isn't armel the (old, but not EABI-very-old) pre-hardware-floating point ABI? In any case, this is fallout from 933adc0f31164cb651d11ecfcfe612ac429f714f, but fixing it means we'd need to add in several more code paths to handle this case... So I suppose we should probably file a ticket and get that fixed for 8.0 On Tue, Nov 3, 2015 at 6:37 AM, Joachim Breitner wrote: > Hi, > > I cannot build ghc-7.10.3 on Debian armel: > > "inplace/bin/ghc-stage1" -static -H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o > /tmp/ghcd0b9_0/ghc_7.s: Assembler messages: > > /tmp/ghcd0b9_0/ghc_7.s:96:0: > Error: selected processor does not support ARM mode `ldrd r0,r1,[r3,#64]' > > /tmp/ghcd0b9_0/ghc_7.s:99:0: > Error: selected processor does not support ARM mode `strd r0,r1,[r3,#64]' > > /tmp/ghcd0b9_0/ghc_7.s:210:0: > Error: selected processor does not support ARM mode `ldrd r0,r1,[r7,#64]' > > /tmp/ghcd0b9_0/ghc_7.s:214:0: > Error: selected processor does not support ARM mode `strd r0,r1,[r7,#64]' > rts/ghc.mk:236: recipe for target 'rts/dist/build/StgStartup.o' failed > make[3]: *** [rts/dist/build/StgStartup.o] Error 1 > Makefile:71: recipe for target 'all' failed > make[2]: *** [all] Error 2 > > Erik, can you comment on that? > > Greetings, > Joachim > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From mail at joachim-breitner.de Tue Nov 3 15:15:30 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 03 Nov 2015 16:15:30 +0100 Subject: Error: selected processor does not support ARM mode `ldrd r0, r1, [r7, #64]' In-Reply-To: References: <1446554256.1880.11.camel@joachim-breitner.de> Message-ID: <1446563730.1880.13.camel@joachim-breitner.de> Hi, Am Dienstag, den 03.11.2015, 08:47 -0600 schrieb Austin Seipp: > Isn't armel the (old, but not EABI-very-old) pre-hardware-floating > point ABI? I believe so, but I?m sure Erik knows better. > In any case, this is fallout from > 933adc0f31164cb651d11ecfcfe612ac429f714f, but fixing it means we'd > need to add in several more code paths to handle this case... So I > suppose we should probably file a ticket and get that fixed for 8.0 Well, it is a regression over 7.10.2; such a thing should not happen in a stable point release, shouldn?t it? Filed a ticket at?https://ghc.haskell.org/trac/ghc/ticket/11058 Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Tue Nov 3 16:54:47 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 3 Nov 2015 16:54:47 +0000 Subject: A big patch Message-ID: <38b91eee7ad241039e3489f3b7193401@DB4PR30MB030.064d.mgd.msft.net> Ben, Austin I wonder if one of you could put up a big patch on Phab for me? I started about two months ago on a modest refactoring of HsType and friends, to clarify and tidy up exactly where quantification takes place in types. Although initially driven by making the implementation of wildcards more tidy (and fixing a number of bugs), I gradually got drawn into a pretty big process, which I've been doing on and off for quite a long time. It's time to finish! I could just commit, but it's good practice to put it on Phab first. Could you do that for me? ? It's in branch wip/spj-wildcard-refactor ? It's up to date with HEAD from a day or two back ? The principal driving change is described in Note [HsType binders] in HsType. Worth reading! Those data type changes drive almost everything else. ? There are some uninteresting knock-on changes in Haddock, which are in wip/spj-wildcard-refactor in utils/haddock. I've done the submodule commit thing so the ghc-repo branch should refer correctly to the Haddock branch. ? The commit log on the branch is of no interest; just dump it entirely. I will write a proper commit message in due course. ? A handful of tests are failing. I'm working on that, but I want to get this onto Phab now awyway. You could include this email as the Phab description. Thanks! Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Tue Nov 3 16:56:14 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 03 Nov 2015 17:56:14 +0100 Subject: Error: selected processor does not support ARM mode `ldrd r0, r1, [r7, #64]' In-Reply-To: <1446563730.1880.13.camel@joachim-breitner.de> References: <1446554256.1880.11.camel@joachim-breitner.de> <1446563730.1880.13.camel@joachim-breitner.de> Message-ID: <877flz6mz5.fsf@smart-cactus.org> Joachim Breitner writes: > Hi, > > Am Dienstag, den 03.11.2015, 08:47 -0600 schrieb Austin Seipp: >> Isn't armel the (old, but not EABI-very-old) pre-hardware-floating >> point ABI? > > I believe so, but I?m sure Erik knows better. > >> In any case, this is fallout from >> 933adc0f31164cb651d11ecfcfe612ac429f714f, but fixing it means we'd >> need to add in several more code paths to handle this case... So I >> suppose we should probably file a ticket and get that fixed for 8.0 > > Well, it is a regression over 7.10.2; such a thing should not happen in > a stable point release, shouldn?t it? > Indeed this appears to be regression compared to 7.10.2 for some. However for most users it will be a significant improvement in stability. ARM processors can run code encoded in one of several instruction sets of which ARM and Thumb are two. The issue here is that we have never been able to handle Thumb instructions correctly; we fare even worse in cases where we have Thumb and ARM instructions in the same executable due to various linker issues: * the runtime's linker doesn't support loading heterogeneous code at all * the system's dynamic linker will almost certainly screw up our info tables due to the need for a trampoline (for this reason , I'm not even sure whether it's possible to handle Thumb-ARM interworking in Haskell code) There are several places where Thumb instructions could come from, 1. GHCi produced them in mkJumpToAddr 2. native code compiled with GCC, which defaults to Thumb on many systems 3. system libraries, which are Thumb on many distributions The solution which Erik implemented was to switch entirely to ARM. (1) was addressed by changing the GHC, (2) was fixed by explicitly passing -marm to GCC. I'm actually not sure the state of (3). Regardless, the solution to (2) is clearly upsetting your system. This is odd as I was under the impression that all non-microcontroller ARM devices support the full ARM instruction set (the Cortex devices, on the other hand, only support Thumb but are totally incapable of running GHC at all). What hardware and distribution is this? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From austin at well-typed.com Tue Nov 3 16:59:24 2015 From: austin at well-typed.com (Austin Seipp) Date: Tue, 3 Nov 2015 10:59:24 -0600 Subject: A big patch In-Reply-To: <38b91eee7ad241039e3489f3b7193401@DB4PR30MB030.064d.mgd.msft.net> References: <38b91eee7ad241039e3489f3b7193401@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Sure. I'm looking at it now; I'll try and get a copy onto Phab shortly. On Tue, Nov 3, 2015 at 10:54 AM, Simon Peyton Jones wrote: > Ben, Austin > > I wonder if one of you could put up a big patch on Phab for me? > > I started about two months ago on a modest refactoring of HsType and > friends, to clarify and tidy up exactly where quantification takes place in > types. Although initially driven by making the implementation of wildcards > more tidy (and fixing a number of bugs), I gradually got drawn into a > pretty big process, which I?ve been doing on and off for quite a long time. > It?s time to finish! > > I could just commit, but it?s good practice to put it on Phab first. Could > you do that for me? > > ? It?s in branch wip/spj-wildcard-refactor > > ? It?s up to date with HEAD from a day or two back > > ? The principal driving change is described in Note [HsType binders] > in HsType. Worth reading! Those data type changes drive almost everything > else. > > ? There are some uninteresting knock-on changes in Haddock, which > are in wip/spj-wildcard-refactor in utils/haddock. I?ve done the submodule > commit thing so the ghc-repo branch should refer correctly to the Haddock > branch. > > ? The commit log on the branch is of no interest; just dump it > entirely. I will write a proper commit message in due course. > > ? A handful of tests are failing. I?m working on that, but I want > to get this onto Phab now awyway. > > You could include this email as the Phab description. > > Thanks! > > Simon -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From ben at well-typed.com Tue Nov 3 17:06:58 2015 From: ben at well-typed.com (Ben Gamari) Date: Tue, 03 Nov 2015 18:06:58 +0100 Subject: A big patch In-Reply-To: <38b91eee7ad241039e3489f3b7193401@DB4PR30MB030.064d.mgd.msft.net> References: <38b91eee7ad241039e3489f3b7193401@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <874mh36mh9.fsf@smart-cactus.org> Simon Peyton Jones writes: > Ben, Austin I wonder if one of you could put up a big patch on Phab > for me? I started about two months ago on a modest refactoring of > HsType and friends, to clarify and tidy up exactly where > quantification takes place in types. Although initially driven by > making the implementation of wildcards more tidy (and fixing a number > of bugs), I gradually got drawn into a pretty big process, which I've > been doing on and off for quite a long time. It's time to finish! I > could just commit, but it's good practice to put it on Phab first. > Could you do that for me? Sure. It's D1428. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From mle+hs at mega-nerd.com Tue Nov 3 22:11:22 2015 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Wed, 4 Nov 2015 09:11:22 +1100 Subject: Error: selected processor does not support ARM mode `ldrd r0,r1,[r7,#64]' In-Reply-To: <1446554256.1880.11.camel@joachim-breitner.de> References: <1446554256.1880.11.camel@joachim-breitner.de> Message-ID: <20151104091122.f693774baa9969ca73914e25@mega-nerd.com> Joachim Breitner wrote: > Erik, can you comment on that? Well, I agree that not being able to build GHC on `armel` is a regression with respect to 7.10.2, but in my opinion, GHC 7.10.2 was not actually usable on Arm, at least not on `armhf` (not sure about `armel` as I don't have an `armel` setup). Currently, GHC treats all 32 bit Arm systems as the same. I think this shows that we need at least the equivalent of Debian's `armhf` (which is what we currently have) and Debian's `armel`. I'm not even too sure what `armel` actually is. Is it Armv4 with softfloat? Is so, I can probably create a chroot on one of my fast `armhf` boards. The main problem is that Arm needs more developer man power. For the last several months my employer has allowed me to allocate some of my work hours to improve GHC on Arm and Arm64. That however is about to come to an end and at the moment I seem to be the only person working on Arm. That work is also made more difficult by the fact that changes in the master branch seem to break Arm (and/or PowerPC) every 2-3 weeks. Sometimes just fixing new breakage in master takes up all the time I have. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From mle+hs at mega-nerd.com Tue Nov 3 22:20:31 2015 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Wed, 4 Nov 2015 09:20:31 +1100 Subject: Error: selected processor does not support ARM mode `ldrd r0, r1, [r7, #64]' In-Reply-To: <877flz6mz5.fsf@smart-cactus.org> References: <1446554256.1880.11.camel@joachim-breitner.de> <1446563730.1880.13.camel@joachim-breitner.de> <877flz6mz5.fsf@smart-cactus.org> Message-ID: <20151104092031.4bd753b5cbeda90b1faa930b@mega-nerd.com> Ben Gamari wrote: > There are several places where Thumb instructions could come from, > > 1. GHCi produced them in mkJumpToAddr > > 2. native code compiled with GCC, which defaults to Thumb on many > systems > > 3. system libraries, which are Thumb on many distributions > > The solution which Erik implemented was to switch entirely to ARM. (1) > was addressed by changing the GHC, (2) was fixed by explicitly passing > -marm to GCC. I'm actually not sure the state of (3). Unfortunately, (3) is likely to still be broken. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From carter.schonwald at gmail.com Wed Nov 4 00:11:58 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 3 Nov 2015 19:11:58 -0500 Subject: [ANNOUNCE] GHC 7.10.3 release candidate 1 In-Reply-To: References: <87fv0o8k3d.fsf@smart-cactus.org> <9CDB96CA-FCDC-47F9-AF19-F6E44CE75C1E@cis.upenn.edu> <1446488843.1764.19.camel@joachim-breitner.de> Message-ID: I will kick off a Mac build this evening or tomorrow. On Nov 3, 2015 6:28 AM, "P?li G?bor J?nos" wrote: > 2015-11-03 1:17 GMT+01:00 Austin Seipp : > > Yeah, so in the past Tier 1 platforms (OS X, Win, Lin, FreeBSD) are > > always available, but I rarely (if ever) held up RCs for anything > > besides that. > > The FreeBSD bindists are available there: > > > http://haskell.inf.elte.hu/ghc/ghc-7.10.2.20151030-i386-portbld-freebsd.tar.bz2 > > http://haskell.inf.elte.hu/ghc/ghc-7.10.2.20151030-i386-portbld-freebsd.tar.xz > > http://haskell.inf.elte.hu/ghc/ghc-7.10.2.20151030-x86_64-portbld-freebsd.tar.bz2 > > http://haskell.inf.elte.hu/ghc/ghc-7.10.2.20151030-x86_64-portbld-freebsd.tar.xz > > along with their sha256 sums: > > http://haskell.inf.elte.hu/ghc/SHA256SUMS > > and some notes on the installation: > > http://haskell.inf.elte.hu/ghc/README.html > > Cheers, > G?bor > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.grenrus at iki.fi Wed Nov 4 10:53:51 2015 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Wed, 4 Nov 2015 12:53:51 +0200 Subject: [ANNOUNCE] GHC 7.10.3 release candidate 1 In-Reply-To: <87fv0o8k3d.fsf@smart-cactus.org> References: <87fv0o8k3d.fsf@smart-cactus.org> Message-ID: <65A5651A-7C9D-4B6B-AEF2-459135E6ACB9@iki.fi> Travis has whitelisted hvr/ppa ghc-7.10.3 package. Please update your travis build matrices! Let?s make travis do its job! Cheers, Oleg > On 02 Nov 2015, at 18:03, Ben Gamari wrote: > > > We are pleased to announce the first (and hopefully only) release > candidate for GHC 7.10.3: > > https://downloads.haskell.org/~ghc/7.10.3-rc1/ > > This includes the source tarball and bindists for 64-bit and 32-bit > modern Linux (GMP 5.0 or later) and Windows. These binaries and tarballs > have an accompanying SHA256SUMS file signed by my GPG key id > (0x97DB64AD). As always, our content delivery network tends to be a bit > slow on the uptake. If you see an empty directory at this URL just add a > few superfluous slashes to the end; this is typically enough to fool it. > > The 7.10.2 release 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. > > The one exception to this is an upgrade of the Windows compiler > toolchain to GCC 5.2. Windows users have been long suffering at the hand > of our old toolchain (e.g. lack of response file support, #8596, and > lack of SEH support) so we expect that this change should fix far more > than breaks. > > We plan to make the 7.10.3 release sometime next week. > > Please test this as much as possible; bugs are much cheaper if we find > them before the release and this will ideally be the last release of the > 7.10 series. > > Happy testing, > > - Ben > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From eir at cis.upenn.edu Wed Nov 4 15:46:18 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 4 Nov 2015 10:46:18 -0500 Subject: [ANNOUNCE] GHC 7.10.3 release candidate 1 In-Reply-To: <65A5651A-7C9D-4B6B-AEF2-459135E6ACB9@iki.fi> References: <87fv0o8k3d.fsf@smart-cactus.org> <65A5651A-7C9D-4B6B-AEF2-459135E6ACB9@iki.fi> Message-ID: <6BA7E4B9-8791-4A31-BE90-4B632FAE423C@cis.upenn.edu> I can't build 7.10.3 RC1 because I don't have readelf. ./configure says this: > checking for readelf... no > configure: error: cannot find readelf in your PATH A (very) quick search has turned up no help. I'm worried that my problem is that I'm still running Mac OS 10.8.5 (Snow Leopard? I never could keep track of all the animals... and now mountains.) I *really* don't want to upgrade, as I tried 10.9 once and it brought my system to its knees... had to reformat to downgrade back to 10.8. Help? Thanks! Richard On Nov 4, 2015, at 5:53 AM, Oleg Grenrus wrote: > Travis has whitelisted hvr/ppa ghc-7.10.3 package. Please update your > travis build matrices! > > Let?s make travis do its job! > > Cheers, > Oleg > >> On 02 Nov 2015, at 18:03, Ben Gamari wrote: >> >> >> We are pleased to announce the first (and hopefully only) release >> candidate for GHC 7.10.3: >> >> https://downloads.haskell.org/~ghc/7.10.3-rc1/ >> >> This includes the source tarball and bindists for 64-bit and 32-bit >> modern Linux (GMP 5.0 or later) and Windows. These binaries and tarballs >> have an accompanying SHA256SUMS file signed by my GPG key id >> (0x97DB64AD). As always, our content delivery network tends to be a bit >> slow on the uptake. If you see an empty directory at this URL just add a >> few superfluous slashes to the end; this is typically enough to fool it. >> >> The 7.10.2 release 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. >> >> The one exception to this is an upgrade of the Windows compiler >> toolchain to GCC 5.2. Windows users have been long suffering at the hand >> of our old toolchain (e.g. lack of response file support, #8596, and >> lack of SEH support) so we expect that this change should fix far more >> than breaks. >> >> We plan to make the 7.10.3 release sometime next week. >> >> Please test this as much as possible; bugs are much cheaper if we find >> them before the release and this will ideally be the last release of the >> 7.10 series. >> >> Happy testing, >> >> - Ben >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From eir at cis.upenn.edu Wed Nov 4 16:18:07 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 4 Nov 2015 11:18:07 -0500 Subject: [ANNOUNCE] GHC 7.10.3 release candidate 1 In-Reply-To: References: <87fv0o8k3d.fsf@smart-cactus.org> <65A5651A-7C9D-4B6B-AEF2-459135E6ACB9@iki.fi> <6BA7E4B9-8791-4A31-BE90-4B632FAE423C@cis.upenn.edu> Message-ID: <506D8F5A-AA06-4A73-8DE6-12B2332C15BF@cis.upenn.edu> On Nov 4, 2015, at 11:12 AM, Peter Trommler wrote: > It looks like a bug to me. I'm taking your "it" here to mean the fact that GHC is looking for readelf on a Mac OS platform. I tend to agree -- I was surprised to see this, but I'm almost-totally clueless about these things. Thanks for the info, Richard PS: There's been much muttering about call stacks and DWARF. I haven't a clue what DWARF is, but I always assumed that this nice feature would not be available on Macs. What I realized today is that this assumption likely stems from the fact that ELF is not for Mac. ELFs and DWARFs tend to be found near one another in other settings, but perhaps this fact doesn't carry over to computer architectures. :) > > Cheers, > > Peter > >> On 04.11.2015, at 16:46, Richard Eisenberg wrote: >> >> I can't build 7.10.3 RC1 because I don't have readelf. ./configure says this: >> >>> checking for readelf... no >>> configure: error: cannot find readelf in your PATH >> >> A (very) quick search has turned up no help. I'm worried that my problem is that I'm still running Mac OS 10.8.5 (Snow Leopard? I never could keep track of all the animals... and now mountains.) I *really* don't want to upgrade, as I tried 10.9 once and it brought my system to its knees... had to reformat to downgrade back to 10.8. >> >> Help? >> >> Thanks! >> Richard >> > > > > -- > Prof. Dr. Peter Trommler email: peter.trommler at th-nuernberg.de > Technische Hochschule Nuernberg phone: +49-911-58 80-16 63 > Faculty of Computer Science fax: +49-911-58 80-56 66 > Postfach 31 03 20, 90121 Nuernberg office: Hohfederstrasse 40, 90489 Nuernberg > > From trp at bluewin.ch Wed Nov 4 16:35:12 2015 From: trp at bluewin.ch (Peter Trommler) Date: Wed, 4 Nov 2015 17:35:12 +0100 Subject: [ANNOUNCE] GHC 7.10.3 release candidate 1 References: Message-ID: Sent from the wrong account the first time around. > On 04.11.2015, at 17:18, Richard Eisenberg wrote: > > > On Nov 4, 2015, at 11:12 AM, Peter Trommler wrote: > >> It looks like a bug to me. > > I'm taking your "it" here to mean the fact that GHC is looking for readelf on a Mac OS platform. Yes. That's correct. Peter From nicola.gigante at gmail.com Wed Nov 4 19:12:39 2015 From: nicola.gigante at gmail.com (Nicola Gigante) Date: Wed, 4 Nov 2015 20:12:39 +0100 Subject: Questions on the RTS C API regarding threads and tasks Message-ID: Hi everybody, I?m new on this list, congratulations to everyone for the great work that you?re doing on GHC! I apologize if this is not the right list where to ask the following questions. Please point me to the correct list or IRC channel otherwise. I?m part of a small group of people who is going to work on a project that seems to need low-level handling of haskell threads. I?ve started delving into the ghc runtime API to understand if everything we need is exposed to the world or if we have to modify the runtime itself (which I would avoid if possible). I have a few questions about the functions that the runtime exports to the C world regarding the manipulation of tasks: - Fundamentally, is there a way for a C function called by a foreign call to suspend the haskell thread that called it, to be resumed later when appropriate? I see that the runtime has a concept of ?blocking queue?, but I also see that the functions that work on blocking queues are not exported. I can manage a queue of TSOs myself, but then I need a way to put in sleep the task indefinitely up to a wake signal. In other words, can I sleep and awake haskell threads from a C function called by a foreign call? - I see the ?suspendThread? and ?resumeThread? functions exist in include/rts/Threads.h Are these the functions that I need for the point above? My main concern is that the comments in the source code for suspendThread say that these functions are used in case of a CCall, and put the thread in a specific queue, so they seems to have more specific role than what the name might suggest. - Also, I?m unable to find what a StgRegTable is (which is taken as argument by suspendThread). Thank you in advance for your help, Greetings, Nicola From carter.schonwald at gmail.com Thu Nov 5 00:41:27 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 4 Nov 2015 19:41:27 -0500 Subject: [ANNOUNCE] GHC 7.10.3 release candidate 1 In-Reply-To: References: Message-ID: i'm seeing that problem on my mac too. the RC is busted for mac :(, unbuildable even On Wed, Nov 4, 2015 at 11:35 AM, Peter Trommler wrote: > Sent from the wrong account the first time around. > > > On 04.11.2015, at 17:18, Richard Eisenberg wrote: > > > > > > On Nov 4, 2015, at 11:12 AM, Peter Trommler < > Peter.Trommler at th-nuernberg.de> wrote: > > > >> It looks like a bug to me. > > > > I'm taking your "it" here to mean the fact that GHC is looking for > readelf on a Mac OS platform. > Yes. That's correct. > > Peter > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Thu Nov 5 04:27:15 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Wed, 04 Nov 2015 20:27:15 -0800 Subject: Questions on the RTS C API regarding threads and tasks In-Reply-To: References: Message-ID: <1446696928-sup-6497@sabre> Excerpts from Nicola Gigante's message of 2015-11-04 11:12:39 -0800: > I?ve started delving into the ghc runtime API to understand > if everything we need is exposed to the world or if we > have to modify the runtime itself (which I would avoid if possible). I agree with this goal in principle, but: (1) Depending on what you want to do, it may be quite difficult to do this, and (2) The RTS is actually quite hackable (as long as you are not changing any of the interfaces with generated Haskell code, you could even build your own RTS and have users link against that.) Something to keep in mind. > I have a few questions about the functions that the runtime > exports to the C world regarding the manipulation of tasks: > > - Fundamentally, is there a way for a C function called by a foreign call > to suspend the haskell thread that called it, to be resumed later > when appropriate? I see that the runtime has a concept of > ?blocking queue?, but I also see that the functions that work on > blocking queues are not exported. I can manage a queue of TSOs myself, > but then I need a way to put in sleep the task indefinitely up to a wake signal. > In other words, can I sleep and awake haskell threads from a C function > called by a foreign call? Not easily. If you make a safe foreign call, the capability is given up before the C code executes, so you actually lose ownership of the capability and TSO by the time you're running C code. The only way to write a foreign call to properly suspend the thread that called it is a primop function (e.g. stg_putMVar), and the operation is quite delicate and you will probably want to use some existing (internal) code in the RTS to do it. But if you just need to sleep/awake threads, why not just use an MVar? Edward From trp at bluewin.ch Thu Nov 5 06:53:10 2015 From: trp at bluewin.ch (Peter Trommler) Date: Thu, 5 Nov 2015 07:53:10 +0100 Subject: [ANNOUNCE] GHC 7.10.3 release candidate 1 In-Reply-To: References: Message-ID: <053082B5-3ED6-4B4C-8899-80188E313E6D@bluewin.ch> I created #11061. Peter > On 05.11.2015, at 01:41, Carter Schonwald wrote: > > i'm seeing that problem on my mac too. the RC is busted for mac :(, unbuildable even > > On Wed, Nov 4, 2015 at 11:35 AM, Peter Trommler wrote: > Sent from the wrong account the first time around. > >> On 04.11.2015, at 17:18, Richard Eisenberg wrote: >> >> >> On Nov 4, 2015, at 11:12 AM, Peter Trommler wrote: >> >>> It looks like a bug to me. >> >> I'm taking your "it" here to mean the fact that GHC is looking for readelf on a Mac OS platform. > Yes. That's correct. From nicola.gigante at gmail.com Thu Nov 5 07:13:51 2015 From: nicola.gigante at gmail.com (Nicola Gigante) Date: Thu, 5 Nov 2015 08:13:51 +0100 Subject: Questions on the RTS C API regarding threads and tasks Message-ID: <5701AB9A-E4F1-4885-AD28-DE6F5480EAD9@gmail.com> Il giorno 05 nov 2015, alle ore 05:27, Edward Z. Yang ha scritto: > > Excerpts from Nicola Gigante's message of 2015-11-04 11:12:39 -0800: >> I?ve started delving into the ghc runtime API to understand >> if everything we need is exposed to the world or if we >> have to modify the runtime itself (which I would avoid if possible). > > I agree with this goal in principle, but: > > (1) Depending on what you want to do, it may be quite difficult to > do this, and > > (2) The RTS is actually quite hackable (as long as you are not > changing any of the interfaces with generated Haskell code, you > could even build your own RTS and have users link against that.) > > Something to keep in mind. > Edward, thanks for the quick reply! Yes, I see that the source code is clear and well documented! :) However, this project is something we would eventually want to publish on hackage, not something of internal use. This means we'd have to contribute the runtime changes upstream, which would be cool but I assumed GHC as a project doesn't accept every experimental new feature that come across, and we don't have the energy to guarantee maintenance of this eventual contribution. An external solution would be better. > > Not easily. If you make a safe foreign call, the capability is given up > before the C code executes, so you actually lose ownership of the > capability and TSO by the time you're running C code. The only > way to write a foreign call to properly suspend the thread that called > it is a primop function (e.g. stg_putMVar), and the operation is quite > delicate and you will probably want to use some existing (internal) > code in the RTS to do it. > > But if you just need to sleep/awake threads, why not just use an MVar? We don't have measurements, but we ruled out this possibility for performance reasons. Our idea is to make a thin Haskell wrapper around a tiny bit of highly optimized C code. What's the performance of locking on MVars? While we are at it: are primops callable directly from C? I suppose calling conventions are different. A question comes to mind: you mentioned "safe" calls. Are unsafe calls different regarding the detaching of the capability? Also: would a patch to make this possible be accepted? In particular: - add a way to make a "ultraunsafe" foreign call that do not loose the ownership of the calling thread. - add a BlockedOnExplicitSleep flag for tso->why_blocked (And in turn this means managing a different blocking queue, right?) - export something to reliably put in sleep and resume threads in this way. Is this feasible? Would it be a good idea? > > Edward Thank you again, Greetings, Nicola From adam at well-typed.com Thu Nov 5 09:03:00 2015 From: adam at well-typed.com (Adam Gundry) Date: Thu, 5 Nov 2015 09:03:00 +0000 Subject: Status of OverloadedRecordFields [Was: Re: Proposal: Dot as Postfix Function Apply] In-Reply-To: <1446633873720-5821620.post@n5.nabble.com> References: <1446633873720-5821620.post@n5.nabble.com> Message-ID: <563B1B44.3010302@well-typed.com> [copying ghc-devs as the following is perhaps more relevant there] On 04/11/15 10:44, Jeremy wrote: > Dot as Postfix Function Apply > (https://ghc.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields/DotPostfix) > was originally part of ORF, but dropped to keep the scope/discussion more > manageable. Now that ORF is in for GHC 8.0, I would like to re-propose dot > postfix syntax. I'm going to stay out of the discussion over the proposed syntax extension, but I feel like I should do some expectation management about ORF in GHC 8.0. As the wiki page [1] makes clear, ORF has been divided into three components, and so far only one of these is in GHC HEAD. The first part is a language extension, DuplicateRecordFields, which allows field names to be duplicated provided they are unambiguous. (It does not allow any kind of polymorphism over record fields.) This is already in HEAD. The second part is another language extension, OverloadedLabels, which introduces a new syntax #x for an identifier whose type is inferred and may depend on the text of the identifier. This is implemented and up on Phabricator [2], but not yet in HEAD. It should make GHC 8.0, but I'm wary about giving cast-iron guarantees. The third part, which is necessary for the OverloadedLabels syntax to be used for polymorphism over record fields, involves typeclass constraints that capture when a type has a particular field, with the instances provided automatically by GHC. This is not yet implemented in the intended form, and is unlikely to make GHC 8.0 (barring me having a sudden outbreak of free time...). Adam [1] https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields [2] https://phabricator.haskell.org/D1331 -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From ben at well-typed.com Thu Nov 5 10:53:20 2015 From: ben at well-typed.com (Ben Gamari) Date: Thu, 05 Nov 2015 11:53:20 +0100 Subject: [ANNOUNCE] GHC 7.10.3 release candidate 1 In-Reply-To: <053082B5-3ED6-4B4C-8899-80188E313E6D@bluewin.ch> References: <053082B5-3ED6-4B4C-8899-80188E313E6D@bluewin.ch> Message-ID: <877flwvhsv.fsf@smart-cactus.org> Peter Trommler writes: > I created #11061. > Erikd has provided a patch tested on OS X fixing this issue. I'll push an rc2 source tarball some time today. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From jan.bracker at googlemail.com Thu Nov 5 13:22:14 2015 From: jan.bracker at googlemail.com (Jan Bracker) Date: Thu, 5 Nov 2015 13:22:14 +0000 Subject: Type Checker Plugin: Producing the correct evidence Message-ID: Hello, I am using type checker plugins to select specific instances in a program. My current problem concerns the following instance: class Polymonad m n p where (>>=) :: m a -> (a -> n b) -> p b instance ( Effect m, E.Inv m f (Unit m), f ~ Plus m f (Unit m)) => Polymonad (m (f :: [*])) Identity (m (f :: [*])) where ma >>= f = ma E.>>= (E.return . runIdentity . f) 'E', 'Unit' and 'Plus' refer to the module 'Control.Effect' [5] from the 'effect-monad' package. At some point in my example program [2] GHC is uncertain which instance to use for the '>>=' operator. The wanted constraint is: [W] $dPolymonad_a5Qp :: Polymonad (State '[n :-> (a :! 'W)]) Identity (State '[n :-> (a :! 'W)]) (CNonCanonical) To select the instance above I produce the following evidence: $fPolymonadmIdentitym @[State, '[n :-> (a :! 'W)]] [$fEffect[]State @[] []] 'State' is from the module 'Control.Effect.State' [4]. This works so far, but during the core-lint phase I get the following error message: : Warning: [RHS of $dPolymonad_a5Qp :: Polymonad (State '[n_a5PL :-> (a_a5PM :! 'W)]) Identity (State '[n_a5PL :-> (a_a5PM :! 'W)])] The type of this binder doesn't match the type of its RHS: $dPolymonad_a5Qp Binder's type: Polymonad (State '[n_a5PL :-> (a_a5PM :! 'W)]) Identity (State '[n_a5PL :-> (a_a5PM :! 'W)]) Rhs type: (Inv State '[n_a5PL :-> (a_a5PM :! 'W)] (Unit State), '[n_a5PL :-> (a_a5PM :! 'W)] ~ Plus State '[n_a5PL :-> (a_a5PM :! 'W)] (Unit State)) => Polymonad (State '[n_a5PL :-> (a_a5PM :! 'W)]) Identity (State '[n_a5PL :-> (a_a5PM :! 'W)]) Which I parse as a missing proof that the instance constraints are fulfilled by the evidence. >From this I have a few questions: 1. Why doesn't the type checker prove these type equality constraints for me? (or how can I get the type checker to do so?) I checked them on paper and the constraints are solvable and the equalities are true. 2. If I can't get the type checker to solve this for me, how do I produce appropriate evidence? 3. Another issue I see is that I would need to expand the type synonym 'E.Inv' to see what constraints it contains. I there an easy way to do so in GHC? I could not find appropriate functionality. It would be very useful for me if there was a function 'Type -> TcM Type' that evaluates the type as far as possible (by evaluate I mean expand synonyms, evaluate type functions and remove equalities that hold). The example program [2] and the plugin I am developing can be found [1] on GitHub (Commit fefc149ec6e1c1a3c3c2597c66d176854b94287d ). This is how I produce the evidence for my selected instance [3]. I hope this abstract description of my problem is enough. Best regards, Jan Bracker [1] https://github.com/jbracker/polymonad-plugin [2] https://github.com/jbracker/polymonad-plugin/blob/master/examples/effect/MainPolymonad.hs [3] https://github.com/jbracker/polymonad-plugin/blob/master/src/Control/Polymonad/Plugin/Evidence.hs [4] http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-State.html [5] http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.bracker at googlemail.com Thu Nov 5 18:12:32 2015 From: jan.bracker at googlemail.com (Jan Bracker) Date: Thu, 5 Nov 2015 18:12:32 +0000 Subject: Evaluating types and determining instantiability of an instance Message-ID: Hello, I am trying to write a type checker plugin and I noticed that I keep trying to reimplement functionality that GHC type system already implements, but I can't seem to find a way to access the functionality. Part of these features I already asked in another (previous) email [1] to the mailing list and I am sorry if this will duplicate part of that discussion. 1. Is there a function in the type system which I can use to evaluate type functions and expand type synonyms (including associated instances)? Ideally I would want something that looks like this 'Type -> TcM Type'. I know that this kind of evaluation is not necessarily possible (e.g. type variables that can't be matched against in a type function application), but it would be helpful if the function could at least evaluate/expand as far as is possible in the current context. That way I don't have to manually lookup type family instances or type synonyms and make mistakes by doing so. This would also ease the support for the different type system extensions available, which I currently have to manually reimplement. 2. If I have an instance and a number of type arguments for that instance, is there an easy way to check if that instance is instantiated by those arguments? Something of the form '[Ct] -> ClsInst -> [Type] -> TcM (Maybe EvTerm)' would be useful. This function would take the given and derived constraints and deliver evidence for the instantiation if it is possible or return nothing if it is not. Again, if there are some open type variables I know this is not always possible in general and I am aware that this, in its full generality, requires a call to the constraint solver. But currently I am manually walking through the instance constraints to check if they are instantiated given the arguments [3] and then I also manually produce evidence [2]. In that process I ignore type equalities, type synonym and type families, because that would require me to implement question 1. I suspect this kind of functionality should exists somewhere within the GHC API. I would want this function to work with type arguments, whose only type variables already occur in the given and derived constraints. I think in that case it should always be possible to determine if the instance is instantiated. Best regards, Jan Bracker [1] https://mail.haskell.org/pipermail/ghc-devs/2015-November/010342.html [2] https://github.com/jbracker/polymonad-plugin/blob/master/src/Control/Polymonad/Plugin/Evidence.hs#L29 [3] https://github.com/jbracker/polymonad-plugin/blob/master/src/Control/Polymonad/Plugin/Instance.hs#L141 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsf at seereason.com Thu Nov 5 20:42:52 2015 From: dsf at seereason.com (David Fox) Date: Thu, 5 Nov 2015 12:42:52 -0800 Subject: Evaluating types and determining instantiability of an instance In-Reply-To: References: Message-ID: I think what you want is what I have attempted to do in th-context: https://hackage.haskell.org/package/th-context But it uses template-haskell types rather than GHC internal types. On Thu, Nov 5, 2015 at 10:12 AM, Jan Bracker wrote: > Hello, > > I am trying to write a type checker plugin and I noticed that I keep > trying to reimplement functionality that GHC type system already > implements, but I can't seem to find a way to access the functionality. > Part of these features I already asked in another (previous) email [1] to > the mailing list and I am sorry if this will duplicate part of that > discussion. > > 1. Is there a function in the type system which I can use to evaluate type > functions and expand type synonyms (including associated instances)? > Ideally I would want something that looks like this 'Type -> TcM Type'. I > know that this kind of evaluation is not necessarily possible (e.g. type > variables that can't be matched against in a type function application), > but it would be helpful if the function could at least evaluate/expand as > far as is possible in the current context. That way I don't have to > manually lookup type family instances or type synonyms and make mistakes by > doing so. This would also ease the support for the different type system > extensions available, which I currently have to manually reimplement. > > 2. If I have an instance and a number of type arguments for that instance, > is there an easy way to check if that instance is instantiated by those > arguments? Something of the form '[Ct] -> ClsInst -> [Type] -> TcM (Maybe > EvTerm)' would be useful. This function would take the given and derived > constraints and deliver evidence for the instantiation if it is possible or > return nothing if it is not. Again, if there are some open type variables I > know this is not always possible in general and I am aware that this, in > its full generality, requires a call to the constraint solver. But > currently I am manually walking through the instance constraints to check > if they are instantiated given the arguments [3] and then I also manually > produce evidence [2]. In that process I ignore type equalities, type > synonym and type families, because that would require me to implement > question 1. I suspect this kind of functionality should exists somewhere > within the GHC API. I would want this function to work with type arguments, > whose only type variables already occur in the given and derived > constraints. I think in that case it should always be possible to determine > if the instance is instantiated. > > Best regards, > Jan Bracker > > [1] https://mail.haskell.org/pipermail/ghc-devs/2015-November/010342.html > [2] > https://github.com/jbracker/polymonad-plugin/blob/master/src/Control/Polymonad/Plugin/Evidence.hs#L29 > [3] > https://github.com/jbracker/polymonad-plugin/blob/master/src/Control/Polymonad/Plugin/Instance.hs#L141 > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Fri Nov 6 02:13:15 2015 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Thu, 5 Nov 2015 21:13:15 -0500 Subject: Printing local Var(Id) types(in Outputable outputs) Message-ID: Hi all, I'm considering getting into the trouble of implementing this: A flag for printing types of local Ids. To be more specific, I'd like to see types of local Ids and binders in case expression alternatives etc. I may name it -dshow-local-id-types or something like that. An example output would be like this. Instead of: case ds_dPC of _ [Occ=Dead] { C1 l_avq -> ... C2 r_avr -> ... } It would print: case ds_dPC of _ [Occ=Dead] { C1 (l_avq :: Type1) -> ... C2 (r_avr :: Type2) -> ... } So my questions are: * Do we already have something like this? (I can't see it in man page) * Do you think, for some reason, this would be useless? (maybe there's some workaround etc. that has a similar effect) Thanks. From eir at cis.upenn.edu Fri Nov 6 15:25:03 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 6 Nov 2015 10:25:03 -0500 Subject: Evaluating types and determining instantiability of an instance In-Reply-To: References: Message-ID: <2CAEE28A-CDDD-48E2-B79D-4B3475835998@cis.upenn.edu> On Nov 5, 2015, at 1:12 PM, Jan Bracker wrote: > > 1. Is there a function in the type system which I can use to evaluate type functions and expand type synonyms (including associated instances)? Ideally I would want something that looks like this 'Type -> TcM Type'. I know that this kind of evaluation is not necessarily possible (e.g. type variables that can't be matched against in a type function application), but it would be helpful if the function could at least evaluate/expand as far as is possible in the current context. That way I don't have to manually lookup type family instances or type synonyms and make mistakes by doing so. This would also ease the support for the different type system extensions available, which I currently have to manually reimplement. I think FamInstEnv.normaliseType is the function you're looking for. You can get the FamInstEnvs argument from tcGetFamInstEnvs. > > 2. If I have an instance and a number of type arguments for that instance, is there an easy way to check if that instance is instantiated by those arguments? Something of the form '[Ct] -> ClsInst -> [Type] -> TcM (Maybe EvTerm)' would be useful. This function would take the given and derived constraints and deliver evidence for the instantiation if it is possible or return nothing if it is not. Again, if there are some open type variables I know this is not always possible in general and I am aware that this, in its full generality, requires a call to the constraint solver. But currently I am manually walking through the instance constraints to check if they are instantiated given the arguments [3] and then I also manually produce evidence [2]. In that process I ignore type equalities, type synonym and type families, because that would require me to implement question 1. I suspect this kind of functionality should exists somewhere within the GHC API. I would want this function to work with type arguments, whose only type variables already occur in the given and derived constraints. I think in that case it should always be possible to determine if the instance is instantiated. I'm less familiar with this. Does InstEnv.lookupInstEnv do it for you? I hope this is helpful! Richard From eir at cis.upenn.edu Fri Nov 6 15:29:07 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 6 Nov 2015 10:29:07 -0500 Subject: Printing local Var(Id) types(in Outputable outputs) In-Reply-To: References: Message-ID: <34FF1A38-3E17-4270-B295-1A817361A5B0@cis.upenn.edu> Yes -- I've wanted this too. It seems this functionality was once enabled by -dppr-debug, but then it got removed. See the vestigial flag -dsuppress-var-kinds. I've actually re-enabled this in my kind=type branch, because I needed it too. I say: go for it. Richard On Nov 5, 2015, at 9:13 PM, ?mer Sinan A?acan wrote: > Hi all, > > I'm considering getting into the trouble of implementing this: A flag for > printing types of local Ids. To be more specific, I'd like to see types of > local Ids and binders in case expression alternatives etc. I may name it > -dshow-local-id-types or something like that. > > An example output would be like this. Instead of: > > case ds_dPC of _ [Occ=Dead] { > C1 l_avq -> ... > C2 r_avr -> ... > } > > It would print: > > case ds_dPC of _ [Occ=Dead] { > C1 (l_avq :: Type1) -> ... > C2 (r_avr :: Type2) -> ... > } > > So my questions are: > > * Do we already have something like this? (I can't see it in man page) > > * Do you think, for some reason, this would be useless? (maybe there's some > workaround etc. that has a similar effect) > > Thanks. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ggreif at gmail.com Fri Nov 6 16:27:30 2015 From: ggreif at gmail.com (Gabor Greif) Date: Fri, 6 Nov 2015 17:27:30 +0100 Subject: Implied GHC extensions (in HEAD) Message-ID: Hi devs, when compiling a snippet of code (which I have written using GHC HEAD) with GHC 7.10.2 (from the platform) I got errors about missing extension pragmas. I had to add two: > {-# LANGUAGE ViewPatterns, KindSignatures, GADTs, PolyKinds, StandaloneDeriving, FlexibleContexts, FlexibleInstances, ScopedTypeVariables, TypeFamilies, PatternSynonyms, FunctionalDependencies, RankNTypes, UndecidableInstances #-} > {-# LANGUAGE DataKinds, TypeOperators #-} -- 7.10?? Looks like the implications have been extended in 7.11. I guess PolyKinds now implies DataKinds, but cannot think of what implies TypeOperators. Was this change by design or by accident? Any ideas? Cheers, Gabor From nicola.gigante at gmail.com Fri Nov 6 19:09:14 2015 From: nicola.gigante at gmail.com (Nicola Gigante) Date: Fri, 6 Nov 2015 20:09:14 +0100 Subject: Questions on the RTS C API regarding threads and tasks In-Reply-To: <5701AB9A-E4F1-4885-AD28-DE6F5480EAD9@gmail.com> References: <5701AB9A-E4F1-4885-AD28-DE6F5480EAD9@gmail.com> Message-ID: <82956D84-B154-4609-8072-B99521CD1BD0@gmail.com> Ping? Please tell me if my questions were unclear. Thank you, Nicola Il giorno 05 nov 2015, alle ore 08:13, Nicola Gigante ha scritto: > >> Il giorno 05 nov 2015, alle ore 05:27, Edward Z. Yang ha scritto: >> >> >> I agree with this goal in principle, but: >> >> (1) Depending on what you want to do, it may be quite difficult to >> do this, and >> >> (2) The RTS is actually quite hackable (as long as you are not >> changing any of the interfaces with generated Haskell code, you >> could even build your own RTS and have users link against that.) >> >> Something to keep in mind. > > Edward, thanks for the quick reply! > > Yes, I see that the source code is clear and well documented! :) > However, this project is something we would eventually want to publish > on hackage, not something of internal use. This means we'd have to > contribute the runtime changes upstream, which would be cool but > I assumed GHC as a project doesn't accept every experimental new feature > that come across, and we don't have the energy to guarantee maintenance > of this eventual contribution. An external solution would be better. >> >> Not easily. If you make a safe foreign call, the capability is given up >> before the C code executes, so you actually lose ownership of the >> capability and TSO by the time you're running C code. The only >> way to write a foreign call to properly suspend the thread that called >> it is a primop function (e.g. stg_putMVar), and the operation is quite >> delicate and you will probably want to use some existing (internal) >> code in the RTS to do it. >> >> But if you just need to sleep/awake threads, why not just use an MVar? > > We don't have measurements, but we ruled out this possibility for > performance reasons. Our idea is to make a thin Haskell wrapper > around a tiny bit of highly optimized C code. What's the performance > of locking on MVars? > > While we are at it: are primops callable directly from C? I suppose > calling conventions are different. > > A question comes to mind: you mentioned "safe" calls. > Are unsafe calls different regarding the detaching of the capability? > > Also: would a patch to make this possible be accepted? > In particular: > - add a way to make a "ultraunsafe" foreign call that do not loose the > ownership of the calling thread. > - add a BlockedOnExplicitSleep flag for tso->why_blocked > (And in turn this means managing a different blocking queue, right?) > - export something to reliably put in sleep and resume threads > in this way. > > Is this feasible? Would it be a good idea? >> From simonpj at microsoft.com Sat Nov 7 01:34:28 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Sat, 7 Nov 2015 01:34:28 +0000 Subject: Printing local Var(Id) types(in Outputable outputs) In-Reply-To: <34FF1A38-3E17-4270-B295-1A817361A5B0@cis.upenn.edu> References: <34FF1A38-3E17-4270-B295-1A817361A5B0@cis.upenn.edu> Message-ID: <5c95e63f1cfa4cbbbd292f11963c0d7a@DB4PR30MB030.064d.mgd.msft.net> Yes, go for it! Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Richard | Eisenberg | Sent: 06 November 2015 15:29 | To: ?mer Sinan A?acan | Cc: ghc-devs | Subject: Re: Printing local Var(Id) types(in Outputable outputs) | | Yes -- I've wanted this too. | | It seems this functionality was once enabled by -dppr-debug, but then it got | removed. See the vestigial flag -dsuppress-var-kinds. I've actually re- | enabled this in my kind=type branch, because I needed it too. | | I say: go for it. | | Richard | | On Nov 5, 2015, at 9:13 PM, ?mer Sinan A?acan wrote: | | > Hi all, | > | > I'm considering getting into the trouble of implementing this: A flag for | > printing types of local Ids. To be more specific, I'd like to see types of | > local Ids and binders in case expression alternatives etc. I may name it | > -dshow-local-id-types or something like that. | > | > An example output would be like this. Instead of: | > | > case ds_dPC of _ [Occ=Dead] { | > C1 l_avq -> ... | > C2 r_avr -> ... | > } | > | > It would print: | > | > case ds_dPC of _ [Occ=Dead] { | > C1 (l_avq :: Type1) -> ... | > C2 (r_avr :: Type2) -> ... | > } | > | > So my questions are: | > | > * Do we already have something like this? (I can't see it in man page) | > | > * Do you think, for some reason, this would be useless? (maybe there's some | > workaround etc. that has a similar effect) | > | > Thanks. | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell. | org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c122790e6daed42064deb08 | d2e6bf07f7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Kzxep971U2yrPgXODZyGn | Xfp3pau8POJwBn98vgmeUU%3d | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell. | org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c122790e6daed42064de | b08d2e6bf07f7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=b9tOk8zL7EallijICx | AspzLoGdqo09go%2bQcixr8%2fAcU%3d From ben at well-typed.com Sat Nov 7 22:28:04 2015 From: ben at well-typed.com (Ben Gamari) Date: Sat, 07 Nov 2015 23:28:04 +0100 Subject: [ANNOUNCE] 7.10.3 release candidate 2 Message-ID: <87pozltpfv.fsf@smart-cactus.org> Hello everyone, We are pleased to announce the second release candidate for GHC 7.10.3: https://downloads.haskell.org/~ghc/7.10.3-rc2/ This release differs from -rc1 by only two commits, * Disable the newly-introduced readelf configure check on non-ELF platforms. * Remove some tracing output from the typechecker that was causing some testsuites to fail. At the moment you should find the source tarball as well as 32- and 64-bit modern Linux (built on Debian 8) binary distributions available at the above URL. Windows and CentOS binaries will be made available shortly. As usual, you may need to work around our content delivery network's update latency by adding redundant forward-slashes to the URL. As far as OS X support goes, we are still looking for contributors to help us to support their platform by offering access to hardware, testing, or builds. Please let us know if you would be willing to provide any of the above. Happy testing! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ben at well-typed.com Sun Nov 8 00:22:38 2015 From: ben at well-typed.com (Ben Gamari) Date: Sun, 08 Nov 2015 01:22:38 +0100 Subject: [ANNOUNCE] 7.10.3 release candidate 2 In-Reply-To: <87pozltpfv.fsf@smart-cactus.org> References: <87pozltpfv.fsf@smart-cactus.org> Message-ID: <87twoxgx0x.fsf@smart-cactus.org> Ben Gamari writes: > Hello everyone, > > We are pleased to announce the second release candidate for GHC 7.10.3: > > https://downloads.haskell.org/~ghc/7.10.3-rc2/ > It has been brought to my attention that the configure script in this source tarballs is out of date. Because of this `configure` will still fail on OS X. Reports suggest that there may be other issues unrelated to the configure issue on OS X as well. In light of this it would seem that an -rc3 will likely be necessary. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From george.colpitts at gmail.com Sun Nov 8 00:36:43 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Sat, 7 Nov 2015 20:36:43 -0400 Subject: [ANNOUNCE] 7.10.3 release candidate 2 In-Reply-To: <87twoxgx0x.fsf@smart-cactus.org> References: <87pozltpfv.fsf@smart-cactus.org> <87twoxgx0x.fsf@smart-cactus.org> Message-ID: I can do testing on OS X. On Sat, Nov 7, 2015 at 8:22 PM, Ben Gamari wrote: > Ben Gamari writes: > > > Hello everyone, > > > > We are pleased to announce the second release candidate for GHC 7.10.3: > > > > https://downloads.haskell.org/~ghc/7.10.3-rc2/ > > > It has been brought to my attention that the configure script in this > source tarballs is out of date. Because of this `configure` will > still fail on OS X. Reports suggest that there may be other issues > unrelated to the configure issue on OS X as well. > > In light of this it would seem that an -rc3 will likely be necessary. > > Cheers, > > - Ben > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Sun Nov 8 09:44:27 2015 From: ben at well-typed.com (Ben Gamari) Date: Sun, 08 Nov 2015 10:44:27 +0100 Subject: [ANNOUNCE] 7.10.3 release candidate 2 In-Reply-To: <87twoxgx0x.fsf@smart-cactus.org> References: <87pozltpfv.fsf@smart-cactus.org> <87twoxgx0x.fsf@smart-cactus.org> Message-ID: <87mvuohll0.fsf@smart-cactus.org> Ben Gamari writes: > Ben Gamari writes: > >> Hello everyone, >> >> We are pleased to announce the second release candidate for GHC 7.10.3: >> >> https://downloads.haskell.org/~ghc/7.10.3-rc2/ >> > It has been brought to my attention that the configure script in this > source tarballs is out of date. Because of this `configure` will > still fail on OS X. Reports suggest that there may be other issues > unrelated to the configure issue on OS X as well. > Further testing suggests that perhaps the only issue is the out-of-date `configure` script. Mac OS X users with `autotools` installed should be able to run `./boot` in the source tree to bring `configure` up-to-date, at which point this release candidate should be buildable. I'll cut an -rc3 with a fixed `configure` script today. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ezyang at mit.edu Sun Nov 8 23:17:25 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Sun, 08 Nov 2015 15:17:25 -0800 Subject: Questions on the RTS C API regarding threads and tasks In-Reply-To: <5701AB9A-E4F1-4885-AD28-DE6F5480EAD9@gmail.com> References: <5701AB9A-E4F1-4885-AD28-DE6F5480EAD9@gmail.com> Message-ID: <1447024045-sup-6907@sabre> Excerpts from Nicola Gigante's message of 2015-11-04 23:13:51 -0800: > We don't have measurements, but we ruled out this possibility for > performance reasons. Our idea is to make a thin Haskell wrapper > around a tiny bit of highly optimized C code. What's the performance > of locking on MVars? I still don't know what it is you're trying to do. If you have a tiny bit of optimized C code that runs quickly, then you should just make an unsafe FFI call to it (as for as Haskell's runtime is concerned, it's just a "fat instruction"). > While we are at it: are primops callable directly from C? I suppose > calling conventions are different. Anything is "callable" from C, but yes, you have to do the right calling convention. Primops are not easily callable from C. > A question comes to mind: you mentioned "safe" calls. > Are unsafe calls different regarding the detaching of the capability? An unsafe call does not detach the capability. > Also: would a patch to make this possible be accepted? > In particular: > - add a way to make a "ultraunsafe" foreign call that do not loose the > ownership of the calling thread. I don't see what the difference between this and an unsafe foreign call is. > - add a BlockedOnExplicitSleep flag for tso->why_blocked > (And in turn this means managing a different blocking queue, right?) > - export something to reliably put in sleep and resume threads > in this way. > > Is this feasible? Would it be a good idea? I still don't see why you can't just block the thread on an MVar (removing it from the main run queues), and then when you want to resume it write to the MVar. It'll have an added bonus that you'll automatically handle masking/async exceptions correctly. If you find the MVar implementation is too slow, then maybe you can think about making an optimized implementation which doesn't use any synchronization / is inline in the TSO so no allocation is necessary. But in my opinion this is putting the cart before the horse. Edward From carter.schonwald at gmail.com Mon Nov 9 01:34:07 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 8 Nov 2015 20:34:07 -0500 Subject: [ANNOUNCE] 7.10.3 release candidate 2 In-Reply-To: <87mvuohll0.fsf@smart-cactus.org> References: <87pozltpfv.fsf@smart-cactus.org> <87twoxgx0x.fsf@smart-cactus.org> <87mvuohll0.fsf@smart-cactus.org> Message-ID: I'm having trouble setting the make file flags to make the Mac build use the intree gmp. I'm going to dig into this a bit more this evening. On Sunday, November 8, 2015, Ben Gamari wrote: > Ben Gamari > writes: > > > Ben Gamari > writes: > > > >> Hello everyone, > >> > >> We are pleased to announce the second release candidate for GHC 7.10.3: > >> > >> https://downloads.haskell.org/~ghc/7.10.3-rc2/ > >> > > It has been brought to my attention that the configure script in this > > source tarballs is out of date. Because of this `configure` will > > still fail on OS X. Reports suggest that there may be other issues > > unrelated to the configure issue on OS X as well. > > > Further testing suggests that perhaps the only issue is the out-of-date > `configure` script. Mac OS X users with `autotools` installed should be > able to run `./boot` in the source tree to bring `configure` up-to-date, > at which point this release candidate should be buildable. > > I'll cut an -rc3 with a fixed `configure` script today. > > Cheers, > > - Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Mon Nov 9 02:36:44 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Sun, 8 Nov 2015 22:36:44 -0400 Subject: [ANNOUNCE] 7.10.3 release candidate 2 In-Reply-To: References: <87pozltpfv.fsf@smart-cactus.org> <87twoxgx0x.fsf@smart-cactus.org> <87mvuohll0.fsf@smart-cactus.org> Message-ID: I get make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1 make[1]: *** Waiting for unfinished jobs.... checking whether byte ordering is bigendian... no checking assembler .cfi pseudo-op support... yes checking for _ prefix in compiled symbols... yes checking whether .eh_frame section should be read-only... expr: syntax error no checking for __attribute__((visibility("hidden")))... no checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating include/Makefile config.status: creating include/ffi.h config.status: creating Makefile config.status: creating testsuite/Makefile config.status: creating man/Makefile config.status: creating libffi.pc config.status: creating fficonfig.h config.status: linking ../src/x86/ffitarget.h to include/ffitarget.h config.status: executing buildir commands config.status: create top_srcdir/Makefile guessed from local Makefile config.status: build in x86_64-apple-darwin (HOST=) config.status: executing depfiles commands config.status: executing libtool commands config.status: executing include commands config.status: executing src commands # wc on OS X has spaces in its output, which libffi's Makefile # doesn't expect, so we tweak it to sed them out mv libffi/build/Makefile libffi/build/Makefile.orig sed "s#wc -w#wc -w | sed 's/ //g'#" < libffi/build/Makefile.orig > libffi/build/Makefile "touch" libffi/stamp.ffi.static-shared.configure make: *** [all] Error 2 Is that the same error you are getting? On Sun, Nov 8, 2015 at 9:34 PM, Carter Schonwald wrote: > I'm having trouble setting the make file flags to make the Mac build use > the intree gmp. I'm going to dig into this a bit more this evening. > > > On Sunday, November 8, 2015, Ben Gamari wrote: > >> Ben Gamari writes: >> >> > Ben Gamari writes: >> > >> >> Hello everyone, >> >> >> >> We are pleased to announce the second release candidate for GHC 7.10.3: >> >> >> >> https://downloads.haskell.org/~ghc/7.10.3-rc2/ >> >> >> > It has been brought to my attention that the configure script in this >> > source tarballs is out of date. Because of this `configure` will >> > still fail on OS X. Reports suggest that there may be other issues >> > unrelated to the configure issue on OS X as well. >> > >> Further testing suggests that perhaps the only issue is the out-of-date >> `configure` script. Mac OS X users with `autotools` installed should be >> able to run `./boot` in the source tree to bring `configure` up-to-date, >> at which point this release candidate should be buildable. >> >> I'll cut an -rc3 with a fixed `configure` script today. >> >> Cheers, >> >> - Ben >> >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon Nov 9 04:07:55 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 8 Nov 2015 23:07:55 -0500 Subject: [ANNOUNCE] 7.10.3 release candidate 2 In-Reply-To: References: <87pozltpfv.fsf@smart-cactus.org> <87twoxgx0x.fsf@smart-cactus.org> <87mvuohll0.fsf@smart-cactus.org> Message-ID: nope, my error was a bad copy and paste :) heres a link to my build (uses the GCC style rts build, which should be more performant than the default clang one last i checked, also has html docs and should work OS X >= 10.7) https://www.wellposed.com.s3.amazonaws.com/opensource/ghc/releasebuild-unofficial/ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2 (http:// also works) shasum -a512 ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2 003a23929a17e9d01f52ef0a9388b6af51d409eda12627b20500c820f44da1e21976a46da7a50d040072cf5243a05d8f6a4344899fe3c2d8fb3f4f101ef29dce for those who want to check the check the sha sum On Sun, Nov 8, 2015 at 9:36 PM, George Colpitts wrote: > I get > > make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1 > make[1]: *** Waiting for unfinished jobs.... > checking whether byte ordering is bigendian... no > checking assembler .cfi pseudo-op support... yes > checking for _ prefix in compiled symbols... yes > checking whether .eh_frame section should be read-only... expr: syntax > error > no > checking for __attribute__((visibility("hidden")))... no > checking that generated files are newer than configure... done > configure: creating ./config.status > config.status: creating include/Makefile > config.status: creating include/ffi.h > config.status: creating Makefile > config.status: creating testsuite/Makefile > config.status: creating man/Makefile > config.status: creating libffi.pc > config.status: creating fficonfig.h > config.status: linking ../src/x86/ffitarget.h to include/ffitarget.h > config.status: executing buildir commands > config.status: create top_srcdir/Makefile guessed from local Makefile > config.status: build in x86_64-apple-darwin (HOST=) > config.status: executing depfiles commands > config.status: executing libtool commands > config.status: executing include commands > config.status: executing src commands > # wc on OS X has spaces in its output, which libffi's Makefile > # doesn't expect, so we tweak it to sed them out > mv libffi/build/Makefile libffi/build/Makefile.orig > sed "s#wc -w#wc -w | sed 's/ //g'#" < libffi/build/Makefile.orig > > libffi/build/Makefile > "touch" libffi/stamp.ffi.static-shared.configure > make: *** [all] Error 2 > > Is that the same error you are getting? > > > On Sun, Nov 8, 2015 at 9:34 PM, Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> I'm having trouble setting the make file flags to make the Mac build use >> the intree gmp. I'm going to dig into this a bit more this evening. >> >> >> On Sunday, November 8, 2015, Ben Gamari wrote: >> >>> Ben Gamari writes: >>> >>> > Ben Gamari writes: >>> > >>> >> Hello everyone, >>> >> >>> >> We are pleased to announce the second release candidate for GHC >>> 7.10.3: >>> >> >>> >> https://downloads.haskell.org/~ghc/7.10.3-rc2/ >>> >> >>> > It has been brought to my attention that the configure script in this >>> > source tarballs is out of date. Because of this `configure` will >>> > still fail on OS X. Reports suggest that there may be other issues >>> > unrelated to the configure issue on OS X as well. >>> > >>> Further testing suggests that perhaps the only issue is the out-of-date >>> `configure` script. Mac OS X users with `autotools` installed should be >>> able to run `./boot` in the source tree to bring `configure` up-to-date, >>> at which point this release candidate should be buildable. >>> >>> I'll cut an -rc3 with a fixed `configure` script today. >>> >>> Cheers, >>> >>> - Ben >>> >>> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juhpetersen at gmail.com Mon Nov 9 04:33:50 2015 From: juhpetersen at gmail.com (Jens Petersen) Date: Mon, 9 Nov 2015 13:33:50 +0900 Subject: [ANNOUNCE] 7.10.3 release candidate 2 In-Reply-To: <87pozltpfv.fsf@smart-cactus.org> References: <87pozltpfv.fsf@smart-cactus.org> Message-ID: I haven't looked but I note for the record that the size of the tar.xz is increasing: 10547868 Mar 30 2015 ghc-7.10.1-src.tar.xz 11113204 Jul 31 15:50 ghc-7.10.2-src.tar.xz 13270576 Nov 9 13:12 ghc-7.10.2.20151105-src.tar.xz Jens On 8 November 2015 at 07:28, Ben Gamari wrote: > We are pleased to announce the second release candidate for GHC 7.10.3: Thanks! I am building it now in Fedora Copr: https://copr.fedoraproject.org/coprs/petersen/ghc-7.10.3/build/138255/ Jens From simonpj at microsoft.com Mon Nov 9 10:20:49 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 9 Nov 2015 10:20:49 +0000 Subject: [commit: ghc] master: Remove PatSynBuilderId (2208011) In-Reply-To: <20151107235023.DD7BF3A300@ghc.haskell.org> References: <20151107235023.DD7BF3A300@ghc.haskell.org> Message-ID: <2a4628524e7d49acae7ab7e31db3690e@DB4PR30MB030.064d.mgd.msft.net> Matthew, | Remove PatSynBuilderId Thanks for doing this. But it can be simpler still! Suggestion: - remove the new 'labels' field from RecordCon; you only use it in dsExpr - In dsExpr, use the hsRecFieldSel of the first item in 'rbinds' to get a selector-Id - Inside that selector-Id you'll find RecSelId IdInfo; you can use that to get the labels. Would that work? Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of | git at git.haskell.org | Sent: 07 November 2015 23:50 | To: ghc-commits at haskell.org | Subject: [commit: ghc] master: Remove PatSynBuilderId (2208011) | | Repository : ssh://git at git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.haskell. | org%2ftrac%2fghc%2fchangeset%2f22080113f02f6644e2a0e3ce8adb1502346ab3b4%2fgh | c&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c761b0bb4068a4d3ebe4c08d2 | e7ce3c86%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=SQ%2fUVBd2qpKcBoN17ALE | MES4qFLtEuWiJakOotW0IUM%3d | | >--------------------------------------------------------------- | | commit 22080113f02f6644e2a0e3ce8adb1502346ab3b4 | Author: Matthew Pickering | Date: Sat Nov 7 23:46:03 2015 +0000 | | Remove PatSynBuilderId | | Summary: | It was only used to pass field labels between the typechecker and | desugarer. Instead we add an extra field the RecordCon to carry this | information. | | Reviewers: austin, goldfire, bgamari | | Reviewed By: bgamari | | Subscribers: thomie | | Differential Revision: https://phabricator.haskell.org/D1443 | | GHC Trac Issues: #11057 | | | >--------------------------------------------------------------- | | 22080113f02f6644e2a0e3ce8adb1502346ab3b4 | compiler/basicTypes/Id.hs | 11 +---------- | compiler/basicTypes/IdInfo.hs | 3 --- | compiler/deSugar/Coverage.hs | 5 +++-- | compiler/deSugar/DsExpr.hs | 4 +--- | compiler/deSugar/DsMeta.hs | 2 +- | compiler/hsSyn/Convert.hs | 4 +++- | compiler/hsSyn/HsExpr.hs | 4 +++- | compiler/hsSyn/PlaceHolder.hs | 2 ++ | compiler/parser/RdrHsSyn.hs | 4 ++-- | compiler/rename/RnExpr.hs | 6 +++--- | compiler/typecheck/TcExpr.hs | 5 +++-- | compiler/typecheck/TcHsSyn.hs | 4 ++-- compiler/typecheck/TcPatSyn.hs | | 14 ++++++-------- | 13 files changed, 30 insertions(+), 38 deletions(-) | | Diff suppressed because of size. To see it, use: | | git diff-tree --root --patch-with-stat --no-color --find-copies-harder - | -ignore-space-at-eol --cc 22080113f02f6644e2a0e3ce8adb1502346ab3b4 | _______________________________________________ | ghc-commits mailing list | ghc-commits at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell | .org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | commits&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c761b0bb4068a4d3ebe | 4c08d2e7ce3c86%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=BnsSFmFFBiglS%2b | ZyKRkye9LUDZyIh7lDkRoyCLDvb9U%3d From matthewtpickering at gmail.com Mon Nov 9 10:56:06 2015 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Mon, 9 Nov 2015 10:56:06 +0000 Subject: [commit: ghc] master: Remove PatSynBuilderId (2208011) In-Reply-To: <2a4628524e7d49acae7ab7e31db3690e@DB4PR30MB030.064d.mgd.msft.net> References: <20151107235023.DD7BF3A300@ghc.haskell.org> <2a4628524e7d49acae7ab7e31db3690e@DB4PR30MB030.064d.mgd.msft.net> Message-ID: I don't think this would work in the case where there are no fields initialised? Concretely, I am thinking of a case like this: https://phabricator.haskell.org/P72 If I understand right, rbinds would be an empty list so there would be no selector Id to get the relevant ConLike from. On Mon, Nov 9, 2015 at 10:20 AM, Simon Peyton Jones wrote: > Matthew, > > | Remove PatSynBuilderId > > Thanks for doing this. But it can be simpler still! Suggestion: > > - remove the new 'labels' field from RecordCon; you only use it in dsExpr > > - In dsExpr, use the hsRecFieldSel of the first item in 'rbinds' to get a selector-Id > > - Inside that selector-Id you'll find RecSelId IdInfo; you can use that to > get the labels. > > Would that work? > > Simon > > | -----Original Message----- > | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of > | git at git.haskell.org > | Sent: 07 November 2015 23:50 > | To: ghc-commits at haskell.org > | Subject: [commit: ghc] master: Remove PatSynBuilderId (2208011) > | > | Repository : ssh://git at git.haskell.org/ghc > | > | On branch : master > | Link : > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.haskell. > | org%2ftrac%2fghc%2fchangeset%2f22080113f02f6644e2a0e3ce8adb1502346ab3b4%2fgh > | c&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c761b0bb4068a4d3ebe4c08d2 > | e7ce3c86%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=SQ%2fUVBd2qpKcBoN17ALE > | MES4qFLtEuWiJakOotW0IUM%3d > | > | >--------------------------------------------------------------- > | > | commit 22080113f02f6644e2a0e3ce8adb1502346ab3b4 > | Author: Matthew Pickering > | Date: Sat Nov 7 23:46:03 2015 +0000 > | > | Remove PatSynBuilderId > | > | Summary: > | It was only used to pass field labels between the typechecker and > | desugarer. Instead we add an extra field the RecordCon to carry this > | information. > | > | Reviewers: austin, goldfire, bgamari > | > | Reviewed By: bgamari > | > | Subscribers: thomie > | > | Differential Revision: https://phabricator.haskell.org/D1443 > | > | GHC Trac Issues: #11057 > | > | > | >--------------------------------------------------------------- > | > | 22080113f02f6644e2a0e3ce8adb1502346ab3b4 > | compiler/basicTypes/Id.hs | 11 +---------- > | compiler/basicTypes/IdInfo.hs | 3 --- > | compiler/deSugar/Coverage.hs | 5 +++-- > | compiler/deSugar/DsExpr.hs | 4 +--- > | compiler/deSugar/DsMeta.hs | 2 +- > | compiler/hsSyn/Convert.hs | 4 +++- > | compiler/hsSyn/HsExpr.hs | 4 +++- > | compiler/hsSyn/PlaceHolder.hs | 2 ++ > | compiler/parser/RdrHsSyn.hs | 4 ++-- > | compiler/rename/RnExpr.hs | 6 +++--- > | compiler/typecheck/TcExpr.hs | 5 +++-- > | compiler/typecheck/TcHsSyn.hs | 4 ++-- compiler/typecheck/TcPatSyn.hs | > | 14 ++++++-------- > | 13 files changed, 30 insertions(+), 38 deletions(-) > | > | Diff suppressed because of size. To see it, use: > | > | git diff-tree --root --patch-with-stat --no-color --find-copies-harder - > | -ignore-space-at-eol --cc 22080113f02f6644e2a0e3ce8adb1502346ab3b4 > | _______________________________________________ > | ghc-commits mailing list > | ghc-commits at haskell.org > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell > | .org%2fcgi-bin%2fmailman%2flistinfo%2fghc- > | commits&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c761b0bb4068a4d3ebe > | 4c08d2e7ce3c86%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=BnsSFmFFBiglS%2b > | ZyKRkye9LUDZyIh7lDkRoyCLDvb9U%3d From simonpj at microsoft.com Mon Nov 9 11:48:36 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 9 Nov 2015 11:48:36 +0000 Subject: [commit: ghc] master: Remove PatSynBuilderId (2208011) In-Reply-To: References: <20151107235023.DD7BF3A300@ghc.haskell.org> <2a4628524e7d49acae7ab7e31db3690e@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <371c6d358c3e47ae885ecfa49d49ccbe@DB4PR30MB030.064d.mgd.msft.net> | I don't think this would work in the case where there are no fields | initialised? Oh yes, silly me. I was thinking that then we wouldn?t need to look at 'labels' at all, but that's not true. Well, at least then I'd replace [PostTc id [FieldLabel] with (PostTc ConLike). This makes it like ConPatOut in HsPat. Then the (Located id) field is redundant (we can get it from the ConLike), but that?s only true after typechecking, so maybe simpler to keep both. It amounts to moving the call to conLikeFieldLabels from tcExpr (RecordCon ...) to dsExpr (RecordCon ...). A small thing but I think it'd be better. Simon | | Concretely, I am thinking of a case like this: | https://phabricator.haskell.org/P72 | | If I understand right, rbinds would be an empty list so there would be no | selector Id to get the relevant ConLike from. | | On Mon, Nov 9, 2015 at 10:20 AM, Simon Peyton Jones | wrote: | > Matthew, | > | > | Remove PatSynBuilderId | > | > Thanks for doing this. But it can be simpler still! Suggestion: | > | > - remove the new 'labels' field from RecordCon; you only use it in | > dsExpr | > | > - In dsExpr, use the hsRecFieldSel of the first item in 'rbinds' to | > get a selector-Id | > | > - Inside that selector-Id you'll find RecSelId IdInfo; you can use that to | > get the labels. | > | > Would that work? | > | > Simon | > | > | -----Original Message----- | > | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On | > | Behalf Of git at git.haskell.org | > | Sent: 07 November 2015 23:50 | > | To: ghc-commits at haskell.org | > | Subject: [commit: ghc] master: Remove PatSynBuilderId (2208011) | > | | > | Repository : ssh://git at git.haskell.org/ghc | > | | > | On branch : master | > | Link : | > | | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.haskell. | > | | > | org%2ftrac%2fghc%2fchangeset%2f22080113f02f6644e2a0e3ce8adb1502346ab | > | 3b4%2fgh | > | | > | c&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c761b0bb4068a4d3e | > | be4c08d2 | > | e7ce3c86%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=SQ%2fUVBd2qpKc | > | BoN17ALE | > | MES4qFLtEuWiJakOotW0IUM%3d | > | | > | >--------------------------------------------------------------- | > | | > | commit 22080113f02f6644e2a0e3ce8adb1502346ab3b4 | > | Author: Matthew Pickering | > | Date: Sat Nov 7 23:46:03 2015 +0000 | > | | > | Remove PatSynBuilderId | > | | > | Summary: | > | It was only used to pass field labels between the typechecker and | > | desugarer. Instead we add an extra field the RecordCon to carry | this | > | information. | > | | > | Reviewers: austin, goldfire, bgamari | > | | > | Reviewed By: bgamari | > | | > | Subscribers: thomie | > | | > | Differential Revision: https://phabricator.haskell.org/D1443 | > | | > | GHC Trac Issues: #11057 | > | | > | | > | >--------------------------------------------------------------- | > | | > | 22080113f02f6644e2a0e3ce8adb1502346ab3b4 | > | compiler/basicTypes/Id.hs | 11 +---------- | > | compiler/basicTypes/IdInfo.hs | 3 --- | > | compiler/deSugar/Coverage.hs | 5 +++-- | > | compiler/deSugar/DsExpr.hs | 4 +--- | > | compiler/deSugar/DsMeta.hs | 2 +- | > | compiler/hsSyn/Convert.hs | 4 +++- | > | compiler/hsSyn/HsExpr.hs | 4 +++- | > | compiler/hsSyn/PlaceHolder.hs | 2 ++ | > | compiler/parser/RdrHsSyn.hs | 4 ++-- | > | compiler/rename/RnExpr.hs | 6 +++--- | > | compiler/typecheck/TcExpr.hs | 5 +++-- | > | compiler/typecheck/TcHsSyn.hs | 4 ++-- | > | compiler/typecheck/TcPatSyn.hs | | > | 14 ++++++-------- | > | 13 files changed, 30 insertions(+), 38 deletions(-) | > | | > | Diff suppressed because of size. To see it, use: | > | | > | git diff-tree --root --patch-with-stat --no-color | > | --find-copies-harder - -ignore-space-at-eol --cc | > | 22080113f02f6644e2a0e3ce8adb1502346ab3b4 | > | _______________________________________________ | > | ghc-commits mailing list | > | ghc-commits at haskell.org | > | | > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail | > | .haskell | > | .org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | > | | > | commits&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c761b0bb406 | > | 8a4d3ebe | > | 4c08d2e7ce3c86%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=BnsSFmFF | > | BiglS%2b | > | ZyKRkye9LUDZyIh7lDkRoyCLDvb9U%3d From george.colpitts at gmail.com Mon Nov 9 12:25:08 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Mon, 9 Nov 2015 08:25:08 -0400 Subject: [ANNOUNCE] 7.10.3 release candidate 2 In-Reply-To: References: <87pozltpfv.fsf@smart-cactus.org> <87twoxgx0x.fsf@smart-cactus.org> <87mvuohll0.fsf@smart-cactus.org> Message-ID: Thanks Carter. I will check out your build Any ideas as to why mine failed? I am on OS 10.11.1 with Xcode 7.1 compiling using clang with make -j5 After the error shown below I typed make again and got: ... checking whether clang is gcc... yes checking compiler clang -m32 -O2 -pedantic -fPIC -fomit-frame-pointer ... no, gnupro alpha ev6 char spilling checking compiler clang -O2 -pedantic -fPIC -fomit-frame-pointer ... no, gnupro alpha ev6 char spilling configure: error: could not find a working compiler, see config.log for details make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1 make: *** [all] Error 2 On Mon, Nov 9, 2015 at 12:07 AM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > nope, my error was a bad copy and paste :) > > heres a link to my build (uses the GCC style rts build, which should be > more performant than the default clang one last i checked, also has html > docs and should work OS X >= 10.7) > > > https://www.wellposed.com.s3.amazonaws.com/opensource/ghc/releasebuild-unofficial/ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2 > > (http:// also works) > > > shasum -a512 ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2 > 003a23929a17e9d01f52ef0a9388b6af51d409eda12627b20500c820f44da1e21976a46da7a50d040072cf5243a05d8f6a4344899fe3c2d8fb3f4f101ef29dce > > > for those who want to check the check the sha sum > > > > On Sun, Nov 8, 2015 at 9:36 PM, George Colpitts > wrote: > >> I get >> >> make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1 >> make[1]: *** Waiting for unfinished jobs.... >> checking whether byte ordering is bigendian... no >> checking assembler .cfi pseudo-op support... yes >> checking for _ prefix in compiled symbols... yes >> checking whether .eh_frame section should be read-only... expr: syntax >> error >> no >> checking for __attribute__((visibility("hidden")))... no >> checking that generated files are newer than configure... done >> configure: creating ./config.status >> config.status: creating include/Makefile >> config.status: creating include/ffi.h >> config.status: creating Makefile >> config.status: creating testsuite/Makefile >> config.status: creating man/Makefile >> config.status: creating libffi.pc >> config.status: creating fficonfig.h >> config.status: linking ../src/x86/ffitarget.h to include/ffitarget.h >> config.status: executing buildir commands >> config.status: create top_srcdir/Makefile guessed from local Makefile >> config.status: build in x86_64-apple-darwin (HOST=) >> config.status: executing depfiles commands >> config.status: executing libtool commands >> config.status: executing include commands >> config.status: executing src commands >> # wc on OS X has spaces in its output, which libffi's Makefile >> # doesn't expect, so we tweak it to sed them out >> mv libffi/build/Makefile libffi/build/Makefile.orig >> sed "s#wc -w#wc -w | sed 's/ //g'#" < libffi/build/Makefile.orig > >> libffi/build/Makefile >> "touch" libffi/stamp.ffi.static-shared.configure >> make: *** [all] Error 2 >> >> Is that the same error you are getting? >> >> >> On Sun, Nov 8, 2015 at 9:34 PM, Carter Schonwald < >> carter.schonwald at gmail.com> wrote: >> >>> I'm having trouble setting the make file flags to make the Mac build use >>> the intree gmp. I'm going to dig into this a bit more this evening. >>> >>> >>> On Sunday, November 8, 2015, Ben Gamari wrote: >>> >>>> Ben Gamari writes: >>>> >>>> > Ben Gamari writes: >>>> > >>>> >> Hello everyone, >>>> >> >>>> >> We are pleased to announce the second release candidate for GHC >>>> 7.10.3: >>>> >> >>>> >> https://downloads.haskell.org/~ghc/7.10.3-rc2/ >>>> >> >>>> > It has been brought to my attention that the configure script in this >>>> > source tarballs is out of date. Because of this `configure` will >>>> > still fail on OS X. Reports suggest that there may be other issues >>>> > unrelated to the configure issue on OS X as well. >>>> > >>>> Further testing suggests that perhaps the only issue is the out-of-date >>>> `configure` script. Mac OS X users with `autotools` installed should be >>>> able to run `./boot` in the source tree to bring `configure` up-to-date, >>>> at which point this release candidate should be buildable. >>>> >>>> I'll cut an -rc3 with a fixed `configure` script today. >>>> >>>> Cheers, >>>> >>>> - Ben >>>> >>>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Mon Nov 9 12:28:44 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Mon, 9 Nov 2015 08:28:44 -0400 Subject: [ANNOUNCE] 7.10.3 release candidate 2 In-Reply-To: References: <87pozltpfv.fsf@smart-cactus.org> <87twoxgx0x.fsf@smart-cactus.org> <87mvuohll0.fsf@smart-cactus.org> Message-ID: Download works with http When I try to download your build using https I get This Connection is Untrusted You have asked Firefox to connect securely to www.wellposed.com.s3.amazonaws.com, but we can't confirm that your connection is secure. Normally, when you try to connect securely, sites will present trusted identification to prove that you are going to the right place. However, this site's identity can't be verified. What Should I Do? If you usually connect to this site without problems, this error could mean that someone is trying to impersonate the site, and you shouldn't continue. www.wellposed.com.s3.amazonaws.com uses an invalid security certificate. The certificate is only valid for the following names: *.s3.amazonaws.com, s3.amazonaws.com (Error code: ssl_error_bad_cert_domain) If you understand what's going on, you can tell Firefox to start trusting this site's identification. Even if you trust the site, this error could mean that someone is tampering with your connection. Don't add an exception unless you know there's a good reason why this site doesn't use trusted identification. On Mon, Nov 9, 2015 at 12:07 AM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > nope, my error was a bad copy and paste :) > > heres a link to my build (uses the GCC style rts build, which should be > more performant than the default clang one last i checked, also has html > docs and should work OS X >= 10.7) > > > https://www.wellposed.com.s3.amazonaws.com/opensource/ghc/releasebuild-unofficial/ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2 > > (http:// also works) > > > shasum -a512 ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2 > 003a23929a17e9d01f52ef0a9388b6af51d409eda12627b20500c820f44da1e21976a46da7a50d040072cf5243a05d8f6a4344899fe3c2d8fb3f4f101ef29dce > > > for those who want to check the check the sha sum > > > > On Sun, Nov 8, 2015 at 9:36 PM, George Colpitts > wrote: > >> I get >> >> make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1 >> make[1]: *** Waiting for unfinished jobs.... >> checking whether byte ordering is bigendian... no >> checking assembler .cfi pseudo-op support... yes >> checking for _ prefix in compiled symbols... yes >> checking whether .eh_frame section should be read-only... expr: syntax >> error >> no >> checking for __attribute__((visibility("hidden")))... no >> checking that generated files are newer than configure... done >> configure: creating ./config.status >> config.status: creating include/Makefile >> config.status: creating include/ffi.h >> config.status: creating Makefile >> config.status: creating testsuite/Makefile >> config.status: creating man/Makefile >> config.status: creating libffi.pc >> config.status: creating fficonfig.h >> config.status: linking ../src/x86/ffitarget.h to include/ffitarget.h >> config.status: executing buildir commands >> config.status: create top_srcdir/Makefile guessed from local Makefile >> config.status: build in x86_64-apple-darwin (HOST=) >> config.status: executing depfiles commands >> config.status: executing libtool commands >> config.status: executing include commands >> config.status: executing src commands >> # wc on OS X has spaces in its output, which libffi's Makefile >> # doesn't expect, so we tweak it to sed them out >> mv libffi/build/Makefile libffi/build/Makefile.orig >> sed "s#wc -w#wc -w | sed 's/ //g'#" < libffi/build/Makefile.orig > >> libffi/build/Makefile >> "touch" libffi/stamp.ffi.static-shared.configure >> make: *** [all] Error 2 >> >> Is that the same error you are getting? >> >> >> On Sun, Nov 8, 2015 at 9:34 PM, Carter Schonwald < >> carter.schonwald at gmail.com> wrote: >> >>> I'm having trouble setting the make file flags to make the Mac build use >>> the intree gmp. I'm going to dig into this a bit more this evening. >>> >>> >>> On Sunday, November 8, 2015, Ben Gamari wrote: >>> >>>> Ben Gamari writes: >>>> >>>> > Ben Gamari writes: >>>> > >>>> >> Hello everyone, >>>> >> >>>> >> We are pleased to announce the second release candidate for GHC >>>> 7.10.3: >>>> >> >>>> >> https://downloads.haskell.org/~ghc/7.10.3-rc2/ >>>> >> >>>> > It has been brought to my attention that the configure script in this >>>> > source tarballs is out of date. Because of this `configure` will >>>> > still fail on OS X. Reports suggest that there may be other issues >>>> > unrelated to the configure issue on OS X as well. >>>> > >>>> Further testing suggests that perhaps the only issue is the out-of-date >>>> `configure` script. Mac OS X users with `autotools` installed should be >>>> able to run `./boot` in the source tree to bring `configure` up-to-date, >>>> at which point this release candidate should be buildable. >>>> >>>> I'll cut an -rc3 with a fixed `configure` script today. >>>> >>>> Cheers, >>>> >>>> - Ben >>>> >>>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Mon Nov 9 13:19:26 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Mon, 9 Nov 2015 09:19:26 -0400 Subject: [ANNOUNCE] 7.10.3 release candidate 2 In-Reply-To: References: <87pozltpfv.fsf@smart-cactus.org> <87twoxgx0x.fsf@smart-cactus.org> <87mvuohll0.fsf@smart-cactus.org> Message-ID: install into /opt works fine However the INSTALL file says `make show-install-setup' prints the details of where the different pieces of the bundle are heading when -- possibly helpful but this doesn't work: make show-install-setup make: *** No rule to make target `show-install-setup'. Stop. I installed in /opt as I didn't want to overwrite my current ghc. It would be nice if there was an uninstall target for make. I removed /opt/bin/* and /opt/lib/* as there were only ghc files there. Then I did an uninstall-hs (uninstall of Haskell Platform) Then install into the default (/usr/local) I get: /usr/bin/install -c -m 644 docs/man/ghc.1 "/usr/local/share/man/man1" install: /usr/local/share/man/man1/ghc.1: No such file or directory make[1]: *** [install_man] Error 71 make: *** [install] Error 2 I then did ls -l /usr/local/share/man/man1/ghc.1 lrwxr-xr-x 1 gcolpitts admin 81 Oct 11 17:35 /usr/local/share/man/man1/ghc.1 -> /Library/Frameworks/GHC.framework/Versions/7.10.2-x86_64/usr/share/man/man1/ghc.1 then rm /usr/local/share/man/man1/ghc.1 and then "make install" worked However cabal install hlint didn't work because it couldn't install text-1.2.1.3: cabal install text ... Data/Text.hs:203:8: Could not find module ?Control.DeepSeq? Perhaps you haven't installed the profiling libraries for package ?deepseq-1.4.1.1 at deeps_6vMKxt5sPFR0XsbRWvvq59?? Use -v to see a list of the files searched for. Data/Text.hs:208:8: Could not find module ?Data.Char? Perhaps you haven't installed the profiling libraries for package ?base-4.8.2.0?? Use -v to see a list of the files searched for. Data/Text.hs:209:8: Could not find module ?Data.Data? Perhaps you haven't installed the profiling libraries for package ?base-4.8.2.0?? Use -v to see a list of the files searched for. Data/Text.hs:211:8: Could not find module ?Control.Monad? Perhaps you haven't installed the profiling libraries for package ?base-4.8.2.0?? Use -v to see a list of the files searched for. Data/Text.hs:212:8: Could not find module ?Control.Monad.ST? Perhaps you haven't installed the profiling libraries for package ?base-4.8.2.0?? ... ghc-pkg list /usr/local/lib/ghc-7.10.2.20151105/package.conf.d: Cabal-1.22.4.0 array-0.5.1.0 base-4.8.2.0 bin-package-db-0.0.0.0 binary-0.7.5.0 rts-1.0 bytestring-0.10.6.0 containers-0.5.6.2 deepseq-1.4.1.1 directory-1.2.2.0 filepath-1.4.0.0 (ghc-7.10.2.20151105) ghc-prim-0.4.0.0 haskeline-0.7.2.1 hoopl-3.10.0.2 hpc-0.6.0.2 integer-gmp-1.0.0.0 pretty-1.1.2.0 process-1.2.3.0 template-haskell-2.10.0.0 terminfo-0.4.0.1 time-1.5.0.1 transformers-0.4.2.0 unix-2.7.1.0 xhtml-3000.2.1 ghc-pkg check Similar problems with cabal install vector On Mon, Nov 9, 2015 at 12:07 AM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > nope, my error was a bad copy and paste :) > > heres a link to my build (uses the GCC style rts build, which should be > more performant than the default clang one last i checked, also has html > docs and should work OS X >= 10.7) > > > https://www.wellposed.com.s3.amazonaws.com/opensource/ghc/releasebuild-unofficial/ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2 > > (http:// also works) > > > shasum -a512 ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2 > 003a23929a17e9d01f52ef0a9388b6af51d409eda12627b20500c820f44da1e21976a46da7a50d040072cf5243a05d8f6a4344899fe3c2d8fb3f4f101ef29dce > > > for those who want to check the check the sha sum > > > > On Sun, Nov 8, 2015 at 9:36 PM, George Colpitts > wrote: > >> I get >> >> make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1 >> make[1]: *** Waiting for unfinished jobs.... >> checking whether byte ordering is bigendian... no >> checking assembler .cfi pseudo-op support... yes >> checking for _ prefix in compiled symbols... yes >> checking whether .eh_frame section should be read-only... expr: syntax >> error >> no >> checking for __attribute__((visibility("hidden")))... no >> checking that generated files are newer than configure... done >> configure: creating ./config.status >> config.status: creating include/Makefile >> config.status: creating include/ffi.h >> config.status: creating Makefile >> config.status: creating testsuite/Makefile >> config.status: creating man/Makefile >> config.status: creating libffi.pc >> config.status: creating fficonfig.h >> config.status: linking ../src/x86/ffitarget.h to include/ffitarget.h >> config.status: executing buildir commands >> config.status: create top_srcdir/Makefile guessed from local Makefile >> config.status: build in x86_64-apple-darwin (HOST=) >> config.status: executing depfiles commands >> config.status: executing libtool commands >> config.status: executing include commands >> config.status: executing src commands >> # wc on OS X has spaces in its output, which libffi's Makefile >> # doesn't expect, so we tweak it to sed them out >> mv libffi/build/Makefile libffi/build/Makefile.orig >> sed "s#wc -w#wc -w | sed 's/ //g'#" < libffi/build/Makefile.orig > >> libffi/build/Makefile >> "touch" libffi/stamp.ffi.static-shared.configure >> make: *** [all] Error 2 >> >> Is that the same error you are getting? >> >> >> On Sun, Nov 8, 2015 at 9:34 PM, Carter Schonwald < >> carter.schonwald at gmail.com> wrote: >> >>> I'm having trouble setting the make file flags to make the Mac build use >>> the intree gmp. I'm going to dig into this a bit more this evening. >>> >>> >>> On Sunday, November 8, 2015, Ben Gamari wrote: >>> >>>> Ben Gamari writes: >>>> >>>> > Ben Gamari writes: >>>> > >>>> >> Hello everyone, >>>> >> >>>> >> We are pleased to announce the second release candidate for GHC >>>> 7.10.3: >>>> >> >>>> >> https://downloads.haskell.org/~ghc/7.10.3-rc2/ >>>> >> >>>> > It has been brought to my attention that the configure script in this >>>> > source tarballs is out of date. Because of this `configure` will >>>> > still fail on OS X. Reports suggest that there may be other issues >>>> > unrelated to the configure issue on OS X as well. >>>> > >>>> Further testing suggests that perhaps the only issue is the out-of-date >>>> `configure` script. Mac OS X users with `autotools` installed should be >>>> able to run `./boot` in the source tree to bring `configure` up-to-date, >>>> at which point this release candidate should be buildable. >>>> >>>> I'll cut an -rc3 with a fixed `configure` script today. >>>> >>>> Cheers, >>>> >>>> - Ben >>>> >>>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Mon Nov 9 13:32:53 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 09 Nov 2015 14:32:53 +0100 Subject: [ANNOUNCE] 7.10.3 release candidate 2 In-Reply-To: References: <87pozltpfv.fsf@smart-cactus.org> <87twoxgx0x.fsf@smart-cactus.org> <87mvuohll0.fsf@smart-cactus.org> Message-ID: <87h9kvguwq.fsf@smart-cactus.org> George Colpitts writes: > I get > > make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1 > make[1]: *** Waiting for unfinished jobs.... It looks like the build failed somewhere before this point. Could you provide a more complete log? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From carter.schonwald at gmail.com Mon Nov 9 13:51:23 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 9 Nov 2015 08:51:23 -0500 Subject: [ANNOUNCE] 7.10.3 release candidate 2 In-Reply-To: References: <87pozltpfv.fsf@smart-cactus.org> <87twoxgx0x.fsf@smart-cactus.org> <87mvuohll0.fsf@smart-cactus.org> Message-ID: Why were you trying to do Haskell platform things ? This isn't a Haskell platform build. Just configure --prefix=blsh and then make install On Monday, November 9, 2015, George Colpitts wrote: > install into /opt works fine > However the INSTALL file says > > `make show-install-setup' prints the details of where the different > pieces of the bundle are heading when -- possibly helpful > > but this doesn't work: > > make show-install-setup > make: *** No rule to make target `show-install-setup'. Stop. > > I installed in /opt as I didn't want to overwrite my current ghc. It would > be nice if there was an uninstall target for make. > > I removed /opt/bin/* and /opt/lib/* as there were only ghc files there. > Then I did an uninstall-hs (uninstall of Haskell Platform) > Then install into the default (/usr/local) I get: > > /usr/bin/install -c -m 644 docs/man/ghc.1 "/usr/local/share/man/man1" > install: /usr/local/share/man/man1/ghc.1: No such file or directory > make[1]: *** [install_man] Error 71 > make: *** [install] Error 2 > > I then did > > ls -l /usr/local/share/man/man1/ghc.1 > lrwxr-xr-x 1 gcolpitts admin 81 Oct 11 17:35 > /usr/local/share/man/man1/ghc.1 -> > /Library/Frameworks/GHC.framework/Versions/7.10.2-x86_64/usr/share/man/man1/ghc.1 > > then > > rm /usr/local/share/man/man1/ghc.1 > > and then "make install" worked > > However cabal install hlint didn't work because it couldn't install > text-1.2.1.3: > > cabal install text > ... > > Data/Text.hs:203:8: > Could not find module ?Control.DeepSeq? > Perhaps you haven't installed the profiling libraries for package > ?deepseq-1.4.1.1 at deeps_6vMKxt5sPFR0XsbRWvvq59?? > Use -v to see a list of the files searched for. > > Data/Text.hs:208:8: > Could not find module ?Data.Char? > Perhaps you haven't installed the profiling libraries for package > ?base-4.8.2.0?? > Use -v to see a list of the files searched for. > > Data/Text.hs:209:8: > Could not find module ?Data.Data? > Perhaps you haven't installed the profiling libraries for package > ?base-4.8.2.0?? > Use -v to see a list of the files searched for. > > Data/Text.hs:211:8: > Could not find module ?Control.Monad? > Perhaps you haven't installed the profiling libraries for package > ?base-4.8.2.0?? > Use -v to see a list of the files searched for. > > Data/Text.hs:212:8: > Could not find module ?Control.Monad.ST? > Perhaps you haven't installed the profiling libraries for package > ?base-4.8.2.0?? > ... > > > ghc-pkg list > /usr/local/lib/ghc-7.10.2.20151105/package.conf.d: > Cabal-1.22.4.0 > array-0.5.1.0 > base-4.8.2.0 > bin-package-db-0.0.0.0 > binary-0.7.5.0 > rts-1.0 > bytestring-0.10.6.0 > containers-0.5.6.2 > deepseq-1.4.1.1 > directory-1.2.2.0 > filepath-1.4.0.0 > (ghc-7.10.2.20151105) > ghc-prim-0.4.0.0 > haskeline-0.7.2.1 > hoopl-3.10.0.2 > hpc-0.6.0.2 > integer-gmp-1.0.0.0 > pretty-1.1.2.0 > process-1.2.3.0 > template-haskell-2.10.0.0 > terminfo-0.4.0.1 > time-1.5.0.1 > transformers-0.4.2.0 > unix-2.7.1.0 > xhtml-3000.2.1 > > ghc-pkg check > > Similar problems with cabal install vector > > > > On Mon, Nov 9, 2015 at 12:07 AM, Carter Schonwald < > carter.schonwald at gmail.com > > wrote: > >> nope, my error was a bad copy and paste :) >> >> heres a link to my build (uses the GCC style rts build, which should be >> more performant than the default clang one last i checked, also has html >> docs and should work OS X >= 10.7) >> >> >> https://www.wellposed.com.s3.amazonaws.com/opensource/ghc/releasebuild-unofficial/ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2 >> >> (http:// also works) >> >> >> shasum -a512 ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2 >> 003a23929a17e9d01f52ef0a9388b6af51d409eda12627b20500c820f44da1e21976a46da7a50d040072cf5243a05d8f6a4344899fe3c2d8fb3f4f101ef29dce >> >> >> for those who want to check the check the sha sum >> >> >> >> On Sun, Nov 8, 2015 at 9:36 PM, George Colpitts < >> george.colpitts at gmail.com >> > wrote: >> >>> I get >>> >>> make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1 >>> make[1]: *** Waiting for unfinished jobs.... >>> checking whether byte ordering is bigendian... no >>> checking assembler .cfi pseudo-op support... yes >>> checking for _ prefix in compiled symbols... yes >>> checking whether .eh_frame section should be read-only... expr: syntax >>> error >>> no >>> checking for __attribute__((visibility("hidden")))... no >>> checking that generated files are newer than configure... done >>> configure: creating ./config.status >>> config.status: creating include/Makefile >>> config.status: creating include/ffi.h >>> config.status: creating Makefile >>> config.status: creating testsuite/Makefile >>> config.status: creating man/Makefile >>> config.status: creating libffi.pc >>> config.status: creating fficonfig.h >>> config.status: linking ../src/x86/ffitarget.h to include/ffitarget.h >>> config.status: executing buildir commands >>> config.status: create top_srcdir/Makefile guessed from local Makefile >>> config.status: build in x86_64-apple-darwin (HOST=) >>> config.status: executing depfiles commands >>> config.status: executing libtool commands >>> config.status: executing include commands >>> config.status: executing src commands >>> # wc on OS X has spaces in its output, which libffi's Makefile >>> # doesn't expect, so we tweak it to sed them out >>> mv libffi/build/Makefile libffi/build/Makefile.orig >>> sed "s#wc -w#wc -w | sed 's/ //g'#" < libffi/build/Makefile.orig > >>> libffi/build/Makefile >>> "touch" libffi/stamp.ffi.static-shared.configure >>> make: *** [all] Error 2 >>> >>> Is that the same error you are getting? >>> >>> >>> On Sun, Nov 8, 2015 at 9:34 PM, Carter Schonwald < >>> carter.schonwald at gmail.com >>> > wrote: >>> >>>> I'm having trouble setting the make file flags to make the Mac build >>>> use the intree gmp. I'm going to dig into this a bit more this evening. >>>> >>>> >>>> On Sunday, November 8, 2015, Ben Gamari >>> > wrote: >>>> >>>>> Ben Gamari writes: >>>>> >>>>> > Ben Gamari writes: >>>>> > >>>>> >> Hello everyone, >>>>> >> >>>>> >> We are pleased to announce the second release candidate for GHC >>>>> 7.10.3: >>>>> >> >>>>> >> https://downloads.haskell.org/~ghc/7.10.3-rc2/ >>>>> >> >>>>> > It has been brought to my attention that the configure script in this >>>>> > source tarballs is out of date. Because of this `configure` will >>>>> > still fail on OS X. Reports suggest that there may be other issues >>>>> > unrelated to the configure issue on OS X as well. >>>>> > >>>>> Further testing suggests that perhaps the only issue is the out-of-date >>>>> `configure` script. Mac OS X users with `autotools` installed should be >>>>> able to run `./boot` in the source tree to bring `configure` >>>>> up-to-date, >>>>> at which point this release candidate should be buildable. >>>>> >>>>> I'll cut an -rc3 with a fixed `configure` script today. >>>>> >>>>> Cheers, >>>>> >>>>> - Ben >>>>> >>>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon Nov 9 13:53:27 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 9 Nov 2015 08:53:27 -0500 Subject: [ANNOUNCE] 7.10.3 release candidate 2 In-Reply-To: References: <87pozltpfv.fsf@smart-cactus.org> <87twoxgx0x.fsf@smart-cactus.org> <87mvuohll0.fsf@smart-cactus.org> Message-ID: The cert warning is merely because it's using the aws cert and that one isn't a wild card. I assume we can generally assume the aws cert isn't broken :) On Monday, November 9, 2015, Carter Schonwald wrote: > Why were you trying to do Haskell platform things ? > This isn't a Haskell platform build. Just configure --prefix=blsh and > then make install > > On Monday, November 9, 2015, George Colpitts > wrote: > >> install into /opt works fine >> However the INSTALL file says >> >> `make show-install-setup' prints the details of where the different >> pieces of the bundle are heading when -- possibly helpful >> >> but this doesn't work: >> >> make show-install-setup >> make: *** No rule to make target `show-install-setup'. Stop. >> >> I installed in /opt as I didn't want to overwrite my current ghc. It >> would be nice if there was an uninstall target for make. >> >> I removed /opt/bin/* and /opt/lib/* as there were only ghc files there. >> Then I did an uninstall-hs (uninstall of Haskell Platform) >> Then install into the default (/usr/local) I get: >> >> /usr/bin/install -c -m 644 docs/man/ghc.1 "/usr/local/share/man/man1" >> install: /usr/local/share/man/man1/ghc.1: No such file or directory >> make[1]: *** [install_man] Error 71 >> make: *** [install] Error 2 >> >> I then did >> >> ls -l /usr/local/share/man/man1/ghc.1 >> lrwxr-xr-x 1 gcolpitts admin 81 Oct 11 17:35 >> /usr/local/share/man/man1/ghc.1 -> >> /Library/Frameworks/GHC.framework/Versions/7.10.2-x86_64/usr/share/man/man1/ghc.1 >> >> then >> >> rm /usr/local/share/man/man1/ghc.1 >> >> and then "make install" worked >> >> However cabal install hlint didn't work because it couldn't install >> text-1.2.1.3: >> >> cabal install text >> ... >> >> Data/Text.hs:203:8: >> Could not find module ?Control.DeepSeq? >> Perhaps you haven't installed the profiling libraries for package >> ?deepseq-1.4.1.1 at deeps_6vMKxt5sPFR0XsbRWvvq59?? >> Use -v to see a list of the files searched for. >> >> Data/Text.hs:208:8: >> Could not find module ?Data.Char? >> Perhaps you haven't installed the profiling libraries for package >> ?base-4.8.2.0?? >> Use -v to see a list of the files searched for. >> >> Data/Text.hs:209:8: >> Could not find module ?Data.Data? >> Perhaps you haven't installed the profiling libraries for package >> ?base-4.8.2.0?? >> Use -v to see a list of the files searched for. >> >> Data/Text.hs:211:8: >> Could not find module ?Control.Monad? >> Perhaps you haven't installed the profiling libraries for package >> ?base-4.8.2.0?? >> Use -v to see a list of the files searched for. >> >> Data/Text.hs:212:8: >> Could not find module ?Control.Monad.ST? >> Perhaps you haven't installed the profiling libraries for package >> ?base-4.8.2.0?? >> ... >> >> >> ghc-pkg list >> /usr/local/lib/ghc-7.10.2.20151105/package.conf.d: >> Cabal-1.22.4.0 >> array-0.5.1.0 >> base-4.8.2.0 >> bin-package-db-0.0.0.0 >> binary-0.7.5.0 >> rts-1.0 >> bytestring-0.10.6.0 >> containers-0.5.6.2 >> deepseq-1.4.1.1 >> directory-1.2.2.0 >> filepath-1.4.0.0 >> (ghc-7.10.2.20151105) >> ghc-prim-0.4.0.0 >> haskeline-0.7.2.1 >> hoopl-3.10.0.2 >> hpc-0.6.0.2 >> integer-gmp-1.0.0.0 >> pretty-1.1.2.0 >> process-1.2.3.0 >> template-haskell-2.10.0.0 >> terminfo-0.4.0.1 >> time-1.5.0.1 >> transformers-0.4.2.0 >> unix-2.7.1.0 >> xhtml-3000.2.1 >> >> ghc-pkg check >> >> Similar problems with cabal install vector >> >> >> >> On Mon, Nov 9, 2015 at 12:07 AM, Carter Schonwald < >> carter.schonwald at gmail.com> wrote: >> >>> nope, my error was a bad copy and paste :) >>> >>> heres a link to my build (uses the GCC style rts build, which should be >>> more performant than the default clang one last i checked, also has html >>> docs and should work OS X >= 10.7) >>> >>> >>> https://www.wellposed.com.s3.amazonaws.com/opensource/ghc/releasebuild-unofficial/ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2 >>> >>> (http:// also works) >>> >>> >>> shasum -a512 ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2 >>> 003a23929a17e9d01f52ef0a9388b6af51d409eda12627b20500c820f44da1e21976a46da7a50d040072cf5243a05d8f6a4344899fe3c2d8fb3f4f101ef29dce >>> >>> >>> for those who want to check the check the sha sum >>> >>> >>> >>> On Sun, Nov 8, 2015 at 9:36 PM, George Colpitts < >>> george.colpitts at gmail.com> wrote: >>> >>>> I get >>>> >>>> make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1 >>>> make[1]: *** Waiting for unfinished jobs.... >>>> checking whether byte ordering is bigendian... no >>>> checking assembler .cfi pseudo-op support... yes >>>> checking for _ prefix in compiled symbols... yes >>>> checking whether .eh_frame section should be read-only... expr: syntax >>>> error >>>> no >>>> checking for __attribute__((visibility("hidden")))... no >>>> checking that generated files are newer than configure... done >>>> configure: creating ./config.status >>>> config.status: creating include/Makefile >>>> config.status: creating include/ffi.h >>>> config.status: creating Makefile >>>> config.status: creating testsuite/Makefile >>>> config.status: creating man/Makefile >>>> config.status: creating libffi.pc >>>> config.status: creating fficonfig.h >>>> config.status: linking ../src/x86/ffitarget.h to include/ffitarget.h >>>> config.status: executing buildir commands >>>> config.status: create top_srcdir/Makefile guessed from local Makefile >>>> config.status: build in x86_64-apple-darwin (HOST=) >>>> config.status: executing depfiles commands >>>> config.status: executing libtool commands >>>> config.status: executing include commands >>>> config.status: executing src commands >>>> # wc on OS X has spaces in its output, which libffi's Makefile >>>> # doesn't expect, so we tweak it to sed them out >>>> mv libffi/build/Makefile libffi/build/Makefile.orig >>>> sed "s#wc -w#wc -w | sed 's/ //g'#" < libffi/build/Makefile.orig > >>>> libffi/build/Makefile >>>> "touch" libffi/stamp.ffi.static-shared.configure >>>> make: *** [all] Error 2 >>>> >>>> Is that the same error you are getting? >>>> >>>> >>>> On Sun, Nov 8, 2015 at 9:34 PM, Carter Schonwald < >>>> carter.schonwald at gmail.com> wrote: >>>> >>>>> I'm having trouble setting the make file flags to make the Mac build >>>>> use the intree gmp. I'm going to dig into this a bit more this evening. >>>>> >>>>> >>>>> On Sunday, November 8, 2015, Ben Gamari wrote: >>>>> >>>>>> Ben Gamari writes: >>>>>> >>>>>> > Ben Gamari writes: >>>>>> > >>>>>> >> Hello everyone, >>>>>> >> >>>>>> >> We are pleased to announce the second release candidate for GHC >>>>>> 7.10.3: >>>>>> >> >>>>>> >> https://downloads.haskell.org/~ghc/7.10.3-rc2/ >>>>>> >> >>>>>> > It has been brought to my attention that the configure script in >>>>>> this >>>>>> > source tarballs is out of date. Because of this `configure` will >>>>>> > still fail on OS X. Reports suggest that there may be other issues >>>>>> > unrelated to the configure issue on OS X as well. >>>>>> > >>>>>> Further testing suggests that perhaps the only issue is the >>>>>> out-of-date >>>>>> `configure` script. Mac OS X users with `autotools` installed should >>>>>> be >>>>>> able to run `./boot` in the source tree to bring `configure` >>>>>> up-to-date, >>>>>> at which point this release candidate should be buildable. >>>>>> >>>>>> I'll cut an -rc3 with a fixed `configure` script today. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> - Ben >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> ghc-devs mailing list >>>>> ghc-devs at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>>> >>>>> >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicola.gigante at gmail.com Mon Nov 9 14:02:49 2015 From: nicola.gigante at gmail.com (Nicola Gigante) Date: Mon, 9 Nov 2015 15:02:49 +0100 Subject: Questions on the RTS C API regarding threads and tasks In-Reply-To: <1447024045-sup-6907@sabre> References: <5701AB9A-E4F1-4885-AD28-DE6F5480EAD9@gmail.com> <1447024045-sup-6907@sabre> Message-ID: <381528B2-12FE-48B8-8825-EC84A5EF1D34@gmail.com> > Il giorno 09 nov 2015, alle ore 00:17, Edward Z. Yang ha scritto: > > Excerpts from Nicola Gigante's message of 2015-11-04 23:13:51 -0800: >> We don't have measurements, but we ruled out this possibility for >> performance reasons. Our idea is to make a thin Haskell wrapper >> around a tiny bit of highly optimized C code. What's the performance >> of locking on MVars? > > I still don't know what it is you're trying to do. If you have a tiny > bit of optimized C code that runs quickly, then you should just make > an unsafe FFI call to it (as for as Haskell's runtime is concerned, > it's just a "fat instruction?). > I?m sorry, I know my description was too vague. The reason is that we have a blind review pending on a paper and I had instructions of not to talk about what we are doing. Anyway, your reply is nevertheless very clear. >> While we are at it: are primops callable directly from C? I suppose >> calling conventions are different. > > Anything is "callable" from C, but yes, you have to do the right > calling convention. Primops are not easily callable from C. > Ok, that?s what I meant. >> A question comes to mind: you mentioned "safe" calls. >> Are unsafe calls different regarding the detaching of the capability? > > An unsafe call does not detach the capability. > Ok, thanks for the confirmation of this fact. >> Also: would a patch to make this possible be accepted? >> In particular: >> - add a way to make a "ultraunsafe" foreign call that do not loose the >> ownership of the calling thread. > > I don't see what the difference between this and an unsafe foreign call > is. > Nothing actually, I was confused about what ?unsafe? call means. >> - add a BlockedOnExplicitSleep flag for tso->why_blocked >> (And in turn this means managing a different blocking queue, right?) >> - export something to reliably put in sleep and resume threads >> in this way. >> >> Is this feasible? Would it be a good idea? > > I still don't see why you can't just block the thread on an MVar > (removing it from the main run queues), and then when you want to > resume it write to the MVar. It'll have an added bonus that you'll > automatically handle masking/async exceptions correctly. > > If you find the MVar implementation is too slow, then maybe you > can think about making an optimized implementation which doesn't > use any synchronization / is inline in the TSO so no allocation > is necessary. But in my opinion this is putting the cart before > the horse. > Yes, that seems simple and fast enough. You?re right that we should measure before making assumptions about hypothetical poor performance. Thank you for your help > Edward Greetings, Nicola From george.colpitts at gmail.com Mon Nov 9 14:03:47 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Mon, 9 Nov 2015 10:03:47 -0400 Subject: [ANNOUNCE] 7.10.3 release candidate 2 In-Reply-To: References: <87pozltpfv.fsf@smart-cactus.org> <87twoxgx0x.fsf@smart-cactus.org> <87mvuohll0.fsf@smart-cactus.org> Message-ID: I understand this isn't a Haskell Platform thing. I just uninstalled the Haskell Platform before installing the binary as I wanted to make sure I didn't have a mixture of both on my machine Before doing the last make install I had done: ./configure --prefix=/usr/local On Mon, Nov 9, 2015 at 9:51 AM, Carter Schonwald wrote: > Why were you trying to do Haskell platform things ? > This isn't a Haskell platform build. Just configure --prefix=blsh and > then make install > > > On Monday, November 9, 2015, George Colpitts > wrote: > >> install into /opt works fine >> However the INSTALL file says >> >> `make show-install-setup' prints the details of where the different >> pieces of the bundle are heading when -- possibly helpful >> >> but this doesn't work: >> >> make show-install-setup >> make: *** No rule to make target `show-install-setup'. Stop. >> >> I installed in /opt as I didn't want to overwrite my current ghc. It >> would be nice if there was an uninstall target for make. >> >> I removed /opt/bin/* and /opt/lib/* as there were only ghc files there. >> Then I did an uninstall-hs (uninstall of Haskell Platform) >> Then install into the default (/usr/local) I get: >> >> /usr/bin/install -c -m 644 docs/man/ghc.1 "/usr/local/share/man/man1" >> install: /usr/local/share/man/man1/ghc.1: No such file or directory >> make[1]: *** [install_man] Error 71 >> make: *** [install] Error 2 >> >> I then did >> >> ls -l /usr/local/share/man/man1/ghc.1 >> lrwxr-xr-x 1 gcolpitts admin 81 Oct 11 17:35 >> /usr/local/share/man/man1/ghc.1 -> >> /Library/Frameworks/GHC.framework/Versions/7.10.2-x86_64/usr/share/man/man1/ghc.1 >> >> then >> >> rm /usr/local/share/man/man1/ghc.1 >> >> and then "make install" worked >> >> However cabal install hlint didn't work because it couldn't install >> text-1.2.1.3: >> >> cabal install text >> ... >> >> Data/Text.hs:203:8: >> Could not find module ?Control.DeepSeq? >> Perhaps you haven't installed the profiling libraries for package >> ?deepseq-1.4.1.1 at deeps_6vMKxt5sPFR0XsbRWvvq59?? >> Use -v to see a list of the files searched for. >> >> Data/Text.hs:208:8: >> Could not find module ?Data.Char? >> Perhaps you haven't installed the profiling libraries for package >> ?base-4.8.2.0?? >> Use -v to see a list of the files searched for. >> >> Data/Text.hs:209:8: >> Could not find module ?Data.Data? >> Perhaps you haven't installed the profiling libraries for package >> ?base-4.8.2.0?? >> Use -v to see a list of the files searched for. >> >> Data/Text.hs:211:8: >> Could not find module ?Control.Monad? >> Perhaps you haven't installed the profiling libraries for package >> ?base-4.8.2.0?? >> Use -v to see a list of the files searched for. >> >> Data/Text.hs:212:8: >> Could not find module ?Control.Monad.ST? >> Perhaps you haven't installed the profiling libraries for package >> ?base-4.8.2.0?? >> ... >> >> >> ghc-pkg list >> /usr/local/lib/ghc-7.10.2.20151105/package.conf.d: >> Cabal-1.22.4.0 >> array-0.5.1.0 >> base-4.8.2.0 >> bin-package-db-0.0.0.0 >> binary-0.7.5.0 >> rts-1.0 >> bytestring-0.10.6.0 >> containers-0.5.6.2 >> deepseq-1.4.1.1 >> directory-1.2.2.0 >> filepath-1.4.0.0 >> (ghc-7.10.2.20151105) >> ghc-prim-0.4.0.0 >> haskeline-0.7.2.1 >> hoopl-3.10.0.2 >> hpc-0.6.0.2 >> integer-gmp-1.0.0.0 >> pretty-1.1.2.0 >> process-1.2.3.0 >> template-haskell-2.10.0.0 >> terminfo-0.4.0.1 >> time-1.5.0.1 >> transformers-0.4.2.0 >> unix-2.7.1.0 >> xhtml-3000.2.1 >> >> ghc-pkg check >> >> Similar problems with cabal install vector >> >> >> >> On Mon, Nov 9, 2015 at 12:07 AM, Carter Schonwald < >> carter.schonwald at gmail.com> wrote: >> >>> nope, my error was a bad copy and paste :) >>> >>> heres a link to my build (uses the GCC style rts build, which should be >>> more performant than the default clang one last i checked, also has html >>> docs and should work OS X >= 10.7) >>> >>> >>> https://www.wellposed.com.s3.amazonaws.com/opensource/ghc/releasebuild-unofficial/ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2 >>> >>> (http:// also works) >>> >>> >>> shasum -a512 ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2 >>> 003a23929a17e9d01f52ef0a9388b6af51d409eda12627b20500c820f44da1e21976a46da7a50d040072cf5243a05d8f6a4344899fe3c2d8fb3f4f101ef29dce >>> >>> >>> for those who want to check the check the sha sum >>> >>> >>> >>> On Sun, Nov 8, 2015 at 9:36 PM, George Colpitts < >>> george.colpitts at gmail.com> wrote: >>> >>>> I get >>>> >>>> make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1 >>>> make[1]: *** Waiting for unfinished jobs.... >>>> checking whether byte ordering is bigendian... no >>>> checking assembler .cfi pseudo-op support... yes >>>> checking for _ prefix in compiled symbols... yes >>>> checking whether .eh_frame section should be read-only... expr: syntax >>>> error >>>> no >>>> checking for __attribute__((visibility("hidden")))... no >>>> checking that generated files are newer than configure... done >>>> configure: creating ./config.status >>>> config.status: creating include/Makefile >>>> config.status: creating include/ffi.h >>>> config.status: creating Makefile >>>> config.status: creating testsuite/Makefile >>>> config.status: creating man/Makefile >>>> config.status: creating libffi.pc >>>> config.status: creating fficonfig.h >>>> config.status: linking ../src/x86/ffitarget.h to include/ffitarget.h >>>> config.status: executing buildir commands >>>> config.status: create top_srcdir/Makefile guessed from local Makefile >>>> config.status: build in x86_64-apple-darwin (HOST=) >>>> config.status: executing depfiles commands >>>> config.status: executing libtool commands >>>> config.status: executing include commands >>>> config.status: executing src commands >>>> # wc on OS X has spaces in its output, which libffi's Makefile >>>> # doesn't expect, so we tweak it to sed them out >>>> mv libffi/build/Makefile libffi/build/Makefile.orig >>>> sed "s#wc -w#wc -w | sed 's/ //g'#" < libffi/build/Makefile.orig > >>>> libffi/build/Makefile >>>> "touch" libffi/stamp.ffi.static-shared.configure >>>> make: *** [all] Error 2 >>>> >>>> Is that the same error you are getting? >>>> >>>> >>>> On Sun, Nov 8, 2015 at 9:34 PM, Carter Schonwald < >>>> carter.schonwald at gmail.com> wrote: >>>> >>>>> I'm having trouble setting the make file flags to make the Mac build >>>>> use the intree gmp. I'm going to dig into this a bit more this evening. >>>>> >>>>> >>>>> On Sunday, November 8, 2015, Ben Gamari wrote: >>>>> >>>>>> Ben Gamari writes: >>>>>> >>>>>> > Ben Gamari writes: >>>>>> > >>>>>> >> Hello everyone, >>>>>> >> >>>>>> >> We are pleased to announce the second release candidate for GHC >>>>>> 7.10.3: >>>>>> >> >>>>>> >> https://downloads.haskell.org/~ghc/7.10.3-rc2/ >>>>>> >> >>>>>> > It has been brought to my attention that the configure script in >>>>>> this >>>>>> > source tarballs is out of date. Because of this `configure` will >>>>>> > still fail on OS X. Reports suggest that there may be other issues >>>>>> > unrelated to the configure issue on OS X as well. >>>>>> > >>>>>> Further testing suggests that perhaps the only issue is the >>>>>> out-of-date >>>>>> `configure` script. Mac OS X users with `autotools` installed should >>>>>> be >>>>>> able to run `./boot` in the source tree to bring `configure` >>>>>> up-to-date, >>>>>> at which point this release candidate should be buildable. >>>>>> >>>>>> I'll cut an -rc3 with a fixed `configure` script today. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> - Ben >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> ghc-devs mailing list >>>>> ghc-devs at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>>> >>>>> >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Mon Nov 9 14:49:58 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Mon, 9 Nov 2015 10:49:58 -0400 Subject: [ANNOUNCE] 7.10.3 release candidate 2 - problems compiling source on Mac OS with clang Message-ID: redid with just make rather than make -j5. I get ... chmod +x libraries/integer-gmp2/gmp/ln # Their cmd invocation only works on msys. On cygwin it starts # a cmd interactive shell. The replacement works in both environments. mv libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh.orig sed 's#cmd //c echo "\$1"#cmd /c "echo $1"#' < libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh.orig > libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh cd libraries/integer-gmp2/gmp; (set -o igncr 2>/dev/null) && set -o igncr; export SHELLOPTS; \ PATH=`pwd`:$PATH; \ export PATH; \ cd gmpbuild && \ CC=clang NM=/usr/bin/nm AR=/usr/bin/ar ./configure \ --enable-shared=no \ --host=x86_64-apple-darwin --build=x86_64-apple-darwin /bin/sh: SHELLOPTS: readonly variable checking build system type... /bin/sh: SHELLOPTS: readonly variable /bin/sh: SHELLOPTS: readonly variable x86_64-apple-darwin checking host system type... /bin/sh: SHELLOPTS: readonly variable /bin/sh: SHELLOPTS: readonly variable x86_64-apple-darwin checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes /bin/sh: SHELLOPTS: readonly variable checking for a thread-safe mkdir -p... ./install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking ABI=64 checking whether clang is gcc... yes checking compiler clang -O2 -pedantic -fPIC -m64 ... no, gnupro alpha ev6 char spilling checking ABI=32 checking whether clang is gcc... yes *checking compiler clang -m32 -O2 -pedantic -fPIC -fomit-frame-pointer ... no, gnupro alpha ev6 char spilling* *checking compiler clang -O2 -pedantic -fPIC -fomit-frame-pointer ... no, gnupro alpha ev6 char spilling* *configure: error: could not find a working compiler, see config.log for details* *make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1* *make: *** [all] Error 2* On Mon, Nov 9, 2015 at 9:32 AM, Ben Gamari wrote: > George Colpitts writes: > > > I get > > > > make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1 > > make[1]: *** Waiting for unfinished jobs.... > > It looks like the build failed somewhere before this point. Could you > provide a more complete log? > > Cheers, > > - Ben > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at gregorycollins.net Mon Nov 9 20:33:25 2015 From: greg at gregorycollins.net (Gregory Collins) Date: Mon, 9 Nov 2015 12:33:25 -0800 Subject: Questions on the RTS C API regarding threads and tasks In-Reply-To: <381528B2-12FE-48B8-8825-EC84A5EF1D34@gmail.com> References: <5701AB9A-E4F1-4885-AD28-DE6F5480EAD9@gmail.com> <1447024045-sup-6907@sabre> <381528B2-12FE-48B8-8825-EC84A5EF1D34@gmail.com> Message-ID: On Mon, Nov 9, 2015 at 6:02 AM, Nicola Gigante wrote: > Nothing actually, I was confused about what ?unsafe? call means. In fact, as you've probably realized, the reason these calls are labeled unsafe is precisely because they don't yield the capability. An unsafe FFI call that blocks will block the Haskell capability -- this not only starves that CPU for actual work, it will eventually block the whole program once the RTS tries to do a round of stop-the-world GC. As Edward pointed out, you're better off just relying on the concurrency primitives Haskell already gives you unless you find they're too slow. Another thing you can try is the unagi-chan library on Hackage ( https://hackage.haskell.org/package/unagi-chan), which offers versions of blocking and non-blocking producer-consumer queues that claim to be much faster than the ones that come with the standard library. Greg -- Gregory Collins -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Mon Nov 9 21:02:48 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 9 Nov 2015 16:02:48 -0500 Subject: too many lines too long Message-ID: <966B4013-23C0-45EA-975A-6506707A555E@cis.upenn.edu> Hi devs, We seem to be uncommitted to the ideal of 80-character lines. Almost every patch on Phab I look through has a bunch of "line too long" lint errors. No one seems to do much about these. And Phab's very very loud indication of a lint error makes reviewing the code harder. I like the ideal of 80-character lines. I aim for this ideal in my patches, falling short sometimes, of course. But I think the current setting of requiring everyone to "explain" away their overlong lines during `arc diff` and then trying hard to ignore the lint errors during code review is wrong. And it makes us all inured to more serious lint errors. How about this: after `arc diff` is run, it will count the number of overlong lines before and after the patch. If there are more after, have the last thing `arc diff` outputs be a stern telling-off of the dev, along the lines of > Before your patch, 15 of the edited lines were over 80 characters. > Now, a whopping 28 of them are. Can't you do better? Please? Would this be ignored more or followed more? Who knows. But it would sure be less annoying. :) What do others think? Thanks, Richard From ezyang at mit.edu Mon Nov 9 21:10:33 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Mon, 09 Nov 2015 13:10:33 -0800 Subject: too many lines too long In-Reply-To: <966B4013-23C0-45EA-975A-6506707A555E@cis.upenn.edu> References: <966B4013-23C0-45EA-975A-6506707A555E@cis.upenn.edu> Message-ID: <1447103251-sup-9965@sabre> For me, a huge reason why the line length errors are annoying is because there will often be some existing line which is 80+, and I just need to change one word in it. Well, now that's a line length error. Now, I *could* refactor the line so that it's less than 80. But this (1) fluffs up the diffs with non-semantic noise, and (2) makes merge conflicts a lot more likely. I think the counts thing could help for this case. But now suppose there's an existing line which is just barely under 80, and you need to do a mechanical substitution which pushes it over. Yes, I /could/ reindent it, but it's a huge timesink for no very good reason. Usually the best way to eliminate a long line is to refactor the entire region of code, e.g. splitting out helper functions or whatnot. Edward Excerpts from Richard Eisenberg's message of 2015-11-09 13:02:48 -0800: > Hi devs, > > We seem to be uncommitted to the ideal of 80-character lines. Almost every patch on Phab I look through has a bunch of "line too long" lint errors. No one seems to do much about these. And Phab's very very loud indication of a lint error makes reviewing the code harder. > > I like the ideal of 80-character lines. I aim for this ideal in my patches, falling short sometimes, of course. But I think the current setting of requiring everyone to "explain" away their overlong lines during `arc diff` and then trying hard to ignore the lint errors during code review is wrong. And it makes us all inured to more serious lint errors. > > How about this: after `arc diff` is run, it will count the number of overlong lines before and after the patch. If there are more after, have the last thing `arc diff` outputs be a stern telling-off of the dev, along the lines of > > > Before your patch, 15 of the edited lines were over 80 characters. > > Now, a whopping 28 of them are. Can't you do better? Please? > > Would this be ignored more or followed more? Who knows. But it would sure be less annoying. :) > > What do others think? > > Thanks, > Richard From austin at well-typed.com Mon Nov 9 21:15:26 2015 From: austin at well-typed.com (Austin Seipp) Date: Mon, 9 Nov 2015 15:15:26 -0600 Subject: too many lines too long In-Reply-To: <966B4013-23C0-45EA-975A-6506707A555E@cis.upenn.edu> References: <966B4013-23C0-45EA-975A-6506707A555E@cis.upenn.edu> Message-ID: Something like this might be possible. It'd just require implementing a new arcanist linter, I think, and enabling it in .arclint In general I really sympathize with this. The problem 90% of people hit is that they touch a line that was *already* over 80 columns, so 'arc lint' warns them and gets annoyed, but they don't want to fix or split up a bunch of stuff to avoid it. It's an issue of having to do 'boring work' which nobody likes, and seems very tedious, regardless of the mechanism of how they do the change. Really, I'm more inclined to begin a policy of rejecting reviews that do not pass the linter. Exceptions can be made, but in general we need to start *enforcing it* with the red button I think. And it would require us to be more diligent about merging patches quickly to reduce the scope of merge conflicts (because fixing an 80col violation normally, almost always, adds more LOC). However, there are people who in general think the contribution barrier is already too high, and I fear that enforcing this with a hard rule may make people 'give up' because it seems like a pointless thing to mandate to block their changes. I'm not sure how people feel about that, but it is worth keeping in mind the developer economics. I hope suggesting the possibility of being more forceful against 80col violations doesn't derail this too much. :) On Mon, Nov 9, 2015 at 3:02 PM, Richard Eisenberg wrote: > Hi devs, > > We seem to be uncommitted to the ideal of 80-character lines. Almost every patch on Phab I look through has a bunch of "line too long" lint errors. No one seems to do much about these. And Phab's very very loud indication of a lint error makes reviewing the code harder. > > I like the ideal of 80-character lines. I aim for this ideal in my patches, falling short sometimes, of course. But I think the current setting of requiring everyone to "explain" away their overlong lines during `arc diff` and then trying hard to ignore the lint errors during code review is wrong. And it makes us all inured to more serious lint errors. > > How about this: after `arc diff` is run, it will count the number of overlong lines before and after the patch. If there are more after, have the last thing `arc diff` outputs be a stern telling-off of the dev, along the lines of > >> Before your patch, 15 of the edited lines were over 80 characters. >> Now, a whopping 28 of them are. Can't you do better? Please? > > Would this be ignored more or followed more? Who knows. But it would sure be less annoying. :) > > What do others think? > > Thanks, > Richard > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From eir at cis.upenn.edu Mon Nov 9 21:21:20 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 9 Nov 2015 16:21:20 -0500 Subject: too many lines too long In-Reply-To: References: <966B4013-23C0-45EA-975A-6506707A555E@cis.upenn.edu> Message-ID: I agree that being forceful about the 80-col limit would solve my problem. But I really dislike the idea. There will always be long-running patches. Volunteers can't be relied on to have time available to continue their work right away. And so I think this decision would increase barriers to contributing and increase merge conflicts for a cause that, frankly, isn't terribly important. (To repeat: I *do* want 80-col lines. I just want an amazing compiler more.) Richard On Nov 9, 2015, at 4:15 PM, Austin Seipp wrote: > Something like this might be possible. It'd just require implementing > a new arcanist linter, I think, and enabling it in .arclint > > In general I really sympathize with this. The problem 90% of people > hit is that they touch a line that was *already* over 80 columns, so > 'arc lint' warns them and gets annoyed, but they don't want to fix or > split up a bunch of stuff to avoid it. It's an issue of having to do > 'boring work' which nobody likes, and seems very tedious, regardless > of the mechanism of how they do the change. > > Really, I'm more inclined to begin a policy of rejecting reviews that > do not pass the linter. Exceptions can be made, but in general we need > to start *enforcing it* with the red button I think. And it would > require us to be more diligent about merging patches quickly to reduce > the scope of merge conflicts (because fixing an 80col violation > normally, almost always, adds more LOC). > > However, there are people who in general think the contribution > barrier is already too high, and I fear that enforcing this with a > hard rule may make people 'give up' because it seems like a pointless > thing to mandate to block their changes. I'm not sure how people feel > about that, but it is worth keeping in mind the developer economics. > > I hope suggesting the possibility of being more forceful against 80col > violations doesn't derail this too much. :) > > On Mon, Nov 9, 2015 at 3:02 PM, Richard Eisenberg wrote: >> Hi devs, >> >> We seem to be uncommitted to the ideal of 80-character lines. Almost every patch on Phab I look through has a bunch of "line too long" lint errors. No one seems to do much about these. And Phab's very very loud indication of a lint error makes reviewing the code harder. >> >> I like the ideal of 80-character lines. I aim for this ideal in my patches, falling short sometimes, of course. But I think the current setting of requiring everyone to "explain" away their overlong lines during `arc diff` and then trying hard to ignore the lint errors during code review is wrong. And it makes us all inured to more serious lint errors. >> >> How about this: after `arc diff` is run, it will count the number of overlong lines before and after the patch. If there are more after, have the last thing `arc diff` outputs be a stern telling-off of the dev, along the lines of >> >>> Before your patch, 15 of the edited lines were over 80 characters. >>> Now, a whopping 28 of them are. Can't you do better? Please? >> >> Would this be ignored more or followed more? Who knows. But it would sure be less annoying. :) >> >> What do others think? >> >> Thanks, >> Richard >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > From omeragacan at gmail.com Mon Nov 9 22:17:22 2015 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Mon, 9 Nov 2015 17:17:22 -0500 Subject: too many lines too long In-Reply-To: References: <966B4013-23C0-45EA-975A-6506707A555E@cis.upenn.edu> Message-ID: I also dislike the idea of automatically rejecting such code. I agree with Austin's argument that the contribution barrier is already too high and Richard's arguments, but in addition to those, I think it wouldn't be fair because some patches of people with push access won't be subject to the automatic lint checks. 100-col lines will make it to the code base even if only by mistake. It'll be annoying to new contributors and won't solve the problem. Personally I'm trying to be very careful, and in my patches I usually do a lint pass at the end to fix all long lines. But I'm OK if some patches with 100-col lines occasionally make it to the master. 2015-11-09 16:21 GMT-05:00 Richard Eisenberg : > I agree that being forceful about the 80-col limit would solve my problem. > > But I really dislike the idea. There will always be long-running patches. Volunteers can't be relied on to have time available to continue their work right away. And so I think this decision would increase barriers to contributing and increase merge conflicts for a cause that, frankly, isn't terribly important. (To repeat: I *do* want 80-col lines. I just want an amazing compiler more.) > > Richard > > On Nov 9, 2015, at 4:15 PM, Austin Seipp wrote: > >> Something like this might be possible. It'd just require implementing >> a new arcanist linter, I think, and enabling it in .arclint >> >> In general I really sympathize with this. The problem 90% of people >> hit is that they touch a line that was *already* over 80 columns, so >> 'arc lint' warns them and gets annoyed, but they don't want to fix or >> split up a bunch of stuff to avoid it. It's an issue of having to do >> 'boring work' which nobody likes, and seems very tedious, regardless >> of the mechanism of how they do the change. >> >> Really, I'm more inclined to begin a policy of rejecting reviews that >> do not pass the linter. Exceptions can be made, but in general we need >> to start *enforcing it* with the red button I think. And it would >> require us to be more diligent about merging patches quickly to reduce >> the scope of merge conflicts (because fixing an 80col violation >> normally, almost always, adds more LOC). >> >> However, there are people who in general think the contribution >> barrier is already too high, and I fear that enforcing this with a >> hard rule may make people 'give up' because it seems like a pointless >> thing to mandate to block their changes. I'm not sure how people feel >> about that, but it is worth keeping in mind the developer economics. >> >> I hope suggesting the possibility of being more forceful against 80col >> violations doesn't derail this too much. :) >> >> On Mon, Nov 9, 2015 at 3:02 PM, Richard Eisenberg wrote: >>> Hi devs, >>> >>> We seem to be uncommitted to the ideal of 80-character lines. Almost every patch on Phab I look through has a bunch of "line too long" lint errors. No one seems to do much about these. And Phab's very very loud indication of a lint error makes reviewing the code harder. >>> >>> I like the ideal of 80-character lines. I aim for this ideal in my patches, falling short sometimes, of course. But I think the current setting of requiring everyone to "explain" away their overlong lines during `arc diff` and then trying hard to ignore the lint errors during code review is wrong. And it makes us all inured to more serious lint errors. >>> >>> How about this: after `arc diff` is run, it will count the number of overlong lines before and after the patch. If there are more after, have the last thing `arc diff` outputs be a stern telling-off of the dev, along the lines of >>> >>>> Before your patch, 15 of the edited lines were over 80 characters. >>>> Now, a whopping 28 of them are. Can't you do better? Please? >>> >>> Would this be ignored more or followed more? Who knows. But it would sure be less annoying. :) >>> >>> What do others think? >>> >>> Thanks, >>> Richard >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >> >> >> >> -- >> Regards, >> >> Austin Seipp, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simonpj at microsoft.com Mon Nov 9 22:45:15 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 9 Nov 2015 22:45:15 +0000 Subject: too many lines too long In-Reply-To: <966B4013-23C0-45EA-975A-6506707A555E@cis.upenn.edu> References: <966B4013-23C0-45EA-975A-6506707A555E@cis.upenn.edu> Message-ID: <4662eae97b8e431eade708afc6906616@DB4PR30MB030.064d.mgd.msft.net> In my view 80 chars is too short. It was justified in the days of 80-column CRTs, but that just isn't a restriction any more. I routinely edit in a much wider window. Clearly there's a judgement call here. But I'd prefer 120 cols say. Simon -----Original Message----- From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Richard Eisenberg Sent: 09 November 2015 21:03 To: ghc-devs Devs Subject: too many lines too long Hi devs, We seem to be uncommitted to the ideal of 80-character lines. Almost every patch on Phab I look through has a bunch of "line too long" lint errors. No one seems to do much about these. And Phab's very very loud indication of a lint error makes reviewing the code harder. I like the ideal of 80-character lines. I aim for this ideal in my patches, falling short sometimes, of course. But I think the current setting of requiring everyone to "explain" away their overlong lines during `arc diff` and then trying hard to ignore the lint errors during code review is wrong. And it makes us all inured to more serious lint errors. How about this: after `arc diff` is run, it will count the number of overlong lines before and after the patch. If there are more after, have the last thing `arc diff` outputs be a stern telling-off of the dev, along the lines of > Before your patch, 15 of the edited lines were over 80 characters. > Now, a whopping 28 of them are. Can't you do better? Please? Would this be ignored more or followed more? Who knows. But it would sure be less annoying. :) What do others think? Thanks, Richard _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cebcdeaa0675a490898dc08d2e94927cc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6IXQEBFIJnDRWCSKmNxdVsWQm2bqPVPn133kblshukU%3d From mail at joachim-breitner.de Mon Nov 9 22:47:12 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 09 Nov 2015 23:47:12 +0100 Subject: too many lines too long In-Reply-To: <966B4013-23C0-45EA-975A-6506707A555E@cis.upenn.edu> References: <966B4013-23C0-45EA-975A-6506707A555E@cis.upenn.edu> Message-ID: <1447109232.24679.15.camel@joachim-breitner.de> Hi, I?d like to state a differing opinion: I don?t think highly of such a hard rule. A line should have the length that is most natural to it. Patches should be easy to review. Developers time is spent better than re-shuffling code to be short and still nicely formatted and aligned. I might be in the minority here, and of course I?ll be adhering to any hard requirements agreed on by broad consensus, but note that the support for an 80-line regime is not unanimous. Oh, and obviously dropping this requirement would also solve Richard?s problems with the linter :-) Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From eir at cis.upenn.edu Mon Nov 9 22:51:28 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 9 Nov 2015 17:51:28 -0500 Subject: too many lines too long In-Reply-To: <4662eae97b8e431eade708afc6906616@DB4PR30MB030.064d.mgd.msft.net> References: <966B4013-23C0-45EA-975A-6506707A555E@cis.upenn.edu> <4662eae97b8e431eade708afc6906616@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <7A8FD49D-825F-48B6-BFD0-D019825109C9@cis.upenn.edu> At both school and at home I can fit 3 80-character buffers side by side, at a comfortable font size. Going up (even to 85 cols) would mean losing a buffer. (Or straining my eyes.) Of course I can deal with wrapped lines. But I still vote for 80 characters as a target, while allowing people wiggle room to miss this target. The number 80 is with us for historical reasons, but I know I'm not the only one who still routinely uses 80-column buffers. Richard On Nov 9, 2015, at 5:45 PM, Simon Peyton Jones wrote: > In my view 80 chars is too short. It was justified in the days of 80-column CRTs, but that just isn't a restriction any more. I routinely edit in a much wider window. > > Clearly there's a judgement call here. But I'd prefer 120 cols say. > > Simon > > -----Original Message----- > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Richard Eisenberg > Sent: 09 November 2015 21:03 > To: ghc-devs Devs > Subject: too many lines too long > > Hi devs, > > We seem to be uncommitted to the ideal of 80-character lines. Almost every patch on Phab I look through has a bunch of "line too long" lint errors. No one seems to do much about these. And Phab's very very loud indication of a lint error makes reviewing the code harder. > > I like the ideal of 80-character lines. I aim for this ideal in my patches, falling short sometimes, of course. But I think the current setting of requiring everyone to "explain" away their overlong lines during `arc diff` and then trying hard to ignore the lint errors during code review is wrong. And it makes us all inured to more serious lint errors. > > How about this: after `arc diff` is run, it will count the number of overlong lines before and after the patch. If there are more after, have the last thing `arc diff` outputs be a stern telling-off of the dev, along the lines of > >> Before your patch, 15 of the edited lines were over 80 characters. >> Now, a whopping 28 of them are. Can't you do better? Please? > > Would this be ignored more or followed more? Who knows. But it would sure be less annoying. :) > > What do others think? > > Thanks, > Richard > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cebcdeaa0675a490898dc08d2e94927cc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6IXQEBFIJnDRWCSKmNxdVsWQm2bqPVPn133kblshukU%3d > From nikita at karetnikov.org Mon Nov 9 22:59:29 2015 From: nikita at karetnikov.org (Nikita Karetnikov) Date: Tue, 10 Nov 2015 01:59:29 +0300 Subject: too many lines too long In-Reply-To: <7A8FD49D-825F-48B6-BFD0-D019825109C9@cis.upenn.edu> (Richard Eisenberg's message of "Mon, 9 Nov 2015 17:51:28 -0500") References: <966B4013-23C0-45EA-975A-6506707A555E@cis.upenn.edu> <4662eae97b8e431eade708afc6906616@DB4PR30MB030.064d.mgd.msft.net> <7A8FD49D-825F-48B6-BFD0-D019825109C9@cis.upenn.edu> Message-ID: <87bnb2ye26.fsf@karetnikov.org> > At both school and at home I can fit 3 80-character buffers side by > side, at a comfortable font size. Going up (even to 85 cols) would > mean losing a buffer. (Or straining my eyes.) Of course I can deal > with wrapped lines. But I still vote for 80 characters as a target, > while allowing people wiggle room to miss this target. > The number 80 is with us for historical reasons, but I know I'm not the only one who still routinely uses 80-column buffers. +1 From edzhavoronkov at gmail.com Tue Nov 10 10:16:58 2015 From: edzhavoronkov at gmail.com (=?UTF-8?B?0K3QtNCz0LDRgCDQltCw0LLQvtGA0L7QvdC60L7Qsg==?=) Date: Tue, 10 Nov 2015 13:16:58 +0300 Subject: How inline pragma works Message-ID: Hello everyone! Where can i read about how does INLINE pragma in compiler works? --- ? ?????????, ?????????? ????? Best regards, Edgar A. Zhavoronkov -------------- next part -------------- An HTML attachment was scrubbed... URL: From edzhavoronkov at gmail.com Tue Nov 10 10:44:16 2015 From: edzhavoronkov at gmail.com (=?UTF-8?B?0K3QtNCz0LDRgCDQltCw0LLQvtGA0L7QvdC60L7Qsg==?=) Date: Tue, 10 Nov 2015 13:44:16 +0300 Subject: Problems with cabal Message-ID: Hi, everyone! I have a strange problems with building GHC from sources. I cloned git repo as said in newcomers' page, but i have that kind of error: Cloning into 'libraries/Cabal'... fatal: repository 'https://github.com/ghc/packages/Cabal.git/' not found Clone of 'http://github.com/ghc/packages/Cabal.git' into submodule path 'libraries/Cabal' failed What am i doing wrong? --- ? ?????????, ?????????? ????? Best regards, Edgar A. Zhavoronkov -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at sandbergericsson.se Tue Nov 10 10:47:49 2015 From: adam at sandbergericsson.se (Adam Sandberg Eriksson) Date: Tue, 10 Nov 2015 11:47:49 +0100 Subject: Problems with cabal In-Reply-To: References: Message-ID: <1447152469.709585.434813297.03236AA8@webmail.messagingengine.com> It seems you missed this part on the newcomers page[1]: git config --global url."git://github.com/ghc/packages-".insteadOf git://github.com/ghc/packages/ Adam Sandberg Eriksson [1]https://ghc.haskell.org/trac/ghc/wiki/Newcomers On Tue, 10 Nov 2015, at 11:44 AM, ????? ?????????? wrote: > Hi, everyone! > > I have a strange problems with building GHC from sources. I cloned git > repo as said in newcomers' page, but i have that kind of error: > > Cloning into 'libraries/Cabal'... fatal: repository ' > https://github.com/ghc/packages/Cabal.git/' not found Clone of ' > http://github.com/ghc/packages/Cabal.git' into submodule path > 'libraries/Cabal' failed > > What am i doing wrong? > --- > ? ?????????, ?????????? ????? > > Best regards, Edgar A. Zhavoronkov > _________________________________________________ > ghc-devs mailing list ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Tue Nov 10 11:30:58 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 10 Nov 2015 12:30:58 +0100 Subject: too many lines too long In-Reply-To: <4662eae97b8e431eade708afc6906616@DB4PR30MB030.064d.mgd.msft.net> References: <966B4013-23C0-45EA-975A-6506707A555E@cis.upenn.edu> <4662eae97b8e431eade708afc6906616@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <877flqgkgd.fsf@smart-cactus.org> Simon Peyton Jones writes: > In my view 80 chars is too short. It was justified in the days of > 80-column CRTs, but that just isn't a restriction any more. I > routinely edit in a much wider window. > As far as a hard length limit is concerned I am with Simon here. 80 characters is quite short and some of the more "tabular" source files of GHC would be on the whole less readable if such a limit were strictly enforced. On the other hand, I agree that in many cases 80-characters is quite a convenient length; having several buffers side-by-side can make reading much easier. Many of the files with long-lines could and should be fixed. However, I am not convinced that this is true for *all* source files and in my opinion a bit of discretion doesn't hurt. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From tuncer.ayaz at gmail.com Tue Nov 10 11:31:46 2015 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Tue, 10 Nov 2015 12:31:46 +0100 Subject: too many lines too long In-Reply-To: <7A8FD49D-825F-48B6-BFD0-D019825109C9@cis.upenn.edu> References: <966B4013-23C0-45EA-975A-6506707A555E@cis.upenn.edu> <4662eae97b8e431eade708afc6906616@DB4PR30MB030.064d.mgd.msft.net> <7A8FD49D-825F-48B6-BFD0-D019825109C9@cis.upenn.edu> Message-ID: On Mon, Nov 9, 2015 at 11:51 PM, Richard Eisenberg wrote: > At both school and at home I can fit 3 80-character buffers side by > side, at a comfortable font size. Going up (even to 85 cols) would > mean losing a buffer. (Or straining my eyes.) Of course I can deal > with wrapped lines. But I still vote for 80 characters as a target, > while allowing people wiggle room to miss this target. > > The number 80 is with us for historical reasons, but I know I'm not > the only one who still routinely uses 80-column buffers. It's not just for historical reasons, it's one of those things that turned out to be a reasonable convention: Regardless of the width of windows, it's easier to read limited-width columns. I may be part of a sub-group, but just like a newspaper, I find it easier to "eye-scroll" up and down than left and right. This is the major reason why limiting column width still makes sense. Unless, of course, it's just a few lines, or things that cannot be limited due to technical reasons. I don't know if 120 is too wide, but 100 might be okay. Also, changing the length while touching a line is the most natural way to do it, as white-space reformatting patches, unless done once-only-for-everything-and-never-again, will be noise and make things like git-bisect harder to use. A width limit also is a nice way to alarm you if you start nesting too much :). From alan.zimm at gmail.com Tue Nov 10 11:33:10 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Tue, 10 Nov 2015 13:33:10 +0200 Subject: too many lines too long In-Reply-To: References: <966B4013-23C0-45EA-975A-6506707A555E@cis.upenn.edu> <4662eae97b8e431eade708afc6906616@DB4PR30MB030.064d.mgd.msft.net> <7A8FD49D-825F-48B6-BFD0-D019825109C9@cis.upenn.edu> Message-ID: 80 cols does work well with the side by side diff in Phabricator. Alan On Tue, Nov 10, 2015 at 1:31 PM, Tuncer Ayaz wrote: > On Mon, Nov 9, 2015 at 11:51 PM, Richard Eisenberg > wrote: > > At both school and at home I can fit 3 80-character buffers side by > > side, at a comfortable font size. Going up (even to 85 cols) would > > mean losing a buffer. (Or straining my eyes.) Of course I can deal > > with wrapped lines. But I still vote for 80 characters as a target, > > while allowing people wiggle room to miss this target. > > > > The number 80 is with us for historical reasons, but I know I'm not > > the only one who still routinely uses 80-column buffers. > > It's not just for historical reasons, it's one of those things that > turned out to be a reasonable convention: > > Regardless of the width of windows, it's easier to read limited-width > columns. I may be part of a sub-group, but just like a newspaper, I > find it easier to "eye-scroll" up and down than left and right. This > is the major reason why limiting column width still makes sense. > Unless, of course, it's just a few lines, or things that cannot be > limited due to technical reasons. I don't know if 120 is too wide, but > 100 might be okay. > > Also, changing the length while touching a line is the most natural > way to do it, as white-space reformatting patches, unless done > once-only-for-everything-and-never-again, will be noise and make > things like git-bisect harder to use. > > A width limit also is a nice way to alarm you if you start nesting too > much :). > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From edzhavoronkov at gmail.com Tue Nov 10 11:34:45 2015 From: edzhavoronkov at gmail.com (=?UTF-8?B?0K3QtNCz0LDRgCDQltCw0LLQvtGA0L7QvdC60L7Qsg==?=) Date: Tue, 10 Nov 2015 14:34:45 +0300 Subject: Problems with cabal In-Reply-To: <1447152469.709585.434813297.03236AA8@webmail.messagingengine.com> References: <1447152469.709585.434813297.03236AA8@webmail.messagingengine.com> Message-ID: But i've already done that my .gitconfig section with urls looks like this: [url "http://github.com/ghc/packages-"] insteadOf = git://github.com/ghc/packages/ I am using http because of strange proxy settings in university's network --- ? ?????????, ?????????? ????? Best regards, Edgar A. Zhavoronkov 2015-11-10 13:47 GMT+03:00 Adam Sandberg Eriksson : > It seems you missed this part on the newcomers page[1]: > > git config --global url."git://github.com/ghc/packages-".insteadOf > git:// > github.com/ghc/packages/ > > Adam Sandberg Eriksson > > [1] https://ghc.haskell.org/trac/ghc/wiki/Newcomers > > > > On Tue, 10 Nov 2015, at 11:44 AM, ????? ?????????? wrote: > > Hi, everyone! > > I have a strange problems with building GHC from sources. I cloned git > repo as said in newcomers' page, but i have that kind of error: > > Cloning into 'libraries/Cabal'... > fatal: repository 'https://github.com/ghc/packages/Cabal.git/' not found > Clone of 'http://github.com/ghc/packages/Cabal.git' into submodule path > 'libraries/Cabal' failed > > What am i doing wrong? > --- > ? ?????????, > ?????????? ????? > > Best regards, > Edgar A. Zhavoronkov > *_______________________________________________* > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From edzhavoronkov at gmail.com Tue Nov 10 11:36:52 2015 From: edzhavoronkov at gmail.com (=?UTF-8?B?0K3QtNCz0LDRgCDQltCw0LLQvtGA0L7QvdC60L7Qsg==?=) Date: Tue, 10 Nov 2015 14:36:52 +0300 Subject: Problems with cabal In-Reply-To: References: <1447152469.709585.434813297.03236AA8@webmail.messagingengine.com> Message-ID: Ooops screwed up a bit. Forgot to do another git configs --- ? ?????????, ?????????? ????? Best regards, Edgar A. Zhavoronkov 2015-11-10 14:34 GMT+03:00 ????? ?????????? : > But i've already done that > > my .gitconfig section with urls looks like this: > [url "http://github.com/ghc/packages-"] > insteadOf = git://github.com/ghc/packages/ > > I am using http because of strange proxy settings in university's network > > --- > ? ?????????, > ?????????? ????? > > Best regards, > Edgar A. Zhavoronkov > > 2015-11-10 13:47 GMT+03:00 Adam Sandberg Eriksson < > adam at sandbergericsson.se>: > >> It seems you missed this part on the newcomers page[1]: >> >> git config --global url."git://github.com/ghc/packages-".insteadOf >> git:// >> github.com/ghc/packages/ >> >> Adam Sandberg Eriksson >> >> [1] https://ghc.haskell.org/trac/ghc/wiki/Newcomers >> >> >> >> On Tue, 10 Nov 2015, at 11:44 AM, ????? ?????????? wrote: >> >> Hi, everyone! >> >> I have a strange problems with building GHC from sources. I cloned git >> repo as said in newcomers' page, but i have that kind of error: >> >> Cloning into 'libraries/Cabal'... >> fatal: repository 'https://github.com/ghc/packages/Cabal.git/' not found >> Clone of 'http://github.com/ghc/packages/Cabal.git' into submodule path >> 'libraries/Cabal' failed >> >> What am i doing wrong? >> --- >> ? ?????????, >> ?????????? ????? >> >> Best regards, >> Edgar A. Zhavoronkov >> *_______________________________________________* >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsf at seereason.com Tue Nov 10 14:28:42 2015 From: dsf at seereason.com (David Fox) Date: Tue, 10 Nov 2015 06:28:42 -0800 Subject: too many lines too long In-Reply-To: <7A8FD49D-825F-48B6-BFD0-D019825109C9@cis.upenn.edu> References: <966B4013-23C0-45EA-975A-6506707A555E@cis.upenn.edu> <4662eae97b8e431eade708afc6906616@DB4PR30MB030.064d.mgd.msft.net> <7A8FD49D-825F-48B6-BFD0-D019825109C9@cis.upenn.edu> Message-ID: I am concerned that 80 character lines discourages the use of longerSymbolNamesLikeThis. Which I really like. On Mon, Nov 9, 2015 at 2:51 PM, Richard Eisenberg wrote: > At both school and at home I can fit 3 80-character buffers side by side, > at a comfortable font size. Going up (even to 85 cols) would mean losing a > buffer. (Or straining my eyes.) Of course I can deal with wrapped lines. > But I still vote for 80 characters as a target, while allowing people > wiggle room to miss this target. > > The number 80 is with us for historical reasons, but I know I'm not the > only one who still routinely uses 80-column buffers. > > Richard > > On Nov 9, 2015, at 5:45 PM, Simon Peyton Jones > wrote: > > > In my view 80 chars is too short. It was justified in the days of > 80-column CRTs, but that just isn't a restriction any more. I routinely > edit in a much wider window. > > > > Clearly there's a judgement call here. But I'd prefer 120 cols say. > > > > Simon > > > > -----Original Message----- > > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > Richard Eisenberg > > Sent: 09 November 2015 21:03 > > To: ghc-devs Devs > > Subject: too many lines too long > > > > Hi devs, > > > > We seem to be uncommitted to the ideal of 80-character lines. Almost > every patch on Phab I look through has a bunch of "line too long" lint > errors. No one seems to do much about these. And Phab's very very loud > indication of a lint error makes reviewing the code harder. > > > > I like the ideal of 80-character lines. I aim for this ideal in my > patches, falling short sometimes, of course. But I think the current > setting of requiring everyone to "explain" away their overlong lines during > `arc diff` and then trying hard to ignore the lint errors during code > review is wrong. And it makes us all inured to more serious lint errors. > > > > How about this: after `arc diff` is run, it will count the number of > overlong lines before and after the patch. If there are more after, have > the last thing `arc diff` outputs be a stern telling-off of the dev, along > the lines of > > > >> Before your patch, 15 of the edited lines were over 80 characters. > >> Now, a whopping 28 of them are. Can't you do better? Please? > > > > Would this be ignored more or followed more? Who knows. But it would > sure be less annoying. :) > > > > What do others think? > > > > Thanks, > > Richard > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cebcdeaa0675a490898dc08d2e94927cc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6IXQEBFIJnDRWCSKmNxdVsWQm2bqPVPn133kblshukU%3d > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Tue Nov 10 14:48:23 2015 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Tue, 10 Nov 2015 09:48:23 -0500 Subject: How inline pragma works In-Reply-To: References: Message-ID: There's this section in GHC user manual: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/pragmas.html#inline-noinline-pragma But see also: https://ghc.haskell.org/trac/ghc/ticket/10766 2015-11-10 5:16 GMT-05:00 ????? ?????????? : > Hello everyone! > > Where can i read about how does INLINE pragma in compiler works? > > > --- > ? ?????????, > ?????????? ????? > > Best regards, > Edgar A. Zhavoronkov > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From marlowsd at gmail.com Tue Nov 10 16:23:37 2015 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 10 Nov 2015 16:23:37 +0000 Subject: too many lines too long In-Reply-To: <7A8FD49D-825F-48B6-BFD0-D019825109C9@cis.upenn.edu> References: <966B4013-23C0-45EA-975A-6506707A555E@cis.upenn.edu> <4662eae97b8e431eade708afc6906616@DB4PR30MB030.064d.mgd.msft.net> <7A8FD49D-825F-48B6-BFD0-D019825109C9@cis.upenn.edu> Message-ID: <56421A09.90605@gmail.com> I also use multiple 80-column windows side-by-side, and long lines are quite unreadable. I have a local emacs key binding to make the window 120 wide temporarily for when I'm working on Simon's code :-) There's also the issue of having side-by-side diffs in Phabricator being readable on a laptop screen, for which I think 80 is a reasonable limit. I think the current level of nagging in Phabricator isn't terrible, though if we want to make it less annoying I believe it's also possible to make it an "advice"-level warning, which wouldn't force you to explain yourself, but it would still appear in the diff. Cheers Simon On 09/11/2015 22:51, Richard Eisenberg wrote: > At both school and at home I can fit 3 80-character buffers side by side, at a comfortable font size. Going up (even to 85 cols) would mean losing a buffer. (Or straining my eyes.) Of course I can deal with wrapped lines. But I still vote for 80 characters as a target, while allowing people wiggle room to miss this target. > > The number 80 is with us for historical reasons, but I know I'm not the only one who still routinely uses 80-column buffers. > > Richard > > On Nov 9, 2015, at 5:45 PM, Simon Peyton Jones wrote: > >> In my view 80 chars is too short. It was justified in the days of 80-column CRTs, but that just isn't a restriction any more. I routinely edit in a much wider window. >> >> Clearly there's a judgement call here. But I'd prefer 120 cols say. >> >> Simon >> >> -----Original Message----- >> From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Richard Eisenberg >> Sent: 09 November 2015 21:03 >> To: ghc-devs Devs >> Subject: too many lines too long >> >> Hi devs, >> >> We seem to be uncommitted to the ideal of 80-character lines. Almost every patch on Phab I look through has a bunch of "line too long" lint errors. No one seems to do much about these. And Phab's very very loud indication of a lint error makes reviewing the code harder. >> >> I like the ideal of 80-character lines. I aim for this ideal in my patches, falling short sometimes, of course. But I think the current setting of requiring everyone to "explain" away their overlong lines during `arc diff` and then trying hard to ignore the lint errors during code review is wrong. And it makes us all inured to more serious lint errors. >> >> How about this: after `arc diff` is run, it will count the number of overlong lines before and after the patch. If there are more after, have the last thing `arc diff` outputs be a stern telling-off of the dev, along the lines of >> >>> Before your patch, 15 of the edited lines were over 80 characters. >>> Now, a whopping 28 of them are. Can't you do better? Please? >> >> Would this be ignored more or followed more? Who knows. But it would sure be less annoying. :) >> >> What do others think? >> >> Thanks, >> Richard >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cebcdeaa0675a490898dc08d2e94927cc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6IXQEBFIJnDRWCSKmNxdVsWQm2bqPVPn133kblshukU%3d >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From austin at well-typed.com Tue Nov 10 17:22:19 2015 From: austin at well-typed.com (Austin Seipp) Date: Tue, 10 Nov 2015 11:22:19 -0600 Subject: too many lines too long In-Reply-To: References: <966B4013-23C0-45EA-975A-6506707A555E@cis.upenn.edu> Message-ID: Lots of good replies in this thread. I just wanted to follow up on my suggestion from earlier and give some insight as to why I suggested this: The _only_ reason I really suggested a hard enforcement is because, roughly speaking, maintaining code is roughly ~infinitely more expensive than actually writing it. Abiding by a column limit, if enforced, seems really really trivial to many people and very stupid to reject a patch over. But it is far more useful to the tons of people who may read it later, because the labor balance is asymmetrical. The author of a patch must spend some amount of effort N writing it, where N is roughly linear in the size of the change. But the 'maintenance effort' for that patch is, instead, at least linear in the _lifetime of the project_. Basically: code is very cheap, but maintenance is extremely costly. All that said, I'm not going to lose sleep over this, and it's not a stylistic hill that's worth dying on. And again, if GHC only had a few occurrences of this, it would be easier to fix, but that's not the case, and hampers contributors a bit. If anything, a more pressing stylistic concern is our odd naming scheme that has very little consistency, and that does make it harder to find and read things I think. :) On Mon, Nov 9, 2015 at 3:15 PM, Austin Seipp wrote: > Something like this might be possible. It'd just require implementing > a new arcanist linter, I think, and enabling it in .arclint > > In general I really sympathize with this. The problem 90% of people > hit is that they touch a line that was *already* over 80 columns, so > 'arc lint' warns them and gets annoyed, but they don't want to fix or > split up a bunch of stuff to avoid it. It's an issue of having to do > 'boring work' which nobody likes, and seems very tedious, regardless > of the mechanism of how they do the change. > > Really, I'm more inclined to begin a policy of rejecting reviews that > do not pass the linter. Exceptions can be made, but in general we need > to start *enforcing it* with the red button I think. And it would > require us to be more diligent about merging patches quickly to reduce > the scope of merge conflicts (because fixing an 80col violation > normally, almost always, adds more LOC). > > However, there are people who in general think the contribution > barrier is already too high, and I fear that enforcing this with a > hard rule may make people 'give up' because it seems like a pointless > thing to mandate to block their changes. I'm not sure how people feel > about that, but it is worth keeping in mind the developer economics. > > I hope suggesting the possibility of being more forceful against 80col > violations doesn't derail this too much. :) > > On Mon, Nov 9, 2015 at 3:02 PM, Richard Eisenberg wrote: >> Hi devs, >> >> We seem to be uncommitted to the ideal of 80-character lines. Almost every patch on Phab I look through has a bunch of "line too long" lint errors. No one seems to do much about these. And Phab's very very loud indication of a lint error makes reviewing the code harder. >> >> I like the ideal of 80-character lines. I aim for this ideal in my patches, falling short sometimes, of course. But I think the current setting of requiring everyone to "explain" away their overlong lines during `arc diff` and then trying hard to ignore the lint errors during code review is wrong. And it makes us all inured to more serious lint errors. >> >> How about this: after `arc diff` is run, it will count the number of overlong lines before and after the patch. If there are more after, have the last thing `arc diff` outputs be a stern telling-off of the dev, along the lines of >> >>> Before your patch, 15 of the edited lines were over 80 characters. >>> Now, a whopping 28 of them are. Can't you do better? Please? >> >> Would this be ignored more or followed more? Who knows. But it would sure be less annoying. :) >> >> What do others think? >> >> Thanks, >> Richard >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From edzhavoronkov at gmail.com Tue Nov 10 20:57:08 2015 From: edzhavoronkov at gmail.com (=?UTF-8?B?0K3QtNCz0LDRgCDQltCw0LLQvtGA0L7QvdC60L7Qsg==?=) Date: Tue, 10 Nov 2015 23:57:08 +0300 Subject: How inline pragma works In-Reply-To: References: Message-ID: And can you tell me, where can i find a source code in GHC to see, how this pragma is handeled? --- ? ?????????, ?????????? ????? Best regards, Edgar A. Zhavoronkov 2015-11-10 17:48 GMT+03:00 ?mer Sinan A?acan : > There's this section in GHC user manual: > > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/pragmas.html#inline-noinline-pragma > > But see also: https://ghc.haskell.org/trac/ghc/ticket/10766 > > 2015-11-10 5:16 GMT-05:00 ????? ?????????? : > > Hello everyone! > > > > Where can i read about how does INLINE pragma in compiler works? > > > > > > --- > > ? ?????????, > > ?????????? ????? > > > > Best regards, > > Edgar A. Zhavoronkov > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Tue Nov 10 21:33:22 2015 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Tue, 10 Nov 2015 16:33:22 -0500 Subject: How inline pragma works In-Reply-To: References: Message-ID: I don't know the whole story, but here are some pointers to get you started: - Internally, inlined code is called "unfolding". You can see the definition in CoreSyn. - CoreUnfold module has important functions to decide whether to inline or not. - Actual work of replacing identifiers with their definitions is done in Simplify and probably in some other places. I believe if you start grepping for functions in CoreUnfold you can find all the places that inlining is done. It may be just the simplifier, I'm not sure. (see SimplUtils.preInlineUnconditionally and SimplUtils.postInlineUnconditionally) When you figure the details it'd be great if you could give us a hand in #10766 :) 2015-11-10 15:57 GMT-05:00 ????? ?????????? : > And can you tell me, where can i find a source code in GHC to see, how this > pragma is handeled? > > --- > ? ?????????, > ?????????? ????? > > Best regards, > Edgar A. Zhavoronkov > > 2015-11-10 17:48 GMT+03:00 ?mer Sinan A?acan : >> >> There's this section in GHC user manual: >> >> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/pragmas.html#inline-noinline-pragma >> >> But see also: https://ghc.haskell.org/trac/ghc/ticket/10766 >> >> 2015-11-10 5:16 GMT-05:00 ????? ?????????? : >> > Hello everyone! >> > >> > Where can i read about how does INLINE pragma in compiler works? >> > >> > >> > --- >> > ? ?????????, >> > ?????????? ????? >> > >> > Best regards, >> > Edgar A. Zhavoronkov >> > >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > > From ekmett at gmail.com Tue Nov 10 21:47:02 2015 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 10 Nov 2015 16:47:02 -0500 Subject: too many lines too long In-Reply-To: <4662eae97b8e431eade708afc6906616@DB4PR30MB030.064d.mgd.msft.net> References: <966B4013-23C0-45EA-975A-6506707A555E@cis.upenn.edu> <4662eae97b8e431eade708afc6906616@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Heck, I've been able to use 132 columns since my VT-220 days. ;) -Edward On Mon, Nov 9, 2015 at 5:45 PM, Simon Peyton Jones wrote: > In my view 80 chars is too short. It was justified in the days of > 80-column CRTs, but that just isn't a restriction any more. I routinely > edit in a much wider window. > > Clearly there's a judgement call here. But I'd prefer 120 cols say. > > Simon > > -----Original Message----- > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Richard > Eisenberg > Sent: 09 November 2015 21:03 > To: ghc-devs Devs > Subject: too many lines too long > > Hi devs, > > We seem to be uncommitted to the ideal of 80-character lines. Almost every > patch on Phab I look through has a bunch of "line too long" lint errors. No > one seems to do much about these. And Phab's very very loud indication of a > lint error makes reviewing the code harder. > > I like the ideal of 80-character lines. I aim for this ideal in my > patches, falling short sometimes, of course. But I think the current > setting of requiring everyone to "explain" away their overlong lines during > `arc diff` and then trying hard to ignore the lint errors during code > review is wrong. And it makes us all inured to more serious lint errors. > > How about this: after `arc diff` is run, it will count the number of > overlong lines before and after the patch. If there are more after, have > the last thing `arc diff` outputs be a stern telling-off of the dev, along > the lines of > > > Before your patch, 15 of the edited lines were over 80 characters. > > Now, a whopping 28 of them are. Can't you do better? Please? > > Would this be ignored more or followed more? Who knows. But it would sure > be less annoying. :) > > What do others think? > > Thanks, > Richard > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cebcdeaa0675a490898dc08d2e94927cc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6IXQEBFIJnDRWCSKmNxdVsWQm2bqPVPn133kblshukU%3d > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander at plaimi.net Wed Nov 11 09:50:41 2015 From: alexander at plaimi.net (Alexander Berntsen) Date: Wed, 11 Nov 2015 10:50:41 +0100 Subject: too many lines too long In-Reply-To: <7A8FD49D-825F-48B6-BFD0-D019825109C9@cis.upenn.edu> References: <966B4013-23C0-45EA-975A-6506707A555E@cis.upenn.edu> <4662eae97b8e431eade708afc6906616@DB4PR30MB030.064d.mgd.msft.net> <7A8FD49D-825F-48B6-BFD0-D019825109C9@cis.upenn.edu> Message-ID: <56430F71.3040407@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 FWIW, I agree with Austin on this. On 09/11/15 23:51, Richard Eisenberg wrote: > I know I'm not the only one who still routinely uses 80-column > buffers. My preferences are 78 > 74 > 80 > less than 80 > *. I don't feel strongly about any =<80 number in particular, but I feel rather strongly about =<80. However, the most important thing is choosing a limit and sticking to it. If you're not going to do anything about it, why have Phabricator warn about it at all. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWQw9wAAoJENQqWdRUGk8BJBEP/Ao7zyCh0zmR1aDpa0oy2d76 6X+2gBsx3aA6kEJmkaM6I23eAQLBowkHAwS5y2lizouulvPVkL7ZRIA25U5adutq swGmsoQXS+n/dJtkVpugnW116ILEnORC7Y/NHH+cHhUMuCdWTWsANssF6h3gHciN SH1nS1O4oPI63kpb7PhZA5r4CpVWGwD9aq8bruKrLPmZkYuvdYgF4Vly69UX6n1z P5wVEfws04E/sdM/BRf4v1JY0TpgP0CBOnjDIcX63Rhir9xAp3jAUyMHOVHdHnKh +TaHGmwkavINhpOjQgNh6akNoC/Nh4ocWq7J9Hqo9JgdIW2LfUozf52Ha7jFUaeu 6gXXr4stMnfv6fje3MNFpIQ1tCTarDsvCTJ549rqmH++RVtZLFmDpnXQAYMq8wNd sqDCtmdM8bOgru3kkdsJjGRFumZ5k+r9riKf/STXdf4rXfZt20aq0hg+snZDWSIQ 0zyTl6jYD+0Xu8naP3/F+THvLzEpefOROAFdYpii2R42Y5jBA56XSbJ4atkLdA/1 fUaewmYomGHeCileolJ56A0qgnoh67siEYQ8aKMfK68B9anvjvkN/0trixNEF94B CMWJrBGoK4NOyQX7TuJKNq9cCELLpvsjr8oU1J4UyZfYm10Zcjm0JN+JGqwtM64A pfLNN+0yi7kYtUiGPaUy =bt6t -----END PGP SIGNATURE----- From jan.stolarek at p.lodz.pl Wed Nov 11 11:14:20 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Wed, 11 Nov 2015 12:14:20 +0100 Subject: Pretty-printing TH data types Message-ID: <201511111214.20513.jan.stolarek@p.lodz.pl> Devs, Module Language.Haskell.TH.Ppr defines Ppr instances for Template Haskell data types. What is the fastest way of testing these instances, ie. pretty-printing TH data types? I want to make sure that the instances I added print the data type in the way that I expect. Janek --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From c.maeder at jacobs-university.de Wed Nov 11 12:03:50 2015 From: c.maeder at jacobs-university.de (C Maeder) Date: Wed, 11 Nov 2015 13:03:50 +0100 Subject: too many lines too long In-Reply-To: <966B4013-23C0-45EA-975A-6506707A555E@cis.upenn.edu> References: <966B4013-23C0-45EA-975A-6506707A555E@cis.upenn.edu> Message-ID: <56432EA6.40502@jacobs-university.de> Maybe increasing the limit is not such a bad idea (see scala blog) http://hilton.org.uk/blog/source-code-line-length "GitHub is the de facto coding standard 125 characters per line is the real de facto coding standard for maximum line length these days, because this is the maximum number of characters that you can see in the GitHub diff view." Cheers Christian On 09.11.2015 22:02, Richard Eisenberg wrote: > Hi devs, > > We seem to be uncommitted to the ideal of 80-character lines. Almost every patch on Phab I look through has a bunch of "line too long" lint errors. No one seems to do much about these. And Phab's very very loud indication of a lint error makes reviewing the code harder. > > I like the ideal of 80-character lines. I aim for this ideal in my patches, falling short sometimes, of course. But I think the current setting of requiring everyone to "explain" away their overlong lines during `arc diff` and then trying hard to ignore the lint errors during code review is wrong. And it makes us all inured to more serious lint errors. > > How about this: after `arc diff` is run, it will count the number of overlong lines before and after the patch. If there are more after, have the last thing `arc diff` outputs be a stern telling-off of the dev, along the lines of > >> Before your patch, 15 of the edited lines were over 80 characters. >> Now, a whopping 28 of them are. Can't you do better? Please? > > Would this be ignored more or followed more? Who knows. But it would sure be less annoying. :) > > What do others think? > > Thanks, > Richard > From eir at cis.upenn.edu Wed Nov 11 14:12:04 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 11 Nov 2015 09:12:04 -0500 Subject: Pretty-printing TH data types In-Reply-To: <201511111214.20513.jan.stolarek@p.lodz.pl> References: <201511111214.20513.jan.stolarek@p.lodz.pl> Message-ID: <34436181-34C2-4D6A-A788-C2256B5E32B2@cis.upenn.edu> Does this Template Haskell template work for you? > {-# LANGUAGE TemplateHaskell #-} > > module TestTH where > > import Language.Haskell.TH.Ppr > import Language.Haskell.TH > > $( do expr <- [| \x -> case x of True -> not; False -> id |] > runIO $ putStrLn $ pprint expr > return [] ) Richard On Nov 11, 2015, at 6:14 AM, Jan Stolarek wrote: > Devs, > > Module Language.Haskell.TH.Ppr defines Ppr instances for Template Haskell data types. What is the > fastest way of testing these instances, ie. pretty-printing TH data types? I want to make sure > that the instances I added print the data type in the way that I expect. > > Janek > > --- > Politechnika ??dzka > Lodz University of Technology > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? > prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > > This email contains information intended solely for the use of the individual to whom it is addressed. > If you are not the intended recipient or if you have received this message in error, > please notify the sender and delete it from your system. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From jan.stolarek at p.lodz.pl Wed Nov 11 15:14:43 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Wed, 11 Nov 2015 16:14:43 +0100 Subject: Pretty-printing TH data types In-Reply-To: <34436181-34C2-4D6A-A788-C2256B5E32B2@cis.upenn.edu> References: <201511111214.20513.jan.stolarek@p.lodz.pl> <34436181-34C2-4D6A-A788-C2256B5E32B2@cis.upenn.edu> Message-ID: <201511111614.43323.jan.stolarek@p.lodz.pl> Yes, that does the job. Thanks. Janek Dnia ?roda, 11 listopada 2015, Richard Eisenberg napisa?: > Does this Template Haskell template work for you? > > > {-# LANGUAGE TemplateHaskell #-} > > > > module TestTH where > > > > import Language.Haskell.TH.Ppr > > import Language.Haskell.TH > > > > $( do expr <- [| \x -> case x of True -> not; False -> id |] > > runIO $ putStrLn $ pprint expr > > return [] ) > > Richard > > On Nov 11, 2015, at 6:14 AM, Jan Stolarek wrote: > > Devs, > > > > Module Language.Haskell.TH.Ppr defines Ppr instances for Template Haskell > > data types. What is the fastest way of testing these instances, ie. > > pretty-printing TH data types? I want to make sure that the instances I > > added print the data type in the way that I expect. > > > > Janek > > > > --- > > Politechnika ??dzka > > Lodz University of Technology > > > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. > > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez > > pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > > > > This email contains information intended solely for the use of the > > individual to whom it is addressed. If you are not the intended recipient > > or if you have received this message in error, please notify the sender > > and delete it from your system. > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From eir at cis.upenn.edu Wed Nov 11 16:26:58 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 11 Nov 2015 11:26:58 -0500 Subject: Pre-Proposal: Introspective Template Haskell Message-ID: <792B5E26-FE61-4FC3-9A45-4948DBED1B4C@cis.upenn.edu> Hi devs, There's a bunch of open tickets around Template Haskell. A great many of them are attempts to make TH more like what's already in GHC. Of course, when someone improves GHC, then TH also has to be updated. But this doesn't always happen, leading to several of these tickets. I believe I have a solution to the problem: just eliminate Template Haskell and provide direct access to GHC's internal structures. The idea (still very sketchy; hence pre-proposal) is like this (numbered for easy reference, but no order is implied): 1. TH quotes would remain. DsMeta would desugar quotes into Core code that produces HsExprs. For example, [| 1 |] would have type (Q (LHsExpr Name)). (Or perhaps (Q (LHsExpr RdrName)) if that works out better for clients.) 2. TH splices would remain, working much as they do now. The expression inside, say, an expression splice would have type (Q exp) where we can satisfy the constraint (SpliceExpr exp). There would be instances for (SpliceExpr (LHsExpr Name)) and (SpliceExpr (LHsExpr RdrName)) as well as the non-located variants. Generalizing the type of expressions here allows users not to worry about un-renaming when roundtripping between quotes and splices. 3. Reification would remain, using an Info structure much like we have now. Would we expose the real GHC TyCons as the result of reification? Or is it better to give the users HsDecls? This would need to be fleshed out. 4. Lifting would remain, doing the obvious thing. 5. The template-haskell package could even remain, as a backward-compatibility shim. It would declare gobs of pattern synonyms and type synonyms to wrap the new underlying interface. This re-imagined template-haskell package would not need to be a boot library, and could be upgraded separately from GHC. We could even maintain multiple versions of the library so that TH clients wouldn't have to change their code when GHC upgrades. Perhaps someday we could think about deprecating, if that's the way the wind blows. So, the end result is a completely re-engineered TH, but I believe we could keep full backward compatibility. (I have not considered Typed TH in any depth yet. But my hope is that it's not too different from the above.) And, we're left with a significantly lower maintenance burden, especially if we eliminate template-haskell someday. And, tantalizingly, the flexibility in splices might allow us to splice in *Core* code someday. Perhaps we could also reify Core code. Then clients could write their own custom, domain-aware optimizations. Like RULES on steroids. But that's all for the next phase. (Giving due credit, this last bit is inspired by work David Christiansen is doing in Idris.) What's wrong with this idea? I feel like *something* has to be more complicated than I've made it seem! Richard From dan.doel at gmail.com Wed Nov 11 17:32:29 2015 From: dan.doel at gmail.com (Dan Doel) Date: Wed, 11 Nov 2015 12:32:29 -0500 Subject: too many lines too long In-Reply-To: <56432EA6.40502@jacobs-university.de> References: <966B4013-23C0-45EA-975A-6506707A555E@cis.upenn.edu> <56432EA6.40502@jacobs-university.de> Message-ID: I don't really have a strong opinion on what gets decided here. But, I might take the blog post with some salt. I write some Scala for work, and despite not being a fan of long lines, I find myself writing them in Scala (and our code base has many), because it is often difficult to break a single line into multiple lines in a way that looks good in Scala (in my opinion at least, although I know at least one other person who shares my opinion). So for Scala, I'd probably look for justifications of longer lines, because they look better there. By contrast, I find it much easier to format Haskell code to 80 columns in a way that looks good. So my average Haskell line length is almost certainly shorter than my Scala line length, because I prefer something around 80 columns when possible. Just a thought, -- Dan P.S. I don't see why github would be relevant for a project that doesn't use it. It seems like a better idea to base line length on what the tools GHC actually uses can handle well. Maybe that was the point, though. On Wed, Nov 11, 2015 at 7:03 AM, C Maeder wrote: > Maybe increasing the limit is not such a bad idea (see scala blog) > http://hilton.org.uk/blog/source-code-line-length > > "GitHub is the de facto coding standard > > 125 characters per line is the real de facto coding standard for maximum > line length these days, because this is the maximum number of characters > that you can see in the GitHub diff view." > > Cheers Christian > > On 09.11.2015 22:02, Richard Eisenberg wrote: >> Hi devs, >> >> We seem to be uncommitted to the ideal of 80-character lines. Almost every patch on Phab I look through has a bunch of "line too long" lint errors. No one seems to do much about these. And Phab's very very loud indication of a lint error makes reviewing the code harder. >> >> I like the ideal of 80-character lines. I aim for this ideal in my patches, falling short sometimes, of course. But I think the current setting of requiring everyone to "explain" away their overlong lines during `arc diff` and then trying hard to ignore the lint errors during code review is wrong. And it makes us all inured to more serious lint errors. >> >> How about this: after `arc diff` is run, it will count the number of overlong lines before and after the patch. If there are more after, have the last thing `arc diff` outputs be a stern telling-off of the dev, along the lines of >> >>> Before your patch, 15 of the edited lines were over 80 characters. >>> Now, a whopping 28 of them are. Can't you do better? Please? >> >> Would this be ignored more or followed more? Who knows. But it would sure be less annoying. :) >> >> What do others think? >> >> Thanks, >> Richard >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From eric at seidel.io Wed Nov 11 17:46:03 2015 From: eric at seidel.io (Eric Seidel) Date: Wed, 11 Nov 2015 09:46:03 -0800 Subject: Pre-Proposal: Introspective Template Haskell In-Reply-To: <792B5E26-FE61-4FC3-9A45-4948DBED1B4C@cis.upenn.edu> References: <792B5E26-FE61-4FC3-9A45-4948DBED1B4C@cis.upenn.edu> Message-ID: <1447263963.2461981.436253921.5899CBC1@webmail.messagingengine.com> I think backwards-compatibility is still a potential issue, not because the pattern/type synonym layer seems implausible, but because I suspect people will begin to sidestep the compatibility layer and just use the GHC API (I certainly would). GHC is not shy about breaking backwards-compatibility between major releases, so it seems possible that this could extend to breaking TH. Missing features is not nearly as bad as breaking most clients of TH. But perhaps this isn't a very likely scenario. TH mostly exports datatypes for haskell syntax, smart constructors, and a few functions for looking up metadata. I doubt these pieces of GHC change very often, and when they do it's probably an extension rather than a breaking change. Someone with more historical knowledge of GHC could comment :) All in all, I like this idea a lot! Eric On Wed, Nov 11, 2015, at 08:26, Richard Eisenberg wrote: > Hi devs, > > There's a bunch of open tickets around Template Haskell. A great many of > them are attempts to make TH more like what's already in GHC. Of course, > when someone improves GHC, then TH also has to be updated. But this > doesn't always happen, leading to several of these tickets. > > I believe I have a solution to the problem: just eliminate Template > Haskell and provide direct access to GHC's internal structures. The idea > (still very sketchy; hence pre-proposal) is like this (numbered for easy > reference, but no order is implied): > > 1. TH quotes would remain. DsMeta would desugar quotes into Core code > that produces HsExprs. For example, [| 1 |] would have type (Q (LHsExpr > Name)). (Or perhaps (Q (LHsExpr RdrName)) if that works out better for > clients.) > > 2. TH splices would remain, working much as they do now. The expression > inside, say, an expression splice would have type (Q exp) where we can > satisfy the constraint (SpliceExpr exp). There would be instances for > (SpliceExpr (LHsExpr Name)) and (SpliceExpr (LHsExpr RdrName)) as well as > the non-located variants. Generalizing the type of expressions here > allows users not to worry about un-renaming when roundtripping between > quotes and splices. > > 3. Reification would remain, using an Info structure much like we have > now. Would we expose the real GHC TyCons as the result of reification? Or > is it better to give the users HsDecls? This would need to be fleshed > out. > > 4. Lifting would remain, doing the obvious thing. > > 5. The template-haskell package could even remain, as a > backward-compatibility shim. It would declare gobs of pattern synonyms > and type synonyms to wrap the new underlying interface. This re-imagined > template-haskell package would not need to be a boot library, and could > be upgraded separately from GHC. We could even maintain multiple versions > of the library so that TH clients wouldn't have to change their code when > GHC upgrades. Perhaps someday we could think about deprecating, if that's > the way the wind blows. > > So, the end result is a completely re-engineered TH, but I believe we > could keep full backward compatibility. (I have not considered Typed TH > in any depth yet. But my hope is that it's not too different from the > above.) And, we're left with a significantly lower maintenance burden, > especially if we eliminate template-haskell someday. > > And, tantalizingly, the flexibility in splices might allow us to splice > in *Core* code someday. Perhaps we could also reify Core code. Then > clients could write their own custom, domain-aware optimizations. Like > RULES on steroids. But that's all for the next phase. (Giving due credit, > this last bit is inspired by work David Christiansen is doing in Idris.) > > What's wrong with this idea? I feel like *something* has to be more > complicated than I've made it seem! > > Richard > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From eir at cis.upenn.edu Wed Nov 11 17:50:36 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 11 Nov 2015 12:50:36 -0500 Subject: Pre-Proposal: Introspective Template Haskell In-Reply-To: <1447263963.2461981.436253921.5899CBC1@webmail.messagingengine.com> References: <792B5E26-FE61-4FC3-9A45-4948DBED1B4C@cis.upenn.edu> <1447263963.2461981.436253921.5899CBC1@webmail.messagingengine.com> Message-ID: <8B283903-F125-4654-B7CE-91889314ADDE@cis.upenn.edu> On Nov 11, 2015, at 12:46 PM, Eric Seidel wrote: > I think backwards-compatibility is still a potential issue, not because > the pattern/type synonym layer seems implausible, but because I suspect > people will begin to sidestep the compatibility layer and just use the > GHC API (I certainly would). GHC is not shy about breaking > backwards-compatibility between major releases, so it seems possible > that this could extend to breaking TH. Missing features is not nearly as > bad as breaking most clients of TH. This is a very good point. We would want to bless some API that would remain stable. Then, clients that go around that API get what they deserve. A starting point for the stable API would be today's template-haskell (less some unsafe features, like exposing NameG). > > But perhaps this isn't a very likely scenario. TH mostly exports > datatypes for haskell syntax, smart constructors, and a few functions > for looking up metadata. I doubt these pieces of GHC change very often, > and when they do it's probably an extension rather than a breaking > change. Someone with more historical knowledge of GHC could comment :) I actually think this *is* a likely scenario. In the last revision of GHC, lots of AST changes have taken place. We would want to insulate TH users from this. Richard > > All in all, I like this idea a lot! > > Eric > > On Wed, Nov 11, 2015, at 08:26, Richard Eisenberg wrote: >> Hi devs, >> >> There's a bunch of open tickets around Template Haskell. A great many of >> them are attempts to make TH more like what's already in GHC. Of course, >> when someone improves GHC, then TH also has to be updated. But this >> doesn't always happen, leading to several of these tickets. >> >> I believe I have a solution to the problem: just eliminate Template >> Haskell and provide direct access to GHC's internal structures. The idea >> (still very sketchy; hence pre-proposal) is like this (numbered for easy >> reference, but no order is implied): >> >> 1. TH quotes would remain. DsMeta would desugar quotes into Core code >> that produces HsExprs. For example, [| 1 |] would have type (Q (LHsExpr >> Name)). (Or perhaps (Q (LHsExpr RdrName)) if that works out better for >> clients.) >> >> 2. TH splices would remain, working much as they do now. The expression >> inside, say, an expression splice would have type (Q exp) where we can >> satisfy the constraint (SpliceExpr exp). There would be instances for >> (SpliceExpr (LHsExpr Name)) and (SpliceExpr (LHsExpr RdrName)) as well as >> the non-located variants. Generalizing the type of expressions here >> allows users not to worry about un-renaming when roundtripping between >> quotes and splices. >> >> 3. Reification would remain, using an Info structure much like we have >> now. Would we expose the real GHC TyCons as the result of reification? Or >> is it better to give the users HsDecls? This would need to be fleshed >> out. >> >> 4. Lifting would remain, doing the obvious thing. >> >> 5. The template-haskell package could even remain, as a >> backward-compatibility shim. It would declare gobs of pattern synonyms >> and type synonyms to wrap the new underlying interface. This re-imagined >> template-haskell package would not need to be a boot library, and could >> be upgraded separately from GHC. We could even maintain multiple versions >> of the library so that TH clients wouldn't have to change their code when >> GHC upgrades. Perhaps someday we could think about deprecating, if that's >> the way the wind blows. >> >> So, the end result is a completely re-engineered TH, but I believe we >> could keep full backward compatibility. (I have not considered Typed TH >> in any depth yet. But my hope is that it's not too different from the >> above.) And, we're left with a significantly lower maintenance burden, >> especially if we eliminate template-haskell someday. >> >> And, tantalizingly, the flexibility in splices might allow us to splice >> in *Core* code someday. Perhaps we could also reify Core code. Then >> clients could write their own custom, domain-aware optimizations. Like >> RULES on steroids. But that's all for the next phase. (Giving due credit, >> this last bit is inspired by work David Christiansen is doing in Idris.) >> >> What's wrong with this idea? I feel like *something* has to be more >> complicated than I've made it seem! >> >> Richard >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From eir at cis.upenn.edu Wed Nov 11 18:03:13 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 11 Nov 2015 13:03:13 -0500 Subject: one weird trick to get all your types Message-ID: <47100068-0AB1-4482-A894-988D0F20F8E6@cis.upenn.edu> Hi devs, I spent some of my time at Hac Phi this past weekend teaching a few people the ropes about GHC hacking. One innocently asked if it's possible to load GHC into GHCi. I shuddered at the thought. But, actually, you can get quite close to this ideal: > ghc-stage2 --interactive GHCi, version 7.11.20151104: http://www.haskell.org/ghc/ :? for help Prelude> :set -package ghc -- THIS IS THE KEY LINE package flags have changed, resetting and loading new packages... Prelude> import TcMType Prelude TcMType> :t newEvVar newEvVar :: forall gbl lcl. TcType.TcPredType -> TcRnTypes.TcRnIf gbl lcl Var.EvVar Prelude TcMType> Pretty cool, huh? This improves my life. Hopefully it improves yours, too. Richard PS: Can anyone recommend a place on the wiki where I should put this? From eric at seidel.io Wed Nov 11 18:06:29 2015 From: eric at seidel.io (Eric Seidel) Date: Wed, 11 Nov 2015 10:06:29 -0800 Subject: Pre-Proposal: Introspective Template Haskell In-Reply-To: <8B283903-F125-4654-B7CE-91889314ADDE@cis.upenn.edu> References: <792B5E26-FE61-4FC3-9A45-4948DBED1B4C@cis.upenn.edu> <1447263963.2461981.436253921.5899CBC1@webmail.messagingengine.com> <8B283903-F125-4654-B7CE-91889314ADDE@cis.upenn.edu> Message-ID: <1447265189.2467699.436290153.27B01D12@webmail.messagingengine.com> On Wed, Nov 11, 2015, at 09:50, Richard Eisenberg wrote: > > On Nov 11, 2015, at 12:46 PM, Eric Seidel wrote: > > > I think backwards-compatibility is still a potential issue, not because > > the pattern/type synonym layer seems implausible, but because I suspect > > people will begin to sidestep the compatibility layer and just use the > > GHC API (I certainly would). GHC is not shy about breaking > > backwards-compatibility between major releases, so it seems possible > > that this could extend to breaking TH. Missing features is not nearly as > > bad as breaking most clients of TH. > > This is a very good point. We would want to bless some API that would > remain stable. Then, clients that go around that API get what they > deserve. A starting point for the stable API would be today's > template-haskell (less some unsafe features, like exposing NameG). > > > > > But perhaps this isn't a very likely scenario. TH mostly exports > > datatypes for haskell syntax, smart constructors, and a few functions > > for looking up metadata. I doubt these pieces of GHC change very often, > > and when they do it's probably an extension rather than a breaking > > change. Someone with more historical knowledge of GHC could comment :) > > I actually think this *is* a likely scenario. In the last revision of > GHC, lots of AST changes have taken place. We would want to insulate TH > users from this. You're talking about the ApiAnnotations stuff right? Or was there another big change? I had assumed that the ApiAnnotations changes fell into the "extension" category rather than "breaking", because presumably the changes amounted to adding a bunch of extra record fields (I didn't follow this patch so could be way off base...) Then again, even adding a record field is a breaking change as it changes the arity of the datacon... So I agree, we really ought to have a blessed API that we guarantee across versions. We could maintain it via pattern/type synonyms. (This would be a Good Thing even if we ignore your proposal!) Eric From alan.zimm at gmail.com Wed Nov 11 18:10:18 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Wed, 11 Nov 2015 20:10:18 +0200 Subject: Pre-Proposal: Introspective Template Haskell In-Reply-To: <1447265189.2467699.436290153.27B01D12@webmail.messagingengine.com> References: <792B5E26-FE61-4FC3-9A45-4948DBED1B4C@cis.upenn.edu> <1447263963.2461981.436253921.5899CBC1@webmail.messagingengine.com> <8B283903-F125-4654-B7CE-91889314ADDE@cis.upenn.edu> <1447265189.2467699.436290153.27B01D12@webmail.messagingengine.com> Message-ID: >From an ApiAnnotations point of view, they will change to match changes in the AST, they cannot be a brake on improvements. We do intend to nudge the AST toward being more ApiAnnotations friendly over time. If the AST is shared, then a scenario of generating TH and being able to pretty-print it in compilable form becomes possible. Alan On Wed, Nov 11, 2015 at 8:06 PM, Eric Seidel wrote: > > > On Wed, Nov 11, 2015, at 09:50, Richard Eisenberg wrote: > > > > On Nov 11, 2015, at 12:46 PM, Eric Seidel wrote: > > > > > I think backwards-compatibility is still a potential issue, not because > > > the pattern/type synonym layer seems implausible, but because I suspect > > > people will begin to sidestep the compatibility layer and just use the > > > GHC API (I certainly would). GHC is not shy about breaking > > > backwards-compatibility between major releases, so it seems possible > > > that this could extend to breaking TH. Missing features is not nearly > as > > > bad as breaking most clients of TH. > > > > This is a very good point. We would want to bless some API that would > > remain stable. Then, clients that go around that API get what they > > deserve. A starting point for the stable API would be today's > > template-haskell (less some unsafe features, like exposing NameG). > > > > > > > > But perhaps this isn't a very likely scenario. TH mostly exports > > > datatypes for haskell syntax, smart constructors, and a few functions > > > for looking up metadata. I doubt these pieces of GHC change very often, > > > and when they do it's probably an extension rather than a breaking > > > change. Someone with more historical knowledge of GHC could comment :) > > > > I actually think this *is* a likely scenario. In the last revision of > > GHC, lots of AST changes have taken place. We would want to insulate TH > > users from this. > > You're talking about the ApiAnnotations stuff right? Or was there > another big change? > > I had assumed that the ApiAnnotations changes fell into the "extension" > category rather than "breaking", because presumably the changes amounted > to adding a bunch of extra record fields (I didn't follow this patch so > could be way off base...) > > Then again, even adding a record field is a breaking change as it > changes the arity of the datacon... So I agree, we really ought to have > a blessed API that we guarantee across versions. We could maintain it > via pattern/type synonyms. (This would be a Good Thing even if we ignore > your proposal!) > > Eric > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Wed Nov 11 19:21:04 2015 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 11 Nov 2015 14:21:04 -0500 Subject: Pre-Proposal: Introspective Template Haskell In-Reply-To: <1447263963.2461981.436253921.5899CBC1@webmail.messagingengine.com> References: <792B5E26-FE61-4FC3-9A45-4948DBED1B4C@cis.upenn.edu> <1447263963.2461981.436253921.5899CBC1@webmail.messagingengine.com> Message-ID: In practice I find that almost every piece of template-haskell code I've written gets broken by something every other release of GHC, so it hasn't exactly been a shining beacon of backwards compatibility thus far. Invariably it is always missing _something_ that I need, and anything that ties it to a more canonical form like this would be a very good thing. I'd strongly support this move. A sample just from my current working directory: haskell> grep -r MIN_VERSION_template_haskell */src bifunctors/src/Data/Bifunctor/TH/Internal.hs:#if MIN_VERSION_template_haskell(2,10,0) bifunctors/src/Data/Bifunctor/TH/Internal.hs:#if MIN_VERSION_template_haskell(2,7,0) bifunctors/src/Data/Bifunctor/TH/Internal.hs:#if MIN_VERSION_template_haskell(2,10,0) bifunctors/src/Data/Bifunctor/TH/Internal.hs:#if MIN_VERSION_template_haskell(2,8,0) bifunctors/src/Data/Bifunctor/TH/Internal.hs:#if MIN_VERSION_template_haskell(2,8,0) bifunctors/src/Data/Bifunctor/TH/Internal.hs:#if MIN_VERSION_template_haskell(2,8,0) bifunctors/src/Data/Bifunctor/TH.hs:#ifndef MIN_VERSION_template_haskell bifunctors/src/Data/Bifunctor/TH.hs:#if __GLASGOW_HASKELL__ < 710 && MIN_VERSION_template_haskell(2,8,0) bifunctors/src/Data/Bifunctor/TH.hs:#if MIN_VERSION_template_haskell(2,7,0) bifunctors/src/Data/Bifunctor/TH.hs:#if MIN_VERSION_template_haskell(2,7,0) bifunctors/src/Data/Bifunctor/TH.hs:#if MIN_VERSION_template_haskell(2,7,0) bifunctors/src/Data/Bifunctor/TH.hs:#if MIN_VERSION_template_haskell(2,7,0) bifunctors/src/Data/Bifunctor/TH.hs:#if MIN_VERSION_template_haskell(2,7,0) bifunctors/src/Data/Bifunctor/TH.hs:# if __GLASGOW_HASKELL__ >= 710 || !(MIN_VERSION_template_haskell(2,8,0)) bifunctors/src/Data/Bifunctor/TH.hs:#if MIN_VERSION_template_haskell(2,7,0) free/src/Control/Monad/Free/TH.hs:#if MIN_VERSION_template_haskell(2,10,0) lens/src/Control/Lens/Internal/FieldTH.hs:#if MIN_VERSION_template_haskell(2,8,0) lens/src/Control/Lens/Internal/TH.hs:#ifndef MIN_VERSION_template_haskell lens/src/Control/Lens/Internal/TH.hs:#define MIN_VERSION_template_haskell(x,y,z) (defined(__GLASGOW_HASKELL__) && __GLASGOW_HASKELL__ >= 706) lens/src/Control/Lens/Internal/TH.hs:#if MIN_VERSION_template_haskell(2,9,0) lens/src/Control/Lens/Plated.hs:#if !(MIN_VERSION_template_haskell(2,8,0)) lens/src/Control/Lens/TH.hs:#ifndef MIN_VERSION_template_haskell lens/src/Control/Lens/TH.hs:#define MIN_VERSION_template_haskell(x,y,z) (defined(__GLASGOW_HASKELL__) && __GLASGOW_HASKELL__ >= 706) lens/src/Control/Lens/TH.hs:#if !(MIN_VERSION_template_haskell(2,7,0)) lens/src/Control/Lens/TH.hs:#if MIN_VERSION_template_haskell(2,10,0) lens/src/Control/Lens/TH.hs:#if !(MIN_VERSION_template_haskell(2,7,0)) lens/src/Language/Haskell/TH/Lens.hs:#ifndef MIN_VERSION_template_haskell lens/src/Language/Haskell/TH/Lens.hs:#define MIN_VERSION_template_haskell(x,y,z) 1 lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,9,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,8,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,9,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,10,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,10,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,8,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,9,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,10,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,9,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,8,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,8,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,10,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,8,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,10,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,8,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,8,0) lens/src/Language/Haskell/TH/Lens.hs:#if !MIN_VERSION_template_haskell(2,10,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,9,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,8,0) lens/src/Language/Haskell/TH/Lens.hs:#if !MIN_VERSION_template_haskell(2,10,0) lens/src/Language/Haskell/TH/Lens.hs:#if !MIN_VERSION_template_haskell(2,10,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,8,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,8,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,8,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,9,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,10,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,10,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,8,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,8,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,9,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,10,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,9,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,9,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,8,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,8,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,10,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,8,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,8,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,10,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,8,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,8,0) lens/src/Language/Haskell/TH/Lens.hs:#if !MIN_VERSION_template_haskell(2,10,0) lens/src/Language/Haskell/TH/Lens.hs:#if MIN_VERSION_template_haskell(2,9,0) linear/src/Linear/V.hs:#ifdef MIN_VERSION_template_haskell linear/src/Linear/V.hs:#if !(MIN_VERSION_reflection(1,3,0)) && defined(MIN_VERSION_template_haskell) linear/src/Linear/V.hs:#if !(MIN_VERSION_reflection(1,3,0)) && defined(MIN_VERSION_template_haskell) nats/src/Numeric/Natural.hs:#if defined(MIN_VERSION_hashable) || defined(MIN_VERSION_template_haskell) nats/src/Numeric/Natural.hs:#ifdef MIN_VERSION_template_haskell nats/src/Numeric/Natural.hs:#ifdef MIN_VERSION_template_haskell tables/src/Data/Table.hs:#if MIN_VERSION_template_haskell(2,10,0) tables/src/Data/Table.hs:#if MIN_VERSION_template_haskell(2,9,0) tagged/src/Data/Proxy/TH.hs:#if MIN_VERSION_template_haskell(2,8,0) tagged/src/Data/Proxy/TH.hs:#if MIN_VERSION_template_haskell(2,8,0) tagged/src/Data/Proxy/TH.hs:#if MIN_VERSION_template_haskell(2,8,0) tagged/src/Data/Proxy/TH.hs:#if MIN_VERSION_template_haskell(2,8,0) On Wed, Nov 11, 2015 at 12:46 PM, Eric Seidel wrote: > I think backwards-compatibility is still a potential issue, not because > the pattern/type synonym layer seems implausible, but because I suspect > people will begin to sidestep the compatibility layer and just use the > GHC API (I certainly would). GHC is not shy about breaking > backwards-compatibility between major releases, so it seems possible > that this could extend to breaking TH. Missing features is not nearly as > bad as breaking most clients of TH. > > But perhaps this isn't a very likely scenario. TH mostly exports > datatypes for haskell syntax, smart constructors, and a few functions > for looking up metadata. I doubt these pieces of GHC change very often, > and when they do it's probably an extension rather than a breaking > change. Someone with more historical knowledge of GHC could comment :) > > All in all, I like this idea a lot! > > Eric > > On Wed, Nov 11, 2015, at 08:26, Richard Eisenberg wrote: > > Hi devs, > > > > There's a bunch of open tickets around Template Haskell. A great many of > > them are attempts to make TH more like what's already in GHC. Of course, > > when someone improves GHC, then TH also has to be updated. But this > > doesn't always happen, leading to several of these tickets. > > > > I believe I have a solution to the problem: just eliminate Template > > Haskell and provide direct access to GHC's internal structures. The idea > > (still very sketchy; hence pre-proposal) is like this (numbered for easy > > reference, but no order is implied): > > > > 1. TH quotes would remain. DsMeta would desugar quotes into Core code > > that produces HsExprs. For example, [| 1 |] would have type (Q (LHsExpr > > Name)). (Or perhaps (Q (LHsExpr RdrName)) if that works out better for > > clients.) > > > > 2. TH splices would remain, working much as they do now. The expression > > inside, say, an expression splice would have type (Q exp) where we can > > satisfy the constraint (SpliceExpr exp). There would be instances for > > (SpliceExpr (LHsExpr Name)) and (SpliceExpr (LHsExpr RdrName)) as well as > > the non-located variants. Generalizing the type of expressions here > > allows users not to worry about un-renaming when roundtripping between > > quotes and splices. > > > > 3. Reification would remain, using an Info structure much like we have > > now. Would we expose the real GHC TyCons as the result of reification? Or > > is it better to give the users HsDecls? This would need to be fleshed > > out. > > > > 4. Lifting would remain, doing the obvious thing. > > > > 5. The template-haskell package could even remain, as a > > backward-compatibility shim. It would declare gobs of pattern synonyms > > and type synonyms to wrap the new underlying interface. This re-imagined > > template-haskell package would not need to be a boot library, and could > > be upgraded separately from GHC. We could even maintain multiple versions > > of the library so that TH clients wouldn't have to change their code when > > GHC upgrades. Perhaps someday we could think about deprecating, if that's > > the way the wind blows. > > > > So, the end result is a completely re-engineered TH, but I believe we > > could keep full backward compatibility. (I have not considered Typed TH > > in any depth yet. But my hope is that it's not too different from the > > above.) And, we're left with a significantly lower maintenance burden, > > especially if we eliminate template-haskell someday. > > > > And, tantalizingly, the flexibility in splices might allow us to splice > > in *Core* code someday. Perhaps we could also reify Core code. Then > > clients could write their own custom, domain-aware optimizations. Like > > RULES on steroids. But that's all for the next phase. (Giving due credit, > > this last bit is inspired by work David Christiansen is doing in Idris.) > > > > What's wrong with this idea? I feel like *something* has to be more > > complicated than I've made it seem! > > > > Richard > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Wed Nov 11 19:25:16 2015 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 11 Nov 2015 14:25:16 -0500 Subject: Pre-Proposal: Introspective Template Haskell In-Reply-To: <8B283903-F125-4654-B7CE-91889314ADDE@cis.upenn.edu> References: <792B5E26-FE61-4FC3-9A45-4948DBED1B4C@cis.upenn.edu> <1447263963.2461981.436253921.5899CBC1@webmail.messagingengine.com> <8B283903-F125-4654-B7CE-91889314ADDE@cis.upenn.edu> Message-ID: On Wed, Nov 11, 2015 at 12:50 PM, Richard Eisenberg wrote: > > This is a very good point. We would want to bless some API that would > remain stable. Then, clients that go around that API get what they deserve. > A starting point for the stable API would be today's template-haskell (less > some unsafe features, like exposing NameG). > As a data point, in a couple of packages I wind up forced into using mkNameG_v and mkNameG_tc in order to avoid incurring a dependency on a stage2 compiler today. Removing them would force me to drop support for stage1-only platforms offered by some linux distributions. If you're going to drop support for it, please consider offering me some horrible back door to get at the functionality that I can't currently replace by other means. -Edward -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomberek at gmail.com Wed Nov 11 19:53:25 2015 From: tomberek at gmail.com (Thomas Bereknyei) Date: Wed, 11 Nov 2015 14:53:25 -0500 Subject: Pre-Proposal: Introspective Template Haskell In-Reply-To: References: <792B5E26-FE61-4FC3-9A45-4948DBED1B4C@cis.upenn.edu> <1447263963.2461981.436253921.5899CBC1@webmail.messagingengine.com> Message-ID: If I understand this correctly it would also subsume haskell-src-exts. If so I would definitely support this. On Nov 11, 2015 2:21 PM, "Edward Kmett" wrote: > In practice I find that almost every piece of template-haskell code I've > written gets broken by something every other release of GHC, so it hasn't > exactly been a shining beacon of backwards compatibility thus far. > > Invariably it is always missing _something_ that I need, and anything that > ties it to a more canonical form like this would be a very good thing. > > I'd strongly support this move. > > A sample just from my current working directory: > > haskell> grep -r MIN_VERSION_template_haskell */src > > bifunctors/src/Data/Bifunctor/TH/Internal.hs:#if > MIN_VERSION_template_haskell(2,10,0) > > bifunctors/src/Data/Bifunctor/TH/Internal.hs:#if > MIN_VERSION_template_haskell(2,7,0) > > bifunctors/src/Data/Bifunctor/TH/Internal.hs:#if > MIN_VERSION_template_haskell(2,10,0) > > bifunctors/src/Data/Bifunctor/TH/Internal.hs:#if > MIN_VERSION_template_haskell(2,8,0) > > bifunctors/src/Data/Bifunctor/TH/Internal.hs:#if > MIN_VERSION_template_haskell(2,8,0) > > bifunctors/src/Data/Bifunctor/TH/Internal.hs:#if > MIN_VERSION_template_haskell(2,8,0) > > bifunctors/src/Data/Bifunctor/TH.hs:#ifndef MIN_VERSION_template_haskell > > bifunctors/src/Data/Bifunctor/TH.hs:#if __GLASGOW_HASKELL__ < 710 && > MIN_VERSION_template_haskell(2,8,0) > > bifunctors/src/Data/Bifunctor/TH.hs:#if MIN_VERSION_template_haskell(2,7,0) > > bifunctors/src/Data/Bifunctor/TH.hs:#if MIN_VERSION_template_haskell(2,7,0) > > bifunctors/src/Data/Bifunctor/TH.hs:#if MIN_VERSION_template_haskell(2,7,0) > > bifunctors/src/Data/Bifunctor/TH.hs:#if MIN_VERSION_template_haskell(2,7,0) > > bifunctors/src/Data/Bifunctor/TH.hs:#if MIN_VERSION_template_haskell(2,7,0) > > bifunctors/src/Data/Bifunctor/TH.hs:# if __GLASGOW_HASKELL__ >= 710 || > !(MIN_VERSION_template_haskell(2,8,0)) > > bifunctors/src/Data/Bifunctor/TH.hs:#if MIN_VERSION_template_haskell(2,7,0) > > free/src/Control/Monad/Free/TH.hs:#if MIN_VERSION_template_haskell(2,10,0) > > lens/src/Control/Lens/Internal/FieldTH.hs:#if > MIN_VERSION_template_haskell(2,8,0) > > lens/src/Control/Lens/Internal/TH.hs:#ifndef MIN_VERSION_template_haskell > > lens/src/Control/Lens/Internal/TH.hs:#define > MIN_VERSION_template_haskell(x,y,z) (defined(__GLASGOW_HASKELL__) && > __GLASGOW_HASKELL__ >= 706) > > lens/src/Control/Lens/Internal/TH.hs:#if > MIN_VERSION_template_haskell(2,9,0) > > lens/src/Control/Lens/Plated.hs:#if !(MIN_VERSION_template_haskell(2,8,0)) > > lens/src/Control/Lens/TH.hs:#ifndef MIN_VERSION_template_haskell > > lens/src/Control/Lens/TH.hs:#define MIN_VERSION_template_haskell(x,y,z) > (defined(__GLASGOW_HASKELL__) && __GLASGOW_HASKELL__ >= 706) > > lens/src/Control/Lens/TH.hs:#if !(MIN_VERSION_template_haskell(2,7,0)) > > lens/src/Control/Lens/TH.hs:#if MIN_VERSION_template_haskell(2,10,0) > > lens/src/Control/Lens/TH.hs:#if !(MIN_VERSION_template_haskell(2,7,0)) > > lens/src/Language/Haskell/TH/Lens.hs:#ifndef MIN_VERSION_template_haskell > > lens/src/Language/Haskell/TH/Lens.hs:#define > MIN_VERSION_template_haskell(x,y,z) 1 > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,9,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,8,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,9,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,10,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,10,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,8,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,9,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,10,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,9,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,8,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,8,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,10,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,8,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,10,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,8,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,8,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > !MIN_VERSION_template_haskell(2,10,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,9,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,8,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > !MIN_VERSION_template_haskell(2,10,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > !MIN_VERSION_template_haskell(2,10,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,8,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,8,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,8,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,9,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,10,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,10,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,8,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,8,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,9,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,10,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,9,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,9,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,8,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,8,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,10,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,8,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,8,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,10,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,8,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,8,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > !MIN_VERSION_template_haskell(2,10,0) > > lens/src/Language/Haskell/TH/Lens.hs:#if > MIN_VERSION_template_haskell(2,9,0) > > linear/src/Linear/V.hs:#ifdef MIN_VERSION_template_haskell > > linear/src/Linear/V.hs:#if !(MIN_VERSION_reflection(1,3,0)) && > defined(MIN_VERSION_template_haskell) > > linear/src/Linear/V.hs:#if !(MIN_VERSION_reflection(1,3,0)) && > defined(MIN_VERSION_template_haskell) > > nats/src/Numeric/Natural.hs:#if defined(MIN_VERSION_hashable) || > defined(MIN_VERSION_template_haskell) > > nats/src/Numeric/Natural.hs:#ifdef MIN_VERSION_template_haskell > > nats/src/Numeric/Natural.hs:#ifdef MIN_VERSION_template_haskell > > tables/src/Data/Table.hs:#if MIN_VERSION_template_haskell(2,10,0) > > tables/src/Data/Table.hs:#if MIN_VERSION_template_haskell(2,9,0) > > tagged/src/Data/Proxy/TH.hs:#if MIN_VERSION_template_haskell(2,8,0) > > tagged/src/Data/Proxy/TH.hs:#if MIN_VERSION_template_haskell(2,8,0) > > tagged/src/Data/Proxy/TH.hs:#if MIN_VERSION_template_haskell(2,8,0) > > tagged/src/Data/Proxy/TH.hs:#if MIN_VERSION_template_haskell(2,8,0) > > On Wed, Nov 11, 2015 at 12:46 PM, Eric Seidel wrote: > >> I think backwards-compatibility is still a potential issue, not because >> the pattern/type synonym layer seems implausible, but because I suspect >> people will begin to sidestep the compatibility layer and just use the >> GHC API (I certainly would). GHC is not shy about breaking >> backwards-compatibility between major releases, so it seems possible >> that this could extend to breaking TH. Missing features is not nearly as >> bad as breaking most clients of TH. >> >> But perhaps this isn't a very likely scenario. TH mostly exports >> datatypes for haskell syntax, smart constructors, and a few functions >> for looking up metadata. I doubt these pieces of GHC change very often, >> and when they do it's probably an extension rather than a breaking >> change. Someone with more historical knowledge of GHC could comment :) >> >> All in all, I like this idea a lot! >> >> Eric >> >> On Wed, Nov 11, 2015, at 08:26, Richard Eisenberg wrote: >> > Hi devs, >> > >> > There's a bunch of open tickets around Template Haskell. A great many of >> > them are attempts to make TH more like what's already in GHC. Of course, >> > when someone improves GHC, then TH also has to be updated. But this >> > doesn't always happen, leading to several of these tickets. >> > >> > I believe I have a solution to the problem: just eliminate Template >> > Haskell and provide direct access to GHC's internal structures. The idea >> > (still very sketchy; hence pre-proposal) is like this (numbered for easy >> > reference, but no order is implied): >> > >> > 1. TH quotes would remain. DsMeta would desugar quotes into Core code >> > that produces HsExprs. For example, [| 1 |] would have type (Q (LHsExpr >> > Name)). (Or perhaps (Q (LHsExpr RdrName)) if that works out better for >> > clients.) >> > >> > 2. TH splices would remain, working much as they do now. The expression >> > inside, say, an expression splice would have type (Q exp) where we can >> > satisfy the constraint (SpliceExpr exp). There would be instances for >> > (SpliceExpr (LHsExpr Name)) and (SpliceExpr (LHsExpr RdrName)) as well >> as >> > the non-located variants. Generalizing the type of expressions here >> > allows users not to worry about un-renaming when roundtripping between >> > quotes and splices. >> > >> > 3. Reification would remain, using an Info structure much like we have >> > now. Would we expose the real GHC TyCons as the result of reification? >> Or >> > is it better to give the users HsDecls? This would need to be fleshed >> > out. >> > >> > 4. Lifting would remain, doing the obvious thing. >> > >> > 5. The template-haskell package could even remain, as a >> > backward-compatibility shim. It would declare gobs of pattern synonyms >> > and type synonyms to wrap the new underlying interface. This re-imagined >> > template-haskell package would not need to be a boot library, and could >> > be upgraded separately from GHC. We could even maintain multiple >> versions >> > of the library so that TH clients wouldn't have to change their code >> when >> > GHC upgrades. Perhaps someday we could think about deprecating, if >> that's >> > the way the wind blows. >> > >> > So, the end result is a completely re-engineered TH, but I believe we >> > could keep full backward compatibility. (I have not considered Typed TH >> > in any depth yet. But my hope is that it's not too different from the >> > above.) And, we're left with a significantly lower maintenance burden, >> > especially if we eliminate template-haskell someday. >> > >> > And, tantalizingly, the flexibility in splices might allow us to splice >> > in *Core* code someday. Perhaps we could also reify Core code. Then >> > clients could write their own custom, domain-aware optimizations. Like >> > RULES on steroids. But that's all for the next phase. (Giving due >> credit, >> > this last bit is inspired by work David Christiansen is doing in Idris.) >> > >> > What's wrong with this idea? I feel like *something* has to be more >> > complicated than I've made it seem! >> > >> > Richard >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Wed Nov 11 19:55:56 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Wed, 11 Nov 2015 21:55:56 +0200 Subject: Pre-Proposal: Introspective Template Haskell In-Reply-To: References: <792B5E26-FE61-4FC3-9A45-4948DBED1B4C@cis.upenn.edu> <1447263963.2461981.436253921.5899CBC1@webmail.messagingengine.com> Message-ID: Well, as of 7.10.2 the GHC AST no longer has bottoms in it, so it can already be used quite easily On Wed, Nov 11, 2015 at 9:53 PM, Thomas Bereknyei wrote: > If I understand this correctly it would also subsume haskell-src-exts. If > so I would definitely support this. > On Nov 11, 2015 2:21 PM, "Edward Kmett" wrote: > >> In practice I find that almost every piece of template-haskell code I've >> written gets broken by something every other release of GHC, so it hasn't >> exactly been a shining beacon of backwards compatibility thus far. >> >> Invariably it is always missing _something_ that I need, and anything >> that ties it to a more canonical form like this would be a very good thing. >> >> I'd strongly support this move. >> >> A sample just from my current working directory: >> >> haskell> grep -r MIN_VERSION_template_haskell */src >> >> bifunctors/src/Data/Bifunctor/TH/Internal.hs:#if >> MIN_VERSION_template_haskell(2,10,0) >> >> bifunctors/src/Data/Bifunctor/TH/Internal.hs:#if >> MIN_VERSION_template_haskell(2,7,0) >> >> bifunctors/src/Data/Bifunctor/TH/Internal.hs:#if >> MIN_VERSION_template_haskell(2,10,0) >> >> bifunctors/src/Data/Bifunctor/TH/Internal.hs:#if >> MIN_VERSION_template_haskell(2,8,0) >> >> bifunctors/src/Data/Bifunctor/TH/Internal.hs:#if >> MIN_VERSION_template_haskell(2,8,0) >> >> bifunctors/src/Data/Bifunctor/TH/Internal.hs:#if >> MIN_VERSION_template_haskell(2,8,0) >> >> bifunctors/src/Data/Bifunctor/TH.hs:#ifndef MIN_VERSION_template_haskell >> >> bifunctors/src/Data/Bifunctor/TH.hs:#if __GLASGOW_HASKELL__ < 710 && >> MIN_VERSION_template_haskell(2,8,0) >> >> bifunctors/src/Data/Bifunctor/TH.hs:#if >> MIN_VERSION_template_haskell(2,7,0) >> >> bifunctors/src/Data/Bifunctor/TH.hs:#if >> MIN_VERSION_template_haskell(2,7,0) >> >> bifunctors/src/Data/Bifunctor/TH.hs:#if >> MIN_VERSION_template_haskell(2,7,0) >> >> bifunctors/src/Data/Bifunctor/TH.hs:#if >> MIN_VERSION_template_haskell(2,7,0) >> >> bifunctors/src/Data/Bifunctor/TH.hs:#if >> MIN_VERSION_template_haskell(2,7,0) >> >> bifunctors/src/Data/Bifunctor/TH.hs:# if __GLASGOW_HASKELL__ >= 710 || >> !(MIN_VERSION_template_haskell(2,8,0)) >> >> bifunctors/src/Data/Bifunctor/TH.hs:#if >> MIN_VERSION_template_haskell(2,7,0) >> >> free/src/Control/Monad/Free/TH.hs:#if MIN_VERSION_template_haskell(2,10,0) >> >> lens/src/Control/Lens/Internal/FieldTH.hs:#if >> MIN_VERSION_template_haskell(2,8,0) >> >> lens/src/Control/Lens/Internal/TH.hs:#ifndef MIN_VERSION_template_haskell >> >> lens/src/Control/Lens/Internal/TH.hs:#define >> MIN_VERSION_template_haskell(x,y,z) (defined(__GLASGOW_HASKELL__) && >> __GLASGOW_HASKELL__ >= 706) >> >> lens/src/Control/Lens/Internal/TH.hs:#if >> MIN_VERSION_template_haskell(2,9,0) >> >> lens/src/Control/Lens/Plated.hs:#if !(MIN_VERSION_template_haskell(2,8,0)) >> >> lens/src/Control/Lens/TH.hs:#ifndef MIN_VERSION_template_haskell >> >> lens/src/Control/Lens/TH.hs:#define MIN_VERSION_template_haskell(x,y,z) >> (defined(__GLASGOW_HASKELL__) && __GLASGOW_HASKELL__ >= 706) >> >> lens/src/Control/Lens/TH.hs:#if !(MIN_VERSION_template_haskell(2,7,0)) >> >> lens/src/Control/Lens/TH.hs:#if MIN_VERSION_template_haskell(2,10,0) >> >> lens/src/Control/Lens/TH.hs:#if !(MIN_VERSION_template_haskell(2,7,0)) >> >> lens/src/Language/Haskell/TH/Lens.hs:#ifndef MIN_VERSION_template_haskell >> >> lens/src/Language/Haskell/TH/Lens.hs:#define >> MIN_VERSION_template_haskell(x,y,z) 1 >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,9,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,8,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,9,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,10,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,10,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,8,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,9,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,10,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,9,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,8,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,8,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,10,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,8,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,10,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,8,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,8,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> !MIN_VERSION_template_haskell(2,10,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,9,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,8,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> !MIN_VERSION_template_haskell(2,10,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> !MIN_VERSION_template_haskell(2,10,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,8,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,8,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,8,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,9,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,10,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,10,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,8,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,8,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,9,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,10,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,9,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,9,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,8,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,8,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,10,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,8,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,8,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,10,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,8,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,8,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> !MIN_VERSION_template_haskell(2,10,0) >> >> lens/src/Language/Haskell/TH/Lens.hs:#if >> MIN_VERSION_template_haskell(2,9,0) >> >> linear/src/Linear/V.hs:#ifdef MIN_VERSION_template_haskell >> >> linear/src/Linear/V.hs:#if !(MIN_VERSION_reflection(1,3,0)) && >> defined(MIN_VERSION_template_haskell) >> >> linear/src/Linear/V.hs:#if !(MIN_VERSION_reflection(1,3,0)) && >> defined(MIN_VERSION_template_haskell) >> >> nats/src/Numeric/Natural.hs:#if defined(MIN_VERSION_hashable) || >> defined(MIN_VERSION_template_haskell) >> >> nats/src/Numeric/Natural.hs:#ifdef MIN_VERSION_template_haskell >> >> nats/src/Numeric/Natural.hs:#ifdef MIN_VERSION_template_haskell >> >> tables/src/Data/Table.hs:#if MIN_VERSION_template_haskell(2,10,0) >> >> tables/src/Data/Table.hs:#if MIN_VERSION_template_haskell(2,9,0) >> >> tagged/src/Data/Proxy/TH.hs:#if MIN_VERSION_template_haskell(2,8,0) >> >> tagged/src/Data/Proxy/TH.hs:#if MIN_VERSION_template_haskell(2,8,0) >> >> tagged/src/Data/Proxy/TH.hs:#if MIN_VERSION_template_haskell(2,8,0) >> >> tagged/src/Data/Proxy/TH.hs:#if MIN_VERSION_template_haskell(2,8,0) >> >> On Wed, Nov 11, 2015 at 12:46 PM, Eric Seidel wrote: >> >>> I think backwards-compatibility is still a potential issue, not because >>> the pattern/type synonym layer seems implausible, but because I suspect >>> people will begin to sidestep the compatibility layer and just use the >>> GHC API (I certainly would). GHC is not shy about breaking >>> backwards-compatibility between major releases, so it seems possible >>> that this could extend to breaking TH. Missing features is not nearly as >>> bad as breaking most clients of TH. >>> >>> But perhaps this isn't a very likely scenario. TH mostly exports >>> datatypes for haskell syntax, smart constructors, and a few functions >>> for looking up metadata. I doubt these pieces of GHC change very often, >>> and when they do it's probably an extension rather than a breaking >>> change. Someone with more historical knowledge of GHC could comment :) >>> >>> All in all, I like this idea a lot! >>> >>> Eric >>> >>> On Wed, Nov 11, 2015, at 08:26, Richard Eisenberg wrote: >>> > Hi devs, >>> > >>> > There's a bunch of open tickets around Template Haskell. A great many >>> of >>> > them are attempts to make TH more like what's already in GHC. Of >>> course, >>> > when someone improves GHC, then TH also has to be updated. But this >>> > doesn't always happen, leading to several of these tickets. >>> > >>> > I believe I have a solution to the problem: just eliminate Template >>> > Haskell and provide direct access to GHC's internal structures. The >>> idea >>> > (still very sketchy; hence pre-proposal) is like this (numbered for >>> easy >>> > reference, but no order is implied): >>> > >>> > 1. TH quotes would remain. DsMeta would desugar quotes into Core code >>> > that produces HsExprs. For example, [| 1 |] would have type (Q (LHsExpr >>> > Name)). (Or perhaps (Q (LHsExpr RdrName)) if that works out better for >>> > clients.) >>> > >>> > 2. TH splices would remain, working much as they do now. The expression >>> > inside, say, an expression splice would have type (Q exp) where we can >>> > satisfy the constraint (SpliceExpr exp). There would be instances for >>> > (SpliceExpr (LHsExpr Name)) and (SpliceExpr (LHsExpr RdrName)) as well >>> as >>> > the non-located variants. Generalizing the type of expressions here >>> > allows users not to worry about un-renaming when roundtripping between >>> > quotes and splices. >>> > >>> > 3. Reification would remain, using an Info structure much like we have >>> > now. Would we expose the real GHC TyCons as the result of reification? >>> Or >>> > is it better to give the users HsDecls? This would need to be fleshed >>> > out. >>> > >>> > 4. Lifting would remain, doing the obvious thing. >>> > >>> > 5. The template-haskell package could even remain, as a >>> > backward-compatibility shim. It would declare gobs of pattern synonyms >>> > and type synonyms to wrap the new underlying interface. This >>> re-imagined >>> > template-haskell package would not need to be a boot library, and could >>> > be upgraded separately from GHC. We could even maintain multiple >>> versions >>> > of the library so that TH clients wouldn't have to change their code >>> when >>> > GHC upgrades. Perhaps someday we could think about deprecating, if >>> that's >>> > the way the wind blows. >>> > >>> > So, the end result is a completely re-engineered TH, but I believe we >>> > could keep full backward compatibility. (I have not considered Typed TH >>> > in any depth yet. But my hope is that it's not too different from the >>> > above.) And, we're left with a significantly lower maintenance burden, >>> > especially if we eliminate template-haskell someday. >>> > >>> > And, tantalizingly, the flexibility in splices might allow us to splice >>> > in *Core* code someday. Perhaps we could also reify Core code. Then >>> > clients could write their own custom, domain-aware optimizations. Like >>> > RULES on steroids. But that's all for the next phase. (Giving due >>> credit, >>> > this last bit is inspired by work David Christiansen is doing in >>> Idris.) >>> > >>> > What's wrong with this idea? I feel like *something* has to be more >>> > complicated than I've made it seem! >>> > >>> > Richard >>> > _______________________________________________ >>> > ghc-devs mailing list >>> > ghc-devs at haskell.org >>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Wed Nov 11 20:03:45 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 11 Nov 2015 15:03:45 -0500 Subject: Pre-Proposal: Introspective Template Haskell In-Reply-To: References: <792B5E26-FE61-4FC3-9A45-4948DBED1B4C@cis.upenn.edu> <1447263963.2461981.436253921.5899CBC1@webmail.messagingengine.com> <8B283903-F125-4654-B7CE-91889314ADDE@cis.upenn.edu> Message-ID: <8735E6E2-0B79-46D2-819A-0E5B16818207@cis.upenn.edu> On Nov 11, 2015, at 2:25 PM, Edward Kmett wrote: > > As a data point, in a couple of packages I wind up forced into using mkNameG_v and mkNameG_tc in order to avoid incurring a dependency on a stage2 compiler today. Removing them would force me to drop support for stage1-only platforms offered by some linux distributions. > > If you're going to drop support for it, please consider offering me some horrible back door to get at the functionality that I can't currently replace by other means. > I've had to use these functions, too, mostly because TH didn't export the functionality I needed. But this wouldn't be problematic in the new scenario: just depend on the ghc package instead of template-haskell. Then you can do whatever you like. :) > -Edward From eir at cis.upenn.edu Wed Nov 11 20:05:52 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 11 Nov 2015 15:05:52 -0500 Subject: Pre-Proposal: Introspective Template Haskell In-Reply-To: <792B5E26-FE61-4FC3-9A45-4948DBED1B4C@cis.upenn.edu> References: <792B5E26-FE61-4FC3-9A45-4948DBED1B4C@cis.upenn.edu> Message-ID: <47165C93-6D10-497A-9882-E000A7C07F01@cis.upenn.edu> I've gotten some encouraging feedback here. But I'm worried about the technicalities. I *think* this would all work out, but I'm a little worried about weird recursive dependencies and such. For example, is there something fundamentally important about all the names in THNames being in a package that is not `ghc`? Any thoughts there? Richard On Nov 11, 2015, at 11:26 AM, Richard Eisenberg wrote: > Hi devs, > > There's a bunch of open tickets around Template Haskell. A great many of them are attempts to make TH more like what's already in GHC. Of course, when someone improves GHC, then TH also has to be updated. But this doesn't always happen, leading to several of these tickets. > > I believe I have a solution to the problem: just eliminate Template Haskell and provide direct access to GHC's internal structures. The idea (still very sketchy; hence pre-proposal) is like this (numbered for easy reference, but no order is implied): > > 1. TH quotes would remain. DsMeta would desugar quotes into Core code that produces HsExprs. For example, [| 1 |] would have type (Q (LHsExpr Name)). (Or perhaps (Q (LHsExpr RdrName)) if that works out better for clients.) > > 2. TH splices would remain, working much as they do now. The expression inside, say, an expression splice would have type (Q exp) where we can satisfy the constraint (SpliceExpr exp). There would be instances for (SpliceExpr (LHsExpr Name)) and (SpliceExpr (LHsExpr RdrName)) as well as the non-located variants. Generalizing the type of expressions here allows users not to worry about un-renaming when roundtripping between quotes and splices. > > 3. Reification would remain, using an Info structure much like we have now. Would we expose the real GHC TyCons as the result of reification? Or is it better to give the users HsDecls? This would need to be fleshed out. > > 4. Lifting would remain, doing the obvious thing. > > 5. The template-haskell package could even remain, as a backward-compatibility shim. It would declare gobs of pattern synonyms and type synonyms to wrap the new underlying interface. This re-imagined template-haskell package would not need to be a boot library, and could be upgraded separately from GHC. We could even maintain multiple versions of the library so that TH clients wouldn't have to change their code when GHC upgrades. Perhaps someday we could think about deprecating, if that's the way the wind blows. > > So, the end result is a completely re-engineered TH, but I believe we could keep full backward compatibility. (I have not considered Typed TH in any depth yet. But my hope is that it's not too different from the above.) And, we're left with a significantly lower maintenance burden, especially if we eliminate template-haskell someday. > > And, tantalizingly, the flexibility in splices might allow us to splice in *Core* code someday. Perhaps we could also reify Core code. Then clients could write their own custom, domain-aware optimizations. Like RULES on steroids. But that's all for the next phase. (Giving due credit, this last bit is inspired by work David Christiansen is doing in Idris.) > > What's wrong with this idea? I feel like *something* has to be more complicated than I've made it seem! > > Richard > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ekmett at gmail.com Wed Nov 11 20:06:31 2015 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 11 Nov 2015 15:06:31 -0500 Subject: Pre-Proposal: Introspective Template Haskell In-Reply-To: <8735E6E2-0B79-46D2-819A-0E5B16818207@cis.upenn.edu> References: <792B5E26-FE61-4FC3-9A45-4948DBED1B4C@cis.upenn.edu> <1447263963.2461981.436253921.5899CBC1@webmail.messagingengine.com> <8B283903-F125-4654-B7CE-91889314ADDE@cis.upenn.edu> <8735E6E2-0B79-46D2-819A-0E5B16818207@cis.upenn.edu> Message-ID: <55B6BA7B-E1ED-4DD4-999F-7CD2CB645644@gmail.com> That would be a sufficient "horrible backdoor" for me. :) -Edward > On Nov 11, 2015, at 3:03 PM, Richard Eisenberg wrote: > > >> On Nov 11, 2015, at 2:25 PM, Edward Kmett wrote: >> >> As a data point, in a couple of packages I wind up forced into using mkNameG_v and mkNameG_tc in order to avoid incurring a dependency on a stage2 compiler today. Removing them would force me to drop support for stage1-only platforms offered by some linux distributions. >> >> If you're going to drop support for it, please consider offering me some horrible back door to get at the functionality that I can't currently replace by other means. > > I've had to use these functions, too, mostly because TH didn't export the functionality I needed. But this wouldn't be problematic in the new scenario: just depend on the ghc package instead of template-haskell. Then you can do whatever you like. :) > >> -Edward > From marlowsd at gmail.com Thu Nov 12 11:24:53 2015 From: marlowsd at gmail.com (Simon Marlow) Date: Thu, 12 Nov 2015 11:24:53 +0000 Subject: Questions on the RTS C API regarding threads and tasks In-Reply-To: References: Message-ID: <56447705.5090108@gmail.com> On 04/11/2015 19:12, Nicola Gigante wrote: > I?m new on this list, congratulations to everyone for > the great work that you?re doing on GHC! > > I apologize if this is not the right list where to ask the following > questions. Please point me to the correct list or IRC channel > otherwise. > > I?m part of a small group of people who is going to work > on a project that seems to need low-level handling of haskell > threads. > > I?ve started delving into the ghc runtime API to understand > if everything we need is exposed to the world or if we > have to modify the runtime itself (which I would avoid if possible). > > I have a few questions about the functions that the runtime > exports to the C world regarding the manipulation of tasks: > > - Fundamentally, is there a way for a C function called by a foreign call > to suspend the haskell thread that called it, to be resumed later > when appropriate? I see that the runtime has a concept of > ?blocking queue?, but I also see that the functions that work on > blocking queues are not exported. I can manage a queue of TSOs myself, > but then I need a way to put in sleep the task indefinitely up to a wake signal. > In other words, can I sleep and awake haskell threads from a C function > called by a foreign call? When you call a C function from Haskell, the Haskell thread that called it *is* suspended, until the C call returns. So I'm not sure exactly what it is you want to do - maybe you could describe in more detail? Cheers, Simon > - I see the ?suspendThread? and ?resumeThread? functions exist in include/rts/Threads.h > Are these the functions that I need for the point above? My main concern is > that the comments in the source code for suspendThread say that these > functions are used in case of a CCall, and put the thread in a specific queue, > so they seems to have more specific role than what the name might suggest. > > - Also, I?m unable to find what a StgRegTable is > (which is taken as argument by suspendThread). > > > Thank you in advance for your help, > > Greetings, > Nicola > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From thomasmiedema at gmail.com Thu Nov 12 11:59:13 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Thu, 12 Nov 2015 12:59:13 +0100 Subject: one weird trick to get all your types In-Reply-To: <47100068-0AB1-4482-A894-988D0F20F8E6@cis.upenn.edu> References: <47100068-0AB1-4482-A894-988D0F20F8E6@cis.upenn.edu> Message-ID: I'd put it here: https://ghc.haskell.org/trac/ghc/wiki/Debugging/Compiler How about loading GHCi in GHCi :) On Wed, Nov 11, 2015 at 7:03 PM, Richard Eisenberg wrote: > Hi devs, > > I spent some of my time at Hac Phi this past weekend teaching a few people > the ropes about GHC hacking. One innocently asked if it's possible to load > GHC into GHCi. I shuddered at the thought. But, actually, you can get quite > close to this ideal: > > > ghc-stage2 --interactive > GHCi, version 7.11.20151104: http://www.haskell.org/ghc/ :? for help > Prelude> :set -package ghc -- THIS IS THE KEY LINE > package flags have changed, resetting and loading new packages... > Prelude> import TcMType > Prelude TcMType> :t newEvVar > newEvVar > :: forall gbl lcl. > TcType.TcPredType -> TcRnTypes.TcRnIf gbl lcl Var.EvVar > Prelude TcMType> > > Pretty cool, huh? This improves my life. Hopefully it improves yours, too. > > Richard > > PS: Can anyone recommend a place on the wiki where I should put this? > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicola.gigante at gmail.com Thu Nov 12 13:15:45 2015 From: nicola.gigante at gmail.com (Nicola Gigante) Date: Thu, 12 Nov 2015 14:15:45 +0100 Subject: Questions on the RTS C API regarding threads and tasks In-Reply-To: <56447705.5090108@gmail.com> References: <56447705.5090108@gmail.com> Message-ID: <7D1E811C-DF9D-4399-82F7-33FF8B64FC28@gmail.com> > Il giorno 12 nov 2015, alle ore 12:24, Simon Marlow ha scritto: > > When you call a C function from Haskell, the Haskell thread that called it *is* suspended, until the C call returns. So I'm not sure exactly what it is you want to do - maybe you could describe in more detail? > Yes, the haskell thread is suspended but it will be resumed when the C code returns. If you see the haskell + C code as a single computation, nothing gets suspended, you just switch environment and language. I?m sorry for the vagueness in my question. At the time we had a blind review of a paper pending so I couldn?t give more details because some reviewer could be a member of mailing lists like this. Now I can explain at a little bit higher level what I was talking about. There are a few places in the haskell concurrency libraries where haskell threads gets suspended until something happens. MVars suspend on reads, STM transactions block after a retry to wait for the change of some TVar, and so on? Each case is internally treated explicitly by the runtime. By looking at the implementation I see that there is a concept of ?Blocking Queue?, and each TSO can be added to one of these queues. Each TSO also has a why_blocked flag that tells why it is blocked, with all these cases explicitly enumerated (e.g. BlockedOnCCall and BlockedOnSTM). We are implementing some kind of concurrency primitive, which is similar in spirit to the STM but with a number of differences, and we?d need access to a primitive to block the thread exactly as it happens with the readMVar function or the retry action of the STM: simply put a thread to sleep until something happens. We are implementing a concurrency primitive, so everything has to be fast and low-overhead. As Edward pointed out, it sounds like premature optimization to a priori exclude the possibility to implement our primitive on top of MVars. For this reason, that is the way that we are exploring in the last days. Nevertheless, it does seem strange to us that the GHC runtime doesn?t expose some generic way to do something that is needed by so many subsystems. What do you think about this? Are we missing something? Thank you for your help, > Cheers, > Simon Greetings, Nicola -------------- next part -------------- An HTML attachment was scrubbed... URL: From spitzenb at fim.uni-passau.de Thu Nov 12 16:25:15 2015 From: spitzenb at fim.uni-passau.de (David Spitzenberg) Date: Thu, 12 Nov 2015 17:25:15 +0100 Subject: Questions concerning the LLVM backend - i.e. 'proc point splitting' Message-ID: <5644BD6B.8060105@fim.uni-passau.de> Hello everybody, I've got some questions concerning the LLVM backend - i.e. the pass 'proc point splitting' in the cmm-pipeline. I'm new to this list as well as to computer science in general - at least in some sense. Being a third semester student of computer science, I'm not quite sure, whether I'm addressing the right list with this mail. Feel free to correct me, if not. I'm doing numerical stencil calculations which heavily depend on nested loops expressed as tail-recursive functions nested one in another. When compiling a module, GHC seems capable of emitting pretty good cmm-code. At least as long as the loop bodies do not contain any call to non-inlineable functions. In most cases 'loopification' fires and transforms tail-recursive calls into loops. When calling into non-inlineable functions, 'proc point splitting' is performed. This splits the loops into several mutually-recursive functions therefore significantly decreasing the possibilities of 'opt' in optimizing the code later on. This leads to pretty bad performance of the whole calculation. To avoid the presence of proc points within a loop body - and by doing so the splitting of the body - I currently try to avoid calls into non-inlineable functions by merging the nested recursive functions into one giant tail-recursive function. This works, as long as everything not defined in the module being compiled can be inlined. Apparently, this is not a long term solution. My questions: - The reason to perform 'proc point splitting' is, that LLVM IR lacks of the possibility to call into an arbitrary basic block of a function body from outside the function itself. Is this understanding right? - Are there any other possibilities to avoid 'proc point splitting' when using LLVM as a backend? - I recently read the article on an improved LLVM backend in the GHC wiki (https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend), but couldn't find any suggestions on the topic of 'proc point splitting'. Are there any plans to solve the problem either by teaching LLVM IR the lacking functionality or in any other way? I'd really like to contribute to GHC by working on this problem, but I'm not quite sure, if I'm capable of doing so. My background knowledge is still somewhat limited, but I'm working on it ;-) Thanks in advance for your help! Regards, David Spitzenberg PS.: Thanks to everyone for the great work you're doing on GHC! From mainland at apeiron.net Thu Nov 12 17:12:05 2015 From: mainland at apeiron.net (Geoffrey Mainland) Date: Thu, 12 Nov 2015 12:12:05 -0500 Subject: Pre-Proposal: Introspective Template Haskell In-Reply-To: <792B5E26-FE61-4FC3-9A45-4948DBED1B4C@cis.upenn.edu> References: <792B5E26-FE61-4FC3-9A45-4948DBED1B4C@cis.upenn.edu> Message-ID: <5644C865.3090404@apeiron.net> Hi Richard, Please correct me if I misunderstand, but in summary, you propose to change Template Haskell so that GHC's internal AST is produced directly, instead of the current route where there is an intermediate TH AST? Geoff On 11/11/2015 11:26 AM, Richard Eisenberg wrote: > Hi devs, > > There's a bunch of open tickets around Template Haskell. A great many of them are attempts to make TH more like what's already in GHC. Of course, when someone improves GHC, then TH also has to be updated. But this doesn't always happen, leading to several of these tickets. > > I believe I have a solution to the problem: just eliminate Template Haskell and provide direct access to GHC's internal structures. The idea (still very sketchy; hence pre-proposal) is like this (numbered for easy reference, but no order is implied): > > 1. TH quotes would remain. DsMeta would desugar quotes into Core code that produces HsExprs. For example, [| 1 |] would have type (Q (LHsExpr Name)). (Or perhaps (Q (LHsExpr RdrName)) if that works out better for clients.) > > 2. TH splices would remain, working much as they do now. The expression inside, say, an expression splice would have type (Q exp) where we can satisfy the constraint (SpliceExpr exp). There would be instances for (SpliceExpr (LHsExpr Name)) and (SpliceExpr (LHsExpr RdrName)) as well as the non-located variants. Generalizing the type of expressions here allows users not to worry about un-renaming when roundtripping between quotes and splices. > > 3. Reification would remain, using an Info structure much like we have now. Would we expose the real GHC TyCons as the result of reification? Or is it better to give the users HsDecls? This would need to be fleshed out. > > 4. Lifting would remain, doing the obvious thing. > > 5. The template-haskell package could even remain, as a backward-compatibility shim. It would declare gobs of pattern synonyms and type synonyms to wrap the new underlying interface. This re-imagined template-haskell package would not need to be a boot library, and could be upgraded separately from GHC. We could even maintain multiple versions of the library so that TH clients wouldn't have to change their code when GHC upgrades. Perhaps someday we could think about deprecating, if that's the way the wind blows. > > So, the end result is a completely re-engineered TH, but I believe we could keep full backward compatibility. (I have not considered Typed TH in any depth yet. But my hope is that it's not too different from the above.) And, we're left with a significantly lower maintenance burden, especially if we eliminate template-haskell someday. > > And, tantalizingly, the flexibility in splices might allow us to splice in *Core* code someday. Perhaps we could also reify Core code. Then clients could write their own custom, domain-aware optimizations. Like RULES on steroids. But that's all for the next phase. (Giving due credit, this last bit is inspired by work David Christiansen is doing in Idris.) > > What's wrong with this idea? I feel like *something* has to be more complicated than I've made it seem! > > Richard > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From eir at cis.upenn.edu Thu Nov 12 17:14:47 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 12 Nov 2015 12:14:47 -0500 Subject: Pre-Proposal: Introspective Template Haskell In-Reply-To: <5644C865.3090404@apeiron.net> References: <792B5E26-FE61-4FC3-9A45-4948DBED1B4C@cis.upenn.edu> <5644C865.3090404@apeiron.net> Message-ID: Yes, that's right. But with a compatibility shim, no longer tied into GHC, that could provide stability and/or a simpler interface. This compatibility shim would likely be called template-haskell. (I retract the idea of deprecating the package. But we could democratize its maintenance rather easily after this change.) Richard On Nov 12, 2015, at 12:12 PM, Geoffrey Mainland wrote: > Hi Richard, > > Please correct me if I misunderstand, but in summary, you propose to > change Template Haskell so that GHC's internal AST is produced directly, > instead of the current route where there is an intermediate TH AST? > > Geoff > > On 11/11/2015 11:26 AM, Richard Eisenberg wrote: >> Hi devs, >> >> There's a bunch of open tickets around Template Haskell. A great many of them are attempts to make TH more like what's already in GHC. Of course, when someone improves GHC, then TH also has to be updated. But this doesn't always happen, leading to several of these tickets. >> >> I believe I have a solution to the problem: just eliminate Template Haskell and provide direct access to GHC's internal structures. The idea (still very sketchy; hence pre-proposal) is like this (numbered for easy reference, but no order is implied): >> >> 1. TH quotes would remain. DsMeta would desugar quotes into Core code that produces HsExprs. For example, [| 1 |] would have type (Q (LHsExpr Name)). (Or perhaps (Q (LHsExpr RdrName)) if that works out better for clients.) >> >> 2. TH splices would remain, working much as they do now. The expression inside, say, an expression splice would have type (Q exp) where we can satisfy the constraint (SpliceExpr exp). There would be instances for (SpliceExpr (LHsExpr Name)) and (SpliceExpr (LHsExpr RdrName)) as well as the non-located variants. Generalizing the type of expressions here allows users not to worry about un-renaming when roundtripping between quotes and splices. >> >> 3. Reification would remain, using an Info structure much like we have now. Would we expose the real GHC TyCons as the result of reification? Or is it better to give the users HsDecls? This would need to be fleshed out. >> >> 4. Lifting would remain, doing the obvious thing. >> >> 5. The template-haskell package could even remain, as a backward-compatibility shim. It would declare gobs of pattern synonyms and type synonyms to wrap the new underlying interface. This re-imagined template-haskell package would not need to be a boot library, and could be upgraded separately from GHC. We could even maintain multiple versions of the library so that TH clients wouldn't have to change their code when GHC upgrades. Perhaps someday we could think about deprecating, if that's the way the wind blows. >> >> So, the end result is a completely re-engineered TH, but I believe we could keep full backward compatibility. (I have not considered Typed TH in any depth yet. But my hope is that it's not too different from the above.) And, we're left with a significantly lower maintenance burden, especially if we eliminate template-haskell someday. >> >> And, tantalizingly, the flexibility in splices might allow us to splice in *Core* code someday. Perhaps we could also reify Core code. Then clients could write their own custom, domain-aware optimizations. Like RULES on steroids. But that's all for the next phase. (Giving due credit, this last bit is inspired by work David Christiansen is doing in Idris.) >> >> What's wrong with this idea? I feel like *something* has to be more complicated than I've made it seem! >> >> Richard >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > From alan.zimm at gmail.com Thu Nov 12 19:31:16 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Thu, 12 Nov 2015 21:31:16 +0200 Subject: [GHC] #11018: ApiAnnotations: Add SourceText for unicode tokens In-Reply-To: <059.0876ec48a19bff24366602f44c0bcafc@haskell.org> References: <044.b2f994e490e36bcbf86a1f576ead0ae0@haskell.org> <059.0876ec48a19bff24366602f44c0bcafc@haskell.org> Message-ID: agree, as we discussed on IRC On Thu, Nov 12, 2015 at 9:30 PM, GHC wrote: > #11018: ApiAnnotations: Add SourceText for unicode tokens > -------------------------------------+------------------------------------- > Reporter: alanz | Owner: alanz > Type: bug | Status: new > Priority: normal | Milestone: 8.0.1 > Component: Compiler | Version: 7.10.2 > Resolution: | Keywords: > | ApiAnnotations > Operating System: Unknown/Multiple | Architecture: > | Unknown/Multiple > Type of failure: None/Unknown | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > -------------------------------------+------------------------------------- > > Comment (by mpickering): > > No. Go for it. > > For the purpose of this ticket, I will also add that I think adding a flag > `IsUnicodeSyntax` is better than adding `SourceText`. > > -- > Ticket URL: > GHC > The Glasgow Haskell Compiler > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Fri Nov 13 00:51:47 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 12 Nov 2015 16:51:47 -0800 Subject: On the record pattern synonyms patch Message-ID: <1447375513-sup-1888@sabre> Hello Matthew, I have a question about the record pattern synonyms patch which you landed in the last month (2a74a64e8329ab9e0c74bec47198cb492d25affb). In IfaceSyn, you made the following change: data IfaceIdDetails = IfVanillaId - | IfRecSelId IfaceTyCon Bool + | IfRecSelId (Either IfaceTyCon IfaceDecl) Bool | IfDFunId I don't understand why IfRecSelIds can now store IfaceDecls. Why aren't these declarations stored at the *top level* list of declarations in an interface file? If they are, you shouldn't be storing the entire IfaceDecl structure when serializing to disk. If they are not, I am afraid I don't understand this code. I also noticed that the commit message is quite long, and many of the comments I see are not replicated anywhere in the source. Is there any reason why they should not be written down as proper notes, with cross-references from the appropriate code? Thanks, Edward From gershomb at gmail.com Fri Nov 13 04:47:03 2015 From: gershomb at gmail.com (Gershom B) Date: Thu, 12 Nov 2015 23:47:03 -0500 Subject: Haskell Platform Plans Message-ID: Dear all, As you know, Mark has passed on the Haskell Platform maintainer hat to me. I wanted to give a heads-up on current plans to keep folks in the loop. This message has three sections, first the 7.10.3 release, next the 8.0 release, and finally some general musings on fiddly details and future plans. 1) 7.10.3 The 7.10.3 release candidates have been out for windows and unix for a bit. As I understand it there is still work underway on the mac build, but that will hopefully be coming shortly. The plan is to release a new platform roughly simultaneously. This platform will work essentially as in the past, for two reasons. First, because it is the last release in the 7.10 series and should be seen like the 7.10.3 compiler as just incorporating some necessary patches rather than any serious changes. Furthermore, the future plans underway rely on a few patches to cabal which have been merged, but are not yet in any existing cabal-install release. A few packages have received minor version bumps, as follows: PACKAGE 7.10.2-a latest ------------------------------------------- case-insensitive 1.2.0.4 1.2.0.5 fgl 5.5.2.0 5.5.2.3 GLUT 2.7.0.1 2.7.0.3 GLURaw 1.5.0.1 1.5.0.2 HUnit 1.2.5.2 1.3.0.0 OpenGL 2.12.0.1 2.13.1.0 OpenGLRaw 2.5.1.0 2.6.0.0 primitive 0.6 0.6.1.0 syb 0.5.1 0.6 scientific 0.3.3.8 0.3.4.2 StateVar 1.1.0.0 1.1.0.1 A few packages were held back due to dependency issues (notably zlib) and additionally, packages shipped with ghc were held back to the versions that will be shipped with 7.10.3. 2) 8.0 We also plan to ship a new platform concurrently with the ghc 8.0 that should be released early next year. That platform will implement some long-discussed and requested changes. First, the platform already ships with msys on windows. However, it does not do so in a way that lets you, as with minGHC, install the network library directly, or for that matter install directly other libraries that use build-type configure. This is because the msys binaries don't get placed into the path, by design. The new platform will ship with a newer cabal, incorporating a patch (pull request #2480) that uses the extra-prog-path setting for build-type: configure. This should allow network and other things reliant on build-type: configure to directly cabal install. The goal for the platform on windows will be that any packages binding to msys libraries _should_ be cabal installable without hassle. If you maintain a library that you think would be a good test-case for this, please drop a line so we can work together towards this goal. Second, the default platform will be _minimal_. That is to say that it will _only_ install into the global package database those packages that are directly shipped with ghc, and not any additional platform packages. "Blessed" platform packages will however still be shipped as a "default user cabal.config" file, so in a setting where users want to work unsandboxed, their versions of platform libs will remain pegged to those chosen by the platform, should they not choose to alter their settings. In a sandboxed setting, or in the presence of a local cabal.config generated by a freeze, those constraints will be disregarded. Furthermore, it is likely but not certain that the "nix-like cabal" or "no-reinstall cabal" will be available for the 8.0 release. If this is the case, users will be able to operate in an unsandboxed environment without conflicts, as multiple instances of the same version of a package, with different dependency choices, will be able to live side-by-side. Third, the platform will ship not only with cabal-install, but also with the stack tool, so that users can choose either workflow, depending on their project or preferences. A number of people have adopted the stack tool, and many beginners have reported success with it as well, so it will be good to provide that functionality out of the box with every platform install. Time and resources permitting we would also like to ship a platform version _with_ the platform libraries prebuilt and included, as that is also a use case that some people continue to like. However, this is a secondary priority, and contingent on us getting our build infrastructure into a good enough shape to make this not too much extra hassle. I'm excited about these changes, and confident we can get their in a timespan that matches the 8.0 release of ghc. 3) Generalities As I mentioned, it would be good to have a more uniform build infrastructure. Generally, I have put out some feelers and am working towards extending the ghc nightly buildbot infrastructure to both cover more platforms and also cover more tools -- not only ghc, but cabal, the platform, perhaps haddock, ghcjs, etc. This way we can get an economy of scale and many of our core tools will be able to all share regular automated builds across many platforms. If you like CI/buildbot systems and would like to help out with this project, please reach out. Also, once we've modernized and fixed up the core platform installer tech, it would be nice to move back to the process of making the platform a good set of blessed libraries -- taking more proposals for additions to it, looking to cull libraries that are no longer widely used, etc. As part of this I intend to move the haskell-platform list off our deprecated community.haskell.org infrastructure and onto mail.haskell.org with our other active lists. Finally, I'm happy to be maintainer of the platform through this period of change and transition, but at some future point, as things get sorted out and the release process becomes more standard and mechanical, I would very much like to pass this responsibility on. I have had some nibbles of offers, but if other people want to begin to get involved, please let me know and we can start to get small contributions from you so that you can become familiar with the various tech and systems involved. The Haskell ecosystem is a team effort, a collective project, and volunteer driven. In my modest experience hacking on the various systems involved (cabal, cabal-install, hackage, the platform build, etc.) some are a bit confusing, but I have always found helpful contributors willing to explain things and review patches, and to help think about and diagnose problems. And none of the code has been as confusing as things I've had to wade through for employment-related purposes :-). So when this stuff doesn't work as well as we'd like, we can investigate together, and then put our heads together and figure out how to improve it together. Furthermore, it can be very satisfying to do so, because the impact of those improvements makes itself widely felt. I look forward to more people joining in! Best, Gershom -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Fri Nov 13 09:39:10 2015 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Fri, 13 Nov 2015 09:39:10 +0000 Subject: On the record pattern synonyms patch In-Reply-To: <1447375513-sup-1888@sabre> References: <1447375513-sup-1888@sabre> Message-ID: Hi Edward, I don't understand what should and shouldn't be in interface files. I tried to make the least changes to get everything still to work. The change was because of the corresponding change to the datatype. https://github.com/ghc/ghc/commit/2a74a64e8329ab9e0c74bec47198cb492d25affb#diff-b59958324bac281f11d55f4263de7b0fL111 If you have a concrete suggestion about how this should be changed then please say and I will do it. With regards to the comments, it seems like the only relevant one for the long run is to do with mixing pattern synonym and record field selectors. This is also included in the source. Maybe it would be good to put the one about duplicate record fields somewhere as well, do you have a suggestion as to where might be appropriate? Matt On Fri, Nov 13, 2015 at 12:51 AM, Edward Z. Yang wrote: > Hello Matthew, > > I have a question about the record pattern synonyms patch > which you landed in the last month (2a74a64e8329ab9e0c74bec47198cb492d25affb). > > In IfaceSyn, you made the following change: > > data IfaceIdDetails > = IfVanillaId > - | IfRecSelId IfaceTyCon Bool > + | IfRecSelId (Either IfaceTyCon IfaceDecl) Bool > | IfDFunId > > I don't understand why IfRecSelIds can now store IfaceDecls. Why aren't > these declarations stored at the *top level* list of declarations in an > interface file? If they are, you shouldn't be storing the entire > IfaceDecl structure when serializing to disk. If they are not, I > am afraid I don't understand this code. > > I also noticed that the commit message is quite long, and many of the > comments I see are not replicated anywhere in the source. Is there any > reason why they should not be written down as proper notes, with > cross-references from the appropriate code? > > Thanks, > Edward From jan.stolarek at p.lodz.pl Fri Nov 13 15:01:35 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Fri, 13 Nov 2015 16:01:35 +0100 Subject: too many lines too long In-Reply-To: References: <966B4013-23C0-45EA-975A-6506707A555E@cis.upenn.edu> <56432EA6.40502@jacobs-university.de> Message-ID: <201511131601.35607.jan.stolarek@p.lodz.pl> My view on this is: Firstly, I hate explaining myself to Arcanist. When prompted to explain the reason for too long lines I typically enter "wontfix" without thinking too much. Secondly, I really don't like how warnings clutter code reviews. I have my Emacs highlight text beyond 80th column with a really ugly colour, so I strive real hard to maintain 80-column limit whenever possible. But sometimes fitting in that limit is nearly impossible: imagine being in a let nested in a do-notation nested in a guard nested in a where clause. Approx. 15-20 columns are lost for the indentation. Nevertheless I would support introducing a hard limit on having no more than 80 columns. Janek PS. It makes me really sad that we don't have any coding convention for GHC: we mix camelCase with underscore_case, indentation is inconsistent (good thing we at least got rid of tabs!), whitespace usage is inconsistent, etc. I could make this list very long. --- Politechnika ????dzka Lodz University of Technology Tre???? tej wiadomo??ci zawiera informacje przeznaczone tylko dla adresata. Je??eli nie jeste??cie Pa??stwo jej adresatem, b? d?? otrzymali??cie j? przez pomy??k?? prosimy o powiadomienie o tym nadawcy oraz trwa??e jej usuni??cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From eir at cis.upenn.edu Fri Nov 13 15:20:17 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 13 Nov 2015 10:20:17 -0500 Subject: too many lines too long In-Reply-To: <201511131601.35607.jan.stolarek@p.lodz.pl> References: <966B4013-23C0-45EA-975A-6506707A555E@cis.upenn.edu> <56432EA6.40502@jacobs-university.de> <201511131601.35607.jan.stolarek@p.lodz.pl> Message-ID: <18A0D099-B809-48F3-B44E-2B7A9E138F11@cis.upenn.edu> Could you add your comment to the ticket I've created? https://ghc.haskell.org/trac/ghc/ticket/11082 As for case conventions: The parts of GHC I play in have a fairly reliable convention: underscores for local things (both local variables and non-exported helper functions) and camel case for exported things. It's a nice convention that I've used elsewhere. This is not rigorously applied, but it's pretty good. Richard On Nov 13, 2015, at 10:01 AM, Jan Stolarek wrote: > My view on this is: > > Firstly, I hate explaining myself to Arcanist. When prompted to explain the reason for too long > lines I typically enter "wontfix" without thinking too much. > > Secondly, I really don't like how warnings clutter code reviews. > > I have my Emacs highlight text beyond 80th column with a really ugly colour, so I strive real hard > to maintain 80-column limit whenever possible. But sometimes fitting in that limit is nearly > impossible: imagine being in a let nested in a do-notation nested in a guard nested in a where > clause. Approx. 15-20 columns are lost for the indentation. Nevertheless I would support > introducing a hard limit on having no more than 80 columns. > > Janek > > PS. It makes me really sad that we don't have any coding convention for GHC: we mix camelCase with > underscore_case, indentation is inconsistent (good thing we at least got rid of tabs!), > whitespace usage is inconsistent, etc. I could make this list very long. > > --- > Politechnika ????dzka > Lodz University of Technology > > Tre???? tej wiadomo??ci zawiera informacje przeznaczone tylko dla adresata. > Je??eli nie jeste??cie Pa??stwo jej adresatem, b? > d?? otrzymali??cie j? > przez pomy??k?? > prosimy o powiadomienie o tym nadawcy oraz trwa??e jej usuni??cie. > > This email contains information intended solely for the use of the individual to whom it is addressed. > If you are not the intended recipient or if you have received this message in error, > please notify the sender and delete it from your system. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From jan.stolarek at p.lodz.pl Fri Nov 13 17:10:11 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Fri, 13 Nov 2015 18:10:11 +0100 Subject: Can't build current HEAD Message-ID: <201511131810.12387.jan.stolarek@p.lodz.pl> I am unable to build current HEAD. I'm getting a build error in Outputable module: compiler/utils/Outputable.hs:1046:28: Not in scope: type constructor or class ?CallStack? compiler/utils/Outputable.hs:1047:23: Not in scope: ?showCallStack? The most likely culprit is 80d7ce8038a100f6797a89755c893c6f67f18a30, which added this: #if __GLASGOW_HASKELL__ >= 710 pprSTrace :: (?location :: CallStack) => SDoc -> a -> a pprSTrace = pprTrace (showCallStack ?location) #else pprSTrace :: SDoc -> a -> a pprSTrace = pprTrace "no callstack info" #endif The most interesting thing is that if I change the definition of pprSTrace in the first branch of #if to be identical to the definition in the second branch, then I get warnings that GHC.Stack and GHC.Exception imports are redundant. Any ideas what might be going on here? I'm compiling using GHC 7.10.1. This happens in a clean build tree. Janek --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From jan.stolarek at p.lodz.pl Fri Nov 13 18:00:07 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Fri, 13 Nov 2015 19:00:07 +0100 Subject: Can't build current HEAD In-Reply-To: <201511131810.12387.jan.stolarek@p.lodz.pl> References: <201511131810.12387.jan.stolarek@p.lodz.pl> Message-ID: <201511131900.07302.jan.stolarek@p.lodz.pl> I just verified this does not happen when building with GHC 7.8.4, so if our build machines (harbormaster, travis) are building using 7.8.4 this might not show up in the logs. Janek Dnia pi?tek, 13 listopada 2015, Jan Stolarek napisa?: > I am unable to build current HEAD. I'm getting a build error in Outputable > module: > > compiler/utils/Outputable.hs:1046:28: > Not in scope: type constructor or class ?CallStack? > > compiler/utils/Outputable.hs:1047:23: Not in scope: ?showCallStack? > > The most likely culprit is 80d7ce8038a100f6797a89755c893c6f67f18a30, which > added this: > > #if __GLASGOW_HASKELL__ >= 710 > pprSTrace :: (?location :: CallStack) => SDoc -> a -> a > pprSTrace = pprTrace (showCallStack ?location) > #else > pprSTrace :: SDoc -> a -> a > pprSTrace = pprTrace "no callstack info" > #endif > > The most interesting thing is that if I change the definition of pprSTrace > in the first branch of #if to be identical to the definition in the second > branch, then I get warnings that GHC.Stack and GHC.Exception imports are > redundant. Any ideas what might be going on here? I'm compiling using GHC > 7.10.1. This happens in a clean build tree. > > Janek > > --- > Politechnika ??dzka > Lodz University of Technology > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez > pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > > This email contains information intended solely for the use of the > individual to whom it is addressed. If you are not the intended recipient > or if you have received this message in error, please notify the sender and > delete it from your system. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From mainland at apeiron.net Fri Nov 13 21:18:26 2015 From: mainland at apeiron.net (Geoffrey Mainland) Date: Fri, 13 Nov 2015 13:18:26 -0800 Subject: Pre-Proposal: Introspective Template Haskell In-Reply-To: References: <792B5E26-FE61-4FC3-9A45-4948DBED1B4C@cis.upenn.edu> <5644C865.3090404@apeiron.net> Message-ID: <564653A2.4080809@apeiron.net> Sounds like a good pan to me. Note that we would still need a small GHC-version-specific shim, somewhere, to define the Q monad, which does occasionally change. We could push it into the GHC API. Having three Haskell ASTs has always been a pain---it would be nice to finally fix this situation. Using your proposal, we could implement a fully compatible template-haskell library on top of the GHC AST and the "internal" Q monad. We could also implement an analogous package that was based on haskell-src-exts instead; in fact, it would be nice if the latter became the "standard" Template Haskell implementation, as it would also help us avoid hacks like haskell-src-meta. Geoff On 11/12/15 9:14 AM, Richard Eisenberg wrote: > Yes, that's right. But with a compatibility shim, no longer tied into GHC, that could provide stability and/or a simpler interface. This compatibility shim would likely be called template-haskell. (I retract the idea of deprecating the package. But we could democratize its maintenance rather easily after this change.) > > Richard > > On Nov 12, 2015, at 12:12 PM, Geoffrey Mainland wrote: > >> Hi Richard, >> >> Please correct me if I misunderstand, but in summary, you propose to >> change Template Haskell so that GHC's internal AST is produced directly, >> instead of the current route where there is an intermediate TH AST? >> >> Geoff >> >> On 11/11/2015 11:26 AM, Richard Eisenberg wrote: >>> Hi devs, >>> >>> There's a bunch of open tickets around Template Haskell. A great many of them are attempts to make TH more like what's already in GHC. Of course, when someone improves GHC, then TH also has to be updated. But this doesn't always happen, leading to several of these tickets. >>> >>> I believe I have a solution to the problem: just eliminate Template Haskell and provide direct access to GHC's internal structures. The idea (still very sketchy; hence pre-proposal) is like this (numbered for easy reference, but no order is implied): >>> >>> 1. TH quotes would remain. DsMeta would desugar quotes into Core code that produces HsExprs. For example, [| 1 |] would have type (Q (LHsExpr Name)). (Or perhaps (Q (LHsExpr RdrName)) if that works out better for clients.) >>> >>> 2. TH splices would remain, working much as they do now. The expression inside, say, an expression splice would have type (Q exp) where we can satisfy the constraint (SpliceExpr exp). There would be instances for (SpliceExpr (LHsExpr Name)) and (SpliceExpr (LHsExpr RdrName)) as well as the non-located variants. Generalizing the type of expressions here allows users not to worry about un-renaming when roundtripping between quotes and splices. >>> >>> 3. Reification would remain, using an Info structure much like we have now. Would we expose the real GHC TyCons as the result of reification? Or is it better to give the users HsDecls? This would need to be fleshed out. >>> >>> 4. Lifting would remain, doing the obvious thing. >>> >>> 5. The template-haskell package could even remain, as a backward-compatibility shim. It would declare gobs of pattern synonyms and type synonyms to wrap the new underlying interface. This re-imagined template-haskell package would not need to be a boot library, and could be upgraded separately from GHC. We could even maintain multiple versions of the library so that TH clients wouldn't have to change their code when GHC upgrades. Perhaps someday we could think about deprecating, if that's the way the wind blows. >>> >>> So, the end result is a completely re-engineered TH, but I believe we could keep full backward compatibility. (I have not considered Typed TH in any depth yet. But my hope is that it's not too different from the above.) And, we're left with a significantly lower maintenance burden, especially if we eliminate template-haskell someday. >>> >>> And, tantalizingly, the flexibility in splices might allow us to splice in *Core* code someday. Perhaps we could also reify Core code. Then clients could write their own custom, domain-aware optimizations. Like RULES on steroids. But that's all for the next phase. (Giving due credit, this last bit is inspired by work David Christiansen is doing in Idris.) >>> >>> What's wrong with this idea? I feel like *something* has to be more complicated than I've made it seem! >>> >>> Richard From eir at cis.upenn.edu Fri Nov 13 22:28:41 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 13 Nov 2015 17:28:41 -0500 Subject: Pre-Proposal: Introspective Template Haskell In-Reply-To: <564653A2.4080809@apeiron.net> References: <792B5E26-FE61-4FC3-9A45-4948DBED1B4C@cis.upenn.edu> <5644C865.3090404@apeiron.net> <564653A2.4080809@apeiron.net> Message-ID: This proposal now has a home at wiki:TemplateHaskell/Introspective and #11081. I think exploring how this might help haskell-src-exts would be very fruitful. Richard On Nov 13, 2015, at 4:18 PM, Geoffrey Mainland wrote: > Sounds like a good pan to me. Note that we would still need a small > GHC-version-specific shim, somewhere, to define the Q monad, which does > occasionally change. We could push it into the GHC API. > > Having three Haskell ASTs has always been a pain---it would be nice to > finally fix this situation. > > Using your proposal, we could implement a fully compatible > template-haskell library on top of the GHC AST and the "internal" Q > monad. We could also implement an analogous package that was based on > haskell-src-exts instead; in fact, it would be nice if the latter became > the "standard" Template Haskell implementation, as it would also help us > avoid hacks like haskell-src-meta. > > Geoff > > On 11/12/15 9:14 AM, Richard Eisenberg wrote: >> Yes, that's right. But with a compatibility shim, no longer tied into GHC, that could provide stability and/or a simpler interface. This compatibility shim would likely be called template-haskell. (I retract the idea of deprecating the package. But we could democratize its maintenance rather easily after this change.) >> >> Richard >> >> On Nov 12, 2015, at 12:12 PM, Geoffrey Mainland wrote: >> >>> Hi Richard, >>> >>> Please correct me if I misunderstand, but in summary, you propose to >>> change Template Haskell so that GHC's internal AST is produced directly, >>> instead of the current route where there is an intermediate TH AST? >>> >>> Geoff >>> >>> On 11/11/2015 11:26 AM, Richard Eisenberg wrote: >>>> Hi devs, >>>> >>>> There's a bunch of open tickets around Template Haskell. A great many of them are attempts to make TH more like what's already in GHC. Of course, when someone improves GHC, then TH also has to be updated. But this doesn't always happen, leading to several of these tickets. >>>> >>>> I believe I have a solution to the problem: just eliminate Template Haskell and provide direct access to GHC's internal structures. The idea (still very sketchy; hence pre-proposal) is like this (numbered for easy reference, but no order is implied): >>>> >>>> 1. TH quotes would remain. DsMeta would desugar quotes into Core code that produces HsExprs. For example, [| 1 |] would have type (Q (LHsExpr Name)). (Or perhaps (Q (LHsExpr RdrName)) if that works out better for clients.) >>>> >>>> 2. TH splices would remain, working much as they do now. The expression inside, say, an expression splice would have type (Q exp) where we can satisfy the constraint (SpliceExpr exp). There would be instances for (SpliceExpr (LHsExpr Name)) and (SpliceExpr (LHsExpr RdrName)) as well as the non-located variants. Generalizing the type of expressions here allows users not to worry about un-renaming when roundtripping between quotes and splices. >>>> >>>> 3. Reification would remain, using an Info structure much like we have now. Would we expose the real GHC TyCons as the result of reification? Or is it better to give the users HsDecls? This would need to be fleshed out. >>>> >>>> 4. Lifting would remain, doing the obvious thing. >>>> >>>> 5. The template-haskell package could even remain, as a backward-compatibility shim. It would declare gobs of pattern synonyms and type synonyms to wrap the new underlying interface. This re-imagined template-haskell package would not need to be a boot library, and could be upgraded separately from GHC. We could even maintain multiple versions of the library so that TH clients wouldn't have to change their code when GHC upgrades. Perhaps someday we could think about deprecating, if that's the way the wind blows. >>>> >>>> So, the end result is a completely re-engineered TH, but I believe we could keep full backward compatibility. (I have not considered Typed TH in any depth yet. But my hope is that it's not too different from the above.) And, we're left with a significantly lower maintenance burden, especially if we eliminate template-haskell someday. >>>> >>>> And, tantalizingly, the flexibility in splices might allow us to splice in *Core* code someday. Perhaps we could also reify Core code. Then clients could write their own custom, domain-aware optimizations. Like RULES on steroids. But that's all for the next phase. (Giving due credit, this last bit is inspired by work David Christiansen is doing in Idris.) >>>> >>>> What's wrong with this idea? I feel like *something* has to be more complicated than I've made it seem! >>>> >>>> Richard > From dluposchainsky at gmail.com Sat Nov 14 15:00:15 2015 From: dluposchainsky at gmail.com (David Luposchainsky) Date: Sat, 14 Nov 2015 16:00:15 +0100 Subject: Can't build current HEAD In-Reply-To: <201511131900.07302.jan.stolarek@p.lodz.pl> References: <201511131810.12387.jan.stolarek@p.lodz.pl> <201511131900.07302.jan.stolarek@p.lodz.pl> Message-ID: <56474C7F.6080709@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13.11.2015 19:00, Jan Stolarek wrote: > I am unable to build current HEAD. I'm getting a build error in Outputable > module I just ran into this myself. The ">= 710" is wrong, since 7.10 does not have CallStack yet. Changing it to "> 710" lets you compile GHC again, at the cost of a redundant import warning. David/quchen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWR0x/AAoJELrQsaT5WQUssXMH/2KLJbUiaiqgT5jqUKWclBcm bKSYXc5rgXWNzhWI5Y6WkHkexm0lP/VuDXJhL5xryoZoas5q2lo1YsvQ64+Ur5bl 94b7h7Q6pc+lm16dPR6G4SDo9enE38vjvpYMF7OD51IdnFpvWbqmliLc0moLK0rO S/JHa2AdjBt2zPbr+PE3iJGX1ARqyLjszPcawR+YzJzbBxtPb2NRdnfLNHLOMLXZ AO/Auy/GivfLCQHBd30g2vbniGa1BNyUpbV62BivFm2zbMf/zTQi+CQoubewdEBo sLRoceFzVw8BmMNMuZycINuID6gsQJ4Ir/UP/l17+gJI8DNCGCzs8pOVFYwYwas= =iFM0 -----END PGP SIGNATURE----- From omeragacan at gmail.com Sun Nov 15 00:01:03 2015 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Sat, 14 Nov 2015 19:01:03 -0500 Subject: build system issue: some changes in libraries doesn't trigger required rebuilds Message-ID: Hi all, I'm having this annoying issue all the time: Whenever a `git pull origin master` updates a library(one of the submodules, like `Binary`) a `make` doesn't trigger required rebuilds(e.g. it doesn't rebuild libraries and tries to rebuild GHC code). I don't know how to force build libraries, so most of the time I end up doing `make distclean` and wasting 30 minutes. I was wondering if there's a way to force rebuilding libraries? Or can we fix the build system somehow? From f at mazzo.li Sun Nov 15 10:26:21 2015 From: f at mazzo.li (Francesco Mazzoli) Date: Sun, 15 Nov 2015 10:26:21 +0000 Subject: Implementation idea for unboxed polymorphic types Message-ID: <1194C002-769A-4232-A2BC-632875496F37@mazzo.li> (A nicely rendered version of this email can be found at ) ## Macro types I very often find myself wanting unboxed polymorphic types (e.g. types that contain `UNPACK`ed type variables). I find it extremely frustrating that it's easier to write fast _and_ generic code in C++ than in Haskell. I'd like to submit to the mailing list a very rough proposal on how this could be achieved in a pretty straightforward way in GHC. The proposal is meant to be a proof of concept, just to show that this could be done rather easily. I did not think about a nice interface or the implementation details in GHC. My goal is to check the feasibility of this plan with GHC developers. I'll call such types "macro types", since their effect is similar to defining a macro that defines a new type for each type variable instantiation. Consider ``` data #Point a = Point { x :: {-# UNPACK #-} !a , y :: {-# UNPACK #-} !a } ``` This definition defines the macro type `#Point`, with one parameter `a`. Macro types definition would be allowed only for single-constructor records. The intent is that if we mention `#Point Double`, it will be equivalent to ``` data PointDouble = PointDouble { x :: {-# UNPACK #-} !Double , y :: {-# UNPACK #-} !Double } ``` To use `#Point` generically, the following type class would be generated: ``` class PointFamily a where data #Point a :: * -- Family of types generated by @data #Point a at . #Point :: a -> a -> #Point a -- Constructor. #x :: #Point a -> a -- Projection @x at . #y :: #Point a -> a -- Projection @y at . ``` Thi type class lets us work with `#Point`s generically, for example ``` distance :: (PointFamily a, Fractional a) => #Point a -> #Point a -> a distance p1 p2 = let dx = #x p1 - #x p2 dy = #y p1 - #y p2 in sqrt (dx*dx + dy*dy) ``` Internally, for every type appearing for `a`, e.g. `#Point Double`, a new type equivalent to the `PointDouble` above would be generated by GHC, with the corresponding instance ``` instance PointFamily Double where data #Point Double = PointDouble #x = x #y = x ``` If it's not possible to instantiate `#Point` with the provided type (for example because the type is not `UNPACK`able, e.g. `#Point (Maybe A)`), GHC would throw an error. Note that we can compile `distance` in its polymorphic version (as opposed to C++ templates, where template functions _must_ be instantiated at every use). The polymorphic `distance` would require a call to "virtual functions" `#x` and `#y`, as provided by the `PointFamily` dictionary. But if we use `INLINE` or `SPECIALIZE` pragmas the virtual calls to `#x` and `#y` would disappear, making this as efficient as if we were to define `distance` on the manually defined `PointDouble`. Compiler hints would be put in place to always inline functions using macro types, if possible. Note that the inlining is only important so that the `PointFamily` dictionary disappears, e.g. functions containing recursive helpers are fine, such as ``` {-# INLINE leftmost #-} leftmost :: forall a. (PointFamily a, Ord a) => [#Point a] -> #Point a leftmost [] = error "leftmost: no points" leftmost (p0 : ps0) = go p0 ps0 where go :: #Point a -> [#Point a] -> Point# a go candidate (p : ps) = if #x p < #x candidate then go p ps else go candidate ps ``` It might be worth considering throwing a warning when a top-level definition whose type contains a macro type cannot be inlined, since the main performance benefit of using macro types would be lost. We can define instances for these types as normal, for instance ``` instance (Show a, PointFamily a) => Show (#Point a) where {-# INLINE show #-} show pt = "Point{x = " ++ #x pt ++ ", y = " ++ #y pt ++ "}" ``` `deriving` support could also be added. ## Further ideas ### Hide or remove `PointFamily` from the user In the examples above `PointFamily` is manipulated explicitely (e.g. in the type signature for `distance`). In most cases the right constraint could be generated automatically by GHC, although I think direct access to the type class would be beneficial (history shows that direct access to these facilities is good, see upcoming explicit type applications). Maybe the type class associated to a macro type should not even exist -- for example we could simply represent `#Point` as a type family and treat construction and destruction as built-in syntax (the `#` prefix). ### Pattern matching Sugar could be added to pattern match, e.g. ``` foo :: Point# a -> ... distance (Point# x1 y1) = ... or dinstance Point#{..} = ... -- #x and #y are available ``` ### No "record types" limitation Instead of restricting ourselves to single-constructor records, we could simply generate ``` data Point a = Point a { x :: !a , y :: !a } class PointFamily a where data Point# a :: * destruct :: Point# a -> Point a construct :: Point a -> Point# a ``` However, I think it would be harder to guarantee the well-behavedness of the inlined functions if we had this intermediate type. I also don't think macro types would be very useful beyond polymorphic unboxed types. From ben at smart-cactus.org Sun Nov 15 10:37:05 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Sun, 15 Nov 2015 11:37:05 +0100 Subject: build system issue: some changes in libraries doesn't trigger required rebuilds In-Reply-To: References: Message-ID: <87bnav1rce.fsf@smart-cactus.org> ?mer Sinan A?acan writes: > Hi all, > > I'm having this annoying issue all the time: Whenever a `git pull origin > master` updates a library(one of the submodules, like `Binary`) a `make` > doesn't trigger required rebuilds(e.g. it doesn't rebuild libraries and tries > to rebuild GHC code). > > I don't know how to force build libraries, so most of the time I end up doing > `make distclean` and wasting 30 minutes. > You could try removing the dist-install/ directory of the relevant library. It generally triggers a rebuild (albeit not necessarily minimal). That being said, I generally just distclean when there's any question. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From omeragacan at gmail.com Sun Nov 15 15:08:32 2015 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Sun, 15 Nov 2015 10:08:32 -0500 Subject: Implementation idea for unboxed polymorphic types In-Reply-To: <1194C002-769A-4232-A2BC-632875496F37@mazzo.li> References: <1194C002-769A-4232-A2BC-632875496F37@mazzo.li> Message-ID: I had started working on exactly the same thing at some point. I had a TemplateHaskell-based implementation which _almost_ worked. The problem was that the syntax was very, very heavy. Because I had to use quotes for _every_ constructor application(with explicitly passed types). (because I had a specialized constructor for every instantiation of this generic type) Another problem was that because of how TemplateHaskell quotes evaluated, I couldn't use a `List Int` where `List` is a template without first manually adding a line for generating specialized version of `List` on `Int`. When all of these combined it became very hard to use. But it was a proof-of-concept and I think it worked. (Code is horrible so I won't share it here :) I had to maintain a state shared with different TH quote evaluations etc.) 2015-11-15 5:26 GMT-05:00 Francesco Mazzoli : > (A nicely rendered version of this email can be found at ) > > ## Macro types > > I very often find myself wanting unboxed polymorphic types > (e.g. types that contain `UNPACK`ed type variables). I find > it extremely frustrating that it's easier to write fast _and_ > generic code in C++ than in Haskell. > > I'd like to submit to the mailing list a very rough proposal > on how this could be achieved in a pretty straightforward way > in GHC. > > The proposal is meant to be a proof of concept, just to show that > this could be done rather easily. I did not think about a nice > interface or the implementation details in GHC. My goal is to > check the feasibility of this plan with GHC developers. > > I'll call such types "macro types", since their effect is similar > to defining a macro that defines a new type for each type > variable instantiation. > > Consider > > ``` > data #Point a = Point > { x :: {-# UNPACK #-} !a > , y :: {-# UNPACK #-} !a > } > ``` > > This definition defines the macro type `#Point`, with one parameter > `a`. > > Macro types definition would be allowed only for single-constructor > records. The intent is that if we mention `#Point Double`, it will > be equivalent to > > ``` > data PointDouble = PointDouble > { x :: {-# UNPACK #-} !Double > , y :: {-# UNPACK #-} !Double > } > ``` > > To use `#Point` generically, the following type class would be > generated: > > ``` > class PointFamily a where > data #Point a :: * -- Family of types generated by @data #Point a at . > #Point :: a -> a -> #Point a -- Constructor. > #x :: #Point a -> a -- Projection @x at . > #y :: #Point a -> a -- Projection @y at . > ``` > > Thi type class lets us work with `#Point`s generically, for example > > ``` > distance :: (PointFamily a, Fractional a) => #Point a -> #Point a -> a > distance p1 p2 = > let dx = #x p1 - #x p2 > dy = #y p1 - #y p2 > in sqrt (dx*dx + dy*dy) > ``` > > Internally, for every type appearing for `a`, e.g. `#Point Double`, > a new type equivalent to the `PointDouble` above would be generated > by GHC, with the corresponding instance > > ``` > instance PointFamily Double where > data #Point Double = PointDouble > #x = x > #y = x > ``` > > If it's not possible to instantiate `#Point` with the provided type > (for example because the type is not `UNPACK`able, e.g. > `#Point (Maybe A)`), GHC would throw an error. > > Note that we can compile `distance` in its polymorphic version > (as opposed to C++ templates, where template functions _must_ be > instantiated at every use). The polymorphic `distance` would > require a call to "virtual functions" `#x` and `#y`, as provided by > the `PointFamily` dictionary. But if we use > `INLINE` or `SPECIALIZE` pragmas the virtual calls to `#x` and `#y` > would disappear, making this as efficient as if we were to define > `distance` on the manually defined `PointDouble`. Compiler hints > would be put in place to always inline functions using macro types, > if possible. > > Note that the inlining is only important so that the `PointFamily` > dictionary disappears, e.g. functions containing recursive > helpers are fine, such as > > ``` > {-# INLINE leftmost #-} > leftmost :: forall a. (PointFamily a, Ord a) => [#Point a] -> #Point a > leftmost [] = error "leftmost: no points" > leftmost (p0 : ps0) = go p0 ps0 > where > go :: #Point a -> [#Point a] -> Point# a > go candidate (p : ps) = > if #x p < #x candidate > then go p ps > else go candidate ps > ``` > > It might be worth considering throwing a warning when a top-level > definition whose type contains a macro type cannot be inlined, since > the main performance benefit of using macro types would be lost. > > We can define instances for these types as normal, for instance > > ``` > instance (Show a, PointFamily a) => Show (#Point a) where > {-# INLINE show #-} > show pt = "Point{x = " ++ #x pt ++ ", y = " ++ #y pt ++ "}" > ``` > > `deriving` support could also be added. > > ## Further ideas > > ### Hide or remove `PointFamily` from the user > > In the examples above `PointFamily` is manipulated explicitely > (e.g. in the type signature for `distance`). > In most cases the right constraint could be generated > automatically by GHC, although I think direct access to the > type class would be beneficial (history shows that direct > access to these facilities is good, see upcoming explicit > type applications). > > Maybe the type class associated to a macro type should not even > exist -- for example we could simply represent `#Point` as a type > family and treat construction and destruction as built-in syntax > (the `#` prefix). > > ### Pattern matching > > Sugar could be added to pattern match, e.g. > > ``` > foo :: Point# a -> ... > distance (Point# x1 y1) = ... > or > dinstance Point#{..} = ... -- #x and #y are available > ``` > > ### No "record types" limitation > > Instead of restricting ourselves to single-constructor records, > we could simply generate > > ``` > data Point a = Point a > { x :: !a > , y :: !a > } > > class PointFamily a where > data Point# a :: * > destruct :: Point# a -> Point a > construct :: Point a -> Point# a > ``` > > However, I think it would be harder to guarantee the well-behavedness > of the inlined functions if we had this intermediate type. I also > don't think macro types would be very useful beyond polymorphic > unboxed types. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From george.colpitts at gmail.com Sun Nov 15 21:46:41 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Sun, 15 Nov 2015 17:46:41 -0400 Subject: [ANNOUNCE] 7.10.3 release candidate 2 - problems compiling source on Mac OS with clang Message-ID: I did get compiling from source to work on the Mac. Unfortunately I'm not sure what the problem was. I now see a new problem, not sure if it is a ghc problem or a library problem: cabal install HsOpenSSL ... Building HsOpenSSL-0.11.1.1... Preprocessing library HsOpenSSL-0.11.1.1... In file included from BN.hsc:45: cbits/HsOpenSSL.h:3:10: fatal error: 'openssl/asn1.h' file not found #include ^ 1 error generated. compiling dist/build/OpenSSL/BN_hsc_make.c failed (exit code 1) command was: /usr/bin/gcc -c dist/build/OpenSSL/BN_hsc_make.c -o dist/build/OpenSSL/BN_hsc_make.o -m64 -fno-stack-protector -D__GLASGOW_HASKELL__=710 -Ddarwin_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 -Ddarwin_HOST_OS=1 -Dx86_64_HOST_ARCH=1 -Icbits -D PTHREAD -DCALLCONV=ccall -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -I/Users/gcolpitts/Library/Haskell/ghc-7.10.2.20151105-x86_64/lib/network-2.6.2.1/include -I/usr/local/lib/ghc-7.10.2.20151105/unix_KZL8h98IqDM57kQSPo1mKx/include -I/usr/local/lib/ghc-7.10.2.20151105/time_FTheb6LSxyX1UABIbBXRfn/include -I/usr/local/lib/ghc-7.10.2.20151105/bytes_6VWy06pWzJq9evDvK2d4w6/include -I/usr/local/lib/ghc-7.10.2.20151105/base_HQfYBxpPvuw8OunzQu6JGM/include -I/usr/local/lib/ghc-7.10.2.20151105/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I/usr/local/lib/ghc-7.10.2.20151105/include -I/usr/local/lib/ghc-7.10.2.20151105/include/ cabal: Error: some packages failed to install: HsOpenSSL-0.11.1.1 failed during the building phase. The exception was: ExitFailure 1 /usr/bin/gcc --version /usr/bin/gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/c++/4.2.1 Apple LLVM version 7.0.0 (clang-700.1.76) Target: x86_64-apple-darwin15.0.0 Thread model: posix On Mon, Nov 9, 2015 at 10:49 AM, George Colpitts wrote: > redid with just make rather than make -j5. I get > > > ... > chmod +x libraries/integer-gmp2/gmp/ln > # Their cmd invocation only works on msys. On cygwin it starts > # a cmd interactive shell. The replacement works in both environments. > mv libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh > libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh.orig > sed 's#cmd //c echo "\$1"#cmd /c "echo $1"#' < > libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh.orig > > libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh > cd libraries/integer-gmp2/gmp; (set -o igncr 2>/dev/null) && set -o igncr; > export SHELLOPTS; \ > PATH=`pwd`:$PATH; \ > export PATH; \ > cd gmpbuild && \ > CC=clang NM=/usr/bin/nm AR=/usr/bin/ar ./configure \ > --enable-shared=no \ > --host=x86_64-apple-darwin --build=x86_64-apple-darwin > /bin/sh: SHELLOPTS: readonly variable > checking build system type... /bin/sh: SHELLOPTS: readonly variable > /bin/sh: SHELLOPTS: readonly variable > x86_64-apple-darwin > checking host system type... /bin/sh: SHELLOPTS: readonly variable > /bin/sh: SHELLOPTS: readonly variable > x86_64-apple-darwin > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > /bin/sh: SHELLOPTS: readonly variable > checking for a thread-safe mkdir -p... ./install-sh -c -d > checking for gawk... no > checking for mawk... no > checking for nawk... no > checking for awk... awk > checking whether make sets $(MAKE)... yes > checking whether to enable maintainer-specific portions of Makefiles... no > checking ABI=64 > checking whether clang is gcc... yes > checking compiler clang -O2 -pedantic -fPIC -m64 ... no, gnupro alpha ev6 > char spilling > checking ABI=32 > checking whether clang is gcc... yes > *checking compiler clang -m32 -O2 -pedantic -fPIC -fomit-frame-pointer ... > no, gnupro alpha ev6 char spilling* > *checking compiler clang -O2 -pedantic -fPIC -fomit-frame-pointer ... no, > gnupro alpha ev6 char spilling* > *configure: error: could not find a working compiler, see config.log for > details* > *make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1* > *make: *** [all] Error 2* > > > On Mon, Nov 9, 2015 at 9:32 AM, Ben Gamari wrote: > >> George Colpitts writes: >> >> > I get >> > >> > make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1 >> > make[1]: *** Waiting for unfinished jobs.... >> >> It looks like the build failed somewhere before this point. Could you >> provide a more complete log? >> >> Cheers, >> >> - Ben >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sun Nov 15 22:14:07 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 15 Nov 2015 17:14:07 -0500 Subject: [ANNOUNCE] 7.10.3 release candidate 2 - problems compiling source on Mac OS with clang In-Reply-To: References: Message-ID: Did you install OpenSSL ?? I'll upload my better ghc build in 5 minutes. Did it end of the week and then got a bit busy On Sunday, November 15, 2015, George Colpitts wrote: > I did get compiling from source to work on the Mac. Unfortunately I'm not > sure what the problem was. > > I now see a new problem, not sure if it is a ghc problem or a library > problem: > > cabal install HsOpenSSL > ... > Building HsOpenSSL-0.11.1.1... > Preprocessing library HsOpenSSL-0.11.1.1... > In file included from BN.hsc:45: > cbits/HsOpenSSL.h:3:10: fatal error: 'openssl/asn1.h' file not found > #include > ^ > 1 error generated. > compiling dist/build/OpenSSL/BN_hsc_make.c failed (exit code 1) > command was: /usr/bin/gcc -c dist/build/OpenSSL/BN_hsc_make.c -o > dist/build/OpenSSL/BN_hsc_make.o -m64 -fno-stack-protector > -D__GLASGOW_HASKELL__=710 -Ddarwin_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 > -Ddarwin_HOST_OS=1 -Dx86_64_HOST_ARCH=1 -Icbits -D PTHREAD -DCALLCONV=ccall > -Idist/build/autogen -include dist/build/autogen/cabal_macros.h > -I/Users/gcolpitts/Library/Haskell/ghc-7.10.2.20151105-x86_64/lib/network-2.6.2.1/include > -I/usr/local/lib/ghc-7.10.2.20151105/unix_KZL8h98IqDM57kQSPo1mKx/include > -I/usr/local/lib/ghc-7.10.2.20151105/time_FTheb6LSxyX1UABIbBXRfn/include > -I/usr/local/lib/ghc-7.10.2.20151105/bytes_6VWy06pWzJq9evDvK2d4w6/include > -I/usr/local/lib/ghc-7.10.2.20151105/base_HQfYBxpPvuw8OunzQu6JGM/include > -I/usr/local/lib/ghc-7.10.2.20151105/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include > -I/usr/local/lib/ghc-7.10.2.20151105/include > -I/usr/local/lib/ghc-7.10.2.20151105/include/ > cabal: Error: some packages failed to install: > HsOpenSSL-0.11.1.1 failed during the building phase. The exception was: > ExitFailure 1 > > /usr/bin/gcc --version > /usr/bin/gcc --version > Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr > --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/c++/4.2.1 > Apple LLVM version 7.0.0 (clang-700.1.76) > Target: x86_64-apple-darwin15.0.0 > Thread model: posix > > On Mon, Nov 9, 2015 at 10:49 AM, George Colpitts < > george.colpitts at gmail.com > > wrote: > >> redid with just make rather than make -j5. I get >> >> >> ... >> chmod +x libraries/integer-gmp2/gmp/ln >> # Their cmd invocation only works on msys. On cygwin it starts >> # a cmd interactive shell. The replacement works in both environments. >> mv libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh >> libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh.orig >> sed 's#cmd //c echo "\$1"#cmd /c "echo $1"#' < >> libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh.orig > >> libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh >> cd libraries/integer-gmp2/gmp; (set -o igncr 2>/dev/null) && set -o >> igncr; export SHELLOPTS; \ >> PATH=`pwd`:$PATH; \ >> export PATH; \ >> cd gmpbuild && \ >> CC=clang NM=/usr/bin/nm AR=/usr/bin/ar ./configure \ >> --enable-shared=no \ >> --host=x86_64-apple-darwin --build=x86_64-apple-darwin >> /bin/sh: SHELLOPTS: readonly variable >> checking build system type... /bin/sh: SHELLOPTS: readonly variable >> /bin/sh: SHELLOPTS: readonly variable >> x86_64-apple-darwin >> checking host system type... /bin/sh: SHELLOPTS: readonly variable >> /bin/sh: SHELLOPTS: readonly variable >> x86_64-apple-darwin >> checking for a BSD-compatible install... /usr/bin/install -c >> checking whether build environment is sane... yes >> /bin/sh: SHELLOPTS: readonly variable >> checking for a thread-safe mkdir -p... ./install-sh -c -d >> checking for gawk... no >> checking for mawk... no >> checking for nawk... no >> checking for awk... awk >> checking whether make sets $(MAKE)... yes >> checking whether to enable maintainer-specific portions of Makefiles... no >> checking ABI=64 >> checking whether clang is gcc... yes >> checking compiler clang -O2 -pedantic -fPIC -m64 ... no, gnupro alpha ev6 >> char spilling >> checking ABI=32 >> checking whether clang is gcc... yes >> *checking compiler clang -m32 -O2 -pedantic -fPIC -fomit-frame-pointer >> ... no, gnupro alpha ev6 char spilling* >> *checking compiler clang -O2 -pedantic -fPIC -fomit-frame-pointer ... no, >> gnupro alpha ev6 char spilling* >> *configure: error: could not find a working compiler, see config.log for >> details* >> *make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1* >> *make: *** [all] Error 2* >> >> >> On Mon, Nov 9, 2015 at 9:32 AM, Ben Gamari > > wrote: >> >>> George Colpitts >> > writes: >>> >>> > I get >>> > >>> > make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1 >>> > make[1]: *** Waiting for unfinished jobs.... >>> >>> It looks like the build failed somewhere before this point. Could you >>> provide a more complete log? >>> >>> Cheers, >>> >>> - Ben >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sun Nov 15 22:17:55 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 15 Nov 2015 17:17:55 -0500 Subject: mac build for 7.10.3 RC Message-ID: here yah go! this should fix issues with my earlier build http://www.wellposed.com/opensource/ghc/releasebuild-unofficial/ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2 $ shasum -a512 ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2 6bf9c93e217a148e97884db447cbeb2d9370facecc61d81cf7e47cf1f66ad664046f79e0813117342dcd811fd0e290fa0247a34cbd26c7c577f7159f51f4bbbe ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2 for those who want the check sum -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Sun Nov 15 22:55:14 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Sun, 15 Nov 2015 18:55:14 -0400 Subject: mac build for 7.10.3 RC In-Reply-To: References: Message-ID: Thanks! That seems to work on my Mac as I can install packages like QuickCheck On Sun, Nov 15, 2015 at 6:17 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > here yah go! > this should fix issues with my earlier build > > http://www.wellposed.com/opensource/ghc/releasebuild-unofficial/ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2 > > $ shasum -a512 ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2 > 6bf9c93e217a148e97884db447cbeb2d9370facecc61d81cf7e47cf1f66ad664046f79e0813117342dcd811fd0e290fa0247a34cbd26c7c577f7159f51f4bbbe > ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2 > for those who want the check sum > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Sun Nov 15 23:09:33 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Sun, 15 Nov 2015 19:09:33 -0400 Subject: [ANNOUNCE] 7.10.3 release candidate 2 - problems compiling source on Mac OS with clang In-Reply-To: References: Message-ID: Yes I have openssl installed $ brew upgrade openssl brew upgrade openssl Error: openssl 1.0.2d_1 already installed Thanks for uploading the new binary install, it definitely solved the problem I originally reported However it doesn't solve the HsOpenSSL problem: cabal install HsOpenSSL cabal install HsOpenSSL Resolving dependencies... Configuring HsOpenSSL-0.11.1.1... Building HsOpenSSL-0.11.1.1... Failed to install HsOpenSSL-0.11.1.1 Build log ( /Users/gcolpitts/.cabal/logs/HsOpenSSL-0.11.1.1.log ): Configuring HsOpenSSL-0.11.1.1... Building HsOpenSSL-0.11.1.1... Preprocessing library HsOpenSSL-0.11.1.1... In file included from BN.hsc:45: cbits/HsOpenSSL.h:3:10: fatal error: 'openssl/asn1.h' file not found #include ^ 1 error generated. compiling dist/build/OpenSSL/BN_hsc_make.c failed (exit code 1) command was: /usr/bin/gcc -c dist/build/OpenSSL/BN_hsc_make.c -o dist/build/OpenSSL/BN_hsc_make.o -m64 -fno-stack-protector -D__GLASGOW_HASKELL__=710 -Ddarwin_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 -Ddarwin_HOST_OS=1 -Dx86_64_HOST_ARCH=1 -Icbits -D PTHREAD -DCALLCONV=ccall -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -I/Users/gcolpitts/Library/Haskell/ghc-7.10.2.20151105-x86_64/lib/network-2.6.2.1/include -I/usr/local/lib/ghc-7.10.2.20151105/unix_KZL8h98IqDM57kQSPo1mKx/include -I/usr/local/lib/ghc-7.10.2.20151105/time_FTheb6LSxyX1UABIbBXRfn/include -I/usr/local/lib/ghc-7.10.2.20151105/bytes_6VWy06pWzJq9evDvK2d4w6/include -I/usr/local/lib/ghc-7.10.2.20151105/base_HQfYBxpPvuw8OunzQu6JGM/include -I/usr/local/lib/ghc-7.10.2.20151105/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I/usr/local/lib/ghc-7.10.2.20151105/include -I/usr/local/lib/ghc-7.10.2.20151105/include/ cabal: Error: some packages failed to install: HsOpenSSL-0.11.1.1 failed during the building phase. The exception was: ExitFailure 1 However I think I have some problems I need to clean up first. What do I need to do to get to a clean state wrt existing libraries, i.e. how do I delete them before installing the latest ghc? I think building and installing from source, then installing libraries, then installing binaries and building more libraries has left me in an unstable state. Thanks George ghc-pkg check There are problems in package hashtables-1.2.0.2: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist There are problems in package hashable-1.2.3.3: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist dependency "bytestring-0.10.6.0-57aca8b044c60296d333ba9ef7a6b270" doesn't exist There are problems in package ghc-events-0.4.4.0: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist dependency "bytestring-0.10.6.0-57aca8b044c60296d333ba9ef7a6b270" doesn't exist There are problems in package data-ordlist-0.4.7.0: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist There are problems in package criterion-1.1.0.0: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist dependency "binary-0.7.5.0-77839394dfefc3f030d00790a2cef7fa" doesn't exist dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" doesn't exist dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" doesn't exist dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" doesn't exist dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't exist dependency "time-1.5.0.1-2654f2ea82eb50a9cb76337c0b480079" doesn't exist There are problems in package statistics-0.13.2.3: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist dependency "binary-0.7.5.0-77839394dfefc3f030d00790a2cef7fa" doesn't exist There are problems in package aeson-0.10.0.0: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" doesn't exist dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" doesn't exist dependency "hashable-1.2.3.3-bc60d08cd07d83826168419244ef8bf3" doesn't exist dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't exist dependency "time-1.5.0.1-2654f2ea82eb50a9cb76337c0b480079" doesn't exist There are problems in package vector-algorithms-0.7.0.1: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" doesn't exist There are problems in package cassava-0.4.4.0: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" doesn't exist dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" doesn't exist dependency "hashable-1.2.3.3-bc60d08cd07d83826168419244ef8bf3" doesn't exist dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't exist There are problems in package attoparsec-0.13.0.1: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" doesn't exist dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" doesn't exist dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't exist There are problems in package monad-par-0.3.4.7: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" doesn't exist There are problems in package mwc-random-0.13.3.2: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist dependency "time-1.5.0.1-2654f2ea82eb50a9cb76337c0b480079" doesn't exist There are problems in package math-functions-0.1.5.2: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist There are problems in package scientific-0.3.4.2: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist dependency "binary-0.7.5.0-77839394dfefc3f030d00790a2cef7fa" doesn't exist dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" doesn't exist dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" doesn't exist dependency "hashable-1.2.3.3-bc60d08cd07d83826168419244ef8bf3" doesn't exist dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't exist There are problems in package vector-th-unbox-0.2.1.3: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist There are problems in package vector-binary-instances-0.2.1.0: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist dependency "binary-0.7.5.0-77839394dfefc3f030d00790a2cef7fa" doesn't exist There are problems in package vector-0.11.0.0: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist There are problems in package Glob-0.7.5: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" doesn't exist dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" doesn't exist There are problems in package monad-par-extras-0.3.3: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist dependency "random-1.1-e88d133272c86b979391f1c08bf5ca07" doesn't exist There are problems in package parsec-3.1.9: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" doesn't exist dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't exist There are problems in package abstract-deque-0.3: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" doesn't exist dependency "random-1.1-e88d133272c86b979391f1c08bf5ca07" doesn't exist dependency "time-1.5.0.1-2654f2ea82eb50a9cb76337c0b480079" doesn't exist There are problems in package optparse-applicative-0.12.0.0: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist dependency "process-1.2.3.0-0103d9aa28c4fa0eada355d1840af7ae" doesn't exist There are problems in package hastache-0.6.1: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" doesn't exist dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" doesn't exist dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" doesn't exist dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't exist There are problems in package cereal-0.5.0.0: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" doesn't exist dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" doesn't exist There are problems in package dlist-0.7.1.2: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist There are problems in package ansi-wl-pprint-0.6.7.3: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist There are problems in package blaze-builder-0.4.0.1: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" doesn't exist dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't exist There are problems in package parallel-3.2.0.6: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" doesn't exist There are problems in package transformers-compat-0.4.0.4: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist There are problems in package ieee754-0.7.6: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist There are problems in package abstract-par-0.3.3: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist There are problems in package erf-2.0.0.0: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist There are problems in package hlint-1.9.22: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" doesn't exist dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" doesn't exist dependency "process-1.2.3.0-0103d9aa28c4fa0eada355d1840af7ae" doesn't exist There are problems in package haskell-src-exts-1.16.0.1: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist There are problems in package uniplate-1.6.12: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" doesn't exist dependency "hashable-1.2.3.3-bc60d08cd07d83826168419244ef8bf3" doesn't exist There are problems in package cpphs-1.19.3: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" doesn't exist There are problems in package polyparse-1.11: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" doesn't exist dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't exist There are problems in package unordered-containers-0.2.5.1: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist dependency "hashable-1.2.3.3-bc60d08cd07d83826168419244ef8bf3" doesn't exist There are problems in package cmdargs-0.10.13: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist dependency "process-1.2.3.0-0103d9aa28c4fa0eada355d1840af7ae" doesn't exist There are problems in package old-time-1.1.0.3: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist There are problems in package hscolour-1.23: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" doesn't exist There are problems in package syb-0.6: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist There are problems in package refact-0.3.0.1: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist There are problems in package extra-1.4.2: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" doesn't exist dependency "process-1.2.3.0-0103d9aa28c4fa0eada355d1840af7ae" doesn't exist dependency "time-1.5.0.1-2654f2ea82eb50a9cb76337c0b480079" doesn't exist dependency "unix-2.7.1.0-327d00fd34e5d5a1c53223d920b10810" doesn't exist There are problems in package ansi-terminal-0.6.2.3: dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist dependency "unix-2.7.1.0-327d00fd34e5d5a1c53223d920b10810" doesn't exist The following packages are broken, either because they have a problem listed above, or because they depend on a broken package. hashtables-1.2.0.2 hashable-1.2.3.3 ghc-events-0.4.4.0 data-ordlist-0.4.7.0 criterion-1.1.0.0 statistics-0.13.2.3 aeson-0.10.0.0 vector-algorithms-0.7.0.1 cassava-0.4.4.0 attoparsec-0.13.0.1 monad-par-0.3.4.7 mwc-random-0.13.3.2 math-functions-0.1.5.2 scientific-0.3.4.2 vector-th-unbox-0.2.1.3 vector-binary-instances-0.2.1.0 vector-0.11.0.0 Glob-0.7.5 monad-par-extras-0.3.3 parsec-3.1.9 abstract-deque-0.3 optparse-applicative-0.12.0.0 hastache-0.6.1 cereal-0.5.0.0 dlist-0.7.1.2 ansi-wl-pprint-0.6.7.3 blaze-builder-0.4.0.1 parallel-3.2.0.6 transformers-compat-0.4.0.4 ieee754-0.7.6 abstract-par-0.3.3 erf-2.0.0.0 hlint-1.9.22 haskell-src-exts-1.16.0.1 uniplate-1.6.12 cpphs-1.19.3 polyparse-1.11 unordered-containers-0.2.5.1 cmdargs-0.10.13 old-time-1.1.0.3 hscolour-1.23 syb-0.6 refact-0.3.0.1 extra-1.4.2 ansi-terminal-0.6.2.3 On Sun, Nov 15, 2015 at 6:14 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > Did you install OpenSSL ?? > > I'll upload my better ghc build in 5 minutes. Did it end of the week and > then got a bit busy > > > On Sunday, November 15, 2015, George Colpitts > wrote: > >> I did get compiling from source to work on the Mac. Unfortunately I'm not >> sure what the problem was. >> >> I now see a new problem, not sure if it is a ghc problem or a library >> problem: >> >> cabal install HsOpenSSL >> ... >> Building HsOpenSSL-0.11.1.1... >> Preprocessing library HsOpenSSL-0.11.1.1... >> In file included from BN.hsc:45: >> cbits/HsOpenSSL.h:3:10: fatal error: 'openssl/asn1.h' file not found >> #include >> ^ >> 1 error generated. >> compiling dist/build/OpenSSL/BN_hsc_make.c failed (exit code 1) >> command was: /usr/bin/gcc -c dist/build/OpenSSL/BN_hsc_make.c -o >> dist/build/OpenSSL/BN_hsc_make.o -m64 -fno-stack-protector >> -D__GLASGOW_HASKELL__=710 -Ddarwin_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 >> -Ddarwin_HOST_OS=1 -Dx86_64_HOST_ARCH=1 -Icbits -D PTHREAD -DCALLCONV=ccall >> -Idist/build/autogen -include dist/build/autogen/cabal_macros.h >> -I/Users/gcolpitts/Library/Haskell/ghc-7.10.2.20151105-x86_64/lib/network-2.6.2.1/include >> -I/usr/local/lib/ghc-7.10.2.20151105/unix_KZL8h98IqDM57kQSPo1mKx/include >> -I/usr/local/lib/ghc-7.10.2.20151105/time_FTheb6LSxyX1UABIbBXRfn/include >> -I/usr/local/lib/ghc-7.10.2.20151105/bytes_6VWy06pWzJq9evDvK2d4w6/include >> -I/usr/local/lib/ghc-7.10.2.20151105/base_HQfYBxpPvuw8OunzQu6JGM/include >> -I/usr/local/lib/ghc-7.10.2.20151105/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include >> -I/usr/local/lib/ghc-7.10.2.20151105/include >> -I/usr/local/lib/ghc-7.10.2.20151105/include/ >> cabal: Error: some packages failed to install: >> HsOpenSSL-0.11.1.1 failed during the building phase. The exception was: >> ExitFailure 1 >> >> /usr/bin/gcc --version >> /usr/bin/gcc --version >> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr >> --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/c++/4.2.1 >> Apple LLVM version 7.0.0 (clang-700.1.76) >> Target: x86_64-apple-darwin15.0.0 >> Thread model: posix >> >> On Mon, Nov 9, 2015 at 10:49 AM, George Colpitts < >> george.colpitts at gmail.com> wrote: >> >>> redid with just make rather than make -j5. I get >>> >>> >>> ... >>> chmod +x libraries/integer-gmp2/gmp/ln >>> # Their cmd invocation only works on msys. On cygwin it starts >>> # a cmd interactive shell. The replacement works in both environments. >>> mv libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh >>> libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh.orig >>> sed 's#cmd //c echo "\$1"#cmd /c "echo $1"#' < >>> libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh.orig > >>> libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh >>> cd libraries/integer-gmp2/gmp; (set -o igncr 2>/dev/null) && set -o >>> igncr; export SHELLOPTS; \ >>> PATH=`pwd`:$PATH; \ >>> export PATH; \ >>> cd gmpbuild && \ >>> CC=clang NM=/usr/bin/nm AR=/usr/bin/ar ./configure \ >>> --enable-shared=no \ >>> --host=x86_64-apple-darwin --build=x86_64-apple-darwin >>> /bin/sh: SHELLOPTS: readonly variable >>> checking build system type... /bin/sh: SHELLOPTS: readonly variable >>> /bin/sh: SHELLOPTS: readonly variable >>> x86_64-apple-darwin >>> checking host system type... /bin/sh: SHELLOPTS: readonly variable >>> /bin/sh: SHELLOPTS: readonly variable >>> x86_64-apple-darwin >>> checking for a BSD-compatible install... /usr/bin/install -c >>> checking whether build environment is sane... yes >>> /bin/sh: SHELLOPTS: readonly variable >>> checking for a thread-safe mkdir -p... ./install-sh -c -d >>> checking for gawk... no >>> checking for mawk... no >>> checking for nawk... no >>> checking for awk... awk >>> checking whether make sets $(MAKE)... yes >>> checking whether to enable maintainer-specific portions of Makefiles... >>> no >>> checking ABI=64 >>> checking whether clang is gcc... yes >>> checking compiler clang -O2 -pedantic -fPIC -m64 ... no, gnupro alpha >>> ev6 char spilling >>> checking ABI=32 >>> checking whether clang is gcc... yes >>> *checking compiler clang -m32 -O2 -pedantic -fPIC -fomit-frame-pointer >>> ... no, gnupro alpha ev6 char spilling* >>> *checking compiler clang -O2 -pedantic -fPIC -fomit-frame-pointer ... >>> no, gnupro alpha ev6 char spilling* >>> *configure: error: could not find a working compiler, see config.log for >>> details* >>> *make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1* >>> *make: *** [all] Error 2* >>> >>> >>> On Mon, Nov 9, 2015 at 9:32 AM, Ben Gamari wrote: >>> >>>> George Colpitts writes: >>>> >>>> > I get >>>> > >>>> > make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1 >>>> > make[1]: *** Waiting for unfinished jobs.... >>>> >>>> It looks like the build failed somewhere before this point. Could you >>>> provide a more complete log? >>>> >>>> Cheers, >>>> >>>> - Ben >>>> >>>> >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Mon Nov 16 00:41:19 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Sun, 15 Nov 2015 19:41:19 -0500 Subject: Implementation idea for unboxed polymorphic types In-Reply-To: References: <1194C002-769A-4232-A2BC-632875496F37@mazzo.li> Message-ID: After reading Francesco's original post, I immediately thought of ?mer's proposed approach, of using Template Haskell to produce the right data family instances. But I don't see why you'd need quoting at constructor calls. Couldn't you just have a type class like `PointFamily`? I'd be more interested to see client code in ?mer's version than the TH generation code. The TH approach would seem to require having a fixed set of specializations, which is a downside. But I'm not sure it's so much of a downside that the approach is unusable. Richard On Nov 15, 2015, at 10:08 AM, ?mer Sinan A?acan wrote: > I had started working on exactly the same thing at some point. I had a > TemplateHaskell-based implementation which _almost_ worked. > > The problem was that the syntax was very, very heavy. Because I had to use > quotes for _every_ constructor application(with explicitly passed types). > (because I had a specialized constructor for every instantiation of this > generic type) > > Another problem was that because of how TemplateHaskell quotes evaluated, I > couldn't use a `List Int` where `List` is a template without first manually > adding a line for generating specialized version of `List` on `Int`. > > When all of these combined it became very hard to use. But it was a > proof-of-concept and I think it worked. > > (Code is horrible so I won't share it here :) I had to maintain a state shared > with different TH quote evaluations etc.) > > 2015-11-15 5:26 GMT-05:00 Francesco Mazzoli : >> (A nicely rendered version of this email can be found at ) >> >> ## Macro types >> >> I very often find myself wanting unboxed polymorphic types >> (e.g. types that contain `UNPACK`ed type variables). I find >> it extremely frustrating that it's easier to write fast _and_ >> generic code in C++ than in Haskell. >> >> I'd like to submit to the mailing list a very rough proposal >> on how this could be achieved in a pretty straightforward way >> in GHC. >> >> The proposal is meant to be a proof of concept, just to show that >> this could be done rather easily. I did not think about a nice >> interface or the implementation details in GHC. My goal is to >> check the feasibility of this plan with GHC developers. >> >> I'll call such types "macro types", since their effect is similar >> to defining a macro that defines a new type for each type >> variable instantiation. >> >> Consider >> >> ``` >> data #Point a = Point >> { x :: {-# UNPACK #-} !a >> , y :: {-# UNPACK #-} !a >> } >> ``` >> >> This definition defines the macro type `#Point`, with one parameter >> `a`. >> >> Macro types definition would be allowed only for single-constructor >> records. The intent is that if we mention `#Point Double`, it will >> be equivalent to >> >> ``` >> data PointDouble = PointDouble >> { x :: {-# UNPACK #-} !Double >> , y :: {-# UNPACK #-} !Double >> } >> ``` >> >> To use `#Point` generically, the following type class would be >> generated: >> >> ``` >> class PointFamily a where >> data #Point a :: * -- Family of types generated by @data #Point a at . >> #Point :: a -> a -> #Point a -- Constructor. >> #x :: #Point a -> a -- Projection @x at . >> #y :: #Point a -> a -- Projection @y at . >> ``` >> >> Thi type class lets us work with `#Point`s generically, for example >> >> ``` >> distance :: (PointFamily a, Fractional a) => #Point a -> #Point a -> a >> distance p1 p2 = >> let dx = #x p1 - #x p2 >> dy = #y p1 - #y p2 >> in sqrt (dx*dx + dy*dy) >> ``` >> >> Internally, for every type appearing for `a`, e.g. `#Point Double`, >> a new type equivalent to the `PointDouble` above would be generated >> by GHC, with the corresponding instance >> >> ``` >> instance PointFamily Double where >> data #Point Double = PointDouble >> #x = x >> #y = x >> ``` >> >> If it's not possible to instantiate `#Point` with the provided type >> (for example because the type is not `UNPACK`able, e.g. >> `#Point (Maybe A)`), GHC would throw an error. >> >> Note that we can compile `distance` in its polymorphic version >> (as opposed to C++ templates, where template functions _must_ be >> instantiated at every use). The polymorphic `distance` would >> require a call to "virtual functions" `#x` and `#y`, as provided by >> the `PointFamily` dictionary. But if we use >> `INLINE` or `SPECIALIZE` pragmas the virtual calls to `#x` and `#y` >> would disappear, making this as efficient as if we were to define >> `distance` on the manually defined `PointDouble`. Compiler hints >> would be put in place to always inline functions using macro types, >> if possible. >> >> Note that the inlining is only important so that the `PointFamily` >> dictionary disappears, e.g. functions containing recursive >> helpers are fine, such as >> >> ``` >> {-# INLINE leftmost #-} >> leftmost :: forall a. (PointFamily a, Ord a) => [#Point a] -> #Point a >> leftmost [] = error "leftmost: no points" >> leftmost (p0 : ps0) = go p0 ps0 >> where >> go :: #Point a -> [#Point a] -> Point# a >> go candidate (p : ps) = >> if #x p < #x candidate >> then go p ps >> else go candidate ps >> ``` >> >> It might be worth considering throwing a warning when a top-level >> definition whose type contains a macro type cannot be inlined, since >> the main performance benefit of using macro types would be lost. >> >> We can define instances for these types as normal, for instance >> >> ``` >> instance (Show a, PointFamily a) => Show (#Point a) where >> {-# INLINE show #-} >> show pt = "Point{x = " ++ #x pt ++ ", y = " ++ #y pt ++ "}" >> ``` >> >> `deriving` support could also be added. >> >> ## Further ideas >> >> ### Hide or remove `PointFamily` from the user >> >> In the examples above `PointFamily` is manipulated explicitely >> (e.g. in the type signature for `distance`). >> In most cases the right constraint could be generated >> automatically by GHC, although I think direct access to the >> type class would be beneficial (history shows that direct >> access to these facilities is good, see upcoming explicit >> type applications). >> >> Maybe the type class associated to a macro type should not even >> exist -- for example we could simply represent `#Point` as a type >> family and treat construction and destruction as built-in syntax >> (the `#` prefix). >> >> ### Pattern matching >> >> Sugar could be added to pattern match, e.g. >> >> ``` >> foo :: Point# a -> ... >> distance (Point# x1 y1) = ... >> or >> dinstance Point#{..} = ... -- #x and #y are available >> ``` >> >> ### No "record types" limitation >> >> Instead of restricting ourselves to single-constructor records, >> we could simply generate >> >> ``` >> data Point a = Point a >> { x :: !a >> , y :: !a >> } >> >> class PointFamily a where >> data Point# a :: * >> destruct :: Point# a -> Point a >> construct :: Point a -> Point# a >> ``` >> >> However, I think it would be harder to guarantee the well-behavedness >> of the inlined functions if we had this intermediate type. I also >> don't think macro types would be very useful beyond polymorphic >> unboxed types. >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From george.colpitts at gmail.com Mon Nov 16 00:54:22 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Sun, 15 Nov 2015 20:54:22 -0400 Subject: [ANNOUNCE] 7.10.3 release candidate 2 - problems compiling source on Mac OS with clang In-Reply-To: References: Message-ID: I cleaned up my ghc pkg problems by doing rm -fr ~/.ghc/* most packages now compile but hsopenssl still fails in the same way: Building HsOpenSSL-0.11.1.1... Preprocessing library HsOpenSSL-0.11.1.1... In file included from BN.hsc:45: cbits/HsOpenSSL.h:3:10: fatal error: 'openssl/asn1.h' file not found #include ^ 1 error generated. compiling dist/build/OpenSSL/BN_hsc_make.c failed (exit code 1) command was: /usr/bin/gcc -c dist/build/OpenSSL/BN_hsc_make.c -o dist/build/OpenSSL/BN_hsc_make.o -m64 -fno-stack-protector -D__GLASGOW_HASKELL__=710 -Ddarwin_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 -Ddarwin_HOST_OS=1 -Dx86_64_HOST_ARCH=1 -Icbits -D PTHREAD -DCALLCONV=ccall -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -I/Users/gcolpitts/Library/Haskell/ghc-7.10.2.20151105-x86_64/lib/network-2.6.2.1/include -I/usr/local/lib/ghc-7.10.2.20151105/unix_KZL8h98IqDM57kQSPo1mKx/include -I/usr/local/lib/ghc-7.10.2.20151105/time_FTheb6LSxyX1UABIbBXRfn/include -I/usr/local/lib/ghc-7.10.2.20151105/bytes_6VWy06pWzJq9evDvK2d4w6/include -I/usr/local/lib/ghc-7.10.2.20151105/base_HQfYBxpPvuw8OunzQu6JGM/include -I/usr/local/lib/ghc-7.10.2.20151105/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I/usr/local/lib/ghc-7.10.2.20151105/include -I/usr/local/lib/ghc-7.10.2.20151105/include/ On Sun, Nov 15, 2015 at 7:09 PM, George Colpitts wrote: > Yes I have openssl installed > > $ brew upgrade openssl > brew upgrade openssl > Error: openssl 1.0.2d_1 already installed > > Thanks for uploading the new binary install, it definitely solved the > problem I originally reported > > However it doesn't solve the HsOpenSSL problem: > > cabal install HsOpenSSL > cabal install HsOpenSSL > Resolving dependencies... > Configuring HsOpenSSL-0.11.1.1... > Building HsOpenSSL-0.11.1.1... > Failed to install HsOpenSSL-0.11.1.1 > Build log ( /Users/gcolpitts/.cabal/logs/HsOpenSSL-0.11.1.1.log ): > Configuring HsOpenSSL-0.11.1.1... > Building HsOpenSSL-0.11.1.1... > Preprocessing library HsOpenSSL-0.11.1.1... > In file included from BN.hsc:45: > cbits/HsOpenSSL.h:3:10: fatal error: 'openssl/asn1.h' file not found > #include > ^ > 1 error generated. > compiling dist/build/OpenSSL/BN_hsc_make.c failed (exit code 1) > command was: /usr/bin/gcc -c dist/build/OpenSSL/BN_hsc_make.c -o > dist/build/OpenSSL/BN_hsc_make.o -m64 -fno-stack-protector > -D__GLASGOW_HASKELL__=710 -Ddarwin_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 > -Ddarwin_HOST_OS=1 -Dx86_64_HOST_ARCH=1 -Icbits -D PTHREAD -DCALLCONV=ccall > -Idist/build/autogen -include dist/build/autogen/cabal_macros.h > -I/Users/gcolpitts/Library/Haskell/ghc-7.10.2.20151105-x86_64/lib/network-2.6.2.1/include > -I/usr/local/lib/ghc-7.10.2.20151105/unix_KZL8h98IqDM57kQSPo1mKx/include > -I/usr/local/lib/ghc-7.10.2.20151105/time_FTheb6LSxyX1UABIbBXRfn/include > -I/usr/local/lib/ghc-7.10.2.20151105/bytes_6VWy06pWzJq9evDvK2d4w6/include > -I/usr/local/lib/ghc-7.10.2.20151105/base_HQfYBxpPvuw8OunzQu6JGM/include > -I/usr/local/lib/ghc-7.10.2.20151105/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include > -I/usr/local/lib/ghc-7.10.2.20151105/include > -I/usr/local/lib/ghc-7.10.2.20151105/include/ > cabal: Error: some packages failed to install: > HsOpenSSL-0.11.1.1 failed during the building phase. The exception was: > ExitFailure 1 > > However I think I have some problems I need to clean up first. What do I > need to do to get to a clean state wrt existing libraries, i.e. how do I > delete them before installing the latest ghc? > > I think building and installing from source, then installing libraries, > then installing binaries and building more libraries has left me in an > unstable state. > > Thanks > George > > ghc-pkg check > There are problems in package hashtables-1.2.0.2: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > There are problems in package hashable-1.2.3.3: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > dependency "bytestring-0.10.6.0-57aca8b044c60296d333ba9ef7a6b270" > doesn't exist > There are problems in package ghc-events-0.4.4.0: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > dependency "bytestring-0.10.6.0-57aca8b044c60296d333ba9ef7a6b270" > doesn't exist > There are problems in package data-ordlist-0.4.7.0: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > There are problems in package criterion-1.1.0.0: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > dependency "binary-0.7.5.0-77839394dfefc3f030d00790a2cef7fa" doesn't > exist > dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" > doesn't exist > dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" doesn't > exist > dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" doesn't > exist > dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't exist > dependency "time-1.5.0.1-2654f2ea82eb50a9cb76337c0b480079" doesn't exist > There are problems in package statistics-0.13.2.3: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > dependency "binary-0.7.5.0-77839394dfefc3f030d00790a2cef7fa" doesn't > exist > There are problems in package aeson-0.10.0.0: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" > doesn't exist > dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" doesn't > exist > dependency "hashable-1.2.3.3-bc60d08cd07d83826168419244ef8bf3" doesn't > exist > dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't exist > dependency "time-1.5.0.1-2654f2ea82eb50a9cb76337c0b480079" doesn't exist > There are problems in package vector-algorithms-0.7.0.1: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" > doesn't exist > There are problems in package cassava-0.4.4.0: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" > doesn't exist > dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" doesn't > exist > dependency "hashable-1.2.3.3-bc60d08cd07d83826168419244ef8bf3" doesn't > exist > dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't exist > There are problems in package attoparsec-0.13.0.1: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" > doesn't exist > dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" doesn't > exist > dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't exist > There are problems in package monad-par-0.3.4.7: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" doesn't > exist > There are problems in package mwc-random-0.13.3.2: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > dependency "time-1.5.0.1-2654f2ea82eb50a9cb76337c0b480079" doesn't exist > There are problems in package math-functions-0.1.5.2: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > There are problems in package scientific-0.3.4.2: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > dependency "binary-0.7.5.0-77839394dfefc3f030d00790a2cef7fa" doesn't > exist > dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" > doesn't exist > dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" doesn't > exist > dependency "hashable-1.2.3.3-bc60d08cd07d83826168419244ef8bf3" doesn't > exist > dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't exist > There are problems in package vector-th-unbox-0.2.1.3: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > There are problems in package vector-binary-instances-0.2.1.0: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > dependency "binary-0.7.5.0-77839394dfefc3f030d00790a2cef7fa" doesn't > exist > There are problems in package vector-0.11.0.0: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > There are problems in package Glob-0.7.5: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" doesn't > exist > dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" doesn't > exist > There are problems in package monad-par-extras-0.3.3: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > dependency "random-1.1-e88d133272c86b979391f1c08bf5ca07" doesn't exist > There are problems in package parsec-3.1.9: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" > doesn't exist > dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't exist > There are problems in package abstract-deque-0.3: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" doesn't > exist > dependency "random-1.1-e88d133272c86b979391f1c08bf5ca07" doesn't exist > dependency "time-1.5.0.1-2654f2ea82eb50a9cb76337c0b480079" doesn't exist > There are problems in package optparse-applicative-0.12.0.0: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > dependency "process-1.2.3.0-0103d9aa28c4fa0eada355d1840af7ae" doesn't > exist > There are problems in package hastache-0.6.1: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" > doesn't exist > dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" doesn't > exist > dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" doesn't > exist > dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't exist > There are problems in package cereal-0.5.0.0: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" > doesn't exist > dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" doesn't > exist > There are problems in package dlist-0.7.1.2: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > There are problems in package ansi-wl-pprint-0.6.7.3: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > There are problems in package blaze-builder-0.4.0.1: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" > doesn't exist > dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't exist > There are problems in package parallel-3.2.0.6: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" doesn't > exist > There are problems in package transformers-compat-0.4.0.4: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > There are problems in package ieee754-0.7.6: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > There are problems in package abstract-par-0.3.3: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > There are problems in package erf-2.0.0.0: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > There are problems in package hlint-1.9.22: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" doesn't > exist > dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" doesn't > exist > dependency "process-1.2.3.0-0103d9aa28c4fa0eada355d1840af7ae" doesn't > exist > There are problems in package haskell-src-exts-1.16.0.1: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > There are problems in package uniplate-1.6.12: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" doesn't > exist > dependency "hashable-1.2.3.3-bc60d08cd07d83826168419244ef8bf3" doesn't > exist > There are problems in package cpphs-1.19.3: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" doesn't > exist > There are problems in package polyparse-1.11: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" > doesn't exist > dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't exist > There are problems in package unordered-containers-0.2.5.1: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > dependency "hashable-1.2.3.3-bc60d08cd07d83826168419244ef8bf3" doesn't > exist > There are problems in package cmdargs-0.10.13: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > dependency "process-1.2.3.0-0103d9aa28c4fa0eada355d1840af7ae" doesn't > exist > There are problems in package old-time-1.1.0.3: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > There are problems in package hscolour-1.23: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" doesn't > exist > There are problems in package syb-0.6: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > There are problems in package refact-0.3.0.1: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > There are problems in package extra-1.4.2: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" doesn't > exist > dependency "process-1.2.3.0-0103d9aa28c4fa0eada355d1840af7ae" doesn't > exist > dependency "time-1.5.0.1-2654f2ea82eb50a9cb76337c0b480079" doesn't exist > dependency "unix-2.7.1.0-327d00fd34e5d5a1c53223d920b10810" doesn't exist > There are problems in package ansi-terminal-0.6.2.3: > dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist > dependency "unix-2.7.1.0-327d00fd34e5d5a1c53223d920b10810" doesn't exist > > The following packages are broken, either because they have a problem > listed above, or because they depend on a broken package. > hashtables-1.2.0.2 > hashable-1.2.3.3 > ghc-events-0.4.4.0 > data-ordlist-0.4.7.0 > criterion-1.1.0.0 > statistics-0.13.2.3 > aeson-0.10.0.0 > vector-algorithms-0.7.0.1 > cassava-0.4.4.0 > attoparsec-0.13.0.1 > monad-par-0.3.4.7 > mwc-random-0.13.3.2 > math-functions-0.1.5.2 > scientific-0.3.4.2 > vector-th-unbox-0.2.1.3 > vector-binary-instances-0.2.1.0 > vector-0.11.0.0 > Glob-0.7.5 > monad-par-extras-0.3.3 > parsec-3.1.9 > abstract-deque-0.3 > optparse-applicative-0.12.0.0 > hastache-0.6.1 > cereal-0.5.0.0 > dlist-0.7.1.2 > ansi-wl-pprint-0.6.7.3 > blaze-builder-0.4.0.1 > parallel-3.2.0.6 > transformers-compat-0.4.0.4 > ieee754-0.7.6 > abstract-par-0.3.3 > erf-2.0.0.0 > hlint-1.9.22 > haskell-src-exts-1.16.0.1 > uniplate-1.6.12 > cpphs-1.19.3 > polyparse-1.11 > unordered-containers-0.2.5.1 > cmdargs-0.10.13 > old-time-1.1.0.3 > hscolour-1.23 > syb-0.6 > refact-0.3.0.1 > extra-1.4.2 > ansi-terminal-0.6.2.3 > > On Sun, Nov 15, 2015 at 6:14 PM, Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> Did you install OpenSSL ?? >> >> I'll upload my better ghc build in 5 minutes. Did it end of the week and >> then got a bit busy >> >> >> On Sunday, November 15, 2015, George Colpitts >> wrote: >> >>> I did get compiling from source to work on the Mac. Unfortunately I'm >>> not sure what the problem was. >>> >>> I now see a new problem, not sure if it is a ghc problem or a library >>> problem: >>> >>> cabal install HsOpenSSL >>> ... >>> Building HsOpenSSL-0.11.1.1... >>> Preprocessing library HsOpenSSL-0.11.1.1... >>> In file included from BN.hsc:45: >>> cbits/HsOpenSSL.h:3:10: fatal error: 'openssl/asn1.h' file not found >>> #include >>> ^ >>> 1 error generated. >>> compiling dist/build/OpenSSL/BN_hsc_make.c failed (exit code 1) >>> command was: /usr/bin/gcc -c dist/build/OpenSSL/BN_hsc_make.c -o >>> dist/build/OpenSSL/BN_hsc_make.o -m64 -fno-stack-protector >>> -D__GLASGOW_HASKELL__=710 -Ddarwin_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 >>> -Ddarwin_HOST_OS=1 -Dx86_64_HOST_ARCH=1 -Icbits -D PTHREAD -DCALLCONV=ccall >>> -Idist/build/autogen -include dist/build/autogen/cabal_macros.h >>> -I/Users/gcolpitts/Library/Haskell/ghc-7.10.2.20151105-x86_64/lib/network-2.6.2.1/include >>> -I/usr/local/lib/ghc-7.10.2.20151105/unix_KZL8h98IqDM57kQSPo1mKx/include >>> -I/usr/local/lib/ghc-7.10.2.20151105/time_FTheb6LSxyX1UABIbBXRfn/include >>> -I/usr/local/lib/ghc-7.10.2.20151105/bytes_6VWy06pWzJq9evDvK2d4w6/include >>> -I/usr/local/lib/ghc-7.10.2.20151105/base_HQfYBxpPvuw8OunzQu6JGM/include >>> -I/usr/local/lib/ghc-7.10.2.20151105/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include >>> -I/usr/local/lib/ghc-7.10.2.20151105/include >>> -I/usr/local/lib/ghc-7.10.2.20151105/include/ >>> cabal: Error: some packages failed to install: >>> HsOpenSSL-0.11.1.1 failed during the building phase. The exception was: >>> ExitFailure 1 >>> >>> /usr/bin/gcc --version >>> /usr/bin/gcc --version >>> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr >>> --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/c++/4.2.1 >>> Apple LLVM version 7.0.0 (clang-700.1.76) >>> Target: x86_64-apple-darwin15.0.0 >>> Thread model: posix >>> >>> On Mon, Nov 9, 2015 at 10:49 AM, George Colpitts < >>> george.colpitts at gmail.com> wrote: >>> >>>> redid with just make rather than make -j5. I get >>>> >>>> >>>> ... >>>> chmod +x libraries/integer-gmp2/gmp/ln >>>> # Their cmd invocation only works on msys. On cygwin it starts >>>> # a cmd interactive shell. The replacement works in both environments. >>>> mv libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh >>>> libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh.orig >>>> sed 's#cmd //c echo "\$1"#cmd /c "echo $1"#' < >>>> libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh.orig > >>>> libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh >>>> cd libraries/integer-gmp2/gmp; (set -o igncr 2>/dev/null) && set -o >>>> igncr; export SHELLOPTS; \ >>>> PATH=`pwd`:$PATH; \ >>>> export PATH; \ >>>> cd gmpbuild && \ >>>> CC=clang NM=/usr/bin/nm AR=/usr/bin/ar ./configure \ >>>> --enable-shared=no \ >>>> --host=x86_64-apple-darwin --build=x86_64-apple-darwin >>>> /bin/sh: SHELLOPTS: readonly variable >>>> checking build system type... /bin/sh: SHELLOPTS: readonly variable >>>> /bin/sh: SHELLOPTS: readonly variable >>>> x86_64-apple-darwin >>>> checking host system type... /bin/sh: SHELLOPTS: readonly variable >>>> /bin/sh: SHELLOPTS: readonly variable >>>> x86_64-apple-darwin >>>> checking for a BSD-compatible install... /usr/bin/install -c >>>> checking whether build environment is sane... yes >>>> /bin/sh: SHELLOPTS: readonly variable >>>> checking for a thread-safe mkdir -p... ./install-sh -c -d >>>> checking for gawk... no >>>> checking for mawk... no >>>> checking for nawk... no >>>> checking for awk... awk >>>> checking whether make sets $(MAKE)... yes >>>> checking whether to enable maintainer-specific portions of Makefiles... >>>> no >>>> checking ABI=64 >>>> checking whether clang is gcc... yes >>>> checking compiler clang -O2 -pedantic -fPIC -m64 ... no, gnupro alpha >>>> ev6 char spilling >>>> checking ABI=32 >>>> checking whether clang is gcc... yes >>>> *checking compiler clang -m32 -O2 -pedantic -fPIC -fomit-frame-pointer >>>> ... no, gnupro alpha ev6 char spilling* >>>> *checking compiler clang -O2 -pedantic -fPIC -fomit-frame-pointer ... >>>> no, gnupro alpha ev6 char spilling* >>>> *configure: error: could not find a working compiler, see config.log >>>> for details* >>>> *make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1* >>>> *make: *** [all] Error 2* >>>> >>>> >>>> On Mon, Nov 9, 2015 at 9:32 AM, Ben Gamari >>>> wrote: >>>> >>>>> George Colpitts writes: >>>>> >>>>> > I get >>>>> > >>>>> > make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1 >>>>> > make[1]: *** Waiting for unfinished jobs.... >>>>> >>>>> It looks like the build failed somewhere before this point. Could you >>>>> provide a more complete log? >>>>> >>>>> Cheers, >>>>> >>>>> - Ben >>>>> >>>>> >>>>> >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon Nov 16 01:50:34 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 15 Nov 2015 20:50:34 -0500 Subject: [ANNOUNCE] 7.10.3 release candidate 2 - problems compiling source on Mac OS with clang In-Reply-To: References: Message-ID: what does your ghc --info say? On Sun, Nov 15, 2015 at 7:54 PM, George Colpitts wrote: > I cleaned up my ghc pkg problems by doing > > rm -fr ~/.ghc/* > > most packages now compile but hsopenssl still fails in the same way: > > Building HsOpenSSL-0.11.1.1... > Preprocessing library HsOpenSSL-0.11.1.1... > In file included from BN.hsc:45: > cbits/HsOpenSSL.h:3:10: fatal error: 'openssl/asn1.h' file not found > #include > ^ > 1 error generated. > compiling dist/build/OpenSSL/BN_hsc_make.c failed (exit code 1) > command was: /usr/bin/gcc -c dist/build/OpenSSL/BN_hsc_make.c -o > dist/build/OpenSSL/BN_hsc_make.o -m64 -fno-stack-protector > -D__GLASGOW_HASKELL__=710 -Ddarwin_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 > -Ddarwin_HOST_OS=1 -Dx86_64_HOST_ARCH=1 -Icbits -D PTHREAD -DCALLCONV=ccall > -Idist/build/autogen -include dist/build/autogen/cabal_macros.h > -I/Users/gcolpitts/Library/Haskell/ghc-7.10.2.20151105-x86_64/lib/network-2.6.2.1/include > -I/usr/local/lib/ghc-7.10.2.20151105/unix_KZL8h98IqDM57kQSPo1mKx/include > -I/usr/local/lib/ghc-7.10.2.20151105/time_FTheb6LSxyX1UABIbBXRfn/include > -I/usr/local/lib/ghc-7.10.2.20151105/bytes_6VWy06pWzJq9evDvK2d4w6/include > -I/usr/local/lib/ghc-7.10.2.20151105/base_HQfYBxpPvuw8OunzQu6JGM/include > -I/usr/local/lib/ghc-7.10.2.20151105/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include > -I/usr/local/lib/ghc-7.10.2.20151105/include > -I/usr/local/lib/ghc-7.10.2.20151105/include/ > > On Sun, Nov 15, 2015 at 7:09 PM, George Colpitts < > george.colpitts at gmail.com> wrote: > >> Yes I have openssl installed >> >> $ brew upgrade openssl >> brew upgrade openssl >> Error: openssl 1.0.2d_1 already installed >> >> Thanks for uploading the new binary install, it definitely solved the >> problem I originally reported >> >> However it doesn't solve the HsOpenSSL problem: >> >> cabal install HsOpenSSL >> cabal install HsOpenSSL >> Resolving dependencies... >> Configuring HsOpenSSL-0.11.1.1... >> Building HsOpenSSL-0.11.1.1... >> Failed to install HsOpenSSL-0.11.1.1 >> Build log ( /Users/gcolpitts/.cabal/logs/HsOpenSSL-0.11.1.1.log ): >> Configuring HsOpenSSL-0.11.1.1... >> Building HsOpenSSL-0.11.1.1... >> Preprocessing library HsOpenSSL-0.11.1.1... >> In file included from BN.hsc:45: >> cbits/HsOpenSSL.h:3:10: fatal error: 'openssl/asn1.h' file not found >> #include >> ^ >> 1 error generated. >> compiling dist/build/OpenSSL/BN_hsc_make.c failed (exit code 1) >> command was: /usr/bin/gcc -c dist/build/OpenSSL/BN_hsc_make.c -o >> dist/build/OpenSSL/BN_hsc_make.o -m64 -fno-stack-protector >> -D__GLASGOW_HASKELL__=710 -Ddarwin_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 >> -Ddarwin_HOST_OS=1 -Dx86_64_HOST_ARCH=1 -Icbits -D PTHREAD -DCALLCONV=ccall >> -Idist/build/autogen -include dist/build/autogen/cabal_macros.h >> -I/Users/gcolpitts/Library/Haskell/ghc-7.10.2.20151105-x86_64/lib/network-2.6.2.1/include >> -I/usr/local/lib/ghc-7.10.2.20151105/unix_KZL8h98IqDM57kQSPo1mKx/include >> -I/usr/local/lib/ghc-7.10.2.20151105/time_FTheb6LSxyX1UABIbBXRfn/include >> -I/usr/local/lib/ghc-7.10.2.20151105/bytes_6VWy06pWzJq9evDvK2d4w6/include >> -I/usr/local/lib/ghc-7.10.2.20151105/base_HQfYBxpPvuw8OunzQu6JGM/include >> -I/usr/local/lib/ghc-7.10.2.20151105/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include >> -I/usr/local/lib/ghc-7.10.2.20151105/include >> -I/usr/local/lib/ghc-7.10.2.20151105/include/ >> cabal: Error: some packages failed to install: >> HsOpenSSL-0.11.1.1 failed during the building phase. The exception was: >> ExitFailure 1 >> >> However I think I have some problems I need to clean up first. What do I >> need to do to get to a clean state wrt existing libraries, i.e. how do I >> delete them before installing the latest ghc? >> >> I think building and installing from source, then installing libraries, >> then installing binaries and building more libraries has left me in an >> unstable state. >> >> Thanks >> George >> >> ghc-pkg check >> There are problems in package hashtables-1.2.0.2: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> There are problems in package hashable-1.2.3.3: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> dependency "bytestring-0.10.6.0-57aca8b044c60296d333ba9ef7a6b270" >> doesn't exist >> There are problems in package ghc-events-0.4.4.0: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> dependency "bytestring-0.10.6.0-57aca8b044c60296d333ba9ef7a6b270" >> doesn't exist >> There are problems in package data-ordlist-0.4.7.0: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> There are problems in package criterion-1.1.0.0: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> dependency "binary-0.7.5.0-77839394dfefc3f030d00790a2cef7fa" doesn't >> exist >> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >> doesn't exist >> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >> doesn't exist >> dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" doesn't >> exist >> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't exist >> dependency "time-1.5.0.1-2654f2ea82eb50a9cb76337c0b480079" doesn't exist >> There are problems in package statistics-0.13.2.3: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> dependency "binary-0.7.5.0-77839394dfefc3f030d00790a2cef7fa" doesn't >> exist >> There are problems in package aeson-0.10.0.0: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >> doesn't exist >> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >> doesn't exist >> dependency "hashable-1.2.3.3-bc60d08cd07d83826168419244ef8bf3" doesn't >> exist >> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't exist >> dependency "time-1.5.0.1-2654f2ea82eb50a9cb76337c0b480079" doesn't exist >> There are problems in package vector-algorithms-0.7.0.1: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >> doesn't exist >> There are problems in package cassava-0.4.4.0: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >> doesn't exist >> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >> doesn't exist >> dependency "hashable-1.2.3.3-bc60d08cd07d83826168419244ef8bf3" doesn't >> exist >> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't exist >> There are problems in package attoparsec-0.13.0.1: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >> doesn't exist >> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >> doesn't exist >> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't exist >> There are problems in package monad-par-0.3.4.7: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >> doesn't exist >> There are problems in package mwc-random-0.13.3.2: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> dependency "time-1.5.0.1-2654f2ea82eb50a9cb76337c0b480079" doesn't exist >> There are problems in package math-functions-0.1.5.2: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> There are problems in package scientific-0.3.4.2: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> dependency "binary-0.7.5.0-77839394dfefc3f030d00790a2cef7fa" doesn't >> exist >> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >> doesn't exist >> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >> doesn't exist >> dependency "hashable-1.2.3.3-bc60d08cd07d83826168419244ef8bf3" doesn't >> exist >> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't exist >> There are problems in package vector-th-unbox-0.2.1.3: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> There are problems in package vector-binary-instances-0.2.1.0: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> dependency "binary-0.7.5.0-77839394dfefc3f030d00790a2cef7fa" doesn't >> exist >> There are problems in package vector-0.11.0.0: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> There are problems in package Glob-0.7.5: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >> doesn't exist >> dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" doesn't >> exist >> There are problems in package monad-par-extras-0.3.3: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> dependency "random-1.1-e88d133272c86b979391f1c08bf5ca07" doesn't exist >> There are problems in package parsec-3.1.9: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >> doesn't exist >> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't exist >> There are problems in package abstract-deque-0.3: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >> doesn't exist >> dependency "random-1.1-e88d133272c86b979391f1c08bf5ca07" doesn't exist >> dependency "time-1.5.0.1-2654f2ea82eb50a9cb76337c0b480079" doesn't exist >> There are problems in package optparse-applicative-0.12.0.0: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> dependency "process-1.2.3.0-0103d9aa28c4fa0eada355d1840af7ae" doesn't >> exist >> There are problems in package hastache-0.6.1: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >> doesn't exist >> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >> doesn't exist >> dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" doesn't >> exist >> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't exist >> There are problems in package cereal-0.5.0.0: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >> doesn't exist >> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >> doesn't exist >> There are problems in package dlist-0.7.1.2: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> There are problems in package ansi-wl-pprint-0.6.7.3: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> There are problems in package blaze-builder-0.4.0.1: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >> doesn't exist >> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't exist >> There are problems in package parallel-3.2.0.6: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >> doesn't exist >> There are problems in package transformers-compat-0.4.0.4: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> There are problems in package ieee754-0.7.6: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> There are problems in package abstract-par-0.3.3: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> There are problems in package erf-2.0.0.0: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> There are problems in package hlint-1.9.22: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >> doesn't exist >> dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" doesn't >> exist >> dependency "process-1.2.3.0-0103d9aa28c4fa0eada355d1840af7ae" doesn't >> exist >> There are problems in package haskell-src-exts-1.16.0.1: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> There are problems in package uniplate-1.6.12: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >> doesn't exist >> dependency "hashable-1.2.3.3-bc60d08cd07d83826168419244ef8bf3" doesn't >> exist >> There are problems in package cpphs-1.19.3: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" doesn't >> exist >> There are problems in package polyparse-1.11: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >> doesn't exist >> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't exist >> There are problems in package unordered-containers-0.2.5.1: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> dependency "hashable-1.2.3.3-bc60d08cd07d83826168419244ef8bf3" doesn't >> exist >> There are problems in package cmdargs-0.10.13: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> dependency "process-1.2.3.0-0103d9aa28c4fa0eada355d1840af7ae" doesn't >> exist >> There are problems in package old-time-1.1.0.3: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> There are problems in package hscolour-1.23: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >> doesn't exist >> There are problems in package syb-0.6: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> There are problems in package refact-0.3.0.1: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> There are problems in package extra-1.4.2: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" doesn't >> exist >> dependency "process-1.2.3.0-0103d9aa28c4fa0eada355d1840af7ae" doesn't >> exist >> dependency "time-1.5.0.1-2654f2ea82eb50a9cb76337c0b480079" doesn't exist >> dependency "unix-2.7.1.0-327d00fd34e5d5a1c53223d920b10810" doesn't exist >> There are problems in package ansi-terminal-0.6.2.3: >> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't exist >> dependency "unix-2.7.1.0-327d00fd34e5d5a1c53223d920b10810" doesn't exist >> >> The following packages are broken, either because they have a problem >> listed above, or because they depend on a broken package. >> hashtables-1.2.0.2 >> hashable-1.2.3.3 >> ghc-events-0.4.4.0 >> data-ordlist-0.4.7.0 >> criterion-1.1.0.0 >> statistics-0.13.2.3 >> aeson-0.10.0.0 >> vector-algorithms-0.7.0.1 >> cassava-0.4.4.0 >> attoparsec-0.13.0.1 >> monad-par-0.3.4.7 >> mwc-random-0.13.3.2 >> math-functions-0.1.5.2 >> scientific-0.3.4.2 >> vector-th-unbox-0.2.1.3 >> vector-binary-instances-0.2.1.0 >> vector-0.11.0.0 >> Glob-0.7.5 >> monad-par-extras-0.3.3 >> parsec-3.1.9 >> abstract-deque-0.3 >> optparse-applicative-0.12.0.0 >> hastache-0.6.1 >> cereal-0.5.0.0 >> dlist-0.7.1.2 >> ansi-wl-pprint-0.6.7.3 >> blaze-builder-0.4.0.1 >> parallel-3.2.0.6 >> transformers-compat-0.4.0.4 >> ieee754-0.7.6 >> abstract-par-0.3.3 >> erf-2.0.0.0 >> hlint-1.9.22 >> haskell-src-exts-1.16.0.1 >> uniplate-1.6.12 >> cpphs-1.19.3 >> polyparse-1.11 >> unordered-containers-0.2.5.1 >> cmdargs-0.10.13 >> old-time-1.1.0.3 >> hscolour-1.23 >> syb-0.6 >> refact-0.3.0.1 >> extra-1.4.2 >> ansi-terminal-0.6.2.3 >> >> On Sun, Nov 15, 2015 at 6:14 PM, Carter Schonwald < >> carter.schonwald at gmail.com> wrote: >> >>> Did you install OpenSSL ?? >>> >>> I'll upload my better ghc build in 5 minutes. Did it end of the week >>> and then got a bit busy >>> >>> >>> On Sunday, November 15, 2015, George Colpitts >>> wrote: >>> >>>> I did get compiling from source to work on the Mac. Unfortunately I'm >>>> not sure what the problem was. >>>> >>>> I now see a new problem, not sure if it is a ghc problem or a library >>>> problem: >>>> >>>> cabal install HsOpenSSL >>>> ... >>>> Building HsOpenSSL-0.11.1.1... >>>> Preprocessing library HsOpenSSL-0.11.1.1... >>>> In file included from BN.hsc:45: >>>> cbits/HsOpenSSL.h:3:10: fatal error: 'openssl/asn1.h' file not found >>>> #include >>>> ^ >>>> 1 error generated. >>>> compiling dist/build/OpenSSL/BN_hsc_make.c failed (exit code 1) >>>> command was: /usr/bin/gcc -c dist/build/OpenSSL/BN_hsc_make.c -o >>>> dist/build/OpenSSL/BN_hsc_make.o -m64 -fno-stack-protector >>>> -D__GLASGOW_HASKELL__=710 -Ddarwin_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 >>>> -Ddarwin_HOST_OS=1 -Dx86_64_HOST_ARCH=1 -Icbits -D PTHREAD -DCALLCONV=ccall >>>> -Idist/build/autogen -include dist/build/autogen/cabal_macros.h >>>> -I/Users/gcolpitts/Library/Haskell/ghc-7.10.2.20151105-x86_64/lib/network-2.6.2.1/include >>>> -I/usr/local/lib/ghc-7.10.2.20151105/unix_KZL8h98IqDM57kQSPo1mKx/include >>>> -I/usr/local/lib/ghc-7.10.2.20151105/time_FTheb6LSxyX1UABIbBXRfn/include >>>> -I/usr/local/lib/ghc-7.10.2.20151105/bytes_6VWy06pWzJq9evDvK2d4w6/include >>>> -I/usr/local/lib/ghc-7.10.2.20151105/base_HQfYBxpPvuw8OunzQu6JGM/include >>>> -I/usr/local/lib/ghc-7.10.2.20151105/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include >>>> -I/usr/local/lib/ghc-7.10.2.20151105/include >>>> -I/usr/local/lib/ghc-7.10.2.20151105/include/ >>>> cabal: Error: some packages failed to install: >>>> HsOpenSSL-0.11.1.1 failed during the building phase. The exception was: >>>> ExitFailure 1 >>>> >>>> /usr/bin/gcc --version >>>> /usr/bin/gcc --version >>>> Configured with: >>>> --prefix=/Applications/Xcode.app/Contents/Developer/usr >>>> --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/c++/4.2.1 >>>> Apple LLVM version 7.0.0 (clang-700.1.76) >>>> Target: x86_64-apple-darwin15.0.0 >>>> Thread model: posix >>>> >>>> On Mon, Nov 9, 2015 at 10:49 AM, George Colpitts < >>>> george.colpitts at gmail.com> wrote: >>>> >>>>> redid with just make rather than make -j5. I get >>>>> >>>>> >>>>> ... >>>>> chmod +x libraries/integer-gmp2/gmp/ln >>>>> # Their cmd invocation only works on msys. On cygwin it starts >>>>> # a cmd interactive shell. The replacement works in both environments. >>>>> mv libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh >>>>> libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh.orig >>>>> sed 's#cmd //c echo "\$1"#cmd /c "echo $1"#' < >>>>> libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh.orig > >>>>> libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh >>>>> cd libraries/integer-gmp2/gmp; (set -o igncr 2>/dev/null) && set -o >>>>> igncr; export SHELLOPTS; \ >>>>> PATH=`pwd`:$PATH; \ >>>>> export PATH; \ >>>>> cd gmpbuild && \ >>>>> CC=clang NM=/usr/bin/nm AR=/usr/bin/ar ./configure \ >>>>> --enable-shared=no \ >>>>> --host=x86_64-apple-darwin --build=x86_64-apple-darwin >>>>> /bin/sh: SHELLOPTS: readonly variable >>>>> checking build system type... /bin/sh: SHELLOPTS: readonly variable >>>>> /bin/sh: SHELLOPTS: readonly variable >>>>> x86_64-apple-darwin >>>>> checking host system type... /bin/sh: SHELLOPTS: readonly variable >>>>> /bin/sh: SHELLOPTS: readonly variable >>>>> x86_64-apple-darwin >>>>> checking for a BSD-compatible install... /usr/bin/install -c >>>>> checking whether build environment is sane... yes >>>>> /bin/sh: SHELLOPTS: readonly variable >>>>> checking for a thread-safe mkdir -p... ./install-sh -c -d >>>>> checking for gawk... no >>>>> checking for mawk... no >>>>> checking for nawk... no >>>>> checking for awk... awk >>>>> checking whether make sets $(MAKE)... yes >>>>> checking whether to enable maintainer-specific portions of >>>>> Makefiles... no >>>>> checking ABI=64 >>>>> checking whether clang is gcc... yes >>>>> checking compiler clang -O2 -pedantic -fPIC -m64 ... no, gnupro alpha >>>>> ev6 char spilling >>>>> checking ABI=32 >>>>> checking whether clang is gcc... yes >>>>> *checking compiler clang -m32 -O2 -pedantic -fPIC -fomit-frame-pointer >>>>> ... no, gnupro alpha ev6 char spilling* >>>>> *checking compiler clang -O2 -pedantic -fPIC -fomit-frame-pointer ... >>>>> no, gnupro alpha ev6 char spilling* >>>>> *configure: error: could not find a working compiler, see config.log >>>>> for details* >>>>> *make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1* >>>>> *make: *** [all] Error 2* >>>>> >>>>> >>>>> On Mon, Nov 9, 2015 at 9:32 AM, Ben Gamari >>>>> wrote: >>>>> >>>>>> George Colpitts writes: >>>>>> >>>>>> > I get >>>>>> > >>>>>> > make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1 >>>>>> > make[1]: *** Waiting for unfinished jobs.... >>>>>> >>>>>> It looks like the build failed somewhere before this point. Could you >>>>>> provide a more complete log? >>>>>> >>>>>> Cheers, >>>>>> >>>>>> - Ben >>>>>> >>>>>> >>>>>> >>>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon Nov 16 01:50:53 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 15 Nov 2015 20:50:53 -0500 Subject: [ANNOUNCE] 7.10.3 release candidate 2 - problems compiling source on Mac OS with clang In-Reply-To: References: Message-ID: did you do configure before make install or not? On Sun, Nov 15, 2015 at 8:50 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > what does your ghc --info say? > > On Sun, Nov 15, 2015 at 7:54 PM, George Colpitts < > george.colpitts at gmail.com> wrote: > >> I cleaned up my ghc pkg problems by doing >> >> rm -fr ~/.ghc/* >> >> most packages now compile but hsopenssl still fails in the same way: >> >> Building HsOpenSSL-0.11.1.1... >> Preprocessing library HsOpenSSL-0.11.1.1... >> In file included from BN.hsc:45: >> cbits/HsOpenSSL.h:3:10: fatal error: 'openssl/asn1.h' file not found >> #include >> ^ >> 1 error generated. >> compiling dist/build/OpenSSL/BN_hsc_make.c failed (exit code 1) >> command was: /usr/bin/gcc -c dist/build/OpenSSL/BN_hsc_make.c -o >> dist/build/OpenSSL/BN_hsc_make.o -m64 -fno-stack-protector >> -D__GLASGOW_HASKELL__=710 -Ddarwin_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 >> -Ddarwin_HOST_OS=1 -Dx86_64_HOST_ARCH=1 -Icbits -D PTHREAD -DCALLCONV=ccall >> -Idist/build/autogen -include dist/build/autogen/cabal_macros.h >> -I/Users/gcolpitts/Library/Haskell/ghc-7.10.2.20151105-x86_64/lib/network-2.6.2.1/include >> -I/usr/local/lib/ghc-7.10.2.20151105/unix_KZL8h98IqDM57kQSPo1mKx/include >> -I/usr/local/lib/ghc-7.10.2.20151105/time_FTheb6LSxyX1UABIbBXRfn/include >> -I/usr/local/lib/ghc-7.10.2.20151105/bytes_6VWy06pWzJq9evDvK2d4w6/include >> -I/usr/local/lib/ghc-7.10.2.20151105/base_HQfYBxpPvuw8OunzQu6JGM/include >> -I/usr/local/lib/ghc-7.10.2.20151105/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include >> -I/usr/local/lib/ghc-7.10.2.20151105/include >> -I/usr/local/lib/ghc-7.10.2.20151105/include/ >> >> On Sun, Nov 15, 2015 at 7:09 PM, George Colpitts < >> george.colpitts at gmail.com> wrote: >> >>> Yes I have openssl installed >>> >>> $ brew upgrade openssl >>> brew upgrade openssl >>> Error: openssl 1.0.2d_1 already installed >>> >>> Thanks for uploading the new binary install, it definitely solved the >>> problem I originally reported >>> >>> However it doesn't solve the HsOpenSSL problem: >>> >>> cabal install HsOpenSSL >>> cabal install HsOpenSSL >>> Resolving dependencies... >>> Configuring HsOpenSSL-0.11.1.1... >>> Building HsOpenSSL-0.11.1.1... >>> Failed to install HsOpenSSL-0.11.1.1 >>> Build log ( /Users/gcolpitts/.cabal/logs/HsOpenSSL-0.11.1.1.log ): >>> Configuring HsOpenSSL-0.11.1.1... >>> Building HsOpenSSL-0.11.1.1... >>> Preprocessing library HsOpenSSL-0.11.1.1... >>> In file included from BN.hsc:45: >>> cbits/HsOpenSSL.h:3:10: fatal error: 'openssl/asn1.h' file not found >>> #include >>> ^ >>> 1 error generated. >>> compiling dist/build/OpenSSL/BN_hsc_make.c failed (exit code 1) >>> command was: /usr/bin/gcc -c dist/build/OpenSSL/BN_hsc_make.c -o >>> dist/build/OpenSSL/BN_hsc_make.o -m64 -fno-stack-protector >>> -D__GLASGOW_HASKELL__=710 -Ddarwin_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 >>> -Ddarwin_HOST_OS=1 -Dx86_64_HOST_ARCH=1 -Icbits -D PTHREAD -DCALLCONV=ccall >>> -Idist/build/autogen -include dist/build/autogen/cabal_macros.h >>> -I/Users/gcolpitts/Library/Haskell/ghc-7.10.2.20151105-x86_64/lib/network-2.6.2.1/include >>> -I/usr/local/lib/ghc-7.10.2.20151105/unix_KZL8h98IqDM57kQSPo1mKx/include >>> -I/usr/local/lib/ghc-7.10.2.20151105/time_FTheb6LSxyX1UABIbBXRfn/include >>> -I/usr/local/lib/ghc-7.10.2.20151105/bytes_6VWy06pWzJq9evDvK2d4w6/include >>> -I/usr/local/lib/ghc-7.10.2.20151105/base_HQfYBxpPvuw8OunzQu6JGM/include >>> -I/usr/local/lib/ghc-7.10.2.20151105/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include >>> -I/usr/local/lib/ghc-7.10.2.20151105/include >>> -I/usr/local/lib/ghc-7.10.2.20151105/include/ >>> cabal: Error: some packages failed to install: >>> HsOpenSSL-0.11.1.1 failed during the building phase. The exception was: >>> ExitFailure 1 >>> >>> However I think I have some problems I need to clean up first. What do I >>> need to do to get to a clean state wrt existing libraries, i.e. how do I >>> delete them before installing the latest ghc? >>> >>> I think building and installing from source, then installing libraries, >>> then installing binaries and building more libraries has left me in an >>> unstable state. >>> >>> Thanks >>> George >>> >>> ghc-pkg check >>> There are problems in package hashtables-1.2.0.2: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> There are problems in package hashable-1.2.3.3: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "bytestring-0.10.6.0-57aca8b044c60296d333ba9ef7a6b270" >>> doesn't exist >>> There are problems in package ghc-events-0.4.4.0: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "bytestring-0.10.6.0-57aca8b044c60296d333ba9ef7a6b270" >>> doesn't exist >>> There are problems in package data-ordlist-0.4.7.0: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> There are problems in package criterion-1.1.0.0: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "binary-0.7.5.0-77839394dfefc3f030d00790a2cef7fa" doesn't >>> exist >>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>> doesn't exist >>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>> doesn't exist >>> dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" >>> doesn't exist >>> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't >>> exist >>> dependency "time-1.5.0.1-2654f2ea82eb50a9cb76337c0b480079" doesn't >>> exist >>> There are problems in package statistics-0.13.2.3: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "binary-0.7.5.0-77839394dfefc3f030d00790a2cef7fa" doesn't >>> exist >>> There are problems in package aeson-0.10.0.0: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>> doesn't exist >>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>> doesn't exist >>> dependency "hashable-1.2.3.3-bc60d08cd07d83826168419244ef8bf3" doesn't >>> exist >>> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't >>> exist >>> dependency "time-1.5.0.1-2654f2ea82eb50a9cb76337c0b480079" doesn't >>> exist >>> There are problems in package vector-algorithms-0.7.0.1: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>> doesn't exist >>> There are problems in package cassava-0.4.4.0: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>> doesn't exist >>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>> doesn't exist >>> dependency "hashable-1.2.3.3-bc60d08cd07d83826168419244ef8bf3" doesn't >>> exist >>> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't >>> exist >>> There are problems in package attoparsec-0.13.0.1: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>> doesn't exist >>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>> doesn't exist >>> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't >>> exist >>> There are problems in package monad-par-0.3.4.7: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>> doesn't exist >>> There are problems in package mwc-random-0.13.3.2: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "time-1.5.0.1-2654f2ea82eb50a9cb76337c0b480079" doesn't >>> exist >>> There are problems in package math-functions-0.1.5.2: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> There are problems in package scientific-0.3.4.2: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "binary-0.7.5.0-77839394dfefc3f030d00790a2cef7fa" doesn't >>> exist >>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>> doesn't exist >>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>> doesn't exist >>> dependency "hashable-1.2.3.3-bc60d08cd07d83826168419244ef8bf3" doesn't >>> exist >>> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't >>> exist >>> There are problems in package vector-th-unbox-0.2.1.3: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> There are problems in package vector-binary-instances-0.2.1.0: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "binary-0.7.5.0-77839394dfefc3f030d00790a2cef7fa" doesn't >>> exist >>> There are problems in package vector-0.11.0.0: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> There are problems in package Glob-0.7.5: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>> doesn't exist >>> dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" >>> doesn't exist >>> There are problems in package monad-par-extras-0.3.3: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "random-1.1-e88d133272c86b979391f1c08bf5ca07" doesn't exist >>> There are problems in package parsec-3.1.9: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>> doesn't exist >>> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't >>> exist >>> There are problems in package abstract-deque-0.3: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>> doesn't exist >>> dependency "random-1.1-e88d133272c86b979391f1c08bf5ca07" doesn't exist >>> dependency "time-1.5.0.1-2654f2ea82eb50a9cb76337c0b480079" doesn't >>> exist >>> There are problems in package optparse-applicative-0.12.0.0: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "process-1.2.3.0-0103d9aa28c4fa0eada355d1840af7ae" doesn't >>> exist >>> There are problems in package hastache-0.6.1: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>> doesn't exist >>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>> doesn't exist >>> dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" >>> doesn't exist >>> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't >>> exist >>> There are problems in package cereal-0.5.0.0: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>> doesn't exist >>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>> doesn't exist >>> There are problems in package dlist-0.7.1.2: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> There are problems in package ansi-wl-pprint-0.6.7.3: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> There are problems in package blaze-builder-0.4.0.1: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>> doesn't exist >>> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't >>> exist >>> There are problems in package parallel-3.2.0.6: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>> doesn't exist >>> There are problems in package transformers-compat-0.4.0.4: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> There are problems in package ieee754-0.7.6: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> There are problems in package abstract-par-0.3.3: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> There are problems in package erf-2.0.0.0: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> There are problems in package hlint-1.9.22: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>> doesn't exist >>> dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" >>> doesn't exist >>> dependency "process-1.2.3.0-0103d9aa28c4fa0eada355d1840af7ae" doesn't >>> exist >>> There are problems in package haskell-src-exts-1.16.0.1: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> There are problems in package uniplate-1.6.12: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>> doesn't exist >>> dependency "hashable-1.2.3.3-bc60d08cd07d83826168419244ef8bf3" doesn't >>> exist >>> There are problems in package cpphs-1.19.3: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" >>> doesn't exist >>> There are problems in package polyparse-1.11: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>> doesn't exist >>> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't >>> exist >>> There are problems in package unordered-containers-0.2.5.1: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "hashable-1.2.3.3-bc60d08cd07d83826168419244ef8bf3" doesn't >>> exist >>> There are problems in package cmdargs-0.10.13: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "process-1.2.3.0-0103d9aa28c4fa0eada355d1840af7ae" doesn't >>> exist >>> There are problems in package old-time-1.1.0.3: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> There are problems in package hscolour-1.23: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>> doesn't exist >>> There are problems in package syb-0.6: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> There are problems in package refact-0.3.0.1: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> There are problems in package extra-1.4.2: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" >>> doesn't exist >>> dependency "process-1.2.3.0-0103d9aa28c4fa0eada355d1840af7ae" doesn't >>> exist >>> dependency "time-1.5.0.1-2654f2ea82eb50a9cb76337c0b480079" doesn't >>> exist >>> dependency "unix-2.7.1.0-327d00fd34e5d5a1c53223d920b10810" doesn't >>> exist >>> There are problems in package ansi-terminal-0.6.2.3: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "unix-2.7.1.0-327d00fd34e5d5a1c53223d920b10810" doesn't >>> exist >>> >>> The following packages are broken, either because they have a problem >>> listed above, or because they depend on a broken package. >>> hashtables-1.2.0.2 >>> hashable-1.2.3.3 >>> ghc-events-0.4.4.0 >>> data-ordlist-0.4.7.0 >>> criterion-1.1.0.0 >>> statistics-0.13.2.3 >>> aeson-0.10.0.0 >>> vector-algorithms-0.7.0.1 >>> cassava-0.4.4.0 >>> attoparsec-0.13.0.1 >>> monad-par-0.3.4.7 >>> mwc-random-0.13.3.2 >>> math-functions-0.1.5.2 >>> scientific-0.3.4.2 >>> vector-th-unbox-0.2.1.3 >>> vector-binary-instances-0.2.1.0 >>> vector-0.11.0.0 >>> Glob-0.7.5 >>> monad-par-extras-0.3.3 >>> parsec-3.1.9 >>> abstract-deque-0.3 >>> optparse-applicative-0.12.0.0 >>> hastache-0.6.1 >>> cereal-0.5.0.0 >>> dlist-0.7.1.2 >>> ansi-wl-pprint-0.6.7.3 >>> blaze-builder-0.4.0.1 >>> parallel-3.2.0.6 >>> transformers-compat-0.4.0.4 >>> ieee754-0.7.6 >>> abstract-par-0.3.3 >>> erf-2.0.0.0 >>> hlint-1.9.22 >>> haskell-src-exts-1.16.0.1 >>> uniplate-1.6.12 >>> cpphs-1.19.3 >>> polyparse-1.11 >>> unordered-containers-0.2.5.1 >>> cmdargs-0.10.13 >>> old-time-1.1.0.3 >>> hscolour-1.23 >>> syb-0.6 >>> refact-0.3.0.1 >>> extra-1.4.2 >>> ansi-terminal-0.6.2.3 >>> >>> On Sun, Nov 15, 2015 at 6:14 PM, Carter Schonwald < >>> carter.schonwald at gmail.com> wrote: >>> >>>> Did you install OpenSSL ?? >>>> >>>> I'll upload my better ghc build in 5 minutes. Did it end of the week >>>> and then got a bit busy >>>> >>>> >>>> On Sunday, November 15, 2015, George Colpitts < >>>> george.colpitts at gmail.com> wrote: >>>> >>>>> I did get compiling from source to work on the Mac. Unfortunately I'm >>>>> not sure what the problem was. >>>>> >>>>> I now see a new problem, not sure if it is a ghc problem or a library >>>>> problem: >>>>> >>>>> cabal install HsOpenSSL >>>>> ... >>>>> Building HsOpenSSL-0.11.1.1... >>>>> Preprocessing library HsOpenSSL-0.11.1.1... >>>>> In file included from BN.hsc:45: >>>>> cbits/HsOpenSSL.h:3:10: fatal error: 'openssl/asn1.h' file not found >>>>> #include >>>>> ^ >>>>> 1 error generated. >>>>> compiling dist/build/OpenSSL/BN_hsc_make.c failed (exit code 1) >>>>> command was: /usr/bin/gcc -c dist/build/OpenSSL/BN_hsc_make.c -o >>>>> dist/build/OpenSSL/BN_hsc_make.o -m64 -fno-stack-protector >>>>> -D__GLASGOW_HASKELL__=710 -Ddarwin_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 >>>>> -Ddarwin_HOST_OS=1 -Dx86_64_HOST_ARCH=1 -Icbits -D PTHREAD -DCALLCONV=ccall >>>>> -Idist/build/autogen -include dist/build/autogen/cabal_macros.h >>>>> -I/Users/gcolpitts/Library/Haskell/ghc-7.10.2.20151105-x86_64/lib/network-2.6.2.1/include >>>>> -I/usr/local/lib/ghc-7.10.2.20151105/unix_KZL8h98IqDM57kQSPo1mKx/include >>>>> -I/usr/local/lib/ghc-7.10.2.20151105/time_FTheb6LSxyX1UABIbBXRfn/include >>>>> -I/usr/local/lib/ghc-7.10.2.20151105/bytes_6VWy06pWzJq9evDvK2d4w6/include >>>>> -I/usr/local/lib/ghc-7.10.2.20151105/base_HQfYBxpPvuw8OunzQu6JGM/include >>>>> -I/usr/local/lib/ghc-7.10.2.20151105/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include >>>>> -I/usr/local/lib/ghc-7.10.2.20151105/include >>>>> -I/usr/local/lib/ghc-7.10.2.20151105/include/ >>>>> cabal: Error: some packages failed to install: >>>>> HsOpenSSL-0.11.1.1 failed during the building phase. The exception was: >>>>> ExitFailure 1 >>>>> >>>>> /usr/bin/gcc --version >>>>> /usr/bin/gcc --version >>>>> Configured with: >>>>> --prefix=/Applications/Xcode.app/Contents/Developer/usr >>>>> --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/c++/4.2.1 >>>>> Apple LLVM version 7.0.0 (clang-700.1.76) >>>>> Target: x86_64-apple-darwin15.0.0 >>>>> Thread model: posix >>>>> >>>>> On Mon, Nov 9, 2015 at 10:49 AM, George Colpitts < >>>>> george.colpitts at gmail.com> wrote: >>>>> >>>>>> redid with just make rather than make -j5. I get >>>>>> >>>>>> >>>>>> ... >>>>>> chmod +x libraries/integer-gmp2/gmp/ln >>>>>> # Their cmd invocation only works on msys. On cygwin it starts >>>>>> # a cmd interactive shell. The replacement works in both environments. >>>>>> mv libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh >>>>>> libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh.orig >>>>>> sed 's#cmd //c echo "\$1"#cmd /c "echo $1"#' < >>>>>> libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh.orig > >>>>>> libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh >>>>>> cd libraries/integer-gmp2/gmp; (set -o igncr 2>/dev/null) && set -o >>>>>> igncr; export SHELLOPTS; \ >>>>>> PATH=`pwd`:$PATH; \ >>>>>> export PATH; \ >>>>>> cd gmpbuild && \ >>>>>> CC=clang NM=/usr/bin/nm AR=/usr/bin/ar ./configure \ >>>>>> --enable-shared=no \ >>>>>> --host=x86_64-apple-darwin --build=x86_64-apple-darwin >>>>>> /bin/sh: SHELLOPTS: readonly variable >>>>>> checking build system type... /bin/sh: SHELLOPTS: readonly variable >>>>>> /bin/sh: SHELLOPTS: readonly variable >>>>>> x86_64-apple-darwin >>>>>> checking host system type... /bin/sh: SHELLOPTS: readonly variable >>>>>> /bin/sh: SHELLOPTS: readonly variable >>>>>> x86_64-apple-darwin >>>>>> checking for a BSD-compatible install... /usr/bin/install -c >>>>>> checking whether build environment is sane... yes >>>>>> /bin/sh: SHELLOPTS: readonly variable >>>>>> checking for a thread-safe mkdir -p... ./install-sh -c -d >>>>>> checking for gawk... no >>>>>> checking for mawk... no >>>>>> checking for nawk... no >>>>>> checking for awk... awk >>>>>> checking whether make sets $(MAKE)... yes >>>>>> checking whether to enable maintainer-specific portions of >>>>>> Makefiles... no >>>>>> checking ABI=64 >>>>>> checking whether clang is gcc... yes >>>>>> checking compiler clang -O2 -pedantic -fPIC -m64 ... no, gnupro alpha >>>>>> ev6 char spilling >>>>>> checking ABI=32 >>>>>> checking whether clang is gcc... yes >>>>>> *checking compiler clang -m32 -O2 -pedantic -fPIC >>>>>> -fomit-frame-pointer ... no, gnupro alpha ev6 char spilling* >>>>>> *checking compiler clang -O2 -pedantic -fPIC -fomit-frame-pointer ... >>>>>> no, gnupro alpha ev6 char spilling* >>>>>> *configure: error: could not find a working compiler, see config.log >>>>>> for details* >>>>>> *make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1* >>>>>> *make: *** [all] Error 2* >>>>>> >>>>>> >>>>>> On Mon, Nov 9, 2015 at 9:32 AM, Ben Gamari >>>>>> wrote: >>>>>> >>>>>>> George Colpitts writes: >>>>>>> >>>>>>> > I get >>>>>>> > >>>>>>> > make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1 >>>>>>> > make[1]: *** Waiting for unfinished jobs.... >>>>>>> >>>>>>> It looks like the build failed somewhere before this point. Could you >>>>>>> provide a more complete log? >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> - Ben >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Mon Nov 16 01:52:29 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Sun, 15 Nov 2015 21:52:29 -0400 Subject: [ANNOUNCE] 7.10.3 release candidate 2 - problems compiling source on Mac OS with clang In-Reply-To: References: Message-ID: ghc --info ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","/usr/bin/gcc") ,("C compiler flags"," -m64 -fno-stack-protector") ,("C compiler link flags"," -m64") ,("Haskell CPP command","/usr/bin/gcc") ,("Haskell CPP flags","-E -undef -traditional -Wno-invalid-pp-token -Wno-unicode -Wno-trigraphs ") ,("ld command","/usr/bin/ld") ,("ld flags"," -arch x86_64") ,("ld supports compact unwind","YES") ,("ld supports build-id","NO") ,("ld supports filelist","YES") ,("ld is GNU ld","NO") ,("ar command","/usr/bin/ar") ,("ar flags","clqs") ,("ar supports at file","NO") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("readelf command","") ,("perl command","/usr/bin/perl") ,("cross compiling","NO") ,("target os","OSDarwin") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","True") ,("Unregisterised","NO") ,("LLVM llc command","/usr/local/bin/llc-3.5") ,("LLVM opt command","/usr/local/bin/opt-3.5") ,("Project version","7.10.2.20151105") ,("Project Git commit id","7f8fc1c9db5bef2dea05e001488d5bc7c8b38575") ,("Booter version","7.10.2") ,("Stage","2") ,("Build platform","x86_64-apple-darwin") ,("Host platform","x86_64-apple-darwin") ,("Target platform","x86_64-apple-darwin") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Support reexported-modules","YES") ,("Support thinning and renaming package flags","YES") ,("Uses package keys","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("Leading underscore","YES") ,("Debug on","False") ,("LibDir","/usr/local/lib/ghc-7.10.2.20151105") ,("Global Package DB","/usr/local/lib/ghc-7.10.2.20151105/package.conf.d") ] On Sun, Nov 15, 2015 at 9:50 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > what does your ghc --info say? > > On Sun, Nov 15, 2015 at 7:54 PM, George Colpitts < > george.colpitts at gmail.com> wrote: > >> I cleaned up my ghc pkg problems by doing >> >> rm -fr ~/.ghc/* >> >> most packages now compile but hsopenssl still fails in the same way: >> >> Building HsOpenSSL-0.11.1.1... >> Preprocessing library HsOpenSSL-0.11.1.1... >> In file included from BN.hsc:45: >> cbits/HsOpenSSL.h:3:10: fatal error: 'openssl/asn1.h' file not found >> #include >> ^ >> 1 error generated. >> compiling dist/build/OpenSSL/BN_hsc_make.c failed (exit code 1) >> command was: /usr/bin/gcc -c dist/build/OpenSSL/BN_hsc_make.c -o >> dist/build/OpenSSL/BN_hsc_make.o -m64 -fno-stack-protector >> -D__GLASGOW_HASKELL__=710 -Ddarwin_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 >> -Ddarwin_HOST_OS=1 -Dx86_64_HOST_ARCH=1 -Icbits -D PTHREAD -DCALLCONV=ccall >> -Idist/build/autogen -include dist/build/autogen/cabal_macros.h >> -I/Users/gcolpitts/Library/Haskell/ghc-7.10.2.20151105-x86_64/lib/network-2.6.2.1/include >> -I/usr/local/lib/ghc-7.10.2.20151105/unix_KZL8h98IqDM57kQSPo1mKx/include >> -I/usr/local/lib/ghc-7.10.2.20151105/time_FTheb6LSxyX1UABIbBXRfn/include >> -I/usr/local/lib/ghc-7.10.2.20151105/bytes_6VWy06pWzJq9evDvK2d4w6/include >> -I/usr/local/lib/ghc-7.10.2.20151105/base_HQfYBxpPvuw8OunzQu6JGM/include >> -I/usr/local/lib/ghc-7.10.2.20151105/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include >> -I/usr/local/lib/ghc-7.10.2.20151105/include >> -I/usr/local/lib/ghc-7.10.2.20151105/include/ >> >> On Sun, Nov 15, 2015 at 7:09 PM, George Colpitts < >> george.colpitts at gmail.com> wrote: >> >>> Yes I have openssl installed >>> >>> $ brew upgrade openssl >>> brew upgrade openssl >>> Error: openssl 1.0.2d_1 already installed >>> >>> Thanks for uploading the new binary install, it definitely solved the >>> problem I originally reported >>> >>> However it doesn't solve the HsOpenSSL problem: >>> >>> cabal install HsOpenSSL >>> cabal install HsOpenSSL >>> Resolving dependencies... >>> Configuring HsOpenSSL-0.11.1.1... >>> Building HsOpenSSL-0.11.1.1... >>> Failed to install HsOpenSSL-0.11.1.1 >>> Build log ( /Users/gcolpitts/.cabal/logs/HsOpenSSL-0.11.1.1.log ): >>> Configuring HsOpenSSL-0.11.1.1... >>> Building HsOpenSSL-0.11.1.1... >>> Preprocessing library HsOpenSSL-0.11.1.1... >>> In file included from BN.hsc:45: >>> cbits/HsOpenSSL.h:3:10: fatal error: 'openssl/asn1.h' file not found >>> #include >>> ^ >>> 1 error generated. >>> compiling dist/build/OpenSSL/BN_hsc_make.c failed (exit code 1) >>> command was: /usr/bin/gcc -c dist/build/OpenSSL/BN_hsc_make.c -o >>> dist/build/OpenSSL/BN_hsc_make.o -m64 -fno-stack-protector >>> -D__GLASGOW_HASKELL__=710 -Ddarwin_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 >>> -Ddarwin_HOST_OS=1 -Dx86_64_HOST_ARCH=1 -Icbits -D PTHREAD -DCALLCONV=ccall >>> -Idist/build/autogen -include dist/build/autogen/cabal_macros.h >>> -I/Users/gcolpitts/Library/Haskell/ghc-7.10.2.20151105-x86_64/lib/network-2.6.2.1/include >>> -I/usr/local/lib/ghc-7.10.2.20151105/unix_KZL8h98IqDM57kQSPo1mKx/include >>> -I/usr/local/lib/ghc-7.10.2.20151105/time_FTheb6LSxyX1UABIbBXRfn/include >>> -I/usr/local/lib/ghc-7.10.2.20151105/bytes_6VWy06pWzJq9evDvK2d4w6/include >>> -I/usr/local/lib/ghc-7.10.2.20151105/base_HQfYBxpPvuw8OunzQu6JGM/include >>> -I/usr/local/lib/ghc-7.10.2.20151105/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include >>> -I/usr/local/lib/ghc-7.10.2.20151105/include >>> -I/usr/local/lib/ghc-7.10.2.20151105/include/ >>> cabal: Error: some packages failed to install: >>> HsOpenSSL-0.11.1.1 failed during the building phase. The exception was: >>> ExitFailure 1 >>> >>> However I think I have some problems I need to clean up first. What do I >>> need to do to get to a clean state wrt existing libraries, i.e. how do I >>> delete them before installing the latest ghc? >>> >>> I think building and installing from source, then installing libraries, >>> then installing binaries and building more libraries has left me in an >>> unstable state. >>> >>> Thanks >>> George >>> >>> ghc-pkg check >>> There are problems in package hashtables-1.2.0.2: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> There are problems in package hashable-1.2.3.3: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "bytestring-0.10.6.0-57aca8b044c60296d333ba9ef7a6b270" >>> doesn't exist >>> There are problems in package ghc-events-0.4.4.0: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "bytestring-0.10.6.0-57aca8b044c60296d333ba9ef7a6b270" >>> doesn't exist >>> There are problems in package data-ordlist-0.4.7.0: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> There are problems in package criterion-1.1.0.0: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "binary-0.7.5.0-77839394dfefc3f030d00790a2cef7fa" doesn't >>> exist >>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>> doesn't exist >>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>> doesn't exist >>> dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" >>> doesn't exist >>> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't >>> exist >>> dependency "time-1.5.0.1-2654f2ea82eb50a9cb76337c0b480079" doesn't >>> exist >>> There are problems in package statistics-0.13.2.3: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "binary-0.7.5.0-77839394dfefc3f030d00790a2cef7fa" doesn't >>> exist >>> There are problems in package aeson-0.10.0.0: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>> doesn't exist >>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>> doesn't exist >>> dependency "hashable-1.2.3.3-bc60d08cd07d83826168419244ef8bf3" doesn't >>> exist >>> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't >>> exist >>> dependency "time-1.5.0.1-2654f2ea82eb50a9cb76337c0b480079" doesn't >>> exist >>> There are problems in package vector-algorithms-0.7.0.1: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>> doesn't exist >>> There are problems in package cassava-0.4.4.0: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>> doesn't exist >>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>> doesn't exist >>> dependency "hashable-1.2.3.3-bc60d08cd07d83826168419244ef8bf3" doesn't >>> exist >>> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't >>> exist >>> There are problems in package attoparsec-0.13.0.1: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>> doesn't exist >>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>> doesn't exist >>> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't >>> exist >>> There are problems in package monad-par-0.3.4.7: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>> doesn't exist >>> There are problems in package mwc-random-0.13.3.2: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "time-1.5.0.1-2654f2ea82eb50a9cb76337c0b480079" doesn't >>> exist >>> There are problems in package math-functions-0.1.5.2: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> There are problems in package scientific-0.3.4.2: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "binary-0.7.5.0-77839394dfefc3f030d00790a2cef7fa" doesn't >>> exist >>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>> doesn't exist >>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>> doesn't exist >>> dependency "hashable-1.2.3.3-bc60d08cd07d83826168419244ef8bf3" doesn't >>> exist >>> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't >>> exist >>> There are problems in package vector-th-unbox-0.2.1.3: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> There are problems in package vector-binary-instances-0.2.1.0: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "binary-0.7.5.0-77839394dfefc3f030d00790a2cef7fa" doesn't >>> exist >>> There are problems in package vector-0.11.0.0: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> There are problems in package Glob-0.7.5: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>> doesn't exist >>> dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" >>> doesn't exist >>> There are problems in package monad-par-extras-0.3.3: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "random-1.1-e88d133272c86b979391f1c08bf5ca07" doesn't exist >>> There are problems in package parsec-3.1.9: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>> doesn't exist >>> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't >>> exist >>> There are problems in package abstract-deque-0.3: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>> doesn't exist >>> dependency "random-1.1-e88d133272c86b979391f1c08bf5ca07" doesn't exist >>> dependency "time-1.5.0.1-2654f2ea82eb50a9cb76337c0b480079" doesn't >>> exist >>> There are problems in package optparse-applicative-0.12.0.0: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "process-1.2.3.0-0103d9aa28c4fa0eada355d1840af7ae" doesn't >>> exist >>> There are problems in package hastache-0.6.1: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>> doesn't exist >>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>> doesn't exist >>> dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" >>> doesn't exist >>> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't >>> exist >>> There are problems in package cereal-0.5.0.0: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>> doesn't exist >>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>> doesn't exist >>> There are problems in package dlist-0.7.1.2: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> There are problems in package ansi-wl-pprint-0.6.7.3: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> There are problems in package blaze-builder-0.4.0.1: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>> doesn't exist >>> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't >>> exist >>> There are problems in package parallel-3.2.0.6: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>> doesn't exist >>> There are problems in package transformers-compat-0.4.0.4: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> There are problems in package ieee754-0.7.6: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> There are problems in package abstract-par-0.3.3: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> There are problems in package erf-2.0.0.0: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> There are problems in package hlint-1.9.22: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>> doesn't exist >>> dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" >>> doesn't exist >>> dependency "process-1.2.3.0-0103d9aa28c4fa0eada355d1840af7ae" doesn't >>> exist >>> There are problems in package haskell-src-exts-1.16.0.1: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> There are problems in package uniplate-1.6.12: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>> doesn't exist >>> dependency "hashable-1.2.3.3-bc60d08cd07d83826168419244ef8bf3" doesn't >>> exist >>> There are problems in package cpphs-1.19.3: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" >>> doesn't exist >>> There are problems in package polyparse-1.11: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>> doesn't exist >>> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't >>> exist >>> There are problems in package unordered-containers-0.2.5.1: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "hashable-1.2.3.3-bc60d08cd07d83826168419244ef8bf3" doesn't >>> exist >>> There are problems in package cmdargs-0.10.13: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "process-1.2.3.0-0103d9aa28c4fa0eada355d1840af7ae" doesn't >>> exist >>> There are problems in package old-time-1.1.0.3: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> There are problems in package hscolour-1.23: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>> doesn't exist >>> There are problems in package syb-0.6: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> There are problems in package refact-0.3.0.1: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> There are problems in package extra-1.4.2: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" >>> doesn't exist >>> dependency "process-1.2.3.0-0103d9aa28c4fa0eada355d1840af7ae" doesn't >>> exist >>> dependency "time-1.5.0.1-2654f2ea82eb50a9cb76337c0b480079" doesn't >>> exist >>> dependency "unix-2.7.1.0-327d00fd34e5d5a1c53223d920b10810" doesn't >>> exist >>> There are problems in package ansi-terminal-0.6.2.3: >>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>> exist >>> dependency "unix-2.7.1.0-327d00fd34e5d5a1c53223d920b10810" doesn't >>> exist >>> >>> The following packages are broken, either because they have a problem >>> listed above, or because they depend on a broken package. >>> hashtables-1.2.0.2 >>> hashable-1.2.3.3 >>> ghc-events-0.4.4.0 >>> data-ordlist-0.4.7.0 >>> criterion-1.1.0.0 >>> statistics-0.13.2.3 >>> aeson-0.10.0.0 >>> vector-algorithms-0.7.0.1 >>> cassava-0.4.4.0 >>> attoparsec-0.13.0.1 >>> monad-par-0.3.4.7 >>> mwc-random-0.13.3.2 >>> math-functions-0.1.5.2 >>> scientific-0.3.4.2 >>> vector-th-unbox-0.2.1.3 >>> vector-binary-instances-0.2.1.0 >>> vector-0.11.0.0 >>> Glob-0.7.5 >>> monad-par-extras-0.3.3 >>> parsec-3.1.9 >>> abstract-deque-0.3 >>> optparse-applicative-0.12.0.0 >>> hastache-0.6.1 >>> cereal-0.5.0.0 >>> dlist-0.7.1.2 >>> ansi-wl-pprint-0.6.7.3 >>> blaze-builder-0.4.0.1 >>> parallel-3.2.0.6 >>> transformers-compat-0.4.0.4 >>> ieee754-0.7.6 >>> abstract-par-0.3.3 >>> erf-2.0.0.0 >>> hlint-1.9.22 >>> haskell-src-exts-1.16.0.1 >>> uniplate-1.6.12 >>> cpphs-1.19.3 >>> polyparse-1.11 >>> unordered-containers-0.2.5.1 >>> cmdargs-0.10.13 >>> old-time-1.1.0.3 >>> hscolour-1.23 >>> syb-0.6 >>> refact-0.3.0.1 >>> extra-1.4.2 >>> ansi-terminal-0.6.2.3 >>> >>> On Sun, Nov 15, 2015 at 6:14 PM, Carter Schonwald < >>> carter.schonwald at gmail.com> wrote: >>> >>>> Did you install OpenSSL ?? >>>> >>>> I'll upload my better ghc build in 5 minutes. Did it end of the week >>>> and then got a bit busy >>>> >>>> >>>> On Sunday, November 15, 2015, George Colpitts < >>>> george.colpitts at gmail.com> wrote: >>>> >>>>> I did get compiling from source to work on the Mac. Unfortunately I'm >>>>> not sure what the problem was. >>>>> >>>>> I now see a new problem, not sure if it is a ghc problem or a library >>>>> problem: >>>>> >>>>> cabal install HsOpenSSL >>>>> ... >>>>> Building HsOpenSSL-0.11.1.1... >>>>> Preprocessing library HsOpenSSL-0.11.1.1... >>>>> In file included from BN.hsc:45: >>>>> cbits/HsOpenSSL.h:3:10: fatal error: 'openssl/asn1.h' file not found >>>>> #include >>>>> ^ >>>>> 1 error generated. >>>>> compiling dist/build/OpenSSL/BN_hsc_make.c failed (exit code 1) >>>>> command was: /usr/bin/gcc -c dist/build/OpenSSL/BN_hsc_make.c -o >>>>> dist/build/OpenSSL/BN_hsc_make.o -m64 -fno-stack-protector >>>>> -D__GLASGOW_HASKELL__=710 -Ddarwin_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 >>>>> -Ddarwin_HOST_OS=1 -Dx86_64_HOST_ARCH=1 -Icbits -D PTHREAD -DCALLCONV=ccall >>>>> -Idist/build/autogen -include dist/build/autogen/cabal_macros.h >>>>> -I/Users/gcolpitts/Library/Haskell/ghc-7.10.2.20151105-x86_64/lib/network-2.6.2.1/include >>>>> -I/usr/local/lib/ghc-7.10.2.20151105/unix_KZL8h98IqDM57kQSPo1mKx/include >>>>> -I/usr/local/lib/ghc-7.10.2.20151105/time_FTheb6LSxyX1UABIbBXRfn/include >>>>> -I/usr/local/lib/ghc-7.10.2.20151105/bytes_6VWy06pWzJq9evDvK2d4w6/include >>>>> -I/usr/local/lib/ghc-7.10.2.20151105/base_HQfYBxpPvuw8OunzQu6JGM/include >>>>> -I/usr/local/lib/ghc-7.10.2.20151105/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include >>>>> -I/usr/local/lib/ghc-7.10.2.20151105/include >>>>> -I/usr/local/lib/ghc-7.10.2.20151105/include/ >>>>> cabal: Error: some packages failed to install: >>>>> HsOpenSSL-0.11.1.1 failed during the building phase. The exception was: >>>>> ExitFailure 1 >>>>> >>>>> /usr/bin/gcc --version >>>>> /usr/bin/gcc --version >>>>> Configured with: >>>>> --prefix=/Applications/Xcode.app/Contents/Developer/usr >>>>> --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/c++/4.2.1 >>>>> Apple LLVM version 7.0.0 (clang-700.1.76) >>>>> Target: x86_64-apple-darwin15.0.0 >>>>> Thread model: posix >>>>> >>>>> On Mon, Nov 9, 2015 at 10:49 AM, George Colpitts < >>>>> george.colpitts at gmail.com> wrote: >>>>> >>>>>> redid with just make rather than make -j5. I get >>>>>> >>>>>> >>>>>> ... >>>>>> chmod +x libraries/integer-gmp2/gmp/ln >>>>>> # Their cmd invocation only works on msys. On cygwin it starts >>>>>> # a cmd interactive shell. The replacement works in both environments. >>>>>> mv libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh >>>>>> libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh.orig >>>>>> sed 's#cmd //c echo "\$1"#cmd /c "echo $1"#' < >>>>>> libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh.orig > >>>>>> libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh >>>>>> cd libraries/integer-gmp2/gmp; (set -o igncr 2>/dev/null) && set -o >>>>>> igncr; export SHELLOPTS; \ >>>>>> PATH=`pwd`:$PATH; \ >>>>>> export PATH; \ >>>>>> cd gmpbuild && \ >>>>>> CC=clang NM=/usr/bin/nm AR=/usr/bin/ar ./configure \ >>>>>> --enable-shared=no \ >>>>>> --host=x86_64-apple-darwin --build=x86_64-apple-darwin >>>>>> /bin/sh: SHELLOPTS: readonly variable >>>>>> checking build system type... /bin/sh: SHELLOPTS: readonly variable >>>>>> /bin/sh: SHELLOPTS: readonly variable >>>>>> x86_64-apple-darwin >>>>>> checking host system type... /bin/sh: SHELLOPTS: readonly variable >>>>>> /bin/sh: SHELLOPTS: readonly variable >>>>>> x86_64-apple-darwin >>>>>> checking for a BSD-compatible install... /usr/bin/install -c >>>>>> checking whether build environment is sane... yes >>>>>> /bin/sh: SHELLOPTS: readonly variable >>>>>> checking for a thread-safe mkdir -p... ./install-sh -c -d >>>>>> checking for gawk... no >>>>>> checking for mawk... no >>>>>> checking for nawk... no >>>>>> checking for awk... awk >>>>>> checking whether make sets $(MAKE)... yes >>>>>> checking whether to enable maintainer-specific portions of >>>>>> Makefiles... no >>>>>> checking ABI=64 >>>>>> checking whether clang is gcc... yes >>>>>> checking compiler clang -O2 -pedantic -fPIC -m64 ... no, gnupro alpha >>>>>> ev6 char spilling >>>>>> checking ABI=32 >>>>>> checking whether clang is gcc... yes >>>>>> *checking compiler clang -m32 -O2 -pedantic -fPIC >>>>>> -fomit-frame-pointer ... no, gnupro alpha ev6 char spilling* >>>>>> *checking compiler clang -O2 -pedantic -fPIC -fomit-frame-pointer ... >>>>>> no, gnupro alpha ev6 char spilling* >>>>>> *configure: error: could not find a working compiler, see config.log >>>>>> for details* >>>>>> *make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1* >>>>>> *make: *** [all] Error 2* >>>>>> >>>>>> >>>>>> On Mon, Nov 9, 2015 at 9:32 AM, Ben Gamari >>>>>> wrote: >>>>>> >>>>>>> George Colpitts writes: >>>>>>> >>>>>>> > I get >>>>>>> > >>>>>>> > make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1 >>>>>>> > make[1]: *** Waiting for unfinished jobs.... >>>>>>> >>>>>>> It looks like the build failed somewhere before this point. Could you >>>>>>> provide a more complete log? >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> - Ben >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Mon Nov 16 01:53:07 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Sun, 15 Nov 2015 21:53:07 -0400 Subject: [ANNOUNCE] 7.10.3 release candidate 2 - problems compiling source on Mac OS with clang In-Reply-To: References: Message-ID: inline On Sun, Nov 15, 2015 at 9:50 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > did you do configure before make install or not? > > ?yes? > On Sun, Nov 15, 2015 at 8:50 PM, Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> what does your ghc --info say? >> >> On Sun, Nov 15, 2015 at 7:54 PM, George Colpitts < >> george.colpitts at gmail.com> wrote: >> >>> I cleaned up my ghc pkg problems by doing >>> >>> rm -fr ~/.ghc/* >>> >>> most packages now compile but hsopenssl still fails in the same way: >>> >>> Building HsOpenSSL-0.11.1.1... >>> Preprocessing library HsOpenSSL-0.11.1.1... >>> In file included from BN.hsc:45: >>> cbits/HsOpenSSL.h:3:10: fatal error: 'openssl/asn1.h' file not found >>> #include >>> ^ >>> 1 error generated. >>> compiling dist/build/OpenSSL/BN_hsc_make.c failed (exit code 1) >>> command was: /usr/bin/gcc -c dist/build/OpenSSL/BN_hsc_make.c -o >>> dist/build/OpenSSL/BN_hsc_make.o -m64 -fno-stack-protector >>> -D__GLASGOW_HASKELL__=710 -Ddarwin_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 >>> -Ddarwin_HOST_OS=1 -Dx86_64_HOST_ARCH=1 -Icbits -D PTHREAD -DCALLCONV=ccall >>> -Idist/build/autogen -include dist/build/autogen/cabal_macros.h >>> -I/Users/gcolpitts/Library/Haskell/ghc-7.10.2.20151105-x86_64/lib/network-2.6.2.1/include >>> -I/usr/local/lib/ghc-7.10.2.20151105/unix_KZL8h98IqDM57kQSPo1mKx/include >>> -I/usr/local/lib/ghc-7.10.2.20151105/time_FTheb6LSxyX1UABIbBXRfn/include >>> -I/usr/local/lib/ghc-7.10.2.20151105/bytes_6VWy06pWzJq9evDvK2d4w6/include >>> -I/usr/local/lib/ghc-7.10.2.20151105/base_HQfYBxpPvuw8OunzQu6JGM/include >>> -I/usr/local/lib/ghc-7.10.2.20151105/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include >>> -I/usr/local/lib/ghc-7.10.2.20151105/include >>> -I/usr/local/lib/ghc-7.10.2.20151105/include/ >>> >>> On Sun, Nov 15, 2015 at 7:09 PM, George Colpitts < >>> george.colpitts at gmail.com> wrote: >>> >>>> Yes I have openssl installed >>>> >>>> $ brew upgrade openssl >>>> brew upgrade openssl >>>> Error: openssl 1.0.2d_1 already installed >>>> >>>> Thanks for uploading the new binary install, it definitely solved the >>>> problem I originally reported >>>> >>>> However it doesn't solve the HsOpenSSL problem: >>>> >>>> cabal install HsOpenSSL >>>> cabal install HsOpenSSL >>>> Resolving dependencies... >>>> Configuring HsOpenSSL-0.11.1.1... >>>> Building HsOpenSSL-0.11.1.1... >>>> Failed to install HsOpenSSL-0.11.1.1 >>>> Build log ( /Users/gcolpitts/.cabal/logs/HsOpenSSL-0.11.1.1.log ): >>>> Configuring HsOpenSSL-0.11.1.1... >>>> Building HsOpenSSL-0.11.1.1... >>>> Preprocessing library HsOpenSSL-0.11.1.1... >>>> In file included from BN.hsc:45: >>>> cbits/HsOpenSSL.h:3:10: fatal error: 'openssl/asn1.h' file not found >>>> #include >>>> ^ >>>> 1 error generated. >>>> compiling dist/build/OpenSSL/BN_hsc_make.c failed (exit code 1) >>>> command was: /usr/bin/gcc -c dist/build/OpenSSL/BN_hsc_make.c -o >>>> dist/build/OpenSSL/BN_hsc_make.o -m64 -fno-stack-protector >>>> -D__GLASGOW_HASKELL__=710 -Ddarwin_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 >>>> -Ddarwin_HOST_OS=1 -Dx86_64_HOST_ARCH=1 -Icbits -D PTHREAD -DCALLCONV=ccall >>>> -Idist/build/autogen -include dist/build/autogen/cabal_macros.h >>>> -I/Users/gcolpitts/Library/Haskell/ghc-7.10.2.20151105-x86_64/lib/network-2.6.2.1/include >>>> -I/usr/local/lib/ghc-7.10.2.20151105/unix_KZL8h98IqDM57kQSPo1mKx/include >>>> -I/usr/local/lib/ghc-7.10.2.20151105/time_FTheb6LSxyX1UABIbBXRfn/include >>>> -I/usr/local/lib/ghc-7.10.2.20151105/bytes_6VWy06pWzJq9evDvK2d4w6/include >>>> -I/usr/local/lib/ghc-7.10.2.20151105/base_HQfYBxpPvuw8OunzQu6JGM/include >>>> -I/usr/local/lib/ghc-7.10.2.20151105/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include >>>> -I/usr/local/lib/ghc-7.10.2.20151105/include >>>> -I/usr/local/lib/ghc-7.10.2.20151105/include/ >>>> cabal: Error: some packages failed to install: >>>> HsOpenSSL-0.11.1.1 failed during the building phase. The exception was: >>>> ExitFailure 1 >>>> >>>> However I think I have some problems I need to clean up first. What do >>>> I need to do to get to a clean state wrt existing libraries, i.e. how do I >>>> delete them before installing the latest ghc? >>>> >>>> I think building and installing from source, then installing libraries, >>>> then installing binaries and building more libraries has left me in an >>>> unstable state. >>>> >>>> Thanks >>>> George >>>> >>>> ghc-pkg check >>>> There are problems in package hashtables-1.2.0.2: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> There are problems in package hashable-1.2.3.3: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> dependency "bytestring-0.10.6.0-57aca8b044c60296d333ba9ef7a6b270" >>>> doesn't exist >>>> There are problems in package ghc-events-0.4.4.0: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> dependency "bytestring-0.10.6.0-57aca8b044c60296d333ba9ef7a6b270" >>>> doesn't exist >>>> There are problems in package data-ordlist-0.4.7.0: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> There are problems in package criterion-1.1.0.0: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> dependency "binary-0.7.5.0-77839394dfefc3f030d00790a2cef7fa" doesn't >>>> exist >>>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>>> doesn't exist >>>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>>> doesn't exist >>>> dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" >>>> doesn't exist >>>> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't >>>> exist >>>> dependency "time-1.5.0.1-2654f2ea82eb50a9cb76337c0b480079" doesn't >>>> exist >>>> There are problems in package statistics-0.13.2.3: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> dependency "binary-0.7.5.0-77839394dfefc3f030d00790a2cef7fa" doesn't >>>> exist >>>> There are problems in package aeson-0.10.0.0: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>>> doesn't exist >>>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>>> doesn't exist >>>> dependency "hashable-1.2.3.3-bc60d08cd07d83826168419244ef8bf3" >>>> doesn't exist >>>> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't >>>> exist >>>> dependency "time-1.5.0.1-2654f2ea82eb50a9cb76337c0b480079" doesn't >>>> exist >>>> There are problems in package vector-algorithms-0.7.0.1: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>>> doesn't exist >>>> There are problems in package cassava-0.4.4.0: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>>> doesn't exist >>>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>>> doesn't exist >>>> dependency "hashable-1.2.3.3-bc60d08cd07d83826168419244ef8bf3" >>>> doesn't exist >>>> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't >>>> exist >>>> There are problems in package attoparsec-0.13.0.1: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>>> doesn't exist >>>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>>> doesn't exist >>>> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't >>>> exist >>>> There are problems in package monad-par-0.3.4.7: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>>> doesn't exist >>>> There are problems in package mwc-random-0.13.3.2: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> dependency "time-1.5.0.1-2654f2ea82eb50a9cb76337c0b480079" doesn't >>>> exist >>>> There are problems in package math-functions-0.1.5.2: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> There are problems in package scientific-0.3.4.2: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> dependency "binary-0.7.5.0-77839394dfefc3f030d00790a2cef7fa" doesn't >>>> exist >>>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>>> doesn't exist >>>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>>> doesn't exist >>>> dependency "hashable-1.2.3.3-bc60d08cd07d83826168419244ef8bf3" >>>> doesn't exist >>>> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't >>>> exist >>>> There are problems in package vector-th-unbox-0.2.1.3: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> There are problems in package vector-binary-instances-0.2.1.0: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> dependency "binary-0.7.5.0-77839394dfefc3f030d00790a2cef7fa" doesn't >>>> exist >>>> There are problems in package vector-0.11.0.0: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> There are problems in package Glob-0.7.5: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>>> doesn't exist >>>> dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" >>>> doesn't exist >>>> There are problems in package monad-par-extras-0.3.3: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> dependency "random-1.1-e88d133272c86b979391f1c08bf5ca07" doesn't exist >>>> There are problems in package parsec-3.1.9: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>>> doesn't exist >>>> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't >>>> exist >>>> There are problems in package abstract-deque-0.3: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>>> doesn't exist >>>> dependency "random-1.1-e88d133272c86b979391f1c08bf5ca07" doesn't exist >>>> dependency "time-1.5.0.1-2654f2ea82eb50a9cb76337c0b480079" doesn't >>>> exist >>>> There are problems in package optparse-applicative-0.12.0.0: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> dependency "process-1.2.3.0-0103d9aa28c4fa0eada355d1840af7ae" doesn't >>>> exist >>>> There are problems in package hastache-0.6.1: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>>> doesn't exist >>>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>>> doesn't exist >>>> dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" >>>> doesn't exist >>>> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't >>>> exist >>>> There are problems in package cereal-0.5.0.0: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>>> doesn't exist >>>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>>> doesn't exist >>>> There are problems in package dlist-0.7.1.2: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> There are problems in package ansi-wl-pprint-0.6.7.3: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> There are problems in package blaze-builder-0.4.0.1: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>>> doesn't exist >>>> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't >>>> exist >>>> There are problems in package parallel-3.2.0.6: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>>> doesn't exist >>>> There are problems in package transformers-compat-0.4.0.4: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> There are problems in package ieee754-0.7.6: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> There are problems in package abstract-par-0.3.3: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> There are problems in package erf-2.0.0.0: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> There are problems in package hlint-1.9.22: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>>> doesn't exist >>>> dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" >>>> doesn't exist >>>> dependency "process-1.2.3.0-0103d9aa28c4fa0eada355d1840af7ae" doesn't >>>> exist >>>> There are problems in package haskell-src-exts-1.16.0.1: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> There are problems in package uniplate-1.6.12: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>>> doesn't exist >>>> dependency "hashable-1.2.3.3-bc60d08cd07d83826168419244ef8bf3" >>>> doesn't exist >>>> There are problems in package cpphs-1.19.3: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" >>>> doesn't exist >>>> There are problems in package polyparse-1.11: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> dependency "bytestring-0.10.6.0-09b6bde4572288cdbf02e4115ed5cd91" >>>> doesn't exist >>>> dependency "text-1.2.1.3-4c78ad7426ae4be055d28adf31eabdf8" doesn't >>>> exist >>>> There are problems in package unordered-containers-0.2.5.1: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> dependency "hashable-1.2.3.3-bc60d08cd07d83826168419244ef8bf3" >>>> doesn't exist >>>> There are problems in package cmdargs-0.10.13: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> dependency "process-1.2.3.0-0103d9aa28c4fa0eada355d1840af7ae" doesn't >>>> exist >>>> There are problems in package old-time-1.1.0.3: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> There are problems in package hscolour-1.23: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> dependency "containers-0.5.6.2-12e20ec15ed50c37491ff947fa0f9c1a" >>>> doesn't exist >>>> There are problems in package syb-0.6: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> There are problems in package refact-0.3.0.1: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> There are problems in package extra-1.4.2: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> dependency "directory-1.2.2.0-6be4b069bff3ad3d34e43f79a1d2adaf" >>>> doesn't exist >>>> dependency "process-1.2.3.0-0103d9aa28c4fa0eada355d1840af7ae" doesn't >>>> exist >>>> dependency "time-1.5.0.1-2654f2ea82eb50a9cb76337c0b480079" doesn't >>>> exist >>>> dependency "unix-2.7.1.0-327d00fd34e5d5a1c53223d920b10810" doesn't >>>> exist >>>> There are problems in package ansi-terminal-0.6.2.3: >>>> dependency "base-4.8.2.0-950f36cacffcd4ead0c487bd275e50bd" doesn't >>>> exist >>>> dependency "unix-2.7.1.0-327d00fd34e5d5a1c53223d920b10810" doesn't >>>> exist >>>> >>>> The following packages are broken, either because they have a problem >>>> listed above, or because they depend on a broken package. >>>> hashtables-1.2.0.2 >>>> hashable-1.2.3.3 >>>> ghc-events-0.4.4.0 >>>> data-ordlist-0.4.7.0 >>>> criterion-1.1.0.0 >>>> statistics-0.13.2.3 >>>> aeson-0.10.0.0 >>>> vector-algorithms-0.7.0.1 >>>> cassava-0.4.4.0 >>>> attoparsec-0.13.0.1 >>>> monad-par-0.3.4.7 >>>> mwc-random-0.13.3.2 >>>> math-functions-0.1.5.2 >>>> scientific-0.3.4.2 >>>> vector-th-unbox-0.2.1.3 >>>> vector-binary-instances-0.2.1.0 >>>> vector-0.11.0.0 >>>> Glob-0.7.5 >>>> monad-par-extras-0.3.3 >>>> parsec-3.1.9 >>>> abstract-deque-0.3 >>>> optparse-applicative-0.12.0.0 >>>> hastache-0.6.1 >>>> cereal-0.5.0.0 >>>> dlist-0.7.1.2 >>>> ansi-wl-pprint-0.6.7.3 >>>> blaze-builder-0.4.0.1 >>>> parallel-3.2.0.6 >>>> transformers-compat-0.4.0.4 >>>> ieee754-0.7.6 >>>> abstract-par-0.3.3 >>>> erf-2.0.0.0 >>>> hlint-1.9.22 >>>> haskell-src-exts-1.16.0.1 >>>> uniplate-1.6.12 >>>> cpphs-1.19.3 >>>> polyparse-1.11 >>>> unordered-containers-0.2.5.1 >>>> cmdargs-0.10.13 >>>> old-time-1.1.0.3 >>>> hscolour-1.23 >>>> syb-0.6 >>>> refact-0.3.0.1 >>>> extra-1.4.2 >>>> ansi-terminal-0.6.2.3 >>>> >>>> On Sun, Nov 15, 2015 at 6:14 PM, Carter Schonwald < >>>> carter.schonwald at gmail.com> wrote: >>>> >>>>> Did you install OpenSSL ?? >>>>> >>>>> I'll upload my better ghc build in 5 minutes. Did it end of the week >>>>> and then got a bit busy >>>>> >>>>> >>>>> On Sunday, November 15, 2015, George Colpitts < >>>>> george.colpitts at gmail.com> wrote: >>>>> >>>>>> I did get compiling from source to work on the Mac. Unfortunately I'm >>>>>> not sure what the problem was. >>>>>> >>>>>> I now see a new problem, not sure if it is a ghc problem or a library >>>>>> problem: >>>>>> >>>>>> cabal install HsOpenSSL >>>>>> ... >>>>>> Building HsOpenSSL-0.11.1.1... >>>>>> Preprocessing library HsOpenSSL-0.11.1.1... >>>>>> In file included from BN.hsc:45: >>>>>> cbits/HsOpenSSL.h:3:10: fatal error: 'openssl/asn1.h' file not found >>>>>> #include >>>>>> ^ >>>>>> 1 error generated. >>>>>> compiling dist/build/OpenSSL/BN_hsc_make.c failed (exit code 1) >>>>>> command was: /usr/bin/gcc -c dist/build/OpenSSL/BN_hsc_make.c -o >>>>>> dist/build/OpenSSL/BN_hsc_make.o -m64 -fno-stack-protector >>>>>> -D__GLASGOW_HASKELL__=710 -Ddarwin_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 >>>>>> -Ddarwin_HOST_OS=1 -Dx86_64_HOST_ARCH=1 -Icbits -D PTHREAD -DCALLCONV=ccall >>>>>> -Idist/build/autogen -include dist/build/autogen/cabal_macros.h >>>>>> -I/Users/gcolpitts/Library/Haskell/ghc-7.10.2.20151105-x86_64/lib/network-2.6.2.1/include >>>>>> -I/usr/local/lib/ghc-7.10.2.20151105/unix_KZL8h98IqDM57kQSPo1mKx/include >>>>>> -I/usr/local/lib/ghc-7.10.2.20151105/time_FTheb6LSxyX1UABIbBXRfn/include >>>>>> -I/usr/local/lib/ghc-7.10.2.20151105/bytes_6VWy06pWzJq9evDvK2d4w6/include >>>>>> -I/usr/local/lib/ghc-7.10.2.20151105/base_HQfYBxpPvuw8OunzQu6JGM/include >>>>>> -I/usr/local/lib/ghc-7.10.2.20151105/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include >>>>>> -I/usr/local/lib/ghc-7.10.2.20151105/include >>>>>> -I/usr/local/lib/ghc-7.10.2.20151105/include/ >>>>>> cabal: Error: some packages failed to install: >>>>>> HsOpenSSL-0.11.1.1 failed during the building phase. The exception >>>>>> was: >>>>>> ExitFailure 1 >>>>>> >>>>>> /usr/bin/gcc --version >>>>>> /usr/bin/gcc --version >>>>>> Configured with: >>>>>> --prefix=/Applications/Xcode.app/Contents/Developer/usr >>>>>> --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/c++/4.2.1 >>>>>> Apple LLVM version 7.0.0 (clang-700.1.76) >>>>>> Target: x86_64-apple-darwin15.0.0 >>>>>> Thread model: posix >>>>>> >>>>>> On Mon, Nov 9, 2015 at 10:49 AM, George Colpitts < >>>>>> george.colpitts at gmail.com> wrote: >>>>>> >>>>>>> redid with just make rather than make -j5. I get >>>>>>> >>>>>>> >>>>>>> ... >>>>>>> chmod +x libraries/integer-gmp2/gmp/ln >>>>>>> # Their cmd invocation only works on msys. On cygwin it starts >>>>>>> # a cmd interactive shell. The replacement works in both >>>>>>> environments. >>>>>>> mv libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh >>>>>>> libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh.orig >>>>>>> sed 's#cmd //c echo "\$1"#cmd /c "echo $1"#' < >>>>>>> libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh.orig > >>>>>>> libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh >>>>>>> cd libraries/integer-gmp2/gmp; (set -o igncr 2>/dev/null) && set -o >>>>>>> igncr; export SHELLOPTS; \ >>>>>>> PATH=`pwd`:$PATH; \ >>>>>>> export PATH; \ >>>>>>> cd gmpbuild && \ >>>>>>> CC=clang NM=/usr/bin/nm AR=/usr/bin/ar ./configure \ >>>>>>> --enable-shared=no \ >>>>>>> --host=x86_64-apple-darwin --build=x86_64-apple-darwin >>>>>>> /bin/sh: SHELLOPTS: readonly variable >>>>>>> checking build system type... /bin/sh: SHELLOPTS: readonly variable >>>>>>> /bin/sh: SHELLOPTS: readonly variable >>>>>>> x86_64-apple-darwin >>>>>>> checking host system type... /bin/sh: SHELLOPTS: readonly variable >>>>>>> /bin/sh: SHELLOPTS: readonly variable >>>>>>> x86_64-apple-darwin >>>>>>> checking for a BSD-compatible install... /usr/bin/install -c >>>>>>> checking whether build environment is sane... yes >>>>>>> /bin/sh: SHELLOPTS: readonly variable >>>>>>> checking for a thread-safe mkdir -p... ./install-sh -c -d >>>>>>> checking for gawk... no >>>>>>> checking for mawk... no >>>>>>> checking for nawk... no >>>>>>> checking for awk... awk >>>>>>> checking whether make sets $(MAKE)... yes >>>>>>> checking whether to enable maintainer-specific portions of >>>>>>> Makefiles... no >>>>>>> checking ABI=64 >>>>>>> checking whether clang is gcc... yes >>>>>>> checking compiler clang -O2 -pedantic -fPIC -m64 ... no, gnupro >>>>>>> alpha ev6 char spilling >>>>>>> checking ABI=32 >>>>>>> checking whether clang is gcc... yes >>>>>>> *checking compiler clang -m32 -O2 -pedantic -fPIC >>>>>>> -fomit-frame-pointer ... no, gnupro alpha ev6 char spilling* >>>>>>> *checking compiler clang -O2 -pedantic -fPIC -fomit-frame-pointer >>>>>>> ... no, gnupro alpha ev6 char spilling* >>>>>>> *configure: error: could not find a working compiler, see config.log >>>>>>> for details* >>>>>>> *make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1* >>>>>>> *make: *** [all] Error 2* >>>>>>> >>>>>>> >>>>>>> On Mon, Nov 9, 2015 at 9:32 AM, Ben Gamari >>>>>>> wrote: >>>>>>> >>>>>>>> George Colpitts writes: >>>>>>>> >>>>>>>> > I get >>>>>>>> > >>>>>>>> > make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1 >>>>>>>> > make[1]: *** Waiting for unfinished jobs.... >>>>>>>> >>>>>>>> It looks like the build failed somewhere before this point. Could >>>>>>>> you >>>>>>>> provide a more complete log? >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> - Ben >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Mon Nov 16 10:00:51 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 16 Nov 2015 11:00:51 +0100 Subject: [ANNOUNCE] 7.10.3 release candidate 2 - problems compiling source on Mac OS with clang In-Reply-To: References: Message-ID: <87oaeuz2jw.fsf@smart-cactus.org> George Colpitts writes: > I did get compiling from source to work on the Mac. Unfortunately I'm not > sure what the problem was. > > I now see a new problem, not sure if it is a ghc problem or a library > problem: > > cabal install HsOpenSSL > ... > Building HsOpenSSL-0.11.1.1... > Preprocessing library HsOpenSSL-0.11.1.1... > In file included from BN.hsc:45: > cbits/HsOpenSSL.h:3:10: fatal error: 'openssl/asn1.h' file not found > #include > ^ > 1 error generated. It would appear that you don't have headers for OpenSSL installed. Where did you get your OpenSSL distribution from? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From george.colpitts at gmail.com Mon Nov 16 12:45:02 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Mon, 16 Nov 2015 08:45:02 -0400 Subject: [ANNOUNCE] 7.10.3 release candidate 2 - problems compiling source on Mac OS with clang In-Reply-To: <87oaeuz2jw.fsf@smart-cactus.org> References: <87oaeuz2jw.fsf@smart-cactus.org> Message-ID: As I mentioned above from brew: $ brew upgrade openssl brew upgrade openssl Error: openssl 1.0.2d_1 already installed Thanks On Mon, Nov 16, 2015 at 6:00 AM, Ben Gamari wrote: > George Colpitts writes: > > > I did get compiling from source to work on the Mac. Unfortunately I'm not > > sure what the problem was. > > > > I now see a new problem, not sure if it is a ghc problem or a library > > problem: > > > > cabal install HsOpenSSL > > ... > > Building HsOpenSSL-0.11.1.1... > > Preprocessing library HsOpenSSL-0.11.1.1... > > In file included from BN.hsc:45: > > cbits/HsOpenSSL.h:3:10: fatal error: 'openssl/asn1.h' file not found > > #include > > ^ > > 1 error generated. > > It would appear that you don't have headers for OpenSSL installed. Where > did you get your OpenSSL distribution from? > > Cheers, > > - Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Mon Nov 16 12:52:55 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 16 Nov 2015 13:52:55 +0100 Subject: [ANNOUNCE] 7.10.3 release candidate 2 - problems compiling source on Mac OS with clang In-Reply-To: References: <87oaeuz2jw.fsf@smart-cactus.org> Message-ID: <87bnauyul4.fsf@smart-cactus.org> George Colpitts writes: > As I mentioned above from brew: > > $ brew upgrade openssl > brew upgrade openssl > Error: openssl 1.0.2d_1 already installed > I see. Does the file in question exist? What does find /usr/local -iname asn1.h say? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From george.colpitts at gmail.com Mon Nov 16 13:14:22 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Mon, 16 Nov 2015 09:14:22 -0400 Subject: [ANNOUNCE] 7.10.3 release candidate 2 - problems compiling source on Mac OS with clang In-Reply-To: <87bnauyul4.fsf@smart-cactus.org> References: <87oaeuz2jw.fsf@smart-cactus.org> <87bnauyul4.fsf@smart-cactus.org> Message-ID: find /usr/local -iname asn1.h /usr/local/Cellar/nettle/2.7.1/include/nettle/asn1.h /usr/local/Cellar/openssl/1.0.1j/include/openssl/asn1.h /usr/local/Cellar/openssl/1.0.1j_1/include/openssl/asn1.h /usr/local/Cellar/openssl/1.0.1l/include/openssl/asn1.h /usr/local/Cellar/openssl/1.0.2a-1/include/openssl/asn1.h /usr/local/Cellar/openssl/1.0.2c/include/openssl/asn1.h /usr/local/Cellar/openssl/1.0.2d_1/include/openssl/asn1.h ?As you might guess? from the above I've successfully installed this in the past with other versions of ghc :) Thanks for all your help here Cheers George On Mon, Nov 16, 2015 at 8:52 AM, Ben Gamari wrote: > George Colpitts writes: > > > As I mentioned above from brew: > > > > $ brew upgrade openssl > > brew upgrade openssl > > Error: openssl 1.0.2d_1 already installed > > > I see. Does the file in question exist? > > What does > > find /usr/local -iname asn1.h > > say? > > Cheers, > > - Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Mon Nov 16 13:54:37 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Mon, 16 Nov 2015 09:54:37 -0400 Subject: [ANNOUNCE] 7.10.3 release candidate 2 - problems compiling source on Mac OS with clang In-Reply-To: References: <87oaeuz2jw.fsf@smart-cactus.org> <87bnauyul4.fsf@smart-cactus.org> Message-ID: Sorry, it seems that this is a known problem with Mac OS 10.11. From https://github.com/phonohawk/HsOpenSSL/issues/41 openssl libs and includes are not included in OS X 10.11. I'm not sure if this is permanent or just an effect of the beta release but we should keep our eye on it so when 10.11 is released, HsOpenSSL will work smoothly. On Mon, Nov 16, 2015 at 9:14 AM, George Colpitts wrote: > > find /usr/local -iname asn1.h > /usr/local/Cellar/nettle/2.7.1/include/nettle/asn1.h > /usr/local/Cellar/openssl/1.0.1j/include/openssl/asn1.h > /usr/local/Cellar/openssl/1.0.1j_1/include/openssl/asn1.h > /usr/local/Cellar/openssl/1.0.1l/include/openssl/asn1.h > /usr/local/Cellar/openssl/1.0.2a-1/include/openssl/asn1.h > /usr/local/Cellar/openssl/1.0.2c/include/openssl/asn1.h > /usr/local/Cellar/openssl/1.0.2d_1/include/openssl/asn1.h > > ?As you might guess? from the above I've successfully installed this in > the past with other versions of ghc :) > > Thanks for all your help here > > Cheers > George > > > On Mon, Nov 16, 2015 at 8:52 AM, Ben Gamari wrote: > >> George Colpitts writes: >> >> > As I mentioned above from brew: >> > >> > $ brew upgrade openssl >> > brew upgrade openssl >> > Error: openssl 1.0.2d_1 already installed >> > >> I see. Does the file in question exist? >> >> What does >> >> find /usr/local -iname asn1.h >> >> say? >> >> Cheers, >> >> - Ben >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Mon Nov 16 17:32:30 2015 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Mon, 16 Nov 2015 12:32:30 -0500 Subject: Implementation idea for unboxed polymorphic types In-Reply-To: References: <1194C002-769A-4232-A2BC-632875496F37@mazzo.li> Message-ID: > But I don't see why you'd need quoting at constructor calls. Couldn't you > just have a type class like `PointFamily`? This is exactly right, my memory has failed me. My initial implementation didn't use the type family trick, I had further attempts that use type families but honestly I don't remember how good it worked. This was quite a while ago. 2015-11-15 19:41 GMT-05:00 Richard Eisenberg : > After reading Francesco's original post, I immediately thought of ?mer's proposed approach, of using Template Haskell to produce the right data family instances. But I don't see why you'd need quoting at constructor calls. Couldn't you just have a type class like `PointFamily`? I'd be more interested to see client code in ?mer's version than the TH generation code. > > The TH approach would seem to require having a fixed set of specializations, which is a downside. But I'm not sure it's so much of a downside that the approach is unusable. > > Richard > > On Nov 15, 2015, at 10:08 AM, ?mer Sinan A?acan wrote: > >> I had started working on exactly the same thing at some point. I had a >> TemplateHaskell-based implementation which _almost_ worked. >> >> The problem was that the syntax was very, very heavy. Because I had to use >> quotes for _every_ constructor application(with explicitly passed types). >> (because I had a specialized constructor for every instantiation of this >> generic type) >> >> Another problem was that because of how TemplateHaskell quotes evaluated, I >> couldn't use a `List Int` where `List` is a template without first manually >> adding a line for generating specialized version of `List` on `Int`. >> >> When all of these combined it became very hard to use. But it was a >> proof-of-concept and I think it worked. >> >> (Code is horrible so I won't share it here :) I had to maintain a state shared >> with different TH quote evaluations etc.) >> >> 2015-11-15 5:26 GMT-05:00 Francesco Mazzoli : >>> (A nicely rendered version of this email can be found at ) >>> >>> ## Macro types >>> >>> I very often find myself wanting unboxed polymorphic types >>> (e.g. types that contain `UNPACK`ed type variables). I find >>> it extremely frustrating that it's easier to write fast _and_ >>> generic code in C++ than in Haskell. >>> >>> I'd like to submit to the mailing list a very rough proposal >>> on how this could be achieved in a pretty straightforward way >>> in GHC. >>> >>> The proposal is meant to be a proof of concept, just to show that >>> this could be done rather easily. I did not think about a nice >>> interface or the implementation details in GHC. My goal is to >>> check the feasibility of this plan with GHC developers. >>> >>> I'll call such types "macro types", since their effect is similar >>> to defining a macro that defines a new type for each type >>> variable instantiation. >>> >>> Consider >>> >>> ``` >>> data #Point a = Point >>> { x :: {-# UNPACK #-} !a >>> , y :: {-# UNPACK #-} !a >>> } >>> ``` >>> >>> This definition defines the macro type `#Point`, with one parameter >>> `a`. >>> >>> Macro types definition would be allowed only for single-constructor >>> records. The intent is that if we mention `#Point Double`, it will >>> be equivalent to >>> >>> ``` >>> data PointDouble = PointDouble >>> { x :: {-# UNPACK #-} !Double >>> , y :: {-# UNPACK #-} !Double >>> } >>> ``` >>> >>> To use `#Point` generically, the following type class would be >>> generated: >>> >>> ``` >>> class PointFamily a where >>> data #Point a :: * -- Family of types generated by @data #Point a at . >>> #Point :: a -> a -> #Point a -- Constructor. >>> #x :: #Point a -> a -- Projection @x at . >>> #y :: #Point a -> a -- Projection @y at . >>> ``` >>> >>> Thi type class lets us work with `#Point`s generically, for example >>> >>> ``` >>> distance :: (PointFamily a, Fractional a) => #Point a -> #Point a -> a >>> distance p1 p2 = >>> let dx = #x p1 - #x p2 >>> dy = #y p1 - #y p2 >>> in sqrt (dx*dx + dy*dy) >>> ``` >>> >>> Internally, for every type appearing for `a`, e.g. `#Point Double`, >>> a new type equivalent to the `PointDouble` above would be generated >>> by GHC, with the corresponding instance >>> >>> ``` >>> instance PointFamily Double where >>> data #Point Double = PointDouble >>> #x = x >>> #y = x >>> ``` >>> >>> If it's not possible to instantiate `#Point` with the provided type >>> (for example because the type is not `UNPACK`able, e.g. >>> `#Point (Maybe A)`), GHC would throw an error. >>> >>> Note that we can compile `distance` in its polymorphic version >>> (as opposed to C++ templates, where template functions _must_ be >>> instantiated at every use). The polymorphic `distance` would >>> require a call to "virtual functions" `#x` and `#y`, as provided by >>> the `PointFamily` dictionary. But if we use >>> `INLINE` or `SPECIALIZE` pragmas the virtual calls to `#x` and `#y` >>> would disappear, making this as efficient as if we were to define >>> `distance` on the manually defined `PointDouble`. Compiler hints >>> would be put in place to always inline functions using macro types, >>> if possible. >>> >>> Note that the inlining is only important so that the `PointFamily` >>> dictionary disappears, e.g. functions containing recursive >>> helpers are fine, such as >>> >>> ``` >>> {-# INLINE leftmost #-} >>> leftmost :: forall a. (PointFamily a, Ord a) => [#Point a] -> #Point a >>> leftmost [] = error "leftmost: no points" >>> leftmost (p0 : ps0) = go p0 ps0 >>> where >>> go :: #Point a -> [#Point a] -> Point# a >>> go candidate (p : ps) = >>> if #x p < #x candidate >>> then go p ps >>> else go candidate ps >>> ``` >>> >>> It might be worth considering throwing a warning when a top-level >>> definition whose type contains a macro type cannot be inlined, since >>> the main performance benefit of using macro types would be lost. >>> >>> We can define instances for these types as normal, for instance >>> >>> ``` >>> instance (Show a, PointFamily a) => Show (#Point a) where >>> {-# INLINE show #-} >>> show pt = "Point{x = " ++ #x pt ++ ", y = " ++ #y pt ++ "}" >>> ``` >>> >>> `deriving` support could also be added. >>> >>> ## Further ideas >>> >>> ### Hide or remove `PointFamily` from the user >>> >>> In the examples above `PointFamily` is manipulated explicitely >>> (e.g. in the type signature for `distance`). >>> In most cases the right constraint could be generated >>> automatically by GHC, although I think direct access to the >>> type class would be beneficial (history shows that direct >>> access to these facilities is good, see upcoming explicit >>> type applications). >>> >>> Maybe the type class associated to a macro type should not even >>> exist -- for example we could simply represent `#Point` as a type >>> family and treat construction and destruction as built-in syntax >>> (the `#` prefix). >>> >>> ### Pattern matching >>> >>> Sugar could be added to pattern match, e.g. >>> >>> ``` >>> foo :: Point# a -> ... >>> distance (Point# x1 y1) = ... >>> or >>> dinstance Point#{..} = ... -- #x and #y are available >>> ``` >>> >>> ### No "record types" limitation >>> >>> Instead of restricting ourselves to single-constructor records, >>> we could simply generate >>> >>> ``` >>> data Point a = Point a >>> { x :: !a >>> , y :: !a >>> } >>> >>> class PointFamily a where >>> data Point# a :: * >>> destruct :: Point# a -> Point a >>> construct :: Point a -> Point# a >>> ``` >>> >>> However, I think it would be harder to guarantee the well-behavedness >>> of the inlined functions if we had this intermediate type. I also >>> don't think macro types would be very useful beyond polymorphic >>> unboxed types. >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From ben at smart-cactus.org Mon Nov 16 21:21:46 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 16 Nov 2015 22:21:46 +0100 Subject: Further custom type error questions Message-ID: <876111zllh.fsf@smart-cactus.org> While preparing some additional documentation for Iavor's custom type errors work (which has been merged; thanks Iavor!) I noticed that Dominique Devriese has raised some additional questions on the proposal [1]. In particular, Dominique suggests that perhaps TypeError should simply be of kind `ErrorMessage -> Constraint`. My understanding of the proposal is that the intention is that `TypeError`s should be usable on the RHS of type functions, like `error` on the term level. However, is this strictly necessary? Is there any place where you couldn't just as easily express the `TypeError` as a constraint? If not, it seems like this may be substantially simpler approach and totally side-steps the detection of `TypeError` in inappropriate places on the RHS. Regardless, it seems like this (and the other questions) is worth addressing in the proposal. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Proposal/CustomTypeErrors#SomedesignquestionsDominiqueDevriese: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From simonpj at microsoft.com Mon Nov 16 23:24:43 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 16 Nov 2015 23:24:43 +0000 Subject: process librarry Message-ID: <01153f3818a14815961074d1a50c4851@DB4PR30MB030.064d.mgd.msft.net> Michael My Windows build (sh validate in a clean tree) is still falling over as follows, on Windows. Would it be possible to fix the process library to stop this happening? Thanks Simon libraries\process\System\Process\Internals.hs:106:16: warning: Defined but not used: data constructor `CGid' -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Tue Nov 17 00:09:48 2015 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon, 16 Nov 2015 16:09:48 -0800 Subject: Further custom type error questions In-Reply-To: <876111zllh.fsf@smart-cactus.org> References: <876111zllh.fsf@smart-cactus.org> Message-ID: Hello, I imagine people wanting to do things as in the example below. If we were to use only `TypeError` constraints, then we'd have to mostly use the class system to do type-level evaluation. It doesn't seem obvious how to do that with just `TypeError` of kind constraint, unless all evaluation was to happen using the class system. -Iavor PS: Interestingly, this example reveals a bug with GHC's new warning about unused constraints, where the `OffsetOf` constant on `get` is reported as unnecessary... I'll file a bug. {-# LANGUAGE TypeFamilies, TypeOperators, UndecidableInstances, DataKinds #-} {-# LANGUAGE ScopedTypeVariables #-} import GHC.TypeLits import Data.Proxy import Data.Word import Foreign.Ptr type OffsetOf l xs = GetOffset 0 l xs type family ByteSize x where ByteSize Word64 = 8 ByteSize Word32 = 4 ByteSize Word16 = 2 ByteSize Word8 = 1 ByteSize a = TypeError (Text "The type " :<>: ShowType a :<>: Text " is not exportable.") type family GetOffset n (l :: Symbol) xs where GetOffset n l ( '(l,a) ': xs) = '(n,a) GetOffset n l ( '(x,a) : xs) = GetOffset (n+ByteSize a) l xs GetOffset n l '[] = TypeError (Text "Missing field: " :<>: ShowType l) newtype Struct (a :: [(Symbol,*)]) = Struct (Ptr ()) get :: forall l fs n a. (OffsetOf l fs ~ '(n,a), KnownNat n) => Struct fs -> Proxy l -> Ptr a get (Struct p) _ = plusPtr p (fromInteger (natVal (Proxy :: Proxy n))) type MyStruct = [ '("A",Word8), '("B",Word8), '("C",Int) ] testOk :: Struct MyStruct -> Ptr Word8 testOk s = get s (Proxy :: Proxy "B") {- testNotOk :: Struct MyStruct -> Ptr Word8 testNotOk s = get s (Proxy :: Proxy "X") --} {- type MyOtherStruct = [ '("A",Int), '("B",Word8) ] testNotOk :: Struct MyOtherStruct -> Ptr Word8 testNotOk s = get s (Proxy :: Proxy "B") --} On Mon, Nov 16, 2015 at 1:21 PM, Ben Gamari wrote: > > While preparing some additional documentation for Iavor's custom type > errors work (which has been merged; thanks Iavor!) I noticed that > Dominique Devriese has raised some additional questions on the proposal > [1]. > > In particular, Dominique suggests that perhaps TypeError should simply > be of kind `ErrorMessage -> Constraint`. My understanding of the > proposal is that the intention is that `TypeError`s should be usable on > the RHS of type functions, like `error` on the term level. However, is > this strictly necessary? Is there any place where you couldn't just as > easily express the `TypeError` as a constraint? > > If not, it seems like this may be substantially simpler approach and > totally side-steps the detection of `TypeError` in inappropriate places > on the RHS. > > Regardless, it seems like this (and the other questions) is worth > addressing in the proposal. > > Cheers, > > - Ben > > > [1] > https://ghc.haskell.org/trac/ghc/wiki/Proposal/CustomTypeErrors#SomedesignquestionsDominiqueDevriese > : > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Nov 17 01:18:04 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 16 Nov 2015 20:18:04 -0500 Subject: [ANNOUNCE] 7.10.3 release candidate 2 - problems compiling source on Mac OS with clang In-Reply-To: References: <87oaeuz2jw.fsf@smart-cactus.org> <87bnauyul4.fsf@smart-cactus.org> Message-ID: My understanding is that they now use libre ssl. So definitely not OpenSSL. If you want open ssl instead you need to install it via brew or the like On Monday, November 16, 2015, George Colpitts wrote: > Sorry, it seems that this is a known problem with Mac OS 10.11. From > https://github.com/phonohawk/HsOpenSSL/issues/41 > > openssl libs and includes are not included in OS X 10.11. I'm not sure if > this is permanent or just an effect of the beta release but we should keep > our eye on it so when 10.11 is released, HsOpenSSL will work smoothly. > > > On Mon, Nov 16, 2015 at 9:14 AM, George Colpitts < > george.colpitts at gmail.com > > wrote: > >> >> find /usr/local -iname asn1.h >> /usr/local/Cellar/nettle/2.7.1/include/nettle/asn1.h >> /usr/local/Cellar/openssl/1.0.1j/include/openssl/asn1.h >> /usr/local/Cellar/openssl/1.0.1j_1/include/openssl/asn1.h >> /usr/local/Cellar/openssl/1.0.1l/include/openssl/asn1.h >> /usr/local/Cellar/openssl/1.0.2a-1/include/openssl/asn1.h >> /usr/local/Cellar/openssl/1.0.2c/include/openssl/asn1.h >> /usr/local/Cellar/openssl/1.0.2d_1/include/openssl/asn1.h >> >> ?As you might guess? from the above I've successfully installed this in >> the past with other versions of ghc :) >> >> Thanks for all your help here >> >> Cheers >> George >> >> >> On Mon, Nov 16, 2015 at 8:52 AM, Ben Gamari > > wrote: >> >>> George Colpitts >> > writes: >>> >>> > As I mentioned above from brew: >>> > >>> > $ brew upgrade openssl >>> > brew upgrade openssl >>> > Error: openssl 1.0.2d_1 already installed >>> > >>> I see. Does the file in question exist? >>> >>> What does >>> >>> find /usr/local -iname asn1.h >>> >>> say? >>> >>> Cheers, >>> >>> - Ben >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chak at justtesting.org Tue Nov 17 02:36:54 2015 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Tue, 17 Nov 2015 13:36:54 +1100 Subject: [ANNOUNCE] 7.10.3 release candidate 2 - problems compiling source on Mac OS with clang In-Reply-To: References: <87oaeuz2jw.fsf@smart-cactus.org> <87bnauyul4.fsf@smart-cactus.org> Message-ID: <08FFC2BD-BAF2-4D5E-974D-11E6D1FD5240@justtesting.org> Apple has started to move away from OpenSSL for quite a while. This post summarises it quite nicely http://rentzsch.tumblr.com/post/33696323211/wherein-i-write-apples-technote-about-openssl-on In recent times, you could add as a reason for avoiding OpenSSL its shaky security track record. (Heartbleed anyone). Manuel > Carter Schonwald : > > My understanding is that they now use libre ssl. So definitely not OpenSSL. If you want open ssl instead you need to install it via brew or the like > > On Monday, November 16, 2015, George Colpitts > wrote: > Sorry, it seems that this is a known problem with Mac OS 10.11. From https://github.com/phonohawk/HsOpenSSL/issues/41 > > openssl libs and includes are not included in OS X 10.11. I'm not sure if this is permanent or just an effect of the beta release but we should keep our eye on it so when 10.11 is released, HsOpenSSL will work smoothly. > > > On Mon, Nov 16, 2015 at 9:14 AM, George Colpitts > wrote: > > find /usr/local -iname asn1.h > /usr/local/Cellar/nettle/2.7.1/include/nettle/asn1.h > /usr/local/Cellar/openssl/1.0.1j/include/openssl/asn1.h > /usr/local/Cellar/openssl/1.0.1j_1/include/openssl/asn1.h > /usr/local/Cellar/openssl/1.0.1l/include/openssl/asn1.h > /usr/local/Cellar/openssl/1.0.2a-1/include/openssl/asn1.h > /usr/local/Cellar/openssl/1.0.2c/include/openssl/asn1.h > /usr/local/Cellar/openssl/1.0.2d_1/include/openssl/asn1.h > > ?As you might guess? from the above I've successfully installed this in the past with other versions of ghc :) > > Thanks for all your help here > > Cheers > George > > > On Mon, Nov 16, 2015 at 8:52 AM, Ben Gamari > wrote: > George Colpitts > writes: > > > As I mentioned above from brew: > > > > $ brew upgrade openssl > > brew upgrade openssl > > Error: openssl 1.0.2d_1 already installed > > > I see. Does the file in question exist? > > What does > > find /usr/local -iname asn1.h > > say? > > Cheers, > > - Ben > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Tue Nov 17 03:29:20 2015 From: michael at snoyman.com (Michael Snoyman) Date: Tue, 17 Nov 2015 03:29:20 +0000 Subject: process librarry In-Reply-To: <01153f3818a14815961074d1a50c4851@DB4PR30MB030.064d.mgd.msft.net> References: <01153f3818a14815961074d1a50c4851@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Can you try updating the submodule to the latest master and see if that fixes it for you? On Tue, Nov 17, 2015, 1:25 AM Simon Peyton Jones wrote: > Michael > > My Windows build (sh validate in a clean tree) is still falling over as > follows, on Windows. Would it be possible to fix the process library to > stop this happening? > > Thanks > > Simon > > > > libraries\process\System\Process\Internals.hs:106:16: warning: > > Defined but not used: data constructor `CGid' > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Tue Nov 17 10:10:55 2015 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 17 Nov 2015 10:10:55 +0000 Subject: Remote GHCi Message-ID: <564AFD2F.6020305@gmail.com> Hi folks - I've been thinking about changing the way we run interpreted code so that it would be run in a separate process. It turns out this has quite a few benefits, and would let us kill some of the really awkward hacks we have in GHC to work around problems that arise because we're running interpreted code and the compiler on the same runtime. I summarised the idea here: https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi I'd be interested to hear if anyone has any thoughts around this, particularly if doing this would make your life difficult in some way. Are people relying on dynCompileExpr for anything? Cheers, Simon From marlowsd at gmail.com Tue Nov 17 10:19:16 2015 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 17 Nov 2015 10:19:16 +0000 Subject: too many lines too long In-Reply-To: <201511131601.35607.jan.stolarek@p.lodz.pl> References: <966B4013-23C0-45EA-975A-6506707A555E@cis.upenn.edu> <56432EA6.40502@jacobs-university.de> <201511131601.35607.jan.stolarek@p.lodz.pl> Message-ID: <564AFF24.2090308@gmail.com> On 13/11/2015 15:01, Jan Stolarek wrote: > My view on this is: > > Firstly, I hate explaining myself to Arcanist. When prompted to explain the reason for too long > lines I typically enter "wontfix" without thinking too much. > > Secondly, I really don't like how warnings clutter code reviews. > > I have my Emacs highlight text beyond 80th column with a really ugly colour, so I strive real hard > to maintain 80-column limit whenever possible. But sometimes fitting in that limit is nearly > impossible: imagine being in a let nested in a do-notation nested in a guard nested in a where > clause. Approx. 15-20 columns are lost for the indentation. Nevertheless I would support > introducing a hard limit on having no more than 80 columns. > > Janek > > PS. It makes me really sad that we don't have any coding convention for GHC: we mix camelCase with > underscore_case, indentation is inconsistent (good thing we at least got rid of tabs!), > whitespace usage is inconsistent, etc. I could make this list very long. Why not write down a set of style guidelines and get everyone to agree to them? I'd happily compromise my personal stylistic preferences if there was a standard style that we all agreed on and tried to adhere to. Personally I think a good starting point is http://chrisdone.github.io/hindent/HIndent-Styles-JohanTibell.html Incidentally the mixed camelCase and underscore style is deliberate: underscores for local identifiers, camelCase for exported functions. It's a cute idea I've been using for a long time, but we don't have to do it that way. At work we use camelCase exclusively and it's fine. Cheers, Simon > --- > Politechnika ????dzka > Lodz University of Technology > > Tre???? tej wiadomo??ci zawiera informacje przeznaczone tylko dla adresata. > Je??eli nie jeste??cie Pa??stwo jej adresatem, b??d?? otrzymali??cie j?? przez pomy??k?? > prosimy o powiadomienie o tym nadawcy oraz trwa??e jej usuni??cie. > > This email contains information intended solely for the use of the individual to whom it is addressed. > If you are not the intended recipient or if you have received this message in error, > please notify the sender and delete it from your system. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From alan.zimm at gmail.com Tue Nov 17 10:40:09 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Tue, 17 Nov 2015 12:40:09 +0200 Subject: Remote GHCi In-Reply-To: <564AFD2F.6020305@gmail.com> References: <564AFD2F.6020305@gmail.com> Message-ID: This fits in directly with what I am trying to do for the haskell-ide-engine, where the intention is to expose ghci via an asynchronous process with communication via message passing. A bonus would be to have two separate interfaces, one for REPL interaction for the user, the other to be able to query properties of the loaded code. I am currently investigating exposing Behavior and RunTerm from haskeline to create a message passing backend instead. Alan On 17 Nov 2015 12:11 PM, "Simon Marlow" wrote: > Hi folks - I've been thinking about changing the way we run interpreted > code so that it would be run in a separate process. It turns out this has > quite a few benefits, and would let us kill some of the really awkward > hacks we have in GHC to work around problems that arise because we're > running interpreted code and the compiler on the same runtime. > > I summarised the idea here: > https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi > > I'd be interested to hear if anyone has any thoughts around this, > particularly if doing this would make your life difficult in some way. Are > people relying on dynCompileExpr for anything? > > Cheers, > Simon > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sumit.sahrawat.apm13 at iitbhu.ac.in Tue Nov 17 10:47:36 2015 From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing, IIT (BHU)) Date: Tue, 17 Nov 2015 16:17:36 +0530 Subject: Remote GHCi In-Reply-To: References: <564AFD2F.6020305@gmail.com> Message-ID: Hi Simon, IHaskell makes use of dynCompileExpr to evaluate code provided by the user, so that the result can be sent to the frontend to be displayed. I don't think we can make it work without using dynCompileExpr, Andrew would have more to say about this. On 17 November 2015 at 16:10, Alan & Kim Zimmerman wrote: > This fits in directly with what I am trying to do for the > haskell-ide-engine, where the intention is to expose ghci via an > asynchronous process with communication via message passing. > > A bonus would be to have two separate interfaces, one for REPL interaction > for the user, the other to be able to query properties of the loaded code. > > I am currently investigating exposing Behavior and RunTerm from haskeline > to create a message passing backend instead. > > Alan > On 17 Nov 2015 12:11 PM, "Simon Marlow" wrote: > >> Hi folks - I've been thinking about changing the way we run interpreted >> code so that it would be run in a separate process. It turns out this has >> quite a few benefits, and would let us kill some of the really awkward >> hacks we have in GHC to work around problems that arise because we're >> running interpreted code and the compiler on the same runtime. >> >> I summarised the idea here: >> https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi >> >> I'd be interested to hear if anyone has any thoughts around this, >> particularly if doing this would make your life difficult in some way. Are >> people relying on dynCompileExpr for anything? >> >> Cheers, >> Simon >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -- Regards Sumit Sahrawat -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Tue Nov 17 11:04:13 2015 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 17 Nov 2015 11:04:13 +0000 Subject: Remote GHCi In-Reply-To: References: <564AFD2F.6020305@gmail.com> Message-ID: <564B09AD.5050403@gmail.com> I think there will be ways to do what you want in the context of a remote interpreter, but I'll need to understand more about the way in which you use dynCompileExpr. What do you do with the result of dynCompileExpr? Can you run that code in the context of the interpreter instead? Cheers Simon On 17/11/2015 10:47, Sumit Sahrawat, Maths & Computing, IIT (BHU) wrote: > Hi Simon, > > IHaskell makes use of > dynCompileExpr to evaluate code provided by the user, so that the result > can be sent to the frontend to be displayed. > > I don't think we can make it work without using dynCompileExpr, Andrew > would have more to say about this. > > On 17 November 2015 at 16:10, Alan & Kim Zimmerman > wrote: > > This fits in directly with what I am trying to do for the > haskell-ide-engine, where the intention is to expose ghci via an > asynchronous process with communication via message passing. > > A bonus would be to have two separate interfaces, one for REPL > interaction for the user, the other to be able to query properties > of the loaded code. > > I am currently investigating exposing Behavior and RunTerm from > haskeline to create a message passing backend instead. > > Alan > > On 17 Nov 2015 12:11 PM, "Simon Marlow" > wrote: > > Hi folks - I've been thinking about changing the way we run > interpreted code so that it would be run in a separate process. > It turns out this has quite a few benefits, and would let us > kill some of the really awkward hacks we have in GHC to work > around problems that arise because we're running interpreted > code and the compiler on the same runtime. > > I summarised the idea here: > https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi > > I'd be interested to hear if anyone has any thoughts around > this, particularly if doing this would make your life difficult > in some way. Are people relying on dynCompileExpr for anything? > > Cheers, > Simon > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > -- > Regards > > Sumit Sahrawat From marlowsd at gmail.com Tue Nov 17 11:08:07 2015 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 17 Nov 2015 11:08:07 +0000 Subject: Remote GHCi In-Reply-To: References: <564AFD2F.6020305@gmail.com> Message-ID: <564B0A97.7030702@gmail.com> So the remote GHCi server I had in mind would be too dumb to support this - it would be at a much lower level, with support for linking object code and bytecode and evaluation only. What you probably want for this is a remote interface to the GHC API, similar to what ide-backend provides. Cheers, Simon On 17/11/2015 10:40, Alan & Kim Zimmerman wrote: > This fits in directly with what I am trying to do for the > haskell-ide-engine, where the intention is to expose ghci via an > asynchronous process with communication via message passing. > > A bonus would be to have two separate interfaces, one for REPL > interaction for the user, the other to be able to query properties of > the loaded code. > > I am currently investigating exposing Behavior and RunTerm from > haskeline to create a message passing backend instead. > > Alan > > On 17 Nov 2015 12:11 PM, "Simon Marlow" > wrote: > > Hi folks - I've been thinking about changing the way we run > interpreted code so that it would be run in a separate process. It > turns out this has quite a few benefits, and would let us kill some > of the really awkward hacks we have in GHC to work around problems > that arise because we're running interpreted code and the compiler > on the same runtime. > > I summarised the idea here: > https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi > > I'd be interested to hear if anyone has any thoughts around this, > particularly if doing this would make your life difficult in some > way. Are people relying on dynCompileExpr for anything? > > Cheers, > Simon > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From simonpj at microsoft.com Tue Nov 17 11:19:23 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 17 Nov 2015 11:19:23 +0000 Subject: Further custom type error questions In-Reply-To: References: <876111zllh.fsf@smart-cactus.org> Message-ID: <8d7ed06345a845e188d18d869a7ec684@DB4PR30MB030.064d.mgd.msft.net> So perhaps you can update the wiki page to give an example like this, and thereby explain the design choice? Or have a FAQ: ?why not give TypeErorr the kind String -> Constraint??. The thought will be lost in email! Simon From: Iavor Diatchki [mailto:iavor.diatchki at gmail.com] Sent: 17 November 2015 00:10 To: Ben Gamari Cc: Simon Peyton Jones; Richard Eisenberg; Dominique Devriese; ghc-devs at haskell.org Subject: Re: Further custom type error questions Hello, I imagine people wanting to do things as in the example below. If we were to use only `TypeError` constraints, then we'd have to mostly use the class system to do type-level evaluation. It doesn't seem obvious how to do that with just `TypeError` of kind constraint, unless all evaluation was to happen using the class system. -Iavor PS: Interestingly, this example reveals a bug with GHC's new warning about unused constraints, where the `OffsetOf` constant on `get` is reported as unnecessary... I'll file a bug. {-# LANGUAGE TypeFamilies, TypeOperators, UndecidableInstances, DataKinds #-} {-# LANGUAGE ScopedTypeVariables #-} import GHC.TypeLits import Data.Proxy import Data.Word import Foreign.Ptr type OffsetOf l xs = GetOffset 0 l xs type family ByteSize x where ByteSize Word64 = 8 ByteSize Word32 = 4 ByteSize Word16 = 2 ByteSize Word8 = 1 ByteSize a = TypeError (Text "The type " :<>: ShowType a :<>: Text " is not exportable.") type family GetOffset n (l :: Symbol) xs where GetOffset n l ( '(l,a) ': xs) = '(n,a) GetOffset n l ( '(x,a) : xs) = GetOffset (n+ByteSize a) l xs GetOffset n l '[] = TypeError (Text "Missing field: " :<>: ShowType l) newtype Struct (a :: [(Symbol,*)]) = Struct (Ptr ()) get :: forall l fs n a. (OffsetOf l fs ~ '(n,a), KnownNat n) => Struct fs -> Proxy l -> Ptr a get (Struct p) _ = plusPtr p (fromInteger (natVal (Proxy :: Proxy n))) type MyStruct = [ '("A",Word8), '("B",Word8), '("C",Int) ] testOk :: Struct MyStruct -> Ptr Word8 testOk s = get s (Proxy :: Proxy "B") {- testNotOk :: Struct MyStruct -> Ptr Word8 testNotOk s = get s (Proxy :: Proxy "X") --} {- type MyOtherStruct = [ '("A",Int), '("B",Word8) ] testNotOk :: Struct MyOtherStruct -> Ptr Word8 testNotOk s = get s (Proxy :: Proxy "B") --} On Mon, Nov 16, 2015 at 1:21 PM, Ben Gamari > wrote: While preparing some additional documentation for Iavor's custom type errors work (which has been merged; thanks Iavor!) I noticed that Dominique Devriese has raised some additional questions on the proposal [1]. In particular, Dominique suggests that perhaps TypeError should simply be of kind `ErrorMessage -> Constraint`. My understanding of the proposal is that the intention is that `TypeError`s should be usable on the RHS of type functions, like `error` on the term level. However, is this strictly necessary? Is there any place where you couldn't just as easily express the `TypeError` as a constraint? If not, it seems like this may be substantially simpler approach and totally side-steps the detection of `TypeError` in inappropriate places on the RHS. Regardless, it seems like this (and the other questions) is worth addressing in the proposal. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Proposal/CustomTypeErrors#SomedesignquestionsDominiqueDevriese: -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Tue Nov 17 11:31:51 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Tue, 17 Nov 2015 13:31:51 +0200 Subject: Further custom type error questions In-Reply-To: References: <876111zllh.fsf@smart-cactus.org> Message-ID: <564B1027.4070902@ro-che.info> Iavor, Ben, et al.: How about much simpler type family Head (a :: [k]) :: k where Head (x ': xs) = x Head '[] = Error "Empty list" Can this be expressed through Error-as-constraint? On 11/17/2015 02:09 AM, Iavor Diatchki wrote: > Hello, > > I imagine people wanting to do things as in the example below. If we > were to use only `TypeError` constraints, then we'd have to mostly use > the class system to do type-level evaluation. It doesn't seem obvious > how to do that with just `TypeError` of kind constraint, unless all > evaluation was to happen using the class system. > > -Iavor > PS: Interestingly, this example reveals a bug with GHC's new warning > about unused constraints, where the `OffsetOf` constant on `get` is > reported as unnecessary... I'll file a bug. > > > {-# LANGUAGE TypeFamilies, TypeOperators, UndecidableInstances, > DataKinds #-} > {-# LANGUAGE ScopedTypeVariables #-} > > import GHC.TypeLits > import Data.Proxy > import Data.Word > import Foreign.Ptr > > type OffsetOf l xs = GetOffset 0 l xs > > type family ByteSize x where > ByteSize Word64 = 8 > ByteSize Word32 = 4 > ByteSize Word16 = 2 > ByteSize Word8 = 1 > ByteSize a = TypeError (Text "The type " :<>: ShowType a :<>: > Text " is not exportable.") > > type family GetOffset n (l :: Symbol) xs where > GetOffset n l ( '(l,a) ': xs) = '(n,a) > GetOffset n l ( '(x,a) : xs) = GetOffset (n+ByteSize a) l xs > GetOffset n l '[] = TypeError (Text "Missing field: " :<>: > > ShowType l) > > newtype Struct (a :: [(Symbol,*)]) = Struct (Ptr ()) > > > get :: forall l fs n a. > (OffsetOf l fs ~ '(n,a), KnownNat n) => > Struct fs -> > Proxy l -> > Ptr a > get (Struct p) _ = plusPtr p (fromInteger (natVal (Proxy :: Proxy n))) > > > type MyStruct = [ '("A",Word8), '("B",Word8), '("C",Int) ] > > testOk :: Struct MyStruct -> Ptr Word8 > testOk s = get s (Proxy :: Proxy "B") > > > {- > testNotOk :: Struct MyStruct -> Ptr Word8 > testNotOk s = get s (Proxy :: Proxy "X") > --} > > {- > type MyOtherStruct = [ '("A",Int), '("B",Word8) ] > > testNotOk :: Struct MyOtherStruct -> Ptr Word8 > testNotOk s = get s (Proxy :: Proxy "B") > --} > > > > > > > > On Mon, Nov 16, 2015 at 1:21 PM, Ben Gamari > wrote: > > > While preparing some additional documentation for Iavor's custom type > errors work (which has been merged; thanks Iavor!) I noticed that > Dominique Devriese has raised some additional questions on the proposal > [1]. > > In particular, Dominique suggests that perhaps TypeError should simply > be of kind `ErrorMessage -> Constraint`. My understanding of the > proposal is that the intention is that `TypeError`s should be usable on > the RHS of type functions, like `error` on the term level. However, is > this strictly necessary? Is there any place where you couldn't just as > easily express the `TypeError` as a constraint? > > If not, it seems like this may be substantially simpler approach and > totally side-steps the detection of `TypeError` in inappropriate places > on the RHS. > > Regardless, it seems like this (and the other questions) is worth > addressing in the proposal. > > Cheers, > > - Ben > > > [1] > https://ghc.haskell.org/trac/ghc/wiki/Proposal/CustomTypeErrors#SomedesignquestionsDominiqueDevriese: > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From stegeman at gmail.com Tue Nov 17 11:49:30 2015 From: stegeman at gmail.com (Luite Stegeman) Date: Tue, 17 Nov 2015 11:49:30 +0000 Subject: Remote GHCi In-Reply-To: <564AFD2F.6020305@gmail.com> References: <564AFD2F.6020305@gmail.com> Message-ID: I like this idea, and it overlaps very much with the work that still needs to be done for GHCJSi. I think that for Template Haskell, the restriction that everything has to be marshalled via Binary is not too problematic, although it'd require a bit of care if Richard's pre-proposal to expose more GHC types to TH ( #11081 ) is to be implemented. In particular, the API for querying the type environment would have to remain implementable via message passing, so we can't expose the full TcRn there. compileExpr / dynCompileExpr seem to get some use, perhaps mostly through the hint package: http://packdeps.haskellers.com/reverse/hint But I think the most common use case is just compiling and running Haskell expressions, without any specific need for interpreted code. The machinery behind hint could be reworked to have the GHC API produce a dynamic library for the compiled expression, which could then be loaded into the current process with the system linker. Or is there some reason that this approach would be unusable? luite On Tue, Nov 17, 2015 at 10:10 AM Simon Marlow wrote: > Hi folks - I've been thinking about changing the way we run interpreted > code so that it would be run in a separate process. It turns out this > has quite a few benefits, and would let us kill some of the really > awkward hacks we have in GHC to work around problems that arise because > we're running interpreted code and the compiler on the same runtime. > > I summarised the idea here: > https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi > > I'd be interested to hear if anyone has any thoughts around this, > particularly if doing this would make your life difficult in some way. > Are people relying on dynCompileExpr for anything? > > Cheers, > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominique.devriese at cs.kuleuven.be Tue Nov 17 12:02:28 2015 From: dominique.devriese at cs.kuleuven.be (Dominique Devriese) Date: Tue, 17 Nov 2015 13:02:28 +0100 Subject: Further custom type error questions In-Reply-To: <564B1027.4070902@ro-che.info> References: <876111zllh.fsf@smart-cactus.org> <564B1027.4070902@ro-che.info> Message-ID: FWIW: I didn't realise that this kind of example was the point of TypeError being kind-polymorphic, thanks for the clarification. I don't see an easy way of encoding this using the simpler alternative I suggested, so my question is answered. In hindsight, the wiki does already show an example like this, so I must have missed this, sorry. Thanks, see you, Dominique PS: I would still be interested if anyone has thoughts about the TypeWarning thing I suggested... 2015-11-17 12:31 GMT+01:00 Roman Cheplyaka : > Iavor, Ben, et al.: > > How about much simpler > > type family Head (a :: [k]) :: k where > Head (x ': xs) = x > Head '[] = Error "Empty list" > > Can this be expressed through Error-as-constraint? > > On 11/17/2015 02:09 AM, Iavor Diatchki wrote: >> Hello, >> >> I imagine people wanting to do things as in the example below. If we >> were to use only `TypeError` constraints, then we'd have to mostly use >> the class system to do type-level evaluation. It doesn't seem obvious >> how to do that with just `TypeError` of kind constraint, unless all >> evaluation was to happen using the class system. >> >> -Iavor >> PS: Interestingly, this example reveals a bug with GHC's new warning >> about unused constraints, where the `OffsetOf` constant on `get` is >> reported as unnecessary... I'll file a bug. >> >> >> {-# LANGUAGE TypeFamilies, TypeOperators, UndecidableInstances, >> DataKinds #-} >> {-# LANGUAGE ScopedTypeVariables #-} >> >> import GHC.TypeLits >> import Data.Proxy >> import Data.Word >> import Foreign.Ptr >> >> type OffsetOf l xs = GetOffset 0 l xs >> >> type family ByteSize x where >> ByteSize Word64 = 8 >> ByteSize Word32 = 4 >> ByteSize Word16 = 2 >> ByteSize Word8 = 1 >> ByteSize a = TypeError (Text "The type " :<>: ShowType a :<>: >> Text " is not exportable.") >> >> type family GetOffset n (l :: Symbol) xs where >> GetOffset n l ( '(l,a) ': xs) = '(n,a) >> GetOffset n l ( '(x,a) : xs) = GetOffset (n+ByteSize a) l xs >> GetOffset n l '[] = TypeError (Text "Missing field: " :<>: >> >> ShowType l) >> >> newtype Struct (a :: [(Symbol,*)]) = Struct (Ptr ()) >> >> >> get :: forall l fs n a. >> (OffsetOf l fs ~ '(n,a), KnownNat n) => >> Struct fs -> >> Proxy l -> >> Ptr a >> get (Struct p) _ = plusPtr p (fromInteger (natVal (Proxy :: Proxy n))) >> >> >> type MyStruct = [ '("A",Word8), '("B",Word8), '("C",Int) ] >> >> testOk :: Struct MyStruct -> Ptr Word8 >> testOk s = get s (Proxy :: Proxy "B") >> >> >> {- >> testNotOk :: Struct MyStruct -> Ptr Word8 >> testNotOk s = get s (Proxy :: Proxy "X") >> --} >> >> {- >> type MyOtherStruct = [ '("A",Int), '("B",Word8) ] >> >> testNotOk :: Struct MyOtherStruct -> Ptr Word8 >> testNotOk s = get s (Proxy :: Proxy "B") >> --} >> >> >> >> >> >> >> >> On Mon, Nov 16, 2015 at 1:21 PM, Ben Gamari > > wrote: >> >> >> While preparing some additional documentation for Iavor's custom type >> errors work (which has been merged; thanks Iavor!) I noticed that >> Dominique Devriese has raised some additional questions on the proposal >> [1]. >> >> In particular, Dominique suggests that perhaps TypeError should simply >> be of kind `ErrorMessage -> Constraint`. My understanding of the >> proposal is that the intention is that `TypeError`s should be usable on >> the RHS of type functions, like `error` on the term level. However, is >> this strictly necessary? Is there any place where you couldn't just as >> easily express the `TypeError` as a constraint? >> >> If not, it seems like this may be substantially simpler approach and >> totally side-steps the detection of `TypeError` in inappropriate places >> on the RHS. >> >> Regardless, it seems like this (and the other questions) is worth >> addressing in the proposal. >> >> Cheers, >> >> - Ben >> >> >> [1] >> https://ghc.haskell.org/trac/ghc/wiki/Proposal/CustomTypeErrors#SomedesignquestionsDominiqueDevriese: >> >> >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From marlowsd at gmail.com Tue Nov 17 13:36:10 2015 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 17 Nov 2015 13:36:10 +0000 Subject: Remote GHCi In-Reply-To: References: <564AFD2F.6020305@gmail.com> Message-ID: <564B2D4A.50403@gmail.com> CC Daniel Corin, maintainer of hint. On 17/11/2015 11:49, Luite Stegeman wrote: > I like this idea, and it overlaps very much with the work that still > needs to be done for GHCJSi. I think that for Template Haskell, the > restriction that everything has to be marshalled via Binary is not too > problematic, although it'd require a bit of care if Richard's > pre-proposal to expose more GHC types to TH ( #11081 ) is to be > implemented. In particular, the API for querying the type environment > would have to remain implementable via message passing, so we can't > expose the full TcRn there. > > compileExpr / dynCompileExpr seem to get some use, perhaps mostly > through the hint package: > > http://packdeps.haskellers.com/reverse/hint > > But I think the most common use case is just compiling and running > Haskell expressions, without any specific need for interpreted code. The > machinery behind hint could be reworked to have the GHC API produce a > dynamic library for the compiled expression, which could then be loaded > into the current process with the system linker. Or is there some reason > that this approach would be unusable? I don't think that simplifies the problem, we would still be dynamically loading and running code in the current process, which is exactly what we do now. The issue is with interpret :: (MonadInterpreter m, Typeable a) => String -> a -> m a which would need to become interpret :: (MonadInterpreter m, Typeable a, Binary a) => String -> a -> m a or else we have to keep the current single-process mechanism for this use case. Cheers, Simon > luite > > On Tue, Nov 17, 2015 at 10:10 AM Simon Marlow > wrote: > > Hi folks - I've been thinking about changing the way we run interpreted > code so that it would be run in a separate process. It turns out this > has quite a few benefits, and would let us kill some of the really > awkward hacks we have in GHC to work around problems that arise because > we're running interpreted code and the compiler on the same runtime. > > I summarised the idea here: > https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi > > I'd be interested to hear if anyone has any thoughts around this, > particularly if doing this would make your life difficult in some way. > Are people relying on dynCompileExpr for anything? > > Cheers, > Simon > From eir at cis.upenn.edu Tue Nov 17 14:15:57 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 17 Nov 2015 09:15:57 -0500 Subject: too many lines too long In-Reply-To: <564AFF24.2090308@gmail.com> References: <966B4013-23C0-45EA-975A-6506707A555E@cis.upenn.edu> <56432EA6.40502@jacobs-university.de> <201511131601.35607.jan.stolarek@p.lodz.pl> <564AFF24.2090308@gmail.com> Message-ID: We have such a thing: https://ghc.haskell.org/trac/ghc/wiki/Commentary/CodingStyle I don't think its widely consulted or respected, though. Richard On Nov 17, 2015, at 5:19 AM, Simon Marlow wrote: > On 13/11/2015 15:01, Jan Stolarek wrote: >> My view on this is: >> >> Firstly, I hate explaining myself to Arcanist. When prompted to explain the reason for too long >> lines I typically enter "wontfix" without thinking too much. >> >> Secondly, I really don't like how warnings clutter code reviews. >> >> I have my Emacs highlight text beyond 80th column with a really ugly colour, so I strive real hard >> to maintain 80-column limit whenever possible. But sometimes fitting in that limit is nearly >> impossible: imagine being in a let nested in a do-notation nested in a guard nested in a where >> clause. Approx. 15-20 columns are lost for the indentation. Nevertheless I would support >> introducing a hard limit on having no more than 80 columns. >> >> Janek >> >> PS. It makes me really sad that we don't have any coding convention for GHC: we mix camelCase with >> underscore_case, indentation is inconsistent (good thing we at least got rid of tabs!), >> whitespace usage is inconsistent, etc. I could make this list very long. > > Why not write down a set of style guidelines and get everyone to agree to them? I'd happily compromise my personal stylistic preferences if there was a standard style that we all agreed on and tried to adhere to. > > Personally I think a good starting point is http://chrisdone.github.io/hindent/HIndent-Styles-JohanTibell.html > > Incidentally the mixed camelCase and underscore style is deliberate: underscores for local identifiers, camelCase for exported functions. It's a cute idea I've been using for a long time, but we don't have to do it that way. At work we use camelCase exclusively and it's fine. > > Cheers, > Simon > >> --- >> Politechnika ????dzka >> Lodz University of Technology >> >> Tre???? tej wiadomo??ci zawiera informacje przeznaczone tylko dla adresata. >> Je??eli nie jeste??cie Pa??stwo jej adresatem, b??d?? otrzymali??cie j?? przez pomy??k?? >> prosimy o powiadomienie o tym nadawcy oraz trwa??e jej usuni??cie. >> >> This email contains information intended solely for the use of the individual to whom it is addressed. >> If you are not the intended recipient or if you have received this message in error, >> please notify the sender and delete it from your system. >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From eir at cis.upenn.edu Tue Nov 17 14:29:54 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 17 Nov 2015 09:29:54 -0500 Subject: Remote GHCi In-Reply-To: <564AFD2F.6020305@gmail.com> References: <564AFD2F.6020305@gmail.com> Message-ID: <8498A048-6385-4065-8920-C0A8639C4508@cis.upenn.edu> How does this interact with typechecker plugins? I assume they would still happen in GHC's process. I've also been thinking about designing and implementing a mechanisms where programmers could specify custom pretty-printers for their types, and GHC would use these pretty-printers in error messages. This action would also probably need to be in the same process. Would either of these ideas be affected? My guess is "no", because we should be able to be selective in what gets farmed out to the second process and what stays locally. Richard On Nov 17, 2015, at 5:10 AM, Simon Marlow wrote: > Hi folks - I've been thinking about changing the way we run interpreted code so that it would be run in a separate process. It turns out this has quite a few benefits, and would let us kill some of the really awkward hacks we have in GHC to work around problems that arise because we're running interpreted code and the compiler on the same runtime. > > I summarised the idea here: https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi > > I'd be interested to hear if anyone has any thoughts around this, particularly if doing this would make your life difficult in some way. Are people relying on dynCompileExpr for anything? > > Cheers, > Simon > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From alexander at plaimi.net Tue Nov 17 14:31:25 2015 From: alexander at plaimi.net (Alexander Berntsen) Date: Tue, 17 Nov 2015 15:31:25 +0100 Subject: too many lines too long In-Reply-To: References: <966B4013-23C0-45EA-975A-6506707A555E@cis.upenn.edu> <56432EA6.40502@jacobs-university.de> <201511131601.35607.jan.stolarek@p.lodz.pl> <564AFF24.2090308@gmail.com> Message-ID: <564B3A3D.8060205@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 17/11/15 15:15, Richard Eisenberg wrote: > We have such a thing: > https://ghc.haskell.org/trac/ghc/wiki/Commentary/CodingStyle > > I don't think its widely consulted or respected, though. There are several issues here. (Get rid of tabs v. spaces for instance.) In general it's just too complicated. Successful coding guidelines are in my experience a line or two to explain each point, and then an example or two. Anyway, I read these, but quickly enough found out that the best strategy was to just try to fit in with the existing code. We should simplify them and make a more pretty site for them. Something like [0], although that's a bit wordy for my taste. Then we need to decide on how to "get there". E.g. do we enforce all new files to follow it rigorously, but adhere to the dominating style of the file you are changing? Do we change the function we are modifying in a patch to adhere to the style? Do we just go through everything all at once and fix it once and for all, like with tabs? I'm not voting for any of them right now, but we need to consider them. [0] - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWSzo8AAoJENQqWdRUGk8BuYkQAMVLUfgdYaaduhTCeDBSACjC 9iP8AcmmTsMPbEcSvIA3u2c5wDSxJe1v4kJcglftylcCwLNZQgcVy9k05HlbRbDP CCUS/Glv1TM+s79xueH3ByispjrhZt7yJgdJ5SJbe43i9KyjAG+TaqfgyJRL5oiw 4VKRAfoT2RYm6cjG1WlnzGzDh4QF3y8F9MCZWVgAMbAIDU0gKyR1Mxpf3xSXb02y ObbCKiA3qqITqfjs1ZHXwaJqbg/F21uELS+veGZN149ylimm0zpVzolx9mRgYASv t/b20+qBtDBr/K0BQ/ZPzgx0d9TaYiGF2Jd1AE+m9P9cqPD7qPqljI2/G4Vn0g61 pEburlt4OdSdMlUCmsf3lXBDUMQrXDjBRkh8zMirlt/BzC9a6+9JOfjLixgFlDSV ohy3XmQVokeDWrcFmxz0FPWinU4P+5uQos0Jp/sO+fukRkormM089UYB7vRZVOn9 GtaBCA5FQSvgqfLbDpPDRHfYka5qLPXo9dKtyjjhqEXggwlVCys5rrF+y1B4qs9A XgENKexKtsg7aGc99KZh3t2rF7/jwKsdcVnAbEbyEUvZ9fqvtwZO6DN32YLjNLoV McVeGkLWhtw+ihD/E6VueUxk0ImCr8CpGGMxW7WvyPlQW3v/seU3l7Qezh1PkRZ/ jvj8PUJfGZA/GEZALpIv =tY36 -----END PGP SIGNATURE----- From ben at well-typed.com Tue Nov 17 15:22:22 2015 From: ben at well-typed.com (Ben Gamari) Date: Tue, 17 Nov 2015 16:22:22 +0100 Subject: Feature status for GHC 8.0 Message-ID: <87y4dwy7kh.fsf@smart-cactus.org> tldr. Please let us know the status of your patches for GHC 8.0. Hello everyone! You are receiving this message because you responsible for one of the in-flight items on the GHC 8.0 roadmap [1]. As you may know, the release is quickly approaching and we'd like to have final patches up for review in the next week or so. Until then we'd like to get an idea of how your various projects are progressing. Below is a list of the projects which we believe are still in progress along with my understanding of the state of your work. If you see your name in this list please let us know how things are going. * OverloadedRecordFields Adam Gundry Documentation needed Full ORF not happening? * Kind equality Richard Eisenberg Patches coming soon? * GADT pattern matching rework George Karachalias How is this coming along? * LLVM backend Austin Seipp Patches coming * Pattern synonyms Matthew Pickering Documentation needed (ongoing work in D1325) * Backpack work Edward Z. Yang How is this coming along? * Compact regions Giovanni Campagna Patches need revision Edward Z. Yang * Type signature sections Herbert Valerio Riedel Not pushing for 8.0? * DWARF-based stack traces and Ben Gamari statistical profiling Patches slowly being merged Documentation needed Thanks for all of your hard work! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ben at smart-cactus.org Tue Nov 17 15:49:37 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 17 Nov 2015 16:49:37 +0100 Subject: [ANNOUNCE] GHC 7.10.3 release candidate 1 In-Reply-To: <506D8F5A-AA06-4A73-8DE6-12B2332C15BF@cis.upenn.edu> References: <87fv0o8k3d.fsf@smart-cactus.org> <65A5651A-7C9D-4B6B-AEF2-459135E6ACB9@iki.fi> <6BA7E4B9-8791-4A31-BE90-4B632FAE423C@cis.upenn.edu> <506D8F5A-AA06-4A73-8DE6-12B2332C15BF@cis.upenn.edu> Message-ID: <87si44y6b2.fsf@smart-cactus.org> Richard Eisenberg writes: > On Nov 4, 2015, at 11:12 AM, Peter Trommler wrote: > >> It looks like a bug to me. > > I'm taking your "it" here to mean the fact that GHC is looking for > readelf on a Mac OS platform. I tend to agree -- I was surprised to > see this, but I'm almost-totally clueless about these things. > > Thanks for the info, > Richard > > PS: There's been much muttering about call stacks and DWARF. I haven't > a clue what DWARF is, but I always assumed that this nice feature > would not be available on Macs. What I realized today is that this > assumption likely stems from the fact that ELF is not for Mac. ELFs > and DWARFs tend to be found near one another in other settings, but > perhaps this fact doesn't carry over to computer architectures. :) > DWARF is a standard for expressing debug information about compiled native programs. It is used by almost all modern operating systems (including OS X; the only notable exception is Windows, naturally). Indeed the name is a not-so-subtle reference to the fact that DWARF debug information will often be found within ELF object files. Recently I have been working on using the mechanisms that came out of Peter Wortmann's thesis to provide better stack traces and (statistical) profiling support for Haskell code. While at the moment I am focusing on Linux, there is little reason why this couldn't (fairly easily, I suspect) be extended to work on OS X. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From vagarenko at gmail.com Tue Nov 17 15:54:57 2015 From: vagarenko at gmail.com (Alexey Vagarenko) Date: Tue, 17 Nov 2015 20:54:57 +0500 Subject: Implementation idea for unboxed polymorphic types In-Reply-To: References: <1194C002-769A-4232-A2BC-632875496F37@mazzo.li> Message-ID: At the moment, GHC does not support type families over kind #, but if it did, would this code do the trick https://gist.github.com/vagarenko/077c6dd73cd610269aa9 ? 2015-11-16 22:32 GMT+05:00 ?mer Sinan A?acan : > > But I don't see why you'd need quoting at constructor calls. Couldn't you > > just have a type class like `PointFamily`? > > This is exactly right, my memory has failed me. My initial implementation > didn't use the type family trick, I had further attempts that use type > families > but honestly I don't remember how good it worked. This was quite a while > ago. > > 2015-11-15 19:41 GMT-05:00 Richard Eisenberg : > > After reading Francesco's original post, I immediately thought of ?mer's > proposed approach, of using Template Haskell to produce the right data > family instances. But I don't see why you'd need quoting at constructor > calls. Couldn't you just have a type class like `PointFamily`? I'd be more > interested to see client code in ?mer's version than the TH generation code. > > > > The TH approach would seem to require having a fixed set of > specializations, which is a downside. But I'm not sure it's so much of a > downside that the approach is unusable. > > > > Richard > > > > On Nov 15, 2015, at 10:08 AM, ?mer Sinan A?acan > wrote: > > > >> I had started working on exactly the same thing at some point. I had a > >> TemplateHaskell-based implementation which _almost_ worked. > >> > >> The problem was that the syntax was very, very heavy. Because I had to > use > >> quotes for _every_ constructor application(with explicitly passed > types). > >> (because I had a specialized constructor for every instantiation of this > >> generic type) > >> > >> Another problem was that because of how TemplateHaskell quotes > evaluated, I > >> couldn't use a `List Int` where `List` is a template without first > manually > >> adding a line for generating specialized version of `List` on `Int`. > >> > >> When all of these combined it became very hard to use. But it was a > >> proof-of-concept and I think it worked. > >> > >> (Code is horrible so I won't share it here :) I had to maintain a state > shared > >> with different TH quote evaluations etc.) > >> > >> 2015-11-15 5:26 GMT-05:00 Francesco Mazzoli : > >>> (A nicely rendered version of this email can be found at < > https://gist.github.com/bitonic/52cfe54a2dcdbee1b7f3>) > >>> > >>> ## Macro types > >>> > >>> I very often find myself wanting unboxed polymorphic types > >>> (e.g. types that contain `UNPACK`ed type variables). I find > >>> it extremely frustrating that it's easier to write fast _and_ > >>> generic code in C++ than in Haskell. > >>> > >>> I'd like to submit to the mailing list a very rough proposal > >>> on how this could be achieved in a pretty straightforward way > >>> in GHC. > >>> > >>> The proposal is meant to be a proof of concept, just to show that > >>> this could be done rather easily. I did not think about a nice > >>> interface or the implementation details in GHC. My goal is to > >>> check the feasibility of this plan with GHC developers. > >>> > >>> I'll call such types "macro types", since their effect is similar > >>> to defining a macro that defines a new type for each type > >>> variable instantiation. > >>> > >>> Consider > >>> > >>> ``` > >>> data #Point a = Point > >>> { x :: {-# UNPACK #-} !a > >>> , y :: {-# UNPACK #-} !a > >>> } > >>> ``` > >>> > >>> This definition defines the macro type `#Point`, with one parameter > >>> `a`. > >>> > >>> Macro types definition would be allowed only for single-constructor > >>> records. The intent is that if we mention `#Point Double`, it will > >>> be equivalent to > >>> > >>> ``` > >>> data PointDouble = PointDouble > >>> { x :: {-# UNPACK #-} !Double > >>> , y :: {-# UNPACK #-} !Double > >>> } > >>> ``` > >>> > >>> To use `#Point` generically, the following type class would be > >>> generated: > >>> > >>> ``` > >>> class PointFamily a where > >>> data #Point a :: * -- Family of types generated by @data #Point a at . > >>> #Point :: a -> a -> #Point a -- Constructor. > >>> #x :: #Point a -> a -- Projection @x at . > >>> #y :: #Point a -> a -- Projection @y at . > >>> ``` > >>> > >>> Thi type class lets us work with `#Point`s generically, for example > >>> > >>> ``` > >>> distance :: (PointFamily a, Fractional a) => #Point a -> #Point a -> a > >>> distance p1 p2 = > >>> let dx = #x p1 - #x p2 > >>> dy = #y p1 - #y p2 > >>> in sqrt (dx*dx + dy*dy) > >>> ``` > >>> > >>> Internally, for every type appearing for `a`, e.g. `#Point Double`, > >>> a new type equivalent to the `PointDouble` above would be generated > >>> by GHC, with the corresponding instance > >>> > >>> ``` > >>> instance PointFamily Double where > >>> data #Point Double = PointDouble > >>> #x = x > >>> #y = x > >>> ``` > >>> > >>> If it's not possible to instantiate `#Point` with the provided type > >>> (for example because the type is not `UNPACK`able, e.g. > >>> `#Point (Maybe A)`), GHC would throw an error. > >>> > >>> Note that we can compile `distance` in its polymorphic version > >>> (as opposed to C++ templates, where template functions _must_ be > >>> instantiated at every use). The polymorphic `distance` would > >>> require a call to "virtual functions" `#x` and `#y`, as provided by > >>> the `PointFamily` dictionary. But if we use > >>> `INLINE` or `SPECIALIZE` pragmas the virtual calls to `#x` and `#y` > >>> would disappear, making this as efficient as if we were to define > >>> `distance` on the manually defined `PointDouble`. Compiler hints > >>> would be put in place to always inline functions using macro types, > >>> if possible. > >>> > >>> Note that the inlining is only important so that the `PointFamily` > >>> dictionary disappears, e.g. functions containing recursive > >>> helpers are fine, such as > >>> > >>> ``` > >>> {-# INLINE leftmost #-} > >>> leftmost :: forall a. (PointFamily a, Ord a) => [#Point a] -> #Point a > >>> leftmost [] = error "leftmost: no points" > >>> leftmost (p0 : ps0) = go p0 ps0 > >>> where > >>> go :: #Point a -> [#Point a] -> Point# a > >>> go candidate (p : ps) = > >>> if #x p < #x candidate > >>> then go p ps > >>> else go candidate ps > >>> ``` > >>> > >>> It might be worth considering throwing a warning when a top-level > >>> definition whose type contains a macro type cannot be inlined, since > >>> the main performance benefit of using macro types would be lost. > >>> > >>> We can define instances for these types as normal, for instance > >>> > >>> ``` > >>> instance (Show a, PointFamily a) => Show (#Point a) where > >>> {-# INLINE show #-} > >>> show pt = "Point{x = " ++ #x pt ++ ", y = " ++ #y pt ++ "}" > >>> ``` > >>> > >>> `deriving` support could also be added. > >>> > >>> ## Further ideas > >>> > >>> ### Hide or remove `PointFamily` from the user > >>> > >>> In the examples above `PointFamily` is manipulated explicitely > >>> (e.g. in the type signature for `distance`). > >>> In most cases the right constraint could be generated > >>> automatically by GHC, although I think direct access to the > >>> type class would be beneficial (history shows that direct > >>> access to these facilities is good, see upcoming explicit > >>> type applications). > >>> > >>> Maybe the type class associated to a macro type should not even > >>> exist -- for example we could simply represent `#Point` as a type > >>> family and treat construction and destruction as built-in syntax > >>> (the `#` prefix). > >>> > >>> ### Pattern matching > >>> > >>> Sugar could be added to pattern match, e.g. > >>> > >>> ``` > >>> foo :: Point# a -> ... > >>> distance (Point# x1 y1) = ... > >>> or > >>> dinstance Point#{..} = ... -- #x and #y are available > >>> ``` > >>> > >>> ### No "record types" limitation > >>> > >>> Instead of restricting ourselves to single-constructor records, > >>> we could simply generate > >>> > >>> ``` > >>> data Point a = Point a > >>> { x :: !a > >>> , y :: !a > >>> } > >>> > >>> class PointFamily a where > >>> data Point# a :: * > >>> destruct :: Point# a -> Point a > >>> construct :: Point a -> Point# a > >>> ``` > >>> > >>> However, I think it would be harder to guarantee the well-behavedness > >>> of the inlined functions if we had this intermediate type. I also > >>> don't think macro types would be very useful beyond polymorphic > >>> unboxed types. > >>> _______________________________________________ > >>> ghc-devs mailing list > >>> ghc-devs at haskell.org > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Tue Nov 17 16:40:58 2015 From: ben at well-typed.com (Ben Gamari) Date: Tue, 17 Nov 2015 17:40:58 +0100 Subject: [commit: ghc] master: Remove PatSynBuilderId (2208011) In-Reply-To: <371c6d358c3e47ae885ecfa49d49ccbe@DB4PR30MB030.064d.mgd.msft.net> References: <20151107235023.DD7BF3A300@ghc.haskell.org> <2a4628524e7d49acae7ab7e31db3690e@DB4PR30MB030.064d.mgd.msft.net> <371c6d358c3e47ae885ecfa49d49ccbe@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <87oaesy3xh.fsf@smart-cactus.org> Simon Peyton Jones writes: > | I don't think this would work in the case where there are no fields > | initialised? > > Oh yes, silly me. I was thinking that then we wouldn?t need to look at > 'labels' at all, but that's not true. > > Well, at least then I'd replace [PostTc id [FieldLabel] with (PostTc > ConLike). This makes it like ConPatOut in HsPat. Then the (Located id) > field is redundant (we can get it from the ConLike), but that?s only > true after typechecking, so maybe simpler to keep both. > > It amounts to moving the call to conLikeFieldLabels from tcExpr > (RecordCon ...) to dsExpr (RecordCon ...). A small thing but I think > it'd be better. > Mathew, did you ever get to this? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From andrew.gibiansky at gmail.com Tue Nov 17 17:11:07 2015 From: andrew.gibiansky at gmail.com (Andrew Gibiansky) Date: Tue, 17 Nov 2015 09:11:07 -0800 Subject: Remote GHCi In-Reply-To: <8498A048-6385-4065-8920-C0A8639C4508@cis.upenn.edu> References: <564AFD2F.6020305@gmail.com> <8498A048-6385-4065-8920-C0A8639C4508@cis.upenn.edu> Message-ID: Simon, As Sumit said, we use dynCompileExpr for core functionality of IHaskell. I am not really sure how the change you are proposing affects that, though. We use dynCompileExpr in several places for evaluation inside the interpreter context: 1. Evaluating a Haskell expression in the interpreter context, converting the result to a ByteString, then using fromDynamic to extract the bytestring and convert it to a value in the compiled context. 2. Getting a file handle from the interpreter context to the compiled context; this does not actually use dynCompileExpr because there were some bugs with dynCompileExpr and so I had to literally copy source from InteractiveEval to reimplement parts of dynCompileExpr (unrelated: the issue was that dyncompileexpr imported and then unimported Data.Dynamic, and this messed with data declarations that had already been created in the interpreter context) 3. Extracting IO a values from the interpreted context to the compiled context so that they could be run; this is necessary to get displayed values from the interpreter back to the compiled code. I think two of our uses, which are both very central to the way IHaskell works, would be impacted by requiring a Binary instance (or similar), which is what I think you are proposing (since we have two uses at least where we marshall `IO x` values via dynCompileExpr, which cannot be serialized, I believe.) I am sure that there are alternative ways to do what we are doing, but they are probably not simple and would take quite a bit of work. -- Andrew On Tue, Nov 17, 2015 at 6:29 AM, Richard Eisenberg wrote: > How does this interact with typechecker plugins? I assume they would still > happen in GHC's process. > > I've also been thinking about designing and implementing a mechanisms > where programmers could specify custom pretty-printers for their types, and > GHC would use these pretty-printers in error messages. This action would > also probably need to be in the same process. > > Would either of these ideas be affected? My guess is "no", because we > should be able to be selective in what gets farmed out to the second > process and what stays locally. > > Richard > > On Nov 17, 2015, at 5:10 AM, Simon Marlow wrote: > > > Hi folks - I've been thinking about changing the way we run interpreted > code so that it would be run in a separate process. It turns out this has > quite a few benefits, and would let us kill some of the really awkward > hacks we have in GHC to work around problems that arise because we're > running interpreted code and the compiler on the same runtime. > > > > I summarised the idea here: > https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi > > > > I'd be interested to hear if anyone has any thoughts around this, > particularly if doing this would make your life difficult in some way. Are > people relying on dynCompileExpr for anything? > > > > Cheers, > > Simon > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sumit.sahrawat.apm13 at iitbhu.ac.in Tue Nov 17 17:20:48 2015 From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing, IIT (BHU)) Date: Tue, 17 Nov 2015 22:50:48 +0530 Subject: Remote GHCi In-Reply-To: <8498A048-6385-4065-8920-C0A8639C4508@cis.upenn.edu> References: <564AFD2F.6020305@gmail.com> <8498A048-6385-4065-8920-C0A8639C4508@cis.upenn.edu> Message-ID: The use-case which I've worked on deals with widget messages. Widgets are stored inside the kernel, and can recieve signals from user code, frontend events etc. To capture messages sent by the user code, the messages are queued in a TChan inside the interpreter environment. Messages from this TChan are extracted into the kernel using dynCompileExpr and fromDynamic, and processed as required. The user input code is executed in the interpreter context, but we also need to gather information some more information from the context, which is why dynCompileExpr is crucial there. On 17 November 2015 at 19:59, Richard Eisenberg wrote: > How does this interact with typechecker plugins? I assume they would still > happen in GHC's process. > > I've also been thinking about designing and implementing a mechanisms > where programmers could specify custom pretty-printers for their types, and > GHC would use these pretty-printers in error messages. This action would > also probably need to be in the same process. > > Would either of these ideas be affected? My guess is "no", because we > should be able to be selective in what gets farmed out to the second > process and what stays locally. > > Richard > > On Nov 17, 2015, at 5:10 AM, Simon Marlow wrote: > > > Hi folks - I've been thinking about changing the way we run interpreted > code so that it would be run in a separate process. It turns out this has > quite a few benefits, and would let us kill some of the really awkward > hacks we have in GHC to work around problems that arise because we're > running interpreted code and the compiler on the same runtime. > > > > I summarised the idea here: > https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi > > > > I'd be interested to hear if anyone has any thoughts around this, > particularly if doing this would make your life difficult in some way. Are > people relying on dynCompileExpr for anything? > > > > Cheers, > > Simon > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Regards Sumit Sahrawat -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Nov 17 17:42:36 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 17 Nov 2015 17:42:36 +0000 Subject: [commit: ghc] master: Remove PatSynBuilderId (2208011) In-Reply-To: <87oaesy3xh.fsf@smart-cactus.org> References: <20151107235023.DD7BF3A300@ghc.haskell.org> <2a4628524e7d49acae7ab7e31db3690e@DB4PR30MB030.064d.mgd.msft.net> <371c6d358c3e47ae885ecfa49d49ccbe@DB4PR30MB030.064d.mgd.msft.net> <87oaesy3xh.fsf@smart-cactus.org> Message-ID: <21b023bbd515490e9068f06d89683663@DB4PR30MB030.064d.mgd.msft.net> I will do it if Matthew doesn't get to it Simon | -----Original Message----- | From: Ben Gamari [mailto:ben at well-typed.com] | Sent: 17 November 2015 16:41 | To: Simon Peyton Jones; Matthew Pickering | Cc: ghc-devs at haskell.org | Subject: RE: [commit: ghc] master: Remove PatSynBuilderId (2208011) | | Simon Peyton Jones writes: | | > | I don't think this would work in the case where there are no fields | > | initialised? | > | > Oh yes, silly me. I was thinking that then we wouldn?t need to look at | > 'labels' at all, but that's not true. | > | > Well, at least then I'd replace [PostTc id [FieldLabel] with (PostTc | > ConLike). This makes it like ConPatOut in HsPat. Then the (Located id) | > field is redundant (we can get it from the ConLike), but that?s only | > true after typechecking, so maybe simpler to keep both. | > | > It amounts to moving the call to conLikeFieldLabels from tcExpr | > (RecordCon ...) to dsExpr (RecordCon ...). A small thing but I think | > it'd be better. | > | Mathew, did you ever get to this? | | Cheers, | | - Ben From stegeman at gmail.com Tue Nov 17 19:02:42 2015 From: stegeman at gmail.com (Luite Stegeman) Date: Tue, 17 Nov 2015 19:02:42 +0000 Subject: Remote GHCi In-Reply-To: <8498A048-6385-4065-8920-C0A8639C4508@cis.upenn.edu> References: <564AFD2F.6020305@gmail.com> <8498A048-6385-4065-8920-C0A8639C4508@cis.upenn.edu> Message-ID: I've been thinking of these applications before, in the context of cross compilers, and of how to deal with these things as dependencies. Custom error message formatting could be done in the same way as Template Haskell I think, since there appears to be a reasonably well-defined place where these are needed, and the cost of marshalling the data does not look prohibitive for this application. It could run in the Quasi monad (which would perhaps get some extensions) with type similar to formatError :: Quasi m => TypeError -> m (Maybe Doc) (IDE people will argue that errors shouldn't be formatted as Doc, some structured error message format is needed, we could add that later) Two questions: - Which formatters would be loaded by GHC? Would libraries supply formatters that automatically get loaded by everything that depends on the package? - How would GHC decide which formatter(s) to call for a specific error? As for typechecker (and also core-to-core) plugins: Am I right in thinking that these can usually be treated as a separate build tool, where having it in a separate package is not too problematic? This way, plugins could be loaded from dynamic libraries at startup (or for platforms where this is problematic, GHC could bootstrap itself by linking the plugins statically). Plugins would be built for the host platform, so GHC's package database, which lists packages for the target platform, may not be relevant at all. Cabal would only need to check whether GHC can somehow load pluginpackage-x.y.z before proceeding with the build. I like the idea of extending GHC in various places, but for GHCJS I do need a somewhat workable story for cross-compilation. (Of course I could make GHCJS a non-crosscompiler, by compiling the whole compiler to JS and running everything in a JS runtime; everything would magically work again, but that's a bit too deep down the rabbit-hole for me at the time...) luite Am I right in thinking that typechecker plugins are a special On Tue, Nov 17, 2015 at 2:30 PM Richard Eisenberg wrote: > How does this interact with typechecker plugins? I assume they would still > happen in GHC's process. > > I've also been thinking about designing and implementing a mechanisms > where programmers could specify custom pretty-printers for their types, and > GHC would use these pretty-printers in error messages. This action would > also probably need to be in the same process. > > Would either of these ideas be affected? My guess is "no", because we > should be able to be selective in what gets farmed out to the second > process and what stays locally. > > Richard > > On Nov 17, 2015, at 5:10 AM, Simon Marlow wrote: > > > Hi folks - I've been thinking about changing the way we run interpreted > code so that it would be run in a separate process. It turns out this has > quite a few benefits, and would let us kill some of the really awkward > hacks we have in GHC to work around problems that arise because we're > running interpreted code and the compiler on the same runtime. > > > > I summarised the idea here: > https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi > > > > I'd be interested to hear if anyone has any thoughts around this, > particularly if doing this would make your life difficult in some way. Are > people relying on dynCompileExpr for anything? > > > > Cheers, > > Simon > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Nov 17 22:31:27 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 17 Nov 2015 22:31:27 +0000 Subject: Window build broken Message-ID: <742ebc4814d848e3b259eb6cbef37bb2@DB4PR30MB030.064d.mgd.msft.net> Sigh. My Windows build is broken. See below. Any ideas? The stage2 complier in non-interactive mode works ok. It?s just ghci fails. What does ?Not x86_64 PEi386? mean? What can I do to fix? I should say that my laptop broke so this is a new Windows machine, presumably with a slightly different config? Simon ./inplace/bin/ghc-stage2 --interactive GHCi, version 7.11.20151117: http://www.haskell.org/ghc/ :? for help ghc-stage2.exe: panic! (the 'impossible' happened) (GHC version 7.11.20151117 for x86_64-unknown-mingw32): loadObj "C:\\code\\HEAD-1\\libraries\\ghc-prim\\dist-install\\build\\HSghc-prim-0.5.0.0.o": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ghc-stage2.exe: C:\code\HEAD-1\libraries\ghc-prim\dist-install\build\HSghc-prim-0.5.0.0.o: Not x86_64 PEi386 /cygdrive/c/code/HEAD-1$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.macek.0 at gmail.com Tue Nov 17 22:45:03 2015 From: david.macek.0 at gmail.com (David Macek) Date: Tue, 17 Nov 2015 23:45:03 +0100 Subject: Window build broken In-Reply-To: <742ebc4814d848e3b259eb6cbef37bb2@DB4PR30MB030.064d.mgd.msft.net> References: <742ebc4814d848e3b259eb6cbef37bb2@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <564BADEF.7000607@gmail.com> On 17. 11. 2015 23:31, Simon Peyton Jones wrote: > Sigh. My Windows build is broken. See below. Any ideas? The stage2 complier in non-interactive mode works ok. It?s just ghci fails. What does ?Not x86_64 PEi386? mean? What can I do to fix? Maybe it's obvious and you already checked, but could it be that the object file is for a different architecture? What does `file` say about it? -- David Macek -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4254 bytes Desc: S/MIME Cryptographic Signature URL: From ben at well-typed.com Tue Nov 17 23:02:34 2015 From: ben at well-typed.com (Ben Gamari) Date: Wed, 18 Nov 2015 00:02:34 +0100 Subject: Window build broken In-Reply-To: <742ebc4814d848e3b259eb6cbef37bb2@DB4PR30MB030.064d.mgd.msft.net> References: <742ebc4814d848e3b259eb6cbef37bb2@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <87egfoxm9h.fsf@smart-cactus.org> Simon Peyton Jones writes: > Sigh. My Windows build is broken. See below. Any ideas? The stage2 > complier in non-interactive mode works ok. It?s just ghci fails. What > does ?Not x86_64 PEi386? mean? What can I do to fix? > > I should say that my laptop broke so this is a new Windows machine, > presumably with a slightly different config? > Hmm, very interesting. I hope this isn't the result of acce37f38bc3, which directly touched the Windows linker. Do you have this commit by any chance? I'll try to reproduce tomorrow. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From simonpj at microsoft.com Tue Nov 17 23:25:43 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 17 Nov 2015 23:25:43 +0000 Subject: Window build broken In-Reply-To: <87egfoxm9h.fsf@smart-cactus.org> References: <742ebc4814d848e3b259eb6cbef37bb2@DB4PR30MB030.064d.mgd.msft.net> <87egfoxm9h.fsf@smart-cactus.org> Message-ID: <0553fe056cad443ea6d468c5526dbcec@DB4PR30MB030.064d.mgd.msft.net> I have two builds failing in the same way. One is a branch that is not fully up to date, and doesn?t have acce37f38bc3. So it seems independent of whether that's there or not Simon | -----Original Message----- | From: Ben Gamari [mailto:ben at well-typed.com] | Sent: 17 November 2015 23:03 | To: Simon Peyton Jones ; ghc-devs at haskell.org | Cc: Tamar Christina | Subject: Re: Window build broken | | Simon Peyton Jones writes: | | > Sigh. My Windows build is broken. See below. Any ideas? The stage2 | > complier in non-interactive mode works ok. It?s just ghci fails. What | > does ?Not x86_64 PEi386? mean? What can I do to fix? | > | > I should say that my laptop broke so this is a new Windows machine, | > presumably with a slightly different config? | > | Hmm, very interesting. I hope this isn't the result of acce37f38bc3, | which directly touched the Windows linker. Do you have this commit by | any chance? | | I'll try to reproduce tomorrow. | | Cheers, | | - Ben From simonpj at microsoft.com Tue Nov 17 23:25:43 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 17 Nov 2015 23:25:43 +0000 Subject: Window build broken In-Reply-To: <564BADEF.7000607@gmail.com> References: <742ebc4814d848e3b259eb6cbef37bb2@DB4PR30MB030.064d.mgd.msft.net> <564BADEF.7000607@gmail.com> Message-ID: <9d77fb778a204a648007aba0f3f1e8aa@DB4PR30MB030.064d.mgd.msft.net> It says this: bash$ file libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.0.0.o libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.0.0.o: PE Unknown PE signature 0x742e x86-64 (stripped to external PDB), for MS Windows | -----Original Message----- | From: David Macek [mailto:david.macek.0 at gmail.com] | Sent: 17 November 2015 22:45 | To: Simon Peyton Jones ; ghc-devs at haskell.org | Subject: Re: Window build broken | | On 17. 11. 2015 23:31, Simon Peyton Jones wrote: | > Sigh. My Windows build is broken. See below. Any ideas? The stage2 | complier in non-interactive mode works ok. It?s just ghci fails. What does | ?Not x86_64 PEi386? mean? What can I do to fix? | | Maybe it's obvious and you already checked, but could it be that the object | file is for a different architecture? What does `file` say about it? | | -- | David Macek From lonetiger at gmail.com Tue Nov 17 23:43:56 2015 From: lonetiger at gmail.com (lonetiger at gmail.com) Date: Wed, 18 Nov 2015 00:43:56 +0100 Subject: Window build broken In-Reply-To: <9d77fb778a204a648007aba0f3f1e8aa@DB4PR30MB030.064d.mgd.msft.net> References: <742ebc4814d848e3b259eb6cbef37bb2@DB4PR30MB030.064d.mgd.msft.net> <564BADEF.7000607@gmail.com> <9d77fb778a204a648007aba0f3f1e8aa@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <564bbbbb.913bc20a.7a664.ffffc141@mx.google.com> Hi Simon, I?m wondering what environment you?re coming in, is it msys2? The prompt you showed earlier /cygdrive/c/code/HEAD-1$ Looks like cygwin. Tamar From: Simon Peyton Jones Sent: Wednesday, November 18, 2015 00:25 To: David Macek;ghc-devs at haskell.org Subject: RE: Window build broken It says this: bash$ file libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.0.0.o libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.0.0.o: PE Unknown PE signature 0x742e x86-64 (stripped to external PDB), for MS Windows | -----Original Message----- | From: David Macek [mailto:david.macek.0 at gmail.com] | Sent: 17 November 2015 22:45 | To: Simon Peyton Jones ; ghc-devs at haskell.org | Subject: Re: Window build broken | | On 17. 11. 2015 23:31, Simon Peyton Jones wrote: | > Sigh. My Windows build is broken. See below. Any ideas? The stage2 | complier in non-interactive mode works ok. It?s just ghci fails. What does | ?Not x86_64 PEi386? mean? What can I do to fix? | | Maybe it's obvious and you already checked, but could it be that the object | file is for a different architecture? What does `file` say about it? | | -- | David Macek _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Tue Nov 17 23:44:02 2015 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Tue, 17 Nov 2015 15:44:02 -0800 Subject: Window build broken Message-ID: Wow, I happened to try building GHC on Windows for the first time ever today, and I also experienced this error :) Interestingly, someone reported a very similar error to this on Trac, but for GHC 7.8.3 [1]. Here's where the error message comes from [2] in Linker.c: static int verifyCOFFHeader (COFF_header *hdr, pathchar *fileName) { if (hdr->Machine != 0x8664) { errorBelch("%" PATH_FMT ": Not x86_64 PEi386", fileName); return 0; } ... } Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/10437 [2] https://github.com/ghc/ghc/blob/233d1312bf15940fca5feca6884f965e7944b555/rts/Linker.c#L3355 From lonetiger at gmail.com Tue Nov 17 23:50:48 2015 From: lonetiger at gmail.com (lonetiger at gmail.com) Date: Wed, 18 Nov 2015 00:50:48 +0100 Subject: Window build broken In-Reply-To: References: Message-ID: <564bbd58.6650c20a.ed6b5.6460@mx.google.com> Well the error is correct, it?s just checking against the machine type in the PE spec: IMAGE_FILE_MACHINE_AMD64 0x8664 x64 So somewhere along the line an invalid PE file was generated (or for the wrong architecture). From: Ryan Scott Sent: Wednesday, November 18, 2015 00:44 To: ghc-devs at haskell.org Subject: Re: Window build broken Wow, I happened to try building GHC on Windows for the first time ever today, and I also experienced this error :) Interestingly, someone reported a very similar error to this on Trac, but for GHC 7.8.3 [1]. Here's where the error message comes from [2] in Linker.c: static int verifyCOFFHeader (COFF_header *hdr, pathchar *fileName) { if (hdr->Machine != 0x8664) { errorBelch("%" PATH_FMT ": Not x86_64 PEi386", fileName); return 0; } ... } Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/10437 [2] https://github.com/ghc/ghc/blob/233d1312bf15940fca5feca6884f965e7944b555/rts/Linker.c#L3355 _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Wed Nov 18 00:53:53 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Tue, 17 Nov 2015 16:53:53 -0800 Subject: Remote GHCi In-Reply-To: <564AFD2F.6020305@gmail.com> References: <564AFD2F.6020305@gmail.com> Message-ID: <1447807180-sup-4328@sabre> I like it. Let me make sure that I've understand this correctly: - While GHC doesn't need to be built with profiling if you want to use profiling in the interpeter, you will need multiple versions of the "server binary" for each way you want to implement. This should be pretty reasonable, because the server binary is a lot smaller than GHC. - It seems that GHC will ship bytecode and object code to the server binary. In this case, the interpeted code and compiled code CAN share data among each other; it is just when you want to share data with GHC that you must implement serialization. (Also, external bytecode format?!) - Many people have commented that their extensions use dynCompileExpr. I think these cases can be accommodated, by making the server binary not a standalone application, but a LIBRARY which can be linked against a custom application (e.g. IHaskell). The messages to be sent should not be the values/file descriptors, but the invocations that are being requested of GHC. Unfortunately, this does seem to imply that most things would have to be rewritten from scratch to not use the ghc-api, but use whatever this new library's interface over the message passing is. Honestly, it seems like the hard part is defining the message-passing protocol, esp. since the GHC API is as overgrown as it is today. Edward Excerpts from Simon Marlow's message of 2015-11-17 02:10:55 -0800: > Hi folks - I've been thinking about changing the way we run interpreted > code so that it would be run in a separate process. It turns out this > has quite a few benefits, and would let us kill some of the really > awkward hacks we have in GHC to work around problems that arise because > we're running interpreted code and the compiler on the same runtime. > > I summarised the idea here: https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi > > I'd be interested to hear if anyone has any thoughts around this, > particularly if doing this would make your life difficult in some way. > Are people relying on dynCompileExpr for anything? > > Cheers, > Simon From chak at justtesting.org Wed Nov 18 01:41:09 2015 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Wed, 18 Nov 2015 12:41:09 +1100 Subject: Remote GHCi In-Reply-To: <564AFD2F.6020305@gmail.com> References: <564AFD2F.6020305@gmail.com> Message-ID: Hi Simon, While this is an interesting proposal, Haskell for Mac strongly relies on running interpreted code in the same process. I?m using ?dynCompileExpr? as well as ?hscStmtWithLocation? and some other stuff. This is quite crucial for some of the interactive functionality. Imagine a game where the game engine is in Swift linked into the main application and the game logic is in *interpreted* Haskell code. The engine calls into the Haskell code multiple times per frame of the animation and for all keyboard/mouse/etc input (using StablePtr and ForeignPtr to construct the scene graph across the Swift and Haskell heap). This is an intricate dance (e.g, exceptions in either language don?t play nice across the language boundary and using multi-threading in both worlds adds to the fun), but it allows for a very nice interactive and responsive user experience. I actually also might have a use for the architecture that you are proposing. However, I really would like to keep the ability to, at least, optionally run interpreted code in the same process (without profiling etc). Do you think we could have both? Cheers, Manuel > Simon Marlow : > > Hi folks - I've been thinking about changing the way we run interpreted code so that it would be run in a separate process. It turns out this has quite a few benefits, and would let us kill some of the really awkward hacks we have in GHC to work around problems that arise because we're running interpreted code and the compiler on the same runtime. > > I summarised the idea here: https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi > > I'd be interested to hear if anyone has any thoughts around this, particularly if doing this would make your life difficult in some way. Are people relying on dynCompileExpr for anything? > > Cheers, > Simon > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From carter.schonwald at gmail.com Wed Nov 18 03:01:39 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 17 Nov 2015 22:01:39 -0500 Subject: [ANNOUNCE] GHC 7.10.3 release candidate 1 In-Reply-To: <87si44y6b2.fsf@smart-cactus.org> References: <87fv0o8k3d.fsf@smart-cactus.org> <65A5651A-7C9D-4B6B-AEF2-459135E6ACB9@iki.fi> <6BA7E4B9-8791-4A31-BE90-4B632FAE423C@cis.upenn.edu> <506D8F5A-AA06-4A73-8DE6-12B2332C15BF@cis.upenn.edu> <87si44y6b2.fsf@smart-cactus.org> Message-ID: I'd be keen to see Mac support. How can I help out to test that for 8.0? On Tuesday, November 17, 2015, Ben Gamari wrote: > Richard Eisenberg > writes: > > > On Nov 4, 2015, at 11:12 AM, Peter Trommler < > Peter.Trommler at th-nuernberg.de > wrote: > > > >> It looks like a bug to me. > > > > I'm taking your "it" here to mean the fact that GHC is looking for > > readelf on a Mac OS platform. I tend to agree -- I was surprised to > > see this, but I'm almost-totally clueless about these things. > > > > Thanks for the info, > > Richard > > > > PS: There's been much muttering about call stacks and DWARF. I haven't > > a clue what DWARF is, but I always assumed that this nice feature > > would not be available on Macs. What I realized today is that this > > assumption likely stems from the fact that ELF is not for Mac. ELFs > > and DWARFs tend to be found near one another in other settings, but > > perhaps this fact doesn't carry over to computer architectures. :) > > > DWARF is a standard for expressing debug information about compiled > native programs. It is used by almost all modern operating systems > (including OS X; the only notable exception is Windows, naturally). > Indeed the name is a not-so-subtle reference to the fact that DWARF > debug information will often be found within ELF object files. > > Recently I have been working on using the mechanisms that came out of > Peter Wortmann's thesis to provide better stack traces and (statistical) > profiling support for Haskell code. While at the moment I am focusing on > Linux, there is little reason why this couldn't (fairly easily, I > suspect) be extended to work on OS X. > > Cheers, > > - Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Nov 18 08:29:37 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 18 Nov 2015 08:29:37 +0000 Subject: Window build broken In-Reply-To: <564bbbbb.913bc20a.7a664.ffffc141@mx.google.com> References: <742ebc4814d848e3b259eb6cbef37bb2@DB4PR30MB030.064d.mgd.msft.net> <564BADEF.7000607@gmail.com> <9d77fb778a204a648007aba0f3f1e8aa@DB4PR30MB030.064d.mgd.msft.net> <564bbbbb.913bc20a.7a664.ffffc141@mx.google.com> Message-ID: <128313f357ba40f5ab6ef8ada7452f23@DB4PR30MB030.064d.mgd.msft.net> It?s msys2. I don?t have Cygwin on this machine. I have no idea where that prompt comes from, but I agree it?s suspicious. Simon From: lonetiger at gmail.com [mailto:lonetiger at gmail.com] Sent: 17 November 2015 23:44 To: Simon Peyton Jones; David Macek; ghc-devs at haskell.org Subject: RE: Window build broken Hi Simon, I?m wondering what environment you?re coming in, is it msys2? The prompt you showed earlier /cygdrive/c/code/HEAD-1$ Looks like cygwin. Tamar From: Simon Peyton Jones Sent: Wednesday, November 18, 2015 00:25 To: David Macek;ghc-devs at haskell.org Subject: RE: Window build broken It says this: bash$ file libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.0.0.o libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.0.0.o: PE Unknown PE signature 0x742e x86-64 (stripped to external PDB), for MS Windows | -----Original Message----- | From: David Macek [mailto:david.macek.0 at gmail.com] | Sent: 17 November 2015 22:45 | To: Simon Peyton Jones >; ghc-devs at haskell.org | Subject: Re: Window build broken | | On 17. 11. 2015 23:31, Simon Peyton Jones wrote: | > Sigh. My Windows build is broken. See below. Any ideas? The stage2 | complier in non-interactive mode works ok. It?s just ghci fails. What does | ?Not x86_64 PEi386? mean? What can I do to fix? | | Maybe it's obvious and you already checked, but could it be that the object | file is for a different architecture? What does `file` say about it? | | -- | David Macek _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Nov 18 08:31:28 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 18 Nov 2015 08:31:28 +0000 Subject: Window build broken In-Reply-To: <564bbd58.6650c20a.ed6b5.6460@mx.google.com> References: <564bbd58.6650c20a.ed6b5.6460@mx.google.com> Message-ID: I?m happy to do experiments to help narrow it down, but I haven?t the foggiest idea where to start, and am utterly stalled on GHC Thanks Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of lonetiger at gmail.com Sent: 17 November 2015 23:51 To: Ryan Scott; ghc-devs at haskell.org Subject: RE: Window build broken Well the error is correct, it?s just checking against the machine type in the PE spec: IMAGE_FILE_MACHINE_AMD64 0x8664 x64 So somewhere along the line an invalid PE file was generated (or for the wrong architecture). From: Ryan Scott Sent: Wednesday, November 18, 2015 00:44 To: ghc-devs at haskell.org Subject: Re: Window build broken Wow, I happened to try building GHC on Windows for the first time ever today, and I also experienced this error :) Interestingly, someone reported a very similar error to this on Trac, but for GHC 7.8.3 [1]. Here's where the error message comes from [2] in Linker.c: static int verifyCOFFHeader (COFF_header *hdr, pathchar *fileName) { if (hdr->Machine != 0x8664) { errorBelch("%" PATH_FMT ": Not x86_64 PEi386", fileName); return 0; } ... } Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/10437 [2] https://github.com/ghc/ghc/blob/233d1312bf15940fca5feca6884f965e7944b555/rts/Linker.c#L3355 _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.macek.0 at gmail.com Wed Nov 18 08:35:25 2015 From: david.macek.0 at gmail.com (David Macek) Date: Wed, 18 Nov 2015 09:35:25 +0100 Subject: Window build broken In-Reply-To: <128313f357ba40f5ab6ef8ada7452f23@DB4PR30MB030.064d.mgd.msft.net> References: <742ebc4814d848e3b259eb6cbef37bb2@DB4PR30MB030.064d.mgd.msft.net> <564BADEF.7000607@gmail.com> <9d77fb778a204a648007aba0f3f1e8aa@DB4PR30MB030.064d.mgd.msft.net> <564bbbbb.913bc20a.7a664.ffffc141@mx.google.com> <128313f357ba40f5ab6ef8ada7452f23@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <564C384D.9010707@gmail.com> On 18. 11. 2015 9:29, Simon Peyton Jones wrote: > It?s msys2. I don?t have Cygwin on this machine. I have no idea where that prompt comes from, but I agree it?s suspicious. Looks like your /etc/fstab is wrong. There should be a line like this one, that removes the `cygdrive` prefix from Windows drive/letter mounts: none / cygdrive binary,posix=0,noacl,user 0 0 -- David Macek -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4254 bytes Desc: S/MIME Cryptographic Signature URL: From lonetiger at gmail.com Wed Nov 18 09:13:55 2015 From: lonetiger at gmail.com (Tamar Christina) Date: Wed, 18 Nov 2015 01:13:55 -0800 Subject: Window build broken Message-ID: <-8479951699220888539@unknownmsgid> Hmm, Presumably Simon didn't change this. Maybe the msys2 install is broken? TamarFrom: David Macek Sent: ?18/?11/?2015 09:35 To: Simon Peyton Jones; lonetiger at gmail.com; ghc-devs at haskell.org Subject: Re: Window build broken On 18. 11. 2015 9:29, Simon Peyton Jones wrote: > It?s msys2. I don?t have Cygwin on this machine. I have no idea where that prompt comes from, but I agree it?s suspicious. Looks like your /etc/fstab is wrong. There should be a line like this one, that removes the `cygdrive` prefix from Windows drive/letter mounts: none / cygdrive binary,posix=0,noacl,user 0 0 -- David Macek From marlowsd at gmail.com Wed Nov 18 09:17:58 2015 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 18 Nov 2015 09:17:58 +0000 Subject: Remote GHCi In-Reply-To: References: <564AFD2F.6020305@gmail.com> <8498A048-6385-4065-8920-C0A8639C4508@cis.upenn.edu> Message-ID: <564C4246.7080900@gmail.com> Ok, it seems that (1) is easy to support in a remote GHCi, (2) is not, and (3) I'm not sure about. GHCi itself does something very similar to (3): when we compile a statement it becomes a value of type IO [HValue], that we can evaluate and get back a list of the values that were bound to variables by the statement. In remote GHCi I can support this by having an RPC to evaluate the IO action and the returned HValues are remote references (StablePtrs) to values in the interpreter context. In any case I don't plan to break anything unless we have alternative ways to support everything without major upheaval. In the meantime there will probably be a flag to select remote GHCi, and existing use cases will continue to be supported. Cheers Simon On 17/11/2015 17:11, Andrew Gibiansky wrote: > Simon, > > As Sumit said, we use dynCompileExpr for core functionality of IHaskell. > I am not really sure how the change you are proposing affects that, though. > > We use dynCompileExpr in several places for evaluation inside the > interpreter context: > > 1. Evaluating a Haskell expression in the interpreter context, > converting the result to a ByteString, then using fromDynamic to extract > the bytestring and convert it to a value in the compiled context. > 2. Getting a file handle from the interpreter context to the compiled > context; this does not actually use dynCompileExpr because there were > some bugs with dynCompileExpr and so I had to literally copy source from > InteractiveEval to reimplement parts of dynCompileExpr (unrelated: the > issue was that dyncompileexpr imported and then unimported Data.Dynamic, > and this messed with data declarations that had already been created in > the interpreter context) > 3. Extracting IO a values from the interpreted context to the compiled > context so that they could be run; this is necessary to get displayed > values from the interpreter back to the compiled code. > > I think two of our uses, which are both very central to the way IHaskell > works, would be impacted by requiring a Binary instance (or similar), > which is what I think you are proposing (since we have two uses at least > where we marshall `IO x` values via dynCompileExpr, which cannot be > serialized, I believe.) > > I am sure that there are alternative ways to do what we are doing, but > they are probably not simple and would take quite a bit of work. > > -- Andrew > > On Tue, Nov 17, 2015 at 6:29 AM, Richard Eisenberg > wrote: > > How does this interact with typechecker plugins? I assume they would > still happen in GHC's process. > > I've also been thinking about designing and implementing a > mechanisms where programmers could specify custom pretty-printers > for their types, and GHC would use these pretty-printers in error > messages. This action would also probably need to be in the same > process. > > Would either of these ideas be affected? My guess is "no", because > we should be able to be selective in what gets farmed out to the > second process and what stays locally. > > Richard > > On Nov 17, 2015, at 5:10 AM, Simon Marlow > wrote: > > > Hi folks - I've been thinking about changing the way we run > interpreted code so that it would be run in a separate process. It > turns out this has quite a few benefits, and would let us kill some > of the really awkward hacks we have in GHC to work around problems > that arise because we're running interpreted code and the compiler > on the same runtime. > > > > I summarised the idea here: > https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi > > > > I'd be interested to hear if anyone has any thoughts around this, > particularly if doing this would make your life difficult in some > way. Are people relying on dynCompileExpr for anything? > > > > Cheers, > > Simon > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > From marlowsd at gmail.com Wed Nov 18 09:25:51 2015 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 18 Nov 2015 09:25:51 +0000 Subject: Remote GHCi In-Reply-To: <1447807180-sup-4328@sabre> References: <564AFD2F.6020305@gmail.com> <1447807180-sup-4328@sabre> Message-ID: <564C441F.8000105@gmail.com> On 18/11/2015 00:53, Edward Z. Yang wrote: > I like it. > > Let me make sure that I've understand this correctly: > > - While GHC doesn't need to be built with profiling if you > want to use profiling in the interpeter, you will need > multiple versions of the "server binary" for each way > you want to implement. This should be pretty reasonable, > because the server binary is a lot smaller than GHC. Yes, exactly. > - It seems that GHC will ship bytecode and object code > to the server binary. In this case, the interpeted > code and compiled code CAN share data among each other; > it is just when you want to share data with GHC that > you must implement serialization. (Also, external > bytecode format?!) We need to ship bytecode, but not necessarily object code. The idea is to implement the linker API via an RPC protocol to the server binary. It's pretty straightforward actually, I have a prototype running already. We would only need to ship object code if the server were running on a separate machine, that's something for later (if ever). > - Many people have commented that their extensions use > dynCompileExpr. I think these cases can be accommodated, > by making the server binary not a standalone application, > but a LIBRARY which can be linked against a custom > application (e.g. IHaskell). The messages to be sent > should not be the values/file descriptors, but the > invocations that are being requested of GHC. Unfortunately, > this does seem to imply that most things would have to > be rewritten from scratch to not use the ghc-api, but > use whatever this new library's interface over the message > passing is. Hmm, the thing is that it is *already* a library (the GHC API) and I want to make it a separate process, to decouple the runtime that is running the compiler from the one running the interpreted code. > Honestly, it seems like the hard part is defining the message-passing > protocol, esp. since the GHC API is as overgrown as it is today. What I have in mind is much lower level than the GHC API. Here's what I have so far: data Message a where -- linker API LookupSymbol :: String -> Message (Maybe RemotePtr) LoadDLL :: String -> Message (Maybe String) LoadArchive :: String -> Message () -- error? LoadObj :: String -> Message () -- error? UnloadObj :: String -> Message () -- error? AddLibrarySearchPath :: String -> Message RemotePtr RemoveLibrarySearchPath :: RemotePtr -> Message Bool ResolveObjs :: Message Bool -- creating and evaluating bytecode CreateBCO :: ResolvedBCO -> Message RemoteHValue FreeHValue :: RemoteHValue -> Message () Eval :: RemoteHValue {- IO [a] -} -> Message [RemoteHValue] {- [a] -} this is enough to support basic GHCi operations. Cheers, Simon > Edward > > Excerpts from Simon Marlow's message of 2015-11-17 02:10:55 -0800: >> Hi folks - I've been thinking about changing the way we run interpreted >> code so that it would be run in a separate process. It turns out this >> has quite a few benefits, and would let us kill some of the really >> awkward hacks we have in GHC to work around problems that arise because >> we're running interpreted code and the compiler on the same runtime. >> >> I summarised the idea here: https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi >> >> I'd be interested to hear if anyone has any thoughts around this, >> particularly if doing this would make your life difficult in some way. >> Are people relying on dynCompileExpr for anything? >> >> Cheers, >> Simon From marlowsd at gmail.com Wed Nov 18 09:45:26 2015 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 18 Nov 2015 09:45:26 +0000 Subject: Remote GHCi In-Reply-To: References: <564AFD2F.6020305@gmail.com> Message-ID: <564C48B6.5070202@gmail.com> On 18/11/2015 01:41, Manuel M T Chakravarty wrote: > Hi Simon, > > While this is an interesting proposal, Haskell for Mac strongly > relies on running interpreted code in the same process. I?m using > ?dynCompileExpr? as well as ?hscStmtWithLocation? and some other > stuff. Let me say first of all that I'm not going to remove anything, so there's no need to worry. But I'd like to explore exactly what you need, so that we can see whether there's a way to accommodate it with a separate-process implementation. hscStmtWithLocation is part of the core GHCi functionality, it is definitely supported. It has a slightly different signature: hscStmtWithLocation :: HscEnv -> String -- ^ The statement -> String -- ^ The source -> Int -- ^ Starting line -> IO ( Maybe ([Id] , RemoteHValue {- IO [HValue] -} , FixityEnv)) RemoteHValue is a reference to a value in the interpreter's context. These have to be evaluated via an explicit API, rather than just unsafeCoercing HValue as we do now. (this is not strictly speaking part of the GHC API, so a separate but interesting question is: why did you need to use this directly, and what should we add to the GHC API?) I believe that many uses of dynCompileExpr can be changed so that the code using the resulting value is moved into the interpreter's context, and then there's no problem. > This is quite crucial for some of the interactive > functionality. Imagine a game where the game engine is in Swift > linked into the main application and the game logic is in > *interpreted* Haskell code. The engine calls into the Haskell code > multiple times per frame of the animation and for all > keyboard/mouse/etc input (using StablePtr and ForeignPtr to construct > the scene graph across the Swift and Haskell heap). So my question is, why wouldn't you run the whole game engine in the interpreter's context? That's what would happen if you were to load the program into GHCi and run it. Directly calling back and forth between the client of the GHC API and the program being interpreted is arguably a strange thing to do, and it's kind of accidental that we allow it. > I actually also might have a use for the architecture that you are > proposing. However, I really would like to keep the ability to, at > least, optionally run interpreted code in the same process (without > profiling etc). Do you think we could have both? We can certainly have both, it's straightforward to implement, but I don't get to throw away some of the hacks we have to support same-process execution, which would be a shame. We just add more code rather than > Cheers, > Manuel > >> Simon Marlow : >> >> Hi folks - I've been thinking about changing the way we run interpreted code so that it would be run in a separate process. It turns out this has quite a few benefits, and would let us kill some of the really awkward hacks we have in GHC to work around problems that arise because we're running interpreted code and the compiler on the same runtime. >> >> I summarised the idea here: https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi >> >> I'd be interested to hear if anyone has any thoughts around this, particularly if doing this would make your life difficult in some way. Are people relying on dynCompileExpr for anything? >> >> Cheers, >> Simon >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From simonpj at microsoft.com Wed Nov 18 10:02:09 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 18 Nov 2015 10:02:09 +0000 Subject: Wildcard refactor Message-ID: Alan I'm really close on wip/spj-wildcard-refactor, that I really want to get into HEAD asap. Could you possibly checkout wip/spj-wildcard-refactor, and validate? I get two failures I don't understand: ghc-api/annotations listcomps [bad stdout] (normal) ghc-api/landmines landmines [bad stderr] (normal) The output is not wildly different but I just don't know how to interpret it, so I don't even know what the problem is exactly. NB: you''ll need to do a 'git submodule update' because the haddock submodule changes. Thank you! Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Wed Nov 18 10:03:44 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Wed, 18 Nov 2015 02:03:44 -0800 Subject: Feature status for GHC 8.0 In-Reply-To: <87y4dwy7kh.fsf@smart-cactus.org> References: <87y4dwy7kh.fsf@smart-cactus.org> Message-ID: <1447840946-sup-1450@sabre> Excerpts from Ben Gamari's message of 2015-11-17 07:22:22 -0800: > * Backpack work Edward Z. Yang > How is this coming along? Had a chat with SPJ about this and we've decided that Backpack still needs stabilizing, and there is not much gain to be had shipping it until it is very nearly done, so we are not going to be targeting this patch for GHC 8.0 Edward From alan.zimm at gmail.com Wed Nov 18 10:04:26 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Wed, 18 Nov 2015 12:04:26 +0200 Subject: Wildcard refactor In-Reply-To: References: Message-ID: ok. I have been waiting to jump in and help. Alan On Wed, Nov 18, 2015 at 12:02 PM, Simon Peyton Jones wrote: > Alan > > I?m really close on wip/spj-wildcard-refactor, that I really want to get > into HEAD asap. > > Could you possibly checkout wip/spj-wildcard-refactor, and validate? I > get two failures I don?t understand: > > ghc-api/annotations listcomps [bad stdout] (normal) > > ghc-api/landmines landmines [bad stderr] (normal) > > The output is not wildly different but I just don?t know how to interpret > it, so I don?t even know what the problem is exactly. > > NB: you??ll need to do a ?git submodule update? because the haddock > submodule changes. > > Thank you! > > Simon > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Nov 18 11:18:14 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 18 Nov 2015 11:18:14 +0000 Subject: Wildcard refactor In-Reply-To: References: Message-ID: <9eca7dbbe97f40e1be34b80820538cd0@DB4PR30MB030.064d.mgd.msft.net> It does, yes. It?s on 0d157fe, which is the head of wip/spj-wildcard-refactor in the haddock repo Is that what get checked out by ?git submodule update?? Simon From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] Sent: 18 November 2015 10:57 To: Simon Peyton Jones Subject: Re: Wildcard refactor I found the haddock library did not compile, but I am skipping straight to the tests. Does it compile for you at the moment? On Wed, Nov 18, 2015 at 12:51 PM, Simon Peyton Jones > wrote: Thank you! From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] Sent: 18 November 2015 10:04 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: Wildcard refactor ok. I have been waiting to jump in and help. Alan On Wed, Nov 18, 2015 at 12:02 PM, Simon Peyton Jones > wrote: Alan I?m really close on wip/spj-wildcard-refactor, that I really want to get into HEAD asap. Could you possibly checkout wip/spj-wildcard-refactor, and validate? I get two failures I don?t understand: ghc-api/annotations listcomps [bad stdout] (normal) ghc-api/landmines landmines [bad stderr] (normal) The output is not wildly different but I just don?t know how to interpret it, so I don?t even know what the problem is exactly. NB: you??ll need to do a ?git submodule update? because the haddock submodule changes. Thank you! Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Nov 18 11:19:17 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 18 Nov 2015 11:19:17 +0000 Subject: Wildcard refactor In-Reply-To: <9eca7dbbe97f40e1be34b80820538cd0@DB4PR30MB030.064d.mgd.msft.net> References: <9eca7dbbe97f40e1be34b80820538cd0@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <854c96d4ae904d2ca1696764acb43479@DB4PR30MB030.064d.mgd.msft.net> Oh sorry, no I think I?d been skipping it too. I?ll fix that! Meanwhile, skip! From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon Peyton Jones Sent: 18 November 2015 11:18 To: Alan & Kim Zimmerman Cc: ghc-devs at haskell.org Subject: RE: Wildcard refactor It does, yes. It?s on 0d157fe, which is the head of wip/spj-wildcard-refactor in the haddock repo Is that what get checked out by ?git submodule update?? Simon From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] Sent: 18 November 2015 10:57 To: Simon Peyton Jones Subject: Re: Wildcard refactor I found the haddock library did not compile, but I am skipping straight to the tests. Does it compile for you at the moment? On Wed, Nov 18, 2015 at 12:51 PM, Simon Peyton Jones > wrote: Thank you! From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] Sent: 18 November 2015 10:04 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: Wildcard refactor ok. I have been waiting to jump in and help. Alan On Wed, Nov 18, 2015 at 12:02 PM, Simon Peyton Jones > wrote: Alan I?m really close on wip/spj-wildcard-refactor, that I really want to get into HEAD asap. Could you possibly checkout wip/spj-wildcard-refactor, and validate? I get two failures I don?t understand: ghc-api/annotations listcomps [bad stdout] (normal) ghc-api/landmines landmines [bad stderr] (normal) The output is not wildly different but I just don?t know how to interpret it, so I don?t even know what the problem is exactly. NB: you??ll need to do a ?git submodule update? because the haddock submodule changes. Thank you! Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Wed Nov 18 11:22:16 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Wed, 18 Nov 2015 13:22:16 +0200 Subject: Wildcard refactor In-Reply-To: <854c96d4ae904d2ca1696764acb43479@DB4PR30MB030.064d.mgd.msft.net> References: <9eca7dbbe97f40e1be34b80820538cd0@DB4PR30MB030.064d.mgd.msft.net> <854c96d4ae904d2ca1696764acb43479@DB4PR30MB030.064d.mgd.msft.net> Message-ID: This is what I get locally unexpected results from: TEST="landmines listcomps T7861 T5837 T4896 T3064" OVERALL SUMMARY for test run started at Wed Nov 18 10:48:00 2015 UTC 0:27:16 spent to go through 4802 total tests, which gave rise to 18143 test cases, of which 13285 were skipped 77 had missing libraries 4667 expected passes 108 expected failures 0 caused framework failures 0 unexpected passes 5 unexpected failures 1 unexpected stat failures Unexpected failures: deriving/should_compile T4896 [exit code non-0] (normal) ghc-api/annotations listcomps [bad stdout] (normal) ghc-api/landmines landmines [bad stderr] (normal) perf/compiler T5837 [stderr mismatch] (normal) typecheck/should_run T7861 [bad stderr] (normal) Unexpected stat failures: perf/compiler T3064 [stat not good enough] (normal) I will look into the two ghc-api ones. On Wed, Nov 18, 2015 at 1:19 PM, Simon Peyton Jones wrote: > Oh sorry, no I think I?d been skipping it too. I?ll fix that! Meanwhile, > skip! > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Simon > Peyton Jones > *Sent:* 18 November 2015 11:18 > *To:* Alan & Kim Zimmerman > *Cc:* ghc-devs at haskell.org > *Subject:* RE: Wildcard refactor > > > > It does, yes. It?s on 0d157fe, which is the head of > wip/spj-wildcard-refactor in the haddock repo > > Is that what get checked out by ?git submodule update?? > > > > Simon > > > > *From:* Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com > ] > *Sent:* 18 November 2015 10:57 > *To:* Simon Peyton Jones > *Subject:* Re: Wildcard refactor > > > > I found the haddock library did not compile, but I am skipping straight to > the tests. > > Does it compile for you at the moment? > > > > On Wed, Nov 18, 2015 at 12:51 PM, Simon Peyton Jones < > simonpj at microsoft.com> wrote: > > Thank you! > > > > *From:* Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] > *Sent:* 18 November 2015 10:04 > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: Wildcard refactor > > > > ok. > > I have been waiting to jump in and help. > > Alan > > > > On Wed, Nov 18, 2015 at 12:02 PM, Simon Peyton Jones < > simonpj at microsoft.com> wrote: > > Alan > > I?m really close on wip/spj-wildcard-refactor, that I really want to get > into HEAD asap. > > Could you possibly checkout wip/spj-wildcard-refactor, and validate? I > get two failures I don?t understand: > > ghc-api/annotations listcomps [bad stdout] (normal) > > ghc-api/landmines landmines [bad stderr] (normal) > > The output is not wildly different but I just don?t know how to interpret > it, so I don?t even know what the problem is exactly. > > NB: you??ll need to do a ?git submodule update? because the haddock > submodule changes. > > Thank you! > > Simon > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matej.borovec at yahoo.com Wed Nov 18 11:25:16 2015 From: matej.borovec at yahoo.com (Matej Borovec) Date: Wed, 18 Nov 2015 12:25:16 +0100 Subject: Window build broken In-Reply-To: <9d77fb778a204a648007aba0f3f1e8aa@DB4PR30MB030.064d.mgd.msft.net> References: <742ebc4814d848e3b259eb6cbef37bb2@DB4PR30MB030.064d.mgd.msft.net> <564BADEF.7000607@gmail.com> <9d77fb778a204a648007aba0f3f1e8aa@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <118763124E81449E95AD063287003695@unknown> I'm getting similar error on my 32-bit Windows 10: GHCi, version 7.11.20151114: http://www.haskell.org/ghc/ :? for help ghc.exe: C:\ghc-8.0_git\usr\local\lib\ghc-prim-0.5.0.0\HSghc-prim-0.5.0.0.o: Not x86 PEi386 ghc.exe: panic! (the 'impossible' happened) (GHC version 7.11.20151114 for i386-unknown-mingw32): loadObj "C:\\ghc-8.0_git\\usr\\local\\lib\\ghc-prim-0.5.0.0\\HSghc-prim-0.5.0.0.o": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug And running `file lib\ghc-prim-0.5.0.0\HSghc-prim-0.5.0.0.o` I get: lib\ghc-prim-0.5.0.0\HSghc-prim-0.5.0.0.o: PE Unknown PE signature 0x342f Intel 80386 (stripped to external PDB), for MS Windows -----Original Message----- From: Simon Peyton Jones Sent: Wednesday, November 18, 2015 12:25 AM To: David Macek ; ghc-devs at haskell.org Subject: RE: Window build broken It says this: bash$ file libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.0.0.o libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.0.0.o: PE Unknown PE signature 0x742e x86-64 (stripped to external PDB), for MS Windows | -----Original Message----- | From: David Macek [mailto:david.macek.0 at gmail.com] | Sent: 17 November 2015 22:45 | To: Simon Peyton Jones ; ghc-devs at haskell.org | Subject: Re: Window build broken | | On 17. 11. 2015 23:31, Simon Peyton Jones wrote: | > Sigh. My Windows build is broken. See below. Any ideas? The stage2 | complier in non-interactive mode works ok. It?s just ghci fails. What does | ?Not x86_64 PEi386? mean? What can I do to fix? | | Maybe it's obvious and you already checked, but could it be that the object | file is for a different architecture? What does `file` say about it? | | -- | David Macek _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Wed Nov 18 13:04:31 2015 From: ben at well-typed.com (Ben Gamari) Date: Wed, 18 Nov 2015 14:04:31 +0100 Subject: Feature status for GHC 8.0 In-Reply-To: <1447840946-sup-1450@sabre> References: <87y4dwy7kh.fsf@smart-cactus.org> <1447840946-sup-1450@sabre> Message-ID: <878u5vxxuo.fsf@smart-cactus.org> "Edward Z. Yang" writes: > Excerpts from Ben Gamari's message of 2015-11-17 07:22:22 -0800: >> * Backpack work Edward Z. Yang >> How is this coming along? > > Had a chat with SPJ about this and we've decided that Backpack still > needs stabilizing, and there is not much gain to be had shipping it > until it is very nearly done, so we are not going to be targeting > this patch for GHC 8.0 > Sounds good; that is consistent with my own discussions with Simon on this matter. What about the compacts work? I know that Simon Marlow has some questions about the implementation. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From simonpj at microsoft.com Wed Nov 18 13:38:18 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 18 Nov 2015 13:38:18 +0000 Subject: Window build broken In-Reply-To: <-8479951699220888539@unknownmsgid> References: <-8479951699220888539@unknownmsgid> Message-ID: | Presumably Simon didn't change this. Maybe the msys2 install is broken? Perhaps it is. Should I blow it away and re-install? One other difficulty is that (before my machine change) I tried to follow the instructions on https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows to install 64-bit msys2; but I had a series of problems that Ben G was unable to get to the bottom of. Particularly I could not run bash from emacs; the emacs shell window never got as far as a prompt. So I backed off. As far as I know that is still broken. I think I have not tried the "32-bit msys2 installer" on that page. Maybe that should be my next step? Regardless, it's hard to see how any of this concerns the error message I was getting. As lonetiger said, it looks very similar to https://ghc.haskell.org/trac/ghc/ticket/10437 What next? Simon | -----Original Message----- | From: Tamar Christina [mailto:lonetiger at gmail.com] | Sent: 18 November 2015 09:14 | To: David Macek; Simon Peyton Jones; ghc-devs at haskell.org | Subject: RE: Window build broken | | Hmm, | | Presumably Simon didn't change this. Maybe the msys2 install is broken? | | TamarFrom: David Macek | Sent: ?18/?11/?2015 09:35 | To: Simon Peyton Jones; lonetiger at gmail.com; ghc-devs at haskell.org | Subject: Re: Window build broken | On 18. 11. 2015 9:29, Simon Peyton Jones wrote: | > It?s msys2. I don?t have Cygwin on this machine. I have no idea where | that prompt comes from, but I agree it?s suspicious. | | Looks like your /etc/fstab is wrong. There should be a line like this one, | that removes the `cygdrive` prefix from Windows drive/letter | mounts: | | none / cygdrive binary,posix=0,noacl,user 0 0 | | -- | David Macek From eir at cis.upenn.edu Wed Nov 18 13:47:57 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 18 Nov 2015 08:47:57 -0500 Subject: Feature status for GHC 8.0 In-Reply-To: <87y4dwy7kh.fsf@smart-cactus.org> References: <87y4dwy7kh.fsf@smart-cactus.org> Message-ID: <6CF80E92-98E5-4625-9B0C-69BCC22A1F39@cis.upenn.edu> On Nov 17, 2015, at 10:22 AM, Ben Gamari wrote: > * Kind equality Richard Eisenberg > Patches coming soon? Yes yes yes. Coming soon! I'll post an update to D808 presently if anyone wants to watch from home. Richard From ben at well-typed.com Wed Nov 18 14:48:16 2015 From: ben at well-typed.com (Ben Gamari) Date: Wed, 18 Nov 2015 15:48:16 +0100 Subject: [ANNOUNCE] 7.10.3 release candidate 3 In-Reply-To: <87pozltpfv.fsf@smart-cactus.org> References: <87pozltpfv.fsf@smart-cactus.org> Message-ID: <87610zxt1r.fsf@smart-cactus.org> Hello everyone, We are pleased to announce the third release candidate of GHC 7.10.3: https://downloads.haskell.org/~ghc/7.10.3-rc3/ There have been a few changes since -rc2, * The newly-introduced readelf configure check has been disabled on non-ELF platforms * Some tracing output from the typechecker that was causing some testsuites to fail was removed * A latent bug in call arity analysis (#11064) is fixed * A code generation bug (#10870) in the PowerPC NCG is fixed * A bug in the treatment of foreign calls during demand analysis (#11076) which had affected GHCJS is fixed * A bug in the x86 NCG causing invalid assembly to be produced when compiling with `-g` is fixed. At this moment you will find the source tarball, as well as, 64-bit Windows, Mac OS X, 32- and 64-bit modern Linux (built on Debian 8) binary distributions available at the above URL. As usual, you may need to work around our content delivery network's update latency by adding redundant forward-slashes to the URL. It has come to our attention that there still may be some issues with long command lines on Windows with this release: While the toolchain upgrade included in this release has the response file support necessary to work around this limitation, the version of the Cabal library shipped with this release does not. Unfortunately, the fix [1], which affects Cabal's haddock integration, has not yet shipped in a Cabal release. If you encounter this issue you might consider installing Cabal and cabal-install from git. Lastly, I'd like to take a moment to acknowledge Futureice [2], who have donated a brand new Mac Mini for use by GHC developers to help support this platform. Their generosity is the reason we are able to offer OS X builds to you today. Many thanks to Futureice for this donation! Happy testing! Cheers, - Ben [1] https://github.com/haskell/cabal/commit/1c1228a808b55331ac1db6d71fd2f8533f5fc57e [2] http://futurice.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From simonpj at microsoft.com Wed Nov 18 15:57:49 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 18 Nov 2015 15:57:49 +0000 Subject: [commit: ghc] master: Remove PatSynBuilderId (2208011) In-Reply-To: <87oaesy3xh.fsf@smart-cactus.org> References: <20151107235023.DD7BF3A300@ghc.haskell.org> <2a4628524e7d49acae7ab7e31db3690e@DB4PR30MB030.064d.mgd.msft.net> <371c6d358c3e47ae885ecfa49d49ccbe@DB4PR30MB030.064d.mgd.msft.net> <87oaesy3xh.fsf@smart-cactus.org> Message-ID: Done! | -----Original Message----- | From: Ben Gamari [mailto:ben at well-typed.com] | Sent: 17 November 2015 16:41 | To: Simon Peyton Jones; Matthew Pickering | Cc: ghc-devs at haskell.org | Subject: RE: [commit: ghc] master: Remove PatSynBuilderId (2208011) | | Simon Peyton Jones writes: | | > | I don't think this would work in the case where there are no fields | > | initialised? | > | > Oh yes, silly me. I was thinking that then we wouldn?t need to look at | > 'labels' at all, but that's not true. | > | > Well, at least then I'd replace [PostTc id [FieldLabel] with (PostTc | > ConLike). This makes it like ConPatOut in HsPat. Then the (Located id) | > field is redundant (we can get it from the ConLike), but that?s only | > true after typechecking, so maybe simpler to keep both. | > | > It amounts to moving the call to conLikeFieldLabels from tcExpr | > (RecordCon ...) to dsExpr (RecordCon ...). A small thing but I think | > it'd be better. | > | Mathew, did you ever get to this? | | Cheers, | | - Ben From andrew.gibiansky at gmail.com Wed Nov 18 16:26:59 2015 From: andrew.gibiansky at gmail.com (Andrew Gibiansky) Date: Wed, 18 Nov 2015 08:26:59 -0800 Subject: Remote GHCi In-Reply-To: <564C48B6.5070202@gmail.com> References: <564AFD2F.6020305@gmail.com> <564C48B6.5070202@gmail.com> Message-ID: Simon, I'd like to hear how we can support what IHaskell does with remote GHCi. One core functionality that we use dynCompileExpr for (not quite dynCompileExpr, but similar) is getting the standard output of code that is being run. Any time code is run, we 1. Create a unix pipe. 2. Set stdout to point to that pipe using dupTo. 3. Use hscStmt with unsafeCoerce to get the other end of the pipe in the compiled context. 4. Run the statement in the interpreted context in a separate thread; meanwhile, read from the pipe to get the stdout of the code running in the interpreted context. 5. When it is done running, move stdout back to point to the read stdout and close the unix pipe file handle. 6. Send the stdout (both intermediate values and the final value) to the frontend to display to the user. The key here is that we can access directly the file handle created by the interpreted code. If the interpreted code is remote, we clearly cannot read from a pipe it creates. In your remote GHCi, how could we solve this problem? In general, how would stdin and stdout work? Would there be a clean way to feed the remote process its stdin and receive its stdout and stderr? That would effectively mean stdin/stdout/stderr are configurable which would be a godsend for IHaskell. -- Andrew On Wed, Nov 18, 2015 at 1:45 AM, Simon Marlow wrote: > On 18/11/2015 01:41, Manuel M T Chakravarty wrote: > >> Hi Simon, >> >> While this is an interesting proposal, Haskell for Mac strongly >> relies on running interpreted code in the same process. I?m using >> ?dynCompileExpr? as well as ?hscStmtWithLocation? and some other >> stuff. >> > > Let me say first of all that I'm not going to remove anything, so there's > no need to worry. But I'd like to explore exactly what you need, so that > we can see whether there's a way to accommodate it with a separate-process > implementation. > > hscStmtWithLocation is part of the core GHCi functionality, it is > definitely supported. It has a slightly different signature: > > hscStmtWithLocation :: HscEnv > -> String -- ^ The statement > -> String -- ^ The source > -> Int -- ^ Starting line > -> IO ( Maybe ([Id] > , RemoteHValue {- IO [HValue] -} > , FixityEnv)) > > RemoteHValue is a reference to a value in the interpreter's context. These > have to be evaluated via an explicit API, rather than just unsafeCoercing > HValue as we do now. (this is not strictly speaking part of the GHC API, > so a separate but interesting question is: why did you need to use this > directly, and what should we add to the GHC API?) > > I believe that many uses of dynCompileExpr can be changed so that the code > using the resulting value is moved into the interpreter's context, and then > there's no problem. > > This is quite crucial for some of the interactive >> functionality. Imagine a game where the game engine is in Swift >> linked into the main application and the game logic is in >> *interpreted* Haskell code. The engine calls into the Haskell code >> multiple times per frame of the animation and for all >> keyboard/mouse/etc input (using StablePtr and ForeignPtr to construct >> the scene graph across the Swift and Haskell heap). >> > > So my question is, why wouldn't you run the whole game engine in the > interpreter's context? That's what would happen if you were to load the > program into GHCi and run it. Directly calling back and forth between the > client of the GHC API and the program being interpreted is arguably a > strange thing to do, and it's kind of accidental that we allow it. > > I actually also might have a use for the architecture that you are >> proposing. However, I really would like to keep the ability to, at >> least, optionally run interpreted code in the same process (without >> profiling etc). Do you think we could have both? >> > > We can certainly have both, it's straightforward to implement, but I don't > get to throw away some of the hacks we have to support same-process > execution, which would be a shame. We just add more code rather than > > > Cheers, >> Manuel >> >> Simon Marlow : >>> >>> Hi folks - I've been thinking about changing the way we run interpreted >>> code so that it would be run in a separate process. It turns out this has >>> quite a few benefits, and would let us kill some of the really awkward >>> hacks we have in GHC to work around problems that arise because we're >>> running interpreted code and the compiler on the same runtime. >>> >>> I summarised the idea here: >>> https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi >>> >>> I'd be interested to hear if anyone has any thoughts around this, >>> particularly if doing this would make your life difficult in some way. Are >>> people relying on dynCompileExpr for anything? >>> >>> Cheers, >>> Simon >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >> >> _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.bracker at googlemail.com Wed Nov 18 16:35:37 2015 From: jan.bracker at googlemail.com (Jan Bracker) Date: Wed, 18 Nov 2015 16:35:37 +0000 Subject: Explanation of a core-lint warning (Bad getNth) Message-ID: Hi, I am using the type checker plugin interface and I am trying to produce some evidence for type class instances. During compilation of one of my examples I get this core-lint error: *** Core Lint errors : in result of Simplifier *** : Warning: [RHS of ds_a6bY :: (Set '["thres" :-> Int], Set (Unit Reader))] Bad getNth: Nth:0 (Nth:2 (Sub (Sym (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N <'[]>_N)) ; (Inv _N <'["thres" :-> Int]>_N (Sym TFCo:R:Unit[]Reader[0]))_R ; Sub (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N _N))) Split '["thres" :-> Int] '[] (Union '["thres" :-> Int] '[]) Split '["thres" :-> Int] (Unit Reader) (Union '["thres" :-> Int] (Unit Reader)) I suppose "getNth" refers to the constructor "EvTupleSel" from "EvTerm", "TcNthCo" from "TcCoercion" or to "NthCo" from "Coercion". But I never produce evidence of the shape "getNth". My evidence production code can be found at [1] and the only place where evidence of this shape can come from is my "evaluateType" function [2] that calls "normaliseType" from the GHC module "FamInstEnv". You can reproduce the error by checking out commit 144525886ec107af6f1283b26b19f8125c980aa4 from [3] and running "make effect-example" in the top directory of the repository (GHC 7.10 or better is required and a sandbox is automatically created). The core-lint error does not seem to have any negative consequences when ignored. The produced executable works fine. Can somebody explain why it appears and maybe how I can fix it? Thank you! Jan [1] https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evidence.hs#L177 [2] https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evaluate.hs#L29 [3] https://github.com/jbracker/polymonad-plugin -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Wed Nov 18 17:05:43 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 18 Nov 2015 12:05:43 -0500 Subject: Explanation of a core-lint warning (Bad getNth) In-Reply-To: References: Message-ID: I took just a quick look at this. Is Split a type family? The NthCo coercion form takes apart a composite equality into its pieces. For example, if we know (Maybe a ~ Maybe b), then NthCo:0 will tell us that (a ~ b). In your case, it looks like GHC is trying to deduce (Union '["thres" :-> Int] []) ~ (Union '["thres" :-> Int] (Unit Reader)) from an equality of two (Split ...) types. If Split is a type family, this deduction is unsound. That may be what Core Lint is worried about. I'm not surprised that the executable would run with an error. But it might not in the future. If -dcore-lint fails, it means that there is a potential type safety issue in the Core code, and this should be taken seriously. I hope this helps! Richard On Nov 18, 2015, at 11:35 AM, Jan Bracker wrote: > Hi, > > I am using the type checker plugin interface and I am trying to produce some evidence for type class instances. During compilation of one of my examples I get this core-lint error: > > *** Core Lint errors : in result of Simplifier *** > : Warning: > [RHS of ds_a6bY :: (Set '["thres" :-> Int], Set (Unit Reader))] > Bad getNth: > Nth:0 > (Nth:2 > (Sub (Sym (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N <'[]>_N)) > ; (Inv > _N <'["thres" :-> Int]>_N (Sym TFCo:R:Unit[]Reader[0]))_R > ; Sub > (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N _N))) > Split '["thres" :-> Int] '[] (Union '["thres" :-> Int] '[]) > Split > '["thres" :-> Int] > (Unit Reader) > (Union '["thres" :-> Int] (Unit Reader)) > > I suppose "getNth" refers to the constructor "EvTupleSel" from "EvTerm", "TcNthCo" from "TcCoercion" or to "NthCo" from "Coercion". But I never produce evidence of the shape "getNth". My evidence production code can be found at [1] and the only place where evidence of this shape can come from is my "evaluateType" function [2] that calls "normaliseType" from the GHC module "FamInstEnv". You can reproduce the error by checking out commit 144525886ec107af6f1283b26b19f8125c980aa4 from [3] and running "make effect-example" in the top directory of the repository (GHC 7.10 or better is required and a sandbox is automatically created). > > The core-lint error does not seem to have any negative consequences when ignored. The produced executable works fine. Can somebody explain why it appears and maybe how I can fix it? > > Thank you! > Jan > > [1] https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evidence.hs#L177 > [2] https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evaluate.hs#L29 > [3] https://github.com/jbracker/polymonad-plugin > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.bracker at googlemail.com Wed Nov 18 17:11:43 2015 From: jan.bracker at googlemail.com (Jan Bracker) Date: Wed, 18 Nov 2015 17:11:43 +0000 Subject: Explanation of a core-lint warning (Bad getNth) In-Reply-To: References: Message-ID: Hi Richard, No "Split" is a class and is defined here: http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-State.html#t:Split "Union" is a type function (synonym that refers to a type function call): http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-Writer.html#t:Union thank you for your quick reply! Best, Jan 2015-11-18 17:05 GMT+00:00 Richard Eisenberg : > I took just a quick look at this. Is Split a type family? The NthCo > coercion form takes apart a composite equality into its pieces. For > example, if we know (Maybe a ~ Maybe b), then NthCo:0 will tell us that (a > ~ b). In your case, it looks like GHC is trying to deduce (Union '["thres" > :-> Int] []) ~ (Union '["thres" :-> Int] (Unit Reader)) from an equality of > two (Split ...) types. If Split is a type family, this deduction is > unsound. That may be what Core Lint is worried about. > > I'm not surprised that the executable would run with an error. But it > might not in the future. If -dcore-lint fails, it means that there is a > potential type safety issue in the Core code, and this should be taken > seriously. > > I hope this helps! > Richard > > On Nov 18, 2015, at 11:35 AM, Jan Bracker > wrote: > > Hi, > > I am using the type checker plugin interface and I am trying to produce > some evidence for type class instances. During compilation of one of my > examples I get this core-lint error: > > *** Core Lint errors : in result of Simplifier *** > : Warning: > [RHS of ds_a6bY :: (Set '["thres" :-> Int], Set (Unit Reader))] > Bad getNth: > Nth:0 > (Nth:2 > (Sub (Sym (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N > <'[]>_N)) > ; (Inv > _N <'["thres" :-> Int]>_N (Sym > TFCo:R:Unit[]Reader[0]))_R > ; Sub > (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N Reader>_N))) > Split '["thres" :-> Int] '[] (Union '["thres" :-> Int] '[]) > Split > '["thres" :-> Int] > (Unit Reader) > (Union '["thres" :-> Int] (Unit Reader)) > > I suppose "getNth" refers to the constructor "EvTupleSel" from "EvTerm", > "TcNthCo" from "TcCoercion" or to "NthCo" from "Coercion". But I never > produce evidence of the shape "getNth". My evidence production code can be > found at [1] and the only place where evidence of this shape can come > from is my "evaluateType" function [2] that calls "normaliseType" from the > GHC module "FamInstEnv". You can reproduce the error by checking out > commit 144525886ec107af6f1283b26b19f8125c980aa4 from [3] and running "make > effect-example" in the top directory of the repository (GHC 7.10 or better > is required and a sandbox is automatically created). > > The core-lint error does not seem to have any negative consequences when > ignored. The produced executable works fine. Can somebody explain why it > appears and maybe how I can fix it? > > Thank you! > Jan > > [1] > https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evidence.hs#L177 > [2] > https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evaluate.hs#L29 > [3] https://github.com/jbracker/polymonad-plugin > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Wed Nov 18 17:13:56 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 18 Nov 2015 12:13:56 -0500 Subject: Explanation of a core-lint warning (Bad getNth) In-Reply-To: References: Message-ID: Ah yes. I looked too quickly. Note that there are two NthCo's listed. Its the outermost that's the problem, which is deconstructing the Union. But it's doing so to prove that '["thres" :-> Int] ~ '["thres" :-> Int] which is rather easy to prove without NthCo. I'm not sure why GHC is doing this. Richard On Nov 18, 2015, at 12:11 PM, Jan Bracker wrote: > Hi Richard, > > No "Split" is a class and is defined here: http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-State.html#t:Split > "Union" is a type function (synonym that refers to a type function call): http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-Writer.html#t:Union > > thank you for your quick reply! > > Best, > Jan > > 2015-11-18 17:05 GMT+00:00 Richard Eisenberg : > I took just a quick look at this. Is Split a type family? The NthCo coercion form takes apart a composite equality into its pieces. For example, if we know (Maybe a ~ Maybe b), then NthCo:0 will tell us that (a ~ b). In your case, it looks like GHC is trying to deduce (Union '["thres" :-> Int] []) ~ (Union '["thres" :-> Int] (Unit Reader)) from an equality of two (Split ...) types. If Split is a type family, this deduction is unsound. That may be what Core Lint is worried about. > > I'm not surprised that the executable would run with an error. But it might not in the future. If -dcore-lint fails, it means that there is a potential type safety issue in the Core code, and this should be taken seriously. > > I hope this helps! > Richard > > On Nov 18, 2015, at 11:35 AM, Jan Bracker wrote: > >> Hi, >> >> I am using the type checker plugin interface and I am trying to produce some evidence for type class instances. During compilation of one of my examples I get this core-lint error: >> >> *** Core Lint errors : in result of Simplifier *** >> : Warning: >> [RHS of ds_a6bY :: (Set '["thres" :-> Int], Set (Unit Reader))] >> Bad getNth: >> Nth:0 >> (Nth:2 >> (Sub (Sym (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N <'[]>_N)) >> ; (Inv >> _N <'["thres" :-> Int]>_N (Sym TFCo:R:Unit[]Reader[0]))_R >> ; Sub >> (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N _N))) >> Split '["thres" :-> Int] '[] (Union '["thres" :-> Int] '[]) >> Split >> '["thres" :-> Int] >> (Unit Reader) >> (Union '["thres" :-> Int] (Unit Reader)) >> >> I suppose "getNth" refers to the constructor "EvTupleSel" from "EvTerm", "TcNthCo" from "TcCoercion" or to "NthCo" from "Coercion". But I never produce evidence of the shape "getNth". My evidence production code can be found at [1] and the only place where evidence of this shape can come from is my "evaluateType" function [2] that calls "normaliseType" from the GHC module "FamInstEnv". You can reproduce the error by checking out commit 144525886ec107af6f1283b26b19f8125c980aa4 from [3] and running "make effect-example" in the top directory of the repository (GHC 7.10 or better is required and a sandbox is automatically created). >> >> The core-lint error does not seem to have any negative consequences when ignored. The produced executable works fine. Can somebody explain why it appears and maybe how I can fix it? >> >> Thank you! >> Jan >> >> [1] https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evidence.hs#L177 >> [2] https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evaluate.hs#L29 >> [3] https://github.com/jbracker/polymonad-plugin >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.bracker at googlemail.com Wed Nov 18 17:19:48 2015 From: jan.bracker at googlemail.com (Jan Bracker) Date: Wed, 18 Nov 2015 17:19:48 +0000 Subject: Explanation of a core-lint warning (Bad getNth) In-Reply-To: References: Message-ID: As far as I understand your explanation this should not lead to an error, although it is not the most obvious coercion. Is that right? Do you or anybody else have a suggestion on how to resolve this issue? 2015-11-18 17:13 GMT+00:00 Richard Eisenberg : > Ah yes. I looked too quickly. Note that there are two NthCo's listed. Its > the outermost that's the problem, which is deconstructing the Union. But > it's doing so to prove that '["thres" :-> Int] ~ '["thres" :-> Int] which > is rather easy to prove without NthCo. I'm not sure why GHC is doing this. > > Richard > > On Nov 18, 2015, at 12:11 PM, Jan Bracker > wrote: > > Hi Richard, > > No "Split" is a class and is defined here: > http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-State.html#t:Split > "Union" is a type function (synonym that refers to a type function call): > http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-Writer.html#t:Union > > thank you for your quick reply! > > Best, > Jan > > 2015-11-18 17:05 GMT+00:00 Richard Eisenberg : > >> I took just a quick look at this. Is Split a type family? The NthCo >> coercion form takes apart a composite equality into its pieces. For >> example, if we know (Maybe a ~ Maybe b), then NthCo:0 will tell us that (a >> ~ b). In your case, it looks like GHC is trying to deduce (Union '["thres" >> :-> Int] []) ~ (Union '["thres" :-> Int] (Unit Reader)) from an equality of >> two (Split ...) types. If Split is a type family, this deduction is >> unsound. That may be what Core Lint is worried about. >> >> I'm not surprised that the executable would run with an error. But it >> might not in the future. If -dcore-lint fails, it means that there is a >> potential type safety issue in the Core code, and this should be taken >> seriously. >> >> I hope this helps! >> Richard >> >> On Nov 18, 2015, at 11:35 AM, Jan Bracker >> wrote: >> >> Hi, >> >> I am using the type checker plugin interface and I am trying to produce >> some evidence for type class instances. During compilation of one of my >> examples I get this core-lint error: >> >> *** Core Lint errors : in result of Simplifier *** >> : Warning: >> [RHS of ds_a6bY :: (Set '["thres" :-> Int], Set (Unit Reader))] >> Bad getNth: >> Nth:0 >> (Nth:2 >> (Sub (Sym (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N >> <'[]>_N)) >> ; (Inv >> _N <'["thres" :-> Int]>_N (Sym >> TFCo:R:Unit[]Reader[0]))_R >> ; Sub >> (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N > Reader>_N))) >> Split '["thres" :-> Int] '[] (Union '["thres" :-> Int] '[]) >> Split >> '["thres" :-> Int] >> (Unit Reader) >> (Union '["thres" :-> Int] (Unit Reader)) >> >> I suppose "getNth" refers to the constructor "EvTupleSel" from "EvTerm", >> "TcNthCo" from "TcCoercion" or to "NthCo" from "Coercion". But I never >> produce evidence of the shape "getNth". My evidence production code can be >> found at [1] and the only place where evidence of this shape can come >> from is my "evaluateType" function [2] that calls "normaliseType" from the >> GHC module "FamInstEnv". You can reproduce the error by checking out >> commit 144525886ec107af6f1283b26b19f8125c980aa4 from [3] and running "make >> effect-example" in the top directory of the repository (GHC 7.10 or better >> is required and a sandbox is automatically created). >> >> The core-lint error does not seem to have any negative consequences when >> ignored. The produced executable works fine. Can somebody explain why it >> appears and maybe how I can fix it? >> >> Thank you! >> Jan >> >> [1] >> https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evidence.hs#L177 >> [2] >> https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evaluate.hs#L29 >> [3] https://github.com/jbracker/polymonad-plugin >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Wed Nov 18 17:27:10 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 18 Nov 2015 12:27:10 -0500 Subject: Explanation of a core-lint warning (Bad getNth) In-Reply-To: References: Message-ID: <511EA726-CCE7-4A75-A4BF-87569B2E0E6E@cis.upenn.edu> On Nov 18, 2015, at 12:19 PM, Jan Bracker wrote: > As far as I understand your explanation this should not lead to an error, although it is not the most obvious coercion. Is that right? That's what it seems to be, in this particular case. But I'd be nervous with this result and would want further examination. My next port of call in your shoes would be to run with -ddump-tc-trace. I'm afraid I don't have the time right now to walk through that with you, though -- sorry! Richard > > Do you or anybody else have a suggestion on how to resolve this issue? > > 2015-11-18 17:13 GMT+00:00 Richard Eisenberg : > Ah yes. I looked too quickly. Note that there are two NthCo's listed. Its the outermost that's the problem, which is deconstructing the Union. But it's doing so to prove that '["thres" :-> Int] ~ '["thres" :-> Int] which is rather easy to prove without NthCo. I'm not sure why GHC is doing this. > > Richard > > On Nov 18, 2015, at 12:11 PM, Jan Bracker wrote: > >> Hi Richard, >> >> No "Split" is a class and is defined here: http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-State.html#t:Split >> "Union" is a type function (synonym that refers to a type function call): http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-Writer.html#t:Union >> >> thank you for your quick reply! >> >> Best, >> Jan >> >> 2015-11-18 17:05 GMT+00:00 Richard Eisenberg : >> I took just a quick look at this. Is Split a type family? The NthCo coercion form takes apart a composite equality into its pieces. For example, if we know (Maybe a ~ Maybe b), then NthCo:0 will tell us that (a ~ b). In your case, it looks like GHC is trying to deduce (Union '["thres" :-> Int] []) ~ (Union '["thres" :-> Int] (Unit Reader)) from an equality of two (Split ...) types. If Split is a type family, this deduction is unsound. That may be what Core Lint is worried about. >> >> I'm not surprised that the executable would run with an error. But it might not in the future. If -dcore-lint fails, it means that there is a potential type safety issue in the Core code, and this should be taken seriously. >> >> I hope this helps! >> Richard >> >> On Nov 18, 2015, at 11:35 AM, Jan Bracker wrote: >> >>> Hi, >>> >>> I am using the type checker plugin interface and I am trying to produce some evidence for type class instances. During compilation of one of my examples I get this core-lint error: >>> >>> *** Core Lint errors : in result of Simplifier *** >>> : Warning: >>> [RHS of ds_a6bY :: (Set '["thres" :-> Int], Set (Unit Reader))] >>> Bad getNth: >>> Nth:0 >>> (Nth:2 >>> (Sub (Sym (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N <'[]>_N)) >>> ; (Inv >>> _N <'["thres" :-> Int]>_N (Sym TFCo:R:Unit[]Reader[0]))_R >>> ; Sub >>> (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N _N))) >>> Split '["thres" :-> Int] '[] (Union '["thres" :-> Int] '[]) >>> Split >>> '["thres" :-> Int] >>> (Unit Reader) >>> (Union '["thres" :-> Int] (Unit Reader)) >>> >>> I suppose "getNth" refers to the constructor "EvTupleSel" from "EvTerm", "TcNthCo" from "TcCoercion" or to "NthCo" from "Coercion". But I never produce evidence of the shape "getNth". My evidence production code can be found at [1] and the only place where evidence of this shape can come from is my "evaluateType" function [2] that calls "normaliseType" from the GHC module "FamInstEnv". You can reproduce the error by checking out commit 144525886ec107af6f1283b26b19f8125c980aa4 from [3] and running "make effect-example" in the top directory of the repository (GHC 7.10 or better is required and a sandbox is automatically created). >>> >>> The core-lint error does not seem to have any negative consequences when ignored. The produced executable works fine. Can somebody explain why it appears and maybe how I can fix it? >>> >>> Thank you! >>> Jan >>> >>> [1] https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evidence.hs#L177 >>> [2] https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evaluate.hs#L29 >>> [3] https://github.com/jbracker/polymonad-plugin >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Wed Nov 18 21:10:14 2015 From: austin at well-typed.com (Austin Seipp) Date: Wed, 18 Nov 2015 15:10:14 -0600 Subject: HEADS UP: Phabricator will be moving to a new server soon. Message-ID: Hi *, After talking with Ben today, I'll be moving the Phabricator server to a new host Real Soon. Our current load has outgrown the very basic server we've been using for the past year. It's worked fine, but occasionally it cuts into swap space, causing things like request timeouts or errors. This is particularly noticeable on things like extremely large diffs, which we tend to have a handful of. This is also the first step in a two-part upgrade to the system, which I'd like to carry out sometime within the next week. The next step will be to upgrade our Phabricator to the latest version available upstream. Why have we held off on this? The primary reason is that Harbormaster, the component that does our builds, has undergone a very large rewrite. This was expected to happen, and for the most part the new implementation is *far* better in many measurable ways. It has taken some time, but I think it's now in a usable state for replacing our current system. I didn't want to upgrade it and take away one of the more useful features in the mean time. I will reply to this email with an exact time slot on the server migration. I'll have to push over a few gigs of data and resync it after taking down the HTTP server, so I imagine the downtime window will be small (< 1hr). The upgrade to Phabricator itself will come with many benefits, including: - The patch-build process will be more robust - buildbots should no longer need 'arc patch'. Phabricator will stage diffs in a special 'staging area' repository it manages, and you will be able to 'git pull' patches people post, directly into your tree! - More scalable build machine management. We will transparently be able to add new devices into a 'pool' of machines. For example, there could be 3 ARM devices in the 'ARM pool' and 10 x86 machines in the 'x86 pool'. These pools have machines leased out appropriately to build jobs. That means if you have *any* internet-addressable machine with some spare disk space/CPU, it can be added easily at a low cost, expanding our infrastructure. - A Mac Mini is now available for us to do builds on! I'll be turning it on along with this. And if you have your *own*, internet-addressable Mac - we can use that too! - Better build security, and CI builds for 'master' will be separated (on different machines) from (possibly hostile) patch builds. - We should be able to afford a significantly better set of Linux build machines. Harbormaster can do patches and commits in about ~30 minutes. Why not go for ~10min in the common case? :) - Remarkup now supports 'figlet' and 'cowsay' syntax, allowing you to Moo to your hearts desire, or give someone advice with large, 8-bit retro-style ASCII font rendering. There will be some other fun stuff coming down the pipe soon (a 'merge this patch' button directly in Phabricator, and on-demand build machines for even better performance are two examples). That's all for now! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From lonetiger at gmail.com Wed Nov 18 22:41:00 2015 From: lonetiger at gmail.com (lonetiger at gmail.com) Date: Wed, 18 Nov 2015 23:41:00 +0100 Subject: Window build broken In-Reply-To: References: <-8479951699220888539@unknownmsgid> Message-ID: <564cfe7b.c22e1c0a.eb6d1.ffffd0c6@mx.google.com> ?? Perhaps it is. Should I blow it away and re-install? I?d hold on that this. I have just tried building myself and also hit it. Taking a closer look, it seems that the .o file being produces isn?t an object file but an image file. It contains the standard image headers and a PE signature. GHC is doing the right thing in error out here. I think this is coming from D1242, there?s a linker script in there driver/utils/merge_sections.ld that?s causing ld on windows to output an image file instead of an object file. I?m afraid I am not familiar enough with ld to offer a proper fix, but to get you working again: In rules/build-package-way.mk on line 154, remove the ?$(if $(filter YES,$(LdIsGNULd)),-T $$($1_$2_LD_SCRIPT))? bit. That should get It working again. Regards, Tamar From: Simon Peyton Jones Sent: Wednesday, November 18, 2015 14:39 To: Tamar Christina;David Macek;ghc-devs at haskell.org Subject: RE: Window build broken | Presumably Simon didn't change this. Maybe the msys2 install is broken? Perhaps it is. Should I blow it away and re-install? One other difficulty is that (before my machine change) I tried to follow the instructions on https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows to install 64-bit msys2; but I had a series of problems that Ben G was unable to get to the bottom of. Particularly I could not run bash from emacs; the emacs shell window never got as far as a prompt. So I backed off. As far as I know that is still broken. I think I have not tried the "32-bit msys2 installer" on that page. Maybe that should be my next step? Regardless, it's hard to see how any of this concerns the error message I was getting. As lonetiger said, it looks very similar to https://ghc.haskell.org/trac/ghc/ticket/10437 What next? Simon | -----Original Message----- | From: Tamar Christina [mailto:lonetiger at gmail.com] | Sent: 18 November 2015 09:14 | To: David Macek; Simon Peyton Jones; ghc-devs at haskell.org | Subject: RE: Window build broken | | Hmm, | | Presumably Simon didn't change this. Maybe the msys2 install is broken? | | TamarFrom: David Macek | Sent: ?18/?11/?2015 09:35 | To: Simon Peyton Jones; lonetiger at gmail.com; ghc-devs at haskell.org | Subject: Re: Window build broken | On 18. 11. 2015 9:29, Simon Peyton Jones wrote: | > It?s msys2. I don?t have Cygwin on this machine. I have no idea where | that prompt comes from, but I agree it?s suspicious. | | Looks like your /etc/fstab is wrong. There should be a line like this one, | that removes the `cygdrive` prefix from Windows drive/letter | mounts: | | none / cygdrive binary,posix=0,noacl,user 0 0 | | -- | David Macek -------------- next part -------------- An HTML attachment was scrubbed... URL: From chak at justtesting.org Wed Nov 18 23:34:42 2015 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Thu, 19 Nov 2015 10:34:42 +1100 Subject: [ANNOUNCE] 7.10.3 release candidate 3 In-Reply-To: <87610zxt1r.fsf@smart-cactus.org> References: <87pozltpfv.fsf@smart-cactus.org> <87610zxt1r.fsf@smart-cactus.org> Message-ID: > Ben Gamari : > Lastly, I'd like to take a moment to acknowledge Futureice [2], who have > donated a brand new Mac Mini for use by GHC developers to help support > this platform. Their generosity is the reason we are able to offer OS X > builds to you today. > > Many thanks to Futureice for this donation! > [2] http://futurice.com/ Wow ? that is generous! Many thanks to them! Manuel From gershomb at gmail.com Thu Nov 19 04:44:05 2015 From: gershomb at gmail.com (Gershom B) Date: Wed, 18 Nov 2015 23:44:05 -0500 Subject: [ANNOUNCE] 7.10.3 release candidate 3 In-Reply-To: References: Message-ID: The link provided for rc3 (https://downloads.haskell.org/~ghc/7.10.3-rc3/) appears to be empty at the moment. However I have had success with a different link:?https://downloads.haskell.org/~ghc/ghc-7.10.3-rc3/ Cheers, Gershom From marlowsd at gmail.com Thu Nov 19 09:44:19 2015 From: marlowsd at gmail.com (Simon Marlow) Date: Thu, 19 Nov 2015 09:44:19 +0000 Subject: Remote GHCi In-Reply-To: References: <564AFD2F.6020305@gmail.com> <564C48B6.5070202@gmail.com> Message-ID: <564D99F3.9080809@gmail.com> Hi Andrew - Since the interpreted code is running in a separate process that we spawn using createProcess, we can set stdin/stdout/stderr to be whatever we like, including new pipes. GHC itself needs two pipes to communicate with the sub-process, but those use separate file descriptors from the std Handles. So I think the answer is yes, we can support that more easily with remote GHCi. I'll think about what API we can provide for it. Cheers, Simon On 18/11/2015 16:26, Andrew Gibiansky wrote: > Simon, > > I'd like to hear how we can support what IHaskell does with remote GHCi. > > One core functionality that we use dynCompileExpr for (not quite > dynCompileExpr, but similar) is getting the standard output of code that > is being run. Any time code is run, we > > 1. Create a unix pipe. > 2. Set stdout to point to that pipe using dupTo. > 3. Use hscStmt with unsafeCoerce to get the other end of the pipe in the > compiled context. > 4. Run the statement in the interpreted context in a separate thread; > meanwhile, read from the pipe to get the stdout of the code running in > the interpreted context. > 5. When it is done running, move stdout back to point to the read stdout > and close the unix pipe file handle. > 6. Send the stdout (both intermediate values and the final value) to the > frontend to display to the user. > > The key here is that we can access directly the file handle created by > the interpreted code. If the interpreted code is remote, we clearly > cannot read from a pipe it creates. In your remote GHCi, how could we > solve this problem? > > In general, how would stdin and stdout work? Would there be a clean way > to feed the remote process its stdin and receive its stdout and stderr? > That would effectively mean stdin/stdout/stderr are configurable which > would be a godsend for IHaskell. > > -- Andrew > > On Wed, Nov 18, 2015 at 1:45 AM, Simon Marlow > wrote: > > On 18/11/2015 01:41, Manuel M T Chakravarty wrote: > > Hi Simon, > > While this is an interesting proposal, Haskell for Mac strongly > relies on running interpreted code in the same process. I?m using > ?dynCompileExpr? as well as ?hscStmtWithLocation? and some other > stuff. > > > Let me say first of all that I'm not going to remove anything, so > there's no need to worry. But I'd like to explore exactly what you > need, so that we can see whether there's a way to accommodate it > with a separate-process implementation. > > hscStmtWithLocation is part of the core GHCi functionality, it is > definitely supported. It has a slightly different signature: > > hscStmtWithLocation :: HscEnv > -> String -- ^ The statement > -> String -- ^ The source > -> Int -- ^ Starting line > -> IO ( Maybe ([Id] > , RemoteHValue {- IO [HValue] -} > , FixityEnv)) > > RemoteHValue is a reference to a value in the interpreter's context. > These have to be evaluated via an explicit API, rather than just > unsafeCoercing HValue as we do now. (this is not strictly speaking > part of the GHC API, so a separate but interesting question is: why > did you need to use this directly, and what should we add to the GHC > API?) > > I believe that many uses of dynCompileExpr can be changed so that > the code using the resulting value is moved into the interpreter's > context, and then there's no problem. > > This is quite crucial for some of the interactive > functionality. Imagine a game where the game engine is in Swift > linked into the main application and the game logic is in > *interpreted* Haskell code. The engine calls into the Haskell code > multiple times per frame of the animation and for all > keyboard/mouse/etc input (using StablePtr and ForeignPtr to > construct > the scene graph across the Swift and Haskell heap). > > > So my question is, why wouldn't you run the whole game engine in the > interpreter's context? That's what would happen if you were to load > the program into GHCi and run it. Directly calling back and forth > between the client of the GHC API and the program being interpreted > is arguably a strange thing to do, and it's kind of accidental that > we allow it. > > I actually also might have a use for the architecture that you are > proposing. However, I really would like to keep the ability to, at > least, optionally run interpreted code in the same process (without > profiling etc). Do you think we could have both? > > > We can certainly have both, it's straightforward to implement, but I > don't get to throw away some of the hacks we have to support > same-process execution, which would be a shame. We just add more > code rather than > > > Cheers, > Manuel > > Simon Marlow >: > > Hi folks - I've been thinking about changing the way we run > interpreted code so that it would be run in a separate > process. It turns out this has quite a few benefits, and > would let us kill some of the really awkward hacks we have > in GHC to work around problems that arise because we're > running interpreted code and the compiler on the same runtime. > > I summarised the idea here: > https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi > > I'd be interested to hear if anyone has any thoughts around > this, particularly if doing this would make your life > difficult in some way. Are people relying on dynCompileExpr > for anything? > > Cheers, > Simon > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > From ben at well-typed.com Thu Nov 19 09:48:12 2015 From: ben at well-typed.com (Ben Gamari) Date: Thu, 19 Nov 2015 10:48:12 +0100 Subject: [ANNOUNCE] 7.10.3 release candidate 3 In-Reply-To: References: Message-ID: <87y4duwc9v.fsf@smart-cactus.org> Gershom B writes: > The link provided for rc3 (https://downloads.haskell.org/~ghc/7.10.3-rc3/) appears to be empty at the moment. > > However I have had success with a different link:?https://downloads.haskell.org/~ghc/ghc-7.10.3-rc3/ > Indeed my upload script had uploaded to the wrong directory. I have corrected this. Sorry for the confusion! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From simonpj at microsoft.com Thu Nov 19 17:14:58 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 19 Nov 2015 17:14:58 +0000 Subject: About Feature status for GHC 8.0 In-Reply-To: References: Message-ID: <163bcf2a1bf94fbb876ed4ea2f33154b@AM3PR30MB019.064d.mgd.msft.net> 1. Shall I assume that we will be part of GHC 8.0? Dropping the literals from the pattern syntax is not an option at the moment since I am as swamped as ever. Nevertheless I can sprint for about a week and wrap what we have up which works OK. Yes: provided it all validates, just commit it. It?s already a substantial improvement over what we have right now. I?d still like to understand why putting literals in guards rather than in patterns makes performance worse. But that should not stand in the way of getting it in. Still I hope you won?t drop the investigation altogether. I suspect that making literals-in-guards work acceptably well will improve performance all round. 1. Ben asked the developers to put the patches on the phabricator but you have told me that there is no need since you have reviewed the code yourself. Shall I assume this still holds? Yes I think so. Simon From: George Karachalias [mailto:george.karachalias at gmail.com] Sent: 18 November 2015 19:49 To: Simon Peyton Jones Cc: Tom Schrijvers ; Dimitrios Vytiniotis Subject: About Feature status for GHC 8.0 Hello Simon, I got the mail from Ben Gamari about the state of our patch (since GHC 8.0 release is approaching) and I would like to respond to Ben tomorrow about it. Current State As you have probably noticed, I reverted back to the last commit (just revert, I did not rewrite history) that was able to bootstrap the compiler. This means that literals are currently in the pattern syntax. I could not find why moving literals to the solver generated so many problems. The only thing that I didn't have the time to address yet is warnings for data families but the deadline is close so I will look into that. Performance of current implementation When I started the implementation, I branched on this commit (it was the HEAD at the time): https://git.haskell.org/ghc.git/commit/b14dae3cc43572a9dd5ca11241981105e4281aac For some time now I was under the impression that our checker consumes a lot of memory because we had many perf-failures from the test suit. Yet, I ran the test suite with the above version of GHC. The performance tests from the test suite that fail for our implementation fail for that as well. Hence, I do not think that it is our problem exactly, I expect GHC's current HEAD to perform OK, and when merging I do not expect any performance problems from our checker (the only performance test we fail is testsuite/tests/perf/compiler/T5642.hs which has pattern matching on ~100 constructors and also nested pattern matching so I think that it makes a lot of sense to consume more memory on this one). More importantly, what should my response to Ben be? Many users are expecting the new checker so I would like to merge what we have when I finish the data families handling. I would like to drop the literals from patterns but for now I think that having the improved checker in GHC 8.0 is more important. We can always make it more generic in the future. To wrap things up: 1. Shall I assume that we will be part of GHC 8.0? Dropping the literals from the pattern syntax is not an option at the moment since I am as swamped as ever. Nevertheless I can sprint for about a week and wrap what we have up which works OK. 2. Ben asked the developers to put the patches on the phabricator but you have told me that there is no need since you have reviewed the code yourself. Shall I assume this still holds? George -- things you own end up owning you -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Nov 19 17:14:58 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 19 Nov 2015 17:14:58 +0000 Subject: Window build broken In-Reply-To: <564cfe7b.c22e1c0a.eb6d1.ffffd0c6@mx.google.com> References: <-8479951699220888539@unknownmsgid> <564cfe7b.c22e1c0a.eb6d1.ffffd0c6@mx.google.com> Message-ID: I?m afraid I am not familiar enough with ld to offer a proper fix, but to get you working again: In rules/build-package-way.mk on line 154, remove the ?$(if $(filter YES,$(LdIsGNULd)),-T $$($1_$2_LD_SCRIPT))? bit. Yay. That worked! I can build again. Could you possibly ? Push that change, so that Windows builds work again. ? Open a ticket for a full fix. Presumably that bit of code was there for a reason, so there?s still an action outstanding. Thanks!! Simon From: lonetiger at gmail.com [mailto:lonetiger at gmail.com] Sent: 18 November 2015 22:41 To: Simon Peyton Jones ; David Macek ; ghc-devs at haskell.org Subject: RE: Window build broken > Perhaps it is. Should I blow it away and re-install? I?d hold on that this. I have just tried building myself and also hit it. Taking a closer look, it seems that the .o file being produces isn?t an object file but an image file. It contains the standard image headers and a PE signature. GHC is doing the right thing in error out here. I think this is coming from D1242, there?s a linker script in there driver/utils/merge_sections.ld that?s causing ld on windows to output an image file instead of an object file. I?m afraid I am not familiar enough with ld to offer a proper fix, but to get you working again: In rules/build-package-way.mk on line 154, remove the ?$(if $(filter YES,$(LdIsGNULd)),-T $$($1_$2_LD_SCRIPT))? bit. That should get It working again. Regards, Tamar From: Simon Peyton Jones Sent: Wednesday, November 18, 2015 14:39 To: Tamar Christina;David Macek;ghc-devs at haskell.org Subject: RE: Window build broken | Presumably Simon didn't change this. Maybe the msys2 install is broken? Perhaps it is. Should I blow it away and re-install? One other difficulty is that (before my machine change) I tried to follow the instructions on https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows to install 64-bit msys2; but I had a series of problems that Ben G was unable to get to the bottom of. Particularly I could not run bash from emacs; the emacs shell window never got as far as a prompt. So I backed off. As far as I know that is still broken. I think I have not tried the "32-bit msys2 installer" on that page. Maybe that should be my next step? Regardless, it's hard to see how any of this concerns the error message I was getting. As lonetiger said, it looks very similar to https://ghc.haskell.org/trac/ghc/ticket/10437 What next? Simon | -----Original Message----- | From: Tamar Christina [mailto:lonetiger at gmail.com] | Sent: 18 November 2015 09:14 | To: David Macek; Simon Peyton Jones; ghc-devs at haskell.org | Subject: RE: Window build broken | | Hmm, | | Presumably Simon didn't change this. Maybe the msys2 install is broken? | | TamarFrom: David Macek | Sent: ?18/?11/?2015 09:35 | To: Simon Peyton Jones; lonetiger at gmail.com; ghc-devs at haskell.org | Subject: Re: Window build broken | On 18. 11. 2015 9:29, Simon Peyton Jones wrote: | > It?s msys2. I don?t have Cygwin on this machine. I have no idea where | that prompt comes from, but I agree it?s suspicious. | | Looks like your /etc/fstab is wrong. There should be a line like this one, | that removes the `cygdrive` prefix from Windows drive/letter | mounts: | | none / cygdrive binary,posix=0,noacl,user 0 0 | | -- | David Macek -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at well-typed.com Thu Nov 19 17:23:38 2015 From: adam at well-typed.com (Adam Gundry) Date: Thu, 19 Nov 2015 17:23:38 +0000 Subject: Feature status for GHC 8.0 In-Reply-To: <87y4dwy7kh.fsf@smart-cactus.org> References: <87y4dwy7kh.fsf@smart-cactus.org> Message-ID: <564E059A.3010706@well-typed.com> Hi Ben, On 17/11/15 15:22, Ben Gamari wrote: > * OverloadedRecordFields Adam Gundry > Documentation needed > Full ORF not happening? That's right. The full status is described on the wiki [1]. The short story is that the DuplicateRecordFields and OverloadedLabels extensions are implemented and I will document them, but that I don't expect to have the constraint solver extensions ready for 8.0. While I think about it, are there any Template Haskell experts out there who could advise on #11103 [2]? Thanks, Adam [1] https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields [2] https://ghc.haskell.org/trac/ghc/ticket/11103 -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From andrew.gibiansky at gmail.com Thu Nov 19 17:37:43 2015 From: andrew.gibiansky at gmail.com (Andrew Gibiansky) Date: Thu, 19 Nov 2015 09:37:43 -0800 Subject: Remote GHCi In-Reply-To: <564D99F3.9080809@gmail.com> References: <564AFD2F.6020305@gmail.com> <564C48B6.5070202@gmail.com> <564D99F3.9080809@gmail.com> Message-ID: Simon, That's good to hear. That addresses one of the complex use cases for dynCompileExpr that we have. I'd like to present two more and see how we can address them. They both follow the same pattern so I will just describe the first one. In order to let interpreted Haskell code display images and other complex media to the frontend, the interpreted code uses unsafePerformIO to create a TChan. This TChan holds images (roughly speaking). The interpreted Haskell has access to a function which writes to this TChan. The compiled Haskell runs the interpreted Haskell in a separate thread. That thread then writes to this TChan (which lives in the interpreted context). In order to access values in the TChan, IHaskell uses dynCompileExpr on a value of type `IO [Image]`. This value is an IO action that reads from the TChan that lives in the interpreted context. This value is then run in the compiled code, giving IHaskell access to the results generated by the interpreter. I do not see how this can be easily replicated with a remote GHCi. The value is `IO [Image]`, so it is not serializable. `[Image]` is serializable; however, in order to get the Image values from the TChan, we would have to run interpreted code, and these images are generated during the runtime of interpreted code already, so we would need to be running two separate interpreted threads at once. This has to be completely invisible to the user and seems to me like it might be a logistical nightmare... And, if I understand correctly, GHC/GHCi are not thread safe, so I can't just use the new equivalent of dynCompileExpr from two threads. (Can I?) Thanks, -- Andrew On Thu, Nov 19, 2015 at 1:44 AM, Simon Marlow wrote: > Hi Andrew - > > Since the interpreted code is running in a separate process that we spawn > using createProcess, we can set stdin/stdout/stderr to be whatever we like, > including new pipes. GHC itself needs two pipes to communicate with the > sub-process, but those use separate file descriptors from the std Handles. > > So I think the answer is yes, we can support that more easily with remote > GHCi. I'll think about what API we can provide for it. > > Cheers, > Simon > > > On 18/11/2015 16:26, Andrew Gibiansky wrote: > >> Simon, >> >> I'd like to hear how we can support what IHaskell does with remote GHCi. >> >> One core functionality that we use dynCompileExpr for (not quite >> dynCompileExpr, but similar) is getting the standard output of code that >> is being run. Any time code is run, we >> >> 1. Create a unix pipe. >> 2. Set stdout to point to that pipe using dupTo. >> 3. Use hscStmt with unsafeCoerce to get the other end of the pipe in the >> compiled context. >> 4. Run the statement in the interpreted context in a separate thread; >> meanwhile, read from the pipe to get the stdout of the code running in >> the interpreted context. >> 5. When it is done running, move stdout back to point to the read stdout >> and close the unix pipe file handle. >> 6. Send the stdout (both intermediate values and the final value) to the >> frontend to display to the user. >> >> The key here is that we can access directly the file handle created by >> the interpreted code. If the interpreted code is remote, we clearly >> cannot read from a pipe it creates. In your remote GHCi, how could we >> solve this problem? >> >> In general, how would stdin and stdout work? Would there be a clean way >> to feed the remote process its stdin and receive its stdout and stderr? >> That would effectively mean stdin/stdout/stderr are configurable which >> would be a godsend for IHaskell. >> >> -- Andrew >> >> On Wed, Nov 18, 2015 at 1:45 AM, Simon Marlow > > wrote: >> >> On 18/11/2015 01:41, Manuel M T Chakravarty wrote: >> >> Hi Simon, >> >> While this is an interesting proposal, Haskell for Mac strongly >> relies on running interpreted code in the same process. I?m using >> ?dynCompileExpr? as well as ?hscStmtWithLocation? and some other >> stuff. >> >> >> Let me say first of all that I'm not going to remove anything, so >> there's no need to worry. But I'd like to explore exactly what you >> need, so that we can see whether there's a way to accommodate it >> with a separate-process implementation. >> >> hscStmtWithLocation is part of the core GHCi functionality, it is >> definitely supported. It has a slightly different signature: >> >> hscStmtWithLocation :: HscEnv >> -> String -- ^ The statement >> -> String -- ^ The source >> -> Int -- ^ Starting line >> -> IO ( Maybe ([Id] >> , RemoteHValue {- IO [HValue] -} >> , FixityEnv)) >> >> RemoteHValue is a reference to a value in the interpreter's context. >> These have to be evaluated via an explicit API, rather than just >> unsafeCoercing HValue as we do now. (this is not strictly speaking >> part of the GHC API, so a separate but interesting question is: why >> did you need to use this directly, and what should we add to the GHC >> API?) >> >> I believe that many uses of dynCompileExpr can be changed so that >> the code using the resulting value is moved into the interpreter's >> context, and then there's no problem. >> >> This is quite crucial for some of the interactive >> functionality. Imagine a game where the game engine is in Swift >> linked into the main application and the game logic is in >> *interpreted* Haskell code. The engine calls into the Haskell code >> multiple times per frame of the animation and for all >> keyboard/mouse/etc input (using StablePtr and ForeignPtr to >> construct >> the scene graph across the Swift and Haskell heap). >> >> >> So my question is, why wouldn't you run the whole game engine in the >> interpreter's context? That's what would happen if you were to load >> the program into GHCi and run it. Directly calling back and forth >> between the client of the GHC API and the program being interpreted >> is arguably a strange thing to do, and it's kind of accidental that >> we allow it. >> >> I actually also might have a use for the architecture that you are >> proposing. However, I really would like to keep the ability to, at >> least, optionally run interpreted code in the same process >> (without >> profiling etc). Do you think we could have both? >> >> >> We can certainly have both, it's straightforward to implement, but I >> don't get to throw away some of the hacks we have to support >> same-process execution, which would be a shame. We just add more >> code rather than >> >> >> Cheers, >> Manuel >> >> Simon Marlow > >>: >> >> Hi folks - I've been thinking about changing the way we run >> interpreted code so that it would be run in a separate >> process. It turns out this has quite a few benefits, and >> would let us kill some of the really awkward hacks we have >> in GHC to work around problems that arise because we're >> running interpreted code and the compiler on the same runtime. >> >> I summarised the idea here: >> https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi >> >> I'd be interested to hear if anyone has any thoughts around >> this, particularly if doing this would make your life >> difficult in some way. Are people relying on dynCompileExpr >> for anything? >> >> Cheers, >> Simon >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Nov 20 09:57:58 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 20 Nov 2015 09:57:58 +0000 Subject: Explanation of a core-lint warning (Bad getNth) In-Reply-To: References: Message-ID: <1471396847564ce18df16cc6a3692ace@DB4PR30MB030.064d.mgd.msft.net> I don't know how to help either, because there's no way to reproduce it. Can you find a Haskell program that, when GHC compiles it, produces this Lint error? Or does it require your plugin? If the latter, it's hard to know what your plugin might be doing... So I feel a bit stalled on how to help. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Richard Eisenberg Sent: 18 November 2015 17:14 To: Jan Bracker Cc: ghc-devs at haskell.org Subject: Re: Explanation of a core-lint warning (Bad getNth) Ah yes. I looked too quickly. Note that there are two NthCo's listed. Its the outermost that's the problem, which is deconstructing the Union. But it's doing so to prove that '["thres" :-> Int] ~ '["thres" :-> Int] which is rather easy to prove without NthCo. I'm not sure why GHC is doing this. Richard On Nov 18, 2015, at 12:11 PM, Jan Bracker > wrote: Hi Richard, No "Split" is a class and is defined here: http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-State.html#t:Split "Union" is a type function (synonym that refers to a type function call): http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-Writer.html#t:Union thank you for your quick reply! Best, Jan 2015-11-18 17:05 GMT+00:00 Richard Eisenberg >: I took just a quick look at this. Is Split a type family? The NthCo coercion form takes apart a composite equality into its pieces. For example, if we know (Maybe a ~ Maybe b), then NthCo:0 will tell us that (a ~ b). In your case, it looks like GHC is trying to deduce (Union '["thres" :-> Int] []) ~ (Union '["thres" :-> Int] (Unit Reader)) from an equality of two (Split ...) types. If Split is a type family, this deduction is unsound. That may be what Core Lint is worried about. I'm not surprised that the executable would run with an error. But it might not in the future. If -dcore-lint fails, it means that there is a potential type safety issue in the Core code, and this should be taken seriously. I hope this helps! Richard On Nov 18, 2015, at 11:35 AM, Jan Bracker > wrote: Hi, I am using the type checker plugin interface and I am trying to produce some evidence for type class instances. During compilation of one of my examples I get this core-lint error: *** Core Lint errors : in result of Simplifier *** : Warning: [RHS of ds_a6bY :: (Set '["thres" :-> Int], Set (Unit Reader))] Bad getNth: Nth:0 (Nth:2 (Sub (Sym (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N <'[]>_N)) ; (Inv _N <'["thres" :-> Int]>_N (Sym TFCo:R:Unit[]Reader[0]))_R ; Sub (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N _N))) Split '["thres" :-> Int] '[] (Union '["thres" :-> Int] '[]) Split '["thres" :-> Int] (Unit Reader) (Union '["thres" :-> Int] (Unit Reader)) I suppose "getNth" refers to the constructor "EvTupleSel" from "EvTerm", "TcNthCo" from "TcCoercion" or to "NthCo" from "Coercion". But I never produce evidence of the shape "getNth". My evidence production code can be found at [1] and the only place where evidence of this shape can come from is my "evaluateType" function [2] that calls "normaliseType" from the GHC module "FamInstEnv". You can reproduce the error by checking out commit 144525886ec107af6f1283b26b19f8125c980aa4 from [3] and running "make effect-example" in the top directory of the repository (GHC 7.10 or better is required and a sandbox is automatically created). The core-lint error does not seem to have any negative consequences when ignored. The produced executable works fine. Can somebody explain why it appears and maybe how I can fix it? Thank you! Jan [1] https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evidence.hs#L177 [2] https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evaluate.hs#L29 [3] https://github.com/jbracker/polymonad-plugin _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Nov 20 16:06:04 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 20 Nov 2015 16:06:04 +0000 Subject: Profiled build Message-ID: <9c834407a45c43d589322c9e049110b3@DB4PR30MB030.064d.mgd.msft.net> I can?t build a profiled HEAD compiler. In validate.mk I put GhcProfiled = YES GhcStage1HcOpts = -DDEBUG GhcStage2HcOpts = -fprof-auto GhcLibHcOpts += -Wwarn GhcLibWays += p But then ?sh validate ?fast? gives rts/RtsFlags.c: In function ?read_heap_profiling_flag?: rts/RtsFlags.c:1562:26: error: error: assignment discards ?const? qualifier from pointer target type [-Werror] rts/RtsFlags.c:1565:27: error: error: assignment discards ?const? qualifier from pointer target type [-Werror] cc1: all warnings being treated as errors `gcc' failed in phase `C Compiler'. (Exit code: 1) Does anyone have ideas for how to fix this? Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Fri Nov 20 16:13:32 2015 From: ben at well-typed.com (Ben Gamari) Date: Fri, 20 Nov 2015 17:13:32 +0100 Subject: Profiled build In-Reply-To: <9c834407a45c43d589322c9e049110b3@DB4PR30MB030.064d.mgd.msft.net> References: <9c834407a45c43d589322c9e049110b3@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <87poz4wswj.fsf@smart-cactus.org> Simon Peyton Jones writes: > I can?t build a profiled HEAD compiler. > I believe that this patch [1] will fix this (although I am still waiting on the build to verify this). To grab it, $ git remote add bgamari git://github.com/bgamari/ghc $ git remote update $ git cherry-pick 441dde678079bdd9ba80ca75aef18984dc2e3f8e Cheers, - Ben [1] https://github.com/bgamari/ghc/commit/441dde678079bdd9ba80ca75aef18984dc2e3f8e -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ben at well-typed.com Fri Nov 20 16:38:36 2015 From: ben at well-typed.com (Ben Gamari) Date: Fri, 20 Nov 2015 17:38:36 +0100 Subject: Profiled build In-Reply-To: <87poz4wswj.fsf@smart-cactus.org> References: <9c834407a45c43d589322c9e049110b3@DB4PR30MB030.064d.mgd.msft.net> <87poz4wswj.fsf@smart-cactus.org> Message-ID: <87lh9swrqr.fsf@smart-cactus.org> Ben Gamari writes: > Simon Peyton Jones writes: > >> I can?t build a profiled HEAD compiler. >> > I believe that this patch [1] will fix this (although I am still waiting > on the build to verify this). > Sadly this doesn't quite do it. Working on a fix. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From simonpj at microsoft.com Fri Nov 20 17:14:33 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 20 Nov 2015 17:14:33 +0000 Subject: spj-wildcard-refactor Message-ID: Status on my spj-wildcard-refactor patch ? I?m down to one test failure a modest perf regression on T3064. This is really a test of type family reduction which is nothing to do with my changes, so I have no idea what?s happening there. I?m waiting till I can build a profiled compiler to test. What?s the best workflow for to take my branch with tons of wibble-ish patches, and commit to HEAD with a small number of sensible patches. I was thinking: ? Git checkout wip/spj-wildcard-refactor ? Git merge master ? Git reset master (leaves working files alone) ? Now commit patches Is that right? Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Fri Nov 20 17:42:26 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Fri, 20 Nov 2015 19:42:26 +0200 Subject: spj-wildcard-refactor In-Reply-To: References: Message-ID: I would imagine git pull # Get master up to date git checkout wip/spj-wildcard-refactor git rebase -i master The -i will let you flatten commits See https://robots.thoughtbot.com/git-interactive-rebase-squash-amend-rewriting-history Alan On Fri, Nov 20, 2015 at 7:14 PM, Simon Peyton Jones wrote: > Status on my spj-wildcard-refactor patch > > ? I?m down to one test failure a modest perf regression on T3064. > This is really a test of type family reduction which is nothing to do > with my changes, so I have no idea what?s happening there. I?m waiting > till I can build a profiled compiler to test. > > > > What?s the best workflow for to take my branch with tons of wibble-ish > patches, and commit to HEAD with a small number of sensible patches. > > > > I was thinking: > > ? Git checkout wip/spj-wildcard-refactor > > ? Git merge master > > ? Git reset master (leaves working files alone) > > ? Now commit patches > > Is that right? > > > > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Nov 20 17:47:36 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 20 Nov 2015 17:47:36 +0000 Subject: Questions concerning the LLVM backend - i.e. 'proc point splitting' In-Reply-To: <5644BD6B.8060105@fim.uni-passau.de> References: <5644BD6B.8060105@fim.uni-passau.de> Message-ID: <0d142c3bd7da47a9b869481dcef9a374@DB4PR30MB030.064d.mgd.msft.net> David All this stuff is terribly paged-out for me. But I'd love someone to pay attention to some of this back-end stuff, so if you'd like to work there, I'd like to help you. David Terei was also thinking of getting rid of proc point splitting for LLVM (see attached email and the notes attached to it) Simon Marlow also was thinking about this; see his attached email. The main *reason* for establishing a proc-point is so that, when generating C code (which we don't do any more) you can take its address. E.g. foo() { ... Push &bar onto the stack (effectively a return address) Jump to thingumpy } bar() { ... } Really bar is part of foo, but we have make it a separate top level thing so that we can take the address of bar and push it on the stack. The trouble is that if there is a label inside bar that foo wants to jump to (i.e. without pushing &bar etc) then we have to make that label too into a proc-point, so that both foo and bar can see it. Urgh. In LLVM this probably is not true; presumably you can take the address of any label? Avoiding proc-point splitting would be GREAT. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | David Spitzenberg | Sent: 12 November 2015 16:25 | To: ghc-devs at haskell.org | Subject: Questions concerning the LLVM backend - i.e. 'proc point | splitting' | | Hello everybody, | | I've got some questions concerning the LLVM backend - i.e. the pass | 'proc point splitting' in the cmm-pipeline. | | I'm new to this list as well as to computer science in general - at | least in some sense. Being a third semester student of computer | science, I'm not quite sure, whether I'm addressing the right list | with this mail. Feel free to correct me, if not. | | I'm doing numerical stencil calculations which heavily depend on | nested loops expressed as tail-recursive functions nested one in | another. When compiling a module, GHC seems capable of emitting pretty | good cmm-code. | At least as long as the loop bodies do not contain any call to non- | inlineable functions. In most cases 'loopification' fires and | transforms tail-recursive calls into loops. | | When calling into non-inlineable functions, 'proc point splitting' is | performed. This splits the loops into several mutually-recursive | functions therefore significantly decreasing the possibilities of | 'opt' | in optimizing the code later on. This leads to pretty bad performance | of the whole calculation. | | To avoid the presence of proc points within a loop body - and by doing | so the splitting of the body - I currently try to avoid calls into | non-inlineable functions by merging the nested recursive functions | into one giant tail-recursive function. This works, as long as | everything not defined in the module being compiled can be inlined. | Apparently, this is not a long term solution. | | | | My questions: | | - The reason to perform 'proc point splitting' is, that LLVM IR lacks | of the possibility to call into an arbitrary basic block of a function | body from outside the function itself. Is this understanding right? | | - Are there any other possibilities to avoid 'proc point splitting' | when using LLVM as a backend? | | - I recently read the article on an improved LLVM backend in the GHC | wiki (https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend), but | couldn't find any suggestions on the topic of 'proc point splitting'. | Are there any plans to solve the problem either by teaching LLVM IR | the lacking functionality or in any other way? | | | | I'd really like to contribute to GHC by working on this problem, but | I'm not quite sure, if I'm capable of doing so. My background | knowledge is still somewhat limited, but I'm working on it ;-) | | Thanks in advance for your help! | | Regards, | | David Spitzenberg | | PS.: Thanks to everyone for the great work you're doing on GHC! | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h | askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cfe71402ab68e40b | 9777408d2eb7ddf90%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Bqkhoth | 1Ui6FRUwEbfHajdjx7g9bSrM25geCCDREdus%3d -------------- next part -------------- An embedded message was scrubbed... From: David Terei Subject: Re: Hoopl profiling Date: Fri, 18 Mar 2011 23:20:03 +0000 Size: 24312 URL: -------------- next part -------------- An embedded message was scrubbed... From: Simon Marlow Subject: RE: LLVM optimisation passes / tables next to code Date: Mon, 19 Mar 2012 10:12:35 +0000 Size: 8825 URL: From ezyang at mit.edu Fri Nov 20 18:41:34 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 20 Nov 2015 10:41:34 -0800 Subject: spj-wildcard-refactor In-Reply-To: References: Message-ID: <1448044770-sup-1683@sabre> IMO, reset is a fine way to do this if you don't care about any of this history. But Simon, you should use 'git reset --soft master' so that you don't have to re-add any new files (if you have any!). Edward Excerpts from Alan & Kim Zimmerman's message of 2015-11-20 09:42:26 -0800: > I would imagine > > git pull # Get master up to date > git checkout wip/spj-wildcard-refactor > git rebase -i master > > The -i will let you flatten commits > > See > https://robots.thoughtbot.com/git-interactive-rebase-squash-amend-rewriting-history > > Alan > > On Fri, Nov 20, 2015 at 7:14 PM, Simon Peyton Jones > wrote: > > > Status on my spj-wildcard-refactor patch > > > > ? I?m down to one test failure a modest perf regression on T3064. > > This is really a test of type family reduction which is nothing to do > > with my changes, so I have no idea what?s happening there. I?m waiting > > till I can build a profiled compiler to test. > > > > > > > > What?s the best workflow for to take my branch with tons of wibble-ish > > patches, and commit to HEAD with a small number of sensible patches. > > > > > > > > I was thinking: > > > > ? Git checkout wip/spj-wildcard-refactor > > > > ? Git merge master > > > > ? Git reset master (leaves working files alone) > > > > ? Now commit patches > > > > Is that right? > > > > > > > > Simon > > From tuncer.ayaz at gmail.com Fri Nov 20 18:42:29 2015 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Fri, 20 Nov 2015 19:42:29 +0100 Subject: Arcanist "lite" Haskell reimplementation (was: Proposal: accept pull requests on GitHub) In-Reply-To: <87si6rprqv.fsf@gnu.org> References: <87si6rprqv.fsf@gnu.org> Message-ID: On 6 September 2015 at 16:06, Herbert Valerio Riedel wrote: > I went ahead wasting some time and hacked up `arc-lite` for fun: > > https://github.com/haskell-infra/arc-lite > > It's currently at 407 Haskell SLOCs according to sloccount(1), and > emulates the `arc` CLI as a drop-in replacement. As a > proof-of-concept I've implemented the 3 simple operations > > - `arc install-certificate` > - `arc list` > - `arc call-conduit` > > If we wasted even more time, this could result in > > - Simplify installation of Arcanist for GHC contributors via Hacked > (i.e. just `cabal install arc-lite`) > - Implement a simple `arc diff`-like operation for submitting patches > to Phabricator > - Implement convenience operations tailored to GHC development > - Teach arc-lite to behave more Git-idomatic > - Make `arc-lite` automatically manage multi-commit code-reviews by > splitting them up and submit them as multiple inter-dependendant > code-revisions > - ... > > Any comments? I'm surprised there hasn't been any feedback on the list yet, so let me say I like this a lot. It'll be easier to get running than having the right PHP interpreter version with all required libraries. It's easier to bundle in the Haskell Platform as well. Do you plan to implement the most important commands, or is this project on ice (for now)? From ben at well-typed.com Fri Nov 20 23:00:30 2015 From: ben at well-typed.com (Ben Gamari) Date: Sat, 21 Nov 2015 00:00:30 +0100 Subject: Questions concerning the LLVM backend - i.e. 'proc point splitting' In-Reply-To: <0d142c3bd7da47a9b869481dcef9a374@DB4PR30MB030.064d.mgd.msft.net> References: <5644BD6B.8060105@fim.uni-passau.de> <0d142c3bd7da47a9b869481dcef9a374@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <87h9kgwa29.fsf@smart-cactus.org> Simon Peyton Jones writes: > David > > All this stuff is terribly paged-out for me. But I'd love someone to > pay attention to some of this back-end stuff, so if you'd like to work > there, I'd like to help you. > > David Terei was also thinking of getting rid of proc point splitting > for LLVM (see attached email and the notes attached to it) > > Simon Marlow also was thinking about this; see his attached email. > > The main *reason* for establishing a proc-point is so that, when > generating C code (which we don't do any more) you can take its > address. E.g. > > foo() { ... Push &bar onto the stack (effectively a return address) > Jump to thingumpy } > > bar() { ... } > > Really bar is part of foo, but we have make it a separate top level > thing so that we can take the address of bar and push it on the stack. > > The trouble is that if there is a label inside bar that foo wants to > jump to (i.e. without pushing &bar etc) then we have to make that > label too into a proc-point, so that both foo and bar can see it. > Urgh. > > In LLVM this probably is not true; presumably you can take the address > of any label? > This is true. While labels themselves have function-local scope in LLVM, there is an expression, `blockaddress`, which allows you to take an address to a label in another function [1]. That being said, in reading through the documentation it's not at all clear to me that it would be safe to jump to such an address. In fact, given that the instruction that this expression is supposed to be used with, `indirectbr`, can only be used for local blocks, I suspect it is not. More information about this feature can be found here [2]. The jump issue aside, I don't know how you would deal with tables-next-to-code. The prefix data support that currently available in LLVM is attached to functions and I unfortunately don't see that changing any time soon. Ultimately it seems that trying to refer to labels defined in other functions is using LLVM against the way it was intended. One alternative would be to teach llvmGen to merge mutually recusive top-level functions into a single LLVM function during code generation. Otherwise I'm afraid you are stuck with either the status quo or attempting to improve on LLVM's own cross-procedure optimization ability. That being said, it sounds as though eliminating proc-point splitting would make for quite a nice project in the native code generator. Cheers, - Ben [1] http://llvm.org/docs/LangRef.html#addresses-of-basic-blocks [2] http://blog.llvm.org/2010/01/address-of-label-and-indirect-branches.html [3] http://llvm.org/docs/LangRef.html#prefix-data -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From george.colpitts at gmail.com Fri Nov 20 23:55:10 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Fri, 20 Nov 2015 19:55:10 -0400 Subject: mac platform problem with configure in 7.10.3 release candidate 3 Message-ID: On MacOS if your path is such that gcc is the gnu gcc rather than Apple's gcc then ./configure gives checking whether we are cross compiling... configure: error: in `/Users/gcolpitts/downloads/ghc-7.10.2.20151114': configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details I worked around this by doing export PATH=/usr/bin:$PATH before doing ./configure After that the install worked fine. Thanks On Wed, Nov 18, 2015 at 10:48 AM, Ben Gamari wrote: > > Hello everyone, > > We are pleased to announce the third release candidate of GHC 7.10.3: > > https://downloads.haskell.org/~ghc/7.10.3-rc3/ > > There have been a few changes since -rc2, > > * The newly-introduced readelf configure check has been disabled on > non-ELF platforms > > * Some tracing output from the typechecker that was causing > some testsuites to fail was removed > > * A latent bug in call arity analysis (#11064) is fixed > > * A code generation bug (#10870) in the PowerPC NCG is fixed > > * A bug in the treatment of foreign calls during demand analysis > (#11076) which had affected GHCJS is fixed > > * A bug in the x86 NCG causing invalid assembly to be produced > when compiling with `-g` is fixed. > > At this moment you will find the source tarball, as well as, 64-bit > Windows, Mac OS X, 32- and 64-bit modern Linux (built on Debian 8) > binary distributions available at the above URL. As usual, you may need > to work around our content delivery network's update latency by adding > redundant forward-slashes to the URL. > > It has come to our attention that there still may be some issues with > long command lines on Windows with this release: While the toolchain > upgrade included in this release has the response file support necessary > to work around this limitation, the version of the Cabal library > shipped with this release does not. Unfortunately, the fix [1], which > affects Cabal's haddock integration, has not yet shipped in a Cabal > release. If you encounter this issue you might consider installing Cabal > and cabal-install from git. > > Lastly, I'd like to take a moment to acknowledge Futureice [2], who have > donated a brand new Mac Mini for use by GHC developers to help support > this platform. Their generosity is the reason we are able to offer OS X > builds to you today. > > Many thanks to Futureice for this donation! > > Happy testing! > > Cheers, > > - Ben > > > [1] > https://github.com/haskell/cabal/commit/1c1228a808b55331ac1db6d71fd2f8533f5fc57e > [2] http://futurice.com/ > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chak at justtesting.org Sat Nov 21 03:38:49 2015 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Sat, 21 Nov 2015 14:38:49 +1100 Subject: Remote GHCi In-Reply-To: <564C48B6.5070202@gmail.com> References: <564AFD2F.6020305@gmail.com> <564C48B6.5070202@gmail.com> Message-ID: <1B324BD5-4154-42A3-B094-2FD06CB02925@justtesting.org> > Simon Marlow : > On 18/11/2015 01:41, Manuel M T Chakravarty wrote: >> Hi Simon, >> >> While this is an interesting proposal, Haskell for Mac strongly >> relies on running interpreted code in the same process. I?m using >> ?dynCompileExpr? as well as ?hscStmtWithLocation? and some other >> stuff. > > Let me say first of all that I'm not going to remove anything, so there's no need to worry. But I'd like to explore exactly what you need, so that we can see whether there's a way to accommodate it with a separate-process implementation. > > hscStmtWithLocation is part of the core GHCi functionality, it is definitely supported. It has a slightly different signature: > > hscStmtWithLocation :: HscEnv > -> String -- ^ The statement > -> String -- ^ The source > -> Int -- ^ Starting line > -> IO ( Maybe ([Id] > , RemoteHValue {- IO [HValue] -} > , FixityEnv)) > > RemoteHValue is a reference to a value in the interpreter's context. These have to be evaluated via an explicit API, rather than just unsafeCoercing Value as we do now. (this is not strictly speaking part of the GHC API, so a separate but interesting question is: why did you need to use this directly, and what should we add to the GHC API?) The GHC API basically assumes that the ?result? of statement execution is the *side-effect* of printing the result to stdout. This is not sufficient for an interactive graphical environment as (1) I want to have the result (even if it is a string) separate from anything else interpreted code execution writes to stdout. (In Haskell for Mac, these things are displayed in different places.) (2) I want results that are not just strings. For example, a result (of running Haskell code) may be a ForeignPtr to a C-land data structure representing an image (e.g., an in-memory representation of a PNG image rendered by Diagrams). For the latter, I?m actually using `compileExpr`, then `unsafeCoerce` the `hValue` into `IO (ForeignPtr ())` and `try` that (to also catch any exceptions). When this code runs, in some cases, it calls back and forth between interpreted Haskell code and the host application using the FFI. > I believe that many uses of dynCompileExpr can be changed so that the code using the resulting value is moved into the interpreter?s context, and then there?s no problem. This is difficult in my case, because the resulting value is used in the GUI code written in Swift. Code running in a different process cannot call the Cocoa framework methods for the GUI of the main process. >> This is quite crucial for some of the interactive >> functionality. Imagine a game where the game engine is in Swift >> linked into the main application and the game logic is in >> *interpreted* Haskell code. The engine calls into the Haskell code >> multiple times per frame of the animation and for all >> keyboard/mouse/etc input (using StablePtr and ForeignPtr to construct >> the scene graph across the Swift and Haskell heap). > > So my question is, why wouldn't you run the whole game engine in the interpreter's context? That?s what would happen if you were to load the program into GHCi and run it. On a fundamental level: The game engine runs on OpenGL. If it is in a different process, it cannot access the OpenGL context of the main process (which it needs to do to render into a specific view of a specific window of the main process). In practice, it is not just an OpenGL problem as I?m using a framework called SpriteKit with its own event and rendering loop that in turn uses OpenGL for the actual rendering. It does a lot of things behind the scenes (which makes it convenient to use), which requires you to be careful which threads you use to execute some operations. Running in an entire different process is surely going to break things. > Directly calling back and forth between the client of the GHC API and the program being interpreted is arguably a strange thing to do, and it?s kind of accidental that we allow it. I understand that, but I also think that it is an artefact of Haskell mostly being used in a command line program set up. I don?t think, it is just by chance that the IHaskell people do some quite similar things to at least some of what I?m doing. Once you want a more interactive experience, call patterns get more complicated. >> I actually also might have a use for the architecture that you are >> proposing. However, I really would like to keep the ability to, at >> least, optionally run interpreted code in the same process (without >> profiling etc). Do you think we could have both? > > We can certainly have both, it's straightforward to implement, but I don't get to throw away some of the hacks we have to support same-process execution, which would be a shame. We just add more code rather than Yes, I understand that and, as I wrote, I do like the idea of running in a separate process. However, it would also be a shame to prevent richer and more interactive experiences than CLI applications. I have thought a bit more about what the fundamental obstacle is. I think, it is two things: (1) I have interpreted Haskell code that (via a compiled Haskell library) uses FFI calls to call Cocoa system framework methods to create Cocoa objects. In Haskell, these Cocoa objects are referenced via a ForeignPtr and I need the interpreter to be able to return these foreign pointers. The ForeignPtr?s need to refer to memory of the main host process; hence, the FFI calls need to run the Cocoa framework code in the host process. (2) The Cocoa objects from (1) include both StablePtrs as well as C function pointers created via foreign dynamic wrapper. At least some of the StablePtrs refer to Haskell heap structures that need to be accessed by interpreted Haskell code. And calling the dynamic wrapper code from Swift in the main process needs to execute Haskell code that may refer to closures created by interpreted code. So, the issue really is that I would need FFI calls in the interpreter process that call Cocoa code in the main process and dynamic wrapper entry code in the main process that needs to call Haskell code in the interpreter process. (Crossing the FFI language chasm corresponds to cross-process calls.) I cannot move the Cocoa code from the main process to the interpreter process, as Cocoa requires that it runs on the *main* thread of the main process (to interact with the GUI and also to render via OpenGL). Does that make sense? Cheers, Manuel >>> Simon Marlow : >>> >>> Hi folks - I've been thinking about changing the way we run interpreted code so that it would be run in a separate process. It turns out this has quite a few benefits, and would let us kill some of the really awkward hacks we have in GHC to work around problems that arise because we're running interpreted code and the compiler on the same runtime. >>> >>> I summarised the idea here: https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi >>> >>> I'd be interested to hear if anyone has any thoughts around this, particularly if doing this would make your life difficult in some way. Are people relying on dynCompileExpr for anything? >>> >>> Cheers, >>> Simon >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> From carter.schonwald at gmail.com Sat Nov 21 04:07:01 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 20 Nov 2015 23:07:01 -0500 Subject: mac platform problem with configure in 7.10.3 release candidate 3 In-Reply-To: References: Message-ID: Was this my build or the hq build? On Nov 20, 2015 6:55 PM, "George Colpitts" wrote: > On MacOS if your path is such that gcc is the gnu gcc rather than Apple's > gcc then ./configure gives > > checking whether we are cross compiling... configure: error: in > `/Users/gcolpitts/downloads/ghc-7.10.2.20151114': > configure: error: cannot run C compiled programs. > If you meant to cross compile, use `--host'. > See `config.log' for more details > > I worked around this by doing > > export PATH=/usr/bin:$PATH > > before doing ./configure > > After that the install worked fine. > > Thanks > > > On Wed, Nov 18, 2015 at 10:48 AM, Ben Gamari wrote: > >> >> Hello everyone, >> >> We are pleased to announce the third release candidate of GHC 7.10.3: >> >> https://downloads.haskell.org/~ghc/7.10.3-rc3/ >> >> There have been a few changes since -rc2, >> >> * The newly-introduced readelf configure check has been disabled on >> non-ELF platforms >> >> * Some tracing output from the typechecker that was causing >> some testsuites to fail was removed >> >> * A latent bug in call arity analysis (#11064) is fixed >> >> * A code generation bug (#10870) in the PowerPC NCG is fixed >> >> * A bug in the treatment of foreign calls during demand analysis >> (#11076) which had affected GHCJS is fixed >> >> * A bug in the x86 NCG causing invalid assembly to be produced >> when compiling with `-g` is fixed. >> >> At this moment you will find the source tarball, as well as, 64-bit >> Windows, Mac OS X, 32- and 64-bit modern Linux (built on Debian 8) >> binary distributions available at the above URL. As usual, you may need >> to work around our content delivery network's update latency by adding >> redundant forward-slashes to the URL. >> >> It has come to our attention that there still may be some issues with >> long command lines on Windows with this release: While the toolchain >> upgrade included in this release has the response file support necessary >> to work around this limitation, the version of the Cabal library >> shipped with this release does not. Unfortunately, the fix [1], which >> affects Cabal's haddock integration, has not yet shipped in a Cabal >> release. If you encounter this issue you might consider installing Cabal >> and cabal-install from git. >> >> Lastly, I'd like to take a moment to acknowledge Futureice [2], who have >> donated a brand new Mac Mini for use by GHC developers to help support >> this platform. Their generosity is the reason we are able to offer OS X >> builds to you today. >> >> Many thanks to Futureice for this donation! >> >> Happy testing! >> >> Cheers, >> >> - Ben >> >> >> [1] >> https://github.com/haskell/cabal/commit/1c1228a808b55331ac1db6d71fd2f8533f5fc57e >> [2] http://futurice.com/ >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Sat Nov 21 04:50:17 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 20 Nov 2015 23:50:17 -0500 Subject: new Typeable story Message-ID: Hi Simon, I'm a bit confused by the new handling of Typeable. * You say (in Note [Grand plan for Typeable]) that there is trouble making the TyCon/Module information for the types in GHC.Types. But what precisely goes wrong? I agree that it seems a bit fishy, but I don't actually see the spot where trouble lurks. Did you try this? * Even more bizarre would be putting TyCon/Module info for GHC.Prim stuff (I'm thinking about the super-magical TYPE) right in GHC.Prim. But still I can't quite articulate what goes wrong. There is no Prim.hi file that would be wonky. And, provided that GHC.Types itself doesn't try to solve a Typeable constraint, no one would ever notice the weird dependency. I recognize that this means we'd have to build the info somewhere manually in GHC, but I don't think that would be too hard -- and I think easier than the current story around name-mangling just so that you can write the typereps by hand in Data.Typeable.Internal. There's also not very many lifted tycons in GHC.Prim. I count TYPE and RealWorld, and that's it. For what it's worth, a weird dependency from GHC.Prim to GHC.Types actually works in practice. I put Levity in GHC.Types but (TYPE :: Levity -> TYPE 'Lifted) in GHC.Prim. No one complained. * Let's assume that we really can't clean up this mess. It still seems that several TyCons are missing from Data.Typeable.Internal. Like promoted nil and cons, and Nat, and Symbol. At the least, we should put a loud comment in the export list of GHC.Types saying that everything defined there must be accompanied by a definition in Data.Typeable.Internal. What do you think? Richard From eir at cis.upenn.edu Sat Nov 21 05:08:15 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Sat, 21 Nov 2015 00:08:15 -0500 Subject: new Typeable story In-Reply-To: References: Message-ID: <6689E5A3-A2B4-4515-A43D-E83EA71AEF1D@cis.upenn.edu> My bullet #3 below is correct. When I try to solve for Typeable '[1,2,3] in HEAD (*not* my branch), I get a panic in the desugarer. I will post a bug report. Separately, I have another question: * Data.Typeable.Internal uses mkGhcTypesTyCon, which refers to GHC.Types. But this function is used also for things from GHC.Prim, like (->). Solving (Typeable (->)) works fine. But I'm sure there's trouble lurking here. This is all captured in #11120. Richard On Nov 20, 2015, at 11:50 PM, Richard Eisenberg wrote: > Hi Simon, > > I'm a bit confused by the new handling of Typeable. > > * You say (in Note [Grand plan for Typeable]) that there is trouble making the TyCon/Module information for the types in GHC.Types. But what precisely goes wrong? I agree that it seems a bit fishy, but I don't actually see the spot where trouble lurks. Did you try this? > > * Even more bizarre would be putting TyCon/Module info for GHC.Prim stuff (I'm thinking about the super-magical TYPE) right in GHC.Prim. But still I can't quite articulate what goes wrong. There is no Prim.hi file that would be wonky. And, provided that GHC.Types itself doesn't try to solve a Typeable constraint, no one would ever notice the weird dependency. I recognize that this means we'd have to build the info somewhere manually in GHC, but I don't think that would be too hard -- and I think easier than the current story around name-mangling just so that you can write the typereps by hand in Data.Typeable.Internal. There's also not very many lifted tycons in GHC.Prim. I count TYPE and RealWorld, and that's it. > > For what it's worth, a weird dependency from GHC.Prim to GHC.Types actually works in practice. I put Levity in GHC.Types but (TYPE :: Levity -> TYPE 'Lifted) in GHC.Prim. No one complained. > > * Let's assume that we really can't clean up this mess. It still seems that several TyCons are missing from Data.Typeable.Internal. Like promoted nil and cons, and Nat, and Symbol. At the least, we should put a loud comment in the export list of GHC.Types saying that everything defined there must be accompanied by a definition in Data.Typeable.Internal. > > What do you think? > > Richard > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From george.colpitts at gmail.com Sat Nov 21 13:13:28 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Sat, 21 Nov 2015 09:13:28 -0400 Subject: mac platform problem with configure in 7.10.3 release candidate 3 In-Reply-To: References: Message-ID: The hq rc3 mac binary build is where I am reporting the problem. I also reproduced it on a mac just now on the hq rc3 src build which I guess is not surprising. I believe I encountered this in previous 7.10.3 builds but failed to report it. Sorry On Sat, Nov 21, 2015 at 12:07 AM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > Was this my build or the hq build? > On Nov 20, 2015 6:55 PM, "George Colpitts" > wrote: > >> On MacOS if your path is such that gcc is the gnu gcc rather than Apple's >> gcc then ./configure gives >> >> checking whether we are cross compiling... configure: error: in >> `/Users/gcolpitts/downloads/ghc-7.10.2.20151114': >> configure: error: cannot run C compiled programs. >> If you meant to cross compile, use `--host'. >> See `config.log' for more details >> >> I worked around this by doing >> >> export PATH=/usr/bin:$PATH >> >> before doing ./configure >> >> After that the install worked fine. >> >> Thanks >> >> >> On Wed, Nov 18, 2015 at 10:48 AM, Ben Gamari wrote: >> >>> >>> Hello everyone, >>> >>> We are pleased to announce the third release candidate of GHC 7.10.3: >>> >>> https://downloads.haskell.org/~ghc/7.10.3-rc3/ >>> >>> There have been a few changes since -rc2, >>> >>> * The newly-introduced readelf configure check has been disabled on >>> non-ELF platforms >>> >>> * Some tracing output from the typechecker that was causing >>> some testsuites to fail was removed >>> >>> * A latent bug in call arity analysis (#11064) is fixed >>> >>> * A code generation bug (#10870) in the PowerPC NCG is fixed >>> >>> * A bug in the treatment of foreign calls during demand analysis >>> (#11076) which had affected GHCJS is fixed >>> >>> * A bug in the x86 NCG causing invalid assembly to be produced >>> when compiling with `-g` is fixed. >>> >>> At this moment you will find the source tarball, as well as, 64-bit >>> Windows, Mac OS X, 32- and 64-bit modern Linux (built on Debian 8) >>> binary distributions available at the above URL. As usual, you may need >>> to work around our content delivery network's update latency by adding >>> redundant forward-slashes to the URL. >>> >>> It has come to our attention that there still may be some issues with >>> long command lines on Windows with this release: While the toolchain >>> upgrade included in this release has the response file support necessary >>> to work around this limitation, the version of the Cabal library >>> shipped with this release does not. Unfortunately, the fix [1], which >>> affects Cabal's haddock integration, has not yet shipped in a Cabal >>> release. If you encounter this issue you might consider installing Cabal >>> and cabal-install from git. >>> >>> Lastly, I'd like to take a moment to acknowledge Futureice [2], who have >>> donated a brand new Mac Mini for use by GHC developers to help support >>> this platform. Their generosity is the reason we are able to offer OS X >>> builds to you today. >>> >>> Many thanks to Futureice for this donation! >>> >>> Happy testing! >>> >>> Cheers, >>> >>> - Ben >>> >>> >>> [1] >>> https://github.com/haskell/cabal/commit/1c1228a808b55331ac1db6d71fd2f8533f5fc57e >>> [2] http://futurice.com/ >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >>> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Sat Nov 21 16:05:10 2015 From: ben at well-typed.com (Ben Gamari) Date: Sat, 21 Nov 2015 17:05:10 +0100 Subject: mac platform problem with configure in 7.10.3 release candidate 3 In-Reply-To: References: Message-ID: <87a8q7wd6x.fsf@smart-cactus.org> George Colpitts writes: > The hq rc3 mac binary build is where I am reporting the problem. > I also reproduced it on a mac just now on the hq rc3 src build which I > guess is not surprising. > > I believe I encountered this in previous 7.10.3 builds but failed to report > it. > > Sorry > > On Sat, Nov 21, 2015 at 12:07 AM, Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> Was this my build or the hq build? >> On Nov 20, 2015 6:55 PM, "George Colpitts" >> wrote: >> >>> On MacOS if your path is such that gcc is the gnu gcc rather than Apple's >>> gcc then ./configure gives >>> >>> checking whether we are cross compiling... configure: error: in >>> `/Users/gcolpitts/downloads/ghc-7.10.2.20151114': >>> configure: error: cannot run C compiled programs. >>> If you meant to cross compile, use `--host'. >>> See `config.log' for more details >>> It's not clear to me why Apple's "GCC" (actually clang, if I'm not mistaken) doesn't work here. Could you paste config.log somewhere? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From george.colpitts at gmail.com Sat Nov 21 17:26:57 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Sat, 21 Nov 2015 13:26:57 -0400 Subject: mac platform problem with configure in 7.10.3 release candidate 3 In-Reply-To: <87a8q7wd6x.fsf@smart-cactus.org> References: <87a8q7wd6x.fsf@smart-cactus.org> Message-ID: No, it's the reverse, it is gnu gcc that fails and Apple gcc that works Attached is the config.log for the failing case of gnu gcc On Sat, Nov 21, 2015 at 12:05 PM, Ben Gamari wrote: > George Colpitts writes: > > > The hq rc3 mac binary build is where I am reporting the problem. > > I also reproduced it on a mac just now on the hq rc3 src build which I > > guess is not surprising. > > > > I believe I encountered this in previous 7.10.3 builds but failed to > report > > it. > > > > Sorry > > > > On Sat, Nov 21, 2015 at 12:07 AM, Carter Schonwald < > > carter.schonwald at gmail.com> wrote: > > > >> Was this my build or the hq build? > >> On Nov 20, 2015 6:55 PM, "George Colpitts" > >> wrote: > >> > >>> On MacOS if your path is such that gcc is the gnu gcc rather than > Apple's > >>> gcc then ./configure gives > >>> > >>> checking whether we are cross compiling... configure: error: in > >>> `/Users/gcolpitts/downloads/ghc-7.10.2.20151114': > >>> configure: error: cannot run C compiled programs. > >>> If you meant to cross compile, use `--host'. > >>> See `config.log' for more details > >>> > It's not clear to me why Apple's "GCC" (actually clang, if I'm not > mistaken) doesn't work here. Could you paste config.log somewhere? > > Cheers, > > - Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 10492 bytes Desc: not available URL: From george.colpitts at gmail.com Sat Nov 21 18:07:12 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Sat, 21 Nov 2015 14:07:12 -0400 Subject: mac platform problem with configure in 7.10.3 release candidate 3 In-Reply-To: References: <87a8q7wd6x.fsf@smart-cactus.org> Message-ID: Maybe my gnu gcc is not functional, let me check it out and get back to you On Saturday, November 21, 2015, George Colpitts wrote: > No, it's the reverse, it is gnu gcc that fails and Apple gcc that works > > Attached is the config.log for the failing case of gnu gcc > > On Sat, Nov 21, 2015 at 12:05 PM, Ben Gamari > wrote: > >> George Colpitts > > writes: >> >> > The hq rc3 mac binary build is where I am reporting the problem. >> > I also reproduced it on a mac just now on the hq rc3 src build which I >> > guess is not surprising. >> > >> > I believe I encountered this in previous 7.10.3 builds but failed to >> report >> > it. >> > >> > Sorry >> > >> > On Sat, Nov 21, 2015 at 12:07 AM, Carter Schonwald < >> > carter.schonwald at gmail.com >> > wrote: >> > >> >> Was this my build or the hq build? >> >> On Nov 20, 2015 6:55 PM, "George Colpitts" > > >> >> wrote: >> >> >> >>> On MacOS if your path is such that gcc is the gnu gcc rather than >> Apple's >> >>> gcc then ./configure gives >> >>> >> >>> checking whether we are cross compiling... configure: error: in >> >>> `/Users/gcolpitts/downloads/ghc-7.10.2.20151114': >> >>> configure: error: cannot run C compiled programs. >> >>> If you meant to cross compile, use `--host'. >> >>> See `config.log' for more details >> >>> >> It's not clear to me why Apple's "GCC" (actually clang, if I'm not >> mistaken) doesn't work here. Could you paste config.log somewhere? >> >> Cheers, >> >> - Ben >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sat Nov 21 19:49:11 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 21 Nov 2015 14:49:11 -0500 Subject: mac platform problem with configure in 7.10.3 release candidate 3 In-Reply-To: References: <87a8q7wd6x.fsf@smart-cactus.org> Message-ID: What version of gcc are you using? I'll do my own rc3 build and share it. On Saturday, November 21, 2015, George Colpitts wrote: > Maybe my gnu gcc is not functional, let me check it out and get back to you > > On Saturday, November 21, 2015, George Colpitts > wrote: > >> No, it's the reverse, it is gnu gcc that fails and Apple gcc that works >> >> Attached is the config.log for the failing case of gnu gcc >> >> On Sat, Nov 21, 2015 at 12:05 PM, Ben Gamari wrote: >> >>> George Colpitts writes: >>> >>> > The hq rc3 mac binary build is where I am reporting the problem. >>> > I also reproduced it on a mac just now on the hq rc3 src build which I >>> > guess is not surprising. >>> > >>> > I believe I encountered this in previous 7.10.3 builds but failed to >>> report >>> > it. >>> > >>> > Sorry >>> > >>> > On Sat, Nov 21, 2015 at 12:07 AM, Carter Schonwald < >>> > carter.schonwald at gmail.com> wrote: >>> > >>> >> Was this my build or the hq build? >>> >> On Nov 20, 2015 6:55 PM, "George Colpitts" >> > >>> >> wrote: >>> >> >>> >>> On MacOS if your path is such that gcc is the gnu gcc rather than >>> Apple's >>> >>> gcc then ./configure gives >>> >>> >>> >>> checking whether we are cross compiling... configure: error: in >>> >>> `/Users/gcolpitts/downloads/ghc-7.10.2.20151114': >>> >>> configure: error: cannot run C compiled programs. >>> >>> If you meant to cross compile, use `--host'. >>> >>> See `config.log' for more details >>> >>> >>> It's not clear to me why Apple's "GCC" (actually clang, if I'm not >>> mistaken) doesn't work here. Could you paste config.log somewhere? >>> >>> Cheers, >>> >>> - Ben >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Sat Nov 21 23:02:45 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Sat, 21 Nov 2015 19:02:45 -0400 Subject: mac platform problem with configure in 7.10.3 release candidate 3 In-Reply-To: References: <87a8q7wd6x.fsf@smart-cactus.org> Message-ID: sorry for the noise, my gnu gcc is not functional, I do not believe there is any problem with ghc 7.10.3 rc3 My apologies George On Sat, Nov 21, 2015 at 2:07 PM, George Colpitts wrote: > Maybe my gnu gcc is not functional, let me check it out and get back to you > > > On Saturday, November 21, 2015, George Colpitts > wrote: > >> No, it's the reverse, it is gnu gcc that fails and Apple gcc that works >> >> Attached is the config.log for the failing case of gnu gcc >> >> On Sat, Nov 21, 2015 at 12:05 PM, Ben Gamari wrote: >> >>> George Colpitts writes: >>> >>> > The hq rc3 mac binary build is where I am reporting the problem. >>> > I also reproduced it on a mac just now on the hq rc3 src build which I >>> > guess is not surprising. >>> > >>> > I believe I encountered this in previous 7.10.3 builds but failed to >>> report >>> > it. >>> > >>> > Sorry >>> > >>> > On Sat, Nov 21, 2015 at 12:07 AM, Carter Schonwald < >>> > carter.schonwald at gmail.com> wrote: >>> > >>> >> Was this my build or the hq build? >>> >> On Nov 20, 2015 6:55 PM, "George Colpitts" >> > >>> >> wrote: >>> >> >>> >>> On MacOS if your path is such that gcc is the gnu gcc rather than >>> Apple's >>> >>> gcc then ./configure gives >>> >>> >>> >>> checking whether we are cross compiling... configure: error: in >>> >>> `/Users/gcolpitts/downloads/ghc-7.10.2.20151114': >>> >>> configure: error: cannot run C compiled programs. >>> >>> If you meant to cross compile, use `--host'. >>> >>> See `config.log' for more details >>> >>> >>> It's not clear to me why Apple's "GCC" (actually clang, if I'm not >>> mistaken) doesn't work here. Could you paste config.log somewhere? >>> >>> Cheers, >>> >>> - Ben >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Sun Nov 22 12:58:05 2015 From: ben at well-typed.com (Ben Gamari) Date: Sun, 22 Nov 2015 13:58:05 +0100 Subject: mac platform problem with configure in 7.10.3 release candidate 3 In-Reply-To: References: <87a8q7wd6x.fsf@smart-cactus.org> Message-ID: <877flaw5r6.fsf@smart-cactus.org> George Colpitts writes: > sorry for the noise, my gnu gcc is not functional, I do not believe there > is any problem with ghc 7.10.3 rc3 > No worries! Thanks for clarifying. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From eir at cis.upenn.edu Sun Nov 22 19:00:04 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Sun, 22 Nov 2015 14:00:04 -0500 Subject: Should (~) be homogeneous or heterogeneous? Message-ID: <535F0264-3D46-461E-96FF-DA6299E1D3D6@cis.upenn.edu> Hi devs, I'm desperately working toward getting kind equalities in before the feature freeze. It's coming along nicely. But I have a user-facing issue to work out. * Should (~), as written in user code, require the kinds of its arguments to be equal? Another way of asking the same question is: Should the kind of (~) be 1. forall k. k -> k -> Constraint (HEAD) 2. forall k1 k2. k1 -> k2 -> Constraint (my branch, at the moment) Choice #2 is strictly more powerful and cannot be expressed in terms of #1. But #1 is perhaps more intuitive for programmers, who might expect inference to conclude that the two kinds are the same. Here is an example of where the difference matters: > data KProxy k = KP > class kproxy ~ 'KP => C (kproxy :: KProxy k) We can see that the kind of the type variable kproxy should be (KProxy k). But we still have to infer the kind of the occurrence of 'KP on the left. HEAD sees the kind of kproxy and infers that 'KP should have kind (KProxy k). My branch, on the other hand, doesn't have any reason to constrain the kind of 'KP, and so it gets (KProxy Any), which quickly causes trouble. The fix is easy: add a kind signature. I see two ways forward, corresponding to the choices for the kind of (~) above: 1. Make (~) homogeneous and introduce a new constraint (~~) that is like (~) but heterogeneous. We resign ourselves to explaining the technical, subtle difference between (~) and (~~) into perpetuity. 2. Make (~) heterogeneous. Some people will have to add kind annotations to their code to port from GHC 7.10 to GHC 8.0. But these kind annotations will be fully backward-compatible, and won't require CPP, or warnings, or any other bother. We may have to explain why kind inference around (~) is weaker than it was before. I'm (clearly?) leaning toward #2. But I'd like feedback. Thoughts? Thanks! Richard From dan.doel at gmail.com Sun Nov 22 19:56:28 2015 From: dan.doel at gmail.com (Dan Doel) Date: Sun, 22 Nov 2015 14:56:28 -0500 Subject: Should (~) be homogeneous or heterogeneous? In-Reply-To: <535F0264-3D46-461E-96FF-DA6299E1D3D6@cis.upenn.edu> References: <535F0264-3D46-461E-96FF-DA6299E1D3D6@cis.upenn.edu> Message-ID: I don't know if you saw my idea for unlifted types that ties into the work-in-progress on improved impredicativity support, but it relies on the (transient) subtyping constraints being heterogeneous. So it'd need: !a <~ a even though `!a :: Unlifted` and `a :: *`. I don't think this has any direct bearing on ~, because <~ disappears pretty early, I think, and the `<~ turns into ~` rule could be conditioned on the arguments to <~ having homogeneous kinds. Now that I think about it, I'm unsure which direction this supports. The check on `<~ into ~` actually makes sense, because `!a <~ a` should only be satisfied by an 'identity' function `!a -> a`, because the opposite `a -> !a` isn't appropriate, and thus we shouldn't simply have `!a ~ a`. One could still do the check, though, even if ~ is heterogeneous itself. -- Dan On Sun, Nov 22, 2015 at 2:00 PM, Richard Eisenberg wrote: > Hi devs, > > I'm desperately working toward getting kind equalities in before the feature freeze. It's coming along nicely. But I have a user-facing issue to work out. > > * Should (~), as written in user code, require the kinds of its arguments to be equal? > > Another way of asking the same question is: Should the kind of (~) be > 1. forall k. k -> k -> Constraint (HEAD) > 2. forall k1 k2. k1 -> k2 -> Constraint (my branch, at the moment) > > Choice #2 is strictly more powerful and cannot be expressed in terms of #1. But #1 is perhaps more intuitive for programmers, who might expect inference to conclude that the two kinds are the same. > > Here is an example of where the difference matters: > >> data KProxy k = KP >> class kproxy ~ 'KP => C (kproxy :: KProxy k) > > We can see that the kind of the type variable kproxy should be (KProxy k). But we still have to infer the kind of the occurrence of 'KP on the left. HEAD sees the kind of kproxy and infers that 'KP should have kind (KProxy k). My branch, on the other hand, doesn't have any reason to constrain the kind of 'KP, and so it gets (KProxy Any), which quickly causes trouble. > > The fix is easy: add a kind signature. > > I see two ways forward, corresponding to the choices for the kind of (~) above: > > 1. Make (~) homogeneous and introduce a new constraint (~~) that is like (~) but heterogeneous. We resign ourselves to explaining the technical, subtle difference between (~) and (~~) into perpetuity. > > 2. Make (~) heterogeneous. Some people will have to add kind annotations to their code to port from GHC 7.10 to GHC 8.0. But these kind annotations will be fully backward-compatible, and won't require CPP, or warnings, or any other bother. We may have to explain why kind inference around (~) is weaker than it was before. > > > I'm (clearly?) leaning toward #2. But I'd like feedback. > > Thoughts? > > Thanks! > Richard > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From gershomb at gmail.com Sun Nov 22 20:53:20 2015 From: gershomb at gmail.com (Gershom B) Date: Sun, 22 Nov 2015 15:53:20 -0500 Subject: On parsing Haskell and CPP Message-ID: We've had quite a bit of discussion lately on the difficulty in performing automated processing of Haskell files in the presence of CPP. It turns out that folks have tackled this sort of problem in the world of C, and done some interesting work. I recently ran across SuperC [1], part of the xtc [2] project. In the setting of C they have achieved some impressive results, including as I understand it, the ability to handle the entire Linux kernel across all CPP-recognized configurations. They note that this is a rather tedious to implement task, even once one has recognized the specification of how to do so. However, the paper is good at reviewing related work and simpler techniques as well, and perhaps among them there is a "good enough" set for the CPP used in common Haskell libraries? Cheers, Gershom [1] https://cs.nyu.edu/rgrimm/papers/pldi12.pdf [2] http://cs.nyu.edu/xtc/ From simonpj at microsoft.com Mon Nov 23 10:13:33 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 23 Nov 2015 10:13:33 +0000 Subject: [GHC] #11019: ApiAnnotations: Make all RdrName occurences Located In-Reply-To: <059.42557279b0c58b19d3fb821bc0fb56ed@haskell.org> References: <044.6f9b0661f882f5c32756a32bbf81653d@haskell.org> <059.42557279b0c58b19d3fb821bc0fb56ed@haskell.org> Message-ID: Alan | ApiAnnotations: Make all RdrName occurences Located There is a principle here: that every RdrName occurrence is located. Is this principle articulated in a Note anywhere? I wish it was! (Including an explanation of why.) Otherwise you risk someone removing the change in a few years time. When I built HsSyn originally I reasoned that data HsExpr = ...| HsVar RdrName was better than data HsExpr = ... | HsVar (Located RdrName0 because the location on the RdrName is identical to that on the LHsExpr, so it's redundant. But you think it is non-redundant. I'm sure you are right (although I don't know why), but it would be a real help to document the invariant and the reasoning in the code somewhere. Are there any other principles that the code embodies? Thanks Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces at haskell.org] On Behalf | Of GHC | Sent: 22 November 2015 23:11 | Cc: ghc-tickets at haskell.org | Subject: Re: [GHC] #11019: ApiAnnotations: Make all RdrName occurences | Located | | #11019: ApiAnnotations: Make all RdrName occurences Located | -------------------------------------+-------------------------------- | -- | -------------------------------------+--- | Reporter: alanz | Owner: alanz | Type: bug | Status: new | Priority: normal | Milestone: 8.0.1 | Component: Compiler | Version: 7.10.2 | Resolution: | Keywords: | | ApiAnnotations | Operating System: Unknown/Multiple | Architecture: | | Unknown/Multiple | Type of failure: None/Unknown | Test Case: | Blocked By: | Blocking: | Related Tickets: | Differential Rev(s): | Phab:1512 | Wiki Page: | | -------------------------------------+-------------------------------- | -- | -------------------------------------+--- | | Comment (by Ben Gamari ): | | In [changeset:"3df9563e590bbfbfe1bc9171a0e8fc93ceef690d/ghc" | 3df9563e/ghc]: | {{{ | #!CommitTicketReference repository="ghc" | revision="3df9563e590bbfbfe1bc9171a0e8fc93ceef690d" | ApiAnnotations: Make all RdrName occurences Located | | At the moment the API Annotations can only be used on the | ParsedSource, as there are changes made to the RenamedSource that | prevent it from being used to round trip source code. | | It is possible to build a map from every Located Name in the | RenamedSource from its location to the Name, which can then be used | when resolved names are required when changing the ParsedSource. | | However, there are instances where the identifier is not located, | specifically | | (GHC.VarPat name) | (GHC.HsVar name) | (GHC.UserTyVar name) | (GHC.HsTyVar name) | | Replace each of the name types above with (Located name) | | Updates the haddock submodule. | | Test Plan: ./validate | | Reviewers: austin, goldfire, bgamari | | Reviewed By: bgamari | | Subscribers: goldfire, thomie, mpickering | | Differential Revision: https://phabricator.haskell.org/D1512 | | GHC Trac Issues: #11019 | }}} | | -- | Ticket URL: | | GHC | | The Glasgow Haskell Compiler | _______________________________________________ | ghc-tickets mailing list | ghc-tickets at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h | askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | tickets%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cd486e47f7 | 42f47e34e7308d2f39230b0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Q | aS%2fcmZrioGbpGHXUFNcdCmhyFt6mnV4DH4ucOsO7eo%3d From mjgajda at gmail.com Mon Nov 23 15:09:56 2015 From: mjgajda at gmail.com (=?UTF-8?Q?Micha=c5=82_J._Gajda?=) Date: Mon, 23 Nov 2015 23:09:56 +0800 Subject: Should (~) be homogeneous or heterogeneous? In-Reply-To: <535F0264-3D46-461E-96FF-DA6299E1D3D6@cis.upenn.edu> References: <535F0264-3D46-461E-96FF-DA6299E1D3D6@cis.upenn.edu> Message-ID: <56532C44.60402@gmail.com> Naive question: Would it be "evil" or otherwise complicated to assume that (~) is heterogeneous only in the _presence_ of kind constraint? Or only when the kind can be inferred? -- Cheers Michal On 23/11/2015 03:00, Richard Eisenberg wrote: > > * Should (~), as written in user code, require the kinds of its arguments to be equal? > We can see that the kind of the type variable kproxy should be (KProxy k). But we still have to infer the kind of the occurrence of 'KP on the left. HEAD sees the kind of kproxy and infers that 'KP should have kind (KProxy k). My branch, on the other hand, doesn't have any reason to constrain the kind of 'KP, and so it gets (KProxy Any), which quickly causes trouble. > > The fix is easy: add a kind signature. > > I see two ways forward, corresponding to the choices for the kind of (~) above: > > 1. Make (~) homogeneous and introduce a new constraint (~~) that is like (~) but heterogeneous. We resign ourselves to explaining the technical, subtle difference between (~) and (~~) into perpetuity. > > 2. Make (~) heterogeneous. Some people will have to add kind annotations to their code to port from GHC 7.10 to GHC 8.0. But these kind annotations will be fully backward-compatible, and won't require CPP, or warnings, or any other bother. We may have to explain why kind inference around (~) is weaker than it was before. From eir at cis.upenn.edu Mon Nov 23 16:05:33 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 23 Nov 2015 11:05:33 -0500 Subject: Should (~) be homogeneous or heterogeneous? In-Reply-To: <56532C44.60402@gmail.com> References: <535F0264-3D46-461E-96FF-DA6299E1D3D6@cis.upenn.edu> <56532C44.60402@gmail.com> Message-ID: > Naive question: > Would it be "evil" or otherwise complicated to assume that (~) is > heterogeneous only in the _presence_ of kind constraint? Or only when > the kind can be inferred? I'm afraid I don't understand. Do you mean that it's heterogeneous only when -XTypeInType is specified? That just might be possible, but I don't personally like it. Others might, though. Richard From marlowsd at gmail.com Mon Nov 23 16:26:17 2015 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 23 Nov 2015 16:26:17 +0000 Subject: Remote GHCi In-Reply-To: <1B324BD5-4154-42A3-B094-2FD06CB02925@justtesting.org> References: <564AFD2F.6020305@gmail.com> <564C48B6.5070202@gmail.com> <1B324BD5-4154-42A3-B094-2FD06CB02925@justtesting.org> Message-ID: <56533E29.3040703@gmail.com> Hi Manuel, Thanks for the detailed reply, I have a much better understanding of your requirements now. I'm going to support both models of running interpreted code. The current plan is to have a flag, -fexternal-interpreter, which GHC will use by default when running Template Haskell during compilation, and perhaps for GHCi, but for compatibility with applications like yours I'll probably leave it off for GHC API users. There's really no downside to doing this, it's not much more complicated than implementing the separate-process model. Cheers, Simon On 21/11/2015 03:38, Manuel M T Chakravarty wrote: >> Simon Marlow : >> On 18/11/2015 01:41, Manuel M T Chakravarty wrote: >>> Hi Simon, >>> >>> While this is an interesting proposal, Haskell for Mac strongly >>> relies on running interpreted code in the same process. I?m using >>> ?dynCompileExpr? as well as ?hscStmtWithLocation? and some other >>> stuff. >> >> Let me say first of all that I'm not going to remove anything, so there's no need to worry. But I'd like to explore exactly what you need, so that we can see whether there's a way to accommodate it with a separate-process implementation. >> >> hscStmtWithLocation is part of the core GHCi functionality, it is definitely supported. It has a slightly different signature: >> >> hscStmtWithLocation :: HscEnv >> -> String -- ^ The statement >> -> String -- ^ The source >> -> Int -- ^ Starting line >> -> IO ( Maybe ([Id] >> , RemoteHValue {- IO [HValue] -} >> , FixityEnv)) >> >> RemoteHValue is a reference to a value in the interpreter's context. These have to be evaluated via an explicit API, rather than just unsafeCoercing Value as we do now. (this is not strictly speaking part of the GHC API, so a separate but interesting question is: why did you need to use this directly, and what should we add to the GHC API?) > > The GHC API basically assumes that the ?result? of statement execution is the *side-effect* of printing the result to stdout. This is not sufficient for an interactive graphical environment as > > (1) I want to have the result (even if it is a string) separate from anything else interpreted code execution writes to stdout. (In Haskell for Mac, these things are displayed in different places.) > > (2) I want results that are not just strings. For example, a result (of running Haskell code) may be a ForeignPtr to a C-land data structure representing an image (e.g., an in-memory representation of a PNG image rendered by Diagrams). > > For the latter, I?m actually using `compileExpr`, then `unsafeCoerce` the `hValue` into `IO (ForeignPtr ())` and `try` that (to also catch any exceptions). When this code runs, in some cases, it calls back and forth between interpreted Haskell code and the host application using the FFI. > >> I believe that many uses of dynCompileExpr can be changed so that the code using the resulting value is moved into the interpreter?s context, and then there?s no problem. > > This is difficult in my case, because the resulting value is used in the GUI code written in Swift. Code running in a different process cannot call the Cocoa framework methods for the GUI of the main process. > >>> This is quite crucial for some of the interactive >>> functionality. Imagine a game where the game engine is in Swift >>> linked into the main application and the game logic is in >>> *interpreted* Haskell code. The engine calls into the Haskell code >>> multiple times per frame of the animation and for all >>> keyboard/mouse/etc input (using StablePtr and ForeignPtr to construct >>> the scene graph across the Swift and Haskell heap). >> >> So my question is, why wouldn't you run the whole game engine in the interpreter's context? That?s what would happen if you were to load the program into GHCi and run it. > > On a fundamental level: The game engine runs on OpenGL. If it is in a different process, it cannot access the OpenGL context of the main process (which it needs to do to render into a specific view of a specific window of the main process). > > In practice, it is not just an OpenGL problem as I?m using a framework called SpriteKit with its own event and rendering loop that in turn uses OpenGL for the actual rendering. It does a lot of things behind the scenes (which makes it convenient to use), which requires you to be careful which threads you use to execute some operations. Running in an entire different process is surely going to break things. > >> Directly calling back and forth between the client of the GHC API and the program being interpreted is arguably a strange thing to do, and it?s kind of accidental that we allow it. > > I understand that, but I also think that it is an artefact of Haskell mostly being used in a command line program set up. I don?t think, it is just by chance that the IHaskell people do some quite similar things to at least some of what I?m doing. Once you want a more interactive experience, call patterns get more complicated. > >>> I actually also might have a use for the architecture that you are >>> proposing. However, I really would like to keep the ability to, at >>> least, optionally run interpreted code in the same process (without >>> profiling etc). Do you think we could have both? >> >> We can certainly have both, it's straightforward to implement, but I don't get to throw away some of the hacks we have to support same-process execution, which would be a shame. We just add more code rather than > > Yes, I understand that and, as I wrote, I do like the idea of running in a separate process. However, it would also be a shame to prevent richer and more interactive experiences than CLI applications. > > I have thought a bit more about what the fundamental obstacle is. I think, it is two things: > > (1) I have interpreted Haskell code that (via a compiled Haskell library) uses FFI calls to call Cocoa system framework methods to create Cocoa objects. In Haskell, these Cocoa objects are referenced via a ForeignPtr and I need the interpreter to be able to return these foreign pointers. The ForeignPtr?s need to refer to memory of the main host process; hence, the FFI calls need to run the Cocoa framework code in the host process. > > (2) The Cocoa objects from (1) include both StablePtrs as well as C function pointers created via foreign dynamic wrapper. At least some of the StablePtrs refer to Haskell heap structures that need to be accessed by interpreted Haskell code. And calling the dynamic wrapper code from Swift in the main process needs to execute Haskell code that may refer to closures created by interpreted code. > > So, the issue really is that I would need FFI calls in the interpreter process that call Cocoa code in the main process and dynamic wrapper entry code in the main process that needs to call Haskell code in the interpreter process. (Crossing the FFI language chasm corresponds to cross-process calls.) > > I cannot move the Cocoa code from the main process to the interpreter process, as Cocoa requires that it runs on the *main* thread of the main process (to interact with the GUI and also to render via OpenGL). > > Does that make sense? > > Cheers, > Manuel > >>>> Simon Marlow : >>>> >>>> Hi folks - I've been thinking about changing the way we run interpreted code so that it would be run in a separate process. It turns out this has quite a few benefits, and would let us kill some of the really awkward hacks we have in GHC to work around problems that arise because we're running interpreted code and the compiler on the same runtime. >>>> >>>> I summarised the idea here: https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi >>>> >>>> I'd be interested to hear if anyone has any thoughts around this, particularly if doing this would make your life difficult in some way. Are people relying on dynCompileExpr for anything? >>>> >>>> Cheers, >>>> Simon >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> > From simonpj at microsoft.com Mon Nov 23 16:40:03 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 23 Nov 2015 16:40:03 +0000 Subject: [GHC] #11019: ApiAnnotations: Make all RdrName occurences Located In-Reply-To: References: <044.6f9b0661f882f5c32756a32bbf81653d@haskell.org> <059.42557279b0c58b19d3fb821bc0fb56ed@haskell.org> Message-ID: The commit is a one-line change to IEThingAll, which says: -- See Note [Located RdrNames] in HsExpr But HsExpr does not contain such a Note. Did you omit something? Simon From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] Sent: 23 November 2015 13:40 To: Simon Peyton Jones Subject: Re: [GHC] #11019: ApiAnnotations: Make all RdrName occurences Located Done, see https://phabricator.haskell.org/rGHC7c9a04d6eda5495f150a1140e6d26fc64e319b7e On Mon, Nov 23, 2015 at 12:13 PM, Simon Peyton Jones > wrote: Alan | ApiAnnotations: Make all RdrName occurences Located There is a principle here: that every RdrName occurrence is located. Is this principle articulated in a Note anywhere? I wish it was! (Including an explanation of why.) Otherwise you risk someone removing the change in a few years time. When I built HsSyn originally I reasoned that data HsExpr = ...| HsVar RdrName was better than data HsExpr = ... | HsVar (Located RdrName0 because the location on the RdrName is identical to that on the LHsExpr, so it's redundant. But you think it is non-redundant. I'm sure you are right (although I don't know why), but it would be a real help to document the invariant and the reasoning in the code somewhere. Are there any other principles that the code embodies? Thanks Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces at haskell.org] On Behalf | Of GHC | Sent: 22 November 2015 23:11 | Cc: ghc-tickets at haskell.org | Subject: Re: [GHC] #11019: ApiAnnotations: Make all RdrName occurences | Located | | #11019: ApiAnnotations: Make all RdrName occurences Located | -------------------------------------+-------------------------------- | -- | -------------------------------------+--- | Reporter: alanz | Owner: alanz | Type: bug | Status: new | Priority: normal | Milestone: 8.0.1 | Component: Compiler | Version: 7.10.2 | Resolution: | Keywords: | | ApiAnnotations | Operating System: Unknown/Multiple | Architecture: | | Unknown/Multiple | Type of failure: None/Unknown | Test Case: | Blocked By: | Blocking: | Related Tickets: | Differential Rev(s): | Phab:1512 | Wiki Page: | | -------------------------------------+-------------------------------- | -- | -------------------------------------+--- | | Comment (by Ben Gamari ): | | In [changeset:"3df9563e590bbfbfe1bc9171a0e8fc93ceef690d/ghc" | 3df9563e/ghc]: | {{{ | #!CommitTicketReference repository="ghc" | revision="3df9563e590bbfbfe1bc9171a0e8fc93ceef690d" | ApiAnnotations: Make all RdrName occurences Located | | At the moment the API Annotations can only be used on the | ParsedSource, as there are changes made to the RenamedSource that | prevent it from being used to round trip source code. | | It is possible to build a map from every Located Name in the | RenamedSource from its location to the Name, which can then be used | when resolved names are required when changing the ParsedSource. | | However, there are instances where the identifier is not located, | specifically | | (GHC.VarPat name) | (GHC.HsVar name) | (GHC.UserTyVar name) | (GHC.HsTyVar name) | | Replace each of the name types above with (Located name) | | Updates the haddock submodule. | | Test Plan: ./validate | | Reviewers: austin, goldfire, bgamari | | Reviewed By: bgamari | | Subscribers: goldfire, thomie, mpickering | | Differential Revision: https://phabricator.haskell.org/D1512 | | GHC Trac Issues: #11019 | }}} | | -- | Ticket URL: | %2ftrac%2fghc%2fticket%2f11019%23comment%3a5&data=01%7c01%7c | simonpj%40064d.mgd.microsoft.com%7cd486e47f742f47e34e7308d2f39230b0%7c | 72f988bf86f141af91ab2d7cd011db47%7c1&sdata=AmQZ%2boKbdHXQ4cuPjYOVePqF7 | ivXocZyqHXbcyBj3GY%3d> | GHC | %2fghc%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c | d486e47f742f47e34e7308d2f39230b0%7c72f988bf86f141af91ab2d7cd011db47%7c | 1&sdata=Ca9k88QpvsPGDgrkQCANdKLAPCnAKwoZdHzbIhBgnIU%3d> | The Glasgow Haskell Compiler | _______________________________________________ | ghc-tickets mailing list | ghc-tickets at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h | askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | tickets%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cd486e47f7 | 42f47e34e7308d2f39230b0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Q | aS%2fcmZrioGbpGHXUFNcdCmhyFt6mnV4DH4ucOsO7eo%3d -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.doel at gmail.com Mon Nov 23 17:02:32 2015 From: dan.doel at gmail.com (Dan Doel) Date: Mon, 23 Nov 2015 12:02:32 -0500 Subject: Should (~) be homogeneous or heterogeneous? In-Reply-To: References: <535F0264-3D46-461E-96FF-DA6299E1D3D6@cis.upenn.edu> <56532C44.60402@gmail.com> Message-ID: I suspect he means that with `t1 :: k1` and `t2 :: k2`, `t1 ~ t2` is permitted as long as `k1 ~ k2` accompanies it. However, this would already work with homogeneous ~, wouldn't it (because homogeneity is up to whatever constraints are in scope)? On Mon, Nov 23, 2015 at 11:05 AM, Richard Eisenberg wrote: >> Naive question: >> Would it be "evil" or otherwise complicated to assume that (~) is >> heterogeneous only in the _presence_ of kind constraint? Or only when >> the kind can be inferred? > > I'm afraid I don't understand. Do you mean that it's heterogeneous only when -XTypeInType is specified? That just might be possible, but I don't personally like it. Others might, though. > > Richard > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From chak at justtesting.org Tue Nov 24 00:25:28 2015 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Tue, 24 Nov 2015 11:25:28 +1100 Subject: Remote GHCi In-Reply-To: <56533E29.3040703@gmail.com> References: <564AFD2F.6020305@gmail.com> <564C48B6.5070202@gmail.com> <1B324BD5-4154-42A3-B094-2FD06CB02925@justtesting.org> <56533E29.3040703@gmail.com> Message-ID: <55E48C32-9E95-4B32-AD34-989FA0FA7875@justtesting.org> Hi Simon, Sounds great! This may very well what you have got in mind anyway, but I could imagine to run the interpreter on a different thread in the -fno-external-interpreter case and arrange communication through the same messaging API that you outlined for the seperate-process interpreter. Then, the essential difference between the two modes would be whether memory is shared or not (i.e., multithreading vs multi-process). Cheers, Manuel > Simon Marlow : > > Hi Manuel, > > Thanks for the detailed reply, I have a much better understanding of your requirements now. > > I'm going to support both models of running interpreted code. The current plan is to have a flag, -fexternal-interpreter, which GHC will use by default when running Template Haskell during compilation, and perhaps for GHCi, but for compatibility with applications like yours I'll probably leave it off for GHC API users. > > There's really no downside to doing this, it's not much more complicated than implementing the separate-process model. > > Cheers, > Simon > > On 21/11/2015 03:38, Manuel M T Chakravarty wrote: >>> Simon Marlow : >>> On 18/11/2015 01:41, Manuel M T Chakravarty wrote: >>>> Hi Simon, >>>> >>>> While this is an interesting proposal, Haskell for Mac strongly >>>> relies on running interpreted code in the same process. I?m using >>>> ?dynCompileExpr? as well as ?hscStmtWithLocation? and some other >>>> stuff. >>> >>> Let me say first of all that I'm not going to remove anything, so there's no need to worry. But I'd like to explore exactly what you need, so that we can see whether there's a way to accommodate it with a separate-process implementation. >>> >>> hscStmtWithLocation is part of the core GHCi functionality, it is definitely supported. It has a slightly different signature: >>> >>> hscStmtWithLocation :: HscEnv >>> -> String -- ^ The statement >>> -> String -- ^ The source >>> -> Int -- ^ Starting line >>> -> IO ( Maybe ([Id] >>> , RemoteHValue {- IO [HValue] -} >>> , FixityEnv)) >>> >>> RemoteHValue is a reference to a value in the interpreter's context. These have to be evaluated via an explicit API, rather than just unsafeCoercing Value as we do now. (this is not strictly speaking part of the GHC API, so a separate but interesting question is: why did you need to use this directly, and what should we add to the GHC API?) >> >> The GHC API basically assumes that the ?result? of statement execution is the *side-effect* of printing the result to stdout. This is not sufficient for an interactive graphical environment as >> >> (1) I want to have the result (even if it is a string) separate from anything else interpreted code execution writes to stdout. (In Haskell for Mac, these things are displayed in different places.) >> >> (2) I want results that are not just strings. For example, a result (of running Haskell code) may be a ForeignPtr to a C-land data structure representing an image (e.g., an in-memory representation of a PNG image rendered by Diagrams). >> >> For the latter, I?m actually using `compileExpr`, then `unsafeCoerce` the `hValue` into `IO (ForeignPtr ())` and `try` that (to also catch any exceptions). When this code runs, in some cases, it calls back and forth between interpreted Haskell code and the host application using the FFI. >> >>> I believe that many uses of dynCompileExpr can be changed so that the code using the resulting value is moved into the interpreter?s context, and then there?s no problem. >> >> This is difficult in my case, because the resulting value is used in the GUI code written in Swift. Code running in a different process cannot call the Cocoa framework methods for the GUI of the main process. >> >>>> This is quite crucial for some of the interactive >>>> functionality. Imagine a game where the game engine is in Swift >>>> linked into the main application and the game logic is in >>>> *interpreted* Haskell code. The engine calls into the Haskell code >>>> multiple times per frame of the animation and for all >>>> keyboard/mouse/etc input (using StablePtr and ForeignPtr to construct >>>> the scene graph across the Swift and Haskell heap). >>> >>> So my question is, why wouldn't you run the whole game engine in the interpreter's context? That?s what would happen if you were to load the program into GHCi and run it. >> >> On a fundamental level: The game engine runs on OpenGL. If it is in a different process, it cannot access the OpenGL context of the main process (which it needs to do to render into a specific view of a specific window of the main process). >> >> In practice, it is not just an OpenGL problem as I?m using a framework called SpriteKit with its own event and rendering loop that in turn uses OpenGL for the actual rendering. It does a lot of things behind the scenes (which makes it convenient to use), which requires you to be careful which threads you use to execute some operations. Running in an entire different process is surely going to break things. >> >>> Directly calling back and forth between the client of the GHC API and the program being interpreted is arguably a strange thing to do, and it?s kind of accidental that we allow it. >> >> I understand that, but I also think that it is an artefact of Haskell mostly being used in a command line program set up. I don?t think, it is just by chance that the IHaskell people do some quite similar things to at least some of what I?m doing. Once you want a more interactive experience, call patterns get more complicated. >> >>>> I actually also might have a use for the architecture that you are >>>> proposing. However, I really would like to keep the ability to, at >>>> least, optionally run interpreted code in the same process (without >>>> profiling etc). Do you think we could have both? >>> >>> We can certainly have both, it's straightforward to implement, but I don't get to throw away some of the hacks we have to support same-process execution, which would be a shame. We just add more code rather than >> >> Yes, I understand that and, as I wrote, I do like the idea of running in a separate process. However, it would also be a shame to prevent richer and more interactive experiences than CLI applications. >> >> I have thought a bit more about what the fundamental obstacle is. I think, it is two things: >> >> (1) I have interpreted Haskell code that (via a compiled Haskell library) uses FFI calls to call Cocoa system framework methods to create Cocoa objects. In Haskell, these Cocoa objects are referenced via a ForeignPtr and I need the interpreter to be able to return these foreign pointers. The ForeignPtr?s need to refer to memory of the main host process; hence, the FFI calls need to run the Cocoa framework code in the host process. >> >> (2) The Cocoa objects from (1) include both StablePtrs as well as C function pointers created via foreign dynamic wrapper. At least some of the StablePtrs refer to Haskell heap structures that need to be accessed by interpreted Haskell code. And calling the dynamic wrapper code from Swift in the main process needs to execute Haskell code that may refer to closures created by interpreted code. >> >> So, the issue really is that I would need FFI calls in the interpreter process that call Cocoa code in the main process and dynamic wrapper entry code in the main process that needs to call Haskell code in the interpreter process. (Crossing the FFI language chasm corresponds to cross-process calls.) >> >> I cannot move the Cocoa code from the main process to the interpreter process, as Cocoa requires that it runs on the *main* thread of the main process (to interact with the GUI and also to render via OpenGL). >> >> Does that make sense? >> >> Cheers, >> Manuel >> >>>>> Simon Marlow : >>>>> >>>>> Hi folks - I've been thinking about changing the way we run interpreted code so that it would be run in a separate process. It turns out this has quite a few benefits, and would let us kill some of the really awkward hacks we have in GHC to work around problems that arise because we're running interpreted code and the compiler on the same runtime. >>>>> >>>>> I summarised the idea here: https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi >>>>> >>>>> I'd be interested to hear if anyone has any thoughts around this, particularly if doing this would make your life difficult in some way. Are people relying on dynCompileExpr for anything? >>>>> >>>>> Cheers, >>>>> Simon >>>>> _______________________________________________ >>>>> ghc-devs mailing list >>>>> ghc-devs at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From erkokl at gmail.com Tue Nov 24 07:37:28 2015 From: erkokl at gmail.com (Levent Erkok) Date: Mon, 23 Nov 2015 23:37:28 -0800 Subject: Plugins: How to determine ghc vs ghci Message-ID: I'm working on a plugin, and would like to be able to tell if it's GHC or GHCi that's running. I tried: df <- getDynFlags let isGHCi = ghcMode df == CompManager Alas, while that correctly tells apart "ghci" from "ghc -c", it also returns True when ghc is called without the "-c" argument. Is there a better/more robust way of figuring out whether we're in an interactive session? -Levent. -------------- next part -------------- An HTML attachment was scrubbed... URL: From iricanaycan at gmail.com Tue Nov 24 08:28:50 2015 From: iricanaycan at gmail.com (=?utf-8?Q?Aycan_=C4=B0rican?=) Date: Tue, 24 Nov 2015 10:28:50 +0200 Subject: Plugins: How to determine ghc vs ghci In-Reply-To: References: Message-ID: <4B57134C-623E-47C2-BD21-7615EC9E8149@gmail.com> How about `GHC.Environment.getFullArgs` which includes ??interactive? when you?re in GHCi? > On 24 Nov 2015, at 09:37, Levent Erkok wrote: > > I'm working on a plugin, and would like to be able to tell if it's GHC or GHCi that's running. > > I tried: > > df <- getDynFlags > let isGHCi = ghcMode df == CompManager > > Alas, while that correctly tells apart "ghci" from "ghc -c", it also returns True when ghc is called without the "-c" argument. > > Is there a better/more robust way of figuring out whether we're in an interactive session? > > -Levent. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From alan.zimm at gmail.com Tue Nov 24 11:04:40 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Tue, 24 Nov 2015 13:04:40 +0200 Subject: Remote GHCi In-Reply-To: <55E48C32-9E95-4B32-AD34-989FA0FA7875@justtesting.org> References: <564AFD2F.6020305@gmail.com> <564C48B6.5070202@gmail.com> <1B324BD5-4154-42A3-B094-2FD06CB02925@justtesting.org> <56533E29.3040703@gmail.com> <55E48C32-9E95-4B32-AD34-989FA0FA7875@justtesting.org> Message-ID: What kind of timescale can we expect on this, and will it be possible to backport it (via a ghci-ng or similar)? We are currently wrestling with ghci stdio issues in haskell-ide-engine. If this will be out soon we can wait for it. Alan On Tue, Nov 24, 2015 at 2:25 AM, Manuel M T Chakravarty < chak at justtesting.org> wrote: > Hi Simon, > > Sounds great! > > This may very well what you have got in mind anyway, but I could imagine > to run the interpreter on a different thread in the > -fno-external-interpreter case and arrange communication through the same > messaging API that you outlined for the seperate-process interpreter. Then, > the essential difference between the two modes would be whether memory is > shared or not (i.e., multithreading vs multi-process). > > Cheers, > Manuel > > > Simon Marlow : > > > > Hi Manuel, > > > > Thanks for the detailed reply, I have a much better understanding of > your requirements now. > > > > I'm going to support both models of running interpreted code. The > current plan is to have a flag, -fexternal-interpreter, which GHC will use > by default when running Template Haskell during compilation, and perhaps > for GHCi, but for compatibility with applications like yours I'll probably > leave it off for GHC API users. > > > > There's really no downside to doing this, it's not much more complicated > than implementing the separate-process model. > > > > Cheers, > > Simon > > > > On 21/11/2015 03:38, Manuel M T Chakravarty wrote: > >>> Simon Marlow : > >>> On 18/11/2015 01:41, Manuel M T Chakravarty wrote: > >>>> Hi Simon, > >>>> > >>>> While this is an interesting proposal, Haskell for Mac strongly > >>>> relies on running interpreted code in the same process. I?m using > >>>> ?dynCompileExpr? as well as ?hscStmtWithLocation? and some other > >>>> stuff. > >>> > >>> Let me say first of all that I'm not going to remove anything, so > there's no need to worry. But I'd like to explore exactly what you need, > so that we can see whether there's a way to accommodate it with a > separate-process implementation. > >>> > >>> hscStmtWithLocation is part of the core GHCi functionality, it is > definitely supported. It has a slightly different signature: > >>> > >>> hscStmtWithLocation :: HscEnv > >>> -> String -- ^ The statement > >>> -> String -- ^ The source > >>> -> Int -- ^ Starting line > >>> -> IO ( Maybe ([Id] > >>> , RemoteHValue {- IO [HValue] -} > >>> , FixityEnv)) > >>> > >>> RemoteHValue is a reference to a value in the interpreter's context. > These have to be evaluated via an explicit API, rather than just > unsafeCoercing Value as we do now. (this is not strictly speaking part of > the GHC API, so a separate but interesting question is: why did you need to > use this directly, and what should we add to the GHC API?) > >> > >> The GHC API basically assumes that the ?result? of statement execution > is the *side-effect* of printing the result to stdout. This is not > sufficient for an interactive graphical environment as > >> > >> (1) I want to have the result (even if it is a string) separate from > anything else interpreted code execution writes to stdout. (In Haskell for > Mac, these things are displayed in different places.) > >> > >> (2) I want results that are not just strings. For example, a result (of > running Haskell code) may be a ForeignPtr to a C-land data structure > representing an image (e.g., an in-memory representation of a PNG image > rendered by Diagrams). > >> > >> For the latter, I?m actually using `compileExpr`, then `unsafeCoerce` > the `hValue` into `IO (ForeignPtr ())` and `try` that (to also catch any > exceptions). When this code runs, in some cases, it calls back and forth > between interpreted Haskell code and the host application using the FFI. > >> > >>> I believe that many uses of dynCompileExpr can be changed so that the > code using the resulting value is moved into the interpreter?s context, and > then there?s no problem. > >> > >> This is difficult in my case, because the resulting value is used in > the GUI code written in Swift. Code running in a different process cannot > call the Cocoa framework methods for the GUI of the main process. > >> > >>>> This is quite crucial for some of the interactive > >>>> functionality. Imagine a game where the game engine is in Swift > >>>> linked into the main application and the game logic is in > >>>> *interpreted* Haskell code. The engine calls into the Haskell code > >>>> multiple times per frame of the animation and for all > >>>> keyboard/mouse/etc input (using StablePtr and ForeignPtr to construct > >>>> the scene graph across the Swift and Haskell heap). > >>> > >>> So my question is, why wouldn't you run the whole game engine in the > interpreter's context? That?s what would happen if you were to load the > program into GHCi and run it. > >> > >> On a fundamental level: The game engine runs on OpenGL. If it is in a > different process, it cannot access the OpenGL context of the main process > (which it needs to do to render into a specific view of a specific window > of the main process). > >> > >> In practice, it is not just an OpenGL problem as I?m using a framework > called SpriteKit with its own event and rendering loop that in turn uses > OpenGL for the actual rendering. It does a lot of things behind the scenes > (which makes it convenient to use), which requires you to be careful which > threads you use to execute some operations. Running in an entire different > process is surely going to break things. > >> > >>> Directly calling back and forth between the client of the GHC API > and the program being interpreted is arguably a strange thing to do, and > it?s kind of accidental that we allow it. > >> > >> I understand that, but I also think that it is an artefact of Haskell > mostly being used in a command line program set up. I don?t think, it is > just by chance that the IHaskell people do some quite similar things to at > least some of what I?m doing. Once you want a more interactive experience, > call patterns get more complicated. > >> > >>>> I actually also might have a use for the architecture that you are > >>>> proposing. However, I really would like to keep the ability to, at > >>>> least, optionally run interpreted code in the same process (without > >>>> profiling etc). Do you think we could have both? > >>> > >>> We can certainly have both, it's straightforward to implement, but I > don't get to throw away some of the hacks we have to support same-process > execution, which would be a shame. We just add more code rather than > >> > >> Yes, I understand that and, as I wrote, I do like the idea of running > in a separate process. However, it would also be a shame to prevent richer > and more interactive experiences than CLI applications. > >> > >> I have thought a bit more about what the fundamental obstacle is. I > think, it is two things: > >> > >> (1) I have interpreted Haskell code that (via a compiled Haskell > library) uses FFI calls to call Cocoa system framework methods to create > Cocoa objects. In Haskell, these Cocoa objects are referenced via a > ForeignPtr and I need the interpreter to be able to return these foreign > pointers. The ForeignPtr?s need to refer to memory of the main host > process; hence, the FFI calls need to run the Cocoa framework code in the > host process. > >> > >> (2) The Cocoa objects from (1) include both StablePtrs as well as C > function pointers created via foreign dynamic wrapper. At least some of the > StablePtrs refer to Haskell heap structures that need to be accessed by > interpreted Haskell code. And calling the dynamic wrapper code from Swift > in the main process needs to execute Haskell code that may refer to > closures created by interpreted code. > >> > >> So, the issue really is that I would need FFI calls in the interpreter > process that call Cocoa code in the main process and dynamic wrapper entry > code in the main process that needs to call Haskell code in the interpreter > process. (Crossing the FFI language chasm corresponds to cross-process > calls.) > >> > >> I cannot move the Cocoa code from the main process to the interpreter > process, as Cocoa requires that it runs on the *main* thread of the main > process (to interact with the GUI and also to render via OpenGL). > >> > >> Does that make sense? > >> > >> Cheers, > >> Manuel > >> > >>>>> Simon Marlow : > >>>>> > >>>>> Hi folks - I've been thinking about changing the way we run > interpreted code so that it would be run in a separate process. It turns > out this has quite a few benefits, and would let us kill some of the really > awkward hacks we have in GHC to work around problems that arise because > we're running interpreted code and the compiler on the same runtime. > >>>>> > >>>>> I summarised the idea here: > https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi > >>>>> > >>>>> I'd be interested to hear if anyone has any thoughts around this, > particularly if doing this would make your life difficult in some way. Are > people relying on dynCompileExpr for anything? > >>>>> > >>>>> Cheers, > >>>>> Simon > >>>>> _______________________________________________ > >>>>> ghc-devs mailing list > >>>>> ghc-devs at haskell.org > >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >>>> > >> > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Nov 24 12:54:43 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 24 Nov 2015 12:54:43 +0000 Subject: Should (~) be homogeneous or heterogeneous? In-Reply-To: <535F0264-3D46-461E-96FF-DA6299E1D3D6@cis.upenn.edu> References: <535F0264-3D46-461E-96FF-DA6299E1D3D6@cis.upenn.edu> Message-ID: <93d830da2e484a56a119d32c162ef241@DB4PR30MB030.064d.mgd.msft.net> In your example, why do you get KP Any? Why don't you get class forall k1 k2 kproxy). (kproxy :: KProxy k1 ~ 'KP :: KProxy k2) => C kproxy where ... That may be over-polymorphic, but it'll work ok won't it? More generally, why does (2) lead to "trouble"? Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Richard Eisenberg | Sent: 22 November 2015 19:00 | To: ghc-devs Devs | Subject: Should (~) be homogeneous or heterogeneous? | | Hi devs, | | I'm desperately working toward getting kind equalities in before the | feature freeze. It's coming along nicely. But I have a user-facing | issue to work out. | | * Should (~), as written in user code, require the kinds of its | arguments to be equal? | | Another way of asking the same question is: Should the kind of (~) be | 1. forall k. k -> k -> Constraint (HEAD) | 2. forall k1 k2. k1 -> k2 -> Constraint (my branch, at the moment) | | Choice #2 is strictly more powerful and cannot be expressed in terms | of #1. But #1 is perhaps more intuitive for programmers, who might | expect inference to conclude that the two kinds are the same. | | Here is an example of where the difference matters: | | > data KProxy k = KP | > class kproxy ~ 'KP => C (kproxy :: KProxy k) | | We can see that the kind of the type variable kproxy should be (KProxy | k). But we still have to infer the kind of the occurrence of 'KP on | the left. HEAD sees the kind of kproxy and infers that 'KP should have | kind (KProxy k). My branch, on the other hand, doesn't have any reason | to constrain the kind of 'KP, and so it gets (KProxy Any), which | quickly causes trouble. | | The fix is easy: add a kind signature. | | I see two ways forward, corresponding to the choices for the kind of | (~) above: | | 1. Make (~) homogeneous and introduce a new constraint (~~) that is | like (~) but heterogeneous. We resign ourselves to explaining the | technical, subtle difference between (~) and (~~) into perpetuity. | | 2. Make (~) heterogeneous. Some people will have to add kind | annotations to their code to port from GHC 7.10 to GHC 8.0. But these | kind annotations will be fully backward-compatible, and won't require | CPP, or warnings, or any other bother. We may have to explain why kind | inference around (~) is weaker than it was before. | | | I'm (clearly?) leaning toward #2. But I'd like feedback. | | Thoughts? | | Thanks! | Richard | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h | askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c95ca36eba6074ac | feefb08d2f36f2700%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=0w0B9q7 | SJpXzf4UJokFZejYBhiIeASO0bfaJSDVRrJU%3d From marlowsd at gmail.com Tue Nov 24 14:07:18 2015 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 24 Nov 2015 14:07:18 +0000 Subject: Remote GHCi In-Reply-To: <55E48C32-9E95-4B32-AD34-989FA0FA7875@justtesting.org> References: <564AFD2F.6020305@gmail.com> <564C48B6.5070202@gmail.com> <1B324BD5-4154-42A3-B094-2FD06CB02925@justtesting.org> <56533E29.3040703@gmail.com> <55E48C32-9E95-4B32-AD34-989FA0FA7875@justtesting.org> Message-ID: <56546F16.5040009@gmail.com> It's even easier than that: if there's an API for sending messages and an API for executing messages, then the former just calls the latter directly in the single-process case. Cheers Simon On 24/11/2015 00:25, Manuel M T Chakravarty wrote: > Hi Simon, > > Sounds great! > > This may very well what you have got in mind anyway, but I could > imagine to run the interpreter on a different thread in the > -fno-external-interpreter case and arrange communication through the > same messaging API that you outlined for the seperate-process > interpreter. Then, the essential difference between the two modes > would be whether memory is shared or not (i.e., multithreading vs > multi-process). > > Cheers, > Manuel > >> Simon Marlow : >> >> Hi Manuel, >> >> Thanks for the detailed reply, I have a much better understanding of your requirements now. >> >> I'm going to support both models of running interpreted code. The current plan is to have a flag, -fexternal-interpreter, which GHC will use by default when running Template Haskell during compilation, and perhaps for GHCi, but for compatibility with applications like yours I'll probably leave it off for GHC API users. >> >> There's really no downside to doing this, it's not much more complicated than implementing the separate-process model. >> >> Cheers, >> Simon >> >> On 21/11/2015 03:38, Manuel M T Chakravarty wrote: >>>> Simon Marlow : >>>> On 18/11/2015 01:41, Manuel M T Chakravarty wrote: >>>>> Hi Simon, >>>>> >>>>> While this is an interesting proposal, Haskell for Mac strongly >>>>> relies on running interpreted code in the same process. I?m using >>>>> ?dynCompileExpr? as well as ?hscStmtWithLocation? and some other >>>>> stuff. >>>> >>>> Let me say first of all that I'm not going to remove anything, so there's no need to worry. But I'd like to explore exactly what you need, so that we can see whether there's a way to accommodate it with a separate-process implementation. >>>> >>>> hscStmtWithLocation is part of the core GHCi functionality, it is definitely supported. It has a slightly different signature: >>>> >>>> hscStmtWithLocation :: HscEnv >>>> -> String -- ^ The statement >>>> -> String -- ^ The source >>>> -> Int -- ^ Starting line >>>> -> IO ( Maybe ([Id] >>>> , RemoteHValue {- IO [HValue] -} >>>> , FixityEnv)) >>>> >>>> RemoteHValue is a reference to a value in the interpreter's context. These have to be evaluated via an explicit API, rather than just unsafeCoercing Value as we do now. (this is not strictly speaking part of the GHC API, so a separate but interesting question is: why did you need to use this directly, and what should we add to the GHC API?) >>> >>> The GHC API basically assumes that the ?result? of statement execution is the *side-effect* of printing the result to stdout. This is not sufficient for an interactive graphical environment as >>> >>> (1) I want to have the result (even if it is a string) separate from anything else interpreted code execution writes to stdout. (In Haskell for Mac, these things are displayed in different places.) >>> >>> (2) I want results that are not just strings. For example, a result (of running Haskell code) may be a ForeignPtr to a C-land data structure representing an image (e.g., an in-memory representation of a PNG image rendered by Diagrams). >>> >>> For the latter, I?m actually using `compileExpr`, then `unsafeCoerce` the `hValue` into `IO (ForeignPtr ())` and `try` that (to also catch any exceptions). When this code runs, in some cases, it calls back and forth between interpreted Haskell code and the host application using the FFI. >>> >>>> I believe that many uses of dynCompileExpr can be changed so that the code using the resulting value is moved into the interpreter?s context, and then there?s no problem. >>> >>> This is difficult in my case, because the resulting value is used in the GUI code written in Swift. Code running in a different process cannot call the Cocoa framework methods for the GUI of the main process. >>> >>>>> This is quite crucial for some of the interactive >>>>> functionality. Imagine a game where the game engine is in Swift >>>>> linked into the main application and the game logic is in >>>>> *interpreted* Haskell code. The engine calls into the Haskell code >>>>> multiple times per frame of the animation and for all >>>>> keyboard/mouse/etc input (using StablePtr and ForeignPtr to construct >>>>> the scene graph across the Swift and Haskell heap). >>>> >>>> So my question is, why wouldn't you run the whole game engine in the interpreter's context? That?s what would happen if you were to load the program into GHCi and run it. >>> >>> On a fundamental level: The game engine runs on OpenGL. If it is in a different process, it cannot access the OpenGL context of the main process (which it needs to do to render into a specific view of a specific window of the main process). >>> >>> In practice, it is not just an OpenGL problem as I?m using a framework called SpriteKit with its own event and rendering loop that in turn uses OpenGL for the actual rendering. It does a lot of things behind the scenes (which makes it convenient to use), which requires you to be careful which threads you use to execute some operations. Running in an entire different process is surely going to break things. >>> >>>> Directly calling back and forth between the client of the GHC API and the program being interpreted is arguably a strange thing to do, and it?s kind of accidental that we allow it. >>> >>> I understand that, but I also think that it is an artefact of Haskell mostly being used in a command line program set up. I don?t think, it is just by chance that the IHaskell people do some quite similar things to at least some of what I?m doing. Once you want a more interactive experience, call patterns get more complicated. >>> >>>>> I actually also might have a use for the architecture that you are >>>>> proposing. However, I really would like to keep the ability to, at >>>>> least, optionally run interpreted code in the same process (without >>>>> profiling etc). Do you think we could have both? >>>> >>>> We can certainly have both, it's straightforward to implement, but I don't get to throw away some of the hacks we have to support same-process execution, which would be a shame. We just add more code rather than >>> >>> Yes, I understand that and, as I wrote, I do like the idea of running in a separate process. However, it would also be a shame to prevent richer and more interactive experiences than CLI applications. >>> >>> I have thought a bit more about what the fundamental obstacle is. I think, it is two things: >>> >>> (1) I have interpreted Haskell code that (via a compiled Haskell library) uses FFI calls to call Cocoa system framework methods to create Cocoa objects. In Haskell, these Cocoa objects are referenced via a ForeignPtr and I need the interpreter to be able to return these foreign pointers. The ForeignPtr?s need to refer to memory of the main host process; hence, the FFI calls need to run the Cocoa framework code in the host process. >>> >>> (2) The Cocoa objects from (1) include both StablePtrs as well as C function pointers created via foreign dynamic wrapper. At least some of the StablePtrs refer to Haskell heap structures that need to be accessed by interpreted Haskell code. And calling the dynamic wrapper code from Swift in the main process needs to execute Haskell code that may refer to closures created by interpreted code. >>> >>> So, the issue really is that I would need FFI calls in the interpreter process that call Cocoa code in the main process and dynamic wrapper entry code in the main process that needs to call Haskell code in the interpreter process. (Crossing the FFI language chasm corresponds to cross-process calls.) >>> >>> I cannot move the Cocoa code from the main process to the interpreter process, as Cocoa requires that it runs on the *main* thread of the main process (to interact with the GUI and also to render via OpenGL). >>> >>> Does that make sense? >>> >>> Cheers, >>> Manuel >>> >>>>>> Simon Marlow : >>>>>> >>>>>> Hi folks - I've been thinking about changing the way we run interpreted code so that it would be run in a separate process. It turns out this has quite a few benefits, and would let us kill some of the really awkward hacks we have in GHC to work around problems that arise because we're running interpreted code and the compiler on the same runtime. >>>>>> >>>>>> I summarised the idea here: https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi >>>>>> >>>>>> I'd be interested to hear if anyone has any thoughts around this, particularly if doing this would make your life difficult in some way. Are people relying on dynCompileExpr for anything? >>>>>> >>>>>> Cheers, >>>>>> Simon >>>>>> _______________________________________________ >>>>>> ghc-devs mailing list >>>>>> ghc-devs at haskell.org >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>>> >>> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From simonpj at microsoft.com Tue Nov 24 14:07:50 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 24 Nov 2015 14:07:50 +0000 Subject: Monad fail errors Message-ID: <0c08dea067c8493fb0b66930687c4973@DB4PR30MB030.064d.mgd.msft.net> Herbert In tests/monadfail/MonadFailErrors.stderr I see MonadFailErrors.hs:59:5: error: No instance for (MonadFail Identity) arising from a do statement with the failable pattern ?Newtype x? In a stmt of a 'do' block: Newtype x <- undefined In the expression: do { Newtype x <- undefined; undefined } In an equation for ?newtypeMatch?: newtypeMatch = do { Newtype x <- undefined; undefined } MonadFailErrors.hs:67:5: error: No instance for (MonadFail Identity) arising from a do statement with the failable pattern ?Data x? In a stmt of a 'do' block: Data x <- undefined In the expression: do { Data x <- undefined; undefined } In an equation for ?singleConMatch?: singleConMatch = do { Data x <- undefined; undefined } But ?Newtype? and ?Data? are single constructor types and hence cannot fail. So why are these errors happening? I?m tiding up your implementation (deleting code!) and accidentally fixed this. So I wanted to check that it is indeed wrong as-is. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Tue Nov 24 21:32:58 2015 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 24 Nov 2015 21:32:58 +0000 Subject: Remote GHCi In-Reply-To: References: <564AFD2F.6020305@gmail.com> <564C48B6.5070202@gmail.com> <1B324BD5-4154-42A3-B094-2FD06CB02925@justtesting.org> <56533E29.3040703@gmail.com> <55E48C32-9E95-4B32-AD34-989FA0FA7875@justtesting.org> Message-ID: <5654D78A.7020500@gmail.com> I want to get it done within the next few weeks. Currently GHCi is mostly working, and the main missing pieces are TH and the debugger. I plan to backport it to the 7.10 branch so that I can have it in our local GHC builds at Facebook. My WIP branch is here: https://github.com/simonmar/ghc/commits/prof-ghci Cheers Simon On 24/11/2015 11:04, Alan & Kim Zimmerman wrote: > What kind of timescale can we expect on this, and will it be possible to > backport it (via a ghci-ng or similar)? > > We are currently wrestling with ghci stdio issues in haskell-ide-engine. > If this will be out soon we can wait for it. > > Alan > > On Tue, Nov 24, 2015 at 2:25 AM, Manuel M T Chakravarty > > wrote: > > Hi Simon, > > Sounds great! > > This may very well what you have got in mind anyway, but I could > imagine to run the interpreter on a different thread in the > -fno-external-interpreter case and arrange communication through the > same messaging API that you outlined for the seperate-process > interpreter. Then, the essential difference between the two modes > would be whether memory is shared or not (i.e., multithreading vs > multi-process). > > Cheers, > Manuel > > > Simon Marlow >: > > > > Hi Manuel, > > > > Thanks for the detailed reply, I have a much better understanding > of your requirements now. > > > > I'm going to support both models of running interpreted code. > The current plan is to have a flag, -fexternal-interpreter, which > GHC will use by default when running Template Haskell during > compilation, and perhaps for GHCi, but for compatibility with > applications like yours I'll probably leave it off for GHC API users. > > > > There's really no downside to doing this, it's not much more > complicated than implementing the separate-process model. > > > > Cheers, > > Simon > > > > On 21/11/2015 03:38, Manuel M T Chakravarty wrote: > >>> Simon Marlow >: > >>> On 18/11/2015 01:41, Manuel M T Chakravarty wrote: > >>>> Hi Simon, > >>>> > >>>> While this is an interesting proposal, Haskell for Mac strongly > >>>> relies on running interpreted code in the same process. I?m using > >>>> ?dynCompileExpr? as well as ?hscStmtWithLocation? and some other > >>>> stuff. > >>> > >>> Let me say first of all that I'm not going to remove anything, > so there's no need to worry. But I'd like to explore exactly what > you need, so that we can see whether there's a way to accommodate it > with a separate-process implementation. > >>> > >>> hscStmtWithLocation is part of the core GHCi functionality, it > is definitely supported. It has a slightly different signature: > >>> > >>> hscStmtWithLocation :: HscEnv > >>> -> String -- ^ The statement > >>> -> String -- ^ The source > >>> -> Int -- ^ Starting line > >>> -> IO ( Maybe ([Id] > >>> , RemoteHValue {- IO [HValue] -} > >>> , FixityEnv)) > >>> > >>> RemoteHValue is a reference to a value in the interpreter's > context. These have to be evaluated via an explicit API, rather than > just unsafeCoercing Value as we do now. (this is not strictly > speaking part of the GHC API, so a separate but interesting question > is: why did you need to use this directly, and what should we add to > the GHC API?) > >> > >> The GHC API basically assumes that the ?result? of statement > execution is the *side-effect* of printing the result to stdout. > This is not sufficient for an interactive graphical environment as > >> > >> (1) I want to have the result (even if it is a string) separate > from anything else interpreted code execution writes to stdout. (In > Haskell for Mac, these things are displayed in different places.) > >> > >> (2) I want results that are not just strings. For example, a > result (of running Haskell code) may be a ForeignPtr to a C-land > data structure representing an image (e.g., an in-memory > representation of a PNG image rendered by Diagrams). > >> > >> For the latter, I?m actually using `compileExpr`, then > `unsafeCoerce` the `hValue` into `IO (ForeignPtr ())` and `try` that > (to also catch any exceptions). When this code runs, in some cases, > it calls back and forth between interpreted Haskell code and the > host application using the FFI. > >> > >>> I believe that many uses of dynCompileExpr can be changed so > that the code using the resulting value is moved into the > interpreter?s context, and then there?s no problem. > >> > >> This is difficult in my case, because the resulting value is > used in the GUI code written in Swift. Code running in a different > process cannot call the Cocoa framework methods for the GUI of the > main process. > >> > >>>> This is quite crucial for some of the interactive > >>>> functionality. Imagine a game where the game engine is in Swift > >>>> linked into the main application and the game logic is in > >>>> *interpreted* Haskell code. The engine calls into the Haskell code > >>>> multiple times per frame of the animation and for all > >>>> keyboard/mouse/etc input (using StablePtr and ForeignPtr to > construct > >>>> the scene graph across the Swift and Haskell heap). > >>> > >>> So my question is, why wouldn't you run the whole game engine > in the interpreter's context? That?s what would happen if you were > to load the program into GHCi and run it. > >> > >> On a fundamental level: The game engine runs on OpenGL. If it is > in a different process, it cannot access the OpenGL context of the > main process (which it needs to do to render into a specific view of > a specific window of the main process). > >> > >> In practice, it is not just an OpenGL problem as I?m using a > framework called SpriteKit with its own event and rendering loop > that in turn uses OpenGL for the actual rendering. It does a lot of > things behind the scenes (which makes it convenient to use), which > requires you to be careful which threads you use to execute some > operations. Running in an entire different process is surely going > to break things. > >> > >>> Directly calling back and forth between the client of the GHC > API and the program being interpreted is arguably a strange thing to > do, and it?s kind of accidental that we allow it. > >> > >> I understand that, but I also think that it is an artefact of > Haskell mostly being used in a command line program set up. I don?t > think, it is just by chance that the IHaskell people do some quite > similar things to at least some of what I?m doing. Once you want a > more interactive experience, call patterns get more complicated. > >> > >>>> I actually also might have a use for the architecture that you are > >>>> proposing. However, I really would like to keep the ability to, at > >>>> least, optionally run interpreted code in the same process > (without > >>>> profiling etc). Do you think we could have both? > >>> > >>> We can certainly have both, it's straightforward to implement, > but I don't get to throw away some of the hacks we have to support > same-process execution, which would be a shame. We just add more > code rather than > >> > >> Yes, I understand that and, as I wrote, I do like the idea of > running in a separate process. However, it would also be a shame to > prevent richer and more interactive experiences than CLI applications. > >> > >> I have thought a bit more about what the fundamental obstacle > is. I think, it is two things: > >> > >> (1) I have interpreted Haskell code that (via a compiled Haskell > library) uses FFI calls to call Cocoa system framework methods to > create Cocoa objects. In Haskell, these Cocoa objects are referenced > via a ForeignPtr and I need the interpreter to be able to return > these foreign pointers. The ForeignPtr?s need to refer to memory of > the main host process; hence, the FFI calls need to run the Cocoa > framework code in the host process. > >> > >> (2) The Cocoa objects from (1) include both StablePtrs as well > as C function pointers created via foreign dynamic wrapper. At least > some of the StablePtrs refer to Haskell heap structures that need to > be accessed by interpreted Haskell code. And calling the dynamic > wrapper code from Swift in the main process needs to execute Haskell > code that may refer to closures created by interpreted code. > >> > >> So, the issue really is that I would need FFI calls in the > interpreter process that call Cocoa code in the main process and > dynamic wrapper entry code in the main process that needs to call > Haskell code in the interpreter process. (Crossing the FFI language > chasm corresponds to cross-process calls.) > >> > >> I cannot move the Cocoa code from the main process to the > interpreter process, as Cocoa requires that it runs on the *main* > thread of the main process (to interact with the GUI and also to > render via OpenGL). > >> > >> Does that make sense? > >> > >> Cheers, > >> Manuel > >> > >>>>> Simon Marlow >: > >>>>> > >>>>> Hi folks - I've been thinking about changing the way we run > interpreted code so that it would be run in a separate process. It > turns out this has quite a few benefits, and would let us kill some > of the really awkward hacks we have in GHC to work around problems > that arise because we're running interpreted code and the compiler > on the same runtime. > >>>>> > >>>>> I summarised the idea here: > https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi > >>>>> > >>>>> I'd be interested to hear if anyone has any thoughts around > this, particularly if doing this would make your life difficult in > some way. Are people relying on dynCompileExpr for anything? > >>>>> > >>>>> Cheers, > >>>>> Simon > >>>>> _______________________________________________ > >>>>> ghc-devs mailing list > >>>>> ghc-devs at haskell.org > >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >>>> > >> > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > From erkokl at gmail.com Wed Nov 25 01:58:45 2015 From: erkokl at gmail.com (Levent Erkok) Date: Tue, 24 Nov 2015 17:58:45 -0800 Subject: Plugins: How to determine ghc vs ghci In-Reply-To: <4B57134C-623E-47C2-BD21-7615EC9E8149@gmail.com> References: <4B57134C-623E-47C2-BD21-7615EC9E8149@gmail.com> Message-ID: Thanks! That indeed does work. I'm a bit surprised though that there isn't already an internal boolean set somewhere; checking for a string in the arguments sounds a bit fragile. On Tue, Nov 24, 2015 at 12:28 AM, Aycan ?rican wrote: > How about `GHC.Environment.getFullArgs` which includes ??interactive? when > you?re in GHCi? > > > > On 24 Nov 2015, at 09:37, Levent Erkok wrote: > > > > I'm working on a plugin, and would like to be able to tell if it's GHC > or GHCi that's running. > > > > I tried: > > > > df <- getDynFlags > > let isGHCi = ghcMode df == CompManager > > > > Alas, while that correctly tells apart "ghci" from "ghc -c", it also > returns True when ghc is called without the "-c" argument. > > > > Is there a better/more robust way of figuring out whether we're in an > interactive session? > > > > -Levent. > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgsloan at gmail.com Wed Nov 25 02:25:58 2015 From: mgsloan at gmail.com (Michael Sloan) Date: Tue, 24 Nov 2015 18:25:58 -0800 Subject: Plugins: How to determine ghc vs ghci In-Reply-To: References: <4B57134C-623E-47C2-BD21-7615EC9E8149@gmail.com> Message-ID: The executable-path package wraps this up nicely with its `getScriptPath` function: https://hackage.haskell.org/package/executable-path-0.0.3/docs/System-Environment-Executable.html#v:getScriptPath Probably best to use this existing function. Then, if a less fragile solution comes along, getScriptPath can do that instead. -Michael On Tue, Nov 24, 2015 at 5:58 PM, Levent Erkok wrote: > Thanks! That indeed does work. > > I'm a bit surprised though that there isn't already an internal boolean > set somewhere; checking for a string in the arguments sounds a bit fragile. > > On Tue, Nov 24, 2015 at 12:28 AM, Aycan ?rican > wrote: > >> How about `GHC.Environment.getFullArgs` which includes ??interactive? >> when you?re in GHCi? >> >> >> > On 24 Nov 2015, at 09:37, Levent Erkok wrote: >> > >> > I'm working on a plugin, and would like to be able to tell if it's GHC >> or GHCi that's running. >> > >> > I tried: >> > >> > df <- getDynFlags >> > let isGHCi = ghcMode df == CompManager >> > >> > Alas, while that correctly tells apart "ghci" from "ghc -c", it also >> returns True when ghc is called without the "-c" argument. >> > >> > Is there a better/more robust way of figuring out whether we're in an >> interactive session? >> > >> > -Levent. >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From qdunkan at gmail.com Wed Nov 25 03:14:41 2015 From: qdunkan at gmail.com (Evan Laforge) Date: Tue, 24 Nov 2015 19:14:41 -0800 Subject: ok to do reformatting commits? Message-ID: When I was doing a recent patch, I was annoyed by lint errors about >80 lines when I was just conforming to the existing style. To avoid cluttering my commit with unrelated changes, I decided to fix the lints in a formatting-only commit afterwards. Looking in the archives, I see there was some recent discussion about this, but I didn't see anyone volunteering to just go wrap a bunch of files, or saying that they didn't want anyone to do this (usual reason being cluttering the history, which as a rationale to not do formatting only changes never sat too well with me). Would anyone mind if I went and wrapped a bunch of files, say typecheck/*.hs? This seems simpler than either constant hassling from arc or coming up with more elaborate rules for arc. I would have to make some formatting decisions, so likely to some eyes I would be messing some stuff up, but since there's no real standard that is probably unavoidable. From eir at cis.upenn.edu Wed Nov 25 03:23:05 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 24 Nov 2015 22:23:05 -0500 Subject: ok to do reformatting commits? In-Reply-To: References: Message-ID: <1A19BAA2-04D8-4854-A64A-21C046804E89@cis.upenn.edu> Thanks for volunteering to do this work, but I'm afraid now is a terrible time to do it. I know of three significant patches that are about to be committed, and your reformatting would cause quite a few merge conflicts. If there is a lull between a feature freeze and a ghc-8.0 fork, that would be the ideal time, to my mind. That said, I remain unconvinced that a rigid commitment to 80-char lines is in our best interest. My personal vote is to continue to have 80 characters as a guideline but to keep the current practice of allowing programmer discretion. Richard On Nov 24, 2015, at 10:14 PM, Evan Laforge wrote: > When I was doing a recent patch, I was annoyed by lint errors about >> 80 lines when I was just conforming to the existing style. To avoid > cluttering my commit with unrelated changes, I decided to fix the > lints in a formatting-only commit afterwards. Looking in the > archives, I see there was some recent discussion about this, but I > didn't see anyone volunteering to just go wrap a bunch of files, or > saying that they didn't want anyone to do this (usual reason being > cluttering the history, which as a rationale to not do formatting only > changes never sat too well with me). > > Would anyone mind if I went and wrapped a bunch of files, say > typecheck/*.hs? This seems simpler than either constant hassling from > arc or coming up with more elaborate rules for arc. I would have to > make some formatting decisions, so likely to some eyes I would be > messing some stuff up, but since there's no real standard that is > probably unavoidable. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From qdunkan at gmail.com Wed Nov 25 03:37:42 2015 From: qdunkan at gmail.com (Evan Laforge) Date: Tue, 24 Nov 2015 19:37:42 -0800 Subject: ok to do reformatting commits? In-Reply-To: <1A19BAA2-04D8-4854-A64A-21C046804E89@cis.upenn.edu> References: <1A19BAA2-04D8-4854-A64A-21C046804E89@cis.upenn.edu> Message-ID: On Tue, Nov 24, 2015 at 7:23 PM, Richard Eisenberg wrote: > Thanks for volunteering to do this work, but I'm afraid now is a terrible time to do it. I know of three significant patches that are about to be committed, and your reformatting would cause quite a few merge conflicts. If there is a lull between a feature freeze and a ghc-8.0 fork, that would be the ideal time, to my mind. Ok, I'll shelve the idea until further notice. > That said, I remain unconvinced that a rigid commitment to 80-char lines is in our best interest. My personal vote is to continue to have 80 characters as a guideline but to keep the current practice of allowing programmer discretion. In my case it's not so much discretion, but that in the absence of clear guidance, I default to conservatively trying to do whatever the file already does. So there's a bit of contradiction where the local convention says to do one thing but lint says another, and without a tie-breaker I'd go with local convention. In which case best to turn off the lint, and put a guideline in the doc. Also I had no idea about the under_scores means private thing, I just picked what seemed to be prevalent in the surroundings. That would be another good thing to put into https://ghc.haskell.org/trac/ghc/wiki/Commentary/CodingStyle From matthewtpickering at gmail.com Wed Nov 25 12:11:41 2015 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Wed, 25 Nov 2015 12:11:41 +0000 Subject: Remove deprecated quasiquote syntax Message-ID: The [$qq| quasiquote syntax has been deprecated since around 2010. Is there any objection to removing the backwards compatibility now? I counted 216 uses of it on hackage in a handful of packages, some in comments. http://lpaste.net/145938 Here is the commit which deprecated it - https://github.com/ghc/ghc/commit/9ba922ee06b048774d7a82964867ff768a78126e Matt From michael at snoyman.com Wed Nov 25 12:19:05 2015 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 25 Nov 2015 14:19:05 +0200 Subject: Remove deprecated quasiquote syntax In-Reply-To: References: Message-ID: I think I'm the one who requested that the backwards compatibility be added back in. I have no objection to removing it at this point. On Wed, Nov 25, 2015 at 2:11 PM, Matthew Pickering < matthewtpickering at gmail.com> wrote: > The [$qq| quasiquote syntax has been deprecated since around 2010. > > Is there any objection to removing the backwards compatibility now? > > I counted 216 uses of it on hackage in a handful of packages, some in > comments. > > http://lpaste.net/145938 > > Here is the commit which deprecated it - > https://github.com/ghc/ghc/commit/9ba922ee06b048774d7a82964867ff768a78126e > > Matt > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Nov 25 12:36:03 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 25 Nov 2015 12:36:03 +0000 Subject: Remove deprecated quasiquote syntax In-Reply-To: References: Message-ID: <6db50339030b4caaa1b0e00ca0675163@DB4PR30MB030.064d.mgd.msft.net> I'm all for it, if the broader community (e.g. the developers of those packages) are ok. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Matthew Pickering | Sent: 25 November 2015 12:12 | To: GHC developers | Subject: Remove deprecated quasiquote syntax | | The [$qq| quasiquote syntax has been deprecated since around 2010. | | Is there any objection to removing the backwards compatibility now? | | I counted 216 uses of it on hackage in a handful of packages, some in | comments. | | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flpaste | .net%2f145938&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c82c772 | ac7dc64bbe2b1208d2f59196d4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdat | a=haPJyAOBSnUnXkyHn%2b%2bcqXRMj97pC1SwkXKr5liC00E%3d | | Here is the commit which deprecated it - | https://github.com/ghc/ghc/commit/9ba922ee06b048774d7a82964867ff768a78 | 126e | | Matt | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h | askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c82c772ac7dc64bb | e2b1208d2f59196d4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=EcfMMN4 | prdTj%2bBzm2%2bpMpQlmMIuXe3yefy1TFdYMV9I%3d From simonpj at microsoft.com Wed Nov 25 13:03:59 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 25 Nov 2015 13:03:59 +0000 Subject: ok to do reformatting commits? In-Reply-To: <1A19BAA2-04D8-4854-A64A-21C046804E89@cis.upenn.edu> References: <1A19BAA2-04D8-4854-A64A-21C046804E89@cis.upenn.edu> Message-ID: <9311f5ba1a714d5c8309ec2a88861c85@DB4PR30MB030.064d.mgd.msft.net> I don?t have a strong view but like Richard I find 80 chars limiting. I agree that we should resolve this and write down the result on the coding style page Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Richard Eisenberg | Sent: 25 November 2015 03:23 | To: Evan Laforge | Cc: ghc-devs at haskell.org | Subject: Re: ok to do reformatting commits? | | Thanks for volunteering to do this work, but I'm afraid now is a | terrible time to do it. I know of three significant patches that are | about to be committed, and your reformatting would cause quite a few | merge conflicts. If there is a lull between a feature freeze and a | ghc-8.0 fork, that would be the ideal time, to my mind. | | That said, I remain unconvinced that a rigid commitment to 80-char | lines is in our best interest. My personal vote is to continue to have | 80 characters as a guideline but to keep the current practice of | allowing programmer discretion. | | Richard | | On Nov 24, 2015, at 10:14 PM, Evan Laforge wrote: | | > When I was doing a recent patch, I was annoyed by lint errors about | >> 80 lines when I was just conforming to the existing style. To | avoid | > cluttering my commit with unrelated changes, I decided to fix the | > lints in a formatting-only commit afterwards. Looking in the | > archives, I see there was some recent discussion about this, but I | > didn't see anyone volunteering to just go wrap a bunch of files, or | > saying that they didn't want anyone to do this (usual reason being | > cluttering the history, which as a rationale to not do formatting | only | > changes never sat too well with me). | > | > Would anyone mind if I went and wrapped a bunch of files, say | > typecheck/*.hs? This seems simpler than either constant hassling | from | > arc or coming up with more elaborate rules for arc. I would have to | > make some formatting decisions, so likely to some eyes I would be | > messing some stuff up, but since there's no real standard that is | > probably unavoidable. | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h | > askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csi | > | monpj%40064d.mgd.microsoft.com%7c27ba726d65bd49df735d08d2f547c211%7c72 | > | f988bf86f141af91ab2d7cd011db47%7c1&sdata=iGQx%2bYYoG%2bv7xCd6Su%2bzN1L | > gIjx5FxEqmWOSpIbLnjY%3d | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h | askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c27ba726d65bd49d | f735d08d2f547c211%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=iGQx%2b | YYoG%2bv7xCd6Su%2bzN1LgIjx5FxEqmWOSpIbLnjY%3d From alan.zimm at gmail.com Wed Nov 25 13:23:48 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Wed, 25 Nov 2015 15:23:48 +0200 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <061.16ee1c8fc76877b64cf016d03fb13b39@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> <061.16ee1c8fc76877b64cf016d03fb13b39@haskell.org> Message-ID: I just pushed to wip/T11028 It is very much a work in progress, working through to sort out the compiler errors, in the simplest way at the moment. On Wed, Nov 25, 2015 at 3:06 PM, GHC wrote: > #11028: Refactor ConDecl > -------------------------------------+------------------------------------- > Reporter: simonpj | Owner: alanz > Type: bug | Status: new > Priority: normal | Milestone: > Component: Compiler | Version: 7.10.2 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: > | Unknown/Multiple > Type of failure: None/Unknown | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > -------------------------------------+------------------------------------- > > Comment (by simonpj): > > Yes, because of the possibility of `HsRecTy`, you can't use `tcHsSigType`. > So something like what you propose looks good. > > Ca you make a branch and push what you have so that I can see? > > -- > Ticket URL: > GHC > The Glasgow Haskell Compiler > -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Wed Nov 25 13:47:20 2015 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Wed, 25 Nov 2015 08:47:20 -0500 Subject: ok to do reformatting commits? In-Reply-To: References: Message-ID: 2015-11-24 22:14 GMT-05:00 Evan Laforge : > Would anyone mind if I went and wrapped a bunch of files, say > typecheck/*.hs? This seems simpler than either constant hassling from > arc or coming up with more elaborate rules for arc. I would have to > make some formatting decisions, so likely to some eyes I would be > messing some stuff up, but since there's no real standard that is > probably unavoidable. Please don't -- like Richard I have patches in many different branches(although they rarely touch typecheck/) and this will cause so much trouble to us. If Arc linter is causing so much trouble(IMHO it isn't) maybe the solution is to make Arc linter less strict. From chak at justtesting.org Wed Nov 25 22:04:11 2015 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Thu, 26 Nov 2015 09:04:11 +1100 Subject: ok to do reformatting commits? In-Reply-To: <9311f5ba1a714d5c8309ec2a88861c85@DB4PR30MB030.064d.mgd.msft.net> References: <1A19BAA2-04D8-4854-A64A-21C046804E89@cis.upenn.edu> <9311f5ba1a714d5c8309ec2a88861c85@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <1CE544C8-A585-43FD-BC74-B830A87C8AC9@justtesting.org> I used to be a 80 chars kind of guy, but working with Simon on the type checker, I did get into the habit of using 120. It has stuck with me. Especially in Haskell, there is a lot of value in that additional space, especially if you like to have descriptive identifiers. (In statement-oriented languages, 80 chars are far less limiting.) Manuel > Simon Peyton Jones : > > I don?t have a strong view but like Richard I find 80 chars limiting. > > I agree that we should resolve this and write down the result on the coding style page > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > | Richard Eisenberg > | Sent: 25 November 2015 03:23 > | To: Evan Laforge > | Cc: ghc-devs at haskell.org > | Subject: Re: ok to do reformatting commits? > | > | Thanks for volunteering to do this work, but I'm afraid now is a > | terrible time to do it. I know of three significant patches that are > | about to be committed, and your reformatting would cause quite a few > | merge conflicts. If there is a lull between a feature freeze and a > | ghc-8.0 fork, that would be the ideal time, to my mind. > | > | That said, I remain unconvinced that a rigid commitment to 80-char > | lines is in our best interest. My personal vote is to continue to have > | 80 characters as a guideline but to keep the current practice of > | allowing programmer discretion. > | > | Richard > | > | On Nov 24, 2015, at 10:14 PM, Evan Laforge wrote: > | > | > When I was doing a recent patch, I was annoyed by lint errors about > | >> 80 lines when I was just conforming to the existing style. To > | avoid > | > cluttering my commit with unrelated changes, I decided to fix the > | > lints in a formatting-only commit afterwards. Looking in the > | > archives, I see there was some recent discussion about this, but I > | > didn't see anyone volunteering to just go wrap a bunch of files, or > | > saying that they didn't want anyone to do this (usual reason being > | > cluttering the history, which as a rationale to not do formatting > | only > | > changes never sat too well with me). > | > > | > Would anyone mind if I went and wrapped a bunch of files, say > | > typecheck/*.hs? This seems simpler than either constant hassling > | from > | > arc or coming up with more elaborate rules for arc. I would have to > | > make some formatting decisions, so likely to some eyes I would be > | > messing some stuff up, but since there's no real standard that is > | > probably unavoidable. > | > _______________________________________________ > | > ghc-devs mailing list > | > ghc-devs at haskell.org > | > > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h > | > askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- > | devs&data=01%7c01%7csi > | > > | monpj%40064d.mgd.microsoft.com%7c27ba726d65bd49df735d08d2f547c211%7c72 > | > > | f988bf86f141af91ab2d7cd011db47%7c1&sdata=iGQx%2bYYoG%2bv7xCd6Su%2bzN1L > | > gIjx5FxEqmWOSpIbLnjY%3d > | > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h > | askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- > | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c27ba726d65bd49d > | f735d08d2f547c211%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=iGQx%2b > | YYoG%2bv7xCd6Su%2bzN1LgIjx5FxEqmWOSpIbLnjY%3d > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From alan.zimm at gmail.com Wed Nov 25 22:26:21 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Thu, 26 Nov 2015 00:26:21 +0200 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <061.a1d23c30ac777cc38efb5045eb9abaaf@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> <061.a1d23c30ac777cc38efb5045eb9abaaf@haskell.org> Message-ID: As I wrote that I came to the same conclusion, but decided to leave the rest in case. On Thu, Nov 26, 2015 at 12:25 AM, GHC wrote: > #11028: Refactor ConDecl > -------------------------------------+------------------------------------- > Reporter: simonpj | Owner: alanz > Type: bug | Status: new > Priority: normal | Milestone: > Component: Compiler | Version: 7.10.2 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: > | Unknown/Multiple > Type of failure: None/Unknown | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > -------------------------------------+------------------------------------- > > Comment (by simonpj): > > > Alternatively, everything except the `rnLHsType` in `rnConResult` can > move to the type checking. > > That sounds exactly right. `Note [Sorting out the result type]` in > `RdrHsSyn` seems entirely redundant with the new `ConDeclGADT` form. > > -- > Ticket URL: > GHC > The Glasgow Haskell Compiler > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Nov 26 15:58:27 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 26 Nov 2015 15:58:27 +0000 Subject: D1428: Rework treatment of wildcards In-Reply-To: <20151126143944.31415.61795@phabricator.haskell.org> References: <20151126143944.31415.61795@phabricator.haskell.org> Message-ID: <6965dd5ca899479b86fa83b494da10d4@DB4PR30MB030.064d.mgd.msft.net> Ben So that you know, the state of play is: * wip/spj-wildcard-refactor is fully up to speed with HEAD * It validates except for perf/compiler/T3064 (8% loss) * It does need a decent commit message I'd really like this in 8.0: - It's a big patch, so not having it will lead to lots of tiresome cross-branch porting - It does fix things in the wildcard story Of these the former is the more important. The only think holding me up is that I really don't understand the perf regression. It seems to be in the simplifier, which I have not touched! Working on it. But in the worst case I can commit and open a ticket for the perf regression Simon | -----Original Message----- | From: noreply at phabricator.haskell.org | [mailto:noreply at phabricator.haskell.org] | Sent: 26 November 2015 14:40 | To: Simon Peyton Jones | Subject: [Differential] [Requested Changes To] D1428: Rework treatment | of wildcards | | bgamari requested changes to this revision. | bgamari added a comment. | This revision now requires changes to proceed. | | Requesting changes to bump this out of the review queue. | | | REPOSITORY | rGHC Glasgow Haskell Compiler | | REVISION DETAIL | https://phabricator.haskell.org/D1428 | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: austin, hvr, goldfire, simonpj, bgamari | Cc: jstolarek, alanz, goldfire, thomie, mpickering, simonpj From ben at well-typed.com Thu Nov 26 17:11:55 2015 From: ben at well-typed.com (Ben Gamari) Date: Thu, 26 Nov 2015 18:11:55 +0100 Subject: D1428: Rework treatment of wildcards In-Reply-To: <6965dd5ca899479b86fa83b494da10d4@DB4PR30MB030.064d.mgd.msft.net> References: <20151126143944.31415.61795@phabricator.haskell.org> <6965dd5ca899479b86fa83b494da10d4@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <87k2p48z38.fsf@smart-cactus.org> Simon Peyton Jones writes: > Ben > > So that you know, the state of play is: > > * wip/spj-wildcard-refactor is fully up to speed with HEAD > * It validates except for perf/compiler/T3064 (8% loss) > * It does need a decent commit message > > I'd really like this in 8.0: > - It's a big patch, so not having it will lead to lots of > tiresome cross-branch porting > - It does fix things in the wildcard story > Of these the former is the more important. > > The only think holding me up is that I really don't understand the > perf regression. It seems to be in the simplifier, which I have not > touched! Working on it. But in the worst case I can commit and open a > ticket for the perf regression > Thanks for the update! Don't worry, there's still time as we're still waiting for D808 which will likely be at least a few more days. Let me know if I can be of assistance. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From mail at joachim-breitner.de Fri Nov 27 13:21:49 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 27 Nov 2015 14:21:49 +0100 Subject: Reproducible builds using GHC Message-ID: <1448630509.29734.8.camel@joachim-breitner.de> Hi Bartosz, you might be aware of the reproducible builds project (https://reproducible-builds.org/) which tries to make as much software as possible to build reproducibly, i.e. bitwise identical output files. I have done a few minor things in that direction myself and therefore got invited to the ?Reproducibly World Summit? next week in Athens. But by now, you have worked much harder on the problem than I ever have, and so you have a much better overview of the remaining issues.? Would you mind posting an update on your work on #4012, about what remains to be done, whether you think that the remaining problems are solved (and just need doing) or whether there are issues without a known solution so far? I know that your focus right now is reproducible interface files, but can you say something about how far away reproducible binary files are, once the interface files are reproducible? Are the causes of non- determinism in principle the same in either case, or are there unique problems when it comes to object files? Are there areas of work where you could need some extra help? Thanks for your input, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Fri Nov 27 15:31:39 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 27 Nov 2015 15:31:39 +0000 Subject: Bad interface file Message-ID: Can anyone confirm that Trac #11122 is fixed in HEAD? When I try to reproduce it, I tried this, with a freshly-built HEAD cabal install parsec --with-ghc=/home/simonpj/5builds/HEAD-5/inplace/bin/ghc-stage2 But that fails as below, with a bizarre ?bad interface file? error. Does anyone have a clue about what?s happening? Does it work for you? Simon cabal install parsec --with-ghc=/home/simonpj/5builds/HEAD-5/inplace/bin/ghc-stage2 Resolving dependencies... Configuring mtl-2.2.1... Building mtl-2.2.1... Preprocessing library mtl-2.2.1... [ 1 of 22] Compiling Control.Monad.Writer.Class ( Control/Monad/Writer/Class.hs, dist/build/Control/Monad/Writer/Class.o ) [ 2 of 22] Compiling Control.Monad.State.Class ( Control/Monad/State/Class.hs, dist/build/Control/Monad/State/Class.o ) [ 3 of 22] Compiling Control.Monad.Reader.Class ( Control/Monad/Reader/Class.hs, dist/build/Control/Monad/Reader/Class.o ) [ 4 of 22] Compiling Control.Monad.RWS.Class ( Control/Monad/RWS/Class.hs, dist/build/Control/Monad/RWS/Class.o ) [ 5 of 22] Compiling Control.Monad.Identity ( Control/Monad/Identity.hs, dist/build/Control/Monad/Identity.o ) [ 6 of 22] Compiling Control.Monad.Error.Class ( Control/Monad/Error/Class.hs, dist/build/Control/Monad/Error/Class.o ) [ 7 of 22] Compiling Control.Monad.Cont.Class ( Control/Monad/Cont/Class.hs, dist/build/Control/Monad/Cont/Class.o ) [ 8 of 22] Compiling Control.Monad.Trans ( Control/Monad/Trans.hs, dist/build/Control/Monad/Trans.o ) [ 9 of 22] Compiling Control.Monad.Error ( Control/Monad/Error.hs, dist/build/Control/Monad/Error.o ) [10 of 22] Compiling Control.Monad.Except ( Control/Monad/Except.hs, dist/build/Control/Monad/Except.o ) [11 of 22] Compiling Control.Monad.List ( Control/Monad/List.hs, dist/build/Control/Monad/List.o ) [12 of 22] Compiling Control.Monad.RWS.Lazy ( Control/Monad/RWS/Lazy.hs, dist/build/Control/Monad/RWS/Lazy.o ) [13 of 22] Compiling Control.Monad.RWS ( Control/Monad/RWS.hs, dist/build/Control/Monad/RWS.o ) [14 of 22] Compiling Control.Monad.Reader ( Control/Monad/Reader.hs, dist/build/Control/Monad/Reader.o ) [15 of 22] Compiling Control.Monad.RWS.Strict ( Control/Monad/RWS/Strict.hs, dist/build/Control/Monad/RWS/Strict.o ) [16 of 22] Compiling Control.Monad.State.Lazy ( Control/Monad/State/Lazy.hs, dist/build/Control/Monad/State/Lazy.o ) [17 of 22] Compiling Control.Monad.State ( Control/Monad/State.hs, dist/build/Control/Monad/State.o ) [18 of 22] Compiling Control.Monad.State.Strict ( Control/Monad/State/Strict.hs, dist/build/Control/Monad/State/Strict.o ) [19 of 22] Compiling Control.Monad.Writer.Lazy ( Control/Monad/Writer/Lazy.hs, dist/build/Control/Monad/Writer/Lazy.o ) [20 of 22] Compiling Control.Monad.Writer ( Control/Monad/Writer.hs, dist/build/Control/Monad/Writer.o ) [21 of 22] Compiling Control.Monad.Writer.Strict ( Control/Monad/Writer/Strict.hs, dist/build/Control/Monad/Writer/Strict.o ) [22 of 22] Compiling Control.Monad.Cont ( Control/Monad/Cont.hs, dist/build/Control/Monad/Cont.o ) In-place registering mtl-2.2.1... Creating package registration file: /tmp/pkgConf-mtl-2.253500.1 Installing library in /home/simonpj/.cabal/lib/x86_64-linux-ghc-7.11.20151125/mtl_29yPYQfz4VvKtYIFBb0Wdp Registering mtl-2.2.1... Installed mtl-2.2.1 Downloading text-1.2.1.3... Failed to install text-1.2.1.3 cabal: Error: some packages failed to install: parsec-3.1.9 depends on text-1.2.1.3 which failed to install. text-1.2.1.3 failed while downloading the package. The exception was: : hGetBufSome: resource vanished (Connection reset by peer) simonpj at cam-05-unx:~/5builds/HEAD-5$ cabal install parsec --with-ghc=/home/simonpj/5builds/HEAD-5/inplace/bin/ghc-stage2 Resolving dependencies... Downloading text-1.2.1.3... Configuring text-1.2.1.3... Building text-1.2.1.3... Preprocessing library text-1.2.1.3... [ 1 of 44] Compiling Data.Text.Internal.Read ( Data/Text/Internal/Read.hs, dist/build/Data/Text/Internal/Read.o ) [ 2 of 44] Compiling Data.Text.Internal.Encoding.Utf32 ( Data/Text/Internal/Encoding/Utf32.hs, dist/build/Data/Text/Internal/Encoding/Utf32.o ) [ 3 of 44] Compiling Data.Text.Internal.Builder.RealFloat.Functions ( Data/Text/Internal/Builder/RealFloat/Functions.hs, dist/build/Data/Text/Internal/Builder/RealFloat/Functions.o ) [ 4 of 44] Compiling Data.Text.Internal.Builder.Int.Digits ( Data/Text/Internal/Builder/Int/Digits.hs, dist/build/Data/Text/Internal/Builder/Int/Digits.o ) [ 5 of 44] Compiling Data.Text.Encoding.Error ( Data/Text/Encoding/Error.hs, dist/build/Data/Text/Encoding/Error.o ) Data/Text/Encoding/Error.hs:3:14: warning: ?Data.Text.Encoding.Error? is marked as Trustworthy but has been inferred as safe! [ 6 of 44] Compiling Data.Text.Internal.Unsafe.Shift ( Data/Text/Internal/Unsafe/Shift.hs, dist/build/Data/Text/Internal/Unsafe/Shift.o ) [ 7 of 44] Compiling Data.Text.Internal.Encoding.Utf16 ( Data/Text/Internal/Encoding/Utf16.hs, dist/build/Data/Text/Internal/Encoding/Utf16.o ) [ 8 of 44] Compiling Data.Text.Internal.Functions ( Data/Text/Internal/Functions.hs, dist/build/Data/Text/Internal/Functions.o ) [ 9 of 44] Compiling Data.Text.Internal.Unsafe ( Data/Text/Internal/Unsafe.hs, dist/build/Data/Text/Internal/Unsafe.o ) [10 of 44] Compiling Data.Text.Array ( Data/Text/Array.hs, dist/build/Data/Text/Array.o ) [11 of 44] Compiling Data.Text.Internal.Unsafe.Char ( Data/Text/Internal/Unsafe/Char.hs, dist/build/Data/Text/Internal/Unsafe/Char.o ) [12 of 44] Compiling Data.Text.Internal ( Data/Text/Internal.hs, dist/build/Data/Text/Internal.o ) [13 of 44] Compiling Data.Text.Internal.Fusion.Size ( Data/Text/Internal/Fusion/Size.hs, dist/build/Data/Text/Internal/Fusion/Size.o ) [14 of 44] Compiling Data.Text.Internal.Fusion.Types ( Data/Text/Internal/Fusion/Types.hs, dist/build/Data/Text/Internal/Fusion/Types.o ) [15 of 44] Compiling Data.Text.Internal.Fusion.CaseMapping ( Data/Text/Internal/Fusion/CaseMapping.hs, dist/build/Data/Text/Internal/Fusion/CaseMapping.o ) [16 of 44] Compiling Data.Text.Internal.Fusion.Common ( Data/Text/Internal/Fusion/Common.hs, dist/build/Data/Text/Internal/Fusion/Common.o ) [17 of 44] Compiling Data.Text.Unsafe ( Data/Text/Unsafe.hs, dist/build/Data/Text/Unsafe.o ) [18 of 44] Compiling Data.Text.Internal.Private ( Data/Text/Internal/Private.hs, dist/build/Data/Text/Internal/Private.o ) [19 of 44] Compiling Data.Text.Internal.Fusion ( Data/Text/Internal/Fusion.hs, dist/build/Data/Text/Internal/Fusion.o ) [20 of 44] Compiling Data.Text.Show ( Data/Text/Show.hs, dist/build/Data/Text/Show.o ) Data/Text/Show.hs:57:11: warning: Rule "TEXT literal UTF8" may never fire because ?unpackCStringUtf8#? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ?unpackCStringUtf8#? [21 of 44] Compiling Data.Text.Internal.Encoding.Fusion.Common ( Data/Text/Internal/Encoding/Fusion/Common.hs, dist/build/Data/Text/Internal/Encoding/Fusion/Common.o ) [22 of 44] Compiling Data.Text.Internal.Encoding.Utf8 ( Data/Text/Internal/Encoding/Utf8.hs, dist/build/Data/Text/Internal/Encoding/Utf8.o ) [23 of 44] Compiling Data.Text.Internal.Encoding.Fusion ( Data/Text/Internal/Encoding/Fusion.hs, dist/build/Data/Text/Internal/Encoding/Fusion.o ) [24 of 44] Compiling Data.Text.Encoding ( Data/Text/Encoding.hs, dist/build/Data/Text/Encoding.o ) [25 of 44] Compiling Data.Text.Internal.Lazy.Encoding.Fusion ( Data/Text/Internal/Lazy/Encoding/Fusion.hs, dist/build/Data/Text/Internal/Lazy/Encoding/Fusion.o ) [26 of 44] Compiling Data.Text.Internal.Search ( Data/Text/Internal/Search.hs, dist/build/Data/Text/Internal/Search.o ) [27 of 44] Compiling Data.Text.Foreign ( Data/Text/Foreign.hs, dist/build/Data/Text/Foreign.o ) [28 of 44] Compiling Data.Text ( Data/Text.hs, dist/build/Data/Text.o ) Data/Text.hs:558:1: warning: Rule "TEXT compareN/length -> compareLength" may never fire because ?length? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ?length? Data/Text.hs:563:1: warning: Rule "TEXT ==N/length -> compareLength/==EQ" may never fire because ?length? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ?length? Data/Text.hs:568:1: warning: Rule "TEXT /=N/length -> compareLength//=EQ" may never fire because ?length? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ?length? Data/Text.hs:573:1: warning: Rule "TEXT compareLength/==LT" may never fire because ?length? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ?length? Data/Text.hs:578:1: warning: Rule "TEXT <=N/length -> compareLength//=GT" may never fire because ?length? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ?length? Data/Text.hs:583:1: warning: Rule "TEXT >N/length -> compareLength/==GT" may never fire because ?length? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ?length? Data/Text.hs:588:1: warning: Rule "TEXT >=N/length -> compareLength//=LT" may never fire because ?length? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ?length? [29 of 44] Compiling Data.Text.Internal.IO ( Data/Text/Internal/IO.hs, dist/build/Data/Text/Internal/IO.o ) [30 of 44] Compiling Data.Text.IO ( Data/Text/IO.hs, dist/build/Data/Text/IO.o ) [31 of 44] Compiling Data.Text.Internal.Lazy ( Data/Text/Internal/Lazy.hs, dist/build/Data/Text/Internal/Lazy.o ) [32 of 44] Compiling Data.Text.Internal.Lazy.Fusion ( Data/Text/Internal/Lazy/Fusion.hs, dist/build/Data/Text/Internal/Lazy/Fusion.o ) [33 of 44] Compiling Data.Text.Internal.Lazy.Search ( Data/Text/Internal/Lazy/Search.hs, dist/build/Data/Text/Internal/Lazy/Search.o ) [34 of 44] Compiling Data.Text.Lazy.Internal ( Data/Text/Lazy/Internal.hs, dist/build/Data/Text/Lazy/Internal.o ) [35 of 44] Compiling Data.Text.Lazy.Encoding ( Data/Text/Lazy/Encoding.hs, dist/build/Data/Text/Lazy/Encoding.o ) [36 of 44] Compiling Data.Text.Lazy ( Data/Text/Lazy.hs, dist/build/Data/Text/Lazy.o ) Data/Text/Lazy.hs:403:11: warning: Rule "TEXT literal UTF8" may never fire because ?unpackCStringUtf8#? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ?unpackCStringUtf8#? [37 of 44] Compiling Data.Text.Internal.Builder ( Data/Text/Internal/Builder.hs, dist/build/Data/Text/Internal/Builder.o ) Data/Text/Internal/Builder.hs:311:1: warning: Rule "flush/flush" may never fire because ?flush? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ?flush? [38 of 44] Compiling Data.Text.Lazy.Builder ( Data/Text/Lazy/Builder.hs, dist/build/Data/Text/Lazy/Builder.o ) [39 of 44] Compiling Data.Text.Internal.Builder.Functions ( Data/Text/Internal/Builder/Functions.hs, dist/build/Data/Text/Internal/Builder/Functions.o ) [40 of 44] Compiling Data.Text.Lazy.Builder.Int ( Data/Text/Lazy/Builder/Int.hs, dist/build/Data/Text/Lazy/Builder/Int.o ) [41 of 44] Compiling Data.Text.Lazy.IO ( Data/Text/Lazy/IO.hs, dist/build/Data/Text/Lazy/IO.o ) [42 of 44] Compiling Data.Text.Lazy.Read ( Data/Text/Lazy/Read.hs, dist/build/Data/Text/Lazy/Read.o ) Data/Text/Lazy/Read.hs:3:14: warning: ?Data.Text.Lazy.Read? is marked as Trustworthy but has been inferred as safe! [43 of 44] Compiling Data.Text.Lazy.Builder.RealFloat ( Data/Text/Lazy/Builder/RealFloat.hs, dist/build/Data/Text/Lazy/Builder/RealFloat.o ) [44 of 44] Compiling Data.Text.Read ( Data/Text/Read.hs, dist/build/Data/Text/Read.o ) In-place registering text-1.2.1.3... Creating package registration file: /tmp/pkgConf-text-1.2.118076.3 Installing library in /home/simonpj/.cabal/lib/x86_64-linux-ghc-7.11.20151125/text_5Rq52TgwV3S3ky6aLF96ly Registering text-1.2.1.3... Installed text-1.2.1.3 Configuring parsec-3.1.9... Building parsec-3.1.9... Preprocessing library parsec-3.1.9... [ 1 of 25] Compiling Text.Parsec.Pos ( Text/Parsec/Pos.hs, dist/build/Text/Parsec/Pos.o ) [ 2 of 25] Compiling Text.Parsec.Error ( Text/Parsec/Error.hs, dist/build/Text/Parsec/Error.o ) [ 3 of 25] Compiling Text.ParserCombinators.Parsec.Error ( Text/ParserCombinators/Parsec/Error.hs, dist/build/Text/ParserCombinators/Parsec/Error.o ) [ 4 of 25] Compiling Text.Parsec.Prim ( Text/Parsec/Prim.hs, dist/build/Text/Parsec/Prim.o ) Text/Parsec/Prim.hs:75:1: error: Bad interface file: /home/simonpj/.cabal/lib/x86_64-linux-ghc-7.11.20151125/text_5Rq52TgwV3S3ky6aLF96ly/Data/Text.hi Something is amiss; requested module text-1.2.1.3 at text-1.2.1.3-97fb94aeb32201606fe5187cbce5d852:Data.Text differs from name found in the interface file text_5Rq52TgwV3S3ky6aLF96ly:Data.Text Text/Parsec/Prim.hs:76:1: error: Bad interface file: /home/simonpj/.cabal/lib/x86_64-linux-ghc-7.11.20151125/text_5Rq52TgwV3S3ky6aLF96ly/Data/Text/Lazy.hi Something is amiss; requested module text-1.2.1.3 at text-1.2.1.3-97fb94aeb32201606fe5187cbce5d852:Data.Text.Lazy differs from name found in the interface file text_5Rq52TgwV3S3ky6aLF96ly:Data.Text.Lazy Text/Parsec/Prim.hs:80:1: error: Bad interface file: /home/simonpj/.cabal/lib/x86_64-linux-ghc-7.11.20151125/mtl_29yPYQfz4VvKtYIFBb0Wdp/Control/Monad/Trans.hi Something is amiss; requested module mtl-2.2.1 at mtl-2.2.1-fd5d2a6f3b4f2b35d982c365df381a09:Control.Monad.Trans differs from name found in the interface file mtl_29yPYQfz4VvKtYIFBb0Wdp:Control.Monad.Trans Text/Parsec/Prim.hs:81:1: error: Bad interface file: /home/simonpj/.cabal/lib/x86_64-linux-ghc-7.11.20151125/mtl_29yPYQfz4VvKtYIFBb0Wdp/Control/Monad/Identity.hi Something is amiss; requested module mtl-2.2.1 at mtl-2.2.1-fd5d2a6f3b4f2b35d982c365df381a09:Control.Monad.Identity differs from name found in the interface file mtl_29yPYQfz4VvKtYIFBb0Wdp:Control.Monad.Identity Text/Parsec/Prim.hs:83:1: error: Bad interface file: /home/simonpj/.cabal/lib/x86_64-linux-ghc-7.11.20151125/mtl_29yPYQfz4VvKtYIFBb0Wdp/Control/Monad/Reader/Class.hi Something is amiss; requested module mtl-2.2.1 at mtl-2.2.1-fd5d2a6f3b4f2b35d982c365df381a09:Control.Monad.Reader.Class differs from name found in the interface file mtl_29yPYQfz4VvKtYIFBb0Wdp:Control.Monad.Reader.Class Text/Parsec/Prim.hs:84:1: error: Bad interface file: /home/simonpj/.cabal/lib/x86_64-linux-ghc-7.11.20151125/mtl_29yPYQfz4VvKtYIFBb0Wdp/Control/Monad/State/Class.hi Something is amiss; requested module mtl-2.2.1 at mtl-2.2.1-fd5d2a6f3b4f2b35d982c365df381a09:Control.Monad.State.Class differs from name found in the interface file mtl_29yPYQfz4VvKtYIFBb0Wdp:Control.Monad.State.Class Text/Parsec/Prim.hs:85:1: error: Bad interface file: /home/simonpj/.cabal/lib/x86_64-linux-ghc-7.11.20151125/mtl_29yPYQfz4VvKtYIFBb0Wdp/Control/Monad/Cont/Class.hi Something is amiss; requested module mtl-2.2.1 at mtl-2.2.1-fd5d2a6f3b4f2b35d982c365df381a09:Control.Monad.Cont.Class differs from name found in the interface file mtl_29yPYQfz4VvKtYIFBb0Wdp:Control.Monad.Cont.Class Text/Parsec/Prim.hs:86:1: error: Bad interface file: /home/simonpj/.cabal/lib/x86_64-linux-ghc-7.11.20151125/mtl_29yPYQfz4VvKtYIFBb0Wdp/Control/Monad/Error/Class.hi Something is amiss; requested module mtl-2.2.1 at mtl-2.2.1-fd5d2a6f3b4f2b35d982c365df381a09:Control.Monad.Error.Class differs from name found in the interface file mtl_29yPYQfz4VvKtYIFBb0Wdp:Control.Monad.Error.Class Failed to install parsec-3.1.9 cabal: Error: some packages failed to install: parsec-3.1.9 failed during the building phase. The exception was: ExitFailure 1 simonpj at cam-05-unx:~/5builds/HEAD-5$ /home/simonpj/5builds/HEAD-5/inplace/bin/ghc-pkg list /5playpen/simonpj/HEAD-5/inplace/lib/package.conf.d: Cabal-1.23.0.0 array-0.5.1.0 base-4.9.0.0 binary-0.7.5.0 bytestring-0.10.6.0 containers-0.5.6.2 deepseq-1.4.2.0 directory-1.2.5.0 filepath-1.4.1.0 (ghc-7.11.20151125) ghc-boot-0.0.0.0 ghc-prim-0.5.0.0 haskeline-0.7.2.1 hoopl-3.10.2.0 hpc-0.6.0.2 integer-gmp-1.0.0.0 pretty-1.1.2.0 process-1.4.1.0 rts-1.0 template-haskell-2.11.0.0 terminfo-0.4.0.1 time-1.5.0.1 transformers-0.4.3.0 unix-2.7.1.0 xhtml-3000.2.1 /home/simonpj/.ghc/x86_64-linux-7.11.20151125/package.conf.d: mtl-2.2.1 text-1.2.1.3 simonpj at cam-05-unx:~/5builds/HEAD-5$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From spitzenb at fim.uni-passau.de Fri Nov 27 16:03:22 2015 From: spitzenb at fim.uni-passau.de (David Spitzenberg) Date: Fri, 27 Nov 2015 17:03:22 +0100 Subject: Questions concerning the LLVM backend - i.e. 'proc point splitting' In-Reply-To: <87h9kgwa29.fsf@smart-cactus.org> References: <5644BD6B.8060105@fim.uni-passau.de> <0d142c3bd7da47a9b869481dcef9a374@DB4PR30MB030.064d.mgd.msft.net> <87h9kgwa29.fsf@smart-cactus.org> Message-ID: <56587ECA.3070104@fim.uni-passau.de> Hello Simon, hello Ben, thank you very much to both of you for your encouraging answers! First of all, I've two questions concerning your answer, Ben. a) > The jump issue aside, I don't know how you would deal with > tables-next-to-code. The prefix data support that currently available > in LLVM is attached to functions and I unfortunately don't see that > changing any time soon. Looks like I messed things up with those info-tables. As far as I understood [1], these are part of the STG. Therefore, every function present at the STG-level needs a info-table. The code generator does generate info-tables for every proc-point after splitting them. But to me, this was a consequence of making them stand-alone functions. Could you explain the need of further info-tables for 'inner' proc-points (those, which are not the entry-block of a function) to me, please? b) > That being said, it sounds as though eliminating proc-point splitting > would make for quite a nice project in the native code generator. The documentation states, that proc-point splitting is only required by the LLVM backend (see [2]). Does the cmm-pipeline perform proc-point splitting even when using the native code generator? Second, some background information concerning my situation. As a student assistant, I'm part of a work group at university. They're doing research on loop-optimization (which is the reason why I'm doing stencil calculations in Haskell). The group uses LLVM (which is the reason why I'm using the LLVM backend). Recently I talked to them, trying to explain the reasons for GHC emitting code containing mutual recursion instead of loops under certain circumstances. They told me, that LLVM's cross-procedure optimization fails to merge the mutual recursion into a single loop because of the following. When pushing a continuation defined in the local LLVM module onto the stack and calling into a method defined externally, the analysis can't assure, that control eventually returns to the local continuation. To make control flow more apparent to LLVM, they came up with the following idea. Remark before showing the idea: I know that it greatly interferes with CPS. It leaves parts of the continuation-handling to the implicit LLVM call-stack. Further, this does not solve the problem of proc-point splitting at all. It is more a workaround than a solution. But it would greatly increase LLVM's possibilities to optimize code later on. That's why I found this idea worth mentioning. Especially because after reading your answer, Ben, I'm somewhat convinced that solving the problem of proc-point splitting is nearly impossible with the capabilities of LLVM IR available at the moment. Now back to the idea. As stated above, the major problem of LLVM seems to be inferring control flow when it comes to call proc-points. As it's hard to avoid proc-point splitting, we leave the cmm-pipeline 'as-is'. We modify the code, llvmGen produces when it comes to call proc-points instead. All other types of proc-points remain unchanged. Initial situation in pseudo cmm: foo() { ... call bar() returns to cont // bar defined externally cont: ... } After proc-point splitting, this is converted into LLVM IR similar to the following: @foo() { ... store @cont(), %Sp ; push continuation on the stack tail call @bar() ; @bar defined externally } @cont() { ... } To fix the above issue, we introduce a method, which restores the pointers Sp, Hp and the register R1 (among everything else, what has to be restored) and 'fakes' the continuation. Note, that '@restore' returns without calling into the continuation. This way, the call into the continuation can be made direct. The above code would be transformed into something similar to the following: @foo() { ... store @restore(), %Sp ; 'fake' continuation call @bar() ; br label restore restore: %Sp = load (getelementptr @environment 0, 0) ; restore what has to be ... ; restored tail call @cont() } @cont() { ... } @restore(%Sp, %Hp, %R1, ...) { store %Sp, (getelementptr @environment 0, 0) ; store everything into ... ; global variable ret void } @environment ; structure of type similar to {i64*, i64*, i64*, i64, i64, ..} As an alternative, the above transformation could be done by a LLVM pass. llvmGen could then annotate the continuation of calls call cite. This would greatly simplify the detection of the correct continuation. What do you think about this idea? Especially when thinking about the interference with CPS? Regards, David [1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/GeneratedCode#Importantconceptsinthemachine [2] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/CodeGen#Secondstage:theCmmpipeline On 11/21/2015 12:00 AM, Ben Gamari wrote: > Simon Peyton Jones writes: > >> David >> >> All this stuff is terribly paged-out for me. But I'd love someone to >> pay attention to some of this back-end stuff, so if you'd like to work >> there, I'd like to help you. >> >> David Terei was also thinking of getting rid of proc point splitting >> for LLVM (see attached email and the notes attached to it) >> >> Simon Marlow also was thinking about this; see his attached email. >> >> The main *reason* for establishing a proc-point is so that, when >> generating C code (which we don't do any more) you can take its >> address. E.g. >> >> foo() { ... Push &bar onto the stack (effectively a return address) >> Jump to thingumpy } >> >> bar() { ... } >> >> Really bar is part of foo, but we have make it a separate top level >> thing so that we can take the address of bar and push it on the stack. >> >> The trouble is that if there is a label inside bar that foo wants to >> jump to (i.e. without pushing &bar etc) then we have to make that >> label too into a proc-point, so that both foo and bar can see it. >> Urgh. >> >> In LLVM this probably is not true; presumably you can take the address >> of any label? >> > This is true. While labels themselves have function-local scope in LLVM, > there is an expression, `blockaddress`, which allows you to take an > address to a label in another function [1]. That being said, in reading > through the documentation it's not at all clear to me that it would be > safe to jump to such an address. In fact, given that the instruction > that this expression is supposed to be used with, `indirectbr`, can only > be used for local blocks, I suspect it is not. More information about > this feature can be found here [2]. > > The jump issue aside, I don't know how you would deal with > tables-next-to-code. The prefix data support that currently available in > LLVM is attached to functions and I unfortunately don't see that > changing any time soon. > > Ultimately it seems that trying to refer to labels defined in other > functions is using LLVM against the way it was intended. One alternative > would be to teach llvmGen to merge mutually recusive top-level functions > into a single LLVM function during code generation. Otherwise I'm afraid > you are stuck with either the status quo or attempting to improve on > LLVM's own cross-procedure optimization ability. > > That being said, it sounds as though eliminating proc-point splitting > would make for quite a nice project in the native code generator. > > Cheers, > > - Ben > > > [1] http://llvm.org/docs/LangRef.html#addresses-of-basic-blocks > [2] http://blog.llvm.org/2010/01/address-of-label-and-indirect-branches.html > [3] http://llvm.org/docs/LangRef.html#prefix-data > From niteria at gmail.com Fri Nov 27 17:02:15 2015 From: niteria at gmail.com (Bartosz Nitka) Date: Fri, 27 Nov 2015 17:02:15 +0000 Subject: Bad interface file In-Reply-To: References: Message-ID: I don't understand the root cause, but I run into this once and installing cabal HEAD fixed it for me. 2015-11-27 15:31 GMT+00:00 Simon Peyton Jones : > Can anyone confirm that Trac #11122 is fixed in HEAD? > > When I try to reproduce it, I tried this, *with a freshly-built HEAD* > > cabal install parsec > --with-ghc=/home/simonpj/5builds/HEAD-5/inplace/bin/ghc-stage2 > > But that fails as below, with a bizarre ?bad interface file? error. Does > anyone have a clue about what?s happening? Does it work for you? > > Simon > > cabal install parsec > --with-ghc=/home/simonpj/5builds/HEAD-5/inplace/bin/ghc-stage2 > > Resolving dependencies... > > Configuring mtl-2.2.1... > > Building mtl-2.2.1... > > Preprocessing library mtl-2.2.1... > > [ 1 of 22] Compiling Control.Monad.Writer.Class ( > Control/Monad/Writer/Class.hs, dist/build/Control/Monad/Writer/Class.o ) > > [ 2 of 22] Compiling Control.Monad.State.Class ( > Control/Monad/State/Class.hs, dist/build/Control/Monad/State/Class.o ) > > [ 3 of 22] Compiling Control.Monad.Reader.Class ( > Control/Monad/Reader/Class.hs, dist/build/Control/Monad/Reader/Class.o ) > > [ 4 of 22] Compiling Control.Monad.RWS.Class ( Control/Monad/RWS/Class.hs, > dist/build/Control/Monad/RWS/Class.o ) > > [ 5 of 22] Compiling Control.Monad.Identity ( Control/Monad/Identity.hs, > dist/build/Control/Monad/Identity.o ) > > [ 6 of 22] Compiling Control.Monad.Error.Class ( > Control/Monad/Error/Class.hs, dist/build/Control/Monad/Error/Class.o ) > > [ 7 of 22] Compiling Control.Monad.Cont.Class ( > Control/Monad/Cont/Class.hs, dist/build/Control/Monad/Cont/Class.o ) > > [ 8 of 22] Compiling Control.Monad.Trans ( Control/Monad/Trans.hs, > dist/build/Control/Monad/Trans.o ) > > [ 9 of 22] Compiling Control.Monad.Error ( Control/Monad/Error.hs, > dist/build/Control/Monad/Error.o ) > > [10 of 22] Compiling Control.Monad.Except ( Control/Monad/Except.hs, > dist/build/Control/Monad/Except.o ) > > [11 of 22] Compiling Control.Monad.List ( Control/Monad/List.hs, > dist/build/Control/Monad/List.o ) > > [12 of 22] Compiling Control.Monad.RWS.Lazy ( Control/Monad/RWS/Lazy.hs, > dist/build/Control/Monad/RWS/Lazy.o ) > > [13 of 22] Compiling Control.Monad.RWS ( Control/Monad/RWS.hs, > dist/build/Control/Monad/RWS.o ) > > [14 of 22] Compiling Control.Monad.Reader ( Control/Monad/Reader.hs, > dist/build/Control/Monad/Reader.o ) > > [15 of 22] Compiling Control.Monad.RWS.Strict ( > Control/Monad/RWS/Strict.hs, dist/build/Control/Monad/RWS/Strict.o ) > > [16 of 22] Compiling Control.Monad.State.Lazy ( > Control/Monad/State/Lazy.hs, dist/build/Control/Monad/State/Lazy.o ) > > [17 of 22] Compiling Control.Monad.State ( Control/Monad/State.hs, > dist/build/Control/Monad/State.o ) > > [18 of 22] Compiling Control.Monad.State.Strict ( > Control/Monad/State/Strict.hs, dist/build/Control/Monad/State/Strict.o ) > > [19 of 22] Compiling Control.Monad.Writer.Lazy ( > Control/Monad/Writer/Lazy.hs, dist/build/Control/Monad/Writer/Lazy.o ) > > [20 of 22] Compiling Control.Monad.Writer ( Control/Monad/Writer.hs, > dist/build/Control/Monad/Writer.o ) > > [21 of 22] Compiling Control.Monad.Writer.Strict ( > Control/Monad/Writer/Strict.hs, dist/build/Control/Monad/Writer/Strict.o ) > > [22 of 22] Compiling Control.Monad.Cont ( Control/Monad/Cont.hs, > dist/build/Control/Monad/Cont.o ) > > In-place registering mtl-2.2.1... > > Creating package registration file: /tmp/pkgConf-mtl-2.253500.1 > > Installing library in > > > /home/simonpj/.cabal/lib/x86_64-linux-ghc-7.11.20151125/mtl_29yPYQfz4VvKtYIFBb0Wdp > > Registering mtl-2.2.1... > > Installed mtl-2.2.1 > > Downloading text-1.2.1.3... > > Failed to install text-1.2.1.3 > > cabal: Error: some packages failed to install: > > parsec-3.1.9 depends on text-1.2.1.3 which failed to install. > > text-1.2.1.3 failed while downloading the package. The exception was: > > : hGetBufSome: resource vanished (Connection reset by peer) > > simonpj at cam-05-unx:~/5builds/HEAD-5$ cabal install parsec > --with-ghc=/home/simonpj/5builds/HEAD-5/inplace/bin/ghc-stage2 > > Resolving dependencies... > > Downloading text-1.2.1.3... > > Configuring text-1.2.1.3... > > Building text-1.2.1.3... > > Preprocessing library text-1.2.1.3... > > [ 1 of 44] Compiling Data.Text.Internal.Read ( Data/Text/Internal/Read.hs, > dist/build/Data/Text/Internal/Read.o ) > > [ 2 of 44] Compiling Data.Text.Internal.Encoding.Utf32 ( > Data/Text/Internal/Encoding/Utf32.hs, > dist/build/Data/Text/Internal/Encoding/Utf32.o ) > > [ 3 of 44] Compiling Data.Text.Internal.Builder.RealFloat.Functions ( > Data/Text/Internal/Builder/RealFloat/Functions.hs, > dist/build/Data/Text/Internal/Builder/RealFloat/Functions.o ) > > [ 4 of 44] Compiling Data.Text.Internal.Builder.Int.Digits ( > Data/Text/Internal/Builder/Int/Digits.hs, > dist/build/Data/Text/Internal/Builder/Int/Digits.o ) > > [ 5 of 44] Compiling Data.Text.Encoding.Error ( > Data/Text/Encoding/Error.hs, dist/build/Data/Text/Encoding/Error.o ) > > > > Data/Text/Encoding/Error.hs:3:14: warning: > > ?Data.Text.Encoding.Error? is marked as Trustworthy but has been > inferred as safe! > > [ 6 of 44] Compiling Data.Text.Internal.Unsafe.Shift ( > Data/Text/Internal/Unsafe/Shift.hs, > dist/build/Data/Text/Internal/Unsafe/Shift.o ) > > [ 7 of 44] Compiling Data.Text.Internal.Encoding.Utf16 ( > Data/Text/Internal/Encoding/Utf16.hs, > dist/build/Data/Text/Internal/Encoding/Utf16.o ) > > [ 8 of 44] Compiling Data.Text.Internal.Functions ( > Data/Text/Internal/Functions.hs, dist/build/Data/Text/Internal/Functions.o ) > > [ 9 of 44] Compiling Data.Text.Internal.Unsafe ( > Data/Text/Internal/Unsafe.hs, dist/build/Data/Text/Internal/Unsafe.o ) > > [10 of 44] Compiling Data.Text.Array ( Data/Text/Array.hs, > dist/build/Data/Text/Array.o ) > > [11 of 44] Compiling Data.Text.Internal.Unsafe.Char ( > Data/Text/Internal/Unsafe/Char.hs, > dist/build/Data/Text/Internal/Unsafe/Char.o ) > > [12 of 44] Compiling Data.Text.Internal ( Data/Text/Internal.hs, > dist/build/Data/Text/Internal.o ) > > [13 of 44] Compiling Data.Text.Internal.Fusion.Size ( > Data/Text/Internal/Fusion/Size.hs, > dist/build/Data/Text/Internal/Fusion/Size.o ) > > [14 of 44] Compiling Data.Text.Internal.Fusion.Types ( > Data/Text/Internal/Fusion/Types.hs, > dist/build/Data/Text/Internal/Fusion/Types.o ) > > [15 of 44] Compiling Data.Text.Internal.Fusion.CaseMapping ( > Data/Text/Internal/Fusion/CaseMapping.hs, > dist/build/Data/Text/Internal/Fusion/CaseMapping.o ) > > [16 of 44] Compiling Data.Text.Internal.Fusion.Common ( > Data/Text/Internal/Fusion/Common.hs, > dist/build/Data/Text/Internal/Fusion/Common.o ) > > [17 of 44] Compiling Data.Text.Unsafe ( Data/Text/Unsafe.hs, > dist/build/Data/Text/Unsafe.o ) > > [18 of 44] Compiling Data.Text.Internal.Private ( > Data/Text/Internal/Private.hs, dist/build/Data/Text/Internal/Private.o ) > > [19 of 44] Compiling Data.Text.Internal.Fusion ( > Data/Text/Internal/Fusion.hs, dist/build/Data/Text/Internal/Fusion.o ) > > [20 of 44] Compiling Data.Text.Show ( Data/Text/Show.hs, > dist/build/Data/Text/Show.o ) > > > > Data/Text/Show.hs:57:11: warning: > > Rule "TEXT literal UTF8" may never fire > > because ?unpackCStringUtf8#? might inline first > > Probable fix: add an INLINE[n] or NOINLINE[n] pragma for > ?unpackCStringUtf8#? > > [21 of 44] Compiling Data.Text.Internal.Encoding.Fusion.Common ( > Data/Text/Internal/Encoding/Fusion/Common.hs, > dist/build/Data/Text/Internal/Encoding/Fusion/Common.o ) > > [22 of 44] Compiling Data.Text.Internal.Encoding.Utf8 ( > Data/Text/Internal/Encoding/Utf8.hs, > dist/build/Data/Text/Internal/Encoding/Utf8.o ) > > [23 of 44] Compiling Data.Text.Internal.Encoding.Fusion ( > Data/Text/Internal/Encoding/Fusion.hs, > dist/build/Data/Text/Internal/Encoding/Fusion.o ) > > [24 of 44] Compiling Data.Text.Encoding ( Data/Text/Encoding.hs, > dist/build/Data/Text/Encoding.o ) > > [25 of 44] Compiling Data.Text.Internal.Lazy.Encoding.Fusion ( > Data/Text/Internal/Lazy/Encoding/Fusion.hs, > dist/build/Data/Text/Internal/Lazy/Encoding/Fusion.o ) > > [26 of 44] Compiling Data.Text.Internal.Search ( > Data/Text/Internal/Search.hs, dist/build/Data/Text/Internal/Search.o ) > > [27 of 44] Compiling Data.Text.Foreign ( Data/Text/Foreign.hs, > dist/build/Data/Text/Foreign.o ) > > [28 of 44] Compiling Data.Text ( Data/Text.hs, > dist/build/Data/Text.o ) > > > > Data/Text.hs:558:1: warning: > > Rule "TEXT compareN/length -> compareLength" may never fire > > because ?length? might inline first > > Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ?length? > > > > Data/Text.hs:563:1: warning: > > Rule "TEXT ==N/length -> compareLength/==EQ" may never fire > > because ?length? might inline first > > Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ?length? > > > > Data/Text.hs:568:1: warning: > > Rule "TEXT /=N/length -> compareLength//=EQ" may never fire > > because ?length? might inline first > > Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ?length? > > > > Data/Text.hs:573:1: warning: > > Rule "TEXT compareLength/==LT" may never fire > > because ?length? might inline first > > Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ?length? > > > > Data/Text.hs:578:1: warning: > > Rule "TEXT <=N/length -> compareLength//=GT" may never fire > > because ?length? might inline first > > Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ?length? > > > > Data/Text.hs:583:1: warning: > > Rule "TEXT >N/length -> compareLength/==GT" may never fire > > because ?length? might inline first > > Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ?length? > > > > Data/Text.hs:588:1: warning: > > Rule "TEXT >=N/length -> compareLength//=LT" may never fire > > because ?length? might inline first > > Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ?length? > > [29 of 44] Compiling Data.Text.Internal.IO ( Data/Text/Internal/IO.hs, > dist/build/Data/Text/Internal/IO.o ) > > [30 of 44] Compiling Data.Text.IO ( Data/Text/IO.hs, > dist/build/Data/Text/IO.o ) > > [31 of 44] Compiling Data.Text.Internal.Lazy ( Data/Text/Internal/Lazy.hs, > dist/build/Data/Text/Internal/Lazy.o ) > > [32 of 44] Compiling Data.Text.Internal.Lazy.Fusion ( > Data/Text/Internal/Lazy/Fusion.hs, > dist/build/Data/Text/Internal/Lazy/Fusion.o ) > > [33 of 44] Compiling Data.Text.Internal.Lazy.Search ( > Data/Text/Internal/Lazy/Search.hs, > dist/build/Data/Text/Internal/Lazy/Search.o ) > > [34 of 44] Compiling Data.Text.Lazy.Internal ( Data/Text/Lazy/Internal.hs, > dist/build/Data/Text/Lazy/Internal.o ) > > [35 of 44] Compiling Data.Text.Lazy.Encoding ( Data/Text/Lazy/Encoding.hs, > dist/build/Data/Text/Lazy/Encoding.o ) > > [36 of 44] Compiling Data.Text.Lazy ( Data/Text/Lazy.hs, > dist/build/Data/Text/Lazy.o ) > > > > Data/Text/Lazy.hs:403:11: warning: > > Rule "TEXT literal UTF8" may never fire > > because ?unpackCStringUtf8#? might inline first > > Probable fix: add an INLINE[n] or NOINLINE[n] pragma for > ?unpackCStringUtf8#? > > [37 of 44] Compiling Data.Text.Internal.Builder ( > Data/Text/Internal/Builder.hs, dist/build/Data/Text/Internal/Builder.o ) > > > > Data/Text/Internal/Builder.hs:311:1: warning: > > Rule "flush/flush" may never fire > > because ?flush? might inline first > > Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ?flush? > > [38 of 44] Compiling Data.Text.Lazy.Builder ( Data/Text/Lazy/Builder.hs, > dist/build/Data/Text/Lazy/Builder.o ) > > [39 of 44] Compiling Data.Text.Internal.Builder.Functions ( > Data/Text/Internal/Builder/Functions.hs, > dist/build/Data/Text/Internal/Builder/Functions.o ) > > [40 of 44] Compiling Data.Text.Lazy.Builder.Int ( > Data/Text/Lazy/Builder/Int.hs, dist/build/Data/Text/Lazy/Builder/Int.o ) > > [41 of 44] Compiling Data.Text.Lazy.IO ( Data/Text/Lazy/IO.hs, > dist/build/Data/Text/Lazy/IO.o ) > > [42 of 44] Compiling Data.Text.Lazy.Read ( Data/Text/Lazy/Read.hs, > dist/build/Data/Text/Lazy/Read.o ) > > > > Data/Text/Lazy/Read.hs:3:14: warning: > > ?Data.Text.Lazy.Read? is marked as Trustworthy but has been inferred > as safe! > > [43 of 44] Compiling Data.Text.Lazy.Builder.RealFloat ( > Data/Text/Lazy/Builder/RealFloat.hs, > dist/build/Data/Text/Lazy/Builder/RealFloat.o ) > > [44 of 44] Compiling Data.Text.Read ( Data/Text/Read.hs, > dist/build/Data/Text/Read.o ) > > In-place registering text-1.2.1.3... > > Creating package registration file: /tmp/pkgConf-text-1.2.118076.3 > > Installing library in > > > /home/simonpj/.cabal/lib/x86_64-linux-ghc-7.11.20151125/text_5Rq52TgwV3S3ky6aLF96ly > > Registering text-1.2.1.3... > > Installed text-1.2.1.3 > > Configuring parsec-3.1.9... > > Building parsec-3.1.9... > > Preprocessing library parsec-3.1.9... > > [ 1 of 25] Compiling Text.Parsec.Pos ( Text/Parsec/Pos.hs, > dist/build/Text/Parsec/Pos.o ) > > [ 2 of 25] Compiling Text.Parsec.Error ( Text/Parsec/Error.hs, > dist/build/Text/Parsec/Error.o ) > > [ 3 of 25] Compiling Text.ParserCombinators.Parsec.Error ( > Text/ParserCombinators/Parsec/Error.hs, > dist/build/Text/ParserCombinators/Parsec/Error.o ) > > [ 4 of 25] Compiling Text.Parsec.Prim ( Text/Parsec/Prim.hs, > dist/build/Text/Parsec/Prim.o ) > > > > Text/Parsec/Prim.hs:75:1: error: > > Bad interface file: > /home/simonpj/.cabal/lib/x86_64-linux-ghc-7.11.20151125/text_5Rq52TgwV3S3ky6aLF96ly/Data/Text.hi > > Something is amiss; requested module > text-1.2.1.3 at text-1.2.1.3-97fb94aeb32201606fe5187cbce5d852:Data.Text > differs from name found in the interface file > text_5Rq52TgwV3S3ky6aLF96ly:Data.Text > > > > Text/Parsec/Prim.hs:76:1: error: > > Bad interface file: > /home/simonpj/.cabal/lib/x86_64-linux-ghc-7.11.20151125/text_5Rq52TgwV3S3ky6aLF96ly/Data/Text/Lazy.hi > > Something is amiss; requested module > text-1.2.1.3 at text-1.2.1.3-97fb94aeb32201606fe5187cbce5d852:Data.Text.Lazy > differs from name found in the interface file > text_5Rq52TgwV3S3ky6aLF96ly:Data.Text.Lazy > > > > Text/Parsec/Prim.hs:80:1: error: > > Bad interface file: > /home/simonpj/.cabal/lib/x86_64-linux-ghc-7.11.20151125/mtl_29yPYQfz4VvKtYIFBb0Wdp/Control/Monad/Trans.hi > > Something is amiss; requested module > mtl-2.2.1 at mtl-2.2.1-fd5d2a6f3b4f2b35d982c365df381a09:Control.Monad.Trans > differs from name found in the interface file > mtl_29yPYQfz4VvKtYIFBb0Wdp:Control.Monad.Trans > > > > Text/Parsec/Prim.hs:81:1: error: > > Bad interface file: > /home/simonpj/.cabal/lib/x86_64-linux-ghc-7.11.20151125/mtl_29yPYQfz4VvKtYIFBb0Wdp/Control/Monad/Identity.hi > > Something is amiss; requested module > mtl-2.2.1 at mtl-2.2.1-fd5d2a6f3b4f2b35d982c365df381a09:Control.Monad.Identity > differs from name found in the interface file > mtl_29yPYQfz4VvKtYIFBb0Wdp:Control.Monad.Identity > > > > Text/Parsec/Prim.hs:83:1: error: > > Bad interface file: > /home/simonpj/.cabal/lib/x86_64-linux-ghc-7.11.20151125/mtl_29yPYQfz4VvKtYIFBb0Wdp/Control/Monad/Reader/Class.hi > > Something is amiss; requested module > mtl-2.2.1 at mtl-2.2.1-fd5d2a6f3b4f2b35d982c365df381a09:Control.Monad.Reader.Class > differs from name found in the interface file > mtl_29yPYQfz4VvKtYIFBb0Wdp:Control.Monad.Reader.Class > > > > Text/Parsec/Prim.hs:84:1: error: > > Bad interface file: > /home/simonpj/.cabal/lib/x86_64-linux-ghc-7.11.20151125/mtl_29yPYQfz4VvKtYIFBb0Wdp/Control/Monad/State/Class.hi > > Something is amiss; requested module > mtl-2.2.1 at mtl-2.2.1-fd5d2a6f3b4f2b35d982c365df381a09:Control.Monad.State.Class > differs from name found in the interface file > mtl_29yPYQfz4VvKtYIFBb0Wdp:Control.Monad.State.Class > > > > Text/Parsec/Prim.hs:85:1: error: > > Bad interface file: > /home/simonpj/.cabal/lib/x86_64-linux-ghc-7.11.20151125/mtl_29yPYQfz4VvKtYIFBb0Wdp/Control/Monad/Cont/Class.hi > > Something is amiss; requested module > mtl-2.2.1 at mtl-2.2.1-fd5d2a6f3b4f2b35d982c365df381a09:Control.Monad.Cont.Class > differs from name found in the interface file > mtl_29yPYQfz4VvKtYIFBb0Wdp:Control.Monad.Cont.Class > > > > Text/Parsec/Prim.hs:86:1: error: > > Bad interface file: > /home/simonpj/.cabal/lib/x86_64-linux-ghc-7.11.20151125/mtl_29yPYQfz4VvKtYIFBb0Wdp/Control/Monad/Error/Class.hi > > Something is amiss; requested module > mtl-2.2.1 at mtl-2.2.1-fd5d2a6f3b4f2b35d982c365df381a09:Control.Monad.Error.Class > differs from name found in the interface file > mtl_29yPYQfz4VvKtYIFBb0Wdp:Control.Monad.Error.Class > > Failed to install parsec-3.1.9 > > cabal: Error: some packages failed to install: > > parsec-3.1.9 failed during the building phase. The exception was: > > ExitFailure 1 > > simonpj at cam-05-unx:~/5builds/HEAD-5$ > /home/simonpj/5builds/HEAD-5/inplace/bin/ghc-pkg list > > /5playpen/simonpj/HEAD-5/inplace/lib/package.conf.d: > > Cabal-1.23.0.0 > > array-0.5.1.0 > > base-4.9.0.0 > > binary-0.7.5.0 > > bytestring-0.10.6.0 > > containers-0.5.6.2 > > deepseq-1.4.2.0 > > directory-1.2.5.0 > > filepath-1.4.1.0 > > (ghc-7.11.20151125) > > ghc-boot-0.0.0.0 > > ghc-prim-0.5.0.0 > > haskeline-0.7.2.1 > > hoopl-3.10.2.0 > > hpc-0.6.0.2 > > integer-gmp-1.0.0.0 > > pretty-1.1.2.0 > > process-1.4.1.0 > > rts-1.0 > > template-haskell-2.11.0.0 > > terminfo-0.4.0.1 > > time-1.5.0.1 > > transformers-0.4.3.0 > > unix-2.7.1.0 > > xhtml-3000.2.1 > > > > /home/simonpj/.ghc/x86_64-linux-7.11.20151125/package.conf.d: > > mtl-2.2.1 > > text-1.2.1.3 > > > > simonpj at cam-05-unx:~/5builds/HEAD-5$ > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Fri Nov 27 17:14:01 2015 From: ben at well-typed.com (Ben Gamari) Date: Fri, 27 Nov 2015 18:14:01 +0100 Subject: Questions concerning the LLVM backend - i.e. 'proc point splitting' In-Reply-To: <56587ECA.3070104@fim.uni-passau.de> References: <5644BD6B.8060105@fim.uni-passau.de> <0d142c3bd7da47a9b869481dcef9a374@DB4PR30MB030.064d.mgd.msft.net> <87h9kgwa29.fsf@smart-cactus.org> <56587ECA.3070104@fim.uni-passau.de> Message-ID: <878u5j8iw6.fsf@smart-cactus.org> David Spitzenberg writes: > Hello Simon, hello Ben, > > thank you very much to both of you for your encouraging answers! > Hello again! > First of all, I've two questions concerning your answer, Ben. > > a) > >> The jump issue aside, I don't know how you would deal with >> tables-next-to-code. The prefix data support that currently available >> in LLVM is attached to functions and I unfortunately don't see that >> changing any time soon. > > Looks like I messed things up with those info-tables. As far as I > understood [1], these are part of the STG. Therefore, every function > present at the STG-level needs a info-table. The code generator does > generate info-tables for every proc-point after splitting them. But to > me, this was a consequence of making them stand-alone functions. > > Could you explain the need of further info-tables for 'inner' > proc-points (those, which are not the entry-block of a function) to me, > please? Ahh, yes. I believe you are right; there should be no need for info tables on these proc-points given that they don't correspond to anything in the STG program. My apologies for muddying things! snip > > To make control flow more apparent to LLVM, they came up with the > following idea. Remark before showing the idea: I know that it greatly > interferes with CPS. It leaves parts of the continuation-handling to the > implicit LLVM call-stack. Further, this does not solve the problem of > proc-point splitting at all. It is more a workaround than a solution. > But it would greatly increase LLVM's possibilities to optimize code > later on. That's why I found this idea worth mentioning. Especially > because after reading your answer, Ben, I'm somewhat convinced that > solving the problem of proc-point splitting is nearly impossible with > the capabilities of LLVM IR available at the moment. Now back to the idea. > Well, don't let me dissuade you: firstly, I'm a rather fallible human and may have missed something; secondly, the LLVM folks have been quite receptive to new ideas and there is likely a reason they left the door open to expressing inter-procedure block references with `blockaddress`. You might consider asking about this on the LLVM list, assuming this isn't beyond the scope of your project. I'll leave the rest for those with better understanding of the whole picture to address. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From eir at cis.upenn.edu Fri Nov 27 23:29:45 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 27 Nov 2015 18:29:45 -0500 Subject: Should (~) be homogeneous or heterogeneous? In-Reply-To: <93d830da2e484a56a119d32c162ef241@DB4PR30MB030.064d.mgd.msft.net> References: <535F0264-3D46-461E-96FF-DA6299E1D3D6@cis.upenn.edu> <93d830da2e484a56a119d32c162ef241@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <9E28769F-BEB0-499A-BB4E-48FFE7636985@cis.upenn.edu> On Nov 24, 2015, at 7:54 AM, Simon Peyton Jones wrote: > In your example, why do you get KP Any? Why don't you get > > class forall k1 k2 kproxy). > (kproxy :: KProxy k1 ~ 'KP :: KProxy k2) => C kproxy where ... > > That may be over-polymorphic, but it'll work ok won't it? > All tyvars mentioned in superclass constraints must be introduced in the class head. Your version violates this constraint. > More generally, why does (2) lead to "trouble"? Suppose I then say > instance C ('KP :: KProxy Bool) GHC needs to prove ('KP :: KProxy Bool) ~ ('KP :: KProxy Any) and it has a hard time doing so. In any case, I've now seen enough very weird gotchas around heterogeneous ~ to convince me to keep it homogeneous, and to introduce ~~. If you want (~~), you'll need to import it from Data.Type.Equality -- it won't have magical scope like (~) does. Thanks for the feedback. Richard > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > | Richard Eisenberg > | Sent: 22 November 2015 19:00 > | To: ghc-devs Devs > | Subject: Should (~) be homogeneous or heterogeneous? > | > | Hi devs, > | > | I'm desperately working toward getting kind equalities in before the > | feature freeze. It's coming along nicely. But I have a user-facing > | issue to work out. > | > | * Should (~), as written in user code, require the kinds of its > | arguments to be equal? > | > | Another way of asking the same question is: Should the kind of (~) be > | 1. forall k. k -> k -> Constraint (HEAD) > | 2. forall k1 k2. k1 -> k2 -> Constraint (my branch, at the moment) > | > | Choice #2 is strictly more powerful and cannot be expressed in terms > | of #1. But #1 is perhaps more intuitive for programmers, who might > | expect inference to conclude that the two kinds are the same. > | > | Here is an example of where the difference matters: > | > | > data KProxy k = KP > | > class kproxy ~ 'KP => C (kproxy :: KProxy k) > | > | We can see that the kind of the type variable kproxy should be (KProxy > | k). But we still have to infer the kind of the occurrence of 'KP on > | the left. HEAD sees the kind of kproxy and infers that 'KP should have > | kind (KProxy k). My branch, on the other hand, doesn't have any reason > | to constrain the kind of 'KP, and so it gets (KProxy Any), which > | quickly causes trouble. > | > | The fix is easy: add a kind signature. > | > | I see two ways forward, corresponding to the choices for the kind of > | (~) above: > | > | 1. Make (~) homogeneous and introduce a new constraint (~~) that is > | like (~) but heterogeneous. We resign ourselves to explaining the > | technical, subtle difference between (~) and (~~) into perpetuity. > | > | 2. Make (~) heterogeneous. Some people will have to add kind > | annotations to their code to port from GHC 7.10 to GHC 8.0. But these > | kind annotations will be fully backward-compatible, and won't require > | CPP, or warnings, or any other bother. We may have to explain why kind > | inference around (~) is weaker than it was before. > | > | > | I'm (clearly?) leaning toward #2. But I'd like feedback. > | > | Thoughts? > | > | Thanks! > | Richard > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h > | askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- > | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c95ca36eba6074ac > | feefb08d2f36f2700%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=0w0B9q7 > | SJpXzf4UJokFZejYBhiIeASO0bfaJSDVRrJU%3d > From juhpetersen at gmail.com Sat Nov 28 15:34:10 2015 From: juhpetersen at gmail.com (Jens Petersen) Date: Sun, 29 Nov 2015 00:34:10 +0900 Subject: [ANNOUNCE] 7.10.3 release candidate 3 In-Reply-To: <87610zxt1r.fsf@smart-cactus.org> References: <87pozltpfv.fsf@smart-cactus.org> <87610zxt1r.fsf@smart-cactus.org> Message-ID: On 18 November 2015 at 23:48, Ben Gamari wrote: > We are pleased to announce the third release candidate of GHC 7.10.3: Thanks, I built it for Fedora and RHEL/CentOS 7 in my copr repo: https://copr.fedoraproject.org/coprs/petersen/ghc-7.10.3/ -Jens From edzhavoronkov at gmail.com Sun Nov 29 00:08:24 2015 From: edzhavoronkov at gmail.com (=?UTF-8?B?0K3QtNCz0LDRgCDQltCw0LLQvtGA0L7QvdC60L7Qsg==?=) Date: Sun, 29 Nov 2015 03:08:24 +0300 Subject: Warning suppression pragmas Message-ID: Hello devs! I am trying to implement some kind of local warnings suppresion and i need some help. I want to use a pragma to mark functions so compiler won't throw warnings from them. I defined my pragma in lexer, parser and added type signature in HsBinds.hs. And i am stuck. I don't know what to do. What should i consider doing further? I designed a small wiki page here - https://ghc.haskell.org/trac/ghc/wiki/Design/LocalWarningPragmas So if you have nice examples, feel free to add them. Thanks for your help in advance! --- ? ?????????, ?????????? ????? Best regards, Edgar A. Zhavoronkov -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Sun Nov 29 12:27:49 2015 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sun, 29 Nov 2015 12:27:49 +0000 Subject: Remove deprecated quasiquote syntax In-Reply-To: <6db50339030b4caaa1b0e00ca0675163@DB4PR30MB030.064d.mgd.msft.net> References: <6db50339030b4caaa1b0e00ca0675163@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Done in https://phabricator.haskell.org/D1530. On Wed, Nov 25, 2015 at 12:36 PM, Simon Peyton Jones wrote: > I'm all for it, if the broader community (e.g. the developers of those packages) are ok. > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > | Matthew Pickering > | Sent: 25 November 2015 12:12 > | To: GHC developers > | Subject: Remove deprecated quasiquote syntax > | > | The [$qq| quasiquote syntax has been deprecated since around 2010. > | > | Is there any objection to removing the backwards compatibility now? > | > | I counted 216 uses of it on hackage in a handful of packages, some in > | comments. > | > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flpaste > | .net%2f145938&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c82c772 > | ac7dc64bbe2b1208d2f59196d4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdat > | a=haPJyAOBSnUnXkyHn%2b%2bcqXRMj97pC1SwkXKr5liC00E%3d > | > | Here is the commit which deprecated it - > | https://github.com/ghc/ghc/commit/9ba922ee06b048774d7a82964867ff768a78 > | 126e > | > | Matt > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h > | askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- > | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c82c772ac7dc64bb > | e2b1208d2f59196d4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=EcfMMN4 > | prdTj%2bBzm2%2bpMpQlmMIuXe3yefy1TFdYMV9I%3d From ben at well-typed.com Sun Nov 29 14:54:28 2015 From: ben at well-typed.com (Ben Gamari) Date: Sun, 29 Nov 2015 15:54:28 +0100 Subject: [ANNOUNCE] 7.10.3 release candidate 3 In-Reply-To: References: <87pozltpfv.fsf@smart-cactus.org> <87610zxt1r.fsf@smart-cactus.org> Message-ID: <87si3o7t5n.fsf@smart-cactus.org> Jens Petersen writes: > On 18 November 2015 at 23:48, Ben Gamari wrote: >> We are pleased to announce the third release candidate of GHC 7.10.3: > > Thanks, I built it for Fedora and RHEL/CentOS 7 in my copr repo: > Thanks Jens! On that note, 7.10.3 is coming. At the moment I am blocked on getting a Cabal release tagged but hopefully this will happen Real Soon Now(TM). Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From eir at cis.upenn.edu Sun Nov 29 15:42:16 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Sun, 29 Nov 2015 10:42:16 -0500 Subject: stranal/sigs/UnsatFun Message-ID: <188691F7-A2E3-4E8E-9D95-385E32BE1054@cis.upenn.edu> Hi devs, On my kind=type branch (D808), I have this test failure for stranal/sigs/UnsatFun: ==================== Strictness signatures ==================== UnsatFun.$trModule: m UnsatFun.f: b -UnsatFun.g: b -UnsatFun.g': +UnsatFun.g: +UnsatFun.g': UnsatFun.g3: m -UnsatFun.h: -UnsatFun.h2: -UnsatFun.h3: m +UnsatFun.h: +UnsatFun.h2: +UnsatFun.h3: m *** unexpected failure for UnsatFun(optasm) I haven't any clue what this means. Is it bad? Is it good? Any pointers? Thanks! Richard From mail at joachim-breitner.de Sun Nov 29 18:09:18 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 29 Nov 2015 19:09:18 +0100 Subject: stranal/sigs/UnsatFun In-Reply-To: <188691F7-A2E3-4E8E-9D95-385E32BE1054@cis.upenn.edu> References: <188691F7-A2E3-4E8E-9D95-385E32BE1054@cis.upenn.edu> Message-ID: <1448820558.2939.2.camel@joachim-breitner.de> Hi, Am Sonntag, den 29.11.2015, 10:42 -0500 schrieb Richard Eisenberg: > On my kind=type branch (D808), I have this test failure for > stranal/sigs/UnsatFun: > > ==================== Strictness signatures ==================== > ?UnsatFun.$trModule: m > ?UnsatFun.f: b > -UnsatFun.g: b > -UnsatFun.g': > +UnsatFun.g: > +UnsatFun.g': > ?UnsatFun.g3: m > -UnsatFun.h: > -UnsatFun.h2: > -UnsatFun.h3: m > +UnsatFun.h: > +UnsatFun.h2: > +UnsatFun.h3: m > *** unexpected failure for UnsatFun(optasm) > > > I haven't any clue what this means. Is it bad? Is it good? Any > pointers? Unless the test case is bogus (which is possible, it was created by me, two years ago), the result ist bad. Here is the comment from the test case source file: Here we test how a partially applied function (f x) with a bottom result affects the strictness signature when used strictly (g) and lazily (g') In both cases, the parameter x should not be absent So it looks as if the strictness analysis become less powerful with your changes. Probably not downright wrong (I guess ?L? is always correct), but less precise. I admit to not having documented the test case well enough back then. (I can dig deeper if required, but not right now.) Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From ben at smart-cactus.org Sun Nov 29 19:49:06 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Sun, 29 Nov 2015 20:49:06 +0100 Subject: stranal/sigs/UnsatFun In-Reply-To: <188691F7-A2E3-4E8E-9D95-385E32BE1054@cis.upenn.edu> References: <188691F7-A2E3-4E8E-9D95-385E32BE1054@cis.upenn.edu> Message-ID: <87poys7fil.fsf@smart-cactus.org> Richard Eisenberg writes: > Hi devs, > > On my kind=type branch (D808), I have this test failure for stranal/sigs/UnsatFun: > Hmmm. I was curious and so took the opportunity to do a bit of digging. This likely isn't helpful but you never know... > -UnsatFun.g: b > +UnsatFun.g: It looks like the strictness analyzer can no longer see that `g` is bottoming (hence the missing `b`), which unfortunately seems to be exactly what this test is testing for. :( Moreover, the `B` changing to an `L` means that the demand analysis can't see that any demand is made of the first argument. > -UnsatFun.h: > +UnsatFun.h: This is the helper used by `g`. Again, it looks like something is going awry here with strictness analysis as the argument which was previously deemed "call-demand" is now just "strict". > -UnsatFun.g': > +UnsatFun.g': > > -UnsatFun.h2: > +UnsatFun.h2: This appears to be a very similar test which is likely failing for a similar reason. Could you perhaps collect the Core for this test before and after your patch? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From svenpanne at gmail.com Sun Nov 29 20:39:58 2015 From: svenpanne at gmail.com (Sven Panne) Date: Sun, 29 Nov 2015 21:39:58 +0100 Subject: What is causing the "Unrecognized field abi" warning? Message-ID: This shows up in more recent builds of my packages on Travis CI, e.g. https://travis-ci.org/haskell-opengl/OpenGL/jobs/93814917#L296, but I don't have a clue what's causing it (GHC? cabal? Something else?), if I should ignore it or if I should somehow act on that. :-/ My gut feeling is that it's GHC, but I might be wrong... Cheers, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Sun Nov 29 20:42:20 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Sun, 29 Nov 2015 12:42:20 -0800 Subject: What is causing the "Unrecognized field abi" warning? In-Reply-To: References: Message-ID: <1448829669-sup-2169@sabre> Hello Sven, Recent versions of Cabal output an 'abi' field to the installed package database which records what the abi hash of the package is. Old versions GHC (or more specifically, ghc-pkg) are not able to interpret this, so they print an error; however, the error is harmless. If the messages are bothersome, we could setup Cabal to not print out fields if it knows that GHC doesn't support them. Edward Excerpts from Sven Panne's message of 2015-11-29 12:39:58 -0800: > This shows up in more recent builds of my packages on Travis CI, e.g. > https://travis-ci.org/haskell-opengl/OpenGL/jobs/93814917#L296, but I don't > have a clue what's causing it (GHC? cabal? Something else?), if I should > ignore it or if I should somehow act on that. :-/ My gut feeling is that > it's GHC, but I might be wrong... > > Cheers, > S. From carter.schonwald at gmail.com Mon Nov 30 00:32:01 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 29 Nov 2015 19:32:01 -0500 Subject: [ANNOUNCE] 7.10.3 release candidate 3 In-Reply-To: <87si3o7t5n.fsf@smart-cactus.org> References: <87pozltpfv.fsf@smart-cactus.org> <87610zxt1r.fsf@smart-cactus.org> <87si3o7t5n.fsf@smart-cactus.org> Message-ID: Cool. Please let me know how I can help with the Mac build :) I'm a bit busy at work this week, but I can slice out soem time to help get all the details right On Sunday, November 29, 2015, Ben Gamari wrote: > Jens Petersen > writes: > > > On 18 November 2015 at 23:48, Ben Gamari > wrote: > >> We are pleased to announce the third release candidate of GHC 7.10.3: > > > > Thanks, I built it for Fedora and RHEL/CentOS 7 in my copr repo: > > > Thanks Jens! > > On that note, 7.10.3 is coming. At the moment I am blocked on getting a > Cabal release tagged but hopefully this will happen Real Soon Now(TM). > > Cheers, > > - Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Mon Nov 30 03:16:07 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Sun, 29 Nov 2015 22:16:07 -0500 Subject: stranal/sigs/UnsatFun In-Reply-To: <87poys7fil.fsf@smart-cactus.org> References: <188691F7-A2E3-4E8E-9D95-385E32BE1054@cis.upenn.edu> <87poys7fil.fsf@smart-cactus.org> Message-ID: <9BAA340C-C158-4918-A137-9C9F09DB22D3@cis.upenn.edu> These responses are helpful, thanks. Is there a primer for how to read the output? Or a small function that produces the output that I could quickly reverse engineer? There is a suggestion to look at the core before and after my patch. Is there a certain phase I should look at? What should I look for? And where in the GHC code base should I start looking to understand this better? Sorry if these questions seem too easy -- I'm just out of my element here. My hunch is that I need to update something in the strictness analyzer to look through/around/beyond coercions somewhere. Any ideas as to what that might be would be helpful! :) Thanks, Richard On Nov 29, 2015, at 2:49 PM, Ben Gamari wrote: > Richard Eisenberg writes: > >> Hi devs, >> >> On my kind=type branch (D808), I have this test failure for stranal/sigs/UnsatFun: >> > Hmmm. I was curious and so took the opportunity to do a bit of digging. > This likely isn't helpful but you never know... > >> -UnsatFun.g: b >> +UnsatFun.g: > > It looks like the strictness analyzer can no longer see that `g` is > bottoming (hence the missing `b`), which unfortunately seems to be > exactly what this test is testing for. :( > > Moreover, the `B` changing to an `L` means that the demand analysis > can't see that any demand is made of the first argument. > >> -UnsatFun.h: >> +UnsatFun.h: > > This is the helper used by `g`. Again, it looks like something is going > awry here with strictness analysis as the argument which was previously > deemed "call-demand" is now just "strict". > >> -UnsatFun.g': >> +UnsatFun.g': >> >> -UnsatFun.h2: >> +UnsatFun.h2: > > This appears to be a very similar test which is likely failing for a > similar reason. > > Could you perhaps collect the Core for this test before and after your > patch? > From svenpanne at gmail.com Mon Nov 30 06:49:56 2015 From: svenpanne at gmail.com (Sven Panne) Date: Mon, 30 Nov 2015 07:49:56 +0100 Subject: What is causing the "Unrecognized field abi" warning? In-Reply-To: <1448829669-sup-2169@sabre> References: <1448829669-sup-2169@sabre> Message-ID: 2015-11-29 21:42 GMT+01:00 Edward Z. Yang : > [...] If the messages are bothersome, we could setup Cabal to not print out > fields if it knows that GHC doesn't support them. > I would very much appreciate that, especially given the fact that "old versions of GHC" include GHC HEAD from Herbert's ppa. ;-) Cheers, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon Nov 30 08:59:31 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 30 Nov 2015 09:59:31 +0100 Subject: stranal/sigs/UnsatFun In-Reply-To: <9BAA340C-C158-4918-A137-9C9F09DB22D3@cis.upenn.edu> References: <188691F7-A2E3-4E8E-9D95-385E32BE1054@cis.upenn.edu> <87poys7fil.fsf@smart-cactus.org> <9BAA340C-C158-4918-A137-9C9F09DB22D3@cis.upenn.edu> Message-ID: <1448873971.1640.4.camel@joachim-breitner.de> Hi Richard, Am Sonntag, den 29.11.2015, 22:16 -0500 schrieb Richard Eisenberg: > Is there a primer for how to read the output? there is https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Demand which I think is the most up-to-date-description of strictness signatures. All the papers out there, as far as I know, only cover some of the aspects of it. > Or a small function > that produces the output that I could quickly reverse engineer? Sorry, not sure what you mean :-| The pretty-printer for these is in compiler/basicTypes/Demand.hs. > There is a suggestion to look at the core before and after my patch. > Is there a certain phase I should look at? What should I look for? The strictness signature is calculated by the Demand Analyser, so I think -ddump-stranal is the right one. > And where in the GHC code base should I start looking to understand > this better? Definitely?compiler/stranal/DmdAnal.lhs. > Sorry if these questions seem too easy -- I'm just out of my element > here. My hunch is that I need to update something in the strictness > analyzer to look through/around/beyond coercions somewhere. Any ideas > as to what that might be would be helpful! :) That?d be my hunch as well, but I?m not sure how to help more ? besides building your branch and tracing through the code myself. If you are stuck or really do not feel like looking at that code, just should and I?ll see if I can detect whats wrong. But maybe for that it already suffices to see the core in both cases somewhere. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From ben at smart-cactus.org Mon Nov 30 09:40:11 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 30 Nov 2015 10:40:11 +0100 Subject: stranal/sigs/UnsatFun In-Reply-To: <9BAA340C-C158-4918-A137-9C9F09DB22D3@cis.upenn.edu> References: <188691F7-A2E3-4E8E-9D95-385E32BE1054@cis.upenn.edu> <87poys7fil.fsf@smart-cactus.org> <9BAA340C-C158-4918-A137-9C9F09DB22D3@cis.upenn.edu> Message-ID: <87k2oz7rlw.fsf@smart-cactus.org> Richard Eisenberg writes: > These responses are helpful, thanks. > > Is there a primer for how to read the output? Or a small function that > produces the output that I could quickly reverse engineer? > The Wiki is a good place to start although the description there is lacking a bit. [1] Relatedly, some time ago I started writing a blog article about various aspects of Core with the intent of presenting a document accessible to the average Haskeller with an interest in diving into the compilation pipeline. While it's quite far from done, it's perhaps worth putting up the current state of it. Here it is [2]. > There is a suggestion to look at the core before and after my patch. > Is there a certain phase I should look at? What should I look for? > It would be good to see the Core as it enters strictness analysis. > And where in the GHC code base should I start looking to understand > this better? > compiler/stranal I believe. Of course, take anything I have to say with a large grain of salt; Joachim's opinion is orders of magnitude better informed than mine in this area. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Demand [2] http://smart-cactus.org/~ben/posts/2015-01-19-understanding-ghc-core.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ben at smart-cactus.org Mon Nov 30 09:44:47 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 30 Nov 2015 10:44:47 +0100 Subject: stranal/sigs/UnsatFun In-Reply-To: <9BAA340C-C158-4918-A137-9C9F09DB22D3@cis.upenn.edu> References: <188691F7-A2E3-4E8E-9D95-385E32BE1054@cis.upenn.edu> <87poys7fil.fsf@smart-cactus.org> <9BAA340C-C158-4918-A137-9C9F09DB22D3@cis.upenn.edu> Message-ID: <87h9k37re8.fsf@smart-cactus.org> Richard Eisenberg writes: > These responses are helpful, thanks. > > Is there a primer for how to read the output? Or a small function that > produces the output that I could quickly reverse engineer? > > There is a suggestion to look at the core before and after my patch. > Is there a certain phase I should look at? What should I look for? > > And where in the GHC code base should I start looking to understand > this better? > > Sorry if these questions seem too easy -- I'm just out of my element > here. My hunch is that I need to update something in the strictness > analyzer to look through/around/beyond coercions somewhere. Any ideas > as to what that might be would be helpful! :) > You might also want to look at [1], which appears to offer a nice tour around the implementation. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Demand/RelevantParts -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From george.colpitts at gmail.com Tue Nov 17 02:35:21 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Tue, 17 Nov 2015 02:35:21 -0000 Subject: [ANNOUNCE] 7.10.3 release candidate 2 - problems compiling source on Mac OS with clang In-Reply-To: References: <87oaeuz2jw.fsf@smart-cactus.org> <87bnauyul4.fsf@smart-cactus.org> Message-ID: I don't understand. By they do you mean the HsOpenSSL team? As I've written twice in this thread I have installed openssl via brew so I don't know why you are telling me to install it via brew . I've referenced the HsOpenSSL github page that has an issue on the use of openssl saying it is broken in Mac OS 10.11 and indicating that the HsOpenSSL needs to address this. Do you have a link about their switch to libressl? Dropping ghc devs to bcc as this is not a ghc issue On Mon, Nov 16, 2015 at 9:18 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > My understanding is that they now use libre ssl. So definitely not > OpenSSL. If you want open ssl instead you need to install it via brew or > the like > > > On Monday, November 16, 2015, George Colpitts > wrote: > >> Sorry, it seems that this is a known problem with Mac OS 10.11. From >> https://github.com/phonohawk/HsOpenSSL/issues/41 >> >> openssl libs and includes are not included in OS X 10.11. I'm not sure if >> this is permanent or just an effect of the beta release but we should keep >> our eye on it so when 10.11 is released, HsOpenSSL will work smoothly. >> >> >> On Mon, Nov 16, 2015 at 9:14 AM, George Colpitts < >> george.colpitts at gmail.com> wrote: >> >>> >>> find /usr/local -iname asn1.h >>> /usr/local/Cellar/nettle/2.7.1/include/nettle/asn1.h >>> /usr/local/Cellar/openssl/1.0.1j/include/openssl/asn1.h >>> /usr/local/Cellar/openssl/1.0.1j_1/include/openssl/asn1.h >>> /usr/local/Cellar/openssl/1.0.1l/include/openssl/asn1.h >>> /usr/local/Cellar/openssl/1.0.2a-1/include/openssl/asn1.h >>> /usr/local/Cellar/openssl/1.0.2c/include/openssl/asn1.h >>> /usr/local/Cellar/openssl/1.0.2d_1/include/openssl/asn1.h >>> >>> ​As you might guess​ from the above I've successfully installed this in >>> the past with other versions of ghc :) >>> >>> Thanks for all your help here >>> >>> Cheers >>> George >>> >>> >>> On Mon, Nov 16, 2015 at 8:52 AM, Ben Gamari >>> wrote: >>> >>>> George Colpitts writes: >>>> >>>> > As I mentioned above from brew: >>>> > >>>> > $ brew upgrade openssl >>>> > brew upgrade openssl >>>> > Error: openssl 1.0.2d_1 already installed >>>> > >>>> I see. Does the file in question exist? >>>> >>>> What does >>>> >>>> find /usr/local -iname asn1.h >>>> >>>> say? >>>> >>>> Cheers, >>>> >>>> - Ben >>>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: