commit
a5f8f538a2
111 changed files with 237 additions and 237 deletions
|
|
@ -18,7 +18,7 @@ Advanced commands:
|
|||
track a file, currently not saved to disk
|
||||
--suggest suggest all possible symbols at position
|
||||
--def list all possible definitions at position
|
||||
--context list possible invokation context
|
||||
--context list possible invocation context
|
||||
--usages list all usages of the symbol at position
|
||||
--eval evaluates an expression
|
||||
//serve start the compiler as a service mode (CAAS)
|
||||
|
|
|
|||
|
|
@ -225,7 +225,7 @@ The JavaScript target doesn't have any further interfacing considerations
|
|||
since it also has garbage collection, but the C targets require you to
|
||||
initialize Nim's internals, which is done calling a ``NimMain`` function.
|
||||
Also, C code requires you to specify a forward declaration for functions or
|
||||
the compiler will asume certain types for the return value and parameters
|
||||
the compiler will assume certain types for the return value and parameters
|
||||
which will likely make your program crash at runtime.
|
||||
|
||||
The Nim compiler can generate a C interface header through the ``--header``
|
||||
|
|
@ -427,7 +427,7 @@ Custom data types
|
|||
-----------------
|
||||
|
||||
Just like strings, custom data types that are to be shared between Nim and
|
||||
the backend will need careful consideration of who controlls who. If you want
|
||||
the backend will need careful consideration of who controls who. If you want
|
||||
to hand a Nim reference to C code, you will need to use `GC_ref
|
||||
<system.html#GC_ref>`_ to mark the reference as used, so it does not get
|
||||
freed. And for the C backend you will need to expose the `GC_unref
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ integrations <https://github.com/Araq/Nim/wiki/Editor-Support>`_
|
|||
already available.
|
||||
|
||||
|
||||
Idetools invokation
|
||||
Idetools invocation
|
||||
===================
|
||||
|
||||
Specifying the location of the query
|
||||
|
|
@ -35,7 +35,7 @@ Specifying the location of the query
|
|||
|
||||
All of the available idetools commands require you to specify a
|
||||
query location through the ``--track`` or ``--trackDirty`` switches.
|
||||
The general idetools invokations are::
|
||||
The general idetools invocations are::
|
||||
|
||||
nim idetools --track:FILE,LINE,COL <switches> proj.nim
|
||||
|
||||
|
|
@ -129,7 +129,7 @@ the suggestions sorted first by scope (from innermost to outermost)
|
|||
and then by item name.
|
||||
|
||||
|
||||
Invokation context
|
||||
Invocation context
|
||||
------------------
|
||||
|
||||
The ``--context`` idetools switch is very similar to the suggestions
|
||||
|
|
@ -163,7 +163,7 @@ running/debugged user project.
|
|||
Compiler as a service (CAAS)
|
||||
============================
|
||||
|
||||
The ocasional use of idetools is acceptable for things like
|
||||
The occasional use of idetools is acceptable for things like
|
||||
definitions, where the user puts the cursor on a symbol or double
|
||||
clicks it and after a second or two the IDE displays where that
|
||||
symbol is defined. Such latencies would be terrible for features
|
||||
|
|
@ -533,10 +533,10 @@ run it manually. First you have to compile the tester::
|
|||
Running the ``caasdriver`` without parameters will attempt to process
|
||||
all the test cases in all three operation modes. If a test succeeds
|
||||
nothing will be printed and the process will exit with zero. If any
|
||||
test fails, the specific line of the test preceeding the failure
|
||||
test fails, the specific line of the test preceding the failure
|
||||
and the failure itself will be dumped to stdout, along with a final
|
||||
indicator of the success state and operation mode. You can pass the
|
||||
parameter ``verbose`` to force all output even on successfull tests.
|
||||
parameter ``verbose`` to force all output even on successful tests.
|
||||
|
||||
The normal operation mode is called ``ProcRun`` and it involves
|
||||
starting a process for each command or query, similar to running
|
||||
|
|
|
|||
|
|
@ -236,7 +236,7 @@ too. Type converters fall into this category:
|
|||
|
||||
If in the above example module ``B`` is re-compiled, but ``A`` is not then
|
||||
``B`` needs to be aware of ``toBool`` even though ``toBool`` is not referenced
|
||||
in ``B`` *explicitely*.
|
||||
in ``B`` *explicitly*.
|
||||
|
||||
Both the multi method and the type converter problems are solved by storing
|
||||
them in special sections in the ROD file that are loaded *unconditionally*
|
||||
|
|
@ -370,7 +370,7 @@ needed as the data structures needs to be rebuilt periodically anyway.
|
|||
|
||||
Complete traversal is done in this way::
|
||||
|
||||
for each page decriptor d:
|
||||
for each page descriptor d:
|
||||
for each bit in d:
|
||||
if bit == 1:
|
||||
traverse the pointer belonging to this bit
|
||||
|
|
@ -406,7 +406,7 @@ The generated code looks roughly like this:
|
|||
setRef(&r->left)
|
||||
}
|
||||
|
||||
Note that for systems with a continous stack (which most systems have)
|
||||
Note that for systems with a continuous stack (which most systems have)
|
||||
the check whether the ref is on the stack is very cheap (only two
|
||||
comparisons).
|
||||
|
||||
|
|
|
|||
|
|
@ -370,7 +370,7 @@ Miscellaneous
|
|||
-------------
|
||||
|
||||
* `events <events.html>`_
|
||||
This module implements an event system that is not dependant on external
|
||||
This module implements an event system that is not dependent on external
|
||||
graphical toolkits.
|
||||
|
||||
* `oids <oids.html>`_
|
||||
|
|
|
|||
|
|
@ -25,9 +25,9 @@ with ``'``. An example::
|
|||
|
||||
ifStmt = 'if' expr ':' stmts ('elif' expr ':' stmts)* ('else' stmts)?
|
||||
|
||||
The binary ``^*`` operator is used as a shorthand for 0 or more occurances
|
||||
The binary ``^*`` operator is used as a shorthand for 0 or more occurrences
|
||||
separated by its second argument; likewise ``^+`` means 1 or more
|
||||
occurances: ``a ^+ b`` is short for ``a (b a)*``
|
||||
occurrences: ``a ^+ b`` is short for ``a (b a)*``
|
||||
and ``a ^* b`` is short for ``(a (b a)*)?``. Example::
|
||||
|
||||
arrayConstructor = '[' expr ^* ',' ']'
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ Precedence level Operators First charact
|
|||
Strong spaces
|
||||
-------------
|
||||
|
||||
The number of spaces preceeding a non-keyword operator affects precedence
|
||||
The number of spaces preceding a non-keyword operator affects precedence
|
||||
if the experimental parser directive ``#!strongSpaces`` is used. Indentation
|
||||
is not used to determine the number of spaces. If 2 or more operators have the
|
||||
same number of preceding spaces the precedence table applies, so ``1 + 3 * 4``
|
||||
|
|
|
|||
|
|
@ -1142,7 +1142,7 @@ modules like `db_sqlite <db_sqlite.html>`_.
|
|||
Void type
|
||||
---------
|
||||
|
||||
The ``void`` type denotes the absense of any type. Parameters of
|
||||
The ``void`` type denotes the absence of any type. Parameters of
|
||||
type ``void`` are treated as non-existent, ``void`` as a return type means that
|
||||
the procedure does not return a value:
|
||||
|
||||
|
|
|
|||
|
|
@ -134,7 +134,7 @@ found an ambiguity error is produced.
|
|||
``nim dump`` shows the contents of the PATH.
|
||||
|
||||
However before the PATH is used the current directory is checked for the
|
||||
file's existance. So if PATH contains ``$lib`` and ``$lib/bar`` and the
|
||||
file's existence. So if PATH contains ``$lib`` and ``$lib/bar`` and the
|
||||
directory structure looks like this::
|
||||
|
||||
$lib/x.nim
|
||||
|
|
|
|||
|
|
@ -25,9 +25,9 @@ Compile nimgrep with the command::
|
|||
And copy the executable somewhere in your ``$PATH``.
|
||||
|
||||
|
||||
Command line switches
|
||||
=====================
|
||||
|
||||
Command line switches
|
||||
=====================
|
||||
|
||||
Usage:
|
||||
nimgrep [options] [pattern] [replacement] (file/directory)*
|
||||
Options:
|
||||
|
|
@ -37,7 +37,7 @@ Options:
|
|||
--re pattern is a regular expression (default); extended
|
||||
syntax for the regular expression is always turned on
|
||||
--recursive process directories recursively
|
||||
--confirm confirm each occurence/replacement; there is a chance
|
||||
--confirm confirm each occurrence/replacement; there is a chance
|
||||
to abort any time without touching the file
|
||||
--stdin read pattern from stdin (to avoid the shell's confusing
|
||||
quoting rules)
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ Object Oriented Programming
|
|||
While Nim's support for object oriented programming (OOP) is minimalistic,
|
||||
powerful OOP techniques can be used. OOP is seen as *one* way to design a
|
||||
program, not *the only* way. Often a procedural approach leads to simpler
|
||||
and more efficient code. In particular, prefering composition over inheritance
|
||||
and more efficient code. In particular, preferring composition over inheritance
|
||||
is often the better design.
|
||||
|
||||
|
||||
|
|
@ -142,7 +142,7 @@ An example:
|
|||
|
||||
.. code-block:: nim
|
||||
|
||||
# This is an example how an abstract syntax tree could be modeled in Nim
|
||||
# This is an example how an abstract syntax tree could be modelled in Nim
|
||||
type
|
||||
NodeKind = enum # the different node types
|
||||
nkInt, # a leaf with an integer value
|
||||
|
|
@ -335,7 +335,7 @@ As the example demonstrates, invocation of a multi-method cannot be ambiguous:
|
|||
Collide 2 is preferred over collide 1 because the resolution works from left to
|
||||
right. Thus ``Unit, Thing`` is preferred over ``Thing, Unit``.
|
||||
|
||||
**Perfomance note**: Nim does not produce a virtual method table, but
|
||||
**Performance note**: Nim does not produce a virtual method table, but
|
||||
generates dispatch trees. This avoids the expensive indirect branch for method
|
||||
calls and enables inlining. However, other optimizations like compile time
|
||||
evaluation or dead code elimination do not work with methods.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue