<_whitenotifier-3>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] abed722 - Deploying to main from @ amaranth-lang/amaranth@3d0c5426df8a045179c80119906523d94496b2b0 🚀
<ravenslofty[m]>
Catherine: the "Rendered" link is broken, because it points to `0000-make-signature-immutable.md` but the actual RFC you added is in `0037-make-signature-immutable.md`
<ravenslofty[m]>
I have an objection to this, but it's...perhaps more of a meta-objection? an objection to the process in this case rather than the text. is that valid?
<ravenslofty[m]>
judging by 0034, it's probably not valid.
<whitequark[cis]>
what is the objection?
<ravenslofty[m]>
to me, 34 and 35 are more or less patches to RFC 2, and if RFCs are the present documentation for a particular feature (at least, they seem to be), then they should at least modify the text of RFC 2 to indicate they made a change to it
<whitequark[cis]>
they are not
<whitequark[cis]>
the RFCs document the decisionmaking. the feature is documented by the, well, documentation
<whitequark[cis]>
(there's currently no documentation for lib.wiring but there is a huge open PR for adding it and I'm actively working on fixing it. lib.wiring is a huge and fairly complex feature so the docs took a while to write)
<whitequark[cis]>
anyway, there's an "RFC amended by:" badge that should be added for a few RFCs, I've not been up to date on it, but this should be fixed too
frgo has joined #amaranth-lang
<_whitenotifier-3>
[amaranth-soc] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-61-2b37115c7b996ad0befc73837ed16683dd07f06b - https://github.com/amaranth-lang/amaranth-soc
nelgau_ has quit [Remote host closed the connection]
frgo has quit [Remote host closed the connection]
frgo has joined #amaranth-lang
nelgau has quit [Ping timeout: 252 seconds]
nelgau_ has joined #amaranth-lang
nelgau_ has quit [Remote host closed the connection]
nelgau has joined #amaranth-lang
frgo has quit [Ping timeout: 256 seconds]
frgo has joined #amaranth-lang
frgo has quit [Ping timeout: 255 seconds]
frgo has joined #amaranth-lang
frgo has quit [Ping timeout: 256 seconds]
frgo has joined #amaranth-lang
frgo has quit [Ping timeout: 264 seconds]
<tpw_rules>
re rfc 38: "Do not override the signature property, as both Amaranth and third-party code relies on the fact that it is assigned in the constructor and never changes." so overriding it and adding another member unconditionally becomes verboten? or at least harshly judged?
nelgau has quit [Read error: Connection reset by peer]
<galibert[m]>
Yes
nelgau has joined #amaranth-lang
<galibert[m]>
You’re supposed to have it done at construction time
<whitequark[cis]>
tpw_rules: you should be able to do that within the constructor now
<tpw_rules>
and super().signature within the constructor will be an attributeerror or something?
<tpw_rules>
also, is "the internal attribute"'s name sufficiently unique that someone won't accidentally clobber it? not self._sig or self._signature?
<whitequark[cis]>
yes
<whitequark[cis]>
to both
<tpw_rules>
okay. i think i'd only have a problem with this if interior mutability comes back
nelgau has quit [Read error: Connection reset by peer]
cr1901 has quit [Remote host closed the connection]
nelgau has joined #amaranth-lang
cr1901 has joined #amaranth-lang
frgo has joined #amaranth-lang
<tpw_rules>
it does quite dramatically limit the sensible possibilities there
cr1901 has quit [Remote host closed the connection]
<zyp[m]>
you wouldn't use self._signature anymore, but instead make/modify it locally and then pass it to super().__init__()
<zyp[m]>
sorry, that's 38, not 37
frgo has quit [Ping timeout: 255 seconds]
<zyp[m]>
37 and 38 together means you'd make/modify the members dict locally and then pass it to super().__init__(Signature())
<cr1901>
I ask b/c in 37, __iadd__ methods are removed, but __setitem__ isn't?
<whitequark[cis]>
__setitem__ is just a stub that always raises an exception
<cr1901>
You mean after this RFC, correct?
<galibert[m]>
Catherine: is there a way to build an object piecewise with any kind of mangling in it that you then pass to Signature to get a signature Component will accept?
<galibert[m]>
object where it can add, setitem, delete item, whatever
<zyp[m]>
just keep the members in a dict
<galibert[m]>
I guess a hash would do in fact?
<galibert[m]>
well a dict in python parlance
<galibert[m]>
ok, so you build the {} and just init(Signature(obj)) near the end
<whitequark[cis]>
sorry, I was thinking of something else
<whitequark[cis]>
yes, __setitem__ should be added to the list of removed methods
<cr1901>
ack
<cr1901>
Then disposition to merge for both 36 and 37 for me. Fixes for my use case are easy enough.
<whitequark[cis]>
it is 1703 UTC, which is the time for our regularly scheduled Amaranth meeting
<cr1901>
I'm only sporadically around today (I don't like how split my bandwidth is this time of year).
<whitequark[cis]>
today we have two main items on the agenda, which are the last ones required to make a 0.4 release; we will resume regular discussion next Monday
<whitequark[cis]>
please respond with your comments
<zyp[m]>
it seems reasonable to me
<Wanda[cis]>
I do like fewer moving parts
<cr1901>
It's a welcome reduction in complexity in a feature I never used/didn't even know how to use
frgo has joined #amaranth-lang
frgo has quit [Read error: Connection reset by peer]
<zyp[m]>
I do have some code that appends stuff to the signature as it goes, but it's trivial to convert it to put members in a dict and finally make a signature from it
frgo has joined #amaranth-lang
<cr1901>
yea, this. I'll happily fix my own code
<whitequark[cis]>
this is what Amaranth SoC does already
<zyp[m]>
on interior mutability, what will it mean when we later want to put clock domains into signatures?
<whitequark[cis]>
dunno
<cr1901>
What _is_ interior mutability in this context?
<zyp[m]>
I interpreted it as mutability of other content than the members property
<whitequark[cis]>
yes
<cr1901>
ahhh, hmmm...
<cr1901>
No further comments from me
<zyp[m]>
given that clock domains are resolved after elaboratables (and thereby their signatures) are constructed, it seems like that part of the signature would have to be mutable for it to work
<tpw_rules>
is that a thing that could be on the interface instead?
frgo has quit [Ping timeout: 252 seconds]
<whitequark[cis]>
zyp: I think the domain will be static, just like how it is static in `m.d.<domain>`, which is not modified
<zyp[m]>
so the signature would specify the domains as they appear locally before resolution, and then we'd have to translate them through another mechanism if we want the global domain?
<whitequark[cis]>
yes
<whitequark[cis]>
the signature would basically live in the top-level scope created by elaborate
<whitequark[cis]>
okay, please reply with your proposed disposition on RFC 37: merge or close
<zyp[m]>
merge
<jfng[m]>
merge
<Chips4MakersakaS>
merge
<cr1901>
merge
<whitequark[cis]>
Wanda?
<Wanda[cis]>
merge
<whitequark[cis]>
absentee: @galibert merge. disposition on RFC 37: merge, without changes
<whitequark[cis]>
please respond with your comments
<galibert[m]>
back
<galibert[m]>
suggestion: allow a dict in the constructor in addition to a signature
<whitequark[cis]>
I feel like that does nothing but reduce clarity
<zyp[m]>
I was thinking about the same
<whitequark[cis]>
although, hm
<whitequark[cis]>
you will almost never use a custom Signature subclass for Component
<zyp[m]>
the only reason to accept a signature and not a dict is for when you'd use a predefined signature
<zyp[m]>
which could be useful later when we get standard stream interfaces, could e.g. have a stream filter signature that also contains other metadata like latency
<whitequark[cis]>
ok, I agree
frgo has joined #amaranth-lang
<galibert[m]>
forgot the bread, need to go out again, merge for me whichever way
<whitequark[cis]>
any other comments?
<zyp[m]>
looks good to me
<whitequark[cis]>
please respond with your disposition on RFC 38: merge or close
<whitequark[cis]>
absentees: @galibert merge
<Chips4MakersakaS>
merge
<zyp[m]>
merge, preferably with the addition to be able to pass the members dict directly
frgo has quit [Ping timeout: 246 seconds]
<cr1901>
merge, pass the members dict addition would be "nice to have"
<jfng[m]>
merge
<whitequark[cis]>
Wanda?
<Wanda[cis]>
merge
<whitequark[cis]>
disposition on RFC 38: merge
<whitequark[cis]>
thanks everyone; I am very tired so I'll close this meeting now. next Monday we'll get back to the (growing) queue of things to discuss that isn't tied to the release
<whitequark[cis]>
and I plan to make the 0.4.0 release tomorrow
<_whitenotifier-3>
[amaranth-lang/amaranth-lang.github.io] whitequark 5c65632 - Deploying to main from @ amaranth-lang/rfcs@7cf237d5b02f799b1e311a7c30ae707e52d38075 🚀
<_whitenotifier-3>
[amaranth-lang/amaranth-lang.github.io] whitequark ec1cb82 - Deploying to main from @ amaranth-lang/rfcs@14e0a6163a3f379b50f9a2dd6b0c04da7258f8aa 🚀
<_whitenotifier-3>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 5094dfb - Deploying to main from @ amaranth-lang/amaranth@b9c2404f226ce9bf72c03f2089e5daaba624ba8c 🚀
<_whitenotifier-3>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] bdd45ab - Deploying to main from @ amaranth-lang/amaranth@6ad0d21cc9944b4bf76c358ecbd9ae5de0592874 🚀
<tpw_rules>
i was only briefly there, sorry
<tpw_rules>
it's kind of an abstract and unhelpful feeling though
<tpw_rules>
i know we are anxious for 0.4 but the 7 total hours between the RFC PR being created and implementation being merged seems low, especially for something with "commit to it effectively forever" in the body.
<whitequark[cis]>
at the time, the process is that you are expected to attend meetings if you want to influence decisionmaking
frgo has joined #amaranth-lang
<tpw_rules>
that is fair. lessons learned/to learn i guess
<whitequark[cis]>
(the process before this was that I'd merge things like this effectively whenever with no warning or detailed explanation)
<tpw_rules>
please also don't forget to update the rendered RFC links
<galibert[m]>
It’s not actually dangerous, essentially because you can (mostly) stay with a dict until the point where the members are created
<tpw_rules>
also RFC #38's signatures need closing
<tpw_rules>
s/signatures/issues/ ...
<galibert[m]>
And you must create the members before elaborating, and the only guaranteed time before elaborating is construction
<tpw_rules>
actually i take that back
<galibert[m]>
So it makes explicit something that was already required
<whitequark[cis]>
tpw_rules: (also, in this particular case, it helped that I knew that previously, having mutability in core data structures--lib.data used to have it--turned out to be a serious mistake that I had to rectify at the design phase, and that mutability was only included in lib.wiring because I did not have a better solution to what is now implemented by having Const() as interface object ports)
<whitequark[cis]>
oh, so like, there was this idea that e.g. wishbone interfaces which do not implement optional features would not have thoes ports
<whitequark[cis]>
which would pose a problem for connecting them, because there's no equivalent of Record.include/exclude
<whitequark[cis]>
so I thought that mutability could be added to adapt one interface to another post-factum
<whitequark[cis]>
however it's clear that a much better idea is for the set of members to not change, but for the members corresponding to disabled optional features to be fixed at a constant value
<tpw_rules>
oh i see
<whitequark[cis]>
and without that motivation, the mutability would have never made it into the RFC 2 in first place
<whitequark[cis]>
so considering that nobody has actually used mutability for this (and it probably being just a bad idea, and not a good fit for Amaranth SoC for example) it didn't seem like there's any reason I could find for this feature to stay
<whitequark[cis]>
since nobody raised any objections it was removed
frgo has quit [Ping timeout: 252 seconds]
<tpw_rules>
i understand. like i said i didn't have any concrete objections either
<_whitenotifier-3>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 3fcde61 - Deploying to main from @ amaranth-lang/amaranth@8e6ae9e6e0bc5ab1413f99179f4b76920e8fdc39 🚀
<_whitenotifier-3>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 75a1b90 - Deploying to main from @ amaranth-lang/amaranth@d154bddf17e796b1ca0a6da409b15de97f945f6f 🚀
<_whitenotifier-3>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 9f48dec - Deploying to main from @ amaranth-lang/amaranth@fc4d70486ac1090732a3813640ecc258d4e0ef9d 🚀