RE: [GHC] #8704: Use GHC.Exts.build in randoms, randomRs to achieve fusion
Hi Ryan Are you on this thread? You probably should be! Simon | -Original Message- | From: ghc-tickets [mailto:ghc-tickets-boun...@haskell.org] On Behalf Of | GHC | Sent: 27 January 2014 18:49 | Cc: ghc-tick...@haskell.org | Subject: Re: [GHC] #8704: Use GHC.Exts.build in randoms, randomRs to | achieve fusion | | #8704: Use GHC.Exts.build in randoms, randomRs to achieve fusion | -+- | --- | Reporter: ion1 |Owner: | Type: feature request | Status: patch | Priority: normal|Milestone: |Component: libraries/random | Version: 7.6.3 | Resolution:| Keywords: fusion | Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple | Type of failure: None/Unknown | Difficulty: Unknown |Test Case:| Blocked By: | Blocking:| Related Tickets: #4218 | -+- | --- | | Comment (by nomeata): | | Thanks. From my POV it is worth adding even if you can’t measure a | performance gain; it is still good to know that nice code is being | generated. But of course it is up to Ryan Newton (random maintainer) | to | decide this. | | -- | Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8704#comment:4 | GHC http://www.haskell.org/ghc/ | The Glasgow Haskell Compiler | ___ | ghc-tickets mailing list | ghc-tick...@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-tickets ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Request: export runTcInteractive from TcRnDriver
No, there's no reason it's not exported, excepting only that it's not currently called outside TcRnDriver. Go ahead and create a ticket and patch. It should be exported from GHC.hs (ie the official GHC API), not merely from TcRnDriver. And I suggest you add a comment with the export from GHC.hs to explain why it's exported. Otherwise someone might delete it again! Thx Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of p.k.f.holzensp...@utwente.nl Sent: 29 January 2014 09:55 To: ghc-devs@haskell.org Subject: Request: export runTcInteractive from TcRnDriver Dear GHC-devs, Is there a reason why, in HEAD, TcRnDriver does *not* export runTcInteractive? If not, can it please be added? (I considered sending a patch with this email, but it's so trivial a change that the check of the patch is more work than manually adding runTcInteractive to the export list.) I'm developing against the GHC API of 7.6.3 and it would have saved me hours of work to have precisely that function. Seeing it's in HEAD, but not being exported seems a shame ;) Regards, Philip ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: GHC boot-library package changelogs release-notes
Herbert Would you like to add some notes to https://ghc.haskell.org/trac/ghc/wiki/Commentary/Libraries, to describe what the file is, and the criteria for modifying it? (After all, the patch history is a kind of change log too.) Thanks Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Herbert Valerio Riedel | Sent: 29 January 2014 16:33 | To: ghc-devs | Subject: GHC boot-library package changelogs release-notes | | Hello fellow GHC devs, | | As some of you might have noticed, I added a changelog.md file to | libraries/base: | | https://github.com/ghc/packages- | base/blob/c8634027d4e3315a2276fb1be8168c486419785a/changelog.md | | (please feel free to fix any typos/omissions/whatever you notice) | | My hope/motivation is that since Hackage gained the ability to display | changelog files, the rather extensive changes in `base` might be a bit | more easily/conveniently accessible on Hackage. | | I chose to use Markdown format, as I believe it may be more convenient | to maintain/edit the `base` changelog as plain text rather than having | to edit XML after each noteworthy change in `base`. And as the | release-notes typically only exploit a subset of the Docbook | facilities, | the conversion to Docbook XML could be performed semi-automatically | shortly before a release. | | Moreover, the release notes from previous major GHC release (which in | the past contained the major changes in `base` et al.) are usually | removed again. While a separate changelog file would usually retain | (more) version history. | | Therefore, I'd propose to switch from editing the user's guide release | note for library release notes to using Hackage-changelog files in | Markdown format (following a common structural convention) and make it | the release-manager's responsibility to integrate the respective | package's changelog content into the user's guide. | | Any comments? | | Cheers, | hvr | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Pre-Master checks (Was: Nightlies)
Hi, Am Dienstag, den 04.02.2014, 08:04 + schrieb Simon Peyton Jones: I want just to say thank you for thinking about this. We badly need better nightly-builds for GHC, on a variety of platforms a) to identify regressions, preferably to the actually commit that caused it, so Austin's big red message can go to the right person I believe we can do better, so that Austin’s big red message does not have to be written in the first place. Here is what I have in mind, and I’ll volunteer to implement it if people think it is a good idea and I get the resources/permissions: Proposal Nobody gets to push to master directly. Instead, every push to master is diverted¹ to a temporary branch validating/some id. One of our servers detects the appearance of such a branch and will * check it out, * validate it, * if ok: check if master can still be fast-forward’ed to it, * if yes: push to master. If it does not validate, or if master has changed in between, the branch will be moved to failed/some id, and a message is sent to the pushing developer², including a tail of the log and a link to the full log. Systems can fail, and maybe nothing validates anymore for reasons not easily fixable. For that case, a backdoor is available: Pushes to the branch master-unchecked will be moved to master, well, unchecked. Benefits: * It is guaranteed that master has validated at least once somewhere. I.e. no need to ask on the mailing list “does master validate for you right now?” * It is now ok to do changes that are “obviously correct” (comment changes, removing dead code, code reformatting) without having to validate manually, which _saves developer time_ (our most precious resource). Downsides: * When two commits are racing for master, one will be rejected for being a non-fast-forward commit. The user will then have to merge or rebase and try again. But: The same would be true if he was validating locally (unless he does not validate the merge/rebase, in which case we are again where we don’t want to be: Unvalidated versions in master.) Is this something you would what, or could live with? If it is technically feasible (given our hardware constraints, repository structure and git’s feature) is a different question, which needs to be discussed afterwards. Greetings, Joachim ¹ Might not be possible transparently (http://stackoverflow.com/questions/21362833), but for the sake of argument and workflow design, assume it was. ² As an approximation: The committer of the latest patch. PS: I’m also considering (but not pushing hard) for a stronger variant as follows. We do not need to discuss that now and should, if at all, start the with the proposal above. I’m just adding it to show where this is going ... Stronger proposal ~ Every commit in master needs to be validated! I tend to make sure that all patches on my branch validate individually (git rebase -i -x ./validate is a great tool here, you should use it! ). Contributors who do not want to go through that trouble should then use git merge --squash to produce a single commit from their branch. This would make the git history more useful for things like bitsecting. -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nome...@joachim-breitner.de signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Pre-Master checks (Was: Nightlies)
Yay! I, for one, would probably submit more bugfix patches with this structure in place. I take validating seriously, but my daily schedule often involves switching machines and tasks, and once I press validate, it's often hours before I actually look at the results... by which time, some other commit may have come through. My need (real or perceived) for an uninterrupted chunk of time to make a patch stops me from doing them, sometimes. With Joachim's structure, I could spend a half hour doing a quick patch (especially comments!) and push and move on. Please do it! :) Thanks! Richard PS: Transparency in the git redirects would be nice, of course, but is in no way necessary. We could I suppose add a push script to the repo that handles some of the overhead. On Feb 4, 2014, at 4:41 AM, Joachim Breitner m...@joachim-breitner.de wrote: Hi, Am Dienstag, den 04.02.2014, 08:04 + schrieb Simon Peyton Jones: I want just to say thank you for thinking about this. We badly need better nightly-builds for GHC, on a variety of platforms a) to identify regressions, preferably to the actually commit that caused it, so Austin's big red message can go to the right person I believe we can do better, so that Austin’s big red message does not have to be written in the first place. Here is what I have in mind, and I’ll volunteer to implement it if people think it is a good idea and I get the resources/permissions: Proposal Nobody gets to push to master directly. Instead, every push to master is diverted¹ to a temporary branch validating/some id. One of our servers detects the appearance of such a branch and will * check it out, * validate it, * if ok: check if master can still be fast-forward’ed to it, * if yes: push to master. If it does not validate, or if master has changed in between, the branch will be moved to failed/some id, and a message is sent to the pushing developer², including a tail of the log and a link to the full log. Systems can fail, and maybe nothing validates anymore for reasons not easily fixable. For that case, a backdoor is available: Pushes to the branch master-unchecked will be moved to master, well, unchecked. Benefits: * It is guaranteed that master has validated at least once somewhere. I.e. no need to ask on the mailing list “does master validate for you right now?” * It is now ok to do changes that are “obviously correct” (comment changes, removing dead code, code reformatting) without having to validate manually, which _saves developer time_ (our most precious resource). Downsides: * When two commits are racing for master, one will be rejected for being a non-fast-forward commit. The user will then have to merge or rebase and try again. But: The same would be true if he was validating locally (unless he does not validate the merge/rebase, in which case we are again where we don’t want to be: Unvalidated versions in master.) Is this something you would what, or could live with? If it is technically feasible (given our hardware constraints, repository structure and git’s feature) is a different question, which needs to be discussed afterwards. Greetings, Joachim ¹ Might not be possible transparently (http://stackoverflow.com/questions/21362833), but for the sake of argument and workflow design, assume it was. ² As an approximation: The committer of the latest patch. PS: I’m also considering (but not pushing hard) for a stronger variant as follows. We do not need to discuss that now and should, if at all, start the with the proposal above. I’m just adding it to show where this is going ... Stronger proposal ~ Every commit in master needs to be validated! I tend to make sure that all patches on my branch validate individually (git rebase -i -x ./validate is a great tool here, you should use it! ). Contributors who do not want to go through that trouble should then use git merge --squash to produce a single commit from their branch. This would make the git history more useful for things like bitsecting. -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nome...@joachim-breitner.de ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Pre-Master checks (Was: Nightlies)
On 04/02/14 09:41, Joachim Breitner wrote: Hi, Am Dienstag, den 04.02.2014, 08:04 + schrieb Simon Peyton Jones: I want just to say thank you for thinking about this. We badly need better nightly-builds for GHC, on a variety of platforms a) to identify regressions, preferably to the actually commit that caused it, so Austin's big red message can go to the right person I believe we can do better, so that Austin’s big red message does not have to be written in the first place. Here is what I have in mind, and I’ll volunteer to implement it if people think it is a good idea and I get the resources/permissions: Proposal Nobody gets to push to master directly. Instead, every push to master is diverted¹ to a temporary branch validating/some id. One of our servers detects the appearance of such a branch and will * check it out, * validate it, * if ok: check if master can still be fast-forward’ed to it, * if yes: push to master. If it does not validate, or if master has changed in between, the branch will be moved to failed/some id, and a message is sent to the pushing developer², including a tail of the log and a link to the full log. Systems can fail, and maybe nothing validates anymore for reasons not easily fixable. For that case, a backdoor is available: Pushes to the branch master-unchecked will be moved to master, well, unchecked. Benefits: * It is guaranteed that master has validated at least once somewhere. I.e. no need to ask on the mailing list “does master validate for you right now?” * It is now ok to do changes that are “obviously correct” (comment changes, removing dead code, code reformatting) without having to validate manually, which _saves developer time_ (our most precious resource). Downsides: * When two commits are racing for master, one will be rejected for being a non-fast-forward commit. The user will then have to merge or rebase and try again. But: The same would be true if he was validating locally (unless he does not validate the merge/rebase, in which case we are again where we don’t want to be: Unvalidated versions in master.) Is this something you would what, or could live with? If it is technically feasible (given our hardware constraints, repository structure and git’s feature) is a different question, which needs to be discussed afterwards. Greetings, Joachim ¹ Might not be possible transparently (http://stackoverflow.com/questions/21362833), but for the sake of argument and workflow design, assume it was. ² As an approximation: The committer of the latest patch. PS: I’m also considering (but not pushing hard) for a stronger variant as follows. We do not need to discuss that now and should, if at all, start the with the proposal above. I’m just adding it to show where this is going ... Stronger proposal ~ Every commit in master needs to be validated! I tend to make sure that all patches on my branch validate individually (git rebase -i -x ./validate is a great tool here, you should use it! ). Contributors who do not want to go through that trouble should then use git merge --squash to produce a single commit from their branch. This would make the git history more useful for things like bitsecting. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs You mention that it's enough for one machine to validate the patch. What if the change was for example to fix something on ARM (where builds take a long time) and has no effect on x86? The x86 machine is likely to come through first and give you the OK, pushing to master something that's effectively not checked. In fact, the fastest slave is likely to come through first every time and if it validates there (for example, I hear that 64-bit Linux is the golden platform for validate), it will be pushed to master. I think the proposal needs an enhancement: ability to specify which platform the commit needs to validate on (i.e. even if i686 comes through first, we'll wait for ARM anyway) before being pushed in. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Pre-Master checks (Was: Nightlies)
This actually raises an important question: we don't have any good policy for making sure validate / etc stays clean on all the platforms. There's enough variations that it might take an implausible amount of resources to test all the targets we want to support on every commit. (Eg given how long builds apparently take on certain platforms like arm, we'd need quite a few wee arm machines to test arm at every commit. Or maybe not?) Point being: I agree that support tooling to make sure builds don't stay broken and don't get broken aren't where it should be. And I agree that something like you describe should be done. I'm just wondering if we have the resources to do that correctly. On Tuesday, February 4, 2014, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: On 04/02/14 09:41, Joachim Breitner wrote: Hi, Am Dienstag, den 04.02.2014, 08:04 + schrieb Simon Peyton Jones: I want just to say thank you for thinking about this. We badly need better nightly-builds for GHC, on a variety of platforms a) to identify regressions, preferably to the actually commit that caused it, so Austin's big red message can go to the right person I believe we can do better, so that Austin’s big red message does not have to be written in the first place. Here is what I have in mind, and I’ll volunteer to implement it if people think it is a good idea and I get the resources/permissions: Proposal Nobody gets to push to master directly. Instead, every push to master is diverted¹ to a temporary branch validating/some id. One of our servers detects the appearance of such a branch and will * check it out, * validate it, * if ok: check if master can still be fast-forward’ed to it, * if yes: push to master. If it does not validate, or if master has changed in between, the branch will be moved to failed/some id, and a message is sent to the pushing developer², including a tail of the log and a link to the full log. Systems can fail, and maybe nothing validates anymore for reasons not easily fixable. For that case, a backdoor is available: Pushes to the branch master-unchecked will be moved to master, well, unchecked. Benefits: * It is guaranteed that master has validated at least once somewhere. I.e. no need to ask on the mailing list “does master validate for you right now?” * It is now ok to do changes that are “obviously correct” (comment changes, removing dead code, code reformatting) without having to validate manually, which _saves developer time_ (our most precious resource). Downsides: * When two commits are racing for master, one will be rejected for being a non-fast-forward commit. The user will then have to merge or rebase and try again. But: The same would be true if he was validating locally (unless he does not validate the merge/rebase, in which case we are again where we don’t want to be: Unvalidated versions in master.) Is this something you would what, or could live with? If it is technically feasible (given our hardware constraints, repository structure and git’s feature) is a different question, which needs to be discussed afterwards. Greetings, Joachim ¹ Might not be possible transparently (http://stackoverflow.com/questions/21362833), but for the sake of argument and workflow design, assume it was. ² As an approximation: The committer of the latest patch. PS: I’m also considering (but not pushing hard) for a stronger variant as follows. We do not need to discuss that now and should, if at all, start the with the proposal above. I’m just adding it to show where this is going ... Stronger proposal ~ Every commit in master needs to be validated! I tend to make sure that all patches on my branch validate individually (git rebase -i -x ./validate is a great tool here, you should use it! ). Contributors who do not want to go through that trouble should then use git merge --squash to produce a single commit from their branch. This would make the git history more useful for things like bitsecting. ___ ghc-devs mailing list ghc-devs@haskell.org javascript:; http://www.haskell.org/mailman/listinfo/ghc-devs You mention that it's enough for one machine to validate the patch. What if the change was for example to fix something on ARM (where builds take a long time) and has no effect on x86? The x86 machine is likely to come through first and give you the OK, pushing to master something that's effectively not checked. In fact, the fastest slave is likely to come through first every time and if it validates there (for example, I hear that 64-bit Linux is the golden platform for validate), it will be pushed to master. I think the proposal needs an enhancement: ability to specify which platform the commit needs to
RE: Pre-Master checks (Was: Nightlies)
I can see advantages here, similar to Richard. I'm just a bit worried about keeping all those branches straight in my head. Who names all these temporary branches? Does someone delete them so they don't accumulate and dominate the branch list? Would need careful documenting, so that new people know exactly what to do. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Joachim Breitner | Sent: 04 February 2014 09:42 | To: ghc-devs@haskell.org | Subject: Re: Pre-Master checks (Was: Nightlies) | | Hi, | | Am Dienstag, den 04.02.2014, 08:04 + schrieb Simon Peyton Jones: | I want just to say thank you for thinking about this. We badly need | better nightly-builds for GHC, on a variety of platforms | a) to identify regressions, preferably to the actually commit that | caused it, so Austin's big red message can go to the right person | | I believe we can do better, so that Austin’s big red message does not | have to be written in the first place. | | Here is what I have in mind, and I’ll volunteer to implement it if | people think it is a good idea and I get the resources/permissions: | | Proposal | | | Nobody gets to push to master directly. Instead, every push to master | is | diverted¹ to a temporary branch validating/some id. One of our | servers detects the appearance of such a branch and will | * check it out, | * validate it, | * if ok: check if master can still be fast-forward’ed to it, | * if yes: push to master. | | If it does not validate, or if master has changed in between, the | branch | will be moved to failed/some id, and a message is sent to the pushing | developer², including a tail of the log and a link to the full log. | | Systems can fail, and maybe nothing validates anymore for reasons not | easily fixable. For that case, a backdoor is available: Pushes to the | branch master-unchecked will be moved to master, well, unchecked. | | Benefits: | * It is guaranteed that master has validated at least once somewhere. |I.e. no need to ask on the mailing list “does master validate for | you |right now?” | * It is now ok to do changes that are “obviously correct” (comment |changes, removing dead code, code reformatting) without having |to validate manually, which _saves developer time_ (our most | precious |resource). | | Downsides: | * When two commits are racing for master, one will be rejected for |being a non-fast-forward commit. The user will then have to merge |or rebase and try again. |But: The same would be true if he was validating locally (unless he |does not validate the merge/rebase, in which case we are again where |we don’t want to be: Unvalidated versions in master.) | | | Is this something you would what, or could live with? | | If it is technically feasible (given our hardware constraints, | repository structure and git’s feature) is a different question, which | needs to be discussed afterwards. | | Greetings, | Joachim | | | | ¹ Might not be possible transparently | (http://stackoverflow.com/questions/21362833), but for the sake of | argument and workflow design, assume it was. | ² As an approximation: The committer of the latest patch. | | PS: I’m also considering (but not pushing hard) for a stronger variant | as follows. We do not need to discuss that now and should, if at all, | start the with the proposal above. I’m just adding it to show where | this | is going ... | | Stronger proposal | ~ | | Every commit in master needs to be validated! | I tend to make sure that all patches on my branch validate individually | (git rebase -i -x ./validate is a great tool here, you should use it! | ). Contributors who do not want to go through that trouble should then | use git merge --squash to produce a single commit from their branch. | | This would make the git history more useful for things like bitsecting. | | | | -- | Joachim Breitner | e-Mail: m...@joachim-breitner.de | Homepage: http://www.joachim-breitner.de | Jabber-ID: nome...@joachim-breitner.de ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
please elaborate on comment for base:Data.Type.Equality.(==)?
[CC'ing Richard, as I'm guessing he's the author of the comment.] I have a question regarding the comment on the type family Data.Type.Equality.(==). A poly-kinded instance [of ==] is *not* provided, as a recursive definition for algebraic kinds is generally more useful. Can someone elaborate on generally more useful. Thank you. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Pre-Master checks (Was: Nightlies)
one point in the design space (mind you one i'm not going to advocate) is the testing / merging workflow that the Mozilla folks are doing for rust. Every patch / pull request gets tested by their build bot before merging. Does make the commits on master look pretty mess / mergy though. mind you its a bit tightly coupled to github, but some of the ideas *might* be a good strawman. Likewise, how does eg LLVM/Clang manage its testing infrastructure? How does GCC manage it? On Tue, Feb 4, 2014 at 12:56 PM, Simon Peyton Jones simo...@microsoft.comwrote: I can see advantages here, similar to Richard. I'm just a bit worried about keeping all those branches straight in my head. Who names all these temporary branches? Does someone delete them so they don't accumulate and dominate the branch list? Would need careful documenting, so that new people know exactly what to do. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Joachim Breitner | Sent: 04 February 2014 09:42 | To: ghc-devs@haskell.org | Subject: Re: Pre-Master checks (Was: Nightlies) | | Hi, | | Am Dienstag, den 04.02.2014, 08:04 + schrieb Simon Peyton Jones: | I want just to say thank you for thinking about this. We badly need | better nightly-builds for GHC, on a variety of platforms | a) to identify regressions, preferably to the actually commit that | caused it, so Austin's big red message can go to the right person | | I believe we can do better, so that Austin’s big red message does not | have to be written in the first place. | | Here is what I have in mind, and I’ll volunteer to implement it if | people think it is a good idea and I get the resources/permissions: | | Proposal | | | Nobody gets to push to master directly. Instead, every push to master | is | diverted¹ to a temporary branch validating/some id. One of our | servers detects the appearance of such a branch and will | * check it out, | * validate it, | * if ok: check if master can still be fast-forward’ed to it, | * if yes: push to master. | | If it does not validate, or if master has changed in between, the | branch | will be moved to failed/some id, and a message is sent to the pushing | developer², including a tail of the log and a link to the full log. | | Systems can fail, and maybe nothing validates anymore for reasons not | easily fixable. For that case, a backdoor is available: Pushes to the | branch master-unchecked will be moved to master, well, unchecked. | | Benefits: | * It is guaranteed that master has validated at least once somewhere. |I.e. no need to ask on the mailing list “does master validate for | you |right now?” | * It is now ok to do changes that are “obviously correct” (comment |changes, removing dead code, code reformatting) without having |to validate manually, which _saves developer time_ (our most | precious |resource). | | Downsides: | * When two commits are racing for master, one will be rejected for |being a non-fast-forward commit. The user will then have to merge |or rebase and try again. |But: The same would be true if he was validating locally (unless he |does not validate the merge/rebase, in which case we are again where |we don’t want to be: Unvalidated versions in master.) | | | Is this something you would what, or could live with? | | If it is technically feasible (given our hardware constraints, | repository structure and git’s feature) is a different question, which | needs to be discussed afterwards. | | Greetings, | Joachim | | | | ¹ Might not be possible transparently | (http://stackoverflow.com/questions/21362833), but for the sake of | argument and workflow design, assume it was. | ² As an approximation: The committer of the latest patch. | | PS: I’m also considering (but not pushing hard) for a stronger variant | as follows. We do not need to discuss that now and should, if at all, | start the with the proposal above. I’m just adding it to show where | this | is going ... | | Stronger proposal | ~ | | Every commit in master needs to be validated! | I tend to make sure that all patches on my branch validate individually | (git rebase -i -x ./validate is a great tool here, you should use it! | ). Contributors who do not want to go through that trouble should then | use git merge --squash to produce a single commit from their branch. | | This would make the git history more useful for things like bitsecting. | | | | -- | Joachim Breitner | e-Mail: m...@joachim-breitner.de | Homepage: http://www.joachim-breitner.de | Jabber-ID: nome...@joachim-breitner.de ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list
Re: please elaborate on comment for base:Data.Type.Equality.(==)?
Say I have data Nat = Zero | Succ Nat data SNat :: Nat - * where SZero :: SNat Zero SSucc :: SNat n - SNat (Succ n) data SBool :: Bool - * where SFalse :: SBool False STrue :: SBool True Now, I want eq :: SNat a - SNat b- SBool (a == b) eq SZero SZero = STrue eq (SSucc _) SZero = SFalse eq SZero (SSucc _) = SFalse eq (SSucc c) (SSucc d) = eq c d Does that type check? Suppose we have type family EqPoly (a :: k) (b :: k) :: Bool where EqPoly a a = True EqPoly a b = False type instance a == b = EqPoly a b (Let's forget that the instance there would overlap with any other instance.) Now, in the last line of `eq`, we have that the type of `eq c d` is `SBool (e == f)` where (c :: SNat e), (d :: SNat f), (a ~ Succ e), and (b ~ Succ f). But, does ((e == f) ~ (a == b))? It would need to for the last line of `eq` to type-check. Alas, there is no way to proof ((e == f) ~ (a == b)), so we're hosed. Now, suppose type family EqNat a b where EqNat Zero Zero = True EqNat (Succ n) (Succ m) = EqNat n m EqNat Zero (Succ n) = False EqNat (Succ n) Zero = False type instance a == b = EqNat a b Here, we know that (a ~ Succ e) and (b ~ Succ f), so we compute that (a == b) ~ (EqNat (Succ e) (Succ f)) ~ (EqNat e f) ~ (e == f). Huzzah! Thus, the second version is better. I hope this helps! Richard On Feb 4, 2014, at 1:08 PM, Nicolas Frisby nicolas.fri...@gmail.com wrote: [CC'ing Richard, as I'm guessing he's the author of the comment.] I have a question regarding the comment on the type family Data.Type.Equality.(==). A poly-kinded instance [of ==] is not provided, as a recursive definition for algebraic kinds is generally more useful. Can someone elaborate on generally more useful. Thank you. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: please elaborate on comment for base:Data.Type.Equality.(==)?
Great. Thanks. This reminds me of one emphasis of McBride's lectures and keynotes regarding Agda: it's generally a Good Thing for the shape of your type level recursion to match your value level recursion. On Feb 4, 2014 1:20 PM, Richard Eisenberg e...@cis.upenn.edu wrote: Say I have data Nat = Zero | Succ Nat data SNat :: Nat - * where SZero :: SNat Zero SSucc :: SNat n - SNat (Succ n) data SBool :: Bool - * where SFalse :: SBool False STrue :: SBool True Now, I want eq :: SNat a - SNat b- SBool (a == b) eq SZero SZero = STrue eq (SSucc _) SZero = SFalse eq SZero (SSucc _) = SFalse eq (SSucc c) (SSucc d) = eq c d Does that type check? Suppose we have type family EqPoly (a :: k) (b :: k) :: Bool where EqPoly a a = True EqPoly a b = False type instance a == b = EqPoly a b (Let's forget that the instance there would overlap with any other instance.) Now, in the last line of `eq`, we have that the type of `eq c d` is `SBool (e == f)` where (c :: SNat e), (d :: SNat f), (a ~ Succ e), and (b ~ Succ f). But, does ((e == f) ~ (a == b))? It would need to for the last line of `eq` to type-check. Alas, there is no way to proof ((e == f) ~ (a == b)), so we're hosed. Now, suppose type family EqNat a b where EqNat Zero Zero = True EqNat (Succ n) (Succ m) = EqNat n m EqNat Zero (Succ n) = False EqNat (Succ n) Zero = False type instance a == b = EqNat a b Here, we know that (a ~ Succ e) and (b ~ Succ f), so we compute that (a == b) ~ (EqNat (Succ e) (Succ f)) ~ (EqNat e f) ~ (e == f). Huzzah! Thus, the second version is better. I hope this helps! Richard On Feb 4, 2014, at 1:08 PM, Nicolas Frisby nicolas.fri...@gmail.com wrote: [CC'ing Richard, as I'm guessing he's the author of the comment.] I have a question regarding the comment on the type family Data.Type.Equality.(==). A poly-kinded instance [of ==] is *not* provided, as a recursive definition for algebraic kinds is generally more useful. Can someone elaborate on generally more useful. Thank you. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Summarize #7602
I know that #7602 has been mentioned as a final loose end in the RC. I was wondering if someone in the know could summarize its status in regards to how it effects GHC users. Feel free to be blisteringly brief... ;-) I'm just looking for things like: this is a non-issue on modern OS X/Clang or it'll be fixed soon just be patient or we've done our part, this is Apple's problem now. I gave the trac thread a read-through, but there seems to be several degrees of flexibility/workarounds, so I'm still not sure if this is something I should worry about on my OS X machine. Thanks for your cycles! Andrew ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Summarize #7602
TL;DR OS X suffers a performance hit when build with llvm-gcc/clang. The binary builds are built this way. The fix I outlined in the ticket (a fast `pthread_getspecific`/`pthread_setspecific`) could still work to recover most of the performance, but Apple accidentally messed up the Mavericks source code release, so I'm not sure if anything regarding the pthread implementation has changed. If it hasn't, then I think it should be reasonably easy to fix with some testing. (The ticket is a bit of a long and dry read I'm afraid.) On Tue, Feb 4, 2014 at 3:22 PM, Andrew Farmer afar...@ittc.ku.edu wrote: I know that #7602 has been mentioned as a final loose end in the RC. I was wondering if someone in the know could summarize its status in regards to how it effects GHC users. Feel free to be blisteringly brief... ;-) I'm just looking for things like: this is a non-issue on modern OS X/Clang or it'll be fixed soon just be patient or we've done our part, this is Apple's problem now. I gave the trac thread a read-through, but there seems to be several degrees of flexibility/workarounds, so I'm still not sure if this is something I should worry about on my OS X machine. Thanks for your cycles! Andrew ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Pre-Master checks (Was: Nightlies)
On 2/4/14, Carter Schonwald carter.schonw...@gmail.com wrote: one point in the design space (mind you one i'm not going to advocate) is the testing / merging workflow that the Mozilla folks are doing for rust. Every patch / pull request gets tested by their build bot before merging. Does make the commits on master look pretty mess / mergy though. mind you its a bit tightly coupled to github, but some of the ideas *might* be a good strawman. Likewise, how does eg LLVM/Clang manage its testing infrastructure? How does GCC manage it? LLVM devs need to run 'make check' before committing to the repo. This runs 8000+ tests in about 30 seconds. Then there is the bot infrastructure at http://lab.llvm.org:8011/console , and who breaks a target is alerted by mail. But this applies to all committers whose changes entered into (slow) builds. It is not commit-exact, though better on the fast bots. Cheers, Gabor On Tue, Feb 4, 2014 at 12:56 PM, Simon Peyton Jones simo...@microsoft.comwrote: I can see advantages here, similar to Richard. I'm just a bit worried about keeping all those branches straight in my head. Who names all these temporary branches? Does someone delete them so they don't accumulate and dominate the branch list? Would need careful documenting, so that new people know exactly what to do. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Joachim Breitner | Sent: 04 February 2014 09:42 | To: ghc-devs@haskell.org | Subject: Re: Pre-Master checks (Was: Nightlies) | | Hi, | | Am Dienstag, den 04.02.2014, 08:04 + schrieb Simon Peyton Jones: | I want just to say thank you for thinking about this. We badly need | better nightly-builds for GHC, on a variety of platforms | a) to identify regressions, preferably to the actually commit that | caused it, so Austin's big red message can go to the right person | | I believe we can do better, so that Austin's big red message does not | have to be written in the first place. | | Here is what I have in mind, and I'll volunteer to implement it if | people think it is a good idea and I get the resources/permissions: | | Proposal | | | Nobody gets to push to master directly. Instead, every push to master | is | diverted¹ to a temporary branch validating/some id. One of our | servers detects the appearance of such a branch and will | * check it out, | * validate it, | * if ok: check if master can still be fast-forward'ed to it, | * if yes: push to master. | | If it does not validate, or if master has changed in between, the | branch | will be moved to failed/some id, and a message is sent to the pushing | developer², including a tail of the log and a link to the full log. | | Systems can fail, and maybe nothing validates anymore for reasons not | easily fixable. For that case, a backdoor is available: Pushes to the | branch master-unchecked will be moved to master, well, unchecked. | | Benefits: | * It is guaranteed that master has validated at least once somewhere. |I.e. no need to ask on the mailing list does master validate for | you |right now? | * It is now ok to do changes that are obviously correct (comment |changes, removing dead code, code reformatting) without having |to validate manually, which _saves developer time_ (our most | precious |resource). | | Downsides: | * When two commits are racing for master, one will be rejected for |being a non-fast-forward commit. The user will then have to merge |or rebase and try again. |But: The same would be true if he was validating locally (unless he |does not validate the merge/rebase, in which case we are again where |we don't want to be: Unvalidated versions in master.) | | | Is this something you would what, or could live with? | | If it is technically feasible (given our hardware constraints, | repository structure and git's feature) is a different question, which | needs to be discussed afterwards. | | Greetings, | Joachim | | | | ¹ Might not be possible transparently | (http://stackoverflow.com/questions/21362833), but for the sake of | argument and workflow design, assume it was. | ² As an approximation: The committer of the latest patch. | | PS: I'm also considering (but not pushing hard) for a stronger variant | as follows. We do not need to discuss that now and should, if at all, | start the with the proposal above. I'm just adding it to show where | this | is going ... | | Stronger proposal | ~ | | Every commit in master needs to be validated! | I tend to make sure that all patches on my branch validate individually | (git rebase -i -x ./validate is a great tool here, you should use it! | ). Contributors who do not want to go through that trouble should then | use git merge --squash to produce a single commit from their branch. | | This
Re: Summarize #7602
@Andrew, if you have GHC built with a real GCC, theres no perf issue. (though if you built GHC with clang, thereis) I've a bindist thats from the 7.8 branch from 5 days ago that I built wiht GCC-4.8 here https://github.com/cartazio/ghc/releases/tag/carters-build-7.8-preRC1 you may need to patch the settings file to point to your own GCC version point being, no issue if you built with GCC. :) On Tue, Feb 4, 2014 at 4:31 PM, Austin Seipp aus...@well-typed.com wrote: TL;DR OS X suffers a performance hit when build with llvm-gcc/clang. The binary builds are built this way. The fix I outlined in the ticket (a fast `pthread_getspecific`/`pthread_setspecific`) could still work to recover most of the performance, but Apple accidentally messed up the Mavericks source code release, so I'm not sure if anything regarding the pthread implementation has changed. If it hasn't, then I think it should be reasonably easy to fix with some testing. (The ticket is a bit of a long and dry read I'm afraid.) On Tue, Feb 4, 2014 at 3:22 PM, Andrew Farmer afar...@ittc.ku.edu wrote: I know that #7602 has been mentioned as a final loose end in the RC. I was wondering if someone in the know could summarize its status in regards to how it effects GHC users. Feel free to be blisteringly brief... ;-) I'm just looking for things like: this is a non-issue on modern OS X/Clang or it'll be fixed soon just be patient or we've done our part, this is Apple's problem now. I gave the trac thread a read-through, but there seems to be several degrees of flexibility/workarounds, so I'm still not sure if this is something I should worry about on my OS X machine. Thanks for your cycles! Andrew ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
GHC iOS make binary-dist
Hi folks, I'm all set to release binaries for GHC iOS (arm and i386 simulator), but didn't realize the make binary-dist machinery is broken for cross-compilers. I'm starting work on it but will be fumbling in the dark a bit so if anyone has any knowledge or link or ideas on where to look, I'd love to hear them! Here's the output of make binary-dist on a tree after a successful make for arm-apple-darwin10 (which will make install perfectly). http://lpaste.net/99475 Cheers Luke ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Cabal release for 7.8
On Mon, Feb 3, 2014 at 11:21 PM, Herbert Valerio Riedel
hvrie...@gmail.comwrote:
On 2014-02-04 at 06:10:24 +0100, Johan Tibell wrote:
I guess we need one last cabal release for 7.8? Are we ready for that
now,
or do you expect any more 7.8 change that will require cabal changes?
The RC1 has just started, and I'd rather wait a little more till we're
closer to a final release...
PS: We'll also need a 'cabal-install' release, as the current 1.18.0.2
doesn't build with GHC 7.8RC1
I will make one as soon as the last Cabal release is out. Please let me
know when you're ready for that.
PS2: would it be possible to have
https://github.com/haskell/cabal/commit/32dddcb1f0495a633ab806e0bcd43816cac67b03
picked up for 1.18 (assuming it applies cleanly)? It would make it
easier to generate documentation tarballs for uploading to Hackage
w/o needing to 'sed' away all 'file:///' prefixes.
This is already in the 1.18 branch as
1eb2181fae2b706ee8024d3f8fef104b5089b1a9. I intend to release the following
in the last patch release in the 1.18 series:
0d5ffeb91075739246627da17bda945aedc6a427 Disable
TemplateHaskell/{dynamic,profiling} tests on Travis.
ee6d1cf5cefe18f6d74ed379af21d92f8b0ae92d Don't use -dylib-install-name on
OS X with GHC 7.8.
e97aa58f68519db54de1c62339459ebb88aed069 Add some more OS aliases.
1eb2181fae2b706ee8024d3f8fef104b5089b1a9 Fix the haddock --html-location=
for relative URLs
43f1e2a5a81688eb186102c684bb4d134ca3c63a Add CPP pragma to D.Simple.Setup
8aea1f994c526f0f43ac5b1b29b04e9ab4565b01 Bump Cabal version number to
1.18.1.3.
cb0ad7a77457ef77c34ab4b6d54e2bdc5a972fa1 Default 'library-for-ghci' to True
on Windows.
345650535993522a0fd75a53a4c681c5d3027030 Small warning.
8d168c5fbbcd01ce0c5ff3d9c4a959b4c0819746 Documentation fix.
e93b01dfb34ab1de6fbfaec1b5805eddbb8a46f5
s/extra-html-files/extra-doc-files/.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC iOS make binary-dist
OK, I've made a bit of progress here. Again, I have very little understanding of the binary-dist system so I hope this isn't nonsense. The utils/ghc-cabal/dist-install/build/tmp/ghc-cabal and utils/ghc-pwd/dist-install/build/tmp/ghc-pwd executables have .a extensions, which is a bug, but more importantly are built for arm and thus can't be used. lukexi@thopminkingscape:~/Code/ghc (ghc-7.8 *=)$ file utils/ghc-cabal/dist-install/build/tmp/ghc-cabal.a utils/ghc-cabal/dist-install/build/tmp/ghc-cabal.a: Mach-O executable arm lukexi@thopminkingscape:~/Code/ghc (ghc-7.8 *=)$ file utils/ghc-pwd/dist-install/build/tmp/ghc-pwd.a utils/ghc-pwd/dist-install/build/tmp/ghc-pwd.a: Mach-O executable arm So I tried switching them to the inplace/bin/ghc-cabal and utils/ghc-pwd/dist-boot/ghc-pwd copies, respectively, with this patch: http://lpaste.net/99485 This let me build the .tar.gz without errors, and ./configure it fine, but make install fails here now. inplace/bin/ghc-cabal register libraries/ghc-prim dist-install /usr/local/lib/arm-apple-darwin10ghc-7.8.20140129/bin/ghc /usr/local/lib/arm-apple-darwin10ghc-7.8.20140129/bin/ghc-pkg /usr/local/lib/arm-apple-darwin10ghc-7.8.20140129 '' '/usr/local' '/usr/local/lib/arm-apple-darwin10ghc-7.8.20140129' '/usr/local/share/doc/ghc/html/libraries' NO ghc-cabal: Bad interface file: dist-install/build/GHC/CString.hi magic number mismatch: old/corrupt interface file? (wanted 33214052, got 129742) http://lpaste.net/99486 (looks like a missing dash in the CrossCompilePrefix as well but that's a minor issue) Does this offer any clues? Cheers Luke On Tue, Feb 4, 2014 at 6:22 PM, Luke Iannini lukex...@gmail.com wrote: Hi folks, I'm all set to release binaries for GHC iOS (arm and i386 simulator), but didn't realize the make binary-dist machinery is broken for cross-compilers. I'm starting work on it but will be fumbling in the dark a bit so if anyone has any knowledge or link or ideas on where to look, I'd love to hear them! Here's the output of make binary-dist on a tree after a successful make for arm-apple-darwin10 (which will make install perfectly). http://lpaste.net/99475 Cheers Luke ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC iOS make binary-dist
Aha. Looks like the target word size is incorrect in the binary-dist version. Here's arm-apple-darwin10ghc --info (i.e., the binary-dist version) http://lpaste.net/99489 and here's arm-apple-darwin10-ghc --info (from a working 'make install'ed version) http://lpaste.net/99490 A bad settings file, I guess. I'll see if I can fix that... Cheers Luke On Tue, Feb 4, 2014 at 8:59 PM, Luke Iannini lukex...@gmail.com wrote: OK, I've made a bit of progress here. Again, I have very little understanding of the binary-dist system so I hope this isn't nonsense. The utils/ghc-cabal/dist-install/build/tmp/ghc-cabal and utils/ghc-pwd/dist-install/build/tmp/ghc-pwd executables have .a extensions, which is a bug, but more importantly are built for arm and thus can't be used. lukexi@thopminkingscape:~/Code/ghc (ghc-7.8 *=)$ file utils/ghc-cabal/dist-install/build/tmp/ghc-cabal.a utils/ghc-cabal/dist-install/build/tmp/ghc-cabal.a: Mach-O executable arm lukexi@thopminkingscape:~/Code/ghc (ghc-7.8 *=)$ file utils/ghc-pwd/dist-install/build/tmp/ghc-pwd.a utils/ghc-pwd/dist-install/build/tmp/ghc-pwd.a: Mach-O executable arm So I tried switching them to the inplace/bin/ghc-cabal and utils/ghc-pwd/dist-boot/ghc-pwd copies, respectively, with this patch: http://lpaste.net/99485 This let me build the .tar.gz without errors, and ./configure it fine, but make install fails here now. inplace/bin/ghc-cabal register libraries/ghc-prim dist-install /usr/local/lib/arm-apple-darwin10ghc-7.8.20140129/bin/ghc /usr/local/lib/arm-apple-darwin10ghc-7.8.20140129/bin/ghc-pkg /usr/local/lib/arm-apple-darwin10ghc-7.8.20140129 '' '/usr/local' '/usr/local/lib/arm-apple-darwin10ghc-7.8.20140129' '/usr/local/share/doc/ghc/html/libraries' NO ghc-cabal: Bad interface file: dist-install/build/GHC/CString.hi magic number mismatch: old/corrupt interface file? (wanted 33214052, got 129742) http://lpaste.net/99486 (looks like a missing dash in the CrossCompilePrefix as well but that's a minor issue) Does this offer any clues? Cheers Luke On Tue, Feb 4, 2014 at 6:22 PM, Luke Iannini lukex...@gmail.com wrote: Hi folks, I'm all set to release binaries for GHC iOS (arm and i386 simulator), but didn't realize the make binary-dist machinery is broken for cross-compilers. I'm starting work on it but will be fumbling in the dark a bit so if anyone has any knowledge or link or ideas on where to look, I'd love to hear them! Here's the output of make binary-dist on a tree after a successful make for arm-apple-darwin10 (which will make install perfectly). http://lpaste.net/99475 Cheers Luke ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC iOS make binary-dist
After fixing that, and the prefix missing a -, I've got a working make install! Hurray! I'll tidy this up and make a patch. Cheers Luke On Tue, Feb 4, 2014 at 9:24 PM, Luke Iannini lukex...@gmail.com wrote: Aha. Looks like the target word size is incorrect in the binary-dist version. Here's arm-apple-darwin10ghc --info (i.e., the binary-dist version) http://lpaste.net/99489 and here's arm-apple-darwin10-ghc --info (from a working 'make install'ed version) http://lpaste.net/99490 A bad settings file, I guess. I'll see if I can fix that... Cheers Luke On Tue, Feb 4, 2014 at 8:59 PM, Luke Iannini lukex...@gmail.com wrote: OK, I've made a bit of progress here. Again, I have very little understanding of the binary-dist system so I hope this isn't nonsense. The utils/ghc-cabal/dist-install/build/tmp/ghc-cabal and utils/ghc-pwd/dist-install/build/tmp/ghc-pwd executables have .a extensions, which is a bug, but more importantly are built for arm and thus can't be used. lukexi@thopminkingscape:~/Code/ghc (ghc-7.8 *=)$ file utils/ghc-cabal/dist-install/build/tmp/ghc-cabal.a utils/ghc-cabal/dist-install/build/tmp/ghc-cabal.a: Mach-O executable arm lukexi@thopminkingscape:~/Code/ghc (ghc-7.8 *=)$ file utils/ghc-pwd/dist-install/build/tmp/ghc-pwd.a utils/ghc-pwd/dist-install/build/tmp/ghc-pwd.a: Mach-O executable arm So I tried switching them to the inplace/bin/ghc-cabal and utils/ghc-pwd/dist-boot/ghc-pwd copies, respectively, with this patch: http://lpaste.net/99485 This let me build the .tar.gz without errors, and ./configure it fine, but make install fails here now. inplace/bin/ghc-cabal register libraries/ghc-prim dist-install /usr/local/lib/arm-apple-darwin10ghc-7.8.20140129/bin/ghc /usr/local/lib/arm-apple-darwin10ghc-7.8.20140129/bin/ghc-pkg /usr/local/lib/arm-apple-darwin10ghc-7.8.20140129 '' '/usr/local' '/usr/local/lib/arm-apple-darwin10ghc-7.8.20140129' '/usr/local/share/doc/ghc/html/libraries' NO ghc-cabal: Bad interface file: dist-install/build/GHC/CString.hi magic number mismatch: old/corrupt interface file? (wanted 33214052, got 129742) http://lpaste.net/99486 (looks like a missing dash in the CrossCompilePrefix as well but that's a minor issue) Does this offer any clues? Cheers Luke On Tue, Feb 4, 2014 at 6:22 PM, Luke Iannini lukex...@gmail.com wrote: Hi folks, I'm all set to release binaries for GHC iOS (arm and i386 simulator), but didn't realize the make binary-dist machinery is broken for cross-compilers. I'm starting work on it but will be fumbling in the dark a bit so if anyone has any knowledge or link or ideas on where to look, I'd love to hear them! Here's the output of make binary-dist on a tree after a successful make for arm-apple-darwin10 (which will make install perfectly). http://lpaste.net/99475 Cheers Luke ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
ghc-ios 7.8 working build
Hi all, I believe I've worked around the issues with make binary-dist and cross-compilation. This should be a working binary for iOS devices https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc1-device/ghc-7.8.20140129-arm-apple-ios.tar.bz2 Please try ./configure make install (it should live happily next to your current ghc as arm-apple-darwin10-ghc) and let me know so we can have a build ready for 7.8 RC2! Cheers Luke ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
