Consistently refer to Julia over julia

The manual would sometimes refer to the language as either "Julia" or
"julia". This commit changes references to the Julia language as "Julia"
and any reference to the command line program as `julia`.

doc/manual/conversion-and-promotion.rst

@@ -153,8 +153,8 @@ to one and zero:
 
 The method signatures for conversion methods are often quite a bit more
 involved than this example, especially for parametric types. The example
-above is meant to be pedagogical, and is not the actual julia behaviour.
-This is the actual implementation in julia::
+above is meant to be pedagogical, and is not the actual Julia behaviour.
+This is the actual implementation in Julia::
 
     convert{T<:Real}(::Type{T}, z::Complex) = (imag(z)==0 ? convert(T,real(z)) :
                                                throw(InexactError()))

doc/manual/embedding.rst

@@ -18,15 +18,15 @@ We start with a simple C program that initializes Julia and calls some Julia cod
 
   int main(int argc, char *argv[])
   {
-      /* required: setup the julia context */
+      /* required: setup the Julia context */
       jl_init(NULL);
 
-      /* run julia commands */
+      /* run Julia commands */
       jl_eval_string("print(sqrt(2.0))");
 
-      /* strongly recommended: notify julia that the
+      /* strongly recommended: notify Julia that the
            program is about to terminate. this allows
-           julia time to cleanup pending write requests
+           Julia time to cleanup pending write requests
            and run all finalizers
       */
       jl_atexit_hook(0);

doc/manual/faq.rst

@@ -536,13 +536,13 @@ Memory
 Why does ``x += y`` allocate memory when ``x`` and ``y`` are arrays?
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-In julia, ``x += y`` gets replaced during parsing by ``x = x + y``.
+In Julia, ``x += y`` gets replaced during parsing by ``x = x + y``.
 For arrays, this has the consequence that, rather than storing the
 result in the same location in memory as ``x``, it allocates a new
 array to store the result.
 
 While this behavior might surprise some, the choice is deliberate. The
-main reason is the presence of ``immutable`` objects within julia,
+main reason is the presence of ``immutable`` objects within Julia,
 which cannot change their value once created.  Indeed, a number is an
 immutable object; the statements ``x = 5; x += 1`` do not modify the
 meaning of ``5``, they modify the value bound to ``x``. For an

doc/manual/getting-started.rst

@@ -49,7 +49,7 @@ argument to the julia command::
 
     $ julia script.jl arg1 arg2...
 
-As the example implies, the following command-line arguments to julia
+As the example implies, the following command-line arguments to ``julia``
 are taken as command-line arguments to the program ``script.jl``, passed
 in the global constant ``ARGS``. The name of the script itself is passed
 in as the global ``PROGRAM_FILE``. Note that ``ARGS`` is also set when script
@@ -87,7 +87,7 @@ specifies the ip-address and port that other workers should use to
 connect to this worker.
 
 
-If you have code that you want executed whenever julia is run, you can
+If you have code that you want executed whenever Julia is run, you can
 put it in ``~/.juliarc.jl``:
 
 .. raw:: latex
@@ -116,7 +116,7 @@ those available for the ``perl`` and ``ruby`` programs::
      -J, --sysimage <file>     Start up with the given system image file
      --precompiled={yes|no}    Use precompiled code from system image if available
      --compilecache={yes|no}   Enable/disable incremental precompilation of modules
-     -H, --home <dir>          Set location of julia executable
+     -H, --home <dir>          Set location of `julia` executable
      --startup-file={yes|no}   Load ~/.juliarc.jl
      --handle-signals={yes|no} Enable or disable Julia's default signal handlers
 

doc/manual/modules.rst

@@ -260,7 +260,7 @@ to reduce this time.
 There are two mechanisms that can achieve this:
 incremental compile and custom system image.
 
-To create a custom system image that can be used to start julia with the -J option,
+To create a custom system image that can be used when starting Julia with the ``-J`` option,
 recompile Julia after modifying the file ``base/userimg.jl`` to require the desired modules.
 
 To create an incremental precompiled module file, add

doc/manual/packages.rst

@@ -466,7 +466,7 @@ are several possible approaches, here is one that is widely used:
   run the tests:
 
   + From Julia, run :func:`Pkg.test("Foo") <Pkg.test>`: this will run your
-    tests in a separate (new) julia process.
+    tests in a separate (new) ``julia`` process.
   + From Julia, ``include("runtests.jl")`` from the package's ``test/`` folder
     (it's possible the file has a different name, look for one that runs all
     the tests): this allows you to run the tests repeatedly in the same session

doc/manual/parallel-computing.rst

@@ -167,7 +167,7 @@ the following code::
 
     end
 
-Starting julia with ``julia -p 2``, you can use this to verify the following:
+Starting Julia with ``julia -p 2``, you can use this to verify the following:
 
 - :func:`include("DummyModule.jl") <include>` loads the file on just a single process (whichever one executes the statement).
 - ``using DummyModule`` causes the module to be loaded on all processes; however, the module is brought into scope only on the one executing the statement.
@@ -202,7 +202,7 @@ The base Julia installation has in-built support for two types of clusters:
 - A local cluster specified with the ``-p`` option as shown above.
 
 - A cluster spanning machines using the ``--machinefile`` option. This uses a passwordless
-  ``ssh`` login to start julia worker processes (from the same path as the current host)
+  ``ssh`` login to start Julia worker processes (from the same path as the current host)
   on the specified machines.
 
 Functions :func:`addprocs`, :func:`rmprocs`, :func:`workers`, and others are available as a programmatic means of
@@ -729,15 +729,15 @@ handles mapping the shared segment being released sooner.
 ClusterManagers
 ---------------
 
-The launching, management and networking of julia processes into a logical
+The launching, management and networking of Julia processes into a logical
 cluster is done via cluster managers. A :obj:`ClusterManager` is responsible for
 
 - launching worker processes in a cluster environment
 - managing events during the lifetime of each worker
 - optionally, a cluster manager can also provide data transport
 
-A julia cluster has the following characteristics:
-- The initial julia process, also called the ``master`` is special and has a julia id of 1.
+A Julia cluster has the following characteristics:
+- The initial Julia process, also called the ``master`` is special and has a id of 1.
 - Only the ``master`` process can add or remove worker processes.
 - All processes can directly communicate with each other.
 
@@ -750,11 +750,11 @@ Connections between workers (using the in-built TCP/IP transport) is established
 - The cluster manager captures the stdout's of each worker and makes it available to the master process
 - The master process parses this information and sets up TCP/IP connections to each worker
 - Every worker is also notified of other workers in the cluster
-- Each worker connects to all workers whose julia id is less than its own id
+- Each worker connects to all workers whose id is less than its own id
 - In this way a mesh network is established, wherein every worker is directly connected with every other worker
 
 
-While the default transport layer uses plain TCP sockets, it is possible for a julia cluster to provide
+While the default transport layer uses plain TCP sockets, it is possible for a Julia cluster to provide
 its own transport.
 
 Julia provides two in-built cluster managers:
@@ -860,7 +860,7 @@ If ``io`` is not specified, ``host`` and ``port`` are used to connect.
 For example, a cluster manager may launch a single worker per node, and use that to launch
 additional workers. ``count`` with an integer value ``n`` will launch a total of ``n`` workers,
 while a value of ``:auto`` will launch as many workers as cores on that machine.
-``exename`` is the name of the julia executable including the full path.
+``exename`` is the name of the Julia executable including the full path.
 ``exeflags`` should be set to the required command line arguments for new workers.
 
 ``tunnel``, ``bind_addr``, ``sshflags`` and ``max_parallel`` are used when a ssh tunnel is
@@ -884,14 +884,14 @@ Cluster Managers with custom transports
 ---------------------------------------
 
 Replacing the default TCP/IP all-to-all socket connections with a custom transport layer is a little more involved.
-Each julia process has as many communication tasks as the workers it is connected to. For example, consider a julia cluster of
+Each Julia process has as many communication tasks as the workers it is connected to. For example, consider a Julia cluster of
 32 processes in a all-to-all mesh network:
 
-- Each julia process thus has 31 communication tasks
+- Each Julia process thus has 31 communication tasks
 - Each task handles all incoming messages from a single remote worker in a message processing loop
 - The message processing loop waits on an ``AsyncStream`` object - for example, a TCP socket in the default implementation, reads an entire
   message, processes it and waits for the next one
-- Sending messages to a process is done directly from any julia task - not just communication tasks - again, via the appropriate
+- Sending messages to a process is done directly from any Julia task - not just communication tasks - again, via the appropriate
   ``AsyncStream`` object
 
 Replacing the default transport involves the new implementation to setup connections to remote workers, and to provide appropriate
@@ -904,17 +904,17 @@ The default implementation (which uses TCP/IP sockets) is implemented as ``conne
 
 ``connect`` should return a pair of ``AsyncStream`` objects, one for reading data sent from worker ``pid``,
 and the other to write data that needs to be sent to worker ``pid``. Custom cluster managers can use an in-memory ``BufferStream``
-as the plumbing to proxy data between the custom, possibly non-AsyncStream transport and julia's in-built parallel infrastructure.
+as the plumbing to proxy data between the custom, possibly non-AsyncStream transport and Julia's in-built parallel infrastructure.
 
 A ``BufferStream`` is an in-memory ``IOBuffer`` which behaves like an ``AsyncStream``.
 
-Folder ``examples/clustermanager/0mq`` is an example of using ZeroMQ is connect julia workers in a star network with a 0MQ broker in the middle.
-Note: The julia processes are still all *logically* connected to each other - any worker can message any other worker directly without any
+Folder ``examples/clustermanager/0mq`` is an example of using ZeroMQ is connect Julia workers in a star network with a 0MQ broker in the middle.
+Note: The Julia processes are still all *logically* connected to each other - any worker can message any other worker directly without any
 awareness of 0MQ being used as the transport layer.
 
 When using custom transports:
 
-- julia workers must NOT be started with ``--worker``. Starting with ``--worker`` will result in the newly launched
+- Julia workers must NOT be started with ``--worker``. Starting with ``--worker`` will result in the newly launched
   workers defaulting to the TCP/IP socket transport implementation
 - For every incoming logical connection with a worker, ``Base.process_messages(rd::AsyncStream, wr::AsyncStream)`` must be called.
   This launches a new task that handles reading and writing of messages from/to the worker represented by the ``AsyncStream`` objects

doc/manual/performance-tips.rst

@@ -751,16 +751,16 @@ This might be worthwhile when the following are true:
   ``Array{Car{:Honda,:Accord},N}``.
 
 When the latter holds, a function processing such a homogenous array
-can be productively specialized: julia knows the type of each element
+can be productively specialized: Julia knows the type of each element
 in advance (all objects in the container have the same concrete type),
-so julia can "look up" the correct method calls when the function is
+so Julia can "look up" the correct method calls when the function is
 being compiled (obviating the need to check at run-time) and thereby
 emit efficient code for processing the whole list.
 
 When these do not hold, then it's likely that you'll get no benefit;
 worse, the resulting "combinatorial explosion of types" will be
 counterproductive.  If ``items[i+1]`` has a different type than
-``item[i]``, julia has to look up the type at run-time, search for the
+``item[i]``, Julia has to look up the type at run-time, search for the
 appropriate method in method tables, decide (via type intersection)
 which one matches, determine whether it has been JIT-compiled yet (and
 do so if not), and then make the call. In essence, you're asking the
@@ -773,7 +773,7 @@ lookup, and (3) a "switch" statement can be found `on the mailing list
 <https://groups.google.com/d/msg/julia-users/jUMu9A3QKQQ/qjgVWr7vAwAJ>`_.
 
 Perhaps even worse than the run-time impact is the compile-time
-impact: julia will compile specialized functions for each different
+impact: Julia will compile specialized functions for each different
 ``Car{Make, Model}``; if you have hundreds or thousands of such types,
 then every function that accepts such an object as a parameter (from a
 custom ``get_year`` function you might write yourself, to the generic

ui/repl.c

@@ -60,7 +60,7 @@ static const char opts[]  =
     " -J, --sysimage <file>     Start up with the given system image file\n"
     " --precompiled={yes|no}    Use precompiled code from system image if available\n"
     " --compilecache={yes|no}   Enable/disable incremental precompilation of modules\n"
-    " -H, --home <dir>          Set location of julia executable\n"
+    " -H, --home <dir>          Set location of `julia` executable\n"
     " --startup-file={yes|no}   Load ~/.juliarc.jl\n"
     " --handle-signals={yes|no} Enable or disable Julia's default signal handlers\n\n"