7.8 branch is created, HEAD is now open, and a note on merges
Hello all, I've just created the 7.8 branch after tying off some of the final loose ends. In its current state, I expect the branch as it is now to become RC1 within the day. I plan on starting builds for the following soon: - OS X 10.7 and OS X 10.9 - Linux i386/amd64 (likely based on Debian Wheezey) - Windows i386/amd64 (many thanks to Kyrill Briantsev for the heroic last-minute linker fixes!) I'll send a (GPG-signed) email containing SHA1 hashes when they're done. Two systems I won't make builds for RC1 by default (but could be persuaded to if nobody else does, and people want it): - Older glibc-2.5 based systems (e.g. CentOS, - a few users have talked about this wrt binary releases, where I don't think GHC works.) - FreeBSD - Pali, if you'd like to do this, feel free, and let me know. This means I'll (mostly) be waiting around today, so feel free to shoot questions. As of now, this means HEAD is now version 7.9, and you're free to push wacky experiments or changes now, if you've been holding off. You'll probably want to clean your whole tree, since this means the interface file versions etc will change. Finally, we picked up a good amount of new committers this year, so let's remind people of the merging policy: what happens if you need to merge something you did to the 7.8 branch? There are two main avenues for this to happen: * Someone reports a bug against the 7.8 RC on Trac. You decide to fix it and do so. Now what? 1) Please commit the bug to master, and confirm it's a fix. 2) Go to the bug, and instead of closing it, change the ticket status to 'merge'. 3) I will cherry-pick it over to the 7.8 branch for you - nothing else needed. * There's not a recorded bug, but you do push a change, and you think it should be merged (maybe a typo or something.) In this case, I'd ask you please CC me on the email sent to ghc-comm...@haskell.org which is related to your commit, and just say Please merge or somesuch. I'll come over the commits with such a response. This goes for all changes - submodule updates, typos, real fixes, etc. It's likely me and Herbert will restrict the Gitolite permissions to only allow the two of us to touch the ghc-7.8 branch. So it's really important you put us in the loop, ASAP. If you don't do one of these two things, it's highly likely I will miss it, and not merge it. If you have questions, please ask me or Herbert. If there's a merge conflict, we can discuss it. Thanks -- 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
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
Unit tests for GHC code?
Hi,
I am currently working on a piece of code (an analysis to solve #7994)
where I’d like to make sure that my changes do not regress over what I
had before. But I find it unnecessarily hard to write our usual
test-case styles for them:
* I’d like to test against very small Core that does not involve
anything unnecessary. But it is hard to write Haskell that has,
when it hits my analysis, this shape. It requires lots of {-#
NOINLINE #-} and other tricks.
* To test the result, I either have to write a performance test,
but it is not always easy to come up with a program where the
gains are massive enough to become a reliable test. It is
possible, but work, and doing it maybe half a dozen times for
various inputs is tricky.
* Alternative, I can dump the Core and add that to the test cases.
But now other changes to the compiler can easily trigger my test
case failing.
So I thought about writing a test case that simply imports my module
from the ghc library, generates artificial, minimal core, and checks the
output for precisely what I want (in my case, some fields of the IdInfo
of various binders).
I don’t see any examples for that in the test suite. Is that just
because noone has done that before, or is there inherently bad about
this approach that we do _not_ want to that?
Also, we don’t have a parser for Core, so I’ll have to build my syntax
trees using the stuff from MkCore et al, right?
Thanks,
Joachim
--
Joachim “nomeata” Breitner
m...@joachim-breitner.de • http://www.joachim-breitner.de/
Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C
Debian Developer: nome...@debian.org
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: 7.8 branch is created, HEAD is now open, and a note on merges
On Wed, Jan 29, 2014 at 10:49 AM, Austin Seipp aus...@well-typed.com wrote: Two systems I won't make builds for RC1 by default (but could be persuaded to if nobody else does, and people want it): [..] - FreeBSD - Pali, if you'd like to do this, feel free, and let me know. Sure, I can do it. This means I'll (mostly) be waiting around today, so feel free to shoot questions. I guess it would useful to know exactly which version to build. That is, is it enough to do release builds (by setting RELEASE to yes) with the HEAD of the ghc-7.8 branch (of today)...? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.8 branch is created, HEAD is now open, and a note on merges
Thanks! I'll follow up with you shortly. My plan was actually to create a fingerprint of the repository, so you can just checkout a tree, use the fingerprint, and build the RC from that. The setup would just be a default perf build (i.e. no custom build.mk at all, just a regular boot+configure+make+binary-dist.) Right now I'm going over a few final touch-ups with Herbert before I start building everything (we might cherry-pick one or two minor things to base here momentarily.) After that I'll fingerprint and send it out. Also, for RCs, I believe we traditionally keep RELEASE=NO, so the version number doesn't come off as 7.8 but as 7.8.date instead - indicative of it being not the final version. So you shouldn't need to tweak anything - just use the fingerprint and build. On Wed, Jan 29, 2014 at 6:47 AM, Páli Gábor János pali.ga...@gmail.com wrote: On Wed, Jan 29, 2014 at 10:49 AM, Austin Seipp aus...@well-typed.com wrote: Two systems I won't make builds for RC1 by default (but could be persuaded to if nobody else does, and people want it): [..] - FreeBSD - Pali, if you'd like to do this, feel free, and let me know. Sure, I can do it. This means I'll (mostly) be waiting around today, so feel free to shoot questions. I guess it would useful to know exactly which version to build. That is, is it enough to do release builds (by setting RELEASE to yes) with the HEAD of the ghc-7.8 branch (of today)...? -- 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: 7.8 branch is created, HEAD is now open, and a note on merges
Austin, Blargh, I'll fix this shortly. Thanks Pali. Please do. I also hit upon this bug. I could build GHC head yesterday but not today. P.S. Even if this is fixed, validate does not work on my Mac recently due to a haddock problem of the xhtml library. Does anyone see this problem? --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.8 branch is created, HEAD is now open, and a note on merges
Hi Mateusz, I'll try building now. What's the error? Not building but validate. validate stops due to an error from haddock in the xhtml library. --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.8 branch is created, HEAD is now open, and a note on merges
Also sending to the list. --- Kazu, I fixed the __GLASGOW_HASKELL__ check on both HEAD and the 7.8 branch. As for the bug you are talking of - yes, I made a release note about this the other day. The problem is that due to a bad interaction with Clang, somehow the module downsweep gets broken in an odd way (presumably due to something being preprocessed incorrectly.) This does not affect every library actually - but xhtml is one of them (for example, 'text' works fine on Mavericks using Clang.) I also haven't yet pinned down why for example GHC is fine, but Haddock is not (considering they should mostly do the same thing.) Unfortunately I do not have any more time to fix this, because keeping the RC delayed continuously has a cost (and it's been delayed a lot.) I will reapproach this problem shortly after the first RC is done as it will undoubtly cause some issues. But I just don't have time at this exact moment to fix it (which may end up in integrating cpphs into GHC. I'm not sure yet.) For the record, this error occurs fairly late in the ./validate script - it's for testing the in-place binary distribution after a build, but before the testsuite is run. In the mean time, you can just do 'cd testsuite make fast' to run all your tests after you have seen this error. I simply do not have a sensible, easy fix right now. I sincerely apologize since this is annoying. But I really am out of time right now and I think we'll have to eat this one for the RC. (I should also note that, in the Real World, this will only make a difference in documentation building, not package installation. The xhtml library actually installs just fine - it is the doc generation which fails.) On Wed, Jan 29, 2014 at 8:04 AM, Kazu Yamamoto k...@iij.ad.jp wrote: Austin, Blargh, I'll fix this shortly. Thanks Pali. Please do. I also hit upon this bug. I could build GHC head yesterday but not today. P.S. Even if this is fixed, validate does not work on my Mac recently due to a haddock problem of the xhtml library. Does anyone see this problem? --Kazu ___ 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: Unit tests for GHC code?
Let me take a different slice at this question, inspired more by Joachim's
subject line than his text: On a number of occasions I've wanted to write unit
tests against a certain function or set of functions. The role inference
algorithm is a prime example, but it's happened elsewhere, too. The testsuite
only performs end-to-end testing. Sometimes it's easy/possible to build a test
that gets at what I want, but sometimes it's very hard. (Case in point: I
revised the varSetElemsKvsFirst function on a branch -- it's really hard to
test that thoroughly in an end-to-end test!)
So, is there a way / does someone know how to make a way to do proper unit
testing? The ability to do such tests is treated as a key virtue of (pure)
functional programming, and yet we don't do it! :)
For my varSetElemsKvsFirst problem, I ended up copying the code to a new file,
writing dummy data structures to get it to compile, and then ran unit tests. I
fixed my bug, but there was no way to integrate the testing work into a
regression test, sadly.
Any thoughts?
Thanks,
Richard
On Jan 29, 2014, at 4:58 AM, Joachim Breitner m...@joachim-breitner.de wrote:
Hi,
I am currently working on a piece of code (an analysis to solve #7994)
where I’d like to make sure that my changes do not regress over what I
had before. But I find it unnecessarily hard to write our usual
test-case styles for them:
* I’d like to test against very small Core that does not involve
anything unnecessary. But it is hard to write Haskell that has,
when it hits my analysis, this shape. It requires lots of {-#
NOINLINE #-} and other tricks.
* To test the result, I either have to write a performance test,
but it is not always easy to come up with a program where the
gains are massive enough to become a reliable test. It is
possible, but work, and doing it maybe half a dozen times for
various inputs is tricky.
* Alternative, I can dump the Core and add that to the test cases.
But now other changes to the compiler can easily trigger my test
case failing.
So I thought about writing a test case that simply imports my module
from the ghc library, generates artificial, minimal core, and checks the
output for precisely what I want (in my case, some fields of the IdInfo
of various binders).
I don’t see any examples for that in the test suite. Is that just
because noone has done that before, or is there inherently bad about
this approach that we do _not_ want to that?
Also, we don’t have a parser for Core, so I’ll have to build my syntax
trees using the stuff from MkCore et al, right?
Thanks,
Joachim
--
Joachim “nomeata” Breitner
m...@joachim-breitner.de • http://www.joachim-breitner.de/
Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C
Debian Developer: nome...@debian.org
___
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: Unit tests for GHC code?
Hi, Am Mittwoch, den 29.01.2014, 10:12 -0500 schrieb Richard Eisenberg: So, is there a way / does someone know how to make a way to do proper unit testing? The ability to do such tests is treated as a key virtue of (pure) functional programming, and yet we don't do it! :) I’m now doing this: http://git.haskell.org/ghc.git/commitdiff/aa970ca1e81118bbf37386b8833a01a3791cee62 (Patch “Add a unit test for CallArity” on branch wip/T7994, in case the hash id is invalid later) which I believe is okaish. Greetings, Joachim PS: I’m subscribed to the list, no need to send a copy to my private address. -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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
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
Re: GHC boot-library package changelogs release-notes
Hi Herbert, So who should add to the changelog? If I'm committing a new feature to the base library, should my commit include a small addition to the changelog describing my change? Good idea btw! :) Best, Arash On 2014-01-29 17:32, Herbert Valerio Riedel wrote: 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: GHC boot-library package changelogs release-notes
Hello Arash, On 2014-01-29 at 18:21:05 +0100, Arash Rouhani wrote: So who should add to the changelog? If I'm committing a new feature to the base library, should my commit include a small addition to the changelog describing my change? If you deem your modification release-note-worthy, then yes. The idea is to keep the code-change and the changelog modification more localized to each other. With the current scheme, you have to make two commits, as the the release-notes file is usually in a different repository. Cheers, hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.8 branch is created, HEAD is now open, and a note on merges
Hi Austin, all, FYI: I'm building GHC iOS binaries for RC1 right now. It would be awesome to release them along side if possible! Cheers Luke On Wed, Jan 29, 2014 at 6:28 AM, Kazu Yamamoto k...@iij.ad.jp wrote: Austin, For the record, this error occurs fairly late in the ./validate script - it's for testing the in-place binary distribution after a build, but before the testsuite is run. In the mean time, you can just do 'cd testsuite make fast' to run all your tests after you have seen this error. I simply do not have a sensible, easy fix right now. OK. I understand. P.S. I obtained Mac pro. Building and validating GHC on Mac pro are very quick. So, if necessary, please feel free to ask me to check building or validating GHC on Mac anytime. --Kazu ___ 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: 7.8 branch is created, HEAD is now open, and a note on merges
That is great Luke, I hope your work gets rolled into 7.8. Is this just experimental, or is it possible to actually develop an app that will pass Apple's QA and can be hosted on the app store? Are there any examples currently hosted on the App Store? Thanks, Dominick On Wed, Jan 29, 2014 at 4:26 PM, Luke Iannini lukex...@gmail.com wrote: Hi Austin, all, FYI: I'm building GHC iOS binaries for RC1 right now. It would be awesome to release them along side if possible! Cheers Luke On Wed, Jan 29, 2014 at 6:28 AM, Kazu Yamamoto k...@iij.ad.jp wrote: Austin, For the record, this error occurs fairly late in the ./validate script - it's for testing the in-place binary distribution after a build, but before the testsuite is run. In the mean time, you can just do 'cd testsuite make fast' to run all your tests after you have seen this error. I simply do not have a sensible, easy fix right now. OK. I understand. P.S. I obtained Mac pro. Building and validating GHC on Mac pro are very quick. So, if necessary, please feel free to ask me to check building or validating GHC on Mac anytime. --Kazu ___ 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-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Pattern synonyms for 7.8?
On 05/01/14 12:16, Dr. ERDI Gergo wrote: Hi, When I started working on pattern synonyms (#5144) back in August, it seemed the GHC 7.8 freeze was imminent, so I was planning for a first version in 7.10/8.0 (whatever it will be called). However, since not much has happened re: 7.8 since then (at least not much publicly visible), and on the other hand, my implementation of pattern synonyms is ready, I am now starting to wonder if it could be squeezed into 7.8. What are your thoughts on this? Thanks, Gergo ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs Hi again, We've ran into some trouble over at #ghc regarding Haddock updates to do with PatternSynonyms. You have updated Haddock accordingly but at the same time, you haven't checked that you haven't broken it. This means that when we were trying to quickly fix a bug today, the Haddock tests came up as failing. There at least two faults that I've spotted: * Single space added in front of every function name. This isn't visible by the user but is visible by the test-suite and would require that we update every test file for no good reason. After a long while, I narrowed it down to the line “leader + ppTypeSig summary occnames pp_typ unicode” as it seems that ‘leader’ is empty for a lot of time and the (+) function adds a single space. It'd be an easy fix if it was only this but… * Data types using infix notations are now parenthesised Haddock now renders ‘data a :- b’ as ‘data a (:-) b’. This is a problem. I don't know what else is broken but I can't go on trying to fix this because you haven't added any tests for the features you put in! I have no idea what I'm breaking in PatternSynonyms when making changes. For now we have to revert some of the Haddock changes, namely the XHtml back-end stuff you added. The proposed revert is currently at [1] and will probably be put into the 7.8 RC very soon because the documentation for ‘base’ has to be generated. Please have a look and see what you can fix in the XHtml back-end for your feature. This includes making sure that the existing tests pass (you do this by running ‘cabal test’, just running validate for GHC is _not_ enough) and adding new tests for the things you add (you're going to be interested in adding test cases in html-test/src and adding the expected test results in html-test/ref). Thanks [1]: https://github.com/Fuuzetsu/haddock/tree/codeblockfix -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Pattern synonyms for 7.8?
Hi, Sorry, I wasn't aware running validate was not enough. I'll check out the problems in ~10 hours. Bye, Gergo On Jan 30, 2014 7:41 AM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: On 05/01/14 12:16, Dr. ERDI Gergo wrote: Hi, When I started working on pattern synonyms (#5144) back in August, it seemed the GHC 7.8 freeze was imminent, so I was planning for a first version in 7.10/8.0 (whatever it will be called). However, since not much has happened re: 7.8 since then (at least not much publicly visible), and on the other hand, my implementation of pattern synonyms is ready, I am now starting to wonder if it could be squeezed into 7.8. What are your thoughts on this? Thanks, Gergo ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs Hi again, We've ran into some trouble over at #ghc regarding Haddock updates to do with PatternSynonyms. You have updated Haddock accordingly but at the same time, you haven't checked that you haven't broken it. This means that when we were trying to quickly fix a bug today, the Haddock tests came up as failing. There at least two faults that I've spotted: * Single space added in front of every function name. This isn't visible by the user but is visible by the test-suite and would require that we update every test file for no good reason. After a long while, I narrowed it down to the line leader + ppTypeSig summary occnames pp_typ unicode as it seems that 'leader' is empty for a lot of time and the (+) function adds a single space. It'd be an easy fix if it was only this but... * Data types using infix notations are now parenthesised Haddock now renders 'data a :- b' as 'data a (:-) b'. This is a problem. I don't know what else is broken but I can't go on trying to fix this because you haven't added any tests for the features you put in! I have no idea what I'm breaking in PatternSynonyms when making changes. For now we have to revert some of the Haddock changes, namely the XHtml back-end stuff you added. The proposed revert is currently at [1] and will probably be put into the 7.8 RC very soon because the documentation for 'base' has to be generated. Please have a look and see what you can fix in the XHtml back-end for your feature. This includes making sure that the existing tests pass (you do this by running 'cabal test', just running validate for GHC is _not_ enough) and adding new tests for the things you add (you're going to be interested in adding test cases in html-test/src and adding the expected test results in html-test/ref). Thanks [1]: https://github.com/Fuuzetsu/haddock/tree/codeblockfix -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Reply etiquette
On 29/01/14 22:47, Joachim Breitner wrote: Hi, Am Mittwoch, den 29.01.2014, 23:18 +0100 schrieb Jan Stolarek: PS: I’m subscribed to the list, no need to send a copy to my private address. This is typically done to alert someone that he/she has been addressed directly in a discussion. I for example have my filters set in such a way that all ghc-devs mails are automatically marked as read unless I am CC'd. if someone really needs urgent attention from me, putting me in CC is fine: Mail directed to me will cause popups and land in my Inbox. But doing so carelessly makes this distinction useless; for example with the recent pattern synonym thread, I once made a minor comment and got a dozend mails explicitly sent to me. This is alerting thing is clearly not working – and I am tempted to the opposite of what you do: Automatically delete any mail reaching my inbox that also goes to ghc-dev (and stop whining here). But before doing that, I’ll try using the Reply-To header, let’s see if that works better. BTW, does everyone know about Reply-To-List (sometimes calle Group Reply, Ctrl-L in evolution) instead of Reply-To-All? But I heard rumors that Outlook does not support that, and – unlike in the Debian community – that would be a problem. I guess Reply-To can help then. Thunderbird has this, Reply List. I think the problem is that the reply headers sometimes get messed up: I always use Reply List but even then, Thunderbird often either replies to the person in question and CCs the list or the other way around. For this e-mail, I am only sending to the list, using Reply List. I think it adds the person by default if they address mail e-mail and similar thing probably happens for others. I try to remove such occurrences manually but I'm sure it sometimes slips by. I think that as long as you read ghc-devs, it's fine to set up your client to not show you things in your inbox. Greetings, Joachim ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.8 branch is created, HEAD is now open, and a note on merges
Hi Austin, It seems to me that the patch for Cabal in ticket 8266 is still missing: https://ghc.haskell.org/trac/ghc/ticket/8266 diff --git a/Cabal/Distribution/Simple/GHC.hs b/Cabal/Distribution/Simple/GHC.hs index c7ea633..78cdcbb 100644 --- a/Cabal/Distribution/Simple/GHC.hs +++ b/Cabal/Distribution/Simple/GHC.hs @@ -867,11 +867,6 @@ buildOrReplLib forRepl verbosity pkg_descr lbi lib clbi = do ghcOptDynLinkMode= toFlag GhcDynamicOnly, ghcOptInputFiles = dynamicObjectFiles, ghcOptOutputFile = toFlag sharedLibFilePath, - -- For dynamic libs, Mac OS/X needs to know the install location - -- at build time. - ghcOptDylibName = if buildOS == OSX - then toFlag sharedLibInstallPath - else mempty, ghcOptPackageName= toFlag pkgid, ghcOptNoAutoLinkPackages = toFlag True, ghcOptPackageDBs = withPackageDB lbi, If Duncan is busy at this moment, can you take over the merge job? --Kazu Hello all, I've just created the 7.8 branch after tying off some of the final loose ends. In its current state, I expect the branch as it is now to become RC1 within the day. I plan on starting builds for the following soon: - OS X 10.7 and OS X 10.9 - Linux i386/amd64 (likely based on Debian Wheezey) - Windows i386/amd64 (many thanks to Kyrill Briantsev for the heroic last-minute linker fixes!) I'll send a (GPG-signed) email containing SHA1 hashes when they're done. Two systems I won't make builds for RC1 by default (but could be persuaded to if nobody else does, and people want it): - Older glibc-2.5 based systems (e.g. CentOS, - a few users have talked about this wrt binary releases, where I don't think GHC works.) - FreeBSD - Pali, if you'd like to do this, feel free, and let me know. This means I'll (mostly) be waiting around today, so feel free to shoot questions. As of now, this means HEAD is now version 7.9, and you're free to push wacky experiments or changes now, if you've been holding off. You'll probably want to clean your whole tree, since this means the interface file versions etc will change. Finally, we picked up a good amount of new committers this year, so let's remind people of the merging policy: what happens if you need to merge something you did to the 7.8 branch? There are two main avenues for this to happen: * Someone reports a bug against the 7.8 RC on Trac. You decide to fix it and do so. Now what? 1) Please commit the bug to master, and confirm it's a fix. 2) Go to the bug, and instead of closing it, change the ticket status to 'merge'. 3) I will cherry-pick it over to the 7.8 branch for you - nothing else needed. * There's not a recorded bug, but you do push a change, and you think it should be merged (maybe a typo or something.) In this case, I'd ask you please CC me on the email sent to ghc-comm...@haskell.org which is related to your commit, and just say Please merge or somesuch. I'll come over the commits with such a response. This goes for all changes - submodule updates, typos, real fixes, etc. It's likely me and Herbert will restrict the Gitolite permissions to only allow the two of us to touch the ghc-7.8 branch. So it's really important you put us in the loop, ASAP. If you don't do one of these two things, it's highly likely I will miss it, and not merge it. If you have questions, please ask me or Herbert. If there's a merge conflict, we can discuss it. Thanks -- 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
Re: Reply etiquette
Ironically, this is the first ghc-devs email to ever get sent to my bulk folder. :) I can't speak for others, but I try to read most of the email in devs and related lists (for good or for ill). Though this certainly gets in the way of getting work done sometimes :) On Wednesday, January 29, 2014, Joachim Breitner m...@joachim-breitner.de wrote: Hi, Am Mittwoch, den 29.01.2014, 23:18 +0100 schrieb Jan Stolarek: PS: I’m subscribed to the list, no need to send a copy to my private address. This is typically done to alert someone that he/she has been addressed directly in a discussion. I for example have my filters set in such a way that all ghc-devs mails are automatically marked as read unless I am CC'd. if someone really needs urgent attention from me, putting me in CC is fine: Mail directed to me will cause popups and land in my Inbox. But doing so carelessly makes this distinction useless; for example with the recent pattern synonym thread, I once made a minor comment and got a dozend mails explicitly sent to me. This is alerting thing is clearly not working – and I am tempted to the opposite of what you do: Automatically delete any mail reaching my inbox that also goes to ghc-dev (and stop whining here). But before doing that, I’ll try using the Reply-To header, let’s see if that works better. BTW, does everyone know about Reply-To-List (sometimes calle Group Reply, Ctrl-L in evolution) instead of Reply-To-All? But I heard rumors that Outlook does not support that, and – unlike in the Debian community – that would be a problem. I guess Reply-To can help then. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
GHC for iOS (arm) 7.8 Preview Build ready for upload
Hi folks! I've just finished a preview build of GHC for iOS off the 7.8 branch, but could use a place to upload it. And once that's done, if anyone would like to help me test it that has Xcode 5 and a device, that would be excellent! Cheers Luke ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC for iOS (arm) 7.8 Preview Build ready for upload
OK, it's up here now: https://github.com/ghc-ios/ghc-ios-scripts/releases/tag/7.8RC1Preview1 You'll need the scripts from https://github.com/ghc-ios/ghc-ios-scripts in your path along with LLVM 3.0 (it's the only version that works so far). On Wed, Jan 29, 2014 at 9:27 PM, Luke Iannini lukex...@gmail.com wrote: Hi folks! I've just finished a preview build of GHC for iOS off the 7.8 branch, but could use a place to upload it. And once that's done, if anyone would like to help me test it that has Xcode 5 and a device, that would be excellent! Cheers Luke ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
