| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
| |
fixes #22166
|
| |
|
|
|
|
|
|
|
|
|
| |
When target is nodejs,
`isAbsolute` used to only check in the POSIX flavor,
i.e. for js backend on Windows,
```nim
isAbsolute(r"C:\Windows") == false
```
This fixes it.
|
| |
|
| |
ref #23333
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For this
[proc](https://github.com/nim-lang/Nim/blob/773c066634d831a968bb464eab35b25a00026525/lib/pure/browsers.nim#L83)
`proc openDefaultBrowser*() {.since: (1, 1).}`:
though it's documented to open default browser with `about:blank` page,
it behaves differently:
- On Windows, it failed and open no window
- On Linux(Debian with Kde), it opens not default browser but
`Konqueror`
I have paid much effort to implement this variant, but even the
implementation on Windows is considerably complex.
In short, it's not only hard but unworthy to fix this.
Just as Araq
[said](https://github.com/nim-lang/Nim/issues/22250#issuecomment-1631360617),
we shall remove the `proc openDefaultBrowser*() {.since: (1, 1).}`
variant
---------
Co-authored-by: ringabout <43030857+ringabout@users.noreply.github.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This also prevents unwanted `raises: [ValueError]` effects from bubbling
up from correct format strings which makes `fmt` broadly unusable with
`raises`.
The old runtime-based `formatValue` overloads are kept for
backwards-compatibility, should anyone be using runtime format strings.
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
|
| | |
|
| |
|
|
| |
This PR removes `count` field from `Deque` and get `count` from `tail -
head`.
|
| |
|
| |
fixes #23304
|
| |
|
| |
fixes https://forum.nim-lang.org/t/10807
|
| |
|
|
|
|
|
|
|
| |
It seems Deque doesn't need `mask` field because `data.len - 1` equals
to `mask`.
Deque without `mask` field passes test `tests/stdlib/tdeques.nim`.
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
|
| |
|
|
| |
The implementation of these functions are trivial yet they were missing
from the module.
|
| | |
|
| |
|
| |
follow up #22380
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The doc for `getCurrentCompilerExe` was originally added at [this
commit](https://github.com/nim-lang/Nim/commit/c4e3c4ca2d0a1f44ed1e3dd9db564b66031f0843),
saying "`getAppFilename` at CT", and modified as "This is
`getAppFilename()`_ at compile time..." since
[this](https://github.com/nim-lang/Nim/commit/0c2c2dca2a8a3bcdb9729021d1f4734b8db9efbd#diff-8ed10106605d9e0e3f28a927432acd8312e96791c96dbb126a52a7010cf4b44a)
Which means "at compile time, get result innerly from Nim compiler via
`getAppFilename`", not "get from nim programs".
Thus, the doc was confusing, only mentioning `compile time` and
`getAppFilename`
---------
Co-authored-by: ringabout <43030857+ringabout@users.noreply.github.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This PR speeds up complex.pow when both base and exponent are real; when
only the exponent is real; and when the base is Euler's number. These
are some pretty common cases which appear in many formulas. The speed
ups are pretty significant. According to my measurements (using the
timeit library) when both base and exponent are real the speedup is ~2x;
when only the exponent is real it is ~1.5x and when the base is Euler's
number it is ~2x.
There is no measurable difference when using other exponents which makes
sense since I refactored the code a little to reduce the total number of
branches that are needed to get to the final "fallback" branch, and
those branches have less comparisons. Anecdotally the fallback case
feels slightly faster, but the improvement is so small that I cannot
claim an improvement. If it is there it is perhaps in the order of 3 or
4%.
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
|
| |
|
|
|
|
|
|
| |
(#23262)
In doc, there are 4 references for `getAppFilename`
`getAppFilename` is still in `os`, but the references refer it as if
it's in the current module `cmdline`
|
| | |
|
| |
|
|
|
| |
The documentation links for `parentDir()` and `getCurrentDir()` are
broken as they are no longer part of `std/os`. Link changed to
`std/private/ospaths2`.
|
| | |
|
| |
|
| |
https://nim-lang.github.io/Nim/manual.html#procedures-do-notation
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This PR speeds up the calculation of the power of a complex number when
the exponent is 2.0 or 0.5 (i.e the square and the square root of a
complex number). These are probably two of (if not) the most common
exponents. The speed up that is achieved according to my measurements
(using the timeit library) when the exponent is set to 2.0 or 0.5 is >
x7, while there is no measurable difference when using other exponents.
For the record, this is the function I used to mesure the performance:
```nim
import std/complex
import timeit
proc calculcatePows(v: seq[Complex], factor: Complex): seq[Complex] {.noinit, discardable.} =
result = newSeq[Complex](v.len)
for n in 0 ..< v.len:
result[n] = pow(v[n], factor)
let v: seq[Complex64] = collect:
for n in 0 ..< 1000:
complex(float(n))
echo timeGo(calculcatePows(v, complex(1.5)))
echo timeGo(calculcatePows(v, complex(0.5)))
echo timeGo(calculcatePows(v, complex(2.0)))
```
Which with the original code got:
> [177μs 857.03ns] ± [1μs 234.85ns] per loop (mean ± std. dev. of 7
runs, 1000 loops each)
> [128μs 217.92ns] ± [1μs 630.93ns] per loop (mean ± std. dev. of 7
runs, 1000 loops each)
> [136μs 220.16ns] ± [3μs 475.56ns] per loop (mean ± std. dev. of 7
runs, 1000 loops each)
While with the improved code got:
> [176μs 884.30ns] ± [1μs 307.30ns] per loop (mean ± std. dev. of 7
runs, 1000 loops each)
> [23μs 160.79ns] ± [340.18ns] per loop (mean ± std. dev. of 7 runs,
10000 loops each)
> [19μs 93.29ns] ± [1μs 128.92ns] per loop (mean ± std. dev. of 7 runs,
10000 loops each)
That is, the new optimized path is 5.6 (23 vs 128 us per loop) to 7.16
times faster (19 vs 136 us per loop), while the non-optimized path takes
the same time as the original code.
|
| |
|
|
|
|
| |
generated via https://github.com/bung87/mimetypes_gen
source data:
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/conf/mime.types?view=co
|
| |
|
|
| |
By using the existing isNaN function we can make std/math's classify
function work even if `--passc:-fast-math` is used.
|
| |
|
| |
I'm working on it, but it's quite tricky. I will fix it soon
|
| |
|
|
| |
Since pow() cannot be supported for rationals, we support negative
integer exponents instead.
|
| |
|
| |
fixes #23223
|
| |
|
| |
The problem was fixed by https://github.com/nim-lang/Nim/pull/23195
|
| |
|
| |
fixes it in the normal situation
|
| |
|
| |
fixes #22923
|
| |
|
|
|
|
|
|
|
| |
- Clarified the implications of order of operation.
- Mentioned overlapping isn't handled
- Added the runnableExamples block
Fixes #23160, which supposedly should have been fixed in an earlier PR
#23022, but the wording was still not clear enough to my liking, which
the raised issue kind of confirms.
|
| |
|
| |
fixes #23139
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
why ?
- We already have an emit that does the same thing
- The name asm itself is a bit confusing, you might think it's an alias
for asm.js or something else.
- The asm keyword is used differently on different compiler targets (it
makes it inexpressive).
- Does anyone (other than some compiler libraries) use asm instead of
emit ? If yes, it's a bit strange to use asm somewhere and emit
somewhere. By making the asm keyword for js target deprecated, there
would be even less use of the asm keyword for js target, reducing the
amount of confusion.
- New users might accidentally use a non-universal approach via the asm
keyword instead of emit, and then when they learn about asm, try to
figure out what the differences are.
see https://forum.nim-lang.org/t/10821
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
|
| |
|
| |
4 spaces => 2 spaces
|
| |
|
| |
wether -> whether
|
| |
|
|
|
|
|
| |
Fixes an issue where importing the `strutils` module, or any other
importing the `strutils` module, ends up with a compile time error on
platforms where ints are less then 32-bit wide.
The fix follows the suggestions made in #23125.
|
| |
|
|
|
| |
I have made `realloc` absorb unused adjacent memory, which improves the
performance. I'm investigating whether `deallocOsPages` can be used to
improve memory comsumption.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rendering of `nkRecList` produces an indent and adds a new line at the
end. However for things like case object `of`/`else` branches or `when`
branches this is already done, so this produces 2 indents and an extra
new line. Instead, just add an indent in the place where the indent that
`nkRecList` produces is needed, for the rendering of the final node of
`nkObjectTy`. There doesn't seem to be a need to add the newline.
Before:
```nim
case x*: bool
of true:
y*: int
of false:
nil
```
After:
```nim
case x*: bool
of true:
y*: int
of false:
nil
```
|
| |
|
|
| |
Allow for conversion from `openArray`s, similar to `toSinglyLinkedList`
and `toDoublyLinkedList`.
|
| |
|
| |
alternative to https://github.com/nim-lang/Nim/pull/23092
|
| | |
|
| |
|
|
|
| |
(#23087)
Show name of error that wasn't expected in an `expect` block
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Closes #14329
Marks `macros.error` as `.noreturn` so that it can be used in
expressions. This also fixes the issue that occurred in #19659 where a
stmt that could be an expression (Due to having `discardable` procs at
the end of other branches) would believe a `noreturn` proc is returning
the same type e.g.
```nim
proc bar(): int {.discardable.} = discard
if true: bar()
else: quit(0) # Says that quit is of type `int` and needs to be used/discarded except it actually has no return type
```
|
| | |
|
| |
|
|
|
|
|
|
| |
fixes #22227
rationale:
- `3u - 4u` is supported why not`3u.toRational - 4u.toRational`
- all of rationals' api is on SomeInteger, looks like unsigned is
declared as supported
- math on unsigned rationals is meaningful and useful.
|
| |
|
|
|
|
|
|
|
|
|
| |
#23032
---------
Co-authored-by: Nikolay Nikolov <nickysn@gmail.com>
Co-authored-by: Pylgos <43234674+Pylgos@users.noreply.github.com>
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
Co-authored-by: ringabout <43030857+ringabout@users.noreply.github.com>
Co-authored-by: Jason Beetham <beefers331@gmail.com>
|
| |
|
| |
fixes #23060
|
| |
|
| |
Closes #13341
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the docs for strutils.multiReplace:
Making it more explicit that left to right comes before the order in the
replacements arg (but that the latter matters too).
E.g.
```
echo "ab".multiReplace(@[("a", "1"), ("ax", "2")])
echo "ab".multiReplace(@[("ab", "2"), ("a", "1")])
```
gives
```
1b
2
```
resolves #23016
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
routine declaration (#23015)
I'm not sure if this is a complete fix, as it does not match the
expected output given in the issue. The expected output given in the
issue highlights the identifier after the `'` the same color as numeric
literals (blue), and this change does not address that. I think that
would involve simplifying `nimNumberPostfix`.
However, this fixes the issue where the routine declaration was rendered
as a string.
New rendering:
|
| | |
|