</varlistentry>
<varlistentry>
+ <term>Do I have to recompile all my code if I upgrade
+ GHC?</term>
+ <listitem>
+ <para>Yes. There are two reasons for this:</para>
+ <itemizedlist>
+ <listitem>
+ <para>GHC does a lot of cross-module optimisation, so
+ compiled code will include parts of the libraries it was
+ compiled against (including the Prelude), so will be
+ deeply tied to the actual version of those libraries it
+ was compiled against. When you upgrade GHC, the libraries
+ may change; even if the external interface of the
+ libraries doesn't change, sometimes internal details may
+ change because GHC optimised the code in the library
+ differently.</para>
+ </listitem>
+ <listitem>
+ <para>We sometimes change the ABI (application binary
+ interface) between versions of GHC. Code compiled with
+ one version of GHC is not necessarily compatible with code
+ compiled by a different version, even if you arrange to
+ keep the same libraries.</para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
<term>Why doesn't GHC use shared libraries?</term>
<listitem>
<para>The subject of shared libraries has come up several
with g++ and gcc 3.0.</para>
</listitem>
</varlistentry>
+
+ <varlistentry>
+ <term>My program is failing with <literal>head []</literal>, or
+ an array bounds error, or some other random error, and I have no
+ idea how to find the bug. Can you help?</term>
+
+ <listitem>
+ <para>Compile your program with <literal>-prof
+-auto-all</literal> (make sure you have the profiling libraries
+installed), and run it with <literal>+RTS -xc -RTS</literal> to get a
+“stack trace” at the point at which the exception was
+raised. See <xref linkend="rts-options-debugging"> for more
+details.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>How do I increase the heap size permanently for a given
+ binary?</term>
+ <listitem>
+ <para>See <xref linkend="rts-hooks">.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>I'm trying to compile my program for parallel execution
+ with the <option>-parallel</option>, and GHC complains with an
+ error like “failed to load interface file for
+ Prelude”.</term>
+ <listitem>
+ <para>GHC doesn't ship with support for parallel execution,
+ that support is provided separately by the <ulink
+ url="http://www.macs.hw.ac.uk/~dsg/gph/">GPH</ulink> project.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>When is it safe to use
+ <literal>unsafePerformIO</literal>?</term>
+ <listitem>
+ <para>We'll give two answers to this question, each of which
+ may be helpful. These criteria are not rigorous in any real
+ sense (you'd need a formal semantics for Haskell in order to
+ give a proper answer to this question), but should give you a
+ feel for the kind of things you can and cannot do with
+ <literal>unsafePerformIO</literal>.</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>It is safe to implement a function or API using
+ <literal>unsafePerformIO</literal> if you could imagine
+ also implementing the same function or API in Haskell
+ without using <literal>unsafePerformIO</literal> (forget
+ about efficiency, just consider the semantics).</para>
+ </listitem>
+
+ <listitem>
+ <para>In pure Haskell, the value of a function depends
+ only on the values of its arguments (and free variables,
+ if it has any). If you can implement the function using
+ <literal>unsafePerformIO</literal> and still retain this
+ invariant, then you're probably using
+ <literal>unsafePerformIO</literal> in a safe way. Note
+ that you need only consider the
+ <emphasis>observable</emphasis> values of the arguments
+ and result.</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>For more information, see <ulink
+ url="http://www.haskell.org/pipermail/glasgow-haskell-users/2002-July/003681.html">this
+ thread</ulink>.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Why does linking take so long?</term>
+ <listitem>
+ <para>Linking a small program should take no more than a few
+ seconds. Larger programs can take longer, but even linking
+ GHC itself only takes 3-4 seconds on our development
+ machines.</para>
+
+ <para>Long link times have been attributed to using Sun's
+ linker on Solaris, as compared to GNU <command>ld</command>
+ which appears to be much faster. So if you're on a Sun box,
+ try switching to GNU <command>ld</command>. <ulink
+ url="http://www.haskell.org/pipermail/glasgow-haskell-users/2002-November/004477.html">This
+ article</ulink> from the mailing list has more
+ information.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+
+ <term>If I explicitely set the buffering on a Handle to
+ "NoBuffering" I'm not able to > enter EOF by typing
+ "Ctrl-D".</term>
+
+ <listitem>
+ <para>This is a consequence of Unixy terminal semantics. Unix
+ does line buffering on terminals in the kernel as part of the
+ terminal processing, unless you turn it off. However, the
+ Ctrl-D processing is also part of the terminal processing
+ which gets turned off when the kernel line buffering is
+ disabled. So GHC tries its best to get NoBuffering semantics
+ by turning off the kernel line buffering, but as a result you
+ lose Ctrl-D. C'est la vie.</para>
+ </listitem>
+ </varlistentry>
</variablelist>
</chapter>
projects / ghc-hetmet.git / blobdiff