fix several typos in documentation and comments (#12553)

This commit is contained in:
Nindaleth 2019-10-30 09:08:45 +01:00 • committed by Miran
commit 34dbc5699e
29 changed files with 37 additions and 37 deletions

View file

@ -213,7 +213,7 @@ proc dealloc(r: var MemRegion; p: pointer; size: int) =
if it.typ != nil and it.typ.finalizer != nil:
(cast[Finalizer](it.typ.finalizer))(p)
it.typ = nil
# it is benefitial to not use the free lists here:
# it is beneficial to not use the free lists here:
if r.bump -! size == p:
dec r.bump, size
when false:

View file

@ -115,8 +115,8 @@ proc c_fprintf(f: File, frmt: cstring): cint {.
proc c_fputc(c: char, f: File): cint {.
importc: "fputc", header: "<stdio.h>".}
## When running nim in android app stdout goes no where, so echo gets ignored
## To redreict echo to the android logcat use -d:androidNDK
## When running nim in android app, stdout goes nowhere, so echo gets ignored
## To redirect echo to the android logcat, use -d:androidNDK
when defined(androidNDK):
const ANDROID_LOG_VERBOSE = 2.cint
proc android_log_print(prio: cint, tag: cstring, fmt: cstring): cint

View file

@ -325,7 +325,7 @@ proc setLengthSeq(seq: PGenericSeq, elemSize, newLen: int): PGenericSeq {.
# cell is aliased by another pointer (ie proc parameter or a let variable).
# This is a tough problem, because even if we don't zeroMem here, in the
# presence of user defined destructors, the user will expect the cell to be
# "destroyed" thus creating the same problem. We can destoy the cell in the
# "destroyed" thus creating the same problem. We can destroy the cell in the
# finalizer of the sequence, but this makes destruction non-deterministic.
zeroMem(cast[pointer](cast[ByteAddress](result) +% GenericSeqSize +%
(newLen*%elemSize)), (result.len-%newLen) *% elemSize)
@ -361,7 +361,7 @@ proc setLengthSeqV2(s: PGenericSeq, typ: PNimType, newLen: int): PGenericSeq {.
# cell is aliased by another pointer (ie proc parameter or a let variable).
# This is a tough problem, because even if we don't zeroMem here, in the
# presence of user defined destructors, the user will expect the cell to be
# "destroyed" thus creating the same problem. We can destoy the cell in the
# "destroyed" thus creating the same problem. We can destroy the cell in the
# finalizer of the sequence, but this makes destruction non-deterministic.
zeroMem(cast[pointer](cast[ByteAddress](result) +% GenericSeqSize +%
(newLen*%elemSize)), (result.len-%newLen) *% elemSize)