| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
| |
Seems like these class ids on the page were renamed to reflect their hierarchy but the tutorial links weren't pointing to them, this should fix that
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
* tut1.rst: Fix alignment
* tut1.rst: Change Subrange to MySubrange for clarity
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In general: s/have to/must/g - but you can't do this mechanically because sometimes the must has to go back a word (e.g., line 519).
This looks really odd to me:
if thisIsaLongCondition() and
thisIsAnotherLongCondition(1,
2, 3, 4):
x = true
I would have expected:
if thisIsaLongCondition() and
thisIsAnotherLongCondition(
1, 2, 3, 4):
x = true
If the second form is valid and good Nim style then I suggest using it rather than the original. However, if the original is the preferred style then this should be mentioned in the text since it is unusual.
Since Nim is case-sensitive I think it is bad to write wrongly cased names, e.g., ``Bool`` is a built-in type on line 589. This isn't true since Bool isn't anything, but bool is. So in these cases I'd always reword to avoid this problem (and that's what I've done -- and it also avoids "bool. Bool" which was ugly).
|
| |
|
| |
In a code example I think it best to either use full names (index, item) or abbreviated names where that's common (i, item) but not non-standard abbreviations (indx, itm). So I've changed it to index, item since it is a tutorial, although i, item would be just as good.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
* tut1: added multiline comments
* tut2: replaced expr/stmt with untyped/typed
* added some more template/macro example
* remove immediate pragma from example
|
| |
|
|
| |
Add extra For Statement stuff
Add Distinct Types
|
| |
|