| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
* fixed getTypeImpl for tyEnum
* fixed getType for enum and updated release notes about change
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| | |
Implement ConsoleOutputFormatter that is backward compatible
with the previous implementation.
Implement JUnitOutputFormatter which can be added externally.
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
* Fix kqueue.nim and ansi_c.nim to support dragonfly.
* Fix ioselectors.nim, threads.nim to support dragonfly.
* Fix deprecated dealloc call in tioselectors.nim.
* Fix tfsmonitor.nim test to run only on Linux.
* Fix osproc.nim return wrong exit codes.
* Fix getAppFilename() for dragonfly.
* Fix proper exit code handling.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
coming from templates/macros
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | |
| |
| |
| | |
Having a lexicographically sorted collection is a big benefit (I asked GvR years ago to add one to Python but it was no then and seems to be no now!).
Anyone looking for a such a collection could easily miss the critbits model because very few people have heard of them (according to Wikipedia most people in a ration of approx 750:1 know them as radix trees: https://en.wikipedia.org/wiki/Talk%3ACrit_bit_tree).
|
| | | |
|
| | |\ |
|
| | | |
| | |
| | | |
I deleted it because it came across as arrogant. It is also contentious so IMO has no place in a manual.
|
| | | | |
|
| | |/ |
|
| | | |
|
| | | |
|
| | |\ |
|
| | | | |
|
| | | |\ |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
* fix varargs forwarding for templates; fixes #5455
* document the macros' varargs change in the news for 0.16.2
|
| | | |/ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* Fix 2 problems. First, 0 is a valid fd on Unix (easily gotten if user first
closes all fds and then starts using memfiles). Use -1 instead for an invalid
fd. Second, it is best practice to conserve open fds on Unix and file handles
on Windows. These handles are not needed unless the user wants to remap the
memory with ``mapMem`` (or a hypothetical future ``proc resize``). Adding a
new bool param ``allowRemap=false`` to ``memfiles.open`` solves this cleanly
in a "mostly" backward compatible way. This is only "mostly" because the
default ``false`` case does not keep unneeded resources allocated, but that
most sensible default means that any ``mapMem`` callers need to fix all their
open calls to have allowRemap=true, as this PR also does for tmemfiles2.nim.
* Include backwards compatibility note.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This commit returns to a bit less strict checking of the number
of macro arguments, because some old immediate macros rely on a
behavior where even the arity of the macro is not being checked.
It may be better if such macros are just declared to use varargs[expr],
but this remains for another day.
|