<Wanda[cis]>
it sounds like something mildly useful
<mcc111[m]>
That would be nice actually. The reason I want this is I have three simulate methods (generate gtkwave, generate video, generate audio) and I want to share a process function between them.
<mcc111[m]>
I can do this easily with a factory to generate closures. It's just not as terse as it could be.
balrog has quit [Quit: Bye]
indy_ has quit [*.net *.split]
toshywoshy has quit [*.net *.split]
indy_ has joined #amaranth-lang
toshywoshy has joined #amaranth-lang
SpaceCoaster has quit [Read error: Connection reset by peer]
SpaceCoaster has joined #amaranth-lang
SpaceCoaster has quit [Read error: Connection reset by peer]
SpaceCoaster has joined #amaranth-lang
whitequark[cis] has joined #amaranth-lang
<whitequark[cis]>
<Wanda[cis]> "async def testbench(ctx, meow):..." <- that would mean we can't add new options to add_testbench
<Wanda[cis]>
yeah that is a problem
<whitequark[cis]>
there's functools.partial
FFY00 has quit [Read error: Connection reset by peer]
FFY00 has joined #amaranth-lang
cr1901_ has quit [Read error: Connection reset by peer]
zyp[m] has joined #amaranth-lang
<zyp[m]>
a method or property on the context to get the toplevel sounds reasonable
<whitequark[cis]>
I feel like it unreasonably privileges the toplevel
cr1901 has joined #amaranth-lang
<whitequark[cis]>
I can foresee many calls to add_testbench not caring about the toplevel because they're connected to some peripheral core and are emulating the connected peripheral; this property doesn't help at all that use case
<whitequark[cis]>
Wanda's suggestion does cover it, but has other issues; functools.partial already exists
<Wanda[cis]>
yeah, partial seems like the way to go
<Wanda[cis]>
actually hm.
<Wanda[cis]>
no, it's not
<whitequark[cis]>
ah?
<Wanda[cis]>
add_testbench will only accept an async function, a partial object does not qualify
<whitequark[cis]>
oh.
RobTaylor[m] has joined #amaranth-lang
<RobTaylor[m]>
hmm, do folk just totally disable type checking when working with amaranth at the moment? I can't figure out how to get data.Struct, data.Union to not give errors :/
<whitequark[cis]>
yes
<whitequark[cis]>
you can add this to your vscode config: "python.analysis.typeCheckingMode": "basic"
<tpw_rules>
whitequark[cis]: is there a reason you are on a different matrix for #glasgow? it doesn't matter at all to me except for your color is different
<whitequark[cis]>
i'm talking on discord because there is a one way netsplit between discord and matrix rn
<whitequark[cis]>
which i should really fix
<tpw_rules>
oh
<RobTaylor[m]>
Catherine: i'm a vim user still ;)
<whitequark[cis]>
Rob Taylor: oh yeah I didn't realize (especially given that RTL Debugger is a VS Code extension...)
<whitequark[cis]>
are you using pylance or mypy?
<RobTaylor[m]>
Catherine: currently pyright. Which would you suggest?
<whitequark[cis]>
pyright is fine
<whitequark[cis]>
in fact it's the only typechecker I'm willing to support even in the long run
<whitequark[cis]>
(I'm open to the idea to adding type annotations to Amaranth, provided that's done in separate files from the implementation)
<RobTaylor[m]>
nod. I guess but then how would the novel use of annotations work?
<RobTaylor[m]>
i guess you could make unsigned, signed, StructLayout, UnionLayout etc types, have them work a-la NewType
<RobTaylor[m]>
cant see how to get "member: 1" to work though
<whitequark[cis]>
there's no way to get it work yeah
<whitequark[cis]>
best I can do is to make amaranth.U1, amaranth.S1, etc work, either by defining a huge list of them or by using getattr or something
<whitequark[cis]>
you would have to individually import types for each, which is annoying as hell, but people who use python typechecking seem to have an incredibly high tolerance for churn and noise in their code, so i guess it's fine?
<whitequark[cis]>
for layouts, you would have to define them using data.Struct for static layouts
<whitequark[cis]>
and for dynamic layouts I think there might just be no reasonable way to express them in the Python type system in the general case
<whitequark[cis]>
that would be Annotated[Value, unsigned(1)]
<whitequark[cis]>
there could be a U1 = Annotated[Value, unsigned(1)] somewhere
<RobTaylor[m]>
whitequark[cis]: oh of course
<RobTaylor[m]>
I wonder if it could be Unsigned[1].. I'm not entirely udnerstanding how Literal[] works yet
<whitequark[cis]>
RobTaylor[m]: `Literal[]` is special-cased
<whitequark[cis]>
the ergonomics of types are atrocious, which is why I want them to stay out of the main codebase, and only be present for public APIs for consumers (using the same mechanism that type stubs employ, just a first-party one)
<whitequark[cis]>
pyright itself does a great job inferring most of the things you would care about from the bodies of classes and methods (unlike mypy, which mostly requires and produces noise)
<RobTaylor[m]>
yeah, i'm mostly concerned with being able to use types in my code and not get errors =)
<whitequark[cis]>
but even with pyright, i trialed adding annotations in a few places, and in my view it has made the codebase worse for no real benefit
<whitequark[cis]>
also, someone i knew tried adding types internally in amaranth._hdl and it resulted in some horrific workarounds for the fact that typecheckers can't cope with circular references, where a superclass returns an instance of a subclass
<whitequark[cis]>
(this isn't quite an accurate description, it's the best my memory can provide right now; it's close enough anyhow)
<whitequark[cis]>
i think the main value of pyright is providing IDE completion, which it mostly does without any additional annotations
<RobTaylor[m]>
yeah, its like when you want to use a type reference when you're defining the class, you have to use 'Self' or a string of the type
<whitequark[cis]>
for this reason i've actually put some @types.overload in the codebase, like in the simulator, even if in general i don't add annotations
<RobTaylor[m]>
yeah, i noticed that :_
<RobTaylor[m]>
s/_/)/
<whitequark[cis]>
ultimately i feel like python typechecking is usually mandated as a sort of corporate compliance thing, where you have the power to enforce this bureaucracy and also most developers are just not very familiar with python but you want to hold them to a minimum bar anyways
<whitequark[cis]>
which contrasts with e.g. rust typechecking, which enables you to work on a new level
<RobTaylor[m]>
I dunno, I like it myself as it catches the kinds of errors i make
<RobTaylor[m]>
and I like to know what I'm meant to be passing.
<RobTaylor[m]>
but yeah, they are useful in that corporate context for sure.
<whitequark[cis]>
Amaranth doesn't really have many types in first place: the entire Value hierarchy implements the same API, basically everything in amaranth.hdl accepts a Value or primives (int, str, bool)
<whitequark[cis]>
things do get more complicated with lib.data but I'm also unsure if the typechecker is even powerful enough to understand how lib.data views work
<whitequark[cis]>
I think of the shape of the API as well as the types provided as a set of affordances: you can simplify working with the codebase by providing numerous ones, but some of them can also be not that useful or have a high cost of its own
<whitequark[cis]>
the primary affordance we currently rely on is simplicity of the API itself, which is aggressively maintained via the RFC process