details.</para>
<para>GHC comes with a large collection of libraries, with
- everything from parser combinators to networking. These are all
- described in <xref linkend="book-hslibs">.</para>
+ everything from parser combinators to networking. The libraries are
+ described in separate documentation.</para>
<Sect1 id="mailing-lists-GHC">
<Title>Meta-information: Web sites, mailing lists, etc.</Title>
<varlistentry>
<term>glasgow-haskell-users:</term>
<listitem>
- <para>This list is for GHC users to chat among
- themselves.</para>
+ <para>This list is for GHC users to chat among themselves.
+ If you have a specific question about GHC, please check the
+ FAQ first (<xref linkend="faq">).</para>
<variablelist>
<varlistentry>
</sect1>
+ <sect1 id="bug-reporting">
+ <title>Reporting bugs in GHC</title>
+ <indexterm><primary>bugs</primary><secondary>reporting</secondary>
+ </indexterm>
+ <indexterm><primary>reporting bugs</primary>
+ </indexterm>
+
+ <para>Glasgow Haskell is a changing system so there are sure to be
+ bugs in it. </para>
+
+ <para>To report a bug, either:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>Go to the <ulink
+ url="http://sourceforge.net/projects/ghc/">SoureForge GHC
+ page</ulink>, go to the <quote>bugs</quote> section, click on
+ <quote>submit</quote>, and enter your bug report. You can also
+ check the outstanding bugs here and search the archives to make
+ sure it hasn't already been reported. Or:</para>
+ </listitem>
+ <listitem>
+ <para>Email your bug report to
+ <Email>glasgow-haskell-bugs@haskell.org</Email>. </para>
+ </listitem>
+ </itemizedlist>
+
+ <sect2>
+ <title>How do I tell if I should report my bug?</title>
+
+ <para>Take a look at the FAQ (<xref linkend="faq">) and <xref
+ linkend="wrong">, which will give you some guidance as to
+ whether the behaviour you're seeing is really a bug or
+ not.</para>
+
+ <para>If it is a bug, then it might have been reported before:
+ try searching the mailing list archives. The archives don't
+ have a built-in search facility, but we find that <ulink
+ url="http://www.google.com/">Google</ulink>'s site search works
+ pretty well: enter
+ <quote><literal>site:www.haskell.org</literal></quote> followed
+ by your search term into Google.</para>
+
+ <para>If in doubt, just report it.</para>
+ </sect2>
+
+ <sect2>
+ <title>What to put in a bug report</title>
+ <indexterm><primary>bug reports</primary><secondary>contents</secondary></indexterm>
+
+ <para>The name of the bug-reporting game is: facts, facts,
+ facts. Don't omit them because “Oh, they won't be
+ interested…”</para>
+
+ <orderedlist>
+ <listitem>
+ <para>What kind of machine are you running on, and exactly
+ what version of the operating system are you using?
+ (on a Unix system, <Command>uname -a</Command> or <Command>cat
+ /etc/motd</Command> will show the desired information.)</para>
+ </listitem>
+
+ <listitem>
+ <para> What version of GCC are you using? <Command>gcc
+ -v</Command> will tell you.</para>
+ </listitem>
+
+ <listitem>
+ <para> Run the sequence of compiles/runs that caused the
+ offending behaviour, capturing all the input/output in a
+ “script” (a UNIX command) or in an Emacs shell
+ window. We'd prefer to see the whole thing.</para>
+ </listitem>
+
+ <listitem>
+ <para> Be sure any Haskell compilations are run with a
+ <Option>-v</Option> (verbose) flag, so we can see exactly
+ what was run, what versions of things you have, etc.</para>
+ </listitem>
+
+ <listitem>
+ <para> What is the program behaviour that is wrong, in your
+ opinion?</para>
+ </listitem>
+
+ <listitem>
+ <para> If practical, please send enough source files for us
+ to duplicate the problem.</para>
+ </listitem>
+
+ <listitem>
+ <para> If you are a Hero and track down the problem in the
+ compilation-system sources, please send us patches relative
+ to a known released version of GHC, or whole files if you
+ prefer.</para>
+ </listitem>
+ </orderedlist>
+ </sect2>
+ </sect1>
+
<sect1 id="version-numbering">
<title>GHC version numbering policy</title>
<indexterm><primary>version, of ghc</primary></indexterm>
- <para>As of GHC version 4.08, we have adopted the following
- policy for numbering GHC versions:</para>
+ <para>As of GHC version 6.0, we have adopted the following policy
+ for numbering GHC versions:</para>
<variablelist>
<varlistentry>
<term>Stable Releases</term>
<listitem>
- <para>These are numbered <literal>x.yy.z</literal>, where
- <literal>yy</literal> is <emphasis>even</emphasis>, and
- <literal>z</literal> is the patchlevel number (the trailing
- <literal>.z</literal> can be omitted if <literal>z</literal>
+ <para>These are numbered <literal><replaceable>x</replaceable>.<replaceable>y</replaceable>.<replaceable>z</replaceable></literal>, where
+ <replaceable>y</replaceable> is <emphasis>even</emphasis>, and
+ <replaceable>z</replaceable> is the patchlevel number (the trailing
+ <literal>.<replaceable>z</replaceable></literal> can be omitted if <replaceable>z</replaceable>
is zero). Patchlevels are bug-fix releases only, and never
change the programmer interface to any system-supplied code.
However, if you install a new patchlevel over an old one you
<para>The value of <literal>__GLASGOW_HASKELL__</literal>
(see <xref linkend="c-pre-processor">) for a major release
- <literal>x.yy.z</literal> is the integer
- <literal>xyy</literal>.</para>
+ <literal><replaceable>x</replaceable>.<replaceable>y</replaceable>.<replaceable>z</replaceable></literal>
+ is the integer <replaceable>xyy</replaceable> (if
+ <replaceable>y</replaceable> is a single digit, then a leading zero
+ is added, so for example in version 6.2 of GHC,
+ <literal>__GLASGOW_HASKELL__==602</literal>).</para>
<indexterm>
<primary><literal>__GLASGOW_HASKELL__</literal></primary>
</indexterm>
<para>We may make snapshot releases of the current
development sources from time to time, and the current
sources are always available via the CVS repository (see the
- GHC web site for details).</para>
+ <ulink url="http://www.haskell.org/ghc/">GHC web
+ site</ulink> for details).</para>
<para>Snapshot releases are named
- <literal>x.yy.YYYYMMDD</literal> where <literal>yy</literal>
- is <emphasis>odd</emphasis>, and <literal>YYYYMMDD</literal>
- is the date of the sources from which the snapshot was
- built. In theory, you can check out the exact same sources
- from the CVS repository using this date.</para>
+ <literal><replaceable>x</replaceable>.<replaceable>y</replaceable>.YYYYMMDD</literal>
+ where <literal>y</literal> is <emphasis>odd</emphasis>, and
+ <literal>YYYYMMDD</literal> is the date of the sources from
+ which the snapshot was built. In theory, you can check out
+ the exact same sources from the CVS repository using this
+ date.</para>
<para>The value of <literal>__GLASGOW_HASKELL__</literal>
for a snapshot release is the integer
- <literal>xyy</literal>. You should never write any
+ <replaceable>xyy</replaceable>. You should never write any
conditional code which tests for this value, however: since
interfaces change on a day-to-day basis, and we don't have
finer granularity in the values of
<para>The version number of your copy of GHC can be found by
invoking <literal>ghc</literal> with the
- <literal>--version</literal> flag (see <xref
+ <literal>––version</literal> flag (see <xref
linkend="options-help">).</para>
</sect1>
-&relnotes
+&relnotes;
</Chapter>
projects / ghc-hetmet.git / blobdiff