Re: GHC 7.10 Regression(?) regarding Unicode subscript characters in identifiers
Yonqian, if subscript characters were allowed starting from the second character of an identifier, would that be sufficient for you? Please comment on https://ghc.haskell.org/trac/ghc/ticket/10196, or here. Thomas On Fri, Mar 27, 2015 at 10:32 AM, Thomas Miedema thomasmied...@gmail.com wrote: I opened the following ticket for this issue: https://ghc.haskell.org/trac/ghc/ticket/10196 On Fri, Mar 27, 2015 at 1:50 AM, Yongqian Li yong...@10gic.net wrote: Is this a bug, and if so, will it be fixed before the final release? We currently use subscript characters in our identifiers and would like to see the old behavior restored... ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: ANNOUNCE: GHC version 7.10.1
Austin, links to x86_64 linux versions for CentOS don't work. Janek Dnia piątek, 27 marca 2015, Austin Seipp napisał: == The (Interactive) Glasgow Haskell Compiler -- version 7.10.1 == The GHC Team is pleased to announce a new major release of GHC. There have been a number of significant changes since the last major release, including: * Several new language features and changes have been implemented: - Applicative is now a superclass of Monad and in the Prelude. - Many prelude combinators have been generalized - Static pointers * GHC now has preliminary and experimental support for DWARF based debugging. * `integer-gmp` has been completely rewritten. * Type-checking plugins can now extend the type checker. * Support for partial type signatures * Many bugfixes and other performance improvements. * Preliminary support for 'backpack' features like signatures. * Typeable is now generated by default for all data types automatically. We've also fixed a handful of issues reported since RC3: - A bug in the call arity analysis that would result in invalid core was fixed (#10176) - A bug in the Win32 package causing it to fail to load was fixed (#10165) - ghc-prim has (correctly) been bumped to version 0.4.0.0, to comply with the PVP. - Several libraries have been bumped to their latest available versions after coordination. The full release notes are here: https://downloads.haskell.org/~ghc/7.10.1/docs/html/users_guide/release-7-1 0-1.html How to get it ~ The easy way is to go to the web page, which should be self-explanatory: https://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://ghc.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~ The list of platforms we support, and the people responsible for them, is here: https://ghc.haskell.org/trac/ghc/wiki/Platforms https://ghc.haskell.org/trac/ghc/wiki/CodeOwners Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: https://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: https://ghc.haskell.org/trac/ghc/ Mailing lists ~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at https://www.haskell.org/mailman/listinfo/glasgow-haskell-users https://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see https://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: https://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: https://www.haskell.org/ghc/reportabug Hashes Signatures ~ On https://downloads.haskell.org/~ghc/7.10.1/ you will find a signed copy of the SHA256 hashes for the tarballs, using my GPG key (0F8F 3AA9 9235 C704 ADA0 B419 B942 AEE5 3B58 D86F). --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o
ANNOUNCE: GHC version 7.10.1
== The (Interactive) Glasgow Haskell Compiler -- version 7.10.1 == The GHC Team is pleased to announce a new major release of GHC. There have been a number of significant changes since the last major release, including: * Several new language features and changes have been implemented: - Applicative is now a superclass of Monad and in the Prelude. - Many prelude combinators have been generalized - Static pointers * GHC now has preliminary and experimental support for DWARF based debugging. * `integer-gmp` has been completely rewritten. * Type-checking plugins can now extend the type checker. * Support for partial type signatures * Many bugfixes and other performance improvements. * Preliminary support for 'backpack' features like signatures. * Typeable is now generated by default for all data types automatically. We've also fixed a handful of issues reported since RC3: - A bug in the call arity analysis that would result in invalid core was fixed (#10176) - A bug in the Win32 package causing it to fail to load was fixed (#10165) - ghc-prim has (correctly) been bumped to version 0.4.0.0, to comply with the PVP. - Several libraries have been bumped to their latest available versions after coordination. The full release notes are here: https://downloads.haskell.org/~ghc/7.10.1/docs/html/users_guide/release-7-10-1.html How to get it ~ The easy way is to go to the web page, which should be self-explanatory: https://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://ghc.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~ The list of platforms we support, and the people responsible for them, is here: https://ghc.haskell.org/trac/ghc/wiki/Platforms https://ghc.haskell.org/trac/ghc/wiki/CodeOwners Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: https://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: https://ghc.haskell.org/trac/ghc/ Mailing lists ~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at https://www.haskell.org/mailman/listinfo/glasgow-haskell-users https://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see https://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: https://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: https://www.haskell.org/ghc/reportabug Hashes Signatures ~ On https://downloads.haskell.org/~ghc/7.10.1/ you will find a signed copy of the SHA256 hashes for the tarballs, using my GPG key (0F8F 3AA9 9235 C704 ADA0 B419 B942 AEE5 3B58 D86F). -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC 7.10 Regression(?) regarding Unicode subscript characters in identifiers
I opened the following ticket for this issue: https://ghc.haskell.org/trac/ghc/ticket/10196 On Fri, Mar 27, 2015 at 1:50 AM, Yongqian Li yong...@10gic.net wrote: Is this a bug, and if so, will it be fixed before the final release? We currently use subscript characters in our identifiers and would like to see the old behavior restored... ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
On 2015-03-25 at 15:24:30 +0100, Mark Lentczner wrote: [...] Concrete proposal based on that and the other fine input in the responses: *Simultaneous Release:* Since it is organizationally impractical to have one release, let's have GHC and Platform release at the same moment. That is, GHC HQ would keep a release in RC until HP was ready. By the same token, HP team commits to tracking GHC from RC1, and aiming to hit ready for release within a week of GHC being ready. Both go release in the same announcement. *In fact, let's version HP with the same number as GHC!* [...] I'm a bit worried about the aspect of delaying the GHC release schedule for the sole purpose to provide the HP with more visibility, while penalising those users that have no interest to use the HP anyway. Otoh, there's usually enough time between the last RC and the actual final release, which should give the HP at least one week of time anyway w/o any active delay on GHC's end. Otoh, as soon as the new HP is released, it provides users with the perception of a new stable HP release to jump on right-away. That, however, may lead to a poor experience if the it's the first HP release for a given major GHC version as Hackage usually hasn't fully caught up by the time a GHC x.y.1 is unleashed. So if we had co-released a HP featuring GHC 7.10.1 today, there would still be enough Hackage packages not yet compatible with GHC 7.10.1 to recommend users *not* to install the release right-away. So I'm actually not sure if a simultaneous release of GHC x.y.1 w/ HP would be in the HP's best interest in terms of providing a reliable and complete development environment (which IMO requires access to Hackage, even more so if the HP is to be reduced to contain less packages) -- hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
On Fri, Mar 27, 2015 at 5:24 AM, Herbert Valerio Riedel h...@gnu.org wrote: I'm a bit worried about the aspect of delaying the GHC release schedule for the sole purpose to provide the HP with more visibility, That isn't the purpose at all. My aim ins't to promote HP. The aim of my suggestion is to ensure that there is a consistent way for the community to get Haskell (as GHC itself is not enough for anyone - you need cabal at the least, and there are libraries that are common enough to be considered essential: text, vector, etc...). It is also to ensure there is a consistent reference point for package developers to test their packages against, for those packages that wish to support more than just the current GHC. Again, GHC releases themselves do not form a big enough reference point to ensure two packages that support the last two release are supporting the same thing. ... Otoh, there's usually enough time between the last RC and the actual final release, which should give the HP at least one week of time anyway w/o any active delay on GHC's end. Well - if there is a week of commits to GHC, it should really do another RC before declaring it final. The difference between the last RC and the release should a single commit of no more than the version number change and the change log. Frankly, if we are all on board with this, then GHC could suffer a few day (week at most) delay between such an RC (as in we're frozen, save for the version stamp), and announcing release. This would not only allow there to be a Platform on the same day - but also GHC bindists for other OSes on the same day. Otoh, as soon as the new HP is released, it provides users with the perception of a new stable HP release to jump on right-away. That, however, may lead to a poor experience if the it's the first HP release for a given major GHC version as Hackage usually hasn't fully caught up by the time a GHC x.y.1 is unleashed. We need to have to maintainers of the packages in the HP on board with this and down with the we're all going to gear up in the four weeks before a GHC version... not we'll gear up in the four weeks after. Frankly, for the kinds of packages that are in the platform (text, vector, unordered containers, etc...), having these packages lag GHC release so that they are broken on Hackage the day of GHC release is in nobody's interest: It gives a poor experience for ALL users of Haskell. So if we had co-released a HP featuring GHC 7.10.1 today, there would still be enough Hackage packages not yet compatible with GHC 7.10.1 to recommend users *not* to install the release right-away. But that is true of GHC as well. We need to stop having the attitude of Platform is for newcomers / GHC is for heavyweights. It is perfectly fine to announce GHC 7.10.1 is out - you can install it from Platform 7.10.1 which is a complete installer for your OS with core and standard libraries, and tools; or if you prefer you can get the minimal binary compiler build. As always, not all packages on Hackage will be compatible. Then our recommendations on to users on IRC are about which version is best for their needs, not don't install platform, you won't be able to get lens to compile... So I'm actually not sure if a simultaneous release of GHC x.y.1 w/ HP would be in the HP's best interest in terms of providing a reliable and complete development environment (which IMO requires access to Hackage, even more so if the HP is to be reduced to contain less packages) People who care about stability will go ahead and hang back to what they consider a stable reference for them. (Gosh, how many projects are still supporting Python 2.6?!). But it will only be a stable reference if people use it, and package maintainers support it. Today's mess of GHC releases, Platform releases, alternative installer releases, etc... leaves both users and package maintainers no way to create or find stability. - Mark ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
On Fri, Mar 27, 2015 at 10:09 AM, Mark Lentczner mark.lentcz...@gmail.com wrote: But that is true of GHC as well. We need to stop having the attitude of Platform is for newcomers / GHC is for heavyweights. It is perfectly fine to announce GHC 7.10.1 is out - you can install it from Platform 7.10.1 which is a complete installer for your OS with core and standard libraries, and tools; or if you prefer you can get the minimal binary compiler build. As always, not all packages on Hackage will be compatible. Then our recommendations on to users on IRC are about which version is best for their needs, not don't install platform, you won't be able to get lens to compile... The lens package (alongside every other package I maintain that is incurred as a dependency of lens) has very deliberately support all Haskell Platform releases for at least 3 current major GHC releases, often at great expense to the API. No offense, but I don't think lens is the culprit here. -Edward ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HP 2015.2.0.0 and GHC 7.10
NO MOAR BIKESHEDS! I don't want to release in the platform an API that is out of date the day we release it. So we either go with the new (and I'm trusting Sven to vouch for 'it's the right API, we'll support this for the next year or so') - or we drop OpenGL* from the platform release - or we do with and without releases. Votes? ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
On Fri, Mar 27, 2015 at 7:27 AM, Edward Kmett ekm...@gmail.com wrote: The lens package (alongside every other package I maintain that is incurred as a dependency of lens) has very deliberately support all Haskell Platform releases for at least 3 current major GHC releases, often at great expense to the API. No offense, but I don't think lens is the culprit here. Excellent! None taken. I appologize for my poor choice of example. Several people have included lens in an example of newcomers want to install x, y, and z - and it won't work with the platform. It is great that lens is not the problem - but it does underscore that the other packages haven't seen fit to match the same stability release points as lens - hence the unlikeliness of them working together except at HEAD. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HP 2015.2.0.0 and GHC 7.10
there is a bindist for 7.10 RC3 - right alongside the HP I built. I'm the builder for the bindists for GHC of OS X - not sure why Austin never put it on the GHC site. On Wed, Mar 25, 2015 at 2:51 PM, George Colpitts george.colpi...@gmail.com wrote: Thanks for doing this, AFAIK there is no bindist for 7.10.3 on the Mac. I downloaded and installed it, works great. I used it to install hlint and criterion. The only issue I saw was that uninstall didn't remove ghc executables of older versions that I had in /usr/local/bin (earlier bindist of 7.10.1rc2). Looking forward to using next version for 7.10.1 final Thanks again On Mon, Mar 23, 2015 at 2:13 AM, Mark Lentczner mark.lentcz...@gmail.com wrote: I've gone ahead and built a very provisional, alpha version of 2015.2.0.0 using GHC 7.10 RC3. I bumped all the GHC libs to the versions in 7.10, and bumped all the Platform libs to the latest versions I could find on Hackage. There were a few issues: - *old-locale and old-time* - no longer part of GHC, but cabal-install, cgi HTTP need them - and they are part of the platform - so included now as added packages. Not sure this is a great idea, since they are now very deprecated... but until cabal-install, cgi, HTTP update, not sure what else to do. - *tf-random* - is now required by alex and QuickCheck - seems a shame to add this, as now we're going to have two random packages - *network-uri *- was split out of network, and needed by cabal-install, cgi, HTTP. I suppose we should include it, as it was functionality and API that was part of the platform - *exceptions* *multipart* - needed by cgi - is exceptions now subsumed by something in transformers? and... multipart? maybe time to drop cgi? We didn't have it last time anyway as it wouldn't compile! - *scientific* - needed by attoparsec - debated in detail last time ... and we're still here! The Platform is significantly larger now: On OS X it has gone from 316M to 499M! Most of this is due to new OpenGL libs which are now huge (went from 98M to 239M!) GHC itself grew by 109M (to almost 1G), so that the whole installed magilla is 1.5G! Even the compressed installer is now 250M! If you want to poke at it, the source is in the pre-release branch at GitHub https://github.com/haskell/haskell-platform/tree/pre-release, and the OS X builds are at my usual platform staging area: Index of /mark/platform http://www.ozonehouse.com/mark/platform/ Remember, it already includes GHC, so no need to download the GHC binary for OS X that is there, too. I'll try to get a generic linux build up soonish... but my VM now runs out of memory trying to build OpenGL - and adding more only makes my machine thrash to death! - Mark ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: ANNOUNCE: GHC version 7.10.1
On 03/27/2015 07:43 AM, Austin Seipp wrote: == The (Interactive) Glasgow Haskell Compiler -- version 7.10.1 == The GHC Team is pleased to announce a new major release of GHC. There have been a number of significant changes since the last major release, including: * Several new language features and changes have been implemented: - Applicative is now a superclass of Monad and in the Prelude. - Many prelude combinators have been generalized [snip] I wanted to learn about which combinators have been updated so I click on ‘GHC 7.10 Migration Guide’ in linked documentation page but it seems that it doesn't lead anywhere, or rather leads to the page it's linked from. It was probably meant to link to https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10 -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
HP 2015.2.0.0 and GHC 7.10
I am helping Mark with the Haskell Platform, doing the Windows builds (32- and 64-bit). I want you to be aware of a problem I am encountering, and solicit suggestions and possible help. In building for HP 2015.2.0.0 on Windows 7, 64-bit (haven't gotten to 32-bit yet but likely the same problem will occur), I seem to be hitting the 32K limit for the length of arguments to a process, encountered while cabal is invoking haddock to build the docs for the OpenGLRaw package. For HP2014.2.0.0, the argument list was ~25K (from looking at my old build logs) but now is ~36K, which exceeds the maximum for CreateProcess (not a limit of the command-line, but of the OS call itself). Is there a way to build haddock docs for a single package but in multiple haddock invocations (maybe building a .haddock file for portions, then combining them, with the goal that the command line is kept short)? Seems this would also require a corresponding cabal change, as cabal is the invocator when this happens. Barring any existing mechanism, the typical solution to this problem on the Windows OS is (when possible, of course) to modify the program to accept a response file of command-line arguments. In this case, we could add an option to haddock to accept either a complete response file (i.e., allowing *all* options and arguments to come from a file) or just a file containing the files to process. Either of these changes to haddock are rather trivial to write (but adding another option implies more testing, documentation, other cases to handle, etc.). Since haddock ships with the ghc release, that's another wrinkle for this particular release. The other implication of such a solution is that cabal would need a change to utilize this change for it to be effective, checking haddock's version for support of this new haddock-flag, and either use it if the haddock version supports it, or do it optionally (which implies a new flag for cabal's haddock sub-command). This change to cabal is also rather trivial to implement (this is not to imply insensitivity to the incurred cost of each line of code, nor to the added burden of user-visible changes such as a command-line option). (Less desirable possibilities, mentioned only for completeness: skip the documentation for OpenGLRaw for this version of the Haskell Platform; split up the OpenGLRaw package itself in some way.) Other possible solutions and work-arounds? Thoughts on either using haddock in a different way (and the cabal change that would be required to break up the doc build into multiple steps for a single package)? Thoughts on the response file solution? Randy ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HP 2015.2.0.0 and GHC 7.10
I'm personally a rather vocal proponent of the new OpenGL API changes. I'd also in general favor a policy of greater trust when it comes to library authors factoring out bits of their packages even once they become part of the platform. We all want our code to work together. The hand-wringing we've had over the splitting off of multipart from cgi and ObjectName or StateVar from OpenGL because designers of packages like sdl2 want to be able to support a common API without incurring a needless OpenGL dependency is largely indicative of why some folks get scared of their packages being included in the platform. And, e.g. aeson's scientific dependency is needed to ensure data going through the API doesn't lose precision, and due to stackage almost everyone has adapted to its presence for over a year. Removing it would do nobody any good. Let's bless it and move on. -Edward On Fri, Mar 27, 2015 at 10:41 AM, Mark Lentczner mark.lentcz...@gmail.com wrote: NO MOAR BIKESHEDS! I don't want to release in the platform an API that is out of date the day we release it. So we either go with the new (and I'm trusting Sven to vouch for 'it's the right API, we'll support this for the next year or so') - or we drop OpenGL* from the platform release - or we do with and without releases. Votes? ___ Libraries mailing list librar...@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HP 2015.2.0.0 and GHC 7.10
Relatedly, theres a major version bump release of primitive that's due to be cut soon, and in a month or two vector 0.11 will be ready for release one way or another. At the very least, we should try to get that new version of primitive ready for release and onto platform, since it immediately upgrades the power of any package that uses prim monad! On Mar 27, 2015 11:28 AM, Edward Kmett ekm...@gmail.com wrote: I'm personally a rather vocal proponent of the new OpenGL API changes. I'd also in general favor a policy of greater trust when it comes to library authors factoring out bits of their packages even once they become part of the platform. We all want our code to work together. The hand-wringing we've had over the splitting off of multipart from cgi and ObjectName or StateVar from OpenGL because designers of packages like sdl2 want to be able to support a common API without incurring a needless OpenGL dependency is largely indicative of why some folks get scared of their packages being included in the platform. And, e.g. aeson's scientific dependency is needed to ensure data going through the API doesn't lose precision, and due to stackage almost everyone has adapted to its presence for over a year. Removing it would do nobody any good. Let's bless it and move on. -Edward On Fri, Mar 27, 2015 at 10:41 AM, Mark Lentczner mark.lentcz...@gmail.com wrote: NO MOAR BIKESHEDS! I don't want to release in the platform an API that is out of date the day we release it. So we either go with the new (and I'm trusting Sven to vouch for 'it's the right API, we'll support this for the next year or so') - or we drop OpenGL* from the platform release - or we do with and without releases. Votes? ___ Libraries mailing list librar...@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Rename driver phases C(obj)cpp to C(obj)cplusplus (abde5da)
Hi Thomas, Cplusplus is quite long identifier, bad for eyes. Usually in C++ community if you can't use cpp then you use cxx. It's shorter and clear even when reading fast, don't you think? Karel PS: of course even before cxx it was CC, but I think this does not have any advantage over cxx in this context... On 03/27/15 09:38 PM, g...@git.haskell.org wrote: Repository : ssh://g...@git.haskell.org/ghc On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/abde5da4dee5f3b83264f8471e458b20d04f8b29/ghc --- commit abde5da4dee5f3b83264f8471e458b20d04f8b29 Author: Thomas Miedemathomasmied...@gmail.com Date: Fri Mar 27 21:37:49 2015 +0100 Rename driver phases C(obj)cpp to C(obj)cplusplus Before: Cpp = Pre-process C Ccpp= Compile C++ Cobjcpp = Compile Objective-C++ CmmCpp = Pre-process Cmm Quite confusing! This commit renames `Ccpp` to `Ccplusplus`, and `Cobjcpp` to `Cobjcplusplus`. The two letters `p-p` keep standing for `pre-processing` throughout the compiler. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D756 --- abde5da4dee5f3b83264f8471e458b20d04f8b29 compiler/main/DriverPhases.hs | 32 compiler/main/DriverPipeline.hs | 9 + ghc/Main.hs | 2 +- 3 files changed, 22 insertions(+), 21 deletions(-) diff --git a/compiler/main/DriverPhases.hs b/compiler/main/DriverPhases.hs index 2433f6d..2d7d904 100644 --- a/compiler/main/DriverPhases.hs +++ b/compiler/main/DriverPhases.hs @@ -111,10 +111,10 @@ data Phase | Cpp HscSource | HsPp HscSource | Hsc HscSource -| Ccpp -| Cc -| Cobjc -| Cobjcpp +| Ccplusplus-- Compile C++ +| Cc-- Compile C +| Cobjc -- Compile Objective-C +| Cobjcplusplus -- Compile Objective-C++ | HCc -- Haskellised C (as opposed to vanilla C) compilation | Splitter -- Assembly file splitter (part of '-split-objs') | SplitAs -- Assembler for split assembly files (part of '-split-objs') @@ -148,10 +148,8 @@ eqPhase (Unlit _) (Unlit _) = True eqPhase (Cpp _) (Cpp _) = True eqPhase (HsPp _) (HsPp _) = True eqPhase (Hsc _) (Hsc _) = True -eqPhase CcppCcpp = True eqPhase Cc Cc = True eqPhase Cobjc Cobjc = True -eqPhase Cobjcpp Cobjcpp= True eqPhase HCc HCc= True eqPhase SplitterSplitter = True eqPhase SplitAs SplitAs= True @@ -163,7 +161,9 @@ eqPhase CmmCpp CmmCpp = True eqPhase Cmm Cmm= True eqPhase MergeStub MergeStub = True eqPhase StopLn StopLn = True -eqPhase _ _ = False +eqPhase Ccplusplus Ccplusplus = True +eqPhase Cobjcplusplus Cobjcplusplus = True +eqPhase _ _ = False -- Partial ordering on phases: we want to know which phases will occur before -- which others. This is used for sanity checking, to ensure that the @@ -189,10 +189,10 @@ nextPhase dflags p LlvmMangle - As False SplitAs- MergeStub As _ - MergeStub - Ccpp - As False + Ccplusplus - As False Cc - As False Cobjc - As False - Cobjcpp- As False + Cobjcplusplus - As False CmmCpp - Cmm Cmm- maybeHCc HCc- As False @@ -215,13 +215,13 @@ startPhase hscpp= HsPp HsSrcFile startPhase hspp = Hsc HsSrcFile startPhase hc = HCc startPhase c= Cc -startPhase cpp = Ccpp +startPhase cpp = Ccplusplus startPhase C= Cc startPhase m= Cobjc -startPhase M= Cobjcpp -startPhase mm = Cobjcpp -startPhase cc = Ccpp -startPhase cxx = Ccpp +startPhase M= Cobjcplusplus +startPhase mm = Cobjcplusplus +startPhase cc = Ccplusplus +startPhase cxx = Ccplusplus startPhase split_s = Splitter startPhase s= As False startPhase S= As True @@ -247,9 +247,9 @@ phaseInputExt (Hsc _) = hspp -- intermediate only -- because runPipeline uses the StopBefore phase to pick the -- output filename. That could be fixed, but watch out. phaseInputExt HCc = hc -phaseInputExt Ccpp= cpp +phaseInputExt Ccplusplus = cpp phaseInputExt Cobjc = m -phaseInputExt Cobjcpp = mm +phaseInputExt Cobjcplusplus = mm phaseInputExt Cc = c phaseInputExt Splitter= split_s phaseInputExt (As True) = S diff --git a/compiler/main/DriverPipeline.hs
Re: HP 2015.2.0.0 and GHC 7.10
On Fri, Mar 27, 2015 at 11:50 AM, Carter Schonwald carter.schonw...@gmail.com wrote: Relatedly, theres a major version bump release of primitive that's due to be cut soon, and in a month or two vector 0.11 will be ready for release one way or another. Is soon measured in hours? If not - I suggest that it misses. I'm pushing that we change how we do this Platform thing - and make it stick, like glue, to the GHC release schedule. Sure, this time 'round we'll be out of sync with those it's almost there packages... but next time we'll know it's coming and hopefully, we'll have these panic attacks as GHC is in beta not post-Release. - Mark ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HP 2015.2.0.0 and GHC 7.10
On March 27, 2015 at 10:47:12 PM, Mark Lentczner (mark.lentcz...@gmail.com) wrote: Is soon measured in hours? If not - I suggest that it misses. I'm pushing that we change how we do this Platform thing - and make it stick, like glue, to the GHC release schedule. Sure, this time 'round we'll be out of sync with those it's almost there packages... but next time we'll know it's coming and hopefully, we'll have these panic attacks as GHC is in beta not post-Release. +1 to this sentiment. Now that we can do efficient platform builds, better to release regularly and efficiently. Otherwise we’ll always be playing catch-up to “one more thing.” -g ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HP 2015.2.0.0 and GHC 7.10
Soon is now. I just published primitive-0.6 and vector-0.10.12.3 that increments the version dependency for it. So they can go in if people want. -- Dan On Fri, Mar 27, 2015 at 10:46 PM, Mark Lentczner mark.lentcz...@gmail.com wrote: On Fri, Mar 27, 2015 at 11:50 AM, Carter Schonwald carter.schonw...@gmail.com wrote: Relatedly, theres a major version bump release of primitive that's due to be cut soon, and in a month or two vector 0.11 will be ready for release one way or another. Is soon measured in hours? If not - I suggest that it misses. I'm pushing that we change how we do this Platform thing - and make it stick, like glue, to the GHC release schedule. Sure, this time 'round we'll be out of sync with those it's almost there packages... but next time we'll know it's coming and hopefully, we'll have these panic attacks as GHC is in beta not post-Release. - Mark ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
