Changeset 8606


Ignore:
Timestamp:
Feb 27, 2008, 11:31:54 AM (12 years ago)
Author:
gb
Message:

Rename chapter-level files to not include chapter numbers (so that it'd be
less confusing to change chapter order, remove/introduce chapters, etc.)

Ensure that all chapter-level files have ENTITY definitions in their
DOCTYPE forms.

Define a CCL entity (currently just <literal>CCL</literal>; change all
references to "OpenMCL" to "&CCL;"

Location:
trunk/source/doc/src
Files:
1 edited
14 moved

Legend:

Unmodified
Added
Removed
  • trunk/source/doc/src/build.xml

    r8599 r8606  
    11<?xml version="1.0" encoding="utf-8"?>
    2 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
    3   <chapter><title>Building OpenMCL from its Source Code</title>
    4 
    5     <para>OpenMCL, like many other Lisp implementations, consists of a
     2<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"[
     3<!ENTITY rest "<varname>&amp;rest</varname>">
     4<!ENTITY key "<varname>&amp;key</varname>">
     5<!ENTITY optional "<varname>&amp;optional</varname>">
     6<!ENTITY body "<varname>&amp;body</varname>">
     7<!ENTITY aux "<varname>&amp;aux</varname>">
     8<!ENTITY allow-other-keys "<varname>&amp;allow-other-keys</varname>">
     9<!ENTITY CCL "<literal>CCL</literal>">
     10]>
     11  <chapter><title>Building &CCL; from its Source Code</title>
     12
     13    <para>&CCL;, like many other Lisp implementations, consists of a
    614    kernel and a heap image.  The kernel is an ordinary C program, and
    715    is built with a C compiler.  It provides very basic and
     
    2028    <para>Where will you get a working Lisp compiler?  No worries; you
    2129    can use a precompiled copy of a (slightly older and compatible)
    22     version of OpenMCL.  For help, read on.</para>
     30    version of &CCL;.  For help, read on.</para>
    2331
    2432    <para>In principle it would be possible to use another Lisp as the
    25     host compiler, rather than an old OpenMCL; this would be a
     33    host compiler, rather than an old &CCL;; this would be a
    2634    challenging and experimental way to build, and is not described
    2735    here.</para>
     
    3745      in a compact, machine-readable form. fasl is short for
    3846      &ldquo;<literal>FAS</literal>t
    39       <literal>L</literal>oading&rdquo;.OpenMCL uses different
     47      <literal>L</literal>oading&rdquo;.&CCL; uses different
    4048      pathname types (extensions) to name faslfiles on different
    4149      platforms; see <xref
     
    4856      that the image contains, handle any exceptionsthat occur during
    4957      the execution of that lisp code, and provide variousother forms
    50       of runtime support for that code.OpenMCL uses different
     58      of runtime support for that code.&CCL; uses different
    5159      filenames to name the lisp kernel fileson different platforms;
    5260      see FIXTHIS.</para>
     
    5664      Conceptually, it's not too different from anexecutable file or
    5765      shared library in the OS's native format (ELF orMach-O/dyld
    58       format); for historical reasons, OpenMCL's own heap images are in
     66      format); for historical reasons, &CCL;'s own heap images are in
    5967      their own (fairly simple) format.The term <literal>full heap
    6068      image</literal> refers to a heap image file thatcontains all of
    61       the code and data that comprise OpenMCL.OpenMCL uses different
     69      the code and data that comprise &CCL;.&CCL; uses different
    6270      filenames to name the standard full heapimage files on different
    6371      platforms; see FIXTHIS .</para>
     
    6573      <para>A <indexterm><primary>bootstrapping
    6674      image</primary></indexterm> is a minimal heap image used in
    67       the process of building OpenMCL itself.  The bootstrapping image
    68       containsjust enough code to load the rest of OpenMCL from fasl
     75      the process of building &CCL; itself.  The bootstrapping image
     76      containsjust enough code to load the rest of &CCL; from fasl
    6977      files.  It mayhelp to think of the bootstrapping image as the
    70       egg and the full heapimage as the chicken...OpenMCL uses
     78      egg and the full heapimage as the chicken...&CCL; uses
    7179      different filenames to name the standardbootstrapping image
    7280      files on different platforms; see FIXTHIS .</para>
     
    161169    <sect1 id="Setting-Up-to-Build">
    162170      <title>Setting Up to Build</title>
    163       <para>There are currently three versions of OpenMCL that you
     171      <para>There are currently three versions of &CCL; that you
    164172      might want to use (and therefore might want to build from
    165173      source):</para>
     
    173181        differently</para></listitem>
    174182      </itemizedlist>
    175       <para>All versions are available for download from the OpenMCL
     183      <para>All versions are available for download from the &CCL;
    176184      website in the form of archives that contain everything you need
    177       to work with OpenMCL, including the complete sources, a full
     185      to work with &CCL;, including the complete sources, a full
    178186      heap image, and the foreign-function interface database.</para>
    179187      <para>Version 1.0 archives are named
     
    195203      there may be times when you want to get sources that are more
    196204      recent than the most recent snapshot and use them to build
    197       yourself a new bleeding-edge OpenMCL.  In that case, you should
     205      yourself a new bleeding-edge &CCL;.  In that case, you should
    198206      download and install the latest snapshot, and then update your
    199207      sources via CVS.  At that point you can rebuild and you'll have
    200       the latest and greatest OpenMCL.  The snapshot has CVS
     208      the latest and greatest &CCL;.  The snapshot has CVS
    201209      working-copy information in it, so all you need to do to update
    202210      is</para>
     
    231239      <title>Building Everything</title>
    232240      <para>Given that you now have everything you need, do the
    233       following in a running OpenMCL to bring your Lisp system
     241      following in a running &CCL; to bring your Lisp system
    234242      completely up to date.</para>
    235243      <programlisting>
     
    294302
    295303      <para>This section gives directions on how to rebuild the Lisp
    296       kernel from its source code.  Most OpenMCL users will rarely
     304      kernel from its source code.  Most &CCL; users will rarely
    297305      have to do this.  You probably will only need to do it if you are
    298       attempting to port OpenMCL to a new architecture or extend or enhance
     306      attempting to port &CCL; to a new architecture or extend or enhance
    299307      its kernel in some way.  As mentioned above, this step happens
    300308      automatically when you do
     
    307315      <sect2 id="Kernel-build-prerequisites">
    308316        <title>Kernel build prerequisites</title>
    309         <para>The OpenMCL kernel can be bult with the following widely
     317        <para>The &CCL; kernel can be bult with the following widely
    310318        available tools:</para>
    311319        <itemizedlist>
     
    360368      implementation, all we need to do is load it into memory and
    361369      start using it.</para>
    362       <para>If you're building a new version of OpenMCL, you need to
     370      <para>If you're building a new version of &CCL;, you need to
    363371      build a new heap image.</para>
    364372      <para>(You might also wish to build a heap image if you have a
     
    372380      <sect2 id="Development-cycle">
    373381        <title>Development cycle</title>
    374         <para>Creating a new OpenMCL full heap image consists of the
     382        <para>Creating a new &CCL; full heap image consists of the
    375383        following steps:</para>
    376384        <orderedlist>
    377           <listitem><para>Using your existing OpenMCL, create a
     385          <listitem><para>Using your existing &CCL;, create a
    378386          bootstrapping image</para></listitem>
    379           <listitem><para>Using your existing OpenMCL, recompile your
    380           updated OpenMCL sources</para></listitem>
    381           <listitem><para>Invoke OpenMCL with the bootstrapping image
     387          <listitem><para>Using your existing &CCL;, recompile your
     388          updated &CCL; sources</para></listitem>
     389          <listitem><para>Invoke &CCL; with the bootstrapping image
    382390          you just created (rather than with the existing full heap
    383391          image).</para></listitem>
    384392        </orderedlist>
    385         <para>When you invoke OpenMCL with the bootstrapping image, it
    386         will start up, load al of the OpenMCL fasl files, and save out
     393        <para>When you invoke &CCL; with the bootstrapping image, it
     394        will start up, load al of the &CCL; fasl files, and save out
    387395        a new full heap image.  Voila.  You've created a new heap
    388396        image.</para>
     
    418426      <sect2 id="Generating-a-bootstrapping-image">
    419427        <title>Generating a bootstrapping image</title>
    420         <para>The bootstrapping image isn't provided in OpenMCL
     428        <para>The bootstrapping image isn't provided in &CCL;
    421429        distributions. It can be built from the source code provided
    422430        in distributions (using a lisp image and kernel provided in
     
    425433
    426434        <para>The bootstrapping image is built by invoking a special
    427         utility inside a running OpenMCL heap image to load files
     435        utility inside a running &CCL; heap image to load files
    428436        contained in the <literal>ccl/level-0</literal> directory. The
    429437        bootstrapping image loads several dozen fasl files.  After
     
    434442        <para>Given a source distribution, a lisp kernel, and aheap
    435443        image, one can produce a bootstapping image by first invoking
    436         OpenMCL from the shell:</para>
     444        &CCL; from the shell:</para>
    437445        <programlisting>
    438446shell&gt; openmcl
    439 Welcome to OpenMCL .... !
     447Welcome to &CCL; .... !
    440448?
    441449        </programlisting>
     
    482490        whenever files are <literal>require</literal>d during
    483491        compilation; those warnings can be safely ignored. Depending
    484         on the maturity of the OpenMCL release, calling
     492        on the maturity of the &CCL; release, calling
    485493        <literal>compile-ccl</literal> or
    486494        <literal>xcompile-ccl</literal> may also produce several
  • trunk/source/doc/src/ccl-documentation.xml

    r8568 r8606  
    88<!ENTITY aux "<varname>&amp;aux</varname>">
    99<!ENTITY allow-other-keys "<varname>&amp;allow-other-keys</varname>">
     10<!ENTITY CCL "<literal>CCL</literal>">
    1011]>
    1112
    1213<book lang="en">
    1314 <bookinfo>
    14   <title>OpenMCL Documentation</title>
     15  <title>&CCL; Documentation</title>
    1516 </bookinfo>
    1617
    1718<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
    18             href="01-install.xml"/>
     19            href="install.xml"/>
    1920<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
    20             href="02-build.xml"/>
     21            href="build.xml"/>
    2122<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
    22             href="03-q-and-a.xml"/>
     23            href="q-and-a.xml"/>
    2324<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
    24             href="04-threads.xml"/>
     25            href="threads.xml"/>
    2526<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
    26             href="05-sockets.xml"/>
     27            href="sockets.xml"/>
    2728<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
    28             href="06-external-process.xml"/>
     29            href="external-process.xml"/>
    2930<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
    30             href="07-gray-streams.xml"/>
     31            href="streams.xml"/>
    3132<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
    32             href="08-mop.xml"/>
     33            href="mop.xml"/>
    3334<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
    34             href="09-ffi.xml"/>
     35            href="ffi.xml"/>
    3536<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
    36             href="10-objc-bridge.xml"/>
     37            href="objc-bridge.xml"/>
    3738<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
    38             href="11-platform-notes.xml"/>
     39            href="platform-notes.xml"/>
    3940<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
    40             href="12-gc.xml"/>
     41            href="gc.xml"/>
    4142<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
    42             href="13-implementation.xml"/>
     43            href="implementation.xml"/>
    4344<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
    44             href="14-modifying.xml"/>
     45            href="modifying.xml"/>
    4546
    4647 <index id="Symbol-Index"><title>Symbol Index</title></index>
  • trunk/source/doc/src/external-process.xml

    r8599 r8606  
    77<!ENTITY aux "<varname>&amp;aux</varname>">
    88<!ENTITY allow-other-keys "<varname>&amp;allow-other-keys</varname>">
     9<!ENTITY CCL "<literal>CCL</literal>">
    910]>
    1011
     
    1415    <sect1 id="Subprocess-Overview">
    1516      <title>Overview</title>
    16       <para>OpenMCL provides primitives to run external Unix programs,
     17      <para>&CCL; provides primitives to run external Unix programs,
    1718      to select and connect Lisp streams to their input and output
    1819      sources, to (optionally) wait for their completion and to check
     
    3940? (run-program "sh" '("-c" "ls *.lisp") :output t)
    4041</programlisting>
    41       <para>These last examples will only produce output if OpenMCL's
     42      <para>These last examples will only produce output if &CCL;'s
    4243      current directory contains .lisp files, of course.</para>
    4344    </sect1>
     
    4647      <title>Limitations and known bugs</title>
    4748      <itemizedlist>
    48         <listitem><para>OpenMCL and the external processs may get
     49        <listitem><para>&CCL; and the external processs may get
    4950        confused about whoowns which streams when input, output, or
    5051        error are specified as T and wait is specified as
     
    5253        <listitem><para>External processes that need to talk to a
    5354        terminal device may not work properly; the environment (SLIME,
    54         ILISP) under which OpenMCL is run can affect
     55        ILISP) under which &CCL; is run can affect
    5556        this.</para></listitem>
    5657     
     
    136137                    <listitem>
    137138                      <para>T Specifies that the EXTERNAL-PROCESS should use
    138                       the input source with which OpenMCL was invoked.</para>
     139                      the input source with which &CCL; was invoked.</para>
    139140                    </listitem>
    140141
     
    215216                  <para>A user-defined function of one argument (the
    216217                  EXTERNAL-PROCESS structure.) This function is called
    217                   whenever OpenMCL detects a change in the staus of the
     218                  whenever &CCL; detects a change in the staus of the
    218219                  EXTERNAL-PROCESS.</para>
    219220                </listitem>
  • trunk/source/doc/src/ffi.xml

    r8599 r8606  
    77<!ENTITY aux "<varname>&amp;aux</varname>">
    88<!ENTITY allow-other-keys "<varname>&amp;allow-other-keys</varname>">
     9<!ENTITY CCL "<literal>CCL</literal>">
    910]>
    1011
     
    1718      <sect2 id="Overview-foreign-types">
    1819        <title>Overview</title>
    19         <para>OpenMCL provides a fairly rich language for defining and
     20        <para>&CCL; provides a fairly rich language for defining and
    2021        specifying foreign data types (this language is derived from
    2122        CMUCL's "alien type" system.)</para>
    2223        <para>In practice, most foreign type definitions are
    23         introduced into OpenMCL via its interface database (see ),
     24        introduced into &CCL; via its interface database (see ),
    2425        though it's also possible to define foreign types
    2526        interactively and/or programmatically.</para>
    26         <para>OpenMCL's foreign type system is "evolving" (a polite
     27        <para>&CCL;'s foreign type system is "evolving" (a polite
    2728        word for not-quite-complete): there are some inconsistencies
    2829        involving package usage, for instance. Symbols used in foreign
     
    3031        this convention isn't always enforced.</para>
    3132        <para>Foreign type, record, and field names are
    32         case-sensitive; OpenMCL uses some escaping conventions (see )
     33        case-sensitive; &CCL; uses some escaping conventions (see )
    3334        to allow keywords to be used to denote these names.</para>
    3435      </sect2>
     
    9394            are allowed by the :array constructor,
    9495            only single-dimensioned arrays are (at all) well-supported
    95             in OpenMCL.</para>
     96            in &CCL;.</para>
    9697          </listitem>
    9798        </itemizedlist>
     
    104105      <sect2 id="Overview-foreign-calls">
    105106        <title>Overview</title>
    106         <para>OpenMCL provides a number of constructs for calling
     107        <para>&CCL; provides a number of constructs for calling
    107108        foreign functions from Lisp code (all of them based on the
    108         function CCL:%FF-CALL).  In many cases, OpenMCL's interface
     109        function CCL:%FF-CALL).  In many cases, &CCL;'s interface
    109110        translator (see ) provides information about the foreign
    110111        function's entrypoint name and argument and return types; this
     
    112113        which may be more concise and/or more readable than other
    113114        constructs.</para>
    114         <para>OpenMCL also provides a mechanism for defining
     115        <para>&CCL; also provides a mechanism for defining
    115116        <emphasis>callbacks</emphasis>: lisp functions which can be
    116117        called from foreign code.</para>
     
    243244          32-bit boundaries, so the two least significant bits of the
    244245          first instruction ("entrypoint") of a foreign function are
    245           always 0. OpenMCL often represents an entrypoint address as
     246          always 0. &CCL; often represents an entrypoint address as
    246247          a fixnum that's binary-equivalent to the entrypoint address:
    247248          if<emphasis> E</emphasis> is an entrypoint address expressed
     
    252253          <para>Although it's possible to use fixnums or macptrs to
    253254          represent entrypoint addresses, it's somewhat cumbersome to
    254           do so. OpenMCL can cache the addresses of named external
     255          do so. &CCL; can cache the addresses of named external
    255256          functions in structure-like objects of type
    256257          CCL:EXTERNAL-ENTRY-POINT (sometimes abbreviated as EEP).
    257258          Through the use of LOAD-TIME-VALUE, compiled lisp functions
    258259          are able to reference EEPs as constants; the use of an
    259           indirection allows OpenMCL runtime system to ensure that the
     260          indirection allows &CCL; runtime system to ensure that the
    260261          EEP's address is current and correct.</para>
    261262        </sect3>
     
    287288          possible to directly reference arbitrary absolute addresses
    288289          (such as those returned by the C library function malloc(),
    289           for instance) in OpenMCL. In OpenMCL (and in MCL), such
     290          for instance) in &CCL;. In &CCL; (and in MCL), such
    290291          addresses need to be <emphasis>encapsulated</emphasis> in
    291292          objects of type CCL:MACPTR; one can think of a MACPTR as
     
    391392          referenced once control leaves the extent of the binding of
    392393          that variable.) Common Lisp allows us to make such an
    393           assertion via a DYNAMIC-EXTENT declaration; OpenMCL's
     394          assertion via a DYNAMIC-EXTENT declaration; &CCL;'s
    394395          compiler can recognize the "primitive MACPTR-creating
    395396          operation" involved and can replace it with an equivalent
     
    411412          stack-allocated MACPTRs, then destructively modifying those
    412413          MACPTRs before executing a body of code is common enough
    413           that OpenMCL provides a macro (WITH-MACPTRS) that handles
     414          that &CCL; provides a macro (WITH-MACPTRS) that handles
    414415          all of the gory details. The following version of
    415416          GET-NEXT-EVENT is semantically equivalent to the previous
     
    446447          block of memory that's being allocated and freed have
    447448          dynamic extent and are therefore good candidates for stack
    448           allocation. OpenMCL provides the %STACK-BLOCK macro, which
     449          allocation. &CCL; provides the %STACK-BLOCK macro, which
    449450          executes a body of code with one or more variables bound to
    450451          stack-allocated MACPTRs which encapsulate the addresses of
     
    467468          foreign memory are all potentially dangerous operations;
    468469          this is no less true when these operations are performed in
    469           OpenMCL than when they're done in C or some other
     470          &CCL; than when they're done in C or some other
    470471          lower-level language. In addition, destructive operations on
    471472          Lisp objects be dangerous, as can stack allocation if it's
     
    473474          Correct use of the constructs and primitives described here
    474475          is reliable and safe; slightly incorrect use of these
    475           constructs and primitives can crash OpenMCL.</para>
     476          constructs and primitives can crash &CCL;.</para>
    476477        </sect3>
    477478      </sect2>
     
    12351236      <sect2 id="interface-database-Overview">
    12361237        <title>Overview</title>
    1237         <para>OpenMCL uses a set of database files which contain
     1238        <para>&CCL; uses a set of database files which contain
    12381239        foreign type, record, constant, and function definitions
    12391240        derived from the operating system's header files, be that
     
    12431244        obtaining current interface database files.</para>
    12441245        <para>Not surprisingly, different platforms use different database files.</para>
    1245         <para>OpenMCL defines reader macros that consult these databases:</para>
     1246        <para>&CCL; defines reader macros that consult these databases:</para>
    12461247        <itemizedlist>
    12471248          <listitem>
     
    12681269        and RLET macros) will cause these database files to be
    12691270        consulted.</para>
    1270         <para>Since the OpenMCL sources contain instances of these
     1271        <para>Since the &CCL; sources contain instances of these
    12711272        reader macros (and references to foreign record types and
    1272         fields), compiling OpenMCL from those sources depends on the
     1273        fields), compiling &CCL; from those sources depends on the
    12731274        ability to find and use (see <xref
    12741275        linkend="Building-the-heap-image"/>).</para>
     
    12791280        <itemizedlist>
    12801281          <listitem>
    1281             <para>OpenMCL now preserves the case of external symbols
     1282            <para>&CCL; now preserves the case of external symbols
    12821283            in itsdatabase files. See for information about case in
    12831284            foreign symbol names.</para>
     
    13731374        <para>Hopefully, this scheme will also make it easier to
    13741375        distribute patches and bug fixes.</para>
    1375         <para>OpenMCL maintains a list of directories; when looking
     1376        <para>&CCL; maintains a list of directories; when looking
    13761377        for a foreign type, constant, function, or record definition,
    13771378        it'll consult the database files in each directory on that
    13781379        list. Initially, the list contains an entry for the "libc"
    1379         interface directory. OpenMCL needs to be explicitly told to
     1380        interface directory. &CCL; needs to be explicitly told to
    13801381        look in other interface directories should it need to do
    13811382        so.</para>
     
    14421443        <title>Overview</title>
    14431444
    1444         <para>OpenMCL provides facilities to open and close shared
     1445        <para>&CCL; provides facilities to open and close shared
    14451446        libraries.</para>
    14461447        <para>"Opening" a shared library, which is done with <xref
    14471448        linkend="f_open-shared-library"/>, maps the library's code and
    1448         data into OpenMCL's address space and makes its exported
    1449         symbols accessible to OpenMCL.</para>
     1449        data into &CCL;'s address space and makes its exported
     1450        symbols accessible to &CCL;.</para>
    14501451        <para>"Closing" a shared library, which is done with <xref
    14511452        linkend="f_close-shared-library"/>, unmaps the library's code
     
    14561457        Darwin) are opened by the lisp kernel and can't be
    14571458        closed.</para>
    1458         <para>OpenMCL uses data structures of type
     1459        <para>&CCL; uses data structures of type
    14591460        EXTERNAL-ENTRY-POINT to map a foreign function name (string)
    14601461        to that foreign function's <emphasis>current</emphasis>
     
    14731474        entrypoint that was defined in a closed library will cause an
    14741475        attempt to reopen that library.</para>
    1475         <para>OpenMCL keeps track of all libraries that have been
     1476        <para>&CCL; keeps track of all libraries that have been
    14761477        opened in a lisp session. When a saved application is first
    14771478        started, an attempt is made to reopen all libraries that were
     
    15421543        </itemizedlist>
    15431544        <para>Thanks to Michael Klingbeil for getting both kinds of
    1544         Darwin shared libraries working in OpenMCL.</para>
     1545        Darwin shared libraries working in &CCL;.</para>
    15451546      </sect2>
    15461547    </sect1>
     
    15511552      <sect2 id="Inteface-translator-overview">
    15521553        <title>Overview</title>
    1553         <para>OpenMCL uses an interface translation system based on the FFIGEN
     1554        <para>&CCL; uses an interface translation system based on the FFIGEN
    15541555        system, which is described at
    15551556        http://www.ccs.neu.edu/home/lth/ffigen/.
     
    15671568        <para>The original FFIGEN system used a modified version of
    15681569        the LCC C compiler to produce .ffi files. Since many LinuxPPC
    1569         header files contain GCC-specific constructs, OpenMCL's
     1570        header files contain GCC-specific constructs, &CCL;'s
    15701571        translation system uses a modified version of GCC (called,
    15711572        somewhat confusingly, ffigen.)</para>
     
    15951596        arguments.</para>
    15961597        <para>For each interface directory (see FIXTHIS)
    1597         <emphasis>subdir</emphasis> distributed with OpenMCL, a shell
    1598         script (distributed with OpenMCL as
     1598        <emphasis>subdir</emphasis> distributed with &CCL;, a shell
     1599        script (distributed with &CCL; as
    15991600        "ccl:headers;<emphasis>subdir</emphasis>;C;populate.sh"
    16001601        ("ccl:darwin-headers;<emphasis>subdir</emphasis>;C;populate.sh"
     
    16381639          </listitem>
    16391640          <listitem>
    1640             <para>Run OpenMCL:
     1641            <para>Run &CCL;:
    16411642            <programlisting>
    16421643? (require "PARSE-FFI")
     
    16531654    </sect1>
    16541655
    1655     <sect1 id="Case-sensitivity-of-foreign-names-in-OpenMCL">
    1656       <title>Case-sensitivity of foreign names in OpenMCL</title>
     1656    <sect1 id="Case-sensitivity-of-foreign-names-in-&CCL;">
     1657      <title>Case-sensitivity of foreign names in &CCL;</title>
    16571658
    16581659      <sect2 id="Case-sensitivity-overview">
    16591660        <title>Overview</title>
    1660         <para>As of release 0.11, OpenMCL addresses the fact that
     1661        <para>As of release 0.11, &CCL; addresses the fact that
    16611662        foreign type, constant, record, field, and function nams are
    16621663        case-sensitive and provides mechanisms to refer to these names
    16631664        via lisp symbols.</para>
    1664         <para>Previous versions of OpenMCL have tried to ignore that
     1665        <para>Previous versions of &CCL; have tried to ignore that
    16651666        fact, under the belief that case conflicts were rare and that
    16661667        many users (and implementors) would prefer not to deal with
     
    16831684        <title>Foreign constant and function names</title>
    16841685        <para>The primary way of referring to foreign constant and
    1685         function names in OpenMCL is via the #$ and #_ reader
     1686        function names in &CCL; is via the #$ and #_ reader
    16861687        macros. These reader macro functions each read a symbol into
    16871688        the "OS" package, look up its constant or function definition
     
    17201721        given that many traditional POSIX structure, type, and field
    17211722        names are entirely lowercase.)</para>
    1722         <para>The approach taken by OpenMCL is to allow the symbols
     1723        <para>The approach taken by &CCL; is to allow the symbols
    17231724        (keywords) used to denote foreign type, record, and field
    17241725        names to contain angle brackets (<literal>&lt;</literal> and
     
    17451746        brackets) sequences of upper-case and non-lower-case
    17461747        characters in a symbol used to denote a foreign name. When
    1747         translating in the other direction, OpenMCL always escapes the
     1748        translating in the other direction, &CCL; always escapes the
    17481749        longest sequence that starts with an upper-case character and
    17491750        doesn't contain a lower-case character.</para>
     
    17581759        <para>Older POSIX code tends to use lower-case exclusively for
    17591760        type, record, and field names; there are only a few cases in
    1760         the OpenMCL sources where mixed-case names need to be
     1761        the &CCL; sources where mixed-case names need to be
    17611762        escaped.</para>
    17621763       
     
    17791780    <sect1 id="Tutorial--Using-Basic-Calls-and-Types">
    17801781      <title>Tutorial: Using Basic Calls and Types</title>
    1781       <para>This tutorial is meant to cover the basics of OpenMCL for
     1782      <para>This tutorial is meant to cover the basics of &CCL; for
    17821783      calling external C functions and passing data back and forth.
    17831784      These basics will provide the foundation for more advanced
     
    17861787      <para>The first step is to start with a simple C dynamic library
    17871788      in order to actually observe what is actually passing between
    1788       OpenMCL and C.  So, some C code is in order:</para>
     1789      &CCL; and C.  So, some C code is in order:</para>
    17891790      <para>Create the file typetest.c, and put the following code
    17901791      into it:</para>
     
    18511852      chose a name which follows the normal OS X convention, being in
    18521853      the form "libXXXXX.dylib", so that other programs can link to
    1853       the library.  OpenMCL doesn't need it to be this way, but it is
     1854      the library.  &CCL; doesn't need it to be this way, but it is
    18541855      a good idea to adhere to existing conventions.</para>
    18551856      <para>The -install_name flag is primarily used when building OS
     
    18591860      relative path from some "current" directory.</para>
    18601861      <para>After creating this library, the first step is to tell
    1861       OpenMCL to open the dynamic library.  This is done by calling
     1862      &CCL; to open the dynamic library.  This is done by calling
    18621863      .</para>
    18631864      <programlisting>
    18641865
    1865 Welcome to OpenMCL Version (Beta: Darwin) 0.14.2-040506!
     1866Welcome to &CCL; Version (Beta: Darwin) 0.14.2-040506!
    18661867
    18671868? (open-shared-library "/Users/andewl/openmcl/libtypetest.dylib")
     
    18751876      being anything in particular.</para>
    18761877      <para>This command returns a reference to the opened shared library, and
    1877 OpenMCL also adds one to the global variable
     1878&CCL; also adds one to the global variable
    18781879<literal>ccl::*shared-libraries*</literal>:</para>
    18791880      <programlisting>
     
    19171918#&lt;EXTERNAL-ENTRY-POINT "functiondoesnotexist" {unresolved}  #x638E3F6>
    19181919</programlisting>
    1919       <para>The "unresolved" tells us that OpenMCL wasn't able to find this
     1920      <para>The "unresolved" tells us that &CCL; wasn't able to find this
    19201921      function, which means you would get an error, "Can't resolve foreign
    19211922      symbol," if you tried to call it.</para>
     
    20592060    -install_name ./libtypetest.dylib
    20602061</programlisting>
    2061       <para>Now, restart OpenMCL.  This step is required because
    2062       OpenMCL cannot close and reload a dynamic library on OS
     2062      <para>Now, restart &CCL;.  This step is required because
     2063      &CCL; cannot close and reload a dynamic library on OS
    20632064      X.</para>
    20642065      <para>Have you restarted?  Okay, try out the new code:</para>
    20652066      <programlisting>
    20662067
    2067 Welcome to OpenMCL Version (Beta: Darwin) 0.14.2-040506!
     2068Welcome to &CCL; Version (Beta: Darwin) 0.14.2-040506!
    20682069
    20692070? (open-shared-library "/Users/andewl/openmcl/libtypetest.dylib")
     
    21072108      <para>Ouch.  The C function changes the value with no warning
    21082109      that something is wrong.  Even worse, it manages to pass the
    2109       original value back to OpenMCL, which hides the fact that
     2110      original value back to &CCL;, which hides the fact that
    21102111      something is wrong.</para>
    21112112      <para>Finally, let's take a look at doing this with
     
    21132114      <programlisting>
    21142115
    2115 Welcome to OpenMCL Version (Beta: Darwin) 0.14.2-040506!
     2116Welcome to &CCL; Version (Beta: Darwin) 0.14.2-040506!
    21162117
    21172118? (open-shared-library "/Users/andewl/openmcl/libtypetest.dylib")
     
    21382139:double-float wrong, though, because then there's no protection.</para>
    21392140      <para>Congratulations!  You now know how to call external C functions from
    2140 within OpenMCL, and pass numbers back and forth.  Now that the basic
     2141within &CCL;, and pass numbers back and forth.  Now that the basic
    21412142mechanics of calling and passing work, the next step is to examine how
    21422143to pass more complex data structures around.</para>
     
    22162217      <para>As in the last tutorial, our first step
    22172218      is to create a local dynamic library in order to help show
    2218       what is actually going on between OpenMCL and C.  So, create the file
     2219      what is actually going on between &CCL; and C.  So, create the file
    22192220      ptrtest.c, with the following code:</para>
    22202221      <programlisting>
     
    22772278      <para>If that command doesn't make sense to you, feel free to go back
    22782279and read about it at .</para>
    2279       <para>Now, start OpenMCL and enter:</para>
     2280      <para>Now, start &CCL; and enter:</para>
    22802281      <programlisting>
    22812282? ;; make-heap-ivector courtesy of Gary Byers
     
    23032304      <para>The function <literal>make-heap-ivector</literal> is the
    23042305      primary tool for allocating objects in heap memory.  It
    2305       allocates a fixed-size OpenMCL object in heap memory.  It
     2306      allocates a fixed-size &CCL; object in heap memory.  It
    23062307      returns both an array reference, which can be used directly from
    2307       OpenMCL, and a <literal>macptr</literal>, which can be used to
     2308      &CCL;, and a <literal>macptr</literal>, which can be used to
    23082309      access the underlying memory directly.  For example:</para>
    23092310      <programlisting>
     
    24052406      the contents of the array in-place; that is, it doesn't make a
    24062407      new array, just keeps the same one and reverses what's in it.
    2407       Finally, the C function passes control back to OpenMCL.  Since
    2408       the allocated array memory has been directly modifed, OpenMCL
     2408      Finally, the C function passes control back to &CCL;.  Since
     2409      the allocated array memory has been directly modifed, &CCL;
    24092410      reflects those changes directly in the array as well.</para>
    24102411      <para>There is one final bit of housekeeping to deal with.
     
    24652466      least ensure that the foreign pointer is deallocated when the
    24662467      encapsulating object is about to become garbage, by using
    2467       OpenMCL's nonstandard "termination" mechanism, which is
     2468      &CCL;'s nonstandard "termination" mechanism, which is
    24682469      essentially the same as what Java and other languages call
    24692470      "finialization".</para>
     
    25592560              <listitem>
    25602561                <para>NIL or a keyword; the keyword may contain
    2561                 <link linkend="Case-sensitivity-of-foreign-names-in-OpenMCL" >escaping constructs</link>.</para>
     2562                <link linkend="Case-sensitivity-of-foreign-names-in-&CCL;" >escaping constructs</link>.</para>
    25622563              </listitem>
    25632564            </varlistentry>
     
    29132914          <refname>OPEN-SHARED-LIBRARY</refname>
    29142915          <refpurpose>Asks the operating system to load a shared library
    2915           for OpenMCL to use.</refpurpose>
     2916          for &CCL; to use.</refpurpose>
    29162917          <refclass>Function</refclass>
    29172918        </refnamediv>
     
    35703571         
    35713572          <para>Does a lookup on that symbol in <link
    3572           linkend="The-Interface-Database">the OpenMCL interface
     3573          linkend="The-Interface-Database">the &CCL; interface
    35733574          database</link>, signalling an error if no foreign function
    35743575          information can be found for the symbol in any active <link
     
    36193620          <title>Description</title>
    36203621
    3621           <para>In OpenMCL 0.14.2 and later, the #? reader macro can be used to
     3622          <para>In &CCL; 0.14.2 and later, the #? reader macro can be used to
    36223623          access foreign variables; this functionality depends on the presence of
    36233624          &#34;vars.cdb&#34; files in the interface database. The current behavior
     
    36273628          bound to the &#34;OS&#34; package and with readtable-case preserved.</para>
    36283629         
    3629           <para>Use that symbol&#39;s pname to access the OpenMCL interface
     3630          <para>Use that symbol&#39;s pname to access the &CCL; interface
    36303631          database, signalling an error if no appropriate foreign variable
    36313632          information can be found with that name in any active interface
     
    37033704          <title>Description</title>
    37043705
    3705           <para>Tells OpenMCL to add the interface directory denoted by
     3706          <para>Tells &CCL; to add the interface directory denoted by
    37063707          dir-id to the list of interface directories which it consults for
    37073708          foreign type and function information. Arranges that that
     
    37143715          or doesn&#39;t
    37153716          contain a set of database files, a runtime error may occur
    3716           when OpenMCL
     3717          when &CCL;
    37173718          tries to open some database file in that directory, and it
    37183719          will try to
     
    37853786          <title>Description</title>
    37863787
    3787           <para>Tells OpenMCL to remove the interface directory denoted by
     3788          <para>Tells &CCL; to remove the interface directory denoted by
    37883789          dir-id from the list of interface directories which are
    37893790          consulted for
  • trunk/source/doc/src/gc.xml

    r8599 r8606  
    11<?xml version="1.0" encoding="utf-8"?>
    2 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
     2<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"[
     3<!ENTITY rest "<varname>&amp;rest</varname>">
     4<!ENTITY key "<varname>&amp;key</varname>">
     5<!ENTITY optional "<varname>&amp;optional</varname>">
     6<!ENTITY body "<varname>&amp;body</varname>">
     7<!ENTITY aux "<varname>&amp;aux</varname>">
     8<!ENTITY allow-other-keys "<varname>&amp;allow-other-keys</varname>">
     9<!ENTITY CCL "<literal>CCL</literal>">
     10]>
    311  <chapter id="Understanding-and-Configuring-the-Garbage-Collector">
    412    <title>Understanding and Configuring the Garbage Collector</title>
     
    614    <sect1 id="Heap-space-allocation">
    715      <title>Heap space allocation</title>
    8       <para>Release 0.10 or later of OpenMCL uses a different memory
     16      <para>Release 0.10 or later of &CCL; uses a different memory
    917      management scheme than previous versions did. Those earlier
    1018      versions would allocate a block of memory (of specified size) at
     
    4452</programlisting>
    4553      <para>would provide an execution environment that's very similar to
    46 that provided by earlier OpenMCL versions.</para>
     54that provided by earlier &CCL; versions.</para>
    4755    </sect1>
    4856
     
    118126      on performance is highly application-dependant.</para>
    119127      <para>Most EGC strategies (including the one employed by
    120       OpenMCL) logically or physically divide memory into one or more
     128      &CCL;) logically or physically divide memory into one or more
    121129      areas of relatively young objects ("generations") and one or
    122130      more areas of old objects.  Objects that have survived one or
     
    131139      <para>It's important to note that a GC of the youngest
    132140      generation is typically very fast (perhaps a few milliseconds on
    133       a modern CPU, depending on various factors), OpenMCL's EGC is
     141      a modern CPU, depending on various factors), &CCL;'s EGC is
    134142      not concurrent and doesn't offer realtime guarantees.</para>
    135       <para>OpenMCL's EGC maintains three ephemeral generations; all
     143      <para>&CCL;'s EGC maintains three ephemeral generations; all
    136144      newly created objects are created as members of the youngest
    137145      generation. Each generation has an associated
     
    166174      to be nearly or entirely identical to the address range used by
    167175      the N+1th full GC.</para>
    168       <para>By default (and traditionally in OpenMCL), the GC's policy
     176      <para>By default (and traditionally in &CCL;), the GC's policy
    169177      is to "release" the pages in this address range: to advise the
    170178      virtual memory system that the pages contain garbage and any
     
    173181      range so that the pages will be zero-filled by the virtual
    174182      memory system when they're next accessed.  This policy is
    175       intended to reduce the load on the VM system and keep OpenMCL's
     183      intended to reduce the load on the VM system and keep &CCL;'s
    176184      working set to a minimum.</para>
    177185      <para>For some programs (especially those that cons at a very
     
    210218      which disallows writing to the memory-mapped regions of the file
    211219      from other processes. I'm not sure of how to do that; writing to
    212       the file when it's mapped by OpenMCL can have unpredictable and
     220      the file when it's mapped by &CCL; can have unpredictable and
    213221      unpleasant results.  SAVE-APPLICATION will delete its output
    214222      file's directory entry and create a new file; one may need to
     
    229237      referenced nowhere else in the program.  You may want this
    230238      behaviour.  If you don't, you need weak references.</para>
    231       <para>OpenMCL supports weak references with "weak hash tables".
     239      <para>&CCL; supports weak references with "weak hash tables".
    232240      Hash tables may be weak with respect to either their keys or
    233241      their values.  To make a hash table with weak keys, invoke
     
    516524          threshold sizes in effect and returns T, otherwise, returns NIL.
    517525          (The provided threshold sizes are rounded up to a multiple of
    518           64Kbytes in OpenMCL 0.14 and to a multiple of 32KBytes in earlier
     526          64Kbytes in &CCL; 0.14 and to a multiple of 32KBytes in earlier
    519527          versions.)</para>
    520528        </refsect1>
  • trunk/source/doc/src/implementation.xml

    r8599 r8606  
    11<?xml version="1.0" encoding="utf-8"?>
    2 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
    3   <chapter id="Implementation-Details-of-OpenMCL">
    4     <title>Implementation Details of OpenMCL</title>
    5     <para>This chapter describes many aspects of OpenMCL's
     2<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"[
     3<!ENTITY rest "<varname>&amp;rest</varname>">
     4<!ENTITY key "<varname>&amp;key</varname>">
     5<!ENTITY optional "<varname>&amp;optional</varname>">
     6<!ENTITY body "<varname>&amp;body</varname>">
     7<!ENTITY aux "<varname>&amp;aux</varname>">
     8<!ENTITY allow-other-keys "<varname>&amp;allow-other-keys</varname>">
     9<!ENTITY CCL "<literal>CCL</literal>">
     10]>
     11  <chapter id="Implementation-Details-of-&CCL;">
     12    <title>Implementation Details of &CCL;</title>
     13    <para>This chapter describes many aspects of &CCL;'s
    614    implementation as of (roughly) version 1.1.  Details vary a bit
    715    between the three archutectures (PPC32, PPC64, and X86-64)
     
    1624    <sect1 id="Threads-and-exceptions">
    1725      <title>Threads and exceptions</title>
    18       <para>OpenMCL's threads are "native" (meaning that they're
     26      <para>&CCL;'s threads are "native" (meaning that they're
    1927      scheduled and controlled by the operating system.)  Most of the
    2028      implications of this are discussed elsewhere; this section tries
    2129      to describe how threads look from the lisp kernel's perspective
    2230      (and especailly from the GC's point of view.)</para>
    23       <para>OpenMCL's runtime system tries to use machine-level
     31      <para>&CCL;'s runtime system tries to use machine-level
    2432      exception mechanisms (conditional traps when available, illegal
    2533      instructions, memory access protection in some cases) to detect
     
    3644      <para>Some emulated execution environments (the Rosetta PPC
    3745      emulator on x86 versions of OSX) don't provide accurate
    38       exception information to exception handling functions. OpenMCL
     46      exception information to exception handling functions. &CCL;
    3947      can't run in such environments.</para>
    4048
     
    126134        crashed (when in fact the application in question has
    127135        routinely handled a routine exception.)  On Darwin/OSX,
    128         OpenMCL uses Mach thread-level exception handling facilities
     136        &CCL; uses Mach thread-level exception handling facilities
    129137        which run before GDB or CrashReporter get a chance to confuse
    130         themeselves; OpenMCL's Mach exception handling tries to force
     138        themeselves; &CCL;'s Mach exception handling tries to force
    131139        the thread which received a synchronous exception to invoke a
    132140        signal handling function ("as if" signal handling worked more
     
    139147        from a thread-level exception handler keeps the exception from
    140148        being reported to GDB or CrashReporter and avoids the problems
    141         related to those programs.  Since OpenMCL's Mach exception
     149        related to those programs.  Since &CCL;'s Mach exception
    142150        handler doesn't claim to handle debugging-related exceptions
    143151        (from breakpoints or single-step operations), it's possible to
    144         use GDB to debug OpenMCL.</para>
     152        use GDB to debug &CCL;.</para>
    145153        <para>On platforms where signal handling and debugging don't get in each
    146154other's way, a signal handler is entered with all signals blocked.
     
    173181        context and siginfo structures on the stack of the thread
    174182        which received the signal; in practice, that means "wherever
    175         RSP is pointing."  OpenMCL's require that the thread's value
     183        RSP is pointing."  &CCL;'s require that the thread's value
    176184        stack - where RSP is usually pointing while lisp code is
    177185        running - contain only "nodes" (properly tagged lisp objects),
     
    214222      <sect2 id="Threads-comma---exceptions-comma---and-the-GC">
    215223        <title>Threads, exceptions, and the GC</title>
    216         <para>OpenMCL's GC is not concurrent: when the GC is invoked
     224        <para>&CCL;'s GC is not concurrent: when the GC is invoked
    217225        in response to an exception in a particular thread, all other
    218226        lisp threads must stop until the GC's work is done.  The
     
    244252      <sect2 id="PC-lusering">
    245253        <title>PC-lusering</title>
    246         <para>It's not quite accurate to say that OpenMCL's compiler
     254        <para>It's not quite accurate to say that &CCL;'s compiler
    247255        and runtime follow precise stack and register usage
    248256        conventions at all times; there are a few exceptions:</para>
     
    332340        tolerate ambiguity.</para>
    333341        <para>"Tolerating ambiguity" is an approach taken by some
    334         ("conservative") GC schemes; by contrast, OpenMCL's GC is
     342        ("conservative") GC schemes; by contrast, &CCL;'s GC is
    335343        "precise", which in this case means that it believes that the
    336344        contents of certain machine registers and stack locations are
     
    366374        <para>Such a pointer ("into" the interior of a heap-allocated
    367375        object) is often called a <emphasis>locative</emphasis>; the
    368         cases where locatives are allowed in OpenMCL mostly involve
     376        cases where locatives are allowed in &CCL; mostly involve
    369377        the behavior of function call and return instructions.  (To be
    370378        technicaly accurate, the other case also arises on x86-64, but
     
    372380        <para>On the PowerPC (both PPC32 and PPC64), all machine
    373381        instructions are 32 bits wide and all in1struction words are
    374         allocated on 32-bit boundaries.  In PPC OpenMCL, a CODE-VECTOR
     382        allocated on 32-bit boundaries.  In PPC &CCL;, a CODE-VECTOR
    375383        is a specialized type of vector-like object; its elements are
    376384        32-bit PPC machine instructions.  A CODE-VECTOR is an
     
    393401        lr or ctr needs to be stored in memory it needs to first be
    394402        copied to a general-purpose registers.</para>
    395         <para>OpenMCL's GC understands that certain registers contain
     403        <para>&CCL;'s GC understands that certain registers contain
    396404        these special "pc-locatives" (locatives that point into
    397405        CODE-VECTOR objects); it contains specal support for finding
     
    655663      <sect2 id="Tagging-scheme">
    656664        <title>Tagging scheme</title>
    657         <para>OpenMCL always allocates lisp objects on double-node
     665        <para>&CCL; always allocates lisp objects on double-node
    658666        (64-bit for 32-bit platforms, 128-bit for 64-bit platforms)
    659667        boundaries; this mean that the low 3 bits (32-bit lisp) or 4
     
    700708        to ensure that it will be.</para>
    701709        <para>If we have N available tag bits (N = 3 for 32-bit
    702         OpenMCL and N = 4 for 64-bit OpenMCL), this way of
     710        &CCL; and N = 4 for 64-bit &CCL;), this way of
    703711        representing fixnums with the low M bits forced to 0 works as
    704712        long as M &lt;= N.  The smaller we make M, the larger the
     
    729737            smaller, cheaper addressing modes to be used to "cdr down a
    730738            list."  That's not a factor on ppc or x86-64,but all
    731             versions of OpenMCL still store the CDR of a CONS cell
     739            versions of &CCL; still store the CDR of a CONS cell
    732740            first in memory.  It doesn't matter, but doing it the way
    733741            that the host system did made boostrapping to a new target
     
    743751            and primitives like CAR and CDR do LISTP implicitly when
    744752            safe and want that operation to be fast.There are several
    745             possible approaches to this; OpenMCL uses two of them. On
     753            possible approaches to this; &CCL; uses two of them. On
    746754            PPC32 and X86-64, NIL is basically a weird CONS cell that
    747755            straddles two doublenodes; the tag of NIL is unique and
     
    785793            treatment as well, and the treatment of "memory-allocated
    786794            non-CONS objects" isn't entirely uniformaccross all
    787             OpenMCL implementations.  Let's first pretend that
     795            &CCL; implementations.  Let's first pretend that
    788796            the treatment is uniform, then discuss the ways in which it
    789797            isn't.The "uniform approach" is to treat all
    790798            memory-allocated non-CONS objectsas if they were vectors;
    791799            this use of the term is a little looser thanwhat's implied
    792             by the CL VECTOR type.  OpenMCL actually uses the
     800            by the CL VECTOR type.  &CCL; actually uses the
    793801            term"uvector" to mean "a memory-allocated lisp object
    794802            other than a CONS cell,whose first word is a header which
     
    837845
    838846    <sect1 id="Heap-Allocation">
    839       <title>Heap Allocation</title> <para>When the OpenMCL kernel
     847      <title>Heap Allocation</title> <para>When the &CCL; kernel
    840848      first starts up, a large contiguous chunk of the process's
    841849      address space is mapped as "anonymous, no access"
     
    967975      <sect2 id="Heap-growth">
    968976        <title>Heap growth</title>
    969         <para>All OSes on which OpenMCL currently runs use an
     977        <para>All OSes on which &CCL; currently runs use an
    970978        "overcommit" memory allocation strategy by default (though
    971979        some of them provide ways of overriding that default.)  What
     
    10661074        to that object. Rather than storing that pointer chain
    10671075        implicitly on the stack (in a series of recursive calls to the
    1068         mark subroutine), the OpenMCL marker uses mixture of recursion
     1076        mark subroutine), the &CCL; marker uses mixture of recursion
    10691077        and a technique called <emphasis>link inversion</emphasis> to
    10701078        store the pointer chain in the objects themselves.  (Recursion
     
    11971205    <sect1 id="The-ephemeral-GC">
    11981206      <title>The ephemeral GC</title>
    1199       <para>In the OpenMCL memory management scheme, the relative age
     1207      <para>In the &CCL; memory management scheme, the relative age
    12001208      of two objects in the dynamic heap can be determined by their
    12011209      addresses: if addresses X and Y are both addresses in the
     
    12481256      set of pointers that may contain intergenerational references is
    12491257      sometimes called <emphasis>the remembered set</emphasis>.</para>
    1250       <para>In OpenMCL's EGC, the heap is organized exactly the same
     1258      <para>In &CCL;'s EGC, the heap is organized exactly the same
    12511259      as otherwise; "generations" are merely structures which contain
    12521260      pointers to regions of the heap (which is already ordered by
     
    13331341      The information here is only an overview, which might help when
    13341342      reading the source.</para>
    1335       <para>The OpenMCL Fasl format is forked from the old MCL Fasl
     1343      <para>The &CCL; Fasl format is forked from the old MCL Fasl
    13361344      format; there are a few differences, but they are minor.  The
    13371345      name "nfasload" comes from the fact that this is the so-called
     
    13791387      <title>The Objective-C Bridge</title>
    13801388
    1381       <sect2 id="How-OpenMCL-Recognizes-Objective-C-Objects">
    1382         <title>How OpenMCL Recognizes Objective-C Objects</title>
     1389      <sect2 id="How-&CCL;-Recognizes-Objective-C-Objects">
     1390        <title>How &CCL; Recognizes Objective-C Objects</title>
    13831391        <para>In most cases, pointers to instances of Objective-C
    13841392        classes are recognized as such; the recognition is (and
  • trunk/source/doc/src/install.xml

    r8599 r8606  
    11<?xml version="1.0" encoding="utf-8"?>
    22<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
    3 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
    4 
    5  <chapter><title>Obtaining, Installing, and Running OpenMCL</title>
     3"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"[
     4<!ENTITY rest "<varname>&amp;rest</varname>">
     5<!ENTITY key "<varname>&amp;key</varname>">
     6<!ENTITY optional "<varname>&amp;optional</varname>">
     7<!ENTITY body "<varname>&amp;body</varname>">
     8<!ENTITY aux "<varname>&amp;aux</varname>">
     9<!ENTITY allow-other-keys "<varname>&amp;allow-other-keys</varname>">
     10<!ENTITY CCL "<literal>CCL</literal>">
     11]>
     12
     13 <chapter><title>Obtaining, Installing, and Running &CCL;</title>
    614 
    715  <sect1><title>Releases and System Requirements</title>
    816   
    9    <para>There are three active versions of OpenMCL.  Version 1.0 was
     17   <para>There are three active versions of &CCL;.  Version 1.0 was
    1018   a stable release (released in late 2005); it is no longer under
    1119   active development.  Version 1.1 has been under active development
     
    5058      </itemizedlist>
    5159
    52       <para>A 64-bit version of OpenMCL requires a 64-bit processor
     60      <para>A 64-bit version of &CCL; requires a 64-bit processor
    5361      (obviously) running a 64-bit OS variant.</para>
    5462     
    55       <para>There are ongoing efforts to port OpenMCL to the Windows
     63      <para>There are ongoing efforts to port &CCL; to the Windows
    5664      operating system and 32-bit x86 processors.</para>
    5765     
     
    6270      <sect2><title>LinuxPPC</title>
    6371       
    64         <para>OpenMCL versions 1.0 and later run under relatively
    65         recent versions of LinuxPPC. All versions of OpenMCL require
     72        <para>&CCL; versions 1.0 and later run under relatively
     73        recent versions of LinuxPPC. All versions of &CCL; require
    6674        version 2.2.13 (or later) of the Linux kernel and version
    6775        2.1.3 (or later) of the GNU C library (glibc) at a bare
     
    7179      <sect2><title>LinuxX8664</title>
    7280
    73         <para>Version 1.1 and later of OpenMCL runs on relatively
     81        <para>Version 1.1 and later of &CCL; runs on relatively
    7482        recent Linux distributions for the x86-64 architecture.  It
    7583        requires a Linux with Thread Local Storage support in the
     
    8694        versions of what Linux distributions have what problems.  A
    8795        rule of thumb is that - since much of the development of
    88         OpenMCL for x86-64 took place in that time frame - Linux
     96        &CCL; for x86-64 took place in that time frame - Linux
    8997        distributions released earlier than early 2006 may have
    90         problems running OpenMCL.) </para>
     98        problems running &CCL;.) </para>
    9199      </sect2>
    92100
    93101      <sect2><title>FreeBSD-amd64</title>
    94         <para>Versions 1.1 and later of OpenMCL runs on FreeBSD on
     102        <para>Versions 1.1 and later of &CCL; runs on FreeBSD on
    95103        x86-64 (FreeBSD releases generally call the platform "and64")
    96         OpenMCL should run under FreeBSD 6.0 or later; as of this
     104        &CCL; should run under FreeBSD 6.0 or later; as of this
    97105        writing, FreeBSD 7.0 is about to be released and it may be
    98106        necessary for FreeBSD 7 users to install the "compat6x"
    99         package in order to use a version of OpenMCL built on FreeBSD
     107        package in order to use a version of &CCL; built on FreeBSD
    100108        6.x under FreeBSD 7.  .</para>
    101109      </sect2>
     
    103111      <sect2><title>DarwinPPC-MacOS-X</title>
    104112
    105         <para> OpenMCL 1.0 runs on MacOS X versions 10.2, 10.3 and
     113        <para> &CCL; 1.0 runs on MacOS X versions 10.2, 10.3 and
    106114        10.4 on the PowerPC.</para>
    107115
     
    110118        version 10.3.9</para>
    111119
    112         <para>The 64-bit DarwinPPC version of OpenMCL requires
     120        <para>The 64-bit DarwinPPC version of &CCL; requires
    113121        functionality introduced in OSX 10.4 (namely, the ability to
    114122        run 64-bit binaries).  It also, obviously, requires a G5
    115123        processor.</para>
    116124
    117         <para>OpenMCL hasn't been tested under Darwin proper, but
    118         OpenMCL doesn't intentionally use any MacOS X features beyond
    119         the Darwin subset and therefore it seems likely that OpenMCL
     125        <para>&CCL; hasn't been tested under Darwin proper, but
     126        &CCL; doesn't intentionally use any MacOS X features beyond
     127        the Darwin subset and therefore it seems likely that &CCL;
    120128        would run on PPC Darwin versions that correspond to recent OSX
    121129        versions.</para>
     
    123131
    124132      <sect2><title>Darwinx8664-MacOS-X</title>
    125         <para>Versions 1.1 and later of OpenMCL runs on 64-bit
     133        <para>Versions 1.1 and later of &CCL; runs on 64-bit
    126134        DarwinX86 (MacOS on Intel).</para>
    127135
    128         <para>OpenMCL Darwinx8664/MacOS X requires a 64-bit processor.
     136        <para>&CCL; Darwinx8664/MacOS X requires a 64-bit processor.
    129137        All Macintoshes currently sold by Apple (as of early 2008) and
    130138        all Macintoshes introduced by Apple since August 2006 have
    131139        such processors.  However, the original MacBooks, MacBook Pros
    132140        and Intel iMacs (models introduced in early 2006) used 32-bit
    133         Core Duo processors, and so OpenMCL will not (yet) run on
     141        Core Duo processors, and so &CCL; will not (yet) run on
    134142        them.</para>
    135143
     
    138146
    139147    <sect1><title>Installation</title>
    140       <para>Installing OpenMCL consists of</para>
     148      <para>Installing &CCL; consists of</para>
    141149      <orderedlist>
    142150        <listitem>
    143           <para>Downloading an appropriate distribution of OpenMCL;</para>
     151          <para>Downloading an appropriate distribution of &CCL;;</para>
    144152        </listitem>
    145153        <listitem>
     
    148156        </listitem>
    149157        <listitem>
    150           <para>Configuring a shell script so OpenMCL can locate
     158          <para>Configuring a shell script so &CCL; can locate
    151159          necessary library files and other auxilliary files.</para>
    152160        </listitem>
    153161      </orderedlist>
    154162
    155       <sect2><title>Downloading and untarring OpenMCL binary source
    156       releases</title> <para> OpenMCL releases and snapshots are
     163      <sect2><title>Downloading and untarring &CCL; binary source
     164      releases</title> <para> &CCL; releases and snapshots are
    157165      distributed as tarballs (compressed tar archives).</para>
    158166
    159167      <para>Tarballs of version 1.0 for supported platforms are
    160       available from the download page of the OpenMCL website.</para>
     168      available from the download page of the &CCL; website.</para>
    161169
    162170      <para>Tarballs of the latest development snapshots of version
     
    189197      <para>Once the <literal>ccl</literal> directory is installed,
    190198      it's necessary to install and configure a shell script
    191       distributed with OpenMCL before using it.</para>
     199      distributed with &CCL; before using it.</para>
    192200      </sect2>
    193201
    194202      <sect2><title>The-openmcl-Shell-Script"</title>
    195       <para>OpenMCL needs to be able to find the
     203      <para>&CCL; needs to be able to find the
    196204      <literal>ccl</literal> directory in order to support features
    197205      such as <literal>require</literal> and
     
    202210      this logical host isn't defined (or isn't defined correctly),
    203211      some things might work, some things might not... and it'll
    204       generally be hard to invoke and use OpenMCL productively.</para>
    205 
    206         <para>OpenMCL uses the value of the environment variable
     212      generally be hard to invoke and use &CCL; productively.</para>
     213
     214        <para>&CCL; uses the value of the environment variable
    207215        <literal>CCL_DEFAULT_DIRECTORY</literal> to determine the
    208216        filesystem location of the <literal>ccl</literal> directory;
    209217        the openmcl shell script is intended to provide a way to
    210         invoke OpenMCL with that environment variable set
     218        invoke &CCL; with that environment variable set
    211219        correctly.</para>
    212220        <para>There are two versions of the shell script:
    213221        <literal>"ccl/scripts/openmcl"</literal> is used to invoke
    214         32-bit implementations of OpenMCL and
     222        32-bit implementations of &CCL; and
    215223        <literal>"ccl/scripts/openmcl64"</literal> is used to invoke
    216224        64-bit implementations.</para>
     
    228236            openmcl script will not override it.The shell script sets
    229237            a local variable (<literal>OPENMCL_KERNEL</literal>) to
    230             the standard name of the OpenMCL kernel approprate for the
     238            the standard name of the &CCL; kernel approprate for the
    231239            platform (asdetermined by 'uname -s'.) You might prefer to
    232240            set this variable manually in the shell script</para>
     
    242250            <warning>
    243251              <para>The above command won't work if you are not the
    244               owner of the installed copy of OpenMCL. In that case,
     252              owner of the installed copy of &CCL;. In that case,
    245253              you can use the "sudo" command like this:</para>
    246254              <para><literal>$ sudo chmod +x
     
    261269
    262270        <para>Once this is done, it should be possible to invoke
    263         OpenMCL by typing <literal>openmcl</literal> at a shell
     271        &CCL; by typing <literal>openmcl</literal> at a shell
    264272        prompt:</para>
    265273        <programlisting>
    266274&gt; openmcl [args ...]
    267 Welcome to OpenMCL Version whatever (DarwinPPC32)!
     275Welcome to &CCL; Version whatever (DarwinPPC32)!
    268276?
    269277</programlisting>
    270278        <para>The openmcl shell script will pass all of its arguments
    271         to the OpenMCL kernel.  See <xref linkend="Invocation"/> for
     279        to the &CCL; kernel.  See <xref linkend="Invocation"/> for
    272280        more information about "args".  When invoked this way, the
    273281        lisp should be able to initialize the
     
    275283        translations refer to the <literal>"ccl"</literal>
    276284        directory. To test this, you can call
    277         <literal>probe-file</literal> in OpenMCL's read-eval-print
     285        <literal>probe-file</literal> in &CCL;'s read-eval-print
    278286        loop:</para>
    279287        <programlisting>
     
    284292      <sect2 id="Invocation">
    285293        <title>Invocation</title>
    286         <para>Assuming that the shell script is properly installed, it can be used to invoke OpenMCL from a shell prompt:
     294        <para>Assuming that the shell script is properly installed, it can be used to invoke &CCL; from a shell prompt:
    287295        <programlisting>
    288296shell&gt;<replaceable>ccl</replaceable> <emphasis>args</emphasis>
     
    294302      <sect2 id="Personal-Customization-with-the-Init-File">
    295303        <title>Personal Customization with the Init File</title>
    296         <para>By default OpenMCL will try to load the file
     304        <para>By default &CCL; will try to load the file
    297305        <literal>"home:openmcl-init.lisp"</literal> or the compiled
    298306       
     
    303311        taken; an error is not signalled.</para>
    304312        <para>The <literal>"home:"</literal> prefix to the filename is
    305         a Common Lisp logical host, which OpenMCL initializes to refer
     313        a Common Lisp logical host, which &CCL; initializes to refer
    306314        to your home directory, so this looks for either of the files
    307315        <literal>~/openmcl-init.lisp</literal> or
     
    311319        example, you can change the working directory, and load
    312320        packages which you use frequently.</para>
    313         <para>To suppress the loading of this init-file, invoke OpenMCL with the
     321        <para>To suppress the loading of this init-file, invoke &CCL; with the
    314322<literal>--no-init</literal> option.</para>
    315323      </sect2>
     
    318326        <title>Some (hopefully) useful options</title>
    319327        <para> The exact set of command-line arguments accepted by
    320         OpenMCL may vary slightly from release to release;
     328        &CCL; may vary slightly from release to release;
    321329        <literal>openmcl --help</literal> will provide a definitive
    322330        (if somewhat terse) summary of the options accepted by the
     
    331339          <listitem>
    332340            <para>-b (or --batch). Execute in &#34;batch mode&#34;. End-of-file
    333             from *STANDARD-INPUT* will cause OpenMCL to exit, as will attempts to
     341            from *STANDARD-INPUT* will cause &CCL; to exit, as will attempts to
    334342            enter a break loop.</para>
    335343          </listitem>
     
    337345          <listitem>
    338346            <para>-n (or --no-init). If this option is given, the init file
    339             is not loaded.  This is useful if OpenMCL is being invoked by a
     347            is not loaded.  This is useful if &CCL; is being invoked by a
    340348            shell script which should not be affected by whatever
    341349            customizations a user might have in place.
     
    366374    </sect1>
    367375
    368     <sect1 id="Using-OpenMCL-with-GNU-Emacs-and-SLIME">
    369       <title>Using OpenMCL with GNU Emacs and SLIME</title>
    370       <para>A very common way to use OpenMCL is to run it within the
     376    <sect1 id="Using-&CCL;-with-GNU-Emacs-and-SLIME">
     377      <title>Using &CCL; with GNU Emacs and SLIME</title>
     378      <para>A very common way to use &CCL; is to run it within the
    371379      GNU Emacs editor, using a Lisp interface called SLIME ("Superior
    372380      Lisp Interaction Mode for Emacs"). SLIME is an Emacs package
    373381      designed to provide good support within Emacs for any of several
    374382      Common Lisp implementations; one of the supported
    375       implementations is OpenMCL. This page describes how you can
    376       download SLIME and set it up to work with your OpenMCL
     383      implementations is &CCL;. This page describes how you can
     384      download SLIME and set it up to work with your &CCL;
    377385      installation.</para>
    378386      <para>Why use SLIME? With SLIME, you can do the following things from within
     
    418426              without getting and installing it separately. You just
    419427              need to tell SLIME where to find your installation of
    420               OpenMCL. (See FIXTHIS.)</para>
     428              &CCL;. (See FIXTHIS.)</para>
    421429            </warning>
    422430          </para>
    423431          </listitem>
    424432          <listitem>
    425             <para>You have a working copy of OpenMCL, installed in
     433            <para>You have a working copy of &CCL;, installed in
    426434            <literal>"~/openmcl/ccl"</literal>If you prefer to install
    427             OpenMCL in some directory other
     435            &CCL; in some directory other
    428436            than<literal>"~/openmcl/ccl"</literal> then these
    429437            instructions still work, but you must remember to use your
     
    478486      <sect2 id="Telling-Emacs-About-SLIME">
    479487        <title>Telling Emacs About SLIME</title>
    480         <para> Once SLIME and OpenMCL are installed, you just need to
     488        <para> Once SLIME and &CCL; are installed, you just need to
    481489        add a line to your "~/.emacs" file that tells SLIME where to
    482         find the script that runs OpenMCL:</para>
     490        find the script that runs &CCL;:</para>
    483491        <para><literal>(setq inferior-lisp-program "~/openmcl/ccl/scripts/openmcl64")</literal></para>
    484492        <para>or</para>
     
    489497      </sect2>
    490498
    491       <sect2 id="Running-OpenMCL-with-SLIME">
    492         <title>Running OpenMCL with SLIME</title>
     499      <sect2 id="Running-&CCL;-with-SLIME">
     500        <title>Running &CCL; with SLIME</title>
    493501        <para>Once the preparations in the previous section are
    494502        complete, exit Emacs and restart it, to ensure that it reads
    495503        the changes you made in your ".emacs" file (alternatively, you
    496504        could tell Emacs to reload the ".emacs" file). If all went
    497         well, you should now be ready to run OpenMCL using
     505        well, you should now be ready to run &CCL; using
    498506        SLIME.</para>
    499         <para>To run OpenMCL, execute the command "M-x slime". SLIME
    500         should start an OpenMCL session in a new buffer.  (If you are
     507        <para>To run &CCL;, execute the command "M-x slime". SLIME
     508        should start an &CCL; session in a new buffer.  (If you are
    501509        unfamiliar with the Emacs notation "M-x command", see the GNU
    502510        Emacs FAQ; specifically, take a look at questions 1, 2, and
     
    504512      </sect2>
    505513
    506       <sect2 id="What-if-a-New-Version-of-OpenMCL-Breaks-SLIME-">
    507         <title>What if a New Version of OpenMCL Breaks SLIME?</title>
    508         <para>Sometimes you'll get a new version of OpenMCL, set up
     514      <sect2 id="What-if-a-New-Version-of-&CCL;-Breaks-SLIME-">
     515        <title>What if a New Version of &CCL; Breaks SLIME?</title>
     516        <para>Sometimes you'll get a new version of &CCL;, set up
    509517        Emacs to use it with SLIME, and SLIME will fail. Most likely
    510         what has happened is that the new version of OpenMCL has a
    511         change in the output files produced by the compiler (OpenMCL
     518        what has happened is that the new version of &CCL; has a
     519        change in the output files produced by the compiler (&CCL;
    512520        developers will say "the fasl version has changed." fasl
    513521        stands for "fast load" aka compiled files). This
     
    533541        <title>Known Bugs</title>
    534542        <para>SLIME has not been updated to account for recent changes
    535         made in OpenMCL to support x86-64 processors. You may run into
     543        made in &CCL; to support x86-64 processors. You may run into
    536544        bugs running on those platforms.</para>
    537545        <para>The SLIME backtrace sometimes shows incorrect information.</para>
     
    540548        they work at all, it's pure luck.)</para>
    541549        <para>Some versions of Emacs on the Macintosh may have trouble
    542         finding the shell script that runs OpenMCL unless you specify
     550        finding the shell script that runs &CCL; unless you specify
    543551        a full path to it. See the above section "Telling Emacs About
    544552        SLIME" to learn how to specify the path to the shell
    545553        script.</para>
    546         <para>For more help with OpenMCL on Mac OS X, consult the
    547         OpenMCL mailing lists.</para>
     554        <para>For more help with &CCL; on Mac OS X, consult the
     555        &CCL; mailing lists.</para>
    548556      </sect2>
    549557    </sect1>
     
    569577      responsible for any consequences of your decision to use
    570578      it.</para>
    571       <para>If you've developed OpenMCL examples that you'd like to
     579      <para>If you've developed &CCL; examples that you'd like to
    572580      see added to the distribution, please send mail to let me
    573581      know. Any such contributions would be welcome and appreciated
  • trunk/source/doc/src/modifying.xml

    r8599 r8606  
    77<!ENTITY aux "<varname>&amp;aux</varname>">
    88<!ENTITY allow-other-keys "<varname>&amp;allow-other-keys</varname>">
     9<!ENTITY CCL "<literal>CCL</literal>">
    910]>
    1011
    11   <chapter id="Modifying-OpenMCL">
    12     <title>Modifying OpenMCL</title>
    13 
    14     <sect1 id="Contributing-Code-Back-to-the-OpenMCL-Project">
    15       <title>Contributing Code Back to the OpenMCL Project</title>
     12  <chapter id="Modifying-&CCL;">
     13    <title>Modifying &CCL;</title>
     14
     15    <sect1 id="Contributing-Code-Back-to-the-&CCL;-Project">
     16      <title>Contributing Code Back to the &CCL; Project</title>
    1617      <para>This section is a placeholder, added as of August 2004.  The
    1718      full text is being written, and will be added as soon as it is
     
    1920    </sect1>
    2021
    21     <sect1 id="Using-OpenMCL-in--development--and-in--user--mode">
    22       <title>Using OpenMCL in "development" and in  "user" mode</title>
    23 
    24       <para>As it's distributed, OpenMCL starts up with *PACKAGE* set
     22    <sect1 id="Using-&CCL;-in--development--and-in--user--mode">
     23      <title>Using &CCL; in "development" and in  "user" mode</title>
     24
     25      <para>As it's distributed, &CCL; starts up with *PACKAGE* set
    2526      to the CL-USER package and with most predefined functions and
    2627      methods protected against accidental redefinition.  The package
     
    3031      function) before those errors have a chance to do much
    3132      damage.</para>
    32       <para>These settings may make using OpenMCL to develop OpenMCL a
     33      <para>These settings may make using &CCL; to develop &CCL; a
    3334      bit more awkward, since much of that process assumes that the
    3435      CCL package is current (and a primary purpose of that process is
    3536      to redefine some "predefined, builtin functions".) The standard,
    36       "routine" ways of building OpenMCL from sources (see ) -
     37      "routine" ways of building &CCL; from sources (see ) -
    3738      COMPILE-CCL, XCOMPILE-CCL, and XLOAD-LEVEL-0 - bind *PACKAGE* to
    3839      the "CCL" package and enable the redefinition of predefined
     
    4142      package.</para>
    4243      <para>Some other (more ad-hoc) ways of doing development on
    43       OpenMCL - compiling and/or loading individual files,
     44      &CCL; - compiling and/or loading individual files,
    4445      incrementally redefining individual functions - may be awkward
    4546      unless one reverts to the mode of operation which was
    46       traditionally offered in OpenMCL. (Some OpenMCL source files -
     47      traditionally offered in &CCL;. (Some &CCL; source files -
    4748      especially those that comprise the bootstrapping image sources
    4849      and the first few files in the "cold load" sequence - are
     
    6061      <para>"user" and "development" are otherwise very generic terms;
    6162      here they're intended to enforce the distinction between "using"
    62       OpenMCL and "developing" it.</para>
    63       <para>The initial environment from which OpenMCL images are
     63      &CCL; and "developing" it.</para>
     64      <para>The initial environment from which &CCL; images are
    6465      saved is one where (SET-USER-ENVIRONMENT T) has just been
    6566      called; in previous versions, it was effectively as if
    6667      (SET-DEVELOPMENT-ENVIRONMENT T) had just been called.</para>
    67       <para>Hopefully, most users of OpenMCL can safely ignore these
     68      <para>Hopefully, most users of &CCL; can safely ignore these
    6869      issues most of the time. Note that doing (SET-USER-ENVIRONMENT
    69       T) after loading one's own code (or 3rd-party code) into OpenMCL
    70       would protect that code (as well as OpenMCL's) from accidental
     70      T) after loading one's own code (or 3rd-party code) into &CCL;
     71      would protect that code (as well as &CCL;'s) from accidental
    7172      redefinition; that may be useful in some cases.</para>
    7273    </sect1>
     
    7778      happen:</para>
    7879      <programlisting>
    79 Welcome to OpenMCL Version x.y!
     80Welcome to &CCL; Version x.y!
    8081? (defun foo (x)
    8182    (declare (cons x))
     
    107108
    108109? (classify 0)
    109 Bug in OpenMCL system code:
     110Bug in &CCL; system code:
    110111I give up. How could this happen ?
    111112? for help
    112 [12345] OpenMCL kernel debugger:
     113[12345] &CCL; kernel debugger:
    113114      </programlisting>
    114115      <para>CCL::BUG isn't quite the right tool for this example (a
     
    127128(B)  Show backtrace
    128129(X)  Exit from this debugger, asserting that any exception was handled
    129 (K)  Kill OpenMCL process
     130(K)  Kill &CCL; process
    130131(?)  Show this help
    131132</programlisting>
     
    150151 While executing: #&lt;Function CLASSIFY2 #x08476cfe>
    151152? for help
    152 [12345] OpenMCL kernel debugger: ?
     153[12345] &CCL; kernel debugger: ?
    153154(G)  Set specified GPR to new value
    154155(A)  Advance the program counter by one instruction (use with caution!)
     
    161162(X)  Exit from this debugger, asserting that any exception was handled
    162163(P)  Propagate the exception to another handler (debugger or OS)
    163 (K)  Kill OpenMCL process
     164(K)  Kill &CCL; process
    164165(?)  Show this help
    165166</programlisting>
    166167      <para>CCL::DBG takes an argument, whose value is copied into the register
    167 that OpenMCL uses to return a function's primary value (arg_z, which
     168that &CCL; uses to return a function's primary value (arg_z, which
    168169is r23 on the PowerPC). If we were to choose the (L) option at this point,
    169170we'd see a dislay like:</para>
     
    199200    </sect1>
    200201
    201     <sect1 id="Using-AltiVec-in-OpenMCL-LAP-functions">
    202       <title>Using AltiVec in OpenMCL LAP functions</title>
     202    <sect1 id="Using-AltiVec-in-&CCL;-LAP-functions">
     203      <title>Using AltiVec in &CCL; LAP functions</title>
    203204
    204205      <sect2 id="Overview--16-">
     
    214215        did.</para>
    215216        <para>This document does explain AltiVec register-usage
    216         conventions in OpenMCL and explains the use of some lap macros
     217        conventions in &CCL; and explains the use of some lap macros
    217218        that help to enforce those conventions.</para>
    218219        <para>All of the global symbols described below are exported
     
    221222        treated as strings, so this only applies to functions and
    222223        global variable names.</para>
    223         <para>Much of the OpenMCL support for AltiVec LAP programming
     224        <para>Much of the &CCL; support for AltiVec LAP programming
    224225        is based on work contributed to MCL by Shannon Spires.</para>
    225226      </sect2>
     
    227228      <sect2 id="Register-usage-conventions">
    228229        <title>Register usage conventions</title>
    229         <para>OpenMCL LAP functions that use AltiVec instructions must
     230        <para>&CCL; LAP functions that use AltiVec instructions must
    230231        interoperate with each other and with C functions; that
    231232        suggests that they follow C AltiVec register usage
     
    277278</programlisting>
    278279        <para>AltiVec registers are not preserved by CATCH and UNWIND-PROTECT.
    279 Since AltiVec is only accessible from LAP in OpenMCL and since LAP
     280Since AltiVec is only accessible from LAP in &CCL; and since LAP
    280281functions rarely use high- level control structures, this should rarely be
    281282a problem in practice.</para>
     
    310311          <para>Note that these are CERRORs, not warnings, and that
    311312          no lisp functions or methods have been defined in the kernel
    312           in MCL or OpenMCL since 1987 or so.</para>
     313          in MCL or &CCL; since 1987 or so.</para>
    313314        </refsect1>
    314315      </refentry>
     
    383384        <refsect1>
    384385          <title>Description</title>
    385           <para>This variable is intitialized each time an OpenMCL session
     386          <para>This variable is intitialized each time an &CCL; session
    386387          starts based on information provided by the lisp kernel. Its value
    387388          is true if AltiVec is present and false otherwise. This variable
  • trunk/source/doc/src/mop.xml

    r8599 r8606  
    77<!ENTITY aux "<varname>&amp;aux</varname>">
    88<!ENTITY allow-other-keys "<varname>&amp;allow-other-keys</varname>">
     9<!ENTITY CCL "<literal>CCL</literal>">
    910]>
    1011
     
    1415    <sect1 id="MOP-Overview">
    1516      <title>Overview</title>
    16       <para>OpenMCL supports a fairly large subset of the
     17      <para>&CCL; supports a fairly large subset of the
    1718      semi-standard MetaObject Protocol (MOP) for CLOS, as defined in
    1819      chapters 5 and 6 of "The Art Of The Metaobject Protocol",
     
    325326      dispatch and method invocation (the "Generic Function Invocation
    326327      Protocol".) Method functions are implemented a bit differently
    327       in OpenMCL from what the MOP expects, and it's not yet clear if
     328      in &CCL; from what the MOP expects, and it's not yet clear if
    328329      or how this subprotocol can be well-supported.</para>
    329330      <para>Those constructs that are marked as "+" in the table above
  • trunk/source/doc/src/objc-bridge.xml

    r8599 r8606  
    11<?xml version="1.0" encoding="utf-8"?>
    2 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
     2<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"[
     3<!ENTITY rest "<varname>&amp;rest</varname>">
     4<!ENTITY key "<varname>&amp;key</varname>">
     5<!ENTITY optional "<varname>&amp;optional</varname>">
     6<!ENTITY body "<varname>&amp;body</varname>">
     7<!ENTITY aux "<varname>&amp;aux</varname>">
     8<!ENTITY allow-other-keys "<varname>&amp;allow-other-keys</varname>">
     9<!ENTITY CCL "<literal>CCL</literal>">
     10]>
    311  <chapter id="The-Objective-C-Bridge">
    412    <title>The Objective-C Bridge</title>
     
    917    which can be used by ObjC.</para>
    1018    <para>The ultimate purpose of the ObjC and Cocoa bridges is to
    11     make Cocoa as easy as possible to use from OpenMCL, in order to
     19    make Cocoa as easy as possible to use from &CCL;, in order to
    1220    support the development of GUI applications and IDEs.  The
    1321    eventual goal, which is much closer than it used to be, is
     
    5361to be fast.</para>
    5462      <para>When the process is complete, CLOS is aware of several hundred
    55 new ObjC classes and their metaclasses. OpenMCL's runtime system can
     63new ObjC classes and their metaclasses. &CCL;'s runtime system can
    5664reliably recognize MACPTRs to ObjC classes as being CLASS objects, and
    5765can (fairly reliably but heuristically) recognize instances of those
     
    105113of modifying the existing one.
    106114In fact, if you leave out the setq and
    107 then try to view the value of *N*, OpenMCL will freeze.  There's
     115then try to view the value of *N*, &CCL; will freeze.  There's
    108116little reason to ever do it this way; this is just to show
    109117what's going on.</para>
     
    173181      <sect2 id="Type-Coercion-for-ObjC-Method-Calls">
    174182        <title>Type Coercion for ObjC Method Calls</title>
    175         <para>OpenMCL's FFI handles many common conversions between
     183        <para>&CCL;'s FFI handles many common conversions between
    176184        Lisp and foreign data, such as unboxing floating-point args
    177185        and boxing floating-point results.  The bridge adds a few more
     
    398406        be a "foreign slot" (i.e. an ObjC instance variable). Be aware
    399407        that it is an error to redefine an ObjC class so that its
    400         foreign slots change in any way, and OpenMCL doesn't do
     408        foreign slots change in any way, and &CCL; doesn't do
    401409        anything consistent when you try to.</para>
    402410        <para>The value of the :FOREIGN-TYPE initarg should be a
  • trunk/source/doc/src/platform-notes.xml

    r8599 r8606  
    77<!ENTITY aux "<varname>&amp;aux</varname>">
    88<!ENTITY allow-other-keys "<varname>&amp;allow-other-keys</varname>">
     9<!ENTITY CCL "<literal>CCL</literal>">
    910]>
    1011
     
    1617      <title>Overview</title>
    1718      <para> The documentation and whatever experience you may have in
    18       using OpenMCL under Linux should also apply to using it under
     19      using &CCL; under Linux should also apply to using it under
    1920      Darwin/MacOS X and FreeBSD. There are some differences between
    2021      the platforms, and these differences are sometimes exposed in
     
    2728        <para>Darwin and MacOS X use HFS+ file systems by default;
    2829        HFS+ file systems are usually case-insensitive. Most of
    29         OpenMCL's filesystem and pathname code assumes that the
     30        &CCL;'s filesystem and pathname code assumes that the
    3031        underlying filesystem is case-sensitive; this assumption
    3132        extends to functions like EQUAL, which assumes that #p"FOO"
     
    4041        </programlisting>
    4142        <para>on 32-bit DarwinPPC has the unfortunate side-effect of
    42         trying to overwrite the Darwin OpenMCL kernel, "dppccl", on a
     43        trying to overwrite the Darwin &CCL; kernel, "dppccl", on a
    4344        case-insensitive filesystem.</para>
    44         <para>To work around this, the Darwin OpenMCL kernel expects
     45        <para>To work around this, the Darwin &CCL; kernel expects
    4546        the default heap image file name to be the kernel's own
    4647        filename with the string ".image" appended, so the idiom would
     
    6263        Sometimes this is true, other times ... not so much.
    6364        </para>
    64         <para>OpenMCL follows the Unix convention on both Darwin and
     65        <para>&CCL; follows the Unix convention on both Darwin and
    6566        LinuxPPC, but offers some support for reading and writing
    6667        files that use other conventions (including traditional MacOS
     
    8182        related to the third newline convention ("CRLF") in widespread
    8283        use (since that convention isn't native to any platform on
    83         which OpenMCL currently runs). If OpenMCL is ever ported to
     84        which &CCL; currently runs). If &CCL; is ever ported to
    8485        such a platform, that issue might be revisited.</para>
    8586        <para>Note that some MacOS programs (including some versions
    8687        of commercial MCL) may use HFS file type information to
    8788        recognize TEXT and other file types and so may fail to
    88         recognize files created with OpenMCL or other Darwin
     89        recognize files created with &CCL; or other Darwin
    8990        applications (regardless of line termination issues.)</para>
    9091        <para>Unless otherwise noted, the symbols mentioned in this
     
    9899        (up to and including at least OSX 10.2 (Jaguar) don't implement
    99100        single-precision variants of the transcendental and trig functions
    100         (#_sinf, #_atanf, etc.) OpenMCL worked around this by coercing
     101        (#_sinf, #_atanf, etc.) &CCL; worked around this by coercing
    101102        single-precision args to double-precision, calling the
    102103        double-precision version of the math library function, and coercing
     
    116117        "bundles/extensions" - are expected to be loaded into and
    117118        unloaded from a running application, via a mechanism like the
    118         one used by OpenMCL's OPEN-SHARED-LIBRARY function.</para>
     119        one used by &CCL;'s OPEN-SHARED-LIBRARY function.</para>
    119120      </sect2>
    120121    </sect1>
     
    122123    <sect1 id="Unix-Posix-Darwin-Features">
    123124      <title>Unix/Posix/Darwin Features</title>
    124       <para>OpenMCL has several convenience functions which allow you
     125      <para>&CCL; has several convenience functions which allow you
    125126      to make Posix (portable Unix) calls without having to use the
    126127      foreign-function interface.  Each of these corresponds directly
     
    144145    </sect1>
    145146
    146     <sect1 id="Cocoa-Programming-in-OpenMCL">
    147       <title>Cocoa Programming in OpenMCL</title>
     147    <sect1 id="Cocoa-Programming-in-&CCL;">
     148      <title>Cocoa Programming in &CCL;</title>
    148149      <para>Cocoa is one of Apple's APIs for GUI programming; for most
    149150      purposes, development is considerably faster with Cocoa than
     
    163164      <sect2 id="The-Command-Line-and-the-Window-System">
    164165        <title>The Command Line and the Window System</title>
    165         <para>OpenMCL is ordinarily a command-line application (it
     166        <para>&CCL; is ordinarily a command-line application (it
    166167        doesn't have a connection to the OSX Window server, doesn't
    167168        have its own menubar or dock icon, etc.) By opening some
     
    291292? (require "COCOA-APPLICATION")
    292293      </programlisting>
    293       <para>When it finishes, you should be able to double-click the OpenMCL icon
     294      <para>When it finishes, you should be able to double-click the &CCL; icon
    294295in the ccl directory, to quickly start your program.</para>
    295       <para>The OS may have already decided that OpenMCL.app isn't a valid
     296      <para>The OS may have already decided that &CCL;.app isn't a valid
    296297executable bundle, and therefore won't let you double-click it.
    297298If this happens to you, to force it to reconsider, just update the
    298299last-modified time of the bundle.  In Terminal:</para>
    299       <programlisting>> touch OpenMCL.app
     300      <programlisting>> touch &CCL;.app
    300301</programlisting>
    301302      <para>There is one important caveat.</para>
     
    535536
    536537          <para>
    537             Looks up the current working directory of the OpenMCL process;
    538             unless it has been changed, this is the directory OpenMCL was
     538            Looks up the current working directory of the &CCL; process;
     539            unless it has been changed, this is the directory &CCL; was
    539540            started in.
    540541          </para>
     
    627628            Attempts to change the current user ID (both "real" and
    628629            "effective"); fails unless
    629             the OpenMCL process has super-user privileges or the ID
     630            the &CCL; process has super-user privileges or the ID
    630631            given is that of the current user.
    631632          </para>
     
    679680            Attempts to change the current group ID (both "real" and
    680681            "effective"); fails unless
    681             the OpenMCL process has super-user privileges or the ID
     682            the &CCL; process has super-user privileges or the ID
    682683            given is that of a group to which the current user belongs.
    683684          </para>
     
    718719
    719720          <para>
    720             Returns the ID of the OpenMCL OS process.
     721            Returns the ID of the &CCL; OS process.
    721722          </para>
    722723        </refsect1>
     
    10581059            function for #\; (single-line comments); that function reads successive
    10591060            characters until EOF, a #\NewLine is read, or a character EQL to the
    1060             value of *alternate-line-terminator* is read. In OpenMCL for Darwin, the
    1061             value of this variable is initially #\Return ; in OpenMCL for LinuxPPC,
     1061            value of *alternate-line-terminator* is read. In &CCL; for Darwin, the
     1062            value of this variable is initially #\Return ; in &CCL; for LinuxPPC,
    10621063            it&#39;s initially NIL.</para>
    10631064           
     
    10911092            <title>Description</title>
    10921093
    1093             <para>Per ANSI CL, OpenMCL supports the :EXTERNAL-FORMAT keyword
     1094            <para>Per ANSI CL, &CCL; supports the :EXTERNAL-FORMAT keyword
    10941095            argument to the functions OPEN, LOAD, and COMPILE-FILE. This argument is
    10951096            intended to provide a standard way of providing implementation-dependent
    10961097            information about the format of files opened with an element-type of
    10971098            CHARACTER. This argument can meaningfully take on the values :DEFAULT
    1098             (the default), :MACOS, :UNIX, or :INFERRED in OpenMCL.</para>
     1099            (the default), :MACOS, :UNIX, or :INFERRED in &CCL;.</para>
    10991100           
    11001101            <para>When defaulted to or specified as :DEFAULT, the format of the file
     
    11481149            <para>Because there&#39;s some risk that unsolicited newline translation
    11491150            could have undesirable consequences, the initial value of this variable
    1150             in OpenMCL is :UNIX.</para>
     1151            in &CCL; is :UNIX.</para>
    11511152          </refsect1>
    11521153        </refentry>
  • trunk/source/doc/src/q-and-a.xml

    r8599 r8606  
    11<?xml version="1.0" encoding="utf-8"?>
    2 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
     2<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"[
     3<!ENTITY rest "<varname>&amp;rest</varname>">
     4<!ENTITY key "<varname>&amp;key</varname>">
     5<!ENTITY optional "<varname>&amp;optional</varname>">
     6<!ENTITY body "<varname>&amp;body</varname>">
     7<!ENTITY aux "<varname>&amp;aux</varname>">
     8<!ENTITY allow-other-keys "<varname>&amp;allow-other-keys</varname>">
     9<!ENTITY CCL "<literal>CCL</literal>">
     10]>
    311  <chapter id="Questions-and-Answers">
    412
     
    4149      <title>I'm using the graphics demos. Why doesn't the menubar
    4250      change?</title>
    43       <para>When you interact with text-only OpenMCL, you're either
    44       in Terminal or in Emacs, running OpenMCL as a subprocess.  When
     51      <para>When you interact with text-only &CCL;, you're either
     52      in Terminal or in Emacs, running &CCL; as a subprocess.  When
    4553      you load Cocoa or the graphical environment, the subprocess does
    4654      some tricky things that turn it into a full-fledged Application,
     
    4957      and so on.  It can be confusing, because standard input and
    5058      output will still be connected to Terminal or Emacs, so you can
    51       still type commands to OpenMCL from there.  To see the menubar
    52       you loaded, or the windows you opened, just click on the OpenMCL
     59      still type commands to &CCL; from there.  To see the menubar
     60      you loaded, or the windows you opened, just click on the &CCL;
    5361      icon in the dock.</para>
    5462    </sect1>
     
    5866      seem to work? </title>
    5967      <para>This comes up if you're using the Slime interface
    60       to run OpenMCL under Emacs, and you are doing Cocoa programming
     68      to run &CCL; under Emacs, and you are doing Cocoa programming
    6169      which involves printing to *standard-output*.  It seems as
    6270      though the output goes nowhere; no error is reported, but it
  • trunk/source/doc/src/sockets.xml

    r8599 r8606  
    77<!ENTITY aux "<varname>&amp;aux</varname>">
    88<!ENTITY allow-other-keys "<varname>&amp;allow-other-keys</varname>">
     9<!ENTITY CCL "<literal>CCL</literal>">
    910]>
    1011
     
    1516      <title>Overview</title>
    1617
    17       <para>OpenMCL supports the socket abstraction for
     18      <para>&CCL; supports the socket abstraction for
    1819      interprocess communication. A socket represents a connection to
    1920      another process, typically (but not necessarily) a TCP/IP
     
    2324      the CCL package. As of version 0.13, these symbols are
    2425      additionally exported from the OPENMCL-SOCKET package.</para>
    25       <para>OpenMCL supports three types of sockets: TCP sockets, UDP
     26      <para>&CCL; supports three types of sockets: TCP sockets, UDP
    2627      sockets, and Unix-domain sockets.  This should be enough for all
    2728      but the most esoteric network situations.  All sockets are
  • trunk/source/doc/src/streams.xml

    r8599 r8606  
    77<!ENTITY aux "<varname>&amp;aux</varname>">
    88<!ENTITY allow-other-keys "<varname>&amp;allow-other-keys</varname>">
     9<!ENTITY CCL "<literal>CCL</literal>">
    910]>
    1011
     
    7879      <para>According to the original Gray streams proposal, you
    7980      should inherit from the most specific of the fundamental-*
    80       classes which applies.  Using OpenMCL, though, if you want
     81      classes which applies.  Using &CCL;, though, if you want
    8182      buffering for better performance, which, unless you know of some
    8283      reason you wouldn't, you do, you should instead inherit from the
     
    226227    <sect1 id="Multibyte-I-O">
    227228      <title>Multibyte I/O</title>
    228       <para>All heap-allocated objects in OpenMCL that cannot contain
     229      <para>All heap-allocated objects in &CCL; that cannot contain
    229230      pointers to lisp objects are represented as
    230       <emphasis>ivectors</emphasis>. OpenMCL provides low-level
     231      <emphasis>ivectors</emphasis>. &CCL; provides low-level
    231232      functions, and , to efficiently transfer data between buffered
    232233      streams and ivectors. There's some overlap in functionality
  • trunk/source/doc/src/threads.xml

    r8599 r8606  
    77<!ENTITY aux "<varname>&amp;aux</varname>">
    88<!ENTITY allow-other-keys "<varname>&amp;allow-other-keys</varname>">
     9<!ENTITY CCL "<literal>CCL</literal>">
    910]>
    1011
     
    1516      <title>Threads Overview</title>
    1617
    17       <para>OpenMCL provides facilities which enable multiple threads
     18      <para>&CCL; provides facilities which enable multiple threads
    1819      of execution (<emphasis>threads</emphasis>, sometimes called
    1920      <emphasis>lightweight processes</emphasis> or just
     
    2122      be confused with the OS's notion of a process) within a lisp
    2223      session. This document describes those facilities and issues
    23       related to multitheaded programming in OpenMCL.</para>
     24      related to multitheaded programming in &CCL;.</para>
    2425
    2526      <para>Wherever possible, I'll try to use the term "thread" to
     
    3536      dynamic binding context.</para>
    3637     
    37       <para>Traditionally, OpenMCL's threads have been
     38      <para>Traditionally, &CCL;'s threads have been
    3839      <emphasis>cooperatively scheduled</emphasis>: through a
    3940      combination of compiler and runtime suppport, the currently
     
    5253      thread running in the Lisp image and its stack pointer and other
    5354      registers just happened to change from time to time.</para>
    54       <para>Under OpenMCL's cooperative scheduling model, it was
     55      <para>Under &CCL;'s cooperative scheduling model, it was
    5556      possible (via the use of the CCL:WITHOUT-INTERRUPTS construct)
    5657      to defer handling of the periodic interrupt that invoked the
    5758      lisp scheduler; it was not uncommon to use WITHOUT-INTERRUPTS to
    5859      gain safe, exclusive access to global data structures. In some
    59       code (including much of OpenMCL itself) this idiom was very
     60      code (including much of &CCL; itself) this idiom was very
    6061      common: it was (justifiably) believed to be an efficient way of
    6162      inhibiting the execution of other threads for a short period of
     
    7576      <para>For a variety of reasons - better utilization of CPU
    7677      resources on single and multiprocessor systems and better
    77       integration with the OS in general - threads in OpenMCL 0.14 and
     78      integration with the OS in general - threads in &CCL; 0.14 and
    7879      later are <emphasis>preemptively scheduled. </emphasis>In this
    7980      model, lisp threads are native threads and all scheduling
     
    120121      tuned to the constraints of the cooperative scheduler may need
    121122      to be redesigned to work well with the preemptive scheduler (and
    122       code written to run under OpenMCL's interface to the native
     123      code written to run under &CCL;'s interface to the native
    123124      scheduler may be less portable to other CL implementations, many
    124125      of which offer a cooperative scheduler and an API similar to
    125       OpenMCL (&lt; 0.14) 's.) At the same time, there's a large
     126      &CCL; (&lt; 0.14) 's.) At the same time, there's a large
    126127      overlap in functionality in the two scheduling models, and it'll
    127128      hopefully be possible to write interesting and useful MP code
     
    136137      <title>(Intentionally) Missing Functionality</title>
    137138      <para>Much of the functionality described above is similar to
    138       that provided by OpenMCL's cooperative scheduler, some other
     139      that provided by &CCL;'s cooperative scheduler, some other
    139140      parts of which make no sense in a native threads
    140141      implementation.</para>
     
    189190        </listitem>
    190191        <listitem>
    191           <para>When native threads that aren't created by OpenMCL
     192          <para>When native threads that aren't created by &CCL;
    192193          first call into lisp, a "foreign process" is created, and
    193194          that process is given its own set of initial bindings and set
     
    204205    <sect1 id="Porting-Code-from-the-Old-Thread-Model">
    205206      <title>Porting Code from the Old Thread Model</title>
    206       <para>Older versions of OpenMCL used what are often called
     207      <para>Older versions of &CCL; used what are often called
    207208      "user-mode threads", a less versatile threading model which does
    208209      not require specific support from the operating system.  This
     
    234235          issues tend to be timing-sensitive, and decoupling thread
    235236          scheduling from lisp program execution affects timing. I know
    236           that there is or was code in both OpenMCL and commercial MCL
     237          that there is or was code in both &CCL; and commercial MCL
    237238          that was written under the explicit assumption that certain
    238239          sequences of open-coded operations were uninterruptable; it's
     
    249250        <title>Overview</title>
    250251        <para>
    251           Unless and until OpenMCL provides alternatives (via window
     252          Unless and until &CCL; provides alternatives (via window
    252253          streams, telnet streams, or some other mechanism) all lisp
    253254          processes share a common *TERMINAL-IO* stream (and therefore
     
    259260          *TERMINAL-IO*, that may be a little messy and a little
    260261          confusing to the user, but it shouldn't really be
    261           catastrophic. All I/O to OpenMCL's buffered streams goes
     262          catastrophic. All I/O to &CCL;'s buffered streams goes
    262263          thru a locking mechanism that prevents the worst kinds of
    263264          resource-contention problems.</para>
     
    286287          unreasonable one.</para>
    287288          <para>In the solution described here (and introduced in
    288           OpenMCL 0.9), the internal stream used to provide terminal
     289          &CCL; 0.9), the internal stream used to provide terminal
    289290          input is always locked by some process (the "owning"
    290291          process.) The initial process (the process that typically
     
    294295          terminal and relinquish ownership to the previous owner when
    295296          they're done with it.</para>
    296           <para>In OpenMCL, BREAK, ERROR, CERROR, Y-OR-N-P,
     297          <para>In &CCL;, BREAK, ERROR, CERROR, Y-OR-N-P,
    297298          YES-OR-NO-P, and CCL:GET-STRING- FROM-USER are all defined
    298299          in terms of WITH-TERMINAL-INPUT, as are the :TTY
     
    303304        <title>An example</title>
    304305        <programlisting>
    305 ? Welcome to OpenMCL Version (Beta: linux) 0.9!
     306? Welcome to &CCL; Version (Beta: linux) 0.9!
    306307?
    307308
     
    350351        the initial process regains control.</para>
    351352        <programlisting>
    352 ? Welcome to OpenMCL Version (Beta: linux) 0.9!
     353? Welcome to &CCL; Version (Beta: linux) 0.9!
    353354?
    354355
     
    422423        from a background process will need to be changed to use
    423424        WITH-TERMINAL-INPUT.  Since that code was probably not working
    424         reliably in previous versions of OpenMCL, this requirement
     425        reliably in previous versions of &CCL;, this requirement
    425426        doesn't seem to be too onerous.</para>
    426427        <para>Note that WITH-TERMINAL-INPUT both requests ownership of
     
    432433    </sect1>
    433434
    434     <sect1 id="The-Threads-which-OpenMCL-Uses-for-Its-Own-Purposes">
    435       <title>The Threads which OpenMCL Uses for Its Own Purposes</title>
     435    <sect1 id="The-Threads-which-&CCL;-Uses-for-Its-Own-Purposes">
     436      <title>The Threads which &CCL; Uses for Its Own Purposes</title>
    436437      <para>
    437 In the "tty world", OpenMCL starts out with 2 lisp-level threads:</para>
     438In the "tty world", &CCL; starts out with 2 lisp-level threads:</para>
    438439      <programlisting>
    439440? :proc
     
    4414420 :    Initial      [Active]
    442443</programlisting>
    443       <para>If you look at a running OpenMCL with a debugging tool,
     444      <para>If you look at a running &CCL; with a debugging tool,
    444445      such as GDB, or Apple's Thread Viewer.app, you'll see an
    445446      additional kernel-level thread on Darwin; this is used by the
     
    447448      <para>The initial thread, conveniently named "initial", is the
    448449      one that was created by the operating system when it launched
    449       OpenMCL.  It maps the heap image into memory, does some
     450      &CCL;.  It maps the heap image into memory, does some
    450451      Lisp-level initialization, and, when the Cocoa IDE isn't being
    451452      used, creates the thread "listener", which runs the top-level
     
    581582              <listitem>
    582583                <para>a list of all lisp processes (threads)
    583                 known to OpenMCL.</para>
     584                known to &CCL;.</para>
    584585              </listitem>
    585586            </varlistentry>
     
    590591
    591592          <para>Returns a list of all lisp processes (threads) known
    592           to OpenMCL as of
     593          to &CCL; as of
    593594          the precise instant it&#39;s called. It&#39;s safe to traverse
    594595          this list and to modify the cons cells that comprise that list
Note: See TracChangeset for help on using the changeset viewer.