Several simple doc fixes (#1560)

BUILDING.rst

@@ -15,20 +15,20 @@ Clone the git repository::
 UNIX
 ====
 
+.. note:: Much of what is described here is encoded into
+          `release-with-batteries.sh
+          <https://github.com/dylan-lang/opendylan/blob/master/build/unix/release-with-batteries.sh>`_
+          and running that script may be sufficient.
+
 Dependencies
 ------------
 
-Binary releases come packaged with all of the necessary
-dependencies. The current binary release includes
+Binary releases come packaged with all of the necessary dependencies. The
+current binary release includes
 
-- `LLVM/Clang
-  <https://github.com/llvm/llvm-project/releases/tag/llvmorg-10.0.1
-  version 10.0.1>`_ (subsetted to include only necessary components)
-- `LLVM libunwind
-  <https://clang.llvm.org/docs/Toolchain.html#unwind-library>`_
-  (snapshot revision `22b615a9
-  <https://github.com/llvm/llvm-project/tree/22b615a96593f13109a27cabfd1764ec4f558c7a>`_)
-- `BDW GC 8.0.4 <https://github.com/ivmai/bdwgc/releases/tag/v8.0.4>`_
+- `LLVM/Clang <https://github.com/llvm/llvm-project>`_ (subsetted to include
+  only necessary components, including libunwind)
+- `BDW GC <https://github.com/ivmai/bdwgc>`_
 
 If you build from source, you may need to supply these dependencies as
 described below.
@@ -38,7 +38,7 @@ All 64-bit platforms and macOS must use the Boehm Demers Weiser conservative GC
 is only integrated with the HARP back-end, which itself only works on 32-bit
 x86 platforms.
 
-* 64-bit systems and macOS (LLVM or C back-end) -> `boehm-gc
+* 64-bit systems (LLVM or C back-end) -> `boehm-gc
   <https://github.com/ivmai/bdwgc>`_, usually installed via a package (see
   below).
 * 32-bit x86 Linux or FreeBSD (HARP back-end) -> `MPS 1.114
@@ -64,7 +64,7 @@ FreeBSD. If available, it is used to display stack traces for
 unhandled error conditions. (The ``libunwind`` API is built-in on
 macOS.)
 
-You may also want to install ``lldb-10`` for debugging if you are using the LLVM
+You may also want to install ``lldb`` for debugging if you are using the LLVM
 back-end.
 
 Building

CONTRIBUTING.rst

@@ -1,7 +1,7 @@
 How to Contribute
 =================
 
-If you would like to start contributing to Open Dylan, please see `How to
-Contribute to Open Dylan <https://opendylan.org/hacker-guide/index.html>`_ or
-open the file `documentation/hacker-guide/source/index.rst` in this
-distribution for guidelines and ideas on where to start. Thanks!
+If you would like to start contributing to Open Dylan, please see the `Open
+Dylan Hacker's Guide <https://opendylan.org/hacker-guide/>`_ or open the file
+`documentation/hacker-guide/source/index.rst` in this distribution for
+guidelines and ideas on where to start. Thanks!

README.md

