* Remove unnecessary environment tracking
* try to fix windows
* fix delEnv
* make putEnv work on windows even with empty values; improve tests: add tests, add js, vm testing
* [skip ci] fix changelog
Co-authored-by: Caden Haustein <code@brightlysalty.33mail.com>
* [enumutils] provide node kind for `Invalid node type` error
* [enumutils] add support for nnkAccQuoted in `genEnumCaseStmt`
For reasons unknown to me, when running `nim doc` on a file that uses
`parseEnum` with an enum that contains accented quotes errors at CT
with the `Invalid node for type` error. Further errors are raised,
probably because the enum parsing fails?
* Replace calls to C `putenv` with C `setenv` to remove possible memory leaks
* Add test of correct behaviour on invalid input
* Fix style in tests/stdlib/tos.nim
Co-authored-by: Timothee Cour <timothee.cour2@gmail.com>
* Update tests/stdlib/tos.nim
Co-authored-by: Timothee Cour <timothee.cour2@gmail.com>
* Update tests/stdlib/tos.nim
Co-authored-by: Timothee Cour <timothee.cour2@gmail.com>
* Add comment with bug number to tests/stdlib/tos.nim
Co-authored-by: Timothee Cour <timothee.cour2@gmail.com>
* Fix possible msvc arch issues
Co-authored-by: Timothee Cour <timothee.cour2@gmail.com>
* add [1..2] for JArray
* fix BackwardsIndex to int
* fix for BackwardsIndex
* fix for assert node kind check
* fix variable name
* Update lib/pure/json.nim
* fix for when x.a is BackwardsIndex
Co-authored-by: itsumura-h <dumblepy@mail.com>
Co-authored-by: Dominik Picheta <dominikpicheta@googlemail.com>
* document some std library evolution policies
In wanting to improve the standard library, it's helpful to have a set
of principles and guidelines to lean back on, that show how to introduce
such improvements while at the same time considering existing users of
the language.
A key idea behind documentation of this sort is that it should highlight
a path forwards in making changes rather than trying to prevent them,
and although the current snippet does include some language for what one
shouldn't do, it also shows a few options for what one can do.
This is a riff on https://github.com/nim-lang/Nim/pull/18468 mainly
based on what helps enable to the use of Nim productively in
environments and teams where the priority and focus is not always on the
tool (Nim in this case) but rather on the codebase itself, and its use
by end users.
We use similar guidance documentation to help coordinate the code of the
teams using Nim in https://status-im.github.io/nim-style-guide/ where it
is applied not as law, but rather as recommendations for the default
approach that should be considered first.
* document the new policies
* typo
* Update doc/contributing.rst
Co-authored-by: Timothee Cour <timothee.cour2@gmail.com>
* Update doc/contributing.rst
* Update doc/contributing.rst
Co-authored-by: konsumlamm <44230978+konsumlamm@users.noreply.github.com>
* Update doc/contributing.rst
Co-authored-by: konsumlamm <44230978+konsumlamm@users.noreply.github.com>
* Update doc/contributing.rst
* Update doc/contributing.rst
Co-authored-by: konsumlamm <44230978+konsumlamm@users.noreply.github.com>
* clarify some things
* Update doc/contributing.rst
Co-authored-by: Dominik Picheta <dominikpicheta@googlemail.com>
Co-authored-by: Jacek Sieka <arnetheduck@gmail.com>
Co-authored-by: Timothee Cour <timothee.cour2@gmail.com>
Co-authored-by: konsumlamm <44230978+konsumlamm@users.noreply.github.com>
Co-authored-by: Dominik Picheta <dominikpicheta@googlemail.com>
