Custom Query (117 matches)
Results (31 - 33 of 117)
|#1568||fixed||Haddock: refactor to move doc parsing code from GHC into Haddock||simonmar|
The code for parsing and renaming Haddock comments is currently in GHC. This is clearly not good, since any changes to the comment format have to be made in GHC. It was done this way because GHC implements the module system and can therefore resolve links to names from documentation.
However, the GHC API now provides a way to get hold of the top-level environment. This allows us to move parsing and renaming of Haddock comments back into Haddock.
This would be an improvement for modularity, and would make the Haddock markup format easier to modify in the future.
Please note that we so far only speak about parsing and renaming the Haddock comments themselves, and not about parsing Haskell code containing comments. The parsing of Haskell code containing comments is done the GHC parser, but could perhaps also be done separately in Haddock. We have not yet decided if this is a good idea or not, but it could be discussed and experimented with.
|#1569||fixed||Haddock: enhancements and bug fixes||simonmar|
This project is a catch-all for the high-priority enhancements and bug fixes in Haddock. Haddock is a vital tool for the community and could really use a solid 3 months of improvement and bug-fixing. Here are the highest-priority enhancements:
Along with a bunch of defect tickets (Haddock's ticket list is here). The order in which to tackle the tickets would be agreed between student and mentor(s) before starting the project.
The current documentation has the following to say about profiling:
In short, one is limited to analysing various kinds of logs offline. However, it would often help if this information was available while the program is running. Instead of generating graphs with hp2ps, it should be possible to display them in a graphical application (using OpenGL or Hieroglyph, for instance), which would be much more efficient to start with, also letting the programmer zoom in on various parts of the log or change the ordering on the fly without all the manual work needed today.
More importantly, an interactive profiler would open the door to defining triggers on various patterns of resource use (e.g. going above a preset limiting function) and point out runaway cost centres without any human intervention. Ultimately, this information could be fed back to the runtime and used to stop the program, so the programmer could inspect its state in detail at the critical moment.