If it adds to the environment then it ultimately creates the same
kind of problem it was intended to solve--a need to reproduce
the calls to `subprocess` in the code outside. It's not that hard
to merge two dicts, plus much of the time enough you can get by with
having just `PATH` and `AMARANTH_ENV_*` (if even that).
If an override is wanted it can be done easily enough with:
.execute_local(env={**os.environ, "VAR": "VALUE"})
Build scripts are explicitly intended to have overrides that are
done through the use of environment variables, and right now this
would require a very awkward `run_script=False` invocation followed
by copying a bit of code out of the Amaranth codebase, which is
clearly suboptimal.
Using `sys.excepthook` to silence the must-use warning has some false
negatives: applications may catch the exception and then quit
normally, e.g. becaue the error is well known and does not require
a traceback to be shown (which would be noisy). The current
implementation prints even more noise in that case.
In addition to the existing heuristic, silence the warning if
*nothing* has been elaborated, which is almost always a reliable
sign. It doesn't work if multiple designs are independently created
in the application and some of them are dropped without being used,
but this is unavoidable as it is not distinguishable from the mistake
this warning is attempting to prevent.
Fixes#848.
The main purpose of this change is migrating glasgow from the compat
`TSTriple` (which allows 0 width) to `Pin`. This sort of change would
normally require a RFC, but `Pin` is already slated for
removal/replacement, so that was deemed to be unnecessary.
There's an actual `py_enum.member` (which we briefly overwrite our loop
index with (!)). We delete our `member`, but it's still in the
`__all__` that came from `py_enum`, so `import *` fails.
Amaranth bitwise negation `~` compiles to Python bitwise negation `~` in
simulation; the same holds for comparison operators such as `==`. Thus
an expression such as `~(a == b)` in simulation will compile to Python
that takes the bitwise negation of the comparison result, which will be
an actual bool.
On 3.12, the result is a `DeprecationWarning` emitted only at simulation
run-time.
When negating in simulation, coerce the value to an int. `mask` is
sufficient as we do no further arithmetic here.
The only breaking change in 0.4 is dropping support for Python 3.6,
which Amaranth has already dropped. It also adds official support for
3.10 and 3.11.
3ad7340072/CHANGELOG.rst
This fixes the following issues:
- on Python 3.10 and earlier, storing to free variables is now handled
correctly
- on Python 3.11, `_varname_from_oparg` is now used, fixing problems
with cell variables that are also arguments
- on all supported versions, EXTENDED_ARG is now parsed, ensuring proper
handling for long functions
Fixes#792.
This is actually an existing correctness requirement (for the similar
reasons that ValueCastable.as_value() must always return the same
value every time) that for some reason wasn't respected.
See amaranth-lang/rfcs#15 and #784.
Note that this RFC breaks the existing syntax for initializing a view
with a new signal. Instances of `View(layout)` *must* be changed to
`Signal(layout)`.
