frgo has quit [Read error: Connection reset by peer]
frgo_ has joined #amaranth-lang
balrog has quit [Ping timeout: 276 seconds]
cr1901 has quit [Ping timeout: 276 seconds]
RobTaylor[m] has joined #amaranth-lang
<RobTaylor[m]>
<whitequark[cis]1> "yeah. actually, I suppose that..." <- I was thinking maybe those could be in a lookaside hashed on object id, then Components could be immutable. what do you think?
<whitequark[cis]1>
I don't understand how immutability comes into play?
<whitequark[cis]1>
but yeah, we do that in other cases (for Values, which are not hashable)
<RobTaylor[m]>
I was thinking of dataclasses as Elaboratables, for simple parameterisation
<RobTaylor[m]>
may make no sense at all ><
<whitequark[cis]1>
I mean you can just do that right now?
<whitequark[cis]1>
oh, are dataclasses not hashable?
<vup>
they are hashable only iff either you set `frozen=True`, `frozen=True, eq=True` or `unsafe_hash=True`
<RobTaylor[m]>
yep. i hacked it by adding a decorator to use objectid for hash/eq, but it isn't pretty and breaks dataclass sematics
<vup>
why does `frozen=True` not work for you? or rather `frozen=True,eq=True`?
<RobTaylor[m]>
vup: because of elaboration setting members
<vup>
I see, do you not then want the semantics of a `eq=False,frozen=False,unsafe_hash=True` dataclass?
<RobTaylor[m]>
vup: feels risky, as `hdl._ir:Design` uses Elaboratables as key
<RobTaylor[m]>
probably fine tbh, but y'know. It kinda feels like immutability would be desirous for amaranth objects though.
<vup>
for which of amaranths objects? the `Elaboratable`s? I feel like those not being immutable can be pretty useful. It means I can for example have a PLL Elaboratable and then call `.add_derived_clock` or smth on it to add clocks whenever I need them. I guess you could also do thing with some kind of PLLConfig objects that you in the end pass into the PLL Elaboratable, which then can be immutable, but I don't really see the benefit in that?
<RobTaylor[m]>
vup: well, the risk there is if its already been elaborated
<RobTaylor[m]>
vup: i was playing with dataclasses so things like adding clocks could be prettily done at construction
<vup>
yeah true. I mean I even played around with some hacky layer on top of amaranth to avoid the problems with things already being elaborated. I did it by splitting elaborate into two phases, one before each submodule is elaborated and one after every submodule is elaborated. But back then I think the idea was to add the ability to emit metadata during elaboration and being able to "query" that metadata to the generate things like PLLs or CSRs
<whitequark[cis]1>
I think this should be done just before elaboration period
<whitequark[cis]1>
not during
<whitequark[cis]1>
that's fairly central to the design of Amaranth compared to Migen
<whitequark[cis]1>
is there a reason you can't query whichever metadata you need (maybe even using the new component metadata layer) before elaboration happens?
<whitequark[cis]1>
you don't have the platform yet, sure, but you could always just pass that around
<whitequark[cis]1>
"what would the PLL config be for this platform"
<vup>
hmm good question. I don't have a good example where it wouldn't work I think. I guess it would be mostly about convenience. Like I want to have something like a `ReadableSignal`, that I can just create in `elaborate` and have automatically be connected up to some SoC bus to be readable by whatever else is connected to that bus.
<whitequark[cis]1>
the problem you encounter with this is ordering
<whitequark[cis]1>
you really shouldn't be mutating anything in elaborate, ever
<whitequark[cis]1>
even if it's just exposing metadata
<whitequark[cis]1>
some of the worst bugs I had in my code with Migen were downstream of this; there was finalize (IIRC) and it was awful
<RobTaylor[m]>
damn, now i've got distracted thinking about using PEP749 to allow configurable signal widths.
* RobTaylor[m]
stops it ><
<whitequark[cis]1>
i've considered it but we won't be able to ship it for at least a year or two even if we do get an RFC passed
<whitequark[cis]1>
so it's not particularly pressing
<RobTaylor[m]>
yeah. its not trivial
<RobTaylor[m]>
Catherine: oh just found an interesting issue, `from __future__ import annotations` breaks Component
<RobTaylor[m]>
* breaks Component with python 3.13
<conventia[m]>
Oh, eq just returns a temporary with a reference to the signals and the domain gets updated, not the elaboratable.
<RobTaylor[m]>
whitequark[cis]1: ok, was just concerned incase 3.14 breaks stuff
<whitequark[cis]1>
i think the existing behavior remains the default, doesn't it?
<whitequark[cis]1>
<conventia[m]> "Oh, eq just returns a temporary..." <- yes! I think we cover that in the language manual too
<RobTaylor[m]>
<whitequark[cis]1> "i think the existing behavior..." <- i think annotationlib and the corresponding changes change the behavior, may be wrong! https://github.com/python/cpython/pull/119891
<vup>
whitequark[cis]1: why would exposing metadata be like mutating something? As long `elaborate` is a pure function would it not be the same as a additional return value of `elaborate`?
cr1901 has joined #amaranth-lang
<whitequark[cis]1>
ah I suppose you could implement it like that
<whitequark[cis]1>
<RobTaylor[m]> "i think annotationlib and the..." <- ah hm that could be the case. we'll fix it when that comes though
frgo_ has quit [Remote host closed the connection]
frgo has joined #amaranth-lang
frgo has quit [Remote host closed the connection]
frgo has joined #amaranth-lang
<RobTaylor[m]>
<whitequark[cis]1> "ah hm that could be the case. we..." <- +1