Changes between Version 7 and Version 8 of Status/May09


Ignore:
Timestamp:
Apr 27, 2009 3:41:07 PM (5 years ago)
Author:
simonpj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Status/May09

    v7 v8  
     1= GHC Status May 2009 = 
    12 
    2  * 6.10.2 released. Bugfixes etc only. 
    3  * 6.10.3: tiny release, "by the time you read this ..." 
    4    * Moving to Haskeline 
    5    * Fix !^C in ghci. 
     3The last six months have been busy ones for GHC.   
     4 
     5== The GHC 6.10 branch == 
     6 
     7We finally released GHC 6.10.1 on 4 November 2008, with a raft of new 
     8features we discussed in the October 2008 status report. 
     9 
     10Something over five months later we released GHC 6.10.2, with XX new 
     11patches fixing YY new tickets raised against 6.10.1.  We hoped that'd be 
     12it for the 6.10 branch, but we slipped up and 6.10.2 contained a couple 
     13of regresssions (concerning Control-C and editline)  
     14that were sufficiently annoying that we're about make 
     15a rapid bug-fix release.  By the time you read this, GHC 6.10.3 should 
     16be out, after which we hope to shift all our attention to the 6.12 branch. 
     17 
     18 
     19== The new build system == 
     20 
     21Our old multi-makefile build system had grown old, crufty, hard to  
     22understand.  And it didn't even work very well.  So we embarked 
     23on a [wiki:Design/BuildSystem plan to re-implement the build system]. 
     24Rather than impose the new system on everyone immediately, Ian and Simon (Marlow)  
     25did all the development on a branch, and invited others to give it a whirl. 
     26Finally, on 25 April 2009, we went "live" on the HEAD.  
     27 
     28The new design is [wiki:Building extensively described] on the wiki.  It still 
     29uses `make`, but there is no only one (giant) Makefile, with no recursive invocations 
     30of `make`.  That in turn means that dependency tracking is vastly more accurate than before, 
     31so that if something should be built it will be built. 
     32 
     33The new build system is also much less dependent on Cabal than it was before. 
     34We now use Cabal only to read package metadata from the `<pkg>.cabal` file,  
     35and emit a bunch of Makefile bindings.  Everything else is done in `make`. 
     36You can read more about the [wiki:Design/BuildSystem design rationale] on the wiki. 
     37 
     38We also advertised our [wiki:Design/VersionControlSystem intent to switch to Git] as our 
     39version control system (VCS).  We always planned to change the build system first, and only 
     40then tackle the VCS.  Since then, there has been lots of activity on the Darcs front, so 
     41it's not clear how high priority making this change is.  We'd welcome your opinion. 
     42 
     43== The GHC 6.12 branch == 
     44 
     45The main list of new features in GHC 6.12 remains much the same as it was in our last status report.  Happily, there has been progress on all fronts. 
     46 
     47 * John Dias has continued work on '''rewriting GHC's backend'''.  You can find an [wiki:Commentary/Compiler/NewCodeGenPipeline overview of the new architecture] on the wiki. 
     48He and Norman and Simon wrote [http://research.microsoft.com/~simonpj/papers/c-- Dataflow optimisation made simple], a paper about the dataflow optimisation framework] that the new back end embodies.  Needless to say, the act of writing the paper has made us re-design the framework, so at the time of writing it still isn't on GHC's main compilation path.  But it will be. 
     49 
     50 * '''Data Parallel Haskell''' remains under very active development. The [wiki:DataParallel current state of play], including some benchmark figures is on the wiki.  We also wrote a substantial paper [http://research.microsoft.com/~simonpj/papers/ndp "Harnessing the multicores: nested data parallelism in Haskell"] for FSTTCS; you may find this paper a useful tutorial on the whole idea of nested data parallelism. 
     51 
     52 * We hope that Max Bolingbroke's '''Dynamically Loaded Plugins''' summer of code project will be merged in time for 6.12.  Part of this is a new, modular system for [wiki:Annotations user-defined '''annotations'''], rather like Java or C# attributes.  These attributes are persisted into interface files, can be examined and created by plugins, or by GHC API clients. 
     53 
     54 * Likewise, Donnie Jones's project for '''profiling parallel programs''' should be merged in time for 6.12 
     55 
     56 * Simon Marlow is working on '''improving parallel performance''', incorporating the work done by Jost Berthold during his internship at Microsoft in the summer of 2008.  The plan is to make writing performant parallel programs less of a trial-and-error process, by whacking as many bottlenecks as we can find in the runtime system.   We're already making significant improvements, and there's plenty more low-hanging fruit to pick.  One large project that we hope to tackle is the issue of doing independent per-CPU garbage collection. 
     57 
     58 * '''Shared Libraries''', are inching ever closer to being completed.  Clemens Fruhwirth has been working on polishing the support for shared libraries on Unix systems in particular, and when the remaining issues are ironed out we should be able to roll them out in a release. 
     59 
     60 * Finally, '''unicode text I/O''' and '''dynamic libraries''' were slated for 6.10 but weren't quite ready in time, so we certainly expect those to make it for in 6.12 
    661 
    762 * 6.12: