<whitequark[cis]>
my general thoughts on the topic is that improvements to debuggability are always welcome and i've been thinking about using the vhdl_* types potentially from the beginning
<Wanda[cis]>
hmm
<whitequark[cis]>
including them by default with an opt-out is probably a breaking change
<Wanda[cis]>
why are we not doing it in the first place? did we just forget?
<whitequark[cis]>
pyvcd doesn't support them and they're not a part of the VCD spec
<zyp[m]>
lack of pyvcd support?
<whitequark[cis]>
the latter more important than the former, i think pyvcd would add them without too many questions
<anuejn>
I like it
<whitequark[cis]>
really the third unresolved question (re pyvcd support) isn't an RFC matter, pyvcd is a non-exposed implementation detail
<zyp[m]>
same
<whitequark[cis]>
what are your thoughts on opt-out/opt-in?
<whitequark[cis]>
i feel that both options are bad, in a sense: opt-in means most people will not know about it, opt-out means we'll break some people's workflows
<zyp[m]>
I think opt out is fine, especially if you can do it by setting an env var
<whitequark[cis]>
i was gonna mention an environment variable as well
<Wanda[cis]>
I'd vote for opt-out; we're not backporting that to old releases, right?
<whitequark[cis]>
we're not
<anuejn>
yeah opt-out for me as well
<whitequark[cis]>
okay, fine by me
<whitequark[cis]>
last unresolved question is "do we continue to include the concatenated representation for records, etc"?
<Wanda[cis]>
also, how is this implemented?
<Wanda[cis]>
hm
<whitequark[cis]>
I think the RFC doesn't include an implementation
<Wanda[cis]>
I have a vague feeling I may have implemented and/or designed this thing in the first place
<whitequark[cis]>
yes
<zyp[m]>
as in the underlying value under a lib.data.View?
<whitequark[cis]>
ys
<whitequark[cis]>
I think the underlying values are quite handy to see if you're e.g. stashing it inside of an untyped memory... but then if you're using lib.memory as you should, and you still have an untyped shape, the memory ports will let you peek at that value anyway
<zyp[m]>
I don't see any reason to not have it
<whitequark[cis]>
I think the reason it's a part of the RFC is that it would create a signal at a level of hierarchy higher and dump more data
<whitequark[cis]>
like, the reason the question is there
<zyp[m]>
but that's fine, the interface (e.g. a stream) might have more signals on the same level
<whitequark[cis]>
yeah
<whitequark[cis]>
yeah I think we should probably just keep it
<whitequark[cis]>
there are plenty of cases where you have a composite value but need to operate on the complete thing anyway, like MMIO registers
<zyp[m]>
can we have a data.Layout that has bits not covered by any fields? e.g. if it's sparse
<Wanda[cis]>
ohhh right the Format-based stuff
<Wanda[cis]>
okay I remember now
<whitequark[cis]>
we can
<zyp[m]>
then we absolutely want to be able to see non-fields too
<whitequark[cis]>
yeah that is a clear rationale for having the flattened representation
<Wanda[cis]>
okay, I'm reasonably happy regarding this being implementable
<whitequark[cis]>
any other discussion?
<vup>
For which things would this create this structured representation in the vcd? Only `Signals` that are created with a layout I guess?
<Wanda[cis]>
there's a concern on the PR regarding support in Amaranth playground; what's the status with this?
<whitequark[cis]>
the playground uses pyvcd as the parser and it's already more or less broken with structured data
<whitequark[cis]>
not for pyvcd reasons, because of the library I'm using for rendering, iirc
<zyp[m]>
worst case, amaranth playground could opt-out
<Wanda[cis]>
vup: signals involving a `ShapeCastable` that has a `Format.Struct` or `Format.Array` based format, ie. usually `lib.data`-based stuff
<vup>
Wanda: so not Views created from a "untyped" signal, right? Because to me it seems like that could be handy. But tricky to track implementation / naming wise.
<Wanda[cis]>
only signals (and memories) are dumped into the VCD; any random Views constructed as intermediate expressions are not
<vup>
makes sense
<vup>
What happens for unions with this?
<Wanda[cis]>
same as now
<Wanda[cis]>
you get several traces with aliased data
<Wanda[cis]>
the only difference is that they're grouped together in the new scope thing, instead of being dumped at module level
<vup>
So in addition to what is mentioned in the RFC, a union would become a `vhdl_record` scope with aliased data?
<Wanda[cis]>
yeah
<vup>
sounds nice
<Wanda[cis]>
(same for FlexibleLayout)
<whitequark[cis]>
any further comments?
<whitequark[cis]>
okay. everyone here proposes to merge?
<Wanda[cis]>
yeah, merge
<zyp[m]>
merge
<vup>
yeah merge
<whitequark[cis]>
disposition on RFC #74: merge
<whitequark[cis]>
we have 20 minutes left, let's go with #76 since that should be a quick one
<whitequark[cis]>
I propose using git-describe to derive 0.x.y so that it autoincrements for each commit to main, and then build and upload again on each commit to main
<whitequark[cis]>
so you'd only ever tag v0.x.0 and the rest is done automatically
<whitequark[cis]>
done naively this would result in having v0.x.y and v0.(x+y).0 be uploaded with the same contents, so we should probably not build commits tagged [breaking-change] or somesuch
<zyp[m]>
so y would effectively be the number of commits, and thereby sparse if a PR contains multiple?
<whitequark[cis]>
yes
<whitequark[cis]>
we could also mandate squash&merge via repository policy
<zyp[m]>
sounds reasonable
<whitequark[cis]>
however you do it in the end, it's a bunch of somewhat fragile moving parts, but that's just the nature of doing release management with very limited resources
<zyp[m]>
do we need to define what a breaking change is? is it a breaking change to e.g. swap two pins that were incorrectly defined for a board?
<Wanda[cis]>
I'd say this is good enough for the time being
<whitequark[cis]>
a breaking change is something that requires manual intervention for many users of a repo who previously had something that worked fine
<zyp[m]>
yeah, so a minor fix for a single platform does not really count as breaking
<whitequark[cis]>
fixing something that never worked before doesn't count as "breaking change" i'd say
<whitequark[cis]>
ultimately if you need a really high level of assurance you just review the changelog on every update
<zyp[m]>
could be something innocuous like changing the order of buttons or leds to be consistent with labelling or whatever
<anuejn>
imo it is actually not suuper important to have semantic versions in -boards, its sure nice to have but its not a lot of code and the code thats there is not so tightly integrated that its easy to check if something broke for your usecase
<whitequark[cis]>
it is quite nice to have pdm update not randomly break your code
<whitequark[cis]>
any other comments?
<cr1901>
Oops. I was pinged. Uhhh, the two RFCs discussed look fine
<Wanda[cis]>
tpw_rules: having well-defined (and respected) start and end time
<tpw_rules>
i know that's been done for the whole meeting, is that also per-item now?
<whitequark[cis]>
no, just the whole meeting
<whitequark[cis]>
I skipped an item that I have reasonably foreseen us running out of time over
<whitequark[cis]>
to me this is just running a meeting skillfully, not something special
<whitequark[cis]>
but I've also been in enough poorly run meetings I guess :)
<tpw_rules>
i work on a project with a sort of open-ended meeting and it's a big drag. but i think the root of the problem there is not enough activity gets done off-meeting?
<tpw_rules>
and idk how to inspire that
eigenform[m] has joined #amaranth-lang
<eigenform[m]>
oop, sorry for missing this one! re #74, i only vaguely started sketching the implementation back when i sent the PR and didn't get particularly far. should be able to take a look today and tomorrow, but i'll be out of town the rest of the week~
<whitequark[cis]>
sounds good, thanks for your effort! it's definitely a somewhat overlooked aspect
<zyp[m]>
Catherine: do we make tracking issue for #76?
<whitequark[cis]>
amaranth-boards? sure why not (let's just put it in the main repo I guess)
<_whitenotifier-2>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] a6f6445 - Deploying to main from @ amaranth-lang/amaranth@7dcbb9e7c12b9795ed561819af6cf702b3ae5a71 🚀