@@ -30,11 +30,11 @@ the same directory).
 ## What Next?
 
 If this is your first time trying Open Dylan, take a look at the [Getting
-Started guide](http://opendylan.org/documentation/getting-started-cli/).
+Started](https://opendylan.org/getting-started-cli/) guide.
 
 See also:
 
 *  [BUILDING.rst](BUILDING.rst) - how to build the compiler and IDE
-*  [How to Contribute to Open
-   Dylan](https://opendylan.org/documentation/hacker-guide/contribute.html)
+*  See the [Open Dylan Hacker's Guide](https://opendylan.org/hacker-guide/) for
+   how to contribute to Open Dylan or its libraries.
 *  [opendylan.org](https://opendylan.org) - our main website

documentation/getting-started-ide/source/coloring.rst

@@ -254,7 +254,7 @@ We can recompile the application to see what effect our change has had.
 The refreshed coloring shows the call to ``make`` on ``<reversi-board>`` in
 the *reversi-game-board* slot definition in light gray. This coloring
 means that the compiler determined which ``make`` method to call, computed
-the result of the call—a ``<reversi-board>`` object—and inlined the
+the result of the call — a ``<reversi-board>`` object — and inlined the
 object.
 
 Looking further down *game.dylan*, notice that the definition of
@@ -332,7 +332,7 @@ being made.
 
 The *size(squares)* call is now colored green. Green coloring means the
 compiler determined that the call was equivalent to a slot
-access—particularly, an access to slot having a fixed offset from the
+access — particularly, an access to a slot having a fixed offset from the
 memory address at which its class is located. The compiler removed the
 need for run-time method dispatch by replacing the call with code to
 access the location that would contain the slot value.

documentation/getting-started-ide/source/com-projects.rst

@@ -44,7 +44,7 @@ Creating the server stubs library
 First we use the New Project wizard to create a Dylan library defining
 server-side stubs for the encryption interface.
 
-Choose **File > New…** from the main window.
+Choose **File > New...** from the main window.
 
 #. Select **Project** and click **OK**.
 
@@ -57,7 +57,7 @@ The next page allows you to name a type library to be translated. Most
 COM components store the location of their type libraries in the Windows
 Registry. These registered type libraries are listed in the Installed
 Type Libraries section of the window. You can select a type library from
-the list, or click **Browse…** in the Location pane to select a type
+the list, or click **Browse...** in the Location pane to select a type
 library file from disk.
 
 .. figure:: images/motwiz.png
@@ -67,7 +67,7 @@ library file from disk.
 
 In this case, we use a type library supplied with Open Dylan.
 
-#. Click **Browse…** and navigate to the Open Dylan examples folder.
+#. Click **Browse...** and navigate to the Open Dylan examples folder.
 
 The folder required is called Examples and is placed under the top-level
 Open Dylan folder.
@@ -164,7 +164,7 @@ The specification file looks something like this:
 .. code-block:: dylan
 
     Origin: COM-type-library
-    Type-library: C:\\Program Files\\Open Dylan\\Examples\\…\\RotNExample.tlb
+    Type-library: C:\\Program Files\\Open Dylan\\Examples\\...\\RotNExample.tlb
     Module: type-library-module
     Module-file: type-library-module.dylan
     Generate: dispatch-servers
@@ -254,7 +254,7 @@ Creating the server
 
 Now we create the actual server application.
 
-Choose **File > New…** from the main window.
+Choose **File > New...** from the main window.
 
 #. Select *Project* and click **OK**.
 
@@ -468,15 +468,15 @@ Creating the client stubs library
 Now we create a project for the client-side stubs of the encryption
 interface.
 
-Choose **File > New…** from the main window.
+Choose **File > New...** from the main window.
 
 #. Select **Project** and click **OK**.
 
 The New Project wizard appears.
 
 #. In the Project Type section, select "Interface to COM Type Library"
    and click **Next**.
-#. Click **Browse…** and navigate to the Open Dylan examples folder.
+#. Click **Browse...** and navigate to the Open Dylan examples folder.
 
 The folder required is called Examples and is placed under the top-level
 Open Dylan folder.
@@ -510,7 +510,7 @@ Note that the "OLE Automation" option on the "OLE Automation support"
 page is automatically selected. That is what we want.
 
 #. Click **Next**.
-#. Choose the "NoneÝ" option from "Database support" and click **Next**.
+#. Choose the "None" option from "Database support" and click **Next**.
 
 We are now at the final page of the New Project wizard.
 
@@ -578,7 +578,7 @@ Creating the client
 
 Now we create the actual client application.
 
-Choose **File > New…** from the main window.
+Choose **File > New...** from the main window.
 
 #. Select **Project** and click **OK**.
 
@@ -664,7 +664,7 @@ return ``#t``, and the server to call ``register-coclass``.
 
 Open the RotNExample-server project and build it.
 
-#. Select *Project > Settings…* in the RotNExample-server project
+#. Select *Project > Settings...* in the RotNExample-server project
    window.
 
 The Project Settings dialog appears.
@@ -685,7 +685,7 @@ the environment.
 First, however, we need to remove the */RegServer* argument from the
 project settings, so that the server can run normally.
 
-#. Select **Project > Settings…** in the RotNExample-server project
+#. Select **Project > Settings...** in the RotNExample-server project
    window.
 
 The Project Settings dialog appears.

documentation/getting-started-ide/source/debug.rst

@@ -312,7 +312,7 @@ of an interactive evaluation.
 -  If you issue the pause command (**Application > Pause** or
 
 -  If you issue the pause command from the project window or editor, the
-   debugger for the application’s main thread is refreshed.
+   debugger for the application's main thread is refreshed.
 
 In all of these circumstances, any other open debugger windows will not
 be refreshed unless you choose **View > Refresh** in them. If you choose
@@ -346,7 +346,7 @@ In a debugger window, the commands act upon the application that created
 the thread being debugged. In an editor window, the commands act upon
 the application of the active project. (Note that the **Application** menu
 is not available in the editor if the source file being edited is not
-part of the active project—the project whose name is visible in the main
+part of the active project — the project whose name is visible in the main
 window's drop-down list. See `The active project`_ for more details.)
 
 .. index::
@@ -466,7 +466,7 @@ to set things running, such as a call to start an event loop in a
 windowing application. See :ref:`start-function` for details.
 
 You can specify a start function on the Debug page of the **Project >
-Settings…** dialog. When you use **Application > Debug** or **Application >
+Settings...** dialog. When you use **Application > Debug** or **Application >
 Interact**, the environment places a temporary breakpoint on the start
 function so that the application starts and then enters the debugger on
 entry to the start function. For this reason, the expression that calls
@@ -497,7 +497,7 @@ debugger.
 Nonetheless, for debugging it is still useful to be able to pause the
 DLL once it has initialized completely but before it exits. To do this,
 simply remove the name in the Start Function section of the **Project >
-Settings…** dialog's Debug page. Then, when you choose **Application >
+Settings...** dialog's Debug page. Then, when you choose **Application >
 Debug** or **Application > Interact**, the debugger lets the DLL execute
 all its top-level expressions, and pauses the DLL just as its main
 thread is about to exit. This gives you access to all the definitions
@@ -519,7 +519,7 @@ Interact** the environment runs the EXE. The point at which the EXE is
 paused again depends on whether you supply a start function.
 
 Alternatively, you can supply your own EXE in the Executable field of
-the **Project > Settings…** dialog's Debug page. The **Application > Start**,
+the **Project > Settings...** dialog's Debug page. The **Application > Start**,
 **Application > Debug**, and **Application > Interact** commands then
 call your EXE and behave in the same way as if your EXE was the
 project target file. That is to say, execution of the EXE proceeds
@@ -537,7 +537,7 @@ DLLs, you can use the same debugging processes as described in
 
 If you want to test your server or control in a container application,
 simply enter the name of the application executable in the Executable
-field of the **Project > Settings…** dialog's Debug page. This executable
+field of the **Project > Settings...** dialog's Debug page. This executable
 could be any OLE container, such as WordPad. The **Application > Start**,
 **Application > Debug**, and **Application > Interact** commands then
 execute the container executable. Execution proceeds normally until the
@@ -566,15 +566,15 @@ handled, or due to it reaching a breakpoint. You cannot do so if the
 application has paused because you used **Application > Pause**. (Use
 **Application > Resume** to restart your application in that case.)
 
-To select a restart to be signalled, choose **Thread > Continue…**, which
+To select a restart to be signalled, choose **Thread > Continue...**, which
 displays a dialog listing all available restarts.
 
 For convenience, there are two other menu items for signalling :drm:`<abort>`
 restarts, which are defined to mean "terminate the current computation".
 
-**Thread > Abort** signals the innermost available :drm:`<abort>` restart—that
-is, it aborts as little as possible—whereas **Thread > Abort All** signals
-the outermost :drm:`<abort>` restart—that is, it aborts as much as possible.
+**Thread > Abort** signals the innermost available :drm:`<abort>` restart — that
+is, it aborts as little as possible — whereas **Thread > Abort All** signals
+the outermost :drm:`<abort>` restart — that is, it aborts as much as possible.
 
 Although the meaning of :drm:`<abort>` restarts is part of the Dylan
 language, your application must provide handlers to implement them. If
@@ -596,7 +596,7 @@ time. The command we have seen so far, **Application > Debug**, debugs
 only the application's main thread. To debug another thread in the
 application, choose **Go > Threads** from the debugger, project window, or
 editor. From the debugger window you can also use **Thread > Select
-Thread…**. To bring up multiple debugger windows, use **Window > New
+Thread...**. To bring up multiple debugger windows, use **Window > New
 Window** from an existing debugger.
 
 The **Go > Threads** command launches a browser on the application itself,
@@ -1008,7 +1008,7 @@ The answer is that the editor has an *active project*. This is the
 project whose name is visible in the drop-down list in the main window.
 You can change the active project by changing the setting in the list.
 The active project is always one of the projects that have been
-explicitly opened—that is, one for which there is a project window.
+explicitly opened — that is, one for which there is a project window.
 
 The editor also uses the active project to determine two other things.
 First, the editor shows breakpoint information in its leftmost column
@@ -1018,7 +1018,7 @@ source files that are not part of the active project.
 
 A project can become the active project automatically as well as by
 being set explicitly in the main window's drop-down list. The main
-window's **Options > Environment Options…** dialog has two options on the
+window's **Options > Environment Options...** dialog has two options on the
 General page controlling when projects become active automatically:
 "Project becomes active when opened" and "Project becomes active when
 application started".
@@ -1088,7 +1088,7 @@ development environment, via **Application > Start** and similar commands.
 
 When you set a breakpoint in a function that is in a used library, the
 breakpoint does not go into the project that owns the function, but
-instead into the project you are browsing—or the active project, if in
+instead into the project you are browsing — or the active project, if in
 the editor.
 
 Setting breakpoints on functions
@@ -1200,7 +1200,7 @@ complete list of commands follows.
 "Clear Breakpoint"
     Removes any breakpoint at the line the mouse pointer is on.
 
-Edit Breakpoint Options…
+Edit Breakpoint Options...
     Pops up a dialog for editing breakpoint options. See `Breakpoint
     options`_.
 
@@ -1236,7 +1236,7 @@ all enabled breakpoints.
 Breakpoint options
 ------------------
 
-The **Edit Breakpoint Options…** dialog, available from the shortcut
+The **Edit Breakpoint Options...** dialog, available from the shortcut
 (right-click) menu, contains the following sections.
 
 -  "Enabled" Check item for toggling whether a breakpoint is enabled or
@@ -1385,8 +1385,8 @@ run two instances of the environment, with one debugging the client and
 the other debugging the server: if any libraries are shared between the
 applications, both environment instances will attempt to lock the
 compiler database files for those libraries. Since all applications
-ultimately use the Dylan library, and most share other libraries—not the
-least of which in this case being networking libraries—using two
+ultimately use the Dylan library, and most share other libraries — not the
+least of which in this case being networking libraries — using two
 Open Dylan processes is never a practical debugging method.
 
 This is not a disadvantage. By running both client and server in one
@@ -1398,7 +1398,7 @@ Once you have both projects open, you can start both applications up.
 Note that by default the action of starting a project will switch the
 active project, so the last project you start will be the active one by
 default. You can change this behavior in the main window with **Options >
-Environment Options…** so that the active project does not switch in this
+Environment Options...** so that the active project does not switch in this
 situation. See `The active project`_ for more information.
 
 If you need to rebuild a library shared between the client and server,
@@ -1427,12 +1427,12 @@ Exporting a bug report or a compiler warnings report
 ====================================================
 
 You can save a formatted bug report or compiler warnings report for an
-application by choosing **File > Export…** in the debugger or project
+application by choosing **File > Export...** in the debugger or project
 window. The bug report includes a stack backtrace for all threads in the
 application, while the compiler warnings report contains the same
 information provided in the project window's Warnings page.
 
-The Export… dialog gives you the option of saving the report as either
+The Export... dialog gives you the option of saving the report as either
 text HTML. If you choose to save the report to a file, an editor window
 automatically opens to show the file. The saved report contains a
 section for user-supplied information into which you can type
@@ -1445,7 +1445,7 @@ supplemental text.
 .. figure:: images/export.png
    :align: center
 
-   The Export… dialog.
+   The Export... dialog.
 
 .. index::
    single: debugging; debugger options
@@ -1458,7 +1458,7 @@ Debugger options
 The **View > Debugger Options** command brings up a dialog that controls
 the options for the debugger. This dialog has three property pages:
 Stack, Exceptions, and Misc. The options on these pages apply on a
-per-thread basis—you can have different settings for different threads'
+per-thread basis — you can have different settings for different threads'
 debuggers.
 
 .. index::