jyapayne/Nim
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

the big renamefest: first steps

Browse source
This commit is contained in:
Araq 2014-08-22 23:54:26 +02:00
commit dbf9117c56
56 changed files with 529 additions and 508 deletions
Download patch file Download diff file Expand all files Collapse all files

192
doc/nimrodc.txt
View file

@ -1,9 +1,9 @@
===================================
Nimrod Compiler User Guide
Nim Compiler User Guide
===================================
:Author: Andreas Rumpf
:Version: |nimrodversion|
:Version: |nimversion|
.. contents::
@ -15,11 +15,11 @@
Introduction
============
This document describes the usage of the *Nimrod compiler*
on the different supported platforms. It is not a definition of the Nimrod
This document describes the usage of the *Nim compiler*
on the different supported platforms. It is not a definition of the Nim
programming language (therefore is the `manual <manual.html>`_).
Nimrod is free software; it is licensed under the
Nim is free software; it is licensed under the
`MIT License <http://www.opensource.org/licenses/mit-license.php>`_.
@ -107,14 +107,14 @@ Configuration files
passed as a command line argument to the compiler.
The ``nimrod`` executable processes configuration files in the following
The ``nim`` executable processes configuration files in the following
directories (in this order; later files overwrite previous settings):
1) ``$nimrod/config/nimrod.cfg``, ``/etc/nimrod.cfg`` (UNIX) or ``%NIMROD%/config/nimrod.cfg`` (Windows). This file can be skipped with the ``--skipCfg`` command line option.
2) ``/home/$user/.config/nimrod.cfg`` (UNIX) or ``%APPDATA%/nimrod.cfg`` (Windows). This file can be skipped with the ``--skipUserCfg`` command line option.
3) ``$parentDir/nimrod.cfg`` where ``$parentDir`` stands for any parent directory of the project file's path. These files can be skipped with the ``--skipParentCfg`` command line option.
4) ``$projectDir/nimrod.cfg`` where ``$projectDir`` stands for the project file's path. This file can be skipped with the ``--skipProjCfg`` command line option.
5) A project can also have a project specific configuration file named ``$project.nimrod.cfg`` that resides in the same directory as ``$project.nim``. This file can be skipped with the ``--skipProjCfg`` command line option.
1) ``$nim/config/nim.cfg``, ``/etc/nim.cfg`` (UNIX) or ``%NIMROD%/config/nim.cfg`` (Windows). This file can be skipped with the ``--skipCfg`` command line option.
2) ``/home/$user/.config/nim.cfg`` (UNIX) or ``%APPDATA%/nim.cfg`` (Windows). This file can be skipped with the ``--skipUserCfg`` command line option.
3) ``$parentDir/nim.cfg`` where ``$parentDir`` stands for any parent directory of the project file's path. These files can be skipped with the ``--skipParentCfg`` command line option.
4) ``$projectDir/nim.cfg`` where ``$projectDir`` stands for the project file's path. This file can be skipped with the ``--skipProjCfg`` command line option.
5) A project can also have a project specific configuration file named ``$project.nim.cfg`` that resides in the same directory as ``$project.nim``. This file can be skipped with the ``--skipProjCfg`` command line option.
Command line settings have priority over configuration file settings.
@ -122,17 +122,17 @@ Command line settings have priority over configuration file settings.
The default build of a project is a `debug build`:idx:. To compile a
`release build`:idx: define the ``release`` symbol::
nimrod c -d:release myproject.nim
nim c -d:release myproject.nim
Search path handling
--------------------
Nimrod has the concept of a global search path (PATH) that is queried to
Nim has the concept of a global search path (PATH) that is queried to
determine where to find imported modules or include files. If multiple files are
found an ambiguity error is produced.
``nimrod dump`` shows the contents of the PATH.
``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
@ -152,10 +152,10 @@ the first matching file is used.
Generated C code directory
--------------------------
The generated files that Nimrod produces all go into a subdirectory called
The generated files that Nim produces all go into a subdirectory called
``nimcache`` in your project directory. This makes it easy to delete all
generated files. Files generated in this directory follow a naming logic which
you can read about in the `Nimrod Backend Integration document
you can read about in the `Nim Backend Integration document
<backends.html#nimcache-naming-logic>`_.
However, the generated C code is not platform independent. C code generated for
@ -190,14 +190,14 @@ Cross compilation
To cross compile, use for example::
nimrod c --cpu:i386 --os:linux --compile_only --gen_script myproject.nim
nim c --cpu:i386 --os:linux --compile_only --gen_script myproject.nim
Then move the C code and the compile script ``compile_myproject.sh`` to your
Linux i386 machine and run the script.
Another way is to make Nimrod invoke a cross compiler toolchain::
Another way is to make Nim invoke a cross compiler toolchain::
nimrod c --cpu:arm --os:linux myproject.nim
nim c --cpu:arm --os:linux myproject.nim
For cross compilation, the compiler invokes a C compiler named
like ``$cpu.$os.$cc`` (for example arm.linux.gcc) and the configuration
@ -212,16 +212,16 @@ configuration file should contain something like::
DLL generation
==============
Nimrod supports the generation of DLLs. However, there must be only one
Nim supports the generation of DLLs. However, there must be only one
instance of the GC per process/address space. This instance is contained in
``nimrtl.dll``. This means that every generated Nimrod DLL depends
``nimrtl.dll``. This means that every generated Nim DLL depends
on ``nimrtl.dll``. To generate the "nimrtl.dll" file, use the command::
nimrod c -d:release lib/nimrtl.nim
nim c -d:release lib/nimrtl.nim
To link against ``nimrtl.dll`` use the command::
nimrod c -d:useNimRtl myprog.nim
nim c -d:useNimRtl myprog.nim
**Note**: Currently the creation of ``nimrtl.dll`` with thread support has
never been tested and is unlikely to work!
@ -243,9 +243,9 @@ Define Effect
version.
``useFork`` Makes ``osproc`` use ``fork`` instead of ``posix_spawn``.
``useNimRtl`` Compile and link against ``nimrtl.dll``.
``useMalloc`` Makes Nimrod use C's `malloc`:idx: instead of Nimrod's
``useMalloc`` Makes Nim use C's `malloc`:idx: instead of Nim's
own memory manager. This only works with ``gc:none``.
``useRealtimeGC`` Enables support of Nimrod's GC for *soft* realtime
``useRealtimeGC`` Enables support of Nim's GC for *soft* realtime
systems. See the documentation of the `gc <gc.html>`_
for further information.
``nodejs`` The JS target is actually ``node.js``.
@ -258,8 +258,8 @@ Define Effect
Additional Features
===================
This section describes Nimrod's additional features that are not listed in the
Nimrod manual. Some of the features here only make sense for the C code
This section describes Nim's additional features that are not listed in the
Nim manual. Some of the features here only make sense for the C code
generator and are subject to change.
@ -267,13 +267,13 @@ NoDecl pragma
-------------
The ``noDecl`` pragma can be applied to almost any symbol (variable, proc,
type, etc.) and is sometimes useful for interoperability with C:
It tells Nimrod that it should not generate a declaration for the symbol in
It tells Nim that it should not generate a declaration for the symbol in
the C code. For example:
.. code-block:: Nimrod
.. code-block:: Nim
var
EACCES {.importc, noDecl.}: cint # pretend EACCES was a variable, as
# Nimrod does not know its value
# Nim does not know its value
However, the ``header`` pragma is often the better alternative.
@ -286,14 +286,14 @@ The ``header`` pragma is very similar to the ``noDecl`` pragma: It can be
applied to almost any symbol and specifies that it should not be declared
and instead the generated code should contain an ``#include``:
.. code-block:: Nimrod
.. code-block:: Nim
type
PFile {.importc: "FILE*", header: "<stdio.h>".} = distinct pointer
# import C's FILE* type; Nimrod will treat it as a new pointer type
# import C's FILE* type; Nim will treat it as a new pointer type
The ``header`` pragma always expects a string constant. The string contant
contains the header file: As usual for C, a system header file is enclosed
in angle brackets: ``<>``. If no angle brackets are given, Nimrod
in angle brackets: ``<>``. If no angle brackets are given, Nim
encloses the header file in ``""`` in the generated C code.
**Note**: This will not work for the LLVM backend.
@ -304,7 +304,7 @@ IncompleteStruct pragma
The ``incompleteStruct`` pragma tells the compiler to not use the
underlying C ``struct`` in a ``sizeof`` expression:
.. code-block:: Nimrod
.. code-block:: Nim
type
TDIR* {.importc: "DIR", header: "<dirent.h>",
final, pure, incompleteStruct.} = object
@ -315,10 +315,10 @@ Compile pragma
The ``compile`` pragma can be used to compile and link a C/C++ source file
with the project:
.. code-block:: Nimrod
.. code-block:: Nim
{.compile: "myfile.cpp".}
**Note**: Nimrod computes a CRC checksum and only recompiles the file if it
**Note**: Nim computes a CRC checksum and only recompiles the file if it
has changed. You can use the ``-f`` command line option to force recompilation
of the file.
@ -327,7 +327,7 @@ Link pragma
-----------
The ``link`` pragma can be used to link an additional file with the project:
.. code-block:: Nimrod
.. code-block:: Nim
{.link: "myfile.o".}
@ -336,13 +336,13 @@ PassC pragma
The ``passC`` pragma can be used to pass additional parameters to the C
compiler like you would using the commandline switch ``--passC``:
.. code-block:: Nimrod
.. code-block:: Nim
{.passC: "-Wall -Werror".}
Note that you can use ``gorge`` from the `system module <system.html>`_ to
embed parameters from an external command at compile time:
.. code-block:: Nimrod
.. code-block:: Nim
{.passC: gorge("pkg-config --cflags sdl").}
PassL pragma
@ -350,13 +350,13 @@ PassL pragma
The ``passL`` pragma can be used to pass additional parameters to the linker
like you would using the commandline switch ``--passL``:
.. code-block:: Nimrod
.. code-block:: Nim
{.passL: "-lSDLmain -lSDL".}
Note that you can use ``gorge`` from the `system module <system.html>`_ to
embed parameters from an external command at compile time:
.. code-block:: Nimrod
.. code-block:: Nim
{.passL: gorge("pkg-config --libs sdl").}
@ -369,16 +369,16 @@ extremely useful for interfacing with `C++`:idx: or `Objective C`:idx: code.
Example:
.. code-block:: Nimrod
.. code-block:: Nim
{.emit: """
static int cvariable = 420;
""".}
{.push stackTrace:off.}
proc embedsC() =
var nimrodVar = 89
# use backticks to access Nimrod symbols within an emit section:
{.emit: """fprintf(stdout, "%d\n", cvariable + (int)`nimrodVar`);""".}
var nimVar = 89
# use backticks to access Nim symbols within an emit section:
{.emit: """fprintf(stdout, "%d\n", cvariable + (int)`nimVar`);""".}
{.pop.}
embedsC()
@ -392,7 +392,7 @@ code then uses the C++ method calling syntax: ``obj->method(arg)``. In
addition with the ``header`` and ``emit`` pragmas this allows *sloppy*
interfacing with libraries written in C++:
.. code-block:: Nimrod
.. code-block:: Nim
# Horrible example of how to interface with a C++ engine ... ;-)
{.link: "/usr/lib/libIrrlicht.so".}
@ -431,7 +431,7 @@ generated code then uses the Objective C method calling syntax: ``[obj method
param1: arg]``. In addition with the ``header`` and ``emit`` pragmas this
allows *sloppy* interfacing with libraries written in Objective C:
.. code-block:: Nimrod
.. code-block:: Nim
# horrible example of how to interface with GNUStep ...
{.passL: "-lobjc".}
@ -475,11 +475,11 @@ emits Objective C code.
CodegenDecl pragma
------------------
The ``codegenDecl`` pragma can be used to directly influence Nimrod's code
The ``codegenDecl`` pragma can be used to directly influence Nim's code
generator. It receives a format string that determines how the variable or
proc is declared in the generated code:
.. code-block:: nimrod
.. code-block:: nim
var
a {.codegenDecl: "$# progmem $#".}: int
@ -494,7 +494,7 @@ The ``injectStmt`` pragma can be used to inject a statement before every
other statement in the current module. It is only supposed to be used for
debugging:
.. code-block:: nimrod
.. code-block:: nim
{.injectStmt: gcInvariants().}
# ... complex code here that produces crashes ...
@ -523,7 +523,7 @@ is raised.
Debugger option
---------------
The ``debugger`` option enables or disables the *Embedded Nimrod Debugger*.
The ``debugger`` option enables or disables the *Embedded Nim Debugger*.
See the documentation of endb_ for further information.
@ -545,11 +545,11 @@ in C/C++).
Source code style
=================
Nimrod allows you to `mix freely case and underscores as identifier separators
Nim allows you to `mix freely case and underscores as identifier separators
<manual.html#identifiers-keywords>`_, so variables named ``MyPrecioussInt`` and
``my_preciouss_int`` are equivalent:
.. code-block:: Nimrod
.. code-block:: Nim
var MyPrecioussInt = 3
# Following line compiles fine!
echo my_preciouss_int
@ -557,16 +557,16 @@ Nimrod allows you to `mix freely case and underscores as identifier separators
Since this can lead to many variants of the same source code (you can use
`nimgrep <nimgrep.html>`_ instead of your typical ``grep`` to ignore style
problems) the compiler provides the command ``pretty`` to help unifying the
style of source code. Running ``nimrod pretty ugly_test.nim`` with this
style of source code. Running ``nim pretty ugly_test.nim`` with this
example will generate a secondary file named ``ugly_test.pretty.nim`` with the
following content:
.. code-block:: Nimrod
.. code-block:: Nim
var MyPrecioussInt = 3
# Following line compiles fine!
echo MyPrecioussInt
During execution the ``pretty`` command will also run on Nimrod's standard
During execution the ``pretty`` command will also run on Nim's standard
library, since it doesn't differentiate the standard library as something
special, and hence will warn of many *errors* which are out of your hand to
fix, creating respective ``.pretty.nim`` files all the way. You can ignore
@ -583,11 +583,11 @@ important changes for you to review. In this case the command is warning that a
variable name should not start with a capital letter, which is usually reserved
to `object types <tut2.html#objects>`_. To learn about the accepted `camel case
style <https://en.wikipedia.org/wiki/Camelcase>`_ read `Coding Guidelines in
the Internals of Nimrod Compiler <intern.html#coding-guidelines>`_ or `Coding
Guidelines <https://github.com/Araq/Nimrod/wiki/Coding-Guidelines>`_ and `NEP 1
: Style Guide for Nimrod Code
<https://github.com/Araq/Nimrod/wiki/NEP-1-:-Style-Guide-for-Nimrod-Code>`_
from the Nimrod `GitHub wiki<https://github.com/Araq/Nimrod/wiki>`_.
the Internals of Nim Compiler <intern.html#coding-guidelines>`_ or `Coding
Guidelines <https://github.com/Araq/Nim/wiki/Coding-Guidelines>`_ and `NEP 1
: Style Guide for Nim Code
<https://github.com/Araq/Nim/wiki/NEP-1-:-Style-Guide-for-Nim-Code>`_
from the Nim `GitHub wiki<https://github.com/Araq/Nim/wiki>`_.
This command is safe to run because it will never attempt to overwrite your
existing sources, but the respective ``.pretty.nim`` files **will** be
@ -597,14 +597,14 @@ overwritten without notice.
DynlibOverride
==============
By default Nimrod's ``dynlib`` pragma causes the compiler to generate
By default Nim's ``dynlib`` pragma causes the compiler to generate
``GetProcAddress`` (or their Unix counterparts)
calls to bind to a DLL. With the ``dynlibOverride`` command line switch this
can be prevented and then via ``--passL`` the static library can be linked
against. For instance, to link statically against Lua this command might work
on Linux::
nimrod c --dynlibOverride:lua --passL:liblua.lib program.nim
nim c --dynlibOverride:lua --passL:liblua.lib program.nim
Backend language options
@ -614,32 +614,32 @@ The typical compiler usage involves using the ``compile`` or ``c`` command to
transform a ``.nim`` file into one or more ``.c`` files which are then
compiled with the platform's C compiler into a static binary. However there
are other commands to compile to C++, Objective-C or Javascript. More details
can be read in the `Nimrod Backend Integration document <backends.html>`_.
can be read in the `Nim Backend Integration document <backends.html>`_.
Nimrod documentation tools
==========================
Nim documentation tools
=======================
Nimrod provides the `doc`:idx: and `doc2`:idx: commands to generate HTML
Nim provides the `doc`:idx: and `doc2`:idx: commands to generate HTML
documentation from ``.nim`` source files. Only exported symbols will appear in
the output. For more details `see the docgen documentation <docgen.html>`_.
Nimrod idetools integration
===========================
Nim idetools integration
========================
Nimrod provides language integration with external IDEs through the
Nim provides language integration with external IDEs through the
idetools command. See the documentation of `idetools <idetools.html>`_
for further information.
Nimrod interactive mode
=======================
Nim interactive mode
====================
The Nimrod compiler supports an interactive mode. This is also known as
a `REPL`:idx: (*read eval print loop*). If Nimrod has been built with the
The Nim compiler supports an interactive mode. This is also known as
a `REPL`:idx: (*read eval print loop*). If Nim has been built with the
``-d:useGnuReadline`` switch, it uses the GNU readline library for terminal
input management. To start Nimrod in interactive mode use the command
``nimrod i``. To quit use the ``quit()`` command. To determine whether an input
input management. To start Nim in interactive mode use the command
``nim i``. To quit use the ``quit()`` command. To determine whether an input
line is an incomplete statement to be continued these rules are used:
1. The line ends with ``[-+*/\\<>!\?\|%&$@~,;:=#^]\s*$`` (operator symbol followed by optional whitespace).
@ -648,8 +648,8 @@ line is an incomplete statement to be continued these rules are used:
does not work if the line contains more than one ``"""``.
Nimrod for embedded systems
===========================
Nim for embedded systems
========================
The standard library can be avoided to a point where C code generation
for 16bit micro controllers is feasible. Use the `standalone`:idx: target
@ -661,7 +661,7 @@ target.
For example, to generate code for an `AVR`:idx: processor use this command::
nimrod c --cpu:avr --os:standalone --deadCodeElim:on --genScript x.nim
nim c --cpu:avr --os:standalone --deadCodeElim:on --genScript x.nim
For the ``standalone`` target you need to provide
a file ``panicoverride.nim``.
@ -669,27 +669,27 @@ See ``tests/manyloc/standalone/panicoverride.nim`` for an example
implementation.
Nimrod for realtime systems
===========================
Nim for realtime systems
========================
See the documentation of Nimrod's soft realtime `GC <gc.html>`_ for further
See the documentation of Nim's soft realtime `GC <gc.html>`_ for further
information.
Debugging with Nimrod
=====================
Debugging with Nim
==================
Nimrod comes with its own *Embedded Nimrod Debugger*. See
Nim comes with its own *Embedded Nim Debugger*. See
the documentation of endb_ for further information.
Optimizing for Nimrod
=====================
Optimizing for Nim
==================
Nimrod has no separate optimizer, but the C code that is produced is very
Nim has no separate optimizer, but the C code that is produced is very
efficient. Most C compilers have excellent optimizers, so usually it is
not needed to optimize one's code. Nimrod has been designed to encourage
efficient code: The most readable code in Nimrod is often the most efficient
not needed to optimize one's code. Nim has been designed to encourage
efficient code: The most readable code in Nim is often the most efficient
too.
However, sometimes one has to optimize. Do it in the following order:
@ -706,32 +706,32 @@ This section can only help you with the last item.
Optimizing string handling
--------------------------
String assignments are sometimes expensive in Nimrod: They are required to
String assignments are sometimes expensive in Nim: They are required to
copy the whole string. However, the compiler is often smart enough to not copy
strings. Due to the argument passing semantics, strings are never copied when
passed to subroutines. The compiler does not copy strings that are a result from
a procedure call, because the callee returns a new string anyway.
Thus it is efficient to do:
.. code-block:: Nimrod
.. code-block:: Nim
var s = procA() # assignment will not copy the string; procA allocates a new
# string already
However it is not efficient to do:
.. code-block:: Nimrod
.. code-block:: Nim
var s = varA # assignment has to copy the whole string into a new buffer!
For ``let`` symbols a copy is not always necessary:
.. code-block:: Nimrod
.. code-block:: Nim
let s = varA # may only copy a pointer if it safe to do so
If you know what you're doing, you can also mark single string (or sequence)
objects as `shallow`:idx:\:
.. code-block:: Nimrod
.. code-block:: Nim
var s = "abc"
shallow(s) # mark 's' as shallow string
var x = s # now might not copy the string!
@ -744,7 +744,7 @@ The compiler optimizes string case statements: A hashing scheme is used for them
if several different string constants are used. So code like this is reasonably
efficient:
.. code-block:: Nimrod
.. code-block:: Nim
case normalize(k.key)
of "name": c.name = v
of "displayname": c.displayName = v