Re: GHC 7.8.3 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/31/2014 12:28 PM, George Colpitts wrote: +1 Stability is very important. Also, do we have an ETA for when we will have an improved infrastructure for automated builds and the associated tests. I think this would help a lot with stability and shorten the time to the next release. On Fri, May 30, 2014 at 6:46 PM, Simon Marlow marlo...@gmail.com mailto:marlo...@gmail.com wrote: On 27/05/14 09:06, Austin Seipp wrote: PPS: This might also impact the 7.10 schedule, but last Simon and I talked, we thought perhaps shooting for ICFP this time (and actually hitting it) was a good plan. So I'd estimate on that a 7.8.4 might happen a few months from now, after summer. FWIW, I think doing 7.10 in October is way too soon. Major releases create a large distributed effort for package maintainers and users, and there are other knock-on effects, so we shouldn't do them too often. A lot of our users want stability, while many of them also want progress, and 12 months between major releases is the compromise we settled on. The last major release slipped for various reasons, but I don't believe that means we should try to get back on track by having a short time between 7.8 and 7.10. 7.8 will be out of maintenance when it has only just made it into a platform release. Anyway, that's my opinion. Of course if everyone says they don't mind a 7.10 in October then I withdraw my objection :-) (as a data point, upgrading to 7.8 at work cost me three weeks, but we're probably a special case) Cheers, Simon Hi George: There are continuous builds of GHC HEAD on several platforms and architectures: http://haskell.inf.elte.hu/builders/ There are still some bugs to work out there for sure (particularly mine on SmartOS), but a lot of progress has been made. The most critical gap is the lack of Windows and OS X builders since they are Tier 1 platforms for GHC. If you have Windows or OS X machines available please consider offering a builder: https://ghc.haskell.org/trac/ghc/wiki/Builder Best, Alain -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEbBAEBAgAGBQJTikGBAAoJEP0rIXJNjNSA/KsH+I7mug5uqHDr5YzZJSPl0awS 1PudhQqnBLf8Op/IQuPR7lYZEsXNTUb+VU1vV0vEo8+nRAaueVlhffsXYe7YRRHF wQqA1WsmIfwwDsU2DkeVOhKMht9iB1eKC3vvsTEvZE8GJKvQZDTIeas5QtUki/i0 yuTPrRMZjf6IubsxeY90mlDCgpRMjRIWcRPm9fWj7c0wdzUNmMR0IPshMiXjZbbM US9hkoyuXUyYZrtn19vbPGNTss3gZJEqengyDNDyVNrEd4QXC8Us/dqbnbjrKPI3 8D9BbVTOyELJ44mFXmlcXT8DSfIYCAv/sS81sXNm4lQX3jhTOyx2hNa3jvqIrQ== =sZkd -END PGP SIGNATURE- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
I have trouble with this as it breaks expectations around directory structure mirroring the module hierarchy. I would be very confused reading the source code of a project that availed of this feature as it would break my expectations of how to navigate to source files based on their module hierarchy. I'm not sure how the tool support is implemented in Vim, Emacs, Yi, Leksah etc., but changing this may break the tool's ability to provide jump to symbol. I imagine other unforeseen challenges with source dependency analysis elsewhere in the GHC toolchain may also arise if they assume that the directory layout reflects the module hierarchy. The Java toolchain certainly falls over when the corresponding package-flattening trick is performed on a Java codebase. The workarounds are viral and wind up complicating builds considerably. I could also be totally out to lunch here. On Apr 25, 2014, at 13:17, Simon Marlow marlo...@gmail.com wrote: I want to propose a simple change to the -i flag for finding source files. The problem we often have is that when you're writing code for a library that lives deep in the module hierarchy, you end up needing a deep directory structure, e.g. src/ Graphics/ UI/ Gtk/ Button.hs Label.hs ... where the top few layers are all empty. There have been proposals of elaborate solutions for this in the past (module grafting etc.), but I want to propose something really simple that would avoid this problem with minimal additional complexity: ghc -iGraphics.UI.Gtk=src the meaning of this flag is that when searching for modules, ghc will look for the module Graphics.UI.Gtk.Button in src/Button.hs, rather than src/Graphics/UI/Gtk/Button.hs. The source file itself is unchanged: it still begins with module Graphics.UI.Gtk.Button The implementation is only a few lines in the Finder (and probably rather more in the manual and testsuite), but I wanted to get a sense of whether people thought this would be a good idea, or if there's a better alternative before I push it. Pros: - simple implementation (but Cabal needs mods, see below) - solves the deep directory problem Cons: - It makes the rules about finding files a bit more complicated. People need to find source files too, not just compilers. - packages that want to be compatible with older compilers can't use it yet. - you can't use '=' in a source directory name (but we could pick a different syntax if necessary) - It won't work for Cabal packages until Cabal is modified to support it (PreProcess and SrcDist and perhaps Haddock are the only places affected, I think) - Hackage will need to reject packages that use this feature without also specifying ghc = 7.10 and some cabal-version too. - Are there other tools/libraries that will need changes? Leksah? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
-1 for me. In case that was unclear. On 25 April 2014 14:57, Alain O'Dea alain.o...@gmail.com wrote: I have trouble with this as it breaks expectations around directory structure mirroring the module hierarchy. I would be very confused reading the source code of a project that availed of this feature as it would break my expectations of how to navigate to source files based on their module hierarchy. I'm not sure how the tool support is implemented in Vim, Emacs, Yi, Leksah etc., but changing this may break the tool's ability to provide jump to symbol. I imagine other unforeseen challenges with source dependency analysis elsewhere in the GHC toolchain may also arise if they assume that the directory layout reflects the module hierarchy. The Java toolchain certainly falls over when the corresponding package-flattening trick is performed on a Java codebase. The workarounds are viral and wind up complicating builds considerably. I could also be totally out to lunch here. On Apr 25, 2014, at 13:17, Simon Marlow marlo...@gmail.com wrote: I want to propose a simple change to the -i flag for finding source files. The problem we often have is that when you're writing code for a library that lives deep in the module hierarchy, you end up needing a deep directory structure, e.g. src/ Graphics/ UI/ Gtk/ Button.hs Label.hs ... where the top few layers are all empty. There have been proposals of elaborate solutions for this in the past (module grafting etc.), but I want to propose something really simple that would avoid this problem with minimal additional complexity: ghc -iGraphics.UI.Gtk=src the meaning of this flag is that when searching for modules, ghc will look for the module Graphics.UI.Gtk.Button in src/Button.hs, rather than src/Graphics/UI/Gtk/Button.hs. The source file itself is unchanged: it still begins with module Graphics.UI.Gtk.Button The implementation is only a few lines in the Finder (and probably rather more in the manual and testsuite), but I wanted to get a sense of whether people thought this would be a good idea, or if there's a better alternative before I push it. Pros: - simple implementation (but Cabal needs mods, see below) - solves the deep directory problem Cons: - It makes the rules about finding files a bit more complicated. People need to find source files too, not just compilers. - packages that want to be compatible with older compilers can't use it yet. - you can't use '=' in a source directory name (but we could pick a different syntax if necessary) - It won't work for Cabal packages until Cabal is modified to support it (PreProcess and SrcDist and perhaps Haddock are the only places affected, I think) - Hackage will need to reject packages that use this feature without also specifying ghc = 7.10 and some cabal-version too. - Are there other tools/libraries that will need changes? Leksah? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Buildbots
Hi Joachim: From what I understand Travis CI limits running time for each build. We may be able to create binaries of stage1 and/or stage2 in one build and test them in another. We could also fan out the test process using a Build Matrix to let GHC's full suite fit into the time limit as fragments. That would require some changes to the testsuite or some lengthy build scripts for each segment that explicitly run many make TEST=sometest commands. I had to do something similar at Verafin because the whole test suite was taking too long as a whole unit. I split it into builds for each separate module and used more build agents so they could run in parallel. Verafin is using TeamCity, but I think the concepts are achievable in Buildbot or Travis CI. In my opinion, the best build and CI system is the one you can get working. Best, Alain On Apr 1, 2014, at 10:46, Joachim Breitner m...@joachim-breitner.de wrote: Hi, Am Dienstag, den 01.04.2014, 10:25 + schrieb Simon Peyton Jones: Joachim Breitner has set up Travis-CI. (I don't know exactly what that is, but it sounds useful.) Travis is a free cloud service that runs arbitrary tests (in our case, a stripped version of validate) upon pushes to git repositories on github. I set it up to validate our master, so we get a nice history of successes and failures on https://travis-ci.org/nomeata/ghc-complete/builds and I get mails when things fail; that is when I send hopefully polite enough mails to ghc-dev, asking people to fix their commits. (Unless I broke it myself; then I silently fix it and hide.) It is a makeshift solution until we get our own infrastructure working. An early question would be: to continue to use a DIY system (Builder), or to move to some other better-supported (but perhaps less malleable) system. I don't even know what the options are. Sigh, test infrastructure are like content management systems: There are plenty out there to choose from, all can do lots of things one does not need, but none can do all, so one starts writing something selfmade, which eventually evolves in yet another of these beasts, just with fewer users. I’d recommend a move to existing, proven tools. Unfortunately, I cannot give advice as to what tool to move to. But if all these¹ projects are happy with buildbot, it might not be the worst choice. ¹ http://trac.buildbot.net/wiki/SuccessStories 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-d...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Buildbots
Hi, On Apr 1, 2014, at 11:11, Joachim Breitner m...@joachim-breitner.de wrote: Hi, Am Dienstag, den 01.04.2014, 11:08 + schrieb Alain O'Dea: From what I understand Travis CI limits running time for each build. We may be able to create binaries of stage1 and/or stage2 in one build and test them in another. We could also fan out the test process using a Build Matrix to let GHC's full suite fit into the time limit as fragments. That would require some changes to the testsuite or some lengthy build scripts for each segment that explicitly run many make TEST=sometest commands. The main problem with Travis is that it only tests on one architecture. There are more (e.g. very undetailed reporting compared to a buildbot waterfall/grid) Good points. Hence: Travis is _not_ going to be a solution for us; we will want our own infrastructure. I'm happy to assist with getting whatever system fits the bill working. It seems like Buildbot should. Where can we get infrastructure on multiple architectures easily? I imagine we may need to mix and match. 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Buildbots
I'm going to read up on Ian's Buildbot work and experiment with that in the meantime. If other challenges come up I'm glad to dive in and help. On Apr 1, 2014, at 12:03, Simon Peyton Jones simo...@microsoft.com wrote: Indeed, there is no reason not to use Ian et al's Builder stuff. It's one of the options. But it depends on a critical evaluation of what the advantages and disadvantages of different approaches are Simon | -Original Message- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | boun...@haskell.org] On Behalf Of Karel Gardas | Sent: 01 April 2014 12:46 | To: Joachim Breitner; ghc-d...@haskell.org; Páli Gábor János | Cc: glasgow-haskell-users@haskell.org | Subject: Re: Buildbots | | | Hi, | | I'm curious why not to use what's already written by Ian and others and | which is currently running again? E.g. Janos Gabor Pali was so nice to | start and keep builder server running on | http://haskell.inf.elte.hu/builders/ | | Just few are there, but others may be added. Just send email to Janos to | get the credentials and more information about what to get from where | (recent builder client is needed). | | Perhaps we shall more advertise this option on GHC's builder wiki page? | | Thanks, | Karel | | | On 04/ 1/14 01:11 PM, Joachim Breitner wrote: | Hence: Travis is _not_ going to be a solution for us; we will want our | own infrastructure. | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ ghc-devs mailing list ghc-d...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Buildbots
Thank you Carter. I think it's reasonable to incubate it on your Github profile for now until we are certain it is fully working again. Either way works though :) Best, Alain On Apr 1, 2014, at 17:45, Carter Schonwald carter.schonw...@gmail.com wrote: hey all, I just exported the igloo builder code from darcs to git, and put it here https://github.com/cartazio/ghc-builder would this be something worth adding to github.com/haskell ? (i can easily add it if other folks it should be surfaced more visibly) On Tue, Apr 1, 2014 at 11:04 AM, Páli Gábor János pali.ga...@gmail.com wrote: 2014-04-01 14:03 GMT+02:00 Simon Peyton Jones simo...@microsoft.com: Indeed, there is no reason not to use Ian et al's Builder stuff. It's one of the options. But it depends on a critical evaluation of what the advantages and disadvantages of different approaches are I found Ian's buildbot an appealing alternative as it does a full build, including testing, and uploads the resulting binaries to a common place where anybody can access them (but it can be configured to do almost anything). The builders may be configured individually from a single (Haskell-language) configuration file and they are run on various volunteer-supplied systems so it is also distributed. I use this to keep track of the status of the FreeBSD builds to make my work easier on building the releases and maintaining the associated ports in the FreeBSD Ports Collection, while offering regular developer snapshots for the users. This approach also allows me to control and maintain the builder environment too as it may require minor or major changes and fixes over time that I can do myself as a FreeBSD developer. In the past, there were cases where the build was failing due to bugs in the kernel or the userland, so this is not purely about GHC itself (unfortunately). In my humble opinon, there are merits for the Travis-based Continuous Integration, so as for the daily snapshot building on each supported platform. I do not care if it is not Haskell-based or it is hosted at a central place with individual Virtual Machines for each platform -- until I can keep doing what I have been doing for 4 years now. ___ ghc-devs mailing list ghc-d...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-d...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
