The most specific version of `gcd(int,int)` in `std/math` uses bitwise
comparisons from C compilers, which can't be borrowed on the js platform
in the web browser. Conditional compilation here should fix the issue
for this and downstream libraries such as `std/rationals` when compiling
to browser js as the backend.
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
makes new hash the default, with an opt-out (& js-no-big-int) define.
Also update changelog (& fix one typo).
Only really expect the chronos hash-order sensitive test to fail until
they merge that PR and tag a new release.
added small note regarding style insensitivity for parsing enums. the
casing of the first letter is still taken into account for this
function. was confused a little at first because when I read "style
insensitive manner" I thought it meant casing as well and ran into a
couple of `ValueError`'s because of it.
Using initOptParser with an empty cmdline (so that it gets the cmdline
from the command line) in nimscripts does not yield the expected
results.
Fixes#23774.
After this pr, for a string with just 20 length and 6 `'\t'`, the time reduces by about 1.5%[^t].
Also, the code is clearer than the previous at some places.
[^t]: Generally speaking, this rate increases with length. I may test
for longer string later.
Unlike present Nim this actually fills `Hash` for `string` & related.
For the curious, note that `hashData` remains the aboriginal Nim string
hasher & `import hashes {.all.}` allows simultaneous test/time of {orig,
murmur, farm} on your favorite CPU & back end compiler.
Update tests also conditioned upon `nimPreviewHashFarm` so they should
pass either with or without that `define` on.
In `--jsbigint=on` mode, only the lower 32-bits of `Hash` match nimvm &
run-time values because `type Hash = int` and on JS int=int32, not int64
as for 64-bit Nim platforms. Due to the matching, `const` Table should
match run-time `Table` on all platforms.
To operate in `--jsbigint=off` mode is feasible but needs much "double
precision mul/xor/ror/shr-arithmetic"-style work. That is distracting &
also of questionable value since JS added BigInt in 2018, ringabout
added Nim support for it in 2021 & `nimPreviewHashFarm` is unlikely to
swap from an opt-in to an opt-out default before 2025..2026 which will
have given a backward looking time window of 7..8 years for deployment
platforms - reasonably generous.
Add a changelog entry for 2.2.
Fix non-exported `setFileSize` to take optional `oldSize` to (on posix)
shrink differently than it grows (`ftruncate` not `posix_fallocate`)
since it makes sense to assume the higher address space has already been
allocated there and include the old file size in the `proc resize` call.
Also, do not even try `setFileSize` in the first place unless the `open`
itself works by moving the call into the `if newFileSize != -1` branch.
Just cosmetics, also improve some old 2011 comments, note a logic diff
for callers using both `mappedSize` & `newFileSize` from windows branch
in case someone wants to fix that & simplify code formatting a little.
fixes#23513
Also, the old `runnableExample` is just a copy of `proc
parseInt(openArray[char], var int, int)` variant (in Line 1000).
---------
Co-authored-by: ringabout <43030857+ringabout@users.noreply.github.com>
Because of the bug in `tools/parse_unicodedata.nim`, CJK Ideographs were
not considered letters in `isAlpha()`, even though they have category
Lo. This is because they are specified as range in `UnicodeData.txt`,
not as separate characters:
```
4E00;<CJK Ideograph, First>;Lo;0;L;;;;;N;;;;;
9FEF;<CJK Ideograph, Last>;Lo;0;L;;;;;N;;;;;
```
The parser was not prepared to parse such ranges and thus omitted almost
all CJK Ideographs from consideration.
To fix this, we need to consider ranges from `UnicodeData.txt` in
`tools/parse_unicodedata.nim`.
This adds a version of `almostEqual` (which was already available for
floats) thata works with `Complex[SomeFloat]`.
Proof that this is needed is that the first thing that the complex.nim
runnable examples block did before this commit was define (an
incomplete) `almostEqual` function that worked with complex values.
## Bug
Fixes https://github.com/nim-lang/Nim/issues/12381 - HttpClient socket
handle leak
To replicate the bug, run the following code in a loop:
```nim
import httpclient
while true:
echo "New loop"
var client = newHttpClient(timeout = 1000)
try:
let response = client.request("http://10.44.0.4/bla", httpMethod = HttpPost, body = "boo")
echo "HTTP " & $response.status
except CatchableError as e:
echo "Error sending logs: " & $e.msg
finally:
echo "Finally"
client.close()
```
Note the IP address as the hostname. I'm directly connecting to a
plausible local IP, but one that does not resolve, as I have everything
under 10.4.x.x.
The output looks like this to me:
```
New loop
Error sending logs: Operation timed out
Finally
New loop
Error sending logs: Operation timed out
Finally
New loop
...
```
In Nim 2.0.4, running the code above leaks the socket:
<img width="944" alt="Screenshot 2024-05-05 at 22 00 13"
src="https://github.com/nim-lang/Nim/assets/53387/ddac67db-d7df-45e6-b7a5-3d42f79775ea">
## Fix
With the added line of code, each old socket is cleanly removed:
<img width="938" alt="Screenshot 2024-05-05 at 21 54 18"
src="https://github.com/nim-lang/Nim/assets/53387/5b0b4b2d-d4f0-4e74-a9cf-74aec0c50d2e">
I believe the line below, `closeUnusedFds(ord(domain))` was supposed to
clean up the failed connection attempts, but it failed to do so for the
last one, assuming it succeeded. Yet it didn't. This fix makes sure
failed connections are closed immediately.
## Tests
I don't have a test with this PR. When testing locally, the
`connect(lastFd, ..)` call on line 2032 blocks for ~75 seconds, ignoring
the http timeout. I fear any test I could add would either 1) take way
too long, 2) one day run in an environment where my randomly chosen IP
is real, yielding in weird flakes.
The only bug i can imagine is if running `lastFd.close()` twice is a bad
idea. I tested by actually running it twice, and... no crash/op? So
seems safe? I'm hoping the CI run will be green, and this will be
enough. However I'm happy to take feedback on how I should test this,
and do the necessary changes.
~Edit: looks like a test does fail, so moving to a draft while I figure
this out.~ Attempt 2 fixed it.
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.
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.
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
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>
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>
