fixes#16771
follow up https://github.com/nim-lang/Nim/pull/16536
Ideally it should be handled in the IR part in the future
I have also checked the double evaluation of `swap` in the JS runtime
https://github.com/nim-lang/Nim/issues/16779, that might be solved by a
copy flag or something. Well, it should be best solved in the IR so that
it doesn't bother backends anymore.
## Reprodution
if on Windows:
```Nim
when defined(windows):
var file: File
let succ = file.open(<aFileHandle>)
```
then `succ` will be false.
If tested, it can be found to fail with errno `22` and message: `Invalid
argument`
## Problem
After some investigations and tests,
I found it's due to the `mode` argument for `fdopen`.
Currently `NoInheritFlag`(`'N'` in Windows) is added to `mode` arg
passed to `_fdopen`, but if referring to
[Windows `_fdopen`
doc](https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/fdopen-wfdopen?view=msvc-170),
you'll find there is no `'N'` describled. That's `'N'` is not accepted
by `_fdopen`.
Therefore, the demo above will fail.
## In Addition
To begin with, technologically speaking, when opening with a
`fileHandle`(or called `fd`), there is no concept of fd-inheritable as
`fd` is opened already.
In POSIX, `NoInheritFlag` is defined as `e`.
It's pointed out in [POSIX `open`
man-doc](https://www.man7.org/linux/man-pages/man3/fopen.3.html) that
`e` in mode is ignored for fdopen(),
which means `e` for `fdopen()` is not wanted, just allowed.
Therefore, better to also not pass `e` to `fdopen`
---
In all, that's this PR.
Fixes an issue that comes up when using strutils.`%` or any other
strutils/strformat feature that uses the unicode lookup tables behind
the scenes, on systems where ints are than 32-bit wide.
Tested with:
```bash
./koch test cat lib
```
Refer to the discussion in #23125.
The fix to the atomicArc looks to use `-1` as the check value from the
`SharedPtr` solution. However, it should be `-rcIncrement` since the
refcount is bit shifted in ARC/ORC.
I discovered this playing around doing atomic updates of refcounts in a
user library.
Related to https://github.com/nim-lang/Nim/issues/22711
@ringabout I believe you ported the sharedptr fix?
fix#23381
As for the read function, the original plan was to use lent for
annotation, but after my experiments, it still produced copies, so I had
to move it out.
Now the `read` function cannot be called repeatedly
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.
For this
[proc](773c066634/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>
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 doc for `getCurrentCompilerExe` was originally added at [this
commit](c4e3c4ca2d),
saying "`getAppFilename` at CT", and modified as "This is
`getAppFilename()`_ at compile time..." since
[this](0c2c2dca2a (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>
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`.
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.
- 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.
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>
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
```
