<Para>
Glasgow Haskell is a changing system so there are sure to be bugs in
-it. Please report them to <Email>glasgow-haskell-bugs@haskell.org</Email>! (However, please
+it. Please report them to
+<Email>glasgow-haskell-bugs@haskell.org</Email>! (However, please
check the earlier part of this section to be sure it's not a known
not-really-a problem.)
</Para>
<ListItem>
<Para>
- What kind of machine are you running on, and exactly what
-version of the operating system are you using? (<Command>uname -a</Command> or <Command>cat
-/etc/motd</Command> will show the desired information.)
+What kind of machine are you running on, and exactly what version of
+the operating system are you using? (<Command>uname -a</Command> or
+<Command>cat /etc/motd</Command> will show the desired information.)
</Para>
</ListItem>
<ListItem>
<Para>
- If practical, please send enough source files/interface files
-for us to duplicate the problem.
+ If practical, please send enough source files for us to duplicate the
+ problem.
</Para>
</ListItem>
<ListItem>
<Para>
-If it crashes with the normal
-collector, but not when you force two-space collection (<Option>-F2s</Option>
-runtime flag), then it <Emphasis>probably is</Emphasis> a GC bug.
+If it crashes with the normal collector, but not when you force
+two-space collection (<Option>-G1</Option> runtime flag), then it
+<Emphasis>probably is</Emphasis> a GC bug.
</Para>
</ListItem>
</Para>
<Para>
-If it <Emphasis>is</Emphasis> a GC bug, you may be able to avoid it by using a
-particular heap size or by using a <Option>-F2s</Option> runtime flag. (But don't
-forget to report the bug!!!)
+If it <Emphasis>is</Emphasis> a GC bug, you may be able to avoid it by
+using a particular heap size or by using a <Option>-G1</Option>
+runtime flag. (But don't forget to report the bug!!!)
</Para>
<Para>
</Para>
<Para>
-The parts of the compiler that seem most prone to wandering off for a
-long time are the abstract interpreters (strictness and update
-analysers). You can turn these off individually with
-<Option>-fno-strictness</Option><IndexTerm><Primary>-fno-strictness anti-option</Primary></IndexTerm> and
-<Option>-fno-update-analysis</Option>.<IndexTerm><Primary>-fno-update-analysis anti-option</Primary></IndexTerm>
+The part of the compiler that is occasionally prone to wandering off
+for a long time is the strictness analyser. You can turn this off
+individually with <Option>-fno-strictness</Option>.
+<IndexTerm><Primary>-fno-strictness anti-option</Primary></IndexTerm>
</Para>
<Para>
</Para>
<Para>
-“I think I have a space leak…” Re-run your program with
-<Option>+RTS -Sstderr</Option>,<IndexTerm><Primary>-Sstderr RTS option</Primary></IndexTerm> and remove all doubt!
-(You'll see the heap usage get bigger and bigger…) [Hmmm…this
-might be even easier with the <Option>-F2s</Option><IndexTerm><Primary>-F2s RTS option</Primary></IndexTerm> RTS
-option; so… <Command>./a.out +RTS -Sstderr -F2s</Command>...]
+“I think I have a space leak…” Re-run your program
+with <Option>+RTS -Sstderr</Option>, and remove all doubt! (You'll
+see the heap usage get bigger and bigger…)
+[Hmmm…this might be even easier with the
+<Option>-G1</Option> RTS option; so… <Command>./a.out +RTS
+-Sstderr -G1</Command>...]
+<IndexTerm><Primary>-G RTS option</Primary></IndexTerm>
+<IndexTerm><Primary>-Sstderr RTS option</Primary></IndexTerm>
</Para>
<Para>
-Once again, the profiling facilities (<XRef LinkEnd="profiling">) are the basic tool for demystifying the space
-behaviour of your program.
+Once again, the profiling facilities (<XRef LinkEnd="profiling">) are
+the basic tool for demystifying the space behaviour of your program.
</Para>
<Para>