cyrozap has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
cyrozap has joined #amaranth-lang
<purdeaandrei[m]>
Is there something akin to asyncio.create_task in amaranth?
<purdeaandrei[m]>
or asyncio.gather?
<whitequark[m]>
not currently (adding it would require an RFC)
<purdeaandrei[m]>
So at the moment, the only way I can achieve perceived parallelism is by adding a testbench or process, right?
<whitequark[m]>
yes
buganini has quit [Ping timeout: 245 seconds]
<purdeaandrei[m]>
Can I create (and destroy?) a testbench at runtime
<whitequark[m]>
only before the simulator starts running
buganini has joined #amaranth-lang
<purdeaandrei[m]>
Is there any way I can create a 1ns delayed version of an expression? (or to look at the value of an expression from the past?) ctx.changed() only accepts Signals. Which makes sense I think, the simulator would need to know to recalculate the value of the expression every time one of its dependencies changes, so I guess I would have to wrap my expression as a Signal, but I can't drive that signal with ctx.set, cause it doesn't
<purdeaandrei[m]>
solve my problem I still want to wait on changes of the signal, it would have to be something like `m.d.comb += ` but I think there's no way to schedule something like that from a testbench, unless I make it part of a dut?
<vegard_e[m]>
ideally ctx.changed() should accept expressions
<purdeaandrei[m]>
I guess it could, but it doesn't right now
<zyp[m]>
Catherine: Just noticed I missed the `deadline` argument of `Simulator.run_until()` in RFC 66. I will include it in the implementation; should we also go back and update the RFC?
<whitequark[cis]>
sure
nyanotech has quit [Remote host closed the connection]
nyanotech has joined #amaranth-lang
<zyp[m]>
what's the policy for tests and deprecated code? do I just update all test cases calling Simulator.add_clock() and friends to pass a Period and drop the deprecated form?
<whitequark[cis]>
I'd say copy them and modify the old ones to suppress the warning
<whitequark[cis]>
good evening everyone, it is time for our scheduled Monday meeting
<whitequark[cis]>
who's attending?
jfng[m] has joined #amaranth-lang
<jfng[m]>
o/
<cr1901>
Isort of
galibert[m] has joined #amaranth-lang
<galibert[m]>
Vaguely
<zyp[m]>
o/
<Wanda[cis]>
meow (I may or may not drop randomly)
Chips4MakersakaS has joined #amaranth-lang
<Chips4MakersakaS>
I will be preparing food at the same time; so not really attending.
<whitequark[cis]>
please respond with your comments or disposition: merge or close
<cr1901>
merge
<jfng[m]>
> This will add an implied requirement for a ValueCastable to implement .eq() to be usable with lib.wiring.
<jfng[m]>
i don't see this as a drawback; not implementing `.eq()` would communicate that the ValueCastable is immutable
<galibert[m]>
merge, do you expect automatic insertion of adapters at some point in the future?
<whitequark[cis]>
mine is merge; RFC looks good, the language is extended in a natural way, and because of the 1-version grace period, if we are making a mistake, we have ample opportunity to revert it partly or in full
<whitequark[cis]>
I do not expect automatic insertion of adapters to ever be a part of the language
<galibert[m]>
ok, I tend to agree, explicit is probably better
<whitequark[cis]>
(you could make a wrapper around connect that does it, since connect isn't magic)
<Wanda[cis]>
the RFC presumably should also apply to EnumView?
<whitequark[cis]>
ah, good point
<jfng[m]>
merge
<zyp[m]>
Wanda[cis]: I thought enums already were typesafe, but I see now that only goes for comparisons, not `.eq`
<zyp[m]>
so yeah, it'd make sense to include EnumView too
<whitequark[cis]>
Wanda: all good with the modification?
<Wanda[cis]>
hm
<Wanda[cis]>
I think so, yes
<Wanda[cis]>
or
<Wanda[cis]>
need to look somehting up
<Wanda[cis]>
... ah Struct is a subclass, good
<whitequark[cis]>
yeah
<whitequark[cis]>
View is intended to be inherited from (so long as you don't break the base class)
<Wanda[cis]>
"If other is a View, reject the assignment if layouts are not identical"
<Wanda[cis]>
I'd say something different
<Wanda[cis]>
namely, it should depend on other's shape, not type
<Wanda[cis]>
for one, we also have data.Const to deal with
<Wanda[cis]>
second, the RFC as written allows assigning a Value to a struct, but doesn't allow assigning ArrayProxy (because it counts as a non-View ValueCastable)
<zyp[m]>
hmm
<whitequark[cis]>
so "if the other is a View, reject the assignment if its .shape() isn't a data.Layout"?
<Wanda[cis]>
I think Layout.cast may have to be involved, even
<whitequark[cis]>
this is getting kind of complicated, but, hm
<whitequark[cis]>
yeah
<Wanda[cis]>
anyway
<zyp[m]>
the issue is that currently it's only the .eq target that can indicate compatibility or not, we still don't have a reflected .eq that can say «this ValueCastable can be assigned to anything that accepts a Value»
<Wanda[cis]>
I'm... concerned that the current state of value/shape-castables is kinda an ad-hoc mess
<zyp[m]>
(relfected .eq came up in RFC 28 discussions)
<Wanda[cis]>
while I don't really have anything against this RFC in particular, it feels like it's adding even more complexity
<Wanda[cis]>
to an area that's already hard to understand
<whitequark[cis]>
I generally agree but I also don't see how we could avoid it
<whitequark[cis]>
the writing was on the wall by the time connect was added
<whitequark[cis]>
it's basically the C++ problem of extending an overly simple language in a backwards-compatible way getting overly complex
<zyp[m]>
I can amend the RFC to not reject non-view value-castables
<Wanda[cis]>
yeah I don't think I have a solution either
<whitequark[cis]>
zyp[m]: I think we can proceed with it as-is
<zyp[m]>
what about ArrayProxy?
<Wanda[cis]>
we do need to at least allow data.Const
<zyp[m]>
agreed
<whitequark[cis]>
would ArrayProxy be redefined on top of Choice which does the shape comparison thing?
<whitequark[cis]>
that makes Choice a requirement for the 0.6 release
<whitequark[cis]>
we ran out of time for today
<zyp[m]>
I'll update the RFC for next week, including enum.EnumView and data.Const and look at specifying the exact check conditions better
<zyp[m]>
and if I have time maybe I'll do a proof of concept too
<zyp[m]>
speaking of 0.6, do we have a roadmap yet?