<charlottia>
huh. And sure enough, the change from `self` to `mask` in those binary operands makes the difference, because of adding the extra layer of `(mask & _)` enough times.
<mwk>
so: the CRC module makes a deeply nested amaranth HDL expression; pysim directly translates it to Python, multiplying the nesting level by some small constant due to the masking, you end up overflowing the fixed-size Python parser stack
<mwk>
the limit is Python-compile-time constant and non-configurable btw
<mwk>
and I mean cpython-compile-time
<whitequark>
yea it's not the first time we hit that
<charlottia>
indeed. The xor branch alone returns chunks of Python many thousands of bytes long in this case (which are then included in others).
<whitequark>
but it usually was due to very large Array expressions in memories
<whitequark>
the fix is simple, add intermediate temporaries for expressions that are more than like, 1k long
<whitequark>
we have the infra for it iirc?
<charlottia>
hrmmm. The value compiler descends fairly directly through its operands..
<whitequark>
I don't entirely remember it yea >_>
<charlottia>
oh, yeah, just self.emitter.def_var/gen_var.
<whitequark>
yep
<charlottia>
can confirm the most brainless test impl of that does fix.
<whitequark>
perfect!
<adamgreig[m]>
aah, I was testing locally on py3.10 and the CI was bombing out on 3.8 and so cancelling the >3.8 runs so we never saw them succeed
<adamgreig[m]>
shame as it would have been a bit more obvious if 3.8 was/3.9 was failing and 3.10 worked
<_whitenotifier-6>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 8314b0b - Deploying to main from @ amaranth-lang/amaranth@60c2a1b4b86fe20601dd910a9699f1718838e7f0 🚀
<adamgreig[m]>
whitequark: rebased onto the new main and looks like tests are passing. thanks charlotte!
<_whitenotifier-6>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 14e57df - Deploying to main from @ amaranth-lang/amaranth@45b9730786560893e7cc8eefa3409911be811d15 🚀
Degi_ has joined #amaranth-lang
Degi has quit [Ping timeout: 252 seconds]
Degi_ is now known as Degi
croedv has joined #amaranth-lang
elle has quit [Remote host closed the connection]
elle has joined #amaranth-lang
croedv is now known as peizled
crzwdjk has quit [Quit: Client closed]
peizled is now known as skiidc
skiidc has quit [Remote host closed the connection]
<_whitenotifier-6>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] a5e2697 - Deploying to main from @ amaranth-lang/amaranth@cdf8fcc32ffc8bab7aaf01d9def893ced368e376 🚀
<galibert[m]>
ok, there's just too much I don't understand inthe python class/type system
<galibert[m]>
I want to call a load method at every level of the inheritance hierarchy of a given object in order from top to bottom (doing stuff between each load, so super().load(...) in the method is not good enough). It looks way more complicated that I would have expected
<mwk>
(as in, the Python language gets to define arbitrary magic semantics for such names, and you should only use these names as defined by these semantics)
<Psentee>
I've seen a pattern of using `_names_` surrounded with single underscores for "userland magic", it's similar enough to be readable and still distinct from reserved `__magic__`
jjsuperpower has joined #amaranth-lang
<galibert[m]>
Yeah, not sure why I did that in the first place, it makes no sense, I'll change it
<whitequark>
<mwk> "also may I recommend `for t in..." <- charlotte: I think your PR could use `ShapeCastable in type(obj).mro()`? It's still *weird* but it's slightly less weird to explain to people that they'll have to use it...
<galibert[m]>
errr, the discussion with mwk had nothing to do with amaranth (sorry, btw)
<galibert[m]>
(it had to do with RE-ing the cyclone V fwiw)