| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
If an argument of a data constructor has a type variable head, it is
irreducible and the same type class can be copied into the constraint.
(Formerly we just did this for type variable arguments.)
|
|
|
|
|
|
|
|
| |
Due to the use of pattern guards in Haddock, GHC was called with
-fglasgow-exts. This in turn enables bang patterns, too, which broke the
Haddock build. Removing some unnecessary pattern guards seemed to be the
better way of fixing this instead of using a pragma to disable pattern
guards.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Contributed by Brad Bowman <bsb@bereft.net>, thanks!
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
The --wiki, or rather the --comment-* options are now documented.
There is probably no need to have haddock invoke unlit or cpp itself since
it can now pick up the line pragmas to get the source locations right. Tools
like Cabal will arrange for preprocessors to be run so there is less of a need
for tools like haddock to do it themselves.
|
| |
|
| |
|
|
|
|
|
|
| |
This is a purely cosmetic patch, feel free to ignore it.
The only trickery going on is that we don't display the deprecated -s, --source
flags in the help message, but we do still accept them.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of incomprehensable URL substitutions like ${MODULE/./-|?m=%} we now
use three seperate command line flags for the top level, per-module and
per-entity source and wiki links. They are:
--source-base, --source-module, --source-entity
--comments-base, --comments-module, --comments-entity
We leave -s, --source as an alias for --source-module which is how that option
behaved previously.
The long forms of the substitutions are still available, ${FILE} ${MODULE} etc
and the only non-trivial substitution is ${MODULE/./c} to replace the '.'
characters in the module name with any other character c. eg ${MODULE/./-}
Seperating the source and wiki url flags has the added bonus that they can
be turned on or off individually. So users can have per-module links for
example without having to also have per-entity links.`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Like the wiki link on the contents and index page, add a source code link too.
Extend the wiki & source URL variable expansion syntax.
The original syntax was:
%F for the source file name (the .hs version only, not the .lhs or .hs.pp one)
%M for the module name (with '.' replaced by '/')
The new syntax is:
%F or %{FILE} for the original source file name
%M or %{MODULE} for the module name (no replacements)
%N or %{NAME} for the function/type export name
%K or %{KIND} for a type/value flag "t" or "v"
with these extensions:
%{MODULE/./c} to replace the '.' module seperator with any other char c
%{VAR|some text with the % char in it} which means if the VAR is not in use in
this URL context then "" else replace the given text with the '%' char
replaced by the string value of the VAR. This extension allows us to construct
URLs wit optional parts, since the module/file name is not available for the
URL in the contents/index pages and the value/type name is not available for
the URL at the top level of each module.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Teach haddock about C and Haskell style line pragmas. Extend the lexer/parser's
source location tracking to include the file name as well as line/column. This
way each AST item that is tagged with a SrcLoc gets the original file name too.
Use this original file name to add source links to each exported item, in the
same visual style as the wiki links. Note that the per-export source links are
to the defining module rather than whichever module haddock pretends it is
exported from. This is what we want for source code links. The source code link
URL can also contain the name of the export so one could implement jumping to
the actual location of the function in the file if it were linked to an html
version of the source rather than just plain text. The name can be selected
with the %N wild card.
So for linking to the raw source code one might use:
--source=http://darcs/haskell.org/foo/%F
Or for linking to html syntax highlighted code:
--source=http://darcs/haskell.org/foo/%M.html#%N
|
|
|
|
|
|
| |
When the path ends in a file seperator there is no need to add another.
Now using "--wiki=http://blah.com/foo/" should do the right thing.
(Code snippet adapted from Isaac's FilePath package.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In each module, for each "top level" exported entity we add a hyper link to a
corresponding wiki page. The link url gets the name of the exported entity as
a '#'-style anchor, so if there is an anchor in the page with that name then
the users browser should jump directly to it. By "top level" we mean functions,
classes, class members and data types (data, type, newtype), but not data
constructors, class instances or data type class membership.
The link is added at the right of the page and in a small font. Hopefully this
is the right balance of visibility/distraction.
We also include a link to the wiki base url in the contents and index pages.
|
| |
|
|
|
|
|
|
|
|
| |
So each html page gets an extra link (placed next to the source code and
contents links) to a corresponding wiki page. The idea is to let readers
contribute their own notes, examples etc to the documentation.
Also slightly tidy up the code for the --source option.
|
|
|
|
|
|
|
|
|
| |
Add a separate configure script and build system for building the
documentation. The configure and Makefile code is stolen from
fptools. This is left as a separate build system so that the main
Cabal setup doesn't require a Unix build environment or DocBook XML
tools.
|
| |
|
| |
|
|
|
|
|
|
| |
extractRecSel: ignore non-record constructors (fixes a crash when
using datatypes with a mixture of record and non-record style
constructors).
|
|
|
|
| |
Document new behaviour of -s option
|
|
|
|
| |
Add a bug
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reverted to previous version (but with bumped version number), the last
commit broke RPM building on SuSE systems due to differently named
dependencies.
As a clarification: All .spec files in the repository have to work at least
on SuSE, because that's the system I'm using. And as "Mr. Building Police",
I reserve me the right to keep them that way... >:-) It might very well be
the case that we need different .spec files for different platforms, so
packagers which are unhappy with the current .spec files should contact me,
stating the actual problems.
|
|
|
|
| |
replace mingw tests with $(Windows)
|
|
|
|
| |
spec file from Jens Peterson
|
|
|
|
| |
0.7 changes
|
|
|
|
|
|
| |
name hierarchical HTML files as A-B-C.html instead of A.B.C.html. The
old way confused Apache because the extensions are sometimes
interpreted as having special meanings.
|
|
|
|
| |
wibble
|
|
|
|
| |
Allow "licence" as an alternate spelling of "license"
|
|
|
|
| |
Warning/versionitis police
|
|
|
|
| |
fix 3 bugs in --use-package, and document it.
|
|
|
|
| |
Add a TODO item
|
|
|
|
|
| |
Hack haddock's lexer to accept the output from Apple's broken version of
cpp (Apple's cpp leaves #pragma set_debug_pwd directives in it's output).
|
|
|
|
|
|
| |
Another attempt at lining up the package names on the contents page.
Now, they line up with Konqueror, and almost line up with Firefox & IE
(different layout in each case).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Attempt to fix the layout of the package names in the contents.
Having tried just about everything, the only thing I can get to work
reliably is to make the package names line up on a fixed offset from
the left margin. This obviously isn't ideal, so anyone else that
would like to have a go at improving it is welcome. One option is to
remove the +/- buttons from the contents list and go back to a plain
table.
The contents page now uses CSS for layout rather than tables. It
seems that most browsers have different interpretations of CSS layout,
so only the simplest things lead to consistent results.
|
|
|
|
| |
version 0.7
|
|
|
|
| |
Fix documentation regarding the module attributes.
|
|
|
|
|
|
|
| |
sort lists of instances by
- arity of the type constructors (so higher-kinded instances come first)
- name of the class
- argument types
|